From nobody Sun Nov 1 01:01: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 B86CF1B7500 for ; Sun, 1 Nov 2015 01:01:18 -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 9sbaZ8SIr3_h for ; Sun, 1 Nov 2015 01:01:16 -0800 (PST) Received: from filtteri5.pp.htv.fi (filtteri5.pp.htv.fi [213.243.153.188]) by ietfa.amsl.com (Postfix) with ESMTP id 7153E1B7456 for ; Sun, 1 Nov 2015 01:01:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by filtteri5.pp.htv.fi (Postfix) with ESMTP id 19EAF5A79DD; Sun, 1 Nov 2015 11:00:58 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from smtp4.welho.com ([213.243.153.38]) by localhost (filtteri5.pp.htv.fi [213.243.153.188]) (amavisd-new, port 10024) with ESMTP id GFuHciRta0vW; Sun, 1 Nov 2015 11:00:57 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp4.welho.com (Postfix) with ESMTPSA id C0B6F5BC019; Sun, 1 Nov 2015 11:01:14 +0200 (EET) Date: Sun, 1 Nov 2015 11:01:11 +0200 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20151101090111.GA13377@LK-Perkele-V2.elisa-laajakaista.fi> References: <5634A3B8.7070701@gmail.com> <20151031142945.GA12815@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Revision 10: possible attack if client authentication is allowed during PSK X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2015 09:01:18 -0000 On Sun, Nov 01, 2015 at 04:36:43AM +0900, Eric Rescorla wrote: > > I've been planning to do a big rewrite of the security "analysis" sections > and while I don't think it's worth having a real analysis in the protocol > (the literature is going to do a much better job here than we can), this > seems like exactly the kind of thing that we do want to capture to > explain the design and for future extensions. What I think is also very important with regards to security is explaining the properties of interfaces to applications. E.g. I want to be able to find answer to "Can I authenticate a client by reading value off TLS-EXTRACTOR and signing it?"[1][2] in the final RFC. Or "Can I key something non-TLS off TLS-Extractor" (yes). And with regards to protocol analysis, the thing that nails you with highest probability (after known bad ideas) is some oddball feature that nobody really analyzes (or analyzes in non-realistic ways, for this documenting assumptions at external interface is VERY useful). These often allow taking cracks in one part of the protocol and then amplifying those to actual attacks. [1] The answer being: Yes, but: - You also need ciphersuite if you need cross-collision resistance (TLS certificate auth would be vulernable to CC if another PRF- hash with 256 or 384 bit output was added). - In versions previous to TLS 1.3, you need extended_master_secret negotiated (because otherwise TLS-Extractor outputs aren't nonces). [2] While TLS does have built-in client certificate authentication, application-layer certificate authentication can be much more flexible, doing things that are just plain infeasible to do in TLS layer (like fine-grained authentication). -Ilari From nobody Sun Nov 1 01:20: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 AE9241A6F03 for ; Sun, 1 Nov 2015 01:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_22=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 F8ExFdmGnMzo for ; Sun, 1 Nov 2015 01:20:02 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0A0B1A6EF4 for ; Sun, 1 Nov 2015 01:20:01 -0800 (PST) Received: by wmff134 with SMTP id f134so39124721wmf.0 for ; Sun, 01 Nov 2015 01:20:00 -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=pF7nQlk/cD6++qCg5T38OtoSyT/IjbfQbDHSxZJvBdo=; b=A4Eam+ocNefBxHx/GmIaIl40gz1//0e3m8O8RHTCb9143HHZH0AK3p/aklrEWNchzU oVC5w4y9ddpeoO4wwkjtpDk/qQoQuL96+GtyKR/PIus1QXQgejLPYO7Sw7AgHdw9Plew dwX7qKIl7jfN6oiXI27htJu2PjK29oeTf3QkO5JF9j3noUy1Y2YPR42WhVKVlS2toZgy 80XUlboBXnzl66Kr6DzkuDRHdVcnQKtB5BFQNEfIicAzx95CCUQtGUXAKSOCSlLMJ1/6 riUhahw2vWA9NnICsz8s46vm3/MG9hsku5VG99gBw50AdzsKNKkHiZ9UGXqZ7CMdBPm0 nnlw== X-Received: by 10.28.174.130 with SMTP id x124mr7887619wme.12.1446369600153; Sun, 01 Nov 2015 01:20:00 -0800 (PST) Received: from [192.168.0.12] (89-156-8-219.rev.numericable.fr. [89.156.8.219]) by smtp.gmail.com with ESMTPSA id iw8sm16133953wjb.5.2015.11.01.01.19.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 01 Nov 2015 01:19:59 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_24AF774C-C51B-40E2-A74A-A7C47EB67057" Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Karthikeyan Bhargavan In-Reply-To: <5634A3B8.7070701@gmail.com> Date: Sun, 1 Nov 2015 10:19:58 +0100 Message-Id: References: <5634A3B8.7070701@gmail.com> To: Sam Scott X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Revision 10: possible attack if client authentication is allowed during PSK X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2015 09:20:04 -0000 --Apple-Mail=_24AF774C-C51B-40E2-A74A-A7C47EB67057 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Nice analysis! I think that the composition of different mechanisms in = the protocol is likely to be where many subtle issues lie, and analyses like this one support that = concern. Several other composition examples were already discussed on this list = (for previous drafts). For example, when composing 0-RTT with 1-RTT in the most natural way, = many attacks appeared: (1) 0-RTT application data may be replayed (See note (2) in 6.2.2.) (2) an unknown key share attack on 0-RTT encryption keys (leading to = the inclusion of ServerCertificate in 0-RTT handshake hash in 7.2.1) (3) a key compromise impersonation attack on 0-RTT (See note (3) in = 6.2.2) The addition of resumption, PSK, and client-auth provide plenty of = further composition possibilies that are (in my surely biased opinion) best handled by automated formal = analysis.=20 So, I=E2=80=99m looking forward to the full Tamarin results! Best, Karthik > On 31 Oct 2015, at 12:19, Sam Scott wrote: >=20 > Dear all, >=20 > We [1] are in the process of performing an automated symbolic analysis > of the TLS 1.3 specification draft (revision 10) using the Tamarin > prover [2], which is a tool for automated security protocol analysis. >=20 > While revision 10 does not yet appear to permit certificate-based = client > authentication in PSK (and in particular resumption using PSK), we = modelled > what we believe is the intended functionality. By enabling client > authentication either in the initial handshake, or with a post- = handshake > signature over the handshake hash, our Tamarin analysis finds an = attack. The > result is a complete breakage of client authentication, as the = attacker can > impersonate a client when communicating with a server: >=20 > Suppose a client Alice performs an initial handshake with Charlie. = Charlie, > masquerading as Alice, subsequently performs a handshake with Bob. = Following a > PSK resumption, Bob requests authentication from Charlie = (impersonating Alice). > Charlie then requests authentication from Alice, and the returned = signature > will also be a valid signature for the session with Bob. >=20 > Initial h/s Initial h/s > |<-------------->| = |<-------------->| > | exchange PSK | | exchange PSK = | > | | | = | > |Start PSK resume| |Start PSK = resume| > |--------------->| = |--------------->| > |client_random nc| |client_random = nc| > | | | = | > | Accept resume | | Accept resume = | > Alice|<---------------|(as Charlie) Charlie (as = Alice)|<---------------|Bob > |server_random ns| |server_random = ns| > | | | = | > | | | = | > |Client auth req | |Client auth req = | > |<---------------| = |<---------------| > | | | = | > | Client auth | | Client auth = | > |--------------->| = |--------------->| > sign nc,ns,... relay signature >=20 >=20 >=20 > This attack is possible because the client signature is over the = handshake > hash, which only covers the nonces and other easily duplicated = information, > and in particular does not contain the server certificate (because = none is > presented in PSK mode [3]) or the server Finished. >=20 > While the modifications proposed in PR#316 [4] explicitly allow client > authentication in these contexts, the PR also redefines the client = signature > based on a new "Handshake Context" value which includes the server = Finished > message. Intuitively, this new definition appears to address the = attack > because the attacker cannot transplant the Finished message between > connections. We are currently working towards a Tamarin proof that = PR#316 > indeed prevents our attack. >=20 > Therefore we would like to support the inclusion of Finished as > part of the handshake context, in order to address this problem. >=20 > Many thanks, >=20 > Sam Scott >=20 > [1] Cas Cremers, Marko Horvat - University of Oxford; > Thyla van der Merwe, Sam Scott - Royal Holloway, University of = London. > [2] http://www.infsec.ethz.ch/research/software/tamarin.html = > [3] Except in 0-RTT where the server's Certificate is explicitly > included. > [4] https://github.com/tlswg/tls13-spec/pull/316/ = ___________________________= ____________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_24AF774C-C51B-40E2-A74A-A7C47EB67057 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Nice analysis! I think that the composition of different = mechanisms in the protocol is likely to
be where many = subtle issues lie, and analyses like this one support that = concern.

Several= other composition examples were already discussed on this list (for = previous drafts).
For example, when composing 0-RTT = with 1-RTT in the most natural way, many attacks appeared:
   (1) 0-RTT application data  may be replayed = (See note (2) in 6.2.2.)
   (2) an = unknown key share attack on 0-RTT encryption keys (leading to the = inclusion of ServerCertificate in 0-RTT handshake hash in = 7.2.1)
   (3) a key compromise = impersonation attack on 0-RTT (See note (3) in 6.2.2)

The addition of = resumption, PSK, and client-auth provide plenty of further composition = possibilies
that are (in my surely biased opinion) = best handled by automated formal analysis. 
So, = I=E2=80=99m looking forward to the full Tamarin results!

Best,
Karthik

On = 31 Oct 2015, at 12:19, Sam Scott <sam.scott89@gmail.com> wrote:

=20 =20
Dear all,

We [1] are in the process of performing an = automated symbolic analysis
of the TLS 1.3 specification draft (revision 10) = using the Tamarin
prover [2], which is a tool for automated = security protocol analysis.

While revision 10 does not yet appear to permit certificate-based client
authentication in PSK (and in particular = resumption using PSK), we modelled
what we believe is the intended functionality. = By enabling client
authentication either in the initial handshake, = or with a post- handshake
signature over the handshake hash, our Tamarin = analysis finds an attack. The
result is a complete breakage of client = authentication, as the attacker can
impersonate a client when communicating with a = server:

Suppose a client Alice performs an initial = handshake with Charlie. Charlie,
masquerading as Alice, subsequently performs a = handshake with Bob. Following a
PSK resumption, Bob requests authentication from = Charlie (impersonating Alice).
Charlie then requests authentication from Alice, = and the returned signature
will also be a valid signature for the session = with Bob.

        = Initial = h/s            = ;            &= nbsp;           &nb= sp; Initial h/s
     = |<-------------->|        &n= bsp;           &nbs= p;          |<-------------->|
     |  exchange = PSK  = |            &= nbsp;           &nb= sp;      |  exchange PSK  |
     = |            &= nbsp;   = |            &= nbsp;           &nb= sp;      = |            &= nbsp;   |
     |Start PSK = resume|           &= nbsp;           &nb= sp;       |Start PSK resume|
     = |--------------->|         = ;            &= nbsp;         |--------------->|
     |client_random = nc|            = ;            &= nbsp;      |client_random nc|
     = |            &= nbsp;   = |            &= nbsp;           &nb= sp;      = |            &= nbsp;   |
     |  Accept resume = |            &= nbsp;           &nb= sp;      |  Accept resume |
Alice|<---------------|(as Charlie) Charlie = (as Alice)|<---------------|Bob
     |server_random = ns|            = ;            &= nbsp;      |server_random ns|
     = |            &= nbsp;   = |            &= nbsp;           &nb= sp;      = |            &= nbsp;   |
     = |            &= nbsp;   = |            &= nbsp;           &nb= sp;      = |            &= nbsp;   |
     |Client auth req = |            &= nbsp;           &nb= sp;      |Client auth req |
     = |<---------------|         = ;            &= nbsp;         |<---------------|
     = |            &= nbsp;   = |            &= nbsp;           &nb= sp;      = |            &= nbsp;   |
     |  Client = auth   = |            &= nbsp;           &nb= sp;      |  Client auth   |
     = |--------------->|         = ;            &= nbsp;         |--------------->|
       sign = nc,ns,...           = ;            &= nbsp;          relay signature



This attack is possible because the client = signature is over the handshake
hash, which only covers the nonces and other = easily duplicated information,
and in particular does not contain the server = certificate (because none is
presented in PSK mode [3]) or the server = Finished.

While the modifications proposed in PR#316 [4] = explicitly allow client
authentication in these contexts, the PR also = redefines the client signature
based on a new "Handshake Context" value which = includes the server Finished
message. Intuitively, this new definition = appears to address the attack
because the attacker cannot transplant the = Finished message between
connections. We are currently working towards a = Tamarin proof that PR#316
indeed prevents our attack.
Therefore we would like to support the inclusion = of Finished as
part of the handshake context, in order to = address this problem.

Many thanks,

Sam Scott

[1] Cas Cremers, Marko Horvat - University of = Oxford;
    Thyla van der Merwe, Sam = Scott - Royal Holloway, University of London.
[2] http://w= ww.infsec.ethz.ch/research/software/tamarin.html
[3] Except in 0-RTT where the server's = Certificate is explicitly
    included.
[4] https://github.com/= tlswg/tls13-spec/pull/316/
_______________________________________________
TLS = mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

= --Apple-Mail=_24AF774C-C51B-40E2-A74A-A7C47EB67057-- From nobody Sun Nov 1 16:48: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 445EF1B46C0 for ; Sun, 4 Oct 2015 22:52:38 -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 4IfZmicy15if for ; Sun, 4 Oct 2015 22:52:36 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89FDD1B46BE for ; Sun, 4 Oct 2015 22:52:35 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BYJ10128; Mon, 05 Oct 2015 05:52:32 +0000 (GMT) Received: from SZXEMI403-HUB.china.huawei.com (10.82.75.35) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 5 Oct 2015 06:52:30 +0100 Received: from SZXEMI501-MBX.china.huawei.com ([169.254.1.73]) by SZXEMI403-HUB.china.huawei.com ([10.83.65.55]) with mapi id 14.03.0235.001; Mon, 5 Oct 2015 13:52:18 +0800 From: Jayaraghavendran k To: "tls@ietf.org" Thread-Topic: New Version Notification for draft-jay-tls-omit-aead-explicit-nonce-extension-00.txt Thread-Index: AQHQ+s6TEpl7IcQAS0yZ088MnsrRPJ5cbTdQ Message-ID: <8D925D4C0B78EE41857D407022ECD163BFEE5505@SZXEMI501-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.213.218] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-Mailman-Approved-At: Sun, 01 Nov 2015 16:48:46 -0800 Cc: Ashutosh prakash Subject: [TLS] FW: New Version Notification for draft-jay-tls-omit-aead-explicit-nonce-extension-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: , Date: Mon, 05 Oct 2015 05:52:38 -0000 X-Original-Date: Mon, 5 Oct 2015 05:52:17 +0000 X-List-Received-Date: Mon, 05 Oct 2015 05:52:38 -0000 SGkgQWxsLA0KDQpBIG5ldyBUTFMgZXh0ZW5zaW9uIGRyYWZ0IGZvciBvbWl0dGluZyB0aGUgZXhw bGljaXQgbm9uY2UgaW5jbHVkZWQgaW4gZXZlcnkgcmVjb3JkIHdoZW4gQUVBRCBjaXBoZXJzIGFy ZSB1c2VkIGhhcyBiZWVuIHByb3Bvc2VkLiBUaGlzIGV4dGVuc2lvbiBhbGxvd3MgdGhlIENsaWVu dCBIZWxsbyAmIFNlcnZlciBIZWxsbyBtZXNzYWdlcyB0byBuZWdvdGlhdGUgYSBtZXRob2QgZm9y IGdlbmVyYXRpbmcgZXhwbGljaXQgbm9uY2UgYW5kIHRoZXJlYnkgb21pdCBpbmNsdWRpbmcgaXQg aW4gZXZlcnkgVExTL0RUTFMgcmVjb3JkLg0KDQpSZXF1ZXN0IHlvdXIgY29tbWVudHMgJiBzdWdn ZXN0aW9ucy4NCg0KVGhhbmtzIQ0KIA0KUmVnYXJkcywNCkpheQ0KDQoqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioNClRoaXMgZS1tYWlsIGFuZCBhdHRhY2htZW50cyBjb250YWluIGNvbmZp ZGVudGlhbCBpbmZvcm1hdGlvbiBmcm9tIEhVQVdFSSwgd2hpY2ggaXMgaW50ZW5kZWQgb25seSBm b3IgdGhlIHBlcnNvbiBvciBlbnRpdHkgd2hvc2UgYWRkcmVzcyBpcyBsaXN0ZWQgYWJvdmUuIEFu eSB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaW4gYW55IHdheSAoaW5j bHVkaW5nLCBidXQgbm90IGxpbWl0ZWQgdG8sIHRvdGFsIG9yIHBhcnRpYWwgZGlzY2xvc3VyZSwg cmVwcm9kdWN0aW9uLCBvciBkaXNzZW1pbmF0aW9uKSBieSBwZXJzb25zIG90aGVyIHRoYW4gdGhl IGludGVuZGVkIHJlY2lwaWVudCdzKSBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgcmVjZWl2ZSB0aGlz IGUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGJ5IHBob25lIG9yIGVt YWlsIGltbWVkaWF0ZWx5IGFuZCBkZWxldGUgaXQhDQoqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiAyOSBT ZXB0ZW1iZXIgMjAxNSAyMToxNw0KVG86IEpheWFyYWdoYXZlbmRyYW4gazsgSmF5YXJhZ2hhdmVu ZHJhbiBrOyBSYWphIGFzaG9rOyBSYWphIGFzaG9rDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3Rp ZmljYXRpb24gZm9yIGRyYWZ0LWpheS10bHMtb21pdC1hZWFkLWV4cGxpY2l0LW5vbmNlLWV4dGVu c2lvbi0wMC50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtamF5LXRscy1vbWl0 LWFlYWQtZXhwbGljaXQtbm9uY2UtZXh0ZW5zaW9uLTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1 bGx5IHN1Ym1pdHRlZCBieSBKYXlhcmFnaGF2ZW5kcmFuIEsgYW5kIHBvc3RlZCB0byB0aGUgSUVU RiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtamF5LXRscy1vbWl0LWFlYWQtZXhwbGljaXQt bm9uY2UtZXh0ZW5zaW9uDQpSZXZpc2lvbjoJMDANClRpdGxlOgkJVExTL0RUTFMgT21pdCBBRUFE IEV4cGxpY2l0IE5vbmNlIGZyb20gUmVjb3JkIEV4dGVuc2lvbg0KRG9jdW1lbnQgZGF0ZToJMjAx NS0wOS0yOQ0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJOA0KVVJMOiAg ICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1qYXkt dGxzLW9taXQtYWVhZC1leHBsaWNpdC1ub25jZS1leHRlbnNpb24tMDAudHh0DQpTdGF0dXM6ICAg ICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtamF5LXRscy1vbWl0 LWFlYWQtZXhwbGljaXQtbm9uY2UtZXh0ZW5zaW9uLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1qYXktdGxzLW9taXQtYWVhZC1leHBsaWNpdC1ub25j ZS1leHRlbnNpb24tMDANCg0KDQpBYnN0cmFjdDoNCiAgIFdpdGggZW1lcmdlbmNlIG9mIEludGVy bmV0IG9mIFRoaW5ncyhJb1QpLCBEVExTIGlzIGJlaW5nIHdpZGVseQ0KICAgY29uc2lkZXJlZCBh cyBhIHByb3RvY29sIG9mIGNob2ljZSBmb3IgY29tbXVuaWNhdGlvbiBzZWN1cml0eSBpbiBJb1QN CiAgIGFwcGxpY2F0aW9ucy4gRnVydGhlciwgQUVTX0NDTSBoYXMgZW1lcmdlZCBhcyB0aGUgY2lw aGVyIG9mIGNob2ljZSBpbg0KICAgY29uc3RyYWluZWQgZW52aXJvbm1lbnRzLiBDb25zdHJhaW5l ZCBBcHBsaWNhdGlvbiBQcm90b2NvbCAoQ29BUCksDQogICB3aGljaCBpcyB0aGUgYXBwbGljYXRp b24gbGF5ZXIgcHJvdG9jb2wgZm9yIHJlc291cmNlIGNvbnN0cmFpbmVkDQogICBlbnZpcm9ubWVu dHMsIG1hbmRhdGVzIERUTFMgYXMgdW5kZXJseWluZyBzZWN1cml0eSBwcm90b2NvbCBhbmQNCiAg IHByb3Bvc2VzIEFFU19DQ00gYmFzZWQgY2lwaGVycyB0byBiZSB1c2VkIHdpdGggZGlmZmVyZW50 IGtleSBleGNoYW5nZQ0KICAgbWV0aG9kcy4gQUVBRCBjaXBoZXJzIHJlcXVpcmVzIGFuIGV4cGxp Y2l0IG5vbmNlIG9mIDggYnl0ZXMgbXVzdCBiZQ0KICAgY2FycmllZCBpbiBlYWNoIHRyYW5zbWl0 dGVkIHJlY29yZC5UaGlzIGRvY3VtZW50IGRlZmluZXMgYSBUTFMgKGFuZA0KICAgRFRMUykgZXh0 ZW5zaW9uLCB3aGljaCB3aWxsIGFsbG93IGNsaWVudHMgYW5kIHNlcnZlcnMgdG8gb21pdCB0aGUN CiAgIGV4cGxpY2l0IG5vbmNlIHNlbnQgaW4gVExTL0RUTFMgcmVjb3Jkcy4gIFRoaXMgZG9jdW1l bnQgY2FuIGJlDQogICBjb25zaWRlcmVkIGFzIGFuIGV4dGVuZGVkIHZlcnNpb24gb2YgIlRyYW5z cG9ydCBMYXllciBTZWN1cml0eSAoVExTKQ0KICAgRXh0ZW5zaW9ucyA6IEV4dGVuc2lvbiBEZWZp bml0aW9ucyIuIFRoZSBleHRlbnNpb24gZGVmaW5lZCBpbiB0aGlzDQogICBkb2N1bWVudCBhcHBs eSBlcXVhbGx5IHRvIGJvdGggRFRMUyBhbmQgVExTIHByb3RvY29scy4NCg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUg b2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVk IHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhl IElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Sun Nov 1 16: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 BE3911B3E17 for ; Mon, 26 Oct 2015 06:23:37 -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, HTML_MESSAGE=0.001, 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 TGpYBS1dWQZ6 for ; Mon, 26 Oct 2015 06:23:34 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF8C91B3E16 for ; Mon, 26 Oct 2015 06:23:33 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CDA81381; Mon, 26 Oct 2015 13:23:31 +0000 (GMT) Received: from SZXEMI401-HUB.china.huawei.com (10.82.75.33) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 26 Oct 2015 13:23:28 +0000 Received: from SZXEMI501-MBX.china.huawei.com ([169.254.1.73]) by SZXEMI401-HUB.china.huawei.com ([10.82.75.33]) with mapi id 14.03.0235.001; Mon, 26 Oct 2015 21:23:22 +0800 From: Jayaraghavendran k To: Eric Rescorla , "tls@ietf.org" , "draft-jay-tls-omit-aead-explicit-nonce-extension@tools.ietf.org" Thread-Topic: [TLS] draft-jay-tls-omit-aead-explicit-nonce-extension Thread-Index: AQHRDc4xC8umvb5us06ZJNAT+adNe559uDng Date: Mon, 26 Oct 2015 13:23:21 +0000 Message-ID: <8D925D4C0B78EE41857D407022ECD163BFEE877C@SZXEMI501-MBX.china.huawei.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.213.218] Content-Type: multipart/alternative; boundary="_000_8D925D4C0B78EE41857D407022ECD163BFEE877CSZXEMI501MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-Mailman-Approved-At: Sun, 01 Nov 2015 16:48:46 -0800 Subject: Re: [TLS] draft-jay-tls-omit-aead-explicit-nonce-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2015 13:23:37 -0000 --_000_8D925D4C0B78EE41857D407022ECD163BFEE877CSZXEMI501MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRXJpYywNCg0KVGhhbmtzIGZvciB5b3VyIHJlc3BvbnNlLg0KDQoxLiBUaGVyZSBpcyBhbHJl YWR5IG5vIHJlcXVpcmVtZW50IHRoYXQgeW91IGhhdmUgYW4gZXhwbGljaXQgbm9uY2UuIFJGQzUy NDYNCm1lcmVseSByZXF1aXJlcyB0aGF0IHlvdSBzcGVjaWZ5IHRoZSBsZW5ndGggb2YgdGhlIGV4 cGxpY2l0IG5vbmNlLCBidXQgdGhhdA0KbGVuZ3RoIGNhbiBiZSAwLCBhcyBpdCBpcyBpbiB0aGUg Q2hhQ2hhL1BvbHkgZHJhZnRzLiBTbywgcmF0aGVyIHRoYW4gYnVpbGQNCmFuIGV4dGVuc2lvbiBp dCB3b3VsZCBiZSBiZXR0ZXIgdG8ganVzdCBkZWZpbmUgYSBuZXcgY2lwaGVyIHN1aXRlIGlmIHlv dSB0aGluaw0KdGhpcyBpcyBpbXBvcnRhbnQuDQpbSmF5XTogVGhlIGV4dGVuc2lvbiBpZGVhIHdh cyBtYWlubHkgZm9yIHRoZSBhbHJlYWR5IGRlZmluZWQgY2lwaGVycyBpbiBSRkMgNjY1NSAoZm9y IEFFU19DQ00gdXNhZ2UgaW4gVExTKSAmIFJGQyA1Mjg4IChmb3IgQUVTX0dDTSB1c2FnZSBpbiBU TFMpLiBCb3RoIHRoZXNlIFJGQ3Mgc3RhdGUgdGhhdCBhbiBleHBsaWNpdCBub25jZSBvZiA4IGJ5 dGVzIE1VU1QgYmUgY2FycmllZCBpbiBlYWNoIHJlY29yZC4gU28sIGluIHRoZXNlIGNhc2VzIHRv IGF2b2lkIHRoZSBvdmVyaGVhZCwgdGhlIG9wdGlvbnMgYXMgSSB1bmRlcnN0YW5kIGFyZSBkZWZp bmluZyBhIG5ldyBleHRlbnNpb24gb3IgYSBuZXcgY2lwaGVyIHN1aXRlICh3aGljaCBzdWdnZXN0 cyB0aGUgbmV3IGV4cGxpY2l0IG5vbmNlIGdlbmVyYXRpb24gbWVjaGFuaXNtIGFuZCBtYWtlcyB0 aGUgcmVjb3JkIGl2IGxlbmd0aCBhcyAwKS4NCg0KVGhpcyBuZXcgZXh0ZW5zaW9uIGlzIG1vcmUg bGlrZSBhIGZyYW1ld29yayBmb3IgbmVnb3RpYXRpbmcgdGhlIHR5cGUgb2YgZXhwbGljaXQgbm9u Y2UgZ2VuZXJhdGlvbiBtZWNoYW5pc21zLiBJZiBhIHBhcnRpY3VsYXIgd2F5IG9mIGdlbmVyYXRp bmcgdGhlIGV4cGxpY2l0IG5vbmNlIGlzIGZvdW5kIHRvIGJlIGV4cGxvaXRhYmxlIGluIGZ1dHVy ZSwgYSBuZXcgbWVjaGFuaXNtIGNhbiBiZSBkZWZpbmVkIGFuZCBuZWdvdGlhdGVkIHRocm91Z2gg dGhlIGV4dGVuc2lvbi4gIERlZmluaW5nICBhIG5ldyBjaXBoZXIgZm9yIGVhY2ggbmV3IG1lY2hh bmlzbSBvZiBleHBsaWNpdCBub25jZSBnZW5lcmF0aW9uIG1heSBpbmNyZWFzZSB0aGUgbnVtYmVy IG9mIGNpcGhlcnMgdGhhdCB0aGUgY2xpZW50IGhhcyB0byBjYXJyeSBpbiBpdOKAmXMgY2xpZW50 IGhlbGxvIGJ5IGEgZ29vZCBhbW91bnQgKGNvbnNpZGVyaW5nLCBpdCBuZWVkcyB0byBjYXJyeSBv bGQgY2lwaGVycyBhbHNvIGZvciBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IHdpdGggc2VydmVycyBu b3Qgc3VwcG9ydGluZyBuZXcgY2lwaGVycykuDQoNCg0KMi4gVExTIDEuMyBhbHJlYWR5IG9taXRz IHRoZSBleHBsaWNpdCBub25jZSBlbnRpcmVseS4NCltKYXldOiAgTXkgcHJpbWFyeSBnb2FsIGlz IGZvciBEVExTIDEuMiB3aGljaCBpcyB1c2VkIHdpdGggQ29BUCBpbiB2YXJpb3VzIElvVCBTY2Vu YXJpb3MuIFVzYWdlIG9mIERUTFMgMS4yIHdpdGggQ29BUCBoYXMgYWxyZWFkeSBzdGFydGVkIGlu IG1hbnkgcHJvZHVjdHMgSSBiZWxpZXZlIGFuZCBEVExTIDEuMyBtYXkgdGFrZSBzb21lIHRpbWUg YW5kIHdpbGwgbm90IGJlIGltbWVkaWF0ZWx5IGFkYXB0ZWQgYnkgcHJvZHVjdHMgYWxyZWFkeSBy ZWxlYXNlZC4NCg0KUmVxdWVzdGluZyB5b3VyIHN1Z2dlc3Rpb25zIGluIHRoZSBhYm92ZSBjb250 ZXh0Lg0KDQpUaGFua3MgQWdhaW4uDQoNCkJlc3QgUmVnYXJkcywNCkpheQ0KKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqDQpUaGlzIGUtbWFpbCBhbmQgYXR0YWNobWVudHMgY29udGFpbiBj b25maWRlbnRpYWwgaW5mb3JtYXRpb24gZnJvbSBIVUFXRUksIHdoaWNoIGlzIGludGVuZGVkIG9u bHkgZm9yIHRoZSBwZXJzb24gb3IgZW50aXR5IHdob3NlIGFkZHJlc3MgaXMgbGlzdGVkIGFib3Zl LiBBbnkgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGluIGFueSB3YXkg KGluY2x1ZGluZywgYnV0IG5vdCBsaW1pdGVkIHRvLCB0b3RhbCBvciBwYXJ0aWFsIGRpc2Nsb3N1 cmUsIHJlcHJvZHVjdGlvbiwgb3IgZGlzc2VtaW5hdGlvbikgYnkgcGVyc29ucyBvdGhlciB0aGFu IHRoZSBpbnRlbmRlZCByZWNpcGllbnQncykgaXMgcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmUg dGhpcyBlLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBieSBwaG9uZSBv ciBlbWFpbCBpbW1lZGlhdGVseSBhbmQgZGVsZXRlIGl0IQ0KKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqDQoNCkZyb206IFRMUyBbbWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgRXJpYyBSZXNjb3JsYQ0KU2VudDogMjQgT2N0b2JlciAyMDE1IDAxOjM1DQpUbzog dGxzQGlldGYub3JnOyBkcmFmdC1qYXktdGxzLW9taXQtYWVhZC1leHBsaWNpdC1ub25jZS1leHRl bnNpb25AdG9vbHMuaWV0Zi5vcmcNClN1YmplY3Q6IFtUTFNdIGRyYWZ0LWpheS10bHMtb21pdC1h ZWFkLWV4cGxpY2l0LW5vbmNlLWV4dGVuc2lvbg0KDQpJIHRvb2sgYSBxdWljayBsb29rIGF0IHRo aXMgZHJhZnQgYW5kIElNTyBpdCBpcyB1bm5lY2Vzc2FyeSwgZm9yIHR3byByZWFzb25zOg0KDQox LiBUaGVyZSBpcyBhbHJlYWR5IG5vIHJlcXVpcmVtZW50IHRoYXQgeW91IGhhdmUgYW4gZXhwbGlj aXQgbm9uY2UuIFJGQzUyNDYNCm1lcmVseSByZXF1aXJlcyB0aGF0IHlvdSBzcGVjaWZ5IHRoZSBs ZW5ndGggb2YgdGhlIGV4cGxpY2l0IG5vbmNlLCBidXQgdGhhdA0KbGVuZ3RoIGNhbiBiZSAwLCBh cyBpdCBpcyBpbiB0aGUgQ2hhQ2hhL1BvbHkgZHJhZnRzLiBTbywgcmF0aGVyIHRoYW4gYnVpbGQN CmFuIGV4dGVuc2lvbiBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8ganVzdCBkZWZpbmUgYSBuZXcgY2lw aGVyIHN1aXRlIGlmIHlvdSB0aGluaw0KdGhpcyBpcyBpbXBvcnRhbnQuDQoNCjIuIFRMUyAxLjMg YWxyZWFkeSBvbWl0cyB0aGUgZXhwbGljaXQgbm9uY2UgZW50aXJlbHkuDQoNCi1Fa3INCg0KDQoN Cg== --_000_8D925D4C0B78EE41857D407022ECD163BFEE877CSZXEMI501MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJn aW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5I aSBFcmljLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIGZvciB5b3VyIHJlc3BvbnNlLg0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjEuIFRoZXJlIGlzIGFscmVhZHkgbm8gcmVxdWlyZW1lbnQgdGhhdCB5b3Ug aGF2ZSBhbiBleHBsaWNpdCBub25jZS4gUkZDNTI0NjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+bWVyZWx5IHJlcXVpcmVzIHRoYXQgeW91IHNwZWNpZnkgdGhlIGxlbmd0aCBv ZiB0aGUgZXhwbGljaXQgbm9uY2UsIGJ1dCB0aGF0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5sZW5ndGggY2FuIGJlIDAsIGFzIGl0IGlzIGluIHRoZSBDaGFDaGEvUG9seSBk cmFmdHMuIFNvLCByYXRoZXIgdGhhbiBidWlsZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+YW4gZXh0ZW5zaW9uIGl0IHdvdWxkIGJlIGJldHRlciB0byBqdXN0IGRlZmluZSBh IG5ldyBjaXBoZXIgc3VpdGUgaWYgeW91IHRoaW5rPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj50aGlzIGlzIGltcG9ydGFudC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bSmF5 XTogVGhlIGV4dGVuc2lvbiBpZGVhIHdhcyBtYWlubHkgZm9yIHRoZSBhbHJlYWR5IGRlZmluZWQg Y2lwaGVycyBpbiBSRkMgNjY1NSAoZm9yIEFFU19DQ00gdXNhZ2UgaW4gVExTKSAmYW1wOyBSRkMg NTI4OCAoZm9yIEFFU19HQ00gdXNhZ2UgaW4gVExTKS4gQm90aCB0aGVzZQ0KIFJGQ3Mgc3RhdGUg dGhhdCBhbiBleHBsaWNpdCBub25jZSBvZiA4IGJ5dGVzIE1VU1QgYmUgY2FycmllZCBpbiBlYWNo IHJlY29yZC4gU28sIGluIHRoZXNlIGNhc2VzIHRvIGF2b2lkIHRoZSBvdmVyaGVhZCwgdGhlIG9w dGlvbnMgYXMgSSB1bmRlcnN0YW5kIGFyZSBkZWZpbmluZyBhIG5ldyBleHRlbnNpb24gb3IgYSBu ZXcgY2lwaGVyIHN1aXRlICh3aGljaCBzdWdnZXN0cyB0aGUgbmV3IGV4cGxpY2l0IG5vbmNlIGdl bmVyYXRpb24gbWVjaGFuaXNtDQogYW5kIG1ha2VzIHRoZSByZWNvcmQgaXYgbGVuZ3RoIGFzIDAp LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+VGhpcyBuZXcgZXh0ZW5zaW9uIGlzIG1vcmUgbGlrZSBhIGZyYW1ld29yayBm b3IgbmVnb3RpYXRpbmcgdGhlIHR5cGUgb2YgZXhwbGljaXQgbm9uY2UgZ2VuZXJhdGlvbiBtZWNo YW5pc21zLiBJZiBhIHBhcnRpY3VsYXIgd2F5IG9mIGdlbmVyYXRpbmcgdGhlIGV4cGxpY2l0DQog bm9uY2UgaXMgZm91bmQgdG8gYmUgZXhwbG9pdGFibGUgaW4gZnV0dXJlLCBhIG5ldyBtZWNoYW5p c20gY2FuIGJlIGRlZmluZWQgYW5kIG5lZ290aWF0ZWQgdGhyb3VnaCB0aGUgZXh0ZW5zaW9uLiAm bmJzcDtEZWZpbmluZyZuYnNwOyBhIG5ldyBjaXBoZXIgZm9yIGVhY2ggbmV3IG1lY2hhbmlzbSBv ZiBleHBsaWNpdCBub25jZSBnZW5lcmF0aW9uIG1heSBpbmNyZWFzZSB0aGUgbnVtYmVyIG9mIGNp cGhlcnMgdGhhdCB0aGUgY2xpZW50IGhhcyB0byBjYXJyeSBpbg0KIGl04oCZcyBjbGllbnQgaGVs bG8gYnkgYSBnb29kIGFtb3VudCAoY29uc2lkZXJpbmcsIGl0IG5lZWRzIHRvIGNhcnJ5IG9sZCBj aXBoZXJzIGFsc28gZm9yIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgd2l0aCBzZXJ2ZXJzIG5vdCBz dXBwb3J0aW5nIG5ldyBjaXBoZXJzKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Mi4gVExTIDEuMyBhbHJl YWR5IG9taXRzIHRoZSBleHBsaWNpdCBub25jZSBlbnRpcmVseS48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltK YXldOiAmbmJzcDtNeSBwcmltYXJ5IGdvYWwgaXMgZm9yIERUTFMgMS4yIHdoaWNoIGlzIHVzZWQg d2l0aCBDb0FQIGluIHZhcmlvdXMgSW9UIFNjZW5hcmlvcy4gVXNhZ2Ugb2YgRFRMUyAxLjIgd2l0 aCBDb0FQIGhhcyBhbHJlYWR5IHN0YXJ0ZWQgaW4gbWFueSBwcm9kdWN0cyBJDQogYmVsaWV2ZSBh bmQgRFRMUyAxLjMgbWF5IHRha2Ugc29tZSB0aW1lIGFuZCB3aWxsIG5vdCBiZSBpbW1lZGlhdGVs eSBhZGFwdGVkIGJ5IHByb2R1Y3RzIGFscmVhZHkgcmVsZWFzZWQuDQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlcXVl c3RpbmcgeW91ciBzdWdnZXN0aW9ucyBpbiB0aGUgYWJvdmUgY29udGV4dC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRo YW5rcyBBZ2Fpbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJlc3QgUmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+SmF5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4qKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKio8YnI+DQpUaGlzIGUtbWFpbCBhbmQgYXR0YWNobWVudHMgY29udGFpbiBj b25maWRlbnRpYWwgaW5mb3JtYXRpb24gZnJvbSBIVUFXRUksIHdoaWNoIGlzIGludGVuZGVkIG9u bHkgZm9yIHRoZSBwZXJzb24gb3IgZW50aXR5IHdob3NlIGFkZHJlc3MgaXMgbGlzdGVkIGFib3Zl LiBBbnkgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGluIGFueSB3YXkg KGluY2x1ZGluZywgYnV0IG5vdCBsaW1pdGVkIHRvLCB0b3RhbCBvciBwYXJ0aWFsDQogZGlzY2xv c3VyZSwgcmVwcm9kdWN0aW9uLCBvciBkaXNzZW1pbmF0aW9uKSBieSBwZXJzb25zIG90aGVyIHRo YW4gdGhlIGludGVuZGVkIHJlY2lwaWVudCdzKSBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgcmVjZWl2 ZSB0aGlzIGUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGJ5IHBob25l IG9yIGVtYWlsIGltbWVkaWF0ZWx5IGFuZCBkZWxldGUgaXQhPGJyPg0KKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFRMUyBbbWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnXQ0K PGI+T24gQmVoYWxmIE9mIDwvYj5FcmljIFJlc2NvcmxhPGJyPg0KPGI+U2VudDo8L2I+IDI0IE9j dG9iZXIgMjAxNSAwMTozNTxicj4NCjxiPlRvOjwvYj4gdGxzQGlldGYub3JnOyBkcmFmdC1qYXkt dGxzLW9taXQtYWVhZC1leHBsaWNpdC1ub25jZS1leHRlbnNpb25AdG9vbHMuaWV0Zi5vcmc8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gW1RMU10gZHJhZnQtamF5LXRscy1vbWl0LWFlYWQtZXhwbGljaXQt bm9uY2UtZXh0ZW5zaW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JIHRvb2sgYSBxdWljayBsb29rIGF0IHRoaXMgZHJhZnQgYW5kIElNTyBpdCBpcyB1bm5l Y2Vzc2FyeSwgZm9yIHR3byByZWFzb25zOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+MS4gVGhlcmUgaXMgYWxyZWFkeSBubyByZXF1aXJlbWVudCB0aGF0IHlv dSBoYXZlIGFuIGV4cGxpY2l0IG5vbmNlLiBSRkM1MjQ2PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5tZXJlbHkgcmVxdWlyZXMgdGhhdCB5b3Ugc3Bl Y2lmeSB0aGUgbGVuZ3RoIG9mIHRoZSBleHBsaWNpdCBub25jZSwgYnV0IHRoYXQ8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmxlbmd0aCBjYW4gYmUg MCwgYXMgaXQgaXMgaW4gdGhlIENoYUNoYS9Qb2x5IGRyYWZ0cy4gU28sIHJhdGhlciB0aGFuIGJ1 aWxkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5h biBleHRlbnNpb24gaXQgd291bGQgYmUgYmV0dGVyIHRvIGp1c3QgZGVmaW5lIGEgbmV3IGNpcGhl ciBzdWl0ZSBpZiB5b3UgdGhpbms8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPnRoaXMgaXMgaW1wb3J0YW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yLiBUTFMgMS4zIGFscmVhZHkgb21pdHMg dGhlIGV4cGxpY2l0IG5vbmNlIGVudGlyZWx5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tRWtyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_8D925D4C0B78EE41857D407022ECD163BFEE877CSZXEMI501MBXchi_-- From nobody Sun Nov 1 16:49: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 A78541B3983 for ; Thu, 22 Oct 2015 09:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9ij4kNcqnZ8 for ; Thu, 22 Oct 2015 09:09:19 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C650E1B3982 for ; Thu, 22 Oct 2015 09:09:18 -0700 (PDT) Received: by vkgy127 with SMTP id y127so49572815vkg.0 for ; Thu, 22 Oct 2015 09:09:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=fy6Ri74oVblUO0lm26KnSdVYXcHO07S+4NknTJHW8k4=; b=MXY52E424BnV19MnMZ4xrbLZ5luQOpl4ZM8qO+irj2i/dPuwboGr927Li+YUwVP1dm X+FuyHZ3qhCTyfTA2DE8DV47lJlessTFSCdATA4RSQTher4ZKSWmVq35xeKVlbrPdENC 3wpiBs14gFhKSjrFWtcW17RYgc3Ns4OV+dgsj8Q8QtRz5Rf0uI8cAlGC8zeTx3hkSZc6 +1au0NtetWdYKZLsA3gC7RdXuhrTMyo10v7MNdl+5KPfhf1Lppgsnen+rU0PlvZXW8P4 /JHxizeXeSuLLPduJxez6M6TVzq4LJ4l9DH3RfZVYyRQ+m/eJgIBFpa+d3Le0OCz8rFa VeQw== 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=fy6Ri74oVblUO0lm26KnSdVYXcHO07S+4NknTJHW8k4=; b=NBRnW2WrL+hnNqXa/UF5dgAoqwCRALoeN7udAHJyr64lVklXhZnjfdJhwLT9AdrfJ5 ONRIL6kBpr2/dfL7L1p7O4MtXtM1TM8BCnX/+EV+ZHt5FFEFzPrr1vs3Wevvraq8MXqQ IdBNdrz8KISPiKgSnXkS2a2Nf57Sy5Z2pQMDTSuoS0+vDjroiS4lEkyxCyx0Pc6JvYJj cQvJ8SP+JNK9oN9hJga3LyiVOSB+bJesnC46Lg3D9UP3CKiLwqRqQzapOZ6d418Qkps5 DZ54qw/5BK0y7o6JGj3l0RfBlJTZ/ThUMzJgGTxEnh68N/vhgPt8eotDzuCV4J40ADGR SOug== X-Gm-Message-State: ALoCoQk8ozYf4vHnX25CQ1Jpi+8IsEImMIm5bbTxZIHTQIChe2g1Lq4v6bS+khEROPkPVdICj8z7 X-Received: by 10.31.159.208 with SMTP id i199mr10436356vke.74.1445530157898; Thu, 22 Oct 2015 09:09:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.191.70 with HTTP; Thu, 22 Oct 2015 09:08:58 -0700 (PDT) In-Reply-To: <201510212017.31856.davemgarrett@gmail.com> References: <20151021204320.0CECD18046A@rfc-editor.org> <201510212017.31856.davemgarrett@gmail.com> From: Adam Langley Date: Thu, 22 Oct 2015 09:08:58 -0700 Message-ID: To: Dave Garrett Content-Type: text/plain; charset=UTF-8 Archived-At: X-Mailman-Approved-At: Sun, 01 Nov 2015 16:49:05 -0800 Cc: "tls@ietf.org" Subject: Re: [TLS] RFC 7685 on A Transport Layer Security (TLS) ClientHello Padding Extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 16:09:19 -0000 On Wed, Oct 21, 2015 at 5:17 PM, Dave Garrett wrote: > Congrats on releasing an RFC that has day one 100% server support. :p Thanks. It's the way I think RFCs should be :) Cheers AGL From nobody Sun Nov 1 16:49: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 A45A31B2F35 for ; Thu, 15 Oct 2015 09:28:01 -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 qiQZqCWPJ0ZR for ; Thu, 15 Oct 2015 09:27:59 -0700 (PDT) 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 C64841ACEAA for ; Thu, 15 Oct 2015 09:27:37 -0700 (PDT) Received: by lbwr8 with SMTP id r8so75302173lbw.2 for ; Thu, 15 Oct 2015 09:27:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=TP6v3/e+2SPfukxlmXPBGdC4Ysf1S1+INmmd6jw4U6Y=; b=NngxjpZ0O5ZXhA/W11DjrP42vyKPljZ9tgj+HrjKsfoHpczBpQHu+HZzF3fvm5sYP8 IXvJTAbDzO/meqgIWJOcCn837R6oj6LIid+CHW0cjXrELsS180sAEtEpLDn3amiUZ/Ry acT2xMb+gz4ML5PnpCfT55W/FGUo0PdfA4s64Nsf9GA/J2yMK8p8rEJjTQdGlRZm4izr HSkDodE9WeJrK/fRvonemNV32veDVyaDZPFoq3vMM7pri4h7PcRjsD3UQpwydWTUhG/n qFCWe2UDmT0qACJ28rOUF82PgoIC9twE41FyNxMB9oDo5FsYSaWgtKKjbJxY6BhjCCTM XSXQ== MIME-Version: 1.0 X-Received: by 10.112.53.131 with SMTP id b3mr5259521lbp.55.1444926455521; Thu, 15 Oct 2015 09:27:35 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.213.75 with HTTP; Thu, 15 Oct 2015 09:27:35 -0700 (PDT) In-Reply-To: References: <87fv1fal6s.fsf@latte.josefsson.org> X-Google-Sender-Auth: lnDt1tonREgx7yuGzOxcYTFlAis Message-ID: From: Phillip Hallam-Baker To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11c3e9ac1ba91e052227284f Archived-At: X-Mailman-Approved-At: Sun, 01 Nov 2015 16:49:51 -0800 Subject: [TLS] Fwd: [pkix] Updated elliptic curve drafts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Thu, 15 Oct 2015 16:28:01 -0000 X-Original-Date: Thu, 15 Oct 2015 12:27:35 -0400 X-List-Received-Date: Thu, 15 Oct 2015 16:28:01 -0000 --001a11c3e9ac1ba91e052227284f Content-Type: text/plain; charset=UTF-8 I strongly oppose any new crypto that does not include a fix for the ephemeral keygen. The reason logjam is possible is that the key negotiation is essentially 1) Negotiate a shared secret S1 using the strong, long term server key. 2) Use the shared secret to authenticate ephemeral key parameters Ec, Es 3) Derive the session keys S2 from the ephemeral key parameters only and throw away the output from the strong long term keys. It is not just 512 bit keys that are vulnerable. 1024 bit DH keys are also weak: https://freedom-to-tinker.com/blog/haldermanheninger/how-is-nsa-breaking-so-much-crypto/ If we are changing the crypto suites we can and should fix this instead of S2 being a function of Ec, Es alone, add in the original S1 as a salt. e.g. S2 = SHA512 (S1 + f(Ec, Es)) This ensures that no matter how broken the ephemeral crypto is, the key exchange is always at least as secure as either the long term or the ephemeral key. Logjam isn't the only way that the system can be compromised. Oh and damn right I think BULLRUN might have had a part in keeping the spec broken. There is a right way to design an ephemeral key exchange and it is to 'Do no harm'. Logjam shows that our current key negotiation mechanism has a hole that makes it possible for the ephemeral to do harm. The move to the CFRG curves will mean a backwards incompatible change to the deployed infrastructure so this is a perfect time to fix ephemeral key establishment. I am going to keep raising this until the issue is fixed. On Mon, Oct 12, 2015 at 4:25 PM, Simon Josefsson wrote: > Hi, > > I've updated my drafts on Curve25519/Curve448 support in PKIX to refer > to the CFRG-Curves and CFRG-EdDSA drafts. > > The following document adds new EdDSA key/signature OIDs directly: > > https://tools.ietf.org/html/draft-josefsson-pkix-eddsa-04 > > The following document adds new namedCurve OIDs, thus going indirectly > through the existing ECDSA 3279 route: > > https://tools.ietf.org/html/draft-josefsson-pkix-newcurves-01 > > These two drafts take different approaches to including the new curves > into PKIX, and currently both lack applicability statements. There is > potential for overlap and conflict right now. It recently came up that > for PKCS#11 a namedCurve approach would be useful, but for normal PKIX > Certificates, it may be that the first direct approach is preferrable. > The former lack the possibility of encoding keys for DH. I believe each > approach can be useful on its own, but we need to include text adressing > use-cases that can be resolved by both documents to avoid conflicts. > > /Simon > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > --001a11c3e9ac1ba91e052227284f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I strongly oppose any new c= rypto that does not include a fix for the
ephemeral keygen.

The reason logjam is possible is that the key negotiation is essentially
1) Negotiate a shared secret S1 using the strong, long term server key.
2) Use the shared secret to authenticate ephemeral key parameters Ec, Es 3) Derive the session keys S2 from the ephemeral key parameters only
and throw away the output from the strong long term keys.

It is not just 512 bit keys that are vulnerable. 1024 bit DH keys are also = weak:
https://free= dom-to-tinker.com/blog/haldermanheninger/how-is-nsa-breaking-so-much-crypto= /

If we are changing the crypto suites we can and should fix this
instead of S2 being a function of Ec, Es alone, add in the original S1
as a salt.=C2=A0 e.g. S2 =3D SHA512 (S1 + f(Ec, Es))

This ensures that no matter how broken the ephemeral crypto is, the
key exchange is always at least as secure as either the long term or
the ephemeral key.


Logjam isn't the only way that the system can be compromised.

Oh and damn right I think BULLRUN might have had a part in keeping the
spec broken.


There is a right way to design an ephemeral key exchange and it is to
'Do no harm'. Logjam shows that our current key negotiation mechani= sm
has a hole that makes it possible for the ephemeral to do harm.

The move to the CFRG curves will mean a backwards incompatible change
to the deployed infrastructure so this is a perfect time to fix
ephemeral key establishment.

I am going to keep raising this until the issue is fixed.



On Mon, Oct 12, 2015 at 4:25 PM, Simon Josefsson <simon@josefsson.org> wrote:
> Hi,
>
> I've updated my drafts on Curve25519/Curve448 support in PKIX to r= efer
> to the CFRG-Curves and CFRG-EdDSA drafts.
>
> The following document adds new EdDSA key/signature OIDs directly:
>
> https://tools.ietf.org/html/draft-jose= fsson-pkix-eddsa-04
>
> The following document adds new namedCurve OIDs, thus going indirectly=
> through the existing ECDSA 3279 route:
>
> https://tools.ietf.org/html/draft-= josefsson-pkix-newcurves-01
>
> These two drafts take different approaches to including the new curves=
> into PKIX, and currently both lack applicability statements.=C2=A0 The= re is
> potential for overlap and conflict right now.=C2=A0 It recently came u= p that
> for PKCS#11 a namedCurve approach would be useful, but for normal PKIX=
> Certificates, it may be that the first direct approach is preferrable.=
> The former lack the possibility of encoding keys for DH.=C2=A0 I belie= ve each
> approach can be useful on its own, but we need to include text adressi= ng
> use-cases that can be resolved by both documents to avoid conflicts. >
> /Simon
>
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix
>

--001a11c3e9ac1ba91e052227284f-- From nobody Sun Nov 1 16: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 C788E1A86F1 for ; Mon, 19 Oct 2015 01:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 TPHzcO7WzUtD for ; Mon, 19 Oct 2015 01:36:33 -0700 (PDT) Received: from lb3-smtp-cloud3.xs4all.net (lb3-smtp-cloud3.xs4all.net [194.109.24.30]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50C591A7028 for ; Mon, 19 Oct 2015 01:36:32 -0700 (PDT) Received: from airhead.local ([83.161.146.46]) by smtp-cloud3.xs4all.net with ESMTP id WwcU1r00D10HQrX01wcVR5; Mon, 19 Oct 2015 10:36:30 +0200 Message-ID: <5624AB8B.4050802@openfortress.nl> Date: Mon, 19 Oct 2015 10:36:27 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: " \" References: <56212653.6050702@openfortress.nl> <1177744771.34157013.1445030003104.JavaMail.zimbra@redhat.com> <56216D37.1050701@akamai.com> <5621EF30.8040300@openfortress.nl> <5622857D.90304@akamai.com> <5623528B.7000302@openfortress.nl> In-Reply-To: <5623528B.7000302@openfortress.nl> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Sun, 01 Nov 2015 16:50:02 -0800 Subject: Re: [TLS] Design Alternatives for Kerberos + DH X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 08:36:35 -0000 Hello Benjamin, > No, mutual authentication requires the client to receive a message from > the server. Yes, I know -- the server needs to handle the session key or the subkey to prove posession of its KDC-stored service key. By using it, the client can be convinced or server identity. > This could be implicit I think it automatically is with TLS, since the Finished messages won't succeed until both parties have derived the same master secret, which if it involves the session key or subkey proves the server's identity in an implicit manner. I do believe a long-enough Finished message is required though. For the TLS_ECDHE_KRB_ CipherSuites I've proposed a verify_data_lenth to match the required certainty from the message; if we mix Kerberos client "certificates" info other CipherSuites like TLS_ECDHE_RSA_ then a client SHOULD negotiate a high-enough value and the server MUST support that. It requires TLS 1.2 to do these things. -Rick From scott@paragonie.com Thu Oct 8 19:10: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 381001A877F for ; Thu, 8 Oct 2015 19:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.522 X-Spam-Level: X-Spam-Status: No, score=0.522 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_71=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5y1WLRXooBU for ; Thu, 8 Oct 2015 19:10:54 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.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 B81FC1A8773 for ; Thu, 8 Oct 2015 19:10:53 -0700 (PDT) Received: by lbbwt4 with SMTP id wt4so66080004lbb.1 for ; Thu, 08 Oct 2015 19:10:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=OXZwG0EBIV1vTMufX0DDYs9AkmkbdUn+1ZdmSK3d8lk=; b=W/5Hwr43p0o+6B+8OsEcWz8Ma5HTfMukVRdLg3nMr+jvmKBDMp60Toeq7zCApo4H8B bf4ztA2sq/IRvIvLdp/VjTXpQgfvE9MRyxVGskTSCoCZaMzF6o6+PGTA+FTMW5M1I66u SYfxcCAB0C4hyQwIQpLanApg9i7TRMJIq5UPQOY1ZKDUsnZ5JGP+r+yz47vh7tBIFwQ4 KhNry9jtn6Bnscp57WPxqUpxfBatG3xFWW5QnV7Maqavj7vK5Pj31n02nuW0nXNBX7mi 3Ccd/FbkW+3VIVYIuUtjG9LLIleKTluF/WMah8jUWsRtqlNGKODcjkEa5ibmqUE+5bP1 GI/Q== X-Gm-Message-State: ALoCoQmPVdF0ypxKURB/EREHF9ABS2PVkpDLDLQak8o9fCCydtuqwWriF6KKnVxmrqtPuYl7bjFL MIME-Version: 1.0 X-Received: by 10.112.200.202 with SMTP id ju10mr5090387lbc.97.1444356651851; Thu, 08 Oct 2015 19:10:51 -0700 (PDT) Received: by 10.114.79.105 with HTTP; Thu, 8 Oct 2015 19:10:51 -0700 (PDT) Message-ID: From: Scott Arciszewski To: tls@ietf.org Content-Type: multipart/alternative; boundary=001a11c386c629b70a0521a27d3e Archived-At: X-Mailman-Approved-At: Sun, 01 Nov 2015 16:50:23 -0800 Subject: [TLS] TLS 1.3 - Just ditch compression X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Fri, 09 Oct 2015 02:12:51 -0000 X-Original-Date: Thu, 8 Oct 2015 22:10:51 -0400 X-List-Received-Date: Fri, 09 Oct 2015 02:12:51 -0000 --001a11c386c629b70a0521a27d3e Content-Type: text/plain; charset=UTF-8 Based on CRIME and BREACH we know that this construction is not secure: C = encrypt(compress(A || B)) If you control B and A contains sensitive information, strlen(C) tells you information about A. Vice versa if you control A and B contains sensitive information. In the context of a web application, this can lead to the compromise the contents of HTTP-Only cookies. This is known to be safe: C = encrypt(A || B). (No compression.) This might be safe: C = encrypt(A || compress(B) ). If an application needs to compress data before encryption, it shouldn't be a Transport Layer protocol's job to do so. Compression has no place in Transport Layer Security. Please nix it until we can, in a provably secure manner, make C = encrypt(compress(A || B)) not leak information about A when an attacker controls B. I await your IACR papers that prove the contrary, or a swift and decisive vote to kill TLS encryption in 1.3. Further bikeshedding is just embarrassing. Just my $0.02. Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises --001a11c386c629b70a0521a27d3e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Based on CRIME and BREACH we know that this construct= ion is not secure:

C =3D encrypt(compress(A || B))=

If you control B and A contains sensitive informa= tion, strlen(C) tells you information about A. Vice versa if you control A = and B contains sensitive information.

In the conte= xt of a web application, this can lead to the compromise the contents of HT= TP-Only cookies.

This is known to be safe: C =3D e= ncrypt(A || B). (No compression.)

This might be sa= fe: C =3D encrypt(A || compress(B) ).

If an applic= ation needs to compress data before encryption, it shouldn't be a Trans= port Layer protocol's job to do so.

Compressio= n has no place in Transport Layer Security. Please nix it until we can, in = a provably secure manner, make C =3D encrypt(compress(A || B)) not leak inf= ormation about A when an attacker controls B.

I aw= ait your IACR papers that prove the contrary, or a swift and decisive vote = to kill TLS encryption in 1.3. Further bikeshedding is just embarrassing.

Just my $0.02.

Scott Arcisze= wski
Chief Development Officer
<= /div>
--001a11c386c629b70a0521a27d3e-- From nobody Sun Nov 1 16:50: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 DBEC41A92E4 for ; Fri, 2 Oct 2015 19:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.702 X-Spam-Level: X-Spam-Status: No, score=0.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=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 Vxt0g1c8UQZT for ; Fri, 2 Oct 2015 19:45:11 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D00751A92E1 for ; Fri, 2 Oct 2015 19:45:10 -0700 (PDT) Received: by pacex6 with SMTP id ex6so122160045pac.0 for ; Fri, 02 Oct 2015 19:45:10 -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=Azrl2Q+4xSRIiPS15rCVzLjj7tX0QvlVEyrSCL8Zj1U=; b=FaN8SQl+HDyLfeFuuiteei4mIEsUowvmBRR6lIQnWwnXl2ETA2W5bR8wJgsSlQngVl xwfkYfm4mRgEG41j1VECfq9qRDzRE/EnDHyQMFyk9LY/hBU/ey+nyDXZvk5YoPUTNFJA rbjh/qX4iamfQpZGGOoQTCSbyT5FVuR7r5EiXLirPByv/aPCNODgd21N7FLEY6eOX0Ri R/J13jmjUq0vz0vBL8BxFWpdXTum/OoamDSJnGdkp4QOLpMUQ2DLGM3D+imSZaS2xdxh OLbGJZEJBUeIgmVocA8mowtaZEAR+6BEZg05oJvT6XNmU16OzPmpa7DwBX2YptoY5AZy dXQw== X-Received: by 10.67.4.9 with SMTP id ca9mr24194087pad.90.1443840310524; Fri, 02 Oct 2015 19:45:10 -0700 (PDT) Received: from [10.12.142.197] (s1402242.xgsspn.imtp.tachikawa.spmode.ne.jp. [1.75.2.242]) by smtp.gmail.com with ESMTPSA id dz7sm14515005pab.16.2015.10.02.19.45.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 02 Oct 2015 19:45:09 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-0DEA9B53-A7F9-46AC-8C77-0CA0510EE593 Mime-Version: 1.0 (1.0) From: takamichi saito X-Mailer: iPhone Mail (12H143) In-Reply-To: <682cb934aeeb42fabdf1fecfccf4c5b5@ustx2ex-dag1mb3.msg.corp.akamai.com> Content-Transfer-Encoding: 7bit Message-Id: <2DB2A295-AEE7-46A5-BDD2-4BD298F5DA6D@gmail.com> References: <79C632BCF9D17346A0D3285990FDB01AA3B9DAD8@HOBEX21.hob.de> <55FC5822.5070709@trigofacile.com> <77583acbe981488493fd4f0110365dae@ustx2ex-dag1mb1.msg.corp.akamai.com> <55FC7343.3090301@trigofacile.com> <6796F70E-44FD-4CD8-A691-6D0BFAE6EFDC@cs.meiji.ac.jp> <682cb934aeeb42fabdf1fecfccf4c5b5@ustx2ex-dag1mb3.msg.corp.akamai.com> To: "Salz, Rich" Archived-At: X-Mailman-Approved-At: Sun, 01 Nov 2015 16:50:36 -0800 Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Sat, 03 Oct 2015 02:45:12 -0000 X-Original-Date: Sat, 3 Oct 2015 11:45:07 +0900 X-List-Received-Date: Sat, 03 Oct 2015 02:45:12 -0000 --Apple-Mail-0DEA9B53-A7F9-46AC-8C77-0CA0510EE593 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable 2015/10/03 0:24=1B$B!"=1B(BSalz, Rich =1B$B$N%a%C%;!<%8=1B= (B: >=20 >> 1) We know CRIME threat, but it can not be risk for everyone. >> e.g., CVSS v2 Base Score: 2.6 (LOW) >=20 > CVSS isn't always appropriate; CVSS2 called Heartbleed a 5; CVS v3 called i= t 7.5 We know it, but one of indicators. How can you say the dangerous or risk instead of it?=20 My point is, CRIME is risk for every case? even when we have option in tls1= .3, in case that default is off.=20 >=20 >> Which one is safer, "tls1.2" v.s. "tls1.3 with comp/decomp" ? >=20 > They are equivalent. If you use AES-GCM and ECDHE, and you don't need 0RT= T, then there is no compelling reason to use TLS 1.3. If so, some people can skip tls1.3. ;; takamixhi saito c2xhYWlidHNvcw= --Apple-Mail-0DEA9B53-A7F9-46AC-8C77-0CA0510EE593 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


<= /div>
2015/10/03 0:24=E3=80=81Salz, Rich <rsalz@akamai.com> =E3=81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3=83= =BC=E3=82=B8:


<= blockquote type=3D"cite">1) We know CRIME threat, but it can not be ri= sk for everyone.
e.g.= , CVSS v2 Base Score: 2.6 (LOW)

CVSS isn't always appropriate; CVSS2 called Heartbleed a 5; CVS v3 called i= t 7.5

We know it,= but one of indicators.
How can you say the dangerou= s or risk instead of it? 
My point is, CRIME is= risk for every case? even when we have option  in tls1.3, in case that= default is off. 

=
Which one is safer, "tls1.2" v.s.= "tls1.3 with comp/decomp" ?

T= hey are equivalent.  If you use AES-GCM and ECDHE, and you don't need 0= RTT, then there is no compelling reason to use TLS 1.3.


If so, some people c= an skip tls1.3.

;; takamixhi saito
c2xhYWlidHNvcw
<= /div>= --Apple-Mail-0DEA9B53-A7F9-46AC-8C77-0CA0510EE593-- From nobody Sun Nov 1 16:50: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 352371A9308 for ; Fri, 2 Oct 2015 19:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 jt2pO089LGu8 for ; Fri, 2 Oct 2015 19:51:03 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e: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 858B21A9300 for ; Fri, 2 Oct 2015 19:51:03 -0700 (PDT) Received: by padhy16 with SMTP id hy16so122109709pad.1 for ; Fri, 02 Oct 2015 19:51:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:mime-version:subject :message-id:date:references:in-reply-to:to; bh=4yGI3M0z732+a9J3ubM8RvJ0FyLTDozzBUrydUTRuHM=; b=ePRPXexK5l9htKjxLyVZnhupMqe/UzZfyeBkyHDADovg5lvSHuJ2dqfOOswWSBxTTB eq8KCTiThn78PumUtp3U0nxnmNKDJepdnjfXVeWhZKFR1dq4eRdT2DXwdd2bGa94/Vqc WWu4M7bpwlX02V2W5DA1+S2hTfLZGaYhK79VKr2xoLhfL1rPbj503OUsawlXlZh036Rs m93ry6pKG3rLEi6I/VjtB0n8Y4yweV3+8aGPyZy/ojR7gcm/eISNwR816nXPCqtVEDY3 5OOy7LiaNemdPeoqYRzLCE1runEY0c7b4QdiaeF3UJFGw3rP1l2zi98GuBIqzcpkuuw7 mupg== X-Received: by 10.68.243.99 with SMTP id wx3mr23981084pbc.33.1443840663184; Fri, 02 Oct 2015 19:51:03 -0700 (PDT) Received: from [10.12.142.197] (s1402242.xgsspn.imtp.tachikawa.spmode.ne.jp. [1.75.2.242]) by smtp.gmail.com with ESMTPSA id ll9sm14433424pbc.42.2015.10.02.19.51.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 02 Oct 2015 19:51:02 -0700 (PDT) From: takamichi saito Content-Type: multipart/alternative; boundary=Apple-Mail-22448A29-5EF4-4CBF-9009-7B55BCA9DDB0 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Message-Id: References: <79C632BCF9D17346A0D3285990FDB01AA3B9DAD8@HOBEX21.hob.de> <55FC5822.5070709@trigofacile.com> <77583acbe981488493fd4f0110365dae@ustx2ex-dag1mb1.msg.corp.akamai.com> <55FC7343.3090301@trigofacile.com> <6796F70E-44FD-4CD8-A691-6D0BFAE6EFDC@cs.meiji.ac.jp> <560E8DA8.8020903@zinks.de> In-Reply-To: <560E8DA8.8020903@zinks.de> To: "tls@ietf.org" X-Mailer: iPhone Mail (12H143) Archived-At: X-Mailman-Approved-At: Sun, 01 Nov 2015 16:50:37 -0800 Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Sat, 03 Oct 2015 02:51:05 -0000 X-Original-Date: Sat, 3 Oct 2015 11:51:00 +0900 X-List-Received-Date: Sat, 03 Oct 2015 02:51:05 -0000 --Apple-Mail-22448A29-5EF4-4CBF-9009-7B55BCA9DDB0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > Browsers are not a concern as they already have their own comp/decomp code= s. HTTP/1 can compress content (Content-encoding and transfer-encoding) and H= TTP2 has additional header compression. >=20 I see,=20 but contrary, tls is only for browser?=20 And more,=20 if you kick out comp/decomp from tls, can we be safer when we use tls? If you know the paper, please teach me. Or, rfc or good teacher should notify us, "When you use TLSv1.3, you never use compression, sorry!" I know it may be out scope,=20 but we have to estimate the risk. regards, > Regards, > Roland >=20 >=20 > Am 02.10.2015 um 15:08 schrieb takamichi saito: >>> Do we know how many protocols currently suffer from CRIME? >>>=20 >>>=20 >>> Maybe a best practice could be suggested by UTA for the implementation o= f TLS in software, to disable compression if vulnerable. And for the others= , to implement a way to enable/disable compression in case one day a vulnera= bility is found. >> I agree. >>=20 >> Again, >>=20 >> 1) We know CRIME threat, but it can not be risk for everyone. >> e.g., CVSS v2 Base Score: 2.6 (LOW) >>=20 >> 2) If we need to have comp/decomp in an application layer, >> clients such like browser need their own comp/decomp codes. >>=20 >> 3) If there is no comp in tls1.3, some people may continue to use tls1.2.= >> Which one is safer, "tls1.2" v.s. "tls1.3 with comp/decomp" ? >>=20 >> That's why we explore the way to keep compression in TLSv1.3. >> How about making an option only in server-side? >> The spec has the compression but default is off, and also provides the su= ggestion. >>=20 >>=20 >>> --=20 >>> Julien =C3=89LIE >>>=20 >>> =C2=AB La vraie valeur d'un homme se mesure lorsqu'il a tout perdu. =C2=BB= >>>=20 >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>=20 >> ;; takamixhi saito >> c2xhYWlidHNvcw >>=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 ;; takamixhi saito c2xhYWlidHNvcw= --Apple-Mail-22448A29-5EF4-4CBF-9009-7B55BCA9DDB0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable




Browsers are not a concern as they already h= ave their own comp/decomp codes. HTTP/1 can compress content (Content-encodi= ng and transfer-encoding) and HTTP2 has additional header compression.


I see, 
but co= ntrary,
tls is only for browser? 

And more, 
if= you kick out comp/decomp from tls,
can we be safer w= hen we use tls?
If you know the paper, please teach m= e.

Or, rfc or good teacher s= hould notify us,
"When you use TLSv1.3, you never us= e compression, sorry!"
<= span style=3D"-webkit-text-size-adjust: auto;">I know it may be out scope,&n= bsp;
but we have to estimate the risk.

regards,


Regards,
Roland


Am 02.10.2015 um 15:08 schrieb takamichi s= aito:
Do= we know how many protocols currently suffer from CRIME?
<= /span>

Maybe a best practice could be suggeste= d by UTA for the implementation of TLS in software, to disable compression i= f vulnerable.  And for the others, to implement a way to enable/disable= compression in case one day a vulnerability is found.
I agree.

Again,
<= /span>
1) We know CRIME thre= at, but it can not be risk for everyone.
e.g., CVSS v2 Base Score: 2.6 (LOW)

2) If we need to have comp/decomp in an application layer,
 clients such like b= rowser need their own comp/decomp codes.

3= ) If there is no comp in tls1.3, some people may continue to use tls1.2.
Which one is safer, "tls= 1.2" v.s. "tls1.3 with comp/decomp" ?

Tha= t's why we explore the way to keep compression in TLSv1.3.
How about making an option only in ser= ver-side?
The spec ha= s the compression but default is off, and also provides the suggestion.

<= blockquote type=3D"cite">
--
Julien =C3=89LIE<= /span>

=C2=AB La vraie valeur d'un homme se me= sure lorsqu'il a tout perdu. =C2=BB

___= ____________________________________________
TLS mailing l= ist
TLS@ietf.org
https://w= ww.ietf.org/mailman/listinfo/tls

;; takamixhi saito
c2xhYWlidHNvcw

___________________= ____________________________
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
=
;; takamixhi saito
c2xhYWlidHNvcw
= --Apple-Mail-22448A29-5EF4-4CBF-9009-7B55BCA9DDB0-- From nobody Sun Nov 1 16:54: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 8EE001B3EE2 for ; Sun, 1 Nov 2015 16:54:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.299 X-Spam-Level: X-Spam-Status: No, score=-101.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_71=0.6, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCIOtmjDURof for ; Sun, 1 Nov 2015 16:54:45 -0800 (PST) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED251B3ED8 for ; Sun, 1 Nov 2015 16:54:45 -0800 (PST) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id E546CF24173; Sun, 1 Nov 2015 19:54:34 -0500 (EST) 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 f9Wa6WH7rdp3; Sun, 1 Nov 2015 19:53:09 -0500 (EST) Received: from dhcp-28-85.meeting.ietf94.jp (dhcp-28-85.meeting.ietf94.jp [133.93.28.85]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 8A6E2F2417C; Sun, 1 Nov 2015 19:54:03 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-29--33004578 From: Russ Housley In-Reply-To: Date: Sun, 1 Nov 2015 19:53:50 -0500 Message-Id: References: To: Scott Arciszewski X-Mailer: Apple Mail (2.1085) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] TLS 1.3 - Just ditch compression X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 00:54:46 -0000 --Apple-Mail-29--33004578 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I thought we already decided to remove compression from TLS 1.3. Russ On Oct 8, 2015, at 10:10 PM, Scott Arciszewski wrote: > Based on CRIME and BREACH we know that this construction is not = secure: >=20 > C =3D encrypt(compress(A || B)) >=20 > If you control B and A contains sensitive information, strlen(C) tells = you information about A. Vice versa if you control A and B contains = sensitive information. >=20 > In the context of a web application, this can lead to the compromise = the contents of HTTP-Only cookies. >=20 > This is known to be safe: C =3D encrypt(A || B). (No compression.) >=20 > This might be safe: C =3D encrypt(A || compress(B) ). >=20 > If an application needs to compress data before encryption, it = shouldn't be a Transport Layer protocol's job to do so. >=20 > Compression has no place in Transport Layer Security. Please nix it = until we can, in a provably secure manner, make C =3D encrypt(compress(A = || B)) not leak information about A when an attacker controls B. >=20 > I await your IACR papers that prove the contrary, or a swift and = decisive vote to kill TLS encryption in 1.3. Further bikeshedding is = just embarrassing. >=20 > Just my $0.02. >=20 > Scott Arciszewski > Chief Development Officer > Paragon Initiative Enterprises --Apple-Mail-29--33004578 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = thought we already decided to remove compression from TLS = 1.3.

Russ


On = Oct 8, 2015, at 10:10 PM, Scott Arciszewski wrote:

Based on CRIME and BREACH we know that this = construction is not secure:

C =3D = encrypt(compress(A || B))

If you control B and = A contains sensitive information, strlen(C) tells you information about = A. Vice versa if you control A and B contains sensitive = information.

In the context of a web = application, this can lead to the compromise the contents of HTTP-Only = cookies.

This is known to be safe: C =3D = encrypt(A || B). (No compression.)

This might = be safe: C =3D encrypt(A || compress(B) ).

If = an application needs to compress data before encryption, it shouldn't be = a Transport Layer protocol's job to do = so.

Compression has no place in Transport Layer = Security. Please nix it until we can, in a provably secure manner, make = C =3D encrypt(compress(A || B)) not leak information about A when an = attacker controls B.

I await your IACR papers = that prove the contrary, or a swift and decisive vote to kill TLS = encryption in 1.3. Further bikeshedding is just = embarrassing.

Just my $0.02.

Scott Arciszewski
Chief = Development Officer

= --Apple-Mail-29--33004578-- From nobody Sun Nov 1 17:01: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 13BEC1B3F20 for ; Sun, 1 Nov 2015 17:01:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKYDuytBhU8u for ; Sun, 1 Nov 2015 17:01:51 -0800 (PST) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D73181B3F2D for ; Sun, 1 Nov 2015 17:01:50 -0800 (PST) Received: by ykft191 with SMTP id t191so125206841ykf.0 for ; Sun, 01 Nov 2015 17:01:50 -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=UsDNFnHzSSeTitWGPytUMTf+VEb+8PIcZnNWfuzh9Jk=; b=eN/mI3WAutTBSAxKQOZ5ulrM7NvzqGHliPRI5TOjaOlXmqohwaDoR4H8ld+0XabxbT mcNxXWgQZ2kEQ09uRXWCrMRS2X4C2NPP8x0Uc7N5Sw3eIQwBT73IQrMeWgVrBRKT8ENH nMETigGZvoSb496NpXe9x4CWFooCZQ8Dr1+/5TjQNOuYh54C8ovZot7Y3A1GmOTffGb1 luKjgCuuhMB1LEsQSxEXwLtWJ74MZYzfPT6+EJQE2F45j41CgyIT6AoyN3t73wYKQEWM mu6alMKJZS/v5J78GDktZkqh60vxmnwxsBxEb4nJso/j8Ejd6ri5maTiMYR6D4J+5fGH EsVg== X-Received: by 10.129.72.69 with SMTP id v66mr14400141ywa.220.1446426110281; Sun, 01 Nov 2015 17:01:50 -0800 (PST) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id n186sm1061068ywb.7.2015.11.01.17.01.49 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 01 Nov 2015 17:01:49 -0800 (PST) From: Dave Garrett To: tls@ietf.org Date: Sun, 1 Nov 2015 20:01:48 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201511012001.48698.davemgarrett@gmail.com> Archived-At: Cc: Scott Arciszewski Subject: Re: [TLS] TLS 1.3 - Just ditch compression X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 01:01:53 -0000 On Sunday, November 01, 2015 07:53:50 pm Russ Housley wrote: > I thought we already decided to remove compression from TLS 1.3. We did. See here: https://www.ietf.org/mail-archive/web/tls/current/msg17941.html On Thursday, October 08, 2015 10:10:51 pm Scott Arciszewski wrote: > Compression has no place in Transport Layer Security. [...] > Further bikeshedding is just embarrassing. The bikeshed was officially demolished. Compression will not be in TLS 1.3. Dave From nobody Sun Nov 1 17:12: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 E443E1ACDD5 for ; Sun, 1 Nov 2015 17:12:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 ZmB8L1qGJzVe for ; Sun, 1 Nov 2015 17:12:10 -0800 (PST) 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 7E6F71ACDC9 for ; Sun, 1 Nov 2015 17:12:10 -0800 (PST) Received: by pasz6 with SMTP id z6so130288745pas.2 for ; Sun, 01 Nov 2015 17:12:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=Z/N82DxPrSUanmoUwdz+SJrULlIg/2kkMaJkXig1IAA=; b=IaHg6RdXFVgXl6Arg4q72e8f+TLjNJTim9wTTlKohWySdORr9q6uTHOrhv9m0svCrI X9w8+4AJFmLFNCgOVBS6RiOAsVPqpHR8lE9PzTo7OxIJJrPgU88pGCQLwk9dsgKRr/gu 5e6nHLO6rkBqvxy1nB0GRD9AnldDSppy4oNEo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:content-transfer-encoding :subject:message-id:date:to:mime-version; bh=Z/N82DxPrSUanmoUwdz+SJrULlIg/2kkMaJkXig1IAA=; b=AqnqJLMfA8rTMNundhNc58wVgYfLP2IbVZNeD/C+QRs4kB3GfUu4ElZXQNKw1FfUpG EfSeW65dF3VdG+RPlonq4Yrmp4ytC9V9FHW3IRDw3RpysOJgmuLz5oMbBm283WNDibhd S1OYS5wAZZ7UXOC0gH7iW9Yg7SHX16dCQkFeDO3GtpsHaUa71Gs1AWE4XGBOIW7I8/td Djz/OiF74EaX2ZX924eDok6TwNBuTym8Y1Ed3nnAxvZjHY+E2acxyu7XQF8Sz4TwgyWY is/GyWjaWFzA0wGtB2btcArWILl5kKI22g7fEPNIt5pK/GGUj5saUfoVD2jIPrgFEf15 kQeA== X-Gm-Message-State: ALoCoQkexcSwzsUAslBwMuiVVXVqy9oOKfcNjEaHJrQ/PeqHtkejT21zwTh3qj3aZ3PgjkEVs7GR X-Received: by 10.68.135.161 with SMTP id pt1mr23818193pbb.80.1446426730115; Sun, 01 Nov 2015 17:12:10 -0800 (PST) Received: from dhcp-28-27.meeting.ietf94.jp (dhcp-28-27.meeting.ietf94.jp. [133.93.28.27]) by smtp.gmail.com with ESMTPSA id c4sm20556010pat.46.2015.11.01.17.12.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 01 Nov 2015 17:12:09 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 2 Nov 2015 10:12:05 +0900 To: "" Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) X-Mailer: Apple Mail (2.3096.5) Archived-At: Subject: [TLS] IETF 94 - TLS 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, 02 Nov 2015 01:12:12 -0000 I=E2=80=99ve uploaded the agenda: https://www.ietf.org/proceedings/94/agenda/agenda-94-tls I=E2=80=99ll post slides as I get them. spt= From nobody Sun Nov 1 17:13: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 8114C1B3ADB for ; Sun, 1 Nov 2015 17:13:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 Hr2dhW2dLxWp for ; Sun, 1 Nov 2015 17:13:43 -0800 (PST) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e: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 114141ACDD3 for ; Sun, 1 Nov 2015 17:13:43 -0800 (PST) Received: by pabfh17 with SMTP id fh17so6303231pab.0 for ; Sun, 01 Nov 2015 17:13:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=l2K9Ubb/2FGXkghTh7/caMbBiLlgmPFgct62lretuFY=; b=GqS8lbFPfrBuuFC5h54V83cf7+UaZs1lczYweZunUg3uQfI8Cn7GF6q9KO+XL5U5u2 6Zhiun13Nb22pjwGHFcWmtWvQz5UgNSsaD2wVtJmBEI18PqZDs4UTA92BN21iso7cgaQ 22E5mA8AxvYDquuR5YlmsyNcvjMdF9MvDBpt8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to; bh=l2K9Ubb/2FGXkghTh7/caMbBiLlgmPFgct62lretuFY=; b=nD+vdS0tV9hZQPfGuQDwL71NBGtHefkAWrbQH466o2b+xKj2GMDsLcPlhjt90mq+6H a8Q0FL5TitoyYD2byfoFVHTR0Qb0M2lJxXmf+ENm2yVu7pKAobQmmBvrBFS3P4Ozy94y lgmWJqtQkeOHTc/Rv0MsOstlbED/WOxZAavp10K2t6NBbUIaQMjV5rC5R0FHMZFsMWgy YMNN0z7W//awRr0MuR7wF3WjdoVSkE+K8V3n/D6bXUsy61CM2YX8TxbReNrLJjerZxnl 0SgCdVZWOTOqhIZXc/o9/OgRife4jUm8THOE3fmB6+GHBUl0MSwcLTWR4t5qAW3C7K+Q eBRw== X-Gm-Message-State: ALoCoQmPLUaGAFepIGEX7GApE8+wtLcxO7Epa+FxsqYBqjHkCc3ghnKesdfvOCl4nIHxzMcQh+rH X-Received: by 10.68.252.194 with SMTP id zu2mr23887151pbc.58.1446426822677; Sun, 01 Nov 2015 17:13:42 -0800 (PST) Received: from t20010c4000003024858e77b115aa254b.v6.meeting.ietf94.jp (t20010c4000003024858e77b115aa254b.v6.meeting.ietf94.jp. [2001:c40:0:3024:858e:77b1:15aa:254b]) by smtp.gmail.com with ESMTPSA id hq1sm20483893pbb.43.2015.11.01.17.13.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 01 Nov 2015 17:13:42 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Sean Turner In-Reply-To: <201511012001.48698.davemgarrett@gmail.com> Date: Mon, 2 Nov 2015 10:13:38 +0900 Content-Transfer-Encoding: 7bit Message-Id: <742A1C6B-83FE-48E7-8503-DE3BD60B5536@sn3rd.com> References: <201511012001.48698.davemgarrett@gmail.com> To: "" X-Mailer: Apple Mail (2.3096.5) Archived-At: Subject: Re: [TLS] TLS 1.3 - Just ditch compression X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 01:13:44 -0000 My bad there were some messages sitting in the moderator queue that I let go. spt > On Nov 02, 2015, at 10:01, Dave Garrett wrote: > > On Sunday, November 01, 2015 07:53:50 pm Russ Housley wrote: >> I thought we already decided to remove compression from TLS 1.3. > > We did. > > See here: > https://www.ietf.org/mail-archive/web/tls/current/msg17941.html > > On Thursday, October 08, 2015 10:10:51 pm Scott Arciszewski wrote: >> Compression has no place in Transport Layer Security. > [...] >> Further bikeshedding is just embarrassing. > > The bikeshed was officially demolished. Compression will not be in TLS 1.3. > > > Dave > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Sun Nov 1 17:30: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 A4C871ACE24 for ; Sun, 1 Nov 2015 17:30:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_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 JYirljtgOdMw for ; Sun, 1 Nov 2015 17:30:50 -0800 (PST) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08CB31ACE22 for ; Sun, 1 Nov 2015 17:30:50 -0800 (PST) Received: by ykft191 with SMTP id t191so125665479ykf.0 for ; Sun, 01 Nov 2015 17:30:49 -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=rLTN1P2OpJRaIsgMjsL9ekUslziRhuEsD/2Yz7cpemA=; b=mV4MsW26C+PplUiQAn5vR4oCN5KtYTZvnYOWVFzA0EzRo6lDm2cwS6ftIJ3l5tkFFn bXR8VOEHOTklrANj9e5rXqKLXGSAbRKUacBBWq1J/nEUvZdd8R9cy0nTP4VImR4HhltW 7XquQOYmQwCLiUi+cxsWGxvTzlZI45MOSTYsQpzn1o/WWNTk8Uxe9eDPP8CkamWUo/gz 0/AJ0i9aghEgMeW8+pMElPF/XdZwinFpWjgiwOwEx9jBR1SrtsfZGNN+nA3QU0eEJTDA YKy+3sxkFfT8THUKoU2fKneeL3Q+MWIbbstBhjGRTYqC83aTT23yQZotr9XjkjPNKgF6 6x+g== MIME-Version: 1.0 X-Received: by 10.13.204.207 with SMTP id o198mr16281594ywd.183.1446427849317; Sun, 01 Nov 2015 17:30:49 -0800 (PST) Received: by 10.129.132.145 with HTTP; Sun, 1 Nov 2015 17:30:49 -0800 (PST) In-Reply-To: References: <87fv1fal6s.fsf@latte.josefsson.org> Date: Mon, 2 Nov 2015 10:30:49 +0900 Message-ID: From: Martin Thomson To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fwd: [pkix] Updated elliptic curve drafts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 01:30:51 -0000 It's not entirely clear what you are asking for here, but have you looked at the key derivation in TLS 1.3? On 16 October 2015 at 01:27, Phillip Hallam-Baker wrote: > > I strongly oppose any new crypto that does not include a fix for the > ephemeral keygen. > > The reason logjam is possible is that the key negotiation is essentially > > 1) Negotiate a shared secret S1 using the strong, long term server key. > 2) Use the shared secret to authenticate ephemeral key parameters Ec, Es > 3) Derive the session keys S2 from the ephemeral key parameters only > and throw away the output from the strong long term keys. > > It is not just 512 bit keys that are vulnerable. 1024 bit DH keys are also > weak: > https://freedom-to-tinker.com/blog/haldermanheninger/how-is-nsa-breaking-so-much-crypto/ > > If we are changing the crypto suites we can and should fix this > instead of S2 being a function of Ec, Es alone, add in the original S1 > as a salt. e.g. S2 = SHA512 (S1 + f(Ec, Es)) > > This ensures that no matter how broken the ephemeral crypto is, the > key exchange is always at least as secure as either the long term or > the ephemeral key. > > > Logjam isn't the only way that the system can be compromised. > > Oh and damn right I think BULLRUN might have had a part in keeping the > spec broken. > > > There is a right way to design an ephemeral key exchange and it is to > 'Do no harm'. Logjam shows that our current key negotiation mechanism > has a hole that makes it possible for the ephemeral to do harm. > > The move to the CFRG curves will mean a backwards incompatible change > to the deployed infrastructure so this is a perfect time to fix > ephemeral key establishment. > > I am going to keep raising this until the issue is fixed. > > > > On Mon, Oct 12, 2015 at 4:25 PM, Simon Josefsson > wrote: >> Hi, >> >> I've updated my drafts on Curve25519/Curve448 support in PKIX to refer >> to the CFRG-Curves and CFRG-EdDSA drafts. >> >> The following document adds new EdDSA key/signature OIDs directly: >> >> https://tools.ietf.org/html/draft-josefsson-pkix-eddsa-04 >> >> The following document adds new namedCurve OIDs, thus going indirectly >> through the existing ECDSA 3279 route: >> >> https://tools.ietf.org/html/draft-josefsson-pkix-newcurves-01 >> >> These two drafts take different approaches to including the new curves >> into PKIX, and currently both lack applicability statements. There is >> potential for overlap and conflict right now. It recently came up that >> for PKCS#11 a namedCurve approach would be useful, but for normal PKIX >> Certificates, it may be that the first direct approach is preferrable. >> The former lack the possibility of encoding keys for DH. I believe each >> approach can be useful on its own, but we need to include text adressing >> use-cases that can be resolved by both documents to avoid conflicts. >> >> /Simon >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >> > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Sun Nov 1 23:14: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 DBDF11B339E; Sun, 1 Nov 2015 23:14:04 -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, 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 2mOT26vEmjn8; Sun, 1 Nov 2015 23:14:01 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0736.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::736]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D0921B3383; Sun, 1 Nov 2015 23:13:57 -0800 (PST) Received: from BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) by BN1PR09MB123.namprd09.prod.outlook.com (10.255.200.25) with Microsoft SMTP Server (TLS) id 15.1.312.18; Mon, 2 Nov 2015 07:13:40 +0000 Received: from BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) by BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) with mapi id 15.01.0312.014; Mon, 2 Nov 2015 07:13:40 +0000 From: "Dang, Quynh" To: Eric Rescorla , "cfrg@ietf.org" Thread-Topic: Collision issue in ciphertexts. Thread-Index: AQHRFT3/uhvieo6mr0iE/9qPshn2sQ== Date: Mon, 2 Nov 2015 07:13:39 +0000 Message-ID: References: <811734cd29d64adc98c5388870611575@XCH-ALN-004.cisco.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-originating-ip: [2001:c40:0:3032:c010:3a38:d1de:776b] x-microsoft-exchange-diagnostics: 1; BN1PR09MB123; 5:OysDhTUku/ZcDlr952bIr+5ygzQ7rZOI7tY23Bg39xckQ8C4JxzcTc4LjOilu3k6KrJTO9LpbRmPjzSJvqI8yJT5i2InhvbN3tX4IzAknxnrO2cy5clxr6JzPo4Tn9zQf2xqXnoD09cTc7o4keLFbQ==; 24:rwQ35CQ8yf2fzRQfsoa0buCQ3zkxBeWM1cDnH9o3xWwsQZ9HjEo0IvCSf3CMDnQhpxghKlYHOtp3JKb0HOx0lvNSk1u6K1CS4Lyt2SUd9Yk=; 20:K5RZHh6l9bLcvbeU75mC5nQgNY5k0EQHVlK9rdz9r5MQURKJEM6A/glxLGVIPrcQeUWWAKghvWBwA/HMRZW9rA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB123; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(520078)(3002001)(10201501046); SRVR:BN1PR09MB123; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB123; x-forefront-prvs: 0748FF9A04 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(99286002)(105586002)(92566002)(2900100001)(86362001)(5002640100001)(16236675004)(5007970100001)(33656002)(10400500002)(5004730100002)(106116001)(5001920100001)(2501003)(5001960100002)(19627405001)(97736004)(5001770100001)(81156007)(102836002)(74316001)(229853001)(40100003)(5008740100001)(77096005)(122556002)(54356999)(106356001)(189998001)(93886004)(50986999)(87936001)(19625215002)(101416001)(11100500001)(5003600100002)(76176999)(2950100001)(76576001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB123; H:BN1PR09MB124.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN1PR09MB124321AF53FE4EB4F47AFE9F32C0BN1PR09MB124namprd_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2015 07:13:39.9265 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB123 Archived-At: Cc: "tls@ietf.org" Subject: [TLS] Collision issue in ciphertexts. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 07:14:05 -0000 --_000_BN1PR09MB124321AF53FE4EB4F47AFE9F32C0BN1PR09MB124namprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Eric, As you asked the question about how many ciphertext blocks should be safe u= nder a single key, I think it is safe to have 2^96 blocks under a given key= if the IV (counter) is 96 bits. When there is a collision between two ciphertext blocks when two different = counter values are used , the chance of the same plaintext was used twice i= s 1^128. Collisions start to happen a lot when the number of ciphertext bl= ocks are above 2^64. However, each collision just reveals that the correspo= nding plaintext blocks are probably different ones. Quynh. --_000_BN1PR09MB124321AF53FE4EB4F47AFE9F32C0BN1PR09MB124namprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Eric,


As you asked the question about how many ciphertext blocks should be saf= e under a single key, I think it is safe to have 2^96 blocks under a given = key if the IV (counter) is 96 bits. 


When there is a collision between two ciphertext blocks when two differe= nt counter values are used , the chance of the same plaintext was used twic= e is 1^128.  Collisions start to happen a lot when the number of = ciphertext blocks are above 2^64. However, each collision just reveals that the corresponding plaintext blocks a= re probably different ones. 



Quynh. 

--_000_BN1PR09MB124321AF53FE4EB4F47AFE9F32C0BN1PR09MB124namprd_-- From nobody Mon Nov 2 02:07: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 26A781A1A39; Mon, 2 Nov 2015 02:07:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-OFnqjZr7-K; Mon, 2 Nov 2015 02:07:47 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::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 3B6931A1A3B; Mon, 2 Nov 2015 02:07:47 -0800 (PST) Received: by wmff134 with SMTP id f134so55733687wmf.0; Mon, 02 Nov 2015 02:07:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XYTa7lwo62l3xTRMfSHHAXK8ODoLvGHh73DLRwL3ZNQ=; b=wmVqVTenRx5k08wjuwswYOJlCZAp+2RdFBm7DBNGrb3MivMcclGB2OxskaLZ2wYGSK 77dZlBMgqOok0bWmScOiT0g84kKEf6V2JUgfqxtKNgr7SyxldwRAfbps3zYrBug7Naal 6WFexSNxE7pVRohr9DmLqo7w63Mi5rQD7+AQX38rC4Up2syjo0Yg8QteGTD8OK3utKmy 5Ru5XslTUOpjxTnhvZmSOkexa1kVcCdOz0fUnshHtnTK/0sENEYorNI3PwffpaCNa0QX Wmgz8BPJF4qbmWtaWQ7QAq0Od7oZedvXcjUaTatRxdrIs7tHdd1h4KNXR7PYJ2/xwKI7 1Vcw== MIME-Version: 1.0 X-Received: by 10.28.54.211 with SMTP id y80mr13349225wmh.3.1446458865616; Mon, 02 Nov 2015 02:07:45 -0800 (PST) Received: by 10.28.101.212 with HTTP; Mon, 2 Nov 2015 02:07:45 -0800 (PST) Received: by 10.28.101.212 with HTTP; Mon, 2 Nov 2015 02:07:45 -0800 (PST) In-Reply-To: References: <811734cd29d64adc98c5388870611575@XCH-ALN-004.cisco.com> Date: Mon, 2 Nov 2015 05:07:45 -0500 Message-ID: From: Watson Ladd To: "Dang, Quynh" Content-Type: multipart/alternative; boundary=001a114360ecde0efb05238bf22d Archived-At: Cc: cfrg@ietf.org, tls@ietf.org Subject: Re: [TLS] [Cfrg] Collision issue in ciphertexts. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 10:07:49 -0000 --001a114360ecde0efb05238bf22d Content-Type: text/plain; charset=UTF-8 On Nov 2, 2015 2:14 AM, "Dang, Quynh" wrote: > > Hi Eric, > > > As you asked the question about how many ciphertext blocks should be safe under a single key, I think it is safe to have 2^96 blocks under a given key if the IV (counter) is 96 bits. This is wrong for PRP, right for PRF. It's not that hard to find the right result. > > > When there is a collision between two ciphertext blocks when two different counter values are used , the chance of the same plaintext was used twice is 1^128. Collisions start to happen a lot when the number of ciphertext blocks are above 2^64. However, each collision just reveals that the corresponding plaintext blocks are probably different ones. Which breaks IND-$. Let's not be clever, but stick to ensuring proven definitions are true. > > > > Quynh. > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > --001a114360ecde0efb05238bf22d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Nov 2, 2015 2:14 AM, "Dang, Quynh" <quynh.dang@nist.gov> wrote:
>
> Hi Eric,
>
>
> As you asked the question about how many ciphertext blocks should be s= afe under a single key, I think it is safe to have 2^96 blocks under a give= n key if the IV (counter)=C2=A0is 96 bits.=C2=A0

This is wrong for PRP, right for PRF. It's not that hard= to find the right result.

>
>
> When there is a collision between two ciphertext blocks when two diffe= rent counter values are used , the chance of the same plaintext was used tw= ice is 1^128.=C2=A0 Collisions start to happen a lot=C2=A0when the number o= f ciphertext blocks=C2=A0are above 2^64. However, each collision just=C2=A0= reveals that the corresponding plaintext blocks are probably different ones= .=C2=A0

Which breaks IND-$. Let's not be clever, but stick to en= suring proven definitions are true.

>
>
>
> Quynh.=C2=A0
>
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irt= f.org/mailman/listinfo/cfrg
>

--001a114360ecde0efb05238bf22d-- From horiyo2010@gmail.com Mon Nov 2 05:53: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 256731B36B3 for ; Mon, 2 Nov 2015 05:53:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 fsFDHih3thUO for ; Mon, 2 Nov 2015 05:53:19 -0800 (PST) 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 B576A1B36AC for ; Mon, 2 Nov 2015 05:53:19 -0800 (PST) Received: by oifu63 with SMTP id u63so95701981oif.2 for ; Mon, 02 Nov 2015 05:53:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=xkHSIwSyoBjPY0ll9VrjdNYc7KXIh/hXgz63O2LYEUo=; b=mBT1viWJprXAb/DhkEHd2wgWfn0otaDtHlm/N4swHBgRZ/3NgFkycetieOWKlxsZhM kY71jR1/Z9p3MG7YZhtQkalfKNmlpdYWAg9Rmo8tLRY5yLkglH29gLXuANOxvXVOkYuw Lg5OE/efc1IzA7G9QgoT9FYASq6vu9bK7KvvbcTOiNXnVYASbowijD/RWw9jWegkQjwJ R432+wyxuHLGWk+Z5scgbxKpQb+OUrYqnOBApZd/ByjZcWy6JOLVcRjLLKdsOD/admPQ q1wr1bqb7k9VUf+8pUHlG/2r+p+q/fLhUaSGSpYTO0egy6ENmXV4VPj9ddJ5hIfAxil9 BAjQ== X-Received: by 10.202.216.130 with SMTP id p124mr13913456oig.65.1446472399211; Mon, 02 Nov 2015 05:53:19 -0800 (PST) MIME-Version: 1.0 Sender: horiyo2010@gmail.com Received: by 10.76.35.73 with HTTP; Mon, 2 Nov 2015 05:52:59 -0800 (PST) From: Yoshiaki Hori Date: Mon, 2 Nov 2015 22:52:59 +0900 X-Google-Sender-Auth: fs8mHz8b2Xnwu6CVBIM5FD9rbiU Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary=001a113d42f488521a05238f19d7 Archived-At: Subject: [TLS] Revised I-D: Use of KCipher-2 with Poly1305 in Transport Layer Security (draft-kiyomoto-kcipher2-tls-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, 02 Nov 2015 13:55:28 -0000 --001a113d42f488521a05238f19d7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, We've posted a new version of =E2=80=9CUse of KCipher-2 with Poly1305 in Transport Layer Security=E2=80=9D (draft-kiyomoto-kcipher2-tls-02) that address to add a cipher suite, KCipher-2 [RFC7008] and Poly1305 running with AEAD for TLS1.2. Name: draft-kiyomoto-kcipher2-tls Revision: 02 Title: Use of KCipher-2 with Poly1305 in Transport Layer Security Document date: 2015-11-01 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-kiyomoto-kcipher2-tls-02.txt Status: https://datatracker.ietf.org/doc/draft-kiyomoto-kcipher2-tls/ Htmlized: https://tools.ietf.org/html/draft-kiyomoto-kcipher2-tls-02 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-kiyomoto-kcipher2-tls-02 Abstract: This document describes the use of the KCipher-2 stream cipher with Poly1305 in Transport Layer Security (TLS) protocols version 1.2 and Datagram Transport Layer Security (DTLS) protocols. KCipher-2 is a stream cipher with a 128-bit key and a 128-bit initialization vector, which provides fast, efficient encryption and decryption. We address alternative stream cipher suite for TLS because we concern a risk of =E2=80=9Csingle stream cipher suite, Chacha20 with Poly1305. Our colleague is preparing KCipher-2 with Poly1305 code based on openssl-1.0.2 which will be available as an open source soon. The current Kcipher-2 with Poly1305 implementation can run with around 60% or more throughput comparing with Chacha20-Poly1305 under a small block size, e.g. 16 bytes and 64 bytes. We expect performance improvement with further optimization because the current code development in an early stage. We have tentative two performance reports run with different environment, which are indicated with [i] and [k] respectively. The case [i] is running with Intel(R) Core(TM) i5-4300U CPU@1.90GHz 2.50GHz / RAM 8.00GB / openSUSE13.2 64bit. Also, the case [k] is with Intel(R) Core(TM) i7-4770K 3.50GHz / Host OS: Windows 7 64bit with 32GB / Guest OS: Ubuntu 14.10 64bit with 7GB / gcc 4.9.1. Performance Results: (1) in case [i] environment: with Intel(R) Core(TM) i5-4300U CPU@1.90GHz 2.50GHz / RAM 8.00GB / openSUSE13.2 64bit. chacha20-poly1305 [i]: block size [byte] throughput [kbytes/sec] 16 31,586.83 64 101,580.14 256 188,614.93 1024 248,756.57 8192 272,231.08 kc2-poly1305 [i]: block size [byte] throughput [kbytes/sec] 16 16,938.10 64 54,679.51 256 156,798.30 1024 294,867.97 8192 388,743.17 (2) in case [k] environment: with Intel(R) Core(TM) i7-4770K 3.50GHz / Host OS: Windows 7 64bit with 32GB / Guest OS: Ubuntu 14.10 64bit with 7GB / gcc 4.9.1 chacha20-poly1305 with no-SIMD [k]: block size [byte] throughput [kbytes/sec] 16 51,704.44 64 173,918.85 256 403,878.27 1024 616,232.62 8192 721,810.77 kc2-poly1305 [k]: block size [byte] throughput [kbytes/sec] 16 30,338.55 64 101,063.15 256 284,340.82 1024 544,837.63 8192 736,327.00 Yoshiaki Hori --001a113d42f488521a05238f19d7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdiBkaXI9Imx0ciI+SGksPGJyPjxicj5XZSYjMzk7dmUgcG9zdGVkIGEgbmV3IHZlcnNpb24g b2Yg4oCcVXNlIG9mIEtDaXBoZXItMiB3aXRoIFBvbHkxMzA1PGJyPmluIFRyYW5zcG9ydCBMYXll ciBTZWN1cml0eeKAnSAoZHJhZnQta2l5b21vdG8ta2NpcGhlcjItdGxzLTAyKTxicj50aGF0IGFk ZHJlc3MgdG8gYWRkIGEgY2lwaGVyIHN1aXRlLCBLQ2lwaGVyLTIgW1JGQzcwMDhdIGFuZCA8YnI+ UG9seTEzMDUgcnVubmluZyB3aXRoIEFFQUQgZm9yIFRMUzEuMi48YnI+PGJyPk5hbWU6wqDCoMKg wqDCoMKgwqDCoMKgwqAgZHJhZnQta2l5b21vdG8ta2NpcGhlcjItdGxzPGJyPlJldmlzaW9uOsKg wqDCoMKgwqDCoCAwMjxicj5UaXRsZTrCoMKgwqDCoMKgwqDCoMKgwqAgVXNlIG9mIEtDaXBoZXIt MiB3aXRoIFBvbHkxMzA1IGluIFRyYW5zcG9ydCBMYXllciBTZWN1cml0eTxicj5Eb2N1bWVudCBk YXRlOsKgIDIwMTUtMTEtMDE8YnI+R3JvdXA6wqDCoMKgwqDCoMKgwqDCoMKgIEluZGl2aWR1YWwg U3VibWlzc2lvbjxicj5QYWdlczrCoMKgwqDCoMKgwqDCoMKgwqAgNjxicj5VUkw6wqDCoMKgwqDC oMKgwqDCoMKgwqDCoCA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQta2l5b21vdG8ta2NpcGhlcjItdGxzLTAyLnR4dCI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWtpeW9tb3RvLWtjaXBoZXIyLXRscy0wMi50eHQ8L2E+ PGJyPlN0YXR1czrCoMKgwqDCoMKgwqDCoMKgIDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWtpeW9tb3RvLWtjaXBoZXIyLXRscy8iPmh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWtpeW9tb3RvLWtjaXBoZXIyLXRscy88L2E+PGJyPkh0 bWxpemVkOsKgwqDCoMKgwqDCoCA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQta2l5b21vdG8ta2NpcGhlcjItdGxzLTAyIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQta2l5b21vdG8ta2NpcGhlcjItdGxzLTAyPC9hPjxicj5EaWZmOsKgwqDCoMKgwqDC oMKgwqDCoMKgIDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFm dC1raXlvbW90by1rY2lwaGVyMi10bHMtMDIiPmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/ dXJsMj1kcmFmdC1raXlvbW90by1rY2lwaGVyMi10bHMtMDI8L2E+PGJyPjxicj5BYnN0cmFjdDo8 YnI+wqDCoCBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUgdXNlIG9mIHRoZSBLQ2lwaGVyLTIg c3RyZWFtIGNpcGhlciB3aXRoPGJyPsKgwqAgUG9seTEzMDUgaW4gVHJhbnNwb3J0IExheWVyIFNl Y3VyaXR5IChUTFMpIHByb3RvY29scyB2ZXJzaW9uIDEuMiBhbmQ8YnI+wqDCoCBEYXRhZ3JhbSBU cmFuc3BvcnQgTGF5ZXIgU2VjdXJpdHkgKERUTFMpIHByb3RvY29scy7CoCBLQ2lwaGVyLTIgaXMg YTxicj7CoMKgIHN0cmVhbSBjaXBoZXIgd2l0aCBhIDEyOC1iaXQga2V5IGFuZCBhIDEyOC1iaXQg aW5pdGlhbGl6YXRpb24gdmVjdG9yLDxicj7CoMKgIHdoaWNoIHByb3ZpZGVzIGZhc3QsIGVmZmlj aWVudCBlbmNyeXB0aW9uIGFuZCBkZWNyeXB0aW9uLjxicj48YnI+V2UgYWRkcmVzcyBhbHRlcm5h dGl2ZSBzdHJlYW0gY2lwaGVyIHN1aXRlIGZvciBUTFMgYmVjYXVzZSB3ZSA8YnI+Y29uY2VybiBh IHJpc2sgb2Yg4oCcc2luZ2xlIHN0cmVhbSBjaXBoZXIgc3VpdGUsIENoYWNoYTIwIHdpdGggPGJy PlBvbHkxMzA1LiBPdXIgY29sbGVhZ3VlIGlzIHByZXBhcmluZyBLQ2lwaGVyLTIgd2l0aCBQb2x5 MTMwNSA8YnI+Y29kZSBiYXNlZCBvbiBvcGVuc3NsLTEuMC4yIHdoaWNoIHdpbGwgYmUgYXZhaWxh YmxlIGFzIGFuIG9wZW4gPGJyPnNvdXJjZSBzb29uLjxicj48YnI+VGhlIGN1cnJlbnQgS2NpcGhl ci0yIHdpdGggUG9seTEzMDUgaW1wbGVtZW50YXRpb24gY2FuIHJ1biB3aXRoPGJyPmFyb3VuZCA2 MCUgb3IgbW9yZSB0aHJvdWdocHV0IGNvbXBhcmluZyB3aXRoIENoYWNoYTIwLVBvbHkxMzA1PGJy PnVuZGVyIGEgc21hbGwgYmxvY2sgc2l6ZSwgZS5nLiAxNiBieXRlcyBhbmQgNjQgYnl0ZXMuwqAg PGJyPldlIGV4cGVjdCBwZXJmb3JtYW5jZSBpbXByb3ZlbWVudCB3aXRoIGZ1cnRoZXIgb3B0aW1p emF0aW9uPGJyPmJlY2F1c2UgdGhlIGN1cnJlbnQgY29kZSBkZXZlbG9wbWVudCBpbiBhbiBlYXJs eSBzdGFnZS48YnI+PGJyPldlIGhhdmUgdGVudGF0aXZlIHR3byBwZXJmb3JtYW5jZSByZXBvcnRz IHJ1biB3aXRoIGRpZmZlcmVudDxicj5lbnZpcm9ubWVudCwgd2hpY2ggYXJlIGluZGljYXRlZCB3 aXRoIFtpXSBhbmQgW2tdIHJlc3BlY3RpdmVseS48YnI+VGhlIGNhc2UgW2ldIGlzIHJ1bm5pbmcg d2l0aCBJbnRlbChSKSBDb3JlKFRNKSBpNS00MzAwVSA8YnI+Q1BVQDEuOTBHSHogMi41MEdIeiAv IFJBTSA4LjAwR0IgLyBvcGVuU1VTRTEzLjIgNjRiaXQuIDxicj5BbHNvLCB0aGUgY2FzZSBba10g aXMgd2l0aCBJbnRlbChSKSBDb3JlKFRNKSBpNy00NzcwSyAzLjUwR0h6IC88YnI+wqBIb3N0IE9T OiBXaW5kb3dzIDcgNjRiaXQgd2l0aCAzMkdCIC8gR3Vlc3QgT1M6IFVidW50dSAxNC4xMCA8YnI+ NjRiaXQgd2l0aCA3R0IgLyBnY2MgNC45LjEuPGJyPjxicj5QZXJmb3JtYW5jZSBSZXN1bHRzOjxi cj48YnI+KDEpIGluIGNhc2UgW2ldIGVudmlyb25tZW50OiB3aXRoIEludGVsKFIpIENvcmUoVE0p IGk1LTQzMDBVIDxicj7CoMKgwqAgQ1BVQDEuOTBHSHogMi41MEdIeiAvIFJBTSA4LjAwR0IgLyBv cGVuU1VTRTEzLjIgNjRiaXQuPGJyPjxicj5jaGFjaGEyMC1wb2x5MTMwNSBbaV06PGJyPjxicj5i bG9jayBzaXplIFtieXRlXcKgwqAgdGhyb3VnaHB1dCBba2J5dGVzL3NlY108YnI+wqDCoMKgwqDC oCAxNsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgMzEsNTg2LjgzPGJyPsKgwqDCoMKgwqAg NjTCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAxMDEsNTgwLjE0PGJyPsKgwqDCoMKgIDI1NsKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDE4OCw2MTQuOTM8YnI+wqDCoMKgIDEwMjTCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoCAyNDgsNzU2LjU3PGJyPsKgwqDCoCA4MTkywqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqAgMjcyLDIzMS4wODxicj48YnI+a2MyLXBvbHkxMzA1IFtpXTo8YnI+PGJy PmJsb2NrIHNpemUgW2J5dGVdwqDCoCB0aHJvdWdocHV0IFtrYnl0ZXMvc2VjXTxicj7CoMKgwqDC oMKgIDE2wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAxNiw5MzguMTA8YnI+wqDCoMKgwqDC oCA2NMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgNTQsNjc5LjUxPGJyPsKgwqDCoMKgIDI1 NsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDE1Niw3OTguMzA8YnI+wqDCoMKgIDEwMjTCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAyOTQsODY3Ljk3PGJyPsKgwqDCoCA4MTkywqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqAgMzg4LDc0My4xNzxicj48YnI+KDIpIGluIGNhc2UgW2tdIGVudmly b25tZW50OiB3aXRoIEludGVsKFIpIENvcmUoVE0pIGk3LTQ3NzBLPGJyPsKgwqDCoCAzLjUwR0h6 IC8gSG9zdCBPUzogV2luZG93cyA3IDY0Yml0IHdpdGggMzJHQiAvIEd1ZXN0IE9TOjxicj7CoMKg wqAgVWJ1bnR1IDE0LjEwIDY0Yml0IHdpdGggN0dCIC8gZ2NjIDQuOS4xPGJyPjxicj5jaGFjaGEy MC1wb2x5MTMwNSB3aXRoIG5vLVNJTUQgW2tdOjxicj48YnI+YmxvY2sgc2l6ZSBbYnl0ZV3CoMKg IHRocm91Z2hwdXQgW2tieXRlcy9zZWNdPGJyPsKgwqDCoMKgwqAgMTbCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgIDUxLDcwNC40NDxicj7CoMKgwqDCoMKgIDY0wqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqAgMTczLDkxOC44NTxicj7CoMKgwqDCoCAyNTbCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoCA0MDMsODc4LjI3PGJyPsKgwqDCoCAxMDI0wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg NjE2LDIzMi42Mjxicj7CoMKgwqAgODE5MsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDcyMSw4 MTAuNzc8YnI+PGJyPmtjMi1wb2x5MTMwNSBba106PGJyPjxicj5ibG9jayBzaXplIFtieXRlXcKg wqAgdGhyb3VnaHB1dCBba2J5dGVzL3NlY108YnI+wqDCoMKgwqDCoCAxNsKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqAgMzAsMzM4LjU1PGJyPsKgwqDCoMKgwqAgNjTCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoCAxMDEsMDYzLjE1PGJyPsKgwqDCoMKgIDI1NsKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgIDI4NCwzNDAuODI8YnI+wqDCoMKgIDEwMjTCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oCA1NDQsODM3LjYzPGJyPsKgwqDCoCA4MTkywqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgNzM2 LDMyNy4wMDxicj48YnI+WW9zaGlha2kgSG9yaTxicj48YnI+PC9kaXY+DQo= --001a113d42f488521a05238f19d7-- From nobody Mon Nov 2 06: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 7F8701B372C for ; Mon, 2 Nov 2015 06:23:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.624 X-Spam-Level: ** X-Spam-Status: No, score=2.624 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, FM_FRM_RN_L_BRACK=0.545, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8Z07KHOEJCp for ; Mon, 2 Nov 2015 06:23:00 -0800 (PST) Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-sg2apc01on0092.outbound.protection.outlook.com [104.47.125.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DA4B1B372B for ; Mon, 2 Nov 2015 06:23:00 -0800 (PST) Received: from OS2PR01MB0265.jpnprd01.prod.outlook.com (10.161.78.20) by OS2PR01MB0266.jpnprd01.prod.outlook.com (10.161.78.21) with Microsoft SMTP Server (TLS) id 15.1.312.18; Mon, 2 Nov 2015 14:22:57 +0000 Received: from OS2PR01MB0265.jpnprd01.prod.outlook.com ([10.161.78.20]) by OS2PR01MB0265.jpnprd01.prod.outlook.com ([10.161.78.20]) with mapi id 15.01.0312.014; Mon, 2 Nov 2015 14:22:56 +0000 From: =?iso-2022-jp?B?GyRCS1khIU5JPjQbKEI=?= To: "tls@ietf.org" Thread-Topic: Revised I-D: Use of KCipher-2 with Poly1305 in Transport Layer Security (draft-kiyomoto-kcipher2-tls-02) Thread-Index: AQHRFXnDOk9PA9dgkk6T9eRe4aO8lg== Date: Mon, 2 Nov 2015 14:22:55 +0000 Message-ID: Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=horiyo@cc.saga-u.ac.jp; x-originating-ip: [25.161.74.132] x-microsoft-exchange-diagnostics: 1; OS2PR01MB0266; 5:03vg36nU9wLIaZRAJ7KEijI+ZR8tHFXhzmGZqb+5Y0vuLNserxTeD48pjjmoQsaKZSNj1dW+blC2uLRb17mkyINu2fxgPbJSX4ieNoTLQPdlaDWnZn6TB2Nts+8iXQWo8cdtR25XKajeItEEk2CTpQ==; 24:FHDd//TobGzP0+33Jq5h0KlP6D21o5gdty5kcxlKXXfFodUbPhpfSZqRL0xHH5hEw7d4d7Lr8+t69rZxMei7BWIwuopEDbAXTROF+2DSjNM=; 20:fKFlXyh109EJNR4k72vcW+IGKs2Q/6tBAa5/1/J4Cixz26CSb9QmubSyI05PEaVursN5BGMdi9HEjA7EBqPR4g== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:OS2PR01MB0266; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(2401047)(8121501046)(520078)(5005006)(10201501046)(3002001); SRVR:OS2PR01MB0266; BCL:0; PCL:0; RULEID:; SRVR:OS2PR01MB0266; x-forefront-prvs: 0748FF9A04 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(377424004)(33656002)(86362001)(19580395003)(50986999)(40100003)(5008740100001)(5004730100002)(15975445007)(2351001)(122556002)(76576001)(450100001)(106116001)(54356999)(105586002)(106356001)(230783001)(74482002)(101416001)(102836002)(2900100001)(5001920100001)(92566002)(77096005)(5002640100001)(107886002)(85182001)(19580405001)(229853001)(110136002)(66066001)(5003600100002)(5007970100001)(5001960100002)(10400500002)(189998001)(87936001)(74316001)(97736004)(81156007)(2501003); DIR:OUT; SFP:1102; SCL:1; SRVR:OS2PR01MB0266; H:OS2PR01MB0265.jpnprd01.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; received-spf: None (protection.outlook.com: cc.saga-u.ac.jp does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: cc.saga-u.ac.jp X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2015 14:22:55.3823 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9e322ff5-bedd-42ec-a4b8-c80881b42ab8 X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS2PR01MB0266 Archived-At: Subject: [TLS] Revised I-D: Use of KCipher-2 with Poly1305 in Transport Layer Security (draft-kiyomoto-kcipher2-tls-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, 02 Nov 2015 14:23:02 -0000 Hi, We've posted a new version of "Use of KCipher-2 with Poly1305 in Transport Layer Security" (draft-kiyomoto-kcipher2-tls-02) that address to add a cipher suite, KCipher-2 [RFC7008] and Poly1305 running with AEAD for TLS1.2. Name: draft-kiyomoto-kcipher2-tls Revision: 02 Title: Use of KCipher-2 with Poly1305 in Transport Layer Security Document date: 2015-11-01 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-kiyomoto-kcipher2-tls-02.txt Status: https://datatracker.ietf.org/doc/draft-kiyomoto-kcipher2-tls/ Htmlized: https://tools.ietf.org/html/draft-kiyomoto-kcipher2-tls-02 Diff: https://www.ietf.org/rfcdiff?url2=3D3Ddraft-kiyomoto-kcipher2-tls-02 Abstract: This document describes the use of the KCipher-2 stream cipher with Poly1305 in Transport Layer Security (TLS) protocols version 1.2 and Datagram Transport Layer Security (DTLS) protocols. KCipher-2 is a stream cipher with a 128-bit key and a 128-bit initialization vector, which provides fast, efficient encryption and decryption. We address alternative stream cipher suite for TLS because we concern a risk of single stream cipher suite, Chacha20 with Poly1305. Our colleague is preparing KCipher-2 with Poly1305 code based on openssl-1.0.2 which will be available as an open source soon. The current Kcipher-2 with Poly1305 implementation can run with around 60% or more throughput comparing with Chacha20-Poly1305 under a small block size, e.g. 16 bytes and 64 bytes. We expect performance improvement with further optimization because the current code development in an early stage. We have tentative two performance reports run with different environment, which are indicated with [i] and [k] respectively. The case [i] is running with Intel(R) Core(TM) i5-4300U CPU@1.90GHz 2.50GHz / RAM 8.00GB / openSUSE13.2 64bit. Also, the case [k] is with Intel(R) Core(TM) i7-4770K 3.50GHz / Host OS: Windows 7 64bit with 32GB / Guest OS: Ubuntu 14.10 64bit with 7GB / gcc 4.9.1. Performance Results: (1) in case [i] environment: with Intel(R) Core(TM) i5-4300U CPU@1.90GHz 2.50GHz / RAM 8.00GB / openSUSE13.2 64bit. chacha20-poly1305 [i]: block size [byte] throughput [kbytes/sec] 16 31,586.83 64 101,580.14 256 188,614.93 1024 248,756.57 8192 272,231.08 kc2-poly1305 [i]: block size [byte] throughput [kbytes/sec] 16 16,938.10 64 54,679.51 256 156,798.30 1024 294,867.97 8192 388,743.17 (2) in case [k] environment: with Intel(R) Core(TM) i7-4770K 3.50GHz / Host OS: Windows 7 64bit with 32GB / Guest OS: Ubuntu 14.10 64bit with 7GB / gcc 4.9.1 chacha20-poly1305 with no-SIMD [k]: block size [byte] throughput [kbytes/sec] 16 51,704.44 64 173,918.85 256 403,878.27 1024 616,232.62 8192 721,810.77 kc2-poly1305 [k]: block size [byte] throughput [kbytes/sec] 16 30,338.55 64 101,063.15 256 284,340.82 1024 544,837.63 8192 736,327.00 Yoshiaki Hori From nobody Mon Nov 2 06:27: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 656D21B373A for ; Mon, 2 Nov 2015 06:27:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4BXJ-2YkopQ for ; Mon, 2 Nov 2015 06:27:53 -0800 (PST) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D0811B373E for ; Mon, 2 Nov 2015 06:27:53 -0800 (PST) Received: by wijp11 with SMTP id p11so52739379wij.0 for ; Mon, 02 Nov 2015 06:27:52 -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=U2N6iQV9LFF5UlqUoAtIofKmZkvnrwa8QSB8ky7mI9w=; b=ocj19FVM5pd+Z72hIRfjjoILP//kWUmffImAokYJ0HiUWaVUw6ks8g+zpe/erDMHcT 6PSgt0xWvZ5iLBS6xF8MV5ozb0GBPtQ+Fa6a9WbzrHd9vyklVtEtcQTvY1GUmyQQiazR WmSFzVfYY8gdPpV6vOPWc1Ui3jye+JBYQ7YJpyCp6CtLbDWrbrkJOJaadXHwWwed7wmA 3iU99gTyTQD/6Wmb2Pua1oHxpUimJHR6SWwbJcSo8UjpQecLg/KWRsk/qMTjR+0Nhfyk 0C7II/Y5uv19tm3huODYBJkjMn4vMaNfZ6fdcREF6NfT3tu629ozhNQMzUIISL0yNgMk Rc8w== MIME-Version: 1.0 X-Received: by 10.194.203.101 with SMTP id kp5mr22804362wjc.64.1446474472225; Mon, 02 Nov 2015 06:27:52 -0800 (PST) Received: by 10.28.101.212 with HTTP; Mon, 2 Nov 2015 06:27:52 -0800 (PST) Date: Mon, 2 Nov 2015 09:27:52 -0500 Message-ID: From: Watson Ladd To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] AES-GCM and ChaCha-Poly1305: how many bytes are safe? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 14:27:55 -0000 Dear all, All modes have a limit on how much data can be encrypted before bad things start to happen, i.e. IND-$ becoming false, or authenticity becoming false. In this email I will discuss what those limits are for AES-GCM and ChaCha20-Poly1305, assuming the usual assumptions about the ciphers: that is PRP for AES and PRF for ChaCha20. These limits are due to Iwata et. al. and Bernstein. All I have done in this email is evaluate them carefully. We start by noting that TLS encrypts messages of at most 2^14 bytes, and so at most 2^16 16-byte blocks. This is a ridiculous overestimate, but it doesn't need to be tightened, as I will explain later. Bernstein proves general results on Carter-Wegman authenticators, found in http://cr.yp.to/papers.html#securitywcs. For these results a sender of 2^60 messages can tolerate 2^60 forgery attempts while the probability of forgery is at most 1.002/2^52. I think that's sufficient. These apply to AES-GCM. For ChaCha20-Poly1305 there is a different result where the number of messages does not appear, but only the length: this result gives a much stronger 1/2^87. This is due to generating a different authentication key for every nonce. ChaCha20 is a PRF. As a result we can go beyond the birthday bound, and send use all 2^96 messages. AES is a PRP. Therefore there is a quadratic security loss, and the result from Iwata-Ohashai-Minematsu states the probability of success is upper bounded by (s+q+1)^2/2^127, where s is the total number of blocks encrypted and q the number of queries made by the attacker. The sum must therefore be below 2^32 to have the same level of security as the authenticator, and so we are limited to a total amount of encryption with a given key of 2^32 blocks, or 2^36 bytes. We could be slightly more aggressive, but cannot hit anywhere close to 2^64. Please double-check the above analysis, in particular the assumptions about how ChaCha20-Poly1305 actually works. I haven't dug up other recommendations to see if I got in the right ballpark. Sincerely, Watson From nobody Mon Nov 2 10:37:09 2015 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 951F71A036C; Mon, 2 Nov 2015 10:37:07 -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: 6.7.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151102183707.1577.79330.idtracker@ietfa.amsl.com> Date: Mon, 02 Nov 2015 10:37:07 -0800 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-falsestart-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 Nov 2015 18:37: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) False Start Authors : Adam Langley Nagendra Modadugu Bodo Moeller Filename : draft-ietf-tls-falsestart-01.txt Pages : 10 Date : 2015-11-02 Abstract: This document specifies an optional behavior of TLS client implementations, dubbed False Start. It affects only protocol timing, not on-the-wire protocol data, and can be implemented unilaterally. A TLS False Start reduces handshake latency to one round trip. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-falsestart/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tls-falsestart-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-falsestart-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 Mon Nov 2 11:59: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 EAF8E1A011C for ; Mon, 2 Nov 2015 11:59:33 -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, 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 ZfkDCpWkbiQa for ; Mon, 2 Nov 2015 11:59:32 -0800 (PST) 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 AAE5A1A00CE for ; Mon, 2 Nov 2015 11:59:32 -0800 (PST) Received: by obbwb3 with SMTP id wb3so104152851obb.0 for ; Mon, 02 Nov 2015 11:59:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith_org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DZrciXksHlCrg2L8yxlyF9McM97q+xNN21wuF0gO60Y=; b=FTJgF+MclNV7IO4Kh+4Br2y3ztlwFGfYtAMkNfWsJzmWvelGQGuejAH1g9WcZrs3rF eRQQV4DLdeyAEpoYNqbQpz14j/UQ9tOdsHDWMQFXi/+X3qryLf4EpIxWozmr66Z6osqG kcaizPEg+lg7XPLSh2M1KR6D/eS67QHsL+qmzwvQ6hL1jvaPAdyzDgnrH6vvpKqBqR3Y jj+G8VdcqqT/19FYNHqckUfSRGfbaJULckawZn2cHkq7m1zBw9ZkUizxRfzsp4adwfoB yCYzGacPa1dwkH+N+BDM6JZTdkNlcNrlhG+jWntFa5PshQQ9zl725HSEjnjZQbFs4u8q yhCw== 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=DZrciXksHlCrg2L8yxlyF9McM97q+xNN21wuF0gO60Y=; b=Dm5GZ60kgkQipD7DiOUynxMfGxXeaiVh5EX3fhqah0iiJzFM53IPPl1/W7bwCd5wjN lsewQi2rDAAC3sI/ra3qzvmJxwXsWho2OE97o8+rVaoKf3DodWMgZ9Twt3AcOUfw3Y2y VkL/3a8o2XkOudERMnYj1AoeeGAs0oBYq7SfQJbWpr5iPFVJCOtU4J6Y034kTzSHr9RV 4HheJHYbOb87EwXxq8UiY/VBqPeQEbewnZpFhD3OW7dRhnzHzAJNbu2xl0FD5NmU/OXS hTbud8ElRuWQnJmrzB95CS1Mwhk2sWCvQSOy68L30qOKjGVTBk6UsNb9v6CEbIxCddit DKpA== X-Gm-Message-State: ALoCoQlvG1YeTvVVmCNzhjZcfGGf2XDM8UmUREQJKLv/xacRllvGAKFyY+IBZ5is3bCmI9voYaqq MIME-Version: 1.0 X-Received: by 10.182.130.234 with SMTP id oh10mr16311558obb.58.1446494371820; Mon, 02 Nov 2015 11:59:31 -0800 (PST) Received: by 10.76.44.145 with HTTP; Mon, 2 Nov 2015 11:59:31 -0800 (PST) In-Reply-To: References: Date: Mon, 2 Nov 2015 09:59:31 -1000 Message-ID: From: Brian Smith To: Watson Ladd Content-Type: multipart/alternative; boundary=089e013a011233d1a105239437fa Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] AES-GCM and ChaCha-Poly1305: how many bytes are safe? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 19:59:34 -0000 --089e013a011233d1a105239437fa Content-Type: text/plain; charset=UTF-8 Watson Ladd wrote: > For these results a > sender of 2^60 messages can tolerate 2^60 forgery attempts while the > probability of forgery is at most 1.002/2^52. TLS only allows one forgery attempt per connection (thus per key). That is, as soon as a TLS implementation fails to verify a record's authentication tag, it must shut down the connection. Thus, it would be more useful to state the analysis as "Observing X signed records over Y bytes increases the odds of the attacker forging the next record to Z." Cheers, Brian -- https://briansmith.org/ --089e013a011233d1a105239437fa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Wats= on Ladd <watsonbladd@gmail.com> wrote:
For these results a
sender of 2^60 messages can tolerate 2^60 forgery attempts while the
probability of forgery is at most 1.002/2^52.

TLS only allows one forgery attempt per connection (thus per key). That = is, as soon as a TLS implementation fails to verify a record's authenti= cation tag, it must shut down the connection. Thus, it would be more useful= to state the analysis as "Observing X signed records over Y bytes inc= reases the odds of the attacker forging the next record to Z."

Cheers,
Brian
--
--089e013a011233d1a105239437fa-- From nobody Mon Nov 2 12:00: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 935831B3841; Mon, 2 Nov 2015 12:00:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Soscch1TwmLR; Mon, 2 Nov 2015 12:00:41 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0111.outbound.protection.outlook.com [207.46.100.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 765A81B37E7; Mon, 2 Nov 2015 12:00:29 -0800 (PST) Received: from BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) by BN1PR09MB121.namprd09.prod.outlook.com (10.255.200.145) with Microsoft SMTP Server (TLS) id 15.1.312.18; Mon, 2 Nov 2015 20:00:28 +0000 Received: from BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) by BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) with mapi id 15.01.0312.014; Mon, 2 Nov 2015 20:00:27 +0000 From: "Dang, Quynh" To: Watson Ladd Thread-Topic: [Cfrg] Collision issue in ciphertexts. Thread-Index: AQHRFT3/uhvieo6mr0iE/9qPshn2sZ6IgieAgACWb8s= Date: Mon, 2 Nov 2015 20:00:27 +0000 Message-ID: References: <811734cd29d64adc98c5388870611575@XCH-ALN-004.cisco.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-originating-ip: [129.6.220.229] x-microsoft-exchange-diagnostics: 1; BN1PR09MB121; 5:OpWbHUgnlejUIJ5h5ILIkOr8mI/mu/Tcjhtac8HG2TxLCK6uaOFuWNjYQqtp5k1gXba9LTyQZJI1sYIVgVbIcV5KVLJzc+xSG922vqrtU2A1p8PYIxnC3jMCKnW1JwiAOuO8W7dt9Hnh2yWp3JkyrQ==; 24:ffEP0CCn2hmMWc52NxtIIh55Xdcp9N8CBGCW7O7N7OrQlyKXTPWWQv5RpxnDR8C8Dds3aNp+aojZpYBegCCsoXMc6RNbSJt7I3q2tP0wiWI=; 20:B+22/OkNQh4zQxTFcCYgE0a6/NxtwcolKmLHd5gWrtqwgJ+yugbQm+Mz6yYZ5kUSSYfeadPS8yKs97a42XhDIA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB121; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(10201501046)(3002001); SRVR:BN1PR09MB121; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB121; x-forefront-prvs: 0748FF9A04 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(199003)(189002)(377454003)(19580405001)(2900100001)(76576001)(5001960100002)(19627405001)(106356001)(105586002)(15975445007)(10400500002)(93886004)(122556002)(5002640100001)(110136002)(40100003)(106116001)(102836002)(189998001)(19617315012)(86362001)(5004730100002)(5001920100001)(97736004)(16236675004)(66066001)(74316001)(92566002)(33656002)(87936001)(5008740100001)(76176999)(50986999)(54356999)(77096005)(1411001)(2950100001)(19625215002)(5007970100001)(101416001)(5003600100002)(99286002)(81156007)(19580395003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB121; H:BN1PR09MB124.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN1PR09MB124B270CE55528F10656DECF32C0BN1PR09MB124namprd_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2015 20:00:27.6787 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB121 Archived-At: Cc: "cfrg@ietf.org" , "tls@ietf.org" Subject: Re: [TLS] [Cfrg] Collision issue in ciphertexts. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 20:00:45 -0000 --_000_BN1PR09MB124B270CE55528F10656DECF32C0BN1PR09MB124namprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Now, you talked about a MAC function (with AES). I previously talked about = encryption. If I , the only person, uses the MAC key, when I generate more than 2^64 MA= C values (Let's say each MAC value is 96 bits), I have many collided MAC pa= irs. But, I am the only one (beside the person(s) verifying my MACs) who kn= ows the MAC key in order to generate those verified MAC values. If the MAC length is k bits, an attacker is allowed to send 2^n failed veri= fications, his or her chance of success is approximately 2^n / 2^k. Let's i= magine n is 64 and k is 96, the success chance is 1/2^36 which is practical= ly ZERO! If I am an attacker, I would choose a message that I want to be verified, a= nd I keep changing the MAC key to generate different MAC values with differ= ent keys and hope one of them will get verified. Let's assume the MAC key = to be 96 bits ( 96 bits of random bits, the other 32 bits are known). In th= eory, when I get close to 2^96 attempts, I would expect some chance of succ= ess. To deal with this attacker, one would change the MAC key when the numb= er of failed attempts gets close to a number that you don't want. For examp= le, if you don't want a success chance of an attack to be above 1 / 2^36, t= hen you need to change your MAC key when the number of failed verifications= reaches 2^64 when your MAC length is 96 bits. After you change the MAC key, I ( the attacker) will have to start everythi= ng again because all of the failed MACs I generated before are useless now. ________________________________ From: Watson Ladd Sent: Monday, November 2, 2015 5:07 AM To: Dang, Quynh Cc: tls@ietf.org; cfrg@ietf.org; Eric Rescorla Subject: Re: [Cfrg] Collision issue in ciphertexts. On Nov 2, 2015 2:14 AM, "Dang, Quynh" > wrote: > > Hi Eric, > > > As you asked the question about how many ciphertext blocks should be safe= under a single key, I think it is safe to have 2^96 blocks under a given k= ey if the IV (counter) is 96 bits. This is wrong for PRP, right for PRF. It's not that hard to find the right = result. > > > When there is a collision between two ciphertext blocks when two differen= t counter values are used , the chance of the same plaintext was used twice= is 1^128. Collisions start to happen a lot when the number of ciphertext = blocks are above 2^64. However, each collision just reveals that the corres= ponding plaintext blocks are probably different ones. Which breaks IND-$. Let's not be clever, but stick to ensuring proven defin= itions are true. > > > > Quynh. > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > --_000_BN1PR09MB124B270CE55528F10656DECF32C0BN1PR09MB124namprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Now, you talked about a MAC function (with AES). I previously talke= d about encryption. 


If I , the only person, uses the MAC key, when I generate more than 2^64= MAC values (Let's say each MAC value is 96 bits), I have many collided MAC= pairs. But, I am the only one (beside the person(s) verifying my MACs)&nbs= p;who knows the MAC key in order to generate those  verified MAC values.


If the MAC length is k bits, an attacker is allowed to send 2^= n failed verifications, his or her chance of success is approximately = 2^n / 2^k. Let's imagine n is 64 and k is 96, the success chance is 1/2^36 = which is practically ZERO! 


If I am an attacker, I would choose a message that I want to be ver= ified, and I keep changing the MAC key to generate different MAC values wit= h different keys and hope one of them will get verified.  Let's assume= the MAC key to be 96 bits ( 96 bits of random bits, the other 32 bits are known). In theory, when I get close to 2^96 at= tempts, I would expect some chance of success. To deal with this attac= ker, one would change the MAC key when the number of failed attempts gets c= lose to a number that you don't want. For example, if you don't want a success chance of an attack to be ab= ove 1 / 2^36, then you need to change your MAC key when the number of faile= d verifications reaches 2^64 when your MAC length is 96 bits. 


After you change the MAC key, I ( the attacker) will have to start = everything again because all of the failed MACs I generated before are usel= ess now. 


From: Watson Ladd <watso= nbladd@gmail.com>
Sent: Monday, November 2, 2015 5:07 AM
To: Dang, Quynh
Cc: tls@ietf.org; cfrg@ietf.org; Eric Rescorla
Subject: Re: [Cfrg] Collision issue in ciphertexts.
 


On Nov 2, 2015 2:14 AM, "Dang, Quynh" <quynh.dang@nist.gov> wrote:
>
> Hi Eric,
>
>
> As you asked the question about how many ciphertext blocks should be s= afe under a single key, I think it is safe to have 2^96 blocks under a give= n key if the IV (counter) is 96 bits. 

This is wrong for PRP, right for PRF. It's not that hard to = find the right result.

>
>
> When there is a collision between two ciphertext blocks when two diffe= rent counter values are used , the chance of the same plaintext was used tw= ice is 1^128.  Collisions start to happen a lot when the number o= f ciphertext blocks are above 2^64. However, each collision just reveals that the corresponding plaintext blocks a= re probably different ones. 

Which breaks IND-$. Let's not be clever, but stick to ensuri= ng proven definitions are true.

>
>
>
> Quynh. 
>
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irt= f.org/mailman/listinfo/cfrg
>

--_000_BN1PR09MB124B270CE55528F10656DECF32C0BN1PR09MB124namprd_-- From nobody Mon Nov 2 14:06:20 2015 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E6F2E1A8886; Mon, 2 Nov 2015 14:06:17 -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: 6.7.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151102220617.22528.91021.idtracker@ietfa.amsl.com> Date: Mon, 02 Nov 2015 14:06:17 -0800 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-chacha20-poly1305-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 Nov 2015 22:06: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 : ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS) Authors : Adam Langley Wan-Teh Chang Nikos Mavrogiannopoulos Joachim Strombergson Simon Josefsson Filename : draft-ietf-tls-chacha20-poly1305-01.txt Pages : 7 Date : 2015-11-02 Abstract: This document describes the use of the ChaCha stream cipher and Poly1305 authenticator in the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-chacha20-poly1305/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tls-chacha20-poly1305-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-chacha20-poly1305-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 Mon Nov 2 14:12: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 438921A88C5 for ; Mon, 2 Nov 2015 14:12:37 -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 HF4nM-IhCVRB for ; Mon, 2 Nov 2015 14:12:35 -0800 (PST) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::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 9D8DC1A88C1 for ; Mon, 2 Nov 2015 14:12:35 -0800 (PST) Received: by qkcl124 with SMTP id l124so60853782qkc.3 for ; Mon, 02 Nov 2015 14:12:34 -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:content-type; bh=h0ij8+WzDMwyxd3h7UTSdc8tZDf8aYExZVhfTXCXADQ=; b=xUeDT05T1FhQ65Eev9E54V2i7+KzVgvCiDftxzGh2n5QdlmYfWjtCJj2Jk0XL5W8G8 T0kOwvQ4+rNZPfNatZSo3oSqyZdXcaWElG9XtLd/NSiDhRbpTE5drFvjuh0jpYf3v617 W5qd71K4jvNpqab+i63OP6UnNePL4lFMyt5fiI1qhULxXb93A3W6fAkyAV97tc2ZDjdH b+QfYd6dFgNhrjbiRadL8+2JBLIBLbwS9K1iiXUdNKgXVTTtPQnomtrW+3dNQWlE13d/ Ac25FfxaTwRyEBj/FA3t/YG320jsBqEjrmbbvbbyXCvo1ujtdLexDqvAgbj3i/vD5DEv CN2A== MIME-Version: 1.0 X-Received: by 10.55.71.146 with SMTP id u140mr31993757qka.17.1446502354678; Mon, 02 Nov 2015 14:12:34 -0800 (PST) Sender: alangley@gmail.com Received: by 10.140.81.241 with HTTP; Mon, 2 Nov 2015 14:12:34 -0800 (PST) In-Reply-To: <20151102220617.22528.91021.idtracker@ietfa.amsl.com> References: <20151102220617.22528.91021.idtracker@ietfa.amsl.com> Date: Mon, 2 Nov 2015 14:12:34 -0800 X-Google-Sender-Auth: OOQuByO5ujQ-TJ5QMgOLn-gb7Us Message-ID: From: Adam Langley To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-chacha20-poly1305-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: Mon, 02 Nov 2015 22:12:37 -0000 On Mon, Nov 2, 2015 at 2:06 PM, wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Transport Layer Security Working Group of the IETF. > > Title : ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS) > Authors : Adam Langley > Wan-Teh Chang > Nikos Mavrogiannopoulos > Joachim Strombergson > Simon Josefsson > Filename : draft-ietf-tls-chacha20-poly1305-01.txt > Pages : 7 > Date : 2015-11-02 > > Abstract: > This document describes the use of the ChaCha stream cipher and > Poly1305 authenticator in the Transport Layer Security (TLS) and > Datagram Transport Layer Security (DTLS) protocols. Dear all, I've submitted the above version of the ChaCha20-Poly1305 draft in the hopes of getting consensus that it's basically what the group wants and thus is suitable for early code-point assignment. The major change in this version is that the nonce is constructed using the scheme that's currently in TLS 1.3. To recap: AES-GCM in TLS 1.2 uses a four-byte, fixed nonce fragment with an explicit, eight-byte value from the wire appended. ChaCha20-Poly1305 seeks to eliminate these eight bytes in each record by using the TLS sequence number. (On this I believe that we basically have agreement.) The TLS 1.3 spec already specifies that AEADs use the sequence number and has a construction where a fixed value (from the handshake output) is XORed with it. (See https://tlswg.github.io/tls13-spec/#record-payload-protection.) This draft apes that in the hopes that the TLS 1.3 construction doesn't change before its final. Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Mon Nov 2 14:25: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 5F96F1A895D for ; Mon, 2 Nov 2015 14:25:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTP2BCTMTvXv for ; Mon, 2 Nov 2015 14:25:12 -0800 (PST) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e: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 5CA8E1A895B for ; Mon, 2 Nov 2015 14:25:12 -0800 (PST) Received: by pabfh17 with SMTP id fh17so36754287pab.0 for ; Mon, 02 Nov 2015 14:25:12 -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=idswG0313ruo7m8o0D/oC/FBSW/vbL3GCAoFtCaRtho=; b=wRJc+M/tc9Tvmm0XNU0aoNKfkJv0KMN5YBb+hn2Vq/L97KSq42TPeD9LOswzi3nXBo AF1/7enzCA1SHyj7vtiQhHfyvT/5M/QPJaUgh1vOoPRS2rTw1GtwV/OwaLkXbBxRsl41 FETr6O0Y/BjGgJw73LPUVbfc3qdhglY1hCdkNj4BVhzuAf7coxcmCZdIqXX0xZA/3nQs NlDMKI3hH146ewhIi1Ud+WbOa0SLuuwnNWy4xfWUiccxw3Ztja7zR80lDO0NMuyug62n F8Aq6if+yR+WEQ6RJ89SvqA1CoigwDKE81bLXbK7ztEerjaKcWRTZN40qa+OfGyPCa4g zd4g== X-Received: by 10.68.182.34 with SMTP id eb2mr29361876pbc.87.1446503112055; Mon, 02 Nov 2015 14:25:12 -0800 (PST) Received: from [10.11.2.214] (y125063.ppp.asahi-net.or.jp. [118.243.125.63]) by smtp.gmail.com with ESMTPSA id sn9sm25938939pac.16.2015.11.02.14.25.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Nov 2015 14:25:10 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_13D54DC5-A93E-435A-AC43-E400A1C73EE0" Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Yoav Nir In-Reply-To: Date: Tue, 3 Nov 2015 07:25:07 +0900 Message-Id: References: To: Brian Smith X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] AES-GCM and ChaCha-Poly1305: how many bytes are safe? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 22:25:13 -0000 --Apple-Mail=_13D54DC5-A93E-435A-AC43-E400A1C73EE0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 3 Nov 2015, at 4:59 AM, Brian Smith wrote: >=20 > Watson Ladd > = wrote: > For these results a > sender of 2^60 messages can tolerate 2^60 forgery attempts while the > probability of forgery is at most 1.002/2^52. >=20 > TLS only allows one forgery attempt per connection (thus per key). = That is, as soon as a TLS implementation fails to verify a record's = authentication tag, it must shut down the connection. Thus, it would be = more useful to state the analysis as "Observing X signed records over Y = bytes increases the odds of the attacker forging the next record to = Z.=E2=80=9D That is true for TLS, but not for DTLS, so I guess we have to state it = both ways. Yoav --Apple-Mail=_13D54DC5-A93E-435A-AC43-E400A1C73EE0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 3 Nov 2015, at 4:59 AM, Brian Smith <brian@briansmith.org> wrote:

Watson = Ladd <watsonbladd@gmail.com> wrote:
For these results a
sender of 2^60 messages can tolerate 2^60 forgery attempts while the
probability of forgery is at most 1.002/2^52.

TLS only allows one = forgery attempt per connection (thus per key). That is, as soon as a TLS = implementation fails to verify a record's authentication tag, it must = shut down the connection. Thus, it would be more useful to state the = analysis as "Observing X signed records over Y bytes increases the odds = of the attacker forging the next record to = Z.=E2=80=9D

That is true for TLS, but not for DTLS, so I guess = we have to state it both ways.

Yoav


= --Apple-Mail=_13D54DC5-A93E-435A-AC43-E400A1C73EE0-- From nobody Mon Nov 2 15:02: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 999F01A8AEC for ; Mon, 2 Nov 2015 15:02:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, 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 a2RXweYhgywR for ; Mon, 2 Nov 2015 15:02:03 -0800 (PST) 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 F3A531A8AE9 for ; Mon, 2 Nov 2015 15:02:02 -0800 (PST) Received: by obbwb3 with SMTP id wb3so107903326obb.0 for ; Mon, 02 Nov 2015 15:02:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith_org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=muR8+GjAr1KjWNhKneIFlCGGuhF+F1NBHJkexQuIHJw=; b=bFpw2YYY8DRUhCgESffUMBOK2jd1GEVU6/JmWk53VgRiCxi+pgVqASJYf3ovgabkus X309cw0psxA7nugQ2BfUWjzViM0DQmpjN2UaIXMohXRGwLyOHT73JS1/57FE2ZaQU3at jRWiW071Kor0CYSwFrBb7fK9eCNef1mfXlgDAOp+poeCFSJ+mK1MXdcirxBld0Rbu9GG ktbZwospXBfPYhc+/M/BfrwX5R2+2pGSPe01PR8hoWeh1Jb5jpypt0QtRTR91fQOjlvZ JODn/4lF8sJC4wTDUwuuH/920w9pODCLJyBHk/teTAncQipB2wKmfbvNL39fLWBHxMZT e7+A== 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=muR8+GjAr1KjWNhKneIFlCGGuhF+F1NBHJkexQuIHJw=; b=f1Db/wAcZ9IR8xV2pL8u5TQHMoZdxk8ooqRFYTIIWJMbtjglfX23ylPlTCV+sE912P rCk/J4NpBfsgp+OGfo+lQ59C4JI0rnUmFqP1wBVYGMj+8KOEcithQ/RKwBdq2B1kzXge cgHytFM/5EGb9hTfn84mibVn2JT49jnLVK3MO87e5J6Cq/pYj47ONHKHO/DuS1354jzq uVJ6966A+LWbIWPKx7eFBoPoCGKA/56WooIwTMKdnGAYleiKuygF9z0vK0DzF9mcroX1 pjgr5/unA0tj1UTTTLvS8eagJrJIQpDgu4kcIrd3DJRTG5pwodfsLPVqlr6nV0/6N/e2 vF3w== X-Gm-Message-State: ALoCoQn9zXn6ZSMY3dhafCpg9PwjNTlrEzmWwUU4N6WX/nzICi4+KBJoFg1m33j0w3Ci9kB6jwqh MIME-Version: 1.0 X-Received: by 10.60.70.40 with SMTP id j8mr16000382oeu.78.1446505322220; Mon, 02 Nov 2015 15:02:02 -0800 (PST) Received: by 10.76.44.145 with HTTP; Mon, 2 Nov 2015 15:02:02 -0800 (PST) In-Reply-To: References: <20151102220617.22528.91021.idtracker@ietfa.amsl.com> Date: Mon, 2 Nov 2015 13:02:02 -1000 Message-ID: From: Brian Smith To: Adam Langley Content-Type: multipart/alternative; boundary=001a11330ab4e5a6f1052396c341 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] I-D Action: draft-ietf-tls-chacha20-poly1305-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: Mon, 02 Nov 2015 23:02:04 -0000 --001a11330ab4e5a6f1052396c341 Content-Type: text/plain; charset=UTF-8 Adam Langley wrote: > The major change in this version is that the nonce is constructed > using the scheme that's currently in TLS 1.3. > Would it be possible to do something similar for the additional data, so that there is no additional data in TLS 1.2, just like in TLS 1.3 for application_data records? This is the TLS 1.2 definition of additional_data is: additional_data = seq_num + TLSCompressed.type + TLSCompressed.version + TLSCompressed.length; In particular, I think we could define the cipher suite to preprocess the AAD so that if it were equal to this: (seq_num XOR client_write_iv)[4..] || 23 || 3 || 3 || HI(len) || LO(len) then the AAD could be replaced with zero bytes of AAD; otherwise, the AAD be equal to the input AAD. In other words, compress the AAD with a very simple function prior to passing it to the RFC 7539 chacha20-poly1305 AEAD function. This way, one Poly1305 invocation per record could be saved, potentially, for application_data records, which is the common case. An implementation that avavoids sending encrypted alerts and avoids renegotiation could avoid writing code for the case where non-empty AAD is needed, and could share the exact same code between TLS 1.2 and TLS 1.3 for ChaCha20-Poly1305. Cheers, Brian -- https://briansmith.org/ --001a11330ab4e5a6f1052396c341 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Adam= Langley <agl@imperialviolet.org> wrote:
The major change in this version is that the nonce is constructed
using the scheme that's currently in TLS 1.3.

=
Would it be possible to do something similar for the additional = data, so that there is no additional data in TLS 1.2, just like in TLS 1.3 = for application_data records?

This is the TLS 1.2 = definition of additional_data is:

    additional_data =3D seq_num=C2=A0 +
                  =
    TLSCompressed.type +
                      TLSCompressed.version +
TLSCompre= ssed.length;

=

In parti=
cular, I think we could define the cipher suite to preprocess the AAD so th=
at if it were equal to this:

     (seq_num XOR client_write_iv)[4..] || 23 || 3 || 3 || =
HI(len) || LO(len)

then the =
AAD could be replaced with zero bytes of AAD; otherwise, the AAD be equal t=
o the input AAD. In other words, compress the AAD with a very simple functi=
on prior to passing it to the RFC 7539 chacha20-poly1305 AEAD function.
Th=
is way, one Poly1305 invocation per record could be saved, potentially, for=
 application_data records, which is the common case. An implementation that=
 avavoids sending encrypted alerts and avoids renegotiation could avoid wri=
ting code for the case where non-empty AAD is needed, and could share the e=
xact same code between TLS 1.2 and TLS 1.3 for ChaCha20-Poly1305.

Cheers,
Brian
--
--001a11330ab4e5a6f1052396c341-- From nobody Mon Nov 2 16: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 3D2D31A92FC for ; Mon, 2 Nov 2015 16:26:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lClMlG7NXIOr for ; Mon, 2 Nov 2015 16:26:31 -0800 (PST) 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 020DD1A92F7 for ; Mon, 2 Nov 2015 16:26:31 -0800 (PST) Received: by ykdr3 with SMTP id r3so957342ykd.1 for ; Mon, 02 Nov 2015 16:26:30 -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=Go8WMuGn9ZACwL2tQ7E+j3DCGuh/KHDT1OAIAvF1xgY=; b=wkvM3vezdUEgJGHspy7uO1PNO2MAwtuP7FkCa05rPYpoYY+aT6GxDUOmzv66vKjUDH SrIWgycQs0ux8xj9MoBLVX3VqbkgJvz2iU0D8wA3Ftu6hxh3eogF5e+6BR+aeSaQYvDW rs+BMQmZ4zuYJbngd/FGxNiFqqNFLkI3+bk5a4smUae39w4WvfWT0WGC14jAIuUaHQ77 XXJiTXGMwEwUwZKwvO784EAm6UVBHVvdMAhkte61sZibLvV8p9oeoqUwJTI4ScnrEsQd vv5cLEpc27fGF7+bWZwLVMlnO3u+7ZVnuarlFsqtADbZvHJkLSfgNCozbGdC2x5xnkSi AlbQ== MIME-Version: 1.0 X-Received: by 10.129.79.132 with SMTP id d126mr18220892ywb.159.1446510390234; Mon, 02 Nov 2015 16:26:30 -0800 (PST) Received: by 10.129.132.145 with HTTP; Mon, 2 Nov 2015 16:26:30 -0800 (PST) In-Reply-To: References: <20151102220617.22528.91021.idtracker@ietfa.amsl.com> Date: Tue, 3 Nov 2015 09:26:30 +0900 Message-ID: From: Martin Thomson To: Brian Smith Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Adam Langley , "tls@ietf.org" Subject: Re: [TLS] I-D Action: draft-ietf-tls-chacha20-poly1305-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: Tue, 03 Nov 2015 00:26:32 -0000 On 3 November 2015 at 08:02, Brian Smith wrote: >> The major change in this version is that the nonce is constructed >> using the scheme that's currently in TLS 1.3. > > > Would it be possible to do something similar for the additional data, so > that there is no additional data in TLS 1.2, just like in TLS 1.3 for > application_data records? The construction in TLS 1.3 will have no AAD. I believe that the rationale is: seq_num is masked into the nonce TLSCompressed(sic).type is under encryption TLSCompressed.version is covered by key derivation via the handshake hash TLSCompressed.length was included in the AAD in 1.2 in error Unfortunately, I don't believe that all of the above is true for TLS 1.2. Your proposed construction covers some of these things. If you are willing to rely on session hash, you might drop the version, which leaves this with the type. We have to authenticate the content type somehow, and I like your hack for that. From nobody Mon Nov 2 23:55: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 72D591B2A79 for ; Mon, 2 Nov 2015 23:55:01 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 JnvrmikGfR-3 for ; Mon, 2 Nov 2015 23:54:59 -0800 (PST) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003: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 D476E1B29D1 for ; Mon, 2 Nov 2015 23:54:58 -0800 (PST) Received: by obbwb3 with SMTP id wb3so6516523obb.0 for ; Mon, 02 Nov 2015 23:54:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts_net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Cj9aIjBr1lflUEz6r83I/Bm5/W1pOM/6cLhuM4i3fZ0=; b=QBWNSK5sOwQlOtN1gcJWMBGgyJ0QYPW9dQsHd28M6ubbFIS1dlfN2tecy+OAm2sZKM jRgFSbC9sqE5vsrpA0OHqtCJGBGPPm2yAp6owXZo0Ouvvv/CLHyTuCkf0PdtToUu9PzM d9Voc0cq5hVahdM6x7Cf7b7qKfJMpHxfxqvjEbsu+631TeevgB/XvmS8ColmfiUSOs87 3ag7IBcOCqZcyPi58mbKtJu90KaVtGgjGbJ5q36hcqpJi+VN5H1ijHRb2QeAp5Nn+JyY U3GyYSH/zo2KhOno3PNy/PmmEjaB0aCif+2L11yWIbK+7hpMNBgvTv1mskm/49abe7L2 RoEA== 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=Cj9aIjBr1lflUEz6r83I/Bm5/W1pOM/6cLhuM4i3fZ0=; b=An5HEwM6XUaWiqZpLPC/khWnuAgyfDunq1JTdm/cvSSgzjDa1faHS3ric8j8SvrAk7 Q1GvJ76y4XveZUXGyL3vpW++nKHUGUZKjqFDTgrH6auWPY3b+vnEAOZcFKApuCyMZmbp tJOLt4T8FUmxYRpQohNwZzJC7gcqagbxxSk/vibHZaEiJawoVF/8RTGoWKMjZD+IRSY6 8/bKJ0Ju/T+c+0ZrcXip7CqWxvIwWnaPy5ZghhmJ9WHXUw+2o25zMF+bAm1qNvrn1H1C f6SgSD4eQRYlHpYc/swXwh0AtXux4DoL3hvxUWaun5YdSdaEJy40ZUH6R3pniFVy1w1c Uelw== X-Gm-Message-State: ALoCoQn7cusDxZ3at/u2cMUzzB1Wwd2iQkzTmRQ//dTyPiDja06BhFBinN0YAXpRqGZXtGiMLNxn MIME-Version: 1.0 X-Received: by 10.182.65.138 with SMTP id x10mr16905994obs.39.1446537298204; Mon, 02 Nov 2015 23:54:58 -0800 (PST) Received: by 10.76.10.8 with HTTP; Mon, 2 Nov 2015 23:54:58 -0800 (PST) In-Reply-To: References: <20151102220617.22528.91021.idtracker@ietfa.amsl.com> Date: Mon, 2 Nov 2015 23:54:58 -0800 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: Adam Langley Content-Type: multipart/alternative; boundary=001a11c1bb24d0721305239e3550 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] I-D Action: draft-ietf-tls-chacha20-poly1305-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: Tue, 03 Nov 2015 07:55:01 -0000 --001a11c1bb24d0721305239e3550 Content-Type: text/plain; charset=UTF-8 Huge +1 to this I-D, just some minor comments: * I wonder if the document should be more forthright in specifying that the ChaCha20/Poly1305 implementations SHOULD actually attempt to use constant-time and constant-access patterns that the algorithm is designed to facilitate. If that's a selling point then I wonder if it's worth being specific about that. On that point: I'm curious if those properties are implementable in a variety of languages, or if it requires near-assembly (e.g. C) levels of precision. If it's the latter, then I wonder if it's legitimate to include those selling points. * I think the statement "can be implemented easily without being vulnerable to software side-channel attacks" is too strong, unless one wants to really litigate what "software side-channels are". Unless I'm mistaken, as a stream cipher ChaCha20 is *more* vulnerable to a class of size-based side-channels than a block cipher would be. A simple form of attack would be to monitor connections to wikipedia and identify which pages a user is browsing; from observing just the size of requests and responses [*] it's pretty easy for an attacker to (offline) create a graph of HTML page sizes and the sizes of the images they load and then (in real time) to correlate things such that they can uniquely identify the page loaded. This attack is feasible with both stream and block ciphers, but it is far easier with a stream cipher. Similarly, the compressed map tiles attack that shows where an online maps user is browsing is much more effective with a stream cipher. [ http://blog.ioactive.com/2012/02/ssl-traffic-analysis-on-google-maps.html] These kinds of simple correlation attack are vastly more practical than the kinds of time and cache access side-channels that CBC verification is weak against. They are also inherently passive and undetectable. On the whole the I-D reads as if ChaCha20 is more side-channel resistant, but I think reasonable people could disagree about this - and it's worth some discussion in the security section. [*] Consider also that in the case of Wikipedia an attacker can control the size of a target page they may be interested in. On Mon, Nov 2, 2015 at 2:12 PM, Adam Langley wrote: > On Mon, Nov 2, 2015 at 2:06 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Transport Layer Security Working Group > of the IETF. > > > > Title : ChaCha20-Poly1305 Cipher Suites for Transport > Layer Security (TLS) > > Authors : Adam Langley > > Wan-Teh Chang > > Nikos Mavrogiannopoulos > > Joachim Strombergson > > Simon Josefsson > > Filename : draft-ietf-tls-chacha20-poly1305-01.txt > > Pages : 7 > > Date : 2015-11-02 > > > > Abstract: > > This document describes the use of the ChaCha stream cipher and > > Poly1305 authenticator in the Transport Layer Security (TLS) and > > Datagram Transport Layer Security (DTLS) protocols. > > Dear all, > > I've submitted the above version of the ChaCha20-Poly1305 draft in the > hopes of getting consensus that it's basically what the group wants > and thus is suitable for early code-point assignment. > > The major change in this version is that the nonce is constructed > using the scheme that's currently in TLS 1.3. To recap: AES-GCM in TLS > 1.2 uses a four-byte, fixed nonce fragment with an explicit, > eight-byte value from the wire appended. ChaCha20-Poly1305 seeks to > eliminate these eight bytes in each record by using the TLS sequence > number. (On this I believe that we basically have agreement.) > > The TLS 1.3 spec already specifies that AEADs use the sequence number > and has a construction where a fixed value (from the handshake output) > is XORed with it. (See > https://tlswg.github.io/tls13-spec/#record-payload-protection.) This > draft apes that in the hopes that the TLS 1.3 construction doesn't > change before its final. > > > Cheers > > AGL > > -- > Adam Langley agl@imperialviolet.org https://www.imperialviolet.org > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Colm --001a11c1bb24d0721305239e3550 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Huge +1 to this I-D, just some minor comments:

* I wonder if the document should be more forthright= in specifying that the ChaCha20/Poly1305 implementations SHOULD actually a= ttempt to use constant-time and constant-access patterns that the algorithm= is designed to facilitate. If that's a selling point then I wonder if = it's worth being specific about that. On that point: I'm curious if= those properties are implementable in a variety of languages, or if it req= uires near-assembly (e.g. C) levels of precision. If it's the latter, t= hen I wonder if it's legitimate to include those selling points.
<= div>
* I think the statement "can be implemented easily without being vulnera= ble to software side-channel attacks"=C2=A0is too strong, unles= s one wants to really litigate what "software side-channels are".= Unless I'm mistaken, as a stream cipher ChaCha20 is *more* vulnerable = to a class of size-based =C2=A0side-channels than a block cipher would be.= =C2=A0

A simple form of attack would be to monitor= connections to wikipedia and identify which pages a user is browsing; from= observing just the size of requests and responses [*] it's pretty easy= for an attacker to (offline) create a graph of HTML page sizes and the siz= es of the images they load and then (in real time) to correlate things such= that they can uniquely identify the page loaded. This attack is feasible w= ith both stream and block ciphers, but it is far easier with a stream ciphe= r. Similarly, the compressed map tiles attack that shows where an online ma= ps user is browsing is much more effective with a stream cipher. [http://blog.ioactive.com/2012/02/ssl-traffic-analysis-on-google-maps.ht= ml]

These kinds of simple correlation attack a= re vastly more practical than the kinds of time and cache access side-chann= els that CBC verification is weak against. They are also inherently passive= and undetectable. On the whole the I-D reads as if ChaCha20 is more side-c= hannel resistant, but I think reasonable people could disagree about this -= and it's worth some discussion in the security section.=C2=A0

[*] Consider also that in the case of Wikipedia an attacke= r can control the size of a target page they may be interested in.



On Mon, Nov 2, 2015 at 2:12 PM, Adam Langley <agl@im= perialviolet.org> wrote:
On Mon, Nov 2, 2015 at 2:06 PM,=C2=A0 <internet-drafts@ietf.org> wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
>=C2=A0 This draft is a work item of the Transport Layer Security Workin= g Group of the IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (T= LS)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: Adam Langley
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Wan-Teh Chang
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Nikos Mavrogiannopoulos
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Joachim Strombergson
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Simon Josefsson
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 := draft-ietf-tls-chacha20-poly1305-01.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: 7
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 : 2015-11-02
>
> Abstract:
>=C2=A0 =C2=A0 This document describes the use of the ChaCha stream ciph= er and
>=C2=A0 =C2=A0 Poly1305 authenticator in the Transport Layer Security (T= LS) and
>=C2=A0 =C2=A0 Datagram Transport Layer Security (DTLS) protocols.

Dear all,

I've submitted the above version of the ChaCha20-Poly1305 draft in the<= br> hopes of getting consensus that it's basically what the group wants
and thus is suitable for early code-point assignment.

The major change in this version is that the nonce is constructed
using the scheme that's currently in TLS 1.3. To recap: AES-GCM in TLS<= br> 1.2 uses a four-byte, fixed nonce fragment with an explicit,
eight-byte value from the wire appended. ChaCha20-Poly1305 seeks to
eliminate these eight bytes in each record by using the TLS sequence
number. (On this I believe that we basically have agreement.)

The TLS 1.3 spec already specifies that AEADs use the sequence number
and has a construction where a fixed value (from the handshake output)
is XORed with it. (See
https://tlswg.github.io/tls13-spec/#rec= ord-payload-protection.) This
draft apes that in the hopes that the TLS 1.3 construction doesn't
change before its final.


Cheers

AGL

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

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



--
=
Colm
--001a11c1bb24d0721305239e3550-- From nobody Tue Nov 3 02:34: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 9867E1B31B0 for ; Tue, 3 Nov 2015 02:34:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWlPm1i9h_Fr for ; Tue, 3 Nov 2015 02:34:40 -0800 (PST) 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 43CE61B31AF for ; Tue, 3 Nov 2015 02:34:40 -0800 (PST) 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 A85FA42E5A7 for ; Tue, 3 Nov 2015 10:34:39 +0000 (UTC) Received: from dhcp-10-40-3-77.brq.redhat.com (dhcp-10-40-3-77.brq.redhat.com [10.40.3.77]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tA3AYbHQ016881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 3 Nov 2015 05:34:38 -0500 Message-ID: <1446546877.3276.21.camel@redhat.com> From: Nikos Mavrogiannopoulos To: "tls@ietf.org" Date: Tue, 03 Nov 2015 11:34:37 +0100 In-Reply-To: References: <20151102220617.22528.91021.idtracker@ietfa.amsl.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.26 Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-chacha20-poly1305-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: Tue, 03 Nov 2015 10:34:41 -0000 On Mon, 2015-11-02 at 23:54 -0800, Colm MacCárthaigh wrote: > * I think the statement "can be implemented easily without being > vulnerable to software side-channel attacks" is too strong, unless > one wants to really litigate what "software side-channels are". > Unless I'm mistaken, as a stream cipher ChaCha20 is *more* vulnerable > to a class of size-based side-channels than a block cipher would be. > A simple form of attack would be to monitor connections to wikipedia > and identify which pages a user is browsing; from observing just the > size of requests and responses [*] it's pretty easy for an attacker > to (offline) create a graph of HTML page sizes and the sizes of the > images they load and then (in real time) to correlate things such > that they can uniquely identify the page loaded. This attack is > feasible with both stream and block ciphers, but it is far easier > with a stream cipher. Similarly, the compressed map tiles attack that > shows where an online maps user is browsing is much more effective > with a stream cipher. [http://blog.ioactive.com/2012/02/ssl-traffic > -analysis-on-google-maps.html] I agree that protecting the length of the communicated data is important, but there is nothing specific to this cipher. All modern TLS ciphers today are stream ciphers (i.e., AES-GCM and AES-CCM (*)), so they offer the same protection as chacha20 with respect to hiding the length. Maybe we should add a note about that in the security considerations. regards, Nikos (*). More specifically their mode is a stream cipher mode From nobody Tue Nov 3 03:37: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 6011B1B324E for ; Tue, 3 Nov 2015 03:37:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_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 CcwNv4cnJPSr for ; Tue, 3 Nov 2015 03:37:06 -0800 (PST) Received: from zucker2.schokokeks.org (zucker2.schokokeks.org [178.63.68.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B5191B324B for ; Tue, 3 Nov 2015 03:37:06 -0800 (PST) Received: from pc1 (0x3ec66991.inet.dsl.telianet.dk [::ffff:62.198.105.145]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Tue, 03 Nov 2015 12:37:03 +0100 id 00000000000000AF.0000000056389C5F.00007EFB Date: Tue, 3 Nov 2015 12:37:57 +0100 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: tls@ietf.org Message-ID: <20151103123757.5943257d@pc1> In-Reply-To: References: X-Mailer: Claws Mail 3.13.0 (GTK+ 2.24.28; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-32507-1446550623-0001-2" Archived-At: Subject: Re: [TLS] Revised I-D: Use of KCipher-2 with Poly1305 in Transport Layer Security (draft-kiyomoto-kcipher2-tls-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: Tue, 03 Nov 2015 11:37:08 -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-32507-1446550623-0001-2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, 2 Nov 2015 22:52:59 +0900 Yoshiaki Hori wrote: > Name: draft-kiyomoto-kcipher2-tls > Revision: 02 > Title: Use of KCipher-2 with Poly1305 in Transport Layer I feel I've written almost the same on multiple occassions lately, but I'll do it again: I think one of the major problems of TLS (and other crypto) in the past has been that it has grown to be too complicated. I'm therefore strictly against adding new options without any reasonable rationale behind them. The rationale here seems to be "let's have another algorithm just in case". That "just in case" here is that if chacha20 turns out to be insecure we don't have another streamcipher. However we'd of course still have AES-GCM. I think TLS has suffered a lot in the past from feature bloat. I'd propose to go the other way: Lower the number of options if they don't make sense. Therefore: Please don't introduce another algorithm into TLS - unless you have very good arguments (i.e. it is vastly better than the other options or you have serious arguments why you think AES-GCM and chacha20/poly1305 are in danger of being real-world-broken any time soon). --=20 Hanno B=C3=B6ck http://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: BBB51E42 --=_zucker.schokokeks.org-32507-1446550623-0001-2 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWOJyVAAoJEKWIAHK7tR5CSrQP/29UhG956jDIsNCPbrcoeCIS 4d7ty6VnPABJipy/oLLYVd0OzejMKKd+ft/yo1TBx5Q5rUT46K58rV2XYpbCqD+6 VLcJ6zQsu9IL0GaMqHxrNenVWpJi7xroExbPf0VyV2TV2Ll7ADzhYMEoKfzcYw3O BFpTg7E9vxiA7Esxe9UIxYpfMxm9WFMr+KfPlXCmEmEoPS+B1F2hFfX+P8uPvlz9 Z3R3Nj6oD9/R9Dwj6V7LcA/nVCWEIDAJrJUx/ML0CLAygJHyPOFrvrJshSYirO0z 4RicxYJnM5MGBM17UkhK5bEP1NplYHwUL81Q2rSBft6e/8x6WA6YElw9fH1hcaPE PkFzEYTtv0dEgw6mGXGN/JWP6QnTa/3bGrr5lXUBGPrlGPd02ks1oj529m3u57II xLv12EsJWlaG6WsPHvtGB9gpFX0LADrFEW6m5/BJb5AFX5McX1X7FoxSHSrlloCk HCBecBQRu6WRZrdgbzC+M6/CfATMdF2WRsvug/GMsjBeHhz/6GcKRMADujj1t11I SQ8hJOvXihR0jRz3xHBSNn7IoTzG2KthyX8gZvNA1+aggcFwibXf/h00SVZ6YNrb NWH62WSYSBsGyfV5Ft5Xs9HPzjVEcgJyIoIzsrmXkLf+vfJ6GDZstvia1Q7JGiSM Dry+gXLuSF5mc4c/T4EX =e5Qu -----END PGP SIGNATURE----- --=_zucker.schokokeks.org-32507-1446550623-0001-2-- From nobody Tue Nov 3 07:54: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 5ABCF1A6FB5 for ; Tue, 3 Nov 2015 07:54:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_52=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 T-Y9jtQM4fPk for ; Tue, 3 Nov 2015 07:54:52 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::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 C7B961A21C7 for ; Tue, 3 Nov 2015 07:54:51 -0800 (PST) Received: by wmff134 with SMTP id f134so87920521wmf.1 for ; Tue, 03 Nov 2015 07:54:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; bh=eu92NI0rJbFkavOi+MbSZ1/3fj8Jdhl6B4JqqRAh5W0=; b=WzQv/gw6pL0ZsAx9xN7/PBnYRsbOuud1n5B9oy1HTp3JdkJG0sdcIrv1Zb0HBk/twM a6rFRe25P4+6Aw0RtzJ7/l7lbSPaBTb4oeWJ4TOpAZVIoM246NmPutholEo3Lu9MQ7Cj 4yTYTZysNedGkcNgexaL6r9cGM6IV5nnMhc+I= 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=eu92NI0rJbFkavOi+MbSZ1/3fj8Jdhl6B4JqqRAh5W0=; b=QXVr0GDsRuD4OS/Wff112fQTBuA4aKwfqyxhSxZw+TR44/R9lqIWFEMXsJv51ze9iz DjDFUlERhfbvf5BED2NWTUr3s0naPEvJfjqlnGiDWtoc0+8G41rqmIgwUr84Jco6BvoJ uj6wrMynOftsMJzYOpO/DRJueFS+J3BJ0WJx19MD7GDjdIXW+5boXL1QzZ0F6LZUC5j/ YgIdYj4bveyERXI81PJmcdtnIwG9cSvZlkDFAwoBIY7VPSippT5lOuHhixtQgvF1TWgj 6Q2In5ITs9rO4w0NIg1SrkpsKFZ8PEwctnrmzusES2NbeaT+aiXFfpdNst0V/Wg30uAl +XCQ== X-Gm-Message-State: ALoCoQlv5U6+Dvs7pLLb2dKPlJV4BJ24Bl+xoojAT6SsxhVBFzjPjV1Ogb2jhwG22/2q90VCLCWi X-Received: by 10.28.132.18 with SMTP id g18mr19366039wmd.64.1446566090337; Tue, 03 Nov 2015 07:54:50 -0800 (PST) Received: from [192.168.23.123] (chello212017113090.11.11.vie.surfer.at. [212.17.113.90]) by smtp.gmail.com with ESMTPSA id om1sm28245688wjc.2.2015.11.03.07.54.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Nov 2015 07:54:49 -0800 (PST) Message-ID: <5638D8C5.9010903@azet.org> Date: Tue, 03 Nov 2015 16:54:45 +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="------------enig5E89B92A9635225755894A87" Archived-At: Subject: [TLS] AES-OCB patent situation resolved X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 15:54:53 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5E89B92A9635225755894A87 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, As some might remember I've been working on a draft for AES-OCB cipher-suites in TLS (https://datatracker.ietf.org/doc/draft-zauner-tls-aes-ocb/). Where, ideally, OCB would replace CCM [or even GCM, but I don't think that's realistic] in TLS. Beginning of this summer Rogaway and IBM (Jutla) filed IPR exemptions for this very draft for use of OCB specific to TLS. What was unclear until very recently was if patents by Gligor/Donescu would be relevant to this document. I've been told that these patents aren't relevant because IPR by Rogaway and Jutla pre-dates them by years. In more detail: ``` IBM patents/publications on IAPM/OCB 7,093,126 "Encryption schemes with almost free integrity awareness " filed April 14, 2000. (Fig 10 describes the parallelized scheme. Also described in detail in text of the patent). Eprint ia.cr/2000/039 "Encryption Modes with Almost Free Message Integrity". 1 Aug 2000. (Section 2.1 describes the parallelizable mode IAPM, also see Fig 2 on page 5). 6,963,976 "Symmetric key authenticated encryption schemes " filed November 3, 2000. (Claim 23 says all blocks to be encrypted in parallel). Gligor and Donescu Patents/Publications 6,973,187 "Block encryption method and schemes for data confidentiality and integrity protection " filed Jan 18, 2001. This patent does not describe ciphertext stealing as done in Rogaway's OCB to handle non-standard size messages. Also, it does not describe any ways to generate the whitening sequence as used in OCB (which are not already covered by IBM patents). Virgil D. Gligor, Pompiliu Donescu: Fast Encryption and Authentication: XCBC Encryption and XECB Authentication Modes. FSE 2001: 92-108 Their earlier paper from 1999 was a broken scheme. (Virgil D. Gligor, Pompiliu Donescu: Integrity-Aware PCBC Encryption Schemes. Security Protocols Workshop 1999: 153-171) ``` Usual reminder here: I'm not a lawyer and neither intimately familiar with US patent law in particular. Hope this gets the discussion started again, as OCB is a very elegant mode which I'd like to see deployed instead of CCM, at least. What's missing currently are implementations. There're primitives available in OpenSSL but code is missing for OCB use with TLS. I probably won't find time to add this code, so if someone is interested, please let me know. Aaron --------------enig5E89B92A9635225755894A87 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJWONjGAAoJEOTbZJL9ubXVMN8P+wcO2BTAkac5Iezqj8bPJl+I T0XL6k7PLrqehuiC4M0/cHaYm39cqxR9hEclh9eCGsi/jy43mO31FhxnT2oDrBps CNulwnLdM+sRatDNCTnF5rmCup+lBBCdIz30UvN5303LSFHFjiX1TX3pnvq8S5s2 dF9KndCiSwrUUUqhwOiKSLh7rzvFgyD5bnm/MwRfxxOjn2VWgduEd+tdjXgRR3Ay HWlc2Xt2HdoAJEYCgG+UD7JCxrKeCypIG0NZduz0NplMTUL5VbH1Tj/QIG3Gb7WA CQlcPOfC956JGHPEaJCe8S/LL0xU2QGUmK5GRMsCVxcmM38t71hNHAdjpe6yAEpb 5vPHzFp3Va9X9hlY/umozV6DJNhz2lW+stqSUJDM1F/Xa38JwLmuELBelq7dW+KY bTvQ9X6E9feNbhTpbsLitDRBy95txNNA2lLTKDDnv+4rwsU7J5lsFz8sofTwiLrr 5QW+dIEFgS/YOBTtQ12H3GB38qDkaeQ2bMJfNGhF1gkv2duF4fPp6KVuVpJ5+GX+ i6IK2x2RScHKk0bQKJAWwV5RwKIrAMHvVU0hWXTvNRQJxzoiTa1+0BKrHu3OiUjE 2katsV87L2nT8ynZKA6DyV5v765T6ZQFafAkfHy2Rg5CGXDLrB7nyvV6N7bQPzsp fZWI76BtroVqu3bymAgv =zjjl -----END PGP SIGNATURE----- --------------enig5E89B92A9635225755894A87-- From nobody Tue Nov 3 08:26: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 A61A61A87BD for ; Tue, 3 Nov 2015 08:26:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 CxznjioMl1_g for ; Tue, 3 Nov 2015 08:25:59 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA271A87BC for ; Tue, 3 Nov 2015 08:25:59 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 63B77433409 for ; Tue, 3 Nov 2015 16:25:58 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 4B206433403 for ; Tue, 3 Nov 2015 16:25:58 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1446567958; bh=HefLPN3Fe6rE5ITPF0AFlqt79tdJBFg8RQpVuHzPpvQ=; l=582; h=References:To:From:Date:In-Reply-To:From; b=o9/eZsRtZyTmIkz9saSGF9x/z/FbMt7hCX6xQJh7lGOVCPe6wPIE3IMneUK/yZwWi xrrWC1sG8QT8R7XjorOeeOSGPA71ZvWZxiKpQNgpvydZj9+Ydv1yBehESy9gYIkKyO OeBEQwUM8K3BcHGolxxLylW9l1612Aaa07S2asv8= Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 224CD20AB for ; Tue, 3 Nov 2015 16:25:58 +0000 (GMT) References: <20151102220617.22528.91021.idtracker@ietfa.amsl.com> To: "" From: Benjamin Kaduk X-Enigmail-Draft-Status: N1110 Message-ID: <5638E015.3060804@akamai.com> Date: Tue, 3 Nov 2015 10:25:57 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20151102220617.22528.91021.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-chacha20-poly1305-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: Tue, 03 Nov 2015 16:26:00 -0000 On 11/02/2015 04:06 PM, internet-drafts@ietf.org wrote: > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-tls-chacha20-poly1305-01 > > Section 2, % 1. The 64-bit record sequence number is serialized as an 8-byte, % big-endian value and padded on the left with 4 zeroes. I assume you mean zero octets/bytes, and not ASCII '0' (or EBCDIC, or ...) "padded on the left" also has some potential for ambiguity (though not as much); something about "four zero octets are prepended to the stream" might be less ambiguous. -Ben From nobody Tue Nov 3 08:29: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 BEAF01A87B9 for ; Tue, 3 Nov 2015 08:29:19 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 9kWRyS4MAQKi for ; Tue, 3 Nov 2015 08:29:18 -0800 (PST) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8967C1A8739 for ; Tue, 3 Nov 2015 08:29:18 -0800 (PST) Received: by oiao187 with SMTP id o187so11772593oia.3 for ; Tue, 03 Nov 2015 08:29:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts_net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JRf1qaf8PRYta06/feCYlxr9mptggI7Ze1cPkjXVHU0=; b=CsPwhlij9XQ30pST6B3GaXIjtp9eKp3CJDDDZ7qlobnUQRmN5MvafoGT0jevxy7KRP dIVDROIq7M8i4SbmKvnJUxRm8Wwm6yswb1/16BEmPgYnVGTsBAtzDXoRtSBGnbWx6ZYI nopLLDMBdul+yjSRPcz7li/Hay9S0Dq6mcUUMp8b902unPj9orLl7rBn2omBbuVjMyc3 2O2ud+CjgieCpr/ZAoM9OsomCuyUFXDxF92XAmRWus+8DScj3UaimdAgtL2H2nLCM+z9 3IjEd7h1YRWqDDTYNqqnkvtnuqLqrH8hZJfPaiWeoGxVJ7uxMj+BsmsEhs2KiDsIj52J Pdfw== 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=JRf1qaf8PRYta06/feCYlxr9mptggI7Ze1cPkjXVHU0=; b=Phedg/T6yPzVbOwRNXmc9X1FFp63kn51MgoZSlrLd1xb1V1+nNfXptYnXG+/kfTKN6 Wj8Ka4hJ/QBqi3Gm1YSxAh2Ou7tFj95xToQUt9XvcQejkuQ9C0XSsRPjWl4J+Yd3gPaZ iYonWD8LKV+N0TYgphY37U8IkInK0nBogHR6bcFcqEG0XZ6VIHXeV97AwuxyPu/2ZaNn 14JCpWKkVUfvVdsKFLPTFbjoi3PnNhLGVir7l7A89viReKxn7I5SwUjpvYTnz/r2ycjR D7neP7HNLNh0Id5Yxd3JFHiIjLsI5O/eQCQA2jEJjLVZ+hWYuHVVkPdmWtJpYxBWvI2+ GFUQ== X-Gm-Message-State: ALoCoQmgV2I1dmmwuODCosl2K5UobD/PJhv89VH8P/mMqLKQ11PN384tOkWA7NHPSLNtdjL/mOL5 MIME-Version: 1.0 X-Received: by 10.202.105.84 with SMTP id e81mr17942684oic.30.1446568157979; Tue, 03 Nov 2015 08:29:17 -0800 (PST) Received: by 10.76.10.8 with HTTP; Tue, 3 Nov 2015 08:29:17 -0800 (PST) In-Reply-To: <1446546877.3276.21.camel@redhat.com> References: <20151102220617.22528.91021.idtracker@ietfa.amsl.com> <1446546877.3276.21.camel@redhat.com> Date: Tue, 3 Nov 2015 08:29:17 -0800 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: Nikos Mavrogiannopoulos Content-Type: multipart/alternative; boundary=001a1141b6243342d30523a56507 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] I-D Action: draft-ietf-tls-chacha20-poly1305-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: Tue, 03 Nov 2015 16:29:19 -0000 --001a1141b6243342d30523a56507 Content-Type: text/plain; charset=UTF-8 On Tue, Nov 3, 2015 at 2:34 AM, Nikos Mavrogiannopoulos wrote: > > I agree that protecting the length of the communicated data is > important, but there is nothing specific to this cipher. I wouldn't contest that; I just think the I-D is over-selling ChaCha20's side-channel resistance. I would argue that in real practical terms it is less side-channel resistant than AES-CBC; but I think a reader would be left with the opposite impression. Still huge +1 on adding it; it's exciting to get a fast modern well-designed cipher into TLS. -- Colm --001a1141b6243342d30523a56507 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Nov 3, 2015 at 2:34 AM, Nikos Mavrogiannopoulos <nmav@redhat.com= > wrote:
I agree that protectin= g the length of the communicated data is
important, but there is nothing specific to this cipher.
=
I wouldn't contest that; I just think the I-D is over-se= lling ChaCha20's side-channel resistance. I would argue that in real pr= actical terms it is less side-channel resistant than AES-CBC; but I think a= reader would be left with the opposite impression.=C2=A0

Still huge +1 on adding it; it's exciting to get a fast modern = well-designed cipher into TLS.=C2=A0

--
Colm
--001a1141b6243342d30523a56507-- From nobody Tue Nov 3 11:30: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 073A01A6FC5 for ; Tue, 3 Nov 2015 11:30:02 -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, 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 LrywbQ2gXR7W for ; Tue, 3 Nov 2015 11:30:00 -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 957CF1A6FE0 for ; Tue, 3 Nov 2015 11:29:47 -0800 (PST) Received: by oiad129 with SMTP id d129so15041126oia.0 for ; Tue, 03 Nov 2015 11:29:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith_org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+xY6UlQiuFLuvWfhc/YVcTLPcF9VKlv9WVT4VB+qNzU=; b=Ik312++Tei0AS8xATLAzkMPGlBxRIwpdJWIL17WV06psuI9E8dbt1oar+kl6L0LaIB 90PQaNyGaJ9/Nuabuwh9rwPwN9we37RSDfFfKl5shG98XIkKBg2+dou9RguWc6HGZ28s OtrnE9giInBOce07R+c1iNI+R3xICqsEFSIcIcfzPoIkT3XnUSF9nRbcHI4ym9SCBGt/ FHWMd0MO4VZi48ml5M+F4NsBX8xeZY+McwzXPPBNxWFQNy0Uqxsx7FGHo8H1vkANJqGu 506mIVlhjCiAvbUXWfJoBDpbCLdHo2LEdtJNRudSqSlJEcTs/bkAACsfwh6g6lE4M1mu OUkg== 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=+xY6UlQiuFLuvWfhc/YVcTLPcF9VKlv9WVT4VB+qNzU=; b=HODBcXxt70pQ7ztDbedVPXwvwXrhFNVWLY8Wmto8meMSg2IsRaWhPs+7vAxT2/saDK F87MeLG+79HWfzFC8hApfhwrEFLcufWA6b30bnl+AlWti8prBX/DmKHZn/Ql58taTDRM lNKpFR2vylhECYRQlJT6IieUrcXAXxLy6jmbTh0fo116cB8xlVZxvEKXD5zvv2gZQG+K jlyyaRuiZ9ya+YdJgeIKgRBbVPQ2yZj7AueNIfA2+eMR3oG+b/+G7cHhOmwhMFpnlH1B rCMIvJ8CAFIp7yyKIlqnh+JeLFIRqRRYbXJx4MuXV3f01Sp/uWIBg+cA4w1omprMkNUx 7jRQ== X-Gm-Message-State: ALoCoQlBX+IXg6NjVdHsOt4vaKcUM7BhrEwU46ax3WGkqyXx/IbN8UCmw/Th+AnxMFkozbRlV571 MIME-Version: 1.0 X-Received: by 10.202.63.132 with SMTP id m126mr18648534oia.80.1446578986977; Tue, 03 Nov 2015 11:29:46 -0800 (PST) Received: by 10.76.44.145 with HTTP; Tue, 3 Nov 2015 11:29:46 -0800 (PST) In-Reply-To: References: <20151102220617.22528.91021.idtracker@ietfa.amsl.com> Date: Tue, 3 Nov 2015 09:29:46 -1000 Message-ID: From: Brian Smith To: Adam Langley Content-Type: multipart/alternative; boundary=001a113d660aa8a4d40523a7ea14 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] I-D Action: draft-ietf-tls-chacha20-poly1305-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: Tue, 03 Nov 2015 19:30:02 -0000 --001a113d660aa8a4d40523a7ea14 Content-Type: text/plain; charset=UTF-8 Brian Smith wrote: > This way, one Poly1305 invocation per record could be saved, potentially, forapplication_data records, which is the common case. > > This is still true, but... > An implementation that avavoids sending encrypted alerts and avoids renegotiation could avoid writing code for the case where non-empty AAD is needed, and could share the exact same code between TLS 1.2 and TLS 1.3 for ChaCha20-Poly1305. > > This isn't true, because of the Finished message. So, it is not quite as good of an idea as I thought, but still it seems like it could be worthwhile. Cheers, Brian -- https://briansmith.org/ --001a113d660aa8a4d40523a7ea14 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Bria= n Smith <brian@briansmith.org> wrote:
This =
way, one Poly1305 invocation per record could be saved, potentially, forapp=
lication_data records, which is the common case.

This is still true, but...
=
=C2=A0
An implementation that avavoids sending encrypt=
ed alerts and avoids renegotiation could avoid writing code for the case wh=
ere non-empty AAD is needed, and could share the exact same code between TL=
S 1.2 and TLS 1.3 for ChaCha20-Poly1305.

This isn't true, because of the Fini= shed message. So, it is not quite as good of an idea as I thought, but stil= l it seems like it could be worthwhile.

Cheers,
Brian
--
--001a113d660aa8a4d40523a7ea14-- From nobody Tue Nov 3 13:01: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 29E161A01D7 for ; Tue, 3 Nov 2015 13:01:07 -0800 (PST) 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 JiZguOUhb5jB for ; Tue, 3 Nov 2015 13:01:05 -0800 (PST) Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1900:3001:11::28]) by ietfa.amsl.com (Postfix) with ESMTP id E8A821A00CE for ; Tue, 3 Nov 2015 13:01:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 2D8D01E5D4E for ; Tue, 3 Nov 2015 13:00:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id odYyR66TKRx4 for ; Tue, 3 Nov 2015 13:00:29 -0800 (PST) Received: from dhcp-84-117.meeting.ietf94.jp (dhcp-84-117.meeting.ietf94.jp [133.93.84.117]) by c8a.amsl.com (Postfix) with ESMTPA id CC8C51E5D47 for ; Tue, 3 Nov 2015 13:00:28 -0800 (PST) From: Alexa Morris Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Nov 2015 13:01:06 -0800 Message-Id: <9723D737-7D3F-4CA4-BEDD-8740B8394456@amsl.com> To: tls@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Sendlaterdate: Tue, 3 Nov 2015 13:01:06 -0800 X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [TLS] Queue for TLS Remote Attendees X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 21:01:07 -0000 If you are planning to participate in the TLS session here at IETF 94 = today =97 either locally in Yokohama or as a remote participant =97 we = want to make sure that you are aware that the IETF is providing a remote = participants with a fairly new way to ask questions or make comments. In = addition to using the Jabber room, for the TLS session there is also the = opportunity for remote participants to enter a virtual queue and ask = questions directly into the meeting room.=20 This experimental queue was used in several sessions at IETF 92 and IETF = 93, so you may have already seen it in action. There will be two queues = for the TLS session =97 a virtual queue and an actual (in-room) queue. = Remote attendees will log into the Meetecho platform and will have a = virtual mic line that they can enter if they have a question or comment. = In-room participants will continue to use normal mic lines.=20 Instructions for remote participants are at = http://ietf94.conf.meetecho.com/index.php/Remote_Participation.=20 Information on how to join the Meetecho session is at = http://ietf94.conf.meetecho.com/. Verify that you are WebRTC compliant (required to use the virtual queue) = by performing a self-test here: = http://ietf94.conf.meetecho.com/index.php/Self_Test.=20 Regards, Alexa ---------- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amorris@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com From nobody Tue Nov 3 18:12: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 025441A89C5 for ; Tue, 3 Nov 2015 18:12:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 iluHQWpPoctc for ; Tue, 3 Nov 2015 18:12:23 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [217.34.220.150]) by ietfa.amsl.com (Postfix) with ESMTP id 91CBC1A89C4 for ; Tue, 3 Nov 2015 18:12:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1446603137; d=isode.com; s=selector; i=@isode.com; bh=1vGeJA4qksUL0L4Kz7A5R+lq9XQSTEfgf04iRwAndU4=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=uFbvl4Aw/NW/yjx2BrRGtN5jtGsoeyn2e+Nk6HQiuhbJwSjGDhIYzdjtn5Ih8wp2zSdhfY 97WiyZyF0LZ/eifC7Cm/YLDBdtjg7IVwYPk/kdioqKGJrvdkgzer5JC26838Jo/np/u6Lp W3akQXU+8Wbt1U4v+PJwLupdk0drf6U=; Received: from [133.93.39.101] ((unknown) [133.93.39.101]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 4 Nov 2015 02:12:16 +0000 X-SMTP-Protocol-Errors: NORDNS PIPELINING From: Alexey Melnikov Date: Wed, 4 Nov 2015 11:12:50 +0900 Message-Id: To: "tls@ietf.org" X-Mailer: iPad Mail (13B143) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [TLS] Deprecating tls-unique for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 02:12:24 -0000 Just to clarify, I think it is fine to define TLS 1.3 replacement for tls-un= ique using Exporters. But I suggest for interoperability this should be defi= ned as a new channel binding with a new name, as opposed to just redefining t= ls-unique.= From nobody Tue Nov 3 18:14: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 B11431A8960 for ; Tue, 3 Nov 2015 18:14:37 -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, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jtE7RH352WS for ; Tue, 3 Nov 2015 18:14:36 -0800 (PST) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::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 936481A89AF for ; Tue, 3 Nov 2015 18:14:33 -0800 (PST) Received: by ykft191 with SMTP id t191so49348231ykf.0 for ; Tue, 03 Nov 2015 18:14:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=sOLIwr/e4DF/0dy/t+V1vuIYnjUjB9CsVBYg9KOYheo=; b=h34FpwHsczJizqPZL1d8tPSqNaAKLxJkWCOQZGSEKHcM9nvg4yDJleDa9mJvJznm6H crkkKKmc16zLBwF/F+f4qSJ26EjbVn0/A689pcOYee0wqVHN7O9oMwpMdZ4D4Z3U38bI bMN8egkUzjtC6H8Jr30KK+M4Cy7Cr+9NTQGuh6dkUpBpJxO4SulEPU7/AcERtnSTTdMO AjKF4ksXmF41YJ6II0h5ZEftaiEWed4WGARxxNNbaGfmAXAEuc6VX4yjx7JOr6tkQBfp 4fStjLTnB8r35i4sbqxBrzKGJ1GnCX9w7/HniTC1TZYBaTa0Pz9ugA2pKzhry82mwq8e io5Q== 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=sOLIwr/e4DF/0dy/t+V1vuIYnjUjB9CsVBYg9KOYheo=; b=W0rRk00RMJvjmTCFmjFct3EVfXCoQVghF7jlII8DLyOw/A/SYX8ZZq+RwG+R+1B6w1 plKG84hPbZQM90AIJqoeJ+QxYg0D+jpeEOxtHas7lQdasbUrya7Vbf2+nQo6K+lOKDfE Ytj3CswVVqaVqjOK2/dNJQWy0KrEsv4CYDxlBxQTHRG3vLvVno3GGfsMLWwq6dLrs3/Z 38z1mxRL8kn2GyS89fkjZ15E6OGl4DPYE4K9G/7IBpFSqJFMvxlYaVGuFrP/BRtW6a3L aS0TZQ2aChRdcRkaJ9ZnGP3aBW9WTEDigYrmJ4BOAjs1YHD9IxQGIba1tBJXTOZqPU1M qG+w== X-Gm-Message-State: ALoCoQmLHiIh3i1WsVmAhpKEGJVzKVSYU2pSfdUWiprgWWfMDXbFHSrHjVcneEd/QSQp7rg6k7Do X-Received: by 10.129.93.193 with SMTP id r184mr7854885ywb.115.1446603272758; Tue, 03 Nov 2015 18:14:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.221.203 with HTTP; Tue, 3 Nov 2015 18:13:53 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Wed, 4 Nov 2015 11:13:53 +0900 Message-ID: To: Alexey Melnikov Content-Type: multipart/alternative; boundary=001a114d71d8345e9d0523ad92da Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecating tls-unique for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 02:14:37 -0000 --001a114d71d8345e9d0523ad92da Content-Type: text/plain; charset=UTF-8 Can you expand on this a bit? Perhaps propose some text. -Ekr On Wed, Nov 4, 2015 at 11:12 AM, Alexey Melnikov wrote: > Just to clarify, I think it is fine to define TLS 1.3 replacement for > tls-unique using Exporters. But I suggest for interoperability this should > be defined as a new channel binding with a new name, as opposed to just > redefining tls-unique. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a114d71d8345e9d0523ad92da Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Can you expand on this a bit? Perhaps propose some text.
-Ekr


On Wed, Nov 4, 2015 at 11:12 AM, Alexey Mel= nikov <alexey.melnikov@isode.com> wrote:
Just to clarify, I think it is fine to define TLS 1.= 3 replacement for tls-unique using Exporters. But I suggest for interoperab= ility this should be defined as a new channel binding with a new name, as o= pposed to just redefining tls-unique.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--001a114d71d8345e9d0523ad92da-- From nobody Tue Nov 3 18:16: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 76C781A8A05 for ; Tue, 3 Nov 2015 18:16:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVO_But47lRN for ; Tue, 3 Nov 2015 18:16:09 -0800 (PST) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::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 E1BF61A8A15 for ; Tue, 3 Nov 2015 18:16:08 -0800 (PST) Received: by pabfh17 with SMTP id fh17so36445806pab.0 for ; Tue, 03 Nov 2015 18:16:08 -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 :content-transfer-encoding:message-id:references:to; bh=i9nu96MHEH2+r4kHfsj4ivtGqvCnW7aPKxVJBk1bFp0=; b=qbe/XLijJTGlnq3KVppQW4KPVeljclB1LGrPXmCEHb10iF+/yEtDEX9tuykyoya5e6 sQywVMUDvn8QehDP8Ev8D6ayUZtY8H+a3L78u5as+3v/H+QXfJEZOmiBBAsLWg+7yfSU B91haVe/gkL13+pifs9zPtANBqwLAuUJmxii9EuMLuvTZb7vNi/eU1Ph22urngcKvlHl q20F2qv+e9bzi1wGiW7T77y0zcpllFs18BmBEQ9k2K4lKs3w2V5Nvn/7xDuqtOor/3OS oi41M46w/0hGV45sQt8FHSnkwfjmbqv0+iR9u/KgMndLVG120EFhLNIOTVs46vT7wVyd rYnQ== X-Received: by 10.66.235.71 with SMTP id uk7mr36924647pac.3.1446603368637; Tue, 03 Nov 2015 18:16:08 -0800 (PST) Received: from t20010c40000030245da01e30ec98faa2.v6.meeting.ietf94.jp (t20010c40000030245da01e30ec98faa2.v6.meeting.ietf94.jp. [2001:c40:0:3024:5da0:1e30:ec98:faa2]) by smtp.gmail.com with ESMTPSA id sx1sm958405pbc.36.2015.11.03.18.16.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Nov 2015 18:16:07 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Yoav Nir In-Reply-To: Date: Wed, 4 Nov 2015 11:16:04 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <9AB2FB66-1E46-473B-AE7E-E27798474891@gmail.com> References: To: Alexey Melnikov X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecating tls-unique for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 02:16:10 -0000 Can=E2=80=99t we just say that all previous uses of tis-unique will = instead get an exporter generated with the label =E2=80=9Ctis-unique=E2=80= =9D ? > On 4 Nov 2015, at 11:12 AM, Alexey Melnikov = wrote: >=20 > Just to clarify, I think it is fine to define TLS 1.3 replacement for = tls-unique using Exporters. But I suggest for interoperability this = should be defined as a new channel binding with a new name, as opposed = to just redefining tls-unique. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Nov 3 19:05:14 2015 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B15CB1A8ABB; Tue, 3 Nov 2015 19:05:11 -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: 6.8.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151104030511.26412.4737.idtracker@ietfa.amsl.com> Date: Tue, 03 Nov 2015 19:05:11 -0800 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-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: Wed, 04 Nov 2015 03:05:12 -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 Authors : Yoav Nir Simon Josefsson Manuel Pegourie-Gonnard Filename : draft-ietf-tls-rfc4492bis-05.txt Pages : 31 Date : 2015-11-03 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) and Edwards Digital Signature Algorithm (EdDSA) as new authentication mechanisms. 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: https://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-rfc4492bis-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 Tue Nov 3 19:56: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 B28471A90C2; Tue, 3 Nov 2015 19:56:18 -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 gJ_NI177Lw-q; Tue, 3 Nov 2015 19:56:16 -0800 (PST) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e: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 7D6281A90C1; Tue, 3 Nov 2015 19:56:16 -0800 (PST) Received: by pasz6 with SMTP id z6so39779399pas.2; Tue, 03 Nov 2015 19:56:16 -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 :content-transfer-encoding:message-id:references:to; bh=iwCMinMHW8ve9t5q94dgKoadrXlTQTm6kxAx9l7/n4I=; b=ZS5LZLg/nf8lbxxj9JI/fck4rl7QxygBGdLgt5kcfldJ6tK8h20Eh5x9+9Jq0r49bC krxeo24cKWebB2pdjSHLr1/octe8y/iBd/erT7kdVUZGYkQgnZjSwzfxjhHXIQL/jseh ElEVC7hnKybjvha8oAbvpTakum+FS3cPjZT1ruJuZ3OcVhwYNi4p1/b8vMW8c845WoBc gSRRVo3fW6hhtJS9bFYFQNRJV0P+SsJwTi3iD0ECPh9HbNNh1ZEVqPyG4zc5+nsE3ljX locKwl9sKjkc5entajEONV8XAAD4MfJwDoeviJI36mvwEFkCVJvMeXWbdnDrIkND0I78 qqzA== X-Received: by 10.66.164.201 with SMTP id ys9mr38667410pab.50.1446609376201; Tue, 03 Nov 2015 19:56:16 -0800 (PST) Received: from t20010c400000302408e8831114c881ca.v6.meeting.ietf94.jp (t20010c400000302408e8831114c881ca.v6.meeting.ietf94.jp. [2001:c40:0:3024:8e8:8311:14c8:81ca]) by smtp.gmail.com with ESMTPSA id zk3sm32241030pbb.41.2015.11.03.19.56.13 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Nov 2015 19:56:15 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Yoav Nir In-Reply-To: <20151104030511.26412.4737.idtracker@ietfa.amsl.com> Date: Wed, 4 Nov 2015 12:56:10 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151104030511.26412.4737.idtracker@ietfa.amsl.com> To: internet-drafts@ietf.org X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: tls@ietf.org, i-d-announce@ietf.org Subject: Re: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-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: Wed, 04 Nov 2015 03:56:18 -0000 This includes three of the pull requests we discussed at the meeting. I=E2=80=99ve left the change in IANA registry policies out for now = because we=E2=80=99re not yet in agreement about how that should go. Yoav > On 4 Nov 2015, at 12:05 PM, internet-drafts@ietf.org wrote: >=20 >=20 > 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 > Authors : Yoav Nir > Simon Josefsson > Manuel Pegourie-Gonnard > Filename : draft-ietf-tls-rfc4492bis-05.txt > Pages : 31 > Date : 2015-11-03 >=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) and = Edwards > Digital Signature Algorithm (EdDSA) as new authentication = mechanisms. >=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: > https://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-05 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-rfc4492bis-05 >=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 From nobody Tue Nov 3 22:00: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 AE97D1ACE25 for ; Tue, 3 Nov 2015 22:00:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5RWESkY3Phg for ; Tue, 3 Nov 2015 22:00:24 -0800 (PST) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79C791ACE23 for ; Tue, 3 Nov 2015 22:00:24 -0800 (PST) Received: by ykft191 with SMTP id t191so55644178ykf.0 for ; Tue, 03 Nov 2015 22:00:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ELUHGfybP+YbpqHcMBO/9QC+w+dlOyqJPXZzQKAFXZM=; b=mbYuzvwqBoicKIbiolSHp3KwTEFkRSwuBtpQM0JYMmG7NY1qQZoeI/hvwT4rf0+u7Z UCJQDx9vVSCigHfPfUgZXP6vPKRJCZSKEz7muUXcbzsXepI+KGEfboTzQ9rzjsRSpwHF 2z5LFSFHHsMiVboHkETm8GQ/TpL81N8cmCZxbGjLE91Hpy+9PEG8WQn7tzNFLL6Y/ef5 F+Gehiv6sBPmqjoPoWWRZrNExv2xfEP3EyzxRYBd+czH29JPKqUzNu+66XkUf9WqgwRk sORsuGK/11lmvkrlyT4LQWQ4qpOnnc4aX0HWnOLR+siN+JmrOeJVtIgCd1ZiXduekQeq 3j4w== MIME-Version: 1.0 X-Received: by 10.129.131.1 with SMTP id t1mr20144917ywf.207.1446616823847; Tue, 03 Nov 2015 22:00:23 -0800 (PST) Received: by 10.129.132.145 with HTTP; Tue, 3 Nov 2015 22:00:23 -0800 (PST) In-Reply-To: <9AB2FB66-1E46-473B-AE7E-E27798474891@gmail.com> References: <9AB2FB66-1E46-473B-AE7E-E27798474891@gmail.com> Date: Wed, 4 Nov 2015 15:00:23 +0900 Message-ID: From: Martin Thomson To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecating tls-unique for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 06:00:25 -0000 On 4 November 2015 at 11:16, Yoav Nir wrote: > Can=E2=80=99t we just say that all previous uses of tis-unique will inste= ad get an exporter generated with the label =E2=80=9Ctis-unique=E2=80=9D ? That was my thought here: redefine what it means to generate tls-unique. That's part of why I asked about the size. We should ensure that clients are not made sad if they receive a tls-unique that is longer than 96 bits. We could backport this to 1.2, but I'm not sure whether this is a new feature or whether it's a bug fix. If it is the former, I'm not that enthusiastic about a backport. From nobody Tue Nov 3 22:44: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 A0E461A8A08 for ; Tue, 3 Nov 2015 22:44:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 j0-QQSLud5ey for ; Tue, 3 Nov 2015 22:44:45 -0800 (PST) Received: from statler.isode.com (statler.isode.com [217.34.220.151]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC2A1ACEBC for ; Tue, 3 Nov 2015 22:44:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1446619475; d=isode.com; s=selector; i=@isode.com; bh=JTOR7jzL3y2OQOTyb98cYeTIxf8WSUeTl4vCGaBcY+8=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=plHiEguohOGKY373T47xg9WkA/EO0nsoHVMpFpMCiRJUkh9ReF037CEgiQB4frbg/doDxH n3cbOz1NrWirYaZJ9jodhaYMglYI0De7xvkr5tW108jkIV4rVOZCHBCOynE65uDY7CMHX4 XzkEtdiaD65wmxdX1Lgrs1hNDc3KB60=; Received: from [133.93.32.122] (dhcp-32-122.meeting.ietf94.jp [133.93.32.122]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 4 Nov 2015 06:43:54 +0000 To: Eric Rescorla References: From: Alexey Melnikov X-Enigmail-Draft-Status: N1110 Message-ID: <5639A8D8.1060400@isode.com> Date: Wed, 4 Nov 2015 15:42:32 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecating tls-unique for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 06:44:48 -0000 On 04/11/2015 11:13, Eric Rescorla wrote: > Can you expand on this a bit? Perhaps propose some text. So, tls-unique is defined in RFC 5929 as: Description: The first TLS Finished message sent (note: the Finished struct, not the TLS record layer message containing it) in the most recent TLS handshake of the TLS connection being bound to (note: TLS connection, not session, so that the channel binding is specific to each connection regardless of whether session resumption is used). If TLS renegotiation takes place before the channel binding operation, then the first TLS Finished message sent of the latest/ inner-most TLS connection is used. Note that for full TLS handshakes, the first Finished message is sent by the client, while for abbreviated TLS handshakes (session resumption), the first Finished message is sent by the server. This is currently independent of the version of TLS used. This is also broken for TLS 1.2 due to the triple handshake vulnerability. I don't think we can just redefine this for TLS 1.3 and expect this to work, because APIs for getting this information out of TLS libraries are going to be different if Exporters are used. Also, if "tls-unique" is redefined, an old implementation of "tls-unique" would be unable to talk to a new implementation. For example if one end is IMAP client using SCRAM or GS2 against IMAP server implementing the same. I think there is desire to fix this for both TLS 1.2 and 1.3. I think the best way would be to take Simon's draft-josefsson-sasl-tls-cb-03 (Channel Bindings for TLS based on the PRF) and update it for TLS 1.3. I think conceptually what Simon did is very similar to what was proposed in the TLS meeting today. > -Ekr >=20 >=20 > On Wed, Nov 4, 2015 at 11:12 AM, Alexey Melnikov > > wrote: >=20 > Just to clarify, I think it is fine to define TLS 1.3 replacement > for tls-unique using Exporters. But I suggest for interoperability > this should be defined as a new channel binding with a new name, as > opposed to just redefining tls-unique. From nobody Tue Nov 3 22:48:11 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10B9F1ACED3 for ; Tue, 3 Nov 2015 22:48:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yw6J9JyLOD21 for ; Tue, 3 Nov 2015 22:48:08 -0800 (PST) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E7BA1ACED2 for ; Tue, 3 Nov 2015 22:48:08 -0800 (PST) Received: by ykdr3 with SMTP id r3so56857882ykd.1 for ; Tue, 03 Nov 2015 22:48:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VTNIcHLP83bR0VwQsDsWF1bU6bDt/0np0chOeD0vxGU=; b=iDonnSjvgFzJJ1MuNqtqi+Fzt15+9BNp6sR+mk9jQaPKaiG+6i7jsfGzS4QqRenUka 8dfQrHIAqUvB9v59ar7fS8UawrDyLGjbdmm/shfB6BwhyR5QOdplFdhjn30D66TfsPyD sqbRm8GhBsiJXuev8BvdL3jP7ovkAWoD6JMQGGD76kZXI5H7MAPlBHk21/VCI86ANsXp b3EEWqlEmeIsRNjUDCGOFaJczDt1orXtq/cG/xOXM9tzDJ34PBrIdQ0WJgjCKX0EB3R+ Xf8859RxFy3ADsJl4txke8PHH7uIRAJs1OT2z/bblNVqo4/F5fdT+aPvzfwg1sYObD2i qCXw== MIME-Version: 1.0 X-Received: by 10.129.132.83 with SMTP id u80mr23469100ywf.187.1446619687494; Tue, 03 Nov 2015 22:48:07 -0800 (PST) Received: by 10.129.132.145 with HTTP; Tue, 3 Nov 2015 22:48:07 -0800 (PST) In-Reply-To: <5639A8D8.1060400@isode.com> References: <5639A8D8.1060400@isode.com> Date: Wed, 4 Nov 2015 15:48:07 +0900 Message-ID: From: Martin Thomson To: Alexey Melnikov Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecating tls-unique for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 06:48:10 -0000 What is wrong with getTlsUnique2() or getBetterTlsUnique() ? It's not a drop-in replacement, but it indicates that the app understands the change. Otherwise, we might have to signal this in TLS 1.2 proper. 1.3 can just be fixed. On 4 November 2015 at 15:42, Alexey Melnikov wrote: > On 04/11/2015 11:13, Eric Rescorla wrote: >> Can you expand on this a bit? Perhaps propose some text. > > So, tls-unique is defined in RFC 5929 as: > > Description: The first TLS Finished message sent (note: the Finished > struct, not the TLS record layer message containing it) in the most > recent TLS handshake of the TLS connection being bound to (note: TLS > connection, not session, so that the channel binding is specific to > each connection regardless of whether session resumption is used). > If TLS renegotiation takes place before the channel binding > operation, then the first TLS Finished message sent of the latest/ > inner-most TLS connection is used. Note that for full TLS > handshakes, the first Finished message is sent by the client, while > for abbreviated TLS handshakes (session resumption), the first > Finished message is sent by the server. > > This is currently independent of the version of TLS used. This is also > broken for TLS 1.2 due to the triple handshake vulnerability. > > I don't think we can just redefine this for TLS 1.3 and expect this to > work, because APIs for getting this information out of TLS libraries are > going to be different if Exporters are used. > Also, if "tls-unique" is redefined, an old implementation of > "tls-unique" would be unable to talk to a new implementation. For > example if one end is IMAP client using SCRAM or GS2 against IMAP server > implementing the same. > > I think there is desire to fix this for both TLS 1.2 and 1.3. I think > the best way would be to take Simon's draft-josefsson-sasl-tls-cb-03 > (Channel Bindings for TLS based on the PRF) and update it for TLS 1.3. I > think conceptually what Simon did is very similar to what was proposed > in the TLS meeting today. > > >> -Ekr >> >> >> On Wed, Nov 4, 2015 at 11:12 AM, Alexey Melnikov >> > wrote: >> >> Just to clarify, I think it is fine to define TLS 1.3 replacement >> for tls-unique using Exporters. But I suggest for interoperability >> this should be defined as a new channel binding with a new name, as >> opposed to just redefining tls-unique. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Nov 3 23:06: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 595911AD277 for ; Tue, 3 Nov 2015 23:06:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 K1VmTVayqagX for ; Tue, 3 Nov 2015 23:06:21 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [217.34.220.150]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0591AD259 for ; Tue, 3 Nov 2015 23:06:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1446620770; d=isode.com; s=selector; i=@isode.com; bh=b2O4PC8HS1lB0cQr6UesvGBvH3CztfsBH8jRImrIV34=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=ciUIiR+ZXoWtbGt5s8YIerkkUtMop53PE6w0InlOH0WInvKAmY0xE5oqdRTr5y76ubVq/H fC3ec1pXs2U8U/TMThaRe7thTszrLcp6nS9v7W+DltBejDylSqp3NaCbY7psaOaV2vypAH k9TogWqW6K5sE1elybG38RlGnU88ey0=; Received: from [133.93.32.122] (dhcp-32-122.meeting.ietf94.jp [133.93.32.122]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 4 Nov 2015 07:06:06 +0000 To: Martin Thomson References: <5639A8D8.1060400@isode.com> From: Alexey Melnikov X-Enigmail-Draft-Status: N1110 Message-ID: <5639AE45.2030909@isode.com> Date: Wed, 4 Nov 2015 16:05:41 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecating tls-unique for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 07:06:23 -0000 On 04/11/2015 15:48, Martin Thomson wrote: > What is wrong with getTlsUnique2() or getBetterTlsUnique() ? That would be fine, but see below. > It's not a drop-in replacement, If it is not a drop in replacement, it should have a different name. Channel bindings are referenced by names in various protocols (and some implementations can support more than one channel binding type), in particular in SASL SCRAM and SASL GS2. > but it indicates that the app understands the > change. Otherwise, we might have to signal this in TLS 1.2 proper. > 1.3 can just be fixed. My point are: 1) "tls-unique" is defined in TLS version-independent way, so it is currently defined for TLS 1.3 (as long as TLS 1.3 still uses Finished messages). 2) It would be much better to implement a single recommended TLS channel binding that works for both TLS 1.2 and TLS 1.3 3) We can't redefine how tls-unique works for TLS 1.2 without breaking existing implementations (I can explain this in more details, if needed). All of these made me think that defining a new channel binding that works for both TLS 1.2 and TLS 1.3 would be a better option. > On 4 November 2015 at 15:42, Alexey Melnikov w= rote: >> On 04/11/2015 11:13, Eric Rescorla wrote: >>> Can you expand on this a bit? Perhaps propose some text. >> >> So, tls-unique is defined in RFC 5929 as: >> >> Description: The first TLS Finished message sent (note: the Finished >> struct, not the TLS record layer message containing it) in the most >> recent TLS handshake of the TLS connection being bound to (note: TLS >> connection, not session, so that the channel binding is specific to >> each connection regardless of whether session resumption is used). >> If TLS renegotiation takes place before the channel binding >> operation, then the first TLS Finished message sent of the latest/ >> inner-most TLS connection is used. Note that for full TLS >> handshakes, the first Finished message is sent by the client, while >> for abbreviated TLS handshakes (session resumption), the first >> Finished message is sent by the server. >> >> This is currently independent of the version of TLS used. This is also >> broken for TLS 1.2 due to the triple handshake vulnerability. >> >> I don't think we can just redefine this for TLS 1.3 and expect this to >> work, because APIs for getting this information out of TLS libraries are >> going to be different if Exporters are used. >> Also, if "tls-unique" is redefined, an old implementation of >> "tls-unique" would be unable to talk to a new implementation. For >> example if one end is IMAP client using SCRAM or GS2 against IMAP server >> implementing the same. >> >> I think there is desire to fix this for both TLS 1.2 and 1.3. I think >> the best way would be to take Simon's draft-josefsson-sasl-tls-cb-03 >> (Channel Bindings for TLS based on the PRF) and update it for TLS 1.3. I >> think conceptually what Simon did is very similar to what was proposed >> in the TLS meeting today. >> >> >>> -Ekr >>> >>> >>> On Wed, Nov 4, 2015 at 11:12 AM, Alexey Melnikov >>> > wrote: >>> >>> Just to clarify, I think it is fine to define TLS 1.3 replacement >>> for tls-unique using Exporters. But I suggest for interoperability >>> this should be defined as a new channel binding with a new name, as >>> opposed to just redefining tls-unique. >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls From nobody Tue Nov 3 23:30: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 CFCAA1B2A03 for ; Tue, 3 Nov 2015 23:30:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9A9zN2aiLu_0 for ; Tue, 3 Nov 2015 23:30:36 -0800 (PST) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 344081B2A05 for ; Tue, 3 Nov 2015 23:30:28 -0800 (PST) Received: by wicfv8 with SMTP id fv8so26326377wic.0 for ; Tue, 03 Nov 2015 23:30:26 -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=ipOyO4rAmHMh8dFcEBA5WtbNX0J/7QDWZ4Du5fR91I4=; b=HE7HrjRPLXjJx+j1hHWq90zbowVFISLXmi8M9hAAQZ+7ITaJ5OqAMtk3FrbIxzpn9L 5W6w7Rly7+l3erjL6zlLCQhghFognVCAZy+X8hkW1nDA4l3cySOKJF+yq6Yw6ZVThdxb OrthQvii6ZrJl4wLuuFwYTmAZVrYDUcGiYwd5EJDcHkHJYHzvulwJFOPsx/1BD217GzD 0LoZLiDoWy0qDYPT6UlJynBCk8QzWPb/72DfIMq4OuEKDYMu7n1+bZIJ0EdjPFXxJ7TM srx0ooIhPdjIF7AtgH8vnsbQE7+aM7FGM0l6iUnoBf3UbBlD7Sm5bpuoeXFQTynd/Jnn RilA== X-Received: by 10.194.58.142 with SMTP id r14mr26973wjq.37.1446622226729; Tue, 03 Nov 2015 23:30:26 -0800 (PST) Received: from ?IPv6:2001:660:330f:38:95ba:8865:d014:619d? ([2001:660:330f:38:95ba:8865:d014:619d]) by smtp.gmail.com with ESMTPSA id ka10sm46459wjc.30.2015.11.03.23.30.25 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Nov 2015 23:30:26 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_C98D670B-E383-4BF6-887F-0132ABAEB086" Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Karthikeyan Bhargavan In-Reply-To: Date: Wed, 4 Nov 2015 08:30:24 +0100 Message-Id: <225ECEC4-8553-4C49-9FA8-4139E67DFD44@gmail.com> References: <9AB2FB66-1E46-473B-AE7E-E27798474891@gmail.com> To: Martin Thomson X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecating tls-unique for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 07:30:38 -0000 --Apple-Mail=_C98D670B-E383-4BF6-887F-0132ABAEB086 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Despite the proposed extended master secret fix in RFC7627, I now think = that tls-unique needs to be deprecated for all versions of TLS, and that we should design and = recommend a new channel binding that can be used uniformly by = SASL/TokenBinding/FIDO etc. I have read Simon=E2=80=99s draft and it is a plausible approach = https://tools.ietf.org/html/draft-josefsson-sasl-tls-cb-03 = The TokenBinding folks have gone with an exporters-based binding, which = makes sense too. Both of them rely on the session hash construction and should be = compatible with TLS 1.3. One question to ask is whether the binding should be per-session (i.e. = per master secret) or per-connection. Best, Karthik >=20 > On Wed, Nov 4, 2015 at 7:00 AM, Martin Thomson = > wrote: > On 4 November 2015 at 11:16, Yoav Nir > wrote: > > Can=E2=80=99t we just say that all previous uses of tis-unique will = instead get an exporter generated with the label =E2=80=9Ctis-unique=E2=80= =9D ? >=20 >=20 > That was my thought here: redefine what it means to generate = tls-unique. >=20 > That's part of why I asked about the size. We should ensure that > clients are not made sad if they receive a tls-unique that is longer > than 96 bits. >=20 > We could backport this to 1.2, but I'm not sure whether this is a new > feature or whether it's a bug fix. If it is the former, I'm not that > enthusiastic about a backport. >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls = >=20 --Apple-Mail=_C98D670B-E383-4BF6-887F-0132ABAEB086 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Despite the proposed extended master secret fix in RFC7627, I = now think that tls-unique needs
to be deprecated for all = versions of TLS, and that we should design and recommend
a new channel binding that can be used uniformly by = SASL/TokenBinding/FIDO etc.

I have read Simon=E2=80=99s draft and it is a plausible = approach https://tools.ietf.org/html/draft-josefsson-sasl-tls-cb-03<= /div>
The TokenBinding folks have gone with an = exporters-based binding, which makes sense too.
Both = of them rely on the session hash construction and should be compatible = with TLS 1.3.
One question to ask is whether the = binding should be per-session (i.e. per master secret) or = per-connection.

Best,
Karthik


On Wed, Nov 4, 2015 at 7:00 AM, Martin Thomson = <martin.thomson@gmail.com> wrote:
On 4 = November 2015 at 11:16, Yoav Nir <ynir.ietf@gmail.com>= wrote:
> Can=E2=80=99t we just say that all previous uses of tis-unique will = instead get an exporter generated with the label =E2=80=9Ctis-unique=E2=80= =9D ?


That was my thought here: redefine what it means to generate = tls-unique.

That's part of why I asked about the size.  We should ensure = that
clients are not made sad if they receive a tls-unique that is longer
than 96 bits.

We could backport this to 1.2, but I'm not sure whether this is a new
feature or whether it's a bug fix.  If it is the former, I'm not = that
enthusiastic about a backport.

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


= --Apple-Mail=_C98D670B-E383-4BF6-887F-0132ABAEB086-- From nobody Wed Nov 4 00:43: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 F0B0D1AC3CD for ; Wed, 4 Nov 2015 00:43:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 Gq_ec4Z4PHjO for ; Wed, 4 Nov 2015 00:43:37 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0754.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:754]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CBA31A92BC for ; Wed, 4 Nov 2015 00:43:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=m/74IoS+rWo5g0DVzXm5AxV+TAgrLgFTH+jZdZt5smw=; b=Eud8xM38Jf+WeBM6mJOdjSOpvYmGKtklSbnyVBpW3yMfb1oAJgYm9WX2q47VqKcKptsMFfsN8jRLEuWFGusOr/QaJm8bEK3ILNZXn0SkTtshyGqRnO/6lOoKGqWHmWMPYxVRTuCp3Qy8piPDEuYanbg+nWJ78fQwd2R+E/8JyME= Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1395.namprd03.prod.outlook.com (10.163.81.141) with Microsoft SMTP Server (TLS) id 15.1.312.18; Wed, 4 Nov 2015 08:43:18 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0312.014; Wed, 4 Nov 2015 08:43:18 +0000 From: Andrei Popov To: Alexey Melnikov , Martin Thomson Thread-Topic: [TLS] Deprecating tls-unique for TLS 1.3 Thread-Index: AQHRFqZDUwDvKAI6N0ymNo51TIx4056LH5qAgABLDwCAAAGQgIAABOiAgAAZkxA= Date: Wed, 4 Nov 2015 08:43:17 +0000 Message-ID: References: <5639A8D8.1060400@isode.com> <5639AE45.2030909@isode.com> In-Reply-To: <5639AE45.2030909@isode.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [118.243.125.71] x-microsoft-exchange-diagnostics: 1; BLUPR03MB1395; 5:L4eL4iNlCllI2Hq5dO3C5b/9eZg0a+AT39qCsZqqDnsc9thaTl+YMfDEZq6hBnDJQ4FxXmETZsCH/IFZyF/gK+JK9iQizKX5is2RpXwPSxviB+DRO028BN8Ii5QBxUVi7u0HeJdmzpdzLyVjQ/EmmQ==; 24:JARONdL3r3GCtJHqnsXMfvyWAqmlkLM2VkAwmM3QBToKIU6ueZowyI0WqG/ZxVLMoIERk/wQPxpSI/9cztPVprUnkrEwjFCV+l5oDyOPeio=; 20:pVMBJLFYm9rbzP70xzUti6fuivJTN8MKz/0UsyxQWRObCviyRz34vypX4mpK16LuUCJjoesUCG7q6gemFYn+Kg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1395; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(189930954265078); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(520078)(8121501046)(5005006)(10201501046)(3002001)(61426024)(61427024); SRVR:BLUPR03MB1395; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1395; x-forefront-prvs: 0750463DC9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(189002)(199003)(24454002)(13464003)(479174004)(50944005)(86612001)(102836002)(2950100001)(2900100001)(15975445007)(8990500004)(5005710100001)(5004730100002)(10400500002)(92566002)(40100003)(5007970100001)(81156007)(189998001)(11100500001)(74316001)(5008740100001)(77096005)(10290500002)(122556002)(5001960100002)(86362001)(5002640100001)(575784001)(33656002)(66066001)(99286002)(97736004)(106356001)(106116001)(101416001)(105586002)(54356999)(10090500001)(76176999)(50986999)(87936001)(93886004)(19580395003)(5003600100002)(19580405001)(76576001)(5001770100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1395; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2015 08:43:17.7693 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1395 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecating tls-unique for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 08:43:41 -0000 I agree with Alexey that we can't just start returning the new, longer, tls= -unique from the same API call. So perhaps the simplest fix is to update RFC 5929 to say that tls-unique is= deprecated and EKM should be used instead, with certain recommended parame= ters. This does mean that any protocols that rely on tls-unique will need t= o negotiate a new revision. Cheers, Andrei -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Alexey Melnikov Sent: Wednesday, November 4, 2015 4:06 PM To: Martin Thomson Cc: tls@ietf.org Subject: Re: [TLS] Deprecating tls-unique for TLS 1.3 On 04/11/2015 15:48, Martin Thomson wrote: > What is wrong with getTlsUnique2() or getBetterTlsUnique() ? That would be fine, but see below. > It's not a drop-in replacement, If it is not a drop in replacement, it should have a different name. Channel bindings are referenced by names in various protocols (and some imp= lementations can support more than one channel binding type), in particular= in SASL SCRAM and SASL GS2. > but it indicates that the app understands the change. Otherwise, we=20 > might have to signal this in TLS 1.2 proper. > 1.3 can just be fixed. My point are: 1) "tls-unique" is defined in TLS version-independent way, so it is current= ly defined for TLS 1.3 (as long as TLS 1.3 still uses Finished messages). 2) It would be much better to implement a single recommended TLS channel bi= nding that works for both TLS 1.2 and TLS 1.3 3) We can't redefine how tls-unique works for TLS 1.2 without breaking exis= ting implementations (I can explain this in more details, if needed). All of these made me think that defining a new channel binding that works f= or both TLS 1.2 and TLS 1.3 would be a better option. > On 4 November 2015 at 15:42, Alexey Melnikov = wrote: >> On 04/11/2015 11:13, Eric Rescorla wrote: >>> Can you expand on this a bit? Perhaps propose some text. >> >> So, tls-unique is defined in RFC 5929 as: >> >> Description: The first TLS Finished message sent (note: the Finished >> struct, not the TLS record layer message containing it) in the most >> recent TLS handshake of the TLS connection being bound to (note: TLS >> connection, not session, so that the channel binding is specific to >> each connection regardless of whether session resumption is used). >> If TLS renegotiation takes place before the channel binding >> operation, then the first TLS Finished message sent of the latest/ >> inner-most TLS connection is used. Note that for full TLS >> handshakes, the first Finished message is sent by the client, while >> for abbreviated TLS handshakes (session resumption), the first >> Finished message is sent by the server. >> >> This is currently independent of the version of TLS used. This is=20 >> also broken for TLS 1.2 due to the triple handshake vulnerability. >> >> I don't think we can just redefine this for TLS 1.3 and expect this=20 >> to work, because APIs for getting this information out of TLS=20 >> libraries are going to be different if Exporters are used. >> Also, if "tls-unique" is redefined, an old implementation of=20 >> "tls-unique" would be unable to talk to a new implementation. For=20 >> example if one end is IMAP client using SCRAM or GS2 against IMAP=20 >> server implementing the same. >> >> I think there is desire to fix this for both TLS 1.2 and 1.3. I think=20 >> the best way would be to take Simon's draft-josefsson-sasl-tls-cb-03=20 >> (Channel Bindings for TLS based on the PRF) and update it for TLS=20 >> 1.3. I think conceptually what Simon did is very similar to what was=20 >> proposed in the TLS meeting today. >> >> >>> -Ekr >>> >>> >>> On Wed, Nov 4, 2015 at 11:12 AM, Alexey Melnikov=20 >>> > wrote: >>> >>> Just to clarify, I think it is fine to define TLS 1.3 replacement >>> for tls-unique using Exporters. But I suggest for interoperability >>> this should be defined as a new channel binding with a new name, as >>> opposed to just redefining tls-unique. >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww. >> ietf.org%2fmailman%2flistinfo%2ftls&data=3D01%7c01%7cAndrei.Popov%40mic >> rosoft.com%7c5848f661843a4a6bdf2f08d2e4e676db%7c72f988bf86f141af91ab2 >> d7cd011db47%7c1&sdata=3Deo0A63TBIz1CdZKzpBRb9o2A7y1CW12IEtXPltbiohY%3d _______________________________________________ TLS mailing list TLS@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf= .org%2fmailman%2flistinfo%2ftls&data=3D01%7c01%7cAndrei.Popov%40microsoft.c= om%7c5848f661843a4a6bdf2f08d2e4e676db%7c72f988bf86f141af91ab2d7cd011db47%7c= 1&sdata=3Deo0A63TBIz1CdZKzpBRb9o2A7y1CW12IEtXPltbiohY%3d From nobody Wed Nov 4 02:51: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 4FCBA1B2D16 for ; Wed, 4 Nov 2015 02:51:52 -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 VXquvOQjL60D for ; Wed, 4 Nov 2015 02:51:50 -0800 (PST) Received: from filtteri1.pp.htv.fi (filtteri1.pp.htv.fi [213.243.153.184]) by ietfa.amsl.com (Postfix) with ESMTP id 39F3A1B2D0C for ; Wed, 4 Nov 2015 02:51:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by filtteri1.pp.htv.fi (Postfix) with ESMTP id 4944521BCF4 for ; Wed, 4 Nov 2015 12:51:48 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from smtp4.welho.com ([213.243.153.38]) by localhost (filtteri1.pp.htv.fi [213.243.153.184]) (amavisd-new, port 10024) with ESMTP id 6ufz2xwzuRbW for ; Wed, 4 Nov 2015 12:51:48 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp4.welho.com (Postfix) with ESMTPSA id 246315BC018 for ; Wed, 4 Nov 2015 12:51:48 +0200 (EET) Date: Wed, 4 Nov 2015 12:51:44 +0200 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20151104105144.GA14151@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Subject: [TLS] PR #333 - CFRG ECC ECDH&signatures X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 10:51:52 -0000 I forward-ported the merged RFC4492bis changes (with explicit numbers added[1], in style of rsapss(4)) as PR #333. This also includes the ECDH stuff, which IIRC was in RFC4492bis before my PR. I tried to align everything as close as possible (the only difference should be PMS getting replaced by ES and SS, due to TLS changes). [1] Signature algorithm #5 (#0-#4 are already used) and and Elliptic curves #29-#32 (#1-#28 are already used). -Ilari From nobody Wed Nov 4 03:30: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 779041A00EF; Wed, 4 Nov 2015 03:30:29 -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 nchQcXSZdi0v; Wed, 4 Nov 2015 03:30:28 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::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 0F8411A065C; Wed, 4 Nov 2015 03:30:28 -0800 (PST) Received: by wmll128 with SMTP id l128so111470837wml.0; Wed, 04 Nov 2015 03:30:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vMFWwe2J/ffYSs2v+3aXs2kaGwGYfgDZKf0Gf5OnElw=; b=wfe1STMH9JGuXEz4W7EhenBtEystJ0gIs7j2V69ZOBZYfAFqP11XRl9ECFTCaLLdfe krWzMi3o59V2uhsnBWqO0sO6ELQI1bmOeYfKuNELUFjPzR4QuN8HVTBeVwDqt8fvdmy+ J640+zzwYDlSMFFQsze9ZAqLfxGqU93tEw8YUqAdR/qOPxvmUQR4wrt7S4nlVpr5WRNR E/K0279KqxvZlEze4Aql2i7xUn30y8+HK9y0vrl3TgxpksIN7HEM8h6npDkNvAZ04Wfh tLLY0dQbIs7HFYoqCzo0hSeLOYHUm4O4R/A55VwA760KoHj7AG74CGjBr98IlLlNzZG0 ZpFw== MIME-Version: 1.0 X-Received: by 10.28.54.211 with SMTP id y80mr2931881wmh.3.1446636626615; Wed, 04 Nov 2015 03:30:26 -0800 (PST) Received: by 10.28.101.212 with HTTP; Wed, 4 Nov 2015 03:30:26 -0800 (PST) In-Reply-To: <20151104030511.26412.4737.idtracker@ietfa.amsl.com> References: <20151104030511.26412.4737.idtracker@ietfa.amsl.com> Date: Wed, 4 Nov 2015 06:30:26 -0500 Message-ID: From: Watson Ladd To: internet-drafts@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" , i-d-announce@ietf.org Subject: Re: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-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: Wed, 04 Nov 2015 11:30:29 -0000 This draft continues to have security issues when used in TLS 1.2. An attacker can mount triple-handshake by using points of small order on Curve25519, generating zero on both sides. This draft needs to say that Curve25519 can only be used along with extended master secret. Alternatively we can completely remove the cofactor and reject zero keys. From nobody Wed Nov 4 03:34: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 A390B1ACE01 for ; Wed, 4 Nov 2015 03:34:54 -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 h7htxOEnB7Om for ; Wed, 4 Nov 2015 03:34:53 -0800 (PST) Received: from filtteri5.pp.htv.fi (filtteri5.pp.htv.fi [213.243.153.188]) by ietfa.amsl.com (Postfix) with ESMTP id 4886F1ACDE3 for ; Wed, 4 Nov 2015 03:34:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by filtteri5.pp.htv.fi (Postfix) with ESMTP id 31AF75A71BA; Wed, 4 Nov 2015 13:34:35 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from smtp4.welho.com ([213.243.153.38]) by localhost (filtteri5.pp.htv.fi [213.243.153.188]) (amavisd-new, port 10024) with ESMTP id mpuuz7iQs7sr; Wed, 4 Nov 2015 13:34:35 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp4.welho.com (Postfix) with ESMTPSA id 0D8575BC011; Wed, 4 Nov 2015 13:34:52 +0200 (EET) Date: Wed, 4 Nov 2015 13:34:48 +0200 From: Ilari Liusvaara To: Watson Ladd Message-ID: <20151104113448.GA14210@LK-Perkele-V2.elisa-laajakaista.fi> References: <20151104030511.26412.4737.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-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: Wed, 04 Nov 2015 11:34:54 -0000 On Wed, Nov 04, 2015 at 06:30:26AM -0500, Watson Ladd wrote: > This draft needs to say that Curve25519 can only be used along with > extended master secret. Alternatively we can completely remove the > cofactor and reject zero keys. X25519 and X448 specifications say zero keys MUST be rejected (and the functions are also internally specified to clear the cofactor). -Ilari From nobody Wed Nov 4 03:56: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 72D161B2DD9 for ; Wed, 4 Nov 2015 03:56:18 -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 eftqz6NG0mwk for ; Wed, 4 Nov 2015 03:56:17 -0800 (PST) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05EF81B2DD6 for ; Wed, 4 Nov 2015 03:56:17 -0800 (PST) Received: by wijp11 with SMTP id p11so90741018wij.0 for ; Wed, 04 Nov 2015 03:56:15 -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=WmcaWunFrENCU5NMqGZK90A4o92SomqkOM7KCBatIIM=; b=hWEiuAe1zuboo0Pb9jcVI27sWqj6W2PKIbHIDnAsZcPrJ4ORqORLDw4044bSxVB3ho HEd7qTe0OpYpnDK6aM5Qal30Kn9q0lEMpyS79hMcBEano7Oja3YG/LSsB03fgLh9Vme7 CHnST34Q3qxQEXNhSc6RNr8LZA6oXzvK9qNweAse40oLPC9g32z0UXsxMLf4n7zQY6b4 Rvl+YuSpgVoB12i7TzpjklVZnkEeIdxMRMJ9ORrqn9qUmRzEhpthMdd+3LyeIusKAXZQ 851DNayyWSbr6safwfeltY7a/DTEEc+LwBHxikDmXfGFI5D9nITV54Cu0jGQfZMZ8jpv 4ADQ== MIME-Version: 1.0 X-Received: by 10.194.142.45 with SMTP id rt13mr1510302wjb.45.1446638175596; Wed, 04 Nov 2015 03:56:15 -0800 (PST) Received: by 10.28.101.212 with HTTP; Wed, 4 Nov 2015 03:56:15 -0800 (PST) In-Reply-To: <20151104113448.GA14210@LK-Perkele-V2.elisa-laajakaista.fi> References: <20151104030511.26412.4737.idtracker@ietfa.amsl.com> <20151104113448.GA14210@LK-Perkele-V2.elisa-laajakaista.fi> Date: Wed, 4 Nov 2015 06:56:15 -0500 Message-ID: From: Watson Ladd To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-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: Wed, 04 Nov 2015 11:56:18 -0000 On Wed, Nov 4, 2015 at 6:34 AM, Ilari Liusvaara wrote: > On Wed, Nov 04, 2015 at 06:30:26AM -0500, Watson Ladd wrote: >> This draft needs to say that Curve25519 can only be used along with >> extended master secret. Alternatively we can completely remove the >> cofactor and reject zero keys. > > X25519 and X448 specifications say zero keys MUST be rejected (and > the functions are also internally specified to clear the cofactor). The language used in the current draft doesn't clearly say you must use the definition in CFRG curves which does this with cofactor business, and in fact doesn't include the string X25519. > > > -Ilari -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Wed Nov 4 04:30: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 CE63A1B2E50 for ; Wed, 4 Nov 2015 04:30:04 -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 TLocXSelJTng for ; Wed, 4 Nov 2015 04:30:03 -0800 (PST) Received: from filtteri6.pp.htv.fi (filtteri6.pp.htv.fi [213.243.153.189]) by ietfa.amsl.com (Postfix) with ESMTP id 529E11B2E4C for ; Wed, 4 Nov 2015 04:30:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by filtteri6.pp.htv.fi (Postfix) with ESMTP id 9DB2456F756; Wed, 4 Nov 2015 14:30:01 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from smtp4.welho.com ([213.243.153.38]) by localhost (filtteri6.pp.htv.fi [213.243.153.189]) (amavisd-new, port 10024) with ESMTP id 2fyrca-IpLTA; Wed, 4 Nov 2015 14:30:01 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp4.welho.com (Postfix) with ESMTPSA id 747855BC015; Wed, 4 Nov 2015 14:30:01 +0200 (EET) Date: Wed, 4 Nov 2015 14:29:58 +0200 From: Ilari Liusvaara To: Watson Ladd Message-ID: <20151104122958.GA14234@LK-Perkele-V2.elisa-laajakaista.fi> References: <20151104030511.26412.4737.idtracker@ietfa.amsl.com> <20151104113448.GA14210@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-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: Wed, 04 Nov 2015 12:30:05 -0000 On Wed, Nov 04, 2015 at 06:56:15AM -0500, Watson Ladd wrote: > On Wed, Nov 4, 2015 at 6:34 AM, Ilari Liusvaara > wrote: > > > > X25519 and X448 specifications say zero keys MUST be rejected (and > > the functions are also internally specified to clear the cofactor). > > The language used in the current draft doesn't clearly say you must > use the definition in CFRG curves which does this with cofactor > business, and in fact doesn't include the string X25519. I made PR #16 about this (renamed the functions and added the zero checks). -Ilari From nobody Wed Nov 4 04:45: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 A5F441B2E8A for ; Wed, 4 Nov 2015 04:45:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nICSZAiV4jLq for ; Wed, 4 Nov 2015 04:45:03 -0800 (PST) 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 44A031B2E83 for ; Wed, 4 Nov 2015 04:45:03 -0800 (PST) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 0AE958E22C for ; Wed, 4 Nov 2015 12:45:03 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-122.brq.redhat.com [10.34.0.122]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tA4Cj1Xw017955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 4 Nov 2015 07:45:02 -0500 From: Hubert Kario To: tls@ietf.org Date: Wed, 04 Nov 2015 13:45 +0100 Message-ID: <18087174.ghTSLDDQdq@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.9 (Linux/4.2.3-200.fc22.x86_64; KDE/4.14.11; x86_64; ; ) In-Reply-To: <20151104030511.26412.4737.idtracker@ietfa.amsl.com> References: <20151104030511.26412.4737.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1460999.0oBNRdOnQk"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-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: Wed, 04 Nov 2015 12:45:04 -0000 --nextPart1460999.0oBNRdOnQk Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Tuesday 03 November 2015 19:05:11 internet-drafts@ietf.org wrote: > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-05 typo: MUST still be included, and contain exactly one value: the uncomptessed= =20 point format (0). is "uncomptessed" should be "uncompressed" =09=09 =09 =2D-=20 Regards, Hubert Kario Senior 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 --nextPart1460999.0oBNRdOnQk 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 iQIcBAABCgAGBQJWOf3MAAoJEJKo0bgB0vX1MzIP/39ZttN71gLUVkl9vzJkSj5q eYVPE6e7G8OhhbsxbHPYjhLH7X5vSKfulIXOxxb1Mfao+6bfE8MzsblLu+Q5C3l5 ReHeskv709PQKGbZmagFZvMq0Ey8QVnpcFmfjUAQ5WyvUqL212GhoNtRaizr544P CM2Y1f33Jpfqo3UyR//hWyp5i6ljNT001pQcEbmdypBsttbMmKbxJzw8BsPIKukC ng4kVd63iZf9KL9f3BP666+1Dr24PyOxQQz3qfiKBMZDSJYO7csVb9nEloOzcVSh sEEToDRLT7MN1EUiektcxShdDcApOr1o29+m1iWLM+ZXFi7epXC5gNEnQ6jiLU3L ezLbBX2HuWOiVH7u/gSgO2UnJZornwtRw3XF3980BLHtwsDwjzYJY0OurNL4qVCb rmbvGzp2IVqp/F/eQwdkUFXmVhWBJSCh5qCWqoPYYYdWBN/pqhbiYmuB8pleM1Kn PaTgZMU+ygzymseZyLHouyXof3G0cDMP0z/8Zh8yCTe2u0cACWvcrDTmEj80wQC+ 5eguHP3rsN0iH8dKmIL8f6RrfvaqReHa6uulHJtZZTSCcKTsWjTK+bgI8ERYxS7D x+o3xPDqxe4opqKg2kc9mqIJfkClcxnV2vo0V4XZYGCqM6ZcEaleTIUHU92GBXCh dD1c30sn/EOqu2VNYXXJ =5z9Q -----END PGP SIGNATURE----- --nextPart1460999.0oBNRdOnQk-- From nobody Wed Nov 4 07:21: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 B87551B317A for ; Wed, 4 Nov 2015 07:21:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6ozKKSuHj4R for ; Wed, 4 Nov 2015 07:21:22 -0800 (PST) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e: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 6869F1B3175 for ; Wed, 4 Nov 2015 07:21:22 -0800 (PST) Received: by pacdm15 with SMTP id dm15so31520082pac.3 for ; Wed, 04 Nov 2015 07:21:22 -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 :content-transfer-encoding:message-id:references:to; bh=l324O1L2j8BBg7qKeHBZORU+JBg8lrNsVIfKgYIYx/Y=; b=J+iVurueMn/Z2Wzo8cwss1BAhyCmiUUKAZF71Y64GehFT1AR2KXWrfaMJNDT1HEPm4 WhjfAAiSYWAhOLH085Wmfbo1S8UtKnw9rIhnVHirglrwqzaXqaTEb2a/fl4D2ZsmPSj/ quh8oqRBeGix/sA62tPlmve23L2GSf0HXpWCHONRDDpObcn/taLcbOHDHe52/hdbGwqw nz4A6UvZuulWC9b1Sp5XSeYZLWxOpo5mQRnMNyoBp7ThwaU5/pEt9NyXyKy7d5Cu6fd5 rTo40cB9pb0RkRsfcnP5R7XXNxXjuwli1rqq8OgEJmoIGTEFrqw3vHMRREJRs/BD+hfo vDiA== X-Received: by 10.66.219.39 with SMTP id pl7mr2532088pac.88.1446650482152; Wed, 04 Nov 2015 07:21:22 -0800 (PST) Received: from [10.11.0.90] (y255183.ppp.asahi-net.or.jp. [118.243.255.183]) by smtp.gmail.com with ESMTPSA id bz2sm2656112pad.32.2015.11.04.07.21.19 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Nov 2015 07:21:20 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Yoav Nir In-Reply-To: <18087174.ghTSLDDQdq@pintsize.usersys.redhat.com> Date: Thu, 5 Nov 2015 00:21:17 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151104030511.26412.4737.idtracker@ietfa.amsl.com> <18087174.ghTSLDDQdq@pintsize.usersys.redhat.com> To: Hubert Kario X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-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: Wed, 04 Nov 2015 15:21:23 -0000 Thanks! Fixed in master. > On 4 Nov 2015, at 9:45 PM, Hubert Kario wrote: >=20 > On Tuesday 03 November 2015 19:05:11 internet-drafts@ietf.org wrote: >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-05 >=20 >=20 > typo: > MUST still be included, and contain exactly one value: the = uncomptessed=20 > point format (0). >=20 > is "uncomptessed" should be "uncompressed" > =09 > --=20 > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech = Republic_______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Nov 4 07:23: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 16A401B3197 for ; Wed, 4 Nov 2015 07:23:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8I5ZJphAunR for ; Wed, 4 Nov 2015 07:23:40 -0800 (PST) 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 30A291B3192 for ; Wed, 4 Nov 2015 07:23:40 -0800 (PST) Received: by pasz6 with SMTP id z6so57413586pas.2 for ; Wed, 04 Nov 2015 07:23:39 -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 :content-transfer-encoding:message-id:references:to; bh=N0lvYnGzNEFMYmh2jv6vMBtk17dp8mp/hWoSUs30d/A=; b=ObDCC3X4M8c5ghRess0nnokDkaef9om7nIDDMb1iQb/gJ0xNXRGSx9od/KFyJglirR HQQE0/2APw3JSyF9ge6p5qXCiHiZNf1gx0jgh556OUvXGzUA2Q9JHdyN7YjqOZE8WJ8x NCPkdu+k74tgyrEBe+5hjzGD0JjCczGqj6QC1G5KZO7HVvB1xmjVLN3+v+vfz6onEN9P EzpPzgJN3lxLNm++la3llSquLpWwp/YlEuxjxqBos2qmDTArPBwIIX3tgro/fg6Cvsh1 pzhvnOZ/5AVTQMZcttSB7GWzWc61RUUKxXgyRFG4gg2SmDiU7KCrT//QDxbkWan2VJli n3iA== X-Received: by 10.68.103.194 with SMTP id fy2mr2517778pbb.39.1446650619855; Wed, 04 Nov 2015 07:23:39 -0800 (PST) Received: from [10.11.0.90] (y255183.ppp.asahi-net.or.jp. [118.243.255.183]) by smtp.gmail.com with ESMTPSA id qn5sm2640069pac.41.2015.11.04.07.23.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Nov 2015 07:23:38 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Yoav Nir In-Reply-To: <20151104122958.GA14234@LK-Perkele-V2.elisa-laajakaista.fi> Date: Thu, 5 Nov 2015 00:23:35 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <173DD762-A043-4A7C-8047-5BD617F6DF9C@gmail.com> References: <20151104030511.26412.4737.idtracker@ietfa.amsl.com> <20151104113448.GA14210@LK-Perkele-V2.elisa-laajakaista.fi> <20151104122958.GA14234@LK-Perkele-V2.elisa-laajakaista.fi> To: "tls@ietf.org" X-Mailer: Apple Mail (2.3096.5) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-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: Wed, 04 Nov 2015 15:23:42 -0000 > On 4 Nov 2015, at 9:29 PM, Ilari Liusvaara = wrote: >=20 > On Wed, Nov 04, 2015 at 06:56:15AM -0500, Watson Ladd wrote: >> On Wed, Nov 4, 2015 at 6:34 AM, Ilari Liusvaara >> wrote: >>>=20 >>> X25519 and X448 specifications say zero keys MUST be rejected (and >>> the functions are also internally specified to clear the cofactor). >>=20 >> The language used in the current draft doesn't clearly say you must >> use the definition in CFRG curves which does this with cofactor >> business, and in fact doesn't include the string X25519. >=20 > I made PR #16 about this (renamed the functions and added the zero > checks). Link to the PR: https://github.com/tlswg/rfc4492bis/pull/16/files Are we all OK with renaming Curve25519 to X25519 (and same for Curve448) = ? Yoav From nobody Wed Nov 4 09:27: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 03FD51A0029 for ; Wed, 4 Nov 2015 09:27:12 -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 qdSse17cmC6c for ; Wed, 4 Nov 2015 09:27:05 -0800 (PST) Received: from filtteri2.pp.htv.fi (filtteri2.pp.htv.fi [213.243.153.185]) by ietfa.amsl.com (Postfix) with ESMTP id 99E371A009C for ; Wed, 4 Nov 2015 09:27:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by filtteri2.pp.htv.fi (Postfix) with ESMTP id 3BE6219C658 for ; Wed, 4 Nov 2015 19:27:04 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from smtp5.welho.com ([213.243.153.39]) by localhost (filtteri2.pp.htv.fi [213.243.153.185]) (amavisd-new, port 10024) with ESMTP id dJgmuDTFTRIx for ; Wed, 4 Nov 2015 19:27:04 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp5.welho.com (Postfix) with ESMTPSA id 1AEB85BC010 for ; Wed, 4 Nov 2015 19:27:04 +0200 (EET) Date: Wed, 4 Nov 2015 19:27:00 +0200 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20151104172700.GA29224@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Subject: [TLS] #311 (remove early_data) - Potential deadlock? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 17:27:12 -0000 I thought of following scenario: Client: ClientHello+0RTT Server: 0RTT rejected. Fallback to 1RTT. Server: (Drains 0-RTT records) Client: Finished (corrupted in transit) Client: Appdata (request for something) Server: (Drains corrupt finished as 0-RTT record) Server: (Drains appdata as 0-RTT record) Client: (Waiting for response from server, handshake finished) Server: (Waiting for Client Finished, handshake in progress) *Deadlock?* Can this actually happen? Or is it considered "too unlikely"? -Ilari From nobody Wed Nov 4 11:30: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 E8A721A8A6A for ; Wed, 4 Nov 2015 11:30:00 -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 pKfUrzn5rI4c for ; Wed, 4 Nov 2015 11:29:57 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0122.outbound.protection.outlook.com [207.46.100.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 861DD1A7015 for ; Wed, 4 Nov 2015 11:29:57 -0800 (PST) Received: from BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) by BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) with Microsoft SMTP Server (TLS) id 15.1.312.18; Wed, 4 Nov 2015 19:29:55 +0000 Received: from BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) by BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) with mapi id 15.01.0312.014; Wed, 4 Nov 2015 19:29:55 +0000 From: "Dang, Quynh" To: Eric Rescorla , "tls@ietf.org" Thread-Topic: Data limit for GCM under a given key. Thread-Index: AQHRFzcvtEucviFc9UutVqNJaXFvZg== Date: Wed, 4 Nov 2015 19:29:55 +0000 Message-ID: References: <811734cd29d64adc98c5388870611575@XCH-ALN-004.cisco.com> , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-originating-ip: [2001:c40:0:3064:8d11:1642:b370:f1af] x-microsoft-exchange-diagnostics: 1; BN1PR09MB124; 5:ARyHXTXPuukcZdfXfvtu60sZIIoXomvFCl8l18T9YukJJ481cBjHMyO/EKBuV1lhxmtAPUx8DEsGLDb0HpnlfC40wcMUgM3ObxHdm5O6/aIMl3zgxLQA7kCduBeJQ/sTCnBtg+Dk8p3HuALmq/TeHA==; 24:jUr4IkZPW+MxbULBbN1CxBEFnHn8ST0Oacdt/2kVBslNn8YvQNiNXQwZITknzhZVfE9ZD90MCuoFdR2FNNfIVFHzvrcTq8lVC3dndnMRc5Y=; 20:aSLA0G3j/DjhH3xeSB0k9KoPvGwBnQc7s9kXhvcWK3kiawb/wocA0QbrkxqcgqLNWDP2/nK63GQl17ljbHpeOg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB124; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001); SRVR:BN1PR09MB124; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB124; x-forefront-prvs: 0750463DC9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(24454002)(199003)(377454003)(93886004)(5001960100002)(15975445007)(229853001)(106116001)(99286002)(122556002)(40100003)(105586002)(5004730100002)(107886002)(50986999)(16236675004)(5007970100001)(76176999)(76576001)(87936001)(5001770100001)(5003600100002)(2900100001)(54356999)(2501003)(19580395003)(101416001)(19617315012)(97736004)(11100500001)(86362001)(10400500002)(106356001)(33656002)(19627405001)(19580405001)(2950100001)(92566002)(77096005)(5002640100001)(5008740100001)(102836002)(81156007)(74316001)(19625215002)(189998001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB124; H:BN1PR09MB124.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN1PR09MB124A4974829B07CC2E8CC68F32A0BN1PR09MB124namprd_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2015 19:29:55.5233 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB124 Archived-At: Subject: [TLS] Data limit for GCM under a given key. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 19:30:01 -0000 --_000_BN1PR09MB124A4974829B07CC2E8CC68F32A0BN1PR09MB124namprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Eric and all, The limit of 2^48 packets under a given key for GCM you mentioned today is = the limit for SRTP (https://tools.ietf.org/html/draft-ietf-avtcore-srtp-aes= -gcm-17#section-6). The nonce space of the IV construction is only 48 bits = and that is why it has the limit of 2^48. The limit here should be 2^48 blo= cks, not records as stated in the document. As I explained before, GCM is counter mode for encryption. For a given key,= the nonce never repeats globally, then confidentiality of the encrypted da= ta is preserved. When the nonce space is 2^n values, then 2^n message block= s can have secure confidentiality protection. Regarding to authentication, as I explained before, if the tag size is n, t= hen you have collision issue among the tags when the number of tags goes ar= ound 2^(n/2) which is not a good thing, but strictly speaking, this does no= t break your authentication. However, rekeying often is a good thing which could help prevent disaster t= o keep go on if there is something wrong with the IV or the key. Quynh. ________________________________ From: Dang, Quynh Sent: Monday, November 2, 2015 3:00 PM To: Watson Ladd Cc: tls@ietf.org; cfrg@ietf.org; Eric Rescorla Subject: Re: [Cfrg] Collision issue in ciphertexts. Now, you talked about a MAC function (with AES). I previously talked about = encryption. If I , the only person, uses the MAC key, when I generate more than 2^64 MA= C values (Let's say each MAC value is 96 bits), I have many collided MAC pa= irs. But, I am the only one (beside the person(s) verifying my MACs) who kn= ows the MAC key in order to generate those verified MAC values. If the MAC length is k bits, an attacker is allowed to send 2^n failed veri= fications, his or her chance of success is approximately 2^n / 2^k. Let's i= magine n is 64 and k is 96, the success chance is 1/2^36 which is practical= ly ZERO! If I am an attacker, I would choose a message that I want to be verified, a= nd I keep changing the MAC key to generate different MAC values with differ= ent keys and hope one of them will get verified. Let's assume the MAC key = to be 96 bits ( 96 bits of random bits, the other 32 bits are known). In th= eory, when I get close to 2^96 attempts, I would expect some chance of succ= ess. To deal with this attacker, one would change the MAC key when the numb= er of failed attempts gets close to a number that you don't want. For examp= le, if you don't want a success chance of an attack to be above 1 / 2^36, t= hen you need to change your MAC key when the number of failed verifications= reaches 2^64 when your MAC length is 96 bits. After you change the MAC key, I ( the attacker) will have to start everythi= ng again because all of the failed MACs I generated before are useless now. ________________________________ From: Watson Ladd Sent: Monday, November 2, 2015 5:07 AM To: Dang, Quynh Cc: tls@ietf.org; cfrg@ietf.org; Eric Rescorla Subject: Re: [Cfrg] Collision issue in ciphertexts. On Nov 2, 2015 2:14 AM, "Dang, Quynh" > wrote: > > Hi Eric, > > > As you asked the question about how many ciphertext blocks should be safe= under a single key, I think it is safe to have 2^96 blocks under a given k= ey if the IV (counter) is 96 bits. This is wrong for PRP, right for PRF. It's not that hard to find the right = result. > > > When there is a collision between two ciphertext blocks when two differen= t counter values are used , the chance of the same plaintext was used twice= is 1^128. Collisions start to happen a lot when the number of ciphertext = blocks are above 2^64. However, each collision just reveals that the corres= ponding plaintext blocks are probably different ones. Which breaks IND-$. Let's not be clever, but stick to ensuring proven defin= itions are true. > > > > Quynh. > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > --_000_BN1PR09MB124A4974829B07CC2E8CC68F32A0BN1PR09MB124namprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Eric and all, 


The limit of 2^48 packets under a given key for GCM you mentioned today = is the limit for SRTP (https://tools.ietf.org/html/draft-ietf-avtcore-srtp-= aes-gcm-17#section-6). The nonce space of the IV construction is only 48 bi= ts and that is why it has the limit of 2^48. The limit here should be 2^48 blocks, not records as stated in th= e document. 


As I explained before, GCM is counter mode for encryption. For= a given key, the nonce never repeats globally, then confidentiality of the= encrypted data is preserved. When the nonce space is 2^n values, then= 2^n message blocks can have secure confidentiality protection. 


Regarding to authentication, as I explained before, if the tag size is n= , then you have collision issue among the tags when the number of tags= goes around 2^(n/2) which is not a good thing, but strictly speaking,= this does not break your authentication. 


However, rekeying often is a good thing which could help prevent disaste= r to keep go on if there is something wrong with the IV or the key.


Quynh. 




From: Dang, Quynh
Sent: Monday, November 2, 2015 3:00 PM
To: Watson Ladd
Cc: tls@ietf.org; cfrg@ietf.org; Eric Rescorla
Subject: Re: [Cfrg] Collision issue in ciphertexts.
 

Now, you talked about a MAC function (with AES). I previously talke= d about encryption. 


If I , the only person, uses the MAC key, when I generate more than 2^64= MAC values (Let's say each MAC value is 96 bits), I have many collided MAC= pairs. But, I am the only one (beside the person(s) verifying my MACs)&nbs= p;who knows the MAC key in order to generate those  verified MAC values.


If the MAC length is k bits, an attacker is allowed to send 2^= n failed verifications, his or her chance of success is approximately = 2^n / 2^k. Let's imagine n is 64 and k is 96, the success chance is 1/2^36 = which is practically ZERO! 


If I am an attacker, I would choose a message that I want to be ver= ified, and I keep changing the MAC key to generate different MAC values wit= h different keys and hope one of them will get verified.  Let's assume= the MAC key to be 96 bits ( 96 bits of random bits, the other 32 bits are known). In theory, when I get close to 2^96 at= tempts, I would expect some chance of success. To deal with this attac= ker, one would change the MAC key when the number of failed attempts gets c= lose to a number that you don't want. For example, if you don't want a success chance of an attack to be ab= ove 1 / 2^36, then you need to change your MAC key when the number of faile= d verifications reaches 2^64 when your MAC length is 96 bits. 


After you change the MAC key, I ( the attacker) will have to start = everything again because all of the failed MACs I generated before are usel= ess now. 


From: Watson Ladd <watso= nbladd@gmail.com>
Sent: Monday, November 2, 2015 5:07 AM
To: Dang, Quynh
Cc: tls@ietf.org; cfrg@ietf.org; Eric Rescorla
Subject: Re: [Cfrg] Collision issue in ciphertexts.
 


On Nov 2, 2015 2:14 AM, "Dang, Quynh" <quynh.dang@nist.gov> wrote:
>
> Hi Eric,
>
>
> As you asked the question about how many ciphertext blocks should be s= afe under a single key, I think it is safe to have 2^96 blocks under a give= n key if the IV (counter) is 96 bits. 

This is wrong for PRP, right for PRF. It's not that hard to = find the right result.

>
>
> When there is a collision between two ciphertext blocks when two diffe= rent counter values are used , the chance of the same plaintext was used tw= ice is 1^128.  Collisions start to happen a lot when the number o= f ciphertext blocks are above 2^64. However, each collision just reveals that the corresponding plaintext blocks a= re probably different ones. 

Which breaks IND-$. Let's not be clever, but stick to ensuri= ng proven definitions are true.

>
>
>
> Quynh. 
>
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irt= f.org/mailman/listinfo/cfrg
>

--_000_BN1PR09MB124A4974829B07CC2E8CC68F32A0BN1PR09MB124namprd_-- From nobody Wed Nov 4 12:17: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 F3FA41B3404 for ; Wed, 4 Nov 2015 12:17:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id krTkOmKWN-fj for ; Wed, 4 Nov 2015 12:17:02 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::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 521B81B33FD for ; Wed, 4 Nov 2015 12:17:02 -0800 (PST) Received: by wmeg8 with SMTP id g8so51167749wme.1 for ; Wed, 04 Nov 2015 12:17:00 -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=OAMv2YAYErOeXCZxJ8me2YM1b4XldRObu+gpbEO1KNA=; b=NjKTfEJWTeLt3hEgnZDfLscatQ9hYdCEBLd2HHBndGmbQe3+JFyxHfX76eqYf0zry+ NtIcojonBSC3sbaz2nN4mrdT1YV47wS+77/TPczFoDT4wcMN9POJifekN47NfQwJMsXl gZZT8CrQeA94aXpq5D+j7rcOhaW14j8zTN2SNA2E/5EmlVIYPcmt+CmWMWOY69s8FA03 Zs6JA2qytwI6zCv4SzYYDukBeZLaBjXuV7hNqnko2Hatdk6eIw4DPtrVZfzkOHIJ6dQp Z7x4QxTQOXfAY7zOiLPhD0KekGBjgfRXxYATd53+3pFnOMkhcZfPa3tCByRWRX3PEMpW 5mzg== MIME-Version: 1.0 X-Received: by 10.28.143.8 with SMTP id r8mr30096752wmd.3.1446668220761; Wed, 04 Nov 2015 12:17:00 -0800 (PST) Received: by 10.28.101.212 with HTTP; Wed, 4 Nov 2015 12:17:00 -0800 (PST) In-Reply-To: References: <811734cd29d64adc98c5388870611575@XCH-ALN-004.cisco.com> Date: Wed, 4 Nov 2015 15:17:00 -0500 Message-ID: From: Watson Ladd To: "Dang, Quynh" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data limit for GCM under a given key. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 20:17:05 -0000 On Wed, Nov 4, 2015 at 2:29 PM, Dang, Quynh wrote: > Hi Eric and all, > > > The limit of 2^48 packets under a given key for GCM you mentioned today is > the limit for SRTP > (https://tools.ietf.org/html/draft-ietf-avtcore-srtp-aes-gcm-17#section-6). > The nonce space of the IV construction is only 48 bits and that is why it > has the limit of 2^48. The limit here should be 2^48 blocks, not records as > stated in the document. > > > As I explained before, GCM is counter mode for encryption. For a given key, > the nonce never repeats globally, then confidentiality of the encrypted data > is preserved. When the nonce space is 2^n values, then 2^n message blocks > can have secure confidentiality protection. This is completely untrue. If you actually understood the definitions, and thought about the matter for 15 minutes, you would realize that permutations are distinguishable from functions after 2^(n/2) queries with high probabilities, and this breaks IND-$. This is an elementary result found on page 134 of Boneh-Shoup. > > > Regarding to authentication, as I explained before, if the tag size is n, > then you have collision issue among the tags when the number of tags goes > around 2^(n/2) which is not a good thing, but strictly speaking, this does > not break your authentication. Carter-Wegman security results are weaker than for PRF-based MACs. > > > However, rekeying often is a good thing which could help prevent disaster to > keep go on if there is something wrong with the IV or the key. > > > Quynh. > > > > > ________________________________ > From: Dang, Quynh > Sent: Monday, November 2, 2015 3:00 PM > To: Watson Ladd > Cc: tls@ietf.org; cfrg@ietf.org; Eric Rescorla > Subject: Re: [Cfrg] Collision issue in ciphertexts. > > > Now, you talked about a MAC function (with AES). I previously talked about > encryption. > > > If I , the only person, uses the MAC key, when I generate more than 2^64 MAC > values (Let's say each MAC value is 96 bits), I have many collided MAC > pairs. But, I am the only one (beside the person(s) verifying my MACs) who > knows the MAC key in order to generate those verified MAC values. > > > If the MAC length is k bits, an attacker is allowed to send 2^n failed > verifications, his or her chance of success is approximately 2^n / 2^k. > Let's imagine n is 64 and k is 96, the success chance is 1/2^36 which is > practically ZERO! > > > If I am an attacker, I would choose a message that I want to be verified, > and I keep changing the MAC key to generate different MAC values with > different keys and hope one of them will get verified. Let's assume the MAC > key to be 96 bits ( 96 bits of random bits, the other 32 bits are known). In > theory, when I get close to 2^96 attempts, I would expect some chance of > success. To deal with this attacker, one would change the MAC key when the > number of failed attempts gets close to a number that you don't want. For > example, if you don't want a success chance of an attack to be above 1 / > 2^36, then you need to change your MAC key when the number of failed > verifications reaches 2^64 when your MAC length is 96 bits. > > > After you change the MAC key, I ( the attacker) will have to start > everything again because all of the failed MACs I generated before are > useless now. > > > ________________________________ > From: Watson Ladd > Sent: Monday, November 2, 2015 5:07 AM > To: Dang, Quynh > Cc: tls@ietf.org; cfrg@ietf.org; Eric Rescorla > Subject: Re: [Cfrg] Collision issue in ciphertexts. > > > > On Nov 2, 2015 2:14 AM, "Dang, Quynh" wrote: >> >> Hi Eric, >> >> >> As you asked the question about how many ciphertext blocks should be safe >> under a single key, I think it is safe to have 2^96 blocks under a given key >> if the IV (counter) is 96 bits. > > This is wrong for PRP, right for PRF. It's not that hard to find the right > result. > >> >> >> When there is a collision between two ciphertext blocks when two different >> counter values are used , the chance of the same plaintext was used twice is >> 1^128. Collisions start to happen a lot when the number of ciphertext >> blocks are above 2^64. However, each collision just reveals that the >> corresponding plaintext blocks are probably different ones. > > Which breaks IND-$. Let's not be clever, but stick to ensuring proven > definitions are true. > >> >> >> >> Quynh. >> >> >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> https://www.irtf.org/mailman/listinfo/cfrg >> > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Wed Nov 4 12:43: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 999E31A219E for ; Wed, 4 Nov 2015 12:43:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cncBlaNcalXW for ; Wed, 4 Nov 2015 12:43:32 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0775.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:775]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D31D81A1F73 for ; Wed, 4 Nov 2015 12:43:31 -0800 (PST) Received: from BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) by BN1PR09MB123.namprd09.prod.outlook.com (10.255.200.25) with Microsoft SMTP Server (TLS) id 15.1.312.18; Wed, 4 Nov 2015 20:43:15 +0000 Received: from BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) by BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) with mapi id 15.01.0312.014; Wed, 4 Nov 2015 20:43:15 +0000 From: "Dang, Quynh" To: Watson Ladd Thread-Topic: [TLS] Data limit for GCM under a given key. Thread-Index: AQHRFzcvtEucviFc9UutVqNJaXFvZp6MTRcAgAAF1Tk= Date: Wed, 4 Nov 2015 20:43:15 +0000 Message-ID: References: <811734cd29d64adc98c5388870611575@XCH-ALN-004.cisco.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-originating-ip: [129.6.222.19] x-microsoft-exchange-diagnostics: 1; BN1PR09MB123; 5:NnkV9lyZu7rXRlgAwc8tGgfQUgRf292LH8EMlJgBnyIRaBJ2+cd/OF/WTc6uUXl8RZxPgNROJ2K7Yn3wWd6PvJiGfVoqqJ/zfLRb+HdSfcLQaHS54y+qm8Hmfp8ARnNgn3QUQdOJAdx320h6ago3pA==; 24:LM1RjYsYNLUAzxokojTlQcnLA8BNOUeGzWo0/4Y2qUdh+Fziaq9G+7db3wZBwjDA4cdLHGbH+eY8i4EMzsZ0H1MJMBSjSc2TRWf4ozxMBTo=; 20:bKw+fZTPSrbnaAQw327YXXcqctESsG19ry9p0p4XFgzJRZkxqHdeo9GqfElxyEHFx+oiQzvy5EYC1pwYC8IrpA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB123; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001); SRVR:BN1PR09MB123; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB123; x-forefront-prvs: 0750463DC9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(24454002)(377454003)(5004730100002)(122556002)(2900100001)(105586002)(110136002)(99286002)(10400500002)(86362001)(5007970100001)(92566002)(97736004)(33656002)(66066001)(5002640100001)(77096005)(19580405001)(74316001)(5001960100002)(102836002)(106356001)(40100003)(54356999)(50986999)(5008740100001)(76176999)(81156007)(1411001)(93886004)(189998001)(87936001)(106116001)(76576001)(2950100001)(15975445007)(5003600100002)(19580395003)(101416001)(11100500001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB123; H:BN1PR09MB124.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2015 20:43:15.2398 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB123 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data limit for GCM under a given key. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 20:43:35 -0000 I did not talk under indistinguishability framework. My discussion was abo= ut confidentiality protection and authentication. Quynh. ________________________________________ From: Watson Ladd Sent: Wednesday, November 4, 2015 3:17:00 PM To: Dang, Quynh Cc: Eric Rescorla; tls@ietf.org Subject: Re: [TLS] Data limit for GCM under a given key. On Wed, Nov 4, 2015 at 2:29 PM, Dang, Quynh wrote: > Hi Eric and all, > > > The limit of 2^48 packets under a given key for GCM you mentioned today i= s > the limit for SRTP > (https://tools.ietf.org/html/draft-ietf-avtcore-srtp-aes-gcm-17#section-6= ). > The nonce space of the IV construction is only 48 bits and that is why it > has the limit of 2^48. The limit here should be 2^48 blocks, not records = as > stated in the document. > > > As I explained before, GCM is counter mode for encryption. For a given ke= y, > the nonce never repeats globally, then confidentiality of the encrypted d= ata > is preserved. When the nonce space is 2^n values, then 2^n message blocks > can have secure confidentiality protection. This is completely untrue. If you actually understood the definitions, and thought about the matter for 15 minutes, you would realize that permutations are distinguishable from functions after 2^(n/2) queries with high probabilities, and this breaks IND-$. This is an elementary result found on page 134 of Boneh-Shoup. > > > Regarding to authentication, as I explained before, if the tag size is n, > then you have collision issue among the tags when the number of tags goes > around 2^(n/2) which is not a good thing, but strictly speaking, this doe= s > not break your authentication. Carter-Wegman security results are weaker than for PRF-based MACs. > > > However, rekeying often is a good thing which could help prevent disaster= to > keep go on if there is something wrong with the IV or the key. > > > Quynh. > > > > > ________________________________ > From: Dang, Quynh > Sent: Monday, November 2, 2015 3:00 PM > To: Watson Ladd > Cc: tls@ietf.org; cfrg@ietf.org; Eric Rescorla > Subject: Re: [Cfrg] Collision issue in ciphertexts. > > > Now, you talked about a MAC function (with AES). I previously talked abou= t > encryption. > > > If I , the only person, uses the MAC key, when I generate more than 2^64 = MAC > values (Let's say each MAC value is 96 bits), I have many collided MAC > pairs. But, I am the only one (beside the person(s) verifying my MACs) wh= o > knows the MAC key in order to generate those verified MAC values. > > > If the MAC length is k bits, an attacker is allowed to send 2^n failed > verifications, his or her chance of success is approximately 2^n / 2^k. > Let's imagine n is 64 and k is 96, the success chance is 1/2^36 which is > practically ZERO! > > > If I am an attacker, I would choose a message that I want to be verified, > and I keep changing the MAC key to generate different MAC values with > different keys and hope one of them will get verified. Let's assume the = MAC > key to be 96 bits ( 96 bits of random bits, the other 32 bits are known).= In > theory, when I get close to 2^96 attempts, I would expect some chance of > success. To deal with this attacker, one would change the MAC key when th= e > number of failed attempts gets close to a number that you don't want. For > example, if you don't want a success chance of an attack to be above 1 / > 2^36, then you need to change your MAC key when the number of failed > verifications reaches 2^64 when your MAC length is 96 bits. > > > After you change the MAC key, I ( the attacker) will have to start > everything again because all of the failed MACs I generated before are > useless now. > > > ________________________________ > From: Watson Ladd > Sent: Monday, November 2, 2015 5:07 AM > To: Dang, Quynh > Cc: tls@ietf.org; cfrg@ietf.org; Eric Rescorla > Subject: Re: [Cfrg] Collision issue in ciphertexts. > > > > On Nov 2, 2015 2:14 AM, "Dang, Quynh" wrote: >> >> Hi Eric, >> >> >> As you asked the question about how many ciphertext blocks should be saf= e >> under a single key, I think it is safe to have 2^96 blocks under a given= key >> if the IV (counter) is 96 bits. > > This is wrong for PRP, right for PRF. It's not that hard to find the righ= t > result. > >> >> >> When there is a collision between two ciphertext blocks when two differe= nt >> counter values are used , the chance of the same plaintext was used twic= e is >> 1^128. Collisions start to happen a lot when the number of ciphertext >> blocks are above 2^64. However, each collision just reveals that the >> corresponding plaintext blocks are probably different ones. > > Which breaks IND-$. Let's not be clever, but stick to ensuring proven > definitions are true. > >> >> >> >> Quynh. >> >> >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> https://www.irtf.org/mailman/listinfo/cfrg >> > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Wed Nov 4 13:07: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 69DF41A6FCC for ; Wed, 4 Nov 2015 13:07:32 -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, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sfk9NA1U7IWc for ; Wed, 4 Nov 2015 13:07:30 -0800 (PST) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B6311A6FC9 for ; Wed, 4 Nov 2015 13:07:30 -0800 (PST) Received: by ykba4 with SMTP id a4so95806038ykb.3 for ; Wed, 04 Nov 2015 13:07:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=aRhSdA48GCIa/aenZ5MtN77ltfunjcoIOSdewE5lFKs=; b=NGd6O3l9j/OvnabYcwngC0OmyoT5PLzRVir9GiRNKwX4V58m0MgwOYqLgjX6fXtsv1 wsbAG/37Z8xqW2anQgs+gHq35tWJdl/19BNCUEF0I2XioNnwbyFafl7CZfDRQTMuwwdi mvrIUvwJZ+biU7GwaycGHj2PN2eIwdEj8p19FYvroEQforJPfV6ffRzsEhGagkFlk+Cq oPeroLU/fcTfQiWGE0bsjhxfztcYRkNTaQw7xwHWTqgmOF7E9MCngHk2uYjsvddUQnZC Zt9YNEDiVQ0Q7Ftrf2kHHxJPzTKgfDAtmPK6/g5PZDoNf1DHl00l9RvHsoBz9szXiwSN Zmzw== 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=aRhSdA48GCIa/aenZ5MtN77ltfunjcoIOSdewE5lFKs=; b=AVP5sJm/SWMsW4ZWLW77wYKpD+stth5/WyTdpn2DtjBbHVvepeM0FQip0cGN9S0//J fuQJvqo1twYnEbLNIkFFTD3VsuNQ729l2vGWSr8guORNCXNv0jg+zlhrYWMT83+E82Lh R8Y5CpjFgqkMKzONOCoe3GXtzEtzPT2awt/KtAZt8PK1dYDKCoJzRUQUbO7SQnFO3n7d lXwCEpUn3UWSkBT12Ze6EnHP0aWUXI7439mXQ8AvlR+3lSAVNNrSunIVvlLga5UQdlUs GkeSMjNSq3I4+aQBlGesDk9PCD/MGP2Q5Rs7WYPBk8+AAQEpJ7wib1RDByyARRppjfCo +0nw== X-Gm-Message-State: ALoCoQkLr3NegkIdDkBTC9BsJtc/PtvuL8kqHtrf1FK6F8f1Y7jcUu86WukECQnODOwWA6Hk/R7A X-Received: by 10.129.93.193 with SMTP id r184mr2985242ywb.115.1446671249477; Wed, 04 Nov 2015 13:07:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.221.203 with HTTP; Wed, 4 Nov 2015 13:06:50 -0800 (PST) In-Reply-To: <20151104172700.GA29224@LK-Perkele-V2.elisa-laajakaista.fi> References: <20151104172700.GA29224@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Thu, 5 Nov 2015 06:06:50 +0900 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a114d71d8eec15b0523bd6512 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] #311 (remove early_data) - Potential deadlock? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 21:07:32 -0000 --001a114d71d8eec15b0523bd6512 Content-Type: text/plain; charset=UTF-8 On Thu, Nov 5, 2015 at 2:27 AM, Ilari Liusvaara wrote: > I thought of following scenario: > > Client: ClientHello+0RTT > Server: 0RTT rejected. Fallback to 1RTT. > Server: (Drains 0-RTT records) > Client: Finished (corrupted in transit) > Client: Appdata (request for something) > Server: (Drains corrupt finished as 0-RTT record) > Server: (Drains appdata as 0-RTT record) > Client: (Waiting for response from server, handshake finished) > Server: (Waiting for Client Finished, handshake in progress) > *Deadlock?* > > > Can this actually happen? Or is it considered "too unlikely"? > Yes, this can happen, but there are much simpler deadlock scenarios in TLS if you allow for data corruption. Consider what happens if the client sends a ClientHello and the length bytes get changed from 128 to 129. The server will just sit there waiting for the rest. -Ekr > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a114d71d8eec15b0523bd6512 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Nov 5, 2015 at 2:27 AM, Ilari Liusvaara <<= a href=3D"mailto:ilariliusvaara@welho.com" target=3D"_blank">ilariliusvaara= @welho.com> wrote:
I though= t of following scenario:

Client: ClientHello+0RTT
Server: 0RTT rejected. Fallback to 1RTT.
Server: (Drains 0-RTT records)
Client: Finished (corrupted in transit)
Client: Appdata (request for something)
Server: (Drains corrupt finished as 0-RTT record)
Server: (Drains appdata as 0-RTT record)
Client: (Waiting for response from server, handshake finished)
Server: (Waiting for Client Finished, handshake in progress)
*Deadlock?*


Can this actually happen? Or is it considered "too unlikely"?
=

Yes, this can happen, but there are much s= impler deadlock scenarios in TLS
if you allow for data corruption= . Consider what =C2=A0happens if the client sends
a ClientHello a= nd the length bytes get changed from 128 to 129. The server
will = just sit there waiting for the rest.

-Ekr


-Ilari

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

--001a114d71d8eec15b0523bd6512-- From nobody Thu Nov 5 01:47: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 0470A1A9082 for ; Thu, 5 Nov 2015 01:47:54 -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 SjuTlmBQpS-E for ; Thu, 5 Nov 2015 01:47:52 -0800 (PST) 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 9DA4E1A906C for ; Thu, 5 Nov 2015 01:47:52 -0800 (PST) Received: by ykba4 with SMTP id a4so121177129ykb.3 for ; Thu, 05 Nov 2015 01:47:52 -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=6w5QEOd6AJ83RE6vmyDM/dEF4ez0eqNiADvlQdvAg48=; b=TdUvHyuaDGkmItDbfLC6KPbirr0/5bUAyCY2jtLi/7KEQ438is7AeeIjK4g4iLx4V+ /xcj5VxxJMwI0pRLHfyt4zRlMG3MwWPwb3rW/Fa8hGbRHIi/W5+mkjtM+B/5t46PESWO j00z8DAXV6JYBU7z1KuVTEZRKS4UDbp0u38k1oa+1MLq2z019JZUjw65N28a/bROnq1U AnMO31oAPvPV6i191hGzcmWvBMlxQUDABDGkm5a6cYGmKwe+NdSbZcnZFniouJZx8emk HksJ/5jRzI6y2UFAGzpjH2DQ+wfA5QPc/jFPE3G0lpzu886IZ/7VupLYfe8TFH7ZKR3O K5Dw== MIME-Version: 1.0 X-Received: by 10.129.79.6 with SMTP id d6mr6187298ywb.120.1446716871996; Thu, 05 Nov 2015 01:47:51 -0800 (PST) Received: by 10.129.132.145 with HTTP; Thu, 5 Nov 2015 01:47:51 -0800 (PST) Date: Thu, 5 Nov 2015 18:47:51 +0900 Message-ID: From: Martin Thomson To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] SHA-1 patch updated with Russ' suggestion X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 09:47:54 -0000 Nitpicks accepted, pull requests preferred: https://github.com/tlswg/tls13-spec/pull/317 From nobody Thu Nov 5 13:38: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 876FE1B3355 for ; Thu, 5 Nov 2015 13:38:38 -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 IQf-yf1_aVc2 for ; Thu, 5 Nov 2015 13:38:36 -0800 (PST) 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 5F5761B3344 for ; Thu, 5 Nov 2015 13:38:35 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 640FE28304A; Thu, 5 Nov 2015 21:38:34 +0000 (UTC) Date: Thu, 5 Nov 2015 21:38:34 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20151105213834.GB18315@mournblade.imrryr.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] SHA-1 patch updated with Russ' suggestion X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 21:38:38 -0000 On Thu, Nov 05, 2015 at 06:47:51PM +0900, Martin Thomson wrote: > Nitpicks accepted, pull requests preferred: > > https://github.com/tlswg/tls13-spec/pull/317 I am having a hard time figuring out what's changing. Can you summarize the proposal? I'd like it to say: * The signature algorithms of self-signed certificates are not subject to any constraints on either the supplicant or the verifier. They are not required to match the supported signature algorithms of the peer, are not required to avoid deprecated algorithms, and their self-signatures SHOULD NOT be checked. * A "compatible" certificate message (ideally a certificate chain) is one in which each certificate is either self-signed or else is signed with a supported signature algorithm advertised by the peer. * A "non-SHA1" certificate message is a certificate message in which each certificate is either self-signed or else is signed with a signature algorithm other than SHA-1. * A certificate message provided for verification to the peer MUST be compatible if at all possible. * A compatible certificate message MUST be "non-SHA1" if at at all possible. * When it is not possible to send a compatible certificate message, a suitable default certificate message, in which signature algorithms not known to be supported by the peer MAY be sent. The onus of determining whether such a chain is trustworthy falls exclusively on the verifier. * If a verifier determines that the chain is not trustworthy it MAY elect to abort the hanshake with a corresponding fatal alert. If the chain is not trusted because it depends on an unsupported signature algorithm, then the appropriate alert is unsupported_certificate(43). Note that the pull request contains harmful text: Any endpoint receiving any certificate signed using any signature algorithm using an MD5 hash MUST send a "bad_certificate" alert message and close the connection. This breaks peers that send the self-signed CAcert root CA as part of their chain. The correct language would be: Certificates signed with a signature algorithm based on the MD5 hash that are not self-signed MUST NOT be trusted, even if signed by a trusted issuer (and not expired, etc.). I should note that the harmful text is at least on the correct side of the supplicant/verifier divide. We protect nobody by restricting what legitimate supplicants can send, that just lulls verifiers into a false sense of security (they might not check for conditions that they are not typically exposed to). We need to protect verifiers from what malicious actors will send, and malicious actors will not play nice by avoiding MD5 and SHA-1. So the emphasis needs to be clearly on the responsibilities of the verifier. Furthermore, questions of whether the chain is trusted or not trusted belong in the layer doing PKIX (5280) trust chain construction, not the layer doing TLS protocol message processing. I will make sure that OpenSSL's stack for TLS 1.3 does not accept MD5 signatures as trusted and (by default) won't accept SHA-1 as trusted either. The simplest implementation is to delete all non-leaf certificates from the received chain that use disabled or unsupported algorithms and then construct the chain from what remains. If no trusted chain can be built, succeed or fail accordingly. Some peers will be opportunistic and go on regardless. Some peers will require a secure connection, but will complete the connection and then gracefully disconnect at the application layer. Other peers will abort the handshake and close with a fatal alert. The logic unequivocally belongs in the verifier as it always did. The lower levels of the protocol MUST NOT get in the way. -- Viktor. From nobody Thu Nov 5 13:59: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 31F151B3C27 for ; Thu, 5 Nov 2015 13:59:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7wBsZ3vtcvNm for ; Thu, 5 Nov 2015 13:59:21 -0800 (PST) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::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 EAE181B3C25 for ; Thu, 5 Nov 2015 13:59:20 -0800 (PST) Received: by ykdr3 with SMTP id r3so156940198ykd.1 for ; Thu, 05 Nov 2015 13:59:20 -0800 (PST) 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=z8LkXBgfQ40jl4D7J7796AJJxqDqA8ITRTcn8WtubR8=; b=NGqrUSqcXUL6Q1W+27K9UnhN2ItFI7Vxh0AzXnKG0Mg0uuxgHl20AE/jiqyGpvcEh/ JeXFk4KJEE1qzVtZB9KHE594mOm30BmjYDYshta+sTIQFbxBS5IFFv0P05DCYNHj9h6P Bka60pwRNb5KV/YEcva9d4X7tS5Xed3DGnETEJYPt+N7hWLDwhfUCAGKZ0g/Lqbpmr0g sG1VZ9qIjJ52WgAS2WPFlWW0YqQfJrV7plJmDRiHYPsZ6TrDM7lZZDoSf2B1nrq503JA 7yG9WFpIj5v4opITf3P/ZfBM6QRQE8Ne4ao0403qPHAXHyUyiSYP8Fouj6ClNr5EjrhB J7+Q== X-Received: by 10.129.75.131 with SMTP id y125mr9583926ywa.48.1446760760311; Thu, 05 Nov 2015 13:59:20 -0800 (PST) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id l68sm5902763ywd.3.2015.11.05.13.59.19 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 05 Nov 2015 13:59:19 -0800 (PST) From: Dave Garrett To: tls@ietf.org, Viktor Dukhovni Date: Thu, 5 Nov 2015 16:59:18 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20151105213834.GB18315@mournblade.imrryr.org> In-Reply-To: <20151105213834.GB18315@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201511051659.18674.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] SHA-1 patch updated with Russ' suggestion X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 21:59:22 -0000 On Thursday, November 05, 2015 04:38:34 pm Viktor Dukhovni wrote: > I'd like it to say: > > * The signature algorithms of self-signed certificates are > not subject to any constraints on either the supplicant or > the verifier. They are not required to match the supported > signature algorithms of the peer, are not required to avoid > deprecated algorithms, and their self-signatures SHOULD NOT > be checked. Why "SHOULD NOT be checked"? I don't think it needs to say anything about checking self-signatures here, one way or another. Dave From nobody Thu Nov 5 14:05: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 D13501B3C3F for ; Thu, 5 Nov 2015 14:05:04 -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 V263cXwjqeQj for ; Thu, 5 Nov 2015 14:05:03 -0800 (PST) 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 662A81B3C3D for ; Thu, 5 Nov 2015 14:05:03 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 6AE5628304A; Thu, 5 Nov 2015 22:05:02 +0000 (UTC) Date: Thu, 5 Nov 2015 22:05:02 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20151105220502.GC18315@mournblade.imrryr.org> References: <20151105213834.GB18315@mournblade.imrryr.org> <201511051659.18674.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201511051659.18674.davemgarrett@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] SHA-1 patch updated with Russ' suggestion X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 22:05:05 -0000 On Thu, Nov 05, 2015 at 04:59:18PM -0500, Dave Garrett wrote: > On Thursday, November 05, 2015 04:38:34 pm Viktor Dukhovni wrote: > > I'd like it to say: > > > > * The signature algorithms of self-signed certificates are > > not subject to any constraints on either the supplicant or > > the verifier. They are not required to match the supported > > signature algorithms of the peer, are not required to avoid > > deprecated algorithms, and their self-signatures SHOULD NOT > > be checked. > > Why "SHOULD NOT be checked"? I don't think it needs to say anything about checking self-signatures here, one way or another. The verifier always has a trusted out-of-band copy of each trust-anchor. Checking the self-signature may needlessly run into problems when its deprecated algorithm is no longer even implemented in the crypto library. And yet the trust-anchor is still fine. If this is the only point on which I'm in the rough, so be it, but as a starting position I think it makes to avoid needless breakage. -- Viktor. From nobody Thu Nov 5 15:53: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 370CC1B3788 for ; Thu, 5 Nov 2015 15:53:50 -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 z8z30iMpOSW2 for ; Thu, 5 Nov 2015 15:53:48 -0800 (PST) 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 C19E61B3789 for ; Thu, 5 Nov 2015 15:53:48 -0800 (PST) Received: by ykdv3 with SMTP id v3so71986235ykd.0 for ; Thu, 05 Nov 2015 15:53:48 -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=xgtqhT+45BTU/RLBYE9ZYTlmU6sX+W4AARIuOpuaDt4=; b=xI93gh0IkUZVEmwl2DZdotPeNl92rD+i1LZj0Mnofn8gvRVBkvJeClbNaQAqUU8qck b9arFMUCrTigyFEQBFkGhFtruZPab+xgwia31SqNuyeuULmcJSkbwEANAoY32aRUPskc bajXHCS3zyvpfSJdIgQM4V9mnydvejESh+EubK1+lkoLG+Gz/ZPJdEBNnYZ4x6qrLRmR q6hOsp0smxcx0OhNBZtcAJhlS8M+Xro6sFZfjrcNmf/q6JMbICUODddDZ9QW80BlsGC7 SW9nj87uApSxhYhvBxCa40VkSF6Be894oZG43pPOov69I9mhGYJq4sXYYfqBiYQ5oHAt LKsQ== X-Received: by 10.129.40.214 with SMTP id o205mr8721783ywo.145.1446767628183; Thu, 05 Nov 2015 15:53:48 -0800 (PST) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id i132sm6246520ywb.9.2015.11.05.15.53.47 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 05 Nov 2015 15:53:47 -0800 (PST) From: Dave Garrett To: Viktor Dukhovni Date: Thu, 5 Nov 2015 18:53:46 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201511051659.18674.davemgarrett@gmail.com> <20151105220502.GC18315@mournblade.imrryr.org> In-Reply-To: <20151105220502.GC18315@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201511051853.46672.davemgarrett@gmail.com> Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] SHA-1 patch updated with Russ' suggestion X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 23:53:50 -0000 On Thursday, November 05, 2015 05:05:02 pm Viktor Dukhovni wrote: > On Thu, Nov 05, 2015 at 04:59:18PM -0500, Dave Garrett wrote: > > > On Thursday, November 05, 2015 04:38:34 pm Viktor Dukhovni wrote: > > > I'd like it to say: > > > > > > * The signature algorithms of self-signed certificates are > > > not subject to any constraints on either the supplicant or > > > the verifier. They are not required to match the supported > > > signature algorithms of the peer, are not required to avoid > > > deprecated algorithms, and their self-signatures SHOULD NOT > > > be checked. > > > > Why "SHOULD NOT be checked"? I don't think it needs to say anything about checking self-signatures here, one way or another. > > The verifier always has a trusted out-of-band copy of each > trust-anchor. Checking the self-signature may needlessly run into > problems when its deprecated algorithm is no longer even implemented > in the crypto library. And yet the trust-anchor is still fine. Ideally, if the implementation is trusting certs as a whole, then it should be attempting to validate self-signatures upon addition to the trust store. If the cert received matches exactly, then it has been checked; redoing it isn't helpful. I note "attempt to validate" and agree that failing but still agreeing to trust the cert could be fine. Essentially, I'd rather it say something to the effect of: "Trusted self-signatures SHOULD be validated before adding to a trust store and SHOULD NOT be re-checked at runtime." But we're getting slightly out of scope here, which is why I'm thinking that elaborating on this topic exactly as suggested is not needed in the document. Dave From nobody Thu Nov 5 16:29: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 B29E71A6FE5 for ; Thu, 5 Nov 2015 16:29:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 DnDBjbXKpCRq for ; Thu, 5 Nov 2015 16:29:45 -0800 (PST) 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 DC4A01A6FBC for ; Thu, 5 Nov 2015 16:29:44 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 0A6DC28304A; Fri, 6 Nov 2015 00:29:43 +0000 (UTC) Date: Fri, 6 Nov 2015 00:29:42 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20151106002942.GD18315@mournblade.imrryr.org> References: <201511051659.18674.davemgarrett@gmail.com> <20151105220502.GC18315@mournblade.imrryr.org> <201511051853.46672.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201511051853.46672.davemgarrett@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] SHA-1 patch updated with Russ' suggestion X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 00:29:46 -0000 On Thu, Nov 05, 2015 at 06:53:46PM -0500, Dave Garrett wrote: > On Thursday, November 05, 2015 05:05:02 pm Viktor Dukhovni wrote: > > On Thu, Nov 05, 2015 at 04:59:18PM -0500, Dave Garrett wrote: > > > > > On Thursday, November 05, 2015 04:38:34 pm Viktor Dukhovni wrote: > > > > I'd like it to say: > > > > > > > > * The signature algorithms of self-signed certificates are > > > > not subject to any constraints on either the supplicant or > > > > the verifier. They are not required to match the supported > > > > signature algorithms of the peer, are not required to avoid > > > > deprecated algorithms, and their self-signatures SHOULD NOT > > > > be checked. > > > > > > Why "SHOULD NOT be checked"? I don't think it needs to say anything > > > about checking self-signatures here, one way or another. > > > > The verifier always has a trusted out-of-band copy of each > > trust-anchor. Checking the self-signature may needlessly run into > > problems when its deprecated algorithm is no longer even implemented > > in the crypto library. And yet the trust-anchor is still fine. > > Ideally, if the implementation is trusting certs as a whole, then it should > be attempting to validate self-signatures upon addition to the trust store. > If the cert received matches exactly, then it has been checked; redoing > it isn't helpful. I note "attempt to validate" and agree that failing but > still agreeing to trust the cert could be fine. Essentially, I'd rather > it say something to the effect of: "Trusted self-signatures SHOULD be > validated before adding to a trust store and SHOULD NOT be re-checked at > runtime." But we're getting slightly out of scope here, which is why I'm > thinking that elaborating on this topic exactly as suggested is not needed > in the document. Good, we essentially agree on the preferred implementation behaviour, what remains to quibble over is how explicit the text should be in that direction. And your more nuanced formulation is fine. I think that some implementation guidance is reasonable, but it can be weaker than "SHOULD". Implementations need to be strict where necessary, but being "strict" where unnecessary is bad, because connections break or downgrade to cleartext in cases that would otherwise just work. Having seen both a considerable lack of necessary checks in many implementations, *and* a considerable excess of counter-productive unnecessary checks, I prefer to give implementation guidance where there is non-negligible risk of either type of error. This particular issue is one where Schannel, for example, is at present not implemented correctly. It aborts handshakes when clients present CAcert.org issued certificates along with the issuer root CA cert. In SMTP to outlook.com this typically downgrades STARTTLS to cleartext for senders configured with client certs as described. Yes, I still agree that this is not a major issue, and if the core issues around client and server obligations are sorted, I can live with silence on this question if it is felt that guidance of this type detracts too much from the document. -- Viktor. From nobody Thu Nov 5 17:16: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 413E31ACEDD for ; Thu, 5 Nov 2015 17:16:27 -0800 (PST) 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 zUJ4RW4wAb9N for ; Thu, 5 Nov 2015 17:16:25 -0800 (PST) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 3A82B1ACE84 for ; Thu, 5 Nov 2015 17:16:25 -0800 (PST) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id A55C8F24181; Thu, 5 Nov 2015 20:16:14 -0500 (EST) 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 GoYq3qvufQ+4; Thu, 5 Nov 2015 20:14:40 -0500 (EST) Received: from dhcp-31-62.meeting.ietf94.jp (unknown [133.93.31.62]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 71606F24189; Thu, 5 Nov 2015 20:15:44 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: Date: Thu, 5 Nov 2015 20:15:31 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <473B9694-E659-4ED8-B7F3-CDC68F1E661F@vigilsec.com> References: To: Martin Thomson X-Mailer: Apple Mail (2.1085) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] SHA-1 patch updated with Russ' suggestion X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 01:16:27 -0000 Martin: > Nitpicks accepted, pull requests preferred: >=20 > https://github.com/tlswg/tls13-spec/pull/317 It might be useful to remind people about the difference between = self-signed certificates and self-issued certificates. RFC 5280 says: Self-signed certificates are self-issued certificates where the = digital signature may be verified by the public key bound into the certificate. Self-signed certificates are used to convey a public key for use to begin certification paths. Self-issued certificates are CA certificates in which the issuer and subject are the same entity. Self-issued certificates can appear in the middle of a path when a CA is = doing key rollover and is doing old-signed-by-new and new-signed-by-old. = The rollover approach is described in RFC 2510; look for "key update". Self-signed certificates are one very popular way to distribute the = public key and distinguished name for a trust anchor. The certification = path validation procedures in Section 6 of RFC 5280 do not validate the = signature on such a sel-signed certificate. It says: When the trust anchor is provided in the form of a self-signed certificate, this self-signed certificate is not included as part of the prospective certification path. Russ From nobody Thu Nov 5 17:47: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 895931B2A7A for ; Thu, 5 Nov 2015 17:47:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0_uU2phiLT3N for ; Thu, 5 Nov 2015 17:47:33 -0800 (PST) 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 DAD551ACD7E for ; Thu, 5 Nov 2015 17:47:32 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id A5BDB28304A; Fri, 6 Nov 2015 01:47:31 +0000 (UTC) Date: Fri, 6 Nov 2015 01:47:31 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20151106014731.GF18315@mournblade.imrryr.org> References: <473B9694-E659-4ED8-B7F3-CDC68F1E661F@vigilsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <473B9694-E659-4ED8-B7F3-CDC68F1E661F@vigilsec.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] SHA-1 patch updated with Russ' suggestion X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 01:47:34 -0000 On Thu, Nov 05, 2015 at 08:15:31PM -0500, Russ Housley wrote: > It might be useful to remind people about the difference between self-signed > certificates and self-issued certificates. RFC 5280 says: > > Self-signed certificates are self-issued certificates where the digital > signature may be verified by the public key bound into the > certificate. Self-signed certificates are used to convey a public > key for use to begin certification paths. > Self-issued certificates are CA certificates in which > the issuer and subject are the same entity. > > Self-issued certificates can appear in the middle of a path when a CA is > doing key rollover and is doing old-signed-by-new and new-signed-by-old. > The rollover approach is described in RFC 2510; look for "key update". Thanks, I tried to use the right term in this discussion, and by luck or otherwise seem to have gotten it right. > Self-signed certificates are one very popular way to distribute the public > key and distinguished name for a trust anchor. The certification path > validation procedures in Section 6 of RFC 5280 do not validate the signature > on such a sel-signed certificate. It says: > > When the trust anchor is provided in the form of a self-signed > certificate, this self-signed certificate is not included as part of > the prospective certification path. Which is I think consistent with a recommendation to not check the self-signatures of trust anchors. In OpenSSL the definition of self-issued is as you explained, while self-signed requires all of the below. * Self-issued as a pre-requisite. * If an authority key id is present, it must match. * If keyUsage is present, it must permit certificate signing[0] So for a CA, a self-issued certificate can avoid being self-signed by having an authority key identifier that through its key id, or serial number identifies some other certificate as the issuer. -- Viktor. [0] The check of the keyUsage is a recent addition. From nobody Fri Nov 6 10: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 9BD211B2EB6 for ; Fri, 6 Nov 2015 10:44:15 -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 4lQclQEE3gbe for ; Fri, 6 Nov 2015 10:44:14 -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 3BAEF1B2EB3 for ; Fri, 6 Nov 2015 10:44:14 -0800 (PST) Received: by qgec40 with SMTP id c40so37781629qge.2 for ; Fri, 06 Nov 2015 10:44:13 -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=VLNL2JmwPlFFMyk9o73Fw7r3Zs0N9yc2aOsKmvkjWqM=; b=Ckgg8Cn+uRJ+8gGK0+RlgIZhNnyFkZO9IwFl2YIpaF0wma2JliHuYWxL0HVq+hu+4f FzNlDCnv5hWs9jvTw3yi4hjVwq3RnvjVTMpEOSDdqewUuVk0Sd5GUZHiNeOMIym3DxFs Vi5QJPLus0/fczxu+KrSmib94sfUOBWn1SmBcDJkH0X63ZEFLToDwrPq7fngYsDilETF SMZlPx8dQRa0IkCX8UbTwwEWTQSoAZoHUlQy7WNJb3JVeR3D8SQr1HD3wuZ4fmSHcFcL S6QvHLyBBRcfEwOZ6VKGXKauUMBBoBy6PnhRBwFs7EZViu4CAFOst29XcS8zjCaUTk9U 0OHg== MIME-Version: 1.0 X-Received: by 10.140.171.197 with SMTP id r188mr16155392qhr.93.1446835453407; Fri, 06 Nov 2015 10:44:13 -0800 (PST) Sender: alangley@gmail.com Received: by 10.140.81.241 with HTTP; Fri, 6 Nov 2015 10:44:13 -0800 (PST) In-Reply-To: References: <20151102220617.22528.91021.idtracker@ietfa.amsl.com> Date: Fri, 6 Nov 2015 10:44:13 -0800 X-Google-Sender-Auth: oEevua_hKpH7OiVVauVoq0ZFmxc Message-ID: From: Adam Langley To: Brian Smith Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] I-D Action: draft-ietf-tls-chacha20-poly1305-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: Fri, 06 Nov 2015 18:44:15 -0000 On Tue, Nov 3, 2015 at 11:29 AM, Brian Smith wrote: > Brian Smith wrote: >> >> This way, one Poly1305 invocation per record could be saved, potentially, >> forapplication_data records, which is the common case. > > > This is still true, but... > >> >> An implementation that avavoids sending encrypted alerts and avoids >> renegotiation could avoid writing code for the case where non-empty AAD is >> needed, and could share the exact same code between TLS 1.2 and TLS 1.3 for >> ChaCha20-Poly1305. > > > This isn't true, because of the Finished message. So, it is not quite as > good of an idea as I thought, but still it seems like it could be > worthwhile. My feelings on this are not strong either way but I tend towards keeping it simple, which to me means that this cipher suite will use the standard AD value for the TLS version in use. Saving a single Poly1305 block per record isn't a big deal and it looks like we'll get it anyway with TLS 1.3. So, for the moment, I'm not planning on adding anything to that effect. Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Fri Nov 6 11:10:11 2015 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 65E621B2EFC; Fri, 6 Nov 2015 11:10:09 -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: 6.8.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151106191009.7959.27617.idtracker@ietfa.amsl.com> Date: Fri, 06 Nov 2015 11:10:09 -0800 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-chacha20-poly1305-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: Fri, 06 Nov 2015 19:10:09 -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 : ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS) Authors : Adam Langley Wan-Teh Chang Nikos Mavrogiannopoulos Joachim Strombergson Simon Josefsson Filename : draft-ietf-tls-chacha20-poly1305-02.txt Pages : 7 Date : 2015-11-06 Abstract: This document describes the use of the ChaCha stream cipher and Poly1305 authenticator in the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-chacha20-poly1305/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tls-chacha20-poly1305-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-chacha20-poly1305-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 Fri Nov 6 11:11: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 767371ACEFB for ; Fri, 6 Nov 2015 11:11:31 -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 CjijcXlhdkEC for ; Fri, 6 Nov 2015 11:11:30 -0800 (PST) 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 ED25F1AC40D for ; Fri, 6 Nov 2015 11:11:29 -0800 (PST) Received: by qgeb1 with SMTP id b1so45960840qge.1 for ; Fri, 06 Nov 2015 11:11:29 -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=pQA60Dn6GO++8M4V8xgmjQx2kjFSSmwGKUkRypbUEQk=; b=mDg/zCgbqJJaknfM1uVKTA2D8nYqLbFzbW/+GxxsLMTtihh3S7kD9MEvj7RcpK++mQ V3hyd6690ViknsmCQPLbtMIL7ckkP9F7b34CH/P98eWmiV0x1ibS+uCKT/VQUL2UCg0m jJkn9V164Wejpr2kT2NYbjlpvSsRYQlYK69HxmsqsMPTpuMK4eQAo728IEUMk3hRLP3K jViMLcy8xM/hiXkVWHWuuyf70iGdR8k8L6d30aaP+Py7JA6ckUPDNrxeMuANSqwvw/6W +AhpG81mJrW85S8bN5Rj28KdbrZkGFZ3S20+vwBkbnk3kPwrTrz/M61uDPnnpm1CSCXL Ap6A== MIME-Version: 1.0 X-Received: by 10.140.201.139 with SMTP id w133mr15865360qha.15.1446837089172; Fri, 06 Nov 2015 11:11:29 -0800 (PST) Sender: alangley@gmail.com Received: by 10.140.81.241 with HTTP; Fri, 6 Nov 2015 11:11:29 -0800 (PST) In-Reply-To: <1446546877.3276.21.camel@redhat.com> References: <20151102220617.22528.91021.idtracker@ietfa.amsl.com> <1446546877.3276.21.camel@redhat.com> Date: Fri, 6 Nov 2015 11:11:29 -0800 X-Google-Sender-Auth: kI5W2zH6xFleL7yZ44XrDKHVRU4 Message-ID: From: Adam Langley To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] I-D Action: draft-ietf-tls-chacha20-poly1305-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: Fri, 06 Nov 2015 19:11:31 -0000 On Tue, Nov 3, 2015 at 2:34 AM, Nikos Mavrogiannopoulos wrote: > I agree that protecting the length of the communicated data is > important, but there is nothing specific to this cipher. All modern TLS > ciphers today are stream ciphers (i.e., AES-GCM and AES-CCM (*)), so > they offer the same protection as chacha20 with respect to hiding the > length. Maybe we should add a note about that in the security > considerations. I've added the following to the security considerations section in -02: It should be noted that AEADs, such as ChaCha20-Poly1305, are not intended to hide the lengths of plaintext. When this document speaks of side-channel attacks, it is not considering traffic analysis, but rather timing and cache side-channels. Traffic analysis, while a valid concern, is outside the scope of the AEAD and is being addressed elsewhere in future versions of TLS. Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Fri Nov 6 11: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 4FA6B1ACF07 for ; Fri, 6 Nov 2015 11:12:46 -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 M5pGfmiTAw8e for ; Fri, 6 Nov 2015 11:12:45 -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 148271ACEFB for ; Fri, 6 Nov 2015 11:12:45 -0800 (PST) Received: by qgec40 with SMTP id c40so38401519qge.2 for ; Fri, 06 Nov 2015 11:12:44 -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=uMjPYM9IXudrdJwNiJpPyjIvU2DhVYuZuUYDpjxjf/A=; b=VaJMdjsmN/Rv3t/NN4tF41zZyF/NUbzMmOL3T1p4hG3tjKJpxTMsHyBWg0xvjHU0pM JGc0+/0h8TIN3PpMT9bQtUSBd4f6yo63BsYMRdN9DIp7ItZjzWcOe2ueCdwEFALecpQg VJIrXkh3n83WoNdxRuyb/N+TyoT+om100vFtfT53MkoMBSvXharxDVuvjL1o+lUOMMVk sZnkTbKd3pfTTh5mlDlvjbClFvZ4e34DBxBAYGPPwYPf6PZ7L8xqUzMZFd8hOUq2RGZV 6/wvkCL4tEDTQu5L37syBzEov7ZaSN20Rp4oa34NEP993ac7c3xTinZwcoxwHBJdbDqF Vtfg== MIME-Version: 1.0 X-Received: by 10.140.34.204 with SMTP id l70mr15135359qgl.24.1446837164251; Fri, 06 Nov 2015 11:12:44 -0800 (PST) Sender: alangley@gmail.com Received: by 10.140.81.241 with HTTP; Fri, 6 Nov 2015 11:12:44 -0800 (PST) In-Reply-To: <5638E015.3060804@akamai.com> References: <20151102220617.22528.91021.idtracker@ietfa.amsl.com> <5638E015.3060804@akamai.com> Date: Fri, 6 Nov 2015 11:12:44 -0800 X-Google-Sender-Auth: XXCPlaP0LWtXk09S5DewP5vlfOs Message-ID: From: Adam Langley To: Benjamin Kaduk Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] I-D Action: draft-ietf-tls-chacha20-poly1305-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: Fri, 06 Nov 2015 19:12:46 -0000 On Tue, Nov 3, 2015 at 8:25 AM, Benjamin Kaduk wrote: > % 1. The 64-bit record sequence number is serialized as an 8-byte, > % big-endian value and padded on the left with 4 zeroes. > > I assume you mean zero octets/bytes, and not ASCII '0' (or EBCDIC, or ...) > > "padded on the left" also has some potential for ambiguity (though not as much); something about "four zero octets are prepended to the stream" might be less ambiguous. Sorry, I missed seeing this for -02, but I now have locally, for the next revision: "The 64-bit record sequence number is serialized as an 8-byte, big-endian value and padded on the left with four 0x00 bytes." Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Fri Nov 6 16:27: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 62BB81B3136 for ; Fri, 6 Nov 2015 16:27:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgBo8pnI7ec8 for ; Fri, 6 Nov 2015 16:27:54 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::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 E5C4E1B3135 for ; Fri, 6 Nov 2015 16:27:53 -0800 (PST) Received: by wmnn186 with SMTP id n186so54851891wmn.1 for ; Fri, 06 Nov 2015 16:27:52 -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=ZIF1uSNAJKa7A0aC67pC29wWwyaTFbCHmP4UiNJOPI0=; b=gsCTW0+G/flyBGKP1SV6rOlDBYOV7WvBmnCIRzb+nj/S7ZqKPYEDgR9lpeQA24GaB5 Uhw5MshYwF2dmffQQXBDay3euiVDOTt5ppubJL7RutxHwcP7zrZLB8tCuftKBK+koco+ C3KcLLp9R0O8y6rDyZyVe1UwScUxa3dU1iSHXpXRiBs6gTwcEAiL2LHnUxkbsoc83xgf TWN6eVxmrsFsg63M7XPEnn+D9KHzvwkJGgYHnX5KtWJhHHL5CRVvRjZ+sNDVgtrKfNVO C/Bg2G3U81FMU4GaYpFKUnuY0CraqD0tJaRngpb0nLA6sKPM3EN/Dk3UJzgv/hcRuzfv XuxA== MIME-Version: 1.0 X-Received: by 10.28.129.131 with SMTP id c125mr9451276wmd.21.1446856072560; Fri, 06 Nov 2015 16:27:52 -0800 (PST) Received: by 10.28.101.212 with HTTP; Fri, 6 Nov 2015 16:27:52 -0800 (PST) In-Reply-To: References: <811734cd29d64adc98c5388870611575@XCH-ALN-004.cisco.com> Date: Fri, 6 Nov 2015 19:27:52 -0500 Message-ID: From: Watson Ladd To: "Dang, Quynh" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data limit for GCM under a given key. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2015 00:27:56 -0000 On Wed, Nov 4, 2015 at 3:43 PM, Dang, Quynh wrote: > I did not talk under indistinguishability framework. My discussion was about confidentiality protection and authentication. What is the definition of "confidentiality protection" being used here? > > Quynh. > ________________________________________ > From: Watson Ladd > Sent: Wednesday, November 4, 2015 3:17:00 PM > To: Dang, Quynh > Cc: Eric Rescorla; tls@ietf.org > Subject: Re: [TLS] Data limit for GCM under a given key. > > On Wed, Nov 4, 2015 at 2:29 PM, Dang, Quynh wrote: >> Hi Eric and all, >> >> >> The limit of 2^48 packets under a given key for GCM you mentioned today is >> the limit for SRTP >> (https://tools.ietf.org/html/draft-ietf-avtcore-srtp-aes-gcm-17#section-6). >> The nonce space of the IV construction is only 48 bits and that is why it >> has the limit of 2^48. The limit here should be 2^48 blocks, not records as >> stated in the document. >> >> >> As I explained before, GCM is counter mode for encryption. For a given key, >> the nonce never repeats globally, then confidentiality of the encrypted data >> is preserved. When the nonce space is 2^n values, then 2^n message blocks >> can have secure confidentiality protection. > > This is completely untrue. If you actually understood the definitions, > and thought about the matter for 15 minutes, you would realize that > permutations are distinguishable from functions after 2^(n/2) queries > with high probabilities, and this breaks IND-$. This is an elementary > result found on page 134 of Boneh-Shoup. > >> >> >> Regarding to authentication, as I explained before, if the tag size is n, >> then you have collision issue among the tags when the number of tags goes >> around 2^(n/2) which is not a good thing, but strictly speaking, this does >> not break your authentication. > > Carter-Wegman security results are weaker than for PRF-based MACs. >> >> >> However, rekeying often is a good thing which could help prevent disaster to >> keep go on if there is something wrong with the IV or the key. >> >> >> Quynh. >> >> >> >> >> ________________________________ >> From: Dang, Quynh >> Sent: Monday, November 2, 2015 3:00 PM >> To: Watson Ladd >> Cc: tls@ietf.org; cfrg@ietf.org; Eric Rescorla >> Subject: Re: [Cfrg] Collision issue in ciphertexts. >> >> >> Now, you talked about a MAC function (with AES). I previously talked about >> encryption. >> >> >> If I , the only person, uses the MAC key, when I generate more than 2^64 MAC >> values (Let's say each MAC value is 96 bits), I have many collided MAC >> pairs. But, I am the only one (beside the person(s) verifying my MACs) who >> knows the MAC key in order to generate those verified MAC values. >> >> >> If the MAC length is k bits, an attacker is allowed to send 2^n failed >> verifications, his or her chance of success is approximately 2^n / 2^k. >> Let's imagine n is 64 and k is 96, the success chance is 1/2^36 which is >> practically ZERO! >> >> >> If I am an attacker, I would choose a message that I want to be verified, >> and I keep changing the MAC key to generate different MAC values with >> different keys and hope one of them will get verified. Let's assume the MAC >> key to be 96 bits ( 96 bits of random bits, the other 32 bits are known). In >> theory, when I get close to 2^96 attempts, I would expect some chance of >> success. To deal with this attacker, one would change the MAC key when the >> number of failed attempts gets close to a number that you don't want. For >> example, if you don't want a success chance of an attack to be above 1 / >> 2^36, then you need to change your MAC key when the number of failed >> verifications reaches 2^64 when your MAC length is 96 bits. >> >> >> After you change the MAC key, I ( the attacker) will have to start >> everything again because all of the failed MACs I generated before are >> useless now. >> >> >> ________________________________ >> From: Watson Ladd >> Sent: Monday, November 2, 2015 5:07 AM >> To: Dang, Quynh >> Cc: tls@ietf.org; cfrg@ietf.org; Eric Rescorla >> Subject: Re: [Cfrg] Collision issue in ciphertexts. >> >> >> >> On Nov 2, 2015 2:14 AM, "Dang, Quynh" wrote: >>> >>> Hi Eric, >>> >>> >>> As you asked the question about how many ciphertext blocks should be safe >>> under a single key, I think it is safe to have 2^96 blocks under a given key >>> if the IV (counter) is 96 bits. >> >> This is wrong for PRP, right for PRF. It's not that hard to find the right >> result. >> >>> >>> >>> When there is a collision between two ciphertext blocks when two different >>> counter values are used , the chance of the same plaintext was used twice is >>> 1^128. Collisions start to happen a lot when the number of ciphertext >>> blocks are above 2^64. However, each collision just reveals that the >>> corresponding plaintext blocks are probably different ones. >> >> Which breaks IND-$. Let's not be clever, but stick to ensuring proven >> definitions are true. >> >>> >>> >>> >>> Quynh. >>> >>> >>> _______________________________________________ >>> Cfrg mailing list >>> Cfrg@irtf.org >>> https://www.irtf.org/mailman/listinfo/cfrg >>> >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > > > -- > "Man is born free, but everywhere he is in chains". > --Rousseau. -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Fri Nov 6 16:59: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 41C471B3185 for ; Fri, 6 Nov 2015 16:59:11 -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 Lzjh5WFGHVf5 for ; Fri, 6 Nov 2015 16:59:09 -0800 (PST) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C473C1B3183 for ; Fri, 6 Nov 2015 16:59:09 -0800 (PST) Received: by ioll68 with SMTP id l68so140443988iol.3 for ; Fri, 06 Nov 2015 16:59: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=IFLIYrCf6TsU7ePwsOnYIcHxQXH+uVuwOmnpMPH+6Ss=; b=B/gRbfnvlYjl4aK5riekrD8lTuKDgyxZNuR/2W7YG0NhrBAueEsIkqaqw/W+fbdvNg sveizq7S9J89An9y9hWkbKuNML2F2tGPqfFl8HpcqCPfzJn9JEznnDA/YueF0lTRHgqM 28V1QTrfinhEZ6Cf2webWMOBnAWb3wuk77TKwajwknzEqPfbrhzNwMuyAgfIpazUJ902 /RUi9/ZeNFl7uVfh7Th3oMyCk8D1guOYFvtHvPkw4C3U2yEkPLBQ1wDv404MYAYTntH6 kguyhqDLgbLXPGK8de/Sn1TOtNbOqhOCACaudmSDcxmvQU0tG3jrKp6UN5v09QNgiJOu ZY7w== MIME-Version: 1.0 X-Received: by 10.107.25.11 with SMTP id 11mr13566294ioz.5.1446857949034; Fri, 06 Nov 2015 16:59:09 -0800 (PST) Received: by 10.79.33.21 with HTTP; Fri, 6 Nov 2015 16:59:08 -0800 (PST) In-Reply-To: References: <811734cd29d64adc98c5388870611575@XCH-ALN-004.cisco.com> Date: Fri, 6 Nov 2015 16:59:08 -0800 Message-ID: From: Tony Arcieri To: Watson Ladd Content-Type: multipart/alternative; boundary=001a114097aa17be930523e8deb4 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data limit for GCM under a given key. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2015 00:59:11 -0000 --001a114097aa17be930523e8deb4 Content-Type: text/plain; charset=UTF-8 On Friday, November 6, 2015, Watson Ladd wrote: > On Wed, Nov 4, 2015 at 3:43 PM, Dang, Quynh > wrote: > > I did not talk under indistinguishability framework. My discussion was > about confidentiality protection and authentication. > > What is the definition of "confidentiality protection" being used here? > I too am confused by Quynh's statement. Indistinguishability is the modern bar for confidentiality and authentication. Quynh, are you talking about anything less than IND-CCA2? If you are, that is less than the modern bar I would personally consider acceptable. -- Tony Arcieri --001a114097aa17be930523e8deb4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Friday, November 6, 2015, Watson Ladd <watsonbladd@gmail.com> wrote:
On Wed, Nov 4, 2015 at 3:43 PM, Dang, Quynh <q= uynh.dang@nist.gov> wrote:
> I did not talk=C2=A0 under indistinguishability framework. My discussi= on was about confidentiality protection and authentication.

What is the definition of "confidentiality protection" being used= here?

I too am confused by Quynh's statement= .=C2=A0Indistinguishability is the modern bar for confidentiality and authe= ntication.

Quynh, are you talking about anything l= ess than IND-CCA2? If you are, that is less than the modern bar I would per= sonally consider acceptable.


--
Tony Arcieri<= br>
--001a114097aa17be930523e8deb4-- From nobody Fri Nov 6 17:14: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 728E51AD333 for ; Fri, 6 Nov 2015 17:14:26 -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, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twLCSZB7rA_X for ; Fri, 6 Nov 2015 17:14:25 -0800 (PST) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E603F1ACECD for ; Fri, 6 Nov 2015 17:14:24 -0800 (PST) Received: by ykba4 with SMTP id a4so202504418ykb.3 for ; Fri, 06 Nov 2015 17:14:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=oIN8IeJxDk7egV1cmsBGq30dWHAvtBlfVXtzIxHNBPo=; b=MpYExKdQK7YSFCVNP/0r207JH5bgHdY44jeoBgwjEfn+azOLEqw6Y7XuvQStOnEVRl TCFLarLFiVR2GTydM8mlOJtav9mg9iFtIRfJQ7bJNABQk2bjby7RZoxW7B59JebZXTav Bv9Mh45WcVEp5uFpZC/flfQLqMvCFOQMNWZ9HajkpnhhgczBTsbkZyO6Go389Pa+GSQa 5eY0ap7NSCqiOskz4ycJVLwxhFl2kWxQm5zo0bxMTuG9w6+oBRRXih9xQRnfqjSscti9 QBQsA+XF+ruuE0FDVf/+xtPU2QzceNhvVgSpHpiJ05otZeMJ2yzdIeD/tOKyegO9YW8+ E7DA== 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=oIN8IeJxDk7egV1cmsBGq30dWHAvtBlfVXtzIxHNBPo=; b=a9BmFOMf8R5fC+UoUXqXyaqmqXevE5+JvVFzEBPY90FCvrGAky2sDVyKuHZaHNMh8y +ASs6IjEev+U9svTRdQKVch3ct+NWJIPkbMkE7jfHJixC0S965ZaSubwUWC/7Qd4sPos 2MSHHgES00/Lw2mhgNoqRT0DZuNRLCXfv4ucvKaqOrQ+ik66yrYoCwIvltgq+Ljhk6YU IZvKRGIyszReSFLXWDuv0NAdFS+ow53n3d9fsYgXKbxpnoxGahTjNhe2nCXAUIHxR0Yy I+uXZ6laSp9MQKxMzp5bcgLFr5923Q5Z/EpqQp8tY45w9cnCPU5cpJBl/XbJtZijQHpU dZqQ== X-Gm-Message-State: ALoCoQnc+Fz2OOYrcSBzpmJTX3jhIgdKmJadMuqgCrY2M2wL/qcSPpCKwQaxm3rgmXgx5mbtmDCf X-Received: by 10.13.212.8 with SMTP id w8mr15918353ywd.192.1446858864152; Fri, 06 Nov 2015 17:14:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.221.203 with HTTP; Fri, 6 Nov 2015 17:13:44 -0800 (PST) In-Reply-To: References: <811734cd29d64adc98c5388870611575@XCH-ALN-004.cisco.com> From: Eric Rescorla Date: Fri, 6 Nov 2015 17:13:44 -0800 Message-ID: To: Tony Arcieri Content-Type: multipart/alternative; boundary=001a114fa4a4a384dd0523e91489 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data limit for GCM under a given key. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2015 01:14:26 -0000 --001a114fa4a4a384dd0523e91489 Content-Type: text/plain; charset=UTF-8 Update: we discussed this extensively in Yokohama and based on Watson's feedback and offline comments from David McGrew, the consensus was that we needed to add some sort of rekeying mechanism to support long-lived flows. Expect a PR on this next week. Note: We'll still need guidance to implementations on when to re-key, but we don't expect to have a hard protocol limit. -Ekr On Fri, Nov 6, 2015 at 4:59 PM, Tony Arcieri wrote: > On Friday, November 6, 2015, Watson Ladd wrote: > >> On Wed, Nov 4, 2015 at 3:43 PM, Dang, Quynh wrote: >> > I did not talk under indistinguishability framework. My discussion was >> about confidentiality protection and authentication. >> >> What is the definition of "confidentiality protection" being used here? >> > > I too am confused by Quynh's statement. Indistinguishability is the modern > bar for confidentiality and authentication. > > Quynh, are you talking about anything less than IND-CCA2? If you are, that > is less than the modern bar I would personally consider acceptable. > > > -- > Tony Arcieri > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a114fa4a4a384dd0523e91489 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Update: we discussed this extensively in Yokohama and base= d on Watson's feedback and offline comments from David McGrew, the cons= ensus was that we needed to add some sort of rekeying mechanism to support = long-lived flows. Expect a PR on this next week.

No= te: We'll still need guidance to implementations on when to re-key, but= we don't expect to have a hard protocol limit.

-Ekr



On Fri, Nov 6, 2015 at 4:= 59 PM, Tony Arcieri <bascule@gmail.com> wrote:
On Friday, November 6, 2015, Watson Ladd <watsonbladd@gmail.c= om> wrote:
On Wed, Nov 4, 2015 at = 3:43 PM, Dang, Quynh <quynh.dang@nist.gov> wrote:
> I did not talk=C2=A0 under indistinguishability framework. My discussi= on was about confidentiality protection and authentication.

What is the definition of "confidentiality protection" being used= here?

I too am confused by Quynh's st= atement.=C2=A0Indistinguishability is the modern bar for confidentiality an= d authentication.

Quynh, are you talking about any= thing less than IND-CCA2? If you are, that is less than the modern bar I wo= uld personally consider acceptable.


--
Tony Ar= cieri


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


--001a114fa4a4a384dd0523e91489-- From nobody Fri Nov 6 18:39: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 5E1351A89E9 for ; Fri, 6 Nov 2015 18:39:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vxjOZkzhZwFg for ; Fri, 6 Nov 2015 18:39:14 -0800 (PST) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1969B1A89C7 for ; Fri, 6 Nov 2015 18:39:14 -0800 (PST) Received: by ykek133 with SMTP id k133so204028007yke.2 for ; Fri, 06 Nov 2015 18:39:13 -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=0VuWRg9iuRCchz/t+GCy7KosLb8jR2w9kdJNTKj2q50=; b=w7e0JQRltpzYXIDRaPaPwaFBeifeAuEbcKzU8sldBDd8E/sJ4zFla9dNEv/ASD8eps nw2BsDptuknz1nJLKqwzNxE73pud3OomDzq89pp5EQBGocwnl9xpRYFoPgLhB3pPgYhP diZm113givxKUG9pEhPzUzdroyJLF19spcze5ZnlA9vNOXoctoHKKaBFGMBTgMSUNmPD T6jBJAJ/iJXTndmIdujLMBCL8g5WhpL5cNHyBboAGXwLNFJdj3ZhS7c9D1BOG1QI34ZH 8GVNHUV5EQ/c85x+2NlGkakXTUug1hBrD1lcBbT8w/HywQxga4E2rYFOqOw4Ng9QlWsB 8ACQ== X-Received: by 10.13.226.142 with SMTP id l136mr13775995ywe.313.1446863953308; Fri, 06 Nov 2015 18:39:13 -0800 (PST) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id i12sm519982ywg.40.2015.11.06.18.39.12 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 06 Nov 2015 18:39:12 -0800 (PST) From: Dave Garrett To: tls@ietf.org Date: Fri, 6 Nov 2015 21:39:10 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201511062139.11139.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Data limit for GCM under a given key. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2015 02:39:15 -0000 On Friday, November 06, 2015 08:13:44 pm Eric Rescorla wrote: > Update: we discussed this extensively in Yokohama and based on Watson's > feedback and offline comments from David McGrew, the consensus was that we > needed to add some sort of rekeying mechanism to support long-lived flows. > Expect a PR on this next week. > > Note: We'll still need guidance to implementations on when to re-key, but > we don't expect to have a hard protocol limit. If re-keying is back up for discussion, let me restate my request for it to be routine, rather than only an niche-case feature. Any re-key schedule should be considered valid, but the spec should set a "SHOULD"-level requirement that the minimum be once every N hours or M terabytes, whichever comes first (where N & M are some bike-shedable numbers with some expectation of randomization in values for each period). Dave From nobody Fri Nov 6 19:46: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 92A3C1ACE96 for ; Fri, 6 Nov 2015 19:46: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 zXS65lVAK5_o for ; Fri, 6 Nov 2015 19:46:21 -0800 (PST) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e: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 8DB9B1ACE8E for ; Fri, 6 Nov 2015 19:46:21 -0800 (PST) Received: by pabfh17 with SMTP id fh17so141223580pab.0 for ; Fri, 06 Nov 2015 19:46:21 -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 :content-transfer-encoding:message-id:references:to; bh=WJ30WCQ4c8eznjNRdbOhUmlOISkuyy7ciBDwK1q6hCg=; b=ou01jYLqG4NNOPHyXflbqqP+qc+DIlnqEuljby/kH02buvGKIYzo3RR63rJ9D++GiH sM40daai8JjvIqSatA/AKxhkrxtoT7Vn0OMIZF9ES+4zgKMBgv54rlRCznIw239FaZ9X BpdvKFw77H0MxzSKc1dZi2BdKJ3P2xyQYYbWPg/hkrrQmX9ATHvdkUJjKXVqNy/9dtJN 6ymEQw+uVj4o6jw3dCsQrFt4t635FU4QebxDg8pmC3Hv8z+OCRoPdrzy0a/Mj6cSKyIc yivoPPw5PX7GuTtycvnZ16h7DvfvUUlbt6jp19lZ51LwPIAG+U5XFnjxgC+xXdZMx7Aa EVLw== X-Received: by 10.68.165.34 with SMTP id yv2mr22306597pbb.153.1446867981161; Fri, 06 Nov 2015 19:46:21 -0800 (PST) Received: from [10.216.98.81] ([210.160.37.24]) by smtp.gmail.com with ESMTPSA id d2sm2720781pat.24.2015.11.06.19.46.19 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 06 Nov 2015 19:46:20 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Yoav Nir In-Reply-To: <201511062139.11139.davemgarrett@gmail.com> Date: Sat, 7 Nov 2015 12:46:18 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <5FA3B020-DDCC-4745-B969-9A54A98C9948@gmail.com> References: <201511062139.11139.davemgarrett@gmail.com> To: Dave Garrett X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Data limit for GCM under a given key. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2015 03:46:26 -0000 > On 7 Nov 2015, at 11:39 AM, Dave Garrett = wrote: >=20 > On Friday, November 06, 2015 08:13:44 pm Eric Rescorla wrote: >> Update: we discussed this extensively in Yokohama and based on = Watson's >> feedback and offline comments from David McGrew, the consensus was = that we >> needed to add some sort of rekeying mechanism to support long-lived = flows. >> Expect a PR on this next week. >>=20 >> Note: We'll still need guidance to implementations on when to re-key, = but >> we don't expect to have a hard protocol limit. >=20 > If re-keying is back up for discussion, let me restate my request for = it to be routine, rather than only an niche-case feature. Any re-key = schedule should be considered valid, but the spec should set a = "SHOULD"-level requirement that the minimum be once every N hours or M = terabytes, whichever comes first (where N & M are some bike-shedable = numbers with some expectation of randomization in values for each = period). N and M will be different depending on the algorithms, no? I think before we start with pull requests we should be certain of what = the requirements are for this rekeying. Are we OK with just generating new keys from the same internal state (so = the handshake message is pretty much only =E2=80=9Crekey now=E2=80=9D), = or Do we want freshness (usually in the form of new mutual nonces, or Do we want forward secrecy so another diffie-hellamn exchange? Yoav= From nobody Fri Nov 6 19:50: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 E5C931ACEBD for ; Fri, 6 Nov 2015 19:50:44 -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, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WCdUAc8CJenz for ; Fri, 6 Nov 2015 19:50:43 -0800 (PST) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::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 3F3251ACEBC for ; Fri, 6 Nov 2015 19:50:43 -0800 (PST) Received: by ykba4 with SMTP id a4so204566092ykb.3 for ; Fri, 06 Nov 2015 19:50:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Fls49T0o722D8thH2UFea+8+50LwnR1WBEe+nBW7erI=; b=E8jX9PRnM7/RgxsjXSS7ea9mK81ftPSB1gPgyO1lJQl01d0Lz82FVd3JeENGID2N1j NGd3hYa01SjL7qr5kKzCvZM0hoaNynNcl0T02c4BuXqrdzUE9OkfU57NzEzBqHwotOLG 4vJcRZ3D9IInh7hDcSB/SuLTlHiq289W2sGf7Y7XOTZhz9UpRzlReI9/MauWGeZo5UeZ 4svxDhAMZcmGsnhwWF4oqrtUIESWM2XHUEs1Zf5G4eB/oljEwJigxZbJeOrN9CKZgsWU 1ey9auTmPPIzzwNdoHuKE7gUrSTyxDA0x76wKOxuMnydJQbnoJaUYz+Md5R1kNL+GKkB ANBA== 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=Fls49T0o722D8thH2UFea+8+50LwnR1WBEe+nBW7erI=; b=MnLYFphfeMKLvvfhDlXonI0JZVl2L5JD1NTWDEHxLDRhXTJjSQID1cmfiuOTKG3sTR qN+OV7DvFbVh14eOOoQjLLivT1nMSj2mcon1sERsPn5MhWDywi5JiNYngZHzyM4manHC ZXCPSfXyAVbVD2PcrrJwrXDhUi5ILZI1gANFkVf5aDxb+L5PloSXw0bRyTo4d1OgPJAc Z1+WHgzweBVdrsBmvyyKq7gub4Ci40KdI844fITl9G8hCK0TOZ8ut71bSLqpDMxwbJQD eplKJ7lUAga5BKJt8hBa5okvBCle89XKFCaxbgUADMGAuEGg/cg4KN+31jR6XKTdpCFL W8OQ== X-Gm-Message-State: ALoCoQn3N24c891CFFPeKss2ym38lLTH0bhX4kddaC7ipJAOa9vWFDENZecKKVsNyJRAjhfj5fqp X-Received: by 10.129.93.193 with SMTP id r184mr13801875ywb.115.1446868242489; Fri, 06 Nov 2015 19:50:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.221.203 with HTTP; Fri, 6 Nov 2015 19:50:03 -0800 (PST) In-Reply-To: <5FA3B020-DDCC-4745-B969-9A54A98C9948@gmail.com> References: <201511062139.11139.davemgarrett@gmail.com> <5FA3B020-DDCC-4745-B969-9A54A98C9948@gmail.com> From: Eric Rescorla Date: Fri, 6 Nov 2015 19:50:03 -0800 Message-ID: To: Yoav Nir Content-Type: multipart/alternative; boundary=001a114d71d8a194290523eb4351 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data limit for GCM under a given key. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2015 03:50:45 -0000 --001a114d71d8a194290523eb4351 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Nov 6, 2015 at 7:46 PM, Yoav Nir wrote: > > > On 7 Nov 2015, at 11:39 AM, Dave Garrett wrote= : > > > > On Friday, November 06, 2015 08:13:44 pm Eric Rescorla wrote: > >> Update: we discussed this extensively in Yokohama and based on Watson'= s > >> feedback and offline comments from David McGrew, the consensus was tha= t > we > >> needed to add some sort of rekeying mechanism to support long-lived > flows. > >> Expect a PR on this next week. > >> > >> Note: We'll still need guidance to implementations on when to re-key, > but > >> we don't expect to have a hard protocol limit. > > > > If re-keying is back up for discussion, let me restate my request for i= t > to be routine, rather than only an niche-case feature. Any re-key schedul= e > should be considered valid, but the spec should set a "SHOULD"-level > requirement that the minimum be once every N hours or M terabytes, > whichever comes first (where N & M are some bike-shedable numbers with so= me > expectation of randomization in values for each period). > > N and M will be different depending on the algorithms, no? > > I think before we start with pull requests we should be certain of what > the requirements are for this rekeying. > These were discussed extensively both in the interim and at IETF. The purpose of rekeying in this context is to deal with cryptographic exhaustion, namely having more ciphertext under the same key than is safe for a given algorithm (where safe is defined by an analysis like the one Watson has posted upthread). > Are we OK with just generating new keys from the same internal state (so > the handshake message is pretty much only =E2=80=9Crekey now=E2=80=9D), I believe this is what we agreed both in Seattle and in Prague. -Ekr > or > Do we want freshness (usually in the form of new mutual nonces, or > Do we want forward secrecy so another diffie-hellamn exchange? > > Yoav > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a114d71d8a194290523eb4351 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Nov 6, 2015 at 7:46 PM, Yoav Nir <ynir.ietf@gmail.com&g= t; wrote:

> On 7 Nov 2015, at 11:39 AM, Dave Garrett <davemgarrett@gmail.com> wrote:
>
> On Friday, November 06, 2015 08:13:44 pm Eric Rescorla wrote:
>> Update: we discussed this extensively in Yokohama and based on Wat= son's
>> feedback and offline comments from David McGrew, the consensus was= that we
>> needed to add some sort of rekeying mechanism to support long-live= d flows.
>> Expect a PR on this next week.
>>
>> Note: We'll still need guidance to implementations on when to = re-key, but
>> we don't expect to have a hard protocol limit.
>
> If re-keying is back up for discussion, let me restate my request for = it to be routine, rather than only an niche-case feature. Any re-key schedu= le should be considered valid, but the spec should set a "SHOULD"= -level requirement that the minimum be once every N hours or M terabytes, w= hichever comes first (where N & M are some bike-shedable numbers with s= ome expectation of randomization in values for each period).

N and M will be different depending on the algorithms, no?

I think before we start with pull requests we should be certain of what the= requirements are for this rekeying.

Th= ese were discussed extensively both in the interim and at IETF. The purpose= of rekeying in this context is to deal with cryptographic exhaustion, name= ly having more ciphertext under the same key than is safe for a
g= iven algorithm (where safe is defined by an analysis like the one Watson
has posted upthread).

=C2=A0
Are we OK with just generating new keys from the same internal state (so th= e handshake message is pretty much only =E2=80=9Crekey now=E2=80=9D),

I believe this is what we agreed both in Seattl= e and in Prague.

-Ekr

=C2= =A0
or
Do we want freshness (usually in the form of new mutual nonces, or
Do we want forward secrecy so another diffie-hellamn exchange?

Yoav
_____________________= __________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--001a114d71d8a194290523eb4351-- From nobody Fri Nov 6 19:54: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 A63691ACEE5 for ; Fri, 6 Nov 2015 19:54:44 -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, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0NrRCsboZVpP for ; Fri, 6 Nov 2015 19:54:43 -0800 (PST) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ED971ACEE6 for ; Fri, 6 Nov 2015 19:54:42 -0800 (PST) Received: by ykba4 with SMTP id a4so204613264ykb.3 for ; Fri, 06 Nov 2015 19:54:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=msJvbzqXhdtLRJf9GnOI9aTxE5por2PiJPYb8ZbaYb0=; b=Hw/JFqXQnZl3ZauX6iOxsO0VG4FrXQELQIpKImPH3ozwF3sA3KcBgn10fKcjwRyWaZ rzw5qvqTNAsX2fHzRKjk6+ydatoNADnVZMHlgfh8E/iEKh2cQurhXEiHh5ellDEizm5/ RWWjks4Hm4M0zNgUVyuzElW0DWZLpKtawvAttiURSk5HM9vHB/WtWy140sNEBw4eAP8B TZbo//RRr1sy0zorrS4XC35cUBN+gWWeyylYd34AzSGqD1Cs61j49mhW0mzjecYdJBeZ yE9KWvFa2PheJ4XRhJ9pWsnVjCK38WshfvVs5o5GblQidJ9LCyG/LJ3LN2VIAFHzZDfT uaPg== 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=msJvbzqXhdtLRJf9GnOI9aTxE5por2PiJPYb8ZbaYb0=; b=KxDq0H6xQh1kpp2fWidga6iqcukYsHz1tTCVTwzZuFKxA8H4b/4Wk8i3FScZpSTtG8 TYIaohq3z/HKlLE8N4KvV2FAeyXcExz2og53JbEFNGVtiaCRbMlcz+K4gqa0Xi7MYOqX bBuIr0PVgTC8INT0IC6c5rvO5nc/jIHwr94kW09ocLDbHYUUObk0Vvgi22ygRAJGeKr7 EgmQYsAsgmSkOlnq30v9H46f2BLqykG8I9PKkrwhL0fwq/g9xCxGtc6m9HKBzhfjHtQa bauLKxRj6f/UZ6I2p2WdMhgWpBT1oP9A5GZNO+iyy8nXd8wj6oSP5xeOw9SoBofKFRQf NMBQ== X-Gm-Message-State: ALoCoQk4TmtkRE1E5EWUnXC4TZYAkg21WhFTj498QlK16ImWik/CezMrQbZBYYywxsIs72mv8COi X-Received: by 10.13.236.10 with SMTP id v10mr16181051ywe.231.1446868481627; Fri, 06 Nov 2015 19:54:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.221.203 with HTTP; Fri, 6 Nov 2015 19:54:02 -0800 (PST) In-Reply-To: <201511062139.11139.davemgarrett@gmail.com> References: <201511062139.11139.davemgarrett@gmail.com> From: Eric Rescorla Date: Fri, 6 Nov 2015 19:54:02 -0800 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=94eb2c0889dce287b70523eb51af Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data limit for GCM under a given key. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2015 03:54:44 -0000 --94eb2c0889dce287b70523eb51af Content-Type: text/plain; charset=UTF-8 On Fri, Nov 6, 2015 at 6:39 PM, Dave Garrett wrote: > On Friday, November 06, 2015 08:13:44 pm Eric Rescorla wrote: > > Update: we discussed this extensively in Yokohama and based on Watson's > > feedback and offline comments from David McGrew, the consensus was that > we > > needed to add some sort of rekeying mechanism to support long-lived > flows. > > Expect a PR on this next week. > > > > Note: We'll still need guidance to implementations on when to re-key, but > > we don't expect to have a hard protocol limit. > > If re-keying is back up for discussion, let me restate my request for it > to be routine, rather than only an niche-case feature. Any re-key schedule > should be considered valid, but the spec should set a "SHOULD"-level > requirement that the minimum be once every N hours or M terabytes, > whichever comes first (where N & M are some bike-shedable numbers with some > expectation of randomization in values for each period). As I said above, I agree that the specification should provide some guidance on how often you should re-key for a given cipher based on the number of records/cipher blocks (whatever is more convenient for analysis). This guidance should be derived from the kind of analysis Watson and Dave McGrew have done for these algorithms, and, as Watson's analysis suggests, is likely to be algorithm specific. I don't believe time-based guidance is useful here, given that it's highly situation specific rather than derived from reasoning about the properties of the cipher. -Ekr --94eb2c0889dce287b70523eb51af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Nov 6, 2015 at 6:39 PM, Dave Garrett <davemgarrett@gmail.= com> wrote:
On Friday= , November 06, 2015 08:13:44 pm Eric Rescorla wrote:
> Update: we discussed this extensively in Yokohama and based on Watson&= #39;s
> feedback and offline comments from David McGrew, the consensus was tha= t we
> needed to add some sort of rekeying mechanism to support long-lived fl= ows.
> Expect a PR on this next week.
>
> Note: We'll still need guidance to implementations on when to re-k= ey, but
> we don't expect to have a hard protocol limit.

If re-keying is back up for discussion, let me restate my request fo= r it to be routine, rather than only an niche-case feature. Any re-key sche= dule should be considered valid, but the spec should set a "SHOULD&quo= t;-level requirement that the minimum be once every N hours or M terabytes,= whichever comes first (where N & M are some bike-shedable numbers with= some expectation of randomization in values for each period).
=

As I said above, I agree that the specification should = provide some guidance on how often you should re-key for a given cipher bas= ed on the number of records/cipher blocks (whatever is more convenient for = analysis). This guidance should be derived from the kind of analysis Watson= and Dave McGrew have done for these algorithms, and, as Watson's analy= sis suggests, is likely to be algorithm specific.

= I don't believe time-based guidance is useful here, given that it's= highly situation specific rather than derived from reasoning about the pro= perties of the cipher.

-Ekr

=



--94eb2c0889dce287b70523eb51af-- From nobody Fri Nov 6 20:00: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 89F191ACF1C for ; Fri, 6 Nov 2015 20:00:30 -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, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nk5WkYJ4mTjY for ; Fri, 6 Nov 2015 20:00:29 -0800 (PST) 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 006F51ACF1A for ; Fri, 6 Nov 2015 20:00:28 -0800 (PST) Received: by ykdr3 with SMTP id r3so204772093ykd.1 for ; Fri, 06 Nov 2015 20:00:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=NeCd/uMIkSVqqfqMvvVIZupm+PMioV+H1NZEe7cAOCU=; b=nSogEArOyTVmWI1rJCtpMZ2660elrBJKRojbudWK5mDgTRFGihmtw+ChiCEFCCPuSh jPKO/vUra5p3/KZk2Dgip0uDterrXvkwES2v8Q8mGcCqOSKWJStrm7aJayA1OK4LiW+s AGjwG///vfHnpHxxAy7AAyAUnMvUsR/7PxvEq+2BAlH86QBHM9xT43zh80sN909EIzbt 3uUW+kATSf2L0Ys+i7+dFsKL5BM6ZykXC8IB63KHCxuxqo2ihI/cNpFO3/vc9UFMsq2T JBlrY6cA4lhpORy8EFRIIEd4qm2xho/eMbzQKh+Gkv0FaT80Wb1JsrJ1rdIK5WWGcyyI G7wA== 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=NeCd/uMIkSVqqfqMvvVIZupm+PMioV+H1NZEe7cAOCU=; b=WVO3d8DiUIlKFLvoNZELhQfZYdMG3V+TTSFs8XIdp1fuEdkpf3Jju9ah/SNixQsXXx fnuhhco7NW8dQWnVqKzJU+bsFSUh5RJnD7ukpwIu4tLyvLqpI5/LDA47CAtUle9JMVAp wRnou0+A4zK2wNWlg78LEHjLxoLdQGpSgL+0FXCtUdsjR9AXATZc68wv5AG+Fvpc/rBp NNzue2vTf0dkpAyshHjqwtWr6BYw1pdLevyyHNE2JyOmto94sq/4rSvhvO3g7YJUIASZ U8T1LxiCs0GigL5raQHkpyWe6l8q5ZBdR7hWsN76xRyGNiMtoRwlUvGRXIDJ0Zn6V79f pzJg== X-Gm-Message-State: ALoCoQkcPnWi1oKn78IdSMet51WxKzQ9irNZzPRzqof8JT6lMP6Npv4bAItJaujxOmmCM8e85SIt X-Received: by 10.13.224.2 with SMTP id j2mr15748680ywe.165.1446868827850; Fri, 06 Nov 2015 20:00:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.221.203 with HTTP; Fri, 6 Nov 2015 19:59:48 -0800 (PST) In-Reply-To: References: <201511062139.11139.davemgarrett@gmail.com> <5FA3B020-DDCC-4745-B969-9A54A98C9948@gmail.com> From: Eric Rescorla Date: Fri, 6 Nov 2015 19:59:48 -0800 Message-ID: To: Yoav Nir Content-Type: multipart/alternative; boundary=94eb2c074626857eed0523eb6669 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data limit for GCM under a given key. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2015 04:00:30 -0000 --94eb2c074626857eed0523eb6669 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Nov 6, 2015 at 7:50 PM, Eric Rescorla wrote: > > > On Fri, Nov 6, 2015 at 7:46 PM, Yoav Nir wrote: > >> >> > On 7 Nov 2015, at 11:39 AM, Dave Garrett >> wrote: >> > >> > On Friday, November 06, 2015 08:13:44 pm Eric Rescorla wrote: >> >> Update: we discussed this extensively in Yokohama and based on Watson= 's >> >> feedback and offline comments from David McGrew, the consensus was >> that we >> >> needed to add some sort of rekeying mechanism to support long-lived >> flows. >> >> Expect a PR on this next week. >> >> >> >> Note: We'll still need guidance to implementations on when to re-key, >> but >> >> we don't expect to have a hard protocol limit. >> > >> > If re-keying is back up for discussion, let me restate my request for >> it to be routine, rather than only an niche-case feature. Any re-key >> schedule should be considered valid, but the spec should set a >> "SHOULD"-level requirement that the minimum be once every N hours or M >> terabytes, whichever comes first (where N & M are some bike-shedable >> numbers with some expectation of randomization in values for each period= ). >> >> N and M will be different depending on the algorithms, no? >> >> I think before we start with pull requests we should be certain of what >> the requirements are for this rekeying. >> > > These were discussed extensively both in the interim and at IETF. The > purpose of rekeying in this context is to deal with cryptographic > exhaustion, namely having more ciphertext under the same key than is safe > for a > given algorithm (where safe is defined by an analysis like the one Watson > has posted upthread). > To be clear, I'm not saying that there aren't other reasons for rekeying, just that the problem agreed to address is the one above. -Ekr > Are we OK with just generating new keys from the same internal state (so >> the handshake message is pretty much only =E2=80=9Crekey now=E2=80=9D), > > > I believe this is what we agreed both in Seattle and in Prague. > > -Ekr > > > >> or >> Do we want freshness (usually in the form of new mutual nonces, or >> Do we want forward secrecy so another diffie-hellamn exchange? >> >> Yoav >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > --94eb2c074626857eed0523eb6669 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Nov 6, 2015 at 7:50 PM, Eric Rescorla <ekr@rtfm.com> = wrote:


On Fri, Nov 6, 2015 at 7= :46 PM, Yoav Nir <ynir.ietf@gmail.com> wrote:

> On 7 Nov 2015, at 11:39 AM, Dave Garrett <davemgarrett@gmail.com> wrote: >
> On Friday, November 06, 2015 08:13:44 pm Eric Rescorla wrote:
>> Update: we discussed this extensively in Yokohama and based on Wat= son's
>> feedback and offline comments from David McGrew, the consensus was= that we
>> needed to add some sort of rekeying mechanism to support long-live= d flows.
>> Expect a PR on this next week.
>>
>> Note: We'll still need guidance to implementations on when to = re-key, but
>> we don't expect to have a hard protocol limit.
>
> If re-keying is back up for discussion, let me restate my request for = it to be routine, rather than only an niche-case feature. Any re-key schedu= le should be considered valid, but the spec should set a "SHOULD"= -level requirement that the minimum be once every N hours or M terabytes, w= hichever comes first (where N & M are some bike-shedable numbers with s= ome expectation of randomization in values for each period).

N and M will be different depending on the algorithms, no?

I think before we start with pull requests we should be certain of what the= requirements are for this rekeying.

=
These were discussed extensively both in the interim and at IETF. The = purpose of rekeying in this context is to deal with cryptographic exhaustio= n, namely having more ciphertext under the same key than is safe for a
given algorithm (where safe is defined by an analysis like the one Wa= tson
has posted upthread).

To be clear, I'm not saying that there aren't oth= er reasons for rekeying,
just that the problem agreed to address = is the one above.

-Ekr
=C2=A0
Are we OK with just generating new keys from the same internal state (so th= e handshake message is pretty much only =E2=80=9Crekey now=E2=80=9D),

I believe this is what we agreed both in= Seattle and in Prague.

-Ekr

<= /div>
=C2=A0
or
Do we want freshness (usually in the form of new mutual nonces, or
Do we want forward secrecy so another diffie-hellamn exchange?

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


--94eb2c074626857eed0523eb6669-- From nobody Fri Nov 6 20:21:50 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 474261AD481 for ; Fri, 6 Nov 2015 20:21:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVsBBM-oFImG for ; Fri, 6 Nov 2015 20:21:47 -0800 (PST) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::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 ED95D1AD37C for ; Fri, 6 Nov 2015 20:21:46 -0800 (PST) Received: by ykdr3 with SMTP id r3so205035332ykd.1 for ; Fri, 06 Nov 2015 20:21:46 -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=8DS39TQg0KxQCI42+NgENy8n09tOvaIVdQuqqF7gHlY=; b=Y3DwPpJglcVLhsEIWjH+1NnEVq0zMoIloUA+jBHuplP5r8uweQBxYJdg3vQh2jiWSB oYs/W7Pph0cv4KhhCR24MuoOfFqG+Whkp6EnJDxajmJ9UH/1YUKLg7Eaxj7Fd+ixdtkK VTH6FnJQ2KWvU4UklU+DOWetp7kvzC8q8V8TVhQJ8/XhTd+b/aKYHZkPKQX6Qbz+5ZTm a8qYrDL7MxM0Z6Sg9jg5KLi/2QPnUv+WqxIQoo2iE0o2+62mwWcXlWzr86rjwOB3H8Z+ OiTYhQkYj+ejltUCnbKsIfJ7T+0XGr6h5uEmIK/XouLnIHTdiZ88uzqTNa6NZM6Z/PIa fUlg== X-Received: by 10.129.56.4 with SMTP id f4mr13628123ywa.201.1446870106301; Fri, 06 Nov 2015 20:21:46 -0800 (PST) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id p8sm2676075ywc.38.2015.11.06.20.21.45 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 06 Nov 2015 20:21:45 -0800 (PST) From: Dave Garrett To: Eric Rescorla Date: Fri, 6 Nov 2015 23:21:44 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201511062139.11139.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201511062321.44511.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data limit for GCM under a given key. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2015 04:21:48 -0000 On Friday, November 06, 2015 10:54:02 pm Eric Rescorla wrote: > I don't believe time-based guidance is useful here, given that it's highly > situation specific rather than derived from reasoning about the properties > of the cipher. One reason to have a regular interval between rekeys is to ensure that it's a standard operation, rather than something implementations in many use-cases never see and possibly muck up when they eventually do. The time does not need to be short, though, and can vary by algorithm and implementation discretion. Dave From nobody Fri Nov 6 21:08: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 C692E1B29DD for ; Fri, 6 Nov 2015 21:08:07 -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, 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 H5qnjgzl0Wsg for ; Fri, 6 Nov 2015 21:08:04 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0796.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::796]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C11E1A9121 for ; Fri, 6 Nov 2015 21:08:04 -0800 (PST) Received: from BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) by BN1PR09MB122.namprd09.prod.outlook.com (10.255.200.156) with Microsoft SMTP Server (TLS) id 15.1.312.18; Sat, 7 Nov 2015 05:07:44 +0000 Received: from BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) by BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) with mapi id 15.01.0312.014; Sat, 7 Nov 2015 05:07:44 +0000 From: "Dang, Quynh" To: Tony Arcieri Thread-Topic: [TLS] Data limit for GCM under a given key. Thread-Index: AQHRFzcvtEucviFc9UutVqNJaXFvZp6MTRcAgAAF1TmAA2TsAIAACLwAgAA8it8= Date: Sat, 7 Nov 2015 05:07:43 +0000 Message-ID: References: <811734cd29d64adc98c5388870611575@XCH-ALN-004.cisco.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-originating-ip: [129.6.218.206] x-microsoft-exchange-diagnostics: 1; BN1PR09MB122; 5:hJyxsFfgKe2W0zc53HTAsubZB5I8mbKY0W556iNB7JWjOBICCD9T9M/OjsI69PK88YPrwlgcy2AhTXIlMFh6JW0BZAgm9LSzgSzJ0auHroahh/7RXSuquOtBoG6ElStk2KdfW78HD4qEl0gdUyZlug==; 24:g1oflsy6oLvUWoUYGsA3ZZTaA6WjE4hjbkNVlruf5fBoznSEoMtFKoOLQtAgZfKxDHGaa37kLde467mPCZs0svwKJCRYO0KwMMsPTcGDAYk=; 20:Hh5vzvC9tD/KEN2cJdOTeC/+I04PmJUfA3L42TEmkMACb7ciVA3zzD/NYIB3hfwucFIqcDQqkneDfTtvRS5GHQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB122; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001); SRVR:BN1PR09MB122; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB122; x-forefront-prvs: 0753EA505A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(189002)(24454002)(377454003)(11100500001)(19625215002)(101416001)(5007970100001)(5004730100002)(10400500002)(106116001)(105586002)(99286002)(106356001)(189998001)(110136002)(87936001)(16236675004)(5001960100002)(33656002)(76576001)(74316001)(5002640100001)(19627405001)(40100003)(122556002)(5003600100002)(102836002)(81156007)(97736004)(66066001)(5008740100001)(2900100001)(92566002)(5001920100001)(1411001)(2950100001)(93886004)(77096005)(50986999)(86362001)(19580395003)(19580405001)(76176999)(54356999)(18265965002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB122; H:BN1PR09MB124.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN1PR09MB124D3BB5E8C4CDC74FA8302F3170BN1PR09MB124namprd_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2015 05:07:43.6676 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB122 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data limit for GCM under a given key. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2015 05:08:08 -0000 --_000_BN1PR09MB124D3BB5E8C4CDC74FA8302F3170BN1PR09MB124namprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Tony, You are correct. An Indistinguishability bound promises you no attacks will= be below the bound assuming the claimed property(ies) of the underline fun= ction in the construction (mode) hold(s). A distinguishing attack below the bound tells you that the construction or = the underlined function is not strong or ideal as you would like, but it do= es not directly (100%) lead to a break of plaintext confidentiality or auth= enticity. Here, confidentiality protection of plaintext(s) is that an atta= cker who does not know the key can not find out any part of the plaintext(s= ) by decryption. And, I explained the point in the previous emails. Under indistinguishability framework, one should not even go to 2^32 blocks= with GCM when the IV space is 2^64 because there is a high probability of = ciphertext collision with 2^32 ciphertexts. Quynh. ________________________________ From: Tony Arcieri Sent: Friday, November 6, 2015 7:59 PM To: Watson Ladd Cc: Dang, Quynh; tls@ietf.org Subject: Re: [TLS] Data limit for GCM under a given key. On Friday, November 6, 2015, Watson Ladd > wrote: On Wed, Nov 4, 2015 at 3:43 PM, Dang, Quynh wrote: > I did not talk under indistinguishability framework. My discussion was a= bout confidentiality protection and authentication. What is the definition of "confidentiality protection" being used here? I too am confused by Quynh's statement. Indistinguishability is the modern = bar for confidentiality and authentication. Quynh, are you talking about anything less than IND-CCA2? If you are, that = is less than the modern bar I would personally consider acceptable. -- Tony Arcieri --_000_BN1PR09MB124D3BB5E8C4CDC74FA8302F3170BN1PR09MB124namprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Tony,


You are correct. An Indistinguishability bound promises you no atta= cks will be below the bound assuming the claimed property(ies) of the under= line function in the construction (mode) hold(s). 


A distinguishing attack below the bound tells you that the construction = or the underlined function is not strong or ideal as you would like, but it= does not directly (100%) lead to a break of plaintext confidentiality or a= uthenticity.  Here, confidentiality protection of plaintext(s) is that an attacker who does not know the key c= an not find out any part of the plaintext(s) by decryption. And, I exp= lained the point in the previous emails. 


Under indistinguishability framework, one should not even go to 2^32 blo= cks with GCM when the IV space is 2^64 because there is a high probability = of ciphertext collision with 2^32 ciphertexts.


Quynh. 





From: Tony Arcieri <basc= ule@gmail.com>
Sent: Friday, November 6, 2015 7:59 PM
To: Watson Ladd
Cc: Dang, Quynh; tls@ietf.org
Subject: Re: [TLS] Data limit for GCM under a given key.
 
On Friday, November 6, 2015, Watson Ladd <watsonbladd@gmail.com> wrote:
On Wed, Nov 4, 2015 at 3:43 PM, Dang, Quynh <quynh.dang@nis= t.gov> wrote:
> I did not talk  under indistinguishability framework. My discussi= on was about confidentiality protection and authentication.

What is the definition of "confidentiality protection" being used= here?

I too am confused by Quynh's statement. Indistinguishability is t= he modern bar for confidentiality and authentication.

Quynh, are you talking about anything less than IND-CCA2? If you are, = that is less than the modern bar I would personally consider acceptable.


--
Tony Arcieri

--_000_BN1PR09MB124D3BB5E8C4CDC74FA8302F3170BN1PR09MB124namprd_-- From nobody Fri Nov 6 23:16: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 366DB1B2BAA for ; Fri, 6 Nov 2015 23:16:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWkJ8BlZ6HhD for ; Fri, 6 Nov 2015 23:16:29 -0800 (PST) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003: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 591291B2BA9 for ; Fri, 6 Nov 2015 23:16:29 -0800 (PST) Received: by obctp1 with SMTP id tp1so108853897obc.2 for ; Fri, 06 Nov 2015 23:16:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=i7oJqV/GQKC+2Pl5nSWFQmFW/a1lJKZjGaZPDSsB3Hk=; b=uRwDb1Q/V44slOicV3XgFgEgKLh8ZNx367rLFfOL+R2oF1lM/pDRyGUR4NSt1+GXRU xaUAH+W8nVRrFnyJtysLnZSchghMxvl7L3HDw+FDv8xaAkKCTKoqdmEnDY0YKBEfddyT wbvKplcEJuJC+B5WQYN96WWvbX7+d4isLKlqRhh6MB7wPM0kY955PE7XOH7ev36eBsqB FIEU1h13skFGF/pkj6x4CIkBnatASrNGXyWnkfPSGVotYUWrhK+V7nDXvezFpHVptB8p q5HUPnGkP97QfQuXrHjdPBmR1mJK4ctjn9r9B1doL8CVIDZAJ5VqR1i04CzftaMHzrcf TPXA== X-Received: by 10.60.143.74 with SMTP id sc10mr10435625oeb.79.1446880588773; Fri, 06 Nov 2015 23:16:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.48.193 with HTTP; Fri, 6 Nov 2015 23:16:09 -0800 (PST) In-Reply-To: References: <201511062139.11139.davemgarrett@gmail.com> <5FA3B020-DDCC-4745-B969-9A54A98C9948@gmail.com> From: Quynh Dang Date: Sat, 7 Nov 2015 16:16:09 +0900 Message-ID: To: Eric Rescorla , Watson Ladd Content-Type: multipart/alternative; boundary=047d7b33c67c86c0830523ee2361 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data limit for GCM under a given key. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2015 07:16:31 -0000 --047d7b33c67c86c0830523ee2361 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Eric and Watson, On Sat, Nov 7, 2015 at 12:50 PM, Eric Rescorla wrote: > > > On Fri, Nov 6, 2015 at 7:46 PM, Yoav Nir wrote: > >> >> > On 7 Nov 2015, at 11:39 AM, Dave Garrett >> wrote: >> > >> > On Friday, November 06, 2015 08:13:44 pm Eric Rescorla wrote: >> >> Update: we discussed this extensively in Yokohama and based on Watson= 's >> >> feedback and offline comments from David McGrew, the consensus was >> that we >> >> needed to add some sort of rekeying mechanism to support long-lived >> flows. >> >> Expect a PR on this next week. >> >> >> >> Note: We'll still need guidance to implementations on when to re-key, >> but >> >> we don't expect to have a hard protocol limit. >> > >> > If re-keying is back up for discussion, let me restate my request for >> it to be routine, rather than only an niche-case feature. Any re-key >> schedule should be considered valid, but the spec should set a >> "SHOULD"-level requirement that the minimum be once every N hours or M >> terabytes, whichever comes first (where N & M are some bike-shedable >> numbers with some expectation of randomization in values for each period= ). >> >> N and M will be different depending on the algorithms, no? >> >> I think before we start with pull requests we should be certain of what >> the requirements are for this rekeying. >> > > These were discussed extensively both in the interim and at IETF. The > purpose of rekeying in this context is to deal with cryptographic > exhaustion, namely having more ciphertext under the same key than is safe > for a > given algorithm (where safe is defined by an analysis like the one Watson > has posted upthread). > You basically said here was that what I described was not safe. Show me how to break the following: I encrypt 2^64 plaintext blocks with 2^64 different IVs with AES (with the same key), then give you the 2^64 ciphertext blocks. Show me an attack that you can recover any of the plaintext blocks. All of the plaintext blocks can be the same block, they can be all different or some of them are repeated block(s) of other block(s). > > > >> Are we OK with just generating new keys from the same internal state (so >> the handshake message is pretty much only =E2=80=9Crekey now=E2=80=9D), > > > I believe this is what we agreed both in Seattle and in Prague. > > -Ekr > > > >> or >> Do we want freshness (usually in the form of new mutual nonces, or >> Do we want forward secrecy so another diffie-hellamn exchange? >> >> Yoav >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls I support rekeying often to avoid disaster to keep going on just in case there is something wrong with the key or IV as I stated before. Quynh. --047d7b33c67c86c0830523ee2361 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Eric and Watson,

On Sat, Nov 7, 2015 at = 12:50 PM, Eric Rescorla <ekr@rtfm.com> wrote:


On Fri, Nov 6, 2015 at 7:46 PM, Yoav Ni= r <ynir.ietf@gmail.com> wrote:

> On 7 Nov 2015, at 11:39 AM, Dave Garrett <davemgarrett@gmail.com> wrote: >
> On Friday, November 06, 2015 08:13:44 pm Eric Rescorla wrote:
>> Update: we discussed this extensively in Yokohama and based on Wat= son's
>> feedback and offline comments from David McGrew, the consensus was= that we
>> needed to add some sort of rekeying mechanism to support long-live= d flows.
>> Expect a PR on this next week.
>>
>> Note: We'll still need guidance to implementations on when to = re-key, but
>> we don't expect to have a hard protocol limit.
>
> If re-keying is back up for discussion, let me restate my request for = it to be routine, rather than only an niche-case feature. Any re-key schedu= le should be considered valid, but the spec should set a "SHOULD"= -level requirement that the minimum be once every N hours or M terabytes, w= hichever comes first (where N & M are some bike-shedable numbers with s= ome expectation of randomization in values for each period).

N and M will be different depending on the algorithms, no?

I think before we start with pull requests we should be certain of what the= requirements are for this rekeying.

=
These were discussed extensively both in the interim and at IETF. The = purpose of rekeying in this context is to deal with cryptographic exhaustio= n, namely having more ciphertext under the same key than is safe for a
given algorithm (where safe is defined by an analysis like the one Wa= tson
has posted upthread).

You basically said here was that what I described was not= safe. Show me how to break the following:

I encry= pt 2^64 plaintext blocks with 2^64 different IVs with AES (with the same ke= y), then give you the 2^64 ciphertext blocks. Show me an attack that you ca= n recover any of the plaintext blocks. All of the plaintext blocks can be t= he same block, they can be all different or some of them are repeated block= (s) of other block(s).=C2=A0
=C2=A0

=C2=A0
Are we OK with just generating new keys from the same internal state (so th= e handshake message is pretty much only =E2=80=9Crekey now=E2=80=9D),

I believe this is what we agreed both in= Seattle and in Prague.

-Ekr

=C2=A0
or
Do we want freshness (usually in the form of new mutual nonces, or
Do we want forward secrecy so another diffie-hellamn exchange?

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


_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
<= div>
I support rekeying often to avoid disaster to keep going= on just in case there is something wrong with the key or IV as I stated be= fore.=C2=A0

Quynh. =C2=A0

--047d7b33c67c86c0830523ee2361-- From nobody Sat Nov 7 10:38:52 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0D11B2A32 for ; Sat, 7 Nov 2015 10:38:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJ9-HyPJZLFk for ; Sat, 7 Nov 2015 10:38:49 -0800 (PST) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::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 EBA231B2A1E for ; Sat, 7 Nov 2015 10:38:48 -0800 (PST) Received: by wimw2 with SMTP id w2so48060611wim.1 for ; Sat, 07 Nov 2015 10:38:47 -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=hzpqMH42aMYbvrYoE9fZCl6Y9qYnVJA82mVwUhjkGyE=; b=Hq2hg7t7caI5kluK5pKMbJMnZWn0/LqXNbyRV+LEVALa010BYCEBRY9HOtHHqOEJJf /uQkkiZFtQLlTS1GrUO05+QMUUPgSzQIZLJzGqSNNCmNWarux/WC2XMLir66Yt+rCkPr ZoFJEq15UnD8umwL56IrLoHiJ8zTyqX7TlxiSJCF7Hgdkh1qYj3uXDeWrUFTfiGMHUji tg+1Q7f/dMmdSlZ3hNi8lZBHcxlzQAiLRcoqOCtfNaO0FDY8CAnVXT4YRpoRszkUdkb0 DV3gCN9SS6MoLBPWutG/LBGsLV7N6lGc8opACKHjoZlPZFiWPD84yzGnB6vbs84c6GcH O3fg== X-Received: by 10.194.205.9 with SMTP id lc9mr5593986wjc.120.1446921527451; Sat, 07 Nov 2015 10:38:47 -0800 (PST) Received: from [10.219.15.163] (smb-adpcdg1-06.hotspot.hub-one.net. [213.174.99.134]) by smtp.gmail.com with ESMTPSA id t126sm5156010wmd.23.2015.11.07.10.38.45 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 07 Nov 2015 10:38:46 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_26FFB217-9B84-4993-BA9D-15FC51048070" Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Yoav Nir In-Reply-To: Date: Sat, 7 Nov 2015 19:38:45 +0100 Message-Id: References: <201511062139.11139.davemgarrett@gmail.com> <5FA3B020-DDCC-4745-B969-9A54A98C9948@gmail.com> To: Eric Rescorla X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data limit for GCM under a given key. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2015 18:38:50 -0000 --Apple-Mail=_26FFB217-9B84-4993-BA9D-15FC51048070 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 7 Nov 2015, at 12:50 PM, Eric Rescorla wrote: >=20 >=20 >=20 > On Fri, Nov 6, 2015 at 7:46 PM, Yoav Nir > wrote: >=20 > > On 7 Nov 2015, at 11:39 AM, Dave Garrett > wrote: > > > > On Friday, November 06, 2015 08:13:44 pm Eric Rescorla wrote: > >> Update: we discussed this extensively in Yokohama and based on = Watson's > >> feedback and offline comments from David McGrew, the consensus was = that we > >> needed to add some sort of rekeying mechanism to support long-lived = flows. > >> Expect a PR on this next week. > >> > >> Note: We'll still need guidance to implementations on when to = re-key, but > >> we don't expect to have a hard protocol limit. > > > > If re-keying is back up for discussion, let me restate my request = for it to be routine, rather than only an niche-case feature. Any re-key = schedule should be considered valid, but the spec should set a = "SHOULD"-level requirement that the minimum be once every N hours or M = terabytes, whichever comes first (where N & M are some bike-shedable = numbers with some expectation of randomization in values for each = period). >=20 > N and M will be different depending on the algorithms, no? >=20 > I think before we start with pull requests we should be certain of = what the requirements are for this rekeying. >=20 > These were discussed extensively both in the interim and at IETF. The = purpose of rekeying in this context is to deal with cryptographic = exhaustion, namely having more ciphertext under the same key than is = safe for a > given algorithm (where safe is defined by an analysis like the one = Watson > has posted upthread). Sure, but once you provide a rekeying capability, the connection can = keep going forever. That means you could be running for weeks and = terabytes without injecting any freshness, and the the internal state = remains in memory for all that time. A compromise of the state in the = future allows decrypting everything since the beginning of the = connection. This is not the same as having to tear down the connection = at the cryptographic exhaustion. It is possible to get this kind of forward secrecy if the rekeying = includes modifying the internal state in a non-reversible way such as = hashing the master secret into a new master secret (or using = HKDF-Extract), but that hurts the goal of having each side recycle the = keys at its own pace (which is a strange goal, because my security = depends on the security of my receiving keys as much as it depends on = the security of my transmitting keys). Yoav --Apple-Mail=_26FFB217-9B84-4993-BA9D-15FC51048070 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On 7 Nov 2015, at 12:50 PM, Eric Rescorla <ekr@rtfm.com> = wrote:



On Fri, Nov 6, 2015 = at 7:46 PM, Yoav Nir <ynir.ietf@gmail.com> wrote:

> On 7 Nov 2015, at 11:39 AM, Dave Garrett <davemgarrett@gmail.com> wrote:
>
> On Friday, November 06, 2015 08:13:44 pm Eric Rescorla = wrote:
>> Update: we discussed this extensively in = Yokohama and based on Watson's
>> feedback and = offline comments from David McGrew, the consensus was that we
>> needed to add some sort of rekeying mechanism to = support long-lived flows.
>> Expect a PR on this = next week.
>>
>> Note: We'll = still need guidance to implementations on when to re-key, but
>> we don't expect to have a hard protocol limit.
>
> If re-keying is back up for = discussion, let me restate my request for it to be routine, rather than = only an niche-case feature. Any re-key schedule should be considered = valid, but the spec should set a "SHOULD"-level requirement that the = minimum be once every N hours or M terabytes, whichever comes first = (where N & M are some bike-shedable numbers with some expectation of = randomization in values for each period).

N and M will be different depending on the algorithms, = no?

I think before we start with pull = requests we should be certain of what the requirements are for this = rekeying.

These were discussed extensively both = in the interim and at IETF. The purpose of rekeying in this context is = to deal with cryptographic exhaustion, namely having more ciphertext = under the same key than is safe for a
given = algorithm (where safe is defined by an analysis like the one = Watson
has posted = upthread).

Sure, but once you provide a rekeying capability, = the connection can keep going forever. That means you could be running = for weeks and terabytes without injecting any freshness, and the the = internal state remains in memory for all that time. A compromise of the = state in the future allows decrypting everything since the beginning of = the connection. This is not the same as having to tear down the = connection at the cryptographic exhaustion.

It is possible to get this kind of = forward secrecy if the rekeying includes modifying the internal state in = a non-reversible way such as hashing the master secret into a new master = secret (or using HKDF-Extract), but that hurts the goal of having each = side recycle the keys at its own pace (which is a strange goal, because = my security depends on the security of my receiving keys as much as it = depends on the security of my transmitting keys).
Yoav

= --Apple-Mail=_26FFB217-9B84-4993-BA9D-15FC51048070-- From nobody Mon Nov 9 15: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 8AD711ACC91 for ; Mon, 9 Nov 2015 15:53:22 -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, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-65T9NPeZG6 for ; Mon, 9 Nov 2015 15:53:21 -0800 (PST) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A5E51ACCEA for ; Mon, 9 Nov 2015 15:53:21 -0800 (PST) Received: by ykdv3 with SMTP id v3so202488275ykd.0 for ; Mon, 09 Nov 2015 15:53:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=6KzDkuUNbI+wAPaHF7tDr1pPpji68SIE6vY5jaADt5M=; b=wqu8JsaKA+4vHv629fRw55AJJAUGaGHfKzbQrnzaP5uJ28zpCDSf2vTz3ct8DZD1xm Gau3pvgjYyocAzE5tIvQ8vHV9b5Eom+pZ4CQUoaypaYhAxiOdvNfYca/ftdx1XXNn8O+ q8CG+I5MJKQJ/3si5DUhDMDbYEHyOaIjR5wH5vrO0ysvzIn+B8BWeDZQvK3zTL76GGhh YOB/Rp3yo3M0A0t3nXKdrMJz5JDRVXy7hpg811qYxaf9CnIPo6DakOdEn5yMjdECDCxR SAF82F9WQD59ldMGD/zTg/N+eaZnlmE5HR/B0y1g4k37aMgU4xJRn/v2pnUA3jjPoL34 apnA== 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=6KzDkuUNbI+wAPaHF7tDr1pPpji68SIE6vY5jaADt5M=; b=PJbnX6bXdFSAKwJ81gagT0P7OHK6RzQJbZR9PNKmUlAIyRQVn8vBk9QltowCC8XRP/ SbzXMFK/6rmva10jcIYMedxrEuo8GG1ezWW/OzP1zJhKIh+uRjFiZHLeuj870PZzOLOq BJCUA5er2VhAeAawSvBjn/SynC3XXm5fQdDcn8OfZH73VTY8be+ENSVGjblA9LvhtnQv Ku2wJpNjEkrI/UnkkNKmTsI6qFgIR9Wf3BYEOkiry1Jc9QzfOV+xScdT3PhrJzJ4/xvl ObRh2zONmqV8Hii6dn+KV6XwxySO085Sw9UmPiJ7wgbTgl53PqNS/Bh2yXW5C7HR+eK4 lE8Q== X-Gm-Message-State: ALoCoQnUJvIhYUDB77J8Okhm8NY1vxppBDYrIpm1wdOUSXjaG6z/5KR33OW9uysfFTT9ObNzHRHZ X-Received: by 10.129.34.4 with SMTP id i4mr503631ywi.155.1447113200383; Mon, 09 Nov 2015 15:53:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.221.203 with HTTP; Mon, 9 Nov 2015 15:52:40 -0800 (PST) In-Reply-To: References: <201510171708.16547.davemgarrett@gmail.com> <201510171734.26589.davemgarrett@gmail.com> <20151017220548.GF15070@mournblade.imrryr.org> <20151017221733.GG15070@mournblade.imrryr.org> <20151017230257.GI15070@mournblade.imrryr.org> <84C5B67D-F236-4BFD-AA13-5CC13062B8C5@akamai.com> From: Eric Rescorla Date: Mon, 9 Nov 2015 15:52:40 -0800 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11408678426fa50524244cbc Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR for anti-downgrade 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: Mon, 09 Nov 2015 23:53:22 -0000 --001a11408678426fa50524244cbc Content-Type: text/plain; charset=UTF-8 In an attempt to close the loop here, I've pushed a new PR version with a 64-bit sentinel with the final byte being 00 for TLS 1.2 and 01 for TLS 1.3. If anyone strongly objects to this construction, please raise your hand now. Otherwise, I plan to merge this on Wednesday. https://github.com/tlswg/tls13-spec/pull/284 -Ekr On Mon, Oct 19, 2015 at 10:05 AM, Martin Thomson wrote: > On 19 October 2015 at 08:08, Eric Rescorla wrote: > > overloading the time field > > lowers the risk of false positives because we can choose a sentinel that > > will never > > collide with a conformant TLS 1.2 ServerHello. By contrast, a sentinel in > > the > > randomly generated portion always has a 2^{-n} chance of collision. > > Yes, this is right. The marginal gain is that the proportion of > servers that generate a time here are immune to collisions. If > servers all servers did that, we wouldn't have to worry about > collisions at all. Unfortunately, we do know that some generate random > values. > --001a11408678426fa50524244cbc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In an attempt to close the loop here, I've pushed a ne= w PR version with a 64-bit sentinel with the final byte being 00 for TLS 1.= 2 and 01 for TLS 1.3. If anyone strongly objects to this construction, plea= se raise your hand now.

Otherwise, I plan to merge this = on Wednesday.


On Mon, Oct 19, 2015 a= t 10:05 AM, Martin Thomson <martin.thomson@gmail.com>= wrote:
On 19 October 20= 15 at 08:08, Eric Rescorla <ekr@rtfm.com= > wrote:
> overloading the time field
> lowers the risk of false positives because we can choose a sentinel th= at
> will never
> collide with a conformant TLS 1.2 ServerHello. By contrast, a sentinel= in
> the
> randomly generated portion always has a 2^{-n} chance of collision.
Yes, this is right.=C2=A0 The marginal gain is that the proportion o= f
servers that generate a time here are immune to collisions.=C2=A0 If
servers all servers did that, we wouldn't have to worry about
collisions at all. Unfortunately, we do know that some generate random
values.

--001a11408678426fa50524244cbc-- From nobody Mon Nov 9 16: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 0791E1AD0A4 for ; Mon, 9 Nov 2015 16:30:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 U8zqXrntyxLn for ; Mon, 9 Nov 2015 16:30:47 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0143.outbound.protection.outlook.com [65.55.169.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18C121AD0A3 for ; Mon, 9 Nov 2015 16:30:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=98jJsGJykqhGGr+poskbRgTI9Kcz4EbN8gKGI7//+dM=; b=koMXC0y6do+BkI/DeCROG17lhqUEHt+9P0PEPDte4wvkdGPnHeB66IAF4nuOcyiR5rdQvcUI3FHP03c6MkCbetHDjDQzr8s36brzQt8vvZtacUicISGnQPtqa+/Lj3tPIxjP2YRlPx4yIE/4PCGy3ljDBLaVLia3gRXhnP0RqGs= Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) with Microsoft SMTP Server (TLS) id 15.1.318.15; Tue, 10 Nov 2015 00:30:45 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0318.003; Tue, 10 Nov 2015 00:30:45 +0000 From: Christian Huitema To: Eric Rescorla , Martin Thomson Thread-Topic: [TLS] PR for anti-downgrade mechanism Thread-Index: AQHRAo2XH3FLVO3qjUqf9pv0XfX2g55jwgYAgAAnWQCACqFpAIAAC9CAgAAJyQCAABn0AIAABjIAgACDCoCAAMyMgIAABv+AgAAA0ACAAAHkAIAAIPYAgAACZICAAATsAIAABXSAgAADTwCAAAEugIAAAhuAgAAAuACAAAv4AIACl4gAgAAIlACAACCMAIAhctoAgAAD/tA= Date: Tue, 10 Nov 2015 00:30:44 +0000 Message-ID: References: <201510171708.16547.davemgarrett@gmail.com> <201510171734.26589.davemgarrett@gmail.com> <20151017220548.GF15070@mournblade.imrryr.org> <20151017221733.GG15070@mournblade.imrryr.org> <20151017230257.GI15070@mournblade.imrryr.org> <84C5B67D-F236-4BFD-AA13-5CC13062B8C5@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=huitema@microsoft.com; x-originating-ip: [131.107.174.75] x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0655; 5:3HOwxnt9Ea+7b8Trdquh8qJ0oLIDYb4Bz90SfEGzT6ZmXmeGGS7pAawLVl4+mXoj64i3XBBt6QOsnhS9lGjXSRoPuJ27xrAipY9gH7ekp+16s03iH6mVG6oNspApuY4mEENJZSKsjKsflnTjAbXAjw==; 24:WDHVt2TIKvm+PfqiLfITDwaZelBcHuMgSR+LOwkJK/Aq4kkT6qdm0quyrBQ2Cq7GSfE8bJc5iUd1nd0kNugjRrNEsEMnbli2t3F0C/IaM1M=; 20:G7v9vexzbaVrBicKCuCatGSJdtZrEox9znKUosYbDVY0dSOhroeQDaR39/FDTNmF04A/7Gm121rfagZJ3WKFmA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0655; x-o365eop-header: O365_EOP: Allow for Unauthenticated Relay x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046)(61426024)(61427024); SRVR:DM2PR0301MB0655; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0655; x-forefront-prvs: 07562C22DA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(24454002)(377454003)(86612001)(101416001)(76576001)(50986999)(5001770100001)(122556002)(76176999)(19580395003)(105586002)(40100003)(66066001)(97736004)(106356001)(106116001)(93886004)(81156007)(5008740100001)(5004730100002)(10090500001)(99286002)(11100500001)(2950100001)(92566002)(2900100001)(5002640100001)(15975445007)(5003600100002)(86362001)(102836002)(33656002)(189998001)(5007970100001)(54356999)(87936001)(5001960100002)(8990500004)(10290500002)(10400500002)(5005710100001)(74316001)(77096005); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0655; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Nov 2015 00:30:44.9572 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0655 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR for anti-downgrade 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 Nov 2015 00:30:49 -0000 T24gTW9uZGF5LCBOb3ZlbWJlciA5LCAyMDE1IDM6NTMgUE0sIEVyaWMgUmVzY29ybGEgd3JvdGU6 DQo+IEluIGFuIGF0dGVtcHQgdG8gY2xvc2UgdGhlIGxvb3AgaGVyZSwgSSd2ZSBwdXNoZWQgYSBu ZXcgUFIgdmVyc2lvbiB3aXRoIGEgNjQtYml0IHNlbnRpbmVsIHdpdGggDQo+IHRoZSBmaW5hbCBi eXRlIGJlaW5nIDAwIGZvciBUTFMgMS4yIGFuZCAwMSBmb3IgVExTIDEuMy4gSWYgYW55b25lIHN0 cm9uZ2x5IG9iamVjdHMgdG8gdGhpcw0KPiBjb25zdHJ1Y3Rpb24sIHBsZWFzZSByYWlzZSB5b3Vy IGhhbmQgbm93Lg0KPg0KPiBPdGhlcndpc2UsIEkgcGxhbiB0byBtZXJnZSB0aGlzIG9uIFdlZG5l c2RheS4NCj4gDQo+IGh0dHBzOi8vZ2l0aHViLmNvbS90bHN3Zy90bHMxMy1zcGVjL3B1bGwvMjg0 DQoNCkVkaXRvcmlhbDogeW91ciBwcm9wb3NlZCB0ZXh0IHNheXMgIi4uLk1VU1Qgc2V0IHRoZSBm aXJzdCBzaXggIGJ5dGVzIG9mIGl0cyBSYW5kb20gdmFsdWUgdG8gdGhlIHRoZSBieXRlcyA0NCA0 RiA1NyA0RSA0NyA1MiA0NCAwMS4iIEkgYXNzdW1lIHlvdSBtZWFuIHRoZSBmaXJzdCA4IGJ5dGVz LCBhbmQgdGhhdCB5b3UgZG8gbm90IHJlYWxseSB3YW50IHRvIGhhdmUgInRoZSIgdHdpY2UuIA0K DQpDb3VsZCB5b3UgYWxzbyBhZGQgYSByZWZlcmVuY2UgdG8gdGhlIGRvY3VtZW50IHRoYXQgc3Bl Y2lmaWVzIHVzaW5nIDQ0IDRGICA1NyA0RSA0NyA1MiA0NCAwMCBieSAiVExTIDEuMiBzZXJ2ZXJz IHdoaWNoIGFyZSAgbmVnb3RpYXRpbmcgVExTIDEuMSBvciBiZWxvdyIgPw0KDQotLSBDaHJpc3Rp YW4gSHVpdGVtYQ0KDQoNCg== From nobody Mon Nov 9 16:34: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 041101AD186 for ; Mon, 9 Nov 2015 16:34:52 -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, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHmgop7qeXta for ; Mon, 9 Nov 2015 16:34:51 -0800 (PST) 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 CB5E21AD160 for ; Mon, 9 Nov 2015 16:34:50 -0800 (PST) Received: by ykek133 with SMTP id k133so293255378yke.2 for ; Mon, 09 Nov 2015 16:34:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=BM0Rr2GCjvaGURHzdUS2oWQSlvN9GgG6njBEz6Hqhgc=; b=vCgqvxEx1Ug2P2dPraR2iSz3y+3aEWV9W6PQl5j7gxQbLwD7c4jiWrBM7PCJQ9d1R5 h8BkD3vxzgIiosUGaKkExTKQQIPtad7z4trkqUldg7H8IiLhHhl4Gn+2h31FM1XLnFDE ufdG9izoP3ybdlUV4HHPPQ8l6gb3G6QgfUBLogAgtTG2ovj1xgkMTpUjmBQKrnGW5J73 VuIqlAOtlJGT+8i1Ebgd7tLyUM1FD7LfsvT2npJVcJRY5Vwqpn+viEqJBwaNbKLukzMS PEEZBOcUPk8Gm4lVJz48gSV9qeFxkq00F3IA07oEXs8MEP3XJzByaYT7DJQTBxou8tOR wSSA== 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=BM0Rr2GCjvaGURHzdUS2oWQSlvN9GgG6njBEz6Hqhgc=; b=IZ3ChEIz0ZYn35RD2AtS7z9nTlHqbX71ebS+QWmDTbmisJs5hLMc1idfaxHNBlqjOv dfCi9bxlCV6GVVI/lAU+tXagGYPh2+RrobeOOLY1HF7tcflJJsvMt1NlAH/TZJho33em Vh6gMrC3lEDip7fxkmjwE3es9WmIAaqPTQ9fyCZbEv60JCILxK7HmwTDJtHb1r8RnKng hjZIOJd1LlexHp0AYy+Izax0FGfpu5lbJsXB+rzb52F/bMI9fY3YwOwBngZio5V17+aH y83TfiUPmCCiFNUukOS72zhXndm3CxrNbOCrLXGB5jkO80y4x+EyHmZgBEvtHdWw5BT/ YcFA== X-Gm-Message-State: ALoCoQlHPf5nitpvDYCiDWQZuVYDkN/8DY3qpVU40KHY2hZDxz30AmvQDbG5HukuwVh6RgWE6s7G X-Received: by 10.129.34.4 with SMTP id i4mr627044ywi.155.1447115690080; Mon, 09 Nov 2015 16:34:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.221.203 with HTTP; Mon, 9 Nov 2015 16:34:10 -0800 (PST) In-Reply-To: References: <201510171708.16547.davemgarrett@gmail.com> <201510171734.26589.davemgarrett@gmail.com> <20151017220548.GF15070@mournblade.imrryr.org> <20151017221733.GG15070@mournblade.imrryr.org> <20151017230257.GI15070@mournblade.imrryr.org> <84C5B67D-F236-4BFD-AA13-5CC13062B8C5@akamai.com> From: Eric Rescorla Date: Mon, 9 Nov 2015 16:34:10 -0800 Message-ID: To: Christian Huitema Content-Type: multipart/alternative; boundary=001a11408678a82685052424e04a Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR for anti-downgrade 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 Nov 2015 00:34:52 -0000 --001a11408678a82685052424e04a Content-Type: text/plain; charset=UTF-8 On Mon, Nov 9, 2015 at 4:30 PM, Christian Huitema wrote: > On Monday, November 9, 2015 3:53 PM, Eric Rescorla wrote: > > In an attempt to close the loop here, I've pushed a new PR version with > a 64-bit sentinel with > > the final byte being 00 for TLS 1.2 and 01 for TLS 1.3. If anyone > strongly objects to this > > construction, please raise your hand now. > > > > Otherwise, I plan to merge this on Wednesday. > > > > https://github.com/tlswg/tls13-spec/pull/284 > > Editorial: your proposed text says "...MUST set the first six bytes of > its Random value to the the bytes 44 4F 57 4E 47 52 44 01." I assume you > mean the first 8 bytes, and that you do not really want to have "the" twice. > Fixed. Could you also add a reference to the document that specifies using 44 4F > 57 4E 47 52 44 00 by "TLS 1.2 servers which are negotiating TLS 1.1 or > below" ? We don't have one. Wasn't totally sure how to handle that. -Ekr > > -- Christian Huitema > > > --001a11408678a82685052424e04a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Nov 9, 2015 at 4:30 PM, Christian Huitema <= ;huitema@microso= ft.com> wrote:
On Monday, November 9, 2015 3:53 PM, Eric Rescorla wrote:
> In an attempt to close the loop here, I've pushed a new PR version= with a 64-bit sentinel with
> the final byte being 00 for TLS 1.2 and 01 for TLS 1.3. If anyone stro= ngly objects to this
> construction, please raise your hand now.
>
> Otherwise, I plan to merge this on Wednesday.
>
> https://github.com/tlswg/tls13-spec/pull/284
Editorial: your proposed text says "...MUST set the first six= =C2=A0 bytes of its Random value to the the bytes 44 4F 57 4E 47 52 44 01.&= quot; I assume you mean the first 8 bytes, and that you do not really want = to have "the" twice.

Fixed.


Could you also add a reference to the document that specifies using 44 4F= =C2=A0 57 4E 47 52 44 00 by "TLS 1.2 servers which are=C2=A0 negotiati= ng TLS 1.1 or below" ?

We don't ha= ve one. Wasn't totally sure how to handle that.

-Ekr

=C2=A0

-- Christian Huitema



--001a11408678a82685052424e04a-- From nobody Mon Nov 9 16:41: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 B94721B29EA for ; Mon, 9 Nov 2015 16:41:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 Sa5-ybDwC82e for ; Mon, 9 Nov 2015 16:41:39 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0728.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::728]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4487A1B29E9 for ; Mon, 9 Nov 2015 16:41:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Anc5iSbuu+GmHH066raZHld0XxoUKtLL8N1rJJvPjNU=; b=Jv6lO0p0xahlF2mvZydp4/5rx2CqfwEREHbsjOiFX/fsqoEUBR1hqqZxSiY7wFsvopbMXTD2EkZhcPfxx8kkwbhtj1IvPrqwsefnH82a4mWxUsr0Tkl0P7tmFOQ/MjONgrD1kZZ5JH6GfKzHCjKIyduPSxwdqzfZyA5zu/yw3CI= Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0653.namprd03.prod.outlook.com (10.160.96.15) with Microsoft SMTP Server (TLS) id 15.1.318.15; Tue, 10 Nov 2015 00:41:34 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0318.003; Tue, 10 Nov 2015 00:41:34 +0000 From: Christian Huitema To: Eric Rescorla Thread-Topic: [TLS] PR for anti-downgrade mechanism Thread-Index: AQHRAo2XH3FLVO3qjUqf9pv0XfX2g55jwgYAgAAnWQCACqFpAIAAC9CAgAAJyQCAABn0AIAABjIAgACDCoCAAMyMgIAABv+AgAAA0ACAAAHkAIAAIPYAgAACZICAAATsAIAABXSAgAADTwCAAAEugIAAAhuAgAAAuACAAAv4AIACl4gAgAAIlACAACCMAIAhctoAgAAD/tCAAAeaAIAAAKgg Date: Tue, 10 Nov 2015 00:41:34 +0000 Message-ID: References: <201510171708.16547.davemgarrett@gmail.com> <201510171734.26589.davemgarrett@gmail.com> <20151017220548.GF15070@mournblade.imrryr.org> <20151017221733.GG15070@mournblade.imrryr.org> <20151017230257.GI15070@mournblade.imrryr.org> <84C5B67D-F236-4BFD-AA13-5CC13062B8C5@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=huitema@microsoft.com; x-originating-ip: [131.107.174.75] x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0653; 5:0lPR02QbMcA1sFCPwIqhg5QBTguga+EGp8AEB7rkyMWE5O9se5EOWPYHr7tTIn9gPvz1uLFqBhuFes2C2ymqTxE3qV+zjrsqopVO0MTmuyX+VOQt6lu3lN4fe+3lwK2ySdYzdhg/Kbw2AhnnfDMWeg==; 24:fWDqiN0apjkUSmOeC9ix+ICQbjFF0PMsxZvZMc4snU30Xcf9ht1TU/Eouo4yRT3ycJ96ewh9BFgSxz3inVXAAhRF3mtSejVMaTGNLCQnR4w=; 20:QLQnGPqJmJNKwjVspxq4MZHuhBC9WKZeixfdDSQiKFaoXNZIWGTAXJe8+YTn9eJ1dkuaxckVnA3eBdVbfB32Dg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0653; x-o365eop-header: O365_EOP: Allow for Unauthenticated Relay x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(8121501046)(520078)(5005006)(10201501046)(3002001)(61426024)(61427024); SRVR:DM2PR0301MB0653; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0653; x-forefront-prvs: 07562C22DA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(199003)(189002)(24454002)(86362001)(19580395003)(77096005)(66066001)(87936001)(122556002)(86612001)(2900100001)(102836002)(74316001)(2950100001)(92566002)(19580405001)(110136002)(76576001)(5001960100002)(10090500001)(40100003)(11100500001)(97736004)(105586002)(10290500002)(10400500002)(106116001)(8990500004)(99286002)(93886004)(5003600100002)(189998001)(5008740100001)(5004730100002)(5007970100001)(5001920100001)(81156007)(76176999)(54356999)(5005710100001)(33656002)(50986999)(106356001)(101416001)(5002640100001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0653; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Nov 2015 00:41:34.3102 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0653 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR for anti-downgrade 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 Nov 2015 00:41:43 -0000 T24gTW9uZGF5LCBOb3ZlbWJlciA5LCAyMDE1IDQ6MzQgUE0sIEVyaWMgUmVzY29ybGEgd3JvdGU6 DQoNCj4gT24gTW9uLCBOb3YgOSwgMjAxNSBhdCA0OjMwIFBNLCBDaHJpc3RpYW4gSHVpdGVtYSA8 aHVpdGVtYUBtaWNyb3NvZnQuY29tPiB3cm90ZToNCj4NCj4uLi4NCj4+IEVkaXRvcmlhbDogeW91 ciBwcm9wb3NlZCB0ZXh0IHNheXMgIi4uLk1VU1Qgc2V0IHRoZSBmaXJzdCBzaXjCoCBieXRlcyBv ZiBpdHMgUmFuZG9tIHZhbHVlIA0KPj4gdG8gdGhlIHRoZSBieXRlcyA0NCA0RiA1NyA0RSA0NyA1 MiA0NCAwMS4iIEkgYXNzdW1lIHlvdSBtZWFuIHRoZSBmaXJzdCA4IGJ5dGVzLCBhbmQgdGhhdCAN Cj4+IHlvdSBkbyBub3QgcmVhbGx5IHdhbnQgdG8gaGF2ZSAidGhlIiB0d2ljZS4NCj4NCj4gRml4 ZWQuDQoNClRoYW5rcw0KDQo+PiBDb3VsZCB5b3UgYWxzbyBhZGQgYSByZWZlcmVuY2UgdG8gdGhl IGRvY3VtZW50IHRoYXQgc3BlY2lmaWVzIHVzaW5nIDQ0IDRGwqAgNTcgNEUgNDcgNTIgDQo+PiA0 NCAwMCBieSAiVExTIDEuMiBzZXJ2ZXJzIHdoaWNoIGFyZcKgIG5lZ290aWF0aW5nIFRMUyAxLjEg b3IgYmVsb3ciID8NCj4NCj4gV2UgZG9uJ3QgaGF2ZSBvbmUuIFdhc24ndCB0b3RhbGx5IHN1cmUg aG93IHRvIGhhbmRsZSB0aGF0Lg0KDQpJIHN1c3BlY3RlZCB0aGF0LiBTcGVudCBzb21ldGltZXMg bG9va2luZyBmb3IgdGV4dCBpbiBwdWJsaXNoZWQgUkZDLCBjb3VsZCBub3QgZmluZCBpdC4gSSBz dXNwZWN0IHRoYXQgbWFueSByZWFkZXJzIHdpbGwgZmFsbCBpbiB0aGUgc2FtZSB0cmFwIGFuZCBs b3NlIHNvbWUgdGltZS4gQ291bGQgeW91IGFkZCB0ZXh0IGV4cGxhaW5pbmcgdGhhdCB0aGlzIGlz IGFuIHVuZG9jdW1lbnRlZCBmZWF0dXJlIG9mIHNvbWUgaW1wbGVtZW50YXRpb25zLCBhbmQgdGhh dCB3ZSBhcmUgcmVjb21tZW5kaW5nIGl0cyB1c2U/IE9yIHNvbWV0aGluZyB0byB0aGF0IGVmZmVj dC4uLg0KDQotLSBDaHJpc3RpYW4gSHVpdGVtYQ0KDQoNCg0K From nobody Mon Nov 9 16:45: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 2F90C1B29FF for ; Mon, 9 Nov 2015 16:45:04 -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, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5Q2K5g8ucKV for ; Mon, 9 Nov 2015 16:45:03 -0800 (PST) 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 1DAE81B2A10 for ; Mon, 9 Nov 2015 16:45:03 -0800 (PST) Received: by ykek133 with SMTP id k133so293503825yke.2 for ; Mon, 09 Nov 2015 16:45:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Zy4eNn4ElXAJSnAO0RvOeJW6ETl0CTnYHjWfJeBhEO0=; b=jWnKPumBXP1kjDpoatdqu0MrLPlg57BRTQYznHt3iYhlQ9HSwh84a3jk5ZuaGnXgXj aEd8Y+1Cf1ON1XvSVF5IRQfUjMT3nmXhpaEnjXgSqItVG0GHp5T4Onq/gSsyl+bFHp4x FHmV8wdkuxai1XDovaZCpCWM/xlvDpz24rXkJ+uyWorABo/BHnUNyfO8cfLkvK9sSI8W N5a5ySoFlWt6Ac7PSdzY34AezPGq8/1cSTCxSvvDdmMjPaoa3aEvOCotZcTbFEml1ouw OLh6qhOHmcZ/vJLv/JWxzCEjSjpk2wv63Jbzo6uwiiSs6S5W25as1C1wT/rai/g7E4i2 jhxg== 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=Zy4eNn4ElXAJSnAO0RvOeJW6ETl0CTnYHjWfJeBhEO0=; b=PFryeJ7dQ0FfyiAIefb/uzC7zBUpi73q3WM97VGfP1lZmRfyqNgbQAkwA0zWuRzt7y FwmVPKi6b5Op2iQoaNT3y3lzOWaHCUr0RhIsBRLoTLxmsGXNfS36T+RyrvQy0wq5VkrL PBDoKJbfxxXvqo4hdrB+vJcIlmuKftwq6PTR6zL7g9XRN1A9q5DLnTXte+44riaFm35N 6hgTMgjKPoHdSxWhrqpw8pwOnGd00lysdA1aSnTxykxUXOSAUwBUNpdmV4t3slMLB1dK qoHahBtpiJXmT+x07YqnIMEgjBGHQNWiGPezFLl7KfREDjOuMZG3JegabA96WsSvExkE jg/w== X-Gm-Message-State: ALoCoQnrOI94ujYCBf+mXGiuzX6RgdxpP6LVgkX9P5ASJ936jBrEMda2F14p7mdo1IPZnpJbSzj7 X-Received: by 10.129.34.4 with SMTP id i4mr653352ywi.155.1447116302463; Mon, 09 Nov 2015 16:45:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.221.203 with HTTP; Mon, 9 Nov 2015 16:44:22 -0800 (PST) In-Reply-To: References: <201510171708.16547.davemgarrett@gmail.com> <201510171734.26589.davemgarrett@gmail.com> <20151017220548.GF15070@mournblade.imrryr.org> <20151017221733.GG15070@mournblade.imrryr.org> <20151017230257.GI15070@mournblade.imrryr.org> <84C5B67D-F236-4BFD-AA13-5CC13062B8C5@akamai.com> From: Eric Rescorla Date: Mon, 9 Nov 2015 16:44:22 -0800 Message-ID: To: Christian Huitema Content-Type: multipart/alternative; boundary=001a11408678285c80052425059d Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR for anti-downgrade 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 Nov 2015 00:45:04 -0000 --001a11408678285c80052425059d Content-Type: text/plain; charset=UTF-8 On Mon, Nov 9, 2015 at 4:41 PM, Christian Huitema wrote: > On Monday, November 9, 2015 4:34 PM, Eric Rescorla wrote: > > > On Mon, Nov 9, 2015 at 4:30 PM, Christian Huitema > wrote: > > > >... > >> Editorial: your proposed text says "...MUST set the first six bytes of > its Random value > >> to the the bytes 44 4F 57 4E 47 52 44 01." I assume you mean the first > 8 bytes, and that > >> you do not really want to have "the" twice. > > > > Fixed. > > Thanks > > >> Could you also add a reference to the document that specifies using 44 > 4F 57 4E 47 52 > >> 44 00 by "TLS 1.2 servers which are negotiating TLS 1.1 or below" ? > > > > We don't have one. Wasn't totally sure how to handle that. > > I suspected that. Spent sometimes looking for text in published RFC, could > not find it. I suspect that many readers will fall in the same trap and > lose some time. Could you add text explaining that this is an undocumented > feature of some implementations, and that we are recommending its use? Or > something to that effect... > Worse, we just invented it. What about if I say "TLS 1.2 servers SHOULD..." -Ekr > > -- Christian Huitema > > > > --001a11408678285c80052425059d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Nov 9, 2015 at 4:41 PM, Christian Huitema <= ;huitema@microso= ft.com> wrote:
On Monday, November 9, 2015 4:34 PM, Eric Rescorla wrote:

> On Mon, Nov 9, 2015 at 4:30 PM, Christian Huitema <huitema@microsoft.com> wrote:
>
>...
>> Editorial: your proposed text says "...MUST = set the first six=C2=A0 bytes of its Random value
>> to the the bytes 44 4F 57 4E 47 52 44 01." I assume you mean = the first 8 bytes, and that
>> you do not really want to have "the" twice.
>
> Fixed.

Thanks

>> Could you also add a reference to the document that specifies usin= g 44 4F=C2=A0 57 4E 47 52
>> 44 00 by "TLS 1.2 servers which are=C2=A0 negotiating TLS 1.1= or below" ?
>
> We don't have one. Wasn't totally sure how to handle that.

I suspected that. Spent sometimes looking for text in published RFC,= could not find it. I suspect that many readers will fall in the same trap = and lose some time. Could you add text explaining that this is an undocumen= ted feature of some implementations, and that we are recommending its use? = Or something to that effect...

Worse, w= e just invented it. What about if I say "TLS 1.2 servers SHOULD...&quo= t;

-Ekr
=C2=A0

-- Christian Huitema




--001a11408678285c80052425059d-- From nobody Mon Nov 9 16:54: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 96BDB1B2B9E for ; Mon, 9 Nov 2015 16:54:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 frGu8AV2mi1s for ; Mon, 9 Nov 2015 16:54:28 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0102.outbound.protection.outlook.com [65.55.169.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CC0A1B2B8C for ; Mon, 9 Nov 2015 16:54:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jY89iudhDPHihrcmp2KHRCzre6TJlLbo12TN7N7N2Cs=; b=IWUVqBzgXatipWBrVg+Q2ih1lp7DSr0VW4iszl1rQOWRMYG6nTJLsOz1DIde8wn8tf5m+EZ6wn5ALKjSiYlFzoWDWkF/dY/zcqBUPW/dx8WN5de4fupo3IVr3KLoY59CkIni+yeeMJypFQjnJ1gYFKJKO2QsvxPTnu/H+5553WY= Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0654.namprd03.prod.outlook.com (10.160.96.16) with Microsoft SMTP Server (TLS) id 15.1.318.15; Tue, 10 Nov 2015 00:54:25 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0318.003; Tue, 10 Nov 2015 00:54:25 +0000 From: Christian Huitema To: Eric Rescorla Thread-Topic: [TLS] PR for anti-downgrade mechanism Thread-Index: AQHRAo2XH3FLVO3qjUqf9pv0XfX2g55jwgYAgAAnWQCACqFpAIAAC9CAgAAJyQCAABn0AIAABjIAgACDCoCAAMyMgIAABv+AgAAA0ACAAAHkAIAAIPYAgAACZICAAATsAIAABXSAgAADTwCAAAEugIAAAhuAgAAAuACAAAv4AIACl4gAgAAIlACAACCMAIAhctoAgAAD/tCAAAeaAIAAAKgggAACMgCAAADXwA== Date: Tue, 10 Nov 2015 00:54:25 +0000 Message-ID: References: <201510171708.16547.davemgarrett@gmail.com> <201510171734.26589.davemgarrett@gmail.com> <20151017220548.GF15070@mournblade.imrryr.org> <20151017221733.GG15070@mournblade.imrryr.org> <20151017230257.GI15070@mournblade.imrryr.org> <84C5B67D-F236-4BFD-AA13-5CC13062B8C5@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=huitema@microsoft.com; x-originating-ip: [131.107.174.75] x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0654; 5:djkFYwm5PuQaBaawASamYGH5aTWbC+lAbGnGIOZCFZBgYtnrmY7fyvc/LxGslDKKiERHBtH2pkH5Lcd76JQWkRPIAjiViYsSqfTJvqWpJGGByRvKPLSigULtqxQx9LjMj1G+yPdj2s1ERtWM2zybKQ==; 24:TYsvfZugnpgUbIrqpim5yRNr9zAPpA/mxyq4Bvhx3WACTDS4Ue63MtPivy2n97L1iNxbXnkcLWNb7jaVhOfQOhXJ7ehqzcIgz7lOIHHI1qA=; 20:gE4a+N9wUa+Hl0CyIMap4B10ZQP4nTiPZosEo1fpcAldmY4LNStS2jt6zQAtUnPMxa/6XMsAxJ0Wc1xjVU1SgQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0654; x-o365eop-header: O365_EOP: Allow for Unauthenticated Relay x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046)(61426024)(61427024); SRVR:DM2PR0301MB0654; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0654; x-forefront-prvs: 07562C22DA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(189002)(199003)(377454003)(11100500001)(8990500004)(81156007)(5004730100002)(105586002)(74316001)(101416001)(97736004)(5002640100001)(110136002)(189998001)(93886004)(92566002)(76576001)(5001960100002)(19580405001)(19580395003)(5008740100001)(50986999)(33656002)(99286002)(86612001)(122556002)(106116001)(106356001)(40100003)(54356999)(76176999)(87936001)(86362001)(5007970100001)(66066001)(5003600100002)(10290500002)(5005710100001)(10400500002)(10090500001)(77096005)(102836002)(2950100001)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0654; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Nov 2015 00:54:25.2431 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0654 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR for anti-downgrade 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 Nov 2015 00:54:32 -0000 T24gTW9uZGF5LCBOb3ZlbWJlciA5LCAyMDE1IDQ6NDQgUE0sIEVyaWMgUmVzY29ybGEgd3JvdGU6 DQo+IE9uIE1vbiwgTm92IDksIDIwMTUgYXQgNDo0MSBQTSwgQ2hyaXN0aWFuIEh1aXRlbWEgPGh1 aXRlbWFAbWljcm9zb2Z0LmNvbT4gd3JvdGU6DQo+PiBPbiBNb25kYXksIE5vdmVtYmVyIDksIDIw MTUgNDozNCBQTSwgRXJpYyBSZXNjb3JsYSB3cm90ZToNCj4+PiBPbiBNb24sIE5vdiA5LCAyMDE1 IGF0IDQ6MzAgUE0sIENocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQG1pY3Jvc29mdC5jb20+IHdy b3RlOg0KPi4uLg0KPj4+PiBDb3VsZCB5b3UgYWxzbyBhZGQgYSByZWZlcmVuY2UgdG8gdGhlIGRv Y3VtZW50IHRoYXQgc3BlY2lmaWVzIHVzaW5nIDQ0IDRGwqAgNTcgNEUgNDcgNTINCj4+Pj4gNDQg MDAgYnkgIlRMUyAxLjIgc2VydmVycyB3aGljaCBhcmXCoCBuZWdvdGlhdGluZyBUTFMgMS4xIG9y IGJlbG93IiA/DQo+Pj4NCj4+PiBXZSBkb24ndCBoYXZlIG9uZS4gV2Fzbid0IHRvdGFsbHkgc3Vy ZSBob3cgdG8gaGFuZGxlIHRoYXQuDQo+Pg0KPj4gSSBzdXNwZWN0ZWQgdGhhdC4gU3BlbnQgc29t ZXRpbWVzIGxvb2tpbmcgZm9yIHRleHQgaW4gcHVibGlzaGVkIFJGQywgDQo+PiBjb3VsZCBub3Qg ZmluZCBpdC4gSSBzdXNwZWN0IHRoYXQgbWFueSByZWFkZXJzIHdpbGwgZmFsbCBpbiB0aGUgc2Ft ZSB0cmFwIA0KPj4gYW5kIGxvc2Ugc29tZSB0aW1lLiBDb3VsZCB5b3UgYWRkIHRleHQgZXhwbGFp bmluZyB0aGF0IHRoaXMgaXMgYW4gDQo+PiB1bmRvY3VtZW50ZWQgZmVhdHVyZSBvZiBzb21lIGlt cGxlbWVudGF0aW9ucywgYW5kIHRoYXQgd2UgYXJlIA0KPj4gcmVjb21tZW5kaW5nIGl0cyB1c2U/ IE9yIHNvbWV0aGluZyB0byB0aGF0IGVmZmVjdC4uLg0KPg0KPiBXb3JzZSwgd2UganVzdCBpbnZl bnRlZCBpdC4gV2hhdCBhYm91dCBpZiBJIHNheSAiVExTIDEuMiBzZXJ2ZXJzIFNIT1VMRC4uLiIN Cg0KVGhhdCB3b3VsZCBiZSBiZXR0ZXIuIFRoZXJlIGlzIGhvd2V2ZXIgYSBxdWVzdGlvbiBvZiAi aXMgdGhpcyB0aGUgcmlnaHQgZG9jdW1lbnQuIiBUaGlzIGlzIHRoZSBzcGVjIGZvciBUTFMgMS4z IHNlcnZlcnMsIHNvIGltcGxlbWVudGVycyBvZiBUTFMgMS4yIHNlcnZlcnMgbWF5IG9yIG1heSBu b3QgcmVhZCBpdC4gVGhpcyBkb2N1bWVudCAib2Jzb2xldGVzIDUyNDYsIiBzbyBjYW5ub3QgcmVh bGx5IHVwZGF0ZSBpdC4gTGV0IHNlZSB3aGF0IHlvdSBjb21lIHVwIHdpdGguLi4NCg0KLS0gQ2hy aXN0aWFuIEh1aXRlbWENCg0KDQoNCg== From nobody Mon Nov 9 17:15: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 3716E1B2CFF for ; Mon, 9 Nov 2015 17:15:24 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 6winP6zHWOH4 for ; Mon, 9 Nov 2015 17:15:23 -0800 (PST) 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 C05E51B2CFB for ; Mon, 9 Nov 2015 17:15:22 -0800 (PST) Received: by oies6 with SMTP id s6so66775406oie.1 for ; Mon, 09 Nov 2015 17:15:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts_net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lzzdO4jKPIXTZzQgHmbHpNFQnND+By8GzLHGEU2Mpig=; b=Xm3HZo2spx+tS9sh6mj9rQXmap8ImrMyZOUCzhShU2e1uY/ugZLkbJ58u68+kX4AcE 554iQTaTh8rw0DE3R9j3zGCzJ46dcLwI0Ri6oXVemHvsgnw1bcuuBboYaENejBabXfVP LzHYQfDMwMHLspPo1Hx69LblIilyU/zkYug4PYUjTq/dAChQLNojXjhk+hP1BpazdRPv Kh52gCMO6ioct7+aUcflKr3ZHtDc0tsK4e0mdn+ZXfzXFWXwqKqWvhXdAykLk9QTauPj +rj3cDy8cFZ536BLDcv3zJjYtiilkV7Iq4UD5OqrbHMWK6Fy7hXOQIFwhwvRVuhCLmmZ GxIQ== 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=lzzdO4jKPIXTZzQgHmbHpNFQnND+By8GzLHGEU2Mpig=; b=dfNnGGau5upoMXRfvrY1qq5jbdQOO4Z1JM7vu4+xChrg9w+NnwFP3TdHjx4lcCK1R2 /b4kK7VeMQoAcPi5mMlBMk6BhjRbElzztpGB9AnA56zlwS3QsWwSJeYIwlfn7cMro//9 XNEzenfbtqEt5gco96KmTmNMXRJaIbeCwEhD7oL4oVvzvJLrdpYQximga2sJFOmcS7Xv r3+0XbF0O0cnE8frzWY0Bs5/7m9Q+FybvlzplIGSN4Gm40cPUSk1tHwNXmjB07qg9IZj ktkVaj2RGJsnywdSxcyqCwxt/c1gR0jHbGBCVnY09WIiL6oif6cGBpgLOV3gcvDyX92U yatQ== X-Gm-Message-State: ALoCoQlSRG1j2RKWndYqKxPUiPkGDNGtSFku+U5WSiy8n+OkN8cQ7v03ccCxkJe4fTYsGY9Hdbzz MIME-Version: 1.0 X-Received: by 10.202.4.129 with SMTP id 123mr380430oie.131.1447118122064; Mon, 09 Nov 2015 17:15:22 -0800 (PST) Received: by 10.76.10.8 with HTTP; Mon, 9 Nov 2015 17:15:21 -0800 (PST) In-Reply-To: References: <201510171708.16547.davemgarrett@gmail.com> <201510171734.26589.davemgarrett@gmail.com> <20151017220548.GF15070@mournblade.imrryr.org> <20151017221733.GG15070@mournblade.imrryr.org> <20151017230257.GI15070@mournblade.imrryr.org> <84C5B67D-F236-4BFD-AA13-5CC13062B8C5@akamai.com> Date: Mon, 9 Nov 2015 17:15:21 -0800 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a113b30f09d6a090524257132 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR for anti-downgrade 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 Nov 2015 01:15:24 -0000 --001a113b30f09d6a090524257132 Content-Type: text/plain; charset=UTF-8 Would the values chosen there have a calamitous impact on Mon, 24 Dec 2125 11:21:51 GMT? I think that's the epoch when a regular TLS1.2 server would put that value in. I know it's 110 years in the future, but would it be better to choose a value that's in the past? On Mon, Nov 9, 2015 at 3:52 PM, Eric Rescorla wrote: > In an attempt to close the loop here, I've pushed a new PR version with a > 64-bit sentinel with the final byte being 00 for TLS 1.2 and 01 for TLS > 1.3. If anyone strongly objects to this construction, please raise your > hand now. > > Otherwise, I plan to merge this on Wednesday. > > https://github.com/tlswg/tls13-spec/pull/284 > > -Ekr > > > > On Mon, Oct 19, 2015 at 10:05 AM, Martin Thomson > wrote: > >> On 19 October 2015 at 08:08, Eric Rescorla wrote: >> > overloading the time field >> > lowers the risk of false positives because we can choose a sentinel that >> > will never >> > collide with a conformant TLS 1.2 ServerHello. By contrast, a sentinel >> in >> > the >> > randomly generated portion always has a 2^{-n} chance of collision. >> >> Yes, this is right. The marginal gain is that the proportion of >> servers that generate a time here are immune to collisions. If >> servers all servers did that, we wouldn't have to worry about >> collisions at all. Unfortunately, we do know that some generate random >> values. >> > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > -- Colm --001a113b30f09d6a090524257132 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Would the values chosen there have a calamitous i= mpact on=C2=A0Mon, 24 Dec 21= 25 11:21:51 GMT? I think that's the epoch when a regular TLS1.2 server = would put that value in. I know it's 110 years in the future, but would= it be better to choose a value that's in the past?
<= div class=3D"gmail_extra">
On Mon, Nov 9, 201= 5 at 3:52 PM, Eric Rescorla <ekr@rtfm.com> wrote:
In an attempt to close the loop here, I= 've pushed a new PR version with a 64-bit sentinel with the final byte = being 00 for TLS 1.2 and 01 for TLS 1.3. If anyone strongly objects to this= construction, please raise your hand now.

Otherwise, I = plan to merge this on Wednesday.


-Ekr



On Mon, Oct 19, 2015= at 10:05 AM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 19 October 2015 at 08:= 08, Eric Rescorla <ekr= @rtfm.com> wrote:
> overloading the time field
> lowers the risk of false positives because we can choose a sentinel th= at
> will never
> collide with a conformant TLS 1.2 ServerHello. By contrast, a sentinel= in
> the
> randomly generated portion always has a 2^{-n} chance of collision.
Yes, this is right.=C2=A0 The marginal gain is that the proportion o= f
servers that generate a time here are immune to collisions.=C2=A0 If
servers all servers did that, we wouldn't have to worry about
collisions at all. Unfortunately, we do know that some generate random
values.


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




--
Colm
--001a113b30f09d6a090524257132-- From nobody Mon Nov 9 17:29: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 6A0801B2DAF for ; Mon, 9 Nov 2015 17:29:39 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 1zAPxzoTsApf for ; Mon, 9 Nov 2015 17:29:38 -0800 (PST) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003: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 E44741B2DA2 for ; Mon, 9 Nov 2015 17:29:37 -0800 (PST) Received: by obdgf3 with SMTP id gf3so153859817obd.3 for ; Mon, 09 Nov 2015 17:29:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts_net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=0oIhiHknqRq/2/iojV08n1DO37+5wY776PcaIwqDHnU=; b=uEpD94DhUq13Ya9jTZ4LcaV1WhRRdg+R2Aa0H7ESAe7Vvf0TbDpGRnGIbAPBz7KgwH W/a+3ca9dl+uNb03g23wjd0kiOTqjA3DWO0JW7Z2EKs9/CjlOv4byKOTqdWNTV95Rp5o DlTI14YglMJ/ouex2dP3wuhD5d6FOp524wLbY028ZOOjCkzhoGSWwVvdgqodz2png6Kq Ls8umV5H19So13yMFjFQLEbS5cAyfElqFUnMOrLsphyNgpIk3/vJaLMqwFWMbDnSpmGu i278LHf5fJmIxR/3aDW1IYa8d5Wl/vg8yRu9G53tfwzPJpDyX5FxiuwDMnO27M2jUYX5 38eA== 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=0oIhiHknqRq/2/iojV08n1DO37+5wY776PcaIwqDHnU=; b=S2q9ae+mAH89ZBYGHxll5UpWWw6fYNVtuPeAZirNt9Wliz5uYWtRpNBiu92JQW5oL/ kBfBoJ7uCGNVIVikI+30DjraFvY6x5LXRV0icTJfth2Uf2t4LW3qGwv+N2hotF6amchI /Nb9ZMS3tkZ+OL55FBq/jYadj/Y/hvXm0Gjo0+XdG6V1DwcvBMUTm/20HwNSniBo6idD 1nt18YMRVcDTtHtaEz+7vrIGnvme+I1IBdbPxVzlKkclHtriJNcrzJpfRBGln2P2o35C q7juWqEN7gUeWslR53x8TJbPC7bguFrDZAMAGp0KoTsoesKyEQqUesQxlx1GtwhW8Zi3 BfoA== X-Gm-Message-State: ALoCoQkJTpx9wrgzxNupF9lrv8hKuSETbpzFAp1C2OfFfkvJfWm2eQr8WNQRfJOsxuqGLTLaOAyK MIME-Version: 1.0 X-Received: by 10.182.65.138 with SMTP id x10mr412256obs.39.1447118977319; Mon, 09 Nov 2015 17:29:37 -0800 (PST) Received: by 10.76.10.8 with HTTP; Mon, 9 Nov 2015 17:29:37 -0800 (PST) In-Reply-To: References: <201510171708.16547.davemgarrett@gmail.com> <201510171734.26589.davemgarrett@gmail.com> <20151017220548.GF15070@mournblade.imrryr.org> <20151017221733.GG15070@mournblade.imrryr.org> <20151017230257.GI15070@mournblade.imrryr.org> <84C5B67D-F236-4BFD-AA13-5CC13062B8C5@akamai.com> Date: Mon, 9 Nov 2015 17:29:37 -0800 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: Eric Rescorla , "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11c1bb249760a5052425a4d3 Archived-At: Subject: Re: [TLS] PR for anti-downgrade 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 Nov 2015 01:29:39 -0000 --001a11c1bb249760a5052425a4d3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable No, you're right and I'm off : that value is in the past. I was treating it as a 64-bit epoch value. Bad me for having a 2038-ready timestamp interpreter. On Mon, Nov 9, 2015 at 5:20 PM, Eric Rescorla wrote: > On Mon, Nov 9, 2015 at 5:15 PM, Colm MacC=C3=A1rthaigh > wrote: > >> >> Would the values chosen there have a calamitous impact on Mon, 24 Dec >> 2125 11:21:51 GMT? I think that's the epoch when a regular TLS1.2 server >> would put that value in. I know it's 110 years in the future, but would = it >> be better to choose a value that's in the past? >> > > I believe that the current time is: +/- 56 41 46 1f > And the first 4 bytes are: 44 4F 57 4E, which should be in the past. > > Am I taking crazy pills? > > -Ekr > > > >> On Mon, Nov 9, 2015 at 3:52 PM, Eric Rescorla wrote: >> >>> In an attempt to close the loop here, I've pushed a new PR version with >>> a 64-bit sentinel with the final byte being 00 for TLS 1.2 and 01 for T= LS >>> 1.3. If anyone strongly objects to this construction, please raise your >>> hand now. >>> >>> Otherwise, I plan to merge this on Wednesday. >>> >>> https://github.com/tlswg/tls13-spec/pull/284 >>> >>> -Ekr >>> >>> >>> >>> On Mon, Oct 19, 2015 at 10:05 AM, Martin Thomson < >>> martin.thomson@gmail.com> wrote: >>> >>>> On 19 October 2015 at 08:08, Eric Rescorla wrote: >>>> > overloading the time field >>>> > lowers the risk of false positives because we can choose a sentinel >>>> that >>>> > will never >>>> > collide with a conformant TLS 1.2 ServerHello. By contrast, a >>>> sentinel in >>>> > the >>>> > randomly generated portion always has a 2^{-n} chance of collision. >>>> >>>> Yes, this is right. The marginal gain is that the proportion of >>>> servers that generate a time here are immune to collisions. If >>>> servers all servers did that, we wouldn't have to worry about >>>> collisions at all. Unfortunately, we do know that some generate random >>>> values. >>>> >>> >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >>> >> >> >> -- >> Colm >> > > --=20 Colm --001a11c1bb249760a5052425a4d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

No, you're right and I'm off := that value is in the past. I was treating it as =C2=A0a 64-bit epoch value= .=C2=A0 Bad me for having a 2038-ready timestamp interpreter.=C2=A0

On Mon, Nov 9, = 2015 at 5:20 PM, Eric Rescorla <ekr@rtfm.com> wrote:
On Mon, Nov 9, 2015 at 5:15 PM, Colm Mac= C=C3=A1rthaigh <colm@allcosts.net> wrote:

Would the values chosen there have a calamitous= impact on=C2=A0Mon, 24 Dec = 2125 11:21:51 GMT? I think that's the epoch when a regular TLS1.2 serve= r would put that value in. I know it's 110 years in the future, but wou= ld it be better to choose a value that's in the past?

I believe that the current time is= : +/- 56 41 46 1f=C2=A0
And the first 4 bytes are: 44 4F 57 4E, w= hich should be in the past.

Am I taking crazy pill= s?

-Ekr

=

On Mon, Nov 9, 2015 at 3:52 PM, Eric Rescorla <ekr@rtfm.com= > wrote:
In an attempt to close the loop here, I've pushed a new PR ver= sion with a 64-bit sentinel with the final byte being 00 for TLS 1.2 and 01= for TLS 1.3. If anyone strongly objects to this construction, please raise= your hand now.

Otherwise, I plan to merge this on Wedne= sday.


-Ekr


<= /div>

On= Mon, Oct 19, 2015 at 10:05 AM, Martin Thomson <martin.thomson@gmai= l.com> wrote:
On 19 October 2015 at= 08:08, Eric Rescorla <ekr@rtfm.com> wrote:
> overloading the time field
> lowers the risk of false positives because we can choose a sentinel th= at
> will never
> collide with a conformant TLS 1.2 ServerHello. By contrast, a sentinel= in
> the
> randomly generated portion always has a 2^{-n} chance of collision.
Yes, this is right.=C2=A0 The marginal gain is that the proportion o= f
servers that generate a time here are immune to collisions.=C2=A0 If
servers all servers did that, we wouldn't have to worry about
collisions at all. Unfortunately, we do know that some generate random
values.


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




--
Colm




--
Colm
--001a11c1bb249760a5052425a4d3-- From nobody Wed Nov 11 17:00: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 97EF61B37D7 for ; Wed, 11 Nov 2015 10:40:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 sxtZ3gGjlQx8 for ; Wed, 11 Nov 2015 10:40:13 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0784.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:784]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A73C1B37DA for ; Wed, 11 Nov 2015 10:40:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0h4g3axNBIziwFa/MjjpAbXzIz9PZYbp6MBgbiVmY6k=; b=Mr0Bf5vk9+Sfg/aATIRHTqn+AH9UuZY74/cXXl+9rlEsgvPNP6Wg413XobcK/e1kyvpm3uvCjw5roPwr5REpMHrmVuenXt2VhCSN8ryLxqCzobB5efRi5iEMK88aN6dHXWhhwZx2P05OTvqfLvauEQqkvcexBSzoRu8L0QGJ1Xc= Received: from CY1PR03MB1374.namprd03.prod.outlook.com (10.163.16.28) by CY1PR03MB1374.namprd03.prod.outlook.com (10.163.16.28) with Microsoft SMTP Server (TLS) id 15.1.318.15; Wed, 11 Nov 2015 18:39:51 +0000 Received: from CY1PR03MB1374.namprd03.prod.outlook.com ([10.163.16.28]) by CY1PR03MB1374.namprd03.prod.outlook.com ([10.163.16.28]) with mapi id 15.01.0318.003; Wed, 11 Nov 2015 18:39:51 +0000 From: Mike Bishop To: "tls@ietf.org" Thread-Topic: Application data during renegotiation handshake Thread-Index: AdEcrQnuroKmbT4dRXSQtSnp2IGJXA== Date: Wed, 11 Nov 2015 18:39:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com; x-originating-ip: [2601:600:8300:3b9a:cc6d:4a41:90f:dfb2] x-microsoft-exchange-diagnostics: 1; CY1PR03MB1374; 5:8j/YiJvN0fxF+R1fKIP2kerKshslYwznJLskkf2glzNNPYjSFzzLxeE3BJ3lvSd8ROO+GFZFsa28PvvU3IW0sf5PSfQkHl3JXBrVobFlZUwpkDoMzyHMb1Quo1UwWmsXqsK6tMOwHfJRoHdAlmkEKw==; 24:SFft+n6q3aH4dBXDtayKEzN1mAF81k14E5S2rHXnbOD4276tvGAS30dBA5vFPvTt08FTb98MeBWTO7i/BoX+k+47+LbJ11Gr4B88NNv1Jhs=; 20:+8cYRobG2EenszxLh1OoDvR8sW5w8TMSdGRcHilVP5993V/QLhKSrm9bf07klFytTHmW/C8ad9Fg7QV9gTFC0w== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB1374; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001)(61426024)(61427024); SRVR:CY1PR03MB1374; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB1374; x-forefront-prvs: 0757EEBDCA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(189002)(92566002)(19625215002)(105586002)(5008740100001)(77096005)(54356999)(101416001)(16236675004)(19300405004)(50986999)(99286002)(87936001)(86362001)(33656002)(19617315012)(74316001)(2351001)(229853001)(86612001)(5007970100001)(189998001)(10290500002)(106356001)(5002640100001)(76576001)(2900100001)(102836002)(19580395003)(5003600100002)(97736004)(81156007)(5004730100002)(8990500004)(2501003)(5001920100001)(107886002)(15975445007)(40100003)(110136002)(5001960100002)(11100500001)(10400500002)(5005710100001)(122556002)(10090500001)(450100001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB1374; H:CY1PR03MB1374.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR03MB13743E3AE466C2F8F7AC140687130CY1PR03MB1374namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Nov 2015 18:39:51.3396 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB1374 Archived-At: X-Mailman-Approved-At: Wed, 11 Nov 2015 17:00:21 -0800 Subject: [TLS] Application data during renegotiation handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2015 18:40:16 -0000 --_000_CY1PR03MB13743E3AE466C2F8F7AC140687130CY1PR03MB1374namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A question for TLS implementation owners: During the discussion of the TLS= 1.2 portion of https://tools.ietf.org/html/draft-thomson-http2-client-cert= s-00, it was pointed out that HTTP/2 breaks a simplification of the HTTP-TL= S interface that some implementations may have assumed. Since HTTP/1.1 only has one request per connection and that request is wait= ing on the client certificate to be retrieved via renegotiation, you can as= sume that the client will not send any application data between the new Cli= entHello and sending the Finished message. ("...it is expected that the ne= gotiation will begin before no more than a few records are received from th= e client.") Likewise, the server will not emit any application data betwee= n sending the HelloRequest and sending its own Finished message. Since HTT= P/2 will have other requests being generated and served in parallel, this i= s no longer the case. Per the TLS 1.2 spec, that's permitted, but if it's = not been done before, I'm afraid we may be hitting less-tested code paths. I know that BoringSSL explicitly requires that application data flow be stopped during reneg= otiation. If the HTTP working group adopts this draft, do the owners of ot= her TLS implementations expect this to require changes in their TLS 1.2 imp= lementations? --_000_CY1PR03MB13743E3AE466C2F8F7AC140687130CY1PR03MB1374namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A question for TLS implementation owners:  Duri= ng the discussion of the TLS 1.2 portion of https://tools.ietf.org/html/draft-thomson-http2-client-certs-00, it wa= s pointed out that HTTP/2 breaks a simplification of the HTTP-TLS interface= that some implementations may have assumed.

 

Since HTTP/1.1 only has one request per connection a= nd that request is waiting on the client certificate to be retrieved via re= negotiation, you can assume that the client will not send any application d= ata between the new ClientHello and sending the Finished message.  (“…it is expected that the= negotiation will begin before no more than a few records are received from= the client.”)  Likewise, the server will not emit any applicati= on data between sending the HelloRequest and sending its own Finished message.  Since HTTP/2 will have other requests being genera= ted and served in parallel, this is no longer the case.  Per the TLS 1= .2 spec, that’s permitted, but if it’s not been done before, I&= #8217;m afraid we may be hitting less-tested code paths.

 

I know that BoringSSL explicitly requires that application data flow be stopped dur= ing renegotiation.  If the HTTP working group adopts this draft, do th= e owners of other TLS implementations expect this to require changes in the= ir TLS 1.2 implementations?

--_000_CY1PR03MB13743E3AE466C2F8F7AC140687130CY1PR03MB1374namp_-- From nobody Wed Nov 11 17:32: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 490AE1A0087 for ; Wed, 11 Nov 2015 17:32:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 tHz-ulf07-h8 for ; Wed, 11 Nov 2015 17:32:10 -0800 (PST) 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 A624D1A003B for ; Wed, 11 Nov 2015 17:32:10 -0800 (PST) Received: by qgea14 with SMTP id a14so37495638qge.0 for ; Wed, 11 Nov 2015 17:32:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=HRSmbKXajYm/aWhEyN8fh3QoCK84G0SK4OHcZTAdyrg=; b=NYUtNCgSQEkWrJJAewjMZx9Ai2Bhid+Hc/CWW1bjXdWznA0HTxDhArvm15lNCGFHPF WRLQr+hJcTIkL5rX74fcNS6QUWBe2otA0P2OlOSL/G3Ok+YQeVMdZgjMfJQOjbq7ueFu f3BI5uY/3VXXCoDorZYYMNo9ocIyeWIy2blQg/LhjS2Jnu/PkYKXivsWmqEWtzYGHmNn pizd2Uk1DvPmpW4oX5EwROLFaGtxXsOB+IcuGJfzAjl6RL6Ks/JsVklESgoUEnRzsPUF USVb4SjaUa0uiP6UEpmclVesheqdMTbpmztPvFz9pnW+4Bnvf1T1uqnz6KqsfyMAmQfz 3G6w== MIME-Version: 1.0 X-Received: by 10.140.201.139 with SMTP id w133mr14473224qha.15.1447291929838; Wed, 11 Nov 2015 17:32:09 -0800 (PST) Sender: alangley@gmail.com Received: by 10.140.81.175 with HTTP; Wed, 11 Nov 2015 17:32:09 -0800 (PST) In-Reply-To: References: Date: Wed, 11 Nov 2015 17:32:09 -0800 X-Google-Sender-Auth: oCmnFNq7LgXsoous5TfiyATCym8 Message-ID: From: Adam Langley To: Mike Bishop Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Application data during renegotiation handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 01:32:12 -0000 On Wed, Nov 11, 2015 at 10:39 AM, Mike Bishop wrote: > Since HTTP/1.1 only has one request per connection and that request is > waiting on the client certificate to be retrieved via renegotiation, you = can > assume that the client will not send any application data between the new > ClientHello and sending the Finished message. (=E2=80=9C=E2=80=A6it is e= xpected that the > negotiation will begin before no more than a few records are received fro= m > the client.=E2=80=9D) Likewise, the server will not emit any application= data > between sending the HelloRequest and sending its own Finished message. > Since HTTP/2 will have other requests being generated and served in > parallel, this is no longer the case. Per the TLS 1.2 spec, that=E2=80= =99s > permitted, but if it=E2=80=99s not been done before, I=E2=80=99m afraid w= e may be hitting > less-tested code paths. > > I know that BoringSSL explicitly requires that application data flow be > stopped during renegotiation. If the HTTP working group adopts this draf= t, > do the owners of other TLS implementations expect this to require changes= in > their TLS 1.2 implementations? Chrome, Android WebView etc treat a HelloRequest when HTTP/2 has been negotiated as a fatal error. We do not expect to change this. The TLS 1.3 post-handshake client-auth was intended, as I recall, to support HTTP/1.1 over TLS 1.3. With HTTP/2 isn't it cleaner to do client-auth at the HTTP layer (i.e. by signing exporter values)? SPDY, at one point of development, supported this via the CREDENTIAL frame. That also avoided a confused deputy problem: with connection pooling over HTTP/2, there seems to be a risk of confusion about which requests are authenticated with which client certificate. Cheers AGL --=20 Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Wed Nov 11 22:43: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 6C3AE1AD359 for ; Wed, 11 Nov 2015 22:43:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPpLV_nvrUk8 for ; Wed, 11 Nov 2015 22:43:27 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::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 02D551ACEFD for ; Wed, 11 Nov 2015 22:43:27 -0800 (PST) Received: by wmww144 with SMTP id w144so74295064wmw.0 for ; Wed, 11 Nov 2015 22:43:25 -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 :content-transfer-encoding:message-id:references:to; bh=XY3Xwb77zMTvVATxqfx/QAxzudc0/hLKXpBe0vhpZOE=; b=FY5ygkXf/XuMDwyOOiKK/hSpURpwGlWtkfH3UTRJOKgMaO9J1smyuPrfsBVDS9BGHN QJYKdusB4gS296V22lt45mq02BtWDivXjwlDk/l5166IZcUEKTis6ICRl1DuKCANnVSQ ebjx4jFPd8skm7qUm90XblVI9tHDHo1mPhb4oDChLseKidSuxzWgGN8kvsACAJq5XFvi Nko2t9ZjXqcKsJVZphdKwuzOYbfnqJju+HzOu6D3Jh8t6BsPW06oSt2fGXmL4dZG9HcU I8O0ZPX3RZuQCo81Z00cttdzYspJHD7BcnSQgaE4itKPSHXuGbmFegeyG7lZsCYBVODT mS5g== X-Received: by 10.194.95.202 with SMTP id dm10mr14491756wjb.56.1447310605666; Wed, 11 Nov 2015 22:43:25 -0800 (PST) Received: from yoavs-mbp.mshome.net ([176.13.16.49]) by smtp.gmail.com with ESMTPSA id ej10sm11835003wjd.32.2015.11.11.22.43.24 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Nov 2015 22:43:25 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Yoav Nir In-Reply-To: Date: Thu, 12 Nov 2015 08:43:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Adam Langley X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: Mike Bishop , "tls@ietf.org" Subject: Re: [TLS] Application data during renegotiation handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 06:43:28 -0000 > On 12 Nov 2015, at 3:32 AM, Adam Langley = wrote: >=20 > The TLS 1.3 post-handshake client-auth was intended, as I recall, to > support HTTP/1.1 over TLS 1.3. No, it was (and is) presented as a way to do client certificate = authentication with HTTP/2 not at the initial handshake. > With HTTP/2 isn't it cleaner to do client-auth at the HTTP layer (i.e. > by signing exporter values)? It is. I thought that an HTTP authentication method based on = certificates could be a drop-in replacement for TLS layer = authentication, but someone (I think it was Mike) pointed out that with = TLS-layer certificate authentication the stream continues after the = authentication, while with HTTP-layer authentication, the stream ends = with a 401 status code, and the client has to start a new stream with = the Authorization header. So applications would need to be changed for = this to work. > SPDY, at one point of development, > supported this via the CREDENTIAL frame. That also avoided a confused > deputy problem: with connection pooling over HTTP/2, there seems to be > a risk of confusion about which requests are authenticated with which > client certificate. I agree that is a good idea. We have to be mindful of how this interacts = with multiple concurrent streams requiring authentication, and whether = we can avoid race conditions where the server sends a different response = for the same resource depending on authentication without actually = requiring it (=E2=80=9CHello, guest=E2=80=9D vs =E2=80=9CHello, Adam=E2=80= =9D) Yoav From nobody Thu Nov 12 00:23: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 BC9F61AC3BF for ; Thu, 12 Nov 2015 00:23:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UaB8jM3A6PNC for ; Thu, 12 Nov 2015 00:23:45 -0800 (PST) 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 22EA51A92FD for ; Thu, 12 Nov 2015 00:23:45 -0800 (PST) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 8AD7CA0B3E; Thu, 12 Nov 2015 08:23:44 +0000 (UTC) Received: from dhcp-10-40-2-201.brq.redhat.com (dhcp-10-40-2-201.brq.redhat.com [10.40.2.201]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tAC8NfgX021620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 12 Nov 2015 03:23:43 -0500 Message-ID: <1447316621.9624.3.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Mike Bishop , "tls@ietf.org" Date: Thu, 12 Nov 2015 09:23:41 +0100 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: Subject: Re: [TLS] Application data during renegotiation handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 08:23:46 -0000 On Wed, 2015-11-11 at 18:39 +0000, Mike Bishop wrote: > I know that BoringSSL explicitly requires that application data flow > be stopped during renegotiation.  If the HTTP working group adopts > this draft, do the owners of other TLS implementations expect this to > require changes in their TLS 1.2 implementations? GnuTLS also has this requirement. regards, Nikos From nobody Thu Nov 12 01:09: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 871AF1B2C65 for ; Thu, 12 Nov 2015 01:09:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szkGPfCqJbGQ for ; Thu, 12 Nov 2015 01:09:07 -0800 (PST) Received: from ns3.dns-engine.com (ns3.dns-engine.com [87.106.189.53]) by ietfa.amsl.com (Postfix) with ESMTP id F11281B2C63 for ; Thu, 12 Nov 2015 01:09:06 -0800 (PST) Received: from [10.102.1.6] (unknown [104.238.169.17]) by ns3.dns-engine.com (Postfix) with ESMTPSA id 4D19618002DF for ; Thu, 12 Nov 2015 09:09:03 +0000 (GMT) To: tls@ietf.org References: <1447316621.9624.3.camel@redhat.com> From: Matt Caswell Message-ID: <5644572F.3080203@baggins.org> Date: Thu, 12 Nov 2015 09:09:03 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <1447316621.9624.3.camel@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Application data during renegotiation handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 09:09:08 -0000 On 12/11/15 08:23, Nikos Mavrogiannopoulos wrote: > On Wed, 2015-11-11 at 18:39 +0000, Mike Bishop wrote: > >> I know that BoringSSL explicitly requires that application data flow >> be stopped during renegotiation. If the HTTP working group adopts >> this draft, do the owners of other TLS implementations expect this to >> require changes in their TLS 1.2 implementations? > GnuTLS also has this requirement. > OpenSSL also does not allow application data during renegotiation. Matt From nobody Thu Nov 12 04:37: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 3920A1A877C for ; Thu, 12 Nov 2015 04:37:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKgHSkq7bafa for ; Thu, 12 Nov 2015 04:37:05 -0800 (PST) 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 0B9D71A8785 for ; Thu, 12 Nov 2015 04:37:04 -0800 (PST) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 7884A42E5C1; Thu, 12 Nov 2015 12:37:04 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-169.brq.redhat.com [10.34.0.169]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tACCb2wg020818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Nov 2015 07:37:04 -0500 From: Hubert Kario To: tls@ietf.org Date: Thu, 12 Nov 2015 13:37:02 +0100 Message-ID: <2631117.oMlyajinHN@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.9 (Linux/4.2.5-201.fc22.x86_64; KDE/4.14.13; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1454613.UBkQgQpqVj"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: Cc: Mike Bishop Subject: Re: [TLS] Application data during renegotiation handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 12:37:07 -0000 --nextPart1454613.UBkQgQpqVj Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Wednesday 11 November 2015 18:39:51 Mike Bishop wrote: > Per the TLS 1.2 spec, that's permitted, but if > it's not been done before, I'm afraid we may be hitting less-tested > code paths. It's also something that Java does and what NSS supports. But indeed it is problematic: https://rt.openssl.org/Ticket/Display.html?id=3D3712&user=3Dguest&pass=3D= guest =2D-=20 Regards, Hubert Kario Senior 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 --nextPart1454613.UBkQgQpqVj 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 iQIcBAABCgAGBQJWRIfuAAoJEJKo0bgB0vX1XRsP/iR7KZvP7z3j5o/0rj3PThmJ VGZVXDHU2wXb5XdEI0z98T11ltEeG/wNtkclK+tUX0qNy9LHCB0T7JeV0Oj44g3f g4oZ/Ist78pmsI1FjrMvtuMtiWP9MdP0txgJopOvEFkO6mWCTBrOoRYWhWUqQKk4 pyIUSVDDpJKnHyLDkT8QQdGyXNe8CjN02ubjne1b7pO3z6z1UzEBvDxr/GH6Oxwd E6FURxkrG8CcL0NWBNLhHDJrgSO0uNg+YMhvsVh3BT8MGrKUyf3XVXl12UGm06Zh EI84gbsIIW75/DTBc4qjuLo/A3i1hfeQWZB6xmkee3Ms1TABF1eoNLMKfQy0HSdX wrqdQicIsIIXWec2l7SAjPeWW+Dz249nVBe+VRe0WFVYS2kffNiyznP7I3U/wclX cnK3wQl0z1EETZpq/9h8YneMlYu9CReogreI3BiJii9Jc/A4FwuzhRfNQpPBN9mQ 4YZRDjDvo7WRb4+9Ge4iSDFYMEJsX1bWKRmoEzqVoBoP2yc0nUWMwZ7lTPWYEgaO EnWIUtJzLg3oob/mspoH+9zf9tN6vJe38pe4c27IIU8HKJIk4Zcp+veKFIntXHwS HaPFrNcFQsdrSlECPfcf++Cfcwd7sBu4M8r52rHvIqVxzwZazMneJQwzW5Jj1LEW QS+YP9Z/jv+TKl3UpuRr =wnsJ -----END PGP SIGNATURE----- --nextPart1454613.UBkQgQpqVj-- From nobody Thu Nov 12 06:52: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 21A481B2FA5 for ; Thu, 12 Nov 2015 06:52:00 -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 gSHwg-bzC3lo for ; Thu, 12 Nov 2015 06:51:58 -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 366C81B2FA2 for ; Thu, 12 Nov 2015 06:51:58 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 2E5462AEF8; Thu, 12 Nov 2015 15:51:56 +0100 (CET) X-purgate-ID: 152705::1447339916-00006F99-394A7C86/0/0 X-purgate-size: 698 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 211AB4078B; Thu, 12 Nov 2015 15:51:56 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 182151A368; Thu, 12 Nov 2015 15:51:56 +0100 (CET) In-Reply-To: <5644572F.3080203@baggins.org> To: Matt Caswell Date: Thu, 12 Nov 2015 15:51:56 +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: <20151112145156.182151A368@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Application data during renegotiation handshake 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, 12 Nov 2015 14:52:00 -0000 Matt Caswell wrote: > > > On 12/11/15 08:23, Nikos Mavrogiannopoulos wrote: > > On Wed, 2015-11-11 at 18:39 +0000, Mike Bishop wrote: > > > >> I know that BoringSSL explicitly requires that application data flow > >> be stopped during renegotiation. If the HTTP working group adopts > >> this draft, do the owners of other TLS implementations expect this to > >> require changes in their TLS 1.2 implementations? > > GnuTLS also has this requirement. > > > OpenSSL also does not allow application data during renegotiation. Our implementation also does not allow application data during renegotiation. (But it also has server-side renegotiation completely disabled.) -Martin From nobody Thu Nov 12 07:32: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 24FB61ACEE6 for ; Thu, 12 Nov 2015 07:32:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXIncjHPOicB for ; Thu, 12 Nov 2015 07:32:44 -0800 (PST) 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 B555E1ACEE3 for ; Thu, 12 Nov 2015 07:32:44 -0800 (PST) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 7ED5EA452E for ; Thu, 12 Nov 2015 15:32:44 +0000 (UTC) Received: from dhcp-10-40-2-201.brq.redhat.com (dhcp-10-40-2-201.brq.redhat.com [10.40.2.201]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tACFWgIP013046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 12 Nov 2015 10:32:43 -0500 Message-ID: <1447342361.3315.28.camel@redhat.com> From: Nikos Mavrogiannopoulos To: "tls@ietf.org" Date: Thu, 12 Nov 2015 16:32:41 +0100 In-Reply-To: References: 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.24 Archived-At: Subject: Re: [TLS] Application data during renegotiation handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 15:32:46 -0000 On Wed, 2015-11-11 at 18:39 +0000, Mike Bishop wrote: > A question for TLS implementation owners:  During the discussion of > the TLS 1.2 portion of https://tools.ietf.org/html/draft-thomson-http > 2-client-certs-00, it was pointed out that HTTP/2 breaks a > simplification of the HTTP-TLS interface that some implementations > may have assumed. >   > Since HTTP/1.1 only has one request per connection and that request > is waiting on the client certificate to be retrieved via > renegotiation, you can assume that the client will not send any > application data between the new ClientHello and sending the Finished > message.  (“…it is expected that the negotiation will begin before no > more than a few records are received from the client.â€)  Likewise, > the server will not emit any application data between sending the > HelloRequest and sending its own Finished message.  Since HTTP/2 will > have other requests being generated and served in parallel, this is > no longer the case.  Per the TLS 1.2 spec, that’s permitted, but if > it’s not been done before, I’m afraid we may be hitting less-tested > code paths. We may are also introducing a new attack surface by allowing application data during rehandshake and implementations cache the messages until the handshake is complete. There is an interesting part of the triple handshake attack which can take advantage of applications which cache application data during rehandshake. Quoting: https://www.secure-resumption.com/ "... Consequently, A cannot read or send messages on these connections any more. However, its prior [to rehandshake] messages on both connections may well be prefixed to the messages sent after renegotiation." So an attacker could ensure that his messages are prefixed to the next session if he simply sends his application data during rehandshake. That was not possible with most implementations until now. So we are hitting less-tested protocol paths as well, not only code paths. regards, Nikos From nobody Thu Nov 12 10:06: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 982811B2BF4 for ; Thu, 12 Nov 2015 10:06:29 -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 iApJeJqOSnce for ; Thu, 12 Nov 2015 10:06:28 -0800 (PST) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001: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 DDECC1B2BF0 for ; Thu, 12 Nov 2015 10:06:27 -0800 (PST) Received: by iouu10 with SMTP id u10so65524107iou.0 for ; Thu, 12 Nov 2015 10:06:27 -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=44/pqHaC5gOhzhB03M5KttAM33kKXEMGdMaXojCnSkQ=; b=XqZL1UH/Vfqh0ViMf6FO9XVHd8xHn2oD746F7nfdAXRu+IQOnqlkMaz0vX+Te1cjI2 VHhv0pEvGeK7t+KyPTzD9okteszyL8AS2bc7rVRM2eE3Nf8caf0TK8iwLyGUgwv5eFt3 VvBxfWTULgBDBgE9V3xfzeODREj03OHNpmvJpOGHV8l3StFep6FDiSxeNZLa9o3voCF1 Dqp1XEjBwK2Ll7s/E8QQswTD3ml7RKNwKj9J+OekfyMgsmOMkQnNX1irRvexZijacKXw 24msTW1VjYojA0IjzRrSRWrCuj+Ikit6DTlfKtIHmRGaugM3syn4QeTjnVW/tovFLE7h oGyg== MIME-Version: 1.0 X-Received: by 10.107.33.203 with SMTP id h194mr10323508ioh.108.1447351587208; Thu, 12 Nov 2015 10:06:27 -0800 (PST) Received: by 10.36.155.139 with HTTP; Thu, 12 Nov 2015 10:06:27 -0800 (PST) Date: Thu, 12 Nov 2015 10:06:27 -0800 Message-ID: From: Martin Thomson To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] Review of https://tools.ietf.org/html/draft-ietf-tls-chacha20-poly1305-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 18:06:29 -0000 This is good. I have an editorial comment: can someone please go through and reconcile all the use of bits and bytes throughout. It actually seems like someone did a coin flip on every occurrence to decide which one to use. From nobody Thu Nov 12 10:26: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 31A951B2CBA for ; Thu, 12 Nov 2015 10:26:35 -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 MfybUl8FPho2 for ; Thu, 12 Nov 2015 10:26:33 -0800 (PST) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::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 971BD1B2CB8 for ; Thu, 12 Nov 2015 10:26:33 -0800 (PST) Received: by qkfo3 with SMTP id o3so26213592qkf.1 for ; Thu, 12 Nov 2015 10:26:32 -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=wj73OgROch1Mu4CYf5BXsUspQzwh73oWcohESmLTUDk=; b=r3Tt9RhMAGQGLz/bXX/z/qsnm9YE85nH1Oa8R1rP0H3MVKQbQM4q8vSKoPdOqFDZ5d SeNtRplqi2QRruhH7gU5FT/h+gVu83vV/IKecmTdYQaR3voeIdugzAIiVgTOmRfCYfwP hbIVzBrnN5po/8oIwlAF3wti0Ic8LoQVVBxjuOId+DqYrnAgKZ64W+7PiJXlNRDucxsg j99G8o064cLJPgftVDBIACysxLUwoenhGZ76i412tOtn2EwOuuYuzz7Uu0Y/4fJQ5rVF aM5c81QLVugh6jhW71fefY98AJyvBh3pBOQ59c5BinO65MmOAGUwVOBvwMPsJf3y+f+K Dbkg== MIME-Version: 1.0 X-Received: by 10.55.82.137 with SMTP id g131mr17363329qkb.66.1447352792751; Thu, 12 Nov 2015 10:26:32 -0800 (PST) Sender: alangley@gmail.com Received: by 10.140.97.66 with HTTP; Thu, 12 Nov 2015 10:26:32 -0800 (PST) In-Reply-To: References: Date: Thu, 12 Nov 2015 10:26:32 -0800 X-Google-Sender-Auth: QAMAGNmBDgGFLa3STcQjKj_22Yc Message-ID: From: Adam Langley To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Review of https://tools.ietf.org/html/draft-ietf-tls-chacha20-poly1305-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 18:26:35 -0000 On Thu, Nov 12, 2015 at 10:06 AM, Martin Thomson wrote: > This is good. > > I have an editorial comment: can someone please go through and > reconcile all the use of bits and bytes throughout. It actually seems > like someone did a coin flip on every occurrence to decide which one > to use. -01 already has some cleanups. But there's inevitably going to be some use of both bits and bytes in a draft such as this since keys are generally measured in bits but wire protocols are generally measured in bytes. I looked over each use of "bit" and "byte" in -01 and changed one key length to bits, but otherwise I think each use is about right. Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Thu Nov 12 12:43: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 ED3971B3573 for ; Thu, 12 Nov 2015 12:43:27 -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 uvLGUe_DGrQ7 for ; Thu, 12 Nov 2015 12:43:26 -0800 (PST) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 328771B3595 for ; Thu, 12 Nov 2015 12:43:26 -0800 (PST) Received: by iouu10 with SMTP id u10so70073832iou.0 for ; Thu, 12 Nov 2015 12:43:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=19s38QWgSU/Fwk2GvZaRAVx5trH3/awrfPsxAvyDYLc=; b=cp2+32f6pcqLMa7Ek0qYQDos6PHVtU9CSw49BDZa2fUmagxAFYn5g6irrYlOB2eupa 4zVvPHreV+56hfRxifHXJBjXJIX2FU1Auf/IednLQcupUpDYSd8ajyQ7XlbeEwcg/Smq 6ML78MmfAnWEMpblp1DD5+BWFECRHeF6Ifjoc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=19s38QWgSU/Fwk2GvZaRAVx5trH3/awrfPsxAvyDYLc=; b=e43lho4ULIrrmJPnqPzLdkkKHYujmLIM6WUee27Ql3UWe6rYwwrTq7uEwHqV3QvIyj GNLxmTXM2ZRczrnYjZmVIUMFc0nw5BtF17HeKk3b3qUmNG7UOa94ft6chWisFtwxynV8 HhuP6ejkDnwGso+gv3nrZf5J1zjhrtjGy7IMZEkpDd4NP4xWwZ03rfTNuPCz6zP3lnkG TYRmyAzx5tvDKWLHBH/qE6Zw/pLd9ea04jDDbmwiTO1EEYyRDvUG1OrW9E1Bfjpkrs/K bjewlLbeUSowhwczD9YEmLeVdKb66rN/zT+05V9Jz8ELjY+CBc+Sd5wmb2qr4Sz8GZY6 4/yw== X-Gm-Message-State: ALoCoQmrYvyEoI/nS/2Cw5s0MeGOEaS9M+sb9phGWrdP9rt/MDE7bs0iYwxpHgvQOOjRCHxbofyy X-Received: by 10.107.44.210 with SMTP id s201mr20113042ios.62.1447361005518; Thu, 12 Nov 2015 12:43:25 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Thu, 12 Nov 2015 20:43:15 +0000 Message-ID: To: Yoav Nir , Adam Langley Content-Type: multipart/alternative; boundary=001a113978f298d2b005245dfe64 Archived-At: Cc: Mike Bishop , "tls@ietf.org" Subject: Re: [TLS] Application data during renegotiation handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 20:43:28 -0000 --001a113978f298d2b005245dfe64 Content-Type: text/plain; charset=UTF-8 On Wed, Nov 11, 2015 at 10:43 PM Yoav Nir wrote: > > > On 12 Nov 2015, at 3:32 AM, Adam Langley wrote: > > > > The TLS 1.3 post-handshake client-auth was intended, as I recall, to > > support HTTP/1.1 over TLS 1.3. > > No, it was (and is) presented as a way to do client certificate > authentication with HTTP/2 not at the initial handshake. > > > With HTTP/2 isn't it cleaner to do client-auth at the HTTP layer (i.e. > > by signing exporter values)? > > It is. I thought that an HTTP authentication method based on certificates > could be a drop-in replacement for TLS layer authentication, but someone (I > think it was Mike) pointed out that with TLS-layer certificate > authentication the stream continues after the authentication, while with > HTTP-layer authentication, the stream ends with a 401 status code, and the > client has to start a new stream with the Authorization header. So > applications would need to be changed for this to work. > Using existing HTTP semantics would certainly be cleaner in a vacuum, but one could still do it in HTTP/2 layer without creating a new stream. Perhaps adapt SPDY's CREDENTIAL frame and add a new SWITCH_CREDENTIAL frame to swap a stream's credential slot mid-stream? Alternatively, HTTP/2 frontend could make the application think there were two independent requests. Am I misunderstanding the objection? What about this: 1. Client hits HTTP/2 frontend. Frontend talks to application which decides it needs client auth, expecting it on the same stream. 2. Frontend immediately aborts that request and returns a 401 to the client. Application thinks the client just gave up. 3. Client makes a new stream, now authenticated. The frontend hits the application fresh. Application requests client auth as before and frontend responds immediately with the certificate the client asserted. This is, by the way, how Chrome implements client auth today, even with renego. We never reconfigure client auth mid-stream. I think it would be helpful to have examples of exactly what the applications look like, to know what constraints the various interested parties are working with. For example, Apache httpd has some high-level configuration file. https://httpd.apache.org/docs/2.2/ssl/ssl_howto.html#arbitraryclients Existing Apache installs can easily compatibility regardless of how the HTTP/TLS interaction looks. On the other extreme, if the goal is to keep Apache httpd unchanged while only changing OpenSSL, then we have a very different picture because the OpenSSL API is SSL_renegotiate/SSL_do_handshake (send a HelloRequest) + SSL_set_state/SSL_do_handshake (don't continue until renego completes). That one is quite overfit to the old flow and will be difficult to reconcile with almost anything. draft-thomson-http2-client-certs-00's HTTP/2 mode seems to be targeting something in between. It's okay with adding a new application_context_id, but the client certificate still needs to be asserted at the transport. I'm having a hard time divining the constraints from this. David --001a113978f298d2b005245dfe64 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Nov 11= , 2015 at 10:43 PM Yoav Nir <ynir= .ietf@gmail.com> wrote:

> On 12 Nov 2015, at 3:32 AM, Adam Langley <agl@imperialviolet.org> wrote: >
> The TLS 1.3 post-handshake client-auth was intended, as I recall, to > support HTTP/1.1 over TLS 1.3.

No, it was (and is) presented as a way to do client certificate authenticat= ion with HTTP/2 not at the initial handshake.

> With HTTP/2 isn't it cleaner to do client-auth at the HTTP layer (= i.e.
> by signing exporter values)?

It is. I thought that an HTTP authentication method based on certificates c= ould be a drop-in replacement for TLS layer authentication, but someone (I = think it was Mike) pointed out that with TLS-layer certificate authenticati= on the stream continues after the authentication, while with HTTP-layer aut= hentication, the stream ends with a 401 status code, and the client has to = start a new stream with the Authorization header. So applications would nee= d to be changed for this to work.

Using= existing HTTP semantics would certainly be cleaner in a vacuum, but one co= uld still do it in HTTP/2 layer without creating a new stream. Perhaps adap= t SPDY's CREDENTIAL frame and add a new SWITCH_CREDENTIAL frame to swap= a stream's credential slot mid-stream?

Altern= atively, HTTP/2 frontend could make the application think there were two in= dependent requests. Am I misunderstanding the objection? What about this:
1. Client hits HTTP/2 frontend. Frontend talks to application whic= h decides it needs client auth, expecting it on the same stream.
= 2. Frontend immediately aborts that request and returns a 401 to the client= . Application thinks the client just gave up.
3. Client makes a n= ew stream, now authenticated. The frontend hits the application fresh. Appl= ication requests client auth as before and frontend responds immediately wi= th the certificate the client asserted.
This is, by the way, how = Chrome implements client auth today, even with renego. We never reconfigure= client auth mid-stream.

I think it would be helpf= ul to have examples of exactly what the applications look like, to know wha= t constraints the various interested parties are working with.
For example, Apache httpd has some high-level configuration fi= le.
Existing Apache installs can easil= y compatibility regardless of how the HTTP/TLS interaction looks.

On the other extreme, if the goal is to keep Apache httpd u= nchanged while only changing OpenSSL, then we have a very different picture= because the OpenSSL API is SSL_renegotiate/SSL_do_handshake (send a HelloR= equest)=C2=A0+ SSL_set_state/SSL_do_handshake (don't continue until ren= ego completes). That one is quite overfit to the old flow and will be diffi= cult to reconcile with almost anything.

draft-thom= son-http2-client-certs-00's HTTP/2 mode seems to be targeting something= in between. It's okay with adding a new application_context_id, but th= e client certificate still needs to be asserted at the transport. I'm h= aving a hard time divining the constraints from this.

<= div>David
--001a113978f298d2b005245dfe64-- From nobody Thu Nov 12 16:21: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 2B22A1A8A9C for ; Thu, 12 Nov 2015 16:21:18 -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 PqpiHDnzu5Fb for ; Thu, 12 Nov 2015 16:21:15 -0800 (PST) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::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 977891A8A97 for ; Thu, 12 Nov 2015 16:21:15 -0800 (PST) Received: by qkao63 with SMTP id o63so32505246qka.2 for ; Thu, 12 Nov 2015 16:21:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=fnB45O6ye3tXt6bSr5NLN6am6ktW70hnowbl9xoqQ8o=; b=jT5X7m3gE0YyA4ilWNIcLPJUL+NKRV3jKHNF7dfITg6BE9PidUMiWkrrBE0neOkZ9H vuCkSbowFsLHGo370zfCvh61cqaNu6GT2b2CV9AfzZwQk8oUkF2dyrIDbzN1z1N4+dmO NCQ2DLhA2t2Y0CUWxfpk/9eipex6wjQ1ESqEyo+Eb4brsSlVyKhXBWPFrtUUi/NoIbd8 XkNaCO49/6109R1nskh1rReE6ImO3WfO9FT7Vvrt5wQFg4wOREetkGi//i0KeW8E2ylj YFYK9m5Ap3KXy9daB6ErB2TN3kII4uWmcpmWRt7vgGc2nf7RNoe/2MiFWc5uyBz6M9cV mztw== MIME-Version: 1.0 X-Received: by 10.55.31.30 with SMTP id f30mr19397120qkf.5.1447374074776; Thu, 12 Nov 2015 16:21:14 -0800 (PST) Received: by 10.55.42.96 with HTTP; Thu, 12 Nov 2015 16:21:14 -0800 (PST) In-Reply-To: <201511051853.46672.davemgarrett@gmail.com> References: <201511051659.18674.davemgarrett@gmail.com> <20151105220502.GC18315@mournblade.imrryr.org> <201511051853.46672.davemgarrett@gmail.com> Date: Thu, 12 Nov 2015 16:21:14 -0800 Message-ID: From: Martin Thomson To: Dave Garrett Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] SHA-1 patch updated with Russ' suggestion X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 00:21:18 -0000 On 5 November 2015 at 15:53, Dave Garrett wrote: > "Trusted self-signatures SHOULD be validated before adding to a trust sto= re and SHOULD NOT be re-checked at runtime." But we're getting slightly out= of scope here, which is why I'm thinking that elaborating on this topic ex= actly as suggested is not needed in the document. A trust anchor is a container for a public key and maybe some ancillary information. You don't actually need to check the signature because the process by which you determine that the information is correct doesn't depend on the signature. For example, the certificates that are in the Mozilla trust store all rely on the fact that you downloaded a valid version of Firefox and the mechanisms by which we safeguard that process. The signatures on trust anchors could be garbage and everything would still be fine. The intent of the change is to point this out. I'll rebase it and maybe add the pointer Russ provided, then we can double check that it's right. Right now, it's all dependent on other PRs and hard to follow. From nobody Thu Nov 12 16:21: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 5AAE51B3608 for ; Thu, 12 Nov 2015 13:09:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 veDWmk9fLaGf for ; Thu, 12 Nov 2015 13:09:20 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0749.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:749]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 202C31B3607 for ; Thu, 12 Nov 2015 13:09:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=sqgDQUwdUkGIrZKuKmX97S7oe2/Cvng0DmWq1pNL7Q4=; b=ezcm8956lBqjPywrdr9cELhfvJN1Yeg2dHF6pRFi9yZ9f8XIHjgVapDN4l37exYxTssDLx6YpduqmK/bkbf2wYiIbrPqnPYnC/19lGYYr6NAv+EJgsOuAZDQ7ZEf+cYlpzKaTHUK3f8gErD81uyGIW4m01bO74mK0SIeRYPTDB8= Received: from BN3PR03MB1367.namprd03.prod.outlook.com (10.163.34.153) by BN3PR03MB1366.namprd03.prod.outlook.com (10.163.34.152) with Microsoft SMTP Server (TLS) id 15.1.325.17; Thu, 12 Nov 2015 21:08:58 +0000 Received: from BN3PR03MB1367.namprd03.prod.outlook.com ([10.163.34.153]) by BN3PR03MB1367.namprd03.prod.outlook.com ([10.163.34.153]) with mapi id 15.01.0325.003; Thu, 12 Nov 2015 21:08:57 +0000 From: Mike Bishop To: David Benjamin , Yoav Nir , Adam Langley Thread-Topic: [TLS] Application data during renegotiation handshake Thread-Index: AdEcrQnuroKmbT4dRXSQtSnp2IGJXAAPOh2AAAreWIAAHVVLgAAAE5ow Date: Thu, 12 Nov 2015 21:08:57 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com; x-originating-ip: [2001:4898:80e8:6::1f7] x-microsoft-exchange-diagnostics: 1; BN3PR03MB1366; 5:kd+3XRBc65O7hl4gT19qK/o4f7KDP6u+AoxlOELV0oESSUgz6zpkDkTJJup6h8AZi/BZ4Lm/luE6Sq2rDux22F4X86w6MZqhHaXtV69by0UkdzYgnTNOtxvjUM4chRc3EmlGJVlmA9+XbHd1Jt8nkw==; 24:+x/RvmV4ySEDNsa+MvvdQJUFG0IYhpbLeVPAHN09o7+K3B5ok62TwsYPQThWQ93Q+KR6WDeSCDbU75rGpdwe8y9AimXBg6c6zH9NNfRtHMY=; 20:WKdCUW4zxSyP8KeXc7lIhhvWGJ028enkuaOBhuhtvF5CSrNcx0PeiyC9VfPrOv7X/jSbgzUUtkIeVcVZf+xjdQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR03MB1366; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001)(61426024)(61427024); SRVR:BN3PR03MB1366; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB1366; x-forefront-prvs: 07584EDBCD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(24454002)(52034003)(377454003)(189002)(97736004)(15975445007)(87936001)(81156007)(77096005)(102836002)(122556002)(5001770100001)(5003600100002)(86362001)(19617315012)(40100003)(2900100001)(5002640100001)(19609705001)(86612001)(74316001)(19580395003)(19580405001)(2950100001)(5004730100002)(5007970100001)(99286002)(76176999)(189998001)(19300405004)(92566002)(5001920100001)(10090500001)(54356999)(5008740100001)(93886004)(19625215002)(101416001)(106356001)(33656002)(10290500002)(5005710100001)(76576001)(10400500002)(16236675004)(105586002)(5001960100002)(8990500004)(50986999)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR03MB1366; H:BN3PR03MB1367.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR03MB1367EAFDEE6FA4D3433C50CF87120BN3PR03MB1367namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Nov 2015 21:08:57.7841 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB1366 Archived-At: X-Mailman-Approved-At: Thu, 12 Nov 2015 16:21:26 -0800 Cc: "tls@ietf.org" Subject: Re: [TLS] Application data during renegotiation handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 21:09:23 -0000 --_000_BN3PR03MB1367EAFDEE6FA4D3433C50CF87120BN3PR03MB1367namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RG9pbmcgaXQgYXQgdGhlIEhUVFAgbGF5ZXIgKGFzIGFuIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlz bSkgaXMgY2hhbGxlbmdpbmcsIHNpbmNlIGFwcGxpY2F0aW9ucyBhcmVu4oCZdCBleHBlY3Rpbmcg dG8gcmVjZWl2ZSBpdCB0aGF0IHdheSwgYW5kIG1vdmVzIHRoZSBhdXRoZW50aWNhdGVkIGV4Y2hh bmdlIG9udG8gYSBkaWZmZXJlbnQgc3RyZWFtIHRoYW4gdHJpZ2dlcmVkIGl0LiAgSSBrbm93IHRo YXQgdGhlcmXigJlzIHRoZSBwb3NzaWJpbGl0eSBmb3IgYSBsYXllciB0byBmYWtlIHRoZSBjbGll bnQgZ29pbmcgYXdheSB3aGlsZSBhY3R1YWxseSBzZW5kaW5nIGEgNDAxLCBidXQgdGhlbiB5b3Ug aGF2ZSB0byBiZSBhYmxlIHRvIHRpZSB0aGUgY2xpZW504oCZcyBzZWNvbmQgYXR0ZW1wdCBiYWNr IHRvIHRoZSBjaGFsbGVuZ2UsIGRvbuKAmXQgeW91Pw0KDQpXaGVuIEkgc2F5IOKAnGFwcGxpY2F0 aW9uLOKAnSBJIG1lYW4gdGhlIGNvZGUgYmVpbmcgaG9zdGVkIGJ5IHRoZSB3ZWIgc2VydmVyIHRo YXTigJlzIGFjdHVhbGx5IHJlc3BvbmRpbmcgdG8gdGhlIGludGVycHJldGVkIHJlcXVlc3RzLiAg V2hpbGUgSeKAmWQgbGlrZSB0byBtaW5pbWl6ZSBjb2RlIGNoYW5nZXMgaW4gdGhlIEhUVFAgc2Vy dmVyLCBteSBwcmltYXJ5IGNvbnN0cmFpbnQgaXMgdGhhdCBJIGRvbuKAmXQgY2hhbmdlIHRoZSBh cHBsaWNhdGlvbiB0aGV54oCZcmUgaG9zdGluZyBhdCBhbGwuICBUaGUgY2hhbmdlIHRvIEhUVFAv MiBhbmQvb3IgVExTIDEuMyBzaG91bGQgYmUgYXMgdHJhbnNwYXJlbnQgYXMgcG9zc2libGUuICBL ZWVwaW5nIGF1dGggdGhhdOKAmXMgY3VycmVudGx5IGRvbmUgdmlhIFRMUyBzdGlsbCBpbiBUTFMg aGVscHMgdG8gcmVkdWNlIHRob3NlIGNoYW5nZXMgYXQgaGlnaGVyIGxheWVycy4NCg0KSW4gdGhl IEh0dHBCaXMgd29ya2luZyBncm91cCBtZWV0aW5nLCB0aGVyZSB3YXMgZmFpcmx5IHN0cm9uZyBj b25zZW5zdXMgdGhhdCB3ZSBuZWVkZWQgYSBiYWNrd2FyZC1jb21wYXRpYmlsaXR5IG1lY2hhbmlz bSBmb3IgZXhpc3RpbmcgYXBwcyBtb3ZpbmcgdG8gSFRUUC8yIG92ZXIgVExTIDEuWzIzXTsgdGhl cmUgd2FzIGFsc28gaW50ZXJlc3QgaW4gZGVmaW5pbmcgc29tZXRoaW5nIGNsZWFuZXIgaW4gdGhl IGZ1dHVyZSBmb3IgbmV3IGFwcHMgdGhhdCBjb3VsZCBhZG9wdCBzb21ldGhpbmcgYnJhbmQgbmV3 LCBidXQgbm90IGF0IHRoZSBleHBlbnNlIG9mIHF1aWNrbHkgZW5hYmxpbmcgY3VycmVudCBhcHBz IHRvIGtlZXAgd29ya2luZy4gIFRoZSBkcmFmdCBiZWxvdyBpcyB0aGUgY3VycmVudCBjYW5kaWRh dGUgZm9yIGxlYXN0LXVnbHkgY29tcGF0IHNvbHV0aW9uLiAgRG9pbmcgaXQgYXQgdGhlIGZyYW1p bmcgbGF5ZXIgaXMgZGVmaW5pdGVseSBhIGdvb2Qgb3B0aW9uIGZvciB0aGUgc29tZXRoaW5nIGNs ZWFuZXIuDQoNCkZyb206IERhdmlkIEJlbmphbWluIFttYWlsdG86ZGF2aWRiZW5AY2hyb21pdW0u b3JnXQ0KU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDEyLCAyMDE1IDEyOjQzIFBNDQpUbzogWW9h diBOaXIgPHluaXIuaWV0ZkBnbWFpbC5jb20+OyBBZGFtIExhbmdsZXkgPGFnbEBpbXBlcmlhbHZp b2xldC5vcmc+DQpDYzogTWlrZSBCaXNob3AgPE1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20+ OyB0bHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbVExTXSBBcHBsaWNhdGlvbiBkYXRhIGR1cmlu ZyByZW5lZ290aWF0aW9uIGhhbmRzaGFrZQ0KDQpPbiBXZWQsIE5vdiAxMSwgMjAxNSBhdCAxMDo0 MyBQTSBZb2F2IE5pciA8eW5pci5pZXRmQGdtYWlsLmNvbTxtYWlsdG86eW5pci5pZXRmQGdtYWls LmNvbT4+IHdyb3RlOg0KDQo+IE9uIDEyIE5vdiAyMDE1LCBhdCAzOjMyIEFNLCBBZGFtIExhbmds ZXkgPGFnbEBpbXBlcmlhbHZpb2xldC5vcmc8bWFpbHRvOmFnbEBpbXBlcmlhbHZpb2xldC5vcmc+ PiB3cm90ZToNCj4NCj4gVGhlIFRMUyAxLjMgcG9zdC1oYW5kc2hha2UgY2xpZW50LWF1dGggd2Fz IGludGVuZGVkLCBhcyBJIHJlY2FsbCwgdG8NCj4gc3VwcG9ydCBIVFRQLzEuMSBvdmVyIFRMUyAx LjMuDQoNCk5vLCBpdCB3YXMgKGFuZCBpcykgcHJlc2VudGVkIGFzIGEgd2F5IHRvIGRvIGNsaWVu dCBjZXJ0aWZpY2F0ZSBhdXRoZW50aWNhdGlvbiB3aXRoIEhUVFAvMiBub3QgYXQgdGhlIGluaXRp YWwgaGFuZHNoYWtlLg0KDQo+IFdpdGggSFRUUC8yIGlzbid0IGl0IGNsZWFuZXIgdG8gZG8gY2xp ZW50LWF1dGggYXQgdGhlIEhUVFAgbGF5ZXIgKGkuZS4NCj4gYnkgc2lnbmluZyBleHBvcnRlciB2 YWx1ZXMpPw0KDQpJdCBpcy4gSSB0aG91Z2h0IHRoYXQgYW4gSFRUUCBhdXRoZW50aWNhdGlvbiBt ZXRob2QgYmFzZWQgb24gY2VydGlmaWNhdGVzIGNvdWxkIGJlIGEgZHJvcC1pbiByZXBsYWNlbWVu dCBmb3IgVExTIGxheWVyIGF1dGhlbnRpY2F0aW9uLCBidXQgc29tZW9uZSAoSSB0aGluayBpdCB3 YXMgTWlrZSkgcG9pbnRlZCBvdXQgdGhhdCB3aXRoIFRMUy1sYXllciBjZXJ0aWZpY2F0ZSBhdXRo ZW50aWNhdGlvbiB0aGUgc3RyZWFtIGNvbnRpbnVlcyBhZnRlciB0aGUgYXV0aGVudGljYXRpb24s IHdoaWxlIHdpdGggSFRUUC1sYXllciBhdXRoZW50aWNhdGlvbiwgdGhlIHN0cmVhbSBlbmRzIHdp dGggYSA0MDEgc3RhdHVzIGNvZGUsIGFuZCB0aGUgY2xpZW50IGhhcyB0byBzdGFydCBhIG5ldyBz dHJlYW0gd2l0aCB0aGUgQXV0aG9yaXphdGlvbiBoZWFkZXIuIFNvIGFwcGxpY2F0aW9ucyB3b3Vs ZCBuZWVkIHRvIGJlIGNoYW5nZWQgZm9yIHRoaXMgdG8gd29yay4NCg0KVXNpbmcgZXhpc3Rpbmcg SFRUUCBzZW1hbnRpY3Mgd291bGQgY2VydGFpbmx5IGJlIGNsZWFuZXIgaW4gYSB2YWN1dW0sIGJ1 dCBvbmUgY291bGQgc3RpbGwgZG8gaXQgaW4gSFRUUC8yIGxheWVyIHdpdGhvdXQgY3JlYXRpbmcg YSBuZXcgc3RyZWFtLiBQZXJoYXBzIGFkYXB0IFNQRFkncyBDUkVERU5USUFMIGZyYW1lIGFuZCBh ZGQgYSBuZXcgU1dJVENIX0NSRURFTlRJQUwgZnJhbWUgdG8gc3dhcCBhIHN0cmVhbSdzIGNyZWRl bnRpYWwgc2xvdCBtaWQtc3RyZWFtPw0KDQpBbHRlcm5hdGl2ZWx5LCBIVFRQLzIgZnJvbnRlbmQg Y291bGQgbWFrZSB0aGUgYXBwbGljYXRpb24gdGhpbmsgdGhlcmUgd2VyZSB0d28gaW5kZXBlbmRl bnQgcmVxdWVzdHMuIEFtIEkgbWlzdW5kZXJzdGFuZGluZyB0aGUgb2JqZWN0aW9uPyBXaGF0IGFi b3V0IHRoaXM6DQoxLiBDbGllbnQgaGl0cyBIVFRQLzIgZnJvbnRlbmQuIEZyb250ZW5kIHRhbGtz IHRvIGFwcGxpY2F0aW9uIHdoaWNoIGRlY2lkZXMgaXQgbmVlZHMgY2xpZW50IGF1dGgsIGV4cGVj dGluZyBpdCBvbiB0aGUgc2FtZSBzdHJlYW0uDQoyLiBGcm9udGVuZCBpbW1lZGlhdGVseSBhYm9y dHMgdGhhdCByZXF1ZXN0IGFuZCByZXR1cm5zIGEgNDAxIHRvIHRoZSBjbGllbnQuIEFwcGxpY2F0 aW9uIHRoaW5rcyB0aGUgY2xpZW50IGp1c3QgZ2F2ZSB1cC4NCjMuIENsaWVudCBtYWtlcyBhIG5l dyBzdHJlYW0sIG5vdyBhdXRoZW50aWNhdGVkLiBUaGUgZnJvbnRlbmQgaGl0cyB0aGUgYXBwbGlj YXRpb24gZnJlc2guIEFwcGxpY2F0aW9uIHJlcXVlc3RzIGNsaWVudCBhdXRoIGFzIGJlZm9yZSBh bmQgZnJvbnRlbmQgcmVzcG9uZHMgaW1tZWRpYXRlbHkgd2l0aCB0aGUgY2VydGlmaWNhdGUgdGhl IGNsaWVudCBhc3NlcnRlZC4NClRoaXMgaXMsIGJ5IHRoZSB3YXksIGhvdyBDaHJvbWUgaW1wbGVt ZW50cyBjbGllbnQgYXV0aCB0b2RheSwgZXZlbiB3aXRoIHJlbmVnby4gV2UgbmV2ZXIgcmVjb25m aWd1cmUgY2xpZW50IGF1dGggbWlkLXN0cmVhbS4NCg0KSSB0aGluayBpdCB3b3VsZCBiZSBoZWxw ZnVsIHRvIGhhdmUgZXhhbXBsZXMgb2YgZXhhY3RseSB3aGF0IHRoZSBhcHBsaWNhdGlvbnMgbG9v ayBsaWtlLCB0byBrbm93IHdoYXQgY29uc3RyYWludHMgdGhlIHZhcmlvdXMgaW50ZXJlc3RlZCBw YXJ0aWVzIGFyZSB3b3JraW5nIHdpdGguDQoNCkZvciBleGFtcGxlLCBBcGFjaGUgaHR0cGQgaGFz IHNvbWUgaGlnaC1sZXZlbCBjb25maWd1cmF0aW9uIGZpbGUuDQpodHRwczovL2h0dHBkLmFwYWNo ZS5vcmcvZG9jcy8yLjIvc3NsL3NzbF9ob3d0by5odG1sI2FyYml0cmFyeWNsaWVudHMNCkV4aXN0 aW5nIEFwYWNoZSBpbnN0YWxscyBjYW4gZWFzaWx5IGNvbXBhdGliaWxpdHkgcmVnYXJkbGVzcyBv ZiBob3cgdGhlIEhUVFAvVExTIGludGVyYWN0aW9uIGxvb2tzLg0KDQpPbiB0aGUgb3RoZXIgZXh0 cmVtZSwgaWYgdGhlIGdvYWwgaXMgdG8ga2VlcCBBcGFjaGUgaHR0cGQgdW5jaGFuZ2VkIHdoaWxl IG9ubHkgY2hhbmdpbmcgT3BlblNTTCwgdGhlbiB3ZSBoYXZlIGEgdmVyeSBkaWZmZXJlbnQgcGlj dHVyZSBiZWNhdXNlIHRoZSBPcGVuU1NMIEFQSSBpcyBTU0xfcmVuZWdvdGlhdGUvU1NMX2RvX2hh bmRzaGFrZSAoc2VuZCBhIEhlbGxvUmVxdWVzdCkgKyBTU0xfc2V0X3N0YXRlL1NTTF9kb19oYW5k c2hha2UgKGRvbid0IGNvbnRpbnVlIHVudGlsIHJlbmVnbyBjb21wbGV0ZXMpLiBUaGF0IG9uZSBp cyBxdWl0ZSBvdmVyZml0IHRvIHRoZSBvbGQgZmxvdyBhbmQgd2lsbCBiZSBkaWZmaWN1bHQgdG8g cmVjb25jaWxlIHdpdGggYWxtb3N0IGFueXRoaW5nLg0KDQpkcmFmdC10aG9tc29uLWh0dHAyLWNs aWVudC1jZXJ0cy0wMCdzIEhUVFAvMiBtb2RlIHNlZW1zIHRvIGJlIHRhcmdldGluZyBzb21ldGhp bmcgaW4gYmV0d2Vlbi4gSXQncyBva2F5IHdpdGggYWRkaW5nIGEgbmV3IGFwcGxpY2F0aW9uX2Nv bnRleHRfaWQsIGJ1dCB0aGUgY2xpZW50IGNlcnRpZmljYXRlIHN0aWxsIG5lZWRzIHRvIGJlIGFz c2VydGVkIGF0IHRoZSB0cmFuc3BvcnQuIEknbSBoYXZpbmcgYSBoYXJkIHRpbWUgZGl2aW5pbmcg dGhlIGNvbnN0cmFpbnRzIGZyb20gdGhpcy4NCg0KRGF2aWQNCg== --_000_BN3PR03MB1367EAFDEE6FA4D3433C50CF87120BN3PR03MB1367namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkRvaW5nIGl0IGF0IHRoZSBIVFRQIGxheWVyIChhcyBh biBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc20pIGlzIGNoYWxsZW5naW5nLCBzaW5jZSBhcHBsaWNh dGlvbnMgYXJlbuKAmXQgZXhwZWN0aW5nIHRvIHJlY2VpdmUgaXQgdGhhdCB3YXksIGFuZCBtb3Zl cyB0aGUgYXV0aGVudGljYXRlZA0KIGV4Y2hhbmdlIG9udG8gYSBkaWZmZXJlbnQgc3RyZWFtIHRo YW4gdHJpZ2dlcmVkIGl0LiZuYnNwOyBJIGtub3cgdGhhdCB0aGVyZeKAmXMgdGhlIHBvc3NpYmls aXR5IGZvciBhIGxheWVyIHRvIGZha2UgdGhlIGNsaWVudCBnb2luZyBhd2F5IHdoaWxlIGFjdHVh bGx5IHNlbmRpbmcgYSA0MDEsIGJ1dCB0aGVuIHlvdSBoYXZlIHRvIGJlIGFibGUgdG8gdGllIHRo ZSBjbGllbnTigJlzIHNlY29uZCBhdHRlbXB0IGJhY2sgdG8gdGhlIGNoYWxsZW5nZSwgZG9u4oCZ dCB5b3U/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5XaGVuIEkg c2F5IOKAnGFwcGxpY2F0aW9uLOKAnSBJIG1lYW4gdGhlIGNvZGUgYmVpbmcgaG9zdGVkIGJ5IHRo ZSB3ZWIgc2VydmVyIHRoYXTigJlzIGFjdHVhbGx5IHJlc3BvbmRpbmcgdG8gdGhlIGludGVycHJl dGVkIHJlcXVlc3RzLiZuYnNwOyBXaGlsZSBJ4oCZZCBsaWtlIHRvIG1pbmltaXplIGNvZGUNCiBj aGFuZ2VzIGluIHRoZSBIVFRQIHNlcnZlciwgbXkgcHJpbWFyeSBjb25zdHJhaW50IGlzIHRoYXQg SSBkb27igJl0IGNoYW5nZSB0aGUgYXBwbGljYXRpb24gdGhleeKAmXJlIGhvc3RpbmcgYXQgYWxs LiZuYnNwOyBUaGUgY2hhbmdlIHRvIEhUVFAvMiBhbmQvb3IgVExTIDEuMyBzaG91bGQgYmUgYXMg dHJhbnNwYXJlbnQgYXMgcG9zc2libGUuJm5ic3A7IEtlZXBpbmcgYXV0aCB0aGF04oCZcyBjdXJy ZW50bHkgZG9uZSB2aWEgVExTIHN0aWxsIGluIFRMUyBoZWxwcyB0byByZWR1Y2UNCiB0aG9zZSBj aGFuZ2VzIGF0IGhpZ2hlciBsYXllcnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5JbiB0aGUgSHR0cEJpcyB3b3JraW5nIGdyb3VwIG1lZXRpbmcsIHRoZXJlIHdh cyBmYWlybHkgc3Ryb25nIGNvbnNlbnN1cyB0aGF0IHdlIG5lZWRlZCBhIGJhY2t3YXJkLWNvbXBh dGliaWxpdHkgbWVjaGFuaXNtIGZvciBleGlzdGluZyBhcHBzIG1vdmluZyB0byBIVFRQLzIgb3Zl cg0KIFRMUyAxLlsyM107IHRoZXJlIHdhcyBhbHNvIGludGVyZXN0IGluIGRlZmluaW5nIHNvbWV0 aGluZyBjbGVhbmVyIGluIHRoZSBmdXR1cmUgZm9yIG5ldyBhcHBzIHRoYXQgY291bGQgYWRvcHQg c29tZXRoaW5nIGJyYW5kIG5ldywgYnV0IG5vdCBhdCB0aGUgZXhwZW5zZSBvZiBxdWlja2x5IGVu YWJsaW5nIGN1cnJlbnQgYXBwcyB0byBrZWVwIHdvcmtpbmcuJm5ic3A7IFRoZSBkcmFmdCBiZWxv dyBpcyB0aGUgY3VycmVudCBjYW5kaWRhdGUgZm9yIGxlYXN0LXVnbHkNCiBjb21wYXQgc29sdXRp b24uJm5ic3A7IERvaW5nIGl0IGF0IHRoZSBmcmFtaW5nIGxheWVyIGlzIGRlZmluaXRlbHkgYSBn b29kIG9wdGlvbiBmb3IgdGhlIHNvbWV0aGluZyBjbGVhbmVyLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBEYXZpZCBCZW5q YW1pbiBbbWFpbHRvOmRhdmlkYmVuQGNocm9taXVtLm9yZ10NCjxicj4NCjxiPlNlbnQ6PC9iPiBU aHVyc2RheSwgTm92ZW1iZXIgMTIsIDIwMTUgMTI6NDMgUE08YnI+DQo8Yj5Ubzo8L2I+IFlvYXYg TmlyICZsdDt5bmlyLmlldGZAZ21haWwuY29tJmd0OzsgQWRhbSBMYW5nbGV5ICZsdDthZ2xAaW1w ZXJpYWx2aW9sZXQub3JnJmd0Ozxicj4NCjxiPkNjOjwvYj4gTWlrZSBCaXNob3AgJmx0O01pY2hh ZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20mZ3Q7OyB0bHNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFtUTFNdIEFwcGxpY2F0aW9uIGRhdGEgZHVyaW5nIHJlbmVnb3RpYXRpb24gaGFu ZHNoYWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PbiBXZWQsIE5vdiAxMSwgMjAxNSBhdCAxMDo0MyBQTSBZb2F2IE5pciAmbHQ7PGEgaHJlZj0i bWFpbHRvOnluaXIuaWV0ZkBnbWFpbC5jb20iPnluaXIuaWV0ZkBnbWFpbC5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxicj4NCiZndDsgT24gMTIgTm92IDIwMTUsIGF0IDM6MzIgQU0sIEFkYW0gTGFuZ2xl eSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFnbEBpbXBlcmlhbHZpb2xldC5vcmciIHRhcmdldD0iX2Js YW5rIj5hZ2xAaW1wZXJpYWx2aW9sZXQub3JnPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0Ozxicj4N CiZndDsgVGhlIFRMUyAxLjMgcG9zdC1oYW5kc2hha2UgY2xpZW50LWF1dGggd2FzIGludGVuZGVk LCBhcyBJIHJlY2FsbCwgdG88YnI+DQomZ3Q7IHN1cHBvcnQgSFRUUC8xLjEgb3ZlciBUTFMgMS4z Ljxicj4NCjxicj4NCk5vLCBpdCB3YXMgKGFuZCBpcykgcHJlc2VudGVkIGFzIGEgd2F5IHRvIGRv IGNsaWVudCBjZXJ0aWZpY2F0ZSBhdXRoZW50aWNhdGlvbiB3aXRoIEhUVFAvMiBub3QgYXQgdGhl IGluaXRpYWwgaGFuZHNoYWtlLjxicj4NCjxicj4NCiZndDsgV2l0aCBIVFRQLzIgaXNuJ3QgaXQg Y2xlYW5lciB0byBkbyBjbGllbnQtYXV0aCBhdCB0aGUgSFRUUCBsYXllciAoaS5lLjxicj4NCiZn dDsgYnkgc2lnbmluZyBleHBvcnRlciB2YWx1ZXMpPzxicj4NCjxicj4NCkl0IGlzLiBJIHRob3Vn aHQgdGhhdCBhbiBIVFRQIGF1dGhlbnRpY2F0aW9uIG1ldGhvZCBiYXNlZCBvbiBjZXJ0aWZpY2F0 ZXMgY291bGQgYmUgYSBkcm9wLWluIHJlcGxhY2VtZW50IGZvciBUTFMgbGF5ZXIgYXV0aGVudGlj YXRpb24sIGJ1dCBzb21lb25lIChJIHRoaW5rIGl0IHdhcyBNaWtlKSBwb2ludGVkIG91dCB0aGF0 IHdpdGggVExTLWxheWVyIGNlcnRpZmljYXRlIGF1dGhlbnRpY2F0aW9uIHRoZSBzdHJlYW0gY29u dGludWVzIGFmdGVyIHRoZQ0KIGF1dGhlbnRpY2F0aW9uLCB3aGlsZSB3aXRoIEhUVFAtbGF5ZXIg YXV0aGVudGljYXRpb24sIHRoZSBzdHJlYW0gZW5kcyB3aXRoIGEgNDAxIHN0YXR1cyBjb2RlLCBh bmQgdGhlIGNsaWVudCBoYXMgdG8gc3RhcnQgYSBuZXcgc3RyZWFtIHdpdGggdGhlIEF1dGhvcml6 YXRpb24gaGVhZGVyLiBTbyBhcHBsaWNhdGlvbnMgd291bGQgbmVlZCB0byBiZSBjaGFuZ2VkIGZv ciB0aGlzIHRvIHdvcmsuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5Vc2luZyBleGlzdGluZyBIVFRQIHNlbWFudGljcyB3b3VsZCBj ZXJ0YWlubHkgYmUgY2xlYW5lciBpbiBhIHZhY3V1bSwgYnV0IG9uZSBjb3VsZCBzdGlsbCBkbyBp dCBpbiBIVFRQLzIgbGF5ZXIgd2l0aG91dCBjcmVhdGluZyBhIG5ldyBzdHJlYW0uIFBlcmhhcHMg YWRhcHQgU1BEWSdzIENSRURFTlRJQUwgZnJhbWUgYW5kIGFkZCBhIG5ldyBTV0lUQ0hfQ1JFREVO VElBTCBmcmFtZSB0byBzd2FwIGEgc3RyZWFtJ3MNCiBjcmVkZW50aWFsIHNsb3QgbWlkLXN0cmVh bT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ QWx0ZXJuYXRpdmVseSwgSFRUUC8yIGZyb250ZW5kIGNvdWxkIG1ha2UgdGhlIGFwcGxpY2F0aW9u IHRoaW5rIHRoZXJlIHdlcmUgdHdvIGluZGVwZW5kZW50IHJlcXVlc3RzLiBBbSBJIG1pc3VuZGVy c3RhbmRpbmcgdGhlIG9iamVjdGlvbj8gV2hhdCBhYm91dCB0aGlzOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MS4gQ2xpZW50IGhpdHMgSFRUUC8y IGZyb250ZW5kLiBGcm9udGVuZCB0YWxrcyB0byBhcHBsaWNhdGlvbiB3aGljaCBkZWNpZGVzIGl0 IG5lZWRzIGNsaWVudCBhdXRoLCBleHBlY3RpbmcgaXQgb24gdGhlIHNhbWUgc3RyZWFtLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Mi4gRnJvbnRl bmQgaW1tZWRpYXRlbHkgYWJvcnRzIHRoYXQgcmVxdWVzdCBhbmQgcmV0dXJucyBhIDQwMSB0byB0 aGUgY2xpZW50LiBBcHBsaWNhdGlvbiB0aGlua3MgdGhlIGNsaWVudCBqdXN0IGdhdmUgdXAuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4zLiBDbGll bnQgbWFrZXMgYSBuZXcgc3RyZWFtLCBub3cgYXV0aGVudGljYXRlZC4gVGhlIGZyb250ZW5kIGhp dHMgdGhlIGFwcGxpY2F0aW9uIGZyZXNoLiBBcHBsaWNhdGlvbiByZXF1ZXN0cyBjbGllbnQgYXV0 aCBhcyBiZWZvcmUgYW5kIGZyb250ZW5kIHJlc3BvbmRzIGltbWVkaWF0ZWx5IHdpdGggdGhlIGNl cnRpZmljYXRlIHRoZSBjbGllbnQgYXNzZXJ0ZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGlzLCBieSB0aGUgd2F5LCBob3cgQ2hyb21l IGltcGxlbWVudHMgY2xpZW50IGF1dGggdG9kYXksIGV2ZW4gd2l0aCByZW5lZ28uIFdlIG5ldmVy IHJlY29uZmlndXJlIGNsaWVudCBhdXRoIG1pZC1zdHJlYW0uPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgaXQgd291bGQgYmUgaGVs cGZ1bCB0byBoYXZlIGV4YW1wbGVzIG9mIGV4YWN0bHkgd2hhdCB0aGUgYXBwbGljYXRpb25zIGxv b2sgbGlrZSwgdG8ga25vdyB3aGF0IGNvbnN0cmFpbnRzIHRoZSB2YXJpb3VzIGludGVyZXN0ZWQg cGFydGllcyBhcmUgd29ya2luZyB3aXRoLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb3IgZXhhbXBsZSwgQXBhY2hlIGh0dHBkIGhhcyBzb21l IGhpZ2gtbGV2ZWwgY29uZmlndXJhdGlvbiBmaWxlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vaHR0cGQu YXBhY2hlLm9yZy9kb2NzLzIuMi9zc2wvc3NsX2hvd3RvLmh0bWwjYXJiaXRyYXJ5Y2xpZW50cyI+ aHR0cHM6Ly9odHRwZC5hcGFjaGUub3JnL2RvY3MvMi4yL3NzbC9zc2xfaG93dG8uaHRtbCNhcmJp dHJhcnljbGllbnRzPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5FeGlzdGluZyBBcGFjaGUgaW5zdGFsbHMgY2FuIGVhc2lseSBj b21wYXRpYmlsaXR5IHJlZ2FyZGxlc3Mgb2YgaG93IHRoZSBIVFRQL1RMUyBpbnRlcmFjdGlvbiBs b29rcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gdGhlIG90aGVyIGV4dHJlbWUsIGlmIHRoZSBnb2FsIGlzIHRvIGtlZXAgQXBhY2hlIGh0 dHBkIHVuY2hhbmdlZCB3aGlsZSBvbmx5IGNoYW5naW5nIE9wZW5TU0wsIHRoZW4gd2UgaGF2ZSBh IHZlcnkgZGlmZmVyZW50IHBpY3R1cmUgYmVjYXVzZSB0aGUgT3BlblNTTCBBUEkgaXMgU1NMX3Jl bmVnb3RpYXRlL1NTTF9kb19oYW5kc2hha2UgKHNlbmQgYSBIZWxsb1JlcXVlc3QpJm5ic3A7JiM0 MzsgU1NMX3NldF9zdGF0ZS9TU0xfZG9faGFuZHNoYWtlDQogKGRvbid0IGNvbnRpbnVlIHVudGls IHJlbmVnbyBjb21wbGV0ZXMpLiBUaGF0IG9uZSBpcyBxdWl0ZSBvdmVyZml0IHRvIHRoZSBvbGQg ZmxvdyBhbmQgd2lsbCBiZSBkaWZmaWN1bHQgdG8gcmVjb25jaWxlIHdpdGggYWxtb3N0IGFueXRo aW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5kcmFmdC10aG9tc29uLWh0dHAyLWNsaWVudC1jZXJ0cy0wMCdzIEhUVFAvMiBtb2RlIHNlZW1z IHRvIGJlIHRhcmdldGluZyBzb21ldGhpbmcgaW4gYmV0d2Vlbi4gSXQncyBva2F5IHdpdGggYWRk aW5nIGEgbmV3IGFwcGxpY2F0aW9uX2NvbnRleHRfaWQsIGJ1dCB0aGUgY2xpZW50IGNlcnRpZmlj YXRlIHN0aWxsIG5lZWRzIHRvIGJlIGFzc2VydGVkIGF0IHRoZSB0cmFuc3BvcnQuIEknbSBoYXZp bmcgYSBoYXJkDQogdGltZSBkaXZpbmluZyB0aGUgY29uc3RyYWludHMgZnJvbSB0aGlzLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EYXZpZDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_BN3PR03MB1367EAFDEE6FA4D3433C50CF87120BN3PR03MB1367namp_-- From nobody Fri Nov 13 00:12: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 658CF1A03A6 for ; Fri, 13 Nov 2015 00:12:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-PZ8Txw-iBI for ; Fri, 13 Nov 2015 00:12:49 -0800 (PST) Received: from out4133-146.mail.aliyun.com (out4133-146.mail.aliyun.com [42.120.133.146]) by ietfa.amsl.com (Postfix) with ESMTP id D41F91A039D for ; Fri, 13 Nov 2015 00:12:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1447402366; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; bh=IrTxVT1w0jRUwnu3iHrTr0+0TZGBFDBVMA6srBGEP08=; b=cqhW2JpZ1kRl7vZiFT8dGJU+O2zJeV91EAB7/iOmzDhJqQ0Zow5KyLL+cuy/WEjjR24K1s2Dev8BSbHEIpqZ2L2UXglfZecfk1A956nVo31gQY8uXEYGAnPvFEVKnUw9LT31NW2Zg1hGEm1XIo9ksjl2Ox4pVcYA+08MwcnGr9Q= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R211e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03271; MF=bingzheng.wbz@alibaba-inc.com; NM=1; PH=DW; RN=1; SR=0; Received: from WS-web (bingzheng.wbz@alibaba-inc.com[42.120.74.185]) by e02c03291.eu6 at Fri, 13 Nov 2015 16:12:45 +0800 Date: Fri, 13 Nov 2015 16:12:45 +0800 From: "Bingzheng Wu" To: "tls" Message-ID: <92b759ca-873c-4786-ad88-e199a4dc757e.bingzheng.wbz@alibaba-inc.com> X-Mailer: Alimail-Mailagent revision 2708461 MIME-Version: 1.0 x-aliyun-mail-creator: W4_2708319_IChTW96aWxsYS81LjAgKFdpbmRvd3MgTlQgNi4xOyBXT1c2NCkgQXBwbGVXZWJLaXQvNTM3LjM2IChLSFRNTCwgbGlrZSBHZWNrbykgQ2hyb21lLzQ2LjAuMjQ5MC44NiBTYWZhcmkvNTM3LjM2jM Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [TLS] =?utf-8?q?what=27s_Negotiated_Groups_extension_for=3F?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bingzheng Wu List-Id: "This is the mailing list for 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 Nov 2015 08:12:50 -0000 Hi All,=0A=0AWithout the Negotiated Groups extension,=0A=0ACase 1: if the serv= er accepts the Groups in ClientHello.keyshare, it just use one of the Groups f= or DH, and CertificateVerify for both sides.=0A=0ACase 2: else it responses an= HelloRetryRequest message, which takes *all Groups* that the server supports.= Client picks one and continue.=0A=0AI think Case 1 always happens in real wor= ld, and Negotiated Groups extension is then useless.=0ASo removing it will sim= plify the protocol and save some bytes, without bring any disadvantage.=0A=0AD= o I miss anything? Does this extension exist for compatible with elliptic_curv= es?=0A=0AWu From nobody Fri Nov 13 06:38: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 8DEF21A898C for ; Fri, 13 Nov 2015 06:38:46 -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, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sgdyydp1WR1Q for ; Fri, 13 Nov 2015 06:38:43 -0800 (PST) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 756061A897F for ; Fri, 13 Nov 2015 06:38:43 -0800 (PST) Received: by ykba77 with SMTP id a77so148450816ykb.2 for ; Fri, 13 Nov 2015 06:38:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=TG6bumt/g2APLM+kImTmuYSmExtAMPc1R1lcEklcMBs=; b=Pf+uGukjiZHbE4J8tfBsUNOXtVtuXG6W03pkYrKfOI5fkmJHgiJvxWJF98TwnUiABs zP7IyFL0L3pB6ftAn3LXapS7RwVOhq1WpLXZv4UTG7PYy97Tov5TXWo76qDbqdvyxNDQ GWXbfuy2e06jbCbCpP3qY/WniZo5LR6FVekGNOS2YgOEGyFeY3QiMx6/XLriT4MGIqGm dvz5H9FM7qLkmL9FNCifKLew8wgiPU1HCjm8NoHrLxjlbNNGmyPYImnmG0/9lkPXBE8N 4fHI52ZCaGUd0ZuKNzoN0GcgswnfsmxkcNNRVNG9saJ9RYq6FqgUrDZLdBaOas20LSat VaBg== 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=TG6bumt/g2APLM+kImTmuYSmExtAMPc1R1lcEklcMBs=; b=gCndyYPBppK9NMqSXVOt9qpJEfoWoHPxDi65Ka5WxHVK10iTqKQLJNw/mJ4UntBjc4 9iR9UsBgFZ6tzbVUlfZJYII2hR89Hw8rAezapFPqlcWkR/V4NnwkmPlJEzHJkc7Rfb3+ am1iqknSV8UWCQTWabdxF7vVyA04zDJHtVkxvOY95py+A6rCaRGgYPaomE5P4zc1/quP lk8bg5ojlEi7UclNc6bvULbV6sWPO7pjPS4F+spx0upfMSrMWgZ86D/vqSamr8yMa4Bh lJsgpbBmhGITTgdFMH5MqWQTE7IK9uem4ehfV+YS8YhiN/UcHYiw6s6XweITldOXSzaO hjpg== X-Gm-Message-State: ALoCoQlsfRIw7epoqzyW58krRakiVUidg/gRJoUVtxI0P581b7KWZbqM48XK2mDbZeSZFxTh7MdL X-Received: by 10.129.79.139 with SMTP id d133mr5536377ywb.115.1447425522771; Fri, 13 Nov 2015 06:38:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.221.203 with HTTP; Fri, 13 Nov 2015 06:38:03 -0800 (PST) In-Reply-To: <92b759ca-873c-4786-ad88-e199a4dc757e.bingzheng.wbz@alibaba-inc.com> References: <92b759ca-873c-4786-ad88-e199a4dc757e.bingzheng.wbz@alibaba-inc.com> From: Eric Rescorla Date: Fri, 13 Nov 2015 06:38:03 -0800 Message-ID: To: Bingzheng Wu Content-Type: multipart/alternative; boundary=94eb2c054ad81ff40f05246d048b Archived-At: Cc: tls Subject: Re: [TLS] what's Negotiated Groups extension for? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 14:38:46 -0000 --94eb2c054ad81ff40f05246d048b Content-Type: text/plain; charset=UTF-8 On Fri, Nov 13, 2015 at 12:12 AM, Bingzheng Wu < bingzheng.wbz@alibaba-inc.com> wrote: > Hi All, > > Without the Negotiated Groups extension, > > Case 1: if the server accepts the Groups in ClientHello.keyshare, it just > use one of the Groups for DH, and CertificateVerify for both sides. > > Case 2: else it responses an HelloRetryRequest message, which takes *all > Groups* that the server supports. Client picks one and continue. > No. In case 2, the client indicates the groups it supports and the server tells it which group to use. -Ekr > > I think Case 1 always happens in real world, and Negotiated Groups > extension is then useless. > So removing it will simplify the protocol and save some bytes, without > bring any disadvantage. > > Do I miss anything? Does this extension exist for compatible with > elliptic_curves? > > Wu > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c054ad81ff40f05246d048b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Nov 13, 2015 at 12:12 AM, Bingzheng Wu <bingzheng.= wbz@alibaba-inc.com> wrote:
Hi All,

Without the Negotiated Groups extension,

Case 1: if the server accepts the Groups in ClientHello.keyshare, it just u= se one of the Groups for DH, and CertificateVerify for both sides.

Case 2: else it responses an HelloRetryRequest message, which takes *all Gr= oups* that the server supports. Client picks one and continue.

No. In case 2, the client indicates the groups it s= upports and the server
tells it which group to use.
-Ekr
=C2=A0

I think Case 1 always happens in real world, and Negotiated Groups extensio= n is then useless.
So removing it will simplify the protocol and save some bytes, without brin= g any disadvantage.

Do I miss anything? Does this extension exist for compatible with elliptic_= curves?

Wu

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

--94eb2c054ad81ff40f05246d048b-- From nobody Sat Nov 14 10:14: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 080481A89C6 for ; Sat, 14 Nov 2015 10:14:56 -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 IKWG8gGYD51o for ; Sat, 14 Nov 2015 10:14:55 -0800 (PST) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::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 DFCDD1A8A07 for ; Sat, 14 Nov 2015 10:14:54 -0800 (PST) Received: by qkao63 with SMTP id o63so78218960qka.2 for ; Sat, 14 Nov 2015 10:14:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=Crlf/J2eaVjqJ4cqYPulvS4Rv3suqvgrcCOTqBHJEp0=; b=oKPku1r+co5oNpgk6JO/tpSRX84fRSAsv1MDX0lmZv9tchIXwlaa87dSfg6tFbhzJc BZ9LpEQvcvNbBRO+FXVXUw8negUZ6OxpZOB4Ra1w9xiGZhoU1WMkg6NJTZWwKdkGDmvz ypE/HsRx0knYQ3uw9LjxOlFk9BlcgJh85ozAppb2H04vuFAZtdwPVvrJBD/MmQqzrMx+ /MbVHIcoy1xxF0Y3TmlV2Ej3R0g/P9RO31SguZfU1/fKtKHZlr6oDc1yZFNMFkdmZelH q44izVh8TNKTmsMTZaxMOni7hx1tgMHA7AgHc8G9sIFKa8L1tHvkpz7iJU92D6/PvaLn 0SoQ== MIME-Version: 1.0 X-Received: by 10.140.227.16 with SMTP id x16mr29612574qhb.46.1447524893979; Sat, 14 Nov 2015 10:14:53 -0800 (PST) Sender: alangley@gmail.com Received: by 10.140.97.66 with HTTP; Sat, 14 Nov 2015 10:14:53 -0800 (PST) Date: Sat, 14 Nov 2015 10:14:53 -0800 X-Google-Sender-Auth: -qAtLQOXeMUC81Std_LFLW_lgDM Message-ID: From: Adam Langley To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] Early code point assignment request for curve25519 and curve448 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Nov 2015 18:14:56 -0000 The IESG conflicts review for https://datatracker.ietf.org/doc/draft-irtf-cfrg-curves/ has now completed without issue[1]. The editor's copy of the 1.3 spec contains code points for these curves[2], specifically: // ECDH functions. ecdh_x25519 (29), ecdh_x448 (30), // Signature curves. eddsa_ed25519 (31), eddsa_ed448 (32), I'd like to request that these code points for early assignment. [1] https://mailarchive.ietf.org/arch/msg/ietf-announce/MWmqSxBZxWPEt6glXJZvXg5lMS4 [2] https://tlswg.github.io/tls13-spec/#rfc.section.6.3.2.2 Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Sat Nov 14 10: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 705A91ACE3B for ; Sat, 14 Nov 2015 10:37:02 -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, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNvwhxsCvQfa for ; Sat, 14 Nov 2015 10:37:01 -0800 (PST) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E05721ACE37 for ; Sat, 14 Nov 2015 10:37:00 -0800 (PST) Received: by ykfs79 with SMTP id s79so190453756ykf.1 for ; Sat, 14 Nov 2015 10:37:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Cg7f27TbkHJ1FpdU/aFcbM4pRLqFIU77A26UbecG1wI=; b=Io5oIsLBwkJiA9KyTEHZ1wfRvTrID2XC/f2EQLbe+Uij+MaObEpmgx4Fr28XVL1ng5 u6bsFKpMMtnB2mkNb7M1wigAnbMWY9UUTw9F4TqegwzX9a8usxPPyaINfjUBQPaWg7c5 uC25F/yOVwGxXY6LArTyVShn2Wm9yxhsFoI9YYUq7zbYHbABPXPDGg3ZBerd1fO7SUmB 2X1rRtlcM4V6X+JZkuTRiUOw4ocoiDlHrIHTPtcxHIjra/5oDuowW3yuvNVSnYYK1/Ug wL0DSuewx3927OLMw29aKWwY88Y1M5kX6UEGus4DeCcxRWdRol1BkfqFHvKNnFMyC0sy 8Haw== 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=Cg7f27TbkHJ1FpdU/aFcbM4pRLqFIU77A26UbecG1wI=; b=itF8JI1TLAeeQtcFaEbWXB22Fq383r77X2WGzCY46EyB9fWG0uwBKOgjvoC5JrCPfY lYYl94Ru6yrajUlzID030zwVNvndguZ7MAD4HWSoyM6wfHEefqbJbymATnCFgIX2WyzX h9cLCrfh8PxTmVhP79K47Qvnc7wa1Y55bMcJ+L5kxCUPYxY7sLoN4aLyDHRBtxf78rd0 rxNmX9mjD7P28WoDakL3oTz2jrYUuym/JFvSzq6xN9/l1qYZX5ggbtOKmVSGlk7SlTPy HN6swACVINVgRV+p9tKOLMAccF+Qf2v6cghZQJ0wD0gCvU0JPKaTyPTLx16TY29dEWe8 dqPQ== X-Gm-Message-State: ALoCoQlWAe7l/ZSbxBj9W9ib/UM45NA3xqGkRquJgixl8oOyhLzoWSlDAuiT52rjVEUOo1fztxRc X-Received: by 10.129.73.145 with SMTP id w139mr16050007ywa.223.1447526220133; Sat, 14 Nov 2015 10:37:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.221.203 with HTTP; Sat, 14 Nov 2015 10:36:20 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Sat, 14 Nov 2015 10:36:20 -0800 Message-ID: To: Adam Langley Content-Type: multipart/alternative; boundary=001a114d736227a8c1052484761c Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Early code point assignment request for curve25519 and curve448 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Nov 2015 18:37:02 -0000 --001a114d736227a8c1052484761c Content-Type: text/plain; charset=UTF-8 I support this code point assignment and we should also pull the same code points into RFC 4492-bis. On Sat, Nov 14, 2015 at 10:14 AM, Adam Langley wrote: > The IESG conflicts review for > https://datatracker.ietf.org/doc/draft-irtf-cfrg-curves/ has now > completed without issue[1]. > > The editor's copy of the 1.3 spec contains code points for these > curves[2], specifically: > > // ECDH functions. > ecdh_x25519 (29), ecdh_x448 (30), > > // Signature curves. > eddsa_ed25519 (31), eddsa_ed448 (32), > > I'd like to request that these code points for early assignment. > > [1] > https://mailarchive.ietf.org/arch/msg/ietf-announce/MWmqSxBZxWPEt6glXJZvXg5lMS4 > [2] https://tlswg.github.io/tls13-spec/#rfc.section.6.3.2.2 > > > Cheers > > AGL > > -- > Adam Langley agl@imperialviolet.org https://www.imperialviolet.org > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a114d736227a8c1052484761c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I support this code point assignment and we should also pu= ll the same code points into RFC 4492-bis.
=
On Sat, Nov 14, 2015 at 10:14 AM, Adam Langl= ey <agl@imperialviolet.org> wrote:
The IESG conflicts review for
https://datatracker.ietf.org/doc/draft-irtf-= cfrg-curves/ has now
completed without issue[1].

The editor's copy of the 1.3 spec contains code points for these
curves[2], specifically:

=C2=A0 =C2=A0 =C2=A0 // ECDH functions.
=C2=A0 =C2=A0 =C2=A0 =C2=A0ecdh_x25519 (29), ecdh_x448 (30),

=C2=A0 =C2=A0 =C2=A0 =C2=A0// Signature curves.
=C2=A0 =C2=A0 =C2=A0 =C2=A0eddsa_ed25519 (31), eddsa_ed448 (32),

I'd like to request that these code points for early assignment.

[1] https://mailarchi= ve.ietf.org/arch/msg/ietf-announce/MWmqSxBZxWPEt6glXJZvXg5lMS4
[2] https://tlswg.github.io/tls13-spec/#rfc.s= ection.6.3.2.2


Cheers

AGL

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

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

--001a114d736227a8c1052484761c-- From nobody Sat Nov 14 10: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 40E111ACE49 for ; Sat, 14 Nov 2015 10:40:09 -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 IPI3pxeb80sZ for ; Sat, 14 Nov 2015 10:40:07 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 00EC71ACE47 for ; Sat, 14 Nov 2015 10:40:07 -0800 (PST) Received: by wmww144 with SMTP id w144so65323049wmw.1 for ; Sat, 14 Nov 2015 10:40:05 -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=Kzgv+1IxKXdg/DZCkpvlr0nXTuy5eE3HlifqP0hhsZo=; b=B0eVWIIesuaU24GnmR4YZLtcvg61DEyX7NXUtvVUmU+0Qxf5ljHlXqgaHb/URuPAs7 ua8kPtHjJExxH559pLAYrmuw/0tIrsrBfAZC4u/M9j09JpZ5vL731KkNB942ar4XFDQ9 u54AB1XGlVl2kq5ZRtJG+PjW5RUfR/CusYPyd3Z4Kgw2B9kqU9b0mX3gxbt1GBrU+nHI Ufgrvzy6gsOsvt25E9EMFse638KFJEbQ/+67LJn4uR3vLZmDLXDkD9b4U0NzmugU5ItD 5fl0g0CUd0Ux1SWDhfM7/JUVjx5EqIzapCkzG9oQIRhhWKRGk1R8H+VcoofhgY6oxh8U Yqxg== X-Received: by 10.194.5.2 with SMTP id o2mr27913973wjo.98.1447526405548; Sat, 14 Nov 2015 10:40:05 -0800 (PST) Received: from [192.168.1.14] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id 197sm9948391wmx.23.2015.11.14.10.40.03 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 14 Nov 2015 10:40:04 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_54FC2FF1-37E1-42A6-85A2-4F6EF392C226" Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Yoav Nir In-Reply-To: Date: Sat, 14 Nov 2015 20:40:01 +0200 Message-Id: References: To: Eric Rescorla X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: Adam Langley , "tls@ietf.org" Subject: Re: [TLS] Early code point assignment request for curve25519 and curve448 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Nov 2015 18:40:09 -0000 --Apple-Mail=_54FC2FF1-37E1-42A6-85A2-4F6EF392C226 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1 The IANA considerations section in the github copy has the same = identifiers. = https://github.com/tlswg/rfc4492bis/blob/master/draft-ietf-tls-rfc4492bis.= xml = Yoav > On 14 Nov 2015, at 8:36 PM, Eric Rescorla wrote: >=20 > I support this code point assignment and we should also pull the same = code points into RFC 4492-bis. >=20 > On Sat, Nov 14, 2015 at 10:14 AM, Adam Langley > wrote: > The IESG conflicts review for > https://datatracker.ietf.org/doc/draft-irtf-cfrg-curves/ = has now > completed without issue[1]. >=20 > The editor's copy of the 1.3 spec contains code points for these > curves[2], specifically: >=20 > // ECDH functions. > ecdh_x25519 (29), ecdh_x448 (30), >=20 > // Signature curves. > eddsa_ed25519 (31), eddsa_ed448 (32), >=20 > I'd like to request that these code points for early assignment. >=20 > [1] = https://mailarchive.ietf.org/arch/msg/ietf-announce/MWmqSxBZxWPEt6glXJZvXg= 5lMS4 = > [2] https://tlswg.github.io/tls13-spec/#rfc.section.6.3.2.2 = >=20 >=20 > Cheers >=20 > AGL >=20 > -- > Adam Langley agl@imperialviolet.org = https://www.imperialviolet.org >=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=_54FC2FF1-37E1-42A6-85A2-4F6EF392C226 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii +1

The = IANA considerations section in the github copy has the same = identifiers.
https://github.com/tlswg/rfc4492bis/blob/master/draft-ietf-tls-= rfc4492bis.xml

Yoav

On 14 Nov 2015, at 8:36 PM, = Eric Rescorla <ekr@rtfm.com> wrote:

I support this code point assignment and we should also pull = the same code points into RFC 4492-bis.

On Sat, = Nov 14, 2015 at 10:14 AM, Adam Langley <agl@imperialviolet.org> wrote:
The IESG conflicts = review for
https://datatracker.ietf.org/doc/draft-irtf-cfrg-curves/ = has now
completed without issue[1].

The editor's copy of the 1.3 spec contains code points for these
curves[2], specifically:

      // ECDH functions.
       ecdh_x25519 (29), ecdh_x448 (30),

       // Signature curves.
       eddsa_ed25519 (31), eddsa_ed448 (32),

I'd like to request that these code points for early assignment.

[1] https://mailarchive.ietf.org/arch/msg/ietf-announce/MWmqSxBZxWP= Et6glXJZvXg5lMS4
[2] https://tlswg.github.io/tls13-spec/#rfc.section.6.3.2.2


Cheers

AGL

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

_______________________________________________
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

= --Apple-Mail=_54FC2FF1-37E1-42A6-85A2-4F6EF392C226-- From nobody Sat Nov 14 10:41: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 12FDC1ACE5E for ; Sat, 14 Nov 2015 10:41:33 -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 FOQVLjMc_drt for ; Sat, 14 Nov 2015 10:41:31 -0800 (PST) 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 D198C1ACE5D for ; Sat, 14 Nov 2015 10:41:31 -0800 (PST) Received: by pabfh17 with SMTP id fh17so132913189pab.0 for ; Sat, 14 Nov 2015 10:41:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Kf+nxyIolZ09klNa5VtXNzC2lSRuHFdHhtq9uUsxxVU=; b=IjeYLu36Wnl/qlmvfcsBSlsEt5rSD0OfZSx2pyAdFyd7+1SAvEPvQLEnp9s1Av6A7+ DTzRdYgj1dLnjuoS2a/SXvax3PFzUyGzeGb5ABLu5BGsY+VbfKuy9ua/fxh9Cxj/dXbE UpXn/MbLYc3vnzVpXBG4AJABEl/IOhbPCUoTpfEivR0dTxXkF8cEVwGC8ss3KlYJY67e WGZ6Nmzo4LSO6QaAKfqrJyONv95gNuKX3xd1LqppCDDGnzWUVuWtjReFxvUbBVHM4R0g G9p7EjHEq6HrCHAGrQnleBKhGI9Har1OdQUnJSGjkhvYKI/SszFBoPps4gKvOCN08DYi SPCQ== MIME-Version: 1.0 X-Received: by 10.67.14.166 with SMTP id fh6mr41971307pad.156.1447526491520; Sat, 14 Nov 2015 10:41:31 -0800 (PST) Received: by 10.66.101.98 with HTTP; Sat, 14 Nov 2015 10:41:31 -0800 (PST) In-Reply-To: References: Date: Sat, 14 Nov 2015 18:41:31 +0000 Message-ID: From: Loganaden Velvindron To: Adam Langley Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Early code point assignment request for curve25519 and curve448 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Nov 2015 18:41:33 -0000 On Sat, Nov 14, 2015 at 6:14 PM, Adam Langley wrote: > The IESG conflicts review for > https://datatracker.ietf.org/doc/draft-irtf-cfrg-curves/ has now > completed without issue[1]. > > The editor's copy of the 1.3 spec contains code points for these > curves[2], specifically: > > // ECDH functions. > ecdh_x25519 (29), ecdh_x448 (30), > > // Signature curves. > eddsa_ed25519 (31), eddsa_ed448 (32), > > I'd like to request that these code points for early assignment. > > [1] https://mailarchive.ietf.org/arch/msg/ietf-announce/MWmqSxBZxWPEt6glXJZvXg5lMS4 > [2] https://tlswg.github.io/tls13-spec/#rfc.section.6.3.2.2 > I support this code point assignment. From nobody Sat Nov 14 10:44: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 7980A1ACE7A for ; Sat, 14 Nov 2015 10:44:22 -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 HMZcocWJhh8l for ; Sat, 14 Nov 2015 10:44:21 -0800 (PST) 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 342561ACE73 for ; Sat, 14 Nov 2015 10:44:21 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3B7B52843A5; Sat, 14 Nov 2015 18:44:20 +0000 (UTC) Date: Sat, 14 Nov 2015 18:44:20 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20151114184419.GY18315@mournblade.imrryr.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Early code point assignment request for curve25519 and curve448 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: Sat, 14 Nov 2015 18:44:22 -0000 On Sat, Nov 14, 2015 at 10:14:53AM -0800, Adam Langley wrote: > The editor's copy of the 1.3 spec contains code points for these > curves[2], specifically: > > // ECDH functions. > ecdh_x25519 (29), ecdh_x448 (30), Thanks, good news. > // Signature curves. > eddsa_ed25519 (31), eddsa_ed448 (32), AFAIK the signature detailes are not pinned down yet. Is this allocation in anticipation of the final details? -- Viktor. From nobody Sat Nov 14 10:47: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 CB5F11ACEB7 for ; Sat, 14 Nov 2015 10:47:11 -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 khYB1_kSIKhN for ; Sat, 14 Nov 2015 10:47:10 -0800 (PST) Received: from filtteri5.pp.htv.fi (filtteri5.pp.htv.fi [213.243.153.188]) by ietfa.amsl.com (Postfix) with ESMTP id 155B01ACEB6 for ; Sat, 14 Nov 2015 10:47:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by filtteri5.pp.htv.fi (Postfix) with ESMTP id 76A625A705B; Sat, 14 Nov 2015 20:46:51 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from smtp4.welho.com ([213.243.153.38]) by localhost (filtteri5.pp.htv.fi [213.243.153.188]) (amavisd-new, port 10024) with ESMTP id KtSXf40zSIN2; Sat, 14 Nov 2015 20:46:50 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp4.welho.com (Postfix) with ESMTPSA id 2A4AD5BC010; Sat, 14 Nov 2015 20:47:08 +0200 (EET) Date: Sat, 14 Nov 2015 20:47:03 +0200 From: Ilari Liusvaara To: Adam Langley Message-ID: <20151114184703.GB31954@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Early code point assignment request for curve25519 and curve448 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Nov 2015 18:47:12 -0000 On Sat, Nov 14, 2015 at 10:14:53AM -0800, Adam Langley wrote: > The IESG conflicts review for > https://datatracker.ietf.org/doc/draft-irtf-cfrg-curves/ has now > completed without issue[1]. > > The editor's copy of the 1.3 spec contains code points for these > curves[2], specifically: > > // ECDH functions. > ecdh_x25519 (29), ecdh_x448 (30), > > // Signature curves. > eddsa_ed25519 (31), eddsa_ed448 (32), > > I'd like to request that these code points for early assignment. Nothing against #29 and #30. Those are ready. Regarding #31, one would need to pull eddsa codepoint (5 in TLS 1.3 editor's copy) and presumably fix OIDs 1.3.101.100 and 1.3.101.101 in order to get usable Ed25519 keys in PKIX. Regarding #32, it has all of #31, plus no stable spec (due to missing decision on "hash" to be used). -Ilari From nobody Sat Nov 14 10:47: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 6E2021ACECE for ; Sat, 14 Nov 2015 10:47:41 -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 peSSW_f-fDJ2 for ; Sat, 14 Nov 2015 10:47:39 -0800 (PST) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::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 8A3BF1ACEC7 for ; Sat, 14 Nov 2015 10:47:39 -0800 (PST) Received: by qkfo3 with SMTP id o3so78600533qkf.1 for ; Sat, 14 Nov 2015 10:47:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=WT4Z/DdMkAhRnT9emjE8FGVtFjrd9RHGji3hvhzIOh0=; b=HtDu8fpXZmO61+vhAUVWzadQcg80hnvJgnJVFIcqWxEeOWJ8I3eI2BpDnfgewGCGCg YD1N5KrOQVfzl/d80a9f6Un525On/dTxpy0XmD79ZMBZyw7V45var5wkkYwwdZ25cmWl x8sIZOJwBidQeUZDTRtQPmSkRjcnRJChOxUbOvM+jEh9a4qE3liy0D71GPjr5J5bTe93 JV+vjtOzIUAYDURRWOk/6B/7PUT1WkVwIw/GCHvF6j9y1yBi3pify91lXau6XV4YYI15 RnWABUTJdo8LkoL3ja2TedXZdfib9hdkPyqz29iH+tQwFqRbUpLBidRRrJl//1T+JOCe HQUw== MIME-Version: 1.0 X-Received: by 10.55.71.203 with SMTP id u194mr27268666qka.14.1447526858714; Sat, 14 Nov 2015 10:47:38 -0800 (PST) Sender: alangley@gmail.com Received: by 10.140.97.66 with HTTP; Sat, 14 Nov 2015 10:47:38 -0800 (PST) In-Reply-To: <20151114184419.GY18315@mournblade.imrryr.org> References: <20151114184419.GY18315@mournblade.imrryr.org> Date: Sat, 14 Nov 2015 10:47:38 -0800 X-Google-Sender-Auth: AiNMoPDbJqFXE7OfHKBLACFKJZ8 Message-ID: From: Adam Langley To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [TLS] Early code point assignment request for curve25519 and curve448 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Nov 2015 18:47:41 -0000 On Sat, Nov 14, 2015 at 10:44 AM, Viktor Dukhovni wrote: > AFAIK the signature detailes are not pinned down yet. Is this > allocation in anticipation of the final details? It might well be that the X25519 and X448 code points are suitable for early assignment while the signature code points are not since the signature work in CFRG is ongoing. I'll leave that to the chairs. (While we would use early code-point assignments for X25519/X448 we don't have plans for using the signature code points at this time.) Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Sat Nov 14 11:18: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 F27C81AD1EC for ; Sat, 14 Nov 2015 11:18:33 -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, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JrM5sPX3lIjO for ; Sat, 14 Nov 2015 11:18:32 -0800 (PST) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D7901AD1BA for ; Sat, 14 Nov 2015 11:18:32 -0800 (PST) Received: by ykba77 with SMTP id a77so190045093ykb.2 for ; Sat, 14 Nov 2015 11:18:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=OYFbisd29kebBmz1fXVdacWmTOgcB64YSdl9A2qitPg=; b=A5OFKFQYDWYrD53gSJ+mfEIqLdlsDCG8eKator3axkpmpvdeo4i9bzFUl1P7q4qBl0 gY+30dNqlLScVXchH8G+PPDc6X3jQpn7HsNNPY4n5mOeLZObMQZ/2EVJHSPb5rlrmhIa pnyQl79Q9PmlbX/luZvFeDr34tPS/KHmKwUmg7I5M7+6mK6sXA7potZK9Vol33EQkdwD cwWw/cCsQp+zHPJtR9rO8yjGURattn+NZDWkMkFVzAn0DjTg1BFsbzS6ldAJrsHbmXlt XOD50Oo1g5408gjgtWO4TaOubihFMh/qnNe3hpFlG8cGFJeNi1iBbaXihcGhTVbfAlsc tKSg== 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=OYFbisd29kebBmz1fXVdacWmTOgcB64YSdl9A2qitPg=; b=RwIgP2FM9JbyA9W88FVB5EO2FlGQu3dVxnnO/nPzgVwgN1QSglSUfESbIXNmxapXGU M6V8Chlv1DxzcPtc1eE96oT0hWMHhIXWdAVWzPBqw5R4YHSqt7kSydV9Nr9YYd+5Q+Si S2pGTLiwTrVLypJxJvJg36vcK0AWoKcLBTf8g/BNTLBdx/D6GTrPwXbQuIxp6er6GGrq nP9tVM5PV7Zw4IVJWNd1KSzDv82lJ5y4H63shDGCKKTVIfmhOFQEC/8Ljixfl9lScbxq cyb9NF5vJgUDnsdTV9xoIJHCC6JM5IIYQyhr2Jk0kQo3vhDEfjx14uW117s3JlZgulei SZNw== X-Gm-Message-State: ALoCoQmRhsk/mNwhKJiVjIHd3Qs7OXdiX9KGR6iOuWX0AjR8JkpOODKbFapSsyZOhqovJB9z2XQF X-Received: by 10.13.249.4 with SMTP id j4mr27241385ywf.129.1447528711397; Sat, 14 Nov 2015 11:18:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.221.203 with HTTP; Sat, 14 Nov 2015 11:17:52 -0800 (PST) In-Reply-To: References: <20151114184419.GY18315@mournblade.imrryr.org> From: Eric Rescorla Date: Sat, 14 Nov 2015 11:17:52 -0800 Message-ID: To: Adam Langley Content-Type: multipart/alternative; boundary=94eb2c0826e8a55c030524850ac4 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Early code point assignment request for curve25519 and curve448 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Nov 2015 19:18:34 -0000 --94eb2c0826e8a55c030524850ac4 Content-Type: text/plain; charset=UTF-8 On Sat, Nov 14, 2015 at 10:47 AM, Adam Langley wrote: > On Sat, Nov 14, 2015 at 10:44 AM, Viktor Dukhovni > wrote: > > AFAIK the signature detailes are not pinned down yet. Is this > > allocation in anticipation of the final details? > > It might well be that the X25519 and X448 code points are suitable for > early assignment while the signature code points are not since the > signature work in CFRG is ongoing. I'll leave that to the chairs. > > (While we would use early code-point assignments for X25519/X448 we > don't have plans for using the signature code points at this time. I'm fine either way. As Adam says, it wouldn't be harmful to wait for the signature code point assignments for a bit, but I doubt it would be that harmful not to. People who deploy the signature schemes before they are stable do so at their own risk. Also, that risk seems low since you're not going to have public certificates with these schemes until they are stable. -Ekr > > > Cheers > > AGL > > -- > Adam Langley agl@imperialviolet.org https://www.imperialviolet.org > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c0826e8a55c030524850ac4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Nov 14, 2015 at 10:47 AM, Adam Langley <agl@imperialviole= t.org> wrote:
On Sat, Nov 14, 2015 at 10:44 AM, Viktor Dukhovni
<ietf-dane@dukhovni.org>= ; wrote:
> AFAIK the signature detailes are not pinned down yet.=C2=A0 Is this > allocation in anticipation of the final details?

It might well be that the X25519 and X448 code points are suitable f= or
early assignment while the signature code points are not since the
signature work in CFRG is ongoing. I'll leave that to the chairs.

(While we would use early code-point assignments for X25519/X448 we
don't have plans for using the signature code points at this time.

I'm fine either way. As Adam says, it would= n't be harmful to wait for
the signature code point assignmen= ts for a bit, but I doubt it would
be that harmful not to. People= who deploy the signature schemes
before they are stable do so at= their own risk. Also, that risk seems
low since you're not g= oing to have public certificates with these
schemes until they ar= e stable.

-Ekr
=C2=A0


Cheers

AGL

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

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

--94eb2c0826e8a55c030524850ac4-- From nobody Sat Nov 14 11:47: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 7B52A1B2A45 for ; Sat, 14 Nov 2015 11:47:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXClvOkQzPfJ for ; Sat, 14 Nov 2015 11:47:30 -0800 (PST) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB0271B2A38 for ; Sat, 14 Nov 2015 11:47:29 -0800 (PST) Received: by ykdr82 with SMTP id r82so190819632ykd.3 for ; Sat, 14 Nov 2015 11:47:29 -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=t4q7MNf8bKdenDa232lJ+ewDY6/fyyn1qTMVyMF0ba4=; b=Rw+dOsjqJLEnjA4RyKvzvb5y2I41eMFNzdt/VNfUrsaNCTuCG75IPtD5/g7Ba+DbAc IJf3Pt/hEhWYFZeHfEp1CvNBQLnSRBkqPSUowlliAbgOHaqzpMdWAl8WPDfR1IMfQay1 gu58JSl+/3KE26o2S8sxi6fyiKiqhN38S0Exbcah4+bbwVmiIzhCw+fo9ikAXm7nNwxT zL+tsQuyWJPoRicxkbkqK7cMl928ZeEwV+/XTsFCtR5ONCx2qbvXRZ/8PmkvSg+qSGOd bXLPOOyhm/hWwSjZ2xpZUUalCMNNEJsoi8P90aCqFP0Ha8cTamAGJPETwo2c+LaSLasm VPAA== MIME-Version: 1.0 X-Received: by 10.129.99.195 with SMTP id x186mr26387805ywb.345.1447530449304; Sat, 14 Nov 2015 11:47:29 -0800 (PST) Received: by 10.129.128.199 with HTTP; Sat, 14 Nov 2015 11:47:29 -0800 (PST) Received: by 10.129.128.199 with HTTP; Sat, 14 Nov 2015 11:47:29 -0800 (PST) In-Reply-To: References: <20151114184419.GY18315@mournblade.imrryr.org> Date: Sat, 14 Nov 2015 14:47:29 -0500 Message-ID: From: Deirdre Connolly To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a114920f83b847805248572c6 Archived-At: Cc: Adam Langley , tls@ietf.org Subject: Re: [TLS] Early code point assignment request for curve25519 and curve448 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Nov 2015 19:47:31 -0000 --001a114920f83b847805248572c6 Content-Type: text/plain; charset=UTF-8 On Nov 14, 2015 2:18 PM, "Eric Rescorla" wrote: > I'm fine either way. As Adam says, it wouldn't be harmful to wait for > the signature code point assignments for a bit, but I doubt it would > be that harmful not to. People who deploy the signature schemes > before they are stable do so at their own risk. Also, that risk seems > low since you're not going to have public certificates with these > schemes until they are stable. +1 -DC- --001a114920f83b847805248572c6 Content-Type: text/html; charset=UTF-8

On Nov 14, 2015 2:18 PM, "Eric Rescorla" <ekr@rtfm.com> wrote:
> I'm fine either way. As Adam says, it wouldn't be harmful to wait for
> the signature code point assignments for a bit, but I doubt it would
> be that harmful not to. People who deploy the signature schemes
> before they are stable do so at their own risk. Also, that risk seems
> low since you're not going to have public certificates with these
> schemes until they are stable.

+1

-DC-

--001a114920f83b847805248572c6-- From nobody Sun Nov 15 00:28: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 DBF3E1A912C for ; Sun, 15 Nov 2015 00:28:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2B42dkA9lro for ; Sun, 15 Nov 2015 00:28:26 -0800 (PST) Received: from out4133-82.mail.aliyun.com (out4133-82.mail.aliyun.com [42.120.133.82]) by ietfa.amsl.com (Postfix) with ESMTP id C34821A9129 for ; Sun, 15 Nov 2015 00:28:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1447576103; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; bh=5ZYHJV9/XEU004vmM8F93pIIDYBiioaNOMYR9XrrRhM=; b=EzUYWnk4raaABNE2pHb2jVQNDek4MSGpgPNbKgArIFftgpkqy9rI/uZadxhf+oMpdVMcN/pJ/NpgqbzJh/rg751MGRlCf4z0u1oWa/j89w1oafQKhAQT1Peq1yPdRJ8mW3CHZi/tTWZo6fHWrCmwXoPYNWOu+aaF2Fgeqs/35pM= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R931e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03301; MF=bingzheng.wbz@alibaba-inc.com; NM=1; PH=DW; RN=2; SR=0; Received: from WS-web (bingzheng.wbz@alibaba-inc.com[122.235.84.120]) by e02c03301.eu6 at Sun, 15 Nov 2015 16:28:20 +0800 Date: Sun, 15 Nov 2015 16:28:20 +0800 From: "Bingzheng Wu" To: "Eric Rescorla" Message-ID: <88538417-239c-4dbe-aa17-7b8bce3f88c8.bingzheng.wbz@alibaba-inc.com> X-Mailer: Alimail-Mailagent revision 2708461 MIME-Version: 1.0 References: <92b759ca-873c-4786-ad88-e199a4dc757e.bingzheng.wbz@alibaba-inc.com>, CABcZeBPVzf9CO4kZ4Hzovr92rBmvUjJ4S-ARO30Yf6EEbVie5w@mail.gmail.com In-Reply-To: CABcZeBPVzf9CO4kZ4Hzovr92rBmvUjJ4S-ARO30Yf6EEbVie5w@mail.gmail.com x-aliyun-mail-creator: W4_2708319_IChTW96aWxsYS81LjAgKFdpbmRvd3MgTlQgNi4xOyBXT1c2NCkgQXBwbGVXZWJLaXQvNTM3LjM2IChLSFRNTCwgbGlrZSBHZWNrbykgQ2hyb21lLzQ2LjAuMjQ5MC44NiBTYWZhcmkvNTM3LjM2jM Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Cc: tls Subject: Re: [TLS] =?utf-8?q?what=27s_Negotiated_Groups_extension_for=3F?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bingzheng Wu List-Id: "This is the mailing list 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 Nov 2015 08:28:28 -0000 >> Without the Negotiated Groups extension,=0A>> =0A>> Case 1: if the server a= ccepts the Groups in ClientHello.keyshare, it just use one of the Groups for D= H, and CertificateVerify for both sides.=0A>> =0A>> Case 2: else it responses = an HelloRetryRequest message, which takes *all Groups* that the server support= s. Client picks one and continue.=0A=0A=0A> No. In case 2, the client indicate= s the groups it supports and the server=0A> tells it which group to use.=0A=0A= So, could the HelloRetryRequest be changed to indicate *all Groups* ?=0AIf so,= could the Negotiated Groups extension be removed? From nobody Sun Nov 15 07:01: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 E191E1A6EE8 for ; Sun, 15 Nov 2015 07:01:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.623 X-Spam-Level: ** X-Spam-Status: No, score=2.623 tagged_above=-999 required=5 tests=[BAYES_80=2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXjgz7l7LEli for ; Sun, 15 Nov 2015 07:01:33 -0800 (PST) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EDA81A6EE2 for ; Sun, 15 Nov 2015 07:01:33 -0800 (PST) Received: by ykba77 with SMTP id a77so203561580ykb.2 for ; Sun, 15 Nov 2015 07:01:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=vM2ikXu5jS/PkD8aAPLJcqN7EZ0J/OI7GSgogLuTR8E=; b=ZSAKWN8QmCkE5rtWGPCeXt+dYyXjt5ytmleKPjp3yweHSftfundyd69yRxlSWQtp0+ kcp4j4Kp9t4Ot4dNoDjirvJoGYMrSSdASAXvR2G9Cg8Hz/rOeQtFdZZgvOHxddDVX1yW x1qM3u/3QAe2WqsTBtiHZZQc7XQs8Rrb4MgU2nL75+PsfrIH7oxHvXdfpCRISeAy2SCu GPJ8G1ispczRNCGUr4MkmoBf5tLRKA7iIoVeKHhX8Mk426RWkUs8D0j9GfBYBc2BCGok qGjCxieXcNVTzTP+Bt5ZSi5XjpAI2tlyuhhC165GLeUPOfO9//9MTZ5TJRaLAK1cXnfR 25qg== 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=vM2ikXu5jS/PkD8aAPLJcqN7EZ0J/OI7GSgogLuTR8E=; b=mVH9BVyJCgcRFtSVaYDdlPYoq1EHSEfm+kdgb9J3H4Emj+iaRlB5hvV0oZ081rG3F1 7h/92SaP7838qrNfayOgiTPxbV7jbKawtlYoazAnwWjGPszbYXSdSiIJsFMLMrGHSh4L HkXlIZRYby6koK/6u1LsPPveiGC/ZFPAFltrSdKOvCWrqlMq2rI7znwCECUHNXp5vomR 2oUgotuaQFd8MbgdNruZ2i6wc0Ir8KDPHAf+j83bwwQAO1VtL0npjfB7Bywrze7wAy4w FpN6Hdanwzt4ixusiqI2DpckFsuqUyJzfSD1KcNYEcV7j8wJVjkXvD5wNJV+NXXprVdq c2fw== X-Gm-Message-State: ALoCoQnd4hGwMU5Kmz0BVoFtSEzqjeMfQo9PjN7Txeh2fRGMuhft/QqhXHKwB7/lutp0zMASXnmb X-Received: by 10.129.79.139 with SMTP id d133mr14114382ywb.115.1447599692866; Sun, 15 Nov 2015 07:01:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.221.203 with HTTP; Sun, 15 Nov 2015 07:00:53 -0800 (PST) In-Reply-To: <88538417-239c-4dbe-aa17-7b8bce3f88c8.bingzheng.wbz@alibaba-inc.com> References: <92b759ca-873c-4786-ad88-e199a4dc757e.bingzheng.wbz@alibaba-inc.com> <88538417-239c-4dbe-aa17-7b8bce3f88c8.bingzheng.wbz@alibaba-inc.com> From: Eric Rescorla Date: Sun, 15 Nov 2015 07:00:53 -0800 Message-ID: To: Bingzheng Wu Content-Type: multipart/alternative; boundary=94eb2c054ad87899c0052495912f Archived-At: Cc: tls Subject: Re: [TLS] what's Negotiated Groups extension for? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Nov 2015 15:01:35 -0000 --94eb2c054ad87899c0052495912f Content-Type: text/plain; charset=UTF-8 On Sun, Nov 15, 2015 at 12:28 AM, Bingzheng Wu < bingzheng.wbz@alibaba-inc.com> wrote: > >> Without the Negotiated Groups extension, > >> > >> Case 1: if the server accepts the Groups in ClientHello.keyshare, it > just use one of the Groups for DH, and CertificateVerify for both sides. > >> > >> Case 2: else it responses an HelloRetryRequest message, which takes > *all Groups* that the server supports. Client picks one and continue. > > > > No. In case 2, the client indicates the groups it supports and the server > > tells it which group to use. > > So, could the HelloRetryRequest be changed to indicate *all Groups* ? > No, I don't think that would be a good idea. > If so, could the Negotiated Groups extension be removed? > No. -Ekr --94eb2c054ad87899c0052495912f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Nov 15, 2015 at 12:28 AM, Bingzheng Wu <bingzheng.= wbz@alibaba-inc.com> wrote:
>> Without the Negotiated Groups extension,
>>
>> Case 1: if the server accepts the Groups in ClientHello.keyshare, = it just use one of the Groups for DH, and CertificateVerify for both sides.=
>>
>> Case 2: else it responses an HelloRetryRequest message, which take= s *all Groups* that the server supports. Client picks one and continue.


> No. In case 2, the client indicates the groups= it supports and the server
> tells it which group to use.

So, could the HelloRetryRequest be changed to indicate *all Groups* = ?

No, I don't think that would be a= good idea.

=C2=A0
If so, could the Negotiated Groups extension be removed?

No.

-Ekr

--94eb2c054ad87899c0052495912f-- From nobody Mon Nov 16 09:09: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 ECA521A6FE2 for ; Mon, 16 Nov 2015 09:08:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.237 X-Spam-Level: * X-Spam-Status: No, score=1.237 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.585, 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 WC__vLRVYfNz for ; Mon, 16 Nov 2015 09:08:56 -0800 (PST) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34F041A6F86 for ; Mon, 16 Nov 2015 09:08:56 -0800 (PST) Received: by igl9 with SMTP id 9so61490497igl.0 for ; Mon, 16 Nov 2015 09:08:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=0W2Hijhi29rVKbpcPC4IdWaB/31tnAQ9kWUQFyI0fFM=; b=ZD3rQ04633V+zT/+3jtR3QkDUT4W71phKdi2YjwKHJXv7QAXRhD4xcYC/aDn7ZZ2aY NRZxEW/C8RTdoImhIuslvqDfB3Pe/t7ugjOoDLWu2bUaa09sM7qqNOI6x1Kf6SwLwHLP iavbZvu9FY6XolW3s/z8l2MzIhUZ0Z/by2DF4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=0W2Hijhi29rVKbpcPC4IdWaB/31tnAQ9kWUQFyI0fFM=; b=iYkZarRvoE9bquo67Ke7QL7sdgE0tg/pOgyg9jKGDmFSudJdxJo5+rTy3KjxeE7sYH Cj/TaD3qp+nfZlqfaK7uvXyAOxfxPtPZ4/hPG5y+WulochfDbjQBf/OlgPlmY64pPoR7 BtZBV9kb0WhQgKzpVepbIWgMdjICAYAp2+ebMbFUeCVXFFMBF5T8Wl47hbzEPAx6uCA9 0sMZRysbRfSA6w0UynVLfhtOOKKzUz7lEcXnGd4fu2S5GfX/5cu+Vl6s7R56WfQ3Ux9N 51jQ/pfoMUV8Y3av8XVfQrhGvo5ku+GuN3jlfhhETFSGspSomrT0x1oSiu4VUVX+Tf40 bWfg== X-Gm-Message-State: ALoCoQl8VZog+ATlxCr/aCy/DQbHw+KiL9tYuBXIY5Bb/4fch6n9TaAlS9p1nVpyAxe1eycZAPf1 X-Received: by 10.50.138.3 with SMTP id qm3mr4488128igb.11.1447693735430; Mon, 16 Nov 2015 09:08:55 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Mon, 16 Nov 2015 17:08:45 +0000 Message-ID: To: Mike Bishop , Yoav Nir , Adam Langley Content-Type: multipart/alternative; boundary=001a1134cb0cd890820524ab7693 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Application data during renegotiation handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 17:09:00 -0000 --001a1134cb0cd890820524ab7693 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable [Reordering your message slightly so the important question is first.] [MB] When I say =E2=80=9Capplication,=E2=80=9D I mean the code being hosted= by the web server that=E2=80=99s actually responding to the interpreted requests. Whi= le I=E2=80=99d like to minimize code changes in the HTTP server, my primary constraint is that I don=E2=80=99t change the application they=E2=80=99re hosting at all.= The change to HTTP/2 and/or TLS 1.3 should be as transparent as possible. Keeping auth that=E2=80=99s currently done via TLS still in TLS helps to reduce those ch= anges at higher layers. [DB] Right, this is why, again, I'm asking for what interface, specifically, are you trying to hold fixed? I can imagine a number of interfaces, ranging from the OpenSSL/Apache boundary (basically impossible, but not your definition of "application") to the Apache/.htaccess boundary (compat is trivial, but probably simpler than your "application"). Without knowing what interface constrains you, it's very difficult to explore the problem space. On Thu, Nov 12, 2015 at 4:09 PM Mike Bishop wrote: > Doing it at the HTTP layer (as an authentication mechanism) is > challenging, since applications aren=E2=80=99t expecting to receive it th= at way, > and moves the authenticated exchange onto a different stream than trigger= ed > it. > Note I provided two (sketches of) proposals, only one of which switches streams. What's incompatible with adapting the SPDY CREDENTIAL frame but tweaking it so it is asserted mid-stream? I would prefer two separate requests, but it seems we could avoid touching the socket layer either way. > I know that there=E2=80=99s the possibility for a layer to fake the clien= t going > away while actually sending a 401, but then you have to be able to tie th= e > client=E2=80=99s second attempt back to the challenge, don=E2=80=99t you? > I don't believe so. But, again, you haven't given me the actual interface, so I have to speculate. Can't you can defer checking against the challenge to when you receive it? So, something like: First request: 1. Client hits frontend. 2. [frontend <-> application] Frontend forwards HTTP request to appropriate application. 3. [frontend <-> application] Application requests certificate auth, handing frontend information to go in CertificateRequest, along with information on how to verify the certificate. 4. Frontend surfaces CertificateRequest information with the HTTP 401 response or similar. Request ends, frontend saves no state. 5. [frontend <-> application] Application thinks the client ran away. Second request (maybe doesn't happen, maybe happens without the first request, doesn't matter): 1. Client hits frontend. It authenticates the request with certificate chain C. (I dunno, sign an exporter value or whatever. Or maybe you do the CREDENTIAL frame + slotted SYN_STREAM route to save on signatures. Or maybe there's something more complex with nonces. We can sort out the exact details.) 2. Frontend checks the client is authenticated as C, but doesn't do anything with C as it doesn't remember the application's challenge. Whether C is a meaningful identity is not its problem yet. 3. [frontend <-> application] Frontend forwards HTTP request to appropriate application. 4. [frontend <-> application] Application requests certificate auth, handing frontend information to go in CertificateRequest, along with information on how to verify the certificate. This is the same output as in step 3 of the first request. 5. Frontend verifies C against information the application gave, etc. Whatever it would have done before. 6. [frontend <-> application] Frontend reports that the client, remarkably quickly :-), received the challenge and authenticated as C. Application continues as it did with the renego hack. > In the HttpBis working group meeting, there was fairly strong consensus > that we needed a backward-compatibility mechanism for existing apps movin= g > to HTTP/2 over TLS 1.[23]; there was also interest in defining something > cleaner in the future for new apps that could adopt something brand new, > but not at the expense of quickly enabling current apps to keep working. > The draft below is the current candidate for least-ugly compat solution. > Doing it at the framing layer is definitely a good option for the somethi= ng > cleaner. > It's possible that I'm misunderstanding the requirements, but if it is possible for the "something cleaner" and "ugly compat solution" to be the same, that is certainly preferable, no? It's possible my guesses about your constraints are incorrect, but so far I'm not seeing any reason that wouldn't be possible. What am I missing here? David > > > *From:* David Benjamin [mailto:davidben@chromium.org] > *Sent:* Thursday, November 12, 2015 12:43 PM > *To:* Yoav Nir ; Adam Langley > > *Cc:* Mike Bishop ; tls@ietf.org > *Subject:* Re: [TLS] Application data during renegotiation handshake > > > > On Wed, Nov 11, 2015 at 10:43 PM Yoav Nir wrote: > > > > On 12 Nov 2015, at 3:32 AM, Adam Langley wrote= : > > > > The TLS 1.3 post-handshake client-auth was intended, as I recall, to > > support HTTP/1.1 over TLS 1.3. > > No, it was (and is) presented as a way to do client certificate > authentication with HTTP/2 not at the initial handshake. > > > With HTTP/2 isn't it cleaner to do client-auth at the HTTP layer (i.e. > > by signing exporter values)? > > It is. I thought that an HTTP authentication method based on certificates > could be a drop-in replacement for TLS layer authentication, but someone = (I > think it was Mike) pointed out that with TLS-layer certificate > authentication the stream continues after the authentication, while with > HTTP-layer authentication, the stream ends with a 401 status code, and th= e > client has to start a new stream with the Authorization header. So > applications would need to be changed for this to work. > > > > Using existing HTTP semantics would certainly be cleaner in a vacuum, but > one could still do it in HTTP/2 layer without creating a new stream. > Perhaps adapt SPDY's CREDENTIAL frame and add a new SWITCH_CREDENTIAL fra= me > to swap a stream's credential slot mid-stream? > > > > Alternatively, HTTP/2 frontend could make the application think there wer= e > two independent requests. Am I misunderstanding the objection? What about > this: > > 1. Client hits HTTP/2 frontend. Frontend talks to application which > decides it needs client auth, expecting it on the same stream. > > 2. Frontend immediately aborts that request and returns a 401 to the > client. Application thinks the client just gave up. > > 3. Client makes a new stream, now authenticated. The frontend hits the > application fresh. Application requests client auth as before and fronten= d > responds immediately with the certificate the client asserted. > > This is, by the way, how Chrome implements client auth today, even with > renego. We never reconfigure client auth mid-stream. > > > > I think it would be helpful to have examples of exactly what the > applications look like, to know what constraints the various interested > parties are working with. > > > > For example, Apache httpd has some high-level configuration file. > > https://httpd.apache.org/docs/2.2/ssl/ssl_howto.html#arbitraryclients > > Existing Apache installs can easily compatibility regardless of how the > HTTP/TLS interaction looks. > > > > On the other extreme, if the goal is to keep Apache httpd unchanged while > only changing OpenSSL, then we have a very different picture because the > OpenSSL API is SSL_renegotiate/SSL_do_handshake (send a HelloRequest) + > SSL_set_state/SSL_do_handshake (don't continue until renego completes). > That one is quite overfit to the old flow and will be difficult to > reconcile with almost anything. > > > > draft-thomson-http2-client-certs-00's HTTP/2 mode seems to be targeting > something in between. It's okay with adding a new application_context_id, > but the client certificate still needs to be asserted at the transport. I= 'm > having a hard time divining the constraints from this. > > > > David > --001a1134cb0cd890820524ab7693 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

[Re= ordering your message slightly so the important question is first.]

= [MB] When I say =E2=80=9Capplication,=E2=80=9D I mean the code bein= g hosted by the web server that=E2=80=99s actually responding to the interp= reted requests.=C2=A0 While I=E2=80=99d like to minimize code changes in th= e HTTP server, my primary constraint is that I don=E2=80=99t change the app= lication they=E2=80=99re hosting at all.=C2=A0 The change to HTTP/2 and/or = TLS 1.3 should be as transparent as possible.=C2=A0 Keeping auth that=E2=80= =99s currently done via TLS still in TLS helps to reduce those changes at h= igher layers.

[DB] Right, this is why, aga= in, I'm asking for what interface, specifically, are you trying to hold= fixed? I can imagine a number of interfaces, ranging from the OpenSSL/Apac= he boundary (basically impossible, but not your definition of "applica= tion") to the Apache/.htaccess boundary (compat is trivial, but probab= ly simpler than your "application"). Without knowing what interfa= ce constrains you, it's very difficult to explore the problem space.


On Thu, Nov 12, 2015 at 4:09 PM Mike Bishop &= lt;Michae= l.Bishop@microsoft.com> wrote:

Doing it at the HTTP layer (as an aut= hentication mechanism) is challenging, since applications aren=E2=80=99t ex= pecting to receive it that way, and moves the authenticated exchange onto a different stream than triggered it.

=
N= ote I provided two (sketches of) proposals, only one of which switches stre= ams. What's incompatible with adapting the SPDY CREDENTIAL frame but tw= eaking it so it is asserted mid-stream? I would prefer two separate request= s, but it seems we could avoid touching the socket layer either way.

I know that there=E2=80=99s the possibil= ity for a layer to fake the client going away while actually sending a 401,= but then you have to be able to tie the client=E2=80=99s second attempt ba= ck to the challenge, don=E2=80=99t you?

=
I don't be= lieve so. But, again, you haven't given me the actual interface, so I h= ave to speculate. Can't you can defer checking against the challenge to= when you receive it? So, something like:

First request:
1. Clien= t hits frontend.
2.=C2=A0[frontend <-> application]=C2=A0Fr= ontend forwards HTTP request to appropriate application.
3.=C2=A0= [frontend <-> application]=C2=A0Application requests certificate auth= , handing frontend information to go in=C2=A0CertificateRequest, along with= information on how to verify the certificate.
4. Frontend surfac= es CertificateRequest information with the HTTP 401 response or similar. Re= quest ends, frontend saves no state.
5. [frontend <-> appli= cation] Application thinks the client ran away.

Se= cond request (maybe doesn't happen, maybe happens without the first req= uest, doesn't matter):
1. Client hits frontend. It authentica= tes the request with certificate chain C. (I dunno, sign an exporter value = or whatever. Or maybe you do the CREDENTIAL frame + slotted SYN_STREAM rout= e to save on signatures. Or maybe there's something more complex with n= onces. We can sort out the exact details.)
2. Frontend checks the= client is authenticated as C, but doesn't do anything with C as it doe= sn't remember the application's challenge. Whether C is a meaningfu= l identity is not its problem yet.
3. [frontend <-> ap= plication] Frontend forwards HTTP request to appropriate application.
=
4. [frontend <-> application] Application requests certificate a= uth, handing frontend information to go in CertificateRequest, along with i= nformation on how to verify the certificate. This is the same output as in = step 3 of the first request.
5. Frontend verifies C against= information the application gave, etc. Whatever it would have done before.=
6. [frontend <-> application] Frontend reports that the cl= ient, remarkably quickly :-), received the challenge and authenticated as C= . Application continues as it did with the renego hack.
=C2=A0

In the HttpBis working group meeting, there = was fairly strong consensus that we needed a backward-compatibility mechani= sm for existing apps moving to HTTP/2 over TLS 1.[23]; there was also interest in defining something cleaner in the f= uture for new apps that could adopt something brand new, but not at the exp= ense of quickly enabling current apps to keep working.=C2=A0 The draft belo= w is the current candidate for least-ugly compat solution.=C2=A0 Doing it at the framing layer is definitely a good = option for the something cleaner.

It'= s possible that I'm misunderstanding the requirements, but if it is pos= sible for the "something cleaner" and "ugly compat solution&= quot; to be the same, that is certainly preferable, no? It's possible m= y guesses about your constraints are incorrect, but so far I'm not seei= ng any reason that wouldn't be possible. What am I missing here?
<= /div>

= David
=C2= =A0

=C2=A0

From: David Benjamin [mailto:davidben@chromium.org]
Sent: Thursday, November 12, 2015 12:43 PM
To: Yoav Nir <ynir.ietf@gmail.com>; Adam Langley <agl@imperialviolet.org>
Cc: Mike Bishop <Michael.Bishop@microsoft.com>; tls@ietf.org
Subject: Re: [TLS] Application data during renegotiation handshake

=C2=A0

On Wed, Nov 11, 2015 at 10:43 PM Yoav Nir <ynir.ietf@gmail.com&= gt; wrote:


> On 12 Nov 2015, at 3:32 AM, Adam Langley <agl@imperialviolet.org> wrote: >
> The TLS 1.3 post-handshake client-auth was intended, as I recall, to > support HTTP/1.1 over TLS 1.3.

No, it was (and is) presented as a way to do client certificate authenticat= ion with HTTP/2 not at the initial handshake.

> With HTTP/2 isn't it cleaner to do client-auth at the HTTP layer (= i.e.
> by signing exporter values)?

It is. I thought that an HTTP authentication method based on certificates c= ould be a drop-in replacement for TLS layer authentication, but someone (I = think it was Mike) pointed out that with TLS-layer certificate authenticati= on the stream continues after the authentication, while with HTTP-layer authentication, the stream ends with= a 401 status code, and the client has to start a new stream with the Autho= rization header. So applications would need to be changed for this to work.=

=C2=A0

Using existing HTTP semantics would certainly be cle= aner in a vacuum, but one could still do it in HTTP/2 layer without creatin= g a new stream. Perhaps adapt SPDY's CREDENTIAL frame and add a new SWI= TCH_CREDENTIAL frame to swap a stream's credential slot mid-stream?

=C2=A0

Alternatively, HTTP/2 frontend could make the applic= ation think there were two independent requests. Am I misunderstanding the = objection? What about this:

1. Client hits HTTP/2 frontend. Frontend talks to ap= plication which decides it needs client auth, expecting it on the same stre= am.

2. Frontend immediately aborts that request and retu= rns a 401 to the client. Application thinks the client just gave up.=

3. Client makes a new stream, now authenticated. The= frontend hits the application fresh. Application requests client auth as b= efore and frontend responds immediately with the certificate the client ass= erted.

This is, by the way, how Chrome implements client au= th today, even with renego. We never reconfigure client auth mid-stream.=

=C2=A0

I think it would be helpful to have examples of exac= tly what the applications look like, to know what constraints the various i= nterested parties are working with.

=C2=A0

For example, Apache httpd has some high-level config= uration file.

Existing Apache installs can easily compatibility re= gardless of how the HTTP/TLS interaction looks.

=C2=A0

On the other extreme, if the goal is to keep Apache = httpd unchanged while only changing OpenSSL, then we have a very different = picture because the OpenSSL API is SSL_renegotiate/SSL_do_handshake (send a= HelloRequest)=C2=A0+ SSL_set_state/SSL_do_handshake (don't continue until renego completes). That one is quite overfit to = the old flow and will be difficult to reconcile with almost anything.

=C2=A0

draft-thomson-http2-client-certs-00's HTTP/2 mod= e seems to be targeting something in between. It's okay with adding a n= ew application_context_id, but the client certificate still needs to be ass= erted at the transport. I'm having a hard time divining the constraints from this.

=C2=A0

David

--001a1134cb0cd890820524ab7693-- From nobody Mon Nov 16 15:17: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 D89F61A8A90 for ; Mon, 16 Nov 2015 15:17:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.423 X-Spam-Level: * X-Spam-Status: No, score=1.423 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWFW10K-TNJq for ; Mon, 16 Nov 2015 15:17:30 -0800 (PST) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::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 992CB1A8A8C for ; Mon, 16 Nov 2015 15:17:30 -0800 (PST) Received: by ykba77 with SMTP id a77so266164476ykb.2 for ; Mon, 16 Nov 2015 15:17:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm_com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:content-type; bh=eRDdKQtFS4hon9PHOrPiRL8ndeAaEcyjHsMhh6HdUdo=; b=oeNOxy4xe5gFYSsVqs6mxQsZNihciK/dyuxdmlX4SO55iMfLrfWlHkwUDgQQbbxZNT Gh6yROETD0kuaQNUYBClvBM6qH/L5PSyQoDDfRfswKOXelujPg8kcLhkUnjN6krOar1W IW5btFt55oeLPzhsH/IEF0TnEi96cSAdN4QUxJv9ALjsLHR+a2P5jMa6Mal8/mrRV9Zn +etbdS2y+z27yWnuGuhq6/1TZelSix1MsnMntmU2PInyyAfUYwEDloPO5UMlg/S08tMy PEaEWqHsCbTtyC2lvRlS7eTHzBMylYD7Fbkfl2NZOUUMLcBedirCCCMV33PfVp3zsMqG gWnw== 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=eRDdKQtFS4hon9PHOrPiRL8ndeAaEcyjHsMhh6HdUdo=; b=OTg1WiAqSsS3EwE5RVh3Mo4Xk1rTUng4GESyHXY/AjnlzLXdwhlZMvESj2fgvr5BKZ v20tR9loH9iFnfADMMgmIY4suvDbrth217HyU1KUixDVAf3TshSmUCWw/Vx9fXI6JV31 B9Avd9U9eHHpzLYyLcvcHTCst7YtfhWLQf/wVNSGd10J0NmmZGv5XbZ1PYIHKAxZbmbp ZNRwksF9kbR8AV7bu8xl8Lb4+TIPZFa/o4/Zdy8PQfEDjcUp6X5a9oaYkzzUtqyU3t1I it6DC9aroLEYjVN/RMya8WcQxj8htmRPeIyCwmiathy88iN8chAJlb32/64V+YI5jAsM Jxiw== X-Gm-Message-State: ALoCoQkWCKMm1aAwieSWYg+65Dpscgvqfa+thzFPVAys0K68Q/czrNvWK0EegKz2m0M9MLtAGRet X-Received: by 10.13.218.198 with SMTP id c189mr10846559ywe.165.1447715849856; Mon, 16 Nov 2015 15:17:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.221.203 with HTTP; Mon, 16 Nov 2015 15:16:50 -0800 (PST) From: Eric Rescorla Date: Mon, 16 Nov 2015 15:16:50 -0800 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c08192af799820524b09ced Archived-At: Subject: [TLS] PR#345: IANA Considerations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 23:17:32 -0000 --94eb2c08192af799820524b09ced Content-Type: text/plain; charset=UTF-8 PR: https://github.com/tlswg/tls13-spec/pull/345 Per discussion in Yokohama, I have rewritten the IANA considerations section so that the 16-bit code spaces are "Specification Required" and they have a "Recommended" column. 1. The Cipher Suites "Recommended" column was populated based on the Standards Track RFCs listed in the document (and I removed the others). 2. The Extensions "Recommended"column was populated by taking all the Standards Track RFCs and marking them "Yes" and marking others "No". I recognize that this probably marks a bunch of extensions which we actually don't love as "Yes" (and perhaps others as "No") and if people want to move some from one column to another, that seems like a great mailing list discussion which I will let the chairs drive. Thanks, -Ekr --94eb2c08192af799820524b09ced Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
PR: https://github.com/tlswg/tls13-spec/pull/345

Per = discussion in Yokohama, I have rewritten the IANA considerations section
so that the 16-bit code spaces are "Specification Required&quo= t; and they have
a "Recommended" column.

=
1. The Cipher Suites "Recommended" column was populate= d based on
=C2=A0 =C2=A0 the Standards Track RFCs listed in the d= ocument (and I removed the
=C2=A0 =C2=A0 others).

<= /div>
2. The Extensions "Recommended"column was populated by = taking all
=C2=A0 =C2=A0 the Standards Track RFCs and marking the= m "Yes" and marking
=C2=A0 =C2=A0 others "No"= . I recognize that this probably marks a bunch of extensions
=C2= =A0 =C2=A0 which we actually don't love as "Yes" (and perhaps= others as "No")
=C2=A0 =C2=A0 and if people want to mo= ve some from one column to another, that
=C2=A0 =C2=A0 seems like= a great mailing list discussion which I will let the chairs
=C2= =A0 =C2=A0 drive.

Thanks,
-Ekr




--94eb2c08192af799820524b09ced-- From nobody Mon Nov 16 15:19: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 AE61E1A8A9A for ; Mon, 16 Nov 2015 15:19:27 -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, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OFpn1dXtLNZV for ; Mon, 16 Nov 2015 15:19:26 -0800 (PST) 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 722F81A8A7A for ; Mon, 16 Nov 2015 15:19:26 -0800 (PST) Received: by ykba77 with SMTP id a77so266210395ykb.2 for ; Mon, 16 Nov 2015 15:19:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=EBBwv6IOqgQYcetkKloQCxNbYIoDDzWjPQEM02JzUck=; b=zjvY28/ZHdkhgpzLR246T0F8A+cZT+2FoB+RTdF6bgtvkE+Yqc3ZTsdVz5mm9yM36u 99ls7LLYfPbfwdcgRUvCq16wtmHuIEiEpLBCal6hpAKvFuyI+JNp2XjX484lJFAKd2Uf UZuHb0gbdf13ANQWr7Q+ozgPrBAe0hr3QcCeHcpSfqmuZEbghRClNhMHiBhWsQlerCIz SZfK1EQdokdSUVTkRYhlmaZZ9YyulHjj8t24VLPou1VFePtiYW/eMxGWUIr/FWL8DE0M OV0zQ4JkAevDeV6FQKdtqalcXSIM23of2LqoB0gz4VVPEPiAhl52yxFKHAvYQGAGGWXP Gh1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=EBBwv6IOqgQYcetkKloQCxNbYIoDDzWjPQEM02JzUck=; b=YjRb3u6kYuK21tNfZqYhtEAGcKzHy/wuW/Y06gsjGeqG+VTm0qYq3pZPjsol74RzRq p5TcagStTuQjo/3oBpGsxMKv739QXnT6Ld78tYwerj46WtRKqC/SbQcx7sGUBsIYSSYD 895523QEtdrjh9A+kSr8avyLLglUXIN4OBDcn6xujOsJCSWLj6hPlYl+s1YZIIHGWpJW zd6ZxW5rUpOch5/zz+RU4cftlB0yrzIcSDEhse4qKONKz9OcScJnglQefekwURHh97XQ sqqxVNmaDbLTrn3Try8t7UBntJbN+38eLVsHGTNd8uFEGloCGJreLh+gTn928Fp1GDjc mfBA== X-Gm-Message-State: ALoCoQl1LonQuO6cQBLdrmbbypI6vHZHGa27Yz8wgTpC2t73Iu2eBVHS1bau7VZBjeuaNbTs0Wih X-Received: by 10.13.249.4 with SMTP id j4mr37728734ywf.129.1447715965762; Mon, 16 Nov 2015 15:19:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.221.203 with HTTP; Mon, 16 Nov 2015 15:18:46 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Mon, 16 Nov 2015 15:18:46 -0800 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c0826e8e030840524b0a3c7 Archived-At: Subject: Re: [TLS] PR#345: IANA Considerations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 23:19:27 -0000 --94eb2c0826e8e030840524b0a3c7 Content-Type: text/plain; charset=UTF-8 Double-checking, I see that some of the entries in the "TLS 1.3" column for Extensions are wrong. Will be updating shortly. On Mon, Nov 16, 2015 at 3:16 PM, Eric Rescorla wrote: > PR: https://github.com/tlswg/tls13-spec/pull/345 > > Per discussion in Yokohama, I have rewritten the IANA considerations > section > so that the 16-bit code spaces are "Specification Required" and they have > a "Recommended" column. > > 1. The Cipher Suites "Recommended" column was populated based on > the Standards Track RFCs listed in the document (and I removed the > others). > > 2. The Extensions "Recommended"column was populated by taking all > the Standards Track RFCs and marking them "Yes" and marking > others "No". I recognize that this probably marks a bunch of extensions > which we actually don't love as "Yes" (and perhaps others as "No") > and if people want to move some from one column to another, that > seems like a great mailing list discussion which I will let the chairs > drive. > > Thanks, > -Ekr > > > > > --94eb2c0826e8e030840524b0a3c7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Double-checking, I see that some of the entries in the &qu= ot;TLS 1.3" column
for Extensions are wrong. Will be updating shor= tly.

O= n Mon, Nov 16, 2015 at 3:16 PM, Eric Rescorla <ekr@rtfm.com> wrot= e:
PR: https://github.co= m/tlswg/tls13-spec/pull/345

Per discussion in Yokoha= ma, I have rewritten the IANA considerations section
so that the = 16-bit code spaces are "Specification Required" and they have
a "Recommended" column.

1. The Ci= pher Suites "Recommended" column was populated based on
=C2=A0 =C2=A0 the Standards Track RFCs listed in the document (and I remov= ed the
=C2=A0 =C2=A0 others).

2. The Ext= ensions "Recommended"column was populated by taking all
=C2=A0 =C2=A0 the Standards Track RFCs and marking them "Yes" an= d marking
=C2=A0 =C2=A0 others "No". I recognize that t= his probably marks a bunch of extensions
=C2=A0 =C2=A0 which we a= ctually don't love as "Yes" (and perhaps others as "No&q= uot;)
=C2=A0 =C2=A0 and if people want to move some from one colu= mn to another, that
=C2=A0 =C2=A0 seems like a great mailing list= discussion which I will let the chairs
=C2=A0 =C2=A0 drive.

Thanks,
-Ekr





--94eb2c0826e8e030840524b0a3c7-- From nobody Mon Nov 16 17:26:28 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFA521A89FA for ; Mon, 16 Nov 2015 17:26:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.622 X-Spam-Level: X-Spam-Status: No, score=0.622 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b59jpDxRYYsc for ; Mon, 16 Nov 2015 17:26:25 -0800 (PST) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6AFB1AC411 for ; Mon, 16 Nov 2015 17:26:25 -0800 (PST) Received: by ykfs79 with SMTP id s79so270969551ykf.1 for ; Mon, 16 Nov 2015 17:26:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm_com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:content-type; bh=zbwn/VF8y/DI0yz2fT2OJHiL2zbE+sD1fG/W+WUMB1U=; b=JdNVlxxQhrkViOBT8M928GaG4ugY/QmxGyZtT5zcPyChv4YGZBgmBl5s7tqQ8Z/58z 4s94YmRk2NCn2v1ycut9XQVRl+Ky5hworOY37fLJtKIBE7HCdI/v9M6EHx16oduJcptn tpVyLdM5pwMi2Bc7SCibRUiGMv/hQ5VEFKzrl2BI1z/kyhNWpf4UizRm/O9k705EkEBB cbJLKJ4Qa/jW/btlThdBSn+AVwLoFbO/HUSzBNw6UI84tFkDhYpAzx0Biw2HjKW09MlV 8mTK6/cDZyVM1w9DTDnzgoCkuhnoiB0gicHk6Fzr0LMH8PDDplazh37gqh/QAppeidUp QGYQ== 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=zbwn/VF8y/DI0yz2fT2OJHiL2zbE+sD1fG/W+WUMB1U=; b=OtOwfVOdjhPKa+bKGWfeWjr6VF6ManzE3+e4HyCHWvsBmvKUxUKMvDigjhhCW84QcR mwKQL2K4fWGaKuucdw7aOTsuR+v5c0c5qaIT1Yomoiu2G5a2czsQLdP/jQJacopbIu/I 2CRjKY/WEhESMzSmtU3YP20F36XJX+XiLgNBldo7FmexJCSUKlzzKZ6tETzfNJ5ENXcV OE0rMczQnrDzaAKYwcJOsGSqPSB0pgAoqa7hG7RuKdZ8bZ6/gBytHRY43rSfaB2RiGvc dPrynVjBS0c5EMqYtr5Tdy2kmek/VTU26BXbXaPomxjGMjmuMsrK6UddWaUv0L+gPelt Hzog== X-Gm-Message-State: ALoCoQk0VYbfiSKpVBxNxgBSEGrwqs70QIx4h0lUFY5qLynAX5hiTyKNaeM/nP97qJFEt4DjBGok X-Received: by 10.13.197.194 with SMTP id h185mr30997197ywd.12.1447723585001; Mon, 16 Nov 2015 17:26:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.221.203 with HTTP; Mon, 16 Nov 2015 17:25:45 -0800 (PST) From: Eric Rescorla Date: Mon, 16 Nov 2015 17:25:45 -0800 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a114edd4a048dcd0524b26a21 Archived-At: Subject: [TLS] PR#346: Individual traffic key generation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 01:26:27 -0000 --001a114edd4a048dcd0524b26a21 Content-Type: text/plain; charset=UTF-8 https://github.com/tlswg/tls13-spec/pull/346 As discussed in Seattle and Yokohama, I've broken out the traffic key generation into individual values. This makes life somewhat easier for those dealing the cryptographic modules, because some of this data needs to be public and some of it needs to be secret. This general change already had consensus, so I plan to merge it on Wednesday modulo major objections. Please advise here or on Github if you find any errors or you violently object. -Ekr --001a114edd4a048dcd0524b26a21 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
h= ttps://github.com/tlswg/tls13-spec/pull/346

As d= iscussed in Seattle and Yokohama, I've broken out the traffic key gener= ation
into individual values. This makes life somewhat easier for= those dealing the
cryptographic modules, because some of this da= ta needs to be public and some
of it needs to be secret.

This general change already had consensus, so I plan to me= rge it on Wednesday
modulo major objections. Please advise here o= r on Github if you find any errors
or you violently object.
=

-Ekr


--001a114edd4a048dcd0524b26a21-- From nobody Mon Nov 16 19:01: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 14A6B1ACDA0 for ; Mon, 16 Nov 2015 19:01:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTHj2Imq76gP for ; Mon, 16 Nov 2015 19:01:45 -0800 (PST) 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 9D2591ACD9F for ; Mon, 16 Nov 2015 19:01:45 -0800 (PST) Received: by igvi2 with SMTP id i2so88867215igv.0 for ; Mon, 16 Nov 2015 19:01:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=g/omYX+sEVoRNqKFlSQAScxs+jFEl4T7qz/jjDpN8f4=; b=YcMcoOZYI4vyr9yttCzzxlP0BJ2tE0EiXHtkfbsBStrkjrJJgyCgPvNkVLDQcVvTZg xeWA8Xtw1Z196JKlBYqI9BU2lsTlPV13mA5hISzg6Rl1NhNOSGxwWKy47ahYxeBWWNdq SXjbSffhZDRI5sXJYe863zAU46MYKbn9at+XxCgzaqr8s3EF2XCWDMCWiqcUjHBn/F/l A+pq7uL8N5EmWmALUneUDKwMSFhgXXPwz5sfYvjMEAkxdgyQJZMBdWa/7CQXaVpR4Zp6 r9BB+k4Jf4+lG27Ts/cAy6Rxmh+J7mVDEUABzqhuT23aKXxnccpdFtcNvogpRcOH7iEu snRA== MIME-Version: 1.0 X-Received: by 10.50.221.36 with SMTP id qb4mr14252175igc.77.1447729304881; Mon, 16 Nov 2015 19:01:44 -0800 (PST) Received: by 10.36.155.139 with HTTP; Mon, 16 Nov 2015 19:01:44 -0800 (PST) In-Reply-To: References: Date: Mon, 16 Nov 2015 19:01:44 -0800 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR#346: Individual traffic key generation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 03:01:47 -0000 I have to ask why the continued insistence on calling the thing that forms part of the nonce an "IV". I find it to be misleading. Also, it might be worth noting that the string "early data key expansion, server write " is never needed. On 16 November 2015 at 17:25, Eric Rescorla wrote: > https://github.com/tlswg/tls13-spec/pull/346 > > As discussed in Seattle and Yokohama, I've broken out the traffic key > generation > into individual values. This makes life somewhat easier for those dealing > the > cryptographic modules, because some of this data needs to be public and some > of it needs to be secret. > > This general change already had consensus, so I plan to merge it on > Wednesday > modulo major objections. Please advise here or on Github if you find any > errors > or you violently object. > > -Ekr > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Mon Nov 16 19:53: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 A76F11ACE4D for ; Mon, 16 Nov 2015 19:53: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, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4c53cVg5v6h for ; Mon, 16 Nov 2015 19:53:02 -0800 (PST) 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 5AB6D1ACE4C for ; Mon, 16 Nov 2015 19:53:02 -0800 (PST) Received: by ykdv3 with SMTP id v3so272953654ykd.0 for ; Mon, 16 Nov 2015 19:53:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=wxjvW8k0hxGwGmZPFde1L32d3JQcxf0WPPj0F/W1CEI=; b=YBqtJeFtDAdN7JwCOMEqrzBhAFkzlOsYIF2ck0hGEWrhozQj/5YHZOHbqeqg1+G9HM wDgqkpV4iHRJosAzT/6RRjwo1V9hYQLlqwtcpBt6jTCgBH0v812YiS9YB2ALc2d2YGvx Tt7dX5kps8urLS2/T3bCH3kstka7KXC7QcSqwVU/LC8aSvu54Y0UBNSFiWcfNSjYrgwW LBy5DJtnhMq71SyFOV+Yjjj6shjPnhbU73eIZUrpVeZBGkcRfnsbVHthvYHJ0t9HjO7R /oths87AUrF7xhOqSWGW5yP1rk/fMUbr5qQYBM/YsFHcs8Ga0fqtQDKssYMqbQgvkoQX F3Tw== 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=wxjvW8k0hxGwGmZPFde1L32d3JQcxf0WPPj0F/W1CEI=; b=MaUZIZKPPY2yrtv5J/43cyg/jCCz1vaLiE2qLQc02rKMTaAa5tsEITyUMpWAIbk37k TLu4tDrRjnQERbcvvGrEgdmdCW88OM5sitcMhulYwkvtils5ocqqw6pwRUDyWvH0h28g FN2FHOABFxaG/chfzN9x8bCN7CFxKlQqtIZBOgeoc331tU0pcXIqefUqtuWf97rzsxmH TbU4JeEZHGoVzOXzc0GwaScWbjaOLn7LL5EY5j3M6AbwpLg5LPSG3bEgWPDqeqRWmQbb jDtlvM80G6fscYQJz2LonIzkcxyeLHMN1ewEkz/tCz/oGstuiPUO62t9Gam0u9oEB11/ 5Hqg== X-Gm-Message-State: ALoCoQle8hARdcEPCpXVMhovadVLyL62IchCqwNPMkNf6ztmhtugWBUsuIgVE567o5tRt8p2UjKM X-Received: by 10.13.218.198 with SMTP id c189mr11575643ywe.165.1447732381625; Mon, 16 Nov 2015 19:53:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.221.203 with HTTP; Mon, 16 Nov 2015 19:52:22 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Mon, 16 Nov 2015 19:52:22 -0800 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=94eb2c08192a5661210524b4768d Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR#346: Individual traffic key generation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 03:53:03 -0000 --94eb2c08192a5661210524b4768d Content-Type: text/plain; charset=UTF-8 On Mon, Nov 16, 2015 at 7:01 PM, Martin Thomson wrote: > I have to ask why the continued insistence on calling the thing that > forms part of the nonce an "IV". I find it to be misleading. > This is the historical terminology that TLS has used. > > Also, it might be worth noting that the string "early data key > expansion, server write " is never needed. > Yes, that's fair. -Ekr > > On 16 November 2015 at 17:25, Eric Rescorla wrote: > > https://github.com/tlswg/tls13-spec/pull/346 > > > > As discussed in Seattle and Yokohama, I've broken out the traffic key > > generation > > into individual values. This makes life somewhat easier for those dealing > > the > > cryptographic modules, because some of this data needs to be public and > some > > of it needs to be secret. > > > > This general change already had consensus, so I plan to merge it on > > Wednesday > > modulo major objections. Please advise here or on Github if you find any > > errors > > or you violently object. > > > > -Ekr > > > > > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > --94eb2c08192a5661210524b4768d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Nov 16, 2015 at 7:01 PM, Martin Thomson <martin.thomson@gmail= .com> wrote:
I have to ask = why the continued insistence on calling the thing that
forms part of the nonce an "IV".=C2=A0 I find it to be misleading= .

This is the historical terminology th= at TLS has used.=C2=A0
=C2=A0

Also, it might be worth noting that the string "early data key
expansion, server write " is never needed.

Yes, that's fair.

-Ekr
=C2= =A0

On 16 November 2015 at 17:25, Eric Rescorla <ekr@rtfm.com> wrote:
> https://github.com/tlswg/tls13-spec/pull/346 >
> As discussed in Seattle and Yokohama, I've broken out the traffic = key
> generation
> into individual values. This makes life somewhat easier for those deal= ing
> the
> cryptographic modules, because some of this data needs to be public an= d some
> of it needs to be secret.
>
> This general change already had consensus, so I plan to merge it on > Wednesday
> modulo major objections. Please advise here or on Github if you find a= ny
> errors
> or you violently object.
>
> -Ekr
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--94eb2c08192a5661210524b4768d-- From nobody Mon Nov 16 20:05:15 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8011F1ACE86 for ; Mon, 16 Nov 2015 20:05:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.701 X-Spam-Level: **** X-Spam-Status: No, score=4.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_SUMOF=1, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_66=0.6, J_CHICKENPOX_84=0.6, J_CHICKENPOX_92=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 5p0vGb1eWUPs for ; Mon, 16 Nov 2015 20:05:07 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CE751ACE90 for ; Mon, 16 Nov 2015 20:05:06 -0800 (PST) Received: by wmvv187 with SMTP id v187so207650438wmv.1 for ; Mon, 16 Nov 2015 20:05:03 -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=RMh3JQxhGnXcXrPL4c0hxdZA0lJirJDjG3m7U+J2ZNY=; b=rkY0lOIdrYAL7nvTqYva+ibH4v/9nXBNwmpWL50YgrXnjG6ITFQ0yGhcXngfFzSCb0 C67rLuwceAHR3N/PEjpvUsz6tmCBGaWUCB7IhriKx4o1p5rD3NDFBP+sObVXauXGqmLA clLl7KmA6f+hta8cE7tNeIHyw/V3jw3EvpJoKIEGTMQ4Lvb6iW5uVZy/f6isBQ7gqEel qkE6GgXBWKMEJRh7un3z31vV7VwZ07VWvL+xNrYWh0cJjcKNgZSn0S5q+VORpJaknwSg vULYeH+zJM9xU3L4gd2+oXC2fN3J45tlPrGb/5LeZEMM47PkdPjmLBojmdIfTHMmplR6 UYvQ== MIME-Version: 1.0 X-Received: by 10.28.24.5 with SMTP id 5mr13300085wmy.3.1447733103840; Mon, 16 Nov 2015 20:05:03 -0800 (PST) Received: by 10.194.30.166 with HTTP; Mon, 16 Nov 2015 20:05:03 -0800 (PST) Date: Tue, 17 Nov 2015 06:05:03 +0200 Message-ID: From: Ismail Kizir To: tls@ietf.org Content-Type: multipart/mixed; boundary=001a114690586272d30524b4a176 Archived-At: Subject: [TLS] An new "theoretically and practically unbreakable" and fast encryption algorithm X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 04:05:13 -0000 --001a114690586272d30524b4a176 Content-Type: multipart/alternative; boundary=001a114690586272ce0524b4a174 --001a114690586272ce0524b4a174 Content-Type: text/plain; charset=UTF-8 Hello, I've developed a new encryption algorithm, which dynamically changes the key according to plaintext and practically impossible to break. I also opened to public with MIT License. It is also quite fast; ~80% faster than the fastest mode of AES without cpu instruction set support. I will present a paper on a Turkish National Symposium on 3 December: Inet-tr 2015. I am sending the document as an attachment Sorry, it is in Turkish Language. I've studied political sciences. Unfortunately, I haven't mathematical background to write the proof. But it is a very simple logic. Anyone who looks at the attached C code may understand why and how it is unbreakable. I use the key as jump table and with every encrypted byte, I change the jump table(the key) as a result of 3-4 parameters including the last plaintext byte itself. The code is self documented in English. On Linux simply gcc HohhaDynamicXOR.c -O2 -Wall ./a.out will make integrity checks and print benchmarks. It is production ready. Other algorithm results are the output of the "openssl speed" command. If I am right; you will not be disappointed to include "Hohha Dynamic XOR Encryption Algorithm" on TLS 1.3 Draft. Here are the benchmarks for 16,64,256,1024,8192 byte values with -O2 optimization level(-O3 gives ~20% better results).Hop2 is 2 jump results and Hop3 is 3 jump results. Please feel free to ask any questions or any explanation I can give. PS: I've sent 2 other mails but they are blocked because of max. attachment size quota. If admin allows, you can see my paper to be presented on Turkish National Internet Symposium. Regards Ismail Kizir *Algoritma* *16* *64* *256* *1024* *8192* Memcpy 663.42 1052.33 1043.33 1147.54 869.60 *Hohha XOR-Hop2* *162.33* *193.15* *198.17* *198.65* *202.56* *Hohha XOR Hop3* *116.46* *127.42* *130.00* *130.36* *127.33* des cbc 44.98 46.53 46.90 47.14 47.05 des ede3 17.65 18.00 18.03 18.03 18.06 rc2 cbc 26.58 27.10 27.28 27.25 27.35 rc4 22.22 36.02 41.81 43.71 43.63 blowfish cbc 84.71 90.58 91.71 91.28 91.41 Cast cbc 81.23 86.99 88.62 89.00 89.10 aes-128 cbc 77.85 85.20 87.91 18.27 18.59 aes-192 cbc 65.98 71.70 72.70 15.53 15.65 Aes-256 cbc 57.59 61.22 62.43 133.67 134.40 Camellia-128 74.04 109.17 124.03 12.87 12.88 Camellia-192 62.57 85.60 94.68 97.20 98.11 Camellia-256 62.58 85.63 94.69 97.35 97.97 aes-128 ige 78.44 82.05 83.08 83.42 83.17 Aes-192 ige 66.25 69.13 69.75 69.95 69.94 Aes-256 ige 57.69 59.71 60.22 60.40 60.27 --001a114690586272ce0524b4a174 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

I've de= veloped a new encryption algorithm, which dynamically changes the key accor= ding to plaintext and practically impossible to break. I also opened to pub= lic with MIT License.
It is also quite= fast; ~80% faster than the fastest mode of AES without cpu instruction set= support.
I will present a paper on a = Turkish National Symposium on 3 December: Inet-tr 2015. I am sending the do= cument as an attachment Sorry, it is in Turkish Language.=C2=A0
I've studied political sciences. Unfortunatel= y, I haven't mathematical background to write the proof. But it is a ve= ry simple logic. Anyone who looks at the attached C code may understand why= and how it is unbreakable.=C2=A0

=
I use the key as jump table and with = every encrypted byte, I change the jump table(the key) as a result of 3-4 p= arameters including the last plaintext byte itself.
The code is self documented in English.
On Linux simply=C2=A0
= gcc HohhaDynamicXOR.c -O2 -Wall
./a.ou= t
will make integrity checks and print= benchmarks. It is production ready.
O= ther algorithm results are the output of the "openssl speed" comm= and.
If I am right; you will not be di= sappointed to include "Hohha Dynamic XOR Encryption Algorithm" on= TLS 1.3 Draft. Here are the benchmarks for 16,64,256,1024,8192 byte values= with -O2 optimization level(-O3 gives ~20% better results).Hop2 is 2 jump = results and Hop3 is 3 jump results.
Pl= ease feel free to ask any questions or any explanation I can give.

PS: = I've sent 2 other mails but they are blocked because of max. attachment= size quota. If admin allows, you can see my paper to be presented on Turki= sh National Internet Symposium.

Regards
Ismail Kizir

= <= td width=3D"64" bgcolor=3D"#ffffff" style=3D"border-style:none none solid;b= order-bottom-width:1px;border-bottom-color:rgb(0,0,128);padding:0cm">

18.03

<= td width=3D"42" bgcolor=3D"#ffffff" style=3D"border-style:none none solid;b= order-bottom-width:1px;border-bottom-color:rgb(0,0,128);padding:0cm">

22.22

<= td width=3D"64" bgcolor=3D"#ffffff" style=3D"border-style:none none solid;b= order-bottom-width:1px;border-bottom-color:rgb(0,0,128);padding:0cm">

89.00

=

71.70

<= td width=3D"87" bgcolor=3D"#ffffff" style=3D"border-style:none none solid;b= order-bottom-width:1px;border-bottom-color:rgb(0,0,128);padding:0cm">

83.17

= Algoritma

16

64

<= /th>

256

1024<= /font>

8192

= Memcpy

663.42

1052.33

1043.33

1147.54

869.60

Hohha XOR-H= op2

= 162.33

193.15

198.17

198.65<= /font>

202.56=

Hohha XOR Hop= 3

116.46<= /font>

127.42=

130.00

130.36

127.33

=

des cbc

44.98

46.53

46.90

47.14

47.05

des ede3

17.65

18.00

18.03

<= font color=3D"#000000">18.06

rc2 cbc

26.58

27.1= 0

27.28

27.25

= 		=

= 27.35

rc4

<= font color=3D"#000000">36.02

41.= 81

43.71

43.63

=

blowfish cbc<= /font>

84.71<= /p>

90.58

91.71

91.28

91.41

Cast cbc

81.23

86.99

88.62

<= font color=3D"#000000">89.10

aes-128 cbc

77.85

85.20

= 87.91=

18.27=

18.59

aes-192 cbc

65.98

72.70

15.53=

15.65=

Aes-256 c= bc

57.59

61.22

= 		=

= 62.43

133.67

134.40

Camellia-128

74.04

109.= 17

124.03

12.87

12.88

Camellia-192=

62.57

85.60

94.68

97.20=

98.11=

Camellia-= 256

62.58

85.63

= 		=

= 94.69

97.35

97.97

aes-128 ige

78.44

82.05

83.08

83.42

Aes-192 ige

66.25

69.13

69.75

<= font face=3D"Thorndale, serif">69.95<= /font>

69.94<= /p>

Aes-256 ige

57.69

59.71

60.22

60.40

60.27=

--001a114690586272ce0524b4a174-- --001a114690586272d30524b4a176 Content-Type: text/x-csrc; charset=UTF-8; name="HohhaDynamicXOR.c" Content-Disposition: attachment; filename="HohhaDynamicXOR.c" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ih2uwj7b0 LypCLgpIb2hoYSBEeW5hbWljIFhPUiBBbGdvcml0aG0uIENvcHlyaWdodCAoYykgMjAxNSDEsHNt YWlsIEtpemlyClBlcm1pc3Npb24gaXMgaGVyZWJ5IGdyYW50ZWQsIGZyZWUgb2YgY2hhcmdlLCB0 byBhbnkgcGVyc29uIG9idGFpbmluZyBhIGNvcHkgb2YgdGhpcyBzb2Z0d2FyZSAKYW5kIGFzc29j aWF0ZWQgZG9jdW1lbnRhdGlvbiBmaWxlcyAodGhlICJTb2Z0d2FyZSIpLCB0byBkZWFsIGluIHRo ZSBTb2Z0d2FyZSB3aXRob3V0IHJlc3RyaWN0aW9uLCAKaW5jbHVkaW5nIHdpdGhvdXQgbGltaXRh dGlvbiB0aGUgcmlnaHRzIHRvIHVzZSwgY29weSwgbW9kaWZ5LCBtZXJnZSwgcHVibGlzaCwgZGlz dHJpYnV0ZSwgc3VibGljZW5zZSwgCmFuZC9vciBzZWxsIGNvcGllcyBvZiB0aGUgU29mdHdhcmUs IGFuZCB0byBwZXJtaXQgcGVyc29ucyB0byB3aG9tIHRoZSBTb2Z0d2FyZSBpcyBmdXJuaXNoZWQg dG8gZG8gc28sIApzdWJqZWN0IHRvIHRoZSBmb2xsb3dpbmcgY29uZGl0aW9uczoKVGhlIGFib3Zl IGNvcHlyaWdodCBub3RpY2UgYW5kIHRoaXMgcGVybWlzc2lvbiBub3RpY2Ugc2hhbGwgYmUgaW5j bHVkZWQgaW4gYWxsIGNvcGllcyBvciBzdWJzdGFudGlhbCBwb3J0aW9ucyBvZiB0aGUgU29mdHdh cmUuClRIRSBTT0ZUV0FSRSBJUyBQUk9WSURFRCAiQVMgSVMiLCBXSVRIT1VUIFdBUlJBTlRZIE9G IEFOWSBLSU5ELCBFWFBSRVNTIE9SIElNUExJRUQsIElOQ0xVRElORyBCVVQgTk9UIExJTUlURUQg VE8gVEhFIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZLCBGSVRORVNTIEZPUiBBIFBBUlRJ Q1VMQVIgUFVSUE9TRSBBTkQgTk9OSU5GUklOR0VNRU5ULiBJTiBOTyBFVkVOVCBTSEFMTCBUSEUg QVVUSE9SUyBPUiBDT1BZUklHSFQgSE9MREVSUyBCRSBMSUFCTEUgRk9SIEFOWSBDTEFJTSwgREFN QUdFUyBPUiBPVEhFUiBMSUFCSUxJVFksIFdIRVRIRVIgSU4gQU4gQUNUSU9OIE9GIENPTlRSQUNU LCBUT1JUIE9SIE9USEVSV0lTRSwgQVJJU0lORyBGUk9NLCBPVVQgT0YgT1IgSU4gQ09OTkVDVElP TiBXSVRIIFRIRSBTT0ZUV0FSRSBPUiBUSEUgVVNFIE9SIE9USEVSIERFQUxJTkdTIElOIFRIRSBT T0ZUV0FSRS4KICovCiNpbmNsdWRlIDxzdGRpby5oPgojaW5jbHVkZSA8c3lzL3R5cGVzLmg+CiNp bmNsdWRlIDxmY250bC5oPgojaW5jbHVkZSA8ZXJybm8uaD4KI2luY2x1ZGUgPHRpbWUuaD4KI2lu Y2x1ZGUgPGN0eXBlLmg+CiNpbmNsdWRlIDxzdHJpbmcuaD4KI2luY2x1ZGUgPHN0ZGRlZi5oPgoj aW5jbHVkZSA8c3RkbGliLmg+CiNpbmNsdWRlIDxhc3NlcnQuaD4KI2luY2x1ZGUgPHN5cy90aW1l Lmg+CgojaW5jbHVkZSA8aW50dHlwZXMuaD4KI2luY2x1ZGUgPHN0cmluZy5oPgoKLyogLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBCQVNFNjQgRU5DT0RFL0RFQ09ERSBGVU5DVElPTlMgLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQogKi8KLyoKY2VuY29kZXIuYyAtIGMg c291cmNlIHRvIGEgYmFzZTY0IGVuY29kaW5nIGFsZ29yaXRobSBpbXBsZW1lbnRhdGlvbgoKVGhp cyBpcyBwYXJ0IG9mIHRoZSBsaWJiNjQgcHJvamVjdCwgYW5kIGhhcyBiZWVuIHBsYWNlZCBpbiB0 aGUgcHVibGljIGRvbWFpbi4KRm9yIGRldGFpbHMsIHNlZSBodHRwOi8vc291cmNlZm9yZ2UubmV0 L3Byb2plY3RzL2xpYmI2NAoqLwoKdHlwZWRlZiBlbnVtCnsKCXN0ZXBfQSwgc3RlcF9CLCBzdGVw X0MKfSBiYXNlNjRfZW5jb2Rlc3RlcDsKCnR5cGVkZWYgc3RydWN0CnsKCWJhc2U2NF9lbmNvZGVz dGVwIHN0ZXA7CgljaGFyIHJlc3VsdDsKCWludCBzdGVwY291bnQ7Cn0gYmFzZTY0X2VuY29kZXN0 YXRlOwp0eXBlZGVmIGVudW0KewoJc3RlcF9hLCBzdGVwX2IsIHN0ZXBfYywgc3RlcF9kCn0gYmFz ZTY0X2RlY29kZXN0ZXA7Cgp0eXBlZGVmIHN0cnVjdAp7CgliYXNlNjRfZGVjb2Rlc3RlcCBzdGVw OwoJY2hhciBwbGFpbmNoYXI7Cn0gYmFzZTY0X2RlY29kZXN0YXRlOwpjb25zdCBpbnQgQ0hBUlNf UEVSX0xJTkUgPSA3MjsKCnZvaWQgYmFzZTY0X2luaXRfZW5jb2Rlc3RhdGUoYmFzZTY0X2VuY29k ZXN0YXRlKiBzdGF0ZV9pbikKewoJc3RhdGVfaW4tPnN0ZXAgPSBzdGVwX0E7CglzdGF0ZV9pbi0+ cmVzdWx0ID0gMDsKCXN0YXRlX2luLT5zdGVwY291bnQgPSAwOwp9CgpjaGFyIGJhc2U2NF9lbmNv ZGVfdmFsdWUoY2hhciB2YWx1ZV9pbikKewoJc3RhdGljIGNvbnN0IGNoYXIqIGVuY29kaW5nID0g IkFCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFlaYWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXowMTIz NDU2Nzg5Ky8iOwoJaWYgKHZhbHVlX2luID4gNjMpIHJldHVybiAnPSc7CglyZXR1cm4gZW5jb2Rp bmdbKGludCl2YWx1ZV9pbl07Cn0KCmludCBiYXNlNjRfZW5jb2RlX2Jsb2NrKGNvbnN0IGNoYXIq IHBsYWludGV4dF9pbiwgaW50IGxlbmd0aF9pbiwgY2hhciogY29kZV9vdXQsIGJhc2U2NF9lbmNv ZGVzdGF0ZSogc3RhdGVfaW4pCnsKCWNvbnN0IGNoYXIqIHBsYWluY2hhciA9IHBsYWludGV4dF9p bjsKCWNvbnN0IGNoYXIqIGNvbnN0IHBsYWludGV4dGVuZCA9IHBsYWludGV4dF9pbiArIGxlbmd0 aF9pbjsKCWNoYXIqIGNvZGVjaGFyID0gY29kZV9vdXQ7CgljaGFyIHJlc3VsdDsKCWNoYXIgZnJh Z21lbnQ7CgkKCXJlc3VsdCA9IHN0YXRlX2luLT5yZXN1bHQ7CgkKCXN3aXRjaCAoc3RhdGVfaW4t PnN0ZXApCgl7CgkJd2hpbGUgKDEpCgkJewoJY2FzZSBzdGVwX0E6CgkJCWlmIChwbGFpbmNoYXIg PT0gcGxhaW50ZXh0ZW5kKQoJCQl7CgkJCQlzdGF0ZV9pbi0+cmVzdWx0ID0gcmVzdWx0OwoJCQkJ c3RhdGVfaW4tPnN0ZXAgPSBzdGVwX0E7CgkJCQlyZXR1cm4gY29kZWNoYXIgLSBjb2RlX291dDsK CQkJfQoJCQlmcmFnbWVudCA9ICpwbGFpbmNoYXIrKzsKCQkJcmVzdWx0ID0gKGZyYWdtZW50ICYg MHgwZmMpID4+IDI7CgkJCSpjb2RlY2hhcisrID0gYmFzZTY0X2VuY29kZV92YWx1ZShyZXN1bHQp OwoJCQlyZXN1bHQgPSAoZnJhZ21lbnQgJiAweDAwMykgPDwgNDsKCWNhc2Ugc3RlcF9COgoJCQlp ZiAocGxhaW5jaGFyID09IHBsYWludGV4dGVuZCkKCQkJewoJCQkJc3RhdGVfaW4tPnJlc3VsdCA9 IHJlc3VsdDsKCQkJCXN0YXRlX2luLT5zdGVwID0gc3RlcF9COwoJCQkJcmV0dXJuIGNvZGVjaGFy IC0gY29kZV9vdXQ7CgkJCX0KCQkJZnJhZ21lbnQgPSAqcGxhaW5jaGFyKys7CgkJCXJlc3VsdCB8 PSAoZnJhZ21lbnQgJiAweDBmMCkgPj4gNDsKCQkJKmNvZGVjaGFyKysgPSBiYXNlNjRfZW5jb2Rl X3ZhbHVlKHJlc3VsdCk7CgkJCXJlc3VsdCA9IChmcmFnbWVudCAmIDB4MDBmKSA8PCAyOwoJY2Fz ZSBzdGVwX0M6CgkJCWlmIChwbGFpbmNoYXIgPT0gcGxhaW50ZXh0ZW5kKQoJCQl7CgkJCQlzdGF0 ZV9pbi0+cmVzdWx0ID0gcmVzdWx0OwoJCQkJc3RhdGVfaW4tPnN0ZXAgPSBzdGVwX0M7CgkJCQly ZXR1cm4gY29kZWNoYXIgLSBjb2RlX291dDsKCQkJfQoJCQlmcmFnbWVudCA9ICpwbGFpbmNoYXIr KzsKCQkJcmVzdWx0IHw9IChmcmFnbWVudCAmIDB4MGMwKSA+PiA2OwoJCQkqY29kZWNoYXIrKyA9 IGJhc2U2NF9lbmNvZGVfdmFsdWUocmVzdWx0KTsKCQkJcmVzdWx0ICA9IChmcmFnbWVudCAmIDB4 MDNmKSA+PiAwOwoJCQkqY29kZWNoYXIrKyA9IGJhc2U2NF9lbmNvZGVfdmFsdWUocmVzdWx0KTsK CQkJCgkJCSsrKHN0YXRlX2luLT5zdGVwY291bnQpOwoJCQlpZiAoc3RhdGVfaW4tPnN0ZXBjb3Vu dCA9PSBDSEFSU19QRVJfTElORS80KQoJCQl7CgkJCQkvLypjb2RlY2hhcisrID0gJ1xuJzsKCQkJ CXN0YXRlX2luLT5zdGVwY291bnQgPSAwOwoJCQl9CgkJfQoJfQoJLyogY29udHJvbCBzaG91bGQg bm90IHJlYWNoIGhlcmUgKi8KCXJldHVybiBjb2RlY2hhciAtIGNvZGVfb3V0Owp9CgppbnQgYmFz ZTY0X2VuY29kZV9ibG9ja2VuZChjaGFyKiBjb2RlX291dCwgYmFzZTY0X2VuY29kZXN0YXRlKiBz dGF0ZV9pbikKewoJY2hhciogY29kZWNoYXIgPSBjb2RlX291dDsKCQoJc3dpdGNoIChzdGF0ZV9p bi0+c3RlcCkKCXsKCWNhc2Ugc3RlcF9COgoJCSpjb2RlY2hhcisrID0gYmFzZTY0X2VuY29kZV92 YWx1ZShzdGF0ZV9pbi0+cmVzdWx0KTsKCQkqY29kZWNoYXIrKyA9ICc9JzsKCQkqY29kZWNoYXIr KyA9ICc9JzsKCQlicmVhazsKCWNhc2Ugc3RlcF9DOgoJCSpjb2RlY2hhcisrID0gYmFzZTY0X2Vu Y29kZV92YWx1ZShzdGF0ZV9pbi0+cmVzdWx0KTsKCQkqY29kZWNoYXIrKyA9ICc9JzsKCQlicmVh azsKCWNhc2Ugc3RlcF9BOgoJCWJyZWFrOwoJfQoJLy8qY29kZWNoYXIrKyA9ICdcbic7CgkKCXJl dHVybiBjb2RlY2hhciAtIGNvZGVfb3V0Owp9CgppbnQgYmFzZTY0X2RlY29kZV92YWx1ZShjaGFy IHZhbHVlX2luKQp7CglzdGF0aWMgY29uc3QgY2hhciBkZWNvZGluZ1tdID0gezYyLC0xLC0xLC0x LDYzLDUyLDUzLDU0LDU1LDU2LDU3LDU4LDU5LDYwLDYxLC0xLC0xLC0xLC0yLC0xLC0xLC0xLDAs MSwyLDMsNCw1LDYsNyw4LDksMTAsMTEsMTIsMTMsMTQsMTUsMTYsMTcsMTgsMTksMjAsMjEsMjIs MjMsMjQsMjUsLTEsLTEsLTEsLTEsLTEsLTEsMjYsMjcsMjgsMjksMzAsMzEsMzIsMzMsMzQsMzUs MzYsMzcsMzgsMzksNDAsNDEsNDIsNDMsNDQsNDUsNDYsNDcsNDgsNDksNTAsNTF9OwoJc3RhdGlj IGNvbnN0IGNoYXIgZGVjb2Rpbmdfc2l6ZSA9IHNpemVvZihkZWNvZGluZyk7Cgl2YWx1ZV9pbiAt PSA0MzsKCWlmICh2YWx1ZV9pbiA8IDAgfHwgdmFsdWVfaW4gPj0gZGVjb2Rpbmdfc2l6ZSkgcmV0 dXJuIC0xOwoJcmV0dXJuIGRlY29kaW5nWyhpbnQpdmFsdWVfaW5dOwp9Cgp2b2lkIGJhc2U2NF9p bml0X2RlY29kZXN0YXRlKGJhc2U2NF9kZWNvZGVzdGF0ZSogc3RhdGVfaW4pCnsKCXN0YXRlX2lu LT5zdGVwID0gc3RlcF9hOwoJc3RhdGVfaW4tPnBsYWluY2hhciA9IDA7Cn0KCmludCBiYXNlNjRf ZGVjb2RlX2Jsb2NrKGNvbnN0IGNoYXIqIGNvZGVfaW4sIGNvbnN0IGludCBsZW5ndGhfaW4sIGNo YXIqIHBsYWludGV4dF9vdXQsIGJhc2U2NF9kZWNvZGVzdGF0ZSogc3RhdGVfaW4pCnsKCWNvbnN0 IGNoYXIqIGNvZGVjaGFyID0gY29kZV9pbjsKCWNoYXIqIHBsYWluY2hhciA9IHBsYWludGV4dF9v dXQ7CgljaGFyIGZyYWdtZW50OwoJCgkqcGxhaW5jaGFyID0gc3RhdGVfaW4tPnBsYWluY2hhcjsK CQoJc3dpdGNoIChzdGF0ZV9pbi0+c3RlcCkKCXsKCQl3aGlsZSAoMSkKCQl7CgljYXNlIHN0ZXBf YToKCQkJZG8gewoJCQkJaWYgKGNvZGVjaGFyID09IGNvZGVfaW4rbGVuZ3RoX2luKQoJCQkJewoJ CQkJCXN0YXRlX2luLT5zdGVwID0gc3RlcF9hOwoJCQkJCXN0YXRlX2luLT5wbGFpbmNoYXIgPSAq cGxhaW5jaGFyOwoJCQkJCXJldHVybiBwbGFpbmNoYXIgLSBwbGFpbnRleHRfb3V0OwoJCQkJfQoJ CQkJZnJhZ21lbnQgPSAoY2hhciliYXNlNjRfZGVjb2RlX3ZhbHVlKCpjb2RlY2hhcisrKTsKCQkJ fSB3aGlsZSAoZnJhZ21lbnQgPCAwKTsKCQkJKnBsYWluY2hhciAgICA9IChmcmFnbWVudCAmIDB4 MDNmKSA8PCAyOwoJY2FzZSBzdGVwX2I6CgkJCWRvIHsKCQkJCWlmIChjb2RlY2hhciA9PSBjb2Rl X2luK2xlbmd0aF9pbikKCQkJCXsKCQkJCQlzdGF0ZV9pbi0+c3RlcCA9IHN0ZXBfYjsKCQkJCQlz dGF0ZV9pbi0+cGxhaW5jaGFyID0gKnBsYWluY2hhcjsKCQkJCQlyZXR1cm4gcGxhaW5jaGFyIC0g cGxhaW50ZXh0X291dDsKCQkJCX0KCQkJCWZyYWdtZW50ID0gKGNoYXIpYmFzZTY0X2RlY29kZV92 YWx1ZSgqY29kZWNoYXIrKyk7CgkJCX0gd2hpbGUgKGZyYWdtZW50IDwgMCk7CgkJCSpwbGFpbmNo YXIrKyB8PSAoZnJhZ21lbnQgJiAweDAzMCkgPj4gNDsKCQkJKnBsYWluY2hhciAgICA9IChmcmFn bWVudCAmIDB4MDBmKSA8PCA0OwoJY2FzZSBzdGVwX2M6CgkJCWRvIHsKCQkJCWlmIChjb2RlY2hh ciA9PSBjb2RlX2luK2xlbmd0aF9pbikKCQkJCXsKCQkJCQlzdGF0ZV9pbi0+c3RlcCA9IHN0ZXBf YzsKCQkJCQlzdGF0ZV9pbi0+cGxhaW5jaGFyID0gKnBsYWluY2hhcjsKCQkJCQlyZXR1cm4gcGxh aW5jaGFyIC0gcGxhaW50ZXh0X291dDsKCQkJCX0KCQkJCWZyYWdtZW50ID0gKGNoYXIpYmFzZTY0 X2RlY29kZV92YWx1ZSgqY29kZWNoYXIrKyk7CgkJCX0gd2hpbGUgKGZyYWdtZW50IDwgMCk7CgkJ CSpwbGFpbmNoYXIrKyB8PSAoZnJhZ21lbnQgJiAweDAzYykgPj4gMjsKCQkJKnBsYWluY2hhciAg ICA9IChmcmFnbWVudCAmIDB4MDAzKSA8PCA2OwoJY2FzZSBzdGVwX2Q6CgkJCWRvIHsKCQkJCWlm IChjb2RlY2hhciA9PSBjb2RlX2luK2xlbmd0aF9pbikKCQkJCXsKCQkJCQlzdGF0ZV9pbi0+c3Rl cCA9IHN0ZXBfZDsKCQkJCQlzdGF0ZV9pbi0+cGxhaW5jaGFyID0gKnBsYWluY2hhcjsKCQkJCQly ZXR1cm4gcGxhaW5jaGFyIC0gcGxhaW50ZXh0X291dDsKCQkJCX0KCQkJCWZyYWdtZW50ID0gKGNo YXIpYmFzZTY0X2RlY29kZV92YWx1ZSgqY29kZWNoYXIrKyk7CgkJCX0gd2hpbGUgKGZyYWdtZW50 IDwgMCk7CgkJCSpwbGFpbmNoYXIrKyAgIHw9IChmcmFnbWVudCAmIDB4MDNmKTsKCQl9Cgl9Cgkv KiBjb250cm9sIHNob3VsZCBub3QgcmVhY2ggaGVyZSAqLwoJcmV0dXJuIHBsYWluY2hhciAtIHBs YWludGV4dF9vdXQ7Cn0KCgpjaGFyICpCYXNlNjRFbmNvZGUoY29uc3QgY2hhciogaW5wdXQsIHVp bnQzMl90IGlucHV0bGVuKQp7CiAgLyogc2V0IHVwIGEgZGVzdGluYXRpb24gYnVmZmVyIGxhcmdl IGVub3VnaCB0byBob2xkIHRoZSBlbmNvZGVkIGRhdGEgKi8KICBjaGFyKiBvdXRwdXQgPSAoY2hh ciopbWFsbG9jKDggKyAoaW5wdXRsZW4gKiA0KS8zKTsKICAvKiBrZWVwIHRyYWNrIG9mIG91ciBl bmNvZGVkIHBvc2l0aW9uICovCiAgY2hhciogYyA9IG91dHB1dDsKICAvKiBzdG9yZSB0aGUgbnVt YmVyIG9mIGJ5dGVzIGVuY29kZWQgYnkgYSBzaW5nbGUgY2FsbCAqLwogIGludCBjbnQgPSAwOwog IC8qIHdlIG5lZWQgYW4gZW5jb2RlciBzdGF0ZSAqLwogIGJhc2U2NF9lbmNvZGVzdGF0ZSBzOwoK ICAvKi0tLS0tLS0tLS0gU1RBUlQgRU5DT0RJTkcgLS0tLS0tLS0tLSovCiAgLyogaW5pdGlhbGlz ZSB0aGUgZW5jb2RlciBzdGF0ZSAqLwogIGJhc2U2NF9pbml0X2VuY29kZXN0YXRlKCZzKTsKICAv KiBnYXRoZXIgZGF0YSBmcm9tIHRoZSBpbnB1dCBhbmQgc2VuZCBpdCB0byB0aGUgb3V0cHV0ICov CiAgY250ID0gYmFzZTY0X2VuY29kZV9ibG9jayhpbnB1dCwgaW5wdXRsZW4sIGMsICZzKTsKICBj ICs9IGNudDsKICAvKiBzaW5jZSB3ZSBoYXZlIGVuY29kZWQgdGhlIGVudGlyZSBpbnB1dCBzdHJp bmcsIHdlIGtub3cgdGhhdCAKICAgICB0aGVyZSBpcyBubyBtb3JlIGlucHV0IGRhdGE7IGZpbmFs aXNlIHRoZSBlbmNvZGluZyAqLwogIGNudCA9IGJhc2U2NF9lbmNvZGVfYmxvY2tlbmQoYywgJnMp OwogIGMgKz0gY250OwogIC8qLS0tLS0tLS0tLSBTVE9QIEVOQ09ESU5HICAtLS0tLS0tLS0tKi8K CiAgLyogd2Ugd2FudCB0byBwcmludCB0aGUgZW5jb2RlZCBkYXRhLCBzbyBudWxsLXRlcm1pbmF0 ZSBpdDogKi8KICAqYyA9IDA7CgogIHJldHVybiBvdXRwdXQ7Cn0KCmNoYXIgKkJhc2U2NERlY29k ZShjb25zdCBjaGFyKiBpbnB1dCkKewogIC8qIHNldCB1cCBhIGRlc3RpbmF0aW9uIGJ1ZmZlciBs YXJnZSBlbm91Z2ggdG8gaG9sZCB0aGUgZW5jb2RlZCBkYXRhICovCiAgdW5zaWduZWQgaWxlbiA9 IHN0cmxlbihpbnB1dCk7CiAgY2hhciogb3V0cHV0ID0gKGNoYXIqKW1hbGxvYyhpbGVuKTsKICAv KiBrZWVwIHRyYWNrIG9mIG91ciBkZWNvZGVkIHBvc2l0aW9uICovCiAgY2hhciogYyA9IG91dHB1 dDsKICAvKiBzdG9yZSB0aGUgbnVtYmVyIG9mIGJ5dGVzIGRlY29kZWQgYnkgYSBzaW5nbGUgY2Fs bCAqLwogIGludCBjbnQgPSAwOwogIC8qIHdlIG5lZWQgYSBkZWNvZGVyIHN0YXRlICovCiAgYmFz ZTY0X2RlY29kZXN0YXRlIHM7CgogIC8qLS0tLS0tLS0tLSBTVEFSVCBERUNPRElORyAtLS0tLS0t LS0tKi8KICAvKiBpbml0aWFsaXNlIHRoZSBkZWNvZGVyIHN0YXRlICovCiAgYmFzZTY0X2luaXRf ZGVjb2Rlc3RhdGUoJnMpOwogIC8qIGRlY29kZSB0aGUgaW5wdXQgZGF0YSAqLwogIGNudCA9IGJh c2U2NF9kZWNvZGVfYmxvY2soaW5wdXQsIGlsZW4sIGMsICZzKTsKICBjICs9IGNudDsKICAvKiBu b3RlOiB0aGVyZSBpcyBubyBiYXNlNjRfZGVjb2RlX2Jsb2NrZW5kISAqLwogIC8qLS0tLS0tLS0t LSBTVE9QIERFQ09ESU5HICAtLS0tLS0tLS0tKi8KCiAgLyogd2Ugd2FudCB0byBwcmludCB0aGUg ZGVjb2RlZCBkYXRhLCBzbyBudWxsLXRlcm1pbmF0ZSBpdDogKi8KICAqYyA9IDA7CgogIHJldHVy biBvdXRwdXQ7Cn0KCgovKiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIEJBU0U2NCBFTkNP REUvREVDT0RFIEZVTkNUSU9OUyBFTkRTIEhFUkUgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQogKi8KCi8qIC0tLS0tLS0tLS0tLS0tLS0gdXRpbGl0eSBmbmNzICovCnVpbnQz Ml90IEdldEVsYXBzZWRUaW1lSW5NaWxsaVNlY29uZHMoc3RydWN0IHRpbWV2YWwgKlN0YXJ0VGlt ZSkKewogIHN0cnVjdCB0aW1ldmFsIE5vdzsKCiAgZ2V0dGltZW9mZGF5ICgmTm93LCBOVUxMKTsg CiAgcmV0dXJuIChOb3cudHZfc2VjIC0gU3RhcnRUaW1lLT50dl9zZWMpICogMTAwMCArIChOb3cu dHZfdXNlYyAtIFN0YXJ0VGltZS0+dHZfdXNlYykgLyAxMDAwOwp9CmRvdWJsZSBQcmludEVsYXBz ZWRUaW1lKHN0cnVjdCB0aW1ldmFsICpTdGFydFRpbWUsIHVuc2lnbmVkIGxvbmcgbG9uZyBpbnQg VG90YWxQcm9jZXNzZWRCeXRlcykKewogIGRvdWJsZSBUb3RhbE1CeXRlcyA9ICgoZG91YmxlKVRv dGFsUHJvY2Vzc2VkQnl0ZXMvKDEwMjQuMCoxMDI0KSk7IAogIHVuc2lnbmVkIEVJbk1zID0gR2V0 RWxhcHNlZFRpbWVJbk1pbGxpU2Vjb25kcyhTdGFydFRpbWUpOwogIGRvdWJsZSBBdmVyYWdlID0g VG90YWxNQnl0ZXMgLyAoMS4wICogRUluTXMpICogMTAwMC4wOwogIHByaW50ZigiXG5cdFRvdGFs IGRhdGEgcHJvY2Vzc2VkOiAlNi4yZiBNQnl0ZXNcblx0RWxhcHNlZCBUaW1lOiAldSBtcy5cblx0 QXZlcmFnZTogJTEwLjRmIE1CeXRlcy9zZWNzIFxuIixUb3RhbE1CeXRlcywgRUluTXMsIEF2ZXJh Z2UpOwogIHJldHVybiBBdmVyYWdlOwp9Cgp2b2lkIEluY0J5T25lKHVpbnQ4X3QgKkJ1ZiwgdWlu dDMyX3QgQnVmTGVuKQp7CiAgdW5zaWduZWQgdDsKICBmb3IgKHQ9MDsgdDxCdWZMZW47IHQrKykK ICAgIEJ1Zlt0XSsrOwp9CnVpbnQ4X3QgKkNyZWF0ZURhdGFCdWYoU2l6ZSkKewogIHJldHVybiAo dWludDhfdCAqKWNhbGxvYygxLCBTaXplKTsKfQoKLyogLS0tLS0tLS0tLS0tLS0tLSBlbmQgdXRp bGl0eSBmbmNzICovCgoKCiNkZWZpbmUgU0FMVF9TSVpFIDQgLy8gCiNkZWZpbmUgTUFYX05VTV9K VU1QUyA2NAojZGVmaW5lIEZBTFNFICgwVSkKI2RlZmluZSBUUlVFICghKEZBTFNFKSkKI2RlZmlu ZSBWRVJCT1NFCi8vI2RlZmluZSBPVkVSTFlfVkVSQk9TRQojZGVmaW5lIFJBTkRPTV9CVUZfU0la RSA4MTkyCnVpbnQ4X3QgUmFuZG9tQnVmW1JBTkRPTV9CVUZfU0laRV07Cgp1aW50MzJfdCBSYW5k b21CdWZTdGFydFBvcz05OTk5OTk5OTk7IC8vIEl0IG11c3QgYmUgYSBudW1iZXIgZ3JlYXRlciB0 aGFuIFJBTkRPTV9CVUZfU0laRSBmb3IgaW5pdGlhbGl6YXRpb24KCnZvaWQgUmVhZFJhbmRvbUJ5 dGVzRnJvbVVERXYodWludDMyX3QgQnl0ZUNvdW50LCB1aW50OF90ICpCdWZmZXIpCnsKICBGSUxF ICpmcDsKICAKICBmcCA9IGZvcGVuKCIvZGV2L3VyYW5kb20iLCAiciIpOwogIGlmICghZnApCiAg ewogICAgZnByaW50ZihzdGRlcnIsICJcblxuRVJST1IgT1BFTklORyAvZGV2L3VyYW5kb20hISEh XG5cbiIpOwogICAgZXhpdCgtMSk7CiAgfQogIAogIGZyZWFkKEJ1ZmZlciwgQnl0ZUNvdW50LCAx LCBmcCk7CiAgZmNsb3NlKGZwKTsKfQp2b2lkIFJhbmRvbWl6ZUJ1ZmZlcigpCnsKI2lmZGVmIFZF UkJPU0UKICBwcmludGYoIlJhbmRvbWl6aW5nIC4uLiBcbiIpOwojZW5kaWYKICBSYW5kb21CdWZT dGFydFBvcz0wOwogIFJlYWRSYW5kb21CeXRlc0Zyb21VREV2KFJBTkRPTV9CVUZfU0laRSwgUmFu ZG9tQnVmKTsKICAKI2lmZGVmIE9WRVJMWV9WRVJCT1NFCiAgaW50IHQ7CiAgZm9yICh0PTA7IHQ8 UkFORE9NX0JVRl9TSVpFOyB0KyspCiAgICBwcmludGYoIiV1ICIsUmFuZG9tQnVmW3RdKTsKICBw cmludGYoIlxuXG4iKTsKI2VuZGlmCn0KCnZvaWQgR2V0UmFuZG9tTnVtYmVycyh1aW50MzJfdCBC eXRlQ291bnQsIHVpbnQ4X3QgKkJ1ZmZlcikKewogIGlmIChSQU5ET01fQlVGX1NJWkUgPCBCeXRl Q291bnQpCiAgewogICAgUmVhZFJhbmRvbUJ5dGVzRnJvbVVERXYoQnl0ZUNvdW50LCBCdWZmZXIp OwogICAgcmV0dXJuOwogIH0KICBpZiAoUkFORE9NX0JVRl9TSVpFIDwgUmFuZG9tQnVmU3RhcnRQ b3MrQnl0ZUNvdW50KQogICAgUmFuZG9taXplQnVmZmVyKCk7CiAgaWYgKEJ5dGVDb3VudCA9PSAx KQogIHsKICAgIEJ1ZmZlclswXSA9IFJhbmRvbUJ1ZltSYW5kb21CdWZTdGFydFBvcysrXTsKICAg IHJldHVybjsKICB9CiAgbWVtY3B5KEJ1ZmZlciwgUmFuZG9tQnVmICsgUmFuZG9tQnVmU3RhcnRQ b3MsIEJ5dGVDb3VudCk7CiAgUmFuZG9tQnVmU3RhcnRQb3MgKz0gQnl0ZUNvdW50Owp9CnVpbnQ4 X3QgR2V0UmFuZG9tVUludDgodm9pZCkKewogIGlmIChSYW5kb21CdWZTdGFydFBvcyA+PSBSQU5E T01fQlVGX1NJWkUpCiAgICBSYW5kb21pemVCdWZmZXIoKTsKICByZXR1cm4gUmFuZG9tQnVmW1Jh bmRvbUJ1ZlN0YXJ0UG9zKytdOwp9CgoKLyogRnVuY3Rpb24gdXNlZCB0byBkZXRlcm1pbmUgaWYg ViBpcyB1bmlxdWUgYW1vbmcgdGhlIGZpcnN0IFBvcyBlbGVtZW50cwogKiBVc2VkIGJ5IHRoZSB4 b3JHZXRLZXkgZnVuY3Rpb24gdG8gY2hlY2sgcGFydGljbGUgbGVuZ3RoIHVuaXF1ZW5lc3MKICov CiNkZWZpbmUgTUFYX0JPRFlfU0laRSAxMDI0CgojZGVmaW5lIFNQX05VTV9KVU1QUyAwCiNkZWZp bmUgU1BfQk9EWV9MRU4gMQojZGVmaW5lIFNQX1NBTFRfREFUQSAzCiNkZWZpbmUgU1BfQk9EWSA3 CiNkZWZpbmUgR2V0Qm9keUxlbihLKSAoS1tTUF9CT0RZX0xFTl0gKyAyNTYgKiBLW1NQX0JPRFlf TEVOKzFdKQojZGVmaW5lIEdldEJvZHlQdHIoSykgKEsgKyBTUF9CT0RZKQojZGVmaW5lIEdldE51 bUp1bXBzKEspIChLW1NQX05VTV9KVU1QU10pCiNkZWZpbmUgeG9yQ29tcHV0ZUtleUJ1ZkxlbihC b2R5TGVuKSAoU1BfQk9EWStCb2R5TGVuKQoKLy8gQ3JlYXRlcyBYT1Iga2V5Ci8vIFRoZSBmaXJz dCBieXRlIHdpbGwgYmUgZXF1YWwgdG8gTnVtSnVtcHMKLy8gRm9sbG93aW5nIDIgYnl0ZXMgaXMg a2V5IGJvZHkgbGVuZ3RoCi8vIEZvbGxvd2luZyA0IGJ5dGVzIGFyZSByYW5kb20gc2FsdCBkYXRh Ci8vIEZvbGxvd2luZyBCb2R5TGVuIGJ5dGVzIGFyZSByYW5kb20gbnVtYmVycyBvYnRhaW5lZCBm cm9tIGJ1ZmZlcmVkIC9kZXYvdXJhbmRvbSBkYXRhLiBCT0RZTEVOIE1VU1QgQkUgQSBQT1dFUiBP RiAyIQovLyBSZXN1bHQgYnVmZmVyIG11c3QgYmUgZW5vdWdoIHRvIHN0b3JlIGtleSEhIE5vIGVy cm9yIGNoZWNraW5nIGlzIGRvbmUhISEKdm9pZCB4b3JHZXRLZXkodWludDhfdCBOdW1KdW1wcywg dWludDMyX3QgQm9keUxlbiwgdWludDhfdCAqS2V5QnVmKQp7CiAgYXNzZXJ0KE51bUp1bXBzID4g MSAmJiBCb2R5TGVuID4gMTUgJiYgTnVtSnVtcHM8TUFYX05VTV9KVU1QUyAmJiAoKEJvZHlMZW4t MSkmQm9keUxlbikgPT0gMCk7CiAgCiNpZmRlZiBWRVJCT1NFCiAgcHJpbnRmKCJHZW5lcmF0aW5n IGtleSAuLi4gQm9keUxlbjogJXUgTnVtSnVtcHM6ICV1XG4iLEJvZHlMZW4sTnVtSnVtcHMpOwoj ZW5kaWYKICBLZXlCdWZbU1BfTlVNX0pVTVBTXSA9ICh1aW50OF90KShOdW1KdW1wcyYyNTUpOwog IEtleUJ1ZltTUF9CT0RZX0xFTl0gPSAodWludDhfdCkoKEJvZHlMZW4gJSAyNTYpICYgMHhmZik7 CiAgS2V5QnVmW1NQX0JPRFlfTEVOKzFdID0gKHVpbnQ4X3QpKChCb2R5TGVuIC8gMjU2KSAmIDB4 ZmYpOwogIEdldFJhbmRvbU51bWJlcnMoU0FMVF9TSVpFICsgQm9keUxlbiwgS2V5QnVmICsgU1Bf U0FMVF9EQVRBKTsgLy8gRmlsbCA0IGJ5dGVzIHNhbHQgZGF0YSB3aXRoIHJhbmRvbSBudW1iZXJz Cn0KCnZvaWQgeG9yQW5hbHl6ZUtleSh1aW50OF90ICpLKQp7CiAgdWludDMyX3QgdDsKICAKICBw cmludGYoIi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIFNoaWZ0aW5nIHhvciBrZXkgYW5hbHl6 ZSAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tXG5OdW1KdW1wczogJXVcbkJvZHlMZW46ICV1 IG5TYWx0OiAiLCAKICAgICAgICAgS1swXSwgR2V0Qm9keUxlbihLKSk7CiAgZm9yICh0PTA7IHQg PCBTQUxUX1NJWkU7IHQrKykKICB7CiAgICBwcmludGYoIiAldSIsIEtbU1BfU0FMVF9EQVRBK3Rd KTsKICB9CiAgcHJpbnRmKCJcbiIpOwp9CgovLyBTdGFuZGFydCBDIGhhcyBub3QgUk9MIG9yIFJP UiBmdW5jdGlvbiwgYnV0IG1vc3QgbW9kZXJuIGNwdXMgaGFzIGluc3RydWN0aW9ucyBmb3IgY2ly Y3VsYXIgc2hpZnQgb3BlcmF0aW9ucwovLyBUaGlzIGlzIGEgcXVpY2sgYW5kIGRpcnR5IGNvZGUg Zm9yIHN0YW5kYXJ0IEMgdmVyc2lvbnMgYW5kIEludGVsIEZhbWlseSBjcHUgYXNzZW1ibGVyIG9w dGltaXplZCB2ZXJzaW9ucwoKI2RlZmluZSBHQ0NfSU5URUxfT1BUSU1JWkVEIAoKc3RhdGljIGlu bGluZSBpbnQgUk9MMzJfMShpbnQgdikgCnsKICAjaWYgZGVmaW5lZChfX0dOVUNfXykgIAogICAg I2lmIGRlZmluZWQoR0NDX0lOVEVMX09QVElNSVpFRCkKICAgICAgYXNtICgicm9sICUwOyIgOiI9 ciIodikgLyogb3V0cHV0ICovIDoiMCIodikgLyogaW5wdXQgKi8gKTsKICAgICAgcmV0dXJuIHY7 CiAgICAjZWxzZSAKICAgICAgcmV0dXJuICgoKHYpIDw8IDEpIHwgKCh2KSA+PiAzMSkpOwogICAg I2VuZGlmCiAgI2VuZGlmCn0Kc3RhdGljIGlubGluZSBpbnQgUk9SMzJfMShpbnQgdikgewogICNp ZiBkZWZpbmVkKF9fR05VQ19fKSAgCiAgICAjaWYgZGVmaW5lZChHQ0NfSU5URUxfT1BUSU1JWkVE KQogICAgICBhc20gKCJyb3IgJTA7IiA6Ij1yIih2KSAvKiBvdXRwdXQgKi8gOiIwIih2KSAvKiBp bnB1dCAqLyApOwogICAgICByZXR1cm4gdjsKICAgICNlbHNlIAogICAgICByZXR1cm4gKCgodikg Pj4gMSkgfCAoKHYpIDw8IDMxKSkKICAgICNlbmRpZgogICNlbmRpZgp9Ci8qIFVOT1BUSU1JWkVE IFZFUlNJT04gZm9yIEJFVFRFUiBVTkRFUlNUQU5ESU5HIE9GIFRIRSBGVU5DVElPTklORyBPRiBU SEUgQUxHT1JJVEhNLiBJVCBJUyBOT1QgVVNFRCBJTiBSRUFMIExJRkUuIFVTRSBPUFRJTUlaRUQg VkVSU0lPTlMhCiAqIEVuY3J5cHRzIG9yIGRlY3J5cHRzIEluT3V0QnVmIAogKiBLZXlCdWYgaXMg dGhlIHJhdyBrZXkgYnVmZmVyCiAqIEtleUNoZWNrU3VtIGlzIHRoZSBzdW0gb2YgYWxsIGtleSBj b25zdGl0dWVudHMqMy4gSElHSCBCSVQgTVVTVCBCRSBTRVQhIAogKiAgIFVzZWQgdG8gcHJldmVu dCAiUmVsYXRlZCBrZXkgYXR0YWNrcyIuIElmIHNvbWUgYml0cyBvZiB0aGUga2V5IGNoYW5nZXMs IGVudGlyZSBjeXBoZXJ0ZXh0IGNoYW5nZXMKICogSW5PdXREYXRhTGVuIGlzIHRoZSBsZW5ndGgg b2YgdGhlIGRhdGEgdG8gYmUgZW5jcnlwdGVkIG9yIGRlY3J5cHRlZAogKiBJbk91dEJ1ZiBpcyB0 aGUgcG9pbnRlciB0byB0aGUgZGF0YSB0byBiZSBlbmNyeXB0ZWQgb3IgZGVjcnlwdGVkCiAqIEFm dGVyIGV2ZXJ5IGVuY3J5cHRpb24gb3IgZGVjcnlwdGlvbiwgdGhlIHZhbHVlIG9mIHNhbHQgd2ls bCBiZSBzZXQgdG8gdGhlIG9yaWdpbmFsIG9uZQogKiBTbywgYmVmb3JlIGVuY3J5cHRpb24gb3Ig ZGVjcnlwdGlvbiwgaWYgeW91IHdhbnQgdG8gdXNlIGEgc3BlY2lmaWMgc2FsdCB2YWx1ZSwgYXNz aWduIHRoYXQgdG8gSydzIFNhbHQgdmFsdWUuIEVuYyBvciBEZWMgd2lsbCBiZSBkb25lIHdpdGgg dGhhdCB2YWx1ZQogKiBhbmQgYXQgdGhlIGVuZCBvZiB0aGUgZnVuY3Rpb24sIHRoZSBzYWx0IHZh bHVlIHdpbGwgYmUgc2V0IGJhY2sgdG8gaXRzIG9yaWdpbmFsIHN0YXRlCiAqIFRoaXMgbG9naWMg ZW5zdXJlcyB1cyB0aGlzOiBBbiBvcmlnaW5hbCBrZXkgaXMgY3JlYXRlZCB3aXRoIGFuIG9yaWdp bmFsIHNhbHQgdmFsdWUsIGZvciBleGFtcGxlIGZvciBhbiBvbmxpbmUgY29tbXVuaWNhdGlvbgog KiBmb3IgZWFjaCBkaXN0aW5jdCBwYWNrZXQsIGluIHRoZSBwYWNrZXQgaGVhZGVyLCB3ZSBjYW4g dHJhbnNtaXQgYSBzcGVjaWZpYyBzYWx0IHZhbHVlIGZvciB0aGF0IHBhY2tldCBhbmQgd2UgY2Fu IGVuY3J5cHQgaXQgd2l0aCBvcmlnaW5hbCBrZXkgYW5kIHNhbHQKICogd2hlbiB0aGUgcmVjZWl2 ZXIgcmVjZWl2ZXMgdGhlIHBhY2tldCwgZGVjcnlwdHMgdGhlIG5ldyBzYWx0IHZhbHVlIHdpdGgg dGhlIG9yaWdpbmFsIHNhbHQgdmFsdWUsIHNldCB0aGF0IHNhbHQgdmFsdWUgYXMgdGhlIG5ldyBz YWx0IHZhbHVlCiAqIGFuZCBkZWNyeXB0cyB0aGUgcGFja2V0IGJvZHkgd2l0aCB0aGF0IHNhbHQg dmFsdWUKICovCgojZGVmaW5lIE1ha2VYT1JFbmMoSW5PdXRCdWYsWE9SVmFsLFNhbHQsS2V5Q2hl Y2tTdW0sUGxhaW5UZXh0Q2hlY2tzdW0sTGFzdFZhbCxUbXBWYWwsQ291bnRlcilcClBsYWluVGV4 dENoZWNrc3VtICs9IEluT3V0QnVmW0NvdW50ZXJdOyBcClRtcFZhbCA9IEluT3V0QnVmW0NvdW50 ZXJdOyBcClhPUlZhbCBePSBMYXN0VmFsOyBcClhPUlZhbCBePSAqKFNhbHQgKyAoTGFzdFZhbCYo U0FMVF9TSVpFLTEpKSk7IFwKSW5PdXRCdWZbQ291bnRlcl0gXj0gKCh1aW50OF90KShYT1JWYWwp KTsgXApMYXN0VmFsID0gVG1wVmFsOyAKCiNkZWZpbmUgTWFrZVhPUkRlYyhJbk91dEJ1ZixYT1JW YWwsU2FsdCxLZXlDaGVja1N1bSxQbGFpblRleHRDaGVja3N1bSxMYXN0VmFsLENvdW50ZXIpXApY T1JWYWwgXj0gTGFzdFZhbDsgXApYT1JWYWwgXj0gKihTYWx0ICsgKExhc3RWYWwmKFNBTFRfU0la RS0xKSkpOyBcCkluT3V0QnVmW0NvdW50ZXJdIF49ICgodWludDhfdCkoWE9SVmFsKSk7IFwKTGFz dFZhbCA9IEluT3V0QnVmW0NvdW50ZXJdOyBcClBsYWluVGV4dENoZWNrc3VtICs9IExhc3RWYWw7 IAoKLy9TYWx0W0NvdW50ZXImU0FMVF9TSVpFXSsrOyBYT1JWYWwgXj0gKEtleUNoZWNrU3VtIF4g U2FsdFtDb3VudGVyJlNBTFRfU0laRV0pOyAKLyogOC1iaXQgQ1JDIHdpdGggcG9seW5vbWlhbCB4 XjgreF42K3heMyt4XjIrMSwgMHgxNEQuCiAgIENob3NlbiBiYXNlZCBvbiBLb29wbWFuLCBldCBh bC4gKDB4QTYgaW4gaGlzIG5vdGF0aW9uID0gMHgxNEQgPj4gMSk6CiAgIGh0dHA6Ly93d3cuZWNl LmNtdS5lZHUvfmtvb3BtYW4vcm9zZXMvZHNuMDQva29vcG1hbjA0X2NyY19wb2x5X2VtYmVkZGVk LnBkZgogKi8KCgpzdGF0aWMgdWludDhfdCBjcmM4X3RhYmxlW10gPSB7CiAgICAweDAwLCAweDNl LCAweDdjLCAweDQyLCAweGY4LCAweGM2LCAweDg0LCAweGJhLCAweDk1LCAweGFiLCAweGU5LCAw eGQ3LAogICAgMHg2ZCwgMHg1MywgMHgxMSwgMHgyZiwgMHg0ZiwgMHg3MSwgMHgzMywgMHgwZCwg MHhiNywgMHg4OSwgMHhjYiwgMHhmNSwKICAgIDB4ZGEsIDB4ZTQsIDB4YTYsIDB4OTgsIDB4MjIs IDB4MWMsIDB4NWUsIDB4NjAsIDB4OWUsIDB4YTAsIDB4ZTIsIDB4ZGMsCiAgICAweDY2LCAweDU4 LCAweDFhLCAweDI0LCAweDBiLCAweDM1LCAweDc3LCAweDQ5LCAweGYzLCAweGNkLCAweDhmLCAw eGIxLAogICAgMHhkMSwgMHhlZiwgMHhhZCwgMHg5MywgMHgyOSwgMHgxNywgMHg1NSwgMHg2Yiwg MHg0NCwgMHg3YSwgMHgzOCwgMHgwNiwKICAgIDB4YmMsIDB4ODIsIDB4YzAsIDB4ZmUsIDB4NTks IDB4NjcsIDB4MjUsIDB4MWIsIDB4YTEsIDB4OWYsIDB4ZGQsIDB4ZTMsCiAgICAweGNjLCAweGYy LCAweGIwLCAweDhlLCAweDM0LCAweDBhLCAweDQ4LCAweDc2LCAweDE2LCAweDI4LCAweDZhLCAw eDU0LAogICAgMHhlZSwgMHhkMCwgMHg5MiwgMHhhYywgMHg4MywgMHhiZCwgMHhmZiwgMHhjMSwg MHg3YiwgMHg0NSwgMHgwNywgMHgzOSwKICAgIDB4YzcsIDB4ZjksIDB4YmIsIDB4ODUsIDB4M2Ys IDB4MDEsIDB4NDMsIDB4N2QsIDB4NTIsIDB4NmMsIDB4MmUsIDB4MTAsCiAgICAweGFhLCAweDk0 LCAweGQ2LCAweGU4LCAweDg4LCAweGI2LCAweGY0LCAweGNhLCAweDcwLCAweDRlLCAweDBjLCAw eDMyLAogICAgMHgxZCwgMHgyMywgMHg2MSwgMHg1ZiwgMHhlNSwgMHhkYiwgMHg5OSwgMHhhNywg MHhiMiwgMHg4YywgMHhjZSwgMHhmMCwKICAgIDB4NGEsIDB4NzQsIDB4MzYsIDB4MDgsIDB4Mjcs IDB4MTksIDB4NWIsIDB4NjUsIDB4ZGYsIDB4ZTEsIDB4YTMsIDB4OWQsCiAgICAweGZkLCAweGMz LCAweDgxLCAweGJmLCAweDA1LCAweDNiLCAweDc5LCAweDQ3LCAweDY4LCAweDU2LCAweDE0LCAw eDJhLAogICAgMHg5MCwgMHhhZSwgMHhlYywgMHhkMiwgMHgyYywgMHgxMiwgMHg1MCwgMHg2ZSwg MHhkNCwgMHhlYSwgMHhhOCwgMHg5NiwKICAgIDB4YjksIDB4ODcsIDB4YzUsIDB4ZmIsIDB4NDEs IDB4N2YsIDB4M2QsIDB4MDMsIDB4NjMsIDB4NWQsIDB4MWYsIDB4MjEsCiAgICAweDliLCAweGE1 LCAweGU3LCAweGQ5LCAweGY2LCAweGM4LCAweDhhLCAweGI0LCAweDBlLCAweDMwLCAweDcyLCAw eDRjLAogICAgMHhlYiwgMHhkNSwgMHg5NywgMHhhOSwgMHgxMywgMHgyZCwgMHg2ZiwgMHg1MSwg MHg3ZSwgMHg0MCwgMHgwMiwgMHgzYywKICAgIDB4ODYsIDB4YjgsIDB4ZmEsIDB4YzQsIDB4YTQs IDB4OWEsIDB4ZDgsIDB4ZTYsIDB4NWMsIDB4NjIsIDB4MjAsIDB4MWUsCiAgICAweDMxLCAweDBm LCAweDRkLCAweDczLCAweGM5LCAweGY3LCAweGI1LCAweDhiLCAweDc1LCAweDRiLCAweDA5LCAw eDM3LAogICAgMHg4ZCwgMHhiMywgMHhmMSwgMHhjZiwgMHhlMCwgMHhkZSwgMHg5YywgMHhhMiwg MHgxOCwgMHgyNiwgMHg2NCwgMHg1YSwKICAgIDB4M2EsIDB4MDQsIDB4NDYsIDB4NzgsIDB4YzIs IDB4ZmMsIDB4YmUsIDB4ODAsIDB4YWYsIDB4OTEsIDB4ZDMsIDB4ZWQsCiAgICAweDU3LCAweDY5 LCAweDJiLCAweDE1fTsKCnVpbnQ4X3QgY3JjOCh1aW50OF90IGNyYywgdWludDhfdCAqZGF0YSwg c2l6ZV90IGxlbikKewogIHVpbnQ4X3QgKmVuZDsKCiAgaWYgKGxlbiA9PSAwKQogICAgcmV0dXJu IGNyYzsKICBjcmMgXj0gMHhmZjsKICBlbmQgPSBkYXRhICsgbGVuOwogIGRvIHsKICAgIGNyYyA9 IGNyYzhfdGFibGVbY3JjIF4gKmRhdGErK107CiAgfSB3aGlsZSAoZGF0YSA8IGVuZCk7CiAgcmV0 dXJuIGNyYyBeIDB4ZmY7Cn0KCiNkZWZpbmUgeG9yQ29tcHV0ZUtleUNoZWNrU3VtKEspIGNyYzgo MCwgSywgU1BfQk9EWSArIEdldEJvZHlMZW4oSykpCgp1bnNpZ25lZCBsb25nIGxvbmcgaW50IHhv ckVuY3J5cHQodWludDhfdCAqSywgdWludDhfdCAqU2FsdCwgdWludDhfdCBLZXlDaGVja1N1bSwg dWludDMyX3QgSW5PdXREYXRhTGVuLCB1aW50OF90ICpJbk91dEJ1ZikKeyAvLyBFbmNyeXB0cyBv ciBkZWNyeXB0cyBtZXNzYWdlIGFuZCByZXR1cm5zIGNoZWNrc3VtIG9mIHRoZSBJbk91dEJ1ZiBC RUZPUkUgZW5jeXB0aW9uCiAgLy8gU2FsdERhdGEgaXMgYSA0IGJ5dGVzIHVpbnQ4IGFycmF5ISBJ VCBJUyBOT1QgUkVBRCBPTkxZISBJVCBXSUxMIEJFIE1BTklQVUxBVEVEIEJZIFRIRSBGVU5DVElP TiEKICByZWdpc3RlciB1aW50MzJfdCB0LCB0dCwgTTsKICByZWdpc3RlciB1aW50OF90IFhPUlZh bCwgTGFzdFZhbCA9IDAsVG1wVmFsOyAvLyBMYXN0IFBMQUlOVEVYVCBieXRlIHByb2Nlc3NlZC4g SXQgd2lsbCBiZSBhbiBpbnB1dCBwYXJhbWV0ZXIgZm9yIHRoZSBuZXh0IGVuY3J5dHBpb24KICBy ZWdpc3RlciB1aW50NjRfdCBDaGVja3N1bT0wOwogIHJlZ2lzdGVyIHVpbnQzMl90IEJvZHlNYXNr ID0gR2V0Qm9keUxlbihLKTsgLy8gKzEgYmVjYXVzZSB3ZSB3aWxsIHVzZSB0aGlzICJNZXJzZW5u ZSBudW1iZXIiIGZvciAmIG9wZXJhdGlvbiBpbnN0ZWFkIG9mIG1vZHVsdXMgb3BlcmF0aW9uCiAg dWludDhfdCBCb2R5W01BWF9CT0RZX1NJWkVdOwogIAogIG1lbWNweShCb2R5LEsrU1BfQk9EWSxC b2R5TWFzayk7CiAgQm9keU1hc2stLTsKICAKICBTYWx0WzBdIF49IEtleUNoZWNrU3VtOwogIFNh bHRbMV0gXj0gS2V5Q2hlY2tTdW07CiAgU2FsdFsyXSBePSBLZXlDaGVja1N1bTsKICBTYWx0WzNd IF49IEtleUNoZWNrU3VtOwogIAogIC8vIEluaXRpYWwgcG9zaXRpb24gb2YgdGhlIHBvaW50ZXIg aXMgZGVwZW5kZW50IG9uIGFjdHVhbCBzYWx0IHZhbHVlCiAgTSA9IEJvZHlNYXNrICYgU2FsdFsw XTsKICAvL3ByaW50ZigieG9yRW5jcnlwdCBCb2R5TGVuOiAldSBLZXlDaGVja1N1bTogJXUgU2Fs dDogJXVcbiIsQm9keUxlbiwgS2V5Q2hlY2tTdW0sU2FsdCk7CiAgCiAgZm9yICh0PTA7IHQ8SW5P dXREYXRhTGVuOyB0KyspCiAgewogICAgLy8gRmlyc3QganVtcCBzdGVwIGlzIHByZXZpb3VzIHBs YWludGV4dCBieXRlCiAgICBYT1JWYWwgPSBCb2R5W01dOyAKICAgIE0gPSAoTSArIExhc3RWYWwp ICYgQm9keU1hc2s7IAoKICAgIGZvciAodHQ9MTsgdHQgPCBHZXROdW1KdW1wcyhLKTsgdHQrKykK ICAgIHsKICAgICAgLy8gQWxsIGZvbGxvd2luZyBqdW1wcyBhcmUgYmFzZWQgb24gYm9keSB2YWx1 ZXMKICAgICAgWE9SVmFsIF49IEJvZHlbTV07IAogICAgICBNID0gKE0gKyBCb2R5W01dKSAmIEJv ZHlNYXNrOyAKICAgIH0KICAgIE1ha2VYT1JFbmMoSW5PdXRCdWYsWE9SVmFsLFNhbHQsS2V5Q2hl Y2tTdW0sQ2hlY2tzdW0sTGFzdFZhbCxUbXBWYWwsdCk7CiAgICBCb2R5W01dKys7CiAgfQogIHJl dHVybiBDaGVja3N1bTsKfSAKdW5zaWduZWQgbG9uZyBsb25nIGludCB4b3JEZWNyeXB0KHVpbnQ4 X3QgKkssIHVpbnQ4X3QgKlNhbHQsIHVpbnQ4X3QgS2V5Q2hlY2tTdW0sIHVpbnQzMl90IEluT3V0 RGF0YUxlbiwgdWludDhfdCAqSW5PdXRCdWYpCnsgLy8gRGVjcnlwdHMgbWVzc2FnZSBhbmQgcmV0 dXJucyBjaGVja3N1bSBvZiB0aGUgSW5PdXRCdWYgQUZURVIgZW5jeXB0aW9uCiAgLy8gU2FsdERh dGEgaXMgYSA0IGJ5dGVzIHVpbnQ4IGFycmF5ISBJVCBJUyBOT1QgUkVBRCBPTkxZISBJVCBXSUxM IEJFIE1BTklQVUxBVEVEIEJZIFRIRSBGVU5DVElPTiEKICByZWdpc3RlciB1aW50MzJfdCB0LCB0 dCwgTTsKICByZWdpc3RlciB1aW50OF90IFhPUlZhbCwgTGFzdFZhbCA9IDA7IC8vIExhc3QgUExB SU5URVhUIGJ5dGUgcHJvY2Vzc2VkLiBJdCB3aWxsIGJlIGFuIGlucHV0IHBhcmFtZXRlciBmb3Ig dGhlIG5leHQgZW5jcnl0cGlvbgogIHJlZ2lzdGVyIHVpbnQ2NF90IENoZWNrc3VtPTA7CiAgcmVn aXN0ZXIgdWludDMyX3QgQm9keU1hc2sgPSBHZXRCb2R5TGVuKEspOyAvLyArMSBiZWNhdXNlIHdl IHdpbGwgdXNlIHRoaXMgIk1lcnNlbm5lIG51bWJlciIgZm9yICYgb3BlcmF0aW9uIGluc3RlYWQg b2YgbW9kdWx1cyBvcGVyYXRpb24KICB1aW50OF90IEJvZHlbTUFYX0JPRFlfU0laRV07CiAgCiAg bWVtY3B5KEJvZHksSytTUF9CT0RZLEJvZHlNYXNrKTsKICBCb2R5TWFzay0tOwogIAogIFNhbHRb MF0gXj0gS2V5Q2hlY2tTdW07CiAgU2FsdFsxXSBePSBLZXlDaGVja1N1bTsKICBTYWx0WzJdIF49 IEtleUNoZWNrU3VtOwogIFNhbHRbM10gXj0gS2V5Q2hlY2tTdW07CiAgCiAgLy8gSW5pdGlhbCBw b3NpdGlvbiBvZiB0aGUgcG9pbnRlciBpcyBkZXBlbmRlbnQgb24gYWN0dWFsIHNhbHQgdmFsdWUK ICBNID0gQm9keU1hc2sgJiBTYWx0WzBdOwogIC8vcHJpbnRmKCJ4b3JFbmNyeXB0IEJvZHlMZW46 ICV1IEtleUNoZWNrU3VtOiAldSBTYWx0OiAldVxuIixCb2R5TGVuLCBLZXlDaGVja1N1bSxTYWx0 KTsKICAKICBmb3IgKHQ9MDsgdDxJbk91dERhdGFMZW47IHQrKykKICB7CiAgICAvLyBGaXJzdCBq dW1wIHN0ZXAgaXMgcHJldmlvdXMgcGxhaW50ZXh0IGJ5dGUKICAgIFhPUlZhbCA9IEJvZHlbTV07 IAogICAgTSA9IChNICsgTGFzdFZhbCkgJiBCb2R5TWFzazsgCgogICAgZm9yICh0dD0xOyB0dCA8 IEdldE51bUp1bXBzKEspOyB0dCsrKQogICAgewogICAgICAvLyBBbGwgZm9sbG93aW5nIGp1bXBz IGFyZSBiYXNlZCBvbiBib2R5IHZhbHVlcwogICAgICBYT1JWYWwgXj0gQm9keVtNXTsgCiAgICAg IE0gPSAoTSArIEJvZHlbTV0pICYgQm9keU1hc2s7IAogICAgfQogICAgTWFrZVhPUkRlYyhJbk91 dEJ1ZixYT1JWYWwsU2FsdCxLZXlDaGVja1N1bSxDaGVja3N1bSxMYXN0VmFsLHQpOwogICAgQm9k eVtNXSsrOwogIH0KICByZXR1cm4gQ2hlY2tzdW07Cn0gCgp1bnNpZ25lZCBsb25nIGxvbmcgaW50 IHhvckVuY3J5cHRIT1AyKHVpbnQ4X3QgKkssIHVpbnQ4X3QgKlNhbHQsIHVpbnQ4X3QgS2V5Q2hl Y2tTdW0sIHVpbnQzMl90IEluT3V0RGF0YUxlbiwgdWludDhfdCAqSW5PdXRCdWYpCnsgLy8gRW5j cnlwdHMgb3IgZGVjcnlwdHMgbWVzc2FnZSBhbmQgcmV0dXJucyBjaGVja3N1bSBvZiB0aGUgSW5P dXRCdWYgQkVGT1JFIGVuY3lwdGlvbgogIC8vIFNhbHREYXRhIGlzIGEgNCBieXRlcyB1aW50OCBh cnJheSEgSVQgSVMgTk9UIFJFQUQgT05MWSEgSVQgV0lMTCBCRSBNQU5JUFVMQVRFRCBCWSBUSEUg RlVOQ1RJT04hCiAgcmVnaXN0ZXIgdWludDMyX3QgdCwgTTsKICByZWdpc3RlciB1aW50OF90IFhP UlZhbCwgTGFzdFZhbCA9IDAsVG1wVmFsOyAvLyBMYXN0IFBMQUlOVEVYVCBieXRlIHByb2Nlc3Nl ZC4gSXQgd2lsbCBiZSBhbiBpbnB1dCBwYXJhbWV0ZXIgZm9yIHRoZSBuZXh0IGVuY3J5dHBpb24K ICByZWdpc3RlciB1aW50NjRfdCBDaGVja3N1bT0wOwogIHJlZ2lzdGVyIHVpbnQzMl90IEJvZHlN YXNrID0gR2V0Qm9keUxlbihLKTsgLy8gKzEgYmVjYXVzZSB3ZSB3aWxsIHVzZSB0aGlzICJNZXJz ZW5uZSBudW1iZXIiIGZvciAmIG9wZXJhdGlvbiBpbnN0ZWFkIG9mIG1vZHVsdXMgb3BlcmF0aW9u CiAgdWludDhfdCBCb2R5W01BWF9CT0RZX1NJWkVdOwogIAogIG1lbWNweShCb2R5LEsrU1BfQk9E WSxCb2R5TWFzayk7CiAgQm9keU1hc2stLTsKICAKICBTYWx0WzBdIF49IEtleUNoZWNrU3VtOwog IFNhbHRbMV0gXj0gS2V5Q2hlY2tTdW07CiAgU2FsdFsyXSBePSBLZXlDaGVja1N1bTsKICBTYWx0 WzNdIF49IEtleUNoZWNrU3VtOwogIAogIC8vIEluaXRpYWwgcG9zaXRpb24gb2YgdGhlIHBvaW50 ZXIgaXMgZGVwZW5kZW50IG9uIGFjdHVhbCBzYWx0IHZhbHVlCiAgTSA9IEJvZHlNYXNrICYgU2Fs dFswXTsKICAvL3ByaW50ZigieG9yRW5jcnlwdCBCb2R5TGVuOiAldSBLZXlDaGVja1N1bTogJXUg U2FsdDogJXVcbiIsQm9keUxlbiwgS2V5Q2hlY2tTdW0sU2FsdCk7CiAgZm9yICh0PTA7IHQ8SW5P dXREYXRhTGVuOyB0KyspCiAgewogICAgLy8gRmlyc3QganVtcCBzdGVwIGlzIHByZXZpb3VzIHBs YWludGV4dCBieXRlCiAgICBYT1JWYWwgPSBCb2R5W01dOyAKICAgIE0gPSAoTSArIExhc3RWYWwp ICYgQm9keU1hc2s7IAogICAgLy8gQWxsIGZvbGxvd2luZyBqdW1wcyBhcmUgYmFzZWQgb24gYm9k eSB2YWx1ZXMKICAgIFhPUlZhbCBePSBCb2R5W01dOyAKICAgIE0gPSAoTSArIEJvZHlbTV0pICYg Qm9keU1hc2s7IAogICAgTWFrZVhPUkVuYyhJbk91dEJ1ZixYT1JWYWwsU2FsdCxLZXlDaGVja1N1 bSxDaGVja3N1bSxMYXN0VmFsLFRtcFZhbCx0KTsKICAgIEJvZHlbTV0rKzsKICB9CiAgcmV0dXJu IENoZWNrc3VtOwp9IAoKdW5zaWduZWQgbG9uZyBsb25nIGludCB4b3JEZWNyeXB0SE9QMih1aW50 OF90ICpLLCB1aW50OF90ICpTYWx0LCB1aW50OF90IEtleUNoZWNrU3VtLCB1aW50MzJfdCBJbk91 dERhdGFMZW4sIHVpbnQ4X3QgKkluT3V0QnVmKQp7IC8vIEVuY3J5cHRzIG9yIGRlY3J5cHRzIG1l c3NhZ2UgYW5kIHJldHVybnMgY2hlY2tzdW0gb2YgdGhlIEluT3V0QnVmIEJFRk9SRSBlbmN5cHRp b24KICAvLyBTYWx0RGF0YSBpcyBhIDQgYnl0ZXMgdWludDggYXJyYXkhIElUIElTIE5PVCBSRUFE IE9OTFkhIElUIFdJTEwgQkUgTUFOSVBVTEFURUQgQlkgVEhFIEZVTkNUSU9OIQogIHJlZ2lzdGVy IHVpbnQzMl90IHQsIE07CiAgcmVnaXN0ZXIgdWludDhfdCBYT1JWYWwsIExhc3RWYWwgPSAwOyAv LyBMYXN0IFBMQUlOVEVYVCBieXRlIHByb2Nlc3NlZC4gSXQgd2lsbCBiZSBhbiBpbnB1dCBwYXJh bWV0ZXIgZm9yIHRoZSBuZXh0IGVuY3J5dHBpb24KICByZWdpc3RlciB1aW50NjRfdCBDaGVja3N1 bT0wOwogIHJlZ2lzdGVyIHVpbnQzMl90IEJvZHlNYXNrID0gR2V0Qm9keUxlbihLKTsgLy8gKzEg YmVjYXVzZSB3ZSB3aWxsIHVzZSB0aGlzICJNZXJzZW5uZSBudW1iZXIiIGZvciAmIG9wZXJhdGlv biBpbnN0ZWFkIG9mIG1vZHVsdXMgb3BlcmF0aW9uCiAgdWludDhfdCBCb2R5W01BWF9CT0RZX1NJ WkVdOwogIAogIG1lbWNweShCb2R5LEsrU1BfQk9EWSxCb2R5TWFzayk7CiAgQm9keU1hc2stLTsK ICAKICBTYWx0WzBdIF49IEtleUNoZWNrU3VtOwogIFNhbHRbMV0gXj0gS2V5Q2hlY2tTdW07CiAg U2FsdFsyXSBePSBLZXlDaGVja1N1bTsKICBTYWx0WzNdIF49IEtleUNoZWNrU3VtOwogIAogIC8v IEluaXRpYWwgcG9zaXRpb24gb2YgdGhlIHBvaW50ZXIgaXMgZGVwZW5kZW50IG9uIGFjdHVhbCBz YWx0IHZhbHVlCiAgTSA9IEJvZHlNYXNrICYgU2FsdFswXTsKICAvL3ByaW50ZigieG9yRW5jcnlw dCBCb2R5TGVuOiAldSBLZXlDaGVja1N1bTogJXUgU2FsdDogJXVcbiIsQm9keUxlbiwgS2V5Q2hl Y2tTdW0sU2FsdCk7CiAgCiAgZm9yICh0PTA7IHQ8SW5PdXREYXRhTGVuOyB0KyspCiAgewogICAg Ly8gRmlyc3QganVtcCBzdGVwIGlzIHByZXZpb3VzIHBsYWludGV4dCBieXRlCiAgICBYT1JWYWwg PSBCb2R5W01dOyAKICAgIE0gPSAoTSArIExhc3RWYWwpICYgQm9keU1hc2s7IAogICAgLy8gQWxs IGZvbGxvd2luZyBqdW1wcyBhcmUgYmFzZWQgb24gYm9keSB2YWx1ZXMKICAgIFhPUlZhbCBePSBC b2R5W01dOyAKICAgIE0gPSAoTSArIEJvZHlbTV0pICYgQm9keU1hc2s7IAogICAgTWFrZVhPUkRl YyhJbk91dEJ1ZixYT1JWYWwsU2FsdCxLZXlDaGVja1N1bSxDaGVja3N1bSxMYXN0VmFsLHQpOwog ICAgQm9keVtNXSsrOwogIH0KICByZXR1cm4gQ2hlY2tzdW07Cn0gCnVuc2lnbmVkIGxvbmcgbG9u ZyBpbnQgeG9yRW5jcnlwdEhPUDModWludDhfdCAqSywgdWludDhfdCAqU2FsdCwgdWludDhfdCBL ZXlDaGVja1N1bSwgdWludDMyX3QgSW5PdXREYXRhTGVuLCB1aW50OF90ICpJbk91dEJ1ZikKeyAv LyBFbmNyeXB0cyBvciBkZWNyeXB0cyBtZXNzYWdlIGFuZCByZXR1cm5zIGNoZWNrc3VtIG9mIHRo ZSBJbk91dEJ1ZiBCRUZPUkUgZW5jeXB0aW9uCiAgLy8gU2FsdERhdGEgaXMgYSA0IGJ5dGVzIHVp bnQ4IGFycmF5ISBJVCBJUyBOT1QgUkVBRCBPTkxZISBJVCBXSUxMIEJFIE1BTklQVUxBVEVEIEJZ IFRIRSBGVU5DVElPTiEKICByZWdpc3RlciB1aW50MzJfdCB0LCBNOwogIHJlZ2lzdGVyIHVpbnQ4 X3QgWE9SVmFsLCBMYXN0VmFsID0gMCxUbXBWYWw7IC8vIExhc3QgUExBSU5URVhUIGJ5dGUgcHJv Y2Vzc2VkLiBJdCB3aWxsIGJlIGFuIGlucHV0IHBhcmFtZXRlciBmb3IgdGhlIG5leHQgZW5jcnl0 cGlvbgogIHJlZ2lzdGVyIHVpbnQ2NF90IENoZWNrc3VtPTA7CiAgcmVnaXN0ZXIgdWludDMyX3Qg Qm9keU1hc2sgPSBHZXRCb2R5TGVuKEspOyAvLyArMSBiZWNhdXNlIHdlIHdpbGwgdXNlIHRoaXMg Ik1lcnNlbm5lIG51bWJlciIgZm9yICYgb3BlcmF0aW9uIGluc3RlYWQgb2YgbW9kdWx1cyBvcGVy YXRpb24KICB1aW50OF90IEJvZHlbTUFYX0JPRFlfU0laRV07CiAgCiAgbWVtY3B5KEJvZHksSytT UF9CT0RZLEJvZHlNYXNrKTsKICBCb2R5TWFzay0tOwogIAogIFNhbHRbMF0gXj0gS2V5Q2hlY2tT dW07CiAgU2FsdFsxXSBePSBLZXlDaGVja1N1bTsKICBTYWx0WzJdIF49IEtleUNoZWNrU3VtOwog IFNhbHRbM10gXj0gS2V5Q2hlY2tTdW07CiAgCiAgLy8gSW5pdGlhbCBwb3NpdGlvbiBvZiB0aGUg cG9pbnRlciBpcyBkZXBlbmRlbnQgb24gYWN0dWFsIHNhbHQgdmFsdWUKICBNID0gQm9keU1hc2sg JiBTYWx0WzBdOwogIC8vcHJpbnRmKCJ4b3JFbmNyeXB0IEJvZHlMZW46ICV1IEtleUNoZWNrU3Vt OiAldSBTYWx0OiAldVxuIixCb2R5TGVuLCBLZXlDaGVja1N1bSxTYWx0KTsKICBmb3IgKHQ9MDsg dDxJbk91dERhdGFMZW47IHQrKykKICB7CiAgICAvLyBGaXJzdCBqdW1wIHN0ZXAgaXMgcHJldmlv dXMgcGxhaW50ZXh0IGJ5dGUKICAgIFhPUlZhbCA9IEJvZHlbTV07IAogICAgTSA9IChNICsgTGFz dFZhbCkgJiBCb2R5TWFzazsgCiAgICAvLyBBbGwgZm9sbG93aW5nIGp1bXBzIGFyZSBiYXNlZCBv biBib2R5IHZhbHVlcwogICAgWE9SVmFsIF49IEJvZHlbTV07IAogICAgTSA9IChNICsgQm9keVtN XSkgJiBCb2R5TWFzazsgCiAgICBYT1JWYWwgXj0gQm9keVtNXTsgCiAgICBNID0gKE0gKyBCb2R5 W01dKSAmIEJvZHlNYXNrOyAKICAgIE1ha2VYT1JFbmMoSW5PdXRCdWYsWE9SVmFsLFNhbHQsS2V5 Q2hlY2tTdW0sQ2hlY2tzdW0sTGFzdFZhbCxUbXBWYWwsdCk7CiAgICBCb2R5W01dKys7CiAgfQog IHJldHVybiBDaGVja3N1bTsKfSAKCnVuc2lnbmVkIGxvbmcgbG9uZyBpbnQgeG9yRGVjcnlwdEhP UDModWludDhfdCAqSywgdWludDhfdCAqU2FsdCwgdWludDhfdCBLZXlDaGVja1N1bSwgdWludDMy X3QgSW5PdXREYXRhTGVuLCB1aW50OF90ICpJbk91dEJ1ZikKeyAvLyBFbmNyeXB0cyBvciBkZWNy eXB0cyBtZXNzYWdlIGFuZCByZXR1cm5zIGNoZWNrc3VtIG9mIHRoZSBJbk91dEJ1ZiBCRUZPUkUg ZW5jeXB0aW9uCiAgLy8gU2FsdERhdGEgaXMgYSA0IGJ5dGVzIHVpbnQ4IGFycmF5ISBJVCBJUyBO T1QgUkVBRCBPTkxZISBJVCBXSUxMIEJFIE1BTklQVUxBVEVEIEJZIFRIRSBGVU5DVElPTiEKICBy ZWdpc3RlciB1aW50MzJfdCB0LCBNOwogIHJlZ2lzdGVyIHVpbnQ4X3QgWE9SVmFsLCBMYXN0VmFs ID0gMDsgLy8gTGFzdCBQTEFJTlRFWFQgYnl0ZSBwcm9jZXNzZWQuIEl0IHdpbGwgYmUgYW4gaW5w dXQgcGFyYW1ldGVyIGZvciB0aGUgbmV4dCBlbmNyeXRwaW9uCiAgcmVnaXN0ZXIgdWludDY0X3Qg Q2hlY2tzdW09MDsKICByZWdpc3RlciB1aW50MzJfdCBCb2R5TWFzayA9IEdldEJvZHlMZW4oSyk7 IC8vICsxIGJlY2F1c2Ugd2Ugd2lsbCB1c2UgdGhpcyAiTWVyc2VubmUgbnVtYmVyIiBmb3IgJiBv cGVyYXRpb24gaW5zdGVhZCBvZiBtb2R1bHVzIG9wZXJhdGlvbgogIHVpbnQ4X3QgQm9keVtNQVhf Qk9EWV9TSVpFXTsKICAKICBtZW1jcHkoQm9keSxLK1NQX0JPRFksQm9keU1hc2spOwogIEJvZHlN YXNrLS07CiAgCiAgU2FsdFswXSBePSBLZXlDaGVja1N1bTsKICBTYWx0WzFdIF49IEtleUNoZWNr U3VtOwogIFNhbHRbMl0gXj0gS2V5Q2hlY2tTdW07CiAgU2FsdFszXSBePSBLZXlDaGVja1N1bTsK ICAKICAvLyBJbml0aWFsIHBvc2l0aW9uIG9mIHRoZSBwb2ludGVyIGlzIGRlcGVuZGVudCBvbiBh Y3R1YWwgc2FsdCB2YWx1ZQogIE0gPSBCb2R5TWFzayAmIFNhbHRbMF07CiAgLy9wcmludGYoInhv ckVuY3J5cHQgQm9keUxlbjogJXUgS2V5Q2hlY2tTdW06ICV1IFNhbHQ6ICV1XG4iLEJvZHlMZW4s IEtleUNoZWNrU3VtLFNhbHQpOwogIAogIGZvciAodD0wOyB0PEluT3V0RGF0YUxlbjsgdCsrKQog IHsKICAgIC8vIEZpcnN0IGp1bXAgc3RlcCBpcyBwcmV2aW91cyBwbGFpbnRleHQgYnl0ZQogICAg WE9SVmFsID0gQm9keVtNXTsgCiAgICBNID0gKE0gKyBMYXN0VmFsKSAmIEJvZHlNYXNrOyAKICAg IC8vIEFsbCBmb2xsb3dpbmcganVtcHMgYXJlIGJhc2VkIG9uIGJvZHkgdmFsdWVzCiAgICBYT1JW YWwgXj0gQm9keVtNXTsgCiAgICBNID0gKE0gKyBCb2R5W01dKSAmIEJvZHlNYXNrOyAKICAgIFhP UlZhbCBePSBCb2R5W01dOyAKICAgIE0gPSAoTSArIEJvZHlbTV0pICYgQm9keU1hc2s7IAogICAg TWFrZVhPUkRlYyhJbk91dEJ1ZixYT1JWYWwsU2FsdCxLZXlDaGVja1N1bSxDaGVja3N1bSxMYXN0 VmFsLHQpOwogICAgQm9keVtNXSsrOwogIH0KICByZXR1cm4gQ2hlY2tzdW07Cn0gCgovLyNkZWZp bmUgeG9yRW5jcnlwdERlY3J5cHQgeG9yRW5jcnlwdERlY3J5cHRIT1A1Ci8qIE1lbWNweSBCZW5j aG1hcmsxIDogCiAqIFRoaXMgZnVuY3Rpb24gCiAqICAgQ3JlYXRlcyBhIE4gYnl0ZXMgcmFuZG9t IGRhdGEgYnVmZmVyIAogKiAgIENyZWF0ZXMgYW5vdGhlciBOIGJ5dGVzIHplcm8gZmlsbGVkIGJ1 ZmZlciAoRGVzdEJ1ZikKICogICBTdGFydHMgYW4gaXRlcmF0aW9uIAogKiAgIEZvciBlYWNoIGl0 ZXJhdGlvbiwgaW5jcmVhc2VzIGV2ZXJ5IGJ5dGUgb2YgdGhlIGRhdGEgYnkgMQogKiAgIENvcGll cyB0aGUgZGF0YSBidWZmZXIgdG8gRGVzdEJ1ZgogKiAgIFByaW50cyB0aGUgZWxhcHNlZCB0aW1l IAogKi8Kdm9pZCBNZW1DcHlCZW5jaG1hcmsxKHVpbnQzMl90IFRlc3RTYW1wbGVMZW5ndGgsIHVp bnQzMl90IE51bUl0ZXJhdGlvbnMpCnsKICB1aW50OF90ICpEYXRhID0gQ3JlYXRlRGF0YUJ1ZihU ZXN0U2FtcGxlTGVuZ3RoKTsKICB1aW50OF90ICpEZXN0QnVmID0gQ3JlYXRlRGF0YUJ1ZihUZXN0 U2FtcGxlTGVuZ3RoKTsKICB1bnNpZ25lZCBsb25nIGxvbmcgaW50IFRvdGFsUHJvY2Vzc2VkQnl0 ZXMgPSAwOwogIHVuc2lnbmVkIHQ7CiAgCiAgLypwcmludGYoIi0tLS0tLS0tLS0tLS0tLS0tLS0t IE1lbUNweUJlbmNobWFyazEgMTogQkFTSUMgRlVOQ1RJT05BTElUWSAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tXG4iCiAgICAgICAgIlRoaXMgZnVuY3Rpb25cbiAxLkNyZWF0ZXMgYSAldSBieXRl cyByYW5kb20gZGF0YSBidWZmZXJcbkNyZWF0ZXMgYW5vdGhlciBidWZmZXIoRGVzdEJ1Zikgd2l0 aCB0aGUgc2FtZSBzaXplXG5NYWtlcyAldSBpdGVyYXRpb25cbiIKICAgICAgICAgIkZvciBlYWNo IGl0ZXJhdGlvbiwgaW5jcmVhc2VzIGV2ZXJ5IGJ5dGUgb2YgdGhlIGRhdGEgYnkgMVxuQ29waWVz IHRoZSBkYXRhIGJ1ZmZlciB0byBEZXN0QnVmXG5QcmludHMgdGhlIGVsYXBzZWQgdGltZSIsVGVz dFNhbXBsZUxlbmd0aCxOdW1JdGVyYXRpb25zKTsqLwogIHByaW50ZigiTWVtQ3B5QmVuY2htYXJr MVxuXHRUZXN0U2FtcGxlTGVuZ3RoOiAldVxuXHROdW1JdGVyYXRpb25zOiAldSAuLi4gIixUZXN0 U2FtcGxlTGVuZ3RoLE51bUl0ZXJhdGlvbnMpOyAgCiAgc3RydWN0IHRpbWV2YWwgU3RhcnRUaW1l OwogIGdldHRpbWVvZmRheSAoJlN0YXJ0VGltZSwgTlVMTCk7IAogIAogIGZvciAodD0wOyB0PE51 bUl0ZXJhdGlvbnM7IHQrKykKICB7CiAgICBJbmNCeU9uZShEYXRhLCBUZXN0U2FtcGxlTGVuZ3Ro KTsKICAgIG1lbWNweShEZXN0QnVmLCBEYXRhLCBUZXN0U2FtcGxlTGVuZ3RoKTsKICAgIFRvdGFs UHJvY2Vzc2VkQnl0ZXMgKz0gVGVzdFNhbXBsZUxlbmd0aDsKICB9CiAgUHJpbnRFbGFwc2VkVGlt ZSgmU3RhcnRUaW1lLFRvdGFsUHJvY2Vzc2VkQnl0ZXMpOwogIGZyZWUoRGF0YSk7CiAgZnJlZShE ZXN0QnVmKTsKfQoKLyogQmVuY2htYXJrMSA6IAogKiBUaGlzIGZ1bmN0aW9uIAogKiAgIENyZWF0 ZXMgYSBrZXkgd2l0aCBOdW1KdW1wcyBwYXJ0aWNsZXMgYW5kIHdpdGggYSBib2R5IGxlbmd0aCBv ZiBCb2R5TGVuCiAqICAgQ3JlYXRlcyBhIE4gYnl0ZXMgcmFuZG9tIHplcm8gZmlsbGVkIGJ1ZmZl ciAKICogICBTdGFydHMgYW4gaXRlcmF0aW9uIG9mIE51bUl0ZXJhdGlvbnMgdGltZXMKICogICBG b3IgZWFjaCBpdGVyYXRpb24sIGluY3JlYXNlcyBldmVyeSBieXRlIG9mIHRoZSBkYXRhIGJ5IDEK ICogICBFbmNyeXB0cyB0aGUgZGF0YQogKiAgIFByaW50cyB0aGUgZWxhcHNlZCB0aW1lIAogKi8K ZG91YmxlIEJlbmNobWFyazEodWludDhfdCBOdW1KdW1wcywgdWludDMyX3QgQm9keUxlbiwgdWlu dDMyX3QgVGVzdFNhbXBsZUxlbmd0aCwgdWludDMyX3QgTnVtSXRlcmF0aW9ucykKewogIHVpbnQ4 X3QgKktleUJ1ZiA9ICh1aW50OF90ICopbWFsbG9jKHhvckNvbXB1dGVLZXlCdWZMZW4oQm9keUxl bikpOwogIHVpbnQ4X3QgKkRhdGEgPSBDcmVhdGVEYXRhQnVmKFRlc3RTYW1wbGVMZW5ndGgpOwog IHVuc2lnbmVkIGxvbmcgbG9uZyBpbnQgVG90YWxQcm9jZXNzZWRCeXRlcyA9IDA7CiAgdWludDMy X3QgdCxTYWx0OwogIHVpbnQ4X3QgS2V5Q2hlY2tTdW07CiAgCiAgcHJpbnRmKCJCZW5jaG1hcmsx XG5cdE51bUp1bXBzOiAldVxuXHRCb2R5TGVuOiAldVxuXHRUZXN0U2FtcGxlTGVuZ3RoOiAldVxu XHROdW1JdGVyYXRpb25zOiAldSAuLi4gIixOdW1KdW1wcyxCb2R5TGVuLFRlc3RTYW1wbGVMZW5n dGgsTnVtSXRlcmF0aW9ucyk7ICAKICAKICBHZXRSYW5kb21OdW1iZXJzKFRlc3RTYW1wbGVMZW5n dGgsIERhdGEpOwogIHhvckdldEtleShOdW1KdW1wcywgQm9keUxlbiwgS2V5QnVmKTsKICBLZXlD aGVja1N1bSA9IHhvckNvbXB1dGVLZXlDaGVja1N1bShLZXlCdWYpOwogIHhvckFuYWx5emVLZXko S2V5QnVmKTsKICBzdHJ1Y3QgdGltZXZhbCBTdGFydFRpbWU7CiAgZ2V0dGltZW9mZGF5ICgmU3Rh cnRUaW1lLCBOVUxMKTsgCiAgCiAgZm9yICh0PTA7IHQ8TnVtSXRlcmF0aW9uczsgdCsrKQogIHsK ICAgIEluY0J5T25lKERhdGEsIFRlc3RTYW1wbGVMZW5ndGgpOwogICAgU2FsdD0xMjM0OwogICAg eG9yRW5jcnlwdChLZXlCdWYsICh1aW50OF90ICopKCZTYWx0KSwgS2V5Q2hlY2tTdW0sIFRlc3RT YW1wbGVMZW5ndGgsIERhdGEpOwogICAgVG90YWxQcm9jZXNzZWRCeXRlcyArPSBUZXN0U2FtcGxl TGVuZ3RoOwogIH0KICBkb3VibGUgQXZlcmFnZSA9IFByaW50RWxhcHNlZFRpbWUoJlN0YXJ0VGlt ZSxUb3RhbFByb2Nlc3NlZEJ5dGVzKTsKICBmcmVlKERhdGEpOwogIGZyZWUoS2V5QnVmKTsKICBy ZXR1cm4gQXZlcmFnZTsKfQpzdGF0aWMgaW5saW5lIHVpbnQ2NF90IEJ1ZkNoZWNrU3VtKHVpbnQ4 X3QgKkJ1ZiwgdWludDY0X3QgQnVmTGVuKQp7CiAgdWludDY0X3QgdCwgQ2hlY2tTdW0gPSAwOwog IAogIGZvciAodD0wOyB0PEJ1ZkxlbjsgdCsrKQogICAgQ2hlY2tTdW0gKz0gQnVmW3RdOwogIHJl dHVybiBDaGVja1N1bTsKfQpkb3VibGUgQmVuY2htYXJrSE9QMih1aW50OF90IE51bUp1bXBzLCB1 aW50MzJfdCBCb2R5TGVuLCB1aW50MzJfdCBUZXN0U2FtcGxlTGVuZ3RoLCB1aW50MzJfdCBOdW1J dGVyYXRpb25zKQp7CiAgdWludDhfdCAqS2V5QnVmID0gKHVpbnQ4X3QgKiltYWxsb2MoeG9yQ29t cHV0ZUtleUJ1ZkxlbihCb2R5TGVuKSk7CiAgdWludDhfdCAqRGF0YSA9IENyZWF0ZURhdGFCdWYo VGVzdFNhbXBsZUxlbmd0aCk7CiAgdW5zaWduZWQgbG9uZyBsb25nIGludCBUb3RhbFByb2Nlc3Nl ZEJ5dGVzID0gMDsKICB1aW50MzJfdCB0OwogIHVpbnQ4X3QgS2V5Q2hlY2tTdW07CiAgdWludDMy X3QgIFNhbHREYXRhPTEyNDU7CiAgCiAgcHJpbnRmKCJCZW5jaG1hcmtIb3AyXG5cdE51bUp1bXBz OiAldVxuXHRCb2R5TGVuOiAldVxuXHRUZXN0U2FtcGxlTGVuZ3RoOiAldVxuXHROdW1JdGVyYXRp b25zOiAldSAuLi4gIixOdW1KdW1wcyxCb2R5TGVuLFRlc3RTYW1wbGVMZW5ndGgsTnVtSXRlcmF0 aW9ucyk7ICAKICAKICBHZXRSYW5kb21OdW1iZXJzKFRlc3RTYW1wbGVMZW5ndGgsIERhdGEpOwog IHhvckdldEtleShOdW1KdW1wcywgQm9keUxlbiwgS2V5QnVmKTsKICBLZXlDaGVja1N1bSA9IHhv ckNvbXB1dGVLZXlDaGVja1N1bShLZXlCdWYpOwogIHhvckFuYWx5emVLZXkoS2V5QnVmKTsKICBz dHJ1Y3QgdGltZXZhbCBTdGFydFRpbWU7CiAgZ2V0dGltZW9mZGF5ICgmU3RhcnRUaW1lLCBOVUxM KTsgCiAgCiAgQnVmQ2hlY2tTdW0oRGF0YSwgVGVzdFNhbXBsZUxlbmd0aCk7ICAKICBmb3IgKHQ9 MDsgdDxOdW1JdGVyYXRpb25zOyB0KyspCiAgewogICAgSW5jQnlPbmUoRGF0YSwgVGVzdFNhbXBs ZUxlbmd0aCk7CiAgICB4b3JFbmNyeXB0SE9QMihLZXlCdWYsICh1aW50OF90ICopKCZTYWx0RGF0 YSksIEtleUNoZWNrU3VtLCBUZXN0U2FtcGxlTGVuZ3RoLCBEYXRhKTsKICAgIFRvdGFsUHJvY2Vz c2VkQnl0ZXMgKz0gVGVzdFNhbXBsZUxlbmd0aDsKICB9CiAgZG91YmxlIEF2ZXJhZ2UgPSBQcmlu dEVsYXBzZWRUaW1lKCZTdGFydFRpbWUsVG90YWxQcm9jZXNzZWRCeXRlcyk7CiAgZnJlZShEYXRh KTsKICBmcmVlKEtleUJ1Zik7CiAgcmV0dXJuIEF2ZXJhZ2U7Cn0KCmRvdWJsZSBCZW5jaG1hcmtI T1AzKHVpbnQ4X3QgTnVtSnVtcHMsIHVpbnQzMl90IEJvZHlMZW4sIHVpbnQzMl90IFRlc3RTYW1w bGVMZW5ndGgsIHVpbnQzMl90IE51bUl0ZXJhdGlvbnMpCnsKICB1aW50OF90ICpLZXlCdWYgPSAo dWludDhfdCAqKW1hbGxvYyh4b3JDb21wdXRlS2V5QnVmTGVuKEJvZHlMZW4pKTsKICB1aW50OF90 ICpEYXRhID0gQ3JlYXRlRGF0YUJ1ZihUZXN0U2FtcGxlTGVuZ3RoKTsKICB1bnNpZ25lZCBsb25n IGxvbmcgaW50IFRvdGFsUHJvY2Vzc2VkQnl0ZXMgPSAwOwogIHVpbnQzMl90IHQ7CiAgdWludDhf dCBLZXlDaGVja1N1bTsKICB1aW50MzJfdCBTYWx0RGF0YTsKICAKICBwcmludGYoIkJlbmNobWFy a0hvcDNcblx0TnVtSnVtcHM6ICV1XG5cdEJvZHlMZW46ICV1XG5cdFRlc3RTYW1wbGVMZW5ndGg6 ICV1XG5cdE51bUl0ZXJhdGlvbnM6ICV1IC4uLiAiLE51bUp1bXBzLEJvZHlMZW4sVGVzdFNhbXBs ZUxlbmd0aCxOdW1JdGVyYXRpb25zKTsgIAogIAogIEdldFJhbmRvbU51bWJlcnMoVGVzdFNhbXBs ZUxlbmd0aCwgRGF0YSk7CiAgeG9yR2V0S2V5KE51bUp1bXBzLCBCb2R5TGVuLCBLZXlCdWYpOwog IEtleUNoZWNrU3VtID0geG9yQ29tcHV0ZUtleUNoZWNrU3VtKEtleUJ1Zik7CiAgeG9yQW5hbHl6 ZUtleShLZXlCdWYpOwogIHN0cnVjdCB0aW1ldmFsIFN0YXJ0VGltZTsKICBnZXR0aW1lb2ZkYXkg KCZTdGFydFRpbWUsIE5VTEwpOyAKICAKICBCdWZDaGVja1N1bShEYXRhLCBUZXN0U2FtcGxlTGVu Z3RoKTsgIAogIGZvciAodD0wOyB0PE51bUl0ZXJhdGlvbnM7IHQrKykKICB7CiAgICBJbmNCeU9u ZShEYXRhLCBUZXN0U2FtcGxlTGVuZ3RoKTsKICAgIHhvckVuY3J5cHRIT1AzKEtleUJ1ZiwgKHVp bnQ4X3QgKikoJlNhbHREYXRhKSwgS2V5Q2hlY2tTdW0sIFRlc3RTYW1wbGVMZW5ndGgsIERhdGEp OwogICAgVG90YWxQcm9jZXNzZWRCeXRlcyArPSBUZXN0U2FtcGxlTGVuZ3RoOwogIH0KICBkb3Vi bGUgQXZlcmFnZSA9IFByaW50RWxhcHNlZFRpbWUoJlN0YXJ0VGltZSxUb3RhbFByb2Nlc3NlZEJ5 dGVzKTsKICBmcmVlKERhdGEpOwogIGZyZWUoS2V5QnVmKTsKICByZXR1cm4gQXZlcmFnZTsKfQoK I2RlZmluZSBURVNUU1RSMSAiVMOcUkvDh0Uga2FyYWt0ZXIga3VsbGFuxLFuxLF6IERFTkVNRS4g VMOcUkvDh0Uga2FyYWt0ZXIga3VsbGFuxLFuxLF6IERFTkVNRS4gdXp1dXV1dXV1bi4gVMOcUkvD h0Uga2FyYWt0ZXIga3VsbGFuxLFuxLF6IERFTkVNRS4gw4dvayB1enVuIMOnb2shMjIyVMOcUkvD h0Uga2FyYWt0ZXIga3VsbGFuxLFuxLF6IERFTkVNRS4gVMOcUkvDh0Uga2FyYWt0ZXIga3VsbGFu xLFuxLF6IERFTkVNRS4gdXp1dXV1dXV1bi4gVMOcUkvDh0Uga2FyYWt0ZXIga3VsbGFuxLFuxLF6 IERFTkVNRS4gw4dvayB1enVuIMOnb2shZnJmclTDnFJLw4dFIGthcmFrdGVyIGt1bGxhbsSxbsSx eiBERU5FTUUuIFTDnFJLw4dFIGthcmFrdGVyIGt1bGxhbsSxbsSxeiBERU5FTUUuIHV6dXV1dXV1 dW4uIFTDnFJLw4dFIGthcmFrdGVyIGt1bGxhbsSxbsSxeiBERU5FTUUuIMOHb2sgdXp1biDDp29r ISIKI2RlZmluZSBURVNUU1RSMV9MRU4gc3RybGVuKFRFU1RTVFIxKQp2b2lkIENoZWNrT3B0aW1p emVkVmVyc2lvbih1bnNpZ25lZCBOdW1KdW1wcywgdW5zaWduZWQgQm9keUxlbikKewogIHVuc2ln bmVkIGxvbmcgbG9uZyBpbnQgRExlbiwgT3JpZ2luYWxQbGFpblRleHRDaGVja1N1bSwgQ2hlY2tT dW1SZXR1cm5lZEZyb21FbmNyeXB0b3IsIENoZWNrU3VtUmV0dXJuZWRGcm9tRGVjcnlwdG9yOwog IHVuc2lnbmVkIFJhd0tleUxlbiA9IHhvckNvbXB1dGVLZXlCdWZMZW4oQm9keUxlbik7CiAgdWlu dDhfdCAqS2V5QnVmID0gKHVpbnQ4X3QgKiltYWxsb2MoUmF3S2V5TGVuKTsKICB1aW50OF90IFBs YWluVGV4dEJ1ZlsxMzIwMDBdLCBEYXRhWzEzMjAwMF07CiAgdW5zaWduZWQgbG9uZyBsb25nIGlu dCBLZXlDaGVja1N1bTsKICB1aW50MzJfdCBTYWx0RGF0YTsKICAKICBwcmludGYoIi0tLS0tLS0t LS0tLS0tLS0tLS0tIFRFU1RJTkcgT1BUSU1JWkVEIFZFUlNJT04gRk9SICV1IFBBUlRJQ0xFUyAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tXG4iLE51bUp1bXBzKTsKICB4b3JHZXRLZXkoTnVtSnVt cHMsIEJvZHlMZW4sIEtleUJ1Zik7CiAgS2V5Q2hlY2tTdW0gPSB4b3JDb21wdXRlS2V5Q2hlY2tT dW0oS2V5QnVmKTsKICBETGVuID0gVEVTVFNUUjFfTEVOOyAKICBtZW1jcHkoRGF0YSwgVEVTVFNU UjEsIERMZW4pOwogIG1lbWNweShQbGFpblRleHRCdWYsIFRFU1RTVFIxLCBETGVuKTsKICAKICBm b3IgKERMZW4gPSAwOyBETGVuIDwgVEVTVFNUUjFfTEVOOyBETGVuKyspCiAgewogICAgUGxhaW5U ZXh0QnVmW0RMZW5dID0gKHVpbnQ4X3QpKERMZW4gJiAyNTUpOwogICAgRGF0YVtETGVuXSA9IFBs YWluVGV4dEJ1ZltETGVuXTsKICAgIE9yaWdpbmFsUGxhaW5UZXh0Q2hlY2tTdW0gPSBCdWZDaGVj a1N1bShEYXRhLCBETGVuKzEpOwogICAgU2FsdERhdGE9MTIzNDsKICAgIENoZWNrU3VtUmV0dXJu ZWRGcm9tRW5jcnlwdG9yID0geG9yRW5jcnlwdChLZXlCdWYsICh1aW50OF90ICopKCZTYWx0RGF0 YSksIEtleUNoZWNrU3VtLCBETGVuKzEsIERhdGEpOyAvLyBXZSBlbmNyeXB0IHdpdGggbm9uLW9w dGltaXplZCB2ZXJzaW9uCiAgICBpZiAoT3JpZ2luYWxQbGFpblRleHRDaGVja1N1bSAhPSBDaGVj a1N1bVJldHVybmVkRnJvbUVuY3J5cHRvcikKICAgIHsKICAgICAgcHJpbnRmKCJPcmlnaW5hbCBD aGVja3N1bSAlbGx1IHJldHVybmVkIGZyb20gQnVmQ2hlY2tzdW0gZm5jIDw+IENoZWNrc3VtICVs bHUgcmV0dXJuZWQgZnJvbSB4b3JFbmNyeXB0RGVjcnlwdFxuIixPcmlnaW5hbFBsYWluVGV4dENo ZWNrU3VtLENoZWNrU3VtUmV0dXJuZWRGcm9tRW5jcnlwdG9yKTsKICAgICAgZXhpdCgtMSk7CiAg ICB9CiAgICAvLyBTYWx0IGRhdGEgY2hhbmdlcyB3aXRoIGV2ZXJ5IGVuY3J5cHQgZGVjcnlwdCEg CiAgICBTYWx0RGF0YT0xMjM0OwogICAgaWYgKE51bUp1bXBzID09IDIpCiAgICAgIENoZWNrU3Vt UmV0dXJuZWRGcm9tRGVjcnlwdG9yID0geG9yRGVjcnlwdEhPUDIoS2V5QnVmLCAodWludDhfdCAq KSgmU2FsdERhdGEpLCBLZXlDaGVja1N1bSwgRExlbisxLCBEYXRhKTsKICAgIGVsc2UgaWYgKE51 bUp1bXBzID09IDMpCiAgICAgIENoZWNrU3VtUmV0dXJuZWRGcm9tRGVjcnlwdG9yID0geG9yRGVj cnlwdEhPUDMoS2V5QnVmLCAodWludDhfdCAqKSgmU2FsdERhdGEpLCBLZXlDaGVja1N1bSwgRExl bisxLCBEYXRhKTsKICAgIGVsc2UgZXhpdCgtMSk7CiAgICAKICAgIGlmIChPcmlnaW5hbFBsYWlu VGV4dENoZWNrU3VtICE9IENoZWNrU3VtUmV0dXJuZWRGcm9tRGVjcnlwdG9yKQogICAgewogICAg ICBwcmludGYoIk9yaWdpbmFsIENoZWNrc3VtICVsbHUgcmV0dXJuZWQgZnJvbSBCdWZDaGVja3N1 bSBmbmMgPD4gQ2hlY2tzdW0gJWxsdSByZXR1cm5lZCBmcm9tIEhPUCBkZWN5cHRvclxuIixPcmln aW5hbFBsYWluVGV4dENoZWNrU3VtLENoZWNrU3VtUmV0dXJuZWRGcm9tRGVjcnlwdG9yKTsKICAg ICAgZXhpdCgtMSk7CiAgICB9CiAgICBpZiAobWVtY21wKChjaGFyICopRGF0YSwgKGNoYXIgKilQ bGFpblRleHRCdWYsIERMZW4rMSkgIT0gMCkKICAgIHsKICAgICAgcHJpbnRmKCJTdHJpbmc6ICVz IC4uLiBUZXN0MSByZXN1bHQ6IEZBSUxFRCEhISFcbi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS1cbiIsIERhdGEpOwogICAgICBleGl0KC0xKTsKICAgIH0KICB9CiAgcHJp bnRmKCJ4b3JFbmNyeXB0RGVjcnlwdEhPUCV1IFNVQ0NFU1NGVUwhXG4iLE51bUp1bXBzKTsKfQp2 b2lkIFRlc3QxKHVuc2lnbmVkIE51bUp1bXBzLCB1bnNpZ25lZCBCb2R5TGVuKQp7CiAgdW5zaWdu ZWQgbG9uZyBsb25nIGludCBETGVuLCBPcmlnaW5hbFBsYWluVGV4dENoZWNrU3VtLCBDaGVja1N1 bVJldHVybmVkRnJvbUVuY3J5cHRvciwgQ2hlY2tTdW1SZXR1cm5lZEZyb21EZWNyeXB0b3I7CiAg dW5zaWduZWQgUmF3S2V5TGVuID0geG9yQ29tcHV0ZUtleUJ1ZkxlbihCb2R5TGVuKTsKICB1aW50 OF90ICpLZXlCdWYgPSAodWludDhfdCAqKW1hbGxvYyhSYXdLZXlMZW4pOwogIHVpbnQ4X3QgRGF0 YVsyMDQ4XSxEYXRhMlsyMDQ4XTsKICBjaGFyICpCYXNlNjRFbmNvZGVkS2V5U3RyLCAqQmFzZTY0 Q2lwaGVyVGV4dDsKICB1aW50OF90IEtleUNoZWNrU3VtOwogIHVpbnQzMl90IFNhbHREYXRhPTEy MzQ7CiAgCiAgcHJpbnRmKCItLS0tLS0tLS0tLSBURVNUIDE6IEJBU0lDIEZVTkNUSU9OQUxJVFko JXUgSnVtcHMpIC0tLS0tLS0tLS0tLS0tXG4iLE51bUp1bXBzKTsKICB4b3JHZXRLZXkoTnVtSnVt cHMsIEJvZHlMZW4sIEtleUJ1Zik7CiAgS2V5Q2hlY2tTdW0gPSB4b3JDb21wdXRlS2V5Q2hlY2tT dW0oS2V5QnVmKTsKICBCYXNlNjRFbmNvZGVkS2V5U3RyID0gQmFzZTY0RW5jb2RlKChjb25zdCBj aGFyICopS2V5QnVmLCBSYXdLZXlMZW4pOwogIHByaW50ZigiQmFzZTY0IGVuY29kZWQga2V5OiAl c1xuIiwgQmFzZTY0RW5jb2RlZEtleVN0cik7CiNpZmRlZiBPVkVSTFlfVkVSQk9TRQogIHByaW50 ZigiQW5hbHl6aW5nIHJhdyBrZXkgZGF0YTpcbiIpOwogIFRQYXJzZWRLZXkgKlBLMCA9IHhvclBh cnNlS2V5KEtleUJ1Zik7CiAgeG9yQW5hbHl6ZUtleShQSzApOwogIGZyZWUoUEswKTsKICBmcmVl KEtleUJ1Zik7CiNlbmRpZgogIHhvckFuYWx5emVLZXkoS2V5QnVmKTsKICBtZW1zZXQoJkRhdGEs IDAsIHNpemVvZihEYXRhKSk7CiAgbWVtc2V0KCZEYXRhMiwgMCwgc2l6ZW9mKERhdGEyKSk7CiAg RExlbiA9IFRFU1RTVFIxX0xFTjsgCiAgbWVtY3B5KERhdGEsIFRFU1RTVFIxLCBETGVuKTsKICBt ZW1jcHkoRGF0YTIsIFRFU1RTVFIxLCBETGVuKTsKICBPcmlnaW5hbFBsYWluVGV4dENoZWNrU3Vt ID0gQnVmQ2hlY2tTdW0oRGF0YSwgRExlbik7CiAgQ2hlY2tTdW1SZXR1cm5lZEZyb21FbmNyeXB0 b3IgPSB4b3JFbmNyeXB0KEtleUJ1ZiwgKHVpbnQ4X3QgKikoJlNhbHREYXRhKSwgS2V5Q2hlY2tT dW0sIERMZW4sIERhdGEpOyAvLyBXZSBlbmNyeXB0IHdpdGggbm9uLW9wdGltaXplZCB2ZXJzaW9u CiAgaWYgKE9yaWdpbmFsUGxhaW5UZXh0Q2hlY2tTdW0gIT0gQ2hlY2tTdW1SZXR1cm5lZEZyb21F bmNyeXB0b3IpCiAgewogICAgcHJpbnRmKCJPcmlnaW5hbCBDaGVja3N1bSAlbGx1IHJldHVybmVk IGZyb20gQnVmQ2hlY2tzdW0gZm5jIDw+IENoZWNrc3VtICVsbHUgcmV0dXJuZWQgZnJvbSBub24t b3B0aW1pemVkIGVuY3J5cHRvclxuIixPcmlnaW5hbFBsYWluVGV4dENoZWNrU3VtLENoZWNrU3Vt UmV0dXJuZWRGcm9tRW5jcnlwdG9yKTsKICAgIGV4aXQoLTEpOwogIH0gZWxzZSBwcmludGYoIk9y aWdpbmFsUGxhaW5UZXh0Q2hlY2tTdW0gJWxsdSA9IENoZWNrU3VtUmV0dXJuZWRGcm9tRW5jcnlw dG9yICVsbHUgOjogU1VDQ0VTUyFcbiIsT3JpZ2luYWxQbGFpblRleHRDaGVja1N1bSxDaGVja1N1 bVJldHVybmVkRnJvbUVuY3J5cHRvcik7CiAgLy8gTm93IGxldCdzIGVuY3J5cHQgd2l0aCB0aGUg b3B0aW1pemVkIGVuY3J5cHRvcgogIFNhbHREYXRhPTEyMzQ7CiAgCiAgaWYgKE51bUp1bXBzID09 IDIpCiAgICBDaGVja1N1bVJldHVybmVkRnJvbUVuY3J5cHRvciA9IHhvckVuY3J5cHRIT1AyKEtl eUJ1ZiwgKHVpbnQ4X3QgKikoJlNhbHREYXRhKSwgS2V5Q2hlY2tTdW0sIERMZW4sIERhdGEyKTsg CiAgZWxzZSBpZiAoTnVtSnVtcHMgPT0gMykKICAgIENoZWNrU3VtUmV0dXJuZWRGcm9tRW5jcnlw dG9yID0geG9yRW5jcnlwdEhPUDMoS2V5QnVmLCAodWludDhfdCAqKSgmU2FsdERhdGEpLCBLZXlD aGVja1N1bSwgRExlbiwgRGF0YTIpOyAKICBlbHNlIGV4aXQoLTEpOwogIAogIAogIGlmIChPcmln aW5hbFBsYWluVGV4dENoZWNrU3VtICE9IENoZWNrU3VtUmV0dXJuZWRGcm9tRW5jcnlwdG9yKQog IHsKICAgIHByaW50ZigiT3JpZ2luYWwgQ2hlY2tzdW0gJWxsdSByZXR1cm5lZCBmcm9tIEJ1ZkNo ZWNrc3VtIGZuYyA8PiBDaGVja3N1bSAlbGx1IHJldHVybmVkIGZyb20gb3B0aW1pemVkIGVuY3J5 cHRvclxuIixPcmlnaW5hbFBsYWluVGV4dENoZWNrU3VtLENoZWNrU3VtUmV0dXJuZWRGcm9tRW5j cnlwdG9yKTsKICAgIGV4aXQoLTEpOwogIH0gZWxzZSBwcmludGYoIk9yaWdpbmFsUGxhaW5UZXh0 Q2hlY2tTdW0gJWxsdSA9IENoZWNrU3VtUmV0dXJuZWRGcm9tT3B0aW1pemVkRW5jcnlwdG9yICVs bHUgOjogU1VDQ0VTUyFcbiIsT3JpZ2luYWxQbGFpblRleHRDaGVja1N1bSxDaGVja1N1bVJldHVy bmVkRnJvbUVuY3J5cHRvcik7ICAKICBpZiAobWVtY21wKChjaGFyICopRGF0YSwgRGF0YTIsIERM ZW4pICE9IDApCiAgewogICAgcHJpbnRmKCJOb24tb3B0aW1pemVkIGFuZCBvcHRpbWl6ZWQgZW5j cnlwdG9yIGZ1bmN0aW9ucyBvdXRwdXRzIGFyZSBkaWZmZXJlbnQhIEZBSUxFRCEgRkFJTEVEIVxu Iik7CiAgICBleGl0KC0xKTsKICB9CiAgICAKICBCYXNlNjRDaXBoZXJUZXh0ID0gQmFzZTY0RW5j b2RlKChjb25zdCBjaGFyICopRGF0YSwgRExlbik7CiAgcHJpbnRmKCJCYXNlNjRDaXBoZXJUZXh0 OiAlc1xuIiwgQmFzZTY0Q2lwaGVyVGV4dCk7CiAgcHJpbnRmKCJcblxuRGVjcnlwdGlvbiBwcm9j ZXNzOlxuXG4iKTsKICBTYWx0RGF0YT0xMjM0OwogIHVpbnQ4X3QgKksgPSAodWludDhfdCAqKUJh c2U2NERlY29kZShCYXNlNjRFbmNvZGVkS2V5U3RyKTsKICAKICBpZiAobWVtY21wKChjaGFyICop S2V5QnVmLCAoY2hhciAqKUssIFJhd0tleUxlbikgIT0gMCkKICB7CiAgICBwcmludGYoIk9yaWdp bmFsIGtleSBhbmQgYmFzZTY0IGVuY29kZWQgYW5kIGRlY29kZWQga2V5cyBhcmUgZGlmZmVyZW50 ISEhISFcbiIpOwogICAgZXhpdCgtMSk7CiAgfQogIAogIGlmIChOdW1KdW1wcyA9PSAyKQogICAg Q2hlY2tTdW1SZXR1cm5lZEZyb21EZWNyeXB0b3IgPSB4b3JEZWNyeXB0SE9QMihLLCAodWludDhf dCAqKSgmU2FsdERhdGEpLCBLZXlDaGVja1N1bSwgRExlbiwgRGF0YSk7CiAgZWxzZSBpZiAoTnVt SnVtcHMgPT0gMykKICAgIENoZWNrU3VtUmV0dXJuZWRGcm9tRGVjcnlwdG9yID0geG9yRGVjcnlw dEhPUDMoSywgKHVpbnQ4X3QgKikoJlNhbHREYXRhKSwgS2V5Q2hlY2tTdW0sIERMZW4sIERhdGEp OwogIGVsc2UgZXhpdCgtMSk7CiAgCiAgaWYgKE9yaWdpbmFsUGxhaW5UZXh0Q2hlY2tTdW0gIT0g Q2hlY2tTdW1SZXR1cm5lZEZyb21EZWNyeXB0b3IpCiAgewogICAgcHJpbnRmKCJPcmlnaW5hbCBD aGVja3N1bSAlbGx1IHJldHVybmVkIGZyb20gQnVmQ2hlY2tzdW0gZm5jIDw+IENoZWNrc3VtICVs bHUgcmV0dXJuZWQgZnJvbSBIT1AgZGVjeXB0b3JcbiIsT3JpZ2luYWxQbGFpblRleHRDaGVja1N1 bSxDaGVja1N1bVJldHVybmVkRnJvbURlY3J5cHRvcik7CiAgICBleGl0KC0xKTsKICB9IGVsc2Ug cHJpbnRmKCJPcmlnaW5hbFBsYWluVGV4dENoZWNrU3VtICVsbHUgPSBDaGVja1N1bVJldHVybmVk RnJvbURlY3J5cHRvciAlbGx1IDo6IFNVQ0NFU1MhXG4iLE9yaWdpbmFsUGxhaW5UZXh0Q2hlY2tT dW0sQ2hlY2tTdW1SZXR1cm5lZEZyb21EZWNyeXB0b3IpOwogIAogIGlmIChtZW1jbXAoKGNoYXIg KilEYXRhLCBURVNUU1RSMSwgRExlbikgPT0gMCkKICB7CiAgICBwcmludGYoIlN0cmluZzogJXMg Li4uIFRlc3QxIHJlc3VsdDogU1VDQ0VTU0ZVTCEhISFcbi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS1cbiIsIERhdGEpOwogIH0KICBlbHNlIHsKICAgIHByaW50ZigiU3Ry aW5nOiAlcyAuLi4gVGVzdDEgcmVzdWx0OiBGQUlMRUQhISEhXG4tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tXG4iLCBEYXRhKTsKICAgIGV4aXQoLTEpOwogIH0KICAvL2V4 aXQoLTEpOwp9CnZvaWQgRDEoKQp7CiAgaW50IHQ7CiAgcmVnaXN0ZXIgdWludDhfdCBWPTA7CiAg Zm9yICh0PTA7dDwxMjg7dCsrKQogIHsKICAgIHByaW50ZigiJXUgIixWKTsKICAgIFYgKz0gdDsK ICB9Cn0KY2hhciAqR2V0QmluU3RyKHVpbnQzMl90IHZhbCwgY2hhciAqUmVzQnVmKQp7CiAgY2hh ciAqcDsKICB1bnNpZ25lZCBpbnQgdDsKICBwID0gUmVzQnVmOwogIHQgPSAweDgwMDAwMDAwOyAv LyBzY2FuIDMyIGJpdHMKICBmb3IgKCA7IHQgPiAwOyB0ID0gdCA+PiAxKSAKICB7CiAgICBpZiAo dmFsICYgdCkKICAgICAgKnArKyA9ICcxJzsKICAgIGVsc2UgKnArKyA9ICcwJzsKICB9CiAgKnAg PSAwOwogIHJldHVybiBSZXNCdWY7Cn0Kdm9pZCBDaXJjdWxhclNoaWZ0VGVzdCgpCnsKICB1aW50 MzJfdCB0LCBObiA9ICh1aW50MzJfdCkoMGIxMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAx MFUpOwogIGNoYXIgQnVmWzI1Nl07CiAgcHJpbnRmKCJDaXJjdWxhciBzaGlmdCBsZWZ0OlxuIik7 CiAgZm9yICh0PTA7IHQ8NTsgdCsrKQogIHsKICAgIHByaW50ZigiJXNcbiIsIEdldEJpblN0cihO bixCdWYpKTsgIAogICAgTm4gPSBST0wzMl8xKE5uKTsKICB9CiAgcHJpbnRmKCJDaXJjdWxhciBz aGlmdCByaWdodDpcbiIpOwogIGZvciAodD0wOyB0PDY7IHQrKykKICB7CiAgICBwcmludGYoIiVz XG4iLCBHZXRCaW5TdHIoTm4sQnVmKSk7ICAKICAgIE5uID0gUk9SMzJfMShObik7CiAgfQp9Cgpp bnQgbWFpbigpCnsKICB1aW50MzJfdCBCb2R5TGVuID0gNjQ7CiAgCiAgLy9DaXJjdWxhclNoaWZ0 VGVzdCgpOwogIC8vdWludDMyX3QgVGVzdFNhbXBsZUxlbmd0aCA9IDgxOTI7CiAgdWludDMyX3Qg TnVtSXRlcmF0aW9ucyA9IDEwMDAwMDA7CiAgLy9EMSgpOwogIFRlc3QxKDIsIEJvZHlMZW4pOwog IFRlc3QxKDMsIEJvZHlMZW4pOwogIC8vVGVzdDEoNCwgQm9keUxlbik7CiAgLy9UZXN0MSg1LCBC b2R5TGVuKTsKICAKICAvLyAgZXhpdCgtMSk7CiAgLy9NZW1DcHlCZW5jaG1hcmsxKFRlc3RTYW1w bGVMZW5ndGgsIE51bUl0ZXJhdGlvbnMpOwogIENoZWNrT3B0aW1pemVkVmVyc2lvbigyLCBCb2R5 TGVuKTsKICBDaGVja09wdGltaXplZFZlcnNpb24oMywgQm9keUxlbik7CiAgLy9DaGVja09wdGlt aXplZFZlcnNpb24oNSwgQm9keUxlbik7CiAgCiAgCiAgZG91YmxlIEF2ZXJhZ2UxNkgyLEF2ZXJh Z2U2NEgyLEF2ZXJhZ2UyNTZIMixBdmVyYWdlMTAyNEgyLEF2ZXJhZ2U4MTkySDI7CiAgZG91Ymxl IEF2ZXJhZ2UxNkgzLEF2ZXJhZ2U2NEgzLEF2ZXJhZ2UyNTZIMyxBdmVyYWdlMTAyNEgzLEF2ZXJh Z2U4MTkySDM7CiAgCiAgCiAgLyoKICBkb3VibGUgQXZlcmFnZTE2LEF2ZXJhZ2U2NCxBdmVyYWdl MjU2LEF2ZXJhZ2UxMDI0LEF2ZXJhZ2U4MTkyOwogIEF2ZXJhZ2UxNiA9IEJlbmNobWFyazEoTnVt SnVtcHMsIEJvZHlMZW4sIDE2LCBOdW1JdGVyYXRpb25zKTsKICBBdmVyYWdlNjQgPSBCZW5jaG1h cmsxKE51bUp1bXBzLCBCb2R5TGVuLCA2NCwgTnVtSXRlcmF0aW9ucyk7CiAgQXZlcmFnZTI1NiA9 IEJlbmNobWFyazEoTnVtSnVtcHMsIEJvZHlMZW4sIDI1NiwgTnVtSXRlcmF0aW9ucyk7CiAgQXZl cmFnZTEwMjQgPSBCZW5jaG1hcmsxKE51bUp1bXBzLCBCb2R5TGVuLCAxMDI0LCBOdW1JdGVyYXRp b25zKTsKICBBdmVyYWdlODE5MiA9IEJlbmNobWFyazEoTnVtSnVtcHMsIEJvZHlMZW4sIDgxOTIs IE51bUl0ZXJhdGlvbnMpOwogIHByaW50ZigiXG5cbk5PTi1IQU5ELU9QVElNSVpFRCBWRVJTSU9O IEJFTkNITUFSS1M6XG4iCiAgICAgICAgICIxNiAgICAgICAgICAgICAgICAgIDY0ICAgICAgICAg ICAgICAgICAgMjU2ICAgICAgICAgICAgICAgICAxMDI0ICAgICAgICAgICAgICAgICA4MTkyXG4i CiAgICAgICAgICItLS0tLS0tLS0tLS0tLS0tLS0tIC0tLS0tLS0tLS0tLS0tLS0tLS0gLS0tLS0t LS0tLS0tLS0tLS0tLSAtLS0tLS0tLS0tLS0tLS0tLS0tLSAtLS0tLS0tLS0tLS0tLS0tLS0tLVxu IgogICAgICAgICAiJTE5LjJmICUxOS4yZiAlMTkuMmYgJTE5LjJmICUxOS4yZlxuXG4iLCBBdmVy YWdlMTYsIEF2ZXJhZ2U2NCwgQXZlcmFnZTI1NiwgQXZlcmFnZTEwMjQsIEF2ZXJhZ2U4MTkyKTsK ICAqLwogIEF2ZXJhZ2UxNkgyID0gQmVuY2htYXJrSE9QMigzLCBCb2R5TGVuLCAxNiwgTnVtSXRl cmF0aW9ucyk7CiAgQXZlcmFnZTY0SDIgPSBCZW5jaG1hcmtIT1AyKDMsIEJvZHlMZW4sIDY0LCBO dW1JdGVyYXRpb25zKTsKICBBdmVyYWdlMjU2SDIgPSBCZW5jaG1hcmtIT1AyKDMsIEJvZHlMZW4s IDI1NiwgTnVtSXRlcmF0aW9ucyk7CiAgQXZlcmFnZTEwMjRIMiA9IEJlbmNobWFya0hPUDIoMywg Qm9keUxlbiwgMTAyNCwgTnVtSXRlcmF0aW9ucyk7CiAgQXZlcmFnZTgxOTJIMiA9IEJlbmNobWFy a0hPUDIoMywgQm9keUxlbiwgODE5MiwgTnVtSXRlcmF0aW9ucyk7CiAgCiAgQXZlcmFnZTE2SDMg PSBCZW5jaG1hcmtIT1AzKDMsIEJvZHlMZW4sIDE2LCBOdW1JdGVyYXRpb25zKTsKICBBdmVyYWdl NjRIMyA9IEJlbmNobWFya0hPUDMoMywgQm9keUxlbiwgNjQsIE51bUl0ZXJhdGlvbnMpOwogIEF2 ZXJhZ2UyNTZIMyA9IEJlbmNobWFya0hPUDMoMywgQm9keUxlbiwgMjU2LCBOdW1JdGVyYXRpb25z KTsKICBBdmVyYWdlMTAyNEgzID0gQmVuY2htYXJrSE9QMygzLCBCb2R5TGVuLCAxMDI0LCBOdW1J dGVyYXRpb25zKTsKICBBdmVyYWdlODE5MkgzID0gQmVuY2htYXJrSE9QMygzLCBCb2R5TGVuLCA4 MTkyLCBOdW1JdGVyYXRpb25zKTsKICAKICBwcmludGYoIlxuXG4yLUp1bXBzIEJFTkNITUFSS1Mo UmVhbCBsaWZlIHVzYWdlKTpcbiIKICAgICAgICAgIjE2ICAgICAgICAgICAgICAgICAgNjQgICAg ICAgICAgICAgICAgICAyNTYgICAgICAgICAgICAgICAgIDEwMjQgICAgICAgICAgICAgICAgODE5 MiAgICAgICAgICAgICAgIFxuIgogICAgICAgICAiLS0tLS0tLS0tLS0tLS0tLS0tLSAtLS0tLS0t LS0tLS0tLS0tLS0tIC0tLS0tLS0tLS0tLS0tLS0tLS0gLS0tLS0tLS0tLS0tLS0tLS0tLSAtLS0t LS0tLS0tLS0tLS0tLS0tXG4iCiAgICAgICAgICIlMTkuMmYgJTE5LjJmICUxOS4yZiAlMTkuMmYg JTE5LjJmXG5cbiIsIEF2ZXJhZ2UxNkgyLCBBdmVyYWdlNjRIMiwgQXZlcmFnZTI1NkgyLCBBdmVy YWdlMTAyNEgyLCBBdmVyYWdlODE5MkgyKTsKICBwcmludGYoIlxuXG4zLUp1bXBzIEJFTkNITUFS S1MoUmVhbCBsaWZlIHVzYWdlKTpcbiIKICAgICAgICAgIjE2ICAgICAgICAgICAgICAgICAgNjQg ICAgICAgICAgICAgICAgICAyNTYgICAgICAgICAgICAgICAgIDEwMjQgICAgICAgICAgICAgICAg ODE5MiAgICAgICAgICAgICAgIFxuIgogICAgICAgICAiLS0tLS0tLS0tLS0tLS0tLS0tLSAtLS0t LS0tLS0tLS0tLS0tLS0tIC0tLS0tLS0tLS0tLS0tLS0tLS0gLS0tLS0tLS0tLS0tLS0tLS0tLSAt LS0tLS0tLS0tLS0tLS0tLS0tXG4iCiAgICAgICAgICIlMTkuMmYgJTE5LjJmICUxOS4yZiAlMTku MmYgJTE5LjJmXG5cbiIsIEF2ZXJhZ2UxNkgzLCBBdmVyYWdlNjRIMywgQXZlcmFnZTI1NkgzLCBB dmVyYWdlMTAyNEgzLCBBdmVyYWdlODE5MkgzKTsKICAKICByZXR1cm4gMDsKfQo= --001a114690586272d30524b4a176-- From nobody Mon Nov 16 20:07: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 BB1DD1ACE94 for ; Mon, 16 Nov 2015 20:07:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 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, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hQ8EPXhsTfR for ; Mon, 16 Nov 2015 20:07:36 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 65BC21ACE22 for ; Mon, 16 Nov 2015 20:07:36 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 822E343347C for ; Tue, 17 Nov 2015 04:07:35 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 6BE24433402 for ; Tue, 17 Nov 2015 04:07:35 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1447733255; bh=Nmb6QvwWhIpzwbiZN4wuRo9Auw3fNkPcqLYrx/ZSIA8=; l=2214; h=From:To:Date:From; b=dbakf0lPyP9c5OedotROl1FAALNGqLqptOGhUJrgcxhYJ8y7Ca2YyxFKLrd2iFacE gYywx0ur/5Gngci6/4tK6ltAzVLBoTm41873Cp7hDrt9xjFA1fweBeCRGKBcfleO0j BJ1v4X1LWUR77/r7cggLaYf3Dg3Lfb4/ZRcjMY8I= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 683DA2027 for ; Tue, 17 Nov 2015 04:07:35 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 16 Nov 2015 23:07:34 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1076.000; Mon, 16 Nov 2015 23:07:34 -0500 From: "Salz, Rich" To: "tls@ietf.org" Thread-Topic: Is anyone using DTLS heartbeats? Thread-Index: AdEg7XgdfNa7utvdQDeSwW0JI9YSjw== Date: Tue, 17 Nov 2015 04:07:34 +0000 Message-ID: <00d157b8d3494e8992ad28ed6cf0bd8f@usma1ex-dag1mb1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.38.112] Content-Type: multipart/alternative; boundary="_000_00d157b8d3494e8992ad28ed6cf0bd8fusma1exdag1mb1msgcorpak_" MIME-Version: 1.0 Archived-At: Subject: [TLS] Is anyone using DTLS heartbeats? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 04:07:37 -0000 --_000_00d157b8d3494e8992ad28ed6cf0bd8fusma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please reply to me, I will summarize. --_000_00d157b8d3494e8992ad28ed6cf0bd8fusma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please reply to me, I will summarize.

 

--_000_00d157b8d3494e8992ad28ed6cf0bd8fusma1exdag1mb1msgcorpak_-- From nobody Mon Nov 16 20:12: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 42FCC1ACE9D for ; Mon, 16 Nov 2015 20:12: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 kW3i5-dgyhED for ; Mon, 16 Nov 2015 20:12:34 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::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 48DDD1ACE9C for ; Mon, 16 Nov 2015 20:12:34 -0800 (PST) Received: by wmww144 with SMTP id w144so7907369wmw.0 for ; Mon, 16 Nov 2015 20:12:32 -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=8ujDu+6toFe49rMP4Sv+B2a/8rMg8810VO4khN9HjWQ=; b=h2f2FP51aY9HGbbxxrbMkLLYU3N/BQRsVeyzT4FVtI+L8o7FjOxhgnTgaRJB2rGSTK B4ZfS/hQGtyrfuLyEKSqq10K4/Y7pNmd7U6ibAdoZWk59KBKlyyte9mtaYgjh9i4lylc Px4kqFjSDtOpKmE7fqkoMABAO6dvs6I1jIuVkcSBpWCI6+mdD+miN2mn4733I2sA0QUe pbGJoMF98ZpwoDlNPnj481eb+YJ7U4cDKzkS5Ti7fgwlJoQE3X1sYlt3J74a24G5oMJr VgKiOBOmiNUrvoH6w1m3g1AvdQHwMJ+SUL+Sux/S/rqK16EHGF20MEN6Zhjfp8oPCspu Djzg== MIME-Version: 1.0 X-Received: by 10.28.24.5 with SMTP id 5mr13329519wmy.3.1447733552926; Mon, 16 Nov 2015 20:12:32 -0800 (PST) Received: by 10.194.30.166 with HTTP; Mon, 16 Nov 2015 20:12:32 -0800 (PST) Date: Tue, 17 Nov 2015 06:12:32 +0200 Message-ID: From: Ismail Kizir To: tls@ietf.org Content-Type: multipart/alternative; boundary=001a1146905826d64f0524b4bcc0 Archived-At: Subject: [TLS] Hohha Dynamic XOR Encyrption Algorithm Source Code X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 04:12:36 -0000 --001a1146905826d64f0524b4bcc0 Content-Type: text/plain; charset=UTF-8 Hello, Unfortunately the system doesn't allow me to attach .c files. The documented source code is on my blog: http://ismail-kizir.blogspot.com.tr/2015/11/hohha-dynamic-xor-algorithm-source-code.html I am also regularly updating the site. Please feel free to ask any questions. Regards Ismail Kizir --001a1146905826d64f0524b4bcc0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

Unfortunately the system doesn&#= 39;t allow me to attach .c files.
The documented source code is o= n my blog:
<= div>
I am also regularly updating the site.
Please = feel free to ask any questions.

Regards
= Ismail Kizir
--001a1146905826d64f0524b4bcc0-- From nobody Mon Nov 16 22:29: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 A8C691B2AAE for ; Mon, 16 Nov 2015 22:29:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uct1ACtLfIf2 for ; Mon, 16 Nov 2015 22:29:55 -0800 (PST) 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 8F9731B2AAD for ; Mon, 16 Nov 2015 22:29:55 -0800 (PST) Received: by igl9 with SMTP id 9so73164782igl.0 for ; Mon, 16 Nov 2015 22:29:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Nih4DQdU3oP1gZVx88ANk5SUrcPp3DUk0YpJzrcNXZ8=; b=KtV+D/HOdNi8U7amyVmiCE+bCx05J1BGbF8diQb6zirCrDTOL1NHxPLaj0TZDgPKCD UCj2VkQ61+Q1kwaxWvudzd/pTaFX5eaw/KR6NXKXJ9UVDgy+YF/jGamqFgmlowpVA6vP dh8l1DaXBbYtpzRo3l2zs4Xu+QRIHVh8JfPKUmJNIdJMBDLqW067rf9sx5ZZLjHbSJLS A7vAb12/Oe4mO809QC5ZPE7wmtT0790MvzEYI9r3iSIU5eHhk3hXGrR9hXG26iRJYpYk auPLtl+BRO2Jg7N439ptx8ssZxNyoazeJUhYpwn3DYhwv9E2J6r0lsZ5Lk/PcgpznSGf SviA== MIME-Version: 1.0 X-Received: by 10.50.6.104 with SMTP id z8mr328500igz.58.1447741795014; Mon, 16 Nov 2015 22:29:55 -0800 (PST) Received: by 10.36.155.139 with HTTP; Mon, 16 Nov 2015 22:29:54 -0800 (PST) In-Reply-To: References: Date: Mon, 16 Nov 2015 22:29:54 -0800 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR#346: Individual traffic key generation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 06:29:56 -0000 On 16 November 2015 at 19:52, Eric Rescorla wrote: >> I have to ask why the continued insistence on calling the thing that >> forms part of the nonce an "IV". I find it to be misleading. > > > This is the historical terminology that TLS has used. It was actually accurate when we were using CBC modes, but now it's just confusing. From ikizir@gmail.com Mon Nov 16 18:29:50 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0771A00EF for ; Mon, 16 Nov 2015 18:29:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.921 X-Spam-Level: **** X-Spam-Status: No, score=4.921 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, GB_SUMOF=1, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_66=0.6, J_CHICKENPOX_84=0.6, J_CHICKENPOX_92=0.6, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_FREEMAIL_DOC_PDF=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 APCE8fJZxrjK for ; Mon, 16 Nov 2015 18:29:44 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::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 CEEA61A7D82 for ; Mon, 16 Nov 2015 18:29:42 -0800 (PST) Received: by wmdw130 with SMTP id w130so136221016wmd.0 for ; Mon, 16 Nov 2015 18:29: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=hUyb9Ki62zO2q/X6chMbgtS6utLrY1J6r0Yx+8qqR+c=; b=eTRcGILYTX6tAS9CJLSr6NTqgBOjnMSVMfiJW7tkEoRbtcL4l1y9XGY2lgY91Hcktj JlyHzvasBJ7PkHw5rL79UZAXkT45bemW6PdL/y3mYdUxHnHk4IuniWYBVwh9YHxssobU PYNVsiaBQKeToIkpe/PVkPFq8FHLzzRuiCe6hZeCNECECiyInZb9QI4vOLXziIZmXTnq 4Ny1wSUrM5qJaVX7kPhyk+IbmYbpeo4cjr9qeHHWcVCy8yuGdmvN2INUDB8pkpktiAQz Kl4JSdMbL6EqvWXt3/yBB1pFFAvpb+ZrjqW6O/6x0Jlr1T6WuUHbZ5skAeNsMgx5Q+f2 WPAA== MIME-Version: 1.0 X-Received: by 10.28.1.146 with SMTP id 140mr23776659wmb.73.1447727381320; Mon, 16 Nov 2015 18:29:41 -0800 (PST) Received: by 10.194.30.166 with HTTP; Mon, 16 Nov 2015 18:29:41 -0800 (PST) Date: Tue, 17 Nov 2015 04:29:41 +0200 Message-ID: From: Ismail Kizir To: tls@ietf.org Content-Type: multipart/mixed; boundary=001a113c8fca4c94a70524b34c81 Archived-At: X-Mailman-Approved-At: Tue, 17 Nov 2015 04:46:58 -0800 Subject: [TLS] A new encyrption "impossible to crack" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 02:30:28 -0000 --001a113c8fca4c94a70524b34c81 Content-Type: multipart/alternative; boundary=001a113c8fca4c94a20524b34c7f --001a113c8fca4c94a20524b34c7f Content-Type: text/plain; charset=UTF-8 Hello, I've developed a new encryption algorithm, which dynamically changes the key according to plaintext and practically impossible to break. I also opened to public with MIT License. It is also quite fast; ~80% faster than the fastest mode of AES. I will present a paper on a Turkish National Symposium on 3 December: Inet-tr 2015. I am sending the document as an attachment Sorry, it is in Turkish Language. I've studied political sciences. Unfortunately, I haven't mathematical background the proof. But it is a very simple logic. Anyone who looks at the attached C code may understand why and how it is unbreakable. On Linux simply gcc HohhaDynamicXOR.c -O2 -Wall ./a.out will make integrity checks and print benchmarks. Other algorithm results are the output of the "openssl speed" command. If I am right; you will not be disappointed to include "Hohha Dynamic Encryption Algorithm" on TLS 1.3 Draft. Here are the benchmarks for 16,64,256,1024,8192 bit values. Please feel free to ask any questions or any explanation I can give. Regards Ismail Kizir *Algoritma* *16* *64* *256* *1024* *8192* Memcpy 663.42 1052.33 1043.33 1147.54 869.60 *Kayan XOR-Hop2* *162.33* *193.15* *198.17* *198.65* *202.56* *Kayan XOR Hop3* *116.46* *127.42* *130.00* *130.36* *127.33* des cbc 44.98 46.53 46.90 47.14 47.05 des ede3 17.65 18.00 18.03 18.03 18.06 rc2 cbc 26.58 27.10 27.28 27.25 27.35 rc4 22.22 36.02 41.81 43.71 43.63 blowfish cbc 84.71 90.58 91.71 91.28 91.41 Cast cbc 81.23 86.99 88.62 89.00 89.10 aes-128 cbc 77.85 85.20 87.91 18.27 18.59 aes-192 cbc 65.98 71.70 72.70 15.53 15.65 Aes-256 cbc 57.59 61.22 62.43 133.67 134.40 Camellia-128 74.04 109.17 124.03 12.87 12.88 Camellia-192 62.57 85.60 94.68 97.20 98.11 Camellia-256 62.58 85.63 94.69 97.35 97.97 aes-128 ige 78.44 82.05 83.08 83.42 83.17 Aes-192 ige 66.25 69.13 69.75 69.95 69.94 Aes-256 ige 57.69 59.71 60.22 60.40 60.27 --001a113c8fca4c94a20524b34c7f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

I've developed a new encrypt= ion algorithm, which dynamically changes the key according to plaintext and= practically impossible to break. I also opened to public with MIT License.=
It is also quite fast; ~80% faster than the fastest mode of AES.=
I will present a paper on a Turkish National Symposium on 3 Dece= mber: Inet-tr 2015. I am sending the document as an attachment Sorry, it is= in Turkish Language.=C2=A0
I've studied political sciences. = Unfortunately, I haven't mathematical background the proof. But it is a= very simple logic. Anyone who looks at the attached C code may understand = why and how it is unbreakable. On Linux simply=C2=A0
gcc HohhaDyn= amicXOR.c -O2 -Wall
./a.out
will make integrity checks = and print benchmarks.
Other algorithm results are the output of t= he "openssl speed" command.
If I am right; you will not= be disappointed to include "Hohha Dynamic Encryption Algorithm" = on TLS 1.3 Draft. Here are the benchmarks for 16,64,256,1024,8192 bit value= s.
Please feel free to ask any questions or any explanation I can= give.

Regards
Ismail Kizir
=09 =09 =09

Algoritma

16

64

256

1024

8192

Memcpy

663.42

1052.33

1043.33

1147.54

869.60

Kayan XOR-Hop2

162.33

193.15

198.17

198.65

202.56

Kayan XOR Hop3

116.46

127.42

130.00

130.36

127.33

des cbc

44.98

46.53

46.90

47.14

47.05

des ede3

17.65

18.00

18.03

18.03

18.06

rc2 cbc

26.58

27.10

27.28

27.25

27.35

rc4

22.22

36.02

41.81

43.71

43.63

blowfish cbc

84.71

90.58

91.71

91.28

91.41

Cast cbc

81.23

86.99

88.62

89.00

89.10

aes-128 cbc

77.85

85.20

87.91

18.27

18.59

aes-192 cbc

65.98

71.70

72.70

15.53

15.65

Aes-256 cbc

57.59

61.22

62.43

133.67

134.40

Camellia-128

74.04

109.17

124.03

12.87

12.88

Camellia-192

62.57

85.60

94.68

97.20

98.11

Camellia-256

62.58

85.63

94.69

97.35

97.97

aes-128 ige

78.44

82.05

83.08

83.42

83.17

Aes-192 ige

66.25

69.13

69.75

69.95

69.94

Aes-256 ige

57.69

59.71

60.22

60.40

60.27
--001a113c8fca4c94a20524b34c7f-- --001a113c8fca4c94a70524b34c81 Content-Type: application/pdf; name="Hohha_Bildiri.pdf" Content-Disposition: attachment; filename="Hohha_Bildiri.pdf" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ih2rdn8w0 JVBERi0xLjQKJcOkw7zDtsOfCjIgMCBvYmoKPDwvTGVuZ3RoIDMgMCBSL0ZpbHRlci9GbGF0ZURl Y29kZT4+CnN0cmVhbQp4nK1cSY8st5G+96+os4FukcEkMxNoJNC1CZibxg+Yg+HTjGXA8ALLB/39 YWyMYG7dTzYe1FWVxSUY6xcRLIW3ePn15Z+XcHkN9e1QxrdyKaXU97/86eV/fnf5+0u84L9f/vyS w9t8iePbdElTrAPynN6gDrv8/DtaAf/VYddvLxm/HOvob/93+eFZpw+Xbz//4T3EJb0HCGl5hfcw hFzfD/KphDFM9GxeXiOO+qifSrgucX4Pt+W1vId7yAvgTPpUv6nvefSDntBaM671xLkxLDG9xxgB x/DfcIspDryDvi6v4zvvVNe7hTt9/sJO7Rng61TXWP747b9eHt9eftrhR2XZtOIHE1gXw8PSUjEj h3RVpK9+lINU0jJuHksdg7TjjnGsfMPTQkzEr5uck+jTE9ap9s1tGfFRiZNslJc4IAMeddjEU4Rl PP264NdxrrK5+XNHJLrSc2UBxhs9vAf8dztnRslv41o5bvUMgOvR0eqZi0llqIx5RRbEB51LZVno qUhOuUU8RE169kw9oSdBVXulJ7JwnpVPuG0MtENGCut6A+2OHMG/EJA59DhMyFh+m482iwENLKdi xlHekAHvEJdvfzmiD4IqD1yGNyQQjelgfELbjFO1TZkxMoOBVDexApPMc/1X5PlIhjaJKn/Q91cy p4m1E+0B8Ii37ts7vX+gtJ4sAfq2yu8VBtk0xgW5SNpSFZX2w6WqqKeoE3JlIM0n2qpolcw48uYP mu72wAkwNaoGoarO4JUibYgLyQOh5mNBJ1H1NuGupSr9DcdUw4fQVnuQFj4WmEnUuFxAPep4wUvx 0LLgbH4/Ezvqh7UavOUQ5+IkGxKKv5MTnTPzy5M5i4eqqlaXrmqCLBGH47cWvj49Ezulj0QC6oZs +79/ewn15deOtP/+8YWCQbn87UIen97/9fL7PcUcyvSWm+EEoh+A/MFEVoh/EvL5SsQdOoURDcKt BrpanY3OpS4B1UsuZO0JT4x7fNDKyAz68BpRryChslXzrRsCKR4MbhIMqLaQ+QtSYagO64OVUtbC /aptXEngC2nSK2kgOp8HCfpDPTU/xxedPURHKiop7hGhkjHJZHLhwMFKyK5rjZUgWQJkibaiEFNk 10ZMbkPD3XGFx/gHNP0hoiGKThzikJuDMknQ3hMSXJAJic6B74O8FuMd8fvGu+mr8HrgcY7TLCta Ju2NiDqkk09sPDo4pfIFbR93rooZg35rA+swfXTAEChoJkNxTjjj259xhX0nDAV2mIg2eujkhyGb K1Bbqpb9fqQ3iVwWHQ3dWNOWGtgHHl/fEdf1tfJADWLqFcyzjBjNA+X57P6K2sHItsFSAbWYIrMn VVaRrVMN8AaE2IG0n2gxgRGtsxNmmFdCnpyety9/uw2Duo8zq0jJNEAkVDmPzJxiQCbX/6osyP+Q 0qtOP5kdWwe1b6yqkjH7Y+PaAXczV4AKQEb11FPCVZ7YRLcwywUJ3rVV0R9+/3QmHMCGBj8oNwfq zFR0h8TBevKwA0ZHGLOAJQxBdLh4heSTQ1uRv4+NJZ97MoC3tLaqublSYYSepikP7cTCI/jhNbhF HIpKqnTOQFnlb+7MnrsHXrKph7hWXnciRsDWe/GmAeN80F0mPIBjlbdYmfLBgdTJg0c+mzVzZGz8 b6Gthq94ZccBg4ZPPlJ9FffMnKWQPTC61OjWuD06Zp/JLQZNEczWfqtsxH0yayK7RDdHoji9D5TG gIICUj4gs+ZpJByIcVI9NL+rZ+zCXeVNCMIlU2do/JWQ11l98WHJ5EFU7aIbDa1mP6IFgw+I8zrs dpoocuocxusnDjHNs2UZHiZ4tddDmtPK6rYI5eLAq8Bo8piOhK+YY2dFsu5vRXGq8g6uZBGrBUS2 B9aoxJFJHVJce/IerYr/V7Hd1a+r9ZmpyJR5y0bYYXCFQjfTFXl6Krhp1ITXBPdA27x64qfOOSSL R8KF61ISYpqTjUYsJa02wmwLUoN0PoJCByxPHCmbKFvISOURFR+04FdMa7wcGo512NCM/cYZ/7gA VlkqQeiymm6KiQfl8daTrrGYeQ08FDQJU2D0Z2sEzZ+Y+Z6TJb26I1h84J8n1kXgCwZchm3G9Z1e JKxxfqVkbLbuxWa+eYPTJkp/tlrcAA6Nutvgtv2hOzAnzrs9W9AvioQOpykSdfQKorbzHAblq9oK GZQ68y04VYemyIGVwxuA2X+EDqc5utux1DhtOBvnZwgp5bTO4Em3gCtudMA7vcdEnqqQVGfD5Lny MVOmH+m7EZ9Q5S5yEYDy/7xw/h/PCgAxjVUTGy2G1W7f6cYtJ7KgwrDXFnBI28UXndibFjkFTMO6 kN3RkLe2F++Ezh4rxCsK5ZLPTArzfVSSE3iKeOrfFBagHc+kPMRNdvkfgsD/NvhtRr5i/Hlkgdk1 GJziossla0iqfFj0X1whCk41ccaI5VZv7EqRS3EiH8VsBIJjZIuJYW5sxTx9bk/h6r3oXY2XPYsO xJcB0M8XW44sXKB2y/AVpphX82CfY4WtKeELFwy2MAPSbi+/OU7kRTOBk9Aet6pUWHhMDLCil6Qr yObRQU7PqsqUdV7piGzccFv7qHLWYkhx2uR9R+W5xIyqL6uqmx1ly+Iqulx0nsgIkQEFsi5WTmvR 1JCZ/K4MNpCSbM+E8xZfkDND0O+Fc3DVowzsG4a2QoKFQedQ+kc+ycAmBrQ1watoqxfI0EdHMn6b KLjA1VJQZlMD0G783QlaGIGQrx65HUmCoh7p2emEG0YqkcqaU3XWiTqEsind1I0GuMZVLUSlWkVB QOvcbsusg9nmsn0Wofr0YF25krpTaTu2FDDQ8QkUB684dXBoO5ifsW2VXPHeHw0vjWCUxqk/6BpM lvUhCMQGB7vWa8JNdpSI0ZUPaXp94rlDgcsx5e792ZkkYc77OSdVL0EPd1SNKBrOJWZpPXtl2nt4 Omh5Ut1CQ4WV6V0OaRn5l3LykKWOIhgR1dInYFLx1bSmJiWotuBTE6VZLXw0szhNaSy3I9/18VnU hbITdSOUUEJcZgWNFG0b9pOH0gtiGMhQ0TWJtPHdgOeHTaIucJLePI2F5Hrz3jHPbZ+TMwzDJieN H9Ru7gDMDC5+jpYycua2RjJ9VV5i7zhjj3MMzWgU9NjaVjv3frkuMfESk64K/TyqIWl+0ZdLLfbj 5KxWdsIR63+bTTmP7YFcV2OYWsCpLzCs69qbbowPmVmzFg+S90B9Ad0h5igs9E77pJ6ZVuVMkpHA 6BN2wFo9qAQ4qag6/sbWr3LZnOHaGHlkOdIEeE/EN184JBgl6uERgERD9Q12qEaN48XYpQ3rauLJ 6cO8qQl4d946Os2HWD1THC9rZuicKnSl6spPUaTJlb77qujUsgitDHw5p412+2hl4qqN655hV4Kz mo0k0zQc+kYEuwFf/NN8T9IZinpUO6bPnQ8Jrbtiq8KgHWryMdINyJ4LrnhweMUEjz+VbSvRy2jk U5Zx7jq5LRreUWFnG6N9hg7QdvlgV6q8Nn9VtRsvLU0C+ZMggIJgtCwRpGuxdaMnhxuHLZRTJ6rG selYwsaOWEkNxg/z+0r/TEgenA+z9RutmAQKliexD+oG+km+VmQVYduc0IoWj9gD+nLZdMaSkjbJ jpRz5fSm2dHiyarr2tsEV6NYhzsZN2vltYYdzXwVpxdXQcGQ6b0bI+qPSm+7CieuXQA54UGO24ZR ruRdm9OedoIiRSCBrl3Q9UFoEgNueS562lbjXEdEFxsEUWU17cbcqbj4sWo8mF8fN379NIxXbLeF xlhZd7jdujAtpkfJAOPA17m6OxI9ed3QxsP6UfQBk8jJjOa6WAHeW2Tpp/hetb/n4lce5vdOW9ff 3c+VA6YNwDntCrK2Chq3mIXODDSzcAGlA/itVWdqreenm0hY0qf0eTyjOI4bkJomuQ1ijVczLsZX c9OrlkjOe4o3z9bNaOrgAK/IAitEg4XxuWl/Ywpfe+jh6u7OJ0cNeduEWJXZcDPRPYBD+jj20gAZ yCk87EsJWA7e4vzcZvuQ3ILY0WW9oUupMNh3opsSaj5EiY4PPm8KssMWHnWp37pYduOW3bYb0xry Ow0Kf0PgykBGEXt1omeZ0wQbWEFGED2TzKC31L7CDrkchUGsGeefUthdiXECSJ9icT+09R+t1O47 fbn562NujGGDMdkv7EaOAitHtqO9FKazeTXXwvCh6vxynylzFPDhvHXsmReHT0ac3Jmet5DDOyW9 GXL3RbJjS/R0u6KaxZjRilLmSltpZaiRWcrZrnq14o2Aq54InyTltndpraPRsfbsvsq4fzWMxYZO UpR41yQdMsqa0/qrCbBDjMK30yZJ2QCCZrCjnXS7e0uURdfubfxItuOaochziSojSdguH/ZpQkOA xU+opPTlY3UQ6i7q4NBSaLACAA+C01wBhj1M2CJFEgyKr9Hq9q3gDUFqeSnZQO0KrgBNEkwsa7UE g68JdVnWFRd0o3uvRV/DZjEJ0qPii+6amGf0YW4PVUeTr+CZ4eaWDJVtu/Lwfu3dmwtHWt8ycSto ZvwU8KNGWgS59Wa6sUuaLsVm1AJsOzmIKflM187cSUuPaz7CmbxtGe0LO1kUfYgWqpsq5krmVoL+ N648a03YJQA0obss2d0Jkrz72C/IaYdtR8SXSK6tcYSB6CnX95M/xPoaad+Cqi9pXqav6QSNxMm5 n9zVBq47beXcI562zpoIEF/MXjgd/hpImJO2TQYl5e507rCpXaTJWYLFKxxdgj3nXwT094MK6/Fr EQdA466ADQFqwpZgz3399xCnyHkg7TnCA9Z25bcOeEy+pIlVyn2sk6ANOEbqYNdkrCdM7hBv1fFt U1d0crchPrPjCNv6fnZNEb9W59tEgUGUEPHiKizsuHIQX0ajN648rdTVodBh7duNN30B3NeLSu+D e2I1lwtNmueMCmGbFX+qFXt3DSeuk5rYtXqTrZhN6gL+JgE9mVpR0VULup95tPqNV7zPvcrp0eO0 iYEHccgSDanrwNybdBKThrkVfLqWZpXGTgBN0Watc0qFJfxdjxaT8A60LeXKclQAVVmdH38cNyk3 olSu5XXi7q/A+WuMrS7oI+4Xo08seXu/5oOOehZkCLRZ3XD9Qwq71NAsKTt0+bFoeTF+L16xeV8X sWIkK3RainXOnDxs82ywwqkuGKm/sMZB2fWR/Mh1wtvMFQ91dejiC1lmuvbzpVmoe9OdHWWZKzjf VrOc3/Ptg+kM1QuLBtg2AQ5una4Ln9XCRvHBo2bjVG1N7iGZFliJv1MqKm2NUo/C4VLqSwwx2kX/ 6dBvf5ZRyilT3CJS56fsd0JfKAao3Qzr3nHTKy0GcHdWM8762VUk2IG7J9tksFUwkjY1vhPEwSdo purOBs3s9CFOApVVZ5vIrtqDXLUpjxttacD/ZUKs0KoFUf5ZIDVf4kkmloa0e4zqNivjDn5RyEcP 0waY8u1UuUSAdEsmChhecz2hBqvA5RiQgEyvaREN2P7ESvrSzpNBtJl9QqI5Tbc3IVkInhouL5ih fqWhySefyxarcDwarHIvf9ntSkU6jqqGX++/T2YJ2KYMroDe7vzIj574J1F2sYDxrDY8B1qgVatc nL/SpZyK7A+VfQCWeLBQvdavOH2a7095+wOMDUZtjlGLuOaz97Bf1+A1+7KbhCc/Sb7z6iCXQFwt fmy3+sC6E+qHrt20z439lCdj2kE/Hdq0gmORlpZP262iZWUMDxmNcitaaIgMuprbYOewrg7pmgL0 G/++5CJaTRz2V8u0GfGJLy07aa7ELjJwUeRp7i5sr8sBrYrf9Z82EWavAetaoZQi5rDC/m7N7qc1 Lti5AK3SOyLklBk5bO/Iu8KYzwe6RI34LsUPKZPSq91ComqK+8YVt2zV7/t1bl1I6jOqQQbRP6S6 1ErFX7j4xCxI08EP/7UCtvsrnRVlvnzpJO1LpH220OZrWkRDfHAwy0jBarFcXtu/8dFswXJ2/t89 SP34E6gxwFDZ4WGmd74TdsoPZ070/0ha//g/jaehnbz9KiO6LatG6iq3cfeM+jSxXWPq7+zqL8Je G5LrPvbX5cTtpJbBeLjA4Qy2rJaB7nJAI6Xl8XPb1Ln/vmuausD20+Wflx8eP/4+X/78r8sP334Z Lvd/XH56+X/9jADHCmVuZHN0cmVhbQplbmRvYmoKCjMgMCBvYmoKNDYxNQplbmRvYmoKCjQgMCBv YmoKPDwvVHlwZS9YT2JqZWN0Ci9TdWJ0eXBlL0Zvcm0KL0JCb3hbIC05MCAzMzIgNTU4IDMzMi4x IF0KL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCL0sgdHJ1ZT4+Ci9MZW5ndGgg MjUKL0ZpbHRlci9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeJwrVDBQMATionQupxAu1xCuQC4AKcYE BAplbmRzdHJlYW0KZW5kb2JqCgo1IDAgb2JqCjw8L0NBIDAuNQogICAvY2EgMC41Cj4+CmVuZG9i agoKNyAwIG9iago8PC9MZW5ndGggOCAwIFIvRmlsdGVyL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnic tVzLjiw5bt3fr8j1AFWtd0QAhQQqK6sMeNfwBbwwvLN7AC9mMO2Ff9+S+BApKZRZ1zAaM1k3M0Ih USJ5eEiGebWX//nxj4u5vJj8Z0jba7qklPLff/7nj3/9y+VvP+yl/PfnX39E83pc7Pa6X/xu8wXx 8K8uX3b54y91hPJfvuz280e0l2RsHunnf1x++3IXay4///i3N/N53d5sur64N/N+ffEuvRlXPo83 a0y6+jdzrx/2lr/1hn81Eb6GWz/r/+/W9YOYgFeUi52DC/l5efQdr6OHOvj6Lq85+ptu5f9gqAOf n1fxdX1Jb/Z+/fef//zj8+eP30cJxKNIVEsgP1HO0X5enXmzH3VwUz4PV2e3H72wdljmdry5o9wZ rpuBQcxep4ijtMHlt7Ao+LvO3JWl5enXJ8G4Wci4XnrYfi6i3fFtVTRuYynhziwEs+2vcRQMzQg3 yOFKnbOwQJCYyx8vHuZ3nIjBOx7B8ca3YdUWmC8a2sWrNUJggUfJh/PpUWyEjSxyWMkgbb0EImqA s2UeMBgPVdddRq8ypqnZMwk4mBEuJn7jVLw4VChX1nine1K+yecvPa7fHG/+frUODqcL4h4+RovV x/ga+vV/Xn1dSJnHzci5tfnn3+Qad60yzlXJfbYFzfU436dOPqghyrAcq3KZNU5rXLQ7DDeXJkym fLp3qUE4HXiEtEigNxGnvBBW8NnuDpa0V7oyY1iRtWpJ7lY1JU/OOpJyqKu8oU21bTVZZn4r3yQe yvirFKG9lR1PYkUWj2O5WG2BWCdeHcoQoObWtdnCkXe+PsDVyXUTfbFezOi+ti/evfrF6crDWY/P JLEkOm5PyCiCLhww/1R00IWiTPIk2p1P2M4nCNb/lg/SQQf64IOSl7+L82oXjihrevnGLaXgTPbU WgpoWtpo9UGxLBTOUt5ZWyakjVuzvrHsXFnVqGrGoYZspwoCt6IpK2Ogs++MHF0INgBmG62rDjF/ t1iyOTIg6TTlDgN0o8mjGemKKNUKHVI253QZzirUc5OEBd0nB9YXPTqfaji218EDvF+zWu3o2cjt 0WHJ/8xmC350vs4B5P7OyEivqk0TFNY4/+m/jL2GPE2LeyEBCOsA7wUchnJJMEVvAZPEEViR51ut eE8jHIq8SPBXe/Z4u7AN+TNYPFV49OmE0DXZPntzrfgJMeTOx7xYs9C8er0NPVgxltl3BqOx3buw fQU/JGH7HBkNvKMejGwX4BFVJxfL38KAh9HlZ2+XWA9nB2yOBVifTDYrEiLdTUM9dcD67ZdQRB6B 1Lmapr0esX2JW0IaLCticzqkAc9UfnhAAxg2sG4uEGoPG8g4ZOtpDm0tlOu/qbPZSyNsjh8Aotwa upnIa7GuaM8wKbtomM/RNApVXgKg6gLJrAmg72AyEmMiYCCwWpy2y37kVqQ09YFVPwDWeMRaeCMo dvZCfrVEfww4Am/MTwjx4B2B52rXODHpAYOAuomdoxiA6x2vw+vdjX0Pfx3JCwX1dblaqkRc65nb T6Cl81WOuwjzurAOPCvjKY8e3u+HRqcOccTOIDtY1y41wsHeyVZoR57HTnzDoAD1JO8zfV0t3KbB 31vHq5HOwMOQGoD2i8fz4MOBsE3Ok+Hli0dNLtdJ7Yu9sp7M3G5HVryQwQq7w1jW8UeW3fXnf01v 2V3e4tl6AY8hQMxLEFNzzxg3E0fg+CRHgK7yBbVYuGaB/IvY6yF85+stgUOT7yrusI7t0GPX3zsm QDzIBNw+NA5CSfeJ6/CrmMwffkAkZFfyzXgcyucJaEBrUK4oxh5C4ioBI1Dri0upjeSGb9DCUUBL js6hNSgB6P8di/h8gnqgiFQBjCSA8mkIyTvpDc7/OOSNhKiRdzIHX8SzvjGS4Ccdrl3WYjg0++QT xdZ24Zucy4MwyW9mQCSoJqf43W6InvaDdqceLjifFo9A/VXA0rrLFg1F+1ERdKM9UqPd+yEA9YgZ bT0lI6KWlRTiMcDS5hWJLJz7xPyPKEmicC464QY9jxmym8vXbSUczRjWNtqqwk44aCJOQ9tAYXJA tFvlEBprNhKfS57Sh22APioghzNMFq3apargIkqlGAkjweohrT62xvGhd5UGjRA0N4P1gFapKBWH uB5vveosFugH4N1iQQwa7NahHK1lBmhF16jmGQHjreCWZ8HwPuJAj+SJt23nqiITr21RXTK2A2Ys 5CnT1BaLdmHEQVNkUj7R6hwMtZr/6oweGzRim7SulwOC0GZmDcWRlrqvtqOovm00+Do60JawOz4L 6Vg3cmpiFrFZj7IZAX1uMId62IgMGFfBHPAfvuBZ5BPLGEXxbdV8VzX/xaeNf7SCWllof5nVwTdN eLel7Td2QDrVem6cidklMczEA/JY52oowIvU7ihWwnC7cW1whwit/A38GgMdAWBTi73IHhv8A67v ABNYJLtCfm4/RvD8aPrMahImtPi9COnQkAaioRgWNZ7d6jMlznf1sPmC+YVD3qHkTkRQmE1FO8Ry 0it36LZ9pNBO3WpecSCmJhwnFPl+mo5jhOiiDkDKobMupjZ0Hx1tg8YDaFysLKWRcSPSAkBH23AY 32gXBKpQ6HGP9H6JEMNWnfiZqCHCo9DQqXMTYNoc1d+7mBOMsDAEDCFozEOACDAlCwHEOCCd54BG hjloaQ6ZqAvty5sL+bjFZsJFhlRcB7Lye35oOGVHbSrUaA4GdDxYqNyr3Ra5ErsVVD9bJjN07Krb glqOy8topqdqnojAXfBjyhuAK6Jyayg1cDQWcjza2f+166s9VmRTEhGViCflPeemi1xrvUyQGssI 4wSWLUThh/Dq65rn91H3Pzs89HeFY6UoqDIeYrKTuIszTW6MiiVrG8C0NPA6oFROJ7knCRs9/kOM tBCNMyPcdt1qZBJWpo1EVo883WBTaVKa2eGDgvG0b44CqysoV47ARSRbEbSqBHBhHe01kSsQpm8Z bDizD8CLfSTByy6PQVFYm6pM2KLf5YQa7dOpOxoKJZauST+fyG7HXqc97pf8rT22EaZPeOdEG9AM l/8otvvRQUcnGidRxFWga7ouVBnT3V5C83Ithrvx4Lxae3SzqoXHadgQzlA8Zc4WwtnjjNLsjF3F pBSOUnxSdVrWuXBKyQjMquKO0egEvNWKvLqQxx1zVnAEnbTY+IAm4acyugtJbGHE6wgo2wMw3LpR pM5ZFtp9OlnrA6+QM02RUy2JXJjMGOjYaWfEGHJcvU2slFz4atnJDZgN0ysmCloRPt00CKrwX4A6 GT+KooR5kn8xtWgHoBwKsDnJhkEyDrOqwvk4He0pP2MFBHGUJWfzrEheXR+B4gfoIGs5BA0lc6yy LoAg+FIx/TEiHZhKxoEiV1MnGFI7OlZjxLVGMFobk1NjxCgA3Hhem3xDbDrR6QE+zq3y9tbtk6K+ DhA0tAZBLhDfO9Lcezg0V29LtdM2h50f5T7X7jPO44nSlSLWNXe1o7TqDTCnwCVci6XZNAKTj+/E vw4pDrs1Tx3zfyMHyqxt2Z0PtE0i5VmOLdJIdhux3tZ+6gp7PP0p1Vx6/5UATL98AYBbuZCDoIbI F8vFq+R8KMIPqHhB12Nlt/DCBX6OEXfJIiJxECz7qOJGOyQqhxU5hnsfxqlqomct7uFHOPJtHsSj 7pUcIiV6bwoev3hMmJdLCsC1t5HPmAYeJLFWk+iTYF2DQ2u+Al27HTCopCDduFm6KkZSN+JQK/Ll EIgaLJlz8iaShlDjGQTRNNE+EEcyMQ41IGFVIbWZEUbUmGyUucTYLSVXGQ0SeBzcl5+UBwK/y2ci sDIEqHjx5QwXztCnlq8dYJNQxUqbRyfOTzaKtyV+ivsIJM+C39mxw8kXJqqrVRwZbKkXZQOj4XuF cF6IOXONVJkg/ua5qAI3tttg6wQuUMHJMtO9jSyfrBRgDlhTbD2zn+VeJSdjtzuTG/tMDaisdv+W FrQHky/l/EDoTz+g/lXG74QHBGXCk4fflHq0MNhXmnm4keqjN3ANTImEmMAXwghIVMIcr6vJ83vN 6ZWNYICjtL7H0zRDdj/WhRV+c2EEMTNkgRVk6E3UziqPJzT0Lstez4snRNSD0z/taDCSDE9F5qJo trlezUOcrN3lg++nvSllo5XME0YOwnECKxoGjgLEDySWmwimnZVaZJq62+FI1yxFX3agjYkSHVuE Ku3lemedKJWEHVZC1VG7jnprRBflNk/iCHsWR+TYxLQIJLIwNwVip5G3GPsXsklrocy6ULAMEg6D 3XvVVmGucPiQdW+xXrmMejTcRF8VWnCnANJ5xQLiSdz6gjU8T+vVDv0mw4Sp8mQbJtwqdLYh2et2 8RPOZFM+O3bmwaF9KHfIXCd6Pwrm1MhZmpueRpl+CxigBNtQOfZaFLPmk1rCYqxSTgXQT+Coqsa1 FHnZHZx6S5zpjOWOeIKuQ9Gspz1rA5kwt+KU3SQseRxkU8FlATnhQQUAqDFH9uH/QT8nXRxUkIKG uNTMUf1LwlNVyv9O1GnDLEy5hBLZMmm/ITSpQ3yzNfAcceBqJt0Y36n7fPFUNuQaC40QURJDH13F CcZTBRONpceQSxQDm6AqRYezPrRPJt2AucqyoxwmLRoq+6HQ00TUHjfJ7af7zDVwBEBVkDowPjl8 6G6aFvew2dohsyACL5VdOKv0Xopl2g4iqsHdrW4Vltx4TiPyN/bolYMUQ960PDgt6Jg1HdStNqIm qcUbFDytVzhp/6CKk6eSjS8InbGps3FsANRabyYVTAHCEHy9sHXo0zUIT/r2WztadRR6PEcceQdw lytYeLD+Wf8H77DC+sJnvotgQ5t3cJIjp/dqc6Qdy2c4jC2fyWy7nsrYw1E6j1TEcheka3zCuA8c EDcHIMEjYZUeO3zof/eevQVkQM9/d7UPOzuU77R8WpTctQObdmSst781X1i2e6bkRmKLE2pfIv7t KivzYR2m7BPmlvZrrcb6tLZecPpYb0vubNrzEVsUXrNhsr+TSxWOo1mSdvBqX8pBF5T9rOUK7R5I 4ie2DWxn57VeHQh5hIHOmzvkqF1ReP474mGM26Gj/DCEdzP2ISLfXG9/3mkXJYpIdMeBxdbRYeVH e2T/QBjfbPjoiyw9gjdk5PhcE58idFCkxqofIgKwcXkDsa2zaYrbE6R15dAEh810g6xwOWf2UBCT tg2jAhAMzQWyuEPugXIQRBwAg1kxOkH01Pe1TMsH9Maq6gGV6xDuxqJI6vN1t6dNTvx0xg0+MDnT ho53freA7IfdscoecyqALVRlfQTrnf93734hLH6Iiv3tUJ6zUr3nFXJyuGdx93rlk/aOb4HthNxs 8s8ecETZmFws90HlV/Ltm0na3XU9EEM0zPy5a/55vfZJV8dQteJ1q3uv37Jvk/a3IZSO7A1bu1jB BEr1MoXJ5QibVrgR7pkHbMasaQOZNxf7AIb6pzHRpgpsWxKJSvfNqq6pB9OikH1KyXC04rlwPCrP d3/geh7n7FAgkx6OZwoby5oSLj3Z59aUEAknK9e0fWNJRS8waky2M76TXeIJr0UwdHmAWTbYXq2s SFc9QaeUnp7VAbM2Niij7VV6X+HFmyjWLdaTqKAgqu7UlyQg6986nobNPxc+731KrjNFa8lMWkG6 9LysCtXl3vK9Ilxs9TztpIIuUYI1TZJsk+hc2kE3jGjbiJ1Vf2hCJh0gT4TH2zQ6pt41yRjw+y1Q WsDyw9s1DimswbEbmTyQR+OpSEO0drRIA9qq62SuNawwNXPo6hMCFtYmOHEZ+URTHaMD3w23ncYZ 5SVgs36SGmdQwW7pdtu51rxVA8gS1Wt7OcOaT7Sxjao96Ph+BhlerAU37QF5tvtXtmvpog4BLQCJ chtZKwtpBqQdfY/FIJVpY6aD6yYa/2bT5LpZl/p69YvGDyS7bvwqEp0Vpil9KzjiYlE/pBTaePJF Ht9qIMNjFzprRgoLijx6wweqNWshCfcah2MCth1TSZNTrYIuHxWNNM09t0tVMyAX59ZamUpsld2Q kWZgcXKMQvmMWtMmxdqGXq930kpRuZzGKqsqijsSa+3tAPVscjE5JT/hQEbpN529ESB+bz9OK1Gd SJiO9dhdGvVxOSMuddK7oRL0W0s9CaVFBEBvcBE5E8lpQDe2vnsWTzC3LXqZpbvRrynjQfdp/C4y T13N6AOSZezdeNrfq8LH1E79GStxprccPlECtJbOoBcVAtnUW/rY3bJlaD82koF9jzRlpz1FKJJJ z4aAjSCdSUsa94nN35OIP+AFZ+0KI96Y1MDJceA1UqpPbDtLlqyXPWnW+EXsx1l0+1TDz8hWycoZ 0zXLDA2Stz4P9qjFYymGWY+Gjgnc+LYu+GJZc4ujtyaHhtcyVGI201fExjyxR6RWFB11IaItIYzn B/CmaGVPA9Rf8UL6GQqY60i1twWudEfNNr2JB0J6RTy1MtYllQbbUNMxwGh/GHCSsfQoloHTQ9cj Gh5YKpX7RqEAct0WSeTsq920b6LgUkfvWijN2J/lzQsPXqbWF2/Q2zzMU91mfELNc91m0kSw5hgN lJ6mR0+aKAYkRclw2bB5hq5jw1ddqUhofUTVS7e+Iv2CT5VwdEhHNTCW2gPuelhsPnk4xfO+gkcO cNba8d16gMoiolFOxGvmv5L8pndXCTnnJP2/yDIOQ+q6mcfE6Kxvo0LUjY1y+Kqv1enNWZeXrfot X9sz8OcOd9DBSejQt/pZNDjW/LlYL7/2hzqYHgVxs/6M/mUlRDTsSFfv29Ehkc4d9Vss3oKxU7Hj 1vNEsKtD/e6+tRu697+sFzbpzrAdMdXoRS5P5tfDoMGCd0VMC9LUJY9tmnwnhmqwMe37kxeOkKzX Cx66MaiYeGK5dGGkH1Nt9aW83PsTqLdK0xFi5wNZuNCfDQKe80pxeR9gPcEoNXZbh39rQZy3ZECg 2aKt1EKE7H2FduIrmoA/Oiv7mAAl23jdofr0jA+Kdc5bc7utfT/fa/cF2PapLHW2Xln4nhji6i+/ VUb0jB+YtYloY6kxApeVuNYMHADkdleLF5TL1KI4GJKOHuJA9aRpXNFeU37yHqJVuU+b3eoNYiCj SUOJesEBve3sXGbtwrXMRraw3dkIdtMeq5YFaVWMr1uJoGi8q6y/MTzkdC9AaWjkdaXb2HIiTMUX vvgDKmIkj+OojpE34Uu4EzD5RA2OCRtOw4gcVIupTzJQ26NsTWhheE+4PCh6Gov95iXiDiVvjy5J Tl2Ah+78RC2/1YKBjnvBtwoaceeDNwHMWH2qkDm4a1dMZc4qPmLmx8aT2sOvG9F12FEOBL1ygfo/ S0BBO0LwaadXJ6urb6a5RNmBT2+tC8cb1WTR+5cnPk1e3lnUB5zayB7Cm1hb/VQGGlRAIJNpCuH/ IuUgCNFfIhzeOla150/guLEEfr/84/Lb5z/9S17pX//78tvPP4/L/e+X33/8L4T+u64KZW5kc3Ry ZWFtCmVuZG9iagoKOCAwIG9iago1NTgxCmVuZG9iagoKOSAwIG9iago8PC9UeXBlL1hPYmplY3QK L1N1YnR5cGUvRm9ybQovQkJveFsgLTkwIDMzMiA1NTggMzMyLjEgXQovR3JvdXA8PC9TL1RyYW5z cGFyZW5jeS9DUy9EZXZpY2VSR0IvSyB0cnVlPj4KL0xlbmd0aCAyNQovRmlsdGVyL0ZsYXRlRGVj b2RlCj4+CnN0cmVhbQp4nCtUMFAwBOKidC6nEC7XEK5ALgApxgQECmVuZHN0cmVhbQplbmRvYmoK CjEwIDAgb2JqCjw8L0NBIDAuNQogICAvY2EgMC41Cj4+CmVuZG9iagoKMTIgMCBvYmoKPDwvTGVu Z3RoIDEzIDAgUi9GaWx0ZXIvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJytPMluLLmR9/cVdTYgdZJM kpmAIEBVJQ0wt4YfMIeBbzNtwAcbbh/m94eMnUstKTca/aqUxSQZwdgXLq/u9H8//nlaTi9L+bqm /JpOKaXy/ff//fFffzr9/Yc71f9+/+uPuLzuJ5dft1PYXBkQ9/Dqy7DTb3+CGep/Zdj554/oTmlx Zaaf/3P65cuf3HL6+dt/v7n9/cW/LR/v4W05139S+cdFl+pjdyn/LuVn//7itv3Nu3e3vPngvt5f 0huOMa9+1NEJR+97mQUmg9/cuc7ldi+/er98wvvn+nfSNcKymZnr/uxry1p+zLxt3Oyifyzb+19+ /uePz58/fh3hj3vFZwt/WU4x4D7f/YJweNyRXxhq3K3zsisPj5znt9YKiX1vucJMzszk3Ua/0RO3 wHtlxq2A3f3oc/lBsA1L+tWsFstr4R68eXuNPbzpnc/sag8QZm9P9IVOxRyWPZgr/EIDyiHAW5sb RyJx4GFvFSU6r0UmHp/sxhHdyajJxJvdAj+6g4+U59QPS0cmYtxRiLh+CD34DT1MwJQ3V8ALn++c ZMuoJKP9jj/SK7EQBZ7LtnzBHP7jHngxvq49gL7hz/LPlwBZ0QbEHohEg9srMQdkgfQmnFG/w44W grpQZCBKD4twOgmNG6xJqCKRkIB2yyxE7oXz3eoZcOUs2UxYK9Zl03fQsIYiEzuqv8QFRFfd+Ft0 7y/5Lfp3X7ZSxVLoZ3/xgbjWK3TAeCASG3aBJ8HL8IUZtX56fX6MiDxQt2f01PfXIg9UwOCMcJDn e9gI/jX0RFEJi4iyyqy6ERav155e6i7crgMsdMSiIMiiged8Ay6WG82EUYWAUzkPhCvqxCuR+TMe QRmQ7sHtl6IUOyo440GCPDW6SQlTaPdlw4W3nc69qiUQS74RWgVOUk5lZAe1nWPB5XYimDzhlYXg uuJc9KLRod22eAO5ASjew8myF+OgxQnr0wVkUSKeTqL1lPkR7Bhi+X3zMm7d3kV4VyWGT/lXq1zx 65cQOCHKPADxEpJOXk4MV21nBcVYdn4P2HXPr724x21eC9nH9jyI3SJpk7ix0ilbTETl8NAIsuZd oMbyfpKhqOvtjAUYwONaGE5NrV2I+YH2Wrc0Wi9lEaKkaj945uvyxQND1j3UHRCXsXj9MMJ8oSHe 9xKJVa4X3gYGtQOrmVBhRs1FJAyreNQx8uQGYGWnhSbXfWHIYmXbelbXd5frKg7+2eq/t+bwaYKd ql9+/k3Gv7qQfayfZTFXP9OSN4PevLJx7FRgvLsqwS8VjVVXAAHWics/a9VewJSe1Gg5WtCwVY14 +iOQpuW/o5AdGhcywaoD98KQuJJM++ITjyx7EdWss7lFN1Bn0YkLDLD1KwyI8NeKtGDx+RA/KXTY MRvBjbtc/np6zrQXNS2zCklX+bKhTH16qm19NRsMwu4OsLGECu9O2CpYWdeC31w/9zeQ6hl1fkEJ 4fXCn2VQfZMHX3HCzwW001oNvUxDroR5GMcPv45AUZEcHVvsCsW5rAazr2JN0dFX78EVYyY6XDN6 3eNW/r+Uc0E7K3ovI9yK0DpXGNYt5BAARRZE7TAeYW/mjezivQmS4jHgws6GmQUuooAPBq6CYDCe YHFHhwQsxEsDYN2gL3xXzxoHwUP67YIs0c9avQ1+WjBC2OFjdrrE2SWXZdKLRYfbjiHDb2ysB/VG yoIgXB1uAQ/iiz6LiVr3d4Btt1CoyaykirAaunWyj8LCpDRQHaEFnMhQW0npwudaNEXdW2PHs0dR 2Sqj9lvj3hjL9YWVLIb6m69k9sKuBmmo6uGgEXMIiy6NVp4GFsSwQAUmJlv7Y+tQFp4g4xS+XHuz vDdq2cOCV7151ZNOj4VLGwfWhAsq8sm9D8cAX+Jg1q9FTXo2Btl6kQ0TIjoPfhP3GTR4Y0/s1ra1 5ubeEYAx3nzV+9bBv7aGMK3iDQHQ91jRJnbviPfO9X2EoLCHwfxjq+86mF8dSQPdruTchNGwF+8w YLzKOGr1ydnOt4Eeti9kXqG17o09yeYX/kWWXP0edU8ePdavzj6/HsPS5gePoNIABfoKx4MUiLuq Nib25qG6VY1BTCPXXXjf+AMU5WjjatduuBzU0ljsyeAqWv/tIPh5GQKiQKESreqjoyY+ReGp6gsr yzX+O/qwiccFc2DMnjILSYWElh4+Ap9C/oqWYLfJeHSPLXWhYQ//iv1/CD9xH1yOxdCs3wy0uBgd ZPF11oYLJsRcn15YZFQgivwMpDi6ADB/J4gkForIiECoHqJHEFc6aHWFNd+IkxrKs/55IGZHLw8i GuSc1ieNdxTIhe7gEqYV5AWZgUVQ49jj8hRmQpGUzXQsXyZ+OzrLiD4mOQwbtVE2EMMSmTuEv9Az EQYFLAVY+JU8HUHtPKsKR+Rcn7DDrIzfabFPmceZeZJ1PDexZZw3YwwBOYrROU/SbQ0Vd0DBy4P4 5SEs+XW0w6xUs2tdSfFwTJGYqEOfHWISORRtcnnUbY0musmri4ZEml2Qon9v5fj2h9GR80PkNobq ZCo3caJhlq8QAzTtjUIxRixKd8L6pkFYsU+7mJUugLJubTWbNY+HSQ+BvrjBngNDNs/ixQsqBtEB geIwojGqPCHTLuQ2g2VCuxjSR+dHT5LC+2SzzV9XqZXNKpsw63hSBqdoJxzT1H7bB0P/sW0uapzB Cm2CJkBklhJXlP9ZLRYSCleTonnClK/qLMSkS7SjP+S4WKcdQkTephYbB189WU9erCeV/E2Qu1HB bFdGSQAllIGQtVVAibXVdqHTxkxkMUVo8VVcy/bh80d2lD5SGs19C4lwBmbSLkbuLyItHqZELemz twKfRliYRKfjbPjS6mU00gxLDIFWL2LVbFLgcSHZrR/zmX2MYxyZNxe6vamUQYPiSwwaH5t9coo+ c+rGUS4BnkTjOALHlcf6M61uEx1BjW87e1IGnKXh/z3149fA3oCGZC4mRrRTkAjyMnX5FeNrzl2d g0TitsuIGvtbAlc1yHufJCOKEduNx7hd0b0UfoMJ+klrrNJzlBix721083IM4uD7eBztYueoUwEt YBwgo0MfOMr2QujY9zZy531A4wp/yujP62vl/OW9iPqgUF106/JJkPnu3S+OWFIglDD02e3MxHHr vGWSQ7jwyxh6DRx69bg1CY1WH0bCpCHiXgMEt1BqQDotZnlOEUiGEGeVqKsTlNm5bIAypMXORaTV jKZKlqMKZdnGqOynNfGU2C7moAEAirJWyQBfq01UZV5G+6McNT0O7XQVGWhi0EhGTzRHfSEMw5Gv Gv4sS+y6xAV4BlY45vW5PY8R2ETB342hM5FjR5F9+KypBU8Od5HHAX8JxAtlHiZmitM3hywzBbCa akqJ4vChfKkWiMKEaHCUaqhvcAT6ELBbZPspmEiHl0i2RvdhXdgG7KiS6kvGk0Ka7PeWvPxoxFPA 4Ln50aLT0pFQjyGkq011kAV5FOS8vg4ZobP/MOISziKaU7UZAWI4eH4uf1360f4MpnOBNxPDO2J4 nKtmZprZZ9JEDjbeYAJQAnWZY6EblzwbRErdrdLaJiIIqTcQwkkD5YRA5NygCEVEzl5/LJK6HB0c vDxPmnGq6yz+YKak2K6vvZryNfX4iGcM6XFyjk6DZGjzd8PQa5DnzM7vLNunHN1MjPR6JY13JCda wQ37YIUc4NRA4rcWVE1w4klfYr0VW6QeAneo+avFvuscLGyah/6CMktTVfQ+Uc7BA/YbG6S3SPUK WU4iwwhYNhmdi9H6xQAxiUq2OWJe9NWKwvItyRNNiC6rv9aFwnwh0XkiQ8DtOwatS7MUr2ZByUhu rDxcTijLbMkKyBqlQTi9ay0Rv2R5XgsXPCV24W9NaK6Nkmbk2UmR5IoyZtq7QBzKJxmBSULZ9yHU LD1iNBmLjhGKFk8ZWaiVvZ+SxQoyGov51UKweThQg20z+SC32umIsVax2Rvhecwa2cNojETLUaHh Uaj6e8lUm5BrsPRTqzEWOcdsUJHplDIEQkGzWGTtavNdxOqpsi17XQXk3kXs9GMO1uZGS5Mk14eo +NB6E1pqgB5lRi+Qcf8F7k/xIhfVosbV4MdpFzXNvJ6Mck77rA7EZf9oUtCPR1CQl8EmYU76MKzn GxcDcVQOALeb0JSAA5PSgBfaVXpkdZMpl26ZG6JKQr8mDkdmOxp0iNtgfrI9qJwIRv7Ts+ZU9KTO y1VfIR+r+mLbQou+Lj6RR0Wffjmyq9mcRX4lLpJC3rlIERmcbdKvxdULsvRQveWRCBP/omWopuDM FJjB95C9zCiFYi60RWbsPO7t68dEeIhsdSrsSxVMaLcUWV192cVTdVrVPuDJVULg2jUqsAPVsycZ CUU/4Fkg4qRG7kK/9+OAhbBEPeh6TfXci89mgc+yy01OhY4Lj+WY8e1XNmgUCzsdIJymHpL7oE8M fEmOsW4dz/xKpYfJANRsjk40EUVAIWEsWPh8D0ptCcP8RE5YzZRqq4FxdIkCjhisvhB7mDcWSfzX ZJCK4xMon7FK5atUhdtsFqYLN8r49ikOv2oWq8mNzcusu8qONrFVPeoLHQF/7bLU/nBxAeJl1nB0 p+WEg8c2UUDZ7y5rIfUZV07ccGBWchWMmVm1MsiCMB3YdG/Qr7zopOLkKEImHUk27bnMq/IntQM2 iVG3FKmHZe1ay6KE4Clcv+4306nRDHkinerOgqyjaBgbkUyuwhbSNFscK84DkjIVmft9rDob02+x fUFSiiMBSucSbAgK/6leBV4MkOMvRBy/gYFJr9L0VLjY49mTAPtY86LP4BLCyIeihwTDpNEICh+k hq5JqvfiqBbMUA3VLnk3H6gacmg1uZ2I2inBtq+7NBLUIynTJpm+OdgDuWkCddJFNMpdd7aIxnIk bXrKHU99koXNeR3MgGUDGlRtEIqcbUkJXG4kZVSbmWidVqmyRHNZJ+RGJcxcqyxuq4/8dwTdpP3o Zu3bYnKGwdRQNdlAizzLql/UgHGjXWfsUR27Rp+BR1uH1FBe1ZRi06OuHsSkkM4EB/YJmXipBg0O vFd2A3FljhR7NnI8+z5JJ7rVIgJQTHuCLlJgYnuheXtySJEMco8tSGAsPE09aOBIsQT5FonFPhAz 1HdlLyto+Sjwc1d0q4aMNEZBjJ3XvY+HSSvRdwCCqivbwKfEW748ZC4m+I1mGvG/GQ7wpr6xNVJg F6P4eIAD7fdpGiNRUnWSW7XHYIoEqhMOvrGjiB8tnzeqeKwoC207MFfEhVvVEpt2zwZTnGVJ2bW1 iGNKfMTK2I9TXVdCtbWur5TU8PjZLnybh+w7fSOZI9hhvudFc9ER5r3pEfa6aDCJ7iNFu3JUbDxW Vy42Z8GFRqaCxAy+VUHCVRSt+hMuQBvBVmlUT06Ki7oiDaMlpeZC9EVXdHEfI9rK09oD4m3kxtmw lyDcIn2oUjLNwRBiPUAFwxoPZadxBs2a1hnCAVoxpHb6ffTMWm6agl0buWnY+jaRAoOtVAG8htYc 6jQ+8tNK/FQHCzHWgkgSGzAJFTDbZ+qMrER+K9fGugUmug/9pClHKpldI71bt53aaZI1XKh23lQg Coaupux9el789oB6P3SffFWuGB5h+Z9LzS58wLLq1Z0f1PKNmJl07bT1dlKtNoj7W0zttaDyJZJw rZ/aIBCp1Cqyf1C+6ZMlg+U0aXUQC7v+FKkru74ynMZdoGedOKwXjS60Ts5ADVdTz7ope3+1kiOQ W1vtrLC/bxJUeEIzhRqf250s8U3XYIR+0mFzR0e1vkomgPJ2rK7fiBbd+iOi6ksPkbAy9XLBFjSu ch/mSVsN8uB5wJ/TOZ8wT2YNKWF5J7snP7bgSc7DpSXfseD9d99v7kuZGav4Aw/QlgnRWM73EcgR PZNGlqe2aZl9w2wPVkfcMclZIOy28ag1zKPMM4XY/DyBd2vnv63Nb4V476Nq6Fn5jvHf6VPf4ELi ivK7ewTLWrvKg+pcfy42m4ddEdq+6g86gO9yANStj/hy0oEi7asTB6MJygfxLm9dItEMnZuzTR/k rZpjOytdA2PD/dHQ0tMSadJZwsHEKIYqqZMXRxofuopMNElvh0mN2gZbnjuZnrY+TUfSIjfE8HFw OF/aodxRgXMfH5N2kymLrm43tHYrsNk+6kxY4+RZJQOME3R27R4Z/EzLX3itit3WPWzfRcKsp+Sx EJio6b2xKNmU05ekUWIzYw9qn8Zv3DXO0ljBrUlkuj+vjwhi1lYynVJlNp0Ep0zunsMLeeixN8b5 h7WxLlrRIcHCKhx1HsuYGxs9erGV4Vi85ioustPH6Ji1k9w4MXW+bZLOddf3NWzd5dZAzHTdskIw NsZDyZ1iRkF8X0wK392/dSPgcB/kSVvIRIqjQOasWuRLDc1RLM1Ndza55+BKEa9vNg6sOlFih0Ri 8zoYDPrbydP7sGlnx0DdcyFd3QFX1XGQLlREwNXIJsBENM5Vp4wLcRs/q6N744IRoWh21a9GCPTi tBOl9wEPg+9xzGoFTfgoNUX7O2TJm3aLWa9n6xxoC1IW/ud+eC8yJhnZ8EAuMJtdGyN0NH8pYGGS iA1vJiMMDft9Cbk8JExtvpi3fc46w/r0TyakZOxdzVRbkSmXkDmX8GyINhNY+fsZsgFQ02zRRT4s WbWeofBK0ysPZ0aJlJieDzxHPqx82HWzPXByxVvu4kEPMaAdGDYMMgTAVN3G1YQcbVCqa3s2bXkS CUdD2YgqMV2ld9Dca9pc7PNhdsIRsFXfMdaZo9SHCybcFKBiiUmO2Q/91+dEg2nc6KuJ2u5rNgKx C3Jy28DooYGlrSVurbblkNRKTZd1dPDvIofbJYcanO5SgvswanuGvZ6SOpBxc2stz7LG6JD7N74X t/0Gho0LrCrhNJ7ZEVEgL67fZ5oHKsq0dwyuWe8Mbaal9LmAj2T788GUklnqrmFr+1gneXu5CvWp tIrp/bjvlrVppjtuGWzR5JDokg2bVfIdW7lk5gZeqc016vAsNrEj4MvgZ+jqPhK0HeS7VksSp+K7 GVm58fgiga5VgBPFpN6INJCL1Rt9Y1fYi5hbdqabkPkqCe2cv48lbSN5yqRVWzQ+JFSJ9Yu7NsZt jTJmCyoSCaDLI4ZxpFuwN7dBM9J9sJYpUM+eoARm6rllypXl1tVoxPSNWHlzBX1XbpVJByRTPNcR /s1LDeSuuLtI0F6Q6a1LjZfUmUpWbuEVRsw0vr2uqb5cL7pxiQr5FDVDIejt/QbIjO9Z9bVc3wp3 toabqj7ENIXTS3nMHZm7/YEyV5tS2juRW6OsKTVB3dQ57Obq27Hc8FEoSttCtLqqaE+4r9xjhuNg HVQYC7mHVYfmCbKzGjGn0VsKYCH18w3J3R38NjL+pRRVzT+6Rpkv9zOXBEIZuq3ZQzY2lxM+r1rM /v4o30X7Ob4nlG6nKKzWlVsnZ1eI1Vw4J8P3SgFe6cNRI4f7Tk6L7cCHcfRiExcsRKeqGTm9srjp t2neqAGlCfKgZwmTXQ+SfYOJXDhh92PVHN8Yvu7mmqZIVxs194JspoqPI4Ht/T4mE7X1kz8b2G+W eK4kT1tGvmv0cKbALvnC18forSzy95HyPE5U7LOaNAl+rrLYzYyg04kmdq1g6NfTP0+/fP7Hn108 /fVfp19+/u7W0/Ufp19//D/JKwrqCmVuZHN0cmVhbQplbmRvYmoKCjEzIDAgb2JqCjU3MzkKZW5k b2JqCgoxNCAwIG9iago8PC9UeXBlL1hPYmplY3QKL1N1YnR5cGUvRm9ybQovQkJveFsgLTkwIDMz MiA1NTggMzMyLjEgXQovR3JvdXA8PC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0IvSyB0cnVl Pj4KL0xlbmd0aCAyNQovRmlsdGVyL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp4nCtUMFAwBOKidC6n EC7XEK5ALgApxgQECmVuZHN0cmVhbQplbmRvYmoKCjE1IDAgb2JqCjw8L0NBIDAuNQogICAvY2Eg MC41Cj4+CmVuZG9iagoKMTcgMCBvYmoKPDwvTGVuZ3RoIDE4IDAgUi9GaWx0ZXIvRmxhdGVEZWNv ZGU+PgpzdHJlYW0KeJylXUmPLLlxvr9fUWcB1UMGyVyARgFdvQjwbawH+CDoZFsCDEmGxgf9fXOJ jUtmFVsQMK86k8kkg7F+EZEyL/byzx//uJjL1cSffllflsuyLPH3b//94z9+d/n7D3tJ//vtLz+C edkvdn3ZLm6zcUDY3QvEYZc//y7PkP4Xh91//gj2shgbZ/r5X5dfvuBizeXnn//4aoPd7HJbX+N/ rvBqlpt7NZt9T3+US3bnG9akGz7+BfHa/mo+zNvt6hb6G7b0tI/PB2tuV2te7efNmXjpdt3TtJvZ 4vN7Hu/ieMBpzWd+xy7ryBcg3OIc6Te+Mz1j87W3vM78Dy4Tyh8ftz/9/Lcfnz9//NoTIOyJoA0B 7redXpeXf0//kXnLzx1/Xpe0JcgLuHq74Kp4WWUfeYr8M85+9caUYdtOq8wjeNtbvhqnWXgcPl12 FvAa3cMzUgeWl6cPDcec0WLdXkJDi3IaeQLcj1d7wbcodlCvyhsCeu3VpuXG423pYSDyQuKLMWsB 856BSJ50o/AAvyoeQJxuiQ+4anMv1q0Q0r9+Nzb9u5h1U9td1maz/uMW5/I2HL0Kjx3yTqrTTYsA s/fsUTPNR5w5xDeotUfmSRNBf4b23p0f0U+LRKElFMnL/DJFhRBefKcB1BJdWuF1LcyW+HUr7F7Y wW5Jjquz2M5WekWOTvP5kyNPc20yNG9RHUh8xAKJfBTw677T2Kho1NJRoKLATBHFu6hEa6LAxy3K wGf6z1eU4ODyC32Ib7w/ryz8Ujblvei6r8wGSY0G4EmPeUmPKs/SKcVTKfTLK0HqFhYKtWROEcPB i2uJAUrGSUoBfxXBx5WU8+Ihog6gnJg1WQW2IuHKQxa1fB5VtCypGQs8bT2bCVoVfZaRZcaF2Cb+ s/AD2n5kSYaVz3CSb8BEu9to0KCOh3WzJeWZdhypUhYTxQvu9OL8J11W7FA47EsUaBq6q6FvRfGS +K0VAxVmc9FuFJF+ent2XaJ1UDu0tENX6PeeDHxc1Ltx8UUOcFULrsplR6AowSAWyswR2OzRmalf bz8s5P29l3nzOmxw5dU+aayo1q2tL5r3zJj5SbtWa4pLLTbF5t0kG/tqfTFB6Xfemt9l/iW7KVFB pMfCDWijZVn+5vBB/mkXtZDyHp8fdrKIOTXu9/VlbQlj80u3ND/+LnuBxBP5gn2L/y60vChOzpZ9 5X/zJhYhirOL3PxKS9ZX7Fr2lwjp5LQLU/Df+VXOyTx4ZiEPwTmYclMk2BZy5ay2ZLycwnCAOsry lbiSsGTZvAaX2eXKpxBlK+AewzNHLYwTf4cgTxZ+I0KbD6FKYVubx4OMz57vt+iwevLphQ4GRYBO nyRGMXe+kb1OuvAW/11pzW9l5Yn5E5WYInlmj8RScwmV4+Fq8ZHf0czq/fITrEjKeHp6myPD4kaK greI/J+1QBGOhd5Ljo0TkmVNXRj4DdljHfISi7DNBLEm+izLidPtg+2c7uCSTD7tU6zoU6yeI4Hy TzDiWjWmOpFdP+e+8Pn0d0i+SSSAeOUxSmvdtJMtub3znqI/sJUl4ER5SnSAPpClAFnqmfjLZMeT fwavng+y4/KC0JnPT/Ic9INt7HiyRdg6r7m3u5XzgRFviv4wPPb21AlOZMlDcOiUm4nujYcplsik +jzbt106B+chua/IZyGf6iorvga+8XhzGNqnM1t2fmzmqOUx7WYWRkpkWIHve+03PcPyJnQ+8jHL X4HxEeQWQ0jFFR1ZKCIpfyFMAKHemUJeGuZVIEzLmRyQoVPqM1fK8PHuC0se08Dt7qWNqOeglHzI IpkBzyvZZB1GCNs+wAwCUidkYAk8Bq4+Odd6dnCIcCS/P94+l323AfmgJxEz1AhF5G+FyGjJI+ji iguKeigYBYplhQauPB4XZ8BX9xjkUhM8qUGRcAxLLYYnUEeyY0R+phfcajocUWE90dHFCCfLLB6e sZokmw4Uy0h+oghqjiTUPFmUbJArSrfZ6uf62kBJzQs0mFMBFkXn1FgGCRJDkSdkCXuPLnZqYYyZ ZfVv8EjNs2q8eUbUrUYjZYveAg/WMsYCP15hS8wTCvi1c28UaGEYzqm4jWGbMvKLuNdAEVFXboBX 7Nwckgp5aTLhxx4sbFbtWmaedMmUMn3O+vLxOdH4LCfKZLhj9Sym4NjynGwZfO/RZEgRENOGp3wQ ZaaB9mKVQmFXuUK60fG4AgA/AqDnFqhTXdCjXb4JPi6AVKVaVeUJnFDBQue6aiTOwD3LVHbwFxDN M7CwDVOuPU/qGU68Ba3iBlcOIcA4/6JUHJPwZPvGdm7MbAYAWruG0FT8x5eoN9vfTQPKBZTKqSB1 fcLfRVR5fyhvvSY7pgZse+/sFk+tIIRn+sYib1pb2WiLDr26HFmq8h0YFmSM0lJezdrmiuJs6+SF tZtdSxyR1fZSeEKKdet8HuV562RTtPZr8SOWOgdWOHADvgeU5QglGiUEPxKE/flq5YF9+IX53qtz tVuLczvt2K+sU1Q+AXr98IgWy9L5uRpC1nS91+5tFZ1M2CMIofMjXAbuMOYhUnncql/Ia8IETeBE WYEzSgzkkeg+8HGYgCyOK1W7kdxrzT3pJDivsZxppOeTEs3+vevdS+3QdKd46Bjog5Goy5NDndIy VaIH76Mp807s8uM4xKNJzk+TVeRXuYqHTzbvumhjLkEdUI8E8iK/kc9l3ukzOQFVWrC1I83zBlSF YZScQSf7ZPtgOg9Sidvjg0Yz5AMVGcTQ2tzgSSqw5tEsomEHTa17zdhtCsyjvc9clhjMp2UHm36d coDZeq/kMEivDqcCkGAUpKZ1oenIgxRYhSsvSNuGaBIBV9nE3BuG86DiCcl4wR01jjt3v+y+9sno s3yz41TwuPqAFB3aTVo2qguVSix3dchKT5yWw+zq4cPqBE0IWsQRm57QZgudN+Leb4xaRDH6yj8S EEBIV8Y9CN3w6FhqxEAGGhfninIQsojGS4vcKqpGfJ4s9pt6CQZkJJEnu1h9n0zupJkclc6UtqH3 wBJVgEDxmtQVeM9FSGZNqZuUV7Be4QzapBg66SxWdlXOfg1iVs54UD4c8iqBFydEWaDzKAq7rI13 pdPpGj1JG98xi7ylA9njg+5NBsP9gCML/JkVkbelQAsDELjTYZcD8kmIrXpHYyfhTItHKRo7kBO2 qBxEOocu6AQ1lyohcYgdaGS4CU9mUkrW7X1mjYDRtP4S33xQMtWuqH1WNDlJOBN8MZF1NympaaP/ E+jFWQ0k4fc3myPR5yezCaUb7SJnYxfK6tp1Qa2ZC/j2RVLJlAzL6fTN8faeIsO2C79Aoki8tfIU VX52LuVpYetSv5y/L+ugXK0kaFlvYKa7Tr5LCni7SUJvseutqI90/0vl9i1muLPna95xGzmnrXKf cTlLVXlAidOndwsmoc9qwyhOaQE//+d5itmlx+XeGOOq4iGuNSF3trYqguCVvIMXpOr5ssSTwkH2 2zhdQTZ74ZelJa3ijvdZoSZz8ZA8piuEzBajgEtcenZnBcohk7MEw+3J4opZ7EPMqzMLj1WKLhpg ceiZSyWRWMr80rtA3pUyEKmcNmrJKrM6s+vddd5Xg7d2hZoCeFTObVtRRdEvB0EYx/uwi4tNhb1q opMqOP06BAyi91n7ozOb3+zYx858bTfyhRONbxlxzJQ3uQIieUBi66XMrAn+409Qz+2d/ITkxlmA YgddeoDYKT3wSD4VcD538KsZVfgdJA8af2sRpv7AAjzAgj2jGP9DL9BahVVpHIv4g2EyIzhg0QuB JY0RtlxBSOjTKJ9dY2H4oqmys+00613eqjdVCBbP8YNAccxhVIWHOmipUmHZJNrhQN7fuGCgon9g ZpDrFms72pNCHG3LxzhXbvQsMhhKfnsXnWU0Psthq3pQxXn3zp/DAjKaDFo+4rQRxoGtxu0LsavV NVjGDE1cGGTCdZpjlKh3O2nbrBGqDBfpCoqJsoZAYMOxfYyexfJ6SlIsHXYtEFOvYoiu1H0a5VXv WCM1QxvwHZTJ+hvX7uVossdMO/QYZEvtRmm/qLsmSmjrgn6o6O3MEbmwy8tN7Fghr8WrmozO+KCi fd5Zi8Lhhk02rYPSYjeFT2JoSWGn5yPTkLU2d3dB/OJzizw3LE4gQZrcy7f7ZZSbNMLpdCWKpeol m7A6jOGpFaZce5oSHOtOn9qoGyaH1Yzbb/qd1AJEOwXav23szpXOpi1VK1aETjwfuDLsUF4bUIJD 6BRUKTelR8tKwI4gmWd23zXHsDNUCjWonoWSlgrqoEI31E9caBHFeJi0QAvlZFjNISfehwakqgn2 mzvwPxJ/GR448j5mSTXqoBGRaN0WxOStYPI9E0Bin3ivGqMs9Nj2B7ToiLN3pVXdCIL1Zjc86o5p skf2sBqjFhRATZwcY42+ApXIDcsZnPLAoYUui/5nTxvI4dFXmphjlgCDjpjahdoQToHyb9X2Ro5K 9pexCyOPkjKnBQvh3A5y91GACBVtMUxl6dAvEuaY3figvwV8D0CvkqXVSG125BFIXUizozZcCtJ+ WhnFhyvzKz6XzHJxq/TERHFg2z5OPT1DA2lBOQkGAFcDy2PZxWyCeqL3PPgcAdkKVgU6QBdnIoXy 6KYernhB74O+qGkrobpOvoHmj4rqZhBZXIO0fYitanIZDBJVrwzs0AZ0vbs467Bsk1atEHaG5ikH z9yZjbPUQCuzhfqq1L+oanip5DRYVVOFNLqiegIpRYJJf4gQ7GxNbSqskcyKpUO2/SWZRuiX6KoP umtpkH93X9GALuox0pV5VqcgJ8nFdmPvKsUHXxyauInuMiTOMqx/OigoypRReTHYWCBxYSBuU+cy zQSVzvm4tkXsLmcBXHyT3aasmPPlKwLu2wgyEmvQu9KI3spK+KQdfud6oSZSS39W1gRaE7AqrGWj DCdxXrEDagmbchg5vTfNIqP2lkemS+kFtnyyMBLvj65m67CGUVdCHYjloAW3Np4ifDJZFVRMOwij vphaHqOclpYysOfFelegBga7v57IGGHgpWJWNy0d6ihdJ96VK1ZuYkI5auxgliCDhhlJ7RIwxgrx AU3wCeCxj5AKNVZ7l9JyDrW5qwvy9ar6EoAiXYRSshw6lkECcGZJNuil6ZyKcVHdNWB/QFhJyPSV nLXSrRlvurxcSh7WvXM6NSoT0CvncXR3WlyGLTNGeyHQex4p3VB+5qw9vCPHeKfBeK+ymcULKfdz N4RgCkKINm2ny//EbQx+xmhtqW7J7av4G2K2cvI6mq7Xb9ivPVVgjoiHJqHGu0zP6KwTZw9s1PtD yls5OlU6IucFQJ8kJSUPigfPFVQWylz5Uwt+5SORq6U8UPbinlMEs5QZdQCxZVZYvNbNbYas+fyN 3ahtaOMoPv/ka2fKcnYDw16dAljWQexZHDMAOA9UFWBEAIxB8xVuKAh8wsg11ZgW/6vutQmoxoWe Jc6ojefgEzmPjK2trO1eULu2cuglGLsv7K/Cy7iVKJ/5imoK7tbknOlrSH3rwbcO1I7WUqfk7oIR wx1RE+tywG4dkjFUNszmFab1yKr+828/Evv/s1r8v//+R/5g137522XHX3+9/OF5onddSGRtRNF0 qY9soZwBSWMd+d0VoJrYb1e5MaDpG1xB5cfaBoQRv5t2NV1t/TN0GLQmpSS5vRenf1yUUJXaT6MK o0agALlo0OgSkMbdQgxn7YoEla/fJqMWjmSeSwoJztWiGeLFP50gmSXLoEFIQ7+fWS8X/byqTGL1 UZ3iWe7NqIHjKF/AWXWwYleyAF24Im/fnvGk7S5rbbT4JGGGvULK0MK9NbKVGpSuJ7/dMlhwUHHM 4F2J5TbmnY6tGkMv38jaRqjp2qGkeIPoWMcrs9QZtA/VYSHWTrhnTo0Q0yqZLRXodLFNrjcUom8P qvT5IC5TXyb84m/kfANXGjUNPbFT3CL4TqGAF/fhm+3egP3e4JrcC02truuGN1XrVw09BHhmaTXo dkq9C+iGIcyiHHyinHxIaz/NIR5gKlItA1Qbs2eAVX0HpQXxVGVY/RhXYqkM3N6SZl6QBo1QR6cv zfLLjFSxBmWcyq4yTyMFV2tWrUGpIUW3gNX180sTnel4SKn2VYN9s0TqG6aaBBAuBlZOvsK9xf43 GfME8XY1uhFUpF5+2RPt052UboafP2jifYYmoy6qRrbXSrSt44KLGmdvr/dFghbVlnVi3NlD1SIn MS11YTgsc8yhnrrYf6GhkuimfoAOTBeLzRJs1HM1MBBiuU/BTMvNGS1/7HzjsPprVDXTVLiFyrxX ArbpW2cQaeVgTJJr1LmVy5EbYakRGcE25FO3XPLjjVw5klJvQJ56SsXJBzLczuk1roWA+WKAUV/W uHA4WSiBS6k0r01gKVgXt0uNEUMgqMz1Jjh1BduOSkvGvYkcZtCXJuy/oIFHXV5taqcpStVACyFW g490jtJHFgxP80BPDCx/06h/6GWQZpY2d2vlvYzEv32PYIMOsLPGQxUGVN+0oej8LMcAbYqUPhzw jAg54Dc0Zk64Zt7IzVJr0Ex2asxKypDrSF0dmSpWqOtKdRmpY3GoZKaqb65fYamYdfAdkxR3wGA1 jNQWafiGNpLmrk4bdf5W9UEK87TPWpeOf8OlYYE1DwMMspt5mb5JoM+j1H3f1B8PvzOjPySnyiMw TMi5lyJCCHUxFudrk0vJFoIdFTF0QpqVUu6zlO+ZfNROwlGy90QtzNJo1BoWGsOr3sUfHnFcuPR1 Kz3f7JMBf19iABdXQlSiBS9TcmpdslA4UR5JriYcBvh6EUj2eY3T94P1UOxZXMk7gs4l1hpo6BPH RwKU76IeJ3o1yYZOOSgO16s5A44mqTTqHzs8dfZmvHutGkPkMy2dSJ4HSrsESs9qMq6Te+S/Mzj+ LyOFgz6zh/jNZx1AayfnSG/qTz+duE74qR79hag5wEQ3xj+I9QRIoNb8SdIN29RUu2Ouj2QnJ1fk KtVRVItyYPJ3AbdcRc6l7er5ppJJvtnZNL47fuHkxy4zk85Wn/adaEfAIEGgLtGacTL6Shx9kkZO ijJy6PGkEeqrd8xc5S/+fzzhpKOTrx+AiI1aDMm9UgJa8Ve6YdqBHnShjUsnUdlsomzac94UXsN5 fK65aJIxGvjhPEZJqrdC89bMLVXBHCRPp6yPqkd6fXu/hXK+Xbr1KdjxQYmt6xMMop00eiSOTS0I eYqV2AGJKonIo2+kOfV/aIBHyp8yIW/6wSuZFL9e/nH55fP3fwBz+cv/XX75+ZvdLx//e/n1x/8D 8EGCLwplbmRzdHJlYW0KZW5kb2JqCgoxOCAwIG9iago1NDY0CmVuZG9iagoKMTkgMCBvYmoKPDwv VHlwZS9YT2JqZWN0Ci9TdWJ0eXBlL0Zvcm0KL0JCb3hbIC05MCAzMzIgNTU4IDMzMi4xIF0KL0dy b3VwPDwvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCL0sgdHJ1ZT4+Ci9MZW5ndGggMjUKL0Zp bHRlci9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeJwrVDBQMATionQupxAu1xCuQC4AKcYEBAplbmRz dHJlYW0KZW5kb2JqCgoyMCAwIG9iago8PC9DQSAwLjUKICAgL2NhIDAuNQo+PgplbmRvYmoKCjIy IDAgb2JqCjw8L0xlbmd0aCAyMyAwIFIvRmlsdGVyL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicrV1J byO5Fb77V+g8gDxcq0jAENBqWQFyG6SBHILcsgA5JJjJIX8/XN7GRSXRCRpj2aUqFvn4lu9tHPWu T/95+/WkTmeVfnXb/r6dtm1Lv//217c//nT655s+5X+//f3Nq/d40vt7ONmg0w0+2neTbjv97ac8 wru2u/H500Wl8+em9pAfvP548/q0KZ3G/vGX0893c9Lq9ONvf/pQ28V+6O1yNh/6e/6p7vlC+VUr uBTKXcroUO+sD11VFI9d62M7DmbqdeMvWpV7dLrJ1IGCzr+ctzykusQP9VlfVwdU3/JQdWxT/lDh co7dzXUinzC/T5jDlp60lz//+P3b54+3X14hio+Z7C1RtDMuT8DmKaeR44f2uHZBgbSOgWTi2+vF pcu38nwexsYPY2imNq/zbLbJV3g1v1cpp7wBMqQpOZoSXTL4sxKmEnwjStZ3fTaPlvvLGpdItYd3 35MKpl33GV941hrWkH4h6u1LxMOrefPLKHU4HesdZufnfH+HuSeafqjv+adVa4vc9pmIoAx4oDVP 8sGkK4O7TBBz1cGYhmPveTsqhVwhUGX6z4tJe6dcoqCz4muFL6+0zl/rutzy6YA1w2RGX5AI799d RwOrLxuIva8jV/lM3G13YO+9TBRE+YJcNkqzLsuwwfBjlXnqoxF0QblVjr/l8dMaQ/qvME3oXm4a KgFNbmtrdzap2I7F84B7OzFSOWkOJtQ55E8tuMOjlNf1W2XoticsJbUucFBRgCjJ6cub2IWsSKza eBKSmxIvLRHAmnfbE6Bnv6SJ61YauXGg9ztdXBT32hSMShaum8K3zH9CQcJqfVUurPKeaJhbfYae nWsvs/PwjV727Wtf0Gl0KTPKxm+e6LAlGqmYLP+SnhJ6yQCz6DjVLfkyff1wo1lCjeb7k54rEpqv N+O0kouyGpZW7eL+PmjnIpsSOuSdCnWBWTvcsnjs/HfRy0k2rCp3box7zqji0txh6lmt1FsrXqHd 1KZw9iZfZTRxkbS/QY4mVQm+Ucwuia5LexQZJIBuN26NUmEbUE19NU7sHOtLA+wxriM066gUKnyK ujs2K9Mq0jDVMiT10GLKaPCO1ziUyBVG7kRhDIwMl8iyuwEBj7tGgpCnMXythVlr1YcAowXsVroW lFu2tdzUb22FxTDat6/abLf1SttsFzZEeeIadJcCVFnBAjE8CnH9Pplvgesf3FQvw6zviGgNvycr g/obXqk8WHdTGx7rFXi9RA+vB6jKnFYnrliWM4E0CIQOR/Np9f2dBvO8TsQkeSD3vX7i3yAcZRZV qmgctAPCGQPEUAaweTuTL1B2c4kUNg6QxtzSaOYz/6hI2aShrwwoAOgZwnNC6AUDg8NBbt1UsIsA gAfTYGCBVRkjVomp0CX/Xrh2KqL6iw6fM2GAt+Z7HRxYeu92Xl8FrgOQnjcW9ofU+obeyE763hgc QbCNoE+QN7/qJ93kQ0+V6hJx9DZgL3YvCsxCtx+cDaFGYLMr8wjHF40waCAGCVno4NIjJIZA5aNf WLU1obEbhEPmLiJ9m5h++5p3mARwgMfPrZqGQEJxXlsrzH5yosGVwhtlYcJ/2GaysXEcYasrtJEH 610lrflLcB9IBQruVjVW00yYpQEg3wrJbLQDaEMn8lpFI08CoxPmaKuLIXNgYCwiFWMZD6Bektoh PQJLT+KSNrysZp/Eu251VJzHYOEyxb+JGbDnXibwuUaXYAYIf+A+SnPZ8u9Zu50N7HOIZUxnjom5 0C+ggaQEsUpCFCZB7p0RYgsTCgZYosuuRoxmxEzBGtRNBmlIf0A8wZPPkjTVKEtn8By3+NGBLvlN UVee/gZ9RT7LGVxIP4FSHarYmkHWCOHjDMOfjYiXaOAKrV60HvKBY0CEgRrSBapI5l7jhu1AAtVJ C63E5Oo+lWHv7HW1lhXnXTXbEq3cPuA9QJ+aBfoQphjLUt3xN4Na85KWFvEh1kFCsbRgzo6KR3rb 11HYRBxokaVsL1nVu03eZbbB92Kj+0tV6e3opGben4DF7MVGvsOjpqAJSwtyZbC3b2Lc/yeUscaN OG8BhtqHJB84ovh55GCJiKxcUFGMJk6tXMAkiZEmQEsSYEJFpBVwMB2r8C1RR5vBK5AzuhH0b6F4 4/e2DG8OvThYl0n8XM1EswkmC6s2BU2uQ3qr9IDKqv/rklJDzZPMP2AtHxs3Bqapqjg3DKtn+4/2 5VYRBQ3pOf3h+U3p7jSLrAVFKEkHMZWqS3Yp1PULHoH8+BWymBAHMC9jOwE1TA4fY26IINVN98Ii Ekg3kbwy7QzF5bSrVYtIjeJLuoszUXsOB96l+rcsBGcr3yEikb1a+QQAt0SfPYwIbB7V2KqLbKab ubF1q/M1lvQmTTDRQgSJwC1+6jez7zX4XSLnsy4xZtsGUN5FjBgQZEbfwIxuiljEFS4ooiPjZmS7 NvB6thZqDEnj1orIF7W8IOIkBPwkZFjdfe/HxO//mqjcIQa0RXBp98a2oN70M9OyA6LKz+KbDeED OfLX/Vfj7LwEYDm/WT5lCG+SKLjKxLTc7CfWFeybiBuysMn4Yhu4K95GIIV+FVZmEToYO+RW7jxD L1FsT50yo4Cx9P1oRueAkfF9yFifg64+XXgeNh83aGmtRo1J/bkYTJB6xxR58ZxXeISCAoX3GwzU JcwIOWP4dCergT48K5J7z5kysoYk/Hq6zagwoqXnYR+D4a/OncA42IuuRBmCEi4UU2O4QeOpMRtW fDWcyMP0En+tV91UHfcBZwugA7ESzeKqRcRLzLOJvXJIT4mQ1nEmDhAZ1oGol4bX4u5ZvKDbiiHj s0Sp4Mfg6ixQieEq+3rKjPBiV0pE9Hdt8qGzus0rK7eyxnMMhTzDoqIkKnM5CXntwO9LNNrdCOVN 66rtnHkgN5JS9ttRVJC0RsMYFEmySoD+swn9kDxY2jHCd9KYIw8Jvz+wFTvSW4voRW9mFlVtuRR9 OHBZ/XQ9naqhIoXtFfmRxRTKib83Yt324lG1Rl8yuEQPr5cKIs4edtdvo372O3/3ilbgjLEHk5M/ X9TuQz5ZTxLKS6Sw8RHGm7lYEJkQRUwTh7TgsV3c4rpHaK9lMdQcRgyVoeuVUWv0MGEA+geqUKCT VhGKOoYe19/kY0/EsK+zONJTfQFJOFLiSzTR25gfL6uqjivGITjQTgihT9y0idJZTXCjDwm/eEWu fI33QliLbqjxW/rrwHgRJOIVzLwLWsX/x0vQak5BLoyCXYsSumDC7yVexyB7WPSv4OsX5lAxGWD2 eOiuYDg/NAhjhWLRDkjxoWPFyRZCdOZ4ephkNR0CQrz5LAGgrbixswiUpqUImSA6h9E0xNFK0bNA qwYC3pj0WKJa0GNJqhli1b7jBRA3B/vvMr8V77KtwxNpmcQsXvPdz42/A52X3/FAl32hRmtXY4b9 ae5fsAslUmxsSpB9W6gg0z1rNl6+4AtQE+zAUrVnGAtiYcHE5pH9LMn9LNnFucMQYmRxHjePCgs6 XkJnKSIrGVtMeE4bKeHmFScz8ZbSodE/7QTW6vbm4A7YN8i8dqk2vXMlShNi4HgaRpc0RtteiCdg QauISFVqVe4QE3gNxkxiaGsRfutn9bAE3vrYGjslCPKT21dKq3WH5eVecdlic5dr6DaCfT+pQZEP J4NeIxCgT6/dlq2Gc90kmvtoEZyAONJynO94JCCgGtIVR408kOyole+hSSIRIpxuCrjgWavMytEW wIlJ8mKn7V7HavrsYA7Ovt7yJAXEWX5+atk7jc1dLnnVVA8pRVFfkbUWlz9r7Bp5znYsRwGnGDn1 SUE4UXHxXMgpNYHKMb7oE04qIUUdBk+sWMErRb+a8rtlas16u44RgDmwrpTcehTtoIRZAVajzDwW maayq+zV6lKHDi+bM1/kzOwt//k2COkc/+0wpNM0H5D99wxhRe0dJqYnIXSqqdFHntZBlKT8q2u1 0STpp7Xqutb8wh//eI1aNs6pZVwVbdYcsasS+mL4D7Zn0n5msAhGwNWahVV9/hWrMErzgKmFKsbV be2hmAw8JEHSqlN1Q/aiGDgEAYHy4FG8U2R5u6pNAReWaTJpS0uLYv001Crwuy0EHHJZejIs+0Wn b13tpyvXc5BLJtEVLr+kf9Pc6PGuXNDuPDKwKwIy2Jac6wcnAW5azC/A8idNadhmMqaBx7CE7O2R 4qxKIKvf9sYG9KVattwvsg+3BhdzubfvNL/Bupdm+Grz3Bf09aRJjuF4U3owz84bbG7mcmDIYFLE hnOtmlhdXKF6QbaiwgsTlU595UMzyCMbI4NKhOFXiTTpkmvKNu6iElHqfBnEanxLkZLmrWsz1U0p jGi64dDFUO2iekeAyj76QBe/Z1Y1tEieaTudLAWfgBmOWBM8ayN+6GGIYPFB87AMF0O9Jj64x67Q WJtp3KVpxZUh6t77A/SxSqRZJ12jFDhdkN7u9ktbFRAZ6zkRotOBNEmuJw6cNpjlxOPADF0Picw7 EGOueFCw2El/3FFN+kdjlhELeOBkF6A+GhpFAnZ9NEGpwDJQjYuL/HjVOg4MbLmCqIrCcKtrHFrl WvQ5tq3LvH1rW2X3RiE7Vn4lOOSqrk0QJOTKt6b9YsQXj3Z4CJ+LYcBzV1/ppgVaTNrktGnAKbc7 QSEYQd9nppHK5LOz31XE7S3kmNZDGS617AZDFYvN+JJ4Em2t88akVw676dt62MzUBDat6qGgVUMe iMAmBdyGWuRZQH/SYtqI3p17//NLTcyv/FqzINBg1h/X9QuaLJT7JqX8swXYkzZBETDeX4m58oa6 IOSfvUqgopMcM8iRElGKVUrMmuEeiC6bmOqW+xFJgARkzVBURa7EuZdfoNM4143WhVVQKhi66YEk o69bdtxqJW3+XKgGhbVyY5smt9ibTW0k+vn1t1KlVn9+VxuxhKmOcLp7qz0itzJrfzHZFBU+Lotx oEQ1XvZdJFh4sHVis/YxFy4tQlTMY/LQgZZtTX4pBogL2XIcTEX2nKRgNWXeTQtz6F5iuMRZDuYQ 7nN4xnbWm01Kd0rHSIVZs1hguF+sQEVJASIDaBc4r6W7xFjTevi6NDZ5sucpTJGWk85WKVzGlK/I 8BU9ekyLSYPYciXdnb73l9Gltw8BJuLVPcoCPCoVorwZGEMcgGKhkSMOMsLT80UbSLo9IcikUWwx 0EgLeKWhGNVpD7oz/KVhIWyQL8JrqusvGCCHcEyAzoOMK4K7Mo7oSHdMgUn716vkxXbIsTe38d6m qoQfuo5klaVXYiRBUJBG6fiJBJ35aM5bkwt5Qo2xy+sZN4j4clM4qcm+kQg00RMRZSiJEZkHFCVN RpbtTcBsuttbOuHn8RT1ZIrjDKOY4MMQ9TEFJ71jtVWlxl6vErTDpQsf9EApRZmexLlzYdGEZ76J 1qA445VKhyjG6jhGCJgZbQGd/MOzoHKVY4pM+sXaLdglj4CXoJ9141JL1jbjl7aaJd+l+G556Bny E742pzXdZVcdbRte2gyNBZEO47tY4DQROZJm0n1WIp2NE8Ulti5OUOQsxC8MpHj2ydC1ZgpcWq0p AdnEE66iXteh79Jc8dUdx1oq5HwRHRybjgbKzBrQbMZu1Smu5AWwi1U/XCFnj7MrbchWVO3Z8gLt 8QWDjkBHlflVFO/Nz0IiX2sjTXa88klrWdN8+qAA9wpQOVa/B48I1I/TsUM1pQPAVR4SB2Y+883E gYILaPCYCpMus3EeBRekVyfhLvvtlXqY1TIx09VIBFhq6jNj2TRpHbJ38igllnycbTopeVbT5Gyc PiLUBtepHL0/+m7RBZs2pPG5d8B92feCUIitx9DN/aDmJvJ2CmcNyyE5aHJC5MxW5RiYA6ZgkBJF RTmrvkH8qyGqWccaJpvQzD1uJgRouu3zgPl528QNVQ9LUwA6jxtMyhkHGxw1se1PSTuJa62uf+hF w6q9qkJA34MtBN0/CQlYjwWwqxOYNIgpra2Q2FfDMXgUlAjhG+QOTiR/vNAXe9xqzgTwLxipSW+X /SzFBW2W/2HdKCf5HrbrzlKLmBQIaTFNS7GDQPTGxatxUnYK3QLyHI4hmfmyzzDt4uJ6DXMdYFGB k5j5xoMkKfaKXboQfit+of3mRNC0ON1t/jxdsZ+jdbYYfYnS6baTVMDZojcXHxYpj0uftGVl/kqT u038C9XFPhnd7vWEZtAODjsg9zEeSSmO9tRI4G7wVqgoC/lwj313/vG6Jq1Uz2JGdZ8yRMtbBYAQ EeIMf/Ux8SpwIlhP5YWivO0J45dKZJE6wCBAU2Y3HKczrn/SImVLh9POIYdO+1DYIn8nTsaBNN4E tDWdZ6MMUMCHjhWis2u3KI4/aHuJBcM4mRrfWKkiO9Y5PYsfPmyPetxdL5rhtouVB5lrONeQ/sKq h8oGkQ5O13Mi9gREf5eWSSknMc7BQQgD9/E8kfuOiTNpmBqmYhpqsGtGqduwXN3nI+eNZWhKWlCu GRfhaJkunpw1ITEpZ9aOSTDpkXotDng570DuvW28YLmS9+iuEELyfbpro5GeHuvc1vdY7LR4UhYH y520P8HpM4WjYv8C7u0fzkib1aAbNVOZTSBZlp+LQLIY/fWuBOo6DS9YhaFr6ainBgNNsUsdBA4j Nc3LHBKTj0pSjK238sYZRpfnpx7jvq6KSzz3PKsw6U36arEu6rTnus9S+G2o1ILMkWlKZlAkJYiu tbZNnDOImMWDvqDYewIDQSZtR86IDr4s0d+zd1qaPeqeCZzD5sJgaY948BGcIDkQZwhJjSIIN+bK VdeWKfarHEfKVf+1o137PGn3vXwg6DmkyaQ3abB92htKZr2YouuCfPQ/9+ib37C4sD2l97NLssmS KT8fYTpZ+y1PynJZ6SEpJj1JTZw3jw5IOMw8k9A1zfbnKJZ1gWrYK+CAu/FUXa7ziOwGkSk9OlSK w3sTRsQYCk8Pw8r7K3pk0qrUhCtYPYnkx2Q9GKbsUIc0vPy/PBnO1lCDq9D2EjjpND5CViJ/IF7W Z1We5SbHc6YmAYDDM7D6JBNf7JNLhFzBlei6jmmmv5x+Pf38+bs/GH/6+79PP//4zbjT7V+nX97+ C4h/iRsKZW5kc3RyZWFtCmVuZG9iagoKMjMgMCBvYmoKNTMxMQplbmRvYmoKCjI0IDAgb2JqCjw8 L1R5cGUvWE9iamVjdAovU3VidHlwZS9Gb3JtCi9CQm94WyAtOTAgMzMyIDU1OCAzMzIuMSBdCi9H cm91cDw8L1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQi9LIHRydWU+PgovTGVuZ3RoIDI1Ci9G aWx0ZXIvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnicK1QwUDAE4qJ0LqcQLtcQrkAuACnGBAQKZW5k c3RyZWFtCmVuZG9iagoKMjUgMCBvYmoKPDwvQ0EgMC41CiAgIC9jYSAwLjUKPj4KZW5kb2JqCgoy NyAwIG9iago8PC9MZW5ndGggMjggMCBSL0ZpbHRlci9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nL1c SY8rOXK+v1+h8wBVzT0zgYKAklQaYG4NP8AHw7dZAB88mJ6D/77JWBjBJVNS9djdwJMqxTUYyxcL 07zb0//8+MfJnN5M/hrS8p5OKaX8/be//Pj3P5z++4c9lf9/+9uPaN63k13e15NfbW4QN//ucrPT X/8AI5T/c7PLzx/RnpKxeaSffz79cncna04///ofH+Fq/fnNxu3DOPyM/pw+zNf5zX249ew/zKX8 85l/TKk2sl9nZz5Myn+t6qmDJ7F58pm728ujAfF3e7GpfGKnDb5+lYauNnRlDi8t4Q9nrzB8PFvz gd/Naqnl7fyfP//04+vnj19HksStkLglCfQyK35Es9VpYOEwOq3HlYUHXIhd8yY3/IY7xGGoFbeG Fi7A3qKMArt6S4Wu3lCrMq4dpsYhkwwZy99h00MBLesgCxM3HhFiWd9jRwg6vEwK+KjH4fhoHD0L 7gKEVyeCk1+pWcQDNfCb00eXjwkbXcr2jQulYYjnt9zuXv7F7wH27482kJaetUNhbaJUJpAN52DK Od2B0v1i4QCQIUufG24aThL3bIiuK3/WwctH5PZvSx2EeRWFpZJkw3PfPrw5uz1OU8NUcqTy9YAE Mb6H+RmiZHRbMiRVSxU/Fr78jERzzbu45VW6r/LPvTzxfa+50DpknGYotUXnYEVFulfXNbAr/Ebf Wb7ywhMwAbakNdjPTJbc6FDKg89qsiWM2+RklYxcbGxoUb4HklO/HeqG3DDVhsTrtHZXmZyl2BpS WZ88YO4m3UEMUACQrEpiNiG2U6Jfeq1nPD5QJAf08O7dd/RAXtxEc+Bk9zJNDCSdmTiijS4s3lXj AGc55806cISVNumRJDuT7Vm7uph6M2Wu5dP3lsbFXm47LsxN/b0bSpG100nMcElaC8M1g0xNnP9Q hGA9upLwcEdjQn52QA+zZZvece9cs6BWsmVwezlvMzPeLclu3UGxHORhDKpu4eNOATrTd7bm3OkS sv9w+tmYkX0LRfs9wQphW957tR43OBFPFMzs7worBFP/PtJ5QKANdRzjFE8sQZJk/SFL5HZJpkJm aDs7WybOYnCDlchEoZ7IotbDGKkongNSrGlAKurwsr0CUV1p0c5dMjK5K+sFB9rQf7V0/NUmriDM n/2BXxrz/41jXMIAPOMKx7iR9jIZyNisgYpYlT/44fNiBTsgSuYfrRoDV6tVrGGwmv/RT/bBqm6o eNo1S7nX9R3Z6ZB65TsRZx+UQCdhdn3mW7VbRrPgYzbLLOlkRKOsUwPgg2YS0fy4Vuilx5log0qh A2JEOwBPpi+J7kP28ttg3mMs7EUEyfL9KZ5Bgz/V3kCj1x5ZfuqGkY5iD68Ep9+cNCeZz3tWB3Q5 u9zbKuYYIKQawiHuqXgnH1nGRujTHBmI4NYB9+UpgtUAhbwhgyJOLlREr2Mw4WPv6u+5JIo/aRiA axcoXZp9ZQbdhYcvQILsYw2QoD3S9i+ET9d6ogBhA+4tfipPw13zgwVhS268lOfYLNxRj0IzX4BV 8NDR5gYHKzVxgFaoSLKRtzFLDVIyoB2yaI0mqsRpJZRYHpCsE/XDlNxfmd/8YEuN9XdQw8yF5dOf hX2zPRMjmRV0brGIkWQlY5WWuanREJI2fXZo0ZjQ3J0lLu+XzLiCzgoLIy5NpPQrKCgSf+QQ+NUN kErZFVY9h5R+xLN+MWO0ZUUea6gwN8wN6+amsNO8KetY8MpyCoe2cEfcGDKOWuNAc/Y81kpRJO5A VvBRwRGGv7KIHew2bvNACtOSYAkBDZLTadSAtYeY7YTauDwVSA5HfbCgsAx2Jbqij+mMRX1nMRS1 vmsdXG8kyDOGs/Hj0SCU4aagQSokrGQhb5MDAhnJbh9iuGZxocBtUbmyxjgghO+5sHPol9GhL6t4 yqdfOp8esMXi9I9LBaWNKy9jcLSlGRUw/WJkoKtaae5BnihbtUPF58JoHgXMaOepVzKdH3gwh3UD BMlLTiDkCjRFAtA1Jsai9jwH+iNo6Y0dzc9DLrX/Ci7V8NXPmbQqlY4DfdP6MJy0v3W3bgNGGHiT vNYdnnx0ym5ZR08cUYbC3r/D/WvwtMPQvB550Aa28fujNO19YNSdvg2nh5fkyKU0Aoh/sRy5GEcv N1C8nOKEbgGFjWZk2ReX1p45ylO4EtF0YiqbkBfHyWv0sUZsHIUcYXLTSfWt/b3h7gWttpVVHew+ +AEyHAYzqvCirnE7QTBUOCPEbMXw9wIe5wfZmBCihS8S+bXBB9ii9o1UIABweLEC/iND8+UjOAxK Yi9XDqSoUJcRlPb990WG5oY5Wi2lXf1mCwd7d2bXi+1jzM+Q0qw75uRJtMcxLujxzRAK8FVi91ec 3u1DXEgJWDhufRRI3d+x3ZbRSLMBLTiKjnSTjFsfkIgIuKThkxsve9aBmzdv9ibrVzKhjv69p9LB 9tc4GK9H0vP/I9V2CQOimMkqY4Emwyn4gHXt0qy1UVBNS+WBFHWrVfxNTUaH2LWzjn0IWREFK+o5 buPa6npBxg5IktxoCHklnORE+SzHpBInyAmYDrJHdtKjvmOzrGlCmdRPzQUcyEEtZ3ETyhRvkkl+ nEnNgjSgnBYYCmkfwZnvQEZLn9+CFnUCoF80YgrxIADlfoX8H7Hw4UH7bbTHq+bFiwWWvpIaNsx3 /t77r3vH/Pg4bBod2b0ajUDhmuCOc5VSTCDwMZCzWj5rbG7VsIrh0Vuw0lSLbHBpeM7csUgm8JDm ZqcMobN4KthMYWZ/UbnkheKpEjtfelA8jqT1mc4xqwhG03qmylw7yrKp9TwRpdv8YAZLPpUN1Jun 5JMv2P25FF/FsJ78Ax8m8lcyDoVXfVITgB71PvXdKChdmdmT21KagBJeGiReIk77W17tgHWe2tne wW3qwKMWViMM3JxLZy9RMZT4ezuYtmyaz9AXQckC4qyD99GI2z4lFjOYWvLbZ4F8na2wOk07lBuM Gbs3ElRbYy/ytwyEniwvQVcVTTBet549dd2xxWOixHV065U2ibwKGo1Oo0tcEzKy4kTpwIKCITUk fTnH5wKNYRmspQ3nhefRxKPBOZZCSxzNG/OO+C1JSpZomyiyh7GgOKAUb881XK7n1kF7+2otg+qo glqWOcz2OUuh+0q9uBmmkDgVXSMznALDMhk9cJOvPQTYLoxxhZ3pVOIru5LkCtpje9o0dEFoNlgN clOIaKU5W6VLC3OVoOh8NkvszlZdZkc/rfSsYSmGaLJI17gGzWJL5RzZ+oVDWypwicZ91tTEkYG7 8qLcPtX2Y+SmKTX4VP13yyRw87OazlnhUuPYDTS/TxOj9DgoOS0Msw/gaEmz6spaOqIlbz6+khO3 NakILXztuTU5vSPWrQLl9gF9K84vqIdjsgw1m6OmWFWori9yILef0fe1ItY25ooGTlXtaMjaVPNQ xhoPoQvH6tIHggIiDeyJ9eHeHeD4SH5nlZw70CtQtiWoWuQhMpJ/5jrYNAaoA0G+8ttjHYzAqI4n tdtRh9EeyeisIvMiaskS1jINXGhT5xOEVXFoSQQHXUzRFWc3XlxLKU8c5llu7MR3UzAhT5qkw0PV PKu9zDuXivHG1aoyLXX2JVaq69wfIiy7SZT1EXJqZnENakFDIV5/W/fEkYnGt9Jb2Y2eElmGok9y 088//2vaKznoFQTjQAQNMjKc8wiFmraswJbF+ESVboFZ2wJn7xfXuG3LcjgrSIUDr7gbo8yCqbNS WjMr3ET+Xf3puDBY2mmLNZbbsGfTXXw4pvGkkLTBl2yytWEU/+EhLn63fnGxfIbN2PKZzLI2S1AF nVb825KfjGU2X3YYYPZYv0KVMzq//OSzIGw8A/oBMgMgsHAsCUKNpaQnlaFcAeLgO8FQgdJhlh7T QDUCGD3Bkw+7AC8tMHdZHX7NjRJ8DbWluU63kB+/TiQp9axEymdSPdDdXbEqC+jPJRBWlAbc4dXc 4NPjypjGEBu0Fn4C59XWTeLY+MBijRX/+AYNuTwoj2Cu1HqxN9w8UtTjwmw1heZlikgBqVDElLnL JuQwr7nr1XyVPcWAGDO6jUgDJ2PkpFuyIS9ovkCJQD8LmGKTAR/v9EoUCsRUr+6Ya0StclcS7JD2 cK1eCXoRq+LhAv825IDiaQCp6Nzu+X8hh6uA3Lna3HyRFkemWc6JhQyZv/yYdR63ThhkAzH+P2MA qRJ9lgHw1HwkpQA4pRGGEnROuGuw+Td1XitJBgAK7j5y0dIw0Zcok+RrtyyusDBTJc9FE18mgNS4 VgLUVYKpZVnN+ydaUDgnM/G1mEDDbSNtEhwQVlV0pK8uS0pPRZ9zKM2VSyUZSizIIxsroz0m0ccY q+BoIcqDIGEBnwBFedMwcKz81bQEQmUiXFF1VjpV/bc5aSuKjdb5uuxKtWonvV8oCqC0o4dqnoWm pel74i1LFTDIwfjNQ6XHIgu+g75fkm7YtHhizMV/qjF41Ff3LbWvwgyDsWLtVQURnFVTzRWbqkz3 RZzA1soJ2/gatKSMN8klzSutWR8zpP6qphMzY2/MUDw44mSW+FuzMIlirK8SSZXhiiDfqcb7DdUq WBp3KacWadbKNyghvG7aH0BP6ogSkApTeHn6xfhEaYcN0z7S6IYWpoIk6W8X0X7VxnSGlOgKUv09 baLKcitt/OWcmimv5cjhAiwb40R/P4F0UIs4Us+lFx16OFvfAkpykhh2LWQfY2WzMlxK9Slgzkfw zFFP/w1IoAqKhXMUiPUTJBssGSJQvqQxA7lv24dWsoigt9rcLmCncBdvweBOA15/SWoOxVRV+wbj a3N7axQuLOPVrUt1sWz9s9LSflJlAcPfqmZEbOqhWtcgGMIH5fqkvyrircLpJbxLolBuW6Iq7yGk xl+oujQbfdahrJohz57q7Ea5F5eXCSTVzlbFPJW51f6TiAMZPiha+eqVTbXHM9XrrXSlvcvvSurQ 6HpiHyyp0eexzNRHFjfV/humqBY9C7u8DtnfvK/6z2is1HmmDWYht8NvSuJJ24B1W7UmqsD62rYj y0MKW5Ruy9Wv0kTqoIUqii3ZMrOh1FCYBDg7H0Edkz+4ZUFzTuqi4abx8wlGqPehqo5NkrhDoFil 2TIDrdLjYbS6jpVhSOJuQ6qDy1qGxGFNhJk6p+TBjqkzqdbWGRCKwPSBTgg2RUo4lZxLCTdROKgP 3TSP3EExYh5wqwPiHaCM5yhFyeVekurl1tFsBLhKXvxwt7MCbX1h+LkTXb93ojX2OVaXz6o4KGS6 chWJTP5Senycnuc6ptSsztzWa1AYaF0UU+o9Xaap7dfq/mgZk4LvvcqjHfLXquvE74yBapaNsyVt aZGUcUCOlF9y0tbOIOiqz9UVogCJUtXrtTKSY1pMCtMnlS5D7J0DuqbmoYxKpB2+HcdKw4cXIyQ/ RkrIGlXEJdsG9WWpLA9G3k0ZHZNjVqn+0hsH+KZRxkAI2uGtGfuFAo7u9jnfi1Lz3g2jqprW5l09 HrhIXfJTxIzt+C5YyWi0lV2P2GSogW8C7He5/DZXy7TlScFOJEmKS5faGgtqivBEEoO4HHDPnXYW KYdYGhf5PKDT8e4nVfBkm5apadKVL6uVG8pUhEvp6lRvEyvCcBENX5Dtql+rmq5vUFpntG6qv+Wy aVvL+iiNPavWz12bag4s/N1P0CwlneUyWlr7dJb3Z7sU33y36/o+vzEASpQK3dzLpkuXbnjSRbFV yZSQioha01xbr/IcD+LG56E4dzmm8Ox2QFNovVc409TNSdX1E8ZvVpH/DeRaCwjXfXNUL5xAI3lZ hVVP8c1qbXZ233boAY9sR5cafutKPx5QaHIzQL81QSNZViekaNKm3qnQ5NU5TT/PbU+rdBIPKS8p WOUZXgWof8+qOFobpV681et/JvbjQmai0OSiwKE+3N/kY36dVe3TjZF+G1T1gXKpvRVSt2VFxODF Ojhu2KIw9TToopGaml7VHWsnUGPHYknDbIIuqCH6ioKHLDkp2G+8KLmnowuq+pe9WbqMUEun7E75 /MSAteVUv6dzU6XUPn/mVhFRxK0jbtW1n50I0vVyPxIl1l+6uqe2YpD98xtmxV31nfzk4mRsB9YV 1rKQ+RW+3ikWz1SmKx2PqTO5WzGw8x7Tcj2do9s4hJpcB1SkcrHsaHyvYHd15cWgznhd4iUjJe7I 4KBs+OLBEiitDsVKPpzlfMXW6yzbEKl6GuUm5dXAm0JKBEnFc5RXShadK5Kskc77zvMTNJrcqeB6 eaoJU68zBaSZzu29vtTL62Cn4AhfPz6p+JewLWvEcnSYxLhRYC61mTwgdTLHmfc+qfriAqX6Xi9w kTz5y5Ucg5XSb+Xo7KzUvz0/zVIc9WhF6wmQzoS0S1+beDza6rKCmJX431pfu42YifPeXyHOv6A8 xe1lOKnvSxy4++1V8ZczLSNieTZGB/eyGVs9FdMj5yQdYGOFxl67mDKzEGuFn10IQQFErie+v0q6 2RWD47LzGdpVUEG/Zsu5GuQy+Jo+9eaK9djnmbk8v57+cfrl64//5s3pb/88/fLzN7edbn8//frj fwGgtV+JCmVuZHN0cmVhbQplbmRvYmoKCjI4IDAgb2JqCjQ5MTIKZW5kb2JqCgoyOSAwIG9iago8 PC9UeXBlL1hPYmplY3QKL1N1YnR5cGUvRm9ybQovQkJveFsgLTkwIDMzMiA1NTggMzMyLjEgXQov R3JvdXA8PC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0IvSyB0cnVlPj4KL0xlbmd0aCAyNQov RmlsdGVyL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp4nCtUMFAwBOKidC6nEC7XEK5ALgApxgQECmVu ZHN0cmVhbQplbmRvYmoKCjMwIDAgb2JqCjw8L0NBIDAuNQogICAvY2EgMC41Cj4+CmVuZG9iagoK MzIgMCBvYmoKPDwvTGVuZ3RoIDMzIDAgUi9GaWx0ZXIvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJyl XUuPIzlyvvev0HmBquE7k0BBQEmqMuDbYBvYg7G3fQA+2NjxwX/fjGCQEXxkSmxPY1pSJpNJBoMR X7zY6l1f/vfHvy7q8qbSVxe293AJIaTvf/z9x1/+dPmvH/oCf/745w+v3uNFb+/7xe46NfDRvpvU 7PKPP0EP79puxsOni0rDZ1DbDg/efv7w+hKUTn3//Nvlt29z0ery8x//8WHDVSvzocLVfpibvl/f zIcO8DdeUnv6Gj+UyR+eGnynv0O9GrH5Z2quVf5BPcAldYO/vvD3rk1u9ri+2dqrpl6xpRyBNmls dMX48t2Z+mLsNQ3/lscah8HP5vBIQ/jrz3//8fXzx++vUM1HWJeWakbDaIzDzuANaeJflTKKSKNi Hoc2Zd6GWgny7NQwPaBj/DCpA/vh/DV8uHu+VPpK3WTi3K6RqIIUDUTR2o2LH1ZdzYdXClopW3vH cSxNftvffTd5eqXycjIwAB/yAPwW61TzuhVOePN7qE3yehmnI/w2/GihJfMVsRizkvbd6270ur2y HBKcCV17W5p+2PrJf11tWnl7fYvAX7Hrv77wLUw5H5bbEutbHQUtA9wI9QY8pw29Dn5Y4nubeNjg xqCub3At8L0bb7tMDZc3VhT7Qqs1Mnj/7npCqPIeY2k/DMxN78yXb0r8So+FdN+uDcPZJP9wGLrK r6/r9qE22DTqW7lr5vXKMR53HX6NqWE3b/zD3VvzbrtZuq8rrp5XTt/0nua2fViP/WXh5F6fQQSZ Ll5iKyl1IlREroF+0xrlpU6XNg1LqDXdKy3u+G4rruVn1NdI0vTf8MlzNippk04lgOzIq0jr6iQr R7E3i+hxJKbwE9uGURuQSM6XQJBHww91CsKjEHh5JnpXSUx5497rfvUwL5iNveoNpP7XVe8fa51G 7HSkkPvsd7a28KI3TyLY7enTpe23tBYqJm3evkl95x1M78o/834qAiVfg+/uRssBGgBFfpIHbr+a uhykMLVfooONiaxeW1aDh8TVaxROgMZN542zIKWtE1Ht4xqK7CCmLOI0SpzxCZMPPHkPsiAJUaNA MHrZ+uVRGrPDKE/mD/O2axvPxe291y3qYQxs6rJ8hnaV9rEBNLSfKuDQPlTFj4iEaeBRnfJDBUNU rKW9qc8SnSxR9VC3CVCXVVR6ihWf3sRoSHIUaZG0Imm0sEatPYwYbGO46DN5+F1TILsTYNgTYEiz RA3pikRKOGQyv51wCTxSdCd3qkfx1hJYSMlMpfvatDc3APY0XsnuNguCStik4d7y7kiAjxYioHzd ynB9BQGM5uuiBcDjDLvl3OCNdmvbZv14y7yJwyDAV4Qj7OONcal2huCIx/Ub8dg5QUKvoLPhIlkB Jk6ANwElBkk6lKsjsGy1D4r3ZAyJuRf5y09ay5uEBW99cxVPfKnSuxmi3GaedWcm0syWWaKX1wN8 t8AhfssSBo06fmEGjAsSfLepfyfhYSsaV6RiUrd2OmI0bohi8Pkc7KelbKBn+huETnn+dP1TkyCJ 0xgPZLCVwXCLFYUCC5N0apwj6jyruekMVoXJDZhJPIn2O4rjdJ+ZHtAwMXU1xLJlgj1JbYL9fVfo 5qUcPULr51NEtdlO0RuwFhr9ddONHYlCN8vcrdV6yithwtzKPqW5fHYzEbsKxHcsPWpa0PSaENvX RIa3TA3t0+Z+I6s1PNOmpm5yHPQSuXQYcKbUazo7Z6ypbDw6ISRdmQny0qVHYxXbCPEP6Vp8Cnlh HL+RN4DhDaB3ZkgQbfJeZ6gu0UP5wRprWbmYldVZ4Is9IVdRD1/LJHyxWT5OdhT3KXUJAS5QaOCM ORNHwGi1j1bybHVz50HT2D8Ffy3qRxvtiCo7z9MmR1FsgqK9k7jI+MyBdsNRmCIossImKq3LA7ub 0by5o63+WXsfBlkFeLLDsrcHvSYJrX3DtcDXyqR0L9Xz/dpuZQOTjMlmhAIngCrsszT1TY047rui wt4yyRPQc6Dx8ntjSO+0CUH6UTVXu+V1U025+TTMKKSyFlqSTkvU9HEwBoiRQsHDRZeBOg+kzt0z 5AC3aK+aYbM2DGWKhfbUvpozlLDjYfGFJ81Z3IYSZ6YfS+Rx24Cgkh1G9NdftJvP1F0g99NE/9Cd Rd2D1PLqVO/wW6XS2KXkLq7fJXLYnmU7fFR+SgEUq/QdEVSBLQ1ul3DjhLVbh6M1bnSruqtLxteu v1tAU9UYe4lLMOPNanHlFDEVThROaMO++jmxszuam55pYNPLlG7C2oyo18gtyRKw2KitIzxbuuBI IFgSdKx2U9lPeSBu6jLZwNw9GKEOEF+zEohNRObg4mp6iNjDOM3skbK/5GTBlTmlq9JHWClxiPAU lABSjqMRLEGcJsQWITlqi8NFP47Pe9kR5+z0Cc/bzwbnlT4e+W5pdSJQHfEYfk4tqnbGJhmLA1p+ BsXIX9pwbTGspA/tzMAS7rLWAXXgdroJZ1xxzzVLOxJYFzcV4vRYeR9FJK3TN4pLIvIJmbZ9dK2+ gFgdmRluDqz2+cKRbYUkhU40dzKI2EJ3R7LLaRIu7ZUn+vpk5iEMSLhxE0orl9ek3X5vjkK5do8f /bNVraO59GYjN4Vw0TDa/BB65+qaAwEpZJCf03vrOGS/3v1sst6PiOiJxy8047rl8FjnG66sh9bA CxrNODsgRP15DW1okC2ObIgFssRC8XN3/rwQ+P6RBeVIEe8q8e4186Z87tydp09hdjdHO+yopwhQ BOxhUauHSU8xlvl1G7/Y3ulRbxESP5eHg1H/qgw2agSao3yDxADyv/jYmdElG2BHGA2+eNpfqWmo j7wq2LMFW8NhyDq0u3AEw9iEIDuZptoHbV4C6zsEKuVuBndIkQhJ7hfB7zAu3wmQSXpD9mR1TyrX KhT2tRwPWsdthJaeAthtwEIm3AhficSOgqfXo/Z690VV16i9sVdDcXm96QeG6el9Nk8SlM3dAgk0 CoU3iIXBPa2RrTEsngP799K8aQyiFluH8iJqjUgFcwQS1ubr2Eea9T0HHHEBIelmvxZzjBpCjgEM LHKjNFIcmhtTDJ5SJxnotqMOzQeTGSxTBn13eXdgRBDSHTK4oCtpEWtWzQN5yYNJiR2JwVOCxI0V Oqx+Ghd3/doARL+RaVgwQt6Gb9hPhldlmA+MLxlSTUNI7JxewRS9roWHKwAbPDjxAzlnM7RE8OVV 4uD+ghFvhbLYjWCb+iYkzT3nmLhCIWKD9HVpWl4XoFanhayX2T0NcCucX8ZATJ8HfE8dtENAL0zQ Gw0wfRgeNG3tPOPPyuHqC/eiVkkFD97r8/HbOKYWHhoFIJN7xwvbj1vBJzXiIY2/qrNLhhX3gXgT lbGETQhjskAOh8a8r1ow5vehRK+wfj/EP08JY/YRmoH0m8WVIroj2twujPhYDrGikDKNLptTshC6 STHDqI+0OwrZJsHtJhuU4W5Nf1rxwuhkVA9hvbRPFKvqvVo9r+P06qPghyW+IHixz0zPXQBkTqXg J4rWTRPf86QpLGXQLHuzW2mZPXqUYcOOvRXvKlBItfRBIyIp3l0ZH5xLkPTnf77cWbSj9mcYjkYp eZG07ULQIu/GvuZO0tL0/e66dijrBSUxTF5CUZCiY9rfZ8Y3+XygecHcJa2C9HMd8RLtdz36a8ry 7ziBGw1+zVO9qcEtk1B5eAHL9tGPTdUA5GEIqaTDFkM61KBlt8DcUG6WEMRVmaqTYxFgXmz8IIS1 tjomfMCLICklbe+VSRajf34f3TtdHFsieZRgAq/ejpxXcVVwuW10oMBO0iJvG5Ozb/2Vo3ShxgBU UaazNapsHHwx0GqC9+LGDF1kl/wzMAi3RhXrB+fK2b4lyam36b4tNghmy5Ag1zU/XLnGdJdzUjsn KuHDGz9sv5LMdNaVpAdNkh3uJR1rKb81iydKAFM7/L9ECOMG7U7aazSyDJMbJPqV00hUifqa1tvd ul1qBB+5JpS0zqzYjWGOQs0hSCYT9PLGvnXZHUV/BcEwGUf7a+OPWOETk/aOnRadPGECmSCfZdwR D1gaGrTMNK3BCv2Epk22fc+83yKnXnR0ALQWlEKmyaykhNDQ4UzJIwu0oZkWKtl2gA0FbVaw1vDv ESDbwH2X/BjFeqV5kdDn5/6IV8gwKS5BjbTNPIWmLZ6pesv0eX3wvItXWaGkPXqe80ciH13OH5T1 VbtpNs/BW52V+X4ACb+wb3fPH8777hUL2UBEnaH2ZBzY1o8LMzRXXzSp7ngJplQoki2r51iR0tMI UxG+oicOCA0Gb7uuq7PjopHOABtEUFW0NVHYn4W2ZKuXXJRMr53A1t5ldh9HbKt0XJ3+pKgFVmBG /a11Awo5YOreGOM4BKoOkl4ztb5l+q39ahpM0k+LPq+NFjI+66hXCTWp85CVBvxSPwK0LD1qJuMj cbnLRHrqb9CRG3EyAvppT8Qfy2ebX7Pib6IJc9kF+2UdQNsHOZHQ3zRm8D7reFbaYKEKJSOsgrZQ BiAqRdTF0C9KRhIXzQ20o5EaqMTpaqp7dvzGRj+3LnYrvAay97UdvEqSSf2CQFwvlVmV2B34HouZ YckQkBOVUyzGMD+R3ehY7uDLWgwReYLNIswrn2+K/UokcZZN9pQqk/IGI1HWaBo1M7QUjLfmQDBV 2JOrjKXamdVscI1xKbY0oSmlzXJf9poMie8u/1hs3WIE5buPZfqM1Q4opG8jR7LbqSdURjc1nIYe MjBVfTHm96Xq2aanKdFlxz15VgkwKQaYmstmLC9t6aHZVQLuFEe+fLKVyMkLPZQq21gLXGu34pYp aob3Dwt4X9tRelYovzOlHIgeSiBk7xvl5LUuyVHfPyXZpLCgzUsrrELDBAQiC36+S5YJZz5n945j /1AOSuPaer5qs/1MWRz1+mBZQpNZYb+puRShplc3a+ibNOkgvAwjun5Kp0l1woG4KUEBKs/Yyvao 7viVkAC9fZLsL+SMjjnOA/opUcTV4h82zXU0rLpO2dEoUzurXk0Z261Kohw2gK/N4Aax4Y0zI8Y1 65xMq4SYZPn350lsc5mWhXFghkBQnzrMDhFXecg8QN9BoVo+XCFrN4C+VAPQSHi6y7Y0lwk0kRQu AcBTMbYmqWas83tGiGnmflmtJLCJ5MSLWQ+cHHzRrEqX3LMYxKLxTbL3z+lmCFyZraOcofpBuDGn XbpluMkiTmqT78zOL5No55HTnUs5+jo9JrnwXTGkndRC7iTAdoNHfQQqLXAL/GKNOkrrzxV36qwY +6RfqxIHznP8wXzzNTCXAEQmsoOoCIbNSMftJQOZ2LXzEx0ZsU+JPcn4P82M6ghPGol2rI+vpMJM 898wFSbnmjkFLJvQA549UStAXRFITR5pQeIlMLs6/1lKP1cmknsdynFpUDB7GJjPeiT73aOcqhGr YtiyIA2wRdk/qZpNnE6TebYEhPZ67AjoaHGR8c5YgbesK8ZM/v7koG3guOKZzGZ271whBiFjvK1k YdHJgtSuW9mzHH8LSUlTvkDmLExaYBYD8s4HYEZm7+PZLdM3Cn/I8sQsIMP+rcrKvleuqzSY5MPn +EVxcMzKDmQY+kyF18MubEGqTQDaM2worqadLdiaz227YnHRxXkO5uD1fkqNSbJ+n/XKAEvUDtak lAb1oImRwYhWM5UsLDNGMmoupUdLeKvvV9p++5uPPlrpgqnrxdC8qol1Vpnm9UNW9KNQH7ikuiOf ZN6a6n8/EBQiIstRBCkFJjFlL22Z1noRHZl59VQTYfPrmmCW0N8B33o8w/Zk34hQa46WenCBmfvg Dupjq/5+rYbirhpnPsNU2b30GFUZtj73WUp/rXKh/BuUYUSA/gAILa73e1r4DZooPAtXTRE4zDF9 lKWl0GwVVsBATxPetebWQnHKTlh1rlJpVguwBqGbWGzs2Dknh7BPY9idlnfd6e4sAc1f3XGrdJmU JiCQs1/+dlqX2JQGyey8eG2Pz9nZpY3JQt2ecAU/CrbxIqPjGBXIZv8vTTzWLrygh4t+9U/kied2 L4QCSbFhQvAL0R3eO4FpcVxQtkqXWSnDl/Q85DzMNjezT0OUSYrmtKgyQdHDpP6StDmJGsk0rldL Tl+Z/azCocsvcezEFCLVhl7nb7Jpk50XKpix2VkoKjWaUwhc3ykjVrrXAh1nqytVp83MQmvcr4uE mVZRvJaLbFURg5E4qRbHPa71ZC/wkXgNlM6ALZlvhhJLTVtyJs0Q33Ywjccws8lwxJW9Muw35B0n VqT0sEoxLvaQOloGm4a0OFjXjXT2Zg+iChvpxs1ktOKDuFa4ckM6baRZwhZP8fDq1LhS4xdLarhi UFaSkuu8DW2NrofX/TgOctK0BIrzKuYFAGY9WLFTCthW8tfkyOZiNsuKHoUZR5bq1WcISTsJo5nl 8KooCpE5ZnTS2E65u+CTLHBmEkB4M54PipCR/1lc6ThHj9QTnozDCe4N4BLu63qQhGPpJa8xW6+S hAtKzvy1Q7LF4XnM24SVK9KzK35GY3B8fjxOscpvCn+Y/WPF42KtSx3NZn4QN63jbxM9asDSv7j2 RQ/qYo+zNYnB1tW1mxTT1JJixNs76tlSKK3GE4HlvaaOQmQVPkT1tmqP/WuXfibGanG3os2c7Bg+ t6EFO7+YNDEtnXla1Wwy/MoHiTTGXdWER35dlGVAkKySu5zKSL22+pogTZM/Uo8PycthSF+tTn9S MiO0nJERl+bQ0+zfUGI5pEPLRAkaZ6RAMSz6y8vb4UHZgGYtC4r43GqwoeX5Cia2mHco1YLBUnxe 5/P1Ch5YJaA6JV+DyEUqV8iHXEpnQTv3Nhen2vJlIxwfZz8W1Er3EVJJvLXoiuY4nCDatFnjbebH ssyZVAydqIuc+zrL1xIXhfdfXn6OmcaAdKxH+X5SzKw51T7niKNpvaMxujj5Sf3PaWjhuR8+y5xA 3lM82AAVQyhFMn7mVxb/iEAI3HAWB0Y8szjNSTkSC9E7mUhiovK0XtCJgE18h01I3xgSL0YYiNWG qBJbsW1REqzYipcKqlrdxnG/B+Hbl4ngkpGvLwnDTnAxRU4XIDEkkOwjSUF4tIV6T/MwJ6VOTmsU SPcawsMsdm1F5rotqY5HcT0R3OPUJdUocsHSk39fIyeKidctpIkFYSh76RBg43nBpin5giOwE3Ww RwJdnldMx2N7vnKUFFAdVPDUHQvMQYtiVqwu/9IGhFyNtva7s3eeB1vp6nIgfKy7mnuy+yqJwOFP grb9ObFLTuJcln1EOnPgwVqYr1PbRcLgwYR9rDgnnJ5SL0d017brpOIrH7E/O4Ks5Eng3trKish/ yqOc9NZ735s2U1Iyr4MrtjjdOOvQ8BUseOuOabdlV5pGkleS/n751+W3r3/7s/WXf/7P5beff1h3 efz35fcf/wd1BFN+CmVuZHN0cmVhbQplbmRvYmoKCjMzIDAgb2JqCjU1NDQKZW5kb2JqCgozNCAw IG9iago8PC9UeXBlL1hPYmplY3QKL1N1YnR5cGUvRm9ybQovQkJveFsgLTkwIDMzMiA1NTggMzMy LjEgXQovR3JvdXA8PC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0IvSyB0cnVlPj4KL0xlbmd0 aCAyNQovRmlsdGVyL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp4nCtUMFAwBOKidC6nEC7XEK5ALgAp xgQECmVuZHN0cmVhbQplbmRvYmoKCjM1IDAgb2JqCjw8L0NBIDAuNQogICAvY2EgMC41Cj4+CmVu ZG9iagoKMzcgMCBvYmoKPDwvTGVuZ3RoIDM4IDAgUi9GaWx0ZXIvRmxhdGVEZWNvZGU+PgpzdHJl YW0KeJy1XMmOI7kRvddX6DyAarhnJlAQUKrFgG8DN+CDMTd75mZjxgf/vrnESlIqsT1GA61uZSaT DMby4kVQ5tme/vP028mczib/M6TtOZ1SSvnfv//j6a8/nP75ZE/lz++/PkXzfJzs9ryf/G7zDfHw zy7fdvrlhzLCs/Wbi+UzHMaWz2S2vTx4/fYU7SkZm8f+9vfTj5/uZM3p2y9/ezEfl7N7sc66izXw P5Mu/sUe9cJb/fvzcg4uvRhXPo8X+3Hx+eZwOed/R9Pu3M31EvNzPt/jj3avzddfLylfbA/SAAe/ J7aPVL95zf80O0xDPmTrW52Bh/KEEk7uuPz87c9PH9+efnpECPEoYtZCsMaFPHsP7/8sf8EUrKvf 2ff836PNxW3Hi9vLPWUq9Tkb2/zrjA7XbtsPWuErCRTkbWAxbb2Xszc8tnnPX+fHEw2TR7jSnNy1 CTyLP+8YyC3YDUZfksW2P8deFnsdtgmYtylLIvF/6przWkNsaw3hKO/eeBvzV4kvHfCt9WrrTRnB 8G1KFeQG8Gj+IJWFzyj0LYD0loSQtk4EzhYROG8NTRzXTC+V+op7k2DnU97E/CyvJZtXVVWSW9rE ndemHhGGTvy3Hr5Io8gibYkfjmJDrnnopZXH+Bx6f/Aqd2DTWtuUwpHWSpNuQhOPo6xcFJ5lN3WM uqWeHYqQs3VOuqJr5xuu+sG8/tBMifSqTBE9xZI0gs/etdOEDc1c2HfZMekcY3F5HkRRP/0Fpuuu WQ/E1nlwor5bM9g3bOXZh/ltqCk2Vn+lh2vC61UG9syvicK7Z9+JIuwXHRl2kvLZ2TYPe4DLq3ID 8SRw0htJL/9tmtXb6tzyYuqQLmTfBgq9S0XEnXcm0WPSWshFW3DRdVy0XnBfji3FLIYMZ3LI7dzk 9YJzaLGAwoecEu7dOYLKYux0vsTOvMp8h1V3Tx1L8xa+CMvuykPA4mQ8ra+B+w14lbwhZ1SqA5TC VB0S3zblkfZqF03IHBmPdCZEkRJ9VVtm2a0aIst21ZDaOxCYAoY74Q8mnqX3Uxbjp+U4XEeF1wTp Vg8xAjoQv+xAwrE93wgloUYlhDZ5wyWCamva66zBkHZEAQf/vzqVkDe0iFFccG9NZhBwtk45clSg hcFD8XjxKc/LEZjqjBVxVTXZJRHsaQBXpIAcxbLWwc6HY1hZOBJdcunCSEA4HxH6Dx7Ivee73Uf5 qwDWw9OVrESPmurScrcwAGqw0E0baPv4bKaQFaypLqPr6qLPdSlLE0i9m24Sq28DNGXgLQXBJkCZ CeIFWBD5V0AW5bpzgASF1dgpCHRDrlBBQhLjxTIeWXAen78XqL4oxtFFWvW/uCacaEd0qzKXAkAt phTFIdkmn1EpLUYe84hSYhQyvU5a4+nKkk/ifczOHj7XhOGPAd14k6cVjcnj+RcfJExjWVjGIKBV YrPr+slr1VtTc9D146MbJhAc3sEA9rycHa66dnf2S9UU2laVJ2xvoy3K0UMOYteSPNw+YF9HSFyk IdVcjbOAUOqsmwQKbsmwokKx5MmA/euFdEoCkIJO8uXbyQUmnw0f+wYsl9Zk04hTSvrNlhcYh3w3 gDEXrREKWlGqw2qKcKR8BEEW+FG9g6O3RNQWUiVGNcKXLMnHxAHW6tS/wCQLMrI3IVH525cbQf/y p7dFzHOUg7fl8aItrqPZWzG+wejEkHWRMqNWE3s8oDGcWSMH/OEHOKMgNHsBtZf0vnIxOsdxXujM O+ZFxIOco+W430zh4PwTEE5+JBoekWzps3wvYIM3ezPORa/gdzcCWEeQu3grh7q7T52Zo2ASDSMT tJAB4CghlNVZXt3/CbT4zYws4GIsmqAAa4HTyNFgCcyTnuYHQcFtFCzPq07BO2JuMQz6eIwA9V1w imLiLYk9Rmn7MdtI5Nk7f470KOB+9iR1oxu5VR4GrI4YYuJQVZBZW3TYRiCEtGw8MCd4mJTlRxBj CjpWMjYQHijtB64vHg8yronnNmdAkf2s5vc9DKj3A35f4T91nPMgGJ8OIjBQS8tyPKyn3pfEVXKd HizAVwAuUoQ4+lv+J+YVEiSiG1oShgsjJjouxGDXvSmqu4Olb2uByEI6UJ5b9DikRaRpchLf420o Ki56T+seZgmlQTWOklQlz5lBVSSgcZ9fdmCFQLpH1BGGdwKlQdHhU30pwxC/fFRwdDrLENQbe4M5 VArkHSEZhLrm/srJ427IXslxHGMBcJouNF6WEBXxskNJ5paoYX44z9W6gtuPAY37kjqC50PWU9iH SDKr0HqosUPmiLllEFUkmSgNGtOldKajlzgdjdIv6YpVTZV12WpJHNs+QKv8niDSiYfIBf8iEwuA WPvR4e5YwSdCRaLTFPTq/dToLQaOmb5VQ0+Y6CXJpDTyhlfp5AM4OCoSKJmM5AsJKMKOR53EA1d4 Q8iAYvND4CHsPBG6dhY7td8lQcQ4lmaRiS3YrK+7vIvSH3IPsvQQtUb1laN6+7V3eO+6rjXzT9uN xQ7OClV2EZW44AeIPlScJXRQ/FPFiAfSw4IAIMfZ0iqoVs5qNijmrdMoDCC7fEMLf6FQMjvxZzhd zgZdRa46SlpId/bvzumdH5zKkNF78Ku1yC44qCIoLOqXa+HjYklKopA5V28atgzRGL7i3W3wb5TZ w6LLzba7WY16AKxFBnFJAs6M6D5cNuSgotxTnFal7RCOcbaFOK9kNAddxK1BVT5Tqhc1jyywGw+0 wUBJ66KEfhBhutpL2YVrAXqJBnBveW9XMYkz+wDZ6kych1kEYvc4RubPaLAojxIAvmbngqPgIB0l cYTnJTPagh3yX4JHbJUfl+i9jWCmfE+9o6hO4UwXzcQe2wDtQUmC2gqgO2MpacMmRrWvAcgOZEQc WZRKHwsA+4QtxIHcvVp2TYJv17CbIJeWvMcBf+VloQI+xJwxRBZKLRMV4KRcd1/SC0ARVlqIctqa WjWc16d1o0RrYpf4PdybgcBnp0pPIzLW0KrdwgDcG2aynmnHOuXsp4K7utDHvpLR2Mg3/0+kkmY7 hd40peI4KDIuVVQbaBPJw3KHxqodJXejxkvRJrHvc/DK8kmV4EoF0BUUqkrNHKxdPYcVZBk4isjV zV0+SNdWt2NJJtEOyF5YAKfvY937vLGFvRuVESPIHA2TyaKuPUSY61henTBSLZcJ3Le4Md/U6DHe NElGzSraSwLzx1g2NlSOEdoO7kT4m1gKIFgIWaNfgk303B9A+AbAbnU4iaoi8iFLMnH7LezfGFJB 3EiKEZlUlf6XDXMBiojdHttl+jQH8QFgNU4jYPPnnt9X6EcEeVZwUjjhJhUsXjoI6uXWrOS7r985 +o49lNV4yll+ENumCEyIAWpk2r5SpiU5mAFmrtUQE3ij5L+vDaoF0ASuMxU49FlhChbUsvvY6A2Y 6T5iUytiOPyIpJbkwLNqTYGI/AhBqjgmpAHfkBLXR7QEoIBqD8L9aK+bGqR9a7jzgQZk4M7vAC/Y MkSAzEsy2+2IwB93eOCWH2KbSxwAkmfT8ZATt52uT5jPJm9DyS/f3PcFKOI9+k32V9lQk4oVGW1m AGBtmbLTpKC8PBnbCilb22diCe+xaHmTN+AOy2Pou1zf0xP8eG91JEbRY9G5PsYvNlXuAzoX3hs9 W6sBz32BL3+6IwKBnWEAcrhexzBdBNe3XeykeSHwI7X/qQ5KjNEf1lAatrHKHLjsNHK4oue6zOcB M7jRaNiw8FrFdAC8/v1iXTMlB8lBCWcljIn45A4lKXWr//Cf4S12txMFpKkKiny+G9leR3fZciDY eufu4ec1Rm4sGwNv2FVuZOYmi/sCgqwhEJe1xU/P7oQ3/xljTNQag1zNpkTIBYBEjTiOqIiCk/hx NHXkNzhbffRlKm1WqKwv6wbaxv50hOMXqHxmUWazoz4mMq0JaOSYIF3dm+IFwwplR93jcKNyoJja mvdxhqHIrtb4+EajR3LQyoS2pN99IytcATQgqclBoHvLY/2+5WI4w7WHJDmw9DCUrGtW7PmZDtiM yqwQtDGhdRLKb6dlYassclVOw1kh2AA+CxESn1TSbT9eXIjZJsD8Cl+tKhleUOoq4sABJ7zn1oGb Opi8UYKgz+UlTw4Jqda0G76uKPfe4lmGRqsvnZ3F+Szc3W19ANNKHHbMpIJBLi2NELl33716iidd 4wQOxVY3I907I8UeFaSHix2zD/mOqgeIaHJGBzuOCoAKfVPyRgWbRrUIYKt78ThvsobKM9yAszFK wTHaaZtKgEGd8Eq1oPIhTyr2uLlrbBHgfa3iDlKZHNUpSI5pat5VnRFVzporWWXyGWjJ3UVt2Slh YjN10xypU/z6R812dl6mUqxv6Dg4cE5crmBGnDwyuhHijQLxqkcbz8/l9Op+YctK+3+W0H7hAwMb QAMTzWjusKXCyirew9kkWSK8K4/pCRrqoKLq062Qwx4guovzfKSyKjMbXeu6ixz+a/RQrXCyBqHa sgVqwOY3IQSgMT4wT08rM7ovmsnJmu4wA/WIHAiJeU0eOVF8P2K8GWyVF7iyF5HumzbvvaqTZJiK 7pJnwGNqA/t6f+GTMzY9VwxFfARMI4tMqb/ouDKyX6TvVacOPcmZ9MfsRB+kypBfxWLnCht8199I blqWQ1Vl6QEVGQ4Dgdilu1WtAbAFt3QHe432yXl3Oc5Mkwb1OTiUcAmnOyDBIUN6Yn5Pn+19qTuT E0BOVRlnp63PLoqKitdNmgPMobNMePZcPd4UQ1k98RCMZEWZqPkmOcQDVn5fCJOTP7UguX2XG/Cw kX6/6Qg8xHDfcIMsKQg6tCd1ugd7m/Y7X+us+v7yJwd9ettXh/XcTVng9rkWMIy7FybKbZ90zHbk XcaJ3jq9Y9kyCqVJ3YO1xMEmU89r8tT7UM/QaodehJ4nVGBI4UXuO8N+iGtnMgII9r9IwKwM5rH3 xTA5pCObJugAER/F+GLbonS0zlFhqNQfwKpkpO5rqILN2MTLkixe6tZ/PsA15QUeYeUGscxO44B2 1HYQSaWZaYmyIjxxCxK4+4TXlv3tF86pDecBwjnIopPY/Ds9nbLO9UUtdRTE5IjO3SZBnAAVDt+g ZFhdqGhAciJ/riyr/okWmCs9yc23rYJzlw7qiir3e3fBhbRDJa4xG9Z8IZbZqZ7BxhkE4DRkGJQE j/wC72STgO/aErDTp4UuixeRmuobaQePSpvRwic+j+1wfdcrjEXZ9H2xzM77cHPgTntz5baSWmLJ qWUrf8WD+94cganOooGxrC0mWArf6WdCui7unlywAPJsnOmjHJsOqELrHT70WHY1OwZkOGgwSpSe KmsgdMhOG280imtRrymFn1V1aVCi9e/xRlOufFzWcITnzmFMES5NhnbtVAZlB+mhn5YQ5cUb3kO+ pZlv2yKx8+8qpt+3Qn2Gswpw0lQ8CmZynEe7hF21MHpAa9sDYE3EFHVIQiTEOxizPNbqkViQL8Xy QKvD6Z8LAp8iesEkmSTPXn4hi9mxnRu7p35SolUB5a9VALHyEA8yOQWqf9+iA7ny2hRIzbrd7i98 ciBHdd2O3Za81xpTKZDfvJCqvdLZEWq3x5+Ms+1I7tje8cFtRLXSeuMHAr7CBLOjNuMvtAluqjab vour91ud3IOuaHbGJZrazYhNHvzreUl0SzpUDnlf11dIfZhUnJa/rWAHNpoPXrI2kq26HrOq3kV1 rqF26iJZ2P7Z/aTXFxnY7HxL39TQU0JdFJA+hnIi5VVU87HYR8r1lRNB7Bsh/x2PUdz9bSE5EoXk +zKYHG0R7HH3Wwc1PoKaVva62oCBqotBryFxbt/uen82k/Ml9dSCRlgTCVA5hdmrDdWRU6hHlFFU Q7fKpaJzmBZHPEdB8Z7xqe0Qp+W+wszj2RGs0TAvjqVX+QOEgpySdbYZPXUOUTz3NfUkfzWRqadd MzKQTNxf2+RUyOMWP2E9LG9Gp2E/nX47/fjxp78Ec/r136cfv/3uj9P7v04/Pf0XBHgg9AplbmRz dHJlYW0KZW5kb2JqCgozOCAwIG9iago0NDk1CmVuZG9iagoKMzkgMCBvYmoKPDwvVHlwZS9YT2Jq ZWN0Ci9TdWJ0eXBlL0Zvcm0KL0JCb3hbIC05MCAzMzIgNTU4IDMzMi4xIF0KL0dyb3VwPDwvUy9U cmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCL0sgdHJ1ZT4+Ci9MZW5ndGggMjUKL0ZpbHRlci9GbGF0 ZURlY29kZQo+PgpzdHJlYW0KeJwrVDBQMATionQupxAu1xCuQC4AKcYEBAplbmRzdHJlYW0KZW5k b2JqCgo0MCAwIG9iago8PC9DQSAwLjUKICAgL2NhIDAuNQo+PgplbmRvYmoKCjQyIDAgb2JqCjw8 L0xlbmd0aCA0MyAwIFIvRmlsdGVyL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCniczVrLrts2EN37K7Qu YIccPiQBhoBryw7QXVoDXQRd9RGgaFokXeT3O5wZSpREXTLJxggi+0ri65x5HA6tTrr5cvjUqOao 8Kv17ck33nv8/vmPwy8/NP/Qw/Dv84fD5XFw/tQ1ru9PffP4vXlzh0ar5vHnWd2Gx1+H2+PwbtWg NdkG78/2NsBZXQZzVp16GY7+DG7QKvR0xAedHodjf1YwgDprO3R4NdYNR4OfeNeps1Ghh0750Fjf BoON+buKn/o6HDW+BHDFW9gUNPBgCszN3MKAxtGAMPz6+HGxgpNTuveLdXTdya7WoZzqqQO6wkWr oZc+nZ2vBhcyXVoIi+AGoOlTrgY0gWDVOLRK3tICFPdEK0DURvrQnga3cOGnytIgtFq54wljQjNC BYpv42SPOn43WsZKkJoGYNDCLGx4C9m6WHDhBcIxwU4TerpJEPvt40GhYX1Z4PrT2wOZXd98bMB1 J+A//m5+3hgRW513J7MG/za04VJBXa71ijpkra0iDRsSBRcCJXwV2sh20fwESHnJB3AJ/3u4YRHp TjsZ4mbuSlsrf91dvH9HeOdJSM+OP+HC1IA4C5E9Tp4D2L2SmZKDzW8xm27E5zQXnzJs6AFbIs/d 8wKCobhRLMjQEG5Ey/X7vBPcRd6NCcxuec/w58ypXfNHkwnr0E5m7aflykrt/hSpx/IU7cmVLNOE LvKWeYRK+8z1URdacOntbHpkGAot1SJxOlqmvOllPhR42Db8ZMgcFyRoOGKbTXuKA2jT1kiETfCe DYafxhiGhqj4TmrDXq67vBASRV50B/hZIEa1SN6GmDDbsYaTXPOvjxnJ4pOIgeCYGA/6pDnFA3Nb RwHoBjDhSp7eUYoLncxOmRByn0bB9Ji4sySRXeRpvWXke19E3nZ2lSkD5CuJsEV82+zborTTHVt3 DH9ouZL2OJFJtk2DstxK4qa4QgQ7mDImvsCOueEf5BOT58EMMd8RT4EpLM9hVoKVuCx1hYx7pQeL M5RrsAQLu2QxVOXMaj0+L5Dl9So3BnWxUXQZujYNq4OWWOfCO15LbxLQIA1oOpscuX/bBqnIdLzM 7sEkc6AbDYqiNmgtG/JZ2kJiBOsldie9L3IYhjIVymaT3YIKE4TQCtGxXuZk23+rzBEnYmBXHiQx ngVlEm/maINec6v3siBaWKSmSl64BKWdp14m38AuWMDiesw+MwRHmRntUQoUmNEOd0V7zNSm+Wwv 38+PC4KS/gvoWR4y6QYfurhliNJ29hnZCBh0SId6n4U/v0fSH5OTR8HqXbfPAC24zIAxBfxNv7Hr gP2S/B3UM20ro1Q0U5Lw3xCqdiW8ZHU/PUgSvPT1kuQcM0Q2o3ya9owiyd0oX/jDpXrgwtIetvts fZHPmJH2eAwQViSbvphsjO/WxQPksJhqts2eJtXAiA8glDPgHlIIMnGfWAyuE5XBLra0trLu8v2p 6CWuXesuY2pS+bbh8zgJoaqu4WrUPoq0gjKKxhRjvcFN31rXEIz5ML/AMdNUFsD5SsDk9LkssARH h6jsKdeG+hVQ/cqupUyyTUe4BFpo5/DR6TH0FtIq/qddMu7buXOprfEssO8xbhbiLsUke0W0/Tlk UDWNIm9IvcnOQ96X+gDfukqIWdbWTtq04MKn7ZUOn161nYBoQO+guKp+yZ9dsosNy4sKI1YPqwdm 9gC2VYakqLPU77OXx1lButej6UwZ+77aZyN4UiUK4aUn5tG90rAd6eIlytvoLouKZzftADH7+7mA xyRep0a6S1NHHOCaZJNr6sbY5GXAQbh7iH6ZVGj3JwJO+uriymQdX02H1hs1q10i0RnEgGGsg+p2 FmQ5p8DJRBU7Yzrt3JICCbVfbKFpWAuXef2EabuCFHjx7DJzAXp2eEEqKaoIliZUg+M+MTqnoXHB UptYS9yJQBS8oOs2EjMJXpUbiVwvz5JvrwI177Ajs7SNXtRnZQeelMfQEhfVzrRysqifBG/azTSM TVkNgcHXXs804NcFpomqmgrVtvmTcERnM9jDJErvMXuFrXawZafi3WxQ5KEt6VrK/LuBUe/XSAI8 FaK1KwoCsHorWmsKWtuGT0ORjidNvHv3y/AXYyMHdyn+W6k/SiwysRbQTdLkklYeY1lglx4Cp6Ju kqNngTWTZFS+GtWmW+sVylMdw6SKCvGVaK9nfZEe1MWgE5CQQH3ZBpP50CwUEfMbcFhXb2XLFxPa 5pwm2d8jOT0dErpUE+Zr6wlEFZHLFo/jkJVVbiaXeP0geNvo/WIPfEGrsVs9KRTQsW2CFMAEEkQh vFDUcra8oDb6zOq0GaacrKLkScUNx6hJjUe/o4kByU4HdrEfVzCJknQNlFi4/3FdMV5Ibhm4Pu+j ctiEGmGkMufnevieM1KM3rzYyU45IiwdwO2oYq0kDs5qmo6bqZwoqZ8DEmd+9q1J523F+ZSE9uIR r7+iWliu42rX4XWfjGNFvdChq+T6eZL8IfVyMfL0RwVehnDzjgDS6jCPeZ9TSX25ZMakJm0Ui1Ha uM1+LwqwqspiroMn4ceMg58C63r34W7Bb1xg0AL9QYrNdUkGz9WxOJ/tOhChUZFeVLGQpTWszsOR kJpC4bbh0zCiExbyMsGNrKUSEu66S9NS6SyKl19xel6SvF2/OfsmAsIkapJJpn0xl8RYkWTDxHJB Uy0rbJEZBTMLAH6NSlJRP5jSkZP89Oa6Pmrndi5kIEE+VuHzcWpx6iUI0Q3OS69tMeuk24xn+dcq ShV/ruL9ptKbMFupFTKdPImX7ZypJFp8UdVJBpLfRr2yK138lG4q37BUi7+lk3LhLpGEXEWMBHwt IfJd86l5c3v7s3XNh/+aN4/P1jbjv827w/8RBNi4CmVuZHN0cmVhbQplbmRvYmoKCjQzIDAgb2Jq CjIxNTMKZW5kb2JqCgo0NCAwIG9iago8PC9UeXBlL1hPYmplY3QKL1N1YnR5cGUvRm9ybQovQkJv eFsgLTkwIDMzMiA1NTggMzMyLjEgXQovR3JvdXA8PC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VS R0IvSyB0cnVlPj4KL0xlbmd0aCAyNQovRmlsdGVyL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp4nCtU MFAwBOKidC6nEC7XEK5ALgApxgQECmVuZHN0cmVhbQplbmRvYmoKCjQ1IDAgb2JqCjw8L0NBIDAu NQogICAvY2EgMC41Cj4+CmVuZG9iagoKNDcgMCBvYmoKPDwvTGVuZ3RoIDQ4IDAgUi9GaWx0ZXIv RmxhdGVEZWNvZGU+PgpzdHJlYW0KeJydlE2L2zAQhu/+FToX7MyMNLINQlDH9kJv6Rp6WHrqx0Lp tmx62L/f0Udiu3ESaAKKlJFeSe8zI6hQvRWvClQJ0jW2rqyy1kr/+K349E79isHwPT4X3VSwrRrF TVMZNX1Vu5EUgpq+PzktH1+2DgZfh6ak0H6ePhTDVBxOKhUDtjZr1VzRphYwtFEgttQh+NZpDgM2 cwvvvXbQoNbkKe+JnH6pi1GkfBQbBhoMdJ60I/QIUQXJbaxO+jT6UjvDsd0v74LxNqgWN/jyUoB4 97a658eHIjrbqheF2lacBj/V42zJyljLlb5pbH9h6clMI7tfrndAfvpxg0EtqLe2jQzqBYKz/3W2 J/p2amoK9jZCqhRns92EYnifYc0csrudsBB+RmbFTlwTt0NIUxCwyevaM3Ai7mEMCzpfWoeDJwhi bYS5lJOo/M/BPJmlI/AtiLMFdyESgbC+A9GQZMUViJf81jj0FYF/S0Jo1KtiQLtwuUFGHVIc4WRz DqTMFyPFHAnYgCkeLDpqkv+ZWPyLI5fk76nkujNEQD0Kd2n1yG0QYnHa6UGjt86QEXGUjjF7Pcog FJIx3MrsJsSsY+ZeD5tcZi/uc2EQfHe4YCugr3IJtlw+WKvq2hC4Xyb/+Urh8pW68Uih8QZyLcT1 oQhF1yTsiWePCbudK+acAoFBD3vhpPNZA3dsoi2L1En1lQrJwpwzy2hcL2qNbD/nS04COYPsm4Xj HovSBAz9OWFIjzOLg3pVu+HhkUE9/1G76Wha1f9Wh+Iv+fBwGAplbmRzdHJlYW0KZW5kb2JqCgo0 OCAwIG9iago1ODYKZW5kb2JqCgo0OSAwIG9iago8PC9UeXBlL1hPYmplY3QKL1N1YnR5cGUvRm9y bQovQkJveFsgLTkwIDMzMiA1NTggMzMyLjEgXQovR3JvdXA8PC9TL1RyYW5zcGFyZW5jeS9DUy9E ZXZpY2VSR0IvSyB0cnVlPj4KL0xlbmd0aCAyNQovRmlsdGVyL0ZsYXRlRGVjb2RlCj4+CnN0cmVh bQp4nCtUMFAwBOKidC6nEC7XEK5ALgApxgQECmVuZHN0cmVhbQplbmRvYmoKCjUwIDAgb2JqCjw8 L0NBIDAuNQogICAvY2EgMC41Cj4+CmVuZG9iagoKMTA1IDAgb2JqCjw8L0xlbmd0aCAxMDYgMCBS L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGgxIDM2NTkyPj4Kc3RyZWFtCnic5b0JeFTHlTBap+re 3pfbu7pbrdtNt7ZuSa2tkYRQ6wJaGsTSQINBQkiAJDaDhBDY2LGRbTBm8YBjjMHYMfEwjoPJWCwh dpzESn6cP/69kQn2TGI7VjI4yYyjmHGIX2JQ61Xd22Kxnfm/7733fe9932up763l1H7q1DmnTlUP 9G/pRgY0iAiSVm1Y0ffSn3/5MkLoDYTAumrrgH98uuSn7hGEsLOnb/WGgor3/oQQ+StCan717dt6 fmuavQ8hPU2ytWhN94quX0umSoTuK6IBk9fQgOfT29TU30X9oTUbBu68PbdygPofonkeur131Yoh W0EWQg/QMtBbG1bc2bdU9QeO+i9Tv3/jig3dc7ufOYjQDgEhzey+3s0DXSg0jtC+ZSy+r7+77y+t j2uo/2u0fjRfBPSPfQzUqWJ+TDhepdZodXqD0WQWLFab3eF0Zbk9Xl+O6A9MCoby8gvDkaLikmhp WXlFZWxyVXXNlNqpdfH6adNnNDQ2NSdmzmqZPWfuvOT8BQtTixYvWdratqx9eUfnipWrurrR/9c/ /MPIgRJ8HTKjPvl5y4ecRG72Hv/jrc/07PHP/5+shUZ5HUbPorPoYfRL1J6JaEJJtBZtoSE3f36M fk5D2SeJWtEJtOfvZHsSvUjjFbhOtB8d+TtwSfQ4OoP+5y2lJNEGdDety3fRL6EMvUZRpRd9Chp0 H3qV5vopDZvzVVlhE330yM6em0LfQ0fxXjQLX6KeIywGR7GAzqMnYTnNeYC28+HrLZ76pUx3oXvo cyFag7ZSt/zh6679CmnH/0xbdQ+ahe5H09DtN6X4ATxNdHT8Uuhp2qc/lsOiE5HqBFmHz2E89ij1 PIJW0+8KoG3HD5NpqIG3wFmEpMalSxalFi6Yn5w3d87sllkzE81NjQ0zpk+T6uN1U2un1FRXTY6V lUZLiosK8vNyQ8FJATHLbhHMJqNep9WoVTxHMKCixmBTp38or3OIywsmEsXMH1xBA1bcFNA55KdB TbfCDPk7ZTD/rZAShez5AqSkQErXIUHwT0VTi4v8jUH/0JsNQf+L0Dp/CXU/3BBc6h8ald1zZDeX J3uM1BMI0BT+xqw1Df4h6PQ3DjVtXbOnsbOB5ndKr5sRnNGtKy5Cp3R66tRT11BBsO8UFMRBduCC ximnMNIYWbFDJLdxRddQcv6SxgZvILC0uGjmkCnYIEehGXKWQ6oZQ2o5S/9aVnW013+qaHjPvhcF tLIzYugKdq1YtmSIrKBp95DGPXt2DVkiQ4XBhqHCuy5l0ZZ3DxUFGxqHIizXlgXXy2m5USQM8blC 0L/nL4g2Jzj6x1tDVmRCVLnCXxBzNtHu3bOnKehv2tO5Z8WL44Mrg34huOeUwbCnr5H2MEouoale HP/+Xu9Q076lQ0LnGpiSaWzTgpYh2/y2JUM4t8m/ZgUNof/1wUC1N2BZOgGT/HvRiHYE7Q7ap4EA a/jeFyW0knqGBucvUfx+tNJ7GknRyNIh3MlihidiHItYzOBEzPXknUE6mi0Ll+wZ4nJndgUbaR/v XTE0uJLi0zo2FEFhyPSZNxDcY7X4a6JLZVg/rdXMrrX+IT6PdgtNdXMCiiksyR5B9pg+U16jXlpA nsXqrwnSbFg+jcHGzsz/1jVZNAN/cdFQIqIMfWrJkNRAHdKKzBg1niqN0hQrOukQrW2Qh28oGuwb sgenXx9PVq3GtQuXyEkyyYbsM4ZQ56pMqqFoYwMr2d+4p7NBqQLLKzh/yUuoYnzkVKXfe6YCVaKl DQzYOYPiVV7jniVdPUNip7eLzrQe/xJvYEhaSgd4aXBJ91KGaLSHCkdocQG5xCE8I7WkZWGwZX7r kupMRZQIlh2X2/iFbIJLvEo2FOWGNLka/xLsJUspoEAD/E3UEZw+lT6H1Lka+hVoh8uhDFWnT/Uv AS+agKbVGCr0N3Y3ZOCY/5ZMeYZOMxITuamYl+YzI+ENLA0on+IiTKP9mYJpCg3r1MREFMmllICG YZqNHMT6MovhvH9JsDu4NLjGPyQll7C2se6ReznTGXKfZ8YqdYvvps6i3YQCNHrCwzpzqCnivblz h5pl/3Vv4gvRMyei/Xs0wZaFe1jmwUyGiNZ85hBiKCxVW7zy7GfzOdi0gk5iOqPl+bznlCSxubyG Tds9wZlde4ILl0yVoSkFucd7FyvLilqgJTW9uIgSs+mngvDQ/FMSPLSwdclLAmWpHkotOY0Bz+ic vvRUiMYteclP1wo5FLNQFsg8fuZhOS2gHo0M731JQmhQjuXkANm/6kVAcphmIgzQqhexEiZMhGEa xilhkhzGPnSUstbQPqb0u9Hfxcbna0vX7OlcynAcOWmP0H8YgmCc9k4wfgqwyjCkC3ZPH9IHp7Pw ehZer4SrWLiaYgY4objorj1CY/AvWcXy0o0a6KOLX0Q5YDUqOQUoOvW0mtOMlp9S8e9PPU0wdaJT hAXzLPi0WqW9NvU0sPAKS8CSG7AEGrA/HYLD6TX8os+fb+DeRIwTpass2cknkA7FpbBgSBpw0tBn GDJcNnBooyTwgHiJT/LH+CGe1/DqQZ0K8ZtJFqofLa/3vAnR5e2bPKPtm8pKc3lHIJZr4WO5FXgz WMeiYEv/F+yqTHpjMS/XtCL2a7m8Wso17KU8nhcdkAo1DtDYQWMEjQE0OmdrmwUqLQ0WbPE1+Lp8 530k5KukTuJ7cXz4zJS6BHtLJfnhxIgPcNLX5zvmu+DjtO7WJB6hQ5/VqdViQa8hHUaeuJ0W3GFH VlRfPlpeXl5fwZ7WmugoRNtHy9s72iORTf3C++3UU1a6vJ1+KmJVlvxYwKGm/aW8XbRJVdTnctSe PIndJ/EdJ3HWyZNjfzg5tvskbdU3PLGYZ+y/sJm9r65kLcWxsde9MWXM5o7/kZwmr1LBQ0T7pKk7 dAd1mNfBXs1RDdZpYC93lMNaDnbggxirMO2EBAqggD+AhUBpIBkYCXDMJwVIbYA13DltVuLpAPQF QAp0BgYDxwJcZwDkKFNuScKZUFmSWsGbJE46OvW0naOR9k39/RE6RP3Cr0czrWQfsOPgpLxY5eSK cqe6soR6TNhhz8EV5XFMTr/724v/9m/vv/urs566rpmzOqudzurOWTO76jzw3ifjKP1ff7r2f/x5 xZG1VVVrj6xY+cT6mpr1TyB5bO0Ulz6ivHwBGnoJGWm1IhohUWivseMsO2jZv6PZLIBTCB8LAwoL 4eHwSJirORa+HMZh1gx7pDQRDYMQhmQY+sKD4QNhwiLOiJMSMkDE5kwgsXkwBCgkhPyh4dCF0EhI pQnlJguQ6BBCSdskRw7PuxfoBNoJFZYKZdxZb9BuGC2PKF3STz3C+8vp2LM+KSuNgN2E1XFSUZ6D HZlhr8xj3TKBBBQhoAmA4OzkbbeFJrdOy+1Pr79n/qLs+vhk6/Z01x37oJx8ZiqIFBiFUI4tZ/q6 lrFD7uJiN16+cKlKo+fGbMzHY3lCY5SguLGJ/BiF0WT0uBRYnwdeV8SFTc64E1v9enPCZy22YoMV jBYADsiL4yOST2tJAAFNtm5ys6p6sBo6qkGqBuooa7bns/4RdaZEfv48O9jz8iZFktnZaHLFfJ3Z qUpqHZOSSJARg3WJhU4EOhnoXKiIRoRR1inC+7SnGJJEGIqwB0z0Rr6JBCeV4FhlnKuHmIwwKjME Y3GwqU3EYa8on1wFP5c2Jou3pNM2c0WiY0pDe3VWzuSZizpKHzYFqsOlK3MnVU/b++4DtYurs/c3 rConP86asqplbKe7eLm5IJgVblk9Nd4Wz3dqgHs03Fie7XFsedPkSOdw2FaSjA+JWRS/ZtGOW0lp hx79SKpCrXY+xB/kj/Mcx++gDmLk+4yDxgNG0mBMGbuMRDD6jZgzwojxshGfNZ43XjQSI8OmOckE e0u3NcxMdBpZIjkJLjUCZ7QbQ0ZSyxkrjQ00kwHjDjnhJaP2gnHEiDHLtNSYNHYajxmHjMNGzaD8 umDk9KoODUF8B7HKxHG0HNo3dWzqlycdpTW0h/v7ZSSktPI6TjnUcI7RE0ZXFEop0xRlPlFZifyG 0o8gOvcS0lAECGuFBKcBjVnQGhJmoVmv/1iPnfrc47nA5dpzz+deyuVqjudeycW5rH1ZdDpFcsGe C8O5lF7mQl/uYO6BXJKbmVIyUDGbUp7mQXFYxEgURD91XBBHRJVG9CeDZo+gF5Mmn4NK4PYF/N+f VB23TquIjEjwv5tRDdlzUqmbZ1N8aozOpnWbNoGBdH5hIi1Z2HFjIhG/u1imOeN/xMXcfciNbpNq cLXGkuBU8IIXhr1Q753nxTpTM0naO+3YblcjIhA/IRrCGZJaSWtKaNV6s8MyHzGCSRv1VoQOGm1S RUW0XaBrRHt/WWl7hKeU0hKM1UOFo8IRtNidDNsdJgJzOzvuvqe7/l//tbY0d6ZoLqudbu9fjR8t zn/nndTY9mnTdappOrtZp6wFSTrfm+hYinTGD0jFu+1w2AZ6214bdnrzvFib5c4qzDqSxWnyEqJe LxahIogPFh0rulxEithwzZiVYG/JFS5J5ELiISc4UTI3V+VPugXVfItC8q8vbxTflrcLb5VHhetk HyYIPKu7Mpsns8HxATDqH6CzGjhHfX97zvTpcY9r2twlxVu+2VX01istD6ysST9ePT/mhq9bIgn4 pXXmg6vreI1OVW32Oo3Svd/f9tmnBcu/sXUBPBldfPfs2Xcvjir4W0gbfpi2OQutP8PpAL84/m9S VGtO2ETohe2UkoG2GZkEk980bLpgGjGpNCbR0+HBkgcW23ps2EayMGszw3a6ugvmpNWsNSUNDmWC 1TPS9VpFO2xi82q0PNpOyVeENjSYfyuauSga4sORKdmSVOv8Znr6HXeAVetKtreHyKvpjRqjVTc2 fQKnttjKinJo3XfT8brCz6b8ykfSM3YxJFaKRG+DCNQC9gDoKj2VeEcUHiwBR0msBE8LA5dlz8Ka QhvorKDXm8Cg0jl12Jwj5mAhJ8fQWlaH6qB6pO5yHUZ1F+pwaZ1EX6Sg1UE7y1HqkBxJB6dx9BRA qgAeKIKtRZAq6irCuUXgLILdAswS7hKwQSgq4DzqjskAk23BDg8SQRQ9HKqXcZY+hVGrq6b9+krP 0DkqE3iKEL8eraD+slLUvpz+tWf4AWAPW4UrhzD0oORdRQk9RRWnyxLML4EMc6By0CWS4U3+3mlB W8PCZUWz+2aG6lbdu/PeVXVTB759+6rTLdOCRYPJWeubJtWt2r5z+6q6ms3f2RK/c11rANZ+NysS sBUmVk5JLJ9WXFK9eHv73O1LSz2W9H8c94f9VS2RaYvriqK1bQ90th9aX2Owe4wKDqHxP3JMA2gC r5TTqlun26MjrWgdwos03Rq8iHQTTFSckzJSarpEnqE8lCrzhhfHf3aGYo6WLZ0h6tDBAkDQotXZ tVodhgUaraaZYDshGINWCzkyoNVoSWi1RKenHGoEkUlIECgKfi/RmUACNDO3ZCloSowIcFY4L1wU yDEB5NCYb1JCEPxCqUA4AY7TSDwoAO4U+gRM1wWNjpCkgTdLWuC13Vr8Fy1oAdNpW1HRvmkTJagu SnoYW0p9dLHYRLm2iPDW8na6UtdFI4wm7coSIrsi5zOvslKI0M9ylqK9XQtBkFcTrfwiz6Z3zUrf 0wnnHgMrqB6DZWTdtfvJXRTJvWN34L30zWhShD6sFMdtyIeelBaiWXrdUd3zOvKx7qoO79CBzt2s t0fsuMXeZj9qv2rnmK/W/rz9ZfvHdpVgl2rqEnaRE+0irrkiwgGRLjLiMXGIriDcAerAIqNcxaUJ +Z3lld+SYBQS/EIz50n6zHZ30jUxm0dZg+hC0s8w9X2Zax272C6vl5BBPQUvczC5sYLcbckpcDrz cyyWnHynsyDHovtm2n1sJ0S4D28OpVBX59+8bjDefC6lTflog5SvUT+kxhrjQ0as0QK4VQA+my2/ EBVCXCocLDxWeKHwciFfKHNY4eJER+ELhXixr8eHfYltut06rMtK2s1C/qT5vFNuTIVMhemyn6HC dMYtbwd5zuVeZ6W+NMMU6kzmehILlobv+s7Gyhl3/tPK+YfjVZHctTXTVjUGc2bft2pS84xaV43N Z9PNGHxpy+BLd1TbDOnPn3V4ol1PrG99pKea1xrUtH0pui7+grYvhr4phWaV7ynHX3Psc+ApzlnO u5x7nBxPV7PcCjLVM9vzNc8+DycTZ5fWmMjJolMlVxIcidxcWxOq8ldBFWt4aU4gMa+qo+qFKlLc lK3XZ9uK+XAyUJnXkIfz8gKCkOQr9Q3643ri11P6x3qCkiSFJtGntaYGojIlimyS6RDlEOhwI0Uc yVCWGCVCQJfXm2mQQ+khFSNB+Bf5qZ3Lo21zpxiLy8SV09u7ww23td3WEC5ZuLmx4f6p0bCntWL+ onDjkmVLGsOgqV/bUqg3C/zvH8gumL+ofFqRLydvausMqashaDO8ucGVlWwoqS3M8RdKyzKyKbeG 8pcCGpF0vNqhxlqisVpfHB+USju7Eiqr05pnbbIutvZYVVes8DsrXLRCj3Wr9VnrOetPrXzKCiwe v2sFOVHNtMYEi8YN1pQVl1sB/FawWwFZocZurbR2WQ9aL1ovWa9Y1TQI91lBsiatfVZiZfMltyAh vz0++S1l21wJ3Jo0jBiwAYwdZmLo0CUpM6ghnTrGcioLAONg2kdvzKR2mUBQn/zppzSlrLSDIiMV cikbY6sgmYmE73gbNPd8Iyc+zXr1I8qOTuU1nqtrTCpwpbcrXKnCx8yi8+b3VMbz0NX9a1Ksp2Br AT6sAa1mtwY/ycHDHBg40FhRsNkVQRFopl8pMhgZjhB/pFN2cBG5NZGShDcxjwfelfQ4bEknyk/q hCBC/vmy/FohvCbLKvJMiijL14SAIn9yTRD0WzJIUkLqGOFjSz7IE2lylUXGGvyLogeWprdXrHum t2JzjBJ6+AY0DKT/mhZzGzprp67LDW+s2Lm9KVgFv9ny8gONBr2e4qX5Slbx5y+5i+HNtQeW5rsE /HuN9l2KH7vG/x22oXcovcyX3OgQ0gHSCbrLOpJ5aXTmo7wNZfjifsbof4FwwTabv9jtKfLbbP4i j7vYb1vmLgrYbIEiN/PQSIaHuRQPf0zx0AX/JY3zRocx10h0Go8Ga81uSJvd89wd7u3u/e5X3B+6 x92ay27Y737a/bab9LnB7BZpPHmbRn3iJkNueNoNg24Q3VGaiCA3vNXrfoGm/MTNJRl01F3vJuNu uOCGV9xwzA31NPl2RiZhO830FZrtuJvvdMM8N5SyBPDUJzJ01N1L4V5wcwJL+TbNcNzNHXAfc+Pt buhkkPVuPMLym6gs75fTr6f1fVsuar8bbtRYCaUV7qAZs/ZwpW7JjaVdohtotT9kzRhy4w7mK3Xj WlrnkYkkrEP2u0kp84y4L7uJkrMM66fQLHOawbDcG33uQTcWlYbTjJOGQcOQYdjAGXCHdr/2Fe3b Wk7raMVGRFdorZ1OLuLAHWhCqKOzrAKiY2+0C29M8FjKzJI/y6/7vxxy3dd+PX75jQz6GV9G/Ww6 KtK1JcAWBxIBitVQ+07FA6dzvTO4Jxu81ublvVPK3qGz8nGD5udQm37155yKJ1fXK3onoGsa4tie qhtuk4QH1I+q8TxzhxnPQx10vX9x/A9nKJm3MGbnCHUYC0yWRK2hxdBmILX6Fn2bnni10KUeUB9U E0mdVGNOXanGXRjUao3JZDSrzCYjLDA2a9R2jUZtUqsFeEH1iuptFVGpjL0aEDR+TamGmBlp8kre Ti8+5gXk9VN30jvsHfGq6gTvkBcL3lIa0Om94L3sVSHq7PMeoOHDNEDtZYRvaXtCfs9ZpLxjNfJb skXKEmYkNHc6ADkEh99BNA6ZpFgdCYcz6UYao0AcSTMyqTnKsztUkCRmZV2mrDFltNgEjciSa3lE ppT9sorsTdr9m8qpGFFhrbFU7BIiEcrE7dIMa4YpB5IZawqOZH4rw23JjAjcLNIugftWwuwt6Suw pCe9fXE6fXdXevsde6EMXoWnvcXFrvSfxv7kopwIPLYr/elNOiFFXhLouGnRLqmAb44g0COY0obW o7vRUcR5URt6Gb2OOOZ7HhGkP09XWtYz9U0JvdwD1bWJA3rASC/ok/pj+iH9sF51gDou64k+w4vJ gAbKg6mSWoT4JMnwX6AsGZEIU4rKPXKLogJ6GV91DJqabqoywuOvpmfDbpmHLIBC6S2XX6NPoFnr dXdTrkiiLEOKspHZoeb1dtDbwWYP68PeME5fDF8K4/Xhu8N7wyQUhufD74Xx8+GXw1fD5GAY9GF4 KxJeH8Zh6fR3E2HpWycSXSzUG46EyTc+plD4fPhiGHvDLSyDNgZaGW4IY5YB3iFnsEEGawm3yYUc DfNhqa0jUcni7g6zot4LfxxW1R4LA/YzZaQ/XBoeCg+HL4RVyXBnuI96OEUnSfvMTHkJxrLmJgvM gaTP7aW8jbI4MW3Zpv4O1l0RRdczMbEjEcUr+4RfU4CxNy5S5of2Kop8iaGV/XmMAWLqhZjc47sZ 8+pSmFgXY2Z1kXkbphdJuVFvoLx26sNQ8SUe9/NL6x7vLNJp/ueG7Hv3kWG3gldeumZ/QGUoHzos LXVJGiFh0E7VYoNmqgZrzKpms/4TPbbrKccOTAM0LI6IXA0S/WKpKFE3L4mdYh9l6zm/7BiUeXwV ah5SFh487L7gxm65s+jou9WepNZnVpEFZrtTnzQx/GIKI/al8452kCKNZjRFMtWjHSKrVSyZRXxC 4Sj3Q03Louo7q/8BKu5I/0njS962JDR5SX3wTsgBw8KlZro6u4uvPeEuni1MyrbmTF/bgnsy7aby jcpNeeCp5GVpJxeDS7ErMczHHLHcGOEq4VLllUrMVzoqcyuJPh8+zr+aj1/Jfzsf5/s1xoS+AD4u uFqAXyl4uwAXsBAuDy7lXcnDfJ4jLzePcLlwiana+FxHbm4u0bvgY9dVF37F9bYLu+QcnPCx86oT v+J824mdLISKqD+T9LqcBKgsqoCKCIzpvkDHg1hAQzSh5sLC6qxmle2QDets8ab41jgujIM9Dqo4 /PVSHP4lDmfj5+P4mTgcjMP9cRiIw8o4pBiAM55HU3CfxuF8/GL8UpycjsPxOEyOL4730IwOxflQ HJxx4OJwJQ7vxn8Xx+fjcCh+Lo53xGFrHJbGoTLeEMd5cbDKYD/7TCnuYpw8Kxf4YBz649AVh2Qc pschFKfYq4BSyN/G4WIcfhqHOGN9XS+cTiyIr4zjBlYFCirXEMtx48e/lXgmfjqOb85ycSY/pYaH Wf0+i5PjcVYBcigOOxjIVjm/vPjkOMZxaxzThvxOaS8+x0AOxjFr79Y4mSjwM1arS3H8U7kzDsnd xapPsyllJdnjoThZczkDNUCLwxILZ3UhNPv34jAUH47jrviO+PE4SSq1bIgTYaInL7AKwPNxOCBX sja+Po79Sta4Ws61M34sjukYSWwoaROltoO0UZfiV+LcIBu8AbnMyjh45TzpOA/HAQvxZLwvPhgf ivPmOGhQRXNfNaBqqK5JTjXbskKFFXx1Mt852aEJBLIXGAVUXl6sKGjLGevMHhUVmcWOLXXL2xXl wg3e5Pp20EToTcEdXxFxS5KIHB65OfJWgC8nzsQKF+m0Z/sP5bIkQtfTCEQoNPsq/7f6ZCWy0/WV qmTnf7NZkz1nQSrUuMXnb13Rkccoxrb0on0tizyNjfUOy8Pp6XsXLcquq41ZH04vvuMOsCnq5soa a77ffovSealGZ+QmT7vhl5XQ7uvKBIJqxz/nPqX8uoFS2Fo0KnmewLBXd1SHnxDgLu8e7xNecpd5 j/kJM8lnXFeCEkluMjxRAnwJaErUqK1QojxYYWGF2t7q9w/5sb/QCMY2VCFUlFZIFcmKoQqVoaKu tO5AHe6jj2N1Q3UX6vg6RnETVDCN1n1Sh811EEN1fgrVWTdcx08R6pJM0Xig7nIdkai7jya7UDdS pyqxdh5TU2Yu6O6stgY6VJ1B4u/IscoKZPpPR2bTaA3IJFpZ1djiNdrO1Mo0LkIl+eVsy0zZJmqH yhJMWVSmurApTqcsw8cxKAPBBo1truUQRYGYFyQ/Cs79Wuvb77Xf1ezrLu44tPZySXlkTcXy++eH rmVR0bP74R/0lxbO7Jl628MrY7X3/nRf36+Xk7/WLqn1pfn85q6x8009MwJjb2DAEJ6zMf0/FfE0 smDLzPo182JGbeXC/qbbHlldo0Lj4yiVns30INY8KtUjiwpl5yBkfAnB+C/PxifrUW4kwzPvp3AC 5fK90HlW7QWbl2kR9UICy9pEK9t6RpJl5epEv+9+39d9pMsHC3wgh5YvXZbAPhjxXfbhn/j+xYeH fMBgnmFQAz5M4TL72Cqf04c/k5MNSnNmNCWe9cEBH6z0sUxJygflvuk+zPnsvpCPVFPASz74Fx+c 98FpH8AxHxz0QZ9v0IdTvi4flli+IPiAU3I8E8xXdsgNOZMSSZbsog/LAT5XdoKWgzt9LDVxZjmz NBaENIxVJxoGEaAIqDE7RWfUSTTOfW43n8X4hCzTPj8/xA/zhEcUAaIRtsOwvJ0t4++/aa2piUbZ RjrFksjEFO+4mQxEbtAABiCrfJa38xPMDlM4M10Pzq+qUOdQkhea3jbZ3yJqfYGgaerknOJYVuFi a9vq/yyZFfPp9bOIiiO1xf6I14iPLNAumVjjsZXyNlo0KE3hm/U0ALdQRvkouoo45nue8swfI0oY mbYS6Tm9XY9rruiB8ckTPDJ3C3Osy/ImXpABbuaVzbfwyvKW3s2qyluZ5U0ZJWTTDZUj0zmmX4Xt 6BfIherOag+jx3m55zWWBI8EEDoZF6V6in+uV7udCqJE22nrsw3aiI32fEX7lVGgU/B8ZCyjVVDH 4mwnlsvs4sD2wMyBhW2L7DnBHHtDLLsyP6ustnf57Kw5vlSV1W2zunOzJ9c4CutYPdzpJvJX2meT yEMvUeZQ1pZ7GGUyUoczKy8LYw403IvjF6QSvSWhArAQp9Ply8lRNOi+HLvPl+OEBdm+7GaX0+5y OcGp8UGOj2UyrrUkfD5XjpbKM7gQSb5AAoWWhtaGtoVISwjcocJQTYjoQ/DXj0NXQ/hI6Nuh10Jk bwgWh4DGh6Tf/2fi4xC8FILnQ7AttDuE20LrQ7guNCeEvaFICL8b+l3osxD5dgiOhuDhENwdApY9 doaA5vqzqyEYZclfC+HnlZjdcsHaEPwtBDTnX4bg9Yn8t2bSRkK1oZYQcYfgXZq3XCl8d2hvCGtZ 7GGa8L3QxyH8WgjOskSHQs+GyMwQTA6BPRQKYVUmHa3TIWlnCAZCO0J4cagnhHEIPg3BxdClED4X +mkI72aRkAx1hnB5aHoITyRfI6c/HfpJCB8PwdczWfSEIBWCphBYQ5NC5SHCheAKK+p3IXw2dD6E n5VBd4RgQWhlqD9EKkMNrB/yQjjESEyyMZH4aQiOh86G8ESWDBLLcHms8kDLrv6M1RDkwneEDoaO h0h/CK6XXU4HhdUAQM5Um1uQkAsPMfRdRGW8ZAjkDGnVLoQA94UGQwdCQ6HhEG8OzQthjd9QapAM xGDIRi6/C0uupKvTRZBLcGGtq84Heh9YS33DPox8fl+pj8yUidYkaUaC90Gjb5Gv27fTx4HTR4KU fhNX0u82C/MNqmxZDGNMjsVV0c62TDYtV7a8NvUzOX6C5YlsinR8JY8S2fR3eJRb1TRf1u3cCF/+ BW4nchOj81bk7+/f7JK1Coz/kWVFLSgST0YCjON6UFQMXmVD51D6Ef/0+WsaPfmTJjmiAbEq0lRb 6vSkn+iEswfTnz0Ky8m6a23z962uxbyKf73Tlde4vCZB+uQdn178qLzjw+Z+FbPHpnPfhS5KNs5h d4QcRK/1aiNaYuJNYHpx/A+Sh1I8HQYrzqIODAtMRlMzYDsAdrKBWSU4E04nNrr3K/o1iekZKe36 UPEm3X3uA25+qhxL/w+4mVKOY8GD1DMsa+jU8+RYjQl0uqcBwIiTBq3WYAZTEjmdiNJZtnddLu9n lstWKpaKjDi9XH4Kb9ERjuy6vhfGBPHlzIZL3k1hxikBBwTkjqwgVZj7ILuqLE8nRvG5sWt0da+r KTNXRN3FJMprjZpdn5dde0dtsOhfTf8AYbQhfbfqUz6FutDXgJPuPFoGjTbg2u3tB9vJY8tAPz8y v3b++vl3z+fXJe9KYtVU51SsidnBo25Vr1OTBoCBfyl2ToWp0/8l92vdXbnmXNAW5xbn6ub+AjkF JzY47zXfC+P3ArpXuPfCvSP3Xr6Xl6R7j92LO+/tuxcfoK6he8m9rK9rWpcnzPeK92JNU+vi1q2t pPVfVutgiQ6MOtA1/6vPd8e/hde9WxUNQ7gqXMVrF8LCdyxcV8c7dL0eragfbVcWaWFUGK0QmCTQ Tlk5RWmhmIXJvDgFWd5uqamoYFYPzGQAsU1hBbWZk2fIGcrDsUorY8O5HKC8HJcxIqhikXlMk1FF I6dQsdxFmFGQvJ/FKdZCJu76/hbkZXa8ZMshGder+NOTtz3y/Orvpn//465p277z7tV9L4Dm1NLq lQ8+efI2g8tq4Il3ZmpZSWJezpQlNaVL2tfU28Vsr9DPa1QcZ/Z5pvW3zyzzLDjyywcHP/jewysq 5n7zyrMdR+5dX5b+rU6rEVS+xuambF9lvqugINTSXOd4MTyrOrDlDbA+uR+4X393e+Ntx367d/UP vrmjvZwz2M3ZjdneeGVwQ9vCfzx4b0lemVcHBI/9yVEeDZsMLouu/Latux5J3PfTXU0z7vz26/9x z45PX+rNjsaD5CRFZSrb57g9t/Xd39g81xkotLJ5R9ASuub+kvOiStSMlsLDkmtbIywu6ynDZX66 6CbKlpStKXuojCtjg66lITiLSgnlTD9gonxYqIAG5bMgI1tiF2vMCSdLJ1ZrjAl/AYVQN08qL1EF ObQokTtJcvsSuewxKXdSbtYuOq2bYpLHl4jFWhIRBC8j4JAdYS1qS7WB1AaVbeBvgzZWtnVpZ2Kw DQbaoLMNzradb8NysHdOKnGsDbg2qOfadrQdbyPHadzFtkttHIs/My2RkN+xOuUdicpvyUaXh+sF YH9baSa/ErMnUROf6SvNgixVsDzKhUky4avWmxNiIpogx/SQ0Cf0M5LJsDAjacvOWLcwVG4X3iwX Ri2uGkYVRssj7R2M6kYiivpN5jhlGsxQm8q9FVRiUSZBJCKbRjD0jigfFIm0M1YO7CrGj1IWtCJQ 7nTcpJurKiGxqrwJLZ2rykVhCJU1A9cRHIPCwk7s4ZKen5wrXJhdTxKTwXn40dgdw/vWH1oedhfH Q9ZoOPsb36hc8Q+t2VMq8rQfBPdOChQ2NacPOoJuk6tm5azWBxYXps9saHNEZ0+umlPmdJbOxg88 86xW9YAlZ8fAtHtW1AbjC0oDtVWVHpU3XDXp9Kxfzts2v1Cl1pLeyIG8zde+XyNZo5Uxd6g2nBWs X4xr7tle3z41J2dqe319R73I9u8Qs0nlH6bSUBjtlwR9EDQac5YZm0iOLQfnMISbwlS4CbXf5ceC v0gqAlQ0WIRrhKIDRVgq6qSeA0VDRcNFI0Vqv+wdLuI8+uYPKQ2Sh5ziZdiUzHV6dDp+vk+wJO1I Hj9ZL8FEB0pk2GAp1IepQ9neONshz/Sj2iLvAss7erJdJvVdH5Z8nM5tXFGbVTW53Bq+vWLP18b2 7oYoAIHi++YOv1l5+z9tKl3V2ZoHl3v2Ls7ltAbNmEuj+TeuJKs4PWQri8WygpH/+OMdrzyY0Fvd ZsRkRNlOlzdRGZGjMqIa5aLn6JwVThEq/I2dnexXoVyIxGLy/mc914jX8SZkRD78G6l4ltgqYq8Y EWtFYhDhc3H4L39LPC++LL4ukidF2CPCNhEY0DqRiC8Cktb/4ePEf4h/E/HPxH8T8fdF2Cc+KZ4U Sbu4QbxHJHNFmCpCRASDmC3iayK8KX4gjorkRyIwMPywCLeLXxNxO4ObLeJiEfSil+ZGQX8l/qeI XxfhpPgDET8lglxexw+GE9likThVJEYRPhavivgH4hvi+yJ5SvyOiL8m7hMxqx1mTWhhjaDlXhXh jyL8L/FXIn5ZhCfEEyJeL94t7hXJMhGmiLNEzAqNiOQwLUOSfnPw8cQJ8fsi3iseFfFdIrSIbeJ6 kdCWeMQwAwaa43+K8J4I3xf/l4ifF2G3eEQp+C6RZIrOFkEnwt+Ugv9TJEdF1pFknwiIlY7rxDli u0iiIhhFn4jXjLP2wC9FyPT3PeLD4lMi6aUtH1zanqDNHRXHRPyhCCwai8NzFyRYzbBWdIuYlnNe vCheEsmz4jkRf12EHSKsFPtFXCk2iCmRqESnmCeS6ousJyled5dWJgZE6BGBReM8cbKIrSIAEmFE vCxilhseYtkcFI+LJClSeidr0MllEV4QXxHxARHMoihGRWLa6UQ72ea93vsoMVtES9Qyz9Jr4alU zgy2lE386KjMV3Yo7KbCwUZuZjgjE4L1LVq7L7GokS8p+vr7I7cyrzelitxIwwxvVNdNBZ38hEfe c8frqsOOkFeYEg5Xp59k7mxByA45wtXciXCt7JpC42SXDIfkuSbvRchzLSsz107SCOP3MHCVOV6D MtEonLxe8ndQuEl0KqpRATog868xrgNv5u+gHGJcCuvtXnvETvTYiyOY9mO93IvbLfstKo1F4gV+ UL/fjERG9mh/et6k3ep5QzGAawdGSyoUm7eqChOB1Mz1VNiZpS2oaczLbaop0M7Cwab1XEfRnJ6a 3MpJgjCpMremZ06RYgdRO36N3yLbiuShO6XUFjdssYHe5DWtN5F2soHgGjKTYD3xEqz1YtDSfwQm 1Iac4HIWoAKolwrAXwB9BccKRgqIujUZHAniYKhD1ZlHgh2GTi/TyDGVnGxKtCmziTTKan/Dck/R uCmNgAxfBjJjFlHUb9zxBUf+befZnKZZLaHt3x2oGvvrt8D4o9WpE+mxF2p23b8l/+TJk/i5g/+6 r+Hq3RgTaHns16Sw6RvXvnc8/c+tgEHRrTEamZ7N7KXoeJjlcctGp2k/6M9BRWmBTqaPinxRTzvn BP8MCsALklGrcqsKVURDV5mxIJtDy/96NbE3CJXBhmBXkOwIXgxeCl4Jcn1BsNOgFA3k2GMgeFaO UOmD3iB+43IQzsugRE7L4snxibQKPHPychG6oTMJOdmTstdw+GjiaBAGgjto77KAst0PJ54PAku2 I0i8QdpdcCUILweB5SMHRYKYBq5nAAeDRE51oHtNomUC9vngy0F8MAiRYBuDtAcxC3k9SJibNWMg yE+5GoSztI74WBBCQdbgATk7lRAEjILgD5YGk8HB4IHgEB34y0GNEPRT73CQyzIas5sJCggBf2Aw wGkC2YGk6ECeJHGbrUltB+XmTFq4bvCpmJpTqlE+Wh4tb990QwN3farfsDqIyDNbPgMxASKHsE04 WzBW9QWjKxP2AbN5lhVbv3nmmcj8LTOLm7LLioW87GCRR/f556+nub1kSVn+9HXf3FCt17x5t04v TutqejJ17bNAcXFAmSsrSROpovKUC0Uxlsb1ZTB2vuxi2aUyQkWryrIdZVgoA64MrpTBy2Wvl+Hj ZdBZ1lc2WEbsZaGyyjLycRlcLIO7y6ChLFXWVUb0Zd4y/CbL4UoZeb4MDpRBV9kAzYjUloGf5WUv w6+XwdkyWF92d9neMiKVAcsJXy2DgzQZ7isDlhP2ygU/RQs4XsbqRO5mNaIRerk6R8tYhciNzFmF 8HtlH5fht8tgqAx2lB0sO15G2ljVQK7WuqtKZc7KLeS9ZbVlWGnb86xtoTLp66yAg2Ucy+ZqGTlI Qc+XkfVK67CcyRSWL6sPV1vWUtamdARt0cesc86WYdYqnAGHq6x3aJtoRwwqZeMIK9VcJpZhLDyu Pax68gKdmgWPBw7nPGnOErNwVs5TPh8fiES0tudUT/EcJTWXqDxdYamQDcgvjY6+zx4dX7BwuY5I Ny8eX9pQ+rJ65GYQuqhUykbozCCdioXympL75SCsulmjWUmFt6z0si8Fkd8zLad7rm9htc1ls3py sydXOwqn5n9lKMPFxaSBRPgFDBdRUqI4dqAMBw77nsx6fKQACgTtYf5J9Ph24WnhE4EgATQC7SQb 6y2mmdXamKH1FSpUjFpoX7FZ1z52aVR4nz3bFTvVLyhm+a/Q1e76gq62wAXHv6S+5Ya+Un+b/3e0 uqxtAUqjh8irKIBK0QGpe210WxSrfLDDctCCVRbYoT+ox0QPGhWAdlLCVC6VAyofLMc11JEs7ys/ UH6h/HI5rzjIvHKIOLnsZoUSXWCUKJCdzPGWJG3OcP58Tisgxa5GoUEZKsQOhrRPsPfy4YMMVtgy hviZ/SAmcOUQX8aARjlSlOH7D68HDXbUTJ+Vt2TfyorKNU+trdhUwU4LHE9Ld+CuSdOW15ZuyAv3 VOy4k/S4i6usPochfvd3t25+6YEmvd4gBrK16axoNIvM7TnQFrYIYxaN9r2MfafqN3TNzkLflvyQ ZbAkUJbeknAhysQZjZosk6u11MpMMInV42FU32FzJeZ5YJPhPsMjBjLDsNCwykAMTEU2mcpIBrpg LuvUDGqw5n7j143YYMw2YqMKW7IIpdIGPSFWF9F0IDAD5QU1DlBZmbn38naLvC8r785aa5jCkh1e KGf7aRGKSqPsmGJdtKKC7bFFAkG4samphRunEsnyYNpxNl118iQcgrPwPgyePDk2cpa77+rbE+eI rnHk2sS5RK5MWZ+LEeKfYecv4RFp+novzPPCIjvMskPSCJVGmKl6SYW7vRD2TPHM8pCX3fByFsxy gM0OYdsUG9YLXgHrzV4zDpummDDtixelUwZjosIAuQZI6iGmb9TjpA44bGe7CHbacLvB4VV7kA0Z DQ6V2sObeDt1GbzUrTbBAhrRyZvsPG9SwwKHwdHqUds9NGa97W4bttnsRq+KU3s6HOBl9l5gcPhE X4cPm331vnm+7b4XfJ/4VB/6xpn2WPL1+YZ8XK3kA79v0HfAR5CvUz4mOuy74BvxqQ0H1cfVWP3i +ENSyGxJLGT7oIjnsw0mG1F3eFV2I0cELUEOD+E7sthJLmWoFLsxC1RE2dmgSLsiwDIF2hsMvcst rhpmN7brZg2vsGt4WPkyE7LrhmQTZDNyg/dGmbeygaS92ZL/uokZ1D2bnnUQfpa++3FceAKcUPUs fO9gehe8eXjsX0+kj8mHx/ByLLHjY+mVIB8jS+vGlsjhGpk+pMb/yG+WbbXy0e3SnKW5a3Px4kBP AKu8i709XqJ1LXWtdRGdGnRG4AnwFtDr2lAOuHKYLXy9v1AqxKit1C7Zsdku2qN2Yuc7gjZzh5vL HDltbx/dlOFUbzlvquhKJhQl6kork+lzwOqwYxNlNEooq5kb7jl5//0nV4fDq9m7J/zz25698o0j fz7R2nriz0eOfHqiFR/b99tjt9127Lf79o48lUo9NbL3NODnksnn0unTp9NXTyxceAJ4xptTHF9I cdxNefN/lNbpbHts+Dh3lsPySdsHLYcseE0uPJENa7IfysbMwBZr3FkU+exue1arw25njoC51AEO h6fVXCAUgFTQV3ChgASgNakClR11RgO9ARwIqMROdYeW0LndkcXJ6MLOxbGDWO2KEFfezg5WUqSx WGtqdkUE9ONdfEQ4fxMioPabZvjEbjkbde1Ne+vw3Otj7zx9Es94+If9pcWzuybD+kfSr9Dh1+XN 3976/Kll986dhGenuYmpX96+Y+GcbcvqhLE/eGN4NtyTvH169tj/CDRvpP1jp/3zIp+gnLwV/YeU oEuDxWQWzForWI0GFSwwCIZWtcquVqt4WEAjOjneznG8VwDBT4mmIHBPq0E2Da1QA1Hb7Xa4ZAc7 0/uVLkmwt2SOlCQu0Mnfab9gv0zRhMX5Q3LcGU+OApMn2BIddpjMAWc0dVrNtBoU4YQWAWsEFc8Z 1Jy5QweZTi2XKSfrV0U6ZpaY7R2b5EPcbzA+Rd5n2XTrJoswPAztbA4CXZxz5XlUocwnEiBAR/PN dPNheO1H8N6JsdfO7hy7vAv2/g5+EWOd+NerGtaZ8ED6Hm7N2JaJ8wGFFK886DfSLGaVHTMShyHX EDMQt6PRsciBicPlAj1dYvXZA9k7sg9mk85saMhOZeNL2XAhG1I0+Gz2+WxOyoZQdmU2HsqGbFlp Fm9MoGwh259Najma7ng2kcNrq6YkhrOBwdkZ7o2osKreCU4n6rSXusHtjto77L20g+0qW6cWGcBg YPhI0ZHLWCxnTl+wLRR2qDGqLDebaNf1L5/YoGfq0rfYDkC0ooOuTkzCvAknJ8yQA1UV1AnPfTj2 46dPkj9N9/vblqdc78Fesa5OxK1jn00gX/qVX3IqAmM/P5bueob2G6Z050fkJLLDB5KwHgP2FxYn 1gl3CU8IzCz1D5LLZEm08G08Xsn38/fz5Bn+NP8TnvBsB3oLhX2Yf4rH6/i7eLyEB5JnBzcuxDPx Usw5TXmmJtNiE8cO2+XpiFOdp8aUvxGUnWqzYDebBbaFZTZlznoZYQFHuBaD0W4wGmCBntc3qwx2 lcpAMc5kJBjMk81gZlp2Ha2V2uwyYw1b5k5nz5RXO71l5oABFhm6DWz1e05aapxJFz+VwWnAWgMx m4mBqATkDDkbnCknEZzAOeGs84oTH3NCg3PAucN50MmVOiHkhJSzi3qOOznkhJqU8xKFIpIT8KAT LtAxZnOlsCgh77lFvWLiFSf0OQedx5ykwwl+J+iRSqDoYCQmpBdoDyStGjNgzmDm2eEbV4W8dtEF iw54ubziXD8TcmPQ2cpVF2XbP+2yTQNDCUtFhfKvzKKLu7Ju3re8fvxMoV4Tp0si7ZFNWgjqJw6i eaFC2brkF6dfnfuHj2alX+6FV5788N9Tv33nCehh59Hw7WMHM2fSduLuscfxffIuJVCqhMjvKb54 4UfSpK32Q3bMe3d68TrPXZ4n6MLsAdm8Urao3GJjR21GzmgyFu1G6tAZ9xjpWIBGm4nRsJhSZsHJ khD28NqQysRTBsRO2RITz9gR6rKpqNvUaIOdNrAxxNyXV5iYxcMeinV8FnU7YAFN02Jw2A0GByWO NEkzZWdMJt4xywMej53ma6QZ8/L+ig75fNKKrgQz6MGKCVCXb4fvuI9Z5lzyaRVDnwY56CwNvOS7 4tPVsNBK34DvoByqrqSPizSCky/B8AUUE59Ks4uZ+GCB8jzYtpLpBNSI0m2/gWgMNsq+mJIqo9fO 6VyCGfFqYkgSneNWbiZz0nnTxF0YbD8wwviZcrZUsS+NvJWlgUgHs8zb9HdYG+VAIsOzSERe2BSG Rg838zUKVtB1Y9vG9OJ7fpm+L/3PGyCWvtwLJ+757oX7YMHt6b9OdxQXu2BO+hR9C3AYHmFIkv4U BPp2pE8wHFlMloGX0mICJ15CPLsC4+p44iJ/ib/Ck5/wwMuWCp9+lljM9/CY+c788ZMEM7g58/uP 5bek++1HiS4eFivA33v/wwRd7t5j7nPv/iqhBA+f+fk7CrTh9bcTlXwDjycp8GeGz2eyefmVxAAP 7yrw0sLvvpQ4z8Oz/DkeH+RhLQ+T+SYes7sKMM3/H2sonHT0Gwleeuxw4nf8Zzxey2/jsZZ38y/x r/FcHy9tvz9Bc9vNH+G/zZOtmXx1K7tZvueU0s8tbk30ZGo4f5FSEVPLvESIB8xbeSwpdaytl6PO TZ6SuJDJx1BaSd0j/GWeYDm5GFKSu92+hJl/gX+FJxo4UorYfTeUcmJEUP2b8qJBaUOELRv0mRll RVvM7C42RW5opjP2YPQrkxO2UjNVdaSs1FZBgotfjc/i69JMKfvM+L/Do+THMj/6zPcqCxsKU4VE PmVpnNGUQIVCIZ56sRBYyDl2skFxSjnFpYmRQjhbeL7wYiEpLaR1pKD+QnKscKgQyyBWo5Cwo0M5 fbpB3QEdGdKBjrU1kJfQyaut05t4mp3eAo3OfTQoZI5tKQe3WMv65Z1FWfUe6VcWyi8f5rJ88XDX ozZ/0Y3DXcr7Fv8XD3vhX9yIlSMUGc1F+bNHKW7b0WFpLRFsQlAgmrV0jrNzN62ZczeoVa3WmJFd sPspP87p7U66itQnnZ1OLDhL6YsuJcw36DzgHHJedqqN2zX7NU+zo8ig0RjNdiqaqpGJcBbdTezC TbQhI+RkDiFHR2uUEzEgKwsn2INbZBXS9M7YY++kCx/HVWfhPth4As4+ioW0JPNR38eX5NtyHsPr lRsuMHqPjv+btJ022uJT0r7J7ib3T93vujmnO8/9rPucmzsn+8lB93E3vt8NkHR3uvvcJOSudDew w1uCG9dcdsNF9yV2CAEY3Fk36ZQtTQgnQ6Xc3AXlTFjK3SXHn3fzkptSTuVkGDtUxs4vcI4jdoox OgdxKtgw9lY9RJmmR0GDG+qsDtkM5cvoQChyw5tfPN/3u1/Fl39x2LmfXUsg5Ywuv4vKY4XoQ6lk Gw/bdKCyOC15liYLl5sNvNfhzfWSXCfwLocr10W0RGuGsNkcbEXyjDWYEyiSF2mK9ES2RrjPIvAv EYDhCMgHLJdMa0gkI8BFQpHKSEOEq+EioDgPRs5GzkcuRa5ENEKEMmMRKdIZ6YuMRHh3W6lG0mD6 1Sc0haEOc56Y93QeycvLsXfoBUHP5XQQeaLI1wxkZJxI+yjbg1d235m9lfDrSOaegY4JkpArC3k4 JqDAVx56Vq5C4bmBzw88PX62E1bAovs/XjfD2/jj9Vu+d++MuTtfWFG2YtF020n45IGmvMrbnr/2 T9AJ7f7s9MizZbFpXx99/ju/3zPFaM/Swz2eyZM9ij5sO1mGX2VrBFKjd6SHntWe0+Kl2rVa3KIF Tgvvan+n/Yz2qTQ/lXBq87STteQ/tPBTLQxooUcLC7QAfm2pVtISTmvX4ikXtHBWe16LB7UHtLhS 26Ud0BJBzmlAe1x7VntJe0XLJ7UQ0lZqG7TkohZkSNyp7dPiem2HFlNoOCKPHeN4EX8EcQLn54iG UzNSyzFaW/5mu6JIez8y2j5hs38d+xSNLLPKph+65DKco1+MKFVNT8+QVvgNJa8Uv1ZSeWUzbb8D XC8hHWVhTTN1jIUNaXWJfXrQF2jNCStllPF+CizpzAlitVmxQZWtwlo9472ztZaEDqYANhFgx8Kh Ta/z6rCg09lcLnnNodxNnwtSrgHXcRdhQWdaOxJyVOGiJQnkorTZ5XeVupIuruaAa4QZ//W5DriG XMPUo0pSD5ZTSQk5FeN35dR5Nm+i3kVJIejb0KCspnEifYfDanVYdUAlHSqFq7QkswsyYSfGztpT ryIcMoxUBMQIC5c1EpGMwR1iyxKFqoKJs5aKsZh8IHolvvz5AydzxUbyyJgeJk27b+MCa22T95pu ObfboPkF1C2+ukGt13OA0ntlPFuXfhWelNexCNok6SgV0YV8h+2Py0eiJmksCTcKXQhhTWiwGFAx 1A8WHyjGx4qHii8UExpULBvY2F0Jz1Pu53p92337fcTXmd+XP5hP8vmjZnamI2MCrLSKXXfCLIGZ tv7LlyPYvkLj/KWVSRuYuWVh22J7TijH3liZHcvPIokvrEXXLnylqnl8HEUo3XpSdbc1jzIJ8h4u 7IcNyCUZMQT5PAxosl8gyk6uYjbB7LRZGoqLIjoiRdYAxLSNWhzTNGrwFOMsI9Zkg56IyziVXUUR MMAFoL4y0BDA7HazM+FoQr7lrNofSvgDwAXsAXw5AJhdgjYUGA6MBHhHqwnxdmLuwBbS7LnNgz2d GiaGa+g801OSFWFHGDK3bFByJTMsNxRVGTqlrGLysu4PxTJ3wE2orrhdZ+G1kyUDrz2R/kv6/2D3 NeUv2tW59tCKYu5PbEG79uGy7zy44L8+IJWy770FuzorK5c/OJ+t5+O/4Ydo200gSc8266FLN6Db oSNNHNzF7eGwlu0UbyO7Ce4mMIMAgQUGvWEZJnaMiV6nXaBr5Tk7lSk4ulKTAT3T45MePXB6duFC Ss/p9bzhaQzb8G5KbDBk4WqMdWzPWRCFDgGbhXphnrBdeEH4RFB9KIwLlLGThD5hSOBqj9HnsED8 wqBwgG14XBBGhMsCx240OVMUTchvwS6/JbPelND1Uj6Sd1CW2izbzIcKZJv5c05fInMYVbIYaZcT rDMQvsOkJhxbMRRZ1FrD5hydpZS3mJihTIf6ltL9sqksfVe0y5In5TVuETY3sdNAQCWHm6464Yce HfuoYuzDx3HOWTgEj9Fejnk+/zNvlMcgl7znidH+b6Xy5H66zk5C26VFuTnAux9zU6Hemm2dap1t 5XbTRZUDux1rez2TJnlCKCSFsBTqDB0LjYQ4BQ1LsYQx1roC+9n1DYIVW62Gzbtc4FLhwFZQrkNs Z7oWpudjlmlsHZTvX6Ksk2JvwDZCCiEW52PKYSVGdiYsmzh1gOy/9nr3t3d1zwhsfTCndnLUGpw+ +9HF738QSQ4cPNWFTz+6/LH7tg4ebL//Ia3ZpjsO2Or+3rcW7Lvvngcfb5u4a5BfgIwogFZ8VxT0 ZnZY+rJUR5mExY4eB7YI1HWHgTEZd6rgDgKmXhREQSmIpWBn8FhwJMhl9UqaA5pjGqKxbdarfZt5 94RWd5St6qNML6TQTVDUtjRTa0W5lXzpCsHY7c9uYpcIXnz/RXftqpmzOiY7HJM7Zs1cVevGx59L XzvVBl2QgjmwIv2P6RcO/Pbo/PlHf3vgwEdPL1r09EcyvcDjv1HvZjwwfls6rTaDywR3G2GJESJG WMNTHAceQEOoDK436FtVvF2l4hXVzjKm2jEYFaVPq6L0AVggmIVlCOw07wcNoDbkG6oMdxg47W3m 1WY82dxkxkzVk28mugklDnK+5oSXnfBtJxx1wm4n5DkXO7c6ybvO3znxWed5J35WDr7bCT1MlwNN TtA63c5CJ/mtrLO5/Ze/TjD1Dn7QCQuYwqfS2eAkTidgJ3zqhEtOeNcJx50sK7LNuduJaQaFTLeX R4t50HnOyWudcOI/nH9zYqf0T88lXne+x1xPPJWgRa5l5S124jznZApJZGXRgUcVZVHurr0JuxNU TvjMCRedwHL7qZMsdUILC3XSJKRfTrG+N6Ne6lmbeMkJ9zsB+pzQxVJdcuK9zqPO552kT9FUYckJ didrhVyaVERltL1OYFIG5mgorrnC+ut15rM7DzqJ3TkgN+6ik5cTxOgS53VGnC1OoiJSsCARJfVk HiFeAkZK2CRDVqKQvo1Gk0nQI1WHVUPMBoMszlHgzCECuwEw+5e5D1NWotLQYMAGjqIDIzP00x6R pbaJS+rKoxXRCtnQP0LxODKxix2ZMITqYILq9Y3riAygiHy33uPwJSMq4ac3VGdsan/BvP+L2rLr rDC7q+mm65oqMrKTPT0rlj6ePhpLN2yh3BzUw9piWAalP4cfcH/6/M/kyWtdGao2jzxzbTk55WEr q7yu4k/lPc1vSdk2jc6YQFpBizUajs4OCGgwaADCWa0q1mHLKAlQecwe0TPPs92z38OLnqjnbc+4 hzNTx37P054XPB96VFPrPb2eVzyfeLhXaCz2SAsXJ455YLsH/B7o8ADygOB2dhpFa5QRQqONRx2Y KPIj479A+KncS5EJI/OIshkk/0eur7Jc5sQ72/SNwRMnMXd4UvXMuXMD09bmTs+xNYX3ZVbWn7Tt 6ZpRIAimK3tdnh8p/MRKSu+GKE2fiobOPFgFlUzFt5mKLRG/1pjYZwUde/MENLVTWqbgKd4HYxDr 9Xd4e714u3+/Hxd5/X5vEdE6ereiByn9jKO4xM7hssO6I3Euw/hrp3g3Z2eXCygiRHAkkru5XC1s 5plWAZt1oNMxCpm55Sizx0PlZLY7QcllOzNSjsoWy6Ptlpp25WpNZnKc2f4mN125hqMQq4rDxAaZ vDaQjNUrszkekrad2rTq+y366cXWKTOac9rvaPQUzVldu3//ptu9U9pn5NRVl9IVI9g0O1X2i/cm JXpnnzsJG9r2r6rMsoHnBzq7WVuycHPD3NX1PqJZoFUN3j9theTPrCRaQa9+5rn6DakaveNbtG9n wyHKR0SpNLJCsmO+lIcGfoDfwR/nz/L8wYwiKWtxW2KQp/w9DzXD/GUeS3wfPygr7YfP1EqKUkkf zE9s5wGhl+AH8r04GU2jfGiwn91FZKPIMBvb4dCRI/K43iGPax0qQtuksp0YzGwcVRrgiYPkEqLJ yyvw9G7lH6QcSAkqkUqwVNJZcqxkpIQr6Aua5MOONIFpkrgZIUf+1pDKsVnXZx40Y7MZzGbdTePF xoqJr++OKqNlZQu1LMTCTTYKtwwSs1FgskKADg581HdyoLZm65lty789mw1LxVRJHhZv4p6Vta2+ Tvzc2GlrcVUjEYqXP9Ld8cTGqQ5nZiiii++cOXdgbr6gwUeOpFOcRs1n9AHcRxSnI2iN5OjOBocv 19ftI46s3KzuLJLrYuev5Mtb2CUuUj51CEJesVQMnrZSXqI9wuR23tGhQ2wrTcfl5YkdyCZfDZWZ mLKwrtxIJqto2/lJoRKKddbJIdnA3fZFyZydnjERojqeHj+1rP0U4Gcb7+rtiqqm5zS91MlE8+lf O9Mf37Rijid3mip8+10P2pf989VvnAXNd1Jak1WXfu+fI1HpkdHvHP7NY7OE7Fz7z9KvGlxWnTKH z5IG+IjZ4sB06S96t9eNrx13M2UOaXOvd2O7myl6yPPu99w45d7hPugmMtB5CoNb3G1uzLntbvz6 3e7X2b1AvW5cK18wNO4Gt3TupcQLbhiQryLCSeWWIcwOI112k6MXblwEVO+mtAz8bviE3Q90wY3l Y0udbrxmiN2ABEl2dxJclm9HYsmxcnVRrxskd9KNaXGVIzeBHJBvHSqVK3FBucsIS25QzIrMlBvv pYw4xwk3WxMxaZ/ZD90wlPqyndWE9dQmRSd5PWLCLusrbY/goy8ZGv0dq6KMTStCXEA+xx5Ax6V7 jlvOWjAvwk7PYx7Mu3dSnlmHPRibdFlM89SaHTQHo8He4Pbg/iAfDdYH51HP08FXgh8G1eZgB/W8 TZ3jQVU1C8IMeDuN5cxBkQJvp6AvBFUatak1aQObptNotPCd9g4nMdk6LJnNS/meAHnDcvn1E0tM jM9YFd28Qf6lPfQgaQ3OG1y+cs3y7XP86bnvjL3+9En4nO2fR3u/v4cMJQdaQmM7i1N3pZ9PT5/Y uqxbf2DhgsMDTdfvKj/N7AhgmpRkchduIClyiZAqTbPmNg3RAeRmgUYNC7RY3coRO8eRu1x7XE+4 iAsTjZZdH4e1dBwIk8Y0hIpzNBHH2TnKsTBSVWW2JjjvcS8c8ELK2+Xd4SW1XuC8cNkLZ72XvPio Fyq9DTRmwMtd8MJBCnveS+RbkJZOrU/4GbDdi2sOshuWJC/Gfm8pffd5B+WblEa8l73apPeY9wJ1 ck5da9I8Qimhg9ZO6Nji3On8yEm2aHdqsVNrdFtp1cwdauOEFUOFtaamvV2WmOUTG8rWYSRzXZV8 xOYNOhDKIsdIOh20mhphFz88bIGK9l1CRKMYOiiydcaU5ea7kigXwGS4mUfTk3HdI+kXx/783eGx Xyg3rd+/k4lyaWlskjeGn30kXXvjcuSxh/CdVK7DaN34v5MaSi9FVIF/LI2vszxB8ZVZKPgPbQ/v Dz8dJmERhSnzb9McYcplisQOd66bDoI7djUG/xGD9yhXIP3tWmJ97O7Y3hipic2MYW8sEsNaFv23 GKYAr8XgZQb2+/+kYLA0BrWxlhgujoE3BsYYfEyzwm/GPojh2OC/vZfYELuHuX7+ToLGXYgNvvF2 4oexN2P4+RgciQErBbfHNsTwTJrl4Cs/SYzJ9Xg59nrsvRh5KvadGN4W2x3DbbH1MTyHlQWFDPLk UILW42js+djLMfJwDGB7DGSY2OCxf0zoY/D0h9IbsU9i4zHyegxeicHzLNXBwwm5slG5suYYjLP6 wtuxD1mFXo7hp2OwNwa9se2sRKiPzaMZSvfel/iQZoWVjPbGWKmElkdb35FpvRiLxjAttVduvZxf TOpem+iNQSRWG2uLEXNMjOFMs15g3Ud5yHkx0MfocI5PtOTjGLcjBn0xSMW6Yrg0BqEYoJgQw/GY rASsrktciMH5GAzFKKNBI/wxKcYh+krG+mJDseHYSEwtgxZGy2ml4UAM5KqhGGhKbWCmhEV8CmMn ih7NtVksxqecnLIcjr2VoSwKIYkoZtM3mHz5cIUsCtx8SOLW88IRhQhHMpvgXzhBoWx+RSbEhcjN qYRfM3GAEbeKijfLo7Jmsh2CpCpObrldPcMAmsH2xa2mF5Oe/aGpRVnu6mUzpq4KBqc3PZy6eDHQ cudtNXO+qOuD5TDXpw7OWDtnZo/ky3YcT9uyTj7XtH11i9U49vlX3D/Ymp6N1/APIxdqlLLyHVBu n27Hd5rhTj3IW6D5PNjU8j6azpRQo0/3G8HIWA9KOjReVF8vsxlvRMoVfYFs/sW5HCVYPj8K8t3Z Xo2reNbtLQ+++oAkPfDqg5t2NNrgT6lvPf3YA5siqeZvvQfZP/wheH/1bHNq2ksffEbrNJ3WKSnX aY4Uq6UyZJuT1AotQptAGl2LXHiWudWMiRFJtErI9mlSQxFGvt9C0nAajQkhpWKMTo3JVUMd8s3H Nlkhww5e52DFGm16y+2zil0aW+OOTTt/yqr30/TsVGTTA489/a3UvZ998NK0VPOzv0p/9MMfpi+9 9y153SxAiIzwDUiHTOg+STBUO32JmKpRtUhFFqtAxdQwVpuHMmtJASdlxdtlgTMyHq7M6U0YOcnu TnA6nQY2mlQIC9iPJZzEffgYHqKCHNbwpi2IENCrVUzTxAhzlFFoZQOfOqLRSEWE/QYHfSC6HlIW NQYVlgoHFTMDJHxy7ATev/lc+ht82g8fQX76l5C/kxy+1r+flI+1K3ekML7TmodmKmc74DvK2Y7O yiI+L3O2g8Ex+0FZ71uW0fvuhQ3IfY7gCJ/HDstdOxsvsOfcpPklTC+lslMerwLNQAvwEin4wKxH Z+HdOdDdvKUZd0/bMg3PmtI6BeunwBQ/ZSvaaqAsY7ZRzGS6bopXtZNgoZsKsXdl4btc0GWFASPo 9V49lncjNLzKocI6klUzJZcLuxJ2m4qfydkbEmGUmGvSrtdCeK5WOzdM/AaO3UKX2pGCzlRfClem GlKpFPGnICUb+/75r4nnUzCYgq7UQAonU3A+ExP56OPEsdRQCu9IHUzhvhSwdF0pUpoCLmVPhVLk Xy+mLqXwyxl450/fTgylhlP4YOp4CtMML6WupLAcZXnxR4mXU6+nMEt4PEW+JYe6TryQGE5dSOFQ ilWKnE9dpCmIHLf8qWdoZoCFlD8lpZKpztRg6kDqWEqDUqU0gNyBqPdCaiTFMYhSCsGKvpxSo5Qg QyQp8EhKLflpm1krRlK8koAMK/U9c++OhPzu2yK/pdKV3QlzCpL1UJ/Q+nf7j/iJxm/SJvV6V1aN TTUll5+p8SWTUa4y6XPalRuc5QO6rpqMULW8fXRT+42rFZezPdSIctTk+hHdW+6IUY7sysYnitBs qWBn1i3svC59sOkq36CcMZeFdhSJQHsk41auEFYDJS4yW2EiahEyt8jlTZzjnSCd8iF05fwuoV8X o7mU4pIPatrvjMOzJZPJP8Brew3BaF3BpX9KP/d8fnv/7oV//Vu8c0tV9uSIp7D1H7pX7l6Ul75H 2tDa4k8bc5urgyWLti3LKa7KqkhN8Z9bu4yrnbVmTnVWenD5SynGt4RXb76r9oI7djQolWb/+Hvt 9y2pdnhnzO+srl8/tyjS0nP1jaxwlR9eE6KJnsTsTS25HJp8W0Ol1RaJL50+3Dlhe3gP5UUDaFBa yPscPsxrHJotGtKh6lVtVxGryqpyiUEpmAz2ydpc3uxqTcIIYKhn0qCz01xqB7vdbOZcnYGcHOgI WE2dHGJba7iDIzcuEK5QlNa3mAtSmVG+JUA+fFYPX7YKDFgm7loI1J682ThwnShJYvoQaOIbl9Sb a6bbrv78ViPBK8xIcOwDQj1/TX/jOt99WLYLOCZFs9RL1LhKDVZYoNaoW21Wu82qti2Tbd8MKgdy QL3kAL8DjjlGHOx6059JNRohYdVolyVNYGK9hAniNcTcYcUWojV1vGODB2yA2fU6eL4NZtgg1xaz YZvaINvnZ6zaRjMW+h1KD5RHrp/BGyvfJRtDyQckFTb2ZiN94B5gO0Urrr2asc7HpxU91lUrd+7q E9eN80WZpsq/aaJ6gtJUtUxTbxsfh7nIKunBwucBchpUenZHVYTtY3zMbYbzsv32T6SI3lHraHOs dxx18F7qbHHc7Xje8brjPYf6Ywccd5x14AMOGHDscGAHs4Uyxqcl2GUfmHZYrXxdqnXylMTwDVC7 A+RgT1FZgsLgPsegA/sdSUcndYw4LjtULPpMsCAhg+k9vgR6MKnr1GHZtEacJJvWfM+ZndCxqzJl bQ8lAKOZa0UndKiR9oz5xBe3LeH8F29y/9Ltlqy/dqdns99loP1lyJxDfB9lbvT649mGqahMvtFL /t0AXMM30RVo9kvU8wcp3+tnl5owCTaMv4//E3+OVVqcRUMRD1M7+WM8ltje24vjQ9+jiw/bjbcp vEyUXSsjC52bIq4gVHR1wb+utPOt8to/ffyP5CQdkwJUjY5KG6qYaLw7H54QIaeAOmtzgKm88Trj XcYnjESX58kL55HKQK9uijAlOQUnp/RNGZpyeQpX1Ivs9l60nR3jqawsG9CGdoeOhEgoVJi92cKu 5apnWwcWd+FmFf8gf4gnGl6N6imdrb9u4MsO2MtXpQjKdk155h4P2QbLpnQzs7i/oXhVDr8qthkg X7EuX51N2aHpU/uOdfU/uyGW37Ri4IHGJfsbpgVt0YqYu2lbaxU//YmlqX3dVXD6vm2B+rba6Tvi 2VNXkuOrn15flfxWOn3qvtef2NAgWix/OKA16fnaHb84nFta0X0Ivn/m2wv6m/3Z7kc/fKxF0Tks of33P2j/5aHJ6KTUcn+I0qiQPWXvsg/Y+crsruyBbBKLPRbDHJF/4yaUuyOX09De+pDy9pJRSNhs D9LhrkbVUjWWqjurj1WPVHNiea+OsV1FdAhKdRLFUZGySQMPToJJk/I9mzNmU4SSQ3X+5od42MYD U+W2f0V3RpjsK7zVXh6NbLrxaypo4tJ6UJjaiUOTRD7eIB9ukFcaea9PpWZrzf+IrTnStfE7d9Qv 3HtuZcsT8elBK2X/Xc2bFkQ5ynikdi0vT6+Ulkx2re5reGyW2LAGjq15pm/K4ufR+IlzoDqRtJt/ v1snGNQNey48nFca7fx6uia8aHvq+Nc9WQd+fWSeolPrQa9zIrcT6dFsKaozAW/SwglJZisZUzmI eR3B2MSpeRNSC2pmxc9p1Ij7jpY/Iwv+P2VXMmYJv4MoXXHLPaPll4RLdLbKTGXAUmEJOPCW1ekl 8NxqOIG3pBfDiR44kV7co/B68h6kj/KHjehpqW8XwE4CFmJ/EB2iY91bPrVXtMP99q/bsVAO+8uf Lsf2cnu5Kaf3Qc0hyug2C83JZpxs7msear7czBX07jYdMWFGxi0kuHnatOKqzYoIv9P9mJt3q4s3 a/VufaF+t/6Intfo3cqEkFW5ozWyHj6j21UWr03tm0ZlXXyNbOFuV8mXEqqUn0KrYnrQjCXXF/cz v+jfvb5t8pL6Se/+9t13BzfctqFs5cGuzq+vKt/7xR9MK3SUp+Lx+VGbLTo/Hk+VO8hnG48U2KXb emf8aPiHP975QmHB4d5597WVlbbeNxacuWluQcHcTTNnbZpdUDB7E363dmVzQUHzytqpnQ2hUEOn PL67KFPNbJo0aJ7kRX6tOcGrVKAmOsTQXKL0+JhuRMeBchsvpWN8FqfZKlv4sH+smlCA18hiGtuk Zos9JW822QqGSgyvTSfxsRP34ZaxMxyCujlXBe64PFd74DlOJM/J9lRNUqnKj0txJ5VTODMWMdZg HiE/klAn4hD+ziAlpqrviGowUxZDMghUUGTljdLRkIkUMzCkeEVXTfblxGvN5KVrzdjU0wNP9PTI bfVR7HmWtlWF1kgtGpyFsVrlUmEBaWCuXwNJTafmmGZIM6K5rFHxBIuqqIpxQ5yKiVBJWjUO0yZz EpfkOrlB7gBHozJGVtEKcNNaVLzZ/iZlNcsVCs8uD6tQdudeK4OTq9PPpJ/p4euuJUjhtX/9/7cN y/jl9F85YXw57TzTWYzQ9wEx9Um0rJTQEgTOn/4rGzQeNY1/pOqiNIAgMwqiKJX6vvESKlHuGCzK /DKPKfM2MAEvTB0F7C6jPPbQsIeKPaacDX83VAlQSdjdLkQXOlsq723TqFLhLPddz9k+HXToQCee U3/Pcc7IYS52rvh79efy89nCXR4dvTJaXz96RTmUdmU0GslQgXbhinzpTObD0xUdJojAV/we4n8b 9+JGcrZ3rOub3/7msW8++/Q/PWktmFFWJuWZzXlSWdmMAisXPfbtb37zmWefPn70i1F2vif9yJkf /+jc6R+++L2mDS35+S0bmpp7ZxcWzu4d+9HZH//oe18RkfkNDsoDvUd+idwojB6QWvXmveajZtJd uKUQewi7Z12vAk3ITXn7gLoZ37jBJ1kEyv09x4q4Gzf3JO60PGTB86iQUJAEp6APhcT5JidWJ3lv 5jcP2FXCoxlqmjnYS5eGiZ/ioEthxcQtvJNlZiJv4hoBuG7fKf8YByluWpPedB+nKt7Z+uoPKtd+ 8/aKO2LpSHD6inhWdVW5NbyxYscg+eXn32end4HPuy0cLL36x80v3ddo0Kdzex5pj7DrfPAo+zUO 1g+5lBa+J/+WqIj+SVppE7NVnFV9QiMYDVpOYzlhdXm8mHOSE5w9x8dznOOEs94KGivndHJWDadD 5qx5WTiLXb6bFTDpVFj3HX22Vy96TN8xu2xmsx7MZjr/zHozcViIRj4OKqvF5U1/i3xdWnnmBdFy 4a3IhPjKeIgJ2fVmKZaSOhK0sW8wVkG/AWZvSL8VjiApBBrxXvra3DVz0/9rztq5J4enfA6G2Wta IDZ7zezj52rSKyFWk34dG3rSrfAs+/ZAxWp4PL2WfVen34SKzG9mIbB8/C+NfyvvME/9CxKV37V/ e99H9onfXh9/Nd2k3q1iP9upYZejoEw6dSDdiG6bgJJzuvnTjf+IGjiEGAFA/P9EtdQ9l37t5GGU wCfQLOqO4hrZn6T+Qm4z2s2xoapBERo2l/hQivt3Od0smscu6qaiLsqn8YW4ZvxV6vaqKCy/GNUy WJrHfpYWK+W4aR5V6uVoA3UvYfmy8ilMPUvHwqg7xurFymLh9L2SfhfTuIDah2ppXDH9plj+9G2n 9WNvuiYgK2xCi2lZz1C/i6Z9j8GRBrSd1nElDV9H/ZHM10XhW1nZ6ocRpvWMUPdKmmY2fd9B82b1 PpvJm9VlHfW30u90Gl/A4lnetJ1zWV8wGNZ39Psx6y9aFmvXdLmND6CeTB/vYm7yY+RjdeDQ+GXV CdTE+pHNAvopQl3071ewAP6A78efk31khGvlXuS/pgqrnlNnqU9rGjQ/0Xymc+o+1c825BieML1l ftI8JOwTfmvJs4Vs5+wjzpDzn53ns7qy7szakfUzt+ROeZZ7j2dbs5/xhXIm5RwS88Sf+JcHtk56 KLgu+FloXeg/c5+g8sxb+U35nfm/LvhGoVB4Z8QQeahoctFA0afF60rKS74f3VM2uWyw7K3ykvLp 5csqUeXWyj/GcGxH7HDsjcm3V9mrFlRz1dOr76r+SY1Uk5qimrKn1pnBvB50D11P+hgzgQS6klB5 i9PTXiMyxmbD4uv42XkdV4FCdmbcmHIpfRk3oTTijoybozBfz7h5ZELPZNwqumINZdxqdBd6JePW IDvUZNxaZII5Gbee1qEt4zagEpjI34h64Z8ybhOKYzstHTgt9Q3jBRk3ID+lJoobIxMpz7gJmkyk jJujMFszbh5lk0MZtwrlkNMZtxpdIRcybg0q4M5n3FqUzf0x49ajal6TcRvQMn4ifyP6Nf9kxm1C X1PdNaO3b1v/2tVrBvwFqwr95aWlVf4F3V3+xIqBIv/MjatK/NNuv90vA2z293dv7u7f2t1V4p89 c3rjgmmpmfPm+tdu9q/wD/Sv6OresKJ/vb+359b0s9eu7O5fMbC2d6N/YXf/2p4F3au33L6if9rm Vd0bu7r7/cX+L0J80b+4u38z85SVlFaVVN6I/SLw/6YitPar124e6O6ngWs3+heVLCzxJ1cMdG8c 8K/Y2OVPXU84r6dn7apuOXBVd//ACgrcO7CGVnXdlv61m7vWrmKlbS653oIZvf19vZkqDXRv7fbP WTEw0L25d+OagYG+KdHoHXfcUbIiA7yKwpas6t0Q/e/iBrb1dXd1b167eiNtecmagQ23z6YV2riZ VnyLXCKtzc291tS7kQ7O7QpMkX9zd7efZb+Z5t/T3UWr1tffu6571UBJb//q6B1r16+NKvmt3bg6 eiMblkumnP97qSn310vn4DbUj9ai1WgNGqACQgFahQrpuxyV0r8q6lqAuint8qMEWkEhiqhrJtpI oUqoaxq6nf75b8phs+zrpu9u+t4qp2WQs2mq6VTuXEDTpKh7HppLQ9fK8Cvod4BCr6Cw3WgDffej 9TSsl1KZ/6782TT9SrkcFrOWwm+ksQvlkLU0LUu5Gm2hNWQ5TqNlraIhG+VS+ilksVyv/z6P/138 Ytm1+XpMGa0X67cSVPmVaf93Of/f6xGl71fLuQzIeSuQa+W8F1GIhTJUUk7J+mJALm2jDJX6ihLn 0RJ7aHrWczcgV8l5D1C/knMvda/J9Oo62uP9cg265HQTbdtMS/7yGDAc7KdY2PuFXmK12yqXOUcO H5BxisWtkX19aApddaJ03WB/JRTm1pxXZfItkV0bKOT/1XQDdIb0yf3YLY/zagqrjHmJnOcGil+z Mz20UcZ71kNbbmqj0jd/D9ea5Lcyc26/JR82suzN0k7UfnOm/j1yOUqv9dFnL+33brm3S+TQ1XIb 19IxXEtdN9ePjdjqTNgXazNRl1vb8/9m2STDEwdoiV/xOaXt/BGwX9Ssl5+vACcthZExeHsM/GOw /Sokr8Lgpwc+xf91uVB84fIrl/G8Tzo+eeETUvoJmD8BDRoVRpOjnaN9o8dGVTrzH8GAPgbLv49U ix9WfLDo1xXvL0IfwNTkB4MfDH1AmITb+oFG3/QBkEXvE6coDPuHS4f7hgeHLwyPDF8e1gz+6MCP 8A9/EBXNPxB/gMUz885sP0M6nwPzc+JzOHm08yg+8CSYnxSfjD5JnjhSIh5pzhEfP5Qvjhy6fEj+ MeXYIaOlqeMx2P71/V/HfQ8OPnjgQTK488BO/MLWV7bizclCsXdjRNzYHBbdFVmL1BVkkYqMyxdg NqzMLWjq7JDEDgrU1loqtjYXirYK6yKeVpajgGYiyhbdvWQ/eYWoNQuSOeJ8+h1JXk5i8zxxXnSe /Dv2K1oCNKNZfbMGZ5GZTYViorlaNDeLzdHmt5s/bP6kWdXRDE/T/6YXml5pIlJTYbRJasoJNGUn vIucFY5FQoV5EQa0iMo7i6LmcWbb2WHebmaXUSF2eQIPL8KBU6mFkUjLi+rxBS1DmmTbEDw0lLuQ PaX5rUOqh4bQota2JacA/mHpzocfRtN9LUPlC5cMdfqWtgx1UYfEHIPUIfhOOdH0pZs3D8jqAohE qHMLfaLIFhq0fLMSmNEnyK7NsHkz2rwZIixOdtIQtDnCglkISwM05fLNiD1YbESGYq7Nm7OW/5/n r3WJCmVuZHN0cmVhbQplbmRvYmoKCjEwNiAwIG9iagoyNTMyNQplbmRvYmoKCjEwNyAwIG9iago8 PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0NBQUFBQStMaWJlcmF0aW9uU2VyaWYKL0Zs YWdzIDQKL0ZvbnRCQm94Wy0xNzYgLTMwMyAxMDA1IDk4MV0vSXRhbGljQW5nbGUgMAovQXNjZW50 IDg5MQovRGVzY2VudCAtMjE2Ci9DYXBIZWlnaHQgOTgxCi9TdGVtViA4MAovRm9udEZpbGUyIDEw NSAwIFIKPj4KZW5kb2JqCgoxMDggMCBvYmoKPDwvTGVuZ3RoIDYzOC9GaWx0ZXIvRmxhdGVEZWNv ZGU+PgpzdHJlYW0KeJxdlM2Om0AQhO88BcfNYQXTMwNrybLktY3kQ34Ubx4Aw9hBigFhfPDbh+qa JFIOuyqa7p5vinZnu+P+2Hdz9m0amlOY00vXt1O4D4+pCek5XLs+MZK2XTPHJ/3f3OoxyZba0/M+ h9uxvwzrdZJ9X97d5+mZvmzb4Rw+JdnXqQ1T11/Tlx+70/J8eozjr3AL/ZzmyWaTtuGy9Plcj1/q W8i06vXYLq+7+fm6lPxL+HiOIRV9NkRphjbcx7oJU91fQ7LO8026rqpNEvr2v3ergiXnS/OznpZU s6TmuTWbRYtqyaGtavcG7VQXFbSn1nhBrbUl81fQb4wfoFeqSwe9ZdxDvzMu0DvV3kLvGS+gD8zX nhU1ckzOHNXkdzto8hc4y5BfwGDI7zUe+d+hI7/Wkr/YQpO/BKchf7GHJr8Ds1F+4+GJUX6jHhry i/Ykfwl+Q/4S/YX8Dj4L+YsSOvKjv5C/gg9C/go9RfmNwblCfod7CfkP2if6r7Xgl9xo7ZYad5Ho vzLQf6dx8nt8XyG/07PI78FmIz/ua6P/OMuSvwSDJX+JPpb8onH6b+GDJb+HP5b8oj3J7zSf/oue S/+91pLf4jta8u9xRxv5lYf8VmvJb3FfR36P/i7yo6cjv8VcuTg/8MSR32IeHPmd5hT0E/yO/F77 R36wOfJbeOjIL/DEkV+0lvwW39GRf6ds5N/jLo78Au2j/+DxkR9z7oVzCAZvOZ8aj/6DwUf/ca6n /1Z7Rv/B7MlvwekjP3g8+S088eRn//j7VZ7ov55FftF4nH9834L8y4hjQcVNhFWFXfpnBabNY5qW 9acLV/ceNl7Xh787eRxGVOnfb6ywTSoKZW5kc3RyZWFtCmVuZG9iagoKMTA5IDAgb2JqCjw8L1R5 cGUvRm9udC9TdWJ0eXBlL1RydWVUeXBlL0Jhc2VGb250L0NBQUFBQStMaWJlcmF0aW9uU2VyaWYK L0ZpcnN0Q2hhciAwCi9MYXN0Q2hhciA5NgovV2lkdGhzWzM2NSA1MDAgMjUwIDcyMiA1MDAgNTAw IDQ0MyAzMzMgNTAwIDI3NyA0NDMgMzMzIDU1NiA1MDAgMjc3IDQ0MwozODkgNjEwIDUwMCAyNTAg NjEwIDUwMCAyNzcgMjc3IDUwMCA3NzcgNjY2IDM4OSAyNzcgMjUwIDUwMCA0NDMKOTIwIDUwMCA1 MDAgNTAwIDUwMCA1MDAgNzIyIDQ0MyAzMzMgNDQzIDQ0MyA1MDAgODg5IDcyMiA3MjIgNjY2Cjcy MiA1NTYgNzIyIDUwMCAxODAgMjc3IDcyMiAzMzMgNzIyIDQwOCA2MTAgMjc3IDcyMiA3MjIgNTAw IDUwMAo5NDMgMzg5IDUwMCAzMzMgNTAwIDY2NiAzMzMgNTU2IDcyMiA0NDMgMzMzIDMzMyA1MDAg NjY2IDcyMiA3NzcKNjEwIDcyMiAzMzMgNTU2IDI3NyA1MDAgNTAwIDU2MyA1MDAgNTAwIDU2MyA0 NjkgNzIyIDUwMCA4MzMgNTAwCjUwMCBdCi9Gb250RGVzY3JpcHRvciAxMDcgMCBSCi9Ub1VuaWNv ZGUgMTA4IDAgUgo+PgplbmRvYmoKCjExMCAwIG9iago8PC9MZW5ndGggMTExIDAgUi9GaWx0ZXIv RmxhdGVEZWNvZGUvTGVuZ3RoMSAxNzQ2OD4+CnN0cmVhbQp4nN17C3Rb1ZXo2efqSrr6y/pYsmzf K8t/WZZt+Zs49o1jW3LsxIp/sR0c24m/IbEd20kIUBJoSkJCgLSU8mtJgUn5NVEgQ5NCC6XQwsww gQdtpx9IZsq0pSVt30zp8Eojv32uZOcD7Zv35q311npyJO2zzz77nLP3PvtzrjI/u2OUGMhewhF5 87bhmTrRXkUI+QdCIGXzznnp2+2b8hE+TwiVx2bGt+WHfvpbQlQSIRp+fOvusdqy154nRI80hW9M jA6PnKv7XTkhFR8hj8oJRLwTv0eDYAm2sye2zV8XMeQ+ju0ubL+xdXrzsMe9w0lIVTa2t2wbvm5m jr+ew/Zd2JamhreN/vqdtWnYjhGiPTAzPTef/aQ9TohczfpnZkdnvqn98CZs9xLCvYc4wD/2MiCo Zm3KqXi1Rivo9AajyWxJsdkdzlR3mic9I1P0Zvmyc3Lz8guKAsXBktKyEPn/78UfJg78XEHMZJpf wbdd2cs9Rdzse+GDyz/jP4+3Lfzp/+YqtIvAMXKCfIH8mHwv2W4mUTJJPoOYy1/fIa8i3S7si5J+ 8sRfZPsUOY397BUlQ+QWct9foPt7UkV+hDQPkFNLuNfIDWQbOYwzR3EVvVAGzeTfyNNkC/kJeQWh NQmyhZ+TB8nb1ETiiTZKkpAxBRwjL9KfLvG7lx4lqymzwfuwJ6rgGkgDPEYehIdwhjuWdlz7ifV9 htyGnx1kguwk+5PzNNBUvoPqyE04cisilpEe0kjGyQxn4piNPw574BB+x8jfJLn0kOJ4WxxPpybC baHPUnrxC4g9gmOOkGFACdPD3EpGSIMLFtzVy6RkgcTH473wGvwQpddMfgWzKKEpcjj+INkCT/BW OCU39fV2d3V2rIu2r13T1rq6JRJubmpc1bBSrq9bUbt8WU11VWVFaUmwOFCUn5ebk+3L8oouu9Vi Nhn1OkGrUfMqjgIpavI1D0mx3KGYKtcXiQRY2zeMiOHLEEMxCVHNV9LEpCGFTLqSUkbKsaso5QSl vEQJFqmW1AaKpCafFHu90Sedhv51vQgfbvT1SbELCrxGgVW5SsOIDa8XR0hNrolGKQZDUlOseefE waahRuR3Uq9b5Vs1qgsUkZM6PYJ6hGL5vpmTkF8HCkDzm5adpERrZNPGuJym4ZFYdF1vU6PH6+0L FLXETL5GpYusUljG1KtiGoWlNMmWTg5JJ4tePHj7aQvZNOQ3jPhGhq/pjXHDOPYg13Tw4P6Y1R8r 8DXGCq5/z4U7H40V+RqbYn7GtbVjaZ7WS1NCjM+x+KSDHxLcju/CB1dihpMYdY7lQ8LAZhTvwYPN Pqn54NDB4dMLezf5JIvv4EmD4eBME0qYRHtx1OmFbx7yxJpv74tZhiZgWXKzzR2tMdu6Db0xmtMs TQwjBv/V+7zVHq+1b5Em+pe6CQoCxYEy9XrZxg+dlskmbMT2rutNtCWyyfM0kYP+vhgdYj0vLvY4 ulnP3sWepeFDPtRma2fvwZgqp2XE14QyPjQc27sJ7WkLU4XPEjP90eP1HUyxSjXBPoVWwlW1jExK MT4XxYKjLh+AlsKGHLQoDdMfE18XPDhBrjVFqvEhG8anydc0lPy3c8KFDKRAUSziT6i+qzcmNyIg Dyd11HSyJIgjhodQRZONivpiQd9MzO5rWNInW1bTZGevMiQ5LGZfFSNDm5OjYsGmRjaz1HRwqDGx BMbLt673DAktnD9ZLnmeCZFy0tfIiJ2r0K5ymw72jozFxCHPCJ60ManX443JfajgPl/vaB8zNJRQ wXmczqvMGKOrunpbO32t6/p7q5MLSXQwdqqcpqvY+Ho9CTZocjFtjlbqpR6uDwktiJCaEfA11OJn TJOjxbcFBa5gmak21Eq94CGL1LiMWIHUNNqYpGPtK5jyzJxWRRa5qVkT+ayKeLx93sQrUESxW0pO jCO0TKiRxS4uBz0B4iiyUVBMli5m81Kvb9TX55uQYnK0l+2NiUeRclIYisyTuuq6onWZsFBMxIvd iw0mzFiz33O5cGNhpb3UjFzV3bLYLR3U+lo7DzLmviRDgitviRFmwnK11aOcfnaefc3DeIjxRCvn +eBJWWZneYId24O+lpGDvs7eWoUaPchnPNezuVJIK7R2NQSK0Jk1nPTBgXUnZTjQ2d97xoKp14Gu 3qcp0FVDDX0ns7Gv94yEWZiCpQzLkKwhsQbj1IENrULvOSMTslfpVSkIpb35NBAFp13EAdl8miZw lkUcRZwqgZMVHHuhllwTKGP0303SCNPPjX0TB4f6mI0TJ0oE/0EMfHUoHV/dSaBqQ0znG22I6X0N DF/P8PUJvJrhNWgZ4IRA0fUHLU2+D10BJWhi9CV0hO/GTFlDik8CCdY+rVH94kLZSTX/s9qnOYog OckxNM/QT2vUmX+ufRoYPmT1WnO8Vm8jleLZcG98gu/+05ONqteRLyz8CiO2FvMKFzkpT6daQTKU GKjNACoDHCDQZR4xU7PVmtKfaoAOoNBvNNiNht1GmDAiDI1GWG4EldFuzDZyRqPWZUpNTdMJAlWp 7KpsFafiBrRWYdBlMlA9l5rCaQcdbxlhnxGMQNQppD4UCg1sD10oKytjIAIQvFA2gCvGv2AolFLj Dg4or/0u/37/y+CyXCizhgZKSxSk16eHVI23Hmx5VV4beM3AJZr0Td8vvxXTxat1J958TAc3/SPt gc/rYghfPK87/S3VzR+f9VRUeFRfSav4M3ALFWkfb1LapQlZr1j4DfcM9zLJJCGyTc5vLO0qHSnl xvOgJw9ycmE+B3SSYIhoATJJJCSqVnDwZQ640wsvyhmI57iKgsi0YY+BGjIs2VGbRVXcoXGSds5B 6i/UXyjDDwgOXMAd+nHzbNe4H7+yoxxcf5UJfFnFtKK8ThUqc6ZWVtVBVWVVSFPM+bJM1GHPpKGy OlrFObZr4z/P6Lo/XLMpUpAbHrnx89GG6RCKXMvrDJXP2bJyCtK69m8sSw8sl7wN9cvTmt2BB3v7 /F2f6eh55Mju9aVOO+WoWqXR7TKmGPjNX35pqL6vJi01r8yD5r8a8/MnMX8vInvOECvuLE2wRsIc 9BJw28LpR7NgfRZwVVnhLJp1euG0bNW3cFm2LEqzsooLBc4fhtML5+V0wRgBUoD8okVQVORwt6c7 hJwOkwWlQS6XRmjAGvIzO0CpDKIwBgcGEnIZ8AMqF9NOTR0XKsvE/ZuohqnZVsdVlOcykWg4H1Tt 1ILUq2KmlxXtHwoVt1Zk8Fqtqvez2vhbYyqtRlVSXti7rtk1/Td8xBWI2xzV5X5NoH1Zlqs8WmUo KAk54+AK0GZnSXGuIVCdu2Jt3sX9uO5OlIOPe4U4ySo5g+NcCy5IseoNYZNsjBqp0dRuMRsdKeoO wqP6n0Xt8zyxkPqyoB9Ntb7+Atsb2xfuL1haAqhQjS8vsWhmtbgr+ra9RF/kzy3q7WiTrj12H+7E Ieb39W/gXuG5P+7JXhENXLyXG3MH3q7tX5bB7LN+4QNuENeUi/a5Wy6YL9tXRudL95XSGgn0bo/b 7+Z66BilTRQGrdNWarWSyB6UPzPQXNRIUVHFGxWQp41Me8DDt+flOYPRLEu7ZdAybeEsFuM6pxN1 EwoO1F9IqQmyLVwo266Y64Wy4OLhGwCmCRMkDLKyKtXEXTLbTApL6uEGO778yy8CZyvpqO+/tyFD 6hmdWdZ9U1dhfmRkx2cb5dHmnItf3vbotsoVy5ZPdC6jH62cH6jXCblppddE/CvyCj3Lgpml/bes 63vk8FxHQKxqjZ/WVqwZDFVHWneyGkOxVX47ymMlue0MWblw/lk0VUEPmoQFWiNekhUueNYHX/PB PT7w+Sq0pkjqghWsTCAFqDOrddXQKgiugmU1ofJwZcWyoo56S2V7tbXC4XOY2q0OktbBo1YVa61X zBaCCbUOKHJBGCU1oBgtWq0frZaZq/OT1qpiir+ikbACJOYmvWs7ugu6hlUaZrhC/K1xZriFgdTq ZVXFEr/5GBqyli8KplYvrwmyNrMVZ7p3bVd3Qe8w/XUwutx77ai5sKTMGaduNGZHKTPmKldBZa2c cfHFTyCYVb3ERk0rfq8N7eolPPMiKSH7ZHt7EHpzJ3KpPweEHHcOLXAyiZ2XBZSYLTKYD/lMflXY ys8vI2WWspIyuSxaxpcIvegNpUgeVEEYsF7sY+dfBNEXTXMK/qtOf/LwDzC/n7Cy7ReYBBUTu/ro q5iJ5VVlAnOBi8cfSj+nhaLVnKDX8znrOjpyl42uLsxtHr3p7s6cdZ0dOU9ldJR13ra5amCt2NCw MlM5/2F7qCKUkruyxHPJHwp2KdXvcm2875WxmRscuWWZTCazaGAf820YdT1ktZxhzhAzghncQxmg XZ2SoiERlZkTOfoQt8BRJQBYWAAwdqaqVO1q85LPZ9v0K5EuFLwwsL20hDl6JWqhgSSPDVWOTfaX tfEz992sBX+dNTPf6czLtFoz85zO/Ewr+m+mMAhdjkQi5Qxsw8UaUHca0i7rRAGIAL8TgGf6yscj z6v6VKDC9YpckKvnuN+xBVs4iSvhOA6XSkg7TSwV9TGwHdfJHPLA9suWCiJb2gW2NFwJkyKTD8Tb uJcxVtrx9N0rj7XUQU01jAZ3BGlXEEixpZhmyCiScRP0mCDHCDsMUOSPrHTwP1XDKTU8oobd6tvU dEINXLkafGqgRG1RU7V61VAlVFZaImLtulJvFVRVlXr00VyLg3SkOZMnET2UBdfLPBXaDYsZg4rZ LMZUfCXDKguYtksBNOdKX5XKJdp5VaHUhGlVwcNZ4cYVrilXbk6hJ3pgc5WjUAbR3tQzXNIw1pSd v3r8piPtWT393d7HbC0zD45Vjq1vcqQEsrPnOlaPr8oRJtz5ZS66Ra1Tc9fc+73Jsp767GpnXU1+ ae8Nq/v+5siunqBGb9b+uWHrfUNFJodb/95NviJ/y3ClossWFnvRn+WR8TMkFY3Kjk5MdIezjhJY TzDqkjBKnkXdHIy6xEYoJaTAbNIKYX1UBzqxPcth1nIddou+3WQWUK/KWSu7FI2uirJ+WIqkS+7o ylBL/53Fz45m11TC6XhyO/sGSj4ZZekHgeq8uva8iwe5cXfgxdJotfgpARbzzu54M3cH9xTmBqfk 69UFEE6BlHGAPCXLDOfn2fPz8zzUT5dTTqDwPyg8QJ+kv8GEheabTqjPMgvxZ6ann8p/L5+eyIcH 8oHkW/JpfopMo5TaaTYtp9xeCvNYKOTlFXrXpdZlrM3YmPFuxm8z+IyM1PT8dh0QM0bqsqQhsYwT TX97CJScE1vMqF63Kjno9u37XRYlBR0oYxHQ5vVAHaAHQpvJxBio1sAlG3IyE6oHLq8cyJHfeMVC l/bbgjWrND6/fHJyriktzyvZcgIWd41/XUu9O/CNGe6pi9lwz7Lh3JwiTUCb5ZAmOy+OjhydqaW8 mv/7odSy9qFAB9fvRttwL3xAz6FtBMlpuX6+eF8xnQ/sC9AxP+jTPGn+NO4G5yEnbXPCcifoHR6H 38G12GG5HVRgh2zgSNhaEHbdZT2KaQHzV7JgirhkhytidVldaklOSYtIUukLalBbC7jcaMbPvFDu Ba83w2KIcqCxarZrbtaovJojmq9qOI2Gw7OIUtpuUYSIUkypqQHlOPoRCgb9fsRZLizmDMnEQe3L yr102CrKi1UJ/6ckR8WY/qrxlKroqRe/239HSUHAmjZYG4jWZi3vHe9dXjWwe1Xk1rqcoCl9fahj 0/L+8f7lYP/SkQLHv9yWXpRS0BQqb64qW9nf2LqlIdNhenOrW2xtL22oqmgcZP6qbuE3Kl6JcWXk 83JNMrfvyRvLo5ja78wBO0vt9XroFSAsgKCLVGqaNVSj7kWRlEkmssIIX8b6hckuHymNxvL68hPl L5SfLVcVRqade5zU6YtmWEzBDqtT1250qNu1JBkDEgfwwvalzD+0GPkGFisATBvqlaj3yUKAycWk Wky3ODOotRrOf78WGn+/WAnUbmrOy23efOORaNk6vW91ReXGaH1RKhYAYvVnV3BfNwRKi81/cAX+ dEapBIrX39Te88hdu9aXGOZS04rbt1x/i8wqgJaGhQXijnczO0vJJSZCrGpifY8Q0xk8uI+dqixR Szngr1B81SzSmTA2ukn4me+7wY1yecZgjQCTj8dgiThTUx12u9p8az17OKJO/bzdzjkMR7BSvRBM JJdoNyzNDOFxQ0/kH+CT5pGJTqgSbYMdKU0mUNOdB3yRtFTB5fHoVrS5c0ucjT3e6Pq3N+0wCK2c WsVV1aTnpxnpfR3aDqKsbWzhV9yz6GPysIpLSZUES0SvC6ObvE2A61C1bIkuVKEgFGSRsBh1w4T7 OvcBN7dO2ccbslNnjAgIi+1esxndqRPdqUMwJ92pokxUGovqikYX444/x654gCpbKKHGxWCDmERC A4bFaoR50/ivL/OmGkHVO60Ft+JNv5MoROh1f77fHfhOabQGnWl7tSG/JJQKcVfg4nOKM1X2ymqC XegXCsi4HFZnOjNzMzm91qP1aznWTSQnOJ3+o37Y63/DT72RaYwT6VHrHa6vuH7rirtUxAUul9XS XjBYMF3AFRTkruMXi4DEwWaWO8BMFz2jUgN8Iogmju5iiYomqnavGZ5d0bWnqzCwdvK6m+XcjraV zkCVJaOjJvzZkRUZlW3B7rtX3pFaXZoVGti7dvTrh7euzhXMNiH+p+MZWdEjf7e7cbguY1lhMr+B 51GXGlIgu1nexcmu9MhlGcylZIupRVHElZnLfcnMheVQi3X+B9x3UWZm4iNb5eJ9WVCZBbd6QZ3h zKCHXFDjgttSQbC5bXSnCbKNmKqAn4dbKYgRLbMeN2ZWWm3O0RwgkWnHHgd16KNpFi5qcS4u5ILi Cq/0fwMDtoSBJBNY22X5H4u5FyY3Nu0ZXj65qfGmoWXfXrd/uKL10PduTH5D1/47O498f8fBOzuO vBb3Vo59/podP3xkePGbEDy79fFuZgt4dm2Js+tLnt0Dp0oKdc7E2UU65XzwmAaTFKTTEBe5H+Vi /AaFqbp8t47RVTA5va7aQj/iQ8RIMuiHsutvxVdE+qgIO8TPiV8UuTERGsUukYqnF2R5IdwWeVb8 nvhDkfuaCF8UYZ8I3eKouEPkwiJUipAjglp0irTmjyL8UoRXxB+I9B7xmPisyI2Lu8T9IlcpNos9 IpcnAi86RPpD8RfiH0WOdX1N/Ib4fZFn3bRKBKeYK1INY/MfIr1VhPUi48C5RCC3aLWmW5we/e3W x7hXMTOXqxoieVyYoy6MYdyXOKrlHuM+4jiBk/XWCKcV4Tf/oaznRyJ8X4QDIlwnwjhjCbhsnOsj EX4lwjdEwF3dK8J+hWBShD4RIiJUi6BN0MgLIvxYhNdEOCPC4wpVoj9fRD/CqL6ZYPVPi0SPiXCf MuOuRTrcgCDC/1DIHlOmw97dynS9Sq92kcOrIpxeXO2EspgWEWoUJqkioGhuu3yy0wqvCYULLqpc BJ8INhFUIvxBhPdE+IEI3xXhGREeEeELInxWhHkRRkToEqFJhApFeU4ROBH+XaF/S6EnMRGOinCX CLeIMCtLImxShsgilIiQJUIK0ojQw1r4/buNmKZvvPw0KEn79qtes5e/riAf+M8QfTqrjQMk6N84 gBj/bOKykZVjS+Sf5ORX8KUlSsrCTmklRmJ+saGkLPSj6kJHtseyrLCwOv4gg9MtlvRsR2G16mzh cgVahn0KpNAl/HU6+p7D6M8c5JC8UZ0CghkKzGC2QIfdYQ9bLXar1dLlAIfDqj/BnUUT5lLrUwdT 96Ryb1vfs9LnrH9vpSes8IAViNWCuZzd2q6xmWVH1EHtjmxHuYPb64B5ZMB8kZLX1ocuJFNb5dIi mdkuprVKVjtwdU7r41iNSk/4MhI5rBSK97V8azuWl0foWM2mpXz12nUXN3DXuwMXs9nelifvDm3k BXldpRXGLGAxQ4c5bNDbDQb9A/on9bRZD3oDf0IHD+igRgf5GI50Ow23GmiXAUoMsoGKBjAYHGdx BzKmESprCh5f4FIS94r5S/eK07Y9tjttnM3QbjZbVRa9SmNzpOj4do2Zw5KWshCGsTpYn5JaEwou Xjb4L5YNfGb/yy+DHxuuZLqvfGI6NrDf4vdbXkalJy8g2IcZwIbJKcfuGv37tVD6FDy1UQvZ2nXx n/z7Ju0HP7m77hgrif9cDQ95AoHU+C8vfpgagHOH4k8p+l54H2VCFX0fkC0m6MCyJGw02Y1Gk9Fg Z7FkBaYnOrvOTgyGVCBdxnkjNdKoXtKV6O7SHdXFdPxZ3TkdLWGC0pv14AE/bIAbgAdTlNjY5aPN GbHZcILE5WNNInBvZxAotUwiIbeG9isaLy3xVSnh2gw+LPkwE6+sB0xYBFr+RU9NWb6hKhigI9qL //hK9RZfWzAS4IK8YNTu/1Ppn3/gdn6BPepnuk7F+j+Hf5ikkVvk9lYtJhEnDC8Yzhq4qGHIMGPg DIZ0c/pD6XQhHQbTp9P3pJ9LX0jn5XRISyVhnuZABTQBBzQtyqearVGhxCSboqY3TOdNvImJRcj0 RkwmNDgPpl0sy2KVBju6AyzZwsx5+ywz5gF2uzpg89l89bQOkpVEbmJ7IY3vW8f++WHtE4b8b301 0JjmK7VlVPlKczzGjDdNb8bbeENpXsO5N/Xal2cd4sqR5ge7cF/dCz+HMPkB2rBbNpF7zDpRF9Rx OvMD/FGSiOyYX1x9eRO2SQF3WpFks0lFae6AZLvGXeS12bxFbtbATiYzLNgX/qR6ll9BdJg1V5EH zpASNGmTyRoZCbBijusJgI9ZeTsmp4c00Eqh0JGzgeeDGyQLSJa7LEfZNW3NTA3szrwtk2ZmZKTr 7A5BcPSnF9qHLDpZN4MWo0I7yRgUhkTO4dAPpQ+mpeDC2VG4wNLt7RewTrtYxk6BFRSzV07CduYR rTXKxTu7e09kKX7gbEuQE8s2PvHMZfGSIJNz2FVelISP7hk72OW75Ytf6b1j213dWSe/9s2RUElB 78W/033uzcd0NO+GxyeKy3pvbGnatb4s/k783erN1/QF6b9lhafXTIzEzRc3Bbp2rT5w/cWX8HxA V+IRTUHrRF3brvWVOnXh6q0tP3qNsusOlr+wu6dX+V2Yv+iV/EUiX8MO/bP05XBPpT9ZoqAuz6kG OS+/C/ObUjmTk4SUiM3OLqXsgszbtHtNd5qxHDxBzhIVIajYtNfRvNJe/5n/dXYzknD76BE5JacP Yfb+prxheTqlq6kUasjNaakrM682VHTOqQazajtKTOmmnPIsiyWrPKdmbE0R07cfff37fAfJIKWk Cf29caRuvm5fHSdJqPMMpmkvqzldHhddbQUzK0AbaRcdoRxvIyunnNopn4+dhTy9KeL0OX0WMrWH 3YiFA1MWWUiNWHhb/lxZWWbtnEeTOWd0K8knK65YLe5nFxuswmKHn9XiCCWqTay1lDt85uuZIeey fRZDMq4lVI8qTWb0tqva3PuF4YHynk21N3zr5u8+f/Ruubty5sn5k49ffH1gd9iTWt6xfP11q73u is4n2ifq02yFTaXt47WulPxVqsbonqF6c+ahsemndtQ+cs/jrxel79owdP+Wmts/3lEzdmdPSXS5 VLn5UHdFd61Ev1Gz8fqVReHStIoNNzTnN5Vnoj7b4B46RIMo2XzZVUJlOkM5GoUhmAEsi0W0HHIG ToMucVAHWLliq/A62qgd7rnvPrJ0x5bNR/AMlsuZOjJ1HZb3Zh5O8MDLKGZeLWg0goYnc9Sl3DYy 95m4wx1QSgseC7scG1+VE6JOMOkuBnWQ+p34eR0cL48qzxKbhyvexdy5HXX/C9S9A3XfIVf1l8Du IPQGoccHu7JAb/KYaIEBVJydo7kYY6b2eMDjCeVPaZmBaqU5iyYwx7uT5URSl5dVE6Cm7JZAUV1l iuL5WOBmDxgSqlp6QlNHuX/IHDzwzPZjxw3GzKEDsaljp4zf1Rq1KmcwXLp6qqvenaJ3BBpLWma6 6+mjj8X/fHLD2beX39l6DMjx/lffWnZkY8lg75rMxq2teevu/5e7xr8Slre0Fqz90ruKPPsXPqCb VDfjQbpWbhxJnU/dl8oZZcEaMXtFL93j/Z2XaqJpYE6DtLR0NwmbnWa73VZiZk9ttWaXmZpt6VG3 y+V0m9Vqbp0uUXzWh0JBi+LtWXUdtIawUaa4e3aJ7h9QKm327Cl5U1JZxQJASIMunzMBaAM+fyTH Edq9plD2O3TqzTdoP3ebnPMjy4+GtbrjgYDFFMwOeUpW5WeszqKBQN4PftB18acFzVjzLOTE26iG byOpxE/ukfUj3Dy3D+tMCgF2Eis9eZHpwJ4AlQPgWp2VlUrQpdiIFrTanbZbbffYuFEbBGzgsYHR BntsCzY6ZQMWpWWvzhixZXTmqeztTrMpyt8hQJ2wVtgovCv8VuAFgfcs3aglHxskslPlktuSeIAw 4GcmwLMC/LJ7tKpPfaCQYatfP7Uy0JPhDZr1WWnpJflZpidu00Ko9urnC3lbvjRUZNM/N6W3uGrH 27kX/9Kzhsb4K7CHvIU2nXNKII+a2KNP2YD5C8+b1A/yj1gfJvV/UG52WB6SiJOaCpZaJlNoXNae 7DW7OjcM5gXzGivSS7Pthcu3XrPatSajqyo9PcNfWFnjKJSZHg6gj38Ja3QfWUZ2y7rJAPiL4AY/ OHHOv8Uj4oqUsNlrECwpqd29DJZlW4g6vBuzx0k9dOmhQt+kp7l60OhT9VRfEBWdlooOm4Xli2p9 u+BJPktI3ucoSeAAuyIvW6zc2b1clQkdy9JPDTTsnF16HqXcVNWplk7c+6BS8VB0VBtv0O7+6bgW BFv3Q8pT+pzmkRs/32EPBgt1Kf5AUUrNpuiKAoeneLmUVr9qVSY1iN50Ie4KBl2qt9yBe3s2XHo4 xam1UyabXhXs2Lp7by27prNnhyQlDi58hIL6k/p+jIOFShz0k5WwlthkPVj5XHjIaeAEJRgm42GC HvMPPWmVi6/THtDS6zQHNNRsBLrXCBq1mh8VoEcAQa8n/egUeb16UMsRfpBLSUgLD+R25YcYA+yH GgOD25X7oCX5YLK8/Zj24vva2NljWurWPh1d/LVFRRrOD9eq5mgjni0bsTxLVuv4TrNKcdUXWKF1 pfnSxqutVHXukyaJNnkrIaoPcE+ppEX2myUjGI12Rz8VdG4d1en1XD09h3mDmehn0Ar0dm7IwDno IFncELvWUnLKYGiA+RgES0tCuJ1khmzzcj6MjX72C5OY7sdnQys3NpbY5FXVquLqRp3vjh2lZ9/U 4R6/xKk1qjdhefyVNzX6j6/1VCh3pAsX+EncbwHZLqcd9sINXij3QK5zzEl3Om510E0OKHckUr5i tGNfdrYKS0Gj0e/awNsGddPms+ZzWM4gzqxTyb6ob8jH+XwZgyjAK2/oEs8wUCX+pRDBK8JMqcxm OTHnq1Cu6GDpZyQs5Tdx9Lk7f3J3243vQNmzt73dF1hZFxs68IuvbQxsuvfaup3jPWJk5Yrg3N4D trV3vHr9d6Hyh7OiPf7T4/7gtr+L/0ts8OEdDfYsv+u1+CtWyW3G/W5f+C3/AO43QPbInmYJsqVy iY7jjj0wlrYz7dY0rjytMY09wfq9XIkpEAn052UtPsDJ19mllJIUmpISzNigC+QPFhZmuQbN0/az 9nN2zm43q7IGebbxxFMbluaUJXY+EFKewSfuYBO7X7qjXBJA1VUCqEoYrOqFuuv33tZ28EdfWLP3 PJSevPnHo6FV3Ionrv3Me0+NYVKyvnJTT7Or/mvsqeqBHleex9R6+6s3vQaVb09J6fHzx0orRl+O n3tu6thUldUjmWE4rbIyjeWoyh2jcsfmSN6xHVPu2Dh6YFm2Q1y8YwOeu4bbjPbLEQ11yAsbhGsF KghuoUDgPhbgPuFx4X2Bu0E4JNBtAoBe8Aj02o+VZ7yHhAeEJwVuWtgjUL2wXGgVNggqhnxO+FhQ 7RGAoWhQACR/TwC/QsIJckNzRBSQEyx/W3hP+IPAJRmNJGioWYC3EU09gh85sk4ehz8gwLywD9em VOUCqCWM8WqNRkUZQDkO7ieEv19WqQBrcfqiijyGQ/axUdDK1sKeTL/3B2UpTwpw92LfiNLnT2Lk OxloF+A3Ajx3GVW2gsRpT32s9J1DSIANAsgClCvdiPypgnxUgBsEmFZ6WxeZewTAbS0ocntOWcAD TIBJygQZSgrlwrZ/i6yACP2WXQltTD5e/itXTBsv77z6ZgoLc6W02DiQxqosdkyZ+/QrT36S5BsH kq2ldvJ2DF1jiPOxN/3KK19YHf8SfvAr4iL8c1xk9lPENWLUYXkmen85W3R6ZAzIHk/2o06nQHg5 EZ0fJSSQZ30kXf2gh0efi0flvTIs//AIBf3WmsVvnIs9rHAkUkdH4ror55Mo+tpVQTy++SoEd+FT wvqnh3rcQynuQUjuofGU6Hw027OYWeBGspdSDTNaGm5G2cUjeVa2kT+UKT/JURKO0FLiAZ9MPPhP oujWq1YNX74KoXr8P7+NxG8q+eN4lt3kjLxMq4EOgWr6McVXqbhxFVyjglxVpapZxVEVqMxvccBp BYpvTpcqU7BT0GPxSz3K3ks9vshu621WarVYzE5B5+iyjdiozeHYpwe9rt9MUx2WQcFpdKdwOpV5 UGNMUbSK9QqWeSyNYUX+AAvVlyp9f/LOC0lSSE3Nfv7FF8n2FKhhhrbf4tcmLr/MILCMBzTcZXGd 3YXxx3UPXnwbXrhVF389Pnpn7/O6i28rv7Okbl1sEz22S8evqEiL11ws8FTQ4zviqZeC/8X/RovT Es8N8W39zdHy+vigufZDIib+j87Z2//VsfjfUjADb9Zo1fdjDaUlNInEcRpvvImsX/rfKyNYVV/+ KqcfkEb1Ewu/wlp+Bb5XcxmkkztM6vnvk9WMDeLaaA2Zxfc2hAHfLdzhhW6kcyNcx77pE2QW4TE2 Lkm3gsEMh32vI5yO7+VcxsL72J+KfLtVPyc2xg/7z+G3H7/bGG8V+2lNDemnNQs5SNeoIgsH6BML HyXeLBcit/I9ZBbXt12Z5xrgVXNQhO9SvofZEikiz0I1PE/V9A6uDP+eV1lUbao/8hNqlfpRTbWm TXO/1qLdq31CcAqFQp3uV/oe/XlDm+G04RfGg8avGN813Wp6zPQzc9R82tJsudFqsuZax6x3Wd9N 6Un5Wcrv7Rb7rP2HjomkXspJM0ahDSgoSiwkyP6PE/em6iHEMfGlQ0/yf7kRMpQcwT4t2ErAlKjJ TBLmSBbZmYRVmJvdm4R5YiInkrCaOMm3krCGXI91RQLWEjusScICMcFwEtbjGqaX/qddMRxKwkYy DWeSsInU0XycHUMFtl6kY0kYiMTlJmFKDFxzEuZII9eRhFWkmLsnCfOo55eTsJoUceeTsIb8QWVI wlqSz5MkLJB0fnFePanmG5OwgVzD35iEjeRd/p+SsIncqH521fTM7tnJ8Yl5KX9zgVRWUlIldYyO SJHh+SKpZWpzsbRy61ZJIZiTZkfnRmd3jo4US20tDU0dK7ta2tdKk3PSsDQ/Ozwyum149lppeuzK 8W2Tm0Znh+cnp6ekztHZybGW+eGtk5tXzm0enRoZnZUC0tUEUoLiL6B7RmfnGK60uKSquPwSkUIT +MTQ/8XicEfjk3Pzo7OInJySuos7i6Xo8Pzo1Lw0PDUidS0NbB8bm9w8qiA3j87ODyPx9PwErn/L jtnJuZHJzWy2ueKlba2anp2ZTq5sfnTnqLRmeH5+dG56amJ+fmZZMLhr167i4STxZqQt3jy9LfjX +uZ3z4yOjM5Njk+hAIon5rdtbcMFTc3hwncoM+JqLhdl8/QUKmxrgqZImhsdlRj7OeQ/NjqCS5uZ nd4yunm+eHp2PLhr8trJYILf5NR48BIbxiU5z39tNFlFpvFc7iazZJKMkwkyTySSTzZjVSKRMlKC f1UIdZBR9KkSiZBhpChCqIVMIVUxQivJVvyTLuMwp7RG8XsUv3cqYxllG45qIE3IbSXpQridrEXs pEI/jO95pB5G2lGyDb9nybWImyZjf3X+Nhy/SZmH9Uwi/RT2diqYSRzbgthhXN8kUq/EmTZjz5Qy xyzSBZRV/XUO0hU8/veoexT83BJdKa6YSbQY/emncbrEJ/CfmPW/JrmEjsYVLvMK7wTlpMK7Gyk6 FaqoMpJJbV6ZbUqh6vqUGdtxxjFlvaOXUW5WeLO9JDhPIzyRlP8WskPZ7xxSsnGLe5vDmT+pLWar s2it01fJjK1upzLnGgU/r9ge65tQWjNkGUasINml/BUjzZWcNyf5FivQNqT8Px03jydpRpHjqKL1 caRNWECxwnMb6rMtKaEp5XwwCe24bI8J2fwlq2xWvhMnbOsVfJhm2Tcbu7j6ueT6x5R5ElKbwc9p lPuoIu1iBTuu7HESdTiJ0OXrYxobT+KuXs3iWq7cz//LuTnMD3/3xIsLXpzxU14vkChoMNgHlc8T oJKt8MZFeOEiWC7C9McgfwwfnQaznFIg/odnQfxjNF/8MFor/vff14pnwAYp8r5a8bcXasUPwgvi r6IF4i/x/Yv3asV/jVaI7+H7n0+FxPOn0sRfvx8Sz70TEt/lQmLw/cH397x/4n2VGYET7y+8j+H9 HagNvlP/zp53XnhHxYD2d04gePadhXc05nfgZzjqn6Lp4o/w/UN8/yC6IL726grx1fZa8bvtBbgU fWKNwZeg/qU7X6Lf+eqC+AIu5TQYnw6n4JfhG4j59sYC0XwadFisPvf1cvGbX18QWeUQOpOd33wm mi3WfwOexUEvnALzicET0yceOqGaOb73+F3HOel4yXH5+BvHzx///XH115HmebCSFWAh3WB52lOL E5jk4gKu2/wIBB+GOx+GhYdh6OGZh/c+zD2esiA+xi2IR0Mp3Q/iyAc6a8VHV9cqMzu+6s1ufuir J75K78dV3rd6QbwHe56HDEjFYCOC65nOArH+m9hqh1R5Nf3i3bWi+e49d1PhC9EV4ufxfQQlcdft K8Q7DxeIdxxeIZLDsNx8GG7HSfbfUiDuu6VWnLll7y10545a8fc7YH6uUJxT5OKQPTMF4vSUX5wK F4ppek+3O+Tq1oS4bjUu9nlIA7uyBPczgyFRPg32p7PzmtlPFof9Jc1KrTks+pqHBmVxkPFDxP0D aZnN14QlcUN/idgfLhDtkNJtw13zwHWrkLFZ+UH9ILeHO8GphzpnOvd2ch3rguI6ZHA++vsoNbeL 7cF2rjUcElejPFrCtWIkXC2aw2I4GD4bPhf+XVj9UBil4+lOj3i6nSFHtxXM3ZaQuZsCqiJEuoPm BTM1mwfNe8ycmdQTutcJPJyGu052dfr9rac1Cx2tMSG6IQYHYjmd7FNe1x9TH4iR7v4NvScB7uj7 3OHDpCGjNVbW2RsbyuhrjY0gIDNgLwKWjJNO0tA3NzfvT7xgbgf7IjsQMTenYJS2/9ILEu15pGXA jo1zCTx+zyV65xYHIN8dSi9+wRzxK/BckgHOCUuMkXLj3EZlGbA4WulNksyxF+Db9T8Bv/icVQpl bmRzdHJlYW0KZW5kb2JqCgoxMTEgMCBvYmoKMTE2NDgKZW5kb2JqCgoxMTIgMCBvYmoKPDwvVHlw ZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9EQUFBQUErTGliZXJhdGlvblNlcmlmLUl0YWxpYwov RmxhZ3MgNjgKL0ZvbnRCQm94Wy0xNzYgLTMwMyAxMDg2IDk4MF0vSXRhbGljQW5nbGUgLTMwCi9B c2NlbnQgODkxCi9EZXNjZW50IC0yMTYKL0NhcEhlaWdodCA5ODAKL1N0ZW1WIDgwCi9Gb250Rmls ZTIgMTEwIDAgUgo+PgplbmRvYmoKCjExMyAwIG9iago8PC9MZW5ndGggNDMyL0ZpbHRlci9GbGF0 ZURlY29kZT4+CnN0cmVhbQp4nF2Tz26jMBCH7zyFj+2hwjMQaKQIKf+QctjdatM+AAEni7QxyCGH vP36N0NbaQ+gz/YM/mY0pNvD7uD7KX0LQ3t0kzn3vgvuNtxD68zJXXqfEJuub6d5Je/22oxJGnOP j9vkrgd/HlarJP0dz25TeJindTec3HOS/gqdC72/mKeP7TGuj/dx/Ouuzk/GJlVlOneO3/nRjD+b q0sl6+XQxeN+erzElO+A98foDMuaVKUdOncbm9aFxl9csrK2Mqu6rhLnu//O8kJTTuf2TxNiKMVQ a/NdFZmFCwJnyq/gXLhk8EL3F+BCWXJLYbbgV92X+KXyErxW3oI3yiV4q7wH7/Quid8rZ+BaY/LI hPIsLWqw+pfwodkf8ST+lKEWUv9C4tV/j3tJ/Wv4kPqXBXj234DVv1yDZ3+JUX+GM6l/jnpJ/Ink LvXP0ENSf0av2Oo+3Fj9M/SN1b9EjTz3H/ey+jM8Wf1LiS+0RmH1X0iu+ufoA6t/jnpZ/Wv48+wP Z4Y/W5Lv75TFU/3zjQzSPDEYKcz856ia9h5CHFP5MWQ+MZm9d1//zjiMyJLnH0HZ12UKZW5kc3Ry ZWFtCmVuZG9iagoKMTE0IDAgb2JqCjw8L1R5cGUvRm9udC9TdWJ0eXBlL1RydWVUeXBlL0Jhc2VG b250L0RBQUFBQStMaWJlcmF0aW9uU2VyaWYtSXRhbGljCi9GaXJzdENoYXIgMAovTGFzdENoYXIg NDYKL1dpZHRoc1szNjUgODMzIDUwMCA1MDAgMzg5IDQ0MyA3MjIgMjUwIDUwMCAyNzcgMjc3IDUw MCA1MDAgNDQzIDM4OSA1MDAKMzg5IDUwMCA0NDMgMjc3IDUwMCA0NDMgNTAwIDQ0MyA0NDMgMzg5 IDI3NyAyNTAgNjEwIDUwMCA1MDAgMzMzCjUwMCA1MDAgMjc3IDI3NyAyNTAgNTAwIDMzMyA1NTYg NjY2IDcyMiA1MDAgNDE5IDU1NiA1NTYgNjY2IF0KL0ZvbnREZXNjcmlwdG9yIDExMiAwIFIKL1Rv VW5pY29kZSAxMTMgMCBSCj4+CmVuZG9iagoKMTE1IDAgb2JqCjw8L0xlbmd0aCAxMTYgMCBSL0Zp bHRlci9GbGF0ZURlY29kZS9MZW5ndGgxIDI1OTY4Pj4Kc3RyZWFtCnic7bwLeFTHlTBYp+refj9u vx9X/VLrSmq1pJbUeiAa0EXo0byEEAKEQEgCSSAwSEgyBjsJcoLBgB1IQog9HseMhzgkxqHBjI3j OBCH+J+MQ8xMsGdi7JhkPPknv00gGccbG6u1VbdbCBzP/Lv77/ftt/ttS9236tSpU1WnTp1HVXWP jdzdjwxoHBEkr9/SOzwvZJ6DEPoZQmBdv30seFTeHKbpqwhh1cDwhi2F8Su/R4j8O0JqfsNdOwfu afvDcwjpbiC0ePfG/t4+p4wrEeoYozSqN1LAgfRONc2foPm8jVvGdjzl/jxNdlyiNO13Da3vbfnr ivsQWvUuBT60pXfH8Dv8CwShzmGaD27t3dL/b/m/p+13HkJIMzw8NDr2Y5Q3idB6xMqHR/qH7zr1 cB/NB2n/FlMY0D/2MtCkiuUx4XiVWqc3GE1mwWK12R1Ol9sr5vgCwVBuWMoviBRFi0tKY2XlFfHK quqaGbUzE7Nmz6mT59bPa0D/73/xDyMHGuJnI3P2844XOYE86DRCk++z3PRnetHkx/939kKjfIIV Qugn6COIA0afAxvqRH1oCH0O7Yf47diQgEW07PPoLVq+FT0M6s+mCiHIByOl0KngfR5dRL/5TMRt 6Ifoxp1tUNgRdAydYHBoorQOw49hEfRRGozyIvqx5rNI4U304yB976CfWzBkodfpivkXtAb/EL+L DqHvZftnQu8DFSJYSHv4fJbAQrTsL4iepb3QoQ1oJ9pDaysvfvYnbyLt5H9QWgvQjyhgProPPXyr xp9BaYPo0OQt2MpbfezDB8AG+eib6M+ogbfAGYTkxlUdy9uXtS1tXdKyeNHCBfOTzU2NDfPq58p1 c2bPSsysnVFTXVVeFistKS4syJfywrmhgNtuEcwmo16n1ahVPEfoaIsbw009wVR+T4rLDyeTJSwf 7qWA3tsAPakgBTXdiZMK9ihowTsxZYo58ClMOYMp38IEITgLzSopDjaGg6mLDeHgWehc2kHTDzeE VwVT15T0YiXN5SsZI82EQrRGsNG9sSGYgp5gY6pp+8b9jT0NlN4pvW5eeF6/rqQYndLpaVJPU6nC 8PApKJwDSgIXNs48hZHGyJpNEamxty/VurSjsUEMhVaVFM9PmcINShGap5BMqeal1ArJ4CDrOjoQ PFV8fv9DZwW0ridq6Av39a7pSJFeWnc/ady/f2/KEk1Fwg2pyL3vuunI+1PF4YbGVJRRXdh2q52F 001CipeEcHD/nxAdTvja+3dCerMQlST8CbFkE2Xv/v1N4WDT/p79vWcnx9eFg0J4/ymDYf9wI+Uw au2gtc5Ofv+AmGp6aFVK6NkIM7ODbWpbmLItXd2RwlJTcGMvhdD/unBohhiyrJrCaf3PihFlBGUH 5WkoxAZ+4KyM1tFManxpRyYfROvE00iORVelcA8rOT9V4ljOSsanSm5V7wnT2Vy4rGN/ipPm94Ub KY8P9KbG11F52sSmIiykTB+KofB+qyVYG1ul4AZpr+b3DQZTfD5lC611ewUqKazKfkHJmD7MPK6J tIF8izVYG6ZkGJ3GcGNP9n/7RjclECwpTiWjmalv70jJDTQh92bnqPFUWYzW6O2hUzTYoExfKhYe TtnD9bfmk3WrcXBZh1IlWy1ln5dCPeuztVKxxgbWcrBxf09DpguMVnhpxwsoPnn1VGVQfDaOKtGq BobsnEflKr9xf0ffQCrQI/bRlTYQ7BBDKXkVneBV4Y7+VUzQKIciV2lzIaXFFJ7X3rFwWXjh0s6O GdmOZAoYOU5q/BSZcIeYIUNFLqWRNMEOLJJVFFGggGATTYTrZ9HPlFrS0LdAGa5AmajWzwp2gIim sGk3UpFgY39DFo/l7yDKM3Gal5yipmJZSmdeUgytCmVeJcWYFgezDdMaGsbU5FQRkagmoDBMySgg xks3k/lgR7g/vCq8MZiSWzvY2Bh7FC5nmaHwPDtX7XfkbmMWZRMK0eKpDGNmqikq3s7cVLOSv5VN fqp4/lRxcL8mvHDZfkY8nCWIaM/npxATYXmGRVRWP1vP4aZeuojpilbW8/5TsszW8ka2bPeH5/ft Dy/rmKVgUw3yefFe1pYVLYSF7fUlxVSZ1Z8Kw4NLT8nw4LLOjhcE6kI92N5xGgOe11O/6lQeLet4 IUhthQLFDMqALBNkGUapjWY0Cr74gozQuFLKKQAlv/4sIAWmmYIBWn8WZ2DCFAxTGJeByQqMvegs uTdSHlP93RjsY/PzuVUb9/esYjKOnJQj9B9SEJ5DuROecwqwypDShfvrU/pwPYPXMXhdBq5icDWV DHBCSfG9+4XG8J/cJYpxRA3MQvLLqcerRqWnAMVmnVZz6FrFKRX/1qzTBNMkOkUYmGfg02oVfDLr NDB43BKySCFLqAEH03nwSHojv/zjpxs45jMAaqR0/4X6WHo0Ty5BnTxvMF41QtBYZpSNw8bzRn7c mKIP0m0EBsJ6VbeGIL6bWFHdtQr6D11dXdtGLNba2LXyMsnlCFXVWAqqQg41Lj4xseXECfy1E33e BQu83N3i/Pmi0mYNQlw7+QkKou+/gDSTl2SfVkg+avqO6QUTMQUNQtLE6UGrb+YEu4C9wtnJ8/J6 nTEpCLl5ubA6F7hcey6uHcvdnXsh93Iu15oLuCxXzsWtuT25qdyruTdy+UAuDOcepbnzuVwsFyo9 DR7sQa5mlCPknM+5lMPl+FoCZpegz2nxOkwOexviBVQXv1ZHR1RBhwWxLppgQ9s20j0yspYm6Aij a7uure2KR7vKy6Iwh8Qr/NhhyQy5Mj+cq7bcGj6cDixo6yip7WnMX5suaW+uX7RoRbpkzRrYQjqF /KDDX79p4cR33fX1bhxrX5s7MVdJ/tldz/gTmnwf/w13PxLRSrl2I4GZZAHpJERPRBIlBDmh1QlO p0Fo1o7zQDvOB/lLPMfzOT6VeYleazC7bEuRk85PvC5+8VqFxQq1sa5tcTog+igvo6Pic0txlSVc VQdxR9wRttid8YrqGoeJwHMLNzcE7/vK3UdeeaW6OHeez1Q9t9meV7cyjjfPLXj99Y0T355br1Mt 19nNOkUumyavkQ7yY+RDhWiL3HKPZ68Hb9fv0WNzXiAPC8IhFaiagnlleXLe0bxU3vk8VV5eUayo rqi7aKhoV9HJonNFrxVdL9KG1c2XRBBVS/LykMW41On0L0F0Rq7VTVxkoqXMRxdNdV3roqNggwDK fR+EHHY/znY+zEZVWe3KNWFHvLIUw++X7VkbT9v05f2rEsNxV9OyNSU7T2yp+MU/5JWKujd5WyH5 cWHv3+xsE+bd1z3Dql9synEY5S+c3fHhH/uLFm2dN2/roqKsvJJe8g/IjR6XbR4naJzgsYHGBrzg EDDRnJ28IRu1hqRmt/qyGqvVXi8T2bzyymSPF7Dglb2tXtLjHfYe8qa8572XvCpkbkZ2wY7tFPFZ X26SPWW31Zm0O1rcZrO9xeowoUktaGX1uIqywXvRe7GLyaUimtEoY8a27m1RC2VInApjdxd7UZFM gCVcQMd/uyhe9C5evaGqekYi1LKo2fuNiZ/fey8cwL/ztTSVpb/zBUEMCRM/mRa/yUkUmPzv3Cy+ 05rPQiCLGmnRr+lcu+jqB58lH4OmutjglSBaVYXYW1nTSh0ameWg0/KXZriSLjzDmXTiDs1GzQ4N malZoMFEq/FoIhrCeUDraUacHXR2u8+f54fVfuD8dB5rx/y7/Rf8l/1cq58yzl/ml/2k1d/jT/mv +m/4+YAfhv1Hae68n4v5wdx8XTepw0gn6LDO05LjcOhbXCazlS5mp7KY4xl+dVGhuW0hM11FVzFd yVSMFM5JWdlh7FLWgsI4xkL8o+l1DLuUZQz3rEl/rW1qEeMV7vqJe+gSxufc9Z98j3IQoypuE76b 70Q2VIBr5CXm3Xx4t9bj8WC9x1MYqY40RTAXsUfyIuTmG5HfRj6MkGMR2B7ZEzkSIbURyI+APQLP RV6hZWR35HDkWISsiAxEtkdIXgQiTFQm//mtJIOfiRAG3xMhlRFQRZyR/Ah59aMIvBuBNyLgiUQi tZGdkX2RRyMqfQRoQYbOc5Qyr414IvjDCOyLfCfyQoYOZrBIhDzCID+NkAORxyI4Q4UwwC8j5LHI 0ww0PzJICXNGheirkSuR9yLk8cgzkZciZHPkvsiBCJkdWRzpipBAJMbIwkaGcjNCGMrFCGEoj0UI Q9kSIXURiLLuQmS8vSPJuvudCFkdYZQoCrD2sT4iRvDNCLwduRbB8o6fRuDFCDBEnG2wlnZqVYQw vGiEzJiIADwdeTHyKm2XOxh5IoIZPEFxOTOryzpNGPxkhERkbyAZuDWQk5FzEYwPRaAusiTSHSEo Ahqd/xAy28GO6IKjRo/KEROdbVEqVvTVzQQr89rGXtGRzGvtbcCpbCaZzUS3TWVZPiOZE7+ilhQU XTYHKzbGbsKhT+Uh7SkO2WyhYo+nOGi1BovT33AXh+z2ULHbEw3aKIDbNJWxBaOe2wun8mzdFlLd 1kPXrQsPylGnKd+0wkR4ExDaAl5sNNmNJqPsEJNGo9bpcQ46dzr3OXma9DDF9clkkj7H5fIPbya3 e6DPA20eaPJQawtOT74HYw986IEznguedz3kKQ8c9sAeD4x5gNV+7p13kx9kkrLll28lj3ngiAfs njxPpYcoZIVfvJFUeeDn73rgZc8/UfvNgEsu/DTZ5skY9HyGD7QVSucNz289+IIHTnsAjrJGdnsO e0iPBxo87R5c5oE8DwgeoLrnhgcueC6zLh3NNv/lJ7+dDLIyuwd/8xLrMTztgXFlRFcojvzlryUp 6YNK30VPwoNf9bznuemhmoxR7/Mc85zxqLae8XzgwUdZnzJQ1gMV+7hMC7jVrCu0Niz0rPYc8Dzt edXDU0ZNtTtjihansLa8OsPaZeGCJCNxzEOG2RgqMzjIA++y1l71wCHKgWHPuAfXeZZ4MPIInqCH aHQ6M8A5eA0wgNuIW6hTAKaWAuo3IAeqq+i6VkuVY60F4swxiGWlWRHTaPSWmGZFVoHektnolIzT V/ct6Y2yMlYUzYj0lFCPRKPCz9dSkx3dG937+QtUrmk78SoIUxtlhrAl5IB4xRxM/RBSCKnNOTXl +bpAEr+Zbj0izq4tN1clxRIi8Vqj5jFwl3/yjtpg0f8y/c2MT0xdYyzyD1P75ENj8lL7glbdIR2+ pAOdmnNzwLkAADUzB+kST3jeH5ADrQHcEzgaSAVIIACpwPnA1QCJBeoCBwPE7AlQGVtmRqoWrRnx LcSR8XDrrnWBYj4sivtR0RXvssQvbxu5w92F25YmMyVwZkPaOtAD96dfdxfNCAZnRNzuCHsWuTun bC0kbwdTNDamZZPvc2vomHJQFB2Sc1xe6gjv0+P9KtCqmNmki1YSpGGJeCUmus1aY1KSSlAJoBKh JFhCEq0ll0pwWYlc0loyXHK0JFVyvkSNfOBrNmtA1rRqLmmIRrGVLS4UWWI2Crmt0+aSjZbay23U XtL5zLq88Tgd6tpbdjI/o4ZcpWQ2ZK0kZH0wSymdWBV+21VS01h66WcVg38ztGUIUxGkjNiQPpLe 44/Xh+OL8yPJks6+KrNoM1z/88jZLzaJ+sKSYvPv3fUfX6RsubL1a6vy3TZ8Qa/7yVS8oNpL44Va EpIX1VQ0V+Ca8uZyPFiwswDPKEgWdBSQwfyd+XhGfjK/I58USDVSs0QK8mrymvPIoGunC7s0elOS aS/sZKkVwoCwXSA0srgqT1IOrlAPqLerCdGows4w1oabCwur3M21NlDZnDbstCXyE+BJgD4BH99M wG8T8ELipwn8VAIS8vX/SC5MgDYRSdQmyC8THyXwhQQ8l4DBxM7EowmyglWMJOYnyE8Tv0vgFxPw nQQ8loB9CbgvAQMJqE1AlNX3JPA//C4BVxJwMQEUbU/iSAIzInhhYnUC17K2zpxNUsqMLt6cgK4E LFS69TvW6tus1VcS+FGKOP7XR5MKxUdoby8k3k3gI4mnEs8lyO4EbGddg/YE1CegMgH5CXkSuASc SVxIXE6Q7RQPr1PK8xPViaYEoWN+N/EBG+wriTcS5FHWM1rclxhLkCaleVp74x8ZFjAMfJgNa4/S YxXlG6bwNxh9oOzKtN+XAMqWvERlAjsVbr48Vc7Gu09hWkMCqrNsmUEp/FMC4HwCjiXOJPCBBPSw 6g2J9unuXWIDhVQCnk7AMOtTA+0iuZxgtXBrYjgxnkgluLoEoARoUFkzqhKqzlddquKqqmV3ywxz WWHYbatqkZxxR06bxigU3woI2T8LnabDwinbf7ue65629dPq8ZYSvNM5mIJmSqLT8OjIp/Gna0Sn 4MJb9PMadfyp/1pRXtbNNG6GyFQMEK9wuv4yOFWp/XBn/lPR6sqSljF/cNnqnuLatfPyWNQ6tz5v eQHPZ5LSYumOCLZ2ri2a574zjnXZHOXidNZpmWiaDiwwqp98n/ya/Ij6HFXoaXlnxAk6p9eJF9D4 1ApFVtBbRSuuJk0Ec8RO8gjx6lTNw1XjVZhN1yE2XdqqKnsNqoGFrTVUL8g1rTU9NeM1V2tUspIg ueEwigkxHGu258p0Zefm+iMtXi+qWKozO6lid/hbMmElm1jGRKbiIHatKx6Ld22jDM64YNuuxeNK oJzh6RQrC6ZiTGaxqhQuUiNWNYfY1CbiyATROHfxF9dWrk0/5bTF69sq2oYa/A2jj664t6G5ZnVR fn3pshXdO9uL5ahjVllZQ5D8yDu7b/7E4+76pDGYYytauGFW71idHZN9y1YGHHf/q9qgU6VdBNtj i2Yub6VBIdOHcbZ/Qm2ExPZPjFP7J7bv2F6wERvbP7FxAmiFZs5hd2CvY2r/xOEoyCuA1QXAFdgL aKxVsLvgQsHlAq61AHBZgVyAWwt6ClIFVwtuFPCBAhguOEpz5wu4WAFU+hv82I9ymlFICJ0PXQpx odwWCeU4hFBLwGFzeNp43f/Z/RNqKdX/9R7KGaC2I7CwfdVf7KNQe0I+NEeKI+b/dDOF+yUVOkD2 dBN5n/q3YRyS/R4zdYYgX1etw/naai1eqd6gxrzaocYNPPA0jH+ORvEN1HNgEf08mnYCJBE41aBW q2gwrFZBm2oxJUr9Cq3JY8ImNYWCFlGdYhSMWGeUtF6PN+IlBuL1eFSgxGoGcxJUUr7UJO2RXpF4 p5JcIQ3Q7FMU8FtJq6KANyTyixXSEfbUShEJfyTBexK8IP1Uwk9LsFPaJ+HNEsyXVkk4KoFW8kiY lv9U+qWEH5OelrCCsVraLOGIVCvNl4jIsODJ30kfSfiKBN+RGC3ymAQD0nbaNJHkrx1J6iX4pcRQ yEWJxkvSixI+KAFtaIkE2CzFJOVjiTQkHZROSq9J1yXNSECqk7qlXdIT0jnpHUk9nZyUVJLcP5xk HooskZpxCZAUlF0sQxNSjzQuHZXOS1elG5JGrfgvTl9hkjIxz9/qteUYNSpo0es4YqailFG6bJXS JFDJ2aYoy21ruzJuJ/3IKMVPa1dFXTL0WDROV3X32i7hFaoqLbV0ccfjXXsF6pJeEPZqzpeXIebZ TWtPHpSNSzHzgMxiL6iKu/yKk1oDP08/WA+/Hn77J1sh3pB+OFi/dGNjTkSSnLOiprAnMrsi6vaR ISp93ok/Yx192j8Zantow0wqY/wfv6A3FDV3V7GzfurjsVNsE0rLc2YYYIYeFHGU1FVs+8ilxpKq SoXVKpcKd2DYCDsAE9BAGyZ4sVZj12o1OuTUPqXFWurBPGuyJBHjZZJ6NoQ6w1pCeM50wYR1JuEx 4UXhikA4IU9oEPqE3QLPZRPHKBPeFdQ1lTR9gWHYKXiMYSgbrvk08LgpAMPCPQJgJAQFWWgVODWv 0yDSYuDNWsDMb4zXKTMFVG12KxEtY/424QJlt6t2dswdY/tVljjl+97oBYgzkzX10kL4dpaTH6Qf 3Jm+h7H4D7+kLCYrPjlCBhR2/jv20mdW9w1T3efBP5AXqm2gtrqsBVZC1YalwEIGjVCgAZ3Gq8H6 RvVyNf4WQLN6JeWqyaxSm1Rmk3o+rKJBkVqI8aDiVbygNYKBGLVszPdSBmpFuwgqEdIfiPCG+FsR nxHhSRF2i4dFvEIcELeLpEEEp1gt4lfEN8QPRUIR8mm2SdwjPiXyl8V3xQ9E8pT4nPiKSA6LsJ3C cYPYLvaJRMWq/fxR8Tvi78SPRI5VwlrRI2KRNT/j2eeSteJ8EWd6wMjjVeKg+KhIEuJChhkR8aO/ pDXxngz5MREGRBBZoPiF/Q8nVaJTxB+JcITV3KmUtbPO0VZ+S3uKL4vwsgi0v6ynmFauFtmQiIcR pi1u/FCEYyKwkRwRiV3MEytZn4G19aEymIHMYJQB0/4AGwb+p2wXDtTNS24XYZ0IIIutIuYyBGoY Q/Al1vAFER8QYViEPlpFTIgYiUD5fFWEw+Ix8bJIhsVxEeNWsUfEdSIgpWiJOCTuEg+KHBIFsUwk ajMSmpFDcJx3XHJwDofX2eJBglHjaEFmTm9zgKqFMyuhW9xaW5sxR0qgS5NrM1qi+3YvbK3izUXv cM4+7ctNu19dWT9t7a3i2+gIr0QrqL6x1NbGYl3WWhYoWqyotnYvfz6jbbZ1rZ2SfCbwNEZXrB1R O263ekN9MHDXVZjXnp5V84PRrnRkFbV38GM45Kqvd74/8Udm3mB+60e3zNz/v/962/6rsqeFncq+ QLccfhTDo5TNd+wE6PSyvlWPe/RH9Sk90bPF5yuvTAb0kNKf11/Vk5i+Tn9QT1QtGnTbTgAoG37Z fQDa95GR2zYATmYD/s7pWWHzws5HOmnsWoBq5dD2HNhuALvNVhA5GXktcj1CAs067xLZNm4WCvKW Mq5NvFLn/Zn3GnNJhZ9XxBQvVJp2O5lvbwkXlBK2gTJ19EE63XMXtxXu+eGOGQt2He9a8Wh9skgI 5EVzChYk8lwzB1rm7iquteXYdPO+8NzY/S/uqHWY0v/jWwaLni/p+mpf+/51VYKR9VXZT6EypEVd 8uzbt1DOZ46ZLvFX2TGTXndrhySlhx49UL6dZ6yDg3qo00NMD1NrI8O37AFUduvkjm2TM7dzber8 a87k+/g9yrMEekau6p8JK2YCN9M+M28m0YW8oaIQ0fm8viIf4bEDS5h0VG+sxk0iRAplwZ4sLERJ 5vI+6/EpT3mG1kld38Bs82yIzT45G8+WjULSoNdXJM0BGArsCuBAhYOPtciR8TzB2iKPGw4ZsGGc TYb3Z13ea8p8UE2i7ItQhyKakeBo9FoF9TDYsu6CbJyQ3fwpsFCXgXq21VWVNFNKpibOkZk4FZs3 ioDfK+n6cm/ZuvY6Y32+ubh6Tmjlck/1spllPQtjVWs+19z0cH190FhYXu1JNvpql1bVrJtfBEUL trcVGywWOiO7zT63aeHMYGle0GouSW5a3LCxWbLq/7DV6LbqE/FQaZ5fsMSa1ylnOnPSnYyn1nzk QsiiQp65CJleQDD58Zm6pQHETnMUeb2P4gVQLfKgDS8gF/UutJakje2TlBgcSbMxYIwZidkcMMfM xGg2monuSw5EBIKJsVXoEbAg0/BDEMyM8TqrN2lWkzLm8cS6Ki7GopRr2y5SPr7F+ElVJIsDopCb X1DFPCzKrvyCmrjaT5QNbjG/Izd3kScemdMYH3JFGsrFwqbudKdg7tTqKvKKY/yPt6rckZkFFQsr vMq1MlSdnkXe50Q0A81Hy9E1+dvRathZtq8MdxRDpLi2eH4x0RV7i/H2/D35WGV32vPtRMt5uAhH IgBeAD3AsmYszjAbvIjDyCpYsbV5cV4tls225MHFkFwMwcVli3FrLaBaoTZYS/CMxbW1i2dgbmVw Jcw2ywEZy8n40VIo9SKzgVO7liyIl82CWSHzgsCC2ALyTghaQz0hvCC0IKRubI3ktC5RZ+LRjNGg NuRiV4VwjbpOwE4auiq2WV20gBaNMOdKuChcY34Ve04HqEz28qdOB1w1LhbqK7KYX0C5mYAK59S+ JEOqoRIJNNYKmSCjQeZgUJiviCYNeU7X3vX4+mB9bbHu1+GRQGDG5sf7C9sCbrAHi71XvnW6fMdP Hxl5ckO5WDY331peHMDP189O/zgSs1eualwysiCcfntB/dyFjXVzYPXCN1t3thWp1FoyFH0yf9Oc pfe1F6n5ReYcl2n8wTlfGJDDs1qLfRWlUac6FG+IpF+KlfkXRFyleS5KHA+Mjo5u2UI/EEZe6jMH qU4XUBH6K7lgRx7sCcLuALgCBQHMB+ABAigXtLnNiKIE0TAaR7xVcYvLaeiLUDEqBlQsFAeLSaK1 +FIxLiuWi1uLh4uPFqeKzxerHdpmcxFcL5oswkXKkYTWlCwyLClwuvlWn2BpsSFlluLK+auiy6Y3 SDOWLDMNdMUreyuZkEHZILWrpuLc7Jzgm96K+aX5nb7g8sLqBTH7xC6qAXneObt5QXjwcHdx7cgz Yz1/egD+MLBvWdhimSjXaKoH/4p82zU3/W1pY5k1x6GvHUvtGHlp36ICH+NNehEXpPoyQDX4k3LE 7QO3l6puuwvv0QNH/1W7VRhpQKtpRkEhGAwOB8eDvDXIxllCuRMMxlAM2L5JMEa5E7sUw2UxOdYa G44djaVi52PqCHI2X1fcvPOyi3JGzGnxm0Vni1uMtgpGp9R6225Z9oxaif8/m0fKFtUUM/zEB7dt o2fZx7ZS4FFnVd2i0gvn4pueHKreOAMIwP6J6wMb4PPQl1NWF46vDC3t6FxBPsd2kn/755EXH5hv NOnzoxHzRcUIn3DXpyu3fGV52ClMJByvKHpQ0RH831I96FXOtv3oO1R3OM6QFZZ8cnby/TOr+0vz FG3IFCKgAq4H38//LbKhEjlHZXVa861Eiz04golZ5k38uPagmTIeMxV3zXuRhkHenym3E5gdiGcD x7iJQPvi4QUS9FsGlhbOLQ/r+3HegmGup3zF9qZlDebwzGjT9hXllMzxyX+F/yDn2dkxuusFJE3e eFZwJENsQ8JEE6JAP1zsw3I2U2RkRYU0oWZQwj7C5iMeZq0xz0cK7Y/5Bd1jyHY0Aoci1FBllI1i kal7xhRw5sV/6oCRfPrAcXF4NjtsnB0OzyrxektmhT+V9zFY7myWnp3LYPgrGawSj6ckg0X5GUZI 5eJnIxFtluca7Hq7aMd2SyeNZ8Hp9GHk6/Fh2dfqO+pL+Ti1yNFwDItaTyd292i1WNBrSLeRJx6n BXfbkRXVVWR3Cehn5p4IEztLPGOj6QgzHkd86lKSJZR9ZkSO+Zhh5Y4SzjuBv/7MMxObT0y8dWLq tlJagBvsefMAu8GEXRO/8y6gc9Qy+T45TdebBUlon1y6T4C9BiB7NfAgAQ7ZEdaiZs5qt+ZZid5q LeCUjTZSxzbbcAFzTWpnJ9lTLiqMJq8W0OC6QC7oKThfcKmAf6IA5ALIaZZ1rbpLOqJzLTELoSXM GckczTBPujtzSKe40dl11T3tfWS9DV5ZSlNO4hxMTpdv+vb2oScHKyo2fWv0nX9MXzEEZ5QUV/t0 Ol91ccmMoAGu7Dj7hbnyF17Ycc/zn5M/+kPvV9eVla37au+6r/VVVPR9TTlzm7yeXoQjVA/bUBR9 QQ76cwrQ9LGbNwLaCETszagAUnQ0ymhlQSskCwqK2SHV+ZKrJbiEAf0mS9LMB6iMLjOjwiVRc26r jHyCL+gjvnGPyK68MN9LOX2b8riY/9XVxY7ehJ9Ryb1zwH5Mshrl1oaNEk/giLtoRiB7whYM0Kdm zqYvt5Z0SnJUZ7c5i0L2p+C/cR/cjkGfH7+y6Rs9xTrNr0c0enFWbzM5mFvP9IdyX051heoPUPRH HpoBLcgm60Hk8wEZnARuaQ+mP17iOuGGwi+XbNAtQMx3wuZlPDMnXcDuzNk+dXT40qcPDFnfPnVO mFlHEbqOPFAl/zLpYhJ4j36vHu/TgEYD+9SwWr1ZfZ+a1Krnq3GRGjxqUHGg3Umgj0ATgZVOIC6s UUObFqs7OWLnOEI0WqwlGqylgwGsI5gD4DDhdBwPDl48I4JeFMWFIomKB8QXxZsipyzPCyy+Xyiu FnElw4BavRilwf19FOkxivaq+B5F1bGq+FXxCl3Ock4wmaItBEW2TzAuHhV5p1bXacYuh9Dt1Bo9 VqLjzN1qoxUpK/tWIJ9Z3ezIY9tUMD4ywnb3LBkfiW3f03BbYPH2XiGqiQoXLGzHCXUrLvra2/0l h1rL7A7ctuFM1QI12PxLx9KNuOXz6QVp/diPJjqoejj8DF5/Hz97vje9c8Iizsd7+tL1TC9w273z 53snfoVzvfPpnByjTugRPol0qFIOoq0HM1GTzLfSqEml1SC1wLb3tCrEjxF3ZoeCqihrrRIh3wqL 1FVSHD/zuwnTv/93uPfLW90rVrjJfyxa/iuk2K++yff511XHqfwVZu5mwUUqfy7ZSHAhn08wP7fG 7r/jbhbO1OEXKTalSS69Jx/GJNgRhHtpOOoE/+pMAK+LxCJ1EYxWm+0BqpP57rDN3O3hphXPVNib CXUyWqUqq2X4Smt1XryCc1oddqziwrl5+RhSue0Pb9r0UHtubvtDmzY93J6bPrPmNJDjTwI+09Nz Jp1+8sl0+u968NGH3nqktfWRtx468ObhlpbDbx44Dfh4a+vxdPr06fTN7y5b9l3g2TjsNBg/S/lr por/nHxvUt2hxitVkK9qUmFOZVdhi8ksmM0cL1iNBsHQYQAVlW+DoBIMnWqVXa1WLRQACYKAlang 6IfApF5jF+xBu2xvtY/bD9lTdnWZfZgmj9ov2a/aVcRo6rFaLCDwnNmg5rp1kBVLRS5j7DYQjQwt 8Rh11D1su5OyhwqfgH60l6cCCF3C3vPnqRha4u7YXrYPpESLEptrCGX3f0IESAhOpDf2wduQC1cG Jp5+bHxi4j64/204M59J2rs3c5jEwer0tzjvxElFt2yhPnEOndcEOi4XcjF7DFeWQLwY7MXAF4PX ClordAqbBEwCftlgTvr95WsNyq0BvSWJKIcwNhhmO2Kz62YvmU39Z1S4FjnAscowaMANhWOFuws/ KOQMhW519xcBxgAaAWoAoNoW7l4ZgICbyka8i/p8bDwsoqNiQSUkHruonKLRZcoi5Iu3lh972TKR sSI4qqrKaiVgYRsakLVVqik1WLClo8Qht66OtWxtCMzuH9873j/7D/9e3t/Tkb+qpHiktaF3Ts6c vvv33t83Z8a9P9w7d3x0XS489s/uSNAanrOyclbLjGjZnO4H1596QW0QNOkfnQ0WiWUNRdXJyqLy uu4He9d9c2iWwe410jWl2HPlvmMoe9/xu5S/nucIzqdOIT47OXmmrkqHbltVgDqpn/YUxOiaqpNz tlv2WPB24x4j3qnep8Y7yT6CzUeG+XFq3hi/9dTJ5nmHnflhKOt9RafW0qcdL6rbsw5W1pn6C8cq q//VbVT/u6FYfv2LBhg1QJ8B7DzwPNg54DnYB7ADoJnOF0ABwEa0A+FVCJoQFKAahHkE/UYAI4I2 k9HU5UZ2N3K7rZ0dRiAqo9OItS6j0aXxeuX21cknvCe957wE13mXeHHQC2ZvwBvzvuZ9x8vPiCll r3k5s3fIe9DLUFnBda/GK8+uT17yXvXe8BJWQCOVoJfdg+XUVPRIFw1JNGPG3UZsVFm03W6TAeuJ y0o03Q5AKuttZ0BKwlqriFdFLL52+piB3YGlkseOGdjxAxW+veyYIaP1b0nd9CsUhml9r4VpT5CM 1KQtZ9LMGTTDLtiLvSdOTPSf4bbc/N+mNP0nXyYj87039yt5LZ2DINVHNXQOHKhbrtd0aw9S82nr xMZWw7jhqOGGgTMIGDB2upBLcJW5ZBcXpB+trmHXuOuQ67zrhktjJT1GrY7YcDfKXKhnI4Ws9/pW 10Vhgn6Ul7EeZg6bqcvKVkuUDQOqX49/6a8kcTXvWiNKz2wvf512bMig+QjuSe/7SKO7+TVxPtOb 6/F/Jy/xbdTnrkEtcmkkChEz6B9B3zDz56iEWgseyfmGOXQuhEOBUigtrZ1REI/rXcdzVY+HeE7R de9WVLCtbBY0XOiauPYr9qHsfDHnhV29piuXm1q50mfA1peue2xLbUvM4cotzHV5orNypeaaXHj5 M8HkePP9W1f61ljKqyttDq/DESjNC1bkWj3lydh/WkLHuZiO81h2nO1yRX4U8jPjRHxqapwolKLj fK0UhFtDdeWGVI/zx/UuNtYPrsXZULOD/dRolTPrqjmEKi9uasnynwEjx0p6/2pL7WI2roJcl7s4 EZaaqkNpuXTdX4BrcrmDzeNbVvq6LOVVbFBOe1AZlMVTkSz7T0uYDsij8neUyp8d9LJ2gwmWm+42 YRoP/ll+kHrXdxvAaRgwYLUB7taDUz+gx2o9aInJzFa8uceO7HY7MhmhzdipUds1GrVRo9cmtPdp X9Te1PJatdnO2S7YsA11cmrQqdUOp+hc7cQLnfc5n3a+5+Tszjwn5pwNzjHnGee7Tj4hOiHh3EwL rzi5q064TEM6pv0kiz057KRRjrPMKTt7nNyAGuxmo6ZbjUyEs+gIqLq5rPRTG8qWPF253cqRjLLI R7L3Yn/eVVEhsI/MGe5ed8bFY5cKs65dlE1SdkVnThYzBy1qcvD1Ce/r6Y3fwKfPQAUUHoO//zIW 0u2KTX0KX1L8uJ/jCvZUbOsK6ssdp7Y1F/XLssYCD+phQAXNqpUqXK0Cqy0317tVK1/XTmox0gpa bNPatHmhMizjVnwIc1gbso6bRl1qHLoHmK9XW3fN+zPF1Ytn9z69AtVllqlrJhGomsNnvCllmc+B zB4Jpw6R4598b8VX71kzOxisaiqYsyAQXdn6aOfb7+XPv+vhE334qy+t+crnt+3c3zF79Wy/1/sy lFs9zx1vvX/krh0PrVLGYqZK4If8kygMJ+TJ5lxoDgEfAI3KraLuvl6CyZsSnJEuSFiUDkiPScQs wbvSBxK+T2I3C0i7BAkpczfgMEsulDAn2SX881elmxI+Jp2RsJ5WxO9KoNxEaJf6GCl2feGCdJld X8jUjErAUZRXpSvSexI5LB1jNxlWS/fRupxC8Lo0yUhtzoCitKHHKO5NiQ9IQLs5+EGm9dXs7kJP XzImActsVjrNS3J7R7JOubUQkLqlIWmXdFJS1V6XQJIb5ycvSXCOXUd49pCElZsH9dHS5GuswaMS 7JKA3U24wYYeoH0XBbPX7G8ml8IQDuf5wy0hB/ItIV6zvVU2CwEhJhBhXAtTBwTKMVeFcsbItiNi caY5sueELFDvZqdG0cyZYea8cPr08PZr4dmi8rJu5datLVxVc2tT1zHlI/mAfWFHEfHHv/zlyt6H VzljJfkm2acNuJyS13zu3KMTVwdIQ2NB//qvr68gvJq7ukVrFmf3Nu3bOOFkG2NMJvKp7jjJ9mFw Wp5c5R307vQSrWfQs9NDtO5B9043+bYDPEJEwB5zxIxXUE2y3UBUVIts1xOVbkC3XUe0O9SPqLEK OzFWAV3gOjuyGXmTwWEQkU3Fm9RetZ2mkF20ISPNG1UmaKP5Ht5k5yketHnV3k6Hwe5wGDQO9oUa tRrUPAjEoFZrTDab1SpTRaaxaqwc4nmO6nun76c+eNr3og8/6oMDPhj07fThhG+hb7WPRHwg+sDo g4984Bu/9ofk4z7Y6YPNPoj45vtW+YjW5/Flkjt9+3wvUFIf+XS/+J1P/in45J/9Y/IKrSdf+Pvk 55VKXT5Y6IPZPshUIz75+e8nH/M97cP7GP0TzyYnfPA7H9BaF31AIce+ndzsu8+Hu33AeoQDvpgP 633w1zd98I7vug+/6oOTvnM+fMD3mA8P+Xb58Gof1PmW+HDUB2ZfwIfHfId9x3xnfJd97/pUPT6o 9DX42n0k6APOZ/fhG+yZgXF3HaNYH/gIy/b5WMUzPpWP7S6N3ptUnl3rlafs7VidDE7XHPPt9qkS F2hdrBQnGxfRfkM76zW86HvV957vpo9j7VVSwhxtE7ONmTKf7Bv2jSsbc+d9V306jc1kUHcLWuJ1 IL7bTaajIiVUZ+6YItFsBWyLRhWHretT9x8z6yDz9aXorQuQ0Uyd6Wvn7CW8Qu1yjFlmpj6jio2m fxnNn7lcwgwCfWQP3Ke3AthlH032kxqLtXdsBWSi7qyZsE0ZDQUIsOCpdPVhOJke/wZ++Lv/A3xP wauH01+D5x+ZGP1u+ld9zHrgPNzGrEb6CGxSnuUTqxSrcu7/U7E3jTf4X7L9Jqo5dsvLdubty8OD HujKfn0h6d7oxmZHwIFX2aHZDh6H3THh9tjdbo/baQ95O81mcBaWFV4qxCHoVHnsqCcU4oI96m4t cVD77+am9nqusSuZ1zJ7PV3CTzJ3NDPXh5TvD9zawJn247OBk5rNmpYdIVDvmDEI609M7HziBL7/ +G8enJlTt2ERDHwl3ZLeD+pg09bFD31lyZZ5PjwjXTzl4Nes37+sbqRngSstiPPxDHiodcMs98Q/ BxvvyuzlUR5w91Me5KB/k592i2tSXvB6wbDGrI/psVbvT/kv+XHAH/PX+bv9u/z8Sf87fiz4g/4y /7D/kJ+/4QezP0BLz/m5mtf81/3YL8+Wk2X+Vlo+TquzCxZmWp/Vfo1WnvSrr9MPrBA+6QdEacn+ HoWaSu2kjAy6we1GPU5RjDm7nUNO4nSqHD3aIQMYDIy3064VDY26hGvKpniMeR5s87EiY3kyazSz mfartV3XMt9zoLyeZjELOrhcytdQTZymse6dieYnTnBr1wYdcxcuaZ5p3gnNgVWrAnhWunCKnelv XCMcB3jiynfTs05Q/onpH8NpKKEyVCHn3HLNgR+2jlux1Sp6FTfc8ZgXCR9UfHBtOt5gzrd0h5+t bBzA6RIWPlB/2kn9aWdnY35zTWhT864tSoRAXWa76HBQl3luA3WYaZzflO5kdzFonO9Q4nwPepzO q/458EZn66aOwGk/NdT3+xM5QW3jsDzJO6ucjc7lTo53VDkaHcsdXJENdlgftGKdpcgy07LAwumE ImGmsEDgdBp20aZTw+nUM9UL1J1qTuLhHhqNE4lUkUbC8VjCVbgRc7xHZbDrjZzR61HZ7Ozis4E+ 7DzNIk7gsNkasGKtCtoosMWjsns8Kiu0cUZusWi1i6JVpecNtLJNtFoXGKnN44ZFEO2NHmC3e/Qe qszLfGD35fnw04pGJ4d9EGVGifPBBz7Q+6I+ZqMOUHP2nk/9LxR03nfJh5kRwZszNSt9hILl4VeZ bWBG44yP0zMSFMAymBHZ7CPHNytESMN0mwz7MDUwXCs1Huas9Qv6WqnpIDS7ndqUg74nfCd9hB31 YKWY2Rhm4BSbZFu1JjmUwcgeCtT72BWznNlzqSljlcZ9h6gZUsmKRWL2iFdsXu2sjO0rr87YvkCk NBnwAfKBx2q0t9i8Bp4DwenQqzixRQPm6Z28TODB7oNGo9ReKd90uuWdKbdNp9K3XRLLppW9h/gr 2yqEt7oq2H4Ee79ScYdVYmZnL7NFf2GPbt+fsDHz46q53QoVqLMWKgAfDu77u7UgL0v/GYo607rB Y2+uTZ9vh+L0H8nmuXPFX7zumTvXkf6HdLVj7lzXxCT9FKAH/obJ9OLJ98n3qR2agR6WK/fMgAfK QB1zxfbGSIewUdghkD0YCgqr3XohWe0tH/If9EOh1+/3FhItGjpkAxvjZq7WlLTZamfqWrWHtFhb 7blb9npNBePh0VK1aVTWjfMepFyXyQQ7Me81JeDJHN5cy1xkoErIUhu9FfdA9tCG3Dq0ofo7BlU1 c+D2aGjqxFjtB/L9+l1ntw/8sMWwpjLYXVPfIwfy5iwvGxtetdwXTxZVN9L4KC/ZsqLi7d+GGgaT J56CLasPrq90WaDxn62B4pa75GRvQiTqnRrVPTtmd87yhWw0ZtIKevWTx+u2tNfqHcfZ/l56Ed6o /A5VSLZZeHTjkh6Ynj+nJ3oBqURUV6ds22cOopiDXopp361zQPka/WZL9fple37yJVn+0k/2LFtf bYHf33v99WfrRpq/fQV8L/0AxDefah6pO/36tanzRL4NGVEItf2dIWgUkjp2sZc+VezqTYQmCIOy uw0YDQVNZSZsMoXdQ+wLXYc0RGMb1at9o4z7WYch8035zOku2LGJhg7YIljjFVb4i3PBqrue2nb5 X/7lrctvpa+YcmuKiqr8BoO/qqiohqIdO57+5NRq6IN2WAy96b9Nnzzw5pGWliNvHnjo7Ufb2h59 m/LKNflrPkXtognb5MkCIzxogJV62K7bo8MFPNRwoGyIJggUUfW7iRANAS3RUXXGc516nV2v1xlw j35Yjyd5aOSBqHjQ8ViP9TxRI6FPOCZcFshCASoF+ECAKwJcEOBpAXYLhwW8WYB2ARIC2AXQC3BT gKsCXBbgqJAS8G4BhgVgV5srlVvP/GvsGnS7sFs4o9x+/kDQmAV4THhVuCkQhjImkGimAn6PNXNZ wC8KcJj2AN8nQJ8AtBd5lBimTT3+AevFFaWVhLBZwLQHrwryIzdZirVDLtMGcIrRyzQ/ply7Vm85 LDDKJMFo0SpwRoCosFp4LHMLG7PL2u0U+XD2jrZm9jEBDijDp5iHBMBC9jL2uMAjoUzoEYZp8qhw SbgqaNTjetimhz49LNODQYf5bpOa6Alnm76qray72JRSW3t7GPqZ91/v/B7zrWuywitTF7wzN79v v+N921EbONRT17yZl82ndk18/MDEO1tx8wHYCT17+dnzxZsa7s/MbfjkK2Qos2c5AF/j/OQHyu+d FMtelYCDuBUTzIMWPxMkVEieMaufUGM1u3fxq23XQPjVBeos0MVIlSV7c/5PkuTsJ0kcPnQIHj14 kMppPV3TrcqaLpA9emS5IataVbhMJauGVVdVN1S8yoBQdmVvm7hIV7Yt43Dggio/Zt61Cerb+qot luq+tgdeYYv7lfSikbpnX79+773XXj9NV/dTb6b/7Qcvpf/1yrdpe+uov/h7tj9MiDy/Rg8qGjtj bQdsZNf59Tp9JwL2HWw9Uq3ZTgNfBDp2gVFnXaO1gc7m+q0LLrjgKddzLrzbddiFt7ugzwUupoi3 /vHDJOeCP7rgXRf8kwvOuC648JMuOOyCPS4Yc8GAC9pcUOlqcOF8V+Yu0IcK8hsMmRJlqOMuGHFB j4Iqu8DqynVVuAil+4+/cf3RhSnqyy54TmlyXDb9/avJeleba52LVCog+blzP05eyiTl4PdfSu5W yLW7+ly4nrUNUy3/MUsi78TJJO3kERfsZj3c7sJTfQy6wO4C7IK/URBnPH40+RsXXHbBadfLLnzM BV9lo9rtwutcsMIFDS6odkGeC1QupzKwC67LrnddRKlseeDB5ArXgAtPjV6BBnfuSu5xHXE95SJj Cg2lNFdpV+WCrQpSfNOW5C02XWADqHY1uVhP99CKamUwH7jgN5kG8WkXZIjblrYn6dS0svHSiZr5 QWaanl3YklSejfOVp2yZJTOONbjG2JS+68JKaVk8qVDRif4k5VowU/k5izt5KDvdfoM5WUb5w84R gi6iblaDDem7HVa1Dnq0hPn3bAeqokuJupWvYLN4eyQazQTS0dsuvEenlmZUia9v/zLidFnG+cl8 KZFF5dE7lcKdquDW/XiqEt6g4cMr0YrYG13XbovZulm8XQNTJxgOCLFbUbY4Ca3Dv73xpUekwCrO MOEA99z7BhZZE53izYMjXK9B8wtYuunm19V6PQcofY9yxzN38mPeR9eUgS7UWvQrObKh8p5KPBDf Ht8TJxti98SwWnJJBRLRFqvR6oICa/lqxH63yGpkjLxfa0gajQlzIpCIJZYkdiUOJk4m1HWJ7sRQ 4nqCY/BMZlfiicRriXcSkwndjAwuwzynQDQsy5AOUsBrtJ4mU4/VYeVqTUJubU+qrZ3+YqFHrXYF uvmeEHF1+7tzWCx2LRvj1rIILPvFpm0j2WtymXg3q0Bvi2Vtlfk05cw6SXBn4Ju5MUvdqDDZ6qpc ljjwtdlLy2z9D3zjmbJiaZGzrqPa88mSZ57BB77+9zvjJYv6atYf7Cqes/cXX9/xfh/5Y+2yGm+6 JLdu9cRrD3xx4ioGDIULNqV/kIniilqGm+fdtbTKoKtuH5q38quDCRXTz9+b/Ff4mM4DQS6oYveI /10e0pmTyE0/iO2Isike1BKnVuv2HPWkPJc8JOgp88iecc8hCrjqueHRsB8rKPP0eIY952k5Bfyj QBGGs/hXPeqpGikFX83wp7BV31R+uuGuP/05OekBho2fYL/wEPSwH0PgWmmd8x6CKP4hWpXbLFOq +KoHTrIfdjjkwUvYTy+UefB1DzBy+KAHejwQ8wDyQAJRMq1KU3yP0t0UpcErDdrCBcmAJ8Z+aQE0 yPQYZyN0/dVN/BwyEcNtO7uZec0sq0w6c45xYeKCcu85TEJ/ccnu4dE1EP36pw6A4Rh59OOn/vIU mPn1fZPvq4D69eXoTXnRdgm258GGPHg+DNsDcLcRBozsGwcbDLBdAxs0MKoC55pJBzgcqBNFheih 6KUop41G43J8OH4+TsxxEOLBeE+cxNlgW5euTJ6Mw6E4dMcBxcsoGpmRil+N34iT1+KTcYzirfHx +KE490QcWmm1YUYiEMea0GqzLqDDuvLi7tLSwpxup5kr7ObZ4XfdhcwGD/NSsx5H9pdQRkYyN9oq pre6pvbo2Bcg8kppRKDsdGWvDEx9B4JTfnpAcTD4L8w8+Fd/nXwi/eG5zRt/BLbvrjz4ua0zOt3h 9u4NVQPH7q6jkULvpsrasbITeNOXmmwht2nl0598KwXqkytN7oCQ/tn33EUBS+2+f3t67Hvjyysc Nupmsrt/Cq/p2/LeuhWPqLrNs/6EApnfh33toX9zTP2G6eT19Cx1m+qKsoeAs0BaTx1KN07/0mn2 136nX434fdRAfKiRG0U1+LsoRB5GTfRdw0hQWIC9KbyKwgpxLSqh+WWq76IaDqF6mo7Tp53L4MYV 3FpUyGgwXEp3DnvT+vdRnGpa7lXeNE1hBfR9XFWLwjTfgr87eZ31g8JeysKO0Wcfe/P/jbYxirYo eAh1qh9GYX4FCtL8evpeTMvz6HMFrWum6fxsnTD3ryhM8UXWH1quYbgUp5PRoeUu7iAaoPl6Smsd fefS9PdYXcTubA+gD2ER/BBX079W/AZXzO/nP1B9QbNOq9L+te63+t1GwXjE+JapwrTdHDRXmr8q jFtMlmOWH1g+sPZZX7E12C7Y3rJr7P/k4Bx+xxedOuf3nH/v0rj+we13f9Wj85z1+sXCnLd8su9l /zr/k/7ngsHg2eDvQy25O3KfzH0zb7eUzDfkv6zMWCNaQbXdJsTRmRVQjC4gRCa59ymMTVMOrLg1 rz235hgoZk82jWnN4WyaoCAay6Y56o8ezqZ5ZELfyaZVyI6ez6bV6F70ajatQXZozKa1yASrsmk9 7cOGW78kXQpfyqaNaAhOZdMmKgdB2jpwWpo7j9dm04CCxJ9NY6Qhc7JpgmTSlE1zqIjsyaZ5lENS 2bSKytrPsmk1+oB8kE1rUCH379m0FuXwQjatRzP44mzagNbwfdm0Ef2KP59Nm9DnVN+cNzS8c2Rw w8axYOH6SLCirKwm2NbfF0z2jhUH529dXxqce9ddQQVhNDjSP9o/sr2/rzS4aH59Y9vc9vlLWoKD o8He4NhIb1//lt6RzcGhgTvrLxpc1z/SOzY4tDW4rH9kcKB+6K6+uaPr+7f29Y8ES4KfLg6y8s8E rugfGWWQ8tKymtLKaRQFo+RT1f4nnaIj2TA4OtY/QoGDW4PLS5eVBlt7x/q3jgV7t/YF229VXDIw MLi+XwGu7x8Z66XIQ2Mbac833T0yONo3uJ61Nlp6a0DzhkaGh7L9Guvf3h9c3Ds21j86tHXj2Njw zFjsnnvuKe3NIq+nuKXrh7bE/quysZ3D/X39o4MbttLhl24c23LXItqhraO043crLdLe3M7EpqGt dKLuyuAUB0f7+4OM/CilP9DfR7s2PDK0qX/9WOnQCPXjBjcPxjL0BrduiE2TYVSy7fyv1Ubz0BBd jzvRCBpEG9BGuh6DqBCtRxH6rEBl9K+GptpQP9VFQZREvRSjmKbmo60Uq5Sm5qK76F/wNgqjSq6f Pvvpc7tSl2EuorXqqQZpo3XaaXoJaqHQQQW/V9EFI/TZR/G30OcI2kxhQ1T7/VftL6L11yntsJJB ir+Vli5TIIO0bj2F3EXrzqWtrKfQrQr9EYpTovTov64dvFX//zjmCgU2egunnPaScbEUVX4mlWka Jf+T1v7XOJWZkw0KlTGFdgZzUKG9nGIsU7BalZqMU2NKa1sVrPbPaHEJbXGA1md8ncZcr9Aeo/kM 5SGa3pjl+SZ0tzLWUYrJ6k2NbZS2/JczxGRzhErn0Kf4xXq3XWlzsQIfU2SNlW1UcsNoJrVMMXSP 8ldKce6kvD5Lt1RJbaGY/1frjdGVM6zwsV+Z8Q0UNzP7pQrNLXQ2F2U5tFVZD4xDd982xgxv/jNJ bFKemRV11x102MyyJ6s71fvRbP8HlHYyXBumn0OU7/0Kt0sV6AZljIN0Dgdp6vb+sRnbkIV9ujdT fblzPP9Ptk2y/mYI/Rh9xksu1/7malXgnfjby38Vf2t52dutb4+/nXqbexvI8reIMzD0C+j+xfVf 4CW/gLqXIfDyOy9j5u7/7Xmdsan1XM+54XPkh81FAXQWYs93P3/w+ZPPv/M8P3QTAh9f/xgPfbzr Yyx/DEN/B+YzgTN46AwEnl3y7OSz5Hsn6gPm47uO45PHYfg41B0H4ZHgI2WPkOFH4BtHcgKxr9d9 HX/lgb7AyS/DQ0sCAfRAzwP40ANw6EvwRZoV7g7ejcd6JgOj3ZOBYdr+EH1vbZ4MeOLu5eo4Wa4i kwHWz5Pp0njT+XVwtRd6uisD3bRu4JPYJ098Qk5+AmgtyGu1xqZdaw6ueWINWd0ZDcQ6AXX2dOJD nTc6caATbHHrcp6ygqM0zSRA6sgSMkQOEpVm2YJQoJWSG2rZ1XKwhSxuDgcWNAcD5iTISb25qYl2 yNwcaMY5SXG5M+5YbgHzciFuXo4BLYc4Wh4zT5qx2dxt3mVmP2KC8LgTeDgLh061L4tGF55VT7Yt TKlbV6fgwZS0jH3KSztTqgdTaHnn6o5TAF9e9cDDD6N638JUxbKOVI9v1cJUH03ILDFOE4LvlBPV rxodHct8awtGo9GxKKLv6NpRJT86djfNjY2OoWh0dFTBoW+aGQOap9DR6ChN0ZXFiIzC6BhLjKJR Wo5G2XuMwu5mtVlV91oqT/87By9AWgplbmRzdHJlYW0KZW5kb2JqCgoxMTYgMCBvYmoKMTc0MjQK ZW5kb2JqCgoxMTcgMCBvYmoKPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9CQUFBQUEr TGliZXJhdGlvblNlcmlmLUJvbGQKL0ZsYWdzIDQKL0ZvbnRCQm94Wy0xODIgLTMwMyAxMDgzIDEw MDddL0l0YWxpY0FuZ2xlIDAKL0FzY2VudCA4OTEKL0Rlc2NlbnQgLTIxNgovQ2FwSGVpZ2h0IDEw MDcKL1N0ZW1WIDgwCi9Gb250RmlsZTIgMTE1IDAgUgo+PgplbmRvYmoKCjExOCAwIG9iago8PC9M ZW5ndGggNTAxL0ZpbHRlci9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nF2Ty47aQBBF9/4KLyeLkd3V fsxICIkBLLHIQ2HyAcZuGEuDbTVmwd+nb91OImUBOt2uKk4Vrmx72B3GYcl++Kk7uiU9D2Pv3W26 +86lJ3cZxsRI2g/dEk/63V3bOclC7vFxW9z1MJ6n1SrJfoZnt8U/0qdNP53clyT77nvnh/GSPv3a HsP5eJ/nT3d145LmyXqd9u4c6nxt52/t1WWa9Xzow+NheTyHlH8B74/ZpaJnQ5Vu6t1tbjvn2/Hi klWer9NV06wTN/b/PauEKadz99H6EGpCaJ4Xr+vAolztwVa5LsAF70twyXsBV8qSg2vlZgt+YcwG /Mpcrb8ha8038g68JRvwjvwC3rOO5jbkKrDJGfMGpn8NNxP94WDoX1mw+huL+ib66736m7IB07+q wfSv0KOhf40ejfobo/H0t+jR0L+As4n+GkP/SmMaOqCO0L+Av9Bf3YT+O/Qo9C/0nvMv4Sz0bzQm zh//l9C/wDyF/iXmLPCX3GAmsiFrDP1LzFbob9GvRH+tT/8SfQnnX6AvS/8S8Ta+P4i39Bf8lqX/ HvO09K9Rx9Lfohcb/fWe/jofG/21Judv4Wz5/gicbfTHbG2cv/rQXzA3S/+i1kWIbzxWAjv7Z9XS 7u59WDNdbN0vbNYwur+7P08zsvTzGzcR/OwKZW5kc3RyZWFtCmVuZG9iagoKMTE5IDAgb2JqCjw8 L1R5cGUvRm9udC9TdWJ0eXBlL1RydWVUeXBlL0Jhc2VGb250L0JBQUFBQStMaWJlcmF0aW9uU2Vy aWYtQm9sZAovRmlyc3RDaGFyIDAKL0xhc3RDaGFyIDYyCi9XaWR0aHNbMzY1IDM4OSA1NTYgMzMz IDQ0MyA0NDMgMjUwIDU1NiA0NDMgMjc3IDU1NiA4MzMgNTAwIDU1NiA1MDAgNTAwCjU1NiA1NTYg Mjc3IDQ0MyAyNzcgMzg5IDM4OSA1MDAgNTU2IDU1NiA1MDAgMzMzIDc3NyA1MDAgMzMzIDM4OQo3 NzcgNTAwIDc3NyA3MjIgNTU2IDUwMCAyNTAgOTQzIDY2NiA1MDAgNTAwIDcyMiA1MDAgMzMzIDcy MiA3NzcKNzIyIDYxMCAyNTAgNDQzIDUwMCA1MDAgMzMzIDUwMCA3MjIgNTY5IDMzMyA2NjYgNjY2 IDMzMyA3NzcgXQovRm9udERlc2NyaXB0b3IgMTE3IDAgUgovVG9Vbmljb2RlIDExOCAwIFIKPj4K ZW5kb2JqCgoxMjAgMCBvYmoKPDwvRjEgMTE5IDAgUi9GMiAxMDkgMCBSL0YzIDExNCAwIFIKPj4K ZW5kb2JqCgoxMjEgMCBvYmoKPDwvRm9udCAxMjAgMCBSCi9YT2JqZWN0PDwvVHIxNCAxNCAwIFIv VHIxOSAxOSAwIFIvVHIyNCAyNCAwIFIvVHIyOSAyOSAwIFIvVHIzNCAzNCAwIFIvVHIzOSAzOSAw IFIvVHI0IDQgMCBSL1RyNDQgNDQgMCBSCi9UcjQ5IDQ5IDAgUi9UcjkgOSAwIFI+PgovRXh0R1N0 YXRlPDwvRUdTMTAgMTAgMCBSL0VHUzE1IDE1IDAgUi9FR1MyMCAyMCAwIFIvRUdTMjUgMjUgMCBS L0VHUzMwIDMwIDAgUi9FR1MzNSAzNSAwIFIvRUdTNDAgNDAgMCBSL0VHUzQ1IDQ1IDAgUgovRUdT NSA1IDAgUi9FR1M1MCA1MCAwIFI+PgovUHJvY1NldFsvUERGL1RleHQvSW1hZ2VDL0ltYWdlSS9J bWFnZUJdCj4+CmVuZG9iagoKMSAwIG9iago8PC9UeXBlL1BhZ2UvUGFyZW50IDEwNCAwIFIvUmVz b3VyY2VzIDEyMSAwIFIvTWVkaWFCb3hbMCAwIDQ2OCA2NjZdL0Fubm90c1sKNTEgMCBSIDc4IDAg UiA3OSAwIFIgODAgMCBSIDgxIDAgUiBdCi9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5L0NTL0Rldmlj ZVJHQi9JIHRydWU+Pi9Db250ZW50cyAyIDAgUj4+CmVuZG9iagoKNiAwIG9iago8PC9UeXBlL1Bh Z2UvUGFyZW50IDEwNCAwIFIvUmVzb3VyY2VzIDEyMSAwIFIvTWVkaWFCb3hbMCAwIDQ2OCA2NjZd L0Fubm90c1sKODIgMCBSIDgzIDAgUiA4NCAwIFIgXQovR3JvdXA8PC9TL1RyYW5zcGFyZW5jeS9D Uy9EZXZpY2VSR0IvSSB0cnVlPj4vQ29udGVudHMgNyAwIFI+PgplbmRvYmoKCjExIDAgb2JqCjw8 L1R5cGUvUGFnZS9QYXJlbnQgMTA0IDAgUi9SZXNvdXJjZXMgMTIxIDAgUi9NZWRpYUJveFswIDAg NDY4IDY2Nl0vQW5ub3RzWwo4NSAwIFIgODYgMCBSIDg3IDAgUiBdCi9Hcm91cDw8L1MvVHJhbnNw YXJlbmN5L0NTL0RldmljZVJHQi9JIHRydWU+Pi9Db250ZW50cyAxMiAwIFI+PgplbmRvYmoKCjE2 IDAgb2JqCjw8L1R5cGUvUGFnZS9QYXJlbnQgMTA0IDAgUi9SZXNvdXJjZXMgMTIxIDAgUi9NZWRp YUJveFswIDAgNDY4IDY2Nl0vQW5ub3RzWwo1MyAwIFIgODggMCBSIDg5IDAgUiA5MCAwIFIgXQov R3JvdXA8PC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0IvSSB0cnVlPj4vQ29udGVudHMgMTcg MCBSPj4KZW5kb2JqCgoyMSAwIG9iago8PC9UeXBlL1BhZ2UvUGFyZW50IDEwNCAwIFIvUmVzb3Vy Y2VzIDEyMSAwIFIvTWVkaWFCb3hbMCAwIDQ2OCA2NjZdL0Fubm90c1sKOTEgMCBSIF0KL0dyb3Vw PDwvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCL0kgdHJ1ZT4+L0NvbnRlbnRzIDIyIDAgUj4+ CmVuZG9iagoKMjYgMCBvYmoKPDwvVHlwZS9QYWdlL1BhcmVudCAxMDQgMCBSL1Jlc291cmNlcyAx MjEgMCBSL01lZGlhQm94WzAgMCA0NjggNjY2XS9Bbm5vdHNbCjkyIDAgUiA5MyAwIFIgXQovR3Jv dXA8PC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0IvSSB0cnVlPj4vQ29udGVudHMgMjcgMCBS Pj4KZW5kb2JqCgozMSAwIG9iago8PC9UeXBlL1BhZ2UvUGFyZW50IDEwNCAwIFIvUmVzb3VyY2Vz IDEyMSAwIFIvTWVkaWFCb3hbMCAwIDQ2OCA2NjZdL0Fubm90c1sKOTQgMCBSIDk1IDAgUiA5NiAw IFIgOTcgMCBSIDk4IDAgUiA5OSAwIFIgMTAwIDAgUiAxMDEgMCBSIDEwMiAwIFIgMTAzIDAgUiBd Ci9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQi9JIHRydWU+Pi9Db250ZW50cyAz MiAwIFI+PgplbmRvYmoKCjM2IDAgb2JqCjw8L1R5cGUvUGFnZS9QYXJlbnQgMTA0IDAgUi9SZXNv dXJjZXMgMTIxIDAgUi9NZWRpYUJveFswIDAgNDY4IDY2Nl0vR3JvdXA8PC9TL1RyYW5zcGFyZW5j eS9DUy9EZXZpY2VSR0IvSSB0cnVlPj4vQ29udGVudHMgMzcgMCBSPj4KZW5kb2JqCgo0MSAwIG9i ago8PC9UeXBlL1BhZ2UvUGFyZW50IDEwNCAwIFIvUmVzb3VyY2VzIDEyMSAwIFIvTWVkaWFCb3hb MCAwIDQ2OCA2NjZdL0Fubm90c1sKNTIgMCBSIDU3IDAgUiA1OCAwIFIgNTkgMCBSIDYwIDAgUiA2 MSAwIFIgNjIgMCBSIDYzIDAgUiA2NCAwIFIgNjUgMCBSIDY2IDAgUiA2NyAwIFIgNjggMCBSIDY5 IDAgUiA3MCAwIFIKNzEgMCBSIDcyIDAgUiA3MyAwIFIgNzQgMCBSIDc1IDAgUiA3NiAwIFIgNzcg MCBSIF0KL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCL0kgdHJ1ZT4+L0NvbnRl bnRzIDQyIDAgUj4+CmVuZG9iagoKNDYgMCBvYmoKPDwvVHlwZS9QYWdlL1BhcmVudCAxMDQgMCBS L1Jlc291cmNlcyAxMjEgMCBSL01lZGlhQm94WzAgMCA0NjggNjY2XS9Bbm5vdHNbCjU0IDAgUiA1 NSAwIFIgNTYgMCBSIF0KL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCL0kgdHJ1 ZT4+L0NvbnRlbnRzIDQ3IDAgUj4+CmVuZG9iagoKMTA0IDAgb2JqCjw8L1R5cGUvUGFnZXMKL1Jl c291cmNlcyAxMjEgMCBSCi9NZWRpYUJveFsgMCAwIDQ2OCA2NjYgXQovS2lkc1sgMSAwIFIgNiAw IFIgMTEgMCBSIDE2IDAgUiAyMSAwIFIgMjYgMCBSIDMxIDAgUiAzNiAwIFIgNDEgMCBSIDQ2IDAg UiBdCi9Db3VudCAxMD4+CmVuZG9iagoKNTEgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xp bmsvQm9yZGVyWzAgMCAwXS9SZWN0WzUwLjIgNTAxLjkgMTAyLjYgNTEwXS9BPDwvVHlwZS9BY3Rp b24vUy9VUkkvVVJJKG1haWx0bzp1dGt1Y2V2cmVAbWFpbC5lZ2UuZWR1LnRyKT4+Cj4+CmVuZG9i agoKNTIgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0 WzczIDg3LjMgMzc0LjkgOTguOV0vQTw8L1R5cGUvQWN0aW9uL1MvVVJJL1VSSShodHRwOi8vYWJp bGdlZ3VuZHV6LmJsb2dzcG90LmNvbS50ci8yMDE0LzAzL2Nob3Nlbi1jaXBoZXJ0ZXh0LWF0dGFj ay5odG1sKT4+Cj4+CmVuZG9iagoKNTMgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsv Qm9yZGVyWzAgMCAwXS9SZWN0WzM0MS4zIDM0NS4zIDQzMi4yIDM1Ni45XS9BPDwvVHlwZS9BY3Rp b24vUy9VUkkvVVJJKGh0dHBzOi8vbGV0c2VuY3J5cHQub3JnLyk+Pgo+PgplbmRvYmoKCjU0IDAg b2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs3MyA1NDAg MzI0LjcgNTUxLjZdL0E8PC9UeXBlL0FjdGlvbi9TL1VSSS9VUkkoaHR0cDovL2xpbmsuc3ByaW5n ZXIuY29tL2NoYXB0ZXIvMTAuMTAwNyUyRjMtNTQwLTQ1NzA4LTlfMik+Pgo+PgplbmRvYmoKCjU1 IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs3Ni4z IDU2My4xIDI5OC4yIDU3NC43XS9BPDwvVHlwZS9BY3Rpb24vUy9VUkkvVVJJKGh0dHBzOi8vd3d3 Lm5zYS5nb3YvaWEvcHJvZ3JhbXMvc3VpdGViX2NyeXB0b2dyYXBoeS8pPj4KPj4KZW5kb2JqCgo1 NiAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbNzQu NCA1ODYuMiAyMTIuMyA1OTcuOF0vQTw8L1R5cGUvQWN0aW9uL1MvVVJJL1VSSShodHRwczovL2Vu Lndpa2lwZWRpYS5vcmcvd2lraS9SQzQpPj4KPj4KZW5kb2JqCgo1NyAwIG9iago8PC9UeXBlL0Fu bm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbNzMgNjQuMiAyOTYuOCA3NS44XS9B PDwvVHlwZS9BY3Rpb24vUy9VUkkvVVJJKGh0dHBzOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL0Rp ZmZlcmVudGlhbF9jcnlwdGFuYWx5c2lzKT4+Cj4+CmVuZG9iagoKNTggMCBvYmoKPDwvVHlwZS9B bm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzczIDExMC40IDI2MS41IDEyMl0v QTw8L1R5cGUvQWN0aW9uL1MvVVJJL1VSSShodHRwczovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9M ZXR0ZXJfZnJlcXVlbmN5KT4+Cj4+CmVuZG9iagoKNTkgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0 eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzczIDEzMy41IDI5NC44IDE0NS4xXS9BPDwvVHlw ZS9BY3Rpb24vUy9VUkkvVVJJKGh0dHBzOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL1ZpZ2VuJUMz JUE4cmVfY2lwaGVyKT4+Cj4+CmVuZG9iagoKNjAgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBl L0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0Wzc0LjQgMTU2LjYgMjgzLjQgMTY4LjJdL0E8PC9UeXBl L0FjdGlvbi9TL1VSSS9VUkkoaHR0cHM6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvUG9seWFscGhh YmV0aWNfY2lwaGVyKT4+Cj4+CmVuZG9iagoKNjEgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBl L0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzczIDE3OS43IDI4OS4yIDE5MS4zXS9BPDwvVHlwZS9B Y3Rpb24vUy9VUkkvVVJJKGh0dHA6Ly93d3cudGhvbmt5LmNvbS9rcnlwdG9zL2luZGV4LW9mLWNv aW5jaWRlbmNlKT4+Cj4+CmVuZG9iagoKNjIgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xp bmsvQm9yZGVyWzAgMCAwXS9SZWN0WzU2IDIyOC4xIDI4MS43IDIzOS43XS9BPDwvVHlwZS9BY3Rp b24vUy9VUkkvVVJJKGh0dHA6Ly9nYW1lcHJvZ3JhbW1pbmdwYXR0ZXJucy5jb20vZGF0YS1sb2Nh bGl0eS5odG1sKT4+Cj4+CmVuZG9iagoKNjMgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xp bmsvQm9yZGVyWzAgMCAwXS9SZWN0WzczIDIzOS43IDI4MS41IDI1MS4zXS9BPDwvVHlwZS9BY3Rp b24vUy9VUkkvVVJJKGh0dHBzOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL0xvY2FsaXR5X29mX3Jl ZmVyZW5jZSk+Pgo+PgplbmRvYmoKCjY0IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5r L0JvcmRlclswIDAgMF0vUmVjdFs3MyAyNjIuOCAzMjMuMSAyNzQuNF0vQTw8L1R5cGUvQWN0aW9u L1MvVVJJL1VSSShodHRwczovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9BZHZhbmNlZF9FbmNyeXB0 aW9uX1N0YW5kYXJkKT4+Cj4+CmVuZG9iagoKNjUgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBl L0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzczIDI4NS45IDI5Ny42IDI5Ny41XS9BPDwvVHlwZS9B Y3Rpb24vUy9VUkkvVVJJKGh0dHBzOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL01hbi1pbi10aGUt bWlkZGxlX2F0dGFjayk+Pgo+PgplbmRvYmoKCjY2IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlw ZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs3MyAzNTUuMiAyMDguMiAzNjYuOF0vQTw8L1R5cGUv QWN0aW9uL1MvVVJJL1VSSShodHRwczovL3RyLndpa2lwZWRpYS5vcmcvd2lraS9SU0EpPj4KPj4K ZW5kb2JqCgo2NyAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBd L1JlY3RbNzMgMzY2LjcgMjQzLjcgMzc4LjNdL0E8PC9UeXBlL0FjdGlvbi9TL1VSSS9VUkkoaHR0 cHM6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvWE9SX2NpcGhlcik+Pgo+PgplbmRvYmoKCjY4IDAg b2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs3MyAzODku OCAzMjQgNDAxLjRdL0E8PC9UeXBlL0FjdGlvbi9TL1VSSS9VUkkoaHR0cHM6Ly90ci53aWtpcGVk aWEub3JnL3dpa2kvRGlmZmllLUhlbGxtYW5fYW5haHRhcl9kZSVDNCU5RmklQzUlOUZpbWkpPj4K Pj4KZW5kb2JqCgo2OSAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAw IDBdL1JlY3RbNzMgNDEyLjkgMzA3LjUgNDI0LjVdL0E8PC9UeXBlL0FjdGlvbi9TL1VSSS9VUkko aHR0cDovL3d3dy50dXJraHVrdWtzaXRlc2kuY29tL3Nob3d0aHJlYWQucGhwP3Q9MzY5NjgpPj4K Pj4KZW5kb2JqCgo3MCAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAw IDBdL1JlY3RbNzMgNDM2IDI5MS4yIDQ0Ny42XS9BPDwvVHlwZS9BY3Rpb24vUy9VUkkvVVJJKGh0 dHA6Ly93d3cudHVya2l5ZWdhemV0ZXNpLmNvbS50ci9kdW55YS8zMTYxMTIuYXNweCk+Pgo+Pgpl bmRvYmoKCjcxIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0v UmVjdFs3MyA0NTkuMSAyNzkuMyA0NzAuN10vQTw8L1R5cGUvQWN0aW9uL1MvVVJJL1VSSShodHRw czovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9QcmV0dHlfR29vZF9Qcml2YWN5KT4+Cj4+CmVuZG9i agoKNzIgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0 WzczIDQ4Mi4yIDMyMS4xIDQ5My44XS9BPDwvVHlwZS9BY3Rpb24vUy9VUkkvVVJJKGh0dHA6Ly93 d3cuaHVycml5ZXQuY29tLnRyL25zYS0xMjItbGlkZXJpLWRpbmxlbWlzLTI2MTExMjAzKT4+Cj4+ CmVuZG9iagoKNzMgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAw XS9SZWN0WzczIDUwNS4zIDI3MS40IDUxNi45XS9BPDwvVHlwZS9BY3Rpb24vUy9VUkkvVVJJKGh0 dHA6Ly93d3cud2lyZWQuY29tLzIwMTIvMDMvZmZfbnNhZGF0YWNlbnRlci8pPj4KPj4KZW5kb2Jq Cgo3NCAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3Rb NzMgNTI4LjQgMjU3LjMgNTQwXS9BPDwvVHlwZS9BY3Rpb24vUy9VUkkvVVJJKGh0dHBzOi8vbWlz ZXMub3JnL2xpYnJhcnkvaGVnZWwtc3RhdGUtZ29kcy13aWxsKT4+Cj4+CmVuZG9iagoKNzUgMCBv YmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzU2IDU1MS41 IDEwOC45IDU2My4xXS9BPDwvVHlwZS9BY3Rpb24vUy9VUkkvVVJJKGh0dHA6Ly93d3cudGhlcmVn aXN0ZXIuY28udWsvMjAxNS8wOS8wMy93aWtpcGVkaWFfaW5kdXN0cmlhbF9zY2FsZV9zbWVhcnNf YW5kX2JsYWNrbWFpbC8pPj4KPj4KZW5kb2JqCgo3NiAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5 cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbNzMgNTYzLjEgNDExLjggNTc0LjddL0E8PC9UeXBl L0FjdGlvbi9TL1VSSS9VUkkoaHR0cDovL3d3dy50aGVyZWdpc3Rlci5jby51ay8yMDE1LzA5LzAz L3dpa2lwZWRpYV9pbmR1c3RyaWFsX3NjYWxlX3NtZWFyc19hbmRfYmxhY2ttYWlsLyk+Pgo+Pgpl bmRvYmoKCjc3IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0v UmVjdFs3MyA1ODYuMiAzMzIuNyA1OTcuOF0vQTw8L1R5cGUvQWN0aW9uL1MvVVJJL1VSSShodHRw czovL3d3dy50Ym1tLmdvdi50ci9kZXZlbG9wL293YS9hbmF5YXNhLm1hZGRlbGVyP3AzPTIyKT4+ Cj4+CmVuZG9iagoKNzggMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAg MCAwXS9SZWN0WzI1OS42IDU4OTcuNiAyNjIuNyA1OTA5LjJdL0Rlc3RbNDEgMCBSL1hZWiA3My43 IDYwOS4zIDBdPj4KZW5kb2JqCgo3OSAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9C b3JkZXJbMCAwIDBdL1JlY3RbMzM5LjMgNTU2MC40IDM0NCA1NTcyXS9EZXN0WzQxIDAgUi9YWVog NzMuNyA1NzQuNyAwXT4+CmVuZG9iagoKODAgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xp bmsvQm9yZGVyWzAgMCAwXS9SZWN0WzQyNi41IDU1MzcuMyA0MzIuMiA1NTQ4LjldL0Rlc3RbNDEg MCBSL1hZWiA3My43IDU0MCAwXT4+CmVuZG9iagoKODEgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0 eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzQyMy41IDU0NzkuNSA0MjkuNSA1NDkxLjFdL0Rl c3RbNDEgMCBSL1hZWiA3My43IDUxNi45IDBdPj4KZW5kb2JqCgo4MiAwIG9iago8PC9UeXBlL0Fu bm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbMTc4LjcgNTE3Ny4xIDE4My4xIDUx ODguN10vRGVzdFs0MSAwIFIvWFlaIDczLjcgNDkzLjggMF0+PgplbmRvYmoKCjgzIDAgb2JqCjw8 L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFsxNjYuOSA1MDE1LjQg MTcyLjkgNTAyN10vRGVzdFs0MSAwIFIvWFlaIDczLjcgNDcwLjcgMF0+PgplbmRvYmoKCjg0IDAg b2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFszNTYuNSA0 ODUzLjcgMzY0LjEgNDg2NS4zXS9EZXN0WzQxIDAgUi9YWVogNzMuNyA0NDcuNiAwXT4+CmVuZG9i agoKODUgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0 WzIxNy40IDQ1NjYuMSAyMjYuNiA0NTc3LjddL0Rlc3RbNDEgMCBSL1hZWiA3My43IDQyNC41IDBd Pj4KZW5kb2JqCgo4NiAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAw IDBdL1JlY3RbMzUwLjcgNDE3My40IDM1Ni43IDQxODVdL0Rlc3RbNDEgMCBSL1hZWiA3My43IDQw MS40IDBdPj4KZW5kb2JqCgo4NyAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3Jk ZXJbMCAwIDBdL1JlY3RbNDIxLjQgNDEyNy4yIDQyNS44IDQxMzguOF0vRGVzdFs0MSAwIFIvWFla IDczLjcgMzc4LjMgMF0+PgplbmRvYmoKCjg4IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9M aW5rL0JvcmRlclswIDAgMF0vUmVjdFsxMDUuMyAzNTM5LjIgMTExLjMgMzU1MC44XS9EZXN0WzQx IDAgUi9YWVogNzMuNyAzNjYuOCAwXT4+CmVuZG9iagoKODkgMCBvYmoKPDwvVHlwZS9Bbm5vdC9T dWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzMzMy4yIDM4NjIuNiAzNDAuOCAzODc0LjJd L0Rlc3RbNDEgMCBSL1hZWiA3My43IDM0My43IDBdPj4KZW5kb2JqCgo5MCAwIG9iago8PC9UeXBl L0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbMzg4LjEgMzc5My4zIDM5Ny4z IDM4MDQuOV0vRGVzdFs0MSAwIFIvWFlaIDczLjcgMjk3LjUgMF0+PgplbmRvYmoKCjkxIDAgb2Jq Cjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFsyOTcuNCAyOTg1 LjkgMzA2LjMgMjk5Ny41XS9EZXN0WzQxIDAgUi9YWVogNzMuNyAyNzQuNCAwXT4+CmVuZG9iagoK OTIgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzI3 MS41IDIyNDcuOCAyNzguOCAyMjU5LjRdL0Rlc3RbNDEgMCBSL1hZWiA3My43IDI1MS4zIDBdPj4K ZW5kb2JqCgo5MyAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBd L1JlY3RbMjc0LjMgMjA4Ni4xIDI4My4yIDIwOTcuN10vRGVzdFs0MSAwIFIvWFlaIDczLjcgMjE2 LjYgMF0+PgplbmRvYmoKCjk0IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRl clswIDAgMF0vUmVjdFsxNzkuNyAxODc5LjMgMTkwLjIgMTg5MC45XS9EZXN0WzQxIDAgUi9YWVog NzMuNyAxOTEuMyAwXT4+CmVuZG9iagoKOTUgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xp bmsvQm9yZGVyWzAgMCAwXS9SZWN0WzEzOC45IDE4NjcuOCAxNTEgMTg3OS40XS9EZXN0WzQxIDAg Ui9YWVogNzUuMSAxNjguMiAwXT4+CmVuZG9iagoKOTYgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0 eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzIyNy42IDE4NjcuOCAyMzUuOSAxODc5LjRdL0Rl c3RbNDEgMCBSL1hZWiA3My43IDE0NS4xIDBdPj4KZW5kb2JqCgo5NyAwIG9iago8PC9UeXBlL0Fu bm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbODIuNyAxODEwIDkwIDE4MjEuNl0v RGVzdFs0MSAwIFIvWFlaIDczLjcgMTIyIDBdPj4KZW5kb2JqCgo5OCAwIG9iago8PC9UeXBlL0Fu bm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbOTUuOCAxNzI5LjIgMTA0LjcgMTc0 MC44XS9EZXN0WzQxIDAgUi9YWVogNzMuNyA5OC45IDBdPj4KZW5kb2JqCgo5OSAwIG9iago8PC9U eXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbMTYwLjEgMTY3MS40IDE3 MC42IDE2ODNdL0Rlc3RbNDEgMCBSL1hZWiA3My43IDc1LjggMF0+PgplbmRvYmoKCjEwMCAwIG9i ago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbMzE5LjIgMjQw OS41IDMzMS4zIDI0MjEuMV0vRGVzdFs0NiAwIFIvWFlaIDc1LjEgNTk3LjggMF0+PgplbmRvYmoK CjEwMSAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3Rb MzQzLjMgMjIxMy4yIDM1NS4xIDIyMjQuOF0vRGVzdFs0NiAwIFIvWFlaIDc0LjUgNTc0LjcgMF0+ PgplbmRvYmoKCjEwMiAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAw IDBdL1JlY3RbNDE5LjMgMjEwOS4yIDQyOS41IDIxMjAuOF0vRGVzdFs0NiAwIFIvWFlaIDczLjcg NTUxLjYgMF0+PgplbmRvYmoKCjEwMyAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9C b3JkZXJbMCAwIDBdL1JlY3RbNDA2LjIgMjA3NC42IDQxOCAyMDg2LjJdL0Rlc3RbNDYgMCBSL1hZ WiA3NC41IDUyOC41IDBdPj4KZW5kb2JqCgoxMjIgMCBvYmoKPDwvVHlwZS9DYXRhbG9nL1BhZ2Vz IDEwNCAwIFIKL09wZW5BY3Rpb25bMSAwIFIgL1hZWiBudWxsIG51bGwgMF0KL0xhbmcoZW4tVVMp Cj4+CmVuZG9iagoKMTIzIDAgb2JqCjw8L0F1dGhvcjxGRUZGMDA0NTAwNzIwMDZCMDA2OTAwNkUw MDIwMDA0MzAwNjEwMDZFPgovQ3JlYXRvcjxGRUZGMDA1NzAwNzIwMDY5MDA3NDAwNjUwMDcyPgov UHJvZHVjZXI8RkVGRjAwNEMwMDY5MDA2MjAwNzIwMDY1MDA0RjAwNjYwMDY2MDA2OTAwNjMwMDY1 MDAyMDAwMzQwMDJFMDAzMz4KL0NyZWF0aW9uRGF0ZShEOjIwMTUxMTE3MDIxMjIwKzAyJzAwJyk+ PgplbmRvYmoKCnhyZWYKMCAxMjQKMDAwMDAwMDAwMCA2NTUzNSBmIAowMDAwMTA2NjA4IDAwMDAw IG4gCjAwMDAwMDAwMTkgMDAwMDAgbiAKMDAwMDAwNDcwNSAwMDAwMCBuIAowMDAwMDA0NzI2IDAw MDAwIG4gCjAwMDAwMDQ5MjIgMDAwMDAgbiAKMDAwMDEwNjgwMCAwMDAwMCBuIAowMDAwMDA0OTYy IDAwMDAwIG4gCjAwMDAwMTA2MTQgMDAwMDAgbiAKMDAwMDAxMDYzNSAwMDAwMCBuIAowMDAwMDEw ODMxIDAwMDAwIG4gCjAwMDAxMDY5NzggMDAwMDAgbiAKMDAwMDAxMDg3MiAwMDAwMCBuIAowMDAw MDE2Njg0IDAwMDAwIG4gCjAwMDAwMTY3MDYgMDAwMDAgbiAKMDAwMDAxNjkwMyAwMDAwMCBuIAow MDAwMTA3MTU4IDAwMDAwIG4gCjAwMDAwMTY5NDQgMDAwMDAgbiAKMDAwMDAyMjQ4MSAwMDAwMCBu IAowMDAwMDIyNTAzIDAwMDAwIG4gCjAwMDAwMjI3MDAgMDAwMDAgbiAKMDAwMDEwNzM0NSAwMDAw MCBuIAowMDAwMDIyNzQxIDAwMDAwIG4gCjAwMDAwMjgxMjUgMDAwMDAgbiAKMDAwMDAyODE0NyAw MDAwMCBuIAowMDAwMDI4MzQ0IDAwMDAwIG4gCjAwMDAxMDc1MTEgMDAwMDAgbiAKMDAwMDAyODM4 NSAwMDAwMCBuIAowMDAwMDMzMzcwIDAwMDAwIG4gCjAwMDAwMzMzOTIgMDAwMDAgbiAKMDAwMDAz MzU4OSAwMDAwMCBuIAowMDAwMTA3Njg0IDAwMDAwIG4gCjAwMDAwMzM2MzAgMDAwMDAgbiAKMDAw MDAzOTI0NyAwMDAwMCBuIAowMDAwMDM5MjY5IDAwMDAwIG4gCjAwMDAwMzk0NjYgMDAwMDAgbiAK MDAwMDEwNzkxNyAwMDAwMCBuIAowMDAwMDM5NTA3IDAwMDAwIG4gCjAwMDAwNDQwNzUgMDAwMDAg biAKMDAwMDA0NDA5NyAwMDAwMCBuIAowMDAwMDQ0Mjk0IDAwMDAwIG4gCjAwMDAxMDgwNjUgMDAw MDAgbiAKMDAwMDA0NDMzNSAwMDAwMCBuIAowMDAwMDQ2NTYxIDAwMDAwIG4gCjAwMDAwNDY1ODMg MDAwMDAgbiAKMDAwMDA0Njc4MCAwMDAwMCBuIAowMDAwMTA4Mzc4IDAwMDAwIG4gCjAwMDAwNDY4 MjEgMDAwMDAgbiAKMDAwMDA0NzQ4MCAwMDAwMCBuIAowMDAwMDQ3NTAxIDAwMDAwIG4gCjAwMDAw NDc2OTggMDAwMDAgbiAKMDAwMDEwODcyMyAwMDAwMCBuIAowMDAwMTA4ODczIDAwMDAwIG4gCjAw MDAxMDkwNjIgMDAwMDAgbiAKMDAwMDEwOTIwNyAwMDAwMCBuIAowMDAwMTA5MzgxIDAwMDAwIG4g CjAwMDAxMDk1NTMgMDAwMDAgbiAKMDAwMDEwOTcwNiAwMDAwMCBuIAowMDAwMTA5ODc4IDAwMDAw IG4gCjAwMDAxMTAwNDAgMDAwMDAgbiAKMDAwMDExMDIwOCAwMDAwMCBuIAowMDAwMTEwMzc5IDAw MDAwIG4gCjAwMDAxMTA1NDcgMDAwMDAgbiAKMDAwMDExMDcxOCAwMDAwMCBuIAowMDAwMTEwODg3 IDAwMDAwIG4gCjAwMDAxMTEwNjMgMDAwMDAgbiAKMDAwMDExMTIzNSAwMDAwMCBuIAowMDAwMTEx Mzg2IDAwMDAwIG4gCjAwMDAxMTE1NDQgMDAwMDAgbiAKMDAwMDExMTczMSAwMDAwMCBuIAowMDAw MTExOTAyIDAwMDAwIG4gCjAwMDAxMTIwNjkgMDAwMDAgbiAKMDAwMDExMjIzNiAwMDAwMCBuIAow MDAwMTEyNDEzIDAwMDAwIG4gCjAwMDAxMTI1NzcgMDAwMDAgbiAKMDAwMDExMjc0MCAwMDAwMCBu IAowMDAwMTEyOTQ2IDAwMDAwIG4gCjAwMDAxMTMxNTIgMDAwMDAgbiAKMDAwMDExMzMyOCAwMDAw MCBuIAowMDAwMTEzNDUwIDAwMDAwIG4gCjAwMDAxMTM1NjggMDAwMDAgbiAKMDAwMDExMzY4OCAw MDAwMCBuIAowMDAwMTEzODEwIDAwMDAwIG4gCjAwMDAxMTM5MzIgMDAwMDAgbiAKMDAwMDExNDA1 MiAwMDAwMCBuIAowMDAwMTE0MTc0IDAwMDAwIG4gCjAwMDAxMTQyOTYgMDAwMDAgbiAKMDAwMDEx NDQxNiAwMDAwMCBuIAowMDAwMTE0NTM4IDAwMDAwIG4gCjAwMDAxMTQ2NjAgMDAwMDAgbiAKMDAw MDExNDc4MiAwMDAwMCBuIAowMDAwMTE0OTA0IDAwMDAwIG4gCjAwMDAxMTUwMjYgMDAwMDAgbiAK MDAwMDExNTE0OCAwMDAwMCBuIAowMDAwMTE1MjcwIDAwMDAwIG4gCjAwMDAxMTUzOTIgMDAwMDAg biAKMDAwMDExNTUxMiAwMDAwMCBuIAowMDAwMTE1NjM0IDAwMDAwIG4gCjAwMDAxMTU3NDggMDAw MDAgbiAKMDAwMDExNTg2OCAwMDAwMCBuIAowMDAwMTE1OTg3IDAwMDAwIG4gCjAwMDAxMTYxMTAg MDAwMDAgbiAKMDAwMDExNjIzMyAwMDAwMCBuIAowMDAwMTE2MzU2IDAwMDAwIG4gCjAwMDAxMDg1 NTggMDAwMDAgbiAKMDAwMDA0NzczOSAwMDAwMCBuIAowMDAwMDczMTUzIDAwMDAwIG4gCjAwMDAw NzMxNzcgMDAwMDAgbiAKMDAwMDA3MzM3NiAwMDAwMCBuIAowMDAwMDc0MDg1IDAwMDAwIG4gCjAw MDAwNzQ2MzUgMDAwMDAgbiAKMDAwMDA4NjM3MiAwMDAwMCBuIAowMDAwMDg2Mzk2IDAwMDAwIG4g CjAwMDAwODY2MDUgMDAwMDAgbiAKMDAwMDA4NzEwOCAwMDAwMCBuIAowMDAwMDg3NDY1IDAwMDAw IG4gCjAwMDAxMDQ5NzggMDAwMDAgbiAKMDAwMDEwNTAwMiAwMDAwMCBuIAowMDAwMTA1MjA4IDAw MDAwIG4gCjAwMDAxMDU3ODAgMDAwMDAgbiAKMDAwMDEwNjE5OSAwMDAwMCBuIAowMDAwMTA2MjU2 IDAwMDAwIG4gCjAwMDAxMTY0NzcgMDAwMDAgbiAKMDAwMDExNjU3NyAwMDAwMCBuIAp0cmFpbGVy Cjw8L1NpemUgMTI0L1Jvb3QgMTIyIDAgUgovSW5mbyAxMjMgMCBSCi9JRCBbIDxGODAwMjFGNUJF RTdCNURFMzQ2MTY1MzZCODhFMjEwOT4KPEY4MDAyMUY1QkVFN0I1REUzNDYxNjUzNkI4OEUyMTA5 PiBdCi9Eb2NDaGVja3N1bSAvQzY3RTFDMjAzM0MzNTkwMzIyQUY2RTQ4OTE0QjQyMDgKPj4Kc3Rh cnR4cmVmCjExNjgwMwolJUVPRgo= --001a113c8fca4c94a70524b34c81 Content-Type: text/x-csrc; charset=UTF-8; name="HohhaDynamicXOR.c" Content-Disposition: attachment; filename="HohhaDynamicXOR.c" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ih2rezoj1 LypCLgpIb2hoYSBEeW5hbWljIFhPUiBBbGdvcml0aG0uIENvcHlyaWdodCAoYykgMjAxNSDEsHNt YWlsIEtpemlyClBlcm1pc3Npb24gaXMgaGVyZWJ5IGdyYW50ZWQsIGZyZWUgb2YgY2hhcmdlLCB0 byBhbnkgcGVyc29uIG9idGFpbmluZyBhIGNvcHkgb2YgdGhpcyBzb2Z0d2FyZSAKYW5kIGFzc29j aWF0ZWQgZG9jdW1lbnRhdGlvbiBmaWxlcyAodGhlICJTb2Z0d2FyZSIpLCB0byBkZWFsIGluIHRo ZSBTb2Z0d2FyZSB3aXRob3V0IHJlc3RyaWN0aW9uLCAKaW5jbHVkaW5nIHdpdGhvdXQgbGltaXRh dGlvbiB0aGUgcmlnaHRzIHRvIHVzZSwgY29weSwgbW9kaWZ5LCBtZXJnZSwgcHVibGlzaCwgZGlz dHJpYnV0ZSwgc3VibGljZW5zZSwgCmFuZC9vciBzZWxsIGNvcGllcyBvZiB0aGUgU29mdHdhcmUs IGFuZCB0byBwZXJtaXQgcGVyc29ucyB0byB3aG9tIHRoZSBTb2Z0d2FyZSBpcyBmdXJuaXNoZWQg dG8gZG8gc28sIApzdWJqZWN0IHRvIHRoZSBmb2xsb3dpbmcgY29uZGl0aW9uczoKVGhlIGFib3Zl IGNvcHlyaWdodCBub3RpY2UgYW5kIHRoaXMgcGVybWlzc2lvbiBub3RpY2Ugc2hhbGwgYmUgaW5j bHVkZWQgaW4gYWxsIGNvcGllcyBvciBzdWJzdGFudGlhbCBwb3J0aW9ucyBvZiB0aGUgU29mdHdh cmUuClRIRSBTT0ZUV0FSRSBJUyBQUk9WSURFRCAiQVMgSVMiLCBXSVRIT1VUIFdBUlJBTlRZIE9G IEFOWSBLSU5ELCBFWFBSRVNTIE9SIElNUExJRUQsIElOQ0xVRElORyBCVVQgTk9UIExJTUlURUQg VE8gVEhFIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZLCBGSVRORVNTIEZPUiBBIFBBUlRJ Q1VMQVIgUFVSUE9TRSBBTkQgTk9OSU5GUklOR0VNRU5ULiBJTiBOTyBFVkVOVCBTSEFMTCBUSEUg QVVUSE9SUyBPUiBDT1BZUklHSFQgSE9MREVSUyBCRSBMSUFCTEUgRk9SIEFOWSBDTEFJTSwgREFN QUdFUyBPUiBPVEhFUiBMSUFCSUxJVFksIFdIRVRIRVIgSU4gQU4gQUNUSU9OIE9GIENPTlRSQUNU LCBUT1JUIE9SIE9USEVSV0lTRSwgQVJJU0lORyBGUk9NLCBPVVQgT0YgT1IgSU4gQ09OTkVDVElP TiBXSVRIIFRIRSBTT0ZUV0FSRSBPUiBUSEUgVVNFIE9SIE9USEVSIERFQUxJTkdTIElOIFRIRSBT T0ZUV0FSRS4KICovCiNpbmNsdWRlIDxzdGRpby5oPgojaW5jbHVkZSA8c3lzL3R5cGVzLmg+CiNp bmNsdWRlIDxmY250bC5oPgojaW5jbHVkZSA8ZXJybm8uaD4KI2luY2x1ZGUgPHRpbWUuaD4KI2lu Y2x1ZGUgPGN0eXBlLmg+CiNpbmNsdWRlIDxzdHJpbmcuaD4KI2luY2x1ZGUgPHN0ZGRlZi5oPgoj aW5jbHVkZSA8c3RkbGliLmg+CiNpbmNsdWRlIDxhc3NlcnQuaD4KI2luY2x1ZGUgPHN5cy90aW1l Lmg+CgojaW5jbHVkZSA8aW50dHlwZXMuaD4KI2luY2x1ZGUgPHN0cmluZy5oPgoKLyogLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBCQVNFNjQgRU5DT0RFL0RFQ09ERSBGVU5DVElPTlMgLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQogKi8KLyoKY2VuY29kZXIuYyAtIGMg c291cmNlIHRvIGEgYmFzZTY0IGVuY29kaW5nIGFsZ29yaXRobSBpbXBsZW1lbnRhdGlvbgoKVGhp cyBpcyBwYXJ0IG9mIHRoZSBsaWJiNjQgcHJvamVjdCwgYW5kIGhhcyBiZWVuIHBsYWNlZCBpbiB0 aGUgcHVibGljIGRvbWFpbi4KRm9yIGRldGFpbHMsIHNlZSBodHRwOi8vc291cmNlZm9yZ2UubmV0 L3Byb2plY3RzL2xpYmI2NAoqLwoKdHlwZWRlZiBlbnVtCnsKCXN0ZXBfQSwgc3RlcF9CLCBzdGVw X0MKfSBiYXNlNjRfZW5jb2Rlc3RlcDsKCnR5cGVkZWYgc3RydWN0CnsKCWJhc2U2NF9lbmNvZGVz dGVwIHN0ZXA7CgljaGFyIHJlc3VsdDsKCWludCBzdGVwY291bnQ7Cn0gYmFzZTY0X2VuY29kZXN0 YXRlOwp0eXBlZGVmIGVudW0KewoJc3RlcF9hLCBzdGVwX2IsIHN0ZXBfYywgc3RlcF9kCn0gYmFz ZTY0X2RlY29kZXN0ZXA7Cgp0eXBlZGVmIHN0cnVjdAp7CgliYXNlNjRfZGVjb2Rlc3RlcCBzdGVw OwoJY2hhciBwbGFpbmNoYXI7Cn0gYmFzZTY0X2RlY29kZXN0YXRlOwpjb25zdCBpbnQgQ0hBUlNf UEVSX0xJTkUgPSA3MjsKCnZvaWQgYmFzZTY0X2luaXRfZW5jb2Rlc3RhdGUoYmFzZTY0X2VuY29k ZXN0YXRlKiBzdGF0ZV9pbikKewoJc3RhdGVfaW4tPnN0ZXAgPSBzdGVwX0E7CglzdGF0ZV9pbi0+ cmVzdWx0ID0gMDsKCXN0YXRlX2luLT5zdGVwY291bnQgPSAwOwp9CgpjaGFyIGJhc2U2NF9lbmNv ZGVfdmFsdWUoY2hhciB2YWx1ZV9pbikKewoJc3RhdGljIGNvbnN0IGNoYXIqIGVuY29kaW5nID0g IkFCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFlaYWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXowMTIz NDU2Nzg5Ky8iOwoJaWYgKHZhbHVlX2luID4gNjMpIHJldHVybiAnPSc7CglyZXR1cm4gZW5jb2Rp bmdbKGludCl2YWx1ZV9pbl07Cn0KCmludCBiYXNlNjRfZW5jb2RlX2Jsb2NrKGNvbnN0IGNoYXIq IHBsYWludGV4dF9pbiwgaW50IGxlbmd0aF9pbiwgY2hhciogY29kZV9vdXQsIGJhc2U2NF9lbmNv ZGVzdGF0ZSogc3RhdGVfaW4pCnsKCWNvbnN0IGNoYXIqIHBsYWluY2hhciA9IHBsYWludGV4dF9p bjsKCWNvbnN0IGNoYXIqIGNvbnN0IHBsYWludGV4dGVuZCA9IHBsYWludGV4dF9pbiArIGxlbmd0 aF9pbjsKCWNoYXIqIGNvZGVjaGFyID0gY29kZV9vdXQ7CgljaGFyIHJlc3VsdDsKCWNoYXIgZnJh Z21lbnQ7CgkKCXJlc3VsdCA9IHN0YXRlX2luLT5yZXN1bHQ7CgkKCXN3aXRjaCAoc3RhdGVfaW4t PnN0ZXApCgl7CgkJd2hpbGUgKDEpCgkJewoJY2FzZSBzdGVwX0E6CgkJCWlmIChwbGFpbmNoYXIg PT0gcGxhaW50ZXh0ZW5kKQoJCQl7CgkJCQlzdGF0ZV9pbi0+cmVzdWx0ID0gcmVzdWx0OwoJCQkJ c3RhdGVfaW4tPnN0ZXAgPSBzdGVwX0E7CgkJCQlyZXR1cm4gY29kZWNoYXIgLSBjb2RlX291dDsK CQkJfQoJCQlmcmFnbWVudCA9ICpwbGFpbmNoYXIrKzsKCQkJcmVzdWx0ID0gKGZyYWdtZW50ICYg MHgwZmMpID4+IDI7CgkJCSpjb2RlY2hhcisrID0gYmFzZTY0X2VuY29kZV92YWx1ZShyZXN1bHQp OwoJCQlyZXN1bHQgPSAoZnJhZ21lbnQgJiAweDAwMykgPDwgNDsKCWNhc2Ugc3RlcF9COgoJCQlp ZiAocGxhaW5jaGFyID09IHBsYWludGV4dGVuZCkKCQkJewoJCQkJc3RhdGVfaW4tPnJlc3VsdCA9 IHJlc3VsdDsKCQkJCXN0YXRlX2luLT5zdGVwID0gc3RlcF9COwoJCQkJcmV0dXJuIGNvZGVjaGFy IC0gY29kZV9vdXQ7CgkJCX0KCQkJZnJhZ21lbnQgPSAqcGxhaW5jaGFyKys7CgkJCXJlc3VsdCB8 PSAoZnJhZ21lbnQgJiAweDBmMCkgPj4gNDsKCQkJKmNvZGVjaGFyKysgPSBiYXNlNjRfZW5jb2Rl X3ZhbHVlKHJlc3VsdCk7CgkJCXJlc3VsdCA9IChmcmFnbWVudCAmIDB4MDBmKSA8PCAyOwoJY2Fz ZSBzdGVwX0M6CgkJCWlmIChwbGFpbmNoYXIgPT0gcGxhaW50ZXh0ZW5kKQoJCQl7CgkJCQlzdGF0 ZV9pbi0+cmVzdWx0ID0gcmVzdWx0OwoJCQkJc3RhdGVfaW4tPnN0ZXAgPSBzdGVwX0M7CgkJCQly ZXR1cm4gY29kZWNoYXIgLSBjb2RlX291dDsKCQkJfQoJCQlmcmFnbWVudCA9ICpwbGFpbmNoYXIr KzsKCQkJcmVzdWx0IHw9IChmcmFnbWVudCAmIDB4MGMwKSA+PiA2OwoJCQkqY29kZWNoYXIrKyA9 IGJhc2U2NF9lbmNvZGVfdmFsdWUocmVzdWx0KTsKCQkJcmVzdWx0ICA9IChmcmFnbWVudCAmIDB4 MDNmKSA+PiAwOwoJCQkqY29kZWNoYXIrKyA9IGJhc2U2NF9lbmNvZGVfdmFsdWUocmVzdWx0KTsK CQkJCgkJCSsrKHN0YXRlX2luLT5zdGVwY291bnQpOwoJCQlpZiAoc3RhdGVfaW4tPnN0ZXBjb3Vu dCA9PSBDSEFSU19QRVJfTElORS80KQoJCQl7CgkJCQkvLypjb2RlY2hhcisrID0gJ1xuJzsKCQkJ CXN0YXRlX2luLT5zdGVwY291bnQgPSAwOwoJCQl9CgkJfQoJfQoJLyogY29udHJvbCBzaG91bGQg bm90IHJlYWNoIGhlcmUgKi8KCXJldHVybiBjb2RlY2hhciAtIGNvZGVfb3V0Owp9CgppbnQgYmFz ZTY0X2VuY29kZV9ibG9ja2VuZChjaGFyKiBjb2RlX291dCwgYmFzZTY0X2VuY29kZXN0YXRlKiBz dGF0ZV9pbikKewoJY2hhciogY29kZWNoYXIgPSBjb2RlX291dDsKCQoJc3dpdGNoIChzdGF0ZV9p bi0+c3RlcCkKCXsKCWNhc2Ugc3RlcF9COgoJCSpjb2RlY2hhcisrID0gYmFzZTY0X2VuY29kZV92 YWx1ZShzdGF0ZV9pbi0+cmVzdWx0KTsKCQkqY29kZWNoYXIrKyA9ICc9JzsKCQkqY29kZWNoYXIr KyA9ICc9JzsKCQlicmVhazsKCWNhc2Ugc3RlcF9DOgoJCSpjb2RlY2hhcisrID0gYmFzZTY0X2Vu Y29kZV92YWx1ZShzdGF0ZV9pbi0+cmVzdWx0KTsKCQkqY29kZWNoYXIrKyA9ICc9JzsKCQlicmVh azsKCWNhc2Ugc3RlcF9BOgoJCWJyZWFrOwoJfQoJLy8qY29kZWNoYXIrKyA9ICdcbic7CgkKCXJl dHVybiBjb2RlY2hhciAtIGNvZGVfb3V0Owp9CgppbnQgYmFzZTY0X2RlY29kZV92YWx1ZShjaGFy IHZhbHVlX2luKQp7CglzdGF0aWMgY29uc3QgY2hhciBkZWNvZGluZ1tdID0gezYyLC0xLC0xLC0x LDYzLDUyLDUzLDU0LDU1LDU2LDU3LDU4LDU5LDYwLDYxLC0xLC0xLC0xLC0yLC0xLC0xLC0xLDAs MSwyLDMsNCw1LDYsNyw4LDksMTAsMTEsMTIsMTMsMTQsMTUsMTYsMTcsMTgsMTksMjAsMjEsMjIs MjMsMjQsMjUsLTEsLTEsLTEsLTEsLTEsLTEsMjYsMjcsMjgsMjksMzAsMzEsMzIsMzMsMzQsMzUs MzYsMzcsMzgsMzksNDAsNDEsNDIsNDMsNDQsNDUsNDYsNDcsNDgsNDksNTAsNTF9OwoJc3RhdGlj IGNvbnN0IGNoYXIgZGVjb2Rpbmdfc2l6ZSA9IHNpemVvZihkZWNvZGluZyk7Cgl2YWx1ZV9pbiAt PSA0MzsKCWlmICh2YWx1ZV9pbiA8IDAgfHwgdmFsdWVfaW4gPj0gZGVjb2Rpbmdfc2l6ZSkgcmV0 dXJuIC0xOwoJcmV0dXJuIGRlY29kaW5nWyhpbnQpdmFsdWVfaW5dOwp9Cgp2b2lkIGJhc2U2NF9p bml0X2RlY29kZXN0YXRlKGJhc2U2NF9kZWNvZGVzdGF0ZSogc3RhdGVfaW4pCnsKCXN0YXRlX2lu LT5zdGVwID0gc3RlcF9hOwoJc3RhdGVfaW4tPnBsYWluY2hhciA9IDA7Cn0KCmludCBiYXNlNjRf ZGVjb2RlX2Jsb2NrKGNvbnN0IGNoYXIqIGNvZGVfaW4sIGNvbnN0IGludCBsZW5ndGhfaW4sIGNo YXIqIHBsYWludGV4dF9vdXQsIGJhc2U2NF9kZWNvZGVzdGF0ZSogc3RhdGVfaW4pCnsKCWNvbnN0 IGNoYXIqIGNvZGVjaGFyID0gY29kZV9pbjsKCWNoYXIqIHBsYWluY2hhciA9IHBsYWludGV4dF9v dXQ7CgljaGFyIGZyYWdtZW50OwoJCgkqcGxhaW5jaGFyID0gc3RhdGVfaW4tPnBsYWluY2hhcjsK CQoJc3dpdGNoIChzdGF0ZV9pbi0+c3RlcCkKCXsKCQl3aGlsZSAoMSkKCQl7CgljYXNlIHN0ZXBf YToKCQkJZG8gewoJCQkJaWYgKGNvZGVjaGFyID09IGNvZGVfaW4rbGVuZ3RoX2luKQoJCQkJewoJ CQkJCXN0YXRlX2luLT5zdGVwID0gc3RlcF9hOwoJCQkJCXN0YXRlX2luLT5wbGFpbmNoYXIgPSAq cGxhaW5jaGFyOwoJCQkJCXJldHVybiBwbGFpbmNoYXIgLSBwbGFpbnRleHRfb3V0OwoJCQkJfQoJ CQkJZnJhZ21lbnQgPSAoY2hhciliYXNlNjRfZGVjb2RlX3ZhbHVlKCpjb2RlY2hhcisrKTsKCQkJ fSB3aGlsZSAoZnJhZ21lbnQgPCAwKTsKCQkJKnBsYWluY2hhciAgICA9IChmcmFnbWVudCAmIDB4 MDNmKSA8PCAyOwoJY2FzZSBzdGVwX2I6CgkJCWRvIHsKCQkJCWlmIChjb2RlY2hhciA9PSBjb2Rl X2luK2xlbmd0aF9pbikKCQkJCXsKCQkJCQlzdGF0ZV9pbi0+c3RlcCA9IHN0ZXBfYjsKCQkJCQlz dGF0ZV9pbi0+cGxhaW5jaGFyID0gKnBsYWluY2hhcjsKCQkJCQlyZXR1cm4gcGxhaW5jaGFyIC0g cGxhaW50ZXh0X291dDsKCQkJCX0KCQkJCWZyYWdtZW50ID0gKGNoYXIpYmFzZTY0X2RlY29kZV92 YWx1ZSgqY29kZWNoYXIrKyk7CgkJCX0gd2hpbGUgKGZyYWdtZW50IDwgMCk7CgkJCSpwbGFpbmNo YXIrKyB8PSAoZnJhZ21lbnQgJiAweDAzMCkgPj4gNDsKCQkJKnBsYWluY2hhciAgICA9IChmcmFn bWVudCAmIDB4MDBmKSA8PCA0OwoJY2FzZSBzdGVwX2M6CgkJCWRvIHsKCQkJCWlmIChjb2RlY2hh ciA9PSBjb2RlX2luK2xlbmd0aF9pbikKCQkJCXsKCQkJCQlzdGF0ZV9pbi0+c3RlcCA9IHN0ZXBf YzsKCQkJCQlzdGF0ZV9pbi0+cGxhaW5jaGFyID0gKnBsYWluY2hhcjsKCQkJCQlyZXR1cm4gcGxh aW5jaGFyIC0gcGxhaW50ZXh0X291dDsKCQkJCX0KCQkJCWZyYWdtZW50ID0gKGNoYXIpYmFzZTY0 X2RlY29kZV92YWx1ZSgqY29kZWNoYXIrKyk7CgkJCX0gd2hpbGUgKGZyYWdtZW50IDwgMCk7CgkJ CSpwbGFpbmNoYXIrKyB8PSAoZnJhZ21lbnQgJiAweDAzYykgPj4gMjsKCQkJKnBsYWluY2hhciAg ICA9IChmcmFnbWVudCAmIDB4MDAzKSA8PCA2OwoJY2FzZSBzdGVwX2Q6CgkJCWRvIHsKCQkJCWlm IChjb2RlY2hhciA9PSBjb2RlX2luK2xlbmd0aF9pbikKCQkJCXsKCQkJCQlzdGF0ZV9pbi0+c3Rl cCA9IHN0ZXBfZDsKCQkJCQlzdGF0ZV9pbi0+cGxhaW5jaGFyID0gKnBsYWluY2hhcjsKCQkJCQly ZXR1cm4gcGxhaW5jaGFyIC0gcGxhaW50ZXh0X291dDsKCQkJCX0KCQkJCWZyYWdtZW50ID0gKGNo YXIpYmFzZTY0X2RlY29kZV92YWx1ZSgqY29kZWNoYXIrKyk7CgkJCX0gd2hpbGUgKGZyYWdtZW50 IDwgMCk7CgkJCSpwbGFpbmNoYXIrKyAgIHw9IChmcmFnbWVudCAmIDB4MDNmKTsKCQl9Cgl9Cgkv KiBjb250cm9sIHNob3VsZCBub3QgcmVhY2ggaGVyZSAqLwoJcmV0dXJuIHBsYWluY2hhciAtIHBs YWludGV4dF9vdXQ7Cn0KCgpjaGFyICpCYXNlNjRFbmNvZGUoY29uc3QgY2hhciogaW5wdXQsIHVp bnQzMl90IGlucHV0bGVuKQp7CiAgLyogc2V0IHVwIGEgZGVzdGluYXRpb24gYnVmZmVyIGxhcmdl IGVub3VnaCB0byBob2xkIHRoZSBlbmNvZGVkIGRhdGEgKi8KICBjaGFyKiBvdXRwdXQgPSAoY2hh ciopbWFsbG9jKDggKyAoaW5wdXRsZW4gKiA0KS8zKTsKICAvKiBrZWVwIHRyYWNrIG9mIG91ciBl bmNvZGVkIHBvc2l0aW9uICovCiAgY2hhciogYyA9IG91dHB1dDsKICAvKiBzdG9yZSB0aGUgbnVt YmVyIG9mIGJ5dGVzIGVuY29kZWQgYnkgYSBzaW5nbGUgY2FsbCAqLwogIGludCBjbnQgPSAwOwog IC8qIHdlIG5lZWQgYW4gZW5jb2RlciBzdGF0ZSAqLwogIGJhc2U2NF9lbmNvZGVzdGF0ZSBzOwoK ICAvKi0tLS0tLS0tLS0gU1RBUlQgRU5DT0RJTkcgLS0tLS0tLS0tLSovCiAgLyogaW5pdGlhbGlz ZSB0aGUgZW5jb2RlciBzdGF0ZSAqLwogIGJhc2U2NF9pbml0X2VuY29kZXN0YXRlKCZzKTsKICAv KiBnYXRoZXIgZGF0YSBmcm9tIHRoZSBpbnB1dCBhbmQgc2VuZCBpdCB0byB0aGUgb3V0cHV0ICov CiAgY250ID0gYmFzZTY0X2VuY29kZV9ibG9jayhpbnB1dCwgaW5wdXRsZW4sIGMsICZzKTsKICBj ICs9IGNudDsKICAvKiBzaW5jZSB3ZSBoYXZlIGVuY29kZWQgdGhlIGVudGlyZSBpbnB1dCBzdHJp bmcsIHdlIGtub3cgdGhhdCAKICAgICB0aGVyZSBpcyBubyBtb3JlIGlucHV0IGRhdGE7IGZpbmFs aXNlIHRoZSBlbmNvZGluZyAqLwogIGNudCA9IGJhc2U2NF9lbmNvZGVfYmxvY2tlbmQoYywgJnMp OwogIGMgKz0gY250OwogIC8qLS0tLS0tLS0tLSBTVE9QIEVOQ09ESU5HICAtLS0tLS0tLS0tKi8K CiAgLyogd2Ugd2FudCB0byBwcmludCB0aGUgZW5jb2RlZCBkYXRhLCBzbyBudWxsLXRlcm1pbmF0 ZSBpdDogKi8KICAqYyA9IDA7CgogIHJldHVybiBvdXRwdXQ7Cn0KCmNoYXIgKkJhc2U2NERlY29k ZShjb25zdCBjaGFyKiBpbnB1dCkKewogIC8qIHNldCB1cCBhIGRlc3RpbmF0aW9uIGJ1ZmZlciBs YXJnZSBlbm91Z2ggdG8gaG9sZCB0aGUgZW5jb2RlZCBkYXRhICovCiAgdW5zaWduZWQgaWxlbiA9 IHN0cmxlbihpbnB1dCk7CiAgY2hhciogb3V0cHV0ID0gKGNoYXIqKW1hbGxvYyhpbGVuKTsKICAv KiBrZWVwIHRyYWNrIG9mIG91ciBkZWNvZGVkIHBvc2l0aW9uICovCiAgY2hhciogYyA9IG91dHB1 dDsKICAvKiBzdG9yZSB0aGUgbnVtYmVyIG9mIGJ5dGVzIGRlY29kZWQgYnkgYSBzaW5nbGUgY2Fs bCAqLwogIGludCBjbnQgPSAwOwogIC8qIHdlIG5lZWQgYSBkZWNvZGVyIHN0YXRlICovCiAgYmFz ZTY0X2RlY29kZXN0YXRlIHM7CgogIC8qLS0tLS0tLS0tLSBTVEFSVCBERUNPRElORyAtLS0tLS0t LS0tKi8KICAvKiBpbml0aWFsaXNlIHRoZSBkZWNvZGVyIHN0YXRlICovCiAgYmFzZTY0X2luaXRf ZGVjb2Rlc3RhdGUoJnMpOwogIC8qIGRlY29kZSB0aGUgaW5wdXQgZGF0YSAqLwogIGNudCA9IGJh c2U2NF9kZWNvZGVfYmxvY2soaW5wdXQsIGlsZW4sIGMsICZzKTsKICBjICs9IGNudDsKICAvKiBu b3RlOiB0aGVyZSBpcyBubyBiYXNlNjRfZGVjb2RlX2Jsb2NrZW5kISAqLwogIC8qLS0tLS0tLS0t LSBTVE9QIERFQ09ESU5HICAtLS0tLS0tLS0tKi8KCiAgLyogd2Ugd2FudCB0byBwcmludCB0aGUg ZGVjb2RlZCBkYXRhLCBzbyBudWxsLXRlcm1pbmF0ZSBpdDogKi8KICAqYyA9IDA7CgogIHJldHVy biBvdXRwdXQ7Cn0KCgovKiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIEJBU0U2NCBFTkNP REUvREVDT0RFIEZVTkNUSU9OUyBFTkRTIEhFUkUgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQogKi8KCi8qIC0tLS0tLS0tLS0tLS0tLS0gdXRpbGl0eSBmbmNzICovCnVpbnQz Ml90IEdldEVsYXBzZWRUaW1lSW5NaWxsaVNlY29uZHMoc3RydWN0IHRpbWV2YWwgKlN0YXJ0VGlt ZSkKewogIHN0cnVjdCB0aW1ldmFsIE5vdzsKCiAgZ2V0dGltZW9mZGF5ICgmTm93LCBOVUxMKTsg CiAgcmV0dXJuIChOb3cudHZfc2VjIC0gU3RhcnRUaW1lLT50dl9zZWMpICogMTAwMCArIChOb3cu dHZfdXNlYyAtIFN0YXJ0VGltZS0+dHZfdXNlYykgLyAxMDAwOwp9CmRvdWJsZSBQcmludEVsYXBz ZWRUaW1lKHN0cnVjdCB0aW1ldmFsICpTdGFydFRpbWUsIHVuc2lnbmVkIGxvbmcgbG9uZyBpbnQg VG90YWxQcm9jZXNzZWRCeXRlcykKewogIGRvdWJsZSBUb3RhbE1CeXRlcyA9ICgoZG91YmxlKVRv dGFsUHJvY2Vzc2VkQnl0ZXMvKDEwMjQuMCoxMDI0KSk7IAogIHVuc2lnbmVkIEVJbk1zID0gR2V0 RWxhcHNlZFRpbWVJbk1pbGxpU2Vjb25kcyhTdGFydFRpbWUpOwogIGRvdWJsZSBBdmVyYWdlID0g VG90YWxNQnl0ZXMgLyAoMS4wICogRUluTXMpICogMTAwMC4wOwogIHByaW50ZigiXG5cdFRvdGFs IGRhdGEgcHJvY2Vzc2VkOiAlNi4yZiBNQnl0ZXNcblx0RWxhcHNlZCBUaW1lOiAldSBtcy5cblx0 QXZlcmFnZTogJTEwLjRmIE1CeXRlcy9zZWNzIFxuIixUb3RhbE1CeXRlcywgRUluTXMsIEF2ZXJh Z2UpOwogIHJldHVybiBBdmVyYWdlOwp9Cgp2b2lkIEluY0J5T25lKHVpbnQ4X3QgKkJ1ZiwgdWlu dDMyX3QgQnVmTGVuKQp7CiAgdW5zaWduZWQgdDsKICBmb3IgKHQ9MDsgdDxCdWZMZW47IHQrKykK ICAgIEJ1Zlt0XSsrOwp9CnVpbnQ4X3QgKkNyZWF0ZURhdGFCdWYoU2l6ZSkKewogIHJldHVybiAo dWludDhfdCAqKWNhbGxvYygxLCBTaXplKTsKfQoKLyogLS0tLS0tLS0tLS0tLS0tLSBlbmQgdXRp bGl0eSBmbmNzICovCgoKCiNkZWZpbmUgU0FMVF9TSVpFIDQgLy8gCiNkZWZpbmUgTUFYX05VTV9K VU1QUyA2NAojZGVmaW5lIEZBTFNFICgwVSkKI2RlZmluZSBUUlVFICghKEZBTFNFKSkKI2RlZmlu ZSBWRVJCT1NFCi8vI2RlZmluZSBPVkVSTFlfVkVSQk9TRQojZGVmaW5lIFJBTkRPTV9CVUZfU0la RSA4MTkyCnVpbnQ4X3QgUmFuZG9tQnVmW1JBTkRPTV9CVUZfU0laRV07Cgp1aW50MzJfdCBSYW5k b21CdWZTdGFydFBvcz05OTk5OTk5OTk7IC8vIEl0IG11c3QgYmUgYSBudW1iZXIgZ3JlYXRlciB0 aGFuIFJBTkRPTV9CVUZfU0laRSBmb3IgaW5pdGlhbGl6YXRpb24KCnZvaWQgUmVhZFJhbmRvbUJ5 dGVzRnJvbVVERXYodWludDMyX3QgQnl0ZUNvdW50LCB1aW50OF90ICpCdWZmZXIpCnsKICBGSUxF ICpmcDsKICAKICBmcCA9IGZvcGVuKCIvZGV2L3VyYW5kb20iLCAiciIpOwogIGlmICghZnApCiAg ewogICAgZnByaW50ZihzdGRlcnIsICJcblxuRVJST1IgT1BFTklORyAvZGV2L3VyYW5kb20hISEh XG5cbiIpOwogICAgZXhpdCgtMSk7CiAgfQogIAogIGZyZWFkKEJ1ZmZlciwgQnl0ZUNvdW50LCAx LCBmcCk7CiAgZmNsb3NlKGZwKTsKfQp2b2lkIFJhbmRvbWl6ZUJ1ZmZlcigpCnsKI2lmZGVmIFZF UkJPU0UKICBwcmludGYoIlJhbmRvbWl6aW5nIC4uLiBcbiIpOwojZW5kaWYKICBSYW5kb21CdWZT dGFydFBvcz0wOwogIFJlYWRSYW5kb21CeXRlc0Zyb21VREV2KFJBTkRPTV9CVUZfU0laRSwgUmFu ZG9tQnVmKTsKICAKI2lmZGVmIE9WRVJMWV9WRVJCT1NFCiAgaW50IHQ7CiAgZm9yICh0PTA7IHQ8 UkFORE9NX0JVRl9TSVpFOyB0KyspCiAgICBwcmludGYoIiV1ICIsUmFuZG9tQnVmW3RdKTsKICBw cmludGYoIlxuXG4iKTsKI2VuZGlmCn0KCnZvaWQgR2V0UmFuZG9tTnVtYmVycyh1aW50MzJfdCBC eXRlQ291bnQsIHVpbnQ4X3QgKkJ1ZmZlcikKewogIGlmIChSQU5ET01fQlVGX1NJWkUgPCBCeXRl Q291bnQpCiAgewogICAgUmVhZFJhbmRvbUJ5dGVzRnJvbVVERXYoQnl0ZUNvdW50LCBCdWZmZXIp OwogICAgcmV0dXJuOwogIH0KICBpZiAoUkFORE9NX0JVRl9TSVpFIDwgUmFuZG9tQnVmU3RhcnRQ b3MrQnl0ZUNvdW50KQogICAgUmFuZG9taXplQnVmZmVyKCk7CiAgaWYgKEJ5dGVDb3VudCA9PSAx KQogIHsKICAgIEJ1ZmZlclswXSA9IFJhbmRvbUJ1ZltSYW5kb21CdWZTdGFydFBvcysrXTsKICAg IHJldHVybjsKICB9CiAgbWVtY3B5KEJ1ZmZlciwgUmFuZG9tQnVmICsgUmFuZG9tQnVmU3RhcnRQ b3MsIEJ5dGVDb3VudCk7CiAgUmFuZG9tQnVmU3RhcnRQb3MgKz0gQnl0ZUNvdW50Owp9CnVpbnQ4 X3QgR2V0UmFuZG9tVUludDgodm9pZCkKewogIGlmIChSYW5kb21CdWZTdGFydFBvcyA+PSBSQU5E T01fQlVGX1NJWkUpCiAgICBSYW5kb21pemVCdWZmZXIoKTsKICByZXR1cm4gUmFuZG9tQnVmW1Jh bmRvbUJ1ZlN0YXJ0UG9zKytdOwp9CgoKLyogRnVuY3Rpb24gdXNlZCB0byBkZXRlcm1pbmUgaWYg ViBpcyB1bmlxdWUgYW1vbmcgdGhlIGZpcnN0IFBvcyBlbGVtZW50cwogKiBVc2VkIGJ5IHRoZSB4 b3JHZXRLZXkgZnVuY3Rpb24gdG8gY2hlY2sgcGFydGljbGUgbGVuZ3RoIHVuaXF1ZW5lc3MKICov CiNkZWZpbmUgTUFYX0JPRFlfU0laRSAxMDI0CgojZGVmaW5lIFNQX05VTV9KVU1QUyAwCiNkZWZp bmUgU1BfQk9EWV9MRU4gMQojZGVmaW5lIFNQX1NBTFRfREFUQSAzCiNkZWZpbmUgU1BfQk9EWSA3 CiNkZWZpbmUgR2V0Qm9keUxlbihLKSAoS1tTUF9CT0RZX0xFTl0gKyAyNTYgKiBLW1NQX0JPRFlf TEVOKzFdKQojZGVmaW5lIEdldEJvZHlQdHIoSykgKEsgKyBTUF9CT0RZKQojZGVmaW5lIEdldE51 bUp1bXBzKEspIChLW1NQX05VTV9KVU1QU10pCiNkZWZpbmUgeG9yQ29tcHV0ZUtleUJ1ZkxlbihC b2R5TGVuKSAoU1BfQk9EWStCb2R5TGVuKQoKLy8gQ3JlYXRlcyBYT1Iga2V5Ci8vIFRoZSBmaXJz dCBieXRlIHdpbGwgYmUgZXF1YWwgdG8gTnVtSnVtcHMKLy8gRm9sbG93aW5nIDIgYnl0ZXMgaXMg a2V5IGJvZHkgbGVuZ3RoCi8vIEZvbGxvd2luZyA0IGJ5dGVzIGFyZSByYW5kb20gc2FsdCBkYXRh Ci8vIEZvbGxvd2luZyBCb2R5TGVuIGJ5dGVzIGFyZSByYW5kb20gbnVtYmVycyBvYnRhaW5lZCBm cm9tIGJ1ZmZlcmVkIC9kZXYvdXJhbmRvbSBkYXRhLiBCT0RZTEVOIE1VU1QgQkUgQSBQT1dFUiBP RiAyIQovLyBSZXN1bHQgYnVmZmVyIG11c3QgYmUgZW5vdWdoIHRvIHN0b3JlIGtleSEhIE5vIGVy cm9yIGNoZWNraW5nIGlzIGRvbmUhISEKdm9pZCB4b3JHZXRLZXkodWludDhfdCBOdW1KdW1wcywg dWludDMyX3QgQm9keUxlbiwgdWludDhfdCAqS2V5QnVmKQp7CiAgYXNzZXJ0KE51bUp1bXBzID4g MSAmJiBCb2R5TGVuID4gMTUgJiYgTnVtSnVtcHM8TUFYX05VTV9KVU1QUyAmJiAoKEJvZHlMZW4t MSkmQm9keUxlbikgPT0gMCk7CiAgCiNpZmRlZiBWRVJCT1NFCiAgcHJpbnRmKCJHZW5lcmF0aW5n IGtleSAuLi4gQm9keUxlbjogJXUgTnVtSnVtcHM6ICV1XG4iLEJvZHlMZW4sTnVtSnVtcHMpOwoj ZW5kaWYKICBLZXlCdWZbU1BfTlVNX0pVTVBTXSA9ICh1aW50OF90KShOdW1KdW1wcyYyNTUpOwog IEtleUJ1ZltTUF9CT0RZX0xFTl0gPSAodWludDhfdCkoKEJvZHlMZW4gJSAyNTYpICYgMHhmZik7 CiAgS2V5QnVmW1NQX0JPRFlfTEVOKzFdID0gKHVpbnQ4X3QpKChCb2R5TGVuIC8gMjU2KSAmIDB4 ZmYpOwogIEdldFJhbmRvbU51bWJlcnMoU0FMVF9TSVpFICsgQm9keUxlbiwgS2V5QnVmICsgU1Bf U0FMVF9EQVRBKTsgLy8gRmlsbCA0IGJ5dGVzIHNhbHQgZGF0YSB3aXRoIHJhbmRvbSBudW1iZXJz Cn0KCnZvaWQgeG9yQW5hbHl6ZUtleSh1aW50OF90ICpLKQp7CiAgdWludDMyX3QgdDsKICAKICBw cmludGYoIi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIFNoaWZ0aW5nIHhvciBrZXkgYW5hbHl6 ZSAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tXG5OdW1KdW1wczogJXVcbkJvZHlMZW46ICV1 IG5TYWx0OiAiLCAKICAgICAgICAgS1swXSwgR2V0Qm9keUxlbihLKSk7CiAgZm9yICh0PTA7IHQg PCBTQUxUX1NJWkU7IHQrKykKICB7CiAgICBwcmludGYoIiAldSIsIEtbU1BfU0FMVF9EQVRBK3Rd KTsKICB9CiAgcHJpbnRmKCJcbiIpOwp9CgovLyBTdGFuZGFydCBDIGhhcyBub3QgUk9MIG9yIFJP UiBmdW5jdGlvbiwgYnV0IG1vc3QgbW9kZXJuIGNwdXMgaGFzIGluc3RydWN0aW9ucyBmb3IgY2ly Y3VsYXIgc2hpZnQgb3BlcmF0aW9ucwovLyBUaGlzIGlzIGEgcXVpY2sgYW5kIGRpcnR5IGNvZGUg Zm9yIHN0YW5kYXJ0IEMgdmVyc2lvbnMgYW5kIEludGVsIEZhbWlseSBjcHUgYXNzZW1ibGVyIG9w dGltaXplZCB2ZXJzaW9ucwoKI2RlZmluZSBHQ0NfSU5URUxfT1BUSU1JWkVEIAoKc3RhdGljIGlu bGluZSBpbnQgUk9MMzJfMShpbnQgdikgCnsKICAjaWYgZGVmaW5lZChfX0dOVUNfXykgIAogICAg I2lmIGRlZmluZWQoR0NDX0lOVEVMX09QVElNSVpFRCkKICAgICAgYXNtICgicm9sICUwOyIgOiI9 ciIodikgLyogb3V0cHV0ICovIDoiMCIodikgLyogaW5wdXQgKi8gKTsKICAgICAgcmV0dXJuIHY7 CiAgICAjZWxzZSAKICAgICAgcmV0dXJuICgoKHYpIDw8IDEpIHwgKCh2KSA+PiAzMSkpOwogICAg I2VuZGlmCiAgI2VuZGlmCn0Kc3RhdGljIGlubGluZSBpbnQgUk9SMzJfMShpbnQgdikgewogICNp ZiBkZWZpbmVkKF9fR05VQ19fKSAgCiAgICAjaWYgZGVmaW5lZChHQ0NfSU5URUxfT1BUSU1JWkVE KQogICAgICBhc20gKCJyb3IgJTA7IiA6Ij1yIih2KSAvKiBvdXRwdXQgKi8gOiIwIih2KSAvKiBp bnB1dCAqLyApOwogICAgICByZXR1cm4gdjsKICAgICNlbHNlIAogICAgICByZXR1cm4gKCgodikg Pj4gMSkgfCAoKHYpIDw8IDMxKSkKICAgICNlbmRpZgogICNlbmRpZgp9Ci8qIFVOT1BUSU1JWkVE IFZFUlNJT04gZm9yIEJFVFRFUiBVTkRFUlNUQU5ESU5HIE9GIFRIRSBGVU5DVElPTklORyBPRiBU SEUgQUxHT1JJVEhNLiBJVCBJUyBOT1QgVVNFRCBJTiBSRUFMIExJRkUuIFVTRSBPUFRJTUlaRUQg VkVSU0lPTlMhCiAqIEVuY3J5cHRzIG9yIGRlY3J5cHRzIEluT3V0QnVmIAogKiBLZXlCdWYgaXMg dGhlIHJhdyBrZXkgYnVmZmVyCiAqIEtleUNoZWNrU3VtIGlzIHRoZSBzdW0gb2YgYWxsIGtleSBj b25zdGl0dWVudHMqMy4gSElHSCBCSVQgTVVTVCBCRSBTRVQhIAogKiAgIFVzZWQgdG8gcHJldmVu dCAiUmVsYXRlZCBrZXkgYXR0YWNrcyIuIElmIHNvbWUgYml0cyBvZiB0aGUga2V5IGNoYW5nZXMs IGVudGlyZSBjeXBoZXJ0ZXh0IGNoYW5nZXMKICogSW5PdXREYXRhTGVuIGlzIHRoZSBsZW5ndGgg b2YgdGhlIGRhdGEgdG8gYmUgZW5jcnlwdGVkIG9yIGRlY3J5cHRlZAogKiBJbk91dEJ1ZiBpcyB0 aGUgcG9pbnRlciB0byB0aGUgZGF0YSB0byBiZSBlbmNyeXB0ZWQgb3IgZGVjcnlwdGVkCiAqIEFm dGVyIGV2ZXJ5IGVuY3J5cHRpb24gb3IgZGVjcnlwdGlvbiwgdGhlIHZhbHVlIG9mIHNhbHQgd2ls bCBiZSBzZXQgdG8gdGhlIG9yaWdpbmFsIG9uZQogKiBTbywgYmVmb3JlIGVuY3J5cHRpb24gb3Ig ZGVjcnlwdGlvbiwgaWYgeW91IHdhbnQgdG8gdXNlIGEgc3BlY2lmaWMgc2FsdCB2YWx1ZSwgYXNz aWduIHRoYXQgdG8gSydzIFNhbHQgdmFsdWUuIEVuYyBvciBEZWMgd2lsbCBiZSBkb25lIHdpdGgg dGhhdCB2YWx1ZQogKiBhbmQgYXQgdGhlIGVuZCBvZiB0aGUgZnVuY3Rpb24sIHRoZSBzYWx0IHZh bHVlIHdpbGwgYmUgc2V0IGJhY2sgdG8gaXRzIG9yaWdpbmFsIHN0YXRlCiAqIFRoaXMgbG9naWMg ZW5zdXJlcyB1cyB0aGlzOiBBbiBvcmlnaW5hbCBrZXkgaXMgY3JlYXRlZCB3aXRoIGFuIG9yaWdp bmFsIHNhbHQgdmFsdWUsIGZvciBleGFtcGxlIGZvciBhbiBvbmxpbmUgY29tbXVuaWNhdGlvbgog KiBmb3IgZWFjaCBkaXN0aW5jdCBwYWNrZXQsIGluIHRoZSBwYWNrZXQgaGVhZGVyLCB3ZSBjYW4g dHJhbnNtaXQgYSBzcGVjaWZpYyBzYWx0IHZhbHVlIGZvciB0aGF0IHBhY2tldCBhbmQgd2UgY2Fu IGVuY3J5cHQgaXQgd2l0aCBvcmlnaW5hbCBrZXkgYW5kIHNhbHQKICogd2hlbiB0aGUgcmVjZWl2 ZXIgcmVjZWl2ZXMgdGhlIHBhY2tldCwgZGVjcnlwdHMgdGhlIG5ldyBzYWx0IHZhbHVlIHdpdGgg dGhlIG9yaWdpbmFsIHNhbHQgdmFsdWUsIHNldCB0aGF0IHNhbHQgdmFsdWUgYXMgdGhlIG5ldyBz YWx0IHZhbHVlCiAqIGFuZCBkZWNyeXB0cyB0aGUgcGFja2V0IGJvZHkgd2l0aCB0aGF0IHNhbHQg dmFsdWUKICovCgojZGVmaW5lIE1ha2VYT1JFbmMoSW5PdXRCdWYsWE9SVmFsLFNhbHQsS2V5Q2hl Y2tTdW0sUGxhaW5UZXh0Q2hlY2tzdW0sTGFzdFZhbCxUbXBWYWwsQ291bnRlcilcClBsYWluVGV4 dENoZWNrc3VtICs9IEluT3V0QnVmW0NvdW50ZXJdOyBcClRtcFZhbCA9IEluT3V0QnVmW0NvdW50 ZXJdOyBcClhPUlZhbCBePSBMYXN0VmFsOyBcClhPUlZhbCBePSAqKFNhbHQgKyAoTGFzdFZhbCYo U0FMVF9TSVpFLTEpKSk7IFwKSW5PdXRCdWZbQ291bnRlcl0gXj0gKCh1aW50OF90KShYT1JWYWwp KTsgXApMYXN0VmFsID0gVG1wVmFsOyAKCiNkZWZpbmUgTWFrZVhPUkRlYyhJbk91dEJ1ZixYT1JW YWwsU2FsdCxLZXlDaGVja1N1bSxQbGFpblRleHRDaGVja3N1bSxMYXN0VmFsLENvdW50ZXIpXApY T1JWYWwgXj0gTGFzdFZhbDsgXApYT1JWYWwgXj0gKihTYWx0ICsgKExhc3RWYWwmKFNBTFRfU0la RS0xKSkpOyBcCkluT3V0QnVmW0NvdW50ZXJdIF49ICgodWludDhfdCkoWE9SVmFsKSk7IFwKTGFz dFZhbCA9IEluT3V0QnVmW0NvdW50ZXJdOyBcClBsYWluVGV4dENoZWNrc3VtICs9IExhc3RWYWw7 IAoKLy9TYWx0W0NvdW50ZXImU0FMVF9TSVpFXSsrOyBYT1JWYWwgXj0gKEtleUNoZWNrU3VtIF4g U2FsdFtDb3VudGVyJlNBTFRfU0laRV0pOyAKLyogOC1iaXQgQ1JDIHdpdGggcG9seW5vbWlhbCB4 XjgreF42K3heMyt4XjIrMSwgMHgxNEQuCiAgIENob3NlbiBiYXNlZCBvbiBLb29wbWFuLCBldCBh bC4gKDB4QTYgaW4gaGlzIG5vdGF0aW9uID0gMHgxNEQgPj4gMSk6CiAgIGh0dHA6Ly93d3cuZWNl LmNtdS5lZHUvfmtvb3BtYW4vcm9zZXMvZHNuMDQva29vcG1hbjA0X2NyY19wb2x5X2VtYmVkZGVk LnBkZgogKi8KCgpzdGF0aWMgdWludDhfdCBjcmM4X3RhYmxlW10gPSB7CiAgICAweDAwLCAweDNl LCAweDdjLCAweDQyLCAweGY4LCAweGM2LCAweDg0LCAweGJhLCAweDk1LCAweGFiLCAweGU5LCAw eGQ3LAogICAgMHg2ZCwgMHg1MywgMHgxMSwgMHgyZiwgMHg0ZiwgMHg3MSwgMHgzMywgMHgwZCwg MHhiNywgMHg4OSwgMHhjYiwgMHhmNSwKICAgIDB4ZGEsIDB4ZTQsIDB4YTYsIDB4OTgsIDB4MjIs IDB4MWMsIDB4NWUsIDB4NjAsIDB4OWUsIDB4YTAsIDB4ZTIsIDB4ZGMsCiAgICAweDY2LCAweDU4 LCAweDFhLCAweDI0LCAweDBiLCAweDM1LCAweDc3LCAweDQ5LCAweGYzLCAweGNkLCAweDhmLCAw eGIxLAogICAgMHhkMSwgMHhlZiwgMHhhZCwgMHg5MywgMHgyOSwgMHgxNywgMHg1NSwgMHg2Yiwg MHg0NCwgMHg3YSwgMHgzOCwgMHgwNiwKICAgIDB4YmMsIDB4ODIsIDB4YzAsIDB4ZmUsIDB4NTks IDB4NjcsIDB4MjUsIDB4MWIsIDB4YTEsIDB4OWYsIDB4ZGQsIDB4ZTMsCiAgICAweGNjLCAweGYy LCAweGIwLCAweDhlLCAweDM0LCAweDBhLCAweDQ4LCAweDc2LCAweDE2LCAweDI4LCAweDZhLCAw eDU0LAogICAgMHhlZSwgMHhkMCwgMHg5MiwgMHhhYywgMHg4MywgMHhiZCwgMHhmZiwgMHhjMSwg MHg3YiwgMHg0NSwgMHgwNywgMHgzOSwKICAgIDB4YzcsIDB4ZjksIDB4YmIsIDB4ODUsIDB4M2Ys IDB4MDEsIDB4NDMsIDB4N2QsIDB4NTIsIDB4NmMsIDB4MmUsIDB4MTAsCiAgICAweGFhLCAweDk0 LCAweGQ2LCAweGU4LCAweDg4LCAweGI2LCAweGY0LCAweGNhLCAweDcwLCAweDRlLCAweDBjLCAw eDMyLAogICAgMHgxZCwgMHgyMywgMHg2MSwgMHg1ZiwgMHhlNSwgMHhkYiwgMHg5OSwgMHhhNywg MHhiMiwgMHg4YywgMHhjZSwgMHhmMCwKICAgIDB4NGEsIDB4NzQsIDB4MzYsIDB4MDgsIDB4Mjcs IDB4MTksIDB4NWIsIDB4NjUsIDB4ZGYsIDB4ZTEsIDB4YTMsIDB4OWQsCiAgICAweGZkLCAweGMz LCAweDgxLCAweGJmLCAweDA1LCAweDNiLCAweDc5LCAweDQ3LCAweDY4LCAweDU2LCAweDE0LCAw eDJhLAogICAgMHg5MCwgMHhhZSwgMHhlYywgMHhkMiwgMHgyYywgMHgxMiwgMHg1MCwgMHg2ZSwg MHhkNCwgMHhlYSwgMHhhOCwgMHg5NiwKICAgIDB4YjksIDB4ODcsIDB4YzUsIDB4ZmIsIDB4NDEs IDB4N2YsIDB4M2QsIDB4MDMsIDB4NjMsIDB4NWQsIDB4MWYsIDB4MjEsCiAgICAweDliLCAweGE1 LCAweGU3LCAweGQ5LCAweGY2LCAweGM4LCAweDhhLCAweGI0LCAweDBlLCAweDMwLCAweDcyLCAw eDRjLAogICAgMHhlYiwgMHhkNSwgMHg5NywgMHhhOSwgMHgxMywgMHgyZCwgMHg2ZiwgMHg1MSwg MHg3ZSwgMHg0MCwgMHgwMiwgMHgzYywKICAgIDB4ODYsIDB4YjgsIDB4ZmEsIDB4YzQsIDB4YTQs IDB4OWEsIDB4ZDgsIDB4ZTYsIDB4NWMsIDB4NjIsIDB4MjAsIDB4MWUsCiAgICAweDMxLCAweDBm LCAweDRkLCAweDczLCAweGM5LCAweGY3LCAweGI1LCAweDhiLCAweDc1LCAweDRiLCAweDA5LCAw eDM3LAogICAgMHg4ZCwgMHhiMywgMHhmMSwgMHhjZiwgMHhlMCwgMHhkZSwgMHg5YywgMHhhMiwg MHgxOCwgMHgyNiwgMHg2NCwgMHg1YSwKICAgIDB4M2EsIDB4MDQsIDB4NDYsIDB4NzgsIDB4YzIs IDB4ZmMsIDB4YmUsIDB4ODAsIDB4YWYsIDB4OTEsIDB4ZDMsIDB4ZWQsCiAgICAweDU3LCAweDY5 LCAweDJiLCAweDE1fTsKCnVpbnQ4X3QgY3JjOCh1aW50OF90IGNyYywgdWludDhfdCAqZGF0YSwg c2l6ZV90IGxlbikKewogIHVpbnQ4X3QgKmVuZDsKCiAgaWYgKGxlbiA9PSAwKQogICAgcmV0dXJu IGNyYzsKICBjcmMgXj0gMHhmZjsKICBlbmQgPSBkYXRhICsgbGVuOwogIGRvIHsKICAgIGNyYyA9 IGNyYzhfdGFibGVbY3JjIF4gKmRhdGErK107CiAgfSB3aGlsZSAoZGF0YSA8IGVuZCk7CiAgcmV0 dXJuIGNyYyBeIDB4ZmY7Cn0KCiNkZWZpbmUgeG9yQ29tcHV0ZUtleUNoZWNrU3VtKEspIGNyYzgo MCwgSywgU1BfQk9EWSArIEdldEJvZHlMZW4oSykpCgp1bnNpZ25lZCBsb25nIGxvbmcgaW50IHhv ckVuY3J5cHQodWludDhfdCAqSywgdWludDhfdCAqU2FsdCwgdWludDhfdCBLZXlDaGVja1N1bSwg dWludDMyX3QgSW5PdXREYXRhTGVuLCB1aW50OF90ICpJbk91dEJ1ZikKeyAvLyBFbmNyeXB0cyBv ciBkZWNyeXB0cyBtZXNzYWdlIGFuZCByZXR1cm5zIGNoZWNrc3VtIG9mIHRoZSBJbk91dEJ1ZiBC RUZPUkUgZW5jeXB0aW9uCiAgLy8gU2FsdERhdGEgaXMgYSA0IGJ5dGVzIHVpbnQ4IGFycmF5ISBJ VCBJUyBOT1QgUkVBRCBPTkxZISBJVCBXSUxMIEJFIE1BTklQVUxBVEVEIEJZIFRIRSBGVU5DVElP TiEKICByZWdpc3RlciB1aW50MzJfdCB0LCB0dCwgTTsKICByZWdpc3RlciB1aW50OF90IFhPUlZh bCwgTGFzdFZhbCA9IDAsVG1wVmFsOyAvLyBMYXN0IFBMQUlOVEVYVCBieXRlIHByb2Nlc3NlZC4g SXQgd2lsbCBiZSBhbiBpbnB1dCBwYXJhbWV0ZXIgZm9yIHRoZSBuZXh0IGVuY3J5dHBpb24KICBy ZWdpc3RlciB1aW50NjRfdCBDaGVja3N1bT0wOwogIHJlZ2lzdGVyIHVpbnQzMl90IEJvZHlNYXNr ID0gR2V0Qm9keUxlbihLKTsgLy8gKzEgYmVjYXVzZSB3ZSB3aWxsIHVzZSB0aGlzICJNZXJzZW5u ZSBudW1iZXIiIGZvciAmIG9wZXJhdGlvbiBpbnN0ZWFkIG9mIG1vZHVsdXMgb3BlcmF0aW9uCiAg dWludDhfdCBCb2R5W01BWF9CT0RZX1NJWkVdOwogIAogIG1lbWNweShCb2R5LEsrU1BfQk9EWSxC b2R5TWFzayk7CiAgQm9keU1hc2stLTsKICAKICBTYWx0WzBdIF49IEtleUNoZWNrU3VtOwogIFNh bHRbMV0gXj0gS2V5Q2hlY2tTdW07CiAgU2FsdFsyXSBePSBLZXlDaGVja1N1bTsKICBTYWx0WzNd IF49IEtleUNoZWNrU3VtOwogIAogIC8vIEluaXRpYWwgcG9zaXRpb24gb2YgdGhlIHBvaW50ZXIg aXMgZGVwZW5kZW50IG9uIGFjdHVhbCBzYWx0IHZhbHVlCiAgTSA9IEJvZHlNYXNrICYgU2FsdFsw XTsKICAvL3ByaW50ZigieG9yRW5jcnlwdCBCb2R5TGVuOiAldSBLZXlDaGVja1N1bTogJXUgU2Fs dDogJXVcbiIsQm9keUxlbiwgS2V5Q2hlY2tTdW0sU2FsdCk7CiAgCiAgZm9yICh0PTA7IHQ8SW5P dXREYXRhTGVuOyB0KyspCiAgewogICAgLy8gRmlyc3QganVtcCBzdGVwIGlzIHByZXZpb3VzIHBs YWludGV4dCBieXRlCiAgICBYT1JWYWwgPSBCb2R5W01dOyAKICAgIE0gPSAoTSArIExhc3RWYWwp ICYgQm9keU1hc2s7IAoKICAgIGZvciAodHQ9MTsgdHQgPCBHZXROdW1KdW1wcyhLKTsgdHQrKykK ICAgIHsKICAgICAgLy8gQWxsIGZvbGxvd2luZyBqdW1wcyBhcmUgYmFzZWQgb24gYm9keSB2YWx1 ZXMKICAgICAgWE9SVmFsIF49IEJvZHlbTV07IAogICAgICBNID0gKE0gKyBCb2R5W01dKSAmIEJv ZHlNYXNrOyAKICAgIH0KICAgIE1ha2VYT1JFbmMoSW5PdXRCdWYsWE9SVmFsLFNhbHQsS2V5Q2hl Y2tTdW0sQ2hlY2tzdW0sTGFzdFZhbCxUbXBWYWwsdCk7CiAgICBCb2R5W01dKys7CiAgfQogIHJl dHVybiBDaGVja3N1bTsKfSAKdW5zaWduZWQgbG9uZyBsb25nIGludCB4b3JEZWNyeXB0KHVpbnQ4 X3QgKkssIHVpbnQ4X3QgKlNhbHQsIHVpbnQ4X3QgS2V5Q2hlY2tTdW0sIHVpbnQzMl90IEluT3V0 RGF0YUxlbiwgdWludDhfdCAqSW5PdXRCdWYpCnsgLy8gRGVjcnlwdHMgbWVzc2FnZSBhbmQgcmV0 dXJucyBjaGVja3N1bSBvZiB0aGUgSW5PdXRCdWYgQUZURVIgZW5jeXB0aW9uCiAgLy8gU2FsdERh dGEgaXMgYSA0IGJ5dGVzIHVpbnQ4IGFycmF5ISBJVCBJUyBOT1QgUkVBRCBPTkxZISBJVCBXSUxM IEJFIE1BTklQVUxBVEVEIEJZIFRIRSBGVU5DVElPTiEKICByZWdpc3RlciB1aW50MzJfdCB0LCB0 dCwgTTsKICByZWdpc3RlciB1aW50OF90IFhPUlZhbCwgTGFzdFZhbCA9IDA7IC8vIExhc3QgUExB SU5URVhUIGJ5dGUgcHJvY2Vzc2VkLiBJdCB3aWxsIGJlIGFuIGlucHV0IHBhcmFtZXRlciBmb3Ig dGhlIG5leHQgZW5jcnl0cGlvbgogIHJlZ2lzdGVyIHVpbnQ2NF90IENoZWNrc3VtPTA7CiAgcmVn aXN0ZXIgdWludDMyX3QgQm9keU1hc2sgPSBHZXRCb2R5TGVuKEspOyAvLyArMSBiZWNhdXNlIHdl IHdpbGwgdXNlIHRoaXMgIk1lcnNlbm5lIG51bWJlciIgZm9yICYgb3BlcmF0aW9uIGluc3RlYWQg b2YgbW9kdWx1cyBvcGVyYXRpb24KICB1aW50OF90IEJvZHlbTUFYX0JPRFlfU0laRV07CiAgCiAg bWVtY3B5KEJvZHksSytTUF9CT0RZLEJvZHlNYXNrKTsKICBCb2R5TWFzay0tOwogIAogIFNhbHRb MF0gXj0gS2V5Q2hlY2tTdW07CiAgU2FsdFsxXSBePSBLZXlDaGVja1N1bTsKICBTYWx0WzJdIF49 IEtleUNoZWNrU3VtOwogIFNhbHRbM10gXj0gS2V5Q2hlY2tTdW07CiAgCiAgLy8gSW5pdGlhbCBw b3NpdGlvbiBvZiB0aGUgcG9pbnRlciBpcyBkZXBlbmRlbnQgb24gYWN0dWFsIHNhbHQgdmFsdWUK ICBNID0gQm9keU1hc2sgJiBTYWx0WzBdOwogIC8vcHJpbnRmKCJ4b3JFbmNyeXB0IEJvZHlMZW46 ICV1IEtleUNoZWNrU3VtOiAldSBTYWx0OiAldVxuIixCb2R5TGVuLCBLZXlDaGVja1N1bSxTYWx0 KTsKICAKICBmb3IgKHQ9MDsgdDxJbk91dERhdGFMZW47IHQrKykKICB7CiAgICAvLyBGaXJzdCBq dW1wIHN0ZXAgaXMgcHJldmlvdXMgcGxhaW50ZXh0IGJ5dGUKICAgIFhPUlZhbCA9IEJvZHlbTV07 IAogICAgTSA9IChNICsgTGFzdFZhbCkgJiBCb2R5TWFzazsgCgogICAgZm9yICh0dD0xOyB0dCA8 IEdldE51bUp1bXBzKEspOyB0dCsrKQogICAgewogICAgICAvLyBBbGwgZm9sbG93aW5nIGp1bXBz IGFyZSBiYXNlZCBvbiBib2R5IHZhbHVlcwogICAgICBYT1JWYWwgXj0gQm9keVtNXTsgCiAgICAg IE0gPSAoTSArIEJvZHlbTV0pICYgQm9keU1hc2s7IAogICAgfQogICAgTWFrZVhPUkRlYyhJbk91 dEJ1ZixYT1JWYWwsU2FsdCxLZXlDaGVja1N1bSxDaGVja3N1bSxMYXN0VmFsLHQpOwogICAgQm9k eVtNXSsrOwogIH0KICByZXR1cm4gQ2hlY2tzdW07Cn0gCgp1bnNpZ25lZCBsb25nIGxvbmcgaW50 IHhvckVuY3J5cHRIT1AyKHVpbnQ4X3QgKkssIHVpbnQ4X3QgKlNhbHQsIHVpbnQ4X3QgS2V5Q2hl Y2tTdW0sIHVpbnQzMl90IEluT3V0RGF0YUxlbiwgdWludDhfdCAqSW5PdXRCdWYpCnsgLy8gRW5j cnlwdHMgb3IgZGVjcnlwdHMgbWVzc2FnZSBhbmQgcmV0dXJucyBjaGVja3N1bSBvZiB0aGUgSW5P dXRCdWYgQkVGT1JFIGVuY3lwdGlvbgogIC8vIFNhbHREYXRhIGlzIGEgNCBieXRlcyB1aW50OCBh cnJheSEgSVQgSVMgTk9UIFJFQUQgT05MWSEgSVQgV0lMTCBCRSBNQU5JUFVMQVRFRCBCWSBUSEUg RlVOQ1RJT04hCiAgcmVnaXN0ZXIgdWludDMyX3QgdCwgTTsKICByZWdpc3RlciB1aW50OF90IFhP UlZhbCwgTGFzdFZhbCA9IDAsVG1wVmFsOyAvLyBMYXN0IFBMQUlOVEVYVCBieXRlIHByb2Nlc3Nl ZC4gSXQgd2lsbCBiZSBhbiBpbnB1dCBwYXJhbWV0ZXIgZm9yIHRoZSBuZXh0IGVuY3J5dHBpb24K ICByZWdpc3RlciB1aW50NjRfdCBDaGVja3N1bT0wOwogIHJlZ2lzdGVyIHVpbnQzMl90IEJvZHlN YXNrID0gR2V0Qm9keUxlbihLKTsgLy8gKzEgYmVjYXVzZSB3ZSB3aWxsIHVzZSB0aGlzICJNZXJz ZW5uZSBudW1iZXIiIGZvciAmIG9wZXJhdGlvbiBpbnN0ZWFkIG9mIG1vZHVsdXMgb3BlcmF0aW9u CiAgdWludDhfdCBCb2R5W01BWF9CT0RZX1NJWkVdOwogIAogIG1lbWNweShCb2R5LEsrU1BfQk9E WSxCb2R5TWFzayk7CiAgQm9keU1hc2stLTsKICAKICBTYWx0WzBdIF49IEtleUNoZWNrU3VtOwog IFNhbHRbMV0gXj0gS2V5Q2hlY2tTdW07CiAgU2FsdFsyXSBePSBLZXlDaGVja1N1bTsKICBTYWx0 WzNdIF49IEtleUNoZWNrU3VtOwogIAogIC8vIEluaXRpYWwgcG9zaXRpb24gb2YgdGhlIHBvaW50 ZXIgaXMgZGVwZW5kZW50IG9uIGFjdHVhbCBzYWx0IHZhbHVlCiAgTSA9IEJvZHlNYXNrICYgU2Fs dFswXTsKICAvL3ByaW50ZigieG9yRW5jcnlwdCBCb2R5TGVuOiAldSBLZXlDaGVja1N1bTogJXUg U2FsdDogJXVcbiIsQm9keUxlbiwgS2V5Q2hlY2tTdW0sU2FsdCk7CiAgZm9yICh0PTA7IHQ8SW5P dXREYXRhTGVuOyB0KyspCiAgewogICAgLy8gRmlyc3QganVtcCBzdGVwIGlzIHByZXZpb3VzIHBs YWludGV4dCBieXRlCiAgICBYT1JWYWwgPSBCb2R5W01dOyAKICAgIE0gPSAoTSArIExhc3RWYWwp ICYgQm9keU1hc2s7IAogICAgLy8gQWxsIGZvbGxvd2luZyBqdW1wcyBhcmUgYmFzZWQgb24gYm9k eSB2YWx1ZXMKICAgIFhPUlZhbCBePSBCb2R5W01dOyAKICAgIE0gPSAoTSArIEJvZHlbTV0pICYg Qm9keU1hc2s7IAogICAgTWFrZVhPUkVuYyhJbk91dEJ1ZixYT1JWYWwsU2FsdCxLZXlDaGVja1N1 bSxDaGVja3N1bSxMYXN0VmFsLFRtcFZhbCx0KTsKICAgIEJvZHlbTV0rKzsKICB9CiAgcmV0dXJu IENoZWNrc3VtOwp9IAoKdW5zaWduZWQgbG9uZyBsb25nIGludCB4b3JEZWNyeXB0SE9QMih1aW50 OF90ICpLLCB1aW50OF90ICpTYWx0LCB1aW50OF90IEtleUNoZWNrU3VtLCB1aW50MzJfdCBJbk91 dERhdGFMZW4sIHVpbnQ4X3QgKkluT3V0QnVmKQp7IC8vIEVuY3J5cHRzIG9yIGRlY3J5cHRzIG1l c3NhZ2UgYW5kIHJldHVybnMgY2hlY2tzdW0gb2YgdGhlIEluT3V0QnVmIEJFRk9SRSBlbmN5cHRp b24KICAvLyBTYWx0RGF0YSBpcyBhIDQgYnl0ZXMgdWludDggYXJyYXkhIElUIElTIE5PVCBSRUFE IE9OTFkhIElUIFdJTEwgQkUgTUFOSVBVTEFURUQgQlkgVEhFIEZVTkNUSU9OIQogIHJlZ2lzdGVy IHVpbnQzMl90IHQsIE07CiAgcmVnaXN0ZXIgdWludDhfdCBYT1JWYWwsIExhc3RWYWwgPSAwOyAv LyBMYXN0IFBMQUlOVEVYVCBieXRlIHByb2Nlc3NlZC4gSXQgd2lsbCBiZSBhbiBpbnB1dCBwYXJh bWV0ZXIgZm9yIHRoZSBuZXh0IGVuY3J5dHBpb24KICByZWdpc3RlciB1aW50NjRfdCBDaGVja3N1 bT0wOwogIHJlZ2lzdGVyIHVpbnQzMl90IEJvZHlNYXNrID0gR2V0Qm9keUxlbihLKTsgLy8gKzEg YmVjYXVzZSB3ZSB3aWxsIHVzZSB0aGlzICJNZXJzZW5uZSBudW1iZXIiIGZvciAmIG9wZXJhdGlv biBpbnN0ZWFkIG9mIG1vZHVsdXMgb3BlcmF0aW9uCiAgdWludDhfdCBCb2R5W01BWF9CT0RZX1NJ WkVdOwogIAogIG1lbWNweShCb2R5LEsrU1BfQk9EWSxCb2R5TWFzayk7CiAgQm9keU1hc2stLTsK ICAKICBTYWx0WzBdIF49IEtleUNoZWNrU3VtOwogIFNhbHRbMV0gXj0gS2V5Q2hlY2tTdW07CiAg U2FsdFsyXSBePSBLZXlDaGVja1N1bTsKICBTYWx0WzNdIF49IEtleUNoZWNrU3VtOwogIAogIC8v IEluaXRpYWwgcG9zaXRpb24gb2YgdGhlIHBvaW50ZXIgaXMgZGVwZW5kZW50IG9uIGFjdHVhbCBz YWx0IHZhbHVlCiAgTSA9IEJvZHlNYXNrICYgU2FsdFswXTsKICAvL3ByaW50ZigieG9yRW5jcnlw dCBCb2R5TGVuOiAldSBLZXlDaGVja1N1bTogJXUgU2FsdDogJXVcbiIsQm9keUxlbiwgS2V5Q2hl Y2tTdW0sU2FsdCk7CiAgCiAgZm9yICh0PTA7IHQ8SW5PdXREYXRhTGVuOyB0KyspCiAgewogICAg Ly8gRmlyc3QganVtcCBzdGVwIGlzIHByZXZpb3VzIHBsYWludGV4dCBieXRlCiAgICBYT1JWYWwg PSBCb2R5W01dOyAKICAgIE0gPSAoTSArIExhc3RWYWwpICYgQm9keU1hc2s7IAogICAgLy8gQWxs IGZvbGxvd2luZyBqdW1wcyBhcmUgYmFzZWQgb24gYm9keSB2YWx1ZXMKICAgIFhPUlZhbCBePSBC b2R5W01dOyAKICAgIE0gPSAoTSArIEJvZHlbTV0pICYgQm9keU1hc2s7IAogICAgTWFrZVhPUkRl YyhJbk91dEJ1ZixYT1JWYWwsU2FsdCxLZXlDaGVja1N1bSxDaGVja3N1bSxMYXN0VmFsLHQpOwog ICAgQm9keVtNXSsrOwogIH0KICByZXR1cm4gQ2hlY2tzdW07Cn0gCnVuc2lnbmVkIGxvbmcgbG9u ZyBpbnQgeG9yRW5jcnlwdEhPUDModWludDhfdCAqSywgdWludDhfdCAqU2FsdCwgdWludDhfdCBL ZXlDaGVja1N1bSwgdWludDMyX3QgSW5PdXREYXRhTGVuLCB1aW50OF90ICpJbk91dEJ1ZikKeyAv LyBFbmNyeXB0cyBvciBkZWNyeXB0cyBtZXNzYWdlIGFuZCByZXR1cm5zIGNoZWNrc3VtIG9mIHRo ZSBJbk91dEJ1ZiBCRUZPUkUgZW5jeXB0aW9uCiAgLy8gU2FsdERhdGEgaXMgYSA0IGJ5dGVzIHVp bnQ4IGFycmF5ISBJVCBJUyBOT1QgUkVBRCBPTkxZISBJVCBXSUxMIEJFIE1BTklQVUxBVEVEIEJZ IFRIRSBGVU5DVElPTiEKICByZWdpc3RlciB1aW50MzJfdCB0LCBNOwogIHJlZ2lzdGVyIHVpbnQ4 X3QgWE9SVmFsLCBMYXN0VmFsID0gMCxUbXBWYWw7IC8vIExhc3QgUExBSU5URVhUIGJ5dGUgcHJv Y2Vzc2VkLiBJdCB3aWxsIGJlIGFuIGlucHV0IHBhcmFtZXRlciBmb3IgdGhlIG5leHQgZW5jcnl0 cGlvbgogIHJlZ2lzdGVyIHVpbnQ2NF90IENoZWNrc3VtPTA7CiAgcmVnaXN0ZXIgdWludDMyX3Qg Qm9keU1hc2sgPSBHZXRCb2R5TGVuKEspOyAvLyArMSBiZWNhdXNlIHdlIHdpbGwgdXNlIHRoaXMg Ik1lcnNlbm5lIG51bWJlciIgZm9yICYgb3BlcmF0aW9uIGluc3RlYWQgb2YgbW9kdWx1cyBvcGVy YXRpb24KICB1aW50OF90IEJvZHlbTUFYX0JPRFlfU0laRV07CiAgCiAgbWVtY3B5KEJvZHksSytT UF9CT0RZLEJvZHlNYXNrKTsKICBCb2R5TWFzay0tOwogIAogIFNhbHRbMF0gXj0gS2V5Q2hlY2tT dW07CiAgU2FsdFsxXSBePSBLZXlDaGVja1N1bTsKICBTYWx0WzJdIF49IEtleUNoZWNrU3VtOwog IFNhbHRbM10gXj0gS2V5Q2hlY2tTdW07CiAgCiAgLy8gSW5pdGlhbCBwb3NpdGlvbiBvZiB0aGUg cG9pbnRlciBpcyBkZXBlbmRlbnQgb24gYWN0dWFsIHNhbHQgdmFsdWUKICBNID0gQm9keU1hc2sg JiBTYWx0WzBdOwogIC8vcHJpbnRmKCJ4b3JFbmNyeXB0IEJvZHlMZW46ICV1IEtleUNoZWNrU3Vt OiAldSBTYWx0OiAldVxuIixCb2R5TGVuLCBLZXlDaGVja1N1bSxTYWx0KTsKICBmb3IgKHQ9MDsg dDxJbk91dERhdGFMZW47IHQrKykKICB7CiAgICAvLyBGaXJzdCBqdW1wIHN0ZXAgaXMgcHJldmlv dXMgcGxhaW50ZXh0IGJ5dGUKICAgIFhPUlZhbCA9IEJvZHlbTV07IAogICAgTSA9IChNICsgTGFz dFZhbCkgJiBCb2R5TWFzazsgCiAgICAvLyBBbGwgZm9sbG93aW5nIGp1bXBzIGFyZSBiYXNlZCBv biBib2R5IHZhbHVlcwogICAgWE9SVmFsIF49IEJvZHlbTV07IAogICAgTSA9IChNICsgQm9keVtN XSkgJiBCb2R5TWFzazsgCiAgICBYT1JWYWwgXj0gQm9keVtNXTsgCiAgICBNID0gKE0gKyBCb2R5 W01dKSAmIEJvZHlNYXNrOyAKICAgIE1ha2VYT1JFbmMoSW5PdXRCdWYsWE9SVmFsLFNhbHQsS2V5 Q2hlY2tTdW0sQ2hlY2tzdW0sTGFzdFZhbCxUbXBWYWwsdCk7CiAgICBCb2R5W01dKys7CiAgfQog IHJldHVybiBDaGVja3N1bTsKfSAKCnVuc2lnbmVkIGxvbmcgbG9uZyBpbnQgeG9yRGVjcnlwdEhP UDModWludDhfdCAqSywgdWludDhfdCAqU2FsdCwgdWludDhfdCBLZXlDaGVja1N1bSwgdWludDMy X3QgSW5PdXREYXRhTGVuLCB1aW50OF90ICpJbk91dEJ1ZikKeyAvLyBFbmNyeXB0cyBvciBkZWNy eXB0cyBtZXNzYWdlIGFuZCByZXR1cm5zIGNoZWNrc3VtIG9mIHRoZSBJbk91dEJ1ZiBCRUZPUkUg ZW5jeXB0aW9uCiAgLy8gU2FsdERhdGEgaXMgYSA0IGJ5dGVzIHVpbnQ4IGFycmF5ISBJVCBJUyBO T1QgUkVBRCBPTkxZISBJVCBXSUxMIEJFIE1BTklQVUxBVEVEIEJZIFRIRSBGVU5DVElPTiEKICBy ZWdpc3RlciB1aW50MzJfdCB0LCBNOwogIHJlZ2lzdGVyIHVpbnQ4X3QgWE9SVmFsLCBMYXN0VmFs ID0gMDsgLy8gTGFzdCBQTEFJTlRFWFQgYnl0ZSBwcm9jZXNzZWQuIEl0IHdpbGwgYmUgYW4gaW5w dXQgcGFyYW1ldGVyIGZvciB0aGUgbmV4dCBlbmNyeXRwaW9uCiAgcmVnaXN0ZXIgdWludDY0X3Qg Q2hlY2tzdW09MDsKICByZWdpc3RlciB1aW50MzJfdCBCb2R5TWFzayA9IEdldEJvZHlMZW4oSyk7 IC8vICsxIGJlY2F1c2Ugd2Ugd2lsbCB1c2UgdGhpcyAiTWVyc2VubmUgbnVtYmVyIiBmb3IgJiBv cGVyYXRpb24gaW5zdGVhZCBvZiBtb2R1bHVzIG9wZXJhdGlvbgogIHVpbnQ4X3QgQm9keVtNQVhf Qk9EWV9TSVpFXTsKICAKICBtZW1jcHkoQm9keSxLK1NQX0JPRFksQm9keU1hc2spOwogIEJvZHlN YXNrLS07CiAgCiAgU2FsdFswXSBePSBLZXlDaGVja1N1bTsKICBTYWx0WzFdIF49IEtleUNoZWNr U3VtOwogIFNhbHRbMl0gXj0gS2V5Q2hlY2tTdW07CiAgU2FsdFszXSBePSBLZXlDaGVja1N1bTsK ICAKICAvLyBJbml0aWFsIHBvc2l0aW9uIG9mIHRoZSBwb2ludGVyIGlzIGRlcGVuZGVudCBvbiBh Y3R1YWwgc2FsdCB2YWx1ZQogIE0gPSBCb2R5TWFzayAmIFNhbHRbMF07CiAgLy9wcmludGYoInhv ckVuY3J5cHQgQm9keUxlbjogJXUgS2V5Q2hlY2tTdW06ICV1IFNhbHQ6ICV1XG4iLEJvZHlMZW4s IEtleUNoZWNrU3VtLFNhbHQpOwogIAogIGZvciAodD0wOyB0PEluT3V0RGF0YUxlbjsgdCsrKQog IHsKICAgIC8vIEZpcnN0IGp1bXAgc3RlcCBpcyBwcmV2aW91cyBwbGFpbnRleHQgYnl0ZQogICAg WE9SVmFsID0gQm9keVtNXTsgCiAgICBNID0gKE0gKyBMYXN0VmFsKSAmIEJvZHlNYXNrOyAKICAg IC8vIEFsbCBmb2xsb3dpbmcganVtcHMgYXJlIGJhc2VkIG9uIGJvZHkgdmFsdWVzCiAgICBYT1JW YWwgXj0gQm9keVtNXTsgCiAgICBNID0gKE0gKyBCb2R5W01dKSAmIEJvZHlNYXNrOyAKICAgIFhP UlZhbCBePSBCb2R5W01dOyAKICAgIE0gPSAoTSArIEJvZHlbTV0pICYgQm9keU1hc2s7IAogICAg TWFrZVhPUkRlYyhJbk91dEJ1ZixYT1JWYWwsU2FsdCxLZXlDaGVja1N1bSxDaGVja3N1bSxMYXN0 VmFsLHQpOwogICAgQm9keVtNXSsrOwogIH0KICByZXR1cm4gQ2hlY2tzdW07Cn0gCgovLyNkZWZp bmUgeG9yRW5jcnlwdERlY3J5cHQgeG9yRW5jcnlwdERlY3J5cHRIT1A1Ci8qIE1lbWNweSBCZW5j aG1hcmsxIDogCiAqIFRoaXMgZnVuY3Rpb24gCiAqICAgQ3JlYXRlcyBhIE4gYnl0ZXMgcmFuZG9t IGRhdGEgYnVmZmVyIAogKiAgIENyZWF0ZXMgYW5vdGhlciBOIGJ5dGVzIHplcm8gZmlsbGVkIGJ1 ZmZlciAoRGVzdEJ1ZikKICogICBTdGFydHMgYW4gaXRlcmF0aW9uIAogKiAgIEZvciBlYWNoIGl0 ZXJhdGlvbiwgaW5jcmVhc2VzIGV2ZXJ5IGJ5dGUgb2YgdGhlIGRhdGEgYnkgMQogKiAgIENvcGll cyB0aGUgZGF0YSBidWZmZXIgdG8gRGVzdEJ1ZgogKiAgIFByaW50cyB0aGUgZWxhcHNlZCB0aW1l IAogKi8Kdm9pZCBNZW1DcHlCZW5jaG1hcmsxKHVpbnQzMl90IFRlc3RTYW1wbGVMZW5ndGgsIHVp bnQzMl90IE51bUl0ZXJhdGlvbnMpCnsKICB1aW50OF90ICpEYXRhID0gQ3JlYXRlRGF0YUJ1ZihU ZXN0U2FtcGxlTGVuZ3RoKTsKICB1aW50OF90ICpEZXN0QnVmID0gQ3JlYXRlRGF0YUJ1ZihUZXN0 U2FtcGxlTGVuZ3RoKTsKICB1bnNpZ25lZCBsb25nIGxvbmcgaW50IFRvdGFsUHJvY2Vzc2VkQnl0 ZXMgPSAwOwogIHVuc2lnbmVkIHQ7CiAgCiAgLypwcmludGYoIi0tLS0tLS0tLS0tLS0tLS0tLS0t IE1lbUNweUJlbmNobWFyazEgMTogQkFTSUMgRlVOQ1RJT05BTElUWSAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tXG4iCiAgICAgICAgIlRoaXMgZnVuY3Rpb25cbiAxLkNyZWF0ZXMgYSAldSBieXRl cyByYW5kb20gZGF0YSBidWZmZXJcbkNyZWF0ZXMgYW5vdGhlciBidWZmZXIoRGVzdEJ1Zikgd2l0 aCB0aGUgc2FtZSBzaXplXG5NYWtlcyAldSBpdGVyYXRpb25cbiIKICAgICAgICAgIkZvciBlYWNo IGl0ZXJhdGlvbiwgaW5jcmVhc2VzIGV2ZXJ5IGJ5dGUgb2YgdGhlIGRhdGEgYnkgMVxuQ29waWVz IHRoZSBkYXRhIGJ1ZmZlciB0byBEZXN0QnVmXG5QcmludHMgdGhlIGVsYXBzZWQgdGltZSIsVGVz dFNhbXBsZUxlbmd0aCxOdW1JdGVyYXRpb25zKTsqLwogIHByaW50ZigiTWVtQ3B5QmVuY2htYXJr MVxuXHRUZXN0U2FtcGxlTGVuZ3RoOiAldVxuXHROdW1JdGVyYXRpb25zOiAldSAuLi4gIixUZXN0 U2FtcGxlTGVuZ3RoLE51bUl0ZXJhdGlvbnMpOyAgCiAgc3RydWN0IHRpbWV2YWwgU3RhcnRUaW1l OwogIGdldHRpbWVvZmRheSAoJlN0YXJ0VGltZSwgTlVMTCk7IAogIAogIGZvciAodD0wOyB0PE51 bUl0ZXJhdGlvbnM7IHQrKykKICB7CiAgICBJbmNCeU9uZShEYXRhLCBUZXN0U2FtcGxlTGVuZ3Ro KTsKICAgIG1lbWNweShEZXN0QnVmLCBEYXRhLCBUZXN0U2FtcGxlTGVuZ3RoKTsKICAgIFRvdGFs UHJvY2Vzc2VkQnl0ZXMgKz0gVGVzdFNhbXBsZUxlbmd0aDsKICB9CiAgUHJpbnRFbGFwc2VkVGlt ZSgmU3RhcnRUaW1lLFRvdGFsUHJvY2Vzc2VkQnl0ZXMpOwogIGZyZWUoRGF0YSk7CiAgZnJlZShE ZXN0QnVmKTsKfQoKLyogQmVuY2htYXJrMSA6IAogKiBUaGlzIGZ1bmN0aW9uIAogKiAgIENyZWF0 ZXMgYSBrZXkgd2l0aCBOdW1KdW1wcyBwYXJ0aWNsZXMgYW5kIHdpdGggYSBib2R5IGxlbmd0aCBv ZiBCb2R5TGVuCiAqICAgQ3JlYXRlcyBhIE4gYnl0ZXMgcmFuZG9tIHplcm8gZmlsbGVkIGJ1ZmZl ciAKICogICBTdGFydHMgYW4gaXRlcmF0aW9uIG9mIE51bUl0ZXJhdGlvbnMgdGltZXMKICogICBG b3IgZWFjaCBpdGVyYXRpb24sIGluY3JlYXNlcyBldmVyeSBieXRlIG9mIHRoZSBkYXRhIGJ5IDEK ICogICBFbmNyeXB0cyB0aGUgZGF0YQogKiAgIFByaW50cyB0aGUgZWxhcHNlZCB0aW1lIAogKi8K ZG91YmxlIEJlbmNobWFyazEodWludDhfdCBOdW1KdW1wcywgdWludDMyX3QgQm9keUxlbiwgdWlu dDMyX3QgVGVzdFNhbXBsZUxlbmd0aCwgdWludDMyX3QgTnVtSXRlcmF0aW9ucykKewogIHVpbnQ4 X3QgKktleUJ1ZiA9ICh1aW50OF90ICopbWFsbG9jKHhvckNvbXB1dGVLZXlCdWZMZW4oQm9keUxl bikpOwogIHVpbnQ4X3QgKkRhdGEgPSBDcmVhdGVEYXRhQnVmKFRlc3RTYW1wbGVMZW5ndGgpOwog IHVuc2lnbmVkIGxvbmcgbG9uZyBpbnQgVG90YWxQcm9jZXNzZWRCeXRlcyA9IDA7CiAgdWludDMy X3QgdCxTYWx0OwogIHVpbnQ4X3QgS2V5Q2hlY2tTdW07CiAgCiAgcHJpbnRmKCJCZW5jaG1hcmsx XG5cdE51bUp1bXBzOiAldVxuXHRCb2R5TGVuOiAldVxuXHRUZXN0U2FtcGxlTGVuZ3RoOiAldVxu XHROdW1JdGVyYXRpb25zOiAldSAuLi4gIixOdW1KdW1wcyxCb2R5TGVuLFRlc3RTYW1wbGVMZW5n dGgsTnVtSXRlcmF0aW9ucyk7ICAKICAKICBHZXRSYW5kb21OdW1iZXJzKFRlc3RTYW1wbGVMZW5n dGgsIERhdGEpOwogIHhvckdldEtleShOdW1KdW1wcywgQm9keUxlbiwgS2V5QnVmKTsKICBLZXlD aGVja1N1bSA9IHhvckNvbXB1dGVLZXlDaGVja1N1bShLZXlCdWYpOwogIHhvckFuYWx5emVLZXko S2V5QnVmKTsKICBzdHJ1Y3QgdGltZXZhbCBTdGFydFRpbWU7CiAgZ2V0dGltZW9mZGF5ICgmU3Rh cnRUaW1lLCBOVUxMKTsgCiAgCiAgZm9yICh0PTA7IHQ8TnVtSXRlcmF0aW9uczsgdCsrKQogIHsK ICAgIEluY0J5T25lKERhdGEsIFRlc3RTYW1wbGVMZW5ndGgpOwogICAgU2FsdD0xMjM0OwogICAg eG9yRW5jcnlwdChLZXlCdWYsICh1aW50OF90ICopKCZTYWx0KSwgS2V5Q2hlY2tTdW0sIFRlc3RT YW1wbGVMZW5ndGgsIERhdGEpOwogICAgVG90YWxQcm9jZXNzZWRCeXRlcyArPSBUZXN0U2FtcGxl TGVuZ3RoOwogIH0KICBkb3VibGUgQXZlcmFnZSA9IFByaW50RWxhcHNlZFRpbWUoJlN0YXJ0VGlt ZSxUb3RhbFByb2Nlc3NlZEJ5dGVzKTsKICBmcmVlKERhdGEpOwogIGZyZWUoS2V5QnVmKTsKICBy ZXR1cm4gQXZlcmFnZTsKfQpzdGF0aWMgaW5saW5lIHVpbnQ2NF90IEJ1ZkNoZWNrU3VtKHVpbnQ4 X3QgKkJ1ZiwgdWludDY0X3QgQnVmTGVuKQp7CiAgdWludDY0X3QgdCwgQ2hlY2tTdW0gPSAwOwog IAogIGZvciAodD0wOyB0PEJ1ZkxlbjsgdCsrKQogICAgQ2hlY2tTdW0gKz0gQnVmW3RdOwogIHJl dHVybiBDaGVja1N1bTsKfQpkb3VibGUgQmVuY2htYXJrSE9QMih1aW50OF90IE51bUp1bXBzLCB1 aW50MzJfdCBCb2R5TGVuLCB1aW50MzJfdCBUZXN0U2FtcGxlTGVuZ3RoLCB1aW50MzJfdCBOdW1J dGVyYXRpb25zKQp7CiAgdWludDhfdCAqS2V5QnVmID0gKHVpbnQ4X3QgKiltYWxsb2MoeG9yQ29t cHV0ZUtleUJ1ZkxlbihCb2R5TGVuKSk7CiAgdWludDhfdCAqRGF0YSA9IENyZWF0ZURhdGFCdWYo VGVzdFNhbXBsZUxlbmd0aCk7CiAgdW5zaWduZWQgbG9uZyBsb25nIGludCBUb3RhbFByb2Nlc3Nl ZEJ5dGVzID0gMDsKICB1aW50MzJfdCB0OwogIHVpbnQ4X3QgS2V5Q2hlY2tTdW07CiAgdWludDMy X3QgIFNhbHREYXRhPTEyNDU7CiAgCiAgcHJpbnRmKCJCZW5jaG1hcmtIb3AyXG5cdE51bUp1bXBz OiAldVxuXHRCb2R5TGVuOiAldVxuXHRUZXN0U2FtcGxlTGVuZ3RoOiAldVxuXHROdW1JdGVyYXRp b25zOiAldSAuLi4gIixOdW1KdW1wcyxCb2R5TGVuLFRlc3RTYW1wbGVMZW5ndGgsTnVtSXRlcmF0 aW9ucyk7ICAKICAKICBHZXRSYW5kb21OdW1iZXJzKFRlc3RTYW1wbGVMZW5ndGgsIERhdGEpOwog IHhvckdldEtleShOdW1KdW1wcywgQm9keUxlbiwgS2V5QnVmKTsKICBLZXlDaGVja1N1bSA9IHhv ckNvbXB1dGVLZXlDaGVja1N1bShLZXlCdWYpOwogIHhvckFuYWx5emVLZXkoS2V5QnVmKTsKICBz dHJ1Y3QgdGltZXZhbCBTdGFydFRpbWU7CiAgZ2V0dGltZW9mZGF5ICgmU3RhcnRUaW1lLCBOVUxM KTsgCiAgCiAgQnVmQ2hlY2tTdW0oRGF0YSwgVGVzdFNhbXBsZUxlbmd0aCk7ICAKICBmb3IgKHQ9 MDsgdDxOdW1JdGVyYXRpb25zOyB0KyspCiAgewogICAgSW5jQnlPbmUoRGF0YSwgVGVzdFNhbXBs ZUxlbmd0aCk7CiAgICB4b3JFbmNyeXB0SE9QMihLZXlCdWYsICh1aW50OF90ICopKCZTYWx0RGF0 YSksIEtleUNoZWNrU3VtLCBUZXN0U2FtcGxlTGVuZ3RoLCBEYXRhKTsKICAgIFRvdGFsUHJvY2Vz c2VkQnl0ZXMgKz0gVGVzdFNhbXBsZUxlbmd0aDsKICB9CiAgZG91YmxlIEF2ZXJhZ2UgPSBQcmlu dEVsYXBzZWRUaW1lKCZTdGFydFRpbWUsVG90YWxQcm9jZXNzZWRCeXRlcyk7CiAgZnJlZShEYXRh KTsKICBmcmVlKEtleUJ1Zik7CiAgcmV0dXJuIEF2ZXJhZ2U7Cn0KCmRvdWJsZSBCZW5jaG1hcmtI T1AzKHVpbnQ4X3QgTnVtSnVtcHMsIHVpbnQzMl90IEJvZHlMZW4sIHVpbnQzMl90IFRlc3RTYW1w bGVMZW5ndGgsIHVpbnQzMl90IE51bUl0ZXJhdGlvbnMpCnsKICB1aW50OF90ICpLZXlCdWYgPSAo dWludDhfdCAqKW1hbGxvYyh4b3JDb21wdXRlS2V5QnVmTGVuKEJvZHlMZW4pKTsKICB1aW50OF90 ICpEYXRhID0gQ3JlYXRlRGF0YUJ1ZihUZXN0U2FtcGxlTGVuZ3RoKTsKICB1bnNpZ25lZCBsb25n IGxvbmcgaW50IFRvdGFsUHJvY2Vzc2VkQnl0ZXMgPSAwOwogIHVpbnQzMl90IHQ7CiAgdWludDhf dCBLZXlDaGVja1N1bTsKICB1aW50MzJfdCBTYWx0RGF0YTsKICAKICBwcmludGYoIkJlbmNobWFy a0hvcDNcblx0TnVtSnVtcHM6ICV1XG5cdEJvZHlMZW46ICV1XG5cdFRlc3RTYW1wbGVMZW5ndGg6 ICV1XG5cdE51bUl0ZXJhdGlvbnM6ICV1IC4uLiAiLE51bUp1bXBzLEJvZHlMZW4sVGVzdFNhbXBs ZUxlbmd0aCxOdW1JdGVyYXRpb25zKTsgIAogIAogIEdldFJhbmRvbU51bWJlcnMoVGVzdFNhbXBs ZUxlbmd0aCwgRGF0YSk7CiAgeG9yR2V0S2V5KE51bUp1bXBzLCBCb2R5TGVuLCBLZXlCdWYpOwog IEtleUNoZWNrU3VtID0geG9yQ29tcHV0ZUtleUNoZWNrU3VtKEtleUJ1Zik7CiAgeG9yQW5hbHl6 ZUtleShLZXlCdWYpOwogIHN0cnVjdCB0aW1ldmFsIFN0YXJ0VGltZTsKICBnZXR0aW1lb2ZkYXkg KCZTdGFydFRpbWUsIE5VTEwpOyAKICAKICBCdWZDaGVja1N1bShEYXRhLCBUZXN0U2FtcGxlTGVu Z3RoKTsgIAogIGZvciAodD0wOyB0PE51bUl0ZXJhdGlvbnM7IHQrKykKICB7CiAgICBJbmNCeU9u ZShEYXRhLCBUZXN0U2FtcGxlTGVuZ3RoKTsKICAgIHhvckVuY3J5cHRIT1AzKEtleUJ1ZiwgKHVp bnQ4X3QgKikoJlNhbHREYXRhKSwgS2V5Q2hlY2tTdW0sIFRlc3RTYW1wbGVMZW5ndGgsIERhdGEp OwogICAgVG90YWxQcm9jZXNzZWRCeXRlcyArPSBUZXN0U2FtcGxlTGVuZ3RoOwogIH0KICBkb3Vi bGUgQXZlcmFnZSA9IFByaW50RWxhcHNlZFRpbWUoJlN0YXJ0VGltZSxUb3RhbFByb2Nlc3NlZEJ5 dGVzKTsKICBmcmVlKERhdGEpOwogIGZyZWUoS2V5QnVmKTsKICByZXR1cm4gQXZlcmFnZTsKfQoK I2RlZmluZSBURVNUU1RSMSAiVMOcUkvDh0Uga2FyYWt0ZXIga3VsbGFuxLFuxLF6IERFTkVNRS4g VMOcUkvDh0Uga2FyYWt0ZXIga3VsbGFuxLFuxLF6IERFTkVNRS4gdXp1dXV1dXV1bi4gVMOcUkvD h0Uga2FyYWt0ZXIga3VsbGFuxLFuxLF6IERFTkVNRS4gw4dvayB1enVuIMOnb2shMjIyVMOcUkvD h0Uga2FyYWt0ZXIga3VsbGFuxLFuxLF6IERFTkVNRS4gVMOcUkvDh0Uga2FyYWt0ZXIga3VsbGFu xLFuxLF6IERFTkVNRS4gdXp1dXV1dXV1bi4gVMOcUkvDh0Uga2FyYWt0ZXIga3VsbGFuxLFuxLF6 IERFTkVNRS4gw4dvayB1enVuIMOnb2shZnJmclTDnFJLw4dFIGthcmFrdGVyIGt1bGxhbsSxbsSx eiBERU5FTUUuIFTDnFJLw4dFIGthcmFrdGVyIGt1bGxhbsSxbsSxeiBERU5FTUUuIHV6dXV1dXV1 dW4uIFTDnFJLw4dFIGthcmFrdGVyIGt1bGxhbsSxbsSxeiBERU5FTUUuIMOHb2sgdXp1biDDp29r ISIKI2RlZmluZSBURVNUU1RSMV9MRU4gc3RybGVuKFRFU1RTVFIxKQp2b2lkIENoZWNrT3B0aW1p emVkVmVyc2lvbih1bnNpZ25lZCBOdW1KdW1wcywgdW5zaWduZWQgQm9keUxlbikKewogIHVuc2ln bmVkIGxvbmcgbG9uZyBpbnQgRExlbiwgT3JpZ2luYWxQbGFpblRleHRDaGVja1N1bSwgQ2hlY2tT dW1SZXR1cm5lZEZyb21FbmNyeXB0b3IsIENoZWNrU3VtUmV0dXJuZWRGcm9tRGVjcnlwdG9yOwog IHVuc2lnbmVkIFJhd0tleUxlbiA9IHhvckNvbXB1dGVLZXlCdWZMZW4oQm9keUxlbik7CiAgdWlu dDhfdCAqS2V5QnVmID0gKHVpbnQ4X3QgKiltYWxsb2MoUmF3S2V5TGVuKTsKICB1aW50OF90IFBs YWluVGV4dEJ1ZlsxMzIwMDBdLCBEYXRhWzEzMjAwMF07CiAgdW5zaWduZWQgbG9uZyBsb25nIGlu dCBLZXlDaGVja1N1bTsKICB1aW50MzJfdCBTYWx0RGF0YTsKICAKICBwcmludGYoIi0tLS0tLS0t LS0tLS0tLS0tLS0tIFRFU1RJTkcgT1BUSU1JWkVEIFZFUlNJT04gRk9SICV1IFBBUlRJQ0xFUyAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tXG4iLE51bUp1bXBzKTsKICB4b3JHZXRLZXkoTnVtSnVt cHMsIEJvZHlMZW4sIEtleUJ1Zik7CiAgS2V5Q2hlY2tTdW0gPSB4b3JDb21wdXRlS2V5Q2hlY2tT dW0oS2V5QnVmKTsKICBETGVuID0gVEVTVFNUUjFfTEVOOyAKICBtZW1jcHkoRGF0YSwgVEVTVFNU UjEsIERMZW4pOwogIG1lbWNweShQbGFpblRleHRCdWYsIFRFU1RTVFIxLCBETGVuKTsKICAKICBm b3IgKERMZW4gPSAwOyBETGVuIDwgVEVTVFNUUjFfTEVOOyBETGVuKyspCiAgewogICAgUGxhaW5U ZXh0QnVmW0RMZW5dID0gKHVpbnQ4X3QpKERMZW4gJiAyNTUpOwogICAgRGF0YVtETGVuXSA9IFBs YWluVGV4dEJ1ZltETGVuXTsKICAgIE9yaWdpbmFsUGxhaW5UZXh0Q2hlY2tTdW0gPSBCdWZDaGVj a1N1bShEYXRhLCBETGVuKzEpOwogICAgU2FsdERhdGE9MTIzNDsKICAgIENoZWNrU3VtUmV0dXJu ZWRGcm9tRW5jcnlwdG9yID0geG9yRW5jcnlwdChLZXlCdWYsICh1aW50OF90ICopKCZTYWx0RGF0 YSksIEtleUNoZWNrU3VtLCBETGVuKzEsIERhdGEpOyAvLyBXZSBlbmNyeXB0IHdpdGggbm9uLW9w dGltaXplZCB2ZXJzaW9uCiAgICBpZiAoT3JpZ2luYWxQbGFpblRleHRDaGVja1N1bSAhPSBDaGVj a1N1bVJldHVybmVkRnJvbUVuY3J5cHRvcikKICAgIHsKICAgICAgcHJpbnRmKCJPcmlnaW5hbCBD aGVja3N1bSAlbGx1IHJldHVybmVkIGZyb20gQnVmQ2hlY2tzdW0gZm5jIDw+IENoZWNrc3VtICVs bHUgcmV0dXJuZWQgZnJvbSB4b3JFbmNyeXB0RGVjcnlwdFxuIixPcmlnaW5hbFBsYWluVGV4dENo ZWNrU3VtLENoZWNrU3VtUmV0dXJuZWRGcm9tRW5jcnlwdG9yKTsKICAgICAgZXhpdCgtMSk7CiAg ICB9CiAgICAvLyBTYWx0IGRhdGEgY2hhbmdlcyB3aXRoIGV2ZXJ5IGVuY3J5cHQgZGVjcnlwdCEg CiAgICBTYWx0RGF0YT0xMjM0OwogICAgaWYgKE51bUp1bXBzID09IDIpCiAgICAgIENoZWNrU3Vt UmV0dXJuZWRGcm9tRGVjcnlwdG9yID0geG9yRGVjcnlwdEhPUDIoS2V5QnVmLCAodWludDhfdCAq KSgmU2FsdERhdGEpLCBLZXlDaGVja1N1bSwgRExlbisxLCBEYXRhKTsKICAgIGVsc2UgaWYgKE51 bUp1bXBzID09IDMpCiAgICAgIENoZWNrU3VtUmV0dXJuZWRGcm9tRGVjcnlwdG9yID0geG9yRGVj cnlwdEhPUDMoS2V5QnVmLCAodWludDhfdCAqKSgmU2FsdERhdGEpLCBLZXlDaGVja1N1bSwgRExl bisxLCBEYXRhKTsKICAgIGVsc2UgZXhpdCgtMSk7CiAgICAKICAgIGlmIChPcmlnaW5hbFBsYWlu VGV4dENoZWNrU3VtICE9IENoZWNrU3VtUmV0dXJuZWRGcm9tRGVjcnlwdG9yKQogICAgewogICAg ICBwcmludGYoIk9yaWdpbmFsIENoZWNrc3VtICVsbHUgcmV0dXJuZWQgZnJvbSBCdWZDaGVja3N1 bSBmbmMgPD4gQ2hlY2tzdW0gJWxsdSByZXR1cm5lZCBmcm9tIEhPUCBkZWN5cHRvclxuIixPcmln aW5hbFBsYWluVGV4dENoZWNrU3VtLENoZWNrU3VtUmV0dXJuZWRGcm9tRGVjcnlwdG9yKTsKICAg ICAgZXhpdCgtMSk7CiAgICB9CiAgICBpZiAobWVtY21wKChjaGFyICopRGF0YSwgKGNoYXIgKilQ bGFpblRleHRCdWYsIERMZW4rMSkgIT0gMCkKICAgIHsKICAgICAgcHJpbnRmKCJTdHJpbmc6ICVz IC4uLiBUZXN0MSByZXN1bHQ6IEZBSUxFRCEhISFcbi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS1cbiIsIERhdGEpOwogICAgICBleGl0KC0xKTsKICAgIH0KICB9CiAgcHJp bnRmKCJ4b3JFbmNyeXB0RGVjcnlwdEhPUCV1IFNVQ0NFU1NGVUwhXG4iLE51bUp1bXBzKTsKfQp2 b2lkIFRlc3QxKHVuc2lnbmVkIE51bUp1bXBzLCB1bnNpZ25lZCBCb2R5TGVuKQp7CiAgdW5zaWdu ZWQgbG9uZyBsb25nIGludCBETGVuLCBPcmlnaW5hbFBsYWluVGV4dENoZWNrU3VtLCBDaGVja1N1 bVJldHVybmVkRnJvbUVuY3J5cHRvciwgQ2hlY2tTdW1SZXR1cm5lZEZyb21EZWNyeXB0b3I7CiAg dW5zaWduZWQgUmF3S2V5TGVuID0geG9yQ29tcHV0ZUtleUJ1ZkxlbihCb2R5TGVuKTsKICB1aW50 OF90ICpLZXlCdWYgPSAodWludDhfdCAqKW1hbGxvYyhSYXdLZXlMZW4pOwogIHVpbnQ4X3QgRGF0 YVsyMDQ4XSxEYXRhMlsyMDQ4XTsKICBjaGFyICpCYXNlNjRFbmNvZGVkS2V5U3RyLCAqQmFzZTY0 Q2lwaGVyVGV4dDsKICB1aW50OF90IEtleUNoZWNrU3VtOwogIHVpbnQzMl90IFNhbHREYXRhPTEy MzQ7CiAgCiAgcHJpbnRmKCItLS0tLS0tLS0tLSBURVNUIDE6IEJBU0lDIEZVTkNUSU9OQUxJVFko JXUgSnVtcHMpIC0tLS0tLS0tLS0tLS0tXG4iLE51bUp1bXBzKTsKICB4b3JHZXRLZXkoTnVtSnVt cHMsIEJvZHlMZW4sIEtleUJ1Zik7CiAgS2V5Q2hlY2tTdW0gPSB4b3JDb21wdXRlS2V5Q2hlY2tT dW0oS2V5QnVmKTsKICBCYXNlNjRFbmNvZGVkS2V5U3RyID0gQmFzZTY0RW5jb2RlKChjb25zdCBj aGFyICopS2V5QnVmLCBSYXdLZXlMZW4pOwogIHByaW50ZigiQmFzZTY0IGVuY29kZWQga2V5OiAl c1xuIiwgQmFzZTY0RW5jb2RlZEtleVN0cik7CiNpZmRlZiBPVkVSTFlfVkVSQk9TRQogIHByaW50 ZigiQW5hbHl6aW5nIHJhdyBrZXkgZGF0YTpcbiIpOwogIFRQYXJzZWRLZXkgKlBLMCA9IHhvclBh cnNlS2V5KEtleUJ1Zik7CiAgeG9yQW5hbHl6ZUtleShQSzApOwogIGZyZWUoUEswKTsKICBmcmVl KEtleUJ1Zik7CiNlbmRpZgogIHhvckFuYWx5emVLZXkoS2V5QnVmKTsKICBtZW1zZXQoJkRhdGEs IDAsIHNpemVvZihEYXRhKSk7CiAgbWVtc2V0KCZEYXRhMiwgMCwgc2l6ZW9mKERhdGEyKSk7CiAg RExlbiA9IFRFU1RTVFIxX0xFTjsgCiAgbWVtY3B5KERhdGEsIFRFU1RTVFIxLCBETGVuKTsKICBt ZW1jcHkoRGF0YTIsIFRFU1RTVFIxLCBETGVuKTsKICBPcmlnaW5hbFBsYWluVGV4dENoZWNrU3Vt ID0gQnVmQ2hlY2tTdW0oRGF0YSwgRExlbik7CiAgQ2hlY2tTdW1SZXR1cm5lZEZyb21FbmNyeXB0 b3IgPSB4b3JFbmNyeXB0KEtleUJ1ZiwgKHVpbnQ4X3QgKikoJlNhbHREYXRhKSwgS2V5Q2hlY2tT dW0sIERMZW4sIERhdGEpOyAvLyBXZSBlbmNyeXB0IHdpdGggbm9uLW9wdGltaXplZCB2ZXJzaW9u CiAgaWYgKE9yaWdpbmFsUGxhaW5UZXh0Q2hlY2tTdW0gIT0gQ2hlY2tTdW1SZXR1cm5lZEZyb21F bmNyeXB0b3IpCiAgewogICAgcHJpbnRmKCJPcmlnaW5hbCBDaGVja3N1bSAlbGx1IHJldHVybmVk IGZyb20gQnVmQ2hlY2tzdW0gZm5jIDw+IENoZWNrc3VtICVsbHUgcmV0dXJuZWQgZnJvbSBub24t b3B0aW1pemVkIGVuY3J5cHRvclxuIixPcmlnaW5hbFBsYWluVGV4dENoZWNrU3VtLENoZWNrU3Vt UmV0dXJuZWRGcm9tRW5jcnlwdG9yKTsKICAgIGV4aXQoLTEpOwogIH0gZWxzZSBwcmludGYoIk9y aWdpbmFsUGxhaW5UZXh0Q2hlY2tTdW0gJWxsdSA9IENoZWNrU3VtUmV0dXJuZWRGcm9tRW5jcnlw dG9yICVsbHUgOjogU1VDQ0VTUyFcbiIsT3JpZ2luYWxQbGFpblRleHRDaGVja1N1bSxDaGVja1N1 bVJldHVybmVkRnJvbUVuY3J5cHRvcik7CiAgLy8gTm93IGxldCdzIGVuY3J5cHQgd2l0aCB0aGUg b3B0aW1pemVkIGVuY3J5cHRvcgogIFNhbHREYXRhPTEyMzQ7CiAgCiAgaWYgKE51bUp1bXBzID09 IDIpCiAgICBDaGVja1N1bVJldHVybmVkRnJvbUVuY3J5cHRvciA9IHhvckVuY3J5cHRIT1AyKEtl eUJ1ZiwgKHVpbnQ4X3QgKikoJlNhbHREYXRhKSwgS2V5Q2hlY2tTdW0sIERMZW4sIERhdGEyKTsg CiAgZWxzZSBpZiAoTnVtSnVtcHMgPT0gMykKICAgIENoZWNrU3VtUmV0dXJuZWRGcm9tRW5jcnlw dG9yID0geG9yRW5jcnlwdEhPUDMoS2V5QnVmLCAodWludDhfdCAqKSgmU2FsdERhdGEpLCBLZXlD aGVja1N1bSwgRExlbiwgRGF0YTIpOyAKICBlbHNlIGV4aXQoLTEpOwogIAogIAogIGlmIChPcmln aW5hbFBsYWluVGV4dENoZWNrU3VtICE9IENoZWNrU3VtUmV0dXJuZWRGcm9tRW5jcnlwdG9yKQog IHsKICAgIHByaW50ZigiT3JpZ2luYWwgQ2hlY2tzdW0gJWxsdSByZXR1cm5lZCBmcm9tIEJ1ZkNo ZWNrc3VtIGZuYyA8PiBDaGVja3N1bSAlbGx1IHJldHVybmVkIGZyb20gb3B0aW1pemVkIGVuY3J5 cHRvclxuIixPcmlnaW5hbFBsYWluVGV4dENoZWNrU3VtLENoZWNrU3VtUmV0dXJuZWRGcm9tRW5j cnlwdG9yKTsKICAgIGV4aXQoLTEpOwogIH0gZWxzZSBwcmludGYoIk9yaWdpbmFsUGxhaW5UZXh0 Q2hlY2tTdW0gJWxsdSA9IENoZWNrU3VtUmV0dXJuZWRGcm9tT3B0aW1pemVkRW5jcnlwdG9yICVs bHUgOjogU1VDQ0VTUyFcbiIsT3JpZ2luYWxQbGFpblRleHRDaGVja1N1bSxDaGVja1N1bVJldHVy bmVkRnJvbUVuY3J5cHRvcik7ICAKICBpZiAobWVtY21wKChjaGFyICopRGF0YSwgRGF0YTIsIERM ZW4pICE9IDApCiAgewogICAgcHJpbnRmKCJOb24tb3B0aW1pemVkIGFuZCBvcHRpbWl6ZWQgZW5j cnlwdG9yIGZ1bmN0aW9ucyBvdXRwdXRzIGFyZSBkaWZmZXJlbnQhIEZBSUxFRCEgRkFJTEVEIVxu Iik7CiAgICBleGl0KC0xKTsKICB9CiAgICAKICBCYXNlNjRDaXBoZXJUZXh0ID0gQmFzZTY0RW5j b2RlKChjb25zdCBjaGFyICopRGF0YSwgRExlbik7CiAgcHJpbnRmKCJCYXNlNjRDaXBoZXJUZXh0 OiAlc1xuIiwgQmFzZTY0Q2lwaGVyVGV4dCk7CiAgcHJpbnRmKCJcblxuRGVjcnlwdGlvbiBwcm9j ZXNzOlxuXG4iKTsKICBTYWx0RGF0YT0xMjM0OwogIHVpbnQ4X3QgKksgPSAodWludDhfdCAqKUJh c2U2NERlY29kZShCYXNlNjRFbmNvZGVkS2V5U3RyKTsKICAKICBpZiAobWVtY21wKChjaGFyICop S2V5QnVmLCAoY2hhciAqKUssIFJhd0tleUxlbikgIT0gMCkKICB7CiAgICBwcmludGYoIk9yaWdp bmFsIGtleSBhbmQgYmFzZTY0IGVuY29kZWQgYW5kIGRlY29kZWQga2V5cyBhcmUgZGlmZmVyZW50 ISEhISFcbiIpOwogICAgZXhpdCgtMSk7CiAgfQogIAogIGlmIChOdW1KdW1wcyA9PSAyKQogICAg Q2hlY2tTdW1SZXR1cm5lZEZyb21EZWNyeXB0b3IgPSB4b3JEZWNyeXB0SE9QMihLLCAodWludDhf dCAqKSgmU2FsdERhdGEpLCBLZXlDaGVja1N1bSwgRExlbiwgRGF0YSk7CiAgZWxzZSBpZiAoTnVt SnVtcHMgPT0gMykKICAgIENoZWNrU3VtUmV0dXJuZWRGcm9tRGVjcnlwdG9yID0geG9yRGVjcnlw dEhPUDMoSywgKHVpbnQ4X3QgKikoJlNhbHREYXRhKSwgS2V5Q2hlY2tTdW0sIERMZW4sIERhdGEp OwogIGVsc2UgZXhpdCgtMSk7CiAgCiAgaWYgKE9yaWdpbmFsUGxhaW5UZXh0Q2hlY2tTdW0gIT0g Q2hlY2tTdW1SZXR1cm5lZEZyb21EZWNyeXB0b3IpCiAgewogICAgcHJpbnRmKCJPcmlnaW5hbCBD aGVja3N1bSAlbGx1IHJldHVybmVkIGZyb20gQnVmQ2hlY2tzdW0gZm5jIDw+IENoZWNrc3VtICVs bHUgcmV0dXJuZWQgZnJvbSBIT1AgZGVjeXB0b3JcbiIsT3JpZ2luYWxQbGFpblRleHRDaGVja1N1 bSxDaGVja1N1bVJldHVybmVkRnJvbURlY3J5cHRvcik7CiAgICBleGl0KC0xKTsKICB9IGVsc2Ug cHJpbnRmKCJPcmlnaW5hbFBsYWluVGV4dENoZWNrU3VtICVsbHUgPSBDaGVja1N1bVJldHVybmVk RnJvbURlY3J5cHRvciAlbGx1IDo6IFNVQ0NFU1MhXG4iLE9yaWdpbmFsUGxhaW5UZXh0Q2hlY2tT dW0sQ2hlY2tTdW1SZXR1cm5lZEZyb21EZWNyeXB0b3IpOwogIAogIGlmIChtZW1jbXAoKGNoYXIg KilEYXRhLCBURVNUU1RSMSwgRExlbikgPT0gMCkKICB7CiAgICBwcmludGYoIlN0cmluZzogJXMg Li4uIFRlc3QxIHJlc3VsdDogU1VDQ0VTU0ZVTCEhISFcbi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS1cbiIsIERhdGEpOwogIH0KICBlbHNlIHsKICAgIHByaW50ZigiU3Ry aW5nOiAlcyAuLi4gVGVzdDEgcmVzdWx0OiBGQUlMRUQhISEhXG4tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tXG4iLCBEYXRhKTsKICAgIGV4aXQoLTEpOwogIH0KICAvL2V4 aXQoLTEpOwp9CnZvaWQgRDEoKQp7CiAgaW50IHQ7CiAgcmVnaXN0ZXIgdWludDhfdCBWPTA7CiAg Zm9yICh0PTA7dDwxMjg7dCsrKQogIHsKICAgIHByaW50ZigiJXUgIixWKTsKICAgIFYgKz0gdDsK ICB9Cn0KY2hhciAqR2V0QmluU3RyKHVpbnQzMl90IHZhbCwgY2hhciAqUmVzQnVmKQp7CiAgY2hh ciAqcDsKICB1bnNpZ25lZCBpbnQgdDsKICBwID0gUmVzQnVmOwogIHQgPSAweDgwMDAwMDAwOyAv LyBzY2FuIDMyIGJpdHMKICBmb3IgKCA7IHQgPiAwOyB0ID0gdCA+PiAxKSAKICB7CiAgICBpZiAo dmFsICYgdCkKICAgICAgKnArKyA9ICcxJzsKICAgIGVsc2UgKnArKyA9ICcwJzsKICB9CiAgKnAg PSAwOwogIHJldHVybiBSZXNCdWY7Cn0Kdm9pZCBDaXJjdWxhclNoaWZ0VGVzdCgpCnsKICB1aW50 MzJfdCB0LCBObiA9ICh1aW50MzJfdCkoMGIxMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAx MFUpOwogIGNoYXIgQnVmWzI1Nl07CiAgcHJpbnRmKCJDaXJjdWxhciBzaGlmdCBsZWZ0OlxuIik7 CiAgZm9yICh0PTA7IHQ8NTsgdCsrKQogIHsKICAgIHByaW50ZigiJXNcbiIsIEdldEJpblN0cihO bixCdWYpKTsgIAogICAgTm4gPSBST0wzMl8xKE5uKTsKICB9CiAgcHJpbnRmKCJDaXJjdWxhciBz aGlmdCByaWdodDpcbiIpOwogIGZvciAodD0wOyB0PDY7IHQrKykKICB7CiAgICBwcmludGYoIiVz XG4iLCBHZXRCaW5TdHIoTm4sQnVmKSk7ICAKICAgIE5uID0gUk9SMzJfMShObik7CiAgfQp9Cgpp bnQgbWFpbigpCnsKICB1aW50MzJfdCBCb2R5TGVuID0gNjQ7CiAgCiAgLy9DaXJjdWxhclNoaWZ0 VGVzdCgpOwogIC8vdWludDMyX3QgVGVzdFNhbXBsZUxlbmd0aCA9IDgxOTI7CiAgdWludDMyX3Qg TnVtSXRlcmF0aW9ucyA9IDEwMDAwMDA7CiAgLy9EMSgpOwogIFRlc3QxKDIsIEJvZHlMZW4pOwog IFRlc3QxKDMsIEJvZHlMZW4pOwogIC8vVGVzdDEoNCwgQm9keUxlbik7CiAgLy9UZXN0MSg1LCBC b2R5TGVuKTsKICAKICAvLyAgZXhpdCgtMSk7CiAgLy9NZW1DcHlCZW5jaG1hcmsxKFRlc3RTYW1w bGVMZW5ndGgsIE51bUl0ZXJhdGlvbnMpOwogIENoZWNrT3B0aW1pemVkVmVyc2lvbigyLCBCb2R5 TGVuKTsKICBDaGVja09wdGltaXplZFZlcnNpb24oMywgQm9keUxlbik7CiAgLy9DaGVja09wdGlt aXplZFZlcnNpb24oNSwgQm9keUxlbik7CiAgCiAgCiAgZG91YmxlIEF2ZXJhZ2UxNkgyLEF2ZXJh Z2U2NEgyLEF2ZXJhZ2UyNTZIMixBdmVyYWdlMTAyNEgyLEF2ZXJhZ2U4MTkySDI7CiAgZG91Ymxl IEF2ZXJhZ2UxNkgzLEF2ZXJhZ2U2NEgzLEF2ZXJhZ2UyNTZIMyxBdmVyYWdlMTAyNEgzLEF2ZXJh Z2U4MTkySDM7CiAgCiAgCiAgLyoKICBkb3VibGUgQXZlcmFnZTE2LEF2ZXJhZ2U2NCxBdmVyYWdl MjU2LEF2ZXJhZ2UxMDI0LEF2ZXJhZ2U4MTkyOwogIEF2ZXJhZ2UxNiA9IEJlbmNobWFyazEoTnVt SnVtcHMsIEJvZHlMZW4sIDE2LCBOdW1JdGVyYXRpb25zKTsKICBBdmVyYWdlNjQgPSBCZW5jaG1h cmsxKE51bUp1bXBzLCBCb2R5TGVuLCA2NCwgTnVtSXRlcmF0aW9ucyk7CiAgQXZlcmFnZTI1NiA9 IEJlbmNobWFyazEoTnVtSnVtcHMsIEJvZHlMZW4sIDI1NiwgTnVtSXRlcmF0aW9ucyk7CiAgQXZl cmFnZTEwMjQgPSBCZW5jaG1hcmsxKE51bUp1bXBzLCBCb2R5TGVuLCAxMDI0LCBOdW1JdGVyYXRp b25zKTsKICBBdmVyYWdlODE5MiA9IEJlbmNobWFyazEoTnVtSnVtcHMsIEJvZHlMZW4sIDgxOTIs IE51bUl0ZXJhdGlvbnMpOwogIHByaW50ZigiXG5cbk5PTi1IQU5ELU9QVElNSVpFRCBWRVJTSU9O IEJFTkNITUFSS1M6XG4iCiAgICAgICAgICIxNiAgICAgICAgICAgICAgICAgIDY0ICAgICAgICAg ICAgICAgICAgMjU2ICAgICAgICAgICAgICAgICAxMDI0ICAgICAgICAgICAgICAgICA4MTkyXG4i CiAgICAgICAgICItLS0tLS0tLS0tLS0tLS0tLS0tIC0tLS0tLS0tLS0tLS0tLS0tLS0gLS0tLS0t LS0tLS0tLS0tLS0tLSAtLS0tLS0tLS0tLS0tLS0tLS0tLSAtLS0tLS0tLS0tLS0tLS0tLS0tLVxu IgogICAgICAgICAiJTE5LjJmICUxOS4yZiAlMTkuMmYgJTE5LjJmICUxOS4yZlxuXG4iLCBBdmVy YWdlMTYsIEF2ZXJhZ2U2NCwgQXZlcmFnZTI1NiwgQXZlcmFnZTEwMjQsIEF2ZXJhZ2U4MTkyKTsK ICAqLwogIEF2ZXJhZ2UxNkgyID0gQmVuY2htYXJrSE9QMigzLCBCb2R5TGVuLCAxNiwgTnVtSXRl cmF0aW9ucyk7CiAgQXZlcmFnZTY0SDIgPSBCZW5jaG1hcmtIT1AyKDMsIEJvZHlMZW4sIDY0LCBO dW1JdGVyYXRpb25zKTsKICBBdmVyYWdlMjU2SDIgPSBCZW5jaG1hcmtIT1AyKDMsIEJvZHlMZW4s IDI1NiwgTnVtSXRlcmF0aW9ucyk7CiAgQXZlcmFnZTEwMjRIMiA9IEJlbmNobWFya0hPUDIoMywg Qm9keUxlbiwgMTAyNCwgTnVtSXRlcmF0aW9ucyk7CiAgQXZlcmFnZTgxOTJIMiA9IEJlbmNobWFy a0hPUDIoMywgQm9keUxlbiwgODE5MiwgTnVtSXRlcmF0aW9ucyk7CiAgCiAgQXZlcmFnZTE2SDMg PSBCZW5jaG1hcmtIT1AzKDMsIEJvZHlMZW4sIDE2LCBOdW1JdGVyYXRpb25zKTsKICBBdmVyYWdl NjRIMyA9IEJlbmNobWFya0hPUDMoMywgQm9keUxlbiwgNjQsIE51bUl0ZXJhdGlvbnMpOwogIEF2 ZXJhZ2UyNTZIMyA9IEJlbmNobWFya0hPUDMoMywgQm9keUxlbiwgMjU2LCBOdW1JdGVyYXRpb25z KTsKICBBdmVyYWdlMTAyNEgzID0gQmVuY2htYXJrSE9QMygzLCBCb2R5TGVuLCAxMDI0LCBOdW1J dGVyYXRpb25zKTsKICBBdmVyYWdlODE5MkgzID0gQmVuY2htYXJrSE9QMygzLCBCb2R5TGVuLCA4 MTkyLCBOdW1JdGVyYXRpb25zKTsKICAKICBwcmludGYoIlxuXG4yLUp1bXBzIEJFTkNITUFSS1Mo UmVhbCBsaWZlIHVzYWdlKTpcbiIKICAgICAgICAgIjE2ICAgICAgICAgICAgICAgICAgNjQgICAg ICAgICAgICAgICAgICAyNTYgICAgICAgICAgICAgICAgIDEwMjQgICAgICAgICAgICAgICAgODE5 MiAgICAgICAgICAgICAgIFxuIgogICAgICAgICAiLS0tLS0tLS0tLS0tLS0tLS0tLSAtLS0tLS0t LS0tLS0tLS0tLS0tIC0tLS0tLS0tLS0tLS0tLS0tLS0gLS0tLS0tLS0tLS0tLS0tLS0tLSAtLS0t LS0tLS0tLS0tLS0tLS0tXG4iCiAgICAgICAgICIlMTkuMmYgJTE5LjJmICUxOS4yZiAlMTkuMmYg JTE5LjJmXG5cbiIsIEF2ZXJhZ2UxNkgyLCBBdmVyYWdlNjRIMiwgQXZlcmFnZTI1NkgyLCBBdmVy YWdlMTAyNEgyLCBBdmVyYWdlODE5MkgyKTsKICBwcmludGYoIlxuXG4zLUp1bXBzIEJFTkNITUFS S1MoUmVhbCBsaWZlIHVzYWdlKTpcbiIKICAgICAgICAgIjE2ICAgICAgICAgICAgICAgICAgNjQg ICAgICAgICAgICAgICAgICAyNTYgICAgICAgICAgICAgICAgIDEwMjQgICAgICAgICAgICAgICAg ODE5MiAgICAgICAgICAgICAgIFxuIgogICAgICAgICAiLS0tLS0tLS0tLS0tLS0tLS0tLSAtLS0t LS0tLS0tLS0tLS0tLS0tIC0tLS0tLS0tLS0tLS0tLS0tLS0gLS0tLS0tLS0tLS0tLS0tLS0tLSAt LS0tLS0tLS0tLS0tLS0tLS0tXG4iCiAgICAgICAgICIlMTkuMmYgJTE5LjJmICUxOS4yZiAlMTku MmYgJTE5LjJmXG5cbiIsIEF2ZXJhZ2UxNkgzLCBBdmVyYWdlNjRIMywgQXZlcmFnZTI1NkgzLCBB dmVyYWdlMTAyNEgzLCBBdmVyYWdlODE5MkgzKTsKICAKICByZXR1cm4gMDsKfQo= --001a113c8fca4c94a70524b34c81-- From nobody Tue Nov 17 04:47: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 66DE11ACE35 for ; Mon, 16 Nov 2015 19:42:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.921 X-Spam-Level: **** X-Spam-Status: No, score=4.921 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, GB_SUMOF=1, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_66=0.6, J_CHICKENPOX_84=0.6, J_CHICKENPOX_92=0.6, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_FREEMAIL_DOC_PDF=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 hAHuorMskw7H for ; Mon, 16 Nov 2015 19:42:53 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::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 DEA9F1ACE32 for ; Mon, 16 Nov 2015 19:42:51 -0800 (PST) Received: by wmww144 with SMTP id w144so136502189wmw.1 for ; Mon, 16 Nov 2015 19:42:50 -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=/YtahB0zZt33h70vEZQZUAVPJ6+UQ8Dk+oiyN47meTU=; b=PRsFFx+v1uNPb9Pr+r1VF+uTAHkqxU43s78rkVWD+C3unGyGQXjsnfO3mOC38dCHkG PoFTt+yFIapOorQHIs87+VukAb6uq10f098gyuMNgfhvYAd0CeXY+cKEfh5oa1Yj+O+l X/rCSo5cQIHPRbe64CHMAjqMEE12qnekSSPpIq57gRU479FCymhgb5wLIsaZoWnxnS4Q lr15HpUO6i3OtgEmR1OM2oqhuU0SaJxqMf7vbjW7cZLRP/Bx8zhQdBR+/01Mp/RoFmjN 9DIDGfzUI74tFSHxSeNMSxHXAT3wt0dwl8KkEhMsYnNT/+sHFZCFNOL8ctyMMKJgl6vW ButA== MIME-Version: 1.0 X-Received: by 10.194.57.142 with SMTP id i14mr46737224wjq.24.1447731770480; Mon, 16 Nov 2015 19:42:50 -0800 (PST) Received: by 10.194.30.166 with HTTP; Mon, 16 Nov 2015 19:42:50 -0800 (PST) Date: Tue, 17 Nov 2015 05:42:50 +0200 Message-ID: From: Ismail Kizir To: tls@ietf.org Content-Type: multipart/mixed; boundary=047d7ba97d24e919130524b451b1 Archived-At: X-Mailman-Approved-At: Tue, 17 Nov 2015 04:46:59 -0800 Subject: [TLS] A new encryption "impossible to break" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 03:42:59 -0000 --047d7ba97d24e919130524b451b1 Content-Type: multipart/alternative; boundary=047d7ba97d24e9190c0524b451af --047d7ba97d24e9190c0524b451af Content-Type: text/plain; charset=UTF-8 Hello, I've developed a new encryption algorithm, which dynamically changes the key according to plaintext and practically impossible to break. I also opened to public with MIT License. It is also quite fast; ~80% faster than the fastest mode of AES without cpu instruction set support. I will present a paper on a Turkish National Symposium on 3 December: Inet-tr 2015. I am sending the document as an attachment Sorry, it is in Turkish Language. I've studied political sciences. Unfortunately, I haven't mathematical background to write the proof. But it is a very simple logic. Anyone who looks at the attached C code may understand why and how it is unbreakable. I use the key as jump table and with every encrypted byte, I change the jump table(the key) as a result of 3-4 parameters including the last plaintext byte itself. The code is self documented in English. On Linux simply gcc HohhaDynamicXOR.c -O2 -Wall ./a.out will make integrity checks and print benchmarks. It is production ready. Other algorithm results are the output of the "openssl speed" command. If I am right; you will not be disappointed to include "Hohha Dynamic XOR Encryption Algorithm" on TLS 1.3 Draft. Here are the benchmarks for 16,64,256,1024,8192 byte values with -O2 optimization level(-O3 gives ~20% better results).Hop2 is 2 jump results and Hop3 is 3 jump results. Please feel free to ask any questions or any explanation I can give. Regards Ismail Kizir *Algoritma* *16* *64* *256* *1024* *8192* Memcpy 663.42 1052.33 1043.33 1147.54 869.60 *Hohha XOR-Hop2* *162.33* *193.15* *198.17* *198.65* *202.56* *Hohha XOR Hop3* *116.46* *127.42* *130.00* *130.36* *127.33* des cbc 44.98 46.53 46.90 47.14 47.05 des ede3 17.65 18.00 18.03 18.03 18.06 rc2 cbc 26.58 27.10 27.28 27.25 27.35 rc4 22.22 36.02 41.81 43.71 43.63 blowfish cbc 84.71 90.58 91.71 91.28 91.41 Cast cbc 81.23 86.99 88.62 89.00 89.10 aes-128 cbc 77.85 85.20 87.91 18.27 18.59 aes-192 cbc 65.98 71.70 72.70 15.53 15.65 Aes-256 cbc 57.59 61.22 62.43 133.67 134.40 Camellia-128 74.04 109.17 124.03 12.87 12.88 Camellia-192 62.57 85.60 94.68 97.20 98.11 Camellia-256 62.58 85.63 94.69 97.35 97.97 aes-128 ige 78.44 82.05 83.08 83.42 83.17 Aes-192 ige 66.25 69.13 69.75 69.95 69.94 Aes-256 ige 57.69 59.71 60.22 60.40 60.27 --047d7ba97d24e9190c0524b451af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

I've de= veloped a new encryption algorithm, which dynamically changes the key accor= ding to plaintext and practically impossible to break. I also opened to pub= lic with MIT License.
It is also quite= fast; ~80% faster than the fastest mode of AES without cpu instruction set= support.
I will present a paper on a = Turkish National Symposium on 3 December: Inet-tr 2015. I am sending the do= cument as an attachment Sorry, it is in Turkish Language.=C2=A0
I've studied political sciences. Unfortunatel= y, I haven't mathematical background to write the proof. But it is a ve= ry simple logic. Anyone who looks at the attached C code may understand why= and how it is unbreakable.=C2=A0

=
I use the key as jump table and with = every encrypted byte, I change the jump table(the key) as a result of 3-4 p= arameters including the last plaintext byte itself.
The code is self documented in English.
On Linux simply=C2=A0
= gcc HohhaDynamicXOR.c -O2 -Wall
./a.ou= t
will make integrity checks and print= benchmarks. It is production ready.
O= ther algorithm results are the output of the "openssl speed" comm= and.
If I am right; you will not be di= sappointed to include "Hohha Dynamic XOR Encryption Algorithm" on= TLS 1.3 Draft. Here are the benchmarks for 16,64,256,1024,8192 byte values= with -O2 optimization level(-O3 gives ~20% better results).Hop2 is 2 jump = results and Hop3 is 3 jump results.
Pl= ease feel free to ask any questions or any explanation I can give.

Rega= rds
Ismail Kizir

= <= td width=3D"64" bgcolor=3D"#ffffff" style=3D"border-style:none none solid;b= order-bottom-width:1px;border-bottom-color:rgb(0,0,128);padding:0cm">

87.91

<= /tr>

Algoritma=

16

64<= /b>

256

1024

8192

= Memcpy

663.42

1052.33

1043.33

1147.54

869.60

Hohha XOR-Hop2

162.33

193.15

<= font color=3D"#000000">198.17

198.65

202.56

Hohha XOR Hop3

116.46

127.42

<= font color=3D"#000000">130.00

130.36

127.33

des cbc

44.98

46.53<= /font>

46.90<= /font>

47.14

47.05

des ede3

17.65

= 18.00

18= .03

18.03

18.06

=

rc2 cbc

26.58

27.10

27.28

27.25

27.35

rc4

22.22

36.02

41.81

43.71

43.63

blowfish cbc

84.71

90.5= 8

91.71

91.28

= 		=

= 91.41

Cast cbc

<= /td>		<= p align=3D"right"><= font style=3D"font-size:10pt">81.23

86.99

88.62

89.00

89.10

aes-128 cbc

77.85

85.20

<= font color=3D"#000000">18.27

18.= 59

aes-192 cbc

65.98

<= font face=3D"Thorndale, serif">71.70<= /font>

72.70<= /p>

15.53

15.65

=

<= font style=3D"font-size:10pt">Aes-256 cbc

57.59

61.22

62.43=

133.67

134.40

<= /td>

Camellia-128

74.04

109.17

124.03

12.87

12.88

Camellia-192

62.5= 7

85.60

94.68

= 		=

= 97.20

98.11

Camellia-256

62.58

85.63

94.69

97.35

97.97

aes-128 ige<= /font>

78.44

82.05

83.08

83.42

<= font face=3D"Thorndale, serif">83.17<= /font>

Aes= -192 ige

66.25

69.13

69.75

69.95

69.94

Aes-256 ige

= 57.69

59= .71

60.22

60.40

= 		=

= 60.27

--047d7ba97d24e9190c0524b451af-- --047d7ba97d24e919130524b451b1 Content-Type: text/x-csrc; charset=UTF-8; name="HohhaDynamicXOR.c" Content-Disposition: attachment; filename="HohhaDynamicXOR.c" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ih2u1qa80 LypCLgpIb2hoYSBEeW5hbWljIFhPUiBBbGdvcml0aG0uIENvcHlyaWdodCAoYykgMjAxNSDEsHNt YWlsIEtpemlyClBlcm1pc3Npb24gaXMgaGVyZWJ5IGdyYW50ZWQsIGZyZWUgb2YgY2hhcmdlLCB0 byBhbnkgcGVyc29uIG9idGFpbmluZyBhIGNvcHkgb2YgdGhpcyBzb2Z0d2FyZSAKYW5kIGFzc29j aWF0ZWQgZG9jdW1lbnRhdGlvbiBmaWxlcyAodGhlICJTb2Z0d2FyZSIpLCB0byBkZWFsIGluIHRo ZSBTb2Z0d2FyZSB3aXRob3V0IHJlc3RyaWN0aW9uLCAKaW5jbHVkaW5nIHdpdGhvdXQgbGltaXRh dGlvbiB0aGUgcmlnaHRzIHRvIHVzZSwgY29weSwgbW9kaWZ5LCBtZXJnZSwgcHVibGlzaCwgZGlz dHJpYnV0ZSwgc3VibGljZW5zZSwgCmFuZC9vciBzZWxsIGNvcGllcyBvZiB0aGUgU29mdHdhcmUs IGFuZCB0byBwZXJtaXQgcGVyc29ucyB0byB3aG9tIHRoZSBTb2Z0d2FyZSBpcyBmdXJuaXNoZWQg dG8gZG8gc28sIApzdWJqZWN0IHRvIHRoZSBmb2xsb3dpbmcgY29uZGl0aW9uczoKVGhlIGFib3Zl IGNvcHlyaWdodCBub3RpY2UgYW5kIHRoaXMgcGVybWlzc2lvbiBub3RpY2Ugc2hhbGwgYmUgaW5j bHVkZWQgaW4gYWxsIGNvcGllcyBvciBzdWJzdGFudGlhbCBwb3J0aW9ucyBvZiB0aGUgU29mdHdh cmUuClRIRSBTT0ZUV0FSRSBJUyBQUk9WSURFRCAiQVMgSVMiLCBXSVRIT1VUIFdBUlJBTlRZIE9G IEFOWSBLSU5ELCBFWFBSRVNTIE9SIElNUExJRUQsIElOQ0xVRElORyBCVVQgTk9UIExJTUlURUQg VE8gVEhFIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZLCBGSVRORVNTIEZPUiBBIFBBUlRJ Q1VMQVIgUFVSUE9TRSBBTkQgTk9OSU5GUklOR0VNRU5ULiBJTiBOTyBFVkVOVCBTSEFMTCBUSEUg QVVUSE9SUyBPUiBDT1BZUklHSFQgSE9MREVSUyBCRSBMSUFCTEUgRk9SIEFOWSBDTEFJTSwgREFN QUdFUyBPUiBPVEhFUiBMSUFCSUxJVFksIFdIRVRIRVIgSU4gQU4gQUNUSU9OIE9GIENPTlRSQUNU LCBUT1JUIE9SIE9USEVSV0lTRSwgQVJJU0lORyBGUk9NLCBPVVQgT0YgT1IgSU4gQ09OTkVDVElP TiBXSVRIIFRIRSBTT0ZUV0FSRSBPUiBUSEUgVVNFIE9SIE9USEVSIERFQUxJTkdTIElOIFRIRSBT T0ZUV0FSRS4KICovCiNpbmNsdWRlIDxzdGRpby5oPgojaW5jbHVkZSA8c3lzL3R5cGVzLmg+CiNp bmNsdWRlIDxmY250bC5oPgojaW5jbHVkZSA8ZXJybm8uaD4KI2luY2x1ZGUgPHRpbWUuaD4KI2lu Y2x1ZGUgPGN0eXBlLmg+CiNpbmNsdWRlIDxzdHJpbmcuaD4KI2luY2x1ZGUgPHN0ZGRlZi5oPgoj aW5jbHVkZSA8c3RkbGliLmg+CiNpbmNsdWRlIDxhc3NlcnQuaD4KI2luY2x1ZGUgPHN5cy90aW1l Lmg+CgojaW5jbHVkZSA8aW50dHlwZXMuaD4KI2luY2x1ZGUgPHN0cmluZy5oPgoKLyogLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBCQVNFNjQgRU5DT0RFL0RFQ09ERSBGVU5DVElPTlMgLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQogKi8KLyoKY2VuY29kZXIuYyAtIGMg c291cmNlIHRvIGEgYmFzZTY0IGVuY29kaW5nIGFsZ29yaXRobSBpbXBsZW1lbnRhdGlvbgoKVGhp cyBpcyBwYXJ0IG9mIHRoZSBsaWJiNjQgcHJvamVjdCwgYW5kIGhhcyBiZWVuIHBsYWNlZCBpbiB0 aGUgcHVibGljIGRvbWFpbi4KRm9yIGRldGFpbHMsIHNlZSBodHRwOi8vc291cmNlZm9yZ2UubmV0 L3Byb2plY3RzL2xpYmI2NAoqLwoKdHlwZWRlZiBlbnVtCnsKCXN0ZXBfQSwgc3RlcF9CLCBzdGVw X0MKfSBiYXNlNjRfZW5jb2Rlc3RlcDsKCnR5cGVkZWYgc3RydWN0CnsKCWJhc2U2NF9lbmNvZGVz dGVwIHN0ZXA7CgljaGFyIHJlc3VsdDsKCWludCBzdGVwY291bnQ7Cn0gYmFzZTY0X2VuY29kZXN0 YXRlOwp0eXBlZGVmIGVudW0KewoJc3RlcF9hLCBzdGVwX2IsIHN0ZXBfYywgc3RlcF9kCn0gYmFz ZTY0X2RlY29kZXN0ZXA7Cgp0eXBlZGVmIHN0cnVjdAp7CgliYXNlNjRfZGVjb2Rlc3RlcCBzdGVw OwoJY2hhciBwbGFpbmNoYXI7Cn0gYmFzZTY0X2RlY29kZXN0YXRlOwpjb25zdCBpbnQgQ0hBUlNf UEVSX0xJTkUgPSA3MjsKCnZvaWQgYmFzZTY0X2luaXRfZW5jb2Rlc3RhdGUoYmFzZTY0X2VuY29k ZXN0YXRlKiBzdGF0ZV9pbikKewoJc3RhdGVfaW4tPnN0ZXAgPSBzdGVwX0E7CglzdGF0ZV9pbi0+ cmVzdWx0ID0gMDsKCXN0YXRlX2luLT5zdGVwY291bnQgPSAwOwp9CgpjaGFyIGJhc2U2NF9lbmNv ZGVfdmFsdWUoY2hhciB2YWx1ZV9pbikKewoJc3RhdGljIGNvbnN0IGNoYXIqIGVuY29kaW5nID0g IkFCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFlaYWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXowMTIz NDU2Nzg5Ky8iOwoJaWYgKHZhbHVlX2luID4gNjMpIHJldHVybiAnPSc7CglyZXR1cm4gZW5jb2Rp bmdbKGludCl2YWx1ZV9pbl07Cn0KCmludCBiYXNlNjRfZW5jb2RlX2Jsb2NrKGNvbnN0IGNoYXIq IHBsYWludGV4dF9pbiwgaW50IGxlbmd0aF9pbiwgY2hhciogY29kZV9vdXQsIGJhc2U2NF9lbmNv ZGVzdGF0ZSogc3RhdGVfaW4pCnsKCWNvbnN0IGNoYXIqIHBsYWluY2hhciA9IHBsYWludGV4dF9p bjsKCWNvbnN0IGNoYXIqIGNvbnN0IHBsYWludGV4dGVuZCA9IHBsYWludGV4dF9pbiArIGxlbmd0 aF9pbjsKCWNoYXIqIGNvZGVjaGFyID0gY29kZV9vdXQ7CgljaGFyIHJlc3VsdDsKCWNoYXIgZnJh Z21lbnQ7CgkKCXJlc3VsdCA9IHN0YXRlX2luLT5yZXN1bHQ7CgkKCXN3aXRjaCAoc3RhdGVfaW4t PnN0ZXApCgl7CgkJd2hpbGUgKDEpCgkJewoJY2FzZSBzdGVwX0E6CgkJCWlmIChwbGFpbmNoYXIg PT0gcGxhaW50ZXh0ZW5kKQoJCQl7CgkJCQlzdGF0ZV9pbi0+cmVzdWx0ID0gcmVzdWx0OwoJCQkJ c3RhdGVfaW4tPnN0ZXAgPSBzdGVwX0E7CgkJCQlyZXR1cm4gY29kZWNoYXIgLSBjb2RlX291dDsK CQkJfQoJCQlmcmFnbWVudCA9ICpwbGFpbmNoYXIrKzsKCQkJcmVzdWx0ID0gKGZyYWdtZW50ICYg MHgwZmMpID4+IDI7CgkJCSpjb2RlY2hhcisrID0gYmFzZTY0X2VuY29kZV92YWx1ZShyZXN1bHQp OwoJCQlyZXN1bHQgPSAoZnJhZ21lbnQgJiAweDAwMykgPDwgNDsKCWNhc2Ugc3RlcF9COgoJCQlp ZiAocGxhaW5jaGFyID09IHBsYWludGV4dGVuZCkKCQkJewoJCQkJc3RhdGVfaW4tPnJlc3VsdCA9 IHJlc3VsdDsKCQkJCXN0YXRlX2luLT5zdGVwID0gc3RlcF9COwoJCQkJcmV0dXJuIGNvZGVjaGFy IC0gY29kZV9vdXQ7CgkJCX0KCQkJZnJhZ21lbnQgPSAqcGxhaW5jaGFyKys7CgkJCXJlc3VsdCB8 PSAoZnJhZ21lbnQgJiAweDBmMCkgPj4gNDsKCQkJKmNvZGVjaGFyKysgPSBiYXNlNjRfZW5jb2Rl X3ZhbHVlKHJlc3VsdCk7CgkJCXJlc3VsdCA9IChmcmFnbWVudCAmIDB4MDBmKSA8PCAyOwoJY2Fz ZSBzdGVwX0M6CgkJCWlmIChwbGFpbmNoYXIgPT0gcGxhaW50ZXh0ZW5kKQoJCQl7CgkJCQlzdGF0 ZV9pbi0+cmVzdWx0ID0gcmVzdWx0OwoJCQkJc3RhdGVfaW4tPnN0ZXAgPSBzdGVwX0M7CgkJCQly ZXR1cm4gY29kZWNoYXIgLSBjb2RlX291dDsKCQkJfQoJCQlmcmFnbWVudCA9ICpwbGFpbmNoYXIr KzsKCQkJcmVzdWx0IHw9IChmcmFnbWVudCAmIDB4MGMwKSA+PiA2OwoJCQkqY29kZWNoYXIrKyA9 IGJhc2U2NF9lbmNvZGVfdmFsdWUocmVzdWx0KTsKCQkJcmVzdWx0ICA9IChmcmFnbWVudCAmIDB4 MDNmKSA+PiAwOwoJCQkqY29kZWNoYXIrKyA9IGJhc2U2NF9lbmNvZGVfdmFsdWUocmVzdWx0KTsK CQkJCgkJCSsrKHN0YXRlX2luLT5zdGVwY291bnQpOwoJCQlpZiAoc3RhdGVfaW4tPnN0ZXBjb3Vu dCA9PSBDSEFSU19QRVJfTElORS80KQoJCQl7CgkJCQkvLypjb2RlY2hhcisrID0gJ1xuJzsKCQkJ CXN0YXRlX2luLT5zdGVwY291bnQgPSAwOwoJCQl9CgkJfQoJfQoJLyogY29udHJvbCBzaG91bGQg bm90IHJlYWNoIGhlcmUgKi8KCXJldHVybiBjb2RlY2hhciAtIGNvZGVfb3V0Owp9CgppbnQgYmFz ZTY0X2VuY29kZV9ibG9ja2VuZChjaGFyKiBjb2RlX291dCwgYmFzZTY0X2VuY29kZXN0YXRlKiBz dGF0ZV9pbikKewoJY2hhciogY29kZWNoYXIgPSBjb2RlX291dDsKCQoJc3dpdGNoIChzdGF0ZV9p bi0+c3RlcCkKCXsKCWNhc2Ugc3RlcF9COgoJCSpjb2RlY2hhcisrID0gYmFzZTY0X2VuY29kZV92 YWx1ZShzdGF0ZV9pbi0+cmVzdWx0KTsKCQkqY29kZWNoYXIrKyA9ICc9JzsKCQkqY29kZWNoYXIr KyA9ICc9JzsKCQlicmVhazsKCWNhc2Ugc3RlcF9DOgoJCSpjb2RlY2hhcisrID0gYmFzZTY0X2Vu Y29kZV92YWx1ZShzdGF0ZV9pbi0+cmVzdWx0KTsKCQkqY29kZWNoYXIrKyA9ICc9JzsKCQlicmVh azsKCWNhc2Ugc3RlcF9BOgoJCWJyZWFrOwoJfQoJLy8qY29kZWNoYXIrKyA9ICdcbic7CgkKCXJl dHVybiBjb2RlY2hhciAtIGNvZGVfb3V0Owp9CgppbnQgYmFzZTY0X2RlY29kZV92YWx1ZShjaGFy IHZhbHVlX2luKQp7CglzdGF0aWMgY29uc3QgY2hhciBkZWNvZGluZ1tdID0gezYyLC0xLC0xLC0x LDYzLDUyLDUzLDU0LDU1LDU2LDU3LDU4LDU5LDYwLDYxLC0xLC0xLC0xLC0yLC0xLC0xLC0xLDAs MSwyLDMsNCw1LDYsNyw4LDksMTAsMTEsMTIsMTMsMTQsMTUsMTYsMTcsMTgsMTksMjAsMjEsMjIs MjMsMjQsMjUsLTEsLTEsLTEsLTEsLTEsLTEsMjYsMjcsMjgsMjksMzAsMzEsMzIsMzMsMzQsMzUs MzYsMzcsMzgsMzksNDAsNDEsNDIsNDMsNDQsNDUsNDYsNDcsNDgsNDksNTAsNTF9OwoJc3RhdGlj IGNvbnN0IGNoYXIgZGVjb2Rpbmdfc2l6ZSA9IHNpemVvZihkZWNvZGluZyk7Cgl2YWx1ZV9pbiAt PSA0MzsKCWlmICh2YWx1ZV9pbiA8IDAgfHwgdmFsdWVfaW4gPj0gZGVjb2Rpbmdfc2l6ZSkgcmV0 dXJuIC0xOwoJcmV0dXJuIGRlY29kaW5nWyhpbnQpdmFsdWVfaW5dOwp9Cgp2b2lkIGJhc2U2NF9p bml0X2RlY29kZXN0YXRlKGJhc2U2NF9kZWNvZGVzdGF0ZSogc3RhdGVfaW4pCnsKCXN0YXRlX2lu LT5zdGVwID0gc3RlcF9hOwoJc3RhdGVfaW4tPnBsYWluY2hhciA9IDA7Cn0KCmludCBiYXNlNjRf ZGVjb2RlX2Jsb2NrKGNvbnN0IGNoYXIqIGNvZGVfaW4sIGNvbnN0IGludCBsZW5ndGhfaW4sIGNo YXIqIHBsYWludGV4dF9vdXQsIGJhc2U2NF9kZWNvZGVzdGF0ZSogc3RhdGVfaW4pCnsKCWNvbnN0 IGNoYXIqIGNvZGVjaGFyID0gY29kZV9pbjsKCWNoYXIqIHBsYWluY2hhciA9IHBsYWludGV4dF9v dXQ7CgljaGFyIGZyYWdtZW50OwoJCgkqcGxhaW5jaGFyID0gc3RhdGVfaW4tPnBsYWluY2hhcjsK CQoJc3dpdGNoIChzdGF0ZV9pbi0+c3RlcCkKCXsKCQl3aGlsZSAoMSkKCQl7CgljYXNlIHN0ZXBf YToKCQkJZG8gewoJCQkJaWYgKGNvZGVjaGFyID09IGNvZGVfaW4rbGVuZ3RoX2luKQoJCQkJewoJ CQkJCXN0YXRlX2luLT5zdGVwID0gc3RlcF9hOwoJCQkJCXN0YXRlX2luLT5wbGFpbmNoYXIgPSAq cGxhaW5jaGFyOwoJCQkJCXJldHVybiBwbGFpbmNoYXIgLSBwbGFpbnRleHRfb3V0OwoJCQkJfQoJ CQkJZnJhZ21lbnQgPSAoY2hhciliYXNlNjRfZGVjb2RlX3ZhbHVlKCpjb2RlY2hhcisrKTsKCQkJ fSB3aGlsZSAoZnJhZ21lbnQgPCAwKTsKCQkJKnBsYWluY2hhciAgICA9IChmcmFnbWVudCAmIDB4 MDNmKSA8PCAyOwoJY2FzZSBzdGVwX2I6CgkJCWRvIHsKCQkJCWlmIChjb2RlY2hhciA9PSBjb2Rl X2luK2xlbmd0aF9pbikKCQkJCXsKCQkJCQlzdGF0ZV9pbi0+c3RlcCA9IHN0ZXBfYjsKCQkJCQlz dGF0ZV9pbi0+cGxhaW5jaGFyID0gKnBsYWluY2hhcjsKCQkJCQlyZXR1cm4gcGxhaW5jaGFyIC0g cGxhaW50ZXh0X291dDsKCQkJCX0KCQkJCWZyYWdtZW50ID0gKGNoYXIpYmFzZTY0X2RlY29kZV92 YWx1ZSgqY29kZWNoYXIrKyk7CgkJCX0gd2hpbGUgKGZyYWdtZW50IDwgMCk7CgkJCSpwbGFpbmNo YXIrKyB8PSAoZnJhZ21lbnQgJiAweDAzMCkgPj4gNDsKCQkJKnBsYWluY2hhciAgICA9IChmcmFn bWVudCAmIDB4MDBmKSA8PCA0OwoJY2FzZSBzdGVwX2M6CgkJCWRvIHsKCQkJCWlmIChjb2RlY2hh ciA9PSBjb2RlX2luK2xlbmd0aF9pbikKCQkJCXsKCQkJCQlzdGF0ZV9pbi0+c3RlcCA9IHN0ZXBf YzsKCQkJCQlzdGF0ZV9pbi0+cGxhaW5jaGFyID0gKnBsYWluY2hhcjsKCQkJCQlyZXR1cm4gcGxh aW5jaGFyIC0gcGxhaW50ZXh0X291dDsKCQkJCX0KCQkJCWZyYWdtZW50ID0gKGNoYXIpYmFzZTY0 X2RlY29kZV92YWx1ZSgqY29kZWNoYXIrKyk7CgkJCX0gd2hpbGUgKGZyYWdtZW50IDwgMCk7CgkJ CSpwbGFpbmNoYXIrKyB8PSAoZnJhZ21lbnQgJiAweDAzYykgPj4gMjsKCQkJKnBsYWluY2hhciAg ICA9IChmcmFnbWVudCAmIDB4MDAzKSA8PCA2OwoJY2FzZSBzdGVwX2Q6CgkJCWRvIHsKCQkJCWlm IChjb2RlY2hhciA9PSBjb2RlX2luK2xlbmd0aF9pbikKCQkJCXsKCQkJCQlzdGF0ZV9pbi0+c3Rl cCA9IHN0ZXBfZDsKCQkJCQlzdGF0ZV9pbi0+cGxhaW5jaGFyID0gKnBsYWluY2hhcjsKCQkJCQly ZXR1cm4gcGxhaW5jaGFyIC0gcGxhaW50ZXh0X291dDsKCQkJCX0KCQkJCWZyYWdtZW50ID0gKGNo YXIpYmFzZTY0X2RlY29kZV92YWx1ZSgqY29kZWNoYXIrKyk7CgkJCX0gd2hpbGUgKGZyYWdtZW50 IDwgMCk7CgkJCSpwbGFpbmNoYXIrKyAgIHw9IChmcmFnbWVudCAmIDB4MDNmKTsKCQl9Cgl9Cgkv KiBjb250cm9sIHNob3VsZCBub3QgcmVhY2ggaGVyZSAqLwoJcmV0dXJuIHBsYWluY2hhciAtIHBs YWludGV4dF9vdXQ7Cn0KCgpjaGFyICpCYXNlNjRFbmNvZGUoY29uc3QgY2hhciogaW5wdXQsIHVp bnQzMl90IGlucHV0bGVuKQp7CiAgLyogc2V0IHVwIGEgZGVzdGluYXRpb24gYnVmZmVyIGxhcmdl IGVub3VnaCB0byBob2xkIHRoZSBlbmNvZGVkIGRhdGEgKi8KICBjaGFyKiBvdXRwdXQgPSAoY2hh ciopbWFsbG9jKDggKyAoaW5wdXRsZW4gKiA0KS8zKTsKICAvKiBrZWVwIHRyYWNrIG9mIG91ciBl bmNvZGVkIHBvc2l0aW9uICovCiAgY2hhciogYyA9IG91dHB1dDsKICAvKiBzdG9yZSB0aGUgbnVt YmVyIG9mIGJ5dGVzIGVuY29kZWQgYnkgYSBzaW5nbGUgY2FsbCAqLwogIGludCBjbnQgPSAwOwog IC8qIHdlIG5lZWQgYW4gZW5jb2RlciBzdGF0ZSAqLwogIGJhc2U2NF9lbmNvZGVzdGF0ZSBzOwoK ICAvKi0tLS0tLS0tLS0gU1RBUlQgRU5DT0RJTkcgLS0tLS0tLS0tLSovCiAgLyogaW5pdGlhbGlz ZSB0aGUgZW5jb2RlciBzdGF0ZSAqLwogIGJhc2U2NF9pbml0X2VuY29kZXN0YXRlKCZzKTsKICAv KiBnYXRoZXIgZGF0YSBmcm9tIHRoZSBpbnB1dCBhbmQgc2VuZCBpdCB0byB0aGUgb3V0cHV0ICov CiAgY250ID0gYmFzZTY0X2VuY29kZV9ibG9jayhpbnB1dCwgaW5wdXRsZW4sIGMsICZzKTsKICBj ICs9IGNudDsKICAvKiBzaW5jZSB3ZSBoYXZlIGVuY29kZWQgdGhlIGVudGlyZSBpbnB1dCBzdHJp bmcsIHdlIGtub3cgdGhhdCAKICAgICB0aGVyZSBpcyBubyBtb3JlIGlucHV0IGRhdGE7IGZpbmFs aXNlIHRoZSBlbmNvZGluZyAqLwogIGNudCA9IGJhc2U2NF9lbmNvZGVfYmxvY2tlbmQoYywgJnMp OwogIGMgKz0gY250OwogIC8qLS0tLS0tLS0tLSBTVE9QIEVOQ09ESU5HICAtLS0tLS0tLS0tKi8K CiAgLyogd2Ugd2FudCB0byBwcmludCB0aGUgZW5jb2RlZCBkYXRhLCBzbyBudWxsLXRlcm1pbmF0 ZSBpdDogKi8KICAqYyA9IDA7CgogIHJldHVybiBvdXRwdXQ7Cn0KCmNoYXIgKkJhc2U2NERlY29k ZShjb25zdCBjaGFyKiBpbnB1dCkKewogIC8qIHNldCB1cCBhIGRlc3RpbmF0aW9uIGJ1ZmZlciBs YXJnZSBlbm91Z2ggdG8gaG9sZCB0aGUgZW5jb2RlZCBkYXRhICovCiAgdW5zaWduZWQgaWxlbiA9 IHN0cmxlbihpbnB1dCk7CiAgY2hhciogb3V0cHV0ID0gKGNoYXIqKW1hbGxvYyhpbGVuKTsKICAv KiBrZWVwIHRyYWNrIG9mIG91ciBkZWNvZGVkIHBvc2l0aW9uICovCiAgY2hhciogYyA9IG91dHB1 dDsKICAvKiBzdG9yZSB0aGUgbnVtYmVyIG9mIGJ5dGVzIGRlY29kZWQgYnkgYSBzaW5nbGUgY2Fs bCAqLwogIGludCBjbnQgPSAwOwogIC8qIHdlIG5lZWQgYSBkZWNvZGVyIHN0YXRlICovCiAgYmFz ZTY0X2RlY29kZXN0YXRlIHM7CgogIC8qLS0tLS0tLS0tLSBTVEFSVCBERUNPRElORyAtLS0tLS0t LS0tKi8KICAvKiBpbml0aWFsaXNlIHRoZSBkZWNvZGVyIHN0YXRlICovCiAgYmFzZTY0X2luaXRf ZGVjb2Rlc3RhdGUoJnMpOwogIC8qIGRlY29kZSB0aGUgaW5wdXQgZGF0YSAqLwogIGNudCA9IGJh c2U2NF9kZWNvZGVfYmxvY2soaW5wdXQsIGlsZW4sIGMsICZzKTsKICBjICs9IGNudDsKICAvKiBu b3RlOiB0aGVyZSBpcyBubyBiYXNlNjRfZGVjb2RlX2Jsb2NrZW5kISAqLwogIC8qLS0tLS0tLS0t LSBTVE9QIERFQ09ESU5HICAtLS0tLS0tLS0tKi8KCiAgLyogd2Ugd2FudCB0byBwcmludCB0aGUg ZGVjb2RlZCBkYXRhLCBzbyBudWxsLXRlcm1pbmF0ZSBpdDogKi8KICAqYyA9IDA7CgogIHJldHVy biBvdXRwdXQ7Cn0KCgovKiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIEJBU0U2NCBFTkNP REUvREVDT0RFIEZVTkNUSU9OUyBFTkRTIEhFUkUgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQogKi8KCi8qIC0tLS0tLS0tLS0tLS0tLS0gdXRpbGl0eSBmbmNzICovCnVpbnQz Ml90IEdldEVsYXBzZWRUaW1lSW5NaWxsaVNlY29uZHMoc3RydWN0IHRpbWV2YWwgKlN0YXJ0VGlt ZSkKewogIHN0cnVjdCB0aW1ldmFsIE5vdzsKCiAgZ2V0dGltZW9mZGF5ICgmTm93LCBOVUxMKTsg CiAgcmV0dXJuIChOb3cudHZfc2VjIC0gU3RhcnRUaW1lLT50dl9zZWMpICogMTAwMCArIChOb3cu dHZfdXNlYyAtIFN0YXJ0VGltZS0+dHZfdXNlYykgLyAxMDAwOwp9CmRvdWJsZSBQcmludEVsYXBz ZWRUaW1lKHN0cnVjdCB0aW1ldmFsICpTdGFydFRpbWUsIHVuc2lnbmVkIGxvbmcgbG9uZyBpbnQg VG90YWxQcm9jZXNzZWRCeXRlcykKewogIGRvdWJsZSBUb3RhbE1CeXRlcyA9ICgoZG91YmxlKVRv dGFsUHJvY2Vzc2VkQnl0ZXMvKDEwMjQuMCoxMDI0KSk7IAogIHVuc2lnbmVkIEVJbk1zID0gR2V0 RWxhcHNlZFRpbWVJbk1pbGxpU2Vjb25kcyhTdGFydFRpbWUpOwogIGRvdWJsZSBBdmVyYWdlID0g VG90YWxNQnl0ZXMgLyAoMS4wICogRUluTXMpICogMTAwMC4wOwogIHByaW50ZigiXG5cdFRvdGFs IGRhdGEgcHJvY2Vzc2VkOiAlNi4yZiBNQnl0ZXNcblx0RWxhcHNlZCBUaW1lOiAldSBtcy5cblx0 QXZlcmFnZTogJTEwLjRmIE1CeXRlcy9zZWNzIFxuIixUb3RhbE1CeXRlcywgRUluTXMsIEF2ZXJh Z2UpOwogIHJldHVybiBBdmVyYWdlOwp9Cgp2b2lkIEluY0J5T25lKHVpbnQ4X3QgKkJ1ZiwgdWlu dDMyX3QgQnVmTGVuKQp7CiAgdW5zaWduZWQgdDsKICBmb3IgKHQ9MDsgdDxCdWZMZW47IHQrKykK ICAgIEJ1Zlt0XSsrOwp9CnVpbnQ4X3QgKkNyZWF0ZURhdGFCdWYoU2l6ZSkKewogIHJldHVybiAo dWludDhfdCAqKWNhbGxvYygxLCBTaXplKTsKfQoKLyogLS0tLS0tLS0tLS0tLS0tLSBlbmQgdXRp bGl0eSBmbmNzICovCgoKCiNkZWZpbmUgU0FMVF9TSVpFIDQgLy8gCiNkZWZpbmUgTUFYX05VTV9K VU1QUyA2NAojZGVmaW5lIEZBTFNFICgwVSkKI2RlZmluZSBUUlVFICghKEZBTFNFKSkKI2RlZmlu ZSBWRVJCT1NFCi8vI2RlZmluZSBPVkVSTFlfVkVSQk9TRQojZGVmaW5lIFJBTkRPTV9CVUZfU0la RSA4MTkyCnVpbnQ4X3QgUmFuZG9tQnVmW1JBTkRPTV9CVUZfU0laRV07Cgp1aW50MzJfdCBSYW5k b21CdWZTdGFydFBvcz05OTk5OTk5OTk7IC8vIEl0IG11c3QgYmUgYSBudW1iZXIgZ3JlYXRlciB0 aGFuIFJBTkRPTV9CVUZfU0laRSBmb3IgaW5pdGlhbGl6YXRpb24KCnZvaWQgUmVhZFJhbmRvbUJ5 dGVzRnJvbVVERXYodWludDMyX3QgQnl0ZUNvdW50LCB1aW50OF90ICpCdWZmZXIpCnsKICBGSUxF ICpmcDsKICAKICBmcCA9IGZvcGVuKCIvZGV2L3VyYW5kb20iLCAiciIpOwogIGlmICghZnApCiAg ewogICAgZnByaW50ZihzdGRlcnIsICJcblxuRVJST1IgT1BFTklORyAvZGV2L3VyYW5kb20hISEh XG5cbiIpOwogICAgZXhpdCgtMSk7CiAgfQogIAogIGZyZWFkKEJ1ZmZlciwgQnl0ZUNvdW50LCAx LCBmcCk7CiAgZmNsb3NlKGZwKTsKfQp2b2lkIFJhbmRvbWl6ZUJ1ZmZlcigpCnsKI2lmZGVmIFZF UkJPU0UKICBwcmludGYoIlJhbmRvbWl6aW5nIC4uLiBcbiIpOwojZW5kaWYKICBSYW5kb21CdWZT dGFydFBvcz0wOwogIFJlYWRSYW5kb21CeXRlc0Zyb21VREV2KFJBTkRPTV9CVUZfU0laRSwgUmFu ZG9tQnVmKTsKICAKI2lmZGVmIE9WRVJMWV9WRVJCT1NFCiAgaW50IHQ7CiAgZm9yICh0PTA7IHQ8 UkFORE9NX0JVRl9TSVpFOyB0KyspCiAgICBwcmludGYoIiV1ICIsUmFuZG9tQnVmW3RdKTsKICBw cmludGYoIlxuXG4iKTsKI2VuZGlmCn0KCnZvaWQgR2V0UmFuZG9tTnVtYmVycyh1aW50MzJfdCBC eXRlQ291bnQsIHVpbnQ4X3QgKkJ1ZmZlcikKewogIGlmIChSQU5ET01fQlVGX1NJWkUgPCBCeXRl Q291bnQpCiAgewogICAgUmVhZFJhbmRvbUJ5dGVzRnJvbVVERXYoQnl0ZUNvdW50LCBCdWZmZXIp OwogICAgcmV0dXJuOwogIH0KICBpZiAoUkFORE9NX0JVRl9TSVpFIDwgUmFuZG9tQnVmU3RhcnRQ b3MrQnl0ZUNvdW50KQogICAgUmFuZG9taXplQnVmZmVyKCk7CiAgaWYgKEJ5dGVDb3VudCA9PSAx KQogIHsKICAgIEJ1ZmZlclswXSA9IFJhbmRvbUJ1ZltSYW5kb21CdWZTdGFydFBvcysrXTsKICAg IHJldHVybjsKICB9CiAgbWVtY3B5KEJ1ZmZlciwgUmFuZG9tQnVmICsgUmFuZG9tQnVmU3RhcnRQ b3MsIEJ5dGVDb3VudCk7CiAgUmFuZG9tQnVmU3RhcnRQb3MgKz0gQnl0ZUNvdW50Owp9CnVpbnQ4 X3QgR2V0UmFuZG9tVUludDgodm9pZCkKewogIGlmIChSYW5kb21CdWZTdGFydFBvcyA+PSBSQU5E T01fQlVGX1NJWkUpCiAgICBSYW5kb21pemVCdWZmZXIoKTsKICByZXR1cm4gUmFuZG9tQnVmW1Jh bmRvbUJ1ZlN0YXJ0UG9zKytdOwp9CgoKLyogRnVuY3Rpb24gdXNlZCB0byBkZXRlcm1pbmUgaWYg ViBpcyB1bmlxdWUgYW1vbmcgdGhlIGZpcnN0IFBvcyBlbGVtZW50cwogKiBVc2VkIGJ5IHRoZSB4 b3JHZXRLZXkgZnVuY3Rpb24gdG8gY2hlY2sgcGFydGljbGUgbGVuZ3RoIHVuaXF1ZW5lc3MKICov CiNkZWZpbmUgTUFYX0JPRFlfU0laRSAxMDI0CgojZGVmaW5lIFNQX05VTV9KVU1QUyAwCiNkZWZp bmUgU1BfQk9EWV9MRU4gMQojZGVmaW5lIFNQX1NBTFRfREFUQSAzCiNkZWZpbmUgU1BfQk9EWSA3 CiNkZWZpbmUgR2V0Qm9keUxlbihLKSAoS1tTUF9CT0RZX0xFTl0gKyAyNTYgKiBLW1NQX0JPRFlf TEVOKzFdKQojZGVmaW5lIEdldEJvZHlQdHIoSykgKEsgKyBTUF9CT0RZKQojZGVmaW5lIEdldE51 bUp1bXBzKEspIChLW1NQX05VTV9KVU1QU10pCiNkZWZpbmUgeG9yQ29tcHV0ZUtleUJ1ZkxlbihC b2R5TGVuKSAoU1BfQk9EWStCb2R5TGVuKQoKLy8gQ3JlYXRlcyBYT1Iga2V5Ci8vIFRoZSBmaXJz dCBieXRlIHdpbGwgYmUgZXF1YWwgdG8gTnVtSnVtcHMKLy8gRm9sbG93aW5nIDIgYnl0ZXMgaXMg a2V5IGJvZHkgbGVuZ3RoCi8vIEZvbGxvd2luZyA0IGJ5dGVzIGFyZSByYW5kb20gc2FsdCBkYXRh Ci8vIEZvbGxvd2luZyBCb2R5TGVuIGJ5dGVzIGFyZSByYW5kb20gbnVtYmVycyBvYnRhaW5lZCBm cm9tIGJ1ZmZlcmVkIC9kZXYvdXJhbmRvbSBkYXRhLiBCT0RZTEVOIE1VU1QgQkUgQSBQT1dFUiBP RiAyIQovLyBSZXN1bHQgYnVmZmVyIG11c3QgYmUgZW5vdWdoIHRvIHN0b3JlIGtleSEhIE5vIGVy cm9yIGNoZWNraW5nIGlzIGRvbmUhISEKdm9pZCB4b3JHZXRLZXkodWludDhfdCBOdW1KdW1wcywg dWludDMyX3QgQm9keUxlbiwgdWludDhfdCAqS2V5QnVmKQp7CiAgYXNzZXJ0KE51bUp1bXBzID4g MSAmJiBCb2R5TGVuID4gMTUgJiYgTnVtSnVtcHM8TUFYX05VTV9KVU1QUyAmJiAoKEJvZHlMZW4t MSkmQm9keUxlbikgPT0gMCk7CiAgCiNpZmRlZiBWRVJCT1NFCiAgcHJpbnRmKCJHZW5lcmF0aW5n IGtleSAuLi4gQm9keUxlbjogJXUgTnVtSnVtcHM6ICV1XG4iLEJvZHlMZW4sTnVtSnVtcHMpOwoj ZW5kaWYKICBLZXlCdWZbU1BfTlVNX0pVTVBTXSA9ICh1aW50OF90KShOdW1KdW1wcyYyNTUpOwog IEtleUJ1ZltTUF9CT0RZX0xFTl0gPSAodWludDhfdCkoKEJvZHlMZW4gJSAyNTYpICYgMHhmZik7 CiAgS2V5QnVmW1NQX0JPRFlfTEVOKzFdID0gKHVpbnQ4X3QpKChCb2R5TGVuIC8gMjU2KSAmIDB4 ZmYpOwogIEdldFJhbmRvbU51bWJlcnMoU0FMVF9TSVpFICsgQm9keUxlbiwgS2V5QnVmICsgU1Bf U0FMVF9EQVRBKTsgLy8gRmlsbCA0IGJ5dGVzIHNhbHQgZGF0YSB3aXRoIHJhbmRvbSBudW1iZXJz Cn0KCnZvaWQgeG9yQW5hbHl6ZUtleSh1aW50OF90ICpLKQp7CiAgdWludDMyX3QgdDsKICAKICBw cmludGYoIi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIFNoaWZ0aW5nIHhvciBrZXkgYW5hbHl6 ZSAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tXG5OdW1KdW1wczogJXVcbkJvZHlMZW46ICV1 IG5TYWx0OiAiLCAKICAgICAgICAgS1swXSwgR2V0Qm9keUxlbihLKSk7CiAgZm9yICh0PTA7IHQg PCBTQUxUX1NJWkU7IHQrKykKICB7CiAgICBwcmludGYoIiAldSIsIEtbU1BfU0FMVF9EQVRBK3Rd KTsKICB9CiAgcHJpbnRmKCJcbiIpOwp9CgovLyBTdGFuZGFydCBDIGhhcyBub3QgUk9MIG9yIFJP UiBmdW5jdGlvbiwgYnV0IG1vc3QgbW9kZXJuIGNwdXMgaGFzIGluc3RydWN0aW9ucyBmb3IgY2ly Y3VsYXIgc2hpZnQgb3BlcmF0aW9ucwovLyBUaGlzIGlzIGEgcXVpY2sgYW5kIGRpcnR5IGNvZGUg Zm9yIHN0YW5kYXJ0IEMgdmVyc2lvbnMgYW5kIEludGVsIEZhbWlseSBjcHUgYXNzZW1ibGVyIG9w dGltaXplZCB2ZXJzaW9ucwoKI2RlZmluZSBHQ0NfSU5URUxfT1BUSU1JWkVEIAoKc3RhdGljIGlu bGluZSBpbnQgUk9MMzJfMShpbnQgdikgCnsKICAjaWYgZGVmaW5lZChfX0dOVUNfXykgIAogICAg I2lmIGRlZmluZWQoR0NDX0lOVEVMX09QVElNSVpFRCkKICAgICAgYXNtICgicm9sICUwOyIgOiI9 ciIodikgLyogb3V0cHV0ICovIDoiMCIodikgLyogaW5wdXQgKi8gKTsKICAgICAgcmV0dXJuIHY7 CiAgICAjZWxzZSAKICAgICAgcmV0dXJuICgoKHYpIDw8IDEpIHwgKCh2KSA+PiAzMSkpOwogICAg I2VuZGlmCiAgI2VuZGlmCn0Kc3RhdGljIGlubGluZSBpbnQgUk9SMzJfMShpbnQgdikgewogICNp ZiBkZWZpbmVkKF9fR05VQ19fKSAgCiAgICAjaWYgZGVmaW5lZChHQ0NfSU5URUxfT1BUSU1JWkVE KQogICAgICBhc20gKCJyb3IgJTA7IiA6Ij1yIih2KSAvKiBvdXRwdXQgKi8gOiIwIih2KSAvKiBp bnB1dCAqLyApOwogICAgICByZXR1cm4gdjsKICAgICNlbHNlIAogICAgICByZXR1cm4gKCgodikg Pj4gMSkgfCAoKHYpIDw8IDMxKSkKICAgICNlbmRpZgogICNlbmRpZgp9Ci8qIFVOT1BUSU1JWkVE IFZFUlNJT04gZm9yIEJFVFRFUiBVTkRFUlNUQU5ESU5HIE9GIFRIRSBGVU5DVElPTklORyBPRiBU SEUgQUxHT1JJVEhNLiBJVCBJUyBOT1QgVVNFRCBJTiBSRUFMIExJRkUuIFVTRSBPUFRJTUlaRUQg VkVSU0lPTlMhCiAqIEVuY3J5cHRzIG9yIGRlY3J5cHRzIEluT3V0QnVmIAogKiBLZXlCdWYgaXMg dGhlIHJhdyBrZXkgYnVmZmVyCiAqIEtleUNoZWNrU3VtIGlzIHRoZSBzdW0gb2YgYWxsIGtleSBj b25zdGl0dWVudHMqMy4gSElHSCBCSVQgTVVTVCBCRSBTRVQhIAogKiAgIFVzZWQgdG8gcHJldmVu dCAiUmVsYXRlZCBrZXkgYXR0YWNrcyIuIElmIHNvbWUgYml0cyBvZiB0aGUga2V5IGNoYW5nZXMs IGVudGlyZSBjeXBoZXJ0ZXh0IGNoYW5nZXMKICogSW5PdXREYXRhTGVuIGlzIHRoZSBsZW5ndGgg b2YgdGhlIGRhdGEgdG8gYmUgZW5jcnlwdGVkIG9yIGRlY3J5cHRlZAogKiBJbk91dEJ1ZiBpcyB0 aGUgcG9pbnRlciB0byB0aGUgZGF0YSB0byBiZSBlbmNyeXB0ZWQgb3IgZGVjcnlwdGVkCiAqIEFm dGVyIGV2ZXJ5IGVuY3J5cHRpb24gb3IgZGVjcnlwdGlvbiwgdGhlIHZhbHVlIG9mIHNhbHQgd2ls bCBiZSBzZXQgdG8gdGhlIG9yaWdpbmFsIG9uZQogKiBTbywgYmVmb3JlIGVuY3J5cHRpb24gb3Ig ZGVjcnlwdGlvbiwgaWYgeW91IHdhbnQgdG8gdXNlIGEgc3BlY2lmaWMgc2FsdCB2YWx1ZSwgYXNz aWduIHRoYXQgdG8gSydzIFNhbHQgdmFsdWUuIEVuYyBvciBEZWMgd2lsbCBiZSBkb25lIHdpdGgg dGhhdCB2YWx1ZQogKiBhbmQgYXQgdGhlIGVuZCBvZiB0aGUgZnVuY3Rpb24sIHRoZSBzYWx0IHZh bHVlIHdpbGwgYmUgc2V0IGJhY2sgdG8gaXRzIG9yaWdpbmFsIHN0YXRlCiAqIFRoaXMgbG9naWMg ZW5zdXJlcyB1cyB0aGlzOiBBbiBvcmlnaW5hbCBrZXkgaXMgY3JlYXRlZCB3aXRoIGFuIG9yaWdp bmFsIHNhbHQgdmFsdWUsIGZvciBleGFtcGxlIGZvciBhbiBvbmxpbmUgY29tbXVuaWNhdGlvbgog KiBmb3IgZWFjaCBkaXN0aW5jdCBwYWNrZXQsIGluIHRoZSBwYWNrZXQgaGVhZGVyLCB3ZSBjYW4g dHJhbnNtaXQgYSBzcGVjaWZpYyBzYWx0IHZhbHVlIGZvciB0aGF0IHBhY2tldCBhbmQgd2UgY2Fu IGVuY3J5cHQgaXQgd2l0aCBvcmlnaW5hbCBrZXkgYW5kIHNhbHQKICogd2hlbiB0aGUgcmVjZWl2 ZXIgcmVjZWl2ZXMgdGhlIHBhY2tldCwgZGVjcnlwdHMgdGhlIG5ldyBzYWx0IHZhbHVlIHdpdGgg dGhlIG9yaWdpbmFsIHNhbHQgdmFsdWUsIHNldCB0aGF0IHNhbHQgdmFsdWUgYXMgdGhlIG5ldyBz YWx0IHZhbHVlCiAqIGFuZCBkZWNyeXB0cyB0aGUgcGFja2V0IGJvZHkgd2l0aCB0aGF0IHNhbHQg dmFsdWUKICovCgojZGVmaW5lIE1ha2VYT1JFbmMoSW5PdXRCdWYsWE9SVmFsLFNhbHQsS2V5Q2hl Y2tTdW0sUGxhaW5UZXh0Q2hlY2tzdW0sTGFzdFZhbCxUbXBWYWwsQ291bnRlcilcClBsYWluVGV4 dENoZWNrc3VtICs9IEluT3V0QnVmW0NvdW50ZXJdOyBcClRtcFZhbCA9IEluT3V0QnVmW0NvdW50 ZXJdOyBcClhPUlZhbCBePSBMYXN0VmFsOyBcClhPUlZhbCBePSAqKFNhbHQgKyAoTGFzdFZhbCYo U0FMVF9TSVpFLTEpKSk7IFwKSW5PdXRCdWZbQ291bnRlcl0gXj0gKCh1aW50OF90KShYT1JWYWwp KTsgXApMYXN0VmFsID0gVG1wVmFsOyAKCiNkZWZpbmUgTWFrZVhPUkRlYyhJbk91dEJ1ZixYT1JW YWwsU2FsdCxLZXlDaGVja1N1bSxQbGFpblRleHRDaGVja3N1bSxMYXN0VmFsLENvdW50ZXIpXApY T1JWYWwgXj0gTGFzdFZhbDsgXApYT1JWYWwgXj0gKihTYWx0ICsgKExhc3RWYWwmKFNBTFRfU0la RS0xKSkpOyBcCkluT3V0QnVmW0NvdW50ZXJdIF49ICgodWludDhfdCkoWE9SVmFsKSk7IFwKTGFz dFZhbCA9IEluT3V0QnVmW0NvdW50ZXJdOyBcClBsYWluVGV4dENoZWNrc3VtICs9IExhc3RWYWw7 IAoKLy9TYWx0W0NvdW50ZXImU0FMVF9TSVpFXSsrOyBYT1JWYWwgXj0gKEtleUNoZWNrU3VtIF4g U2FsdFtDb3VudGVyJlNBTFRfU0laRV0pOyAKLyogOC1iaXQgQ1JDIHdpdGggcG9seW5vbWlhbCB4 XjgreF42K3heMyt4XjIrMSwgMHgxNEQuCiAgIENob3NlbiBiYXNlZCBvbiBLb29wbWFuLCBldCBh bC4gKDB4QTYgaW4gaGlzIG5vdGF0aW9uID0gMHgxNEQgPj4gMSk6CiAgIGh0dHA6Ly93d3cuZWNl LmNtdS5lZHUvfmtvb3BtYW4vcm9zZXMvZHNuMDQva29vcG1hbjA0X2NyY19wb2x5X2VtYmVkZGVk LnBkZgogKi8KCgpzdGF0aWMgdWludDhfdCBjcmM4X3RhYmxlW10gPSB7CiAgICAweDAwLCAweDNl LCAweDdjLCAweDQyLCAweGY4LCAweGM2LCAweDg0LCAweGJhLCAweDk1LCAweGFiLCAweGU5LCAw eGQ3LAogICAgMHg2ZCwgMHg1MywgMHgxMSwgMHgyZiwgMHg0ZiwgMHg3MSwgMHgzMywgMHgwZCwg MHhiNywgMHg4OSwgMHhjYiwgMHhmNSwKICAgIDB4ZGEsIDB4ZTQsIDB4YTYsIDB4OTgsIDB4MjIs IDB4MWMsIDB4NWUsIDB4NjAsIDB4OWUsIDB4YTAsIDB4ZTIsIDB4ZGMsCiAgICAweDY2LCAweDU4 LCAweDFhLCAweDI0LCAweDBiLCAweDM1LCAweDc3LCAweDQ5LCAweGYzLCAweGNkLCAweDhmLCAw eGIxLAogICAgMHhkMSwgMHhlZiwgMHhhZCwgMHg5MywgMHgyOSwgMHgxNywgMHg1NSwgMHg2Yiwg MHg0NCwgMHg3YSwgMHgzOCwgMHgwNiwKICAgIDB4YmMsIDB4ODIsIDB4YzAsIDB4ZmUsIDB4NTks IDB4NjcsIDB4MjUsIDB4MWIsIDB4YTEsIDB4OWYsIDB4ZGQsIDB4ZTMsCiAgICAweGNjLCAweGYy LCAweGIwLCAweDhlLCAweDM0LCAweDBhLCAweDQ4LCAweDc2LCAweDE2LCAweDI4LCAweDZhLCAw eDU0LAogICAgMHhlZSwgMHhkMCwgMHg5MiwgMHhhYywgMHg4MywgMHhiZCwgMHhmZiwgMHhjMSwg MHg3YiwgMHg0NSwgMHgwNywgMHgzOSwKICAgIDB4YzcsIDB4ZjksIDB4YmIsIDB4ODUsIDB4M2Ys IDB4MDEsIDB4NDMsIDB4N2QsIDB4NTIsIDB4NmMsIDB4MmUsIDB4MTAsCiAgICAweGFhLCAweDk0 LCAweGQ2LCAweGU4LCAweDg4LCAweGI2LCAweGY0LCAweGNhLCAweDcwLCAweDRlLCAweDBjLCAw eDMyLAogICAgMHgxZCwgMHgyMywgMHg2MSwgMHg1ZiwgMHhlNSwgMHhkYiwgMHg5OSwgMHhhNywg MHhiMiwgMHg4YywgMHhjZSwgMHhmMCwKICAgIDB4NGEsIDB4NzQsIDB4MzYsIDB4MDgsIDB4Mjcs IDB4MTksIDB4NWIsIDB4NjUsIDB4ZGYsIDB4ZTEsIDB4YTMsIDB4OWQsCiAgICAweGZkLCAweGMz LCAweDgxLCAweGJmLCAweDA1LCAweDNiLCAweDc5LCAweDQ3LCAweDY4LCAweDU2LCAweDE0LCAw eDJhLAogICAgMHg5MCwgMHhhZSwgMHhlYywgMHhkMiwgMHgyYywgMHgxMiwgMHg1MCwgMHg2ZSwg MHhkNCwgMHhlYSwgMHhhOCwgMHg5NiwKICAgIDB4YjksIDB4ODcsIDB4YzUsIDB4ZmIsIDB4NDEs IDB4N2YsIDB4M2QsIDB4MDMsIDB4NjMsIDB4NWQsIDB4MWYsIDB4MjEsCiAgICAweDliLCAweGE1 LCAweGU3LCAweGQ5LCAweGY2LCAweGM4LCAweDhhLCAweGI0LCAweDBlLCAweDMwLCAweDcyLCAw eDRjLAogICAgMHhlYiwgMHhkNSwgMHg5NywgMHhhOSwgMHgxMywgMHgyZCwgMHg2ZiwgMHg1MSwg MHg3ZSwgMHg0MCwgMHgwMiwgMHgzYywKICAgIDB4ODYsIDB4YjgsIDB4ZmEsIDB4YzQsIDB4YTQs IDB4OWEsIDB4ZDgsIDB4ZTYsIDB4NWMsIDB4NjIsIDB4MjAsIDB4MWUsCiAgICAweDMxLCAweDBm LCAweDRkLCAweDczLCAweGM5LCAweGY3LCAweGI1LCAweDhiLCAweDc1LCAweDRiLCAweDA5LCAw eDM3LAogICAgMHg4ZCwgMHhiMywgMHhmMSwgMHhjZiwgMHhlMCwgMHhkZSwgMHg5YywgMHhhMiwg MHgxOCwgMHgyNiwgMHg2NCwgMHg1YSwKICAgIDB4M2EsIDB4MDQsIDB4NDYsIDB4NzgsIDB4YzIs IDB4ZmMsIDB4YmUsIDB4ODAsIDB4YWYsIDB4OTEsIDB4ZDMsIDB4ZWQsCiAgICAweDU3LCAweDY5 LCAweDJiLCAweDE1fTsKCnVpbnQ4X3QgY3JjOCh1aW50OF90IGNyYywgdWludDhfdCAqZGF0YSwg c2l6ZV90IGxlbikKewogIHVpbnQ4X3QgKmVuZDsKCiAgaWYgKGxlbiA9PSAwKQogICAgcmV0dXJu IGNyYzsKICBjcmMgXj0gMHhmZjsKICBlbmQgPSBkYXRhICsgbGVuOwogIGRvIHsKICAgIGNyYyA9 IGNyYzhfdGFibGVbY3JjIF4gKmRhdGErK107CiAgfSB3aGlsZSAoZGF0YSA8IGVuZCk7CiAgcmV0 dXJuIGNyYyBeIDB4ZmY7Cn0KCiNkZWZpbmUgeG9yQ29tcHV0ZUtleUNoZWNrU3VtKEspIGNyYzgo MCwgSywgU1BfQk9EWSArIEdldEJvZHlMZW4oSykpCgp1bnNpZ25lZCBsb25nIGxvbmcgaW50IHhv ckVuY3J5cHQodWludDhfdCAqSywgdWludDhfdCAqU2FsdCwgdWludDhfdCBLZXlDaGVja1N1bSwg dWludDMyX3QgSW5PdXREYXRhTGVuLCB1aW50OF90ICpJbk91dEJ1ZikKeyAvLyBFbmNyeXB0cyBv ciBkZWNyeXB0cyBtZXNzYWdlIGFuZCByZXR1cm5zIGNoZWNrc3VtIG9mIHRoZSBJbk91dEJ1ZiBC RUZPUkUgZW5jeXB0aW9uCiAgLy8gU2FsdERhdGEgaXMgYSA0IGJ5dGVzIHVpbnQ4IGFycmF5ISBJ VCBJUyBOT1QgUkVBRCBPTkxZISBJVCBXSUxMIEJFIE1BTklQVUxBVEVEIEJZIFRIRSBGVU5DVElP TiEKICByZWdpc3RlciB1aW50MzJfdCB0LCB0dCwgTTsKICByZWdpc3RlciB1aW50OF90IFhPUlZh bCwgTGFzdFZhbCA9IDAsVG1wVmFsOyAvLyBMYXN0IFBMQUlOVEVYVCBieXRlIHByb2Nlc3NlZC4g SXQgd2lsbCBiZSBhbiBpbnB1dCBwYXJhbWV0ZXIgZm9yIHRoZSBuZXh0IGVuY3J5dHBpb24KICBy ZWdpc3RlciB1aW50NjRfdCBDaGVja3N1bT0wOwogIHJlZ2lzdGVyIHVpbnQzMl90IEJvZHlNYXNr ID0gR2V0Qm9keUxlbihLKTsgLy8gKzEgYmVjYXVzZSB3ZSB3aWxsIHVzZSB0aGlzICJNZXJzZW5u ZSBudW1iZXIiIGZvciAmIG9wZXJhdGlvbiBpbnN0ZWFkIG9mIG1vZHVsdXMgb3BlcmF0aW9uCiAg dWludDhfdCBCb2R5W01BWF9CT0RZX1NJWkVdOwogIAogIG1lbWNweShCb2R5LEsrU1BfQk9EWSxC b2R5TWFzayk7CiAgQm9keU1hc2stLTsKICAKICBTYWx0WzBdIF49IEtleUNoZWNrU3VtOwogIFNh bHRbMV0gXj0gS2V5Q2hlY2tTdW07CiAgU2FsdFsyXSBePSBLZXlDaGVja1N1bTsKICBTYWx0WzNd IF49IEtleUNoZWNrU3VtOwogIAogIC8vIEluaXRpYWwgcG9zaXRpb24gb2YgdGhlIHBvaW50ZXIg aXMgZGVwZW5kZW50IG9uIGFjdHVhbCBzYWx0IHZhbHVlCiAgTSA9IEJvZHlNYXNrICYgU2FsdFsw XTsKICAvL3ByaW50ZigieG9yRW5jcnlwdCBCb2R5TGVuOiAldSBLZXlDaGVja1N1bTogJXUgU2Fs dDogJXVcbiIsQm9keUxlbiwgS2V5Q2hlY2tTdW0sU2FsdCk7CiAgCiAgZm9yICh0PTA7IHQ8SW5P dXREYXRhTGVuOyB0KyspCiAgewogICAgLy8gRmlyc3QganVtcCBzdGVwIGlzIHByZXZpb3VzIHBs YWludGV4dCBieXRlCiAgICBYT1JWYWwgPSBCb2R5W01dOyAKICAgIE0gPSAoTSArIExhc3RWYWwp ICYgQm9keU1hc2s7IAoKICAgIGZvciAodHQ9MTsgdHQgPCBHZXROdW1KdW1wcyhLKTsgdHQrKykK ICAgIHsKICAgICAgLy8gQWxsIGZvbGxvd2luZyBqdW1wcyBhcmUgYmFzZWQgb24gYm9keSB2YWx1 ZXMKICAgICAgWE9SVmFsIF49IEJvZHlbTV07IAogICAgICBNID0gKE0gKyBCb2R5W01dKSAmIEJv ZHlNYXNrOyAKICAgIH0KICAgIE1ha2VYT1JFbmMoSW5PdXRCdWYsWE9SVmFsLFNhbHQsS2V5Q2hl Y2tTdW0sQ2hlY2tzdW0sTGFzdFZhbCxUbXBWYWwsdCk7CiAgICBCb2R5W01dKys7CiAgfQogIHJl dHVybiBDaGVja3N1bTsKfSAKdW5zaWduZWQgbG9uZyBsb25nIGludCB4b3JEZWNyeXB0KHVpbnQ4 X3QgKkssIHVpbnQ4X3QgKlNhbHQsIHVpbnQ4X3QgS2V5Q2hlY2tTdW0sIHVpbnQzMl90IEluT3V0 RGF0YUxlbiwgdWludDhfdCAqSW5PdXRCdWYpCnsgLy8gRGVjcnlwdHMgbWVzc2FnZSBhbmQgcmV0 dXJucyBjaGVja3N1bSBvZiB0aGUgSW5PdXRCdWYgQUZURVIgZW5jeXB0aW9uCiAgLy8gU2FsdERh dGEgaXMgYSA0IGJ5dGVzIHVpbnQ4IGFycmF5ISBJVCBJUyBOT1QgUkVBRCBPTkxZISBJVCBXSUxM IEJFIE1BTklQVUxBVEVEIEJZIFRIRSBGVU5DVElPTiEKICByZWdpc3RlciB1aW50MzJfdCB0LCB0 dCwgTTsKICByZWdpc3RlciB1aW50OF90IFhPUlZhbCwgTGFzdFZhbCA9IDA7IC8vIExhc3QgUExB SU5URVhUIGJ5dGUgcHJvY2Vzc2VkLiBJdCB3aWxsIGJlIGFuIGlucHV0IHBhcmFtZXRlciBmb3Ig dGhlIG5leHQgZW5jcnl0cGlvbgogIHJlZ2lzdGVyIHVpbnQ2NF90IENoZWNrc3VtPTA7CiAgcmVn aXN0ZXIgdWludDMyX3QgQm9keU1hc2sgPSBHZXRCb2R5TGVuKEspOyAvLyArMSBiZWNhdXNlIHdl IHdpbGwgdXNlIHRoaXMgIk1lcnNlbm5lIG51bWJlciIgZm9yICYgb3BlcmF0aW9uIGluc3RlYWQg b2YgbW9kdWx1cyBvcGVyYXRpb24KICB1aW50OF90IEJvZHlbTUFYX0JPRFlfU0laRV07CiAgCiAg bWVtY3B5KEJvZHksSytTUF9CT0RZLEJvZHlNYXNrKTsKICBCb2R5TWFzay0tOwogIAogIFNhbHRb MF0gXj0gS2V5Q2hlY2tTdW07CiAgU2FsdFsxXSBePSBLZXlDaGVja1N1bTsKICBTYWx0WzJdIF49 IEtleUNoZWNrU3VtOwogIFNhbHRbM10gXj0gS2V5Q2hlY2tTdW07CiAgCiAgLy8gSW5pdGlhbCBw b3NpdGlvbiBvZiB0aGUgcG9pbnRlciBpcyBkZXBlbmRlbnQgb24gYWN0dWFsIHNhbHQgdmFsdWUK ICBNID0gQm9keU1hc2sgJiBTYWx0WzBdOwogIC8vcHJpbnRmKCJ4b3JFbmNyeXB0IEJvZHlMZW46 ICV1IEtleUNoZWNrU3VtOiAldSBTYWx0OiAldVxuIixCb2R5TGVuLCBLZXlDaGVja1N1bSxTYWx0 KTsKICAKICBmb3IgKHQ9MDsgdDxJbk91dERhdGFMZW47IHQrKykKICB7CiAgICAvLyBGaXJzdCBq dW1wIHN0ZXAgaXMgcHJldmlvdXMgcGxhaW50ZXh0IGJ5dGUKICAgIFhPUlZhbCA9IEJvZHlbTV07 IAogICAgTSA9IChNICsgTGFzdFZhbCkgJiBCb2R5TWFzazsgCgogICAgZm9yICh0dD0xOyB0dCA8 IEdldE51bUp1bXBzKEspOyB0dCsrKQogICAgewogICAgICAvLyBBbGwgZm9sbG93aW5nIGp1bXBz IGFyZSBiYXNlZCBvbiBib2R5IHZhbHVlcwogICAgICBYT1JWYWwgXj0gQm9keVtNXTsgCiAgICAg IE0gPSAoTSArIEJvZHlbTV0pICYgQm9keU1hc2s7IAogICAgfQogICAgTWFrZVhPUkRlYyhJbk91 dEJ1ZixYT1JWYWwsU2FsdCxLZXlDaGVja1N1bSxDaGVja3N1bSxMYXN0VmFsLHQpOwogICAgQm9k eVtNXSsrOwogIH0KICByZXR1cm4gQ2hlY2tzdW07Cn0gCgp1bnNpZ25lZCBsb25nIGxvbmcgaW50 IHhvckVuY3J5cHRIT1AyKHVpbnQ4X3QgKkssIHVpbnQ4X3QgKlNhbHQsIHVpbnQ4X3QgS2V5Q2hl Y2tTdW0sIHVpbnQzMl90IEluT3V0RGF0YUxlbiwgdWludDhfdCAqSW5PdXRCdWYpCnsgLy8gRW5j cnlwdHMgb3IgZGVjcnlwdHMgbWVzc2FnZSBhbmQgcmV0dXJucyBjaGVja3N1bSBvZiB0aGUgSW5P dXRCdWYgQkVGT1JFIGVuY3lwdGlvbgogIC8vIFNhbHREYXRhIGlzIGEgNCBieXRlcyB1aW50OCBh cnJheSEgSVQgSVMgTk9UIFJFQUQgT05MWSEgSVQgV0lMTCBCRSBNQU5JUFVMQVRFRCBCWSBUSEUg RlVOQ1RJT04hCiAgcmVnaXN0ZXIgdWludDMyX3QgdCwgTTsKICByZWdpc3RlciB1aW50OF90IFhP UlZhbCwgTGFzdFZhbCA9IDAsVG1wVmFsOyAvLyBMYXN0IFBMQUlOVEVYVCBieXRlIHByb2Nlc3Nl ZC4gSXQgd2lsbCBiZSBhbiBpbnB1dCBwYXJhbWV0ZXIgZm9yIHRoZSBuZXh0IGVuY3J5dHBpb24K ICByZWdpc3RlciB1aW50NjRfdCBDaGVja3N1bT0wOwogIHJlZ2lzdGVyIHVpbnQzMl90IEJvZHlN YXNrID0gR2V0Qm9keUxlbihLKTsgLy8gKzEgYmVjYXVzZSB3ZSB3aWxsIHVzZSB0aGlzICJNZXJz ZW5uZSBudW1iZXIiIGZvciAmIG9wZXJhdGlvbiBpbnN0ZWFkIG9mIG1vZHVsdXMgb3BlcmF0aW9u CiAgdWludDhfdCBCb2R5W01BWF9CT0RZX1NJWkVdOwogIAogIG1lbWNweShCb2R5LEsrU1BfQk9E WSxCb2R5TWFzayk7CiAgQm9keU1hc2stLTsKICAKICBTYWx0WzBdIF49IEtleUNoZWNrU3VtOwog IFNhbHRbMV0gXj0gS2V5Q2hlY2tTdW07CiAgU2FsdFsyXSBePSBLZXlDaGVja1N1bTsKICBTYWx0 WzNdIF49IEtleUNoZWNrU3VtOwogIAogIC8vIEluaXRpYWwgcG9zaXRpb24gb2YgdGhlIHBvaW50 ZXIgaXMgZGVwZW5kZW50IG9uIGFjdHVhbCBzYWx0IHZhbHVlCiAgTSA9IEJvZHlNYXNrICYgU2Fs dFswXTsKICAvL3ByaW50ZigieG9yRW5jcnlwdCBCb2R5TGVuOiAldSBLZXlDaGVja1N1bTogJXUg U2FsdDogJXVcbiIsQm9keUxlbiwgS2V5Q2hlY2tTdW0sU2FsdCk7CiAgZm9yICh0PTA7IHQ8SW5P dXREYXRhTGVuOyB0KyspCiAgewogICAgLy8gRmlyc3QganVtcCBzdGVwIGlzIHByZXZpb3VzIHBs YWludGV4dCBieXRlCiAgICBYT1JWYWwgPSBCb2R5W01dOyAKICAgIE0gPSAoTSArIExhc3RWYWwp ICYgQm9keU1hc2s7IAogICAgLy8gQWxsIGZvbGxvd2luZyBqdW1wcyBhcmUgYmFzZWQgb24gYm9k eSB2YWx1ZXMKICAgIFhPUlZhbCBePSBCb2R5W01dOyAKICAgIE0gPSAoTSArIEJvZHlbTV0pICYg Qm9keU1hc2s7IAogICAgTWFrZVhPUkVuYyhJbk91dEJ1ZixYT1JWYWwsU2FsdCxLZXlDaGVja1N1 bSxDaGVja3N1bSxMYXN0VmFsLFRtcFZhbCx0KTsKICAgIEJvZHlbTV0rKzsKICB9CiAgcmV0dXJu IENoZWNrc3VtOwp9IAoKdW5zaWduZWQgbG9uZyBsb25nIGludCB4b3JEZWNyeXB0SE9QMih1aW50 OF90ICpLLCB1aW50OF90ICpTYWx0LCB1aW50OF90IEtleUNoZWNrU3VtLCB1aW50MzJfdCBJbk91 dERhdGFMZW4sIHVpbnQ4X3QgKkluT3V0QnVmKQp7IC8vIEVuY3J5cHRzIG9yIGRlY3J5cHRzIG1l c3NhZ2UgYW5kIHJldHVybnMgY2hlY2tzdW0gb2YgdGhlIEluT3V0QnVmIEJFRk9SRSBlbmN5cHRp b24KICAvLyBTYWx0RGF0YSBpcyBhIDQgYnl0ZXMgdWludDggYXJyYXkhIElUIElTIE5PVCBSRUFE IE9OTFkhIElUIFdJTEwgQkUgTUFOSVBVTEFURUQgQlkgVEhFIEZVTkNUSU9OIQogIHJlZ2lzdGVy IHVpbnQzMl90IHQsIE07CiAgcmVnaXN0ZXIgdWludDhfdCBYT1JWYWwsIExhc3RWYWwgPSAwOyAv LyBMYXN0IFBMQUlOVEVYVCBieXRlIHByb2Nlc3NlZC4gSXQgd2lsbCBiZSBhbiBpbnB1dCBwYXJh bWV0ZXIgZm9yIHRoZSBuZXh0IGVuY3J5dHBpb24KICByZWdpc3RlciB1aW50NjRfdCBDaGVja3N1 bT0wOwogIHJlZ2lzdGVyIHVpbnQzMl90IEJvZHlNYXNrID0gR2V0Qm9keUxlbihLKTsgLy8gKzEg YmVjYXVzZSB3ZSB3aWxsIHVzZSB0aGlzICJNZXJzZW5uZSBudW1iZXIiIGZvciAmIG9wZXJhdGlv biBpbnN0ZWFkIG9mIG1vZHVsdXMgb3BlcmF0aW9uCiAgdWludDhfdCBCb2R5W01BWF9CT0RZX1NJ WkVdOwogIAogIG1lbWNweShCb2R5LEsrU1BfQk9EWSxCb2R5TWFzayk7CiAgQm9keU1hc2stLTsK ICAKICBTYWx0WzBdIF49IEtleUNoZWNrU3VtOwogIFNhbHRbMV0gXj0gS2V5Q2hlY2tTdW07CiAg U2FsdFsyXSBePSBLZXlDaGVja1N1bTsKICBTYWx0WzNdIF49IEtleUNoZWNrU3VtOwogIAogIC8v IEluaXRpYWwgcG9zaXRpb24gb2YgdGhlIHBvaW50ZXIgaXMgZGVwZW5kZW50IG9uIGFjdHVhbCBz YWx0IHZhbHVlCiAgTSA9IEJvZHlNYXNrICYgU2FsdFswXTsKICAvL3ByaW50ZigieG9yRW5jcnlw dCBCb2R5TGVuOiAldSBLZXlDaGVja1N1bTogJXUgU2FsdDogJXVcbiIsQm9keUxlbiwgS2V5Q2hl Y2tTdW0sU2FsdCk7CiAgCiAgZm9yICh0PTA7IHQ8SW5PdXREYXRhTGVuOyB0KyspCiAgewogICAg Ly8gRmlyc3QganVtcCBzdGVwIGlzIHByZXZpb3VzIHBsYWludGV4dCBieXRlCiAgICBYT1JWYWwg PSBCb2R5W01dOyAKICAgIE0gPSAoTSArIExhc3RWYWwpICYgQm9keU1hc2s7IAogICAgLy8gQWxs IGZvbGxvd2luZyBqdW1wcyBhcmUgYmFzZWQgb24gYm9keSB2YWx1ZXMKICAgIFhPUlZhbCBePSBC b2R5W01dOyAKICAgIE0gPSAoTSArIEJvZHlbTV0pICYgQm9keU1hc2s7IAogICAgTWFrZVhPUkRl YyhJbk91dEJ1ZixYT1JWYWwsU2FsdCxLZXlDaGVja1N1bSxDaGVja3N1bSxMYXN0VmFsLHQpOwog ICAgQm9keVtNXSsrOwogIH0KICByZXR1cm4gQ2hlY2tzdW07Cn0gCnVuc2lnbmVkIGxvbmcgbG9u ZyBpbnQgeG9yRW5jcnlwdEhPUDModWludDhfdCAqSywgdWludDhfdCAqU2FsdCwgdWludDhfdCBL ZXlDaGVja1N1bSwgdWludDMyX3QgSW5PdXREYXRhTGVuLCB1aW50OF90ICpJbk91dEJ1ZikKeyAv LyBFbmNyeXB0cyBvciBkZWNyeXB0cyBtZXNzYWdlIGFuZCByZXR1cm5zIGNoZWNrc3VtIG9mIHRo ZSBJbk91dEJ1ZiBCRUZPUkUgZW5jeXB0aW9uCiAgLy8gU2FsdERhdGEgaXMgYSA0IGJ5dGVzIHVp bnQ4IGFycmF5ISBJVCBJUyBOT1QgUkVBRCBPTkxZISBJVCBXSUxMIEJFIE1BTklQVUxBVEVEIEJZ IFRIRSBGVU5DVElPTiEKICByZWdpc3RlciB1aW50MzJfdCB0LCBNOwogIHJlZ2lzdGVyIHVpbnQ4 X3QgWE9SVmFsLCBMYXN0VmFsID0gMCxUbXBWYWw7IC8vIExhc3QgUExBSU5URVhUIGJ5dGUgcHJv Y2Vzc2VkLiBJdCB3aWxsIGJlIGFuIGlucHV0IHBhcmFtZXRlciBmb3IgdGhlIG5leHQgZW5jcnl0 cGlvbgogIHJlZ2lzdGVyIHVpbnQ2NF90IENoZWNrc3VtPTA7CiAgcmVnaXN0ZXIgdWludDMyX3Qg Qm9keU1hc2sgPSBHZXRCb2R5TGVuKEspOyAvLyArMSBiZWNhdXNlIHdlIHdpbGwgdXNlIHRoaXMg Ik1lcnNlbm5lIG51bWJlciIgZm9yICYgb3BlcmF0aW9uIGluc3RlYWQgb2YgbW9kdWx1cyBvcGVy YXRpb24KICB1aW50OF90IEJvZHlbTUFYX0JPRFlfU0laRV07CiAgCiAgbWVtY3B5KEJvZHksSytT UF9CT0RZLEJvZHlNYXNrKTsKICBCb2R5TWFzay0tOwogIAogIFNhbHRbMF0gXj0gS2V5Q2hlY2tT dW07CiAgU2FsdFsxXSBePSBLZXlDaGVja1N1bTsKICBTYWx0WzJdIF49IEtleUNoZWNrU3VtOwog IFNhbHRbM10gXj0gS2V5Q2hlY2tTdW07CiAgCiAgLy8gSW5pdGlhbCBwb3NpdGlvbiBvZiB0aGUg cG9pbnRlciBpcyBkZXBlbmRlbnQgb24gYWN0dWFsIHNhbHQgdmFsdWUKICBNID0gQm9keU1hc2sg JiBTYWx0WzBdOwogIC8vcHJpbnRmKCJ4b3JFbmNyeXB0IEJvZHlMZW46ICV1IEtleUNoZWNrU3Vt OiAldSBTYWx0OiAldVxuIixCb2R5TGVuLCBLZXlDaGVja1N1bSxTYWx0KTsKICBmb3IgKHQ9MDsg dDxJbk91dERhdGFMZW47IHQrKykKICB7CiAgICAvLyBGaXJzdCBqdW1wIHN0ZXAgaXMgcHJldmlv dXMgcGxhaW50ZXh0IGJ5dGUKICAgIFhPUlZhbCA9IEJvZHlbTV07IAogICAgTSA9IChNICsgTGFz dFZhbCkgJiBCb2R5TWFzazsgCiAgICAvLyBBbGwgZm9sbG93aW5nIGp1bXBzIGFyZSBiYXNlZCBv biBib2R5IHZhbHVlcwogICAgWE9SVmFsIF49IEJvZHlbTV07IAogICAgTSA9IChNICsgQm9keVtN XSkgJiBCb2R5TWFzazsgCiAgICBYT1JWYWwgXj0gQm9keVtNXTsgCiAgICBNID0gKE0gKyBCb2R5 W01dKSAmIEJvZHlNYXNrOyAKICAgIE1ha2VYT1JFbmMoSW5PdXRCdWYsWE9SVmFsLFNhbHQsS2V5 Q2hlY2tTdW0sQ2hlY2tzdW0sTGFzdFZhbCxUbXBWYWwsdCk7CiAgICBCb2R5W01dKys7CiAgfQog IHJldHVybiBDaGVja3N1bTsKfSAKCnVuc2lnbmVkIGxvbmcgbG9uZyBpbnQgeG9yRGVjcnlwdEhP UDModWludDhfdCAqSywgdWludDhfdCAqU2FsdCwgdWludDhfdCBLZXlDaGVja1N1bSwgdWludDMy X3QgSW5PdXREYXRhTGVuLCB1aW50OF90ICpJbk91dEJ1ZikKeyAvLyBFbmNyeXB0cyBvciBkZWNy eXB0cyBtZXNzYWdlIGFuZCByZXR1cm5zIGNoZWNrc3VtIG9mIHRoZSBJbk91dEJ1ZiBCRUZPUkUg ZW5jeXB0aW9uCiAgLy8gU2FsdERhdGEgaXMgYSA0IGJ5dGVzIHVpbnQ4IGFycmF5ISBJVCBJUyBO T1QgUkVBRCBPTkxZISBJVCBXSUxMIEJFIE1BTklQVUxBVEVEIEJZIFRIRSBGVU5DVElPTiEKICBy ZWdpc3RlciB1aW50MzJfdCB0LCBNOwogIHJlZ2lzdGVyIHVpbnQ4X3QgWE9SVmFsLCBMYXN0VmFs ID0gMDsgLy8gTGFzdCBQTEFJTlRFWFQgYnl0ZSBwcm9jZXNzZWQuIEl0IHdpbGwgYmUgYW4gaW5w dXQgcGFyYW1ldGVyIGZvciB0aGUgbmV4dCBlbmNyeXRwaW9uCiAgcmVnaXN0ZXIgdWludDY0X3Qg Q2hlY2tzdW09MDsKICByZWdpc3RlciB1aW50MzJfdCBCb2R5TWFzayA9IEdldEJvZHlMZW4oSyk7 IC8vICsxIGJlY2F1c2Ugd2Ugd2lsbCB1c2UgdGhpcyAiTWVyc2VubmUgbnVtYmVyIiBmb3IgJiBv cGVyYXRpb24gaW5zdGVhZCBvZiBtb2R1bHVzIG9wZXJhdGlvbgogIHVpbnQ4X3QgQm9keVtNQVhf Qk9EWV9TSVpFXTsKICAKICBtZW1jcHkoQm9keSxLK1NQX0JPRFksQm9keU1hc2spOwogIEJvZHlN YXNrLS07CiAgCiAgU2FsdFswXSBePSBLZXlDaGVja1N1bTsKICBTYWx0WzFdIF49IEtleUNoZWNr U3VtOwogIFNhbHRbMl0gXj0gS2V5Q2hlY2tTdW07CiAgU2FsdFszXSBePSBLZXlDaGVja1N1bTsK ICAKICAvLyBJbml0aWFsIHBvc2l0aW9uIG9mIHRoZSBwb2ludGVyIGlzIGRlcGVuZGVudCBvbiBh Y3R1YWwgc2FsdCB2YWx1ZQogIE0gPSBCb2R5TWFzayAmIFNhbHRbMF07CiAgLy9wcmludGYoInhv ckVuY3J5cHQgQm9keUxlbjogJXUgS2V5Q2hlY2tTdW06ICV1IFNhbHQ6ICV1XG4iLEJvZHlMZW4s IEtleUNoZWNrU3VtLFNhbHQpOwogIAogIGZvciAodD0wOyB0PEluT3V0RGF0YUxlbjsgdCsrKQog IHsKICAgIC8vIEZpcnN0IGp1bXAgc3RlcCBpcyBwcmV2aW91cyBwbGFpbnRleHQgYnl0ZQogICAg WE9SVmFsID0gQm9keVtNXTsgCiAgICBNID0gKE0gKyBMYXN0VmFsKSAmIEJvZHlNYXNrOyAKICAg IC8vIEFsbCBmb2xsb3dpbmcganVtcHMgYXJlIGJhc2VkIG9uIGJvZHkgdmFsdWVzCiAgICBYT1JW YWwgXj0gQm9keVtNXTsgCiAgICBNID0gKE0gKyBCb2R5W01dKSAmIEJvZHlNYXNrOyAKICAgIFhP UlZhbCBePSBCb2R5W01dOyAKICAgIE0gPSAoTSArIEJvZHlbTV0pICYgQm9keU1hc2s7IAogICAg TWFrZVhPUkRlYyhJbk91dEJ1ZixYT1JWYWwsU2FsdCxLZXlDaGVja1N1bSxDaGVja3N1bSxMYXN0 VmFsLHQpOwogICAgQm9keVtNXSsrOwogIH0KICByZXR1cm4gQ2hlY2tzdW07Cn0gCgovLyNkZWZp bmUgeG9yRW5jcnlwdERlY3J5cHQgeG9yRW5jcnlwdERlY3J5cHRIT1A1Ci8qIE1lbWNweSBCZW5j aG1hcmsxIDogCiAqIFRoaXMgZnVuY3Rpb24gCiAqICAgQ3JlYXRlcyBhIE4gYnl0ZXMgcmFuZG9t IGRhdGEgYnVmZmVyIAogKiAgIENyZWF0ZXMgYW5vdGhlciBOIGJ5dGVzIHplcm8gZmlsbGVkIGJ1 ZmZlciAoRGVzdEJ1ZikKICogICBTdGFydHMgYW4gaXRlcmF0aW9uIAogKiAgIEZvciBlYWNoIGl0 ZXJhdGlvbiwgaW5jcmVhc2VzIGV2ZXJ5IGJ5dGUgb2YgdGhlIGRhdGEgYnkgMQogKiAgIENvcGll cyB0aGUgZGF0YSBidWZmZXIgdG8gRGVzdEJ1ZgogKiAgIFByaW50cyB0aGUgZWxhcHNlZCB0aW1l IAogKi8Kdm9pZCBNZW1DcHlCZW5jaG1hcmsxKHVpbnQzMl90IFRlc3RTYW1wbGVMZW5ndGgsIHVp bnQzMl90IE51bUl0ZXJhdGlvbnMpCnsKICB1aW50OF90ICpEYXRhID0gQ3JlYXRlRGF0YUJ1ZihU ZXN0U2FtcGxlTGVuZ3RoKTsKICB1aW50OF90ICpEZXN0QnVmID0gQ3JlYXRlRGF0YUJ1ZihUZXN0 U2FtcGxlTGVuZ3RoKTsKICB1bnNpZ25lZCBsb25nIGxvbmcgaW50IFRvdGFsUHJvY2Vzc2VkQnl0 ZXMgPSAwOwogIHVuc2lnbmVkIHQ7CiAgCiAgLypwcmludGYoIi0tLS0tLS0tLS0tLS0tLS0tLS0t IE1lbUNweUJlbmNobWFyazEgMTogQkFTSUMgRlVOQ1RJT05BTElUWSAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tXG4iCiAgICAgICAgIlRoaXMgZnVuY3Rpb25cbiAxLkNyZWF0ZXMgYSAldSBieXRl cyByYW5kb20gZGF0YSBidWZmZXJcbkNyZWF0ZXMgYW5vdGhlciBidWZmZXIoRGVzdEJ1Zikgd2l0 aCB0aGUgc2FtZSBzaXplXG5NYWtlcyAldSBpdGVyYXRpb25cbiIKICAgICAgICAgIkZvciBlYWNo IGl0ZXJhdGlvbiwgaW5jcmVhc2VzIGV2ZXJ5IGJ5dGUgb2YgdGhlIGRhdGEgYnkgMVxuQ29waWVz IHRoZSBkYXRhIGJ1ZmZlciB0byBEZXN0QnVmXG5QcmludHMgdGhlIGVsYXBzZWQgdGltZSIsVGVz dFNhbXBsZUxlbmd0aCxOdW1JdGVyYXRpb25zKTsqLwogIHByaW50ZigiTWVtQ3B5QmVuY2htYXJr MVxuXHRUZXN0U2FtcGxlTGVuZ3RoOiAldVxuXHROdW1JdGVyYXRpb25zOiAldSAuLi4gIixUZXN0 U2FtcGxlTGVuZ3RoLE51bUl0ZXJhdGlvbnMpOyAgCiAgc3RydWN0IHRpbWV2YWwgU3RhcnRUaW1l OwogIGdldHRpbWVvZmRheSAoJlN0YXJ0VGltZSwgTlVMTCk7IAogIAogIGZvciAodD0wOyB0PE51 bUl0ZXJhdGlvbnM7IHQrKykKICB7CiAgICBJbmNCeU9uZShEYXRhLCBUZXN0U2FtcGxlTGVuZ3Ro KTsKICAgIG1lbWNweShEZXN0QnVmLCBEYXRhLCBUZXN0U2FtcGxlTGVuZ3RoKTsKICAgIFRvdGFs UHJvY2Vzc2VkQnl0ZXMgKz0gVGVzdFNhbXBsZUxlbmd0aDsKICB9CiAgUHJpbnRFbGFwc2VkVGlt ZSgmU3RhcnRUaW1lLFRvdGFsUHJvY2Vzc2VkQnl0ZXMpOwogIGZyZWUoRGF0YSk7CiAgZnJlZShE ZXN0QnVmKTsKfQoKLyogQmVuY2htYXJrMSA6IAogKiBUaGlzIGZ1bmN0aW9uIAogKiAgIENyZWF0 ZXMgYSBrZXkgd2l0aCBOdW1KdW1wcyBwYXJ0aWNsZXMgYW5kIHdpdGggYSBib2R5IGxlbmd0aCBv ZiBCb2R5TGVuCiAqICAgQ3JlYXRlcyBhIE4gYnl0ZXMgcmFuZG9tIHplcm8gZmlsbGVkIGJ1ZmZl ciAKICogICBTdGFydHMgYW4gaXRlcmF0aW9uIG9mIE51bUl0ZXJhdGlvbnMgdGltZXMKICogICBG b3IgZWFjaCBpdGVyYXRpb24sIGluY3JlYXNlcyBldmVyeSBieXRlIG9mIHRoZSBkYXRhIGJ5IDEK ICogICBFbmNyeXB0cyB0aGUgZGF0YQogKiAgIFByaW50cyB0aGUgZWxhcHNlZCB0aW1lIAogKi8K ZG91YmxlIEJlbmNobWFyazEodWludDhfdCBOdW1KdW1wcywgdWludDMyX3QgQm9keUxlbiwgdWlu dDMyX3QgVGVzdFNhbXBsZUxlbmd0aCwgdWludDMyX3QgTnVtSXRlcmF0aW9ucykKewogIHVpbnQ4 X3QgKktleUJ1ZiA9ICh1aW50OF90ICopbWFsbG9jKHhvckNvbXB1dGVLZXlCdWZMZW4oQm9keUxl bikpOwogIHVpbnQ4X3QgKkRhdGEgPSBDcmVhdGVEYXRhQnVmKFRlc3RTYW1wbGVMZW5ndGgpOwog IHVuc2lnbmVkIGxvbmcgbG9uZyBpbnQgVG90YWxQcm9jZXNzZWRCeXRlcyA9IDA7CiAgdWludDMy X3QgdCxTYWx0OwogIHVpbnQ4X3QgS2V5Q2hlY2tTdW07CiAgCiAgcHJpbnRmKCJCZW5jaG1hcmsx XG5cdE51bUp1bXBzOiAldVxuXHRCb2R5TGVuOiAldVxuXHRUZXN0U2FtcGxlTGVuZ3RoOiAldVxu XHROdW1JdGVyYXRpb25zOiAldSAuLi4gIixOdW1KdW1wcyxCb2R5TGVuLFRlc3RTYW1wbGVMZW5n dGgsTnVtSXRlcmF0aW9ucyk7ICAKICAKICBHZXRSYW5kb21OdW1iZXJzKFRlc3RTYW1wbGVMZW5n dGgsIERhdGEpOwogIHhvckdldEtleShOdW1KdW1wcywgQm9keUxlbiwgS2V5QnVmKTsKICBLZXlD aGVja1N1bSA9IHhvckNvbXB1dGVLZXlDaGVja1N1bShLZXlCdWYpOwogIHhvckFuYWx5emVLZXko S2V5QnVmKTsKICBzdHJ1Y3QgdGltZXZhbCBTdGFydFRpbWU7CiAgZ2V0dGltZW9mZGF5ICgmU3Rh cnRUaW1lLCBOVUxMKTsgCiAgCiAgZm9yICh0PTA7IHQ8TnVtSXRlcmF0aW9uczsgdCsrKQogIHsK ICAgIEluY0J5T25lKERhdGEsIFRlc3RTYW1wbGVMZW5ndGgpOwogICAgU2FsdD0xMjM0OwogICAg eG9yRW5jcnlwdChLZXlCdWYsICh1aW50OF90ICopKCZTYWx0KSwgS2V5Q2hlY2tTdW0sIFRlc3RT YW1wbGVMZW5ndGgsIERhdGEpOwogICAgVG90YWxQcm9jZXNzZWRCeXRlcyArPSBUZXN0U2FtcGxl TGVuZ3RoOwogIH0KICBkb3VibGUgQXZlcmFnZSA9IFByaW50RWxhcHNlZFRpbWUoJlN0YXJ0VGlt ZSxUb3RhbFByb2Nlc3NlZEJ5dGVzKTsKICBmcmVlKERhdGEpOwogIGZyZWUoS2V5QnVmKTsKICBy ZXR1cm4gQXZlcmFnZTsKfQpzdGF0aWMgaW5saW5lIHVpbnQ2NF90IEJ1ZkNoZWNrU3VtKHVpbnQ4 X3QgKkJ1ZiwgdWludDY0X3QgQnVmTGVuKQp7CiAgdWludDY0X3QgdCwgQ2hlY2tTdW0gPSAwOwog IAogIGZvciAodD0wOyB0PEJ1ZkxlbjsgdCsrKQogICAgQ2hlY2tTdW0gKz0gQnVmW3RdOwogIHJl dHVybiBDaGVja1N1bTsKfQpkb3VibGUgQmVuY2htYXJrSE9QMih1aW50OF90IE51bUp1bXBzLCB1 aW50MzJfdCBCb2R5TGVuLCB1aW50MzJfdCBUZXN0U2FtcGxlTGVuZ3RoLCB1aW50MzJfdCBOdW1J dGVyYXRpb25zKQp7CiAgdWludDhfdCAqS2V5QnVmID0gKHVpbnQ4X3QgKiltYWxsb2MoeG9yQ29t cHV0ZUtleUJ1ZkxlbihCb2R5TGVuKSk7CiAgdWludDhfdCAqRGF0YSA9IENyZWF0ZURhdGFCdWYo VGVzdFNhbXBsZUxlbmd0aCk7CiAgdW5zaWduZWQgbG9uZyBsb25nIGludCBUb3RhbFByb2Nlc3Nl ZEJ5dGVzID0gMDsKICB1aW50MzJfdCB0OwogIHVpbnQ4X3QgS2V5Q2hlY2tTdW07CiAgdWludDMy X3QgIFNhbHREYXRhPTEyNDU7CiAgCiAgcHJpbnRmKCJCZW5jaG1hcmtIb3AyXG5cdE51bUp1bXBz OiAldVxuXHRCb2R5TGVuOiAldVxuXHRUZXN0U2FtcGxlTGVuZ3RoOiAldVxuXHROdW1JdGVyYXRp b25zOiAldSAuLi4gIixOdW1KdW1wcyxCb2R5TGVuLFRlc3RTYW1wbGVMZW5ndGgsTnVtSXRlcmF0 aW9ucyk7ICAKICAKICBHZXRSYW5kb21OdW1iZXJzKFRlc3RTYW1wbGVMZW5ndGgsIERhdGEpOwog IHhvckdldEtleShOdW1KdW1wcywgQm9keUxlbiwgS2V5QnVmKTsKICBLZXlDaGVja1N1bSA9IHhv ckNvbXB1dGVLZXlDaGVja1N1bShLZXlCdWYpOwogIHhvckFuYWx5emVLZXkoS2V5QnVmKTsKICBz dHJ1Y3QgdGltZXZhbCBTdGFydFRpbWU7CiAgZ2V0dGltZW9mZGF5ICgmU3RhcnRUaW1lLCBOVUxM KTsgCiAgCiAgQnVmQ2hlY2tTdW0oRGF0YSwgVGVzdFNhbXBsZUxlbmd0aCk7ICAKICBmb3IgKHQ9 MDsgdDxOdW1JdGVyYXRpb25zOyB0KyspCiAgewogICAgSW5jQnlPbmUoRGF0YSwgVGVzdFNhbXBs ZUxlbmd0aCk7CiAgICB4b3JFbmNyeXB0SE9QMihLZXlCdWYsICh1aW50OF90ICopKCZTYWx0RGF0 YSksIEtleUNoZWNrU3VtLCBUZXN0U2FtcGxlTGVuZ3RoLCBEYXRhKTsKICAgIFRvdGFsUHJvY2Vz c2VkQnl0ZXMgKz0gVGVzdFNhbXBsZUxlbmd0aDsKICB9CiAgZG91YmxlIEF2ZXJhZ2UgPSBQcmlu dEVsYXBzZWRUaW1lKCZTdGFydFRpbWUsVG90YWxQcm9jZXNzZWRCeXRlcyk7CiAgZnJlZShEYXRh KTsKICBmcmVlKEtleUJ1Zik7CiAgcmV0dXJuIEF2ZXJhZ2U7Cn0KCmRvdWJsZSBCZW5jaG1hcmtI T1AzKHVpbnQ4X3QgTnVtSnVtcHMsIHVpbnQzMl90IEJvZHlMZW4sIHVpbnQzMl90IFRlc3RTYW1w bGVMZW5ndGgsIHVpbnQzMl90IE51bUl0ZXJhdGlvbnMpCnsKICB1aW50OF90ICpLZXlCdWYgPSAo dWludDhfdCAqKW1hbGxvYyh4b3JDb21wdXRlS2V5QnVmTGVuKEJvZHlMZW4pKTsKICB1aW50OF90 ICpEYXRhID0gQ3JlYXRlRGF0YUJ1ZihUZXN0U2FtcGxlTGVuZ3RoKTsKICB1bnNpZ25lZCBsb25n IGxvbmcgaW50IFRvdGFsUHJvY2Vzc2VkQnl0ZXMgPSAwOwogIHVpbnQzMl90IHQ7CiAgdWludDhf dCBLZXlDaGVja1N1bTsKICB1aW50MzJfdCBTYWx0RGF0YTsKICAKICBwcmludGYoIkJlbmNobWFy a0hvcDNcblx0TnVtSnVtcHM6ICV1XG5cdEJvZHlMZW46ICV1XG5cdFRlc3RTYW1wbGVMZW5ndGg6 ICV1XG5cdE51bUl0ZXJhdGlvbnM6ICV1IC4uLiAiLE51bUp1bXBzLEJvZHlMZW4sVGVzdFNhbXBs ZUxlbmd0aCxOdW1JdGVyYXRpb25zKTsgIAogIAogIEdldFJhbmRvbU51bWJlcnMoVGVzdFNhbXBs ZUxlbmd0aCwgRGF0YSk7CiAgeG9yR2V0S2V5KE51bUp1bXBzLCBCb2R5TGVuLCBLZXlCdWYpOwog IEtleUNoZWNrU3VtID0geG9yQ29tcHV0ZUtleUNoZWNrU3VtKEtleUJ1Zik7CiAgeG9yQW5hbHl6 ZUtleShLZXlCdWYpOwogIHN0cnVjdCB0aW1ldmFsIFN0YXJ0VGltZTsKICBnZXR0aW1lb2ZkYXkg KCZTdGFydFRpbWUsIE5VTEwpOyAKICAKICBCdWZDaGVja1N1bShEYXRhLCBUZXN0U2FtcGxlTGVu Z3RoKTsgIAogIGZvciAodD0wOyB0PE51bUl0ZXJhdGlvbnM7IHQrKykKICB7CiAgICBJbmNCeU9u ZShEYXRhLCBUZXN0U2FtcGxlTGVuZ3RoKTsKICAgIHhvckVuY3J5cHRIT1AzKEtleUJ1ZiwgKHVp bnQ4X3QgKikoJlNhbHREYXRhKSwgS2V5Q2hlY2tTdW0sIFRlc3RTYW1wbGVMZW5ndGgsIERhdGEp OwogICAgVG90YWxQcm9jZXNzZWRCeXRlcyArPSBUZXN0U2FtcGxlTGVuZ3RoOwogIH0KICBkb3Vi bGUgQXZlcmFnZSA9IFByaW50RWxhcHNlZFRpbWUoJlN0YXJ0VGltZSxUb3RhbFByb2Nlc3NlZEJ5 dGVzKTsKICBmcmVlKERhdGEpOwogIGZyZWUoS2V5QnVmKTsKICByZXR1cm4gQXZlcmFnZTsKfQoK I2RlZmluZSBURVNUU1RSMSAiVMOcUkvDh0Uga2FyYWt0ZXIga3VsbGFuxLFuxLF6IERFTkVNRS4g VMOcUkvDh0Uga2FyYWt0ZXIga3VsbGFuxLFuxLF6IERFTkVNRS4gdXp1dXV1dXV1bi4gVMOcUkvD h0Uga2FyYWt0ZXIga3VsbGFuxLFuxLF6IERFTkVNRS4gw4dvayB1enVuIMOnb2shMjIyVMOcUkvD h0Uga2FyYWt0ZXIga3VsbGFuxLFuxLF6IERFTkVNRS4gVMOcUkvDh0Uga2FyYWt0ZXIga3VsbGFu xLFuxLF6IERFTkVNRS4gdXp1dXV1dXV1bi4gVMOcUkvDh0Uga2FyYWt0ZXIga3VsbGFuxLFuxLF6 IERFTkVNRS4gw4dvayB1enVuIMOnb2shZnJmclTDnFJLw4dFIGthcmFrdGVyIGt1bGxhbsSxbsSx eiBERU5FTUUuIFTDnFJLw4dFIGthcmFrdGVyIGt1bGxhbsSxbsSxeiBERU5FTUUuIHV6dXV1dXV1 dW4uIFTDnFJLw4dFIGthcmFrdGVyIGt1bGxhbsSxbsSxeiBERU5FTUUuIMOHb2sgdXp1biDDp29r ISIKI2RlZmluZSBURVNUU1RSMV9MRU4gc3RybGVuKFRFU1RTVFIxKQp2b2lkIENoZWNrT3B0aW1p emVkVmVyc2lvbih1bnNpZ25lZCBOdW1KdW1wcywgdW5zaWduZWQgQm9keUxlbikKewogIHVuc2ln bmVkIGxvbmcgbG9uZyBpbnQgRExlbiwgT3JpZ2luYWxQbGFpblRleHRDaGVja1N1bSwgQ2hlY2tT dW1SZXR1cm5lZEZyb21FbmNyeXB0b3IsIENoZWNrU3VtUmV0dXJuZWRGcm9tRGVjcnlwdG9yOwog IHVuc2lnbmVkIFJhd0tleUxlbiA9IHhvckNvbXB1dGVLZXlCdWZMZW4oQm9keUxlbik7CiAgdWlu dDhfdCAqS2V5QnVmID0gKHVpbnQ4X3QgKiltYWxsb2MoUmF3S2V5TGVuKTsKICB1aW50OF90IFBs YWluVGV4dEJ1ZlsxMzIwMDBdLCBEYXRhWzEzMjAwMF07CiAgdW5zaWduZWQgbG9uZyBsb25nIGlu dCBLZXlDaGVja1N1bTsKICB1aW50MzJfdCBTYWx0RGF0YTsKICAKICBwcmludGYoIi0tLS0tLS0t LS0tLS0tLS0tLS0tIFRFU1RJTkcgT1BUSU1JWkVEIFZFUlNJT04gRk9SICV1IFBBUlRJQ0xFUyAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tXG4iLE51bUp1bXBzKTsKICB4b3JHZXRLZXkoTnVtSnVt cHMsIEJvZHlMZW4sIEtleUJ1Zik7CiAgS2V5Q2hlY2tTdW0gPSB4b3JDb21wdXRlS2V5Q2hlY2tT dW0oS2V5QnVmKTsKICBETGVuID0gVEVTVFNUUjFfTEVOOyAKICBtZW1jcHkoRGF0YSwgVEVTVFNU UjEsIERMZW4pOwogIG1lbWNweShQbGFpblRleHRCdWYsIFRFU1RTVFIxLCBETGVuKTsKICAKICBm b3IgKERMZW4gPSAwOyBETGVuIDwgVEVTVFNUUjFfTEVOOyBETGVuKyspCiAgewogICAgUGxhaW5U ZXh0QnVmW0RMZW5dID0gKHVpbnQ4X3QpKERMZW4gJiAyNTUpOwogICAgRGF0YVtETGVuXSA9IFBs YWluVGV4dEJ1ZltETGVuXTsKICAgIE9yaWdpbmFsUGxhaW5UZXh0Q2hlY2tTdW0gPSBCdWZDaGVj a1N1bShEYXRhLCBETGVuKzEpOwogICAgU2FsdERhdGE9MTIzNDsKICAgIENoZWNrU3VtUmV0dXJu ZWRGcm9tRW5jcnlwdG9yID0geG9yRW5jcnlwdChLZXlCdWYsICh1aW50OF90ICopKCZTYWx0RGF0 YSksIEtleUNoZWNrU3VtLCBETGVuKzEsIERhdGEpOyAvLyBXZSBlbmNyeXB0IHdpdGggbm9uLW9w dGltaXplZCB2ZXJzaW9uCiAgICBpZiAoT3JpZ2luYWxQbGFpblRleHRDaGVja1N1bSAhPSBDaGVj a1N1bVJldHVybmVkRnJvbUVuY3J5cHRvcikKICAgIHsKICAgICAgcHJpbnRmKCJPcmlnaW5hbCBD aGVja3N1bSAlbGx1IHJldHVybmVkIGZyb20gQnVmQ2hlY2tzdW0gZm5jIDw+IENoZWNrc3VtICVs bHUgcmV0dXJuZWQgZnJvbSB4b3JFbmNyeXB0RGVjcnlwdFxuIixPcmlnaW5hbFBsYWluVGV4dENo ZWNrU3VtLENoZWNrU3VtUmV0dXJuZWRGcm9tRW5jcnlwdG9yKTsKICAgICAgZXhpdCgtMSk7CiAg ICB9CiAgICAvLyBTYWx0IGRhdGEgY2hhbmdlcyB3aXRoIGV2ZXJ5IGVuY3J5cHQgZGVjcnlwdCEg CiAgICBTYWx0RGF0YT0xMjM0OwogICAgaWYgKE51bUp1bXBzID09IDIpCiAgICAgIENoZWNrU3Vt UmV0dXJuZWRGcm9tRGVjcnlwdG9yID0geG9yRGVjcnlwdEhPUDIoS2V5QnVmLCAodWludDhfdCAq KSgmU2FsdERhdGEpLCBLZXlDaGVja1N1bSwgRExlbisxLCBEYXRhKTsKICAgIGVsc2UgaWYgKE51 bUp1bXBzID09IDMpCiAgICAgIENoZWNrU3VtUmV0dXJuZWRGcm9tRGVjcnlwdG9yID0geG9yRGVj cnlwdEhPUDMoS2V5QnVmLCAodWludDhfdCAqKSgmU2FsdERhdGEpLCBLZXlDaGVja1N1bSwgRExl bisxLCBEYXRhKTsKICAgIGVsc2UgZXhpdCgtMSk7CiAgICAKICAgIGlmIChPcmlnaW5hbFBsYWlu VGV4dENoZWNrU3VtICE9IENoZWNrU3VtUmV0dXJuZWRGcm9tRGVjcnlwdG9yKQogICAgewogICAg ICBwcmludGYoIk9yaWdpbmFsIENoZWNrc3VtICVsbHUgcmV0dXJuZWQgZnJvbSBCdWZDaGVja3N1 bSBmbmMgPD4gQ2hlY2tzdW0gJWxsdSByZXR1cm5lZCBmcm9tIEhPUCBkZWN5cHRvclxuIixPcmln aW5hbFBsYWluVGV4dENoZWNrU3VtLENoZWNrU3VtUmV0dXJuZWRGcm9tRGVjcnlwdG9yKTsKICAg ICAgZXhpdCgtMSk7CiAgICB9CiAgICBpZiAobWVtY21wKChjaGFyICopRGF0YSwgKGNoYXIgKilQ bGFpblRleHRCdWYsIERMZW4rMSkgIT0gMCkKICAgIHsKICAgICAgcHJpbnRmKCJTdHJpbmc6ICVz IC4uLiBUZXN0MSByZXN1bHQ6IEZBSUxFRCEhISFcbi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS1cbiIsIERhdGEpOwogICAgICBleGl0KC0xKTsKICAgIH0KICB9CiAgcHJp bnRmKCJ4b3JFbmNyeXB0RGVjcnlwdEhPUCV1IFNVQ0NFU1NGVUwhXG4iLE51bUp1bXBzKTsKfQp2 b2lkIFRlc3QxKHVuc2lnbmVkIE51bUp1bXBzLCB1bnNpZ25lZCBCb2R5TGVuKQp7CiAgdW5zaWdu ZWQgbG9uZyBsb25nIGludCBETGVuLCBPcmlnaW5hbFBsYWluVGV4dENoZWNrU3VtLCBDaGVja1N1 bVJldHVybmVkRnJvbUVuY3J5cHRvciwgQ2hlY2tTdW1SZXR1cm5lZEZyb21EZWNyeXB0b3I7CiAg dW5zaWduZWQgUmF3S2V5TGVuID0geG9yQ29tcHV0ZUtleUJ1ZkxlbihCb2R5TGVuKTsKICB1aW50 OF90ICpLZXlCdWYgPSAodWludDhfdCAqKW1hbGxvYyhSYXdLZXlMZW4pOwogIHVpbnQ4X3QgRGF0 YVsyMDQ4XSxEYXRhMlsyMDQ4XTsKICBjaGFyICpCYXNlNjRFbmNvZGVkS2V5U3RyLCAqQmFzZTY0 Q2lwaGVyVGV4dDsKICB1aW50OF90IEtleUNoZWNrU3VtOwogIHVpbnQzMl90IFNhbHREYXRhPTEy MzQ7CiAgCiAgcHJpbnRmKCItLS0tLS0tLS0tLSBURVNUIDE6IEJBU0lDIEZVTkNUSU9OQUxJVFko JXUgSnVtcHMpIC0tLS0tLS0tLS0tLS0tXG4iLE51bUp1bXBzKTsKICB4b3JHZXRLZXkoTnVtSnVt cHMsIEJvZHlMZW4sIEtleUJ1Zik7CiAgS2V5Q2hlY2tTdW0gPSB4b3JDb21wdXRlS2V5Q2hlY2tT dW0oS2V5QnVmKTsKICBCYXNlNjRFbmNvZGVkS2V5U3RyID0gQmFzZTY0RW5jb2RlKChjb25zdCBj aGFyICopS2V5QnVmLCBSYXdLZXlMZW4pOwogIHByaW50ZigiQmFzZTY0IGVuY29kZWQga2V5OiAl c1xuIiwgQmFzZTY0RW5jb2RlZEtleVN0cik7CiNpZmRlZiBPVkVSTFlfVkVSQk9TRQogIHByaW50 ZigiQW5hbHl6aW5nIHJhdyBrZXkgZGF0YTpcbiIpOwogIFRQYXJzZWRLZXkgKlBLMCA9IHhvclBh cnNlS2V5KEtleUJ1Zik7CiAgeG9yQW5hbHl6ZUtleShQSzApOwogIGZyZWUoUEswKTsKICBmcmVl KEtleUJ1Zik7CiNlbmRpZgogIHhvckFuYWx5emVLZXkoS2V5QnVmKTsKICBtZW1zZXQoJkRhdGEs IDAsIHNpemVvZihEYXRhKSk7CiAgbWVtc2V0KCZEYXRhMiwgMCwgc2l6ZW9mKERhdGEyKSk7CiAg RExlbiA9IFRFU1RTVFIxX0xFTjsgCiAgbWVtY3B5KERhdGEsIFRFU1RTVFIxLCBETGVuKTsKICBt ZW1jcHkoRGF0YTIsIFRFU1RTVFIxLCBETGVuKTsKICBPcmlnaW5hbFBsYWluVGV4dENoZWNrU3Vt ID0gQnVmQ2hlY2tTdW0oRGF0YSwgRExlbik7CiAgQ2hlY2tTdW1SZXR1cm5lZEZyb21FbmNyeXB0 b3IgPSB4b3JFbmNyeXB0KEtleUJ1ZiwgKHVpbnQ4X3QgKikoJlNhbHREYXRhKSwgS2V5Q2hlY2tT dW0sIERMZW4sIERhdGEpOyAvLyBXZSBlbmNyeXB0IHdpdGggbm9uLW9wdGltaXplZCB2ZXJzaW9u CiAgaWYgKE9yaWdpbmFsUGxhaW5UZXh0Q2hlY2tTdW0gIT0gQ2hlY2tTdW1SZXR1cm5lZEZyb21F bmNyeXB0b3IpCiAgewogICAgcHJpbnRmKCJPcmlnaW5hbCBDaGVja3N1bSAlbGx1IHJldHVybmVk IGZyb20gQnVmQ2hlY2tzdW0gZm5jIDw+IENoZWNrc3VtICVsbHUgcmV0dXJuZWQgZnJvbSBub24t b3B0aW1pemVkIGVuY3J5cHRvclxuIixPcmlnaW5hbFBsYWluVGV4dENoZWNrU3VtLENoZWNrU3Vt UmV0dXJuZWRGcm9tRW5jcnlwdG9yKTsKICAgIGV4aXQoLTEpOwogIH0gZWxzZSBwcmludGYoIk9y aWdpbmFsUGxhaW5UZXh0Q2hlY2tTdW0gJWxsdSA9IENoZWNrU3VtUmV0dXJuZWRGcm9tRW5jcnlw dG9yICVsbHUgOjogU1VDQ0VTUyFcbiIsT3JpZ2luYWxQbGFpblRleHRDaGVja1N1bSxDaGVja1N1 bVJldHVybmVkRnJvbUVuY3J5cHRvcik7CiAgLy8gTm93IGxldCdzIGVuY3J5cHQgd2l0aCB0aGUg b3B0aW1pemVkIGVuY3J5cHRvcgogIFNhbHREYXRhPTEyMzQ7CiAgCiAgaWYgKE51bUp1bXBzID09 IDIpCiAgICBDaGVja1N1bVJldHVybmVkRnJvbUVuY3J5cHRvciA9IHhvckVuY3J5cHRIT1AyKEtl eUJ1ZiwgKHVpbnQ4X3QgKikoJlNhbHREYXRhKSwgS2V5Q2hlY2tTdW0sIERMZW4sIERhdGEyKTsg CiAgZWxzZSBpZiAoTnVtSnVtcHMgPT0gMykKICAgIENoZWNrU3VtUmV0dXJuZWRGcm9tRW5jcnlw dG9yID0geG9yRW5jcnlwdEhPUDMoS2V5QnVmLCAodWludDhfdCAqKSgmU2FsdERhdGEpLCBLZXlD aGVja1N1bSwgRExlbiwgRGF0YTIpOyAKICBlbHNlIGV4aXQoLTEpOwogIAogIAogIGlmIChPcmln aW5hbFBsYWluVGV4dENoZWNrU3VtICE9IENoZWNrU3VtUmV0dXJuZWRGcm9tRW5jcnlwdG9yKQog IHsKICAgIHByaW50ZigiT3JpZ2luYWwgQ2hlY2tzdW0gJWxsdSByZXR1cm5lZCBmcm9tIEJ1ZkNo ZWNrc3VtIGZuYyA8PiBDaGVja3N1bSAlbGx1IHJldHVybmVkIGZyb20gb3B0aW1pemVkIGVuY3J5 cHRvclxuIixPcmlnaW5hbFBsYWluVGV4dENoZWNrU3VtLENoZWNrU3VtUmV0dXJuZWRGcm9tRW5j cnlwdG9yKTsKICAgIGV4aXQoLTEpOwogIH0gZWxzZSBwcmludGYoIk9yaWdpbmFsUGxhaW5UZXh0 Q2hlY2tTdW0gJWxsdSA9IENoZWNrU3VtUmV0dXJuZWRGcm9tT3B0aW1pemVkRW5jcnlwdG9yICVs bHUgOjogU1VDQ0VTUyFcbiIsT3JpZ2luYWxQbGFpblRleHRDaGVja1N1bSxDaGVja1N1bVJldHVy bmVkRnJvbUVuY3J5cHRvcik7ICAKICBpZiAobWVtY21wKChjaGFyICopRGF0YSwgRGF0YTIsIERM ZW4pICE9IDApCiAgewogICAgcHJpbnRmKCJOb24tb3B0aW1pemVkIGFuZCBvcHRpbWl6ZWQgZW5j cnlwdG9yIGZ1bmN0aW9ucyBvdXRwdXRzIGFyZSBkaWZmZXJlbnQhIEZBSUxFRCEgRkFJTEVEIVxu Iik7CiAgICBleGl0KC0xKTsKICB9CiAgICAKICBCYXNlNjRDaXBoZXJUZXh0ID0gQmFzZTY0RW5j b2RlKChjb25zdCBjaGFyICopRGF0YSwgRExlbik7CiAgcHJpbnRmKCJCYXNlNjRDaXBoZXJUZXh0 OiAlc1xuIiwgQmFzZTY0Q2lwaGVyVGV4dCk7CiAgcHJpbnRmKCJcblxuRGVjcnlwdGlvbiBwcm9j ZXNzOlxuXG4iKTsKICBTYWx0RGF0YT0xMjM0OwogIHVpbnQ4X3QgKksgPSAodWludDhfdCAqKUJh c2U2NERlY29kZShCYXNlNjRFbmNvZGVkS2V5U3RyKTsKICAKICBpZiAobWVtY21wKChjaGFyICop S2V5QnVmLCAoY2hhciAqKUssIFJhd0tleUxlbikgIT0gMCkKICB7CiAgICBwcmludGYoIk9yaWdp bmFsIGtleSBhbmQgYmFzZTY0IGVuY29kZWQgYW5kIGRlY29kZWQga2V5cyBhcmUgZGlmZmVyZW50 ISEhISFcbiIpOwogICAgZXhpdCgtMSk7CiAgfQogIAogIGlmIChOdW1KdW1wcyA9PSAyKQogICAg Q2hlY2tTdW1SZXR1cm5lZEZyb21EZWNyeXB0b3IgPSB4b3JEZWNyeXB0SE9QMihLLCAodWludDhf dCAqKSgmU2FsdERhdGEpLCBLZXlDaGVja1N1bSwgRExlbiwgRGF0YSk7CiAgZWxzZSBpZiAoTnVt SnVtcHMgPT0gMykKICAgIENoZWNrU3VtUmV0dXJuZWRGcm9tRGVjcnlwdG9yID0geG9yRGVjcnlw dEhPUDMoSywgKHVpbnQ4X3QgKikoJlNhbHREYXRhKSwgS2V5Q2hlY2tTdW0sIERMZW4sIERhdGEp OwogIGVsc2UgZXhpdCgtMSk7CiAgCiAgaWYgKE9yaWdpbmFsUGxhaW5UZXh0Q2hlY2tTdW0gIT0g Q2hlY2tTdW1SZXR1cm5lZEZyb21EZWNyeXB0b3IpCiAgewogICAgcHJpbnRmKCJPcmlnaW5hbCBD aGVja3N1bSAlbGx1IHJldHVybmVkIGZyb20gQnVmQ2hlY2tzdW0gZm5jIDw+IENoZWNrc3VtICVs bHUgcmV0dXJuZWQgZnJvbSBIT1AgZGVjeXB0b3JcbiIsT3JpZ2luYWxQbGFpblRleHRDaGVja1N1 bSxDaGVja1N1bVJldHVybmVkRnJvbURlY3J5cHRvcik7CiAgICBleGl0KC0xKTsKICB9IGVsc2Ug cHJpbnRmKCJPcmlnaW5hbFBsYWluVGV4dENoZWNrU3VtICVsbHUgPSBDaGVja1N1bVJldHVybmVk RnJvbURlY3J5cHRvciAlbGx1IDo6IFNVQ0NFU1MhXG4iLE9yaWdpbmFsUGxhaW5UZXh0Q2hlY2tT dW0sQ2hlY2tTdW1SZXR1cm5lZEZyb21EZWNyeXB0b3IpOwogIAogIGlmIChtZW1jbXAoKGNoYXIg KilEYXRhLCBURVNUU1RSMSwgRExlbikgPT0gMCkKICB7CiAgICBwcmludGYoIlN0cmluZzogJXMg Li4uIFRlc3QxIHJlc3VsdDogU1VDQ0VTU0ZVTCEhISFcbi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS1cbiIsIERhdGEpOwogIH0KICBlbHNlIHsKICAgIHByaW50ZigiU3Ry aW5nOiAlcyAuLi4gVGVzdDEgcmVzdWx0OiBGQUlMRUQhISEhXG4tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tXG4iLCBEYXRhKTsKICAgIGV4aXQoLTEpOwogIH0KICAvL2V4 aXQoLTEpOwp9CnZvaWQgRDEoKQp7CiAgaW50IHQ7CiAgcmVnaXN0ZXIgdWludDhfdCBWPTA7CiAg Zm9yICh0PTA7dDwxMjg7dCsrKQogIHsKICAgIHByaW50ZigiJXUgIixWKTsKICAgIFYgKz0gdDsK ICB9Cn0KY2hhciAqR2V0QmluU3RyKHVpbnQzMl90IHZhbCwgY2hhciAqUmVzQnVmKQp7CiAgY2hh ciAqcDsKICB1bnNpZ25lZCBpbnQgdDsKICBwID0gUmVzQnVmOwogIHQgPSAweDgwMDAwMDAwOyAv LyBzY2FuIDMyIGJpdHMKICBmb3IgKCA7IHQgPiAwOyB0ID0gdCA+PiAxKSAKICB7CiAgICBpZiAo dmFsICYgdCkKICAgICAgKnArKyA9ICcxJzsKICAgIGVsc2UgKnArKyA9ICcwJzsKICB9CiAgKnAg PSAwOwogIHJldHVybiBSZXNCdWY7Cn0Kdm9pZCBDaXJjdWxhclNoaWZ0VGVzdCgpCnsKICB1aW50 MzJfdCB0LCBObiA9ICh1aW50MzJfdCkoMGIxMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAx MFUpOwogIGNoYXIgQnVmWzI1Nl07CiAgcHJpbnRmKCJDaXJjdWxhciBzaGlmdCBsZWZ0OlxuIik7 CiAgZm9yICh0PTA7IHQ8NTsgdCsrKQogIHsKICAgIHByaW50ZigiJXNcbiIsIEdldEJpblN0cihO bixCdWYpKTsgIAogICAgTm4gPSBST0wzMl8xKE5uKTsKICB9CiAgcHJpbnRmKCJDaXJjdWxhciBz aGlmdCByaWdodDpcbiIpOwogIGZvciAodD0wOyB0PDY7IHQrKykKICB7CiAgICBwcmludGYoIiVz XG4iLCBHZXRCaW5TdHIoTm4sQnVmKSk7ICAKICAgIE5uID0gUk9SMzJfMShObik7CiAgfQp9Cgpp bnQgbWFpbigpCnsKICB1aW50MzJfdCBCb2R5TGVuID0gNjQ7CiAgCiAgLy9DaXJjdWxhclNoaWZ0 VGVzdCgpOwogIC8vdWludDMyX3QgVGVzdFNhbXBsZUxlbmd0aCA9IDgxOTI7CiAgdWludDMyX3Qg TnVtSXRlcmF0aW9ucyA9IDEwMDAwMDA7CiAgLy9EMSgpOwogIFRlc3QxKDIsIEJvZHlMZW4pOwog IFRlc3QxKDMsIEJvZHlMZW4pOwogIC8vVGVzdDEoNCwgQm9keUxlbik7CiAgLy9UZXN0MSg1LCBC b2R5TGVuKTsKICAKICAvLyAgZXhpdCgtMSk7CiAgLy9NZW1DcHlCZW5jaG1hcmsxKFRlc3RTYW1w bGVMZW5ndGgsIE51bUl0ZXJhdGlvbnMpOwogIENoZWNrT3B0aW1pemVkVmVyc2lvbigyLCBCb2R5 TGVuKTsKICBDaGVja09wdGltaXplZFZlcnNpb24oMywgQm9keUxlbik7CiAgLy9DaGVja09wdGlt aXplZFZlcnNpb24oNSwgQm9keUxlbik7CiAgCiAgCiAgZG91YmxlIEF2ZXJhZ2UxNkgyLEF2ZXJh Z2U2NEgyLEF2ZXJhZ2UyNTZIMixBdmVyYWdlMTAyNEgyLEF2ZXJhZ2U4MTkySDI7CiAgZG91Ymxl IEF2ZXJhZ2UxNkgzLEF2ZXJhZ2U2NEgzLEF2ZXJhZ2UyNTZIMyxBdmVyYWdlMTAyNEgzLEF2ZXJh Z2U4MTkySDM7CiAgCiAgCiAgLyoKICBkb3VibGUgQXZlcmFnZTE2LEF2ZXJhZ2U2NCxBdmVyYWdl MjU2LEF2ZXJhZ2UxMDI0LEF2ZXJhZ2U4MTkyOwogIEF2ZXJhZ2UxNiA9IEJlbmNobWFyazEoTnVt SnVtcHMsIEJvZHlMZW4sIDE2LCBOdW1JdGVyYXRpb25zKTsKICBBdmVyYWdlNjQgPSBCZW5jaG1h cmsxKE51bUp1bXBzLCBCb2R5TGVuLCA2NCwgTnVtSXRlcmF0aW9ucyk7CiAgQXZlcmFnZTI1NiA9 IEJlbmNobWFyazEoTnVtSnVtcHMsIEJvZHlMZW4sIDI1NiwgTnVtSXRlcmF0aW9ucyk7CiAgQXZl cmFnZTEwMjQgPSBCZW5jaG1hcmsxKE51bUp1bXBzLCBCb2R5TGVuLCAxMDI0LCBOdW1JdGVyYXRp b25zKTsKICBBdmVyYWdlODE5MiA9IEJlbmNobWFyazEoTnVtSnVtcHMsIEJvZHlMZW4sIDgxOTIs IE51bUl0ZXJhdGlvbnMpOwogIHByaW50ZigiXG5cbk5PTi1IQU5ELU9QVElNSVpFRCBWRVJTSU9O IEJFTkNITUFSS1M6XG4iCiAgICAgICAgICIxNiAgICAgICAgICAgICAgICAgIDY0ICAgICAgICAg ICAgICAgICAgMjU2ICAgICAgICAgICAgICAgICAxMDI0ICAgICAgICAgICAgICAgICA4MTkyXG4i CiAgICAgICAgICItLS0tLS0tLS0tLS0tLS0tLS0tIC0tLS0tLS0tLS0tLS0tLS0tLS0gLS0tLS0t LS0tLS0tLS0tLS0tLSAtLS0tLS0tLS0tLS0tLS0tLS0tLSAtLS0tLS0tLS0tLS0tLS0tLS0tLVxu IgogICAgICAgICAiJTE5LjJmICUxOS4yZiAlMTkuMmYgJTE5LjJmICUxOS4yZlxuXG4iLCBBdmVy YWdlMTYsIEF2ZXJhZ2U2NCwgQXZlcmFnZTI1NiwgQXZlcmFnZTEwMjQsIEF2ZXJhZ2U4MTkyKTsK ICAqLwogIEF2ZXJhZ2UxNkgyID0gQmVuY2htYXJrSE9QMigzLCBCb2R5TGVuLCAxNiwgTnVtSXRl cmF0aW9ucyk7CiAgQXZlcmFnZTY0SDIgPSBCZW5jaG1hcmtIT1AyKDMsIEJvZHlMZW4sIDY0LCBO dW1JdGVyYXRpb25zKTsKICBBdmVyYWdlMjU2SDIgPSBCZW5jaG1hcmtIT1AyKDMsIEJvZHlMZW4s IDI1NiwgTnVtSXRlcmF0aW9ucyk7CiAgQXZlcmFnZTEwMjRIMiA9IEJlbmNobWFya0hPUDIoMywg Qm9keUxlbiwgMTAyNCwgTnVtSXRlcmF0aW9ucyk7CiAgQXZlcmFnZTgxOTJIMiA9IEJlbmNobWFy a0hPUDIoMywgQm9keUxlbiwgODE5MiwgTnVtSXRlcmF0aW9ucyk7CiAgCiAgQXZlcmFnZTE2SDMg PSBCZW5jaG1hcmtIT1AzKDMsIEJvZHlMZW4sIDE2LCBOdW1JdGVyYXRpb25zKTsKICBBdmVyYWdl NjRIMyA9IEJlbmNobWFya0hPUDMoMywgQm9keUxlbiwgNjQsIE51bUl0ZXJhdGlvbnMpOwogIEF2 ZXJhZ2UyNTZIMyA9IEJlbmNobWFya0hPUDMoMywgQm9keUxlbiwgMjU2LCBOdW1JdGVyYXRpb25z KTsKICBBdmVyYWdlMTAyNEgzID0gQmVuY2htYXJrSE9QMygzLCBCb2R5TGVuLCAxMDI0LCBOdW1J dGVyYXRpb25zKTsKICBBdmVyYWdlODE5MkgzID0gQmVuY2htYXJrSE9QMygzLCBCb2R5TGVuLCA4 MTkyLCBOdW1JdGVyYXRpb25zKTsKICAKICBwcmludGYoIlxuXG4yLUp1bXBzIEJFTkNITUFSS1Mo UmVhbCBsaWZlIHVzYWdlKTpcbiIKICAgICAgICAgIjE2ICAgICAgICAgICAgICAgICAgNjQgICAg ICAgICAgICAgICAgICAyNTYgICAgICAgICAgICAgICAgIDEwMjQgICAgICAgICAgICAgICAgODE5 MiAgICAgICAgICAgICAgIFxuIgogICAgICAgICAiLS0tLS0tLS0tLS0tLS0tLS0tLSAtLS0tLS0t LS0tLS0tLS0tLS0tIC0tLS0tLS0tLS0tLS0tLS0tLS0gLS0tLS0tLS0tLS0tLS0tLS0tLSAtLS0t LS0tLS0tLS0tLS0tLS0tXG4iCiAgICAgICAgICIlMTkuMmYgJTE5LjJmICUxOS4yZiAlMTkuMmYg JTE5LjJmXG5cbiIsIEF2ZXJhZ2UxNkgyLCBBdmVyYWdlNjRIMiwgQXZlcmFnZTI1NkgyLCBBdmVy YWdlMTAyNEgyLCBBdmVyYWdlODE5MkgyKTsKICBwcmludGYoIlxuXG4zLUp1bXBzIEJFTkNITUFS S1MoUmVhbCBsaWZlIHVzYWdlKTpcbiIKICAgICAgICAgIjE2ICAgICAgICAgICAgICAgICAgNjQg ICAgICAgICAgICAgICAgICAyNTYgICAgICAgICAgICAgICAgIDEwMjQgICAgICAgICAgICAgICAg ODE5MiAgICAgICAgICAgICAgIFxuIgogICAgICAgICAiLS0tLS0tLS0tLS0tLS0tLS0tLSAtLS0t LS0tLS0tLS0tLS0tLS0tIC0tLS0tLS0tLS0tLS0tLS0tLS0gLS0tLS0tLS0tLS0tLS0tLS0tLSAt LS0tLS0tLS0tLS0tLS0tLS0tXG4iCiAgICAgICAgICIlMTkuMmYgJTE5LjJmICUxOS4yZiAlMTku MmYgJTE5LjJmXG5cbiIsIEF2ZXJhZ2UxNkgzLCBBdmVyYWdlNjRIMywgQXZlcmFnZTI1NkgzLCBB dmVyYWdlMTAyNEgzLCBBdmVyYWdlODE5MkgzKTsKICAKICByZXR1cm4gMDsKfQo= --047d7ba97d24e919130524b451b1 Content-Type: application/pdf; name="Hohha_Bildiri.pdf" Content-Disposition: attachment; filename="Hohha_Bildiri.pdf" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ih2u22xs1 JVBERi0xLjQKJcOkw7zDtsOfCjIgMCBvYmoKPDwvTGVuZ3RoIDMgMCBSL0ZpbHRlci9GbGF0ZURl Y29kZT4+CnN0cmVhbQp4nK1cSY8st5G+96+os4FukcEkMxNoJNC1CZibxg+Yg+HTjGXA8ALLB/39 YWyMYG7dTzYe1FWVxSUY6xcRLIW3ePn15Z+XcHkN9e1QxrdyKaXU97/86eV/fnf5+0u84L9f/vyS w9t8iePbdElTrAPynN6gDrv8/DtaAf/VYddvLxm/HOvob/93+eFZpw+Xbz//4T3EJb0HCGl5hfcw hFzfD/KphDFM9GxeXiOO+qifSrgucX4Pt+W1vId7yAvgTPpUv6nvefSDntBaM671xLkxLDG9xxgB x/DfcIspDryDvi6v4zvvVNe7hTt9/sJO7Rng61TXWP747b9eHt9eftrhR2XZtOIHE1gXw8PSUjEj h3RVpK9+lINU0jJuHksdg7TjjnGsfMPTQkzEr5uck+jTE9ap9s1tGfFRiZNslJc4IAMeddjEU4Rl PP264NdxrrK5+XNHJLrSc2UBxhs9vAf8dztnRslv41o5bvUMgOvR0eqZi0llqIx5RRbEB51LZVno qUhOuUU8RE169kw9oSdBVXulJ7JwnpVPuG0MtENGCut6A+2OHMG/EJA59DhMyFh+m482iwENLKdi xlHekAHvEJdvfzmiD4IqD1yGNyQQjelgfELbjFO1TZkxMoOBVDexApPMc/1X5PlIhjaJKn/Q91cy p4m1E+0B8Ii37ts7vX+gtJ4sAfq2yu8VBtk0xgW5SNpSFZX2w6WqqKeoE3JlIM0n2qpolcw48uYP mu72wAkwNaoGoarO4JUibYgLyQOh5mNBJ1H1NuGupSr9DcdUw4fQVnuQFj4WmEnUuFxAPep4wUvx 0LLgbH4/Ezvqh7UavOUQ5+IkGxKKv5MTnTPzy5M5i4eqqlaXrmqCLBGH47cWvj49Ezulj0QC6oZs +79/ewn15deOtP/+8YWCQbn87UIen97/9fL7PcUcyvSWm+EEoh+A/MFEVoh/EvL5SsQdOoURDcKt BrpanY3OpS4B1UsuZO0JT4x7fNDKyAz68BpRryChslXzrRsCKR4MbhIMqLaQ+QtSYagO64OVUtbC /aptXEngC2nSK2kgOp8HCfpDPTU/xxedPURHKiop7hGhkjHJZHLhwMFKyK5rjZUgWQJkibaiEFNk 10ZMbkPD3XGFx/gHNP0hoiGKThzikJuDMknQ3hMSXJAJic6B74O8FuMd8fvGu+mr8HrgcY7TLCta Ju2NiDqkk09sPDo4pfIFbR93rooZg35rA+swfXTAEChoJkNxTjjj259xhX0nDAV2mIg2eujkhyGb K1Bbqpb9fqQ3iVwWHQ3dWNOWGtgHHl/fEdf1tfJADWLqFcyzjBjNA+X57P6K2sHItsFSAbWYIrMn VVaRrVMN8AaE2IG0n2gxgRGtsxNmmFdCnpyety9/uw2Duo8zq0jJNEAkVDmPzJxiQCbX/6osyP+Q 0qtOP5kdWwe1b6yqkjH7Y+PaAXczV4AKQEb11FPCVZ7YRLcwywUJ3rVV0R9+/3QmHMCGBj8oNwfq zFR0h8TBevKwA0ZHGLOAJQxBdLh4heSTQ1uRv4+NJZ97MoC3tLaqublSYYSepikP7cTCI/jhNbhF HIpKqnTOQFnlb+7MnrsHXrKph7hWXnciRsDWe/GmAeN80F0mPIBjlbdYmfLBgdTJg0c+mzVzZGz8 b6Gthq94ZccBg4ZPPlJ9FffMnKWQPTC61OjWuD06Zp/JLQZNEczWfqtsxH0yayK7RDdHoji9D5TG gIICUj4gs+ZpJByIcVI9NL+rZ+zCXeVNCMIlU2do/JWQ11l98WHJ5EFU7aIbDa1mP6IFgw+I8zrs dpoocuocxusnDjHNs2UZHiZ4tddDmtPK6rYI5eLAq8Bo8piOhK+YY2dFsu5vRXGq8g6uZBGrBUS2 B9aoxJFJHVJce/IerYr/V7Hd1a+r9ZmpyJR5y0bYYXCFQjfTFXl6Krhp1ITXBPdA27x64qfOOSSL R8KF61ISYpqTjUYsJa02wmwLUoN0PoJCByxPHCmbKFvISOURFR+04FdMa7wcGo512NCM/cYZ/7gA VlkqQeiymm6KiQfl8daTrrGYeQ08FDQJU2D0Z2sEzZ+Y+Z6TJb26I1h84J8n1kXgCwZchm3G9Z1e JKxxfqVkbLbuxWa+eYPTJkp/tlrcAA6Nutvgtv2hOzAnzrs9W9AvioQOpykSdfQKorbzHAblq9oK GZQ68y04VYemyIGVwxuA2X+EDqc5utux1DhtOBvnZwgp5bTO4Em3gCtudMA7vcdEnqqQVGfD5Lny MVOmH+m7EZ9Q5S5yEYDy/7xw/h/PCgAxjVUTGy2G1W7f6cYtJ7KgwrDXFnBI28UXndibFjkFTMO6 kN3RkLe2F++Ezh4rxCsK5ZLPTArzfVSSE3iKeOrfFBagHc+kPMRNdvkfgsD/NvhtRr5i/Hlkgdk1 GJziossla0iqfFj0X1whCk41ccaI5VZv7EqRS3EiH8VsBIJjZIuJYW5sxTx9bk/h6r3oXY2XPYsO xJcB0M8XW44sXKB2y/AVpphX82CfY4WtKeELFwy2MAPSbi+/OU7kRTOBk9Aet6pUWHhMDLCil6Qr yObRQU7PqsqUdV7piGzccFv7qHLWYkhx2uR9R+W5xIyqL6uqmx1ly+Iqulx0nsgIkQEFsi5WTmvR 1JCZ/K4MNpCSbM+E8xZfkDND0O+Fc3DVowzsG4a2QoKFQedQ+kc+ycAmBrQ1watoqxfI0EdHMn6b KLjA1VJQZlMD0G783QlaGIGQrx65HUmCoh7p2emEG0YqkcqaU3XWiTqEsind1I0GuMZVLUSlWkVB QOvcbsusg9nmsn0Wofr0YF25krpTaTu2FDDQ8QkUB684dXBoO5ifsW2VXPHeHw0vjWCUxqk/6BpM lvUhCMQGB7vWa8JNdpSI0ZUPaXp94rlDgcsx5e792ZkkYc77OSdVL0EPd1SNKBrOJWZpPXtl2nt4 Omh5Ut1CQ4WV6V0OaRn5l3LykKWOIhgR1dInYFLx1bSmJiWotuBTE6VZLXw0szhNaSy3I9/18VnU hbITdSOUUEJcZgWNFG0b9pOH0gtiGMhQ0TWJtPHdgOeHTaIucJLePI2F5Hrz3jHPbZ+TMwzDJieN H9Ru7gDMDC5+jpYycua2RjJ9VV5i7zhjj3MMzWgU9NjaVjv3frkuMfESk64K/TyqIWl+0ZdLLfbj 5KxWdsIR63+bTTmP7YFcV2OYWsCpLzCs69qbbowPmVmzFg+S90B9Ad0h5igs9E77pJ6ZVuVMkpHA 6BN2wFo9qAQ4qag6/sbWr3LZnOHaGHlkOdIEeE/EN184JBgl6uERgERD9Q12qEaN48XYpQ3rauLJ 6cO8qQl4d946Os2HWD1THC9rZuicKnSl6spPUaTJlb77qujUsgitDHw5p412+2hl4qqN655hV4Kz mo0k0zQc+kYEuwFf/NN8T9IZinpUO6bPnQ8Jrbtiq8KgHWryMdINyJ4LrnhweMUEjz+VbSvRy2jk U5Zx7jq5LRreUWFnG6N9hg7QdvlgV6q8Nn9VtRsvLU0C+ZMggIJgtCwRpGuxdaMnhxuHLZRTJ6rG selYwsaOWEkNxg/z+0r/TEgenA+z9RutmAQKliexD+oG+km+VmQVYduc0IoWj9gD+nLZdMaSkjbJ jpRz5fSm2dHiyarr2tsEV6NYhzsZN2vltYYdzXwVpxdXQcGQ6b0bI+qPSm+7CieuXQA54UGO24ZR ruRdm9OedoIiRSCBrl3Q9UFoEgNueS562lbjXEdEFxsEUWU17cbcqbj4sWo8mF8fN379NIxXbLeF xlhZd7jdujAtpkfJAOPA17m6OxI9ed3QxsP6UfQBk8jJjOa6WAHeW2Tpp/hetb/n4lce5vdOW9ff 3c+VA6YNwDntCrK2Chq3mIXODDSzcAGlA/itVWdqreenm0hY0qf0eTyjOI4bkJomuQ1ijVczLsZX c9OrlkjOe4o3z9bNaOrgAK/IAitEg4XxuWl/Ywpfe+jh6u7OJ0cNeduEWJXZcDPRPYBD+jj20gAZ yCk87EsJWA7e4vzcZvuQ3ILY0WW9oUupMNh3opsSaj5EiY4PPm8KssMWHnWp37pYduOW3bYb0xry Ow0Kf0PgykBGEXt1omeZ0wQbWEFGED2TzKC31L7CDrkchUGsGeefUthdiXECSJ9icT+09R+t1O47 fbn562NujGGDMdkv7EaOAitHtqO9FKazeTXXwvCh6vxynylzFPDhvHXsmReHT0ac3Jmet5DDOyW9 GXL3RbJjS/R0u6KaxZjRilLmSltpZaiRWcrZrnq14o2Aq54InyTltndpraPRsfbsvsq4fzWMxYZO UpR41yQdMsqa0/qrCbBDjMK30yZJ2QCCZrCjnXS7e0uURdfubfxItuOaochziSojSdguH/ZpQkOA xU+opPTlY3UQ6i7q4NBSaLACAA+C01wBhj1M2CJFEgyKr9Hq9q3gDUFqeSnZQO0KrgBNEkwsa7UE g68JdVnWFRd0o3uvRV/DZjEJ0qPii+6amGf0YW4PVUeTr+CZ4eaWDJVtu/Lwfu3dmwtHWt8ycSto ZvwU8KNGWgS59Wa6sUuaLsVm1AJsOzmIKflM187cSUuPaz7CmbxtGe0LO1kUfYgWqpsq5krmVoL+ N648a03YJQA0obss2d0Jkrz72C/IaYdtR8SXSK6tcYSB6CnX95M/xPoaad+Cqi9pXqav6QSNxMm5 n9zVBq47beXcI562zpoIEF/MXjgd/hpImJO2TQYl5e507rCpXaTJWYLFKxxdgj3nXwT094MK6/Fr EQdA466ADQFqwpZgz3399xCnyHkg7TnCA9Z25bcOeEy+pIlVyn2sk6ANOEbqYNdkrCdM7hBv1fFt U1d0crchPrPjCNv6fnZNEb9W59tEgUGUEPHiKizsuHIQX0ajN648rdTVodBh7duNN30B3NeLSu+D e2I1lwtNmueMCmGbFX+qFXt3DSeuk5rYtXqTrZhN6gL+JgE9mVpR0VULup95tPqNV7zPvcrp0eO0 iYEHccgSDanrwNybdBKThrkVfLqWZpXGTgBN0Watc0qFJfxdjxaT8A60LeXKclQAVVmdH38cNyk3 olSu5XXi7q/A+WuMrS7oI+4Xo08seXu/5oOOehZkCLRZ3XD9Qwq71NAsKTt0+bFoeTF+L16xeV8X sWIkK3RainXOnDxs82ywwqkuGKm/sMZB2fWR/Mh1wtvMFQ91dejiC1lmuvbzpVmoe9OdHWWZKzjf VrOc3/Ptg+kM1QuLBtg2AQ5una4Ln9XCRvHBo2bjVG1N7iGZFliJv1MqKm2NUo/C4VLqSwwx2kX/ 6dBvf5ZRyilT3CJS56fsd0JfKAao3Qzr3nHTKy0GcHdWM8762VUk2IG7J9tksFUwkjY1vhPEwSdo purOBs3s9CFOApVVZ5vIrtqDXLUpjxttacD/ZUKs0KoFUf5ZIDVf4kkmloa0e4zqNivjDn5RyEcP 0waY8u1UuUSAdEsmChhecz2hBqvA5RiQgEyvaREN2P7ESvrSzpNBtJl9QqI5Tbc3IVkInhouL5ih fqWhySefyxarcDwarHIvf9ntSkU6jqqGX++/T2YJ2KYMroDe7vzIj574J1F2sYDxrDY8B1qgVatc nL/SpZyK7A+VfQCWeLBQvdavOH2a7095+wOMDUZtjlGLuOaz97Bf1+A1+7KbhCc/Sb7z6iCXQFwt fmy3+sC6E+qHrt20z439lCdj2kE/Hdq0gmORlpZP262iZWUMDxmNcitaaIgMuprbYOewrg7pmgL0 G/++5CJaTRz2V8u0GfGJLy07aa7ELjJwUeRp7i5sr8sBrYrf9Z82EWavAetaoZQi5rDC/m7N7qc1 Lti5AK3SOyLklBk5bO/Iu8KYzwe6RI34LsUPKZPSq91ComqK+8YVt2zV7/t1bl1I6jOqQQbRP6S6 1ErFX7j4xCxI08EP/7UCtvsrnRVlvnzpJO1LpH220OZrWkRDfHAwy0jBarFcXtu/8dFswXJ2/t89 SP34E6gxwFDZ4WGmd74TdsoPZ070/0ha//g/jaehnbz9KiO6LatG6iq3cfeM+jSxXWPq7+zqL8Je G5LrPvbX5cTtpJbBeLjA4Qy2rJaB7nJAI6Xl8XPb1Ln/vmuausD20+Wflx8eP/4+X/78r8sP334Z Lvd/XH56+X/9jADHCmVuZHN0cmVhbQplbmRvYmoKCjMgMCBvYmoKNDYxNQplbmRvYmoKCjQgMCBv YmoKPDwvVHlwZS9YT2JqZWN0Ci9TdWJ0eXBlL0Zvcm0KL0JCb3hbIC05MCAzMzIgNTU4IDMzMi4x IF0KL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCL0sgdHJ1ZT4+Ci9MZW5ndGgg MjUKL0ZpbHRlci9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeJwrVDBQMATionQupxAu1xCuQC4AKcYE BAplbmRzdHJlYW0KZW5kb2JqCgo1IDAgb2JqCjw8L0NBIDAuNQogICAvY2EgMC41Cj4+CmVuZG9i agoKNyAwIG9iago8PC9MZW5ndGggOCAwIFIvRmlsdGVyL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnic tVzLjiw5bt3fr8j1AFWtd0QAhQQqK6sMeNfwBbwwvLN7AC9mMO2Ff9+S+BApKZRZ1zAaM1k3M0Ih USJ5eEiGebWX//nxj4u5vJj8Z0jba7qklPLff/7nj3/9y+VvP+yl/PfnX39E83pc7Pa6X/xu8wXx 8K8uX3b54y91hPJfvuz280e0l2RsHunnf1x++3IXay4///i3N/N53d5sur64N/N+ffEuvRlXPo83 a0y6+jdzrx/2lr/1hn81Eb6GWz/r/+/W9YOYgFeUi52DC/l5efQdr6OHOvj6Lq85+ptu5f9gqAOf n1fxdX1Jb/Z+/fef//zj8+eP30cJxKNIVEsgP1HO0X5enXmzH3VwUz4PV2e3H72wdljmdry5o9wZ rpuBQcxep4ijtMHlt7Ao+LvO3JWl5enXJ8G4Wci4XnrYfi6i3fFtVTRuYynhziwEs+2vcRQMzQg3 yOFKnbOwQJCYyx8vHuZ3nIjBOx7B8ca3YdUWmC8a2sWrNUJggUfJh/PpUWyEjSxyWMkgbb0EImqA s2UeMBgPVdddRq8ypqnZMwk4mBEuJn7jVLw4VChX1nine1K+yecvPa7fHG/+frUODqcL4h4+RovV x/ga+vV/Xn1dSJnHzci5tfnn3+Qad60yzlXJfbYFzfU436dOPqghyrAcq3KZNU5rXLQ7DDeXJkym fLp3qUE4HXiEtEigNxGnvBBW8NnuDpa0V7oyY1iRtWpJ7lY1JU/OOpJyqKu8oU21bTVZZn4r3yQe yvirFKG9lR1PYkUWj2O5WG2BWCdeHcoQoObWtdnCkXe+PsDVyXUTfbFezOi+ti/evfrF6crDWY/P JLEkOm5PyCiCLhww/1R00IWiTPIk2p1P2M4nCNb/lg/SQQf64IOSl7+L82oXjihrevnGLaXgTPbU WgpoWtpo9UGxLBTOUt5ZWyakjVuzvrHsXFnVqGrGoYZspwoCt6IpK2Ogs++MHF0INgBmG62rDjF/ t1iyOTIg6TTlDgN0o8mjGemKKNUKHVI253QZzirUc5OEBd0nB9YXPTqfaji218EDvF+zWu3o2cjt 0WHJ/8xmC350vs4B5P7OyEivqk0TFNY4/+m/jL2GPE2LeyEBCOsA7wUchnJJMEVvAZPEEViR51ut eE8jHIq8SPBXe/Z4u7AN+TNYPFV49OmE0DXZPntzrfgJMeTOx7xYs9C8er0NPVgxltl3BqOx3buw fQU/JGH7HBkNvKMejGwX4BFVJxfL38KAh9HlZ2+XWA9nB2yOBVifTDYrEiLdTUM9dcD67ZdQRB6B 1Lmapr0esX2JW0IaLCticzqkAc9UfnhAAxg2sG4uEGoPG8g4ZOtpDm0tlOu/qbPZSyNsjh8Aotwa upnIa7GuaM8wKbtomM/RNApVXgKg6gLJrAmg72AyEmMiYCCwWpy2y37kVqQ09YFVPwDWeMRaeCMo dvZCfrVEfww4Am/MTwjx4B2B52rXODHpAYOAuomdoxiA6x2vw+vdjX0Pfx3JCwX1dblaqkRc65nb T6Cl81WOuwjzurAOPCvjKY8e3u+HRqcOccTOIDtY1y41wsHeyVZoR57HTnzDoAD1JO8zfV0t3KbB 31vHq5HOwMOQGoD2i8fz4MOBsE3Ok+Hli0dNLtdJ7Yu9sp7M3G5HVryQwQq7w1jW8UeW3fXnf01v 2V3e4tl6AY8hQMxLEFNzzxg3E0fg+CRHgK7yBbVYuGaB/IvY6yF85+stgUOT7yrusI7t0GPX3zsm QDzIBNw+NA5CSfeJ6/CrmMwffkAkZFfyzXgcyucJaEBrUK4oxh5C4ioBI1Dri0upjeSGb9DCUUBL js6hNSgB6P8di/h8gnqgiFQBjCSA8mkIyTvpDc7/OOSNhKiRdzIHX8SzvjGS4Ccdrl3WYjg0++QT xdZ24Zucy4MwyW9mQCSoJqf43W6InvaDdqceLjifFo9A/VXA0rrLFg1F+1ERdKM9UqPd+yEA9YgZ bT0lI6KWlRTiMcDS5hWJLJz7xPyPKEmicC464QY9jxmym8vXbSUczRjWNtqqwk44aCJOQ9tAYXJA tFvlEBprNhKfS57Sh22APioghzNMFq3apargIkqlGAkjweohrT62xvGhd5UGjRA0N4P1gFapKBWH uB5vveosFugH4N1iQQwa7NahHK1lBmhF16jmGQHjreCWZ8HwPuJAj+SJt23nqiITr21RXTK2A2Ys 5CnT1BaLdmHEQVNkUj7R6hwMtZr/6oweGzRim7SulwOC0GZmDcWRlrqvtqOovm00+Do60JawOz4L 6Vg3cmpiFrFZj7IZAX1uMId62IgMGFfBHPAfvuBZ5BPLGEXxbdV8VzX/xaeNf7SCWllof5nVwTdN eLel7Td2QDrVem6cidklMczEA/JY52oowIvU7ihWwnC7cW1whwit/A38GgMdAWBTi73IHhv8A67v ABNYJLtCfm4/RvD8aPrMahImtPi9COnQkAaioRgWNZ7d6jMlznf1sPmC+YVD3qHkTkRQmE1FO8Ry 0it36LZ9pNBO3WpecSCmJhwnFPl+mo5jhOiiDkDKobMupjZ0Hx1tg8YDaFysLKWRcSPSAkBH23AY 32gXBKpQ6HGP9H6JEMNWnfiZqCHCo9DQqXMTYNoc1d+7mBOMsDAEDCFozEOACDAlCwHEOCCd54BG hjloaQ6ZqAvty5sL+bjFZsJFhlRcB7Lye35oOGVHbSrUaA4GdDxYqNyr3Ra5ErsVVD9bJjN07Krb glqOy8topqdqnojAXfBjyhuAK6Jyayg1cDQWcjza2f+166s9VmRTEhGViCflPeemi1xrvUyQGssI 4wSWLUThh/Dq65rn91H3Pzs89HeFY6UoqDIeYrKTuIszTW6MiiVrG8C0NPA6oFROJ7knCRs9/kOM tBCNMyPcdt1qZBJWpo1EVo883WBTaVKa2eGDgvG0b44CqysoV47ARSRbEbSqBHBhHe01kSsQpm8Z bDizD8CLfSTByy6PQVFYm6pM2KLf5YQa7dOpOxoKJZauST+fyG7HXqc97pf8rT22EaZPeOdEG9AM l/8otvvRQUcnGidRxFWga7ouVBnT3V5C83Ithrvx4Lxae3SzqoXHadgQzlA8Zc4WwtnjjNLsjF3F pBSOUnxSdVrWuXBKyQjMquKO0egEvNWKvLqQxx1zVnAEnbTY+IAm4acyugtJbGHE6wgo2wMw3LpR pM5ZFtp9OlnrA6+QM02RUy2JXJjMGOjYaWfEGHJcvU2slFz4atnJDZgN0ysmCloRPt00CKrwX4A6 GT+KooR5kn8xtWgHoBwKsDnJhkEyDrOqwvk4He0pP2MFBHGUJWfzrEheXR+B4gfoIGs5BA0lc6yy LoAg+FIx/TEiHZhKxoEiV1MnGFI7OlZjxLVGMFobk1NjxCgA3Hhem3xDbDrR6QE+zq3y9tbtk6K+ DhA0tAZBLhDfO9Lcezg0V29LtdM2h50f5T7X7jPO44nSlSLWNXe1o7TqDTCnwCVci6XZNAKTj+/E vw4pDrs1Tx3zfyMHyqxt2Z0PtE0i5VmOLdJIdhux3tZ+6gp7PP0p1Vx6/5UATL98AYBbuZCDoIbI F8vFq+R8KMIPqHhB12Nlt/DCBX6OEXfJIiJxECz7qOJGOyQqhxU5hnsfxqlqomct7uFHOPJtHsSj 7pUcIiV6bwoev3hMmJdLCsC1t5HPmAYeJLFWk+iTYF2DQ2u+Al27HTCopCDduFm6KkZSN+JQK/Ll EIgaLJlz8iaShlDjGQTRNNE+EEcyMQ41IGFVIbWZEUbUmGyUucTYLSVXGQ0SeBzcl5+UBwK/y2ci sDIEqHjx5QwXztCnlq8dYJNQxUqbRyfOTzaKtyV+ivsIJM+C39mxw8kXJqqrVRwZbKkXZQOj4XuF cF6IOXONVJkg/ua5qAI3tttg6wQuUMHJMtO9jSyfrBRgDlhTbD2zn+VeJSdjtzuTG/tMDaisdv+W FrQHky/l/EDoTz+g/lXG74QHBGXCk4fflHq0MNhXmnm4keqjN3ANTImEmMAXwghIVMIcr6vJ83vN 6ZWNYICjtL7H0zRDdj/WhRV+c2EEMTNkgRVk6E3UziqPJzT0Lstez4snRNSD0z/taDCSDE9F5qJo trlezUOcrN3lg++nvSllo5XME0YOwnECKxoGjgLEDySWmwimnZVaZJq62+FI1yxFX3agjYkSHVuE Ku3lemedKJWEHVZC1VG7jnprRBflNk/iCHsWR+TYxLQIJLIwNwVip5G3GPsXsklrocy6ULAMEg6D 3XvVVmGucPiQdW+xXrmMejTcRF8VWnCnANJ5xQLiSdz6gjU8T+vVDv0mw4Sp8mQbJtwqdLYh2et2 8RPOZFM+O3bmwaF9KHfIXCd6Pwrm1MhZmpueRpl+CxigBNtQOfZaFLPmk1rCYqxSTgXQT+Coqsa1 FHnZHZx6S5zpjOWOeIKuQ9Gspz1rA5kwt+KU3SQseRxkU8FlATnhQQUAqDFH9uH/QT8nXRxUkIKG uNTMUf1LwlNVyv9O1GnDLEy5hBLZMmm/ITSpQ3yzNfAcceBqJt0Y36n7fPFUNuQaC40QURJDH13F CcZTBRONpceQSxQDm6AqRYezPrRPJt2AucqyoxwmLRoq+6HQ00TUHjfJ7af7zDVwBEBVkDowPjl8 6G6aFvew2dohsyACL5VdOKv0Xopl2g4iqsHdrW4Vltx4TiPyN/bolYMUQ960PDgt6Jg1HdStNqIm qcUbFDytVzhp/6CKk6eSjS8InbGps3FsANRabyYVTAHCEHy9sHXo0zUIT/r2WztadRR6PEcceQdw lytYeLD+Wf8H77DC+sJnvotgQ5t3cJIjp/dqc6Qdy2c4jC2fyWy7nsrYw1E6j1TEcheka3zCuA8c EDcHIMEjYZUeO3zof/eevQVkQM9/d7UPOzuU77R8WpTctQObdmSst781X1i2e6bkRmKLE2pfIv7t KivzYR2m7BPmlvZrrcb6tLZecPpYb0vubNrzEVsUXrNhsr+TSxWOo1mSdvBqX8pBF5T9rOUK7R5I 4ie2DWxn57VeHQh5hIHOmzvkqF1ReP474mGM26Gj/DCEdzP2ISLfXG9/3mkXJYpIdMeBxdbRYeVH e2T/QBjfbPjoiyw9gjdk5PhcE58idFCkxqofIgKwcXkDsa2zaYrbE6R15dAEh810g6xwOWf2UBCT tg2jAhAMzQWyuEPugXIQRBwAg1kxOkH01Pe1TMsH9Maq6gGV6xDuxqJI6vN1t6dNTvx0xg0+MDnT ho53freA7IfdscoecyqALVRlfQTrnf93734hLH6Iiv3tUJ6zUr3nFXJyuGdx93rlk/aOb4HthNxs 8s8ecETZmFws90HlV/Ltm0na3XU9EEM0zPy5a/55vfZJV8dQteJ1q3uv37Jvk/a3IZSO7A1bu1jB BEr1MoXJ5QibVrgR7pkHbMasaQOZNxf7AIb6pzHRpgpsWxKJSvfNqq6pB9OikH1KyXC04rlwPCrP d3/geh7n7FAgkx6OZwoby5oSLj3Z59aUEAknK9e0fWNJRS8waky2M76TXeIJr0UwdHmAWTbYXq2s SFc9QaeUnp7VAbM2Niij7VV6X+HFmyjWLdaTqKAgqu7UlyQg6986nobNPxc+731KrjNFa8lMWkG6 9LysCtXl3vK9Ilxs9TztpIIuUYI1TZJsk+hc2kE3jGjbiJ1Vf2hCJh0gT4TH2zQ6pt41yRjw+y1Q WsDyw9s1DimswbEbmTyQR+OpSEO0drRIA9qq62SuNawwNXPo6hMCFtYmOHEZ+URTHaMD3w23ncYZ 5SVgs36SGmdQwW7pdtu51rxVA8gS1Wt7OcOaT7Sxjao96Ph+BhlerAU37QF5tvtXtmvpog4BLQCJ chtZKwtpBqQdfY/FIJVpY6aD6yYa/2bT5LpZl/p69YvGDyS7bvwqEp0Vpil9KzjiYlE/pBTaePJF Ht9qIMNjFzprRgoLijx6wweqNWshCfcah2MCth1TSZNTrYIuHxWNNM09t0tVMyAX59ZamUpsld2Q kWZgcXKMQvmMWtMmxdqGXq930kpRuZzGKqsqijsSa+3tAPVscjE5JT/hQEbpN529ESB+bz9OK1Gd SJiO9dhdGvVxOSMuddK7oRL0W0s9CaVFBEBvcBE5E8lpQDe2vnsWTzC3LXqZpbvRrynjQfdp/C4y T13N6AOSZezdeNrfq8LH1E79GStxprccPlECtJbOoBcVAtnUW/rY3bJlaD82koF9jzRlpz1FKJJJ z4aAjSCdSUsa94nN35OIP+AFZ+0KI96Y1MDJceA1UqpPbDtLlqyXPWnW+EXsx1l0+1TDz8hWycoZ 0zXLDA2Stz4P9qjFYymGWY+Gjgnc+LYu+GJZc4ujtyaHhtcyVGI201fExjyxR6RWFB11IaItIYzn B/CmaGVPA9Rf8UL6GQqY60i1twWudEfNNr2JB0J6RTy1MtYllQbbUNMxwGh/GHCSsfQoloHTQ9cj Gh5YKpX7RqEAct0WSeTsq920b6LgUkfvWijN2J/lzQsPXqbWF2/Q2zzMU91mfELNc91m0kSw5hgN lJ6mR0+aKAYkRclw2bB5hq5jw1ddqUhofUTVS7e+Iv2CT5VwdEhHNTCW2gPuelhsPnk4xfO+gkcO cNba8d16gMoiolFOxGvmv5L8pndXCTnnJP2/yDIOQ+q6mcfE6Kxvo0LUjY1y+Kqv1enNWZeXrfot X9sz8OcOd9DBSejQt/pZNDjW/LlYL7/2hzqYHgVxs/6M/mUlRDTsSFfv29Ehkc4d9Vss3oKxU7Hj 1vNEsKtD/e6+tRu697+sFzbpzrAdMdXoRS5P5tfDoMGCd0VMC9LUJY9tmnwnhmqwMe37kxeOkKzX Cx66MaiYeGK5dGGkH1Nt9aW83PsTqLdK0xFi5wNZuNCfDQKe80pxeR9gPcEoNXZbh39rQZy3ZECg 2aKt1EKE7H2FduIrmoA/Oiv7mAAl23jdofr0jA+Kdc5bc7utfT/fa/cF2PapLHW2Xln4nhji6i+/ VUb0jB+YtYloY6kxApeVuNYMHADkdleLF5TL1KI4GJKOHuJA9aRpXNFeU37yHqJVuU+b3eoNYiCj SUOJesEBve3sXGbtwrXMRraw3dkIdtMeq5YFaVWMr1uJoGi8q6y/MTzkdC9AaWjkdaXb2HIiTMUX vvgDKmIkj+OojpE34Uu4EzD5RA2OCRtOw4gcVIupTzJQ26NsTWhheE+4PCh6Gov95iXiDiVvjy5J Tl2Ah+78RC2/1YKBjnvBtwoaceeDNwHMWH2qkDm4a1dMZc4qPmLmx8aT2sOvG9F12FEOBL1ygfo/ S0BBO0LwaadXJ6urb6a5RNmBT2+tC8cb1WTR+5cnPk1e3lnUB5zayB7Cm1hb/VQGGlRAIJNpCuH/ IuUgCNFfIhzeOla150/guLEEfr/84/Lb5z/9S17pX//78tvPP4/L/e+X33/8L4T+u64KZW5kc3Ry ZWFtCmVuZG9iagoKOCAwIG9iago1NTgxCmVuZG9iagoKOSAwIG9iago8PC9UeXBlL1hPYmplY3QK L1N1YnR5cGUvRm9ybQovQkJveFsgLTkwIDMzMiA1NTggMzMyLjEgXQovR3JvdXA8PC9TL1RyYW5z cGFyZW5jeS9DUy9EZXZpY2VSR0IvSyB0cnVlPj4KL0xlbmd0aCAyNQovRmlsdGVyL0ZsYXRlRGVj b2RlCj4+CnN0cmVhbQp4nCtUMFAwBOKidC6nEC7XEK5ALgApxgQECmVuZHN0cmVhbQplbmRvYmoK CjEwIDAgb2JqCjw8L0NBIDAuNQogICAvY2EgMC41Cj4+CmVuZG9iagoKMTIgMCBvYmoKPDwvTGVu Z3RoIDEzIDAgUi9GaWx0ZXIvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJytPMluLLmR9/cVdTYgdZJM kpmAIEBVJQ0wt4YfMIeBbzNtwAcbbh/m94eMnUstKTca/aqUxSQZwdgXLq/u9H8//nlaTi9L+bqm /JpOKaXy/ff//fFffzr9/Yc71f9+/+uPuLzuJ5dft1PYXBkQ9/Dqy7DTb3+CGep/Zdj554/oTmlx Zaaf/3P65cuf3HL6+dt/v7n9/cW/LR/v4W05139S+cdFl+pjdyn/LuVn//7itv3Nu3e3vPngvt5f 0huOMa9+1NEJR+97mQUmg9/cuc7ldi+/er98wvvn+nfSNcKymZnr/uxry1p+zLxt3Oyifyzb+19+ /uePz58/fh3hj3vFZwt/WU4x4D7f/YJweNyRXxhq3K3zsisPj5znt9YKiX1vucJMzszk3Ua/0RO3 wHtlxq2A3f3oc/lBsA1L+tWsFstr4R68eXuNPbzpnc/sag8QZm9P9IVOxRyWPZgr/EIDyiHAW5sb RyJx4GFvFSU6r0UmHp/sxhHdyajJxJvdAj+6g4+U59QPS0cmYtxRiLh+CD34DT1MwJQ3V8ALn++c ZMuoJKP9jj/SK7EQBZ7LtnzBHP7jHngxvq49gL7hz/LPlwBZ0QbEHohEg9srMQdkgfQmnFG/w44W grpQZCBKD4twOgmNG6xJqCKRkIB2yyxE7oXz3eoZcOUs2UxYK9Zl03fQsIYiEzuqv8QFRFfd+Ft0 7y/5Lfp3X7ZSxVLoZ3/xgbjWK3TAeCASG3aBJ8HL8IUZtX56fX6MiDxQt2f01PfXIg9UwOCMcJDn e9gI/jX0RFEJi4iyyqy6ERav155e6i7crgMsdMSiIMiiged8Ay6WG82EUYWAUzkPhCvqxCuR+TMe QRmQ7sHtl6IUOyo440GCPDW6SQlTaPdlw4W3nc69qiUQS74RWgVOUk5lZAe1nWPB5XYimDzhlYXg uuJc9KLRod22eAO5ASjew8myF+OgxQnr0wVkUSKeTqL1lPkR7Bhi+X3zMm7d3kV4VyWGT/lXq1zx 65cQOCHKPADxEpJOXk4MV21nBcVYdn4P2HXPr724x21eC9nH9jyI3SJpk7ix0ilbTETl8NAIsuZd oMbyfpKhqOvtjAUYwONaGE5NrV2I+YH2Wrc0Wi9lEaKkaj945uvyxQND1j3UHRCXsXj9MMJ8oSHe 9xKJVa4X3gYGtQOrmVBhRs1FJAyreNQx8uQGYGWnhSbXfWHIYmXbelbXd5frKg7+2eq/t+bwaYKd ql9+/k3Gv7qQfayfZTFXP9OSN4PevLJx7FRgvLsqwS8VjVVXAAHWics/a9VewJSe1Gg5WtCwVY14 +iOQpuW/o5AdGhcywaoD98KQuJJM++ITjyx7EdWss7lFN1Bn0YkLDLD1KwyI8NeKtGDx+RA/KXTY MRvBjbtc/np6zrQXNS2zCklX+bKhTH16qm19NRsMwu4OsLGECu9O2CpYWdeC31w/9zeQ6hl1fkEJ 4fXCn2VQfZMHX3HCzwW001oNvUxDroR5GMcPv45AUZEcHVvsCsW5rAazr2JN0dFX78EVYyY6XDN6 3eNW/r+Uc0E7K3ovI9yK0DpXGNYt5BAARRZE7TAeYW/mjezivQmS4jHgws6GmQUuooAPBq6CYDCe YHFHhwQsxEsDYN2gL3xXzxoHwUP67YIs0c9avQ1+WjBC2OFjdrrE2SWXZdKLRYfbjiHDb2ysB/VG yoIgXB1uAQ/iiz6LiVr3d4Btt1CoyaykirAaunWyj8LCpDRQHaEFnMhQW0npwudaNEXdW2PHs0dR 2Sqj9lvj3hjL9YWVLIb6m69k9sKuBmmo6uGgEXMIiy6NVp4GFsSwQAUmJlv7Y+tQFp4g4xS+XHuz vDdq2cOCV7151ZNOj4VLGwfWhAsq8sm9D8cAX+Jg1q9FTXo2Btl6kQ0TIjoPfhP3GTR4Y0/s1ra1 5ubeEYAx3nzV+9bBv7aGMK3iDQHQ91jRJnbviPfO9X2EoLCHwfxjq+86mF8dSQPdruTchNGwF+8w YLzKOGr1ydnOt4Eeti9kXqG17o09yeYX/kWWXP0edU8ePdavzj6/HsPS5gePoNIABfoKx4MUiLuq Nib25qG6VY1BTCPXXXjf+AMU5WjjatduuBzU0ljsyeAqWv/tIPh5GQKiQKESreqjoyY+ReGp6gsr yzX+O/qwiccFc2DMnjILSYWElh4+Ap9C/oqWYLfJeHSPLXWhYQ//iv1/CD9xH1yOxdCs3wy0uBgd ZPF11oYLJsRcn15YZFQgivwMpDi6ADB/J4gkForIiECoHqJHEFc6aHWFNd+IkxrKs/55IGZHLw8i GuSc1ieNdxTIhe7gEqYV5AWZgUVQ49jj8hRmQpGUzXQsXyZ+OzrLiD4mOQwbtVE2EMMSmTuEv9Az EQYFLAVY+JU8HUHtPKsKR+Rcn7DDrIzfabFPmceZeZJ1PDexZZw3YwwBOYrROU/SbQ0Vd0DBy4P4 5SEs+XW0w6xUs2tdSfFwTJGYqEOfHWISORRtcnnUbY0musmri4ZEml2Qon9v5fj2h9GR80PkNobq ZCo3caJhlq8QAzTtjUIxRixKd8L6pkFYsU+7mJUugLJubTWbNY+HSQ+BvrjBngNDNs/ixQsqBtEB geIwojGqPCHTLuQ2g2VCuxjSR+dHT5LC+2SzzV9XqZXNKpsw63hSBqdoJxzT1H7bB0P/sW0uapzB Cm2CJkBklhJXlP9ZLRYSCleTonnClK/qLMSkS7SjP+S4WKcdQkTephYbB189WU9erCeV/E2Qu1HB bFdGSQAllIGQtVVAibXVdqHTxkxkMUVo8VVcy/bh80d2lD5SGs19C4lwBmbSLkbuLyItHqZELemz twKfRliYRKfjbPjS6mU00gxLDIFWL2LVbFLgcSHZrR/zmX2MYxyZNxe6vamUQYPiSwwaH5t9coo+ c+rGUS4BnkTjOALHlcf6M61uEx1BjW87e1IGnKXh/z3149fA3oCGZC4mRrRTkAjyMnX5FeNrzl2d g0TitsuIGvtbAlc1yHufJCOKEduNx7hd0b0UfoMJ+klrrNJzlBix721083IM4uD7eBztYueoUwEt YBwgo0MfOMr2QujY9zZy531A4wp/yujP62vl/OW9iPqgUF106/JJkPnu3S+OWFIglDD02e3MxHHr vGWSQ7jwyxh6DRx69bg1CY1WH0bCpCHiXgMEt1BqQDotZnlOEUiGEGeVqKsTlNm5bIAypMXORaTV jKZKlqMKZdnGqOynNfGU2C7moAEAirJWyQBfq01UZV5G+6McNT0O7XQVGWhi0EhGTzRHfSEMw5Gv Gv4sS+y6xAV4BlY45vW5PY8R2ETB342hM5FjR5F9+KypBU8Od5HHAX8JxAtlHiZmitM3hywzBbCa akqJ4vChfKkWiMKEaHCUaqhvcAT6ELBbZPspmEiHl0i2RvdhXdgG7KiS6kvGk0Ka7PeWvPxoxFPA 4Ln50aLT0pFQjyGkq011kAV5FOS8vg4ZobP/MOISziKaU7UZAWI4eH4uf1360f4MpnOBNxPDO2J4 nKtmZprZZ9JEDjbeYAJQAnWZY6EblzwbRErdrdLaJiIIqTcQwkkD5YRA5NygCEVEzl5/LJK6HB0c vDxPmnGq6yz+YKak2K6vvZryNfX4iGcM6XFyjk6DZGjzd8PQa5DnzM7vLNunHN1MjPR6JY13JCda wQ37YIUc4NRA4rcWVE1w4klfYr0VW6QeAneo+avFvuscLGyah/6CMktTVfQ+Uc7BA/YbG6S3SPUK WU4iwwhYNhmdi9H6xQAxiUq2OWJe9NWKwvItyRNNiC6rv9aFwnwh0XkiQ8DtOwatS7MUr2ZByUhu rDxcTijLbMkKyBqlQTi9ay0Rv2R5XgsXPCV24W9NaK6Nkmbk2UmR5IoyZtq7QBzKJxmBSULZ9yHU LD1iNBmLjhGKFk8ZWaiVvZ+SxQoyGov51UKweThQg20z+SC32umIsVax2Rvhecwa2cNojETLUaHh Uaj6e8lUm5BrsPRTqzEWOcdsUJHplDIEQkGzWGTtavNdxOqpsi17XQXk3kXs9GMO1uZGS5Mk14eo +NB6E1pqgB5lRi+Qcf8F7k/xIhfVosbV4MdpFzXNvJ6Mck77rA7EZf9oUtCPR1CQl8EmYU76MKzn GxcDcVQOALeb0JSAA5PSgBfaVXpkdZMpl26ZG6JKQr8mDkdmOxp0iNtgfrI9qJwIRv7Ts+ZU9KTO y1VfIR+r+mLbQou+Lj6RR0Wffjmyq9mcRX4lLpJC3rlIERmcbdKvxdULsvRQveWRCBP/omWopuDM FJjB95C9zCiFYi60RWbsPO7t68dEeIhsdSrsSxVMaLcUWV192cVTdVrVPuDJVULg2jUqsAPVsycZ CUU/4Fkg4qRG7kK/9+OAhbBEPeh6TfXci89mgc+yy01OhY4Lj+WY8e1XNmgUCzsdIJymHpL7oE8M fEmOsW4dz/xKpYfJANRsjk40EUVAIWEsWPh8D0ptCcP8RE5YzZRqq4FxdIkCjhisvhB7mDcWSfzX ZJCK4xMon7FK5atUhdtsFqYLN8r49ikOv2oWq8mNzcusu8qONrFVPeoLHQF/7bLU/nBxAeJl1nB0 p+WEg8c2UUDZ7y5rIfUZV07ccGBWchWMmVm1MsiCMB3YdG/Qr7zopOLkKEImHUk27bnMq/IntQM2 iVG3FKmHZe1ay6KE4Clcv+4306nRDHkinerOgqyjaBgbkUyuwhbSNFscK84DkjIVmft9rDob02+x fUFSiiMBSucSbAgK/6leBV4MkOMvRBy/gYFJr9L0VLjY49mTAPtY86LP4BLCyIeihwTDpNEICh+k hq5JqvfiqBbMUA3VLnk3H6gacmg1uZ2I2inBtq+7NBLUIynTJpm+OdgDuWkCddJFNMpdd7aIxnIk bXrKHU99koXNeR3MgGUDGlRtEIqcbUkJXG4kZVSbmWidVqmyRHNZJ+RGJcxcqyxuq4/8dwTdpP3o Zu3bYnKGwdRQNdlAizzLql/UgHGjXWfsUR27Rp+BR1uH1FBe1ZRi06OuHsSkkM4EB/YJmXipBg0O vFd2A3FljhR7NnI8+z5JJ7rVIgJQTHuCLlJgYnuheXtySJEMco8tSGAsPE09aOBIsQT5FonFPhAz 1HdlLyto+Sjwc1d0q4aMNEZBjJ3XvY+HSSvRdwCCqivbwKfEW748ZC4m+I1mGvG/GQ7wpr6xNVJg F6P4eIAD7fdpGiNRUnWSW7XHYIoEqhMOvrGjiB8tnzeqeKwoC207MFfEhVvVEpt2zwZTnGVJ2bW1 iGNKfMTK2I9TXVdCtbWur5TU8PjZLnybh+w7fSOZI9hhvudFc9ER5r3pEfa6aDCJ7iNFu3JUbDxW Vy42Z8GFRqaCxAy+VUHCVRSt+hMuQBvBVmlUT06Ki7oiDaMlpeZC9EVXdHEfI9rK09oD4m3kxtmw lyDcIn2oUjLNwRBiPUAFwxoPZadxBs2a1hnCAVoxpHb6ffTMWm6agl0buWnY+jaRAoOtVAG8htYc 6jQ+8tNK/FQHCzHWgkgSGzAJFTDbZ+qMrER+K9fGugUmug/9pClHKpldI71bt53aaZI1XKh23lQg Coaupux9el789oB6P3SffFWuGB5h+Z9LzS58wLLq1Z0f1PKNmJl07bT1dlKtNoj7W0zttaDyJZJw rZ/aIBCp1Cqyf1C+6ZMlg+U0aXUQC7v+FKkru74ynMZdoGedOKwXjS60Ts5ADVdTz7ope3+1kiOQ W1vtrLC/bxJUeEIzhRqf250s8U3XYIR+0mFzR0e1vkomgPJ2rK7fiBbd+iOi6ksPkbAy9XLBFjSu ch/mSVsN8uB5wJ/TOZ8wT2YNKWF5J7snP7bgSc7DpSXfseD9d99v7kuZGav4Aw/QlgnRWM73EcgR PZNGlqe2aZl9w2wPVkfcMclZIOy28ag1zKPMM4XY/DyBd2vnv63Nb4V476Nq6Fn5jvHf6VPf4ELi ivK7ewTLWrvKg+pcfy42m4ddEdq+6g86gO9yANStj/hy0oEi7asTB6MJygfxLm9dItEMnZuzTR/k rZpjOytdA2PD/dHQ0tMSadJZwsHEKIYqqZMXRxofuopMNElvh0mN2gZbnjuZnrY+TUfSIjfE8HFw OF/aodxRgXMfH5N2kymLrm43tHYrsNk+6kxY4+RZJQOME3R27R4Z/EzLX3itit3WPWzfRcKsp+Sx EJio6b2xKNmU05ekUWIzYw9qn8Zv3DXO0ljBrUlkuj+vjwhi1lYynVJlNp0Ep0zunsMLeeixN8b5 h7WxLlrRIcHCKhx1HsuYGxs9erGV4Vi85ioustPH6Ji1k9w4MXW+bZLOddf3NWzd5dZAzHTdskIw NsZDyZ1iRkF8X0wK392/dSPgcB/kSVvIRIqjQOasWuRLDc1RLM1Ndza55+BKEa9vNg6sOlFih0Ri 8zoYDPrbydP7sGlnx0DdcyFd3QFX1XGQLlREwNXIJsBENM5Vp4wLcRs/q6N744IRoWh21a9GCPTi tBOl9wEPg+9xzGoFTfgoNUX7O2TJm3aLWa9n6xxoC1IW/ud+eC8yJhnZ8EAuMJtdGyN0NH8pYGGS iA1vJiMMDft9Cbk8JExtvpi3fc46w/r0TyakZOxdzVRbkSmXkDmX8GyINhNY+fsZsgFQ02zRRT4s WbWeofBK0ysPZ0aJlJieDzxHPqx82HWzPXByxVvu4kEPMaAdGDYMMgTAVN3G1YQcbVCqa3s2bXkS CUdD2YgqMV2ld9Dca9pc7PNhdsIRsFXfMdaZo9SHCybcFKBiiUmO2Q/91+dEg2nc6KuJ2u5rNgKx C3Jy28DooYGlrSVurbblkNRKTZd1dPDvIofbJYcanO5SgvswanuGvZ6SOpBxc2stz7LG6JD7N74X t/0Gho0LrCrhNJ7ZEVEgL67fZ5oHKsq0dwyuWe8Mbaal9LmAj2T788GUklnqrmFr+1gneXu5CvWp tIrp/bjvlrVppjtuGWzR5JDokg2bVfIdW7lk5gZeqc016vAsNrEj4MvgZ+jqPhK0HeS7VksSp+K7 GVm58fgiga5VgBPFpN6INJCL1Rt9Y1fYi5hbdqabkPkqCe2cv48lbSN5yqRVWzQ+JFSJ9Yu7NsZt jTJmCyoSCaDLI4ZxpFuwN7dBM9J9sJYpUM+eoARm6rllypXl1tVoxPSNWHlzBX1XbpVJByRTPNcR /s1LDeSuuLtI0F6Q6a1LjZfUmUpWbuEVRsw0vr2uqb5cL7pxiQr5FDVDIejt/QbIjO9Z9bVc3wp3 toabqj7ENIXTS3nMHZm7/YEyV5tS2juRW6OsKTVB3dQ57Obq27Hc8FEoSttCtLqqaE+4r9xjhuNg HVQYC7mHVYfmCbKzGjGn0VsKYCH18w3J3R38NjL+pRRVzT+6Rpkv9zOXBEIZuq3ZQzY2lxM+r1rM /v4o30X7Ob4nlG6nKKzWlVsnZ1eI1Vw4J8P3SgFe6cNRI4f7Tk6L7cCHcfRiExcsRKeqGTm9srjp t2neqAGlCfKgZwmTXQ+SfYOJXDhh92PVHN8Yvu7mmqZIVxs194JspoqPI4Ht/T4mE7X1kz8b2G+W eK4kT1tGvmv0cKbALvnC18forSzy95HyPE5U7LOaNAl+rrLYzYyg04kmdq1g6NfTP0+/fP7Hn108 /fVfp19+/u7W0/Ufp19//D/JKwrqCmVuZHN0cmVhbQplbmRvYmoKCjEzIDAgb2JqCjU3MzkKZW5k b2JqCgoxNCAwIG9iago8PC9UeXBlL1hPYmplY3QKL1N1YnR5cGUvRm9ybQovQkJveFsgLTkwIDMz MiA1NTggMzMyLjEgXQovR3JvdXA8PC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0IvSyB0cnVl Pj4KL0xlbmd0aCAyNQovRmlsdGVyL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp4nCtUMFAwBOKidC6n EC7XEK5ALgApxgQECmVuZHN0cmVhbQplbmRvYmoKCjE1IDAgb2JqCjw8L0NBIDAuNQogICAvY2Eg MC41Cj4+CmVuZG9iagoKMTcgMCBvYmoKPDwvTGVuZ3RoIDE4IDAgUi9GaWx0ZXIvRmxhdGVEZWNv ZGU+PgpzdHJlYW0KeJylXUmPLLlxvr9fUWcB1UMGyVyARgFdvQjwbawH+CDoZFsCDEmGxgf9fXOJ jUtmFVsQMK86k8kkg7F+EZEyL/byzx//uJjL1cSffllflsuyLPH3b//94z9+d/n7D3tJ//vtLz+C edkvdn3ZLm6zcUDY3QvEYZc//y7PkP4Xh91//gj2shgbZ/r5X5dfvuBizeXnn//4aoPd7HJbX+N/ rvBqlpt7NZt9T3+US3bnG9akGz7+BfHa/mo+zNvt6hb6G7b0tI/PB2tuV2te7efNmXjpdt3TtJvZ 4vN7Hu/ieMBpzWd+xy7ryBcg3OIc6Te+Mz1j87W3vM78Dy4Tyh8ftz/9/Lcfnz9//NoTIOyJoA0B 7redXpeXf0//kXnLzx1/Xpe0JcgLuHq74Kp4WWUfeYr8M85+9caUYdtOq8wjeNtbvhqnWXgcPl12 FvAa3cMzUgeWl6cPDcec0WLdXkJDi3IaeQLcj1d7wbcodlCvyhsCeu3VpuXG423pYSDyQuKLMWsB 856BSJ50o/AAvyoeQJxuiQ+4anMv1q0Q0r9+Nzb9u5h1U9td1maz/uMW5/I2HL0Kjx3yTqrTTYsA s/fsUTPNR5w5xDeotUfmSRNBf4b23p0f0U+LRKElFMnL/DJFhRBefKcB1BJdWuF1LcyW+HUr7F7Y wW5Jjquz2M5WekWOTvP5kyNPc20yNG9RHUh8xAKJfBTw677T2Kho1NJRoKLATBHFu6hEa6LAxy3K wGf6z1eU4ODyC32Ib7w/ryz8Ujblvei6r8wGSY0G4EmPeUmPKs/SKcVTKfTLK0HqFhYKtWROEcPB i2uJAUrGSUoBfxXBx5WU8+Ihog6gnJg1WQW2IuHKQxa1fB5VtCypGQs8bT2bCVoVfZaRZcaF2Cb+ s/AD2n5kSYaVz3CSb8BEu9to0KCOh3WzJeWZdhypUhYTxQvu9OL8J11W7FA47EsUaBq6q6FvRfGS +K0VAxVmc9FuFJF+ent2XaJ1UDu0tENX6PeeDHxc1Ltx8UUOcFULrsplR6AowSAWyswR2OzRmalf bz8s5P29l3nzOmxw5dU+aayo1q2tL5r3zJj5SbtWa4pLLTbF5t0kG/tqfTFB6Xfemt9l/iW7KVFB pMfCDWijZVn+5vBB/mkXtZDyHp8fdrKIOTXu9/VlbQlj80u3ND/+LnuBxBP5gn2L/y60vChOzpZ9 5X/zJhYhirOL3PxKS9ZX7Fr2lwjp5LQLU/Df+VXOyTx4ZiEPwTmYclMk2BZy5ay2ZLycwnCAOsry lbiSsGTZvAaX2eXKpxBlK+AewzNHLYwTf4cgTxZ+I0KbD6FKYVubx4OMz57vt+iwevLphQ4GRYBO nyRGMXe+kb1OuvAW/11pzW9l5Yn5E5WYInlmj8RScwmV4+Fq8ZHf0czq/fITrEjKeHp6myPD4kaK greI/J+1QBGOhd5Ljo0TkmVNXRj4DdljHfISi7DNBLEm+izLidPtg+2c7uCSTD7tU6zoU6yeI4Hy TzDiWjWmOpFdP+e+8Pn0d0i+SSSAeOUxSmvdtJMtub3znqI/sJUl4ER5SnSAPpClAFnqmfjLZMeT fwavng+y4/KC0JnPT/Ic9INt7HiyRdg6r7m3u5XzgRFviv4wPPb21AlOZMlDcOiUm4nujYcplsik +jzbt106B+chua/IZyGf6iorvga+8XhzGNqnM1t2fmzmqOUx7WYWRkpkWIHve+03PcPyJnQ+8jHL X4HxEeQWQ0jFFR1ZKCIpfyFMAKHemUJeGuZVIEzLmRyQoVPqM1fK8PHuC0se08Dt7qWNqOeglHzI IpkBzyvZZB1GCNs+wAwCUidkYAk8Bq4+Odd6dnCIcCS/P94+l323AfmgJxEz1AhF5G+FyGjJI+ji iguKeigYBYplhQauPB4XZ8BX9xjkUhM8qUGRcAxLLYYnUEeyY0R+phfcajocUWE90dHFCCfLLB6e sZokmw4Uy0h+oghqjiTUPFmUbJArSrfZ6uf62kBJzQs0mFMBFkXn1FgGCRJDkSdkCXuPLnZqYYyZ ZfVv8EjNs2q8eUbUrUYjZYveAg/WMsYCP15hS8wTCvi1c28UaGEYzqm4jWGbMvKLuNdAEVFXboBX 7Nwckgp5aTLhxx4sbFbtWmaedMmUMn3O+vLxOdH4LCfKZLhj9Sym4NjynGwZfO/RZEgRENOGp3wQ ZaaB9mKVQmFXuUK60fG4AgA/AqDnFqhTXdCjXb4JPi6AVKVaVeUJnFDBQue6aiTOwD3LVHbwFxDN M7CwDVOuPU/qGU68Ba3iBlcOIcA4/6JUHJPwZPvGdm7MbAYAWruG0FT8x5eoN9vfTQPKBZTKqSB1 fcLfRVR5fyhvvSY7pgZse+/sFk+tIIRn+sYib1pb2WiLDr26HFmq8h0YFmSM0lJezdrmiuJs6+SF tZtdSxyR1fZSeEKKdet8HuV562RTtPZr8SOWOgdWOHADvgeU5QglGiUEPxKE/flq5YF9+IX53qtz tVuLczvt2K+sU1Q+AXr98IgWy9L5uRpC1nS91+5tFZ1M2CMIofMjXAbuMOYhUnncql/Ia8IETeBE WYEzSgzkkeg+8HGYgCyOK1W7kdxrzT3pJDivsZxppOeTEs3+vevdS+3QdKd46Bjog5Goy5NDndIy VaIH76Mp807s8uM4xKNJzk+TVeRXuYqHTzbvumhjLkEdUI8E8iK/kc9l3ukzOQFVWrC1I83zBlSF YZScQSf7ZPtgOg9Sidvjg0Yz5AMVGcTQ2tzgSSqw5tEsomEHTa17zdhtCsyjvc9clhjMp2UHm36d coDZeq/kMEivDqcCkGAUpKZ1oenIgxRYhSsvSNuGaBIBV9nE3BuG86DiCcl4wR01jjt3v+y+9sno s3yz41TwuPqAFB3aTVo2qguVSix3dchKT5yWw+zq4cPqBE0IWsQRm57QZgudN+Leb4xaRDH6yj8S EEBIV8Y9CN3w6FhqxEAGGhfninIQsojGS4vcKqpGfJ4s9pt6CQZkJJEnu1h9n0zupJkclc6UtqH3 wBJVgEDxmtQVeM9FSGZNqZuUV7Be4QzapBg66SxWdlXOfg1iVs54UD4c8iqBFydEWaDzKAq7rI13 pdPpGj1JG98xi7ylA9njg+5NBsP9gCML/JkVkbelQAsDELjTYZcD8kmIrXpHYyfhTItHKRo7kBO2 qBxEOocu6AQ1lyohcYgdaGS4CU9mUkrW7X1mjYDRtP4S33xQMtWuqH1WNDlJOBN8MZF1NympaaP/ E+jFWQ0k4fc3myPR5yezCaUb7SJnYxfK6tp1Qa2ZC/j2RVLJlAzL6fTN8faeIsO2C79Aoki8tfIU VX52LuVpYetSv5y/L+ugXK0kaFlvYKa7Tr5LCni7SUJvseutqI90/0vl9i1muLPna95xGzmnrXKf cTlLVXlAidOndwsmoc9qwyhOaQE//+d5itmlx+XeGOOq4iGuNSF3trYqguCVvIMXpOr5ssSTwkH2 2zhdQTZ74ZelJa3ijvdZoSZz8ZA8piuEzBajgEtcenZnBcohk7MEw+3J4opZ7EPMqzMLj1WKLhpg ceiZSyWRWMr80rtA3pUyEKmcNmrJKrM6s+vddd5Xg7d2hZoCeFTObVtRRdEvB0EYx/uwi4tNhb1q opMqOP06BAyi91n7ozOb3+zYx858bTfyhRONbxlxzJQ3uQIieUBi66XMrAn+409Qz+2d/ITkxlmA YgddeoDYKT3wSD4VcD538KsZVfgdJA8af2sRpv7AAjzAgj2jGP9DL9BahVVpHIv4g2EyIzhg0QuB JY0RtlxBSOjTKJ9dY2H4oqmys+00613eqjdVCBbP8YNAccxhVIWHOmipUmHZJNrhQN7fuGCgon9g ZpDrFms72pNCHG3LxzhXbvQsMhhKfnsXnWU0Psthq3pQxXn3zp/DAjKaDFo+4rQRxoGtxu0LsavV NVjGDE1cGGTCdZpjlKh3O2nbrBGqDBfpCoqJsoZAYMOxfYyexfJ6SlIsHXYtEFOvYoiu1H0a5VXv WCM1QxvwHZTJ+hvX7uVossdMO/QYZEvtRmm/qLsmSmjrgn6o6O3MEbmwy8tN7Fghr8WrmozO+KCi fd5Zi8Lhhk02rYPSYjeFT2JoSWGn5yPTkLU2d3dB/OJzizw3LE4gQZrcy7f7ZZSbNMLpdCWKpeol m7A6jOGpFaZce5oSHOtOn9qoGyaH1Yzbb/qd1AJEOwXav23szpXOpi1VK1aETjwfuDLsUF4bUIJD 6BRUKTelR8tKwI4gmWd23zXHsDNUCjWonoWSlgrqoEI31E9caBHFeJi0QAvlZFjNISfehwakqgn2 mzvwPxJ/GR448j5mSTXqoBGRaN0WxOStYPI9E0Bin3ivGqMs9Nj2B7ToiLN3pVXdCIL1Zjc86o5p skf2sBqjFhRATZwcY42+ApXIDcsZnPLAoYUui/5nTxvI4dFXmphjlgCDjpjahdoQToHyb9X2Ro5K 9pexCyOPkjKnBQvh3A5y91GACBVtMUxl6dAvEuaY3figvwV8D0CvkqXVSG125BFIXUizozZcCtJ+ WhnFhyvzKz6XzHJxq/TERHFg2z5OPT1DA2lBOQkGAFcDy2PZxWyCeqL3PPgcAdkKVgU6QBdnIoXy 6KYernhB74O+qGkrobpOvoHmj4rqZhBZXIO0fYitanIZDBJVrwzs0AZ0vbs467Bsk1atEHaG5ikH z9yZjbPUQCuzhfqq1L+oanip5DRYVVOFNLqiegIpRYJJf4gQ7GxNbSqskcyKpUO2/SWZRuiX6KoP umtpkH93X9GALuox0pV5VqcgJ8nFdmPvKsUHXxyauInuMiTOMqx/OigoypRReTHYWCBxYSBuU+cy zQSVzvm4tkXsLmcBXHyT3aasmPPlKwLu2wgyEmvQu9KI3spK+KQdfud6oSZSS39W1gRaE7AqrGWj DCdxXrEDagmbchg5vTfNIqP2lkemS+kFtnyyMBLvj65m67CGUVdCHYjloAW3Np4ifDJZFVRMOwij vphaHqOclpYysOfFelegBga7v57IGGHgpWJWNy0d6ihdJ96VK1ZuYkI5auxgliCDhhlJ7RIwxgrx AU3wCeCxj5AKNVZ7l9JyDrW5qwvy9ar6EoAiXYRSshw6lkECcGZJNuil6ZyKcVHdNWB/QFhJyPSV nLXSrRlvurxcSh7WvXM6NSoT0CvncXR3WlyGLTNGeyHQex4p3VB+5qw9vCPHeKfBeK+ymcULKfdz N4RgCkKINm2ny//EbQx+xmhtqW7J7av4G2K2cvI6mq7Xb9ivPVVgjoiHJqHGu0zP6KwTZw9s1PtD yls5OlU6IucFQJ8kJSUPigfPFVQWylz5Uwt+5SORq6U8UPbinlMEs5QZdQCxZVZYvNbNbYas+fyN 3ahtaOMoPv/ka2fKcnYDw16dAljWQexZHDMAOA9UFWBEAIxB8xVuKAh8wsg11ZgW/6vutQmoxoWe Jc6ojefgEzmPjK2trO1eULu2cuglGLsv7K/Cy7iVKJ/5imoK7tbknOlrSH3rwbcO1I7WUqfk7oIR wx1RE+tywG4dkjFUNszmFab1yKr+828/Evv/s1r8v//+R/5g137522XHX3+9/OF5onddSGRtRNF0 qY9soZwBSWMd+d0VoJrYb1e5MaDpG1xB5cfaBoQRv5t2NV1t/TN0GLQmpSS5vRenf1yUUJXaT6MK o0agALlo0OgSkMbdQgxn7YoEla/fJqMWjmSeSwoJztWiGeLFP50gmSXLoEFIQ7+fWS8X/byqTGL1 UZ3iWe7NqIHjKF/AWXWwYleyAF24Im/fnvGk7S5rbbT4JGGGvULK0MK9NbKVGpSuJ7/dMlhwUHHM 4F2J5TbmnY6tGkMv38jaRqjp2qGkeIPoWMcrs9QZtA/VYSHWTrhnTo0Q0yqZLRXodLFNrjcUom8P qvT5IC5TXyb84m/kfANXGjUNPbFT3CL4TqGAF/fhm+3egP3e4JrcC02truuGN1XrVw09BHhmaTXo dkq9C+iGIcyiHHyinHxIaz/NIR5gKlItA1Qbs2eAVX0HpQXxVGVY/RhXYqkM3N6SZl6QBo1QR6cv zfLLjFSxBmWcyq4yTyMFV2tWrUGpIUW3gNX180sTnel4SKn2VYN9s0TqG6aaBBAuBlZOvsK9xf43 GfME8XY1uhFUpF5+2RPt052UboafP2jifYYmoy6qRrbXSrSt44KLGmdvr/dFghbVlnVi3NlD1SIn MS11YTgsc8yhnrrYf6GhkuimfoAOTBeLzRJs1HM1MBBiuU/BTMvNGS1/7HzjsPprVDXTVLiFyrxX ArbpW2cQaeVgTJJr1LmVy5EbYakRGcE25FO3XPLjjVw5klJvQJ56SsXJBzLczuk1roWA+WKAUV/W uHA4WSiBS6k0r01gKVgXt0uNEUMgqMz1Jjh1BduOSkvGvYkcZtCXJuy/oIFHXV5taqcpStVACyFW g490jtJHFgxP80BPDCx/06h/6GWQZpY2d2vlvYzEv32PYIMOsLPGQxUGVN+0oej8LMcAbYqUPhzw jAg54Dc0Zk64Zt7IzVJr0Ex2asxKypDrSF0dmSpWqOtKdRmpY3GoZKaqb65fYamYdfAdkxR3wGA1 jNQWafiGNpLmrk4bdf5W9UEK87TPWpeOf8OlYYE1DwMMspt5mb5JoM+j1H3f1B8PvzOjPySnyiMw TMi5lyJCCHUxFudrk0vJFoIdFTF0QpqVUu6zlO+ZfNROwlGy90QtzNJo1BoWGsOr3sUfHnFcuPR1 Kz3f7JMBf19iABdXQlSiBS9TcmpdslA4UR5JriYcBvh6EUj2eY3T94P1UOxZXMk7gs4l1hpo6BPH RwKU76IeJ3o1yYZOOSgO16s5A44mqTTqHzs8dfZmvHutGkPkMy2dSJ4HSrsESs9qMq6Te+S/Mzj+ LyOFgz6zh/jNZx1AayfnSG/qTz+duE74qR79hag5wEQ3xj+I9QRIoNb8SdIN29RUu2Ouj2QnJ1fk KtVRVItyYPJ3AbdcRc6l7er5ppJJvtnZNL47fuHkxy4zk85Wn/adaEfAIEGgLtGacTL6Shx9kkZO ijJy6PGkEeqrd8xc5S/+fzzhpKOTrx+AiI1aDMm9UgJa8Ve6YdqBHnShjUsnUdlsomzac94UXsN5 fK65aJIxGvjhPEZJqrdC89bMLVXBHCRPp6yPqkd6fXu/hXK+Xbr1KdjxQYmt6xMMop00eiSOTS0I eYqV2AGJKonIo2+kOfV/aIBHyp8yIW/6wSuZFL9e/nH55fP3fwBz+cv/XX75+ZvdLx//e/n1x/8D 8EGCLwplbmRzdHJlYW0KZW5kb2JqCgoxOCAwIG9iago1NDY0CmVuZG9iagoKMTkgMCBvYmoKPDwv VHlwZS9YT2JqZWN0Ci9TdWJ0eXBlL0Zvcm0KL0JCb3hbIC05MCAzMzIgNTU4IDMzMi4xIF0KL0dy b3VwPDwvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCL0sgdHJ1ZT4+Ci9MZW5ndGggMjUKL0Zp bHRlci9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeJwrVDBQMATionQupxAu1xCuQC4AKcYEBAplbmRz dHJlYW0KZW5kb2JqCgoyMCAwIG9iago8PC9DQSAwLjUKICAgL2NhIDAuNQo+PgplbmRvYmoKCjIy IDAgb2JqCjw8L0xlbmd0aCAyMyAwIFIvRmlsdGVyL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicrV1J byO5Fb77V+g8gDxcq0jAENBqWQFyG6SBHILcsgA5JJjJIX8/XN7GRSXRCRpj2aUqFvn4lu9tHPWu T/95+/WkTmeVfnXb/r6dtm1Lv//217c//nT655s+5X+//f3Nq/d40vt7ONmg0w0+2neTbjv97ac8 wru2u/H500Wl8+em9pAfvP548/q0KZ3G/vGX0893c9Lq9ONvf/pQ28V+6O1yNh/6e/6p7vlC+VUr uBTKXcroUO+sD11VFI9d62M7DmbqdeMvWpV7dLrJ1IGCzr+ctzykusQP9VlfVwdU3/JQdWxT/lDh co7dzXUinzC/T5jDlp60lz//+P3b54+3X14hio+Z7C1RtDMuT8DmKaeR44f2uHZBgbSOgWTi2+vF pcu38nwexsYPY2imNq/zbLbJV3g1v1cpp7wBMqQpOZoSXTL4sxKmEnwjStZ3fTaPlvvLGpdItYd3 35MKpl33GV941hrWkH4h6u1LxMOrefPLKHU4HesdZufnfH+HuSeafqjv+adVa4vc9pmIoAx4oDVP 8sGkK4O7TBBz1cGYhmPveTsqhVwhUGX6z4tJe6dcoqCz4muFL6+0zl/rutzy6YA1w2RGX5AI799d RwOrLxuIva8jV/lM3G13YO+9TBRE+YJcNkqzLsuwwfBjlXnqoxF0QblVjr/l8dMaQ/qvME3oXm4a KgFNbmtrdzap2I7F84B7OzFSOWkOJtQ55E8tuMOjlNf1W2XoticsJbUucFBRgCjJ6cub2IWsSKza eBKSmxIvLRHAmnfbE6Bnv6SJ61YauXGg9ztdXBT32hSMShaum8K3zH9CQcJqfVUurPKeaJhbfYae nWsvs/PwjV727Wtf0Gl0KTPKxm+e6LAlGqmYLP+SnhJ6yQCz6DjVLfkyff1wo1lCjeb7k54rEpqv N+O0kouyGpZW7eL+PmjnIpsSOuSdCnWBWTvcsnjs/HfRy0k2rCp3box7zqji0txh6lmt1FsrXqHd 1KZw9iZfZTRxkbS/QY4mVQm+Ucwuia5LexQZJIBuN26NUmEbUE19NU7sHOtLA+wxriM066gUKnyK ujs2K9Mq0jDVMiT10GLKaPCO1ziUyBVG7kRhDIwMl8iyuwEBj7tGgpCnMXythVlr1YcAowXsVroW lFu2tdzUb22FxTDat6/abLf1SttsFzZEeeIadJcCVFnBAjE8CnH9Pplvgesf3FQvw6zviGgNvycr g/obXqk8WHdTGx7rFXi9RA+vB6jKnFYnrliWM4E0CIQOR/Np9f2dBvO8TsQkeSD3vX7i3yAcZRZV qmgctAPCGQPEUAaweTuTL1B2c4kUNg6QxtzSaOYz/6hI2aShrwwoAOgZwnNC6AUDg8NBbt1UsIsA gAfTYGCBVRkjVomp0CX/Xrh2KqL6iw6fM2GAt+Z7HRxYeu92Xl8FrgOQnjcW9ofU+obeyE763hgc QbCNoE+QN7/qJ93kQ0+V6hJx9DZgL3YvCsxCtx+cDaFGYLMr8wjHF40waCAGCVno4NIjJIZA5aNf WLU1obEbhEPmLiJ9m5h++5p3mARwgMfPrZqGQEJxXlsrzH5yosGVwhtlYcJ/2GaysXEcYasrtJEH 610lrflLcB9IBQruVjVW00yYpQEg3wrJbLQDaEMn8lpFI08CoxPmaKuLIXNgYCwiFWMZD6Bektoh PQJLT+KSNrysZp/Eu251VJzHYOEyxb+JGbDnXibwuUaXYAYIf+A+SnPZ8u9Zu50N7HOIZUxnjom5 0C+ggaQEsUpCFCZB7p0RYgsTCgZYosuuRoxmxEzBGtRNBmlIf0A8wZPPkjTVKEtn8By3+NGBLvlN UVee/gZ9RT7LGVxIP4FSHarYmkHWCOHjDMOfjYiXaOAKrV60HvKBY0CEgRrSBapI5l7jhu1AAtVJ C63E5Oo+lWHv7HW1lhXnXTXbEq3cPuA9QJ+aBfoQphjLUt3xN4Na85KWFvEh1kFCsbRgzo6KR3rb 11HYRBxokaVsL1nVu03eZbbB92Kj+0tV6e3opGben4DF7MVGvsOjpqAJSwtyZbC3b2Lc/yeUscaN OG8BhtqHJB84ovh55GCJiKxcUFGMJk6tXMAkiZEmQEsSYEJFpBVwMB2r8C1RR5vBK5AzuhH0b6F4 4/e2DG8OvThYl0n8XM1EswkmC6s2BU2uQ3qr9IDKqv/rklJDzZPMP2AtHxs3Bqapqjg3DKtn+4/2 5VYRBQ3pOf3h+U3p7jSLrAVFKEkHMZWqS3Yp1PULHoH8+BWymBAHMC9jOwE1TA4fY26IINVN98Ii Ekg3kbwy7QzF5bSrVYtIjeJLuoszUXsOB96l+rcsBGcr3yEikb1a+QQAt0SfPYwIbB7V2KqLbKab ubF1q/M1lvQmTTDRQgSJwC1+6jez7zX4XSLnsy4xZtsGUN5FjBgQZEbfwIxuiljEFS4ooiPjZmS7 NvB6thZqDEnj1orIF7W8IOIkBPwkZFjdfe/HxO//mqjcIQa0RXBp98a2oN70M9OyA6LKz+KbDeED OfLX/Vfj7LwEYDm/WT5lCG+SKLjKxLTc7CfWFeybiBuysMn4Yhu4K95GIIV+FVZmEToYO+RW7jxD L1FsT50yo4Cx9P1oRueAkfF9yFifg64+XXgeNh83aGmtRo1J/bkYTJB6xxR58ZxXeISCAoX3GwzU JcwIOWP4dCergT48K5J7z5kysoYk/Hq6zagwoqXnYR+D4a/OncA42IuuRBmCEi4UU2O4QeOpMRtW fDWcyMP0En+tV91UHfcBZwugA7ESzeKqRcRLzLOJvXJIT4mQ1nEmDhAZ1oGol4bX4u5ZvKDbiiHj s0Sp4Mfg6ixQieEq+3rKjPBiV0pE9Hdt8qGzus0rK7eyxnMMhTzDoqIkKnM5CXntwO9LNNrdCOVN 66rtnHkgN5JS9ttRVJC0RsMYFEmySoD+swn9kDxY2jHCd9KYIw8Jvz+wFTvSW4voRW9mFlVtuRR9 OHBZ/XQ9naqhIoXtFfmRxRTKib83Yt324lG1Rl8yuEQPr5cKIs4edtdvo372O3/3ilbgjLEHk5M/ X9TuQz5ZTxLKS6Sw8RHGm7lYEJkQRUwTh7TgsV3c4rpHaK9lMdQcRgyVoeuVUWv0MGEA+geqUKCT VhGKOoYe19/kY0/EsK+zONJTfQFJOFLiSzTR25gfL6uqjivGITjQTgihT9y0idJZTXCjDwm/eEWu fI33QliLbqjxW/rrwHgRJOIVzLwLWsX/x0vQak5BLoyCXYsSumDC7yVexyB7WPSv4OsX5lAxGWD2 eOiuYDg/NAhjhWLRDkjxoWPFyRZCdOZ4ephkNR0CQrz5LAGgrbixswiUpqUImSA6h9E0xNFK0bNA qwYC3pj0WKJa0GNJqhli1b7jBRA3B/vvMr8V77KtwxNpmcQsXvPdz42/A52X3/FAl32hRmtXY4b9 ae5fsAslUmxsSpB9W6gg0z1rNl6+4AtQE+zAUrVnGAtiYcHE5pH9LMn9LNnFucMQYmRxHjePCgs6 XkJnKSIrGVtMeE4bKeHmFScz8ZbSodE/7QTW6vbm4A7YN8i8dqk2vXMlShNi4HgaRpc0RtteiCdg QauISFVqVe4QE3gNxkxiaGsRfutn9bAE3vrYGjslCPKT21dKq3WH5eVecdlic5dr6DaCfT+pQZEP J4NeIxCgT6/dlq2Gc90kmvtoEZyAONJynO94JCCgGtIVR408kOyole+hSSIRIpxuCrjgWavMytEW wIlJ8mKn7V7HavrsYA7Ovt7yJAXEWX5+atk7jc1dLnnVVA8pRVFfkbUWlz9r7Bp5znYsRwGnGDn1 SUE4UXHxXMgpNYHKMb7oE04qIUUdBk+sWMErRb+a8rtlas16u44RgDmwrpTcehTtoIRZAVajzDwW maayq+zV6lKHDi+bM1/kzOwt//k2COkc/+0wpNM0H5D99wxhRe0dJqYnIXSqqdFHntZBlKT8q2u1 0STpp7Xqutb8wh//eI1aNs6pZVwVbdYcsasS+mL4D7Zn0n5msAhGwNWahVV9/hWrMErzgKmFKsbV be2hmAw8JEHSqlN1Q/aiGDgEAYHy4FG8U2R5u6pNAReWaTJpS0uLYv001Crwuy0EHHJZejIs+0Wn b13tpyvXc5BLJtEVLr+kf9Pc6PGuXNDuPDKwKwIy2Jac6wcnAW5azC/A8idNadhmMqaBx7CE7O2R 4qxKIKvf9sYG9KVattwvsg+3BhdzubfvNL/Bupdm+Grz3Bf09aRJjuF4U3owz84bbG7mcmDIYFLE hnOtmlhdXKF6QbaiwgsTlU595UMzyCMbI4NKhOFXiTTpkmvKNu6iElHqfBnEanxLkZLmrWsz1U0p jGi64dDFUO2iekeAyj76QBe/Z1Y1tEieaTudLAWfgBmOWBM8ayN+6GGIYPFB87AMF0O9Jj64x67Q WJtp3KVpxZUh6t77A/SxSqRZJ12jFDhdkN7u9ktbFRAZ6zkRotOBNEmuJw6cNpjlxOPADF0Picw7 EGOueFCw2El/3FFN+kdjlhELeOBkF6A+GhpFAnZ9NEGpwDJQjYuL/HjVOg4MbLmCqIrCcKtrHFrl WvQ5tq3LvH1rW2X3RiE7Vn4lOOSqrk0QJOTKt6b9YsQXj3Z4CJ+LYcBzV1/ppgVaTNrktGnAKbc7 QSEYQd9nppHK5LOz31XE7S3kmNZDGS617AZDFYvN+JJ4Em2t88akVw676dt62MzUBDat6qGgVUMe iMAmBdyGWuRZQH/SYtqI3p17//NLTcyv/FqzINBg1h/X9QuaLJT7JqX8swXYkzZBETDeX4m58oa6 IOSfvUqgopMcM8iRElGKVUrMmuEeiC6bmOqW+xFJgARkzVBURa7EuZdfoNM4143WhVVQKhi66YEk o69bdtxqJW3+XKgGhbVyY5smt9ibTW0k+vn1t1KlVn9+VxuxhKmOcLp7qz0itzJrfzHZFBU+Lotx oEQ1XvZdJFh4sHVis/YxFy4tQlTMY/LQgZZtTX4pBogL2XIcTEX2nKRgNWXeTQtz6F5iuMRZDuYQ 7nN4xnbWm01Kd0rHSIVZs1hguF+sQEVJASIDaBc4r6W7xFjTevi6NDZ5sucpTJGWk85WKVzGlK/I 8BU9ekyLSYPYciXdnb73l9Gltw8BJuLVPcoCPCoVorwZGEMcgGKhkSMOMsLT80UbSLo9IcikUWwx 0EgLeKWhGNVpD7oz/KVhIWyQL8JrqusvGCCHcEyAzoOMK4K7Mo7oSHdMgUn716vkxXbIsTe38d6m qoQfuo5klaVXYiRBUJBG6fiJBJ35aM5bkwt5Qo2xy+sZN4j4clM4qcm+kQg00RMRZSiJEZkHFCVN RpbtTcBsuttbOuHn8RT1ZIrjDKOY4MMQ9TEFJ71jtVWlxl6vErTDpQsf9EApRZmexLlzYdGEZ76J 1qA445VKhyjG6jhGCJgZbQGd/MOzoHKVY4pM+sXaLdglj4CXoJ9141JL1jbjl7aaJd+l+G556Bny E742pzXdZVcdbRte2gyNBZEO47tY4DQROZJm0n1WIp2NE8Ulti5OUOQsxC8MpHj2ydC1ZgpcWq0p AdnEE66iXteh79Jc8dUdx1oq5HwRHRybjgbKzBrQbMZu1Smu5AWwi1U/XCFnj7MrbchWVO3Z8gLt 8QWDjkBHlflVFO/Nz0IiX2sjTXa88klrWdN8+qAA9wpQOVa/B48I1I/TsUM1pQPAVR4SB2Y+883E gYILaPCYCpMus3EeBRekVyfhLvvtlXqY1TIx09VIBFhq6jNj2TRpHbJ38igllnycbTopeVbT5Gyc PiLUBtepHL0/+m7RBZs2pPG5d8B92feCUIitx9DN/aDmJvJ2CmcNyyE5aHJC5MxW5RiYA6ZgkBJF RTmrvkH8qyGqWccaJpvQzD1uJgRouu3zgPl528QNVQ9LUwA6jxtMyhkHGxw1se1PSTuJa62uf+hF w6q9qkJA34MtBN0/CQlYjwWwqxOYNIgpra2Q2FfDMXgUlAjhG+QOTiR/vNAXe9xqzgTwLxipSW+X /SzFBW2W/2HdKCf5HrbrzlKLmBQIaTFNS7GDQPTGxatxUnYK3QLyHI4hmfmyzzDt4uJ6DXMdYFGB k5j5xoMkKfaKXboQfit+of3mRNC0ON1t/jxdsZ+jdbYYfYnS6baTVMDZojcXHxYpj0uftGVl/kqT u038C9XFPhnd7vWEZtAODjsg9zEeSSmO9tRI4G7wVqgoC/lwj313/vG6Jq1Uz2JGdZ8yRMtbBYAQ EeIMf/Ux8SpwIlhP5YWivO0J45dKZJE6wCBAU2Y3HKczrn/SImVLh9POIYdO+1DYIn8nTsaBNN4E tDWdZ6MMUMCHjhWis2u3KI4/aHuJBcM4mRrfWKkiO9Y5PYsfPmyPetxdL5rhtouVB5lrONeQ/sKq h8oGkQ5O13Mi9gREf5eWSSknMc7BQQgD9/E8kfuOiTNpmBqmYhpqsGtGqduwXN3nI+eNZWhKWlCu GRfhaJkunpw1ITEpZ9aOSTDpkXotDng570DuvW28YLmS9+iuEELyfbpro5GeHuvc1vdY7LR4UhYH y520P8HpM4WjYv8C7u0fzkib1aAbNVOZTSBZlp+LQLIY/fWuBOo6DS9YhaFr6ainBgNNsUsdBA4j Nc3LHBKTj0pSjK238sYZRpfnpx7jvq6KSzz3PKsw6U36arEu6rTnus9S+G2o1ILMkWlKZlAkJYiu tbZNnDOImMWDvqDYewIDQSZtR86IDr4s0d+zd1qaPeqeCZzD5sJgaY948BGcIDkQZwhJjSIIN+bK VdeWKfarHEfKVf+1o137PGn3vXwg6DmkyaQ3abB92htKZr2YouuCfPQ/9+ib37C4sD2l97NLssmS KT8fYTpZ+y1PynJZ6SEpJj1JTZw3jw5IOMw8k9A1zfbnKJZ1gWrYK+CAu/FUXa7ziOwGkSk9OlSK w3sTRsQYCk8Pw8r7K3pk0qrUhCtYPYnkx2Q9GKbsUIc0vPy/PBnO1lCDq9D2EjjpND5CViJ/IF7W Z1We5SbHc6YmAYDDM7D6JBNf7JNLhFzBlei6jmmmv5x+Pf38+bs/GH/6+79PP//4zbjT7V+nX97+ C4h/iRsKZW5kc3RyZWFtCmVuZG9iagoKMjMgMCBvYmoKNTMxMQplbmRvYmoKCjI0IDAgb2JqCjw8 L1R5cGUvWE9iamVjdAovU3VidHlwZS9Gb3JtCi9CQm94WyAtOTAgMzMyIDU1OCAzMzIuMSBdCi9H cm91cDw8L1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQi9LIHRydWU+PgovTGVuZ3RoIDI1Ci9G aWx0ZXIvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnicK1QwUDAE4qJ0LqcQLtcQrkAuACnGBAQKZW5k c3RyZWFtCmVuZG9iagoKMjUgMCBvYmoKPDwvQ0EgMC41CiAgIC9jYSAwLjUKPj4KZW5kb2JqCgoy NyAwIG9iago8PC9MZW5ndGggMjggMCBSL0ZpbHRlci9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nL1c SY8rOXK+v1+h8wBVzT0zgYKAklQaYG4NP8AHw7dZAB88mJ6D/77JWBjBJVNS9djdwJMqxTUYyxcL 07zb0//8+MfJnN5M/hrS8p5OKaX8/be//Pj3P5z++4c9lf9/+9uPaN63k13e15NfbW4QN//ucrPT X/8AI5T/c7PLzx/RnpKxeaSffz79cncna04///ofH+Fq/fnNxu3DOPyM/pw+zNf5zX249ew/zKX8 85l/TKk2sl9nZz5Myn+t6qmDJ7F58pm728ujAfF3e7GpfGKnDb5+lYauNnRlDi8t4Q9nrzB8PFvz gd/Naqnl7fyfP//04+vnj19HksStkLglCfQyK35Es9VpYOEwOq3HlYUHXIhd8yY3/IY7xGGoFbeG Fi7A3qKMArt6S4Wu3lCrMq4dpsYhkwwZy99h00MBLesgCxM3HhFiWd9jRwg6vEwK+KjH4fhoHD0L 7gKEVyeCk1+pWcQDNfCb00eXjwkbXcr2jQulYYjnt9zuXv7F7wH27482kJaetUNhbaJUJpAN52DK Od2B0v1i4QCQIUufG24aThL3bIiuK3/WwctH5PZvSx2EeRWFpZJkw3PfPrw5uz1OU8NUcqTy9YAE Mb6H+RmiZHRbMiRVSxU/Fr78jERzzbu45VW6r/LPvTzxfa+50DpknGYotUXnYEVFulfXNbAr/Ebf Wb7ywhMwAbakNdjPTJbc6FDKg89qsiWM2+RklYxcbGxoUb4HklO/HeqG3DDVhsTrtHZXmZyl2BpS WZ88YO4m3UEMUACQrEpiNiG2U6Jfeq1nPD5QJAf08O7dd/RAXtxEc+Bk9zJNDCSdmTiijS4s3lXj AGc55806cISVNumRJDuT7Vm7uph6M2Wu5dP3lsbFXm47LsxN/b0bSpG100nMcElaC8M1g0xNnP9Q hGA9upLwcEdjQn52QA+zZZvece9cs6BWsmVwezlvMzPeLclu3UGxHORhDKpu4eNOATrTd7bm3OkS sv9w+tmYkX0LRfs9wQphW957tR43OBFPFMzs7worBFP/PtJ5QKANdRzjFE8sQZJk/SFL5HZJpkJm aDs7WybOYnCDlchEoZ7IotbDGKkongNSrGlAKurwsr0CUV1p0c5dMjK5K+sFB9rQf7V0/NUmriDM n/2BXxrz/41jXMIAPOMKx7iR9jIZyNisgYpYlT/44fNiBTsgSuYfrRoDV6tVrGGwmv/RT/bBqm6o eNo1S7nX9R3Z6ZB65TsRZx+UQCdhdn3mW7VbRrPgYzbLLOlkRKOsUwPgg2YS0fy4Vuilx5log0qh A2JEOwBPpi+J7kP28ttg3mMs7EUEyfL9KZ5Bgz/V3kCj1x5ZfuqGkY5iD68Ep9+cNCeZz3tWB3Q5 u9zbKuYYIKQawiHuqXgnH1nGRujTHBmI4NYB9+UpgtUAhbwhgyJOLlREr2Mw4WPv6u+5JIo/aRiA axcoXZp9ZQbdhYcvQILsYw2QoD3S9i+ET9d6ogBhA+4tfipPw13zgwVhS268lOfYLNxRj0IzX4BV 8NDR5gYHKzVxgFaoSLKRtzFLDVIyoB2yaI0mqsRpJZRYHpCsE/XDlNxfmd/8YEuN9XdQw8yF5dOf hX2zPRMjmRV0brGIkWQlY5WWuanREJI2fXZo0ZjQ3J0lLu+XzLiCzgoLIy5NpPQrKCgSf+QQ+NUN kErZFVY9h5R+xLN+MWO0ZUUea6gwN8wN6+amsNO8KetY8MpyCoe2cEfcGDKOWuNAc/Y81kpRJO5A VvBRwRGGv7KIHew2bvNACtOSYAkBDZLTadSAtYeY7YTauDwVSA5HfbCgsAx2Jbqij+mMRX1nMRS1 vmsdXG8kyDOGs/Hj0SCU4aagQSokrGQhb5MDAhnJbh9iuGZxocBtUbmyxjgghO+5sHPol9GhL6t4 yqdfOp8esMXi9I9LBaWNKy9jcLSlGRUw/WJkoKtaae5BnihbtUPF58JoHgXMaOepVzKdH3gwh3UD BMlLTiDkCjRFAtA1Jsai9jwH+iNo6Y0dzc9DLrX/Ci7V8NXPmbQqlY4DfdP6MJy0v3W3bgNGGHiT vNYdnnx0ym5ZR08cUYbC3r/D/WvwtMPQvB550Aa28fujNO19YNSdvg2nh5fkyKU0Aoh/sRy5GEcv N1C8nOKEbgGFjWZk2ReX1p45ylO4EtF0YiqbkBfHyWv0sUZsHIUcYXLTSfWt/b3h7gWttpVVHew+ +AEyHAYzqvCirnE7QTBUOCPEbMXw9wIe5wfZmBCihS8S+bXBB9ii9o1UIABweLEC/iND8+UjOAxK Yi9XDqSoUJcRlPb990WG5oY5Wi2lXf1mCwd7d2bXi+1jzM+Q0qw75uRJtMcxLujxzRAK8FVi91ec 3u1DXEgJWDhufRRI3d+x3ZbRSLMBLTiKjnSTjFsfkIgIuKThkxsve9aBmzdv9ibrVzKhjv69p9LB 9tc4GK9H0vP/I9V2CQOimMkqY4Emwyn4gHXt0qy1UVBNS+WBFHWrVfxNTUaH2LWzjn0IWREFK+o5 buPa6npBxg5IktxoCHklnORE+SzHpBInyAmYDrJHdtKjvmOzrGlCmdRPzQUcyEEtZ3ETyhRvkkl+ nEnNgjSgnBYYCmkfwZnvQEZLn9+CFnUCoF80YgrxIADlfoX8H7Hw4UH7bbTHq+bFiwWWvpIaNsx3 /t77r3vH/Pg4bBod2b0ajUDhmuCOc5VSTCDwMZCzWj5rbG7VsIrh0Vuw0lSLbHBpeM7csUgm8JDm ZqcMobN4KthMYWZ/UbnkheKpEjtfelA8jqT1mc4xqwhG03qmylw7yrKp9TwRpdv8YAZLPpUN1Jun 5JMv2P25FF/FsJ78Ax8m8lcyDoVXfVITgB71PvXdKChdmdmT21KagBJeGiReIk77W17tgHWe2tne wW3qwKMWViMM3JxLZy9RMZT4ezuYtmyaz9AXQckC4qyD99GI2z4lFjOYWvLbZ4F8na2wOk07lBuM Gbs3ElRbYy/ytwyEniwvQVcVTTBet549dd2xxWOixHV065U2ibwKGo1Oo0tcEzKy4kTpwIKCITUk fTnH5wKNYRmspQ3nhefRxKPBOZZCSxzNG/OO+C1JSpZomyiyh7GgOKAUb881XK7n1kF7+2otg+qo glqWOcz2OUuh+0q9uBmmkDgVXSMznALDMhk9cJOvPQTYLoxxhZ3pVOIru5LkCtpje9o0dEFoNlgN clOIaKU5W6VLC3OVoOh8NkvszlZdZkc/rfSsYSmGaLJI17gGzWJL5RzZ+oVDWypwicZ91tTEkYG7 8qLcPtX2Y+SmKTX4VP13yyRw87OazlnhUuPYDTS/TxOj9DgoOS0Msw/gaEmz6spaOqIlbz6+khO3 NakILXztuTU5vSPWrQLl9gF9K84vqIdjsgw1m6OmWFWori9yILef0fe1ItY25ooGTlXtaMjaVPNQ xhoPoQvH6tIHggIiDeyJ9eHeHeD4SH5nlZw70CtQtiWoWuQhMpJ/5jrYNAaoA0G+8ttjHYzAqI4n tdtRh9EeyeisIvMiaskS1jINXGhT5xOEVXFoSQQHXUzRFWc3XlxLKU8c5llu7MR3UzAhT5qkw0PV PKu9zDuXivHG1aoyLXX2JVaq69wfIiy7SZT1EXJqZnENakFDIV5/W/fEkYnGt9Jb2Y2eElmGok9y 088//2vaKznoFQTjQAQNMjKc8wiFmraswJbF+ESVboFZ2wJn7xfXuG3LcjgrSIUDr7gbo8yCqbNS WjMr3ET+Xf3puDBY2mmLNZbbsGfTXXw4pvGkkLTBl2yytWEU/+EhLn63fnGxfIbN2PKZzLI2S1AF nVb825KfjGU2X3YYYPZYv0KVMzq//OSzIGw8A/oBMgMgsHAsCUKNpaQnlaFcAeLgO8FQgdJhlh7T QDUCGD3Bkw+7AC8tMHdZHX7NjRJ8DbWluU63kB+/TiQp9axEymdSPdDdXbEqC+jPJRBWlAbc4dXc 4NPjypjGEBu0Fn4C59XWTeLY+MBijRX/+AYNuTwoj2Cu1HqxN9w8UtTjwmw1heZlikgBqVDElLnL JuQwr7nr1XyVPcWAGDO6jUgDJ2PkpFuyIS9ovkCJQD8LmGKTAR/v9EoUCsRUr+6Ya0StclcS7JD2 cK1eCXoRq+LhAv825IDiaQCp6Nzu+X8hh6uA3Lna3HyRFkemWc6JhQyZv/yYdR63ThhkAzH+P2MA qRJ9lgHw1HwkpQA4pRGGEnROuGuw+Td1XitJBgAK7j5y0dIw0Zcok+RrtyyusDBTJc9FE18mgNS4 VgLUVYKpZVnN+ydaUDgnM/G1mEDDbSNtEhwQVlV0pK8uS0pPRZ9zKM2VSyUZSizIIxsroz0m0ccY q+BoIcqDIGEBnwBFedMwcKz81bQEQmUiXFF1VjpV/bc5aSuKjdb5uuxKtWonvV8oCqC0o4dqnoWm pel74i1LFTDIwfjNQ6XHIgu+g75fkm7YtHhizMV/qjF41Ff3LbWvwgyDsWLtVQURnFVTzRWbqkz3 RZzA1soJ2/gatKSMN8klzSutWR8zpP6qphMzY2/MUDw44mSW+FuzMIlirK8SSZXhiiDfqcb7DdUq WBp3KacWadbKNyghvG7aH0BP6ogSkApTeHn6xfhEaYcN0z7S6IYWpoIk6W8X0X7VxnSGlOgKUv09 baLKcitt/OWcmimv5cjhAiwb40R/P4F0UIs4Us+lFx16OFvfAkpykhh2LWQfY2WzMlxK9Slgzkfw zFFP/w1IoAqKhXMUiPUTJBssGSJQvqQxA7lv24dWsoigt9rcLmCncBdvweBOA15/SWoOxVRV+wbj a3N7axQuLOPVrUt1sWz9s9LSflJlAcPfqmZEbOqhWtcgGMIH5fqkvyrircLpJbxLolBuW6Iq7yGk xl+oujQbfdahrJohz57q7Ea5F5eXCSTVzlbFPJW51f6TiAMZPiha+eqVTbXHM9XrrXSlvcvvSurQ 6HpiHyyp0eexzNRHFjfV/humqBY9C7u8DtnfvK/6z2is1HmmDWYht8NvSuJJ24B1W7UmqsD62rYj y0MKW5Ruy9Wv0kTqoIUqii3ZMrOh1FCYBDg7H0Edkz+4ZUFzTuqi4abx8wlGqPehqo5NkrhDoFil 2TIDrdLjYbS6jpVhSOJuQ6qDy1qGxGFNhJk6p+TBjqkzqdbWGRCKwPSBTgg2RUo4lZxLCTdROKgP 3TSP3EExYh5wqwPiHaCM5yhFyeVekurl1tFsBLhKXvxwt7MCbX1h+LkTXb93ojX2OVaXz6o4KGS6 chWJTP5Senycnuc6ptSsztzWa1AYaF0UU+o9Xaap7dfq/mgZk4LvvcqjHfLXquvE74yBapaNsyVt aZGUcUCOlF9y0tbOIOiqz9UVogCJUtXrtTKSY1pMCtMnlS5D7J0DuqbmoYxKpB2+HcdKw4cXIyQ/ RkrIGlXEJdsG9WWpLA9G3k0ZHZNjVqn+0hsH+KZRxkAI2uGtGfuFAo7u9jnfi1Lz3g2jqprW5l09 HrhIXfJTxIzt+C5YyWi0lV2P2GSogW8C7He5/DZXy7TlScFOJEmKS5faGgtqivBEEoO4HHDPnXYW KYdYGhf5PKDT8e4nVfBkm5apadKVL6uVG8pUhEvp6lRvEyvCcBENX5Dtql+rmq5vUFpntG6qv+Wy aVvL+iiNPavWz12bag4s/N1P0CwlneUyWlr7dJb3Z7sU33y36/o+vzEASpQK3dzLpkuXbnjSRbFV yZSQioha01xbr/IcD+LG56E4dzmm8Ox2QFNovVc409TNSdX1E8ZvVpH/DeRaCwjXfXNUL5xAI3lZ hVVP8c1qbXZ233boAY9sR5cafutKPx5QaHIzQL81QSNZViekaNKm3qnQ5NU5TT/PbU+rdBIPKS8p WOUZXgWof8+qOFobpV681et/JvbjQmai0OSiwKE+3N/kY36dVe3TjZF+G1T1gXKpvRVSt2VFxODF Ojhu2KIw9TToopGaml7VHWsnUGPHYknDbIIuqCH6ioKHLDkp2G+8KLmnowuq+pe9WbqMUEun7E75 /MSAteVUv6dzU6XUPn/mVhFRxK0jbtW1n50I0vVyPxIl1l+6uqe2YpD98xtmxV31nfzk4mRsB9YV 1rKQ+RW+3ikWz1SmKx2PqTO5WzGw8x7Tcj2do9s4hJpcB1SkcrHsaHyvYHd15cWgznhd4iUjJe7I 4KBs+OLBEiitDsVKPpzlfMXW6yzbEKl6GuUm5dXAm0JKBEnFc5RXShadK5Kskc77zvMTNJrcqeB6 eaoJU68zBaSZzu29vtTL62Cn4AhfPz6p+JewLWvEcnSYxLhRYC61mTwgdTLHmfc+qfriAqX6Xi9w kTz5y5Ucg5XSb+Xo7KzUvz0/zVIc9WhF6wmQzoS0S1+beDza6rKCmJX431pfu42YifPeXyHOv6A8 xe1lOKnvSxy4++1V8ZczLSNieTZGB/eyGVs9FdMj5yQdYGOFxl67mDKzEGuFn10IQQFErie+v0q6 2RWD47LzGdpVUEG/Zsu5GuQy+Jo+9eaK9djnmbk8v57+cfrl64//5s3pb/88/fLzN7edbn8//frj fwGgtV+JCmVuZHN0cmVhbQplbmRvYmoKCjI4IDAgb2JqCjQ5MTIKZW5kb2JqCgoyOSAwIG9iago8 PC9UeXBlL1hPYmplY3QKL1N1YnR5cGUvRm9ybQovQkJveFsgLTkwIDMzMiA1NTggMzMyLjEgXQov R3JvdXA8PC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0IvSyB0cnVlPj4KL0xlbmd0aCAyNQov RmlsdGVyL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp4nCtUMFAwBOKidC6nEC7XEK5ALgApxgQECmVu ZHN0cmVhbQplbmRvYmoKCjMwIDAgb2JqCjw8L0NBIDAuNQogICAvY2EgMC41Cj4+CmVuZG9iagoK MzIgMCBvYmoKPDwvTGVuZ3RoIDMzIDAgUi9GaWx0ZXIvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJyl XUuPIzlyvvev0HmBquE7k0BBQEmqMuDbYBvYg7G3fQA+2NjxwX/fjGCQEXxkSmxPY1pSJpNJBoMR X7zY6l1f/vfHvy7q8qbSVxe293AJIaTvf/z9x1/+dPmvH/oCf/745w+v3uNFb+/7xe46NfDRvpvU 7PKPP0EP79puxsOni0rDZ1DbDg/efv7w+hKUTn3//Nvlt29z0ery8x//8WHDVSvzocLVfpibvl/f zIcO8DdeUnv6Gj+UyR+eGnynv0O9GrH5Z2quVf5BPcAldYO/vvD3rk1u9ri+2dqrpl6xpRyBNmls dMX48t2Z+mLsNQ3/lscah8HP5vBIQ/jrz3//8fXzx++vUM1HWJeWakbDaIzDzuANaeJflTKKSKNi Hoc2Zd6GWgny7NQwPaBj/DCpA/vh/DV8uHu+VPpK3WTi3K6RqIIUDUTR2o2LH1ZdzYdXClopW3vH cSxNftvffTd5eqXycjIwAB/yAPwW61TzuhVOePN7qE3yehmnI/w2/GihJfMVsRizkvbd6270ur2y HBKcCV17W5p+2PrJf11tWnl7fYvAX7Hrv77wLUw5H5bbEutbHQUtA9wI9QY8pw29Dn5Y4nubeNjg xqCub3At8L0bb7tMDZc3VhT7Qqs1Mnj/7npCqPIeY2k/DMxN78yXb0r8So+FdN+uDcPZJP9wGLrK r6/r9qE22DTqW7lr5vXKMR53HX6NqWE3b/zD3VvzbrtZuq8rrp5XTt/0nua2fViP/WXh5F6fQQSZ Ll5iKyl1IlREroF+0xrlpU6XNg1LqDXdKy3u+G4rruVn1NdI0vTf8MlzNippk04lgOzIq0jr6iQr R7E3i+hxJKbwE9uGURuQSM6XQJBHww91CsKjEHh5JnpXSUx5497rfvUwL5iNveoNpP7XVe8fa51G 7HSkkPvsd7a28KI3TyLY7enTpe23tBYqJm3evkl95x1M78o/834qAiVfg+/uRssBGgBFfpIHbr+a uhykMLVfooONiaxeW1aDh8TVaxROgMZN542zIKWtE1Ht4xqK7CCmLOI0SpzxCZMPPHkPsiAJUaNA MHrZ+uVRGrPDKE/mD/O2axvPxe291y3qYQxs6rJ8hnaV9rEBNLSfKuDQPlTFj4iEaeBRnfJDBUNU rKW9qc8SnSxR9VC3CVCXVVR6ihWf3sRoSHIUaZG0Imm0sEatPYwYbGO46DN5+F1TILsTYNgTYEiz RA3pikRKOGQyv51wCTxSdCd3qkfx1hJYSMlMpfvatDc3APY0XsnuNguCStik4d7y7kiAjxYioHzd ynB9BQGM5uuiBcDjDLvl3OCNdmvbZv14y7yJwyDAV4Qj7OONcal2huCIx/Ub8dg5QUKvoLPhIlkB Jk6ANwElBkk6lKsjsGy1D4r3ZAyJuRf5y09ay5uEBW99cxVPfKnSuxmi3GaedWcm0syWWaKX1wN8 t8AhfssSBo06fmEGjAsSfLepfyfhYSsaV6RiUrd2OmI0bohi8Pkc7KelbKBn+huETnn+dP1TkyCJ 0xgPZLCVwXCLFYUCC5N0apwj6jyruekMVoXJDZhJPIn2O4rjdJ+ZHtAwMXU1xLJlgj1JbYL9fVfo 5qUcPULr51NEtdlO0RuwFhr9ddONHYlCN8vcrdV6yithwtzKPqW5fHYzEbsKxHcsPWpa0PSaENvX RIa3TA3t0+Z+I6s1PNOmpm5yHPQSuXQYcKbUazo7Z6ypbDw6ISRdmQny0qVHYxXbCPEP6Vp8Cnlh HL+RN4DhDaB3ZkgQbfJeZ6gu0UP5wRprWbmYldVZ4Is9IVdRD1/LJHyxWT5OdhT3KXUJAS5QaOCM ORNHwGi1j1bybHVz50HT2D8Ffy3qRxvtiCo7z9MmR1FsgqK9k7jI+MyBdsNRmCIossImKq3LA7ub 0by5o63+WXsfBlkFeLLDsrcHvSYJrX3DtcDXyqR0L9Xz/dpuZQOTjMlmhAIngCrsszT1TY047rui wt4yyRPQc6Dx8ntjSO+0CUH6UTVXu+V1U025+TTMKKSyFlqSTkvU9HEwBoiRQsHDRZeBOg+kzt0z 5AC3aK+aYbM2DGWKhfbUvpozlLDjYfGFJ81Z3IYSZ6YfS+Rx24Cgkh1G9NdftJvP1F0g99NE/9Cd Rd2D1PLqVO/wW6XS2KXkLq7fJXLYnmU7fFR+SgEUq/QdEVSBLQ1ul3DjhLVbh6M1bnSruqtLxteu v1tAU9UYe4lLMOPNanHlFDEVThROaMO++jmxszuam55pYNPLlG7C2oyo18gtyRKw2KitIzxbuuBI IFgSdKx2U9lPeSBu6jLZwNw9GKEOEF+zEohNRObg4mp6iNjDOM3skbK/5GTBlTmlq9JHWClxiPAU lABSjqMRLEGcJsQWITlqi8NFP47Pe9kR5+z0Cc/bzwbnlT4e+W5pdSJQHfEYfk4tqnbGJhmLA1p+ BsXIX9pwbTGspA/tzMAS7rLWAXXgdroJZ1xxzzVLOxJYFzcV4vRYeR9FJK3TN4pLIvIJmbZ9dK2+ gFgdmRluDqz2+cKRbYUkhU40dzKI2EJ3R7LLaRIu7ZUn+vpk5iEMSLhxE0orl9ek3X5vjkK5do8f /bNVraO59GYjN4Vw0TDa/BB65+qaAwEpZJCf03vrOGS/3v1sst6PiOiJxy8047rl8FjnG66sh9bA CxrNODsgRP15DW1okC2ObIgFssRC8XN3/rwQ+P6RBeVIEe8q8e4186Z87tydp09hdjdHO+yopwhQ BOxhUauHSU8xlvl1G7/Y3ulRbxESP5eHg1H/qgw2agSao3yDxADyv/jYmdElG2BHGA2+eNpfqWmo j7wq2LMFW8NhyDq0u3AEw9iEIDuZptoHbV4C6zsEKuVuBndIkQhJ7hfB7zAu3wmQSXpD9mR1TyrX KhT2tRwPWsdthJaeAthtwEIm3AhficSOgqfXo/Z690VV16i9sVdDcXm96QeG6el9Nk8SlM3dAgk0 CoU3iIXBPa2RrTEsngP799K8aQyiFluH8iJqjUgFcwQS1ubr2Eea9T0HHHEBIelmvxZzjBpCjgEM LHKjNFIcmhtTDJ5SJxnotqMOzQeTGSxTBn13eXdgRBDSHTK4oCtpEWtWzQN5yYNJiR2JwVOCxI0V Oqx+Ghd3/doARL+RaVgwQt6Gb9hPhldlmA+MLxlSTUNI7JxewRS9roWHKwAbPDjxAzlnM7RE8OVV 4uD+ghFvhbLYjWCb+iYkzT3nmLhCIWKD9HVpWl4XoFanhayX2T0NcCucX8ZATJ8HfE8dtENAL0zQ Gw0wfRgeNG3tPOPPyuHqC/eiVkkFD97r8/HbOKYWHhoFIJN7xwvbj1vBJzXiIY2/qrNLhhX3gXgT lbGETQhjskAOh8a8r1ow5vehRK+wfj/EP08JY/YRmoH0m8WVIroj2twujPhYDrGikDKNLptTshC6 STHDqI+0OwrZJsHtJhuU4W5Nf1rxwuhkVA9hvbRPFKvqvVo9r+P06qPghyW+IHixz0zPXQBkTqXg J4rWTRPf86QpLGXQLHuzW2mZPXqUYcOOvRXvKlBItfRBIyIp3l0ZH5xLkPTnf77cWbSj9mcYjkYp eZG07ULQIu/GvuZO0tL0/e66dijrBSUxTF5CUZCiY9rfZ8Y3+XygecHcJa2C9HMd8RLtdz36a8ry 7ziBGw1+zVO9qcEtk1B5eAHL9tGPTdUA5GEIqaTDFkM61KBlt8DcUG6WEMRVmaqTYxFgXmz8IIS1 tjomfMCLICklbe+VSRajf34f3TtdHFsieZRgAq/ejpxXcVVwuW10oMBO0iJvG5Ozb/2Vo3ShxgBU UaazNapsHHwx0GqC9+LGDF1kl/wzMAi3RhXrB+fK2b4lyam36b4tNghmy5Ag1zU/XLnGdJdzUjsn KuHDGz9sv5LMdNaVpAdNkh3uJR1rKb81iydKAFM7/L9ECOMG7U7aazSyDJMbJPqV00hUifqa1tvd ul1qBB+5JpS0zqzYjWGOQs0hSCYT9PLGvnXZHUV/BcEwGUf7a+OPWOETk/aOnRadPGECmSCfZdwR D1gaGrTMNK3BCv2Epk22fc+83yKnXnR0ALQWlEKmyaykhNDQ4UzJIwu0oZkWKtl2gA0FbVaw1vDv ESDbwH2X/BjFeqV5kdDn5/6IV8gwKS5BjbTNPIWmLZ6pesv0eX3wvItXWaGkPXqe80ciH13OH5T1 VbtpNs/BW52V+X4ACb+wb3fPH8777hUL2UBEnaH2ZBzY1o8LMzRXXzSp7ngJplQoki2r51iR0tMI UxG+oicOCA0Gb7uuq7PjopHOABtEUFW0NVHYn4W2ZKuXXJRMr53A1t5ldh9HbKt0XJ3+pKgFVmBG /a11Awo5YOreGOM4BKoOkl4ztb5l+q39ahpM0k+LPq+NFjI+66hXCTWp85CVBvxSPwK0LD1qJuMj cbnLRHrqb9CRG3EyAvppT8Qfy2ebX7Pib6IJc9kF+2UdQNsHOZHQ3zRm8D7reFbaYKEKJSOsgrZQ BiAqRdTF0C9KRhIXzQ20o5EaqMTpaqp7dvzGRj+3LnYrvAay97UdvEqSSf2CQFwvlVmV2B34HouZ YckQkBOVUyzGMD+R3ehY7uDLWgwReYLNIswrn2+K/UokcZZN9pQqk/IGI1HWaBo1M7QUjLfmQDBV 2JOrjKXamdVscI1xKbY0oSmlzXJf9poMie8u/1hs3WIE5buPZfqM1Q4opG8jR7LbqSdURjc1nIYe MjBVfTHm96Xq2aanKdFlxz15VgkwKQaYmstmLC9t6aHZVQLuFEe+fLKVyMkLPZQq21gLXGu34pYp aob3Dwt4X9tRelYovzOlHIgeSiBk7xvl5LUuyVHfPyXZpLCgzUsrrELDBAQiC36+S5YJZz5n945j /1AOSuPaer5qs/1MWRz1+mBZQpNZYb+puRShplc3a+ibNOkgvAwjun5Kp0l1woG4KUEBKs/Yyvao 7viVkAC9fZLsL+SMjjnOA/opUcTV4h82zXU0rLpO2dEoUzurXk0Z261Kohw2gK/N4Aax4Y0zI8Y1 65xMq4SYZPn350lsc5mWhXFghkBQnzrMDhFXecg8QN9BoVo+XCFrN4C+VAPQSHi6y7Y0lwk0kRQu AcBTMbYmqWas83tGiGnmflmtJLCJ5MSLWQ+cHHzRrEqX3LMYxKLxTbL3z+lmCFyZraOcofpBuDGn XbpluMkiTmqT78zOL5No55HTnUs5+jo9JrnwXTGkndRC7iTAdoNHfQQqLXAL/GKNOkrrzxV36qwY +6RfqxIHznP8wXzzNTCXAEQmsoOoCIbNSMftJQOZ2LXzEx0ZsU+JPcn4P82M6ghPGol2rI+vpMJM 898wFSbnmjkFLJvQA549UStAXRFITR5pQeIlMLs6/1lKP1cmknsdynFpUDB7GJjPeiT73aOcqhGr YtiyIA2wRdk/qZpNnE6TebYEhPZ67AjoaHGR8c5YgbesK8ZM/v7koG3guOKZzGZ271whBiFjvK1k YdHJgtSuW9mzHH8LSUlTvkDmLExaYBYD8s4HYEZm7+PZLdM3Cn/I8sQsIMP+rcrKvleuqzSY5MPn +EVxcMzKDmQY+kyF18MubEGqTQDaM2worqadLdiaz227YnHRxXkO5uD1fkqNSbJ+n/XKAEvUDtak lAb1oImRwYhWM5UsLDNGMmoupUdLeKvvV9p++5uPPlrpgqnrxdC8qol1Vpnm9UNW9KNQH7ikuiOf ZN6a6n8/EBQiIstRBCkFJjFlL22Z1noRHZl59VQTYfPrmmCW0N8B33o8w/Zk34hQa46WenCBmfvg Dupjq/5+rYbirhpnPsNU2b30GFUZtj73WUp/rXKh/BuUYUSA/gAILa73e1r4DZooPAtXTRE4zDF9 lKWl0GwVVsBATxPetebWQnHKTlh1rlJpVguwBqGbWGzs2Dknh7BPY9idlnfd6e4sAc1f3XGrdJmU JiCQs1/+dlqX2JQGyey8eG2Pz9nZpY3JQt2ecAU/CrbxIqPjGBXIZv8vTTzWLrygh4t+9U/kied2 L4QCSbFhQvAL0R3eO4FpcVxQtkqXWSnDl/Q85DzMNjezT0OUSYrmtKgyQdHDpP6StDmJGsk0rldL Tl+Z/azCocsvcezEFCLVhl7nb7Jpk50XKpix2VkoKjWaUwhc3ykjVrrXAh1nqytVp83MQmvcr4uE mVZRvJaLbFURg5E4qRbHPa71ZC/wkXgNlM6ALZlvhhJLTVtyJs0Q33Ywjccws8lwxJW9Muw35B0n VqT0sEoxLvaQOloGm4a0OFjXjXT2Zg+iChvpxs1ktOKDuFa4ckM6baRZwhZP8fDq1LhS4xdLarhi UFaSkuu8DW2NrofX/TgOctK0BIrzKuYFAGY9WLFTCthW8tfkyOZiNsuKHoUZR5bq1WcISTsJo5nl 8KooCpE5ZnTS2E65u+CTLHBmEkB4M54PipCR/1lc6ThHj9QTnozDCe4N4BLu63qQhGPpJa8xW6+S hAtKzvy1Q7LF4XnM24SVK9KzK35GY3B8fjxOscpvCn+Y/WPF42KtSx3NZn4QN63jbxM9asDSv7j2 RQ/qYo+zNYnB1tW1mxTT1JJixNs76tlSKK3GE4HlvaaOQmQVPkT1tmqP/WuXfibGanG3os2c7Bg+ t6EFO7+YNDEtnXla1Wwy/MoHiTTGXdWER35dlGVAkKySu5zKSL22+pogTZM/Uo8PycthSF+tTn9S MiO0nJERl+bQ0+zfUGI5pEPLRAkaZ6RAMSz6y8vb4UHZgGYtC4r43GqwoeX5Cia2mHco1YLBUnxe 5/P1Ch5YJaA6JV+DyEUqV8iHXEpnQTv3Nhen2vJlIxwfZz8W1Er3EVJJvLXoiuY4nCDatFnjbebH ssyZVAydqIuc+zrL1xIXhfdfXn6OmcaAdKxH+X5SzKw51T7niKNpvaMxujj5Sf3PaWjhuR8+y5xA 3lM82AAVQyhFMn7mVxb/iEAI3HAWB0Y8szjNSTkSC9E7mUhiovK0XtCJgE18h01I3xgSL0YYiNWG qBJbsW1REqzYipcKqlrdxnG/B+Hbl4ngkpGvLwnDTnAxRU4XIDEkkOwjSUF4tIV6T/MwJ6VOTmsU SPcawsMsdm1F5rotqY5HcT0R3OPUJdUocsHSk39fIyeKidctpIkFYSh76RBg43nBpin5giOwE3Ww RwJdnldMx2N7vnKUFFAdVPDUHQvMQYtiVqwu/9IGhFyNtva7s3eeB1vp6nIgfKy7mnuy+yqJwOFP grb9ObFLTuJcln1EOnPgwVqYr1PbRcLgwYR9rDgnnJ5SL0d017brpOIrH7E/O4Ks5Eng3trKish/ yqOc9NZ735s2U1Iyr4MrtjjdOOvQ8BUseOuOabdlV5pGkleS/n751+W3r3/7s/WXf/7P5beff1h3 efz35fcf/wd1BFN+CmVuZHN0cmVhbQplbmRvYmoKCjMzIDAgb2JqCjU1NDQKZW5kb2JqCgozNCAw IG9iago8PC9UeXBlL1hPYmplY3QKL1N1YnR5cGUvRm9ybQovQkJveFsgLTkwIDMzMiA1NTggMzMy LjEgXQovR3JvdXA8PC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0IvSyB0cnVlPj4KL0xlbmd0 aCAyNQovRmlsdGVyL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp4nCtUMFAwBOKidC6nEC7XEK5ALgAp xgQECmVuZHN0cmVhbQplbmRvYmoKCjM1IDAgb2JqCjw8L0NBIDAuNQogICAvY2EgMC41Cj4+CmVu ZG9iagoKMzcgMCBvYmoKPDwvTGVuZ3RoIDM4IDAgUi9GaWx0ZXIvRmxhdGVEZWNvZGU+PgpzdHJl YW0KeJy1XMmOI7kRvddX6DyAarhnJlAQUKrFgG8DN+CDMTd75mZjxgf/vrnESlIqsT1GA61uZSaT DMby4kVQ5tme/vP028mczib/M6TtOZ1SSvnfv//j6a8/nP75ZE/lz++/PkXzfJzs9ryf/G7zDfHw zy7fdvrlhzLCs/Wbi+UzHMaWz2S2vTx4/fYU7SkZm8f+9vfTj5/uZM3p2y9/ezEfl7N7sc66izXw P5Mu/sUe9cJb/fvzcg4uvRhXPo8X+3Hx+eZwOed/R9Pu3M31EvNzPt/jj3avzddfLylfbA/SAAe/ J7aPVL95zf80O0xDPmTrW52Bh/KEEk7uuPz87c9PH9+efnpECPEoYtZCsMaFPHsP7/8sf8EUrKvf 2ff836PNxW3Hi9vLPWUq9Tkb2/zrjA7XbtsPWuErCRTkbWAxbb2Xszc8tnnPX+fHEw2TR7jSnNy1 CTyLP+8YyC3YDUZfksW2P8deFnsdtgmYtylLIvF/6przWkNsaw3hKO/eeBvzV4kvHfCt9WrrTRnB 8G1KFeQG8Gj+IJWFzyj0LYD0loSQtk4EzhYROG8NTRzXTC+V+op7k2DnU97E/CyvJZtXVVWSW9rE ndemHhGGTvy3Hr5Io8gibYkfjmJDrnnopZXH+Bx6f/Aqd2DTWtuUwpHWSpNuQhOPo6xcFJ5lN3WM uqWeHYqQs3VOuqJr5xuu+sG8/tBMifSqTBE9xZI0gs/etdOEDc1c2HfZMekcY3F5HkRRP/0Fpuuu WQ/E1nlwor5bM9g3bOXZh/ltqCk2Vn+lh2vC61UG9syvicK7Z9+JIuwXHRl2kvLZ2TYPe4DLq3ID 8SRw0htJL/9tmtXb6tzyYuqQLmTfBgq9S0XEnXcm0WPSWshFW3DRdVy0XnBfji3FLIYMZ3LI7dzk 9YJzaLGAwoecEu7dOYLKYux0vsTOvMp8h1V3Tx1L8xa+CMvuykPA4mQ8ra+B+w14lbwhZ1SqA5TC VB0S3zblkfZqF03IHBmPdCZEkRJ9VVtm2a0aIst21ZDaOxCYAoY74Q8mnqX3Uxbjp+U4XEeF1wTp Vg8xAjoQv+xAwrE93wgloUYlhDZ5wyWCamva66zBkHZEAQf/vzqVkDe0iFFccG9NZhBwtk45clSg hcFD8XjxKc/LEZjqjBVxVTXZJRHsaQBXpIAcxbLWwc6HY1hZOBJdcunCSEA4HxH6Dx7Ivee73Uf5 qwDWw9OVrESPmurScrcwAGqw0E0baPv4bKaQFaypLqPr6qLPdSlLE0i9m24Sq28DNGXgLQXBJkCZ CeIFWBD5V0AW5bpzgASF1dgpCHRDrlBBQhLjxTIeWXAen78XqL4oxtFFWvW/uCacaEd0qzKXAkAt phTFIdkmn1EpLUYe84hSYhQyvU5a4+nKkk/ifczOHj7XhOGPAd14k6cVjcnj+RcfJExjWVjGIKBV YrPr+slr1VtTc9D146MbJhAc3sEA9rycHa66dnf2S9UU2laVJ2xvoy3K0UMOYteSPNw+YF9HSFyk IdVcjbOAUOqsmwQKbsmwokKx5MmA/euFdEoCkIJO8uXbyQUmnw0f+wYsl9Zk04hTSvrNlhcYh3w3 gDEXrREKWlGqw2qKcKR8BEEW+FG9g6O3RNQWUiVGNcKXLMnHxAHW6tS/wCQLMrI3IVH525cbQf/y p7dFzHOUg7fl8aItrqPZWzG+wejEkHWRMqNWE3s8oDGcWSMH/OEHOKMgNHsBtZf0vnIxOsdxXujM O+ZFxIOco+W430zh4PwTEE5+JBoekWzps3wvYIM3ezPORa/gdzcCWEeQu3grh7q7T52Zo2ASDSMT tJAB4CghlNVZXt3/CbT4zYws4GIsmqAAa4HTyNFgCcyTnuYHQcFtFCzPq07BO2JuMQz6eIwA9V1w imLiLYk9Rmn7MdtI5Nk7f470KOB+9iR1oxu5VR4GrI4YYuJQVZBZW3TYRiCEtGw8MCd4mJTlRxBj CjpWMjYQHijtB64vHg8yronnNmdAkf2s5vc9DKj3A35f4T91nPMgGJ8OIjBQS8tyPKyn3pfEVXKd HizAVwAuUoQ4+lv+J+YVEiSiG1oShgsjJjouxGDXvSmqu4Olb2uByEI6UJ5b9DikRaRpchLf420o Ki56T+seZgmlQTWOklQlz5lBVSSgcZ9fdmCFQLpH1BGGdwKlQdHhU30pwxC/fFRwdDrLENQbe4M5 VArkHSEZhLrm/srJ427IXslxHGMBcJouNF6WEBXxskNJ5paoYX44z9W6gtuPAY37kjqC50PWU9iH SDKr0HqosUPmiLllEFUkmSgNGtOldKajlzgdjdIv6YpVTZV12WpJHNs+QKv8niDSiYfIBf8iEwuA WPvR4e5YwSdCRaLTFPTq/dToLQaOmb5VQ0+Y6CXJpDTyhlfp5AM4OCoSKJmM5AsJKMKOR53EA1d4 Q8iAYvND4CHsPBG6dhY7td8lQcQ4lmaRiS3YrK+7vIvSH3IPsvQQtUb1laN6+7V3eO+6rjXzT9uN xQ7OClV2EZW44AeIPlScJXRQ/FPFiAfSw4IAIMfZ0iqoVs5qNijmrdMoDCC7fEMLf6FQMjvxZzhd zgZdRa46SlpId/bvzumdH5zKkNF78Ku1yC44qCIoLOqXa+HjYklKopA5V28atgzRGL7i3W3wb5TZ w6LLzba7WY16AKxFBnFJAs6M6D5cNuSgotxTnFal7RCOcbaFOK9kNAddxK1BVT5Tqhc1jyywGw+0 wUBJ66KEfhBhutpL2YVrAXqJBnBveW9XMYkz+wDZ6kych1kEYvc4RubPaLAojxIAvmbngqPgIB0l cYTnJTPagh3yX4JHbJUfl+i9jWCmfE+9o6hO4UwXzcQe2wDtQUmC2gqgO2MpacMmRrWvAcgOZEQc WZRKHwsA+4QtxIHcvVp2TYJv17CbIJeWvMcBf+VloQI+xJwxRBZKLRMV4KRcd1/SC0ARVlqIctqa WjWc16d1o0RrYpf4PdybgcBnp0pPIzLW0KrdwgDcG2aynmnHOuXsp4K7utDHvpLR2Mg3/0+kkmY7 hd40peI4KDIuVVQbaBPJw3KHxqodJXejxkvRJrHvc/DK8kmV4EoF0BUUqkrNHKxdPYcVZBk4isjV zV0+SNdWt2NJJtEOyF5YAKfvY937vLGFvRuVESPIHA2TyaKuPUSY61henTBSLZcJ3Le4Md/U6DHe NElGzSraSwLzx1g2NlSOEdoO7kT4m1gKIFgIWaNfgk303B9A+AbAbnU4iaoi8iFLMnH7LezfGFJB 3EiKEZlUlf6XDXMBiojdHttl+jQH8QFgNU4jYPPnnt9X6EcEeVZwUjjhJhUsXjoI6uXWrOS7r985 +o49lNV4yll+ENumCEyIAWpk2r5SpiU5mAFmrtUQE3ij5L+vDaoF0ASuMxU49FlhChbUsvvY6A2Y 6T5iUytiOPyIpJbkwLNqTYGI/AhBqjgmpAHfkBLXR7QEoIBqD8L9aK+bGqR9a7jzgQZk4M7vAC/Y MkSAzEsy2+2IwB93eOCWH2KbSxwAkmfT8ZATt52uT5jPJm9DyS/f3PcFKOI9+k32V9lQk4oVGW1m AGBtmbLTpKC8PBnbCilb22diCe+xaHmTN+AOy2Pou1zf0xP8eG91JEbRY9G5PsYvNlXuAzoX3hs9 W6sBz32BL3+6IwKBnWEAcrhexzBdBNe3XeykeSHwI7X/qQ5KjNEf1lAatrHKHLjsNHK4oue6zOcB M7jRaNiw8FrFdAC8/v1iXTMlB8lBCWcljIn45A4lKXWr//Cf4S12txMFpKkKiny+G9leR3fZciDY eufu4ec1Rm4sGwNv2FVuZOYmi/sCgqwhEJe1xU/P7oQ3/xljTNQag1zNpkTIBYBEjTiOqIiCk/hx NHXkNzhbffRlKm1WqKwv6wbaxv50hOMXqHxmUWazoz4mMq0JaOSYIF3dm+IFwwplR93jcKNyoJja mvdxhqHIrtb4+EajR3LQyoS2pN99IytcATQgqclBoHvLY/2+5WI4w7WHJDmw9DCUrGtW7PmZDtiM yqwQtDGhdRLKb6dlYassclVOw1kh2AA+CxESn1TSbT9eXIjZJsD8Cl+tKhleUOoq4sABJ7zn1oGb Opi8UYKgz+UlTw4Jqda0G76uKPfe4lmGRqsvnZ3F+Szc3W19ANNKHHbMpIJBLi2NELl33716iidd 4wQOxVY3I907I8UeFaSHix2zD/mOqgeIaHJGBzuOCoAKfVPyRgWbRrUIYKt78ThvsobKM9yAszFK wTHaaZtKgEGd8Eq1oPIhTyr2uLlrbBHgfa3iDlKZHNUpSI5pat5VnRFVzporWWXyGWjJ3UVt2Slh YjN10xypU/z6R812dl6mUqxv6Dg4cE5crmBGnDwyuhHijQLxqkcbz8/l9Op+YctK+3+W0H7hAwMb QAMTzWjusKXCyirew9kkWSK8K4/pCRrqoKLq062Qwx4guovzfKSyKjMbXeu6ixz+a/RQrXCyBqHa sgVqwOY3IQSgMT4wT08rM7ovmsnJmu4wA/WIHAiJeU0eOVF8P2K8GWyVF7iyF5HumzbvvaqTZJiK 7pJnwGNqA/t6f+GTMzY9VwxFfARMI4tMqb/ouDKyX6TvVacOPcmZ9MfsRB+kypBfxWLnCht8199I blqWQ1Vl6QEVGQ4Dgdilu1WtAbAFt3QHe432yXl3Oc5Mkwb1OTiUcAmnOyDBIUN6Yn5Pn+19qTuT E0BOVRlnp63PLoqKitdNmgPMobNMePZcPd4UQ1k98RCMZEWZqPkmOcQDVn5fCJOTP7UguX2XG/Cw kX6/6Qg8xHDfcIMsKQg6tCd1ugd7m/Y7X+us+v7yJwd9ettXh/XcTVng9rkWMIy7FybKbZ90zHbk XcaJ3jq9Y9kyCqVJ3YO1xMEmU89r8tT7UM/QaodehJ4nVGBI4UXuO8N+iGtnMgII9r9IwKwM5rH3 xTA5pCObJugAER/F+GLbonS0zlFhqNQfwKpkpO5rqILN2MTLkixe6tZ/PsA15QUeYeUGscxO44B2 1HYQSaWZaYmyIjxxCxK4+4TXlv3tF86pDecBwjnIopPY/Ds9nbLO9UUtdRTE5IjO3SZBnAAVDt+g ZFhdqGhAciJ/riyr/okWmCs9yc23rYJzlw7qiir3e3fBhbRDJa4xG9Z8IZbZqZ7BxhkE4DRkGJQE j/wC72STgO/aErDTp4UuixeRmuobaQePSpvRwic+j+1wfdcrjEXZ9H2xzM77cHPgTntz5baSWmLJ qWUrf8WD+94cganOooGxrC0mWArf6WdCui7unlywAPJsnOmjHJsOqELrHT70WHY1OwZkOGgwSpSe KmsgdMhOG280imtRrymFn1V1aVCi9e/xRlOufFzWcITnzmFMES5NhnbtVAZlB+mhn5YQ5cUb3kO+ pZlv2yKx8+8qpt+3Qn2Gswpw0lQ8CmZynEe7hF21MHpAa9sDYE3EFHVIQiTEOxizPNbqkViQL8Xy QKvD6Z8LAp8iesEkmSTPXn4hi9mxnRu7p35SolUB5a9VALHyEA8yOQWqf9+iA7ny2hRIzbrd7i98 ciBHdd2O3Za81xpTKZDfvJCqvdLZEWq3x5+Ms+1I7tje8cFtRLXSeuMHAr7CBLOjNuMvtAluqjab vour91ud3IOuaHbGJZrazYhNHvzreUl0SzpUDnlf11dIfZhUnJa/rWAHNpoPXrI2kq26HrOq3kV1 rqF26iJZ2P7Z/aTXFxnY7HxL39TQU0JdFJA+hnIi5VVU87HYR8r1lRNB7Bsh/x2PUdz9bSE5EoXk +zKYHG0R7HH3Wwc1PoKaVva62oCBqotBryFxbt/uen82k/Ml9dSCRlgTCVA5hdmrDdWRU6hHlFFU Q7fKpaJzmBZHPEdB8Z7xqe0Qp+W+wszj2RGs0TAvjqVX+QOEgpySdbYZPXUOUTz3NfUkfzWRqadd MzKQTNxf2+RUyOMWP2E9LG9Gp2E/nX47/fjxp78Ec/r136cfv/3uj9P7v04/Pf0XBHgg9AplbmRz dHJlYW0KZW5kb2JqCgozOCAwIG9iago0NDk1CmVuZG9iagoKMzkgMCBvYmoKPDwvVHlwZS9YT2Jq ZWN0Ci9TdWJ0eXBlL0Zvcm0KL0JCb3hbIC05MCAzMzIgNTU4IDMzMi4xIF0KL0dyb3VwPDwvUy9U cmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCL0sgdHJ1ZT4+Ci9MZW5ndGggMjUKL0ZpbHRlci9GbGF0 ZURlY29kZQo+PgpzdHJlYW0KeJwrVDBQMATionQupxAu1xCuQC4AKcYEBAplbmRzdHJlYW0KZW5k b2JqCgo0MCAwIG9iago8PC9DQSAwLjUKICAgL2NhIDAuNQo+PgplbmRvYmoKCjQyIDAgb2JqCjw8 L0xlbmd0aCA0MyAwIFIvRmlsdGVyL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCniczVrLrts2EN37K7Qu YIccPiQBhoBryw7QXVoDXQRd9RGgaFokXeT3O5wZSpREXTLJxggi+0ri65x5HA6tTrr5cvjUqOao 8Kv17ck33nv8/vmPwy8/NP/Qw/Dv84fD5XFw/tQ1ru9PffP4vXlzh0ar5vHnWd2Gx1+H2+PwbtWg NdkG78/2NsBZXQZzVp16GY7+DG7QKvR0xAedHodjf1YwgDprO3R4NdYNR4OfeNeps1Ghh0750Fjf BoON+buKn/o6HDW+BHDFW9gUNPBgCszN3MKAxtGAMPz6+HGxgpNTuveLdXTdya7WoZzqqQO6wkWr oZc+nZ2vBhcyXVoIi+AGoOlTrgY0gWDVOLRK3tICFPdEK0DURvrQnga3cOGnytIgtFq54wljQjNC BYpv42SPOn43WsZKkJoGYNDCLGx4C9m6WHDhBcIxwU4TerpJEPvt40GhYX1Z4PrT2wOZXd98bMB1 J+A//m5+3hgRW513J7MG/za04VJBXa71ijpkra0iDRsSBRcCJXwV2sh20fwESHnJB3AJ/3u4YRHp TjsZ4mbuSlsrf91dvH9HeOdJSM+OP+HC1IA4C5E9Tp4D2L2SmZKDzW8xm27E5zQXnzJs6AFbIs/d 8wKCobhRLMjQEG5Ey/X7vBPcRd6NCcxuec/w58ypXfNHkwnr0E5m7aflykrt/hSpx/IU7cmVLNOE LvKWeYRK+8z1URdacOntbHpkGAot1SJxOlqmvOllPhR42Db8ZMgcFyRoOGKbTXuKA2jT1kiETfCe DYafxhiGhqj4TmrDXq67vBASRV50B/hZIEa1SN6GmDDbsYaTXPOvjxnJ4pOIgeCYGA/6pDnFA3Nb RwHoBjDhSp7eUYoLncxOmRByn0bB9Ji4sySRXeRpvWXke19E3nZ2lSkD5CuJsEV82+zborTTHVt3 DH9ouZL2OJFJtk2DstxK4qa4QgQ7mDImvsCOueEf5BOT58EMMd8RT4EpLM9hVoKVuCx1hYx7pQeL M5RrsAQLu2QxVOXMaj0+L5Dl9So3BnWxUXQZujYNq4OWWOfCO15LbxLQIA1oOpscuX/bBqnIdLzM 7sEkc6AbDYqiNmgtG/JZ2kJiBOsldie9L3IYhjIVymaT3YIKE4TQCtGxXuZk23+rzBEnYmBXHiQx ngVlEm/maINec6v3siBaWKSmSl64BKWdp14m38AuWMDiesw+MwRHmRntUQoUmNEOd0V7zNSm+Wwv 38+PC4KS/gvoWR4y6QYfurhliNJ29hnZCBh0SId6n4U/v0fSH5OTR8HqXbfPAC24zIAxBfxNv7Hr gP2S/B3UM20ro1Q0U5Lw3xCqdiW8ZHU/PUgSvPT1kuQcM0Q2o3ya9owiyd0oX/jDpXrgwtIetvts fZHPmJH2eAwQViSbvphsjO/WxQPksJhqts2eJtXAiA8glDPgHlIIMnGfWAyuE5XBLra0trLu8v2p 6CWuXesuY2pS+bbh8zgJoaqu4WrUPoq0gjKKxhRjvcFN31rXEIz5ML/AMdNUFsD5SsDk9LkssARH h6jsKdeG+hVQ/cqupUyyTUe4BFpo5/DR6TH0FtIq/qddMu7buXOprfEssO8xbhbiLsUke0W0/Tlk UDWNIm9IvcnOQ96X+gDfukqIWdbWTtq04MKn7ZUOn161nYBoQO+guKp+yZ9dsosNy4sKI1YPqwdm 9gC2VYakqLPU77OXx1lButej6UwZ+77aZyN4UiUK4aUn5tG90rAd6eIlytvoLouKZzftADH7+7mA xyRep0a6S1NHHOCaZJNr6sbY5GXAQbh7iH6ZVGj3JwJO+uriymQdX02H1hs1q10i0RnEgGGsg+p2 FmQ5p8DJRBU7Yzrt3JICCbVfbKFpWAuXef2EabuCFHjx7DJzAXp2eEEqKaoIliZUg+M+MTqnoXHB UptYS9yJQBS8oOs2EjMJXpUbiVwvz5JvrwI177Ajs7SNXtRnZQeelMfQEhfVzrRysqifBG/azTSM TVkNgcHXXs804NcFpomqmgrVtvmTcERnM9jDJErvMXuFrXawZafi3WxQ5KEt6VrK/LuBUe/XSAI8 FaK1KwoCsHorWmsKWtuGT0ORjidNvHv3y/AXYyMHdyn+W6k/SiwysRbQTdLkklYeY1lglx4Cp6Ju kqNngTWTZFS+GtWmW+sVylMdw6SKCvGVaK9nfZEe1MWgE5CQQH3ZBpP50CwUEfMbcFhXb2XLFxPa 5pwm2d8jOT0dErpUE+Zr6wlEFZHLFo/jkJVVbiaXeP0geNvo/WIPfEGrsVs9KRTQsW2CFMAEEkQh vFDUcra8oDb6zOq0GaacrKLkScUNx6hJjUe/o4kByU4HdrEfVzCJknQNlFi4/3FdMV5Ibhm4Pu+j ctiEGmGkMufnevieM1KM3rzYyU45IiwdwO2oYq0kDs5qmo6bqZwoqZ8DEmd+9q1J523F+ZSE9uIR r7+iWliu42rX4XWfjGNFvdChq+T6eZL8IfVyMfL0RwVehnDzjgDS6jCPeZ9TSX25ZMakJm0Ui1Ha uM1+LwqwqspiroMn4ceMg58C63r34W7Bb1xg0AL9QYrNdUkGz9WxOJ/tOhChUZFeVLGQpTWszsOR kJpC4bbh0zCiExbyMsGNrKUSEu66S9NS6SyKl19xel6SvF2/OfsmAsIkapJJpn0xl8RYkWTDxHJB Uy0rbJEZBTMLAH6NSlJRP5jSkZP89Oa6Pmrndi5kIEE+VuHzcWpx6iUI0Q3OS69tMeuk24xn+dcq ShV/ruL9ptKbMFupFTKdPImX7ZypJFp8UdVJBpLfRr2yK138lG4q37BUi7+lk3LhLpGEXEWMBHwt IfJd86l5c3v7s3XNh/+aN4/P1jbjv827w/8RBNi4CmVuZHN0cmVhbQplbmRvYmoKCjQzIDAgb2Jq CjIxNTMKZW5kb2JqCgo0NCAwIG9iago8PC9UeXBlL1hPYmplY3QKL1N1YnR5cGUvRm9ybQovQkJv eFsgLTkwIDMzMiA1NTggMzMyLjEgXQovR3JvdXA8PC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VS R0IvSyB0cnVlPj4KL0xlbmd0aCAyNQovRmlsdGVyL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp4nCtU MFAwBOKidC6nEC7XEK5ALgApxgQECmVuZHN0cmVhbQplbmRvYmoKCjQ1IDAgb2JqCjw8L0NBIDAu NQogICAvY2EgMC41Cj4+CmVuZG9iagoKNDcgMCBvYmoKPDwvTGVuZ3RoIDQ4IDAgUi9GaWx0ZXIv RmxhdGVEZWNvZGU+PgpzdHJlYW0KeJydlE2L2zAQhu/+FToX7MyMNLINQlDH9kJv6Rp6WHrqx0Lp tmx62L/f0Udiu3ESaAKKlJFeSe8zI6hQvRWvClQJ0jW2rqyy1kr/+K349E79isHwPT4X3VSwrRrF TVMZNX1Vu5EUgpq+PzktH1+2DgZfh6ak0H6ePhTDVBxOKhUDtjZr1VzRphYwtFEgttQh+NZpDgM2 cwvvvXbQoNbkKe+JnH6pi1GkfBQbBhoMdJ60I/QIUQXJbaxO+jT6UjvDsd0v74LxNqgWN/jyUoB4 97a658eHIjrbqheF2lacBj/V42zJyljLlb5pbH9h6clMI7tfrndAfvpxg0EtqLe2jQzqBYKz/3W2 J/p2amoK9jZCqhRns92EYnifYc0csrudsBB+RmbFTlwTt0NIUxCwyevaM3Ai7mEMCzpfWoeDJwhi bYS5lJOo/M/BPJmlI/AtiLMFdyESgbC+A9GQZMUViJf81jj0FYF/S0Jo1KtiQLtwuUFGHVIc4WRz DqTMFyPFHAnYgCkeLDpqkv+ZWPyLI5fk76nkujNEQD0Kd2n1yG0QYnHa6UGjt86QEXGUjjF7Pcog FJIx3MrsJsSsY+ZeD5tcZi/uc2EQfHe4YCugr3IJtlw+WKvq2hC4Xyb/+Urh8pW68Uih8QZyLcT1 oQhF1yTsiWePCbudK+acAoFBD3vhpPNZA3dsoi2L1En1lQrJwpwzy2hcL2qNbD/nS04COYPsm4Xj HovSBAz9OWFIjzOLg3pVu+HhkUE9/1G76Wha1f9Wh+Iv+fBwGAplbmRzdHJlYW0KZW5kb2JqCgo0 OCAwIG9iago1ODYKZW5kb2JqCgo0OSAwIG9iago8PC9UeXBlL1hPYmplY3QKL1N1YnR5cGUvRm9y bQovQkJveFsgLTkwIDMzMiA1NTggMzMyLjEgXQovR3JvdXA8PC9TL1RyYW5zcGFyZW5jeS9DUy9E ZXZpY2VSR0IvSyB0cnVlPj4KL0xlbmd0aCAyNQovRmlsdGVyL0ZsYXRlRGVjb2RlCj4+CnN0cmVh bQp4nCtUMFAwBOKidC6nEC7XEK5ALgApxgQECmVuZHN0cmVhbQplbmRvYmoKCjUwIDAgb2JqCjw8 L0NBIDAuNQogICAvY2EgMC41Cj4+CmVuZG9iagoKMTA1IDAgb2JqCjw8L0xlbmd0aCAxMDYgMCBS L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGgxIDM2NTkyPj4Kc3RyZWFtCnic5b0JeFTHlTBap+re 3pfbu7pbrdtNt7ZuSa2tkYRQ6wJaGsTSQINBQkiAJDaDhBDY2LGRbTBm8YBjjMHYMfEwjoPJWCwh dpzESn6cP/69kQn2TGI7VjI4yYyjmHGIX2JQ61Xd22Kxnfm/7733fe9932up763l1H7q1DmnTlUP 9G/pRgY0iAiSVm1Y0ffSn3/5MkLoDYTAumrrgH98uuSn7hGEsLOnb/WGgor3/oQQ+StCan717dt6 fmuavQ8hPU2ytWhN94quX0umSoTuK6IBk9fQgOfT29TU30X9oTUbBu68PbdygPofonkeur131Yoh W0EWQg/QMtBbG1bc2bdU9QeO+i9Tv3/jig3dc7ufOYjQDgEhzey+3s0DXSg0jtC+ZSy+r7+77y+t j2uo/2u0fjRfBPSPfQzUqWJ+TDhepdZodXqD0WQWLFab3eF0Zbk9Xl+O6A9MCoby8gvDkaLikmhp WXlFZWxyVXXNlNqpdfH6adNnNDQ2NSdmzmqZPWfuvOT8BQtTixYvWdratqx9eUfnipWrurrR/9c/ /MPIgRJ8HTKjPvl5y4ecRG72Hv/jrc/07PHP/5+shUZ5HUbPorPoYfRL1J6JaEJJtBZtoSE3f36M fk5D2SeJWtEJtOfvZHsSvUjjFbhOtB8d+TtwSfQ4OoP+5y2lJNEGdDety3fRL6EMvUZRpRd9Chp0 H3qV5vopDZvzVVlhE330yM6em0LfQ0fxXjQLX6KeIywGR7GAzqMnYTnNeYC28+HrLZ76pUx3oXvo cyFag7ZSt/zh6679CmnH/0xbdQ+ahe5H09DtN6X4ATxNdHT8Uuhp2qc/lsOiE5HqBFmHz2E89ij1 PIJW0+8KoG3HD5NpqIG3wFmEpMalSxalFi6Yn5w3d87sllkzE81NjQ0zpk+T6uN1U2un1FRXTY6V lUZLiosK8vNyQ8FJATHLbhHMJqNep9WoVTxHMKCixmBTp38or3OIywsmEsXMH1xBA1bcFNA55KdB TbfCDPk7ZTD/rZAShez5AqSkQErXIUHwT0VTi4v8jUH/0JsNQf+L0Dp/CXU/3BBc6h8ald1zZDeX J3uM1BMI0BT+xqw1Df4h6PQ3DjVtXbOnsbOB5ndKr5sRnNGtKy5Cp3R66tRT11BBsO8UFMRBduCC ximnMNIYWbFDJLdxRddQcv6SxgZvILC0uGjmkCnYIEehGXKWQ6oZQ2o5S/9aVnW013+qaHjPvhcF tLIzYugKdq1YtmSIrKBp95DGPXt2DVkiQ4XBhqHCuy5l0ZZ3DxUFGxqHIizXlgXXy2m5USQM8blC 0L/nL4g2Jzj6x1tDVmRCVLnCXxBzNtHu3bOnKehv2tO5Z8WL44Mrg34huOeUwbCnr5H2MEouoale HP/+Xu9Q076lQ0LnGpiSaWzTgpYh2/y2JUM4t8m/ZgUNof/1wUC1N2BZOgGT/HvRiHYE7Q7ap4EA a/jeFyW0knqGBucvUfx+tNJ7GknRyNIh3MlihidiHItYzOBEzPXknUE6mi0Ll+wZ4nJndgUbaR/v XTE0uJLi0zo2FEFhyPSZNxDcY7X4a6JLZVg/rdXMrrX+IT6PdgtNdXMCiiksyR5B9pg+U16jXlpA nsXqrwnSbFg+jcHGzsz/1jVZNAN/cdFQIqIMfWrJkNRAHdKKzBg1niqN0hQrOukQrW2Qh28oGuwb sgenXx9PVq3GtQuXyEkyyYbsM4ZQ56pMqqFoYwMr2d+4p7NBqQLLKzh/yUuoYnzkVKXfe6YCVaKl DQzYOYPiVV7jniVdPUNip7eLzrQe/xJvYEhaSgd4aXBJ91KGaLSHCkdocQG5xCE8I7WkZWGwZX7r kupMRZQIlh2X2/iFbIJLvEo2FOWGNLka/xLsJUspoEAD/E3UEZw+lT6H1Lka+hVoh8uhDFWnT/Uv AS+agKbVGCr0N3Y3ZOCY/5ZMeYZOMxITuamYl+YzI+ENLA0on+IiTKP9mYJpCg3r1MREFMmllICG YZqNHMT6MovhvH9JsDu4NLjGPyQll7C2se6ReznTGXKfZ8YqdYvvps6i3YQCNHrCwzpzqCnivblz h5pl/3Vv4gvRMyei/Xs0wZaFe1jmwUyGiNZ85hBiKCxVW7zy7GfzOdi0gk5iOqPl+bznlCSxubyG Tds9wZlde4ILl0yVoSkFucd7FyvLilqgJTW9uIgSs+mngvDQ/FMSPLSwdclLAmWpHkotOY0Bz+ic vvRUiMYteclP1wo5FLNQFsg8fuZhOS2gHo0M731JQmhQjuXkANm/6kVAcphmIgzQqhexEiZMhGEa xilhkhzGPnSUstbQPqb0u9Hfxcbna0vX7OlcynAcOWmP0H8YgmCc9k4wfgqwyjCkC3ZPH9IHp7Pw ehZer4SrWLiaYgY4objorj1CY/AvWcXy0o0a6KOLX0Q5YDUqOQUoOvW0mtOMlp9S8e9PPU0wdaJT hAXzLPi0WqW9NvU0sPAKS8CSG7AEGrA/HYLD6TX8os+fb+DeRIwTpass2cknkA7FpbBgSBpw0tBn GDJcNnBooyTwgHiJT/LH+CGe1/DqQZ0K8ZtJFqofLa/3vAnR5e2bPKPtm8pKc3lHIJZr4WO5FXgz WMeiYEv/F+yqTHpjMS/XtCL2a7m8Wso17KU8nhcdkAo1DtDYQWMEjQE0OmdrmwUqLQ0WbPE1+Lp8 530k5KukTuJ7cXz4zJS6BHtLJfnhxIgPcNLX5zvmu+DjtO7WJB6hQ5/VqdViQa8hHUaeuJ0W3GFH VlRfPlpeXl5fwZ7WmugoRNtHy9s72iORTf3C++3UU1a6vJ1+KmJVlvxYwKGm/aW8XbRJVdTnctSe PIndJ/EdJ3HWyZNjfzg5tvskbdU3PLGYZ+y/sJm9r65kLcWxsde9MWXM5o7/kZwmr1LBQ0T7pKk7 dAd1mNfBXs1RDdZpYC93lMNaDnbggxirMO2EBAqggD+AhUBpIBkYCXDMJwVIbYA13DltVuLpAPQF QAp0BgYDxwJcZwDkKFNuScKZUFmSWsGbJE46OvW0naOR9k39/RE6RP3Cr0czrWQfsOPgpLxY5eSK cqe6soR6TNhhz8EV5XFMTr/724v/9m/vv/urs566rpmzOqudzurOWTO76jzw3ifjKP1ff7r2f/x5 xZG1VVVrj6xY+cT6mpr1TyB5bO0Ulz6ivHwBGnoJGWm1IhohUWivseMsO2jZv6PZLIBTCB8LAwoL 4eHwSJirORa+HMZh1gx7pDQRDYMQhmQY+sKD4QNhwiLOiJMSMkDE5kwgsXkwBCgkhPyh4dCF0EhI pQnlJguQ6BBCSdskRw7PuxfoBNoJFZYKZdxZb9BuGC2PKF3STz3C+8vp2LM+KSuNgN2E1XFSUZ6D HZlhr8xj3TKBBBQhoAmA4OzkbbeFJrdOy+1Pr79n/qLs+vhk6/Z01x37oJx8ZiqIFBiFUI4tZ/q6 lrFD7uJiN16+cKlKo+fGbMzHY3lCY5SguLGJ/BiF0WT0uBRYnwdeV8SFTc64E1v9enPCZy22YoMV jBYADsiL4yOST2tJAAFNtm5ys6p6sBo6qkGqBuooa7bns/4RdaZEfv48O9jz8iZFktnZaHLFfJ3Z qUpqHZOSSJARg3WJhU4EOhnoXKiIRoRR1inC+7SnGJJEGIqwB0z0Rr6JBCeV4FhlnKuHmIwwKjME Y3GwqU3EYa8on1wFP5c2Jou3pNM2c0WiY0pDe3VWzuSZizpKHzYFqsOlK3MnVU/b++4DtYurs/c3 rConP86asqplbKe7eLm5IJgVblk9Nd4Wz3dqgHs03Fie7XFsedPkSOdw2FaSjA+JWRS/ZtGOW0lp hx79SKpCrXY+xB/kj/Mcx++gDmLk+4yDxgNG0mBMGbuMRDD6jZgzwojxshGfNZ43XjQSI8OmOckE e0u3NcxMdBpZIjkJLjUCZ7QbQ0ZSyxkrjQ00kwHjDjnhJaP2gnHEiDHLtNSYNHYajxmHjMNGzaD8 umDk9KoODUF8B7HKxHG0HNo3dWzqlycdpTW0h/v7ZSSktPI6TjnUcI7RE0ZXFEop0xRlPlFZifyG 0o8gOvcS0lAECGuFBKcBjVnQGhJmoVmv/1iPnfrc47nA5dpzz+deyuVqjudeycW5rH1ZdDpFcsGe C8O5lF7mQl/uYO6BXJKbmVIyUDGbUp7mQXFYxEgURD91XBBHRJVG9CeDZo+gF5Mmn4NK4PYF/N+f VB23TquIjEjwv5tRDdlzUqmbZ1N8aozOpnWbNoGBdH5hIi1Z2HFjIhG/u1imOeN/xMXcfciNbpNq cLXGkuBU8IIXhr1Q753nxTpTM0naO+3YblcjIhA/IRrCGZJaSWtKaNV6s8MyHzGCSRv1VoQOGm1S RUW0XaBrRHt/WWl7hKeU0hKM1UOFo8IRtNidDNsdJgJzOzvuvqe7/l//tbY0d6ZoLqudbu9fjR8t zn/nndTY9mnTdappOrtZp6wFSTrfm+hYinTGD0jFu+1w2AZ6214bdnrzvFib5c4qzDqSxWnyEqJe LxahIogPFh0rulxEithwzZiVYG/JFS5J5ELiISc4UTI3V+VPugXVfItC8q8vbxTflrcLb5VHhetk HyYIPKu7Mpsns8HxATDqH6CzGjhHfX97zvTpcY9r2twlxVu+2VX01istD6ysST9ePT/mhq9bIgn4 pXXmg6vreI1OVW32Oo3Svd/f9tmnBcu/sXUBPBldfPfs2Xcvjir4W0gbfpi2OQutP8PpAL84/m9S VGtO2ETohe2UkoG2GZkEk980bLpgGjGpNCbR0+HBkgcW23ps2EayMGszw3a6ugvmpNWsNSUNDmWC 1TPS9VpFO2xi82q0PNpOyVeENjSYfyuauSga4sORKdmSVOv8Znr6HXeAVetKtreHyKvpjRqjVTc2 fQKnttjKinJo3XfT8brCz6b8ykfSM3YxJFaKRG+DCNQC9gDoKj2VeEcUHiwBR0msBE8LA5dlz8Ka QhvorKDXm8Cg0jl12Jwj5mAhJ8fQWlaH6qB6pO5yHUZ1F+pwaZ1EX6Sg1UE7y1HqkBxJB6dx9BRA qgAeKIKtRZAq6irCuUXgLILdAswS7hKwQSgq4DzqjskAk23BDg8SQRQ9HKqXcZY+hVGrq6b9+krP 0DkqE3iKEL8eraD+slLUvpz+tWf4AWAPW4UrhzD0oORdRQk9RRWnyxLML4EMc6By0CWS4U3+3mlB W8PCZUWz+2aG6lbdu/PeVXVTB759+6rTLdOCRYPJWeubJtWt2r5z+6q6ms3f2RK/c11rANZ+NysS sBUmVk5JLJ9WXFK9eHv73O1LSz2W9H8c94f9VS2RaYvriqK1bQ90th9aX2Owe4wKDqHxP3JMA2gC r5TTqlun26MjrWgdwos03Rq8iHQTTFSckzJSarpEnqE8lCrzhhfHf3aGYo6WLZ0h6tDBAkDQotXZ tVodhgUaraaZYDshGINWCzkyoNVoSWi1RKenHGoEkUlIECgKfi/RmUACNDO3ZCloSowIcFY4L1wU yDEB5NCYb1JCEPxCqUA4AY7TSDwoAO4U+gRM1wWNjpCkgTdLWuC13Vr8Fy1oAdNpW1HRvmkTJagu SnoYW0p9dLHYRLm2iPDW8na6UtdFI4wm7coSIrsi5zOvslKI0M9ylqK9XQtBkFcTrfwiz6Z3zUrf 0wnnHgMrqB6DZWTdtfvJXRTJvWN34L30zWhShD6sFMdtyIeelBaiWXrdUd3zOvKx7qoO79CBzt2s t0fsuMXeZj9qv2rnmK/W/rz9ZfvHdpVgl2rqEnaRE+0irrkiwgGRLjLiMXGIriDcAerAIqNcxaUJ +Z3lld+SYBQS/EIz50n6zHZ30jUxm0dZg+hC0s8w9X2Zax272C6vl5BBPQUvczC5sYLcbckpcDrz cyyWnHynsyDHovtm2n1sJ0S4D28OpVBX59+8bjDefC6lTflog5SvUT+kxhrjQ0as0QK4VQA+my2/ EBVCXCocLDxWeKHwciFfKHNY4eJER+ELhXixr8eHfYltut06rMtK2s1C/qT5vFNuTIVMhemyn6HC dMYtbwd5zuVeZ6W+NMMU6kzmehILlobv+s7Gyhl3/tPK+YfjVZHctTXTVjUGc2bft2pS84xaV43N Z9PNGHxpy+BLd1TbDOnPn3V4ol1PrG99pKea1xrUtH0pui7+grYvhr4phWaV7ynHX3Psc+ApzlnO u5x7nBxPV7PcCjLVM9vzNc8+DycTZ5fWmMjJolMlVxIcidxcWxOq8ldBFWt4aU4gMa+qo+qFKlLc lK3XZ9uK+XAyUJnXkIfz8gKCkOQr9Q3643ri11P6x3qCkiSFJtGntaYGojIlimyS6RDlEOhwI0Uc yVCWGCVCQJfXm2mQQ+khFSNB+Bf5qZ3Lo21zpxiLy8SV09u7ww23td3WEC5ZuLmx4f6p0bCntWL+ onDjkmVLGsOgqV/bUqg3C/zvH8gumL+ofFqRLydvausMqashaDO8ucGVlWwoqS3M8RdKyzKyKbeG 8pcCGpF0vNqhxlqisVpfHB+USju7Eiqr05pnbbIutvZYVVes8DsrXLRCj3Wr9VnrOetPrXzKCiwe v2sFOVHNtMYEi8YN1pQVl1sB/FawWwFZocZurbR2WQ9aL1ovWa9Y1TQI91lBsiatfVZiZfMltyAh vz0++S1l21wJ3Jo0jBiwAYwdZmLo0CUpM6ghnTrGcioLAONg2kdvzKR2mUBQn/zppzSlrLSDIiMV cikbY6sgmYmE73gbNPd8Iyc+zXr1I8qOTuU1nqtrTCpwpbcrXKnCx8yi8+b3VMbz0NX9a1Ksp2Br AT6sAa1mtwY/ycHDHBg40FhRsNkVQRFopl8pMhgZjhB/pFN2cBG5NZGShDcxjwfelfQ4bEknyk/q hCBC/vmy/FohvCbLKvJMiijL14SAIn9yTRD0WzJIUkLqGOFjSz7IE2lylUXGGvyLogeWprdXrHum t2JzjBJ6+AY0DKT/mhZzGzprp67LDW+s2Lm9KVgFv9ny8gONBr2e4qX5Slbx5y+5i+HNtQeW5rsE /HuN9l2KH7vG/x22oXcovcyX3OgQ0gHSCbrLOpJ5aXTmo7wNZfjifsbof4FwwTabv9jtKfLbbP4i j7vYb1vmLgrYbIEiN/PQSIaHuRQPf0zx0AX/JY3zRocx10h0Go8Ga81uSJvd89wd7u3u/e5X3B+6 x92ay27Y737a/bab9LnB7BZpPHmbRn3iJkNueNoNg24Q3VGaiCA3vNXrfoGm/MTNJRl01F3vJuNu uOCGV9xwzA31NPl2RiZhO830FZrtuJvvdMM8N5SyBPDUJzJ01N1L4V5wcwJL+TbNcNzNHXAfc+Pt buhkkPVuPMLym6gs75fTr6f1fVsuar8bbtRYCaUV7qAZs/ZwpW7JjaVdohtotT9kzRhy4w7mK3Xj WlrnkYkkrEP2u0kp84y4L7uJkrMM66fQLHOawbDcG33uQTcWlYbTjJOGQcOQYdjAGXCHdr/2Fe3b Wk7raMVGRFdorZ1OLuLAHWhCqKOzrAKiY2+0C29M8FjKzJI/y6/7vxxy3dd+PX75jQz6GV9G/Ww6 KtK1JcAWBxIBitVQ+07FA6dzvTO4Jxu81ublvVPK3qGz8nGD5udQm37155yKJ1fXK3onoGsa4tie qhtuk4QH1I+q8TxzhxnPQx10vX9x/A9nKJm3MGbnCHUYC0yWRK2hxdBmILX6Fn2bnni10KUeUB9U E0mdVGNOXanGXRjUao3JZDSrzCYjLDA2a9R2jUZtUqsFeEH1iuptFVGpjL0aEDR+TamGmBlp8kre Ti8+5gXk9VN30jvsHfGq6gTvkBcL3lIa0Om94L3sVSHq7PMeoOHDNEDtZYRvaXtCfs9ZpLxjNfJb skXKEmYkNHc6ADkEh99BNA6ZpFgdCYcz6UYao0AcSTMyqTnKsztUkCRmZV2mrDFltNgEjciSa3lE ppT9sorsTdr9m8qpGFFhrbFU7BIiEcrE7dIMa4YpB5IZawqOZH4rw23JjAjcLNIugftWwuwt6Suw pCe9fXE6fXdXevsde6EMXoWnvcXFrvSfxv7kopwIPLYr/elNOiFFXhLouGnRLqmAb44g0COY0obW o7vRUcR5URt6Gb2OOOZ7HhGkP09XWtYz9U0JvdwD1bWJA3rASC/ok/pj+iH9sF51gDou64k+w4vJ gAbKg6mSWoT4JMnwX6AsGZEIU4rKPXKLogJ6GV91DJqabqoywuOvpmfDbpmHLIBC6S2XX6NPoFnr dXdTrkiiLEOKspHZoeb1dtDbwWYP68PeME5fDF8K4/Xhu8N7wyQUhufD74Xx8+GXw1fD5GAY9GF4 KxJeH8Zh6fR3E2HpWycSXSzUG46EyTc+plD4fPhiGHvDLSyDNgZaGW4IY5YB3iFnsEEGawm3yYUc DfNhqa0jUcni7g6zot4LfxxW1R4LA/YzZaQ/XBoeCg+HL4RVyXBnuI96OEUnSfvMTHkJxrLmJgvM gaTP7aW8jbI4MW3Zpv4O1l0RRdczMbEjEcUr+4RfU4CxNy5S5of2Kop8iaGV/XmMAWLqhZjc47sZ 8+pSmFgXY2Z1kXkbphdJuVFvoLx26sNQ8SUe9/NL6x7vLNJp/ueG7Hv3kWG3gldeumZ/QGUoHzos LXVJGiFh0E7VYoNmqgZrzKpms/4TPbbrKccOTAM0LI6IXA0S/WKpKFE3L4mdYh9l6zm/7BiUeXwV ah5SFh487L7gxm65s+jou9WepNZnVpEFZrtTnzQx/GIKI/al8452kCKNZjRFMtWjHSKrVSyZRXxC 4Sj3Q03Louo7q/8BKu5I/0njS962JDR5SX3wTsgBw8KlZro6u4uvPeEuni1MyrbmTF/bgnsy7aby jcpNeeCp5GVpJxeDS7ErMczHHLHcGOEq4VLllUrMVzoqcyuJPh8+zr+aj1/Jfzsf5/s1xoS+AD4u uFqAXyl4uwAXsBAuDy7lXcnDfJ4jLzePcLlwiana+FxHbm4u0bvgY9dVF37F9bYLu+QcnPCx86oT v+J824mdLISKqD+T9LqcBKgsqoCKCIzpvkDHg1hAQzSh5sLC6qxmle2QDets8ab41jgujIM9Dqo4 /PVSHP4lDmfj5+P4mTgcjMP9cRiIw8o4pBiAM55HU3CfxuF8/GL8UpycjsPxOEyOL4730IwOxflQ HJxx4OJwJQ7vxn8Xx+fjcCh+Lo53xGFrHJbGoTLeEMd5cbDKYD/7TCnuYpw8Kxf4YBz649AVh2Qc pschFKfYq4BSyN/G4WIcfhqHOGN9XS+cTiyIr4zjBlYFCirXEMtx48e/lXgmfjqOb85ycSY/pYaH Wf0+i5PjcVYBcigOOxjIVjm/vPjkOMZxaxzThvxOaS8+x0AOxjFr79Y4mSjwM1arS3H8U7kzDsnd xapPsyllJdnjoThZczkDNUCLwxILZ3UhNPv34jAUH47jrviO+PE4SSq1bIgTYaInL7AKwPNxOCBX sja+Po79Sta4Ws61M34sjukYSWwoaROltoO0UZfiV+LcIBu8AbnMyjh45TzpOA/HAQvxZLwvPhgf ivPmOGhQRXNfNaBqqK5JTjXbskKFFXx1Mt852aEJBLIXGAVUXl6sKGjLGevMHhUVmcWOLXXL2xXl wg3e5Pp20EToTcEdXxFxS5KIHB65OfJWgC8nzsQKF+m0Z/sP5bIkQtfTCEQoNPsq/7f6ZCWy0/WV qmTnf7NZkz1nQSrUuMXnb13Rkccoxrb0on0tizyNjfUOy8Pp6XsXLcquq41ZH04vvuMOsCnq5soa a77ffovSealGZ+QmT7vhl5XQ7uvKBIJqxz/nPqX8uoFS2Fo0KnmewLBXd1SHnxDgLu8e7xNecpd5 j/kJM8lnXFeCEkluMjxRAnwJaErUqK1QojxYYWGF2t7q9w/5sb/QCMY2VCFUlFZIFcmKoQqVoaKu tO5AHe6jj2N1Q3UX6vg6RnETVDCN1n1Sh811EEN1fgrVWTdcx08R6pJM0Xig7nIdkai7jya7UDdS pyqxdh5TU2Yu6O6stgY6VJ1B4u/IscoKZPpPR2bTaA3IJFpZ1djiNdrO1Mo0LkIl+eVsy0zZJmqH yhJMWVSmurApTqcsw8cxKAPBBo1truUQRYGYFyQ/Cs79Wuvb77Xf1ezrLu44tPZySXlkTcXy++eH rmVR0bP74R/0lxbO7Jl628MrY7X3/nRf36+Xk7/WLqn1pfn85q6x8009MwJjb2DAEJ6zMf0/FfE0 smDLzPo182JGbeXC/qbbHlldo0Lj4yiVns30INY8KtUjiwpl5yBkfAnB+C/PxifrUW4kwzPvp3AC 5fK90HlW7QWbl2kR9UICy9pEK9t6RpJl5epEv+9+39d9pMsHC3wgh5YvXZbAPhjxXfbhn/j+xYeH fMBgnmFQAz5M4TL72Cqf04c/k5MNSnNmNCWe9cEBH6z0sUxJygflvuk+zPnsvpCPVFPASz74Fx+c 98FpH8AxHxz0QZ9v0IdTvi4flli+IPiAU3I8E8xXdsgNOZMSSZbsog/LAT5XdoKWgzt9LDVxZjmz NBaENIxVJxoGEaAIqDE7RWfUSTTOfW43n8X4hCzTPj8/xA/zhEcUAaIRtsOwvJ0t4++/aa2piUbZ RjrFksjEFO+4mQxEbtAABiCrfJa38xPMDlM4M10Pzq+qUOdQkhea3jbZ3yJqfYGgaerknOJYVuFi a9vq/yyZFfPp9bOIiiO1xf6I14iPLNAumVjjsZXyNlo0KE3hm/U0ALdQRvkouoo45nue8swfI0oY mbYS6Tm9XY9rruiB8ckTPDJ3C3Osy/ImXpABbuaVzbfwyvKW3s2qyluZ5U0ZJWTTDZUj0zmmX4Xt 6BfIherOag+jx3m55zWWBI8EEDoZF6V6in+uV7udCqJE22nrsw3aiI32fEX7lVGgU/B8ZCyjVVDH 4mwnlsvs4sD2wMyBhW2L7DnBHHtDLLsyP6ustnf57Kw5vlSV1W2zunOzJ9c4CutYPdzpJvJX2meT yEMvUeZQ1pZ7GGUyUoczKy8LYw403IvjF6QSvSWhArAQp9Ply8lRNOi+HLvPl+OEBdm+7GaX0+5y OcGp8UGOj2UyrrUkfD5XjpbKM7gQSb5AAoWWhtaGtoVISwjcocJQTYjoQ/DXj0NXQ/hI6Nuh10Jk bwgWh4DGh6Tf/2fi4xC8FILnQ7AttDuE20LrQ7guNCeEvaFICL8b+l3osxD5dgiOhuDhENwdApY9 doaA5vqzqyEYZclfC+HnlZjdcsHaEPwtBDTnX4bg9Yn8t2bSRkK1oZYQcYfgXZq3XCl8d2hvCGtZ 7GGa8L3QxyH8WgjOskSHQs+GyMwQTA6BPRQKYVUmHa3TIWlnCAZCO0J4cagnhHEIPg3BxdClED4X +mkI72aRkAx1hnB5aHoITyRfI6c/HfpJCB8PwdczWfSEIBWCphBYQ5NC5SHCheAKK+p3IXw2dD6E n5VBd4RgQWhlqD9EKkMNrB/yQjjESEyyMZH4aQiOh86G8ESWDBLLcHms8kDLrv6M1RDkwneEDoaO h0h/CK6XXU4HhdUAQM5Um1uQkAsPMfRdRGW8ZAjkDGnVLoQA94UGQwdCQ6HhEG8OzQthjd9QapAM xGDIRi6/C0uupKvTRZBLcGGtq84Heh9YS33DPox8fl+pj8yUidYkaUaC90Gjb5Gv27fTx4HTR4KU fhNX0u82C/MNqmxZDGNMjsVV0c62TDYtV7a8NvUzOX6C5YlsinR8JY8S2fR3eJRb1TRf1u3cCF/+ BW4nchOj81bk7+/f7JK1Coz/kWVFLSgST0YCjON6UFQMXmVD51D6Ef/0+WsaPfmTJjmiAbEq0lRb 6vSkn+iEswfTnz0Ky8m6a23z962uxbyKf73Tlde4vCZB+uQdn178qLzjw+Z+FbPHpnPfhS5KNs5h d4QcRK/1aiNaYuJNYHpx/A+Sh1I8HQYrzqIODAtMRlMzYDsAdrKBWSU4E04nNrr3K/o1iekZKe36 UPEm3X3uA25+qhxL/w+4mVKOY8GD1DMsa+jU8+RYjQl0uqcBwIiTBq3WYAZTEjmdiNJZtnddLu9n lstWKpaKjDi9XH4Kb9ERjuy6vhfGBPHlzIZL3k1hxikBBwTkjqwgVZj7ILuqLE8nRvG5sWt0da+r KTNXRN3FJMprjZpdn5dde0dtsOhfTf8AYbQhfbfqUz6FutDXgJPuPFoGjTbg2u3tB9vJY8tAPz8y v3b++vl3z+fXJe9KYtVU51SsidnBo25Vr1OTBoCBfyl2ToWp0/8l92vdXbnmXNAW5xbn6ub+AjkF JzY47zXfC+P3ArpXuPfCvSP3Xr6Xl6R7j92LO+/tuxcfoK6he8m9rK9rWpcnzPeK92JNU+vi1q2t pPVfVutgiQ6MOtA1/6vPd8e/hde9WxUNQ7gqXMVrF8LCdyxcV8c7dL0eragfbVcWaWFUGK0QmCTQ Tlk5RWmhmIXJvDgFWd5uqamoYFYPzGQAsU1hBbWZk2fIGcrDsUorY8O5HKC8HJcxIqhikXlMk1FF I6dQsdxFmFGQvJ/FKdZCJu76/hbkZXa8ZMshGder+NOTtz3y/Orvpn//465p277z7tV9L4Dm1NLq lQ8+efI2g8tq4Il3ZmpZSWJezpQlNaVL2tfU28Vsr9DPa1QcZ/Z5pvW3zyzzLDjyywcHP/jewysq 5n7zyrMdR+5dX5b+rU6rEVS+xuambF9lvqugINTSXOd4MTyrOrDlDbA+uR+4X393e+Ntx367d/UP vrmjvZwz2M3ZjdneeGVwQ9vCfzx4b0lemVcHBI/9yVEeDZsMLouu/Latux5J3PfTXU0z7vz26/9x z45PX+rNjsaD5CRFZSrb57g9t/Xd39g81xkotLJ5R9ASuub+kvOiStSMlsLDkmtbIywu6ynDZX66 6CbKlpStKXuojCtjg66lITiLSgnlTD9gonxYqIAG5bMgI1tiF2vMCSdLJ1ZrjAl/AYVQN08qL1EF ObQokTtJcvsSuewxKXdSbtYuOq2bYpLHl4jFWhIRBC8j4JAdYS1qS7WB1AaVbeBvgzZWtnVpZ2Kw DQbaoLMNzradb8NysHdOKnGsDbg2qOfadrQdbyPHadzFtkttHIs/My2RkN+xOuUdicpvyUaXh+sF YH9baSa/ErMnUROf6SvNgixVsDzKhUky4avWmxNiIpogx/SQ0Cf0M5LJsDAjacvOWLcwVG4X3iwX Ri2uGkYVRssj7R2M6kYiivpN5jhlGsxQm8q9FVRiUSZBJCKbRjD0jigfFIm0M1YO7CrGj1IWtCJQ 7nTcpJurKiGxqrwJLZ2rykVhCJU1A9cRHIPCwk7s4ZKen5wrXJhdTxKTwXn40dgdw/vWH1oedhfH Q9ZoOPsb36hc8Q+t2VMq8rQfBPdOChQ2NacPOoJuk6tm5azWBxYXps9saHNEZ0+umlPmdJbOxg88 86xW9YAlZ8fAtHtW1AbjC0oDtVWVHpU3XDXp9Kxfzts2v1Cl1pLeyIG8zde+XyNZo5Uxd6g2nBWs X4xr7tle3z41J2dqe319R73I9u8Qs0nlH6bSUBjtlwR9EDQac5YZm0iOLQfnMISbwlS4CbXf5ceC v0gqAlQ0WIRrhKIDRVgq6qSeA0VDRcNFI0Vqv+wdLuI8+uYPKQ2Sh5ziZdiUzHV6dDp+vk+wJO1I Hj9ZL8FEB0pk2GAp1IepQ9neONshz/Sj2iLvAss7erJdJvVdH5Z8nM5tXFGbVTW53Bq+vWLP18b2 7oYoAIHi++YOv1l5+z9tKl3V2ZoHl3v2Ls7ltAbNmEuj+TeuJKs4PWQri8WygpH/+OMdrzyY0Fvd ZsRkRNlOlzdRGZGjMqIa5aLn6JwVThEq/I2dnexXoVyIxGLy/mc914jX8SZkRD78G6l4ltgqYq8Y EWtFYhDhc3H4L39LPC++LL4ukidF2CPCNhEY0DqRiC8Cktb/4ePEf4h/E/HPxH8T8fdF2Cc+KZ4U Sbu4QbxHJHNFmCpCRASDmC3iayK8KX4gjorkRyIwMPywCLeLXxNxO4ObLeJiEfSil+ZGQX8l/qeI XxfhpPgDET8lglxexw+GE9likThVJEYRPhavivgH4hvi+yJ5SvyOiL8m7hMxqx1mTWhhjaDlXhXh jyL8L/FXIn5ZhCfEEyJeL94t7hXJMhGmiLNEzAqNiOQwLUOSfnPw8cQJ8fsi3iseFfFdIrSIbeJ6 kdCWeMQwAwaa43+K8J4I3xf/l4ifF2G3eEQp+C6RZIrOFkEnwt+Ugv9TJEdF1pFknwiIlY7rxDli u0iiIhhFn4jXjLP2wC9FyPT3PeLD4lMi6aUtH1zanqDNHRXHRPyhCCwai8NzFyRYzbBWdIuYlnNe vCheEsmz4jkRf12EHSKsFPtFXCk2iCmRqESnmCeS6ousJyled5dWJgZE6BGBReM8cbKIrSIAEmFE vCxilhseYtkcFI+LJClSeidr0MllEV4QXxHxARHMoihGRWLa6UQ72ea93vsoMVtES9Qyz9Jr4alU zgy2lE386KjMV3Yo7KbCwUZuZjgjE4L1LVq7L7GokS8p+vr7I7cyrzelitxIwwxvVNdNBZ38hEfe c8frqsOOkFeYEg5Xp59k7mxByA45wtXciXCt7JpC42SXDIfkuSbvRchzLSsz107SCOP3MHCVOV6D MtEonLxe8ndQuEl0KqpRATog868xrgNv5u+gHGJcCuvtXnvETvTYiyOY9mO93IvbLfstKo1F4gV+ UL/fjERG9mh/et6k3ep5QzGAawdGSyoUm7eqChOB1Mz1VNiZpS2oaczLbaop0M7Cwab1XEfRnJ6a 3MpJgjCpMremZ06RYgdRO36N3yLbiuShO6XUFjdssYHe5DWtN5F2soHgGjKTYD3xEqz1YtDSfwQm 1Iac4HIWoAKolwrAXwB9BccKRgqIujUZHAniYKhD1ZlHgh2GTi/TyDGVnGxKtCmziTTKan/Dck/R uCmNgAxfBjJjFlHUb9zxBUf+befZnKZZLaHt3x2oGvvrt8D4o9WpE+mxF2p23b8l/+TJk/i5g/+6 r+Hq3RgTaHns16Sw6RvXvnc8/c+tgEHRrTEamZ7N7KXoeJjlcctGp2k/6M9BRWmBTqaPinxRTzvn BP8MCsALklGrcqsKVURDV5mxIJtDy/96NbE3CJXBhmBXkOwIXgxeCl4Jcn1BsNOgFA3k2GMgeFaO UOmD3iB+43IQzsugRE7L4snxibQKPHPychG6oTMJOdmTstdw+GjiaBAGgjto77KAst0PJ54PAku2 I0i8QdpdcCUILweB5SMHRYKYBq5nAAeDRE51oHtNomUC9vngy0F8MAiRYBuDtAcxC3k9SJibNWMg yE+5GoSztI74WBBCQdbgATk7lRAEjILgD5YGk8HB4IHgEB34y0GNEPRT73CQyzIas5sJCggBf2Aw wGkC2YGk6ECeJHGbrUltB+XmTFq4bvCpmJpTqlE+Wh4tb990QwN3farfsDqIyDNbPgMxASKHsE04 WzBW9QWjKxP2AbN5lhVbv3nmmcj8LTOLm7LLioW87GCRR/f556+nub1kSVn+9HXf3FCt17x5t04v TutqejJ17bNAcXFAmSsrSROpovKUC0Uxlsb1ZTB2vuxi2aUyQkWryrIdZVgoA64MrpTBy2Wvl+Hj ZdBZ1lc2WEbsZaGyyjLycRlcLIO7y6ChLFXWVUb0Zd4y/CbL4UoZeb4MDpRBV9kAzYjUloGf5WUv w6+XwdkyWF92d9neMiKVAcsJXy2DgzQZ7isDlhP2ygU/RQs4XsbqRO5mNaIRerk6R8tYhciNzFmF 8HtlH5fht8tgqAx2lB0sO15G2ljVQK7WuqtKZc7KLeS9ZbVlWGnb86xtoTLp66yAg2Ucy+ZqGTlI Qc+XkfVK67CcyRSWL6sPV1vWUtamdARt0cesc86WYdYqnAGHq6x3aJtoRwwqZeMIK9VcJpZhLDyu Pax68gKdmgWPBw7nPGnOErNwVs5TPh8fiES0tudUT/EcJTWXqDxdYamQDcgvjY6+zx4dX7BwuY5I Ny8eX9pQ+rJ65GYQuqhUykbozCCdioXympL75SCsulmjWUmFt6z0si8Fkd8zLad7rm9htc1ls3py sydXOwqn5n9lKMPFxaSBRPgFDBdRUqI4dqAMBw77nsx6fKQACgTtYf5J9Ph24WnhE4EgATQC7SQb 6y2mmdXamKH1FSpUjFpoX7FZ1z52aVR4nz3bFTvVLyhm+a/Q1e76gq62wAXHv6S+5Ya+Un+b/3e0 uqxtAUqjh8irKIBK0QGpe210WxSrfLDDctCCVRbYoT+ox0QPGhWAdlLCVC6VAyofLMc11JEs7ys/ UH6h/HI5rzjIvHKIOLnsZoUSXWCUKJCdzPGWJG3OcP58Tisgxa5GoUEZKsQOhrRPsPfy4YMMVtgy hviZ/SAmcOUQX8aARjlSlOH7D68HDXbUTJ+Vt2TfyorKNU+trdhUwU4LHE9Ld+CuSdOW15ZuyAv3 VOy4k/S4i6usPochfvd3t25+6YEmvd4gBrK16axoNIvM7TnQFrYIYxaN9r2MfafqN3TNzkLflvyQ ZbAkUJbeknAhysQZjZosk6u11MpMMInV42FU32FzJeZ5YJPhPsMjBjLDsNCwykAMTEU2mcpIBrpg LuvUDGqw5n7j143YYMw2YqMKW7IIpdIGPSFWF9F0IDAD5QU1DlBZmbn38naLvC8r785aa5jCkh1e KGf7aRGKSqPsmGJdtKKC7bFFAkG4samphRunEsnyYNpxNl118iQcgrPwPgyePDk2cpa77+rbE+eI rnHk2sS5RK5MWZ+LEeKfYecv4RFp+novzPPCIjvMskPSCJVGmKl6SYW7vRD2TPHM8pCX3fByFsxy gM0OYdsUG9YLXgHrzV4zDpummDDtixelUwZjosIAuQZI6iGmb9TjpA44bGe7CHbacLvB4VV7kA0Z DQ6V2sObeDt1GbzUrTbBAhrRyZvsPG9SwwKHwdHqUds9NGa97W4bttnsRq+KU3s6HOBl9l5gcPhE X4cPm331vnm+7b4XfJ/4VB/6xpn2WPL1+YZ8XK3kA79v0HfAR5CvUz4mOuy74BvxqQ0H1cfVWP3i +ENSyGxJLGT7oIjnsw0mG1F3eFV2I0cELUEOD+E7sthJLmWoFLsxC1RE2dmgSLsiwDIF2hsMvcst rhpmN7brZg2vsGt4WPkyE7LrhmQTZDNyg/dGmbeygaS92ZL/uokZ1D2bnnUQfpa++3FceAKcUPUs fO9gehe8eXjsX0+kj8mHx/ByLLHjY+mVIB8jS+vGlsjhGpk+pMb/yG+WbbXy0e3SnKW5a3Px4kBP AKu8i709XqJ1LXWtdRGdGnRG4AnwFtDr2lAOuHKYLXy9v1AqxKit1C7Zsdku2qN2Yuc7gjZzh5vL HDltbx/dlOFUbzlvquhKJhQl6kork+lzwOqwYxNlNEooq5kb7jl5//0nV4fDq9m7J/zz25698o0j fz7R2nriz0eOfHqiFR/b99tjt9127Lf79o48lUo9NbL3NODnksnn0unTp9NXTyxceAJ4xptTHF9I cdxNefN/lNbpbHts+Dh3lsPySdsHLYcseE0uPJENa7IfysbMwBZr3FkU+exue1arw25njoC51AEO h6fVXCAUgFTQV3ChgASgNakClR11RgO9ARwIqMROdYeW0LndkcXJ6MLOxbGDWO2KEFfezg5WUqSx WGtqdkUE9ONdfEQ4fxMioPabZvjEbjkbde1Ne+vw3Otj7zx9Es94+If9pcWzuybD+kfSr9Dh1+XN 3976/Kll986dhGenuYmpX96+Y+GcbcvqhLE/eGN4NtyTvH169tj/CDRvpP1jp/3zIp+gnLwV/YeU oEuDxWQWzForWI0GFSwwCIZWtcquVqt4WEAjOjneznG8VwDBT4mmIHBPq0E2Da1QA1Hb7Xa4ZAc7 0/uVLkmwt2SOlCQu0Mnfab9gv0zRhMX5Q3LcGU+OApMn2BIddpjMAWc0dVrNtBoU4YQWAWsEFc8Z 1Jy5QweZTi2XKSfrV0U6ZpaY7R2b5EPcbzA+Rd5n2XTrJoswPAztbA4CXZxz5XlUocwnEiBAR/PN dPNheO1H8N6JsdfO7hy7vAv2/g5+EWOd+NerGtaZ8ED6Hm7N2JaJ8wGFFK886DfSLGaVHTMShyHX EDMQt6PRsciBicPlAj1dYvXZA9k7sg9mk85saMhOZeNL2XAhG1I0+Gz2+WxOyoZQdmU2HsqGbFlp Fm9MoGwh259Najma7ng2kcNrq6YkhrOBwdkZ7o2osKreCU4n6rSXusHtjto77L20g+0qW6cWGcBg YPhI0ZHLWCxnTl+wLRR2qDGqLDebaNf1L5/YoGfq0rfYDkC0ooOuTkzCvAknJ8yQA1UV1AnPfTj2 46dPkj9N9/vblqdc78Fesa5OxK1jn00gX/qVX3IqAmM/P5bueob2G6Z050fkJLLDB5KwHgP2FxYn 1gl3CU8IzCz1D5LLZEm08G08Xsn38/fz5Bn+NP8TnvBsB3oLhX2Yf4rH6/i7eLyEB5JnBzcuxDPx Usw5TXmmJtNiE8cO2+XpiFOdp8aUvxGUnWqzYDebBbaFZTZlznoZYQFHuBaD0W4wGmCBntc3qwx2 lcpAMc5kJBjMk81gZlp2Ha2V2uwyYw1b5k5nz5RXO71l5oABFhm6DWz1e05aapxJFz+VwWnAWgMx m4mBqATkDDkbnCknEZzAOeGs84oTH3NCg3PAucN50MmVOiHkhJSzi3qOOznkhJqU8xKFIpIT8KAT LtAxZnOlsCgh77lFvWLiFSf0OQedx5ykwwl+J+iRSqDoYCQmpBdoDyStGjNgzmDm2eEbV4W8dtEF iw54ubziXD8TcmPQ2cpVF2XbP+2yTQNDCUtFhfKvzKKLu7Ju3re8fvxMoV4Tp0si7ZFNWgjqJw6i eaFC2brkF6dfnfuHj2alX+6FV5788N9Tv33nCehh59Hw7WMHM2fSduLuscfxffIuJVCqhMjvKb54 4UfSpK32Q3bMe3d68TrPXZ4n6MLsAdm8Urao3GJjR21GzmgyFu1G6tAZ9xjpWIBGm4nRsJhSZsHJ khD28NqQysRTBsRO2RITz9gR6rKpqNvUaIOdNrAxxNyXV5iYxcMeinV8FnU7YAFN02Jw2A0GByWO NEkzZWdMJt4xywMej53ma6QZ8/L+ig75fNKKrgQz6MGKCVCXb4fvuI9Z5lzyaRVDnwY56CwNvOS7 4tPVsNBK34DvoByqrqSPizSCky/B8AUUE59Ks4uZ+GCB8jzYtpLpBNSI0m2/gWgMNsq+mJIqo9fO 6VyCGfFqYkgSneNWbiZz0nnTxF0YbD8wwviZcrZUsS+NvJWlgUgHs8zb9HdYG+VAIsOzSERe2BSG Rg838zUKVtB1Y9vG9OJ7fpm+L/3PGyCWvtwLJ+757oX7YMHt6b9OdxQXu2BO+hR9C3AYHmFIkv4U BPp2pE8wHFlMloGX0mICJ15CPLsC4+p44iJ/ib/Ck5/wwMuWCp9+lljM9/CY+c788ZMEM7g58/uP 5bek++1HiS4eFivA33v/wwRd7t5j7nPv/iqhBA+f+fk7CrTh9bcTlXwDjycp8GeGz2eyefmVxAAP 7yrw0sLvvpQ4z8Oz/DkeH+RhLQ+T+SYes7sKMM3/H2sonHT0Gwleeuxw4nf8Zzxey2/jsZZ38y/x r/FcHy9tvz9Bc9vNH+G/zZOtmXx1K7tZvueU0s8tbk30ZGo4f5FSEVPLvESIB8xbeSwpdaytl6PO TZ6SuJDJx1BaSd0j/GWeYDm5GFKSu92+hJl/gX+FJxo4UorYfTeUcmJEUP2b8qJBaUOELRv0mRll RVvM7C42RW5opjP2YPQrkxO2UjNVdaSs1FZBgotfjc/i69JMKfvM+L/Do+THMj/6zPcqCxsKU4VE PmVpnNGUQIVCIZ56sRBYyDl2skFxSjnFpYmRQjhbeL7wYiEpLaR1pKD+QnKscKgQyyBWo5Cwo0M5 fbpB3QEdGdKBjrU1kJfQyaut05t4mp3eAo3OfTQoZI5tKQe3WMv65Z1FWfUe6VcWyi8f5rJ88XDX ozZ/0Y3DXcr7Fv8XD3vhX9yIlSMUGc1F+bNHKW7b0WFpLRFsQlAgmrV0jrNzN62ZczeoVa3WmJFd sPspP87p7U66itQnnZ1OLDhL6YsuJcw36DzgHHJedqqN2zX7NU+zo8ig0RjNdiqaqpGJcBbdTezC TbQhI+RkDiFHR2uUEzEgKwsn2INbZBXS9M7YY++kCx/HVWfhPth4As4+ioW0JPNR38eX5NtyHsPr lRsuMHqPjv+btJ022uJT0r7J7ib3T93vujmnO8/9rPucmzsn+8lB93E3vt8NkHR3uvvcJOSudDew w1uCG9dcdsNF9yV2CAEY3Fk36ZQtTQgnQ6Xc3AXlTFjK3SXHn3fzkptSTuVkGDtUxs4vcI4jdoox OgdxKtgw9lY9RJmmR0GDG+qsDtkM5cvoQChyw5tfPN/3u1/Fl39x2LmfXUsg5Ywuv4vKY4XoQ6lk Gw/bdKCyOC15liYLl5sNvNfhzfWSXCfwLocr10W0RGuGsNkcbEXyjDWYEyiSF2mK9ES2RrjPIvAv EYDhCMgHLJdMa0gkI8BFQpHKSEOEq+EioDgPRs5GzkcuRa5ENEKEMmMRKdIZ6YuMRHh3W6lG0mD6 1Sc0haEOc56Y93QeycvLsXfoBUHP5XQQeaLI1wxkZJxI+yjbg1d235m9lfDrSOaegY4JkpArC3k4 JqDAVx56Vq5C4bmBzw88PX62E1bAovs/XjfD2/jj9Vu+d++MuTtfWFG2YtF020n45IGmvMrbnr/2 T9AJ7f7s9MizZbFpXx99/ju/3zPFaM/Swz2eyZM9ij5sO1mGX2VrBFKjd6SHntWe0+Kl2rVa3KIF Tgvvan+n/Yz2qTQ/lXBq87STteQ/tPBTLQxooUcLC7QAfm2pVtISTmvX4ikXtHBWe16LB7UHtLhS 26Ud0BJBzmlAe1x7VntJe0XLJ7UQ0lZqG7TkohZkSNyp7dPiem2HFlNoOCKPHeN4EX8EcQLn54iG UzNSyzFaW/5mu6JIez8y2j5hs38d+xSNLLPKph+65DKco1+MKFVNT8+QVvgNJa8Uv1ZSeWUzbb8D XC8hHWVhTTN1jIUNaXWJfXrQF2jNCStllPF+CizpzAlitVmxQZWtwlo9472ztZaEDqYANhFgx8Kh Ta/z6rCg09lcLnnNodxNnwtSrgHXcRdhQWdaOxJyVOGiJQnkorTZ5XeVupIuruaAa4QZ//W5DriG XMPUo0pSD5ZTSQk5FeN35dR5Nm+i3kVJIejb0KCspnEifYfDanVYdUAlHSqFq7QkswsyYSfGztpT ryIcMoxUBMQIC5c1EpGMwR1iyxKFqoKJs5aKsZh8IHolvvz5AydzxUbyyJgeJk27b+MCa22T95pu ObfboPkF1C2+ukGt13OA0ntlPFuXfhWelNexCNok6SgV0YV8h+2Py0eiJmksCTcKXQhhTWiwGFAx 1A8WHyjGx4qHii8UExpULBvY2F0Jz1Pu53p92337fcTXmd+XP5hP8vmjZnamI2MCrLSKXXfCLIGZ tv7LlyPYvkLj/KWVSRuYuWVh22J7TijH3liZHcvPIokvrEXXLnylqnl8HEUo3XpSdbc1jzIJ8h4u 7IcNyCUZMQT5PAxosl8gyk6uYjbB7LRZGoqLIjoiRdYAxLSNWhzTNGrwFOMsI9Zkg56IyziVXUUR MMAFoL4y0BDA7HazM+FoQr7lrNofSvgDwAXsAXw5AJhdgjYUGA6MBHhHqwnxdmLuwBbS7LnNgz2d GiaGa+g801OSFWFHGDK3bFByJTMsNxRVGTqlrGLysu4PxTJ3wE2orrhdZ+G1kyUDrz2R/kv6/2D3 NeUv2tW59tCKYu5PbEG79uGy7zy44L8+IJWy770FuzorK5c/OJ+t5+O/4Ydo200gSc8266FLN6Db oSNNHNzF7eGwlu0UbyO7Ce4mMIMAgQUGvWEZJnaMiV6nXaBr5Tk7lSk4ulKTAT3T45MePXB6duFC Ss/p9bzhaQzb8G5KbDBk4WqMdWzPWRCFDgGbhXphnrBdeEH4RFB9KIwLlLGThD5hSOBqj9HnsED8 wqBwgG14XBBGhMsCx240OVMUTchvwS6/JbPelND1Uj6Sd1CW2izbzIcKZJv5c05fInMYVbIYaZcT rDMQvsOkJhxbMRRZ1FrD5hydpZS3mJihTIf6ltL9sqksfVe0y5In5TVuETY3sdNAQCWHm6464Yce HfuoYuzDx3HOWTgEj9Fejnk+/zNvlMcgl7znidH+b6Xy5H66zk5C26VFuTnAux9zU6Hemm2dap1t 5XbTRZUDux1rez2TJnlCKCSFsBTqDB0LjYQ4BQ1LsYQx1roC+9n1DYIVW62Gzbtc4FLhwFZQrkNs Z7oWpudjlmlsHZTvX6Ksk2JvwDZCCiEW52PKYSVGdiYsmzh1gOy/9nr3t3d1zwhsfTCndnLUGpw+ +9HF738QSQ4cPNWFTz+6/LH7tg4ebL//Ia3ZpjsO2Or+3rcW7Lvvngcfb5u4a5BfgIwogFZ8VxT0 ZnZY+rJUR5mExY4eB7YI1HWHgTEZd6rgDgKmXhREQSmIpWBn8FhwJMhl9UqaA5pjGqKxbdarfZt5 94RWd5St6qNML6TQTVDUtjRTa0W5lXzpCsHY7c9uYpcIXnz/RXftqpmzOiY7HJM7Zs1cVevGx59L XzvVBl2QgjmwIv2P6RcO/Pbo/PlHf3vgwEdPL1r09EcyvcDjv1HvZjwwfls6rTaDywR3G2GJESJG WMNTHAceQEOoDK436FtVvF2l4hXVzjKm2jEYFaVPq6L0AVggmIVlCOw07wcNoDbkG6oMdxg47W3m 1WY82dxkxkzVk28mugklDnK+5oSXnfBtJxx1wm4n5DkXO7c6ybvO3znxWed5J35WDr7bCT1MlwNN TtA63c5CJ/mtrLO5/Ze/TjD1Dn7QCQuYwqfS2eAkTidgJ3zqhEtOeNcJx50sK7LNuduJaQaFTLeX R4t50HnOyWudcOI/nH9zYqf0T88lXne+x1xPPJWgRa5l5S124jznZApJZGXRgUcVZVHurr0JuxNU TvjMCRedwHL7qZMsdUILC3XSJKRfTrG+N6Ne6lmbeMkJ9zsB+pzQxVJdcuK9zqPO552kT9FUYckJ didrhVyaVERltL1OYFIG5mgorrnC+ut15rM7DzqJ3TkgN+6ik5cTxOgS53VGnC1OoiJSsCARJfVk HiFeAkZK2CRDVqKQvo1Gk0nQI1WHVUPMBoMszlHgzCECuwEw+5e5D1NWotLQYMAGjqIDIzP00x6R pbaJS+rKoxXRCtnQP0LxODKxix2ZMITqYILq9Y3riAygiHy33uPwJSMq4ac3VGdsan/BvP+L2rLr rDC7q+mm65oqMrKTPT0rlj6ePhpLN2yh3BzUw9piWAalP4cfcH/6/M/kyWtdGao2jzxzbTk55WEr q7yu4k/lPc1vSdk2jc6YQFpBizUajs4OCGgwaADCWa0q1mHLKAlQecwe0TPPs92z38OLnqjnbc+4 hzNTx37P054XPB96VFPrPb2eVzyfeLhXaCz2SAsXJ455YLsH/B7o8ADygOB2dhpFa5QRQqONRx2Y KPIj479A+KncS5EJI/OIshkk/0eur7Jc5sQ72/SNwRMnMXd4UvXMuXMD09bmTs+xNYX3ZVbWn7Tt 6ZpRIAimK3tdnh8p/MRKSu+GKE2fiobOPFgFlUzFt5mKLRG/1pjYZwUde/MENLVTWqbgKd4HYxDr 9Xd4e714u3+/Hxd5/X5vEdE6ereiByn9jKO4xM7hssO6I3Euw/hrp3g3Z2eXCygiRHAkkru5XC1s 5plWAZt1oNMxCpm55Sizx0PlZLY7QcllOzNSjsoWy6Ptlpp25WpNZnKc2f4mN125hqMQq4rDxAaZ vDaQjNUrszkekrad2rTq+y366cXWKTOac9rvaPQUzVldu3//ptu9U9pn5NRVl9IVI9g0O1X2i/cm JXpnnzsJG9r2r6rMsoHnBzq7WVuycHPD3NX1PqJZoFUN3j9theTPrCRaQa9+5rn6DakaveNbtG9n wyHKR0SpNLJCsmO+lIcGfoDfwR/nz/L8wYwiKWtxW2KQp/w9DzXD/GUeS3wfPygr7YfP1EqKUkkf zE9s5wGhl+AH8r04GU2jfGiwn91FZKPIMBvb4dCRI/K43iGPax0qQtuksp0YzGwcVRrgiYPkEqLJ yyvw9G7lH6QcSAkqkUqwVNJZcqxkpIQr6Aua5MOONIFpkrgZIUf+1pDKsVnXZx40Y7MZzGbdTePF xoqJr++OKqNlZQu1LMTCTTYKtwwSs1FgskKADg581HdyoLZm65lty789mw1LxVRJHhZv4p6Vta2+ Tvzc2GlrcVUjEYqXP9Ld8cTGqQ5nZiiii++cOXdgbr6gwUeOpFOcRs1n9AHcRxSnI2iN5OjOBocv 19ftI46s3KzuLJLrYuev5Mtb2CUuUj51CEJesVQMnrZSXqI9wuR23tGhQ2wrTcfl5YkdyCZfDZWZ mLKwrtxIJqto2/lJoRKKddbJIdnA3fZFyZydnjERojqeHj+1rP0U4Gcb7+rtiqqm5zS91MlE8+lf O9Mf37Rijid3mip8+10P2pf989VvnAXNd1Jak1WXfu+fI1HpkdHvHP7NY7OE7Fz7z9KvGlxWnTKH z5IG+IjZ4sB06S96t9eNrx13M2UOaXOvd2O7myl6yPPu99w45d7hPugmMtB5CoNb3G1uzLntbvz6 3e7X2b1AvW5cK18wNO4Gt3TupcQLbhiQryLCSeWWIcwOI112k6MXblwEVO+mtAz8bviE3Q90wY3l Y0udbrxmiN2ABEl2dxJclm9HYsmxcnVRrxskd9KNaXGVIzeBHJBvHSqVK3FBucsIS25QzIrMlBvv pYw4xwk3WxMxaZ/ZD90wlPqyndWE9dQmRSd5PWLCLusrbY/goy8ZGv0dq6KMTStCXEA+xx5Ax6V7 jlvOWjAvwk7PYx7Mu3dSnlmHPRibdFlM89SaHTQHo8He4Pbg/iAfDdYH51HP08FXgh8G1eZgB/W8 TZ3jQVU1C8IMeDuN5cxBkQJvp6AvBFUatak1aQObptNotPCd9g4nMdk6LJnNS/meAHnDcvn1E0tM jM9YFd28Qf6lPfQgaQ3OG1y+cs3y7XP86bnvjL3+9En4nO2fR3u/v4cMJQdaQmM7i1N3pZ9PT5/Y uqxbf2DhgsMDTdfvKj/N7AhgmpRkchduIClyiZAqTbPmNg3RAeRmgUYNC7RY3coRO8eRu1x7XE+4 iAsTjZZdH4e1dBwIk8Y0hIpzNBHH2TnKsTBSVWW2JjjvcS8c8ELK2+Xd4SW1XuC8cNkLZ72XvPio Fyq9DTRmwMtd8MJBCnveS+RbkJZOrU/4GbDdi2sOshuWJC/Gfm8pffd5B+WblEa8l73apPeY9wJ1 ck5da9I8Qimhg9ZO6Nji3On8yEm2aHdqsVNrdFtp1cwdauOEFUOFtaamvV2WmOUTG8rWYSRzXZV8 xOYNOhDKIsdIOh20mhphFz88bIGK9l1CRKMYOiiydcaU5ea7kigXwGS4mUfTk3HdI+kXx/783eGx Xyg3rd+/k4lyaWlskjeGn30kXXvjcuSxh/CdVK7DaN34v5MaSi9FVIF/LI2vszxB8ZVZKPgPbQ/v Dz8dJmERhSnzb9McYcplisQOd66bDoI7djUG/xGD9yhXIP3tWmJ97O7Y3hipic2MYW8sEsNaFv23 GKYAr8XgZQb2+/+kYLA0BrWxlhgujoE3BsYYfEyzwm/GPojh2OC/vZfYELuHuX7+ToLGXYgNvvF2 4oexN2P4+RgciQErBbfHNsTwTJrl4Cs/SYzJ9Xg59nrsvRh5KvadGN4W2x3DbbH1MTyHlQWFDPLk UILW42js+djLMfJwDGB7DGSY2OCxf0zoY/D0h9IbsU9i4zHyegxeicHzLNXBwwm5slG5suYYjLP6 wtuxD1mFXo7hp2OwNwa9se2sRKiPzaMZSvfel/iQZoWVjPbGWKmElkdb35FpvRiLxjAttVduvZxf TOpem+iNQSRWG2uLEXNMjOFMs15g3Ud5yHkx0MfocI5PtOTjGLcjBn0xSMW6Yrg0BqEYoJgQw/GY rASsrktciMH5GAzFKKNBI/wxKcYh+krG+mJDseHYSEwtgxZGy2ml4UAM5KqhGGhKbWCmhEV8CmMn ih7NtVksxqecnLIcjr2VoSwKIYkoZtM3mHz5cIUsCtx8SOLW88IRhQhHMpvgXzhBoWx+RSbEhcjN qYRfM3GAEbeKijfLo7Jmsh2CpCpObrldPcMAmsH2xa2mF5Oe/aGpRVnu6mUzpq4KBqc3PZy6eDHQ cudtNXO+qOuD5TDXpw7OWDtnZo/ky3YcT9uyTj7XtH11i9U49vlX3D/Ymp6N1/APIxdqlLLyHVBu n27Hd5rhTj3IW6D5PNjU8j6azpRQo0/3G8HIWA9KOjReVF8vsxlvRMoVfYFs/sW5HCVYPj8K8t3Z Xo2reNbtLQ+++oAkPfDqg5t2NNrgT6lvPf3YA5siqeZvvQfZP/wheH/1bHNq2ksffEbrNJ3WKSnX aY4Uq6UyZJuT1AotQptAGl2LXHiWudWMiRFJtErI9mlSQxFGvt9C0nAajQkhpWKMTo3JVUMd8s3H Nlkhww5e52DFGm16y+2zil0aW+OOTTt/yqr30/TsVGTTA489/a3UvZ998NK0VPOzv0p/9MMfpi+9 9y153SxAiIzwDUiHTOg+STBUO32JmKpRtUhFFqtAxdQwVpuHMmtJASdlxdtlgTMyHq7M6U0YOcnu TnA6nQY2mlQIC9iPJZzEffgYHqKCHNbwpi2IENCrVUzTxAhzlFFoZQOfOqLRSEWE/QYHfSC6HlIW NQYVlgoHFTMDJHxy7ATev/lc+ht82g8fQX76l5C/kxy+1r+flI+1K3ekML7TmodmKmc74DvK2Y7O yiI+L3O2g8Ex+0FZ71uW0fvuhQ3IfY7gCJ/HDstdOxsvsOfcpPklTC+lslMerwLNQAvwEin4wKxH Z+HdOdDdvKUZd0/bMg3PmtI6BeunwBQ/ZSvaaqAsY7ZRzGS6bopXtZNgoZsKsXdl4btc0GWFASPo 9V49lncjNLzKocI6klUzJZcLuxJ2m4qfydkbEmGUmGvSrtdCeK5WOzdM/AaO3UKX2pGCzlRfClem GlKpFPGnICUb+/75r4nnUzCYgq7UQAonU3A+ExP56OPEsdRQCu9IHUzhvhSwdF0pUpoCLmVPhVLk Xy+mLqXwyxl450/fTgylhlP4YOp4CtMML6WupLAcZXnxR4mXU6+nMEt4PEW+JYe6TryQGE5dSOFQ ilWKnE9dpCmIHLf8qWdoZoCFlD8lpZKpztRg6kDqWEqDUqU0gNyBqPdCaiTFMYhSCsGKvpxSo5Qg QyQp8EhKLflpm1krRlK8koAMK/U9c++OhPzu2yK/pdKV3QlzCpL1UJ/Q+nf7j/iJxm/SJvV6V1aN TTUll5+p8SWTUa4y6XPalRuc5QO6rpqMULW8fXRT+42rFZezPdSIctTk+hHdW+6IUY7sysYnitBs qWBn1i3svC59sOkq36CcMZeFdhSJQHsk41auEFYDJS4yW2EiahEyt8jlTZzjnSCd8iF05fwuoV8X o7mU4pIPatrvjMOzJZPJP8Brew3BaF3BpX9KP/d8fnv/7oV//Vu8c0tV9uSIp7D1H7pX7l6Ul75H 2tDa4k8bc5urgyWLti3LKa7KqkhN8Z9bu4yrnbVmTnVWenD5SynGt4RXb76r9oI7djQolWb/+Hvt 9y2pdnhnzO+srl8/tyjS0nP1jaxwlR9eE6KJnsTsTS25HJp8W0Ol1RaJL50+3Dlhe3gP5UUDaFBa yPscPsxrHJotGtKh6lVtVxGryqpyiUEpmAz2ydpc3uxqTcIIYKhn0qCz01xqB7vdbOZcnYGcHOgI WE2dHGJba7iDIzcuEK5QlNa3mAtSmVG+JUA+fFYPX7YKDFgm7loI1J682ThwnShJYvoQaOIbl9Sb a6bbrv78ViPBK8xIcOwDQj1/TX/jOt99WLYLOCZFs9RL1LhKDVZYoNaoW21Wu82qti2Tbd8MKgdy QL3kAL8DjjlGHOx6059JNRohYdVolyVNYGK9hAniNcTcYcUWojV1vGODB2yA2fU6eL4NZtgg1xaz YZvaINvnZ6zaRjMW+h1KD5RHrp/BGyvfJRtDyQckFTb2ZiN94B5gO0Urrr2asc7HpxU91lUrd+7q E9eN80WZpsq/aaJ6gtJUtUxTbxsfh7nIKunBwucBchpUenZHVYTtY3zMbYbzsv32T6SI3lHraHOs dxx18F7qbHHc7Xje8brjPYf6Ywccd5x14AMOGHDscGAHs4Uyxqcl2GUfmHZYrXxdqnXylMTwDVC7 A+RgT1FZgsLgPsegA/sdSUcndYw4LjtULPpMsCAhg+k9vgR6MKnr1GHZtEacJJvWfM+ZndCxqzJl bQ8lAKOZa0UndKiR9oz5xBe3LeH8F29y/9Ltlqy/dqdns99loP1lyJxDfB9lbvT649mGqahMvtFL /t0AXMM30RVo9kvU8wcp3+tnl5owCTaMv4//E3+OVVqcRUMRD1M7+WM8ltje24vjQ9+jiw/bjbcp vEyUXSsjC52bIq4gVHR1wb+utPOt8to/ffyP5CQdkwJUjY5KG6qYaLw7H54QIaeAOmtzgKm88Trj XcYnjESX58kL55HKQK9uijAlOQUnp/RNGZpyeQpX1Ivs9l60nR3jqawsG9CGdoeOhEgoVJi92cKu 5apnWwcWd+FmFf8gf4gnGl6N6imdrb9u4MsO2MtXpQjKdk155h4P2QbLpnQzs7i/oXhVDr8qthkg X7EuX51N2aHpU/uOdfU/uyGW37Ri4IHGJfsbpgVt0YqYu2lbaxU//YmlqX3dVXD6vm2B+rba6Tvi 2VNXkuOrn15flfxWOn3qvtef2NAgWix/OKA16fnaHb84nFta0X0Ivn/m2wv6m/3Z7kc/fKxF0Tks of33P2j/5aHJ6KTUcn+I0qiQPWXvsg/Y+crsruyBbBKLPRbDHJF/4yaUuyOX09De+pDy9pJRSNhs D9LhrkbVUjWWqjurj1WPVHNiea+OsV1FdAhKdRLFUZGySQMPToJJk/I9mzNmU4SSQ3X+5od42MYD U+W2f0V3RpjsK7zVXh6NbLrxaypo4tJ6UJjaiUOTRD7eIB9ukFcaea9PpWZrzf+IrTnStfE7d9Qv 3HtuZcsT8elBK2X/Xc2bFkQ5ynikdi0vT6+Ulkx2re5reGyW2LAGjq15pm/K4ufR+IlzoDqRtJt/ v1snGNQNey48nFca7fx6uia8aHvq+Nc9WQd+fWSeolPrQa9zIrcT6dFsKaozAW/SwglJZisZUzmI eR3B2MSpeRNSC2pmxc9p1Ij7jpY/Iwv+P2VXMmYJv4MoXXHLPaPll4RLdLbKTGXAUmEJOPCW1ekl 8NxqOIG3pBfDiR44kV7co/B68h6kj/KHjehpqW8XwE4CFmJ/EB2iY91bPrVXtMP99q/bsVAO+8uf Lsf2cnu5Kaf3Qc0hyug2C83JZpxs7msear7czBX07jYdMWFGxi0kuHnatOKqzYoIv9P9mJt3q4s3 a/VufaF+t/6Intfo3cqEkFW5ozWyHj6j21UWr03tm0ZlXXyNbOFuV8mXEqqUn0KrYnrQjCXXF/cz v+jfvb5t8pL6Se/+9t13BzfctqFs5cGuzq+vKt/7xR9MK3SUp+Lx+VGbLTo/Hk+VO8hnG48U2KXb emf8aPiHP975QmHB4d5597WVlbbeNxacuWluQcHcTTNnbZpdUDB7E363dmVzQUHzytqpnQ2hUEOn PL67KFPNbJo0aJ7kRX6tOcGrVKAmOsTQXKL0+JhuRMeBchsvpWN8FqfZKlv4sH+smlCA18hiGtuk Zos9JW822QqGSgyvTSfxsRP34ZaxMxyCujlXBe64PFd74DlOJM/J9lRNUqnKj0txJ5VTODMWMdZg HiE/klAn4hD+ziAlpqrviGowUxZDMghUUGTljdLRkIkUMzCkeEVXTfblxGvN5KVrzdjU0wNP9PTI bfVR7HmWtlWF1kgtGpyFsVrlUmEBaWCuXwNJTafmmGZIM6K5rFHxBIuqqIpxQ5yKiVBJWjUO0yZz EpfkOrlB7gBHozJGVtEKcNNaVLzZ/iZlNcsVCs8uD6tQdudeK4OTq9PPpJ/p4euuJUjhtX/9/7cN y/jl9F85YXw57TzTWYzQ9wEx9Um0rJTQEgTOn/4rGzQeNY1/pOqiNIAgMwqiKJX6vvESKlHuGCzK /DKPKfM2MAEvTB0F7C6jPPbQsIeKPaacDX83VAlQSdjdLkQXOlsq723TqFLhLPddz9k+HXToQCee U3/Pcc7IYS52rvh79efy89nCXR4dvTJaXz96RTmUdmU0GslQgXbhinzpTObD0xUdJojAV/we4n8b 9+JGcrZ3rOub3/7msW8++/Q/PWktmFFWJuWZzXlSWdmMAisXPfbtb37zmWefPn70i1F2vif9yJkf /+jc6R+++L2mDS35+S0bmpp7ZxcWzu4d+9HZH//oe18RkfkNDsoDvUd+idwojB6QWvXmveajZtJd uKUQewi7Z12vAk3ITXn7gLoZ37jBJ1kEyv09x4q4Gzf3JO60PGTB86iQUJAEp6APhcT5JidWJ3lv 5jcP2FXCoxlqmjnYS5eGiZ/ioEthxcQtvJNlZiJv4hoBuG7fKf8YByluWpPedB+nKt7Z+uoPKtd+ 8/aKO2LpSHD6inhWdVW5NbyxYscg+eXn32end4HPuy0cLL36x80v3ddo0Kdzex5pj7DrfPAo+zUO 1g+5lBa+J/+WqIj+SVppE7NVnFV9QiMYDVpOYzlhdXm8mHOSE5w9x8dznOOEs94KGivndHJWDadD 5qx5WTiLXb6bFTDpVFj3HX22Vy96TN8xu2xmsx7MZjr/zHozcViIRj4OKqvF5U1/i3xdWnnmBdFy 4a3IhPjKeIgJ2fVmKZaSOhK0sW8wVkG/AWZvSL8VjiApBBrxXvra3DVz0/9rztq5J4enfA6G2Wta IDZ7zezj52rSKyFWk34dG3rSrfAs+/ZAxWp4PL2WfVen34SKzG9mIbB8/C+NfyvvME/9CxKV37V/ e99H9onfXh9/Nd2k3q1iP9upYZejoEw6dSDdiG6bgJJzuvnTjf+IGjiEGAFA/P9EtdQ9l37t5GGU wCfQLOqO4hrZn6T+Qm4z2s2xoapBERo2l/hQivt3Od0smscu6qaiLsqn8YW4ZvxV6vaqKCy/GNUy WJrHfpYWK+W4aR5V6uVoA3UvYfmy8ilMPUvHwqg7xurFymLh9L2SfhfTuIDah2ppXDH9plj+9G2n 9WNvuiYgK2xCi2lZz1C/i6Z9j8GRBrSd1nElDV9H/ZHM10XhW1nZ6ocRpvWMUPdKmmY2fd9B82b1 PpvJm9VlHfW30u90Gl/A4lnetJ1zWV8wGNZ39Psx6y9aFmvXdLmND6CeTB/vYm7yY+RjdeDQ+GXV CdTE+pHNAvopQl3071ewAP6A78efk31khGvlXuS/pgqrnlNnqU9rGjQ/0Xymc+o+1c825BieML1l ftI8JOwTfmvJs4Vs5+wjzpDzn53ns7qy7szakfUzt+ROeZZ7j2dbs5/xhXIm5RwS88Sf+JcHtk56 KLgu+FloXeg/c5+g8sxb+U35nfm/LvhGoVB4Z8QQeahoctFA0afF60rKS74f3VM2uWyw7K3ykvLp 5csqUeXWyj/GcGxH7HDsjcm3V9mrFlRz1dOr76r+SY1Uk5qimrKn1pnBvB50D11P+hgzgQS6klB5 i9PTXiMyxmbD4uv42XkdV4FCdmbcmHIpfRk3oTTijoybozBfz7h5ZELPZNwqumINZdxqdBd6JePW IDvUZNxaZII5Gbee1qEt4zagEpjI34h64Z8ybhOKYzstHTgt9Q3jBRk3ID+lJoobIxMpz7gJmkyk jJujMFszbh5lk0MZtwrlkNMZtxpdIRcybg0q4M5n3FqUzf0x49ajal6TcRvQMn4ifyP6Nf9kxm1C X1PdNaO3b1v/2tVrBvwFqwr95aWlVf4F3V3+xIqBIv/MjatK/NNuv90vA2z293dv7u7f2t1V4p89 c3rjgmmpmfPm+tdu9q/wD/Sv6OresKJ/vb+359b0s9eu7O5fMbC2d6N/YXf/2p4F3au33L6if9rm Vd0bu7r7/cX+L0J80b+4u38z85SVlFaVVN6I/SLw/6YitPar124e6O6ngWs3+heVLCzxJ1cMdG8c 8K/Y2OVPXU84r6dn7apuOXBVd//ACgrcO7CGVnXdlv61m7vWrmKlbS653oIZvf19vZkqDXRv7fbP WTEw0L25d+OagYG+KdHoHXfcUbIiA7yKwpas6t0Q/e/iBrb1dXd1b167eiNtecmagQ23z6YV2riZ VnyLXCKtzc291tS7kQ7O7QpMkX9zd7efZb+Z5t/T3UWr1tffu6571UBJb//q6B1r16+NKvmt3bg6 eiMblkumnP97qSn310vn4DbUj9ai1WgNGqACQgFahQrpuxyV0r8q6lqAuint8qMEWkEhiqhrJtpI oUqoaxq6nf75b8phs+zrpu9u+t4qp2WQs2mq6VTuXEDTpKh7HppLQ9fK8Cvod4BCr6Cw3WgDffej 9TSsl1KZ/6782TT9SrkcFrOWwm+ksQvlkLU0LUu5Gm2hNWQ5TqNlraIhG+VS+ilksVyv/z6P/138 Ytm1+XpMGa0X67cSVPmVaf93Of/f6xGl71fLuQzIeSuQa+W8F1GIhTJUUk7J+mJALm2jDJX6ihLn 0RJ7aHrWczcgV8l5D1C/knMvda/J9Oo62uP9cg265HQTbdtMS/7yGDAc7KdY2PuFXmK12yqXOUcO H5BxisWtkX19aApddaJ03WB/JRTm1pxXZfItkV0bKOT/1XQDdIb0yf3YLY/zagqrjHmJnOcGil+z Mz20UcZ71kNbbmqj0jd/D9ea5Lcyc26/JR82suzN0k7UfnOm/j1yOUqv9dFnL+33brm3S+TQ1XIb 19IxXEtdN9ePjdjqTNgXazNRl1vb8/9m2STDEwdoiV/xOaXt/BGwX9Ssl5+vACcthZExeHsM/GOw /Sokr8Lgpwc+xf91uVB84fIrl/G8Tzo+eeETUvoJmD8BDRoVRpOjnaN9o8dGVTrzH8GAPgbLv49U ix9WfLDo1xXvL0IfwNTkB4MfDH1AmITb+oFG3/QBkEXvE6coDPuHS4f7hgeHLwyPDF8e1gz+6MCP 8A9/EBXNPxB/gMUz885sP0M6nwPzc+JzOHm08yg+8CSYnxSfjD5JnjhSIh5pzhEfP5Qvjhy6fEj+ MeXYIaOlqeMx2P71/V/HfQ8OPnjgQTK488BO/MLWV7bizclCsXdjRNzYHBbdFVmL1BVkkYqMyxdg NqzMLWjq7JDEDgrU1loqtjYXirYK6yKeVpajgGYiyhbdvWQ/eYWoNQuSOeJ8+h1JXk5i8zxxXnSe /Dv2K1oCNKNZfbMGZ5GZTYViorlaNDeLzdHmt5s/bP6kWdXRDE/T/6YXml5pIlJTYbRJasoJNGUn vIucFY5FQoV5EQa0iMo7i6LmcWbb2WHebmaXUSF2eQIPL8KBU6mFkUjLi+rxBS1DmmTbEDw0lLuQ PaX5rUOqh4bQota2JacA/mHpzocfRtN9LUPlC5cMdfqWtgx1UYfEHIPUIfhOOdH0pZs3D8jqAohE qHMLfaLIFhq0fLMSmNEnyK7NsHkz2rwZIixOdtIQtDnCglkISwM05fLNiD1YbESGYq7Nm7OW/5/n r3WJCmVuZHN0cmVhbQplbmRvYmoKCjEwNiAwIG9iagoyNTMyNQplbmRvYmoKCjEwNyAwIG9iago8 PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0NBQUFBQStMaWJlcmF0aW9uU2VyaWYKL0Zs YWdzIDQKL0ZvbnRCQm94Wy0xNzYgLTMwMyAxMDA1IDk4MV0vSXRhbGljQW5nbGUgMAovQXNjZW50 IDg5MQovRGVzY2VudCAtMjE2Ci9DYXBIZWlnaHQgOTgxCi9TdGVtViA4MAovRm9udEZpbGUyIDEw NSAwIFIKPj4KZW5kb2JqCgoxMDggMCBvYmoKPDwvTGVuZ3RoIDYzOC9GaWx0ZXIvRmxhdGVEZWNv ZGU+PgpzdHJlYW0KeJxdlM2Om0AQhO88BcfNYQXTMwNrybLktY3kQ34Ubx4Aw9hBigFhfPDbh+qa JFIOuyqa7p5vinZnu+P+2Hdz9m0amlOY00vXt1O4D4+pCek5XLs+MZK2XTPHJ/3f3OoxyZba0/M+ h9uxvwzrdZJ9X97d5+mZvmzb4Rw+JdnXqQ1T11/Tlx+70/J8eozjr3AL/ZzmyWaTtuGy9Plcj1/q W8i06vXYLq+7+fm6lPxL+HiOIRV9NkRphjbcx7oJU91fQ7LO8026rqpNEvr2v3ergiXnS/OznpZU s6TmuTWbRYtqyaGtavcG7VQXFbSn1nhBrbUl81fQb4wfoFeqSwe9ZdxDvzMu0DvV3kLvGS+gD8zX nhU1ckzOHNXkdzto8hc4y5BfwGDI7zUe+d+hI7/Wkr/YQpO/BKchf7GHJr8Ds1F+4+GJUX6jHhry i/Ykfwl+Q/4S/YX8Dj4L+YsSOvKjv5C/gg9C/go9RfmNwblCfod7CfkP2if6r7Xgl9xo7ZYad5Ho vzLQf6dx8nt8XyG/07PI78FmIz/ua6P/OMuSvwSDJX+JPpb8onH6b+GDJb+HP5b8oj3J7zSf/oue S/+91pLf4jta8u9xRxv5lYf8VmvJb3FfR36P/i7yo6cjv8VcuTg/8MSR32IeHPmd5hT0E/yO/F77 R36wOfJbeOjIL/DEkV+0lvwW39GRf6ds5N/jLo78Au2j/+DxkR9z7oVzCAZvOZ8aj/6DwUf/ca6n /1Z7Rv/B7MlvwekjP3g8+S088eRn//j7VZ7ov55FftF4nH9834L8y4hjQcVNhFWFXfpnBabNY5qW 9acLV/ceNl7Xh787eRxGVOnfb6ywTSoKZW5kc3RyZWFtCmVuZG9iagoKMTA5IDAgb2JqCjw8L1R5 cGUvRm9udC9TdWJ0eXBlL1RydWVUeXBlL0Jhc2VGb250L0NBQUFBQStMaWJlcmF0aW9uU2VyaWYK L0ZpcnN0Q2hhciAwCi9MYXN0Q2hhciA5NgovV2lkdGhzWzM2NSA1MDAgMjUwIDcyMiA1MDAgNTAw IDQ0MyAzMzMgNTAwIDI3NyA0NDMgMzMzIDU1NiA1MDAgMjc3IDQ0MwozODkgNjEwIDUwMCAyNTAg NjEwIDUwMCAyNzcgMjc3IDUwMCA3NzcgNjY2IDM4OSAyNzcgMjUwIDUwMCA0NDMKOTIwIDUwMCA1 MDAgNTAwIDUwMCA1MDAgNzIyIDQ0MyAzMzMgNDQzIDQ0MyA1MDAgODg5IDcyMiA3MjIgNjY2Cjcy MiA1NTYgNzIyIDUwMCAxODAgMjc3IDcyMiAzMzMgNzIyIDQwOCA2MTAgMjc3IDcyMiA3MjIgNTAw IDUwMAo5NDMgMzg5IDUwMCAzMzMgNTAwIDY2NiAzMzMgNTU2IDcyMiA0NDMgMzMzIDMzMyA1MDAg NjY2IDcyMiA3NzcKNjEwIDcyMiAzMzMgNTU2IDI3NyA1MDAgNTAwIDU2MyA1MDAgNTAwIDU2MyA0 NjkgNzIyIDUwMCA4MzMgNTAwCjUwMCBdCi9Gb250RGVzY3JpcHRvciAxMDcgMCBSCi9Ub1VuaWNv ZGUgMTA4IDAgUgo+PgplbmRvYmoKCjExMCAwIG9iago8PC9MZW5ndGggMTExIDAgUi9GaWx0ZXIv RmxhdGVEZWNvZGUvTGVuZ3RoMSAxNzQ2OD4+CnN0cmVhbQp4nN17C3Rb1ZXo2efqSrr6y/pYsmzf K8t/WZZt+Zs49o1jW3LsxIp/sR0c24m/IbEd20kIUBJoSkJCgLSU8mtJgUn5NVEgQ5NCC6XQwsww gQdtpx9IZsq0pSVt30zp8Eojv32uZOcD7Zv35q311npyJO2zzz77nLP3PvtzrjI/u2OUGMhewhF5 87bhmTrRXkUI+QdCIGXzznnp2+2b8hE+TwiVx2bGt+WHfvpbQlQSIRp+fOvusdqy154nRI80hW9M jA6PnKv7XTkhFR8hj8oJRLwTv0eDYAm2sye2zV8XMeQ+ju0ubL+xdXrzsMe9w0lIVTa2t2wbvm5m jr+ew/Zd2JamhreN/vqdtWnYjhGiPTAzPTef/aQ9TohczfpnZkdnvqn98CZs9xLCvYc4wD/2MiCo Zm3KqXi1Rivo9AajyWxJsdkdzlR3mic9I1P0Zvmyc3Lz8guKAsXBktKyEPn/78UfJg78XEHMZJpf wbdd2cs9Rdzse+GDyz/jP4+3Lfzp/+YqtIvAMXKCfIH8mHwv2W4mUTJJPoOYy1/fIa8i3S7si5J+ 8sRfZPsUOY397BUlQ+QWct9foPt7UkV+hDQPkFNLuNfIDWQbOYwzR3EVvVAGzeTfyNNkC/kJeQWh NQmyhZ+TB8nb1ETiiTZKkpAxBRwjL9KfLvG7lx4lqymzwfuwJ6rgGkgDPEYehIdwhjuWdlz7ifV9 htyGnx1kguwk+5PzNNBUvoPqyE04cisilpEe0kjGyQxn4piNPw574BB+x8jfJLn0kOJ4WxxPpybC baHPUnrxC4g9gmOOkGFACdPD3EpGSIMLFtzVy6RkgcTH473wGvwQpddMfgWzKKEpcjj+INkCT/BW OCU39fV2d3V2rIu2r13T1rq6JRJubmpc1bBSrq9bUbt8WU11VWVFaUmwOFCUn5ebk+3L8oouu9Vi Nhn1OkGrUfMqjgIpavI1D0mx3KGYKtcXiQRY2zeMiOHLEEMxCVHNV9LEpCGFTLqSUkbKsaso5QSl vEQJFqmW1AaKpCafFHu90Sedhv51vQgfbvT1SbELCrxGgVW5SsOIDa8XR0hNrolGKQZDUlOseefE waahRuR3Uq9b5Vs1qgsUkZM6PYJ6hGL5vpmTkF8HCkDzm5adpERrZNPGuJym4ZFYdF1vU6PH6+0L FLXETL5GpYusUljG1KtiGoWlNMmWTg5JJ4tePHj7aQvZNOQ3jPhGhq/pjXHDOPYg13Tw4P6Y1R8r 8DXGCq5/z4U7H40V+RqbYn7GtbVjaZ7WS1NCjM+x+KSDHxLcju/CB1dihpMYdY7lQ8LAZhTvwYPN Pqn54NDB4dMLezf5JIvv4EmD4eBME0qYRHtx1OmFbx7yxJpv74tZhiZgWXKzzR2tMdu6Db0xmtMs TQwjBv/V+7zVHq+1b5Em+pe6CQoCxYEy9XrZxg+dlskmbMT2rutNtCWyyfM0kYP+vhgdYj0vLvY4 ulnP3sWepeFDPtRma2fvwZgqp2XE14QyPjQc27sJ7WkLU4XPEjP90eP1HUyxSjXBPoVWwlW1jExK MT4XxYKjLh+AlsKGHLQoDdMfE18XPDhBrjVFqvEhG8anydc0lPy3c8KFDKRAUSziT6i+qzcmNyIg Dyd11HSyJIgjhodQRZONivpiQd9MzO5rWNInW1bTZGevMiQ5LGZfFSNDm5OjYsGmRjaz1HRwqDGx BMbLt673DAktnD9ZLnmeCZFy0tfIiJ2r0K5ymw72jozFxCHPCJ60ManX443JfajgPl/vaB8zNJRQ wXmczqvMGKOrunpbO32t6/p7q5MLSXQwdqqcpqvY+Ho9CTZocjFtjlbqpR6uDwktiJCaEfA11OJn TJOjxbcFBa5gmak21Eq94CGL1LiMWIHUNNqYpGPtK5jyzJxWRRa5qVkT+ayKeLx93sQrUESxW0pO jCO0TKiRxS4uBz0B4iiyUVBMli5m81Kvb9TX55uQYnK0l+2NiUeRclIYisyTuuq6onWZsFBMxIvd iw0mzFiz33O5cGNhpb3UjFzV3bLYLR3U+lo7DzLmviRDgitviRFmwnK11aOcfnaefc3DeIjxRCvn +eBJWWZneYId24O+lpGDvs7eWoUaPchnPNezuVJIK7R2NQSK0Jk1nPTBgXUnZTjQ2d97xoKp14Gu 3qcp0FVDDX0ns7Gv94yEWZiCpQzLkKwhsQbj1IENrULvOSMTslfpVSkIpb35NBAFp13EAdl8miZw lkUcRZwqgZMVHHuhllwTKGP0303SCNPPjX0TB4f6mI0TJ0oE/0EMfHUoHV/dSaBqQ0znG22I6X0N DF/P8PUJvJrhNWgZ4IRA0fUHLU2+D10BJWhi9CV0hO/GTFlDik8CCdY+rVH94kLZSTX/s9qnOYog OckxNM/QT2vUmX+ufRoYPmT1WnO8Vm8jleLZcG98gu/+05ONqteRLyz8CiO2FvMKFzkpT6daQTKU GKjNACoDHCDQZR4xU7PVmtKfaoAOoNBvNNiNht1GmDAiDI1GWG4EldFuzDZyRqPWZUpNTdMJAlWp 7KpsFafiBrRWYdBlMlA9l5rCaQcdbxlhnxGMQNQppD4UCg1sD10oKytjIAIQvFA2gCvGv2AolFLj Dg4or/0u/37/y+CyXCizhgZKSxSk16eHVI23Hmx5VV4beM3AJZr0Td8vvxXTxat1J958TAc3/SPt gc/rYghfPK87/S3VzR+f9VRUeFRfSav4M3ALFWkfb1LapQlZr1j4DfcM9zLJJCGyTc5vLO0qHSnl xvOgJw9ycmE+B3SSYIhoATJJJCSqVnDwZQ640wsvyhmI57iKgsi0YY+BGjIs2VGbRVXcoXGSds5B 6i/UXyjDDwgOXMAd+nHzbNe4H7+yoxxcf5UJfFnFtKK8ThUqc6ZWVtVBVWVVSFPM+bJM1GHPpKGy OlrFObZr4z/P6Lo/XLMpUpAbHrnx89GG6RCKXMvrDJXP2bJyCtK69m8sSw8sl7wN9cvTmt2BB3v7 /F2f6eh55Mju9aVOO+WoWqXR7TKmGPjNX35pqL6vJi01r8yD5r8a8/MnMX8vInvOECvuLE2wRsIc 9BJw28LpR7NgfRZwVVnhLJp1euG0bNW3cFm2LEqzsooLBc4fhtML5+V0wRgBUoD8okVQVORwt6c7 hJwOkwWlQS6XRmjAGvIzO0CpDKIwBgcGEnIZ8AMqF9NOTR0XKsvE/ZuohqnZVsdVlOcykWg4H1Tt 1ILUq2KmlxXtHwoVt1Zk8Fqtqvez2vhbYyqtRlVSXti7rtk1/Td8xBWI2xzV5X5NoH1Zlqs8WmUo KAk54+AK0GZnSXGuIVCdu2Jt3sX9uO5OlIOPe4U4ySo5g+NcCy5IseoNYZNsjBqp0dRuMRsdKeoO wqP6n0Xt8zyxkPqyoB9Ntb7+Atsb2xfuL1haAqhQjS8vsWhmtbgr+ra9RF/kzy3q7WiTrj12H+7E Ieb39W/gXuG5P+7JXhENXLyXG3MH3q7tX5bB7LN+4QNuENeUi/a5Wy6YL9tXRudL95XSGgn0bo/b 7+Z66BilTRQGrdNWarWSyB6UPzPQXNRIUVHFGxWQp41Me8DDt+flOYPRLEu7ZdAybeEsFuM6pxN1 EwoO1F9IqQmyLVwo266Y64Wy4OLhGwCmCRMkDLKyKtXEXTLbTApL6uEGO778yy8CZyvpqO+/tyFD 6hmdWdZ9U1dhfmRkx2cb5dHmnItf3vbotsoVy5ZPdC6jH62cH6jXCblppddE/CvyCj3Lgpml/bes 63vk8FxHQKxqjZ/WVqwZDFVHWneyGkOxVX47ymMlue0MWblw/lk0VUEPmoQFWiNekhUueNYHX/PB PT7w+Sq0pkjqghWsTCAFqDOrddXQKgiugmU1ofJwZcWyoo56S2V7tbXC4XOY2q0OktbBo1YVa61X zBaCCbUOKHJBGCU1oBgtWq0frZaZq/OT1qpiir+ikbACJOYmvWs7ugu6hlUaZrhC/K1xZriFgdTq ZVXFEr/5GBqyli8KplYvrwmyNrMVZ7p3bVd3Qe8w/XUwutx77ai5sKTMGaduNGZHKTPmKldBZa2c cfHFTyCYVb3ERk0rfq8N7eolPPMiKSH7ZHt7EHpzJ3KpPweEHHcOLXAyiZ2XBZSYLTKYD/lMflXY ys8vI2WWspIyuSxaxpcIvegNpUgeVEEYsF7sY+dfBNEXTXMK/qtOf/LwDzC/n7Cy7ReYBBUTu/ro q5iJ5VVlAnOBi8cfSj+nhaLVnKDX8znrOjpyl42uLsxtHr3p7s6cdZ0dOU9ldJR13ra5amCt2NCw MlM5/2F7qCKUkruyxHPJHwp2KdXvcm2875WxmRscuWWZTCazaGAf820YdT1ktZxhzhAzghncQxmg XZ2SoiERlZkTOfoQt8BRJQBYWAAwdqaqVO1q85LPZ9v0K5EuFLwwsL20hDl6JWqhgSSPDVWOTfaX tfEz992sBX+dNTPf6czLtFoz85zO/Ewr+m+mMAhdjkQi5Qxsw8UaUHca0i7rRAGIAL8TgGf6yscj z6v6VKDC9YpckKvnuN+xBVs4iSvhOA6XSkg7TSwV9TGwHdfJHPLA9suWCiJb2gW2NFwJkyKTD8Tb uJcxVtrx9N0rj7XUQU01jAZ3BGlXEEixpZhmyCiScRP0mCDHCDsMUOSPrHTwP1XDKTU8oobd6tvU dEINXLkafGqgRG1RU7V61VAlVFZaImLtulJvFVRVlXr00VyLg3SkOZMnET2UBdfLPBXaDYsZg4rZ LMZUfCXDKguYtksBNOdKX5XKJdp5VaHUhGlVwcNZ4cYVrilXbk6hJ3pgc5WjUAbR3tQzXNIw1pSd v3r8piPtWT393d7HbC0zD45Vjq1vcqQEsrPnOlaPr8oRJtz5ZS66Ra1Tc9fc+73Jsp767GpnXU1+ ae8Nq/v+5siunqBGb9b+uWHrfUNFJodb/95NviJ/y3ClossWFnvRn+WR8TMkFY3Kjk5MdIezjhJY TzDqkjBKnkXdHIy6xEYoJaTAbNIKYX1UBzqxPcth1nIddou+3WQWUK/KWSu7FI2uirJ+WIqkS+7o ylBL/53Fz45m11TC6XhyO/sGSj4ZZekHgeq8uva8iwe5cXfgxdJotfgpARbzzu54M3cH9xTmBqfk 69UFEE6BlHGAPCXLDOfn2fPz8zzUT5dTTqDwPyg8QJ+kv8GEheabTqjPMgvxZ6ann8p/L5+eyIcH 8oHkW/JpfopMo5TaaTYtp9xeCvNYKOTlFXrXpdZlrM3YmPFuxm8z+IyM1PT8dh0QM0bqsqQhsYwT TX97CJScE1vMqF63Kjno9u37XRYlBR0oYxHQ5vVAHaAHQpvJxBio1sAlG3IyE6oHLq8cyJHfeMVC l/bbgjWrND6/fHJyriktzyvZcgIWd41/XUu9O/CNGe6pi9lwz7Lh3JwiTUCb5ZAmOy+OjhydqaW8 mv/7odSy9qFAB9fvRttwL3xAz6FtBMlpuX6+eF8xnQ/sC9AxP+jTPGn+NO4G5yEnbXPCcifoHR6H 38G12GG5HVRgh2zgSNhaEHbdZT2KaQHzV7JgirhkhytidVldaklOSYtIUukLalBbC7jcaMbPvFDu Ba83w2KIcqCxarZrbtaovJojmq9qOI2Gw7OIUtpuUYSIUkypqQHlOPoRCgb9fsRZLizmDMnEQe3L yr102CrKi1UJ/6ckR8WY/qrxlKroqRe/239HSUHAmjZYG4jWZi3vHe9dXjWwe1Xk1rqcoCl9fahj 0/L+8f7lYP/SkQLHv9yWXpRS0BQqb64qW9nf2LqlIdNhenOrW2xtL22oqmgcZP6qbuE3Kl6JcWXk 83JNMrfvyRvLo5ja78wBO0vt9XroFSAsgKCLVGqaNVSj7kWRlEkmssIIX8b6hckuHymNxvL68hPl L5SfLVcVRqade5zU6YtmWEzBDqtT1250qNu1JBkDEgfwwvalzD+0GPkGFisATBvqlaj3yUKAycWk Wky3ODOotRrOf78WGn+/WAnUbmrOy23efOORaNk6vW91ReXGaH1RKhYAYvVnV3BfNwRKi81/cAX+ dEapBIrX39Te88hdu9aXGOZS04rbt1x/i8wqgJaGhQXijnczO0vJJSZCrGpifY8Q0xk8uI+dqixR Szngr1B81SzSmTA2ukn4me+7wY1yecZgjQCTj8dgiThTUx12u9p8az17OKJO/bzdzjkMR7BSvRBM JJdoNyzNDOFxQ0/kH+CT5pGJTqgSbYMdKU0mUNOdB3yRtFTB5fHoVrS5c0ucjT3e6Pq3N+0wCK2c WsVV1aTnpxnpfR3aDqKsbWzhV9yz6GPysIpLSZUES0SvC6ObvE2A61C1bIkuVKEgFGSRsBh1w4T7 OvcBN7dO2ccbslNnjAgIi+1esxndqRPdqUMwJ92pokxUGovqikYX444/x654gCpbKKHGxWCDmERC A4bFaoR50/ivL/OmGkHVO60Ft+JNv5MoROh1f77fHfhOabQGnWl7tSG/JJQKcVfg4nOKM1X2ymqC XegXCsi4HFZnOjNzMzm91qP1aznWTSQnOJ3+o37Y63/DT72RaYwT6VHrHa6vuH7rirtUxAUul9XS XjBYMF3AFRTkruMXi4DEwWaWO8BMFz2jUgN8Iogmju5iiYomqnavGZ5d0bWnqzCwdvK6m+XcjraV zkCVJaOjJvzZkRUZlW3B7rtX3pFaXZoVGti7dvTrh7euzhXMNiH+p+MZWdEjf7e7cbguY1lhMr+B 51GXGlIgu1nexcmu9MhlGcylZIupRVHElZnLfcnMheVQi3X+B9x3UWZm4iNb5eJ9WVCZBbd6QZ3h zKCHXFDjgttSQbC5bXSnCbKNmKqAn4dbKYgRLbMeN2ZWWm3O0RwgkWnHHgd16KNpFi5qcS4u5ILi Cq/0fwMDtoSBJBNY22X5H4u5FyY3Nu0ZXj65qfGmoWXfXrd/uKL10PduTH5D1/47O498f8fBOzuO vBb3Vo59/podP3xkePGbEDy79fFuZgt4dm2Js+tLnt0Dp0oKdc7E2UU65XzwmAaTFKTTEBe5H+Vi /AaFqbp8t47RVTA5va7aQj/iQ8RIMuiHsutvxVdE+qgIO8TPiV8UuTERGsUukYqnF2R5IdwWeVb8 nvhDkfuaCF8UYZ8I3eKouEPkwiJUipAjglp0irTmjyL8UoRXxB+I9B7xmPisyI2Lu8T9IlcpNos9 IpcnAi86RPpD8RfiH0WOdX1N/Ib4fZFn3bRKBKeYK1INY/MfIr1VhPUi48C5RCC3aLWmW5we/e3W x7hXMTOXqxoieVyYoy6MYdyXOKrlHuM+4jiBk/XWCKcV4Tf/oaznRyJ8X4QDIlwnwjhjCbhsnOsj EX4lwjdEwF3dK8J+hWBShD4RIiJUi6BN0MgLIvxYhNdEOCPC4wpVoj9fRD/CqL6ZYPVPi0SPiXCf MuOuRTrcgCDC/1DIHlOmw97dynS9Sq92kcOrIpxeXO2EspgWEWoUJqkioGhuu3yy0wqvCYULLqpc BJ8INhFUIvxBhPdE+IEI3xXhGREeEeELInxWhHkRRkToEqFJhApFeU4ROBH+XaF/S6EnMRGOinCX CLeIMCtLImxShsgilIiQJUIK0ojQw1r4/buNmKZvvPw0KEn79qtes5e/riAf+M8QfTqrjQMk6N84 gBj/bOKykZVjS+Sf5ORX8KUlSsrCTmklRmJ+saGkLPSj6kJHtseyrLCwOv4gg9MtlvRsR2G16mzh cgVahn0KpNAl/HU6+p7D6M8c5JC8UZ0CghkKzGC2QIfdYQ9bLXar1dLlAIfDqj/BnUUT5lLrUwdT 96Ryb1vfs9LnrH9vpSes8IAViNWCuZzd2q6xmWVH1EHtjmxHuYPb64B5ZMB8kZLX1ocuJFNb5dIi mdkuprVKVjtwdU7r41iNSk/4MhI5rBSK97V8azuWl0foWM2mpXz12nUXN3DXuwMXs9nelifvDm3k BXldpRXGLGAxQ4c5bNDbDQb9A/on9bRZD3oDf0IHD+igRgf5GI50Ow23GmiXAUoMsoGKBjAYHGdx BzKmESprCh5f4FIS94r5S/eK07Y9tjttnM3QbjZbVRa9SmNzpOj4do2Zw5KWshCGsTpYn5JaEwou Xjb4L5YNfGb/yy+DHxuuZLqvfGI6NrDf4vdbXkalJy8g2IcZwIbJKcfuGv37tVD6FDy1UQvZ2nXx n/z7Ju0HP7m77hgrif9cDQ95AoHU+C8vfpgagHOH4k8p+l54H2VCFX0fkC0m6MCyJGw02Y1Gk9Fg Z7FkBaYnOrvOTgyGVCBdxnkjNdKoXtKV6O7SHdXFdPxZ3TkdLWGC0pv14AE/bIAbgAdTlNjY5aPN GbHZcILE5WNNInBvZxAotUwiIbeG9isaLy3xVSnh2gw+LPkwE6+sB0xYBFr+RU9NWb6hKhigI9qL //hK9RZfWzAS4IK8YNTu/1Ppn3/gdn6BPepnuk7F+j+Hf5ikkVvk9lYtJhEnDC8Yzhq4qGHIMGPg DIZ0c/pD6XQhHQbTp9P3pJ9LX0jn5XRISyVhnuZABTQBBzQtyqearVGhxCSboqY3TOdNvImJRcj0 RkwmNDgPpl0sy2KVBju6AyzZwsx5+ywz5gF2uzpg89l89bQOkpVEbmJ7IY3vW8f++WHtE4b8b301 0JjmK7VlVPlKczzGjDdNb8bbeENpXsO5N/Xal2cd4sqR5ge7cF/dCz+HMPkB2rBbNpF7zDpRF9Rx OvMD/FGSiOyYX1x9eRO2SQF3WpFks0lFae6AZLvGXeS12bxFbtbATiYzLNgX/qR6ll9BdJg1V5EH zpASNGmTyRoZCbBijusJgI9ZeTsmp4c00Eqh0JGzgeeDGyQLSJa7LEfZNW3NTA3szrwtk2ZmZKTr 7A5BcPSnF9qHLDpZN4MWo0I7yRgUhkTO4dAPpQ+mpeDC2VG4wNLt7RewTrtYxk6BFRSzV07CduYR rTXKxTu7e09kKX7gbEuQE8s2PvHMZfGSIJNz2FVelISP7hk72OW75Ytf6b1j213dWSe/9s2RUElB 78W/033uzcd0NO+GxyeKy3pvbGnatb4s/k783erN1/QF6b9lhafXTIzEzRc3Bbp2rT5w/cWX8HxA V+IRTUHrRF3brvWVOnXh6q0tP3qNsusOlr+wu6dX+V2Yv+iV/EUiX8MO/bP05XBPpT9ZoqAuz6kG OS+/C/ObUjmTk4SUiM3OLqXsgszbtHtNd5qxHDxBzhIVIajYtNfRvNJe/5n/dXYzknD76BE5JacP Yfb+prxheTqlq6kUasjNaakrM682VHTOqQazajtKTOmmnPIsiyWrPKdmbE0R07cfff37fAfJIKWk Cf29caRuvm5fHSdJqPMMpmkvqzldHhddbQUzK0AbaRcdoRxvIyunnNopn4+dhTy9KeL0OX0WMrWH 3YiFA1MWWUiNWHhb/lxZWWbtnEeTOWd0K8knK65YLe5nFxuswmKHn9XiCCWqTay1lDt85uuZIeey fRZDMq4lVI8qTWb0tqva3PuF4YHynk21N3zr5u8+f/Ruubty5sn5k49ffH1gd9iTWt6xfP11q73u is4n2ifq02yFTaXt47WulPxVqsbonqF6c+ahsemndtQ+cs/jrxel79owdP+Wmts/3lEzdmdPSXS5 VLn5UHdFd61Ev1Gz8fqVReHStIoNNzTnN5Vnoj7b4B46RIMo2XzZVUJlOkM5GoUhmAEsi0W0HHIG ToMucVAHWLliq/A62qgd7rnvPrJ0x5bNR/AMlsuZOjJ1HZb3Zh5O8MDLKGZeLWg0goYnc9Sl3DYy 95m4wx1QSgseC7scG1+VE6JOMOkuBnWQ+p34eR0cL48qzxKbhyvexdy5HXX/C9S9A3XfIVf1l8Du IPQGoccHu7JAb/KYaIEBVJydo7kYY6b2eMDjCeVPaZmBaqU5iyYwx7uT5URSl5dVE6Cm7JZAUV1l iuL5WOBmDxgSqlp6QlNHuX/IHDzwzPZjxw3GzKEDsaljp4zf1Rq1KmcwXLp6qqvenaJ3BBpLWma6 6+mjj8X/fHLD2beX39l6DMjx/lffWnZkY8lg75rMxq2teevu/5e7xr8Slre0Fqz90ruKPPsXPqCb VDfjQbpWbhxJnU/dl8oZZcEaMXtFL93j/Z2XaqJpYE6DtLR0NwmbnWa73VZiZk9ttWaXmZpt6VG3 y+V0m9Vqbp0uUXzWh0JBi+LtWXUdtIawUaa4e3aJ7h9QKm327Cl5U1JZxQJASIMunzMBaAM+fyTH Edq9plD2O3TqzTdoP3ebnPMjy4+GtbrjgYDFFMwOeUpW5WeszqKBQN4PftB18acFzVjzLOTE26iG byOpxE/ukfUj3Dy3D+tMCgF2Eis9eZHpwJ4AlQPgWp2VlUrQpdiIFrTanbZbbffYuFEbBGzgsYHR BntsCzY6ZQMWpWWvzhixZXTmqeztTrMpyt8hQJ2wVtgovCv8VuAFgfcs3aglHxskslPlktuSeIAw 4GcmwLMC/LJ7tKpPfaCQYatfP7Uy0JPhDZr1WWnpJflZpidu00Ko9urnC3lbvjRUZNM/N6W3uGrH 27kX/9Kzhsb4K7CHvIU2nXNKII+a2KNP2YD5C8+b1A/yj1gfJvV/UG52WB6SiJOaCpZaJlNoXNae 7DW7OjcM5gXzGivSS7Pthcu3XrPatSajqyo9PcNfWFnjKJSZHg6gj38Ja3QfWUZ2y7rJAPiL4AY/ OHHOv8Uj4oqUsNlrECwpqd29DJZlW4g6vBuzx0k9dOmhQt+kp7l60OhT9VRfEBWdlooOm4Xli2p9 u+BJPktI3ucoSeAAuyIvW6zc2b1clQkdy9JPDTTsnF16HqXcVNWplk7c+6BS8VB0VBtv0O7+6bgW BFv3Q8pT+pzmkRs/32EPBgt1Kf5AUUrNpuiKAoeneLmUVr9qVSY1iN50Ie4KBl2qt9yBe3s2XHo4 xam1UyabXhXs2Lp7by27prNnhyQlDi58hIL6k/p+jIOFShz0k5WwlthkPVj5XHjIaeAEJRgm42GC HvMPPWmVi6/THtDS6zQHNNRsBLrXCBq1mh8VoEcAQa8n/egUeb16UMsRfpBLSUgLD+R25YcYA+yH GgOD25X7oCX5YLK8/Zj24vva2NljWurWPh1d/LVFRRrOD9eq5mgjni0bsTxLVuv4TrNKcdUXWKF1 pfnSxqutVHXukyaJNnkrIaoPcE+ppEX2myUjGI12Rz8VdG4d1en1XD09h3mDmehn0Ar0dm7IwDno IFncELvWUnLKYGiA+RgES0tCuJ1khmzzcj6MjX72C5OY7sdnQys3NpbY5FXVquLqRp3vjh2lZ9/U 4R6/xKk1qjdhefyVNzX6j6/1VCh3pAsX+EncbwHZLqcd9sINXij3QK5zzEl3Om510E0OKHckUr5i tGNfdrYKS0Gj0e/awNsGddPms+ZzWM4gzqxTyb6ob8jH+XwZgyjAK2/oEs8wUCX+pRDBK8JMqcxm OTHnq1Cu6GDpZyQs5Tdx9Lk7f3J3243vQNmzt73dF1hZFxs68IuvbQxsuvfaup3jPWJk5Yrg3N4D trV3vHr9d6Hyh7OiPf7T4/7gtr+L/0ts8OEdDfYsv+u1+CtWyW3G/W5f+C3/AO43QPbInmYJsqVy iY7jjj0wlrYz7dY0rjytMY09wfq9XIkpEAn052UtPsDJ19mllJIUmpISzNigC+QPFhZmuQbN0/az 9nN2zm43q7IGebbxxFMbluaUJXY+EFKewSfuYBO7X7qjXBJA1VUCqEoYrOqFuuv33tZ28EdfWLP3 PJSevPnHo6FV3Ionrv3Me0+NYVKyvnJTT7Or/mvsqeqBHleex9R6+6s3vQaVb09J6fHzx0orRl+O n3tu6thUldUjmWE4rbIyjeWoyh2jcsfmSN6xHVPu2Dh6YFm2Q1y8YwOeu4bbjPbLEQ11yAsbhGsF KghuoUDgPhbgPuFx4X2Bu0E4JNBtAoBe8Aj02o+VZ7yHhAeEJwVuWtgjUL2wXGgVNggqhnxO+FhQ 7RGAoWhQACR/TwC/QsIJckNzRBSQEyx/W3hP+IPAJRmNJGioWYC3EU09gh85sk4ehz8gwLywD9em VOUCqCWM8WqNRkUZQDkO7ieEv19WqQBrcfqiijyGQ/axUdDK1sKeTL/3B2UpTwpw92LfiNLnT2Lk OxloF+A3Ajx3GVW2gsRpT32s9J1DSIANAsgClCvdiPypgnxUgBsEmFZ6WxeZewTAbS0ocntOWcAD TIBJygQZSgrlwrZ/i6yACP2WXQltTD5e/itXTBsv77z6ZgoLc6W02DiQxqosdkyZ+/QrT36S5BsH kq2ldvJ2DF1jiPOxN/3KK19YHf8SfvAr4iL8c1xk9lPENWLUYXkmen85W3R6ZAzIHk/2o06nQHg5 EZ0fJSSQZ30kXf2gh0efi0flvTIs//AIBf3WmsVvnIs9rHAkUkdH4ror55Mo+tpVQTy++SoEd+FT wvqnh3rcQynuQUjuofGU6Hw027OYWeBGspdSDTNaGm5G2cUjeVa2kT+UKT/JURKO0FLiAZ9MPPhP oujWq1YNX74KoXr8P7+NxG8q+eN4lt3kjLxMq4EOgWr6McVXqbhxFVyjglxVpapZxVEVqMxvccBp BYpvTpcqU7BT0GPxSz3K3ks9vshu621WarVYzE5B5+iyjdiozeHYpwe9rt9MUx2WQcFpdKdwOpV5 UGNMUbSK9QqWeSyNYUX+AAvVlyp9f/LOC0lSSE3Nfv7FF8n2FKhhhrbf4tcmLr/MILCMBzTcZXGd 3YXxx3UPXnwbXrhVF389Pnpn7/O6i28rv7Okbl1sEz22S8evqEiL11ws8FTQ4zviqZeC/8X/RovT Es8N8W39zdHy+vigufZDIib+j87Z2//VsfjfUjADb9Zo1fdjDaUlNInEcRpvvImsX/rfKyNYVV/+ KqcfkEb1Ewu/wlp+Bb5XcxmkkztM6vnvk9WMDeLaaA2Zxfc2hAHfLdzhhW6kcyNcx77pE2QW4TE2 Lkm3gsEMh32vI5yO7+VcxsL72J+KfLtVPyc2xg/7z+G3H7/bGG8V+2lNDemnNQs5SNeoIgsH6BML HyXeLBcit/I9ZBbXt12Z5xrgVXNQhO9SvofZEikiz0I1PE/V9A6uDP+eV1lUbao/8hNqlfpRTbWm TXO/1qLdq31CcAqFQp3uV/oe/XlDm+G04RfGg8avGN813Wp6zPQzc9R82tJsudFqsuZax6x3Wd9N 6Un5Wcrv7Rb7rP2HjomkXspJM0ahDSgoSiwkyP6PE/em6iHEMfGlQ0/yf7kRMpQcwT4t2ErAlKjJ TBLmSBbZmYRVmJvdm4R5YiInkrCaOMm3krCGXI91RQLWEjusScICMcFwEtbjGqaX/qddMRxKwkYy DWeSsInU0XycHUMFtl6kY0kYiMTlJmFKDFxzEuZII9eRhFWkmLsnCfOo55eTsJoUceeTsIb8QWVI wlqSz5MkLJB0fnFePanmG5OwgVzD35iEjeRd/p+SsIncqH521fTM7tnJ8Yl5KX9zgVRWUlIldYyO SJHh+SKpZWpzsbRy61ZJIZiTZkfnRmd3jo4US20tDU0dK7ta2tdKk3PSsDQ/Ozwyum149lppeuzK 8W2Tm0Znh+cnp6ekztHZybGW+eGtk5tXzm0enRoZnZUC0tUEUoLiL6B7RmfnGK60uKSquPwSkUIT +MTQ/8XicEfjk3Pzo7OInJySuos7i6Xo8Pzo1Lw0PDUidS0NbB8bm9w8qiA3j87ODyPx9PwErn/L jtnJuZHJzWy2ueKlba2anp2ZTq5sfnTnqLRmeH5+dG56amJ+fmZZMLhr167i4STxZqQt3jy9LfjX +uZ3z4yOjM5Njk+hAIon5rdtbcMFTc3hwncoM+JqLhdl8/QUKmxrgqZImhsdlRj7OeQ/NjqCS5uZ nd4yunm+eHp2PLhr8trJYILf5NR48BIbxiU5z39tNFlFpvFc7iazZJKMkwkyTySSTzZjVSKRMlKC f1UIdZBR9KkSiZBhpChCqIVMIVUxQivJVvyTLuMwp7RG8XsUv3cqYxllG45qIE3IbSXpQridrEXs pEI/jO95pB5G2lGyDb9nybWImyZjf3X+Nhy/SZmH9Uwi/RT2diqYSRzbgthhXN8kUq/EmTZjz5Qy xyzSBZRV/XUO0hU8/veoexT83BJdKa6YSbQY/emncbrEJ/CfmPW/JrmEjsYVLvMK7wTlpMK7Gyk6 FaqoMpJJbV6ZbUqh6vqUGdtxxjFlvaOXUW5WeLO9JDhPIzyRlP8WskPZ7xxSsnGLe5vDmT+pLWar s2it01fJjK1upzLnGgU/r9ge65tQWjNkGUasINml/BUjzZWcNyf5FivQNqT8Px03jydpRpHjqKL1 caRNWECxwnMb6rMtKaEp5XwwCe24bI8J2fwlq2xWvhMnbOsVfJhm2Tcbu7j6ueT6x5R5ElKbwc9p lPuoIu1iBTuu7HESdTiJ0OXrYxobT+KuXs3iWq7cz//LuTnMD3/3xIsLXpzxU14vkChoMNgHlc8T oJKt8MZFeOEiWC7C9McgfwwfnQaznFIg/odnQfxjNF/8MFor/vff14pnwAYp8r5a8bcXasUPwgvi r6IF4i/x/Yv3asV/jVaI7+H7n0+FxPOn0sRfvx8Sz70TEt/lQmLw/cH397x/4n2VGYET7y+8j+H9 HagNvlP/zp53XnhHxYD2d04gePadhXc05nfgZzjqn6Lp4o/w/UN8/yC6IL726grx1fZa8bvtBbgU fWKNwZeg/qU7X6Lf+eqC+AIu5TQYnw6n4JfhG4j59sYC0XwadFisPvf1cvGbX18QWeUQOpOd33wm mi3WfwOexUEvnALzicET0yceOqGaOb73+F3HOel4yXH5+BvHzx///XH115HmebCSFWAh3WB52lOL E5jk4gKu2/wIBB+GOx+GhYdh6OGZh/c+zD2esiA+xi2IR0Mp3Q/iyAc6a8VHV9cqMzu+6s1ufuir J75K78dV3rd6QbwHe56HDEjFYCOC65nOArH+m9hqh1R5Nf3i3bWi+e49d1PhC9EV4ufxfQQlcdft K8Q7DxeIdxxeIZLDsNx8GG7HSfbfUiDuu6VWnLll7y10545a8fc7YH6uUJxT5OKQPTMF4vSUX5wK F4ppek+3O+Tq1oS4bjUu9nlIA7uyBPczgyFRPg32p7PzmtlPFof9Jc1KrTks+pqHBmVxkPFDxP0D aZnN14QlcUN/idgfLhDtkNJtw13zwHWrkLFZ+UH9ILeHO8GphzpnOvd2ch3rguI6ZHA++vsoNbeL 7cF2rjUcElejPFrCtWIkXC2aw2I4GD4bPhf+XVj9UBil4+lOj3i6nSFHtxXM3ZaQuZsCqiJEuoPm BTM1mwfNe8ycmdQTutcJPJyGu052dfr9rac1Cx2tMSG6IQYHYjmd7FNe1x9TH4iR7v4NvScB7uj7 3OHDpCGjNVbW2RsbyuhrjY0gIDNgLwKWjJNO0tA3NzfvT7xgbgf7IjsQMTenYJS2/9ILEu15pGXA jo1zCTx+zyV65xYHIN8dSi9+wRzxK/BckgHOCUuMkXLj3EZlGbA4WulNksyxF+Db9T8Bv/icVQpl bmRzdHJlYW0KZW5kb2JqCgoxMTEgMCBvYmoKMTE2NDgKZW5kb2JqCgoxMTIgMCBvYmoKPDwvVHlw ZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9EQUFBQUErTGliZXJhdGlvblNlcmlmLUl0YWxpYwov RmxhZ3MgNjgKL0ZvbnRCQm94Wy0xNzYgLTMwMyAxMDg2IDk4MF0vSXRhbGljQW5nbGUgLTMwCi9B c2NlbnQgODkxCi9EZXNjZW50IC0yMTYKL0NhcEhlaWdodCA5ODAKL1N0ZW1WIDgwCi9Gb250Rmls ZTIgMTEwIDAgUgo+PgplbmRvYmoKCjExMyAwIG9iago8PC9MZW5ndGggNDMyL0ZpbHRlci9GbGF0 ZURlY29kZT4+CnN0cmVhbQp4nF2Tz26jMBCH7zyFj+2hwjMQaKQIKf+QctjdatM+AAEni7QxyCGH vP36N0NbaQ+gz/YM/mY0pNvD7uD7KX0LQ3t0kzn3vgvuNtxD68zJXXqfEJuub6d5Je/22oxJGnOP j9vkrgd/HlarJP0dz25TeJindTec3HOS/gqdC72/mKeP7TGuj/dx/Ouuzk/GJlVlOneO3/nRjD+b q0sl6+XQxeN+erzElO+A98foDMuaVKUdOncbm9aFxl9csrK2Mqu6rhLnu//O8kJTTuf2TxNiKMVQ a/NdFZmFCwJnyq/gXLhk8EL3F+BCWXJLYbbgV92X+KXyErxW3oI3yiV4q7wH7/Quid8rZ+BaY/LI hPIsLWqw+pfwodkf8ST+lKEWUv9C4tV/j3tJ/Wv4kPqXBXj234DVv1yDZ3+JUX+GM6l/jnpJ/Ink LvXP0ENSf0av2Oo+3Fj9M/SN1b9EjTz3H/ey+jM8Wf1LiS+0RmH1X0iu+ufoA6t/jnpZ/Wv48+wP Z4Y/W5Lv75TFU/3zjQzSPDEYKcz856ia9h5CHFP5MWQ+MZm9d1//zjiMyJLnH0HZ12UKZW5kc3Ry ZWFtCmVuZG9iagoKMTE0IDAgb2JqCjw8L1R5cGUvRm9udC9TdWJ0eXBlL1RydWVUeXBlL0Jhc2VG b250L0RBQUFBQStMaWJlcmF0aW9uU2VyaWYtSXRhbGljCi9GaXJzdENoYXIgMAovTGFzdENoYXIg NDYKL1dpZHRoc1szNjUgODMzIDUwMCA1MDAgMzg5IDQ0MyA3MjIgMjUwIDUwMCAyNzcgMjc3IDUw MCA1MDAgNDQzIDM4OSA1MDAKMzg5IDUwMCA0NDMgMjc3IDUwMCA0NDMgNTAwIDQ0MyA0NDMgMzg5 IDI3NyAyNTAgNjEwIDUwMCA1MDAgMzMzCjUwMCA1MDAgMjc3IDI3NyAyNTAgNTAwIDMzMyA1NTYg NjY2IDcyMiA1MDAgNDE5IDU1NiA1NTYgNjY2IF0KL0ZvbnREZXNjcmlwdG9yIDExMiAwIFIKL1Rv VW5pY29kZSAxMTMgMCBSCj4+CmVuZG9iagoKMTE1IDAgb2JqCjw8L0xlbmd0aCAxMTYgMCBSL0Zp bHRlci9GbGF0ZURlY29kZS9MZW5ndGgxIDI1OTY4Pj4Kc3RyZWFtCnic7bwLeFTHlTBYp+refj9u vx9X/VLrSmq1pJbUeiAa0EXo0byEEAKEQEgCSSAwSEgyBjsJcoLBgB1IQog9HseMhzgkxqHBjI3j OBCH+J+MQ8xMsGdi7JhkPPknv00gGccbG6u1VbdbCBzP/Lv77/ftt/ttS9236tSpU1WnTp1HVXWP jdzdjwxoHBEkr9/SOzwvZJ6DEPoZQmBdv30seFTeHKbpqwhh1cDwhi2F8Su/R4j8O0JqfsNdOwfu afvDcwjpbiC0ePfG/t4+p4wrEeoYozSqN1LAgfRONc2foPm8jVvGdjzl/jxNdlyiNO13Da3vbfnr ivsQWvUuBT60pXfH8Dv8CwShzmGaD27t3dL/b/m/p+13HkJIMzw8NDr2Y5Q3idB6xMqHR/qH7zr1 cB/NB2n/FlMY0D/2MtCkiuUx4XiVWqc3GE1mwWK12R1Ol9sr5vgCwVBuWMoviBRFi0tKY2XlFfHK quqaGbUzE7Nmz6mT59bPa0D/73/xDyMHGuJnI3P2844XOYE86DRCk++z3PRnetHkx/939kKjfIIV Qugn6COIA0afAxvqRH1oCH0O7Yf47diQgEW07PPoLVq+FT0M6s+mCiHIByOl0KngfR5dRL/5TMRt 6Ifoxp1tUNgRdAydYHBoorQOw49hEfRRGozyIvqx5rNI4U304yB976CfWzBkodfpivkXtAb/EL+L DqHvZftnQu8DFSJYSHv4fJbAQrTsL4iepb3QoQ1oJ9pDaysvfvYnbyLt5H9QWgvQjyhgProPPXyr xp9BaYPo0OQt2MpbfezDB8AG+eib6M+ogbfAGYTkxlUdy9uXtS1tXdKyeNHCBfOTzU2NDfPq58p1 c2bPSsysnVFTXVVeFistKS4syJfywrmhgNtuEcwmo16n1ahVPEfoaIsbw009wVR+T4rLDyeTJSwf 7qWA3tsAPakgBTXdiZMK9ihowTsxZYo58ClMOYMp38IEITgLzSopDjaGg6mLDeHgWehc2kHTDzeE VwVT15T0YiXN5SsZI82EQrRGsNG9sSGYgp5gY6pp+8b9jT0NlN4pvW5eeF6/rqQYndLpaVJPU6nC 8PApKJwDSgIXNs48hZHGyJpNEamxty/VurSjsUEMhVaVFM9PmcINShGap5BMqeal1ArJ4CDrOjoQ PFV8fv9DZwW0ridq6Av39a7pSJFeWnc/ady/f2/KEk1Fwg2pyL3vuunI+1PF4YbGVJRRXdh2q52F 001CipeEcHD/nxAdTvja+3dCerMQlST8CbFkE2Xv/v1N4WDT/p79vWcnx9eFg0J4/ymDYf9wI+Uw au2gtc5Ofv+AmGp6aFVK6NkIM7ODbWpbmLItXd2RwlJTcGMvhdD/unBohhiyrJrCaf3PihFlBGUH 5WkoxAZ+4KyM1tFManxpRyYfROvE00iORVelcA8rOT9V4ljOSsanSm5V7wnT2Vy4rGN/ipPm94Ub KY8P9KbG11F52sSmIiykTB+KofB+qyVYG1ul4AZpr+b3DQZTfD5lC611ewUqKazKfkHJmD7MPK6J tIF8izVYG6ZkGJ3GcGNP9n/7RjclECwpTiWjmalv70jJDTQh92bnqPFUWYzW6O2hUzTYoExfKhYe TtnD9bfmk3WrcXBZh1IlWy1ln5dCPeuztVKxxgbWcrBxf09DpguMVnhpxwsoPnn1VGVQfDaOKtGq BobsnEflKr9xf0ffQCrQI/bRlTYQ7BBDKXkVneBV4Y7+VUzQKIciV2lzIaXFFJ7X3rFwWXjh0s6O GdmOZAoYOU5q/BSZcIeYIUNFLqWRNMEOLJJVFFGggGATTYTrZ9HPlFrS0LdAGa5AmajWzwp2gIim sGk3UpFgY39DFo/l7yDKM3Gal5yipmJZSmdeUgytCmVeJcWYFgezDdMaGsbU5FQRkagmoDBMySgg xks3k/lgR7g/vCq8MZiSWzvY2Bh7FC5nmaHwPDtX7XfkbmMWZRMK0eKpDGNmqikq3s7cVLOSv5VN fqp4/lRxcL8mvHDZfkY8nCWIaM/npxATYXmGRVRWP1vP4aZeuojpilbW8/5TsszW8ka2bPeH5/ft Dy/rmKVgUw3yefFe1pYVLYSF7fUlxVSZ1Z8Kw4NLT8nw4LLOjhcE6kI92N5xGgOe11O/6lQeLet4 IUhthQLFDMqALBNkGUapjWY0Cr74gozQuFLKKQAlv/4sIAWmmYIBWn8WZ2DCFAxTGJeByQqMvegs uTdSHlP93RjsY/PzuVUb9/esYjKOnJQj9B9SEJ5DuROecwqwypDShfvrU/pwPYPXMXhdBq5icDWV DHBCSfG9+4XG8J/cJYpxRA3MQvLLqcerRqWnAMVmnVZz6FrFKRX/1qzTBNMkOkUYmGfg02oVfDLr NDB43BKySCFLqAEH03nwSHojv/zjpxs45jMAaqR0/4X6WHo0Ty5BnTxvMF41QtBYZpSNw8bzRn7c mKIP0m0EBsJ6VbeGIL6bWFHdtQr6D11dXdtGLNba2LXyMsnlCFXVWAqqQg41Lj4xseXECfy1E33e BQu83N3i/Pmi0mYNQlw7+QkKou+/gDSTl2SfVkg+avqO6QUTMQUNQtLE6UGrb+YEu4C9wtnJ8/J6 nTEpCLl5ubA6F7hcey6uHcvdnXsh93Iu15oLuCxXzsWtuT25qdyruTdy+UAuDOcepbnzuVwsFyo9 DR7sQa5mlCPknM+5lMPl+FoCZpegz2nxOkwOexviBVQXv1ZHR1RBhwWxLppgQ9s20j0yspYm6Aij a7uure2KR7vKy6Iwh8Qr/NhhyQy5Mj+cq7bcGj6cDixo6yip7WnMX5suaW+uX7RoRbpkzRrYQjqF /KDDX79p4cR33fX1bhxrX5s7MVdJ/tldz/gTmnwf/w13PxLRSrl2I4GZZAHpJERPRBIlBDmh1QlO p0Fo1o7zQDvOB/lLPMfzOT6VeYleazC7bEuRk85PvC5+8VqFxQq1sa5tcTog+igvo6Pic0txlSVc VQdxR9wRttid8YrqGoeJwHMLNzcE7/vK3UdeeaW6OHeez1Q9t9meV7cyjjfPLXj99Y0T355br1Mt 19nNOkUumyavkQ7yY+RDhWiL3HKPZ68Hb9fv0WNzXiAPC8IhFaiagnlleXLe0bxU3vk8VV5eUayo rqi7aKhoV9HJonNFrxVdL9KG1c2XRBBVS/LykMW41On0L0F0Rq7VTVxkoqXMRxdNdV3roqNggwDK fR+EHHY/znY+zEZVWe3KNWFHvLIUw++X7VkbT9v05f2rEsNxV9OyNSU7T2yp+MU/5JWKujd5WyH5 cWHv3+xsE+bd1z3Dql9synEY5S+c3fHhH/uLFm2dN2/roqKsvJJe8g/IjR6XbR4naJzgsYHGBrzg EDDRnJ28IRu1hqRmt/qyGqvVXi8T2bzyymSPF7Dglb2tXtLjHfYe8qa8572XvCpkbkZ2wY7tFPFZ X26SPWW31Zm0O1rcZrO9xeowoUktaGX1uIqywXvRe7GLyaUimtEoY8a27m1RC2VInApjdxd7UZFM gCVcQMd/uyhe9C5evaGqekYi1LKo2fuNiZ/fey8cwL/ztTSVpb/zBUEMCRM/mRa/yUkUmPzv3Cy+ 05rPQiCLGmnRr+lcu+jqB58lH4OmutjglSBaVYXYW1nTSh0ameWg0/KXZriSLjzDmXTiDs1GzQ4N malZoMFEq/FoIhrCeUDraUacHXR2u8+f54fVfuD8dB5rx/y7/Rf8l/1cq58yzl/ml/2k1d/jT/mv +m/4+YAfhv1Hae68n4v5wdx8XTepw0gn6LDO05LjcOhbXCazlS5mp7KY4xl+dVGhuW0hM11FVzFd yVSMFM5JWdlh7FLWgsI4xkL8o+l1DLuUZQz3rEl/rW1qEeMV7vqJe+gSxufc9Z98j3IQoypuE76b 70Q2VIBr5CXm3Xx4t9bj8WC9x1MYqY40RTAXsUfyIuTmG5HfRj6MkGMR2B7ZEzkSIbURyI+APQLP RV6hZWR35HDkWISsiAxEtkdIXgQiTFQm//mtJIOfiRAG3xMhlRFQRZyR/Ah59aMIvBuBNyLgiUQi tZGdkX2RRyMqfQRoQYbOc5Qyr414IvjDCOyLfCfyQoYOZrBIhDzCID+NkAORxyI4Q4UwwC8j5LHI 0ww0PzJICXNGheirkSuR9yLk8cgzkZciZHPkvsiBCJkdWRzpipBAJMbIwkaGcjNCGMrFCGEoj0UI Q9kSIXURiLLuQmS8vSPJuvudCFkdYZQoCrD2sT4iRvDNCLwduRbB8o6fRuDFCDBEnG2wlnZqVYQw vGiEzJiIADwdeTHyKm2XOxh5IoIZPEFxOTOryzpNGPxkhERkbyAZuDWQk5FzEYwPRaAusiTSHSEo Ahqd/xAy28GO6IKjRo/KEROdbVEqVvTVzQQr89rGXtGRzGvtbcCpbCaZzUS3TWVZPiOZE7+ilhQU XTYHKzbGbsKhT+Uh7SkO2WyhYo+nOGi1BovT33AXh+z2ULHbEw3aKIDbNJWxBaOe2wun8mzdFlLd 1kPXrQsPylGnKd+0wkR4ExDaAl5sNNmNJqPsEJNGo9bpcQ46dzr3OXma9DDF9clkkj7H5fIPbya3 e6DPA20eaPJQawtOT74HYw986IEznguedz3kKQ8c9sAeD4x5gNV+7p13kx9kkrLll28lj3ngiAfs njxPpYcoZIVfvJFUeeDn73rgZc8/UfvNgEsu/DTZ5skY9HyGD7QVSucNz289+IIHTnsAjrJGdnsO e0iPBxo87R5c5oE8DwgeoLrnhgcueC6zLh3NNv/lJ7+dDLIyuwd/8xLrMTztgXFlRFcojvzlryUp 6YNK30VPwoNf9bznuemhmoxR7/Mc85zxqLae8XzgwUdZnzJQ1gMV+7hMC7jVrCu0Niz0rPYc8Dzt edXDU0ZNtTtjihansLa8OsPaZeGCJCNxzEOG2RgqMzjIA++y1l71wCHKgWHPuAfXeZZ4MPIInqCH aHQ6M8A5eA0wgNuIW6hTAKaWAuo3IAeqq+i6VkuVY60F4swxiGWlWRHTaPSWmGZFVoHektnolIzT V/ct6Y2yMlYUzYj0lFCPRKPCz9dSkx3dG937+QtUrmk78SoIUxtlhrAl5IB4xRxM/RBSCKnNOTXl +bpAEr+Zbj0izq4tN1clxRIi8Vqj5jFwl3/yjtpg0f8y/c2MT0xdYyzyD1P75ENj8lL7glbdIR2+ pAOdmnNzwLkAADUzB+kST3jeH5ADrQHcEzgaSAVIIACpwPnA1QCJBeoCBwPE7AlQGVtmRqoWrRnx LcSR8XDrrnWBYj4sivtR0RXvssQvbxu5w92F25YmMyVwZkPaOtAD96dfdxfNCAZnRNzuCHsWuTun bC0kbwdTNDamZZPvc2vomHJQFB2Sc1xe6gjv0+P9KtCqmNmki1YSpGGJeCUmus1aY1KSSlAJoBKh JFhCEq0ll0pwWYlc0loyXHK0JFVyvkSNfOBrNmtA1rRqLmmIRrGVLS4UWWI2Crmt0+aSjZbay23U XtL5zLq88Tgd6tpbdjI/o4ZcpWQ2ZK0kZH0wSymdWBV+21VS01h66WcVg38ztGUIUxGkjNiQPpLe 44/Xh+OL8yPJks6+KrNoM1z/88jZLzaJ+sKSYvPv3fUfX6RsubL1a6vy3TZ8Qa/7yVS8oNpL44Va EpIX1VQ0V+Ca8uZyPFiwswDPKEgWdBSQwfyd+XhGfjK/I58USDVSs0QK8mrymvPIoGunC7s0elOS aS/sZKkVwoCwXSA0srgqT1IOrlAPqLerCdGows4w1oabCwur3M21NlDZnDbstCXyE+BJgD4BH99M wG8T8ELipwn8VAIS8vX/SC5MgDYRSdQmyC8THyXwhQQ8l4DBxM7EowmyglWMJOYnyE8Tv0vgFxPw nQQ8loB9CbgvAQMJqE1AlNX3JPA//C4BVxJwMQEUbU/iSAIzInhhYnUC17K2zpxNUsqMLt6cgK4E LFS69TvW6tus1VcS+FGKOP7XR5MKxUdoby8k3k3gI4mnEs8lyO4EbGddg/YE1CegMgH5CXkSuASc SVxIXE6Q7RQPr1PK8xPViaYEoWN+N/EBG+wriTcS5FHWM1rclxhLkCaleVp74x8ZFjAMfJgNa4/S YxXlG6bwNxh9oOzKtN+XAMqWvERlAjsVbr48Vc7Gu09hWkMCqrNsmUEp/FMC4HwCjiXOJPCBBPSw 6g2J9unuXWIDhVQCnk7AMOtTA+0iuZxgtXBrYjgxnkgluLoEoARoUFkzqhKqzlddquKqqmV3ywxz WWHYbatqkZxxR06bxigU3woI2T8LnabDwinbf7ue65629dPq8ZYSvNM5mIJmSqLT8OjIp/Gna0Sn 4MJb9PMadfyp/1pRXtbNNG6GyFQMEK9wuv4yOFWp/XBn/lPR6sqSljF/cNnqnuLatfPyWNQ6tz5v eQHPZ5LSYumOCLZ2ri2a574zjnXZHOXidNZpmWiaDiwwqp98n/ya/Ij6HFXoaXlnxAk6p9eJF9D4 1ApFVtBbRSuuJk0Ec8RO8gjx6lTNw1XjVZhN1yE2XdqqKnsNqoGFrTVUL8g1rTU9NeM1V2tUspIg ueEwigkxHGu258p0Zefm+iMtXi+qWKozO6lid/hbMmElm1jGRKbiIHatKx6Ld22jDM64YNuuxeNK oJzh6RQrC6ZiTGaxqhQuUiNWNYfY1CbiyATROHfxF9dWrk0/5bTF69sq2oYa/A2jj664t6G5ZnVR fn3pshXdO9uL5ahjVllZQ5D8yDu7b/7E4+76pDGYYytauGFW71idHZN9y1YGHHf/q9qgU6VdBNtj i2Yub6VBIdOHcbZ/Qm2ExPZPjFP7J7bv2F6wERvbP7FxAmiFZs5hd2CvY2r/xOEoyCuA1QXAFdgL aKxVsLvgQsHlAq61AHBZgVyAWwt6ClIFVwtuFPCBAhguOEpz5wu4WAFU+hv82I9ymlFICJ0PXQpx odwWCeU4hFBLwGFzeNp43f/Z/RNqKdX/9R7KGaC2I7CwfdVf7KNQe0I+NEeKI+b/dDOF+yUVOkD2 dBN5n/q3YRyS/R4zdYYgX1etw/naai1eqd6gxrzaocYNPPA0jH+ORvEN1HNgEf08mnYCJBE41aBW q2gwrFZBm2oxJUr9Cq3JY8ImNYWCFlGdYhSMWGeUtF6PN+IlBuL1eFSgxGoGcxJUUr7UJO2RXpF4 p5JcIQ3Q7FMU8FtJq6KANyTyixXSEfbUShEJfyTBexK8IP1Uwk9LsFPaJ+HNEsyXVkk4KoFW8kiY lv9U+qWEH5OelrCCsVraLOGIVCvNl4jIsODJ30kfSfiKBN+RGC3ymAQD0nbaNJHkrx1J6iX4pcRQ yEWJxkvSixI+KAFtaIkE2CzFJOVjiTQkHZROSq9J1yXNSECqk7qlXdIT0jnpHUk9nZyUVJLcP5xk HooskZpxCZAUlF0sQxNSjzQuHZXOS1elG5JGrfgvTl9hkjIxz9/qteUYNSpo0es4YqailFG6bJXS JFDJ2aYoy21ruzJuJ/3IKMVPa1dFXTL0WDROV3X32i7hFaoqLbV0ccfjXXsF6pJeEPZqzpeXIebZ TWtPHpSNSzHzgMxiL6iKu/yKk1oDP08/WA+/Hn77J1sh3pB+OFi/dGNjTkSSnLOiprAnMrsi6vaR ISp93ok/Yx192j8Zantow0wqY/wfv6A3FDV3V7GzfurjsVNsE0rLc2YYYIYeFHGU1FVs+8ilxpKq SoXVKpcKd2DYCDsAE9BAGyZ4sVZj12o1OuTUPqXFWurBPGuyJBHjZZJ6NoQ6w1pCeM50wYR1JuEx 4UXhikA4IU9oEPqE3QLPZRPHKBPeFdQ1lTR9gWHYKXiMYSgbrvk08LgpAMPCPQJgJAQFWWgVODWv 0yDSYuDNWsDMb4zXKTMFVG12KxEtY/424QJlt6t2dswdY/tVljjl+97oBYgzkzX10kL4dpaTH6Qf 3Jm+h7H4D7+kLCYrPjlCBhR2/jv20mdW9w1T3efBP5AXqm2gtrqsBVZC1YalwEIGjVCgAZ3Gq8H6 RvVyNf4WQLN6JeWqyaxSm1Rmk3o+rKJBkVqI8aDiVbygNYKBGLVszPdSBmpFuwgqEdIfiPCG+FsR nxHhSRF2i4dFvEIcELeLpEEEp1gt4lfEN8QPRUIR8mm2SdwjPiXyl8V3xQ9E8pT4nPiKSA6LsJ3C cYPYLvaJRMWq/fxR8Tvi78SPRI5VwlrRI2KRNT/j2eeSteJ8EWd6wMjjVeKg+KhIEuJChhkR8aO/ pDXxngz5MREGRBBZoPiF/Q8nVaJTxB+JcITV3KmUtbPO0VZ+S3uKL4vwsgi0v6ynmFauFtmQiIcR pi1u/FCEYyKwkRwRiV3MEytZn4G19aEymIHMYJQB0/4AGwb+p2wXDtTNS24XYZ0IIIutIuYyBGoY Q/Al1vAFER8QYViEPlpFTIgYiUD5fFWEw+Ix8bJIhsVxEeNWsUfEdSIgpWiJOCTuEg+KHBIFsUwk ajMSmpFDcJx3XHJwDofX2eJBglHjaEFmTm9zgKqFMyuhW9xaW5sxR0qgS5NrM1qi+3YvbK3izUXv cM4+7ctNu19dWT9t7a3i2+gIr0QrqL6x1NbGYl3WWhYoWqyotnYvfz6jbbZ1rZ2SfCbwNEZXrB1R O263ekN9MHDXVZjXnp5V84PRrnRkFbV38GM45Kqvd74/8Udm3mB+60e3zNz/v/962/6rsqeFncq+ QLccfhTDo5TNd+wE6PSyvlWPe/RH9Sk90bPF5yuvTAb0kNKf11/Vk5i+Tn9QT1QtGnTbTgAoG37Z fQDa95GR2zYATmYD/s7pWWHzws5HOmnsWoBq5dD2HNhuALvNVhA5GXktcj1CAs067xLZNm4WCvKW Mq5NvFLn/Zn3GnNJhZ9XxBQvVJp2O5lvbwkXlBK2gTJ19EE63XMXtxXu+eGOGQt2He9a8Wh9skgI 5EVzChYk8lwzB1rm7iquteXYdPO+8NzY/S/uqHWY0v/jWwaLni/p+mpf+/51VYKR9VXZT6EypEVd 8uzbt1DOZ46ZLvFX2TGTXndrhySlhx49UL6dZ6yDg3qo00NMD1NrI8O37AFUduvkjm2TM7dzber8 a87k+/g9yrMEekau6p8JK2YCN9M+M28m0YW8oaIQ0fm8viIf4bEDS5h0VG+sxk0iRAplwZ4sLERJ 5vI+6/EpT3mG1kld38Bs82yIzT45G8+WjULSoNdXJM0BGArsCuBAhYOPtciR8TzB2iKPGw4ZsGGc TYb3Z13ea8p8UE2i7ItQhyKakeBo9FoF9TDYsu6CbJyQ3fwpsFCXgXq21VWVNFNKpibOkZk4FZs3 ioDfK+n6cm/ZuvY6Y32+ubh6Tmjlck/1spllPQtjVWs+19z0cH190FhYXu1JNvpql1bVrJtfBEUL trcVGywWOiO7zT63aeHMYGle0GouSW5a3LCxWbLq/7DV6LbqE/FQaZ5fsMSa1ylnOnPSnYyn1nzk QsiiQp65CJleQDD58Zm6pQHETnMUeb2P4gVQLfKgDS8gF/UutJakje2TlBgcSbMxYIwZidkcMMfM xGg2monuSw5EBIKJsVXoEbAg0/BDEMyM8TqrN2lWkzLm8cS6Ki7GopRr2y5SPr7F+ElVJIsDopCb X1DFPCzKrvyCmrjaT5QNbjG/Izd3kScemdMYH3JFGsrFwqbudKdg7tTqKvKKY/yPt6rckZkFFQsr vMq1MlSdnkXe50Q0A81Hy9E1+dvRathZtq8MdxRDpLi2eH4x0RV7i/H2/D35WGV32vPtRMt5uAhH IgBeAD3AsmYszjAbvIjDyCpYsbV5cV4tls225MHFkFwMwcVli3FrLaBaoTZYS/CMxbW1i2dgbmVw Jcw2ywEZy8n40VIo9SKzgVO7liyIl82CWSHzgsCC2ALyTghaQz0hvCC0IKRubI3ktC5RZ+LRjNGg NuRiV4VwjbpOwE4auiq2WV20gBaNMOdKuChcY34Ve04HqEz28qdOB1w1LhbqK7KYX0C5mYAK59S+ JEOqoRIJNNYKmSCjQeZgUJiviCYNeU7X3vX4+mB9bbHu1+GRQGDG5sf7C9sCbrAHi71XvnW6fMdP Hxl5ckO5WDY331peHMDP189O/zgSs1eualwysiCcfntB/dyFjXVzYPXCN1t3thWp1FoyFH0yf9Oc pfe1F6n5ReYcl2n8wTlfGJDDs1qLfRWlUac6FG+IpF+KlfkXRFyleS5KHA+Mjo5u2UI/EEZe6jMH qU4XUBH6K7lgRx7sCcLuALgCBQHMB+ABAigXtLnNiKIE0TAaR7xVcYvLaeiLUDEqBlQsFAeLSaK1 +FIxLiuWi1uLh4uPFqeKzxerHdpmcxFcL5oswkXKkYTWlCwyLClwuvlWn2BpsSFlluLK+auiy6Y3 SDOWLDMNdMUreyuZkEHZILWrpuLc7Jzgm96K+aX5nb7g8sLqBTH7xC6qAXneObt5QXjwcHdx7cgz Yz1/egD+MLBvWdhimSjXaKoH/4p82zU3/W1pY5k1x6GvHUvtGHlp36ICH+NNehEXpPoyQDX4k3LE 7QO3l6puuwvv0QNH/1W7VRhpQKtpRkEhGAwOB8eDvDXIxllCuRMMxlAM2L5JMEa5E7sUw2UxOdYa G44djaVi52PqCHI2X1fcvPOyi3JGzGnxm0Vni1uMtgpGp9R6225Z9oxaif8/m0fKFtUUM/zEB7dt o2fZx7ZS4FFnVd2i0gvn4pueHKreOAMIwP6J6wMb4PPQl1NWF46vDC3t6FxBPsd2kn/755EXH5hv NOnzoxHzRcUIn3DXpyu3fGV52ClMJByvKHpQ0RH831I96FXOtv3oO1R3OM6QFZZ8cnby/TOr+0vz FG3IFCKgAq4H38//LbKhEjlHZXVa861Eiz04golZ5k38uPagmTIeMxV3zXuRhkHenym3E5gdiGcD x7iJQPvi4QUS9FsGlhbOLQ/r+3HegmGup3zF9qZlDebwzGjT9hXllMzxyX+F/yDn2dkxuusFJE3e eFZwJENsQ8JEE6JAP1zsw3I2U2RkRYU0oWZQwj7C5iMeZq0xz0cK7Y/5Bd1jyHY0Aoci1FBllI1i kal7xhRw5sV/6oCRfPrAcXF4NjtsnB0OzyrxektmhT+V9zFY7myWnp3LYPgrGawSj6ckg0X5GUZI 5eJnIxFtluca7Hq7aMd2SyeNZ8Hp9GHk6/Fh2dfqO+pL+Ti1yNFwDItaTyd292i1WNBrSLeRJx6n BXfbkRXVVWR3Cehn5p4IEztLPGOj6QgzHkd86lKSJZR9ZkSO+Zhh5Y4SzjuBv/7MMxObT0y8dWLq tlJagBvsefMAu8GEXRO/8y6gc9Qy+T45TdebBUlon1y6T4C9BiB7NfAgAQ7ZEdaiZs5qt+ZZid5q LeCUjTZSxzbbcAFzTWpnJ9lTLiqMJq8W0OC6QC7oKThfcKmAf6IA5ALIaZZ1rbpLOqJzLTELoSXM GckczTBPujtzSKe40dl11T3tfWS9DV5ZSlNO4hxMTpdv+vb2oScHKyo2fWv0nX9MXzEEZ5QUV/t0 Ol91ccmMoAGu7Dj7hbnyF17Ycc/zn5M/+kPvV9eVla37au+6r/VVVPR9TTlzm7yeXoQjVA/bUBR9 QQ76cwrQ9LGbNwLaCETszagAUnQ0ymhlQSskCwqK2SHV+ZKrJbiEAf0mS9LMB6iMLjOjwiVRc26r jHyCL+gjvnGPyK68MN9LOX2b8riY/9XVxY7ehJ9Ryb1zwH5Mshrl1oaNEk/giLtoRiB7whYM0Kdm zqYvt5Z0SnJUZ7c5i0L2p+C/cR/cjkGfH7+y6Rs9xTrNr0c0enFWbzM5mFvP9IdyX051heoPUPRH HpoBLcgm60Hk8wEZnARuaQ+mP17iOuGGwi+XbNAtQMx3wuZlPDMnXcDuzNk+dXT40qcPDFnfPnVO mFlHEbqOPFAl/zLpYhJ4j36vHu/TgEYD+9SwWr1ZfZ+a1Krnq3GRGjxqUHGg3Umgj0ATgZVOIC6s UUObFqs7OWLnOEI0WqwlGqylgwGsI5gD4DDhdBwPDl48I4JeFMWFIomKB8QXxZsipyzPCyy+Xyiu FnElw4BavRilwf19FOkxivaq+B5F1bGq+FXxCl3Ock4wmaItBEW2TzAuHhV5p1bXacYuh9Dt1Bo9 VqLjzN1qoxUpK/tWIJ9Z3ezIY9tUMD4ywnb3LBkfiW3f03BbYPH2XiGqiQoXLGzHCXUrLvra2/0l h1rL7A7ctuFM1QI12PxLx9KNuOXz6QVp/diPJjqoejj8DF5/Hz97vje9c8Iizsd7+tL1TC9w273z 53snfoVzvfPpnByjTugRPol0qFIOoq0HM1GTzLfSqEml1SC1wLb3tCrEjxF3ZoeCqihrrRIh3wqL 1FVSHD/zuwnTv/93uPfLW90rVrjJfyxa/iuk2K++yff511XHqfwVZu5mwUUqfy7ZSHAhn08wP7fG 7r/jbhbO1OEXKTalSS69Jx/GJNgRhHtpOOoE/+pMAK+LxCJ1EYxWm+0BqpP57rDN3O3hphXPVNib CXUyWqUqq2X4Smt1XryCc1oddqziwrl5+RhSue0Pb9r0UHtubvtDmzY93J6bPrPmNJDjTwI+09Nz Jp1+8sl0+u968NGH3nqktfWRtx468ObhlpbDbx44Dfh4a+vxdPr06fTN7y5b9l3g2TjsNBg/S/lr por/nHxvUt2hxitVkK9qUmFOZVdhi8ksmM0cL1iNBsHQYQAVlW+DoBIMnWqVXa1WLRQACYKAlang 6IfApF5jF+xBu2xvtY/bD9lTdnWZfZgmj9ov2a/aVcRo6rFaLCDwnNmg5rp1kBVLRS5j7DYQjQwt 8Rh11D1su5OyhwqfgH60l6cCCF3C3vPnqRha4u7YXrYPpESLEptrCGX3f0IESAhOpDf2wduQC1cG Jp5+bHxi4j64/204M59J2rs3c5jEwer0tzjvxElFt2yhPnEOndcEOi4XcjF7DFeWQLwY7MXAF4PX ClordAqbBEwCftlgTvr95WsNyq0BvSWJKIcwNhhmO2Kz62YvmU39Z1S4FjnAscowaMANhWOFuws/ KOQMhW519xcBxgAaAWoAoNoW7l4ZgICbyka8i/p8bDwsoqNiQSUkHruonKLRZcoi5Iu3lh972TKR sSI4qqrKaiVgYRsakLVVqik1WLClo8Qht66OtWxtCMzuH9873j/7D/9e3t/Tkb+qpHiktaF3Ts6c vvv33t83Z8a9P9w7d3x0XS489s/uSNAanrOyclbLjGjZnO4H1596QW0QNOkfnQ0WiWUNRdXJyqLy uu4He9d9c2iWwe410jWl2HPlvmMoe9/xu5S/nucIzqdOIT47OXmmrkqHbltVgDqpn/YUxOiaqpNz tlv2WPB24x4j3qnep8Y7yT6CzUeG+XFq3hi/9dTJ5nmHnflhKOt9RafW0qcdL6rbsw5W1pn6C8cq q//VbVT/u6FYfv2LBhg1QJ8B7DzwPNg54DnYB7ADoJnOF0ABwEa0A+FVCJoQFKAahHkE/UYAI4I2 k9HU5UZ2N3K7rZ0dRiAqo9OItS6j0aXxeuX21cknvCe957wE13mXeHHQC2ZvwBvzvuZ9x8vPiCll r3k5s3fIe9DLUFnBda/GK8+uT17yXvXe8BJWQCOVoJfdg+XUVPRIFw1JNGPG3UZsVFm03W6TAeuJ y0o03Q5AKuttZ0BKwlqriFdFLL52+piB3YGlkseOGdjxAxW+veyYIaP1b0nd9CsUhml9r4VpT5CM 1KQtZ9LMGTTDLtiLvSdOTPSf4bbc/N+mNP0nXyYj87039yt5LZ2DINVHNXQOHKhbrtd0aw9S82nr xMZWw7jhqOGGgTMIGDB2upBLcJW5ZBcXpB+trmHXuOuQ67zrhktjJT1GrY7YcDfKXKhnI4Ws9/pW 10Vhgn6Ul7EeZg6bqcvKVkuUDQOqX49/6a8kcTXvWiNKz2wvf512bMig+QjuSe/7SKO7+TVxPtOb 6/F/Jy/xbdTnrkEtcmkkChEz6B9B3zDz56iEWgseyfmGOXQuhEOBUigtrZ1REI/rXcdzVY+HeE7R de9WVLCtbBY0XOiauPYr9qHsfDHnhV29piuXm1q50mfA1peue2xLbUvM4cotzHV5orNypeaaXHj5 M8HkePP9W1f61ljKqyttDq/DESjNC1bkWj3lydh/WkLHuZiO81h2nO1yRX4U8jPjRHxqapwolKLj fK0UhFtDdeWGVI/zx/UuNtYPrsXZULOD/dRolTPrqjmEKi9uasnynwEjx0p6/2pL7WI2roJcl7s4 EZaaqkNpuXTdX4BrcrmDzeNbVvq6LOVVbFBOe1AZlMVTkSz7T0uYDsij8neUyp8d9LJ2gwmWm+42 YRoP/ll+kHrXdxvAaRgwYLUB7taDUz+gx2o9aInJzFa8uceO7HY7MhmhzdipUds1GrVRo9cmtPdp X9Te1PJatdnO2S7YsA11cmrQqdUOp+hc7cQLnfc5n3a+5+Tszjwn5pwNzjHnGee7Tj4hOiHh3EwL rzi5q064TEM6pv0kiz057KRRjrPMKTt7nNyAGuxmo6ZbjUyEs+gIqLq5rPRTG8qWPF253cqRjLLI R7L3Yn/eVVEhsI/MGe5ed8bFY5cKs65dlE1SdkVnThYzBy1qcvD1Ce/r6Y3fwKfPQAUUHoO//zIW 0u2KTX0KX1L8uJ/jCvZUbOsK6ssdp7Y1F/XLssYCD+phQAXNqpUqXK0Cqy0317tVK1/XTmox0gpa bNPatHmhMizjVnwIc1gbso6bRl1qHLoHmK9XW3fN+zPF1Ytn9z69AtVllqlrJhGomsNnvCllmc+B zB4Jpw6R4598b8VX71kzOxisaiqYsyAQXdn6aOfb7+XPv+vhE334qy+t+crnt+3c3zF79Wy/1/sy lFs9zx1vvX/krh0PrVLGYqZK4If8kygMJ+TJ5lxoDgEfAI3KraLuvl6CyZsSnJEuSFiUDkiPScQs wbvSBxK+T2I3C0i7BAkpczfgMEsulDAn2SX881elmxI+Jp2RsJ5WxO9KoNxEaJf6GCl2feGCdJld X8jUjErAUZRXpSvSexI5LB1jNxlWS/fRupxC8Lo0yUhtzoCitKHHKO5NiQ9IQLs5+EGm9dXs7kJP XzImActsVjrNS3J7R7JOubUQkLqlIWmXdFJS1V6XQJIb5ycvSXCOXUd49pCElZsH9dHS5GuswaMS 7JKA3U24wYYeoH0XBbPX7G8ml8IQDuf5wy0hB/ItIV6zvVU2CwEhJhBhXAtTBwTKMVeFcsbItiNi caY5sueELFDvZqdG0cyZYea8cPr08PZr4dmi8rJu5datLVxVc2tT1zHlI/mAfWFHEfHHv/zlyt6H VzljJfkm2acNuJyS13zu3KMTVwdIQ2NB//qvr68gvJq7ukVrFmf3Nu3bOOFkG2NMJvKp7jjJ9mFw Wp5c5R307vQSrWfQs9NDtO5B9043+bYDPEJEwB5zxIxXUE2y3UBUVIts1xOVbkC3XUe0O9SPqLEK OzFWAV3gOjuyGXmTwWEQkU3Fm9RetZ2mkF20ISPNG1UmaKP5Ht5k5yketHnV3k6Hwe5wGDQO9oUa tRrUPAjEoFZrTDab1SpTRaaxaqwc4nmO6nun76c+eNr3og8/6oMDPhj07fThhG+hb7WPRHwg+sDo g4984Bu/9ofk4z7Y6YPNPoj45vtW+YjW5/Flkjt9+3wvUFIf+XS/+J1P/in45J/9Y/IKrSdf+Pvk 55VKXT5Y6IPZPshUIz75+e8nH/M97cP7GP0TzyYnfPA7H9BaF31AIce+ndzsu8+Hu33AeoQDvpgP 633w1zd98I7vug+/6oOTvnM+fMD3mA8P+Xb58Gof1PmW+HDUB2ZfwIfHfId9x3xnfJd97/pUPT6o 9DX42n0k6APOZ/fhG+yZgXF3HaNYH/gIy/b5WMUzPpWP7S6N3ptUnl3rlafs7VidDE7XHPPt9qkS F2hdrBQnGxfRfkM76zW86HvV957vpo9j7VVSwhxtE7ONmTKf7Bv2jSsbc+d9V306jc1kUHcLWuJ1 IL7bTaajIiVUZ+6YItFsBWyLRhWHretT9x8z6yDz9aXorQuQ0Uyd6Wvn7CW8Qu1yjFlmpj6jio2m fxnNn7lcwgwCfWQP3Ke3AthlH032kxqLtXdsBWSi7qyZsE0ZDQUIsOCpdPVhOJke/wZ++Lv/A3xP wauH01+D5x+ZGP1u+ld9zHrgPNzGrEb6CGxSnuUTqxSrcu7/U7E3jTf4X7L9Jqo5dsvLdubty8OD HujKfn0h6d7oxmZHwIFX2aHZDh6H3THh9tjdbo/baQ95O81mcBaWFV4qxCHoVHnsqCcU4oI96m4t cVD77+am9nqusSuZ1zJ7PV3CTzJ3NDPXh5TvD9zawJn247OBk5rNmpYdIVDvmDEI609M7HziBL7/ +G8enJlTt2ERDHwl3ZLeD+pg09bFD31lyZZ5PjwjXTzl4Nes37+sbqRngSstiPPxDHiodcMs98Q/ BxvvyuzlUR5w91Me5KB/k592i2tSXvB6wbDGrI/psVbvT/kv+XHAH/PX+bv9u/z8Sf87fiz4g/4y /7D/kJ+/4QezP0BLz/m5mtf81/3YL8+Wk2X+Vlo+TquzCxZmWp/Vfo1WnvSrr9MPrBA+6QdEacn+ HoWaSu2kjAy6we1GPU5RjDm7nUNO4nSqHD3aIQMYDIy3064VDY26hGvKpniMeR5s87EiY3kyazSz mfartV3XMt9zoLyeZjELOrhcytdQTZymse6dieYnTnBr1wYdcxcuaZ5p3gnNgVWrAnhWunCKnelv XCMcB3jiynfTs05Q/onpH8NpKKEyVCHn3HLNgR+2jlux1Sp6FTfc8ZgXCR9UfHBtOt5gzrd0h5+t bBzA6RIWPlB/2kn9aWdnY35zTWhT864tSoRAXWa76HBQl3luA3WYaZzflO5kdzFonO9Q4nwPepzO q/458EZn66aOwGk/NdT3+xM5QW3jsDzJO6ucjc7lTo53VDkaHcsdXJENdlgftGKdpcgy07LAwumE ImGmsEDgdBp20aZTw+nUM9UL1J1qTuLhHhqNE4lUkUbC8VjCVbgRc7xHZbDrjZzR61HZ7Ozis4E+ 7DzNIk7gsNkasGKtCtoosMWjsns8Kiu0cUZusWi1i6JVpecNtLJNtFoXGKnN44ZFEO2NHmC3e/Qe qszLfGD35fnw04pGJ4d9EGVGifPBBz7Q+6I+ZqMOUHP2nk/9LxR03nfJh5kRwZszNSt9hILl4VeZ bWBG44yP0zMSFMAymBHZ7CPHNytESMN0mwz7MDUwXCs1Huas9Qv6WqnpIDS7ndqUg74nfCd9hB31 YKWY2Rhm4BSbZFu1JjmUwcgeCtT72BWznNlzqSljlcZ9h6gZUsmKRWL2iFdsXu2sjO0rr87YvkCk NBnwAfKBx2q0t9i8Bp4DwenQqzixRQPm6Z28TODB7oNGo9ReKd90uuWdKbdNp9K3XRLLppW9h/gr 2yqEt7oq2H4Ee79ScYdVYmZnL7NFf2GPbt+fsDHz46q53QoVqLMWKgAfDu77u7UgL0v/GYo607rB Y2+uTZ9vh+L0H8nmuXPFX7zumTvXkf6HdLVj7lzXxCT9FKAH/obJ9OLJ98n3qR2agR6WK/fMgAfK QB1zxfbGSIewUdghkD0YCgqr3XohWe0tH/If9EOh1+/3FhItGjpkAxvjZq7WlLTZamfqWrWHtFhb 7blb9npNBePh0VK1aVTWjfMepFyXyQQ7Me81JeDJHN5cy1xkoErIUhu9FfdA9tCG3Dq0ofo7BlU1 c+D2aGjqxFjtB/L9+l1ntw/8sMWwpjLYXVPfIwfy5iwvGxtetdwXTxZVN9L4KC/ZsqLi7d+GGgaT J56CLasPrq90WaDxn62B4pa75GRvQiTqnRrVPTtmd87yhWw0ZtIKevWTx+u2tNfqHcfZ/l56Ed6o /A5VSLZZeHTjkh6Ynj+nJ3oBqURUV6ds22cOopiDXopp361zQPka/WZL9fple37yJVn+0k/2LFtf bYHf33v99WfrRpq/fQV8L/0AxDefah6pO/36tanzRL4NGVEItf2dIWgUkjp2sZc+VezqTYQmCIOy uw0YDQVNZSZsMoXdQ+wLXYc0RGMb1at9o4z7WYch8035zOku2LGJhg7YIljjFVb4i3PBqrue2nb5 X/7lrctvpa+YcmuKiqr8BoO/qqiohqIdO57+5NRq6IN2WAy96b9Nnzzw5pGWliNvHnjo7Ufb2h59 m/LKNflrPkXtognb5MkCIzxogJV62K7bo8MFPNRwoGyIJggUUfW7iRANAS3RUXXGc516nV2v1xlw j35Yjyd5aOSBqHjQ8ViP9TxRI6FPOCZcFshCASoF+ECAKwJcEOBpAXYLhwW8WYB2ARIC2AXQC3BT gKsCXBbgqJAS8G4BhgVgV5srlVvP/GvsGnS7sFs4o9x+/kDQmAV4THhVuCkQhjImkGimAn6PNXNZ wC8KcJj2AN8nQJ8AtBd5lBimTT3+AevFFaWVhLBZwLQHrwryIzdZirVDLtMGcIrRyzQ/ply7Vm85 LDDKJMFo0SpwRoCosFp4LHMLG7PL2u0U+XD2jrZm9jEBDijDp5iHBMBC9jL2uMAjoUzoEYZp8qhw SbgqaNTjetimhz49LNODQYf5bpOa6Alnm76qray72JRSW3t7GPqZ91/v/B7zrWuywitTF7wzN79v v+N921EbONRT17yZl82ndk18/MDEO1tx8wHYCT17+dnzxZsa7s/MbfjkK2Qos2c5AF/j/OQHyu+d FMtelYCDuBUTzIMWPxMkVEieMaufUGM1u3fxq23XQPjVBeos0MVIlSV7c/5PkuTsJ0kcPnQIHj14 kMppPV3TrcqaLpA9emS5IataVbhMJauGVVdVN1S8yoBQdmVvm7hIV7Yt43Dggio/Zt61Cerb+qot luq+tgdeYYv7lfSikbpnX79+773XXj9NV/dTb6b/7Qcvpf/1yrdpe+uov/h7tj9MiDy/Rg8qGjtj bQdsZNf59Tp9JwL2HWw9Uq3ZTgNfBDp2gVFnXaO1gc7m+q0LLrjgKddzLrzbddiFt7ugzwUupoi3 /vHDJOeCP7rgXRf8kwvOuC648JMuOOyCPS4Yc8GAC9pcUOlqcOF8V+Yu0IcK8hsMmRJlqOMuGHFB j4Iqu8DqynVVuAil+4+/cf3RhSnqyy54TmlyXDb9/avJeleba52LVCog+blzP05eyiTl4PdfSu5W yLW7+ly4nrUNUy3/MUsi78TJJO3kERfsZj3c7sJTfQy6wO4C7IK/URBnPH40+RsXXHbBadfLLnzM BV9lo9rtwutcsMIFDS6odkGeC1QupzKwC67LrnddRKlseeDB5ArXgAtPjV6BBnfuSu5xHXE95SJj Cg2lNFdpV+WCrQpSfNOW5C02XWADqHY1uVhP99CKamUwH7jgN5kG8WkXZIjblrYn6dS0svHSiZr5 QWaanl3YklSejfOVp2yZJTOONbjG2JS+68JKaVk8qVDRif4k5VowU/k5izt5KDvdfoM5WUb5w84R gi6iblaDDem7HVa1Dnq0hPn3bAeqokuJupWvYLN4eyQazQTS0dsuvEenlmZUia9v/zLidFnG+cl8 KZFF5dE7lcKdquDW/XiqEt6g4cMr0YrYG13XbovZulm8XQNTJxgOCLFbUbY4Ca3Dv73xpUekwCrO MOEA99z7BhZZE53izYMjXK9B8wtYuunm19V6PQcofY9yxzN38mPeR9eUgS7UWvQrObKh8p5KPBDf Ht8TJxti98SwWnJJBRLRFqvR6oICa/lqxH63yGpkjLxfa0gajQlzIpCIJZYkdiUOJk4m1HWJ7sRQ 4nqCY/BMZlfiicRriXcSkwndjAwuwzynQDQsy5AOUsBrtJ4mU4/VYeVqTUJubU+qrZ3+YqFHrXYF uvmeEHF1+7tzWCx2LRvj1rIILPvFpm0j2WtymXg3q0Bvi2Vtlfk05cw6SXBn4Ju5MUvdqDDZ6qpc ljjwtdlLy2z9D3zjmbJiaZGzrqPa88mSZ57BB77+9zvjJYv6atYf7Cqes/cXX9/xfh/5Y+2yGm+6 JLdu9cRrD3xx4ioGDIULNqV/kIniilqGm+fdtbTKoKtuH5q38quDCRXTz9+b/Ff4mM4DQS6oYveI /10e0pmTyE0/iO2Isike1BKnVuv2HPWkPJc8JOgp88iecc8hCrjqueHRsB8rKPP0eIY952k5Bfyj QBGGs/hXPeqpGikFX83wp7BV31R+uuGuP/05OekBho2fYL/wEPSwH0PgWmmd8x6CKP4hWpXbLFOq +KoHTrIfdjjkwUvYTy+UefB1DzBy+KAHejwQ8wDyQAJRMq1KU3yP0t0UpcErDdrCBcmAJ8Z+aQE0 yPQYZyN0/dVN/BwyEcNtO7uZec0sq0w6c45xYeKCcu85TEJ/ccnu4dE1EP36pw6A4Rh59OOn/vIU mPn1fZPvq4D69eXoTXnRdgm258GGPHg+DNsDcLcRBozsGwcbDLBdAxs0MKoC55pJBzgcqBNFheih 6KUop41G43J8OH4+TsxxEOLBeE+cxNlgW5euTJ6Mw6E4dMcBxcsoGpmRil+N34iT1+KTcYzirfHx +KE490QcWmm1YUYiEMea0GqzLqDDuvLi7tLSwpxup5kr7ObZ4XfdhcwGD/NSsx5H9pdQRkYyN9oq pre6pvbo2Bcg8kppRKDsdGWvDEx9B4JTfnpAcTD4L8w8+Fd/nXwi/eG5zRt/BLbvrjz4ua0zOt3h 9u4NVQPH7q6jkULvpsrasbITeNOXmmwht2nl0598KwXqkytN7oCQ/tn33EUBS+2+f3t67Hvjyysc Nupmsrt/Cq/p2/LeuhWPqLrNs/6EApnfh33toX9zTP2G6eT19Cx1m+qKsoeAs0BaTx1KN07/0mn2 136nX434fdRAfKiRG0U1+LsoRB5GTfRdw0hQWIC9KbyKwgpxLSqh+WWq76IaDqF6mo7Tp53L4MYV 3FpUyGgwXEp3DnvT+vdRnGpa7lXeNE1hBfR9XFWLwjTfgr87eZ31g8JeysKO0Wcfe/P/jbYxirYo eAh1qh9GYX4FCtL8evpeTMvz6HMFrWum6fxsnTD3ryhM8UXWH1quYbgUp5PRoeUu7iAaoPl6Smsd fefS9PdYXcTubA+gD2ER/BBX079W/AZXzO/nP1B9QbNOq9L+te63+t1GwXjE+JapwrTdHDRXmr8q jFtMlmOWH1g+sPZZX7E12C7Y3rJr7P/k4Bx+xxedOuf3nH/v0rj+we13f9Wj85z1+sXCnLd8su9l /zr/k/7ngsHg2eDvQy25O3KfzH0zb7eUzDfkv6zMWCNaQbXdJsTRmRVQjC4gRCa59ymMTVMOrLg1 rz235hgoZk82jWnN4WyaoCAay6Y56o8ezqZ5ZELfyaZVyI6ez6bV6F70ajatQXZozKa1yASrsmk9 7cOGW78kXQpfyqaNaAhOZdMmKgdB2jpwWpo7j9dm04CCxJ9NY6Qhc7JpgmTSlE1zqIjsyaZ5lENS 2bSKytrPsmk1+oB8kE1rUCH379m0FuXwQjatRzP44mzagNbwfdm0Ef2KP59Nm9DnVN+cNzS8c2Rw w8axYOH6SLCirKwm2NbfF0z2jhUH529dXxqce9ddQQVhNDjSP9o/sr2/rzS4aH59Y9vc9vlLWoKD o8He4NhIb1//lt6RzcGhgTvrLxpc1z/SOzY4tDW4rH9kcKB+6K6+uaPr+7f29Y8ES4KfLg6y8s8E rugfGWWQ8tKymtLKaRQFo+RT1f4nnaIj2TA4OtY/QoGDW4PLS5eVBlt7x/q3jgV7t/YF229VXDIw MLi+XwGu7x8Z66XIQ2Mbac833T0yONo3uJ61Nlp6a0DzhkaGh7L9Guvf3h9c3Ds21j86tHXj2Njw zFjsnnvuKe3NIq+nuKXrh7bE/quysZ3D/X39o4MbttLhl24c23LXItqhraO043crLdLe3M7EpqGt dKLuyuAUB0f7+4OM/CilP9DfR7s2PDK0qX/9WOnQCPXjBjcPxjL0BrduiE2TYVSy7fyv1Ubz0BBd jzvRCBpEG9BGuh6DqBCtRxH6rEBl9K+GptpQP9VFQZREvRSjmKbmo60Uq5Sm5qK76F/wNgqjSq6f Pvvpc7tSl2EuorXqqQZpo3XaaXoJaqHQQQW/V9EFI/TZR/G30OcI2kxhQ1T7/VftL6L11yntsJJB ir+Vli5TIIO0bj2F3EXrzqWtrKfQrQr9EYpTovTov64dvFX//zjmCgU2egunnPaScbEUVX4mlWka Jf+T1v7XOJWZkw0KlTGFdgZzUKG9nGIsU7BalZqMU2NKa1sVrPbPaHEJbXGA1md8ncZcr9Aeo/kM 5SGa3pjl+SZ0tzLWUYrJ6k2NbZS2/JczxGRzhErn0Kf4xXq3XWlzsQIfU2SNlW1UcsNoJrVMMXSP 8ldKce6kvD5Lt1RJbaGY/1frjdGVM6zwsV+Z8Q0UNzP7pQrNLXQ2F2U5tFVZD4xDd982xgxv/jNJ bFKemRV11x102MyyJ6s71fvRbP8HlHYyXBumn0OU7/0Kt0sV6AZljIN0Dgdp6vb+sRnbkIV9ujdT fblzPP9Ptk2y/mYI/Rh9xksu1/7malXgnfjby38Vf2t52dutb4+/nXqbexvI8reIMzD0C+j+xfVf 4CW/gLqXIfDyOy9j5u7/7Xmdsan1XM+54XPkh81FAXQWYs93P3/w+ZPPv/M8P3QTAh9f/xgPfbzr Yyx/DEN/B+YzgTN46AwEnl3y7OSz5Hsn6gPm47uO45PHYfg41B0H4ZHgI2WPkOFH4BtHcgKxr9d9 HX/lgb7AyS/DQ0sCAfRAzwP40ANw6EvwRZoV7g7ejcd6JgOj3ZOBYdr+EH1vbZ4MeOLu5eo4Wa4i kwHWz5Pp0njT+XVwtRd6uisD3bRu4JPYJ098Qk5+AmgtyGu1xqZdaw6ueWINWd0ZDcQ6AXX2dOJD nTc6caATbHHrcp6ygqM0zSRA6sgSMkQOEpVm2YJQoJWSG2rZ1XKwhSxuDgcWNAcD5iTISb25qYl2 yNwcaMY5SXG5M+5YbgHzciFuXo4BLYc4Wh4zT5qx2dxt3mVmP2KC8LgTeDgLh061L4tGF55VT7Yt TKlbV6fgwZS0jH3KSztTqgdTaHnn6o5TAF9e9cDDD6N638JUxbKOVI9v1cJUH03ILDFOE4LvlBPV rxodHct8awtGo9GxKKLv6NpRJT86djfNjY2OoWh0dFTBoW+aGQOap9DR6ChN0ZXFiIzC6BhLjKJR Wo5G2XuMwu5mtVlV91oqT/87By9AWgplbmRzdHJlYW0KZW5kb2JqCgoxMTYgMCBvYmoKMTc0MjQK ZW5kb2JqCgoxMTcgMCBvYmoKPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9CQUFBQUEr TGliZXJhdGlvblNlcmlmLUJvbGQKL0ZsYWdzIDQKL0ZvbnRCQm94Wy0xODIgLTMwMyAxMDgzIDEw MDddL0l0YWxpY0FuZ2xlIDAKL0FzY2VudCA4OTEKL0Rlc2NlbnQgLTIxNgovQ2FwSGVpZ2h0IDEw MDcKL1N0ZW1WIDgwCi9Gb250RmlsZTIgMTE1IDAgUgo+PgplbmRvYmoKCjExOCAwIG9iago8PC9M ZW5ndGggNTAxL0ZpbHRlci9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nF2Ty47aQBBF9/4KLyeLkd3V fsxICIkBLLHIQ2HyAcZuGEuDbTVmwd+nb91OImUBOt2uKk4Vrmx72B3GYcl++Kk7uiU9D2Pv3W26 +86lJ3cZxsRI2g/dEk/63V3bOclC7vFxW9z1MJ6n1SrJfoZnt8U/0qdNP53clyT77nvnh/GSPv3a HsP5eJ/nT3d145LmyXqd9u4c6nxt52/t1WWa9Xzow+NheTyHlH8B74/ZpaJnQ5Vu6t1tbjvn2/Hi klWer9NV06wTN/b/PauEKadz99H6EGpCaJ4Xr+vAolztwVa5LsAF70twyXsBV8qSg2vlZgt+YcwG /Mpcrb8ha8038g68JRvwjvwC3rOO5jbkKrDJGfMGpn8NNxP94WDoX1mw+huL+ib66736m7IB07+q wfSv0KOhf40ejfobo/H0t+jR0L+As4n+GkP/SmMaOqCO0L+Av9Bf3YT+O/Qo9C/0nvMv4Sz0bzQm zh//l9C/wDyF/iXmLPCX3GAmsiFrDP1LzFbob9GvRH+tT/8SfQnnX6AvS/8S8Ta+P4i39Bf8lqX/ HvO09K9Rx9Lfohcb/fWe/jofG/21Judv4Wz5/gicbfTHbG2cv/rQXzA3S/+i1kWIbzxWAjv7Z9XS 7u59WDNdbN0vbNYwur+7P08zsvTzGzcR/OwKZW5kc3RyZWFtCmVuZG9iagoKMTE5IDAgb2JqCjw8 L1R5cGUvRm9udC9TdWJ0eXBlL1RydWVUeXBlL0Jhc2VGb250L0JBQUFBQStMaWJlcmF0aW9uU2Vy aWYtQm9sZAovRmlyc3RDaGFyIDAKL0xhc3RDaGFyIDYyCi9XaWR0aHNbMzY1IDM4OSA1NTYgMzMz IDQ0MyA0NDMgMjUwIDU1NiA0NDMgMjc3IDU1NiA4MzMgNTAwIDU1NiA1MDAgNTAwCjU1NiA1NTYg Mjc3IDQ0MyAyNzcgMzg5IDM4OSA1MDAgNTU2IDU1NiA1MDAgMzMzIDc3NyA1MDAgMzMzIDM4OQo3 NzcgNTAwIDc3NyA3MjIgNTU2IDUwMCAyNTAgOTQzIDY2NiA1MDAgNTAwIDcyMiA1MDAgMzMzIDcy MiA3NzcKNzIyIDYxMCAyNTAgNDQzIDUwMCA1MDAgMzMzIDUwMCA3MjIgNTY5IDMzMyA2NjYgNjY2 IDMzMyA3NzcgXQovRm9udERlc2NyaXB0b3IgMTE3IDAgUgovVG9Vbmljb2RlIDExOCAwIFIKPj4K ZW5kb2JqCgoxMjAgMCBvYmoKPDwvRjEgMTE5IDAgUi9GMiAxMDkgMCBSL0YzIDExNCAwIFIKPj4K ZW5kb2JqCgoxMjEgMCBvYmoKPDwvRm9udCAxMjAgMCBSCi9YT2JqZWN0PDwvVHIxNCAxNCAwIFIv VHIxOSAxOSAwIFIvVHIyNCAyNCAwIFIvVHIyOSAyOSAwIFIvVHIzNCAzNCAwIFIvVHIzOSAzOSAw IFIvVHI0IDQgMCBSL1RyNDQgNDQgMCBSCi9UcjQ5IDQ5IDAgUi9UcjkgOSAwIFI+PgovRXh0R1N0 YXRlPDwvRUdTMTAgMTAgMCBSL0VHUzE1IDE1IDAgUi9FR1MyMCAyMCAwIFIvRUdTMjUgMjUgMCBS L0VHUzMwIDMwIDAgUi9FR1MzNSAzNSAwIFIvRUdTNDAgNDAgMCBSL0VHUzQ1IDQ1IDAgUgovRUdT NSA1IDAgUi9FR1M1MCA1MCAwIFI+PgovUHJvY1NldFsvUERGL1RleHQvSW1hZ2VDL0ltYWdlSS9J bWFnZUJdCj4+CmVuZG9iagoKMSAwIG9iago8PC9UeXBlL1BhZ2UvUGFyZW50IDEwNCAwIFIvUmVz b3VyY2VzIDEyMSAwIFIvTWVkaWFCb3hbMCAwIDQ2OCA2NjZdL0Fubm90c1sKNTEgMCBSIDc4IDAg UiA3OSAwIFIgODAgMCBSIDgxIDAgUiBdCi9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5L0NTL0Rldmlj ZVJHQi9JIHRydWU+Pi9Db250ZW50cyAyIDAgUj4+CmVuZG9iagoKNiAwIG9iago8PC9UeXBlL1Bh Z2UvUGFyZW50IDEwNCAwIFIvUmVzb3VyY2VzIDEyMSAwIFIvTWVkaWFCb3hbMCAwIDQ2OCA2NjZd L0Fubm90c1sKODIgMCBSIDgzIDAgUiA4NCAwIFIgXQovR3JvdXA8PC9TL1RyYW5zcGFyZW5jeS9D Uy9EZXZpY2VSR0IvSSB0cnVlPj4vQ29udGVudHMgNyAwIFI+PgplbmRvYmoKCjExIDAgb2JqCjw8 L1R5cGUvUGFnZS9QYXJlbnQgMTA0IDAgUi9SZXNvdXJjZXMgMTIxIDAgUi9NZWRpYUJveFswIDAg NDY4IDY2Nl0vQW5ub3RzWwo4NSAwIFIgODYgMCBSIDg3IDAgUiBdCi9Hcm91cDw8L1MvVHJhbnNw YXJlbmN5L0NTL0RldmljZVJHQi9JIHRydWU+Pi9Db250ZW50cyAxMiAwIFI+PgplbmRvYmoKCjE2 IDAgb2JqCjw8L1R5cGUvUGFnZS9QYXJlbnQgMTA0IDAgUi9SZXNvdXJjZXMgMTIxIDAgUi9NZWRp YUJveFswIDAgNDY4IDY2Nl0vQW5ub3RzWwo1MyAwIFIgODggMCBSIDg5IDAgUiA5MCAwIFIgXQov R3JvdXA8PC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0IvSSB0cnVlPj4vQ29udGVudHMgMTcg MCBSPj4KZW5kb2JqCgoyMSAwIG9iago8PC9UeXBlL1BhZ2UvUGFyZW50IDEwNCAwIFIvUmVzb3Vy Y2VzIDEyMSAwIFIvTWVkaWFCb3hbMCAwIDQ2OCA2NjZdL0Fubm90c1sKOTEgMCBSIF0KL0dyb3Vw PDwvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCL0kgdHJ1ZT4+L0NvbnRlbnRzIDIyIDAgUj4+ CmVuZG9iagoKMjYgMCBvYmoKPDwvVHlwZS9QYWdlL1BhcmVudCAxMDQgMCBSL1Jlc291cmNlcyAx MjEgMCBSL01lZGlhQm94WzAgMCA0NjggNjY2XS9Bbm5vdHNbCjkyIDAgUiA5MyAwIFIgXQovR3Jv dXA8PC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0IvSSB0cnVlPj4vQ29udGVudHMgMjcgMCBS Pj4KZW5kb2JqCgozMSAwIG9iago8PC9UeXBlL1BhZ2UvUGFyZW50IDEwNCAwIFIvUmVzb3VyY2Vz IDEyMSAwIFIvTWVkaWFCb3hbMCAwIDQ2OCA2NjZdL0Fubm90c1sKOTQgMCBSIDk1IDAgUiA5NiAw IFIgOTcgMCBSIDk4IDAgUiA5OSAwIFIgMTAwIDAgUiAxMDEgMCBSIDEwMiAwIFIgMTAzIDAgUiBd Ci9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQi9JIHRydWU+Pi9Db250ZW50cyAz MiAwIFI+PgplbmRvYmoKCjM2IDAgb2JqCjw8L1R5cGUvUGFnZS9QYXJlbnQgMTA0IDAgUi9SZXNv dXJjZXMgMTIxIDAgUi9NZWRpYUJveFswIDAgNDY4IDY2Nl0vR3JvdXA8PC9TL1RyYW5zcGFyZW5j eS9DUy9EZXZpY2VSR0IvSSB0cnVlPj4vQ29udGVudHMgMzcgMCBSPj4KZW5kb2JqCgo0MSAwIG9i ago8PC9UeXBlL1BhZ2UvUGFyZW50IDEwNCAwIFIvUmVzb3VyY2VzIDEyMSAwIFIvTWVkaWFCb3hb MCAwIDQ2OCA2NjZdL0Fubm90c1sKNTIgMCBSIDU3IDAgUiA1OCAwIFIgNTkgMCBSIDYwIDAgUiA2 MSAwIFIgNjIgMCBSIDYzIDAgUiA2NCAwIFIgNjUgMCBSIDY2IDAgUiA2NyAwIFIgNjggMCBSIDY5 IDAgUiA3MCAwIFIKNzEgMCBSIDcyIDAgUiA3MyAwIFIgNzQgMCBSIDc1IDAgUiA3NiAwIFIgNzcg MCBSIF0KL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCL0kgdHJ1ZT4+L0NvbnRl bnRzIDQyIDAgUj4+CmVuZG9iagoKNDYgMCBvYmoKPDwvVHlwZS9QYWdlL1BhcmVudCAxMDQgMCBS L1Jlc291cmNlcyAxMjEgMCBSL01lZGlhQm94WzAgMCA0NjggNjY2XS9Bbm5vdHNbCjU0IDAgUiA1 NSAwIFIgNTYgMCBSIF0KL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCL0kgdHJ1 ZT4+L0NvbnRlbnRzIDQ3IDAgUj4+CmVuZG9iagoKMTA0IDAgb2JqCjw8L1R5cGUvUGFnZXMKL1Jl c291cmNlcyAxMjEgMCBSCi9NZWRpYUJveFsgMCAwIDQ2OCA2NjYgXQovS2lkc1sgMSAwIFIgNiAw IFIgMTEgMCBSIDE2IDAgUiAyMSAwIFIgMjYgMCBSIDMxIDAgUiAzNiAwIFIgNDEgMCBSIDQ2IDAg UiBdCi9Db3VudCAxMD4+CmVuZG9iagoKNTEgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xp bmsvQm9yZGVyWzAgMCAwXS9SZWN0WzUwLjIgNTAxLjkgMTAyLjYgNTEwXS9BPDwvVHlwZS9BY3Rp b24vUy9VUkkvVVJJKG1haWx0bzp1dGt1Y2V2cmVAbWFpbC5lZ2UuZWR1LnRyKT4+Cj4+CmVuZG9i agoKNTIgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0 WzczIDg3LjMgMzc0LjkgOTguOV0vQTw8L1R5cGUvQWN0aW9uL1MvVVJJL1VSSShodHRwOi8vYWJp bGdlZ3VuZHV6LmJsb2dzcG90LmNvbS50ci8yMDE0LzAzL2Nob3Nlbi1jaXBoZXJ0ZXh0LWF0dGFj ay5odG1sKT4+Cj4+CmVuZG9iagoKNTMgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsv Qm9yZGVyWzAgMCAwXS9SZWN0WzM0MS4zIDM0NS4zIDQzMi4yIDM1Ni45XS9BPDwvVHlwZS9BY3Rp b24vUy9VUkkvVVJJKGh0dHBzOi8vbGV0c2VuY3J5cHQub3JnLyk+Pgo+PgplbmRvYmoKCjU0IDAg b2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs3MyA1NDAg MzI0LjcgNTUxLjZdL0E8PC9UeXBlL0FjdGlvbi9TL1VSSS9VUkkoaHR0cDovL2xpbmsuc3ByaW5n ZXIuY29tL2NoYXB0ZXIvMTAuMTAwNyUyRjMtNTQwLTQ1NzA4LTlfMik+Pgo+PgplbmRvYmoKCjU1 IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs3Ni4z IDU2My4xIDI5OC4yIDU3NC43XS9BPDwvVHlwZS9BY3Rpb24vUy9VUkkvVVJJKGh0dHBzOi8vd3d3 Lm5zYS5nb3YvaWEvcHJvZ3JhbXMvc3VpdGViX2NyeXB0b2dyYXBoeS8pPj4KPj4KZW5kb2JqCgo1 NiAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbNzQu NCA1ODYuMiAyMTIuMyA1OTcuOF0vQTw8L1R5cGUvQWN0aW9uL1MvVVJJL1VSSShodHRwczovL2Vu Lndpa2lwZWRpYS5vcmcvd2lraS9SQzQpPj4KPj4KZW5kb2JqCgo1NyAwIG9iago8PC9UeXBlL0Fu bm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbNzMgNjQuMiAyOTYuOCA3NS44XS9B PDwvVHlwZS9BY3Rpb24vUy9VUkkvVVJJKGh0dHBzOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL0Rp ZmZlcmVudGlhbF9jcnlwdGFuYWx5c2lzKT4+Cj4+CmVuZG9iagoKNTggMCBvYmoKPDwvVHlwZS9B bm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzczIDExMC40IDI2MS41IDEyMl0v QTw8L1R5cGUvQWN0aW9uL1MvVVJJL1VSSShodHRwczovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9M ZXR0ZXJfZnJlcXVlbmN5KT4+Cj4+CmVuZG9iagoKNTkgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0 eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzczIDEzMy41IDI5NC44IDE0NS4xXS9BPDwvVHlw ZS9BY3Rpb24vUy9VUkkvVVJJKGh0dHBzOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL1ZpZ2VuJUMz JUE4cmVfY2lwaGVyKT4+Cj4+CmVuZG9iagoKNjAgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBl L0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0Wzc0LjQgMTU2LjYgMjgzLjQgMTY4LjJdL0E8PC9UeXBl L0FjdGlvbi9TL1VSSS9VUkkoaHR0cHM6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvUG9seWFscGhh YmV0aWNfY2lwaGVyKT4+Cj4+CmVuZG9iagoKNjEgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBl L0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzczIDE3OS43IDI4OS4yIDE5MS4zXS9BPDwvVHlwZS9B Y3Rpb24vUy9VUkkvVVJJKGh0dHA6Ly93d3cudGhvbmt5LmNvbS9rcnlwdG9zL2luZGV4LW9mLWNv aW5jaWRlbmNlKT4+Cj4+CmVuZG9iagoKNjIgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xp bmsvQm9yZGVyWzAgMCAwXS9SZWN0WzU2IDIyOC4xIDI4MS43IDIzOS43XS9BPDwvVHlwZS9BY3Rp b24vUy9VUkkvVVJJKGh0dHA6Ly9nYW1lcHJvZ3JhbW1pbmdwYXR0ZXJucy5jb20vZGF0YS1sb2Nh bGl0eS5odG1sKT4+Cj4+CmVuZG9iagoKNjMgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xp bmsvQm9yZGVyWzAgMCAwXS9SZWN0WzczIDIzOS43IDI4MS41IDI1MS4zXS9BPDwvVHlwZS9BY3Rp b24vUy9VUkkvVVJJKGh0dHBzOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL0xvY2FsaXR5X29mX3Jl ZmVyZW5jZSk+Pgo+PgplbmRvYmoKCjY0IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5r L0JvcmRlclswIDAgMF0vUmVjdFs3MyAyNjIuOCAzMjMuMSAyNzQuNF0vQTw8L1R5cGUvQWN0aW9u L1MvVVJJL1VSSShodHRwczovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9BZHZhbmNlZF9FbmNyeXB0 aW9uX1N0YW5kYXJkKT4+Cj4+CmVuZG9iagoKNjUgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBl L0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzczIDI4NS45IDI5Ny42IDI5Ny41XS9BPDwvVHlwZS9B Y3Rpb24vUy9VUkkvVVJJKGh0dHBzOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL01hbi1pbi10aGUt bWlkZGxlX2F0dGFjayk+Pgo+PgplbmRvYmoKCjY2IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlw ZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs3MyAzNTUuMiAyMDguMiAzNjYuOF0vQTw8L1R5cGUv QWN0aW9uL1MvVVJJL1VSSShodHRwczovL3RyLndpa2lwZWRpYS5vcmcvd2lraS9SU0EpPj4KPj4K ZW5kb2JqCgo2NyAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBd L1JlY3RbNzMgMzY2LjcgMjQzLjcgMzc4LjNdL0E8PC9UeXBlL0FjdGlvbi9TL1VSSS9VUkkoaHR0 cHM6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvWE9SX2NpcGhlcik+Pgo+PgplbmRvYmoKCjY4IDAg b2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFs3MyAzODku OCAzMjQgNDAxLjRdL0E8PC9UeXBlL0FjdGlvbi9TL1VSSS9VUkkoaHR0cHM6Ly90ci53aWtpcGVk aWEub3JnL3dpa2kvRGlmZmllLUhlbGxtYW5fYW5haHRhcl9kZSVDNCU5RmklQzUlOUZpbWkpPj4K Pj4KZW5kb2JqCgo2OSAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAw IDBdL1JlY3RbNzMgNDEyLjkgMzA3LjUgNDI0LjVdL0E8PC9UeXBlL0FjdGlvbi9TL1VSSS9VUkko aHR0cDovL3d3dy50dXJraHVrdWtzaXRlc2kuY29tL3Nob3d0aHJlYWQucGhwP3Q9MzY5NjgpPj4K Pj4KZW5kb2JqCgo3MCAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAw IDBdL1JlY3RbNzMgNDM2IDI5MS4yIDQ0Ny42XS9BPDwvVHlwZS9BY3Rpb24vUy9VUkkvVVJJKGh0 dHA6Ly93d3cudHVya2l5ZWdhemV0ZXNpLmNvbS50ci9kdW55YS8zMTYxMTIuYXNweCk+Pgo+Pgpl bmRvYmoKCjcxIDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0v UmVjdFs3MyA0NTkuMSAyNzkuMyA0NzAuN10vQTw8L1R5cGUvQWN0aW9uL1MvVVJJL1VSSShodHRw czovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9QcmV0dHlfR29vZF9Qcml2YWN5KT4+Cj4+CmVuZG9i agoKNzIgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0 WzczIDQ4Mi4yIDMyMS4xIDQ5My44XS9BPDwvVHlwZS9BY3Rpb24vUy9VUkkvVVJJKGh0dHA6Ly93 d3cuaHVycml5ZXQuY29tLnRyL25zYS0xMjItbGlkZXJpLWRpbmxlbWlzLTI2MTExMjAzKT4+Cj4+ CmVuZG9iagoKNzMgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAw XS9SZWN0WzczIDUwNS4zIDI3MS40IDUxNi45XS9BPDwvVHlwZS9BY3Rpb24vUy9VUkkvVVJJKGh0 dHA6Ly93d3cud2lyZWQuY29tLzIwMTIvMDMvZmZfbnNhZGF0YWNlbnRlci8pPj4KPj4KZW5kb2Jq Cgo3NCAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3Rb NzMgNTI4LjQgMjU3LjMgNTQwXS9BPDwvVHlwZS9BY3Rpb24vUy9VUkkvVVJJKGh0dHBzOi8vbWlz ZXMub3JnL2xpYnJhcnkvaGVnZWwtc3RhdGUtZ29kcy13aWxsKT4+Cj4+CmVuZG9iagoKNzUgMCBv YmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzU2IDU1MS41 IDEwOC45IDU2My4xXS9BPDwvVHlwZS9BY3Rpb24vUy9VUkkvVVJJKGh0dHA6Ly93d3cudGhlcmVn aXN0ZXIuY28udWsvMjAxNS8wOS8wMy93aWtpcGVkaWFfaW5kdXN0cmlhbF9zY2FsZV9zbWVhcnNf YW5kX2JsYWNrbWFpbC8pPj4KPj4KZW5kb2JqCgo3NiAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5 cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbNzMgNTYzLjEgNDExLjggNTc0LjddL0E8PC9UeXBl L0FjdGlvbi9TL1VSSS9VUkkoaHR0cDovL3d3dy50aGVyZWdpc3Rlci5jby51ay8yMDE1LzA5LzAz L3dpa2lwZWRpYV9pbmR1c3RyaWFsX3NjYWxlX3NtZWFyc19hbmRfYmxhY2ttYWlsLyk+Pgo+Pgpl bmRvYmoKCjc3IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0v UmVjdFs3MyA1ODYuMiAzMzIuNyA1OTcuOF0vQTw8L1R5cGUvQWN0aW9uL1MvVVJJL1VSSShodHRw czovL3d3dy50Ym1tLmdvdi50ci9kZXZlbG9wL293YS9hbmF5YXNhLm1hZGRlbGVyP3AzPTIyKT4+ Cj4+CmVuZG9iagoKNzggMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAg MCAwXS9SZWN0WzI1OS42IDU4OTcuNiAyNjIuNyA1OTA5LjJdL0Rlc3RbNDEgMCBSL1hZWiA3My43 IDYwOS4zIDBdPj4KZW5kb2JqCgo3OSAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9C b3JkZXJbMCAwIDBdL1JlY3RbMzM5LjMgNTU2MC40IDM0NCA1NTcyXS9EZXN0WzQxIDAgUi9YWVog NzMuNyA1NzQuNyAwXT4+CmVuZG9iagoKODAgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xp bmsvQm9yZGVyWzAgMCAwXS9SZWN0WzQyNi41IDU1MzcuMyA0MzIuMiA1NTQ4LjldL0Rlc3RbNDEg MCBSL1hZWiA3My43IDU0MCAwXT4+CmVuZG9iagoKODEgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0 eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzQyMy41IDU0NzkuNSA0MjkuNSA1NDkxLjFdL0Rl c3RbNDEgMCBSL1hZWiA3My43IDUxNi45IDBdPj4KZW5kb2JqCgo4MiAwIG9iago8PC9UeXBlL0Fu bm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbMTc4LjcgNTE3Ny4xIDE4My4xIDUx ODguN10vRGVzdFs0MSAwIFIvWFlaIDczLjcgNDkzLjggMF0+PgplbmRvYmoKCjgzIDAgb2JqCjw8 L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFsxNjYuOSA1MDE1LjQg MTcyLjkgNTAyN10vRGVzdFs0MSAwIFIvWFlaIDczLjcgNDcwLjcgMF0+PgplbmRvYmoKCjg0IDAg b2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFszNTYuNSA0 ODUzLjcgMzY0LjEgNDg2NS4zXS9EZXN0WzQxIDAgUi9YWVogNzMuNyA0NDcuNiAwXT4+CmVuZG9i agoKODUgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0 WzIxNy40IDQ1NjYuMSAyMjYuNiA0NTc3LjddL0Rlc3RbNDEgMCBSL1hZWiA3My43IDQyNC41IDBd Pj4KZW5kb2JqCgo4NiAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAw IDBdL1JlY3RbMzUwLjcgNDE3My40IDM1Ni43IDQxODVdL0Rlc3RbNDEgMCBSL1hZWiA3My43IDQw MS40IDBdPj4KZW5kb2JqCgo4NyAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3Jk ZXJbMCAwIDBdL1JlY3RbNDIxLjQgNDEyNy4yIDQyNS44IDQxMzguOF0vRGVzdFs0MSAwIFIvWFla IDczLjcgMzc4LjMgMF0+PgplbmRvYmoKCjg4IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9M aW5rL0JvcmRlclswIDAgMF0vUmVjdFsxMDUuMyAzNTM5LjIgMTExLjMgMzU1MC44XS9EZXN0WzQx IDAgUi9YWVogNzMuNyAzNjYuOCAwXT4+CmVuZG9iagoKODkgMCBvYmoKPDwvVHlwZS9Bbm5vdC9T dWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzMzMy4yIDM4NjIuNiAzNDAuOCAzODc0LjJd L0Rlc3RbNDEgMCBSL1hZWiA3My43IDM0My43IDBdPj4KZW5kb2JqCgo5MCAwIG9iago8PC9UeXBl L0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbMzg4LjEgMzc5My4zIDM5Ny4z IDM4MDQuOV0vRGVzdFs0MSAwIFIvWFlaIDczLjcgMjk3LjUgMF0+PgplbmRvYmoKCjkxIDAgb2Jq Cjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRlclswIDAgMF0vUmVjdFsyOTcuNCAyOTg1 LjkgMzA2LjMgMjk5Ny41XS9EZXN0WzQxIDAgUi9YWVogNzMuNyAyNzQuNCAwXT4+CmVuZG9iagoK OTIgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzI3 MS41IDIyNDcuOCAyNzguOCAyMjU5LjRdL0Rlc3RbNDEgMCBSL1hZWiA3My43IDI1MS4zIDBdPj4K ZW5kb2JqCgo5MyAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBd L1JlY3RbMjc0LjMgMjA4Ni4xIDI4My4yIDIwOTcuN10vRGVzdFs0MSAwIFIvWFlaIDczLjcgMjE2 LjYgMF0+PgplbmRvYmoKCjk0IDAgb2JqCjw8L1R5cGUvQW5ub3QvU3VidHlwZS9MaW5rL0JvcmRl clswIDAgMF0vUmVjdFsxNzkuNyAxODc5LjMgMTkwLjIgMTg5MC45XS9EZXN0WzQxIDAgUi9YWVog NzMuNyAxOTEuMyAwXT4+CmVuZG9iagoKOTUgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0eXBlL0xp bmsvQm9yZGVyWzAgMCAwXS9SZWN0WzEzOC45IDE4NjcuOCAxNTEgMTg3OS40XS9EZXN0WzQxIDAg Ui9YWVogNzUuMSAxNjguMiAwXT4+CmVuZG9iagoKOTYgMCBvYmoKPDwvVHlwZS9Bbm5vdC9TdWJ0 eXBlL0xpbmsvQm9yZGVyWzAgMCAwXS9SZWN0WzIyNy42IDE4NjcuOCAyMzUuOSAxODc5LjRdL0Rl c3RbNDEgMCBSL1hZWiA3My43IDE0NS4xIDBdPj4KZW5kb2JqCgo5NyAwIG9iago8PC9UeXBlL0Fu bm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbODIuNyAxODEwIDkwIDE4MjEuNl0v RGVzdFs0MSAwIFIvWFlaIDczLjcgMTIyIDBdPj4KZW5kb2JqCgo5OCAwIG9iago8PC9UeXBlL0Fu bm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbOTUuOCAxNzI5LjIgMTA0LjcgMTc0 MC44XS9EZXN0WzQxIDAgUi9YWVogNzMuNyA5OC45IDBdPj4KZW5kb2JqCgo5OSAwIG9iago8PC9U eXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbMTYwLjEgMTY3MS40IDE3 MC42IDE2ODNdL0Rlc3RbNDEgMCBSL1hZWiA3My43IDc1LjggMF0+PgplbmRvYmoKCjEwMCAwIG9i ago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3RbMzE5LjIgMjQw OS41IDMzMS4zIDI0MjEuMV0vRGVzdFs0NiAwIFIvWFlaIDc1LjEgNTk3LjggMF0+PgplbmRvYmoK CjEwMSAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAwIDBdL1JlY3Rb MzQzLjMgMjIxMy4yIDM1NS4xIDIyMjQuOF0vRGVzdFs0NiAwIFIvWFlaIDc0LjUgNTc0LjcgMF0+ PgplbmRvYmoKCjEwMiAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9Cb3JkZXJbMCAw IDBdL1JlY3RbNDE5LjMgMjEwOS4yIDQyOS41IDIxMjAuOF0vRGVzdFs0NiAwIFIvWFlaIDczLjcg NTUxLjYgMF0+PgplbmRvYmoKCjEwMyAwIG9iago8PC9UeXBlL0Fubm90L1N1YnR5cGUvTGluay9C b3JkZXJbMCAwIDBdL1JlY3RbNDA2LjIgMjA3NC42IDQxOCAyMDg2LjJdL0Rlc3RbNDYgMCBSL1hZ WiA3NC41IDUyOC41IDBdPj4KZW5kb2JqCgoxMjIgMCBvYmoKPDwvVHlwZS9DYXRhbG9nL1BhZ2Vz IDEwNCAwIFIKL09wZW5BY3Rpb25bMSAwIFIgL1hZWiBudWxsIG51bGwgMF0KL0xhbmcoZW4tVVMp Cj4+CmVuZG9iagoKMTIzIDAgb2JqCjw8L0F1dGhvcjxGRUZGMDA0NTAwNzIwMDZCMDA2OTAwNkUw MDIwMDA0MzAwNjEwMDZFPgovQ3JlYXRvcjxGRUZGMDA1NzAwNzIwMDY5MDA3NDAwNjUwMDcyPgov UHJvZHVjZXI8RkVGRjAwNEMwMDY5MDA2MjAwNzIwMDY1MDA0RjAwNjYwMDY2MDA2OTAwNjMwMDY1 MDAyMDAwMzQwMDJFMDAzMz4KL0NyZWF0aW9uRGF0ZShEOjIwMTUxMTE3MDIxMjIwKzAyJzAwJyk+ PgplbmRvYmoKCnhyZWYKMCAxMjQKMDAwMDAwMDAwMCA2NTUzNSBmIAowMDAwMTA2NjA4IDAwMDAw IG4gCjAwMDAwMDAwMTkgMDAwMDAgbiAKMDAwMDAwNDcwNSAwMDAwMCBuIAowMDAwMDA0NzI2IDAw MDAwIG4gCjAwMDAwMDQ5MjIgMDAwMDAgbiAKMDAwMDEwNjgwMCAwMDAwMCBuIAowMDAwMDA0OTYy IDAwMDAwIG4gCjAwMDAwMTA2MTQgMDAwMDAgbiAKMDAwMDAxMDYzNSAwMDAwMCBuIAowMDAwMDEw ODMxIDAwMDAwIG4gCjAwMDAxMDY5NzggMDAwMDAgbiAKMDAwMDAxMDg3MiAwMDAwMCBuIAowMDAw MDE2Njg0IDAwMDAwIG4gCjAwMDAwMTY3MDYgMDAwMDAgbiAKMDAwMDAxNjkwMyAwMDAwMCBuIAow MDAwMTA3MTU4IDAwMDAwIG4gCjAwMDAwMTY5NDQgMDAwMDAgbiAKMDAwMDAyMjQ4MSAwMDAwMCBu IAowMDAwMDIyNTAzIDAwMDAwIG4gCjAwMDAwMjI3MDAgMDAwMDAgbiAKMDAwMDEwNzM0NSAwMDAw MCBuIAowMDAwMDIyNzQxIDAwMDAwIG4gCjAwMDAwMjgxMjUgMDAwMDAgbiAKMDAwMDAyODE0NyAw MDAwMCBuIAowMDAwMDI4MzQ0IDAwMDAwIG4gCjAwMDAxMDc1MTEgMDAwMDAgbiAKMDAwMDAyODM4 NSAwMDAwMCBuIAowMDAwMDMzMzcwIDAwMDAwIG4gCjAwMDAwMzMzOTIgMDAwMDAgbiAKMDAwMDAz MzU4OSAwMDAwMCBuIAowMDAwMTA3Njg0IDAwMDAwIG4gCjAwMDAwMzM2MzAgMDAwMDAgbiAKMDAw MDAzOTI0NyAwMDAwMCBuIAowMDAwMDM5MjY5IDAwMDAwIG4gCjAwMDAwMzk0NjYgMDAwMDAgbiAK MDAwMDEwNzkxNyAwMDAwMCBuIAowMDAwMDM5NTA3IDAwMDAwIG4gCjAwMDAwNDQwNzUgMDAwMDAg biAKMDAwMDA0NDA5NyAwMDAwMCBuIAowMDAwMDQ0Mjk0IDAwMDAwIG4gCjAwMDAxMDgwNjUgMDAw MDAgbiAKMDAwMDA0NDMzNSAwMDAwMCBuIAowMDAwMDQ2NTYxIDAwMDAwIG4gCjAwMDAwNDY1ODMg MDAwMDAgbiAKMDAwMDA0Njc4MCAwMDAwMCBuIAowMDAwMTA4Mzc4IDAwMDAwIG4gCjAwMDAwNDY4 MjEgMDAwMDAgbiAKMDAwMDA0NzQ4MCAwMDAwMCBuIAowMDAwMDQ3NTAxIDAwMDAwIG4gCjAwMDAw NDc2OTggMDAwMDAgbiAKMDAwMDEwODcyMyAwMDAwMCBuIAowMDAwMTA4ODczIDAwMDAwIG4gCjAw MDAxMDkwNjIgMDAwMDAgbiAKMDAwMDEwOTIwNyAwMDAwMCBuIAowMDAwMTA5MzgxIDAwMDAwIG4g CjAwMDAxMDk1NTMgMDAwMDAgbiAKMDAwMDEwOTcwNiAwMDAwMCBuIAowMDAwMTA5ODc4IDAwMDAw IG4gCjAwMDAxMTAwNDAgMDAwMDAgbiAKMDAwMDExMDIwOCAwMDAwMCBuIAowMDAwMTEwMzc5IDAw MDAwIG4gCjAwMDAxMTA1NDcgMDAwMDAgbiAKMDAwMDExMDcxOCAwMDAwMCBuIAowMDAwMTEwODg3 IDAwMDAwIG4gCjAwMDAxMTEwNjMgMDAwMDAgbiAKMDAwMDExMTIzNSAwMDAwMCBuIAowMDAwMTEx Mzg2IDAwMDAwIG4gCjAwMDAxMTE1NDQgMDAwMDAgbiAKMDAwMDExMTczMSAwMDAwMCBuIAowMDAw MTExOTAyIDAwMDAwIG4gCjAwMDAxMTIwNjkgMDAwMDAgbiAKMDAwMDExMjIzNiAwMDAwMCBuIAow MDAwMTEyNDEzIDAwMDAwIG4gCjAwMDAxMTI1NzcgMDAwMDAgbiAKMDAwMDExMjc0MCAwMDAwMCBu IAowMDAwMTEyOTQ2IDAwMDAwIG4gCjAwMDAxMTMxNTIgMDAwMDAgbiAKMDAwMDExMzMyOCAwMDAw MCBuIAowMDAwMTEzNDUwIDAwMDAwIG4gCjAwMDAxMTM1NjggMDAwMDAgbiAKMDAwMDExMzY4OCAw MDAwMCBuIAowMDAwMTEzODEwIDAwMDAwIG4gCjAwMDAxMTM5MzIgMDAwMDAgbiAKMDAwMDExNDA1 MiAwMDAwMCBuIAowMDAwMTE0MTc0IDAwMDAwIG4gCjAwMDAxMTQyOTYgMDAwMDAgbiAKMDAwMDEx NDQxNiAwMDAwMCBuIAowMDAwMTE0NTM4IDAwMDAwIG4gCjAwMDAxMTQ2NjAgMDAwMDAgbiAKMDAw MDExNDc4MiAwMDAwMCBuIAowMDAwMTE0OTA0IDAwMDAwIG4gCjAwMDAxMTUwMjYgMDAwMDAgbiAK MDAwMDExNTE0OCAwMDAwMCBuIAowMDAwMTE1MjcwIDAwMDAwIG4gCjAwMDAxMTUzOTIgMDAwMDAg biAKMDAwMDExNTUxMiAwMDAwMCBuIAowMDAwMTE1NjM0IDAwMDAwIG4gCjAwMDAxMTU3NDggMDAw MDAgbiAKMDAwMDExNTg2OCAwMDAwMCBuIAowMDAwMTE1OTg3IDAwMDAwIG4gCjAwMDAxMTYxMTAg MDAwMDAgbiAKMDAwMDExNjIzMyAwMDAwMCBuIAowMDAwMTE2MzU2IDAwMDAwIG4gCjAwMDAxMDg1 NTggMDAwMDAgbiAKMDAwMDA0NzczOSAwMDAwMCBuIAowMDAwMDczMTUzIDAwMDAwIG4gCjAwMDAw NzMxNzcgMDAwMDAgbiAKMDAwMDA3MzM3NiAwMDAwMCBuIAowMDAwMDc0MDg1IDAwMDAwIG4gCjAw MDAwNzQ2MzUgMDAwMDAgbiAKMDAwMDA4NjM3MiAwMDAwMCBuIAowMDAwMDg2Mzk2IDAwMDAwIG4g CjAwMDAwODY2MDUgMDAwMDAgbiAKMDAwMDA4NzEwOCAwMDAwMCBuIAowMDAwMDg3NDY1IDAwMDAw IG4gCjAwMDAxMDQ5NzggMDAwMDAgbiAKMDAwMDEwNTAwMiAwMDAwMCBuIAowMDAwMTA1MjA4IDAw MDAwIG4gCjAwMDAxMDU3ODAgMDAwMDAgbiAKMDAwMDEwNjE5OSAwMDAwMCBuIAowMDAwMTA2MjU2 IDAwMDAwIG4gCjAwMDAxMTY0NzcgMDAwMDAgbiAKMDAwMDExNjU3NyAwMDAwMCBuIAp0cmFpbGVy Cjw8L1NpemUgMTI0L1Jvb3QgMTIyIDAgUgovSW5mbyAxMjMgMCBSCi9JRCBbIDxGODAwMjFGNUJF RTdCNURFMzQ2MTY1MzZCODhFMjEwOT4KPEY4MDAyMUY1QkVFN0I1REUzNDYxNjUzNkI4OEUyMTA5 PiBdCi9Eb2NDaGVja3N1bSAvQzY3RTFDMjAzM0MzNTkwMzIyQUY2RTQ4OTE0QjQyMDgKPj4Kc3Rh cnR4cmVmCjExNjgwMwolJUVPRgo= --047d7ba97d24e919130524b451b1-- From nobody Tue Nov 17 04:55: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 B7EB01B2ED3 for ; Tue, 17 Nov 2015 04:55:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.699 X-Spam-Level: X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 nyEYzNYUJLC6 for ; Tue, 17 Nov 2015 04:55:21 -0800 (PST) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::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 145071B2C2D for ; Tue, 17 Nov 2015 04:55:21 -0800 (PST) Received: by vkas68 with SMTP id s68so4472666vka.2 for ; Tue, 17 Nov 2015 04:55:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=asvtSAMTTjF3ljAyoojKwuKAidx/9iF6uW6aLnONu6Y=; b=X3m17/Zr5qa6rLMa8KUUjZ1ed9h6If19PebE7Dg4aDnyC9FGRGuaZ7qqwFf2ICXgeO oVvw4wJZr4ioU4Myug1lNjJeG0Z3z9fbidtHOcDXk2xrdB/hmiQg9wtF99z9//Pe0yVA DbMQpHALbWRjO/OpwFhPbVlzFBvNniKo1ulp8= 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=asvtSAMTTjF3ljAyoojKwuKAidx/9iF6uW6aLnONu6Y=; b=N+dAUdD7wQhWmjSbASjYbvYDu5o1VT2IQbrnGn9NovXpOUrKIkJJco40KZ4V1MTm6a mV3cicX7IOa6mF9b/Hgw/h/rRtcQjD0RFza7Z8gCflkLWVU0nLMp+eIi4XSrdtMSuWft uafYLh9LztjCJjItyekllSKE9iX25UdeDzf0yv+5sKCJXeVWwkkAPsQG2fdbg6PZZXm8 0hiHS3bvdjYVz/BskZXTMBSE3vF3bdm6IvkYt6rxp9XnXBWcsCitOGGmhUciqW9HM6nq NhVt5vZjVj2YU22XPaChcRUYMVe4UrU+X3ughdXbOQTZIOUDSWIxaY7OetdPGFO33hgc wkYg== X-Gm-Message-State: ALoCoQnQqsz3mo4l8oYoKzCwBKLH0VE/+k9rCK3mblkAde/EArcUmo5KdU+6kE/tFr3Fh0xC/Kkz X-Received: by 10.31.146.1 with SMTP id u1mr3492443vkd.18.1447764920245; Tue, 17 Nov 2015 04:55:20 -0800 (PST) Received: from [5.5.33.110] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id x138sm2836123vke.15.2015.11.17.04.55.18 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Nov 2015 04:55:19 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Sean Turner In-Reply-To: Date: Tue, 17 Nov 2015 14:55:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7051FE9D-84F2-4058-A4BE-19B42B65AA67@sn3rd.com> References: To: Ismail Kizir X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] A new encryption "impossible to break" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 12:55:23 -0000 Ismail, These posts are off-topic for this mailing list. The WG list is = concerned with the design of TLS not the cryptographic algorithms used = by TLS. Other should feel free to provide comments, but please send those = response directly to Ismail not to this list. spt wg chair hat on > On Nov 17, 2015, at 05:42, Ismail Kizir wrote: >=20 > Hello, >=20 > I've developed a new encryption algorithm, which dynamically changes = the key according to plaintext and practically impossible to break. I = also opened to public with MIT License. > It is also quite fast; ~80% faster than the fastest mode of AES = without cpu instruction set support. > I will present a paper on a Turkish National Symposium on 3 December: = Inet-tr 2015. I am sending the document as an attachment Sorry, it is in = Turkish Language.=20 > I've studied political sciences. Unfortunately, I haven't mathematical = background to write the proof. But it is a very simple logic. Anyone who = looks at the attached C code may understand why and how it is = unbreakable.=20 >=20 > I use the key as jump table and with every encrypted byte, I change = the jump table(the key) as a result of 3-4 parameters including the last = plaintext byte itself. > The code is self documented in English. > On Linux simply=20 > gcc HohhaDynamicXOR.c -O2 -Wall > ./a.out > will make integrity checks and print benchmarks. It is production = ready. > Other algorithm results are the output of the "openssl speed" command. > If I am right; you will not be disappointed to include "Hohha Dynamic = XOR Encryption Algorithm" on TLS 1.3 Draft. Here are the benchmarks for = 16,64,256,1024,8192 byte values with -O2 optimization level(-O3 gives = ~20% better results).Hop2 is 2 jump results and Hop3 is 3 jump results. > Please feel free to ask any questions or any explanation I can give. >=20 > Regards > Ismail Kizir >=20 > Algoritma >=20 > 16 >=20 > 64 >=20 > 256 >=20 > 1024 >=20 > 8192 >=20 > Memcpy >=20 > 663.42 >=20 > 1052.33 >=20 > 1043.33 >=20 > 1147.54 >=20 > 869.60 >=20 > Hohha XOR-Hop2 >=20 > 162.33 >=20 > 193.15 >=20 > 198.17 >=20 > 198.65 >=20 > 202.56 >=20 > Hohha XOR Hop3 >=20 > 116.46 >=20 > 127.42 >=20 > 130.00 >=20 > 130.36 >=20 > 127.33 >=20 > des cbc >=20 > 44.98 >=20 > 46.53 >=20 > 46.90 >=20 > 47.14 >=20 > 47.05 >=20 > des ede3 >=20 > 17.65 >=20 > 18.00 >=20 > 18.03 >=20 > 18.03 >=20 > 18.06 >=20 > rc2 cbc >=20 > 26.58 >=20 > 27.10 >=20 > 27.28 >=20 > 27.25 >=20 > 27.35 >=20 > rc4 >=20 > 22.22 >=20 > 36.02 >=20 > 41.81 >=20 > 43.71 >=20 > 43.63 >=20 > blowfish cbc >=20 > 84.71 >=20 > 90.58 >=20 > 91.71 >=20 > 91.28 >=20 > 91.41 >=20 > Cast cbc >=20 > 81.23 >=20 > 86.99 >=20 > 88.62 >=20 > 89.00 >=20 > 89.10 >=20 > aes-128 cbc >=20 > 77.85 >=20 > 85.20 >=20 > 87.91 >=20 > 18.27 >=20 > 18.59 >=20 > aes-192 cbc >=20 > 65.98 >=20 > 71.70 >=20 > 72.70 >=20 > 15.53 >=20 > 15.65 >=20 > Aes-256 cbc >=20 > 57.59 >=20 > 61.22 >=20 > 62.43 >=20 > 133.67 >=20 > 134.40 >=20 > Camellia-128 >=20 > 74.04 >=20 > 109.17 >=20 > 124.03 >=20 > 12.87 >=20 > 12.88 >=20 > Camellia-192 >=20 > 62.57 >=20 > 85.60 >=20 > 94.68 >=20 > 97.20 >=20 > 98.11 >=20 > Camellia-256 >=20 > 62.58 >=20 > 85.63 >=20 > 94.69 >=20 > 97.35 >=20 > 97.97 >=20 > aes-128 ige >=20 > 78.44 >=20 > 82.05 >=20 > 83.08 >=20 > 83.42 >=20 > 83.17 >=20 > Aes-192 ige >=20 > 66.25 >=20 > 69.13 >=20 > 69.75 >=20 > 69.95 >=20 > 69.94 >=20 > Aes-256 ige >=20 > 57.69 >=20 > 59.71 >=20 > 60.22 >=20 > 60.40 >=20 > 60.27 >=20 > = ____________________________________= ___________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Nov 17 05:58: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 A70941B2FA8 for ; Tue, 17 Nov 2015 05:58:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 6qv_Ibb-Pk4g for ; Tue, 17 Nov 2015 05:58:21 -0800 (PST) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0: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 D69B01B2FA5 for ; Tue, 17 Nov 2015 05:58:20 -0800 (PST) Received: by vkgy188 with SMTP id y188so2618436vkg.0 for ; Tue, 17 Nov 2015 05:58:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nbWTjXXFrt70S7/jfuCcE8mHib43eTjWi1JUuSHemcI=; b=hg5WIElgpDsVtTgwVcveYognyzxcOF91M/q+VQCsUMRHen+RT4qoZVdCePvjgTAnzY xUvEaioHYWp9VuJcOuf+ddJCGHmDo5q3lQPP299t+bC3kGRA0HXmp9I7PqDlaVsj/bj+ 2gkBCiwrMQTHdnY4rP/+cXSkFgZBcD949MAiU= 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=nbWTjXXFrt70S7/jfuCcE8mHib43eTjWi1JUuSHemcI=; b=F/FeNPqfMK5L3P1dqrb4ZsYe+J75stAIlhF7MGn5dK7eRllg6/sBqLZj4qA368jDq7 jQ9f9Us8rLEawYnOLgnHyx+PHzGTSgFjbr9wlMQ5u8raK8k+xoLmR/5ci4oQixzu7BGi 4OLRAO54lYHMs7AXepDw9SiBTfkNr3VX+dKb2r/b/F510ashXLTO5K/MnJmiZAUAJ1JM R2FTroRBJxYiHcp7ZA5SNTxEY/1FpYjOIIk1cuAJRw52Mttq7bIjHxTp2h78r9Oe+hHg vPBBWnOhBgZIkVBICqHBa6Db00yVvLwkmn9sWcGeTE3SOBcGn2aiHtSulqHHBF+eJZeF a+eg== X-Gm-Message-State: ALoCoQlt2Jt5Lxs5pPHjQctF/ViPfy7S33yRtAlbf75qjI4UrJpj/X4yN8+yxoBHjuKpaIVedW2y X-Received: by 10.31.6.76 with SMTP id 73mr3908327vkg.102.1447768699770; Tue, 17 Nov 2015 05:58:19 -0800 (PST) Received: from [5.5.33.110] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id g195sm3047944vkg.0.2015.11.17.05.58.18 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Nov 2015 05:58:19 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Sean Turner In-Reply-To: Date: Tue, 17 Nov 2015 15:58:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Eric Rescorla X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR#345: IANA Considerations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 13:58:22 -0000 > On Nov 17, 2015, at 01:18, Eric Rescorla wrote: >=20 > Double-checking, I see that some of the entries in the "TLS 1.3" = column > for Extensions are wrong. Will be updating shortly. >=20 > On Mon, Nov 16, 2015 at 3:16 PM, Eric Rescorla wrote: > PR: https://github.com/tlswg/tls13-spec/pull/345 >=20 > Per discussion in Yokohama, I have rewritten the IANA considerations = section > so that the 16-bit code spaces are "Specification Required" and they = have > a "Recommended" column. >=20 > 1. The Cipher Suites "Recommended" column was populated based on > the Standards Track RFCs listed in the document (and I removed the > others). Isn=E2=80=99t it just the MTI suites listed in s8.1? Also, I added a comment in github requesting that we add a permanent = note to the registry to alert folks looking there for the Recommended = Yes/No marking. IANA [SHALL add/has added] the following to the following to the TLS = Cipher Suite Registry: NOTE Cipher suites marked as "Yes" are the MTI TLS 1.3 cipher suites in the RFC 2119-sense (See Section 8.1 of [THISRFC]) and can be updated later. Algorithms marked as "No" are not; cipher suites marked "No" range from "good" to "bad" from a cryptographic standpoint. Maybe we should also add that cipher suites marked =E2=80=9CNo=E2=80=9D = can later be marked as =E2=80=9CYes=E2=80=9D later? spt > 2. The Extensions "Recommended"column was populated by taking all > the Standards Track RFCs and marking them "Yes" and marking > others "No". I recognize that this probably marks a bunch of = extensions > which we actually don't love as "Yes" (and perhaps others as "No") > and if people want to move some from one column to another, that > seems like a great mailing list discussion which I will let the = chairs > drive. >=20 > Thanks, > -Ekr >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Nov 17 06:33: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 17DAC1A1A34 for ; Tue, 17 Nov 2015 06:33:12 -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, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPyb0-M99bBp for ; Tue, 17 Nov 2015 06:33:11 -0800 (PST) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 296071A1A19 for ; Tue, 17 Nov 2015 06:33:11 -0800 (PST) Received: by ykdr82 with SMTP id r82so10835814ykd.3 for ; Tue, 17 Nov 2015 06:33:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=gytlvzgfkGxKeSzOq/i96XrV3NkQVW/ZH2LAJigB4s8=; b=o12ugXLFnlcDP0fofMKe4qwEMRjqsoRGqQ5QMVKXcQjEXXffaXipE0HmsdSnITXGm9 oGJWYhDJEgaC+3CH1o00SLxIbCTXbVG65ss0SHwMfBa/TSDic8SpBwnUnqUq8fspQRfh q17RmiTWWuZ5KeTBriQCnNHmRmZ/S+E3WEvb0/tsx0jUm1a5YC+7USFiItA4OEu4qJ6b 5oHe4LwnIgI+QiWm5bJXVS0yJ8ZVfNDaVZ9FKGls1FADjJc7YySKyTTOtxduJKH7YRoZ fZvpY4IkPy1mAI3eXP3ascT3utoawLY7pdCCaYzgRmqz9VPmxJPFzq5H2LcZ59D7LJE4 5KHg== 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=gytlvzgfkGxKeSzOq/i96XrV3NkQVW/ZH2LAJigB4s8=; b=WDiJ9mtoWDCTzOMr5eK9J4MHONCL07bbYl9X7/62wPHHhJcwODWGTXYY5fSy+ej4Tz RcnaMnzmZsHWbfZKHd2JbDMkSX23lo688rbELmgBF8Evk+8hvtkVv1RVAy3YS3UAqCrB fjpzR2Ig6tgw9+It7Ko3HAMZtHLw5gHwURZplhaR6svDLm8y1P3/LOZHkttU9TuK/H92 gSTOZw9VJBXA9S7c3Kgho52j0BSz0qvknzwG6ntDNTs6uCLLQFrfEQR36WxQlNkPUQUq vFcQZ0Nh+ePC0N3u7eUHeUEvLhJJRNiHsOve/1b5yttTO3GMceb+sVDVHeXwD7NefxDe zIKw== X-Gm-Message-State: ALoCoQn6GFCnJ4T3pGMSwuvp72RJL3BGCVG6OKEv/UiPWgqdjJ+9qovslmw82JEHH1sJNAjtnzhu X-Received: by 10.13.212.9 with SMTP id w9mr16740581ywd.192.1447770790462; Tue, 17 Nov 2015 06:33:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.221.203 with HTTP; Tue, 17 Nov 2015 06:32:31 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Tue, 17 Nov 2015 06:32:31 -0800 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a114fa638aec6af0524bd6778 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR#346: Individual traffic key generation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 14:33:12 -0000 --001a114fa638aec6af0524bd6778 Content-Type: text/plain; charset=UTF-8 On Mon, Nov 16, 2015 at 10:29 PM, Martin Thomson wrote: > On 16 November 2015 at 19:52, Eric Rescorla wrote: > >> I have to ask why the continued insistence on calling the thing that > >> forms part of the nonce an "IV". I find it to be misleading. > > > > > > This is the historical terminology that TLS has used. > > It was actually accurate when we were using CBC modes, but now it's > just confusing. > It wasn't accurate in TLS 1.1 or later. -Ekr --001a114fa638aec6af0524bd6778 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Nov 16, 2015 at 10:29 PM, Martin Thomson <= martin.thomso= n@gmail.com> wrote:
On 16 November 2015 at 19:52, Eric Rescorla <ekr@rtfm.com> wrote:
>> I have to ask why the continued insistence on calling the thing th= at
>> forms part of the nonce an "IV".=C2=A0 I find it to be m= isleading.
>
>
> This is the historical terminology that TLS has used.

It was actually accurate when we were using CBC modes, but now it= 9;s
just confusing.

It wasn't accur= ate in TLS 1.1 or later.

-Ekr

--001a114fa638aec6af0524bd6778-- From nobody Tue Nov 17 06:40: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 3CEF71A88D1 for ; Tue, 17 Nov 2015 06:40:42 -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, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7KGkQVLjL0VN for ; Tue, 17 Nov 2015 06:40:40 -0800 (PST) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80F821A88C0 for ; Tue, 17 Nov 2015 06:40:40 -0800 (PST) Received: by ykba77 with SMTP id a77so11149059ykb.2 for ; Tue, 17 Nov 2015 06:40:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=4sJXyk5hTF6jAcIHLd1dUzxfT9ReRW4cgD3CtJc4F/4=; b=hv1SXoDT/GOlLQoyerWmmBEYMoMJTEtmrW1ouRo5KvdUlB/sKZQlq2xojaJbjg/dME d/oy1j+xaJSNrjghiomKE6dtr0efa5ByVShob6Z6wCoI6ThmiTjiGIsgllL9v8PEv6Qv yBd88Vx8lmm4iFgIYpf/QSPDaYs37oSFwK7z5cR5Ac9cZrMyI1cOlSVPQ/mA+dXgnFBQ N+7ADX0yL5IBU/JHaHXKgvKiYBHr5OnTbSVsBU86OaaOwTvBiWSztjp8P3sIae1KanjU qvezw+BHL/yQ42P3+dnHfhbZdjE+eQYhEbSL2kQMARvyyRh6EtbZga7GLHGGI5GpWdAM auLw== 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=4sJXyk5hTF6jAcIHLd1dUzxfT9ReRW4cgD3CtJc4F/4=; b=XHlzBge9yGF0SsW54mI/rDSAM3sZSqVkfxv6ejo7Z1NwGWNE4b0L8v3QVySG9jiTZD lFjNMbzNfRl+WAgc+pK3tGBv2qke97rDOiN+gFFcxaZKG3cE6BfZs0RotzPatz4rJMlM nXgglv2W86VM9Z377xdUXFLPmvTg20BjMWajaG6F9HS9wMaEoo7yi2hv9bAQbkWBUsjn vOn0qutecn+GYpA4v2+KbTgzZLXx1h+ZOB7yM2kb/WY/snQ/f+1jlqJVECiO/AYsXNCv P6GU9CJQplnk4vRbrkrlLCmFbD/Q+E9sLCxATfvClL8MZtgD5GkwxOII3TLZPIOZVvUo 2Utw== X-Gm-Message-State: ALoCoQkHiumoWjJE/1h+yusw0VUdd8KJKCUI4MHtQkab/JNZmQNVAW8boKj8YTBJgp1F4YqBL25c X-Received: by 10.13.197.194 with SMTP id h185mr33103136ywd.12.1447771239715; Tue, 17 Nov 2015 06:40:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.221.203 with HTTP; Tue, 17 Nov 2015 06:40:00 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Tue, 17 Nov 2015 06:40:00 -0800 Message-ID: To: Sean Turner Content-Type: multipart/alternative; boundary=001a114edd4a75c7040524bd8297 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR#345: IANA Considerations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 14:40:42 -0000 --001a114edd4a75c7040524bd8297 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Nov 17, 2015 at 5:58 AM, Sean Turner wrote: > > > On Nov 17, 2015, at 01:18, Eric Rescorla wrote: > > > > Double-checking, I see that some of the entries in the "TLS 1.3" column > > for Extensions are wrong. Will be updating shortly. > > > > On Mon, Nov 16, 2015 at 3:16 PM, Eric Rescorla wrote: > > PR: https://github.com/tlswg/tls13-spec/pull/345 > > > > Per discussion in Yokohama, I have rewritten the IANA considerations > section > > so that the 16-bit code spaces are "Specification Required" and they ha= ve > > a "Recommended" column. > > > > 1. The Cipher Suites "Recommended" column was populated based on > > the Standards Track RFCs listed in the document (and I removed the > > others). > > Isn=E2=80=99t it just the MTI suites listed in s8.1? > Maybe I need to go check the minutes, but I thought it was the Standards Track ones, not the MTI ones that we agreed on. The difference here is largely the FFDHE cipher suites and CCM. Also, I added a comment in github requesting that we add a permanent note > to the registry to alert folks looking there for the Recommended Yes/No > marking. > > IANA [SHALL add/has added] the following to the following to the TLS > Cipher Suite Registry: > > NOTE > Cipher suites marked as "Yes" are the MTI TLS 1.3 cipher suites > in the RFC 2119-sense (See Section 8.1 of [THISRFC]) and can be > updated later. Algorithms marked as "No" are not; cipher suites > marked "No" range from "good" to "bad" from a cryptographic > standpoint. > > Maybe we should also add that cipher suites marked =E2=80=9CNo=E2=80=9D c= an later be > marked as =E2=80=9CYes=E2=80=9D later? > Sure. PR or it didn't happen :) -Ekr > > spt > > > > 2. The Extensions "Recommended"column was populated by taking all > > the Standards Track RFCs and marking them "Yes" and marking > > others "No". I recognize that this probably marks a bunch of > extensions > > which we actually don't love as "Yes" (and perhaps others as "No") > > and if people want to move some from one column to another, that > > seems like a great mailing list discussion which I will let the > chairs > > drive. > > > > Thanks, > > -Ekr > > > > > > > > > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > --001a114edd4a75c7040524bd8297 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Nov 17, 2015 at 5:58 AM, Sean Turner <sean@sn3rd.com> wrote:

> On Nov 17, 2015, at 01:18, Eric Rescorla <ekr@rtfm.com> wrote:
>
> Double-checking, I see that some of the entries in the "TLS 1.3&q= uot; column
> for Extensions are wrong. Will be updating shortly.
>
> On Mon, Nov 16, 2015 at 3:16 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> PR: https://github.com/tlswg/tls13-spec/pull/345
>
> Per discussion in Yokohama, I have rewritten the IANA considerations s= ection
> so that the 16-bit code spaces are "Specification Required" = and they have
> a "Recommended" column.
>
> 1. The Cipher Suites "Recommended" column was populated base= d on
>=C2=A0 =C2=A0 =C2=A0the Standards Track RFCs listed in the document (an= d I removed the
>=C2=A0 =C2=A0 =C2=A0others).

Isn=E2=80=99t it just the MTI suites listed in s8.1?

Maybe I need to go check the minutes, but I thought it= was the
Standards Track ones, not the MTI ones that we agreed on= .
The difference here is largely the FFDHE cipher suites and CCM.=


Also, I added a comment in github requesting that we add a permanent note t= o the registry to alert folks looking there for the Recommended Yes/No mark= ing.

IANA [SHALL add/has added] the following to the following to the TLS Cipher= Suite Registry:

NOTE
=C2=A0 =C2=A0 =C2=A0 Cipher suites marked as "Yes" are the MTI TL= S 1.3 cipher suites
=C2=A0 =C2=A0 =C2=A0 in the RFC 2119-sense (See Section 8.1 of [THISRFC]) a= nd can be
=C2=A0 =C2=A0 =C2=A0 updated later. Algorithms marked as "No" are= not; cipher suites
=C2=A0 =C2=A0 =C2=A0 marked "No" range from "good" to &= quot;bad" from a cryptographic
=C2=A0 =C2=A0 =C2=A0 standpoint.

Maybe we should also add that cipher suites marked =E2=80=9CNo=E2=80=9D can= later be marked as =E2=80=9CYes=E2=80=9D later?

--001a114edd4a75c7040524bd8297-- From nobody Tue Nov 17 06:42: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 793B91A8928 for ; Tue, 17 Nov 2015 06:42:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 ukQklMf6OGcX for ; Tue, 17 Nov 2015 06:41:58 -0800 (PST) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0: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 CA61D1A89A2 for ; Tue, 17 Nov 2015 06:41:56 -0800 (PST) Received: by vkha189 with SMTP id a189so6577859vkh.1 for ; Tue, 17 Nov 2015 06:41:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9qkPeY57u26Cqi0siIHCWnM/kxwOzpN/P/MbxprIqQo=; b=BZy6Uqvm85PZM1lBixrnC294ZhAVXa612EK4pd7OPdAug8pLlC6kGTCzU4qgjlgk7H V40/t6p1fxHLsiZ/qMoRYghrjvXmanKX/EaGJgGkyCK9Kr3oG98qhaEkOejoAiGVY4qT 3cv5opO9YO6oNa9RKWOwmDzNzWrG7LkV0/U4A= 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=9qkPeY57u26Cqi0siIHCWnM/kxwOzpN/P/MbxprIqQo=; b=POhZZJMHKhlwS1vMvnryNypQ3N+zc7vTTw5vjig+DBQUBouf6Tic1vV3yNEDh0U3bm NQtJCwWc3mLSwaGPQyftjEFXUixjfVrMQy9O17wQmsVxaFtZtsrztvOWihsGB/OYP2/V VS5vJhEY/OsF3PXiWOAEjdtYhbpSII8jgjSizf9TSg9EIB4LwhCO4Y3ZjWHVXChLERm1 4XQ00vCdTvBDQMUCxuxL7+0hD+tEBFvzQvTPbi7CwOOX/SA6C+zVzLjD6wLJdDoSlUaB 8t6BysAvsGF9ZGqgRbOcK4wCiUMYgHpiwDzqvxbkxCdG7nc2Au7ChdfOf4Kdo+UINFU/ IRDQ== X-Gm-Message-State: ALoCoQmxo+TFFMJgT54pdVh4jPMMSHAuLZgw0gX1tiljDFfwUW5SzC5q3zQTWkKNlymoDv2QefiR X-Received: by 10.31.108.153 with SMTP id j25mr4128717vki.81.1447771315912; Tue, 17 Nov 2015 06:41:55 -0800 (PST) Received: from ?IPv6:2001:67c:64:42:4e4:d264:2484:3411? ([2001:67c:64:42:4e4:d264:2484:3411]) by smtp.gmail.com with ESMTPSA id a206sm3199518vke.16.2015.11.17.06.41.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Nov 2015 06:41:55 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Sean Turner In-Reply-To: Date: Tue, 17 Nov 2015 16:41:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Eric Rescorla X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR#345: IANA Considerations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 14:42:00 -0000 On Nov 17, 2015, at 16:40, Eric Rescorla wrote: >=20 >=20 >=20 > On Tue, Nov 17, 2015 at 5:58 AM, Sean Turner wrote: >=20 > > On Nov 17, 2015, at 01:18, Eric Rescorla wrote: > > > > Double-checking, I see that some of the entries in the "TLS 1.3" = column > > for Extensions are wrong. Will be updating shortly. > > > > On Mon, Nov 16, 2015 at 3:16 PM, Eric Rescorla wrote: > > PR: https://github.com/tlswg/tls13-spec/pull/345 > > > > Per discussion in Yokohama, I have rewritten the IANA considerations = section > > so that the 16-bit code spaces are "Specification Required" and they = have > > a "Recommended" column. > > > > 1. The Cipher Suites "Recommended" column was populated based on > > the Standards Track RFCs listed in the document (and I removed = the > > others). >=20 > Isn=E2=80=99t it just the MTI suites listed in s8.1? >=20 > Maybe I need to go check the minutes, but I thought it was the > Standards Track ones, not the MTI ones that we agreed on. > The difference here is largely the FFDHE cipher suites and CCM. Fair enough we should double check. > Also, I added a comment in github requesting that we add a permanent = note to the registry to alert folks looking there for the Recommended = Yes/No marking. >=20 > IANA [SHALL add/has added] the following to the following to the TLS = Cipher Suite Registry: >=20 > NOTE > Cipher suites marked as "Yes" are the MTI TLS 1.3 cipher suites > in the RFC 2119-sense (See Section 8.1 of [THISRFC]) and can be > updated later. Algorithms marked as "No" are not; cipher suites > marked "No" range from "good" to "bad" from a cryptographic > standpoint. >=20 > Maybe we should also add that cipher suites marked =E2=80=9CNo=E2=80=9D = can later be marked as =E2=80=9CYes=E2=80=9D later? >=20 > Sure. PR or it didn't happen :) Ack :) > -Ekr > =20 >=20 > spt >=20 >=20 > > 2. The Extensions "Recommended"column was populated by taking all > > the Standards Track RFCs and marking them "Yes" and marking > > others "No". I recognize that this probably marks a bunch of = extensions > > which we actually don't love as "Yes" (and perhaps others as = "No") > > and if people want to move some from one column to another, that > > seems like a great mailing list discussion which I will let the = chairs > > drive. > > > > Thanks, > > -Ekr > > > > > > > > > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls >=20 >=20 From nobody Tue Nov 17 06:54: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 750571A8AE3 for ; Tue, 17 Nov 2015 06:54:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 MqGFO7S2iLgE for ; Tue, 17 Nov 2015 06:54:50 -0800 (PST) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0: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 0EC031A8AD0 for ; Tue, 17 Nov 2015 06:54:50 -0800 (PST) Received: by vkgy188 with SMTP id y188so3848520vkg.0 for ; Tue, 17 Nov 2015 06:54:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZzlJDs35MYFGYY1pYASUyCRujgMBm6JPSUfWK2V2sbQ=; b=Fiys+ljZUDri2sp/XgI51zCpvXmkJqfDFY+x/33mj9/zrIZYKV+WH1FMtbdGcn5/Tz XDw0tNQBt17lfwyr5Frg2LV5JL9bDuewvyoSo3ykSUYnkGlEbIWEHtnECxh+sUxi289G nWe7nAwM8+l2t64U3vSBpuWKDgkpODBTTQqDs= 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=ZzlJDs35MYFGYY1pYASUyCRujgMBm6JPSUfWK2V2sbQ=; b=RJl3yTSCFVFpjCrjArfpoDknP9DCyc1ToCJ1RufafB98j1BCUS7dCqDHd9yMwY5VIy xaFfHVxZhD5SznIGFnl8HTQgNQouPTzfI3qI/quGgqbDYknxDep5m5IhY6UgRYCsB4WZ UMLLTKBNHMZbynGW77+rN9FW+hB4FgvFKIaMNfhaULtOCYb6/V/HR4eZ5nBONS0+Rrd8 AplRTFjT9mLTV+CSVQaQwjSJRHpCAJ6Cbpw4Bg7yq+5OJ9v7feThh0vC0oCVeW3dpmPo WC2TFQ3+h9d6uyF08+zgurfmORlBuFLkv3jt/YDAXjKzque5FARj+pUsVDt5VmFNg96G hUWA== X-Gm-Message-State: ALoCoQmx9sOpSYnAR6XKlCHmKuyqRYzAxTbwDU6yCfZyhIEZu+hZHRzrN5yLUDAx0WdPqaanLzrZ X-Received: by 10.31.41.195 with SMTP id p186mr3990557vkp.139.1447772089209; Tue, 17 Nov 2015 06:54:49 -0800 (PST) Received: from ?IPv6:2001:67c:64:42:4e4:d264:2484:3411? ([2001:67c:64:42:4e4:d264:2484:3411]) by smtp.gmail.com with ESMTPSA id o65sm3244198vkf.11.2015.11.17.06.54.48 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Nov 2015 06:54:48 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Sean Turner In-Reply-To: Date: Tue, 17 Nov 2015 16:54:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Eric Rescorla X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR#345: IANA Considerations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 14:54:51 -0000 On Nov 17, 2015, at 16:40, Eric Rescorla wrote: >=20 > > 1. The Cipher Suites "Recommended" column was populated based on > > the Standards Track RFCs listed in the document (and I removed = the > > others). >=20 > Isn=E2=80=99t it just the MTI suites listed in s8.1? >=20 > Maybe I need to go check the minutes, but I thought it was the > Standards Track ones, not the MTI ones that we agreed on. > The difference here is largely the FFDHE cipher suites and CCM. =46rom Jim=E2=80=99s notes in the etherpad: AOB SPT: Requests for additional ciphers from others. Listing in A.4 Suggest thinning it down to the SHOULD/MUST list only. EKR: Need to encourage support for PSK variants EKR: Looking at the difference between the "good" list and the "safe" = list and the "no opinion" list EKR: Sample case would be 448 - not a MUST/SHOULD but still think it is = good. spt= From nobody Tue Nov 17 07:25: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 4DFEA1A90F3 for ; Tue, 17 Nov 2015 07:25:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.985 X-Spam-Level: X-Spam-Status: No, score=-1.985 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, J_CHICKENPOX_84=0.6, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gnyD54eDa7XH for ; Tue, 17 Nov 2015 07:25:20 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5401A90FC for ; Tue, 17 Nov 2015 07:25:20 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 88E9C4334A0 for ; Tue, 17 Nov 2015 15:25:19 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 7178D433469 for ; Tue, 17 Nov 2015 15:25:19 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1447773919; bh=Ej9Si54kK7Acb8W+vUwivw9IhMWie6WfGCmkjxBtSKw=; l=7672; h=From:To:Date:From; b=mvRsTrKpYwW2d/SyC/b+8orlPXe02Bvq6R6JDISxYylLwCYp/gKNtPKAgIya0IVH2 sdThRKUym2RXUTBa34hHn0i0rAMocKKHvfjtul+/QW3Qe0cXbmg39do6kUPuZvUyBM MZ5U2X+00WyncyZl91VqnSiWl837740kb2KPosOM= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.34]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 6D9CA202F for ; Tue, 17 Nov 2015 15:25:19 +0000 (GMT) Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 17 Nov 2015 10:25:19 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1076.000; Tue, 17 Nov 2015 10:25:19 -0500 From: "Short, Todd" To: "tls@ietf.org" Thread-Topic: Record header size? Thread-Index: AQHRIUwqo2PzkmG0m02LaFyKO+3dUw== Date: Tue, 17 Nov 2015 15:25:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.42.131] Content-Type: multipart/alternative; boundary="_000_C5F506DCF8144C0BAFAA86CF790817A7akamaicom_" MIME-Version: 1.0 Archived-At: Subject: [TLS] Record header size? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 15:25:25 -0000 --_000_C5F506DCF8144C0BAFAA86CF790817A7akamaicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Apologies if this has been brought up before. Has there been any consideration to changing the record header for encrypte= d traffic to be 4 bytes (i.e. 32-bits)? 5 bytes is a very awkward size, and= some processors do not handle odd byte offsets well (it was a complaint I = heard from Cisco router/switch engineers). The latest TLS1.3 draft indicates that the record_version is deprecated and= must be ignored. If TLSv1.3 is negotiated, then I propose that the record_= version value must be { 4 } for encrypted records, making the version field= is a single byte, such that the length of the record_header is reduced to = 4 bytes. Alternatively, a TLS extension could be added to negotiate the size of the = record_header. Yes, this creates a serious backwards compatibility issue, but if the recor= d_version field is deprecated, then perhaps a change to the record_header c= ould be made. Thus: struct { uint8 major; uint8 minor; } ProtocolVersion; struct { ContentType type; ProtocolVersion record_version =3D { 3, 1 }; /* TLS v1.x */ uint16 length; opaque fragment[TLSPlaintext.length]; } TLSPlaintext; struct { ContentType opaque_type =3D application_data(23); /* see fragment.ty= pe */ uint8 record_version =3D { 4 }; /* TLS v1.3 4-byte record header = */ uint16 length; aead-ciphered struct { opaque content[TLSPlaintext.length]; ContentType type; uint8 zeros[length_of_padding]; } fragment; } TLSCiphertext; -- -Todd Short // tshort@akamai.com // "One if by land, two if by sea, three if by the Internet." --_000_C5F506DCF8144C0BAFAA86CF790817A7akamaicom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Apologies if this has been brought up before.

Has there been any consideration to changing the record hea= der for encrypted traffic to be 4 bytes (i.e. 32-bits)? 5 bytes is a very a= wkward size, and some processors do not handle odd byte offsets well (it wa= s a complaint I heard from Cisco router/switch engineers).

The latest TLS1.3 draft indicates that the record_version i= s deprecated and must be ignored. If TLSv1.3 is negotiated, then I propose = that the record_version value must be { 4 } for encrypted records, making t= he version field is a single byte, such that the length of the record_header is reduced to 4 bytes. 

Alternatively, a TLS extension could be added to negotiate = the size of the record_header.

Yes, this creates a serious backwards compatibility issue, = but if the record_version field is deprecated, then perhaps a change to the= record_header could be made.

Thus:

   struct {
       uint8 major;
       uint8 minor;
   } ProtocolVersion;

   struct {
       ContentType type;
       ProtocolVersion record_version =3D { 3, 1 };&nb= sp;   /* TLS v1.x */
       uint16 length;
       opaque fragment[TLSPlaintext.length];
   } TLSPlaintext;

   struct {
       ContentType opaque_type =3D application_data(23= ); /* see fragment.type */
       uint8 record_version =3D { 4 };  &nbs= p; /* TLS v1.3 4-byte record header */
       uint16 length;
       aead-ciphered struct {
          opaque content[TLSPlaintext.length];
          ContentType type;
          uint8 zeros[length_of_padding];
       } fragment;
   } TLSCiphertext;

--
-Todd Short
// tshort@a= kamai.com
// "One if by land, two if by sea, three if by the Int= ernet."

--_000_C5F506DCF8144C0BAFAA86CF790817A7akamaicom_-- From nobody Tue Nov 17 07:41: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 E7FEB1ACCFB for ; Tue, 17 Nov 2015 07:41:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.785 X-Spam-Level: X-Spam-Status: No, score=-4.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylbd1I_gf68p for ; Tue, 17 Nov 2015 07:41:06 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52E091ACC87 for ; Tue, 17 Nov 2015 07:41:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1447774866; x=1479310866; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=rlN0fbeuN2jLcODzcV7to4rGAc7rJFEdyaSQOqPjStE=; b=OzKX1smEnmNZpbecXnATcGgjRevjDKSbv3dZEIMCsusmxm7K7d2Rxchl hZJgw3VoM7l8NJirz61oK5HRdxRTLxYQJdLCn0F7DYaG/DdUYTx+mamU2 2Iw1mTFp3wUiDl4I2YqoT51IBgphpmEJRKvPdHDdpOKvZMbiwrks9Zx53 5b2pC0teh8M9J0PILvnvb1GarA1YwL7ZfwuWU/Bx7ZNMYHlxM4zkTp03u uc/HlAv3f5lDYwZBoC0OoqLrgyCkLx+UnjQUozQytXBMwXGlQ+w3I6rPN 9RYUrn7ovgikv7x3amaVJydvxwml/ix/jMPVf4hElDXkzZk3t9xfKidQO A==; X-IronPort-AV: E=Sophos;i="5.20,308,1444647600"; d="scan'208";a="54627423" 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 mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 18 Nov 2015 04:40:57 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.51]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0174.001; Wed, 18 Nov 2015 04:40:56 +1300 From: Peter Gutmann To: "Short, Todd" , "tls@ietf.org" Thread-Topic: Record header size? Thread-Index: AQHRIUwqo2PzkmG0m02LaFyKO+3dU56gWSPK Date: Tue, 17 Nov 2015 15:40:56 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B66D1F@uxcn10-5.UoA.auckland.ac.nz> References: In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Record header size? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 15:41:12 -0000 Short, Todd writes:=0A= =0A= >Has there been any consideration to changing the record header for encrypt= ed=0A= >traffic to be 4 bytes (i.e. 32-bits)? 5 bytes is a very awkward size, and= =0A= >some processors do not handle odd byte offsets well (it was a complaint I= =0A= >heard from Cisco router/switch engineers).=0A= =0A= Not just Cisco, other hardware people have run into it as well. You don't= =0A= need the version field at all because it's been negotiated in the handshake= ,=0A= for the remainder of the session it's just wasted bytes. So having a 1-byt= e=0A= type and 3-byte length for a combined 32-bit field would work fine.=0A= =0A= Peter.= From nobody Tue Nov 17 08:35: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 3A8311A0363 for ; Tue, 17 Nov 2015 08:35:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 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, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0GWxtK55-mBm for ; Tue, 17 Nov 2015 08:35:52 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id C2AB11A0335 for ; Tue, 17 Nov 2015 08:35:51 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 2CEAE4F08C; Tue, 17 Nov 2015 16:35:51 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 156B64F043; Tue, 17 Nov 2015 16:35:51 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1447778151; bh=kyVWO/1Hi4uVvC5IbQRMagryL1uYvBWF5sV0ghr6NTY=; l=4629; h=From:To:CC:Date:References:In-Reply-To:From; b=jgCOaJVRKy04dWEw6be8gfFFJ+Qa2fTzM4NHkjKIHdVAKras2Umus+tti++ZSSnf6 YNfxutyditQKU2E3NsM1mENYVkKWvmwgw1Kwecr+r8SywE9mpT3TbUWydS9MCyjEPO so3pQlkDdd5o2FQNQdNvdbdxtCyJF4IP5YvLhqMc= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 0FD05202D; Tue, 17 Nov 2015 16:35:51 +0000 (GMT) Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 17 Nov 2015 08:35:50 -0800 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1076.000; Tue, 17 Nov 2015 11:35:50 -0500 From: "Short, Todd" To: Peter Gutmann Thread-Topic: Record header size? Thread-Index: AQHRIUwqfC6IjHws+EWK+zLpB/KhZp6gresAgAAPVwA= Date: Tue, 17 Nov 2015 16:35:50 +0000 Message-ID: References: <9A043F3CF02CD34C8E74AC1594475C73F4B66D1F@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B66D1F@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.42.131] Content-Type: multipart/alternative; boundary="_000_AE3C380F10FF4CFA8A11194E2B649EB9akamaicom_" MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Record header size? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 16:35:53 -0000 --_000_AE3C380F10FF4CFA8A11194E2B649EB9akamaicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Plaintext is still limited to 2^14 octets, so there is no need to have the = length be 3 bytes. Having the version start with 4 will purposely indicate = the size of the record header. One could go out on a limb and use it to act= ually indicate the length of the header (i.e. 5 bytes, 4 bytes, 8 bytes, et= c.) with additional options thrown in, not that I am proposing that. -- -Todd Short // tshort@akamai.com // "One if by land, two if by sea, three if by the Internet." On Nov 17, 2015, at 10:40 AM, Peter Gutmann > wrote: Short, Todd > writes: Has there been any consideration to changing the record header for encrypte= d traffic to be 4 bytes (i.e. 32-bits)? 5 bytes is a very awkward size, and some processors do not handle odd byte offsets well (it was a complaint I heard from Cisco router/switch engineers). Not just Cisco, other hardware people have run into it as well. You don't need the version field at all because it's been negotiated in the handshake= , for the remainder of the session it's just wasted bytes. So having a 1-byt= e type and 3-byte length for a combined 32-bit field would work fine. Peter. --_000_AE3C380F10FF4CFA8A11194E2B649EB9akamaicom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Plaintext is still limited to 2^14 octets, so there is no need to have the = length be 3 bytes. Having the version start with 4 will purposely indicate = the size of the record header. One could go out on a limb and use it to act= ually indicate the length of the header (i.e. 5 bytes, 4 bytes, 8 bytes, etc.) with additional options thro= wn in, not that I am proposing that.
--
-Todd Short
// tshort@a= kamai.com
// "One if by land, two if by sea, three if by the Int= ernet."

On Nov 17, 2015, at 10:40 AM, Peter Gutmann <pgut001@cs.auckland.ac.nz&= gt; wrote:

Short, Todd <tshort@akamai.com> writes:

Has there been any consideration to ch= anging the record header for encrypted
traffic to be 4 bytes (i.e. 32-bits)? 5 bytes is a very awkward size, and some processors do not handle odd byte offsets well (it was a complaint I heard from Cisco router/switch engineers).

Not just Cisco, other hardware people have run into it as well.  You d= on't
need the version field at all because it's been negotiated in the handshake= ,
for the remainder of the session it's just wasted bytes.  So having a = 1-byte
type and 3-byte length for a combined 32-bit field would work fine.

Peter.

--_000_AE3C380F10FF4CFA8A11194E2B649EB9akamaicom_-- From nobody Tue Nov 17 08:46: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 18FB61A064C for ; Tue, 17 Nov 2015 08:46:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZf8wartC2Ev for ; Tue, 17 Nov 2015 08:46:16 -0800 (PST) Received: from us-smtp-delivery-180.mimecast.com (us-smtp-delivery-180.mimecast.com [63.128.21.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D6B71A19EC for ; Tue, 17 Nov 2015 08:46:13 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0142.outbound.protection.outlook.com [207.46.163.142]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-20-lFec5dPhRru0r6mZu-WRUw-1; Tue, 17 Nov 2015 11:46:09 -0500 Received: from BL2PR03MB148.namprd03.prod.outlook.com (10.255.230.27) by BL2PR03MB146.namprd03.prod.outlook.com (10.255.230.18) with Microsoft SMTP Server (TLS) id 15.1.318.15; Tue, 17 Nov 2015 16:46:07 +0000 Received: from BL2PR03MB148.namprd03.prod.outlook.com ([169.254.9.84]) by BL2PR03MB148.namprd03.prod.outlook.com ([169.254.9.84]) with mapi id 15.01.0318.003; Tue, 17 Nov 2015 16:46:07 +0000 From: Joe Salowey To: Sean Turner , Eric Rescorla Thread-Topic: [TLS] PR#345: IANA Considerations Thread-Index: AQHRIMUAZTWql70kIkiA6aXjyclI2Z6fSL4AgAD1tACAAAuwAIAABB+A//+ZAAA= Date: Tue, 17 Nov 2015 16:46:07 +0000 Message-ID: <7276DA5B-0563-4D70-A611-96A2E80CAECB@tableau.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.150923 x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [69.25.143.34] x-microsoft-exchange-diagnostics: 1; BL2PR03MB146; 5:ucgl9wLyk2Z5O3G294gZ83Mc3k6kxVMN5E5DRtL6gM0SLjc5vkTcGHDrJDxGh1veMVdptPowIAbXd4FCtgplPdBP9A/DLPpif5SF8eGoYtW+91i1n99txTQ/IGiCZgZHvbBPJ4oU+pjO0d4hI9+JoQ==; 24:h5Pr4XlBw/adWtfRfshYvZjJ67tR0b90jtnsgTuNlHmZ3eZgFkWL1t35JZBEae8ADvBaeUmGQVrIbI2POm+b3EQXILhrAyEKZg3ugKWGytU=; 20:Jh7kYWT0452KEzBhXmkIYNGQQl10u1TlVkYzKCweY+csOFoxMS1Tz4lzOeCXF6FobNmKE6fCx+scZ0Y0015t65BNF/Kg8I35nPKEWRm5wSTesmL/Y7pejd4Wdd3T0Xz58IkuBrHXSlaNgL7vYfW/DC4AGeSTxUotVPVMaqKDi7w= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB146; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046); SRVR:BL2PR03MB146; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB146; x-forefront-prvs: 07630F72AD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(377454003)(199003)(189002)(24454002)(87936001)(106116001)(10400500002)(105586002)(83506001)(106356001)(83716003)(4001350100001)(5001770100001)(82746002)(101416001)(54356999)(97736004)(76176999)(50986999)(5002640100001)(189998001)(5001960100002)(66066001)(81156007)(33656002)(92566002)(86362001)(99286002)(586003)(19580395003)(19580405001)(93886004)(36756003)(11100500001)(5008740100001)(122556002)(5004730100002)(2950100001)(15975445007)(102836002)(40100003)(5007970100001)(2900100001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB146; H:BL2PR03MB148.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-ID: MIME-Version: 1.0 X-OriginatorOrg: tableau.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2015 16:46:07.3184 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5067385a-c584-42cc-8679-3fa2879f99be X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR03MB146 X-MC-Unique: lFec5dPhRru0r6mZu-WRUw-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR#345: IANA Considerations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 16:46:21 -0000 SSB0aGluayB0aGUgVExTIDEuMyBJQU5BIGNvbnNpZGVyYXRpb25zIHNob3VsZCBqdXN0IGRlYWwg d2l0aCBzZXR0aW5nIHVwIHRoZSByZWNvbW1lbmRlZCBjb2x1bW4gYW5kIG1hcmtpbmcgaXQgZm9y IHRoZSBjaXBoZXIgc3VpdGVzL2V4dGVuc2lvbnMgdGhhdCBhcmUgZGVzY3JpYmVkIGluIHRoZSAx LjMgZG9jdW1lbnQuICBPdGhlciBjaXBoZXIgc3VpdGVzL2V4dGVuc2lvbnMgIGNhbiBiZSBtYXJr ZWQgYXMgcmVjb21tZW5kZWQgdGhyb3VnaCBvdGhlciBkb2N1bWVudHMuICANCg0KDQoNCg0KT24g MTEvMTcvMTUsIDY6NTQgQU0sICJUTFMgb24gYmVoYWxmIG9mIFNlYW4gVHVybmVyIiA8dGxzLWJv dW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHNlYW5Ac24zcmQuY29tPiB3cm90ZToNCg0KPk9u IE5vdiAxNywgMjAxNSwgYXQgMTY6NDAsIEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbT4gd3Jv dGU6DQo+PiANCj4+ID4gMS4gVGhlIENpcGhlciBTdWl0ZXMgIlJlY29tbWVuZGVkIiBjb2x1bW4g d2FzIHBvcHVsYXRlZCBiYXNlZCBvbg0KPj4gPiAgICAgdGhlIFN0YW5kYXJkcyBUcmFjayBSRkNz IGxpc3RlZCBpbiB0aGUgZG9jdW1lbnQgKGFuZCBJIHJlbW92ZWQgdGhlDQo+PiA+ICAgICBvdGhl cnMpLg0KPj4gDQo+PiBJc27igJl0IGl0IGp1c3QgdGhlIE1USSBzdWl0ZXMgbGlzdGVkIGluIHM4 LjE/DQo+PiANCj4+IE1heWJlIEkgbmVlZCB0byBnbyBjaGVjayB0aGUgbWludXRlcywgYnV0IEkg dGhvdWdodCBpdCB3YXMgdGhlDQo+PiBTdGFuZGFyZHMgVHJhY2sgb25lcywgbm90IHRoZSBNVEkg b25lcyB0aGF0IHdlIGFncmVlZCBvbi4NCj4+IFRoZSBkaWZmZXJlbmNlIGhlcmUgaXMgbGFyZ2Vs eSB0aGUgRkZESEUgY2lwaGVyIHN1aXRlcyBhbmQgQ0NNLg0KPg0KPkZyb20gSmlt4oCZcyBub3Rl cyBpbiB0aGUgZXRoZXJwYWQ6DQo+DQo+QU9CDQo+U1BUOiBSZXF1ZXN0cyBmb3IgYWRkaXRpb25h bCBjaXBoZXJzIGZyb20gb3RoZXJzLiAgTGlzdGluZyBpbiBBLjQNCj4JU3VnZ2VzdCB0aGlubmlu ZyBpdCBkb3duIHRvIHRoZSBTSE9VTEQvTVVTVCBsaXN0IG9ubHkuDQo+RUtSOiBOZWVkIHRvIGVu Y291cmFnZSBzdXBwb3J0IGZvciBQU0sgdmFyaWFudHMNCj5FS1I6IExvb2tpbmcgYXQgdGhlIGRp ZmZlcmVuY2UgYmV0d2VlbiB0aGUgImdvb2QiIGxpc3QgYW5kIHRoZSAic2FmZSIgbGlzdCBhbmQg dGhlICJubyBvcGluaW9uIiBsaXN0DQo+RUtSOiBTYW1wbGUgY2FzZSB3b3VsZCBiZSA0NDggLSBu b3QgYSBNVVNUL1NIT1VMRCBidXQgc3RpbGwgdGhpbmsgaXQgaXMgZ29vZC4NCj4NCj5zcHQNCj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPlRMUyBtYWls aW5nIGxpc3QNCj5UTFNAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3Rscw0K From nobody Tue Nov 17 09:10: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 4FE701A1B40 for ; Tue, 17 Nov 2015 09:10:12 -0800 (PST) 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, HTML_MESSAGE=0.001, J_CHICKENPOX_84=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 sMqORCZTXIk4 for ; Tue, 17 Nov 2015 09:10:10 -0800 (PST) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::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 B3DF21A1B5A for ; Tue, 17 Nov 2015 09:10:10 -0800 (PST) Received: by ykfs79 with SMTP id s79so17042787ykf.1 for ; Tue, 17 Nov 2015 09:10:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=UL27LThAhTefllEFPNJSnvtWSFya8Sh94ouIYAo+tiU=; b=0tCipm6ylYW/T+nz/OWfH4/FfLREOy7BbbUz6K/C/7Qm/QprNYpMlsKOJHKAXWJgwe BOkUZmW5pl4+XVhrwNL5LJe7ZbGqFVYR0PaG4X3kkxfA4dVvDfjqVHhPRywvC6OLiadI dj++wTuGoZoJT92WPQZDg2PuuRQRaNssJlUxMlyG3DRnJ0kNj8O/KPgU/AZK+l+7rr+M akrWjdWm4ntcmsb1A71/XqntM0ykx++7HJSIIXXiwHHoQ4OBHg0xE1yTwCEaSiGSLJXi rrKd1716XOef4OBax0E4cCaGgaJvo+5tu0gJlQST9XdV75s9MyqKkoFKr14pwJ5+265+ ay5A== 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=UL27LThAhTefllEFPNJSnvtWSFya8Sh94ouIYAo+tiU=; b=RXOzvXNWLBb4PY5eJZBPzN8Q7iejhCdtpLH+JApbSZbKM+8h4K5YcmlHAuZ+J9bSfg 5MgHodkatmPBJjMjvekYDB7pCrLrZkZwAjB4STMq7IVQP1L4Ix3bdoDT+vqHEuONSO2k Uk8CIFL4eZRNRFYaKLskLeYdFL+0+EOFq1bsRvAgVu6jPnM2dBEl6O7M+Zr2uae7blOF T60LiGZGRdE2/iJR9IZGzmzCI6z1sBcD5rgJ0lF86xXP+joabW1HB612tyc1ny2k2QMN ccZBlZ4O3ddZhMlfJd87ZNG4+dIKNlPHB+waIvcTw2zB8KKWXN7pti+X5r2mmKFfwAT+ 0FKg== X-Gm-Message-State: ALoCoQkdVPLt8e8G2aeQcbhCi11M+oE8UmsUcjdMdryOwz4PSEA4Z6JMuJhspLU0/3RcWK58i5t0 X-Received: by 10.13.212.9 with SMTP id w9mr17512083ywd.192.1447780209916; Tue, 17 Nov 2015 09:10:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.221.203 with HTTP; Tue, 17 Nov 2015 09:09:30 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Tue, 17 Nov 2015 09:09:30 -0800 Message-ID: To: "Short, Todd" Content-Type: multipart/alternative; boundary=001a114fa63820362c0524bf9941 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Record header size? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 17:10:12 -0000 --001a114fa63820362c0524bf9941 Content-Type: text/plain; charset=UTF-8 The concern here is backward compatibility with inspection middleboxes which expect the length field to be in a particular place. We agreed in Seattle to wait for early deployment experience before modifying the header to move the length. -Ekr On Tue, Nov 17, 2015 at 7:25 AM, Short, Todd wrote: > Apologies if this has been brought up before. > > Has there been any consideration to changing the record header for > encrypted traffic to be 4 bytes (i.e. 32-bits)? 5 bytes is a very awkward > size, and some processors do not handle odd byte offsets well (it was a > complaint I heard from Cisco router/switch engineers). > > The latest TLS1.3 draft indicates that the record_version is deprecated > and must be ignored. If TLSv1.3 is negotiated, then I propose that the > record_version value must be { 4 } for encrypted records, making the > version field is a single byte, such that the length of the record_header > is reduced to 4 bytes. > > Alternatively, a TLS extension could be added to negotiate the size of the > record_header. > > Yes, this creates a serious backwards compatibility issue, but if the > record_version field is deprecated, then perhaps a change to the > record_header could be made. > > Thus: > > struct { > uint8 major; > uint8 minor; > } ProtocolVersion; > > struct { > ContentType type; > ProtocolVersion record_version = { 3, 1 }; /* TLS v1.x */ > uint16 length; > opaque fragment[TLSPlaintext.length]; > } TLSPlaintext; > > struct { > ContentType opaque_type = application_data(23); /* see > fragment.type */ > uint8 record_version = { 4 }; /* TLS v1.3 4-byte record header */ > uint16 length; > aead-ciphered struct { > opaque content[TLSPlaintext.length]; > ContentType type; > uint8 zeros[length_of_padding]; > } fragment; > } TLSCiphertext; > > -- > -Todd Short > // tshort@akamai.com > // "One if by land, two if by sea, three if by the Internet." > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a114fa63820362c0524bf9941 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The concern here is backward compatibility with inspection= middleboxes which
expect the length field to be in a particular place.= We agreed in Seattle to
wait for early deployment experience bef= ore modifying the header to move
the length.

=
-Ekr


On Tue, Nov 17, 2015 at 7:25 AM, Short, T= odd <tshort@akamai.com> wrote:
Apologies if this has been brought up before.

Has there been any consideration to changing the record header for enc= rypted traffic to be 4 bytes (i.e. 32-bits)? 5 bytes is a very awkward size= , and some processors do not handle odd byte offsets well (it was a complai= nt I heard from Cisco router/switch engineers).

The latest TLS1.3 draft indicates that the record_version is deprecate= d and must be ignored. If TLSv1.3 is negotiated, then I propose that the re= cord_version value must be { 4 } for encrypted records, making the version = field is a single byte, such that the length of the record_header is reduced to 4 bytes.=C2=A0

Alternatively, a TLS extension could be added to negotiate the size of= the record_header.

Yes, this creates a serious backwards compatibility issue, but if the = record_version field is deprecated, then perhaps a change to the record_hea= der could be made.

Thus:

=C2=A0 =C2=A0str= uct {
=C2=A0 =C2=A0 = =C2=A0 =C2=A0uint8 major;
=C2=A0 =C2=A0 = =C2=A0 =C2=A0uint8 minor;
=C2=A0 =C2=A0} P= rotocolVersion;

=C2=A0 =C2=A0str= uct {
=C2=A0=C2=A0 =C2= =A0 =C2=A0 ContentType type;
=C2=A0=C2=A0 =C2= =A0 =C2=A0 ProtocolVersion record_version =3D { 3, 1 };=C2=A0 =C2=A0 /* TLS= v1.x */
=C2=A0=C2=A0 =C2= =A0 =C2=A0 uint16 length;
=C2=A0=C2=A0 =C2= =A0 =C2=A0 opaque fragment[TLSPlaintext.length];
=C2=A0=C2=A0 } T= LSPlaintext;

=C2=A0=C2=A0 str= uct {
=C2=A0=C2=A0 =C2= =A0 =C2=A0 ContentType opaque_type =3D application_data(23); /* see fragmen= t.type */
=C2=A0 =C2=A0 = =C2=A0 =C2=A0uint8=C2=A0record_version =3D { 4 };=C2=A0 =C2=A0 /* TLS v1.3 = 4-byte record header */
=C2=A0=C2=A0 =C2= =A0 =C2=A0 uint16 length;
=C2=A0=C2=A0 =C2= =A0 =C2=A0 aead-ciphered struct {
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 opaque content[TLSPlaintext.length];
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 ContentType type;
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 uint8 zeros[length_of_padding];
=C2=A0=C2=A0 =C2= =A0 =C2=A0 } fragment;
=C2=A0=C2=A0 } T= LSCiphertext;

--
-Todd Short
// "One if by land, two if by sea, three if by the Internet."= ;


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


--001a114fa63820362c0524bf9941-- From nobody Tue Nov 17 09: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 ACF341B2CEE for ; Tue, 17 Nov 2015 09:52:14 -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, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SR4r-5v-tY3f for ; Tue, 17 Nov 2015 09:52:13 -0800 (PST) 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 0CDE91B2D10 for ; Tue, 17 Nov 2015 09:52:13 -0800 (PST) Received: by ykdr82 with SMTP id r82so19078670ykd.3 for ; Tue, 17 Nov 2015 09:52:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=DH73GwwyqrmLBHecRrGagMUmt5qwNt+xEFbDm+OEQ1I=; b=w6vSL5Fjg+utsJziEcIvSiOwU38nIZNy1vtxb8F9P8/5r4PpDrhDVsKzhwgQfB0Yfx gBYseRlbhRLUkWKPWuMTfXe+kBBVumMEU0nCiXNIZSpgb6EIDTZtSdVYScAAwDjHphfg yyqG3Bmx+71ZS1ZRd9RVibSVaMmpZj+42oC3rpZ8VnxXnPS0YOhpD+FSU13p3F6Ihocu XXCVY85AO8S08AB54RUnBbyrAC7jH2h3bmBvCA2h+zZ3A+crB5VUawRIojihX0v4FmaO VRC1ecg3IjNoOv06A0CHsXHMFNRNyrpovulEDUdnpfMd91+VDYaOyi9oM2o0sHo+4WWw OJBw== 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=DH73GwwyqrmLBHecRrGagMUmt5qwNt+xEFbDm+OEQ1I=; b=BXbk2MkbxSGvltp2pc7pkZEdXzZhi3yvI/88MPFpidHrqrPtb1uwAzfMMUtZpBnxs+ LIgEA8SymyhVAQa+CBh+c4rUB5mNfEByRae2kgmMRouohI+e32oXLLI3+wAefZhCUYg/ EO+nPAJ7QB8ij9EbcNH9WNv1U7Oes96XhIZ1ccfKNO79LAp8P/KF336I4v6+0dVbv+Mm H5an2Dz2KIBXqhKRlEjfYpl6g0BhEjEcHyBDL/81XHYyrQ9YWJjFod2KwRQloBdMt5jq 37Rr9UdaBoj33qsbqeCMwHNphNn8LjN5SnksYXA4qSD+i+v5bD3hlZ0aynlapveyHGRA JHSA== X-Gm-Message-State: ALoCoQkS+w3cD3wO5CNKY53bdeFXZw3IKGcEi/hkn9nRajVArF23W0mLxrcYHPXEWf9WxtaUS1Fc X-Received: by 10.13.249.4 with SMTP id j4mr41048644ywf.129.1447782732263; Tue, 17 Nov 2015 09:52:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.221.203 with HTTP; Tue, 17 Nov 2015 09:51:32 -0800 (PST) In-Reply-To: <7276DA5B-0563-4D70-A611-96A2E80CAECB@tableau.com> References: <7276DA5B-0563-4D70-A611-96A2E80CAECB@tableau.com> From: Eric Rescorla Date: Tue, 17 Nov 2015 09:51:32 -0800 Message-ID: To: Joe Salowey Content-Type: multipart/alternative; boundary=94eb2c0826e87822ea0524c02f2b Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR#345: IANA Considerations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 17:52:14 -0000 --94eb2c0826e87822ea0524c02f2b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable There are presently four categories of cipher suites vis-a-vis TLS 1.3. 1. MUST or SHOULD cipher suites. 2. Standards track cipher suites (or ones we are making ST, like the ECC ones). 3. Non standards track cipher suites 4. Cipher suites you can't use at all with TLS 1.3, like AES-CBC. I think we're all agreed that category #1 should be marked recommended and that #3 and #4 should not be. This leaves us with category #2, which includes stuff like: - FFDHE - CCM My proposal is that we: - List all the Standards Track cipher suites that are compatible with TLS 1.3 in Appendix A. - Mark all the cipher suites that are listed in Appendix A as "Recommended" -Ekr On Tue, Nov 17, 2015 at 8:46 AM, Joe Salowey wrote: > I think the TLS 1.3 IANA considerations should just deal with setting up > the recommended column and marking it for the cipher suites/extensions th= at > are described in the 1.3 document. Other cipher suites/extensions can b= e > marked as recommended through other documents. > > > > > On 11/17/15, 6:54 AM, "TLS on behalf of Sean Turner" on behalf of sean@sn3rd.com> wrote: > > >On Nov 17, 2015, at 16:40, Eric Rescorla wrote: > >> > >> > 1. The Cipher Suites "Recommended" column was populated based on > >> > the Standards Track RFCs listed in the document (and I removed t= he > >> > others). > >> > >> Isn=E2=80=99t it just the MTI suites listed in s8.1? > >> > >> Maybe I need to go check the minutes, but I thought it was the > >> Standards Track ones, not the MTI ones that we agreed on. > >> The difference here is largely the FFDHE cipher suites and CCM. > > > >From Jim=E2=80=99s notes in the etherpad: > > > >AOB > >SPT: Requests for additional ciphers from others. Listing in A.4 > > Suggest thinning it down to the SHOULD/MUST list only. > >EKR: Need to encourage support for PSK variants > >EKR: Looking at the difference between the "good" list and the "safe" > list and the "no opinion" list > >EKR: Sample case would be 448 - not a MUST/SHOULD but still think it is > good. > > > >spt > >_______________________________________________ > >TLS mailing list > >TLS@ietf.org > >https://www.ietf.org/mailman/listinfo/tls > --94eb2c0826e87822ea0524c02f2b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There are presently four categories of cipher suites vis-a= -vis TLS 1.3.

1. MUST or SHOULD cipher suites.
2. Standards track cipher suites (or ones we are making ST, like
=C2=A0 =C2=A0 the ECC ones).
3. Non standards track cipher suite= s
4. Cipher suites you can't use at all with TLS 1.3, like AE= S-CBC.

I think we're all agreed that category = #1 should be marked recommended
and that #3 and #4 should not be.= This leaves us with category #2, which
includes stuff like:

- FFDHE
- CCM

My pr= oposal is that we:

- List all the Standards Track = cipher suites that are compatible with TLS 1.3 in Appendix A.
- M= ark all the cipher suites that are listed in Appendix A as "Recommende= d"

-Ekr





=
On Tue, Nov 17, 2015 at 8:46 AM, Joe Salowey= <jsalowey@tableau.com> wrote:
I think the TLS 1.3 IANA considerations should just deal with setti= ng up the recommended column and marking it for the cipher suites/extension= s that are described in the 1.3 document.=C2=A0 Other cipher suites/extensi= ons=C2=A0 can be marked as recommended through other documents.




On 11/17/15, 6:54 AM, "TLS on behalf of Sean Turner" <tls-bounces@ietf.org on behalf of sean@sn3rd.com> wrote:

>On Nov 17, 2015, at 16:40, Eric Rescorla <ekr@rtfm.com> wrote:
>>
>> > 1. The Cipher Suites "Recommended" column was popul= ated based on
>> >=C2=A0 =C2=A0 =C2=A0the Standards Track RFCs listed in the doc= ument (and I removed the
>> >=C2=A0 =C2=A0 =C2=A0others).
>>
>> Isn=E2=80=99t it just the MTI suites listed in s8.1?
>>
>> Maybe I need to go check the minutes, but I thought it was the
>> Standards Track ones, not the MTI ones that we agreed on.
>> The difference here is largely the FFDHE cipher suites and CCM. >
>From Jim=E2=80=99s notes in the etherpad:
>
>AOB
>SPT: Requests for additional ciphers from others.=C2=A0 Listing in A.4<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Suggest thinning it down to the SHOULD/MUST = list only.
>EKR: Need to encourage support for PSK variants
>EKR: Looking at the difference between the "good" list and th= e "safe" list and the "no opinion" list
>EKR: Sample case would be 448 - not a MUST/SHOULD but still think it is= good.
>
>spt
>___________________= ____________________________
>TLS mailing list
>TLS@ietf.org
>https://www.ietf.org/mailman/listinfo/tls

--94eb2c0826e87822ea0524c02f2b-- From nobody Tue Nov 17 09:53: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 680421B2D16 for ; Tue, 17 Nov 2015 09:53:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uoY1TCBvKdjI for ; Tue, 17 Nov 2015 09:53:43 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id CB4E71B2D39 for ; Tue, 17 Nov 2015 09:53:43 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 4582F43349D; Tue, 17 Nov 2015 17:53:42 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 2FB7343346A; Tue, 17 Nov 2015 17:53:42 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1447782822; bh=dFksnNmmsF7o/g1DRikVXMhTuG0fYlT/U4aJ2Eb4YmU=; l=584; h=To:References:Cc:From:Date:In-Reply-To:From; b=IXekAZCMkV6G0r1BJSb8oYxUYn6uISEiHGxc1AWOwex8AzGmNLw0Ay0dlz8nvrl7U 3Rvs/PToH2foR7gt8iMuTwo3HWnypMjQDATOcGE6lc7lorD3tQ+XgMNPlj6ZjAHwVU DXACssmuAqK0EVOnYwleYi8CTTdJsjynZHUGsDD0= Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id F19D1202C; Tue, 17 Nov 2015 17:53:41 +0000 (GMT) To: Joe Salowey References: <7276DA5B-0563-4D70-A611-96A2E80CAECB@tableau.com> From: Benjamin Kaduk Message-ID: <564B69A5.2030205@akamai.com> Date: Tue, 17 Nov 2015 11:53:41 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <7276DA5B-0563-4D70-A611-96A2E80CAECB@tableau.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR#345: IANA Considerations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 17:53:45 -0000 On 11/17/2015 10:46 AM, Joe Salowey wrote: > I think the TLS 1.3 IANA considerations should just deal with setting up the recommended column and marking it for the cipher suites/extensions that are described in the 1.3 document. Other cipher suites/extensions can be marked as recommended through other documents. > That would seem to leave a number of things in limbo until this hypothetical other document or documents come out. It seems more responsible in some sense to make the registry be in a coherent/consistent state from the time its structure is modified. -Ben From nobody Tue Nov 17 10: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 B1A561B2EBD for ; Tue, 17 Nov 2015 10:01:40 -0800 (PST) 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 xnptqxMCaWTv for ; Tue, 17 Nov 2015 10:01:38 -0800 (PST) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 342A51B2EB5 for ; Tue, 17 Nov 2015 10:01:38 -0800 (PST) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 913BBF2403D for ; Tue, 17 Nov 2015 13:01:27 -0500 (EST) 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 cLQEsUSzGJ6V for ; Tue, 17 Nov 2015 13:00:17 -0500 (EST) Received: from [192.168.2.104] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id CF9B0F24013 for ; Tue, 17 Nov 2015 13:01:26 -0500 (EST) From: Russ Housley Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-114--822844187 Date: Tue, 17 Nov 2015 13:01:14 -0500 In-Reply-To: To: IETF TLS References: <7276DA5B-0563-4D70-A611-96A2E80CAECB@tableau.com> Message-Id: X-Mailer: Apple Mail (2.1085) Archived-At: Subject: Re: [TLS] PR#345: IANA Considerations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 18:01:40 -0000 --Apple-Mail-114--822844187 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 +1. This seems like a reasonable way forward. Russ On Nov 17, 2015, at 12:51 PM, Eric Rescorla wrote: > There are presently four categories of cipher suites vis-a-vis TLS = 1.3. >=20 > 1. MUST or SHOULD cipher suites. > 2. Standards track cipher suites (or ones we are making ST, like > the ECC ones). > 3. Non standards track cipher suites > 4. Cipher suites you can't use at all with TLS 1.3, like AES-CBC. >=20 > I think we're all agreed that category #1 should be marked recommended > and that #3 and #4 should not be. This leaves us with category #2, = which > includes stuff like: >=20 > - FFDHE > - CCM >=20 > My proposal is that we: >=20 > - List all the Standards Track cipher suites that are compatible with = TLS 1.3 in Appendix A. > - Mark all the cipher suites that are listed in Appendix A as = "Recommended" >=20 > -Ekr >=20 >=20 >=20 >=20 >=20 >=20 > On Tue, Nov 17, 2015 at 8:46 AM, Joe Salowey = wrote: > I think the TLS 1.3 IANA considerations should just deal with setting = up the recommended column and marking it for the cipher = suites/extensions that are described in the 1.3 document. Other cipher = suites/extensions can be marked as recommended through other documents. >=20 >=20 >=20 >=20 > On 11/17/15, 6:54 AM, "TLS on behalf of Sean Turner" = wrote: >=20 > >On Nov 17, 2015, at 16:40, Eric Rescorla wrote: > >> > >> > 1. The Cipher Suites "Recommended" column was populated based on > >> > the Standards Track RFCs listed in the document (and I = removed the > >> > others). > >> > >> Isn=92t it just the MTI suites listed in s8.1? > >> > >> Maybe I need to go check the minutes, but I thought it was the > >> Standards Track ones, not the MTI ones that we agreed on. > >> The difference here is largely the FFDHE cipher suites and CCM. > > > >=46rom Jim=92s notes in the etherpad: > > > >AOB > >SPT: Requests for additional ciphers from others. Listing in A.4 > > Suggest thinning it down to the SHOULD/MUST list only. > >EKR: Need to encourage support for PSK variants > >EKR: Looking at the difference between the "good" list and the "safe" = list and the "no opinion" list > >EKR: Sample case would be 448 - not a MUST/SHOULD but still think it = is good. > > > >spt > >_______________________________________________ > >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-114--822844187 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 +1. =  This seems like a reasonable way = forward.

Russ


On= Nov 17, 2015, at 12:51 PM, Eric Rescorla wrote:

There are presently four categories of cipher suites = vis-a-vis TLS 1.3.

1. MUST or SHOULD cipher = suites.
2. Standards track cipher suites (or ones we are = making ST, like
    the ECC ones).
3. Non = standards track cipher suites
4. Cipher suites you can't use = at all with TLS 1.3, like AES-CBC.

I think = we're all agreed that category #1 should be marked = recommended
and that #3 and #4 should not be. This leaves us = with category #2, which
includes stuff = like:

- FFDHE
- = CCM

My proposal is that = we:

- List all the Standards Track cipher = suites that are compatible with TLS 1.3 in Appendix A.
- Mark = all the cipher suites that are listed in Appendix A as = "Recommended"

-Ekr


<= /div>




On Tue, Nov 17, = 2015 at 8:46 AM, Joe Salowey <jsalowey@tableau.com> = wrote:
I think the TLS 1.3 = IANA considerations should just deal with setting up the recommended = column and marking it for the cipher suites/extensions that are = described in the 1.3 document.  Other cipher = suites/extensions  can be marked as recommended through other = documents.




On 11/17/15, 6:54 AM, "TLS on behalf of Sean Turner" <tls-bounces@ietf.org on behalf = of sean@sn3rd.com> wrote:

>On Nov 17, 2015, at 16:40, Eric Rescorla <ekr@rtfm.com> wrote:
>>
>> > 1. The Cipher Suites "Recommended" column was populated = based on
>> >     the Standards Track RFCs listed in the = document (and I removed the
>> >     others).
>>
>> Isn=92t it just the MTI suites listed in s8.1?
>>
>> Maybe I need to go check the minutes, but I thought it was = the
>> Standards Track ones, not the MTI ones that we agreed on.
>> The difference here is largely the FFDHE cipher suites and = CCM.
>
>=46rom Jim=92s notes in the etherpad:
>
>AOB
>SPT: Requests for additional ciphers from others.  Listing in = A.4
>       Suggest thinning it down to the = SHOULD/MUST list only.
>EKR: Need to encourage support for PSK variants
>EKR: Looking at the difference between the "good" list and the = "safe" list and the "no opinion" list
>EKR: Sample case would be 448 - not a MUST/SHOULD but still think it = is good.
>
>spt
>_______________________________________________
>TLS mailing list
>TLS@ietf.org
>https://www.ietf.org/mailman/listinfo/tls

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

= --Apple-Mail-114--822844187-- From nobody Tue Nov 17 10:36: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 53FD91B3308 for ; Tue, 17 Nov 2015 10:36:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 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, HTTPS_HTTP_MISMATCH=1.989, 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 3CqQKgMjPxLC for ; Tue, 17 Nov 2015 10:36:43 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0126.outbound.protection.outlook.com [207.46.100.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 989811B3307 for ; Tue, 17 Nov 2015 10:36:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zCl3LHkYcSVikVJGVd3ihXUtnaUwpUhJnRN8MMV5RN0=; b=a8DUPo1r9OiyDV/F7mYvN1JKyDmZfyQCi3ScdxcfXiqeYt/T3mxbWlFedIowdvARDvbX8S9p9o0vkQd6mpn7B7v1UbUkp7ouVkm3Q1tY8R+wwI29ccr8XfvIxxDsemNJvI4tFjbGg7TizFuRncyLRmdhVd1sT81PBD++HIM5j8s= Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) with Microsoft SMTP Server (TLS) id 15.1.318.15; Tue, 17 Nov 2015 18:36:41 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0318.003; Tue, 17 Nov 2015 18:36:40 +0000 From: Andrei Popov To: Russ Housley , IETF TLS Thread-Topic: [TLS] PR#345: IANA Considerations Thread-Index: AQHRIMT9OVhyjmu2u0CH56orafUz4Z6fSL4AgAD1tACAAAuwAIAABB+AgAAfHYCAABJHAIAAArYAgAAI+eA= Date: Tue, 17 Nov 2015 18:36:40 +0000 Message-ID: References: <7276DA5B-0563-4D70-A611-96A2E80CAECB@tableau.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:f::1d2] x-microsoft-exchange-diagnostics: 1; BLUPR03MB1396; 5:WaxoiBOIajsUU+Zj7vV9MzFzOMRIvWv35RAo8Kn2RVIEXh3L8KZdRE+qTiVxm1j3Hezp/dsFPUJGgcPTZsrU5Hmpw1/ViowN8rLep2FfDdBNMoEqYSZZVXfWQ70VVQfXoU7TQLJiWqiFjngnVt86lQ==; 24:2tzVCvfeIP7qFv7FP7U6wk8mJfNQQzkFDIVsa4bfHgIEZVQpY9MSTwuxcDxLGu2UlnalUDtCNioRlk0Ww/EoompzN7ySfy3wNCObkVTeIhU=; 20:iWxbB3kNzYNbclTApFC+sq6bxSZ79NIZN+PGLeqpyxHuVKL0RuVsHfMK4YugteLyLw8rFxOfoE7P7Rzn/Uigsw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1396; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(31773223642792)(189930954265078)(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(520078)(8121501046)(5005006)(3002001)(10201501046)(61426024)(61427024); SRVR:BLUPR03MB1396; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1396; x-forefront-prvs: 07630F72AD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(24454002)(479174004)(199003)(189002)(99286002)(77096005)(54356999)(19609705001)(40100003)(8990500004)(76176999)(5005710100001)(87936001)(105586002)(106356001)(10400500002)(10290500002)(50986999)(5002640100001)(92566002)(5003600100002)(19625215002)(2950100001)(101416001)(189998001)(16236675004)(33656002)(76576001)(102836002)(122556002)(19617315012)(2900100001)(15975445007)(10090500001)(561944003)(93886004)(5001920100001)(5001960100002)(107886002)(81156007)(5001770100001)(97736004)(106116001)(5004730100002)(5007970100001)(86362001)(5008740100001)(74316001)(86612001)(19580405001)(19580395003)(19300405004)(586003)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1396; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR03MB139629A2B2EE9BCD591AA4BB8C1D0BLUPR03MB1396namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2015 18:36:40.5752 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1396 Archived-At: Subject: Re: [TLS] PR#345: IANA Considerations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 18:36:49 -0000 --_000_BLUPR03MB139629A2B2EE9BCD591AA4BB8C1D0BLUPR03MB1396namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable What is the intended use of the "Recommended" list? I.e. how is an implemen= ter supposed to think about this marker? Cheers, Andrei From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Russ Housley Sent: Tuesday, November 17, 2015 10:01 AM To: IETF TLS Subject: Re: [TLS] PR#345: IANA Considerations +1. This seems like a reasonable way forward. Russ On Nov 17, 2015, at 12:51 PM, Eric Rescorla wrote: There are presently four categories of cipher suites vis-a-vis TLS 1.3. 1. MUST or SHOULD cipher suites. 2. Standards track cipher suites (or ones we are making ST, like the ECC ones). 3. Non standards track cipher suites 4. Cipher suites you can't use at all with TLS 1.3, like AES-CBC. I think we're all agreed that category #1 should be marked recommended and that #3 and #4 should not be. This leaves us with category #2, which includes stuff like: - FFDHE - CCM My proposal is that we: - List all the Standards Track cipher suites that are compatible with TLS 1= .3 in Appendix A. - Mark all the cipher suites that are listed in Appendix A as "Recommended" -Ekr On Tue, Nov 17, 2015 at 8:46 AM, Joe Salowey > wrote: I think the TLS 1.3 IANA considerations should just deal with setting up th= e recommended column and marking it for the cipher suites/extensions that a= re described in the 1.3 document. Other cipher suites/extensions can be m= arked as recommended through other documents. On 11/17/15, 6:54 AM, "TLS on behalf of Sean Turner" on behalf of sean@sn3rd.com> wrote: >On Nov 17, 2015, at 16:40, Eric Rescorla > wrote: >> >> > 1. The Cipher Suites "Recommended" column was populated based on >> > the Standards Track RFCs listed in the document (and I removed the >> > others). >> >> Isn't it just the MTI suites listed in s8.1? >> >> Maybe I need to go check the minutes, but I thought it was the >> Standards Track ones, not the MTI ones that we agreed on. >> The difference here is largely the FFDHE cipher suites and CCM. > >From Jim's notes in the etherpad: > >AOB >SPT: Requests for additional ciphers from others. Listing in A.4 > Suggest thinning it down to the SHOULD/MUST list only. >EKR: Need to encourage support for PSK variants >EKR: Looking at the difference between the "good" list and the "safe" list= and the "no opinion" list >EKR: Sample case would be 448 - not a MUST/SHOULD but still think it is go= od. > >spt >_______________________________________________ >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 --_000_BLUPR03MB139629A2B2EE9BCD591AA4BB8C1D0BLUPR03MB1396namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

What is the intended use of the ̶= 0;Recommended” list? I.e. how is an implementer supposed to think abo= ut this marker?

 

Cheers,

 

Andrei

 

From: TLS [mailto:tls-bounces@ietf.o= rg] On Behalf Of Russ Housley
Sent: Tuesday, November 17, 2015 10:01 AM
To: IETF TLS <tls@ietf.org>
Subject: Re: [TLS] PR#345: IANA Considerations

 

+1.  This seems like a reasonable way forwa= rd.

 

Russ

 

 

On Nov 17, 2015, at 12:51 PM, Eric Rescorla wrote:



There are presently four categories of cipher suites= vis-a-vis TLS 1.3.

 

1. MUST or SHOULD cipher suites.

2. Standards track cipher suites (or ones we are mak= ing ST, like

    the ECC ones).

3. Non standards track cipher suites

4. Cipher suites you can't use at all with TLS 1.3, = like AES-CBC.

 

I think we're all agreed that category #1 should be = marked recommended

and that #3 and #4 should not be. This leaves us wit= h category #2, which

includes stuff like:

 

- FFDHE

- CCM

 

My proposal is that we:

 

- List all the Standards Track cipher suites that ar= e compatible with TLS 1.3 in Appendix A.

- Mark all the cipher suites that are listed in Appe= ndix A as "Recommended"

 

-Ekr

 

 

 

 

 

 

On Tue, Nov 17, 2015 at 8:46 AM, Joe Salowey <jsalowey@tableau.com= > wrote:

I think the TLS 1.3 IANA considerations should just = deal with setting up the recommended column and marking it for the cipher s= uites/extensions that are described in the 1.3 document.  Other cipher= suites/extensions  can be marked as recommended through other documents.





On 11/17/15, 6:54 AM, "TLS on behalf of Sean Turner" <tls-bounces@ietf.org on behalf of sean@sn3rd.com> wrote:

>On Nov 17, 2015, at 16:40, Eric Rescorla <ekr@rtfm.com> wrote:
>>
>> > 1. The Cipher Suites "Recommended" column was popul= ated based on
>> >     the Standards Track RFCs listed in the doc= ument (and I removed the
>> >     others).
>>
>> Isn’t it just the MTI suites listed in s8.1?
>>
>> Maybe I need to go check the minutes, but I thought it was the
>> Standards Track ones, not the MTI ones that we agreed on.
>> The difference here is largely the FFDHE cipher suites and CCM. >
>From Jim’s notes in the etherpad:
>
>AOB
>SPT: Requests for additional ciphers from others.  Listing in A.4<= br> >       Suggest thinning it down to the SHOULD/MUST = list only.
>EKR: Need to encourage support for PSK variants
>EKR: Looking at the difference between the "good" list and th= e "safe" list and the "no opinion" list
>EKR: Sample case would be 448 - not a MUST/SHOULD but still think it is= good.
>
>spt

>_______________________________________________<= br> >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

 

--_000_BLUPR03MB139629A2B2EE9BCD591AA4BB8C1D0BLUPR03MB1396namp_-- From nobody Tue Nov 17 10:47: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 5CF421B3332 for ; Tue, 17 Nov 2015 10:47:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.712 X-Spam-Level: X-Spam-Status: No, score=0.712 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5KWzREB4s8Ep for ; Tue, 17 Nov 2015 10:47:47 -0800 (PST) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::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 3E2E31B3335 for ; Tue, 17 Nov 2015 10:47:47 -0800 (PST) Received: by ykdr82 with SMTP id r82so21991859ykd.3 for ; Tue, 17 Nov 2015 10:47:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=j0WmIFbi3Ncxz0RagHL4SPQBJF4gkrwfH9qFt+UaXW4=; b=su9uB8P/PT+4YrpVN0unsotB3aqEFXo+UoQRFZWsKQ6cdwbPSkINemJWiUx51C5Aj/ nuBV79M7Q9OhslkqvOIGrFcP3csvYjaNdBhH5avxqZPygeSvjWGSxI2E43AQBj3WiQAa uYgWyj37iSpHfUx7OPwk3SlfhLb2MbqU7P61hnfnkt0QEVZOH7PSPJX4TBuBXeqrkMyd bAiRcrcIHPIoOhp2PHHgcwglAgDr4BzvgDBd/YrLCzmYpk4qAN9KmApEXpH8dc/x2TBK BFOMmKEsxlybPpEDE1J0GtvBLyO0MphtSfYEXVFVEzZ1OUy2yAqR/ONbiC8hMc1gYCv0 56cg== 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=j0WmIFbi3Ncxz0RagHL4SPQBJF4gkrwfH9qFt+UaXW4=; b=YFw4lOooFqacHsjIYBfkW5jCDaY6fQ0WPJGpOJTEALX831nwEseBBuJdSJP3nfbay0 jxcdNhLuHkOxCA8BOISmpzViQjXrcn5ajybRBFgPEipt5g+n4uqPigyllmyRcGhijFPg afVuDM9pzNCap1z0S3eKsK3CrRkmqX15k4SwioUQdYfrdEeKw5qdLn7ctdsof2Kf7H9O W7GC8dTN7thLMAFeZeOHGp02VpFMfWLFHBf6WhiqTN9nsvgu6LvfYJ6eJkBNmwgaO8fw I6gM6PWIUP0zaCMnCLt0vZmr0rI7HYUhxtqABbuSrm3wEtNDFir17Z3g0vecS5FdGRFF v9ng== X-Gm-Message-State: ALoCoQkBF87HcU5nlwT7iyK+eNK0a1u6cHEIEeatDv2SdD+AiWr6IMlkpJhhYAvJ0TSXCH1UmkMn X-Received: by 10.13.212.9 with SMTP id w9mr18110524ywd.192.1447786066552; Tue, 17 Nov 2015 10:47:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.221.203 with HTTP; Tue, 17 Nov 2015 10:47:07 -0800 (PST) In-Reply-To: References: <7276DA5B-0563-4D70-A611-96A2E80CAECB@tableau.com> From: Eric Rescorla Date: Tue, 17 Nov 2015 10:47:07 -0800 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=001a114fa6383555db0524c0f6d9 Archived-At: Cc: IETF TLS Subject: Re: [TLS] PR#345: IANA Considerations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 18:47:49 -0000 --001a114fa6383555db0524c0f6d9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Here is my understanding - Recommended things are things which the IETF has reviewed and thinks are good. - Not recommended things are things which the IETF has not reviewed and may be fine but may also be bad. The intention is to break the binding between code point assignment and endorsement. -Ekr On Tue, Nov 17, 2015 at 10:36 AM, Andrei Popov wrote: > What is the intended use of the =E2=80=9CRecommended=E2=80=9D list? I.e. = how is an > implementer supposed to think about this marker? > > > > Cheers, > > > > Andrei > > > > *From:* TLS [mailto:tls-bounces@ietf.org] *On Behalf Of *Russ Housley > *Sent:* Tuesday, November 17, 2015 10:01 AM > *To:* IETF TLS > *Subject:* Re: [TLS] PR#345: IANA Considerations > > > > +1. This seems like a reasonable way forward. > > > > Russ > > > > > > On Nov 17, 2015, at 12:51 PM, Eric Rescorla wrote: > > > > There are presently four categories of cipher suites vis-a-vis TLS 1.3. > > > > 1. MUST or SHOULD cipher suites. > > 2. Standards track cipher suites (or ones we are making ST, like > > the ECC ones). > > 3. Non standards track cipher suites > > 4. Cipher suites you can't use at all with TLS 1.3, like AES-CBC. > > > > I think we're all agreed that category #1 should be marked recommended > > and that #3 and #4 should not be. This leaves us with category #2, which > > includes stuff like: > > > > - FFDHE > > - CCM > > > > My proposal is that we: > > > > - List all the Standards Track cipher suites that are compatible with TLS > 1.3 in Appendix A. > > - Mark all the cipher suites that are listed in Appendix A as "Recommende= d" > > > > -Ekr > > > > > > > > > > > > > > On Tue, Nov 17, 2015 at 8:46 AM, Joe Salowey wrote= : > > I think the TLS 1.3 IANA considerations should just deal with setting up > the recommended column and marking it for the cipher suites/extensions th= at > are described in the 1.3 document. Other cipher suites/extensions can b= e > marked as recommended through other documents. > > > > > > On 11/17/15, 6:54 AM, "TLS on behalf of Sean Turner" on behalf of sean@sn3rd.com> wrote: > > >On Nov 17, 2015, at 16:40, Eric Rescorla wrote: > >> > >> > 1. The Cipher Suites "Recommended" column was populated based on > >> > the Standards Track RFCs listed in the document (and I removed t= he > >> > others). > >> > >> Isn=E2=80=99t it just the MTI suites listed in s8.1? > >> > >> Maybe I need to go check the minutes, but I thought it was the > >> Standards Track ones, not the MTI ones that we agreed on. > >> The difference here is largely the FFDHE cipher suites and CCM. > > > >From Jim=E2=80=99s notes in the etherpad: > > > >AOB > >SPT: Requests for additional ciphers from others. Listing in A.4 > > Suggest thinning it down to the SHOULD/MUST list only. > >EKR: Need to encourage support for PSK variants > >EKR: Looking at the difference between the "good" list and the "safe" > list and the "no opinion" list > >EKR: Sample case would be 448 - not a MUST/SHOULD but still think it is > good. > > > >spt > > >_______________________________________________ > >TLS mailing list > >TLS@ietf.org > >https://www.ietf.org/mailman/listinfo/tls > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a114fa6383555db0524c0f6d9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Here is my understanding

- Recommended = things are things which the IETF has reviewed and thinks are good.
- Not recommended things are things which the IETF has not reviewed and m= ay be fine but may also be bad.

The intention is t= o break the binding between code point assignment and
endorsement= .

-Ekr


On Tue, Nov 17, 2015 at 10:36 AM, Andrei= Popov <Andrei.Popov@microsoft.com> wrote:

What is the intended use of the =E2= =80=9CRecommended=E2=80=9D list? I.e. how is an implementer supposed to thi= nk about this marker?

=C2=A0

Cheers,

=C2=A0

Andrei

=C2=A0

From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Russ Housley
Sent: Tuesday, November 17, 2015 10:01 AM
To: IETF TLS <t= ls@ietf.org>
Subject: Re: [TLS] PR#345: IANA Considerations<= /p>

=C2=A0

+1.=C2=A0 This seems like a reasonable way forward.<= u>

=C2=A0

Russ

=C2=A0

=C2=A0

On Nov 17, 2015, at 12:51 PM, Eric Rescorla wrote:



There are presently four categories of cipher suites= vis-a-vis TLS 1.3.

=C2=A0

1. MUST or SHOULD cipher suites.

2. Standards track cipher suites (or ones we are mak= ing ST, like

=C2=A0 =C2=A0 the ECC ones).

3. Non standards track cipher suites

4. Cipher suites you can't use at all with TLS 1= .3, like AES-CBC.

=C2=A0

I think we're all agreed that category #1 should= be marked recommended

and that #3 and #4 should not be. This leaves us wit= h category #2, which

includes stuff like:

=C2=A0

- FFDHE

- CCM

=C2=A0

My proposal is that we:

=C2=A0

- List all the Standards Track cipher suites that ar= e compatible with TLS 1.3 in Appendix A.

- Mark all the cipher suites that are listed in Appe= ndix A as "Recommended"

=C2=A0

-Ekr

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Tue, Nov 17, 2015 at 8:46 AM, Joe Salowey <jsalowey@tableau.com= > wrote:

I think the TLS 1.3 IANA considerations should just = deal with setting up the recommended column and marking it for the cipher s= uites/extensions that are described in the 1.3 document.=C2=A0 Other cipher= suites/extensions=C2=A0 can be marked as recommended through other documents.





On 11/17/15, 6:54 AM, "TLS on behalf of Sean Turner" <tls-bounces@ietf.org= on behalf of sean@sn3rd.com> = wrote:

>On Nov 17, 2015, at 16:40, Eric Rescorla <ekr@rtfm.com> wrote:
>>
>> > 1. The Cipher Suites "Recommended" column was popul= ated based on
>> >=C2=A0 =C2=A0 =C2=A0the Standards Track RFCs listed in the doc= ument (and I removed the
>> >=C2=A0 =C2=A0 =C2=A0others).
>>
>> Isn=E2=80=99t it just the MTI suites listed in s8.1?
>>
>> Maybe I need to go check the minutes, but I thought it was the
>> Standards Track ones, not the MTI ones that we agreed on.
>> The difference here is largely the FFDHE cipher suites and CCM. >
>From Jim=E2=80=99s notes in the etherpad:
>
>AOB
>SPT: Requests for additional ciphers from others.=C2=A0 Listing in A.4<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Suggest thinning it down to the SHOULD/MUST = list only.
>EKR: Need to encourage support for PSK variants
>EKR: Looking at the difference between the "good" list and th= e "safe" list and the "no opinion" list
>EKR: Sample case would be 448 - not a MUST/SHOULD but still think it is= good.
>
>spt

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

=C2=A0

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

=C2=A0


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


--001a114fa6383555db0524c0f6d9-- From nobody Tue Nov 17 10:56: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 2E6C91B311E for ; Tue, 17 Nov 2015 10:56:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 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, HTTPS_HTTP_MISMATCH=1.989, 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 6_5nZRSzDzci for ; Tue, 17 Nov 2015 10:56:54 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0737.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::737]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CD321B3353 for ; Tue, 17 Nov 2015 10:56:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9/tp69iESfQclOPscSe2UZTab6ZgM7TuubaD270EP+w=; b=YgPuctPq0orOCnnhJPy+uaRCeAPqFWML0JyaIHMb1qVVHlMcYp4X3CEvLkUIFP45d9v/xNE6bJTvN7xIjdjc4IAPUInRYFvrraJKxhF+xQTPIe/sIAb8aRvtUlNMfHsHbdXio/JLiylcgscJEFNDzUbN+TI5N8zueNoL1K6PpUA= Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1393.namprd03.prod.outlook.com (10.163.81.14) with Microsoft SMTP Server (TLS) id 15.1.318.15; Tue, 17 Nov 2015 18:56:34 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0318.003; Tue, 17 Nov 2015 18:56:34 +0000 From: Andrei Popov To: Eric Rescorla Thread-Topic: [TLS] PR#345: IANA Considerations Thread-Index: AQHRIMT9OVhyjmu2u0CH56orafUz4Z6fSL4AgAD1tACAAAuwAIAABB+AgAAfHYCAABJHAIAAArYAgAAI+eCAAAPZgIAAAFSQ Date: Tue, 17 Nov 2015 18:56:33 +0000 Message-ID: References: <7276DA5B-0563-4D70-A611-96A2E80CAECB@tableau.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:f::1d2] x-microsoft-exchange-diagnostics: 1; BLUPR03MB1393; 5:QwU90/VY7/fvJqRoKkEhnytHLaVLKQIrSPsUf1Lwaw6d9N2EwCVRI/Y7rCGCkKlNrvjMJhxOw9OdC9fXBfPWYXdxo41z+BACI1qfx5GuqcsWUCPACOqJQVccg9ddfTdNogil6mtN3O6E+Dg2/ww2AA==; 24:s1lq11dH672W4lyGyaq2BcIOvMYUWeNlgAGuLJjIObaKTWdybBOp2G8TmpP1w98SOh1JlWMz0kGGd9/aFbcr2lkOi7v1zesICq4JNcJkx3s=; 20:3avkvf5irfy6DFbFVTSslMpBo+RTl4qpWFAmLiMamkusgDSCtPijYp5djmlwaezlqtwzlnMN4XJe1Gw5iWXQrg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1393; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(31773223642792)(189930954265078)(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(8121501046)(520078)(5005006)(10201501046)(3002001)(61426024)(61427024); SRVR:BLUPR03MB1393; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1393; x-forefront-prvs: 07630F72AD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(479174004)(24454002)(199003)(189002)(377454003)(92566002)(74316001)(561944003)(101416001)(19625215002)(76176999)(5002640100001)(110136002)(5001960100002)(16236675004)(54356999)(189998001)(50986999)(76576001)(81156007)(97736004)(33656002)(93886004)(86362001)(15975445007)(122556002)(102836002)(2950100001)(77096005)(40100003)(19300405004)(2900100001)(19580395003)(86612001)(87936001)(19580405001)(19609705001)(5004730100002)(586003)(99286002)(5007970100001)(10090500001)(5008740100001)(5003600100002)(10290500002)(5005710100001)(11100500001)(8990500004)(10400500002)(105586002)(106116001)(106356001)(19617315012)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1393; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR03MB13968C4501A35779922149C58C1D0BLUPR03MB1396namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2015 18:56:34.0122 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1393 Archived-At: Cc: IETF TLS Subject: Re: [TLS] PR#345: IANA Considerations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 18:56:57 -0000 --_000_BLUPR03MB13968C4501A35779922149C58C1D0BLUPR03MB1396namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBpcyBhIGdvb2QgaW50ZW50aW9uLiBDYW4gd2UgdGhlbiBjaG9vc2UgYSBzdHJvbmdlciwg bW9yZSBkZWZpbml0aXZlIHRlcm0/IEUuZy4g4oCcbm9uLXN0YW5kYXJk4oCdLCDigJx2ZW5kb3It c3BlY2lmaWPigJ0sIOKAnHByaXZhdGXigJ0sIOKAnG5vdCBJRVRGLXJldmlld2Vk4oCdIG9yIHNv bWV0aGluZyBiZXR0ZXIuDQoNCkkgZmVlbCB0aGF0IOKAnHJlY29tbWVuZGVk4oCdIHdpbGwgY2hh bmdlIG92ZXIgdGltZSwgYW5kIGFsc28gdGhhdCBjaXBoZXIgc3VpdGVzIGFuZCBleHRlbnNpb25z IOKAnHJlY29tbWVuZGVk4oCdIGZvciBUTFMxLjMgYXJlIGRpZmZlcmVudCB0aGFuIHRob3NlIOKA nHJlY29tbWVuZGVk4oCdIGZvciBUTFMgMS4yLg0KDQpPbiB0aGUgb3RoZXIgaGFuZCwgc29tZXRo aW5nIHdlIG1hcmsg4oCcbm9uLXN0YW5kYXJk4oCdIG9yIOKAnHZlbmRvci1zcGVjaWZpY+KAnSBp cyBnZW5lcmFsbHkgdW5saWtlbHkgdG8gbW92ZSB0byB0aGUg4oCcc3RhbmRhcmTigJ0gY2F0ZWdv cnkuDQoNCkZyb206IEVyaWMgUmVzY29ybGEgW21haWx0bzpla3JAcnRmbS5jb21dDQpTZW50OiBU dWVzZGF5LCBOb3ZlbWJlciAxNywgMjAxNSAxMDo0NyBBTQ0KVG86IEFuZHJlaSBQb3BvdiA8QW5k cmVpLlBvcG92QG1pY3Jvc29mdC5jb20+DQpDYzogUnVzcyBIb3VzbGV5IDxob3VzbGV5QHZpZ2ls c2VjLmNvbT47IElFVEYgVExTIDx0bHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1RMU10gUFIj MzQ1OiBJQU5BIENvbnNpZGVyYXRpb25zDQoNCkhlcmUgaXMgbXkgdW5kZXJzdGFuZGluZw0KDQot IFJlY29tbWVuZGVkIHRoaW5ncyBhcmUgdGhpbmdzIHdoaWNoIHRoZSBJRVRGIGhhcyByZXZpZXdl ZCBhbmQgdGhpbmtzIGFyZSBnb29kLg0KLSBOb3QgcmVjb21tZW5kZWQgdGhpbmdzIGFyZSB0aGlu Z3Mgd2hpY2ggdGhlIElFVEYgaGFzIG5vdCByZXZpZXdlZCBhbmQgbWF5IGJlIGZpbmUgYnV0IG1h eSBhbHNvIGJlIGJhZC4NCg0KVGhlIGludGVudGlvbiBpcyB0byBicmVhayB0aGUgYmluZGluZyBi ZXR3ZWVuIGNvZGUgcG9pbnQgYXNzaWdubWVudCBhbmQNCmVuZG9yc2VtZW50Lg0KDQotRWtyDQoN Cg0KT24gVHVlLCBOb3YgMTcsIDIwMTUgYXQgMTA6MzYgQU0sIEFuZHJlaSBQb3BvdiA8QW5kcmVp LlBvcG92QG1pY3Jvc29mdC5jb208bWFpbHRvOkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPj4g d3JvdGU6DQpXaGF0IGlzIHRoZSBpbnRlbmRlZCB1c2Ugb2YgdGhlIOKAnFJlY29tbWVuZGVk4oCd IGxpc3Q/IEkuZS4gaG93IGlzIGFuIGltcGxlbWVudGVyIHN1cHBvc2VkIHRvIHRoaW5rIGFib3V0 IHRoaXMgbWFya2VyPw0KDQpDaGVlcnMsDQoNCkFuZHJlaQ0KDQpGcm9tOiBUTFMgW21haWx0bzp0 bHMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhh bGYgT2YgUnVzcyBIb3VzbGV5DQpTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAxNywgMjAxNSAxMDow MSBBTQ0KVG86IElFVEYgVExTIDx0bHNAaWV0Zi5vcmc8bWFpbHRvOnRsc0BpZXRmLm9yZz4+DQpT dWJqZWN0OiBSZTogW1RMU10gUFIjMzQ1OiBJQU5BIENvbnNpZGVyYXRpb25zDQoNCisxLiAgVGhp cyBzZWVtcyBsaWtlIGEgcmVhc29uYWJsZSB3YXkgZm9yd2FyZC4NCg0KUnVzcw0KDQoNCk9uIE5v diAxNywgMjAxNSwgYXQgMTI6NTEgUE0sIEVyaWMgUmVzY29ybGEgd3JvdGU6DQoNClRoZXJlIGFy ZSBwcmVzZW50bHkgZm91ciBjYXRlZ29yaWVzIG9mIGNpcGhlciBzdWl0ZXMgdmlzLWEtdmlzIFRM UyAxLjMuDQoNCjEuIE1VU1Qgb3IgU0hPVUxEIGNpcGhlciBzdWl0ZXMuDQoyLiBTdGFuZGFyZHMg dHJhY2sgY2lwaGVyIHN1aXRlcyAob3Igb25lcyB3ZSBhcmUgbWFraW5nIFNULCBsaWtlDQogICAg dGhlIEVDQyBvbmVzKS4NCjMuIE5vbiBzdGFuZGFyZHMgdHJhY2sgY2lwaGVyIHN1aXRlcw0KNC4g Q2lwaGVyIHN1aXRlcyB5b3UgY2FuJ3QgdXNlIGF0IGFsbCB3aXRoIFRMUyAxLjMsIGxpa2UgQUVT LUNCQy4NCg0KSSB0aGluayB3ZSdyZSBhbGwgYWdyZWVkIHRoYXQgY2F0ZWdvcnkgIzEgc2hvdWxk IGJlIG1hcmtlZCByZWNvbW1lbmRlZA0KYW5kIHRoYXQgIzMgYW5kICM0IHNob3VsZCBub3QgYmUu IFRoaXMgbGVhdmVzIHVzIHdpdGggY2F0ZWdvcnkgIzIsIHdoaWNoDQppbmNsdWRlcyBzdHVmZiBs aWtlOg0KDQotIEZGREhFDQotIENDTQ0KDQpNeSBwcm9wb3NhbCBpcyB0aGF0IHdlOg0KDQotIExp c3QgYWxsIHRoZSBTdGFuZGFyZHMgVHJhY2sgY2lwaGVyIHN1aXRlcyB0aGF0IGFyZSBjb21wYXRp YmxlIHdpdGggVExTIDEuMyBpbiBBcHBlbmRpeCBBLg0KLSBNYXJrIGFsbCB0aGUgY2lwaGVyIHN1 aXRlcyB0aGF0IGFyZSBsaXN0ZWQgaW4gQXBwZW5kaXggQSBhcyAiUmVjb21tZW5kZWQiDQoNCi1F a3INCg0KDQoNCg0KDQoNCk9uIFR1ZSwgTm92IDE3LCAyMDE1IGF0IDg6NDYgQU0sIEpvZSBTYWxv d2V5IDxqc2Fsb3dleUB0YWJsZWF1LmNvbTxtYWlsdG86anNhbG93ZXlAdGFibGVhdS5jb20+PiB3 cm90ZToNCkkgdGhpbmsgdGhlIFRMUyAxLjMgSUFOQSBjb25zaWRlcmF0aW9ucyBzaG91bGQganVz dCBkZWFsIHdpdGggc2V0dGluZyB1cCB0aGUgcmVjb21tZW5kZWQgY29sdW1uIGFuZCBtYXJraW5n IGl0IGZvciB0aGUgY2lwaGVyIHN1aXRlcy9leHRlbnNpb25zIHRoYXQgYXJlIGRlc2NyaWJlZCBp biB0aGUgMS4zIGRvY3VtZW50LiAgT3RoZXIgY2lwaGVyIHN1aXRlcy9leHRlbnNpb25zICBjYW4g YmUgbWFya2VkIGFzIHJlY29tbWVuZGVkIHRocm91Z2ggb3RoZXIgZG9jdW1lbnRzLg0KDQoNCg0K DQpPbiAxMS8xNy8xNSwgNjo1NCBBTSwgIlRMUyBvbiBiZWhhbGYgb2YgU2VhbiBUdXJuZXIiIDx0 bHMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFs ZiBvZiBzZWFuQHNuM3JkLmNvbTxtYWlsdG86c2VhbkBzbjNyZC5jb20+PiB3cm90ZToNCg0KPk9u IE5vdiAxNywgMjAxNSwgYXQgMTY6NDAsIEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbTxtYWls dG86ZWtyQHJ0Zm0uY29tPj4gd3JvdGU6DQo+Pg0KPj4gPiAxLiBUaGUgQ2lwaGVyIFN1aXRlcyAi UmVjb21tZW5kZWQiIGNvbHVtbiB3YXMgcG9wdWxhdGVkIGJhc2VkIG9uDQo+PiA+ICAgICB0aGUg U3RhbmRhcmRzIFRyYWNrIFJGQ3MgbGlzdGVkIGluIHRoZSBkb2N1bWVudCAoYW5kIEkgcmVtb3Zl ZCB0aGUNCj4+ID4gICAgIG90aGVycykuDQo+Pg0KPj4gSXNu4oCZdCBpdCBqdXN0IHRoZSBNVEkg c3VpdGVzIGxpc3RlZCBpbiBzOC4xPw0KPj4NCj4+IE1heWJlIEkgbmVlZCB0byBnbyBjaGVjayB0 aGUgbWludXRlcywgYnV0IEkgdGhvdWdodCBpdCB3YXMgdGhlDQo+PiBTdGFuZGFyZHMgVHJhY2sg b25lcywgbm90IHRoZSBNVEkgb25lcyB0aGF0IHdlIGFncmVlZCBvbi4NCj4+IFRoZSBkaWZmZXJl bmNlIGhlcmUgaXMgbGFyZ2VseSB0aGUgRkZESEUgY2lwaGVyIHN1aXRlcyBhbmQgQ0NNLg0KPg0K PkZyb20gSmlt4oCZcyBub3RlcyBpbiB0aGUgZXRoZXJwYWQ6DQo+DQo+QU9CDQo+U1BUOiBSZXF1 ZXN0cyBmb3IgYWRkaXRpb25hbCBjaXBoZXJzIGZyb20gb3RoZXJzLiAgTGlzdGluZyBpbiBBLjQN Cj4gICAgICAgU3VnZ2VzdCB0aGlubmluZyBpdCBkb3duIHRvIHRoZSBTSE9VTEQvTVVTVCBsaXN0 IG9ubHkuDQo+RUtSOiBOZWVkIHRvIGVuY291cmFnZSBzdXBwb3J0IGZvciBQU0sgdmFyaWFudHMN Cj5FS1I6IExvb2tpbmcgYXQgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgImdvb2QiIGxpc3Qg YW5kIHRoZSAic2FmZSIgbGlzdCBhbmQgdGhlICJubyBvcGluaW9uIiBsaXN0DQo+RUtSOiBTYW1w bGUgY2FzZSB3b3VsZCBiZSA0NDggLSBub3QgYSBNVVNUL1NIT1VMRCBidXQgc3RpbGwgdGhpbmsg aXQgaXMgZ29vZC4NCj4NCj5zcHQNCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPlRMUyBtYWlsaW5nIGxpc3QNCj5UTFNAaWV0Zi5vcmc8bWFpbHRvOlRM U0BpZXRmLm9yZz4NCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rsczxo dHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUz YSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZnRscyZkYXRhPTAxJTdj MDElN2NBbmRyZWkuUG9wb3YlNDBtaWNyb3NvZnQuY29tJTdjOTNiNWY3MDZkYjE4NGYwZmYyMWEw OGQyZWY3OTI4ZTMlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9 cHNYMXhVTGUxeWIlMmZmUWliakxwdlZUZ0ZhbHRuR2lNY3FlbzhTMVk5MXFFJTNkPg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVExTIG1haWxpbmcg bGlzdA0KVExTQGlldGYub3JnPG1haWx0bzpUTFNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RsczxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rp b24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4l MmZsaXN0aW5mbyUyZnRscyZkYXRhPTAxJTdjMDElN2NBbmRyZWkuUG9wb3YlNDBtaWNyb3NvZnQu Y29tJTdjOTNiNWY3MDZkYjE4NGYwZmYyMWEwOGQyZWY3OTI4ZTMlN2M3MmY5ODhiZjg2ZjE0MWFm OTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9cHNYMXhVTGUxeWIlMmZmUWliakxwdlZUZ0ZhbHRu R2lNY3FlbzhTMVk5MXFFJTNkPg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpUTFMgbWFpbGluZyBsaXN0DQpUTFNAaWV0Zi5vcmc8bWFpbHRvOlRM U0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzPGh0 dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNh JTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJmdGxzJmRhdGE9MDElN2Mw MSU3Y0FuZHJlaS5Qb3BvdiU0MG1pY3Jvc29mdC5jb20lN2NhZDFhZGE2NGNhYmM0OGJhYjMxNDA4 ZDJlZjdmOTYzZiU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT1L aUVsV3NjTVpaWUk5d0c0cUh6dlh5bmNJSkpsTTNQMzdXaFU2TDJtTkI4JTNkPg0KDQo= --_000_BLUPR03MB13968C4501A35779922149C58C1D0BLUPR03MB1396namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhpcyBpcyBhIGdvb2QgaW50ZW50aW9u LiBDYW4gd2UgdGhlbiBjaG9vc2UgYSBzdHJvbmdlciwgbW9yZSBkZWZpbml0aXZlIHRlcm0/IEUu Zy4g4oCcbm9uLXN0YW5kYXJk4oCdLCDigJx2ZW5kb3Itc3BlY2lmaWPigJ0sIOKAnHByaXZhdGXi gJ0sIOKAnG5vdCBJRVRGLXJldmlld2Vk4oCdIG9yIHNvbWV0aGluZw0KIGJldHRlci48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgZmVlbCB0aGF0IOKAnHJlY29t bWVuZGVk4oCdIHdpbGwgY2hhbmdlIG92ZXIgdGltZSwgYW5kIGFsc28gdGhhdCBjaXBoZXIgc3Vp dGVzIGFuZCBleHRlbnNpb25zIOKAnHJlY29tbWVuZGVk4oCdIGZvciBUTFMxLjMgYXJlIGRpZmZl cmVudCB0aGFuIHRob3NlIOKAnHJlY29tbWVuZGVk4oCdIGZvcg0KIFRMUyAxLjIuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5PbiB0aGUgb3RoZXIgaGFuZCwgc29t ZXRoaW5nIHdlIG1hcmsg4oCcbm9uLXN0YW5kYXJk4oCdIG9yIOKAnHZlbmRvci1zcGVjaWZpY+KA nSBpcyBnZW5lcmFsbHkgdW5saWtlbHkgdG8gbW92ZSB0byB0aGUg4oCcc3RhbmRhcmTigJ0gY2F0 ZWdvcnkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+IEVyaWMgUmVzY29ybGEgW21haWx0bzpla3JAcnRmbS5jb21dDQo8YnI+ DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgTm92ZW1iZXIgMTcsIDIwMTUgMTA6NDcgQU08YnI+DQo8 Yj5Ubzo8L2I+IEFuZHJlaSBQb3BvdiAmbHQ7QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20mZ3Q7 PGJyPg0KPGI+Q2M6PC9iPiBSdXNzIEhvdXNsZXkgJmx0O2hvdXNsZXlAdmlnaWxzZWMuY29tJmd0 OzsgSUVURiBUTFMgJmx0O3Rsc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IFtUTFNdIFBSIzM0NTogSUFOQSBDb25zaWRlcmF0aW9uczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkhlcmUgaXMgbXkgdW5kZXJzdGFuZGluZzxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBSZWNvbW1lbmRlZCB0aGluZ3MgYXJlIHRo aW5ncyB3aGljaCB0aGUgSUVURiBoYXMgcmV2aWV3ZWQgYW5kIHRoaW5rcyBhcmUgZ29vZC48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gTm90IHJl Y29tbWVuZGVkIHRoaW5ncyBhcmUgdGhpbmdzIHdoaWNoIHRoZSBJRVRGIGhhcyBub3QgcmV2aWV3 ZWQgYW5kIG1heSBiZSBmaW5lIGJ1dCBtYXkgYWxzbyBiZSBiYWQuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBpbnRlbnRpb24gaXMgdG8g YnJlYWsgdGhlIGJpbmRpbmcgYmV0d2VlbiBjb2RlIHBvaW50IGFzc2lnbm1lbnQgYW5kPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5lbmRvcnNlbWVu dC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ LUVrcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBU dWUsIE5vdiAxNywgMjAxNSBhdCAxMDozNiBBTSwgQW5kcmVpIFBvcG92ICZsdDs8YSBocmVmPSJt YWlsdG86QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5BbmRyZWku UG9wb3ZAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+V2hhdCBpcyB0aGUgaW50ZW5kZWQgdXNlIG9mIHRoZSDigJxSZWNv bW1lbmRlZOKAnSBsaXN0PyBJLmUuIGhvdyBpcyBhbiBpbXBsZW1lbnRlciBzdXBwb3NlZCB0byB0 aGluayBhYm91dA0KIHRoaXMgbWFya2VyPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPkNoZWVycyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5BbmRyZWk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiBUTFMgW21haWx0bzo8YSBocmVmPSJtYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj50bHMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhh bGYgT2YgPC9iPlJ1c3MgSG91c2xleTxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBOb3ZlbWJl ciAxNywgMjAxNSAxMDowMSBBTTxicj4NCjxiPlRvOjwvYj4gSUVURiBUTFMgJmx0OzxhIGhyZWY9 Im1haWx0bzp0bHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50bHNAaWV0Zi5vcmc8L2E+Jmd0 Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1RMU10gUFIjMzQ1OiBJQU5BIENvbnNpZGVyYXRp b25zPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+JiM0MzsxLiZuYnNwOyBUaGlzIHNlZW1zIGxpa2UgYSByZWFzb25hYmxlIHdh eSBmb3J3YXJkLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPlJ1c3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPk9uIE5vdiAxNywgMjAxNSwgYXQgMTI6NTEgUE0sIEVyaWMgUmVzY29ybGEg d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZXJlIGFyZSBw cmVzZW50bHkgZm91ciBjYXRlZ29yaWVzIG9mIGNpcGhlciBzdWl0ZXMgdmlzLWEtdmlzIFRMUyAx LjMuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MS4g TVVTVCBvciBTSE9VTEQgY2lwaGVyIHN1aXRlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Mi4gU3RhbmRhcmRzIHRyYWNrIGNpcGhlciBzdWl0 ZXMgKG9yIG9uZXMgd2UgYXJlIG1ha2luZyBTVCwgbGlrZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7IHRoZSBFQ0Mgb25l cykuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjMuIE5vbiBzdGFuZGFyZHMgdHJhY2sgY2lwaGVyIHN1aXRlczxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj40LiBDaXBoZXIgc3VpdGVzIHlvdSBj YW4ndCB1c2UgYXQgYWxsIHdpdGggVExTIDEuMywgbGlrZSBBRVMtQ0JDLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSB0aGluayB3ZSdy ZSBhbGwgYWdyZWVkIHRoYXQgY2F0ZWdvcnkgIzEgc2hvdWxkIGJlIG1hcmtlZCByZWNvbW1lbmRl ZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5h bmQgdGhhdCAjMyBhbmQgIzQgc2hvdWxkIG5vdCBiZS4gVGhpcyBsZWF2ZXMgdXMgd2l0aCBjYXRl Z29yeSAjMiwgd2hpY2g8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+aW5jbHVkZXMgc3R1ZmYgbGlrZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0gRkZESEU8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LSBDQ008bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk15IHByb3Bvc2Fs IGlzIHRoYXQgd2U6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4tIExpc3QgYWxsIHRoZSBTdGFuZGFyZHMgVHJhY2sgY2lwaGVyIHN1aXRl cyB0aGF0IGFyZSBjb21wYXRpYmxlIHdpdGggVExTIDEuMyBpbiBBcHBlbmRpeCBBLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tIE1hcmsgYWxs IHRoZSBjaXBoZXIgc3VpdGVzIHRoYXQgYXJlIGxpc3RlZCBpbiBBcHBlbmRpeCBBIGFzICZxdW90 O1JlY29tbWVuZGVkJnF1b3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4tRWtyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVHVlLCBOb3Yg MTcsIDIwMTUgYXQgODo0NiBBTSwgSm9lIFNhbG93ZXkgJmx0OzxhIGhyZWY9Im1haWx0bzpqc2Fs b3dleUB0YWJsZWF1LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmpzYWxvd2V5QHRhYmxlYXUuY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSB0aGluayB0aGUg VExTIDEuMyBJQU5BIGNvbnNpZGVyYXRpb25zIHNob3VsZCBqdXN0IGRlYWwgd2l0aCBzZXR0aW5n IHVwIHRoZSByZWNvbW1lbmRlZCBjb2x1bW4gYW5kIG1hcmtpbmcgaXQgZm9yIHRoZSBjaXBoZXIg c3VpdGVzL2V4dGVuc2lvbnMgdGhhdCBhcmUgZGVzY3JpYmVkIGluIHRoZSAxLjMgZG9jdW1lbnQu Jm5ic3A7DQogT3RoZXIgY2lwaGVyIHN1aXRlcy9leHRlbnNpb25zJm5ic3A7IGNhbiBiZSBtYXJr ZWQgYXMgcmVjb21tZW5kZWQgdGhyb3VnaCBvdGhlciBkb2N1bWVudHMuPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KPGJyPg0KPGJyPg0K PGJyPg0KT24gMTEvMTcvMTUsIDY6NTQgQU0sICZxdW90O1RMUyBvbiBiZWhhbGYgb2YgU2VhbiBU dXJuZXImcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPnRscy1ib3VuY2VzQGlldGYub3JnPC9hPiBvbiBiZWhhbGYgb2YNCjxhIGhy ZWY9Im1haWx0bzpzZWFuQHNuM3JkLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnNlYW5Ac24zcmQuY29t PC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KJmd0O09uIE5vdiAxNywgMjAxNSwgYXQgMTY6NDAs IEVyaWMgUmVzY29ybGEgJmx0OzxhIGhyZWY9Im1haWx0bzpla3JAcnRmbS5jb20iIHRhcmdldD0i X2JsYW5rIj5la3JAcnRmbS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7ICZndDsgMS4gVGhlIENpcGhlciBTdWl0ZXMgJnF1b3Q7UmVjb21tZW5kZWQmcXVvdDsg Y29sdW1uIHdhcyBwb3B1bGF0ZWQgYmFzZWQgb248YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDt0aGUgU3RhbmRhcmRzIFRyYWNrIFJGQ3MgbGlzdGVkIGluIHRoZSBkb2N1bWVu dCAoYW5kIEkgcmVtb3ZlZCB0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDtvdGhlcnMpLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSXNu4oCZdCBpdCBqdXN0IHRo ZSBNVEkgc3VpdGVzIGxpc3RlZCBpbiBzOC4xPzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg TWF5YmUgSSBuZWVkIHRvIGdvIGNoZWNrIHRoZSBtaW51dGVzLCBidXQgSSB0aG91Z2h0IGl0IHdh cyB0aGU8YnI+DQomZ3Q7Jmd0OyBTdGFuZGFyZHMgVHJhY2sgb25lcywgbm90IHRoZSBNVEkgb25l cyB0aGF0IHdlIGFncmVlZCBvbi48YnI+DQomZ3Q7Jmd0OyBUaGUgZGlmZmVyZW5jZSBoZXJlIGlz IGxhcmdlbHkgdGhlIEZGREhFIGNpcGhlciBzdWl0ZXMgYW5kIENDTS48YnI+DQomZ3Q7PGJyPg0K Jmd0O0Zyb20gSmlt4oCZcyBub3RlcyBpbiB0aGUgZXRoZXJwYWQ6PGJyPg0KJmd0Ozxicj4NCiZn dDtBT0I8YnI+DQomZ3Q7U1BUOiBSZXF1ZXN0cyBmb3IgYWRkaXRpb25hbCBjaXBoZXJzIGZyb20g b3RoZXJzLiZuYnNwOyBMaXN0aW5nIGluIEEuNDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtTdWdnZXN0IHRoaW5uaW5nIGl0IGRvd24gdG8gdGhlIFNIT1VMRC9NVVNUIGxpc3Qg b25seS48YnI+DQomZ3Q7RUtSOiBOZWVkIHRvIGVuY291cmFnZSBzdXBwb3J0IGZvciBQU0sgdmFy aWFudHM8YnI+DQomZ3Q7RUtSOiBMb29raW5nIGF0IHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhl ICZxdW90O2dvb2QmcXVvdDsgbGlzdCBhbmQgdGhlICZxdW90O3NhZmUmcXVvdDsgbGlzdCBhbmQg dGhlICZxdW90O25vIG9waW5pb24mcXVvdDsgbGlzdDxicj4NCiZndDtFS1I6IFNhbXBsZSBjYXNl IHdvdWxkIGJlIDQ0OCAtIG5vdCBhIE1VU1QvU0hPVUxEIGJ1dCBzdGlsbCB0aGluayBpdCBpcyBn b29kLjxicj4NCiZndDs8YnI+DQomZ3Q7c3B0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZndDtfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDtUTFMgbWFpbGluZyBs aXN0PGJyPg0KJmd0OzxhIGhyZWY9Im1haWx0bzpUTFNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5UTFNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OzxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlu a3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3Jn JTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJmdGxzJmFtcDtkYXRhPTAxJTdjMDElN2NBbmRyZWkuUG9w b3YlNDBtaWNyb3NvZnQuY29tJTdjOTNiNWY3MDZkYjE4NGYwZmYyMWEwOGQyZWY3OTI4ZTMlN2M3 MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPXBzWDF4VUxlMXli JTJmZlFpYmpMcHZWVGdGYWx0bkdpTWNxZW84UzFZOTFxRSUzZCIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzPC9hPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQpUTFMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlRM U0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlRMU0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVm PSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRw cyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZnRscyZhbXA7ZGF0 YT0wMSU3YzAxJTdjQW5kcmVpLlBvcG92JTQwbWljcm9zb2Z0LmNvbSU3YzkzYjVmNzA2ZGIxODRm MGZmMjFhMDhkMmVmNzkyOGUzJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2Mx JmFtcDtzZGF0YT1wc1gxeFVMZTF5YiUyZmZRaWJqTHB2VlRnRmFsdG5HaU1jcWVvOFMxWTkxcUUl M2QiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3RsczwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KVExTIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpUTFNA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5UTFNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMl M2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZ0bHMmYW1wO2RhdGE9 MDElN2MwMSU3Y0FuZHJlaS5Qb3BvdiU0MG1pY3Jvc29mdC5jb20lN2NhZDFhZGE2NGNhYmM0OGJh YjMxNDA4ZDJlZjdmOTYzZiU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZh bXA7c2RhdGE9S2lFbFdzY01aWllJOXdHNHFIenZYeW5jSUpKbE0zUDM3V2hVNkwybU5COCUzZCIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxz PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_BLUPR03MB13968C4501A35779922149C58C1D0BLUPR03MB1396namp_-- From nobody Tue Nov 17 11:01: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 E99931B336E for ; Tue, 17 Nov 2015 11:01:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.712 X-Spam-Level: X-Spam-Status: No, score=0.712 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtIvayozKWPX for ; Tue, 17 Nov 2015 11:01:38 -0800 (PST) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8573D1B336A for ; Tue, 17 Nov 2015 11:01:38 -0800 (PST) Received: by ykfs79 with SMTP id s79so22994513ykf.1 for ; Tue, 17 Nov 2015 11:01:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ByEypSRQvwydWdqRyWxw2j7uUYgcO1GKD7NAjUuWR+A=; b=zRGI5NKvna6ilKw78LtjPMRf/liryJVlJkZJ1gwPp6Q8UAsMPIJR7eSUWvxXnfUt/r ZiXoTJRd2QhRZUjCsO9zH7UHjkV7FCVRzrHk1z3q1XPYnMKstehZ2t44ga/+KhomtL0y 7ONpx7U2ryaP/qXmgSDr0octbwhUcAt+10unBwg7P6L26BMR007qqfmXdRdhC4PUHYF+ M/7k+CtBvXAptsIcOnKYwXCu8kELd7XXW/UtVsO71ldaH3kJp1utAWK5/c13++Ckmml4 +7E72400a0oI8ygc7tWpgljj+/glXyPtYq4AvdqOiyg2ZDSYm1xAY9UERWS7vBAk+3Yh 9Ysg== 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=ByEypSRQvwydWdqRyWxw2j7uUYgcO1GKD7NAjUuWR+A=; b=ABsjqI2JDdHgffblkIipS7D3dXvbPMDF8A2v6Jip8bv2MtrfwxDz4AdZoTt/Y/A64p dIXi3zUhRu/zV5dGyEBcrXrI/UEz7ye5QPtnvj4eI4ULe9/3KU6Y9+YwrvyU6N0QkpnW qQdY8kGw7j0JuVbpHQAcMipHhXUKV2kWOk/1RTywqmO9EGYBZKbmY+8OLk16RzRGkDq0 5+/c8DGoqzeijzmP6euHKh0AbDiaW7240LvvklkXVh5OnuzmNW0Y/rPcQqmUb81HHD5F JtoaVRJTIxiKZtjHUkl73v1O/F6UGwcHAiCXVbWwr2+5CUaOpaT6pa6FHHegBsQRFs4E G/zA== X-Gm-Message-State: ALoCoQnsMKhggVZK28x9seOOyUsfl2yijE433BnjNB5JvD8x5PpJ7HOUjCxpX7/kN8yBtNhnsrfi X-Received: by 10.13.212.9 with SMTP id w9mr18189885ywd.192.1447786897721; Tue, 17 Nov 2015 11:01:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.221.203 with HTTP; Tue, 17 Nov 2015 11:00:58 -0800 (PST) In-Reply-To: References: <7276DA5B-0563-4D70-A611-96A2E80CAECB@tableau.com> From: Eric Rescorla Date: Tue, 17 Nov 2015 11:00:58 -0800 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=001a114fa638bff0ca0524c127f4 Archived-At: Cc: IETF TLS Subject: Re: [TLS] PR#345: IANA Considerations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 19:01:41 -0000 --001a114fa638bff0ca0524c127f4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I would be fine with any name people want to use here :) -Ekr On Tue, Nov 17, 2015 at 10:56 AM, Andrei Popov wrote: > This is a good intention. Can we then choose a stronger, more definitive > term? E.g. =E2=80=9Cnon-standard=E2=80=9D, =E2=80=9Cvendor-specific=E2=80= =9D, =E2=80=9Cprivate=E2=80=9D, =E2=80=9Cnot > IETF-reviewed=E2=80=9D or something better. > > > > I feel that =E2=80=9Crecommended=E2=80=9D will change over time, and also= that cipher > suites and extensions =E2=80=9Crecommended=E2=80=9D for TLS1.3 are differ= ent than those > =E2=80=9Crecommended=E2=80=9D for TLS 1.2. > > > > On the other hand, something we mark =E2=80=9Cnon-standard=E2=80=9D or = =E2=80=9Cvendor-specific=E2=80=9D > is generally unlikely to move to the =E2=80=9Cstandard=E2=80=9D category. > > > > *From:* Eric Rescorla [mailto:ekr@rtfm.com] > *Sent:* Tuesday, November 17, 2015 10:47 AM > *To:* Andrei Popov > *Cc:* Russ Housley ; IETF TLS > > *Subject:* Re: [TLS] PR#345: IANA Considerations > > > > Here is my understanding > > > > - Recommended things are things which the IETF has reviewed and thinks ar= e > good. > > - Not recommended things are things which the IETF has not reviewed and > may be fine but may also be bad. > > > > The intention is to break the binding between code point assignment and > > endorsement. > > > > -Ekr > > > > > > On Tue, Nov 17, 2015 at 10:36 AM, Andrei Popov > wrote: > > What is the intended use of the =E2=80=9CRecommended=E2=80=9D list? I.e. = how is an > implementer supposed to think about this marker? > > > > Cheers, > > > > Andrei > > > > *From:* TLS [mailto:tls-bounces@ietf.org] *On Behalf Of *Russ Housley > *Sent:* Tuesday, November 17, 2015 10:01 AM > *To:* IETF TLS > *Subject:* Re: [TLS] PR#345: IANA Considerations > > > > +1. This seems like a reasonable way forward. > > > > Russ > > > > > > On Nov 17, 2015, at 12:51 PM, Eric Rescorla wrote: > > > > There are presently four categories of cipher suites vis-a-vis TLS 1.3. > > > > 1. MUST or SHOULD cipher suites. > > 2. Standards track cipher suites (or ones we are making ST, like > > the ECC ones). > > 3. Non standards track cipher suites > > 4. Cipher suites you can't use at all with TLS 1.3, like AES-CBC. > > > > I think we're all agreed that category #1 should be marked recommended > > and that #3 and #4 should not be. This leaves us with category #2, which > > includes stuff like: > > > > - FFDHE > > - CCM > > > > My proposal is that we: > > > > - List all the Standards Track cipher suites that are compatible with TLS > 1.3 in Appendix A. > > - Mark all the cipher suites that are listed in Appendix A as "Recommende= d" > > > > -Ekr > > > > > > > > > > > > > > On Tue, Nov 17, 2015 at 8:46 AM, Joe Salowey wrote= : > > I think the TLS 1.3 IANA considerations should just deal with setting up > the recommended column and marking it for the cipher suites/extensions th= at > are described in the 1.3 document. Other cipher suites/extensions can b= e > marked as recommended through other documents. > > > > > > On 11/17/15, 6:54 AM, "TLS on behalf of Sean Turner" on behalf of sean@sn3rd.com> wrote: > > >On Nov 17, 2015, at 16:40, Eric Rescorla wrote: > >> > >> > 1. The Cipher Suites "Recommended" column was populated based on > >> > the Standards Track RFCs listed in the document (and I removed t= he > >> > others). > >> > >> Isn=E2=80=99t it just the MTI suites listed in s8.1? > >> > >> Maybe I need to go check the minutes, but I thought it was the > >> Standards Track ones, not the MTI ones that we agreed on. > >> The difference here is largely the FFDHE cipher suites and CCM. > > > >From Jim=E2=80=99s notes in the etherpad: > > > >AOB > >SPT: Requests for additional ciphers from others. Listing in A.4 > > Suggest thinning it down to the SHOULD/MUST list only. > >EKR: Need to encourage support for PSK variants > >EKR: Looking at the difference between the "good" list and the "safe" > list and the "no opinion" list > >EKR: Sample case would be 448 - not a MUST/SHOULD but still think it is > good. > > > >spt > > >_______________________________________________ > >TLS mailing list > >TLS@ietf.org > >https://www.ietf.org/mailman/listinfo/tls > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > > --001a114fa638bff0ca0524c127f4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I wo= uld be fine with any name people want to use here :)

-Ekr

On Tue, Nov 17, 2015 at 10:56= AM, Andrei Popov <Andrei.Popov@microsoft.com> wrot= e:

This is a good intention. Can we then= choose a stronger, more definitive term? E.g. =E2=80=9Cnon-standard=E2=80= =9D, =E2=80=9Cvendor-specific=E2=80=9D, =E2=80=9Cprivate=E2=80=9D, =E2=80= =9Cnot IETF-reviewed=E2=80=9D or something better.

=C2=A0

I feel that =E2=80=9Crecommended=E2= =80=9D will change over time, and also that cipher suites and extensions = =E2=80=9Crecommended=E2=80=9D for TLS1.3 are different than those =E2=80=9C= recommended=E2=80=9D for TLS 1.2.

=C2=A0

On the other hand, something we mark = =E2=80=9Cnon-standard=E2=80=9D or =E2=80=9Cvendor-specific=E2=80=9D is gene= rally unlikely to move to the =E2=80=9Cstandard=E2=80=9D category.

=C2=A0

From: Eric Rescorla [mailto:ekr@rtfm.com]
Sent: Tuesday, November 17, 2015 10:47 AM
To: Andrei Popov <Andrei.Popov@microsoft.com>
Cc: Russ Housley <housley@vigilsec.com>; IETF TLS <tls@ietf.org>


Subject: Re: [TLS] PR#345: IANA Considerations

=C2=A0

Here is my understanding

=C2=A0

- Recommended things are things which the IETF has r= eviewed and thinks are good.

- Not recommended things are things which the IETF h= as not reviewed and may be fine but may also be bad.

=C2=A0

The intention is to break the binding between code p= oint assignment and

endorsement.

=C2=A0

-Ekr

=C2=A0

=C2=A0

On Tue, Nov 17, 2015 at 10:36 AM, Andrei Popov <<= a href=3D"mailto:Andrei.Popov@microsoft.com" target=3D"_blank">Andrei.Popov= @microsoft.com> wrote:

What is the intended use of the =E2= =80=9CRecommended=E2=80=9D list? I.e. how is an implementer supposed to thi= nk about this marker?

=C2=A0

Cheers,

=C2=A0

Andrei

=C2=A0

From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Russ Housley
Sent: Tuesday, November 17, 2015 10:01 AM
To: IETF TLS <t= ls@ietf.org>
Subject: Re: [TLS] PR#345: IANA Considerations<= /p>

=C2=A0

+1.=C2=A0 This seems like a reasonable way forward.<= u>

=C2=A0

Russ

=C2=A0

=C2=A0

On Nov 17, 2015, at 12:51 PM, Eric Rescorla wrote:

=C2=A0<= /p>

There are presently four categories of cipher suites= vis-a-vis TLS 1.3.

=C2=A0

1. MUST or SHOULD cipher suites.

2. Standards track cipher suites (or ones we are mak= ing ST, like

=C2=A0 =C2=A0 the ECC ones).

3. Non standards track cipher suites

4. Cipher suites you can't use at all with TLS 1= .3, like AES-CBC.

=C2=A0

I think we're all agreed that category #1 should= be marked recommended

and that #3 and #4 should not be. This leaves us wit= h category #2, which

includes stuff like:

=C2=A0

- FFDHE

- CCM

=C2=A0

My proposal is that we:

=C2=A0

- List all the Standards Track cipher suites that ar= e compatible with TLS 1.3 in Appendix A.

- Mark all the cipher suites that are listed in Appe= ndix A as "Recommended"

=C2=A0

-Ekr

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Tue, Nov 17, 2015 at 8:46 AM, Joe Salowey <jsalowey@tableau.com= > wrote:

I think the TLS 1.3 IANA considerations should just = deal with setting up the recommended column and marking it for the cipher s= uites/extensions that are described in the 1.3 document.=C2=A0 Other cipher suites/extensions=C2=A0 can be marked as recommended through = other documents.





On 11/17/15, 6:54 AM, "TLS on behalf of Sean Turner" <tls-bounces@ietf.org= on behalf of sean@sn3rd.com> = wrote:

>On Nov 17, 2015, at 16:40, Eric Rescorla <ekr@rtfm.com> wrote:
>>
>> > 1. The Cipher Suites "Recommended" column was popul= ated based on
>> >=C2=A0 =C2=A0 =C2=A0the Standards Track RFCs listed in the doc= ument (and I removed the
>> >=C2=A0 =C2=A0 =C2=A0others).
>>
>> Isn=E2=80=99t it just the MTI suites listed in s8.1?
>>
>> Maybe I need to go check the minutes, but I thought it was the
>> Standards Track ones, not the MTI ones that we agreed on.
>> The difference here is largely the FFDHE cipher suites and CCM. >
>From Jim=E2=80=99s notes in the etherpad:
>
>AOB
>SPT: Requests for additional ciphers from others.=C2=A0 Listing in A.4<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Suggest thinning it down to the SHOULD/MUST = list only.
>EKR: Need to encourage support for PSK variants
>EKR: Looking at the difference between the "good" list and th= e "safe" list and the "no opinion" list
>EKR: Sample case would be 448 - not a MUST/SHOULD but still think it is= good.
>
>spt

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

=C2=A0

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

=C2=A0


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

=C2=A0


--001a114fa638bff0ca0524c127f4-- From nobody Tue Nov 17 11:06:56 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAF701B3385 for ; Tue, 17 Nov 2015 11:06:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_22=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYzDkECJCX75 for ; Tue, 17 Nov 2015 11:06:53 -0800 (PST) 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 C236F1B3384 for ; Tue, 17 Nov 2015 11:06:53 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 47C80284D23; Tue, 17 Nov 2015 19:06:52 +0000 (UTC) Date: Tue, 17 Nov 2015 19:06:52 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20151117190651.GJ18315@mournblade.imrryr.org> References: <7276DA5B-0563-4D70-A611-96A2E80CAECB@tableau.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] PR#345: IANA Considerations 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 Nov 2015 19:06:55 -0000 On Tue, Nov 17, 2015 at 09:51:32AM -0800, Eric Rescorla wrote: > My proposal is that we: > > - List all the Standards Track cipher suites that are compatible with TLS > 1.3 in Appendix A. > > - Mark all the cipher suites that are listed in Appendix A as "Recommended" Where does that leave ciphersuites that are "Recommended" for TLS 1.2, but TLS 1.3? Or do none of the CBC block ciphers in TLS 1.2 qualify? Suites like (please pardon the OpenSSL-specific naming): ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA384 ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384 DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256 ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA256 ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256 DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256 I'd have thought these would still qualify as recommended (for TLS 1.2). And then "not recommended" would cover more exotic/obsolete codepoints. -- Viktor. From nobody Tue Nov 17 11: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 B9CD21B338E for ; Tue, 17 Nov 2015 11:12:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 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, HTTPS_HTTP_MISMATCH=1.989, 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 2PXIsPZV6o5Q for ; Tue, 17 Nov 2015 11:12:09 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0769.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::769]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 884941B338D for ; Tue, 17 Nov 2015 11:12:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=r/gIjKoyJz3wXgdJwW5B7VhlDFBIASQlBOAO1aXjxmU=; b=AhCem1drjgTVOF//jMXMkbvjE3ZZTA+1sQYsRTHr15IGWPP2B+cocN838tCq7NrKq/asVULTXIYAZleWpRNKw2eCIQtkO/kYM6IDeBjVKjTNp8cvGIG7wgC6YJ0f5TggPhMukGZwCpCdnyHby/v/HeYwddzsSt54Bv47znIUmzM= Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) with Microsoft SMTP Server (TLS) id 15.1.318.15; Tue, 17 Nov 2015 19:11:46 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0318.003; Tue, 17 Nov 2015 19:11:46 +0000 From: Andrei Popov To: Eric Rescorla Thread-Topic: [TLS] PR#345: IANA Considerations Thread-Index: AQHRIMT9OVhyjmu2u0CH56orafUz4Z6fSL4AgAD1tACAAAuwAIAABB+AgAAfHYCAABJHAIAAArYAgAAI+eCAAAPZgIAAAFSQgAADiwCAAAHQoA== Date: Tue, 17 Nov 2015 19:11:46 +0000 Message-ID: References: <7276DA5B-0563-4D70-A611-96A2E80CAECB@tableau.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:f::1d2] x-microsoft-exchange-diagnostics: 1; BLUPR03MB1396; 5:AzF85ySyHLQdBpX9fHMNDCCIw/NGmaY4vbDPhTDvg83/TQwioiIYLZaU+3YcqZmrx4nNW1NVxyPJSWpeopR206tND+F3p0vVENOfclW2NeVR+jMSptd9X+JHuB6CaQw63FvQDhmh4Z8hIadhCnVFQw==; 24:GnlQ7rQKu0BsxrAysvwcchS3ozQLdjt84abljqOIrmzgzsfZDQFxF1ecVHconK2DRKE5kHM7SMfvVGsbgI6URdDR1rhIwLZLx3hC+txRuQk=; 20:uEDE6VtQya2Zxs5EYDUYt3XTM5fMVqd1M+BBucaDF/7+ta8/ugICTuUbooO12nCw2LePn6+4fVdAH87aLFZ8Hw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1396; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(31773223642792)(189930954265078)(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(520078)(8121501046)(5005006)(3002001)(10201501046)(61426024)(61427024); SRVR:BLUPR03MB1396; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1396; x-forefront-prvs: 07630F72AD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(24454002)(479174004)(199003)(189002)(99286002)(77096005)(54356999)(19609705001)(40100003)(8990500004)(76176999)(5005710100001)(87936001)(105586002)(106356001)(10400500002)(10290500002)(5002640100001)(50986999)(92566002)(5003600100002)(189998001)(19625215002)(2950100001)(101416001)(76576001)(33656002)(16236675004)(102836002)(122556002)(2900100001)(19617315012)(15975445007)(10090500001)(561944003)(93886004)(5001920100001)(5001960100002)(110136002)(81156007)(97736004)(106116001)(5004730100002)(11100500001)(5007970100001)(86362001)(5008740100001)(74316001)(86612001)(19580405001)(19580395003)(19300405004)(586003)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1396; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR03MB13967E5ECD3CCC3F25BB479B8C1D0BLUPR03MB1396namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2015 19:11:46.6162 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1396 Archived-At: Cc: IETF TLS Subject: Re: [TLS] PR#345: IANA Considerations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 19:12:14 -0000 --_000_BLUPR03MB13967E5ECD3CCC3F25BB479B8C1D0BLUPR03MB1396namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBwZXJzb25hbGx5IGZhdm9yIHRoZSBCLW5hbWUgeW91IHVzZWQgYXQgdGhlIG1lZXRpbmcsIGJ1 dCBJQU5BIG1pZ2h0IGhhdmUgYSBwcm9ibGVtIHdpdGggaXTimLouDQoNCmlmIHRoZSBkaXN0aW5j dGlvbiBpcyB0aGF0IGNlcnRhaW4gY29kZSBwb2ludHMgYXJlIGFzc2lnbmVkIHRvIFRMUyBmZWF0 dXJlcyB0aGF0IGFyZSBub3QgSUVURi1yZXZpZXdlZCBvciBlbmRvcnNlZCwgZm9yIGNvbGxpc2lv biBhdm9pZGFuY2Ugb25seSwgSSB0aGluayB0aGUgbWFya2VyIG5hbWUgc2hvdWxkIHNwZWNpZmlj YWxseSBzYXkgc28uDQoNCkZyb206IEVyaWMgUmVzY29ybGEgW21haWx0bzpla3JAcnRmbS5jb21d DQpTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAxNywgMjAxNSAxMTowMSBBTQ0KVG86IEFuZHJlaSBQ b3BvdiA8QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20+DQpDYzogUnVzcyBIb3VzbGV5IDxob3Vz bGV5QHZpZ2lsc2VjLmNvbT47IElFVEYgVExTIDx0bHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTog W1RMU10gUFIjMzQ1OiBJQU5BIENvbnNpZGVyYXRpb25zDQoNCkkgd291bGQgYmUgZmluZSB3aXRo IGFueSBuYW1lIHBlb3BsZSB3YW50IHRvIHVzZSBoZXJlIDopDQoNCi1Fa3INCg0KT24gVHVlLCBO b3YgMTcsIDIwMTUgYXQgMTA6NTYgQU0sIEFuZHJlaSBQb3BvdiA8QW5kcmVpLlBvcG92QG1pY3Jv c29mdC5jb208bWFpbHRvOkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpUaGlz IGlzIGEgZ29vZCBpbnRlbnRpb24uIENhbiB3ZSB0aGVuIGNob29zZSBhIHN0cm9uZ2VyLCBtb3Jl IGRlZmluaXRpdmUgdGVybT8gRS5nLiDigJxub24tc3RhbmRhcmTigJ0sIOKAnHZlbmRvci1zcGVj aWZpY+KAnSwg4oCccHJpdmF0ZeKAnSwg4oCcbm90IElFVEYtcmV2aWV3ZWTigJ0gb3Igc29tZXRo aW5nIGJldHRlci4NCg0KSSBmZWVsIHRoYXQg4oCccmVjb21tZW5kZWTigJ0gd2lsbCBjaGFuZ2Ug b3ZlciB0aW1lLCBhbmQgYWxzbyB0aGF0IGNpcGhlciBzdWl0ZXMgYW5kIGV4dGVuc2lvbnMg4oCc cmVjb21tZW5kZWTigJ0gZm9yIFRMUzEuMyBhcmUgZGlmZmVyZW50IHRoYW4gdGhvc2Ug4oCccmVj b21tZW5kZWTigJ0gZm9yIFRMUyAxLjIuDQoNCk9uIHRoZSBvdGhlciBoYW5kLCBzb21ldGhpbmcg d2UgbWFyayDigJxub24tc3RhbmRhcmTigJ0gb3Ig4oCcdmVuZG9yLXNwZWNpZmlj4oCdIGlzIGdl bmVyYWxseSB1bmxpa2VseSB0byBtb3ZlIHRvIHRoZSDigJxzdGFuZGFyZOKAnSBjYXRlZ29yeS4N Cg0KRnJvbTogRXJpYyBSZXNjb3JsYSBbbWFpbHRvOmVrckBydGZtLmNvbTxtYWlsdG86ZWtyQHJ0 Zm0uY29tPl0NClNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDE3LCAyMDE1IDEwOjQ3IEFNDQpUbzog QW5kcmVpIFBvcG92IDxBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbTxtYWlsdG86QW5kcmVpLlBv cG92QG1pY3Jvc29mdC5jb20+Pg0KQ2M6IFJ1c3MgSG91c2xleSA8aG91c2xleUB2aWdpbHNlYy5j b208bWFpbHRvOmhvdXNsZXlAdmlnaWxzZWMuY29tPj47IElFVEYgVExTIDx0bHNAaWV0Zi5vcmc8 bWFpbHRvOnRsc0BpZXRmLm9yZz4+DQoNClN1YmplY3Q6IFJlOiBbVExTXSBQUiMzNDU6IElBTkEg Q29uc2lkZXJhdGlvbnMNCg0KSGVyZSBpcyBteSB1bmRlcnN0YW5kaW5nDQoNCi0gUmVjb21tZW5k ZWQgdGhpbmdzIGFyZSB0aGluZ3Mgd2hpY2ggdGhlIElFVEYgaGFzIHJldmlld2VkIGFuZCB0aGlu a3MgYXJlIGdvb2QuDQotIE5vdCByZWNvbW1lbmRlZCB0aGluZ3MgYXJlIHRoaW5ncyB3aGljaCB0 aGUgSUVURiBoYXMgbm90IHJldmlld2VkIGFuZCBtYXkgYmUgZmluZSBidXQgbWF5IGFsc28gYmUg YmFkLg0KDQpUaGUgaW50ZW50aW9uIGlzIHRvIGJyZWFrIHRoZSBiaW5kaW5nIGJldHdlZW4gY29k ZSBwb2ludCBhc3NpZ25tZW50IGFuZA0KZW5kb3JzZW1lbnQuDQoNCi1Fa3INCg0KDQpPbiBUdWUs IE5vdiAxNywgMjAxNSBhdCAxMDozNiBBTSwgQW5kcmVpIFBvcG92IDxBbmRyZWkuUG9wb3ZAbWlj cm9zb2Z0LmNvbTxtYWlsdG86QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCldo YXQgaXMgdGhlIGludGVuZGVkIHVzZSBvZiB0aGUg4oCcUmVjb21tZW5kZWTigJ0gbGlzdD8gSS5l LiBob3cgaXMgYW4gaW1wbGVtZW50ZXIgc3VwcG9zZWQgdG8gdGhpbmsgYWJvdXQgdGhpcyBtYXJr ZXI/DQoNCkNoZWVycywNCg0KQW5kcmVpDQoNCkZyb206IFRMUyBbbWFpbHRvOnRscy1ib3VuY2Vz QGlldGYub3JnPG1haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBSdXNz IEhvdXNsZXkNClNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDE3LCAyMDE1IDEwOjAxIEFNDQpUbzog SUVURiBUTFMgPHRsc0BpZXRmLm9yZzxtYWlsdG86dGxzQGlldGYub3JnPj4NClN1YmplY3Q6IFJl OiBbVExTXSBQUiMzNDU6IElBTkEgQ29uc2lkZXJhdGlvbnMNCg0KKzEuICBUaGlzIHNlZW1zIGxp a2UgYSByZWFzb25hYmxlIHdheSBmb3J3YXJkLg0KDQpSdXNzDQoNCg0KT24gTm92IDE3LCAyMDE1 LCBhdCAxMjo1MSBQTSwgRXJpYyBSZXNjb3JsYSB3cm90ZToNCg0KVGhlcmUgYXJlIHByZXNlbnRs eSBmb3VyIGNhdGVnb3JpZXMgb2YgY2lwaGVyIHN1aXRlcyB2aXMtYS12aXMgVExTIDEuMy4NCg0K MS4gTVVTVCBvciBTSE9VTEQgY2lwaGVyIHN1aXRlcy4NCjIuIFN0YW5kYXJkcyB0cmFjayBjaXBo ZXIgc3VpdGVzIChvciBvbmVzIHdlIGFyZSBtYWtpbmcgU1QsIGxpa2UNCiAgICB0aGUgRUNDIG9u ZXMpLg0KMy4gTm9uIHN0YW5kYXJkcyB0cmFjayBjaXBoZXIgc3VpdGVzDQo0LiBDaXBoZXIgc3Vp dGVzIHlvdSBjYW4ndCB1c2UgYXQgYWxsIHdpdGggVExTIDEuMywgbGlrZSBBRVMtQ0JDLg0KDQpJ IHRoaW5rIHdlJ3JlIGFsbCBhZ3JlZWQgdGhhdCBjYXRlZ29yeSAjMSBzaG91bGQgYmUgbWFya2Vk IHJlY29tbWVuZGVkDQphbmQgdGhhdCAjMyBhbmQgIzQgc2hvdWxkIG5vdCBiZS4gVGhpcyBsZWF2 ZXMgdXMgd2l0aCBjYXRlZ29yeSAjMiwgd2hpY2gNCmluY2x1ZGVzIHN0dWZmIGxpa2U6DQoNCi0g RkZESEUNCi0gQ0NNDQoNCk15IHByb3Bvc2FsIGlzIHRoYXQgd2U6DQoNCi0gTGlzdCBhbGwgdGhl IFN0YW5kYXJkcyBUcmFjayBjaXBoZXIgc3VpdGVzIHRoYXQgYXJlIGNvbXBhdGlibGUgd2l0aCBU TFMgMS4zIGluIEFwcGVuZGl4IEEuDQotIE1hcmsgYWxsIHRoZSBjaXBoZXIgc3VpdGVzIHRoYXQg YXJlIGxpc3RlZCBpbiBBcHBlbmRpeCBBIGFzICJSZWNvbW1lbmRlZCINCg0KLUVrcg0KDQoNCg0K DQoNCg0KT24gVHVlLCBOb3YgMTcsIDIwMTUgYXQgODo0NiBBTSwgSm9lIFNhbG93ZXkgPGpzYWxv d2V5QHRhYmxlYXUuY29tPG1haWx0bzpqc2Fsb3dleUB0YWJsZWF1LmNvbT4+IHdyb3RlOg0KSSB0 aGluayB0aGUgVExTIDEuMyBJQU5BIGNvbnNpZGVyYXRpb25zIHNob3VsZCBqdXN0IGRlYWwgd2l0 aCBzZXR0aW5nIHVwIHRoZSByZWNvbW1lbmRlZCBjb2x1bW4gYW5kIG1hcmtpbmcgaXQgZm9yIHRo ZSBjaXBoZXIgc3VpdGVzL2V4dGVuc2lvbnMgdGhhdCBhcmUgZGVzY3JpYmVkIGluIHRoZSAxLjMg ZG9jdW1lbnQuICBPdGhlciBjaXBoZXIgc3VpdGVzL2V4dGVuc2lvbnMgIGNhbiBiZSBtYXJrZWQg YXMgcmVjb21tZW5kZWQgdGhyb3VnaCBvdGhlciBkb2N1bWVudHMuDQoNCg0KDQoNCk9uIDExLzE3 LzE1LCA2OjU0IEFNLCAiVExTIG9uIGJlaGFsZiBvZiBTZWFuIFR1cm5lciIgPHRscy1ib3VuY2Vz QGlldGYub3JnPG1haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIHNlYW5A c24zcmQuY29tPG1haWx0bzpzZWFuQHNuM3JkLmNvbT4+IHdyb3RlOg0KDQo+T24gTm92IDE3LCAy MDE1LCBhdCAxNjo0MCwgRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPG1haWx0bzpla3JAcnRm bS5jb20+PiB3cm90ZToNCj4+DQo+PiA+IDEuIFRoZSBDaXBoZXIgU3VpdGVzICJSZWNvbW1lbmRl ZCIgY29sdW1uIHdhcyBwb3B1bGF0ZWQgYmFzZWQgb24NCj4+ID4gICAgIHRoZSBTdGFuZGFyZHMg VHJhY2sgUkZDcyBsaXN0ZWQgaW4gdGhlIGRvY3VtZW50IChhbmQgSSByZW1vdmVkIHRoZQ0KPj4g PiAgICAgb3RoZXJzKS4NCj4+DQo+PiBJc27igJl0IGl0IGp1c3QgdGhlIE1USSBzdWl0ZXMgbGlz dGVkIGluIHM4LjE/DQo+Pg0KPj4gTWF5YmUgSSBuZWVkIHRvIGdvIGNoZWNrIHRoZSBtaW51dGVz LCBidXQgSSB0aG91Z2h0IGl0IHdhcyB0aGUNCj4+IFN0YW5kYXJkcyBUcmFjayBvbmVzLCBub3Qg dGhlIE1USSBvbmVzIHRoYXQgd2UgYWdyZWVkIG9uLg0KPj4gVGhlIGRpZmZlcmVuY2UgaGVyZSBp cyBsYXJnZWx5IHRoZSBGRkRIRSBjaXBoZXIgc3VpdGVzIGFuZCBDQ00uDQo+DQo+RnJvbSBKaW3i gJlzIG5vdGVzIGluIHRoZSBldGhlcnBhZDoNCj4NCj5BT0INCj5TUFQ6IFJlcXVlc3RzIGZvciBh ZGRpdGlvbmFsIGNpcGhlcnMgZnJvbSBvdGhlcnMuICBMaXN0aW5nIGluIEEuNA0KPiAgICAgICBT dWdnZXN0IHRoaW5uaW5nIGl0IGRvd24gdG8gdGhlIFNIT1VMRC9NVVNUIGxpc3Qgb25seS4NCj5F S1I6IE5lZWQgdG8gZW5jb3VyYWdlIHN1cHBvcnQgZm9yIFBTSyB2YXJpYW50cw0KPkVLUjogTG9v a2luZyBhdCB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSAiZ29vZCIgbGlzdCBhbmQgdGhlICJz YWZlIiBsaXN0IGFuZCB0aGUgIm5vIG9waW5pb24iIGxpc3QNCj5FS1I6IFNhbXBsZSBjYXNlIHdv dWxkIGJlIDQ0OCAtIG5vdCBhIE1VU1QvU0hPVUxEIGJ1dCBzdGlsbCB0aGluayBpdCBpcyBnb29k Lg0KPg0KPnNwdA0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+VExTIG1haWxpbmcgbGlzdA0KPlRMU0BpZXRmLm9yZzxtYWlsdG86VExTQGlldGYub3Jn Pg0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzPGh0dHBzOi8vbmEw MS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3 LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJmdGxzJmRhdGE9MDElN2MwMSU3Y0FuZHJl aS5Qb3BvdiU0MG1pY3Jvc29mdC5jb20lN2M5M2I1ZjcwNmRiMTg0ZjBmZjIxYTA4ZDJlZjc5Mjhl MyU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT1wc1gxeFVMZTF5 YiUyZmZRaWJqTHB2VlRnRmFsdG5HaU1jcWVvOFMxWTkxcUUlM2Q+DQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUTFMgbWFpbGluZyBsaXN0DQpUTFNA aWV0Zi5vcmc8bWFpbHRvOlRMU0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vdGxzPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29r LmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZv JTJmdGxzJmRhdGE9MDElN2MwMSU3Y0FuZHJlaS5Qb3BvdiU0MG1pY3Jvc29mdC5jb20lN2M5M2I1 ZjcwNmRiMTg0ZjBmZjIxYTA4ZDJlZjc5MjhlMyU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2Qw MTFkYjQ3JTdjMSZzZGF0YT1wc1gxeFVMZTF5YiUyZmZRaWJqTHB2VlRnRmFsdG5HaU1jcWVvOFMx WTkxcUUlM2Q+DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NClRMUyBtYWlsaW5nIGxpc3QNClRMU0BpZXRmLm9yZzxtYWlsdG86VExTQGlldGYub3Jn Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHM8aHR0cHM6Ly9uYTAx LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cu aWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZ0bHMmZGF0YT0wMSU3YzAxJTdjQW5kcmVp LlBvcG92JTQwbWljcm9zb2Z0LmNvbSU3Y2FkMWFkYTY0Y2FiYzQ4YmFiMzE0MDhkMmVmN2Y5NjNm JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPUtpRWxXc2NNWlpZ STl3RzRxSHp2WHluY0lKSmxNM1AzN1doVTZMMm1OQjglM2Q+DQoNCg0K --_000_BLUPR03MB13967E5ECD3CCC3F25BB479B8C1D0BLUPR03MB1396namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs c2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXtt c28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFy Z2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVm dDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu IixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdE O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPkkgcGVyc29uYWxseSBmYXZvciB0aGUgQi1uYW1lIHlvdSB1c2VkIGF0IHRoZSBtZWV0aW5n LCBidXQgSUFOQSBtaWdodCBoYXZlIGEgcHJvYmxlbSB3aXRoIGl0PC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj5K PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5pZiB0aGUgZGlzdGluY3Rpb24gaXMgdGhhdCBjZXJ0 YWluIGNvZGUgcG9pbnRzIGFyZSBhc3NpZ25lZCB0byBUTFMgZmVhdHVyZXMgdGhhdCBhcmUgbm90 IElFVEYtcmV2aWV3ZWQgb3IgZW5kb3JzZWQsIGZvciBjb2xsaXNpb24gYXZvaWRhbmNlIG9ubHks IEkgdGhpbmsgdGhlDQogbWFya2VyIG5hbWUgc2hvdWxkIHNwZWNpZmljYWxseSBzYXkgc28uPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+IEVyaWMgUmVzY29ybGEgW21haWx0bzpla3JAcnRmbS5jb21dDQo8YnI+DQo8Yj5TZW50 OjwvYj4gVHVlc2RheSwgTm92ZW1iZXIgMTcsIDIwMTUgMTE6MDEgQU08YnI+DQo8Yj5Ubzo8L2I+ IEFuZHJlaSBQb3BvdiAmbHQ7QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20mZ3Q7PGJyPg0KPGI+ Q2M6PC9iPiBSdXNzIEhvdXNsZXkgJmx0O2hvdXNsZXlAdmlnaWxzZWMuY29tJmd0OzsgSUVURiBU TFMgJmx0O3Rsc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtUTFNdIFBS IzM0NTogSUFOQSBDb25zaWRlcmF0aW9uczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3b3VsZCBiZSBmaW5lIHdpdGggYW55IG5hbWUgcGVvcGxl IHdhbnQgdG8gdXNlIGhlcmUgOik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+LUVrcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIE5vdiAxNywgMjAxNSBhdCAxMDo1NiBBTSwgQW5k cmVpIFBvcG92ICZsdDs8YSBocmVmPSJtYWlsdG86QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20i IHRhcmdldD0iX2JsYW5rIj5BbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhpcyBpcyBhIGdvb2Qg aW50ZW50aW9uLiBDYW4gd2UgdGhlbiBjaG9vc2UgYSBzdHJvbmdlciwgbW9yZSBkZWZpbml0aXZl IHRlcm0/IEUuZy4g4oCcbm9uLXN0YW5kYXJk4oCdLA0KIOKAnHZlbmRvci1zcGVjaWZpY+KAnSwg 4oCccHJpdmF0ZeKAnSwg4oCcbm90IElFVEYtcmV2aWV3ZWTigJ0gb3Igc29tZXRoaW5nIGJldHRl ci48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIGZlZWwg dGhhdCDigJxyZWNvbW1lbmRlZOKAnSB3aWxsIGNoYW5nZSBvdmVyIHRpbWUsIGFuZCBhbHNvIHRo YXQgY2lwaGVyIHN1aXRlcyBhbmQgZXh0ZW5zaW9ucyDigJxyZWNvbW1lbmRlZOKAnQ0KIGZvciBU TFMxLjMgYXJlIGRpZmZlcmVudCB0aGFuIHRob3NlIOKAnHJlY29tbWVuZGVk4oCdIGZvciBUTFMg MS4yLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk9uIHRo ZSBvdGhlciBoYW5kLCBzb21ldGhpbmcgd2UgbWFyayDigJxub24tc3RhbmRhcmTigJ0gb3Ig4oCc dmVuZG9yLXNwZWNpZmlj4oCdIGlzIGdlbmVyYWxseSB1bmxpa2VseSB0byBtb3ZlDQogdG8gdGhl IOKAnHN0YW5kYXJk4oCdIGNhdGVnb3J5Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gRXJpYyBSZXNjb3JsYSBbbWFp bHRvOjxhIGhyZWY9Im1haWx0bzpla3JAcnRmbS5jb20iIHRhcmdldD0iX2JsYW5rIj5la3JAcnRm bS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIE5vdmVtYmVyIDE3LCAyMDE1 IDEwOjQ3IEFNPGJyPg0KPGI+VG86PC9iPiBBbmRyZWkgUG9wb3YgJmx0OzxhIGhyZWY9Im1haWx0 bzpBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkFuZHJlaS5Qb3Bv dkBtaWNyb3NvZnQuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IFJ1c3MgSG91c2xleSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmhvdXNsZXlAdmlnaWxzZWMuY29tIiB0YXJnZXQ9Il9ibGFuayI+aG91 c2xleUB2aWdpbHNlYy5jb208L2E+Jmd0OzsgSUVURiBUTFMgJmx0OzxhIGhyZWY9Im1haWx0bzp0 bHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50bHNAaWV0Zi5vcmc8L2E+Jmd0Ozwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBbVExTXSBQUiMzNDU6IElBTkEgQ29uc2lkZXJhdGlvbnM8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5IZXJlIGlzIG15IHVuZGVyc3RhbmRpbmc8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4tIFJlY29tbWVuZGVkIHRoaW5ncyBhcmUgdGhpbmdzIHdo aWNoIHRoZSBJRVRGIGhhcyByZXZpZXdlZCBhbmQgdGhpbmtzIGFyZSBnb29kLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tIE5vdCByZWNvbW1l bmRlZCB0aGluZ3MgYXJlIHRoaW5ncyB3aGljaCB0aGUgSUVURiBoYXMgbm90IHJldmlld2VkIGFu ZCBtYXkgYmUgZmluZSBidXQgbWF5IGFsc28gYmUgYmFkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIGludGVudGlvbiBpcyB0byBi cmVhayB0aGUgYmluZGluZyBiZXR3ZWVuIGNvZGUgcG9pbnQgYXNzaWdubWVudCBhbmQ8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ZW5kb3JzZW1l bnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4tRWtyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPk9uIFR1ZSwgTm92IDE3LCAyMDE1IGF0IDEwOjM2IEFNLCBBbmRyZWkgUG9wb3YgJmx0 OzxhIGhyZWY9Im1haWx0bzpBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxh bmsiPkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+V2hhdCBpcyB0aGUgaW50ZW5kZWQgdXNlIG9mIHRoZSDigJxSZWNvbW1lbmRlZOKA nSBsaXN0PyBJLmUuIGhvdyBpcyBhbiBpbXBsZW1lbnRlciBzdXBwb3NlZCB0byB0aGluayBhYm91 dA0KIHRoaXMgbWFya2VyPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPkNoZWVycyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5BbmRyZWk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFF MUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PiBUTFMgW21haWx0bzo8YSBocmVmPSJtYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj50bHMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9i PlJ1c3MgSG91c2xleTxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBOb3ZlbWJlciAxNywgMjAx NSAxMDowMSBBTTxicj4NCjxiPlRvOjwvYj4gSUVURiBUTFMgJmx0OzxhIGhyZWY9Im1haWx0bzp0 bHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50bHNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogW1RMU10gUFIjMzQ1OiBJQU5BIENvbnNpZGVyYXRpb25zPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+JiM0MzsxLiZuYnNwOyBUaGlzIHNlZW1zIGxpa2UgYSByZWFzb25hYmxlIHdheSBmb3J3YXJk LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlJ1c3M8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPk9uIE5vdiAxNywgMjAxNSwgYXQgMTI6NTEgUE0sIEVyaWMgUmVzY29ybGEgd3JvdGU6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZXJlIGFyZSBwcmVzZW50bHkg Zm91ciBjYXRlZ29yaWVzIG9mIGNpcGhlciBzdWl0ZXMgdmlzLWEtdmlzIFRMUyAxLjMuPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MS4gTVVTVCBvciBT SE9VTEQgY2lwaGVyIHN1aXRlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Mi4gU3RhbmRhcmRzIHRyYWNrIGNpcGhlciBzdWl0ZXMgKG9yIG9u ZXMgd2UgYXJlIG1ha2luZyBTVCwgbGlrZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7IHRoZSBFQ0Mgb25lcykuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjMuIE5vbiBz dGFuZGFyZHMgdHJhY2sgY2lwaGVyIHN1aXRlczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj40LiBDaXBoZXIgc3VpdGVzIHlvdSBjYW4ndCB1c2Ug YXQgYWxsIHdpdGggVExTIDEuMywgbGlrZSBBRVMtQ0JDLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSB0aGluayB3ZSdyZSBhbGwgYWdy ZWVkIHRoYXQgY2F0ZWdvcnkgIzEgc2hvdWxkIGJlIG1hcmtlZCByZWNvbW1lbmRlZDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5hbmQgdGhhdCAj MyBhbmQgIzQgc2hvdWxkIG5vdCBiZS4gVGhpcyBsZWF2ZXMgdXMgd2l0aCBjYXRlZ29yeSAjMiwg d2hpY2g8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+aW5jbHVkZXMgc3R1ZmYgbGlrZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0gRkZESEU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LSBDQ008bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk15IHByb3Bvc2FsIGlzIHRoYXQg d2U6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4tIExpc3QgYWxsIHRoZSBTdGFuZGFyZHMgVHJhY2sgY2lwaGVyIHN1aXRlcyB0aGF0IGFy ZSBjb21wYXRpYmxlIHdpdGggVExTIDEuMyBpbiBBcHBlbmRpeCBBLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tIE1hcmsgYWxsIHRoZSBjaXBo ZXIgc3VpdGVzIHRoYXQgYXJlIGxpc3RlZCBpbiBBcHBlbmRpeCBBIGFzICZxdW90O1JlY29tbWVu ZGVkJnF1b3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4tRWtyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVHVlLCBOb3YgMTcsIDIwMTUg YXQgODo0NiBBTSwgSm9lIFNhbG93ZXkgJmx0OzxhIGhyZWY9Im1haWx0bzpqc2Fsb3dleUB0YWJs ZWF1LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmpzYWxvd2V5QHRhYmxlYXUuY29tPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSB0aGluayB0aGUgVExTIDEuMyBJ QU5BIGNvbnNpZGVyYXRpb25zIHNob3VsZCBqdXN0IGRlYWwgd2l0aCBzZXR0aW5nIHVwIHRoZSBy ZWNvbW1lbmRlZCBjb2x1bW4gYW5kIG1hcmtpbmcgaXQgZm9yIHRoZSBjaXBoZXIgc3VpdGVzL2V4 dGVuc2lvbnMgdGhhdCBhcmUgZGVzY3JpYmVkIGluIHRoZSAxLjMgZG9jdW1lbnQuJm5ic3A7DQog T3RoZXIgY2lwaGVyIHN1aXRlcy9leHRlbnNpb25zJm5ic3A7IGNhbiBiZSBtYXJrZWQgYXMgcmVj b21tZW5kZWQgdGhyb3VnaCBvdGhlciBkb2N1bWVudHMuPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KT24g MTEvMTcvMTUsIDY6NTQgQU0sICZxdW90O1RMUyBvbiBiZWhhbGYgb2YgU2VhbiBUdXJuZXImcXVv dDsgJmx0OzxhIGhyZWY9Im1haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPnRscy1ib3VuY2VzQGlldGYub3JnPC9hPiBvbiBiZWhhbGYgb2YNCjxhIGhyZWY9Im1haWx0 bzpzZWFuQHNuM3JkLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnNlYW5Ac24zcmQuY29tPC9hPiZndDsg d3JvdGU6PGJyPg0KPGJyPg0KJmd0O09uIE5vdiAxNywgMjAxNSwgYXQgMTY6NDAsIEVyaWMgUmVz Y29ybGEgJmx0OzxhIGhyZWY9Im1haWx0bzpla3JAcnRmbS5jb20iIHRhcmdldD0iX2JsYW5rIj5l a3JAcnRmbS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZn dDsgMS4gVGhlIENpcGhlciBTdWl0ZXMgJnF1b3Q7UmVjb21tZW5kZWQmcXVvdDsgY29sdW1uIHdh cyBwb3B1bGF0ZWQgYmFzZWQgb248YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDt0aGUgU3RhbmRhcmRzIFRyYWNrIFJGQ3MgbGlzdGVkIGluIHRoZSBkb2N1bWVudCAoYW5kIEkg cmVtb3ZlZCB0aGU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtvdGhlcnMp Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSXNu4oCZdCBpdCBqdXN0IHRoZSBNVEkgc3Vp dGVzIGxpc3RlZCBpbiBzOC4xPzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgTWF5YmUgSSBu ZWVkIHRvIGdvIGNoZWNrIHRoZSBtaW51dGVzLCBidXQgSSB0aG91Z2h0IGl0IHdhcyB0aGU8YnI+ DQomZ3Q7Jmd0OyBTdGFuZGFyZHMgVHJhY2sgb25lcywgbm90IHRoZSBNVEkgb25lcyB0aGF0IHdl IGFncmVlZCBvbi48YnI+DQomZ3Q7Jmd0OyBUaGUgZGlmZmVyZW5jZSBoZXJlIGlzIGxhcmdlbHkg dGhlIEZGREhFIGNpcGhlciBzdWl0ZXMgYW5kIENDTS48YnI+DQomZ3Q7PGJyPg0KJmd0O0Zyb20g Smlt4oCZcyBub3RlcyBpbiB0aGUgZXRoZXJwYWQ6PGJyPg0KJmd0Ozxicj4NCiZndDtBT0I8YnI+ DQomZ3Q7U1BUOiBSZXF1ZXN0cyBmb3IgYWRkaXRpb25hbCBjaXBoZXJzIGZyb20gb3RoZXJzLiZu YnNwOyBMaXN0aW5nIGluIEEuNDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtT dWdnZXN0IHRoaW5uaW5nIGl0IGRvd24gdG8gdGhlIFNIT1VMRC9NVVNUIGxpc3Qgb25seS48YnI+ DQomZ3Q7RUtSOiBOZWVkIHRvIGVuY291cmFnZSBzdXBwb3J0IGZvciBQU0sgdmFyaWFudHM8YnI+ DQomZ3Q7RUtSOiBMb29raW5nIGF0IHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlICZxdW90O2dv b2QmcXVvdDsgbGlzdCBhbmQgdGhlICZxdW90O3NhZmUmcXVvdDsgbGlzdCBhbmQgdGhlICZxdW90 O25vIG9waW5pb24mcXVvdDsgbGlzdDxicj4NCiZndDtFS1I6IFNhbXBsZSBjYXNlIHdvdWxkIGJl IDQ0OCAtIG5vdCBhIE1VU1QvU0hPVUxEIGJ1dCBzdGlsbCB0aGluayBpdCBpcyBnb29kLjxicj4N CiZndDs8YnI+DQomZ3Q7c3B0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZndDtfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDtUTFMgbWFpbGluZyBsaXN0PGJyPg0K Jmd0OzxhIGhyZWY9Im1haWx0bzpUTFNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5UTFNAaWV0 Zi5vcmc8L2E+PGJyPg0KJmd0OzxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVj dGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1h biUyZmxpc3RpbmZvJTJmdGxzJmFtcDtkYXRhPTAxJTdjMDElN2NBbmRyZWkuUG9wb3YlNDBtaWNy b3NvZnQuY29tJTdjOTNiNWY3MDZkYjE4NGYwZmYyMWEwOGQyZWY3OTI4ZTMlN2M3MmY5ODhiZjg2 ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPXBzWDF4VUxlMXliJTJmZlFpYmpM cHZWVGdGYWx0bkdpTWNxZW84UzFZOTFxRSUzZCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQpUTFMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPlRMU0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczov L25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUy Znd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZnRscyZhbXA7ZGF0YT0wMSU3YzAx JTdjQW5kcmVpLlBvcG92JTQwbWljcm9zb2Z0LmNvbSU3YzkzYjVmNzA2ZGIxODRmMGZmMjFhMDhk MmVmNzkyOGUzJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0 YT1wc1gxeFVMZTF5YiUyZmZRaWJqTHB2VlRnRmFsdG5HaU1jcWVvOFMxWTkxcUUlM2QiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RsczwvYT48 bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KVExTIG1haWxpbmcgbGlzdDxicj4NCjxhIGhy ZWY9Im1haWx0bzpUTFNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5UTFNAaWV0Zi5vcmc8L2E+ PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2su Y29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8l MmZ0bHMmYW1wO2RhdGE9MDElN2MwMSU3Y0FuZHJlaS5Qb3BvdiU0MG1pY3Jvc29mdC5jb20lN2Nh ZDFhZGE2NGNhYmM0OGJhYjMxNDA4ZDJlZjdmOTYzZiU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3 Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9S2lFbFdzY01aWllJOXdHNHFIenZYeW5jSUpKbE0zUDM3 V2hVNkwybU5COCUzZCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vdGxzPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BLUPR03MB13967E5ECD3CCC3F25BB479B8C1D0BLUPR03MB1396namp_-- From nobody Tue Nov 17 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 BCEAD1B3386 for ; Tue, 17 Nov 2015 11:14:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQeuYKx4MUqe for ; Tue, 17 Nov 2015 11:14:07 -0800 (PST) Received: from filtteri1.pp.htv.fi (filtteri1.pp.htv.fi [213.243.153.184]) by ietfa.amsl.com (Postfix) with ESMTP id C41121B330E for ; Tue, 17 Nov 2015 11:14:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by filtteri1.pp.htv.fi (Postfix) with ESMTP id 7E2E221BB36 for ; Tue, 17 Nov 2015 21:14:05 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from smtp4.welho.com ([213.243.153.38]) by localhost (filtteri1.pp.htv.fi [213.243.153.184]) (amavisd-new, port 10024) with ESMTP id 3qH-JvnH2X5H for ; Tue, 17 Nov 2015 21:14:05 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp4.welho.com (Postfix) with ESMTPSA id 5C5EB5BC015 for ; Tue, 17 Nov 2015 21:14:05 +0200 (EET) Date: Tue, 17 Nov 2015 21:14:00 +0200 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20151117191400.GA11869@LK-Perkele-V2.elisa-laajakaista.fi> References: <7276DA5B-0563-4D70-A611-96A2E80CAECB@tableau.com> <20151117190651.GJ18315@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20151117190651.GJ18315@mournblade.imrryr.org> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] PR#345: IANA Considerations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 19:14:08 -0000 On Tue, Nov 17, 2015 at 07:06:52PM +0000, Viktor Dukhovni wrote: > On Tue, Nov 17, 2015 at 09:51:32AM -0800, Eric Rescorla wrote: > > > My proposal is that we: > > > > - List all the Standards Track cipher suites that are compatible with TLS > > 1.3 in Appendix A. > > > > - Mark all the cipher suites that are listed in Appendix A as "Recommended" > > Where does that leave ciphersuites that are "Recommended" for TLS > 1.2, but TLS 1.3? Or do none of the CBC block ciphers in TLS 1.2 qualify? None of block ciphers (nor stream ciphers) work in TLS 1.3 at all. All current registered/proposed ciphersuites that work in TLS 1.3 are *-GCM or *-POLY1305 ones (with DHE or ECDHE). -Ilari From nobody Tue Nov 17 11:15: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 1D1401B3398 for ; Tue, 17 Nov 2015 11:15:14 -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, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5XUbIYnGG5h for ; Tue, 17 Nov 2015 11:15:13 -0800 (PST) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFBC61B3386 for ; Tue, 17 Nov 2015 11:15:12 -0800 (PST) Received: by ykfs79 with SMTP id s79so23728969ykf.1 for ; Tue, 17 Nov 2015 11:15:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=Im0YZJNpFg3e0slj6ldFMWOZota5611VrmGm46gNlhE=; b=QLVhsTzu4IIIMo/YSwm4bDUVPBg0kCo2p7YRJmgyEtbUadXxR2MondcC0ksTQh5wNL rHJJ2HiT1vT/DUyjBWfn082MPN4rPHBVg8GtO8ScE2xAuInQa7F/0NU4dAx0Xviw/yzs 3B1SzNjptveogRrX/nhh8kgCqGcv2XmRrFITI4c0M4n+Aibnp0gKChU2YnDEbRbh2xXy DttPxvf32lRXijqFGPH2GuLpwn3Dh9fyopvddbun8jVed8ODU6b7Ft55QCd6T1iYs7h1 uAM/kgWDjDr2J8kw2LBcy9VGn6s1lsZR4KA4z1soCX9dwlN4kH1qf3vaL9GcF215NFla bW/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=Im0YZJNpFg3e0slj6ldFMWOZota5611VrmGm46gNlhE=; b=kOobZiYoPq05u2grayrXw53POKE39XmNV2whTfpB35m5E5z/JVQvQPCLV+moBKuNkL 0He++mCjbUJqZVSAYIr001adcwcLGHe8MHzLoKHUDUr+vIIv4DgENZJjPljpOTGRHP+b bF8pTqhqQ94VfCNP9bKw5c39Xh04cDczX43NA86p9VNmILMbAI7lMFc7+gUgVWZJJfTN FCz2amaOP5DyUO5iVWsVe/AX0bgHQbLy4KbnzvnLEpRdZgtUj0Hqfj5tAt1N9vRrBpNa wYDHMnW/jiOTljNzwOs5sX0LOTTAnYY2leS3cdwSuPUR4jilNm4F+ir6cGgRenEqErVu i6KQ== X-Gm-Message-State: ALoCoQmSuUrXlXnQ7zHJUMQPky8a8jOvT0MqZWLtmZyqrSsb7xxu9lgAK/yrdnwFdX/kvU2waoz2 X-Received: by 10.129.73.145 with SMTP id w139mr32485232ywa.223.1447787712162; Tue, 17 Nov 2015 11:15:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.221.203 with HTTP; Tue, 17 Nov 2015 11:14:32 -0800 (PST) In-Reply-To: <20151117190651.GJ18315@mournblade.imrryr.org> References: <7276DA5B-0563-4D70-A611-96A2E80CAECB@tableau.com> <20151117190651.GJ18315@mournblade.imrryr.org> From: Eric Rescorla Date: Tue, 17 Nov 2015 11:14:32 -0800 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a114d73624b7a160524c158b8 Archived-At: Subject: Re: [TLS] PR#345: IANA Considerations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 19:15:14 -0000 --001a114d73624b7a160524c158b8 Content-Type: text/plain; charset=UTF-8 On Tue, Nov 17, 2015 at 11:06 AM, Viktor Dukhovni wrote: > On Tue, Nov 17, 2015 at 09:51:32AM -0800, Eric Rescorla wrote: > > > My proposal is that we: > > > > - List all the Standards Track cipher suites that are compatible with TLS > > 1.3 in Appendix A. > > > > - Mark all the cipher suites that are listed in Appendix A as > "Recommended" > > Where does that leave ciphersuites that are "Recommended" for TLS > 1.2, but TLS 1.3? Or do none of the CBC block ciphers in TLS 1.2 qualify? > Yes. The proposed intention was that for the same reasons we moved to AEAD for 1.3, we would only Recommend AEAD for TLS 1.2. Note that this is consistent with the guidance in both RFC 7525 (which recommends AEAD) http://tools.ietf.org/html/rfc7525#section-4.2 and RFC 7540 which blacklists the non-AEAD cipher suites (http://tools.ietf.org/html/rfc7540#appendix-A) -Ekr --001a114d73624b7a160524c158b8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Nov 17, 2015 at 11:06 AM, Viktor Dukhovni <= ;ietf-dane@dukh= ovni.org> wrote:
On Tu= e, Nov 17, 2015 at 09:51:32AM -0800, Eric Rescorla wrote:

> My proposal is that we:
>
> - List all the Standards Track cipher suites that are compatible with = TLS
> 1.3 in Appendix A.
>
> - Mark all the cipher suites that are listed in Appendix A as "Re= commended"

Where does that leave ciphersuites that are "Recommended" = for TLS
1.2, but TLS 1.3?=C2=A0 Or do none of the CBC block ciphers in TLS 1.2 qual= ify?

Yes. The proposed intention was th= at for the same reasons we moved to
AEAD for 1.3, we would only R= ecommend AEAD for TLS 1.2. Note that
this is consistent with the = guidance in both RFC 7525 (which recommends AEAD) http://tools.ietf.org/html/rfc7525#sectio= n-4.2 and RFC 7540
which blacklists the non-AEAD cipher suite= s

-Ek= r
=C2=A0
--001a114d73624b7a160524c158b8-- From nobody Tue Nov 17 11:17: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 9293A1A21A5 for ; Tue, 17 Nov 2015 11:17:14 -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 DK4jlJ8JFDc6 for ; Tue, 17 Nov 2015 11:17:12 -0800 (PST) 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 1A7C91A1B5F for ; Tue, 17 Nov 2015 11:17:12 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 81D72284D70; Tue, 17 Nov 2015 19:17:05 +0000 (UTC) Date: Tue, 17 Nov 2015 19:17:05 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20151117191705.GM18315@mournblade.imrryr.org> References: <7276DA5B-0563-4D70-A611-96A2E80CAECB@tableau.com> <20151117190651.GJ18315@mournblade.imrryr.org> <20151117191400.GA11869@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151117191400.GA11869@LK-Perkele-V2.elisa-laajakaista.fi> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] PR#345: IANA Considerations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 19:17:14 -0000 On Tue, Nov 17, 2015 at 09:14:00PM +0200, Ilari Liusvaara wrote: > > Where does that leave ciphersuites that are "Recommended" for TLS > > 1.2, but TLS 1.3? Or do none of the CBC block ciphers in TLS 1.2 qualify? > > None of block ciphers (nor stream ciphers) work in TLS 1.3 at all. > > All current registered/proposed ciphersuites that work in TLS 1.3 are > *-GCM or *-POLY1305 ones (with DHE or ECDHE). I'm well aware of that, I'm just wondering whether the "Recommended" column should cover recommendations for TLS 1.2 as well TLS 1.3? That is, I thought it might distinguish between mainstream and non-mainstream ciphers for multiple protocol versions. -- Viktor. From nobody Tue Nov 17 12:46: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 719031B33AD for ; Tue, 17 Nov 2015 12:46:47 -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 3uzEfA3n1RxH for ; Tue, 17 Nov 2015 12:46:46 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id E29D21B33A7 for ; Tue, 17 Nov 2015 12:46:41 -0800 (PST) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 15184F984; Tue, 17 Nov 2015 15:46:21 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 88047202B0; Tue, 17 Nov 2015 15:45:53 -0500 (EST) From: Daniel Kahn Gillmor To: Eric Rescorla , "Short\, Todd" In-Reply-To: References: User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Tue, 17 Nov 2015 15:45:53 -0500 Message-ID: <87egfoe4n2.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Record header size? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 20:46:47 -0000 On Tue 2015-11-17 12:09:30 -0500, Eric Rescorla wrote: > The concern here is backward compatibility with inspection middleboxes which > expect the length field to be in a particular place. We agreed in Seattle to > wait for early deployment experience before modifying the header to move > the length. In particular, if we're going to make a change to the TLS record header, the change would be to remove the version and the type entirely, leaving only two octets of length on each record. Is a two-octet offset going to be problematic? --dkg From nobody Tue Nov 17 12:51: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 6C4C91B33BE for ; Tue, 17 Nov 2015 12:51:11 -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, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOSmnbr5i6QL for ; Tue, 17 Nov 2015 12:51:10 -0800 (PST) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F3D61B33BB for ; Tue, 17 Nov 2015 12:51:08 -0800 (PST) Received: by ykfs79 with SMTP id s79so28620688ykf.1 for ; Tue, 17 Nov 2015 12:51:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=LvzcnVVscGeHwpO6ADXMFm7bQMfcwyQ3fKLqQkjk55k=; b=dE/7c79YRIHRTWo3R4/Q2iIxLqTN2g9fLxMio7dkfj7i2tr6plAhSPIPDsRgDRckDy Lg7AC5y4g+KagjWGsoYciJVQaHEiQIcGIYkMsfcUtpUa4axAyODGrGvEyYkxs7T2opGg 8rS72sS0kdU5mVlepwTtZQKZf+VbB/hrGRmBFnptZQMJGvEZsGnkPwVHKFGIUA38ioQj A8qJn9GUCqgxfKahG9cXyIMVWIK+uH7jVWbCCtW1olw62uhbSo7+PlI9zjk2sLIBHieA NQ2orLSPIptSw0KxnTEj8O7hQ4SAX/sRErnBpjEnrQQVTz+eo3ix6jbP3HhYX81TX9KD f7xw== 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=LvzcnVVscGeHwpO6ADXMFm7bQMfcwyQ3fKLqQkjk55k=; b=PCmSZGCPYr8XGxX+WiJXctZJt7jj/avoCMskDhD3RppT87I2IB6ACn3fNXuq04NCgf 6IlMt+tOSh8kAn0X6oV7CT6uycHmRtSuLEqg2yca/+l22Ol/ByyXHFc/A/qTfNp5fSrU MONLspCIjq/uBUmXiXx5KKD54r3mzT0rIi1wChLJPNhTs4jmbx36rrP1KNFntcooK5KT Aiw6bg0VHwUu0QAYwYKrYOMkDkpzhKmnLtXTcwHp3RtyB8UHZ96ymXsHKmV06rQbawdI euYDFKDKGIeCUm5+ToA4fESupDeivX3mnif8wiXFfyUu1txFcQRdY2VESXoo/kGTpSzo h2Ag== X-Gm-Message-State: ALoCoQmQYnhb19dJpBABDV2zK83gautdJ94HhnvsHgcnbWm2ttgxTVsUcq/Djo+OGgN/fmdq8wxO X-Received: by 10.13.249.4 with SMTP id j4mr41996080ywf.129.1447793467896; Tue, 17 Nov 2015 12:51:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.221.203 with HTTP; Tue, 17 Nov 2015 12:50:28 -0800 (PST) In-Reply-To: <87egfoe4n2.fsf@alice.fifthhorseman.net> References: <87egfoe4n2.fsf@alice.fifthhorseman.net> From: Eric Rescorla Date: Tue, 17 Nov 2015 12:50:28 -0800 Message-ID: To: Daniel Kahn Gillmor Content-Type: multipart/alternative; boundary=94eb2c0826e85ce9340524c2af1d Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Record header size? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 20:51:11 -0000 --94eb2c0826e85ce9340524c2af1d Content-Type: text/plain; charset=UTF-8 Indeed. It doesn't seem useful to carry around two fixed bytes for alignment reasons -Ekr On Tue, Nov 17, 2015 at 12:45 PM, Daniel Kahn Gillmor wrote: > On Tue 2015-11-17 12:09:30 -0500, Eric Rescorla wrote: > > The concern here is backward compatibility with inspection middleboxes > which > > expect the length field to be in a particular place. We agreed in > Seattle to > > wait for early deployment experience before modifying the header to move > > the length. > > In particular, if we're going to make a change to the TLS record header, > the change would be to remove the version and the type entirely, leaving > only two octets of length on each record. Is a two-octet offset going > to be problematic? > > --dkg > --94eb2c0826e85ce9340524c2af1d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Indeed. It doesn't seem useful to carry around two fix= ed bytes
for alignment reasons

-Ekr
=

O= n Tue, Nov 17, 2015 at 12:45 PM, Daniel Kahn Gillmor <= dkg@fifthhorsema= n.net> wrote:
On Tue 2015-11-17 12:09:30 -0500, Eric Rescorla wrote:
> The concern here is backward compatibility with inspection middleboxes= which
> expect the length field to be in a particular place. We agreed in Seat= tle to
> wait for early deployment experience before modifying the header to mo= ve
> the length.

In particular, if we're going to make a change to the TLS record= header,
the change would be to remove the version and the type entirely, leaving only two octets of length on each record.=C2=A0 Is a two-octet offset going=
to be problematic?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--dkg

--94eb2c0826e85ce9340524c2af1d-- From nobody Tue Nov 17 12:59: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 D8E651B33EF for ; Tue, 17 Nov 2015 12:59:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 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, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tw81sChWdzdo for ; Tue, 17 Nov 2015 12:59:17 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 4A13F1B33D6 for ; Tue, 17 Nov 2015 12:59:13 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id BC113423704; Tue, 17 Nov 2015 20:59:12 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id A5A75423703; Tue, 17 Nov 2015 20:59:12 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1447793952; bh=joUjBeOFl/VPdO/iUe4q4PG8jyv+iMfSb6KL9R1luGQ=; l=5101; h=From:To:CC:Date:References:In-Reply-To:From; b=cKWC2/IQ1OgZWs1pzS8TOnHWtTkARY+iD3DPYFCLPVCJ6ylEJ1lU6e4w1WxDFxqhj Ku1uAAeIp5EDYyVecvswpLuPNEtBeNaZ/ApuRauebJ+nefbYanTEGCEPhClt+yBvVe D4+JsRpHSHC9rKbjgzjxnIdlTwO5/oIFZ60IUdWo= Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id A2586203F; Tue, 17 Nov 2015 20:59:12 +0000 (GMT) Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 17 Nov 2015 15:59:12 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1076.000; Tue, 17 Nov 2015 15:59:12 -0500 From: "Short, Todd" To: Daniel Kahn Gillmor Thread-Topic: [TLS] Record header size? Thread-Index: AQHRIUwqfC6IjHws+EWK+zLpB/KhZp6gxqoAgAA8dYCAAAO3gA== Date: Tue, 17 Nov 2015 20:59:11 +0000 Message-ID: References: <87egfoe4n2.fsf@alice.fifthhorseman.net> In-Reply-To: <87egfoe4n2.fsf@alice.fifthhorseman.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.42.131] Content-Type: multipart/alternative; boundary="_000_D5A18321BA89404791A0D0259E70F0D9akamaicom_" MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Record header size? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 20:59:19 -0000 --_000_D5A18321BA89404791A0D0259E70F0D9akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB3b3VsZCBzYXkgdGhhdCAzMi1iaXRzIHdvdWxkIGJlIG9wdGltYWwsIHNpbmNlIHRoYXQgaXMg dGhlIHR5cGljYWwgd29yZC1zaXplIG9mIHByb2Nlc3NvcnMgdGhhdCBuZWVkIGFsaWdubWVudC4g Mi1ieXRlcyBpc27igJl0IG11Y2ggYmV0dGVyIHRoYW4gNS1ieXRlcyBpbiB0aGlzIHJlZ2FyZC4N Ci0tDQotVG9kZCBTaG9ydA0KLy8gdHNob3J0QGFrYW1haS5jb208bWFpbHRvOnRzaG9ydEBha2Ft YWkuY29tPg0KLy8gIk9uZSBpZiBieSBsYW5kLCB0d28gaWYgYnkgc2VhLCB0aHJlZSBpZiBieSB0 aGUgSW50ZXJuZXQuIg0KDQpPbiBOb3YgMTcsIDIwMTUsIGF0IDM6NDUgUE0sIERhbmllbCBLYWhu IEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldDxtYWlsdG86ZGtnQGZpZnRoaG9yc2VtYW4u bmV0Pj4gd3JvdGU6DQoNCk9uIFR1ZSAyMDE1LTExLTE3IDEyOjA5OjMwIC0wNTAwLCBFcmljIFJl c2NvcmxhIHdyb3RlOg0KVGhlIGNvbmNlcm4gaGVyZSBpcyBiYWNrd2FyZCBjb21wYXRpYmlsaXR5 IHdpdGggaW5zcGVjdGlvbiBtaWRkbGVib3hlcyB3aGljaA0KZXhwZWN0IHRoZSBsZW5ndGggZmll bGQgdG8gYmUgaW4gYSBwYXJ0aWN1bGFyIHBsYWNlLiBXZSBhZ3JlZWQgaW4gU2VhdHRsZSB0bw0K d2FpdCBmb3IgZWFybHkgZGVwbG95bWVudCBleHBlcmllbmNlIGJlZm9yZSBtb2RpZnlpbmcgdGhl IGhlYWRlciB0byBtb3ZlDQp0aGUgbGVuZ3RoLg0KDQpJbiBwYXJ0aWN1bGFyLCBpZiB3ZSdyZSBn b2luZyB0byBtYWtlIGEgY2hhbmdlIHRvIHRoZSBUTFMgcmVjb3JkIGhlYWRlciwNCnRoZSBjaGFu Z2Ugd291bGQgYmUgdG8gcmVtb3ZlIHRoZSB2ZXJzaW9uIGFuZCB0aGUgdHlwZSBlbnRpcmVseSwg bGVhdmluZw0Kb25seSB0d28gb2N0ZXRzIG9mIGxlbmd0aCBvbiBlYWNoIHJlY29yZC4gIElzIGEg dHdvLW9jdGV0IG9mZnNldCBnb2luZw0KdG8gYmUgcHJvYmxlbWF0aWM/DQoNCiAgICAgICAgLS1k a2cNCg0K --_000_D5A18321BA89404791A0D0259E70F0D9akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <96725943ADB95743BB6E88FE68E566D1@akamai.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSSB3b3VsZCBzYXkgdGhhdCAzMi1i aXRzIHdvdWxkIGJlIG9wdGltYWwsIHNpbmNlIHRoYXQgaXMgdGhlIHR5cGljYWwgd29yZC1zaXpl IG9mIHByb2Nlc3NvcnMgdGhhdCBuZWVkIGFsaWdubWVudC4gMi1ieXRlcyBpc27igJl0IG11Y2gg YmV0dGVyIHRoYW4gNS1ieXRlcyBpbiB0aGlzIHJlZ2FyZC48YnIgY2xhc3M9IiI+DQo8ZGl2IGFw cGxlLWNvbnRlbnQtZWRpdGVkPSJ0cnVlIiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImNvbG9yOiBy Z2IoMCwgMCwgMCk7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQt bmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsi IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgbGV0dGVyLXNwYWNp bmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50 OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6 IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0 LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi Pi0tPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPi1Ub2RkIFNob3J0PC9kaXY+DQo8ZGl2IGNsYXNzPSIi Pi8vIDxhIGhyZWY9Im1haWx0bzp0c2hvcnRAYWthbWFpLmNvbSIgY2xhc3M9IiI+dHNob3J0QGFr YW1haS5jb208L2E+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPi8vICZxdW90O09uZSBpZiBieSBsYW5k LCB0d28gaWYgYnkgc2VhLCB0aHJlZSBpZiBieSB0aGUgSW50ZXJuZXQuJnF1b3Q7PC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIE5vdiAxNywgMjAxNSwgYXQg Mzo0NSBQTSwgRGFuaWVsIEthaG4gR2lsbG1vciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRrZ0BmaWZ0 aGhvcnNlbWFuLm5ldCIgY2xhc3M9IiI+ZGtnQGZpZnRoaG9yc2VtYW4ubmV0PC9hPiZndDsgd3Jv dGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBj bGFzcz0iIj5PbiBUdWUgMjAxNS0xMS0xNyAxMjowOTozMCAtMDUwMCwgRXJpYyBSZXNjb3JsYSB3 cm90ZTo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5UaGUg Y29uY2VybiBoZXJlIGlzIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgd2l0aCBpbnNwZWN0aW9uIG1p ZGRsZWJveGVzIHdoaWNoPGJyIGNsYXNzPSIiPg0KZXhwZWN0IHRoZSBsZW5ndGggZmllbGQgdG8g YmUgaW4gYSBwYXJ0aWN1bGFyIHBsYWNlLiBXZSBhZ3JlZWQgaW4gU2VhdHRsZSB0bzxiciBjbGFz cz0iIj4NCndhaXQgZm9yIGVhcmx5IGRlcGxveW1lbnQgZXhwZXJpZW5jZSBiZWZvcmUgbW9kaWZ5 aW5nIHRoZSBoZWFkZXIgdG8gbW92ZTxiciBjbGFzcz0iIj4NCnRoZSBsZW5ndGguPGJyIGNsYXNz PSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KSW4gcGFydGljdWxhciwgaWYgd2Un cmUgZ29pbmcgdG8gbWFrZSBhIGNoYW5nZSB0byB0aGUgVExTIHJlY29yZCBoZWFkZXIsPGJyIGNs YXNzPSIiPg0KdGhlIGNoYW5nZSB3b3VsZCBiZSB0byByZW1vdmUgdGhlIHZlcnNpb24gYW5kIHRo ZSB0eXBlIGVudGlyZWx5LCBsZWF2aW5nPGJyIGNsYXNzPSIiPg0Kb25seSB0d28gb2N0ZXRzIG9m IGxlbmd0aCBvbiBlYWNoIHJlY29yZC4gJm5ic3A7SXMgYSB0d28tb2N0ZXQgb2Zmc2V0IGdvaW5n PGJyIGNsYXNzPSIiPg0KdG8gYmUgcHJvYmxlbWF0aWM/PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7LS1k a2c8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNz PSIiPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D5A18321BA89404791A0D0259E70F0D9akamaicom_-- From nobody Tue Nov 17 13:10: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 419D91A882B for ; Tue, 17 Nov 2015 13:10:24 -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, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bTlN3aqk24R for ; Tue, 17 Nov 2015 13:10:19 -0800 (PST) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::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 376F51A8821 for ; Tue, 17 Nov 2015 13:10:19 -0800 (PST) Received: by ykdv3 with SMTP id v3so29455906ykd.0 for ; Tue, 17 Nov 2015 13:10:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=eeqE+I/L90636DnQE0G+480rleXMFBL4khP1Tjz/hHg=; b=W9hDWqYcHbmPjiXU/GFkZIIZduetqOtxYq5gUOOGTlWwOquOJ5AX8gm/JHrr+nwq67 koFWNii9s/mBu83yO7JDc2P2vu2ykoHXoqUIivf9ZsO1P6QR55N5rcSbER8qxcwu3GF6 wSOeA/ukDZoYAuCEsrw8p5HLN2rnYdEGf/jN0BjbwR7CSN+YNc5+4bkRw8Kt1FR0I0wk z1IxtebtJWfyLkAkooshwOHS/ZSZr2ufTEkXQ6qW0fZ/n2j7g7oAcbu26P6OZRcjU9ZC ljaAuY9taKdZ0dKZyDLvIFzanjjtf1vWgMLIjuzRoDiNO+hOy5jphRmx8yY/7VfsjIy5 OgkA== 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=eeqE+I/L90636DnQE0G+480rleXMFBL4khP1Tjz/hHg=; b=YgzgS9NAxU/vqSrEQtiAiwEiTLoPUuZRi7PcRJWy1pNyI8iTQOA+vnSIfbxQE99jvG d5a60cD/J3Wwsg5ueqetukXPv9gejd0QXeNenhFtvw/5jZRESHZUrnL+1VbHOImp40E7 QaHAoa5jYUeoGLqvRotqd9qmu4Ay5OWOTCtM0hObCGss8TIr/ciNnRcfiCsrDATkOxbr dJ+eIP36e1WGykT/UZhBMi7aVCe2+VvoiCtWNbTYm1VrvoeELgBNCDxfhbzoPVWZJAe3 W8ZgFDMWreLKBEBPWCLj9i2JnOHuAqthIJphf1YX8fK5jUIqT2bUwlolf43ucJ6at2Us egDQ== X-Gm-Message-State: ALoCoQnWE4w92nQEQioEOphZWijkJpePzPcW9fwOMFR8jfluFW6a+u0bMGb4U9N1c7GUaovfhAiD X-Received: by 10.13.197.194 with SMTP id h185mr35074951ywd.12.1447794618428; Tue, 17 Nov 2015 13:10:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.221.203 with HTTP; Tue, 17 Nov 2015 13:09:39 -0800 (PST) In-Reply-To: References: <87egfoe4n2.fsf@alice.fifthhorseman.net> From: Eric Rescorla Date: Tue, 17 Nov 2015 13:09:39 -0800 Message-ID: To: "Short, Todd" Content-Type: multipart/alternative; boundary=001a114edd4af0a2b20524c2f355 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Record header size? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 21:10:24 -0000 --001a114edd4af0a2b20524c2f355 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Can you expand on the alignment issues some more? Thinking through how typical software stacks work, you first read the record header into some buffer to figure out how long the record is and then you read the record payload into a buffer, which may not even be the same buffer. For instance, in NSS, there are two buffers, one for the header and one for the body: https://dxr.mozilla.org/mozilla-central/source/security/nss/lib/ssl/ssl3gth= r.c#53 https://dxr.mozilla.org/mozilla-central/source/security/nss/lib/ssl/sslimpl= .h#377 In a system like this, there's nothing stopping the body from being 4-byte aligned, whatever the alignment of the header is. I'd be interested in hearing about the design you have in mind. -Ekr On Tue, Nov 17, 2015 at 12:59 PM, Short, Todd wrote: > I would say that 32-bits would be optimal, since that is the typical > word-size of processors that need alignment. 2-bytes isn=E2=80=99t much b= etter than > 5-bytes in this regard. > -- > -Todd Short > // tshort@akamai.com > // "One if by land, two if by sea, three if by the Internet." > > On Nov 17, 2015, at 3:45 PM, Daniel Kahn Gillmor > wrote: > > On Tue 2015-11-17 12:09:30 -0500, Eric Rescorla wrote: > > The concern here is backward compatibility with inspection middleboxes > which > expect the length field to be in a particular place. We agreed in Seattle > to > wait for early deployment experience before modifying the header to move > the length. > > > In particular, if we're going to make a change to the TLS record header, > the change would be to remove the version and the type entirely, leaving > only two octets of length on each record. Is a two-octet offset going > to be problematic? > > --dkg > > > --001a114edd4af0a2b20524c2f355 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Can you expand on the alignment issues some more?

=
Thinking through how typical software stacks work, you first rea= d
the record header into some buffer to figure out how long the r= ecord
is and then you read the record payload into a buffer, whic= h may
not even be the same buffer. For instance, in NSS, there ar= e
two buffers, one for the header and one for the body:


In a system like this, there= 9;s nothing stopping the body from being 4-byte aligned, whatever the align= ment of the header is. I'd be interested in hearing
about the= design you have in mind.

-Ekr






=


On Tue, Nov 17, 2015 at 12:59 PM, Short, Todd <tshort@aka= mai.com> wrote:
I would say that 32-bits would be optimal, since that is the typical word-s= ize of processors that need alignment. 2-bytes isn=E2=80=99t much better th= an 5-bytes in this regard.
--
-Todd Short
// "One if by land, two if by sea, three if by the Internet."= ;

On Nov 17, 2015, at 3:45 PM, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wro= te:

On Tue 2015-11-17 12:09:30 -0500, Eric Rescorla wrote:
The concern here is backward compatibility with i= nspection middleboxes which
expect the length field to be in a particular place. We agreed in Seattle t= o
wait for early deployment experience before modifying the header to move the length.

In particular, if we're going to make a change to the TLS record header= ,
the change would be to remove the version and the type entirely, leaving only two octets of length on each record.=C2=A0 Is a two-octet offset going=
to be problematic?

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0--dkg


--001a114edd4af0a2b20524c2f355-- From nobody Tue Nov 17 13:27: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 A02E81A8932 for ; Tue, 17 Nov 2015 13:27:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.596 X-Spam-Level: X-Spam-Status: No, score=-0.596 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, HTTPS_HTTP_MISMATCH=1.989, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jlbWBN34fvfA for ; Tue, 17 Nov 2015 13:26:59 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id AE9A21A8925 for ; Tue, 17 Nov 2015 13:26:58 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 15C464243CC; Tue, 17 Nov 2015 21:26:58 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id F183E423737; Tue, 17 Nov 2015 21:26:57 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1447795617; bh=A3o7r0W9OXDH9HspOKNl58LPlTeaSfDP3idgUDxkteE=; l=19287; h=From:To:CC:Date:References:In-Reply-To:From; b=yrE+8yGyc1RfEsOhDASI/ile3SxOt1vk1voaqKDBGprMv39LitGLERReWNVlBcf73 qOE+vj3/x8Pb7WTJcRZ1xr2O9UIGfpVuxdsXsDXTeYqHHewy11rmXnHpqdB1+2PVNn NI2YDPXK1EBrvQJdoipjwoyF8A385AQaV0Tqj4vk= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id ED171202C; Tue, 17 Nov 2015 21:26:57 +0000 (GMT) Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 17 Nov 2015 16:26:57 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1076.000; Tue, 17 Nov 2015 16:26:57 -0500 From: "Short, Todd" To: Eric Rescorla Thread-Topic: [TLS] Record header size? Thread-Index: AQHRIUwqfC6IjHws+EWK+zLpB/KhZp6gxqoAgAA8dYCAAAO3gIAAAu2AgAAE1oA= Date: Tue, 17 Nov 2015 21:26:57 +0000 Message-ID: <75C621A0-AAFB-4BB9-9958-17864699C2C7@akamai.com> References: <87egfoe4n2.fsf@alice.fifthhorseman.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.42.131] Content-Type: multipart/alternative; boundary="_000_75C621A0AAFB4BB9995817864699C2C7akamaicom_" MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Record header size? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 21:27:01 -0000 --_000_75C621A0AAFB4BB9995817864699C2C7akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RXJpYywNCg0KVG8gYmUgaG9uZXN0LCBpdOKAmXMgYWx3YXlzIGtpbmRhIGJ1Z2dlZCBtZSB0aGF0 IFNTTC9UTFMgdXNlcyBhIDUtYnl0ZSBoZWFkZXIsIGNvbWluZyBmcm9tIG15IGVtYmVkZGVkIG5l dHdvcmsgc3lzdGVtIGJhY2tncm91bmQuDQoNCknigJl2ZSBoYWQgZGVhbGluZ3Mgd2l0aCBjcnlw dG9ncmFwaGljIGhhcmR3YXJlIChTYWZlTmV0IGF0IEFsdGlnYSwgYW5kIENhdml1bSBOaXRyb3gg YXQgQ2lzY28pLCBhbmQgdGhleSBoYXZlIHRvIGdvIHRocm91Z2ggaG9vcHMgdG8gZGVhbCB3aXRo IHVuYWxpZ25lZCBhY2Nlc3MuIFRoZSBDYXZpdW0gTml0cm94IGNoaXAgaXMgYWJsZSB0byBkbyBU TFMgcmVjb3JkIHByb2Nlc3Npbmcgb24gaXTigJlzIG93biAoaXTigJlzIG5vdCBqdXN0IHNpbXBs ZSBjcnlwdG8pLCBhbmQgbmV0d29yayBwcm9jZXNzb3JzIGxpa2UgYWxpZ25lZCBkYXRhLg0KDQpF bWJlZGRlZCBzeXN0ZW1zIGRvbuKAmXQgaGF2ZSB0aGUgbHV4dXJ5IG9mIG1idWYtdHlwZSBvZiBi dWZmZXIgc2NoZW1lIChhcyB5b3UgZGVzY3JpYmUgZm9yIE5TUykuIE1hbnkgaGF2ZSBldGhlcm5l dC1mcmFtZSBzaXplZCBidWZmZXJzIGluIGxvY2tlZC9waW5uZWQgbWVtb3J5IHRoYXQgcmVhZCBp biBhIHdob2xlIGV0aGVybmV0IGZyYW1lLCBhbmQgdGhlbiBzdHJpcCBvZmYgaGVhZGVycyBieSBh ZHZhbmNpbmcgcG9pbnRlcnMgaW50byB0aGUgZnJhbWUuIFRoaXMgbWluaW1pemVzIGNvcGllcywg YW5kIHRoZSBnb2FsIGlzIHRvIGhhdmUgYSB6ZXJvLWNvcHkgbmV0d29yayBzdGFjay4gT25jZSB0 aGUgNS1ieXRlIFRMUyBoZWFkZXIgaXMgcmVhY2hlZCwgdGhlIGRhdGEgdG8gYmUgZGVjcnlwdGVk IGlzIG5vIGxvbmdlciBhbGlnbmVkLCBhbmQgdGhpcyByZXF1aXJlcyBoYW5kbGluZyB1bmFsaWdu ZWQgYWNjZXNzLCBvciBjb3B5aW5nIHRoZSBtZW1vcnkgdG8gYW4gYWxpZ25lZCBidWZmZXI7IGJv dGggb2Ygd2hpY2ggaHVydCBwZXJmb3JtYW5jZS4gSWYgdGhlIGNyeXB0b2dyYXBoeSBpcyB0byBi ZSBvZmZsb2FkZWQgdG8gYSBjby1wcm9jZXNzb3IsIGRlcGVuZGluZyBvbiB0aGUgY2hpcCwgdGhl IGVuY3J5cHRlZCBwb3J0aW9uIG11c3QgYmUgYWxpZ25lZCwgYW5kIHRodXMgbXVzdCBiZSBjb3Bp ZWQuDQoNClRoaXMgaXMgYSBjb21tb24gYXJjaGl0ZWN0dXJlIGZvciBDaXNjbyBJT1MsIENhdGFs eXN0IGFuZCBvdGhlciBoaWdoLXBlcmZvcm1hbmNlIHJvdXRlcnMgYW5kIFZQTiBzZXJ2ZXJzIChl LmcuIENpc2NvIEFTQSkuDQoNCk90aGVyIHJlZmVyZW5jZXMgcmVnYXJkaW5nIGFsaWduZWQgdnMu IHVuYWxpZ25lZDoNCg0KV2hpbGUgdGhpcyByZWZlcmVuY2UgaXMgb2xkICh+NiB5ZWFycyksIHRo aXMgZ3V5IHRlc3RlZCBhbGlnbmVkIHZzLiB1bmFsaWduZWQgYWNjZXNzIG9uIEludGVsIHg4NiBh cmNoaXRlY3R1cmUsIGFuZCBmb3VuZCB0aGF0IHRoZXJlIHdhcyBhIGRpZmZlcmVuY2UgaW4gcGVy Zm9ybWFuY2UuDQoNCmh0dHA6Ly93d3cuYWxleG9ubGludXguY29tL2FsaWduZWQtdnMtdW5hbGln bmVkLW1lbW9yeS1hY2Nlc3MNCg0KSW50ZWwgcmVjb21tZW5kcyBkYXRhIGFsaWdubWVudCBpbiBz dHJ1Y3R1cmVzICh3aGljaCBpcyBiYXNpY2FsbHkgd2hhdCBhIHJlY29yZF9oZWFkZXIgaXMpIGZv ciBwZXJmb3JtYW5jZS9jYWNoZSByZWFzb25zOg0KDQpodHRwczovL3NvZnR3YXJlLmludGVsLmNv bS9lbi11cy9hcnRpY2xlcy9jb2RpbmctZm9yLXBlcmZvcm1hbmNlLWRhdGEtYWxpZ25tZW50LWFu ZC1zdHJ1Y3R1cmVzDQoNCk9sZCBSZWZlcmVuY2UgZnJvbSBJQk0gKDIwMDUpIHJlZ2FyZGluZyBh bGlnbmVkIHZzLiB1bmFsaWduZWQgYWNjZXNzOg0KDQpodHRwOi8vd3d3LmlibS5jb20vZGV2ZWxv cGVyd29ya3MvbGlicmFyeS9wYS1kYWxpZ24vDQoNClNvIHdoaWxlIFJJU0MgcHJvY2Vzc29ycyBz dWZmZXIgdGhlIG1vc3QgZnJvbSB1bmFsaWduZWQgZGF0YSwgeDg2IHByb2Nlc3NvcnMgY2FuIHN1 ZmZlciBmcm9tIHBlcmZvcm1hbmNlIGlzc3VlcyBhcyB3ZWxsLg0KDQotLQ0KLVRvZGQgU2hvcnQN Ci8vIHRzaG9ydEBha2FtYWkuY29tPG1haWx0bzp0c2hvcnRAYWthbWFpLmNvbT4NCi8vICJPbmUg aWYgYnkgbGFuZCwgdHdvIGlmIGJ5IHNlYSwgdGhyZWUgaWYgYnkgdGhlIEludGVybmV0LiINCg0K T24gTm92IDE3LCAyMDE1LCBhdCA0OjA5IFBNLCBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb208 bWFpbHRvOmVrckBydGZtLmNvbT4+IHdyb3RlOg0KDQpDYW4geW91IGV4cGFuZCBvbiB0aGUgYWxp Z25tZW50IGlzc3VlcyBzb21lIG1vcmU/DQoNClRoaW5raW5nIHRocm91Z2ggaG93IHR5cGljYWwg c29mdHdhcmUgc3RhY2tzIHdvcmssIHlvdSBmaXJzdCByZWFkDQp0aGUgcmVjb3JkIGhlYWRlciBp bnRvIHNvbWUgYnVmZmVyIHRvIGZpZ3VyZSBvdXQgaG93IGxvbmcgdGhlIHJlY29yZA0KaXMgYW5k IHRoZW4geW91IHJlYWQgdGhlIHJlY29yZCBwYXlsb2FkIGludG8gYSBidWZmZXIsIHdoaWNoIG1h eQ0Kbm90IGV2ZW4gYmUgdGhlIHNhbWUgYnVmZmVyLiBGb3IgaW5zdGFuY2UsIGluIE5TUywgdGhl cmUgYXJlDQp0d28gYnVmZmVycywgb25lIGZvciB0aGUgaGVhZGVyIGFuZCBvbmUgZm9yIHRoZSBi b2R5Og0KDQpodHRwczovL2R4ci5tb3ppbGxhLm9yZy9tb3ppbGxhLWNlbnRyYWwvc291cmNlL3Nl Y3VyaXR5L25zcy9saWIvc3NsL3NzbDNndGhyLmMjNTM8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29m cG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19keHIubW96aWxsYS5vcmdfbW96aWxsYS0yRGNl bnRyYWxfc291cmNlX3NlY3VyaXR5X25zc19saWJfc3NsX3NzbDNndGhyLmMtMjM1MyZkPUN3TUZh USZjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmcj1RQkVjUXNxb1VEZGsxUTI2Q3psek5QUFVrS1lX SWgxTFlzaUhBd210UmlrJm09bGtwLUFiejh6M3JvRmJHYXZmTkNXbXR6UFhNRGpFckhOR05IVHhZ QnpoNCZzPXAzOF81WEsxNGVQYmhMeDF4MXJMbHJ4b0Z1T0VOeVBXR1Y2OEdGWVpnblkmZT0+DQpo dHRwczovL2R4ci5tb3ppbGxhLm9yZy9tb3ppbGxhLWNlbnRyYWwvc291cmNlL3NlY3VyaXR5L25z cy9saWIvc3NsL3NzbGltcGwuaCMzNzc8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29t L3YyL3VybD91PWh0dHBzLTNBX19keHIubW96aWxsYS5vcmdfbW96aWxsYS0yRGNlbnRyYWxfc291 cmNlX3NlY3VyaXR5X25zc19saWJfc3NsX3NzbGltcGwuaC0yMzM3NyZkPUN3TUZhUSZjPTk2WmJa WmNhTUY0dzBGNGpwTjZMWmcmcj1RQkVjUXNxb1VEZGsxUTI2Q3psek5QUFVrS1lXSWgxTFlzaUhB d210UmlrJm09bGtwLUFiejh6M3JvRmJHYXZmTkNXbXR6UFhNRGpFckhOR05IVHhZQnpoNCZzPXN4 TF9lTWZvTjBvdE1pM25ZdkdremNJZHdNLW9yWUY2eHdGM1BPR1A0REkmZT0+DQoNCkluIGEgc3lz dGVtIGxpa2UgdGhpcywgdGhlcmUncyBub3RoaW5nIHN0b3BwaW5nIHRoZSBib2R5IGZyb20gYmVp bmcgNC1ieXRlIGFsaWduZWQsIHdoYXRldmVyIHRoZSBhbGlnbm1lbnQgb2YgdGhlIGhlYWRlciBp cy4gSSdkIGJlIGludGVyZXN0ZWQgaW4gaGVhcmluZw0KYWJvdXQgdGhlIGRlc2lnbiB5b3UgaGF2 ZSBpbiBtaW5kLg0KDQotRWtyDQoNCg0KDQoNCg0KDQoNCg0KT24gVHVlLCBOb3YgMTcsIDIwMTUg YXQgMTI6NTkgUE0sIFNob3J0LCBUb2RkIDx0c2hvcnRAYWthbWFpLmNvbTxtYWlsdG86dHNob3J0 QGFrYW1haS5jb20+PiB3cm90ZToNCkkgd291bGQgc2F5IHRoYXQgMzItYml0cyB3b3VsZCBiZSBv cHRpbWFsLCBzaW5jZSB0aGF0IGlzIHRoZSB0eXBpY2FsIHdvcmQtc2l6ZSBvZiBwcm9jZXNzb3Jz IHRoYXQgbmVlZCBhbGlnbm1lbnQuIDItYnl0ZXMgaXNu4oCZdCBtdWNoIGJldHRlciB0aGFuIDUt Ynl0ZXMgaW4gdGhpcyByZWdhcmQuDQotLQ0KLVRvZGQgU2hvcnQNCi8vIHRzaG9ydEBha2FtYWku Y29tPG1haWx0bzp0c2hvcnRAYWthbWFpLmNvbT4NCi8vICJPbmUgaWYgYnkgbGFuZCwgdHdvIGlm IGJ5IHNlYSwgdGhyZWUgaWYgYnkgdGhlIEludGVybmV0LiINCg0KT24gTm92IDE3LCAyMDE1LCBh dCAzOjQ1IFBNLCBEYW5pZWwgS2FobiBHaWxsbW9yIDxka2dAZmlmdGhob3JzZW1hbi5uZXQ8bWFp bHRvOmRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD4+IHdyb3RlOg0KDQpPbiBUdWUgMjAxNS0xMS0xNyAx MjowOTozMCAtMDUwMCwgRXJpYyBSZXNjb3JsYSB3cm90ZToNClRoZSBjb25jZXJuIGhlcmUgaXMg YmFja3dhcmQgY29tcGF0aWJpbGl0eSB3aXRoIGluc3BlY3Rpb24gbWlkZGxlYm94ZXMgd2hpY2gN CmV4cGVjdCB0aGUgbGVuZ3RoIGZpZWxkIHRvIGJlIGluIGEgcGFydGljdWxhciBwbGFjZS4gV2Ug YWdyZWVkIGluIFNlYXR0bGUgdG8NCndhaXQgZm9yIGVhcmx5IGRlcGxveW1lbnQgZXhwZXJpZW5j ZSBiZWZvcmUgbW9kaWZ5aW5nIHRoZSBoZWFkZXIgdG8gbW92ZQ0KdGhlIGxlbmd0aC4NCg0KSW4g cGFydGljdWxhciwgaWYgd2UncmUgZ29pbmcgdG8gbWFrZSBhIGNoYW5nZSB0byB0aGUgVExTIHJl Y29yZCBoZWFkZXIsDQp0aGUgY2hhbmdlIHdvdWxkIGJlIHRvIHJlbW92ZSB0aGUgdmVyc2lvbiBh bmQgdGhlIHR5cGUgZW50aXJlbHksIGxlYXZpbmcNCm9ubHkgdHdvIG9jdGV0cyBvZiBsZW5ndGgg b24gZWFjaCByZWNvcmQuICBJcyBhIHR3by1vY3RldCBvZmZzZXQgZ29pbmcNCnRvIGJlIHByb2Js ZW1hdGljPw0KDQogICAgICAgIC0tZGtnDQoNCg0KDQo= --_000_75C621A0AAFB4BB9995817864699C2C7akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <169B2B5DD0627042B60F83D3DFDF5C7F@akamai.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+RXJpYyw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPlRvIGJlIGhvbmVzdCwgaXTigJlzIGFsd2F5cyBraW5kYSBidWdnZWQg bWUgdGhhdCBTU0wvVExTIHVzZXMgYSA1LWJ5dGUgaGVhZGVyLCBjb21pbmcgZnJvbSBteSBlbWJl ZGRlZCBuZXR3b3JrIHN5c3RlbSBiYWNrZ3JvdW5kLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SeKAmXZlIGhhZCBkZWFsaW5ncyB3aXRo IGNyeXB0b2dyYXBoaWMgaGFyZHdhcmUgKFNhZmVOZXQgYXQgQWx0aWdhLCBhbmQgQ2F2aXVtIE5p dHJveCBhdCBDaXNjbyksIGFuZCB0aGV5IGhhdmUgdG8gZ28gdGhyb3VnaCBob29wcyB0byBkZWFs IHdpdGggdW5hbGlnbmVkIGFjY2Vzcy4gVGhlIENhdml1bSBOaXRyb3ggY2hpcCBpcyBhYmxlIHRv IGRvIFRMUyByZWNvcmQgcHJvY2Vzc2luZyBvbiBpdOKAmXMgb3duIChpdOKAmXMgbm90IGp1c3QN CiBzaW1wbGUgY3J5cHRvKSwgYW5kIG5ldHdvcmsgcHJvY2Vzc29ycyBsaWtlIGFsaWduZWQgZGF0 YS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPkVtYmVkZGVkIHN5c3RlbXMgZG9u4oCZdCBoYXZlIHRoZSBsdXh1cnkgb2YgbWJ1Zi10eXBl IG9mIGJ1ZmZlciBzY2hlbWUgKGFzIHlvdSBkZXNjcmliZSBmb3IgTlNTKS4gTWFueSBoYXZlIGV0 aGVybmV0LWZyYW1lIHNpemVkIGJ1ZmZlcnMgaW4gbG9ja2VkL3Bpbm5lZCBtZW1vcnkgdGhhdCBy ZWFkIGluIGEgd2hvbGUgZXRoZXJuZXQgZnJhbWUsIGFuZCB0aGVuIHN0cmlwIG9mZiBoZWFkZXJz IGJ5IGFkdmFuY2luZyBwb2ludGVycw0KIGludG8gdGhlIGZyYW1lLiBUaGlzIG1pbmltaXplcyBj b3BpZXMsIGFuZCB0aGUgZ29hbCBpcyB0byBoYXZlIGEgemVyby1jb3B5IG5ldHdvcmsgc3RhY2su IE9uY2UgdGhlIDUtYnl0ZSBUTFMgaGVhZGVyIGlzIHJlYWNoZWQsIHRoZSBkYXRhIHRvIGJlIGRl Y3J5cHRlZCBpcyBubyBsb25nZXIgYWxpZ25lZCwgYW5kIHRoaXMgcmVxdWlyZXMgaGFuZGxpbmcg dW5hbGlnbmVkIGFjY2Vzcywgb3IgY29weWluZyB0aGUgbWVtb3J5IHRvIGFuIGFsaWduZWQNCiBi dWZmZXI7IGJvdGggb2Ygd2hpY2ggaHVydCBwZXJmb3JtYW5jZS4gSWYgdGhlIGNyeXB0b2dyYXBo eSBpcyB0byBiZSBvZmZsb2FkZWQgdG8gYSBjby1wcm9jZXNzb3IsIGRlcGVuZGluZyBvbiB0aGUg Y2hpcCwgdGhlIGVuY3J5cHRlZCBwb3J0aW9uIG11c3QgYmUgYWxpZ25lZCwgYW5kIHRodXMgbXVz dCBiZSBjb3BpZWQuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj5UaGlzIGlzIGEgY29tbW9uIGFyY2hpdGVjdHVyZSBmb3IgQ2lzY28gSU9T LCBDYXRhbHlzdCBhbmQgb3RoZXIgaGlnaC1wZXJmb3JtYW5jZSByb3V0ZXJzIGFuZCBWUE4gc2Vy dmVycyAoZS5nLiBDaXNjbyBBU0EpLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+T3RoZXIgcmVmZXJlbmNlcyByZWdhcmRpbmcgYWxpZ25l ZCB2cy4gdW5hbGlnbmVkOjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjwvZGl2Pg0KV2hpbGUgdGhpcyByZWZlcmVuY2UgaXMgb2xkICh+NiB5ZWFycyksIHRoaXMg Z3V5IHRlc3RlZCBhbGlnbmVkIHZzLiB1bmFsaWduZWQgYWNjZXNzIG9uIEludGVsIHg4NiBhcmNo aXRlY3R1cmUsIGFuZCBmb3VuZCB0aGF0IHRoZXJlIHdhcyBhIGRpZmZlcmVuY2UgaW4gcGVyZm9y bWFuY2UuDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij48YSBocmVmPSJodHRwOi8vd3d3LmFsZXhvbmxpbnV4LmNvbS9hbGlnbmVkLXZzLXVuYWxpZ25l ZC1tZW1vcnktYWNjZXNzIiBjbGFzcz0iIj5odHRwOi8vd3d3LmFsZXhvbmxpbnV4LmNvbS9hbGln bmVkLXZzLXVuYWxpZ25lZC1tZW1vcnktYWNjZXNzPC9hPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SW50ZWwgcmVjb21tZW5kcyBkYXRh IGFsaWdubWVudCBpbiBzdHJ1Y3R1cmVzICh3aGljaCBpcyBiYXNpY2FsbHkgd2hhdCBhIHJlY29y ZF9oZWFkZXIgaXMpIGZvciBwZXJmb3JtYW5jZS9jYWNoZSByZWFzb25zOjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGEgaHJlZj0iaHR0 cHM6Ly9zb2Z0d2FyZS5pbnRlbC5jb20vZW4tdXMvYXJ0aWNsZXMvY29kaW5nLWZvci1wZXJmb3Jt YW5jZS1kYXRhLWFsaWdubWVudC1hbmQtc3RydWN0dXJlcyIgY2xhc3M9IiI+aHR0cHM6Ly9zb2Z0 d2FyZS5pbnRlbC5jb20vZW4tdXMvYXJ0aWNsZXMvY29kaW5nLWZvci1wZXJmb3JtYW5jZS1kYXRh LWFsaWdubWVudC1hbmQtc3RydWN0dXJlczwvYT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPk9sZCBSZWZlcmVuY2UgZnJvbSBJQk0gKDIw MDUpIHJlZ2FyZGluZyBhbGlnbmVkIHZzLiB1bmFsaWduZWQgYWNjZXNzOjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGEgaHJlZj0iaHR0 cDovL3d3dy5pYm0uY29tL2RldmVsb3BlcndvcmtzL2xpYnJhcnkvcGEtZGFsaWduLyIgY2xhc3M9 IiI+aHR0cDovL3d3dy5pYm0uY29tL2RldmVsb3BlcndvcmtzL2xpYnJhcnkvcGEtZGFsaWduLzwv YT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPlNvIHdoaWxlIFJJU0MgcHJvY2Vzc29ycyBzdWZmZXIgdGhlIG1vc3QgZnJvbSB1bmFsaWdu ZWQgZGF0YSwgeDg2IHByb2Nlc3NvcnMgY2FuIHN1ZmZlciBmcm9tIHBlcmZvcm1hbmNlIGlzc3Vl cyBhcyB3ZWxsLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgYXBwbGUtY29udGVudC1lZGl0ZWQ9InRydWUiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iY29s b3I6IHJnYigwLCAwLCAwKTsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsg dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAt d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdl YmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNw YWNlOyIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBsZXR0ZXIt c3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1p bmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdp ZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13 ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiI+LS08L2Rpdj4NCjxkaXYgY2xhc3M9IiI+LVRvZGQgU2hvcnQ8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+Ly8gPGEgaHJlZj0ibWFpbHRvOnRzaG9ydEBha2FtYWkuY29tIiBjbGFzcz0iIj50c2hv cnRAYWthbWFpLmNvbTwvYT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Ly8gJnF1b3Q7T25lIGlmIGJ5 IGxhbmQsIHR3byBpZiBieSBzZWEsIHRocmVlIGlmIGJ5IHRoZSBJbnRlcm5ldC4mcXVvdDs8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXY+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gTm92IDE3LCAyMDE1 LCBhdCA0OjA5IFBNLCBFcmljIFJlc2NvcmxhICZsdDs8YSBocmVmPSJtYWlsdG86ZWtyQHJ0Zm0u Y29tIiBjbGFzcz0iIj5la3JAcnRmbS5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFz cz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9 Imx0ciIgY2xhc3M9IiI+Q2FuIHlvdSBleHBhbmQgb24gdGhlIGFsaWdubWVudCBpc3N1ZXMgc29t ZSBtb3JlPw0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+VGhpbmtpbmcgdGhyb3VnaCBob3cgdHlwaWNhbCBzb2Z0d2FyZSBzdGFja3Mgd29yaywgeW91 IGZpcnN0IHJlYWQ8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+dGhlIHJlY29yZCBoZWFkZXIgaW50byBz b21lIGJ1ZmZlciB0byBmaWd1cmUgb3V0IGhvdyBsb25nIHRoZSByZWNvcmQ8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+aXMgYW5kIHRoZW4geW91IHJlYWQgdGhlIHJlY29yZCBwYXlsb2FkIGludG8gYSBi dWZmZXIsIHdoaWNoIG1heTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5ub3QgZXZlbiBiZSB0aGUgc2Ft ZSBidWZmZXIuIEZvciBpbnN0YW5jZSwgaW4gTlNTLCB0aGVyZSBhcmU8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+dHdvIGJ1ZmZlcnMsIG9uZSBmb3IgdGhlIGhlYWRlciBhbmQgb25lIGZvciB0aGUgYm9k eTo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o dHRwcy0zQV9fZHhyLm1vemlsbGEub3JnX21vemlsbGEtMkRjZW50cmFsX3NvdXJjZV9zZWN1cml0 eV9uc3NfbGliX3NzbF9zc2wzZ3Roci5jLTIzNTMmYW1wO2Q9Q3dNRmFRJmFtcDtjPTk2WmJaWmNh TUY0dzBGNGpwTjZMWmcmYW1wO3I9UUJFY1FzcW9VRGRrMVEyNkN6bHpOUFBVa0tZV0loMUxZc2lI QXdtdFJpayZhbXA7bT1sa3AtQWJ6OHozcm9GYkdhdmZOQ1dtdHpQWE1EakVySE5HTkhUeFlCemg0 JmFtcDtzPXAzOF81WEsxNGVQYmhMeDF4MXJMbHJ4b0Z1T0VOeVBXR1Y2OEdGWVpnblkmYW1wO2U9 IiBjbGFzcz0iIj5odHRwczovL2R4ci5tb3ppbGxhLm9yZy9tb3ppbGxhLWNlbnRyYWwvc291cmNl L3NlY3VyaXR5L25zcy9saWIvc3NsL3NzbDNndGhyLmMjNTM8L2E+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50 LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZHhyLm1vemlsbGEub3JnX21vemlsbGEtMkRjZW50cmFs X3NvdXJjZV9zZWN1cml0eV9uc3NfbGliX3NzbF9zc2xpbXBsLmgtMjMzNzcmYW1wO2Q9Q3dNRmFR JmFtcDtjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmYW1wO3I9UUJFY1FzcW9VRGRrMVEyNkN6bHpO UFBVa0tZV0loMUxZc2lIQXdtdFJpayZhbXA7bT1sa3AtQWJ6OHozcm9GYkdhdmZOQ1dtdHpQWE1E akVySE5HTkhUeFlCemg0JmFtcDtzPXN4TF9lTWZvTjBvdE1pM25ZdkdremNJZHdNLW9yWUY2eHdG M1BPR1A0REkmYW1wO2U9IiBjbGFzcz0iIj5odHRwczovL2R4ci5tb3ppbGxhLm9yZy9tb3ppbGxh LWNlbnRyYWwvc291cmNlL3NlY3VyaXR5L25zcy9saWIvc3NsL3NzbGltcGwuaCMzNzc8L2E+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj5JbiBhIHN5c3RlbSBsaWtlIHRoaXMsIHRoZXJlJ3Mgbm90aGluZyBzdG9w cGluZyB0aGUgYm9keSBmcm9tIGJlaW5nIDQtYnl0ZSBhbGlnbmVkLCB3aGF0ZXZlciB0aGUgYWxp Z25tZW50IG9mIHRoZSBoZWFkZXIgaXMuIEknZCBiZSBpbnRlcmVzdGVkIGluIGhlYXJpbmc8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+YWJvdXQgdGhlIGRlc2lnbiB5b3UgaGF2ZSBpbiBtaW5kLjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+LUVr cjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxiciBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBUdWUsIE5vdiAxNywgMjAxNSBhdCAxMjo1OSBQTSwg U2hvcnQsIFRvZGQgPHNwYW4gZGlyPSJsdHIiIGNsYXNzPSIiPg0KJmx0OzxhIGhyZWY9Im1haWx0 bzp0c2hvcnRAYWthbWFpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPnRzaG9ydEBha2Ft YWkuY29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIGNs YXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFw eCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOmJy ZWFrLXdvcmQiIGNsYXNzPSIiPkkgd291bGQgc2F5IHRoYXQgMzItYml0cyB3b3VsZCBiZSBvcHRp bWFsLCBzaW5jZSB0aGF0IGlzIHRoZSB0eXBpY2FsIHdvcmQtc2l6ZSBvZiBwcm9jZXNzb3JzIHRo YXQgbmVlZCBhbGlnbm1lbnQuIDItYnl0ZXMgaXNu4oCZdCBtdWNoIGJldHRlciB0aGFuIDUtYnl0 ZXMgaW4gdGhpcyByZWdhcmQuPHNwYW4gY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgc3R5bGU9ImxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0 YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6 IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsiIGNsYXNz PSIiPg0KPGRpdiBzdHlsZT0ibGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3Rh cnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTog bm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyIgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPi0tPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPi1Ub2RkIFNob3J0PC9k aXY+DQo8ZGl2IGNsYXNzPSIiPi8vIDxhIGhyZWY9Im1haWx0bzp0c2hvcnRAYWthbWFpLmNvbSIg dGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPnRzaG9ydEBha2FtYWkuY29tPC9hPjwvZGl2Pg0KPGRp diBjbGFzcz0iIj4vLyAmcXVvdDtPbmUgaWYgYnkgbGFuZCwgdHdvIGlmIGJ5IHNlYSwgdGhyZWUg aWYgYnkgdGhlIEludGVybmV0LiZxdW90OzwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PGJyIGNsYXNzPSIiPg0KPC9zcGFuPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9Img1Ij4N CjxkaXYgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+T24gTm92IDE3LCAyMDE1LCBhdCAzOjQ1IFBNLCBEYW5pZWwgS2FobiBHaWxsbW9y ICZsdDs8YSBocmVmPSJtYWlsdG86ZGtnQGZpZnRoaG9yc2VtYW4ubmV0IiB0YXJnZXQ9Il9ibGFu ayIgY2xhc3M9IiI+ZGtnQGZpZnRoaG9yc2VtYW4ubmV0PC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8 YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIFR1ZSAyMDE1LTExLTE3IDEyOjA5OjMwIC0w NTAwLCBFcmljIFJlc2NvcmxhIHdyb3RlOjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiIGNsYXNzPSIiPlRoZSBjb25jZXJuIGhlcmUgaXMgYmFja3dhcmQgY29tcGF0aWJpbGl0 eSB3aXRoIGluc3BlY3Rpb24gbWlkZGxlYm94ZXMgd2hpY2g8YnIgY2xhc3M9IiI+DQpleHBlY3Qg dGhlIGxlbmd0aCBmaWVsZCB0byBiZSBpbiBhIHBhcnRpY3VsYXIgcGxhY2UuIFdlIGFncmVlZCBp biBTZWF0dGxlIHRvPGJyIGNsYXNzPSIiPg0Kd2FpdCBmb3IgZWFybHkgZGVwbG95bWVudCBleHBl cmllbmNlIGJlZm9yZSBtb2RpZnlpbmcgdGhlIGhlYWRlciB0byBtb3ZlPGJyIGNsYXNzPSIiPg0K dGhlIGxlbmd0aC48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpJ biBwYXJ0aWN1bGFyLCBpZiB3ZSdyZSBnb2luZyB0byBtYWtlIGEgY2hhbmdlIHRvIHRoZSBUTFMg cmVjb3JkIGhlYWRlciw8YnIgY2xhc3M9IiI+DQp0aGUgY2hhbmdlIHdvdWxkIGJlIHRvIHJlbW92 ZSB0aGUgdmVyc2lvbiBhbmQgdGhlIHR5cGUgZW50aXJlbHksIGxlYXZpbmc8YnIgY2xhc3M9IiI+ DQpvbmx5IHR3byBvY3RldHMgb2YgbGVuZ3RoIG9uIGVhY2ggcmVjb3JkLiZuYnNwOyBJcyBhIHR3 by1vY3RldCBvZmZzZXQgZ29pbmc8YnIgY2xhc3M9IiI+DQp0byBiZSBwcm9ibGVtYXRpYz88YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDstLWRrZzxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_75C621A0AAFB4BB9995817864699C2C7akamaicom_-- From nobody Tue Nov 17 13:29:32 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0321A8955 for ; Tue, 17 Nov 2015 13:29:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 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, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5RtedloBJGh for ; Tue, 17 Nov 2015 13:29:28 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 774B01A8957 for ; Tue, 17 Nov 2015 13:29:28 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id F1D1D425330; Tue, 17 Nov 2015 21:29:27 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id D78EB4EBC3; Tue, 17 Nov 2015 21:29:27 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1447795767; bh=+OS80JUN/AnXQdU7JRyEju5kZ6vwg848E/HduXZg8MM=; l=4320; h=From:To:CC:Date:References:In-Reply-To:From; b=OHKjxfFFCAabZAAiDSYrM+gf0uIigh3Oaj1Ckl9ZG3kIVlqaswJVe/Tep1hWGfxOy K7uwP1GKQ/TeTOoPfdyDTopeoEiP30VlxVlgqq0n27ZZP36wIUb8q7NmOXuCE4uhkD FEeH5o6e5Pn25Wx6gqwTj2co/RL7npnH+iSmZGfY= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.34]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id D4A1A2044; Tue, 17 Nov 2015 21:29:27 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 17 Nov 2015 13:29:27 -0800 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1076.000; Tue, 17 Nov 2015 16:29:27 -0500 From: "Salz, Rich" To: Eric Rescorla , Joe Salowey Thread-Topic: [TLS] PR#345: IANA Considerations Thread-Index: AQHRIMT8CS9oUKnbLUaF4RPUQ/eAPJ6fnJAAgAD1swCAAAuxAIAABB+AgAAfHYCAABJHAP//6JnA Date: Tue, 17 Nov 2015 21:29:26 +0000 Message-ID: References: <7276DA5B-0563-4D70-A611-96A2E80CAECB@tableau.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.133] Content-Type: multipart/alternative; boundary="_000_ee328a0f34a94cd3979833a1bb6ca5f6usma1exdag1mb1msgcorpak_" MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR#345: IANA Considerations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 21:29:30 -0000 --_000_ee328a0f34a94cd3979833a1bb6ca5f6usma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBwcmVmZXIgdG8gc2VlIHR3byBjYXRlZ29yaWVzOiAgcmVjb21tZW5kZWQgYW5kIOKAnG5vIGNv bW1lbnTigJ0NCk1VU1Qgb3IgU0hPVUxEIGFyZSByZWNvbW1lbmRlZCBhbmQgZXZlcnl0aGluZyBl bHNlIGlzIOKAnG5vIGNvbW1lbnTigJ0NCkhhdmluZyBvbmUgcG9vbCwgZnJvbSB3aGljaCB3ZSBj YW4gY2hlcnJ5LXBpY2ssIGFzIG9wcG9zZWQgdG8gZmluZXIgbGV2ZWxzIG9mIGdyYWRhdGlvbiwg c2VlbXMgc2ltcGxlci4gIElmIGFuZCB3aGVuIHdl4oCZcmUgcmVhZHkgdG8gbW92ZSBHb2xkaWxv Y2tzLzQ0OCB0byByZWNvbW1lbmRlZCwgaXQgd2lsbCBub3QgbWF0dGVyIHRoYXQgaXTigJlzIGlu IHRoZSBzYW1lIHBpbGUgYXMgM0RFUy1DQkMuDQoNCg== --_000_ee328a0f34a94cd3979833a1bb6ca5f6usma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgcHJlZmVyIHRvIHNlZSB0d28gY2F0ZWdv cmllczombmJzcDsgcmVjb21tZW5kZWQgYW5kIOKAnG5vIGNvbW1lbnTigJ08bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+TVVTVCBvciBTSE9VTEQgYXJlIHJlY29tbWVuZGVkIGFuZCBldmVyeXRoaW5nIGVsc2Ug aXMg4oCcbm8gY29tbWVudOKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IYXZpbmcgb25lIHBvb2wsIGZy b20gd2hpY2ggd2UgY2FuIGNoZXJyeS1waWNrLCBhcyBvcHBvc2VkIHRvIGZpbmVyIGxldmVscyBv ZiBncmFkYXRpb24sIHNlZW1zIHNpbXBsZXIuJm5ic3A7IElmIGFuZCB3aGVuIHdl4oCZcmUgcmVh ZHkgdG8gbW92ZSBHb2xkaWxvY2tzLzQ0OCB0byByZWNvbW1lbmRlZCwNCiBpdCB3aWxsIG5vdCBt YXR0ZXIgdGhhdCBpdOKAmXMgaW4gdGhlIHNhbWUgcGlsZSBhcyAzREVTLUNCQy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_ee328a0f34a94cd3979833a1bb6ca5f6usma1exdag1mb1msgcorpak_-- From nobody Tue Nov 17 13:53: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 0E49E1B3165 for ; Tue, 17 Nov 2015 13:53:00 -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 eywcv72c8Ph5 for ; Tue, 17 Nov 2015 13:52:58 -0800 (PST) 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 0F8A61B3166 for ; Tue, 17 Nov 2015 13:52:57 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 33030284D23; Tue, 17 Nov 2015 21:52:56 +0000 (UTC) Date: Tue, 17 Nov 2015 21:52:56 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20151117215255.GO18315@mournblade.imrryr.org> References: <87egfoe4n2.fsf@alice.fifthhorseman.net> <75C621A0-AAFB-4BB9-9958-17864699C2C7@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <75C621A0-AAFB-4BB9-9958-17864699C2C7@akamai.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Record header size? 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 Nov 2015 21:53:00 -0000 On Tue, Nov 17, 2015 at 09:26:57PM +0000, Short, Todd wrote: > Embedded systems don�t have the luxury of mbuf-type of buffer scheme (as > you describe for NSS). Many have ethernet-frame sized buffers in > locked/pinned memory that read in a whole ethernet frame, and then strip > off headers by advancing pointers into the frame. This minimizes copies, > and the goal is to have a zero-copy network stack. Right, both IP and TCP add padding after options to align the payload on a 32-bit boundary. So the TLS record layer always starts at a 32-bit aligned address, which ensures that the record payload is always misaligned. Padding the record header with zeros to the next multiple of 32-bits could plausibly improve the performance of bare-metal zero-copy implementations. -- Viktor. From nobody Tue Nov 17 17:32: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 C452D1B36F4 for ; Tue, 17 Nov 2015 17:32:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.785 X-Spam-Level: X-Spam-Status: No, score=-4.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsLcVDH72IVw for ; Tue, 17 Nov 2015 17:32:38 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E246C1B36F2 for ; Tue, 17 Nov 2015 17:32:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1447810358; x=1479346358; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=28gWZrrzZkOT8AbJdOhi+HjFxRPoT3CQjtBEjIJZHXM=; b=nYyHdPC5wS3bkoOVClwUmaIlFhle/Cd4vMSaGPbHqnRDw5w5i57Eqlbz nbpWKQFYMitTEMJC4rtD+Eq0qurLzkBrPMoDYwU0nZ33OUAcKAOFskJCB +kUg2/gPdp5S6OBfDN1/eBBqR5n43CXg/5vUsM6y61429J3sqfacNRpYe 4T6fK0RwprQFhAQfTfrp4J57yl3OM7PHq2jweOL83+IKNQ4mhSfg86BSM /Xz3+5caXwZzP2T9oO2+TbH5nrxkLGcp0EJU+OiDTtQCh7/GAJDix9buC OPpgjv+P8Toytyfv46CWuvWdsE7U9BcY2WsTjbfQSx+d1gUJdg1/h/XDm g==; X-IronPort-AV: E=Sophos;i="5.20,310,1444647600"; d="scan'208";a="54717195" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 18 Nov 2015 14:32:23 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.51]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Wed, 18 Nov 2015 14:32:23 +1300 From: Peter Gutmann To: Eric Rescorla , "Short, Todd" Thread-Topic: [TLS] Record header size? Thread-Index: AQHRIUwqo2PzkmG0m02LaFyKO+3dU56fmOsAgAFmVoQ= Date: Wed, 18 Nov 2015 01:32:22 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B679E6@uxcn10-5.UoA.auckland.ac.nz> References: , In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Record header size? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 01:32:42 -0000 Eric Rescorla writes:=0A= =0A= >The concern here is backward compatibility with inspection middleboxes whi= ch=0A= >expect the length field to be in a particular place.=0A= =0A= Given that the rest of TLS 1.3 is going to break compatibility with pretty= =0A= much everything everywhere, I can't see this as a big concern, may as well = fix=0A= it at the same time as everything else is being changed.=0A= =0A= Peter.=0A= =0A= From nobody Tue Nov 17 17:41: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 0A4A81B371C for ; Tue, 17 Nov 2015 17:41:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.785 X-Spam-Level: X-Spam-Status: No, score=-4.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tE2BgkrwcOhZ for ; Tue, 17 Nov 2015 17:41:35 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66B151B371D for ; Tue, 17 Nov 2015 17:41:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1447810895; x=1479346895; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=cMaKKJD5LLuIbRBNQKtxUddAfHF2n36ZwRufmNC57aE=; b=fAfu02ar4zbo4F1i8yaxbUwQNJIwLxiGETEcwoWx7AyiDZVa0R4tFfdC t6TsiXOPPwVVIgzlpelqRe4asTk1WRbq6kArz17c1pYqcHi9mRpWJg6Dx EX0uU7fVzTy6ZL9g0HzmdU+sZ9U8gfyjVct4trwcktZIkKybSDKCzsSj8 rUHWswFbcMGXKow8S7Bg+jWWUnA96Na/EDIvzerJJTUqqJl9vspA1Zqyu qUpxWpiOnHp6OQE7xl+OV9X6yhmPAcrro2onKjNcynwKUS74jgaLX+eRj kUMjemmUmp4eQ5tjTqZClgZyL+/Emqq3GDCt1lO3fstfp5KG4YhSzjbrJ w==; X-IronPort-AV: E=Sophos;i="5.20,310,1444647600"; d="scan'208";a="54718921" 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 mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 18 Nov 2015 14:41:33 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.51]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Wed, 18 Nov 2015 14:41:34 +1300 From: Peter Gutmann To: "Short, Todd" , Eric Rescorla Thread-Topic: [TLS] Record header size? Thread-Index: AQHRIUwqo2PzkmG0m02LaFyKO+3dU56fmOsAgAA8dYCAAAO3gIAAAuyAgAAE1oCAASBNww== Date: Wed, 18 Nov 2015 01:41:32 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B679F9@uxcn10-5.UoA.auckland.ac.nz> References: <87egfoe4n2.fsf@alice.fifthhorseman.net> , <75C621A0-AAFB-4BB9-9958-17864699C2C7@akamai.com> In-Reply-To: <75C621A0-AAFB-4BB9-9958-17864699C2C7@akamai.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Record header size? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 01:41:37 -0000 Short, Todd writes:=0A= =0A= >To be honest, it=92s always kinda bugged me that SSL/TLS uses a 5-byte hea= der,=0A= >coming from my embedded network system background.=0A= >=0A= >[...]=0A= =0A= +1. I wrote about this problem years ago in "Performance Characteristics o= f=0A= Application-level Security Protocols",=0A= https://www.cs.auckland.ac.nz/~pgut001/pubs/app_sec.pdf, see the section=0A= "Interaction with Encryption Hardware" for more. It doesn't name any names= =0A= since I could only use public sources, but was based on discussions with=0A= hardware vendors.=0A= =0A= Mind you, TLS is almost pleasant compared to the crazy calisthenics you hav= e=0A= to go through to deal with SSH data. You basically can't do SSH's crypto= =0A= efficiently...=0A= =0A= Peter.=0A= =0A= =0A= =0A= From nobody Tue Nov 17 20:30: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 A75591AC439 for ; Tue, 17 Nov 2015 20:30:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOMGeTu3huob for ; Tue, 17 Nov 2015 20:30:29 -0800 (PST) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FC671AC434 for ; Tue, 17 Nov 2015 20:30:29 -0800 (PST) Received: by ykdv3 with SMTP id v3so44865408ykd.0 for ; Tue, 17 Nov 2015 20:30:28 -0800 (PST) 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=L8/AdjkOqSfnVsczP+E0xgf9bsZXZMdf/aRarqf6Zv8=; b=LKjzfRCXL1mJOEk6mOU+yUe6GggUgQCpfrZu9yzqUehzGUzlUdFWnuf5sU1gt7MXIF r39ARwZY0jC1omz/5llfFzXXQ6AXyAbf9AwNSGP5uAPyaY8nlM4OY8SDs4mEg8YwRSqD EDZ1fqyYD1z2aNrUN40PAAeNGpCdDWHdZdJZnPw6Kh+EZFXqs/6q/2bfzK60o5pR5g49 EurvW7DUkGeV4JMHJfsXwOGeUI/OfssV2W8ntIV2C9uF4TCR1D/pqLORYbaEhHmgeoTz 70oWx9CYp5EgOpxTQCzDj9OdC51TTem7C+dl9b2Tolb3S83uMxZv0mJZMO2zAnQTB0xn G/3Q== X-Received: by 10.129.157.70 with SMTP id u67mr5213754ywg.160.1447821028590; Tue, 17 Nov 2015 20:30:28 -0800 (PST) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id c5sm1233076ywf.12.2015.11.17.20.30.27 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 17 Nov 2015 20:30:28 -0800 (PST) From: Dave Garrett To: tls@ietf.org, Ilari Liusvaara , Viktor Dukhovni Date: Tue, 17 Nov 2015 23:30:25 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20151117190651.GJ18315@mournblade.imrryr.org> <20151117191400.GA11869@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20151117191400.GA11869@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201511172330.26480.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] PR#345: IANA Considerations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 04:30:30 -0000 On Tuesday, November 17, 2015 02:14:00 pm Ilari Liusvaara wrote: > All current registered/proposed ciphersuites that work in TLS 1.3 are > *-GCM or *-POLY1305 ones (with DHE or ECDHE). DHE AES CCM is still in the list, even after the changes in the current proposal. ECDHE AES CCM is not as it's not standards track. There's an argument that it should be promoted alongside ECDHE AES GCM, however we're not really recommending CCM so that's probably not desired (and I don't know if it has had enough use to be considered recommended). There will likely also be AES OCB, at some point. On Tuesday, November 17, 2015 02:17:05 pm Viktor Dukhovni wrote: > I'm well aware of that, I'm just wondering whether the "Recommended" > column should cover recommendations for TLS 1.2 as well TLS 1.3? Yes. The following is in the backwards compatibility appendix in the current draft: "If an implementation negotiates use of TLS 1.2, then negotiation of cipher suites also supported by TLS 1.3 SHOULD be preferred, if available." At the end of the day, though, it's just a qualified "SHOULD". We're just talking recommendations. This isn't a diediedie RFC. Dave From nobody Wed Nov 18 01:08: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 718301B2A86 for ; Wed, 18 Nov 2015 01:08:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42tKxfx_lLb9 for ; Wed, 18 Nov 2015 01:08:05 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 DAF741B2A8D for ; Wed, 18 Nov 2015 01:08:03 -0800 (PST) Received: by wmec201 with SMTP id c201so63165029wme.1 for ; Wed, 18 Nov 2015 01:08:02 -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 :content-transfer-encoding:message-id:references:to; bh=j7c3MwFcBrlE9w8g5w2/GwpAH65sagvX8G2lqMw7TyU=; b=Vf9Axg2rqOZLSyklrc1bwqWeoxzjn6owQE0YTumlmRx4e/RrvdDNp0vyB0cFAfhBVh VDlcoboB97jUTh1Yv9o1CUQGUI6Ym6Fb9Iw0ie5U5psbfMSATY8uIxWKenalhp3eqJLD ZWInXkQDoeQU1xDeETnFppSSljD9LVljOA9JFnU3u9AyzyNvfDTR0jv+9scIZWtnyksq jRVjUcBtrTRC7MkDzuFQUNfCX0ICnisSXLUA6435RYteKAodzpaoKcLWJ96f8HFLr2Bu BfHyv/KkWQMxzgbNPRPru0reXzcyjPNwE8qht+M2kVaCcH6DEsmglzl3ZKUtcSDzjf2m JCPg== X-Received: by 10.28.178.4 with SMTP id b4mr2837194wmf.46.1447837682535; Wed, 18 Nov 2015 01:08:02 -0800 (PST) Received: from [192.168.6.116] (bzq-28-168-31-169.red.bezeqint.net. [31.168.28.169]) by smtp.gmail.com with ESMTPSA id w67sm2199706wmw.17.2015.11.18.01.08.01 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Nov 2015 01:08:01 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Yoav Nir In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B679E6@uxcn10-5.UoA.auckland.ac.nz> Date: Wed, 18 Nov 2015 11:07:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9A043F3CF02CD34C8E74AC1594475C73F4B679E6@uxcn10-5.UoA.auckland.ac.nz> To: Peter Gutmann X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Record header size? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 09:08:07 -0000 > On 18 Nov 2015, at 3:32 AM, Peter Gutmann = wrote: >=20 > Eric Rescorla writes: >=20 >> The concern here is backward compatibility with inspection = middleboxes which >> expect the length field to be in a particular place. >=20 > Given that the rest of TLS 1.3 is going to break compatibility with = pretty > much everything everywhere, I can't see this as a big concern, may as = well fix > it at the same time as everything else is being changed. >=20 Stateful firewalls tend to pass only what they understand. They use some = measures to avoid tunneling and passing things that are not HTTPS over = TCP port 443. To achieve this, they run sanity checks on the traffic. They try to = strike a balance between not getting circumvented and not dropping = legitimate traffic. Sometimes they get it wrong. Sometimes they block = legitimate but surprising stuff. As an example from 15 years ago, when = Mac OS 9.2 came out, it sent data on the third packet of TCP (the ACK - = last of the handshake packets). This is allowed by RFC, but was not done = by any other platform. This failed the sanity checks of some firewalls, = causing that traffic to be blocked. Two results of this event: we fixed = our firewalls, but nobody (including Apple) does that anymore. A sanity check on TLS might involve validating 5-byte record headers = with sane length and version fields. A firewall might be out there that = verifies this. This is the kind of thing that might be missed in = testing, and we=E2=80=99ll only find out when some brave soul deploys = TLS 1.3 in Chrome only to find out that it is blocked in 3% of the = Internet. Yoav From nobody Wed Nov 18 04:44: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 2E2451A1A6D for ; Wed, 18 Nov 2015 04:44:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.286 X-Spam-Level: X-Spam-Status: No, score=-3.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rNnVZLFqYkyI for ; Wed, 18 Nov 2015 04:44:24 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0D71A1A68 for ; Wed, 18 Nov 2015 04:44:23 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 4D6AA200014; Wed, 18 Nov 2015 12:44:23 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 2DB27200011; Wed, 18 Nov 2015 12:44:23 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1447850663; bh=8KqCN6ahnTId7wKAqr0NtbRZMrnT8+H4tj7ELbkxajo=; l=2963; h=From:To:CC:Date:References:In-Reply-To:From; b=pVYHnuyOp+h/Fi/EabdT+QZAmR0/4w7vDTIRThe1V6cxjJAH053RLwYHz+yYOcnf2 r/03lRIZWCds62AI3dXbLBbsUnjWsVn3M7bumsEBjYhCdfaMKMnd8wv0YR6dVxqphj aWODmv7TVHNrrTqorudGyw/+/Si/2VPsX3365CXo= Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 139F81E080; Wed, 18 Nov 2015 12:44:23 +0000 (GMT) Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 18 Nov 2015 07:44:22 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1076.000; Wed, 18 Nov 2015 07:44:22 -0500 From: "Short, Todd" To: Yoav Nir Thread-Topic: [TLS] Record header size? Thread-Index: AQHRIUwqfC6IjHws+EWK+zLpB/KhZp6gxqoAgACMgACAAH9MgP//6KPC Date: Wed, 18 Nov 2015 12:44:21 +0000 Message-ID: <29BB82B3-9E74-46F0-A2C6-9A5D8143DA07@akamai.com> References: <9A043F3CF02CD34C8E74AC1594475C73F4B679E6@uxcn10-5.UoA.auckland.ac.nz>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Record header size? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 12:44:26 -0000 DPI, admittedly, is an expensive process that slows down traffic. DPI is ev= en more expensive on a protocol such as TLS where the record headers aren't= always in the same place in every packet. DPI is usually off by default on= most firewalls.=20 The problem you are more likely to encounter are TLS interception proxies t= hat end up using only TLSv1.0 to authenticate a connection.=20 Having this controlled by a TLS extension would at least give the client a = modicum of control. (Oops, connection failed, let's try it again with a 3.1= -compatible header.) Also, having the "major" version number be 4, should indicate to these DPI = engines that this is a new version of TLS, and should use new code or be ig= nored. Heck, the version in the handshake should be indicative of this. I think the philosophy some people are going with, if we're going to break = backwards compatibility, let's do it big time, so that we only have to do i= t once, and not make everyone play continuous catchup.=20 -- -Todd Short // tshort@akamai.com // "One if by land, two if by sea, three if by the Internet." > On Nov 18, 2015, at 4:09 AM, Yoav Nir wrote: >=20 >=20 >> On 18 Nov 2015, at 3:32 AM, Peter Gutmann wr= ote: >>=20 >> Eric Rescorla writes: >>=20 >>> The concern here is backward compatibility with inspection middleboxes = which >>> expect the length field to be in a particular place. >>=20 >> Given that the rest of TLS 1.3 is going to break compatibility with pret= ty >> much everything everywhere, I can't see this as a big concern, may as we= ll fix >> it at the same time as everything else is being changed. >=20 > Stateful firewalls tend to pass only what they understand. They use some = measures to avoid tunneling and passing things that are not HTTPS over TCP = port 443. >=20 > To achieve this, they run sanity checks on the traffic. They try to strik= e a balance between not getting circumvented and not dropping legitimate tr= affic. Sometimes they get it wrong. Sometimes they block legitimate but sur= prising stuff. As an example from 15 years ago, when Mac OS 9.2 came out, i= t sent data on the third packet of TCP (the ACK - last of the handshake pac= kets). This is allowed by RFC, but was not done by any other platform. This= failed the sanity checks of some firewalls, causing that traffic to be blo= cked. Two results of this event: we fixed our firewalls, but nobody (includ= ing Apple) does that anymore. >=20 > A sanity check on TLS might involve validating 5-byte record headers with= sane length and version fields. A firewall might be out there that verifie= s this. This is the kind of thing that might be missed in testing, and we= =92ll only find out when some brave soul deploys TLS 1.3 in Chrome only to = find out that it is blocked in 3% of the Internet. >=20 > Yoav >=20 >=20 From nobody Wed Nov 18 05:10: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 4C00A1A8850 for ; Wed, 18 Nov 2015 05:10:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.886 X-Spam-Level: X-Spam-Status: No, score=-4.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAY5PiUAomod for ; Wed, 18 Nov 2015 05:10:52 -0800 (PST) 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 6A9021A87F0 for ; Wed, 18 Nov 2015 05:10:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A84FDBE58 for ; Wed, 18 Nov 2015 13:10:50 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pt6HL_Z5WpI4 for ; Wed, 18 Nov 2015 13:10:50 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B326DBE4D for ; Wed, 18 Nov 2015 13:10:49 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1447852250; bh=U5CvhlNFrPXhLIzNh4S+VKgCRh/aER7tvhLBq5LOmNE=; h=To:From:Subject:Date:From; b=pOHVyyEUHfFK68SLeuFD2zJck2no4k5kNasShTO4CWWtEe5PkW9hzj50oVM13Dm5k AU/hwKVq6XlBCRD2njJU8xSIBYJZ7hdw4C21SdRUmJsJ8cGUPAu76ChTvidQacvszp ZvrByu6liv485GGEDb3TGdsjUfYxQELmAP01oGzY= To: "tls@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <564C78D8.1080409@cs.tcd.ie> Date: Wed, 18 Nov 2015 13:10:48 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [TLS] TRON submission in 2 weeks... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 13:10:54 -0000 Just a reminder that the TRON workshop [1] initial submission date is December 1st. Please get your good submissions in! (Or hassle folks you know who should be submitting:-) Thanks, S. [1] https://www.internetsociety.org/events/ndss-symposium-2016/tron-workshop-call-papers From nobody Wed Nov 18 07:24: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 B40301B3235 for ; Wed, 18 Nov 2015 07:24:25 -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 VtQ_E8dJMI06 for ; Wed, 18 Nov 2015 07:24:24 -0800 (PST) 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 B33B61B3233 for ; Wed, 18 Nov 2015 07:24:23 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 6542328494E; Wed, 18 Nov 2015 15:24:22 +0000 (UTC) Date: Wed, 18 Nov 2015 15:24:22 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20151118152422.GS18315@mournblade.imrryr.org> References: <9A043F3CF02CD34C8E74AC1594475C73F4B679E6@uxcn10-5.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Record header size? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 15:24:25 -0000 On Wed, Nov 18, 2015 at 11:07:59AM +0200, Yoav Nir wrote: > Stateful firewalls tend to pass only what they understand. They use some measures to avoid tunneling and passing things that are not HTTPS over TCP port 443. > If the record layer header for application-data (not the initial handshak), is simply expanded by 3 bytes to 8 (zero padded), and the padding is included in the record length, then to legacy parsers it looks like a 5 byte header with payload that's 3 bytes longer. While implementations aware of the change will treat this as a new format in which the recorder header is 8 bytes and always overstates the payload length by 3. The real payload can then be properly aligned. -- Viktor. From nobody Wed Nov 18 07:30: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 CD1F61A8AA1 for ; Wed, 18 Nov 2015 07:30:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 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, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YF6xf0S0T6fV for ; Wed, 18 Nov 2015 07:30:06 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 235C11B3280 for ; Wed, 18 Nov 2015 07:30:06 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 48A824DCA0 for ; Wed, 18 Nov 2015 15:30:05 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 2AE354DDBA for ; Wed, 18 Nov 2015 15:30:05 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1447860605; bh=nrcNpjP4BsTa1HzkTW0MP3xAOgdDAK3M2krlLYnmvAA=; l=5144; h=From:To:Date:References:In-Reply-To:From; b=qDv6h/ikQH3YSz9LqdsRl8mMxN58zehYi4qvQQeXipx1RzEYxmjZFXzC+jb8IY5wn 0HZRtGfjQOzGHQ30xIadODQuzuF1dG3Qq4ZgUx/eVPjs8n2GH5KuuZNor0Bm6TTVxS BEmtmL8ObumJuVVojE2m0w+XwnZH2qCcvbqupTyE= Received: from email.msg.corp.akamai.com (usma1ex-casadmn.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 285202071 for ; Wed, 18 Nov 2015 15:30:05 +0000 (GMT) Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 18 Nov 2015 10:30:04 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1076.000; Wed, 18 Nov 2015 10:30:04 -0500 From: "Short, Todd" To: "tls@ietf.org" Thread-Topic: [TLS] Record header size? Thread-Index: AQHRIUwqfC6IjHws+EWK+zLpB/KhZp6gxqoAgACMgACAAH9MgIAAaSkAgAABl4A= Date: Wed, 18 Nov 2015 15:30:04 +0000 Message-ID: <2729A4D5-FA80-4902-8F9F-CDDD56E094CD@akamai.com> References: <9A043F3CF02CD34C8E74AC1594475C73F4B679E6@uxcn10-5.UoA.auckland.ac.nz> <20151118152422.GS18315@mournblade.imrryr.org> In-Reply-To: <20151118152422.GS18315@mournblade.imrryr.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.40.72] Content-Type: multipart/alternative; boundary="_000_2729A4D5FA8049028F9FCDDD56E094CDakamaicom_" MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Record header size? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 15:30:10 -0000 --_000_2729A4D5FA8049028F9FCDDD56E094CDakamaicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, that is true, and would accomplish the goals of backwards compatibilit= y along with keeping (at least) 32-bit alignment. Part of my non-stated goal was to also shrink the header, but *shrug*. I still like the idea of marking it with a different version number (8.0)? -- -Todd Short // tshort@akamai.com // "One if by land, two if by sea, three if by the Internet." On Nov 18, 2015, at 10:24 AM, Viktor Dukhovni > wrote: On Wed, Nov 18, 2015 at 11:07:59AM +0200, Yoav Nir wrote: Stateful firewalls tend to pass only what they understand. They use some me= asures to avoid tunneling and passing things that are not HTTPS over TCP po= rt 443. If the record layer header for application-data (not the initial handshak), is simply expanded by 3 bytes to 8 (zero padded), and the padding is included in the record length, then to legacy parsers it looks like a 5 byte header with payload that's 3 bytes longer. While implementations aware of the change will treat this as a new format in which the recorder header is 8 bytes and always overstates the payload length by 3. The real payload can then be properly aligned. -- Viktor. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --_000_2729A4D5FA8049028F9FCDDD56E094CDakamaicom_ Content-Type: text/html; charset="us-ascii" Content-ID: <7ADE9F504A0B924E9417464E76EFB662@akamai.com> Content-Transfer-Encoding: quoted-printable Yes, that is true, and would accomplish the goals of backwards compatibilit= y along with keeping (at least) 32-bit alignment.
Part of my non-stated goal was to also shrink the header, b= ut *shrug*.

I still like the idea of marking it with a different versio= n number (8.0)?
--
-Todd Short
// tshort@a= kamai.com
// "One if by land, two if by sea, three if by the Int= ernet."

On Nov 18, 2015, at 10:24 AM, Viktor Dukhovni <ietf-dane@dukhovni.org>= ; wrote:

On Wed, Nov 18, 2015 at 11:07:59AM +0200, Yoav Nir wrot= e:

Stateful firewalls tend to pass only w= hat they understand. They use some measures to avoid tunneling and passing = things that are not HTTPS over TCP port 443.


If the record layer header for application-data (not the initial
handshak), is simply expanded by 3 bytes to 8 (zero padded), and
the padding is included in the record length, then to legacy parsers
it looks like a 5 byte header with payload that's 3 bytes longer.
While implementations aware of the change will treat this as a new
format in which the recorder header is 8 bytes and always overstates
the payload length by 3.

The real payload can then be properly aligned.

--
Viktor.

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

--_000_2729A4D5FA8049028F9FCDDD56E094CDakamaicom_-- From nobody Wed Nov 18 08:02: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 D7B801B3883 for ; Wed, 18 Nov 2015 08:02:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.486 X-Spam-Level: X-Spam-Status: No, score=-7.486 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2bU46DVCFVK for ; Wed, 18 Nov 2015 08:02:13 -0800 (PST) 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 0D95F1B3875 for ; Wed, 18 Nov 2015 08:02:13 -0800 (PST) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id C6E9442E5B4; Wed, 18 Nov 2015 16:02:12 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-119.brq.redhat.com [10.34.0.119]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tAIG2BVi020613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Nov 2015 11:02:12 -0500 From: Hubert Kario To: tls@ietf.org Date: Wed, 18 Nov 2015 17:02:05 +0100 Message-ID: <2128109.WVJJrpLvzj@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.9 (Linux/4.2.5-201.fc22.x86_64; KDE/4.14.13; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1523940.6XxssaO3MP"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: Subject: Re: [TLS] PR#345: IANA Considerations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 16:02:17 -0000 --nextPart1523940.6XxssaO3MP Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Monday 16 November 2015 15:16:50 Eric Rescorla wrote: > PR: https://github.com/tlswg/tls13-spec/pull/345 >=20 > Per discussion in Yokohama, I have rewritten the IANA considerations > section so that the 16-bit code spaces are "Specification Required" > and they have a "Recommended" column. >=20 > 1. The Cipher Suites "Recommended" column was populated based on > the Standards Track RFCs listed in the document (and I removed th= e > others). >=20 > 2. The Extensions "Recommended"column was populated by taking all > the Standards Track RFCs and marking them "Yes" and marking > others "No". I recognize that this probably marks a bunch of > extensions which we actually don't love as "Yes" (and perhaps others > as "No") and if people want to move some from one column to another, > that seems like a great mailing list discussion which I will let the > chairs drive. why max_fragment_length [RFC6066] is not to be supported in TLSv1.3? https://tools.ietf.org/html/draft-ietf-dice-profile-17#section-15 state= s=20 that this is a MUST for IoT TLS profile =2D-=20 Regards, Hubert Kario Senior 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 --nextPart1523940.6XxssaO3MP 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 iQIcBAABCgAGBQJWTKD9AAoJEJKo0bgB0vX1pQ8P/1TplsyJs9bX2M5/CPUaT9XX IWUunp91QENds7JPCSSRtkBaEgDk8uzpYCX+b8s6q+kfj8JM6abzaWdFOvuL1Z0t Mjd9NP0b81wCyGsFV6a9Oi+lm4GIGOhlcUD4gasuuBSSN3wlbRzfExZaYtVEwefN fInlPbhdpMSPjwD8DKPCAuGjuxH+8pNt8giRjYje+1t1f3XYs4Mw9lDfmqiyEh1K 5pO9LulDFWe/7ozp5Lo5OtAgrvShpuFgFVR8YTGtnTh+znkVhAQ3WjY2XUv9J/7z OYjAPb4bO5KAmRTFMjODasX6fHL2EFjztMQGKEDZXHNlmefBz4CmCKbflyZ74/A5 iA5GoFKP3XTFOB1pOaIwTAVNQwVDeAa/fs+ojpDVviDvBqXgjEBm4jkfwYHefqn6 2renfJ1PLJJK3exwWGFtBGNezIf0EDK/blLUrvvYwWPmU0EWAJOeYL47kFceZy3g fKksrHNWutGbRamtOby9dYl6DUgSRLI/Wg7syGDFhfZb+xw9f54HJBZdHrSchylv xYzAk1KtEG/GtA36kCJwQu4oClHQBTRn3QKAF8o4zvkrESAVrL3wMPap1ZEbwAUd OnEdYU0auVBZByxK5HhSeG+XBYtXZIW7TL98mljpFY5xw+qF+HV0TSqgauxWgbcS An8Ch7jGs6DWwVartUmW =bpyn -----END PGP SIGNATURE----- --nextPart1523940.6XxssaO3MP-- From nobody Wed Nov 18 08:35: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 E29CB1A1A7C for ; Wed, 18 Nov 2015 08:35:12 -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, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssWO6BRN1_hU for ; Wed, 18 Nov 2015 08:35:11 -0800 (PST) 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 7F71B1A1A77 for ; Wed, 18 Nov 2015 08:35:11 -0800 (PST) Received: by ykdr82 with SMTP id r82so72852274ykd.3 for ; Wed, 18 Nov 2015 08:35:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Bek4Wa+dQkHILnAcZ57ClnXzvNA7NrP+ePr4o6INxY0=; b=y5CDRnxtfEYskK+MII6xrhHc8hkkulUxLZC2hs43YXtuNKFpXk3Ho6+KlEsckl7Ctw EACfrje36aFjLNfoDZ/ttOcx4WQ7fDR4qI3pZqwSn0VyI4B0NwcvN+ImpYonzwvA+lVU EfdRZ5Te0ZsJ48lxGzeI5WLiQEDh4rxmyud1+gxKRrLBdFE06MiyzBri0RgwLrwLQcYa P/VmaTMnrNnfjzvpt6voXA0Q7igROH4J9K0oQwQz6kVCqBgOYlcRXnIuw9DfumxVngKs K0LeRHxNind+3xKZwIHmkud3852V9B6tC9yoN5WpWSpwFHA412OoZ2ISgSzXeT+BWkAB pmfA== 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=Bek4Wa+dQkHILnAcZ57ClnXzvNA7NrP+ePr4o6INxY0=; b=gyms38ZCJ/TR1SphV1bPjDKqZ9vRob2tp3xT1txfShye6SAYs16PW3IXxvBMiTCHq6 GA+mSzoc53FXRcQxnGivSQz672YQe22auRM6UuYIktLESmbqVm4sJpybkH1Zm6f0jkbK e9xQvcgifczQcLmNLNncTkkTTetn071dC1JlMjTu8b8fhUjMJDlf6+SpsfwhxMvUS1SV tBGDJY8aY8uQXHt2XEUlXqw1wN8tgQ37VLS1lYStg7HjETsE7Vbc7x4hnk/OVrCW7xYe 54Zy/Ejb9rMkG4CTLv5dNSqScu6F22tQvWpHYsz56x5S6+V55nlYk0RGDMZVzCOwWUBF c94g== X-Gm-Message-State: ALoCoQnY+v8iQf+keULw3ZqZwRATvD6+zPBupqMgoIl0OVv/TJUlUg5nDOz0uluI5dRFsa4VdckZ X-Received: by 10.13.218.198 with SMTP id c189mr3020386ywe.165.1447864510397; Wed, 18 Nov 2015 08:35:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.221.203 with HTTP; Wed, 18 Nov 2015 08:34:27 -0800 (PST) In-Reply-To: <2128109.WVJJrpLvzj@pintsize.usersys.redhat.com> References: <2128109.WVJJrpLvzj@pintsize.usersys.redhat.com> From: Eric Rescorla Date: Wed, 18 Nov 2015 08:34:27 -0800 Message-ID: To: Hubert Kario Content-Type: multipart/alternative; boundary=94eb2c08192ad367530524d33963 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR#345: IANA Considerations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 16:35:13 -0000 --94eb2c08192ad367530524d33963 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Nov 18, 2015 at 8:02 AM, Hubert Kario wrote: > On Monday 16 November 2015 15:16:50 Eric Rescorla wrote: > > PR: https://github.com/tlswg/tls13-spec/pull/345 > > > > Per discussion in Yokohama, I have rewritten the IANA considerations > > section so that the 16-bit code spaces are "Specification Required" > > and they have a "Recommended" column. > > > > 1. The Cipher Suites "Recommended" column was populated based on > > the Standards Track RFCs listed in the document (and I removed the > > others). > > > > > 2. The Extensions "Recommended"column was populated by taking all > > the Standards Track RFCs and marking them "Yes" and marking > > others "No". I recognize that this probably marks a bunch of > > extensions which we actually don't love as "Yes" (and perhaps others > > as "No") and if people want to move some from one column to another, > > that seems like a great mailing list discussion which I will let the > > chairs drive. > > why max_fragment_length [RFC6066] is not to be supported in TLSv1.3? > Pilot error. Send a PR or comment on the PR.. :) -Ekr > https://tools.ietf.org/html/draft-ietf-dice-profile-17#section-15 states > that this is a MUST for IoT TLS profile > > -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic --94eb2c08192ad367530524d33963 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Nov 18, 2015 at 8:02 AM, Hubert Kario <hkario@redhat.com&g= t; wrote:
On Mond= ay 16 November 2015 15:16:50 Eric Rescorla wrote:
> PR: https://github.com/tlswg/tls13-spec/pull/345
>
> Per discussion in Yokohama, I have rewritten the IANA considerations > section so that the 16-bit code spaces are "Specification Require= d"
> and they have a "Recommended" column.
>
> 1. The Cipher Suites "Recommended" column was populated base= d on
>=C2=A0 =C2=A0 =C2=A0the Standards Track RFCs listed in the document (an= d I removed the
> others).

>
> 2. The Extensions "Recommended"column was populated by takin= g all
>=C2=A0 =C2=A0 =C2=A0the Standards Track RFCs and marking them "Yes= " and marking
>=C2=A0 =C2=A0 =C2=A0others "No". I recognize that this probab= ly marks a bunch of
> extensions which we actually don't love as "Yes" (and pe= rhaps others
> as "No") and if people want to move some from one column to = another,
> that seems like a great mailing list discussion which I will let the > chairs drive.

why max_fragment_length [RFC6066] is not to be supported in TLSv1.3?=


https://tools.ietf.org/html/draft-i= etf-dice-profile-17#section-15 states
that this is a MUST for IoT TLS profile

--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic

--94eb2c08192ad367530524d33963-- From nobody Wed Nov 18 12:52: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 D671F1B2EA4 for ; Wed, 18 Nov 2015 12:52:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.151 X-Spam-Level: X-Spam-Status: No, score=-5.151 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 6SAjo8GZzjgQ for ; Wed, 18 Nov 2015 12:52:32 -0800 (PST) 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 246CA1B2EA7 for ; Wed, 18 Nov 2015 12:52:32 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 0D89344845; Wed, 18 Nov 2015 21:52:30 +0100 (CET) X-purgate-ID: 152705::1447879950-00001C04-2BF0D457/0/0 X-purgate-size: 2641 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id EEB1240F2B; Wed, 18 Nov 2015 21:52:29 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id E58841A380; Wed, 18 Nov 2015 21:52:29 +0100 (CET) In-Reply-To: To: Yoav Nir Date: Wed, 18 Nov 2015 21:52:29 +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: <20151118205229.E58841A380@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Record header size? 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, 18 Nov 2015 20:52:35 -0000 Yoav Nir wrote: >> Peter Gutmann wrote: >> >> Eric Rescorla writes: >>> >>> The concern here is backward compatibility with inspection middleboxes which >>> expect the length field to be in a particular place. >> >> Given that the rest of TLS 1.3 is going to break compatibility with pretty >> much everything everywhere, I can't see this as a big concern, may >> as well fix it at the same time as everything else is being changed. > > A sanity check on TLS might involve validating 5-byte record headers > with sane length and version fields. A firewall might be out there that > verifies this. The issue is much more about breaking _applications_ on top of TLS by changing the existing 5-byte record header. Padding the header to 8 bytes (3 bytes into the original record body) would be OK, though. With several TLS implementations it is possible to completely seperate network communication (of the application) from the processing of TLS records (performed by the TLS protocol stack). For some TLS implementations (e.g. Microsoft SChannel) this seems to be the only possible mode of operation. When I changed our (middlware SSL) application APIs from blocking to non-blocking communication semantics a few years ago, I also moved the entire network communication out to the middleware above the TLS protocol stack, and only _full_ TLS records will ever get passed to the TLS library. Everything that doesn't have the regular TLS record header will be unconditionally rejected by the middleware above the TLS implementation. I also use the content type to distinguish application data records from handshake records to properly manage the half-duplex TLS handshake and the resulting application-facing progress reporting. Any changes to the TLS record layer will push support for TLSv1.3 easily a decade into the future. Padding the TLS record header to 8 bytes should be OK and fully backwards compatible with such code, because the actual processing of the TLS record body happens inside the TLS implementation only. As far as alignment is concerned, some of the crypto hardware support (such as Intels AESNI) might need 16-byte alignment. Intel CPUs have load instructions to load 16-bytes aligned (MOVDQA) or unaligned (MOVDQU) into or between XMMx registers, and the amount of extra clock cycles depends on the severity of the "misalignment". https://software.intel.com/en-us/articles/reducing-the-impact-of-misaligned-memory-accesses https://software.intel.com/en-us/forums/watercooler-catchall/topic/304126 -Martin From nobody Wed Nov 18 18:07: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 772481B3B5C for ; Wed, 18 Nov 2015 18:07:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.784 X-Spam-Level: X-Spam-Status: No, score=-4.784 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTP4tazaf0l9 for ; Wed, 18 Nov 2015 18:07:50 -0800 (PST) Received: from e23smtp01.au.ibm.com (e23smtp01.au.ibm.com [202.81.31.143]) (using TLSv1 with cipher CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5AD41B3B57 for ; Wed, 18 Nov 2015 18:07:49 -0800 (PST) Received: from localhost by e23smtp01.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 19 Nov 2015 12:07:46 +1000 Received: from d23dlp01.au.ibm.com (202.81.31.203) by e23smtp01.au.ibm.com (202.81.31.207) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 19 Nov 2015 12:07:44 +1000 X-IBM-Helo: d23dlp01.au.ibm.com X-IBM-MailFrom: mickgray@au1.ibm.com X-IBM-RcptTo: tls@ietf.org Received: from d23relay10.au.ibm.com (d23relay10.au.ibm.com [9.190.26.77]) by d23dlp01.au.ibm.com (Postfix) with ESMTP id 25B7B2CE8052 for ; Thu, 19 Nov 2015 13:07:44 +1100 (EST) Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.235.139]) by d23relay10.au.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id tAJ27Zum64487546 for ; Thu, 19 Nov 2015 13:07:44 +1100 Received: from d23av04.au.ibm.com (localhost [127.0.0.1]) by d23av04.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id tAJ27BKE024973 for ; Thu, 19 Nov 2015 13:07:11 +1100 Received: from d50lp01.ny.us.ibm.com ([146.89.104.207]) by d23av04.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id tAJ2796g023242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 19 Nov 2015 13:07:10 +1100 Message-Id: <201511190207.tAJ2796g023242@d23av04.au.ibm.com> Received: from /spool/local by d50lp01.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 18 Nov 2015 21:06:11 -0500 Received: from smtp.notes.na.collabserv.com (192.155.248.73) by d50lp01.ny.us.ibm.com (158.87.18.20) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256/256) Wed, 18 Nov 2015 21:06:09 -0500 Received: from /spool/local by smtp.notes.na.collabserv.com with smtp.notes.na.collabserv.com ESMTP for from ; Thu, 19 Nov 2015 02:06:08 -0000 Received: from us1a3-smtp03.a3.dal06.isc4sb.com (10.106.154.94) by smtp.notes.na.collabserv.com (10.106.227.90) with smtp.notes.na.collabserv.com ESMTP; Thu, 19 Nov 2015 02:06:06 -0000 Received: from us1a3-mail68.a3.dal09.isc4sb.com ([10.142.3.220]) by us1a3-smtp03.a3.dal06.isc4sb.com with ESMTP id 2015111902064380-2333 ; Thu, 19 Nov 2015 02:06:43 +0000 In-Reply-To: <20151118205229.E58841A380@ld9781.wdf.sap.corp> To: mrex@sap.com From: "Michael Gray" Date: Thu, 19 Nov 2015 12:05:55 +1000 References: <20151118205229.E58841A380@ld9781.wdf.sap.corp> X-KeepSent: F65FC5AC:8F4DB61B-4A257F01:00732ED6; type=4; name=$KeepSent X-Mailer: IBM Notes Release 9.0.1SHF211 December 19, 2013 X-LLNOutbound: False X-Disclaimed: 18919 X-TNEFEvaluated: 1 Content-type: multipart/alternative; Boundary="0__=C5BBF592DFE0A8468f9e8a93df938690918cC5BBF592DFE0A846" Content-Disposition: inline x-cbid: 15111902-1618-0000-0000-0000032A1F1E X-IBM-ISS-SpamDetectors: Score=0.417846; BY=0; FL=0; FP=0; FZ=0; HX=0; KW=0; PH=0; SC=0.417846; ST=0; TS=0; UL=0; ISC= X-IBM-ISS-DetailInfo: BY=3.00004599; HX=3.00000236; KW=3.00000007; PH=3.00000004; SC=3.00000121; SDB=6.00619404; UDB=6.00274904; UTC=2015-11-19 02:06:08 x-cbparentid: 15111902-0598-0000-0000-00000547C671 X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Record header size? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 02:07:53 -0000 --0__=C5BBF592DFE0A8468f9e8a93df938690918cC5BBF592DFE0A846 Content-Transfer-Encoding: quoted-printable Content-type: text/plain; charset=US-ASCII "TLS" wrote on 19/11/2015 06:52:29 AM: > From: mrex@sap.com (Martin Rex) > To: Yoav Nir > Cc: "tls@ietf.org" > Date: 19/11/2015 06:53 AM > Subject: Re: [TLS] Record header size? > Sent by: "TLS" > > Yoav Nir wrote: > >> Peter Gutmann wrote: > >> > >> Eric Rescorla writes: > >>> > >>> The concern here is backward compatibility with inspection > middleboxes which > >>> expect the length field to be in a particular place. > >> > >> Given that the rest of TLS 1.3 is going to break compatibility with pretty > >> much everything everywhere, I can't see this as a big concern, may > >> as well fix it at the same time as everything else is being changed. > > > > A sanity check on TLS might involve validating 5-byte record headers > > with sane length and version fields. A firewall might be out there that > > verifies this. > > The issue is much more about breaking =5Fapplications=5F on top of TLS > by changing the existing 5-byte record header. Padding the header > to 8 bytes (3 bytes into the original record body) would be OK, though. > > With several TLS implementations it is possible to completely seperate > network communication (of the application) from the processing of > TLS records (performed by the TLS protocol stack). For some TLS > implementations (e.g. Microsoft SChannel) this seems to be the only > possible mode of operation. We have the same kind of IO separation and I have observed a few times that some products either interleave/multiplex TLS records with other application data flow or route/buffer TLS traffic based on TLS record header checking. Padding the header to 8 bytes, as above, would probably be OK. -Mick --0__=C5BBF592DFE0A8468f9e8a93df938690918cC5BBF592DFE0A846 Content-Transfer-Encoding: quoted-printable Content-type: text/html; charset=US-ASCII Content-Disposition: inline

"TLS" <tls-bounces@ietf.org> wrote on 19= /11/2015 06:52:29 AM:

> From: mrex@sap.com (Martin Rex)
<= tt>> To: Yoav Nir <ynir.ietf@gmail.com>
> Cc: "= ;tls@ietf.org" <tls@ietf.org>
> Date: 19/11/2015 = 06:53 AM
> Subject: Re: [TLS] Record header size?
> Sent by: "TLS" <tls-bounces@ietf.org>
&g= t;
> Yoav Nir wrote:
> >> Peter Gutmann <pgut001@cs.a= uckland.ac.nz> wrote:
> >>
> >> Eric Rescorla &= lt;ekr@rtfm.com> writes:
> >>>
> >>> The = concern here is backward compatibility with inspection
> middleboxes= which
> >>> expect the length field to be in a particular p= lace.
> >>
> >> Given that the rest of TLS 1.3 is = going to break compatibility with pretty
> >> much everything e= verywhere, I can't see this as a big concern, may
> >> as well = fix it at the same time as everything else is being changed.
> > <= br>> > A sanity check on TLS might involve validating 5-byte record h= eaders
> > with sane length and version fields. A firewall might b= e out there that
> > verifies this.
>
> The issue is = much more about breaking =5Fapplications=5F on top of TLS
> by changi= ng the existing 5-byte record header.  Padding the header
> to 8= bytes (3 bytes into the original record body) would be OK, though.
>=
> With several TLS implementations it is possible to completely sep= erate
> network communication (of the application) from the processin= g of
> TLS records (performed by the TLS protocol stack).  For s= ome TLS
> implementations (e.g. Microsoft SChannel) this seems to be = the only
> possible mode of operation.

We have the sa= me kind of IO separation and I have observed a few times that some products= either interleave/multiplex TLS records with other application data flow o= r route/buffer TLS traffic based on TLS record header checking.  Paddi= ng the header to 8 bytes, as above, would probably be OK.

-= Mick


--0__=C5BBF592DFE0A8468f9e8a93df938690918cC5BBF592DFE0A846-- From nobody Wed Nov 18 18:17: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 2A4C81B37DE for ; Wed, 18 Nov 2015 18:17:29 -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 uBnBV6Trj5-4 for ; Wed, 18 Nov 2015 18:17:26 -0800 (PST) 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 6C3EF1B37DB for ; Wed, 18 Nov 2015 18:17:26 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 7D06928494E; Thu, 19 Nov 2015 02:17:25 +0000 (UTC) Date: Thu, 19 Nov 2015 02:17:25 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20151119021725.GH18315@mournblade.imrryr.org> References: <20151118205229.E58841A380@ld9781.wdf.sap.corp> <201511190207.tAJ2796g023242@d23av04.au.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201511190207.tAJ2796g023242@d23av04.au.ibm.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Record header size? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 02:17:29 -0000 On Thu, Nov 19, 2015 at 12:05:55PM +1000, Michael Gray wrote: > > With several TLS implementations it is possible to completely seperate > > network communication (of the application) from the processing of > > TLS records (performed by the TLS protocol stack). For some TLS > > implementations (e.g. Microsoft SChannel) this seems to be the only > > possible mode of operation. > > We have the same kind of IO separation and I have observed a few times that > some products either interleave/multiplex TLS records with other > application data flow or route/buffer TLS traffic based on TLS record > header checking. Padding the header to 8 bytes, as above, would probably > be OK. Before we seriously consider going there, we should make sure that this really addresses the problems that the hardware vendors reputedly have. Is it enough to pad just the application-data records (effectively prepend 3-nul bytes to every application data record, and think of it as either a longer record header, or initial data padding)? Or do the vendors in question need alignment of the handshake packets too? My guess is that changing the alignment of the handshake packets would not be as useful, and would reduce interoperability (confuse more middle-boxes). But this guess could be wrong. Can anyone definitively confirm the actual requirements? -- Viktor. From nobody Wed Nov 18 21:19: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 408CC1A87E9 for ; Wed, 18 Nov 2015 21:19:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.785 X-Spam-Level: X-Spam-Status: No, score=-4.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9u0spZZA8vbZ for ; Wed, 18 Nov 2015 21:19:20 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9976D1A87E7 for ; Wed, 18 Nov 2015 21:19:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1447910359; x=1479446359; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=0VhknvajDmhbzAya9ABxbLeLEZHjKOquIm/R26zf07w=; b=4LrBhkzL9t6dFSClIj2aRHp9i0GXFaRHrn9boqgLolOefckJclQuTxkW d7wCVUZfljxM2cFiYOq+6DRYSheRemErCa7RXePi3O0sp1AyeB0yRj6zu C0Cr1X4F+t6gZsAPczJmp8S5KupAO9kRkImDkhLqELe5uyATiiuaRO4fn CQXzF+K6LiSyUGSMIWEz0V7uLtIH4bRP0SXBKOGd4qjJZxnoTk8P8hEcE eoaB/7ZO/+5Uw8N4vLvnQV4FAkuGtnNlImn2iKk9jWMT/y1pclDL77lAF SEJqGFHd4fHKYLskgm8z+o32uXewZSgvDn6Nng14mN08rnkk4dZQ6lIRd Q==; X-IronPort-AV: E=Sophos;i="5.20,316,1444647600"; d="scan'208";a="54941075" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxchange10-fe1.UoA.auckland.ac.nz) ([130.216.4.112]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 19 Nov 2015 18:19:18 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.51]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Thu, 19 Nov 2015 18:19:18 +1300 From: Peter Gutmann To: "Short, Todd" , Yoav Nir Thread-Topic: [TLS] Record header size? Thread-Index: AQHRIUwqo2PzkmG0m02LaFyKO+3dU56fmOsAgAFmVoT//6V2gIAAPHOAgAHv2dU= Date: Thu, 19 Nov 2015 05:19:17 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B693A7@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4B679E6@uxcn10-5.UoA.auckland.ac.nz>, , <29BB82B3-9E74-46F0-A2C6-9A5D8143DA07@akamai.com> In-Reply-To: <29BB82B3-9E74-46F0-A2C6-9A5D8143DA07@akamai.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Record header size? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 05:19:21 -0000 Short, Todd writes:=0A= =0A= >I think the philosophy some people are going with, if we're going to break= =0A= >backwards compatibility, let's do it big time, so that we only have to do = =0A= >it once, and not make everyone play continuous catchup. =0A= =0A= Exactly.=0A= =0A= I'm also not convinced by the middlebox argument, anything that does DPI is= =0A= going to be completely confused by the TLS 1.3 handshake which is nothing= =0A= like TLS 1.x, x < 3, so if middleboxes need to be upgraded to support the= =0A= 1.3 handshake they can also support the 1.3 header format.=0A= =0A= Peter.= From nobody Thu Nov 19 01:39: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 5EFB71B30BD for ; Thu, 19 Nov 2015 01:38:21 -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 y2UJRSsXwx7C for ; Thu, 19 Nov 2015 01:38:19 -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 526CA1B30B5 for ; Thu, 19 Nov 2015 01:38:19 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id CCF372ADC4 for ; Thu, 19 Nov 2015 10:38:16 +0100 (CET) X-purgate-ID: 152705::1447925896-00001C04-03027E2F/0/0 X-purgate-size: 1785 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id BF193413E5 for ; Thu, 19 Nov 2015 10:38:16 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id B6B891A382; Thu, 19 Nov 2015 10:38:16 +0100 (CET) In-Reply-To: <20151119021725.GH18315@mournblade.imrryr.org> To: tls@ietf.org Date: Thu, 19 Nov 2015 10:38:16 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20151119093816.B6B891A382@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Subject: Re: [TLS] Record header size? 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, 19 Nov 2015 09:38:21 -0000 Viktor Dukhovni wrote: > On Thu, Nov 19, 2015 at 12:05:55PM +1000, Michael Gray wrote: > > > > With several TLS implementations it is possible to completely seperate > > > network communication (of the application) from the processing of > > > TLS records (performed by the TLS protocol stack). For some TLS > > > implementations (e.g. Microsoft SChannel) this seems to be the only > > > possible mode of operation. > > > > We have the same kind of IO separation and I have observed a few times that > > some products either interleave/multiplex TLS records with other > > application data flow or route/buffer TLS traffic based on TLS record > > header checking. Padding the header to 8 bytes, as above, would probably > > be OK. > > Before we seriously consider going there, we should make sure that > this really addresses the problems that the hardware vendors > reputedly have. > > Is it enough to pad just the application-data records (effectively > prepend 3-nul bytes to every application data record, and think of > it as either a longer record header, or initial data padding)? Or > do the vendors in question need alignment of the handshake packets > too? My guess is that changing the alignment of the handshake > packets would not be as useful, and would reduce interoperability > (confuse more middle-boxes). But this guess could be wrong. > > Can anyone definitively confirm the actual requirements? The padding issue was about inplace or hardware-based encryption/decryption and would depends on whether the TLS record payload is encrypted (ciphertext) or not (cleartext) -- the content type (handshake or app data) is irrelevant. There is no need to pad cleartext TLS records (aka initial handshake messages). -Martin From nobody Thu Nov 19 04:08: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 1C46C1ACE2D for ; Thu, 19 Nov 2015 04:08:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 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, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQ3We8-Du5Cs for ; Thu, 19 Nov 2015 04:08:08 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 23C3C1ACE29 for ; Thu, 19 Nov 2015 04:08:08 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 8E481433482; Thu, 19 Nov 2015 12:08:07 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 78014433401; Thu, 19 Nov 2015 12:08:07 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1447934887; bh=24DoEwmEi/uahZp4nxP6yLdDCPAzaLKA//LmnkVeg3U=; l=21771; h=From:To:CC:Date:References:In-Reply-To:From; b=Dx031rA90MNPDJsEKcLtv2KjzXCD3NN+s3h6gyn2mitZavum0wvIR+YmKoPa3ceeg Es0L5YGY05w3neD6rX5eA/PrdbOS6xWpiw2iYTWhB2eZYY54jISs48+Hh1PgGvcb+r p4781dxbBmldVG4aHgtR+BBIQI3VvrsccqYD9bZ0= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 7516D203B; Thu, 19 Nov 2015 12:08:07 +0000 (GMT) Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Thu, 19 Nov 2015 04:08:06 -0800 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1076.000; Thu, 19 Nov 2015 07:08:06 -0500 From: "Short, Todd" To: "tls@ietf.org" Thread-Topic: [TLS] Record header size? Thread-Index: AQHRIUwqfC6IjHws+EWK+zLpB/KhZp6gxqoAgACMgACAAH9MgIAAxNaAgABXk4CAAAM2gIAAeywAgAAp3QA= Date: Thu, 19 Nov 2015 12:08:06 +0000 Message-ID: <986EBDF9-AC6D-4D64-A9CA-CE49C43D5025@akamai.com> References: <20151119093816.B6B891A382@ld9781.wdf.sap.corp> In-Reply-To: <20151119093816.B6B891A382@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.41.126] Content-Type: multipart/alternative; boundary="_000_986EBDF9AC6D4D64A9CACE49C43D5025akamaicom_" MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Record header size? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 12:08:10 -0000 --_000_986EBDF9AC6D4D64A9CACE49C43D5025akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCB0aGlzIGhhcyB0byBkbyB3aXRoIGVuY3J5cHRlZCByZWNvcmRzLiBUaGUgbm9uLWVuY3J5 cHRlZCBoYW5kc2hha2UgcmVjb3JkcyBhcmUgYWxyZWFkeSBoYXJkIGVub3VnaCB0byBwYXJzZSB0 aGF0IHRoZSA1LWJ5dGUgaGVhZGVyIGRvZXNu4oCZdCBtZWFuIG11Y2guIEkgaGF2ZSB3b3JrZWQg b24gZGVzaWducyB3aGVyZSB0aGUgZ2VuZXJhbC1wdXJwb3NlIHByb2Nlc3NvciBoYW5kbGVkIHRo ZSBoYW5kc2hha2UgYW5kIG5vbi1lbmNyeXB0ZWQgcmVjb3JkcywgYW5kIGEgY3J5cHRvIGNvLXBy b2Nlc3NvciBoYW5kbGVkIHRoZSBlbmNyeXB0aW9uLg0KLS0NCi1Ub2RkIFNob3J0DQovLyB0c2hv cnRAYWthbWFpLmNvbTxtYWlsdG86dHNob3J0QGFrYW1haS5jb20+DQovLyAiT25lIGlmIGJ5IGxh bmQsIHR3byBpZiBieSBzZWEsIHRocmVlIGlmIGJ5IHRoZSBJbnRlcm5ldC4iDQoNCk9uIE5vdiAx OSwgMjAxNSwgYXQgNDozOCBBTSwgTWFydGluIFJleCA8bXJleEBzYXAuY29tPG1haWx0bzptcmV4 QHNhcC5jb20+PiB3cm90ZToNCg0KVmlrdG9yIER1a2hvdm5pIHdyb3RlOg0KT24gVGh1LCBOb3Yg MTksIDIwMTUgYXQgMTI6MDU6NTVQTSArMTAwMCwgTWljaGFlbCBHcmF5IHdyb3RlOg0KDQpXaXRo IHNldmVyYWwgVExTIGltcGxlbWVudGF0aW9ucyBpdCBpcyBwb3NzaWJsZSB0byBjb21wbGV0ZWx5 IHNlcGVyYXRlDQpuZXR3b3JrIGNvbW11bmljYXRpb24gKG9mIHRoZSBhcHBsaWNhdGlvbikgZnJv bSB0aGUgcHJvY2Vzc2luZyBvZg0KVExTIHJlY29yZHMgKHBlcmZvcm1lZCBieSB0aGUgVExTIHBy b3RvY29sIHN0YWNrKS4gIEZvciBzb21lIFRMUw0KaW1wbGVtZW50YXRpb25zIChlLmcuIE1pY3Jv c29mdCBTQ2hhbm5lbCkgdGhpcyBzZWVtcyB0byBiZSB0aGUgb25seQ0KcG9zc2libGUgbW9kZSBv ZiBvcGVyYXRpb24uDQoNCldlIGhhdmUgdGhlIHNhbWUga2luZCBvZiBJTyBzZXBhcmF0aW9uIGFu ZCBJIGhhdmUgb2JzZXJ2ZWQgYSBmZXcgdGltZXMgdGhhdA0Kc29tZSBwcm9kdWN0cyBlaXRoZXIg aW50ZXJsZWF2ZS9tdWx0aXBsZXggVExTIHJlY29yZHMgd2l0aCBvdGhlcg0KYXBwbGljYXRpb24g ZGF0YSBmbG93IG9yIHJvdXRlL2J1ZmZlciBUTFMgdHJhZmZpYyBiYXNlZCBvbiBUTFMgcmVjb3Jk DQpoZWFkZXIgY2hlY2tpbmcuICBQYWRkaW5nIHRoZSBoZWFkZXIgdG8gOCBieXRlcywgYXMgYWJv dmUsIHdvdWxkIHByb2JhYmx5DQpiZSBPSy4NCg0KQmVmb3JlIHdlIHNlcmlvdXNseSBjb25zaWRl ciBnb2luZyB0aGVyZSwgd2Ugc2hvdWxkIG1ha2Ugc3VyZSB0aGF0DQp0aGlzIHJlYWxseSBhZGRy ZXNzZXMgdGhlIHByb2JsZW1zIHRoYXQgdGhlIGhhcmR3YXJlIHZlbmRvcnMNCnJlcHV0ZWRseSBo YXZlLg0KDQpJcyBpdCBlbm91Z2ggdG8gcGFkIGp1c3QgdGhlIGFwcGxpY2F0aW9uLWRhdGEgcmVj b3JkcyAoZWZmZWN0aXZlbHkNCnByZXBlbmQgMy1udWwgYnl0ZXMgdG8gZXZlcnkgYXBwbGljYXRp b24gZGF0YSByZWNvcmQsIGFuZCB0aGluayBvZg0KaXQgYXMgZWl0aGVyIGEgbG9uZ2VyIHJlY29y ZCBoZWFkZXIsIG9yIGluaXRpYWwgZGF0YSBwYWRkaW5nKT8gIE9yDQpkbyB0aGUgdmVuZG9ycyBp biBxdWVzdGlvbiBuZWVkIGFsaWdubWVudCBvZiB0aGUgaGFuZHNoYWtlIHBhY2tldHMNCnRvbz8g IE15IGd1ZXNzIGlzIHRoYXQgY2hhbmdpbmcgdGhlIGFsaWdubWVudCBvZiB0aGUgaGFuZHNoYWtl DQpwYWNrZXRzIHdvdWxkIG5vdCBiZSBhcyB1c2VmdWwsIGFuZCB3b3VsZCByZWR1Y2UgaW50ZXJv cGVyYWJpbGl0eQ0KKGNvbmZ1c2UgbW9yZSBtaWRkbGUtYm94ZXMpLiAgQnV0IHRoaXMgZ3Vlc3Mg Y291bGQgYmUgd3JvbmcuDQoNCkNhbiBhbnlvbmUgZGVmaW5pdGl2ZWx5IGNvbmZpcm0gdGhlIGFj dHVhbCByZXF1aXJlbWVudHM/DQoNCg0KVGhlIHBhZGRpbmcgaXNzdWUgd2FzIGFib3V0IGlucGxh Y2Ugb3IgaGFyZHdhcmUtYmFzZWQgZW5jcnlwdGlvbi9kZWNyeXB0aW9uDQphbmQgd291bGQgZGVw ZW5kcyBvbiB3aGV0aGVyIHRoZSBUTFMgcmVjb3JkIHBheWxvYWQgaXMgZW5jcnlwdGVkIChjaXBo ZXJ0ZXh0KQ0Kb3Igbm90IChjbGVhcnRleHQpIC0tIHRoZSBjb250ZW50IHR5cGUgKGhhbmRzaGFr ZSBvciBhcHAgZGF0YSkgaXMgaXJyZWxldmFudC4NClRoZXJlIGlzIG5vIG5lZWQgdG8gcGFkIGNs ZWFydGV4dCBUTFMgcmVjb3JkcyAoYWthIGluaXRpYWwgaGFuZHNoYWtlDQptZXNzYWdlcykuDQoN Ci1NYXJ0aW4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NClRMUyBtYWlsaW5nIGxpc3QNClRMU0BpZXRmLm9yZzxtYWlsdG86VExTQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMNCg0K --_000_986EBDF9AC6D4D64A9CACE49C43D5025akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <2354237D0E73A54AA558BCB2F774CFE2@akamai.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KWWVzLCB0aGlzIGhhcyB0byBkbyB3 aXRoIGVuY3J5cHRlZCByZWNvcmRzLiBUaGUgbm9uLWVuY3J5cHRlZCBoYW5kc2hha2UgcmVjb3Jk cyBhcmUgYWxyZWFkeSBoYXJkIGVub3VnaCB0byBwYXJzZSB0aGF0IHRoZSA1LWJ5dGUgaGVhZGVy IGRvZXNu4oCZdCBtZWFuIG11Y2guIEkgaGF2ZSB3b3JrZWQgb24gZGVzaWducyB3aGVyZSB0aGUg Z2VuZXJhbC1wdXJwb3NlIHByb2Nlc3NvciBoYW5kbGVkIHRoZSBoYW5kc2hha2UgYW5kIG5vbi1l bmNyeXB0ZWQgcmVjb3JkcywNCiBhbmQgYSBjcnlwdG8gY28tcHJvY2Vzc29yIGhhbmRsZWQgdGhl IGVuY3J5cHRpb24uPGJyIGNsYXNzPSIiPg0KPGRpdiBhcHBsZS1jb250ZW50LWVkaXRlZD0idHJ1 ZSIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBsZXR0ZXItc3Bh Y2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93 czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw eDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJr aXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9 ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1 dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBw eDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7 IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0 ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4tLTwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij4tVG9kZCBTaG9ydDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4vLyA8YSBocmVmPSJtYWlsdG86dHNo b3J0QGFrYW1haS5jb20iIGNsYXNzPSIiPnRzaG9ydEBha2FtYWkuY29tPC9hPjwvZGl2Pg0KPGRp diBjbGFzcz0iIj4vLyAmcXVvdDtPbmUgaWYgYnkgbGFuZCwgdHdvIGlmIGJ5IHNlYSwgdGhyZWUg aWYgYnkgdGhlIEludGVybmV0LiZxdW90OzwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PGJyIGNsYXNzPSIiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj5PbiBOb3YgMTksIDIwMTUsIGF0IDQ6MzggQU0sIE1hcnRpbiBSZXggJmx0 OzxhIGhyZWY9Im1haWx0bzptcmV4QHNhcC5jb20iIGNsYXNzPSIiPm1yZXhAc2FwLmNvbTwvYT4m Z3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4N CjxkaXYgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQt c2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9u dC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5v cm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7 IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87 IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0 OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPlZpa3Rvcg0KIER1 a2hvdm5pIHdyb3RlOjwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZv bnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsg Zm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6 IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAw cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1 dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBj bGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIHN0eWxlPSJmb250LWZhbWlseTogSGVs dmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50 OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxp bmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0 LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsg d2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4OyIgY2xhc3M9IiI+DQpPbiBUaHUsIE5vdiAxOSwgMjAxNSBhdCAxMjowNTo1NVBNICYj NDM7MTAwMCwgTWljaGFlbCBHcmF5IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSIgY2xhc3M9IiI+V2l0aCBzZXZlcmFsIFRMUyBpbXBsZW1lbnRhdGlvbnMgaXQgaXMgcG9zc2li bGUgdG8gY29tcGxldGVseSBzZXBlcmF0ZTxiciBjbGFzcz0iIj4NCm5ldHdvcmsgY29tbXVuaWNh dGlvbiAob2YgdGhlIGFwcGxpY2F0aW9uKSBmcm9tIHRoZSBwcm9jZXNzaW5nIG9mPGJyIGNsYXNz PSIiPg0KVExTIHJlY29yZHMgKHBlcmZvcm1lZCBieSB0aGUgVExTIHByb3RvY29sIHN0YWNrKS4g Jm5ic3A7Rm9yIHNvbWUgVExTPGJyIGNsYXNzPSIiPg0KaW1wbGVtZW50YXRpb25zIChlLmcuIE1p Y3Jvc29mdCBTQ2hhbm5lbCkgdGhpcyBzZWVtcyB0byBiZSB0aGUgb25seTxiciBjbGFzcz0iIj4N CnBvc3NpYmxlIG1vZGUgb2Ygb3BlcmF0aW9uLjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4N CjxiciBjbGFzcz0iIj4NCldlIGhhdmUgdGhlIHNhbWUga2luZCBvZiBJTyBzZXBhcmF0aW9uIGFu ZCBJIGhhdmUgb2JzZXJ2ZWQgYSBmZXcgdGltZXMgdGhhdDxiciBjbGFzcz0iIj4NCnNvbWUgcHJv ZHVjdHMgZWl0aGVyIGludGVybGVhdmUvbXVsdGlwbGV4IFRMUyByZWNvcmRzIHdpdGggb3RoZXI8 YnIgY2xhc3M9IiI+DQphcHBsaWNhdGlvbiBkYXRhIGZsb3cgb3Igcm91dGUvYnVmZmVyIFRMUyB0 cmFmZmljIGJhc2VkIG9uIFRMUyByZWNvcmQ8YnIgY2xhc3M9IiI+DQpoZWFkZXIgY2hlY2tpbmcu ICZuYnNwO1BhZGRpbmcgdGhlIGhlYWRlciB0byA4IGJ5dGVzLCBhcyBhYm92ZSwgd291bGQgcHJv YmFibHk8YnIgY2xhc3M9IiI+DQpiZSBPSy48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8 YnIgY2xhc3M9IiI+DQpCZWZvcmUgd2Ugc2VyaW91c2x5IGNvbnNpZGVyIGdvaW5nIHRoZXJlLCB3 ZSBzaG91bGQgbWFrZSBzdXJlIHRoYXQ8YnIgY2xhc3M9IiI+DQp0aGlzIHJlYWxseSBhZGRyZXNz ZXMgdGhlIHByb2JsZW1zIHRoYXQgdGhlIGhhcmR3YXJlIHZlbmRvcnM8YnIgY2xhc3M9IiI+DQpy ZXB1dGVkbHkgaGF2ZS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJcyBpdCBlbm91Z2gg dG8gcGFkIGp1c3QgdGhlIGFwcGxpY2F0aW9uLWRhdGEgcmVjb3JkcyAoZWZmZWN0aXZlbHk8YnIg Y2xhc3M9IiI+DQpwcmVwZW5kIDMtbnVsIGJ5dGVzIHRvIGV2ZXJ5IGFwcGxpY2F0aW9uIGRhdGEg cmVjb3JkLCBhbmQgdGhpbmsgb2Y8YnIgY2xhc3M9IiI+DQppdCBhcyBlaXRoZXIgYSBsb25nZXIg cmVjb3JkIGhlYWRlciwgb3IgaW5pdGlhbCBkYXRhIHBhZGRpbmcpPyAmbmJzcDtPcjxiciBjbGFz cz0iIj4NCmRvIHRoZSB2ZW5kb3JzIGluIHF1ZXN0aW9uIG5lZWQgYWxpZ25tZW50IG9mIHRoZSBo YW5kc2hha2UgcGFja2V0czxiciBjbGFzcz0iIj4NCnRvbz8gJm5ic3A7TXkgZ3Vlc3MgaXMgdGhh dCBjaGFuZ2luZyB0aGUgYWxpZ25tZW50IG9mIHRoZSBoYW5kc2hha2U8YnIgY2xhc3M9IiI+DQpw YWNrZXRzIHdvdWxkIG5vdCBiZSBhcyB1c2VmdWwsIGFuZCB3b3VsZCByZWR1Y2UgaW50ZXJvcGVy YWJpbGl0eTxiciBjbGFzcz0iIj4NCihjb25mdXNlIG1vcmUgbWlkZGxlLWJveGVzKS4gJm5ic3A7 QnV0IHRoaXMgZ3Vlc3MgY291bGQgYmUgd3JvbmcuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KQ2FuIGFueW9uZSBkZWZpbml0aXZlbHkgY29uZmlybSB0aGUgYWN0dWFsIHJlcXVpcmVtZW50 cz88YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBI ZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh bnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg bGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFs OyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsg Zm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFs OyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdo dDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6 IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czog YXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsi IGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6 ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13 ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1h bDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRl eHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdv cmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBu b25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPlRoZQ0KIHBhZGRpbmcg aXNzdWUgd2FzIGFib3V0IGlucGxhY2Ugb3IgaGFyZHdhcmUtYmFzZWQgZW5jcnlwdGlvbi9kZWNy eXB0aW9uPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXpl OiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdl aWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFs OyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4 dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29y ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsg Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFu czogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2lu ZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNw bGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPmFuZA0KIHdvdWxkIGRlcGVuZHMgb24g d2hldGhlciB0aGUgVExTIHJlY29yZCBwYXlsb2FkIGlzIGVuY3J5cHRlZCAoY2lwaGVydGV4dCk8 L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7 IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBu b3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhh bnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNp bmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0 eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBs ZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRv OyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5v bmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7 IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlu bGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+b3INCiBub3QgKGNsZWFydGV4dCkgLS0gdGhlIGNv bnRlbnQgdHlwZSAoaGFuZHNoYWtlIG9yIGFwcCBkYXRhKSBpcyBpcnJlbGV2YW50Ljwvc3Bhbj48 YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1z dHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsg bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0 bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu b25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4 OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFp bXBvcnRhbnQ7IiBjbGFzcz0iIj5UaGVyZQ0KIGlzIG5vIG5lZWQgdG8gcGFkIGNsZWFydGV4dCBU TFMgcmVjb3JkcyAoYWthIGluaXRpYWwgaGFuZHNoYWtlPC9zcGFuPjxiciBzdHlsZT0iZm9udC1m YW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZv bnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzog bm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBz dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNl OiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBI ZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh bnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg bGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFs OyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNz PSIiPm1lc3NhZ2VzKS48L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBm b250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7 IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0 OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDog MHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBh dXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIg Y2xhc3M9IiI+DQo8YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTog MTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWln aHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsg b3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQt c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4N CjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZv bnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3Jt YWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6 IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9y bTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6 IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxh eTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj4tTWFydGluPC9zcGFuPjxiciBzdHlsZT0i Zm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3Jt YWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3Bh Y2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFs aWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRl LXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQt dGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGJyIHN0eWxlPSJmb250LWZhbWls eTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12 YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0 OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v cm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZl dGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDog bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5l LWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1p bmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdp ZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PGJy IHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5 bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl dHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87 IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9u ZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsg LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3Jt YWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3Bh Y2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFs aWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRl LXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQt dGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1w b3J0YW50OyIgY2xhc3M9IiI+VExTDQogbWFpbGluZyBsaXN0PC9zcGFuPjxiciBzdHlsZT0iZm9u dC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7 IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2lu Zzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWdu OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw YWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4 dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOlRMU0BpZXRm Lm9yZyIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9u dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h bDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczog YXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3Jt OiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzog MHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj5UTFNAaWV0Zi5v cmc8L2E+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7 IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBu b3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhh bnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNp bmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RscyIgc3R5bGU9ImZv bnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFs OyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp bmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGln bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z cGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3RsczwvYT48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNs YXNzPSIiPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_986EBDF9AC6D4D64A9CACE49C43D5025akamaicom_-- From nobody Thu Nov 19 07:03: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 4BDED1B2B03 for ; Thu, 19 Nov 2015 07:03:20 -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 SJrLn3boThPb for ; Thu, 19 Nov 2015 07:03:14 -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 8357D1B2AF2 for ; Thu, 19 Nov 2015 07:03:14 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 0D56C2ADCD; Thu, 19 Nov 2015 16:03:13 +0100 (CET) X-purgate-ID: 152705::1447945393-00002D85-9236E3A8/0/0 X-purgate-size: 975 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id F19D641166; Thu, 19 Nov 2015 16:03:12 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id E8CDA1A383; Thu, 19 Nov 2015 16:03:12 +0100 (CET) In-Reply-To: To: Eric Rescorla Date: Thu, 19 Nov 2015 16:03:12 +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: <20151119150312.E8CDA1A383@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR#345: IANA Considerations 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, 19 Nov 2015 15:03:20 -0000 Eric Rescorla wrote: > > There are presently four categories of cipher suites vis-a-vis TLS 1.3. > > 1. MUST or SHOULD cipher suites. > 2. Standards track cipher suites (or ones we are making ST, like > the ECC ones). > 3. Non standards track cipher suites > 4. Cipher suites you can't use at all with TLS 1.3, like AES-CBC. > > I think we're all agreed that category #1 should be marked recommended > and that #3 and #4 should not be. This leaves us with category #2, which > includes stuff like: > > - FFDHE > - CCM > > My proposal is that we: > > - List all the Standards Track cipher suites that are compatible with TLS > 1.3 in Appendix A. > - Mark all the cipher suites that are listed in Appendix A as "Recommended" I'm slightly confused. rfc5288 is standards track and describes AES-GCM with static RSA keyex. rfc5289 is only informational (i.e. _not_ standards track) and describes AES-GCM with ECDHE keyex. -Martin From nobody Thu Nov 19 07:10: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 331121B2AEE for ; Thu, 19 Nov 2015 07:10:52 -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, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8N-N9b2ttqJ for ; Thu, 19 Nov 2015 07:10:51 -0800 (PST) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDD5D1B2ADD for ; Thu, 19 Nov 2015 07:10:50 -0800 (PST) Received: by ykdr82 with SMTP id r82so110339255ykd.3 for ; Thu, 19 Nov 2015 07:10:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=lv9FCgrtDHvUAieTgz3BMOuMPZ4vkKsNZEqXOI3iVnw=; b=Ph7DXzzEsPF8JAasybuBWbN3ozNdvXEVRgtVfkeYhnSYajmMtxgphAi7QK74bfXeKX a03hcmyObZZ1xm9Ihq6U/cwJhXbN/RZT1LsaOl97LKFT3T2Sh1hNC4FFrG8fgAmR1xAr XSDY5Ts//i2cCGCUvJJJmuC8TcvIK6NOlDGgVXuoXWd1/WaI38BpxglnC9XolKkPQg2X vMRq/PkdUDR9JnHVuypl4tKPOVC5zalZSi5Gd9C9CfWgsuHriZ0VetWVY9AKbZXOZopU /Sjlphs2vJ/qkkEeORnPGGlR9HBfGqnEQCT+fWhN2cdLG0u1SLMT06TA+MMp9TA/XTzl Cf2Q== 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=lv9FCgrtDHvUAieTgz3BMOuMPZ4vkKsNZEqXOI3iVnw=; b=KUpBAIKykARNst4y7dUK89LMZsXvA7UNXDNvsUprK+97S4WtZTg/R11eKk67rR6FB8 /Psc9mzD3VFN9moho+vODiQt+ezVSSIDNOA8BMKfrb2JK8paepJIaB9KOLWGrjQgKc7Q noZpPoCHnupiPCYdaPPGTCNJObor5jYkSZ0vWOG/a3qgui/K5FvQq+HNGBQb0use+y7p GchG5PC+dYOw0mLxA34ZkyIjEzhUez9k86F+YFMqo3eGFFjHLk/WDsWQ+0d+neMrTZt/ V5S+C9ieaYJbd0MHuHWn++mRxyNK/F4mtFjmJhGnuHkjwkR7mzYAY8DNkmcc3WGCOxWN 8Jaw== X-Gm-Message-State: ALoCoQmZcAV10qAWFtWc+ylJyTC0OHGHBOAlOcBQ8kmYM1OruC39bPoaDw0hIBgml45dlTvf+KOZ X-Received: by 10.13.212.9 with SMTP id w9mr7783939ywd.192.1447945849616; Thu, 19 Nov 2015 07:10:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.221.203 with HTTP; Thu, 19 Nov 2015 07:10:10 -0800 (PST) In-Reply-To: <20151119150312.E8CDA1A383@ld9781.wdf.sap.corp> References: <20151119150312.E8CDA1A383@ld9781.wdf.sap.corp> From: Eric Rescorla Date: Thu, 19 Nov 2015 07:10:10 -0800 Message-ID: To: "mrex@sap.com" Content-Type: multipart/alternative; boundary=001a114fa6380566fa0524e62a83 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR#345: IANA Considerations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 15:10:52 -0000 --001a114fa6380566fa0524e62a83 Content-Type: text/plain; charset=UTF-8 On Thu, Nov 19, 2015 at 7:03 AM, Martin Rex wrote: > Eric Rescorla wrote: > > > > There are presently four categories of cipher suites vis-a-vis TLS 1.3. > > > > 1. MUST or SHOULD cipher suites. > > 2. Standards track cipher suites (or ones we are making ST, like > > the ECC ones). > > 3. Non standards track cipher suites > > 4. Cipher suites you can't use at all with TLS 1.3, like AES-CBC. > > > > I think we're all agreed that category #1 should be marked recommended > > and that #3 and #4 should not be. This leaves us with category #2, which > > includes stuff like: > > > > - FFDHE > > - CCM > > > > My proposal is that we: > > > > - List all the Standards Track cipher suites that are compatible with TLS > > 1.3 in Appendix A. > > - Mark all the cipher suites that are listed in Appendix A as > "Recommended" > > > I'm slightly confused. > > rfc5288 is standards track and describes AES-GCM with static RSA keyex. > This isn't compatible with TLS 1.3 because TLS 1.3 removes static RSA. rfc5289 is only informational (i.e. _not_ standards track) and describes > AES-GCM with ECDHE keyex. We are re-labelling the AES-GCM ECDHE suites as standards track either in this document or in RFC4492bis. -Ekr > > > > -Martin > --001a114fa6380566fa0524e62a83 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Thu, Nov 19, 2015 at 7:03 AM, Martin Rex <mrex@sap.com> wr= ote:
Eric Rescorla wrote= :
>
> There are presently four categories of cipher suites vis-a-vis TLS 1.3= .
>
> 1. MUST or SHOULD cipher suites.
> 2. Standards track cipher suites (or ones we are making ST, like
>=C2=A0 =C2=A0 =C2=A0the ECC ones).
> 3. Non standards track cipher suites
> 4. Cipher suites you can't use at all with TLS 1.3, like AES-CBC.<= br> >
> I think we're all agreed that category #1 should be marked recomme= nded
> and that #3 and #4 should not be. This leaves us with category #2, whi= ch
> includes stuff like:
>
> - FFDHE
> - CCM
>
> My proposal is that we:
>
> - List all the Standards Track cipher suites that are compatible with = TLS
> 1.3 in Appendix A.
> - Mark all the cipher suites that are listed in Appendix A as "Re= commended"


I'm slightly confused.

rfc5288 is standards track and describes AES-GCM with static RSA keyex.
=

This isn't compatible with TLS 1.3 bec= ause TLS 1.3 removes static RSA.


rfc5289 is only informational (i.e. _not_ standards track) and describes AES-GCM with ECDHE keyex.

We are re-labelli= ng the AES-GCM ECDHE suites as standards track either in this document or i= n RFC4492bis.

-Ekr
=C2=A0



-Martin

--001a114fa6380566fa0524e62a83-- From nobody Thu Nov 19 13:52: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 943F21B360C for ; Thu, 19 Nov 2015 13:52:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.485 X-Spam-Level: X-Spam-Status: No, score=-7.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNt22TWexzI3 for ; Thu, 19 Nov 2015 13:52:37 -0800 (PST) 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 E95911B3603 for ; Thu, 19 Nov 2015 13:52:36 -0800 (PST) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 6AAFE42E5A8 for ; Thu, 19 Nov 2015 21:52:36 +0000 (UTC) Received: from rrelyea-laptop.usersys.redhat.com (dhcp-16-202.sjc.redhat.com [10.14.16.202]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tAJLqZZ1013987 for ; Thu, 19 Nov 2015 16:52:35 -0500 To: tls@ietf.org References: <20151022125557.9B1651A31C@ld9781.wdf.sap.corp> From: Robert Relyea Message-ID: <564E44A3.8020004@REDHAT.COM> Date: Thu, 19 Nov 2015 13:52:35 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050509080205030301040902" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: Subject: Re: [TLS] Allow NamedGroups from the server? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 21:52:38 -0000 This is a cryptographically signed message in MIME format. --------------ms050509080205030301040902 Content-Type: multipart/alternative; boundary="------------060302010303020002030809" This is a multi-part message in MIME format. --------------060302010303020002030809 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 10/22/2015 06:29 AM, Eric Rescorla wrote: > > > From an implementation perspective, I wouldn't be surprised if client > implementations choked on the server sending this. I had to check > to see if NSS would do so. It doesn't, but given the way the code > is written, it wouldn't have surprised me if it checked that all=20 > extensions > were handled and choked otherwise. Yeah, NSS was implemented under the old 'be graceful in what you accept' = with the 'be a bit paranoid when security is on the line'. That being said, in the early days of SSL3, unknown extensions were=20 explicitly allowed, mostly so you could handle new protocols against old = servers. In practice this failed miserably because many server implementations=20 followed the standard security paranoia of 'it's there and I don't=20 undertand it, fail'. This is why we have/had TLS intolerance issues. Anyway NSS is purposefully tolerant of well formed unknown extensions,=20 as well as typically accepting new extensions on older versions of the=20 protocol (like accepting ECC operations even though you negotiated SSL3).= bob > > -Ekr > > > -Martin > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --------------060302010303020002030809 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On 10/22/2015 06:29 AM, Eric Rescorla wrote:


From an implementation perspective, I wouldn't be surprised if client
implementations choked on the server sending this. I had to check
to see if NSS would do so. It doesn't, but given the way the code
is written, it wouldn't have surprised me if it checked that all extensions
were handled and choked otherwise.

Yeah, NSS was implemented under the old 'be graceful in what you accept' with the 'be a bit paranoid when security is on the line'.
That being said, in the early days of SSL3, unknown extensions were explicitly allowed, mostly so you could handle new protocols against old servers.

In practice this failed miserably because many server implementations followed the standard security paranoia of 'it's there and I don't undertand it, fail'. This is why we have/had TLS intolerance issues.

Anyway NSS is purposefully tolerant of well formed unknown extensions, as well as typically accepting new extensions on older versions of the protocol (like accepting ECC operations even though you negotiated SSL3).

bob

-Ekr
=A0
=A0
-Martin



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

--------------060302010303020002030809-- --------------ms050509080205030301040902 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DJAwggY0MIIEHKADAgECAgEgMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAyNTVaFw0xNzEwMjQyMTAyNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDLKIVFnAEs+xny q6UzjCqgDcvQVe1dIoFnRsQPCFO+y92k8RK0Pn3MbQ2Gd+mehh9GBZ+36uUQA7Xj9AGM6wgP hEE34vKtfpAN5tJ8LcFxveDObCKrL7O5UT9WsnAZHv7OYPYSR68mdmnEnJ83M4wQgKO19b+R t8sPDAz9ptkQsntCn4GeJzg3q2SVc4QJTg/WHo7wF2ah5LMOeh8xJVSKGEmd6uPkSbj113yK Mm8vmNptRPmM1+YgmVwcdOYJOjCgFtb2sOP79jji8uhWR91xx7TpM1K3hv/wrBZwffrmmEpU euXHRs07JqCCvFh9coKF4UQZvfEg+x3/69xRCzb1AgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUrlWDb+wxyrn3HfqvazHzyB3jrLsw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQA6qScNyNO0FpHvaZTQacVMXH33O51KyEKSRw3IvdQxRu31YR0ZDGdSfgSoOVDVMSBSdmfQ fdDInHPzV3LO5DwUXZ+lxjv7z3PO2OkfnFkvTXPfn6dxJ5rJveDsTsCPcJ/Kp6/+qN5g+J6D /SaYcFD018B6L42r0Z4VEBy36P4tjRtF14Ex10tl5tJFVKM16qWKQHbpjIgf73s49UB0CQ5l HT2DHKfq3oPfdNc5Mk93w1v4ryVb+qVrZIej8NsrWU+5r4O2IV91edDb/OtHFddZqHFFXKgS 79IHE/hwQ2LW7r3sTX7cDUCg+dfdwO8zeLxuwk2JF8crUoyrl66RGrRIhT8VoG/OJ1Y9uUlO av69V4cG8upi4ZG2l7JZFbcBFk91Wp+Payo5SuF61CmGFrZ386umkmpObtFacXda2O/bVoQ9 xHQrzoTc/0KZTWvlZCLK3Ke/vGYT9ZdW9lOjGsSFbXrlTA919L84iMK+48WGnvRWY28ZaVHp ql43AtEGhXze6iNCbEDACy+4hkQYOytAqDgcxAnQ937mYpeZFPyz/XK9QSt9VNFMuudWxZwD DDJKoQAoSG59Hou9lZ26UrK60nRdAQBmEPL8h2nuWgoPh++XVQld9yuhbsWa39Pck8/lcfz5 HUVGJF5mc/zk38iV7FDlF68puiryNq2KXHEpOTCCBlQwggU8oAMCAQICAlIDMA0GCSqGSIb3 DQEBCwUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTQwODE4MTcz NjU2WhcNMTYwODE4MjAyMjE2WjBxMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTESMBAGA1UEBxMJU3Vubnl2YWxlMRYwFAYDVQQDEw1Sb2JlcnQgUmVseWVhMSEwHwYJKoZI hvcNAQkBFhJycmVseWVhQHJlZGhhdC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQC2h3cZFHyDLHrwQiIQvW3O1v3sLmwQKSC3YlfJwE0etWUy0cy+XG8cuVlV8x9kWlf2 T1SIikGISMm8UHuUntpuH/0CWziffeF9tmO6pd5M+c/zk+i7gkgvPxf2UqLvKE0q736jJyPm oCPBu8jR74xtZwgIxuHQBx57uVV8/4/VePb3Ef2E8qaDN9V8Rdn51CyryOod/ppJ0so88ReW C5qmDC5/F3D3ku29W/ZqVW84/5F0JKOatO7dqIUdRgx+LWsGvs/gwSlNqsdJ79cdnXDGmWHO a4m+qUqbvPFeYLXRrnFxQJoezPuqcYKmdFmSj2VykxymdauFoQfCOpG17YcZAgMBAAGjggLY MIIC1DAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYB BQUHAwQwHQYDVR0OBBYEFMHL3cM6QMqQtnjEmxqllSebdX/PMB8GA1UdIwQYMBaAFK5Vg2/s Mcq59x36r2sx88gd46y7MB0GA1UdEQQWMBSBEnJyZWx5ZWFAcmVkaGF0LmNvbTCCAUwGA1Ud IASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNz dWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBv ZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5k ZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRp b25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1Mi1j cmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFy dHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEu c3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAa hhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQELBQADggEBAFe1vf4Dk8Wx IGqLN05k/8sM7o0g1iSPRm++kXaIDGXawodnRBe9t1Xx2FvwuQ/AlvfLy0h5Mt6dQu1hKt8p m7n47e7+bUWPiSD/jW8pAuKiXDViR9nCPiIaW3haMJU23dG3leD2lIm5Nuu/ZpKT9Jxsnjyu i0xfLypICpHiQtqXSDPprL3iUgiN3OK6vgC80Ogl7GHd/SqDHNX1xGZpOZgKPOGcL4hj0BPq BtxICdim+cGLAHgnVm6mjD0fd2WiSr3tYQrc8ngafGWQxFQ3XWawimY5kLoFEZI2ygij7wFq ZVzDoZicaSEIIgGJAkKY6nOuqR8d9XrGoxQdMecgke0xggPqMIID5gIBATCBkzCBjDELMAkG A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJp bWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJSAzANBglghkgBZQMEAgEFAKCCAicwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUxMTE5MjE1MjM1WjAv BgkqhkiG9w0BCQQxIgQgOHJaMFetanMEpwre4dK7/9DHay7oWh1mMVVcm41LIm0wbAYJKoZI hvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJ KwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAlID MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgJSAzANBgkqhkiG9w0BAQEFAASCAQCrRGP4zanf2vbgbL0Dj/rIolk3nlrTeB3//sjX aj4//lmEi9ksJghCJG3lI+gwXkL8y/x0/S/ZQixL6cQk9RYcO+fQzhNdwJqyDol5uLR4PiKc 5edp7F1DCAAZ8JN6Eo45W+oSzjOJDAxcvOgI6J7zt68lWaqln3lF30wFaEG+g30ss61qlt8s h+yDtWGgXfpiwCP7adh8VQpKBupFIn2SxZEGYtBSKlhM4R1BoX1ORxHxipesksB+FdKY7MXW tqNbaWrEBmjEiXT4bFDDrNiDQuSuYtPGHd4rDnE70kq6RjfclMjXEMJEHAesrdXo0ncb7s5G 4NimSaO789i4HgeBAAAAAAAA --------------ms050509080205030301040902-- From nobody Fri Nov 20 06:16: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 A66821AD241 for ; Fri, 20 Nov 2015 06:16:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.886 X-Spam-Level: X-Spam-Status: No, score=-4.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5VHyZCHXtAyP for ; Fri, 20 Nov 2015 06:16:34 -0800 (PST) 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 6D2701AD1F5 for ; Fri, 20 Nov 2015 06:16:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6C4C8BE77 for ; Fri, 20 Nov 2015 14:16:32 +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 LcpB4aZZIEUp for ; Fri, 20 Nov 2015 14:16:31 +0000 (GMT) Received: from [10.87.48.91] (unknown [86.46.27.72]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 89FB5BE73 for ; Fri, 20 Nov 2015 14:16:30 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1448028991; bh=m7MAXFf0oChRFWYa/WQXepIE+6Rt2UqPJ0Hn5jdg7Ec=; h=To:From:Subject:Date:From; b=qiAd48bFIcYyXHUq3puEWbpiAAVQvDPKQECqR3ZxBkpHHPzI1f9r7+sFn53Ai5UVB RuSHGcR7nZ3BK2mkWKkyBSkEx4eR/dzWOoMhlF4Fl4/8bs/bn3XUcfO8kD7XoXgv1s LnxorLzSjLPfhG9b6prt5GF5n5uGRpZj1dRHGEWQ= To: "tls@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <564F2B3D.9000901@cs.tcd.ie> Date: Fri, 20 Nov 2015 14:16:29 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [TLS] AD review of /draft-ietf-tls-cached-info-20 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 14:16:39 -0000 Hiya, I've requested IETF LC for this one. (Sorry for being slow getting to it.) Please treat my comments below along with any other last call comments. - You probably thought about this but I forget the argument. Wouldn't it have been better to include the cached info that is not sent within the transcript? I can't see an attack myself, but then we didn't get the triple-handshake problem even after the initial double-handshake attack was known. - ID nits complains that 6234 has obsoleted 4634, and indeed so it has:-) I'll note that in the LC announce. - 2^16-1 CachedObject instances makes no sense at all, that would be bigger than the full handshake. Why not pick a sensible value? Even if you don't put such a value in the syntax, you could at least say that e.g. N instances will likely be pointless, for whatever N (10-ish?) would make the h/w bigger overall. - page 6: wrt 7250 do you need to say that the server can tell which thing (cert or SPKI) the client has cached from the hash value? I think it can only work that way, but it might be worth saying that. If it works some other way, then I didn't get that, so probably some other bit of text would be needed. - typo: consideratios Cheers, S. From nobody Fri Nov 20 06:28:58 2015 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F1FFD1B29D8; Fri, 20 Nov 2015 06:28:57 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.10.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20151120142857.18014.33953.idtracker@ietfa.amsl.com> Date: Fri, 20 Nov 2015 06:28:57 -0800 Archived-At: Cc: draft-ietf-tls-cached-info@ietf.org, tls-chairs@ietf.org, tls@ietf.org Subject: [TLS] Last Call: (Transport Layer Security (TLS) Cached Information Extension) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 14:28:58 -0000 The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Transport Layer Security (TLS) Cached Information 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-12-04. 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 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 file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-cached-info/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tls-cached-info/ballot/ No IPR declarations have been submitted directly on this I-D. RFC 4634 has been obsoleted by RFC 6234. We'll fix the reference later. From nobody Mon Nov 23 06:21: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 3884F1B39DF for ; Mon, 23 Nov 2015 06:21:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 eFG9tQlIIeFQ for ; Mon, 23 Nov 2015 06:21:25 -0800 (PST) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::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 A34451B39DE for ; Mon, 23 Nov 2015 06:21:25 -0800 (PST) Received: by ykba77 with SMTP id a77so237451767ykb.2 for ; Mon, 23 Nov 2015 06:21:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=XxIuCVroTwdd7wi1THmV/daZD2sUW/ULC+5L5Q9Kngk=; b=fysUrTFmUID36x8zCouMt2hongkxwjey5FfwidrL8dDZo81yP3Q897/VdjKrH2JYN7 KLlWbj6qnanicVaMQg8e9mCN23iPYrOq6C+526bdOhU8uAWooNDkH7GvOx1CMY1aQaRh iWgsTnMa1tj/6Gx3zhb0KC8NnswQ73vWgRL6g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:content-transfer-encoding :subject:message-id:date:to:mime-version; bh=XxIuCVroTwdd7wi1THmV/daZD2sUW/ULC+5L5Q9Kngk=; b=UOT0s698ezWn0jqKK2N4A/dUySeb1g8V+oYuIjpwj+xgqN/uIc4uErNH7RMSNgidcx L7i4yONocWbOrq6rw3uV1QIilWrzRaPGnXoFV3WWDZbB0U7TPkO+M8eGRXw2Sg5NADIw mVMszJLlu9gs57jPW2Si59cRQnp7LQFAGN18skKG6tEgZxQM1Pv785X9m/ztBv7Leb7n Hs62o1MuBBo5ce4mlgagq6lMvUX5hum5wmqqZLYdHHnwcAggu6OmMPEi6qUwsbbs/p9X Fm5O6t4T/a9K5SQFOcYmcLlz7mpctgboeJ33YmcXTS4kvTWVfjBnpzlkPYhNvUrih+sb IpFw== X-Gm-Message-State: ALoCoQkgoybW7DZ+2sK+oVrR3wGxRAdtlbG5GdmMpGu8CeTp0UY4UjhpNQh4n/CrNZbZ9hw86zX/ X-Received: by 10.129.131.71 with SMTP id t68mr8415233ywf.266.1448288484731; Mon, 23 Nov 2015 06:21:24 -0800 (PST) Received: from [172.16.0.112] (pool-173-73-126-234.washdc.east.verizon.net. [173.73.126.234]) by smtp.gmail.com with ESMTPSA id w1sm11634410ywe.5.2015.11.23.06.21.23 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 23 Nov 2015 06:21:24 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <385E6AFF-52C3-4E40-A69F-178602A449A7@sn3rd.com> Date: Mon, 23 Nov 2015 09:21:22 -0500 To: "" Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) X-Mailer: Apple Mail (2.3096.5) Archived-At: Subject: [TLS] Early code point assignments for 25519/448 curves X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 14:21:27 -0000 All, We=E2=80=99ve received an early code point assignment for the following = 4 (four) elliptic curve points that will go in the "Supported Groups" = Registry: // ECDH functions. ecdh_x25519 ecdh_x448 // Signature curves. eddsa_ed25519 eddsa_ed448 These points will be included in the following 2 (two) drafts: draft-ietf-tls-tls13 draft-ietf-tls-rfc4492bis. Early code points are permitted in the =E2=80=9CSupported Groups=E2=80=9D = registry and the chairs (that=E2=80=99s us) need to determine whether = there is support for these assignments. Some input has already been = received and those people do not need to respond again to this call, but = we=E2=80=99d like to hear from others whether they support early code = point assignment for these curves. If you do not please state why. = We=E2=80=99re looking for input by November 30th. J&S= From nobody Mon Nov 23 10: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 026261ACD29 for ; Mon, 23 Nov 2015 10:28:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFs_NBClfXFC for ; Mon, 23 Nov 2015 10:28:45 -0800 (PST) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001: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 417AA1A00EE for ; Mon, 23 Nov 2015 10:28:42 -0800 (PST) Received: by igcmv3 with SMTP id mv3so34746158igc.0 for ; Mon, 23 Nov 2015 10:28: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=pbPYYQN+qFZ+VCa6n8z4QRrfan0hQTlIIpFhLbX/sM8=; b=kIuIDwJJR8I2p47Np1qfDWTGDlTGkEEA9py8Z4uVGt5UyqwhV8U0sypzmT+tKQmZ+X /vDDCQhbdr/gf93jVoBo5VBjX0QfImGJ/ksgKvbV7i0TPRV2W8dgnpiRx4714QImh7hr aiOb9M1LI1jeeAQ/L0E3E/4Gg6QMOYtaNOBXdMEkCO4Ufo1EYEzyt6FkGOBY0wpH5JTt /B328kC3V5L6NHDowYgbu+dxQjM073uM7I7SjeqII4tdyTtRDFReR/KDE69GB03Gunfv iJTVRT0kwFnwfeVRRzmUX8mMnmbctwR2mB04ZrXuF5Q1ena4xYJvKh5TqSi7y/FclgrG SAKA== MIME-Version: 1.0 X-Received: by 10.50.6.104 with SMTP id z8mr13829068igz.58.1448303321456; Mon, 23 Nov 2015 10:28:41 -0800 (PST) Received: by 10.36.155.139 with HTTP; Mon, 23 Nov 2015 10:28:41 -0800 (PST) Date: Mon, 23 Nov 2015 10:28:41 -0800 Message-ID: From: Martin Thomson To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] Issue #348: 32bit timestamp in ServerConfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 18:28:47 -0000 >From the issue: <<< As far as I can see, the only timestamp used is expiration_date in the ServerConfiguration (apart from X.509 validity checks which require synchronised clocks). This is defined as seconds since UNIX epoch, and will overflow sooner than later. Maybe either use a relative amount of seconds here, or expand to a 64bit value!? I suggest to use 32bit network byte order (same as ticket_lifetime_hint), which value are the seconds how long this configuration is valid, and thus may be cached for at most this amount of seconds. >>> I don't want to see this change to a relative time. That will mess with our ability to create ServerConfiguration objects that live outside of the handshake. I have no real objection to expanding this to 64bit though. (I'm personally OK with stating that this is modulo 2^32, but recognize how that might result in problems.) From nobody Mon Nov 23 10: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 844EA1ACD7C for ; Mon, 23 Nov 2015 10:37:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q_SxZQY2lmU1 for ; Mon, 23 Nov 2015 10:37:27 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0718.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:718]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 941761ACD7A for ; Mon, 23 Nov 2015 10:37:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fnsOp8UNfdVqHdRjNvuA+iZ60nhWZnFtuZ1I7XMz1Zo=; b=T5B6n3ZYfDnPN6vEG3DumPxcDV/rAub2zvRSuAF3REsIRWxUnXmkzJFRN79d5T02jEUsGTW3wwSCn2ocHMoF8iCgU6GgE0O5+zacEbRvV2CutuS2dyriHrGD+3cwsOlt6YmoYuwiFpnpyxosRZuvtQQv89L8RXAlcdJAUJ8FimM= Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) with Microsoft SMTP Server (TLS) id 15.1.331.20; Mon, 23 Nov 2015 18:37:08 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0331.019; Mon, 23 Nov 2015 18:37:08 +0000 From: Andrei Popov To: Sean Turner , "" Thread-Topic: [TLS] Early code point assignments for 25519/448 curves Thread-Index: AQHRJfpDtA9o6xlel0eT/SSJQcXrIJ6p7uuQ Date: Mon, 23 Nov 2015 18:37:08 +0000 Message-ID: References: <385E6AFF-52C3-4E40-A69F-178602A449A7@sn3rd.com> In-Reply-To: <385E6AFF-52C3-4E40-A69F-178602A449A7@sn3rd.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:a::1d2] x-microsoft-exchange-diagnostics: 1; BLUPR03MB1396; 5:j9lcFnvx0TNGydqMlAL72T/rRYBp8zIUeRN6sKOyyO7FrkGSjdB7PB2MmQZWKLjp88IpV++Mb+OMbwHN2Rfb92nmkXCrcgOsUJC7cK0BgC5lzqVOwCLW/P6sbBXXZ2BecnvmoNYdW/Y/KSZBcQIHMg==; 24:UmkTNGAzzCLi2sIGQl3sqk4j7VISdfMK7vx5FZ+kxi0VmchtWKo7TJ/XVlJkibXdLwJ48v6D1McgNDfQyMx2GZqbyMWEzNQVQ250yX3HlTk= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1396; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(189930954265078); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046)(61426024)(61427024); SRVR:BLUPR03MB1396; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1396; x-forefront-prvs: 07697999E6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(189002)(199003)(92566002)(11100500001)(5004730100002)(10400500002)(105586002)(8990500004)(575784001)(5008740100001)(5005710100001)(81156007)(15975445007)(76576001)(10090500001)(40100003)(2900100001)(77096005)(86362001)(86612001)(99286002)(586003)(87936001)(33656002)(5002640100001)(54356999)(101416001)(106116001)(10290500002)(76176999)(5001770100001)(19580395003)(107886002)(5003600100002)(5001960100002)(97736004)(2950100001)(106356001)(5007970100001)(102836003)(6116002)(189998001)(122556002)(19580405001)(74316001)(50986999)(3826002)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1396; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2015 18:37:08.1552 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1396 Archived-At: Subject: Re: [TLS] Early code point assignments for 25519/448 curves X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 18:37:32 -0000 VGhhbmtzIFNlYW4sDQoNCkkgc3VwcG9ydCBlYXJseSBjb2RlIHBvaW50IGFzc2lnbm1lbnQgZm9y IHRoZXNlIGN1cnZlcy4NCg0KQ2hlZXJzLA0KDQpBbmRyZWkNCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IFRMUyBbbWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgU2VhbiBUdXJuZXINClNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMjMsIDIwMTUgNjoyMSBB TQ0KVG86IDx0bHNAaWV0Zi5vcmc+IDx0bHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbVExTXSBFYXJs eSBjb2RlIHBvaW50IGFzc2lnbm1lbnRzIGZvciAyNTUxOS80NDggY3VydmVzDQoNCkFsbCwNCg0K V2XigJl2ZSByZWNlaXZlZCBhbiBlYXJseSBjb2RlIHBvaW50IGFzc2lnbm1lbnQgZm9yIHRoZSBm b2xsb3dpbmcgNCAoZm91cikgZWxsaXB0aWMgY3VydmUgcG9pbnRzIHRoYXQgd2lsbCBnbyBpbiB0 aGUgIlN1cHBvcnRlZCBHcm91cHMiIFJlZ2lzdHJ5Og0KDQovLyBFQ0RIIGZ1bmN0aW9ucy4NCmVj ZGhfeDI1NTE5DQplY2RoX3g0NDgNCg0KLy8gU2lnbmF0dXJlIGN1cnZlcy4NCmVkZHNhX2VkMjU1 MTkNCmVkZHNhX2VkNDQ4DQoNClRoZXNlIHBvaW50cyB3aWxsIGJlIGluY2x1ZGVkIGluIHRoZSBm b2xsb3dpbmcgMiAodHdvKSBkcmFmdHM6DQoJZHJhZnQtaWV0Zi10bHMtdGxzMTMNCglkcmFmdC1p ZXRmLXRscy1yZmM0NDkyYmlzLg0KDQpFYXJseSBjb2RlIHBvaW50cyBhcmUgcGVybWl0dGVkIGlu IHRoZSDigJxTdXBwb3J0ZWQgR3JvdXBz4oCdIHJlZ2lzdHJ5IGFuZCB0aGUgY2hhaXJzICh0aGF0 4oCZcyB1cykgbmVlZCB0byBkZXRlcm1pbmUgd2hldGhlciB0aGVyZSBpcyBzdXBwb3J0IGZvciB0 aGVzZSBhc3NpZ25tZW50cy4gIFNvbWUgaW5wdXQgaGFzIGFscmVhZHkgYmVlbiByZWNlaXZlZCBh bmQgdGhvc2UgcGVvcGxlIGRvIG5vdCBuZWVkIHRvIHJlc3BvbmQgYWdhaW4gdG8gdGhpcyBjYWxs LCBidXQgd2XigJlkIGxpa2UgdG8gaGVhciBmcm9tIG90aGVycyB3aGV0aGVyIHRoZXkgc3VwcG9y dCBlYXJseSBjb2RlIHBvaW50IGFzc2lnbm1lbnQgZm9yIHRoZXNlIGN1cnZlcy4gIElmIHlvdSBk byBub3QgcGxlYXNlIHN0YXRlIHdoeS4gIFdl4oCZcmUgbG9va2luZyBmb3IgaW5wdXQgYnkgTm92 ZW1iZXIgMzB0aC4NCg0KSiZTDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KVExTIG1haWxpbmcgbGlzdA0KVExTQGlldGYub3JnDQpodHRwczovL25hMDEu c2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy5p ZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZnRscyUwYSZkYXRhPTAxJTdjMDElN2NBbmRy ZWkuUG9wb3YlNDBtaWNyb3NvZnQuY29tJTdjMjYxYzJjN2YzODdhNDM0MDJmYWUwOGQyZjQxMTYz ZjElN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9dTVqZHNiZDB4 TElqVk9Cc3hxaWFlZDNoelA1YzFKQ2VucmNHVzZMVlVWRSUzZA0K From nobody Mon Nov 23 10:56: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 599F11ACDBA for ; Mon, 23 Nov 2015 10:56:55 -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 S8qfcsfY3NFH for ; Mon, 23 Nov 2015 10:56:53 -0800 (PST) Received: from filtteri5.pp.htv.fi (filtteri5.pp.htv.fi [213.243.153.188]) by ietfa.amsl.com (Postfix) with ESMTP id E60CD1ACDCF for ; Mon, 23 Nov 2015 10:56:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by filtteri5.pp.htv.fi (Postfix) with ESMTP id E46335A7318; Mon, 23 Nov 2015 20:56:33 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from smtp5.welho.com ([213.243.153.39]) by localhost (filtteri5.pp.htv.fi [213.243.153.188]) (amavisd-new, port 10024) with ESMTP id rho1nu46k5xS; Mon, 23 Nov 2015 20:56:33 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp5.welho.com (Postfix) with ESMTPSA id 489445BC008; Mon, 23 Nov 2015 20:56:51 +0200 (EET) Date: Mon, 23 Nov 2015 20:56:50 +0200 From: Ilari Liusvaara To: Martin Thomson Message-ID: <20151123185650.GA14878@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Issue #348: 32bit timestamp in ServerConfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 18:56:55 -0000 On Mon, Nov 23, 2015 at 10:28:41AM -0800, Martin Thomson wrote: > >From the issue: > > I don't want to see this change to a relative time. That will mess > with our ability to create ServerConfiguration objects that live > outside of the handshake. > > I have no real objection to expanding this to 64bit though. (I'm > personally OK with stating that this is modulo 2^32, but recognize how > that might result in problems.) I got the idea of using 32-bit sequence number arithmetic there too (window is -2G to 2G seconds around current time). I don't suppose any key will need to have TTL of over ~68 years... -Ilari From nobody Mon Nov 23 11:02: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 D1F5B1ACDE1 for ; Mon, 23 Nov 2015 11:02:16 -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 gH2PGMlog5rQ for ; Mon, 23 Nov 2015 11:02:15 -0800 (PST) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::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 92B6A1ACDD5 for ; Mon, 23 Nov 2015 11:02:15 -0800 (PST) Received: by igcmv3 with SMTP id mv3so35402026igc.0 for ; Mon, 23 Nov 2015 11:02:15 -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=Xw0IHBUK2sppHD2oW3ciQ6jSPWQ5obrHc0BtvAgdO6o=; b=Mqmk0+daeoUAJjwwgRwuAvBoG3pr01s/mQ26OahBfBtObYjAYQVjOvhFQbqzqzPZ89 s3E3HOZ4tzonkvfrpRQyO/Zz6B74NbOSJgu8Kn0m2wFHfwKQYHnmfY5t6hhrFvNLr56b gkrU14dAqS3rHFSE+gYz0KZT2voBZxFcHQc/9NRY2c3/UgwCGlDM3cWNuvjECIDSAke9 vlT2VaIqlX+Nc644c8h1vDQDXV3xQ6J9iE7z90S4rDhSPReq2+Lx4u6IPFBpg2mUzhCf G8YO4LHnoN1gymnJ0nDHjcRJocHd1ndErBe54kHCD+MyvbYn29rsQVf5G1njPsmkOEY8 PZpA== MIME-Version: 1.0 X-Received: by 10.50.6.104 with SMTP id z8mr13972162igz.58.1448305334991; Mon, 23 Nov 2015 11:02:14 -0800 (PST) Received: by 10.36.155.139 with HTTP; Mon, 23 Nov 2015 11:02:14 -0800 (PST) In-Reply-To: <20151123185650.GA14878@LK-Perkele-V2.elisa-laajakaista.fi> References: <20151123185650.GA14878@LK-Perkele-V2.elisa-laajakaista.fi> Date: Mon, 23 Nov 2015 11:02:14 -0800 Message-ID: From: Martin Thomson To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Issue #348: 32bit timestamp in ServerConfiguration X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 19:02:17 -0000 On 23 November 2015 at 10:56, Ilari Liusvaara wrote: > I got the idea of using 32-bit sequence number arithmetic there too > (window is -2G to 2G seconds around current time). I don't suppose > any key will need to have TTL of over ~68 years... I did too, but decoded that 2^64 is just easier. From nobody Mon Nov 23 12:18: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 AE3331B33A4 for ; Mon, 23 Nov 2015 12:18:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.786 X-Spam-Level: X-Spam-Status: No, score=-4.786 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxcRMCeuzIUt for ; Mon, 23 Nov 2015 12:18:05 -0800 (PST) Received: from e37.co.us.ibm.com (e37.co.us.ibm.com [32.97.110.158]) (using TLSv1 with cipher CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84D4D1B33A3 for ; Mon, 23 Nov 2015 12:18:05 -0800 (PST) Received: from localhost by e37.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 23 Nov 2015 13:18:04 -0700 Received: from d03dlp02.boulder.ibm.com (9.17.202.178) by e37.co.us.ibm.com (192.168.1.137) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 23 Nov 2015 13:18:03 -0700 X-IBM-Helo: d03dlp02.boulder.ibm.com X-IBM-MailFrom: dskern@us.ibm.com X-IBM-RcptTo: tls@ietf.org Received: from b03cxnp08027.gho.boulder.ibm.com (b03cxnp08027.gho.boulder.ibm.com [9.17.130.19]) by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id 084663E40041 for ; Mon, 23 Nov 2015 13:18:03 -0700 (MST) Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by b03cxnp08027.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id tANKI2Ft20250868 for ; Mon, 23 Nov 2015 13:18:02 -0700 Received: from d03av05.boulder.ibm.com (localhost [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id tANKI2t8031615 for ; Mon, 23 Nov 2015 13:18:02 -0700 Received: from d40lp02.lotus.com ([9.32.8.79]) by d03av05.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id tANKI17A031553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 23 Nov 2015 13:18:02 -0700 Received: from /spool/local by d40lp02.lotus.com with XMail ESMTP for from ; Mon, 23 Nov 2015 15:17:59 -0500 Received: from smtp.notes.scniris.com (173.192.202.220) by d40lp02.lotus.com (192.147.107.239) with XMail ESMTP; (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256/256) Mon, 23 Nov 2015 15:17:56 -0500 Received: from /spool/local by smtp.notes.scniris.com with smtp.notes.scniris.com ESMTP for from ; Mon, 23 Nov 2015 20:18:58 -0000 Received: from irisa-smtp02.ir3.wdc01.isc4sb.com (10.57.172.131) by smtp.notes.scniris.com (10.102.16.161) with smtp.notes.scniris.com ESMTP; Mon, 23 Nov 2015 20:18:55 -0000 Received: from irisa-mail02.ir3.wdc01.isc4sb.com ([10.102.14.98]) by irisa-smtp02.ir3.wdc01.isc4sb.com with ESMTP id 2015112320173757-133 ; Mon, 23 Nov 2015 20:17:37 +0000 In-Reply-To: References: To: tls@ietf.org MIME-Version: 1.0 X-KeepSent: B1CF98B1:9AA2E9E9-00257F06:006F236C; type=4; name=$KeepSent X-Mailer: IBM Notes Release 9.0.1FP4 Octobe4, 2013 From: "Dave Kern" Date: Mon, 23 Nov 2015 15:17:54 -0500 X-LLNOutbound: False X-TNEFEvaluated: 1 Content-Type: text/plain; charset="US-ASCII" x-cbid: 15112320-0025-0000-0000-00001F01F966 X-IBM-ISS-SpamDetectors: Score=0.40962; BY=0.001898; FL=0; FP=0; FZ=0; HX=0; KW=0; PH=0; SC=0.40962; ST=0; TS=0; UL=0; ISC= X-IBM-ISS-DetailInfo: BY=3.00004605; HX=3.00000236; KW=3.00000007; PH=3.00000004; SC=3.00000121; SDB=6.00621627; UDB=6.00276251; UTC=2015-11-23 20:18:56 x-cbparentid: 15112320-6194-0000-0000-000000520198 Message-Id: X-IBM-ISS-SpamDetectors: X-IBM-ISS-DetailInfo: BY=3.00004605; HX=3.00000236; KW=3.00000007; PH=3.00000004; SC=3.00000121; SDB=6.00621627; UDB=6.00276251; UTC=2015-11-23 20:17:57 X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER Archived-At: Subject: Re: [TLS] Early code point assignments for 25519/448 curves X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 20:18:06 -0000 I support early code point assignment of these curves. Thanks, dave From nobody Mon Nov 23 12:56: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 BB58A1B3AB2 for ; Mon, 23 Nov 2015 12:56:36 -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 QpEVFUOGzqXK for ; Mon, 23 Nov 2015 12:56:34 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D8361B3AAF for ; Mon, 23 Nov 2015 12:56:34 -0800 (PST) Received: by wmww144 with SMTP id w144so113240978wmw.1 for ; Mon, 23 Nov 2015 12:56:33 -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 :content-transfer-encoding:message-id:references:to; bh=bvxC/VYj3Z+G/Or73dzh2WvIMsRECQW23en79wf0sT8=; b=ODL3BXKOWUE8gbUdmTh473Um5J+GASdZ2nWF9ycmDSNqjvc60GbahXKgguT8uSKyTZ LTZYDO3Zx+wkzuFpWy1YTZ8OdP7SXi+GLpfiCek8MSPu3pFbwYONLxWSmPGZX9JAhtMT GlFse94bgSnsv/j0E5XC21os6SabVlX+IB5OFQmZ0J4KdttIxLvtjDkPM0V23RVRbSDM gQUunzGR/lBsW8v7EBTGEIq/hfYbO3WYrL7uqDknynm25SQzq21C8zU4Sn7vpDjz2E/i KlPYWt4s1juJxSR3e/9Qc8Vm6XyqiLLceQhmKLEs1/rjI8F5204CXUVfzn/fhGQ63kqW 0tsg== X-Received: by 10.195.11.101 with SMTP id eh5mr33137471wjd.104.1448312193161; Mon, 23 Nov 2015 12:56:33 -0800 (PST) Received: from [192.168.1.10] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id pc2sm15017706wjb.11.2015.11.23.12.56.31 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 23 Nov 2015 12:56:32 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Yoav Nir In-Reply-To: <385E6AFF-52C3-4E40-A69F-178602A449A7@sn3rd.com> Date: Mon, 23 Nov 2015 22:56:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <45D7CFCA-1ABE-4123-9E27-4DB5B8B6D9DA@gmail.com> References: <385E6AFF-52C3-4E40-A69F-178602A449A7@sn3rd.com> To: Sean Turner X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: "" Subject: Re: [TLS] Early code point assignments for 25519/448 curves X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 20:56:36 -0000 I support early code point assignment. It=E2=80=99s been suggested that as long as the CFRG signature curves = document is not finalized, we should wait with the eddsa_* ones. I = don=E2=80=99t believe so. Anything in any draft is subject to change up = to the time it=E2=80=99s published and people who implement internet = draft should make allowances for such a risk. I see no problem with = assigning numbers now. It does not make sense to ship a version of a = product that you=E2=80=99ll have to support backwards compatibility with = forever. But it is up to implementers to be smart enough about this. Yoav > On 23 Nov 2015, at 4:21 PM, Sean Turner wrote: >=20 > All, >=20 > We=E2=80=99ve received an early code point assignment for the = following 4 (four) elliptic curve points that will go in the "Supported = Groups" Registry: >=20 > // ECDH functions. > ecdh_x25519 > ecdh_x448 >=20 > // Signature curves. > eddsa_ed25519 > eddsa_ed448 >=20 > These points will be included in the following 2 (two) drafts: > draft-ietf-tls-tls13 > draft-ietf-tls-rfc4492bis. >=20 > Early code points are permitted in the =E2=80=9CSupported Groups=E2=80=9D= registry and the chairs (that=E2=80=99s us) need to determine whether = there is support for these assignments. Some input has already been = received and those people do not need to respond again to this call, but = we=E2=80=99d like to hear from others whether they support early code = point assignment for these curves. If you do not please state why. = We=E2=80=99re looking for input by November 30th. >=20 > J&S > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Mon Nov 23 13:16: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 0DC661B344A for ; Mon, 23 Nov 2015 13:16:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHzD63y4eOxx for ; Mon, 23 Nov 2015 13:16:35 -0800 (PST) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B44D91B3452 for ; Mon, 23 Nov 2015 13:16:35 -0800 (PST) Received: by igvg19 with SMTP id g19so82563690igv.1 for ; Mon, 23 Nov 2015 13:16:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Kju35cNb97MxHZeuKkqNnwZDKpU+ivDgXpFCRQ/tq58=; b=swgsnOicXA2lAEqHVQfMnBKB58gjxWbskvirW6/xDFSnGGIAvM9VuhKN7Na3dDuuGG WietvEhd5pq53esjQ7Eru87f75MXttrp/l0YbJtol2AYwJQkmquVZbAKxxMI8y8Ey1VV Ka171qRb6tlhM/0NkKnOuW3T+xHfQzKUdguCVgJbAVQV0i+oRY6OY3MUO3Z8ENhw4bIb IfbkGsB+uFcnHOujC/cnpjS/AponQ28ZlDkI0Yje9p0LTidXN5/HwtxO7JkdwRYbbLHQ sw0v2XjcCkuCpYhlLFV0Ykx/dAUC9lyLjCVWy7aSVXdw6uihsVfgydkvakGYoEP6TFMZ NnsA== MIME-Version: 1.0 X-Received: by 10.50.143.10 with SMTP id sa10mr14797303igb.77.1448313395111; Mon, 23 Nov 2015 13:16:35 -0800 (PST) Received: by 10.36.155.139 with HTTP; Mon, 23 Nov 2015 13:16:35 -0800 (PST) In-Reply-To: <45D7CFCA-1ABE-4123-9E27-4DB5B8B6D9DA@gmail.com> References: <385E6AFF-52C3-4E40-A69F-178602A449A7@sn3rd.com> <45D7CFCA-1ABE-4123-9E27-4DB5B8B6D9DA@gmail.com> Date: Mon, 23 Nov 2015 13:16:35 -0800 Message-ID: From: Martin Thomson To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "" Subject: Re: [TLS] Early code point assignments for 25519/448 curves X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 21:16:40 -0000 On 23 November 2015 at 12:56, Yoav Nir wrote: > It=E2=80=99s been suggested that as long as the CFRG signature curves doc= ument is not finalized, we should wait with the eddsa_* ones. I don=E2=80= =99t believe so. Anything in any draft is subject to change up to the time = it=E2=80=99s published [...] In your opinion, do you see the semantics of the codepoints changing in any meaningful way? It's one thing to say "accept the risks", but if anyone thinks that there are necessary changes forthcoming, that would give me pause. If everyone says that it's highly unlikely, I'm supportive of the notion that we get a codepoint. Are we happy that we will only be needing the PureEdDSA variants and that no-one will be asking for the HashEdDSA versions? I ask because I've heard it suggested (I think Karthik mentioned this) that we might want to sign the transcript directly in TLS 1.3 rather than rely on collision-resistance of the selected hash function. That would be harder without access to HashEdDSA. From nobody Mon Nov 23 13:38: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 1C6C41B34C6 for ; Mon, 23 Nov 2015 13:38:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.886 X-Spam-Level: X-Spam-Status: No, score=-4.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QF3VnIfgHYe6 for ; Mon, 23 Nov 2015 13:38:45 -0800 (PST) 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 62CA81B34C5 for ; Mon, 23 Nov 2015 13:38:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 010B8BE47; Mon, 23 Nov 2015 21:38:43 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4rEFHBew_4I; Mon, 23 Nov 2015 21:38:41 +0000 (GMT) Received: from [10.87.48.91] (unknown [86.46.27.82]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C58C8BE38; Mon, 23 Nov 2015 21:38:40 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1448314721; bh=IHD/W0Y2+lnngpUS9FesM4MiNeU1f9AUrNsDovSXYM0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=mEyLErjlok0AVzHGVdwGqMDt21HYBkFdTLEjULlmhLrzcUaif4dSQmPx+i7/BfpxR 4BAAL/2hvUSrpzldThdADaQCe1nfG/bnEIuW7+ZuMR7nRd5n2DM89JICk1KNh3FB0K REjJrtB/+DqCdwpPbgKz69/hHcbjqPtDiu4+Gbp4= To: Sean Turner , "" References: <385E6AFF-52C3-4E40-A69F-178602A449A7@sn3rd.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56538760.4000909@cs.tcd.ie> Date: Mon, 23 Nov 2015 21:38:40 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <385E6AFF-52C3-4E40-A69F-178602A449A7@sn3rd.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] Early code point assignments for 25519/448 curves X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 21:38:48 -0000 Hiya, On 23/11/15 14:21, Sean Turner wrote: > All, > > We’ve received an early code point assignment for the following 4 Is the word "request" missing above? Either that or I'm forgetting more than I suspected:-) > (four) elliptic curve points that will go in the "Supported Groups" > Registry: > > // ECDH functions. ecdh_x25519 ecdh_x448 > > // Signature curves. eddsa_ed25519 eddsa_ed448 I think 3 of the above are clearly fine now. I'd suggest holding off on eddsa_ed448 for a while until CFRG are done, but maybe establishing now that there is consensus in the WG to allocate that as soon as CFRG are done (where "done" means folks can implement and interop, not that the RFCs are issued). AFAIK the state of play within CFRG on that is that the chairs plan to do a few polls for the couple of remaining issues in a few weeks, so we're not talking about a major delay and to be fair, CFRG recently have delivered more or less when they said they would. My reason to suggest this is just in case CFRG discover some last minute stuff. While burning a code-point for that wouldn't be a problem, we'd be better off without the confusion. But if (the chairs tell me) there's clear consensus for some other action here, I'll consider myself in the rough and go with that. Cheers, S. > > These points will be included in the following 2 (two) drafts: > draft-ietf-tls-tls13 draft-ietf-tls-rfc4492bis. > > Early code points are permitted in the “Supported Groups†registry > and the chairs (that’s us) need to determine whether there is support > for these assignments. Some input has already been received and > those people do not need to respond again to this call, but we’d like > to hear from others whether they support early code point assignment > for these curves. If you do not please state why. We’re looking for > input by November 30th. > > J&S _______________________________________________ TLS mailing list > TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls > From nobody Mon Nov 23 14:02: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 048AE1B3AE4 for ; Mon, 23 Nov 2015 14:02:15 -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, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0pPfsFHsytf for ; Mon, 23 Nov 2015 14:02:13 -0800 (PST) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 245A31B3AEE for ; Mon, 23 Nov 2015 14:02:13 -0800 (PST) Received: by ykdr82 with SMTP id r82so253377804ykd.3 for ; Mon, 23 Nov 2015 14:02:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=TmdBdTI84TZO14R37yI2RDWx3ppSxf01Uj/C4RmAKNM=; b=j/brEeA8G/KGANaG4XZRXg7Mp4eEdiT7Dvmj6zGvTpiyh2ayeUqCeUYsRnsReRP46e CPriFU3+EW/tyXQG3a30Lzkchy002KU1Tf3xPAA+w7jLaxBWtA3QqnZcUBuEAEbmwf6j efNynUV2lAUglErBzklc4cNbkMHpkJFa3skqhBipf21FXcYFZopr00+/XbyJTvzTjJQk ahnEqC1X4Hws441L/sLvxUdTROqnfAC5FezHbbnlSh1gQpHtxrgErE/dlJeX0Vaihy6f dG8cyJOBUFQm1pvxDqZxmD6FwWeuQK77eDCSmIwYEOW9hz0Wanxhh692aM2dw72lNYQG G6Jg== 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=TmdBdTI84TZO14R37yI2RDWx3ppSxf01Uj/C4RmAKNM=; b=WmtaDOnEdtn8goKEJediphEGjJ0/akwrq4arKEQS0MeVIHXXZfohmImD3QiR7ZOaJR 1q28AiTcvmEO+TiBsAUoBdn2vxWYzEUYf2weA+uwzhsSL5JxnjUWZ7lwmjeA5RPYE+Gl qzsOn1mhNmua25Le2khuDly4s2F27x5ztVygTFp3NKWx6zg3/vpR0+IZv/M2t19zKsYf VUOEDVm6dRJcFySct5TXRpzZcCYe1jIHXSTREzJAQbhUgRNrUfOp7aW9QH10Ap3D06OB 5w2VQjGPTOhEAxWFDfpNwERcJcFZozTwagbnNXNF/9CijuJ0JZ7A/iyjjL3Y+9brrOA4 tv+A== X-Gm-Message-State: ALoCoQmermg+WwdOQJ+ze6B5H44lOIcRzt9fR0GWacI8L05j/i9+2rhYcMRHToJFTT7PugWyisPq X-Received: by 10.13.236.10 with SMTP id v10mr29003201ywe.231.1448316132434; Mon, 23 Nov 2015 14:02:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.212.209 with HTTP; Mon, 23 Nov 2015 14:01:32 -0800 (PST) In-Reply-To: <56538760.4000909@cs.tcd.ie> References: <385E6AFF-52C3-4E40-A69F-178602A449A7@sn3rd.com> <56538760.4000909@cs.tcd.ie> From: Eric Rescorla Date: Mon, 23 Nov 2015 14:01:32 -0800 Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=94eb2c0889dc98d56b05253c60bf Archived-At: Cc: "" Subject: Re: [TLS] Early code point assignments for 25519/448 curves X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 22:02:15 -0000 --94eb2c0889dc98d56b05253c60bf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable if it's only a few weeks, let's just do all the signature code points then. -Ekr On Mon, Nov 23, 2015 at 1:38 PM, Stephen Farrell wrote: > > Hiya, > > On 23/11/15 14:21, Sean Turner wrote: > > All, > > > > We=E2=80=99ve received an early code point assignment for the following= 4 > > Is the word "request" missing above? Either that or I'm forgetting > more than I suspected:-) > > > (four) elliptic curve points that will go in the "Supported Groups" > > Registry: > > > > // ECDH functions. ecdh_x25519 ecdh_x448 > > > > // Signature curves. eddsa_ed25519 eddsa_ed448 > > I think 3 of the above are clearly fine now. > > I'd suggest holding off on eddsa_ed448 for a while until CFRG > are done, but maybe establishing now that there is consensus in > the WG to allocate that as soon as CFRG are done (where "done" > means folks can implement and interop, not that the RFCs are > issued). > > AFAIK the state of play within CFRG on that is that the chairs > plan to do a few polls for the couple of remaining issues in > a few weeks, so we're not talking about a major delay and to > be fair, CFRG recently have delivered more or less when they > said they would. > > My reason to suggest this is just in case CFRG discover some > last minute stuff. While burning a code-point for that wouldn't > be a problem, we'd be better off without the confusion. > > But if (the chairs tell me) there's clear consensus for some > other action here, I'll consider myself in the rough and go with > that. > > Cheers, > S. > > > > > > These points will be included in the following 2 (two) drafts: > > draft-ietf-tls-tls13 draft-ietf-tls-rfc4492bis. > > > > Early code points are permitted in the =E2=80=9CSupported Groups=E2=80= =9D registry > > and the chairs (that=E2=80=99s us) need to determine whether there is s= upport > > for these assignments. Some input has already been received and > > those people do not need to respond again to this call, but we=E2=80=99= d like > > to hear from others whether they support early code point assignment > > for these curves. If you do not please state why. We=E2=80=99re looki= ng for > > input by November 30th. > > > > 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 > --94eb2c0889dc98d56b05253c60bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
if it's only a few weeks, let's just do all the si= gnature code points
then.

-Ekr

<= div class=3D"gmail_extra">
On Mon, Nov 23, 20= 15 at 1:38 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie><= /span> wrote:

Hiya,

On 23/11/15 14:21, Sean Turner wrote:
> All,
>
> We=E2=80=99ve received an early code point assignment for the followin= g 4

Is the word "request" missing above? Either that or I'= m forgetting
more than I suspected:-)

> (four) elliptic curve points that will go in the "Supported Group= s"
> Registry:
>
> // ECDH functions. ecdh_x25519 ecdh_x448
>
> // Signature curves. eddsa_ed25519 eddsa_ed448

I think 3 of the above are clearly fine now.

I'd suggest holding off on eddsa_ed448 for a while until CFRG
are done, but maybe establishing now that there is consensus in
the WG to allocate that as soon as CFRG are done (where "done" means folks can implement and interop, not that the RFCs are
issued).

AFAIK the state of play within CFRG on that is that the chairs
plan to do a few polls for the couple of remaining issues in
a few weeks, so we're not talking about a major delay and to
be fair, CFRG recently have delivered more or less when they
said they would.

My reason to suggest this is just in case CFRG discover some
last minute stuff. While burning a code-point for that wouldn't
be a problem, we'd be better off without the confusion.

But if (the chairs tell me) there's clear consensus for some
other action here, I'll consider myself in the rough and go with
that.

Cheers,
S.


>
> These points will be included in the following 2 (two) drafts:
> draft-ietf-tls-tls13 draft-ietf-tls-rfc4492bis.
>
> Early code points are permitted in the =E2=80=9CSupported Groups=E2=80= =9D registry
> and the chairs (that=E2=80=99s us) need to determine whether there is = support
> for these assignments.=C2=A0 Some input has already been received and<= br> > those people do not need to respond again to this call, but we=E2=80= =99d like
> to hear from others whether they support early code point assignment > for these curves.=C2=A0 If you do not please state why.=C2=A0 We=E2=80= =99re looking for
> input by November 30th.
>
> J&S _______________________________________________ TLS mailing li= st
> TLS@ietf.org https= ://www.ietf.org/mailman/listinfo/tls
>

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

--94eb2c0889dc98d56b05253c60bf-- From nobody Mon Nov 23 14:08: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 D1CB51B3B04 for ; Mon, 23 Nov 2015 14:08:14 -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 Md170xHzfSQa for ; Mon, 23 Nov 2015 14:08:12 -0800 (PST) Received: from filtteri5.pp.htv.fi (filtteri5.pp.htv.fi [213.243.153.188]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2051B3B02 for ; Mon, 23 Nov 2015 14:08:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by filtteri5.pp.htv.fi (Postfix) with ESMTP id 1A6CB5A6535; Tue, 24 Nov 2015 00:07:54 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from smtp5.welho.com ([213.243.153.39]) by localhost (filtteri5.pp.htv.fi [213.243.153.188]) (amavisd-new, port 10024) with ESMTP id c6yED6g7XYWt; Tue, 24 Nov 2015 00:07:53 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp5.welho.com (Postfix) with ESMTPSA id 6AE4B5BC003; Tue, 24 Nov 2015 00:08:11 +0200 (EET) Date: Tue, 24 Nov 2015 00:08:10 +0200 From: Ilari Liusvaara To: Martin Thomson Message-ID: <20151123220810.GA15073@LK-Perkele-V2.elisa-laajakaista.fi> References: <385E6AFF-52C3-4E40-A69F-178602A449A7@sn3rd.com> <45D7CFCA-1ABE-4123-9E27-4DB5B8B6D9DA@gmail.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.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "" Subject: Re: [TLS] Early code point assignments for 25519/448 curves X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 22:08:15 -0000 On Mon, Nov 23, 2015 at 01:16:35PM -0800, Martin Thomson wrote: > On 23 November 2015 at 12:56, Yoav Nir wrote: > > It’s been suggested that as long as the CFRG signature curves > > document is not finalized, we should wait with the eddsa_* ones. > > I don’t believe so. Anything in any draft is subject to change up > > to the time it’s published [...] > > In your opinion, do you see the semantics of the codepoints changing > in any meaningful way? It's one thing to say "accept the risks", but > if anyone thinks that there are necessary changes forthcoming, that > would give me pause. If everyone says that it's highly unlikely, I'm > supportive of the notion that we get a codepoint. My personal view is (I haven't asked Simon about this) is that: - Ed25519 is currently technically stable. There seems to be consensus not change it in any way that would break verification. - Ed448 is unimplementable right now due to two missing functions. - Once those two are missing (there is call for proposals this week) functions are decided, Ed448 should become technically stable. > Are we happy that we will only be needing the PureEdDSA variants and > that no-one will be asking for the HashEdDSA versions? I ask because > I've heard it suggested (I think Karthik mentioned this) that we might > want to sign the transcript directly in TLS 1.3 rather than rely on > collision-resistance of the selected hash function. That would be > harder without access to HashEdDSA. I would say that using HashEdDSA is a bad idea in that case. HashEdDSA has fixed "prehash" function and if that hash breaks, the HashEdDSA scheme breaks (the same is not true w.r.t. hash function for PureEdDSA). Also, the prehashes might not be the same for Ed25519ph and Ed448ph, plus I consider interfaces that let one use this dangerous (IUF signing is dangerous!). If one wants to have the entiere transcript signed in reasonable way, one would have to implement hash firewalling at TLS level and require PureEdDSA. If doing that, might also be good idea to throw a prefix that screws many formats ('1E 80 00 00' might be one, it should screw at least ASN.1, JSON and CBOR). Also, the absence of indication of PRF hash in the signed data[1] bugs me, since I need to assume CCR (CR of both hashes does not imply CCR) in order to show security. [1] Heck, that indication was in my original proposal (I didn't quite understand its significance back then). -Ilari From nobody Mon Nov 23 14: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 F19731B3B38 for ; Mon, 23 Nov 2015 14:20:16 -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 z8jLPCwExAm4 for ; Mon, 23 Nov 2015 14:20:15 -0800 (PST) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF6891B3B37 for ; Mon, 23 Nov 2015 14:20:15 -0800 (PST) Received: by igcmv3 with SMTP id mv3so39017830igc.0 for ; Mon, 23 Nov 2015 14:20:15 -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=ndoSFRDRz7UjyR53V/3E5qPdHbmri1KyD9aaLecDcE8=; b=JmhWW7vAYt2yjdsEGGcNwlthqsf12PQ4bhXvEJGHXNUPoYkBnXEYfbM8UUHKiSxjiX Os+YcRy6ETVolLtaC/GRcwlFaC74+/SvFPvrenVi0zlkIBwDOS8KrhKSjgEPnrLpUe7R m3McxAsj3zSTI6ERtOoTLs5KX55hJEG2x9RsooPRcvQKoasmBx7P85NRAEKGQh/nG6HX f+5mUJes8zs9ZpfuAzr30O4ASrgywuQu6zXeZa9DeFzkEo6ODKUSPDURQrx3RcMa5YEY J2uWASpw9UKLNUyPbrh2ShCjZpf2UW/Xhqy5Z/PH9AaoY+1+r1Rw4PIastm4GKGjLUvV LFrA== MIME-Version: 1.0 X-Received: by 10.50.143.10 with SMTP id sa10mr15059406igb.77.1448317215176; Mon, 23 Nov 2015 14:20:15 -0800 (PST) Received: by 10.36.155.139 with HTTP; Mon, 23 Nov 2015 14:20:15 -0800 (PST) In-Reply-To: <20151123220810.GA15073@LK-Perkele-V2.elisa-laajakaista.fi> References: <385E6AFF-52C3-4E40-A69F-178602A449A7@sn3rd.com> <45D7CFCA-1ABE-4123-9E27-4DB5B8B6D9DA@gmail.com> <20151123220810.GA15073@LK-Perkele-V2.elisa-laajakaista.fi> Date: Mon, 23 Nov 2015 14:20:15 -0800 Message-ID: From: Martin Thomson To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] Early code point assignments for 25519/448 curves X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 22:20:17 -0000 On 23 November 2015 at 14:08, Ilari Liusvaara wrote: > Also, the prehashes might not be the same for Ed25519ph and Ed448ph, > plus I consider interfaces that let one use this dangerous (IUF > signing is dangerous!). That suggests that the construction of CertificateVerify is dangerous in the same way, doesn't it? From nobody Mon Nov 23 15:01: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 E557D1ACEE7 for ; Mon, 23 Nov 2015 15:01:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Y3Z4gMVAzWx for ; Mon, 23 Nov 2015 15:01:17 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 409871ACEE4 for ; Mon, 23 Nov 2015 15:01:17 -0800 (PST) Received: from [173.75.83.132] (helo=Williams-MacBook-Pro.local) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1a106c-0005w1-BD for tls@ietf.org; Mon, 23 Nov 2015 18:01:06 -0500 Date: Mon, 23 Nov 2015 15:01:01 -0800 From: Bill Frantz To: "" X-Priority: 3 In-Reply-To: <20151123220810.GA15073@LK-Perkele-V2.elisa-laajakaista.fi> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.3.1 (422) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec799930fc12bc016f2334303a7d0479f910350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 173.75.83.132 Archived-At: Subject: Re: [TLS] Early code point assignments for 25519/448 curves X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 23:01:19 -0000 On 11/24/15 at 2:08 PM, ilariliusvaara@welho.com (Ilari=20 Liusvaara) wrote: >My personal view is (I haven't asked Simon about this) is that: >- Ed25519 is currently technically stable. There seems to be consensus >not change it in any way that would break verification. >- Ed448 is unimplementable right now due to two missing functions. >- Once those two are missing (there is call for proposals this >week) functions are decided, Ed448 should become technically >stable. I would prefer not to assign a code point until we know what it=20 means. (i.e. can write code which interoperates.) On 11/23/15 at 2:01 PM, ekr@rtfm.com (Eric Rescorla) wrote: >if it's only a few weeks, let's just do all the signature code points >then. I would like to hear from implementers about how much this delay=20 would affect them. We're coming into the December madness, so=20 perhaps they want to spend time with their families. :-) Otherwise, I'm in favor of early code points. We can always burn=20 ones we dont want. We can either document them as obsolete, do=20 not use, or if deployment is low enough, reassign them later if needed. Cheers - Bill ----------------------------------------------------------------------- Bill Frantz | "The only thing we have to | Periwinkle (408)356-8506 | fear is fear itself." - FDR | 16345=20 Englewood Ave www.pwpconsult.com | Inaugural address, 3/4/1933 | Los Gatos,=20 CA 95032 From nobody Mon Nov 23 21:54: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 3501E1B2DD9 for ; Mon, 23 Nov 2015 21:54:26 -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 BcsbaJ5TsNoo for ; Mon, 23 Nov 2015 21:54:23 -0800 (PST) Received: from filtteri1.pp.htv.fi (filtteri1.pp.htv.fi [213.243.153.184]) by ietfa.amsl.com (Postfix) with ESMTP id ABEDF1B2DD1 for ; Mon, 23 Nov 2015 21:54:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by filtteri1.pp.htv.fi (Postfix) with ESMTP id 8959C21BB02; Tue, 24 Nov 2015 07:54:22 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from smtp4.welho.com ([213.243.153.38]) by localhost (filtteri1.pp.htv.fi [213.243.153.184]) (amavisd-new, port 10024) with ESMTP id SUHCa0Jz+dd5; Tue, 24 Nov 2015 07:54:22 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp4.welho.com (Postfix) with ESMTPSA id 5F4085BC019; Tue, 24 Nov 2015 07:54:22 +0200 (EET) Date: Tue, 24 Nov 2015 07:54:21 +0200 From: Ilari Liusvaara To: Martin Thomson Message-ID: <20151124055421.GA15495@LK-Perkele-V2.elisa-laajakaista.fi> References: <385E6AFF-52C3-4E40-A69F-178602A449A7@sn3rd.com> <45D7CFCA-1ABE-4123-9E27-4DB5B8B6D9DA@gmail.com> <20151123220810.GA15073@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "" Subject: Re: [TLS] Early code point assignments for 25519/448 curves X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 05:54:26 -0000 On Mon, Nov 23, 2015 at 02:20:15PM -0800, Martin Thomson wrote: > On 23 November 2015 at 14:08, Ilari Liusvaara wrote: > > Also, the prehashes might not be the same for Ed25519ph and Ed448ph, > > plus I consider interfaces that let one use this dangerous (IUF > > signing is dangerous!). > > That suggests that the construction of CertificateVerify is dangerous > in the same way, doesn't it? The problem is that in general, one must not act on invalid data (and IUF signatures positively encourage acting on invalid data), but in case of TLS CertificateVerify, one is expected to act on data, even if invalid, and TLS protocol is designed with that in mind. -Ilari From nobody Tue Nov 24 03:50:59 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD3D11A1AFF for ; Tue, 24 Nov 2015 03:50:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.596 X-Spam-Level: X-Spam-Status: No, score=-0.596 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, HTTPS_HTTP_MISMATCH=1.989, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNeoxQ9U3EYZ for ; Tue, 24 Nov 2015 03:50:56 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id CAE8B1A1AFC for ; Tue, 24 Nov 2015 03:50:55 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 3498B43348B for ; Tue, 24 Nov 2015 11:50:55 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 1E36743341C for ; Tue, 24 Nov 2015 11:50:55 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1448365855; bh=JdNwbyO4gowdXraHQEFTGtweygEJhVD5wY0ccMQKcjw=; l=20530; h=From:To:Date:References:In-Reply-To:From; b=tCJIBSF5BV1AkZSXT8jljafksZpWxNgMAvBlBTJESrmXvsJxn/2PGahU5d0WZwmTY qyrHdOaPwlLjbORYeNA0d2jczWsf2fCh0LBzfA2C3chb3hX3iDfG71yHwUFOabtKl2 avMNBn8zUOPprn92WDN6GpHPm0UV2UdhYzL4CF9Q= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 1B10B2049 for ; Tue, 24 Nov 2015 11:50:55 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 24 Nov 2015 06:50:54 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1076.000; Tue, 24 Nov 2015 06:50:54 -0500 From: "Salz, Rich" To: "tls@ietf.org" Thread-Topic: [acme] Fixed missing references (#48) Thread-Index: AQHRJpzlFQ/D6nGQukufm2+G9vHt4J6rD2UQ Date: Tue, 24 Nov 2015 11:50:53 +0000 Message-ID: <9946898ad4e341d8bebede43a0d66de2@usma1ex-dag1mb1.msg.corp.akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.99] Content-Type: multipart/alternative; boundary="_000_9946898ad4e341d8bebede43a0d66de2usma1exdag1mb1msgcorpak_" MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] [acme] Fixed missing references (#48) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 11:50:58 -0000 --_000_9946898ad4e341d8bebede43a0d66de2usma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmljaGFyZCwNCg0KVGhpcyBpcyBlZGl0b3JpYWwgYW5kIHlvdSBzaG91bGQganVzdCBtZXJnZSBp dC4NCg0KRnJvbTogRG9taW5pYyBbbWFpbHRvOm5vdGlmaWNhdGlvbnNAZ2l0aHViLmNvbV0NClNl bnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDI0LCAyMDE1IDQ6NDYgQU0NClRvOiBpZXRmLXdnLWFjbWUv YWNtZQ0KU3ViamVjdDogW2FjbWVdIEZpeGVkIG1pc3NpbmcgcmVmZXJlbmNlcyAoIzQ4KQ0KDQoN Ckkgd2FzIHVuYWJsZSB0byBnZW5lcmF0ZSB0aGUgbGF0ZXN0IGRyYWZ0IHVzaW5nIG1ha2UuIFRo aXMgUFIgZml4ZXMgdGhlIG1pc3NpbmcgcmVmZXJlbmNlcy4NCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCllvdSBjYW4gdmlldywgY29tbWVudCBvbiwgb3IgbWVyZ2UgdGhpcyBw dWxsIHJlcXVlc3Qgb25saW5lIGF0Og0KDQogIGh0dHBzOi8vZ2l0aHViLmNvbS9pZXRmLXdnLWFj bWUvYWNtZS9wdWxsLzQ4PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/ dT1odHRwcy0zQV9fZ2l0aHViLmNvbV9pZXRmLTJEd2ctMkRhY21lX2FjbWVfcHVsbF80OCZkPUN3 TUNhUSZjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmcj00TE0wR2JSMGg5RnZ4ODZGdHNLSS13Jm09 M0hBaVhrUFdld2dxd2RYLS0wN0ptUkhXRlNYY0xYWFR5X0JYSHVLM2F3OCZzPTJkeDl4cHI5SGs3 VjlkOGVsdnF6c2VqN1FHUUE1eV84dTg0a1EwaHJUQlUmZT0+DQoNCkNvbW1pdCBTdW1tYXJ5DQoN CiAgKiAgIEZpeGVkIG1pc3NpbmcgcmVmZXJlbmNlcw0KDQpGaWxlIENoYW5nZXMNCg0KICAqICAg TSBkcmFmdC1pZXRmLWFjbWUtYWNtZS5tZDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j b20vdjIvdXJsP3U9aHR0cHMtM0FfX2dpdGh1Yi5jb21faWV0Zi0yRHdnLTJEYWNtZV9hY21lX3B1 bGxfNDhfZmlsZXMtMjNkaWZmLTJEMCZkPUN3TUNhUSZjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcm cj00TE0wR2JSMGg5RnZ4ODZGdHNLSS13Jm09M0hBaVhrUFdld2dxd2RYLS0wN0ptUkhXRlNYY0xY WFR5X0JYSHVLM2F3OCZzPW9ZM1ZTZFA1eTJfVjN0aWZEclRlTDVJN19MWEItNE8zOGREZHJlMndt cWsmZT0+ICg3KQ0KDQpQYXRjaCBMaW5rczoNCg0KICAqICAgaHR0cHM6Ly9naXRodWIuY29tL2ll dGYtd2ctYWNtZS9hY21lL3B1bGwvNDgucGF0Y2g8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p bnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19naXRodWIuY29tX2lldGYtMkR3Zy0yRGFjbWVfYWNt ZV9wdWxsXzQ4LnBhdGNoJmQ9Q3dNQ2FRJmM9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZyPTRMTTBH YlIwaDlGdng4NkZ0c0tJLXcmbT0zSEFpWGtQV2V3Z3F3ZFgtLTA3Sm1SSFdGU1hjTFhYVHlfQlhI dUszYXc4JnM9LVhDa0xNd3U2NTJ1bDE1bzBjUllZQ2xrcGpNMWFuNW5GRDhURG1vOWh3MCZlPT4N CiAgKiAgIGh0dHBzOi8vZ2l0aHViLmNvbS9pZXRmLXdnLWFjbWUvYWNtZS9wdWxsLzQ4LmRpZmY8 aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19naXRo dWIuY29tX2lldGYtMkR3Zy0yRGFjbWVfYWNtZV9wdWxsXzQ4LmRpZmYmZD1Dd01DYVEmYz05Nlpi WlpjYU1GNHcwRjRqcE42TFpnJnI9NExNMEdiUjBoOUZ2eDg2RnRzS0ktdyZtPTNIQWlYa1BXZXdn cXdkWC0tMDdKbVJIV0ZTWGNMWFhUeV9CWEh1SzNhdzgmcz01YWEtNG16Q1RjTS1FOXJGNjZ0elBG b0xIeExSSUFzLTVyX2VQenJtV1VFJmU9Pg0KDQrigJQNClJlcGx5IHRvIHRoaXMgZW1haWwgZGly ZWN0bHkgb3IgdmlldyBpdCBvbiBHaXRIdWI8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu Y29tL3YyL3VybD91PWh0dHBzLTNBX19naXRodWIuY29tX2lldGYtMkR3Zy0yRGFjbWVfYWNtZV9w dWxsXzQ4JmQ9Q3dNQ2FRJmM9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZyPTRMTTBHYlIwaDlGdng4 NkZ0c0tJLXcmbT0zSEFpWGtQV2V3Z3F3ZFgtLTA3Sm1SSFdGU1hjTFhYVHlfQlhIdUszYXc4JnM9 MmR4OXhwcjlIazdWOWQ4ZWx2cXpzZWo3UUdRQTV5Xzh1ODRrUTBoclRCVSZlPT4uDQo= --_000_9946898ad4e341d8bebede43a0d66de2usma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6 MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpoNA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTsNCgltc28tc3R5bGUtbGluazoiSGVhZGluZyA0IENoYXIiOw0KCW1zby1tYXJnaW4tdG9wLWFs dDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJZm9udC13ZWlnaHQ6Ym9sZDt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv bGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uSGVhZGluZzRDaGFyDQoJ e21zby1zdHlsZS1uYW1lOiJIZWFkaW5nIDQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk7 DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgNCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkgTGln aHQiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzJFNzRCNTsNCglmb250LXN0eWxlOml0YWxpYzt9DQpz cGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0K CXttc28tbGlzdC1pZDoxODQ3NDAyNjU0Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo1NTQ3NTI3 ODY7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZl bDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVs NQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsOQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjE5OTE4NjEw Mzk7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0yMDA1MzQ3Mjg2O30NCkBsaXN0IGwxOmxldmVs MQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3Rv cDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlz dCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDoyMDg4OTYxNTI5Ow0KCW1zby1saXN0LXRlbXBs YXRlLWlkczotMTc1NTk0ODQ3Njt9DQpAbGlzdCBsMjpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwyOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGkt Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDI6bGV2ZWwzDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIu MGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDI6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2 ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw3DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDI6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJv dHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5SaWNoYXJkLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+VGhpcyBpcyBlZGl0b3JpYWwgYW5kIHlvdSBzaG91bGQganVzdCBtZXJnZSBpdC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4gRG9taW5pYyBbbWFpbHRvOm5vdGlmaWNhdGlvbnNAZ2l0aHViLmNvbV0NCjxicj4NCjxiPlNl bnQ6PC9iPiBUdWVzZGF5LCBOb3ZlbWJlciAyNCwgMjAxNSA0OjQ2IEFNPGJyPg0KPGI+VG86PC9i PiBpZXRmLXdnLWFjbWUvYWNtZTxicj4NCjxiPlN1YmplY3Q6PC9iPiBbYWNtZV0gRml4ZWQgbWlz c2luZyByZWZlcmVuY2VzICgjNDgpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cD5JIHdhcyB1bmFibGUgdG8gZ2VuZXJh dGUgdGhlIGxhdGVzdCBkcmFmdCB1c2luZyBtYWtlLiBUaGlzIFBSIGZpeGVzIHRoZSBtaXNzaW5n IHJlZmVyZW5jZXMuPG86cD48L286cD48L3A+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWdu PSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9 IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0KPC9kaXY+DQo8aDQ+WW91IGNhbiB2aWV3LCBjb21tZW50 IG9uLCBvciBtZXJnZSB0aGlzIHB1bGwgcmVxdWVzdCBvbmxpbmUgYXQ6PG86cD48L286cD48L2g0 Pg0KPHA+Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu Y29tL3YyL3VybD91PWh0dHBzLTNBX19naXRodWIuY29tX2lldGYtMkR3Zy0yRGFjbWVfYWNtZV9w dWxsXzQ4JmFtcDtkPUN3TUNhUSZhbXA7Yz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJmFtcDtyPTRM TTBHYlIwaDlGdng4NkZ0c0tJLXcmYW1wO209M0hBaVhrUFdld2dxd2RYLS0wN0ptUkhXRlNYY0xY WFR5X0JYSHVLM2F3OCZhbXA7cz0yZHg5eHByOUhrN1Y5ZDhlbHZxenNlajdRR1FBNXlfOHU4NGtR MGhyVEJVJmFtcDtlPSI+aHR0cHM6Ly9naXRodWIuY29tL2lldGYtd2ctYWNtZS9hY21lL3B1bGwv NDg8L2E+PG86cD48L286cD48L3A+DQo8aDQ+Q29tbWl0IFN1bW1hcnk8bzpwPjwvbzpwPjwvaDQ+ DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxl dmVsMSBsZm8xIj4NCkZpeGVkIG1pc3NpbmcgcmVmZXJlbmNlczxvOnA+PC9vOnA+PC9saT48L3Vs Pg0KPGg0PkZpbGUgQ2hhbmdlczxvOnA+PC9vOnA+PC9oND4NCjx1bCB0eXBlPSJkaXNjIj4NCjxs aSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPg0KPHN0cm9uZz5N PC9zdHJvbmc+IDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91 cmw/dT1odHRwcy0zQV9fZ2l0aHViLmNvbV9pZXRmLTJEd2ctMkRhY21lX2FjbWVfcHVsbF80OF9m aWxlcy0yM2RpZmYtMkQwJmFtcDtkPUN3TUNhUSZhbXA7Yz05NlpiWlpjYU1GNHcwRjRqcE42TFpn JmFtcDtyPTRMTTBHYlIwaDlGdng4NkZ0c0tJLXcmYW1wO209M0hBaVhrUFdld2dxd2RYLS0wN0pt UkhXRlNYY0xYWFR5X0JYSHVLM2F3OCZhbXA7cz1vWTNWU2RQNXkyX1YzdGlmRHJUZUw1STdfTFhC LTRPMzhkRGRyZTJ3bXFrJmFtcDtlPSI+DQpkcmFmdC1pZXRmLWFjbWUtYWNtZS5tZDwvYT4gKDcp IDxvOnA+PC9vOnA+PC9saT48L3VsPg0KPGg0PlBhdGNoIExpbmtzOjxvOnA+PC9vOnA+PC9oND4N Cjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDIgbGV2 ZWwxIGxmbzMiPg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy L3VybD91PWh0dHBzLTNBX19naXRodWIuY29tX2lldGYtMkR3Zy0yRGFjbWVfYWNtZV9wdWxsXzQ4 LnBhdGNoJmFtcDtkPUN3TUNhUSZhbXA7Yz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJmFtcDtyPTRM TTBHYlIwaDlGdng4NkZ0c0tJLXcmYW1wO209M0hBaVhrUFdld2dxd2RYLS0wN0ptUkhXRlNYY0xY WFR5X0JYSHVLM2F3OCZhbXA7cz0tWENrTE13dTY1MnVsMTVvMGNSWVlDbGtwak0xYW41bkZEOFRE bW85aHcwJmFtcDtlPSI+aHR0cHM6Ly9naXRodWIuY29tL2lldGYtd2ctYWNtZS9hY21lL3B1bGwv NDgucGF0Y2g8L2E+PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxp c3Q6bDIgbGV2ZWwxIGxmbzMiPg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p bnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19naXRodWIuY29tX2lldGYtMkR3Zy0yRGFjbWVfYWNt ZV9wdWxsXzQ4LmRpZmYmYW1wO2Q9Q3dNQ2FRJmFtcDtjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcm YW1wO3I9NExNMEdiUjBoOUZ2eDg2RnRzS0ktdyZhbXA7bT0zSEFpWGtQV2V3Z3F3ZFgtLTA3Sm1S SFdGU1hjTFhYVHlfQlhIdUszYXc4JmFtcDtzPTVhYS00bXpDVGNNLUU5ckY2NnR6UEZvTEh4TFJJ QXMtNXJfZVB6cm1XVUUmYW1wO2U9Ij5odHRwczovL2dpdGh1Yi5jb20vaWV0Zi13Zy1hY21lL2Fj bWUvcHVsbC80OC5kaWZmPC9hPjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgc3R5bGU9Ii13ZWJr aXQtdGV4dC1zaXplLWFkanVzdDpub25lIj48c3BhbiBzdHlsZT0iY29sb3I6IzY2NjY2NiI+4oCU PGJyPg0KUmVwbHkgdG8gdGhpcyBlbWFpbCBkaXJlY3RseSBvciA8YSBocmVmPSJodHRwczovL3Vy bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2dpdGh1Yi5jb21faWV0 Zi0yRHdnLTJEYWNtZV9hY21lX3B1bGxfNDgmYW1wO2Q9Q3dNQ2FRJmFtcDtjPTk2WmJaWmNhTUY0 dzBGNGpwTjZMWmcmYW1wO3I9NExNMEdiUjBoOUZ2eDg2RnRzS0ktdyZhbXA7bT0zSEFpWGtQV2V3 Z3F3ZFgtLTA3Sm1SSFdGU1hjTFhYVHlfQlhIdUszYXc4JmFtcDtzPTJkeDl4cHI5SGs3VjlkOGVs dnF6c2VqN1FHUUE1eV84dTg0a1EwaHJUQlUmYW1wO2U9Ij4NCnZpZXcgaXQgb24gR2l0SHViPC9h Pi48aW1nIGJvcmRlcj0iMCIgd2lkdGg9IjEiIGhlaWdodD0iMSIgaWQ9Il94MDAwMF9pMTAyNiIg c3JjPSJodHRwczovL2dpdGh1Yi5jb20vbm90aWZpY2F0aW9ucy9iZWFjb24vQUdfaWxPN0VZanVn TzIxbEtRRWx1MXJCNEFoVzVfWGNrczVwSkNsSWdhSnBaTTRHb09QVi5naWYiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_9946898ad4e341d8bebede43a0d66de2usma1exdag1mb1msgcorpak_-- From nobody Tue Nov 24 08:26: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 8204F1A900A for ; Tue, 24 Nov 2015 08:26:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.064 X-Spam-Level: X-Spam-Status: No, score=-0.064 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQMOW7Kvms76 for ; Tue, 24 Nov 2015 08:26:16 -0800 (PST) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001: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 81A971A9032 for ; Tue, 24 Nov 2015 08:25:54 -0800 (PST) Received: by ioir85 with SMTP id r85so25482986ioi.1 for ; Tue, 24 Nov 2015 08:25:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=2skNlj1OTKQJqUvpTLpjMn6Ach/dgohRyKwMMlkhGKI=; b=DRpX/y4edtOZtEH0+8gf1q7HUVk2ztBmpihH5/UjJKnsCxKoe6wsWYO1IEFWWDlRSo J4tfc5/ClMk4nx7NWp7Zz3BVheszH589q9rHp5TF0yubWNPP/ibVvcH2zGiCOloGfv23 P3aoRezaaCOCawzdmVm7C5Nqt5gWzb5EF6WWEP2lEK/7cMRekakfZaeRC9U8nZ8zq5m/ 1GCQ/mxDPngMPo3TZRip82dTBetlNzGAsywop4FvzvTmKdSHPxh21IzlN7XtE9kcGyST abJrVvwTQfk2Sqh3AfYqDnYvaP6L+ugiGwd42ONBKBuH/f/yKpt3dE6g7cf1m3Q++pHZ dEsA== 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=2skNlj1OTKQJqUvpTLpjMn6Ach/dgohRyKwMMlkhGKI=; b=jEepdEfqrQsz8jKlMqJ7IXSQL8cm6YPzumzd9wrfoXjhDlOmhwI/HlZYZOa0+uTBeb 2Kn23/EqP/+sQ9MOAIgg0ACFiR2j/IekOO+RYlwfMNufVWEqf0DoS6syZqC2YDX70D5+ AscFfI6YA1uc2npMHDaU/K+YSFHXUR1jDR1OCuWYZEydAuFxC4iLUoHjjEjJyZMAJSiL BJBDHe+0kY+3Y3tVYQaFAbmwHif/J+TxK9XSj3fPD5cKQ9FkQBgL/Zw6N4XgCXJ+16h4 dS87kME24kdJynezWosGia0kIU5GBgJVZ0hz5sPPk15pRCrOtgKC0XySeJAY2TfGLbds VOkg== X-Gm-Message-State: ALoCoQmqOyc73Y3MH+kvTaUSjcpyPPWfnz5cIIWMv68Jvfo1Agl1VV9GrkkM87S/uD3Zj8Nk4m2G MIME-Version: 1.0 X-Received: by 10.107.25.81 with SMTP id 78mr33763928ioz.127.1448382353664; Tue, 24 Nov 2015 08:25:53 -0800 (PST) Received: by 10.107.173.15 with HTTP; Tue, 24 Nov 2015 08:25:53 -0800 (PST) Date: Tue, 24 Nov 2015 08:25:53 -0800 Message-ID: From: Bill Cox To: TLS@ietf.org Content-Type: multipart/alternative; boundary=001a113ff00ab0bab005254bcb8b Archived-At: Subject: [TLS] Should we use proof-of-possession rather than signatures? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 16:26:18 -0000 --001a113ff00ab0bab005254bcb8b Content-Type: text/plain; charset=UTF-8 Much of the world seems to have switched to Schnorr-signature inspired ECC signature schemes such as ECDSA-P256 and Ed25519. These schemes are very fast, but require two point multiplications to do a Schnorr-style verification. A simpler proof-of-possession can be verified with only one point multiplication. The server authentication scheme used in QUIC is for the server to prove possession of the static key when it encrypts the new ephemeral key share. The trick is to take advantage of the key shares that have already been computed. The client has already computed its ephemeral keyshare, and the server just uses its static keyshare from the server config. The CertificateVerify message could be generated by the server computing the ECDHE shared secret between its static secret and the client's ephemeral keyshare, and then encrypt of the client random as it's proof. The client verifies the proof by decrypting the nonce. As with Schnorr signatures, creating the proof takes only one multiply: in this case the server multiplies the client's keyshare by it's static keyshare secret. Instead of having to do two scalar point multiplications, the client only has to multiply the server's static keyshare by its ephemeral keyshare secret. The proof is also smaller: 32 bytes vs 72 for ECDSA-P256. This proof-of-possession is not a digital signature, since it can only be used to prove to the client that the server possesses the static private key. However, I don't see any reason to create a full digital signature. Is there any? I just don't like seeing something as fast as QUIC degraded when we switch to TLS 1.3. I guestimate this will cost every connection ~1/8th of a millisecond when using ECDSA-P256. Running "openssl speed ecdsap256", I get: Doing 256 bit sign ecdsa's for 10s: 90092 256 bit ECDSA signs in 9.99s Doing 256 bit verify ecdsa's for 10s: 37154 256 bit ECDSA verify in 9.99s This is about 0.27ms per verification, and on most client machines, this will probably be slower. I think we can nearly double this speed. In TLS, microseconds count. This seems like low hanging fruit to me. Thanks, Bill --001a113ff00ab0bab005254bcb8b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Much of the world seems to have switched to Schnorr-signat= ure inspired ECC signature schemes such as ECDSA-P256 and Ed25519.=C2=A0 Th= ese schemes are very fast, but require two point multiplications to do a Sc= hnorr-style verification.=C2=A0 A simpler proof-of-possession can be verifi= ed with only one point multiplication.

The server a= uthentication scheme used in QUIC is for the server to prove possession of = the static key when it encrypts the new ephemeral key share.=C2=A0 The tric= k is to take advantage of the key shares that have already been computed.= =C2=A0 The client has already computed its ephemeral keyshare, and the serv= er just uses its static keyshare from the server config.=C2=A0 The Certific= ateVerify message could be generated by the server computing the ECDHE shar= ed secret between its static secret and the client's ephemeral keyshare= , and then encrypt of the client random as it's proof.=C2=A0 The client= verifies the proof by decrypting the nonce.=C2=A0 As with Schnorr signatur= es, creating the proof takes only one multiply: in this case the server mul= tiplies the client's keyshare by it's static keyshare secret.=C2=A0= Instead of having to do two scalar point multiplications, the client only = has to multiply the server's static keyshare by its ephemeral keyshare = secret.=C2=A0 The proof is also smaller: 32 bytes vs 72 for ECDSA-P256.
=

This proof-of-possession is not a digital s= ignature, since it can only be used to prove to the client that the server = possesses the static private key.=C2=A0 However, I don't see any reason= to create a full digital signature.=C2=A0 Is there any?=C2=A0 I just don&#= 39;t like seeing something as fast as QUIC degraded when we switch to TLS 1= .3.=C2=A0 I guestimate this will cost every connection ~1/8th of a millisec= ond when using ECDSA-P256.=C2=A0 Running "openssl speed ecdsap256"= ;, I get:

Doing 256 bit sign ecdsa's for = 10s: 90092 256 bit ECDSA signs in 9.99s=C2=A0
Doing 256 bit verif= y ecdsa's for 10s: 37154 256 bit ECDSA verify in 9.99s
=
This is about 0.27ms per verification, and on most client ma= chines, this will probably be slower.=C2=A0 I think we can nearly double th= is speed.

In TLS, microseconds count.=C2=A0 This s= eems like low hanging fruit to me.

Thanks,
Bill
--001a113ff00ab0bab005254bcb8b-- From nobody Tue Nov 24 09: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 43C841B2D99 for ; Tue, 24 Nov 2015 09:02:37 -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, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id polSzTnyxtSQ for ; Tue, 24 Nov 2015 09:02:35 -0800 (PST) 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 5003C1B2D94 for ; Tue, 24 Nov 2015 09:02:35 -0800 (PST) Received: by ykdr82 with SMTP id r82so25737675ykd.3 for ; Tue, 24 Nov 2015 09:02:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=f4ttVlhDdL53LHqyHZzAWk/duIFOG/JrJyucnQN9xMA=; b=hDFyS/0V4svSph2KTqIgPRu92LWxqe/keCrq57QUPHkLY4+CFJxWGgVh2XkYB1g/uR XrICQx0Pii+7jawQNb80pUx/w31+T6vVhCLkk9BXh7cah8OueXtkdf/4J/SJ1caV9b+h De34ksqqvAp5aDBpsuf5iPS15oGyqV4nqJ/Y9BvIbNqF3+sS5Zs/GeYgnfsGvCpED3yn OpHD9HV9qtstNRotoLmgubKhd+wAwlaijELR5ygiFr+r7vSq+krO92/isUahymKi+b1L +/sYgNwf6ET5MxGM6/rslbJtUvYMTrfm1kzmgkYyZHH9kJqy4kRoWn+cyTpl8MtoQlTS dS6g== 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=f4ttVlhDdL53LHqyHZzAWk/duIFOG/JrJyucnQN9xMA=; b=IyHgbAk2s0fKrf2AalJRvKmzmxCTLURq4jPRLZRZiowHe6k/bLR7tboQuAeAB1k+Ai wyyqoa+CjrzjJw2Uv+O85o4yZJiWmhqcLitfmRTfXTtWOQtjbRpTcM0LMT4tkDVtJuZB 0LKM5uKUB+ruSOSEk+9W9NFpSuhYZ2FyMr3ateVoBmJLZcj4JIoojV6hL5yXFfjzmu4j Vu+io4E/8MoHu6MXI3/z7C4uumVejEQ/qnj0ySRNcJiVYqEchTLDx9lJBnNLp00mE8ad O9WiykhdCCnqZtF/7PBqBx5coVUsRB95YspAaOfY4fILD4b1sTyWJleEqhGDB3n2Te1G ApQQ== X-Gm-Message-State: ALoCoQngqW+EzWeL3GyfTC6gwXDL3yL4cUq8FFzLGI5nkEkxit7PfmVYa5r/MqcalXVHaLBk/Y0e X-Received: by 10.13.197.194 with SMTP id h185mr28772682ywd.12.1448384554543; Tue, 24 Nov 2015 09:02:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.212.209 with HTTP; Tue, 24 Nov 2015 09:01:54 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Tue, 24 Nov 2015 09:01:54 -0800 Message-ID: To: Bill Cox Content-Type: multipart/alternative; boundary=001a114edd4adf5fc905254c4e2c Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Should we use proof-of-possession rather than signatures? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 17:02:37 -0000 --001a114edd4adf5fc905254c4e2c Content-Type: text/plain; charset=UTF-8 On Tue, Nov 24, 2015 at 8:25 AM, Bill Cox wrote: > Much of the world seems to have switched to Schnorr-signature inspired ECC > signature schemes such as ECDSA-P256 and Ed25519. These schemes are very > fast, but require two point multiplications to do a Schnorr-style > verification. A simpler proof-of-possession can be verified with only one > point multiplication. > > The server authentication scheme used in QUIC is for the server to prove > possession of the static key when it encrypts the new ephemeral key share. > The trick is to take advantage of the key shares that have already been > computed. The client has already computed its ephemeral keyshare, and the > server just uses its static keyshare from the server config. The > CertificateVerify message could be generated by the server computing the > ECDHE shared secret between its static secret and the client's ephemeral > keyshare, and then encrypt of the client random as it's proof. The client > verifies the proof by decrypting the nonce. As with Schnorr signatures, > creating the proof takes only one multiply: in this case the server > multiplies the client's keyshare by it's static keyshare secret. Instead > of having to do two scalar point multiplications, the client only has to > multiply the server's static keyshare by its ephemeral keyshare secret. > The proof is also smaller: 32 bytes vs 72 for ECDSA-P256. > This is a sort of complicated question. In general, servers have signature keys, not static DH keys. QUIC bridges this by having the server generate an offline signature over a static DH key, but TLS explicitly rejected this as a generic approach because of concerns about the impact of producing a long-term delegated credential, especially if generic TLS credentials could be used to do so (see the extensive discussion on the list a while back on the mailing list as well as [0]). So, the current design requires the server to prove present possession of the signing key, not just that it possessed it at some point. It's correct that demonstrating proof of possession of a long-term DH share is somewhat faster than signatures. There are two potential ways to do this with TLS while retaining the guarantees above: 1. Issue DH (or probably ECDH) certificates. 2. Have a certificate extension that indicates that the certificate can be used for offline signatures (following a suggestion by Hugo Krawczyk) The general sense of the WG is that while these are both good ideas, ECC is now so fast that they can be pursued separately rather than in the critical path. If you're interested in working on that, it would be great to get someone on it, so please contact me or the chairs offline :) > This proof-of-possession is not a digital signature, since it can only be > used to prove to the client that the server possesses the static private > key. However, I don't see any reason to create a full digital signature. > Is there any? > See above. In addition, because the signature covers the entire handshake transcript, it provides some defense against downgrade in cases where the weakest common group is weaker than the server's signing key. -Ekr [0] See also: http://www.nds.rub.de/media/nds/veroeffentlichungen/2015/08/21/Tls13QuicAttacks.pdf --001a114edd4adf5fc905254c4e2c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Nov 24, 2015 at 8:25 AM, Bill Cox <waywardgeek@google.com= > wrote:
Much of the world s= eems to have switched to Schnorr-signature inspired ECC signature schemes s= uch as ECDSA-P256 and Ed25519.=C2=A0 These schemes are very fast, but requi= re two point multiplications to do a Schnorr-style verification.=C2=A0 A si= mpler proof-of-possession can be verified with only one point multiplicatio= n.

The server authentication scheme used in QUIC is= for the server to prove possession of the static key when it encrypts the = new ephemeral key share.=C2=A0 The trick is to take advantage of the key sh= ares that have already been computed.=C2=A0 The client has already computed= its ephemeral keyshare, and the server just uses its static keyshare from = the server config.=C2=A0 The CertificateVerify message could be generated b= y the server computing the ECDHE shared secret between its static secret an= d the client's ephemeral keyshare, and then encrypt of the client rando= m as it's proof.=C2=A0 The client verifies the proof by decrypting the = nonce.=C2=A0 As with Schnorr signatures, creating the proof takes only one = multiply: in this case the server multiplies the client's keyshare by i= t's static keyshare secret.=C2=A0 Instead of having to do two scalar po= int multiplications, the client only has to multiply the server's stati= c keyshare by its ephemeral keyshare secret.=C2=A0 The proof is also smalle= r: 32 bytes vs 72 for ECDSA-P256.

This is a sort of complicated question.

I= n general, servers have signature keys, not static DH keys. QUIC bridges th= is by
having the server generate an offline signature over a stat= ic DH key, but TLS explicitly
rejected this as a generic approach= because of concerns about the impact of producing
a long-term de= legated credential, especially if generic TLS credentials could be used to<= /div>
do so (see the extensive discussion on the list a while back on t= he mailing list as well
as [0]). So, the current design requires = the server to prove present possession of the
signing key, not ju= st that it possessed it at some point.

It's co= rrect that demonstrating proof of possession of a long-term DH share is
somewhat faster than signatures. There are two potential ways to do = this with
TLS while retaining the guarantees above:
1. Issue DH (or probably ECDH) certificates.=C2=A0
2.= Have a certificate extension that indicates that the certificate can be us= ed
=C2=A0 =C2=A0 for offline signatures (following a suggestion b= y Hugo Krawczyk)

The general sense of the WG is th= at while these are both good ideas, ECC is now
so fast that they = can be pursued separately rather than in the critical path. If you're
interested in working on that, it would be great to get someone on= it, so please
contact me or the chairs offline :)

=
=C2=A0
This proo= f-of-possession is not a digital signature, since it can only be used to pr= ove to the client that the server possesses the static private key.=C2=A0 H= owever, I don't see any reason to create a full digital signature.=C2= =A0 Is there any?=C2=A0

See abo= ve. In addition, because the signature covers the entire handshake
transcript, it provides some defense against downgrade in cases where the=
weakest common group is weaker than the server's signing key= .

-Ekr

=C2=A0
--001a114edd4adf5fc905254c4e2c-- From nobody Tue Nov 24 09:54: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 192D51B303E for ; Tue, 24 Nov 2015 09:54:21 -0800 (PST) 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=[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, MIME_QP_LONG_LINE=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 NjZnB7mn32pd for ; Tue, 24 Nov 2015 09:54:18 -0800 (PST) Received: from aspartame.shiftleft.org (199-116-74-168-v301.PUBLIC.monkeybrains.net [199.116.74.168]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8A2F1B303C for ; Tue, 24 Nov 2015 09:54:18 -0800 (PST) Received: from [10.32.94.200] (mobile-166-171-251-160.mycingular.net [166.171.251.160]) by aspartame.shiftleft.org (Postfix) with ESMTPSA id F075F3AA71; Tue, 24 Nov 2015 09:51:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shiftleft.org; s=sldo; t=1448387499; bh=pUOTjyz9w7VeLpkdXB18yk0Z5eR/4TUQI/cY1m43ni8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=CZw4yGoL311dbKa6dsK7/Q7EMyRbAzHRv9aXZPgCF9/ACXwenA71gRB/FouivhG2n Urp9o19b0Y+j50jQKhA6y4RZoN0TlsmuQDxq4/786iSABOySXE6dCtBNIHJlSsD81P eZWm/KdDVdbAyPlXnV3bNLW6Hf2m8Q9AsGFjlYso= Content-Type: multipart/alternative; boundary=Apple-Mail-5397B554-6924-426B-824A-F1B6496C9899 Mime-Version: 1.0 (1.0) From: Mike Hamburg X-Mailer: iPhone Mail (13B143) In-Reply-To: Date: Tue, 24 Nov 2015 09:53:48 -0800 Content-Transfer-Encoding: 7bit Message-Id: <689E730F-63D4-4D64-B678-D5A701983146@shiftleft.org> References: To: Eric Rescorla Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Should we use proof-of-possession rather than signatures? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 17:54:21 -0000 --Apple-Mail-5397B554-6924-426B-824A-F1B6496C9899 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sent from my phone. Please excuse brevity and typos. > On Nov 24, 2015, at 09:01, Eric Rescorla wrote: >=20 >=20 >> On Tue, Nov 24, 2015 at 8:25 AM, Bill Cox wrote:= >> Much of the world seems to have switched to Schnorr-signature inspired EC= C signature schemes such as ECDSA-P256 and Ed25519. These schemes are very f= ast, but require two point multiplications to do a Schnorr-style verificatio= n. A simpler proof-of-possession can be verified with only one point multip= lication. >>=20 >> The server authentication scheme used in QUIC is for the server to prove p= ossession of the static key when it encrypts the new ephemeral key share. T= he trick is to take advantage of the key shares that have already been compu= ted. The client has already computed its ephemeral keyshare, and the server= just uses its static keyshare from the server config. The CertificateVerif= y message could be generated by the server computing the ECDHE shared secret= between its static secret and the client's ephemeral keyshare, and then enc= rypt of the client random as it's proof.=20 This is insecure. You need to MAC the whole handshake, especially the server= ephemeral. >> The client verifies the proof by decrypting the nonce. As with Schnorr s= ignatures, creating the proof takes only one multiply: in this case the serv= er multiplies the client's keyshare by it's static keyshare secret. Instead= of having to do two scalar point multiplications, the client only has to mu= ltiply the server's static keyshare by its ephemeral keyshare secret. The p= roof is also smaller: 32 bytes vs 72 for ECDSA-P256. The size advantage of proof of possession is significant if the server actua= lly has a DH cert, one for the same group as the client's ephemeral.=20 > This is a sort of complicated question. >=20 > In general, servers have signature keys, not static DH keys. QUIC bridges t= his by > having the server generate an offline signature over a static DH key, but T= LS explicitly > rejected this as a generic approach because of concerns about the impact o= f producing > a long-term delegated credential, especially if generic TLS credentials co= uld be used to > do so (see the extensive discussion on the list a while back on the mailin= g list as well > as [0]). So, the current design requires the server to prove present posse= ssion of the > signing key, not just that it possessed it at some point. >=20 > It's correct that demonstrating proof of possession of a long-term DH shar= e is > somewhat faster than signatures. There are two potential ways to do this w= ith > TLS while retaining the guarantees above: Correct-ish. For example, the current implementation of ed448 takes 463k sky= lake cycles (new cpu, top of the chart, I'm on a phone, sorry) to compute ec= dh, which would need to happen twice. But it takes 162kcy to sign and 509k t= o verify, for a total of 671k vs 926k. Signing favors the server while doub= le DH favors the client; there are good reasons to go in either direction in= this. Presumably the two server scalar multiplications could be combined with dual= Shamir's trick, at which point double DH would be slightly faster than sigs= , but I don't have an implementation of that lying around. There is also a d= ifferent calculation if the client has precomputed a table from the server's= static key, but nobody does that and I'd guess the results are similar anyw= ay. Proof of possession is a bigger win if you go with MQV. > 1. Issue DH (or probably ECDH) certificates.=20 > 2. Have a certificate extension that indicates that the certificate can be= used > for offline signatures (following a suggestion by Hugo Krawczyk) >=20 > The general sense of the WG is that while these are both good ideas, ECC i= s now > so fast that they can be pursued separately rather than in the critical pa= th. If you're > interested in working on that, it would be great to get someone on it, so p= lease > contact me or the chairs offline :) I agree that the speed and size savings are not necessarily worth the comple= xity. If we were rolling a new protocol from scratch they probably would be t= hough.=20 > =20 >> This proof-of-possession is not a digital signature, since it can only be= used to prove to the client that the server possesses the static private ke= y. However, I don't see any reason to create a full digital signature. Is t= here any?=20 >=20 > See above. In addition, because the signature covers the entire handshake > transcript, it provides some defense against downgrade in cases where the > weakest common group is weaker than the server's signing key. Agreed. It's also clearer how to combine this with postquantum key exchange= , though proof of possession should be fine if you're also using DHE. Cheers, -- Mike > -Ekr >=20 > [0] See also: http://www.nds.rub.de/media/nds/veroeffentlichungen/2015/08/= 21/Tls13QuicAttacks.pdf > =20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail-5397B554-6924-426B-824A-F1B6496C9899 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


Sent from my phone.  Plea= se excuse brevity and typos.

On Nov 24, 2015, at 09:01, Eric R= escorla <ekr@rtfm.com> wrote:
<= br>

On Tue, Nov 24, 2015 at 8:25 AM, Bill= Cox <waywardgeek@google.com> wrote:
Much of the world seems to have switched to Schnorr-signature ins= pired ECC signature schemes such as ECDSA-P256 and Ed25519.  These sche= mes are very fast, but require two point multiplications to do a Schnorr-sty= le verification.  A simpler proof-of-possession can be verified with on= ly one point multiplication.

The server authenticati= on scheme used in QUIC is for the server to prove possession of the static k= ey when it encrypts the new ephemeral key share.  The trick is to take a= dvantage of the key shares that have already been computed.  The client= has already computed its ephemeral keyshare, and the server just uses its s= tatic keyshare from the server config.  The CertificateVerify message c= ould be generated by the server computing the ECDHE shared secret between it= s static secret and the client's ephemeral keyshare, and then encrypt of the= client random as it's proof. 

This is insecure. You need t= o MAC the whole handshake, especially the server ephemeral.

The client veri= fies the proof by decrypting the nonce.  As with Schnorr signatures, cr= eating the proof takes only one multiply: in this case the server multiplies= the client's keyshare by it's static keyshare secret.  Instead of havi= ng to do two scalar point multiplications, the client only has to multiply t= he server's static keyshare by its ephemeral keyshare secret.  The proo= f is also smaller: 32 bytes vs 72 for ECDSA-P256.

The size advant= age of proof of possession is significant if the server actually has a DH ce= rt, one for the same group as the client's ephemeral. 

This is a sort of complicated question.
In general, servers have signature keys, not static DH keys. QU= IC bridges this by
having the server generate an offline signature= over a static DH key, but TLS explicitly
rejected this as a gener= ic approach because of concerns about the impact of producing
a lo= ng-term delegated credential, especially if generic TLS credentials could be= used to
do so (see the extensive discussion on the list a while b= ack on the mailing list as well
as [0]). So, the current design re= quires the server to prove present possession of the
signing key, n= ot just that it possessed it at some point.

It's co= rrect that demonstrating proof of possession of a long-term DH share is
somewhat faster than signatures. There are two potential ways to do th= is with
TLS while retaining the guarantees above:

Correct-ish. For example, the c= urrent implementation of ed448 takes 463k skylake cycles (new cpu, top of th= e chart, I'm on a phone, sorry) to compute ecdh, which would need to happen t= wice. But it takes 162kcy to sign and 509k to verify, for a total of 671k vs= 926k.  Signing favors the server while double DH favors the client; th= ere are good reasons to go in either direction in this.

=
Presumably the two server scalar multiplications could be combined with= dual Shamir's trick, at which point double DH would be slightly faster than= sigs, but I don't have an implementation of that lying around.  There i= s also a different calculation if the client has precomputed a table from th= e server's static key, but nobody does that and I'd guess the results are si= milar anyway.

Proof of possession is a bigger win i= f you go with MQV.

=
1. Issue DH (or p= robably ECDH) certificates. 
2. Have a certificate extension t= hat indicates that the certificate can be used
    for o= ffline signatures (following a suggestion by Hugo Krawczyk)

The general sense of the WG is that while these are both good ideas= , ECC is now
so fast that they can be pursued separately rather th= an in the critical path. If you're
interested in working on that, i= t would be great to get someone on it, so please
contact me or the= chairs offline :)

=
I agree that the speed and size savings are not necessarily worth the c= omplexity. If we were rolling a new protocol from scratch they probably woul= d be though. 

=
 
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le= ft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padd= ing-left:1ex">
This proof-of-possession is not a digita= l signature, since it can only be used to prove to the client that the serve= r possesses the static private key.  However, I don't see any reason to= create a full digital signature.  Is there any? 

See above. In addition, because the signature co= vers the entire handshake
transcript, it provides some defense aga= inst downgrade in cases where the
weakest common group is weaker t= han the server's signing key.

Agreed.  It's also clearer how to combine this with pos= tquantum key exchange, though proof of possession should be fine if you're a= lso using DHE.

Cheers,
-- Mike

<= blockquote type=3D"cite">
____________________= ___________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/lis= tinfo/tls
= --Apple-Mail-5397B554-6924-426B-824A-F1B6496C9899-- From nobody Tue Nov 24 10:07: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 B7F481A004D for ; Tue, 24 Nov 2015 10:07:22 -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, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BzAzJJrNXGmT for ; Tue, 24 Nov 2015 10:07:21 -0800 (PST) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 069B91A003B for ; Tue, 24 Nov 2015 10:07:21 -0800 (PST) Received: by ykfs79 with SMTP id s79so28394198ykf.1 for ; Tue, 24 Nov 2015 10:07:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=0jCjIkUFDn4ToxmqBRxZ+DzfD4q418DyFvIh+uR8rB8=; b=Va38NqIe5eC68PQJkZctz4+Ae5jV7tivt1xJmrWSJzJPCS98uX1n2HaD1nlOREIz2U bJfiJFh5rRBEoyJTD+t1GSozyYcnbfVfX161gFZSNLhVx3LNrJ4IOLTFPVrtdClDxPVU YU2WFAoboInLyPSlq/ODTEM9lmQn4ktBIbN7RmEYHaBaQKsr1Mi6mIqvv6klDTcKUoUS nPse4srZBox8goeWUwuN4zsjwf0EwVtqrqQYqmtpRt9zmA0cm1nMGhl3yKp7pCwmI8P+ Rvl8c5yjTCTvGmCK4cRAKJkz6VmxXv38SWXAl9m/wBi72s4/T1Uotg76Iizimbm/94aE Stig== 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=0jCjIkUFDn4ToxmqBRxZ+DzfD4q418DyFvIh+uR8rB8=; b=Gk3tj9G8IiAX6QMzwQQVPJR8n1NrCDFwPdIZ85Yz/3tgTGe5eMZSv+OE2asWqwmWNj Srcy064DjszTvVWWVqCZQK/4byUjFdkq9/FaqmGKsPyfAqWioLo+PVwjNMzqGwrc02J4 jY/0vOaevRh/TlLhAgx/6VYvBLdN5ydMAKK7vzBTFnjKXkCJK2FXwx9BkcOHRdeTNZz0 keniexr8bV9fCWqia79s2Wv7YNtDqPMbB5bdyOQGQFd/grNvoUkMr5FuY80WD5kwJBZl 3Igg7+BMKoMBG7sSv0dJsirmOK0LW+cNQpoAgUZOG3QJkA0xTcQR91MeLkRNGJ+bMVU3 Sf/w== X-Gm-Message-State: ALoCoQlnnb04xx+11vHYHtJ+xGifdL+k4W2f2/ylJM6fgtSgkE6Is/cTfj0iNUE1baWoPPmGNjFu X-Received: by 10.13.212.17 with SMTP id w17mr15789635ywd.192.1448388440344; Tue, 24 Nov 2015 10:07:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.212.209 with HTTP; Tue, 24 Nov 2015 10:06:41 -0800 (PST) In-Reply-To: <689E730F-63D4-4D64-B678-D5A701983146@shiftleft.org> References: <689E730F-63D4-4D64-B678-D5A701983146@shiftleft.org> From: Eric Rescorla Date: Tue, 24 Nov 2015 10:06:41 -0800 Message-ID: To: Mike Hamburg Content-Type: multipart/alternative; boundary=001a114fd59e7bfcb805254d3623 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Should we use proof-of-possession rather than signatures? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 18:07:22 -0000 --001a114fd59e7bfcb805254d3623 Content-Type: text/plain; charset=UTF-8 On Tue, Nov 24, 2015 at 9:53 AM, Mike Hamburg wrote: > > > In general, servers have signature keys, not static DH keys. QUIC bridges > this by > having the server generate an offline signature over a static DH key, but > TLS explicitly > rejected this as a generic approach because of concerns about the impact > of producing > a long-term delegated credential, especially if generic TLS credentials > could be used to > do so (see the extensive discussion on the list a while back on the > mailing list as well > as [0]). So, the current design requires the server to prove present > possession of the > signing key, not just that it possessed it at some point. > > It's correct that demonstrating proof of possession of a long-term DH > share is > somewhat faster than signatures. There are two potential ways to do this > with > TLS while retaining the guarantees above: > > > Correct-ish. For example, the current implementation of ed448 takes 463k > skylake cycles (new cpu, top of the chart, I'm on a phone, sorry) to > compute ecdh, which would need to happen twice. But it takes 162kcy to sign > and 509k to verify, for a total of 671k vs 926k. Signing favors the server > while double DH favors the client; there are good reasons to go in either > direction in this. > In general, I tend to want to favor the server, I think :) 1. Issue DH (or probably ECDH) certificates. > 2. Have a certificate extension that indicates that the certificate can be > used > for offline signatures (following a suggestion by Hugo Krawczyk) > > The general sense of the WG is that while these are both good ideas, ECC > is now > so fast that they can be pursued separately rather than in the critical > path. If you're > interested in working on that, it would be great to get someone on it, so > please > contact me or the chairs offline :) > > > I agree that the speed and size savings are not necessarily worth the > complexity. If we were rolling a new protocol from scratch they probably > would be though. > It's worth noting that it's not just a matter of an existing protocol but also of an existing authentication infrastructure (i.e., widespread RSA and ECDSA signing certs.) Thanks, -Ekr --001a114fd59e7bfcb805254d3623 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Nov 24, 2015 at 9:53 AM, Mike Hamburg <mike@shiftleft.org= > wrote:


= In general, servers have signature keys, not static DH keys. QUIC bridges t= his by
having the server generate an offline signature over a sta= tic DH key, but TLS explicitly
rejected this as a generic approac= h because of concerns about the impact of producing
a long-term d= elegated credential, especially if generic TLS credentials could be used to=
do so (see the extensive discussion on the list a while back on = the mailing list as well
as [0]). So, the current design requires= the server to prove present possession of the
signing key, not j= ust that it possessed it at some point.

It's c= orrect that demonstrating proof of possession of a long-term DH share is
somewhat faster than signatures. There are two potential ways to do= this with
TLS while retaining the guarantees above:
<= /div>

Correct-ish. For e= xample, the current implementation of ed448 takes 463k skylake cycles (new = cpu, top of the chart, I'm on a phone, sorry) to compute ecdh, which wo= uld need to happen twice. But it takes 162kcy to sign and 509k to verify, f= or a total of 671k vs 926k.=C2=A0 Signing favors the server while double DH= favors the client; there are good reasons to go in either direction in thi= s.

In general, I tend to want t= o favor the server, I think :)


1. Issue DH (or probably ECDH) certificates.=C2=A0
2. Have a certificate extension that indicates that the certificate can b= e used
=C2=A0 =C2=A0 for offline signatures (following a suggesti= on by Hugo Krawczyk)

The general sense of the WG i= s that while these are both good ideas, ECC is now
so fast that t= hey can be pursued separately rather than in the critical path. If you'= re
interested in working on that, it would be great to get someon= e on it, so please
contact me or the chairs offline :)

I agree that the= speed and size savings are not necessarily worth the complexity. If we wer= e rolling a new protocol from scratch they probably would be though.=C2=A0<= /div>

It's worth noting that it&#= 39;s not just a matter of an existing protocol but also of an
exi= sting authentication infrastructure (i.e., widespread RSA and ECDSA signing=
certs.)

Thanks,
-Ekr
--001a114fd59e7bfcb805254d3623-- From nobody Tue Nov 24 12:04: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 7CC471A8904 for ; Tue, 24 Nov 2015 12:04:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.556 X-Spam-Level: * X-Spam-Status: No, score=1.556 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 QjCg2komWmdg for ; Tue, 24 Nov 2015 12:04:55 -0800 (PST) Received: from aspartame.shiftleft.org (199-116-74-168-v301.PUBLIC.monkeybrains.net [199.116.74.168]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B2921A88FC for ; Tue, 24 Nov 2015 12:04:55 -0800 (PST) Received: from [10.184.148.249] (unknown [209.36.6.242]) by aspartame.shiftleft.org (Postfix) with ESMTPSA id ECB6AF210A; Tue, 24 Nov 2015 12:02:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shiftleft.org; s=sldo; t=1448395336; bh=D3TUqtSeXB5aYeNqES+IAPIRJeHqLWcZ83YovrnGVto=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=ZuIzlUKgo/VliMbsEyVjwezpLsf/Aii6J7077vG6Ht+BN9ALr7QRgZaS2D/TVpMHZ E4SXETgA+LarAoTrcydoeZ7W7ofFuB+Low7e63ffahOswZh/2+vm8j3h6/ZVXHBDn9 ryMPGMjDLDzA1OMYwe9+Pn5xye7ge/BnHnuQG2R4= Content-Type: multipart/alternative; boundary="Apple-Mail=_8AB7BF2F-0C75-43EC-A9A1-8D85F1738BD3" Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Michael Hamburg In-Reply-To: Date: Tue, 24 Nov 2015 12:04:54 -0800 Message-Id: References: <689E730F-63D4-4D64-B678-D5A701983146@shiftleft.org> To: Eric Rescorla X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Should we use proof-of-possession rather than signatures? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 20:04:56 -0000 --Apple-Mail=_8AB7BF2F-0C75-43EC-A9A1-8D85F1738BD3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 24, 2015, at 10:06 AM, Eric Rescorla wrote: >=20 >=20 >=20 > On Tue, Nov 24, 2015 at 9:53 AM, Mike Hamburg > wrote: >=20 >>=20 >> In general, servers have signature keys, not static DH keys. QUIC = bridges this by >> having the server generate an offline signature over a static DH key, = but TLS explicitly >> rejected this as a generic approach because of concerns about the = impact of producing >> a long-term delegated credential, especially if generic TLS = credentials could be used to >> do so (see the extensive discussion on the list a while back on the = mailing list as well >> as [0]). So, the current design requires the server to prove present = possession of the >> signing key, not just that it possessed it at some point. >>=20 >> It's correct that demonstrating proof of possession of a long-term DH = share is >> somewhat faster than signatures. There are two potential ways to do = this with >> TLS while retaining the guarantees above: >=20 > Correct-ish. For example, the current implementation of ed448 takes = 463k skylake cycles (new cpu, top of the chart, I'm on a phone, sorry) = to compute ecdh, which would need to happen twice. But it takes 162kcy = to sign and 509k to verify, for a total of 671k vs 926k. Signing favors = the server while double DH favors the client; there are good reasons to = go in either direction in this. >=20 > In general, I tend to want to favor the server, I think :) Actually, I did a quick test and the signatures still look faster when = optimized. The hitch is that the dual scalarmul algorithm must be = side-channel protected, which is pretty expensive. I did a quick = implementation this morning with libdecaf on Haswell. I=E2=80=99m sure = it could be done better, but here=E2=80=99s a rough bench, not counting = point encode and decode. For Ed448, a protected fixed-base scalarmul (for signing) takes 109kcy = and an unprotected verification double-scalarmul takes 517kcy, but a = protected dual-scalarmul takes 690kcy which is more than both together. For Ed25519, these take 164kcy, 40kcy and 236kcy respectively; again the = dual scalarmul is slower. Note that these numbers are for some internal testing version, so = they=E2=80=99re not as optimized as the SUPERCOP numbers, but also that = they don=E2=80=99t include point encode and decode. So yeah, you=E2=80=99d need ECMQV to get a speed boost from this, or = you=E2=80=99d need to care more about the client computation and = bandwidth than the server computation. Cheers, =E2=80=94 Mike= --Apple-Mail=_8AB7BF2F-0C75-43EC-A9A1-8D85F1738BD3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Nov 24, 2015, at 10:06 AM, Eric Rescorla <ekr@rtfm.com> = wrote:



On Tue, Nov 24, 2015 at 9:53 AM, = Mike Hamburg <mike@shiftleft.org> wrote:


In general, servers have signature keys, not static DH keys. = QUIC bridges this by
having the server generate an = offline signature over a static DH key, but TLS explicitly
rejected this as a generic approach because of concerns about = the impact of producing
a long-term delegated = credential, especially if generic TLS credentials could be used = to
do so (see the extensive discussion on the list = a while back on the mailing list as well
as [0]). = So, the current design requires the server to prove present possession = of the
signing key, not just that it possessed it = at some point.

It's correct that demonstrating proof of possession of a = long-term DH share is
somewhat faster than = signatures. There are two potential ways to do this with
TLS while retaining the guarantees = above:

Correct-ish. For example, the = current implementation of ed448 takes 463k skylake cycles (new cpu, top = of the chart, I'm on a phone, sorry) to compute ecdh, which would need = to happen twice. But it takes 162kcy to sign and 509k to verify, for a = total of 671k vs 926k.  Signing favors the server while double DH = favors the client; there are good reasons to go in either direction in = this.

In general, I tend to want to favor the server, I think = :)

Actually, I did a quick test and the signatures = still look faster when optimized.  The hitch is that the dual = scalarmul algorithm must be side-channel protected, which is pretty = expensive.  I did a quick implementation this morning with libdecaf = on Haswell.  I=E2=80=99m sure it could be done better, but here=E2=80= =99s a rough bench, not counting point encode and decode.

For Ed448, a protected fixed-base scalarmul (for = signing) takes 109kcy and an unprotected verification double-scalarmul = takes 517kcy, but a protected dual-scalarmul takes 690kcy which is more = than both together.

For Ed25519, = these take 164kcy, 40kcy and 236kcy respectively; again the dual = scalarmul is slower.

Note that these = numbers are for some internal testing version, so they=E2=80=99re not as = optimized as the SUPERCOP numbers, but also that they don=E2=80=99t = include point encode and decode.

So yeah, you=E2=80=99d need ECMQV to get a speed boost from = this, or you=E2=80=99d need to care more about the client computation = and bandwidth than the server computation.

Cheers,
=E2=80=94 = Mike
= --Apple-Mail=_8AB7BF2F-0C75-43EC-A9A1-8D85F1738BD3-- From nobody Tue Nov 24 12:28: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 23C1D1A8981 for ; Tue, 24 Nov 2015 12:28:09 -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 ffuYfJkq-Mvn for ; Tue, 24 Nov 2015 12:28:06 -0800 (PST) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB69C1A897F for ; Tue, 24 Nov 2015 12:28:05 -0800 (PST) Received: by lfs39 with SMTP id 39so34224947lfs.3 for ; Tue, 24 Nov 2015 12:28:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=WSb2L9/Eo/vCOVWkoUEw/lRQDUpkMg2dFk56pRorBI8=; b=tpLFlT80tyvxtzUlliG40DEgVzUM9Fgle6fL90t/H0sypuU/vpqVYpCLXnaZFRpqqV DrHQ3xsug7OaEhRE++YC91lHLcr2cDGkCnkcwjt0mou1IGyqTvJWg7nvS1SKgw/Tivl2 WOifNQ2pPW71d+waP8tWjEX2QUumXsq8SccKR3vXqO+asP2aUWVVsGGbixNM99bBKEyn akxdN1f5pLNkhgiZRZo5MkL3vJctxqwE/OVP4EkBlVGBxNbCCBVJFEGFNdf9apfkOqz3 D9KO9qQO3Gl6vCGBNiGy0E7wwwP+a9xBhQuw9CVaPdUiys+xUylrawfHcSvd34nHLXpG Ewhg== X-Received: by 10.112.16.135 with SMTP id g7mr14768828lbd.80.1448396883971; Tue, 24 Nov 2015 12:28:03 -0800 (PST) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.168.210 with HTTP; Tue, 24 Nov 2015 12:27:34 -0800 (PST) In-Reply-To: <689E730F-63D4-4D64-B678-D5A701983146@shiftleft.org> References: <689E730F-63D4-4D64-B678-D5A701983146@shiftleft.org> From: Hugo Krawczyk Date: Tue, 24 Nov 2015 15:27:34 -0500 X-Google-Sender-Auth: z2TpMs0_Sw1T8fIpGm0mGPKty0A Message-ID: To: Mike Hamburg Content-Type: multipart/alternative; boundary=001a11c3c778c3555d05254f2d15 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Should we use proof-of-possession rather than signatures? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 20:28:09 -0000 --001a11c3c778c3555d05254f2d15 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Nov 24, 2015 at 12:53 PM, Mike Hamburg wrote: > > > Sent from my phone. Please excuse brevity and typos. > > On Nov 24, 2015, at 09:01, Eric Rescorla wrote: > > > On Tue, Nov 24, 2015 at 8:25 AM, Bill Cox wrote: > >> Much of the world seems to have switched to Schnorr-signature inspired >> ECC signature schemes such as ECDSA-P256 and Ed25519. These schemes are >> very fast, but require two point multiplications to do a Schnorr-style >> verification. A simpler proof-of-possession can be verified with only o= ne >> point multiplication. >> >> The server authentication scheme used in QUIC is for the server to prove >> possession of the static key when it encrypts the new ephemeral key shar= e. >> The trick is to take advantage of the key shares that have already been >> computed. The client has already computed its ephemeral keyshare, and t= he >> server just uses its static keyshare from the server config. The >> CertificateVerify message could be generated by the server computing the >> ECDHE shared secret between its static secret and the client's ephemeral >> keyshare, and then encrypt of the client random as it's proof. >> > > This is insecure. You need to MAC the whole handshake, especially the > server ephemeral. > > The client verifies the proof by decrypting the nonce. As with Schnorr >> signatures, creating the proof takes only one multiply: in this case the >> server multiplies the client's keyshare by it's static keyshare secret. >> Instead of having to do two scalar point multiplications, the client onl= y >> has to multiply the server's static keyshare by its ephemeral keyshare >> secret. The proof is also smaller: 32 bytes vs 72 for ECDSA-P256. >> > > The size advantage of proof of possession is significant if the server > actually has a DH cert, one for the same group as the client's ephemeral. > > This is a sort of complicated question. > > In general, servers have signature keys, not static DH keys. QUIC bridges > this by > having the server generate an offline signature over a static DH key, but > TLS explicitly > rejected this as a generic approach because of concerns about the impact > of producing > a long-term delegated credential, especially if generic TLS credentials > could be used to > do so (see the extensive discussion on the list a while back on the > mailing list as well > as [0]). So, the current design requires the server to prove present > possession of the > signing key, not just that it possessed it at some point. > > It's correct that demonstrating proof of possession of a long-term DH > share is > somewhat faster than signatures. There are two potential ways to do this > with > TLS while retaining the guarantees above: > > > Correct-ish. For example, the current implementation of ed448 takes 463k > skylake cycles (new cpu, top of the chart, I'm on a phone, sorry) to > compute ecdh, which would need to happen twice. But it takes 162kcy to si= gn > and 509k to verify, for a total of 671k vs 926k. Signing favors the serv= er > while double DH favors the client; there are good reasons to go in either > direction in this. > > Presumably the two server scalar multiplications could be combined with > dual Shamir's trick, at which point double DH would be slightly faster th= an > sigs, but I don't have an implementation of that lying around. There is > also a different calculation if the client has precomputed a table from t= he > server's static key, but nobody does that and I'd guess the results are > similar anyway. > > Proof of possession is a bigger win if you go with MQV. > > 1. Issue DH (or probably ECDH) certificates. > 2. Have a certificate extension that indicates that the certificate can b= e > used > for offline signatures (following a suggestion by Hugo Krawczyk) > > The general sense of the WG is that while these are both good ideas, ECC > is now > so fast that they can be pursued separately rather than in the critical > path. If you're > interested in working on that, it would be great to get someone on it, so > please > contact me or the chairs offline :) > > > I agree that the speed and size savings are not necessarily worth the > complexity. If we were rolling a new protocol from scratch they probably > would be though. > =E2=80=8BThe all-DH-based solution, with DH certificates, does not add comp= lexity but rather simplifies the protocol and analysis, and opens the option of more efficient protocols (e.g. MQV-like ones). But the world does not seem ready to depart from the beloved signature certificates. =E2=80=8BHugo=E2=80=8B =E2=80=8B > > > >> This proof-of-possession is not a digital signature, since it can only b= e >> used to prove to the client that the server possesses the static private >> key. However, I don't see any reason to create a full digital signature= . >> Is there any? >> > > See above. In addition, because the signature covers the entire handshake > transcript, it provides some defense against downgrade in cases where the > weakest common group is weaker than the server's signing key. > > > Agreed. It's also clearer how to combine this with postquantum key > exchange, though proof of possession should be fine if you're also using > DHE. > > Cheers, > -- Mike > > -Ekr > > [0] See also: > http://www.nds.rub.de/media/nds/veroeffentlichungen/2015/08/21/Tls13QuicA= ttacks.pdf > > > _______________________________________________ > 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 > > --001a11c3c778c3555d05254f2d15 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Nov 24, 2015 at 12:53 PM, Mike Hamburg <mike= @shiftleft.org> wrote:


Sent from my phone.=C2=A0 Please excuse brevity = and typos.

On Nov 24, 2015, at 09:01, Eric R= escorla <ekr@rtfm.com<= /a>> wrote:


On Tue, Nov 24, = 2015 at 8:25 AM, Bill Cox <waywardgeek@google.com> wrot= e:
Much of the world seems to have swi= tched to Schnorr-signature inspired ECC signature schemes such as ECDSA-P25= 6 and Ed25519.=C2=A0 These schemes are very fast, but require two point mul= tiplications to do a Schnorr-style verification.=C2=A0 A simpler proof-of-p= ossession can be verified with only one point multiplication.

The server authentication scheme used in QUIC is for the server = to prove possession of the static key when it encrypts the new ephemeral ke= y share.=C2=A0 The trick is to take advantage of the key shares that have a= lready been computed.=C2=A0 The client has already computed its ephemeral k= eyshare, and the server just uses its static keyshare from the server confi= g.=C2=A0 The CertificateVerify message could be generated by the server com= puting the ECDHE shared secret between its static secret and the client'= ;s ephemeral keyshare, and then encrypt of the client random as it's pr= oof.=C2=A0

This is insecure. You need to MAC the whole = handshake, especially the server ephemeral.

The clien= t verifies the proof by decrypting the nonce.=C2=A0 As with Schnorr signatu= res, creating the proof takes only one multiply: in this case the server mu= ltiplies the client's keyshare by it's static keyshare secret.=C2= =A0 Instead of having to do two scalar point multiplications, the client on= ly has to multiply the server's static keyshare by its ephemeral keysha= re secret.=C2=A0 The proof is also smaller: 32 bytes vs 72 for ECDSA-P256.<= /div>
The size advantage of proof of possession is significant= if the server actually has a DH cert, one for the same group as the client= 's ephemeral.=C2=A0

This is a sort of complicated question.

In = general, servers have signature keys, not static DH keys. QUIC bridges this= by
having the server generate an offline signature over a static= DH key, but TLS explicitly
rejected this as a generic approach b= ecause of concerns about the impact of producing
a long-term dele= gated credential, especially if generic TLS credentials could be used to
do so (see the extensive discussion on the list a while back on the= mailing list as well
as [0]). So, the current design requires th= e server to prove present possession of the
signing key, not just= that it possessed it at some point.

It's corr= ect that demonstrating proof of possession of a long-term DH share is
=
somewhat faster than signatures. There are two potential ways to do th= is with
TLS while retaining the guarantees above:

Correct-ish. For exam= ple, the current implementation of ed448 takes 463k skylake cycles (new cpu= , top of the chart, I'm on a phone, sorry) to compute ecdh, which would= need to happen twice. But it takes 162kcy to sign and 509k to verify, for = a total of 671k vs 926k.=C2=A0 Signing favors the server while double DH fa= vors the client; there are good reasons to go in either direction in this.<= /div>

Presumably the two server scalar multiplications c= ould be combined with dual Shamir's trick, at which point double DH wou= ld be slightly faster than sigs, but I don't have an implementation of = that lying around.=C2=A0 There is also a different calculation if the clien= t has precomputed a table from the server's static key, but nobody does= that and I'd guess the results are similar anyway.

Proof of possession is a bigger win if you go with MQV.

1. Issue DH (or probably ECDH)= certificates.=C2=A0
2. Have a certificate extension that indicat= es that the certificate can be used
=C2=A0 =C2=A0 for offline sig= natures (following a suggestion by Hugo Krawczyk)

= The general sense of the WG is that while these are both good ideas, ECC is= now
so fast that they can be pursued separately rather than in t= he critical path. If you're
interested in working on that, it= would be great to get someone on it, so please
contact me or the= chairs offline :)

I agree that the speed and size savings are not necessarily wo= rth the complexity. If we were rolling a new protocol from scratch they pro= bably would be though.=C2=A0

=E2=80=8BThe all-DH-based solution, with DH certifi= cates, does not add complexity but rather simplifies the protocol and analy= sis, and opens the option of more efficient protocols (e.g. MQV-like ones).= But the world does not seem ready to depart from the beloved signature cer= tificates.

<= div class=3D"gmail_default" style=3D"font-family:verdana,sans-serif;font-si= ze:small">=E2=80=8BHugo=E2=80=8B


=E2=80=8B
=C2=A0

= =C2=A0
This proof-of-posses= sion is not a digital signature, since it can only be used to prove to the = client that the server possesses the static private key.=C2=A0 However, I d= on't see any reason to create a full digital signature.=C2=A0 Is there = any?=C2=A0

See above. In additi= on, because the signature covers the entire handshake
transcript,= it provides some defense against downgrade in cases where the
we= akest common group is weaker than the server's signing key.
=

Agreed.=C2=A0 It&= #39;s also clearer how to combine this with postquantum key exchange, thoug= h proof of possession should be fine if you're also using DHE.

Cheers,
-- Mike

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

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


--001a11c3c778c3555d05254f2d15-- From nobody Tue Nov 24 13:26: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 36B891A8A95 for ; Tue, 24 Nov 2015 13:25:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.156 X-Spam-Level: ** X-Spam-Status: No, score=2.156 tagged_above=-999 required=5 tests=[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, J_CHICKENPOX_34=0.6, 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 YXX1t0hDBlYF for ; Tue, 24 Nov 2015 13:25:57 -0800 (PST) Received: from aspartame.shiftleft.org (199-116-74-168-v301.PUBLIC.monkeybrains.net [199.116.74.168]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD2A91A8A55 for ; Tue, 24 Nov 2015 13:25:57 -0800 (PST) Received: from [10.184.148.249] (unknown [209.36.6.242]) by aspartame.shiftleft.org (Postfix) with ESMTPSA id D290F3AA71; Tue, 24 Nov 2015 13:23:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shiftleft.org; s=sldo; t=1448400198; bh=lb4Z/h79be8jjjvWgdAZL2OaLRary19RD76hth3Rxqk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=Au8xXgjxTPJisSAa9LAVaS+1EBWEm5n+bKDAe1Fi1oc7ggEclsHF2pqCnohLM1kO/ bccp5Fv1p00UkVARGssNDzUN4uTXsjApIgN3vfriuGP967IHpu3y3syw2aeMCrqwjp U3kweYd9p0ITAANqUSvVCf+szUeJe1dGCIEycAUI= Content-Type: multipart/alternative; boundary="Apple-Mail=_CB4165EF-17FB-4814-BF46-09F9022825B2" Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Michael Hamburg In-Reply-To: Date: Tue, 24 Nov 2015 13:25:57 -0800 Message-Id: <727C6597-F386-4349-B334-6D8442354F1E@shiftleft.org> References: <689E730F-63D4-4D64-B678-D5A701983146@shiftleft.org> To: Hugo Krawczyk X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Should we use proof-of-possession rather than signatures? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 21:25:59 -0000 --Apple-Mail=_CB4165EF-17FB-4814-BF46-09F9022825B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 24, 2015, at 12:27 PM, Hugo Krawczyk = wrote: > On Tue, Nov 24, 2015 at 12:53 PM, Mike Hamburg > wrote: >=20 > I agree that the speed and size savings are not necessarily worth the = complexity. If we were rolling a new protocol from scratch they probably = would be though.=20 >=20 > =E2=80=8BThe all-DH-based solution, with DH certificates, does not add = complexity but rather simplifies the protocol and analysis, and opens = the option of more efficient protocols (e.g. MQV-like ones). But the = world does not seem ready to depart from the beloved signature = certificates. >=20 > =E2=80=8BHugo=E2=80=8B I agree for new protocols, but the proposal for TLS isn=E2=80=99t = all-DH. It=E2=80=99s allowing both all-DH and DHE+sign. That=E2=80=99s = more complex than just allowing DHE+sign. But I suppose the difference = in TLS as proposed is really just putting a DH+MAC in CertificateVerify = instead of a signature, which isn=E2=80=99t a complicated difference. Sorry to be negative. I really do like all-DH for simplicity, = compactness and speed, especially if IP-encumbered algorithms are = available. I=E2=80=99m not against its inclusion in TLS if others think = it=E2=80=99s worth the complexity of adding another option. But I=E2=80=99= m grumpy because this thread started with an insecure proposal justified = using incorrect numbers. =E2=80=94 Mike= --Apple-Mail=_CB4165EF-17FB-4814-BF46-09F9022825B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Nov 24, 2015, at 12:27 PM, Hugo Krawczyk <hugo@ee.technion.ac.il> wrote:
On Tue, Nov 24, 2015 at 12:53 PM, Mike Hamburg = <mike@shiftleft.org> = wrote:

I agree that the speed and size = savings are not necessarily worth the complexity. If we were rolling a = new protocol from scratch they probably would be = though. 

=E2= =80=8BThe all-DH-based solution, with DH certificates, does not add = complexity but rather simplifies the protocol and analysis, and opens = the option of more efficient protocols (e.g. MQV-like ones). But the = world does not seem ready to depart from the beloved signature = certificates.
=E2=80=8BHugo=E2=80= =8B

I agree for new protocols, but the proposal = for TLS isn=E2=80=99t all-DH.  It=E2=80=99s allowing both all-DH = and DHE+sign.  That=E2=80=99s more complex than just allowing = DHE+sign.  But I suppose the difference in TLS as proposed is = really just putting a DH+MAC in CertificateVerify instead of a = signature, which isn=E2=80=99t a complicated difference.

Sorry to be negative. =  I really do like all-DH for simplicity, compactness and speed, = especially if IP-encumbered algorithms are available.  I=E2=80=99m = not against its inclusion in TLS if others think it=E2=80=99s worth the = complexity of adding another option.  But I=E2=80=99m grumpy = because this thread started with an insecure proposal justified using = incorrect numbers.

=E2=80=94 Mike
= --Apple-Mail=_CB4165EF-17FB-4814-BF46-09F9022825B2-- From nobody Tue Nov 24 14:31: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 A06B21A90B0 for ; Tue, 24 Nov 2015 14:31:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.363 X-Spam-Level: X-Spam-Status: No, score=-1.363 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, J_CHICKENPOX_34=0.6, RP_MATCHES_RCVD=-0.585, 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 Cdux7fNCpsAJ for ; Tue, 24 Nov 2015 14:31:08 -0800 (PST) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB4CA1A90AD for ; Tue, 24 Nov 2015 14:31:08 -0800 (PST) Received: by iouu10 with SMTP id u10so36373457iou.0 for ; Tue, 24 Nov 2015 14:31:08 -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=DBPrUAlAUHHAp2vEv414hF50Ef4V7qZpF/dv7TRypLk=; b=FwcXIzd9nICloS9nisd+O8kLm2WI8jAVtBYX/7En5lA1jsXEMDiyg8cW4Jh22+qZxl W7KgKTY2jnRzy42f+ZXgqh637MqcSlfRsJPTvyb6YxZzdt6DZuUJKUgbHcdiisPliW4m XJixtZ0Uwx+j2mzChU0iEUo6BOs+lWsFzB34Ibe3J5XsykwfMZ0PSHE3GH+HtbjebAKX 0eXagZ4NVF/X59C/EiXnhoBYaVbEHkRJW6S6rOXhMjgt/rV9sAKZG1n1og2JhhtsLjT4 3luvRbQqIr81c3rWxHGb2pLTgOVxbGyzVBtZJq+djpAu90LxVd/9Us8vlPq7+OohsCP1 XB+w== 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=DBPrUAlAUHHAp2vEv414hF50Ef4V7qZpF/dv7TRypLk=; b=JOqRc0fXjIJsEHH0w3PNhlvgXjodKAcqOewHuNmudLzozdiTDzo5GFpCTDkRyjdnP7 VkPNixiW8TR3QtB3e3nxHa2xEVoPYTuyiDMXX7XzDQs0TLIITvl3RDhxsOo/6SycWKQ4 tzLhvOvSVZ30v3KPN3VNdZRApSwcHwIiX6P8x7D0myCQtVgBs3lENrUj2eHHCqvJOcOZ hKdUUjT+tuMT/+pnVdOZBiINaVXlehoQeJJTLS/bxIwJYeXJHBnf/RY1KWBRPlakli3c 67vog36I87DK/WQsb9vv4Mg2uPrjBWLhIVvY+WTGfZppgxCtqND995/Ou5iil9cT6Nr9 kyBQ== X-Gm-Message-State: ALoCoQmE+fl8+e0FSoVlI7cjbFPvD6xNBTOQve9iLZzdm8oUoW8fxYvqtZXGf4H4eXj4t5CcZSyH MIME-Version: 1.0 X-Received: by 10.107.25.81 with SMTP id 78mr35513251ioz.127.1448404261572; Tue, 24 Nov 2015 14:31:01 -0800 (PST) Received: by 10.107.173.15 with HTTP; Tue, 24 Nov 2015 14:31:00 -0800 (PST) In-Reply-To: <727C6597-F386-4349-B334-6D8442354F1E@shiftleft.org> References: <689E730F-63D4-4D64-B678-D5A701983146@shiftleft.org> <727C6597-F386-4349-B334-6D8442354F1E@shiftleft.org> Date: Tue, 24 Nov 2015 14:31:00 -0800 Message-ID: From: Bill Cox To: Michael Hamburg Content-Type: multipart/alternative; boundary=001a113ff00a838a4e052550e588 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Should we use proof-of-possession rather than signatures? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 22:31:10 -0000 --001a113ff00a838a4e052550e588 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Nov 24, 2015 at 1:25 PM, Michael Hamburg wrote= : > I agree for new protocols, but the proposal for TLS isn=E2=80=99t all-DH.= It=E2=80=99s > allowing both all-DH and DHE+sign. That=E2=80=99s more complex than just= allowing > DHE+sign. But I suppose the difference in TLS as proposed is really just > putting a DH+MAC in CertificateVerify instead of a signature, which isn= =E2=80=99t a > complicated difference. > > Sorry to be negative. I really do like all-DH for simplicity, compactnes= s > and speed, especially if IP-encumbered algorithms are available. I=E2=80= =99m not > against its inclusion in TLS if others think it=E2=80=99s worth the compl= exity of > adding another option. But I=E2=80=99m grumpy because this thread starte= d with an > insecure proposal justified using incorrect numbers. > I need to remember not to skip details when writing to this group :) Yes, encrypting a handshake digest is the right thing to do, not the client random. I normally leave out this detail in discussions to simplify making my point. I'll see if I can correct some numbers below. Also, that was an awesome attack in the paper linked to above. Clearly, this is tricky territory to make changes securely! I think latency is more important than CPU overhead or whether the latency happens at the client or server. Since servers have well managed computation capability, it may be best to favor server-side latency, where it can be managed and minimized, vs client latency which can vary much more= . Just looking at TLS 1.3 1-RTT mode handshake (0-RTT does not use CertificateVerify), the latency looks like this: - First flight from client to server: 0 overhead, since ephemeral keyshare can be precomputed - First flight from server to client: 1 shared key derivation, in parallel with signing - Second flight from client to server: 1 shared key derivation in parallel with verification At least for Ed25519 and ECDSA-P256, signing is faster than shared key derivation, which is faster than signature verification. So, the latency is 1 shared key derivation + 1 signature verification. The median values for Skylake using curve25519/Ed25519 are, in cycles: keyshare computation: 150690 shared secret derivation: 143338 signing: 48990 verify signature: 161488 If we take full advantage of parallelism, the latency is 304,862 cycles. If instead we used ECC DH everywhere, it would be 2 keyshare computations = =3D 286676 cycles. There would only be about a 6% improvement, which is hard to get excited about. Also, on some other curves it could be slower, rather than faster. AFAIK, OpenSSL and most other TLS libraries do not use multiple threads, and will not take advantage of the available parallelism to reduce latency. At first glance, it looks like there is significant opportunity here, but I know the coders involved in this code base are among the best in the world. There is zero chance they decided to avoid pthreads without some pretty good reasons (cross-platform compatibility?). I bet the ephemeral keyshares are also not precomputed. Without multiple threads, the 1-RTT handshake takes 2 keyshare computations + 2 shared key derivations + 1 sign + 1 verify =3D 798534 cycles. With ECC DH based proof-of-possession, it would be 2 keyshare computations + 4 shared key derivations =3D 874732 cycles, worse than with the current signi= ng scheme. >From the paper, it sounds like using delegated keys currently has some unanticipated security problems, at least in the near term while we continue to accept incorrectly padded RSA based certs. Would Hugo's suggestions for extending certificates address weaknesses due to delegated keys, and allow DH keyshares to be used for proof-of-possession, and possibly MQV? If so, it sounds like a valuable upgrade. Thanks, Bill --001a113ff00a838a4e052550e588 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Nov 24, 2015 at 1:25 PM, Michael Hamburg <mike@shiftleft.org>= wrote:
I agree for new protocols, but the proposal for TLS isn=E2=80=99t all-DH.= =C2=A0 It=E2=80=99s allowing both all-DH and DHE+sign.=C2=A0 That=E2=80=99s= more complex than just allowing DHE+sign.=C2=A0 But I suppose the differen= ce in TLS as proposed is really just putting a DH+MAC in CertificateVerify = instead of a signature, which isn=E2=80=99t a complicated difference.
=

Sorry to be negative.=C2=A0 I really do like all-DH for= simplicity, compactness and speed, especially if IP-encumbered algorithms = are available.=C2=A0 I=E2=80=99m not against its inclusion in TLS if others= think it=E2=80=99s worth the complexity of adding another option.=C2=A0 Bu= t I=E2=80=99m grumpy because this thread started with an insecure proposal = justified using incorrect numbers.

<= div>I need to remember not to skip details when writing to this group :) = =C2=A0Yes, encrypting a handshake digest is the right thing to do, not the = client random.=C2=A0 I normally leave out this detail in discussions to sim= plify making my point.=C2=A0 I'll see if I can correct some numbers bel= ow.=C2=A0 Also, that was an awesome attack in the paper linked to above.=C2= =A0 Clearly, this is tricky territory to make changes securely!
<= br>
I think latency is more important than CPU overhead or w= hether the latency happens at the client or server.=C2=A0 Since servers hav= e well managed computation capability, it may be best to favor server-side = latency, where it can be managed and minimized, vs client latency which can= vary much more.

Just looking at TLS 1.3 1-RTT mod= e handshake (0-RTT does not use CertificateVerify), the latency looks like = this:

- First flight from client to server: 0 over= head, since ephemeral keyshare can be precomputed
- First flight = from server to client: 1 shared key derivation, in parallel with signing
- Second flight from client to server: 1 shared key derivation in p= arallel with verification

At least for Ed25519 and= ECDSA-P256, signing is faster than shared key derivation, which is faster = than signature verification.=C2=A0 So, the latency is 1 shared key derivati= on + 1 signature verification.=C2=A0 The median values for Skylake using cu= rve25519/Ed25519 are, in cycles:

keyshare computat= ion:=C2=A0150690
shared secret derivation: 143338
<= div>signing: 48990
verify signature: 161488
<= br>
If we take full advantage of parallelism, the latency is 304,= 862 cycles.=C2=A0 If instead we used ECC DH everywhere, it would be 2 keysh= are computations =3D 286676 cycles.=C2=A0 There would only be about a 6% im= provement, which is hard to get excited about.=C2=A0 Also, on some other cu= rves it could be slower, rather than faster.

AFAIK= , OpenSSL and most other TLS libraries do not use multiple threads, and wil= l not take advantage of the available parallelism to reduce latency.=C2=A0 = At first glance, it looks like there is significant opportunity here, but I= know the coders involved in this code base are among the best in the world= .=C2=A0 There is zero chance they decided to avoid pthreads without some pr= etty good reasons (cross-platform compatibility?).=C2=A0 I bet the ephemera= l keyshares are also not precomputed.

Without mult= iple threads, the 1-RTT handshake takes 2 keyshare computations + 2 shared = key derivations + 1 sign + 1 verify =3D 798534 cycles.=C2=A0 With ECC DH ba= sed proof-of-possession, it would be 2 keyshare computations + 4 shared key= derivations =3D 874732 cycles, worse than with the current signing scheme.=

From the paper, it sounds like using delegated ke= ys currently has some unanticipated security problems, at least in the near= term while we continue to accept incorrectly padded RSA based certs.=C2=A0= Would Hugo's suggestions for extending certificates address weaknesses= due to delegated keys, and allow DH keyshares to be used for proof-of-poss= ession, and possibly MQV?=C2=A0 If so, it sounds like a valuable upgrade.

Thanks,
Bill
<= /div> --001a113ff00a838a4e052550e588-- From nobody Tue Nov 24 14:42: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 CCB2F1A90FB for ; Tue, 24 Nov 2015 14:42:49 -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, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1cBeTjeP8c1 for ; Tue, 24 Nov 2015 14:42:48 -0800 (PST) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 807C71A90FA for ; Tue, 24 Nov 2015 14:42:48 -0800 (PST) Received: by ykdv3 with SMTP id v3so37024403ykd.0 for ; Tue, 24 Nov 2015 14:42:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=bZWSoLag3cIkOQ5ghpqnwx1j+ZXIuimFklpy23XQR74=; b=IIIGAUetKjw70rs/nTp7J9foVs74sHLDqIsv41Ab5QghGr+nPPuaTO25saPqrOHev0 mCIk6PgmiCyHl4npbN8Zk7ZfOdc4Odi/cOT9luaG8fbvVGzPz2oeQ8eCI0o57oDH7oWr FIi4egPMBEOZnDcScVFlfJ+OCA3hNcQ1dzC4uHYjXeTMRry7IDrFy36FrTX5RIQLWM+Y Ap4RhioPT3HSJHoG/0cgMfTYj30Q6kMhIeibpOzaLsYGdtW16iaEJ5HQGlaJ7/q9mHeC bGcTz0xCA8ra+8ujpgbShoPCzECks2d9g1i2Tgl5GMS5nUlHNfvDWB+7kaZWL1S3mX6I s04Q== 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=bZWSoLag3cIkOQ5ghpqnwx1j+ZXIuimFklpy23XQR74=; b=T15iW+VZvqfOiZjtKjAEL9RmOCvE4QUOrgI1kxFGlR5RAR/4fEi9LNAqsg0DIwExhk pPNK6QiLHzsaXQ6m8vJ8GPdrWc9X7yOADowpYMeAyvmk0N+BuxPUcrTdd66sB3g7V1nt B4dy95+FhoZyh6qgEsXi9HdVFjDHz8GrMtHDIq/BYbJ6u8GvhngGQNhinGd50oJhTg1F dkrzj9qSj88PnW+k/r962G/sMLMbtWGVnBZLiBiAjlV+zvYbGYbiLkZEnHi0HbzdfCHG hAafGooYZZtJo+NYUp7niKy34tZVraf1o5HKIqruoLhtevrng9s9LyucQa6wWYu+wmEU txWg== X-Gm-Message-State: ALoCoQksUzYlut9IrO8z8VD4M/5zvqdXSNCjBkTBAI7eDihPo7Gq9lUOH7tqds8HIbiHBELxaaCk X-Received: by 10.129.46.136 with SMTP id u130mr500055ywu.129.1448404967833; Tue, 24 Nov 2015 14:42:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.232.201 with HTTP; Tue, 24 Nov 2015 14:42:08 -0800 (PST) In-Reply-To: References: <689E730F-63D4-4D64-B678-D5A701983146@shiftleft.org> <727C6597-F386-4349-B334-6D8442354F1E@shiftleft.org> From: Eric Rescorla Date: Tue, 24 Nov 2015 14:42:08 -0800 Message-ID: To: Bill Cox Content-Type: multipart/alternative; boundary=001a114095969968720525510f50 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Should we use proof-of-possession rather than signatures? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 22:42:50 -0000 --001a114095969968720525510f50 Content-Type: text/plain; charset=UTF-8 On Tue, Nov 24, 2015 at 2:31 PM, Bill Cox wrote: > > From the paper, it sounds like using delegated keys currently has some > unanticipated security problems, at least in the near term while we > continue to accept incorrectly padded RSA based certs. Would Hugo's > suggestions for extending certificates address weaknesses due to delegated > keys, and allow DH keyshares to be used for proof-of-possession, and > possibly MQV? If so, it sounds like a valuable upgrade. > The underlying concern is misuse of *existing* server's signing keys to produce essentially permanent delegations. So, as Hugo observed, requiring a certificate extension (or DH certificates) removes this case. As I mentioned in my earlier message, we discussed this extensively at a number of meetings and came to the WG consensus that it would be good if someone wrote a separate draft documenting one or both of these mechanisms, but that it shouldn't be on the critical path for TLS 1.3. Volunteers wanted! -Ekr > Thanks, > Bill > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a114095969968720525510f50 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Nov 24, 2015 at 2:31 PM, Bill Cox <waywardgeek@google.com>= wrote:
From the paper, it sound= s like using delegated keys currently has some unanticipated security probl= ems, at least in the near term while we continue to accept incorrectly padd= ed RSA based certs.=C2=A0 Would Hugo's suggestions for extending certif= icates address weaknesses due to delegated keys, and allow DH keyshares to = be used for proof-of-possession, and possibly MQV?=C2=A0 If so, it sounds l= ike a valuable upgrade.

=
The underlying concern is misuse of *existing* server's sign= ing keys to produce essentially
permanent delegations. So, as Hug= o observed, requiring a certificate extension (or DH
certificates= ) removes this case. As I mentioned in my earlier message, we discussed thi= s
extensively at a number of meetings and came to the WG consensu= s that it would
be good if someone wrote a separate draft documen= ting one or both of these mechanisms,
but that it shouldn't b= e on the critical path for TLS 1.3. Volunteers wanted!

=
-Ekr




Thanks,
Bill

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


--001a114095969968720525510f50-- From nobody Tue Nov 24 16:34: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 00E9B1AC3D0 for ; Tue, 24 Nov 2015 16:34:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.963 X-Spam-Level: X-Spam-Status: No, score=-1.963 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, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ipxGH6EQywPn for ; Tue, 24 Nov 2015 16:34:37 -0800 (PST) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91E2E1AC3CD for ; Tue, 24 Nov 2015 16:34:37 -0800 (PST) Received: by igvg19 with SMTP id g19so107316279igv.1 for ; Tue, 24 Nov 2015 16:34:36 -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=QgPgigAIhTQajP/M11ls+0uVVY1tkybrkzWPrmXf518=; b=KEsQU04vG9LFTdDAQ8VP3TDhl7Usz/TBYQHuS2vEOS8vvoSWXr6ZwA1FvLGXUPVeoX 0z6kLReTg2a0lY+HGoEymRmRd4N4mNlXqjvAyJs4K7+t7+W8Jv18y6DV9sc62nbvtjNN 4tDthBJHEp65obyJR718mql/xUWSdxLCm47WhgVTaId1NVeGAFcDFUT/yiJasq6NtbAT 8kXZEQYZSUWtTjMs/ugpOPAimxZ8YKA+wmjKav1uzwe62FdS2ek7el8DR5M3CjKGYLXr YTMuVVwf6j6GAneHyIpwjtC9KwU2DrKCiPl8a+iA6MSedTH0Kisr2m5K9g4S4nQgKRyu 7yrw== 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=QgPgigAIhTQajP/M11ls+0uVVY1tkybrkzWPrmXf518=; b=PpJ+uIavWDGqMlnXsq0shMKjHq+wQVxArdZjrIPgR9t+GZuNlGiK4xo/vvtiIUw0m3 KkwroHwCWlqOiviDSxKjePwK1tGDHILTC5YZ1pgtmEPspE5CX8tjQhsmY1CO7S8/BdHF pr7HR638DqbXNEJfNy34XUYr+Lggnh+HcJG/GdWL26NnCyP6dVUAjdBY9AN2ekTKU9P0 ALih+Bln1XjasCiLJdfTVIQOH6SSEIkYy9lg9qJpQOF1HpNMX3veuoes1Q6MtXMRbST1 rEHKa4j9XDQWPp7zMfm1vNj8vsqRqopsjzGCd/MaUEAVGVWVeIWxWruaEvAnZzonqzYi LZlA== X-Gm-Message-State: ALoCoQlixm9gMn6KllflhXNNtTbxPQFaiW+oGVdcpjFjVL8T6OSZBCCqGZAyoJRL05mdqCeJPLgq MIME-Version: 1.0 X-Received: by 10.50.150.106 with SMTP id uh10mr1334621igb.85.1448411676781; Tue, 24 Nov 2015 16:34:36 -0800 (PST) Received: by 10.107.173.15 with HTTP; Tue, 24 Nov 2015 16:34:36 -0800 (PST) In-Reply-To: References: <689E730F-63D4-4D64-B678-D5A701983146@shiftleft.org> <727C6597-F386-4349-B334-6D8442354F1E@shiftleft.org> Date: Tue, 24 Nov 2015 16:34:36 -0800 Message-ID: From: Bill Cox To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a11c3b1da7bfb940525529f91 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Should we use proof-of-possession rather than signatures? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 00:34:39 -0000 --001a11c3b1da7bfb940525529f91 Content-Type: text/plain; charset=UTF-8 On Tue, Nov 24, 2015 at 2:42 PM, Eric Rescorla wrote: > As I mentioned in my earlier message, we discussed this > extensively at a number of meetings and came to the WG consensus that it > would > be good if someone wrote a separate draft documenting one or both of these > mechanisms, > but that it shouldn't be on the critical path for TLS 1.3. Volunteers > wanted! > > -Ekr > Well, I'm currently over-committed and owe a patch for EMS resumption, and initial integration of Blake2, and I'm behind at work because I got caught with my pants down by the security implications of 0-RTT connections. However, I'd be happy to add it to my list and help if I can :) Bill --001a11c3b1da7bfb940525529f91 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Nov 24, 2015 at 2:42 PM, Eric Rescorla <ekr@rtfm.com> wrote:<= br>
As I mentioned in my earlier message, we= discussed this
extensively at a number of meetings and came to t= he WG consensus that it would
be good if someone wrote a separate= draft documenting one or both of these mechanisms,
but that it s= houldn't be on the critical path for TLS 1.3. Volunteers wanted!
<= div>
-Ekr

=
Well, I'm currently over-committed and owe a patch for EMS resumpt= ion, and initial integration of Blake2, and I'm behind at work because = I got caught with my pants down by the security implications of 0-RTT conne= ctions.=C2=A0 However, I'd be happy to add it to my list and help if I = can :)

Bill=C2=A0
--001a11c3b1da7bfb940525529f91-- From nobody Wed Nov 25 11:05: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 A57DE1AD1A3 for ; Wed, 25 Nov 2015 11:05:42 -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, 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 gb1yWQ_mpx77 for ; Wed, 25 Nov 2015 11:05:40 -0800 (PST) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB7B41AD0EA for ; Wed, 25 Nov 2015 11:05:39 -0800 (PST) Received: by lfaz4 with SMTP id z4so72143523lfa.0 for ; Wed, 25 Nov 2015 11:05:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JAX3Ylzj8KryfIyLSBr1e0i0fVQv46Kw9ph5Dc8QHR0=; b=hiIv1Cff/1JbF+feStIQvuMS+PYoONxeegFdonTh3wGOXI1zSm5bN+iJFe5NHdB5yN y8oBO8tKSGEMOGhTOBQBWH3nlZ/Pfx+XQW45sHuDk6cIJ+UFqtJmSb+BLuNLzhpa452c J/GfQb0PsJ+Fh1fkkZ+3knYrt4kr1w2RuGDezkIBm6tRfgJo1tFExSaHHLlj57eSSKB2 7PBqiXN6XHRKhzblgun2om7aXxlzdYZVJZ6bNOOkxm1XlfZXqTnVhL1xLA9PoMfjKBSR WC8hyEAtZLDVC8Xoqo5MVy88h9iaOenxHXT9WAe92R2IbpiUF6rWDS//j5e6m0mJZgg1 oWKA== 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=JAX3Ylzj8KryfIyLSBr1e0i0fVQv46Kw9ph5Dc8QHR0=; b=IetLXhAuqXO9rGonwRHWPNBroNegGFRV7ykAtY3zAET+4H15F+roq5o3SQJ24tPpwR LLi3OK94yuQKSVAmBLaTA4I5tgnCKDRJcMVMo3Pfq3Dq2Rf9x7Zt/pt02pQ702h9SSvE j4lKX0ypVFtMKXgIBUdsQ8KYvu5j6h/Gl4B4cLgVeJz+Sh/jF4n/z+DJVlI+DYtBRw4a Jy3tEkziCI3TW9FCdEx6cDHv27H/mZWsNEzSR7hJF6pnO9NTpNCpU7q/Y4U+/7Ybni4f 2aBnjw3HSf66A3s82IxFEzzzRuJQnK4C64F1h3Jew0EKZZ5PHbtxYPazqdgmVsGWA3h0 qS3w== X-Gm-Message-State: ALoCoQkO1vbOKuQvByv8iX7vMtqrlMJ4Gql4j0L8WP15kIwxxiqn6gKTw/ywztTsZ8JrhjyjYFpa MIME-Version: 1.0 X-Received: by 10.25.35.194 with SMTP id j185mr17522846lfj.62.1448478337849; Wed, 25 Nov 2015 11:05:37 -0800 (PST) Received: by 10.112.24.131 with HTTP; Wed, 25 Nov 2015 11:05:37 -0800 (PST) In-Reply-To: References: <20151119150312.E8CDA1A383@ld9781.wdf.sap.corp> Date: Wed, 25 Nov 2015 11:05:37 -0800 Message-ID: From: Joseph Salowey To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a113a9f04cb01a0052562241f Archived-At: Subject: Re: [TLS] PR#345: IANA Considerations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 19:05:42 -0000 --001a113a9f04cb01a0052562241f Content-Type: text/plain; charset=UTF-8 It looks like we have rough consensus to accept this PR. We can still have discussion on the naming of the categories. We will also have to define the IANA registration policy for changing the "recommended" bit. I'll open an issue for this, I think changing the bit to recommended should require IETF consensus. Cheers, Joe On Thu, Nov 19, 2015 at 7:10 AM, Eric Rescorla wrote: > > > On Thu, Nov 19, 2015 at 7:03 AM, Martin Rex wrote: > >> Eric Rescorla wrote: >> > >> > There are presently four categories of cipher suites vis-a-vis TLS 1.3. >> > >> > 1. MUST or SHOULD cipher suites. >> > 2. Standards track cipher suites (or ones we are making ST, like >> > the ECC ones). >> > 3. Non standards track cipher suites >> > 4. Cipher suites you can't use at all with TLS 1.3, like AES-CBC. >> > >> > I think we're all agreed that category #1 should be marked recommended >> > and that #3 and #4 should not be. This leaves us with category #2, which >> > includes stuff like: >> > >> > - FFDHE >> > - CCM >> > >> > My proposal is that we: >> > >> > - List all the Standards Track cipher suites that are compatible with >> TLS >> > 1.3 in Appendix A. >> > - Mark all the cipher suites that are listed in Appendix A as >> "Recommended" >> >> >> I'm slightly confused. >> >> rfc5288 is standards track and describes AES-GCM with static RSA keyex. >> > > This isn't compatible with TLS 1.3 because TLS 1.3 removes static RSA. > > > rfc5289 is only informational (i.e. _not_ standards track) and describes >> AES-GCM with ECDHE keyex. > > > We are re-labelling the AES-GCM ECDHE suites as standards track either in > this document or in RFC4492bis. > > -Ekr > > >> >> >> >> -Martin >> > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a113a9f04cb01a0052562241f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It looks like we have rough = consensus to accept this PR. We can still have discussion on the naming of = the categories.=C2=A0 We will also have to define the IANA registration pol= icy for changing the "recommended" bit. =C2=A0 I'll open an i= ssue for this, =C2=A0I think changing the bit to recommended should require= IETF consensus. =C2=A0

Cheers,

Joe

On Thu, Nov 19, 2015 at 7:10 AM, Eric Rescorla <ekr@rtf= m.com> wrote:


On Thu, Nov 19, 2= 015 at 7:03 AM, Martin Rex <mrex@sap.com> wrote:
Eric Rescorla wrote:
>
> There are presently four categories of cipher suites vis-a-vis TLS 1.3= .
>
> 1. MUST or SHOULD cipher suites.
> 2. Standards track cipher suites (or ones we are making ST, like
>=C2=A0 =C2=A0 =C2=A0the ECC ones).
> 3. Non standards track cipher suites
> 4. Cipher suites you can't use at all with TLS 1.3, like AES-CBC.<= br> >
> I think we're all agreed that category #1 should be marked recomme= nded
> and that #3 and #4 should not be. This leaves us with category #2, whi= ch
> includes stuff like:
>
> - FFDHE
> - CCM
>
> My proposal is that we:
>
> - List all the Standards Track cipher suites that are compatible with = TLS
> 1.3 in Appendix A.
> - Mark all the cipher suites that are listed in Appendix A as "Re= commended"


I'm slightly confused.

rfc5288 is standards track and describes AES-GCM with static RSA keyex.
=

This isn't compatible with TLS = 1.3 because TLS 1.3 removes static RSA.


=
rfc5289 is only informational (i.e. _not_ standards track) and describes AES-GCM with ECDHE keyex.

We are re-= labelling the AES-GCM ECDHE suites as standards track either in this docume= nt or in RFC4492bis.

-Ekr
=C2=A0



-Martin


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


--001a113a9f04cb01a0052562241f-- From nobody Wed Nov 25 11:12: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 6F0B61B2C2D for ; Wed, 25 Nov 2015 11:12:33 -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, 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 SvWqLWLH6yTX for ; Wed, 25 Nov 2015 11:12:32 -0800 (PST) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::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 743961B2BDD for ; Wed, 25 Nov 2015 11:12:31 -0800 (PST) Received: by lffu14 with SMTP id u14so72444090lff.1 for ; Wed, 25 Nov 2015 11:12:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Hlx6lnt2uQdSLoJWwv06qauNgNdKbW6bSyaqjt8MA4o=; b=Rb0wUnQLZSlKQC0q1B6SqXKfevfAmfC3AWA3AC4QHax8fn1f3Qm4Gexsbxq2NBRElB 8pLIG9CzGIKlTJW64JBJTk2oxyKReK6LGysBBYv+bubUQia2LO4taTg6DP8Daa/tcbYy RxhZU2PQWBvn/95zQ9K4r6VbP/ScwBUaFQojBg59BKvNCjdYjVQGyy7K2z4pE+VllSzV z+QrIAuMQGW4nszPvSJ2RPgreZO6r3pkhubqy9tEM+1QQltTMczmV96UTo/60v/s2pZW R5i15rQ94vQ7JVE8D6Zm72DWVtPQjJPtvg32k2qyaf0ZaDt3qbrxpwBRhAfGwTiIPZAX 5Pyg== 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=Hlx6lnt2uQdSLoJWwv06qauNgNdKbW6bSyaqjt8MA4o=; b=PP5Pa3tsRcSAxjy2HbU48cRIBUCep78a7/D7J+0ODJ/Uxi0CJaLVgHG40eBSaS/ftz EF3XzPZ+TmnWX9tCT1+xS8zvWy/QlztfCu4lec9B/hTRPaubShK3O/OESb33w98aUno5 E3YGopGWWhRqPMc1IOPKEYjABbWOeuJjFPhuXsm21gA12OdcKPnhWqfJEphqI7O0HExJ /jZDDIOCC3yr++YDeWdtktt/TzXmGaHc8MgHIQ574g122J828lMEBloLS8A2/zsyEMv1 9jW8Wo3aXLVMKyEhJAJDck/HzCXB159w5njugOeNC76ssmisdmNNvt7J8Ij0NjgnF2FR 5Orw== X-Gm-Message-State: ALoCoQkOpu+ujhmaihfkL2ANn+PVIbheuQAi93mSEObz90EniXA384h29hk3uJN67/9soOf3jj3L MIME-Version: 1.0 X-Received: by 10.25.22.214 with SMTP id 83mr17230967lfw.8.1448478749508; Wed, 25 Nov 2015 11:12:29 -0800 (PST) Received: by 10.112.24.131 with HTTP; Wed, 25 Nov 2015 11:12:29 -0800 (PST) In-Reply-To: References: <201510171708.16547.davemgarrett@gmail.com> <201510171734.26589.davemgarrett@gmail.com> <20151017220548.GF15070@mournblade.imrryr.org> <20151017221733.GG15070@mournblade.imrryr.org> <20151017230257.GI15070@mournblade.imrryr.org> <84C5B67D-F236-4BFD-AA13-5CC13062B8C5@akamai.com> Date: Wed, 25 Nov 2015 11:12:29 -0800 Message-ID: From: Joseph Salowey To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11407ed85521350525623d93 Archived-At: Subject: Re: [TLS] PR for anti-downgrade 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, 25 Nov 2015 19:12:33 -0000 --001a11407ed85521350525623d93 Content-Type: text/plain; charset=UTF-8 It looks like we have rough consensus to accept this PR. We should make sure we note the limitations that Karthink brought up for PSK and RSA, https://mailarchive.ietf.org/arch/msg/tls/sZX9ursx4ePK2Zr-yflO2nUtiQY. Procedurally, we should document the requirements for TLS 1.2 in a separate draft to update TLS 1.2 in parallel. This may be necessary to get us out of the situation where we have to update and obsolete a specification at the same time. Thanks, J&S On Mon, Nov 9, 2015 at 4:44 PM, Eric Rescorla wrote: > > > On Mon, Nov 9, 2015 at 4:41 PM, Christian Huitema > wrote: > >> On Monday, November 9, 2015 4:34 PM, Eric Rescorla wrote: >> >> > On Mon, Nov 9, 2015 at 4:30 PM, Christian Huitema < >> huitema@microsoft.com> wrote: >> > >> >... >> >> Editorial: your proposed text says "...MUST set the first six bytes >> of its Random value >> >> to the the bytes 44 4F 57 4E 47 52 44 01." I assume you mean the first >> 8 bytes, and that >> >> you do not really want to have "the" twice. >> > >> > Fixed. >> >> Thanks >> >> >> Could you also add a reference to the document that specifies using 44 >> 4F 57 4E 47 52 >> >> 44 00 by "TLS 1.2 servers which are negotiating TLS 1.1 or below" ? >> > >> > We don't have one. Wasn't totally sure how to handle that. >> >> I suspected that. Spent sometimes looking for text in published RFC, >> could not find it. I suspect that many readers will fall in the same trap >> and lose some time. Could you add text explaining that this is an >> undocumented feature of some implementations, and that we are recommending >> its use? Or something to that effect... >> > > Worse, we just invented it. What about if I say "TLS 1.2 servers SHOULD..." > > -Ekr > > >> >> -- Christian Huitema >> >> >> >> > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a11407ed85521350525623d93 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It looks like we have rough = consensus to accept this PR.=C2=A0 We should make sure we note the limitati= ons that Karthink brought up for PSK and RSA,=C2=A0https://mailarchive.ietf.org/arch/msg/tls/sZX9ursx4ePK2= Zr-yflO2nUtiQY.=C2=A0 Procedurally, we should document the requirements= for TLS 1.2 in a separate draft to update TLS 1.2 in parallel. =C2=A0 This= may be necessary to get us out of the situation where we have to update an= d obsolete a specification at the same time. =C2=A0

Thanks,

J&S

On Mon, Nov 9= , 2015 at 4:44 PM, Eric Rescorla <ekr@rtfm.com> wrote:

On Mon, Nov 9, 2015 at 4:41 PM= , Christian Huitema <huitema@microsoft.com> wrote:
On Monday, November 9, 2015 4:34 PM, Eri= c Rescorla wrote:

> On Mon, Nov 9, 2015 at 4:30 PM, Christian Huitema <huitema@microsoft.com> wr= ote:
>
>...
>> Editorial: your proposed text says "...MUST set the fir= st six=C2=A0 bytes of its Random value
>> to the the bytes 44 4F 57 4E 47 52 44 01." I assume you mean = the first 8 bytes, and that
>> you do not really want to have "the" twice.
>
> Fixed.

Thanks

>> Could you also add a reference to the document that specifies usin= g 44 4F=C2=A0 57 4E 47 52
>> 44 00 by "TLS 1.2 servers which are=C2=A0 negotiating TLS 1.1= or below" ?
>
> We don't have one. Wasn't totally sure how to handle that.

I suspected that. Spent sometimes looking for text in published RFC,= could not find it. I suspect that many readers will fall in the same trap = and lose some time. Could you add text explaining that this is an undocumen= ted feature of some implementations, and that we are recommending its use? = Or something to that effect...

W= orse, we just invented it. What about if I say "TLS 1.2 servers SHOULD= ..."

-Ekr
=C2=A0

-- Christian Huitema





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


--001a11407ed85521350525623d93-- From nobody Wed Nov 25 11:39: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 998871A87C1 for ; Wed, 25 Nov 2015 11:39:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 5A8iRzOKnnJq for ; Wed, 25 Nov 2015 11:39:30 -0800 (PST) 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 12B9E1A87B3 for ; Wed, 25 Nov 2015 11:39:30 -0800 (PST) Received: by qgec40 with SMTP id c40so39762243qge.2 for ; Wed, 25 Nov 2015 11:39:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jZJ0OZNh4mnzw//2x7rwR41d0FvWLWletCaV04wUWfY=; b=MKpLpqzvSSttF6uHtVy0+1diMQhugQTvKAEhSagYpOQYjreoPB1Oa899VSpXXirADz U2Az4UC8lOz/nfRdxO0YorCJ9b1K3mPRQ+cQQGYvNORaNhfI24r6GCdFZizliT/Fr6GL 6m9Wb6VeZm+OFMH76xn2znemcBq8UDzgLT7Gs= 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=jZJ0OZNh4mnzw//2x7rwR41d0FvWLWletCaV04wUWfY=; b=ZcGeAyXwkjOUPPJ3tZYrJ40eCrWRtjUoxyaVu2SmIJk5Vk9+YXh1YnUPmEVfOZD0Rv Iqw/QKE4cQL/2EcNtvBOuY2Y9fEEYqcM90nzaTkmbBUVE4Gj8TSY9sQwctu60Hgf+dfg tzqpyLiiqYkdWsnDdL747eF1eg0KHpiUKANwW8YNDKEHq5tbUIsS9INlzooEaVLn3Jcv Zw5FFiTDptipf5OljcT1c1OyLCdBBm3eXKgUsyE/F27Su7LDG+B35/fPVUn7EUuWX9Eh XVEzrDRvjCRVZH+ajy6Qr442bPEUbazsZQG3pH/8JzQcs20m7jgpoJ2M8sS/80/v52/c TydQ== X-Gm-Message-State: ALoCoQm+SAP4/ylkmLZ4bDKc0h+Ok5FPRFfDJnrgw375vzRNgQaaWakSdMLCocZj1niGOc9l431/ X-Received: by 10.140.88.212 with SMTP id t78mr41003339qgd.82.1448480369237; Wed, 25 Nov 2015 11:39:29 -0800 (PST) Received: from [172.16.0.112] (pool-173-73-126-234.washdc.east.verizon.net. [173.73.126.234]) by smtp.gmail.com with ESMTPSA id 81sm5900076qhx.15.2015.11.25.11.39.28 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 25 Nov 2015 11:39:28 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Sean Turner In-Reply-To: Date: Wed, 25 Nov 2015 14:39:27 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <58021124-ACB3-4E00-8736-3CA23C94CD52@sn3rd.com> References: To: Martin Thomson X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] SHA-1 patch updated with Russ' suggestion X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 19:39:31 -0000 After reviewing the list discussion, PR#317 = (https://github.com/tlswg/tls13-spec/pull/317) is okay to merge. = Initially, there was some confusion about exactly what changes were = being proposed (PR#317 is built on PR#231) but that seems to have no be = cleared up; text about not checking the signature on a self-signed = certificates has been added in various places. Thanks, J&S > On Nov 05, 2015, at 04:47, Martin Thomson = wrote: >=20 > Nitpicks accepted, pull requests preferred: >=20 > https://github.com/tlswg/tls13-spec/pull/317 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Nov 25 12:29:50 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 941CC1B2F54 for ; Wed, 25 Nov 2015 12:29:49 -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 O5C504rAX9iS for ; Wed, 25 Nov 2015 12:29:47 -0800 (PST) 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 6D7F71B2F47 for ; Wed, 25 Nov 2015 12:29:47 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 7BFC4284E33; Wed, 25 Nov 2015 20:29:45 +0000 (UTC) Date: Wed, 25 Nov 2015 20:29:45 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20151125202945.GW18315@mournblade.imrryr.org> References: <58021124-ACB3-4E00-8736-3CA23C94CD52@sn3rd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <58021124-ACB3-4E00-8736-3CA23C94CD52@sn3rd.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] SHA-1 patch updated with Russ' suggestion X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 20:29:49 -0000 On Wed, Nov 25, 2015 at 02:39:27PM -0500, Sean Turner wrote: > After reviewing the list discussion, PR#317 > (https://github.com/tlswg/tls13-spec/pull/317) is okay to merge. Initially, > there was some confusion about exactly what changes were being proposed > (PR#317 is built on PR#231) but that seems to have no be cleared up; text > about not checking the signature on a self-signed certificates has been > added in various places. It seems the below is the final text on server certificates and SHA-1: https://github.com/martinthomson/tls13-spec/commit/bd7d7058d43c946142a8628e7d9103bdf346470a +All certificates provided by the server MUST be signed by a +hash/signature algorithm pair that appears in the "signature_algorithms" +extension provided by the client, if they are able to provide such +a chain (see {{signature-algorithms}}). +If the server cannot produce a certificate chain that is signed only via the +indicated supported pairs, then it SHOULD continue the handshake by sending +the client a certificate chain of its choice that may include algorithms +that are not known to be supported by the client. This fallback chain MAY +use the deprecated SHA-1 hash algorithm. No problem with that text. The text for the receiving end could perhaps use a bit of refinement: +As SHA-1 and SHA-224 are deprecated, support for them is NOT RECOMMENDED. +Endpoints that reject chains due to use of a deprecated hash MUST send +a fatal "bad_certificate" alert message before closing the connection. +All endpoints are RECOMMENDED to transition to SHA-256 or better as soon +as possible to maintain interoperability with implementations +currently in the process of phasing out SHA-1 support. the point being that the layer that's deciding that the hash algorithms in the chain are or are not satisfactory is often well above the code that's responsible for low-level protocol message processing and alert generation. Weak signature algorithms will often simply present as trust failures, and may be reported in the same way as chains for which no suitable trust anchor is found. One reason why a precise error may be difficult is that "path construction" algorithms need not use the particular certificates provided by the peer, and may have access to alternative certificates with which to build the chain. So when an untrusted digest is encountered, the simplest approach is to ignore that certificate (filter such certificates out of the peer's response) and try to build a chain without it. Which means that the final error may not be related to that problem digest. The main case in which one can reasonably expect that the problem digest will be reported is if the weak signature is in the leaf certificate, rather than in an intermediate CA. Some applications don't abort the handshake when trust fails, they continue and disconnect at the application layer. So the upshot is that perhaps "MUST" above is stronger than possible. On the other hand, I don't see implementations taking that MUST too seriously if it does not comport with how certificate chain construction and verification is done. Mere presence of an unsupported digest in the certificate message should not be a reason to send the alert and abort, the certificate with the problem digest might not be needed in the end. So the decision will (or at least should) generally be delayed until chain construction and verification take place, where there's enough complexity that the proposed MUST may not possible. My recommendation would be to encourage implementations to not reject peer certificate messages out of hand (prior to attempting chain construction and verification) merely because they happen to contain an element with an unsupported signature. When chain verification fails, the library will do its best to communicate the reason, which may be that its best chain candidate had an unsupported digest and a "bad_certificate" alert is then sent. It may also be that no candidate chain is constructed (the simpler ignore unsupported intermediates approach), in which case the fatal alert is more likely "certificate_unknown". -- Viktor. From nobody Thu Nov 26 05:52: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 2FBE21B39D7 for ; Thu, 26 Nov 2015 05:52:39 -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, 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 80M0aO8N0hy6 for ; Thu, 26 Nov 2015 05:52:37 -0800 (PST) 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 B30641B39D5 for ; Thu, 26 Nov 2015 05:52:37 -0800 (PST) Received: by obbbj7 with SMTP id bj7so63147782obb.1 for ; Thu, 26 Nov 2015 05:52:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vimino-com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to:content-type; bh=CjxzeEKMVHcfJJEOO0dwgbXXfPZ9zGPPip6Wk928/8E=; b=owfJ5PU/vJCK5hv9NeMd7KYHbckYvLRz0tWrwQirrGbRA/SDfQlTFxW/YGU78IGgx1 WC6eOrXVoVKTWR61sv9ISvpDlal+MTVKC30VsWHQZ2LsG9gHGyrkKAokHVfCcWgETf4c K+iUq6y84CJ4ZjSjucaMC02/AUEXN2kdh+blrk1LiaywgLQxRhmZWoidxs1JjaGDl416 tEPdkBUVVLX42kXZ9RaR/WACtIFqWkWBAVipjhoKlCgZPa7/K12esQX9dPq8Rp8F3Dw+ +3jgYvruBwxkrQizdaVNYDwFZLlYuggWMopHnIvyHmvnDbpuhPA88RcJbt4zCiIwVf5y zF1A== 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=CjxzeEKMVHcfJJEOO0dwgbXXfPZ9zGPPip6Wk928/8E=; b=kzTlQmmxtR6Px5uxFVi6rmzNFECRwMzTZ4RI0zkimjAVO1EQNiKWulM2+qsmGh4Zx+ Xdkyo/x2frgwGQ8N8KOH/n5A+oGoIPzrviFzSeZ5FeU0t26ehBwjW/09qtji7lz0asey CEFtBSbJO8xRKxxlFfYTjpTemingqbiaf8XmXdn6gHSv1dlFZY61aBjloWGMkxvSkPsg 4u+yB5QQBVVLfBs85ORtSNyc8dp+Pg397P+yyacc74pgGaVsDZTSoimboBcTUMCoxv4Y kttE4Lf82VtrpZ3GqqIm9vR8Uuij8ARR9LP2abuMnjg8xkPc6SF5nVW0KIEP4wNWHR6M tYNQ== X-Gm-Message-State: ALoCoQlzr7MPRmvA9qdVWgqr8eY2L3tf12uHGygLzR1kO9MPvGnW5oC9FCaKlf7jYYNl5snjFxf7 MIME-Version: 1.0 X-Received: by 10.60.173.42 with SMTP id bh10mr27981895oec.58.1448545957115; Thu, 26 Nov 2015 05:52:37 -0800 (PST) Received: by 10.76.171.103 with HTTP; Thu, 26 Nov 2015 05:52:37 -0800 (PST) X-Originating-IP: [148.87.19.222] Date: Thu, 26 Nov 2015 21:52:37 +0800 Message-ID: From: Xuelei Fan To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=047d7bd6bf1c371414052571e337 Archived-At: Subject: [TLS] Extensions "supported_groups" and "key_share" in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2015 13:52:39 -0000 --047d7bd6bf1c371414052571e337 Content-Type: text/plain; charset=UTF-8 Hi, Per the latest draft of TLS 1.3, both "supported_groups" and "key_share" extensions are REQUIRED for DHE or ECDHE cipher suites (Section 8.2). Both extension need to provide the supported named groups in preference order. Looks like the functions are overlapped. I was wondering, it may be nice to obsolete the "supported_groups" extension, and use "key_share" extension for both the supported named groups and the key exchange information for each group. For the "supported_groups" extension, the description is (Section 6.3.2.2): --------------- Clients which offer one or more (EC)DHE cipher suites MUST send at least one supported NamedGroup value and servers MUST NOT negotiate any of these cipher suites unless a supported value was provided. If this extension is not provided and no alternative cipher suite is available, the server MUST close the connection with a fatal "missing_extension" alert. (see Section 8.2) If the extension is provided, but no compatible group is offered, the server MUST NOT negotiate a cipher suite of the relevant type. For instance, if a client supplies only ECDHE groups, the server MUST NOT negotiate finite field Diffie-Hellman. If no acceptable group can be selected across all cipher suites, then the server MUST generate a fatal "handshake_failure" alert. --------------- For the "key_share" extension, the description is (Section 6.3.2.3): --------------- Clients which offer one or more (EC)DHE cipher suites MUST send at least one supported KeyShare value and servers MUST NOT negotiate any of these cipher suites unless a supported value was provided. If this extension is not provided in a ServerHello or retried ClientHello, and the peer is offering (EC)DHE cipher suites, then the endpoint MUST close the connection with a fatal "missing_extension" alert. --------------- The "supported_groups" extension defines the groups, while the "key_share" extension defines both the groups and the key exchange information. Both extension has its own preferences for the supported named groups. It's easy to get conflicted if the two preferences are not consistent. The "key_share" extension contains the information of the supported named groups. So, the information can be used to indicate the client supported named groups. Maybe, for TLS 1.3, it is not necessary to use the "supported_groups" extension any more. Cheers, Xuelei --047d7bd6bf1c371414052571e337 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Per the latest draft of TLS 1.3, bo= th "supported_groups" and "key_share" extensions are RE= QUIRED for DHE or ECDHE cipher suites (Section 8.2).=C2=A0 Both extension n= eed to provide the supported named groups in preference order.=C2=A0 Looks = like the functions are overlapped.=C2=A0 I was wondering, it may be nice to= obsolete the "supported_groups" extension, and use "key_sha= re" extension for both the supported named groups and the key exchange= information for each group.

For the "support= ed_groups" extension, the description is (Section 6.3.2.2):
= =C2=A0 =C2=A0---------------
=C2=A0 =C2=A0Clients which offer one= or more (EC)DHE cipher suites MUST send at
=C2=A0 =C2=A0least on= e supported NamedGroup value and servers MUST NOT negotiate
=C2= =A0 =C2=A0any of these cipher suites unless a supported value was provided.= =C2=A0 If
=C2=A0 =C2=A0this extension is not provided and no alte= rnative cipher suite is
=C2=A0 =C2=A0available, the server MUST c= lose the connection with a fatal
=C2=A0 =C2=A0"missing_exten= sion" alert. =C2=A0(see Section 8.2) If the extension is
=C2= =A0 =C2=A0provided, but no compatible group is offered, the server MUST NOT=
=C2=A0 =C2=A0negotiate a cipher suite of the relevant type.=C2= =A0 For instance, if a
=C2=A0 =C2=A0client supplies only ECDHE gr= oups, the server MUST NOT negotiate
=C2=A0 =C2=A0finite field Dif= fie-Hellman.=C2=A0 If no acceptable group can be selected
=C2=A0 = =C2=A0across all cipher suites, then the server MUST generate a fatal
=
=C2=A0 =C2=A0"handshake_failure" alert.
=C2=A0 =C2= =A0---------------

For the "key_share&quo= t; extension, the description is (Section 6.3.2.3):
=C2=A0 =C2=A0= ---------------
=C2=A0 =C2=A0Clients which offer one or more= (EC)DHE cipher suites MUST send at
=C2=A0 =C2=A0least one suppor= ted KeyShare value and servers MUST NOT negotiate any
=C2=A0 =C2= =A0of these cipher suites unless a supported value was provided.=C2=A0 If
=C2=A0 =C2=A0this extension is not provided in a ServerHello or re= tried
=C2=A0 =C2=A0ClientHello, and the peer is offering (EC)DHE = cipher suites, then the
=C2=A0 =C2=A0endpoint MUST close the conn= ection with a fatal "missing_extension"
=C2=A0 =C2=A0al= ert.
=C2=A0 =C2=A0---------------

= The "supported_groups" extension defines the groups, while the &q= uot;key_share" extension defines both the groups and the key exchange = information.=C2=A0 Both extension has its own preferences for the supported= named groups.=C2=A0 It's easy to get conflicted if the two preferences= are not consistent.=C2=A0 The "key_share" extension contains the= information of the supported named groups.=C2=A0 So, the information can b= e used to indicate the client supported named groups.=C2=A0 Maybe, for TLS = 1.3, it is not necessary to use the "supported_groups" extension = any more.

Cheers,
Xuelei
--047d7bd6bf1c371414052571e337-- From nobody Thu Nov 26 06:26: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 423871B3A35 for ; Thu, 26 Nov 2015 06:26:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 JTEShd5NYMdg for ; Thu, 26 Nov 2015 06:26:46 -0800 (PST) Received: from filtteri2.pp.htv.fi (filtteri2.pp.htv.fi [213.243.153.185]) by ietfa.amsl.com (Postfix) with ESMTP id 15F9E1B3A34 for ; Thu, 26 Nov 2015 06:26:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by filtteri2.pp.htv.fi (Postfix) with ESMTP id 7233919BF49; Thu, 26 Nov 2015 16:26:44 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from smtp5.welho.com ([213.243.153.39]) by localhost (filtteri2.pp.htv.fi [213.243.153.185]) (amavisd-new, port 10024) with ESMTP id UrGKXGfnozHF; Thu, 26 Nov 2015 16:26:33 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp5.welho.com (Postfix) with ESMTPSA id A37ED5BC005; Thu, 26 Nov 2015 16:26:33 +0200 (EET) Date: Thu, 26 Nov 2015 16:26:32 +0200 From: Ilari Liusvaara To: Xuelei Fan Message-ID: <20151126142632.GA3582@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Extensions "supported_groups" and "key_share" in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2015 14:26:48 -0000 On Thu, Nov 26, 2015 at 09:52:37PM +0800, Xuelei Fan wrote: > Hi, > > Per the latest draft of TLS 1.3, both "supported_groups" and "key_share" > extensions are REQUIRED for DHE or ECDHE cipher suites (Section 8.2). Both > extension need to provide the supported named groups in preference order. > Looks like the functions are overlapped. I was wondering, it may be nice > to obsolete the "supported_groups" extension, and use "key_share" extension > for both the supported named groups and the key exchange information for > each group. This wouldn't work if one had to downnegotiate TLS 1.2. That is going to happen A LOT. Also, one can support curve, but not prefer to send share on it (the server can call for it, at cost of extra RTT). Plus, some of the curves are of special purpose and won't ever have shares. Also, IIRC, if client has no shares, it omits key_share. If server wants FS cipher suite, it then has to signal retry. > The "supported_groups" extension defines the groups, while the "key_share" > extension defines both the groups and the key exchange information. Both > extension has its own preferences for the supported named groups. It's > easy to get conflicted if the two preferences are not consistent. The > "key_share" extension contains the information of the supported named > groups. So, the information can be used to indicate the client supported > named groups. Maybe, for TLS 1.3, it is not necessary to use the > "supported_groups" extension any more. The only way to be conflicted would be to send key share for group not in supported_groups. Sending supported_group for group not in key_shares is not a conflict[1]. [1] In fact, I expect many clients to send shares for P-256 and X25519, plus offer P-384 and X448 (without shares unless requested). -Ilari From nobody Thu Nov 26 07:37:19 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0391B3B55 for ; Thu, 26 Nov 2015 07:37:15 -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, 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 qm5k851wPZri for ; Thu, 26 Nov 2015 07:37:13 -0800 (PST) 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 59EE61B3B4F for ; Thu, 26 Nov 2015 07:37:13 -0800 (PST) Received: by obdgf3 with SMTP id gf3so65711496obd.3 for ; Thu, 26 Nov 2015 07:37:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vimino-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LqLFaGikE2sPdv2DevgwmAUdPb1Kmsu3/Y2aCvTPDdM=; b=B/enZQgz4ZNpJe3Xz8XmaJgRNa3f65OYNUsopQ9ROP9+/OBX704tq7QDiTX6DyAPg1 zlHvX9BOLpX3wa7w3daKt2hyyZUbDFl5LV8iVG/Ls6UD8kVw4IhPKBVw0MeadhH3Sd6d aTVp6QWAbwSclhmMDFdanLnaGRI2C8Ys8oQEgWpQySe997VW+jKMXmkZphUeb+XVybs9 TwArUtxD4H5q4EjgMNrfY3e4B/1RTwzhLJlqxt3i1wsnAvNkylrN5uwdEcFYWPH2K48M iKBcsaJ6csEBVZoeMtqdkjGivZ+fNZCvf5LzdEr4vXIMylxMpK3oPnx37iBJS1e8y0rH 3Ngw== 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=LqLFaGikE2sPdv2DevgwmAUdPb1Kmsu3/Y2aCvTPDdM=; b=gme/mbWlkiuhrx8fS5+7Q7gHa30/kjRsps0vHqcTdh9RuUMZWJComzMzG/ifCMamlZ zWzJnAtGHENmKPRgSmrT51Y+AFnScXJ8wYf+/cV2VOr9Sb0KSSeRFU754Ehvuqu7iouM OEYy9fxkv5ZmDYwySImNfVELoAO/0cxjSA+cS0W6slb1cmeK9TE+bqPJOC+WFZ8IBscw ZlRzXzbZrw6qBo9ejPDj7i9TBBUdJf1/hdVelBJRjRw87ItWt9WKTtIC5HgE5A1lP6X5 baOAdP6oYIyEcgF2bWSKdvXS5Lv6ts3IyQQEo+BBIBxHvT4m/jZ4eWRouE3JX5ueFWzs USzg== X-Gm-Message-State: ALoCoQkfI+Tyss6dp85teOY+rqHTo6nfzTsj8ICKlPWXOS/Z0Byq+tXuwBd1WYmbtICZzIeR6Eg6 MIME-Version: 1.0 X-Received: by 10.182.81.162 with SMTP id b2mr28589003oby.7.1448552232770; Thu, 26 Nov 2015 07:37:12 -0800 (PST) Received: by 10.76.171.103 with HTTP; Thu, 26 Nov 2015 07:37:12 -0800 (PST) X-Originating-IP: [148.87.19.222] In-Reply-To: <20151126142632.GA3582@LK-Perkele-V2.elisa-laajakaista.fi> References: <20151126142632.GA3582@LK-Perkele-V2.elisa-laajakaista.fi> Date: Thu, 26 Nov 2015 23:37:12 +0800 Message-ID: From: Xuelei Fan To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=047d7b2e49f046083605257359bc Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Extensions "supported_groups" and "key_share" in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2015 15:37:15 -0000 --047d7b2e49f046083605257359bc Content-Type: text/plain; charset=UTF-8 Thanks for the quick feedback. You answered some questions puzzled me for a while. On Thu, Nov 26, 2015 at 10:26 PM, Ilari Liusvaara wrote: > On Thu, Nov 26, 2015 at 09:52:37PM +0800, Xuelei Fan wrote: > > Hi, > > > > Per the latest draft of TLS 1.3, both "supported_groups" and "key_share" > > extensions are REQUIRED for DHE or ECDHE cipher suites (Section 8.2). > Both > > extension need to provide the supported named groups in preference order. > > Looks like the functions are overlapped. I was wondering, it may be nice > > to obsolete the "supported_groups" extension, and use "key_share" > extension > > for both the supported named groups and the key exchange information for > > each group. > > This wouldn't work if one had to downnegotiate TLS 1.2. That is going to > happen A LOT. > > I think, "supported_groups" extension still can be sent for TLS 1.2, but can be ignored for TLS 1.3. And "key_share" extension can be extended to support TLS 1.2 and previous versions. > Also, one can support curve, but not prefer to send share on it (the > server can call for it, at cost of extra RTT). > > The scenarios may be not effective because of the extra RTT. As if the client want to negotiate the curve, it may be more effective to provide the key information in the beginning. Or, maybe the generation of the key exchange information is more expensive? > Plus, some of the curves are of special purpose and won't ever have > shares. > > I missed this point. Is it possible to update the shares to tolerate the special purpose? For example, allowing empty shares. > Also, IIRC, if client has no shares, it omits key_share. If server wants > FS cipher suite, it then has to signal retry. > > That's may be the point I missed, too. Where and when the shares come from? Looks like there are two cases: 1. client generate the shares and wrap them in the initial ClientHello message. 2. client omits the key_share, but still request for (EC)DHE cipher suites. If server want to negotiate (EC)DHE cipher suite, need an extra RTT. Client generate the shares on server request. I think the cases answer my confusing of the two extensions. Suppose, if the shares can be optional, maybe it is easier to use key_share only. If client has no shares, using key_share with no shares (function as supported_groups); if client has shares, using key_share with shares. > > The "supported_groups" extension defines the groups, while the > "key_share" > > extension defines both the groups and the key exchange information. Both > > extension has its own preferences for the supported named groups. It's > > easy to get conflicted if the two preferences are not consistent. The > > "key_share" extension contains the information of the supported named > > groups. So, the information can be used to indicate the client supported > > named groups. Maybe, for TLS 1.3, it is not necessary to use the > > "supported_groups" extension any more. > > The only way to be conflicted would be to send key share for group not in > supported_groups. Sending supported_group for group not in key_shares is > not a conflict[1]. > > The preferences may be not consistent, too. For example, the supported_groups prefer ffdhe2048, but the key_share prefer ffdhe4096. Using two preferences would make the implementation inconsistent between vendors if no clearly specification about the preference of the two. > [1] In fact, I expect many clients to send shares for P-256 and X25519, > plus offer P-384 and X448 (without shares unless requested). > > > I like this scenarios more. It might be more clear if TLS 1.3 support this scenarios, but not the scenarios that sending shares before requested. For the TLS vendors, client implementation may only consider one option. While a server implementation need to consider both, the effort doubles. Thanks, Xuelei > -Ilari > --047d7b2e49f046083605257359bc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Than= ks for the quick feedback.=C2=A0 You answered some questions puzzled me for= a while.

On Thu, Nov 26, 2015 at 10:26 PM, Ilari Liusvaara <= ;ilariliusvaa= ra@welho.com> wrote:
On = Thu, Nov 26, 2015 at 09:52:37PM +0800, Xuelei Fan wrote:
> Hi,
>
> Per the latest draft of TLS 1.3, both "supported_groups" and= "key_share"
> extensions are REQUIRED for DHE or ECDHE cipher suites (Section 8.2).= =C2=A0 Both
> extension need to provide the supported named groups in preference ord= er.
> Looks like the functions are overlapped.=C2=A0 I was wondering, it may= be nice
> to obsolete the "supported_groups" extension, and use "= key_share" extension
> for both the supported named groups and the key exchange information f= or
> each group.

This wouldn't work if one had to downnegotiate TLS 1.2. That is = going to
happen A LOT.

I think, "supported_groups" extension still= can be sent for TLS 1.2, but can be ignored for TLS 1.3.=C2=A0 And "k= ey_share" extension can be extended to support TLS 1.2 and previous ve= rsions.
=C2=A0
Also, one can support curve, but not prefer to send share on it (the
server can call for it, at cost of extra RTT).

The scenarios may be not effective because of the ext= ra RTT.=C2=A0 As if the client want to negotiate the curve, it may be more = effective to provide the key information in the beginning.=C2=A0 Or, maybe = the generation of the key exchange information is more expensive?
=C2=A0
Plus, some of the curves are of special purpose and won't ever have
shares.

I missed this point.=C2=A0 Is it possible to update t= he shares to tolerate the special purpose?=C2=A0 For example, allowing empt= y shares.
=C2=A0
Also, IIRC, if client has no shares, it omits key_share. If server wants FS cipher suite, it then has to signal retry.

That's may be the point I= missed, too.=C2=A0 Where and when the shares come from?=C2=A0 Looks like t= here are two cases:
1. client generate the shares and wrap them i= n the initial ClientHello message.
2. client omits the key_share,= but still request for (EC)DHE cipher suites. If server want to negotiate (= EC)DHE cipher suite, need an extra RTT.=C2=A0 Client generate the shares on= server request.

I think the cases answer my confu= sing of the two extensions.=C2=A0 Suppose, if the shares can be optional, m= aybe it is easier to use key_share only.=C2=A0 If client has no shares, usi= ng key_share with no shares (function as supported_groups); if client has s= hares, using key_share with shares.
=C2=A0
= > The "supported_groups" extension defines the groups, while t= he "key_share"
> extension defines both the groups and the key exchange information.=C2= =A0 Both
> extension has its own preferences for the supported named groups.=C2= =A0 It's
> easy to get conflicted if the two preferences are not consistent.=C2= =A0 The
> "key_share" extension contains the information of the suppor= ted named
> groups.=C2=A0 So, the information can be used to indicate the client s= upported
> named groups.=C2=A0 Maybe, for TLS 1.3, it is not necessary to use the=
> "supported_groups" extension any more.

The only way to be conflicted would be to send key share for group n= ot in
supported_groups. Sending supported_group for group not in key_shares is not a conflict[1].

The preferences may be not consistent, too.=C2=A0 For= example, the supported_groups prefer ffdhe2048, but the key_share prefer f= fdhe4096.=C2=A0 Using two preferences would make the implementation inconsi= stent between vendors if no clearly specification about the preference of t= he two.


[1] In fact, I expect many clients to send shares for P-256 and X25519,
plus offer P-384 and X448 (without shares unless requested).


I like this=C2=A0scenarios=C2=A0more.= =C2=A0 It might be more clear if TLS 1.3 support this scenarios, but not th= e scenarios that sending shares before requested.=C2=A0 For the TLS vendors= , client implementation may only consider one option. While a server implem= entation need to consider both, the effort doubles.

Thanks,
Xuelei
=C2=A0
-Ilari

--047d7b2e49f046083605257359bc-- From nobody Thu Nov 26 11: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 01CFE1A8AC4 for ; Thu, 26 Nov 2015 11:15:31 -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 CJ5fmlqI1wyQ for ; Thu, 26 Nov 2015 11:15:28 -0800 (PST) Received: from filtteri6.pp.htv.fi (filtteri6.pp.htv.fi [213.243.153.189]) by ietfa.amsl.com (Postfix) with ESMTP id 280C81A8AC3 for ; Thu, 26 Nov 2015 11:15:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by filtteri6.pp.htv.fi (Postfix) with ESMTP id A647E56F7C4; Thu, 26 Nov 2015 21:15:26 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from smtp5.welho.com ([213.243.153.39]) by localhost (filtteri6.pp.htv.fi [213.243.153.189]) (amavisd-new, port 10024) with ESMTP id ocKmbEkMnrnK; Thu, 26 Nov 2015 21:15:26 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp5.welho.com (Postfix) with ESMTPSA id 62E855BC005; Thu, 26 Nov 2015 21:15:26 +0200 (EET) Date: Thu, 26 Nov 2015 21:15:25 +0200 From: Ilari Liusvaara To: Xuelei Fan Message-ID: <20151126191525.GB3728@LK-Perkele-V2.elisa-laajakaista.fi> References: <20151126142632.GA3582@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Extensions "supported_groups" and "key_share" in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2015 19:15:31 -0000 On Thu, Nov 26, 2015 at 11:37:12PM +0800, Xuelei Fan wrote: > > This wouldn't work if one had to downnegotiate TLS 1.2. That is going to > > happen A LOT. > > > > I think, "supported_groups" extension still can be sent for TLS 1.2, but > can be ignored for TLS 1.3. And "key_share" extension can be extended to > support TLS 1.2 and previous versions. Given the slowness even _security_ _fix_ extensions get deployed, planning any sort of transition is not IMO a good idea. > > Also, one can support curve, but not prefer to send share on it (the > > server can call for it, at cost of extra RTT). > > > The scenarios may be not effective because of the extra RTT. As if the > client want to negotiate the curve, it may be more effective to provide the > key information in the beginning. Or, maybe the generation of the key > exchange information is more expensive? Yes, generating key exchanges can be expensive (even if it is cheaper for each group then performing the actual key exchange). Especially for P-384, P-521 and larger DH groups. Also, the shares can get large if many are sent. "Xmas tree" client keyshare is 3384 bytes by quick calculation (whereas the one containing P-256 and X25519 is just 109). That's many times the rest of the ClientHello, and might already cause problems. Better plan might be to guess, as the cost of wrong guess is mostly just 1 RTT. > > Plus, some of the curves are of special purpose and won't ever have > > shares. > > > I missed this point. Is it possible to update the shares to tolerate the > special purpose? For example, allowing empty shares. The current grammar does not allow empty value, so it is free. But considering one needs supported_groups for backward compat., one can just rely on that to signal that group is supported but no share is given. > > > Also, IIRC, if client has no shares, it omits key_share. If server wants > > FS cipher suite, it then has to signal retry. > > > That's may be the point I missed, too. Where and when the shares come > from? Looks like there are two cases: > 1. client generate the shares and wrap them in the initial ClientHello > message. > 2. client omits the key_share, but still request for (EC)DHE cipher suites. > If server want to negotiate (EC)DHE cipher suite, need an extra RTT. > Client generate the shares on server request. I actually looked at the Editors's Copy. The description is a mess: It seemingly first requires key_share extension, even for the first ClientHello... Now, that extension can't be empty... And then proceeds to say to omit it if client has no shares to send... Which looks like it is mutually contradictionary. > I think the cases answer my confusing of the two extensions. Suppose, if > the shares can be optional, maybe it is easier to use key_share only. If > client has no shares, using key_share with no shares (function as > supported_groups); if client has shares, using key_share with shares. I think two extensions are needed for backward compatiblity: One needs to use supported_groups, but one can't extend it, so two extension it is. TLS 1.3 (without 0-RTT) is supposed to be possible to downnegotiate at least to TLS 1.2. > > > The "supported_groups" extension defines the groups, while the > > "key_share" > > > extension defines both the groups and the key exchange information. Both > > > extension has its own preferences for the supported named groups. It's > > > easy to get conflicted if the two preferences are not consistent. The > > > "key_share" extension contains the information of the supported named > > > groups. So, the information can be used to indicate the client supported > > > named groups. Maybe, for TLS 1.3, it is not necessary to use the > > > "supported_groups" extension any more. > > > > The only way to be conflicted would be to send key share for group not in > > supported_groups. Sending supported_group for group not in key_shares is > > not a conflict[1]. > > > The preferences may be not consistent, too. For example, the > supported_groups prefer ffdhe2048, but the key_share prefer ffdhe4096. > Using two preferences would make the implementation inconsistent between > vendors if no clearly specification about the preference of the two. Only supported_groups are perference-ordered. Key_shares is unordered, with special exception for retry (the added group always goes last). > > [1] In fact, I expect many clients to send shares for P-256 and X25519, > > plus offer P-384 and X448 (without shares unless requested). > > > > > I like this scenarios more. It might be more clear if TLS 1.3 support > this scenarios, but not the scenarios that sending shares before > requested. For the TLS vendors, client implementation may only consider > one option. While a server implementation need to consider both, the effort > doubles. Basically, with some groups, sending on request is the only workable option, given how slow or large some shares are. Now, if PQ key exchanges were added, things would get worse, because those methods tend to either have large keys or slow key exchange/ generation. -Ilari From nobody Thu Nov 26 14:50: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 814201ACEF6 for ; Thu, 26 Nov 2015 14:50:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hchhxGk1NVVq for ; Thu, 26 Nov 2015 14:50:14 -0800 (PST) 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 18BA41AD082 for ; Thu, 26 Nov 2015 14:50:14 -0800 (PST) Received: by qgec40 with SMTP id c40so62453869qge.2 for ; Thu, 26 Nov 2015 14:50:13 -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=SAG1dpvdOdSQTRuO1M5y+yOFD95ONDhQ2OVbr6m4YEk=; b=I+q5VGHsbTIXDTk1Rhrcsza9p6/KohvE1czES6pYFpcMTXn+yUl55yq2DllNzEOHwe uLdi+VThV9HRsvrB/nloGhH4JwmVC8IoUKItdlx+ykR5ycx0J5o87xCpB2vFDNQ7hwn0 TFvBdtauM28g9TNJey6Q6W29vyrI/Iq2Ct0Jihsk7Xy9Xfe7+GFS7C1s6xp9P9zzxD1O 7QG9Xbv86Ey+HQ4rM5usVVdxh8tpMJiE6tuSlR71d6ypMbC0KVucZXmP11eoYOPEnuK2 FC23I68lzdBlO3peXgJkJ4FZiW/26gWKG6gNfot5FqJiInhnqv82FkZzL4O6K4OJQ6rt 5CEw== X-Received: by 10.140.239.87 with SMTP id k84mr54271445qhc.87.1448578213284; Thu, 26 Nov 2015 14:50:13 -0800 (PST) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id t18sm8141860qkt.26.2015.11.26.14.50.12 (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 26 Nov 2015 14:50:12 -0800 (PST) From: Dave Garrett To: Ilari Liusvaara , Eric Rescorla Date: Thu, 26 Nov 2015 17:50:11 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20151126191525.GB3728@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20151126191525.GB3728@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201511261750.11459.davemgarrett@gmail.com> Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Extensions "supported_groups" and "key_share" in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2015 22:50:15 -0000 On Thursday, November 26, 2015 02:15:25 pm Ilari Liusvaara wrote: > I actually looked at the Editors's Copy. The description is a mess: It > seemingly first requires key_share extension, even for the first > ClientHello... Now, that extension can't be empty... And then proceeds > to say to omit it if client has no shares to send... Which looks like > it is mutually contradictionary. We went back and forth on whether to omit or require an empty extension. It looks like we have a mix of the two left in there that need fixing. (I think something got merged weird) Thanks for pointing this out. I think it might be easier if we just required the extension for all cases where (EC)DHE suites are offered, and have it empty to request a server choice, instead of an omitted extension. If I remember correctly, that's what I had originally. One way or another, it needs to be fixed to be consistent. Dave From nobody Thu Nov 26 15:02: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 EBCC01B2C96 for ; Thu, 26 Nov 2015 15:02:50 -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, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jMoBnN5Di49v for ; Thu, 26 Nov 2015 15:02:49 -0800 (PST) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91A541B2C87 for ; Thu, 26 Nov 2015 15:02:49 -0800 (PST) Received: by ykba77 with SMTP id a77so101865441ykb.2 for ; Thu, 26 Nov 2015 15:02:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ePJ2xJ+46Z8a5o0P79xgszvlEMra8CRiJSlPe7l1l/4=; b=rxuxIakospZKKAVVlzEFKpVKnl1a2cYF7dZvIZnRv37o9M01F6Us2UVBYfjeqmsXN+ 2JIwlmhSBlIh2xiPTYk0vdmjCKZP9b2erMfXJSjy9ZBKQzummrtyq1VfQc/NuGRgRxbN c2SuGvLj0qwxCWbkeThT+ZP7J61dk6OTNGTVVEZVQMT4q7BC/rKG0WU35P2a5+3LKS04 XXL6EWAgaeJpppXPRF5svk7ryS0/2NJ+OSJPNcP2K336mCnvja+qGL1+kdpPD5/bts8B jefunX2nc2DNdroaZLwaMxedj9SyLh1gdFnHEklQeKG/CWwI+Xwhrmn/a6bhEfk49gaE HR0w== 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=ePJ2xJ+46Z8a5o0P79xgszvlEMra8CRiJSlPe7l1l/4=; b=JeF/PkgkDL08R99X/9p/EGmcRwCIF2ECy8230KI7nI01chPOnzRBQwgbTmiSLWB6IO HBPxNzsS1sjWIp/geWbHOV1RWbjBZ2BecY5iJxAQyrOk4wyQ00DhzqBTXkA0d68p08oR N3fYIGHaBcp+iNtkEb6v0wuUZFv8cZ7qfBIW51IYAx2UTeAQ3hggC2F++4JF23Ees/vv 94UFJ/2v1k8G+ZVxyy4mVhEFfoR/Cy4mgqQcvU/x+5oomAiW45jS5f38eQLM0CwKk7NZ 9Z5HmSnrf27MLePJkWPg1ypxhMdL7/0swWvUpw9PC3loglI7vnt8gN//ZaHUwKn9iQ2C VgwQ== X-Gm-Message-State: ALoCoQk7xdVkFCTOzs+c/1WnGGi9OhtZkO//uVOj5TPpYfNM8KA3iVg3bSYBhaeyz4fvvyOqQXAs X-Received: by 10.13.197.194 with SMTP id h185mr38760696ywd.12.1448578968863; Thu, 26 Nov 2015 15:02:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Thu, 26 Nov 2015 15:02:09 -0800 (PST) In-Reply-To: <201511261750.11459.davemgarrett@gmail.com> References: <20151126191525.GB3728@LK-Perkele-V2.elisa-laajakaista.fi> <201511261750.11459.davemgarrett@gmail.com> From: Eric Rescorla Date: Thu, 26 Nov 2015 15:02:09 -0800 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=001a114edd4ade747a05257992f9 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Extensions "supported_groups" and "key_share" in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2015 23:02:51 -0000 --001a114edd4ade747a05257992f9 Content-Type: text/plain; charset=UTF-8 On Thu, Nov 26, 2015 at 2:50 PM, Dave Garrett wrote: > On Thursday, November 26, 2015 02:15:25 pm Ilari Liusvaara wrote: > > I actually looked at the Editors's Copy. The description is a mess: It > > seemingly first requires key_share extension, even for the first > > ClientHello... Now, that extension can't be empty... And then proceeds > > to say to omit it if client has no shares to send... Which looks like > > it is mutually contradictionary. > > We went back and forth on whether to omit or require an empty extension. > It looks like we have a mix of the two left in there that need fixing. (I > think something got merged weird) Thanks for pointing this out. > > I think it might be easier if we just required the extension for all cases > where (EC)DHE suites are offered, and have it empty to request a server > choice, instead of an omitted extension. Yes, we should either have that or have empty be forbidden. It's a matter of taste but on balance, let's go with "empty". If you want to submit a PR that cleans this up, I'll merge that. -Ekr If I remember correctly, that's what I had originally. One way or another, > it needs to be fixed to be consistent. > > > Dave > --001a114edd4ade747a05257992f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Nov 26, 2015 at 2:50 PM, Dave Garrett <davemgarrett@gmail= .com> wrote:
On Thursday, November 26, 2015 02:15:25 pm Ilari Liusvaara wrote:
> I actually looked at the Editors's Copy. The description is a mess= : It
> seemingly first requires key_share extension, even for the first
> ClientHello... Now, that extension can't be empty... And then proc= eeds
> to say to omit it if client has no shares to send... Which looks like<= br> > it is mutually contradictionary.

We went back and forth on whether to omit or require an empty extens= ion. It looks like we have a mix of the two left in there that need fixing.= (I think something got merged weird) Thanks for pointing this out.

I think it might be easier if we just required the extension for all cases = where (EC)DHE suites are offered, and have it empty to request a server cho= ice, instead of an omitted extension.

Yes, = we should either have that or have empty be forbidden. It's a matter of= taste
but on balance, let's go with "empty". If yo= u want to submit a PR that cleans
this up, I'll merge that.

-Ekr

If I remember correctly, that's what I had originally. One way or= another, it needs to be fixed to be consistent.


Dave

--001a114edd4ade747a05257992f9-- From nobody Thu Nov 26 15:03: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 0453F1B2C5D for ; Thu, 26 Nov 2015 15:03:34 -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 jZCvoGk3Qnow for ; Thu, 26 Nov 2015 15:03:32 -0800 (PST) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABC851B2CBE for ; Thu, 26 Nov 2015 15:03:32 -0800 (PST) Received: by qgec40 with SMTP id c40so62603030qge.2 for ; Thu, 26 Nov 2015 15:03:31 -0800 (PST) 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=n4kVqvtKkD3MKUwSdnPRnt4l8aB4Fh98jU5IF35cAa4=; b=KrVQ8bwdxUU0g6bsf4/1WsST0QJZ20gvwQehWvmtyQUGevWwparMyFcJfJ/CWr7e8f vNqOpEREVAvnxF6nXTvKhTe0mXAjYSg43UMA6wVqOesqRpxAymzmWJwp3jUc5HUY8Vg6 4RdkOuuJOMkPH2P1p7XibU/jjySWoRR4BzG0+nwo5Ryyytr1naTYz/81U9aXgFFuRQyw DZnIRm5I5fGnlqXcg0gpFOO2wyBPrFr07IxEfyX6QeqAWyniNyhouvNKPktBiZVNJG2S KJaMd/e/bOQni+aj6C16yo8XypK6mQmkla4/04lvWQow+aBO6xY0qOQzlZJBh5IDFj/I 6Dug== X-Received: by 10.140.94.243 with SMTP id g106mr50563652qge.57.1448579011845; Thu, 26 Nov 2015 15:03:31 -0800 (PST) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id h11sm4236726qge.43.2015.11.26.15.03.31 (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 26 Nov 2015 15:03:31 -0800 (PST) From: Dave Garrett To: tls@ietf.org, Eric Rescorla Date: Thu, 26 Nov 2015 18:03:30 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201511261803.30599.davemgarrett@gmail.com> Archived-At: Subject: [TLS] Replacing HelloRetryRequest in TLS 1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2015 23:03:34 -0000 HelloRetryRequest is annoying. Is there any way we can replace it with something? I know our options are limited, here. We can't mandate offers for everything, not just due to constrained environments, but also because post-quantum keys could get too big. The main thing that comes to mind would be to provide a way for a server to respond to a client with a ServerConfiguration, but not a hello, and put group support in there (maybe a whole supported_groups extension). Clients that don't provide the needed key would get a config and a fatal alert telling it that it needs to use a supported group from that config. The client could then retry as it does now or do 0-RTT with early data, which could cut an RTT out of the current flow. (This is similar to the QUIC way of doing things.) Dave From nobody Thu Nov 26 15:16: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 0F6B51B2C62 for ; Thu, 26 Nov 2015 15:16:07 -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, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0otP72j85Oow for ; Thu, 26 Nov 2015 15:16:06 -0800 (PST) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C89191B2BBC for ; Thu, 26 Nov 2015 15:16:05 -0800 (PST) Received: by ykdr82 with SMTP id r82so101942394ykd.3 for ; Thu, 26 Nov 2015 15:16:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=fw22l1jDXAPXoGmPK4hMF2jN3kB5DarpZpz/RnW5OgI=; b=rnwfMQvE427XnoHbnybq0+RU5ZIAhsOeJbbyw5VGvOR6mkxZ4m+Kyt5C7e9iwydidj eSnwxrbklYR6fEh7qkB0xYpI40dt2rn1Rc7CzNEUs8fILn+cyZSSHyq2d4goE6Z0vqZW h+xcxzjviiNM9wAqbjQIbDRv14sxfLHyhoPRoXyzuueyEOQoCiCZCJtmvPR/voefa9Fp /z28mdz+JFbwlcrPSi7wuNB8pTK5J++Cbi7/qxuwo4ZBLOoz6MRQlt8+Q7HWg67ff9Ur B/mGrwUS6YZU1dVfy9sszEdNSBexaWUY27uovcZjkLfRNhoznuZ+GFZozc/umZwc7ETM DE0w== 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=fw22l1jDXAPXoGmPK4hMF2jN3kB5DarpZpz/RnW5OgI=; b=TEiMhctUace3evYPaXcLtojK4eFfnMEdTtU4fVgDcu+jaAalC7zl103z12JvH6KVMd EG6n1Vn80UtEpJL2HY70KKR+B99XqqzRkkWCqBH+Nt+W62GiW8XGVsB4vyqiBwXu7mkG gvadqg5omz8JOWBN7mubDyYrepsSIAT9EHlYdSeVFgPSB6SjHA97w2TPg/0zMuDPYNyC WooerZNQrADzEb8mUPTbtey+lwlAXAGsVv5zt5U5lT73Y596vK15R/cfmMnE/UuwAWy/ 4h6EgaAjg1NM5IPkTadpgYWb94VwzKdtUvmGP4U6xAnftMn4qOIUyqurzMrWznNSFhP3 SZBQ== X-Gm-Message-State: ALoCoQnMBHvqlgIPr2FBi7fA5dLNHlKYtu8ebkuUYc7mf8A2dMEuxLejMjHkoRAS41x+HOQCOQ+1 X-Received: by 10.129.46.84 with SMTP id u81mr2863261ywu.129.1448579765163; Thu, 26 Nov 2015 15:16:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Thu, 26 Nov 2015 15:15:25 -0800 (PST) In-Reply-To: <201511261803.30599.davemgarrett@gmail.com> References: <201511261803.30599.davemgarrett@gmail.com> From: Eric Rescorla Date: Thu, 26 Nov 2015 15:15:25 -0800 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=001a11409380550978052579c22b Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Replacing HelloRetryRequest in TLS 1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2015 23:16:07 -0000 --001a11409380550978052579c22b Content-Type: text/plain; charset=UTF-8 On Thu, Nov 26, 2015 at 3:03 PM, Dave Garrett wrote: > HelloRetryRequest is annoying I guess this is a matter of opinion. The main thing that comes to mind would be to provide a way for a server to > respond to a client with a ServerConfiguration, but not a hello, and put > group support in there (maybe a whole supported_groups extension). Clients > that don't provide the needed key would get a config and a fatal alert > telling it that it needs to use a supported group from that config. The > client could then retry as it does now or do 0-RTT with early data, which > could cut an RTT out of the current flow. (This is similar to the QUIC way > of doing things.) The server could certainly tell the client what groups it supports, but given that the server already knows precisely what the client's capabilities are at this point, there's no good reason why it shouldn't simply tell the client what to do. This matches the usual TLS negotiation model. For obvious reasons, if the client is to send data in response to the server's first flight (as you suggest) it's going to have to have an authenticated public key. However, that public key will need to be authenticated via a signature, which means carrying the server's cert, which means that we're encrypting much less of the handshake. In addition, you either have to have a statically signed configuration (which we've already rejected for the general case) or the server has to perform an online signature, which means that the server has no defense against computational DoS attacks unless we introduce yet another cookie mechanism. For these reasons, I believe that the current design is superior. -Ekr > > Dave > --001a11409380550978052579c22b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Nov 26, 2015 at 3:03 PM, Dave Garrett <davemgarrett@gmail.com= > wrote:
HelloRetryRequest is a= nnoying

I guess this is a matter of opinion= .


The main thing that comes to mind would be to provide a way for a server to= respond to a client with a ServerConfiguration, but not a hello, and put g= roup support in there (maybe a whole supported_groups extension). Clients t= hat don't provide the needed key would get a config and a fatal alert t= elling it that it needs to use a supported group from that config. The clie= nt could then retry as it does now or do 0-RTT with early data, which could= cut an RTT out of the current flow. (This is similar to the QUIC way of do= ing things.)

The server could certainly tel= l the client what groups it supports, but given
that the server a= lready knows precisely what the client's capabilities are
at = this point, there's no good reason why it shouldn't simply tell the= client
what to do. This matches the usual TLS negotiation model.=

For obvious reasons, if the client is to send dat= a in response to the server's
first flight (as you suggest) = =C2=A0it's going to have to have an authenticated public key.
However, that public key will need to be authenticated via a signature, wh= ich
means carrying the server's cert, which means that we'= ;re encrypting much
less of the handshake. In addition, you eithe= r have to have a statically signed
configuration (which we've= already rejected for the general case) or the=C2=A0
server has t= o perform an online signature, which means that the server
has no= defense against computational DoS attacks unless we introduce
ye= t another cookie mechanism.

For these reasons, I b= elieve that the current design is superior.

-Ekr




Dave

--001a11409380550978052579c22b-- From nobody Thu Nov 26 15:18: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 61D371B2CEF for ; Thu, 26 Nov 2015 15:18:45 -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, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8WfhTp116Rq for ; Thu, 26 Nov 2015 15:18:44 -0800 (PST) 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 BD8D91B2CEC for ; Thu, 26 Nov 2015 15:18:43 -0800 (PST) Received: by ykba77 with SMTP id a77so102146283ykb.2 for ; Thu, 26 Nov 2015 15:18:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=NLugSFUGK1+pbZc4qG68ehT6AmPhpiK21kcMtqgNVfY=; b=OS32vTDwYDFm/QSCij7NS/s0O6pAyLdFYj8O1w9HJdD9yvSfAahhmkplNCfbJF5Pjm TOgOxYmTAQPbIdRtYUn3hMVrQtVjRa+0HLA3ppTTuhuMznfsSKgAqelMvMtOp1h8ff7K oBs547HFZtrvvhnnrteSDRnqp776KN4do5wwnDqrw+0EBDGxfXm5n/OSd7tm3E7S0dj/ 5EgOTUZG5YpghcoZTORG4kHwPG81f9uzgSd4LdZX0K1UKQvqocYp6zcqCG5bvB5JuNei ArO2tc/CoISnvD2Q1tqvC0vW+3ZT9okFjfwfPt/7/YfP02XzTfVTrpK8hYpKlsX7LYfW dtGQ== 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=NLugSFUGK1+pbZc4qG68ehT6AmPhpiK21kcMtqgNVfY=; b=HN3hXvUQk9Mrkqe8Cu33BAtxibeeWGNtvyB8WX89ljtYoZBz6ZGCudAUZPQgcBSvQg KqwqNvxFr8x3FDA5yJDvf3gyHH/oP+KBTUvSmwEnawbUx8BKeFdofg03u+mpB7xqt3L7 h873FWGenFwEWHQg9wRzuk7tSbaYyjIKtZOu/cbOf/qMWeQV/mwd3/h/2en3PiiXzbSb zYhzHHHTGUZJonjC2Va8kGjL4esnHYRp/+7ZFP+8pqTSA+2y8sd8OkIqYu03H6lPEfie vBdhRRYhNaPjDkXAugdGXkczuMuajDD2Cbtasy/1Ett5naBeJ2mm64Ql7Xa7fXmwdPvX xa0A== X-Gm-Message-State: ALoCoQkhdz7fRSCLKdv44VIRu44oG7t8g1HfQIAWznUJDrJj7QCReIXuRUFGDuFbKb2c0EA4KmV1 X-Received: by 10.13.236.10 with SMTP id v10mr44362934ywe.231.1448579923059; Thu, 26 Nov 2015 15:18:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Thu, 26 Nov 2015 15:18:03 -0800 (PST) In-Reply-To: References: <20151119150312.E8CDA1A383@ld9781.wdf.sap.corp> From: Eric Rescorla Date: Thu, 26 Nov 2015 15:18:03 -0800 Message-ID: To: Joseph Salowey Content-Type: multipart/alternative; boundary=94eb2c0889dcbe5800052579cbf7 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR#345: IANA Considerations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 23:18:45 -0000 --94eb2c0889dcbe5800052579cbf7 Content-Type: text/plain; charset=UTF-8 Joe, Can you clarify whether you believe consensus is to make the "Recommended" list the list in the current PR or the MTI list. I can edit the document either way. -Ekr On Wed, Nov 25, 2015 at 11:05 AM, Joseph Salowey wrote: > It looks like we have rough consensus to accept this PR. We can still have > discussion on the naming of the categories. We will also have to define > the IANA registration policy for changing the "recommended" bit. I'll > open an issue for this, I think changing the bit to recommended should > require IETF consensus. > > Cheers, > > Joe > > On Thu, Nov 19, 2015 at 7:10 AM, Eric Rescorla wrote: > >> >> >> On Thu, Nov 19, 2015 at 7:03 AM, Martin Rex wrote: >> >>> Eric Rescorla wrote: >>> > >>> > There are presently four categories of cipher suites vis-a-vis TLS 1.3. >>> > >>> > 1. MUST or SHOULD cipher suites. >>> > 2. Standards track cipher suites (or ones we are making ST, like >>> > the ECC ones). >>> > 3. Non standards track cipher suites >>> > 4. Cipher suites you can't use at all with TLS 1.3, like AES-CBC. >>> > >>> > I think we're all agreed that category #1 should be marked recommended >>> > and that #3 and #4 should not be. This leaves us with category #2, >>> which >>> > includes stuff like: >>> > >>> > - FFDHE >>> > - CCM >>> > >>> > My proposal is that we: >>> > >>> > - List all the Standards Track cipher suites that are compatible with >>> TLS >>> > 1.3 in Appendix A. >>> > - Mark all the cipher suites that are listed in Appendix A as >>> "Recommended" >>> >>> >>> I'm slightly confused. >>> >>> rfc5288 is standards track and describes AES-GCM with static RSA keyex. >>> >> >> This isn't compatible with TLS 1.3 because TLS 1.3 removes static RSA. >> >> >> rfc5289 is only informational (i.e. _not_ standards track) and describes >>> AES-GCM with ECDHE keyex. >> >> >> We are re-labelling the AES-GCM ECDHE suites as standards track either in >> this document or in RFC4492bis. >> >> -Ekr >> >> >>> >>> >>> >>> -Martin >>> >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> > --94eb2c0889dcbe5800052579cbf7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Joe,

Can you clarify whether you believ= e consensus is to make the "Recommended"
list the list = in the current PR or the MTI list. I can edit the document either
way.

-Ekr


On Wed, Nov 25, 2015 at 11:05 = AM, Joseph Salowey <joe@salowey.net> wrote:
It looks lik= e we have rough consensus to accept this PR. We can still have discussion o= n the naming of the categories.=C2=A0 We will also have to define the IANA = registration policy for changing the "recommended" bit. =C2=A0 I&= #39;ll open an issue for this, =C2=A0I think changing the bit to recommende= d should require IETF consensus. =C2=A0
=
Cheers,

Joe

On Thu, Nov = 19, 2015 at 7:10 AM, Eric Rescorla <ekr@rtfm.com> wrote:


On Thu, Nov 19, 20= 15 at 7:03 AM, Martin Rex <mrex@sap.com> wrote:
Eric Rescorla wrote:
>
> There are presently four categories of cipher suites vis-a-vis TLS 1.3= .
>
> 1. MUST or SHOULD cipher suites.
> 2. Standards track cipher suites (or ones we are making ST, like
>=C2=A0 =C2=A0 =C2=A0the ECC ones).
> 3. Non standards track cipher suites
> 4. Cipher suites you can't use at all with TLS 1.3, like AES-CBC.<= br> >
> I think we're all agreed that category #1 should be marked recomme= nded
> and that #3 and #4 should not be. This leaves us with category #2, whi= ch
> includes stuff like:
>
> - FFDHE
> - CCM
>
> My proposal is that we:
>
> - List all the Standards Track cipher suites that are compatible with = TLS
> 1.3 in Appendix A.
> - Mark all the cipher suites that are listed in Appendix A as "Re= commended"


I'm slightly confused.

rfc5288 is standards track and describes AES-GCM with static RSA keyex.
=

This isn't compatible with TLS = 1.3 because TLS 1.3 removes static RSA.


=
rfc5289 is only informational (i.e. _not_ standards track) and describes AES-GCM with ECDHE keyex.

We are re-= labelling the AES-GCM ECDHE suites as standards track either in this docume= nt or in RFC4492bis.

-Ekr
=C2=A0



-Martin


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



--94eb2c0889dcbe5800052579cbf7-- From nobody Thu Nov 26 15: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 932EB1B2E95 for ; Thu, 26 Nov 2015 15:36:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUMj9B6bz1vu for ; Thu, 26 Nov 2015 15:36:57 -0800 (PST) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E68671B2E8F for ; Thu, 26 Nov 2015 15:36:56 -0800 (PST) Received: by qgec40 with SMTP id c40so62969435qge.2 for ; Thu, 26 Nov 2015 15:36:56 -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=4F+vxkk0Aa2sM7ZdT2vNoK+xldTAotlOCbS/cyGIqb8=; b=eOjLl+BBQlVzqTbSG5Sn4EHoPF1HrDHkUgRaCZFkI2aFmat4c7ET+GSJQcVwNmx8YN L4/wREaXJ57cXFidFVol+wgU6nNqtF1PkMQ9oBs53pB327rCOxlAhYub4hNmqh/S0v+Y 76KtK8etgeWRceSwbrNHodigYFxF4FKN3vsXrW3H3jannwEjcGHMpcipbnxYxXbsYbWV qQeTOLY4L6I/TqFCcMwKeEY4xC619reMjwWwiSgLGLsQ0du5YC6orDNpT8MmC5kdE+oi DoE2saTqVu0sdt4t/JqJefaB9jzZV1vL6fgohT53/ob1/U44kN1Kst2l3mlPdxRzsyT8 +doQ== X-Received: by 10.140.155.75 with SMTP id b72mr50615396qhb.29.1448581016156; Thu, 26 Nov 2015 15:36:56 -0800 (PST) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id 6sm8186855qgf.34.2015.11.26.15.36.55 (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 26 Nov 2015 15:36:55 -0800 (PST) From: Dave Garrett To: Eric Rescorla Date: Thu, 26 Nov 2015 18:36:54 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201511261750.11459.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201511261836.54580.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Extensions "supported_groups" and "key_share" in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2015 23:36:58 -0000 On Thursday, November 26, 2015 06:02:09 pm Eric Rescorla wrote: > On Thu, Nov 26, 2015 at 2:50 PM, Dave Garrett > wrote: > > On Thursday, November 26, 2015 02:15:25 pm Ilari Liusvaara wrote: > > > I actually looked at the Editors's Copy. The description is a mess: It > > > seemingly first requires key_share extension, even for the first > > > ClientHello... Now, that extension can't be empty... And then proceeds > > > to say to omit it if client has no shares to send... Which looks like > > > it is mutually contradictionary. > > > > We went back and forth on whether to omit or require an empty extension. > > It looks like we have a mix of the two left in there that need fixing. (I > > think something got merged weird) Thanks for pointing this out. > > > > I think it might be easier if we just required the extension for all cases > > where (EC)DHE suites are offered, and have it empty to request a server > > choice, instead of an omitted extension. > > Yes, we should either have that or have empty be forbidden. It's a matter of taste > but on balance, let's go with "empty". If you want to submit a PR that cleans > this up, I'll merge that. -> https://github.com/tlswg/tls13-spec/pull/349 There's one last decision, though: does "empty" mean empty client_shares vector or empty "extension_data" to save 2 bytes? I think it's cleaner to just keep the same extension structure for all cases and have an empty shares vector, which is what I have in the current PR. Dave From nobody Thu Nov 26 15:48: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 F0C8B1B2EE8 for ; Thu, 26 Nov 2015 15:48:00 -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, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WGJ7z1xdC38 for ; Thu, 26 Nov 2015 15:47:59 -0800 (PST) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41F261B2EE6 for ; Thu, 26 Nov 2015 15:47:59 -0800 (PST) Received: by ykba77 with SMTP id a77so102602848ykb.2 for ; Thu, 26 Nov 2015 15:47:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=yLKA20FkLCOnrjlDzWpcSFS79FgNVSJDD2iimKgV0qU=; b=uGnumYFftkK/esYy8gj6OVI3F5dlcYRlxdiqOrjm7S8oqsWs0aMjfsFK4U8qvNoEoR 1ey4Jbbu+b+ryu6lqLhtSy97HX1co6c1k4vGHvcNx9v9Q85j899OsZBYYsf7FukTCUm0 g6fxrza/HaAXITyFs6H72VPyA4dar0Bf50emxUR3SUb5dhTgwwwdPPHl/8dQJu58QsjR MPaT/3+bvkulZvVOLvAlO7eeqBND0BF6L1JqMOH7oF1MwXwhBxlnzGLDlYwk8irRpSnR 1Y0JlIxySJm5BSmDjMxDGPUMOueXZbyPVh5cT6vedva0Si/Xz70bEzN1SmZtXpKoPh9V 6ATA== 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=yLKA20FkLCOnrjlDzWpcSFS79FgNVSJDD2iimKgV0qU=; b=WdBsNRXr8wVOJQfQMWymZxrS63YyBTzLPT74D8xZSfzSLjw3wIOP3RNB5YrBQFbzKB YUmFNSZbEwW1OZjdRsd0gvkvrVupCKK0UujNWDbvTyeT1ogHPq01t3R8cEDvZTefueii NtEm33oxKOfEZDr2pXZCd7gAhSDT/H1vfTffr0wVMqsmMYzCyF/HzEaCfk1c5uXooTwJ fgUZ6UQ2jLi3MJ0YVN0eesmlXzb4lre+QrfYqF2ssR/OB6GAOpEQ6t+yiZNpLbzXfuQm vwaB4ScjrR49xpQ6Ds8MSRnXszs/lnHdUaCpKnchYdSqWgxPckwnbNADXnYVJOvHfc6W JHwQ== X-Gm-Message-State: ALoCoQmLymJON08hzLuq8rt7LvBtqAUSyXTE7JE5YBAHVsoz1vIt1GAmjmtJxhbFb4krvnrXAm0z X-Received: by 10.13.212.211 with SMTP id w202mr8951661ywd.192.1448581678604; Thu, 26 Nov 2015 15:47:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Thu, 26 Nov 2015 15:47:19 -0800 (PST) In-Reply-To: <201511261836.54580.davemgarrett@gmail.com> References: <201511261750.11459.davemgarrett@gmail.com> <201511261836.54580.davemgarrett@gmail.com> From: Eric Rescorla Date: Thu, 26 Nov 2015 15:47:19 -0800 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=001a114fbe9861d3c505257a3441 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Extensions "supported_groups" and "key_share" in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2015 23:48:01 -0000 --001a114fbe9861d3c505257a3441 Content-Type: text/plain; charset=UTF-8 On Thu, Nov 26, 2015 at 3:36 PM, Dave Garrett wrote: > On Thursday, November 26, 2015 06:02:09 pm Eric Rescorla wrote: > > On Thu, Nov 26, 2015 at 2:50 PM, Dave Garrett > > wrote: > > > On Thursday, November 26, 2015 02:15:25 pm Ilari Liusvaara wrote: > > > > I actually looked at the Editors's Copy. The description is a mess: > It > > > > seemingly first requires key_share extension, even for the first > > > > ClientHello... Now, that extension can't be empty... And then > proceeds > > > > to say to omit it if client has no shares to send... Which looks like > > > > it is mutually contradictionary. > > > > > > We went back and forth on whether to omit or require an empty > extension. > > > It looks like we have a mix of the two left in there that need fixing. > (I > > > think something got merged weird) Thanks for pointing this out. > > > > > > I think it might be easier if we just required the extension for all > cases > > > where (EC)DHE suites are offered, and have it empty to request a server > > > choice, instead of an omitted extension. > > > > Yes, we should either have that or have empty be forbidden. It's a > matter of taste > > but on balance, let's go with "empty". If you want to submit a PR that > cleans > > this up, I'll merge that. > > -> https://github.com/tlswg/tls13-spec/pull/349 > > There's one last decision, though: does "empty" mean empty client_shares > vector or empty "extension_data" to save 2 bytes? I think it's cleaner to > just keep the same extension structure for all cases and have an empty > shares vector, which is what I have in the current PR. Empty vector seems dominant. -Ekr > > Dave > --001a114fbe9861d3c505257a3441 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Nov 26, 2015 at 3:36 PM, Dave Garrett <davemgarrett@gmail= .com> wrote:
On Thursday, November 26, 2015 06:02:09 pm Eric Rescorla wrote:
> On Thu, Nov 26, 2015 at 2:50 PM, Dave Garrett <davemgarrett@gmail.com>
> wrote:
> > On Thursday, November 26, 2015 02:15:25 pm Ilari Liusvaara wrote:=
> > > I actually looked at the Editors's Copy. The description= is a mess: It
> > > seemingly first requires key_share extension, even for the f= irst
> > > ClientHello... Now, that extension can't be empty... And= then proceeds
> > > to say to omit it if client has no shares to send... Which l= ooks like
> > > it is mutually contradictionary.
> >
> > We went back and forth on whether to omit or require an empty ext= ension.
> > It looks like we have a mix of the two left in there that need fi= xing. (I
> > think something got merged weird) Thanks for pointing this out. > >
> > I think it might be easier if we just required the extension for = all cases
> > where (EC)DHE suites are offered, and have it empty to request a = server
> > choice, instead of an omitted extension.
>
> Yes, we should either have that or have empty be forbidden. It's a= matter of taste
> but on balance, let's go with "empty". If you want to su= bmit a PR that cleans
> this up, I'll merge that.

->=C2=A0 https://github.com/tlswg/tls13-spec/p= ull/349

There's one last decision, though: does "empty" mean empty cl= ient_shares vector or empty "extension_data" to save 2 bytes? I t= hink it's cleaner to just keep the same extension structure for all cas= es and have an empty shares vector, which is what I have in the current PR.=

Empty vector seems dominant.
-Ekr



Dave

--001a114fbe9861d3c505257a3441-- From nobody Thu Nov 26 16:59: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 868D81B2FE6 for ; Thu, 26 Nov 2015 16:59:41 -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, 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 mQJ3LUXRNXTj for ; Thu, 26 Nov 2015 16:59:39 -0800 (PST) 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 B8C261B2FE5 for ; Thu, 26 Nov 2015 16:59:39 -0800 (PST) Received: by obdgf3 with SMTP id gf3so73105672obd.3 for ; Thu, 26 Nov 2015 16:59:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vimino-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uYfdrjE4KYhkdzLrmNkkn1LAlGUxv43mzjdW2aXI3Bo=; b=AjFzqnXmlbvNpt4DUwp0cHTvGafFJKj9MBoCb4fKzUHFEbuvfkcEvOYKTHBhG6oZic gmaed9VHKmOSio1pKoOd76NP2EzGcRJIoe/2cX+pGjRBgBdaPOJdDEkIxZ/RqB4z7hJA APpd9/QD0xiQQcul1TFhUYy2NRi2q2O83z1DZsoor8Oa0+UH720iq2W/5o9jNxCXkW3K sUaRTzE1x3Az9JWY0adIfXA82A6qK6ah15Mb/Kjl66IFl1BAN1iE01DfqX3Jdp+49IU+ Qo8AtRosRzk7xTVljuy1knTxpYuDpEexRf/+6GwdhdORJlcRzYJsfKEn5lSClcd/nCXf ipgA== 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=uYfdrjE4KYhkdzLrmNkkn1LAlGUxv43mzjdW2aXI3Bo=; b=EYp8nF4PLZs8DLjAg+p7AhPdXsRcPdzdH/kUBJtKCYG5DjS/SaD0K24jLEzzBYNrgd XlS8wxRV45et4sIwf/Cp+QlYhxyJFQWcrWFodHp+I2CJl+0Zp14TV2m21KXEUPziVQZ3 QwvULeomnCF/wANKgTOXJxTZ/fGni8vGR1bzhJRo4QKqh02Jf6BEF/IvzSs0AwDovldY WHmv4+KNibLRyHdjJaThrf2/CCWkXkuaYH8WKgDv5mp+wDyDPMajs6hWjC0wYYTlPI9G FRHFZZ9x/8uH4mPKyhcrb8PTYP5SoVM3LaPsoAsQZve5Yy/UfSWiZxZzswn5QQccIWSv VArA== X-Gm-Message-State: ALoCoQmHtMPgAZn9jaiaDkRKXp0ska7jbZt5eZNoGkQMzfXQ/PARGjYcAudpGryYPidJELxuDGRu MIME-Version: 1.0 X-Received: by 10.182.19.166 with SMTP id g6mr30364880obe.37.1448585979031; Thu, 26 Nov 2015 16:59:39 -0800 (PST) Received: by 10.76.171.103 with HTTP; Thu, 26 Nov 2015 16:59:38 -0800 (PST) X-Originating-IP: [148.87.19.218] In-Reply-To: References: <201511261750.11459.davemgarrett@gmail.com> <201511261836.54580.davemgarrett@gmail.com> Date: Fri, 27 Nov 2015 08:59:38 +0800 Message-ID: From: Xuelei Fan To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a11c2e71cb50f9505257b3491 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Extensions "supported_groups" and "key_share" in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2015 00:59:41 -0000 --001a11c2e71cb50f9505257b3491 Content-Type: text/plain; charset=UTF-8 If empty key_share vector is used to indicate to request a server choice, I think it is not necessary to have "supported_groups" extension as mandatory any more. key_share extension can be used for the supported named groups. "supported_groups" extension can be used for backward compatibility (if TLS 1.2 fade out in the future, need no "supported_groups" extension any more). Or, if both are needed as mandatory, may be better to separate functions that "supported_groups" extension defines the supported named groups and preference, and key_share defines the shares only (no supported groups, no preference, the groups must be defined in "supported_groups" extension). Xuelei On Fri, Nov 27, 2015 at 7:47 AM, Eric Rescorla wrote: > > > On Thu, Nov 26, 2015 at 3:36 PM, Dave Garrett > wrote: > >> On Thursday, November 26, 2015 06:02:09 pm Eric Rescorla wrote: >> > On Thu, Nov 26, 2015 at 2:50 PM, Dave Garrett >> > wrote: >> > > On Thursday, November 26, 2015 02:15:25 pm Ilari Liusvaara wrote: >> > > > I actually looked at the Editors's Copy. The description is a mess: >> It >> > > > seemingly first requires key_share extension, even for the first >> > > > ClientHello... Now, that extension can't be empty... And then >> proceeds >> > > > to say to omit it if client has no shares to send... Which looks >> like >> > > > it is mutually contradictionary. >> > > >> > > We went back and forth on whether to omit or require an empty >> extension. >> > > It looks like we have a mix of the two left in there that need >> fixing. (I >> > > think something got merged weird) Thanks for pointing this out. >> > > >> > > I think it might be easier if we just required the extension for all >> cases >> > > where (EC)DHE suites are offered, and have it empty to request a >> server >> > > choice, instead of an omitted extension. >> > >> > Yes, we should either have that or have empty be forbidden. It's a >> matter of taste >> > but on balance, let's go with "empty". If you want to submit a PR that >> cleans >> > this up, I'll merge that. >> >> -> https://github.com/tlswg/tls13-spec/pull/349 >> >> There's one last decision, though: does "empty" mean empty client_shares >> vector or empty "extension_data" to save 2 bytes? I think it's cleaner to >> just keep the same extension structure for all cases and have an empty >> shares vector, which is what I have in the current PR. > > > Empty vector seems dominant. > > -Ekr > > >> >> Dave >> > > --001a11c2e71cb50f9505257b3491 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If empty key_share=C2=A0vector=C2=A0is used to indicate to= request a server choice, I think it is not necessary to have=C2=A0=C2=A0"supported_groups&qu= ot; extension as mandatory any more. =C2=A0key_share extension can be used = for the supported named groups. =C2=A0=C2=A0"supported_groups" extension=C2=A0can= be used for=C2=A0backward compatib= ility (if TLS 1.2 fade out in the future, need no=C2=A0"supported_groups" exten= sion any more). =C2=A0
<= span style=3D"font-size:12.8px">
Or, if both are needed as=C2=A0mandatory, may be better to separate functions that=C2=A0"supported_groups" extension def= ines the supported named groups and preference, and key_share defines the s= hares only (no supported groups, no preference, the groups must be defined = in=C2=A0=C2=A0"supported_groups" extensio= n).
=

Xu= elei

On Fri, Nov 27, 2015 at 7:47 AM, Eric Rescorla <<= a href=3D"mailto:ekr@rtfm.com" target=3D"_blank">ekr@rtfm.com> wrote:


On Thu, Nov 26, 2015 at 3= :36 PM, Dave Garrett <davemgarrett@gmail.com> wrote:
On Thursday, November 26, 2015 06:02:09 pm Eric Res= corla wrote:
> On Thu, Nov 26, 2015 at 2:50 PM, Dave Garrett <davemgarrett@gmail.com>
> wrote:
> > On Thursday, November 26, 2015 02:15:25 pm Ilari Liusvaara wrote:=
> > > I actually looked at the Editors's Copy. The description= is a mess: It
> > > seemingly first requires key_share extension, even for the f= irst
> > > ClientHello... Now, that extension can't be empty... And= then proceeds
> > > to say to omit it if client has no shares to send... Which l= ooks like
> > > it is mutually contradictionary.
> >
> > We went back and forth on whether to omit or require an empty ext= ension.
> > It looks like we have a mix of the two left in there that need fi= xing. (I
> > think something got merged weird) Thanks for pointing this out. > >
> > I think it might be easier if we just required the extension for = all cases
> > where (EC)DHE suites are offered, and have it empty to request a = server
> > choice, instead of an omitted extension.
>
> Yes, we should either have that or have empty be forbidden. It's a= matter of taste
> but on balance, let's go with "empty". If you want to su= bmit a PR that cleans
> this up, I'll merge that.

->=C2=A0 https://github.com/tlswg/tls13-spec/p= ull/349

There's one last decision, though: does "empty" mean empty cl= ient_shares vector or empty "extension_data" to save 2 bytes? I t= hink it's cleaner to just keep the same extension structure for all cas= es and have an empty shares vector, which is what I have in the current PR.=

Empty vector seems dominant.
<= div>
-Ekr



Dave


--001a11c2e71cb50f9505257b3491-- From nobody Thu Nov 26 17:13: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 7E8861B3008 for ; Thu, 26 Nov 2015 17:13:05 -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, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id grpZV5lxo5DR for ; Thu, 26 Nov 2015 17:13:04 -0800 (PST) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3F461B3004 for ; Thu, 26 Nov 2015 17:13:03 -0800 (PST) Received: by ykdv3 with SMTP id v3so104145388ykd.0 for ; Thu, 26 Nov 2015 17:13:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=YE+E/UOBYaYKHTfWVjC3zPnGE799qjvhhrfwmC8UTig=; b=nZuAutBZI98txikOJJUEYvx6DIpHljOQVtHRuJkKFeGXNDTMQfepoBoKcAAPJKXyzW iQa1M7eIrUkLaT1UQ1oq1NMlKrYrf1Yk79oiAI4EzoOxGOxtN59n6k+ESvt7A+PDw4qh RSN4++1GmThoyx09FWpPneDJfsL4NRqMZB7HMw+yBBSuDsTPI7IvgaArxD3LBGpXs+Qs LHxtWED9Jb1UpYuitkHHyrTvQbQ/+lPB2f8l14znESPXHcmzEFxYD2d4qNsP68dP19v9 jWrxbfmLKCCChibscITqD+S2hkKVnoOUR3AkORbflRD5TVqOSJNLOu9GjccemNJjDyja wUAw== 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=YE+E/UOBYaYKHTfWVjC3zPnGE799qjvhhrfwmC8UTig=; b=TsnDRaVKuCEVvlyq4gWlN8ZelCvomoPl/t9EHUiBSBpVVethyz8QeQUGeBNlWs8s7r +oyWWgHaBrpBZ4y9TlHUrv24WJqGgpI/SouPti0cncvps4pReYbYPRlPuhd7sJ9iiKYe B63To+h5Jz2+6e+9ZH+XPH4gKY8buLkGVxBszyN6JnvamkSZpNajT8h2SLOGBBuPMUqc bOlGA/IMp7X92cn9vk5O7Ex2bqDNi1Ug/2XDucwnVg6fji63A8ib0+hv/fk5Xt5RAO6V EBKbXlAH93s2g9UaVDmMib8Q+sjkGR7tUzORaRtlBeCQsDv4D65MCywTsCtw+tcKuS0J VmYg== X-Gm-Message-State: ALoCoQn1IMSfzPplbITqdd23V5l+RfVQxDcyjhE5rnf9iJ3PdvizUBWU40jMFFZZ5dsyKTNL+Jkn X-Received: by 10.13.212.211 with SMTP id w202mr9206714ywd.192.1448586782969; Thu, 26 Nov 2015 17:13:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Thu, 26 Nov 2015 17:12:23 -0800 (PST) In-Reply-To: References: <201511261750.11459.davemgarrett@gmail.com> <201511261836.54580.davemgarrett@gmail.com> From: Eric Rescorla Date: Thu, 26 Nov 2015 17:12:23 -0800 Message-ID: To: Xuelei Fan Content-Type: multipart/alternative; boundary=001a114fbe98a0488305257b643f Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Extensions "supported_groups" and "key_share" in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2015 01:13:05 -0000 --001a114fbe98a0488305257b643f Content-Type: text/plain; charset=UTF-8 On Thu, Nov 26, 2015 at 4:59 PM, Xuelei Fan wrote: > If empty key_share vector is used to indicate to request a server choice, > That's not what it means. It means "I have no idea what your preferences are, so tell me which of the groups I support you prefer". Thus, you still need supported_groups to indicate the groups you support. -Ekr I think it is not necessary to have "supported_groups" extension as > mandatory any more. key_share extension can be used for the supported > named groups. "supported_groups" extension can be used for backward > compatibility (if TLS 1.2 fade out in the future, need no "supported_groups" > extension any more). > > Or, if both are needed as mandatory, may be better to separate functions > that "supported_groups" extension defines the supported named groups and > preference, and key_share defines the shares only (no supported groups, no > preference, the groups must be defined in "supported_groups" extension). > > Xuelei > > On Fri, Nov 27, 2015 at 7:47 AM, Eric Rescorla wrote: > >> >> >> On Thu, Nov 26, 2015 at 3:36 PM, Dave Garrett >> wrote: >> >>> On Thursday, November 26, 2015 06:02:09 pm Eric Rescorla wrote: >>> > On Thu, Nov 26, 2015 at 2:50 PM, Dave Garrett >>> > wrote: >>> > > On Thursday, November 26, 2015 02:15:25 pm Ilari Liusvaara wrote: >>> > > > I actually looked at the Editors's Copy. The description is a >>> mess: It >>> > > > seemingly first requires key_share extension, even for the first >>> > > > ClientHello... Now, that extension can't be empty... And then >>> proceeds >>> > > > to say to omit it if client has no shares to send... Which looks >>> like >>> > > > it is mutually contradictionary. >>> > > >>> > > We went back and forth on whether to omit or require an empty >>> extension. >>> > > It looks like we have a mix of the two left in there that need >>> fixing. (I >>> > > think something got merged weird) Thanks for pointing this out. >>> > > >>> > > I think it might be easier if we just required the extension for all >>> cases >>> > > where (EC)DHE suites are offered, and have it empty to request a >>> server >>> > > choice, instead of an omitted extension. >>> > >>> > Yes, we should either have that or have empty be forbidden. It's a >>> matter of taste >>> > but on balance, let's go with "empty". If you want to submit a PR that >>> cleans >>> > this up, I'll merge that. >>> >>> -> https://github.com/tlswg/tls13-spec/pull/349 >>> >>> There's one last decision, though: does "empty" mean empty client_shares >>> vector or empty "extension_data" to save 2 bytes? I think it's cleaner to >>> just keep the same extension structure for all cases and have an empty >>> shares vector, which is what I have in the current PR. >> >> >> Empty vector seems dominant. >> >> -Ekr >> >> >>> >>> Dave >>> >> >> > --001a114fbe98a0488305257b643f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Nov 26, 2015 at 4:59 PM, Xuelei Fan <xuelei.fan@vimino.com= > wrote:
I= f empty key_share=C2=A0vector=C2=A0is used to indicate to request a server = choice,

That's not what it means= . It means "I have no idea what your preferences are, so tell
me which of the groups I support you prefer". Thus, you still need s= upported_groups
to indicate the groups you support.
-Ekr



I think it is not necessary to have= =C2=A0=C2=A0"suppo= rted_groups" extension as mandatory any more. =C2=A0key_share extensio= n can be used for the supported named groups. =C2=A0=C2=A0"supported_groups" exte= nsion=C2=A0can be used for=C2=A0bac= kward compatibility (if TLS 1.2 fade out in the future, need no=C2=A0"supported_groups= " extension any more). =C2=A0<= /span>

Or, if both are needed as=C2=A0mandatory, may be better to separate functions that=C2=A0"supported_groups"= extension defines the supported named groups and preference, and key_share= defines the shares only (no supported groups, no preference, the groups mu= st be defined in=C2=A0=C2=A0= "supported_groups&= quot; extension)= .



<= /span>
Xuelei

On Fri, Nov 27, 2015 at 7:47 AM, Eric R= escorla <ekr@rtfm.com> wrote:


On Th= u, Nov 26, 2015 at 3:36 PM, Dave Garrett <davemgarrett@gmail.com&= gt; wrote:
On Thursday, November 26, 2015 = 06:02:09 pm Eric Rescorla wrote:
> On Thu, Nov 26, 2015 at 2:50 PM, Dave Garrett <davemgarrett@gmail.com>
> wrote:
> > On Thursday, November 26, 2015 02:15:25 pm Ilari Liusvaara wrote:=
> > > I actually looked at the Editors's Copy. The description= is a mess: It
> > > seemingly first requires key_share extension, even for the f= irst
> > > ClientHello... Now, that extension can't be empty... And= then proceeds
> > > to say to omit it if client has no shares to send... Which l= ooks like
> > > it is mutually contradictionary.
> >
> > We went back and forth on whether to omit or require an empty ext= ension.
> > It looks like we have a mix of the two left in there that need fi= xing. (I
> > think something got merged weird) Thanks for pointing this out. > >
> > I think it might be easier if we just required the extension for = all cases
> > where (EC)DHE suites are offered, and have it empty to request a = server
> > choice, instead of an omitted extension.
>
> Yes, we should either have that or have empty be forbidden. It's a= matter of taste
> but on balance, let's go with "empty". If you want to su= bmit a PR that cleans
> this up, I'll merge that.

->=C2=A0 https://github.com/tlswg/tls13-spec/p= ull/349

There's one last decision, though: does "empty" mean empty cl= ient_shares vector or empty "extension_data" to save 2 bytes? I t= hink it's cleaner to just keep the same extension structure for all cas= es and have an empty shares vector, which is what I have in the current PR.=

Empty vector seems dominant.
<= div>
-Ekr



Dave



--001a114fbe98a0488305257b643f-- From nobody Thu Nov 26 17:28: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 5693D1A00A4 for ; Thu, 26 Nov 2015 17:28:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.877 X-Spam-Level: X-Spam-Status: No, score=0.877 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FRT_BELOW2=2.154, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=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 fFuj1W8tgsoc for ; Thu, 26 Nov 2015 17:28:36 -0800 (PST) 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 82CF31A00A8 for ; Thu, 26 Nov 2015 17:28:36 -0800 (PST) Received: by oiww189 with SMTP id w189so54450130oiw.3 for ; Thu, 26 Nov 2015 17:28:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vimino-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mo7HkFEnARfrNDLxoP7cY8Aqnk763LilHgdkt117868=; b=G3QWT5LGCxsWxv52bz9r0eA5qe7Q/Nf7mx2xMmyeqArNG+s6S9hssGd/n4Hm1/WEsH Xk71XODUh74LvaRjx/DUpHPPKaVzRDXhIlv1/+iqt2fJulFg3xZIGnOzYwHhjK5yLhew o8ZXw16yW2B7zuE5xJp8oDNMCpF+ZhJ/z3wFFGw4GlqRrVwlfm9vvZQwdZKmSdbKooYn S1Ic1eii1StrO9XpvM93CIpdt8BJoB4XaJFjvBNZZNKcTwzTe/iG3oiqZ5VynYuhtIlM O2eB4soZ+5ZTCYMfTDdwSKOsmsNyGYJrdEUV4SU9JxoBWnvqmDTP2i+ZT4jEOiIMRQEw PCug== 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=mo7HkFEnARfrNDLxoP7cY8Aqnk763LilHgdkt117868=; b=Sr74HxHz287ZxDngQ9PaRRJXdvUbl9u7GbqI5uFSJ6FhfQ+9H8x6sJ9Wre+0P4L3BD +svUh0c/QUbScL/oBQosbcpoqQy2F1otttMo8N/TDEZGtZcQ5jl1NIxqMU8ssOKEQKb5 wtS0XoIWOa8LgzWe1Vn7rmVapInZM0AxCCy66AaMAIvQ2z/kh571Tx/PyO15pUTe5KDK A4Ivq8/1tGAake0GAWUvWHfR+dPknjCgEs3C6XiAmnEk/TWOlXwfw2vWhlYdw520zagU v+LpA5IH+V43MVLeBsaka7pCbH40jZQL7oDYPdgABhC7bE7wfhRb/AcfvLsAn0RWook+ v3eA== X-Gm-Message-State: ALoCoQmrIll098Dw6ziyAHsjAuTYPFJcqRdDPA3kbkTQrWP9FaZYzgr8AKoll7KfFnJdmgo/0kHd MIME-Version: 1.0 X-Received: by 10.202.208.83 with SMTP id h80mr31030326oig.74.1448587715917; Thu, 26 Nov 2015 17:28:35 -0800 (PST) Received: by 10.76.171.103 with HTTP; Thu, 26 Nov 2015 17:28:35 -0800 (PST) X-Originating-IP: [148.87.19.218] In-Reply-To: <20151126191525.GB3728@LK-Perkele-V2.elisa-laajakaista.fi> References: <20151126142632.GA3582@LK-Perkele-V2.elisa-laajakaista.fi> <20151126191525.GB3728@LK-Perkele-V2.elisa-laajakaista.fi> Date: Fri, 27 Nov 2015 09:28:35 +0800 Message-ID: From: Xuelei Fan To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a113d2ed63bd08505257b9c79 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Extensions "supported_groups" and "key_share" in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2015 01:28:39 -0000 --001a113d2ed63bd08505257b9c79 Content-Type: text/plain; charset=UTF-8 On Fri, Nov 27, 2015 at 3:15 AM, Ilari Liusvaara wrote: > On Thu, Nov 26, 2015 at 11:37:12PM +0800, Xuelei Fan wrote: > > > This wouldn't work if one had to downnegotiate TLS 1.2. That is going > to > > > happen A LOT. > > > > > > I think, "supported_groups" extension still can be sent for TLS 1.2, > but > > can be ignored for TLS 1.3. And "key_share" extension can be extended to > > support TLS 1.2 and previous versions. > > Given the slowness even _security_ _fix_ extensions get deployed, > planning any sort of transition is not IMO a good idea. > > Agreed. If "supported_groups" extension is only for compatibility, it can be not-mandatory. However, if it is defined to define the supported groups and preferences (see bellow), it can be mandatory. > > > Also, one can support curve, but not prefer to send share on it (the > > > server can call for it, at cost of extra RTT). > > > > > The scenarios may be not effective because of the extra RTT. As if the > > client want to negotiate the curve, it may be more effective to provide > the > > key information in the beginning. Or, maybe the generation of the key > > exchange information is more expensive? > > Yes, generating key exchanges can be expensive (even if it is cheaper > for each group then performing the actual key exchange). Especially for > P-384, P-521 and larger DH groups. > > Also, the shares can get large if many are sent. "Xmas tree" client > keyshare is 3384 bytes by quick calculation (whereas the one containing > P-256 and X25519 is just 109). That's many times the rest of the > ClientHello, and might already cause problems. > > Better plan might be to guess, as the cost of wrong guess is mostly > just 1 RTT. > > Agreed. > > > Plus, some of the curves are of special purpose and won't ever have > > > shares. > > > > > I missed this point. Is it possible to update the shares to tolerate the > > special purpose? For example, allowing empty shares. > > The current grammar does not allow empty value, so it is free. But > considering one needs supported_groups for backward compat., one can > just rely on that to signal that group is supported but no share is > given. > > > > > > Also, IIRC, if client has no shares, it omits key_share. If server > wants > > > FS cipher suite, it then has to signal retry. > > > > > That's may be the point I missed, too. Where and when the shares come > > from? Looks like there are two cases: > > 1. client generate the shares and wrap them in the initial ClientHello > > message. > > 2. client omits the key_share, but still request for (EC)DHE cipher > suites. > > If server want to negotiate (EC)DHE cipher suite, need an extra RTT. > > Client generate the shares on server request. > > I actually looked at the Editors's Copy. The description is a mess: It > seemingly first requires key_share extension, even for the first > ClientHello... Now, that extension can't be empty... And then proceeds > to say to omit it if client has no shares to send... Which looks like > it is mutually contradictionary. > > > I think the cases answer my confusing of the two extensions. Suppose, if > > the shares can be optional, maybe it is easier to use key_share only. If > > client has no shares, using key_share with no shares (function as > > supported_groups); if client has shares, using key_share with shares. > > I think two extensions are needed for backward compatiblity: One needs > to use supported_groups, but one can't extend it, so two extension it > is. > > TLS 1.3 (without 0-RTT) is supposed to be possible to downnegotiate at > least to TLS 1.2. > > Version down-negotiation is OK, but define "supported_groups" extension as mandatory may be too strong, unless there are other considerations (See bellow). > > > > The "supported_groups" extension defines the groups, while the > > > "key_share" > > > > extension defines both the groups and the key exchange information. > Both > > > > extension has its own preferences for the supported named groups. > It's > > > > easy to get conflicted if the two preferences are not consistent. > The > > > > "key_share" extension contains the information of the supported named > > > > groups. So, the information can be used to indicate the client > supported > > > > named groups. Maybe, for TLS 1.3, it is not necessary to use the > > > > "supported_groups" extension any more. > > > > > > The only way to be conflicted would be to send key share for group not > in > > > supported_groups. Sending supported_group for group not in key_shares > is > > > not a conflict[1]. > > > > > The preferences may be not consistent, too. For example, the > > supported_groups prefer ffdhe2048, but the key_share prefer ffdhe4096. > > Using two preferences would make the implementation inconsistent between > > vendors if no clearly specification about the preference of the two. > > Only supported_groups are perference-ordered. Key_shares is unordered, > with special exception for retry (the added group always goes last). > > In section 6.3.2.3: client_shares A list of offered KeyShareEntry values in descending order of client preference. I think, key_share is ordered too. If considering both key_share and supported_groups together, looks like there are two options: 1. key_share defines the preferences and supported named groups, which is overlap with supported_groups. supported_groups is used for version down-negotiation purpose. Don't define supported_groups as mandatory any more. For this case, empty key_share vector can be used to indicate to request server choice shares. 2. key_share won't defines the preferences any more. The named groups in key_share MUST exist in supported_groups extensions. supported_groups is used to define the supported named groups and preference, and key_share is used to define the shares. Both are mandatory. For this case, key_share can be omitted to indicate to request server choice shares. > > > [1] In fact, I expect many clients to send shares for P-256 and X25519, > > > plus offer P-384 and X448 (without shares unless requested). > > > > > > > > I like this scenarios more. It might be more clear if TLS 1.3 support > > this scenarios, but not the scenarios that sending shares before > > requested. For the TLS vendors, client implementation may only consider > > one option. While a server implementation need to consider both, the > effort > > doubles. > > Basically, with some groups, sending on request is the only workable > option, given how slow or large some shares are. > > Now, if PQ key exchanges were added, things would get worse, because > those methods tend to either have large keys or slow key exchange/ > generation. > > Agreed. Thanks, Xuelei > > > -Ilari > --001a113d2ed63bd08505257b9c79 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Nov 27, 2015 at 3:15 AM, Ilari Liusvaara <= ilariliusvaar= a@welho.com> wrote:
On T= hu, Nov 26, 2015 at 11:37:12PM +0800, Xuelei Fan wrote:
> > This wouldn't work if one had to downnegotiate TLS 1.2. That = is going to
> > happen A LOT.
> >
> > I think, "supported_groups" extension still can be sent= for TLS 1.2, but
> can be ignored for TLS 1.3.=C2=A0 And "key_share" extension = can be extended to
> support TLS 1.2 and previous versions.

Given the slowness even _security_ _fix_ extensions get deployed, planning any sort of transition is not IMO a good idea.

Agreed. =C2=A0

=
If =C2=A0"supported_groups" extension is only for comp= atibility, it can be not-mandatory.=C2=A0 However, if it is defined to defi= ne the supported groups and preferences (see bellow), it can be mandatory.<= /div>
=C2=A0
> > Also, one can support curve, but not prefer to send share on it (= the
> > server can call for it, at cost of extra RTT).
> >
> The scenarios may be not effective because of the extra RTT.=C2=A0 As = if the
> client want to negotiate the curve, it may be more effective to provid= e the
> key information in the beginning.=C2=A0 Or, maybe the generation of th= e key
> exchange information is more expensive?

Yes, generating key exchanges can be expensive (even if it is cheape= r
for each group then performing the actual key exchange). Especially for
P-384, P-521 and larger DH groups.

Also, the shares can get large if many are sent. "Xmas tree" clie= nt
keyshare is 3384 bytes by quick calculation (whereas the one containing
P-256 and X25519 is just 109). That's many times the rest of the
ClientHello, and might already cause problems.

Better plan might be to guess, as the cost of wrong guess is mostly
just 1 RTT.

Agreed.
=C2=A0
> > Plus, some of the curves are of special purpose and won't eve= r have
> > shares.
> >
> I missed this point.=C2=A0 Is it possible to update the shares to tole= rate the
> special purpose?=C2=A0 For example, allowing empty shares.

The current grammar does not allow empty value, so it is free. But considering one needs supported_groups for backward compat., one can
just rely on that to signal that group is supported but no share is
given.

>
> > Also, IIRC, if client has no shares, it omits key_share. If serve= r wants
> > FS cipher suite, it then has to signal retry.
> >
> That's may be the point I missed, too.=C2=A0 Where and when the sh= ares come
> from?=C2=A0 Looks like there are two cases:
> 1. client generate the shares and wrap them in the initial ClientHello=
> message.
> 2. client omits the key_share, but still request for (EC)DHE cipher su= ites.
> If server want to negotiate (EC)DHE cipher suite, need an extra RTT. > Client generate the shares on server request.

I actually looked at the Editors's Copy. The description is a me= ss: It
seemingly first requires key_share extension, even for the first
ClientHello... Now, that extension can't be empty... And then proceeds<= br> to say to omit it if client has no shares to send... Which looks like
it is mutually contradictionary.

> I think the cases answer my confusing of the two extensions.=C2=A0 Sup= pose, if
> the shares can be optional, maybe it is easier to use key_share only.= =C2=A0 If
> client has no shares, using key_share with no shares (function as
> supported_groups); if client has shares, using key_share with shares.<= br>
I think two extensions are needed for backward compatiblity: One nee= ds
to use supported_groups, but one can't extend it, so two extension it is.

TLS 1.3 (without 0-RTT) is supposed to be possible to downnegotiate at
least to TLS 1.2.

Version down-negotiation is O= K, but define "supported_groups" extension as mandatory may be to= o strong, unless there are other considerations (See bellow).
=C2=A0
> > > The "supported_groups" extension defines the group= s, while the
> > "key_share"
> > > extension defines both the groups and the key exchange infor= mation.=C2=A0 Both
> > > extension has its own preferences for the supported named gr= oups.=C2=A0 It's
> > > easy to get conflicted if the two preferences are not consis= tent.=C2=A0 The
> > > "key_share" extension contains the information of = the supported named
> > > groups.=C2=A0 So, the information can be used to indicate th= e client supported
> > > named groups.=C2=A0 Maybe, for TLS 1.3, it is not necessary = to use the
> > > "supported_groups" extension any more.
> >
> > The only way to be conflicted would be to send key share for grou= p not in
> > supported_groups. Sending supported_group for group not in key_sh= ares is
> > not a conflict[1].
> >
> The preferences may be not consistent, too.=C2=A0 For example, the
> supported_groups prefer ffdhe2048, but the key_share prefer ffdhe4096.=
> Using two preferences would make the implementation inconsistent betwe= en
> vendors if no clearly specification about the preference of the two.
Only supported_groups are perference-ordered. Key_shares is unordere= d,
with special exception for retry (the added group always goes last).


In section 6.3.2.3:
=C2=A0 =C2=A0 client_shares<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A list of offered KeyShareEntry= values in descending order of client preference.=C2=A0

<= /div>
I think, key_share is ordered too.=C2=A0 If considering both key_= share and supported_groups together, looks like there are two options:
1. key_share defines the preferences and supported named groups, whic= h is overlap with supported_groups. supported_groups is used for version do= wn-negotiation purpose. Don't define supported_groups as mandatory any = more.

For this case,=C2=A0empty key_share=C2=A0vector=C2=A0can be used to indicate to reques= t server choice shares.

2. key_share won= 9;t defines the preferences any more.=C2=A0 The named groups in key_share M= UST exist in supported_groups extensions. =C2=A0supported_groups is used to= define the supported named groups and preference, and key_share is used to= define the shares.=C2=A0 Both are mandatory.

For = this case,=C2=A0key_share can be omitted= =C2=A0to indicate to request server= choice shares.
=C2=A0
> > [1] In fact, I expect many clients to send shares for P-256 and X= 25519,
> > plus offer P-384 and X448 (without shares unless requested).
> >
> >
> I like this scenarios more.=C2=A0 It might be more clear if TLS 1.3 su= pport
> this scenarios, but not the scenarios that sending shares before
> requested.=C2=A0 For the TLS vendors, client implementation may only c= onsider
> one option. While a server implementation need to consider both, the e= ffort
> doubles.

Basically, with some groups, sending on request is the only workable=
option, given how slow or large some shares are.

Now, if PQ key exchanges were added, things would get worse, because
those methods tend to either have large keys or slow key exchange/
generation.

Agreed.

Thanks,
Xuelei
=C2= =A0


-Ilari

--001a113d2ed63bd08505257b9c79-- From nobody Thu Nov 26 17:34: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 D4F7E1A01A4 for ; Thu, 26 Nov 2015 17:34:14 -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, 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 N43gLtBo2yQX for ; Thu, 26 Nov 2015 17:34:13 -0800 (PST) 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 EEBAE1A0180 for ; Thu, 26 Nov 2015 17:34:12 -0800 (PST) Received: by oiww189 with SMTP id w189so54497468oiw.3 for ; Thu, 26 Nov 2015 17:34:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vimino-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nQUdOp4M3+BJk97tkyvNvElzDdKAxt2Esab6tqvBeJU=; b=ezWbXsBAUxbo412HS514TFiqRVrarvOnqyvU5JlZMdMt4RLxkOK4dJhfdttLkQerv3 wUwCC0rzpbxRBlw24JzZ7y4i9mYsepaXEjS5oZ1EsmWvwFmSWcOSXi1FWxu9XhPWxahZ hs6RqJBzmd33y+h9du5hjKRuxDcSMU3+2Z/PA4XErnxFv5GJeDitG2T0WV4f86QQzF0v UYSVNPNN3RSNNfPDOTeuDN645C+/NfXXCnrfIE4Ca2CgH8brkzPPUrB6wTYf+QCcgZJv W//KLgUYjg19JWu4OXoeUYutvBT4tk4e1aOsJOjvEyK0jRsNifyvKWJw9b/S/O13nFA4 +80g== 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=nQUdOp4M3+BJk97tkyvNvElzDdKAxt2Esab6tqvBeJU=; b=KuI4X4k8rsub3SoF1cVARM/QgXaAqun5uEKmd6Sou+r9GuAOBTFeuuI06CT+FTsbrP Dm7D1geGmh7zfQIZQ52Eda9UYANEKNB0StM669Ul7g9Fh9Z5PUUFFuTP9Bs5mpgwkxO+ HYdajRvQxvvQ7P0ofGhQAe8Q9s797JE9Sjj51I968ZLo4gIxgOH0DhEsSZu2xz6lXxEl Rl7Gkm3uJ3bRfZK+lRxomBjDe3+0Ii1kJ6g7MZR2jVjeQ6Z7rXl9D1yG4GbgmQXw7oy4 HldB4MBx8aD0/2YUgGO46TWGnZM/M9XUuLgDKZcUbRJTcCwR2R5KAq4qIKzrV1OnBB22 u/Wg== X-Gm-Message-State: ALoCoQkEcVCjmlsp0nu/7DUk3cLNI5/Q8Qn6CgR2bX/ZrlBSeNbMjx1J3ZmyD5mpoYM74yOozICU MIME-Version: 1.0 X-Received: by 10.202.179.195 with SMTP id c186mr9294560oif.73.1448588052483; Thu, 26 Nov 2015 17:34:12 -0800 (PST) Received: by 10.76.171.103 with HTTP; Thu, 26 Nov 2015 17:34:12 -0800 (PST) X-Originating-IP: [148.87.19.218] In-Reply-To: References: <201511261750.11459.davemgarrett@gmail.com> <201511261836.54580.davemgarrett@gmail.com> Date: Fri, 27 Nov 2015 09:34:12 +0800 Message-ID: From: Xuelei Fan To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a113cdd2c4b6a3005257bb084 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Extensions "supported_groups" and "key_share" in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2015 01:34:15 -0000 --001a113cdd2c4b6a3005257bb084 Content-Type: text/plain; charset=UTF-8 On Fri, Nov 27, 2015 at 9:12 AM, Eric Rescorla wrote: > > > On Thu, Nov 26, 2015 at 4:59 PM, Xuelei Fan wrote: > >> If empty key_share vector is used to indicate to request a server choice, >> > > That's not what it means. It means "I have no idea what your preferences > are, so tell > me which of the groups I support you prefer". Thus, you still need > supported_groups > to indicate the groups you support. > > Make sense to me. Thanks, Xuelei > -Ekr > > > > I think it is not necessary to have "supported_groups" extension as >> mandatory any more. key_share extension can be used for the supported >> named groups. "supported_groups" extension can be used for backward >> compatibility (if TLS 1.2 fade out in the future, need no "supported_groups" >> extension any more). >> >> Or, if both are needed as mandatory, may be better to separate functions >> that "supported_groups" extension defines the supported named groups and >> preference, and key_share defines the shares only (no supported groups, no >> preference, the groups must be defined in "supported_groups" extension). >> > > > >> Xuelei >> >> On Fri, Nov 27, 2015 at 7:47 AM, Eric Rescorla wrote: >> >>> >>> >>> On Thu, Nov 26, 2015 at 3:36 PM, Dave Garrett >>> wrote: >>> >>>> On Thursday, November 26, 2015 06:02:09 pm Eric Rescorla wrote: >>>> > On Thu, Nov 26, 2015 at 2:50 PM, Dave Garrett >>> > >>>> > wrote: >>>> > > On Thursday, November 26, 2015 02:15:25 pm Ilari Liusvaara wrote: >>>> > > > I actually looked at the Editors's Copy. The description is a >>>> mess: It >>>> > > > seemingly first requires key_share extension, even for the first >>>> > > > ClientHello... Now, that extension can't be empty... And then >>>> proceeds >>>> > > > to say to omit it if client has no shares to send... Which looks >>>> like >>>> > > > it is mutually contradictionary. >>>> > > >>>> > > We went back and forth on whether to omit or require an empty >>>> extension. >>>> > > It looks like we have a mix of the two left in there that need >>>> fixing. (I >>>> > > think something got merged weird) Thanks for pointing this out. >>>> > > >>>> > > I think it might be easier if we just required the extension for >>>> all cases >>>> > > where (EC)DHE suites are offered, and have it empty to request a >>>> server >>>> > > choice, instead of an omitted extension. >>>> > >>>> > Yes, we should either have that or have empty be forbidden. It's a >>>> matter of taste >>>> > but on balance, let's go with "empty". If you want to submit a PR >>>> that cleans >>>> > this up, I'll merge that. >>>> >>>> -> https://github.com/tlswg/tls13-spec/pull/349 >>>> >>>> There's one last decision, though: does "empty" mean empty >>>> client_shares vector or empty "extension_data" to save 2 bytes? I think >>>> it's cleaner to just keep the same extension structure for all cases and >>>> have an empty shares vector, which is what I have in the current PR. >>> >>> >>> Empty vector seems dominant. >>> >>> -Ekr >>> >>> >>>> >>>> Dave >>>> >>> >>> >> > --001a113cdd2c4b6a3005257bb084 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Nov 27, 2015 at 9:12 AM, Eric Rescorla <ekr@rtfm.com> wrote:<= br>


On Thu, Nov 26, 2015= at 4:59 PM, Xuelei Fan <xuelei.fan@vimino.com> wrote:
If empty key_share=C2=A0v= ector=C2=A0is used to indicate to request a server choice,

That's not what it means. It means "= I have no idea what your preferences are, so tell
me which of the= groups I support you prefer". Thus, you still need supported_groups
to indicate the groups you support.

Make sense to me.

Thanks= ,
Xuelei
=C2=A0
-Ekr



I think it is n= ot necessary to have=C2=A0=C2=A0"supported_groups" extension as mandatory any more. =C2= =A0key_share extension can be used for the supported named groups. =C2=A0=C2=A0"suppor= ted_groups" extension=C2=A0can be used for=C2=A0backward compatibility (if TLS 1.2 fade out in the future= , need no=C2=A0&= quot;supported_groups" extension any more). =C2=A0

Or, if both are needed as=C2= =A0mandatory, may be better to separate functions t= hat=C2=A0"s= upported_groups" extension defines the supported named groups and pref= erence, and key_share defines the shares only (no supported groups, no pref= erence, the groups must be defined in=C2=A0=C2=A0&q= uot;supported_groups" extension).

<= br>
=
Xuelei

On Fri, Nov 27, 2015 at 7:47 AM, Eric Rescorla <ekr@rtfm.com>= wrote:


On Thu, Nov 26, 2015 at 3:36 P= M, Dave Garrett <davemgarrett@gmail.com> wrote:
On Thursday, November 26, 2015 06:02:09 pm Eric Rescorla= wrote:
> On Thu, Nov 26, 2015 at 2:50 PM, Dave Garrett <davemgarrett@gmail.com>
> wrote:
> > On Thursday, November 26, 2015 02:15:25 pm Ilari Liusvaara wrote:=
> > > I actually looked at the Editors's Copy. The description= is a mess: It
> > > seemingly first requires key_share extension, even for the f= irst
> > > ClientHello... Now, that extension can't be empty... And= then proceeds
> > > to say to omit it if client has no shares to send... Which l= ooks like
> > > it is mutually contradictionary.
> >
> > We went back and forth on whether to omit or require an empty ext= ension.
> > It looks like we have a mix of the two left in there that need fi= xing. (I
> > think something got merged weird) Thanks for pointing this out. > >
> > I think it might be easier if we just required the extension for = all cases
> > where (EC)DHE suites are offered, and have it empty to request a = server
> > choice, instead of an omitted extension.
>
> Yes, we should either have that or have empty be forbidden. It's a= matter of taste
> but on balance, let's go with "empty". If you want to su= bmit a PR that cleans
> this up, I'll merge that.

->=C2=A0 https://github.com/tlswg/tls13-spec/p= ull/349

There's one last decision, though: does "empty" mean empty cl= ient_shares vector or empty "extension_data" to save 2 bytes? I t= hink it's cleaner to just keep the same extension structure for all cas= es and have an empty shares vector, which is what I have in the current PR.=

Empty vector seems dominant.
<= div>
-Ekr



Dave




--001a113cdd2c4b6a3005257bb084-- From nobody Thu Nov 26 17:37: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 9ACE51A1AE6 for ; Thu, 26 Nov 2015 17:37:31 -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, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=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 h-DZQ4OWdjSC for ; Thu, 26 Nov 2015 17:37:30 -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 EAF231A1AD9 for ; Thu, 26 Nov 2015 17:37:29 -0800 (PST) Received: by oixx65 with SMTP id x65so54503529oix.0 for ; Thu, 26 Nov 2015 17:37:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vimino-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8UsE18kP7gYh+MH4n6qGSLB89zQZGcYkd7z6OBwqTgs=; b=NNLgfIezoWpg+KCxYpxhI2c+dawr8vHJGa6jDKvV3vCR7XCnbQ44kZGcRrYT/O83sa ul8UQCK1eH28BHx3S4Vfo38OxSOLnhSPlwuJSxfQjdrGLo7ViQ7rQUUKpRe0SqyZGt3s Jb1RWnQHXcnkjHlcCchsUzD2eitS2VsJyFXobXljwf3PwqL90sJDbT7K70rpgYvpd6ho 9sigm/RtwudJDhbLchu+xcha0kcAfrC+kXi5HjTm1WOghJVt+bYtN719Yju4+Qisl9ia 4C6RQEkcVfqMvT3u+BJ7BceWaSuStArrnDRcxQfAQ6EVsiXUGTxeLHV0/9jWSesQ4V6x v9vw== 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=8UsE18kP7gYh+MH4n6qGSLB89zQZGcYkd7z6OBwqTgs=; b=PSf+IJ0oRb0n7kPRryGjCUljVx789HHgDt6ePg/UTH0tE8QMC5/XvgWdegSxy8obGk SpdjgHZqtAeiU9ndEVS3M3ne42eDdSu6BdaMcxPNtQ7lvofLi8ey5YwKg75qrXyIcAAJ TnjXzGXK9r1SmX3DnrQ9pSDOSnW2+oG8Oi31rd+jEOcMzvCPIB68J3ZuG4XazXIcqFaf 9Ts1lfEI4lQ+uCJiqZzjxwJVU4ZvIDbtIqE+w7uDfttQ/pfCSWu4DTwgp4glZ+61Swqu yyohGTyGmeNdZuxiP6aOIOwKQf5jROSM0obJ9g2NgoDwGEzVy7hnPcLAW4TWrWc3bjLh GU5Q== X-Gm-Message-State: ALoCoQkLpVR8xTBERxHcpjNwhgLaWzW6XnlgHDknZNen3rBqcyz2eiSm9N19PHEkFNhh/kY86Ffg MIME-Version: 1.0 X-Received: by 10.202.215.195 with SMTP id o186mr17171263oig.87.1448588249458; Thu, 26 Nov 2015 17:37:29 -0800 (PST) Received: by 10.76.171.103 with HTTP; Thu, 26 Nov 2015 17:37:29 -0800 (PST) X-Originating-IP: [148.87.19.218] In-Reply-To: References: <20151126142632.GA3582@LK-Perkele-V2.elisa-laajakaista.fi> <20151126191525.GB3728@LK-Perkele-V2.elisa-laajakaista.fi> Date: Fri, 27 Nov 2015 09:37:29 +0800 Message-ID: From: Xuelei Fan To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a113d531009039605257bbc36 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Extensions "supported_groups" and "key_share" in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2015 01:37:31 -0000 --001a113d531009039605257bbc36 Content-Type: text/plain; charset=UTF-8 > > > > > The "supported_groups" extension defines the groups, while the >> > > "key_share" >> > > > extension defines both the groups and the key exchange >> information. Both >> > > > extension has its own preferences for the supported named groups. >> It's >> > > > easy to get conflicted if the two preferences are not consistent. >> The >> > > > "key_share" extension contains the information of the supported >> named >> > > > groups. So, the information can be used to indicate the client >> supported >> > > > named groups. Maybe, for TLS 1.3, it is not necessary to use the >> > > > "supported_groups" extension any more. >> > > >> > > The only way to be conflicted would be to send key share for group >> not in >> > > supported_groups. Sending supported_group for group not in key_shares >> is >> > > not a conflict[1]. >> > > >> > The preferences may be not consistent, too. For example, the >> > supported_groups prefer ffdhe2048, but the key_share prefer ffdhe4096. >> > Using two preferences would make the implementation inconsistent between >> > vendors if no clearly specification about the preference of the two. >> >> Only supported_groups are perference-ordered. Key_shares is unordered, >> with special exception for retry (the added group always goes last). >> >> > In section 6.3.2.3: > client_shares > A list of offered KeyShareEntry values in descending order of > client preference. > > I think, key_share is ordered too. If considering both key_share and > supported_groups together, looks like there are two options: > 1. key_share defines the preferences and supported named groups, which is > overlap with supported_groups. supported_groups is used for version > down-negotiation purpose. Don't define supported_groups as mandatory any > more. > > For this case, empty key_share vector can be used to indicate to request > server choice shares. > > 2. key_share won't defines the preferences any more. The named groups in > key_share MUST exist in supported_groups extensions. supported_groups is > used to define the supported named groups and preference, and key_share is > used to define the shares. Both are mandatory. > > For this case, key_share can be omitted to indicate to request server > choice shares. > > Update: key_share can be omitted, or the client_shares vector can be empty to indicate to request server choice shares. Xuelei --001a113d531009039605257bbc36 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> > > The "s= upported_groups" extension defines the groups, while the
> > "key_share"
> > > extension defines both the groups and the key exchange infor= mation.=C2=A0 Both
> > > extension has its own preferences for the supported named gr= oups.=C2=A0 It's
> > > easy to get conflicted if the two preferences are not consis= tent.=C2=A0 The
> > > "key_share" extension contains the information of = the supported named
> > > groups.=C2=A0 So, the information can be used to indicate th= e client supported
> > > named groups.=C2=A0 Maybe, for TLS 1.3, it is not necessary = to use the
> > > "supported_groups" extension any more.
> >
> > The only way to be conflicted would be to send key share for grou= p not in
> > supported_groups. Sending supported_group for group not in key_sh= ares is
> > not a conflict[1].
> >
> The preferences may be not consistent, too.=C2=A0 For example, the
> supported_groups prefer ffdhe2048, but the key_share prefer ffdhe4096.=
> Using two preferences would make the implementation inconsistent betwe= en
> vendors if no clearly specification about the preference of the two.
Only supported_groups are perference-ordered. Key_shares is unordere= d,
with special exception for retry (the added group always goes last).


In section 6.3.2.3:
=C2=A0 =C2=A0 = client_shares
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A list of offered= KeyShareEntry values in descending order of client preference.=C2=A0

I think, key_share is ordered too.=C2=A0 If conside= ring both key_share and supported_groups together, looks like there are two= options:
1. key_share defines the preferences and supported name= d groups, which is overlap with supported_groups. supported_groups is used = for version down-negotiation purpose. Don't define supported_groups as = mandatory any more.

For this case,=C2=A0empty key_share=C2=A0vector=C2=A0can be used to indi= cate to request server choice shares.

2. ke= y_share won't defines the preferences any more.=C2=A0 The named groups = in key_share MUST exist in supported_groups extensions. =C2=A0supported_gro= ups is used to define the supported named groups and preference, and key_sh= are is used to define the shares.=C2=A0 Both are mandatory.

<= /div>
For this case,=C2=A0key_share ca= n be omitted=C2=A0to indicate to re= quest server choice shares.
=C2=A0
<= /span>
Update:=C2=A0key_share can be omitted, or=C2=A0the client_shares vec= tor can be empty=C2=A0to indicate to reque= st server choice shares.
=
Xuelei
<= /div>
--001a113d531009039605257bbc36-- From nobody Thu Nov 26 17:39: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 0DB5A1A1B56 for ; Thu, 26 Nov 2015 17:39:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.154 X-Spam-Level: X-Spam-Status: No, score=0.154 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FRT_BELOW2=2.154, 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 baMb40Ui-OIG for ; Thu, 26 Nov 2015 17:39:05 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED3521A00EE for ; Thu, 26 Nov 2015 17:39:04 -0800 (PST) Received: by qkda6 with SMTP id a6so32058348qkd.3 for ; Thu, 26 Nov 2015 17:39:04 -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=u1sIA3Kxw5MmvGtG6slSlgF6Iqqf8eR5Kn9BvHXPuRs=; b=PHVxheCNLhFN+irbT80o2Mah1bNxiP5618kPgG2MlnyqAtsTZB11Gbs/YCV7mHY3qN MHhFVwIpqYQ83x9SfFHh5Ad+RqOf4DVtmFr9pN2fo+9xXfGE/HzvI1DXXG1jENuPtigD 40q8J3rSEzyEKolyb3ArCK8k9VcOfu97Qz1WkMXWX1GazcACHcNegwqnUXgxI35mT0xu DKiXnsUZxn0XUR7oRKpk+bmDV6XrqU45iHyzEJa9f3LToIvT0izl8ixMmddOlm6ZPLX9 cgg0eCkDDzYkUq4m4/Jik7VKyq41hDkgQaChsxNL3fGrJfxPkTu11J+sEUBcmDw6rk83 8SUA== X-Received: by 10.55.73.142 with SMTP id w136mr46069753qka.87.1448588344213; Thu, 26 Nov 2015 17:39:04 -0800 (PST) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id r66sm8317295qhb.35.2015.11.26.17.39.03 (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 26 Nov 2015 17:39:03 -0800 (PST) From: Dave Garrett To: Xuelei Fan Date: Thu, 26 Nov 2015 20:39:00 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20151126191525.GB3728@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201511262039.01452.davemgarrett@gmail.com> Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Extensions "supported_groups" and "key_share" in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2015 01:39:06 -0000 On Thursday, November 26, 2015 08:28:35 pm Xuelei Fan wrote: > If "supported_groups" extension is only for compatibility, it can be > not-mandatory. However, if it is defined to define the supported groups > and preferences (see bellow), it can be mandatory. If it weren't for the fact that we're retrofitting the elliptic_curves extension from RFC 4492 into the supported_groups extension via draft-ietf-tls-negotiated-ff-dhe & the TLS 1.3 draft, then yes, we'd probably have the key sharing and group support enumeration in the same extension. We are recycling the old extension for backwards compatibility, however, so we're having these two things be separate. A 20 year old protocol is just going to have kludgey stuff like this, whether we like it or not. ;) > In section 6.3.2.3: > client_shares > A list of offered KeyShareEntry values in descending order of > client preference. > > I think, key_share is ordered too. If considering both key_share and > supported_groups together, looks like there are two options [...] Yes, I addressed the conflict of priorities in one of my PRs, but it's on my todo list to rewrite it as ekr noted a few parts that needed changing. We agreed on simply making the two orders be required to be the same, though at "SHOULD"-level requirement. Those that have them differ will be dealt with at the implementations' discretion. > For this case, key_share can be omitted to indicate to request server > choice shares. I dislike special cases; people screw them up. Life is easier if all (EC)DHE suites need a fixed set of accompanying extensions. Less complicated and simpler to describe clearly. (as pointed out, omitting it left us with garbled text, though that was also just due to us flip-flopping on how to handle it) Dave From nobody Thu Nov 26 17:48:17 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DAB41A877A for ; Thu, 26 Nov 2015 17:48:16 -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, 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 bghHTRl-r9hZ for ; Thu, 26 Nov 2015 17:48:15 -0800 (PST) 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 07CF01A8778 for ; Thu, 26 Nov 2015 17:48:15 -0800 (PST) Received: by obbww6 with SMTP id ww6so72959649obb.0 for ; Thu, 26 Nov 2015 17:48:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vimino-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2vwqQb6HHK3rxFZsznI0MyoStQkEE7d8DQq5DJHWKaw=; b=SIYepnL35FrYDeG+o+TErclY10hMGefNefbdEVBDBF2ZYnIQbRmgKwTnVPZS3WwKa4 BYrKm5jsW5q2BjmIUXvzw6zm0gdLcQFkzGmAWaF73UulHoLBt+v8/cgAuUJlYmHORR7s FU0Y2qpEAMoFxShQvbJQsbL0AZltFh2d7NEU0cButWtNby2w5MHVFlWx+4AvmM7R85AT QqKkpDa9j8ghiMd5xswkyma/R1UrxYN+wkLWjdVbeCBqGhqQFKuVBavDX0BWlGsmTFBJ 2zFWNmRmkUpmt8SSXmmygpjK9P8N9CMVBAUCVSmDkmrHEiQBlIa3x1wMiBLdUNS/OVX0 GaGQ== 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=2vwqQb6HHK3rxFZsznI0MyoStQkEE7d8DQq5DJHWKaw=; b=KEoulkrS/xVpWMOrAW8Jyw7DMT5uY6MQ+yN8YaUnaD1ZwccZPwPnpxDU5wnhdvYmuG NmmXmd9tfu2fi4Ms1Le9Q87juacc3iI+NqiAVLLZqyafldtgNaTXMd5/eQh7FdwESko8 B8KVvW/noCeS9+z+yFYxYdqXcpsVUJb7ZvpwFGUj7C9C2uv25c/6N/Jw8pvcvTRMkc3d uKthxHCSUS6FC5GPWKQLh+8byo+ubJF+Nwlp8vPdE9L9iC3afUy/SloVCU4O9eh9wNqX lLAO9OtyrlzaFjYTTEUWw6Ku8UgLVheXy0C4RrbYrR4oswRa+4h8sQgf7xSe2qbWhuh2 j6UA== X-Gm-Message-State: ALoCoQnKktufOdSb11EL7edfvQvoBKPm8XH+QqbmVoTUtUk3AF0Ek4U1azwSmlbeO2ldts6d7ves MIME-Version: 1.0 X-Received: by 10.182.81.162 with SMTP id b2mr30506830oby.7.1448588894489; Thu, 26 Nov 2015 17:48:14 -0800 (PST) Received: by 10.76.171.103 with HTTP; Thu, 26 Nov 2015 17:48:14 -0800 (PST) X-Originating-IP: [148.87.19.218] In-Reply-To: <201511262039.01452.davemgarrett@gmail.com> References: <20151126191525.GB3728@LK-Perkele-V2.elisa-laajakaista.fi> <201511262039.01452.davemgarrett@gmail.com> Date: Fri, 27 Nov 2015 09:48:14 +0800 Message-ID: From: Xuelei Fan To: Dave Garrett Content-Type: multipart/alternative; boundary=047d7b2e49f07b649805257be22f Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Extensions "supported_groups" and "key_share" in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2015 01:48:16 -0000 --047d7b2e49f07b649805257be22f Content-Type: text/plain; charset=UTF-8 > I think, key_share is ordered too. If considering both key_share and > > supported_groups together, looks like there are two options > [...] > > Yes, I addressed the conflict of priorities in one of my PRs, but it's on > my todo list to rewrite it as ekr noted a few parts that needed changing. > We agreed on simply making the two orders be required to be the same, > though at "SHOULD"-level requirement. Those that have them differ will be > dealt with at the implementations' discretion. > > Requiring the two order the same would triage order checking. It may be easier that the key_share does not define the order. > > For this case, key_share can be omitted to indicate to request server > > choice shares. > > I dislike special cases; people screw them up. Life is easier if all > (EC)DHE suites need a fixed set of accompanying extensions. Less > complicated and simpler to describe clearly. (as pointed out, omitting it > left us with garbled text, though that was also just due to us > flip-flopping on how to handle it) I meant that the proposal uses one of the options for the final version, not both. It may be more simple, I think. Thanks, Xuelei --047d7b2e49f07b649805257be22f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


> I think, key_share= is ordered too.=C2=A0 If considering both key_share and
> supported_groups together, looks like there are two options
[...]

Yes, I addressed the conflict of priorities in one of my PRs, but it's = on my todo list to rewrite it as ekr noted a few parts that needed changing= . We agreed on simply making the two orders be required to be the same, tho= ugh at "SHOULD"-level requirement. Those that have them differ wi= ll be dealt with at the implementations' discretion.

Requiring the two order the s= ame would triage order checking.=C2=A0 It may be easier that the key_share = does not define the order.

=C2=A0
> For this case, key_share can be omitted to indicate to request server<= br> > choice shares.

I dislike special cases; people screw them up. Life is easier if all= (EC)DHE suites need a fixed set of accompanying extensions. Less complicat= ed and simpler to describe clearly. (as pointed out, omitting it left us wi= th garbled text, though that was also just due to us flip-flopping on how t= o handle it)
I meant that the proposal uses one of the opt= ions for the final version, not both.=C2=A0 It may be more simple, I think.=

Thanks,
Xuelei
=C2=A0
--047d7b2e49f07b649805257be22f-- From nobody Thu Nov 26 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 6E8AA1B30A9 for ; Thu, 26 Nov 2015 18:12:16 -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, 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 rAEB6gLrLgOh for ; Thu, 26 Nov 2015 18:12:15 -0800 (PST) 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 5E1F71B30A6 for ; Thu, 26 Nov 2015 18:12:15 -0800 (PST) Received: by obbnk6 with SMTP id nk6so73021805obb.2 for ; Thu, 26 Nov 2015 18:12:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vimino-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TfHegkR0Wd/spg8aTbHd8G6+L4MBK8CYXLAw/Y9T71A=; b=EXLrkGk5UI/jWSi0bIfmx00ECaLvj7HLM6zZjScqwnGQ6ttjLt33lFYIwgxope2PBc T8g2lhsIq7wukpUXh/knFuXtkXkJqM22IbMWcaIPs6FAHF4q+0oB2/TiBGsjpSbn6pvf swKT0NHSYBC/j0QH0Pf2nhdEveL4v4qd+TXYGGnpRfOnePlItiWGsusxS3EO2xiTMk/T whPHrMLLkXGOH7vhmnlhP7xq04CIgWaTFfvNs2yhMDdrltFt/oZywZP4Bq4QULnY9Kxi BjKAPh5fcFfc3FFpugAwF5rfE8YJRoQ0EBAWJpQdxmD5t1nGQKWQUocDvpo/IqV/+96l j6Fw== 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=TfHegkR0Wd/spg8aTbHd8G6+L4MBK8CYXLAw/Y9T71A=; b=Q1QieUK0nqhh0CZWDL1/VJxSrd8Wrt4s9O/cUEqAs0aLOzjj0GUy6+MRwsh4cDP+xZ 300dZZ1GSUPMnp7eiS3xjfYrxyoEqyj0W0bfnVww97Y/HWHZahuzimnVmB/PXQnNqVCQ uYpgblLohr2FD3HNIrAzVQEIqrZz8FlClvynFbh6sBHWKB/Mouv/ocSZBQox3ROM3Tjl Dd44e2HBDNzrPdIqHA9RtgQiU1D9WWGNWUz3vQkw3bhqdRHxmR+UpDhIoiyx02N+m42R OdxiaHPvhYXky+ASsqLlAIcss/SYXhxpOvhHoMhnh5me7NXGbJzgXxXMwbrW0mPBTHg/ gV4A== X-Gm-Message-State: ALoCoQnv6MnJ1kYOQdnHyrU2p1cvFkI+vi41KCte/iWRb+BO068zIe7uyQTrmfY2BtuTrVsIVCKp MIME-Version: 1.0 X-Received: by 10.60.65.170 with SMTP id y10mr15774877oes.36.1448590334768; Thu, 26 Nov 2015 18:12:14 -0800 (PST) Received: by 10.76.171.103 with HTTP; Thu, 26 Nov 2015 18:12:14 -0800 (PST) X-Originating-IP: [148.87.19.218] In-Reply-To: References: <20151126191525.GB3728@LK-Perkele-V2.elisa-laajakaista.fi> <201511262039.01452.davemgarrett@gmail.com> Date: Fri, 27 Nov 2015 10:12:14 +0800 Message-ID: From: Xuelei Fan To: Dave Garrett Content-Type: multipart/alternative; boundary=001a11c21194544db405257c38a8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Extensions "supported_groups" and "key_share" in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2015 02:12:16 -0000 --001a11c21194544db405257c38a8 Content-Type: text/plain; charset=UTF-8 On Fri, Nov 27, 2015 at 9:48 AM, Xuelei Fan wrote: > > > > I think, key_share is ordered too. If considering both key_share and >> > supported_groups together, looks like there are two options >> [...] >> >> Yes, I addressed the conflict of priorities in one of my PRs, but it's on >> my todo list to rewrite it as ekr noted a few parts that needed changing. >> We agreed on simply making the two orders be required to be the same, >> though at "SHOULD"-level requirement. Those that have them differ will be >> dealt with at the implementations' discretion. >> >> Requiring the two order the same would triage order checking. It may be > easier that the key_share does not define the order. > I may miss something. Can key_share offers two shares for the same group? For example, two DH public values (dh_Y) for the ffdhe2048? If yes, the key_share order is necessary. Otherwise, I think it is more simple to remove the order requirement of shares. Thanks, Xuelei --001a11c21194544db405257c38a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Fri, Nov 27, 2015 at 9:48 AM, Xuelei Fan <xuelei.fan@vimino.com> wrote:


> I think, key_share is ordered too.=C2=A0 If considering both= key_share and
> supported_groups together, looks like there are two options
[...]

Yes, I addressed the conflict of priorities in one of my PRs, but it's = on my todo list to rewrite it as ekr noted a few parts that needed changing= . We agreed on simply making the two orders be required to be the same, tho= ugh at "SHOULD"-level requirement. Those that have them differ wi= ll be dealt with at the implementations' discretion.

Requiring the two order the same = would triage order checking.=C2=A0 It may be easier that the key_share does= not define the order.
= I may miss something.=C2=A0 Can key_share offers two shares for the same gr= oup?=C2=A0 For example, two DH public values (dh_Y) for the ffdhe2048?=C2= =A0 If yes, the key_share order is necessary.=C2=A0 Otherwise, I think it i= s more simple to remove the order requirement of shares.

Thanks,
Xuelei

--001a11c21194544db405257c38a8-- From nobody Thu Nov 26 18:38: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 C5CF81B3139 for ; Thu, 26 Nov 2015 18:38:46 -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, 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 3M0HCxQXLQO7 for ; Thu, 26 Nov 2015 18:38:46 -0800 (PST) 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 DBBDD1B3138 for ; Thu, 26 Nov 2015 18:38:45 -0800 (PST) Received: by obbbj7 with SMTP id bj7so73406972obb.1 for ; Thu, 26 Nov 2015 18:38:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vimino-com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to:content-type; bh=r+vHBMWk3e3MaWiIOnM+JCNF6khoEKc1D9vIUe0pWwA=; b=QyC1WshxSR3L179juBlCizKO18qzCrBnrf8AEJw746nChkftoNLBOC/ZqZFz0Zq4oz zU+pnY+wBsGy4ivA6DoFCKW/h/YGE4wuxsS8fnwjv0awnIraYfdpc1wbqURX3UqZadI5 Iq5a/FCG4LG/Qxrs3lPHIVCvz0pe9FRDT8bmH/hFTNXpIencCBI/20SkLeZ2YD+FUtTv 8r9wrdpZVvu5IeIG4TWZYTX++JmRO2Iz6VZNX1ryJTdaw+6n99/Qg0J0sDq4m8PeyMie WHXmTHLvZsCPSPcVO7ImXwtl5+0h2TDiSQTMxrqRp6wm+xXuYU6T+rIwsZ06fuWgnEHW zyRA== 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=r+vHBMWk3e3MaWiIOnM+JCNF6khoEKc1D9vIUe0pWwA=; b=Va0g4HTOGZf92lBT3xmu96TAZsBPx13pKlfVpwUTWks/lHnUBLdz3YQAD6FhjtiuAG B0lWQCFBb26brpAi0m4pjbiDyKIMHvBagiL3B3G3MDEsH9XOkV9GrxEfL+zcjaLpp4gP HqSVEaGYYGWKOIBOMvvbi1tEIa9yAT7h/lSO0XdHqlKG1y5ePBFKAfCV4J9FlkpbddUw HPADTVpBOtF75S/sV66jm8aPZvicBdrmPfMIC1r0lvm5oh5Hba4OdSRUs4QqHrX7anid 8rrMUghKcbYuTgQD5qO2g3kXKOf56ZXH/+PLLK/I4FFCqATzn3gqYZ/lCA/XOKo32dGl Mb1A== X-Gm-Message-State: ALoCoQnfbvGXCOGzfsRnNOjbXU4Z3cBOYM8K8wjct5okuA4GzWohq96nwmYvcg8p/mcuFxjez3yR MIME-Version: 1.0 X-Received: by 10.182.142.170 with SMTP id rx10mr30993252obb.34.1448591925307; Thu, 26 Nov 2015 18:38:45 -0800 (PST) Received: by 10.76.171.103 with HTTP; Thu, 26 Nov 2015 18:38:45 -0800 (PST) X-Originating-IP: [148.87.19.218] Date: Fri, 27 Nov 2015 10:38:45 +0800 Message-ID: From: Xuelei Fan To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11c338b22203af05257c9739 Archived-At: Subject: [TLS] "selected_group" field in HelloRetryRequest in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2015 02:38:46 -0000 --001a11c338b22203af05257c9739 Content-Type: text/plain; charset=UTF-8 Hi, What's the consideration to place selected_group out of the extensions filed in HelloRetryRequest? struct { ProtocolVersion server_version; CipherSuite cipher_suite; NamedGroup selected_group; Extension extensions<0..2^16-1>; } HelloRetryRequest; vs struct { ProtocolVersion server_version; CipherSuite cipher_suite; Extension extensions<0..2^16-1>; // use key_share (empty share) or // supported_group for named groups } HelloRetryRequest; The latter may be more friendly for future extensibility, and easier to implement. For example, FFDHE may be easy to expose to pre-computation issues in the future, and dynamic safe prime groups may be expected at that time. Having the selected_group as an extension might be more flexible to define new replacement. Thanks, Xuelei --001a11c338b22203af05257c9739 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

What's the consideration to pla= ce=C2=A0selected_group out of the extensions filed in=C2=A0HelloRetryReques= t?

=C2=A0 =C2=A0 =C2=A0 struct {
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ProtocolVersion server_version;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CipherSuite cipher_suite;
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 NamedGroup selected_group;
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Extension extensions<0..2^16-1>;
=C2=A0 =C2=A0 =C2=A0 } HelloRetryRequest;

<= div>vs

=C2=A0 =C2=A0 =C2=A0 struct {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ProtocolVersion server_version;
<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CipherSuite cipher_suite;
<= div>

<= div>Thanks,
--001a11c338b22203af05257c9739-- From nobody Thu Nov 26 18:39: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 708F21A86F0 for ; Thu, 26 Nov 2015 18:39:36 -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 QcOg9V76LjET for ; Thu, 26 Nov 2015 18:39:35 -0800 (PST) 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 2077A1A70FD for ; Thu, 26 Nov 2015 18:39:35 -0800 (PST) Received: by qgec40 with SMTP id c40so64875068qge.2 for ; Thu, 26 Nov 2015 18:39:34 -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=ccUGM7tE9AYOWhDYbeQ1+OlrsBVB0cF7rvKjq2LHc6I=; b=o9i3X8gO+AJkjxY8AV7KVglgTUVxDjyW/ww1xVHbcbL8HQhk3NbW3TATLSuMPgZpN+ YrbTQDWStbWOXeSvztV8C8yfBU8k/rdrnzinJ8bi2SgKub+75wrYTWWXGr1ao/XJ4IIn DoJtGDxkSUzY21UUuYdseCi4BGBisoeL1oz5tL7mntyhQYEMHUIra6qiD9OXffRTiUbj 4Qi1I/dJ43IW4OoBwSsu3aR3dhKl1+MkZxYbgklhgBtTqKnA92aP3DAR8koW6+l0Wgqt xLE0djpdbcX4BO4s4gjqCRTs0cyVmZs69sDNW3loDU9fdwym1Q6E3bXdnnJ39BsDIHDc ILhA== X-Received: by 10.140.105.36 with SMTP id b33mr39832253qgf.94.1448591974402; Thu, 26 Nov 2015 18:39:34 -0800 (PST) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id r71sm5511456qha.9.2015.11.26.18.39.33 (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 26 Nov 2015 18:39:33 -0800 (PST) From: Dave Garrett To: Xuelei Fan Date: Thu, 26 Nov 2015 21:39:32 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201511262139.32824.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Extensions "supported_groups" and "key_share" in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2015 02:39:36 -0000 On Thursday, November 26, 2015 09:12:14 pm Xuelei Fan wrote: > Can key_share offers two shares for the same group? It's currently worded "Clients MUST NOT offer multiple KeyShareEntry values for the same parameters", which is a little ambiguous, but I interpret this as one share per group. I don't know why you'd need to offer more than one, anyway. Dave From nobody Thu Nov 26 18:50: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 8B44D1A889D for ; Thu, 26 Nov 2015 18:50:42 -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, 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 dgHxBO3rCpVU for ; Thu, 26 Nov 2015 18:50:41 -0800 (PST) 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 995A61A88A4 for ; Thu, 26 Nov 2015 18:50:40 -0800 (PST) Received: by oige206 with SMTP id e206so55056298oig.2 for ; Thu, 26 Nov 2015 18:50:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vimino-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HE3/5c1ruChzSz+dB0XC2t4+xwTe5aUBWoeZlkyzzzI=; b=tuiRQ4KcKoLe1V7oB4nh6UAGqIpMZbBfls/JU7GuPBpz9RaRbT7Og9gykkVhX/Fj/T iIdRKz3Fd55bJQduZt74eW/DVwjgt07gM4HzGAmDbaZkp4luD/rIUqdJRJYsjEsL6nws WxT0s1og2FkphRl9abNP5dCh+fKmu+mEmW7+X/c1jQkL0fV5J2ev6lMLPhNzEp6ytvlu 6t4GdvJ9D12ziGrq/OuiamvOq6Ieyoooxs9MY1rBXkhjJyQC/alEfsOBK9No38SEpl2S euUQs3JbWelynPWkknJEdtzdTQIKvwMB0KFNkmdB/e3Cp/PF6G7SFNTYFlTsODxpikif M8Hw== 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=HE3/5c1ruChzSz+dB0XC2t4+xwTe5aUBWoeZlkyzzzI=; b=BPFwnpiFXDwySWGFYZ6BDaC90KOdDM4WjFi9A5eliZSF9yiTpQzjSMvKBMlVApAM5b fjEfl8sGEyeQyvlmrwIq4CYVFkxcD7CB8CbLE7xK1eCW5qEqurdj8r1wlRpj7NAoJEou ckwN8azNRL10Si0M+sxiaaNd/SuKO+X2Q5gbqYPTOtRnrIxMpRoKr2EG5oi3dygwSltp zDk0GDPWg0nOudCx9AJ9q+/pvK4OqGTXYZOokTMXYXx2H+nT1b6w7VqPRL2/O9umOrrD pDVHG98GS2KujB6wzO/NXEWDPlpqOh+Azv6N10O4wstthXSVye6IpxdiZNQ+gG17m//I guFw== X-Gm-Message-State: ALoCoQmhcrEvvUSqPolxMxK+91gOn4jNiSw1qvRZ1VuKK7sl7jk8spb5bO/wcbB8RpOC0DW+uNIn MIME-Version: 1.0 X-Received: by 10.202.215.195 with SMTP id o186mr17339119oig.87.1448592640107; Thu, 26 Nov 2015 18:50:40 -0800 (PST) Received: by 10.76.171.103 with HTTP; Thu, 26 Nov 2015 18:50:40 -0800 (PST) X-Originating-IP: [148.87.19.218] In-Reply-To: <201511262139.32824.davemgarrett@gmail.com> References: <201511262139.32824.davemgarrett@gmail.com> Date: Fri, 27 Nov 2015 10:50:40 +0800 Message-ID: From: Xuelei Fan To: Dave Garrett Content-Type: multipart/alternative; boundary=001a113d5310bcfeb005257cc18f Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Extensions "supported_groups" and "key_share" in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2015 02:50:42 -0000 --001a113d5310bcfeb005257cc18f Content-Type: text/plain; charset=UTF-8 > On Thursday, November 26, 2015 09:12:14 pm Xuelei Fan wrote: > > Can key_share offers two shares for the same group? > > It's currently worded "Clients MUST NOT offer multiple KeyShareEntry > values for the same parameters", which is a little ambiguous, but I > interpret this as one share per group. I don't know why you'd need to offer > more than one, anyway. > > Need no more than one. Then, it may be more simple that key_share does not define the preference order. The preference order is covered by supported_groups. Thanks, Xuelei --001a113d5310bcfeb005257cc18f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

=
On Thursday, November 26, 2015 09:12:14 p= m Xuelei Fan wrote:
> Can key_share offers two shares for the same group?

It's currently worded "Clients MUST NOT offer multiple KeyS= hareEntry values for the same parameters", which is a little ambiguous= , but I interpret this as one share per group. I don't know why you'= ;d need to offer more than one, anyway.

Need no more than one.=C2=A0 Then, it may be more simple that=C2=A0key_share does not define the= preference order. The preference order is covered by=C2=A0supported_groups.

Thanks,
Xuelei
--001a113d5310bcfeb005257cc18f-- From nobody Fri Nov 27 03:58: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 6AB6A1B3337 for ; Fri, 27 Nov 2015 03:58:47 -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, 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 FjAcGivtAcfs for ; Fri, 27 Nov 2015 03:58:46 -0800 (PST) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003: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 EFF8A1B3334 for ; Fri, 27 Nov 2015 03:58:45 -0800 (PST) Received: by obbnk6 with SMTP id nk6so81009096obb.2 for ; Fri, 27 Nov 2015 03:58:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vimino-com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to:content-type; bh=C3pfacK2s9Tlw2QbBoD3fTTVEFsg5v0e99Optu6Nvm4=; b=lNaiYge2TpllqsLJPTmYRHckFG0o6XF1lKp7UhUjMaiSOa/xVyaaqkpyIMav09y8+E UxEjaW9a5nKud9YPwuosGpwtbiBnvxSwGqi64Zw5cp1a9WOUrr1dRQFIUuaxPnnO17I3 s0/FsSGwBh6oPHig+tOKGhzR+P6Ztyu88sNUYVFaaKLCRMojnN1K6W8Oa4LTMtotuhgu nfee5L6XU7So9TDZkIUFPSE6cnE8w54UrMuMJC+nOp3ikG9kkl44zS2+1uWssDIXqKwR XERoRkNauwb6DRG8LiQJtBPHIewcPl/UqtSUBPIfdt/+fflf6gspFt9a5qnFskWV0uaa a3fw== 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=C3pfacK2s9Tlw2QbBoD3fTTVEFsg5v0e99Optu6Nvm4=; b=i8w6AWy3IiC+HW1SpMgJVEvIIp0CwsjCo7ReCAG2JbY48dgX1jMHg4wovAUfU7VCgf iLwxdlvfD94w+QYRwVYZA4LoM/3iOuXOdUgS/MAkw/QUyEkeHFh/ZsRj5QtTW6rWMhrN Zhd9pVINKsNSwGT8RmYnnyelebqg/9T5blvjgWDrOhuP261Mf4qJ+j1FfnIpd+wSDwjY JHKXafaHbyX45M/sACU8JCjqja1ARfpS1H0xajmFgVQfkJKgPyx9BEqxBdGVZAg+N2m0 CpOpi5VjX2/NKMhVnSxrszKs2Ssnzx+1sM1IzzXMZJ3RtilihauCb1KA4jaDZE+DdkYE chow== X-Gm-Message-State: ALoCoQnNN08k/mD9fGxi1u9aYzFmLbIbOQqrdsjJ3/NhSVUR7/XlFLWbJ321pdI1uk+YVpzL2j7L MIME-Version: 1.0 X-Received: by 10.60.65.170 with SMTP id y10mr17373930oes.36.1448625525169; Fri, 27 Nov 2015 03:58:45 -0800 (PST) Received: by 10.76.171.103 with HTTP; Fri, 27 Nov 2015 03:58:45 -0800 (PST) X-Originating-IP: [148.87.19.214] Date: Fri, 27 Nov 2015 19:58:45 +0800 Message-ID: From: Xuelei Fan To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11c21194d73c7b05258469ea Archived-At: Subject: [TLS] TLS 1.3 and RFC 4279, Pre-Shared Key Ciphersuites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 11:58:47 -0000 --001a11c21194d73c7b05258469ea Content-Type: text/plain; charset=UTF-8 Hi, In the draft spec of TLS 1.3, ServerKeyExchange and ClientKeyExchange get removed, and key_share extension applies to non-PSK cipher suites only. As RFC 4279 need ServerKeyExchange and ClientKeyExchange messages, I think TLS 1.3 updates or obsoletes RFC 4279. Per the draft spec of TLS 1.3, if no suitable identity is provided in pre-shared key extension, the server MUST NOT negotiate a PSK cipher suite. The question comes to me: where the suitable identity comes from? The identity can be acquired by out-of-band approach, or the server NewSessionTicket message. If no out-of-band approach in some circumstances, the server NewSessionTicket message would be the only way to create the identity. The scenarios of using pre-shared key may look like: 1. establish a fresh connection, server sends the NewSessionTicket to indicate it supports session resumption and provide the psk_identity. 2. if client wants a session resumption, subsequent handshaking will use pre_shared key extension with the server provided psk_identity. Looks like PSK applies to session resume only in TLS 1.3, and cannot be used for fresh (initial) handshaking any more, unless out-of-band approach is used to define the identities. I have no experience on PSK, but looks like that it is not A minimal effort for PSK deployments to upgrade from TLS 1.2 to TLS 1.3, if ServerKeyExchange.psk_identity_hint is used previously. It would be nice to consider and specify the impact on RFC 4279 in TLS 1.3 protocols. Regards, Xuelei --001a11c21194d73c7b05258469ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

In the draft spec of TLS 1.3, Serve= rKeyExchange and ClientKeyExchange get removed, and key_share extension app= lies to=C2=A0non-PSK cipher suites only. As RFC 4279 need ServerKeyExchange= and ClientKeyExchange messages, I think TLS 1.3 updates or obsoletes RFC 4= 279.

Per the draft spec of TLS 1.3, if no suitable= identity is provided in pre-shared key extension,=C2=A0the server MUST NOT= negotiate a PSK cipher suite.=C2=A0 The question comes to me: where the su= itable identity comes from?=C2=A0 The identity can be acquired by out-of-ba= nd approach, or the server NewSessionTicket message.=C2=A0 If no out-of-ban= d approach in some circumstances, the server NewSessionTicket message would= be the only way to create the identity.=C2=A0 The=C2=A0scenarios of using = =C2=A0pre-shared key may look like:
1. establish a fresh connecti= on, server sends the NewSessionTicket to indicate it supports session resum= ption and provide the psk_identity.
2. if client wants a session = resumption, subsequent handshaking will use pre_shared key extension with t= he server provided psk_identity.

Looks like PSK ap= plies to session resume only in TLS 1.3, and cannot be used for fresh (init= ial) handshaking any more, =C2=A0unless out-of-band approach is used to def= ine the identities.=C2=A0 I have no experience on PSK, but looks like that = it is not A minimal effort for PSK deployments to upgrade from TLS 1.2 to T= LS 1.3, if ServerKeyExchange.psk_identity_hint is used previously.

It would be nice to consider and specify the impact on RFC= 4279 in TLS 1.3 protocols.

Regards,
Xue= lei
--001a11c21194d73c7b05258469ea-- From nobody Fri Nov 27 04:12: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 A27491B3369 for ; Fri, 27 Nov 2015 04:12:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.486 X-Spam-Level: X-Spam-Status: No, score=-7.486 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-UhWMmlITnF for ; Fri, 27 Nov 2015 04:12:42 -0800 (PST) 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 D9CA51B3368 for ; Fri, 27 Nov 2015 04:12:42 -0800 (PST) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 6F65768E0C; Fri, 27 Nov 2015 12:12:42 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-112-54.ams2.redhat.com [10.36.112.54]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tARCCbjp027079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Nov 2015 07:12:41 -0500 From: Hubert Kario To: tls@ietf.org Date: Fri, 27 Nov 2015 13:12:35 +0100 Message-ID: <5330051.tMbHWVtgER@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.2.6-200.fc22.x86_64; KDE/4.14.14; x86_64; ; ) In-Reply-To: References: <201511262139.32824.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1669306.B4Ul1fYFoV"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: Subject: Re: [TLS] Extensions "supported_groups" and "key_share" in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2015 12:12:44 -0000 --nextPart1669306.B4Ul1fYFoV Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Friday 27 November 2015 10:50:40 Xuelei Fan wrote: > > On Thursday, November 26, 2015 09:12:14 pm Xuelei Fan wrote: > > > Can key_share offers two shares for the same group? > >=20 > > It's currently worded "Clients MUST NOT offer multiple KeyShareEntr= y > > values for the same parameters", which is a little ambiguous, but I= > > interpret this as one share per group. I don't know why you'd need > > to offer more than one, anyway. > >=20 > Need no more than one. Then, it may be more simple that key_share > does > not define the preference order. The preference order is covered by > supported_groups. What would then be the expected behaviour of the server if the first=20= group in the supported_groups does not have a associated key share? that is, I advertise support for secp384r1, secp256r1 or ffdhe2048, but= =20 I provide only secp256r1 key share as it's the one that's most widely=20= supported Should the server ask me to provide a secp384r1 key share or should it=20= just proceed with secp256r1? I think that specifying *both* in preference order, and recommending th= e=20 servers to first inspect key shares and then supported_groups (if no=20= intersect between what server supports and what key shares client=20 provided) would end up with more predictable behaviour and cleaner code= . That being said, we probably should say that clients MUST advertise=20 support for all groups for which they send key shares and servers MUST=20= abort connection with something like illegal_parameter if that happens =2D-=20 Regards, Hubert Kario Senior 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 --nextPart1669306.B4Ul1fYFoV 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 iQIcBAABCgAGBQJWWEizAAoJEJKo0bgB0vX1A28P/jczLfwLRIXsf6FSylbU6ulK EfVmvlIqVrl420MvjNm7maZE2gv3fHUF8+RHZ+CI+S6A2cKsgZ5K/wZigz0+6xsy /DiTWFkDmq9DL6qQ1N9ZSNIpjuUqEEWkVisHqiivHTuoK4QdRGjDGP467JV1clBu PMQg+X30qFwTYXPurXX3HRJoYOC/vuAD5a6JgLlr4+MnMyGPT/SkzDI/QAxyUkdW pIAOKYroDdFjjWfsbqLNbYd/I0is03KeqWjdNcxqgIn7TGHBntX7lW/cMjtvH5qY GBw3GIo4AFEJLhKE718DCcl0kO/TQdUO/gQ+Jbv+4WWKTG8fC8FWwf1RrEYtyLRT I09oZp76M54BBbQXkUPNlbwQeEc8WkhAO4/TnjC4q4HGbV6tH0zlSiwvLrT8gqgZ 2x4PQrXC0cghAr4hc3ABc2LHmhUoplPFjVjXh3yqtYzPwaat3+EALTDyckYkcUKf qal2vaL9AiZfvgFwVsgWc6Yy/BPTgrSVOcPdpjyiNVoyNeAY2memyOW9f1vyFlgm aTC6BaJO/0wa2vE8lVeiJxjlabMJqSoetIVadUep7bg4/4ZzYzJZCJSPfyOcmgVZ yeOlga1j9gMpdXHl3rElhLmbH0rm82Jhbp5zpsobXyjl1xF3kl7vg16OQ+5SliaC hIy/csCxCLq7xpYTp5mp =264L -----END PGP SIGNATURE----- --nextPart1669306.B4Ul1fYFoV-- From nobody Fri Nov 27 04:33: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 F0C8E1B33D1 for ; Fri, 27 Nov 2015 04:33:48 -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, 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 JCSvo8AkVZXb for ; Fri, 27 Nov 2015 04:33:47 -0800 (PST) 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 743B71B33D0 for ; Fri, 27 Nov 2015 04:33:47 -0800 (PST) Received: by oige206 with SMTP id e206so61009123oig.2 for ; Fri, 27 Nov 2015 04:33:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vimino-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=W4vKrBA1lw5pCSMo+9IatAlYSW6f4sTQjUjTbjy/yh0=; b=fLUK/K1uP5OiUZYhWMMPC6D5WzDwIgAOBihe9vCd+uVoidHdnSL8g7Jqf6qn+Mzvgk AGjaFPhrq0hZQzODKWLl7VWw3Pt291MqPFqjdq9VxiYbkbfqoPyMZoox+8AQvnt5lhrU TLze7dyhcKgY41M3rj4AFx6Q4dPs3LXdiNOCLUZotRaXute7Z0eLsw4fvZoLkr5fpp8u QXaabPAjwtyfJnFn5skWRrPK8Xn6AK/tRG3x8AMOwk+RHdJxhXarNf57QgnGb/EMRZnD tpmBE243EP6RIxEZfY3VfuM8Gtiihzq1PjWgp+RXLQqasyh38NnjoME6aielbqh/Mp0Q moFw== 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=W4vKrBA1lw5pCSMo+9IatAlYSW6f4sTQjUjTbjy/yh0=; b=ZaptEp7tsIKDxTOJWqXDdGIw8DEnCma/Ct/8GX7fJ1pe3PSKTwLjz/9xNiCMWr8OOE tMcApKhjNHypLaoEyu4YmqqmjOyJaKQIYKl1+WINOytDjDr6nAl3TT7wLkG2bO3GIZJ1 KJJotpuaFX80y2KLf397ft8EDc5EIGISzQPnSnuCkyyaGV2rWCvGTjhXXLxhdqAg7dNt +7K4J5WxnVzM+km808KJZ+jyoJ94Y23439DYKz7aPEimtaimWqt0q2nnT7Uuumjvkzw6 HBSHHKPgkjG5rapeJcx3llFp7Lhoe5SIx9RpyKmbsiNjsDyOekIsWLGneMhl+ycyzM3+ UV4A== X-Gm-Message-State: ALoCoQlkYM42fEaWPnAqXdFSejQLKBkITR0xKwkb2bflUEFHIcnkEyqVpd4OV2OzdUVa61zNZWyc MIME-Version: 1.0 X-Received: by 10.202.215.195 with SMTP id o186mr18929413oig.87.1448627626857; Fri, 27 Nov 2015 04:33:46 -0800 (PST) Received: by 10.76.171.103 with HTTP; Fri, 27 Nov 2015 04:33:46 -0800 (PST) X-Originating-IP: [148.87.19.214] In-Reply-To: <5330051.tMbHWVtgER@pintsize.usersys.redhat.com> References: <201511262139.32824.davemgarrett@gmail.com> <5330051.tMbHWVtgER@pintsize.usersys.redhat.com> Date: Fri, 27 Nov 2015 20:33:46 +0800 Message-ID: From: Xuelei Fan To: Hubert Kario Content-Type: multipart/alternative; boundary=001a113d53101c6c4c052584e78b Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Extensions "supported_groups" and "key_share" in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2015 12:33:49 -0000 --001a113d53101c6c4c052584e78b Content-Type: text/plain; charset=UTF-8 On Fri, Nov 27, 2015 at 8:12 PM, Hubert Kario wrote: > On Friday 27 November 2015 10:50:40 Xuelei Fan wrote: > > > On Thursday, November 26, 2015 09:12:14 pm Xuelei Fan wrote: > > > > Can key_share offers two shares for the same group? > > > > > > It's currently worded "Clients MUST NOT offer multiple KeyShareEntry > > > values for the same parameters", which is a little ambiguous, but I > > > interpret this as one share per group. I don't know why you'd need > > > to offer more than one, anyway. > > > > > Need no more than one. Then, it may be more simple that key_share > > does > > not define the preference order. The preference order is covered by > > supported_groups. > > What would then be the expected behaviour of the server if the first > group in the supported_groups does not have a associated key share? > > Try the next group in the supported_groups until find an associated key share. > that is, I advertise support for secp384r1, secp256r1 or ffdhe2048, but > I provide only secp256r1 key share as it's the one that's most widely > supported > > Should the server ask me to provide a secp384r1 key share or should it > just proceed with secp256r1? > > I think, it would be better to proceed with secp256r1. > I think that specifying *both* in preference order, and recommending the > servers to first inspect key shares and then supported_groups (if no > intersect between what server supports and what key shares client > provided) would end up with more predictable behaviour and cleaner code. > > But if the orders are not consistent, the logic get annoyed. It's a good practice to keep the order consistent, but it would be better if the preference order is unique and specified in one place. > > That being said, we probably should say that clients MUST advertise > support for all groups for which they send key shares and servers MUST > abort connection with something like illegal_parameter if that happens > This adds additional checking on both client and server. Personally, I would prefer to use one preference order in order to avoid any order conflict. Thanks & Regards, Xuelei --001a113d53101c6c4c052584e78b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Nov 27, 2015 at 8:12 PM, Hubert Kario <hkario@redhat.com&g= t; wrote:
On Friday 27 November= 2015 10:50:40 Xuelei Fan wrote:
> > On Thursday, November 26, 2015 09:12:14 pm Xuelei Fan wrote:
> > > Can key_share offers two shares for the same group?
> >
> > It's currently worded "Clients MUST NOT offer multiple K= eyShareEntry
> > values for the same parameters", which is a little ambiguous= , but I
> > interpret this as one share per group. I don't know why you&#= 39;d need
> > to offer more than one, anyway.
> >
> Need no more than one.=C2=A0 Then, it may be more simple that key_shar= e
> does
> not define the preference order. The preference order is covered by > supported_groups.

What would then be the expected behaviour of the server if the first=
group in the supported_groups does not have a associated key share?

Try the next =C2=A0group in the supported_groups unti= l find an associated key share.

=C2=A0
that is, I advertise support for secp384r1, secp256r1 or ffdhe2048, but
I provide only secp256r1 key share as it's the one that's most wide= ly
supported

Should the server ask me to provide a secp384r1 key share or should it
just proceed with secp256r1?

I think, it would be better to proceed with secp256r1= .

=C2=A0
I think that specifying *both* in preference order, and recommending the servers to first inspect key shares and then supported_groups (if no
intersect between what server supports and what key shares client
provided) would end up with more predictable behaviour and cleaner code.
But if the orders are not consistent, the logic get a= nnoyed.=C2=A0 It's a good practice to keep the order consistent, but it= would be better if the preference order is unique and specified in one pla= ce.
=C2=A0

That being said, we probably should say that clients MUST advertise
support for all groups for which they send key shares and servers MUST
abort connection with something like illegal_parameter if that happens
<= /blockquote>
This adds additional checking on both client and server.= =C2=A0 Personally, I would prefer to use one preference order in order to a= void any order conflict.

Thanks & Regards,
Xuelei
--001a113d53101c6c4c052584e78b-- From nobody Fri Nov 27 04:44: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 CCA1F1B33DA for ; Fri, 27 Nov 2015 04:44:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.486 X-Spam-Level: X-Spam-Status: No, score=-7.486 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dh9k4VM5D6NZ for ; Fri, 27 Nov 2015 04:44:38 -0800 (PST) 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 7A6A01B2EE1 for ; Fri, 27 Nov 2015 04:44:38 -0800 (PST) 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 (Postfix) with ESMTPS id 3A918743; Fri, 27 Nov 2015 12:44:38 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-112-54.ams2.redhat.com [10.36.112.54]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tARCiXt8003770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Nov 2015 07:44:37 -0500 From: Hubert Kario To: Xuelei Fan Date: Fri, 27 Nov 2015 13:44:21 +0100 Message-ID: <1786049.OYDTVEIchY@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.2.6-200.fc22.x86_64; KDE/4.14.14; x86_64; ; ) In-Reply-To: References: <5330051.tMbHWVtgER@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1468959.Qnv9nnF9Gh"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Extensions "supported_groups" and "key_share" in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2015 12:44:40 -0000 --nextPart1468959.Qnv9nnF9Gh Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Friday 27 November 2015 20:33:46 Xuelei Fan wrote: > On Fri, Nov 27, 2015 at 8:12 PM, Hubert Kario =20 wrote: > > On Friday 27 November 2015 10:50:40 Xuelei Fan wrote: > > > > On Thursday, November 26, 2015 09:12:14 pm Xuelei Fan wrote: > > > > > Can key_share offers two shares for the same group? > > > >=20 > > > > It's currently worded "Clients MUST NOT offer multiple > > > > KeyShareEntry > > > > values for the same parameters", which is a little ambiguous, > > > > but I > > > > interpret this as one share per group. I don't know why you'd > > > > need > > > > to offer more than one, anyway. > > >=20 > > > Need no more than one. Then, it may be more simple that key_shar= e > > > does > > > not define the preference order. The preference order is covered > > > by > > > supported_groups. > >=20 > > What would then be the expected behaviour of the server if the firs= t > > group in the supported_groups does not have a associated key share?= > >=20 > Try the next group in the supported_groups until find an associated > key > share. > > > I think that specifying *both* in preference order, and recommendin= g > > the servers to first inspect key shares and then supported_groups > > (if no intersect between what server supports and what key shares > > client provided) would end up with more predictable behaviour and > > cleaner code. > >=20 > But if the orders are not consistent, the logic get annoyed. It's a > good > practice to keep the order consistent, but it would be better if the > preference order is unique and specified in one place. that means that the code needs to keep references to two arrays at the=20= same time and either create a hash table for lookups in key shares or=20= iterate over key shares for every try - this makes code and logic more=20= complex, not less > > That being said, we probably should say that clients MUST advertise= > > support for all groups for which they send key shares and servers > > MUST abort connection with something like illegal_parameter if that= > > happens > This adds additional checking on both client and server. Personally,= > I would prefer to use one preference order in order to avoid any > order conflict. not the first, and certainly not the last checks that need to be done t= o=20 implement TLS securely... =2D-=20 Regards, Hubert Kario Senior 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 --nextPart1468959.Qnv9nnF9Gh 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 iQIcBAABCgAGBQJWWFAlAAoJEJKo0bgB0vX1ymkP/ji4tkTuU2p7ILkgYVdwu2pj VtZ3Se5maLvBXGL700DZ8d4nhGPYg0ih0bWv8ZgB2PIlDLXFF8wtar4lJ9Vo2xTD htd7qg5Bn+qz1uny2aRdyEXairnCVVSAV7a3tXu+ejqPjLB5Oy/P31G0PXkhNtBM tB9nrB/VfAAkAmkvpXxMzEPRBJstRzRGSF+zyttY58tNatq93EKFqzSvBv0xJNJu vBDjCJQFBk4eYM1raTqeNosMxY8wp1FYywytcQco48zOgR45hxlugcjFS+SQa+Pt 3q0poSzAjuJ/0SxWIPLqC6lkUYpI7CHQOsdAuuyZWGVHOsXU5vt429TBchLduLT7 Z7NZ1Z4hW7MMpUh4wtcnco+lk4NQKXoHk36Fv//8mA7Gk7x6uN6rWZzLFV5/nG5i koOipXMIbbtyrHdR0aVb0Pd1+e0jbQ6KhFFxu0sJQpVt7koI+YzL9OSvIJqimgnV WA+PFJPd6bdfNi+TBa+iLSOcB3RXYsbi/z8LN2r436D7MYSpuHWIbPrTCAelqKto dVCJTGSBMrO/54VbB482AkOfyrM545le0ch297N4m6Vxjg2cEV7a0Rduf2/RjX/M KKiArtDpXpHE3wbMCFrLopp8MLTJeStTURPs1LpBVLLwx7fIB0CC0me1b8hEEqR2 Z/UY5qGCyjMGOBu8NWkY =pYWD -----END PGP SIGNATURE----- --nextPart1468959.Qnv9nnF9Gh-- From nobody Fri Nov 27 05:20: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 374F81A038D for ; Fri, 27 Nov 2015 05:20:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gv0E0XiFLqPI for ; Fri, 27 Nov 2015 05:20:25 -0800 (PST) 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 677FB1A038C for ; Fri, 27 Nov 2015 05:20:25 -0800 (PST) Received: by obbww6 with SMTP id ww6so82549493obb.0 for ; Fri, 27 Nov 2015 05:20:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vimino-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KVhazP1L/D35UwuEf/Ir4fw8ANBmyz09RAPoo7U6N/Q=; b=y/aEGVYuMwLTJH2S3oAN0W9nNuA+Yy8Bvrdk/p7yLHJNqosGe+z8FPIkZExdwWPrIJ i29FILMJbjG4GIgEqtFlRBAIl9O6HBMW9ddMcyRy36JJW05xupLlIntrEfNefGS4Gosd CMgDfLf9+pQ617zmGgHaaFFZHqenMEMrEdCH3Soy7sD3SjCMy3zZPs4qbEyDlz1+HCye Fe9NgZx0lgKwfwJdIrXAWfoT2omgZLI1l9MeejoGoMv2H80oeFDc6/o41khUrSedprYR ltsCqLTZzK4mp+XreOXEnXFZi8pDHbw9nxAkWcooARA7K3CBQbvtKH1DJMZlRJPEMEzv IoLg== 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=KVhazP1L/D35UwuEf/Ir4fw8ANBmyz09RAPoo7U6N/Q=; b=LB4ntqu9c4Dc3uFTXvVrC0ac8w6bDhzYAuti0eHeymkqvu3hL1zQCccmbPvLbzdu/o TZGaWjOd8+zPtFTaXi+S1V4gk/l3WsQ8RcDQlsu/uBktSjpDRw0cZVZEX2yRC5TS6mQd I8KmzMKSI6Ha6NzMEpFH+YBLhnyMq6I8eFJYT5McG0fGhJRIUvrtbnT502BY+bm5UE3H vmDeBTo3t3f/8NetzcK9JOSGRWbMyRq3jK0UjGKbTrp+Q5z6g5LaYs9FhDgNR/KyrEPq 6tevdNoL5HsU0Il6Au2mTHIeI+4QUMwqwFId62RjI5Md9Z0mClM5js6FU4Ui8nj28CH+ 677Q== X-Gm-Message-State: ALoCoQmd5LRqGQzWds7BdnQu2gtvHj7H/E9i7+AMZ5zYE91sbj/d273QvjAc2frZu1Jg/ysN7uka MIME-Version: 1.0 X-Received: by 10.182.142.170 with SMTP id rx10mr32825890obb.34.1448630424699; Fri, 27 Nov 2015 05:20:24 -0800 (PST) Received: by 10.76.171.103 with HTTP; Fri, 27 Nov 2015 05:20:24 -0800 (PST) X-Originating-IP: [148.87.19.214] In-Reply-To: <1786049.OYDTVEIchY@pintsize.usersys.redhat.com> References: <5330051.tMbHWVtgER@pintsize.usersys.redhat.com> <1786049.OYDTVEIchY@pintsize.usersys.redhat.com> Date: Fri, 27 Nov 2015 21:20:24 +0800 Message-ID: From: Xuelei Fan To: Hubert Kario Content-Type: multipart/alternative; boundary=001a11c338b2e01bbd0525858d5f Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Extensions "supported_groups" and "key_share" in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2015 13:20:27 -0000 --001a11c338b2e01bbd0525858d5f Content-Type: text/plain; charset=UTF-8 > > > > I think that specifying *both* in preference order, and recommending > > > the servers to first inspect key shares and then supported_groups > > > (if no intersect between what server supports and what key shares > > > client provided) would end up with more predictable behaviour and > > > cleaner code. > > > > > But if the orders are not consistent, the logic get annoyed. It's a > > good > > practice to keep the order consistent, but it would be better if the > > preference order is unique and specified in one place. > > that means that the code needs to keep references to two arrays at the > same time and either create a hash table for lookups in key shares or > iterate over key shares for every try - this makes code and logic more > complex, not less > I did not get the idea, can the complex above be avoided if keeping both? Does one preference order just get ignored? If the orders are not consistent, if I can choose from two options: continue or alter, I would choose the continue option. Alert message is expensive in practice. Anyway, minor question, not a big concern to me. Thanks & Regards, Xuelei --001a11c338b2e01bbd0525858d5f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> > I think that specifyi= ng *both* in preference order, and recommending
> > the servers to first inspect key shares and then supported_groups=
> > (if no intersect between what server supports and what key shares=
> > client provided) would end up with more predictable behaviour and=
> > cleaner code.
> >
> But if the orders are not consistent, the logic get annoyed.=C2=A0 It&= #39;s a
> good
> practice to keep the order consistent, but it would be better if the > preference order is unique and specified in one place.

that means that the code needs to keep references to two arrays at t= he
same time and either create a hash table for lookups in key shares or
iterate over key shares for every try - this makes code and logic more
complex, not less
I did not get the idea, can the comp= lex above be avoided if keeping both?=C2=A0 Does one preference order just = get ignored?

If the orders are not consistent, if = I can choose from two options: continue or alter, I would choose the contin= ue option.=C2=A0 Alert message is expensive in practice.

Anyway, minor question, not a big concern to me.

Thanks & Regards,
Xuelei
--001a11c338b2e01bbd0525858d5f-- From nobody Fri Nov 27 05: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 E59C31A09CF for ; Fri, 27 Nov 2015 05:28:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.486 X-Spam-Level: X-Spam-Status: No, score=-7.486 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3SwL1pm-FJXv for ; Fri, 27 Nov 2015 05:28:29 -0800 (PST) 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 B05BD1A079D for ; Fri, 27 Nov 2015 05:28:29 -0800 (PST) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 46389C0D2230; Fri, 27 Nov 2015 13:28:29 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-112-54.ams2.redhat.com [10.36.112.54]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tARDSOUl004369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Nov 2015 08:28:28 -0500 From: Hubert Kario To: Xuelei Fan Date: Fri, 27 Nov 2015 14:28:22 +0100 Message-ID: <2070739.hCTgo4e1DJ@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.2.6-200.fc22.x86_64; KDE/4.14.14; x86_64; ; ) In-Reply-To: References: <1786049.OYDTVEIchY@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1826396.ABeH8XkNi1"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Extensions "supported_groups" and "key_share" in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2015 13:28:32 -0000 --nextPart1826396.ABeH8XkNi1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Friday 27 November 2015 21:20:24 Xuelei Fan wrote: > > > > I think that specifying *both* in preference order, and > > > > recommending > > > > the servers to first inspect key shares and then > > > > supported_groups > > > > (if no intersect between what server supports and what key > > > > shares > > > > client provided) would end up with more predictable behaviour > > > > and > > > > cleaner code. > > >=20 > > > But if the orders are not consistent, the logic get annoyed. It'= s > > > a > > > good > > > practice to keep the order consistent, but it would be better if > > > the > > > preference order is unique and specified in one place. > >=20 > > that means that the code needs to keep references to two arrays at > > the same time and either create a hash table for lookups in key > > shares or iterate over key shares for every try - this makes code > > and logic more complex, not less >=20 > I did not get the idea, can the complex above be avoided if keeping > both? Does one preference order just get ignored? the idea is that if there is a key share acceptable for the server, the= =20 supported_groups can be ignored but to make sure that clients don't start putting complete garbage=20 there, we need to tell servers to check key shares against=20 supported_groups > If the orders are not consistent, if I can choose from two options: > continue or alter, I would choose the continue option. alter what? > Alert message > is expensive in practice. Note that this alert will never be sent to a client that is behaving=20= according to specification unless the packets were modified by the=20 network. It's a sanity check. =2D-=20 Regards, Hubert Kario Senior 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 --nextPart1826396.ABeH8XkNi1 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 iQIcBAABCgAGBQJWWFp2AAoJEJKo0bgB0vX18jcP/0GPDAvOzsDwi2Z4jKuBiWT+ fwIrldYPSiO45cV+qan1C3xT8K/ETowYG1PrSHLQ8VECoWqDaNX5SOr78Qy/CEKe DYBkK0WMXs+jo7UKrqPbYzi3sTjKJB5YLiI1GGUGyA/nMyz/3WAcek50rhS3xGnL PATBWjSo3h0gzUK7u/rRSH84fWY/D7XGGXV631d/yurTgoPJOv7d+KQIffjZpQi2 kDock4+6mhQuajx6rzIyEf7SYHzyXkLRmRPIO4EsU2UetvqGizt08yBG+QnOYGWz s8GE5a7OCX+JApvalONCxWiRApdhjNwlYbiJ/+iCePDBeES6hyPzjbHQ2V0UFltx QwD3qzubEaqrHPcv583AlcLJvIYtrxFNs1HgoUTStRRbOX6GHWHMKyM3XEBj2mwa kHtHUCmitCpsOXFxtoqiEORSbu+KVTXjHhZJje5q6WsqIOfigqxIPDRRZ6G3BbTh CXb3bHPtsgVNwRWg1X3Orc6In5qx3QTYumpd1sgIQzku7EXKqmsDUAVsBsmHHtHe 1MLFp5CRgY3rswM9bNttR3jImmGFCbJlgzIT12ItfosXpIzhO+1R3tjr/o8KswGK t0QUvdff5CHHvqJzYictockV+qQEtJ9+JV2lyzjbDb8at+18IQXgIKRHM8Cpz9F0 EjvhgI48RtfhWq6HxbB3 =rn8o -----END PGP SIGNATURE----- --nextPart1826396.ABeH8XkNi1-- From nobody Fri Nov 27 05:55: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 1DA671A1A98 for ; Fri, 27 Nov 2015 05:55:36 -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, 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 7WFYupNjJg3i for ; Fri, 27 Nov 2015 05:55:34 -0800 (PST) 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 B283D1A1A97 for ; Fri, 27 Nov 2015 05:55:34 -0800 (PST) Received: by obbnk6 with SMTP id nk6so82923290obb.2 for ; Fri, 27 Nov 2015 05:55:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vimino-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=E5f6reIkKyiCvNYptpWm56hU0qLrblnXbsFw3DIhal4=; b=w7rsvztAo7Z1KFaEULQcZ3p7Q/oL+aigkjrYZ26MQ/hmVNrpDnSJT1pVOWV168GsYt lRG2BrutMq83eGBLYUQ1xWjWDojDOStMKd3BUteBSXQ5ogiaNuVCDIMZz3gyE0/iXBLK amYr1vdECzgXSDT2Wdfq9nugvDLbSIMTl8ERE2OdhYTn4a5X89TAMllhZQgt7ldk/ZId B6FLmE1BMNGrNLJDcozHH+LOf/l2/ZkfwuiQE8c54Xhptx7PRsuGi7nRNBo+2wpH2hRd KiH+MYz1240EV7/y5D3Be8pGRq/khvZng3QuZVXuofhBslMnZbgogTboCIn+e88xbjnO BOgw== 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=E5f6reIkKyiCvNYptpWm56hU0qLrblnXbsFw3DIhal4=; b=RxJMAY0Z/l2cki8kmRHNBSqBxodSTR529D4d3c+Zl8IJHNUHNwHxEltmIOv6KmUydG KwgsbhPGQA1bLX0cym1X6GBU9GTYwsUDEjXDcCd4Ieqs7MdrM64pl6439xk8z3UpeeVA GC3CO/5F+mUGcelz25m6kgiU1IqAvt83+ZtX8as40Yc462vGWZOqV/Uq4iaK8nh+0M+u fURoSHW5eDpv2kQh6qHG85zpEWAWwdA3TKbLcbeQ6XXmzTo3I7ieX34z9bluG3eR8M0c 2n4thnarTE4R4aLcryay+ZcWSvhG4+dRKLqUEkJb8K0QTMkXUd20VAOR0Mc+Rx3NhL4a pXMA== X-Gm-Message-State: ALoCoQl6LpwZEgiCOsNq/TSZ+cAHnEn3GZSyAYMIAXAgbnikwYU3/ytF321h/O1ItkbOWxu7H7S2 MIME-Version: 1.0 X-Received: by 10.182.251.170 with SMTP id zl10mr32226905obc.8.1448632534175; Fri, 27 Nov 2015 05:55:34 -0800 (PST) Received: by 10.76.171.103 with HTTP; Fri, 27 Nov 2015 05:55:34 -0800 (PST) X-Originating-IP: [148.87.19.214] In-Reply-To: <2070739.hCTgo4e1DJ@pintsize.usersys.redhat.com> References: <1786049.OYDTVEIchY@pintsize.usersys.redhat.com> <2070739.hCTgo4e1DJ@pintsize.usersys.redhat.com> Date: Fri, 27 Nov 2015 21:55:34 +0800 Message-ID: From: Xuelei Fan To: Hubert Kario Content-Type: multipart/alternative; boundary=001a11c2003e9c2bd30525860bd0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Extensions "supported_groups" and "key_share" in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2015 13:55:36 -0000 --001a11c2003e9c2bd30525860bd0 Content-Type: text/plain; charset=UTF-8 On Fri, Nov 27, 2015 at 9:28 PM, Hubert Kario wrote: > On Friday 27 November 2015 21:20:24 Xuelei Fan wrote: > > > > > I think that specifying *both* in preference order, and > > > > > recommending > > > > > the servers to first inspect key shares and then > > > > > supported_groups > > > > > (if no intersect between what server supports and what key > > > > > shares > > > > > client provided) would end up with more predictable behaviour > > > > > and > > > > > cleaner code. > > > > > > > > But if the orders are not consistent, the logic get annoyed. It's > > > > a > > > > good > > > > practice to keep the order consistent, but it would be better if > > > > the > > > > preference order is unique and specified in one place. > > > > > > that means that the code needs to keep references to two arrays at > > > the same time and either create a hash table for lookups in key > > > shares or iterate over key shares for every try - this makes code > > > and logic more complex, not less > > > > I did not get the idea, can the complex above be avoided if keeping > > both? Does one preference order just get ignored? > > the idea is that if there is a key share acceptable for the server, the > supported_groups can be ignored > > but to make sure that clients don't start putting complete garbage > there, we need to tell servers to check key shares against > supported_groups > > As the check needs additional effort, and the client code also needs additional effort to keep the order consistent, I think the logic may be more complex. Anyway, not a big concern to me. Personally, I prefer one logic one place. > > If the orders are not consistent, if I can choose from two options: > > continue or alter, I would choose the continue option. > > alter what? > > If the preference orders in key_share and supported_groups are not consistent, I think an alert message is expected. > > Alert message > > is expensive in practice. > > Note that this alert will never be sent to a client that is behaving > according to specification unless the packets were modified by the > network. It's a sanity check. > > Sure, if both peer strict follow the spec. But implementation may be not correct. Conner case, of course. Thanks & Regards, Xuelei --001a11c2003e9c2bd30525860bd0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Nov 27, 2015 at 9:28 PM, Hubert Kario <hkario@redhat.com> wrote:
On Friday 27 November 2015 21= :20:24 Xuelei Fan wrote:
> > > > I think that specifying *both* in preference order, and=
> > > > recommending
> > > > the servers to first inspect key shares and then
> > > > supported_groups
> > > > (if no intersect between what server supports and what = key
> > > > shares
> > > > client provided) would end up with more predictable beh= aviour
> > > > and
> > > > cleaner code.
> > >
> > > But if the orders are not consistent, the logic get annoyed.= =C2=A0 It's
> > > a
> > > good
> > > practice to keep the order consistent, but it would be bette= r if
> > > the
> > > preference order is unique and specified in one place.
> >
> > that means that the code needs to keep references to two arrays a= t
> > the same time and either create a hash table for lookups in key > > shares or iterate over key shares for every try - this makes code=
> > and logic more complex, not less
>
> I did not get the idea, can the complex above be avoided if keeping > both? Does one preference order just get ignored?

the idea is that if there is a key share acceptable for the server, = the
supported_groups can be ignored

but to make sure that clients don't start putting complete garbage
there, we need to tell servers to check key shares against
supported_groups

As the check needs additional= effort, =C2=A0and the client code also needs additional effort to keep the= order consistent, I think the logic may be more complex.

Anyway, not a big concern to me.=C2=A0 Personally, I prefer one log= ic one place.
=C2=A0
> If the orders are not consistent, if I can choose from two options: > continue or alter, I would choose the continue option.

alter what?

If the preference orders in k= ey_share and supported_groups are not consistent, I think an alert message = is expected.

=C2=A0
> Alert message
> is expensive in practice.

Note that this alert will never be sent to a client that is behaving=
according to specification unless the packets were modified by the
network. It's a sanity check.

Sure, i= f both peer strict follow the spec.=C2=A0 But implementation may be not cor= rect.=C2=A0 Conner case, of course.

Thanks & R= egards,
Xuelei
--001a11c2003e9c2bd30525860bd0-- From nobody Fri Nov 27 06:00: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 420661A1AB1 for ; Fri, 27 Nov 2015 06:00:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.785 X-Spam-Level: X-Spam-Status: No, score=-4.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 226saCf2Hky1 for ; Fri, 27 Nov 2015 06:00:22 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AA9F1A1AA3 for ; Fri, 27 Nov 2015 06:00:21 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CAW85230; Fri, 27 Nov 2015 14:00:18 +0000 (GMT) Received: from SZXEMI413-HUB.china.huawei.com (10.86.210.41) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 27 Nov 2015 14:00:16 +0000 Received: from SZXEMI501-MBX.china.huawei.com ([169.254.1.253]) by SZXEMI413-HUB.china.huawei.com ([10.86.210.41]) with mapi id 14.03.0235.001; Fri, 27 Nov 2015 22:00:04 +0800 From: Jayaraghavendran k To: Xuelei Fan , "tls@ietf.org" Thread-Topic: [TLS] TLS 1.3 and RFC 4279, Pre-Shared Key Ciphersuites Thread-Index: AQHRKQsBuPOPt0q8fE+pH+tBV6IRKZ6v4YMw Date: Fri, 27 Nov 2015 14:00:04 +0000 Message-ID: <8D925D4C0B78EE41857D407022ECD163BFF02A60@SZXEMI501-MBX.china.huawei.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.213.218] Content-Type: multipart/alternative; boundary="_000_8D925D4C0B78EE41857D407022ECD163BFF02A60SZXEMI501MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.565861F3.00FC, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.253, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: eaf63c6599d72eb877407c3a5b6dc5a2 Archived-At: Subject: Re: [TLS] TLS 1.3 and RFC 4279, Pre-Shared Key Ciphersuites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 14:00:25 -0000 --_000_8D925D4C0B78EE41857D407022ECD163BFF02A60SZXEMI501MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgWHVlbGVpLA0KDQpBcyBwZXIgUkZDIDQyNzkgYWxzbywgYm90aCB0aGUgY2xpZW50IGFuZCBz ZXJ2ZXIgYXJlIHN1cHBvc2VkIHRvIGhhdmUgYSBzZXQgb2Yg4oCcSWRlbnRpdHkg4oCTIGtleeKA nSBwYWlyICBvbiBlaXRoZXIgc2lkZXMuIFRoZSDigJxTZXJ2ZXJLZXlFeGNoYW5nZS5wc2tfaWRl bnRpdHlfaGludOKAnSBvbmx5IGhlbHBzIHRoZSBjbGllbnQgaW4gY2hvb3NpbmcgYW4g4oCcaWRl bnRpdHkta2V54oCdIHBhaXIgZnJvbSBhIGxpc3Qgb2Ygc2V2ZXJhbCDigJxpZGVudGl0eS1rZXkg cGFpcnPigJ0gdGhlIGNsaWVudCBtYXkgaGF2ZS4NCg0KSW4gVExTIDEuMywgaW5zdGVhZCBvZiB0 aGUgU2VydmVyS2V5RXhjaGFuZ2UucHNrX2lkZW50aXR5X2hpbnQsIGNsaWVudCBzZW5kcyBpdHMg bGlzdCBvZiBpZGVudGl0aWVzIGluIHRoZSBjbGllbnQgaGVsbG8gaXRzZWxmIHRocm91Z2ggUHJl U2hhcmVkS2V5IEV4dGVuc2lvbiBhbmQgc2VydmVyIGNob29zZXMgb25lIGZyb20gaXQgYW5kIHJl cGxpZXMgaW4gdGhlIFByZVNoYXJlZEtleSBFeHRlbnNpb24uICBOb3csIGluc3RlYWQgb2YgdHJh ZGl0aW9uYWwgc2Vzc2lvbiByZXN1bXB0aW9uLCB0aGlzIGxvZ2ljIHdpbGwgYmUgdXNlZCAgd2hp Y2ggYmFzaWNhbGx5IGhhcyB0aGUgc2FtZSBhYmJyZXZpYXRlZCBoYW5kc2hha2UuDQoNClNvLCBl c3NlbnRpYWxseSwgVExTIDEuMiB0byBUTFMgMS4zIHRyYW5zaXRpb24gZm9yIHRoZSBhYm92ZSBz Y2VuYXJpbyBzaG91bGQgYmUgdmlld2VkIGFzIGJlbG93Og0KDQooYSkgICAgSW4gY2FzZSBvZiBQ U0ssIGluc3RlYWQgb2YgQ2xpZW50IGd1ZXNzaW5nIGFuZCB1c2luZyBhbiBJZGVudGl0eSBiYXNl ZCBvbiBQU0sgSWRlbnRpdHkgSGludCwgYm90aCBjbGllbnQgYW5kIHNlcnZlciBuZWdvdGlhdGUg d2hpY2ggaWRlbnRpdHkgdG8gdXNlIGluIHRoZSBoZWxsbyBtZXNzYWdlcyBpdHNlbGYuDQoNCihi KSAgIFNlcnZlcktleUV4Y2hhbmdlLnBza19pZGVudGl0eV9oaW50IGNhbiBiZSBvYnNvbGV0ZWQg cmVtb3ZlZCB3aGVuIHlvdSB0cmFuc2l0aW9uIGZyb20gMS4yIHRvIDEuMy4NCg0KSW4gbXkgb3Bp bmlvbiwgdGhpcyBtYWtlcyB0aGUgUFNLIGJhc2VkIGhhbmRzaGFrZSBhIGxvdCBtb3JlIHNpbXBs ZXIgYW5kIGVhc2llciB0byB1c2UuDQoNCkNvdWxkIHlvdSBlbGFib3JhdGUgb24geW91ciBzY2Vu YXJpbyBiYXNlZCBvbiB3aGljaCB5b3Ugc2F5IHRoZSB0cmFuc2l0aW9uIGZyb20gVExTIDEuMiB0 byBUTFMgMS4zIGZvciBQU0sgd2lsbCBiZSBkaWZmaWN1bHQ/DQoNClJlZ2FyZHMsDQpKYXkNCg0K KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQpUaGlzIGUtbWFpbCBhbmQgYXR0YWNobWVu dHMgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gZnJvbSBIVUFXRUksIHdoaWNoIGlz IGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24gb3IgZW50aXR5IHdob3NlIGFkZHJlc3MgaXMg bGlzdGVkIGFib3ZlLiBBbnkgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWlu IGluIGFueSB3YXkgKGluY2x1ZGluZywgYnV0IG5vdCBsaW1pdGVkIHRvLCB0b3RhbCBvciBwYXJ0 aWFsIGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgb3IgZGlzc2VtaW5hdGlvbikgYnkgcGVyc29u cyBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQncykgaXMgcHJvaGliaXRlZC4gSWYg eW91IHJlY2VpdmUgdGhpcyBlLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBieSBwaG9uZSBvciBlbWFpbCBpbW1lZGlhdGVseSBhbmQgZGVsZXRlIGl0IQ0KKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqDQoNCkZyb206IFRMUyBbbWFpbHRvOnRscy1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgWHVlbGVpIEZhbg0KU2VudDogMjcgTm92ZW1iZXIgMjAxNSAx NzoyOQ0KVG86IHRsc0BpZXRmLm9yZw0KU3ViamVjdDogW1RMU10gVExTIDEuMyBhbmQgUkZDIDQy NzksIFByZS1TaGFyZWQgS2V5IENpcGhlcnN1aXRlcw0KDQpIaSwNCg0KSW4gdGhlIGRyYWZ0IHNw ZWMgb2YgVExTIDEuMywgU2VydmVyS2V5RXhjaGFuZ2UgYW5kIENsaWVudEtleUV4Y2hhbmdlIGdl dCByZW1vdmVkLCBhbmQga2V5X3NoYXJlIGV4dGVuc2lvbiBhcHBsaWVzIHRvIG5vbi1QU0sgY2lw aGVyIHN1aXRlcyBvbmx5LiBBcyBSRkMgNDI3OSBuZWVkIFNlcnZlcktleUV4Y2hhbmdlIGFuZCBD bGllbnRLZXlFeGNoYW5nZSBtZXNzYWdlcywgSSB0aGluayBUTFMgMS4zIHVwZGF0ZXMgb3Igb2Jz b2xldGVzIFJGQyA0Mjc5Lg0KDQpQZXIgdGhlIGRyYWZ0IHNwZWMgb2YgVExTIDEuMywgaWYgbm8g c3VpdGFibGUgaWRlbnRpdHkgaXMgcHJvdmlkZWQgaW4gcHJlLXNoYXJlZCBrZXkgZXh0ZW5zaW9u LCB0aGUgc2VydmVyIE1VU1QgTk9UIG5lZ290aWF0ZSBhIFBTSyBjaXBoZXIgc3VpdGUuICBUaGUg cXVlc3Rpb24gY29tZXMgdG8gbWU6IHdoZXJlIHRoZSBzdWl0YWJsZSBpZGVudGl0eSBjb21lcyBm cm9tPyAgVGhlIGlkZW50aXR5IGNhbiBiZSBhY3F1aXJlZCBieSBvdXQtb2YtYmFuZCBhcHByb2Fj aCwgb3IgdGhlIHNlcnZlciBOZXdTZXNzaW9uVGlja2V0IG1lc3NhZ2UuICBJZiBubyBvdXQtb2Yt YmFuZCBhcHByb2FjaCBpbiBzb21lIGNpcmN1bXN0YW5jZXMsIHRoZSBzZXJ2ZXIgTmV3U2Vzc2lv blRpY2tldCBtZXNzYWdlIHdvdWxkIGJlIHRoZSBvbmx5IHdheSB0byBjcmVhdGUgdGhlIGlkZW50 aXR5LiAgVGhlIHNjZW5hcmlvcyBvZiB1c2luZyAgcHJlLXNoYXJlZCBrZXkgbWF5IGxvb2sgbGlr ZToNCjEuIGVzdGFibGlzaCBhIGZyZXNoIGNvbm5lY3Rpb24sIHNlcnZlciBzZW5kcyB0aGUgTmV3 U2Vzc2lvblRpY2tldCB0byBpbmRpY2F0ZSBpdCBzdXBwb3J0cyBzZXNzaW9uIHJlc3VtcHRpb24g YW5kIHByb3ZpZGUgdGhlIHBza19pZGVudGl0eS4NCjIuIGlmIGNsaWVudCB3YW50cyBhIHNlc3Np b24gcmVzdW1wdGlvbiwgc3Vic2VxdWVudCBoYW5kc2hha2luZyB3aWxsIHVzZSBwcmVfc2hhcmVk IGtleSBleHRlbnNpb24gd2l0aCB0aGUgc2VydmVyIHByb3ZpZGVkIHBza19pZGVudGl0eS4NCg0K TG9va3MgbGlrZSBQU0sgYXBwbGllcyB0byBzZXNzaW9uIHJlc3VtZSBvbmx5IGluIFRMUyAxLjMs IGFuZCBjYW5ub3QgYmUgdXNlZCBmb3IgZnJlc2ggKGluaXRpYWwpIGhhbmRzaGFraW5nIGFueSBt b3JlLCAgdW5sZXNzIG91dC1vZi1iYW5kIGFwcHJvYWNoIGlzIHVzZWQgdG8gZGVmaW5lIHRoZSBp ZGVudGl0aWVzLiAgSSBoYXZlIG5vIGV4cGVyaWVuY2Ugb24gUFNLLCBidXQgbG9va3MgbGlrZSB0 aGF0IGl0IGlzIG5vdCBBIG1pbmltYWwgZWZmb3J0IGZvciBQU0sgZGVwbG95bWVudHMgdG8gdXBn cmFkZSBmcm9tIFRMUyAxLjIgdG8gVExTIDEuMywgaWYgU2VydmVyS2V5RXhjaGFuZ2UucHNrX2lk ZW50aXR5X2hpbnQgaXMgdXNlZCBwcmV2aW91c2x5Lg0KDQpJdCB3b3VsZCBiZSBuaWNlIHRvIGNv bnNpZGVyIGFuZCBzcGVjaWZ5IHRoZSBpbXBhY3Qgb24gUkZDIDQyNzkgaW4gVExTIDEuMyBwcm90 b2NvbHMuDQoNClJlZ2FyZHMsDQpYdWVsZWkNCg== --_000_8D925D4C0B78EE41857D407022ECD163BFF02A60SZXEMI501MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdy YXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFy Z2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCglt YXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkVt YWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4w cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERl ZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxNTI3MTkyOTsNCgltc28tbGlz dC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTEyODIwOTI4NjQgLTE2MDU0 NjkxMjIgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3 MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10ZXh0OiJcKCUxXCkiOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21h cmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ SGkgWHVlbGVpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+QXMgcGVyIFJGQyA0Mjc5IGFsc28sIGJvdGggdGhlIGNsaWVu dCBhbmQgc2VydmVyIGFyZSBzdXBwb3NlZCB0byBoYXZlIGEgc2V0IG9mIOKAnElkZW50aXR5IOKA kyBrZXnigJ0gcGFpciZuYnNwOyBvbiBlaXRoZXIgc2lkZXMuIFRoZSDigJxTZXJ2ZXJLZXlFeGNo YW5nZS5wc2tfaWRlbnRpdHlfaGludOKAnQ0KIG9ubHkgaGVscHMgdGhlIGNsaWVudCBpbiBjaG9v c2luZyBhbiDigJxpZGVudGl0eS1rZXnigJ0gcGFpciBmcm9tIGEgbGlzdCBvZiBzZXZlcmFsIOKA nGlkZW50aXR5LWtleSBwYWlyc+KAnSB0aGUgY2xpZW50IG1heSBoYXZlLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SW4g VExTIDEuMywgaW5zdGVhZCBvZiB0aGUgU2VydmVyS2V5RXhjaGFuZ2UucHNrX2lkZW50aXR5X2hp bnQsIGNsaWVudCBzZW5kcyBpdHMgbGlzdCBvZiBpZGVudGl0aWVzIGluIHRoZSBjbGllbnQgaGVs bG8gaXRzZWxmIHRocm91Z2ggUHJlU2hhcmVkS2V5IEV4dGVuc2lvbg0KIGFuZCBzZXJ2ZXIgY2hv b3NlcyBvbmUgZnJvbSBpdCBhbmQgcmVwbGllcyBpbiB0aGUgUHJlU2hhcmVkS2V5IEV4dGVuc2lv bi4gJm5ic3A7Tm93LCBpbnN0ZWFkIG9mIHRyYWRpdGlvbmFsIHNlc3Npb24gcmVzdW1wdGlvbiwg dGhpcyBsb2dpYyB3aWxsIGJlIHVzZWQgJm5ic3A7d2hpY2ggYmFzaWNhbGx5IGhhcyB0aGUgc2Ft ZSBhYmJyZXZpYXRlZCBoYW5kc2hha2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TbywgZXNzZW50aWFsbHksIFRMUyAx LjIgdG8gVExTIDEuMyB0cmFuc2l0aW9uIGZvciB0aGUgYWJvdmUgc2NlbmFyaW8gc2hvdWxkIGJl IHZpZXdlZCBhcyBiZWxvdzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlz dFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4oYSk8c3BhbiBzdHls ZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZu YnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JbiBjYXNlIG9mIFBTSywgaW5zdGVhZCBvZiBDbGllbnQg Z3Vlc3NpbmcgYW5kIHVzaW5nIGFuIElkZW50aXR5IGJhc2VkIG9uIFBTSyBJZGVudGl0eSBIaW50 LCBib3RoIGNsaWVudCBhbmQgc2VydmVyIG5lZ290aWF0ZSB3aGljaCBpZGVudGl0eSB0byB1c2UN CiBpbiB0aGUgaGVsbG8gbWVzc2FnZXMgaXRzZWxmLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28t bGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUi PihiKTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+ Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNlcnZlcktleUV4Y2hhbmdlLnBza19pZGVu dGl0eV9oaW50IGNhbiBiZSBvYnNvbGV0ZWQgcmVtb3ZlZCB3aGVuIHlvdSB0cmFuc2l0aW9uIGZy b20gMS4yIHRvIDEuMy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkluIG15 IG9waW5pb24sIHRoaXMgbWFrZXMgdGhlIFBTSyBiYXNlZCBoYW5kc2hha2UgYSBsb3QgbW9yZSBz aW1wbGVyIGFuZCBlYXNpZXIgdG8gdXNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q291bGQgeW91IGVsYWJvcmF0ZSBv biB5b3VyIHNjZW5hcmlvIGJhc2VkIG9uIHdoaWNoIHlvdSBzYXkgdGhlIHRyYW5zaXRpb24gZnJv bSBUTFMgMS4yIHRvIFRMUyAxLjMgZm9yIFBTSyB3aWxsIGJlIGRpZmZpY3VsdD88bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkpheTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKjxicj4NClRoaXMgZS1tYWlsIGFuZCBhdHRhY2htZW50 cyBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBmcm9tIEhVQVdFSSwgd2hpY2ggaXMg aW50ZW5kZWQgb25seSBmb3IgdGhlIHBlcnNvbiBvciBlbnRpdHkgd2hvc2UgYWRkcmVzcyBpcyBs aXN0ZWQgYWJvdmUuIEFueSB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4g aW4gYW55IHdheSAoaW5jbHVkaW5nLCBidXQgbm90IGxpbWl0ZWQgdG8sIHRvdGFsIG9yIHBhcnRp YWwNCiBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIG9yIGRpc3NlbWluYXRpb24pIGJ5IHBlcnNv bnMgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50J3MpIGlzIHByb2hpYml0ZWQuIElm IHlvdSByZWNlaXZlIHRoaXMgZS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgYnkgcGhvbmUgb3IgZW1haWwgaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSBpdCE8YnI+DQoqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKio8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gVExTIFttYWlsdG86dGxzLWJvdW5jZXNA aWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlh1ZWxlaSBGYW48YnI+DQo8Yj5TZW50Ojwv Yj4gMjcgTm92ZW1iZXIgMjAxNSAxNzoyOTxicj4NCjxiPlRvOjwvYj4gdGxzQGlldGYub3JnPGJy Pg0KPGI+U3ViamVjdDo8L2I+IFtUTFNdIFRMUyAxLjMgYW5kIFJGQyA0Mjc5LCBQcmUtU2hhcmVk IEtleSBDaXBoZXJzdWl0ZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkhpLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SW4gdGhlIGRyYWZ0IHNwZWMgb2YgVExTIDEuMywgU2VydmVyS2V5RXhjaGFuZ2UgYW5kIENsaWVu dEtleUV4Y2hhbmdlIGdldCByZW1vdmVkLCBhbmQga2V5X3NoYXJlIGV4dGVuc2lvbiBhcHBsaWVz IHRvJm5ic3A7bm9uLVBTSyBjaXBoZXIgc3VpdGVzIG9ubHkuIEFzIFJGQyA0Mjc5IG5lZWQgU2Vy dmVyS2V5RXhjaGFuZ2UgYW5kIENsaWVudEtleUV4Y2hhbmdlIG1lc3NhZ2VzLCBJIHRoaW5rIFRM UyAxLjMgdXBkYXRlcw0KIG9yIG9ic29sZXRlcyBSRkMgNDI3OS48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGVyIHRoZSBkcmFmdCBzcGVjIG9m IFRMUyAxLjMsIGlmIG5vIHN1aXRhYmxlIGlkZW50aXR5IGlzIHByb3ZpZGVkIGluIHByZS1zaGFy ZWQga2V5IGV4dGVuc2lvbiwmbmJzcDt0aGUgc2VydmVyIE1VU1QgTk9UIG5lZ290aWF0ZSBhIFBT SyBjaXBoZXIgc3VpdGUuJm5ic3A7IFRoZSBxdWVzdGlvbiBjb21lcyB0byBtZTogd2hlcmUgdGhl IHN1aXRhYmxlIGlkZW50aXR5IGNvbWVzIGZyb20/Jm5ic3A7IFRoZSBpZGVudGl0eSBjYW4gYmUg YWNxdWlyZWQNCiBieSBvdXQtb2YtYmFuZCBhcHByb2FjaCwgb3IgdGhlIHNlcnZlciBOZXdTZXNz aW9uVGlja2V0IG1lc3NhZ2UuJm5ic3A7IElmIG5vIG91dC1vZi1iYW5kIGFwcHJvYWNoIGluIHNv bWUgY2lyY3Vtc3RhbmNlcywgdGhlIHNlcnZlciBOZXdTZXNzaW9uVGlja2V0IG1lc3NhZ2Ugd291 bGQgYmUgdGhlIG9ubHkgd2F5IHRvIGNyZWF0ZSB0aGUgaWRlbnRpdHkuJm5ic3A7IFRoZSZuYnNw O3NjZW5hcmlvcyBvZiB1c2luZyAmbmJzcDtwcmUtc2hhcmVkIGtleSBtYXkgbG9vayBsaWtlOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MS4gZXN0 YWJsaXNoIGEgZnJlc2ggY29ubmVjdGlvbiwgc2VydmVyIHNlbmRzIHRoZSBOZXdTZXNzaW9uVGlj a2V0IHRvIGluZGljYXRlIGl0IHN1cHBvcnRzIHNlc3Npb24gcmVzdW1wdGlvbiBhbmQgcHJvdmlk ZSB0aGUgcHNrX2lkZW50aXR5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Mi4gaWYgY2xpZW50IHdhbnRzIGEgc2Vzc2lvbiByZXN1bXB0aW9uLCBz dWJzZXF1ZW50IGhhbmRzaGFraW5nIHdpbGwgdXNlIHByZV9zaGFyZWQga2V5IGV4dGVuc2lvbiB3 aXRoIHRoZSBzZXJ2ZXIgcHJvdmlkZWQgcHNrX2lkZW50aXR5LjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Mb29rcyBsaWtlIFBTSyBhcHBsaWVz IHRvIHNlc3Npb24gcmVzdW1lIG9ubHkgaW4gVExTIDEuMywgYW5kIGNhbm5vdCBiZSB1c2VkIGZv ciBmcmVzaCAoaW5pdGlhbCkgaGFuZHNoYWtpbmcgYW55IG1vcmUsICZuYnNwO3VubGVzcyBvdXQt b2YtYmFuZCBhcHByb2FjaCBpcyB1c2VkIHRvIGRlZmluZSB0aGUgaWRlbnRpdGllcy4mbmJzcDsg SSBoYXZlIG5vIGV4cGVyaWVuY2Ugb24gUFNLLCBidXQgbG9va3MgbGlrZSB0aGF0IGl0IGlzDQog bm90IEEgbWluaW1hbCBlZmZvcnQgZm9yIFBTSyBkZXBsb3ltZW50cyB0byB1cGdyYWRlIGZyb20g VExTIDEuMiB0byBUTFMgMS4zLCBpZiBTZXJ2ZXJLZXlFeGNoYW5nZS5wc2tfaWRlbnRpdHlfaGlu dCBpcyB1c2VkIHByZXZpb3VzbHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkl0IHdvdWxkIGJlIG5pY2UgdG8gY29uc2lkZXIgYW5kIHNwZWNp ZnkgdGhlIGltcGFjdCBvbiBSRkMgNDI3OSBpbiBUTFMgMS4zIHByb3RvY29scy48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlh1ZWxlaTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_8D925D4C0B78EE41857D407022ECD163BFF02A60SZXEMI501MBXchi_-- From nobody Fri Nov 27 06:35: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 5BA901B2BA9 for ; Fri, 27 Nov 2015 06:35:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_22=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 uTf4r-X8H_lg for ; Fri, 27 Nov 2015 06:35:30 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F0AE1B2B93 for ; Fri, 27 Nov 2015 06:35:30 -0800 (PST) Received: by wmuu63 with SMTP id u63so57811570wmu.0 for ; Fri, 27 Nov 2015 06:35:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version :content-type; bh=F4oo9QnNNnIbr1Laa2+UIkgDRZ8EJL3tUb4/VH1W6qw=; b=BZBYt7yiSi1wimHw0yZ8fKMgJjGtNbf7cOSNNoZbDP+hv6hvXjkDeNG6Vgf+jiCiu0 /P3RprBe9+eu5AfkxB3n5M+LM/8ulxVYluQV4+eVA7WFClwriskFMK9Yu4GQm3iNFdCE YNwKy9OXA15f0jeL2wFDcpwcvmx5b0pkB8FuS7GnpeYM6wLdViQLQ+4/fi/1uCldBlH7 KczSlcpfDNuXthqi8m1Jpp81IsKY2aCs60KojX2EGQr+b8KvLXhB1AHjroy9d9Hd/sLx ob2nyc+m/7+5EELufxQJvgrWfdeiG5W71PkBEO52qzlIgrCs3X2LnS3gDSKWYsWv6DWL MZrw== X-Received: by 10.194.92.229 with SMTP id cp5mr56424176wjb.163.1448634928765; Fri, 27 Nov 2015 06:35:28 -0800 (PST) Received: from proz.dclient.lsne.ch (85-218-12-53.dclient.lsne.ch. [85.218.12.53]) by smtp.gmail.com with ESMTPSA id lx4sm33066211wjb.5.2015.11.27.06.35.27 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 Nov 2015 06:35:27 -0800 (PST) To: "tls@ietf.org" From: Bryan A Ford X-Enigmail-Draft-Status: N1110 Message-ID: <56586A2F.1070703@gmail.com> Date: Fri, 27 Nov 2015 15:35:27 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030208000305020508010207" Archived-At: Subject: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 14:35:32 -0000 This is a cryptographically signed message in MIME format. --------------ms030208000305020508010207 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The idea of encrypting TLS record headers has come up before, the most important purpose being to hide record lengths and boundaries and make fingerprinting and traffic analysis harder. I had convinced myself that goal this would be "too hard" to accomplish in TLS 1.3, but after further thought I'm not so sure. So I would like to request comment on one approach that strikes me as a practical and requires only a rather minor change to the current spec. The quick summary: * To encrypt a record, we first AEAD-encrypt the record's payload, protecting the header fields via the additional_data, exactly as currently specified. But then we XOR-encrypt the 5-byte TLS header just before transmission, using a (separate) stream cipher indexed by a nonce that depends on record sequence number and *_write_iv, in exactly the same way the AEAD is already nonce-indexed. * To decrypt a record, we simply do the reverse: first use the stream cipher with the appropriate nonce to XOR-decrypt the 5-byte TLS header, then sanity-check it as usual to determine its length, read the rest of the record, and submit it to AEAD for decryption and full integrity checking as before. That's it, in a nutshell. Two likely concerns immediately arise, discussed below, but feel free to TL;DR the rest if you don't share these concerns. --- Concern #1: What if an active attacker messes with the TLS header, especially the length field, since stream ciphers don't protect integrity? The simple answer is that *exactly* the same thing happens as now: the AEAD decryption attempt fails, because the (stream-decrypted) header is AEAD-protected as additional_data. Nothing is gained or lost. SSH, which did something like this, ran into trouble with attackers being able to twiddle the record length field to make the record length look big, causing the receiver to try to receive a very large record, and hence appear to the user to hang, instead of immediately detecting the modification and terminating the connection. But there are three mitigating factors here: (1) TLS is not usually used for interactive terminal traffic like SSH is; (2) TLS's 2-byte record length field imposes a pretty reasonable upper-bound on the maximum size an attacker could maliciously make a record appear to be; and (3) if this risk of length-twiddling is at all a problem in this proposed encrypted-header protocol, then it's already a problem for the current TLS 1.3 spec without encrypted headers, because active attackers can twiddle the bits of a cleartext length field just as easily (and even be *certain* they are making the length appear large!). So I can't see any way this length-twiddling vulnerability becomes any worse, and maybe it gets a bit better (because the attacker can no longer be entirely certain whether he's setting a 1 bit to 0 or a 0 bit to 1). --- Concern #2: Do we want to have to go to the trouble of adding a stream cipher to every TLS 1.3-compatible ciphersuite? Answer: maybe not, but we don't necessarily need to. We could instead just specify a generic method of using the ciphersuite's main AEAD as a stream cipher for header encryption/decryption purposes. The conceptually simplest approach I can think of: In the specification of how AEAD nonces are generated (section 5.2.2 of draft-ietf-tls-tls13-07), reserve the least-significant bit of the record sequence number, so that sequence numbers increment by 2 rather than 1 each record. Thus, we get two unique nonces per record from the same set of symmetric keys. We first use the nonce with a '0' least-significant bit to perform the regular AEAD-encryption of the record with the header info as additional_data. Then for the same record we use the nonce with a '1' least-significant to AEAD-encrypt a sequence of five zero bytes ("\0\0\0\0\0"), and use the first five bytes of result as the cipherstream to XOR the 5-byte TLS header with before transmitting. The AEAD will of course uselessly append some kind of authenticator to this ciphertext that we won't end up using, but that's OK. The receiver will just use AEAD-encrypt (again) on the same five-zero-byte message to reproduce the 5 cipherstream bytes with which to decrypt the TLS header. Thus, senders perform two AEAD-encrypts per record, and receivers do one AEAD-encrypt and one AEAD-decrypt per record. This approach seems pretty conceptually clean and simple, but has the performance downside that we always need to invoke the AEAD twice per record rather than once, which might be (a bit) costly especially when records are small. So a simple refinement is to amortize this cost across records: e.g., once every 256 records (every sequence number ending in 0x00) we AEAD-encrypt a sequence of 5*256=3D1280 zero bytes, an= d the result in 5-byte chunks as the cipherstream with which to encrypt and decrypt 256 consecutive TLS record headers. Thus, we're only adding one additional AEAD-encryption of a "normal-packet-sized" 1280-byte blob once every 256 records, which seems likely to be a pretty inconsequential performance cost. --- Comments? Thanks Bryan --------------ms030208000305020508010207 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfgwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVBMIIEKaADAgECAhAWpZtNxHBkhVoG2HKaeabqMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwNjI0MDAwMDAwWhcNMTYwNjIzMjM1OTU5WjAmMSQwIgYJKoZIhvcNAQkB FhVicnlub3NhdXJ1c0BnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDAPPVOZLVu2tZOao2osnGxGwYy7nC3UX8yoebrOfaNWkItIkUH6NQRKuqxuDE7127q48VH c7kwmg4DifoOjxSjXyT+R9pR/ethFwjXiWCjsIaWbcFc6X7D1fIisO14z8D4luBO1LezNVB6 Dee8lMutP9OO4MmKWYq3+Jab9Rv/3BXCyiDDQfxhiuWFzZQTWpbzGGfwitcqPHH97PN4COCh hhOuUS9Yt1qQBY8Gn36eVepKdz3YiF7ii/JDth1iA/zHK8pyim+OgERcwo6Ildqh59uy0IjM AcKA1Mc34AgMQJdLlmhYAai5nMLOJQiFzfIyB6egjSyishx11rpL/xKlAgMBAAGjggHzMIIB 7zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQUpXGtiQ4RgWPr 1UjnydSPtyPTai8wDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYI KwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsG DCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEF BQcBAQSBgzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RP U0hBMjU2Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEF BQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCAGA1UdEQQZMBeBFWJyeW5vc2F1cnVz QGdtYWlsLmNvbTANBgkqhkiG9w0BAQsFAAOCAQEADDSBNRYWArRAPSTMC6DSrUOIWQ3J1CmE XEYoQ4QByCkkybRUCgXIadTAUwj+D9ZX4HQxxvtOkb+uVQCnwbI6jGZj0Mpb7MWYOZDyeQT1 YEoUMRpeUUpTDd6iw3Em0Lf+rj7/VPlYKvErTCOnyEUm2z8MismcjPIFJ8Ud+HccyfpkhotJ HbVBN+hSGm03l7YxVVzf9owzq7L5vCB5afJyTNt5x7qlLCcsiGBW2kSoQKaDAMwuYMp5YOgD 1doc/yWJSkiQAcKcWY2ALacs+a0FSItqT1rNk3tnHX2spIrBgDrv+5ybZXBBjAknetbTON5m rWT2tzLgYpKPJLs49ETIoDGCBEEwggQ9AgEBMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UE CBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJYIZIAWUD BAIBBQCgggJhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MTEyNzE0MzUyN1owLwYJKoZIhvcNAQkEMSIEIE0vwP7P2fP3dWdcd8EYXoflO6fOKCgEM/Rv dDzg4koRMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgcEGCSsGAQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAWpZtNxHBkhVoG2HKaeabqMIHDBgsqhkiG9w0B CRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBAhAWpZtNxHBkhVoG2HKaeabqMA0GCSqGSIb3DQEBAQUABIIBAD1NyfJ27Y6r0WyH hn3PLrDkbghau+yIYPSpb+6uyVuiOtHG+cmF3RR7L83nYjuS7jCyfyXfM/xRCIcHLV1bu9KV FkQulX4ZLUuPAs2DCKq9AfnzV5ocB0N/MR9wDQcUZhpYPlnKLMibHcszaimR1MfKKc0HpmDs tpucDnMZsUmBbwc+VUnJh75KK806dkBgPpk5CwtRgPZCFZhfX7DoaH4JkbUAhS7mpI9JwYP3 64JnBXwV3VP+tycQ6bIbsyhWWqFc06iuloIw0klD7bBTux3vHYl4e5W/2tako9WaYhnNYzh6 k0Jl7xT5SZM7s285YHFcjd0+4sXFHA4TIWtcVOMAAAAAAAA= --------------ms030208000305020508010207-- From nobody Fri Nov 27 07:03:46 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 799C51B34DF for ; Fri, 27 Nov 2015 07:03:44 -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, 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 qA2rNLAKM326 for ; Fri, 27 Nov 2015 07:03:41 -0800 (PST) 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 D76291B34DB for ; Fri, 27 Nov 2015 07:03:40 -0800 (PST) Received: by obbnk6 with SMTP id nk6so84096755obb.2 for ; Fri, 27 Nov 2015 07:03:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vimino-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FdCgh3pqLE8fzaOczRk+MOT7QQZ6BobS19b071BpSBU=; b=AjXy5wK8Dprh9+oKh03ksmNFXsrxq4+kPWi4z71ErRJGvLFO+SCGmXtHDJfCcaZw4B js73FK40KHfI0lm8/hZRjd9MPKui9ExLW2vw4mg3VQP2kG8asWj7iXHBMKMNETl8iBDY IMH4ZiYq6VpAcJHCaarI899t11okntv9jMNNxnblMetUqtnXmoOzdiuvACj2ZPuRLCS+ 4ivMHwGH6Ghnudrrf4PZGQEdXxmErK57ERD2sgyUCyu31DArSMmOx7SFRIfot9o2YLP4 JH7CjG1kvfYK976SRPwbSmrKeTLbzQ1j267DDFfYL/kRDhATlJkT01xAKIHzeuwftUMB l5Cg== 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=FdCgh3pqLE8fzaOczRk+MOT7QQZ6BobS19b071BpSBU=; b=Q96Y9edkyLQLmPBughJSiP4hejPy8k6lFpmzI1jkdz5QCjd20CqcNh7SsXGc1ndFsX 4NxSxRa/soPJGUaK/uFPz64cWkZRWjUgG6Nq6eBbQdeB/4/P3P8HpF0+9n076P5KH34C 2dF2Ov1aL9jwOev9GYAtxbKCGI/EyZkyu3q2PkK4IeLQeYMzvd+OonqQezH//JTWUPXs vx0bRX6sj4CK1DFMVtoa/guSVI72r4yY7cLXtHCiV5pt84yokEV/R/Pnt/pM9a6E35K9 DeFJ5IJy/O9VYPc73MHPqS3rs65eRyGlKTJkSyXHWEgl8IbwwXXQmnhecitbN1hw9nXP mGhw== X-Gm-Message-State: ALoCoQmvhOWFIUs0NWXKBKItfDY8OrvtYI3GoxIvpR536VVVZdd4ueBY09cKTn/IvtVIMW3GeeGI MIME-Version: 1.0 X-Received: by 10.60.131.180 with SMTP id on20mr256012oeb.7.1448636620251; Fri, 27 Nov 2015 07:03:40 -0800 (PST) Received: by 10.76.171.103 with HTTP; Fri, 27 Nov 2015 07:03:40 -0800 (PST) X-Originating-IP: [148.87.19.214] In-Reply-To: <8D925D4C0B78EE41857D407022ECD163BFF02A60@SZXEMI501-MBX.china.huawei.com> References: <8D925D4C0B78EE41857D407022ECD163BFF02A60@SZXEMI501-MBX.china.huawei.com> Date: Fri, 27 Nov 2015 23:03:40 +0800 Message-ID: From: Xuelei Fan To: Jayaraghavendran k Content-Type: multipart/alternative; boundary=047d7b4726da28bc91052586ff19 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 and RFC 4279, Pre-Shared Key Ciphersuites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 15:03:44 -0000 --047d7b4726da28bc91052586ff19 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It is a great idea to use PSK for session resumption. However, as the ServerKeyExchange.psk_identity_hint disappears in TLS 1.3, I was wondering, it may be not easy to make an upgrade for those PSK implementation that relies on ServerKeyExchange.psk_identity_hint. Considering the following initial handshaking example in TLS 1.2. 1. client requests a PSK cipher suite negotiation; 2. server responses with a hint in ServerKeyExchange.psk_identity_hint 3. client looks for the shared key with the hint in the local database/cache/remote service, etc. 4. client provides the shared key in ClientKeyExchange.psk_identity. Here ServerKeyExchange.psk_identity_hint is used as an index to find the shared key in client side. If moving to TLS 1.3, as there is no hint any more, application may need to reconstruct the scenarios above in order to follow the spec of TLS 1.3 and find a new approach to get the shared key. If the client and server are supposed to have a short set of known =E2=80=9CIdentity =E2=80=93 key=E2=80=9D pair on either sides between them,= the reconstruction can be minimal. If the shared keys are unknown previously before the hint get known, the reconstruction would get complicated. Just guessing theoretically, I have no practical evidence for the case. Hopefully, no one use the case in practice. Regards, Xuelei On Fri, Nov 27, 2015 at 10:00 PM, Jayaraghavendran k < jayaraghavendran.k@huawei.com> wrote: > Hi Xuelei, > > > > As per RFC 4279 also, both the client and server are supposed to have a > set of =E2=80=9CIdentity =E2=80=93 key=E2=80=9D pair on either sides. Th= e > =E2=80=9CServerKeyExchange.psk_identity_hint=E2=80=9D only helps the clie= nt in choosing an > =E2=80=9Cidentity-key=E2=80=9D pair from a list of several =E2=80=9Cident= ity-key pairs=E2=80=9D the client > may have. > > > > In TLS 1.3, instead of the ServerKeyExchange.psk_identity_hint, client > sends its list of identities in the client hello itself through > PreSharedKey Extension and server chooses one from it and replies in the > PreSharedKey Extension. Now, instead of traditional session resumption, > this logic will be used which basically has the same abbreviated handsha= ke. > > > > So, essentially, TLS 1.2 to TLS 1.3 transition for the above scenario > should be viewed as below: > > (a) In case of PSK, instead of Client guessing and using an Identity > based on PSK Identity Hint, both client and server negotiate which identi= ty > to use in the hello messages itself. > > (b) ServerKeyExchange.psk_identity_hint can be obsoleted removed when > you transition from 1.2 to 1.3. > > > > In my opinion, this makes the PSK based handshake a lot more simpler and > easier to use. > > > > Could you elaborate on your scenario based on which you say the transitio= n > from TLS 1.2 to TLS 1.3 for PSK will be difficult? > > > > Regards, > > Jay > > > > > *************************************************************************= ************** > This e-mail and attachments contain confidential information from HUAWEI, > which is intended only for the person or entity whose address is listed > above. Any use of the information contained herein in any way (including, > but not limited to, total or partial disclosure, reproduction, or > dissemination) by persons other than the intended recipient's) is > prohibited. If you receive this e-mail in error, please notify the sender > by phone or email immediately and delete it! > > *************************************************************************= ************** > > > > *From:* TLS [mailto:tls-bounces@ietf.org] *On Behalf Of *Xuelei Fan > *Sent:* 27 November 2015 17:29 > *To:* tls@ietf.org > *Subject:* [TLS] TLS 1.3 and RFC 4279, Pre-Shared Key Ciphersuites > > > > Hi, > > > > In the draft spec of TLS 1.3, ServerKeyExchange and ClientKeyExchange get > removed, and key_share extension applies to non-PSK cipher suites only. A= s > RFC 4279 need ServerKeyExchange and ClientKeyExchange messages, I think T= LS > 1.3 updates or obsoletes RFC 4279. > > > > Per the draft spec of TLS 1.3, if no suitable identity is provided in > pre-shared key extension, the server MUST NOT negotiate a PSK cipher > suite. The question comes to me: where the suitable identity comes from? > The identity can be acquired by out-of-band approach, or the server > NewSessionTicket message. If no out-of-band approach in some > circumstances, the server NewSessionTicket message would be the only way = to > create the identity. The scenarios of using pre-shared key may look lik= e: > > 1. establish a fresh connection, server sends the NewSessionTicket to > indicate it supports session resumption and provide the psk_identity. > > 2. if client wants a session resumption, subsequent handshaking will use > pre_shared key extension with the server provided psk_identity. > > > > Looks like PSK applies to session resume only in TLS 1.3, and cannot be > used for fresh (initial) handshaking any more, unless out-of-band approa= ch > is used to define the identities. I have no experience on PSK, but looks > like that it is not A minimal effort for PSK deployments to upgrade from > TLS 1.2 to TLS 1.3, if ServerKeyExchange.psk_identity_hint is used > previously. > > > > It would be nice to consider and specify the impact on RFC 4279 in TLS 1.= 3 > protocols. > > > > Regards, > > Xuelei > --047d7b4726da28bc91052586ff19 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

It is a great idea to use PSK for s= ession resumption.=C2=A0 However, as the ServerKeyExchange.psk_identity_hin= t disappears in TLS 1.3, I was wondering, it may be not easy to make an upg= rade for those PSK implementation that relies on ServerKeyExchange.psk_iden= tity_hint.


Conside= ring the following initial handshaking example in TLS 1.2.

1. client requests a PSK cipher suite negotiation;

2. server responses with a hint in ServerKeyExchange.psk_identi= ty_hint

3. client looks for the shared key with t= he hint in the local database/cache/remote service, etc.

4. client provides the shared key in ClientKeyExchange.psk_identity= .


Here ServerKeyExchange.psk_identity_hint is used a= s an index to find the shared key in client side.

= If moving to TLS 1.3, as there is no hint any more, application may need to= reconstruct the scenarios above in order to follow the spec of TLS 1.3 and= find a new approach to get the shared key.

If the= client and server are supposed to have a short set of known =E2=80=9CIdent= ity =E2=80=93 key=E2=80=9D pair on either sides between them, the=C2=A0reco= nstruction=C2=A0can be minimal.=C2=A0 If the shared keys are unknown previo= usly before the hint get known, the reconstruction would get complicated.= =C2=A0 Just guessing theoretically, I have no practical evidence for the ca= se.=C2=A0 Hopefully, no one use the case in practice.

<= div>Regards,
Xuelei



On Fri, Nov 27, 2015 at 10= :00 PM, Jayaraghavendran k <jayaraghavendran.k@huawei.com&= gt; wrote:

Hi Xuelei,

=C2=A0

As per RFC 4279 also, both the client and se= rver are supposed to have a set of =E2=80=9CIdentity =E2=80=93 key=E2=80=9D= pair=C2=A0 on either sides. The =E2=80=9CServerKeyExchange.psk_identity_hi= nt=E2=80=9D only helps the client in choosing an =E2=80=9Cidentity-key=E2=80=9D pair f= rom a list of several =E2=80=9Cidentity-key pairs=E2=80=9D the client may h= ave.

=C2=A0

In TLS 1.3, instead of the ServerKeyExchange= .psk_identity_hint, client sends its list of identities in the client hello= itself through PreSharedKey Extension and server chooses one from it and replies in the PreSharedKey Extension.= =C2=A0 Now, instead of traditional session resumption, this logic will be u= sed =C2=A0which basically has the same abbreviated handshake.=

=C2=A0

So, essentially, TLS 1.2 to TLS 1.3 transiti= on for the above scenario should be viewed as below:

(a)=C2=A0=C2=A0=C2=A0 In case of PSK, instead of Client guess= ing and using an Identity based on PSK Identity Hint, both client and serve= r negotiate which identity to use in the hello messages itself.

(b)=C2=A0=C2=A0 ServerKeyExchange.psk_identity_hint can= be obsoleted removed when you transition from 1.2 to 1.3.

=C2=A0<= /u>

In my opinion, this makes the PSK based hand= shake a lot more simpler and easier to use.

=C2=A0

Could you elaborate on your scenario based o= n which you say the transition from TLS 1.2 to TLS 1.3 for PSK will be diff= icult?

=C2=A0

Regards,

Jay

=C2=A0

**********************************************= *****************************************
This e-mail and attachments contain confidential information from HUAWEI, w= hich is intended only for the person or entity whose address is listed abov= e. Any use of the information contained herein in any way (including, but n= ot limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the inte= nded recipient's) is prohibited. If you receive this e-mail in error, p= lease notify the sender by phone or email immediately and delete it!
***************************************************************************= ************

=C2=A0

From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Xuelei Fan
Sent: 27 November 2015 17:29
To: tls@ietf.org
Subject: [TLS] TLS 1.3 and RFC 4279, Pre-Shared Key Ciphersuites<= /u>

=C2=A0

Hi,

=C2=A0

In the draft spec of TLS 1.3, ServerKeyExchange and = ClientKeyExchange get removed, and key_share extension applies to=C2=A0non-= PSK cipher suites only. As RFC 4279 need ServerKeyExchange and ClientKeyExc= hange messages, I think TLS 1.3 updates or obsoletes RFC 4279.

=C2=A0

Per the draft spec of TLS 1.3, if no suitable identi= ty is provided in pre-shared key extension,=C2=A0the server MUST NOT negoti= ate a PSK cipher suite.=C2=A0 The question comes to me: where the suitable = identity comes from?=C2=A0 The identity can be acquired by out-of-band approach, or the server NewSessionTicket message.=C2=A0 If = no out-of-band approach in some circumstances, the server NewSessionTicket = message would be the only way to create the identity.=C2=A0 The=C2=A0scenar= ios of using =C2=A0pre-shared key may look like:

1. establish a fresh connection, server sends the Ne= wSessionTicket to indicate it supports session resumption and provide the p= sk_identity.

2. if client wants a session resumption, subsequent = handshaking will use pre_shared key extension with the server provided psk_= identity.

=C2=A0

Looks like PSK applies to session resume only in TLS= 1.3, and cannot be used for fresh (initial) handshaking any more, =C2=A0un= less out-of-band approach is used to define the identities.=C2=A0 I have no= experience on PSK, but looks like that it is not A minimal effort for PSK deployments to upgrade from TLS 1.2 to TLS 1.= 3, if ServerKeyExchange.psk_identity_hint is used previously.=

=C2=A0

It would be nice to consider and specify the impact = on RFC 4279 in TLS 1.3 protocols.

=C2=A0

Regards,

Xuelei


--047d7b4726da28bc91052586ff19-- From nobody Fri Nov 27 08:22: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 9FF3A1B35E5 for ; Fri, 27 Nov 2015 08:22:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 q4B8aEsRKvgU for ; Fri, 27 Nov 2015 08:22:41 -0800 (PST) Received: from vsp2.ballou.se (vsp2.ballou.se [91.189.40.83]) by ietfa.amsl.com (Postfix) with SMTP id 595431B35E3 for ; Fri, 27 Nov 2015 08:22:40 -0800 (PST) X-Halon-ID: 12f31b57-9523-11e5-976f-0050569222ec X-Halon-Scanned: 7f4a955dd6f4c149d51110a345668da22aa82d04 Received: from nmail1.ballou.se (unknown [10.0.0.116]) by vsp2.ballou.se (Halon Mail Gateway) with ESMTP for ; Fri, 27 Nov 2015 17:22:37 +0100 (CET) Received: from [192.168.0.190] (c-1ec0e555.06-134-73746f39.cust.bredbandsbolaget.se [85.229.192.30]) (Authenticated sender: henrick@streamsec.se) by nmail1.ballou.se (Postfix) with ESMTPSA id 77160C93BB for ; Fri, 27 Nov 2015 17:22:37 +0100 (CET) References: <56586A2F.1070703@gmail.com> To: tls@ietf.org From: =?UTF-8?Q?Henrick_Hellstr=c3=b6m?= Message-ID: <565882FE.80205@streamsec.se> Date: Fri, 27 Nov 2015 17:21:18 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <56586A2F.1070703@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: henrick@streamsec.se List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2015 16:22:43 -0000 On 2015-11-27 15:35, Bryan A Ford wrote: > The idea of encrypting TLS record headers has come up before, the most > important purpose being to hide record lengths and boundaries and make > fingerprinting and traffic analysis harder. How, exactly, would this be significantly harder? The adversary will still be able to tell when, and how much, TCP/IP data is sent between the peers. If there happens to be a revealing TLS record boundary in the middle of a TCP/IP packet, it would seem to me there is an implementation problem rather than a problem with the abstract protocol. From nobody Fri Nov 27 18:25: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 83DC61B2FAD for ; Fri, 27 Nov 2015 18:25:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pl8H4hvfNHNA for ; Fri, 27 Nov 2015 18:25:01 -0800 (PST) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001: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 470861B2FAC for ; Fri, 27 Nov 2015 18:25:01 -0800 (PST) Received: by igvg19 with SMTP id g19so40361675igv.1 for ; Fri, 27 Nov 2015 18:25:00 -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=CCSHJv80SeBWm3T499FjyFF3yLT3jVmqbvgA6kglLnE=; b=lN3/f6N5MI+PX3fgHl8bXxi2L85whPa9OJ1y+y8NVQPRPrHdUIcXLyMTFsguq/V0ai eG66aTxeVCS6PhCXmaDF57qUcUQ6VYcD4AnMVCsNk6iNVaBIY095d7z14wZhR1dUe8hF ju8Xx50PygEKtpxnA9endL2H2SucAG6GhMF2IBSrU7ryex/XZyEpkeauo9EYivyS+6sJ 3aGCdfReLzjNjJ7AMP4PYR/2WCdNlV2WshrcPmZaatzdaenY7T+P5cQX+V/CjmUni7LF 0zam6cQ8z1AckyNeKVNzj4qj5ZdcHHxU/9zpqzYVlFt6lHGlHdJ7oSpLuyAG6AxMx644 eHYA== MIME-Version: 1.0 X-Received: by 10.50.143.10 with SMTP id sa10mr11707428igb.77.1448677500434; Fri, 27 Nov 2015 18:25:00 -0800 (PST) Received: by 10.36.155.139 with HTTP; Fri, 27 Nov 2015 18:25:00 -0800 (PST) In-Reply-To: References: Date: Fri, 27 Nov 2015 18:25:00 -0800 Message-ID: From: Martin Thomson To: Xuelei Fan Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] "selected_group" field in HelloRetryRequest in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2015 02:25:02 -0000 On 26 November 2015 at 18:38, Xuelei Fan wrote: > What's the consideration to place selected_group out of the extensions filed > in HelloRetryRequest? An extension would work, except that I believe that extensions in HelloRetryRequest are going to carry somewhat different semantics to those in other Hello messages. If we go to dynamically generated groups, then we can easily define a new FFDHE code point to signal the use of a dynamic group. Though I think that I'd be sad about having to always spend an extra round trip if it came to that. Also, it's not much, but the explicit field keeps the message (a tiny bit) smaller and easier to process. From nobody Fri Nov 27 20: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 036471A8A50 for ; Fri, 27 Nov 2015 20:42:50 -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, 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 O_hJbyCIw86l for ; Fri, 27 Nov 2015 20:42:48 -0800 (PST) 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 ADE7C1A8A4E for ; Fri, 27 Nov 2015 20:42:48 -0800 (PST) Received: by obbnk6 with SMTP id nk6so93706158obb.2 for ; Fri, 27 Nov 2015 20:42:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vimino-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UsartusLTrmHn5neCtUsUUXAMTDBzLvELMCLFCouzYc=; b=CTC9qMhNdzmqFOjSU6Xd00cPChklEYmA1IjMr1xRBf8k8kgIAUntIz6IXKl41ZT6Bd TuaEMpC12Rz4U5EsFD+0PU7HEccaqiXa6YNOZXYyWMaZLimWY1unOifS5cbpym5SrBMn 2jXDtAdJGwmrg98Csmpo1XvwkbZrXTZuSJarfhV89x28Flv/ON7l9J+62RfGXnKtU+JS p7DZkTwpYuxmCf1s0H4LZ1fnki5ULzT5Cq9neR+82bYF6rz9eErVgytvYwqB/fR1dwND XydWgf9DTTCIfsQaOuFBxUNQyBadi3DYETPLnQYgd7jej1bwvBxDwX/265Tc6gq91/sp HqCw== 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=UsartusLTrmHn5neCtUsUUXAMTDBzLvELMCLFCouzYc=; b=gpcT+LfaKfTWth9lHuVAKExdmvA4t4FQylwrFec8qVQ8988bwYK8Fzf47PFRGnb+6C 8h8neXPA0ufm8hAILv3tbZwh03ZZ5FMrzZt83t70gn/XytDvS25j2pUkIY/9LkAbzG7P xSJvEecsGegcRwhH761lTpi+pJGijyiFfSWI4h7K77mxbxw5LuAwatJfrmMR6XZ2VJ2/ 7jA/AVOTNvOBWZV5OTZMl0mUr7CC+4eZO2ta96ue7zbFyG/F/iyJGWTV1K46WSVlJFFP 4fdF9pyN6z1Ts94CUCnRCD4zUfZOPGXPFCPA84uEeupBpT1OcCTGxq5mUm5z3Vll1mbd emPw== X-Gm-Message-State: ALoCoQnj7aN4b7B8IEw5Wr4oP+dU5CCPcIPgi3QKW+GX73bw1QzOn13XXYvHtgYAQ0KIMtiy4ayy MIME-Version: 1.0 X-Received: by 10.182.210.234 with SMTP id mx10mr35468211obc.47.1448685768075; Fri, 27 Nov 2015 20:42:48 -0800 (PST) Received: by 10.76.171.103 with HTTP; Fri, 27 Nov 2015 20:42:48 -0800 (PST) X-Originating-IP: [148.87.19.218] In-Reply-To: References: Date: Sat, 28 Nov 2015 12:42:48 +0800 Message-ID: From: Xuelei Fan To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11c2b46498fffe052592708a Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] "selected_group" field in HelloRetryRequest in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2015 04:42:50 -0000 --001a11c2b46498fffe052592708a Content-Type: text/plain; charset=UTF-8 It makes sense to me. It's OK if TLS 1.3 only supports (EC)DHE cipher suites. If it is extended to support other cipher suites, for example PSK or KRB5 cipher suites (which do not require named groups), the HelloRetryRequest.selected_group may be redundant if this extra RTT is required. As the ServerKeyExchange/ClientKeyExchange will be replaced with key_share extension, I'm still not sure of the impact on those cipher suites, including PSK and KRB5, that replies on ServerKeyExchange/ClientKeyExchange messages. Hopefully, no other cipher suites needs an extra RTT similar to HelloRetryRequest. Thanks & Regards, Xuelei On Sat, Nov 28, 2015 at 10:25 AM, Martin Thomson wrote: > On 26 November 2015 at 18:38, Xuelei Fan wrote: > > What's the consideration to place selected_group out of the extensions > filed > > in HelloRetryRequest? > > An extension would work, except that I believe that extensions in > HelloRetryRequest are going to carry somewhat different semantics to > those in other Hello messages. > > If we go to dynamically generated groups, then we can easily define a > new FFDHE code point to signal the use of a dynamic group. Though I > think that I'd be sad about having to always spend an extra round trip > if it came to that. > > Also, it's not much, but the explicit field keeps the message (a tiny > bit) smaller and easier to process. > --001a11c2b46498fffe052592708a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It makes sense to me.

It's OK if TL= S 1.3 only supports (EC)DHE cipher suites.=C2=A0 If it is extended to suppo= rt other cipher suites, for example PSK or KRB5 cipher suites (which do not= require named groups),=C2=A0the HelloRetryRequest.selected_group may be=C2= =A0redundant if this extra RTT is required.=C2=A0 As the ServerKeyExchange/= ClientKeyExchange will be replaced with key_share extension, I'm still = not sure of the impact on those cipher suites, including PSK and KRB5, that= replies on=C2=A0ServerKeyExchange/ClientKeyExchange messages.=C2=A0 Hopefu= lly, no other cipher suites needs an extra RTT similar to=C2=A0HelloRetryRequest.
=C2= =A0
Thanks & Regards,
Xuelei
=C2=A0
=
--001a11c2b46498fffe052592708a-- From nobody Sat Nov 28 03:16: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 3CD171ACDD6 for ; Sat, 28 Nov 2015 03:16:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.385 X-Spam-Level: X-Spam-Status: No, score=-3.385 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XT-Bc_lylc4Y for ; Sat, 28 Nov 2015 03:16:01 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47B051ACDD5 for ; Sat, 28 Nov 2015 03:16:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1448709361; x=1480245361; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=MMHghR63fMAOWVPUDhlFXRmO/rOtlfRwE6xABg57L4A=; b=DQSuP7TnFg+Q6MgjYfahWYFGqUCQXEvenUeeJgNV46aDOLO82jvjiPca 2S8vQHeRjnq+9aWlYFhg5lDyqGcrnczE0WA5PhgCng17go6Cgn9uNns1k WLD1C7tn/+ZeNIp+i6lAAJIsmqnINDWD2bfuLHau5hq9mMjkRI3bCcMy3 lbaKaOsL8y4q3+/kWCNcXjibPkM/toBuxO4LWB+kHj/8+GHVSw0r2EgSV Aj+PgMOtnW+603uac0jYEMT4kr6hag8Ep4ipk9qbPaKphjUgW23ezls7S rmu9ECAmPFncZJ/IIbRB55ZdmYubjQox0KCjst+3V4peSmzsXJggaYDZH w==; X-IronPort-AV: E=Sophos;i="5.20,356,1444647600"; d="scan'208";a="56518119" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxchange10-fe3.UoA.auckland.ac.nz) ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 29 Nov 2015 00:15:58 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.153]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0266.001; Sun, 29 Nov 2015 00:15:58 +1300 From: Peter Gutmann To: Bryan A Ford , "tls@ietf.org" Thread-Topic: [TLS] Encrypting record headers: practical for TLS 1.3 after all? Thread-Index: AQHRKSDnEzBCXT12GkOsH7hTugsdcp6xSade Date: Sat, 28 Nov 2015 11:15:57 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B8DA2A@uxcn10-5.UoA.auckland.ac.nz> References: <56586A2F.1070703@gmail.com> In-Reply-To: <56586A2F.1070703@gmail.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Nov 2015 11:16:05 -0000 Bryan A Ford writes:=0A= =0A= >The idea of encrypting TLS record headers has come up before, the most=0A= >important purpose being to hide record lengths and boundaries and make=0A= >fingerprinting and traffic analysis harder.=0A= =0A= Argh, no! I sent the following to the SSH list a few days ago in support o= f=0A= someone else's suggestion to finally abandon this misguided idea:=0A= =0A= -- Snip --=0A= =0A= SSL/TLS have used unencrypted lengths for twenty years without there being = any=0A= (known) attack or weakness based on this. OTOH SSH has used encrypted leng= ths=0A= for nearly the same period, and there have been several attacks/weaknesses= =0A= based on that. Security-wise, it has the opposite effect of the one intend= ed,=0A= it makes the protocol weaker, not stronger.=0A= =0A= My real issue with it though is that, as you've pointed out, it makes it=0A= impossible to create an efficient streaming implementation. With TLS you r= ead=0A= the length at the start, stream the rest into the target memory location, a= nd=0A= decrypt in place. With SSH you have to read a single block, decrypt it, ma= ke=0A= sure you're not providing an oracle for the attacker, copy what's left arou= nd,=0A= read more encrypted data onto the end, decrypt the remainder, ugh.=0A= =0A= -- Snip --=0A= =0A= Encrypting the length information is a serious step backwards both in terms= of=0A= security and processing efficiency.=0A= =0A= Peter.= From nobody Sat Nov 28 04:07: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 E8ABA1ACEA5 for ; Sat, 28 Nov 2015 04:06:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 RCY3_ouoxbCs for ; Sat, 28 Nov 2015 04:06:57 -0800 (PST) Received: from vsp5.ballou.se (vsp5.ballou.se [91.189.40.84]) by ietfa.amsl.com (Postfix) with SMTP id 6DC8C1ACEA4 for ; Sat, 28 Nov 2015 04:06:55 -0800 (PST) X-Halon-ID: 82c59eda-95c8-11e5-a259-005056921986 X-Halon-Scanned: 7f4a955dd6f4c149d51110a345668da22aa82d04 Received: from nmail1.ballou.se (unknown [10.0.0.116]) by vsp5.ballou.se (Halon Mail Gateway) with ESMTP; Sat, 28 Nov 2015 13:06:51 +0100 (CET) Received: from [192.168.0.190] (c-1ec0e555.06-134-73746f39.cust.bredbandsbolaget.se [85.229.192.30]) (Authenticated sender: henrick@streamsec.se) by nmail1.ballou.se (Postfix) with ESMTPSA id B4DC8C9378; Sat, 28 Nov 2015 13:06:51 +0100 (CET) References: <56586A2F.1070703@gmail.com> <565882FE.80205@streamsec.se> To: Kriss Andsten From: =?UTF-8?Q?Henrick_Hellstr=c3=b6m?= Message-ID: <56599884.2090609@streamsec.se> Date: Sat, 28 Nov 2015 13:05:24 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: henrick@streamsec.se List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2015 12:06:59 -0000 On 2015-11-28 12:30, Kriss Andsten wrote: > On 27 Nov 2015, at 17:21, Henrick Hellström wrote: > >> How, exactly, would this be significantly harder? The adversary will still be able to tell when, and how much, TCP/IP data is sent between the peers. If there happens to be a revealing TLS record boundary in the middle of a TCP/IP packet, it would seem to me there is an implementation problem rather than a problem with the abstract protocol. > > This is actually quite common. Even when it does align with packet boundaries, it is providing known information rather than inferred information ("here's a length X blob, then a length Y blob" vs "Here's a bunch of packets whose lengths minus TLS headers amount to to X+Y"). Maybe I have missed something, but this seems awfully implementation dependent to me. Let's take a more specific example: Suppose a web server is serving a request for a web page, which typically means that the client firstly sends a single HTTP request for the HTML page, and then multiple requests for the css, images, etc in a row. Most times, the latter row of requests could easily be encoded in a single TLS fragment. This means that the server will become aware of all of the requests at the same time, and might encode all of the HTTP responses before beginning to encode the TLS fragments. Carefully implemented, such a solution would not necessarily require significantly more resources to handle pipe-lining, compared to an alternative solution that would serve, encode and send the responses on-the-fly, and as a consequence quickly fill up the outgoing TCP/IP queue. From nobody Sat Nov 28 06:49: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 E32041B2B39 for ; Sat, 28 Nov 2015 06:49:02 -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 dnERTt8_SGvb for ; Sat, 28 Nov 2015 06:49:01 -0800 (PST) Received: from filtteri2.pp.htv.fi (filtteri2.pp.htv.fi [213.243.153.185]) by ietfa.amsl.com (Postfix) with ESMTP id 063051B2B34 for ; Sat, 28 Nov 2015 06:49:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by filtteri2.pp.htv.fi (Postfix) with ESMTP id 9FF4C19C1D1; Sat, 28 Nov 2015 16:48:59 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from smtp4.welho.com ([213.243.153.38]) by localhost (filtteri2.pp.htv.fi [213.243.153.185]) (amavisd-new, port 10024) with ESMTP id ruR+npY6mmKV; Sat, 28 Nov 2015 16:48:59 +0200 (EET) Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp4.welho.com (Postfix) with ESMTPSA id 759B25BC005; Sat, 28 Nov 2015 16:48:59 +0200 (EET) Date: Sat, 28 Nov 2015 16:48:57 +0200 From: Ilari Liusvaara To: Martin Thomson Message-ID: <20151128144857.GA11924@LK-Perkele-V2.elisa-laajakaista.fi> References: <385E6AFF-52C3-4E40-A69F-178602A449A7@sn3rd.com> <45D7CFCA-1ABE-4123-9E27-4DB5B8B6D9DA@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "" Subject: Re: [TLS] Early code point assignments for 25519/448 curves X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Nov 2015 14:49:03 -0000 On Mon, Nov 23, 2015 at 01:16:35PM -0800, Martin Thomson wrote: > > Are we happy that we will only be needing the PureEdDSA variants and > that no-one will be asking for the HashEdDSA versions? I ask because > I've heard it suggested (I think Karthik mentioned this) that we might > want to sign the transcript directly in TLS 1.3 rather than rely on > collision-resistance of the selected hash function. That would be > harder without access to HashEdDSA. Also, one problem with signing the transcript directly is that because of the context prefixes, one would either have to buffer all messages or compute multiple hashes. It is made worse by the fact that some hashes and signatures don't mix very well. For example, trying to use SHA-512 with ECDSA is not a good idea[1] (and nobody knows yet what the heck X448ph will use[2]). Also, does the present 1-RTT construct in fact rely on collision- resistance of the prf-hash? [1] Well, it would be a good idea with ECDSA/P-521, but who uses that? [2] Proposals so far have included: - SHA-512 - SHA3-512 (whee, SLOW) - Shake256@512b (not a hash, but cryptographically looks OK). - Sakee256@512b with some prefixing. (That's just including the ones in more formal proposing, not the earlier more handwavy proposals). -Ilari From nobody Sat Nov 28 08:42: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 02AC11B31B9 for ; Sat, 28 Nov 2015 08:42:05 -0800 (PST) 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 OCKGrRfyFvO1 for ; Sat, 28 Nov 2015 08:42:03 -0800 (PST) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::5]) (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 0CCBD1B319D for ; Sat, 28 Nov 2015 08:42:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1448728919; l=2290; s=domk; d=zinks.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:From:References:To:Subject; bh=/Vmm3LLImYY0OShHb0BM9MmbDV1K0L6HkhWmdKiPFzU=; b=Cuct/PZC/Rww28hIF1EBO5l2ab6qa4RacFT/oodZSMTlHMDcRPnDURYgUcLE//pHmBo M60LpA+vjP1nG9FkZO3/yubJbpsuTxqumhTXVWQNf+hEqu8+dXj5npxW2jv0hDG16xBg6 UWNmNSWbuzo5TP7+4UY/ngwC0oe4f4FmJtI= X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9KAK33vRJaCwLQNJU2mlIkBC0t1G+0bSVECAiLyDqLcHdRVpdc4pNvaGg0hjQJme/g== X-RZG-CLASS-ID: mo00 Received: from [IPv6:2001:4dd0:ff67:0:24f5:116e:f0a9:dfcc] ([2001:4dd0:ff67:0:24f5:116e:f0a9:dfcc]) by smtp.strato.de (RZmta 37.14 AUTH) with ESMTPSA id j00972rASGfxIAu (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Sat, 28 Nov 2015 17:41:59 +0100 (CET) To: tls@ietf.org References: <56586A2F.1070703@gmail.com> <565882FE.80205@streamsec.se> <56599884.2090609@streamsec.se> From: Roland Zink Message-ID: <5659D957.3030909@zinks.de> Date: Sat, 28 Nov 2015 17:41:59 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <56599884.2090609@streamsec.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Nov 2015 16:42:05 -0000 Am 28.11.2015 um 13:05 schrieb Henrick Hellström: > On 2015-11-28 12:30, Kriss Andsten wrote: >> On 27 Nov 2015, at 17:21, Henrick Hellström >> wrote: >> >>> How, exactly, would this be significantly harder? The adversary will >>> still be able to tell when, and how much, TCP/IP data is sent >>> between the peers. If there happens to be a revealing TLS record >>> boundary in the middle of a TCP/IP packet, it would seem to me there >>> is an implementation problem rather than a problem with the abstract >>> protocol. >> >> This is actually quite common. Even when it does align with packet >> boundaries, it is providing known information rather than inferred >> information ("here's a length X blob, then a length Y blob" vs >> "Here's a bunch of packets whose lengths minus TLS headers amount to >> to X+Y"). > > Maybe I have missed something, but this seems awfully implementation > dependent to me. Let's take a more specific example: > > Suppose a web server is serving a request for a web page, which > typically means that the client firstly sends a single HTTP request > for the HTML page, and then multiple requests for the css, images, etc > in a row. > > Most times, the latter row of requests could easily be encoded in a > single TLS fragment. This means that the server will become aware of > all of the requests at the same time, and might encode all of the HTTP > responses before beginning to encode the TLS fragments. Even if it could be encoded in a single TLS fragment a simple minded browser may encode it one by one. Also there are many more use cases where such optimization may not work. Can you provide data what browsers are actually doing for HTTP/1.1 and HTTP2? > > Carefully implemented, such a solution would not necessarily require > significantly more resources to handle pipe-lining, compared to an > alternative solution that would serve, encode and send the responses > on-the-fly, and as a consequence quickly fill up the outgoing TCP/IP > queue. > I think it is more complicated so it will use more resources. You have to weight what is more important, the additional "security" or the "overhead". Anyway I thought the decision was to hide the record length. Regards, Roland From nobody Sat Nov 28 08:58: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 7BCF51B320B for ; Sat, 28 Nov 2015 08:58:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 LcYWF7wI96RO for ; Sat, 28 Nov 2015 08:58:27 -0800 (PST) Received: from vsp1.ballou.se (vsp1.ballou.se [91.189.40.82]) by ietfa.amsl.com (Postfix) with SMTP id 220D51B3209 for ; Sat, 28 Nov 2015 08:58:26 -0800 (PST) X-Halon-ID: 3c57eb69-95f1-11e5-b567-005056925495 X-Halon-Scanned: 7f4a955dd6f4c149d51110a345668da22aa82d04 Received: from nmail1.ballou.se (unknown [10.0.0.116]) by vsp1.ballou.se (Halon Mail Gateway) with ESMTP for ; Sat, 28 Nov 2015 17:58:23 +0100 (CET) Received: from [192.168.0.190] (c-1ec0e555.06-134-73746f39.cust.bredbandsbolaget.se [85.229.192.30]) (Authenticated sender: henrick@streamsec.se) by nmail1.ballou.se (Postfix) with ESMTPSA id 66672C9378 for ; Sat, 28 Nov 2015 17:58:23 +0100 (CET) References: <56586A2F.1070703@gmail.com> <565882FE.80205@streamsec.se> <56599884.2090609@streamsec.se> <5659D957.3030909@zinks.de> To: tls@ietf.org From: =?UTF-8?Q?Henrick_Hellstr=c3=b6m?= Message-ID: <5659DCD8.2030400@streamsec.se> Date: Sat, 28 Nov 2015 17:56:56 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <5659D957.3030909@zinks.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: henrick@streamsec.se List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2015 16:58:29 -0000 On 2015-11-28 17:41, Roland Zink wrote: >> Most times, the latter row of requests could easily be encoded in a >> single TLS fragment. This means that the server will become aware of >> all of the requests at the same time, and might encode all of the HTTP >> responses before beginning to encode the TLS fragments. > Even if it could be encoded in a single TLS fragment a simple minded > browser may encode it one by one. Also there are many more use cases > where such optimization may not work. Can you provide data what browsers > are actually doing for HTTP/1.1 and HTTP2? AFAIK, HTTP 1.1 browsers typically don't send a new request over an open connection, before it has received the response to the previous request. If that is the case, it is trivial to get the message lengths from the traffic, with or without encrypted TLS record headers. IOW you gain nothing by encrypting the length fields. >> Carefully implemented, such a solution would not necessarily require >> significantly more resources to handle pipe-lining, compared to an >> alternative solution that would serve, encode and send the responses >> on-the-fly, and as a consequence quickly fill up the outgoing TCP/IP >> queue. >> > I think it is more complicated so it will use more resources. You have > to weight what is more important, the additional "security" or the > "overhead". Anyway I thought the decision was to hide the record length. You will have to make sure the peer is sending out a continuous stream of encrypted messages, anyway, or else you will not gain much by encrypting the TLS record headers. Relying on TLS fragments piling up at the TCP/IP level, rather than at the application level or TLS level, is not a reliable way to make traffic analysis harder. Even if the responses to a specific pair of requests pile up 999 times of 1000, there will still be a signal from the 1 in 1000 event that will be detectable by traffic analysis. From nobody Sat Nov 28 09:05:15 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A18EA1B3233 for ; Sat, 28 Nov 2015 09:05:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 Ziyve-ImVQQh for ; Sat, 28 Nov 2015 09:05:12 -0800 (PST) Received: from vsp1.ballou.se (vsp1.ballou.se [91.189.40.82]) by ietfa.amsl.com (Postfix) with SMTP id 73F931B3232 for ; Sat, 28 Nov 2015 09:05:11 -0800 (PST) X-Halon-ID: 2dfba2b2-95f2-11e5-b567-005056925495 X-Halon-Scanned: 7f4a955dd6f4c149d51110a345668da22aa82d04 Received: from nmail1.ballou.se (unknown [10.0.0.116]) by vsp1.ballou.se (Halon Mail Gateway) with ESMTP for ; Sat, 28 Nov 2015 18:05:08 +0100 (CET) Received: from [192.168.0.190] (c-1ec0e555.06-134-73746f39.cust.bredbandsbolaget.se [85.229.192.30]) (Authenticated sender: henrick@streamsec.se) by nmail1.ballou.se (Postfix) with ESMTPSA id A122BC9378 for ; Sat, 28 Nov 2015 18:05:08 +0100 (CET) References: <56586A2F.1070703@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B8DA2A@uxcn10-5.UoA.auckland.ac.nz> To: tls@ietf.org From: =?UTF-8?Q?Henrick_Hellstr=c3=b6m?= Message-ID: <5659DE6D.8030809@streamsec.se> Date: Sat, 28 Nov 2015 18:03:41 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B8DA2A@uxcn10-5.UoA.auckland.ac.nz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: henrick@streamsec.se List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2015 17:05:13 -0000 On 2015-11-28 12:15, Peter Gutmann wrote: > Encrypting the length information is a serious step backwards both in terms of > security and processing efficiency. I am inclined to +1 on that. From nobody Sat Nov 28 09:05: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 A9D321B3237 for ; Sat, 28 Nov 2015 09:05:26 -0800 (PST) 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 u3zMq21Ccj0T for ; Sat, 28 Nov 2015 09:05:26 -0800 (PST) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::11]) (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 98EE11B323D for ; Sat, 28 Nov 2015 09:05:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1448730323; l=498; s=domk; d=zinks.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:From:References:To:Subject; bh=ve0rUwUib/NDVU/QbXBaC7KvYVt6BHqUm4q/me2FMmA=; b=mOrTUoocznK2aBOOVtHRTBNl5sW2SwfcZlJ3mBtgFMTT26Uhwo9kMAslufrycHwivNU D9oTrpgTtYhjoB82GVptQV0RnvH1onbvd8TLLiFTROn9yxmr1hBBv/Y3KezEvck0kv2yx 4k0aeo8MjZBpERpCCJafNMbNj+v1xpBRHEY= X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9KAK33vRJaCwLQNJU2mlIkBC0t1G+0bSVECAiLyDqLcHdRVpdc4pNvaGg0hjQJme/g== X-RZG-CLASS-ID: mo00 Received: from [IPv6:2001:4dd0:ff67:0:24f5:116e:f0a9:dfcc] ([2001:4dd0:ff67:0:24f5:116e:f0a9:dfcc]) by smtp.strato.de (RZmta 37.14 AUTH) with ESMTPSA id D04411rASH5NNdQ (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Sat, 28 Nov 2015 18:05:23 +0100 (CET) To: tls@ietf.org References: <56586A2F.1070703@gmail.com> <565882FE.80205@streamsec.se> <56599884.2090609@streamsec.se> <5659D957.3030909@zinks.de> <5659DCD8.2030400@streamsec.se> From: Roland Zink Message-ID: <5659DED3.3030908@zinks.de> Date: Sat, 28 Nov 2015 18:05:23 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5659DCD8.2030400@streamsec.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Nov 2015 17:05:26 -0000 Am 28.11.2015 um 17:56 schrieb Henrick Hellström: > AFAIK, HTTP 1.1 browsers typically don't send a new request over an > open connection, before it has received the response to the previous > request. If that is the case, it is trivial to get the message lengths > from the traffic, with or without encrypted TLS record headers. IOW > you gain nothing by encrypting the length fields. > I think this is what browsers do by default. For HTTP2 this should be different. Regards, Roland From nobody Sat Nov 28 10:08: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 2CA071B3371 for ; Sat, 28 Nov 2015 10:08:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nEGFqAHWwU8g for ; Sat, 28 Nov 2015 10:08:29 -0800 (PST) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::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 B3BC71B3370 for ; Sat, 28 Nov 2015 10:08:29 -0800 (PST) Received: by igbxm8 with SMTP id xm8so47515268igb.1 for ; Sat, 28 Nov 2015 10:08:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=8KePz5uCNEdUmyCCyI/ou6Qb8TnzCZno/WFnNdc+ZnI=; b=LnhZ3BT7vrllJR7cun9VZhi1qYQx5IQbLS/OM1UITmddhHI8By+3bXqXpAkjWzcu2Z z1TRV14SfKwDCGeQiYAtQSFHqvqulhqTsODpwzGYCUUOAtplrUt29Qv8B170VVFbz+Nl ma2e6CXgQh1cpOh5OQYS583EH2mXZLyTvCKd/Qv9gy5nnWrKm2hghwllCePMYGOZVJHS DfefUN2L7c5z6HLS8yoO+wfFr4zo2Ix3ZwUlB+l4FRk4tp8caK6K5CXev0Fomi9Heyd+ NsxsN+hnD/H/kV+juV008XfXeKRXdvi1Zo3tM8FNk5yEqNlszdBX1GVVzCIRRHGlSGol sJqA== X-Received: by 10.50.225.105 with SMTP id rj9mr14041525igc.55.1448734109049; Sat, 28 Nov 2015 10:08:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.33.21 with HTTP; Sat, 28 Nov 2015 10:08:09 -0800 (PST) In-Reply-To: <5659DED3.3030908@zinks.de> References: <56586A2F.1070703@gmail.com> <565882FE.80205@streamsec.se> <56599884.2090609@streamsec.se> <5659D957.3030909@zinks.de> <5659DCD8.2030400@streamsec.se> <5659DED3.3030908@zinks.de> From: Tony Arcieri Date: Sat, 28 Nov 2015 11:08:09 -0700 Message-ID: To: Roland Zink Content-Type: multipart/alternative; boundary=001a11c3a57cf1ac0d05259db1de Archived-At: Cc: "" Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Nov 2015 18:08:31 -0000 --001a11c3a57cf1ac0d05259db1de Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Nov 28, 2015 at 10:05 AM, Roland Zink wrote: > Am 28.11.2015 um 17:56 schrieb Henrick Hellstr=C3=B6m: > >> AFAIK, HTTP 1.1 browsers typically don't send a new request over an open >> connection, before it has received the response to the previous request.= If >> that is the case, it is trivial to get the message lengths from the >> traffic, with or without encrypted TLS record headers. IOW you gain noth= ing >> by encrypting the length fields. >> >> I think this is what browsers do by default. For HTTP2 this should be > different. This is HTTP/1.1 pipelining, which is supported by most browsers but typically disabled by default as most servers don't support pipelining correctly. --=20 Tony Arcieri --001a11c3a57cf1ac0d05259db1de Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --001a11c3a57cf1ac0d05259db1de-- From nobody Sat Nov 28 10:21: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 94D071B33B2 for ; Sat, 28 Nov 2015 10:21:51 -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 SX4L3tMGod9V for ; Sat, 28 Nov 2015 10:21:50 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B4CC1B33B1 for ; Sat, 28 Nov 2015 10:21:50 -0800 (PST) Received: by wmww144 with SMTP id w144so85818732wmw.1 for ; Sat, 28 Nov 2015 10:21:48 -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 :content-transfer-encoding:message-id:references:to; bh=t507vI4dC7UaZ+dEa8L2mJ2GRnONb3OcTNf/sYpgVcE=; b=VTTTDoRg/OT6hLjSho6zctP5cczMv1b+6JZHJv6po3yJA5FBnsLhOVs7mRkHOmBRy5 +28FSd3wwb9XdT6rpyIWhbNGsdXyF7JgkRccru4fdq8iQ7HfDLhpv+wSPvT3Av5d4oQV /q94YxClbR/2Kvj09MXf+DOFeTTanZ47mrVaYHQJZQFalXA19q+YGSBgMFbuYMXLKT95 qvKD8JLqrfHf7LNpjUZcKq33gmF6R5OLwpSBARL8zOo5VwySPDYGK18RPd4Qno4kVMOg oQHQ9rFEuvYDRezQ2K5g1V+fsDwL+iH4mSKgEeefj7fw17SLNM1gsaGP81gszwSPZ+O/ uQCw== X-Received: by 10.194.24.70 with SMTP id s6mr14301939wjf.74.1448734908774; Sat, 28 Nov 2015 10:21:48 -0800 (PST) Received: from [192.168.1.10] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id o65sm13358610wmg.3.2015.11.28.10.21.46 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 28 Nov 2015 10:21:47 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Yoav Nir In-Reply-To: <20151128144857.GA11924@LK-Perkele-V2.elisa-laajakaista.fi> Date: Sat, 28 Nov 2015 20:21:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9B5F1183-785C-4002-804C-415828E3C1D3@gmail.com> References: <385E6AFF-52C3-4E40-A69F-178602A449A7@sn3rd.com> <45D7CFCA-1ABE-4123-9E27-4DB5B8B6D9DA@gmail.com> <20151128144857.GA11924@LK-Perkele-V2.elisa-laajakaista.fi> To: Ilari Liusvaara X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: "" Subject: Re: [TLS] Early code point assignments for 25519/448 curves X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Nov 2015 18:21:51 -0000 > On 28 Nov 2015, at 4:48 PM, Ilari Liusvaara = wrote: >=20 > On Mon, Nov 23, 2015 at 01:16:35PM -0800, Martin Thomson wrote: >>=20 >> Are we happy that we will only be needing the PureEdDSA variants and >> that no-one will be asking for the HashEdDSA versions? I ask because >> I've heard it suggested (I think Karthik mentioned this) that we = might >> want to sign the transcript directly in TLS 1.3 rather than rely on >> collision-resistance of the selected hash function. That would be >> harder without access to HashEdDSA. >=20 > Also, one problem with signing the transcript directly is that because > of the context prefixes, one would either have to buffer all messages > or compute multiple hashes. I think buffering all messages is fine for a regular handshake. The = problem begins when you have a certificateRequest later in the = negotiation, leading to a certificateVerify which signs the entire = transcript. This means that we need to keep the transcript for the = duration of the connection just in case the server decides to send a = certificateRequest. If a late certificateRequest signed something other than the entire = transcript, I would be very much in favor of signing directly. Yoav From nobody Sat Nov 28 10:59: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 37E811B33FE for ; Sat, 28 Nov 2015 10:58:59 -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 KDTHyzMDDi99 for ; Sat, 28 Nov 2015 10:58:57 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::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 2EFE51B33FD for ; Sat, 28 Nov 2015 10:58:57 -0800 (PST) Received: by wmuu63 with SMTP id u63so86356078wmu.0 for ; Sat, 28 Nov 2015 10:58:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hnIwaABDB1+FiuQVsycRM4iYlY4k1jCcKg/qt1hf/6M=; b=zcSGzfxo8JGkIKR8fec6EPNK3rNnV+sJ2nBUGWpSssxK+8IzoT29m0a5LhV3RuyR5c BYIOl7r7PKlOmAOBWtXjvv7yRcvmsEXta4Mp98gp0cqyIbZWxu42U0n+4WUh6UGRmOJe nrkg84CXJaXT3PCAQs0rp/NkTe/tn7oI3nVfhyVL0mmNJuMnbfMfyWt66cGOb4iqpiTE F1G//gbi9xOhS9chTrTJnT3sTIIyuaIYYi5AbbeFECCbL3CP+5cYPA+t+vwulwGwHc2j mB24XnL3zJa9r3GvycXiJ/EADhwCNPitbggq0NDc3x2JbNoErO6amJOVoESNmOszAHHg spXA== MIME-Version: 1.0 X-Received: by 10.194.200.227 with SMTP id jv3mr19486689wjc.20.1448737135761; Sat, 28 Nov 2015 10:58:55 -0800 (PST) Received: by 10.28.102.84 with HTTP; Sat, 28 Nov 2015 10:58:55 -0800 (PST) In-Reply-To: References: <56586A2F.1070703@gmail.com> <565882FE.80205@streamsec.se> <56599884.2090609@streamsec.se> <5659D957.3030909@zinks.de> <5659DCD8.2030400@streamsec.se> <5659DED3.3030908@zinks.de> Date: Sat, 28 Nov 2015 13:58:55 -0500 Message-ID: From: Watson Ladd To: Tony Arcieri Content-Type: multipart/alternative; boundary=047d7b8750da59a12605259e66c0 Archived-At: Cc: "" Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Nov 2015 18:58:59 -0000 --047d7b8750da59a12605259e66c0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Nov 28, 2015 at 1:08 PM, Tony Arcieri wrote: > On Sat, Nov 28, 2015 at 10:05 AM, Roland Zink wrote: > >> Am 28.11.2015 um 17:56 schrieb Henrick Hellstr=C3=B6m: >> >>> AFAIK, HTTP 1.1 browsers typically don't send a new request over an ope= n >>> connection, before it has received the response to the previous request= . If >>> that is the case, it is trivial to get the message lengths from the >>> traffic, with or without encrypted TLS record headers. IOW you gain not= hing >>> by encrypting the length fields. >>> >>> I think this is what browsers do by default. For HTTP2 this should be >> different. > > > This is HTTP/1.1 pipelining, which is supported by most browsers but > typically disabled by default as most servers don't support pipelining > correctly. > I think the above analysis is wrong. Consider a service written in Go using the built-in TLS library. Then the number and sizes of writes is visible to an attacker, which can reveal information about which branches were taken and the data sent. That's not because the total size of the response necessarily changes, but the sequence of writes taken to get there. > -- > Tony Arcieri > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --=20 "Man is born free, but everywhere he is in chains". --Rousseau. --047d7b8750da59a12605259e66c0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Sat, Nov= 28, 2015 at 10:25 AM, Martin Thomson <martin.thomson@gmail.com= > wrote:
On 26= November 2015 at 18:38, Xuelei Fan <xuelei.fan@vimino.com> wrote:
> What's the consideration to place selected_group out of the extens= ions filed
> in HelloRetryRequest?

An extension would work, except that I believe that extensions in HelloRetryRequest are going to carry somewhat different semantics to
those in other Hello messages.

If we go to dynamically generated groups, then we can easily define a
new FFDHE code point to signal the use of a dynamic group.=C2=A0 Though I think that I'd be sad about having to always spend an extra round trip<= br> if it came to that.

Also, it's not much, but the explicit field keeps the message (a tiny bit) smaller and easier to process.

--047d7b8750da59a12605259e66c0-- From nobody Sat Nov 28 11:22: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 65DE71B346B for ; Sat, 28 Nov 2015 11:22:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 bmdTlZgAzcxQ for ; Sat, 28 Nov 2015 11:22:07 -0800 (PST) Received: from vsp6.ballou.se (vsp6.ballou.se [91.189.40.85]) by ietfa.amsl.com (Postfix) with SMTP id F24BD1B346A for ; Sat, 28 Nov 2015 11:22:06 -0800 (PST) X-Halon-ID: 4e14d85b-9605-11e5-a960-00505692585a X-Halon-Scanned: 7f4a955dd6f4c149d51110a345668da22aa82d04 Received: from nmail1.ballou.se (unknown [10.0.0.116]) by vsp6.ballou.se (Halon Mail Gateway) with ESMTP for ; Sat, 28 Nov 2015 20:22:03 +0100 (CET) Received: from [192.168.0.190] (c-1ec0e555.06-134-73746f39.cust.bredbandsbolaget.se [85.229.192.30]) (Authenticated sender: henrick@streamsec.se) by nmail1.ballou.se (Postfix) with ESMTPSA id 08B5CC9378 for ; Sat, 28 Nov 2015 20:22:03 +0100 (CET) References: <56586A2F.1070703@gmail.com> <565882FE.80205@streamsec.se> <56599884.2090609@streamsec.se> <5659D957.3030909@zinks.de> <5659DCD8.2030400@streamsec.se> <5659DED3.3030908@zinks.de> To: tls@ietf.org From: =?UTF-8?Q?Henrick_Hellstr=c3=b6m?= Message-ID: <5659FE84.8050509@streamsec.se> Date: Sat, 28 Nov 2015 20:20:36 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: henrick@streamsec.se List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2015 19:22:09 -0000 On 2015-11-28 19:58, Watson Ladd wrote: > I think the above analysis is wrong. Consider a service written in Go > using the built-in TLS library. Then the number and sizes of writes is > visible to an attacker, which can reveal information about which > branches were taken and the data sent. That's not because the total size > of the response necessarily changes, but the sequence of writes taken to > get there. I am not familiar with the internals of that implementation, but if the individual writes are immediately TLS encrypted and sent over the network, the timing of the TCP/IP data will likely leak a lot of information about the number and sizes of writes as well. It doesn't seem like a perfect design choice to use encryption to hide information that will leak with non-negligible probability anyway. From nobody Sun Nov 29 01: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 9074B1B3007 for ; Sun, 29 Nov 2015 01:16:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KAWUIq3RCT6S for ; Sun, 29 Nov 2015 01:16:35 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02FB61B3006 for ; Sun, 29 Nov 2015 01:16:35 -0800 (PST) Received: by wmvv187 with SMTP id v187so117835025wmv.1 for ; Sun, 29 Nov 2015 01:16:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=SC2s056CfGRHTwauvmrSfOt45JrSMsLeU9w8BurSF60=; b=R1pc2i1ewo+YTqGuFgSo+9m0FyE5uVBc9rEvEmM09sYxr74HTYswQJVVf7VsuahfoS cVrCHEKDTz5qE2dDVlLoQNOQddaBKoKbN9OrUxph32Z+JpUavRw8HlmJyxcQh2JKfdH+ xpAiBrzGIZPhe6lfNwX9x8pnRvvfiAHq5vg2yMzTPJ6hJnOBXdktnCEQV3dNKgecqEpL xI1yFoLmOYFSZOPZBf+/bgkVPm7dA+99q+m29Aleem/ZeD6bSrC6DfBStXQoCQmfnlcN KOt9HCtRaxlJE4hVYZb0cuEP7QntW52htlFLcyvLkFIiUcM+qvKXImcmzAV9634Y72C3 ko4g== X-Received: by 10.194.186.170 with SMTP id fl10mr63632150wjc.91.1448788593598; Sun, 29 Nov 2015 01:16:33 -0800 (PST) Received: from proz.dclient.lsne.ch (85-218-12-53.dclient.lsne.ch. [85.218.12.53]) by smtp.gmail.com with ESMTPSA id c4sm41202563wjs.36.2015.11.29.01.16.31 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 29 Nov 2015 01:16:31 -0800 (PST) To: Peter Gutmann , "tls@ietf.org" References: <56586A2F.1070703@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B8DA2A@uxcn10-5.UoA.auckland.ac.nz> From: Bryan A Ford X-Enigmail-Draft-Status: N1110 Message-ID: <565AC278.2010904@gmail.com> Date: Sun, 29 Nov 2015 10:16:40 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B8DA2A@uxcn10-5.UoA.auckland.ac.nz> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070308020507070705010402" Archived-At: Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Nov 2015 09:16:37 -0000 This is a cryptographically signed message in MIME format. --------------ms070308020507070705010402 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Peter, On 11/28/15 12:15 PM, Peter Gutmann wrote: > Bryan A Ford writes: > SSL/TLS have used unencrypted lengths for twenty years without there be= ing any > (known) attack or weakness based on this. =20 Leaving all headers in the clear (and in particular record lengths) is a huge side-channel, and historical experience is that attackers are getting better and better at exploiting side-channels in surprising ways. The CRIME attack, for example, applied to a close relative of TLS (namely SPDY), and exploited the attacker's ability to learn precise information about (compressed in this case) record lengths. I'm not saying that hiding TLS/SPDY record lengths in particular would necessarily address the CRIME attack (there were many factors involved and a combination of weaknesses), but it is certainly an attack in which the attacker's ability to see fine-grained length information was a factor. The general lesson is simply that lengths do represent sometimes-exploitable side-channels. > OTOH SSH has used encrypted lengths > for nearly the same period, and there have been several attacks/weaknes= ses > based on that. Security-wise, it has the opposite effect of the one in= tended, > it makes the protocol weaker, not stronger. You're conflating the goal (hiding TLS headers) with one particular old, broken approach to achieving that goal (namely SSH's). I am not proposing to hide TLS headers in the same way SSH did, and just because one historical approach to hiding headers was broken doesn't mean that the goal itself is a bad idea, or that all possible ways to achieve that goal are broken, or that my proposal in particular is broken. Feel free to attack my proposal but then please attack *my* proposal, not the old broken SSH approach. I already addressed one specific weakness the SSH approach had and explained why that's not an issue in my proposal. You allude to "several attacks/weaknesses" SSH had: if there were several, can you summarize or point me to information about the others? And can you say whether and in what way any of those past weaknesses in SSH might conceivably apply to my proposed approach? I claim you won't be able to (but would be happy to be shown wrong), because there appears to be a rather trivial "security proof" that my proposed hiding approach can't possibly create any new security weaknesses that weren't already in TLS 1.3 as currently specified. I already outlined that reasoning in my proposal but will expand on it a bit more below. > My real issue with it though is that, as you've pointed out, it makes i= t > impossible to create an efficient streaming implementation. With TLS y= ou read > the length at the start, stream the rest into the target memory locatio= n, and > decrypt in place. With SSH you have to read a single block, decrypt it= , make > sure you're not providing an oracle for the attacker, copy what's left = around, > read more encrypted data onto the end, decrypt the remainder, ugh. How exactly does my proposal make it "impossible to create an efficient streaming implementation"? Again, it sounds like you're attacking SSH's broken approach while ignoring my proposal itself. With my proposal you can still perform exactly the same optimization just as before: 1. Read the 5-byte TLS header at the start, and decrypt it by XORing with the output of the stream cipher as my proposal specifies, so you now have the length. 2. Stream the rest into the target memory location, and AEAD-decrypt in place. I don't see how my proposal in any way makes life more difficult for such streaming optimizations, because my proposal keeps encryption/decryption of TLS headers separate from encryption/decryption of the body. What *might* make this optimization a bit more difficult is the MAC that the AEAD wants to attach to each ciphertext, but if that's a problem it's caused by TLS's use of AEAD and has nothing to do with my proposal. (That problem can in principle be worked around if the AEAD cipher implementation has a simple "scatter/gather" capability so it can put the MAC elsewhere, but that's a completely separate and orthogonal topic.) Now, returning to your concern about TLS header hiding creating security weaknesses: my claim is that all that my proposal introduces is a change of encoding of the 5-byte TLS header, which cannot possibly introduce any new security weaknesses because it is not affecting in any way the actual information content transmitted or received in the protocol or the way it is processed outside of that header encoding change. Consider this example: Suppose we decided we wanted the 2-byte length field in the TLS header to be transmitted in little-endian rather than big-endian. A useless change, yes, but could it create a new security vulnerability that TLS 1.3 doesn't already have as specified? Obviously not; this would yield a perfectly (and provably) equivalent protocol. Similarly, what if we decided for whatever reason it would be nice to XOR the 5-byte length field with the constant five-byte sequence [0x55,0x55,0x55,0x55,0x55]? Could that create a new security vulnerability? Again, obviously not. What if we decided that the TLS headers of odd-numbered records should be XORed with [0x55,0x55,0x55,0x55,0x55], and the even-numbered records should be XORed with [0xaa,0xaa,0xaa,0xaa,0xaa]. Could that create a new security vulnerability? No, it's still just an encoding change - just one that happens to depend dynamically on record number. What if we decided that the TLS headers should be XORed with an MD5 hash of the record number? Again, useless from a security perspective, but not harmful either: it's still just changing the TLS header encoding without changing anything else about how the protocol works - and in particular doesn't change anything about how the record is AEAD-protected or how the protocol behaves if an attacker flips any bits.= What if we decided that the TLS headers should be XORed with an HMAC-SHA256 of the record number, keyed with a shared secret used only for TLS header hiding? This is now (finally) potentially useful from a security perspective, and is basically isomorphic to my proposal - but even if the attacker could break HMAC-SHA256 tomorrow or could learn the shared secret used for TLS header protection, we would just be back to the same security level as TLS's current cleartext-header design achieves; we would still not be introducing any new security weaknesses that TLS 1.3 doesn't already have. Again, if you believe my reasoning is in any way flawed here, please point out how you think my proposal (*not* the old SSH approach) could conceivably introduce any new security weaknesses that TLS 1.3 doesn't already have. Thanks Bryan --------------ms070308020507070705010402 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfgwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVBMIIEKaADAgECAhAWpZtNxHBkhVoG2HKaeabqMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwNjI0MDAwMDAwWhcNMTYwNjIzMjM1OTU5WjAmMSQwIgYJKoZIhvcNAQkB FhVicnlub3NhdXJ1c0BnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDAPPVOZLVu2tZOao2osnGxGwYy7nC3UX8yoebrOfaNWkItIkUH6NQRKuqxuDE7127q48VH c7kwmg4DifoOjxSjXyT+R9pR/ethFwjXiWCjsIaWbcFc6X7D1fIisO14z8D4luBO1LezNVB6 Dee8lMutP9OO4MmKWYq3+Jab9Rv/3BXCyiDDQfxhiuWFzZQTWpbzGGfwitcqPHH97PN4COCh hhOuUS9Yt1qQBY8Gn36eVepKdz3YiF7ii/JDth1iA/zHK8pyim+OgERcwo6Ildqh59uy0IjM AcKA1Mc34AgMQJdLlmhYAai5nMLOJQiFzfIyB6egjSyishx11rpL/xKlAgMBAAGjggHzMIIB 7zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQUpXGtiQ4RgWPr 1UjnydSPtyPTai8wDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYI KwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsG DCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEF BQcBAQSBgzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RP U0hBMjU2Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEF BQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCAGA1UdEQQZMBeBFWJyeW5vc2F1cnVz QGdtYWlsLmNvbTANBgkqhkiG9w0BAQsFAAOCAQEADDSBNRYWArRAPSTMC6DSrUOIWQ3J1CmE XEYoQ4QByCkkybRUCgXIadTAUwj+D9ZX4HQxxvtOkb+uVQCnwbI6jGZj0Mpb7MWYOZDyeQT1 YEoUMRpeUUpTDd6iw3Em0Lf+rj7/VPlYKvErTCOnyEUm2z8MismcjPIFJ8Ud+HccyfpkhotJ HbVBN+hSGm03l7YxVVzf9owzq7L5vCB5afJyTNt5x7qlLCcsiGBW2kSoQKaDAMwuYMp5YOgD 1doc/yWJSkiQAcKcWY2ALacs+a0FSItqT1rNk3tnHX2spIrBgDrv+5ybZXBBjAknetbTON5m rWT2tzLgYpKPJLs49ETIoDGCBEEwggQ9AgEBMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UE CBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJYIZIAWUD BAIBBQCgggJhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MTEyOTA5MTY0MFowLwYJKoZIhvcNAQkEMSIEIEz4iy6+e8jucPIgCVTjMND0U2ePP25BefXj qd+uU0/8MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgcEGCSsGAQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAWpZtNxHBkhVoG2HKaeabqMIHDBgsqhkiG9w0B CRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBAhAWpZtNxHBkhVoG2HKaeabqMA0GCSqGSIb3DQEBAQUABIIBAFo+no1GceUi190X wWhwUxZ25LddiKYGeLnZewlBgIhbQC+TRzQkJviXpIu1dQhDAq0Rm4077N3AFRu3E14PBhNn 1hgDWsoaqiuPhk3EyI57GkEWNfJIqeACLz6++lmn18gSLBzks9rD/1HJ6+awLsutR6icLHHz mnwmyuHJUqI8jA2r/Tj1eNEB9PHByCqvW4Hyhm7cTlz+gEyOOA7eLjz3ZuKOAAOLoszMsh58 mXhSj+UVjQ0WA3O8+dzxuiJDBEmj+/MeGS/7b3OlaRsAdmSARC4L0eKdaueaX6AYvarNwEE+ Jh0nVnO+VHVWCo2quMRocLbdxwS9EhcRKCRpVP0AAAAAAAA= --------------ms070308020507070705010402-- From nobody Sun Nov 29 01:47: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 C98391B30D7 for ; Sun, 29 Nov 2015 01:47:57 -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 PLRqn67-_n-4 for ; Sun, 29 Nov 2015 01:47:55 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::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 721291B30D6 for ; Sun, 29 Nov 2015 01:47:55 -0800 (PST) Received: by wmww144 with SMTP id w144so102691501wmw.0 for ; Sun, 29 Nov 2015 01:47:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=oW0dTxnEGazQEw1Fo59HB1H7kBGw+8qJvbiJgmMgzmU=; b=EX3z5sV7vkWYNlSJtlGAf6X6YV/eHvTist2iIEricrrpUiI1L5SvYJRcgfAw5Mqv0V fz0zHgXUJwufnzgjmJKwyW4LmyYk3+gsanWWP9AyZLpsqqN0nP6kZKSW1C2syOI/YIUa jlllOcTU2lNMEEe1oLWSN2xDnHqgRbcFcQN0wteDODAcR5zFhM+Kl96F78mXXNIxc1cF VSXasP4UOMrf30vVrRlaMuWcubMPhlKhRtFitbf3WuQ7BYoPYnK58UcCuU1vvJVKqEg9 AmKbXY/Z9XasqQKqbezmZcRG9nOC5Jb9nCuodlk77kh1Fud/GsbRMfBnCdLHLO0VhoDF tuAw== X-Received: by 10.28.103.84 with SMTP id b81mr20013996wmc.39.1448790474086; Sun, 29 Nov 2015 01:47:54 -0800 (PST) Received: from proz.dclient.lsne.ch (85-218-12-53.dclient.lsne.ch. [85.218.12.53]) by smtp.gmail.com with ESMTPSA id bk2sm41514310wjc.3.2015.11.29.01.47.52 for (version=TLSv1/SSLv3 cipher=OTHER); Sun, 29 Nov 2015 01:47:52 -0800 (PST) To: tls@ietf.org References: <56586A2F.1070703@gmail.com> <565882FE.80205@streamsec.se> From: Bryan A Ford X-Enigmail-Draft-Status: N1110 Message-ID: <565AC9D1.700@gmail.com> Date: Sun, 29 Nov 2015 10:48:01 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <565882FE.80205@streamsec.se> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040705020904070503050101" Archived-At: Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Nov 2015 09:47:58 -0000 This is a cryptographically signed message in MIME format. --------------ms040705020904070503050101 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 11/27/15 5:21 PM, Henrick Hellstr=F6m wrote: > On 2015-11-27 15:35, Bryan A Ford wrote: >> The idea of encrypting TLS record headers has come up before, the most= >> important purpose being to hide record lengths and boundaries and make= >> fingerprinting and traffic analysis harder. >=20 > How, exactly, would this be significantly harder? The adversary will > still be able to tell when, and how much, TCP/IP data is sent between > the peers. If there happens to be a revealing TLS record boundary in th= e > middle of a TCP/IP packet, it would seem to me there is an > implementation problem rather than a problem with the abstract protocol= =2E There are a variety of reasons TLS segment boundaries can and often do become desynchronized from TLS record boundaries, such as: (a) if the TLS implementation happens to encrypt several consecutive records in a buffer and sends them with one write() call for efficiency. (b) if the kernel TCP stack's send buffer is already non-empty on write (e.g., held back to to congestion or flow control) and the TCP stack decides simply to append the newly-written data to the already buffered data, the boundary between those wrotes need not appear as a TCP segment boundary. (c) quite a few middleboxes can and do silently re-segment TCP streams obliviously to the content of that stream. In particular this tends to happen as an incidental side-effect whenever the middlebox interposes on the TCP stream by "terminating" the TCP connection and transparently forwarding the content to/from a second TCP connection. Now, this doesn't mean that "incidental" desynchronization of TCP segment boundaries from TLS record boundaries will by itself add any kind of robust protection against traffic analysis. To achieve that, we would want to ensure that a burst of (say) multiple HTTP requests and their responses over the TLS connection get merged together and then transmitted as a uniform-length series of blobs. A sufficiently careful TLS implementation could potentially achieve this, but with TLS headers sent in cleartext, the TLS implementation is the *only* entity in the system that can provide any kind of traffic analysis protection. With TLS headers encrypted, it becomes feasible for some (weak or strong) traffic analysis protection to be introduced at multiple points: 1. The TLS implementation can do it, either way. 2. Even if the TLS implementation doesn't try to provide any traffic analysis protection, the kernel's TCP stack could provide some protection (either intentionally or unintentionally) simply by merging together consecutive writes as discussed above, so that transmissions are usually just bursts of MTU-sized TCP segments even if they hold many varying-size TLS records. 3. Finally, middleboxes can (again either intentionally or unintentionally) add traffic analysis protection by re-segmenting TCP traffic. Corporate network operators often already see NATs as a security advantage because they obfuscate the source IP addresses of connections coming from the private network. If TLS 1.3 encrypts its record headers, then network operators and the middleboxes they deploy will similarly be able to add traffic analysis protection "in the middle" by re-segmenting TCP streams (which many of these middleboxes may already be doing anyway), and whatever protection this provides will apply to automatically to *all* TLS 1.3 traffic crossing that middlebox, even if few or none of the actual TLS 1.3 endpoint implementations know or care about traffic analysis protection. In short, leaving TLS headers in cleartext basically hands any eavesdropper a huge information side-channel unnecessarily and precludes anyone *but* the TLS implementation itself from adding any traffic analysis protection into the system. Encrypting TLS headers appears to cost practically nothing (at least if done as I've proposed), and it allows traffic analysis protection (whether weak or strong, intentional or unintentional) to be introduced at multiple points: e.g., by TLS itself, or by the TCP stack, or by middleboxes. Cheers Bryan --------------ms040705020904070503050101 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfgwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVBMIIEKaADAgECAhAWpZtNxHBkhVoG2HKaeabqMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwNjI0MDAwMDAwWhcNMTYwNjIzMjM1OTU5WjAmMSQwIgYJKoZIhvcNAQkB FhVicnlub3NhdXJ1c0BnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDAPPVOZLVu2tZOao2osnGxGwYy7nC3UX8yoebrOfaNWkItIkUH6NQRKuqxuDE7127q48VH c7kwmg4DifoOjxSjXyT+R9pR/ethFwjXiWCjsIaWbcFc6X7D1fIisO14z8D4luBO1LezNVB6 Dee8lMutP9OO4MmKWYq3+Jab9Rv/3BXCyiDDQfxhiuWFzZQTWpbzGGfwitcqPHH97PN4COCh hhOuUS9Yt1qQBY8Gn36eVepKdz3YiF7ii/JDth1iA/zHK8pyim+OgERcwo6Ildqh59uy0IjM AcKA1Mc34AgMQJdLlmhYAai5nMLOJQiFzfIyB6egjSyishx11rpL/xKlAgMBAAGjggHzMIIB 7zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQUpXGtiQ4RgWPr 1UjnydSPtyPTai8wDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYI KwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsG DCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEF BQcBAQSBgzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RP U0hBMjU2Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEF BQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCAGA1UdEQQZMBeBFWJyeW5vc2F1cnVz QGdtYWlsLmNvbTANBgkqhkiG9w0BAQsFAAOCAQEADDSBNRYWArRAPSTMC6DSrUOIWQ3J1CmE XEYoQ4QByCkkybRUCgXIadTAUwj+D9ZX4HQxxvtOkb+uVQCnwbI6jGZj0Mpb7MWYOZDyeQT1 YEoUMRpeUUpTDd6iw3Em0Lf+rj7/VPlYKvErTCOnyEUm2z8MismcjPIFJ8Ud+HccyfpkhotJ HbVBN+hSGm03l7YxVVzf9owzq7L5vCB5afJyTNt5x7qlLCcsiGBW2kSoQKaDAMwuYMp5YOgD 1doc/yWJSkiQAcKcWY2ALacs+a0FSItqT1rNk3tnHX2spIrBgDrv+5ybZXBBjAknetbTON5m rWT2tzLgYpKPJLs49ETIoDGCBEEwggQ9AgEBMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UE CBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJYIZIAWUD BAIBBQCgggJhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MTEyOTA5NDgwMVowLwYJKoZIhvcNAQkEMSIEIFS07rnklUj8nFV8vPmEKOuA1oTyNpNEj3MP a2gGcwY0MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgcEGCSsGAQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAWpZtNxHBkhVoG2HKaeabqMIHDBgsqhkiG9w0B CRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBAhAWpZtNxHBkhVoG2HKaeabqMA0GCSqGSIb3DQEBAQUABIIBAHixSZkfiAs7J6rH Qt+aFoyUAnrZie3sguczcbKEPte8I/Y56VIJjF+c90XFRaH8zB9irapmOUfMqWz3+y3PN2w/ oqNd8drh0FIlwJhETOYZeZLw+krMng2zPk37GUFMSk+Vr8+FzSe+dYpOOHsSQMEbgEBHdxOW DW8yZu5zq68f6T9u2b/HrsseI4FMTzYuGtUy+lQMXLrBqXEfAmsjawOyvaZTxaWKeCZt2/Cz hQFGqI2PrNQfnZdWdXe8UTupQWfdEB42l2HZnR3tn7NZpPfMtLAsiq6Zonkyeba8I95lol19 tgCTp3BccRFldnIbrB+TqahIDaJWjZU9Og23HowAAAAAAAA= --------------ms040705020904070503050101-- From nobody Sun Nov 29 03:30: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 77AD41A0141 for ; Sun, 29 Nov 2015 03:30:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 p2O-yNwNb107 for ; Sun, 29 Nov 2015 03:30:42 -0800 (PST) Received: from vsp6.ballou.se (vsp6.ballou.se [91.189.40.85]) by ietfa.amsl.com (Postfix) with SMTP id 1C2751A013F for ; Sun, 29 Nov 2015 03:30:41 -0800 (PST) X-Halon-ID: 9d58d85a-968c-11e5-a960-00505692585a X-Halon-Scanned: 7f4a955dd6f4c149d51110a345668da22aa82d04 Received: from nmail1.ballou.se (unknown [10.0.0.116]) by vsp6.ballou.se (Halon Mail Gateway) with ESMTP for ; Sun, 29 Nov 2015 12:30:38 +0100 (CET) Received: from [192.168.0.190] (c-1ec0e555.06-134-73746f39.cust.bredbandsbolaget.se [85.229.192.30]) (Authenticated sender: henrick@streamsec.se) by nmail1.ballou.se (Postfix) with ESMTPSA id 13D0EC9378 for ; Sun, 29 Nov 2015 12:30:38 +0100 (CET) References: <56586A2F.1070703@gmail.com> <565882FE.80205@streamsec.se> <565AC9D1.700@gmail.com> To: tls@ietf.org From: =?UTF-8?Q?Henrick_Hellstr=c3=b6m?= Message-ID: <565AE180.70101@streamsec.se> Date: Sun, 29 Nov 2015 12:29:04 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <565AC9D1.700@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: henrick@streamsec.se List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2015 11:30:44 -0000 On 2015-11-29 10:48, Bryan A Ford wrote: > In short, leaving TLS headers in cleartext basically hands any > eavesdropper a huge information side-channel unnecessarily and precludes > anyone*but* the TLS implementation itself from adding any traffic > analysis protection into the system. Encrypting TLS headers appears to > cost practically nothing (at least if done as I've proposed), and it > allows traffic analysis protection (whether weak or strong, intentional > or unintentional) to be introduced at multiple points: e.g., by TLS > itself, or by the TCP stack, or by middleboxes. Thank you for the explanation. A few points: The only way to completely thwart traffic analysis, is to always send data with the exact same amount-frequency pattern. The middleboxes you describe will *not* be able to achieve this, unless the TLS sender is adapted for such processing anyway. The middleboxes can't inject data. All they can do is wait for data to arrive and delay data that has already arrived. Traffic analysis is about deriving information from patterns that emerge from the combination of timing and sizes. If data is delayed in order to reach a specific size before being forwarded, the middlebox might just be shifting the size signal to an equally detectable timing signal. This is particularly true, if low latency is also a requirement. If very high latency is acceptable, the middleboxes might theoretically hide everything except the total amount of data transmitted during specific time intervals. From nobody Sun Nov 29 04:11: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 5E7D61ACC91 for ; Sun, 29 Nov 2015 04:11:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l70hh9MrXvMZ for ; Sun, 29 Nov 2015 04:11:01 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::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 802F01ACC92 for ; Sun, 29 Nov 2015 04:11:00 -0800 (PST) Received: by wmvv187 with SMTP id v187so120821564wmv.1 for ; Sun, 29 Nov 2015 04:10:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=1ZzVCvbYNMY+5gfpRX5xAERzy2T4jqjBuiWO+LaBY80=; b=BRhIsF8QmLgHy+kJv5B6y/9uZeRV7nBRK3Leh8cjaP1LKeaJzq6tONpUA8x2adM0gt VeII0Yg93KaDaxKnGMly7w/3p/+LVQy3A2dxpwvUN6TIQrd7gSvRblu4CBgUDxHcFDv7 WVRTedzjIk/JGpg22r99QPifbsQNwG/CfXo5TMY+7/u4LSP5FGUrpXkvjJ1dgGEFeqmL tDj2ZUzAQtRnahypsb/7N2DODWztiwUkSYMiMf/Lru1F1Oc6F+MVdQuwvHNvMRYrgoPz E5HXUZfZPL045CeMHhmS5OLwexnQtdELMkDEKF9185QJ0h5Nw9LLtU0UPT6ncVwKd28a 12ZQ== X-Received: by 10.194.232.230 with SMTP id tr6mr77080695wjc.21.1448799059024; Sun, 29 Nov 2015 04:10:59 -0800 (PST) Received: from proz.dclient.lsne.ch (85-218-12-53.dclient.lsne.ch. [85.218.12.53]) by smtp.gmail.com with ESMTPSA id q6sm41733118wjx.28.2015.11.29.04.10.57 for (version=TLSv1/SSLv3 cipher=OTHER); Sun, 29 Nov 2015 04:10:57 -0800 (PST) To: tls@ietf.org References: <56586A2F.1070703@gmail.com> <565882FE.80205@streamsec.se> <565AC9D1.700@gmail.com> <565AE180.70101@streamsec.se> From: Bryan A Ford X-Enigmail-Draft-Status: N1110 Message-ID: <565AEB5A.9000503@gmail.com> Date: Sun, 29 Nov 2015 13:11:06 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <565AE180.70101@streamsec.se> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090606060509060600030509" Archived-At: Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Nov 2015 12:11:02 -0000 This is a cryptographically signed message in MIME format. --------------ms090606060509060600030509 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 11/29/15 12:29 PM, Henrick Hellstr=F6m wrote: > On 2015-11-29 10:48, Bryan A Ford wrote: >> In short, leaving TLS headers in cleartext basically hands any >> eavesdropper a huge information side-channel unnecessarily and preclud= es >> anyone*but* the TLS implementation itself from adding any traffic >> analysis protection into the system. Encrypting TLS headers appears t= o >> cost practically nothing (at least if done as I've proposed), and it >> allows traffic analysis protection (whether weak or strong, intentiona= l >> or unintentional) to be introduced at multiple points: e.g., by TLS >> itself, or by the TCP stack, or by middleboxes. >=20 > Thank you for the explanation. A few points: >=20 > The only way to completely thwart traffic analysis, is to always send > data with the exact same amount-frequency pattern. The middleboxes you > describe will *not* be able to achieve this, unless the TLS sender is > adapted for such processing anyway. Very true. But perfect traffic analysis protection isn't the only goal of interest, and is usually impractical anyway. A less ambitious but still worthwhile goal is simply to make sure that in imperfectly-protected connections, transmission bursts leak as little of their internal structure as possible even though the timing and burst of the (whole) burst will still inevitably risk leaking something. Even when it's impractical to leak nothing, it's still worthwhile to leak less= =2E A fairly important common-case example of this, I think, is Web page loads in which the client submits a bunch of requests in parallel over the same connection. This was never widely enabled in HTTP/1.1 due to compatibility concerns but will probably become the norm quickly with HTTP/2.0. A TLS implementation designed without much concern for traffic analysis will probably send those multiple small requests/replies in separate TLS records, giving eavesdroppers a nice fine-grained fingerprint of what all is in that transmission burst. If TLS 1.3 hides its headers, then either the TLS implementation, the TCP stack, or a middlebox could readily scrub that internal structure and at least make life harder for the attacker (e.g., reduce the bandwidth of the side-channel). That seems worthwhile to me if it doesn't cost much. Cheers Bryan --------------ms090606060509060600030509 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfgwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVBMIIEKaADAgECAhAWpZtNxHBkhVoG2HKaeabqMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwNjI0MDAwMDAwWhcNMTYwNjIzMjM1OTU5WjAmMSQwIgYJKoZIhvcNAQkB FhVicnlub3NhdXJ1c0BnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDAPPVOZLVu2tZOao2osnGxGwYy7nC3UX8yoebrOfaNWkItIkUH6NQRKuqxuDE7127q48VH c7kwmg4DifoOjxSjXyT+R9pR/ethFwjXiWCjsIaWbcFc6X7D1fIisO14z8D4luBO1LezNVB6 Dee8lMutP9OO4MmKWYq3+Jab9Rv/3BXCyiDDQfxhiuWFzZQTWpbzGGfwitcqPHH97PN4COCh hhOuUS9Yt1qQBY8Gn36eVepKdz3YiF7ii/JDth1iA/zHK8pyim+OgERcwo6Ildqh59uy0IjM AcKA1Mc34AgMQJdLlmhYAai5nMLOJQiFzfIyB6egjSyishx11rpL/xKlAgMBAAGjggHzMIIB 7zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQUpXGtiQ4RgWPr 1UjnydSPtyPTai8wDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYI KwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsG DCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEF BQcBAQSBgzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RP U0hBMjU2Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEF BQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCAGA1UdEQQZMBeBFWJyeW5vc2F1cnVz QGdtYWlsLmNvbTANBgkqhkiG9w0BAQsFAAOCAQEADDSBNRYWArRAPSTMC6DSrUOIWQ3J1CmE XEYoQ4QByCkkybRUCgXIadTAUwj+D9ZX4HQxxvtOkb+uVQCnwbI6jGZj0Mpb7MWYOZDyeQT1 YEoUMRpeUUpTDd6iw3Em0Lf+rj7/VPlYKvErTCOnyEUm2z8MismcjPIFJ8Ud+HccyfpkhotJ HbVBN+hSGm03l7YxVVzf9owzq7L5vCB5afJyTNt5x7qlLCcsiGBW2kSoQKaDAMwuYMp5YOgD 1doc/yWJSkiQAcKcWY2ALacs+a0FSItqT1rNk3tnHX2spIrBgDrv+5ybZXBBjAknetbTON5m rWT2tzLgYpKPJLs49ETIoDGCBEEwggQ9AgEBMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UE CBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJYIZIAWUD BAIBBQCgggJhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MTEyOTEyMTEwNlowLwYJKoZIhvcNAQkEMSIEIP4c2sik04OSMwXbQP/ppg0QBZflxHSIedAS hW61ZelYMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgcEGCSsGAQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAWpZtNxHBkhVoG2HKaeabqMIHDBgsqhkiG9w0B CRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBAhAWpZtNxHBkhVoG2HKaeabqMA0GCSqGSIb3DQEBAQUABIIBAK5Hx6d9hZaAwJWD osYtXut7zLhmUqKp/RXV1I4qD6XeYPqX39WFx51XQX5+yhvZb9Qlc8fJ2FnDBpWweuooP+XW w87COQAlopu55u6B+oouBiBaB9hbo4bbXE7m2EKqIk52j+o7k92SIowYOO82sd8D6heKdoGA uyCcmtUfTgN5FRkMdhPSFnSF9yqAbOJxp8jLAlj2LBGQbuVR4enaQz5Lo1sj5uaoVY0tVvuO NrAK7yulhv3ACsL7zlI+lyR6JKcPfa+VB6+AF6Ah4CSo9EPsQOHw6mqj2SCr7/4DkKBjRxaM FJPqZkC3A/7YLn1uGzph0PgfzK5QQ9Ar5vcaqSIAAAAAAAA= --------------ms090606060509060600030509-- From nobody Sun Nov 29 09:11: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 427961A1A7E for ; Sun, 29 Nov 2015 09:11:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.963 X-Spam-Level: X-Spam-Status: No, score=-1.963 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, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yo63xtZ_Y1i3 for ; Sun, 29 Nov 2015 09:11:40 -0800 (PST) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E25C1A1A7F for ; Sun, 29 Nov 2015 09:11:40 -0800 (PST) Received: by igcmv3 with SMTP id mv3so56389466igc.0 for ; Sun, 29 Nov 2015 09:11:39 -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=SWarSyPzRqKlDYOrJT8+oUN7H2lfHrKJLgvbdXO89O0=; b=h+NY/FEq52vLSGNWZTpKSwubTlQnIkchEa1/6AJbmKVjuCl0OOjmq29M2dVIOV31af flEmu6Zn/TE5qtsKFi7U6r2gj57qef932L2YKwq4GA9DMCIL9I1FG2ZTjZ9uTPldf7Li GJfE98MyLG+DNn8PPu/JWBtfjTapzF4z4N1tooVFYwAy414ugHP14PasIgoKBoM16kJC wuPON3KnVQaTyVY7B1PcC6TV4n6mz2HmJz75JGUZ/1WinwNtJ3T8VtqUc8xZ45PDog5+ FhdFcylJd0Sl7eGbezE666uiC4tn4m/N4tHMP1uovgwDdWlEZGAmjpd95rdIkl7QY43v O/FQ== 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=SWarSyPzRqKlDYOrJT8+oUN7H2lfHrKJLgvbdXO89O0=; b=lUFr4/j8j9rEPx8O4QtwZVOLVVFyZ+vuxbi3iRYJP6+CoEhvEgfsp7R4e/wafn/KfY HBz5WBTBOxOsKvqNM4ERc0U9S6cy8VWlcK0oOLRCg6IO53p/Noz4Y2VPmnLck3T9eFs1 P8/il/tjBjO06wTeUggDxGVpx7Vq8V86djVrHLQKDKhhrLmcAM0ysziyMyth+GxbsATN ymCJrm8MVUw2TNkL/KqfZ/cCpdRjMPyOgpHpIQFL3NiBW45NUJgeoeevre5+al8bS9n8 6CAwCw9hnmjHVntUiE6POjI8lfrRn0SUdv7D8tf1MsY+9MbUKwdBEEkW2ahunXAqckIL LHYA== X-Gm-Message-State: ALoCoQkyLPraH6J6vkz4PwJL4XSS8Z8LSE9O8KKDjSMQG4bLSeFOojDTwK0P22e91P2nAHwLOCeJ MIME-Version: 1.0 X-Received: by 10.50.73.37 with SMTP id i5mr16986257igv.40.1448817099657; Sun, 29 Nov 2015 09:11:39 -0800 (PST) Received: by 10.107.173.15 with HTTP; Sun, 29 Nov 2015 09:11:39 -0800 (PST) In-Reply-To: <565AEB5A.9000503@gmail.com> References: <56586A2F.1070703@gmail.com> <565882FE.80205@streamsec.se> <565AC9D1.700@gmail.com> <565AE180.70101@streamsec.se> <565AEB5A.9000503@gmail.com> Date: Sun, 29 Nov 2015 09:11:39 -0800 Message-ID: From: Bill Cox To: Bryan A Ford Content-Type: multipart/alternative; boundary=089e013a0e08922c250525b104e5 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Nov 2015 17:11:42 -0000 --089e013a0e08922c250525b104e5 Content-Type: text/plain; charset=UTF-8 Thanks for the detailed description of why we might want to obfuscate TLS record lengths. From a security point of view, the only potential attack vector this might create is that the attacker will know in many cases the plain text of the first 5 bytes. A weakness in the stream cipher might be more easily exploited in this case. IIUC, we feel pretty good about the latest AEAD ciphers, and guessing the clear text of many bytes in the record already is not too hard. Is that right? So, from my fairly uninformed point of view, this seems like a reasonable upgrade. I have one concern. These same boxes that hide record lengths by merging and breaking up packets arbitrarily likely would deliver the packets not well aligned to record boundaries. Is this already the case? If these boxes currently inspect packets when breaking them up to split packets along record boundaries, encrypting the lengths will defeat this efficiency hack. We might cause an increase in network latency in this case. Do any of the routers out there currently use the record length field when splitting up packets? Bill --089e013a0e08922c250525b104e5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Than= ks for the detailed description of why we might want to obfuscate TLS recor= d lengths.=C2=A0 From a security point of view, the only potential attack v= ector this might create is that the attacker will know in many cases the pl= ain text of the first 5 bytes.=C2=A0 A weakness in the stream cipher might = be more easily exploited in this case.=C2=A0 IIUC, we feel pretty good abou= t the latest AEAD ciphers, and guessing the clear text of many bytes in the= record already is not too hard.=C2=A0 Is that right?=C2=A0 So, from my fai= rly uninformed point of view, this seems like a reasonable upgrade.

I have one co= ncern.=C2=A0 These same boxes that hide record lengths by merging and break= ing up packets arbitrarily likely would deliver the packets not well aligne= d to record boundaries.=C2=A0 Is this already the case?=C2=A0 If these boxe= s currently inspect packets when breaking them up to split packets along re= cord boundaries, encrypting the lengths will defeat this efficiency hack.= =C2=A0 We might cause an increase in network latency in this case.=C2=A0 Do= any of the routers out there currently use the record length field when sp= litting up packets?

Bill


On Sat, Nov 28, 2015 at 1:08 PM, Tony Arcieri <bascule@gmail.com&g= t; wrote:
On Sat, Nov= 28, 2015 at 10:05 AM, Roland Zink <roland@zinks.de> wrote:
Am 28.11.2015 um 17:56 schrieb Henric= k Hellstr=C3=B6m:
AFAIK, HTTP 1.1 browsers typically don't send a new request over an ope= n connection, before it has received the response to the previous request. = If that is the case, it is trivial to get the message lengths from the traf= fic, with or without encrypted TLS record headers. IOW you gain nothing by = encrypting the length fields.

 I think this is what browsers do by default. For HTTP2 this should be diffe= rent.

This is HTTP/1.1 pipelining, w= hich is supported by most browsers but typically disabled by default as mos= t servers don't support pipelining correctly.=C2=A0

I think the above analysis is wrong. C= onsider a service written in Go using the built-in TLS library. Then the nu= mber and sizes of writes is visible to an attacker, which can reveal inform= ation about which branches were taken and the data sent. That's not bec= ause the total size of the response necessarily changes, but the sequence o= f writes taken to get there.


--
Tony Arcieri

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




--
"Man is born free, but everywhere he is in chai= ns".
--Rousseau.
--089e013a0e08922c250525b104e5-- From nobody Sun Nov 29 12:00: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 6E9A81B331F for ; Sun, 29 Nov 2015 12:00:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.786 X-Spam-Level: X-Spam-Status: No, score=-4.786 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1l_4YvhC5Bf for ; Sun, 29 Nov 2015 12:00:42 -0800 (PST) Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32B561B3323 for ; Sun, 29 Nov 2015 12:00:39 -0800 (PST) Received: from zmail22.collab.prod.int.phx2.redhat.com (zmail22.collab.prod.int.phx2.redhat.com [10.5.83.26]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id tATK0cCb015089; Sun, 29 Nov 2015 15:00:38 -0500 Date: Sun, 29 Nov 2015 15:00:38 -0500 (EST) From: Nikos Mavrogiannopoulos To: Bryan A Ford Message-ID: <2006084219.21103856.1448827238217.JavaMail.zimbra@redhat.com> In-Reply-To: <56586A2F.1070703@gmail.com> References: <56586A2F.1070703@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.181] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF38 (Linux)/8.0.6_GA_5922) Thread-Topic: Encrypting record headers: practical for TLS 1.3 after all? Thread-Index: r+tS4hiLCGV+LeIEk+XqLpQ52xLw0g== Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Nov 2015 20:00:43 -0000 ----- Original Message ----- > The idea of encrypting TLS record headers has come up before, the most > important purpose being to hide record lengths and boundaries and make > fingerprinting and traffic analysis harder. I had convinced myself that > goal this would be "too hard" to accomplish in TLS 1.3, but after > further thought I'm not so sure. So I would like to request comment on > one approach that strikes me as a practical and requires only a rather > minor change to the current spec. I believe your proposal is a nice example of putting the cart before the horse. Before proposing something it should be clear what do you want to protect from, what is the threat? Here you imply that the revealing the length is somehow a weakness. However, TLS isn't supposed to hide lengths and never did [0]. So will hiding the length _field_ of such a protocol, will really protect against attacks taking advantage of packet lengths? If you see the previous work of analyzing TLS packet lengths they don't even need to read that length field, they just use the packet length on the wire. There is already a solution for protecting packet lengths, and that's called padding [1]. regards, Nikos [0]. the cbc ciphersuite approach was a half baked approach which never worked. [1]. http://alfredo.pironti.eu/research/publications/full/identifying-website-users-tls-traffic-analysis-new-attacks-and-effective-counterme From nobody Sun Nov 29 12:20: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 CA03E1B3390 for ; Sun, 29 Nov 2015 12:20:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.299 X-Spam-Level: X-Spam-Status: No, score=0.299 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 Xk2xjleedkod for ; Sun, 29 Nov 2015 12:20:19 -0800 (PST) Received: from denver.dinauz.org (denver.dinauz.org [IPv6:2001:41d0:8:730b::1]) by ietfa.amsl.com (Postfix) with ESMTP id 997111B338E for ; Sun, 29 Nov 2015 12:20:18 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by denver.dinauz.org (Postfix) with ESMTP id 6551960011 for ; Sun, 29 Nov 2015 21:20:16 +0100 (CET) Received: from denver.dinauz.org ([127.0.0.1]) by localhost (denver.dinauz.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jMhQ9nvR7o1P for ; Sun, 29 Nov 2015 21:20:16 +0100 (CET) Received: from macbook-pro-de-julien-elie.home (AAubervilliers-651-1-294-16.w83-114.abo.wanadoo.fr [83.114.213.16]) by denver.dinauz.org (Postfix) with ESMTPSA id 2839F6000F for ; Sun, 29 Nov 2015 21:20:16 +0100 (CET) To: tls@ietf.org References: <20150922132321.17789008.2591.24358@ll.mit.edu> <56019B0F.3020208@trigofacile.com> <201509221423.38061.davemgarrett@gmail.com> <56019FEE.5010008@trigofacile.com> <92D67610-81FD-4515-AFE6-910E8B4E0F44@gmail.com> From: =?UTF-8?Q?Julien_=c3=89LIE?= Organization: TrigoFACILE -- http://www.trigofacile.com/ Message-ID: <565B5DFF.8010308@trigofacile.com> Date: Sun, 29 Nov 2015 21:20:15 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Nov 2015 20:20:22 -0000 Hi all, > > If compression is so important to NNTP, they should add first-class >> support. Period. They should not be relying on a poorly conceived >> feature which has been repeatedly demonstrated to introduce >> vulnerabilities in what is supposed to be a *security protocol* just >> because they don't want to implement compression themselves. >> >> An unsafe feature shouldn't be kept in TLS just because some >> protocols want to do unsafe things and are too lazy to implement >> their own compression. > > [Stephen] > Compression does have issues clearly, but it's not correct to > describe people wanting TLS to compress as lazy. They're rather > looking for the same features that TLS has offered for a couple of > decades. The good news is that the "first-class" NNTP compression support will soon be a reality. We've updated the draft of the COMPRESS command, and we hope to publish it as an RFC: https://tools.ietf.org/html/draft-murchison-nntp-compress-02 Interoperability is proven: both a news client (flnews) and a news server (INN) have implemented it. As far as security is concerned, authentication MUST be done *before* activating the compression layer (in other words, AUTHINFO is no longer valid after a successful use of COMPRESS). Thanks again guys for having put us to work on that NNTP extension! -- Julien ÉLIE « Aequum est ut cuius participauit lucrum, participet et damnun. » From nobody Sun Nov 29 13:47: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 ABF071B3542 for ; Sun, 29 Nov 2015 13:47:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hX1IVqADGok for ; Sun, 29 Nov 2015 13:47:19 -0800 (PST) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::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 2AB511B3541 for ; Sun, 29 Nov 2015 13:47:19 -0800 (PST) Received: by qkao63 with SMTP id o63so52497282qka.2 for ; Sun, 29 Nov 2015 13:47: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=AwR+qSzo7b2neqdG8R04Bmja+hcHQRVK28vZO/mG11M=; b=tpsFY0Q/v5ZEpTBYVExKBn9lg1zZKucJfSMVGXlknCXJ/ZRj/JzRYXzWVsn8bHxXgJ /ify5Ss1fsnRZQ2tPlQh4AlmdbVHS7RXGsSxcUss7l8HZ9pobmEzYHz2Vo0zWe1Cxd3A cmChjVpqYR6nC281prs68vNkD9ocyd8D6Bm3JdkaBFJrE2TF8UPga1X/P8H4VeIZZA4+ wbKtb8QCAnSJOz08SNqpgOFm08VLrzLO7uzEWW6ZGv79fbqjqozQoefprDrhaP6+k/dj dTKwY6vdY0lXvth+TL46jVEZpyEf8DF0dAAeiDDT9UC7byT/NrKOrGDZzCrtN/NwRYhj q74Q== X-Received: by 10.55.75.212 with SMTP id y203mr67842771qka.20.1448833638417; Sun, 29 Nov 2015 13:47:18 -0800 (PST) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id t101sm13686613qge.2.2015.11.29.13.47.17 (version=TLS1 cipher=AES128-SHA bits=128/128); Sun, 29 Nov 2015 13:47:17 -0800 (PST) From: Dave Garrett To: tls@ietf.org Date: Sun, 29 Nov 2015 16:47:16 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <56586A2F.1070703@gmail.com> <2006084219.21103856.1448827238217.JavaMail.zimbra@redhat.com> In-Reply-To: <2006084219.21103856.1448827238217.JavaMail.zimbra@redhat.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201511291647.16541.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Nov 2015 21:47:20 -0000 Maybe I'm missing something, but hasn't this issue already been sufficiently dealt with via padding? https://tools.ietf.org/html/draft-ietf-tls-tls13-10#section-5.2.2 The record type and version fields are now frozen, and the record length field is not indicative of the real length if padding is used. The only way I could see encrypting the length field as helpful would be to further obfuscate it from something that can see the record layer but not the transport layer and doesn't know the full record size, though the padding already obfuscates it somewhat. Is this really worth jumping through hoops for? Dave From nobody Sun Nov 29 17:26: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 188AF1B3DAA for ; Sun, 29 Nov 2015 17:26:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.785 X-Spam-Level: X-Spam-Status: No, score=-4.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7R1rV6iAFdsB for ; Sun, 29 Nov 2015 17:26:18 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35BDD1B3DA8 for ; Sun, 29 Nov 2015 17:26:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1448846778; x=1480382778; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=2PJMoG09jl1lsm2RjuK1PnA7gH+V5u1m3Oe8O8U1Hi8=; b=eVJKZdo272cR37wbryqnqh5Rmk6WLPD49Xyh6rsNukx2+J8gxd3R/h02 VdMtBaB4CQkmqXgwrwj6EBsb33tNmS5aRXzyEKIrrlo96hbTNX7qavEX2 i0mW0+9W+TthIbsapCg1BIpj3JMjVzvOs4nDoKXkZeMjDlCCiQczogvIr UBfuqSoqT5fIeLrdBFqHrKY8IidAmJEVfnrNeIp7SGJ3sqWmQi8W38lgX 4OxE4027az159jqeGV8gBcsXwn7IpPz1A9B/Yd5XSFL7ymwTTZkRiZkUp o4sxoTb4kolKjaELK7wUV+OnsRo8Wu9BXyOKjKijpVnFadrqJKYBlBlng w==; X-IronPort-AV: E=Sophos;i="5.20,361,1444647600"; d="scan'208";a="56726074" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxchange10-fe1.UoA.auckland.ac.nz) ([130.216.4.112]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 30 Nov 2015 14:26:15 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.153]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0266.001; Mon, 30 Nov 2015 14:26:15 +1300 From: Peter Gutmann To: Bryan A Ford , "tls@ietf.org" Thread-Topic: [TLS] Encrypting record headers: practical for TLS 1.3 after all? Thread-Index: AQHRKSDnEzBCXT12GkOsH7hTugsdcp6xSadegACXeACAAeiXew== Date: Mon, 30 Nov 2015 01:26:15 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B92E74@uxcn10-5.UoA.auckland.ac.nz> References: <56586A2F.1070703@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B8DA2A@uxcn10-5.UoA.auckland.ac.nz>, <565AC278.2010904@gmail.com> In-Reply-To: <565AC278.2010904@gmail.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 01:26:22 -0000 Bryan A Ford writes:=0A= =0A= >Feel free to attack my proposal but then please attack *my* proposal, not = =0A= >the old broken SSH approach.=0A= =0A= I was actually commenting on the concept of encrypting headers in general,= =0A= not the specific case you'd given. That is, I assumed you'd specifically = =0A= chosen the one case where it's practical, an AEAD stream cipher, and used= =0A= that as a strawman. Re-reading your post, it looks like "adding a stream= =0A= cipher to every TLS 1.3-compatible ciphersuite" should really be "require= =0A= that the only cipher type allowed for TLS be an AEAD stream cipher", =0A= because it's not going to work with anything else.=0A= =0A= This breaks a fundamental principle of TLS, that you can drop in any =0A= algorithm or mechanism you like (well, within reason) and it'll still work.= =0A= More importantly, if a flaw is found in one mechanism, you can switch to = =0A= another. In the past we've been able to switch between a KSG cipher (RC4),= =0A= 64-bit block ciphers, 128-bit block ciphers, and AEAD ciphers as required.= =0A= With this change, it looks like the only choice you have is an AEAD stream= =0A= cipher.=0A= =0A= In addition, it doesn't actually achieve what you think it does, I'll =0A= expand on that in a separate message in reply to another post.=0A= =0A= Peter.=0A= From nobody Sun Nov 29 17:40: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 4D1FE1B3DCB for ; Sun, 29 Nov 2015 17:40:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.785 X-Spam-Level: X-Spam-Status: No, score=-4.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ewDVpxXvHo4U for ; Sun, 29 Nov 2015 17:40:13 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D93101B3DB8 for ; Sun, 29 Nov 2015 17:40:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1448847612; x=1480383612; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=tBzyhylcQ74akOm5vWioSZxphwEpL7qvgxlArj7D8oM=; b=PXFVmmRDO/ivdizGvwgW/5IPyuufbtx13fiPJCAnSpXCn5aKb94qu+kg 3/7v570/SlYy28mMEwP/xLGp0Ebbuj88MpW63CWMcD32vAPl4YIBhFmf+ +zUQH2QFaGScDIiSg3wg+3jXJrW4SHoS6B1IgclxiOjB5wOTYY8/ZO2vB Y/9WGcUrE3Hl144BD8j8XcD5Zub5itPzmGOFMgLMWxmlzoKCtjY2DDI74 CBuC7XQiN6ZBcu2YToSr5VBrHU6Ns2hrPP/pbE9DYn/nayBWPe0pnuDo+ 27Z2UYvPwZ10GZNe6AE+LIdl++4ZewqpVqyojrCarHobNXQqEegBfmkW4 A==; X-IronPort-AV: E=Sophos;i="5.20,361,1444647600"; d="scan'208";a="56729401" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 30 Nov 2015 14:40:08 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.153]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0266.001; Mon, 30 Nov 2015 14:40:08 +1300 From: Peter Gutmann To: Nikos Mavrogiannopoulos , Bryan A Ford Thread-Topic: [TLS] Encrypting record headers: practical for TLS 1.3 after all? Thread-Index: AQHRKuC7sinTlhcB90OKLJcXcQ2rVp6zyfDc Date: Mon, 30 Nov 2015 01:40:07 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B92EA4@uxcn10-5.UoA.auckland.ac.nz> References: <56586A2F.1070703@gmail.com>, <2006084219.21103856.1448827238217.JavaMail.zimbra@redhat.com> In-Reply-To: <2006084219.21103856.1448827238217.JavaMail.zimbra@redhat.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 01:40:14 -0000 Nikos Mavrogiannopoulos writes:=0A= =0A= >I believe your proposal is a nice example of putting the cart before the= =0A= >horse. Before proposing something it should be clear what do you want to= =0A= >protect from, what is the threat?=0A= =0A= Exactly. If you want to thwart traffic analysis, you need to do something= =0A= like what's done by designs like Aqua ("Towards Efficient Traffic-analysis = =0A= Resistant Anonymity Networks"), or ideas from any of the other anti-traffic= -=0A= analysis work that's emerged in the past decade or two. You get traffic = =0A= analysis resistance by, for example, breaking data into fixed-length =0A= packets, using cover traffic, and messing with packet timings, not by =0A= encrypting TLS headers.=0A= =0A= Peter.= From nobody Sun Nov 29 17: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 2A4071A035F for ; Sun, 29 Nov 2015 17:54:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.286 X-Spam-Level: X-Spam-Status: No, score=-3.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1NYPrbXLPrDg for ; Sun, 29 Nov 2015 17:54:28 -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 7D4C21A0248 for ; Sun, 29 Nov 2015 17:54:28 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A322816C3F2; Mon, 30 Nov 2015 01:54:27 +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 8D1F816C290; Mon, 30 Nov 2015 01:54:27 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1448848467; bh=Lx6VobPn0QIBXhMo7Ht66ls3MkrJ2Asbnlqooctz4/Y=; l=1454; h=From:To:CC:Date:References:In-Reply-To:From; b=g5DsY1YjreHSltAhnfAHNRJHyD+KGIFOon9H487PDD4UGXfT29KZMP+/hHigkccl7 lBzm0RlobPm9gg7LOsWmIwlF1+ej2ZGfMELRnvAsIMKVMFu76OY1GzPkf5XPzgktG6 V0I8AXUQkYInmyvEwiohJDmhYmn/7UFKjp699QGQ= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 73D7A1E07C; Mon, 30 Nov 2015 01:54:27 +0000 (GMT) Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Sun, 29 Nov 2015 17:54:26 -0800 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1076.000; Sun, 29 Nov 2015 20:54:26 -0500 From: "Short, Todd" To: Peter Gutmann Thread-Topic: [TLS] Encrypting record headers: practical for TLS 1.3 after all? Thread-Index: AQHRKuClinUQn5aDaU2ft8eXcUtgg560HiWA//+wL9s= Date: Mon, 30 Nov 2015 01:54:26 +0000 Message-ID: References: <56586A2F.1070703@gmail.com>, <2006084219.21103856.1448827238217.JavaMail.zimbra@redhat.com>, <9A043F3CF02CD34C8E74AC1594475C73F4B92EA4@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B92EA4@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted 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] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 01:54:30 -0000 This brings up an interesting point; having a record length that correspond= s to the TCP segment size can help hardware implementations such that they = don't need to deal with scatter/gather; i.e. one TCP segment corresponds to= a single TLS record. This goes along with 8 (or 4) byte record lengths for= hardware implementations.=20 -- -Todd Short // Sent from my iPhone // "One if by land, two if by sea, three if by the Internet." > On Nov 29, 2015, at 8:40 PM, Peter Gutmann wr= ote: >=20 > Nikos Mavrogiannopoulos writes: >=20 >> I believe your proposal is a nice example of putting the cart before the >> horse. Before proposing something it should be clear what do you want to >> protect from, what is the threat? >=20 > Exactly. If you want to thwart traffic analysis, you need to do somethin= g > like what's done by designs like Aqua ("Towards Efficient Traffic-analysi= s=20 > Resistant Anonymity Networks"), or ideas from any of the other anti-traff= ic- > analysis work that's emerged in the past decade or two. You get traffic= =20 > analysis resistance by, for example, breaking data into fixed-length=20 > packets, using cover traffic, and messing with packet timings, not by=20 > encrypting TLS headers. >=20 > Peter. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Sun Nov 29 20:08: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 A5FD51A701E for ; Sun, 29 Nov 2015 20:08:15 -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, 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 8VWD-ReeHT7r for ; Sun, 29 Nov 2015 20:08:13 -0800 (PST) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DFFB1A7026 for ; Sun, 29 Nov 2015 20:08:13 -0800 (PST) Received: by lffu14 with SMTP id u14so181510927lff.1 for ; Sun, 29 Nov 2015 20:08:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OCy4TrnGCujJ/uLkT2F/eWU+4mtWLL+LoNbRDipPV+I=; b=oKhC5fcNv5vhTEx9SCR8MsF127s2xx3uUgKGtp6NWlY7Y7Ma4mOURWUmaiXTIY4Yv0 nWXzu8MyYsu0k5ejgcHH+eX8gP0Ou8RwYiFhRVNmMvKQ9KLrxW1FYPrXsgHTAAT1CAdn oGoGIlIm4EQJx2Ksu+0ROHmNz9LdOaAocd51bUnnkvNhuQsWlyN7ILmrToRO9bQE/LsG r2PyYmfEpR7LnZr/Ol9fxMIJz8K1Zi1i2OoJzSQZ9UBbkL8apnBoNPPFU27dmhU3FOUF 9ru4oLL0T3+uDRw0B+i8fvDC2UwUFlYZEoHqB/K4LIWZBQa5T1Ra2Iw0V4ZGY2X7Hawh E/rQ== 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=OCy4TrnGCujJ/uLkT2F/eWU+4mtWLL+LoNbRDipPV+I=; b=ibDs8F3oecioigukiac2rnfVxFHRrwbSc6J9ZUCDl1hsedE/frBRu29HF0SfVhKfYW TWL3MX1mVuPHEPMR3hfK3MilqMosl3g2V+DvD5Z5qZHPHMceHUtPPn+hHoYh7wXwA0hq MNTgBB95Hhi9KNRjSUSCdOhNk/Go+8zhhzt+N1lmeebjYRjsU5/kMK5jfbeYUE06D7jj Yi8m5BaA4J994pYRj2JjBWn02k3SOpKD1bD+hOGOhMbq65Bh05Ar5JTy1hSCuBcXFwvc SkgRdELuZznzqgQQA0V55QlLwq5gRIEZFs6X7vYXl7tV9+smvZfL9ouSKMoFpkhrzgyx MWIg== X-Gm-Message-State: ALoCoQl/9tCJlbD06IuV//nlS9MB+dr5DG19+gwfjY7y8Bc+YoG7m59Lob4njjifKN49O3tJmS0j MIME-Version: 1.0 X-Received: by 10.112.171.74 with SMTP id as10mr23266254lbc.137.1448856491235; Sun, 29 Nov 2015 20:08:11 -0800 (PST) Received: by 10.112.24.131 with HTTP; Sun, 29 Nov 2015 20:08:11 -0800 (PST) In-Reply-To: References: <20151119150312.E8CDA1A383@ld9781.wdf.sap.corp> Date: Sun, 29 Nov 2015 20:08:11 -0800 Message-ID: From: Joseph Salowey To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a11c37fba7db7430525ba30a1 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR#345: IANA Considerations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 04:08:15 -0000 --001a11c37fba7db7430525ba30a1 Content-Type: text/plain; charset=UTF-8 I believe the consensus supports what is in the current PR. Cheers, Joe On Thu, Nov 26, 2015 at 3:18 PM, Eric Rescorla wrote: > Joe, > > Can you clarify whether you believe consensus is to make the "Recommended" > list the list in the current PR or the MTI list. I can edit the document > either > way. > > -Ekr > > > On Wed, Nov 25, 2015 at 11:05 AM, Joseph Salowey wrote: > >> It looks like we have rough consensus to accept this PR. We can still >> have discussion on the naming of the categories. We will also have to >> define the IANA registration policy for changing the "recommended" bit. >> I'll open an issue for this, I think changing the bit to recommended >> should require IETF consensus. >> >> Cheers, >> >> Joe >> >> On Thu, Nov 19, 2015 at 7:10 AM, Eric Rescorla wrote: >> >>> >>> >>> On Thu, Nov 19, 2015 at 7:03 AM, Martin Rex wrote: >>> >>>> Eric Rescorla wrote: >>>> > >>>> > There are presently four categories of cipher suites vis-a-vis TLS >>>> 1.3. >>>> > >>>> > 1. MUST or SHOULD cipher suites. >>>> > 2. Standards track cipher suites (or ones we are making ST, like >>>> > the ECC ones). >>>> > 3. Non standards track cipher suites >>>> > 4. Cipher suites you can't use at all with TLS 1.3, like AES-CBC. >>>> > >>>> > I think we're all agreed that category #1 should be marked recommended >>>> > and that #3 and #4 should not be. This leaves us with category #2, >>>> which >>>> > includes stuff like: >>>> > >>>> > - FFDHE >>>> > - CCM >>>> > >>>> > My proposal is that we: >>>> > >>>> > - List all the Standards Track cipher suites that are compatible with >>>> TLS >>>> > 1.3 in Appendix A. >>>> > - Mark all the cipher suites that are listed in Appendix A as >>>> "Recommended" >>>> >>>> >>>> I'm slightly confused. >>>> >>>> rfc5288 is standards track and describes AES-GCM with static RSA keyex. >>>> >>> >>> This isn't compatible with TLS 1.3 because TLS 1.3 removes static RSA. >>> >>> >>> rfc5289 is only informational (i.e. _not_ standards track) and describes >>>> AES-GCM with ECDHE keyex. >>> >>> >>> We are re-labelling the AES-GCM ECDHE suites as standards track either >>> in this document or in RFC4492bis. >>> >>> -Ekr >>> >>> >>>> >>>> >>>> >>>> -Martin >>>> >>> >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >>> >> > --001a11c37fba7db7430525ba30a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I believe the consensus supports what is in the current PR= . =C2=A0

Cheers,

Joe

On Thu, Nov 26, = 2015 at 3:18 PM, Eric Rescorla <ekr@rtfm.com> wrote:
Joe,

Can you clar= ify whether you believe consensus is to make the "Recommended"
list the list in the current PR or the MTI list. I can edit the doc= ument either
way.

-Ekr


On Wed, Nov 25, 2015 at 11:05 AM, Joseph Sa= lowey <joe@salowey.net> wrote:
It looks like we have rou= gh consensus to accept this PR. We can still have discussion on the naming = of the categories.=C2=A0 We will also have to define the IANA registration = policy for changing the "recommended" bit. =C2=A0 I'll open a= n issue for this, =C2=A0I think changing the bit to recommended should requ= ire IETF consensus. =C2=A0

Cheers,

<= /div>
Joe

=
On Thu, Nov 19, 2015 at 7:10 AM, Eric = Rescorla <ekr@rtfm.com> wrote:
=


On Thu, Nov 19, 2015 at 7:03 AM, Martin Rex <mrex@sap.com= > wrote:
Eric Rescorla wrote:
>
> There are presently four categories of cipher suites vis-a-vis TLS 1.3= .
>
> 1. MUST or SHOULD cipher suites.
> 2. Standards track cipher suites (or ones we are making ST, like
>=C2=A0 =C2=A0 =C2=A0the ECC ones).
> 3. Non standards track cipher suites
> 4. Cipher suites you can't use at all with TLS 1.3, like AES-CBC.<= br> >
> I think we're all agreed that category #1 should be marked recomme= nded
> and that #3 and #4 should not be. This leaves us with category #2, whi= ch
> includes stuff like:
>
> - FFDHE
> - CCM
>
> My proposal is that we:
>
> - List all the Standards Track cipher suites that are compatible with = TLS
> 1.3 in Appendix A.
> - Mark all the cipher suites that are listed in Appendix A as "Re= commended"


I'm slightly confused.

rfc5288 is standards track and describes AES-GCM with static RSA keyex.
=

This isn't compatible with TLS = 1.3 because TLS 1.3 removes static RSA.


=
rfc5289 is only informational (i.e. _not_ standards track) and describes AES-GCM with ECDHE keyex.

We are re-= labelling the AES-GCM ECDHE suites as standards track either in this docume= nt or in RFC4492bis.

-Ekr
=C2=A0



-Martin


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




--001a11c37fba7db7430525ba30a1-- From nobody Sun Nov 29 22:33: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 828FA1A885C for ; Sun, 29 Nov 2015 22:33:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.785 X-Spam-Level: X-Spam-Status: No, score=-4.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DI52KXIgcwey for ; Sun, 29 Nov 2015 22:33:11 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0438E1A885B for ; Sun, 29 Nov 2015 22:33:09 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CEU32587; Mon, 30 Nov 2015 06:33:06 +0000 (GMT) Received: from SZXEMI401-HUB.china.huawei.com (10.82.75.33) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 30 Nov 2015 06:33:05 +0000 Received: from SZXEMI501-MBX.china.huawei.com ([169.254.1.253]) by SZXEMI401-HUB.china.huawei.com ([10.82.75.33]) with mapi id 14.03.0235.001; Mon, 30 Nov 2015 14:32:54 +0800 From: Jayaraghavendran k To: Xuelei Fan Thread-Topic: [TLS] TLS 1.3 and RFC 4279, Pre-Shared Key Ciphersuites Thread-Index: AQHRKSTQR81q0xKmjECWMANvrDN0uZ60HO7g Date: Mon, 30 Nov 2015 06:32:54 +0000 Message-ID: <8D925D4C0B78EE41857D407022ECD163BFF02DD7@SZXEMI501-MBX.china.huawei.com> References: <8D925D4C0B78EE41857D407022ECD163BFF02A60@SZXEMI501-MBX.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.213.218] Content-Type: multipart/alternative; boundary="_000_8D925D4C0B78EE41857D407022ECD163BFF02DD7SZXEMI501MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.565BEDA3.007E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.253, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: faa7962a42ad686fb6768c315cc2e638 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 and RFC 4279, Pre-Shared Key Ciphersuites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 06:33:14 -0000 --_000_8D925D4C0B78EE41857D407022ECD163BFF02DD7SZXEMI501MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLiBUaGVvcmV0aWNhbGx5LCB5b3UgZG8gc2VlbSB0byBoYXZlIGEgcG9pbnQuDQoNCkJ1dCwg SSBoYXZlIHNvIGZhciBub3QgY29tZSBhY3Jvc3MgaW1wbGVtZW50YXRpb25zIG1ha2luZyBhbiBl ZmZlY3RpdmUgdXNhZ2Ugb2YgSWRlbnRpdHkgSGludC4gIFNvLCBJIGd1ZXNzIHRoaXMgc2hvdWxk IG5vdCBiZSBzdWNoIGEgYmlnIHByb2JsZW0uDQoNClJlZ2FyZHMsDQpKYXkNCg0KKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqDQpUaGlzIGUtbWFpbCBhbmQgYXR0YWNobWVudHMgY29udGFp biBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gZnJvbSBIVUFXRUksIHdoaWNoIGlzIGludGVuZGVk IG9ubHkgZm9yIHRoZSBwZXJzb24gb3IgZW50aXR5IHdob3NlIGFkZHJlc3MgaXMgbGlzdGVkIGFi b3ZlLiBBbnkgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGluIGFueSB3 YXkgKGluY2x1ZGluZywgYnV0IG5vdCBsaW1pdGVkIHRvLCB0b3RhbCBvciBwYXJ0aWFsIGRpc2Ns b3N1cmUsIHJlcHJvZHVjdGlvbiwgb3IgZGlzc2VtaW5hdGlvbikgYnkgcGVyc29ucyBvdGhlciB0 aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQncykgaXMgcHJvaGliaXRlZC4gSWYgeW91IHJlY2Vp dmUgdGhpcyBlLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBieSBwaG9u ZSBvciBlbWFpbCBpbW1lZGlhdGVseSBhbmQgZGVsZXRlIGl0IQ0KKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqDQoNCkZyb206IFh1ZWxlaSBGYW4gW21haWx0bzp4dWVsZWkuZmFuQHZpbWlu by5jb21dDQpTZW50OiAyNyBOb3ZlbWJlciAyMDE1IDIwOjM0DQpUbzogSmF5YXJhZ2hhdmVuZHJh biBrDQpDYzogdGxzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1RMU10gVExTIDEuMyBhbmQgUkZD IDQyNzksIFByZS1TaGFyZWQgS2V5IENpcGhlcnN1aXRlcw0KDQpJdCBpcyBhIGdyZWF0IGlkZWEg dG8gdXNlIFBTSyBmb3Igc2Vzc2lvbiByZXN1bXB0aW9uLiAgSG93ZXZlciwgYXMgdGhlIFNlcnZl cktleUV4Y2hhbmdlLnBza19pZGVudGl0eV9oaW50IGRpc2FwcGVhcnMgaW4gVExTIDEuMywgSSB3 YXMgd29uZGVyaW5nLCBpdCBtYXkgYmUgbm90IGVhc3kgdG8gbWFrZSBhbiB1cGdyYWRlIGZvciB0 aG9zZSBQU0sgaW1wbGVtZW50YXRpb24gdGhhdCByZWxpZXMgb24gU2VydmVyS2V5RXhjaGFuZ2Uu cHNrX2lkZW50aXR5X2hpbnQuDQoNCkNvbnNpZGVyaW5nIHRoZSBmb2xsb3dpbmcgaW5pdGlhbCBo YW5kc2hha2luZyBleGFtcGxlIGluIFRMUyAxLjIuDQoxLiBjbGllbnQgcmVxdWVzdHMgYSBQU0sg Y2lwaGVyIHN1aXRlIG5lZ290aWF0aW9uOw0KMi4gc2VydmVyIHJlc3BvbnNlcyB3aXRoIGEgaGlu dCBpbiBTZXJ2ZXJLZXlFeGNoYW5nZS5wc2tfaWRlbnRpdHlfaGludA0KMy4gY2xpZW50IGxvb2tz IGZvciB0aGUgc2hhcmVkIGtleSB3aXRoIHRoZSBoaW50IGluIHRoZSBsb2NhbCBkYXRhYmFzZS9j YWNoZS9yZW1vdGUgc2VydmljZSwgZXRjLg0KNC4gY2xpZW50IHByb3ZpZGVzIHRoZSBzaGFyZWQg a2V5IGluIENsaWVudEtleUV4Y2hhbmdlLnBza19pZGVudGl0eS4NCg0KSGVyZSBTZXJ2ZXJLZXlF eGNoYW5nZS5wc2tfaWRlbnRpdHlfaGludCBpcyB1c2VkIGFzIGFuIGluZGV4IHRvIGZpbmQgdGhl IHNoYXJlZCBrZXkgaW4gY2xpZW50IHNpZGUuDQoNCklmIG1vdmluZyB0byBUTFMgMS4zLCBhcyB0 aGVyZSBpcyBubyBoaW50IGFueSBtb3JlLCBhcHBsaWNhdGlvbiBtYXkgbmVlZCB0byByZWNvbnN0 cnVjdCB0aGUgc2NlbmFyaW9zIGFib3ZlIGluIG9yZGVyIHRvIGZvbGxvdyB0aGUgc3BlYyBvZiBU TFMgMS4zIGFuZCBmaW5kIGEgbmV3IGFwcHJvYWNoIHRvIGdldCB0aGUgc2hhcmVkIGtleS4NCg0K SWYgdGhlIGNsaWVudCBhbmQgc2VydmVyIGFyZSBzdXBwb3NlZCB0byBoYXZlIGEgc2hvcnQgc2V0 IG9mIGtub3duIOKAnElkZW50aXR5IOKAkyBrZXnigJ0gcGFpciBvbiBlaXRoZXIgc2lkZXMgYmV0 d2VlbiB0aGVtLCB0aGUgcmVjb25zdHJ1Y3Rpb24gY2FuIGJlIG1pbmltYWwuICBJZiB0aGUgc2hh cmVkIGtleXMgYXJlIHVua25vd24gcHJldmlvdXNseSBiZWZvcmUgdGhlIGhpbnQgZ2V0IGtub3du LCB0aGUgcmVjb25zdHJ1Y3Rpb24gd291bGQgZ2V0IGNvbXBsaWNhdGVkLiAgSnVzdCBndWVzc2lu ZyB0aGVvcmV0aWNhbGx5LCBJIGhhdmUgbm8gcHJhY3RpY2FsIGV2aWRlbmNlIGZvciB0aGUgY2Fz ZS4gIEhvcGVmdWxseSwgbm8gb25lIHVzZSB0aGUgY2FzZSBpbiBwcmFjdGljZS4NCg0KUmVnYXJk cywNClh1ZWxlaQ0KDQoNCk9uIEZyaSwgTm92IDI3LCAyMDE1IGF0IDEwOjAwIFBNLCBKYXlhcmFn aGF2ZW5kcmFuIGsgPGpheWFyYWdoYXZlbmRyYW4ua0BodWF3ZWkuY29tPG1haWx0bzpqYXlhcmFn aGF2ZW5kcmFuLmtAaHVhd2VpLmNvbT4+IHdyb3RlOg0KSGkgWHVlbGVpLA0KDQpBcyBwZXIgUkZD IDQyNzkgYWxzbywgYm90aCB0aGUgY2xpZW50IGFuZCBzZXJ2ZXIgYXJlIHN1cHBvc2VkIHRvIGhh dmUgYSBzZXQgb2Yg4oCcSWRlbnRpdHkg4oCTIGtleeKAnSBwYWlyICBvbiBlaXRoZXIgc2lkZXMu IFRoZSDigJxTZXJ2ZXJLZXlFeGNoYW5nZS5wc2tfaWRlbnRpdHlfaGludOKAnSBvbmx5IGhlbHBz IHRoZSBjbGllbnQgaW4gY2hvb3NpbmcgYW4g4oCcaWRlbnRpdHkta2V54oCdIHBhaXIgZnJvbSBh IGxpc3Qgb2Ygc2V2ZXJhbCDigJxpZGVudGl0eS1rZXkgcGFpcnPigJ0gdGhlIGNsaWVudCBtYXkg aGF2ZS4NCg0KSW4gVExTIDEuMywgaW5zdGVhZCBvZiB0aGUgU2VydmVyS2V5RXhjaGFuZ2UucHNr X2lkZW50aXR5X2hpbnQsIGNsaWVudCBzZW5kcyBpdHMgbGlzdCBvZiBpZGVudGl0aWVzIGluIHRo ZSBjbGllbnQgaGVsbG8gaXRzZWxmIHRocm91Z2ggUHJlU2hhcmVkS2V5IEV4dGVuc2lvbiBhbmQg c2VydmVyIGNob29zZXMgb25lIGZyb20gaXQgYW5kIHJlcGxpZXMgaW4gdGhlIFByZVNoYXJlZEtl eSBFeHRlbnNpb24uICBOb3csIGluc3RlYWQgb2YgdHJhZGl0aW9uYWwgc2Vzc2lvbiByZXN1bXB0 aW9uLCB0aGlzIGxvZ2ljIHdpbGwgYmUgdXNlZCAgd2hpY2ggYmFzaWNhbGx5IGhhcyB0aGUgc2Ft ZSBhYmJyZXZpYXRlZCBoYW5kc2hha2UuDQoNClNvLCBlc3NlbnRpYWxseSwgVExTIDEuMiB0byBU TFMgMS4zIHRyYW5zaXRpb24gZm9yIHRoZSBhYm92ZSBzY2VuYXJpbyBzaG91bGQgYmUgdmlld2Vk IGFzIGJlbG93Og0KDQooYSkgICAgSW4gY2FzZSBvZiBQU0ssIGluc3RlYWQgb2YgQ2xpZW50IGd1 ZXNzaW5nIGFuZCB1c2luZyBhbiBJZGVudGl0eSBiYXNlZCBvbiBQU0sgSWRlbnRpdHkgSGludCwg Ym90aCBjbGllbnQgYW5kIHNlcnZlciBuZWdvdGlhdGUgd2hpY2ggaWRlbnRpdHkgdG8gdXNlIGlu IHRoZSBoZWxsbyBtZXNzYWdlcyBpdHNlbGYuDQoNCihiKSAgIFNlcnZlcktleUV4Y2hhbmdlLnBz a19pZGVudGl0eV9oaW50IGNhbiBiZSBvYnNvbGV0ZWQgcmVtb3ZlZCB3aGVuIHlvdSB0cmFuc2l0 aW9uIGZyb20gMS4yIHRvIDEuMy4NCg0KSW4gbXkgb3BpbmlvbiwgdGhpcyBtYWtlcyB0aGUgUFNL IGJhc2VkIGhhbmRzaGFrZSBhIGxvdCBtb3JlIHNpbXBsZXIgYW5kIGVhc2llciB0byB1c2UuDQoN CkNvdWxkIHlvdSBlbGFib3JhdGUgb24geW91ciBzY2VuYXJpbyBiYXNlZCBvbiB3aGljaCB5b3Ug c2F5IHRoZSB0cmFuc2l0aW9uIGZyb20gVExTIDEuMiB0byBUTFMgMS4zIGZvciBQU0sgd2lsbCBi ZSBkaWZmaWN1bHQ/DQoNClJlZ2FyZHMsDQpKYXkNCg0KKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqDQpUaGlzIGUtbWFpbCBhbmQgYXR0YWNobWVudHMgY29udGFpbiBjb25maWRlbnRpYWwg aW5mb3JtYXRpb24gZnJvbSBIVUFXRUksIHdoaWNoIGlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSBw ZXJzb24gb3IgZW50aXR5IHdob3NlIGFkZHJlc3MgaXMgbGlzdGVkIGFib3ZlLiBBbnkgdXNlIG9m IHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGluIGFueSB3YXkgKGluY2x1ZGluZywg YnV0IG5vdCBsaW1pdGVkIHRvLCB0b3RhbCBvciBwYXJ0aWFsIGRpc2Nsb3N1cmUsIHJlcHJvZHVj dGlvbiwgb3IgZGlzc2VtaW5hdGlvbikgYnkgcGVyc29ucyBvdGhlciB0aGFuIHRoZSBpbnRlbmRl ZCByZWNpcGllbnQncykgaXMgcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmUgdGhpcyBlLW1haWwg aW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBieSBwaG9uZSBvciBlbWFpbCBpbW1l ZGlhdGVseSBhbmQgZGVsZXRlIGl0IQ0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQoN CkZyb206IFRMUyBbbWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzp0bHMtYm91bmNl c0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBYdWVsZWkgRmFuDQpTZW50OiAyNyBOb3ZlbWJlciAy MDE1IDE3OjI5DQpUbzogdGxzQGlldGYub3JnPG1haWx0bzp0bHNAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBbVExTXSBUTFMgMS4zIGFuZCBSRkMgNDI3OSwgUHJlLVNoYXJlZCBLZXkgQ2lwaGVyc3VpdGVz DQoNCkhpLA0KDQpJbiB0aGUgZHJhZnQgc3BlYyBvZiBUTFMgMS4zLCBTZXJ2ZXJLZXlFeGNoYW5n ZSBhbmQgQ2xpZW50S2V5RXhjaGFuZ2UgZ2V0IHJlbW92ZWQsIGFuZCBrZXlfc2hhcmUgZXh0ZW5z aW9uIGFwcGxpZXMgdG8gbm9uLVBTSyBjaXBoZXIgc3VpdGVzIG9ubHkuIEFzIFJGQyA0Mjc5IG5l ZWQgU2VydmVyS2V5RXhjaGFuZ2UgYW5kIENsaWVudEtleUV4Y2hhbmdlIG1lc3NhZ2VzLCBJIHRo aW5rIFRMUyAxLjMgdXBkYXRlcyBvciBvYnNvbGV0ZXMgUkZDIDQyNzkuDQoNClBlciB0aGUgZHJh ZnQgc3BlYyBvZiBUTFMgMS4zLCBpZiBubyBzdWl0YWJsZSBpZGVudGl0eSBpcyBwcm92aWRlZCBp biBwcmUtc2hhcmVkIGtleSBleHRlbnNpb24sIHRoZSBzZXJ2ZXIgTVVTVCBOT1QgbmVnb3RpYXRl IGEgUFNLIGNpcGhlciBzdWl0ZS4gIFRoZSBxdWVzdGlvbiBjb21lcyB0byBtZTogd2hlcmUgdGhl IHN1aXRhYmxlIGlkZW50aXR5IGNvbWVzIGZyb20/ICBUaGUgaWRlbnRpdHkgY2FuIGJlIGFjcXVp cmVkIGJ5IG91dC1vZi1iYW5kIGFwcHJvYWNoLCBvciB0aGUgc2VydmVyIE5ld1Nlc3Npb25UaWNr ZXQgbWVzc2FnZS4gIElmIG5vIG91dC1vZi1iYW5kIGFwcHJvYWNoIGluIHNvbWUgY2lyY3Vtc3Rh bmNlcywgdGhlIHNlcnZlciBOZXdTZXNzaW9uVGlja2V0IG1lc3NhZ2Ugd291bGQgYmUgdGhlIG9u bHkgd2F5IHRvIGNyZWF0ZSB0aGUgaWRlbnRpdHkuICBUaGUgc2NlbmFyaW9zIG9mIHVzaW5nICBw cmUtc2hhcmVkIGtleSBtYXkgbG9vayBsaWtlOg0KMS4gZXN0YWJsaXNoIGEgZnJlc2ggY29ubmVj dGlvbiwgc2VydmVyIHNlbmRzIHRoZSBOZXdTZXNzaW9uVGlja2V0IHRvIGluZGljYXRlIGl0IHN1 cHBvcnRzIHNlc3Npb24gcmVzdW1wdGlvbiBhbmQgcHJvdmlkZSB0aGUgcHNrX2lkZW50aXR5Lg0K Mi4gaWYgY2xpZW50IHdhbnRzIGEgc2Vzc2lvbiByZXN1bXB0aW9uLCBzdWJzZXF1ZW50IGhhbmRz aGFraW5nIHdpbGwgdXNlIHByZV9zaGFyZWQga2V5IGV4dGVuc2lvbiB3aXRoIHRoZSBzZXJ2ZXIg cHJvdmlkZWQgcHNrX2lkZW50aXR5Lg0KDQpMb29rcyBsaWtlIFBTSyBhcHBsaWVzIHRvIHNlc3Np b24gcmVzdW1lIG9ubHkgaW4gVExTIDEuMywgYW5kIGNhbm5vdCBiZSB1c2VkIGZvciBmcmVzaCAo aW5pdGlhbCkgaGFuZHNoYWtpbmcgYW55IG1vcmUsICB1bmxlc3Mgb3V0LW9mLWJhbmQgYXBwcm9h Y2ggaXMgdXNlZCB0byBkZWZpbmUgdGhlIGlkZW50aXRpZXMuICBJIGhhdmUgbm8gZXhwZXJpZW5j ZSBvbiBQU0ssIGJ1dCBsb29rcyBsaWtlIHRoYXQgaXQgaXMgbm90IEEgbWluaW1hbCBlZmZvcnQg Zm9yIFBTSyBkZXBsb3ltZW50cyB0byB1cGdyYWRlIGZyb20gVExTIDEuMiB0byBUTFMgMS4zLCBp ZiBTZXJ2ZXJLZXlFeGNoYW5nZS5wc2tfaWRlbnRpdHlfaGludCBpcyB1c2VkIHByZXZpb3VzbHku DQoNCkl0IHdvdWxkIGJlIG5pY2UgdG8gY29uc2lkZXIgYW5kIHNwZWNpZnkgdGhlIGltcGFjdCBv biBSRkMgNDI3OSBpbiBUTFMgMS4zIHByb3RvY29scy4NCg0KUmVnYXJkcywNClh1ZWxlaQ0KDQo= --_000_8D925D4C0B78EE41857D407022ECD163BFF02DD7SZXEMI501MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNv QWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFs bG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0K c3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4w cHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5ZZXMuIFRoZW9yZXRpY2FsbHksIHlv dSBkbyBzZWVtIHRvIGhhdmUgYSBwb2ludC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJ1dCwgSSBoYXZlIHNvIGZhciBu b3QgY29tZSBhY3Jvc3MgaW1wbGVtZW50YXRpb25zIG1ha2luZyBhbiBlZmZlY3RpdmUgdXNhZ2Ug b2YgSWRlbnRpdHkgSGludC4gJm5ic3A7U28sIEkgZ3Vlc3MgdGhpcyBzaG91bGQgbm90IGJlIHN1 Y2ggYSBiaWcgcHJvYmxlbS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkpheTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxicj4N ClRoaXMgZS1tYWlsIGFuZCBhdHRhY2htZW50cyBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1h dGlvbiBmcm9tIEhVQVdFSSwgd2hpY2ggaXMgaW50ZW5kZWQgb25seSBmb3IgdGhlIHBlcnNvbiBv ciBlbnRpdHkgd2hvc2UgYWRkcmVzcyBpcyBsaXN0ZWQgYWJvdmUuIEFueSB1c2Ugb2YgdGhlIGlu Zm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaW4gYW55IHdheSAoaW5jbHVkaW5nLCBidXQgbm90 IGxpbWl0ZWQgdG8sIHRvdGFsIG9yIHBhcnRpYWwNCiBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24s IG9yIGRpc3NlbWluYXRpb24pIGJ5IHBlcnNvbnMgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgcmVj aXBpZW50J3MpIGlzIHByb2hpYml0ZWQuIElmIHlvdSByZWNlaXZlIHRoaXMgZS1tYWlsIGluIGVy cm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYnkgcGhvbmUgb3IgZW1haWwgaW1tZWRpYXRl bHkgYW5kIGRlbGV0ZSBpdCE8YnI+DQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4gWHVlbGVpIEZhbiBbbWFpbHRvOnh1ZWxlaS5mYW5AdmltaW5vLmNvbV0NCjxicj4NCjxiPlNl bnQ6PC9iPiAyNyBOb3ZlbWJlciAyMDE1IDIwOjM0PGJyPg0KPGI+VG86PC9iPiBKYXlhcmFnaGF2 ZW5kcmFuIGs8YnI+DQo8Yj5DYzo8L2I+IHRsc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW1RMU10gVExTIDEuMyBhbmQgUkZDIDQyNzksIFByZS1TaGFyZWQgS2V5IENpcGhlcnN1 aXRlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JdCBp cyBhIGdyZWF0IGlkZWEgdG8gdXNlIFBTSyBmb3Igc2Vzc2lvbiByZXN1bXB0aW9uLiZuYnNwOyBI b3dldmVyLCBhcyB0aGUgU2VydmVyS2V5RXhjaGFuZ2UucHNrX2lkZW50aXR5X2hpbnQgZGlzYXBw ZWFycyBpbiBUTFMgMS4zLCBJIHdhcyB3b25kZXJpbmcsIGl0IG1heSBiZSBub3QgZWFzeSB0byBt YWtlIGFuDQogdXBncmFkZSBmb3IgdGhvc2UgUFNLIGltcGxlbWVudGF0aW9uIHRoYXQgcmVsaWVz IG9uIFNlcnZlcktleUV4Y2hhbmdlLnBza19pZGVudGl0eV9oaW50LjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Q29uc2lkZXJpbmcgdGhlIGZvbGxvd2luZyBpbml0aWFsIGhhbmRzaGFraW5n IGV4YW1wbGUgaW4gVExTIDEuMi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+MS4gY2xpZW50IHJlcXVlc3RzIGEgUFNLIGNpcGhlciBzdWl0ZSBuZWdvdGlhdGlvbjs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Mi4gc2VydmVyIHJlc3BvbnNlcyB3 aXRoIGEgaGludCBpbiBTZXJ2ZXJLZXlFeGNoYW5nZS5wc2tfaWRlbnRpdHlfaGludDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4zLiBjbGllbnQgbG9va3MgZm9yIHRoZSBz aGFyZWQga2V5IHdpdGggdGhlIGhpbnQgaW4gdGhlIGxvY2FsIGRhdGFiYXNlL2NhY2hlL3JlbW90 ZSBzZXJ2aWNlLCBldGMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjQu IGNsaWVudCBwcm92aWRlcyB0aGUgc2hhcmVkIGtleSBpbiBDbGllbnRLZXlFeGNoYW5nZS5wc2tf aWRlbnRpdHkuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5I ZXJlIFNlcnZlcktleUV4Y2hhbmdlLnBza19pZGVudGl0eV9oaW50IGlzIHVzZWQgYXMgYW4gaW5k ZXggdG8gZmluZCB0aGUgc2hhcmVkIGtleSBpbiBjbGllbnQgc2lkZS48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgbW92aW5nIHRvIFRMUyAx LjMsIGFzIHRoZXJlIGlzIG5vIGhpbnQgYW55IG1vcmUsIGFwcGxpY2F0aW9uIG1heSBuZWVkIHRv IHJlY29uc3RydWN0IHRoZSBzY2VuYXJpb3MgYWJvdmUgaW4gb3JkZXIgdG8gZm9sbG93IHRoZSBz cGVjIG9mIFRMUyAxLjMgYW5kIGZpbmQgYSBuZXcgYXBwcm9hY2ggdG8gZ2V0IHRoZSBzaGFyZWQg a2V5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JZiB0aGUgY2xpZW50IGFuZCBzZXJ2ZXIgYXJlIHN1cHBvc2VkIHRvIGhhdmUgYSBzaG9ydCBz ZXQgb2Yga25vd24g4oCcSWRlbnRpdHkg4oCTIGtleeKAnSBwYWlyIG9uIGVpdGhlciBzaWRlcyBi ZXR3ZWVuIHRoZW0sIHRoZSZuYnNwO3JlY29uc3RydWN0aW9uJm5ic3A7Y2FuIGJlIG1pbmltYWwu Jm5ic3A7IElmIHRoZSBzaGFyZWQga2V5cyBhcmUgdW5rbm93biBwcmV2aW91c2x5IGJlZm9yZSB0 aGUgaGludCBnZXQga25vd24sIHRoZSByZWNvbnN0cnVjdGlvbg0KIHdvdWxkIGdldCBjb21wbGlj YXRlZC4mbmJzcDsgSnVzdCBndWVzc2luZyB0aGVvcmV0aWNhbGx5LCBJIGhhdmUgbm8gcHJhY3Rp Y2FsIGV2aWRlbmNlIGZvciB0aGUgY2FzZS4mbmJzcDsgSG9wZWZ1bGx5LCBubyBvbmUgdXNlIHRo ZSBjYXNlIGluIHByYWN0aWNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+WHVlbGVpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gRnJpLCBOb3YgMjcsIDIwMTUgYXQgMTA6MDAgUE0sIEpheWFyYWdoYXZlbmRyYW4g ayAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpheWFyYWdoYXZlbmRyYW4ua0BodWF3ZWkuY29tIiB0YXJn ZXQ9Il9ibGFuayI+amF5YXJhZ2hhdmVuZHJhbi5rQGh1YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgWHVlbGVpLDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkFzIHBlciBSRkMgNDI3OSBhbHNvLCBib3RoIHRoZSBjbGllbnQgYW5kIHNlcnZlciBh cmUgc3VwcG9zZWQgdG8gaGF2ZSBhIHNldCBvZiDigJxJZGVudGl0eSDigJMga2V54oCdIHBhaXIm bmJzcDsNCiBvbiBlaXRoZXIgc2lkZXMuIFRoZSDigJxTZXJ2ZXJLZXlFeGNoYW5nZS5wc2tfaWRl bnRpdHlfaGludOKAnSBvbmx5IGhlbHBzIHRoZSBjbGllbnQgaW4gY2hvb3NpbmcgYW4g4oCcaWRl bnRpdHkta2V54oCdIHBhaXIgZnJvbSBhIGxpc3Qgb2Ygc2V2ZXJhbCDigJxpZGVudGl0eS1rZXkg cGFpcnPigJ0gdGhlIGNsaWVudCBtYXkgaGF2ZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JbiBUTFMgMS4zLCBp bnN0ZWFkIG9mIHRoZSBTZXJ2ZXJLZXlFeGNoYW5nZS5wc2tfaWRlbnRpdHlfaGludCwgY2xpZW50 IHNlbmRzIGl0cyBsaXN0IG9mIGlkZW50aXRpZXMNCiBpbiB0aGUgY2xpZW50IGhlbGxvIGl0c2Vs ZiB0aHJvdWdoIFByZVNoYXJlZEtleSBFeHRlbnNpb24gYW5kIHNlcnZlciBjaG9vc2VzIG9uZSBm cm9tIGl0IGFuZCByZXBsaWVzIGluIHRoZSBQcmVTaGFyZWRLZXkgRXh0ZW5zaW9uLiZuYnNwOyBO b3csIGluc3RlYWQgb2YgdHJhZGl0aW9uYWwgc2Vzc2lvbiByZXN1bXB0aW9uLCB0aGlzIGxvZ2lj IHdpbGwgYmUgdXNlZCAmbmJzcDt3aGljaCBiYXNpY2FsbHkgaGFzIHRoZSBzYW1lIGFiYnJldmlh dGVkIGhhbmRzaGFrZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TbywgZXNzZW50aWFsbHksIFRMUyAxLjIgdG8g VExTIDEuMyB0cmFuc2l0aW9uIGZvciB0aGUgYWJvdmUgc2NlbmFyaW8gc2hvdWxkIGJlIHZpZXdl ZCBhcyBiZWxvdzo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+KGEpPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkluIGNhc2Ugb2YgUFNLLCBpbnN0ZWFk IG9mIENsaWVudCBndWVzc2luZyBhbmQgdXNpbmcgYW4gSWRlbnRpdHkgYmFzZWQgb24gUFNLIElk ZW50aXR5IEhpbnQsIGJvdGggY2xpZW50IGFuZCBzZXJ2ZXIgbmVnb3RpYXRlIHdoaWNoIGlkZW50 aXR5IHRvIHVzZSBpbiB0aGUgaGVsbG8gbWVzc2FnZXMNCiBpdHNlbGYuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPihi KTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNw OyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5TZXJ2ZXJLZXlFeGNoYW5nZS5wc2tfaWRlbnRpdHlfaGludCBjYW4gYmUgb2Jzb2xldGVkIHJl bW92ZWQgd2hlbiB5b3UgdHJhbnNpdGlvbiBmcm9tIDEuMiB0byAxLjMuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+SW4gbXkgb3BpbmlvbiwgdGhpcyBtYWtlcyB0aGUgUFNLIGJh c2VkIGhhbmRzaGFrZSBhIGxvdCBtb3JlIHNpbXBsZXIgYW5kIGVhc2llciB0byB1c2UuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Q291bGQgeW91IGVsYWJvcmF0ZSBvbiB5b3VyIHNjZW5hcmlvIGJhc2VkIG9uIHdo aWNoIHlvdSBzYXkgdGhlIHRyYW5zaXRpb24gZnJvbSBUTFMgMS4yIHRvIFRMUyAxLjMNCiBmb3Ig UFNLIHdpbGwgYmUgZGlmZmljdWx0Pzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+SmF5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKjxicj4NClRoaXMgZS1tYWlsIGFuZCBhdHRhY2htZW50cyBjb250YWluIGNvbmZp ZGVudGlhbCBpbmZvcm1hdGlvbiBmcm9tIEhVQVdFSSwgd2hpY2ggaXMgaW50ZW5kZWQgb25seSBm b3IgdGhlIHBlcnNvbiBvciBlbnRpdHkgd2hvc2UgYWRkcmVzcyBpcyBsaXN0ZWQgYWJvdmUuIEFu eSB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaW4gYW55IHdheSAoaW5j bHVkaW5nLCBidXQgbm90IGxpbWl0ZWQgdG8sIHRvdGFsIG9yIHBhcnRpYWwNCiBkaXNjbG9zdXJl LCByZXByb2R1Y3Rpb24sIG9yIGRpc3NlbWluYXRpb24pIGJ5IHBlcnNvbnMgb3RoZXIgdGhhbiB0 aGUgaW50ZW5kZWQgcmVjaXBpZW50J3MpIGlzIHByb2hpYml0ZWQuIElmIHlvdSByZWNlaXZlIHRo aXMgZS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYnkgcGhvbmUgb3Ig ZW1haWwgaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSBpdCE8YnI+DQoqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKio8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBUTFMgW21haWx0bzo8YSBocmVmPSJtYWlsdG86 dGxzLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50bHMtYm91bmNlc0BpZXRmLm9y ZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlh1ZWxlaSBGYW48YnI+DQo8Yj5TZW50OjwvYj4g MjcgTm92ZW1iZXIgMjAxNSAxNzoyOTxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnRs c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRsc0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gW1RMU10gVExTIDEuMyBhbmQgUkZDIDQyNzksIFByZS1TaGFyZWQgS2V5IENpcGhl cnN1aXRlczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+SGksPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+SW4gdGhlIGRyYWZ0IHNwZWMgb2YgVExTIDEuMywgU2VydmVyS2V5RXhjaGFu Z2UgYW5kIENsaWVudEtleUV4Y2hhbmdlIGdldCByZW1vdmVkLCBhbmQga2V5X3NoYXJlIGV4dGVu c2lvbiBhcHBsaWVzIHRvJm5ic3A7bm9uLVBTSyBjaXBoZXIgc3VpdGVzIG9ubHkuIEFzIFJGQyA0 Mjc5IG5lZWQgU2VydmVyS2V5RXhjaGFuZ2UNCiBhbmQgQ2xpZW50S2V5RXhjaGFuZ2UgbWVzc2Fn ZXMsIEkgdGhpbmsgVExTIDEuMyB1cGRhdGVzIG9yIG9ic29sZXRlcyBSRkMgNDI3OS48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlBlciB0 aGUgZHJhZnQgc3BlYyBvZiBUTFMgMS4zLCBpZiBubyBzdWl0YWJsZSBpZGVudGl0eSBpcyBwcm92 aWRlZCBpbiBwcmUtc2hhcmVkIGtleSBleHRlbnNpb24sJm5ic3A7dGhlIHNlcnZlciBNVVNUIE5P VCBuZWdvdGlhdGUgYSBQU0sgY2lwaGVyIHN1aXRlLiZuYnNwOyBUaGUgcXVlc3Rpb24gY29tZXMg dG8gbWU6IHdoZXJlDQogdGhlIHN1aXRhYmxlIGlkZW50aXR5IGNvbWVzIGZyb20/Jm5ic3A7IFRo ZSBpZGVudGl0eSBjYW4gYmUgYWNxdWlyZWQgYnkgb3V0LW9mLWJhbmQgYXBwcm9hY2gsIG9yIHRo ZSBzZXJ2ZXIgTmV3U2Vzc2lvblRpY2tldCBtZXNzYWdlLiZuYnNwOyBJZiBubyBvdXQtb2YtYmFu ZCBhcHByb2FjaCBpbiBzb21lIGNpcmN1bXN0YW5jZXMsIHRoZSBzZXJ2ZXIgTmV3U2Vzc2lvblRp Y2tldCBtZXNzYWdlIHdvdWxkIGJlIHRoZSBvbmx5IHdheSB0byBjcmVhdGUgdGhlIGlkZW50aXR5 LiZuYnNwOw0KIFRoZSZuYnNwO3NjZW5hcmlvcyBvZiB1c2luZyAmbmJzcDtwcmUtc2hhcmVkIGtl eSBtYXkgbG9vayBsaWtlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4xLiBlc3RhYmxpc2ggYSBmcmVzaCBjb25uZWN0aW9uLCBzZXJ2ZXIgc2Vu ZHMgdGhlIE5ld1Nlc3Npb25UaWNrZXQgdG8gaW5kaWNhdGUgaXQgc3VwcG9ydHMgc2Vzc2lvbiBy ZXN1bXB0aW9uIGFuZCBwcm92aWRlIHRoZSBwc2tfaWRlbnRpdHkuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjIuIGlmIGNsaWVudCB3YW50cyBh IHNlc3Npb24gcmVzdW1wdGlvbiwgc3Vic2VxdWVudCBoYW5kc2hha2luZyB3aWxsIHVzZSBwcmVf c2hhcmVkIGtleSBleHRlbnNpb24gd2l0aCB0aGUgc2VydmVyIHByb3ZpZGVkIHBza19pZGVudGl0 eS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPkxvb2tzIGxpa2UgUFNLIGFwcGxpZXMgdG8gc2Vzc2lvbiByZXN1bWUgb25seSBpbiBUTFMg MS4zLCBhbmQgY2Fubm90IGJlIHVzZWQgZm9yIGZyZXNoIChpbml0aWFsKSBoYW5kc2hha2luZyBh bnkgbW9yZSwgJm5ic3A7dW5sZXNzIG91dC1vZi1iYW5kIGFwcHJvYWNoIGlzIHVzZWQgdG8gZGVm aW5lIHRoZSBpZGVudGl0aWVzLiZuYnNwOw0KIEkgaGF2ZSBubyBleHBlcmllbmNlIG9uIFBTSywg YnV0IGxvb2tzIGxpa2UgdGhhdCBpdCBpcyBub3QgQSBtaW5pbWFsIGVmZm9ydCBmb3IgUFNLIGRl cGxveW1lbnRzIHRvIHVwZ3JhZGUgZnJvbSBUTFMgMS4yIHRvIFRMUyAxLjMsIGlmIFNlcnZlcktl eUV4Y2hhbmdlLnBza19pZGVudGl0eV9oaW50IGlzIHVzZWQgcHJldmlvdXNseS48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkl0IHdvdWxk IGJlIG5pY2UgdG8gY29uc2lkZXIgYW5kIHNwZWNpZnkgdGhlIGltcGFjdCBvbiBSRkMgNDI3OSBp biBUTFMgMS4zIHByb3RvY29scy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlh1ZWxlaTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_8D925D4C0B78EE41857D407022ECD163BFF02DD7SZXEMI501MBXchi_-- From nobody Sun Nov 29 22:48:23 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04D0D1A8AE9 for ; Sun, 29 Nov 2015 22:48:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.485 X-Spam-Level: X-Spam-Status: No, score=-0.485 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DlPd_Xtpaa_a for ; Sun, 29 Nov 2015 22:48:20 -0800 (PST) Received: from mailsender.cdac.in (mailsender.cdac.in [196.1.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6DC1A8AE4 for ; Sun, 29 Nov 2015 22:48:19 -0800 (PST) Received: from ims.pune.cdac.in (ims.pune.cdac.in [10.208.1.15]) by mailsender.cdac.in (8.14.2/8.14.2) with ESMTP id tAU6m11u032417 for ; Mon, 30 Nov 2015 12:18:01 +0530 Received: from mailgw.pune.cdac.in ([10.208.1.4]) by ims.pune.cdac.in (8.14.4/8.14.4) with ESMTP id tAU6lXSX001927 for ; Mon, 30 Nov 2015 12:17:33 +0530 Received: from webmail.cdac.in (wbms.pune.cdac.in [10.208.1.9]) by mailgw.pune.cdac.in (8.14.2/8.13.8) with ESMTP id tAU6lWce008162 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 30 Nov 2015 12:17:32 +0530 Date: Mon, 30 Nov 2015 12:17:30 +0530 (IST) From: Sankalp Bagaria To: tls@ietf.org Message-ID: <259489845.2296.1448866050224.JavaMail.open-xchange@webmail.cdac.in> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2295_2041191810.1448866050167" X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v6.20.7-Rev15 X-CDAC-PUNE-MailScanner-ID: tAU6lXSX001927 X-CDAC-PUNE-MailScanner: Found to be clean, Found to be clean X-CDAC-PUNE-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-2.909, required 6, autolearn=disabled, ALL_TRUSTED -1.00, BAYES_00 -1.90, HTML_MESSAGE 0.00, T_RP_MATCHES_RCVD -0.01), not spam, SpamAssassin (not cached, score=-1.798, required 6, autolearn=disabled, ALL_TRUSTED -1.80, BAYES_50 0.00, HTML_MESSAGE 0.00) X-CDAC-PUNE-MailScanner-Information: Please contact npsfhelp@cdac.in/mailadmin@cdac.in for more information X-MailScanner-ID: tAU6m11u032417 X-CDAC-PUNE-MailScanner-From: sankalp@cdac.in X-CDAC-MailScanner-Spam-Status: No Archived-At: Subject: [TLS] Reference code of TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Sankalp Bagaria List-Id: "This is the mailing list for 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 Nov 2015 06:48:22 -0000 ------=_Part_2295_2041191810.1448866050167 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi, Does anybody have reference code of TLS 1.3, as much as developed till now, that s/he can share ? Thanks and Regards, Sankalp Bagaria. ------------------------------------------------------------------------------------------------------------------------------- [ C-DAC is on Social-Media too. Kindly follow us at: Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] This e-mail is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies and the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email is strictly prohibited and appropriate legal action will be taken. ------------------------------------------------------------------------------------------------------------------------------- ------=_Part_2295_2041191810.1448866050167 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
Hi,
 
Does anybody have reference code of TLS 1.3, as much
as developed till now, that s/he can share ?
 
Thanks and Regards,
Sankalp Bagaria.

-------------------------------------------------------------------------------------------------------------------------------
[ C-DAC is on Social-Media too. Kindly follow us at:
Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]

This e-mail is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. If you are not the
intended recipient, please contact the sender by reply e-mail and destroy
all copies and the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this email
is strictly prohibited and appropriate legal action will be taken.
------------------------------------------------------------------------------------------------------------------------------- ------=_Part_2295_2041191810.1448866050167-- From nobody Mon Nov 30 00:56: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 0B0A61B2D18 for ; Mon, 30 Nov 2015 00:56: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 bknooiUEA21z for ; Mon, 30 Nov 2015 00:56:09 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::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 21CE61B2D0E for ; Mon, 30 Nov 2015 00:56:09 -0800 (PST) Received: by wmvv187 with SMTP id v187so145300744wmv.1 for ; Mon, 30 Nov 2015 00:56:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=kXt7uW0s/nOCAIEIG1LFbZEIZ/mBOpzeybAE59uCVWo=; b=Dw5PjAew2tksHmh+OGTsPaZc6MbjQwWgSbeyZG0TcKuCodv5jQLj0zc5z2jwPzyM/v Y3CPLcTCL6asu9BCEnRqjMvMA1pz1Qk6TJNVy1vhUXKsOCdFwuOgOrsZp4QSxIJMua4r cOf14A9Lk0Wf+QIFagA/jIDPw3pL6pNmSUSbcfGZkqW3kPg+Hky0b/BUUswhJUnkocox FbcDoWAxX5YQol/+Abz/RZoVbfnA6hqsmy1/Yz8xcEFCRciByqrP0UplHXtapQH2dTXg o9uMr5/q0TD7gDKQM4uU8GTeIVeRNjT3+X7V3ieyrTnOJk4z73fy1+61/a4tzR3BIEnu 18lA== X-Received: by 10.28.48.213 with SMTP id w204mr24966510wmw.38.1448873767546; Mon, 30 Nov 2015 00:56:07 -0800 (PST) Received: from tsf-476-wpa-0-088.epfl.ch (tsf-476-wpa-0-088.epfl.ch. [128.179.176.88]) by smtp.gmail.com with ESMTPSA id kc9sm12221852wjc.34.2015.11.30.00.56.06 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 Nov 2015 00:56:06 -0800 (PST) To: Peter Gutmann , "tls@ietf.org" References: <56586A2F.1070703@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B8DA2A@uxcn10-5.UoA.auckland.ac.nz> <565AC278.2010904@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B92E74@uxcn10-5.UoA.auckland.ac.nz> From: Bryan A Ford X-Enigmail-Draft-Status: N1110 Message-ID: <565C0F25.7000507@gmail.com> Date: Mon, 30 Nov 2015 09:56:05 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B92E74@uxcn10-5.UoA.auckland.ac.nz> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010708000107020700090804" Archived-At: Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 08:56:11 -0000 This is a cryptographically signed message in MIME format. --------------ms010708000107020700090804 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 11/30/15 2:26 AM, Peter Gutmann wrote: > Bryan A Ford writes: >=20 >> Feel free to attack my proposal but then please attack *my* proposal, = not=20 >> the old broken SSH approach. >=20 > I was actually commenting on the concept of encrypting headers in gener= al, > not the specific case you'd given. That is, I assumed you'd specifical= ly=20 > chosen the one case where it's practical, an AEAD stream cipher, and us= ed > that as a strawman. Re-reading your post, it looks like "adding a stre= am > cipher to every TLS 1.3-compatible ciphersuite" should really be "requi= re > that the only cipher type allowed for TLS be an AEAD stream cipher",=20 > because it's not going to work with anything else. In my proposal I focused on AEAD because I had understood (and thought I had read in the TLS spec) that TLS had decided to move to AEAD-based encryption in general. I had no intention of implying that TLS "must" switch to AEAD completely, and there's no reason it would need to for my proposal to work. It would work just as well and in exactly the same way if the AEAD is replaced with the traditional Encrypt-then-MAC construction, for example. Also, if any issues with some (e.g., old) ciphersuites do arise, I wouldn't object to specifying that TLS header encryption is done only with "new" ciphersuites (e.g., the AEAD-based ones, or using some other appropriate definition of "new"). Bryan --------------ms010708000107020700090804 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfgwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVBMIIEKaADAgECAhAWpZtNxHBkhVoG2HKaeabqMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwNjI0MDAwMDAwWhcNMTYwNjIzMjM1OTU5WjAmMSQwIgYJKoZIhvcNAQkB FhVicnlub3NhdXJ1c0BnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDAPPVOZLVu2tZOao2osnGxGwYy7nC3UX8yoebrOfaNWkItIkUH6NQRKuqxuDE7127q48VH c7kwmg4DifoOjxSjXyT+R9pR/ethFwjXiWCjsIaWbcFc6X7D1fIisO14z8D4luBO1LezNVB6 Dee8lMutP9OO4MmKWYq3+Jab9Rv/3BXCyiDDQfxhiuWFzZQTWpbzGGfwitcqPHH97PN4COCh hhOuUS9Yt1qQBY8Gn36eVepKdz3YiF7ii/JDth1iA/zHK8pyim+OgERcwo6Ildqh59uy0IjM AcKA1Mc34AgMQJdLlmhYAai5nMLOJQiFzfIyB6egjSyishx11rpL/xKlAgMBAAGjggHzMIIB 7zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQUpXGtiQ4RgWPr 1UjnydSPtyPTai8wDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYI KwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsG DCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEF BQcBAQSBgzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RP U0hBMjU2Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEF BQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCAGA1UdEQQZMBeBFWJyeW5vc2F1cnVz QGdtYWlsLmNvbTANBgkqhkiG9w0BAQsFAAOCAQEADDSBNRYWArRAPSTMC6DSrUOIWQ3J1CmE XEYoQ4QByCkkybRUCgXIadTAUwj+D9ZX4HQxxvtOkb+uVQCnwbI6jGZj0Mpb7MWYOZDyeQT1 YEoUMRpeUUpTDd6iw3Em0Lf+rj7/VPlYKvErTCOnyEUm2z8MismcjPIFJ8Ud+HccyfpkhotJ HbVBN+hSGm03l7YxVVzf9owzq7L5vCB5afJyTNt5x7qlLCcsiGBW2kSoQKaDAMwuYMp5YOgD 1doc/yWJSkiQAcKcWY2ALacs+a0FSItqT1rNk3tnHX2spIrBgDrv+5ybZXBBjAknetbTON5m rWT2tzLgYpKPJLs49ETIoDGCBEEwggQ9AgEBMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UE CBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJYIZIAWUD BAIBBQCgggJhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MTEzMDA4NTYwNVowLwYJKoZIhvcNAQkEMSIEIKuw/C6uy0Jtvq4yEqXrA7vTsnVkzusEqX2h hhf5BRWUMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgcEGCSsGAQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAWpZtNxHBkhVoG2HKaeabqMIHDBgsqhkiG9w0B CRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBAhAWpZtNxHBkhVoG2HKaeabqMA0GCSqGSIb3DQEBAQUABIIBAASnlYG715vf6L6W be54/cx9uHpQxMmgJa2v2NFXf4PnEhbDRttz7K8ab7LaThe5LSfmZre9Dc0Qz+Uq/KIBt4hS blaN6LDUDXdrq26eMXzdH4uYfvEU5DSO0Fe+SUhaBlBfHn1WOsdWAk4my/YkkvJkVOqnFeaW ETTcmAX1vz6iu92UovokOgPv59JKlMoQMSKhVvS/VWJztHvR0oxTWiZIngev7AeY0gg3UhGq y1yqmVMBb835vXf92bXuAuTwNGTzSDgriIohy9lu68HaJOaZ4Q2HKr9Q9D9+bE2O8Dx7oTGV q/dV6vy93StOj+9wGqVhj8Hj589ivan0rmebytAAAAAAAAA= --------------ms010708000107020700090804-- From nobody Mon Nov 30 01:58: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 C34661A897F for ; Mon, 30 Nov 2015 01:58:54 -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 bhZuLKJZEO4G for ; Mon, 30 Nov 2015 01:58:52 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 3E74C1A897E for ; Mon, 30 Nov 2015 01:58:52 -0800 (PST) Received: by wmvv187 with SMTP id v187so147874344wmv.1 for ; Mon, 30 Nov 2015 01:58:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type; bh=hU/yqjfROvSNx3xdXMs8/DD1wqf39v6wep2NTxR1zFg=; b=ZpCxFLNvT8khp5DD92LWwytyeKXVMuyCVTTuBK1erSWzl5bWIHNNbfCOD917aJ+wRU gdfg6a94CL7JktUpsrh6ElaOceoye4GpbeMUF/KRV6fglwhGRTMgndZN/TQYlbWHep6O sFRb5B1Vzj0q5ftRWF0dXA8fqkp+K764ItCyG8kG8mgirK4DNQmHbnK/Su0v/QAiIUoW HM+Rqt1g/Vn+lJlEn4Iv6nk2uR0l9PjPCQTciRw7HF7x12I8tdyFjpCZt+GCcdQ91x0h LGQW705p/WMelgrrSqzbFYgYYMy1Eztz/KZMa+svlI233BvZjQP7J0xiukIYU7MIgq8Z OEYQ== X-Received: by 10.194.117.163 with SMTP id kf3mr59888070wjb.139.1448877530827; Mon, 30 Nov 2015 01:58:50 -0800 (PST) Received: from tsf-476-wpa-0-088.epfl.ch (tsf-476-wpa-0-088.epfl.ch. [128.179.176.88]) by smtp.gmail.com with ESMTPSA id vu4sm45945706wjc.2.2015.11.30.01.58.49 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 Nov 2015 01:58:49 -0800 (PST) To: Peter Gutmann , Nikos Mavrogiannopoulos References: <56586A2F.1070703@gmail.com> <2006084219.21103856.1448827238217.JavaMail.zimbra@redhat.com> <9A043F3CF02CD34C8E74AC1594475C73F4B92EA4@uxcn10-5.UoA.auckland.ac.nz> From: Bryan A Ford X-Enigmail-Draft-Status: N1110 Message-ID: <565C1DD8.20305@gmail.com> Date: Mon, 30 Nov 2015 10:58:48 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B92EA4@uxcn10-5.UoA.auckland.ac.nz> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040906000808090509040100" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 09:58:54 -0000 This is a cryptographically signed message in MIME format. --------------ms040906000808090509040100 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 11/30/15 2:40 AM, Peter Gutmann wrote: > Nikos Mavrogiannopoulos writes: >=20 >> I believe your proposal is a nice example of putting the cart before t= he >> horse. Before proposing something it should be clear what do you want = to >> protect from, what is the threat? >=20 > Exactly. If you want to thwart traffic analysis, you need to do someth= ing > like what's done by designs like Aqua ("Towards Efficient Traffic-analy= sis=20 > Resistant Anonymity Networks"), or ideas from any of the other anti-tra= ffic- > analysis work that's emerged in the past decade or two. I'm well aware of Aqua and "the other anti-traffic-analysis work that's emerged in the past decade or two": in fact I led one of the major recent systematic projects in that space. See for example: http://dedis.cs.yale.edu/dissent/ http://cacm.acm.org/magazines/2015/10/192387-seeking-anonymity-in-an-int= ernet-panopticon/fulltext > You get traffic > analysis resistance by, for example, breaking data into fixed-length > packets, using cover traffic, and messing with packet timings, not by > encrypting TLS headers. Packet padding and header encryption are both important, complementary security measures: you get security benefits from each that you don't get from the other. Yes, you need padding to obtain systematic protection from traffic analysis - when for whatever reason not all implementations are always padding to the exact same standardized record length, header encryption makes padded streams less trivially distinguishable from unpadded streams, and makes streams with different record sizes less trivially distinguishable from each other. Padding-based transmission formats such as Aqua and Tor tend to specify a single fixed packet size for *all* traffic using that protocol. For example, the Tor protocol always uses 256-byte cells for everything. This is for obvious indistinguishability reasons: e.g., if some versions of Tor padded to 256 bytes while other versions padded to 512 bytes, then it would be trivial for an adversary to distinguish the two. And if the 512-byte version of Tor were fairly uncommon (either because it's "too new" or "too old" or specific to a rare platform or whatever), then the Tor streams using 512-byte cells would stick out obviously from anyone else. Furthermore, popular and well-designed as it is, Tor and similar protocols have the well-known problem that it's pretty trivial for a traffic analysis attacker to distinguish a Tor stream from any other non-Tor stream. The severity of this weakness was put in sharp perspective by the Harvard bomb hoax incident (http://edition.cnn.com/2013/12/18/justice/massachusetts-harvard-hoax/). And it's not in any way because Tor was poorly-designed: on the contrary, the problem is Tor sticks out because it's a well-designed traffic-analysis-resistant protocol sharply silhouetted against a backdrop of traffic that makes no attempt at traffic analysis protection. One thing that would greatly help Tor and all similar, padded protocols is if they could "blend in" even just a little bit better with the vast bulk of ordinary TLS-encrypted Web traffic, and that's one of the big opportunities we're talking about here. But to make that happen, we would need to either (a) specify that *all* TLS 1.3 implementations use the same standardized record length like Tor does, or (b) if that's not practical, do whatever we can to make flows padded to a particular size less obviously distinguishable from unpadded flows or flows padded to a different size. If you think it is practical for the TLS 1.3 standard to specify a single, fixed record size that all implementations of TLS 1.3 must use (i.e., explicitly freeze not only the version field but the length field), then that would be great for traffic analysis protection and on that basis I would support that proposal. But that frankly seems to me likely a bit too much to ask given the diversity of TLS implementations and use-cases. Tell me if you believe otherwise. So on the assumption that TLS 1.3 might not be ready to jump "whole-hog" into Aqua/Tor-style transmission protocols that standardize a single constant record size, I believe that header encryption provides at least a useful, weak but significant security improvement at negligible cost. Sure, active attackers can still use "dribble attacks" (as discussed recently on the SSH mailing list) to sniff out the record boundaries, but they have to be active on-path and have to delay traffic, which risks getting noticed. Many attackers in practice are passive (don't have the option or just don't want to invest the resources for full MITM), and/or don't want to risk getting noticed by fiddling with the traffic in readily detectable ways. Cheers Bryan >=20 > Peter. >=20 --------------ms040906000808090509040100 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfgwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVBMIIEKaADAgECAhAWpZtNxHBkhVoG2HKaeabqMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwNjI0MDAwMDAwWhcNMTYwNjIzMjM1OTU5WjAmMSQwIgYJKoZIhvcNAQkB FhVicnlub3NhdXJ1c0BnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDAPPVOZLVu2tZOao2osnGxGwYy7nC3UX8yoebrOfaNWkItIkUH6NQRKuqxuDE7127q48VH c7kwmg4DifoOjxSjXyT+R9pR/ethFwjXiWCjsIaWbcFc6X7D1fIisO14z8D4luBO1LezNVB6 Dee8lMutP9OO4MmKWYq3+Jab9Rv/3BXCyiDDQfxhiuWFzZQTWpbzGGfwitcqPHH97PN4COCh hhOuUS9Yt1qQBY8Gn36eVepKdz3YiF7ii/JDth1iA/zHK8pyim+OgERcwo6Ildqh59uy0IjM AcKA1Mc34AgMQJdLlmhYAai5nMLOJQiFzfIyB6egjSyishx11rpL/xKlAgMBAAGjggHzMIIB 7zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQUpXGtiQ4RgWPr 1UjnydSPtyPTai8wDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYI KwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsG DCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEF BQcBAQSBgzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RP U0hBMjU2Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEF BQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCAGA1UdEQQZMBeBFWJyeW5vc2F1cnVz QGdtYWlsLmNvbTANBgkqhkiG9w0BAQsFAAOCAQEADDSBNRYWArRAPSTMC6DSrUOIWQ3J1CmE XEYoQ4QByCkkybRUCgXIadTAUwj+D9ZX4HQxxvtOkb+uVQCnwbI6jGZj0Mpb7MWYOZDyeQT1 YEoUMRpeUUpTDd6iw3Em0Lf+rj7/VPlYKvErTCOnyEUm2z8MismcjPIFJ8Ud+HccyfpkhotJ HbVBN+hSGm03l7YxVVzf9owzq7L5vCB5afJyTNt5x7qlLCcsiGBW2kSoQKaDAMwuYMp5YOgD 1doc/yWJSkiQAcKcWY2ALacs+a0FSItqT1rNk3tnHX2spIrBgDrv+5ybZXBBjAknetbTON5m rWT2tzLgYpKPJLs49ETIoDGCBEEwggQ9AgEBMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UE CBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJYIZIAWUD BAIBBQCgggJhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MTEzMDA5NTg0OFowLwYJKoZIhvcNAQkEMSIEINL17dPqfz7zoiPKYfGVTE0naUgVl9Rj6e9R 2m4Xuv8ZMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgcEGCSsGAQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAWpZtNxHBkhVoG2HKaeabqMIHDBgsqhkiG9w0B CRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBAhAWpZtNxHBkhVoG2HKaeabqMA0GCSqGSIb3DQEBAQUABIIBAAa26C109dKwZk+p /vJ7z3nf0ZrsvwswECGOy4iI7HWuCuUGLKvfrhqJxHmvIjtmg4paMY7peV4swzROBjhH6p6c QpTnwUADME3TIg4NejkVn27yB+EecNHHHDJoaTkmEZxq8nubhv8951+aNac4tV+VBBzD0YfB 2e6iaoqfDx7NzdL+SsqGqAyYXiRa/Mr7HTz+2/7a7X8q8HA6LTttiXXDA3yJg1s0N36Cfht/ 7FbhpFXDCISLUdMr1rmMvvjKsV+cT7ztAMOYujAo6VLYNR3fApr1fBnXs84Dr3CGV/znIs01 adJF4cF4w1NBVDxvthMlySZjR/axZnHA/Mbe3qYAAAAAAAA= --------------ms040906000808090509040100-- From nobody Mon Nov 30 02:02: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 8A05B1A89A8 for ; Mon, 30 Nov 2015 02:02:36 -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 IV22DIlVa9FT for ; Mon, 30 Nov 2015 02:02:35 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 AF2061A89A7 for ; Mon, 30 Nov 2015 02:02:34 -0800 (PST) Received: by wmec201 with SMTP id c201so130508142wme.1 for ; Mon, 30 Nov 2015 02:02:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type; bh=uLn+D5DRiS5W2SH60tx51ffrGsneCGqSP6TrYlspRvo=; b=ggNGXjFIUshgSiepQb5t3LQr+z5tfi0O/2YyXKfrMGN+7ppKNBvZ+HJPC6xMVb2B7h P7VIXQoHra4loY6BzhdRtKtnceg0OrrvInwThCo8oiASSSyg7PcU2gN+qRVuWEnld6mm 4Dq0XQ1WmNSSLB5ngtT0Kgl4ZSWQes5oYh4UQLXLwlO92dadq0j21/xBbibi1hzT8O4g /7DQ8zrNMXurKSDid28u4x0zfMsJhkrQvUCYj/pe0Xxb2uJMnOUheexFp9bh4vHd4fSW hHQn8uhgeBsIyNO41ZAwMP6d5ntO3+wd8ZFhkdK0mOEO6sCKf/Au9VCRBuKEt+gejLwF 7DmA== X-Received: by 10.194.87.201 with SMTP id ba9mr35931687wjb.125.1448877753339; Mon, 30 Nov 2015 02:02:33 -0800 (PST) Received: from tsf-476-wpa-0-088.epfl.ch (tsf-476-wpa-0-088.epfl.ch. [128.179.176.88]) by smtp.gmail.com with ESMTPSA id q6sm45841936wjx.28.2015.11.30.02.02.31 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 Nov 2015 02:02:32 -0800 (PST) To: "Short, Todd" , Peter Gutmann References: <56586A2F.1070703@gmail.com> <2006084219.21103856.1448827238217.JavaMail.zimbra@redhat.com> <9A043F3CF02CD34C8E74AC1594475C73F4B92EA4@uxcn10-5.UoA.auckland.ac.nz> From: Bryan A Ford Message-ID: <565C1EB7.5030709@gmail.com> Date: Mon, 30 Nov 2015 11:02:31 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050802090403090606010804" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 10:02:36 -0000 This is a cryptographically signed message in MIME format. --------------ms050802090403090606010804 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 11/30/15 2:54 AM, Short, Todd wrote: > This brings up an interesting point; having a record length that corres= ponds to the TCP segment size can help hardware implementations such that= they don't need to deal with scatter/gather; i.e. one TCP segment corres= ponds to a single TLS record. This goes along with 8 (or 4) byte record l= engths for hardware implementations.=20 This is wildly unsafe to assume or depend on for all sorts of reasons; TCP streams regularly get merged or re-segmented in the network in a variety of unpredictable ways (e.g., by middleboxes). See my earlier E-mail discussing that issue extensively. B --------------ms050802090403090606010804 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfgwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVBMIIEKaADAgECAhAWpZtNxHBkhVoG2HKaeabqMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwNjI0MDAwMDAwWhcNMTYwNjIzMjM1OTU5WjAmMSQwIgYJKoZIhvcNAQkB FhVicnlub3NhdXJ1c0BnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDAPPVOZLVu2tZOao2osnGxGwYy7nC3UX8yoebrOfaNWkItIkUH6NQRKuqxuDE7127q48VH c7kwmg4DifoOjxSjXyT+R9pR/ethFwjXiWCjsIaWbcFc6X7D1fIisO14z8D4luBO1LezNVB6 Dee8lMutP9OO4MmKWYq3+Jab9Rv/3BXCyiDDQfxhiuWFzZQTWpbzGGfwitcqPHH97PN4COCh hhOuUS9Yt1qQBY8Gn36eVepKdz3YiF7ii/JDth1iA/zHK8pyim+OgERcwo6Ildqh59uy0IjM AcKA1Mc34AgMQJdLlmhYAai5nMLOJQiFzfIyB6egjSyishx11rpL/xKlAgMBAAGjggHzMIIB 7zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQUpXGtiQ4RgWPr 1UjnydSPtyPTai8wDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYI KwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsG DCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEF BQcBAQSBgzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RP U0hBMjU2Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEF BQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCAGA1UdEQQZMBeBFWJyeW5vc2F1cnVz QGdtYWlsLmNvbTANBgkqhkiG9w0BAQsFAAOCAQEADDSBNRYWArRAPSTMC6DSrUOIWQ3J1CmE XEYoQ4QByCkkybRUCgXIadTAUwj+D9ZX4HQxxvtOkb+uVQCnwbI6jGZj0Mpb7MWYOZDyeQT1 YEoUMRpeUUpTDd6iw3Em0Lf+rj7/VPlYKvErTCOnyEUm2z8MismcjPIFJ8Ud+HccyfpkhotJ HbVBN+hSGm03l7YxVVzf9owzq7L5vCB5afJyTNt5x7qlLCcsiGBW2kSoQKaDAMwuYMp5YOgD 1doc/yWJSkiQAcKcWY2ALacs+a0FSItqT1rNk3tnHX2spIrBgDrv+5ybZXBBjAknetbTON5m rWT2tzLgYpKPJLs49ETIoDGCBEEwggQ9AgEBMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UE CBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJYIZIAWUD BAIBBQCgggJhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MTEzMDEwMDIzMVowLwYJKoZIhvcNAQkEMSIEIGaBuwTOT8YWozCDYWlPD5b9kxDwYMxvYybT r2VqQHB4MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgcEGCSsGAQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAWpZtNxHBkhVoG2HKaeabqMIHDBgsqhkiG9w0B CRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBAhAWpZtNxHBkhVoG2HKaeabqMA0GCSqGSIb3DQEBAQUABIIBAL093iD9dC7Hol3v LQAFu1aZ3En22APikiQCYAPl2Q6ORsEUn4QWl3W1VIZuguUJRrZmxr20qRkITL76f1Juzhvp Vnj9FfEzvWMWlvuZIETefT8eoLvLEdHCPjypN09X0FL2pZXN7bY49Tele14kCe+42MZb9agE zAX91Bf8GpN3vl9l687G2wthQ8nRPKvLY3vA9JSRgF4RiQG9LtgrDY8KOmP6t6mUgV6eJJS+ oeyIE12+q5AWpgMP0f4rfwGCsC58t7YvR5ZqSbS2C6VdlxvgjbtST3d5EEmHWxy24R+Q77zy KpBJzmblLVaYvqANan7DyFUvAoalPYna6UWmjtwAAAAAAAA= --------------ms050802090403090606010804-- From nobody Mon Nov 30 02: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 3289F1A8A3F for ; Mon, 30 Nov 2015 02:16:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLdn1DBXibbV for ; Mon, 30 Nov 2015 02:16:20 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::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 723E91A8A3E for ; Mon, 30 Nov 2015 02:16:19 -0800 (PST) Received: by wmww144 with SMTP id w144so122387342wmw.1 for ; Mon, 30 Nov 2015 02:16:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=5iQChHL6G93NIbu9qqnhkf8PMwNUfyNL7tZZBoeKiWQ=; b=zkjOsq8fueyeq8aDnLfa4CaMNB6Yc3n+RrSuTFSXpivtNxVNo2VK5i8Kgcab/blntF o57pwNnLDBQfQ5fP9w7tVRAC0ozrxxIAC2qHrU1gPv8F41HT3U6AWA/wh+n9OrIqNpUb wjyWZCDdn+hdfSBB5OpjVm377jv07cBhF4a0K5KtpfSD8smsPQqlkvoB8+pnNuv874MO S6S7MjQJVZ6wndpIMdb8D5CYJC4clk6ec7eTAjlA1TNA9kqo3GG7loyht/HMN/ZShqP3 pBWLF/wma1tAn2r72iiJiBeUKAR7qiVS4tYGwUvXwxGRft84bwrJ6S8UYOTyPdJT30gx VJPw== X-Received: by 10.28.50.70 with SMTP id y67mr27871229wmy.91.1448878578028; Mon, 30 Nov 2015 02:16:18 -0800 (PST) Received: from tsf-476-wpa-0-088.epfl.ch (tsf-476-wpa-0-088.epfl.ch. [128.179.176.88]) by smtp.gmail.com with ESMTPSA id i84sm20739946wmc.20.2015.11.30.02.16.16 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 Nov 2015 02:16:16 -0800 (PST) To: Bill Cox , "tls@ietf.org" References: <56586A2F.1070703@gmail.com> <565882FE.80205@streamsec.se> <565AC9D1.700@gmail.com> <565AE180.70101@streamsec.se> <565AEB5A.9000503@gmail.com> From: Bryan A Ford X-Enigmail-Draft-Status: N1110 Message-ID: <565C21EF.1060600@gmail.com> Date: Mon, 30 Nov 2015 11:16:15 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020302030704060605020907" Archived-At: Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 10:16:25 -0000 This is a cryptographically signed message in MIME format. --------------ms020302030704060605020907 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks Bill for the feedback. On 11/29/15 6:11 PM, Bill Cox wrote: > Thanks for the detailed description of why we might want to obfuscate > TLS record lengths. From a security point of view, the only potential > attack vector this might create is that the attacker will know in many > cases the plain text of the first 5 bytes. A weakness in the stream > cipher might be more easily exploited in this case. IIUC, we feel > pretty good about the latest AEAD ciphers, and guessing the clear text > of many bytes in the record already is not too hard. Is that right?=20 > So, from my fairly uninformed point of view, this seems like a > reasonable upgrade. Just a nitpicky semantic correction: my proposal doesn't "create" the attack vector you describe (that the attacker will know the plaintext of the 5-byte header). That weakness is already there in TLS 1.3 as currently specified, because the TLS header is unencrypted so the attacker will *definitely* know the 5-byte header. :) This is merely an existing weakness that is not fixed by my proposal. > I have one concern. These same boxes that hide record lengths by > merging and breaking up packets arbitrarily likely would deliver the > packets not well aligned to record boundaries. Is this already the > case? =20 It's already the case that middleboxes of various kinds re-segment (merge and break up along different boundaries) TCP streams for various reasons, often as an unintentional side-effect of interposing on the stream by "accepting" the TCP connection (pretending to be an endpoint) on one of the middlebox's interfaces and opening a new outgoing connection on the other interface, and just forwarding the traffic between them. In fact, Performance Enhancing Proxies (PEPs) are one class of middlebox that often do this intentionally, so they can get better control over and fiddle with the way congestion control works over "troublesome" types of links like high-bandwidth-delay-product (e.g., satellite) links. > If these boxes currently inspect packets when breaking them up to > split packets along record boundaries, encrypting the lengths will > defeat this efficiency hack. We might cause an increase in network > latency in this case. Do any of the routers out there currently use th= e > record length field when splitting up packets? If I understand your question correctly, you're asking if encrypting TLS record lengths might break middleboxes that currently want to track TLS records for some reason, e.g., perhaps to re-segment the TCP stream to correspond to TLS records (which might "fix" or "revert" the effect of another middlebox in the path that re-segments TCP in a TLS-oblivious fashion). I don't know of any middleboxes that do precisely this, but it's not inconceivable that they could exist. More generally, since basically all manner of evil/broken middleboxes do exist, it's entirely possible that most any change to TLS's wire encoding *could* disagree with some middleboxes. That's not specific to the change I'm proposing; any wire-visible change could trigger unknown middlebox badness. The only solution to this I'm aware of is empirical: try the change, deploy it experimentally at first, and see what the pain level is, i.e., see if we find any middleboxes that complain and if so how prevalent they are. But since TLS 1.3 is already changing a lot of other prominently wire-visible stuff with respect to prior versions of TLS that might equally well break middleboxes, it's not clear that my proposed change in particular is more likely to cause pain than any of the other changes already made, and in general I don't think we should let a few broken/evil middleboxes prevent meaningful evolution of the TLS protocol. Cheers Bryan >=20 > Bill --------------ms020302030704060605020907 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfgwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVBMIIEKaADAgECAhAWpZtNxHBkhVoG2HKaeabqMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwNjI0MDAwMDAwWhcNMTYwNjIzMjM1OTU5WjAmMSQwIgYJKoZIhvcNAQkB FhVicnlub3NhdXJ1c0BnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDAPPVOZLVu2tZOao2osnGxGwYy7nC3UX8yoebrOfaNWkItIkUH6NQRKuqxuDE7127q48VH c7kwmg4DifoOjxSjXyT+R9pR/ethFwjXiWCjsIaWbcFc6X7D1fIisO14z8D4luBO1LezNVB6 Dee8lMutP9OO4MmKWYq3+Jab9Rv/3BXCyiDDQfxhiuWFzZQTWpbzGGfwitcqPHH97PN4COCh hhOuUS9Yt1qQBY8Gn36eVepKdz3YiF7ii/JDth1iA/zHK8pyim+OgERcwo6Ildqh59uy0IjM AcKA1Mc34AgMQJdLlmhYAai5nMLOJQiFzfIyB6egjSyishx11rpL/xKlAgMBAAGjggHzMIIB 7zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQUpXGtiQ4RgWPr 1UjnydSPtyPTai8wDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYI KwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsG DCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEF BQcBAQSBgzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RP U0hBMjU2Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEF BQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCAGA1UdEQQZMBeBFWJyeW5vc2F1cnVz QGdtYWlsLmNvbTANBgkqhkiG9w0BAQsFAAOCAQEADDSBNRYWArRAPSTMC6DSrUOIWQ3J1CmE XEYoQ4QByCkkybRUCgXIadTAUwj+D9ZX4HQxxvtOkb+uVQCnwbI6jGZj0Mpb7MWYOZDyeQT1 YEoUMRpeUUpTDd6iw3Em0Lf+rj7/VPlYKvErTCOnyEUm2z8MismcjPIFJ8Ud+HccyfpkhotJ HbVBN+hSGm03l7YxVVzf9owzq7L5vCB5afJyTNt5x7qlLCcsiGBW2kSoQKaDAMwuYMp5YOgD 1doc/yWJSkiQAcKcWY2ALacs+a0FSItqT1rNk3tnHX2spIrBgDrv+5ybZXBBjAknetbTON5m rWT2tzLgYpKPJLs49ETIoDGCBEEwggQ9AgEBMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UE CBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJYIZIAWUD BAIBBQCgggJhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MTEzMDEwMTYxNVowLwYJKoZIhvcNAQkEMSIEIIig4zKQ9gvK4uA8o8DyTC1z7NZlyTkIYvSk ccJ0RV+kMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgcEGCSsGAQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAWpZtNxHBkhVoG2HKaeabqMIHDBgsqhkiG9w0B CRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBAhAWpZtNxHBkhVoG2HKaeabqMA0GCSqGSIb3DQEBAQUABIIBAC0vndcvLtC7SMix qUU7IgH09d2/kXeANildHdLDhnmbgJcJPj3qwNuzgiuaaFKE4ARiYxqng6gGkpOhGx4h0DEy gJH28CBhqV1kWCuGe7sWmc32KpTccthc5Ndj+1uEzYeiKuNEOb3RahtacnR0/ggy+DymVjc7 U/q0wSyYZFAytaxwxauJmkbdxKZVLpDLR6y0yoDbtAkZ84y7gidRpcOhhiZJn/+oyEfRcHkO NKbEWjfNJcYALhc0mf49abvpNaQQLLPHwBefJPTOpJaXUfmfTj4ci2+MZWGwIwZveR1Ezx1s 9pN4eYjMvnL3OWSkCa3UOJ+E4QCjTC08G+AoVmwAAAAAAAA= --------------ms020302030704060605020907-- From nobody Mon Nov 30 02:34: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 A1DF11A8AA5 for ; Mon, 30 Nov 2015 02:34:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[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 5yyEGWPcGtv4 for ; Mon, 30 Nov 2015 02:34:32 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB4631A8A9B for ; Mon, 30 Nov 2015 02:34:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1448879671; x=1480415671; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=0ZE1CemPDf3mxPJM3XUJqaCHoPYlQQQC9eVPiffpgNc=; b=CYg7wfkVhOSuViWMVK/AeG7oSX7mhNuuuucjOXfwkjfqUKcz75pcPlVc 7yspuaCGsItS7lTQ2+B7iOQBKLIdUtLH0HGtzW+yPL/yZP11x4Dn/KEaR E0QSqqDjDUKaq2tbhAV1ehDDStEyA3tpmFyWFs/fEwhD9XCsezG+N222J oeOimVID5m+VLQJfUpa5cSrVFvGl9gymKukGti7vpbjdNAvGz9mXyit6f iKJRp+xqn7QYwG2h33/mXUE36H5MxVOxhybc0nne+CLVcOhUeBDU5B/x6 T1/lB5g1ZPBj2VqlgWuFb4w/xz8S443lIpwrVFft/WoUjKQSXlC6CysGS A==; X-IronPort-AV: E=Sophos;i="5.20,364,1444647600"; d="scan'208";a="56798617" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxchange10-fe2.UoA.auckland.ac.nz) ([130.216.4.106]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 30 Nov 2015 23:34:28 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.153]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0266.001; Mon, 30 Nov 2015 23:34:29 +1300 From: Peter Gutmann To: Bryan A Ford , "tls@ietf.org" Thread-Topic: [TLS] Encrypting record headers: practical for TLS 1.3 after all? Thread-Index: AQHRKSDnEzBCXT12GkOsH7hTugsdcp6xSadegACXeACAAeiXe///o/6AgAD0l3o= Date: Mon, 30 Nov 2015 10:34:27 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B9331B@uxcn10-5.UoA.auckland.ac.nz> References: <56586A2F.1070703@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B8DA2A@uxcn10-5.UoA.auckland.ac.nz> <565AC278.2010904@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B92E74@uxcn10-5.UoA.auckland.ac.nz>, <565C0F25.7000507@gmail.com> In-Reply-To: <565C0F25.7000507@gmail.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 10:34:38 -0000 Bryan A Ford writes:=0A= =0A= >It would work just as well and in exactly the same way if the AEAD is=0A= >replaced with the traditional Encrypt-then-MAC construction, for example.= =0A= =0A= No it wouldn't, unless the encrypt part is a stream cipher. You're still= =0A= locked into using an AEAD stream cipher or the equivalent of an AEAD stream= =0A= cipher built with encrypt+MAC. It won't work with, for example, the OCB AE= AD=0A= mode, or CBC + MAC.=0A= =0A= Peter.=0A= From nobody Mon Nov 30 04: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 A8C841A00A0 for ; Mon, 30 Nov 2015 04:26:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.422 X-Spam-Level: * X-Spam-Status: No, score=1.422 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hlMYRWu37kFj for ; Mon, 30 Nov 2015 04:26:10 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::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 7EE571A008A for ; Mon, 30 Nov 2015 04:26:09 -0800 (PST) Received: by wmww144 with SMTP id w144so127051122wmw.1 for ; Mon, 30 Nov 2015 04:26:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=appelbaum-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ffa/2pQg2aEkvrAgxdK+BSwmQZJDqTpT7xIPcm+6hLg=; b=T6aYYm9dIj9JxfW5B5LIJI8lDTP0zCsigpCQ42QquGYSx6/XRbsHRm6Dlk9lv+0qL4 VnP/+Wo8To3qJQPhDVG7/e4gLVlLDw1ay1Mq2npUEhLW/bynJwrCK6TrX4tv+4MfqQNw GDNXAucWglVSJGsyT5kUEVjz7fl0nWMglsQpDy/bQCkA9w0qM3vu5trtxyQNam9vtdJz OO2MF10SNG6g0E2qRA0dKFjiH4MVW6osB8LUxAcVn7WlCfgYioolasxqaGDfQ15YwGUT GtGmpeX1bwBpWgwaTOODyCi7fKvNe0cc6nXSgLBoo/wQK8KQ4Qp+Sf57YaT54xhl56Mx CMcA== 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=ffa/2pQg2aEkvrAgxdK+BSwmQZJDqTpT7xIPcm+6hLg=; b=QMboyxTN9nBPoSlHHUpXB7/O3ZWyqjlxqOmppiHgWNy1OoPw037kCfLd6vyxrj0P07 PwmdyfmkzHY0ybAeMPNZTLE8tp8k1bzQCj5eiBL4M5ISsSkF0ytXXVR7+RLPbxeapdMR sdiY52ssGIvZEWJI38tFO7WU1sByQ77P2++YFggFpHFoJCddBInL659Qeh7O9r+q1GRI immSLNPvPmsAGoo7ZvViI7DoosDZvfhgjRnP73b1dRy559ArKJm5Ev+LeZtGF79VeMDJ 7gWkJo5jDLp7QD2MXhtVEAzECETdOVuOF+wHJw5aq03tevHMIyBfbw9cYYhNaA8r3jV8 YHXQ== X-Gm-Message-State: ALoCoQkWK16Vbz5vSofgxPzhTqh17SHZxXJunMxsesqA77dbT2TsIA7ruAn0elpg8EpquBKZnqLD MIME-Version: 1.0 X-Received: by 10.28.172.129 with SMTP id v123mr27429682wme.47.1448886367980; Mon, 30 Nov 2015 04:26:07 -0800 (PST) Received: by 10.28.173.80 with HTTP; Mon, 30 Nov 2015 04:26:07 -0800 (PST) X-Originating-IP: [193.90.12.89] In-Reply-To: <565C21EF.1060600@gmail.com> References: <56586A2F.1070703@gmail.com> <565882FE.80205@streamsec.se> <565AC9D1.700@gmail.com> <565AE180.70101@streamsec.se> <565AEB5A.9000503@gmail.com> <565C21EF.1060600@gmail.com> Date: Mon, 30 Nov 2015 12:26:07 +0000 Message-ID: From: Jacob Appelbaum To: Bryan A Ford Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 12:26:11 -0000 Dear Bryan, On 11/30/15, Bryan A Ford wrote: > Thanks Bill for the feedback. > > On 11/29/15 6:11 PM, Bill Cox wrote: >> Thanks for the detailed description of why we might want to obfuscate >> TLS record lengths. From a security point of view, the only potential >> attack vector this might create is that the attacker will know in many >> cases the plain text of the first 5 bytes. A weakness in the stream >> cipher might be more easily exploited in this case. IIUC, we feel >> pretty good about the latest AEAD ciphers, and guessing the clear text >> of many bytes in the record already is not too hard. Is that right? >> So, from my fairly uninformed point of view, this seems like a >> reasonable upgrade. > > Just a nitpicky semantic correction: my proposal doesn't "create" the > attack vector you describe (that the attacker will know the plaintext of > the 5-byte header). That weakness is already there in TLS 1.3 as > currently specified, because the TLS header is unencrypted so the > attacker will *definitely* know the 5-byte header. :) This is merely an > existing weakness that is not fixed by my proposal. That is my read as well. I think your proposal sounds pretty interesting. >> I have one concern. These same boxes that hide record lengths by >> merging and breaking up packets arbitrarily likely would deliver the >> packets not well aligned to record boundaries. Is this already the >> case? > > It's already the case that middleboxes of various kinds re-segment > (merge and break up along different boundaries) TCP streams for various > reasons, often as an unintentional side-effect of interposing on the > stream by "accepting" the TCP connection (pretending to be an endpoint) > on one of the middlebox's interfaces and opening a new outgoing > connection on the other interface, and just forwarding the traffic > between them. In fact, Performance Enhancing Proxies (PEPs) are one > class of middlebox that often do this intentionally, so they can get > better control over and fiddle with the way congestion control works > over "troublesome" types of links like high-bandwidth-delay-product > (e.g., satellite) links. > >> If these boxes currently inspect packets when breaking them up to >> split packets along record boundaries, encrypting the lengths will >> defeat this efficiency hack. We might cause an increase in network >> latency in this case. Do any of the routers out there currently use the >> record length field when splitting up packets? > > If I understand your question correctly, you're asking if encrypting TLS > record lengths might break middleboxes that currently want to track TLS > records for some reason, e.g., perhaps to re-segment the TCP stream to > correspond to TLS records (which might "fix" or "revert" the effect of > another middlebox in the path that re-segments TCP in a TLS-oblivious > fashion). I don't know of any middleboxes that do precisely this, but > it's not inconceivable that they could exist. Why would that concern anyone other than to help an attacker? If my ISP requires me to use such a box, I should use it as a proxy or configure it manually. If they use it on me without my consent, it is an attack. I want TLS to break and to do so in a way that fails closed. If another ISP, backbone ISP, or XKeyscore would have a harder job, I fail to see why we should care at all. They're the adversary, we should not give them anything. We should make their job as difficult as possible technically as well as in most other ways as well. I have no sympathy for the what-about-poor-NSAT&T's-big-networks of the world. > More generally, since basically all manner of evil/broken middleboxes do > exist, it's entirely possible that most any change to TLS's wire > encoding *could* disagree with some middleboxes. That's not specific to > the change I'm proposing; any wire-visible change could trigger unknown > middlebox badness. The only solution to this I'm aware of is empirical: > try the change, deploy it experimentally at first, and see what the pain > level is, i.e., see if we find any middleboxes that complain and if so > how prevalent they are. But since TLS 1.3 is already changing a lot of > other prominently wire-visible stuff with respect to prior versions of > TLS that might equally well break middleboxes, it's not clear that my > proposed change in particular is more likely to cause pain than any of > the other changes already made, and in general I don't think we should > let a few broken/evil middleboxes prevent meaningful evolution of the > TLS protocol. > Agreed entirely. TLS should also be able to be composed with anonymity networks in a way that we solve complementary problems, as you've said. The less a hostile Tor exit can learn about a person's TLS 1.3 flow, the better. One could even imagine a key setup over one Tor circuit and then a seemingly unrelated connection using the negotiated key over another Tor circuit. In an ideal world, we'd have two basic phases... setup/keyex/etc: which is distinguishable transfer of data/tear down: which if done correctly, should almost all look the same unless we have a full network view with reassembly. It would be nice if the biggest problem for traffic analysis was then TCP/IP related, though we're far from that point with TLS 1.3 or any other general purpose protocol. It is true that to beat traffic analysis, we need to tackle that problem directly and I very much agree with you that we still should make these positive changes. Your suggested changes will also assist others who are dealing with those problems directly. All the best, Jacob From nobody Mon Nov 30 06:27: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 23B521ACE09 for ; Mon, 30 Nov 2015 06:27:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFc-G_jqto8k for ; Mon, 30 Nov 2015 06:27:36 -0800 (PST) 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 3EE681ACE05 for ; Mon, 30 Nov 2015 06:27:36 -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 (Postfix) with ESMTPS id B01503B70B; Mon, 30 Nov 2015 14:20:44 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-114.brq.redhat.com [10.34.0.114]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tAUEKghH023207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Nov 2015 09:20:43 -0500 From: Hubert Kario To: tls@ietf.org Date: Mon, 30 Nov 2015 15:20:36 +0100 Message-ID: <2564045.EyFMgGcPZE@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.2.6-200.fc22.x86_64; KDE/4.14.14; x86_64; ; ) In-Reply-To: <565C1DD8.20305@gmail.com> References: <56586A2F.1070703@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B92EA4@uxcn10-5.UoA.auckland.ac.nz> <565C1DD8.20305@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart10427855.uAeQSjQljr"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 14:27:38 -0000 --nextPart10427855.uAeQSjQljr Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Monday 30 November 2015 10:58:48 Bryan A Ford wrote: > On 11/30/15 2:40 AM, Peter Gutmann wrote: > > Nikos Mavrogiannopoulos writes: > >> I believe your proposal is a nice example of putting the cart > >> before the horse. Before proposing something it should be clear > >> what do you want to protect from, what is the threat? > >=20 > > Exactly. If you want to thwart traffic analysis, you need to do > > something like what's done by designs like Aqua ("Towards Efficient= > > Traffic-analysis Resistant Anonymity Networks"), or ideas from any > > of the other anti-traffic- analysis work that's emerged in the past= > > decade or two. >=20 > I'm well aware of Aqua and "the other anti-traffic-analysis work > that's emerged in the past decade or two": in fact I led one of the > major recent systematic projects in that space. See for example: >=20 > =09http://dedis.cs.yale.edu/dissent/ > =09http://cacm.acm.org/magazines/2015/10/192387-seeking-anonymity-in-= an-> internet-panopticon/fulltext > > You get traffic > > analysis resistance by, for example, breaking data into fixed-lengt= h > > packets, using cover traffic, and messing with packet timings, not > > by > > encrypting TLS headers. >=20 > Packet padding and header encryption are both important, complementar= y > security measures: you get security benefits from each that you don't= > get from the other. Yes, you need padding to obtain systematic > protection from traffic analysis - when for whatever reason not all > implementations are always padding to the exact same standardized > record length, header encryption makes padded streams less trivially > distinguishable from unpadded streams, and makes streams with > different record sizes less trivially distinguishable from each > other. the header contains only one piece of information, and it is public=20 already - the amount of data transmitted* If you want to hide how much data was transmitted, you need to establis= h=20 a tunnel that transmits data constantly, at the exact same rate for the= =20 whole duration of connection. that means that you need to know a). what bandwidth the client has, b).= =20 what bandwidth the server can spare and c). how much data the user want= s=20 to get or send to the server (I really don't want to transmit 1GiB of=20= data over a 100KiB/s stream if I have a 100Mbps link...). this goes well past the TLS WG charter, if only because it requires ver= y=20 close cooperation with the application layer so while the padding mechanism should be there, we really can't describ= e=20 how it needs to be used, as it can't be made universal nor is it=20 necessary for all use cases * - sure, the record layer boundaries can tell something about the dat= a=20 being transmitted, but so can the presence of data transmission taking=20= place in the first place (think of a station sending reports only when=20= it detects something while keeping connection open the whole time) =20 > One thing that would greatly help Tor and all similar, > padded protocols is if they could "blend in" even just a little bit > better with the vast bulk of ordinary TLS-encrypted Web traffic, and > that's one of the big opportunities we're talking about here.=20 the initial message in handshake in TLS MUST stay the same thus it is=20= impossible to make it look like Tor. Not to thwart the Pervasive=20 Monitoring threat of TLA agencies. =20 > If you think it is practical for the TLS 1.3 standard to specify a > single, fixed record size that all implementations of TLS 1.3 must us= e > (i.e., explicitly freeze not only the version field but the length > field), then that would be great for traffic analysis protection and > on that basis I would support that proposal. But that frankly seems > to me likely a bit too much to ask given the diversity of TLS > implementations and use-cases. Tell me if you believe otherwise. That will just round up to a multiple of 256 bytes the data sizes=20 transmitted. Hardly an improvement over the current 16 byte blocks. =2D-=20 Regards, Hubert Kario Senior 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 --nextPart10427855.uAeQSjQljr 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 iQIcBAABCgAGBQJWXFs0AAoJEJKo0bgB0vX14TUP/RUTK9S9dcPIAIrQ42Ok6DN1 5dJkLOKZkSpEuHDCn/FoQOAizNuy2epyg+hZOmLt8SuEgTcZ/YgUDnT4CrB3e+N8 2vWNb0+JptHwQpO+D1srsS3vhnK3GXv5q6lo1woxxLGerY1pBgPCJ1RaQqTKziPp rFIE95dcfc/vlHbfEcIJU+jd+43+4E0KjleOFlyIsyiq5wWPglzkZ7yViUxLOBQ4 YCLlDxMO5+hUyJ9B/Y0AMOKVwLcXEowNWp6C483zisfaeOdJcoGNGa0HaIx97Zto bD09oCRAc4u5gKhbFMw4r1xzHH6D9es0Z6bND1lhpYuzghF8tVaTet0k4tUHh6w3 w4ixfmi5T98MC9V4+yYEh+2v0gB7kDR9n8o4uFdQRahaLakvaAfuf2we7T2sJ1nu UIOlQbju2DI3s4eGjh2QhoQXooe7+ATn1NEx3JxfQ4uMEiDVZWK7qlZGQAYjkXuJ eHGhu4SvLj8nT/B3hkddhiXLJKDS75Hrh8tpN1zoHJ5TWjStQkcJs/ogBuOyj0cC hZHjn65vyv8Qt43kEGTkBf99T/iVYxIlANS24OtzKpzf06q/By6wch2CuCUxVwm2 ghKltJ2bcWJKeuX6KagspFit7BSeU7Ybr0szpi2MBw5hXawvKmGhuYboFwch1OuS 1KFNe3MtCV2zNtxRcW4Z =SRCk -----END PGP SIGNATURE----- --nextPart10427855.uAeQSjQljr-- From nobody Mon Nov 30 08:06:59 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1B661A036C for ; Mon, 30 Nov 2015 08:03:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.212 X-Spam-Level: X-Spam-Status: No, score=-99.212 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 F3B3z1Vykqh5 for ; Mon, 30 Nov 2015 08:03:50 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 771B91A0368 for ; Mon, 30 Nov 2015 08:03:50 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 90398180013; Mon, 30 Nov 2015 08:02:12 -0800 (PST) To: dtaylor@gnutls.org, thomwu@cisco.com, nmav@gnutls.org, trevp@trevp.net, stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, sean+ietf@sn3rd.com, joe@salowey.net X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20151130160212.90398180013@rfc-editor.org> Date: Mon, 30 Nov 2015 08:02:12 -0800 (PST) Archived-At: X-Mailman-Approved-At: Mon, 30 Nov 2015 08:06:57 -0800 Cc: rick@openfortress.nl, tls@ietf.org, rfc-editor@rfc-editor.org Subject: [TLS] [Technical Errata Reported] RFC5054 (4546) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 16:03:52 -0000 The following errata report has been submitted for RFC5054, "Using the Secure Remote Password (SRP) Protocol for TLS Authentication". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5054&eid=4546 -------------------------------------- Type: Technical Reported by: Rick van Rein Section: 2.6 Original Text ------------- B = k*v + g^b % N Corrected Text -------------- B = ( k*v + g^b ) % N Notes ----- The customary binding is that + has lower priority than % and so the default reading of the expression would be B = k*v + ( g^b % N ) That is inconsistent with the existence of PAD(B) and the size of B in the test vectors, so the context hints at proper brackets, but this may still lead to implementation errors (of which I actually ran into an example). 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. -------------------------------------- RFC5054 (draft-ietf-tls-srp-14) -------------------------------------- Title : Using the Secure Remote Password (SRP) Protocol for TLS Authentication Publication Date : November 2007 Author(s) : D. Taylor, T. Wu, N. Mavrogiannopoulos, T. Perrin Category : INFORMATIONAL Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Mon Nov 30 11:21:47 2015 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC901B2B46; Mon, 30 Nov 2015 11:21:45 -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: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151130192145.21437.54465.idtracker@ietfa.amsl.com> Date: Mon, 30 Nov 2015 11:21:45 -0800 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-chacha20-poly1305-03.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 19:21:45 -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 : ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS) Authors : Adam Langley Wan-Teh Chang Nikos Mavrogiannopoulos Joachim Strombergson Simon Josefsson Filename : draft-ietf-tls-chacha20-poly1305-03.txt Pages : 7 Date : 2015-11-30 Abstract: This document describes the use of the ChaCha stream cipher and Poly1305 authenticator in the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-chacha20-poly1305/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tls-chacha20-poly1305-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-chacha20-poly1305-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 30 13:27: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 207F01B355C for ; Mon, 30 Nov 2015 13:27:31 -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 2qLb7ZRiyUUP for ; Mon, 30 Nov 2015 13:27:30 -0800 (PST) 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 DDF9C1B3530 for ; Mon, 30 Nov 2015 13:27:29 -0800 (PST) Received: by qgeb1 with SMTP id b1so130619395qge.1 for ; Mon, 30 Nov 2015 13:27:29 -0800 (PST) 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=692r2/1m1dMr9MAW1iw71wdpFfrYsqV0N/suF+S6cek=; b=ujWcuxNEiGy+DBJeWRPPH4QueLRmXP9ob/7Cgi6JDR75W7jHyD2BEWUI3Kdmmqp+vm f70V4QYHCT9iFfvTJmE6I0pFjazywV/xr1fV/9o8ZYeyDMKtwUFWEPoImeDYh/SMX2pc QzcaMffLsP7d19qohSQc8SqSvScML7qJ1ynRPiBZvoD6EF4q9jwcJkOEyZEVgfHAraiv Zm1DpL9mgzTI9H/AAmq4smrr0HKh2GvSMBxVmLpjh9oqmQ5hXRH+mrWmG6SHzjoO8W13 rNa2K63Ga8N1bwqiAIS+OAhQ+d0SO1vQwCYJHku+qtePI5LBD8w85I2hLGvahKc2e3lH 5IdA== X-Received: by 10.141.28.80 with SMTP id f77mr61464103qhe.66.1448918849123; Mon, 30 Nov 2015 13:27:29 -0800 (PST) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id i124sm9987461qhi.29.2015.11.30.13.27.28 for (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 30 Nov 2015 13:27:28 -0800 (PST) From: Dave Garrett To: tls@ietf.org Date: Mon, 30 Nov 2015 16:27:27 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201511301627.27616.davemgarrett@gmail.com> Archived-At: Subject: [TLS] bikeshed: Forward Security or Secrecy? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Nov 2015 21:27:31 -0000 Which do we like better: "Forward Security" or "Forward Secrecy"? The TLS 1.3 draft uses both interchangeably. The term is clearly in a state of flux, seeing as we've seemingly collectively agreed to drop the word "perfect" from the term, already. Personally, I prefer "security" because "secrecy" is a less used word, and to "forward secure" something is grammatically OK but to "forward secret" something is not. (e.g. the doc says 0RTT data is not "forward secure" but "forward secret" isn't really the right phrase here) Everything could be rephrased to use either, but I'd like to change all our use to just "forward secure" and stick a note somewhere on the terminology. Dave From nobody Mon Nov 30 16:14: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 100491B33D2 for ; Mon, 30 Nov 2015 16:14:17 -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] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Tq6VDBeZQUC for ; Mon, 30 Nov 2015 16:14:15 -0800 (PST) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001: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 4D3881B33CF for ; Mon, 30 Nov 2015 16:14:15 -0800 (PST) Received: by iouu10 with SMTP id u10so195722347iou.0 for ; Mon, 30 Nov 2015 16:14:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=appelbaum-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Qy5+M/b75EHhR6zNdhxNv/78JN4Bgnh0It7R2zjzASo=; b=hLNTeaeGBre6Vzze21qgYFM7w88mfoXqRUp+YZUv7FUhV2lWEd/8YcY4ByckjM6iC5 KvtNklChD3odTSN6hjRSjFdBQRU8yAaqqzvntJD523JFVLjDAJyEDcu0XTGbOkMIbFbw zMNGOYGcBHZK8yfVX4a8Clh4KcsBhT7ei9KWqwxyeXxKlAjksJ9zqYdfilcWnN1jhWtU Ih7BZRRVXYyG/MQeSyQgqzIm7r79QMsJS9OQRXHgg4TVPoCb4riKZaff7OOeHrQbjn+a CcsFQJ6l/LVnbmgv6Yllff7IJ5e1m1DdbQZYOYFodg2cSw/oYJ7CiyWO7Kdd3g7QEWW1 Ahmw== 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=Qy5+M/b75EHhR6zNdhxNv/78JN4Bgnh0It7R2zjzASo=; b=MlrlKcO+hySLEAJqY921yczHvBK8sQnVdpetiIUdUnTDR0GNwfFatPXLT1kpc0l3Qc +/xgjgqdCLtiXRVin49ZaYUXk0fDMIeOG4RjVeZLA+BTN9WoDi7/JY/zOCFzBRKbOdks 4Mmcm3jpSQs/vndFlqmuX9jAeetpygRqKKp/7yFqArVXqzpZBVVvxSbAnbpk/Dfz6mW0 d7iLJPLjTgDDvPI9PDu2i0crmnCOmqYPAdSfGJcphzQ/OvT2jxxJ3ukO/R9QdwUD9XXx gKl6sa2Ezu2qw2tgSZJJ30VNTC3UDlTtjGS6XmK6c8wUaoDbzUNaLuhon0iXvVJYicUF wQJg== X-Gm-Message-State: ALoCoQmHfgLnAG9nswkot7hjMAKEBLHokZOpiQcDCbx0D+3/cHbfrY4mOl35khbeIpRPvfXUqnLy MIME-Version: 1.0 X-Received: by 10.107.137.19 with SMTP id l19mr53999655iod.138.1448928854627; Mon, 30 Nov 2015 16:14:14 -0800 (PST) Received: by 10.79.70.71 with HTTP; Mon, 30 Nov 2015 16:14:14 -0800 (PST) X-Originating-IP: [199.87.154.251] In-Reply-To: <2564045.EyFMgGcPZE@pintsize.usersys.redhat.com> References: <56586A2F.1070703@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B92EA4@uxcn10-5.UoA.auckland.ac.nz> <565C1DD8.20305@gmail.com> <2564045.EyFMgGcPZE@pintsize.usersys.redhat.com> Date: Tue, 1 Dec 2015 00:14:14 +0000 Message-ID: From: Jacob Appelbaum To: Hubert Kario Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 00:14:17 -0000 On 11/30/15, Hubert Kario wrote: > On Monday 30 November 2015 10:58:48 Bryan A Ford wrote: >> On 11/30/15 2:40 AM, Peter Gutmann wrote: >> > Nikos Mavrogiannopoulos writes: >> >> I believe your proposal is a nice example of putting the cart >> >> before the horse. Before proposing something it should be clear >> >> what do you want to protect from, what is the threat? >> > >> > Exactly. If you want to thwart traffic analysis, you need to do >> > something like what's done by designs like Aqua ("Towards Efficient >> > Traffic-analysis Resistant Anonymity Networks"), or ideas from any >> > of the other anti-traffic- analysis work that's emerged in the past >> > decade or two. >> >> I'm well aware of Aqua and "the other anti-traffic-analysis work >> that's emerged in the past decade or two": in fact I led one of the >> major recent systematic projects in that space. See for example: >> >> http://dedis.cs.yale.edu/dissent/ >> http://cacm.acm.org/magazines/2015/10/192387-seeking-anonymity-in-an-> >> internet-panopticon/fulltext >> > You get traffic >> > analysis resistance by, for example, breaking data into fixed-length >> > packets, using cover traffic, and messing with packet timings, not >> > by >> > encrypting TLS headers. >> >> Packet padding and header encryption are both important, complementary >> security measures: you get security benefits from each that you don't >> get from the other. Yes, you need padding to obtain systematic >> protection from traffic analysis - when for whatever reason not all >> implementations are always padding to the exact same standardized >> record length, header encryption makes padded streams less trivially >> distinguishable from unpadded streams, and makes streams with >> different record sizes less trivially distinguishable from each >> other. > > the header contains only one piece of information, and it is public > already - the amount of data transmitted* I'm pretty sure TLS has a lot more data... > If you want to hide how much data was transmitted, you need to establish > a tunnel that transmits data constantly, at the exact same rate for the > whole duration of connection. > ... > that means that you need to know a). what bandwidth the client has, b). > what bandwidth the server can spare and c). how much data the user wants > to get or send to the server (I really don't want to transmit 1GiB of > data over a 100KiB/s stream if I have a 100Mbps link...). > ... > this goes well past the TLS WG charter, if only because it requires very > close cooperation with the application layer > > so while the padding mechanism should be there, we really can't describe > how it needs to be used, as it can't be made universal nor is it > necessary for all use cases > I think it should be described how it needs to be used... > * - sure, the record layer boundaries can tell something about the data > being transmitted, but so can the presence of data transmission taking > place in the first place (think of a station sending reports only when > it detects something while keeping connection open the whole time) > Yes, they tell something and that something is better removed. >> One thing that would greatly help Tor and all similar, >> padded protocols is if they could "blend in" even just a little bit >> better with the vast bulk of ordinary TLS-encrypted Web traffic, and >> that's one of the big opportunities we're talking about here. > > the initial message in handshake in TLS MUST stay the same thus it is > impossible to make it look like Tor. Not to thwart the Pervasive > Monitoring threat of TLA agencies. That Tor claim is strange and seemingly false in any case. Also, I've said it before quoting the RFC but I'll say it again: Pervasive Monitoring is an attack. >> If you think it is practical for the TLS 1.3 standard to specify a >> single, fixed record size that all implementations of TLS 1.3 must use >> (i.e., explicitly freeze not only the version field but the length >> field), then that would be great for traffic analysis protection and >> on that basis I would support that proposal. But that frankly seems >> to me likely a bit too much to ask given the diversity of TLS >> implementations and use-cases. Tell me if you believe otherwise. > > That will just round up to a multiple of 256 bytes the data sizes > transmitted. Hardly an improvement over the current 16 byte blocks. > Closer to 512 bytes is better. All the best, Jacob From nobody Mon Nov 30 16:56: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 09D521B34ED for ; Mon, 30 Nov 2015 16:56:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-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 OY5oVTtxGJtx for ; Mon, 30 Nov 2015 16:56:12 -0800 (PST) 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 1E4211B34F3 for ; Mon, 30 Nov 2015 16:56:11 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 919B1284E37; Tue, 1 Dec 2015 00:56:09 +0000 (UTC) Date: Tue, 1 Dec 2015 00:56:09 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20151201005609.GD18315@mournblade.imrryr.org> References: <56586A2F.1070703@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B8DA2A@uxcn10-5.UoA.auckland.ac.nz> <565AC278.2010904@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B92E74@uxcn10-5.UoA.auckland.ac.nz> <565C0F25.7000507@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B9331B@uxcn10-5.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B9331B@uxcn10-5.UoA.auckland.ac.nz> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? 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, 01 Dec 2015 00:56:14 -0000 On Mon, Nov 30, 2015 at 10:34:27AM +0000, Peter Gutmann wrote: > Bryan A Ford writes: > > >It would work just as well and in exactly the same way if the AEAD is > >replaced with the traditional Encrypt-then-MAC construction, for example. > > No it wouldn't, unless the encrypt part is a stream cipher. You're still > locked into using an AEAD stream cipher or the equivalent of an AEAD stream > cipher built with encrypt+MAC. It won't work with, for example, the OCB AEAD > mode, or CBC + MAC. I think we should focus on what would get TLS 1.3 to be adopted: * Reasonably implementable in libraries that support older versions alongside TLS 1.3. * Interoperable in the field with various capital-intensive middle boxen. This suggests focusing on solidifying the core protocol, and a healthy dose of skepticism around bells and whistles. If the protocol is overloaded with too many (alright even more) incompatible innovations, the net effect is likely less security due to substantially delayed deployment of the key improvements. Encrypting message lengths looks rather marginal from this perspective, and quite likely to hinder interoperability and delay both implementation and upgrades. However cool an idea this might be, this does not look to me like the right time to add this feature to TLS. At this point, TLS 1.3 is rather feature rich, and it is I think time to focus on reviewing the already agreed changes (maybe even drop some if they look inessential). Make it solid, trim the fat, get it out the door in a usable form. -- Viktor. From nobody Mon Nov 30 17:36: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 06EF71B35FE for ; Mon, 30 Nov 2015 17:36:29 -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] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMKWexk8wypv for ; Mon, 30 Nov 2015 17:36:27 -0800 (PST) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001: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 C787C1B35F9 for ; Mon, 30 Nov 2015 17:36:27 -0800 (PST) Received: by ioir85 with SMTP id r85so194480779ioi.1 for ; Mon, 30 Nov 2015 17:36:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=appelbaum-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=zLveUSTRX6u8JQvwWyT96NHuRO7xvK0P6IXEbdg0XSw=; b=XcO2E/iCBmKlLtPsd6fWUphvd66Pc/vHttGguVDS/1ouWGRrqMFLP/c5FlITUqJS9L BZVwU0uJZrh16/nRwxxD+6tb0fRB/9h6PIbXPg3cjjDpGodVoZsPvxLSTudbCbz1TNFI KfMMjU+9h02Jne6aBFNygDgxMmceb5DSIGtW/8JIlyMjKsSjhFhHBM+mPCOF/e1zm0Co Wdx6wQsVq6VhkjBPxVvTDOlzwAD0OL869MHj4vvhmYimzMK3co6nMauvW538nGEKTpci hlnYpzvFu115wTgdugbwEuDzJ0QICyxS+cS6RnCBrap0oFSS6+IpY9UHD3ceimMT2Do2 AjPQ== 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=zLveUSTRX6u8JQvwWyT96NHuRO7xvK0P6IXEbdg0XSw=; b=XAJxWWLKfo3Tuc5/JhdBoVHZrOpsYrXCQT4d4FgynXRkymQvBrbrt9bD9ee1rXnfst Z23RjTcUgahA17lqtEUG6wRnRg1JCRFTpwyg38kvlapi2+h+ubEI+t9LbJhQmbPK3bMc 5z16NLfIAdVnY/9zJlTkUx+Fed+PN5lK3g8K8QecSM/x6PSyz64h9LnbVssIbyhYDj18 o2JkQNpYyfGb3GSh3FI2NIXY7TPnoXqnockp6Zh4g27t/az6NzdljCKlPFgDZs1TVl3h hpzClv5L+psTljxv70ZlLoL3ll71qBDSu9Tb1U4kdPDhx6P9KdVWQkSCivB1UL9mzMui zTyg== X-Gm-Message-State: ALoCoQmLJZajq+zm864RXIYFPdTFz3mQxVoBf/C75bfLLIRfz/C3RRetnE/K9P8/mk8q3l1SP/Zd MIME-Version: 1.0 X-Received: by 10.107.137.19 with SMTP id l19mr54263852iod.138.1448933787043; Mon, 30 Nov 2015 17:36:27 -0800 (PST) Received: by 10.79.70.71 with HTTP; Mon, 30 Nov 2015 17:36:26 -0800 (PST) X-Originating-IP: [192.42.116.16] In-Reply-To: <20151201005609.GD18315@mournblade.imrryr.org> References: <56586A2F.1070703@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B8DA2A@uxcn10-5.UoA.auckland.ac.nz> <565AC278.2010904@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B92E74@uxcn10-5.UoA.auckland.ac.nz> <565C0F25.7000507@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B9331B@uxcn10-5.UoA.auckland.ac.nz> <20151201005609.GD18315@mournblade.imrryr.org> Date: Tue, 1 Dec 2015 01:36:26 +0000 Message-ID: From: Jacob Appelbaum To: tls@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 01:36:29 -0000 On 12/1/15, Viktor Dukhovni wrote: > On Mon, Nov 30, 2015 at 10:34:27AM +0000, Peter Gutmann wrote: > >> Bryan A Ford writes: >> >> >It would work just as well and in exactly the same way if the AEAD is >> >replaced with the traditional Encrypt-then-MAC construction, for >> > example. >> >> No it wouldn't, unless the encrypt part is a stream cipher. You're still >> locked into using an AEAD stream cipher or the equivalent of an AEAD >> stream >> cipher built with encrypt+MAC. It won't work with, for example, the OCB >> AEAD >> mode, or CBC + MAC. > > I think we should focus on what would get TLS 1.3 to be adopted: > > * Reasonably implementable in libraries that support older > versions alongside TLS 1.3. > That doesn't change with Bryan's suggestion, I think. > * Interoperable in the field with various capital-intensive > middle boxen. Which would those be? And what is the definition of capital-intensive for those watching on the sidelines? > > This suggests focusing on solidifying the core protocol, and a > healthy dose of skepticism around bells and whistles. If the > protocol is overloaded with too many (alright even more) incompatible > innovations, the net effect is likely less security due to > substantially delayed deployment of the key improvements. This seems borderline absurd. The TLS protocol is doing a major version revision. > Encrypting message lengths looks rather marginal from this perspective, > and quite likely to hinder interoperability and delay both > implementation and upgrades. However cool an idea this might be, > this does not look to me like the right time to add this feature > to TLS. I don't think it will hinder interoperability and not one person has even named a single device that would have issues with it. I think the only thing that comes close is when I've named a classified US government surveillance program (XKeyscore) that would probably have trouble with it. We should add Bryan's feature and not pander to non-specific concerns about middleboxes that should be considered as adversaries. > > At this point, TLS 1.3 is rather feature rich, and it is I think > time to focus on reviewing the already agreed changes (maybe even > drop some if they look inessential). Make it solid, trim the fat, > get it out the door in a usable form. That is part of what is happening in Bryan's suggestion. He found a reasonably practical way to encrypt record headers. His suggestion will make TLS more secure. His suggestion includes a review of a part of the previous state of TLS 1.3 with a proposed improvement. No one is debating it on the cryptographic merits which is surprising. All the best, Jacob From nobody Mon Nov 30 18:07: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 C3A181B36BD for ; Mon, 30 Nov 2015 18:07:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.312 X-Spam-Level: * X-Spam-Status: No, score=1.312 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 qcLRx-lNWJaJ for ; Mon, 30 Nov 2015 18:07:20 -0800 (PST) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001: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 6BB731B36BA for ; Mon, 30 Nov 2015 18:07:20 -0800 (PST) Received: by iofh3 with SMTP id h3so196149240iof.3 for ; Mon, 30 Nov 2015 18:07:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=JiiWtts7Ixkk/WB4NH7yAaWAWV5hFNKB+ZDc/hsFE+0=; b=hWqgjmpVqkB7w6Xar8SW2jSsmPkHS+YZIhrqnKO98C420O6ZZisPzk6mCF7DKLu5yB 8eCGysJgEFxdvyWP+DeKMXsg0AZX++TTVNqGeYfVM5jwh7kLvdVGn2rNMXgOmjYz6rXH CXcMJEhz9/z2W3Ej11hDhcF9e6UF9syZKfdFARll6pihMDLirxdhCy3zgTYG2vFY7jrn KKu2WHAcumjwLd1KriDUCX0WfyEnNAzFx0FaVt5BGODL3C/WcI8kAK4nP2NOrj0h9AIE qwE1QveXsVsInLIuY/XM15WCxIpf6jj9MIxiAEWyndTge55HrJXmebKMtoh3ZJUC02lD tE1Q== 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=JiiWtts7Ixkk/WB4NH7yAaWAWV5hFNKB+ZDc/hsFE+0=; b=C+RrhlbFTyYaA0iK9hwIyE8Wp4XcPLL39BUPMNzO12rvJpZkR5Y10z3rBLNTmwsZX9 k0rqjzi9JFGKSepVWmAepSjLbSuB6pvvcEtNObikalwNc+SuP6Kkcu/PFswZvkm7ieSH uiDAHMPKHUJVYBmFX1AeJd6/Na9JzZxWdi4l1JBDJfo0eoQ3fDAhaPTJggGFiua4n+kV PqSMRqMEoiUP1wVXul+27mEuQmgaq0HnIcvTFPMpgVwPMeZxYtMxMHBnaneUrUCYzIda kX6kiHnHweE3xOt0PTCfbZk9SsgITwVgMcII4FVlLJzUMKsmzmuh2TrRpj7JjKt2gDQj jnVw== X-Gm-Message-State: ALoCoQl3WC6aZjobUJuPxHCmpJ9jOD7qihyKS72T3r+S638Z/OJaagyZEwjVe4DlEQP/DTqOUKrH MIME-Version: 1.0 X-Received: by 10.107.152.133 with SMTP id a127mr63394122ioe.60.1448935639746; Mon, 30 Nov 2015 18:07:19 -0800 (PST) Received: by 10.107.173.15 with HTTP; Mon, 30 Nov 2015 18:07:19 -0800 (PST) Date: Mon, 30 Nov 2015 18:07:19 -0800 Message-ID: From: Bill Cox To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a1140e69e1c52970525cc9e98 Archived-At: Subject: [TLS] Dumb thoughts for hardware backed keys for AEAD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 02:07:22 -0000 --001a1140e69e1c52970525cc9e98 Content-Type: text/plain; charset=UTF-8 I don't think even I agree with this idea, but I'll put it out there anyway. We're seeing some new secure computing modes in ARM and Intel processors. Arm has TEE, and Intel has SGX. Both modes basically run at the same speed as the CPU... in theory. There are potential benefits to securing the read/write session keys in these modes. For example, if malware is doing evil things over your connections, when you remove the malware or close your laptop, the encryption keys are out of reach, and the connections go dead. Otherwise, malware might export the keys where they could be used to resume a session, for example, enabling an attacker to continue doing evil. This is possible today over TLS 1.2, even when using Client Certificates. However, there are overhead costs for moving data in/out of these execution zones, and overhead when switching back and forth. Execution speed is a little slower in these modes for various reasons. For maximum speed, I might want a separate HMAC/HKDF key besides the read/write keys. That way, I keep just the HMAC/HKDF key in a secure execution zone, and only have to do one small operation with it per AEAD call per TLS record. This is just a dumb efficiency hack. I hate leaving either speed or security on the table if I can have both :) However, complexity harms security, so even I don't really think this is a good idea. Is there anyone who feels even more strongly about speed than me? Bill --001a1140e69e1c52970525cc9e98 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I don't think even I agree with this idea, but I'l= l put it out there anyway.

We're seeing some new sec= ure computing modes in ARM and Intel processors.=C2=A0 Arm has TEE, and Int= el has SGX.=C2=A0 Both modes basically run at the same speed as the CPU... = in theory.

There are potential benefits to securin= g the read/write session keys in these modes.=C2=A0 For example, if malware= is doing evil things over your connections, when you remove the malware or= close your laptop, the encryption keys are out of reach, and the connectio= ns go dead.=C2=A0 Otherwise, malware might export the keys where they could= be used to resume a session, for example, enabling an attacker to continue= doing evil.=C2=A0 This is possible today over TLS 1.2, even when using Cli= ent Certificates.

However, there are overhead cost= s for moving data in/out of these execution zones, and overhead when switch= ing back and forth.=C2=A0 Execution speed is a little slower in these modes= for various reasons.=C2=A0 For maximum speed, I might want a separate HMAC= /HKDF key besides the read/write keys.=C2=A0 That way, I keep just the HMAC= /HKDF key in a secure execution zone, and only have to do one small operati= on with it per AEAD call per TLS record.

This is j= ust a dumb efficiency hack.=C2=A0 I hate leaving either speed or security o= n the table if I can have both :) =C2=A0However, complexity harms security,= so even I don't really think this is a good idea.=C2=A0 Is there anyon= e who feels even more strongly about speed than me?

Bill
--001a1140e69e1c52970525cc9e98-- From nobody Mon Nov 30 18:57:35 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3AE11B3847 for ; Mon, 30 Nov 2015 18:57:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_22=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 pFPC32Jd4oD5 for ; Mon, 30 Nov 2015 18:57:33 -0800 (PST) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e: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 2AC661B3844 for ; Mon, 30 Nov 2015 18:57:33 -0800 (PST) Received: by padhx2 with SMTP id hx2so205480967pad.1 for ; Mon, 30 Nov 2015 18:57:32 -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 :content-transfer-encoding:message-id:references:to; bh=bi7HM3qfCnIA34+Zm2mzRw/yKllg++OSDmisTA0d0fk=; b=av4s8ZKay66yy7I2CxFr1sGJ1n5+sU6/Xmg3IOOnpplX2H3YpbgufCWs1/yZ9HKnaP dlHl6XdcnApog1WIhRRk5uqdWnKRBINiMCQrmuJWvPy4J7U2xODcU/jk2MHxAav2T6AU bf+tS1N+oIfiSudgogSKkMRxgkTGG0H8HrpZt7KfRyI+W03CbRfAnxa0amdYNMJB9cmi LeYUXsigFctZXhrMBsfIbK9exb1ERGpy9aQN4G8N6k7OX/RcmcIyk88IxkIHNTodnVrF ENJrJQtE/k7ePWYHDXGIYXVTR5PBunsXMefPPKHW8kDISKiPg2c1mIb1F0qea+s/wCS+ a27A== X-Received: by 10.98.67.68 with SMTP id q65mr75739231pfa.63.1448938652827; Mon, 30 Nov 2015 18:57:32 -0800 (PST) Received: from [10.0.1.7] (c-50-136-214-180.hsd1.ca.comcast.net. [50.136.214.180]) by smtp.gmail.com with ESMTPSA id 1sm53957759pfo.72.2015.11.30.18.57.31 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 Nov 2015 18:57:31 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Fabrice Gautier X-Mailer: iPhone Mail (13A340) In-Reply-To: <56586A2F.1070703@gmail.com> Date: Mon, 30 Nov 2015 19:02:05 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56586A2F.1070703@gmail.com> To: Bryan A Ford Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 02:57:34 -0000 1) What would be the implications of this for DTLS? (Knowing that one differ= ence between TLS and DTLS is the record header) 2) In some implementations the record framing/parsing and encryption/decrypt= ion are down at different layers. Would this proposal make this type of impl= ementation impossible?=20 -- Fabrice > On Nov 27, 2015, at 06:35, Bryan A Ford wrote: >=20 > The idea of encrypting TLS record headers has come up before, the most > important purpose being to hide record lengths and boundaries and make > fingerprinting and traffic analysis harder. I had convinced myself that > goal this would be "too hard" to accomplish in TLS 1.3, but after > further thought I'm not so sure. So I would like to request comment on > one approach that strikes me as a practical and requires only a rather > minor change to the current spec. >=20 > The quick summary: >=20 > * To encrypt a record, we first AEAD-encrypt the record's payload, > protecting the header fields via the additional_data, exactly as > currently specified. But then we XOR-encrypt the 5-byte TLS header just > before transmission, using a (separate) stream cipher indexed by a nonce > that depends on record sequence number and *_write_iv, in exactly the > same way the AEAD is already nonce-indexed. >=20 > * To decrypt a record, we simply do the reverse: first use the stream > cipher with the appropriate nonce to XOR-decrypt the 5-byte TLS header, > then sanity-check it as usual to determine its length, read the rest of > the record, and submit it to AEAD for decryption and full integrity > checking as before. >=20 > That's it, in a nutshell. Two likely concerns immediately arise, > discussed below, but feel free to TL;DR the rest if you don't share > these concerns. >=20 > --- >=20 > Concern #1: What if an active attacker messes with the TLS header, > especially the length field, since stream ciphers don't protect > integrity? The simple answer is that *exactly* the same thing happens > as now: the AEAD decryption attempt fails, because the > (stream-decrypted) header is AEAD-protected as additional_data. Nothing > is gained or lost. >=20 > SSH, which did something like this, ran into trouble with attackers > being able to twiddle the record length field to make the record length > look big, causing the receiver to try to receive a very large record, > and hence appear to the user to hang, instead of immediately detecting > the modification and terminating the connection. But there are three > mitigating factors here: (1) TLS is not usually used for interactive > terminal traffic like SSH is; (2) TLS's 2-byte record length field > imposes a pretty reasonable upper-bound on the maximum size an attacker > could maliciously make a record appear to be; and (3) if this risk of > length-twiddling is at all a problem in this proposed encrypted-header > protocol, then it's already a problem for the current TLS 1.3 spec > without encrypted headers, because active attackers can twiddle the bits > of a cleartext length field just as easily (and even be *certain* they > are making the length appear large!). So I can't see any way this > length-twiddling vulnerability becomes any worse, and maybe it gets a > bit better (because the attacker can no longer be entirely certain > whether he's setting a 1 bit to 0 or a 0 bit to 1). >=20 > --- >=20 > Concern #2: Do we want to have to go to the trouble of adding a stream > cipher to every TLS 1.3-compatible ciphersuite? Answer: maybe not, but > we don't necessarily need to. We could instead just specify a generic > method of using the ciphersuite's main AEAD as a stream cipher for > header encryption/decryption purposes. >=20 > The conceptually simplest approach I can think of: In the specification > of how AEAD nonces are generated (section 5.2.2 of > draft-ietf-tls-tls13-07), reserve the least-significant bit of the > record sequence number, so that sequence numbers increment by 2 rather > than 1 each record. Thus, we get two unique nonces per record from the > same set of symmetric keys. We first use the nonce with a '0' > least-significant bit to perform the regular AEAD-encryption of the > record with the header info as additional_data. >=20 > Then for the same record we use the nonce with a '1' least-significant > to AEAD-encrypt a sequence of five zero bytes ("\0\0\0\0\0"), and use > the first five bytes of result as the cipherstream to XOR the 5-byte TLS > header with before transmitting. The AEAD will of course uselessly > append some kind of authenticator to this ciphertext that we won't end > up using, but that's OK. The receiver will just use AEAD-encrypt > (again) on the same five-zero-byte message to reproduce the 5 > cipherstream bytes with which to decrypt the TLS header. Thus, senders > perform two AEAD-encrypts per record, and receivers do one AEAD-encrypt > and one AEAD-decrypt per record. >=20 > This approach seems pretty conceptually clean and simple, but has the > performance downside that we always need to invoke the AEAD twice per > record rather than once, which might be (a bit) costly especially when > records are small. So a simple refinement is to amortize this cost > across records: e.g., once every 256 records (every sequence number > ending in 0x00) we AEAD-encrypt a sequence of 5*256=3D1280 zero bytes, and= > the result in 5-byte chunks as the cipherstream with which to encrypt > and decrypt 256 consecutive TLS record headers. Thus, we're only adding > one additional AEAD-encryption of a "normal-packet-sized" 1280-byte blob > once every 256 records, which seems likely to be a pretty > inconsequential performance cost. >=20 > --- >=20 > Comments? >=20 > Thanks > Bryan >=20 From nobody Mon Nov 30 19:07: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 39FB81B3872 for ; Mon, 30 Nov 2015 19:07:33 -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, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MvcRVEVRRLJw for ; Mon, 30 Nov 2015 19:07:31 -0800 (PST) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A31881B386D for ; Mon, 30 Nov 2015 19:07:31 -0800 (PST) Received: by ykba77 with SMTP id a77so209289718ykb.2 for ; Mon, 30 Nov 2015 19:07:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=X7XzTMGBEpHGF47hIKdwAMM3v8Dsql2c2ewgPC+/F34=; b=GtfJt7XQ+9tH6d06Ofgcj/kprxA/HgpKveUUCH/S8eaiiGl3aQGa35kUMggg9ZiOva IqfBhpAHppkmQtw/3aIJVStLX1JzB09HjPj22PdyRAkVonnpODaXV12hxl0IrsZjwhFG uXtioi+RfTILy4lD68iMJu5Nh1J4WzJidA8d2IBTjToUI8vx/i00Q96gHt/YptsI0ph6 THOY60H/ZP300yW8n0QxW7HDIU1C+oBj8Nnb0n+g4yRlhFw7IipAGTd2J/Z1GK2RsPOI Jdt1UYWmUZd4J+1Ut3YVM/9pFQrEBnhTHA6rek5sof4q/moXjK8+V/3qvC2LU7sWp47J A7aw== 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=X7XzTMGBEpHGF47hIKdwAMM3v8Dsql2c2ewgPC+/F34=; b=fW+UrJ/uLnqTVSfyCd7OnYDkA72BoSCj2l5Cle+EulqAnIaMhApVburzTSNZjSWWOh AClIQWYuPY8VPy6WCxxLJLbPR8tprN4z1I02Js0BqGHGKlBGl8HooxT76mOmPezYVFQj NdcbDqIoo+TeVQ0FUcCOXrNt9nGiaFu92suebDGHNpJXKdqhld4UssVzgnB/gxHZS79r DthCdztWEUG23oVe5/wy6xfxBGTb7KgdTfpBqog6i7c6+yKjWOQgbghm5JZO8rt/U4Oi D9tkvn5lJxQmx5M63kcgdTNJx8jSdMQlDUPWmVByohOiWNseJwmG+W0f6EH7yCPlZmqN QTZQ== X-Gm-Message-State: ALoCoQlxUXBP75h7GSDy1lH5E8e4JdmwIB9YR7BpsY/+ABpdYO8LkvLb7scl5771pGvU4IkjZyDI X-Received: by 10.13.197.194 with SMTP id h185mr56491215ywd.12.1448939250994; Mon, 30 Nov 2015 19:07:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Mon, 30 Nov 2015 19:06:51 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Mon, 30 Nov 2015 19:06:51 -0800 Message-ID: To: Bill Cox Content-Type: multipart/alternative; boundary=001a114edd4a5b83910525cd755f Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Dumb thoughts for hardware backed keys for AEAD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 03:07:33 -0000 --001a114edd4a5b83910525cd755f Content-Type: text/plain; charset=UTF-8 Hi Bill, I am sorry, but I do not understand what you are proposing. Do you think you could try restating the computation you have in mind, perhaps by providing an equation that explains the construct? Thanks, -Ekr On Mon, Nov 30, 2015 at 6:07 PM, Bill Cox wrote: > I don't think even I agree with this idea, but I'll put it out there > anyway. > > We're seeing some new secure computing modes in ARM and Intel processors. > Arm has TEE, and Intel has SGX. Both modes basically run at the same speed > as the CPU... in theory. > > There are potential benefits to securing the read/write session keys in > these modes. For example, if malware is doing evil things over your > connections, when you remove the malware or close your laptop, the > encryption keys are out of reach, and the connections go dead. Otherwise, > malware might export the keys where they could be used to resume a session, > for example, enabling an attacker to continue doing evil. This is possible > today over TLS 1.2, even when using Client Certificates. > > However, there are overhead costs for moving data in/out of these > execution zones, and overhead when switching back and forth. Execution > speed is a little slower in these modes for various reasons. For maximum > speed, I might want a separate HMAC/HKDF key besides the read/write keys. > That way, I keep just the HMAC/HKDF key in a secure execution zone, and > only have to do one small operation with it per AEAD call per TLS record. > > This is just a dumb efficiency hack. I hate leaving either speed or > security on the table if I can have both :) However, complexity harms > security, so even I don't really think this is a good idea. Is there > anyone who feels even more strongly about speed than me? > > Bill > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a114edd4a5b83910525cd755f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Bill,

I am sorry, but I do not under= stand what you are proposing. Do you think
you could try restatin= g the computation you have in mind, perhaps by
providing an equat= ion that explains the construct?

Thanks,
-Ekr


On Mon, Nov 30, 2015 at 6:07 PM, Bill Cox <waywardgeek@google.com= > wrote:
I= don't think even I agree with this idea, but I'll put it out there= anyway.

We're seeing some new secure computing mode= s in ARM and Intel processors.=C2=A0 Arm has TEE, and Intel has SGX.=C2=A0 = Both modes basically run at the same speed as the CPU... in theory.

There are potential benefits to securing the read/write s= ession keys in these modes.=C2=A0 For example, if malware is doing evil thi= ngs over your connections, when you remove the malware or close your laptop= , the encryption keys are out of reach, and the connections go dead.=C2=A0 = Otherwise, malware might export the keys where they could be used to resume= a session, for example, enabling an attacker to continue doing evil.=C2=A0= This is possible today over TLS 1.2, even when using Client Certificates.<= /div>

However, there are overhead costs for moving data = in/out of these execution zones, and overhead when switching back and forth= .=C2=A0 Execution speed is a little slower in these modes for various reaso= ns.=C2=A0 For maximum speed, I might want a separate HMAC/HKDF key besides = the read/write keys.=C2=A0 That way, I keep just the HMAC/HKDF key in a sec= ure execution zone, and only have to do one small operation with it per AEA= D call per TLS record.

This is just a dumb efficie= ncy hack.=C2=A0 I hate leaving either speed or security on the table if I c= an have both :) =C2=A0However, complexity harms security, so even I don'= ;t really think this is a good idea.=C2=A0 Is there anyone who feels even m= ore strongly about speed than me?

Bill

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


--001a114edd4a5b83910525cd755f-- From nobody Mon Nov 30 19:11: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 A836D1B387D for ; Mon, 30 Nov 2015 19:11:19 -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 rKwXsGvz5uNc for ; Mon, 30 Nov 2015 19:11:18 -0800 (PST) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 121DE1B3878 for ; Mon, 30 Nov 2015 19:11:18 -0800 (PST) Received: by iofh3 with SMTP id h3so197466495iof.3 for ; Mon, 30 Nov 2015 19:11:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=wox6qZltn2I1GsYg/RZ8E/ArxcEhu5b/xjezJ7SK2QQ=; b=hyW9Re6ZEs0YgMhoERlHx28EOMvl4zXuPqMKtLAshD/28HTUY/DtKYDMynWOgtNccB XMFrf7vzf0rKA14me4uH73rAzv8+W7MrzbEltR995x/16j/1hBHKI218cj3NYV4MaitR FA9oTOQQCc+z8ihQhEE4hfG3ws6CgAG83t5CX/XES7g3zd3jlcWOUlRKhoRPmb2xIr3m iG+a+xMaWb1papvtedGM4Eeg53889NwesbcazpHUjNV67u2hZkWCW239oB+NuhWslt2P AV5Oz9QZ1CqhE05wNoFpdDkQzSUzXVvt/Xqr2cgy8QMBfQmswGjHNAGad6PBaNNEdtDF fCgA== X-Received: by 10.107.30.75 with SMTP id e72mr61162219ioe.5.1448939477557; Mon, 30 Nov 2015 19:11:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.39.131 with HTTP; Mon, 30 Nov 2015 19:10:58 -0800 (PST) In-Reply-To: References: From: Tony Arcieri Date: Mon, 30 Nov 2015 20:10:58 -0700 Message-ID: To: Bill Cox Content-Type: multipart/alternative; boundary=001a1141977edc669f0525cd82cc Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Dumb thoughts for hardware backed keys for AEAD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 03:11:19 -0000 --001a1141977edc669f0525cd82cc Content-Type: text/plain; charset=UTF-8 On Mon, Nov 30, 2015 at 7:07 PM, Bill Cox wrote: > However, there are overhead costs for moving data in/out of these > execution zones, and overhead when switching back and forth. Execution > speed is a little slower in these modes for various reasons. For maximum > speed, I might want a separate HMAC/HKDF key besides the read/write keys. > That way, I keep just the HMAC/HKDF key in a secure execution zone, and > only have to do one small operation with it per AEAD call per TLS record. > Have you measured the overhead of performing just the private key operations of TLS using a key stored in an SGX enclave versus the same operations outside an SGX enclave? I'd be curious what the actual performance impact is. -- Tony Arcieri --001a1141977edc669f0525cd82cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Nov 30, 2015 at 7:07 PM, Bill Cox <waywardgeek@google.com> wrote:
However, there are overhead costs for= moving data in/out of these execution zones, and overhead when switching b= ack and forth.=C2=A0 Execution speed is a little slower in these modes for = various reasons.=C2=A0 For maximum speed, I might want a separate HMAC/HKDF= key besides the read/write keys.=C2=A0 That way, I keep just the HMAC/HKDF= key in a secure execution zone, and only have to do one small operation wi= th it per AEAD call per TLS record.

=
Have you measured the overhead of performing just the private key oper= ations of TLS using a key stored in an SGX enclave versus the same operatio= ns outside an SGX enclave? I'd be curious what the actual performance i= mpact is.

--
T= ony Arcieri
--001a1141977edc669f0525cd82cc-- From nobody Mon Nov 30 19:17: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 9F5EE1B3898 for ; Mon, 30 Nov 2015 19:17:38 -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 Dkt2iNxWJxo0 for ; Mon, 30 Nov 2015 19:17:37 -0800 (PST) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9024C1B3894 for ; Mon, 30 Nov 2015 19:17:37 -0800 (PST) Received: by iofh3 with SMTP id h3so197588981iof.3 for ; Mon, 30 Nov 2015 19:17:37 -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=guc7cih7aIJBzYoV2h10YzQTFOdhblkmbu85+v4nEgU=; b=YPChZD2g3Z674/mJBODNMNYXVmq+t7xmm/uqVctw4xDnklGSYmOQfkQLioJLYyrOrg iesvLa0TDrbX0Mz1zKn8bLhoAvQJFJ/xs4EWNgVNZfZAT5Qe6JD9WVT+X0nGcCDvEuyT TPCdZ9n2NesH6X7IOfSGLq4cygzqtDGB3fGzGzCR7a2J00960vd9Tp+O+zhLS49irHQ4 ymYENh7V2bfw95GhxIjhp9nAUSWHSXucrHGPRtW85iQ+xajHoi51qwAW790ACgJhDkM0 xRfCtyKBz3331YftUmd7/ip4zFjsnNbD9JYjqYYXMh+rQt9yoO0HoB4zuiiJNb4wMtXm RM3w== 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=guc7cih7aIJBzYoV2h10YzQTFOdhblkmbu85+v4nEgU=; b=D9gw77V+hDRvSj57cJKxiDYuZZjIXC+HyL1u/usFQ/Ta1sDg2eCX+hOSPnvHyCwk4H 9Pmd261eLdEI0eHyWt4hb8euCPtaTsXIPuKuglHJyNmfXa86f+j2HXfo96x4fncn5jCU Pv+j1ef5+Cbthk4Blx7/w75wLtT1bBBeVfO6dDYAB0BhwKN7KRgs8kVieNLskc8FkGO3 LyblD9yye9IzEG0ErSS0+Gh8GpQwdbzJk8pPdvaPQypAuyAJqQKhAiNHHeiA1MPxRhv9 ikFqmwmU53N1Aa3ku8stUdazfDD6fwLZD/SCepi2738D66erJEqgvWAms1NiT6iAwErz o+3Q== X-Gm-Message-State: ALoCoQmqhoWA1tc5CuZdVItr78pPx1/FNpPWZpzkmW/NYO6IFHGCgNmez4G0ZpSW2DCM4p8Lcw1t MIME-Version: 1.0 X-Received: by 10.107.25.81 with SMTP id 78mr66750231ioz.127.1448939856906; Mon, 30 Nov 2015 19:17:36 -0800 (PST) Received: by 10.107.173.15 with HTTP; Mon, 30 Nov 2015 19:17:36 -0800 (PST) In-Reply-To: References: Date: Mon, 30 Nov 2015 19:17:36 -0800 Message-ID: From: Bill Cox To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a113ff00a79212c0525cd996d Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Dumb thoughts for hardware backed keys for AEAD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 03:17:38 -0000 --001a113ff00a79212c0525cd996d Content-Type: text/plain; charset=UTF-8 On Mon, Nov 30, 2015 at 7:06 PM, Eric Rescorla wrote: > Hi Bill, > > I am sorry, but I do not understand what you are proposing. Do you think > you could try restating the computation you have in mind, perhaps by > providing an equation that explains the construct? > Sure. I'll stick to HMAC, which is more widely understood. We do encrypt-them-mac using the write key. The inner SHA-256 consumes the entire ciphertext, and at the end, the outer SHA-256 is applied. This hack would use a different key for the outer SHA-256. This way, it is only used to hash a single block. Quite a hack, right :) Bill --001a113ff00a79212c0525cd996d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Nov 30, 2015 at 7:06 PM, Eric Rescorla <ekr@rtfm.com> wrote:<= br>
Hi Bill,

<= div>I am sorry, but I do not understand what you are proposing. Do you thin= k
you could try restating the computation you have in mind, perha= ps by
providing an equation that explains the construct?

Sure.=C2=A0 I'll stick to HMAC, whi= ch is more widely understood.=C2=A0 We do encrypt-them-mac using the write = key.=C2=A0 The inner SHA-256 consumes the entire ciphertext, and at the end= , the outer SHA-256 is applied.

This hack would us= e a different key for the outer SHA-256.=C2=A0 This way, it is only used to= hash a single block.

Quite a hack, right :)
=

Bill=C2=A0
--001a113ff00a79212c0525cd996d-- From nobody Mon Nov 30 19:54: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 5797A1A1B2E for ; Mon, 30 Nov 2015 19:54:39 -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, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7EFL37HaexET for ; Mon, 30 Nov 2015 19:54:38 -0800 (PST) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 277DB1A1B2D for ; Mon, 30 Nov 2015 19:54:38 -0800 (PST) Received: by ykdr82 with SMTP id r82so209935580ykd.3 for ; Mon, 30 Nov 2015 19:54:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Qjhz2jIaCaWu3mtNHEiS5jItXWtaCZCeoHwsbbEDKt8=; b=RhaXNKtAF+1WonXH8A4gGmwkth8GVRVxlh297k1r7D7c4HcDnYBsOeqx7rU8bwhWS0 kBqnYU+BFmMgrm4+BAyTeRAr376P+qk+bkziWHarOoX2wQIMuyDGBQ3WJALRhf1N55Xd kisaLPNM9vMGa6Mcck0AFLd+HwYJur5OsUQzhHgM+yktNv7t546q7+zL16OGYWgXuec2 DJtJQ3vViWRaNP9i/R0s/FY1oaaslvkxKPkw6BzpQB4UwlhB5zQQrVtPfz0JTkj8bgQX 9VShr3Ie98DDydDLoKrlhmmF0GfOsDQydy8H7MzTDouUCaFqvEObl2Cd2B4x3WjVDORN 3XVw== 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=Qjhz2jIaCaWu3mtNHEiS5jItXWtaCZCeoHwsbbEDKt8=; b=LCkAAh8ImBf+nVGXa07SFyKXy1x+4I3r1GJTCDhvAADK9kVoI8vKIa0PWnU0G2RYut EUS/nXbVWVHApkfeuDl3d9SNtHCVh3sN5v05WG1pgGY3uhxPZIB365F4UBLzrjbQRFvX MVTTtHYnypLZU1+jQQK/GDtWQmwHHfkXbwnxi1pWb7WUdqPMUIOnDQHQYHwcEQJ28Xdm 4tJzVXLhuIC3gyU9J2moID1qyjfaAdZYPW0sH/AbUeHpO0kUnoc7TNcWWjVORPoNmCAm DDG28pCTRSVqKqLls0pAiJhDnSPyR7OsSCqcyyuB9k9aLL6e1abHc3DgqaCVtdoeC+hQ Yq1A== X-Gm-Message-State: ALoCoQkClexkUoPhdX+Q+7si5ibdcTMRMgxSKX43TmJVnDytWrEf85gcj6mwkumaktEjap+tBb5D X-Received: by 10.129.46.84 with SMTP id u81mr20197811ywu.129.1448942077458; Mon, 30 Nov 2015 19:54:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Mon, 30 Nov 2015 19:53:58 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Mon, 30 Nov 2015 19:53:58 -0800 Message-ID: To: Bill Cox Content-Type: multipart/alternative; boundary=001a11409380d3e8bd0525ce1dff Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Dumb thoughts for hardware backed keys for AEAD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 03:54:39 -0000 --001a11409380d3e8bd0525ce1dff Content-Type: text/plain; charset=UTF-8 Ah, I see what you mean. Thanks for explaining. So, if I understand correctly, your threat model is that you want to prevent an attacker who obtains the traffic keys from injecting new traffic during the plausible lifetime of the connection (once close_notify has been exchanged, the traffic keys are useless). Whether this is possible or not with a given AEAD transform seems to depend on the transform. FWIW, in the specific case of HMAC, because the key \xor pad fills an entire digest block, you might imagine storing the state of the outer compression function after the first block in the hardware module. I am not aware of any analysis that shows that this is safe and it very likely is not as strong as having the entire HMAC key in the module, but it might (or might not) be better than nothing. -Ekr On Mon, Nov 30, 2015 at 7:17 PM, Bill Cox wrote: > On Mon, Nov 30, 2015 at 7:06 PM, Eric Rescorla wrote: > >> Hi Bill, >> >> I am sorry, but I do not understand what you are proposing. Do you think >> you could try restating the computation you have in mind, perhaps by >> providing an equation that explains the construct? >> > > Sure. I'll stick to HMAC, which is more widely understood. We do > encrypt-them-mac using the write key. The inner SHA-256 consumes the > entire ciphertext, and at the end, the outer SHA-256 is applied. > > This hack would use a different key for the outer SHA-256. This way, it > is only used to hash a single block. > > Quite a hack, right :) > > Bill > --001a11409380d3e8bd0525ce1dff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ah, I see what you mean. Thanks for explaining.
<= br>
So, if I understand correctly, your threat model is that you = want to
prevent an attacker who obtains the traffic keys from inj= ecting
new traffic during the plausible lifetime of the connectio= n
(once close_notify has been exchanged, the traffic keys are
useless).

Whether this is possible or not w= ith a given AEAD transform seems
to depend on the transform. FWIW= , in the specific case of HMAC,
because the key \xor pad fills an= entire digest block, you might imagine
storing the state of the = outer compression function after the first block
in the hardware = module. I am not aware of any analysis that shows
that this is sa= fe and it very likely is not as strong as having the
entire HMAC = key in the module, but it might (or might not) be better
than not= hing.

-Ekr


On Mon, Nov 30, 2015 at 7:17 PM, = Bill Cox <waywardgeek@google.com> wrote:
On Mon, Nov 30, 2015 at 7:06 PM, Eric Res= corla <ekr@rtfm.com> wrote:
Hi Bill,

I am sorry, but I do not understa= nd what you are proposing. Do you think
you could try restating t= he computation you have in mind, perhaps by
providing an equation= that explains the construct?

Sure.=C2=A0 I'll stick to HMAC, which is more widely understood.= =C2=A0 We do encrypt-them-mac using the write key.=C2=A0 The inner SHA-256 = consumes the entire ciphertext, and at the end, the outer SHA-256 is applie= d.

This hack would use a different key for the out= er SHA-256.=C2=A0 This way, it is only used to hash a single block.

Quite a hack, right :)

Bill=C2=A0
<= /div>

--001a11409380d3e8bd0525ce1dff-- From nobody Mon Nov 30 20:10: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 79E381A0091 for ; Mon, 30 Nov 2015 20:10:15 -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 OO9q7Quvf9Cb for ; Mon, 30 Nov 2015 20:10:13 -0800 (PST) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::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 200191A1B8C for ; Mon, 30 Nov 2015 20:10:13 -0800 (PST) Received: by lffu14 with SMTP id u14so224493513lff.1 for ; Mon, 30 Nov 2015 20:10:11 -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:from:date:message-id :subject:to:cc:content-type; bh=g1o70Wf7IXNCCSef02paXq0c7jKpY3Q6KbNzFVVOivg=; b=z+x5A3NDXtwxqDUKpR1jAiXhFcRqCp/a0V7025p3a5w2OuRyhnkBgOagEBunHPpLlz QTpSDWciqMzV7TUik8yToJnhJXPS3R+rakCqgZRyI/2xO4YTwelj9eJabN056IcOsiY8 YtzpJf5u02h/XZsj2AORUkmEmCKDqBfbKfo2JgafAxfvxQB6dnBqo4yRfygFm5VfoUI2 nfHV00EYWRZ5OHuwj3rDg52KmEV01lcrJ1umMqYT7wvF1l99w87G3ya9GsRa1G1t5vsB DDpaMzPhMn8l6c8r9NM4Nfz1qXuXvJoHGhKCI6GBlfL3pjbrlMvk6y/hDgFJHHeYZ08x b4oQ== X-Received: by 10.25.88.208 with SMTP id m199mr26385060lfb.157.1448943011196; Mon, 30 Nov 2015 20:10:11 -0800 (PST) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.168.210 with HTTP; Mon, 30 Nov 2015 20:09:41 -0800 (PST) In-Reply-To: <201511301627.27616.davemgarrett@gmail.com> References: <201511301627.27616.davemgarrett@gmail.com> From: Hugo Krawczyk Date: Mon, 30 Nov 2015 23:09:41 -0500 X-Google-Sender-Auth: kKm9ZlfRD7U29JPZJU13pPAIqhc Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=001a1141a6347b73470525ce5527 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] bikeshed: Forward Security or Secrecy? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 04:10:15 -0000 --001a1141a6347b73470525ce5527 Content-Type: text/plain; charset=UTF-8 The more common term is "forward secrecy" - indeed, the normal definition [1] refers specifically to the secrecy of session keys or ephemeral key material after being deleted. Other elements of security such as authentication and integrity are irrelevant so "secrecy" seems to be the more appropriate term. There are other notions in cryptography that use the term "forward secure", see http://www.cs.bu.edu/~itkis/pap/forward-secure-survey.pdf. [1] "the compromise of long-term keys does not compromise past session keys" Hugo On Mon, Nov 30, 2015 at 4:27 PM, Dave Garrett wrote: > Which do we like better: "Forward Security" or "Forward Secrecy"? The TLS > 1.3 draft uses both interchangeably. The term is clearly in a state of > flux, seeing as we've seemingly collectively agreed to drop the word > "perfect" from the term, already. Personally, I prefer "security" because > "secrecy" is a less used word, and to "forward secure" something is > grammatically OK but to "forward secret" something is not. (e.g. the doc > says 0RTT data is not "forward secure" but "forward secret" isn't really > the right phrase here) Everything could be rephrased to use either, but I'd > like to change all our use to just "forward secure" and stick a note > somewhere on the terminology. > > > Dave > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a1141a6347b73470525ce5527 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The more common term is "forward secrecy&q= uot; - indeed, the normal definition [1] refers specifically to the secrecy= of session keys or ephemeral key material after being deleted. Other eleme= nts of security such as authentication and integrity are irrelevant so &quo= t;secrecy" seems to be the more appropriate term. There are other noti= ons in cryptography that use the term "forward secure", see=C2=A0= http:= //www.cs.bu.edu/~itkis/pap/forward-secure-survey.pdf.

[1] "the compromise of long-term keys does not c= ompromise past session keys"=C2=A0

Hugo


On Mon, Nov 30, 2015 at 4:27 PM, Dave Garrett <= davemgarrett@gmail.com> wrote:
Which do we like better: "Forward Security" or "Forward = Secrecy"? The TLS 1.3 draft uses both interchangeably. The term is cle= arly in a state of flux, seeing as we've seemingly collectively agreed = to drop the word "perfect" from the term, already. Personally, I = prefer "security" because "secrecy" is a less used word= , and to "forward secure" something is grammatically OK but to &q= uot;forward secret" something is not. (e.g. the doc says 0RTT data is = not "forward secure" but "forward secret" isn't rea= lly the right phrase here) Everything could be rephrased to use either, but= I'd like to change all our use to just "forward secure" and = stick a note somewhere on the terminology.


Dave

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

--001a1141a6347b73470525ce5527-- From nobody Mon Nov 30 20:20: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 F25C61A1BFE for ; Mon, 30 Nov 2015 20:20:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHkxUiSv3LRq for ; Mon, 30 Nov 2015 20:20:12 -0800 (PST) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 913701A1BF3 for ; Mon, 30 Nov 2015 20:20:12 -0800 (PST) Received: by igcmv3 with SMTP id mv3so86058254igc.0 for ; Mon, 30 Nov 2015 20:20:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=tkJGg80OLn/PbK0/lZ46e3PzJli82V6PW8iNQMQgJ7o=; b=xYfz8epGoHu6Md6b6EjAMJDNmka4LbGZPdE5gCiZLUoHOw5VJyx5Z9grB4qvGsNWHy UT53IZ7umFtXNWBe9UYMJmKJuZd07rUHwEK/WFLTD6LztC49IBTykhB/1Z2SFA4Sqzsi DEFB+3fom1Qo9P30qPFA3dh1SuTCo8OTQsOv9BmQtIiYmt34pzHSbgcNzj1w36xrXjbq nxDC5Oz1C1Ta3hYIi8mzV69JVKQLgcVCrtcCnXREnKvLnLPy8JUmYYT1a1beZIbv4s+A zoUZEAtHEA8aIPTQwL9M7jc2BZTTcO5pgW5GW6gnhtAyc+n+vHFYbjkOYFVbyR0eVK8m 4Kxg== X-Received: by 10.50.64.146 with SMTP id o18mr13821369igs.51.1448943611958; Mon, 30 Nov 2015 20:20:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.39.131 with HTTP; Mon, 30 Nov 2015 20:19:52 -0800 (PST) In-Reply-To: References: <201511301627.27616.davemgarrett@gmail.com> From: Tony Arcieri Date: Mon, 30 Nov 2015 20:19:52 -0800 Message-ID: To: Hugo Krawczyk Content-Type: multipart/alternative; boundary=047d7bea43fc4a5fe80525ce79a3 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] bikeshed: Forward Security or Secrecy? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 04:20:14 -0000 --047d7bea43fc4a5fe80525ce79a3 Content-Type: text/plain; charset=UTF-8 On Mon, Nov 30, 2015 at 8:09 PM, Hugo Krawczyk wrote: > The more common term is "forward secrecy" > I'd second this. I'm also a fan of Dan Bernstein's recommended term: "key erasure" -- Tony Arcieri --047d7bea43fc4a5fe80525ce79a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Nov 30, 2015 at 8:09 PM, Hugo Krawczyk <hugo@ee.technion.ac.il> wrote:
The more common term is "forward secrecy"= ;

I'd second this. I'm = also a fan of Dan Bernstein's recommended term: "key erasure"= =C2=A0

--
Ton= y Arcieri
--047d7bea43fc4a5fe80525ce79a3-- From nobody Mon Nov 30 20:20: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 AAFB41A1C02 for ; Mon, 30 Nov 2015 20:20:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwqLoo1LQWrr for ; Mon, 30 Nov 2015 20:20:54 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7D841A1C06 for ; Mon, 30 Nov 2015 20:20:54 -0800 (PST) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 08A3638F0E; Mon, 30 Nov 2015 20:20:53 -0800 (PST) From: "Jim Schaad" To: "'Jacob Appelbaum'" , References: <56586A2F.1070703@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B8DA2A@uxcn10-5.UoA.auckland.ac.nz> <565AC278.2010904@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B92E74@uxcn10-5.UoA.auckland.ac.nz> <565C0F25.7000507@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B9331B@uxcn10-5.UoA.auckland.ac.nz> <20151201005609.GD18315@mournblade.imrryr.org> In-Reply-To: Date: Mon, 30 Nov 2015 20:18:06 -0800 Message-ID: <0c2801d12bef$479e9b90$d6dbd2b0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQKdU3y63pJcfzPIupBntjBUDDYAsAGoFcACAnFTNzMBVqsRewHp/iJsAaDHHGUCMPVzQgHx5gqZnLRJtRA= Content-Language: en-us Archived-At: Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 04:20:56 -0000 > -----Original Message----- > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Jacob Appelbaum > Sent: Monday, November 30, 2015 5:36 PM > To: tls@ietf.org > Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all? > > On 12/1/15, Viktor Dukhovni wrote: > > On Mon, Nov 30, 2015 at 10:34:27AM +0000, Peter Gutmann wrote: > > > >> Bryan A Ford writes: > >> > >> >It would work just as well and in exactly the same way if the AEAD > >> >is replaced with the traditional Encrypt-then-MAC construction, for > >> >example. > >> > >> No it wouldn't, unless the encrypt part is a stream cipher. You're > >> still locked into using an AEAD stream cipher or the equivalent of an > >> AEAD stream cipher built with encrypt+MAC. It won't work with, for > >> example, the OCB AEAD mode, or CBC + MAC. > > > > I think we should focus on what would get TLS 1.3 to be adopted: > > > > * Reasonably implementable in libraries that support older > > versions alongside TLS 1.3. > > > > That doesn't change with Bryan's suggestion, I think. > > > * Interoperable in the field with various capital-intensive > > middle boxen. > > Which would those be? And what is the definition of capital-intensive for those > watching on the sidelines? > > > > > This suggests focusing on solidifying the core protocol, and a healthy > > dose of skepticism around bells and whistles. If the protocol is > > overloaded with too many (alright even more) incompatible innovations, > > the net effect is likely less security due to substantially delayed > > deployment of the key improvements. > > This seems borderline absurd. The TLS protocol is doing a major version revision. > > > Encrypting message lengths looks rather marginal from this > > perspective, and quite likely to hinder interoperability and delay > > both implementation and upgrades. However cool an idea this might be, > > this does not look to me like the right time to add this feature to > > TLS. > > I don't think it will hinder interoperability and not one person has even named a > single device that would have issues with it. I think the only thing that comes > close is when I've named a classified US government surveillance program > (XKeyscore) that would probably have trouble with it. > > We should add Bryan's feature and not pander to non-specific concerns about > middleboxes that should be considered as adversaries. > > > > > At this point, TLS 1.3 is rather feature rich, and it is I think time > > to focus on reviewing the already agreed changes (maybe even drop some > > if they look inessential). Make it solid, trim the fat, get it out > > the door in a usable form. > > That is part of what is happening in Bryan's suggestion. He found a reasonably > practical way to encrypt record headers. His suggestion will make TLS more > secure. His suggestion includes a review of a part of the previous state of TLS > 1.3 with a proposed improvement. I would strongly prefer that the analysis for TLS and DTLS no be too different. This approach will not work for DTLS given that packets can arrive out of order and multiple times. Jim > > No one is debating it on the cryptographic merits which is surprising. > > All the best, > Jacob > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Mon Nov 30 20:23: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 B35351A1C02 for ; Mon, 30 Nov 2015 20:23:00 -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, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TEhsRYATWJVM for ; Mon, 30 Nov 2015 20:22:59 -0800 (PST) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ECAC1A00F6 for ; Mon, 30 Nov 2015 20:22:59 -0800 (PST) Received: by ykba77 with SMTP id a77so210791694ykb.2 for ; Mon, 30 Nov 2015 20:22:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=rbqfVd+A8J1whufUhAQHbdqczTe3/zt/35zP3Da7HBo=; b=IMaZKahvTeG8oXmYM0bWhl9o8iCl14n/28RzFgYbCzF/SX8xmu+70NJs+k2xTlGxWs Q3nZaD7uCuL2WymQ4rCdW1dlEAeVfS8UdzpZpZHxOE2vTWwaHXqWx6DSzfMM+ML4SXKZ pCgGBHYJAILYcNQ8jrA3UJW65kzhe6P0FHcjAfzePKXq6unoYRU1SE5AmrRCk7PPuZqR Kohm2BrY1OTByfNJ9ijuVKRkZX8p2AKUBDIRO+gfZgpvPHV4SqAevjRJViHkqR2HRogN 8EryPvP+969NcKfwHwi4mLCo6lK+ju8cnOr7uGk4yKHkHgvR0528lf8i5938Nfc1UFQr x6yw== 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=rbqfVd+A8J1whufUhAQHbdqczTe3/zt/35zP3Da7HBo=; b=HYqUJAknoxyKixWhVKnQTn41JonkjeUso65sljnSM11NK+Sdseyfanh12lYDmVc7ML CYxVjUQ62Lvg4BNE7LuDPWWWi2q4KbAcIBNgBi5XxzqgzEcPCnut2innLs1clFusz1Sw LmAAQrkE0BJ2pnbS52Wf52ayGoX2ufaA6+gLqpgxHZb32jaNHxGE9jaV+6sjT0+T4w64 Xm+vvg0yxabzQZA1tHLlVJYbj1C0Vb7TypOKe0Rqf4HNwTUwvEGZmyRfPqURas0QXL1s ubFbTzlcKI7avnc5QBt5OS8R9H6vEMnfb2Z8GJVHVEgcG1f1nDU1VKhs0a+MrVUSWnhw Aqvw== X-Gm-Message-State: ALoCoQkYrvQFTL4ErJ8c6ecB6mRonfpCKEOTpw6FIOSnyC2Y85NhC5hqMfLg26T8ZTuylfFGnQmL X-Received: by 10.129.79.11 with SMTP id d11mr25931352ywb.115.1448943778894; Mon, 30 Nov 2015 20:22:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.197 with HTTP; Mon, 30 Nov 2015 20:22:19 -0800 (PST) In-Reply-To: References: <201511301627.27616.davemgarrett@gmail.com> From: Eric Rescorla Date: Mon, 30 Nov 2015 20:22:19 -0800 Message-ID: To: Tony Arcieri Content-Type: multipart/alternative; boundary=001a114dbab03dc5260525ce83e1 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] bikeshed: Forward Security or Secrecy? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 04:23:00 -0000 --001a114dbab03dc5260525ce83e1 Content-Type: text/plain; charset=UTF-8 I have filed issue 353 for this so we don't lose it. https://github.com/tlswg/tls13-spec/issues/353 Thanks. -Ekr On Mon, Nov 30, 2015 at 8:19 PM, Tony Arcieri wrote: > On Mon, Nov 30, 2015 at 8:09 PM, Hugo Krawczyk > wrote: > >> The more common term is "forward secrecy" >> > > I'd second this. I'm also a fan of Dan Bernstein's recommended term: "key > erasure" > > -- > Tony Arcieri > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a114dbab03dc5260525ce83e1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have filed issue 353 for this so we don't lose it.

Thanks.
-Ekr


On Mon, Nov 30, 2015 at 8:19 PM, Ton= y Arcieri <bascule@gmail.com> wrote:
On Mon, Nov 30, 2015 at 8:09 PM, Hugo Krawczyk <hugo@ee.technion.ac.il> wrote:
The more common term is "forward secrecy"
<= /blockquote>

I'd second this. I'm also a = fan of Dan Bernstein's recommended term: "key erasure" =C2=A0=

-= -
Tony Arcieri

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


--001a114dbab03dc5260525ce83e1-- From nobody Mon Nov 30 21:21: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 68F9A1B38EB for ; Mon, 30 Nov 2015 21:21:08 -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 o6m36gXOmURb for ; Mon, 30 Nov 2015 21:21:07 -0800 (PST) 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 3BDD91B38EA for ; Mon, 30 Nov 2015 21:21:07 -0800 (PST) Received: by igcto18 with SMTP id to18so88358125igc.0 for ; Mon, 30 Nov 2015 21:21:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Y4Iz7daIjG8GpNMBew/uTWeb3mfwxnYbQ8JGBJ+sKUw=; b=RqexB4Pgfwg1rXKpUUWQXKc8CUKxzSi1f8tl0ufX8Fc6k1BSzsiNS6wK9KqiKhwBxX tWZz5PYfmkb4hpxB9KeYXZwRsolEAH8SMWmFkUpmO/doEgh/nWpUB/7NHUXYsmvjMz3h QYXBE+aneWtlB7wxrY1BjRWDYjfq6NUhDGuPckL0WAmwlVuWjhMyqc/SJjUHve3uKEfU MqZ+LS0y2zujms6Nsm3EhMpfepmTF+YCbp+qDlxrC54xVShCQ4QmeVYbV/Ws2yNo2Aes zlKAZmP0esYlWtH8aYrSe3Lz1Vot3Zkb62UYwvqZZjLpqKApi7aFeU+jqaIV9O7BdjG0 VosQ== 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=Y4Iz7daIjG8GpNMBew/uTWeb3mfwxnYbQ8JGBJ+sKUw=; b=mD51SaNH4sPzZXEylDiXSxtSpym8JUiXZJenyDf66aLRqq4k9Dnhaz5kbVDaZO+Mqf /N7goq/LErLvB+hFPjeiAXP+gspDVeCHYkuEUG4EssF/8pg9OCX9kAj+svLy2Q+YOsy3 +jLlzjKCaFdTrw9Zj9ke6hr2IAPVb7VjhKJHpCPuvkckxX8NfJRDwHt7bHOMao1irgY9 1LLU8M7X0Mh3L0SdicqfJHSChSZBq4okwmyOjRTVsvxSdpEa5SCWPX+S3qHz5T9pln5t lmnHxjHDofNhJy4uWfJVIQF29/r+zwPaE/I9Ia+yo/DpEX8BLeLcO8+5wr26FvP8hmM7 xjJw== X-Gm-Message-State: ALoCoQmVdZ7V/ToZl8CBGrCLEV0u6t0wfAKkzdDGcfG7vBIoIQgtyTtrPkp5tq+mF1Ar1sCHJwrV MIME-Version: 1.0 X-Received: by 10.50.150.106 with SMTP id uh10mr25514451igb.85.1448947266533; Mon, 30 Nov 2015 21:21:06 -0800 (PST) Received: by 10.107.173.15 with HTTP; Mon, 30 Nov 2015 21:21:06 -0800 (PST) In-Reply-To: References: Date: Mon, 30 Nov 2015 21:21:06 -0800 Message-ID: From: Bill Cox To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a11c3b1da1f14c60525cf537c Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Dumb thoughts for hardware backed keys for AEAD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 05:21:08 -0000 --001a11c3b1da1f14c60525cf537c Content-Type: text/plain; charset=UTF-8 On Mon, Nov 30, 2015 at 7:53 PM, Eric Rescorla wrote: > Ah, I see what you mean. Thanks for explaining. > > So, if I understand correctly, your threat model is that you want to > prevent an attacker who obtains the traffic keys from injecting > new traffic during the plausible lifetime of the connection > (once close_notify has been exchanged, the traffic keys are > useless). > Yes. > Whether this is possible or not with a given AEAD transform seems > to depend on the transform. > Agreed. > FWIW, in the specific case of HMAC, > because the key \xor pad fills an entire digest block, you might imagine > storing the state of the outer compression function after the first block > in the hardware module. I am not aware of any analysis that shows > that this is safe and it very likely is not as strong as having the > entire HMAC key in the module, but it might (or might not) be better > than nothing. > I think it would not be hard to prove for HMAC/HKDF that this scheme has similar defensive properties compared to the usual flow, with reasonable assumptions about key generation. However, the extra complexity in every TLS 1.3 implementation bothers me. I worry that separating the read/write keys may not be worth it. Did we gain enough security to warrant the complexity? Bill --001a11c3b1da1f14c60525cf537c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Nov 30, 2015 at 7:53 PM, Eric Rescorla <ekr@rtfm.com> wrote:<= br>
Ah, I see what you mean.= Thanks for explaining.

So, if I understand correct= ly, your threat model is that you want to
prevent an attacker who= obtains the traffic keys from injecting
new traffic during the p= lausible lifetime of the connection
(once close_notify has been e= xchanged, the traffic keys are
useless).

Yes.
=C2=A0
Whether this is possible or not with a = given AEAD transform seems
to depend on the transform.

Agreed.
=C2=A0
FWIW, in the specific = case of HMAC,
because the key \xor pad fills an entire digest blo= ck, you might imagine
storing the state of the outer compression = function after the first block
in the hardware module. I am not a= ware of any analysis that shows
that this is safe and it very lik= ely is not as strong as having the
entire HMAC key in the module,= but it might (or might not) be better
than nothing.
<= /div>

I think it would not be hard to prove= for HMAC/HKDF that this scheme has similar defensive properties compared t= o the usual flow, with reasonable assumptions about key generation.

However, the extra complexity in every TLS 1.3 implem= entation bothers me.=C2=A0 I worry that separating the read/write keys may = not be worth it.=C2=A0 Did we gain enough security to warrant the complexit= y?

Bill
--001a11c3b1da1f14c60525cf537c--