From nobody Fri Aug 2 15:30:23 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DABF8120077 for ; Fri, 2 Aug 2019 15:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sap.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id esnpK5l1ACsC for ; Fri, 2 Aug 2019 15:30:18 -0700 (PDT) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57D22120059 for ; Fri, 2 Aug 2019 15:30:18 -0700 (PDT) Received: from esa15.sap.c3s2.iphmx.com (esa15.sap.c3s2.iphmx.com [216.71.156.113]) (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 ESMTPSA id 460hgX0fQfz103F; Sat, 3 Aug 2019 00:30:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sap.com; i=@sap.com; q=dns/txt; s=it-20190212; t=1564785017; x=1596321017; h=subject:in-reply-to:references:to:date:cc:reply-to: mime-version:content-transfer-encoding:message-id:from; bh=u047yNO32PPyZhVhRBKKDSCDRiaZ1Xo9REMcB5LyJQc=; b=sMxX2C7KipoDB1afwfRVz9PsctexrwINhv4UQAXncymlA8IkL+XT9Jnw bYWe4aTrOk2zXk+7O2n2fEfx/JKAFz/MWGmkU3f2CPNPJUdFSFk+bPJ7R l9JKKyhCyF+6C3tUELsJJCNBUYEiezmEcYJo0YhJ6hQgLFFwXJMMAY0MO SZtWvh+6MOLwsPoTpDQ2XPPrmU6D80rNgXq6xZIpWhwRx9PcHmBIbo9lq z/q8rfNh9/PqrdIYsLwvtjRqDv8r0ukHaPZKIMFBNElqfGpRt/9cx0CdN BikjVIOx+3BXrZQX8GYl24MNYUlufByj8rX5mHNaWCMDMQKXcAGpIg/26 w==; X-Amp-Result: SKIPPED(no attachment in message) Received: from smtpde02.smtp.sap-ag.de ([155.56.68.140]) by esa15.sap.c3s2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Aug 2019 00:30:16 +0200 Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (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 460hgV5lwNzfg; Sat, 3 Aug 2019 00:30:14 +0200 (CEST) X-purgate-ID: 152705::1564785014-00000317-C595D430/0/0 X-purgate-size: 4451 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]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail07.wdf.sap.corp (Postfix) with ESMTPS id 460hgV3F8XzGpxk; Sat, 3 Aug 2019 00:30:14 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 532BE404C; Sat, 3 Aug 2019 00:30:14 +0200 (CEST) In-Reply-To: <5441930.X76MtM1CnQ@pintsize.usersys.redhat.com> References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <7d37f7ca-e253-4c95-9cf7-2d16b0b6a0aa@www.fastmail.com> <20190430234952.21F5C404C@ld9781.wdf.sap.corp> <5441930.X76MtM1CnQ@pintsize.usersys.redhat.com> To: Hubert Kario Date: Sat, 3 Aug 2019 00:30:14 +0200 (CEST) CC: tls@ietf.org, mrex@sap.com, Martin Thomson Reply-To: mrex@sap.com MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" Message-Id: <20190802223014.532BE404C@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2019 22:30:22 -0000 Hubert Kario wrote: > On Wednesday, 1 May 2019 01:49:52 CEST Martin Rex wrote: >>=20 >> It is formally provable that from the three protocol versions: >>=20 >> TLSv1.0, TLSv1.1, TLSv1.2 >>=20 >> the weakest one is TLSv1.2, because of the royally stupid downgrade >> in the strength of digitally signed. >>=20 >>=20 >> Disabling TLSv1.0 will only result in lots of interop failures >> and pain, but no improvement in security. >=20 > We've been over this Martin, the theoretical research shows that for Merk= le- > Damg=E5rd functions, combining them doesn't increase their security=20 > significantly. >=20 > And the practical research: > https://eprint.iacr.org/2016/131.pdf > https://www.iacr.org/archive/asiacrypt2009/59120136/59120136.pdf > only confirms that. >=20 > So, please, use a bit less inflammatory language when you have no factual= =20 > arguments behind your assertions. I recently looked into the practical research paper you referenced, about what it **REALLY** says. Maybe you should have read this first, about the *true* prerequisites of the attack, and what it means *really* means for the security of digitally_signed using SHA1||MD5 in TLSv1.0+TLSv1= .1 From=20what I can read in that paper, it actually confirms that the security of digitally_signed using SHA1||MD5 for the TLSv1.0 ServerKeyExchange handshake message for TLS_ECDHE_RSA_WITH_* is more in the same ballpark as the security of SHA256, because of the small size of data that gets signed. from page 3 of this paper: https://eprint.iacr.org/2016/131.pdf In this paper, we devise the first second preimage attack on the concatenation combiner of Merkle-Damg=B0ard hash functions which is faster than 2^n. As in related attacks (and in particular, [23]) we obtain a tradeoff between the complexity of the attack and the length of the target message. In particular, our second preimage attack is faster than 2^n only for input messages of length at least[*2] 2^(2*n/7). The optimal complexity[*3] of our attack is 2^(3*n/4), and is obtained for (very) long messages of length 2^(3*n/4). Due to these constraints, the practical impact of our second preimage attack is limited and its main significance is theoretical. Namely, it shows that the concatenation of two Merkle-Damg=B0ard hash functions is not as strong a single ideal hash function. [*2] For example, for n=3D160 and messge block length 512 bits (as in SH= A-1), the attack is faster than 2^160 only for messages containing at lea= st 2^48 blocks, or 2^52 bytes. [*3] The complexity formulas do not take into account (small) constant factors, which are generally ignored throughout this paper. FYI 2^52 bytes =3D=3D 4,503,599,627,370,496 bytes =3D=3D 4 PETA-Bytes i.e. you need an AWFULLY HUGE amount of "wiggle room" in order to efficiently construct a multi-collision, and the paper mentions that if you have just tiny wiggle-room available, you are out-of-luck, there is no "fast" algorithm for an attack. More so if you also have to account for a leading length field in the message. For comparison size of digitally-signed data in ServerKeyExchange: struct { select (KeyExchangeAlgorithm) { case dh_anon: ServerDHParams params; case dhe_dss: case dhe_rsa: ServerDHParams params; digitally-signed struct { opaque client_random[32]; opaque server_random[32]; ServerDHParams params; } signed_params; case rsa: case dh_dss: case dh_rsa: struct {} ; /* message is omitted for rsa, dh_dss, and dh_rsa */ /* may be extended, e.g., for ECDH -- see [TLSECC] */ }; } ServerKeyExchange; for a DHE-2048 bit keypair, the size of signed data is typically 32 + 32 + 2 + 256 + 2 + 1 + 2 + 256 =3D 583 bytes for ECDHE P-384, the size of signed data is typically 32 + 32 + 1 + 2 + 1 + 97 =3D 165 bytes=20 So for TLS_ECDHE_RSA_WITH_* cipher suites, you have a *MUCH* stronger baseline security with TLSv1.0 + TLSv1.1 (SHA1||MD5) than with TLSv1.2 (SHA1-only) -Martin From nobody Fri Aug 2 19:26:58 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA570120046 for ; Fri, 2 Aug 2019 19:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nuMvl0aLEpLZ for ; Fri, 2 Aug 2019 19:26:54 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 44F9212002F for ; Fri, 2 Aug 2019 19:26:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1564799215; x=1596335215; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=WyN44ihID113tkSDGvAnDF1iWPZZrqmBFkrkktPeFU4=; b=bY88uo8Iui8c4DLe/rSj+hcz2PhIaxvEtyAqphEQ0mEIwusCEv8dRHf+ heSjslsosqufvErUArX/RN7ZsSEuqIFAexUUTgqwHtCjOVjCzv93Ppwar zWVa+v4j5SlHqvQdVLtTUItd7c6yVaJW71BOvgpp+Y3rFwzs/RkmQR898 QbFh9rCuoIqHocNr5lJZHQY7ilyD75l9f5CCbIGwKyb8VzBXFC2itReuh iDjA05X8C4WRCGfs15bp6j+ukBgTfAayxQMQ1aePv1B9svdlaSR9B1lRE w1+X13MjfqAtp74i0m8VHA0GkYL1ObcwHW1WX5jOjh0sHBqcEesk9Amj+ Q==; X-IronPort-AV: E=Sophos;i="5.64,340,1559476800"; d="scan'208";a="73708432" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.3 - Outgoing - Outgoing Received: from uxcn13-tdc-b.uoa.auckland.ac.nz ([10.6.3.3]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 03 Aug 2019 14:26:51 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-b.UoA.auckland.ac.nz (10.6.3.3) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 3 Aug 2019 14:26:49 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Sat, 3 Aug 2019 14:26:49 +1200 From: Peter Gutmann To: Hubert Kario , "mrex@sap.com" CC: "tls@ietf.org" Thread-Topic: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" Thread-Index: AQHVSYHtpaAXFZovUU2VBDJQbIGGAqbosczU Date: Sat, 3 Aug 2019 02:26:49 +0000 Message-ID: <1564799187183.77257@cs.auckland.ac.nz> References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <7d37f7ca-e253-4c95-9cf7-2d16b0b6a0aa@www.fastmail.com> <20190430234952.21F5C404C@ld9781.wdf.sap.corp> <5441930.X76MtM1CnQ@pintsize.usersys.redhat.com>, <20190802223014.532BE404C@ld9781.wdf.sap.corp> In-Reply-To: <20190802223014.532BE404C@ld9781.wdf.sap.corp> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 03 Aug 2019 02:26:57 -0000 Martin Rex / Hubert Kario wrote:=0A= =0A= [...]=0A= =0A= We went through the same thing, in the same thread, with the same people, a= =0A= few months ago. Perhaps we could just replay the messages and everyone els= e=0A= could sit back and watch? =0A= =0A= And since Hubert has brought up the same bogus argument as last time, perha= ps=0A= a good re-read would be in order? This was already resolved the last time= =0A= round.=0A= =0A= Peter.=0A= From nobody Mon Aug 5 06:43:37 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9088C120203 for ; Mon, 5 Aug 2019 06:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=notforadio.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHGVImFolDMK for ; Mon, 5 Aug 2019 06:43:34 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::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 6403B1201EC for ; Mon, 5 Aug 2019 06:43:34 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id v24so79484719ljg.13 for ; Mon, 05 Aug 2019 06:43:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=notforadio.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=ZjkItL+TwpPEJysoM7zn6uoH5/EaeBiCfzZ2gPO2Em8=; b=EGPU5kakyVh31W3Ivg8SF9jri/jes4HMWBEQO9othoBeVRIYlAtkVUThKONv75U+5I /jzaLceOdLN0kj2IuGCdVszBkdv/FRDFcnDC+hkMj+r/K2gJYLRK3wK8zb5e6j2xrcWt st8kQYVWkhJ5GBS0tRF2A5yAkrzfOLE+jzH1c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=ZjkItL+TwpPEJysoM7zn6uoH5/EaeBiCfzZ2gPO2Em8=; b=Nauny3yrJcZwVlCzSYQ6X7gZdl/fEe6ZG0YNiTEAIckKNvnvb8I+dWpncIC0NHuFnn QbzVf6PvU4AR5ACjXH9C3C3LzIK/rtc/YeHeaU5adkeRo8RQEgGg+TLL1+zB+rsaCdjJ AFS2CLBmJhnuPcrBOFAiylYFdyQ5M2ZR/bBD1zx6Ey7FwTkDzkzjI6u2zsSGc6T4MaI0 rUYyM6eMKd9CtChZa20tmQIwgCrieAZUkY9eKCb/Ba5oaVwPqZcVGWmsaMsk0QqBTbZz Oj9A4Fr4VWOwgJx9Onv1VlENoKPOJle0DRB9YMmd79BT6uLwXXLZr3uKxub6A48yVxsP vJRQ== X-Gm-Message-State: APjAAAU+jYc6iRUkCb0uB/fuowoy9Mza+ISxnKPDOCAAwmQCnkzNUb+W miI0l/HUY0qWFK/wiIDBRmf+Rw39DuRtCx5cSZrsY6JRpVp7bA== X-Google-Smtp-Source: APXvYqzhnH+aI/ds+1wgctIZqQbJnJf126aFxPoh7n+xBIUpI2EnhpFTO+xr8jcfzSZW8MNZJucccioXv6tsv0Zg5Vg= X-Received: by 2002:a2e:93c5:: with SMTP id p5mr5993689ljh.79.1565012612043; Mon, 05 Aug 2019 06:43:32 -0700 (PDT) MIME-Version: 1.0 References: <20180828032952.70F7CB81122@rfc-editor.org> In-Reply-To: <20180828032952.70F7CB81122@rfc-editor.org> From: Patrick Kelsey Date: Mon, 5 Aug 2019 09:43:21 -0400 Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary="000000000000cf70b1058f5ee42a" Archived-At: Subject: Re: [TLS] [Technical Errata Reported] RFC8446 (5483) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2019 13:43:37 -0000 --000000000000cf70b1058f5ee42a Content-Type: text/plain; charset="UTF-8" I brought this up to Ekr at IETF 105, and he said he hadn't seen this particular errata, so here's a bump to the top of the list. As it's now been about a year that this errata has remained in the initial state, I think it might be worth having a look at and advancing to the next state, if for no other reason than avoidance of the mistaken external impression that there is longstanding uncertainty about a report that part of the document says that a private key is to be put on the wire. -Pat On Mon, Aug 27, 2018 at 11:30 PM RFC Errata System < rfc-editor@rfc-editor.org> wrote: > The following errata report has been submitted for RFC8446, > "The Transport Layer Security (TLS) Protocol Version 1.3". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5483 > > -------------------------------------- > Type: Technical > Reported by: Patrick Kelsey > > Section: 4.2.8.2 > > Original Text > ------------- > For X25519 and X448, the contents of the public value are the byte > string inputs and outputs of the corresponding functions defined in > [RFC7748]: 32 bytes for X25519 and 56 bytes for X448. > > Corrected Text > -------------- > For X25519 and X448, the contents of the public value are the byte > string outputs of the corresponding functions defined in [RFC7748]: 32 > bytes for X25519 and 56 bytes for X448. > > Notes > ----- > Per Section 7.4.2 of this RFC and Section 6 of RFC7748, the byte string > inputs to the corresponding ECDH scalar multiplication function are the > private key and the u-coordinate of the standard public base point, the > former of which of course must not be transmitted and the latter of which > is a known constant. > > From another perspective, including the byte string inputs in the contents > of the public value would contradict the resulting content sizes given at > the end of the cited paragraph as well as the statement in Section 7.4.2 > that the public key put into the KeyShareEntry is the output of ECDH scalar > multiplication function. > > 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 > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC8446 (draft-ietf-tls-tls13-28) > -------------------------------------- > Title : The Transport Layer Security (TLS) Protocol Version > 1.3 > Publication Date : August 2018 > Author(s) : E. Rescorla > Category : PROPOSED STANDARD > Source : Transport Layer Security > Area : Security > Stream : IETF > Verifying Party : IESG > --000000000000cf70b1058f5ee42a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I brought this up to Ekr at IETF 105, and= he said he hadn't seen this particular errata, so here's a bump to= the top of the list.

As it's = now been about a year that this errata has remained in the initial state, I= think it might be worth having a look at and advancing to the next state, = if for no other reason than avoidance of the mistaken external impression t= hat there is longstanding uncertainty about a report that part of the docum= ent says that a private key is to be put on the wire.

<= div>-Pat

On Mon, Aug 27, 2018 at 11:30 PM RFC Errata System <rfc-editor@rfc-editor.org> wrote:
The following err= ata report has been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5483

--------------------------------------
Type: Technical
Reported by: Patrick Kelsey <pat.kelsey@notforadio.com>

Section: 4.2.8.2

Original Text
-------------
For X25519 and X448, the contents of the public value are the byte
string inputs and outputs of the corresponding functions defined in
[RFC7748]: 32 bytes for X25519 and 56 bytes for X448.

Corrected Text
--------------
For X25519 and X448, the contents of the public value are the byte
string outputs of the corresponding functions defined in [RFC7748]: 32
bytes for X25519 and 56 bytes for X448.

Notes
-----
Per Section 7.4.2 of this RFC and Section 6 of RFC7748, the byte string inp= uts to the corresponding ECDH scalar multiplication function are the privat= e key and the u-coordinate of the standard public base point, the former of= which of course must not be transmitted and the latter of which is a known= constant.

>From another perspective, including the byte string inputs in the contents = of the public value would contradict the resulting content sizes given at t= he end of the cited paragraph as well as the statement in Section 7.4.2 tha= t the public key put into the KeyShareEntry is the output of ECDH scalar mu= ltiplication function.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, ple= ase
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party=C2=A0
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC8446 (draft-ietf-tls-tls13-28)
--------------------------------------
Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: The Transport= Layer Security (TLS) Protocol Version 1.3
Publication Date=C2=A0 =C2=A0 : August 2018
Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: E. Rescorla
Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD
Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Transport Layer Se= curity
Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Security
Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
--000000000000cf70b1058f5ee42a-- From nobody Mon Aug 5 07:46:48 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2DD12022C for ; Mon, 5 Aug 2019 07:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.298 X-Spam-Level: X-Spam-Status: No, score=-9.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.201, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iW6Ium9HIr-i for ; Mon, 5 Aug 2019 07:46:45 -0700 (PDT) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAD5C120230 for ; Mon, 5 Aug 2019 07:46:44 -0700 (PDT) Received: by mail-qk1-x730.google.com with SMTP id r6so60302339qkc.0 for ; Mon, 05 Aug 2019 07:46:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sozGV2/Fgur+GyPwkTKu/IYobJaOWeN5dT313+hpp7I=; b=mZZH0JLmK0pJlIYy2Y78cawJS8Pvbxz4lESUO1TwULDMDi17TYYb8yjsp5OObvflCP dIDj8YB6sQh9rJrrV7TxU9ij30Yre3hUs28LAwK5WYtthrTwXcRpyP4w3dyZOt5h/IMi i+pOGGgdOVkZDTRVgC5mPCzYViP2rHfmjt1wk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sozGV2/Fgur+GyPwkTKu/IYobJaOWeN5dT313+hpp7I=; b=U8vriT5QzDD9y5YbxIU9tS74cDpcFt35h51pmyP6DFAZOdCCFm1m5h+kA46HXIu3Qq xf+upZSta+HiFU0EXSYpiz9UTnEVt27dfj4gzhGJoDuEM/fas1eXp7TZPv2TfayFglIf o6hbmq6TKaIdroOCAcZiXRYKhmDyw1FXBUsbJPXlmd642F26Snor2Hilw83XUMWIVmwx kbVNWtnGNKx5pZPtyFSwRlH7vZOodUCZjZDoTzJP1WByo1YzmIujX4u7Q08MJH+2OsyC Qn299NdTn0iZQN/DKDhUd38EAPYM6eXfUPfAwJ8gclTnbUwZGSgAGqfmQtAY9pP3lfQd d3qg== X-Gm-Message-State: APjAAAXu9GvoupYzIaJsep53W8Q0+vwwZRf4tbIKm6/Qs6XMOwcEx4Sb NYL5/p58FXJOmyqoNlzUqc+NgiTk90ormgHBSbVmrZlp+Txq X-Google-Smtp-Source: APXvYqzTRJHbzWQwh9aWB84hvFCTAjZQtSySLhsH0LNyRYsUAzalVBCrdQrDiZkmyp6j0+SkI8qevW3Rgi1HviGJJKk= X-Received: by 2002:a37:7704:: with SMTP id s4mr101667040qkc.310.1565016403684; Mon, 05 Aug 2019 07:46:43 -0700 (PDT) MIME-Version: 1.0 References: <20180828032952.70F7CB81122@rfc-editor.org> In-Reply-To: From: David Benjamin Date: Mon, 5 Aug 2019 10:46:27 -0400 Message-ID: To: Patrick Kelsey Cc: "" Content-Type: multipart/alternative; boundary="000000000000cf98ba058f5fc6b2" Archived-At: Subject: Re: [TLS] [Technical Errata Reported] RFC8446 (5483) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2019 14:46:47 -0000 --000000000000cf98ba058f5fc6b2 Content-Type: text/plain; charset="UTF-8" There are two scalar multiplications involved. The first, as part of key generation, indeed passes in a known constant to the u value and outputs the byte string that goes into the key share. The second, the ECDH operation itself, passes in the peer key share and results in the shared secret. In the first call, the key share is the output. In the second, the key share is the input. https://tools.ietf.org/html/rfc7748#section-6.1 But I agree it's not particularly clear. Perhaps it should have said something like: For X25519 and X448, the contents of the public value are the K_A and K_B values described in section 6 of [RFC7748]. This is 32 bytes for X25519 and 56 bytes for X448. On Mon, Aug 5, 2019 at 9:43 AM Patrick Kelsey wrote: > I brought this up to Ekr at IETF 105, and he said he hadn't seen this > particular errata, so here's a bump to the top of the list. > > As it's now been about a year that this errata has remained in the initial > state, I think it might be worth having a look at and advancing to the next > state, if for no other reason than avoidance of the mistaken external > impression that there is longstanding uncertainty about a report that part > of the document says that a private key is to be put on the wire. > > -Pat > > On Mon, Aug 27, 2018 at 11:30 PM RFC Errata System < > rfc-editor@rfc-editor.org> wrote: > >> The following errata report has been submitted for RFC8446, >> "The Transport Layer Security (TLS) Protocol Version 1.3". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata/eid5483 >> >> -------------------------------------- >> Type: Technical >> Reported by: Patrick Kelsey >> >> Section: 4.2.8.2 >> >> Original Text >> ------------- >> For X25519 and X448, the contents of the public value are the byte >> string inputs and outputs of the corresponding functions defined in >> [RFC7748]: 32 bytes for X25519 and 56 bytes for X448. >> >> Corrected Text >> -------------- >> For X25519 and X448, the contents of the public value are the byte >> string outputs of the corresponding functions defined in [RFC7748]: 32 >> bytes for X25519 and 56 bytes for X448. >> >> Notes >> ----- >> Per Section 7.4.2 of this RFC and Section 6 of RFC7748, the byte string >> inputs to the corresponding ECDH scalar multiplication function are the >> private key and the u-coordinate of the standard public base point, the >> former of which of course must not be transmitted and the latter of which >> is a known constant. >> >> >From another perspective, including the byte string inputs in the >> contents of the public value would contradict the resulting content sizes >> given at the end of the cited paragraph as well as the statement in Section >> 7.4.2 that the public key put into the KeyShareEntry is the output of ECDH >> scalar multiplication function. >> >> 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 >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC8446 (draft-ietf-tls-tls13-28) >> -------------------------------------- >> Title : The Transport Layer Security (TLS) Protocol Version >> 1.3 >> Publication Date : August 2018 >> Author(s) : E. Rescorla >> Category : PROPOSED STANDARD >> Source : Transport Layer Security >> Area : Security >> Stream : IETF >> Verifying Party : IESG >> > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000cf98ba058f5fc6b2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There are two scalar multiplications involved. The first, = as part of key generation, indeed passes in a known constant to the u value= and outputs the byte string that goes into the key share. The second, the = ECDH operation itself, passes in the peer key share and results in the shar= ed secret. In the first call, the key share is the output. In the second, t= he key share is the input.
https://tools.ietf.org/html/rfc7748#section-6.1

But I agree it's not particularly clear. Perhaps = it should have said something like:

For X25519 and= X448, the contents of the public value are the K_A
and K_B value= s described in section 6 of=C2=A0[RFC7748]. This is=C2=A032 bytes
for X25519 and 56 bytes for X448.

On Mon, Aug 5, 2019 at 9:43 AM = Patrick Kelsey <pat.kelsey@= notforadio.com> wrote:
I brought this up to Ekr at= IETF 105, and he said he hadn't seen this particular errata, so here&#= 39;s a bump to the top of the list.

As it's now been about a year that this errata has remained in the in= itial state, I think it might be worth having a look at and advancing to th= e next state, if for no other reason than avoidance of the mistaken externa= l impression that there is longstanding uncertainty about a report that par= t of the document says that a private key is to be put on the wire.

-Pat

On Mon, Aug 27, 2018 at 11:30 PM RFC Errata System &l= t;rfc-editor= @rfc-editor.org> wrote:
The following errata report has been submitted for RFC8446,<= br> "The Transport Layer Security (TLS) Protocol Version 1.3".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5483

--------------------------------------
Type: Technical
Reported by: Patrick Kelsey <pat.kelsey@notforadio.com>

Section: 4.2.8.2

Original Text
-------------
For X25519 and X448, the contents of the public value are the byte
string inputs and outputs of the corresponding functions defined in
[RFC7748]: 32 bytes for X25519 and 56 bytes for X448.

Corrected Text
--------------
For X25519 and X448, the contents of the public value are the byte
string outputs of the corresponding functions defined in [RFC7748]: 32
bytes for X25519 and 56 bytes for X448.

Notes
-----
Per Section 7.4.2 of this RFC and Section 6 of RFC7748, the byte string inp= uts to the corresponding ECDH scalar multiplication function are the privat= e key and the u-coordinate of the standard public base point, the former of= which of course must not be transmitted and the latter of which is a known= constant.

>From another perspective, including the byte string inputs in the conte= nts of the public value would contradict the resulting content sizes given = at the end of the cited paragraph as well as the statement in Section 7.4.2= that the public key put into the KeyShareEntry is the output of ECDH scala= r multiplication function.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, ple= ase
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party=C2=A0
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC8446 (draft-ietf-tls-tls13-28)
--------------------------------------
Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: The Transport= Layer Security (TLS) Protocol Version 1.3
Publication Date=C2=A0 =C2=A0 : August 2018
Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: E. Rescorla
Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD
Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Transport Layer Se= curity
Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Security
Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000cf98ba058f5fc6b2-- From nobody Mon Aug 5 08:24:15 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9558E120162 for ; Mon, 5 Aug 2019 08:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=notforadio.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWtCtj41TSBF for ; Mon, 5 Aug 2019 08:23:53 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::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 0E79C1200F3 for ; Mon, 5 Aug 2019 08:23:53 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id m8so46035454lji.7 for ; Mon, 05 Aug 2019 08:23:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=notforadio.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=voZD3V6aaL4eDkUBibmIwPwCzqgGa89auwXeR1bBcKU=; b=biDNF+ATpMY1lPOqP7rB8S0nsfqlPhrjlGlx4fZQgSKj8G5S76U4J0wea90WeoBGlh S3Y4SqwZjHZVOZPT0LHwmDAkk4DlgEaa6qna/hOUKUHIb5Hd9I9TqcfWByu4rsJ3d6wa VXBDusWXyh0kCrEfbt4roxGKqZSP9BvFXOmDk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=voZD3V6aaL4eDkUBibmIwPwCzqgGa89auwXeR1bBcKU=; b=NiEFV5Ykj4Inl+COCJ7DpL9s6+QY0UrfAVO+KOKzV8iPZPJPk5twk/AMRzxzc6CZSA 8fDfMjewb0fr9SOtDQ88Ikyv48IdwE854y0joMg8NhEIp8s4tavt6K7UTIkgTUgmUst3 ku0Yxs0MiLR3QBzvuIRk5jFZ9U5tl8Izy3CwUfBiXQI6RL/gwBCBAaEzr5ZJywOU+V9S HyZt3eZHsIPuenWMX1mfsJuNh/Szj8BRPMUIrgzyXOqYy38Ck6tTLLed5xq0hUZ/CQja bOYyxi7z6EYyB6y+sC9YUdxix8nFRhZ4pMf9ASF8zUIVc4/Ovch1XiQEH7sARqL4/xbX eL8g== X-Gm-Message-State: APjAAAULy2CuC/tJkcGIV0yk5AjVNQZOlPVs3iK5ZWjyrXFiETNZBQIS r0rooKr4JjbiAIX7RaBl2JR5eJ8uZbaa8oDlRDb/nQ== X-Google-Smtp-Source: APXvYqzzvpxHz0m+ATd0UicqKwZCEBYFtkFF4sig8GMbzp71CzDq0er1wD8Sotw0oK+cCgXGSUAQ6gOvv215mLsInrw= X-Received: by 2002:a2e:89ca:: with SMTP id c10mr63127279ljk.106.1565018630984; Mon, 05 Aug 2019 08:23:50 -0700 (PDT) MIME-Version: 1.0 References: <20180828032952.70F7CB81122@rfc-editor.org> In-Reply-To: From: Patrick Kelsey Date: Mon, 5 Aug 2019 11:23:39 -0400 Message-ID: To: David Benjamin Cc: "" Content-Type: multipart/alternative; boundary="000000000000912db3058f604b4a" Archived-At: Subject: Re: [TLS] [Technical Errata Reported] RFC8446 (5483) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2019 15:23:56 -0000 --000000000000912db3058f604b4a Content-Type: text/plain; charset="UTF-8" Fair point that there are two scalar multiplications involved on either endpoint in the course of the exchange, that what is being referred to in this section of RFC8446 is the first one, and that some readers might find ambiguity with respect to this that could be addressed with a different approach to the correction than I suggested (in my reading of RFC7748, I found 6.1 clear in establishing that it is the results of the first scalar multiplication that are transmitted). If an approach like the one you are suggesting is taken, I recommend replacing "are the K_A and K_B values" with "is the K_A or K_B value", as the content of the public value is one of those and not both. -Pat On Mon, Aug 5, 2019 at 10:46 AM David Benjamin wrote: > There are two scalar multiplications involved. The first, as part of key > generation, indeed passes in a known constant to the u value and outputs > the byte string that goes into the key share. The second, the ECDH > operation itself, passes in the peer key share and results in the shared > secret. In the first call, the key share is the output. In the second, the > key share is the input. > https://tools.ietf.org/html/rfc7748#section-6.1 > > But I agree it's not particularly clear. Perhaps it should have said > something like: > > For X25519 and X448, the contents of the public value are the K_A > and K_B values described in section 6 of [RFC7748]. This is 32 bytes > for X25519 and 56 bytes for X448. > > On Mon, Aug 5, 2019 at 9:43 AM Patrick Kelsey > wrote: > >> I brought this up to Ekr at IETF 105, and he said he hadn't seen this >> particular errata, so here's a bump to the top of the list. >> >> As it's now been about a year that this errata has remained in the >> initial state, I think it might be worth having a look at and advancing to >> the next state, if for no other reason than avoidance of the mistaken >> external impression that there is longstanding uncertainty about a report >> that part of the document says that a private key is to be put on the wire. >> >> -Pat >> >> On Mon, Aug 27, 2018 at 11:30 PM RFC Errata System < >> rfc-editor@rfc-editor.org> wrote: >> >>> The following errata report has been submitted for RFC8446, >>> "The Transport Layer Security (TLS) Protocol Version 1.3". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata/eid5483 >>> >>> -------------------------------------- >>> Type: Technical >>> Reported by: Patrick Kelsey >>> >>> Section: 4.2.8.2 >>> >>> Original Text >>> ------------- >>> For X25519 and X448, the contents of the public value are the byte >>> string inputs and outputs of the corresponding functions defined in >>> [RFC7748]: 32 bytes for X25519 and 56 bytes for X448. >>> >>> Corrected Text >>> -------------- >>> For X25519 and X448, the contents of the public value are the byte >>> string outputs of the corresponding functions defined in [RFC7748]: 32 >>> bytes for X25519 and 56 bytes for X448. >>> >>> Notes >>> ----- >>> Per Section 7.4.2 of this RFC and Section 6 of RFC7748, the byte string >>> inputs to the corresponding ECDH scalar multiplication function are the >>> private key and the u-coordinate of the standard public base point, the >>> former of which of course must not be transmitted and the latter of which >>> is a known constant. >>> >>> >From another perspective, including the byte string inputs in the >>> contents of the public value would contradict the resulting content sizes >>> given at the end of the cited paragraph as well as the statement in Section >>> 7.4.2 that the public key put into the KeyShareEntry is the output of ECDH >>> scalar multiplication function. >>> >>> 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 >>> can log in to change the status and edit the report, if necessary. >>> >>> -------------------------------------- >>> RFC8446 (draft-ietf-tls-tls13-28) >>> -------------------------------------- >>> Title : The Transport Layer Security (TLS) Protocol >>> Version 1.3 >>> Publication Date : August 2018 >>> Author(s) : E. Rescorla >>> Category : PROPOSED STANDARD >>> Source : Transport Layer Security >>> Area : Security >>> Stream : IETF >>> Verifying Party : IESG >>> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > --000000000000912db3058f604b4a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Fair point that there are two scalar multiplications = involved on either endpoint in the course of the exchange, that what is bei= ng referred to in this section of RFC8446 is the first one, and that some r= eaders might find ambiguity with respect to this that could be addressed wi= th a different approach to the correction than I suggested (in my reading o= f RFC7748, I found 6.1 clear in establishing that it is the results of the = first scalar multiplication that are transmitted).

If an approach like the one you are suggesting is taken, I recommend repla= cing "are the K_A and K_B values" with "is the K_A or K_B va= lue", as the content of the public value is one of those and not both.=

-Pat

On Mon, Aug 5, 2019 at 10:46 AM David Benjami= n <davidben@chromium.org>= ; wrote:
There are two scalar multiplications involved. The first, as part= of key generation, indeed passes in a known constant to the u value and ou= tputs the byte string that goes into the key share. The second, the ECDH op= eration itself, passes in the peer key share and results in the shared secr= et. In the first call, the key share is the output. In the second, the key = share is the input.



On Mon, Aug 5, 2019 = at 9:43 AM Patrick Kelsey <pat.kelsey@notforadio.com> wrote:
I brought this up to Ekr at IETF 105, and he said he hadn't seen this= particular errata, so here's a bump to the top of the list.
<= div dir=3D"ltr">
As it's now been about a year that this = errata has remained in the initial state, I think it might be worth having = a look at and advancing to the next state, if for no other reason than avoi= dance of the mistaken external impression that there is longstanding uncert= ainty about a report that part of the document says that a private key is t= o be put on the wire.

-Pat

On Mon, Aug 27, 2018 at = 11:30 PM RFC Errata System <rfc-editor@rfc-editor.org> wrote:
The following errata report has= been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5483

--------------------------------------
Type: Technical
Reported by: Patrick Kelsey <pat.kelsey@notforadio.com>

Section: 4.2.8.2

Original Text
-------------
For X25519 and X448, the contents of the public value are the byte
string inputs and outputs of the corresponding functions defined in
[RFC7748]: 32 bytes for X25519 and 56 bytes for X448.

Corrected Text
--------------
For X25519 and X448, the contents of the public value are the byte
string outputs of the corresponding functions defined in [RFC7748]: 32
bytes for X25519 and 56 bytes for X448.

Notes
-----
Per Section 7.4.2 of this RFC and Section 6 of RFC7748, the byte string inp= uts to the corresponding ECDH scalar multiplication function are the privat= e key and the u-coordinate of the standard public base point, the former of= which of course must not be transmitted and the latter of which is a known= constant.

>From another perspective, including the byte string inputs in the conte= nts of the public value would contradict the resulting content sizes given = at the end of the cited paragraph as well as the statement in Section 7.4.2= that the public key put into the KeyShareEntry is the output of ECDH scala= r multiplication function.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, ple= ase
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party=C2=A0
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC8446 (draft-ietf-tls-tls13-28)
--------------------------------------
Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: The Transport= Layer Security (TLS) Protocol Version 1.3
Publication Date=C2=A0 =C2=A0 : August 2018
Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: E. Rescorla
Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD
Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Transport Layer Se= curity
Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Security
Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000912db3058f604b4a-- From nobody Thu Aug 8 00:27:48 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51B0312010E for ; Thu, 8 Aug 2019 00:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i7VI0K6aD4cq for ; Thu, 8 Aug 2019 00:27:43 -0700 (PDT) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37F1B120105 for ; Thu, 8 Aug 2019 00:27:43 -0700 (PDT) Received: by mail-lf1-x12c.google.com with SMTP id z15so61780256lfh.13 for ; Thu, 08 Aug 2019 00:27:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=yvpgWtsQrfgtuertatQVexOuuJstRjNngG1+80qWEOo=; b=AzRdLgKZUlqk7tWUKP4IviCJm45kneed87F84Pv6UPVEgK4d/EacoXd9dJe0FAFEHB rLGeamYl/DCpwiefKECZJFGH4NCBxKLAv0YhaGNsihvw/QOldzxB58QC0AOsENqQhatP 35iNPbXYPQHcMkVSTV2Jt4JIRTGJjQdCMJnLjF3l5HRgzpPaJVXIUzUFleQ8qmtvwPr6 vq0Kn/MxD5VhziHAIAjll09rVj/AGrKiZ/mgix/dqUMzfemC0BonauYpZjdCMcdjDWZi HFDoEp+rwXtIR+3Hs628Ea4SdAzpGMsC9j9iUi+/QtZYNhpoYGKzfkS0vc0RjM/nxmED Y4uQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=yvpgWtsQrfgtuertatQVexOuuJstRjNngG1+80qWEOo=; b=OZli98WR1YFv8lEqhoJm/oTGV84csEzwgV4Z+n5kgZgkya3YHQREn5uMgwsBxFxFSK Q0lFXI7zAV1DGMlAeDZS6kUkf2Ht3/UC03jL5ji+c4CSADBVvyZkFqoKPWgTOlZ6ezz2 2EidwOKTTJbf+10pzBDnGVMHp02tdaClzfGny0Ql1YzmSnyQZ9I++AKAu75WbOXuddm8 w6ViYNHUwFOx9aUXrVcVP/+Dkyu9nko666iFbZJh9Oj0RY+BEKikqryNNJqadwSuyC7H BAYlPu2bF7HxOkLR9fZRkQaS2tlVEkorq0UdUy+VkWEmkIP8OCvGx44DlQvgkLuvdSTn sXgg== X-Gm-Message-State: APjAAAWQEsM2gYhuCcI5GJapKdXqWHYofRF9W1kDq9B2v7IqR33/6th/ rgNBM4xoxgi0VM/m6aHu9pXNP3T+hbUfMv831zByCQ84mxY= X-Google-Smtp-Source: APXvYqwfK0tBJ/mn2kiSiOjX7kcoRSAmrCdWU1bsFxk81iwdRXdI49Mv6uRK1qtvXzB9CFHeKZtGfuWVnwPjeD1kGks= X-Received: by 2002:ac2:5104:: with SMTP id q4mr8774163lfb.56.1565249260906; Thu, 08 Aug 2019 00:27:40 -0700 (PDT) MIME-Version: 1.0 From: "Stanislav V. Smyshlyaev" Date: Thu, 8 Aug 2019 10:28:06 +0300 Message-ID: To: "" Content-Type: multipart/alternative; boundary="0000000000002e6e41058f95fe8b" Archived-At: Subject: [TLS] Call for independent experts (TLS) for Stage 4 of the PAKE selection process X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 07:27:46 -0000 --0000000000002e6e41058f95fe8b Content-Type: text/plain; charset="UTF-8" Dear TLS WG, I am writing this message on behalf of the CFRG chairs. Currently there is an ongoing PAKE selection process in the CFRG. According to the plan of the PAKE selection process, the CFRG chairs have selected a number of PAKE-related topics that require independent reviews from experts deeply involved in several particular areas of IETF work: TLS and IPsec protocols, constrained environments and privacy. The chairs would like to announce the call for reviewers, who will be asked to prepare their reviews regarding one or more of the following topics about the nominated PAKEs: *- Convenience for usage within/together with TLS 1.3 Handshake.* - Convenience for usage within/together with IKEv2. - Convenience for usage in M2M/IoT protocols (i.e., with corresponding constrains on hardware). - Privacy considerations (e.g., recommendations to prevent user enumeration). The experts who would like to volunteer to do such a review are kindly asked to choose: 1) which topics from the provided list will be considered by them; 2) whether they could prepare their reviews for - all four balanced PAKEs, - all four augmented PAKEs or - all eight candidate PAKEs. We ask each of the expert to prepare reviews for all PAKEs (or at least all balanced/all augmented ones) to be sure that each of the PAKEs will be studied from the same points of view. *The call for reviewers will last until the 15th of August. Please send a message to cfrg@irtf.org or cfrg-chairs@ietf.org , if you could help. * Deadline for the reviews is 15th of September. The reviews will later be provided to Crypto Review Panel experts, who will prepare their overall reviews during Stage 5. Best regards, Stanislav Smyshlyaev, CFRG Secretary --0000000000002e6e41058f95fe8b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear TLS WG,

I am writing this message on behalf of= the CFRG chairs.

Currently there is an ongoing PAKE sel= ection process in the CFRG.
According to the plan of the PAKE sel= ection process, the CFRG chairs have selected a number of PAKE-related topi= cs that require independent reviews from experts deeply involved in several= particular areas of IETF work: TLS and IPsec protocols, constrained enviro= nments and privacy.=C2=A0

The chairs would like to announce the call= for reviewers, who will be asked to prepare their reviews regarding one or= more of the following topics about the nominated PAKEs:
- Convenienc= e for usage within/together with TLS 1.3 Handshake.
- Convenience fo= r usage within/together with IKEv2.
- Convenience for usage in M2M/IoT p= rotocols (i.e., with corresponding constrains on=C2=A0hardware).
- Priva= cy considerations (e.g., recommendations to prevent user enumeration).
<= br>The experts who would like to volunteer to do such a review are kindly a= sked to choose:
1) which topics from the provided list will be considere= d by them;
2) whether they could prepare their reviews for=C2=A0
- al= l four balanced PAKEs,
- all four augmented PAKEs or
- all eight cand= idate PAKEs.

We ask each of the expert to prepare reviews for all PA= KEs (or at least all balanced/all augmented ones) to be sure that each of t= he PAKEs will be studied from the same points of view.

The call f= or reviewers will last until the 15th of August. Please send a message to= =C2=A0cfrg@irtf.org=C2=A0or cfrg-chairs@ietf.org, if you could help.= =C2=A0
Deadline for the reviews is 15th of September.

= The reviews will later be provided to Crypto Review Panel experts, who will= prepare their overall reviews during Stage 5.

Best rega= rds,
Stanislav Smyshlyaev,
CFRG Secretary
--0000000000002e6e41058f95fe8b-- From nobody Thu Aug 8 08:30:57 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B102812017A for ; Thu, 8 Aug 2019 08:30:56 -0700 (PDT) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=EeZZCgU+; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=SDr3TF0V Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ty74qeOH61f3 for ; Thu, 8 Aug 2019 08:30:54 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D20EE1200FD for ; Thu, 8 Aug 2019 08:30:54 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 0AB2E21951 for ; Thu, 8 Aug 2019 11:30:54 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Thu, 08 Aug 2019 11:30:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=p83ekSZutiK3IGD+0YP/QRqmznm9U9d 4BlYU2YY7QTw=; b=EeZZCgU+6y0zS+bGQGHbrAO5wks3P0i2oHG/+RMPuCBFWa9 iTiyx4XwrECxWNcB88Ebh/47kHAPK/fSEr27oi1/PpXHjqHsZAAURToZUJ7M3S97 oNtAtNts3IUXeqs+XF3/Bfo1yWKbt5teu/vZVdPof+Z/aDoB5TP8PFQ1NiksEOlU HsWxNTDA8ZximCJvTRoztXkOLRbNtzpt5zZlJwdTCWHWnSnzP9cyYqZrrXe5jz6n XYOjoKERxr2arfDrGo+zMDMcMJgNzT09RJdVoWjLDLSPyKbhf98PSAGUOWwUyqdQ 0eLEXplCLsk4pPykpiPh1jH3cUiI/oK80aCN6bA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=p83ekS ZutiK3IGD+0YP/QRqmznm9U9d4BlYU2YY7QTw=; b=SDr3TF0VRVzINYcyFc1TK8 tB7mjcBONlBs6LhI4lMxlhKHzoGjQlP0f0Vg+bbqziaPUuNbuFussOhcb//vz8u/ Iv5KmuwhnZ6OmUggMy59r6BMgWu1r0PjhF8nDlz6PdlY3LRAd8drUGDQUyvEUVmf IgrztA67mKlUkOxr4zicfju3boSbjNEbF5YqEOvUwbHYdYZaIXIOPRnbkDiFC7rk VTnGuC5Sx57AwG8zwNGZHTdfHqJdWxKOYD9SeIL1GiPFvFOTflI6cCllnoAV8QHX e5+Ss/sktWjWhdW50j8gMqXcQXe2g/J9GcZ0HBMr/YWIgx+x3AMPlXpVrxENwq8Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudduhedgledtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgif sehhvggrphhinhhgsghithhsrdhnvghtqeenucffohhmrghinhepihgvthhfrdhorhhgne curfgrrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrphhinhhgsghithhsrdhnvght necuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 721E93C00A2; Thu, 8 Aug 2019 11:30:53 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-808-g930a1a1-fmstable-20190805v2 Mime-Version: 1.0 Message-Id: <27bfd393-a34b-4596-9e2e-6ad2fa099f92@www.fastmail.com> In-Reply-To: References: Date: Thu, 08 Aug 2019 08:30:52 -0700 From: "Christopher Wood" To: "TLS@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [TLS] Adoption call for draft-lvelvindron-tls-md5-sha1-deprecate X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 15:30:57 -0000 The adoption call is now complete. Given the support we heard at IETF 105 and seen on the list, we have consensus to adopt this as a working group item. Authors, please submit a new version as draft-ietf-tls-md5-sha1-deprecate. Thanks, Chris, on behalf of the chairs On Wed, Jul 24, 2019, at 5:49 AM, Christopher Wood wrote: > At TLS@IETF105, there was interest in the room to adopt > draft-lvelvindron-tls-md5-sha1-deprecate as a WG item. The draft can be > found here: > > https://datatracker.ietf.org/doc/draft-lvelvindron-tls-md5-sha1-deprecate/ > > This email starts the call for adoption. It will run until August 7, > 2019. Please indicate whether or not you would like to see this draft > adopted. > > Best, > Chris, on behalf of the chairs > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Thu Aug 8 08:31:56 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D98F12021D for ; Thu, 8 Aug 2019 08:31:51 -0700 (PDT) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=o4zzWeMG; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=k0SRhCFw Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIvIakrLAy44 for ; Thu, 8 Aug 2019 08:31:48 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F03051201EE for ; Thu, 8 Aug 2019 08:31:47 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 1CDF8209E5 for ; Thu, 8 Aug 2019 11:31:47 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Thu, 08 Aug 2019 11:31:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=RFDy+xd7zmyYoW92zKxEJw+N9/M7u7A 9yEfmRmkhgcQ=; b=o4zzWeMGHvyAvKMNLjzM07K4zT1vY1VCU0XQC8kKU/StGVo 17ALegIGf/9kmDnosFEnEdLtcyjotPb3GPA+4voRsvzklkINzlURY0OX94gVBLv7 X9zDNj8cDZrAzJVGwRDip4kvbXboteZlXPHc6vbQuPOM5ZDz8gR/epc5k//zk6KF CiEBDsOFdoTr55P6P6K56QTv8LaL7ikck+GOOt3iUb7nmptpcVJBwZKbdTrB+2Qo B6tv0rZ+Ew3kLLhOiKjcmGeMPp+uS7Ubxk7CRn+SYJBE3LpXghh6NLrMts8k7vBh P9eirP+yv89HWSgEIwTVQFm/OJ84eskRV3SiBwA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=RFDy+x d7zmyYoW92zKxEJw+N9/M7u7A9yEfmRmkhgcQ=; b=k0SRhCFw3TGmE0+1KGVGqJ Gz8KozFLptB82L14aGC5y5FiQoya3GfEL5twDzYm0XYplI6lwVDQCXpioxRPVE9D vqOKcypM9lsFqVvLr3z/CGMn85bf6RBJ31/eC5vd8VFmSmVJiiUkqAnth/VpJu+P /XBYbn4hTixpfnMr0+3nAgdDfF50GDL9I0NegMLeV3L1K+y+8+Q3YnUIdvUV61yb fn3hccxtBOQzZwv6Pz/upKubHJ2o1yjlxIv2oT7BiB4duRFM2NlEbOcssG1Fu6LM lYlTTAHwBS0F2wO2rOzvkns3/rjp2MIfljFntg/8BmZa7wA3hoQGazUOpGHmIZkQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudduhedgledtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgif sehhvggrphhinhhgsghithhsrdhnvghtqeenucffohhmrghinhepihgvthhfrdhorhhgne curfgrrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrphhinhhgsghithhsrdhnvght necuvehluhhsthgvrhfuihiivgepud X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id B844E3C00A1; Thu, 8 Aug 2019 11:31:46 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-808-g930a1a1-fmstable-20190805v2 Mime-Version: 1.0 Message-Id: <0dbdd45d-8a8f-47b9-bfe6-fffb136cab43@www.fastmail.com> In-Reply-To: References: <01a21cca-c0b1-4b40-9add-0ea303d0083c@www.fastmail.com> Date: Thu, 08 Aug 2019 08:31:46 -0700 From: "Christopher Wood" To: "TLS@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [TLS] Adoption call for draft-nir-tls-tlsflags X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 15:31:55 -0000 The adoption call is now complete. Given the support seen on the list, we have consensus to adopt this as a working group item. Yoav, please submit a new version as draft-ietf-tls-tlsflags. Thanks, Chris, on behalf of the chairs On Wed, Jul 24, 2019, at 8:03 AM, Nick Sullivan wrote: > I am in favor of adoption. > > On Wed, Jul 24, 2019 at 8:47 AM Christopher Wood > wrote: > > At TLS@IETF105, there was interest in the room to adopt draft-nir-tls-tlsflags as a WG item. The draft can be found here: > > > > https://datatracker.ietf.org/doc/draft-nir-tls-tlsflags/ > > > > This email starts the call for adoption. It will run until August 7, 2019. Please indicate whether or not you would like to see this draft adopted. > > > > Best, > > Chris, on behalf of the chairs > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Mon Aug 12 10:48:57 2019 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 8F4DC120FF9; Mon, 12 Aug 2019 10:48:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <156563213549.17893.514258464688769886@ietfa.amsl.com> Date: Mon, 12 Aug 2019 10:48:55 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-tlsflags-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2019 17:48:56 -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 WG of the IETF. Title : A Flags Extension for TLS 1.3 Author : Yoav Nir Filename : draft-ietf-tls-tlsflags-00.txt Pages : 6 Date : 2019-08-12 Abstract: A number of extensions are proposed in the TLS working group that carry no interesting information except the 1-bit indication that a certain optional feature is supported. Such extensions take 4 octets each. This document defines a flags extension that can provide such indications at an average marginal cost of 1 bit each. More precisely, it provides as many flag extensions as needed at 4 + the order of the last set bit divided by 8. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-tlsflags-00 https://datatracker.ietf.org/doc/html/draft-ietf-tls-tlsflags-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Aug 12 15:39:50 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23D8F120F42 for ; Mon, 12 Aug 2019 15:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nd4jKnAYPj-a for ; Mon, 12 Aug 2019 15:39:45 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6358612080C for ; Mon, 12 Aug 2019 11:25:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id CF28145BE7 for ; Mon, 12 Aug 2019 21:25:21 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id YdwsCyC6F4I7 for ; Mon, 12 Aug 2019 21:25:21 +0300 (EEST) Received: from LK-Perkele-VII (87-100-246-37.bb.dnainternet.fi [87.100.246.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 538042309 for ; Mon, 12 Aug 2019 21:25:20 +0300 (EEST) Date: Mon, 12 Aug 2019 21:25:19 +0300 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20190812182519.GA455391@LK-Perkele-VII> References: <156563213549.17893.514258464688769886@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <156563213549.17893.514258464688769886@ietfa.amsl.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-tlsflags-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2019 22:39:48 -0000 On Mon, Aug 12, 2019 at 10:48:55AM -0700, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Transport Layer Security WG of the IETF. > > Title : A Flags Extension for TLS 1.3 > Author : Yoav Nir > Filename : draft-ietf-tls-tlsflags-00.txt > Pages : 6 > Date : 2019-08-12 > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tls-tlsflags-00 > https://datatracker.ietf.org/doc/html/draft-ietf-tls-tlsflags-00 Two things: 1) uint8 flags<0..31>; That adds an extra byte that is not technically necressary (because extensions have lengths anyway) and limits number of flags to 248 (which might be enough). And I do not think the length of flags field can be 0 (if it would be, one could just omit the extension). 2) I think the bit order within octets should be reversed That is, pack flags so that 0 is LSB of first octet, 7 is MSB of first octet, 8 is LSB of second octet and so on. Then one can read status flags by index with code like: fn read_flag(flags: &[u8], idx: usize) -> bool { *flags.get(idx/8).unwrap_or(&0) >> idx%8 & 1 != 0 } (That code will also happily handle out-of-array flags by reading them as false.) -Ilari From nobody Mon Aug 12 15:43:45 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 392D412003E for ; Mon, 12 Aug 2019 15:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTq2vI5MhkJZ for ; Mon, 12 Aug 2019 15:43:41 -0700 (PDT) Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4340E1221C2 for ; Mon, 12 Aug 2019 10:52:01 -0700 (PDT) Received: by mail-wm1-x332.google.com with SMTP id p77so504380wme.0 for ; Mon, 12 Aug 2019 10:52:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=O0MMzW9d8ADXtUv47mqV9BGxCDuqYiosZtPy/Olv9fU=; b=UcdtkJ/pBmDkPkRLF4+t8E04IEbwTmQuZWkDGdFO4qxtYumKzaGk7MFUpLacND097I cKLnOtfqIz8pfq5kHa57P3+tAzN5IdopBJLUBQinTz0wQy/hur82N9dV+knNoN/ic6Jm jCenfWMik0GF7OdjlQVkAx/cZMgMLPB96p9U+qGXC0catrpBeM25RDMcECJg52IjuuMT XRoSt6SoBMExnogCi7u6bLk086kYpfdDRaHkdxRP3I4oMT5jlecei/SxfG3Ua34Sxbo2 6okCjz+msf7qUhJJUBJOoYzvt3PafS1PSIoSwjTY0a7XGxGkZM2EHdlWvMt5JoQsGTwN WxCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=O0MMzW9d8ADXtUv47mqV9BGxCDuqYiosZtPy/Olv9fU=; b=WfXFtTeP8bnHZqjnwADDz0gwiMwHfwWnly4MVOXsCqiMUYe/GEn1nJuLkkcULDf/0w k5wHBqiaDAyND8lzM0cC3gc6OchHM49Q7aNLntN/tlR9bSA9EN/NoUreslxXFO4HtAqR Lno1DS6bbC5qE7kUekmg1bcY/IvhC0VgYOrQUh9/lE06ufDpF1aN4VsMo2PUdFHe9Ped tNjCqamwlguI0TpScSjemyU5+dSBMYKLlgapXnYlKnejISbx7UtjryMh4fmHlW43IPA1 1GSKT1+Uo/uBPASq1gcZ4XoYZfFC1QwY5Wbhg/kD0yDKb3EyYInUV1TDbZQqtyVwyHzy jYrQ== X-Gm-Message-State: APjAAAX+9gjyzh+8Zyq/3LKavZx3LHAZnH1XpnBJJW2pBQ3VrlEtAgRh bXl3ocxuRQVOibXDXPrUK1N0UgSVQ2g= X-Google-Smtp-Source: APXvYqxRrUZcsCql17cRcGXX1D2SRS7cBQ4m0pc9Ja/soazVlzb3J3Uc/S0wHL+pomfFrQ8kvMGO4g== X-Received: by 2002:a1c:1f4e:: with SMTP id f75mr457126wmf.137.1565632319328; Mon, 12 Aug 2019 10:51:59 -0700 (PDT) Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id v3sm9105261wrq.34.2019.08.12.10.51.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Aug 2019 10:51:58 -0700 (PDT) From: Yoav Nir Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 12 Aug 2019 20:51:56 +0300 References: <156563213549.17893.514258464688769886@ietfa.amsl.com> To: "" In-Reply-To: <156563213549.17893.514258464688769886@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-tlsflags-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2019 22:43:43 -0000 Hi. This is an almost exact copy of draft-nir-tls-tlsflags-02. Since that = is the draft that was adopted, I submitted at as the -00 version. I will reply to comments that came up during the adoption call later = today or tomorrow, but feel free to comment some more. Yoav > On 12 Aug 2019, at 20:48, 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 WG of the = IETF. >=20 > Title : A Flags Extension for TLS 1.3 > Author : Yoav Nir > Filename : draft-ietf-tls-tlsflags-00.txt > Pages : 6 > Date : 2019-08-12 >=20 > Abstract: > A number of extensions are proposed in the TLS working group that > carry no interesting information except the 1-bit indication that a > certain optional feature is supported. Such extensions take 4 = octets > each. This document defines a flags extension that can provide such > indications at an average marginal cost of 1 bit each. More > precisely, it provides as many flag extensions as needed at 4 + the > order of the last set bit divided by 8. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tls-tlsflags-00 > https://datatracker.ietf.org/doc/html/draft-ietf-tls-tlsflags-00 >=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 Aug 13 01:03:28 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE9C1200B3 for ; Tue, 13 Aug 2019 01:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.876 X-Spam-Level: X-Spam-Status: No, score=-0.876 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vriP0gaseNp4 for ; Tue, 13 Aug 2019 01:03:24 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-oln040092004028.outbound.protection.outlook.com [40.92.4.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B52B3120074 for ; Tue, 13 Aug 2019 01:03:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZAU4XegveipXY/I3xlQXbPsG5o24H7F+6NkD0EH5SRVJWVVC7qAmbPhY8LiBDyGYB5PPkQLL6qake/2j+aNOWFhe+A0vEnI1EeMso8Wby/BczulRGIJGuRBI406tjtwCfwscIwi7v7MBFDKp9xOor4MhT1F+dbf8Zp4wdqx3rvHzPWHE1C8+qu+hZAIovjHJBPwXzgXO9yqc+17Du0hqtFGPaeqoZZbz8/PJV8gMe8kS7tjmlVe0GiI1xgRXoIMZGAPPJCZt/vq5VB/pj2QV+c8YbWxx8PtgZJ9aqUqimFwgTYXsWL8htvzxD+YlqU2Qq3lmkssjeKvuKn3f3dxdJw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3LKuvMLgw5joW+vsjXpbm/6FqPloyR413LxWBbu3mI0=; b=OLld2GjphWB2szw97H2nqAdauaJ37oMklZF+YyRZ2ZPPGNVdlGxMPj3wft2Gi+FWPec6mDwtbALMpfGe57IeX0OVPM2FXADxVxQVxucfcd3dTd49NhA5ponoPowk+Cbyb3ASnz7SMcp07oFN4J3oLSYHCRwy8pssxtxaXWsj5MQ20bIUFolzOXbcurq5BIfCdKp8QwLV3ZXP7gieYMP8YA5FFvpBW2AcwLkSXePmVU6azF9Geaq+3/dNR7BcrnqIA8sOQOpwJoWLZmRoB5LZ5SNKCmZnaEGc17Ua4zotNHbHH2GoUeVLLGPhrAZRooyyiVdVdCyb0Rs9yEA78o9F3Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3LKuvMLgw5joW+vsjXpbm/6FqPloyR413LxWBbu3mI0=; b=Zyx8OYKpUoznyalqRzpigHferKNvyRdJe1bWt/YqiMRWxWNnGtQMjzpSBj7M0tGscHTFJjRQk3ynLfZ9Z+HE1FDs6BxVuaykDvFwbbEcPR2yiMPtiPl2xOWqxUfx5n7Ns9Dket15GZTtK/UpprJc68V9qvAXD8Ik0IvcMLzsyWwMPaa9T+Hi9voHKTns2V4BnqGdMT1josQC7qBQqTrn7+bT1eW97yXfQUWZyBDy3c+uqO8tkfA9MsDsX1G+jJUnx+SVq25wLPJV74t8RnwWpVJdTimmRUwmaIZHsXcztr0j+yI13t001q2QYyljzJPhZ3j82p+fhxQqT8qbtu+lTQ== Received: from BL2NAM02FT057.eop-nam02.prod.protection.outlook.com (10.152.76.60) by BL2NAM02HT013.eop-nam02.prod.protection.outlook.com (10.152.77.51) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2157.15; Tue, 13 Aug 2019 08:03:23 +0000 Received: from MWHPR18MB1086.namprd18.prod.outlook.com (10.152.76.51) by BL2NAM02FT057.mail.protection.outlook.com (10.152.77.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2157.15 via Frontend Transport; Tue, 13 Aug 2019 08:03:23 +0000 Received: from MWHPR18MB1086.namprd18.prod.outlook.com ([fe80::64da:f228:d2fd:a60e]) by MWHPR18MB1086.namprd18.prod.outlook.com ([fe80::64da:f228:d2fd:a60e%12]) with mapi id 15.20.2157.022; Tue, 13 Aug 2019 08:03:23 +0000 From: Yuhong Bao To: "tls@ietf.org" Thread-Topic: Compact TLS Thread-Index: AQHVUa2J54h2scsI1EeN5GyY7oMs0A== Date: Tue, 13 Aug 2019 08:03:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:637144563A2DA4DD2205A7BBBA8E67EFE6F45EAC8708D3C6659C18ABDFC5A63C; UpperCasedChecksum:D52B1AA919FDA1A0F959B2EAB55ED0D9E8794FADF731462138B79B349E99F53C; SizeAsReceived:6632; Count:41 x-tmn: [aiS0oDHe58dwlsr+Hl3glYVcj5IB4ovTsEi4BaEs9yUdwsfOOTwMucfpOo/4dUd+] x-ms-publictraffictype: Email x-incomingheadercount: 41 x-eopattributedmessage: 0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(5050001)(7020095)(20181119110)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031322404)(2017031323274)(2017031324274)(1601125500)(1603101475)(1701031045); SRVR:BL2NAM02HT013; x-ms-traffictypediagnostic: BL2NAM02HT013: x-microsoft-antispam-message-info: KAh9SvFuYI0x21C4emfhxe53g8oMh8Se9hALVYs9Bs+gGIqq8B6vYk1Dhd/TX6PxwR8aoQgAOYhx9VPe7X3nZfxFRv219vdNPXc4a3wPBrl5cFnKkYYN/fCLc/ay1xrdsQImJ4Vd9MWU1OtjaqbdKXjsCNqpqY79W/vUqtt7ca+eCOKu2EKbRydWr9aPMR89 x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: cd12d0b5-6ccb-4c5e-a49d-08d71fc4b6b7 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Aug 2019 08:03:23.4834 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2NAM02HT013 Archived-At: Subject: [TLS] Compact TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2019 08:03:26 -0000 I hope everyone knows about draft-rescorla-tls-ctls-01 by now.=0A= It reminds me how I was disliking the middlebox workarounds during the TLS = 1.3 standardization process.= From nobody Tue Aug 13 17:59:40 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16997120805 for ; Tue, 13 Aug 2019 17:59:17 -0700 (PDT) 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7RMNpj1X48aQ for ; Tue, 13 Aug 2019 17:59:15 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23E33120072 for ; Tue, 13 Aug 2019 17:59:15 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id x7E0uqc3022584; Wed, 14 Aug 2019 01:59:14 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=uDGekTQ7yLhMpTyyw5+JuyCb8EN2u27V8R6g+GdunI0=; b=e+4S1Txu/6PfIru4VBX0TuQbA8tHBwfM6T1a5LGB9QHAN41dV3SQCA1uJENL4rN949eq 6S5fdpaaDoGqvge6h6JSrzttmJn8FrXjW6wW+e7Bfq3dZvDqsR4gkhb4tpad2hq9rHfE UixXltLhzRS73MCmFV/fWP+5HQxNVUO6YAYaQpXg8JexUhzk7pFrFk8U+0HF58w4cmZM npHLmMoAnrEpelNQf5WHKKaF8i8VSREsvcezdG9kYGvyFNLbvjOXCt1C+XopPiVoLV3L ZFNvEcc8ctw5gKcLLnfmM9D+FzbAHGwA0/8kmu7YLGwnKImj//BsLWFtk4BEQydOvp2I ng== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2ubf8mxmxs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Aug 2019 01:59:13 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x7E0leeN011313; Tue, 13 Aug 2019 20:59:13 -0400 Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint2.akamai.com with ESMTP id 2u9s8wex4n-1; Tue, 13 Aug 2019 20:59:12 -0400 Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id D07CD20B1D; Wed, 14 Aug 2019 00:59:12 +0000 (GMT) Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1hxhd9-0006WF-LG; Tue, 13 Aug 2019 19:59:11 -0500 Date: Tue, 13 Aug 2019 19:59:11 -0500 From: Benjamin Kaduk To: Ilari Liusvaara Cc: tls@ietf.org Message-ID: <20190814005910.GC30400@akamai.com> References: <156563213549.17893.514258464688769886@ietfa.amsl.com> <20190812182519.GA455391@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190812182519.GA455391@LK-Perkele-VII> User-Agent: Mutt/1.5.24 (2015-08-30) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-13_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908140005 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:5.22.84,1.0.8 definitions=2019-08-13_07:2019-08-13,2019-08-13 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 lowpriorityscore=0 malwarescore=0 mlxlogscore=988 impostorscore=0 mlxscore=0 priorityscore=1501 suspectscore=0 adultscore=0 phishscore=0 bulkscore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1906280000 definitions=main-1908140007 Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-tlsflags-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2019 00:59:27 -0000 On Mon, Aug 12, 2019 at 09:25:19PM +0300, Ilari Liusvaara wrote: > On Mon, Aug 12, 2019 at 10:48:55AM -0700, internet-drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > This draft is a work item of the Transport Layer Security WG of the IETF. > > > > Title : A Flags Extension for TLS 1.3 > > Author : Yoav Nir > > Filename : draft-ietf-tls-tlsflags-00.txt > > Pages : 6 > > Date : 2019-08-12 > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-tls-tlsflags-00 > > https://datatracker.ietf.org/doc/html/draft-ietf-tls-tlsflags-00 > > Two things: > > > 1) uint8 flags<0..31>; > > That adds an extra byte that is not technically necressary (because > extensions have lengths anyway) and limits number of flags to 248 > (which might be enough). > > And I do not think the length of flags field can be 0 (if it would I think you need to send it in at least one protocol "response", to confirm support for the extension, even if none of the flags offered require confirmation/echo individually. -Ben From nobody Tue Aug 13 18:03:51 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE4A8120018 for ; Tue, 13 Aug 2019 18:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xp1lYoZCVNJk for ; Tue, 13 Aug 2019 18:03:45 -0700 (PDT) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84D1512002F for ; Tue, 13 Aug 2019 18:03:45 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id c19so78109676lfm.10 for ; Tue, 13 Aug 2019 18:03:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IIHlv+PEYvwFgja+Wr6eZRjOBRsXmbaaXEk5mbokhS0=; b=lXmxx2iYU5NVu8sXu1OdnAs7CGxRTs1XnpdzaxCLeHycx8VgFoYNYR9esEVuoyKSt0 EYmwwypmxwfs1Iy7Bz1pP7WHEMO6Jcl8XGS+QaoQMO3eTVB3pDQHlMHBX9vA2Oj9GLKK uPpUsvPm21pMM4d5kRiZD+rihhvrDW1ej47pJ7xUGjhm+M49fGyzPtKUYd2v6FWSfm1S wEaBsogQCv70fpc3xGqfjuIeQbjSv957mdkqkAZCUNWH6vdm1ppgXefRUp0KgJAGOUJH DCpWlr2gUyIwgW0mxIsSkdrkJDzjxeSJqL8wYRlxLieNl09cuWfyJn39vwprUpjXlZEH BvTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IIHlv+PEYvwFgja+Wr6eZRjOBRsXmbaaXEk5mbokhS0=; b=Qcd+HIUv+n/BJeCxkpMK3kA0qMYVSMSDwY75IwXP76Yfmlh/6BNSSBf8KQgPouNjd4 Es5o0DSxi1xLSeGS7IRFPFjgv4dBUu3e5kRXhl7+rfghI8FCZK7H7/tWh5T/OssjU4xJ qtcbzZmYy25Nj0H2bHhD6sFcyY/o4CCPQpmXVBsBCqLvManZvlj9577NlJAKDNnWrbqI Vb8Rbm7BRNmU6iSJL/54A6C+tZjqOH8F80FV3T4iZ/n1MBoK9holkk/lq06apPU2xw9I wKPLyN5apncZz9keEVxv9MD6uvEnaQCqxkipg8mEpZKBAhKC2BaKlR2/4KGezK4WZVaa rxKw== X-Gm-Message-State: APjAAAUyPJ7U548KI3bF3BUxQPAImevTa1P5ySnxELByOUhSjPxPh2pj /5ViAbpahpzvLmFMI7VoepaRViehEjdBQbbWr1o= X-Google-Smtp-Source: APXvYqw5Hvhcdo9sGPG4rChTaThA6HP48E7LktTBi+NBct9x0lojG5C7zwovWMsZHy2oKzLi1a3mRTA1xkogMomWZTs= X-Received: by 2002:a05:6512:78:: with SMTP id i24mr8185093lfo.55.1565744623725; Tue, 13 Aug 2019 18:03:43 -0700 (PDT) MIME-Version: 1.0 References: <156563213549.17893.514258464688769886@ietfa.amsl.com> <20190812182519.GA455391@LK-Perkele-VII> <20190814005910.GC30400@akamai.com> In-Reply-To: <20190814005910.GC30400@akamai.com> From: Watson Ladd Date: Tue, 13 Aug 2019 18:03:32 -0700 Message-ID: To: Benjamin Kaduk Cc: Ilari Liusvaara , TLS List Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-tlsflags-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2019 01:03:49 -0000 On Tue, Aug 13, 2019 at 6:00 PM Benjamin Kaduk wrote: > > On Mon, Aug 12, 2019 at 09:25:19PM +0300, Ilari Liusvaara wrote: > > On Mon, Aug 12, 2019 at 10:48:55AM -0700, internet-drafts@ietf.org wrote: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > This draft is a work item of the Transport Layer Security WG of the IETF. > > > > > > Title : A Flags Extension for TLS 1.3 > > > Author : Yoav Nir > > > Filename : draft-ietf-tls-tlsflags-00.txt > > > Pages : 6 > > > Date : 2019-08-12 > > > > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/ > > > > > > There are also htmlized versions available at: > > > https://tools.ietf.org/html/draft-ietf-tls-tlsflags-00 > > > https://datatracker.ietf.org/doc/html/draft-ietf-tls-tlsflags-00 > > > > Two things: > > > > > > 1) uint8 flags<0..31>; > > > > That adds an extra byte that is not technically necressary (because > > extensions have lengths anyway) and limits number of flags to 248 > > (which might be enough). > > > > And I do not think the length of flags field can be 0 (if it would > > I think you need to send it in at least one protocol "response", to > confirm support for the extension, even if none of the flags offered > require confirmation/echo individually. I'm not sure this is the case: if in the future we define flags, then what is the difference between not understanding any flag and not understanding the extension? > > -Ben > > _______________________________________________ > 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 Tue Aug 13 18:12:08 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82B3C120018 for ; Tue, 13 Aug 2019 18:12:06 -0700 (PDT) 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vP-XLEl4C0aS for ; Tue, 13 Aug 2019 18:12:04 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D854212000E for ; Tue, 13 Aug 2019 18:12:04 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id x7E1BgLq016973; Wed, 14 Aug 2019 02:12:03 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=TwuBSCtpmRm/aeANm1JqYCOv6s8Z9e4cGN6WtYOIl28=; b=CS8JxMjaOVl32g4HkOPes31m5hbizOhhiF7rFqxouuPjniOTbWX3yaAnQoO/wCyXfniz RFwcel9kV3NVAo8f+Zdbe9O9wzvl4WbOZaDLzzHTsvqpFryh46aEaZifb7C0WWcKsx0n 2F59QBcyUKZCRUQS50AUYPIUlEXiE4+Cd7uKfRnV9dpDwi9M2onZDmypYAl6Y7V03drf AmJKapUwJyiXqG+be5y9bUle1C5jjl5NHe/cKYZLugKmAJe4c4Aa7cpHWuUqVU2IhfyC wJicT83ffdAUFbBcErUV6tOwQC7pE1MsXIgXMBJNBfFGAFOkQNHtmA08rD2lRnfG0aow lQ== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2ubf8negsa-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Aug 2019 02:12:03 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x7E12Qqa021906; Tue, 13 Aug 2019 21:12:02 -0400 Received: from prod-mail-relay11.akamai.com ([172.27.118.250]) by prod-mail-ppoint2.akamai.com with ESMTP id 2u9s8weyg2-1; Tue, 13 Aug 2019 21:12:02 -0400 Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id F16ED1FC0D; Wed, 14 Aug 2019 01:12:01 +0000 (GMT) Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1hxhpY-0006XE-Hp; Tue, 13 Aug 2019 20:12:00 -0500 Date: Tue, 13 Aug 2019 20:12:00 -0500 From: Benjamin Kaduk To: Watson Ladd Cc: Ilari Liusvaara , TLS List Message-ID: <20190814011159.GE30400@akamai.com> References: <156563213549.17893.514258464688769886@ietfa.amsl.com> <20190812182519.GA455391@LK-Perkele-VII> <20190814005910.GC30400@akamai.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) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-13_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908140008 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:5.22.84,1.0.8 definitions=2019-08-13_07:2019-08-13,2019-08-13 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 clxscore=1015 impostorscore=0 lowpriorityscore=0 suspectscore=0 phishscore=0 mlxscore=0 bulkscore=0 spamscore=0 priorityscore=1501 mlxlogscore=999 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1906280000 definitions=main-1908140010 Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-tlsflags-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2019 01:12:07 -0000 On Tue, Aug 13, 2019 at 06:03:32PM -0700, Watson Ladd wrote: > On Tue, Aug 13, 2019 at 6:00 PM Benjamin Kaduk wrote: > > > > On Mon, Aug 12, 2019 at 09:25:19PM +0300, Ilari Liusvaara wrote: > > > On Mon, Aug 12, 2019 at 10:48:55AM -0700, internet-drafts@ietf.org wrote: > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > > This draft is a work item of the Transport Layer Security WG of the IETF. > > > > > > > > Title : A Flags Extension for TLS 1.3 > > > > Author : Yoav Nir > > > > Filename : draft-ietf-tls-tlsflags-00.txt > > > > Pages : 6 > > > > Date : 2019-08-12 > > > > > > > > > > > > The IETF datatracker status page for this draft is: > > > > https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/ > > > > > > > > There are also htmlized versions available at: > > > > https://tools.ietf.org/html/draft-ietf-tls-tlsflags-00 > > > > https://datatracker.ietf.org/doc/html/draft-ietf-tls-tlsflags-00 > > > > > > Two things: > > > > > > > > > 1) uint8 flags<0..31>; > > > > > > That adds an extra byte that is not technically necressary (because > > > extensions have lengths anyway) and limits number of flags to 248 > > > (which might be enough). > > > > > > And I do not think the length of flags field can be 0 (if it would > > > > I think you need to send it in at least one protocol "response", to > > confirm support for the extension, even if none of the flags offered > > require confirmation/echo individually. > > I'm not sure this is the case: if in the future we define flags, then > what is the difference between not understanding any flag and not > understanding the extension? Nothing -- the difference is between understanding the "please frobnitz my baddle" flag and not understanding it (or the extension, for that matter). If "please frobnitz my baddle" is defined such that it appears in the ClientHello and if the server supports the extension, the server has the option to send a Thwarp handshake message to the client at any time post-handshake if the server detects its imminent demise, then the client that observes "I didn't get a Thwarp" cannot distinguish between "the server doesn't support the extension" and "the server supports the extension but is unaware of an imminent demise". Does that help? -Ben From nobody Tue Aug 13 18:24:11 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1870012001B for ; Tue, 13 Aug 2019 18:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSGvbQvui7FJ for ; Tue, 13 Aug 2019 18:24:08 -0700 (PDT) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C310120018 for ; Tue, 13 Aug 2019 18:24:07 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id j17so24094634lfp.3 for ; Tue, 13 Aug 2019 18:24:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SuhSRqcVLnHn4SQSoJuq0LF243s7I1feZyh7OZ3YiH0=; b=cNMiJkUfptbh29v5S8iskgUU/qDGOB1fG62ncuTIO0eB8ne0ZRyX51L1Ly8yGvPZXz pFN7wqXc6LoQzHYaiKyZeoMfkHvg0xFa296j41jYokzjH4eq2cD0GaFggvkWvAAETm/6 deTxF7sm3OkjCQxnA2mhtGT7d5eawmK/vVWqD2X0hlods0IxYjGEBsLIVm9SeFC372Sz 5SHP8stenGQsQVA45cYCUiZaW6c3AAzRKuZ5NuzAa4QFDav/4llZ/CqgeKgKj1tZ8MuS iyWKpZ2l7bFr9XMmUizaW0iZoYvFYa2whHVwHWfI0pXXQNrCLRUL/rRG6IPbNN6y2JEP 91Sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SuhSRqcVLnHn4SQSoJuq0LF243s7I1feZyh7OZ3YiH0=; b=L0mC7+HFgVAhhIk0eumKnJBmgVqCPh23dSgw1RRUZLnl2XqXQUJpQS5GQv60RDuBvk rsiMlnXZk8Y2Ckm5H/kXbYe2frcBvcMddRTUtNP6TpvylboekLC480c1Z1hzudydepUr UAE0D1/sNVmVXHCFBdmnBVy4n4qh9b6lBtSQMVsyRmuHmpJlWPW16PUX94lw8Ead+QUU YeH2kw5GKalTHDZZzgiT6WmyXWPMeGbyIUjG9kp/BLz4coX5TLazdaPhrnC0pDtzZ/IA IQFZwqRSNcWnmELC4hMAlkEOj0xFw9/c1/DiLT3SYcFREetLAVtRraSCb3+BFslxADFJ Y/vA== X-Gm-Message-State: APjAAAWi9k7sWQ6QEpK2wnlsoFo6nZ/C7wZzTf9f3dAFjHDX1+3rI5CR u0T3GSJ2nsw3Bvf1VtfegRq0NLykurUameFdfOw= X-Google-Smtp-Source: APXvYqw+VbRHRPOeYhaksICRQsyP0aEKh8r+ZnqxpVx0e488u4BMa6KBdthHAketg0KDnyMcFKbErds6huDfAwi6L2U= X-Received: by 2002:a05:6512:78:: with SMTP id i24mr8216836lfo.55.1565745845769; Tue, 13 Aug 2019 18:24:05 -0700 (PDT) MIME-Version: 1.0 References: <156563213549.17893.514258464688769886@ietfa.amsl.com> <20190812182519.GA455391@LK-Perkele-VII> <20190814005910.GC30400@akamai.com> <20190814011159.GE30400@akamai.com> In-Reply-To: <20190814011159.GE30400@akamai.com> From: Watson Ladd Date: Tue, 13 Aug 2019 18:23:54 -0700 Message-ID: To: Benjamin Kaduk Cc: Ilari Liusvaara , TLS List Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-tlsflags-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2019 01:24:10 -0000 On Tue, Aug 13, 2019 at 6:12 PM Benjamin Kaduk wrote: > > On Tue, Aug 13, 2019 at 06:03:32PM -0700, Watson Ladd wrote: > > On Tue, Aug 13, 2019 at 6:00 PM Benjamin Kaduk wrote: > > > > > > On Mon, Aug 12, 2019 at 09:25:19PM +0300, Ilari Liusvaara wrote: > > > > On Mon, Aug 12, 2019 at 10:48:55AM -0700, internet-drafts@ietf.org wrote: > > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > > > This draft is a work item of the Transport Layer Security WG of the IETF. > > > > > > > > > > Title : A Flags Extension for TLS 1.3 > > > > > Author : Yoav Nir > > > > > Filename : draft-ietf-tls-tlsflags-00.txt > > > > > Pages : 6 > > > > > Date : 2019-08-12 > > > > > > > > > > > > > > > The IETF datatracker status page for this draft is: > > > > > https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/ > > > > > > > > > > There are also htmlized versions available at: > > > > > https://tools.ietf.org/html/draft-ietf-tls-tlsflags-00 > > > > > https://datatracker.ietf.org/doc/html/draft-ietf-tls-tlsflags-00 > > > > > > > > Two things: > > > > > > > > > > > > 1) uint8 flags<0..31>; > > > > > > > > That adds an extra byte that is not technically necressary (because > > > > extensions have lengths anyway) and limits number of flags to 248 > > > > (which might be enough). > > > > > > > > And I do not think the length of flags field can be 0 (if it would > > > > > > I think you need to send it in at least one protocol "response", to > > > confirm support for the extension, even if none of the flags offered > > > require confirmation/echo individually. > > > > I'm not sure this is the case: if in the future we define flags, then > > what is the difference between not understanding any flag and not > > understanding the extension? > > Nothing -- the difference is between understanding the "please frobnitz > my baddle" flag and not understanding it (or the extension, for that > matter). If "please frobnitz my baddle" is defined such that it appears > in the ClientHello and if the server supports the extension, the server > has the option to send a Thwarp handshake message to the client at any > time post-handshake if the server detects its imminent demise, then the > client that observes "I didn't get a Thwarp" cannot distinguish between > "the server doesn't support the extension" and "the server supports the > extension but is unaware of an imminent demise". But then you would send the flag back in the Server Hello, no? > > Does that help? > > -Ben -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Tue Aug 13 18:36:36 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A04120045 for ; Tue, 13 Aug 2019 18:36:19 -0700 (PDT) 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwMCs2MlXXNR for ; Tue, 13 Aug 2019 18:36:18 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC1BD1201EA for ; Tue, 13 Aug 2019 18:36:17 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x7E1WEND031166; Wed, 14 Aug 2019 02:36:15 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=Pc0MtQv8T8465zAjzj2PJ0r2oPrVrS8PzH8mZUb9s7s=; b=DL4GQQTfZWhlJbVOGaWWu+rOsQ36c9pYwsylj12UC7QET2GuYPa+qNzOLBNPmps9xwzr ssW/FjVPb178ZWqCymOd6F/Kyr3pXQNDj/2dJ8B7KO8vzlZytKgFpQCUKir+WxLt96ja vJ1oQmrqiVWj+4pMTGb6CRwUZ7pVJXpVGW0aa6yYlpBnWthu/51s+d0ZLA/LjzSZahv/ 0bqcGW++R3NuUdyv7yxu3ytCtNstHACtuakTOuqx8t/cFJCCK07sS4K/8WT3Z7ckPkRs s54a/qeQx8ZbyjArnO9ehuuQlS79Fb5ea3WWC/RQbOA7kDG8PBjvSiQIvctOAVLnzeA0 9g== Received: from prod-mail-ppoint7 (prod-mail-ppoint7.akamai.com [96.6.114.121] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2ubf8jeht1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Aug 2019 02:36:15 +0100 Received: from pps.filterd (prod-mail-ppoint7.akamai.com [127.0.0.1]) by prod-mail-ppoint7.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x7E1WB8a014990; Tue, 13 Aug 2019 21:36:14 -0400 Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint7.akamai.com with ESMTP id 2u9s8w0nj6-1; Tue, 13 Aug 2019 21:36:14 -0400 Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id 81D392006C; Wed, 14 Aug 2019 01:36:14 +0000 (GMT) Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1hxiCy-0006ay-Vm; Tue, 13 Aug 2019 20:36:13 -0500 Date: Tue, 13 Aug 2019 20:36:12 -0500 From: Benjamin Kaduk To: Watson Ladd Cc: Ilari Liusvaara , TLS List Message-ID: <20190814013612.GG30400@akamai.com> References: <156563213549.17893.514258464688769886@ietfa.amsl.com> <20190812182519.GA455391@LK-Perkele-VII> <20190814005910.GC30400@akamai.com> <20190814011159.GE30400@akamai.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) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-13_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=966 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908140014 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:5.22.84,1.0.8 definitions=2019-08-13_07:2019-08-13,2019-08-13 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 spamscore=0 priorityscore=1501 lowpriorityscore=0 impostorscore=0 mlxscore=0 mlxlogscore=952 malwarescore=0 bulkscore=0 adultscore=0 suspectscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1906280000 definitions=main-1908140014 Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-tlsflags-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2019 01:36:29 -0000 On Tue, Aug 13, 2019 at 06:23:54PM -0700, Watson Ladd wrote: > On Tue, Aug 13, 2019 at 6:12 PM Benjamin Kaduk wrote: > > > > On Tue, Aug 13, 2019 at 06:03:32PM -0700, Watson Ladd wrote: > > > On Tue, Aug 13, 2019 at 6:00 PM Benjamin Kaduk wrote: > > > > > > > > On Mon, Aug 12, 2019 at 09:25:19PM +0300, Ilari Liusvaara wrote: > > > > > On Mon, Aug 12, 2019 at 10:48:55AM -0700, internet-drafts@ietf.org wrote: > > > > I think you need to send it in at least one protocol "response", to > > > > confirm support for the extension, even if none of the flags offered > > > > require confirmation/echo individually. > > > > > > I'm not sure this is the case: if in the future we define flags, then > > > what is the difference between not understanding any flag and not > > > understanding the extension? > > > > Nothing -- the difference is between understanding the "please frobnitz > > my baddle" flag and not understanding it (or the extension, for that > > matter). If "please frobnitz my baddle" is defined such that it appears > > in the ClientHello and if the server supports the extension, the server > > has the option to send a Thwarp handshake message to the client at any > > time post-handshake if the server detects its imminent demise, then the > > client that observes "I didn't get a Thwarp" cannot distinguish between > > "the server doesn't support the extension" and "the server supports the > > extension but is unaware of an imminent demise". > > But then you would send the flag back in the Server Hello, no? If you define the extension with those semantics, yes. We've in the past wanted to reserve the option of having, well, the post_handshake_auth semantics, where the client indicates a capability and the server can optionally send a new protocol message. Would it be a huge loss if we didn't have that ability for things that want to use the flags extension? No. -Ben From nobody Tue Aug 13 22:41:30 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A3FE12004C for ; Tue, 13 Aug 2019 22:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Dpf87BP4MjI for ; Tue, 13 Aug 2019 22:41:25 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72032120046 for ; Tue, 13 Aug 2019 22:41:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 7A468C3F99; Wed, 14 Aug 2019 08:41:22 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id 0qZ6_EhD7KY3; Wed, 14 Aug 2019 08:41:21 +0300 (EEST) Received: from LK-Perkele-VII (87-100-246-37.bb.dnainternet.fi [87.100.246.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 29B4E285; Wed, 14 Aug 2019 08:41:17 +0300 (EEST) Date: Wed, 14 Aug 2019 08:41:17 +0300 From: Ilari Liusvaara To: Benjamin Kaduk Cc: Watson Ladd , TLS List Message-ID: <20190814054117.GA475347@LK-Perkele-VII> References: <156563213549.17893.514258464688769886@ietfa.amsl.com> <20190812182519.GA455391@LK-Perkele-VII> <20190814005910.GC30400@akamai.com> <20190814011159.GE30400@akamai.com> <20190814013612.GG30400@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20190814013612.GG30400@akamai.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-tlsflags-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2019 05:41:28 -0000 On Tue, Aug 13, 2019 at 08:36:12PM -0500, Benjamin Kaduk wrote: > On Tue, Aug 13, 2019 at 06:23:54PM -0700, Watson Ladd wrote: > > On Tue, Aug 13, 2019 at 6:12 PM Benjamin Kaduk wrote: > > > > > > On Tue, Aug 13, 2019 at 06:03:32PM -0700, Watson Ladd wrote: > > > > On Tue, Aug 13, 2019 at 6:00 PM Benjamin Kaduk wrote: > > > > > > > > > > On Mon, Aug 12, 2019 at 09:25:19PM +0300, Ilari Liusvaara wrote: > > > > > > On Mon, Aug 12, 2019 at 10:48:55AM -0700, internet-drafts@ietf.org wrote: > > > > > I think you need to send it in at least one protocol "response", to > > > > > confirm support for the extension, even if none of the flags offered > > > > > require confirmation/echo individually. > > > > > > > > I'm not sure this is the case: if in the future we define flags, then > > > > what is the difference between not understanding any flag and not > > > > understanding the extension? > > > > > > Nothing -- the difference is between understanding the "please frobnitz > > > my baddle" flag and not understanding it (or the extension, for that > > > matter). If "please frobnitz my baddle" is defined such that it appears > > > in the ClientHello and if the server supports the extension, the server > > > has the option to send a Thwarp handshake message to the client at any > > > time post-handshake if the server detects its imminent demise, then the > > > client that observes "I didn't get a Thwarp" cannot distinguish between > > > "the server doesn't support the extension" and "the server supports the > > > extension but is unaware of an imminent demise". > > > > But then you would send the flag back in the Server Hello, no? > > If you define the extension with those semantics, yes. We've in the > past wanted to reserve the option of having, well, the > post_handshake_auth semantics, where the client indicates a capability > and the server can optionally send a new protocol message. Would it be > a huge loss if we didn't have that ability for things that want to use > the flags extension? No. Note that interpretation problems arise anyway if one has at least two non-acknowledgeable flags: - Client sends non-acknowledgeable flags X and Y. - Server does not send flags / sends empty flags. What do those mean? The case that come to mind are: - Server does not support X nor Y. - Server does not support X nor Y, but supports some other flags client did not send. - Server supports X but not Y. - Server supports Y but not X. - Server supports both X and Y. And server advertising some optional feature not releated to client certificate or resumption is forbidden with regular extensions anyway. But if one wanted such feature for flags, one would have to allow "offer messages" (CH and CR) to contain empty flags, yes ("response messages" (SH, EE, CT) do not need to be empty for that, and ST is its own special case). In general, if some extension only makes invalid into valid, one only needs receiver acknowledgement of support (but may need sender advertisment if protocol does not support recevier giving such acknowledgement otherwise). If the extension alters meaning of valid, one needs bidirectional negotiation anyway. And there could be extensions that can alter what server sends before server_hello (e.g., extended_alert that alters the alert format in compatible way). Those are impossible to bidirectionally negotatiate, but unidirectional capability advertisment is possible. -Ilari From nobody Wed Aug 14 10:21:26 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 831BA120C05 for ; Wed, 14 Aug 2019 10:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0xgSHX2iggq for ; Wed, 14 Aug 2019 10:21:23 -0700 (PDT) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A1C212018B for ; Wed, 14 Aug 2019 10:21:23 -0700 (PDT) Received: by mail-wr1-x433.google.com with SMTP id k2so25998076wrq.2 for ; Wed, 14 Aug 2019 10:21:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wBD9rnCyhwLKuO6iU/VJ9Do7ZC3Ar1IIA6o8+oKYquM=; b=WIwADp8DN1gCBnUeiO8P9CIEty4k70EWBxlLIAAiSQ2qmwg6qwwUuLCYYXRRCMC00F BVqTexpFr2aEMqxZ5mrg0TKJZdJVkXdwrApro/7n850WMs6RDex8LuiLzYoQLWzc8avZ VMMbwdrAx12dm7N/mH8kfS8TGyaU/2nz7vfXPaHcDrLQjhux4gufqKZIs5oW3HTYlww/ qW1mcgQMEwIDvOVU0IM7/8JBUI9HI8HwmXGpLXYIA2mkPTrJkuTpU22J4jFIU0dq2MEK O7BxSVx2vbomHzWjrFo+K8kxBGRfwWAlLRhjttRQv3dNJSSRgumogtLx11nFTWp6aejS 8VFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wBD9rnCyhwLKuO6iU/VJ9Do7ZC3Ar1IIA6o8+oKYquM=; b=WFIlTMErujmgEpQwsVukp0T2yZa95qGfUBDeCrwNB/OdHuyMU3nb7G35qLIusHfoaC qpqWbRuUcduw3+TPXW9P+WGvNuG+PoqyHUogYrklhfigymG6KAdysEFPzkxmPNu97YNR q7fe1S3VCCDQKWK5+4kLI+U56LxMVgGIpK5FkEsV7diuGP9gPKRYqlxWuXzEoVh0mI9o sFUwTXohyiBLFjte6o6qf+CKY+DeriVsxYdLPfDaGNEknIE2NpGyJ0Wph6hrgXrfzc4M 06V5XIObEcRO4OtZTt03c7rIOCutITQ4yVtuSaQBVavAyRK1R2HpuCpGM6GyL4WYXB42 Wjxw== X-Gm-Message-State: APjAAAXtGq3UKiWb53f/gJ/+a8KC3CyOfm9Zql/M5ENypYlyBm7lCX7z EWdQ9Bdv9ao2vM8usnVU0+A= X-Google-Smtp-Source: APXvYqyj2MKxXs3mxjjqTvtmbU45Mbv/frHUC3/OEh7l+Lfq8xzeWfBdOsjiF+fcjKemhXo2Dpcchw== X-Received: by 2002:adf:f28d:: with SMTP id k13mr812763wro.19.1565803281915; Wed, 14 Aug 2019 10:21:21 -0700 (PDT) Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id m23sm480593wml.41.2019.08.14.10.21.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Aug 2019 10:21:19 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Yoav Nir In-Reply-To: <20190812182519.GA455391@LK-Perkele-VII> Date: Wed, 14 Aug 2019 20:21:17 +0300 Cc: tls@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2A9AE6DD-EE01-4DE6-977D-5A8847FB6BE4@gmail.com> References: <156563213549.17893.514258464688769886@ietfa.amsl.com> <20190812182519.GA455391@LK-Perkele-VII> To: Ilari Liusvaara X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-tlsflags-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2019 17:21:25 -0000 > On 12 Aug 2019, at 21:25, Ilari Liusvaara = wrote: >=20 > On Mon, Aug 12, 2019 at 10:48:55AM -0700, internet-drafts@ietf.org = wrote: >>=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 WG of the = IETF. >>=20 >> Title : A Flags Extension for TLS 1.3 >> Author : Yoav Nir >> Filename : draft-ietf-tls-tlsflags-00.txt >> Pages : 6 >> Date : 2019-08-12 >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/ >>=20 >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-tls-tlsflags-00 >> https://datatracker.ietf.org/doc/html/draft-ietf-tls-tlsflags-00 >=20 > Two things: >=20 >=20 > 1) uint8 flags<0..31>; >=20 > That adds an extra byte that is not technically necressary (because > extensions have lengths anyway) and limits number of flags to 248 > (which might be enough). I hope 248 is enough... > And I do not think the length of flags field can be 0 (if it would > be, one could just omit the extension). There could be a future flag that the server sends unsolicited = (client-auth-required?). It=E2=80=99s important for the client to show = support for the flags extension to make sure that it understands what = the server is sending. Depends on how we define the semantics in the draft. >=20 >=20 > 2) I think the bit order within octets should be reversed >=20 > That is, pack flags so that 0 is LSB of first octet, 7 is MSB of > first octet, 8 is LSB of second octet and so on. >=20 > Then one can read status flags by index with code like: >=20 > fn read_flag(flags: &[u8], idx: usize) -> bool > { > *flags.get(idx/8).unwrap_or(&0) >> idx%8 & 1 !=3D 0 > } >=20 > (That code will also happily handle out-of-array flags by reading > them as false.) Makes sense. I get caught up in visualizing computer memory and protocol = messages as a string of bits written from left to right. > -Ilari >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu Aug 15 07:17:03 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E16512011B for ; Thu, 15 Aug 2019 07:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XpvhW-gM8eDU for ; Thu, 15 Aug 2019 07:17:00 -0700 (PDT) Received: from out0-142.mail.aliyun.com (out0-142.mail.aliyun.com [140.205.0.142]) (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 A632F1200E5 for ; Thu, 15 Aug 2019 07:16:58 -0700 (PDT) X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R181e4; CH=green; DM=||false|; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03267; MF=kaishen.yy@antfin.com; NM=1; PH=DW; RN=1; SR=0; TI=W4_5657687_v5ForWebDing_0AB101E6_1565878614219_o7001c35p; Received: from WS-web (kaishen.yy@antfin.com[W4_5657687_v5ForWebDing_0AB101E6_1565878614219_o7001c35p]) by e01l07394.eu6 at Thu, 15 Aug 2019 22:16:54 +0800 Date: Thu, 15 Aug 2019 22:16:54 +0800 From: "Paul Yang" To: "TLS List" Reply-To: "Paul Yang" Message-ID: <2145119c-0942-4b38-bc58-eb8d6e018a1f.kaishen.yy@antfin.com> X-Mailer: [Alimail-Mailagent][W4_5657687][v5ForWebDing][Chrome] MIME-Version: 1.0 x-aliyun-mail-creator: W4_5657687_v5ForWebDing_M3LTW96aWxsYS81LjAgKE1hY2ludG9zaDsgSW50ZWwgTWFjIE9TIFggMTBfMTRfNSkgQXBwbGVXZWJLaXQvNTM3LjM2IChLSFRNTCwgbGlrZSBHZWNrbykgQ2hyb21lLzc2LjAuMzgwOS4xMDAgU2FmYXJpLzUzNy4zNg==vN Content-Type: multipart/alternative; boundary="----=ALIBOUNDARY_23333_4e15c940_5d556956_192fadc" Archived-At: Subject: [TLS] =?utf-8?q?Draft_for_SM_cipher_suites_used_in_TLS1=2E3?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2019 14:17:02 -0000 ------=ALIBOUNDARY_23333_4e15c940_5d556956_192fadc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgYWxsLAoKSSBoYXZlIHN1Ym1pdHRlZCBhIG5ldyBpbnRlcm5ldCBkcmFmdCB0byBpbnRyb2R1 Y2UgdGhlIFNNIGNpcGhlciBzdWl0ZXMgaW50byBUTFMgMS4zIHByb3RvY29sLgoKaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXlhbmctdGxzLXRsczEzLXNtLXN1aXRlcy0wMAoKU00g Y3J5cHRvZ3JhcGhpYyBhbGdvcml0aG1zIGFyZSBvcmlnaW5hbGx5IGEgc2V0IG9mIENoaW5lc2Ug bmF0aW9uYWwgYWxnb3JpdGhtcyBhbmQgbm93IGhhdmUgYmVlbiAob3IgYmVpbmcpIGFjY2VwdGVk IGJ5IElTTyBhcyBpbnRlcm5hdGlvbmFsIHN0YW5kYXJkcywgaW5jbHVkaW5nIFNNMiBzaWduYXR1 cmUgYWxnb3JpdGhtLCBTTTMgaGFzaCBmdW5jdGlvbiBhbmQgU000IGJsb2NrIGNpcGhlci4gVGhl c2UgYWxnb3JpdGhtcyBoYXZlIGFscmVhZHkgYmVlbiBzdXBwb3J0ZWQgc29tZSB0aW1lIGFnbyBi eSBzZXZlcmFsIHdpZGVseSB1c2VkIG9wZW4gc291cmNlIGNyeXB0b2dyYXBoaWMgbGlicmFyaWVz IGluY2x1ZGluZyBPcGVuU1NMLCBCb3VuY3lDYXN0bGUsIEJvdGFuLCBldGMuCgpDb25zaWRlcmlu ZyBUTFMxLjMgaXMgYmVpbmcgZ3JhZHVhbGx5IGFkb3B0ZWQgaW4gQ2hpbmEncyBpbnRlcm5ldCBp bmR1c3RyeSwgaXQncyBpbXBvcnRhbnQgdG8gaGF2ZSBhIG5vcm1hdGl2ZSBkZWZpbml0aW9uIG9u IGhvdyB0byB1c2UgdGhlIFNNIGFsZ29yaXRobXMgd2l0aCBUTFMxLjMsIGVzcGVjaWFsbHkgZm9y IHRoZSBtb2JpbGUgaW50ZXJuZXQgc2NlbmFyaW8uIEFudCBGaW5hbmNpYWwgaXMgdGhlIGNvbXBh bnkgd2hvIGRldmVsb3BzIHRoZSBtYXJrZXQgbGVhZGluZyBtb2JpbGUgYXBwICdBbGlwYXknIGFu ZCBzdXBwb3J0cyBwYXltZW50IHNlcnZpY2VzIGZvciBBbGliYWJhIGUtY29tbWVyY2UgYnVzaW5l c3MuIFdlIGhpZ2hseSBhcmUgZGVwZW5kaW5nIG9uIHRoZSBuZXcgVExTMS4zIHByb3RvY29sIGZv ciBib3RoIHBlcmZvcm1hbmNlIGFuZCBzZWN1cml0eSBwdXJwb3Nlcy4gV2UgZXhwZWN0IHRvIGhh dmUgbW9yZSBkZXBsb3ltZW50IG9mIFRMUzEuMyBjYXBhYmxlIGFwcGxpY2F0aW9ucyBpbiBDaGlu YSdzIGludGVybmV0IGluZHVzdHJ5IGJ5IHRoaXMgc3RhbmRhcmRpemF0aW9uIGF0dGVtcHRzLgoK SXQncyB2ZXJ5IGFwcHJlY2lhdGVkIHRvIGhhdmUgY29tbWVudHMgZnJvbSB0aGUgSUVURiBUTFMg bGlzdCA6LSkKCk1hbnkgdGhhbmtzIQ== ------=ALIBOUNDARY_23333_4e15c940_5d556956_192fadc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBjbGFzcz0iX19hbGl5dW5fZW1haWxfYm9keV9ibG9jayI+PGRpdiAgc3R5bGU9ImxpbmUt aGVpZ2h0OjEuNztmb250LWZhbWlseTpUYWhvbWEsQXJpYWwsU1RIZWl0aSxTaW1TdW47Zm9udC1z aXplOjE0LjBweDtjb2xvcjojMDAwMDAwOyI+PGRpdiAgc3R5bGU9ImxpbmUtaGVpZ2h0OjEuNztm b250LWZhbWlseTpUYWhvbWEsQXJpYWwsU1RIZWl0aSxTaW1TdW47Zm9udC1zaXplOjE0LjBweDtj b2xvcjojMDAwMDAwOyI+PGRpdiAgc3R5bGU9ImNsZWFyOmJvdGg7Ij5IaSBhbGwsPC9kaXY+PGRp diAgc3R5bGU9ImNsZWFyOmJvdGg7Ij48YnIgPjwvZGl2PjxkaXYgIHN0eWxlPSJjbGVhcjpib3Ro OyI+SSBoYXZlIHN1Ym1pdHRlZCBhIG5ldyBpbnRlcm5ldCBkcmFmdCB0byBpbnRyb2R1Y2UgdGhl IFNNIGNpcGhlciBzdWl0ZXMgaW50byBUTFMgMS4zIHByb3RvY29sLjwvZGl2PjxkaXYgIHN0eWxl PSJjbGVhcjpib3RoOyI+PGJyID48L2Rpdj48ZGl2ICBzdHlsZT0iY2xlYXI6Ym90aDsiPjxhICBo cmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteWFuZy10bHMtdGxzMTMtc20t c3VpdGVzLTAwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LXlhbmctdGxzLXRsczEzLXNtLXN1aXRlcy0wMDwvYT48L2Rpdj48ZGl2ICBzdHlsZT0iY2xl YXI6Ym90aDsiPjxiciA+PC9kaXY+PGRpdiAgc3R5bGU9ImNsZWFyOmJvdGg7Ij5TTSBjcnlwdG9n cmFwaGljIGFsZ29yaXRobXMgYXJlIG9yaWdpbmFsbHkgYSBzZXQgb2YgQ2hpbmVzZSBuYXRpb25h bCBhbGdvcml0aG1zIGFuZCBub3cgaGF2ZSBiZWVuIChvciBiZWluZykgYWNjZXB0ZWQgYnkgSVNP IGFzIGludGVybmF0aW9uYWwgc3RhbmRhcmRzLCBpbmNsdWRpbmcgU00yIHNpZ25hdHVyZSBhbGdv cml0aG0sIFNNMyBoYXNoIGZ1bmN0aW9uIGFuZCBTTTQgYmxvY2sgY2lwaGVyLiBUaGVzZSBhbGdv cml0aG1zIGhhdmUgYWxyZWFkeSBiZWVuIHN1cHBvcnRlZCBzb21lIHRpbWUgYWdvIGJ5IHNldmVy YWwgd2lkZWx5IHVzZWQgb3BlbiBzb3VyY2UgY3J5cHRvZ3JhcGhpYyBsaWJyYXJpZXMgaW5jbHVk aW5nIE9wZW5TU0wsIEJvdW5jeUNhc3RsZSwgQm90YW4sIGV0Yy48L2Rpdj48ZGl2ICBzdHlsZT0i Y2xlYXI6Ym90aDsiPjxiciA+PC9kaXY+PGRpdiAgc3R5bGU9ImNsZWFyOmJvdGg7Ij5Db25zaWRl cmluZyBUTFMxLjMgaXMgYmVpbmcgZ3JhZHVhbGx5IGFkb3B0ZWQgaW4gQ2hpbmEncyBpbnRlcm5l dCBpbmR1c3RyeSwgaXQncyBpbXBvcnRhbnQgdG8gaGF2ZSBhIG5vcm1hdGl2ZSBkZWZpbml0aW9u IG9uIGhvdyB0byB1c2UgdGhlIFNNIGFsZ29yaXRobXMgd2l0aCBUTFMxLjMsIGVzcGVjaWFsbHkg Zm9yIHRoZSBtb2JpbGUgaW50ZXJuZXQgc2NlbmFyaW8uIEFudCBGaW5hbmNpYWwgaXMgdGhlIGNv bXBhbnkgd2hvIGRldmVsb3BzIHRoZSBtYXJrZXQgbGVhZGluZyBtb2JpbGUgYXBwICdBbGlwYXkn IGFuZCBzdXBwb3J0cyBwYXltZW50IHNlcnZpY2VzIGZvciBBbGliYWJhIGUtY29tbWVyY2UgYnVz aW5lc3MuIFdlIGhpZ2hseSBhcmUgZGVwZW5kaW5nIG9uIHRoZSBuZXcgVExTMS4zIHByb3RvY29s IGZvciBib3RoIHBlcmZvcm1hbmNlIGFuZCBzZWN1cml0eSBwdXJwb3Nlcy4gV2UgZXhwZWN0IHRv IGhhdmUgbW9yZSBkZXBsb3ltZW50IG9mIFRMUzEuMyBjYXBhYmxlIGFwcGxpY2F0aW9ucyBpbiBD aGluYSdzIGludGVybmV0IGluZHVzdHJ5IGJ5IHRoaXMgc3RhbmRhcmRpemF0aW9uIGF0dGVtcHRz LjwvZGl2PjxkaXYgIHN0eWxlPSJjbGVhcjpib3RoOyI+PGJyID48L2Rpdj48ZGl2ICBzdHlsZT0i Y2xlYXI6Ym90aDsiPkl0J3MgdmVyeSBhcHByZWNpYXRlZCB0byBoYXZlIGNvbW1lbnRzIGZyb20g dGhlIElFVEYgVExTIGxpc3QgOi0pPC9kaXY+PGRpdiAgc3R5bGU9ImNsZWFyOmJvdGg7Ij48YnIg PjwvZGl2PjxkaXYgIHN0eWxlPSJjbGVhcjpib3RoOyI+TWFueSB0aGFua3MhPC9kaXY+PC9kaXY+ PC9kaXY+PC9kaXY+ ------=ALIBOUNDARY_23333_4e15c940_5d556956_192fadc-- From nobody Thu Aug 15 08:14:20 2019 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 B03011200B8; Thu, 15 Aug 2019 08:14:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: draft-ietf-tls-grease@ietf.org, Sean Turner , tls-chairs@ietf.org, sean@sn3rd.com, tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <156588205271.15865.9243229289426203471.idtracker@ietfa.amsl.com> Date: Thu, 15 Aug 2019 08:14:12 -0700 Archived-At: Subject: [TLS] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-tls-grease-03=3A_=28with_COMMENT=29?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2019 15:14:13 -0000 Mirja KĆ¼hlewind has entered the following ballot position for draft-ietf-tls-grease-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-grease/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- One comment/question: I think I didn't quite understand what a client is supposed to do if the connection fails with use of greasing values...? The security considerations seems to indicate that you should not try to re-connect without use of grease but rather just fail completely...? Also should you cache the information that greasing failed maybe? And a note on normative language: "Implementations sending multiple GREASE extensions in a single block thus must ensure the same value is not selected twice." Should this be a "MUST"? Also this is an interesting MUST: "... MUST correctly ignore unknown values..." While this is the whole point of the document, I assume this is already normatively specified in RFC8446 and therefore it could make sense to use non-formative language here... From nobody Thu Aug 15 08:24:17 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92E43120090; Thu, 15 Aug 2019 08:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id riKRGpHL0DFV; Thu, 15 Aug 2019 08:24:11 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.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 263F01200BA; Thu, 15 Aug 2019 08:24:10 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x7FFO6Fu024027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 15 Aug 2019 11:24:08 -0400 Date: Thu, 15 Aug 2019 10:24:05 -0500 From: Benjamin Kaduk To: Mirja =?iso-8859-1?Q?K=FChlewind?= Cc: The IESG , draft-ietf-tls-grease@ietf.org, tls-chairs@ietf.org, sean@sn3rd.com, tls@ietf.org Message-ID: <20190815152405.GS88236@kduck.mit.edu> References: <156588205271.15865.9243229289426203471.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <156588205271.15865.9243229289426203471.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [TLS] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_draft?= =?iso-8859-1?q?-ietf-tls-grease-03=3A_=28with_COMMENT=29?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2019 15:24:14 -0000 On Thu, Aug 15, 2019 at 08:14:12AM -0700, Mirja Kühlewind via Datatracker wrote: > Mirja Kühlewind has entered the following ballot position for > draft-ietf-tls-grease-03: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tls-grease/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > One comment/question: I think I didn't quite understand what a client is > supposed to do if the connection fails with use of greasing values...? The > security considerations seems to indicate that you should not try to re-connect > without use of grease but rather just fail completely...? Also should you cache > the information that greasing failed maybe? I'll let the authors chime in, but I think the sense of the security considerations is more that we are preventing the fallback from being needed "in production due to "real" negotiation failures. Falling back on GREASE failure is not as bad, provided that you follow-up with the failing peer out of band to try to get it fixed. I don't know how much value there would be in caching the grease-intolerate status; ideally it would almost-never happen. > And a note on normative language: > > "Implementations sending multiple > GREASE extensions in a single block thus must ensure the same value > is not selected twice." > Should this be a "MUST"? I asked for this to be changed away from a "MUST" -- RFC 8466 already has this prohibition on duplicated values; we're just calling it out again here since randomly picking values (with replacement, which is the easy way to code it) can result in collisions, that are forbidden by 8446. > Also this is an interesting MUST: > "... MUST correctly ignore unknown values..." > While this is the whole point of the document, I assume this is already > normatively specified in RFC8446 and therefore it could make sense to use > non-formative language here... I think you are correct, but I personally do not mind the extra normative force in this case. -Ben From nobody Thu Aug 15 08:30:32 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3901208A8; Thu, 15 Aug 2019 08:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RX6H3aF0G4f0; Thu, 15 Aug 2019 08:30:18 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27E5E1208C0; Thu, 15 Aug 2019 08:30:13 -0700 (PDT) Received: from [129.192.10.3] (helo=[10.149.1.218]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hyHhZ-0003Ha-BY; Thu, 15 Aug 2019 17:30:09 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: <20190815152405.GS88236@kduck.mit.edu> Date: Thu, 15 Aug 2019 17:30:08 +0200 Cc: draft-ietf-tls-grease@ietf.org, tls@ietf.org, The IESG , sean@sn3rd.com, tls-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <44BDC996-0E18-48BE-A700-C49A101330F8@kuehlewind.net> References: <156588205271.15865.9243229289426203471.idtracker@ietfa.amsl.com> <20190815152405.GS88236@kduck.mit.edu> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1565883013;407c8d35; X-HE-SMSGID: 1hyHhZ-0003Ha-BY Archived-At: Subject: Re: [TLS] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-tls-grease-03=3A_=28with_COMMENT=29?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2019 15:30:26 -0000 Hi Ben, See line. > On 15. Aug 2019, at 17:24, Benjamin Kaduk wrote: >=20 > On Thu, Aug 15, 2019 at 08:14:12AM -0700, Mirja K=C3=BChlewind via = Datatracker wrote: >> Mirja K=C3=BChlewind has entered the following ballot position for >> draft-ietf-tls-grease-03: No Objection >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-tls-grease/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> One comment/question: I think I didn't quite understand what a client = is >> supposed to do if the connection fails with use of greasing = values...? The >> security considerations seems to indicate that you should not try to = re-connect >> without use of grease but rather just fail completely...? Also should = you cache >> the information that greasing failed maybe? >=20 > I'll let the authors chime in, but I think the sense of the security > considerations is more that we are preventing the fallback from being > needed "in production due to "real" negotiation failures. Falling = back on > GREASE failure is not as bad, provided that you follow-up with the = failing > peer out of band to try to get it fixed. > I don't know how much value there would be in caching the = grease-intolerate > status; ideally it would almost-never happen. Okay, then I think it would be nice to say something more in the = document, about fallback at least. >=20 >> And a note on normative language: >>=20 >> "Implementations sending multiple >> GREASE extensions in a single block thus must ensure the same value >> is not selected twice." >> Should this be a "MUST"? >=20 > I asked for this to be changed away from a "MUST" -- RFC 8466 already = has > this prohibition on duplicated values; we're just calling it out again = here > since randomly picking values (with replacement, which is the easy way = to > code it) can result in collisions, that are forbidden by 8446. Ah okay, that=E2=80=99s fine. Didn=E2=80=99t check 8446. >=20 >> Also this is an interesting MUST: >> "... MUST correctly ignore unknown values..." >> While this is the whole point of the document, I assume this is = already >> normatively specified in RFC8446 and therefore it could make sense to = use >> non-formative language here... >=20 > I think you are correct, but I personally do not mind the extra = normative > force in this case. I just found this actually particularly weird because of the = =E2=80=9Ccorrectly=E2=80=9D. To me it reads like =E2=80=9Cplease, please = finally follow normative specification we do in RFCs=E2=80=9D=E2=80=A6 = anyway=E2=80=A6 I after all don't really mind if you pick on or the = other. Mirja =20 >=20 > -Ben >=20 >=20 From nobody Thu Aug 15 08:34:48 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEECE12011C for ; Thu, 15 Aug 2019 08:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g685C5C_RaS2 for ; Thu, 15 Aug 2019 08:34:44 -0700 (PDT) Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A12B01200DE for ; Thu, 15 Aug 2019 08:34:36 -0700 (PDT) Received: by mail-ot1-x32a.google.com with SMTP id o101so6756948ota.8 for ; Thu, 15 Aug 2019 08:34:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=Vo83r6cQgAlso2g9V7qyCzAgRrrDWqYeTRa6Qn/8/Tc=; b=JLXCOB7UFNv7p5krMGDKk4U9hyMToCAkbzP6sBJbBCvE+bH9QczWztTCKGU7yBF9LP 9767QgkrN2ut42PFKnutRHns/hhwXlydrkWG/luDHAXH72wFict62d+w73OagiLgzfLS ESBKVsnGA5yY9rshcvy6ychUSid8PDxw4lacWzATUTv4R0X5OKm5ifRJkKnAlVTgmu16 xkzbRsfNLh8EySd1xPEIP+7VZMIR3YYcB60t7/3qi6pMpcsaxjp+ko880GbOsABEQb7S SRO5R95DqvE/UBz7k1N7HXqHor8TliHDjoVJkE3X1d7kDyojGEOeHx8lwDdzoTEPJUul GXHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=Vo83r6cQgAlso2g9V7qyCzAgRrrDWqYeTRa6Qn/8/Tc=; b=eP1Zfo5GowIL+EhKqzuzxwq1AhQ6falZiKIZl1d7gPWU7IlDspDqB3Zw86Pgh++2CF 0GaPItcbjXqaTd/suFtPhkOny90EiAKunnqQ+tPdxuG04lMfR8Clc0bT4joKBZrMbToG 9lWFCu403TN0pXf9d6i3180zz7/cIX/h03ezvqkPhi7h+Dq+QNac6Ek0DeufPH4rjThs OjoKHYZ4wWRhFDNYECDXtjL2jjocYniBn+7rjFFpA5cLmQAyK7LNxCqjxSssGHpC+X6d 1pFpnqDgxsu1PEj3KhN18Oz1xdQtQ8Dg3ejCzwyL/xIWnQiV4Gx970cXJ5/2x75kGlZP zh6w== X-Gm-Message-State: APjAAAWOrW82uBqrq9Ih0fSWJ8cpUS/HfM7mlztOs4tEvTuoG9oJ8Q15 BJmdy7Hdw4ZqWDcS/Rm8rKrtR1N6 X-Google-Smtp-Source: APXvYqzBmzTKARkA10sU41GfYN15jt9zp6svuWG6jnDz8wh60wx7srI9bGJImAw1Oht5s1IU/Kb8Sg== X-Received: by 2002:a5d:888d:: with SMTP id d13mr508409ioo.135.1565883275774; Thu, 15 Aug 2019 08:34:35 -0700 (PDT) Received: from ?IPv6:2607:fea8:69f:f5eb:fc5f:12b:d173:619a? ([2607:fea8:69f:f5eb:fc5f:12b:d173:619a]) by smtp.gmail.com with ESMTPSA id k3sm4290636ioq.18.2019.08.15.08.34.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Aug 2019 08:34:35 -0700 (PDT) To: Paul Yang , TLS List References: <2145119c-0942-4b38-bc58-eb8d6e018a1f.kaishen.yy@antfin.com> From: Rene Struik Message-ID: Date: Thu, 15 Aug 2019 11:34:34 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <2145119c-0942-4b38-bc58-eb8d6e018a1f.kaishen.yy@antfin.com> Content-Type: multipart/alternative; boundary="------------ECED97B76975739F2126C337" Content-Language: en-US Archived-At: Subject: Re: [TLS] Draft for SM cipher suites used in TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2019 15:34:47 -0000 This is a multi-part message in MIME format. --------------ECED97B76975739F2126C337 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Paul: I tried and look up the documents GMT.0009-2012 and GBT.32918.5-2016 on the (non-secured) websites you referenced, but only found Chinese versions (and Chinese website navigation panels [pardon my poor language skills here]). Since the ISO documents are not available to the general public without payment, it would be helpful to have a freely available document (in English) from an authoritative source. Having such a reference available would be helpful to the IETF community (and researchers). Please note that BSI provides its specifications in German and English, so as to foster use/study by the community. If the Chinese national algorithms would be available in similar form, this would serve a similar purpose. FYI - I am interested in full details and some time last year I tried to download specs, but only Parts 2, 4, and 5 were available [1], [2], [3], not Parts 1 and 3. Best regards, Rene [1] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC - Part 5 - Parameter Definition (SEMB, July 24, 2018) [2] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC - Part 2 - Digital Signature Algorithm (SEMB, July 24, 2018) [3] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC - Part 4 - Public Key Encryption Algorithm (SEMB, July 24, 2018) On 8/15/2019 10:16 AM, Paul Yang wrote: > Hi all, > > I have submitted a new internet draft to introduce the SM cipher > suites into TLS 1.3 protocol. > > https://tools.ietf.org/html/draft-yang-tls-tls13-sm-suites-00 > > SM cryptographic algorithms are originally a set of Chinese national > algorithms and now have been (or being) accepted by ISO as > international standards, including SM2 signature algorithm, SM3 hash > function and SM4 block cipher. These algorithms have already been > supported some time ago by several widely used open source > cryptographic libraries including OpenSSL, BouncyCastle, Botan, etc. > > Considering TLS1.3 is being gradually adopted in China's internet > industry, it's important to have a normative definition on how to use > the SM algorithms with TLS1.3, especially for the mobile internet > scenario. Ant Financial is the company who develops the market leading > mobile app 'Alipay' and supports payment services for Alibaba > e-commerce business. We highly are depending on the new TLS1.3 > protocol for both performance and security purposes. We expect to have > more deployment of TLS1.3 capable applications in China's internet > industry by this standardization attempts. > > It's very appreciated to have comments from the IETF TLS list :-) > > Many thanks! > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------ECED97B76975739F2126C337 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Hi Paul:

I tried and look up the documents GMT.0009-2012 and GBT.32918.5-2016 on the (non-secured) websites you referenced, but only found Chinese versions (and Chinese website navigation panels [pardon my poor language skills here]). Since the ISO documents are not available to the general public without payment, it would be helpful to have a freely available document (in English) from an authoritative source. Having such a reference available would be helpful to the IETF community (and researchers). Please note that BSI provides its specifications in German and English, so as to foster use/study by the community. If the Chinese national algorithms would be available in similar form, this would serve a similar purpose.

FYI - I am interested in full details and some time last year I tried to download specs, but only Parts 2, 4, and 5 were available [1], [2], [3], not Parts 1 and 3.

Best regards, Rene

[1] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC - Part 5 - Parameter Definition (SEMB, July 24, 2018)
[2] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC - Part 2 - Digital Signature Algorithm (SEMB, July 24, 2018)
[3] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC - Part 4 - Public Key Encryption Algorithm (SEMB, July 24, 2018)

On 8/15/2019 10:16 AM, Paul Yang wrote:
Hi all,

I have submitted a new internet draft to introduce the SM cipher suites into TLS 1.3 protocol.


SM cryptographic algorithms are originally a set of Chinese national algorithms and now have been (or being) accepted by ISO as international standards, including SM2 signature algorithm, SM3 hash function and SM4 block cipher. These algorithms have already been supported some time ago by several widely used open source cryptographic libraries including OpenSSL, BouncyCastle, Botan, etc.

Considering TLS1.3 is being gradually adopted in China's internet industry, it's important to have a normative definition on how to use the SM algorithms with TLS1.3, especially for the mobile internet scenario. Ant Financial is the company who develops the market leading mobile app 'Alipay' and supports payment services for Alibaba e-commerce business. We highly are depending on the new TLS1.3 protocol for both performance and security purposes. We expect to have more deployment of TLS1.3 capable applications in China's internet industry by this standardization attempts.

It's very appreciated to have comments from the IETF TLS list :-)

Many thanks!

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



-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--------------ECED97B76975739F2126C337-- From nobody Thu Aug 15 08:57:49 2019 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 0F215120804; Thu, 15 Aug 2019 08:57:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: draft-ietf-tls-grease@ietf.org, Sean Turner , tls-chairs@ietf.org, sean@sn3rd.com, tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <156588466304.15861.9219490518200903631.idtracker@ietfa.amsl.com> Date: Thu, 15 Aug 2019 08:57:43 -0700 Archived-At: Subject: [TLS] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-tls-grease-03=3A_=28with_COMMENT=29?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2019 15:57:48 -0000 Mirja KĆ¼hlewind has entered the following ballot position for draft-ietf-tls-grease-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-grease/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Sorry one more comment/question I forgot earlier: Why is this document informational? Shouldn't it be at least experimental? ------ previous comment ------ One comment/question: I think I didn't quite understand what a client is supposed to do if the connection fails with use of greasing values...? The security considerations seems to indicate that you should not try to re-connect without use of grease but rather just fail completely...? Also should you cache the information that greasing failed maybe? And a note on normative language: "Implementations sending multiple GREASE extensions in a single block thus must ensure the same value is not selected twice." Should this be a "MUST"? Also this is an interesting MUST: "... MUST correctly ignore unknown values..." While this is the whole point of the document, I assume this is already normatively specified in RFC8446 and therefore it could make sense to use non-formative language here... From nobody Thu Aug 15 11:53:00 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B914E120233 for ; Thu, 15 Aug 2019 11:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id teZuwsb7g0lR for ; Thu, 15 Aug 2019 11:52:55 -0700 (PDT) Received: from mail-pg1-x543.google.com (mail-pg1-x543.google.com [IPv6:2607:f8b0:4864:20::543]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3021F120241 for ; Thu, 15 Aug 2019 11:52:55 -0700 (PDT) Received: by mail-pg1-x543.google.com with SMTP id k3so1667684pgb.10 for ; Thu, 15 Aug 2019 11:52:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5uMlsCBkQos1j0sMhzrzTYVxNrYWXlz5AI2dyb8XuV0=; b=RrmLEwH39icTCWHZWLjJngVcQkV797xR9nrfer8uoflrTD5LEQpiczbmUfuNaz2WO7 mK93WmHpfC1AyI9DGBV/zbR2p0YFLx3/MH4bTZX4i5YPR1M7u2TEP9i+L5wtT+p4+2Gh eiizyEXHhntUXwjT+n14xoNE6+AYjjasmUuFEGCZRrE5AtJx+RQ554VD70Unv736sFD+ izkNR0VjFVLYU9pUJpEqzgzdJctLmRHhTXdZttgn+ELDJgZDX18xO2wS2T5Z6z3QC+VO vkZS6q/v02nXu8SSTxFfddd+PGA1OqN9wlwW2hdd6RXK00XhszE6lFgQC/BdnJkwhYQJ r6TQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5uMlsCBkQos1j0sMhzrzTYVxNrYWXlz5AI2dyb8XuV0=; b=H4MbC/c6CCM1nUCDsK+bGgulMmifAs0eO5Cgl3jLlbsNxuHnqdPmOXnS+urNfd7Quk BMRISw5Lv0KRcnxi7VKCMdhYoXQmIILPsz+bSh+uqbLIbPX1o9mXklikhZojb54TOhWI 41LaIQqQs0KUb85VQZn6bKdrDDphoanANmwu7xstXUO5Y3e6mtVToXinAlhDgLnCEk0U svbMbIlLzKiA0uoqsWZSjymgXh9038wO8nWwnusICafcUFm6WCM5Fu/zNdAa2F0z7yrE 60Vg7CNkcCRg4JqILV3sIYiCZyQuWPrl55f8+VBbLCmVDn3CqRnLjqhCoLUXqWDpg9IK rrEg== X-Gm-Message-State: APjAAAWLQfc8ksPFavOhPurmLaKuB887i68CzO5agI0uF6j09z/q2VT4 H/SVAzPSIBn0swS8u/2GbHTSmcEuIK2FGMenrZTl X-Google-Smtp-Source: APXvYqzk/jO7MiLmQPOXxAJwEYDz6QIHS82mKmfqv9T4UiwCUyFWWopRhClKWlsMfSLkk+CsAK2meD/xSncxr+Zymw0= X-Received: by 2002:a63:2685:: with SMTP id m127mr4594213pgm.6.1565895174162; Thu, 15 Aug 2019 11:52:54 -0700 (PDT) MIME-Version: 1.0 References: <156588205271.15865.9243229289426203471.idtracker@ietfa.amsl.com> <20190815152405.GS88236@kduck.mit.edu> <44BDC996-0E18-48BE-A700-C49A101330F8@kuehlewind.net> In-Reply-To: <44BDC996-0E18-48BE-A700-C49A101330F8@kuehlewind.net> From: David Benjamin Date: Thu, 15 Aug 2019 14:52:37 -0400 Message-ID: To: Mirja Kuehlewind Cc: Benjamin Kaduk , draft-ietf-tls-grease@ietf.org, "" , The IESG , Sean Turner , tls-chairs Content-Type: multipart/alternative; boundary="0000000000009d307705902c612c" Archived-At: Subject: Re: [TLS] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-tls-grease-03=3A_=28with_COMMENT=29?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2019 18:52:59 -0000 --0000000000009d307705902c612c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Aug 15, 2019 at 11:30 AM Mirja Kuehlewind wrote: > Hi Ben, > > See line. > > > On 15. Aug 2019, at 17:24, Benjamin Kaduk wrote: > > > > On Thu, Aug 15, 2019 at 08:14:12AM -0700, Mirja K=C3=BChlewind via > Datatracker wrote: > >> Mirja K=C3=BChlewind has entered the following ballot position for > >> draft-ietf-tls-grease-03: No Objection > >> > >> When responding, please keep the subject line intact and reply to all > >> email addresses included in the To and CC lines. (Feel free to cut thi= s > >> introductory paragraph, however.) > >> > >> > >> Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > >> for more information about IESG DISCUSS and COMMENT positions. > >> > >> > >> The document, along with other ballot positions, can be found here: > >> https://datatracker.ietf.org/doc/draft-ietf-tls-grease/ > >> > >> > >> > >> ---------------------------------------------------------------------- > >> COMMENT: > >> ---------------------------------------------------------------------- > >> > >> One comment/question: I think I didn't quite understand what a client = is > >> supposed to do if the connection fails with use of greasing values...? > The > >> security considerations seems to indicate that you should not try to > re-connect > >> without use of grease but rather just fail completely...? Also should > you cache > >> the information that greasing failed maybe? > > > > I'll let the authors chime in, but I think the sense of the security > > considerations is more that we are preventing the fallback from being > > needed "in production due to "real" negotiation failures. Falling back > on > > GREASE failure is not as bad, provided that you follow-up with the > failing > > peer out of band to try to get it fixed. > > I don't know how much value there would be in caching the > grease-intolerate > > status; ideally it would almost-never happen. > > Okay, then I think it would be nice to say something more in the document= , > about fallback at least. > Ben's description is right. If deploying a new TLS feature results in too many interop failures with existing buggy servers, that feature becomes difficult to deploy and there is a lot of pressure to apply some sort of mitigation like a fallback. That's no good. GREASE's goal is to avoid the interop failures to begin with. The text was not meant to imply that you should do any sort of fallback. What change did you have in mind? The current text says: > Historically, when interoperability problems arise in deploying new TLS features, implementations have used a fallback retry on error with the feature disabled. This allows an active attacker to silently disable the new feature. By preventing a class of such interoperability problems, GREASE reduces the need for this kind of fallback. That reads to me as describing historical fallbacks, rather than recommending new ones. (Indeed you shouldn't do fallbacks. Fallbacks are bad. They break downgrade protection.) > > > >> And a note on normative language: > >> > >> "Implementations sending multiple > >> GREASE extensions in a single block thus must ensure the same value > >> is not selected twice." > >> Should this be a "MUST"? > > > > I asked for this to be changed away from a "MUST" -- RFC 8466 already h= as > > this prohibition on duplicated values; we're just calling it out again > here > > since randomly picking values (with replacement, which is the easy way = to > > code it) can result in collisions, that are forbidden by 8446. > > Ah okay, that=E2=80=99s fine. Didn=E2=80=99t check 8446. > > > >> Also this is an interesting MUST: > >> "... MUST correctly ignore unknown values..." > >> While this is the whole point of the document, I assume this is alread= y > >> normatively specified in RFC8446 and therefore it could make sense to > use > >> non-formative language here... > > > > I think you are correct, but I personally do not mind the extra normati= ve > > force in this case. > > I just found this actually particularly weird because of the =E2=80=9Ccor= rectly=E2=80=9D. > To me it reads like =E2=80=9Cplease, please finally follow normative spec= ification > we do in RFCs=E2=80=9D=E2=80=A6 anyway=E2=80=A6 I after all don't really = mind if you pick on or the > other. > > Mirja > > > > > > > -Ben > > > > > > --0000000000009d307705902c612c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Aug 15, 2019 at 11:30 AM Mirja Ku= ehlewind <ietf@kuehlewind.net= > wrote:
Hi Ben,

See line.

> On 15. Aug 2019, at 17:24, Benjamin Kaduk <kaduk@mit.edu> wrote:
>
> On Thu, Aug 15, 2019 at 08:14:12AM -0700, Mirja K=C3=BChlewind via Dat= atracker wrote:
>> Mirja K=C3=BChlewind has entered the following ballot position for=
>> draft-ietf-tls-grease-03: No Objection
>>
>> When responding, please keep the subject line intact and reply to = all
>> email addresses included in the To and CC lines. (Feel free to cut= this
>> introductory paragraph, however.)
>>
>>
>> Please refer to https://www.ietf.o= rg/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here= :
>> https://datatracker.ietf.org/doc/dra= ft-ietf-tls-grease/
>>
>>
>>
>> ------------------------------------------------------------------= ----
>> COMMENT:
>> ------------------------------------------------------------------= ----
>>
>> One comment/question: I think I didn't quite understand what a= client is
>> supposed to do if the connection fails with use of greasing values= ...? The
>> security considerations seems to indicate that you should not try = to re-connect
>> without use of grease but rather just fail completely...? Also sho= uld you cache
>> the information that greasing failed maybe?
>
> I'll let the authors chime in, but I think the sense of the securi= ty
> considerations is more that we are preventing the fallback from being<= br> > needed "in production due to "real" negotiation failure= s.=C2=A0 Falling back on
> GREASE failure is not as bad, provided that you follow-up with the fai= ling
> peer out of band to try to get it fixed.
> I don't know how much value there would be in caching the grease-i= ntolerate
> status; ideally it would almost-never happen.

Okay, then I think it would be nice to say something more in the document, = about fallback at least.

Ben's desc= ription is right. If deploying a new TLS feature results in too many intero= p failures with existing buggy servers, that feature becomes difficult to d= eploy and there is a lot of pressure to apply some sort of mitigation like = a fallback. That's no good. GREASE's goal is to avoid the interop f= ailures to begin with. The text was not meant to imply that you should do a= ny sort of fallback.

What change did you have in m= ind? The current text says:

>=C2=A0Historically= , when interoperability problems arise in deploying new TLS features, imple= mentations have used a fallback retry on error with the feature disabled. T= his allows an active attacker to silently disable the new feature. By preve= nting a class of such interoperability problems, GREASE reduces the need fo= r this kind of fallback.

That reads to me as descr= ibing historical fallbacks, rather than recommending new ones. (Indeed you = shouldn't do fallbacks. Fallbacks are bad. They break downgrade protect= ion.)
=C2=A0
>
>> And a note on normative language:
>>
>> "Implementations sending multiple
>>=C2=A0 =C2=A0GREASE extensions in a single block thus must ensure t= he same value
>>=C2=A0 =C2=A0is not selected twice."
>> Should this be a "MUST"?
>
> I asked for this to be changed away from a "MUST" -- RFC 846= 6 already has
> this prohibition on duplicated values; we're just calling it out a= gain here
> since randomly picking values (with replacement, which is the easy way= to
> code it) can result in collisions, that are forbidden by 8446.

Ah okay, that=E2=80=99s fine. Didn=E2=80=99t check 8446.
>
>> Also this is an interesting MUST:
>> "... MUST correctly ignore unknown values..."
>> While this is the whole point of the document, I assume this is al= ready
>> normatively specified in RFC8446 and therefore it could make sense= to use
>> non-formative language here...
>
> I think you are correct, but I personally do not mind the extra normat= ive
> force in this case.

I just found this actually particularly weird because of the =E2=80=9Ccorre= ctly=E2=80=9D. To me it reads like =E2=80=9Cplease, please finally follow n= ormative specification we do in RFCs=E2=80=9D=E2=80=A6 anyway=E2=80=A6 I af= ter all don't really mind if you pick on or the other.

Mirja



>
> -Ben
>
>

--0000000000009d307705902c612c-- From nobody Thu Aug 15 14:06:56 2019 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 3F2BD1200CC; Thu, 15 Aug 2019 14:06:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <156590321518.15836.15414514947845259591@ietfa.amsl.com> Date: Thu, 15 Aug 2019 14:06:55 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-sni-encryption-05.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2019 21:06:55 -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 WG of the IETF. Title : Issues and Requirements for SNI Encryption in TLS Authors : Christian Huitema Eric Rescorla Filename : draft-ietf-tls-sni-encryption-05.txt Pages : 14 Date : 2019-08-15 Abstract: This draft describes the general problem of encrypting the Server Name Identification (SNI) TLS parameter. The proposed solutions hide a Hidden Service behind a fronting service, only disclosing the SNI of the fronting service to external observers. The draft lists known attacks against SNI encryption, discusses the current "co-tenancy fronting" solution, and presents requirements for future TLS layer solutions. In practice, it may well be that no solution can meet every requirement, and that practical solutions will have to make some compromises. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-05 https://datatracker.ietf.org/doc/html/draft-ietf-tls-sni-encryption-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-sni-encryption-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 Thu Aug 15 14:20:00 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18AD6120124 for ; Thu, 15 Aug 2019 14:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ecr9eDSwh939 for ; Thu, 15 Aug 2019 14:19:51 -0700 (PDT) Received: from mail-yw1-xc30.google.com (mail-yw1-xc30.google.com [IPv6:2607:f8b0:4864:20::c30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E79112010C for ; Thu, 15 Aug 2019 14:19:51 -0700 (PDT) Received: by mail-yw1-xc30.google.com with SMTP id x74so1160236ywx.6 for ; Thu, 15 Aug 2019 14:19:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cqVO+IVcWFBqH1L/8HUQW96GdFa/dvdNCkBJuf1Guz8=; b=QBzO5erMrnrG7atin0rxesPH8VoP9e2NuO0oZMAl5ELPj8e7vD32UhCC7J/K2Tav6b bcaHNwb4RXlaCUnkWA1j88KTVfx2VxjcN0usPmGS0Pxn/oSGxBbx0iY0olGQNdKHFtAi +e4lNET6jA1/N2lHyXykzObYGK2KgSbIVYFFQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cqVO+IVcWFBqH1L/8HUQW96GdFa/dvdNCkBJuf1Guz8=; b=ugB2DD3XYwNWNWcKKKi+0mEgUEaNck0w+4UAk21wjtUEvFLYHA15FtExtqcFjT/XY/ I/vYpEizUIIJQGBlDwqL0aF6z9YRkvFCfTelVZWm+WTjqSc3lplwUlz0bTIamiCvmkC3 HUgFkefZyA649prxnDyl6sbDSTYlN05F/+LuEFFKVVIHHeRvYzNGbBQ1DeIt7jLvjRVX v+bRzf/7L2nzT1rDHbldl72QkKKlMMeNVLF6gCRU+G2Olqyhdl+RY2fN0eLlzPWDUHkO jhda5EG894aeRrvtaqV/K81aDM+zxVEJvWkU/8gP2xFQezcZgtpaOIcakFxmV60/5jAw eKnw== X-Gm-Message-State: APjAAAV/QAQY66G8ouf1vViHaWO3qu/x0aq2lc8zpQOY3avymzvkUxeN mNdE1HLsYmS0qp5FJ8iXxqqIxTt5lmvS2shu/ExRK3kBUns= X-Google-Smtp-Source: APXvYqzqamnJMrDmQiVoqksqLB0RICkrHp5tI3hqIUcvnTFgqDR0twzJUZwPqamKOGcJFZexCMDiHnp7eaaox532QZE= X-Received: by 2002:a0d:fb83:: with SMTP id l125mr4659298ywf.43.1565903989901; Thu, 15 Aug 2019 14:19:49 -0700 (PDT) MIME-Version: 1.0 References: <2145119c-0942-4b38-bc58-eb8d6e018a1f.kaishen.yy@antfin.com> In-Reply-To: <2145119c-0942-4b38-bc58-eb8d6e018a1f.kaishen.yy@antfin.com> From: Kyle Rose Date: Thu, 15 Aug 2019 17:19:38 -0400 Message-ID: To: Paul Yang Cc: TLS List Content-Type: multipart/alternative; boundary="00000000000012253405902e6f19" Archived-At: Subject: Re: [TLS] Draft for SM cipher suites used in TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2019 21:19:59 -0000 --00000000000012253405902e6f19 Content-Type: text/plain; charset="UTF-8" On Thu, Aug 15, 2019 at 10:17 AM Paul Yang wrote: > Hi all, > > I have submitted a new internet draft to introduce the SM cipher suites > into TLS 1.3 protocol. > > https://tools.ietf.org/html/draft-yang-tls-tls13-sm-suites-00 > Corresponding to changes in the IANA registry for TLS Cipher Suites as specified by RFC 8447 (see section 8 of https://tools.ietf.org/html/rfc8447), you should add a "recommended" column with the value "N" to changes requested to the cipher suites registry. Additionally, the SignatureAlgorithms registry has been deprecated: its contents apply only to versions of TLS prior to 1.3. Kyle --00000000000012253405902e6f19 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Aug 15, 2019 at 10:17 AM Paul Yang <kaishen.yy= =3D40antfin.com@dmarc.ietf.o= rg> wrote:
= Hi all,

= I have submitted a new internet draft to introduce the SM cipher suites int= o TLS 1.3 protocol.


Corresponding to changes in the IANA registry for TLS Cipher Suites = as specified by RFC 8447 (see section 8 of https://tools.ietf.org/html/rfc8447), you should add a = "recommended" column with the value "N" to changes requ= ested to the cipher suites registry.

Additionally, the SignatureAlgorithms registry has been = deprecated: its contents apply only to versions of TLS prior to 1.3.
<= div class=3D"gmail_quote">
Kyle
--00000000000012253405902e6f19-- From nobody Thu Aug 15 19:54:15 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54745120024 for ; Thu, 15 Aug 2019 19:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7IIX9yuj06I1 for ; Thu, 15 Aug 2019 19:54:12 -0700 (PDT) Received: from out0-158.mail.aliyun.com (out0-158.mail.aliyun.com [140.205.0.158]) (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 974CE12000E for ; Thu, 15 Aug 2019 19:54:11 -0700 (PDT) X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R141e4; CH=green; DM=||false|; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03305; MF=kaishen.yy@antfin.com; NM=1; PH=DS; RN=2; SR=0; TI=SMTPD_---.FCwPN4M_1565924046; Received: from 10.15.232.47(mailfrom:kaishen.yy@antfin.com fp:SMTPD_---.FCwPN4M_1565924046) by smtp.aliyun-inc.com(127.0.0.1); Fri, 16 Aug 2019 10:54:06 +0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: "Paul Yang" In-Reply-To: Date: Fri, 16 Aug 2019 10:54:05 +0800 Cc: TLS List Content-Transfer-Encoding: quoted-printable Message-Id: <32A2B06B-2663-453E-AB7F-B8C460C1BC93@antfin.com> References: <2145119c-0942-4b38-bc58-eb8d6e018a1f.kaishen.yy@antfin.com> To: Kyle Rose X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] Draft for SM cipher suites used in TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 02:54:14 -0000 > On Aug 16, 2019, at 5:19 AM, Kyle Rose wrote: >=20 > On Thu, Aug 15, 2019 at 10:17 AM Paul Yang = wrote: > Hi all, >=20 > I have submitted a new internet draft to introduce the SM cipher = suites into TLS 1.3 protocol. >=20 > https://tools.ietf.org/html/draft-yang-tls-tls13-sm-suites-00=20 >=20 > Corresponding to changes in the IANA registry for TLS Cipher Suites as = specified by RFC 8447 (see section 8 of = https://tools.ietf.org/html/rfc8447), you should add a "recommended" = column with the value "N" to changes requested to the cipher suites = registry. Okay, will fix this in next version. >=20 > Additionally, the SignatureAlgorithms registry has been deprecated: = its contents apply only to versions of TLS prior to 1.3. Hmmm, it seems there should not be SignatureAlgorithms registry present = in the draft. But I do find other typos of the IANA section, will all = fix them in next version. Thanks! >=20 > Kyle > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu Aug 15 20:39:47 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D16DF120024; Thu, 15 Aug 2019 20:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNPllZ8mckxl; Thu, 15 Aug 2019 20:39:36 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.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 AC6A1120013; Thu, 15 Aug 2019 20:39:36 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x7G3dVbh017536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 15 Aug 2019 23:39:34 -0400 Date: Thu, 15 Aug 2019 22:39:31 -0500 From: Benjamin Kaduk To: Mirja =?iso-8859-1?Q?K=FChlewind?= Cc: The IESG , draft-ietf-tls-grease@ietf.org, tls-chairs@ietf.org, sean@sn3rd.com, tls@ietf.org Message-ID: <20190816033931.GI88236@kduck.mit.edu> References: <156588466304.15861.9219490518200903631.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <156588466304.15861.9219490518200903631.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [TLS] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_draft?= =?iso-8859-1?q?-ietf-tls-grease-03=3A_=28with_COMMENT=29?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 03:39:39 -0000 On Thu, Aug 15, 2019 at 08:57:43AM -0700, Mirja Kühlewind via Datatracker wrote: > Mirja Kühlewind has entered the following ballot position for > draft-ietf-tls-grease-03: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tls-grease/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Sorry one more comment/question I forgot earlier: Why is this document > informational? Shouldn't it be at least experimental? I added a note to the shepherd writeup's "intended document status" entry: AD NOTE: Note that this has been successfully deployed for over a year; it's not really an "experiment" anymore but rather a useful thing that people do, both in TLS and elsewhere. This is informational in the sense that "here is a thing you can do, and some information about why you might want to do it". There's no real protocol -- you send some codepoints and expect the other endpoint to not change behavior as a result -- so it doesn't make sense as a proposed standard. I suppose one could argue that it is a BCP since it is for the health of the ecosystem, but that does not really feel like a good match. So to me, Informational is the right status. -Ben From kaishen.yy@alipay.com Thu Aug 15 10:38:24 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C50B81200C3 for ; Thu, 15 Aug 2019 10:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alipay.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id apPJY4AlHiEs for ; Thu, 15 Aug 2019 10:38:21 -0700 (PDT) Received: from out0-137.mail.aliyun.com (out0-137.mail.aliyun.com [140.205.0.137]) (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 BD4121200BA for ; Thu, 15 Aug 2019 10:38:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alipay.com; s=default; t=1565890697; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; bh=aXM0VvOmXj+Qyeaz4YNCAdGa5WZhF2wPISNeUqOOzGY=; b=VTiw2bd0gIYxhlvX5/oQp8yLfmt9vHCFcL3Q9ICKsZf51IOhPsMDjVC9enUssMqcne5uVThNbNiWE8pap2/b3YseJa7EMIi6PY9fSTfN/YHAoz20Ba049nl1J1EkcSFqFre5cLynp7Yf6WmbO6orRvlr1HDGhJZFIQYFOgMx7r8= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R181e4; CH=green; DM=||false|; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e01l07423; MF=kaishen.yy@alipay.com; NM=1; PH=DS; RN=3; SR=0; TI=SMTPD_---.FChyfC6_1565890692; Received: from 30.39.171.225(mailfrom:kaishen.yy@alipay.com fp:SMTPD_---.FChyfC6_1565890692) by smtp.aliyun-inc.com(127.0.0.1); Fri, 16 Aug 2019 01:38:15 +0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: "Paul Yang" In-Reply-To: Date: Fri, 16 Aug 2019 01:38:15 +0800 Cc: "Paul Yang" , "TLS List" Content-Transfer-Encoding: quoted-printable Message-Id: References: <2145119c-0942-4b38-bc58-eb8d6e018a1f.kaishen.yy@antfin.com> To: Rene Struik X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] Draft for SM cipher suites used in TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 03:40:41 -0000 Hi Rene: Thanks a lot for the comment. > On Aug 15, 2019, at 11:34 PM, Rene Struik = wrote: >=20 > Hi Paul: >=20 > I tried and look up the documents GMT.0009-2012 and GBT.32918.5-2016 = on the (non-secured) websites you referenced, but only found Chinese = versions (and Chinese website navigation panels [pardon my poor language = skills here]). Since the ISO documents are not available to the general = public without payment, it would be helpful to have a freely available = document (in English) from an authoritative source. Having such a = reference available would be helpful to the IETF community (and = researchers). Please note that BSI provides its specifications in German = and English, so as to foster use/study by the community. If the Chinese = national algorithms would be available in similar form, this would serve = a similar purpose. We also struggled with what references to use when this draft was being = written. As far as I know, there are not many official English = translations for the SM algorithms freely available online. But there = are some not that =E2=80=98official=E2=80=99 expired I-Ds posted to = CFRG, they are all well organized and accurate documents on SM = algorithms. Here is a list of them: SM2: https://tools.ietf.org/html/draft-shen-sm2-ecdsa-02 SM3: https://tools.ietf.org/html/draft-sca-cfrg-sm3-02 SM4: https://tools.ietf.org/html/draft-ribose-cfrg-sm4-10 (No AEAD mode) When OpenSSL (and maybe BouncyCastle) started to accept these = algorithms, the above drafts were mainly referenced. Unfotuantely I = can=E2=80=99t find translation for GMT.0009-2012 online at current = stage. So if you want to take a quick glance on how the algorithms are = designed, the above links could be used. Meanwhile, we are now seeking = official translations as well, will update the draft if we find any. >=20 > FYI - I am interested in full details and some time last year I tried = to download specs, but only Parts 2, 4, and 5 were available [1], [2], = [3], not Parts 1 and 3. Part 1 is the generic information mainly on elliptic curve and Part 3 = describes a key exchange scheme by using SM2 (including shared key = derivation scheme). Actually Part 2 (the [2]) describes SM2 in ISO/IEC = 14888-3:2018 and Part 5 (the [1]) is exactly GBT.32918.5-2016, as you = mentioned above. Both of Part 2 and Part 5 could be used as references = to this proposed new draft. Let me figure out the availability of Parts 1 & 3... >=20 > Best regards, Rene >=20 > [1] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC - = Part 5 - Parameter Definition (SEMB, July 24, 2018) > [2] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC - = Part 2 - Digital Signature Algorithm (SEMB, July 24, 2018) > [3] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC - = Part 4 - Public Key Encryption Algorithm (SEMB, July 24, 2018) >=20 > On 8/15/2019 10:16 AM, Paul Yang wrote: >> Hi all, >>=20 >> I have submitted a new internet draft to introduce the SM cipher = suites into TLS 1.3 protocol. >>=20 >> https://tools.ietf.org/html/draft-yang-tls-tls13-sm-suites-00 >>=20 >> SM cryptographic algorithms are originally a set of Chinese national = algorithms and now have been (or being) accepted by ISO as international = standards, including SM2 signature algorithm, SM3 hash function and SM4 = block cipher. These algorithms have already been supported some time ago = by several widely used open source cryptographic libraries including = OpenSSL, BouncyCastle, Botan, etc. >>=20 >> Considering TLS1.3 is being gradually adopted in China's internet = industry, it's important to have a normative definition on how to use = the SM algorithms with TLS1.3, especially for the mobile internet = scenario. Ant Financial is the company who develops the market leading = mobile app 'Alipay' and supports payment services for Alibaba e-commerce = business. We highly are depending on the new TLS1.3 protocol for both = performance and security purposes. We expect to have more deployment of = TLS1.3 capable applications in China's internet industry by this = standardization attempts. >>=20 >> It's very appreciated to have comments from the IETF TLS list :-) >>=20 >> Many thanks! >>=20 >>=20 >> _______________________________________________ >> TLS mailing list >>=20 >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >=20 >=20 > --=20 > email:=20 > rstruik.ext@gmail.com > | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >=20 From kaishen.yy@alipay.com Thu Aug 15 10:38:19 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC1001200BA for ; Thu, 15 Aug 2019 10:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alipay.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DrjJwm768WPP for ; Thu, 15 Aug 2019 10:38:17 -0700 (PDT) Received: from out0-136.mail.aliyun.com (out0-136.mail.aliyun.com [140.205.0.136]) (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 E3BFB1200C3 for ; Thu, 15 Aug 2019 10:38:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alipay.com; s=default; t=1565890694; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; bh=aXM0VvOmXj+Qyeaz4YNCAdGa5WZhF2wPISNeUqOOzGY=; b=uWEj9fUcaqreS6pBfJZmiSlezZBNzWCqG4AvbJBfy6zw45r/jjK4dRr8/x89dBwUCktw2mfb7Ei38caKwWhtEdHv4q4tVyHbaoWODT74NyibuRxF7cKdn0DzC695ppvlgvOACiYglRxhjqrSX/G3A82IbLiwtJrNW6bn/3TUoTs= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R981e4; CH=green; DM=||false|; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03301; MF=kaishen.yy@alipay.com; NM=1; PH=DS; RN=3; SR=0; TI=SMTPD_---.FChyfC6_1565890692; Received: from 30.39.171.225(mailfrom:kaishen.yy@alipay.com fp:SMTPD_---.FChyfC6_1565890692) by smtp.aliyun-inc.com(127.0.0.1); Fri, 16 Aug 2019 01:38:12 +0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: "Paul Yang" In-Reply-To: Date: Fri, 16 Aug 2019 01:35:02 +0800 Cc: "Paul Yang" , "TLS List" Content-Transfer-Encoding: quoted-printable Message-Id: <29421A57-A59E-495A-B414-0E2358F1FAA6@alipay.com> References: <2145119c-0942-4b38-bc58-eb8d6e018a1f.kaishen.yy@antfin.com> To: Rene Struik X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] Draft for SM cipher suites used in TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 03:41:04 -0000 Hi Rene: Thanks a lot for the comment. > On Aug 15, 2019, at 11:34 PM, Rene Struik = wrote: >=20 > Hi Paul: >=20 > I tried and look up the documents GMT.0009-2012 and GBT.32918.5-2016 = on the (non-secured) websites you referenced, but only found Chinese = versions (and Chinese website navigation panels [pardon my poor language = skills here]). Since the ISO documents are not available to the general = public without payment, it would be helpful to have a freely available = document (in English) from an authoritative source. Having such a = reference available would be helpful to the IETF community (and = researchers). Please note that BSI provides its specifications in German = and English, so as to foster use/study by the community. If the Chinese = national algorithms would be available in similar form, this would serve = a similar purpose. We also struggled with what references to use when this draft was being = written. As far as I know, there are not many official English = translations for the SM algorithms freely available online. But there = are some not that =E2=80=98official=E2=80=99 expired I-Ds posted to = CFRG, they are all well organized and accurate documents on SM = algorithms. Here is a list of them: SM2: https://tools.ietf.org/html/draft-shen-sm2-ecdsa-02 SM3: https://tools.ietf.org/html/draft-sca-cfrg-sm3-02 SM4: https://tools.ietf.org/html/draft-ribose-cfrg-sm4-10 (No AEAD mode) When OpenSSL (and maybe BouncyCastle) started to accept these = algorithms, the above drafts were mainly referenced. Unfotuantely I = can=E2=80=99t find translation for GMT.0009-2012 online at current = stage. So if you want to take a quick glance on how the algorithms are = designed, the above links could be used. Meanwhile, we are now seeking = official translations as well, will update the draft if we find any. >=20 > FYI - I am interested in full details and some time last year I tried = to download specs, but only Parts 2, 4, and 5 were available [1], [2], = [3], not Parts 1 and 3. Part 1 is the generic information mainly on elliptic curve and Part 3 = describes a key exchange scheme by using SM2 (including shared key = derivation scheme). Actually Part 2 (the [2]) describes SM2 in ISO/IEC = 14888-3:2018 and Part 5 (the [1]) is exactly GBT.32918.5-2016, as you = mentioned above. Both of Part 2 and Part 5 could be used as references = to this proposed new draft. Let me figure out the availability of Parts 1 & 3... >=20 > Best regards, Rene >=20 > [1] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC - = Part 5 - Parameter Definition (SEMB, July 24, 2018) > [2] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC - = Part 2 - Digital Signature Algorithm (SEMB, July 24, 2018) > [3] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC - = Part 4 - Public Key Encryption Algorithm (SEMB, July 24, 2018) >=20 > On 8/15/2019 10:16 AM, Paul Yang wrote: >> Hi all, >>=20 >> I have submitted a new internet draft to introduce the SM cipher = suites into TLS 1.3 protocol. >>=20 >> https://tools.ietf.org/html/draft-yang-tls-tls13-sm-suites-00 >>=20 >> SM cryptographic algorithms are originally a set of Chinese national = algorithms and now have been (or being) accepted by ISO as international = standards, including SM2 signature algorithm, SM3 hash function and SM4 = block cipher. These algorithms have already been supported some time ago = by several widely used open source cryptographic libraries including = OpenSSL, BouncyCastle, Botan, etc. >>=20 >> Considering TLS1.3 is being gradually adopted in China's internet = industry, it's important to have a normative definition on how to use = the SM algorithms with TLS1.3, especially for the mobile internet = scenario. Ant Financial is the company who develops the market leading = mobile app 'Alipay' and supports payment services for Alibaba e-commerce = business. We highly are depending on the new TLS1.3 protocol for both = performance and security purposes. We expect to have more deployment of = TLS1.3 capable applications in China's internet industry by this = standardization attempts. >>=20 >> It's very appreciated to have comments from the IETF TLS list :-) >>=20 >> Many thanks! >>=20 >>=20 >> _______________________________________________ >> TLS mailing list >>=20 >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >=20 >=20 > --=20 > email:=20 > rstruik.ext@gmail.com > | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >=20 From nobody Fri Aug 16 00:13:59 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7F3E120041 for ; Fri, 16 Aug 2019 00:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alibaba-inc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCTj0rMeLml5 for ; Fri, 16 Aug 2019 00:13:54 -0700 (PDT) Received: from out0-145.mail.aliyun.com (out0-145.mail.aliyun.com [140.205.0.145]) (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 D3E9312002E for ; Fri, 16 Aug 2019 00:13:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1565939628; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; bh=CsKPhqQlhRGNdLJ0ZzUMSycYgLCDH8GV4ddmkHZQWNw=; b=cLcZbMZwqITXHrb+Fq4yJ9g2RxVX7iO093UwHTHGK07mMbck5GS+YIjAXFcTYjVtHivtqQ+nAp9wt3dtByPYKaKYFOzVL8A7TBQUFqX1Afx5lVVQHK44OktdyMbKCzK+Gfq+J5Jo2vMxeQgx3XwHT1FjotAqJ4rh23l3tPhFKI0= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R161e4; CH=green; DM=||false|; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03267; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DW; RN=2; SR=0; TI=W4_5657687_DEFAULT_0A93269A_1565939620954_o7001c95s; Received: from WS-web (kepeng.lkp@alibaba-inc.com[W4_5657687_DEFAULT_0A93269A_1565939620954_o7001c95s]) by e01l04363.eu6 at Fri, 16 Aug 2019 15:13:44 +0800 Date: Fri, 16 Aug 2019 15:13:44 +0800 From: "Kepeng Li" To: "rstruik.ext" , "TLS" Reply-To: "Kepeng Li" Message-ID: <3dfe43fe-b81c-4fc1-91af-3a1e8565794e.kepeng.lkp@alibaba-inc.com> X-Mailer: [Alimail-Mailagent][W4_5657687][DEFAULT][Chrome] MIME-Version: 1.0 x-aliyun-mail-creator: W4_5657687_DEFAULT_M3LTW96aWxsYS81LjAgKE1hY2ludG9zaDsgSW50ZWwgTWFjIE9TIFggMTBfMTRfNSkgQXBwbGVXZWJLaXQvNTM3LjM2IChLSFRNTCwgbGlrZSBHZWNrbykgQ2hyb21lLzc2LjAuMzgwOS4xMDAgU2FmYXJpLzUzNy4zNg==vN Content-Type: multipart/alternative; boundary="----=ALIBOUNDARY_18741_4cf23940_5d5657a8_194a316" Archived-At: Subject: [TLS] =?utf-8?q?Re=EF=BC=9A_Draft_for_SM_cipher_suites_used_in_T?= =?utf-8?q?LS1=2E3?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 07:13:57 -0000 ------=ALIBOUNDARY_18741_4cf23940_5d5657a8_194a316 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 CkhpIFJlbmUgYW5kIGFsbCwKCj4gU2luY2UgdGhlIElTTyBkb2N1bWVudHMgYXJlIG5vdCBhdmFp bGFibGUgdG8gdGhlIGdlbmVyYWwgCj4gcHVibGljIHdpdGhvdXQgcGF5bWVudCwgaXQgd291bGQg YmUgaGVscGZ1bCB0byBoYXZlIGEgZnJlZWx5IGF2YWlsYWJsZSAKPiBkb2N1bWVudCAoaW4gRW5n bGlzaCkgZnJvbSBhbiBhdXRob3JpdGF0aXZlIHNvdXJjZS4gSGF2aW5nIHN1Y2ggYSAKPiByZWZl cmVuY2UgYXZhaWxhYmxlIHdvdWxkIGJlIGhlbHBmdWwgdG8gdGhlIElFVEYgY29tbXVuaXR5IChh bmQgCj4gcmVzZWFyY2hlcnMpLgpBYm91dCB0aGUgcmVmZXJlbmNlcyB0byBJU08gZG9jdW1lbnMs IEkgdGhpbmsgaXQgaXMgYSBnZW5lcmFsIGlzc3VlIGZvciBJRVRGIGRyYWZ0cy4KCkhvdyBkb2Vz IHRoZSBvdGhlciBJRVRGIGRyYWZ0cyBtYWtlIHRoZSByZWZlcmVuY2VzIHRvIElTTyBkb2N1bWVu dHM/IElTTyBkb2N1bWVudHMgYXJlIG9mdGVuIHJlZmVyZW5jZWQgYnkgSUVURiBkcmFmdHMuCgpU aGFua3MsCgpLaW5kIFJlZ2FyZHMKS2VwZW5nCuKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKA lOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKA lOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKA lOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlApS ZTogW1RMU10gRHJhZnQgZm9yIFNNIGNpcGhlciBzdWl0ZXMgdXNlZCBpbiBUTFMxLjMKUmVuZSBT dHJ1aWsgPHJzdHJ1aWsuZXh0QGdtYWlsLmNvbT4gVGh1LCAxNSBBdWd1c3QgMjAxOSAxNTozNCBV VENTaG93IGhlYWRlcgpIaSBQYXVsOgoKSSB0cmllZCBhbmQgbG9vayB1cCB0aGUgZG9jdW1lbnRz IEdNVC4wMDA5LTIwMTIgYW5kIEdCVC4zMjkxOC41LTIwMTYgb24gCnRoZSAobm9uLXNlY3VyZWQp IHdlYnNpdGVzIHlvdSByZWZlcmVuY2VkLCBidXQgb25seSBmb3VuZCBDaGluZXNlIAp2ZXJzaW9u cyAoYW5kIENoaW5lc2Ugd2Vic2l0ZSBuYXZpZ2F0aW9uIHBhbmVscyBbcGFyZG9uIG15IHBvb3Ig bGFuZ3VhZ2UgCnNraWxscyBoZXJlXSkuIFNpbmNlIHRoZSBJU08gZG9jdW1lbnRzIGFyZSBub3Qg YXZhaWxhYmxlIHRvIHRoZSBnZW5lcmFsIApwdWJsaWMgd2l0aG91dCBwYXltZW50LCBpdCB3b3Vs ZCBiZSBoZWxwZnVsIHRvIGhhdmUgYSBmcmVlbHkgYXZhaWxhYmxlIApkb2N1bWVudCAoaW4gRW5n bGlzaCkgZnJvbSBhbiBhdXRob3JpdGF0aXZlIHNvdXJjZS4gSGF2aW5nIHN1Y2ggYSAKcmVmZXJl bmNlIGF2YWlsYWJsZSB3b3VsZCBiZSBoZWxwZnVsIHRvIHRoZSBJRVRGIGNvbW11bml0eSAoYW5k IApyZXNlYXJjaGVycykuIFBsZWFzZSBub3RlIHRoYXQgQlNJIHByb3ZpZGVzIGl0cyBzcGVjaWZp Y2F0aW9ucyBpbiBHZXJtYW4gCmFuZCBFbmdsaXNoLCBzbyBhcyB0byBmb3N0ZXIgdXNlL3N0dWR5 IGJ5IHRoZSBjb21tdW5pdHkuIElmIHRoZSBDaGluZXNlIApuYXRpb25hbCBhbGdvcml0aG1zIHdv dWxkIGJlIGF2YWlsYWJsZSBpbiBzaW1pbGFyIGZvcm0sIHRoaXMgd291bGQgc2VydmUgCmEgc2lt aWxhciBwdXJwb3NlLgoKRllJIC0gSSBhbSBpbnRlcmVzdGVkIGluIGZ1bGwgZGV0YWlscyBhbmQg c29tZSB0aW1lIGxhc3QgeWVhciBJIHRyaWVkIHRvIApkb3dubG9hZCBzcGVjcywgYnV0IG9ubHkg UGFydHMgMiwgNCwgYW5kIDUgd2VyZSBhdmFpbGFibGUgWzFdLCBbMl0sIFszXSwgCm5vdCBQYXJ0 cyAxIGFuZCAzLgoKQmVzdCByZWdhcmRzLCBSZW5lCgpbMV0gQ2hpbmEgRUNDIC0gUHVibGljIEtl eSBDcnlwdG9ncmFwaGljIEFsZ29yaXRobSBTTTIgQmFzZWQgb24gRUNDIC0gClBhcnQgNSAtIFBh cmFtZXRlciBEZWZpbml0aW9uIChTRU1CLCBKdWx5IDI0LCAyMDE4KQpbMl0gQ2hpbmEgRUNDIC0g UHVibGljIEtleSBDcnlwdG9ncmFwaGljIEFsZ29yaXRobSBTTTIgQmFzZWQgb24gRUNDIC0gClBh cnQgMiAtIERpZ2l0YWwgU2lnbmF0dXJlIEFsZ29yaXRobSAoU0VNQiwgSnVseSAyNCwgMjAxOCkK WzNdIENoaW5hIEVDQyAtIFB1YmxpYyBLZXkgQ3J5cHRvZ3JhcGhpYyBBbGdvcml0aG0gU00yIEJh c2VkIG9uIEVDQyAtIApQYXJ0IDQgLSBQdWJsaWMgS2V5IEVuY3J5cHRpb24gQWxnb3JpdGhtIChT RU1CLCBKdWx5IDI0LCAyMDE4KQoKT24gOC8xNS8yMDE5IDEwOjE2IEFNLCBQYXVsIFlhbmcgd3Jv dGU6Cj4gSGkgYWxsLAo+Cj4gSSBoYXZlIHN1Ym1pdHRlZCBhIG5ldyBpbnRlcm5ldCBkcmFmdCB0 byBpbnRyb2R1Y2UgdGhlIFNNIGNpcGhlciAKPiBzdWl0ZXMgaW50byBUTFMgMS4zIHByb3RvY29s Lgo+Cj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXlhbmctdGxzLXRsczEzLXNt LXN1aXRlcy0wMAo+Cj4gU00gY3J5cHRvZ3JhcGhpYyBhbGdvcml0aG1zIGFyZSBvcmlnaW5hbGx5 IGEgc2V0IG9mIENoaW5lc2UgbmF0aW9uYWwgCj4gYWxnb3JpdGhtcyBhbmQgbm93IGhhdmUgYmVl biAob3IgYmVpbmcpIGFjY2VwdGVkIGJ5IElTTyBhcyAKPiBpbnRlcm5hdGlvbmFsIHN0YW5kYXJk cywgaW5jbHVkaW5nIFNNMiBzaWduYXR1cmUgYWxnb3JpdGhtLCBTTTMgaGFzaCAKPiBmdW5jdGlv biBhbmQgU000IGJsb2NrIGNpcGhlci4gVGhlc2UgYWxnb3JpdGhtcyBoYXZlIGFscmVhZHkgYmVl biAKPiBzdXBwb3J0ZWQgc29tZSB0aW1lIGFnbyBieSBzZXZlcmFsIHdpZGVseSB1c2VkIG9wZW4g c291cmNlIAo+IGNyeXB0b2dyYXBoaWMgbGlicmFyaWVzIGluY2x1ZGluZyBPcGVuU1NMLCBCb3Vu Y3lDYXN0bGUsIEJvdGFuLCBldGMuCj4KPiBDb25zaWRlcmluZyBUTFMxLjMgaXMgYmVpbmcgZ3Jh ZHVhbGx5IGFkb3B0ZWQgaW4gQ2hpbmEncyBpbnRlcm5ldCAKPiBpbmR1c3RyeSwgaXQncyBpbXBv cnRhbnQgdG8gaGF2ZSBhIG5vcm1hdGl2ZSBkZWZpbml0aW9uIG9uIGhvdyB0byB1c2UgCj4gdGhl IFNNIGFsZ29yaXRobXMgd2l0aCBUTFMxLjMsIGVzcGVjaWFsbHkgZm9yIHRoZSBtb2JpbGUgaW50 ZXJuZXQgCj4gc2NlbmFyaW8uIEFudCBGaW5hbmNpYWwgaXMgdGhlIGNvbXBhbnkgd2hvIGRldmVs b3BzIHRoZSBtYXJrZXQgbGVhZGluZyAKPiBtb2JpbGUgYXBwICdBbGlwYXknIGFuZCBzdXBwb3J0 cyBwYXltZW50IHNlcnZpY2VzIGZvciBBbGliYWJhIAo+IGUtY29tbWVyY2UgYnVzaW5lc3MuIFdl IGhpZ2hseSBhcmUgZGVwZW5kaW5nIG9uIHRoZSBuZXcgVExTMS4zIAo+IHByb3RvY29sIGZvciBi b3RoIHBlcmZvcm1hbmNlIGFuZCBzZWN1cml0eSBwdXJwb3Nlcy4gV2UgZXhwZWN0IHRvIGhhdmUg Cj4gbW9yZSBkZXBsb3ltZW50IG9mIFRMUzEuMyBjYXBhYmxlIGFwcGxpY2F0aW9ucyBpbiBDaGlu YSdzIGludGVybmV0IAo+IGluZHVzdHJ5IGJ5IHRoaXMgc3RhbmRhcmRpemF0aW9uIGF0dGVtcHRz Lgo+Cj4gSXQncyB2ZXJ5IGFwcHJlY2lhdGVkIHRvIGhhdmUgY29tbWVudHMgZnJvbSB0aGUgSUVU RiBUTFMgbGlzdCA6LSkKPgo+IE1hbnkgdGhhbmtzIQo+Cj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KPiBUTFMgbWFpbGluZyBsaXN0Cj4gVExTQGlldGYu b3JnCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMKCg== ------=ALIBOUNDARY_18741_4cf23940_5d5657a8_194a316 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBjbGFzcz0iX19hbGl5dW5fZW1haWxfYm9keV9ibG9jayI+PGRpdiAgc3R5bGU9ImNsZWFy OmJvdGg7Ij48c3BhbiAgc3R5bGU9ImZvbnQtZmFtaWx5OlRhaG9tYSxBcmlhbCxTVEhlaXRpLFNp bVN1bjtmb250LXNpemU6MTQuMHB4O2NvbG9yOiMwMDAwMDA7Ij48L3NwYW4+PHNwYW4gIHN0eWxl PSJmb250LWZhbWlseTphcmlhbDsiPkhpIFJlbmUgYW5kIGFsbCw8L3NwYW4+PC9kaXY+PGRpdiAg c3R5bGU9ImNsZWFyOmJvdGg7Ij48ZGl2ICBzdHlsZT0iZm9udC12YXJpYW50LWxpZ2F0dXJlczpu b3JtYWw7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4dC1pbmRl bnQ6LjBweDt3aWRvd3M6MjtiYWNrZ3JvdW5kLWNvbG9yOiNmZmZmZmY7dGV4dC1kZWNvcmF0aW9u LXN0eWxlOmluaXRpYWw7dGV4dC1kZWNvcmF0aW9uLWNvbG9yOmluaXRpYWw7Y2xlYXI6Ym90aDsi PjxzcGFuICBzdHlsZT0iY29sb3I6IzAwMDAwMDtmb250LXNpemU6MTQuMHB4O2ZvbnQtc3R5bGU6 bm9ybWFsO2ZvbnQtd2VpZ2h0OjQwMDt0ZXh0LXRyYW5zZm9ybTpub25lO2ZvbnQtZmFtaWx5OmFy aWFsOyI+PGJyID48L3NwYW4+PC9kaXY+PC9kaXY+PGRpdiAgc3R5bGU9ImNsZWFyOmJvdGg7Ij48 ZGl2ICBzdHlsZT0iZm9udC12YXJpYW50LWxpZ2F0dXJlczpub3JtYWw7Zm9udC12YXJpYW50LWNh cHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4dC1pbmRlbnQ6LjBweDt3aWRvd3M6MjtiYWNr Z3JvdW5kLWNvbG9yOiNmZmZmZmY7dGV4dC1kZWNvcmF0aW9uLXN0eWxlOmluaXRpYWw7dGV4dC1k ZWNvcmF0aW9uLWNvbG9yOmluaXRpYWw7Y2xlYXI6Ym90aDsiPjwvZGl2PjxkaXYgIHN0eWxlPSJm b250LXZhcmlhbnQtbGlnYXR1cmVzOm5vcm1hbDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4 dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDouMHB4O3dpZG93czoyO2JhY2tncm91bmQtY29sb3I6 I2ZmZmZmZjt0ZXh0LWRlY29yYXRpb24tc3R5bGU6aW5pdGlhbDt0ZXh0LWRlY29yYXRpb24tY29s b3I6aW5pdGlhbDtjbGVhcjpib3RoOyI+PC9kaXY+PGRpdiAgc3R5bGU9ImZvbnQtdmFyaWFudC1s aWdhdHVyZXM6bm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0 O3RleHQtaW5kZW50Oi4wcHg7d2lkb3dzOjI7YmFja2dyb3VuZC1jb2xvcjojZmZmZmZmO3RleHQt ZGVjb3JhdGlvbi1zdHlsZTppbml0aWFsO3RleHQtZGVjb3JhdGlvbi1jb2xvcjppbml0aWFsO2Ns ZWFyOmJvdGg7Ij48cHJlICBjbGFzcz0id29yZHdyYXAiIHN0eWxlPSJsaW5lLWhlaWdodDoyMC43 cHg7Zm9udC12YXJpYW50LWxpZ2F0dXJlczpub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFs O3RleHQtYWxpZ246bGVmdDt0ZXh0LWluZGVudDouMHB4O3dpZG93czoyO3RleHQtZGVjb3JhdGlv bi1zdHlsZTppbml0aWFsO3RleHQtZGVjb3JhdGlvbi1jb2xvcjppbml0aWFsO2JveC1zaXppbmc6 Ym9yZGVyLWJveDttYXJnaW4tdG9wOi4wcHg7bWFyZ2luLWJvdHRvbToxLjByZW07b3ZlcmZsb3c6 YXV0bztkaXNwbGF5OmJsb2NrO292ZXJmbG93LXdyYXA6bm9ybWFsO3dvcmQtYnJlYWs6bm9ybWFs O3BhZGRpbmc6LjBweDsiPjxzcGFuICBzdHlsZT0iY29sb3I6IzIxMjUyOTtmb250LXN0eWxlOm5v cm1hbDtmb250LXdlaWdodDo0MDA7dGV4dC10cmFuc2Zvcm06bm9uZTtmb250LWZhbWlseTphcmlh bDtmb250LXNpemU6MTQuMHB4OyI+Jmd0OyBTaW5jZSB0aGUgSVNPIGRvY3VtZW50cyBhcmUgbm90 IGF2YWlsYWJsZSB0byB0aGUgZ2VuZXJhbCAKJmd0OyBwdWJsaWMgd2l0aG91dCBwYXltZW50LCBp dCB3b3VsZCBiZSBoZWxwZnVsIHRvIGhhdmUgYSBmcmVlbHkgYXZhaWxhYmxlIAomZ3Q7IGRvY3Vt ZW50IChpbiBFbmdsaXNoKSBmcm9tIGFuIGF1dGhvcml0YXRpdmUgc291cmNlLiBIYXZpbmcgc3Vj aCBhIAomZ3Q7IHJlZmVyZW5jZSBhdmFpbGFibGUgd291bGQgYmUgaGVscGZ1bCB0byB0aGUgSUVU RiBjb21tdW5pdHkgKGFuZCAKJmd0OyByZXNlYXJjaGVycykuPC9zcGFuPjwvcHJlPjwvZGl2Pjxk aXYgIHN0eWxlPSJmb250LXZhcmlhbnQtbGlnYXR1cmVzOm5vcm1hbDtmb250LXZhcmlhbnQtY2Fw czpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDouMHB4O3dpZG93czoyO2JhY2tn cm91bmQtY29sb3I6I2ZmZmZmZjt0ZXh0LWRlY29yYXRpb24tc3R5bGU6aW5pdGlhbDt0ZXh0LWRl Y29yYXRpb24tY29sb3I6aW5pdGlhbDtjbGVhcjpib3RoOyI+PHNwYW4gIHN0eWxlPSJmb250LXN0 eWxlOm5vcm1hbDtmb250LXdlaWdodDo0MDA7dGV4dC10cmFuc2Zvcm06bm9uZTtmb250LXNpemU6 MTQuMHB4O2NvbG9yOiMwMDAwMDA7Zm9udC1mYW1pbHk6YXJpYWw7Ij5BYm91dCB0aGUgcmVmZXJl bmNlcyB0byBJU08gZG9jdW1lbnMsIEkgdGhpbmsgaXQgaXMgYSBnZW5lcmFsIGlzc3VlIGZvciBJ RVRGIGRyYWZ0cy48L3NwYW4+PC9kaXY+PC9kaXY+PGRpdiAgc3R5bGU9ImNsZWFyOmJvdGg7Ij48 ZGl2ICBzdHlsZT0iZm9udC12YXJpYW50LWxpZ2F0dXJlczpub3JtYWw7Zm9udC12YXJpYW50LWNh cHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4dC1pbmRlbnQ6LjBweDt3aWRvd3M6MjtiYWNr Z3JvdW5kLWNvbG9yOiNmZmZmZmY7dGV4dC1kZWNvcmF0aW9uLXN0eWxlOmluaXRpYWw7dGV4dC1k ZWNvcmF0aW9uLWNvbG9yOmluaXRpYWw7Y2xlYXI6Ym90aDsiPjxzcGFuICBzdHlsZT0iZm9udC1z dHlsZTpub3JtYWw7Zm9udC13ZWlnaHQ6NDAwO3RleHQtdHJhbnNmb3JtOm5vbmU7Zm9udC1zaXpl OjE0LjBweDtjb2xvcjojMDAwMDAwO2ZvbnQtZmFtaWx5OmFyaWFsOyI+PGJyID48L3NwYW4+PC9k aXY+PC9kaXY+PGRpdiAgc3R5bGU9ImNsZWFyOmJvdGg7Ij48ZGl2ICBzdHlsZT0iZm9udC12YXJp YW50LWxpZ2F0dXJlczpub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246 c3RhcnQ7dGV4dC1pbmRlbnQ6LjBweDt3aWRvd3M6MjtiYWNrZ3JvdW5kLWNvbG9yOiNmZmZmZmY7 dGV4dC1kZWNvcmF0aW9uLXN0eWxlOmluaXRpYWw7dGV4dC1kZWNvcmF0aW9uLWNvbG9yOmluaXRp YWw7Y2xlYXI6Ym90aDsiPjwvZGl2PjxkaXYgIHN0eWxlPSJmb250LXZhcmlhbnQtbGlnYXR1cmVz Om5vcm1hbDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWlu ZGVudDouMHB4O3dpZG93czoyO2JhY2tncm91bmQtY29sb3I6I2ZmZmZmZjt0ZXh0LWRlY29yYXRp b24tc3R5bGU6aW5pdGlhbDt0ZXh0LWRlY29yYXRpb24tY29sb3I6aW5pdGlhbDtjbGVhcjpib3Ro OyI+PC9kaXY+PGRpdiAgc3R5bGU9ImZvbnQtdmFyaWFudC1saWdhdHVyZXM6bm9ybWFsO2ZvbnQt dmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50Oi4wcHg7d2lk b3dzOjI7YmFja2dyb3VuZC1jb2xvcjojZmZmZmZmO3RleHQtZGVjb3JhdGlvbi1zdHlsZTppbml0 aWFsO3RleHQtZGVjb3JhdGlvbi1jb2xvcjppbml0aWFsO2NsZWFyOmJvdGg7Ij48c3BhbiAgc3R5 bGU9ImZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtd2VpZ2h0OjQwMDt0ZXh0LXRyYW5zZm9ybTpub25l O2ZvbnQtc2l6ZToxNC4wcHg7Y29sb3I6IzAwMDAwMDtmb250LWZhbWlseTphcmlhbDsiPkhvdyBk b2VzIHRoZSBvdGhlciBJRVRGIGRyYWZ0cyBtYWtlIHRoZSByZWZlcmVuY2VzIHRvIElTTyBkb2N1 bWVudHM/IElTTyBkb2N1bWVudHMgYXJlIG9mdGVuIHJlZmVyZW5jZWQgYnkgSUVURiBkcmFmdHMu PC9zcGFuPjwvZGl2PjxkaXYgIHN0eWxlPSJmb250LXZhcmlhbnQtbGlnYXR1cmVzOm5vcm1hbDtm b250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDouMHB4 O3dpZG93czoyO2JhY2tncm91bmQtY29sb3I6I2ZmZmZmZjt0ZXh0LWRlY29yYXRpb24tc3R5bGU6 aW5pdGlhbDt0ZXh0LWRlY29yYXRpb24tY29sb3I6aW5pdGlhbDtjbGVhcjpib3RoOyI+PC9kaXY+ PGRpdiAgc3R5bGU9ImZvbnQtdmFyaWFudC1saWdhdHVyZXM6bm9ybWFsO2ZvbnQtdmFyaWFudC1j YXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50Oi4wcHg7d2lkb3dzOjI7YmFj a2dyb3VuZC1jb2xvcjojZmZmZmZmO3RleHQtZGVjb3JhdGlvbi1zdHlsZTppbml0aWFsO3RleHQt ZGVjb3JhdGlvbi1jb2xvcjppbml0aWFsO2NsZWFyOmJvdGg7Ij48L2Rpdj48L2Rpdj48ZGl2ICBz dHlsZT0iY2xlYXI6Ym90aDsiPjxkaXYgIHN0eWxlPSJmb250LXZhcmlhbnQtbGlnYXR1cmVzOm5v cm1hbDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVu dDouMHB4O3dpZG93czoyO2JhY2tncm91bmQtY29sb3I6I2ZmZmZmZjt0ZXh0LWRlY29yYXRpb24t c3R5bGU6aW5pdGlhbDt0ZXh0LWRlY29yYXRpb24tY29sb3I6aW5pdGlhbDtjbGVhcjpib3RoOyI+ PHNwYW4gIHN0eWxlPSJmb250LXN0eWxlOm5vcm1hbDtmb250LXdlaWdodDo0MDA7dGV4dC10cmFu c2Zvcm06bm9uZTtmb250LXNpemU6MTQuMHB4O2NvbG9yOiMwMDAwMDA7Zm9udC1mYW1pbHk6YXJp YWw7Ij48YnIgPjwvc3Bhbj48L2Rpdj48L2Rpdj48ZGl2ICBzdHlsZT0iY2xlYXI6Ym90aDsiPjxk aXYgIHN0eWxlPSJmb250LXZhcmlhbnQtbGlnYXR1cmVzOm5vcm1hbDtmb250LXZhcmlhbnQtY2Fw czpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDouMHB4O3dpZG93czoyO2JhY2tn cm91bmQtY29sb3I6I2ZmZmZmZjt0ZXh0LWRlY29yYXRpb24tc3R5bGU6aW5pdGlhbDt0ZXh0LWRl Y29yYXRpb24tY29sb3I6aW5pdGlhbDtjbGVhcjpib3RoOyI+PHNwYW4gIHN0eWxlPSJmb250LXN0 eWxlOm5vcm1hbDtmb250LXdlaWdodDo0MDA7dGV4dC10cmFuc2Zvcm06bm9uZTtmb250LXNpemU6 MTQuMHB4O2NvbG9yOiMwMDAwMDA7Zm9udC1mYW1pbHk6YXJpYWw7Ij5UaGFua3MsPC9zcGFuPjwv ZGl2PjwvZGl2PjxkaXYgIHN0eWxlPSJjbGVhcjpib3RoOyI+PGRpdiAgc3R5bGU9ImZvbnQtdmFy aWFudC1saWdhdHVyZXM6bm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWdu OnN0YXJ0O3RleHQtaW5kZW50Oi4wcHg7d2lkb3dzOjI7YmFja2dyb3VuZC1jb2xvcjojZmZmZmZm O3RleHQtZGVjb3JhdGlvbi1zdHlsZTppbml0aWFsO3RleHQtZGVjb3JhdGlvbi1jb2xvcjppbml0 aWFsO2NsZWFyOmJvdGg7Ij48c3BhbiAgc3R5bGU9ImZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtd2Vp Z2h0OjQwMDt0ZXh0LXRyYW5zZm9ybTpub25lO2ZvbnQtc2l6ZToxNC4wcHg7Y29sb3I6IzAwMDAw MDtmb250LWZhbWlseTphcmlhbDsiPjxiciA+PC9zcGFuPjwvZGl2PjwvZGl2PjxkaXYgIHN0eWxl PSJjbGVhcjpib3RoOyI+PGRpdiAgc3R5bGU9ImZvbnQtdmFyaWFudC1saWdhdHVyZXM6bm9ybWFs O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50Oi4w cHg7d2lkb3dzOjI7YmFja2dyb3VuZC1jb2xvcjojZmZmZmZmO3RleHQtZGVjb3JhdGlvbi1zdHls ZTppbml0aWFsO3RleHQtZGVjb3JhdGlvbi1jb2xvcjppbml0aWFsO2NsZWFyOmJvdGg7Ij48L2Rp dj48ZGl2ICBzdHlsZT0iZm9udC12YXJpYW50LWxpZ2F0dXJlczpub3JtYWw7Zm9udC12YXJpYW50 LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4dC1pbmRlbnQ6LjBweDt3aWRvd3M6Mjti YWNrZ3JvdW5kLWNvbG9yOiNmZmZmZmY7dGV4dC1kZWNvcmF0aW9uLXN0eWxlOmluaXRpYWw7dGV4 dC1kZWNvcmF0aW9uLWNvbG9yOmluaXRpYWw7Y2xlYXI6Ym90aDsiPjxzcGFuICBzdHlsZT0iZm9u dC1zdHlsZTpub3JtYWw7Zm9udC13ZWlnaHQ6NDAwO3RleHQtdHJhbnNmb3JtOm5vbmU7Zm9udC1z aXplOjE0LjBweDtjb2xvcjojMDAwMDAwO2ZvbnQtZmFtaWx5OmFyaWFsOyI+S2luZCBSZWdhcmRz PC9zcGFuPjwvZGl2PjxkaXYgIHN0eWxlPSJmb250LXZhcmlhbnQtbGlnYXR1cmVzOm5vcm1hbDtm b250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDouMHB4 O3dpZG93czoyO2JhY2tncm91bmQtY29sb3I6I2ZmZmZmZjt0ZXh0LWRlY29yYXRpb24tc3R5bGU6 aW5pdGlhbDt0ZXh0LWRlY29yYXRpb24tY29sb3I6aW5pdGlhbDtjbGVhcjpib3RoOyI+PHNwYW4g IHN0eWxlPSJmb250LXN0eWxlOm5vcm1hbDtmb250LXdlaWdodDo0MDA7dGV4dC10cmFuc2Zvcm06 bm9uZTtmb250LXNpemU6MTQuMHB4O2NvbG9yOiMwMDAwMDA7Zm9udC1mYW1pbHk6YXJpYWw7Ij5L ZXBlbmc8L3NwYW4+PC9kaXY+PGRpdiAgc3R5bGU9ImZvbnQtdmFyaWFudC1saWdhdHVyZXM6bm9y bWFsO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50 Oi4wcHg7d2lkb3dzOjI7YmFja2dyb3VuZC1jb2xvcjojZmZmZmZmO3RleHQtZGVjb3JhdGlvbi1z dHlsZTppbml0aWFsO3RleHQtZGVjb3JhdGlvbi1jb2xvcjppbml0aWFsO2NsZWFyOmJvdGg7Ij48 L2Rpdj48ZGl2ICBzdHlsZT0iZm9udC12YXJpYW50LWxpZ2F0dXJlczpub3JtYWw7Zm9udC12YXJp YW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4dC1pbmRlbnQ6LjBweDt3aWRvd3M6 MjtiYWNrZ3JvdW5kLWNvbG9yOiNmZmZmZmY7dGV4dC1kZWNvcmF0aW9uLXN0eWxlOmluaXRpYWw7 dGV4dC1kZWNvcmF0aW9uLWNvbG9yOmluaXRpYWw7Y2xlYXI6Ym90aDsiPjxzcGFuICBzdHlsZT0i Zm9udC1zdHlsZTpub3JtYWw7Zm9udC13ZWlnaHQ6NDAwO3RleHQtdHJhbnNmb3JtOm5vbmU7Zm9u dC1mYW1pbHk6VGFob21hLEFyaWFsLFNUSGVpdGksU2ltU3VuO2ZvbnQtc2l6ZToxNC4wcHg7Y29s b3I6IzAwMDAwMDsiPuKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKA lOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKA lOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKA lOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlDwvc3Bhbj48L2Rpdj48ZGl2 ICBzdHlsZT0iZm9udC12YXJpYW50LWxpZ2F0dXJlczpub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6 bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4dC1pbmRlbnQ6LjBweDt3aWRvd3M6MjtiYWNrZ3Jv dW5kLWNvbG9yOiNmZmZmZmY7dGV4dC1kZWNvcmF0aW9uLXN0eWxlOmluaXRpYWw7dGV4dC1kZWNv cmF0aW9uLWNvbG9yOmluaXRpYWw7Y2xlYXI6Ym90aDsiPjwvZGl2PjxkaXYgIHN0eWxlPSJmb250 LXZhcmlhbnQtbGlnYXR1cmVzOm5vcm1hbDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1h bGlnbjpzdGFydDt0ZXh0LWluZGVudDouMHB4O3dpZG93czoyO2JhY2tncm91bmQtY29sb3I6I2Zm ZmZmZjt0ZXh0LWRlY29yYXRpb24tc3R5bGU6aW5pdGlhbDt0ZXh0LWRlY29yYXRpb24tY29sb3I6 aW5pdGlhbDtjbGVhcjpib3RoOyI+PGgzICBzdHlsZT0ibWFyZ2luOjIuMHB4IC4wcHg7Ym94LXNp emluZzpib3JkZXItYm94O2xpbmUtaGVpZ2h0OjEuMjtmb250LXZhcmlhbnQtbGlnYXR1cmVzOm5v cm1hbDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpsZWZ0O3RleHQtaW5kZW50 Oi4wcHg7d2lkb3dzOjI7YmFja2dyb3VuZC1jb2xvcjojZmZmZmZmO3RleHQtZGVjb3JhdGlvbi1z dHlsZTppbml0aWFsO3RleHQtZGVjb3JhdGlvbi1jb2xvcjppbml0aWFsOyI+PHNwYW4gIHN0eWxl PSJmb250LWZhbWlseTpsdWNpZGEgR3JhbmRlLFZlcmRhbmE7Zm9udC1zaXplOjE4LjBweDtmb250 LXdlaWdodDpub3JtYWw7Y29sb3I6IzIxMjUyOTtmb250LXN0eWxlOm5vcm1hbDt0ZXh0LXRyYW5z Zm9ybTpub25lOyI+UmU6IFtUTFNdIERyYWZ0IGZvciBTTSBjaXBoZXIgc3VpdGVzIHVzZWQgaW4g VExTMS4zPC9zcGFuPjwvaDM+PHAgIGNsYXNzPSJtc2ctaGVhZGVyIiBpZD0ibXNnLWluZm8iIHN0 eWxlPSJsaW5lLWhlaWdodDoyMy44cHg7Ym94LXNpemluZzpib3JkZXItYm94O21hcmdpbjouMHB4 IC4wcHggMjAuMHB4O2ZvbnQtdmFyaWFudC1saWdhdHVyZXM6bm9ybWFsO2ZvbnQtdmFyaWFudC1j YXBzOm5vcm1hbDt0ZXh0LWFsaWduOmxlZnQ7dGV4dC1pbmRlbnQ6LjBweDt3aWRvd3M6MjtiYWNr Z3JvdW5kLWNvbG9yOiNmZmZmZmY7dGV4dC1kZWNvcmF0aW9uLXN0eWxlOmluaXRpYWw7dGV4dC1k ZWNvcmF0aW9uLWNvbG9yOmluaXRpYWw7Ij48c3BhbiAgY2xhc3M9InBpcGUiIGlkPSJtc2ctZnJv bSIgc3R5bGU9ImZvbnQtZmFtaWx5Omx1Y2lkYSBHcmFuZGUsVmVyZGFuYTtjb2xvcjojODA4MDgw O2ZvbnQtc2l6ZToxNC4wcHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC13ZWlnaHQ6NDAwO3RleHQt dHJhbnNmb3JtOm5vbmU7Ym94LXNpemluZzpib3JkZXItYm94OyI+UmVuZSBTdHJ1aWsgJmx0Ozxh ICBocmVmPSJtYWlsdG86cnN0cnVpay5leHRAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayIgc3R5 bGU9Im91dGxpbmU6bm9uZTt0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO2NvbG9yOiMxZTU0OTQ7 Ij5yc3RydWlrLmV4dEBnbWFpbC5jb208L2E+Jmd0Ozwvc3Bhbj48c3BhbiAgc3R5bGU9ImZvbnQt ZmFtaWx5Omx1Y2lkYSBHcmFuZGUsVmVyZGFuYTtjb2xvcjojODA4MDgwO2ZvbnQtc2l6ZToxNC4w cHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC13ZWlnaHQ6NDAwO3RleHQtdHJhbnNmb3JtOm5vbmU7 Ij4mbmJzcDs8L3NwYW4+PHNwYW4gIGNsYXNzPSJwaXBlIiBpZD0ibXNnLWRhdGUiIHN0eWxlPSJm b250LWZhbWlseTpsdWNpZGEgR3JhbmRlLFZlcmRhbmE7Y29sb3I6IzgwODA4MDtmb250LXNpemU6 MTQuMHB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtd2VpZ2h0OjQwMDt0ZXh0LXRyYW5zZm9ybTpu b25lO2JveC1zaXppbmc6Ym9yZGVyLWJveDsiPlRodSwgMTUgQXVndXN0IDIwMTkgMTU6MzQgVVRD PC9zcGFuPjxhICBjbGFzcz0idG9nZ2xlIiBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYu b3JnL2FyY2gvYnJvd3NlL3Rscy8/aW5kZXg9TkhiSE9HdHNSMVM1Y0NyOW5XTjlfc2R5VGdnJmFt cDtnYnQ9MSMiIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iZm9udC1mYW1pbHk6bHVjaWRhIEdyYW5k ZSxWZXJkYW5hO2ZvbnQtc2l6ZToxNC4wcHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC13ZWlnaHQ6 NDAwO3RleHQtdHJhbnNmb3JtOm5vbmU7b3V0bGluZTpub25lO3RleHQtZGVjb3JhdGlvbjpub25l O2NvbG9yOiMzMzdhYjc7Ym94LXNpemluZzpib3JkZXItYm94O2JhY2tncm91bmQtY29sb3I6dHJh bnNwYXJlbnQ7Ij5TaG93IGhlYWRlcjwvYT48L3A+PGRpdiAgY2xhc3M9Im1zZy1wYXlsb2FkIiBz dHlsZT0iYm94LXNpemluZzpib3JkZXItYm94O2ZvbnQtdmFyaWFudC1saWdhdHVyZXM6bm9ybWFs O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOmxlZnQ7dGV4dC1pbmRlbnQ6LjBw eDt3aWRvd3M6MjtiYWNrZ3JvdW5kLWNvbG9yOiNmZmZmZmY7dGV4dC1kZWNvcmF0aW9uLXN0eWxl OmluaXRpYWw7dGV4dC1kZWNvcmF0aW9uLWNvbG9yOmluaXRpYWw7Ij48cHJlICBjbGFzcz0id29y ZHdyYXAiIHN0eWxlPSJmb250LXN0eWxlOm5vcm1hbDtmb250LXdlaWdodDo0MDA7dGV4dC10cmFu c2Zvcm06bm9uZTtsaW5lLWhlaWdodDoyMC43cHg7Ym94LXNpemluZzpib3JkZXItYm94O2ZvbnQt ZmFtaWx5OlNGTW9uby1SZWd1bGFyLE1lbmxvLE1vbmFjbyxDb25zb2xhcyxMaWJlcmF0aW9uIE1v bm8sQ291cmllciBOZXcsbW9ub3NwYWNlO2ZvbnQtc2l6ZToxMi4ycHg7bWFyZ2luLXRvcDouMHB4 O21hcmdpbi1ib3R0b206MS4wcmVtO292ZXJmbG93OmF1dG87ZGlzcGxheTpibG9jaztjb2xvcjoj MjEyNTI5O292ZXJmbG93LXdyYXA6bm9ybWFsO3dvcmQtYnJlYWs6bm9ybWFsO3BhZGRpbmc6LjBw eDsiPkhpIFBhdWw6CgpJIHRyaWVkIGFuZCBsb29rIHVwIHRoZSBkb2N1bWVudHMgR01ULjAwMDkt MjAxMiBhbmQgR0JULjMyOTE4LjUtMjAxNiBvbiAKdGhlIChub24tc2VjdXJlZCkgd2Vic2l0ZXMg eW91IHJlZmVyZW5jZWQsIGJ1dCBvbmx5IGZvdW5kIENoaW5lc2UgCnZlcnNpb25zIChhbmQgQ2hp bmVzZSB3ZWJzaXRlIG5hdmlnYXRpb24gcGFuZWxzIFtwYXJkb24gbXkgcG9vciBsYW5ndWFnZSAK c2tpbGxzIGhlcmVdKS4gU2luY2UgdGhlIElTTyBkb2N1bWVudHMgYXJlIG5vdCBhdmFpbGFibGUg dG8gdGhlIGdlbmVyYWwgCnB1YmxpYyB3aXRob3V0IHBheW1lbnQsIGl0IHdvdWxkIGJlIGhlbHBm dWwgdG8gaGF2ZSBhIGZyZWVseSBhdmFpbGFibGUgCmRvY3VtZW50IChpbiBFbmdsaXNoKSBmcm9t IGFuIGF1dGhvcml0YXRpdmUgc291cmNlLiBIYXZpbmcgc3VjaCBhIApyZWZlcmVuY2UgYXZhaWxh YmxlIHdvdWxkIGJlIGhlbHBmdWwgdG8gdGhlIElFVEYgY29tbXVuaXR5IChhbmQgCnJlc2VhcmNo ZXJzKS4gUGxlYXNlIG5vdGUgdGhhdCBCU0kgcHJvdmlkZXMgaXRzIHNwZWNpZmljYXRpb25zIGlu IEdlcm1hbiAKYW5kIEVuZ2xpc2gsIHNvIGFzIHRvIGZvc3RlciB1c2Uvc3R1ZHkgYnkgdGhlIGNv bW11bml0eS4gSWYgdGhlIENoaW5lc2UgCm5hdGlvbmFsIGFsZ29yaXRobXMgd291bGQgYmUgYXZh aWxhYmxlIGluIHNpbWlsYXIgZm9ybSwgdGhpcyB3b3VsZCBzZXJ2ZSAKYSBzaW1pbGFyIHB1cnBv c2UuCgpGWUkgLSBJIGFtIGludGVyZXN0ZWQgaW4gZnVsbCBkZXRhaWxzIGFuZCBzb21lIHRpbWUg bGFzdCB5ZWFyIEkgdHJpZWQgdG8gCmRvd25sb2FkIHNwZWNzLCBidXQgb25seSBQYXJ0cyAyLCA0 LCBhbmQgNSB3ZXJlIGF2YWlsYWJsZSBbMV0sIFsyXSwgWzNdLCAKbm90IFBhcnRzIDEgYW5kIDMu CgpCZXN0IHJlZ2FyZHMsIFJlbmUKClsxXSBDaGluYSBFQ0MgLSBQdWJsaWMgS2V5IENyeXB0b2dy YXBoaWMgQWxnb3JpdGhtIFNNMiBCYXNlZCBvbiBFQ0MgLSAKUGFydCA1IC0gUGFyYW1ldGVyIERl ZmluaXRpb24gKFNFTUIsIEp1bHkgMjQsIDIwMTgpClsyXSBDaGluYSBFQ0MgLSBQdWJsaWMgS2V5 IENyeXB0b2dyYXBoaWMgQWxnb3JpdGhtIFNNMiBCYXNlZCBvbiBFQ0MgLSAKUGFydCAyIC0gRGln aXRhbCBTaWduYXR1cmUgQWxnb3JpdGhtIChTRU1CLCBKdWx5IDI0LCAyMDE4KQpbM10gQ2hpbmEg RUNDIC0gUHVibGljIEtleSBDcnlwdG9ncmFwaGljIEFsZ29yaXRobSBTTTIgQmFzZWQgb24gRUND IC0gClBhcnQgNCAtIFB1YmxpYyBLZXkgRW5jcnlwdGlvbiBBbGdvcml0aG0gKFNFTUIsIEp1bHkg MjQsIDIwMTgpCgpPbiA4LzE1LzIwMTkgMTA6MTYgQU0sIFBhdWwgWWFuZyB3cm90ZToKJmd0OyBI aSBhbGwsCiZndDsKJmd0OyBJIGhhdmUgc3VibWl0dGVkIGEgbmV3IGludGVybmV0IGRyYWZ0IHRv IGludHJvZHVjZSB0aGUgU00gY2lwaGVyIAomZ3Q7IHN1aXRlcyBpbnRvIFRMUyAxLjMgcHJvdG9j b2wuCiZndDsKJmd0OyA8YSAgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LXlhbmctdGxzLXRsczEzLXNtLXN1aXRlcy0wMCIgdGFyZ2V0PSJfYmxhbmsiIHN0eWxlPSJvdXRs aW5lOm5vbmU7dGV4dC1kZWNvcmF0aW9uOm5vbmU7Y29sb3I6IzMzN2FiNztib3gtc2l6aW5nOmJv cmRlci1ib3g7YmFja2dyb3VuZC1jb2xvcjp0cmFuc3BhcmVudDsiPmh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC15YW5nLXRscy10bHMxMy1zbS1zdWl0ZXMtMDA8L2E+CiZndDsKJmd0 OyBTTSBjcnlwdG9ncmFwaGljIGFsZ29yaXRobXMgYXJlIG9yaWdpbmFsbHkgYSBzZXQgb2YgQ2hp bmVzZSBuYXRpb25hbCAKJmd0OyBhbGdvcml0aG1zIGFuZCBub3cgaGF2ZSBiZWVuIChvciBiZWlu ZykgYWNjZXB0ZWQgYnkgSVNPIGFzIAomZ3Q7IGludGVybmF0aW9uYWwgc3RhbmRhcmRzLCBpbmNs dWRpbmcgU00yIHNpZ25hdHVyZSBhbGdvcml0aG0sIFNNMyBoYXNoIAomZ3Q7IGZ1bmN0aW9uIGFu ZCBTTTQgYmxvY2sgY2lwaGVyLiBUaGVzZSBhbGdvcml0aG1zIGhhdmUgYWxyZWFkeSBiZWVuIAom Z3Q7IHN1cHBvcnRlZCBzb21lIHRpbWUgYWdvIGJ5IHNldmVyYWwgd2lkZWx5IHVzZWQgb3BlbiBz b3VyY2UgCiZndDsgY3J5cHRvZ3JhcGhpYyBsaWJyYXJpZXMgaW5jbHVkaW5nIE9wZW5TU0wsIEJv dW5jeUNhc3RsZSwgQm90YW4sIGV0Yy4KJmd0OwomZ3Q7IENvbnNpZGVyaW5nIFRMUzEuMyBpcyBi ZWluZyBncmFkdWFsbHkgYWRvcHRlZCBpbiBDaGluYSdzIGludGVybmV0IAomZ3Q7IGluZHVzdHJ5 LCBpdCdzIGltcG9ydGFudCB0byBoYXZlIGEgbm9ybWF0aXZlIGRlZmluaXRpb24gb24gaG93IHRv IHVzZSAKJmd0OyB0aGUgU00gYWxnb3JpdGhtcyB3aXRoIFRMUzEuMywgZXNwZWNpYWxseSBmb3Ig dGhlIG1vYmlsZSBpbnRlcm5ldCAKJmd0OyBzY2VuYXJpby4gQW50IEZpbmFuY2lhbCBpcyB0aGUg Y29tcGFueSB3aG8gZGV2ZWxvcHMgdGhlIG1hcmtldCBsZWFkaW5nIAomZ3Q7IG1vYmlsZSBhcHAg J0FsaXBheScgYW5kIHN1cHBvcnRzIHBheW1lbnQgc2VydmljZXMgZm9yIEFsaWJhYmEgCiZndDsg ZS1jb21tZXJjZSBidXNpbmVzcy4gV2UgaGlnaGx5IGFyZSBkZXBlbmRpbmcgb24gdGhlIG5ldyBU TFMxLjMgCiZndDsgcHJvdG9jb2wgZm9yIGJvdGggcGVyZm9ybWFuY2UgYW5kIHNlY3VyaXR5IHB1 cnBvc2VzLiBXZSBleHBlY3QgdG8gaGF2ZSAKJmd0OyBtb3JlIGRlcGxveW1lbnQgb2YgVExTMS4z IGNhcGFibGUgYXBwbGljYXRpb25zIGluIENoaW5hJ3MgaW50ZXJuZXQgCiZndDsgaW5kdXN0cnkg YnkgdGhpcyBzdGFuZGFyZGl6YXRpb24gYXR0ZW1wdHMuCiZndDsKJmd0OyBJdCdzIHZlcnkgYXBw cmVjaWF0ZWQgdG8gaGF2ZSBjb21tZW50cyBmcm9tIHRoZSBJRVRGIFRMUyBsaXN0IDotKQomZ3Q7 CiZndDsgTWFueSB0aGFua3MhCiZndDsKJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXwomZ3Q7IFRMUyBtYWlsaW5nIGxpc3QKJmd0OyA8YSAgaHJlZj0i bWFpbHRvOlRMU0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIHN0eWxlPSJvdXRsaW5lOm5vbmU7 dGV4dC1kZWNvcmF0aW9uOm5vbmU7Y29sb3I6IzMzN2FiNztib3gtc2l6aW5nOmJvcmRlci1ib3g7 YmFja2dyb3VuZC1jb2xvcjp0cmFuc3BhcmVudDsiPlRMU0BpZXRmLm9yZzwvYT4KJmd0OyA8YSAg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMiIHRhcmdldD0i X2JsYW5rIiBzdHlsZT0ib3V0bGluZTpub25lO3RleHQtZGVjb3JhdGlvbjpub25lO2NvbG9yOiMz MzdhYjc7Ym94LXNpemluZzpib3JkZXItYm94O2JhY2tncm91bmQtY29sb3I6dHJhbnNwYXJlbnQ7 Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RsczwvYT48L3ByZT48L2Rp dj48L2Rpdj48c3BhbiAgc3R5bGU9ImZvbnQtZmFtaWx5OlRhaG9tYSxBcmlhbCxTVEhlaXRpLFNp bVN1bjtmb250LXNpemU6MTQuMHB4O2NvbG9yOiMwMDAwMDA7Ij48YnIgPjwvc3Bhbj48L2Rpdj48 ZGl2ID48YnIgPjwvZGl2PjwvZGl2Pg== ------=ALIBOUNDARY_18741_4cf23940_5d5657a8_194a316-- From nobody Fri Aug 16 00:35:24 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56441120124; Fri, 16 Aug 2019 00:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NsZpZaK3NQA0; Fri, 16 Aug 2019 00:35:15 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F35E1120120; Fri, 16 Aug 2019 00:35:14 -0700 (PDT) Received: from [129.192.10.3] (helo=[10.149.1.218]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hyWlT-00081j-7b; Fri, 16 Aug 2019 09:35:11 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: <20190816033931.GI88236@kduck.mit.edu> Date: Fri, 16 Aug 2019 09:35:09 +0200 Cc: The IESG , draft-ietf-tls-grease@ietf.org, tls-chairs@ietf.org, sean@sn3rd.com, tls@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <156588466304.15861.9219490518200903631.idtracker@ietfa.amsl.com> <20190816033931.GI88236@kduck.mit.edu> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1565940915;d8ca0a51; X-HE-SMSGID: 1hyWlT-00081j-7b Archived-At: Subject: Re: [TLS] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-tls-grease-03=3A_=28with_COMMENT=29?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 07:35:18 -0000 Hi Ben, Thanks for the explanation. I would think this is actually a PS given it extents a protocol based on = the extension point this protocol provides. Maybe it is not really = adding a new function but it also kind of is: I would call probing for = non-compliant implementations a protocol function. I mean if we would = specify greasing for a new protocol, I think it would simply be part of = the main spec. Mirja > On 16. Aug 2019, at 05:39, Benjamin Kaduk wrote: >=20 > On Thu, Aug 15, 2019 at 08:57:43AM -0700, Mirja K=C3=BChlewind via = Datatracker wrote: >> Mirja K=C3=BChlewind has entered the following ballot position for >> draft-ietf-tls-grease-03: No Objection >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-tls-grease/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> Sorry one more comment/question I forgot earlier: Why is this = document >> informational? Shouldn't it be at least experimental? >=20 > I added a note to the shepherd writeup's "intended document status" = entry: >=20 > AD NOTE: Note that this has been successfully deployed for > over a year; it's not really an "experiment" anymore but rather > a useful thing that people do, both in TLS and elsewhere. This > is informational in the sense that "here is a thing you can do, > and some information about why you might want to do it". There's > no real protocol -- you send some codepoints and expect the other > endpoint to not change behavior as a result -- so it doesn't make = sense > as a proposed standard. I suppose one could argue that it is a BCP > since it is for the health of the ecosystem, but that does not really > feel like a good match. So to me, Informational is the right status. >=20 > -Ben >=20 From nobody Fri Aug 16 00:39:20 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB23120125; Fri, 16 Aug 2019 00:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HkyZTxGs1OSU; Fri, 16 Aug 2019 00:39:16 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD7E612011A; Fri, 16 Aug 2019 00:39:15 -0700 (PDT) Received: from [129.192.10.3] (helo=[10.149.1.218]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hyWpN-0003Qd-Ro; Fri, 16 Aug 2019 09:39:13 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: Date: Fri, 16 Aug 2019 09:39:13 +0200 Cc: Benjamin Kaduk , draft-ietf-tls-grease@ietf.org, "" , The IESG , Sean Turner , tls-chairs Content-Transfer-Encoding: quoted-printable Message-Id: <6BD4AC5B-BA54-4BED-8B9B-ECA298E8BF0F@kuehlewind.net> References: <156588205271.15865.9243229289426203471.idtracker@ietfa.amsl.com> <20190815152405.GS88236@kduck.mit.edu> <44BDC996-0E18-48BE-A700-C49A101330F8@kuehlewind.net> To: David Benjamin X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1565941155;c0845f8a; X-HE-SMSGID: 1hyWpN-0003Qd-Ro Archived-At: Subject: Re: [TLS] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-tls-grease-03=3A_=28with_COMMENT=29?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 07:39:18 -0000 Hi David, See below. > On 15. Aug 2019, at 20:52, David Benjamin wrote: >=20 > On Thu, Aug 15, 2019 at 11:30 AM Mirja Kuehlewind = wrote: > Hi Ben, >=20 > See line. >=20 > > On 15. Aug 2019, at 17:24, Benjamin Kaduk wrote: > >=20 > > On Thu, Aug 15, 2019 at 08:14:12AM -0700, Mirja K=C3=BChlewind via = Datatracker wrote: > >> Mirja K=C3=BChlewind has entered the following ballot position for > >> draft-ietf-tls-grease-03: No Objection > >>=20 > >> When responding, please keep the subject line intact and reply to = all > >> email addresses included in the To and CC lines. (Feel free to cut = this > >> introductory paragraph, however.) > >>=20 > >>=20 > >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > >> for more information about IESG DISCUSS and COMMENT positions. > >>=20 > >>=20 > >> The document, along with other ballot positions, can be found here: > >> https://datatracker.ietf.org/doc/draft-ietf-tls-grease/ > >>=20 > >>=20 > >>=20 > >> = ---------------------------------------------------------------------- > >> COMMENT: > >> = ---------------------------------------------------------------------- > >>=20 > >> One comment/question: I think I didn't quite understand what a = client is > >> supposed to do if the connection fails with use of greasing = values...? The > >> security considerations seems to indicate that you should not try = to re-connect > >> without use of grease but rather just fail completely...? Also = should you cache > >> the information that greasing failed maybe? > >=20 > > I'll let the authors chime in, but I think the sense of the security > > considerations is more that we are preventing the fallback from = being > > needed "in production due to "real" negotiation failures. Falling = back on > > GREASE failure is not as bad, provided that you follow-up with the = failing > > peer out of band to try to get it fixed. > > I don't know how much value there would be in caching the = grease-intolerate > > status; ideally it would almost-never happen. >=20 > Okay, then I think it would be nice to say something more in the = document, about fallback at least. >=20 > Ben's description is right. If deploying a new TLS feature results in = too many interop failures with existing buggy servers, that feature = becomes difficult to deploy and there is a lot of pressure to apply some = sort of mitigation like a fallback. That's no good. GREASE's goal is to = avoid the interop failures to begin with. The text was not meant to = imply that you should do any sort of fallback. >=20 > What change did you have in mind? The current text says: >=20 > > Historically, when interoperability problems arise in deploying new = TLS features, implementations have used a fallback retry on error with = the feature disabled. This allows an active attacker to silently disable = the new feature. By preventing a class of such interoperability = problems, GREASE reduces the need for this kind of fallback. >=20 > That reads to me as describing historical fallbacks, rather than = recommending new ones. (Indeed you shouldn't do fallbacks. Fallbacks are = bad. They break downgrade protection.) I was thinking about adding some new text somewhere else in the document = that give a recommendation if you should fallback on grease and when. > =20 > >=20 > >> And a note on normative language: > >>=20 > >> "Implementations sending multiple > >> GREASE extensions in a single block thus must ensure the same = value > >> is not selected twice." > >> Should this be a "MUST"? > >=20 > > I asked for this to be changed away from a "MUST" -- RFC 8466 = already has > > this prohibition on duplicated values; we're just calling it out = again here > > since randomly picking values (with replacement, which is the easy = way to > > code it) can result in collisions, that are forbidden by 8446. >=20 > Ah okay, that=E2=80=99s fine. Didn=E2=80=99t check 8446. > >=20 > >> Also this is an interesting MUST: > >> "... MUST correctly ignore unknown values..." > >> While this is the whole point of the document, I assume this is = already > >> normatively specified in RFC8446 and therefore it could make sense = to use > >> non-formative language here... > >=20 > > I think you are correct, but I personally do not mind the extra = normative > > force in this case. >=20 > I just found this actually particularly weird because of the = =E2=80=9Ccorrectly=E2=80=9D. To me it reads like =E2=80=9Cplease, please = finally follow normative specification we do in RFCs=E2=80=9D=E2=80=A6 = anyway=E2=80=A6 I after all don't really mind if you pick on or the = other. >=20 > Mirja >=20 >=20 >=20 > >=20 > > -Ben > >=20 > >=20 >=20 From nobody Fri Aug 16 07:58:21 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D112412008D for ; Fri, 16 Aug 2019 07:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZx8eAB0IQKA for ; Fri, 16 Aug 2019 07:58:17 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCCDF12083C for ; Fri, 16 Aug 2019 07:58:16 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id t6so6750775ios.7 for ; Fri, 16 Aug 2019 07:58:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=y1urM1WMpx4+JNZ2UcsUTq055h/98fL9InNMgCahoYY=; b=I1SK4wMYhmNrioe9mZ68/wpHJdAzzxdph+Dh2mnMLNXRanldmYusGe/wEp+dvhAOIU AWxAjouMdDcTpw5mcMWr7gvCftUItraez1sr5bO6OU9pBxKB7mrhdxzUOtX+quk+8TLt Bj/6YP4Gum3kJQFSiHFYtEEIu1eHh3rygLraD22P+qsHLPDGULPuU4DrnPf2/hx+7ico MSi5NryO3fP9pCsfcPh1HTM7WjzuUgUc20sx91q0kXmb69XoO3jWqBofbtvQKXt5FgHR oRDFY5Aiu5lvd246cITHWGKshbjg7vQlpKhXgJ78/QAR2hf0Bh017AHH762IYn3eKFoY 38bA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=y1urM1WMpx4+JNZ2UcsUTq055h/98fL9InNMgCahoYY=; b=UhyVYhuAVCHUa+aJvu34UnKHWiUI/BznljgBKkO1OkC/49y4rmkZdxWeiHDHG6v9YV 71A4gqYWaGxGJshK/sZND5Y3aZdIGTDVSa8gffpBLJuWg12Xujk/6/DqzJyywGTKppuG SeyqVmnonAVF1SKeyhe6TZEnPmixCGAlVlQEsLTxbFbvwfRxmEPrCK2H1hvpKQxyYFfg 3zkzcCe7ZWdOmlKHApScZcYZFfp55kn8E1E4BnXobe0S1qDGH2T2reqMR8qssk+Y1OVr mkBjferuP/eboGMiH2+Ybz2exsy0VkomxAOnGxtlLde7kflbGjuzxv6BBCX2URDeXNgy GvLQ== X-Gm-Message-State: APjAAAU8K+X8J0y4hxof9Uw7x/vadvhL1Y+bJBFouJWHWDMV795aN5Cu XEE80yiLtkbJrxTpD4WoZq0= X-Google-Smtp-Source: APXvYqy71pVFYLLSUUVl9M41xWZYUdiapp12TYHfDPeOkbF5DTcZP/ulb6NHN0Tkli1Eso9DLXwYSg== X-Received: by 2002:a02:c916:: with SMTP id t22mr11146770jao.24.1565967496212; Fri, 16 Aug 2019 07:58:16 -0700 (PDT) Received: from ?IPv6:2607:fea8:69f:f5eb:8c17:f632:dc51:32cb? ([2607:fea8:69f:f5eb:8c17:f632:dc51:32cb]) by smtp.gmail.com with ESMTPSA id u17sm4449625iob.57.2019.08.16.07.58.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Aug 2019 07:58:15 -0700 (PDT) To: Kepeng Li Cc: "'tls@ietf.org'" , =?UTF-8?B?5p2o5rSLKOWHr+eUsyk=?= References: <3350587b-f768-425f-a759-3ed7ce2e6b27.kepeng.lkp@alibaba-inc.com> From: Rene Struik Message-ID: <1e07a7cc-b316-6a1d-6f59-b352ffbd74b8@gmail.com> Date: Fri, 16 Aug 2019 10:58:13 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <3350587b-f768-425f-a759-3ed7ce2e6b27.kepeng.lkp@alibaba-inc.com> Content-Type: multipart/alternative; boundary="------------0577005CD90846E02168E06F" Content-Language: en-US Archived-At: Subject: [TLS] (offline) Re: Draft for SM cipher suites used in TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 14:58:20 -0000 This is a multi-part message in MIME format. --------------0577005CD90846E02168E06F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Arguably, "national" crypto specifications garnish more stature if these are made available to the pubic by that standard-setting body itself (who, thereby, acts as its authoritative source), without deference to a third party (that may, independently from the originator, enforce document control [e.g., by effectuating technical changes or enforcing controlled dissemination]). Since your draft introducing SM cipher suites with TLS1.3 appeals to the authority of a standard-setting authority, easy availability of the full and accredited technical documentation to the IETF community helps in scrutiny and, e.g., evaluating claims in the security considerations section. On 8/16/2019 3:06 AM, Kepeng Li wrote: > Hi Rene and all, > > > Since the ISO documents are not available to the general > public without payment, it would be helpful to have a freely > available > document (in English) from an authoritative source. Having > such a > reference available would be helpful to the IETF community > (and > researchers). > About the references to ISO documens, I think it is a general issue > for IETF drafts. > > How does the other IETF drafts make the references to ISO documents? > ISO documents are often referenced by IETF drafts. > > Thanks, > > Kind Regards > Kepeng > ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€” > > > Re: [TLS] Draft for SM cipher suites used in TLS1.3 > > Rene Struik >Thu, > 15 August 2019 15:34 UTCShow header > > > Hi Paul: > > I tried and look up the documents GMT.0009-2012 and GBT.32918.5-2016 on > the (non-secured) websites you referenced, but only found Chinese > versions (and Chinese website navigation panels [pardon my poor language > skills here]). Since the ISO documents are not available to the general > public without payment, it would be helpful to have a freely available > document (in English) from an authoritative source. Having such a > reference available would be helpful to the IETF community (and > researchers). Please note that BSI provides its specifications in German > and English, so as to foster use/study by the community. If the Chinese > national algorithms would be available in similar form, this would serve > a similar purpose. > > FYI - I am interested in full details and some time last year I tried to > download specs, but only Parts 2, 4, and 5 were available [1], [2], [3], > not Parts 1 and 3. > > Best regards, Rene > > [1] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC - > Part 5 - Parameter Definition (SEMB, July 24, 2018) > [2] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC - > Part 2 - Digital Signature Algorithm (SEMB, July 24, 2018) > [3] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC - > Part 4 - Public Key Encryption Algorithm (SEMB, July 24, 2018) > > On 8/15/2019 10:16 AM, Paul Yang wrote: > > Hi all, > > > > I have submitted a new internet draft to introduce the SM cipher > > suites into TLS 1.3 protocol. > > > > https://tools.ietf.org/html/draft-yang-tls-tls13-sm-suites-00 > > > > SM cryptographic algorithms are originally a set of Chinese national > > algorithms and now have been (or being) accepted by ISO as > > international standards, including SM2 signature algorithm, SM3 hash > > function and SM4 block cipher. These algorithms have already been > > supported some time ago by several widely used open source > > cryptographic libraries including OpenSSL, BouncyCastle, Botan, etc. > > > > Considering TLS1.3 is being gradually adopted in China's internet > > industry, it's important to have a normative definition on how to use > > the SM algorithms with TLS1.3, especially for the mobile internet > > scenario. Ant Financial is the company who develops the market leading > > mobile app 'Alipay' and supports payment services for Alibaba > > e-commerce business. We highly are depending on the new TLS1.3 > > protocol for both performance and security purposes. We expect to have > > more deployment of TLS1.3 capable applications in China's internet > > industry by this standardization attempts. > > > > It's very appreciated to have comments from the IETF TLS list :-) > > > > Many thanks! > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------0577005CD90846E02168E06F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Arguably, "national" crypto specifications garnish more stature if these are made available to the pubic by that standard-setting body itself (who, thereby, acts as its authoritative source), without deference to a third party (that may, independently from the originator, enforce document control [e.g., by effectuating technical changes or enforcing controlled dissemination]).

Since your draft introducing SM cipher suites with TLS1.3 appeals to the authority of a standard-setting authority, easy availability of the full and accredited technical documentation to the IETF community helps in scrutiny and, e.g., evaluating claims in the security considerations section.

On 8/16/2019 3:06 AM, Kepeng Li wrote:
Hi Rene and all,

> Since the ISO documents are not available to the general 
> public without payment, it would be helpful to have a freely available 
> document (in English) from an authoritative source. Having such a 
> reference available would be helpful to the IETF community (and 
> researchers).
About the references to ISO documens, I think it is a general issue for IETF drafts.

How does the other IETF drafts make the references to ISO documents? ISO documents are often referenced by IETF drafts.

Thanks,

Kind Regards
Kepeng
ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”ā€”

Re: [TLS] Draft for SM cipher suites used in TLS1.3

Rene Struik <rstruik.ext@gmail.com>Ā Thu, 15 August 2019 15:34 UTCShow header

Hi Paul:

I tried and look up the documents GMT.0009-2012 and GBT.32918.5-2016 on 
the (non-secured) websites you referenced, but only found Chinese 
versions (and Chinese website navigation panels [pardon my poor language 
skills here]). Since the ISO documents are not available to the general 
public without payment, it would be helpful to have a freely available 
document (in English) from an authoritative source. Having such a 
reference available would be helpful to the IETF community (and 
researchers). Please note that BSI provides its specifications in German 
and English, so as to foster use/study by the community. If the Chinese 
national algorithms would be available in similar form, this would serve 
a similar purpose.

FYI - I am interested in full details and some time last year I tried to 
download specs, but only Parts 2, 4, and 5 were available [1], [2], [3], 
not Parts 1 and 3.

Best regards, Rene

[1] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC - 
Part 5 - Parameter Definition (SEMB, July 24, 2018)
[2] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC - 
Part 2 - Digital Signature Algorithm (SEMB, July 24, 2018)
[3] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC - 
Part 4 - Public Key Encryption Algorithm (SEMB, July 24, 2018)

On 8/15/2019 10:16 AM, Paul Yang wrote:
> Hi all,
>
> I have submitted a new internet draft to introduce the SM cipher 
> suites into TLS 1.3 protocol.
>
> https://tools.ietf.org/html/draft-yang-tls-tls13-sm-suites-00
>
> SM cryptographic algorithms are originally a set of Chinese national 
> algorithms and now have been (or being) accepted by ISO as 
> international standards, including SM2 signature algorithm, SM3 hash 
> function and SM4 block cipher. These algorithms have already been 
> supported some time ago by several widely used open source 
> cryptographic libraries including OpenSSL, BouncyCastle, Botan, etc.
>
> Considering TLS1.3 is being gradually adopted in China's internet 
> industry, it's important to have a normative definition on how to use 
> the SM algorithms with TLS1.3, especially for the mobile internet 
> scenario. Ant Financial is the company who develops the market leading 
> mobile app 'Alipay' and supports payment services for Alibaba 
> e-commerce business. We highly are depending on the new TLS1.3 
> protocol for both performance and security purposes. We expect to have 
> more deployment of TLS1.3 capable applications in China's internet 
> industry by this standardization attempts.
>
> It's very appreciated to have comments from the IETF TLS list :-)
>
> Many thanks!
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--------------0577005CD90846E02168E06F-- From nobody Fri Aug 16 08:05:43 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ADD5120052 for ; Fri, 16 Aug 2019 08:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.194 X-Spam-Level: X-Spam-Status: No, score=-4.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYP1dob2g2DP for ; Fri, 16 Aug 2019 08:05:39 -0700 (PDT) Received: from llmx3.ll.mit.edu (LLMX3.LL.MIT.EDU [129.55.12.49]) (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 EAC56120047 for ; Fri, 16 Aug 2019 08:05:37 -0700 (PDT) Received: from LLE2K16-MBX03.mitll.ad.local (LLE2K16-MBX03.mitll.ad.local) by llmx3.ll.mit.edu (unknown) with ESMTPS id x7GF5ZXQ047355 for ; Fri, 16 Aug 2019 11:05:35 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: TLS Thread-Topic: =?utf-8?B?W1RMU10gUmXvvJogRHJhZnQgZm9yIFNNIGNpcGhlciBzdWl0ZXMgdXNlZCBp?= =?utf-8?Q?n_TLS1.3?= Thread-Index: AQHVVAJVK0PrqEdKSEeegSRe0UZt+Kb94BWA Date: Fri, 16 Aug 2019 15:05:33 +0000 Message-ID: References: <3dfe43fe-b81c-4fc1-91af-3a1e8565794e.kepeng.lkp@alibaba-inc.com> In-Reply-To: <3dfe43fe-b81c-4fc1-91af-3a1e8565794e.kepeng.lkp@alibaba-inc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1b.0.190715 x-originating-ip: [172.25.1.85] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3648798333_348709734" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-16_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908160159 Archived-At: Subject: Re: [TLS] =?utf-8?q?Re=EF=BC=9A_Draft_for_SM_cipher_suites_used_in_T?= =?utf-8?q?LS1=2E3?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 15:05:42 -0000 --B_3648798333_348709734 Content-type: multipart/alternative; boundary="B_3648798333_411256471" --B_3648798333_411256471 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable AFAIK, all the ISO standards that IETF refers to, were defined elsewhere fi= rst, i.e., ISO defined them based on some open submissions, publications, et= c. =20 I fully agree with Rene =E2=80=93 if you want the specs standardized, provide the= complete specs, including the missing parts 1 and 3. =20 =20 =20 From: TLS on behalf of Kepeng Li Reply-To: Kepeng Li Date: Friday, August 16, 2019 at 3:15 AM To: "rstruik.ext" , TLS Subject: [TLS] Re=EF=BC=9A Draft for SM cipher suites used in TLS1.3 =20 Hi Rene and all, =20 > Since the ISO documents are not available to the general=20 > public without payment, it would be helpful to have a freely available=20 > document (in English) from an authoritative source. Having such a=20 > reference available would be helpful to the IETF community (and=20 > researchers). About the references to ISO documens, I think it is a general issue for IET= F drafts. =20 How does the other IETF drafts make the references to ISO documents? ISO do= cuments are often referenced by IETF drafts. =20 Thanks, =20 Kind Regards Kepeng =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 Re: [TLS] Draft for SM cipher suites used in TLS1.3 Rene Struik Thu, 15 August 2019 15:34 UTCShow heade= r Hi Paul: =20 I tried and look up the documents GMT.0009-2012 and GBT.32918.5-2016 on=20 the (non-secured) websites you referenced, but only found Chinese=20 versions (and Chinese website navigation panels [pardon my poor language=20 skills here]). Since the ISO documents are not available to the general=20 public without payment, it would be helpful to have a freely available=20 document (in English) from an authoritative source. Having such a=20 reference available would be helpful to the IETF community (and=20 researchers). Please note that BSI provides its specifications in German=20 and English, so as to foster use/study by the community. If the Chinese=20 national algorithms would be available in similar form, this would serve=20 a similar purpose. =20 FYI - I am interested in full details and some time last year I tried to=20 download specs, but only Parts 2, 4, and 5 were available [1], [2], [3],=20 not Parts 1 and 3. =20 Best regards, Rene =20 [1] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC -=20 Part 5 - Parameter Definition (SEMB, July 24, 2018) [2] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC -=20 Part 2 - Digital Signature Algorithm (SEMB, July 24, 2018) [3] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC -=20 Part 4 - Public Key Encryption Algorithm (SEMB, July 24, 2018) =20 On 8/15/2019 10:16 AM, Paul Yang wrote: > Hi all, >=20 > I have submitted a new internet draft to introduce the SM cipher=20 > suites into TLS 1.3 protocol. >=20 > https://tools.ietf.org/html/draft-yang-tls-tls13-sm-suites-00 >=20 > SM cryptographic algorithms are originally a set of Chinese national=20 > algorithms and now have been (or being) accepted by ISO as=20 > international standards, including SM2 signature algorithm, SM3 hash=20 > function and SM4 block cipher. These algorithms have already been=20 > supported some time ago by several widely used open source=20 > cryptographic libraries including OpenSSL, BouncyCastle, Botan, etc. >=20 > Considering TLS1.3 is being gradually adopted in China's internet=20 > industry, it's important to have a normative definition on how to use=20 > the SM algorithms with TLS1.3, especially for the mobile internet=20 > scenario. Ant Financial is the company who develops the market leading=20 > mobile app 'Alipay' and supports payment services for Alibaba=20 > e-commerce business. We highly are depending on the new TLS1.3=20 > protocol for both performance and security purposes. We expect to have=20 > more deployment of TLS1.3 capable applications in China's internet=20 > industry by this standardization attempts. >=20 > It's very appreciated to have comments from the IETF TLS list :-) >=20 > Many thanks! >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls =20 =20 --B_3648798333_411256471 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

AFAIK, all the ISO standards that IETF refers to, = were defined elsewhere first, i.e., ISO defined them based on some op= en submissions, publications, etc.

&nb= sp;

I fully agree with Rene =E2=80=93 if you want the = specs standardized, provide the complete specs, including the missing parts = 1 and 3.

 

 

 

From: TLS &= lt;tls-bounces@ietf.org> on behalf of Kepeng Li <kepeng.lkp@alibaba-in= c.com>
Reply-To: Kepeng Li <kepeng.lkp@alibaba-inc.com>Date: Friday, August 16, 2019 at 3:15 AM
To: "rstrui= k.ext" <rstruik.ext@gmail.com>, TLS <tls@ietf.org>
Su= bject: [TLS] Re=EF=BC=9A Draft= for SM cipher suites used in TLS1.3

 

Hi Rene and all,

 

> Since the ISO documents are not available to the general <=
/o:p>
> public without payment, it would be helpful to have a freely a=
vailable 
> document (in English) from an authoritative sou=
rce. Having such a 
> reference available would be helpful =
to the IETF community (and 
> researchers).

About the references to ISO documens, I think it is a general issue for IE= TF drafts.

 

How does th= e other IETF drafts make the references to ISO documents? ISO documents are = often referenced by IETF drafts.

=

 

Thanks,

 

<= span style=3D'font-size:10.5pt;font-family:"Arial",sans-serif;color:black'>Kin= d Regards

Kepeng

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94

Re: [TLS] Draft for SM cipher suites used in TLS1.3<= o:p>

Rene Struik <rstruik.ext@gmail.c= om> Thu, 15 August 20= 19 15:34 UTCShow header

Hi Paul:=

 
I tried and look up the documents GMT.0009-2012 and GBT.32918.5-2016=
 on 
the (non-secured) websites you referenced, but only found Chinese =

vers=
ions (and Chinese website navigation panels [pardon my poor language 
skills=
 here]). Since the ISO documents are not available to the general 
public wi=
thout payment, it would be helpful to have a freely available 
document (in =
English) from an authoritative source. Having such a 
reference available wo=
uld be helpful to the IETF community (and 
researchers). Please note that BS=
I provides its specifications in German 
and English, so as to foster use/st=
udy by the community. If the Chinese 
national algorithms would be available=
 in similar form, this would serve 
a similar purpose.
 
=
FYI - I am int=
erested in full details and some time last year I tried to 
download specs, =
but only Parts 2, 4, and 5 were available [1], [2], [3], <=
/pre>
not Parts 1 and 3.=

 
Best regards, Rene
 
[1] China ECC - Public Key Cryptographic A=
lgorithm SM2 Based on ECC - 
Part 5 - Parameter Definition (SEMB, July 24, 2=
018)
[2] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC - <=
o:p>
=
Part 2 - Digital Signature Algorithm (SEMB, July 24, 2018)=

[3] China ECC - P=
ublic Key Cryptographic Algorithm SM2 Based on ECC - 
Part 4 - Public Key En=
cryption Algorithm (SEMB, July 24, 2018)
 
On 8/15/2019 10:16 AM, Paul =
Yang wrote:
> Hi all,
> 
> I have submitted a new internet dra=
ft to introduce the SM cipher 
> suites into TLS 1.3 protocol.=

>&=
nbsp;
> https://t=
ools.ietf.org/html/draft-yang-tls-tls13-sm-suites-00
>&nb=
sp;
&=
gt; SM cryptographic algorithms are originally a set of Chinese national 
&g=
t; algorithms and now have been (or being) accepted by ISO as 
> internat=
ional standards, including SM2 signature algorithm, SM3 hash 
=
> function =
and SM4 block cipher. These algorithms have already been <=
/pre>
> supported som=
e time ago by several widely used open source 
> cryptographic libraries =
including OpenSSL, BouncyCastle, Botan, etc.
> 
> Considering TLS=
1.3 is being gradually adopted in China's internet 
<=
pre style=3D'margin-left:.5in;line-height:15.55pt;background:white'>> industry, it's impo=
rtant to have a normative definition on how to use 
<=
pre style=3D'margin-left:.5in;line-height:15.55pt;background:white'>> the SM algorithms w=
ith TLS1.3, especially for the mobile internet 
> scenario. Ant Financial=
 is the company who develops the market leading 
> mobile app 'Alipay' an=
d supports payment services for Alibaba 
> e-commerce business. We highly=
 are depending on the new TLS1.3 
> protocol for both performance and sec=
urity purposes. We expect to have 
> more deployment of TLS1.3 capable ap=
plications in China's internet 
> industry by this standardization attemp=
ts.
> 
> It's very appreciated to have comments from the IETF TLS=
 list :-)
> 
> Many thanks!
> 
> _____________________=
__________________________
> TLS mailing list
> TLS=
@ietf.org
> https://w=
ww.ietf.org/mailman/listinfo/tls

 

 

--B_3648798333_411256471-- --B_3648798333_348709734 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUfQYJKoZIhvcNAQcCoIIUbjCCFGoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghJDMIIE8zCCA9ugAwIBAgITWQADyHaxtc8GrYDIrgAAAAPIdjANBgkqhkiG9w0BAQsF ADBRMQswCQYDVQQGEwJVUzEfMB0GA1UECgwWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoG A1UECwwDUEtJMRMwEQYDVQQDDApNSVRMTCBDQS01MB4XDTE5MDMyNjE4NDEwMVoXDTIyMDMy NTE4NDEwMVowYTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRv cnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCzD7FJptOjLaaidxt9QIIH/dAblMrT ESMm4ggEBR0KqbmSkRY+x45ed8E2u9fJuFWKAgwU+vJo//kzavEpAAuyhe61Z+4noWIvV0sY WkUs+ffLh+29MxDs8Mt1++mDAC1+NyLCPN8QNPRJVu7ECRtmKu3DiAtuEKva3J7lZyVVNE+3 e9HQJlr/3alifN4sg/NxOFMTKMMEq15RgOhDyAudnNSs2IesRnoKTZq/Jykwbm0fg06ePSBR /k2JuYNW8/UZnU7d/Ez2n1NEtZkQw5QzWrC27ijf7FFQxM9yLToJneFVK+krQsfvtMbHGpnz Yo9keqc3Uxb13P4mpDbZiIBTAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUMzH1HGnW9jHVrCuy FAmJhhljwLcwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFC/vu8YNHbvpav6sZ/MHOwh2 9ktZMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvbGxj YTUwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUv Z2V0dG8vbGxjYTUwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9 BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+K cwIBZAIBCDAiBgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAZBgNVHREEEjAQ gQ51cmlAbGwubWl0LmVkdTAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMCcGCSsGAQQBgjcU AgQaHhgATABMAFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBACztsHHc HX+FTwlhjHUUU+AcLyX3hgIdnTovNmPWVhVgzpN25AotcwODhCwuaLNoLsC0OHRISFUvkqHg 7aeZ9CiDOL4KwlNZgzGpDlqZ/AgMJ+JodWz0XqoNm4wYNs2rl7sEzLe70yPVyzTYlhECYnex UxE4hL334w/cx+Mb8vKn+/EQ9NFKVfCJ8X1dDkCA19EkZu2DbFF2oAM0kr6JX2dNx1rChTMZ iOSkGkKKpnVNFBMl/uw8qH8XrD+slPhLpTQg5t9l0pCtkJSMnrMovPvgwhlOP7yCLdPYYTwY IjwvUeqj1VAvid80L9vevRY1D6NDz/eWfoqCxXxPvtue//owggTAMIIDqKADAgECAgEGMA0G CSqGSIb3DQEBCwUAMFYxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJv cmF0b3J5MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD01JVExMIFJvb3QgQ0EtMjAeFw0xNzAz MDIxMjAwMDBaFw0yNjAzMDIyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQg TGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLDANQS0kxEzARBgNVBAMMCk1JVExMIENBLTUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCnmoMOvTkfw7nq19mrWazGaa+Q83Uv 0+ATXT3q6kr+WExIMIZ87C74WCcRXpvO7uvx7HvMsYWAFHW93wQwhjytxHIOZgKNJ4VnGVDU l+KI7g0n9+Zjt3hB3HhHbcvbe9+Y4jz+XzCiLl2OaYvICKbxvbBSCLtPEeZQ6x6Tb6EK0ym0 gvYeHO3kuuY+SJHJMltbrLnIVLxjZrNVS77zXKvu6Q3hSdkRIB7kJgEXfL+p/z/2p94bEEZ2 TnQz0TkOjG+Jq7UlXlFRtvsYcDPEQD3UNkZsWcXgC1hXG8TGknUcAhlGxVhlKlFLmNd7342s eGy2s9YxNDnSE+eXTtb0I5LLAgMBAAGjggGcMIIBmDASBgNVHRMBAf8ECDAGAQH/AgEAMB0G A1UdDgQWBBQv77vGDR276Wr+rGfzBzsIdvZLWTAfBgNVHSMEGDAWgBT/ycllTFOA8akMPCGu girH7vgy+zAOBgNVHQ8BAf8EBAMCAYYwZwYIKwYBBQUHAQEEWzBZMC4GCCsGAQUFBzAChiJo dHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExSQ0EyMCcGCCsGAQUFBzABhhtodHRwOi8v b2NzcC5sbC5taXQuZWR1L29jc3AwNAYDVR0fBC0wKzApoCegJYYjaHR0cDovL2NybC5sbC5t aXQuZWR1L2dldGNybC9MTFJDQTIwgZIGA1UdIASBijCBhzANBgsqhkiG9xICAQMBBjANBgsq hkiG9xICAQMBCDANBgsqhkiG9xICAQMBBzANBgsqhkiG9xICAQMBCTANBgsqhkiG9xICAQMB CjANBgsqhkiG9xICAQMBCzANBgsqhkiG9xICAQMBDjANBgsqhkiG9xICAQMBDzANBgsqhkiG 9xICAQMBEDANBgkqhkiG9w0BAQsFAAOCAQEAMJYRwLPJ91K7e2mA2Nj10W0o5JMHYkaa+ctL 8/xY8QzIHFI5Ij+iydpPN9KCYn/4Sy80T3aNoYkFlS0GRQXhf0nsiY7TWJwAKw4AiO/yJ37/ oRKRgtyRicvaJ6RjlHCXBOalFLw9UtpodP4/idC51lxzsolaQZraBjVe7PL95PhS7D+22Nff InzLdIb1DBf54NwOVfPIgABtxH1fhZrja7EhR9RoUw5E1O6iWaAuP/xWhSTQFWlhyA0/kkIi 9/HXaY0hYnhcjcbPPqjpyfIhSFjjXhjqK7t2wPrSrBFLFUbnLiNlgQHrvNYF5IqgIfnSBWIr m3rfLhpZZJ/xJ7Yf6DCCA4owggJyoAMCAQICAQEwDQYJKoZIhvcNAQELBQAwVjELMAkGA1UE BhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEY MBYGA1UEAxMPTUlUTEwgUm9vdCBDQS0yMB4XDTE2MDQyMDEyMDAwMFoXDTM1MDQxOTIzNTk1 OVowVjELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAK BgNVBAsTA1BLSTEYMBYGA1UEAxMPTUlUTEwgUm9vdCBDQS0yMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAv3WoBEGOOJtm4ucvaf6vKIFPs8watCd6Smwq/XeRNo7P3jPIxNPw F398RGDUmPJIXA7idzD6j0opFIW+kLqYye9e788PV0dqaJlX8818fNDbSE+8B6hieqKTR7Vf OI74UVQEUKVRFuRFw6uVYuvgew2Tj/C2dEee37eruQl5nHkbV2OsWnZ7O+yt+etd6HRcaXLl P9q8WKgA3B7vkOVIMCKoAuaWj+BFq7K+WNkiyi/KdOH9JmOpbyRK4jcA7xbLnF8JFUSNg5c4 Y1BJrFaZtkCeG6Nm9p524GllkRFzPgpj8VicV+AK+9rY07dTx02kYotTnKuy0YxBAwsUXxAQ EwIDAQABo2MwYTAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBT/ycllTFOA8akMPCGugirH 7vgy+zAfBgNVHSMEGDAWgBT/ycllTFOA8akMPCGugirH7vgy+zAOBgNVHQ8BAf8EBAMCAYYw DQYJKoZIhvcNAQELBQADggEBAHqYfEf/3J5aMKhlYQ0PnUAbMB8jZSr9/HvjfOF00crFUCfS rqG8JQwo+S/iq66gcp62FEgJ0fQkDgVg6m+C2ETo1LoWiSxhYCfcSIQECljlXwR8wFSayF82 2S69IqvHhdq4d58jU6gYi6ssjU4vwsvsVLRJKk/m/Cg/w8gW6YHM5ahBD6/5Ccel2fI7oSms kO991+otrC11YfDwCFvz7Am0r+K9iVhSWta4hmIuV0YBia07eZKSO02LPgQ8YOz3ku0Yt+mh 8VWRKux2CcYjMpk+WDV0BMp75tqb6pqBFkcKvEBXqxg+8+G/umjii4H0c5kvJhaQyykbmOKm xO9IcJIwggT2MIID3qADAgECAhNZAAA7OX5fo0OiIK0RAAAAADs5MA0GCSqGSIb3DQEBCwUA MFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYD VQQLDANQS0kxEzARBgNVBAMMCk1JVExMIENBLTUwHhcNMTgwODI4MjE0NTI5WhcNMjEwODI3 MjE0NTI5WjBhMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9y eTEPMA0GA1UECxMGUGVvcGxlMSAwHgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAI5Vc19RKc/69lmwhogDOjjzPQbmc8s6 Z6rzP6oUHAswDICqZWwPt+FTbKr0YTAqRNsTEN4YiW0fORK+fNRvClo0pdiCqj3DwDQZLRI4 Dak1yTsUtVe35oomQbXtO+0A0L/CowYri/UKeRG1i1/0cXSf4mAx0ed9wh2SordAb8o2FuOU 0B2ppnqjro1VFugHHX6QOggaeLFOprT5gnTZUmqM37/d4DGB9XDdTQi144zQSwSWKkaUThsy D9CHSRNcB79HBvlZGSM+BkIbayPdhQAuz4yKsOZEWPx/6LnMotzBevSswnCDf+u9ajCgMnje WbrZRN+xoYEuhycXyK2b8/MCAwEAAaOCAbUwggGxMB0GA1UdDgQWBBTZUpq7Rsccv42yU9UQ 4wvojOl4pzAOBgNVHQ8BAf8EBAMCBSAwHwYDVR0jBBgwFoAUL++7xg0du+lq/qxn8wc7CHb2 S1kwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9sbGNh NTBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9n ZXR0by9sbGNhNTAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3NwMD0G CSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXr0HCD6+0g AgFkAgEJMCUGA1UdJQQeMBwGBFUdJQAGCCsGAQUFBwMEBgorBgEEAYI3CgMEMBkGA1UdEQQS MBCBDnVyaUBsbC5taXQuZWR1MBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgwJwYJKwYBBAGC NxQCBBoeGABMAEwAVQBzAGUAcgBFAG4AYwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEACyN6 Yhi9LApOPpf60ypSV2WmV3sqnrsrdlPTW+am4wMK/M/5PZmt5jFVtXaErkWYdrbMdjeo2o/G 9N2DnrFOhz7kDYM9HC9AH/rWCfoSkI/C2N6Rq/uDnRJfao61wyv37qKtanNdkp+reyLxdVPn foVrD/VZli4UV28u4XBuYDkjXPyyiH+bb395FnxOtTA3Uz41Ohpdvr6oLPEuy0IP4MPfK5wD mS6GXcB+ze9sYEp+DJxE7WAbkW5Y536WPl/rfWm/k6ZC1KPVSRM7mS+atk44VOgzPLXkl6Tu 6zY8tMczfr5F0om1JfN8G50s4QDUGtsMgzW+LXVDhFD24xnUojGCAf4wggH6AgEBMGgwUTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoMFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsM A1BLSTETMBEGA1UEAwwKTUlUTEwgQ0EtNQITWQADyHaxtc8GrYDIrgAAAAPIdjANBglghkgB ZQMEAgEFAKBpMC8GCSqGSIb3DQEJBDEiBCCXttr4LsjlqT2JJuBYQka9O0lffJOAnn+neKQQ snQqzDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xOTA4MTYx NTA1MzNaMA0GCSqGSIb3DQEBAQUABIIBAHH1fnDeTUVolXhvq3T2NT9xFKWqcZ9BgQFzuMWq 1550zor2Dnh1yzmi9gCXLc1HR6qywM9Ole2Z68JADK9ikfKIyspiR1aC//QvBigo4wG9F+yr /FWE98PCoHz+sdYG2wLgDnr95ex3+ih1Qe44r+vWEyg1TOdjdw3JxKfrOQju4IanTmGJ4niS ByecZZf3OHkmgOkcX/qVaDmKDVaEe1IVqjHHZuMATr3d/JCnYqiIHUkuTZfb+kIQPL+cAHKr 04Q8dRxUrcPWYhNG82bOcdBpJHXZl7YI7vr9e/RKPYe2ZdNM0FqoOm1W+CsuklWHqp/zl1G+ 76b4QM3vL6ZybgU= --B_3648798333_348709734-- From nobody Fri Aug 16 08:07:01 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8C3120052 for ; Fri, 16 Aug 2019 08:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ga91SutifNML for ; Fri, 16 Aug 2019 08:06:57 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68C6A120047 for ; Fri, 16 Aug 2019 08:06:57 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id x7GEuRZW029743; Fri, 16 Aug 2019 16:06:53 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=T7pUf20w/SkJaulFR58igVLKLCMbbDfVMZxL87LGmP0=; b=AMXAucH3BpyBWzKTc2iQYYJrhARnvpHCTQiD9JoOBtpfa2Fil4NfTRfdvYvgtgZlAFSC l8i1rVGGnHCpm0sU/kr3IKsIRINUqR1Q2Kc+bbd7KgfziVJEw3YADtLOJ/MmRcoXOANe QuG+Dmb9b4QY496pjmc7ak/Gnd7mtlU/ZbYZ3+y9tdpWh1lhjC7cKg03G4rcYiQ6S7y2 PJ2VGaZdPzdqPujOL0qVe0kdbOkrV/sdA2kz1ttvQ9KJtGC8nDL+ROtxL6aIYwzziFN5 X+Ha4NTdbxfD54lEnCnuISDAOOMa8qXMqJzwEZNn1R6TVHBeZ3Fn8W8B6MdapLF45p5T 9w== Received: from prod-mail-ppoint3 (prod-mail-ppoint3.akamai.com [96.6.114.86] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2ubf8nm67k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 16 Aug 2019 16:06:53 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x7GF39fL026747; Fri, 16 Aug 2019 11:06:52 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint3.akamai.com with ESMTP id 2u9s918k6t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 16 Aug 2019 11:06:52 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 16 Aug 2019 11:06:50 -0400 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.1473.005; Fri, 16 Aug 2019 11:06:50 -0400 From: "Salz, Rich" To: Kepeng Li CC: "'tls@ietf.org'" Thread-Topic: [TLS] (offline) Re: Draft for SM cipher suites used in TLS1.3 Thread-Index: AQHVVEMWHZ8LpEHPb025DYn6/X4p8Kb93+8A Date: Fri, 16 Aug 2019 15:06:50 +0000 Message-ID: References: <3350587b-f768-425f-a759-3ed7ce2e6b27.kepeng.lkp@alibaba-inc.com> <1e07a7cc-b316-6a1d-6f59-b352ffbd74b8@gmail.com> In-Reply-To: <1e07a7cc-b316-6a1d-6f59-b352ffbd74b8@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1c.0.190812 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.114.146] Content-Type: multipart/alternative; boundary="_000_A644F3ECB8354D3CA1FB5D33547F1C84akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-16_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=412 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908160159 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:5.22.84,1.0.8 definitions=2019-08-16_06:2019-08-16,2019-08-16 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 mlxlogscore=387 phishscore=0 suspectscore=0 spamscore=0 mlxscore=0 clxscore=1011 bulkscore=0 lowpriorityscore=0 malwarescore=0 impostorscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1906280000 definitions=main-1908160158 Archived-At: Subject: Re: [TLS] (offline) Re: Draft for SM cipher suites used in TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 15:07:00 -0000 --_000_A644F3ECB8354D3CA1FB5D33547F1C84akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PkhvdyBkb2VzIHRoZSBvdGhlciBJRVRGIGRyYWZ0cyBtYWtlIHRoZSByZWZlcmVuY2VzIHRvIElT TyBkb2N1bWVudHM/IElTTyBkb2N1bWVudHMgYXJlIG9mdGVuIHJlZmVyZW5jZWQgYnkgSUVURiBk cmFmdHMuDQoNCg0KDQpDYW4geW91IHBvaW50IHRvIHNwZWNpZmljIGRyYWZ0cyB3aGVyZSAqbm9y bWF0aXZlKiByZWZlcmVuY2VzIGFyZSBvbmx5IGF2YWlsYWJsZSBmb3IgcGF5aW5nIGEgZmVlPyAg SSBndWVzcyB0aGF0IHRoZXJlIGFyZSBzb21lLCBidXQgSSBkb27igJl0IGtub3cgb2YgYW55LiBZ b3VyIGNsYWltIGltcGxpZXMgZGVmaW5pdGl2ZSBrbm93bGVkZ2UsIGhvd2V2ZXIuDQoNCg0KDQpJ biBnZW5lcmFsLCB0aGUgSUVURiB0ZW5kcyB0byBkaXNsaWtlIHVzaW5nIHN0YW5kYXJkcyB3aGVy ZSB0aGUgc3BlY2lmaWNhdGlvbiBpcyBub3QgZnJlZWx5IGF2YWlsYWJsZSBpbiBFbmdsaXNoLiBU aGF0IGxhc3QgcGFydCwgaW4gRW5nbGlzaCwgaXMgcGVyaGFwcyBuYXJyb3ctbWluZGVkIHRoZXNl IGRheXMsIGJ1dCB0aGUgSUVURiB3b3JrcyBpbiBFbmdsaXNoLiAgQWxzbywgbm90ZSB0aGF0IEkg c2FpZCDigJx0ZW5kcyB0byBkaXNsaWtl4oCdIGFuZCBkaWRu4oCZdCBjbGFpbSBhIGhhcmQgcnVs ZSBhbHdheXMgZW5mb3JjZWQuICBJbiB0aGUgcGFzdCwgd2hlcmUgdGhlcmUgaGF2ZSBiZWVuIGlz c3VlcywgaXQgaGFzIGJlZW4gbm90IHVuY29tbW9uIHRvIHdyaXRlIGludGVybmV0LWRyYWZ0cyBh bmQgcHVibGlzaCB0aHJvdWdoIENGUkc7IHNlZSBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L3JnL2NmcmcvZG9jdW1lbnRzLyBmb3IgbWFueSBleGFtcGxlcy4gU29tZXRpbWVzIHRoZXkgYXJl IHB1Ymxpc2hlZCBhcyBpbmRpdmlkdWFsIHN0cmVhbSBSRkPigJlzOyBzZWUgaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL3JmYzcwOTEgZm9yIGEgaGlnaGx5IGFwcGxpY2FibGUgZXhhbXBsZS4N Cg0KDQo= --_000_A644F3ECB8354D3CA1FB5D33547F1C84akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <84D97E102F589F47A0A4AD6FCCBDA07C@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFz Ow0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KaDMNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk7 DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgMyBDaGFyIjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTMuNXB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCWZvbnQtd2VpZ2h0OmJvbGQ7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dl ZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7 bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1h cmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxl ZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRN TCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bh bi5IZWFkaW5nM0NoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhlYWRpbmcgMyBDaGFyIjsNCgltc28t c3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUtbGluazoiSGVhZGluZyAzIjsNCglmb250LWZh bWlseToiQ2FsaWJyaSBMaWdodCIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUYzNzYzO30NCnAubXNn LWhlYWRlciwgbGkubXNnLWhlYWRlciwgZGl2Lm1zZy1oZWFkZXINCgl7bXNvLXN0eWxlLW5hbWU6 bXNnLWhlYWRlcjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGlu Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4u cGlwZQ0KCXttc28tc3R5bGUtbmFtZTpwaXBlO30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLXJpZ2h0OjEuMGluO2JhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mZ3Q7PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj5Ib3cgZG9lcyB0aGUgb3RoZXIgSUVURiBkcmFmdHMgbWFrZSB0aGUgcmVmZXJlbmNl cyB0byBJU08gZG9jdW1lbnRzPw0KIElTTyBkb2N1bWVudHMgYXJlIG9mdGVuIHJlZmVyZW5jZWQg YnkgSUVURiBkcmFmdHMuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5D YW4geW91IHBvaW50IHRvIHNwZWNpZmljIGRyYWZ0cyB3aGVyZSAqPGI+bm9ybWF0aXZlPC9iPiog cmVmZXJlbmNlcyBhcmUgb25seSBhdmFpbGFibGUgZm9yIHBheWluZyBhIGZlZT8mbmJzcDsgSSBn dWVzcyB0aGF0IHRoZXJlIGFyZSBzb21lLCBidXQgSSBkb27igJl0IGtub3cgb2YgYW55LiBZb3Vy IGNsYWltIGltcGxpZXMgZGVmaW5pdGl2ZSBrbm93bGVkZ2UsIGhvd2V2ZXIuPG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SW4gZ2VuZXJhbCwgdGhlIElFVEYgdGVu ZHMgdG8gZGlzbGlrZSB1c2luZyBzdGFuZGFyZHMgd2hlcmUgdGhlIHNwZWNpZmljYXRpb24gaXMg bm90IGZyZWVseSBhdmFpbGFibGUgaW4gRW5nbGlzaC4gVGhhdCBsYXN0IHBhcnQsIGluIEVuZ2xp c2gsIGlzIHBlcmhhcHMgbmFycm93LW1pbmRlZCB0aGVzZSBkYXlzLCBidXQgdGhlIElFVEYgd29y a3MgaW4gRW5nbGlzaC4mbmJzcDsgQWxzbywgbm90ZSB0aGF0IEkgc2FpZCDigJx0ZW5kcyB0byBk aXNsaWtl4oCdIGFuZCBkaWRu4oCZdCBjbGFpbSBhIGhhcmQgcnVsZSBhbHdheXMgZW5mb3JjZWQu Jm5ic3A7IEluIHRoZSBwYXN0LCB3aGVyZSB0aGVyZSBoYXZlIGJlZW4gaXNzdWVzLCBpdCBoYXMg YmVlbiBub3QgdW5jb21tb24gdG8gd3JpdGUgaW50ZXJuZXQtZHJhZnRzIGFuZCBwdWJsaXNoIHRo cm91Z2ggQ0ZSRzsgc2VlIDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvcmcv Y2ZyZy9kb2N1bWVudHMvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL3JnL2NmcmcvZG9j dW1lbnRzLzwvYT4gZm9yIG1hbnkgZXhhbXBsZXMuIFNvbWV0aW1lcyB0aGV5IGFyZSBwdWJsaXNo ZWQgYXMgaW5kaXZpZHVhbCBzdHJlYW0gUkZD4oCZczsgc2VlIDxhIGhyZWY9Imh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9yZmM3MDkxIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj NzA5MTwvYT4gZm9yIGEgaGlnaGx5IGFwcGxpY2FibGUgZXhhbXBsZS48bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3ByZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_A644F3ECB8354D3CA1FB5D33547F1C84akamaicom_-- From nobody Fri Aug 16 09:17:13 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B240C120865 for ; Fri, 16 Aug 2019 09:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMS8aLrlXh0n for ; Fri, 16 Aug 2019 09:17:09 -0700 (PDT) Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A48712029C for ; Fri, 16 Aug 2019 09:17:09 -0700 (PDT) Received: by mail-pl1-x634.google.com with SMTP id t14so2620248plr.11 for ; Fri, 16 Aug 2019 09:17:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6QD5Rxi5Bu3hkJNq+D8RzfnB59ixYqxRlW1C2Td3sxQ=; b=c3KE16LITQz4ko8An2fklj7z4uHfX+Wx6rJ9vk6qrhvEN9CpxkmuNIkEMZdtXb98TU WFfpSLlR2fVb+OAkrLh+aBv4HbBy0+hYAr8Sf61wyR9Sff9kG3oCSyNlNdRqDu91qUeV vmuXrmFRyHKbvIT+e8+e649tfvCZl+gl1Ua9aAUyruzMZ+pG4Vkpv6RCJFCCUSGDbJCl 1Q/nYf1zQINmEZNNbs8R5MPo6N/qiTpl7IYjBnP+UioXm8EliMU3/DdVhoxzwwfoL01m YBLdGzAUN65J/mqeV5o/WAyxlDAo08wTiBakTqK6aFk/jARJyKKW3yqj91QsamhH1Pxq QpKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6QD5Rxi5Bu3hkJNq+D8RzfnB59ixYqxRlW1C2Td3sxQ=; b=JszuwuyB+sFJ1JAsba5GDxFTnejBvOo/cCrwPGUw9ea9W2b6CArObceux304iQYBCB WgsiRBzS/d8NH9CWEF7niaDDiFk4LmxAVZ7gkJB8FfXmbD0DP2oI84jV84+YMDqYVp30 WNfE+4aqBmu/1cG6H9xJHEs57vL69oOw9IHrHMzFwYgUZypnjrJER0gTfoFwaCwWErbt JRDS8/ZD791/0qe/yGv/fQcmETHBOYE+RxQnwVuXvD5xUOE2BG+HQjTXFnJ7L7YlBIJc pqF3KfASmidItpY3G0qqBHUts5f/dYAisNQ/ddiZ5NcqGeIG8A6YoxY+fwnO4uksiiqQ vWqw== X-Gm-Message-State: APjAAAVyE9xiD6dLdmdqRV91hL4x91N8IUkJp60WqC9ZODZcG4nQArQh Xmq8o67NiK+OBOuZC8MYXYu2N3B9E4kC6RdrqIlV X-Google-Smtp-Source: APXvYqw0um55K5F3MF7lYJ5hr/nO5uq3leCppRilZToyLWlVGTx4gT4+mTaPU5Lsw3C+h8eEKpOTobtZKEM8qUCGcA8= X-Received: by 2002:a17:902:e510:: with SMTP id ck16mr1502738plb.334.1565972228367; Fri, 16 Aug 2019 09:17:08 -0700 (PDT) MIME-Version: 1.0 References: <156588205271.15865.9243229289426203471.idtracker@ietfa.amsl.com> <20190815152405.GS88236@kduck.mit.edu> <44BDC996-0E18-48BE-A700-C49A101330F8@kuehlewind.net> <6BD4AC5B-BA54-4BED-8B9B-ECA298E8BF0F@kuehlewind.net> In-Reply-To: <6BD4AC5B-BA54-4BED-8B9B-ECA298E8BF0F@kuehlewind.net> From: David Benjamin Date: Fri, 16 Aug 2019 12:16:50 -0400 Message-ID: To: Mirja Kuehlewind Cc: Benjamin Kaduk , draft-ietf-tls-grease@ietf.org, "" , The IESG , Sean Turner , tls-chairs Content-Type: multipart/alternative; boundary="00000000000066c86d05903e52e2" Archived-At: Subject: Re: [TLS] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-tls-grease-03=3A_=28with_COMMENT=29?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 16:17:11 -0000 --00000000000066c86d05903e52e2 Content-Type: text/plain; charset="UTF-8" On Fri, Aug 16, 2019 at 3:39 AM Mirja Kuehlewind wrote: > > >> One comment/question: I think I didn't quite understand what a client > is > > >> supposed to do if the connection fails with use of greasing > values...? The > > >> security considerations seems to indicate that you should not try to > re-connect > > >> without use of grease but rather just fail completely...? Also should > you cache > > >> the information that greasing failed maybe? > > > > > > I'll let the authors chime in, but I think the sense of the security > > > considerations is more that we are preventing the fallback from being > > > needed "in production due to "real" negotiation failures. Falling > back on > > > GREASE failure is not as bad, provided that you follow-up with the > failing > > > peer out of band to try to get it fixed. > > > I don't know how much value there would be in caching the > grease-intolerate > > > status; ideally it would almost-never happen. > > > > Okay, then I think it would be nice to say something more in the > document, about fallback at least. > > > > Ben's description is right. If deploying a new TLS feature results in > too many interop failures with existing buggy servers, that feature becomes > difficult to deploy and there is a lot of pressure to apply some sort of > mitigation like a fallback. That's no good. GREASE's goal is to avoid the > interop failures to begin with. The text was not meant to imply that you > should do any sort of fallback. > > > > What change did you have in mind? The current text says: > > > > > Historically, when interoperability problems arise in deploying new > TLS features, implementations have used a fallback retry on error with the > feature disabled. This allows an active attacker to silently disable the > new feature. By preventing a class of such interoperability problems, > GREASE reduces the need for this kind of fallback. > > > > That reads to me as describing historical fallbacks, rather than > recommending new ones. (Indeed you shouldn't do fallbacks. Fallbacks are > bad. They break downgrade protection.) > > I was thinking about adding some new text somewhere else in the document > that give a recommendation if you should fallback on grease and when. > I mean, the answer to that is "don't" and "never", just as is unstatedly true for any other TLS extension. TLS's downgrade protection doesn't work if you do fallbacks. While downgrading from GREASE doesn't matter per se, it defeats the purpose, so the usual rules for TLS apply. David --00000000000066c86d05903e52e2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Aug 16, 2019 at 3:39 AM Mirja Kue= hlewind <ietf@kuehlewind.net&= gt; wrote:
> >> One comment/question: I think I didn't quite understand w= hat a client is
> >> supposed to do if the connection fails with use of greasing v= alues...? The
> >> security considerations seems to indicate that you should not= try to re-connect
> >> without use of grease but rather just fail completely...? Als= o should you cache
> >> the information that greasing failed maybe?
> >
> > I'll let the authors chime in, but I think the sense of the s= ecurity
> > considerations is more that we are preventing the fallback from b= eing
> > needed "in production due to "real" negotiation fa= ilures.=C2=A0 Falling back on
> > GREASE failure is not as bad, provided that you follow-up with th= e failing
> > peer out of band to try to get it fixed.
> > I don't know how much value there would be in caching the gre= ase-intolerate
> > status; ideally it would almost-never happen.
>
> Okay, then I think it would be nice to say something more in the docum= ent, about fallback at least.
>
> Ben's description is right. If deploying a new TLS feature results= in too many interop failures with existing buggy servers, that feature bec= omes difficult to deploy and there is a lot of pressure to apply some sort = of mitigation like a fallback. That's no good. GREASE's goal is to = avoid the interop failures to begin with. The text was not meant to imply t= hat you should do any sort of fallback.
>
> What change did you have in mind? The current text says:
>
> > Historically, when interoperability problems arise in deploying n= ew TLS features, implementations have used a fallback retry on error with t= he feature disabled. This allows an active attacker to silently disable the= new feature. By preventing a class of such interoperability problems, GREA= SE reduces the need for this kind of fallback.
>
> That reads to me as describing historical fallbacks, rather than recom= mending new ones. (Indeed you shouldn't do fallbacks. Fallbacks are bad= . They break downgrade protection.)

I was thinking about adding some new text somewhere else in the document th= at give a recommendation if you should fallback on grease and when.

I mean, the answer to that is "don't&= quot; and "never", just as is unstatedly true for any other TLS e= xtension. TLS's downgrade protection doesn't work if you do fallbac= ks. While downgrading from GREASE doesn't matter per se, it defeats the= purpose, so the usual rules for TLS apply.

David<= /div>
--00000000000066c86d05903e52e2-- From nobody Fri Aug 16 22:01:52 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FED21200D5 for ; Fri, 16 Aug 2019 22:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alipay.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V_HXsK5UJAcG for ; Fri, 16 Aug 2019 22:01:48 -0700 (PDT) Received: from out0-156.mail.aliyun.com (out0-156.mail.aliyun.com [140.205.0.156]) (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 48B0A12003E for ; Fri, 16 Aug 2019 22:01:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alipay.com; s=default; t=1566018102; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:To; bh=lmbLmH450A4ozb484NwMDhjdDpOkV8n3jXtwNwrhmOU=; b=YWRrWz5CDMwga93DQsDs2/TdgnyLOe3eURO1nJXc5GfXvOM9dDI7Ch6uOspbLIJks0UK0FXHU5c9Adxd6Vp7VfeSHwVWkF/i7SoU8AzQV1lQ1+w9oOPWNXC7NqPwb5rHsTYz7i1D1jiFsct3kexM70GAF5x5Vlv4jnFWdol0S94= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R231e4; CH=green; DM=||false|; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e01l07440; MF=kaishen.yy@alipay.com; NM=1; PH=DS; RN=3; SR=0; TI=SMTPD_---.FDU7EVr_1566018100; Received: from 10.65.151.139(mailfrom:kaishen.yy@alipay.com fp:SMTPD_---.FDU7EVr_1566018100) by smtp.aliyun-inc.com(127.0.0.1); Sat, 17 Aug 2019 13:01:40 +0800 From: Paul Yang Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_4E1C2B47-5C42-41BF-9EB0-762BB587DAAE"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sat, 17 Aug 2019 13:01:39 +0800 In-Reply-To: <1e07a7cc-b316-6a1d-6f59-b352ffbd74b8@gmail.com> Cc: Kepeng Li , "tls@ietf.org" To: Rene Struik References: <3350587b-f768-425f-a759-3ed7ce2e6b27.kepeng.lkp@alibaba-inc.com> <1e07a7cc-b316-6a1d-6f59-b352ffbd74b8@gmail.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] (offline) Re: Draft for SM cipher suites used in TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 17 Aug 2019 05:01:51 -0000 --Apple-Mail=_4E1C2B47-5C42-41BF-9EB0-762BB587DAAE Content-Type: multipart/alternative; boundary="Apple-Mail=_6A0A964B-7B04-4D4B-A7FF-38D56608C7A9" --Apple-Mail=_6A0A964B-7B04-4D4B-A7FF-38D56608C7A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Good points. The good news is that we have found some English PDFs of SM2, including = the missing part 1 and part 3. Will continue to find English = translations of other SM standards mentioned in the draft. So, if we host a free website, say on Github or so, to provide those = docs, is it convenient for you guys? Or should we just drop the PDF = files to this mailing list as attachments? > On Aug 16, 2019, at 10:58 PM, Rene Struik = wrote: >=20 > Arguably, "national" crypto specifications garnish more stature if = these are made available to the pubic by that standard-setting body = itself (who, thereby, acts as its authoritative source), without = deference to a third party (that may, independently from the originator, = enforce document control [e.g., by effectuating technical changes or = enforcing controlled dissemination]). >=20 > Since your draft introducing SM cipher suites with TLS1.3 appeals to = the authority of a standard-setting authority, easy availability of the = full and accredited technical documentation to the IETF community helps = in scrutiny and, e.g., evaluating claims in the security considerations = section. >=20 > On 8/16/2019 3:06 AM, Kepeng Li wrote: >> Hi Rene and all, >>=20 >> > Since the ISO documents are not available to the general >> > public without payment, it would be helpful to have a freely = available >> > document (in English) from an authoritative source. Having such a >> > reference available would be helpful to the IETF community (and >> > researchers). >> About the references to ISO documens, I think it is a general issue = for IETF drafts. >>=20 >> How does the other IETF drafts make the references to ISO documents? = ISO documents are often referenced by IETF drafts. >>=20 >> Thanks, >>=20 >> Kind Regards >> Kepeng >> = =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 >> Re: [TLS] Draft for SM cipher suites used in TLS1.3 >>=20 >> Rene Struik > = Thu, 15 August 2019 15:34 UTCShow header = >> Hi Paul: >>=20 >> I tried and look up the documents GMT.0009-2012 and GBT.32918.5-2016 = on >> the (non-secured) websites you referenced, but only found Chinese >> versions (and Chinese website navigation panels [pardon my poor = language >> skills here]). Since the ISO documents are not available to the = general >> public without payment, it would be helpful to have a freely = available >> document (in English) from an authoritative source. Having such a >> reference available would be helpful to the IETF community (and >> researchers). Please note that BSI provides its specifications in = German >> and English, so as to foster use/study by the community. If the = Chinese >> national algorithms would be available in similar form, this would = serve >> a similar purpose. >>=20 >> FYI - I am interested in full details and some time last year I tried = to >> download specs, but only Parts 2, 4, and 5 were available [1], [2], = [3], >> not Parts 1 and 3. >>=20 >> Best regards, Rene >>=20 >> [1] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC - >> Part 5 - Parameter Definition (SEMB, July 24, 2018) >> [2] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC - >> Part 2 - Digital Signature Algorithm (SEMB, July 24, 2018) >> [3] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC - >> Part 4 - Public Key Encryption Algorithm (SEMB, July 24, 2018) >>=20 >> On 8/15/2019 10:16 AM, Paul Yang wrote: >> > Hi all, >> > >> > I have submitted a new internet draft to introduce the SM cipher >> > suites into TLS 1.3 protocol. >> > >> > https://tools.ietf.org/html/draft-yang-tls-tls13-sm-suites-00 = >> > >> > SM cryptographic algorithms are originally a set of Chinese = national >> > algorithms and now have been (or being) accepted by ISO as >> > international standards, including SM2 signature algorithm, SM3 = hash >> > function and SM4 block cipher. These algorithms have already been >> > supported some time ago by several widely used open source >> > cryptographic libraries including OpenSSL, BouncyCastle, Botan, = etc. >> > >> > Considering TLS1.3 is being gradually adopted in China's internet >> > industry, it's important to have a normative definition on how to = use >> > the SM algorithms with TLS1.3, especially for the mobile internet >> > scenario. Ant Financial is the company who develops the market = leading >> > mobile app 'Alipay' and supports payment services for Alibaba >> > e-commerce business. We highly are depending on the new TLS1.3 >> > protocol for both performance and security purposes. We expect to = have >> > more deployment of TLS1.3 capable applications in China's internet >> > industry by this standardization attempts. >> > >> > It's very appreciated to have comments from the IETF TLS list :-) >> > >> > Many thanks! >> > >> > _______________________________________________ >> > TLS mailing list >> > TLS@ietf.org >> > https://www.ietf.org/mailman/listinfo/tls = >=20 > -- > email: rstruik.ext@gmail.com | Skype: = rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls Regards, Paul Yang --Apple-Mail=_6A0A964B-7B04-4D4B-A7FF-38D56608C7A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Good = points.

The good = news is that we have found some English PDFs of SM2, including the = missing part 1 and part 3. Will continue to find English translations of = other SM standards mentioned in the draft.

So, if we host a free website, say on = Github or so, to provide those docs, is it convenient for you guys? Or = should we just drop the   PDF files to this mailing list as = attachments?

On Aug 16, 2019, at 10:58 PM, Rene Struik = <rstruik.ext@gmail.com> wrote:

=20 =20
Arguably, "national" crypto specifications garnish more stature if these are made available to the pubic by that standard-setting body itself (who, thereby, acts as its authoritative source), without deference to a third party (that may, independently from the originator, enforce document control [e.g., by effectuating technical changes or enforcing controlled dissemination]).

Since your draft introducing SM = cipher suites with TLS1.3 appeals to the authority of a standard-setting authority, easy availability of the full and accredited technical documentation to the IETF community helps in scrutiny and, e.g., evaluating claims in the security considerations section.

On 8/16/2019 3:06 AM, Kepeng Li = wrote:
Hi Rene and all,

> Since the ISO =
documents are not available to the general=20
> public without payment, it would be helpful to have a freely =
available=20
> document (in English) from an authoritative source. Having such a=20=

> reference available would be helpful to the IETF community (and=20
> researchers).
About the references to ISO documens, I think it is a general issue for IETF drafts.

How does the other IETF drafts make the references to ISO documents? ISO documents are often referenced by IETF drafts.

Thanks,

Kind Regards
Kepeng
=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94

Re: [TLS] Draft for SM cipher suites used in = TLS1.3

Rene Struik <rstruik.ext@gmail.com> Thu, 15 August 2019 15:34 UTCShow = header

Hi Paul:

I tried and look up the documents GMT.0009-2012 and GBT.32918.5-2016 on=20=

the (non-secured) websites you referenced, but only found Chinese=20
versions (and Chinese website navigation panels [pardon my poor language=20=

skills here]). Since the ISO documents are not available to the general=20=

public without payment, it would be helpful to have a freely available=20=

document (in English) from an authoritative source. Having such a=20
reference available would be helpful to the IETF community (and=20
researchers). Please note that BSI provides its specifications in German=20=

and English, so as to foster use/study by the community. If the Chinese=20=

national algorithms would be available in similar form, this would serve=20=

a similar purpose.

FYI - I am interested in full details and some time last year I tried to=20=

download specs, but only Parts 2, 4, and 5 were available [1], [2], [3],=20=

not Parts 1 and 3.

Best regards, Rene

[1] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC -=20
Part 5 - Parameter Definition (SEMB, July 24, 2018)
[2] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC -=20
Part 2 - Digital Signature Algorithm (SEMB, July 24, 2018)
[3] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC -=20
Part 4 - Public Key Encryption Algorithm (SEMB, July 24, 2018)

On 8/15/2019 10:16 AM, Paul Yang wrote:
> Hi all,
>
> I have submitted a new internet draft to introduce the SM cipher=20
> suites into TLS 1.3 protocol.
>
> https://tools.ietf.org/html/draft-yang-tls-tls13-sm-suites-00
>
> SM cryptographic algorithms are originally a set of Chinese =
national=20
> algorithms and now have been (or being) accepted by ISO as=20
> international standards, including SM2 signature algorithm, SM3 =
hash=20
> function and SM4 block cipher. These algorithms have already been=20=

> supported some time ago by several widely used open source=20
> cryptographic libraries including OpenSSL, BouncyCastle, Botan, =
etc.
>
> Considering TLS1.3 is being gradually adopted in China's internet=20=

> industry, it's important to have a normative definition on how to =
use=20
> the SM algorithms with TLS1.3, especially for the mobile internet=20=

> scenario. Ant Financial is the company who develops the market =
leading=20
> mobile app 'Alipay' and supports payment services for Alibaba=20
> e-commerce business. We highly are depending on the new TLS1.3=20
> protocol for both performance and security purposes. We expect to =
have=20
> more deployment of TLS1.3 capable applications in China's internet=20=

> industry by this standardization attempts.
>
> It's very appreciated to have comments from the IETF TLS list :-)
>
> Many thanks!
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


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


Regards,

Paul Yang

= --Apple-Mail=_6A0A964B-7B04-4D4B-A7FF-38D56608C7A9-- --Apple-Mail=_4E1C2B47-5C42-41BF-9EB0-762BB587DAAE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEndC1x/yVcklg1DZ15HtIVEj/IsoFAl1XijMACgkQ5HtIVEj/ Ispewg/9GMYKNSuppxhyFj1LxPfN+bgoLIbiIFDNTewpAH5hCSHRJBhd8zYa2wqW /IUyMiysSBcqDGYKAgwHUxyKOHvG4JEdHroLmfhP1bbSS9gbQP7TpZaFLpnbqchx 8Icodd4x/D136a+f94UyQIDEb2VdsMOEQHPJw35iV2zH3ZTjqzLnejLITZLNRIQY SFuPkhPC2PloDY9US74VNlsuWCAKMd0ZGI25KDbZpIkH28eWDoP9nWsO23cr8RR/ IpcbGA0Gvrw/GvcfICh9eV3nzoxBujCfepPGpiC630zomIh5VNoNBLB21ykzs/PY 8CnTBJWx/t534sfWk8vBeB3TYxeQuzmRvRqnKOGgIo4ZPwYGITxNnxQalO0KvUkR mFEa0yLodco3fGLEwACIqrBlDqfJLb1T2VJQY1QMAjZJYiMefnQENxe95ETEs9jn WFqRsXyxkjlRjbZmP3K+WAf5UrCjw+mHPPAe3/Sie51xsm6ZKC6x6WFMrkX43Mfk tvTsPXQyDOqT+uLF1xU78RQWNhIj9FfV9g5ZFHjUdcElq9JLLGZSv8UuUYB6J7bi 2yHPH1w6AY8xN5q71X1XbDaHTmAmmKEYh3+Nul+wSjTo6hXcmurQjK+h/86lE51W l+cvJ3+hmxhQauycdwWAm+jWWfTx+r+TUgwCHKSgScpVe/1hofI= =ZCdq -----END PGP SIGNATURE----- --Apple-Mail=_4E1C2B47-5C42-41BF-9EB0-762BB587DAAE-- From nobody Sat Aug 17 02:39:01 2019 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 2A63A120119; Sat, 17 Aug 2019 02:38:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov via Datatracker To: "The IESG" Cc: draft-ietf-tls-grease@ietf.org, Sean Turner , tls-chairs@ietf.org, sean@sn3rd.com, tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alexey Melnikov Message-ID: <156603473416.11195.18372949069778788332.idtracker@ietfa.amsl.com> Date: Sat, 17 Aug 2019 02:38:54 -0700 Archived-At: Subject: [TLS] Alexey Melnikov's Yes on draft-ietf-tls-grease-03: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list 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, 17 Aug 2019 09:38:54 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-tls-grease-03: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-grease/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I am looking forward to this being deployed. TLS 1.2 should be a Normative reference, despite being obsolete, as some of the requirements only apply to TLS 1.2. From nobody Sat Aug 17 16:07:23 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E44A1200E5; Sat, 17 Aug 2019 16:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szdxYq_DSqFo; Sat, 17 Aug 2019 16:07:13 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.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 5A8671200CC; Sat, 17 Aug 2019 16:07:12 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x7HN78Ww009082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 17 Aug 2019 19:07:10 -0400 Date: Sat, 17 Aug 2019 18:07:07 -0500 From: Benjamin Kaduk To: Mirja Kuehlewind Cc: The IESG , draft-ietf-tls-grease@ietf.org, tls-chairs@ietf.org, sean@sn3rd.com, tls@ietf.org Message-ID: <20190817230707.GU88236@kduck.mit.edu> References: <156588466304.15861.9219490518200903631.idtracker@ietfa.amsl.com> <20190816033931.GI88236@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [TLS] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_draft?= =?iso-8859-1?q?-ietf-tls-grease-03=3A_=28with_COMMENT=29?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 17 Aug 2019 23:07:15 -0000 On Fri, Aug 16, 2019 at 09:35:09AM +0200, Mirja Kuehlewind wrote: > Hi Ben, > > Thanks for the explanation. > > I would think this is actually a PS given it extents a protocol based on the extension point this protocol provides. Maybe it is not really adding a new function but it also kind of is: I would call probing for non-compliant implementations a protocol function. I mean if we would specify greasing for a new protocol, I think it would simply be part of the main spec. Re "part of the main spec", perhaps, but presumably not a mandatory-to-implement one? To look at it a different way, what kind of interoperability requirements does GREASE mandate? Isn't it just the same interoperability requirements of the main protocol, i.e., an incremental addition of zero? -Ben From nobody Sat Aug 17 17:44:44 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 127B31200F5 for ; Sat, 17 Aug 2019 17:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EATt91Pk6F_x for ; Sat, 17 Aug 2019 17:44:31 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::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 0485112006D for ; Sat, 17 Aug 2019 17:44:31 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id x18so8462268ljh.1 for ; Sat, 17 Aug 2019 17:44:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gG98yI+F0X1V2rSWZHaiDLAwXx9drSfmRII9EVvjiEc=; b=ABPkTJPWmN/ZphuyVFpqEOXDzR1U17D12kW1j87PJyZ9wLktcbRuAUjnJOe5Q6kV6q lFDx4ES+bc6ycaHqU0GM3AsKlxvslK9Fhxt51yxrbS7p9ZO/EFqfiY/SW6uk8CsQCSc9 x2vsonMmS+LmCD+skTP/b1uNlFWne8eedpjK+3HLgA43qb0BeoEFKRkU8hj6dDF+A3GD m0Z87DRPyLYIecpvsVP8SxTXX82JNCqA5tY3jtfZ0CBaffclUnsAT5+duFT/8Cm+yiji AaNC/yJ7nUn+IqB+rjRAY3yxbkir++4l9htXjbN5EeLaTXxlxSVCEMlX7my2hjmDGLJr nYzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gG98yI+F0X1V2rSWZHaiDLAwXx9drSfmRII9EVvjiEc=; b=JzKFUtOxh+qwTa03RlqduVa2nQjYfGPhQk/ITFS2uhhQvptw9nej0o2LLG1/vPwNRg +iPxmVYFz81xAgXrt8ugK1PJ0Nt9GyytLIuxS/U/ffPxXO2ZZXwUubq7tGzqcREBYVyV UrW7sMcnsLby/nULVjSpQsyp+S0ZmAT0YbcuXVJzjdZwUYoKzMlosngu9z12RLrDI8ht p4zaanULbfy81PZAHYfmoZ8qI7KOGCT5QrfTnwoNu64nTx5duqxWdfTzhVqxUl9Md4L5 ZbIhtrbQ+ueGQ+/dDyYq11JzoUjoJly7E+8jxG1au3yRl0UZY/1imcOFIeDMRUw8l6lF KeUA== X-Gm-Message-State: APjAAAXdsxZ6NfQ9FxRcdtjFZwefznR/eeR3uo0c1ZVI05Q7epDt4Qd/ dwkllABw+LCOHtPAhIi+kBQzTDd7en5/xhOrpe10rQ== X-Google-Smtp-Source: APXvYqzaTsKqUmAIPro2KozxGkSuWM1ybItFgIO700sOpxlmglwHnYt1eJDqx+4R7m6b0I7Ns/SJqLl1XepnwLkQlAA= X-Received: by 2002:a2e:b0e6:: with SMTP id h6mr8425841ljl.18.1566089069215; Sat, 17 Aug 2019 17:44:29 -0700 (PDT) MIME-Version: 1.0 References: <156588466304.15861.9219490518200903631.idtracker@ietfa.amsl.com> <20190816033931.GI88236@kduck.mit.edu> <20190817230707.GU88236@kduck.mit.edu> In-Reply-To: <20190817230707.GU88236@kduck.mit.edu> From: Eric Rescorla Date: Sun, 18 Aug 2019 02:43:52 +0200 Message-ID: To: Benjamin Kaduk Cc: Mirja Kuehlewind , draft-ietf-tls-grease@ietf.org, "" , The IESG , tls-chairs Content-Type: multipart/alternative; boundary="000000000000a858d905905986a3" Archived-At: Subject: Re: [TLS] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-tls-grease-03=3A_=28with_COMMENT=29?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 18 Aug 2019 00:44:34 -0000 --000000000000a858d905905986a3 Content-Type: text/plain; charset="UTF-8" I do not think this needs to be a PS specification. The code points here do not require a standards track RFC. Note that advancing this at PS would require a new IETF LC. -Ekr On Sun, Aug 18, 2019 at 1:07 AM Benjamin Kaduk wrote: > On Fri, Aug 16, 2019 at 09:35:09AM +0200, Mirja Kuehlewind wrote: > > Hi Ben, > > > > Thanks for the explanation. > > > > I would think this is actually a PS given it extents a protocol based on > the extension point this protocol provides. Maybe it is not really adding a > new function but it also kind of is: I would call probing for non-compliant > implementations a protocol function. I mean if we would specify greasing > for a new protocol, I think it would simply be part of the main spec. > > Re "part of the main spec", perhaps, but presumably not a > mandatory-to-implement one? > To look at it a different way, what kind of interoperability requirements > does GREASE mandate? Isn't it just the same interoperability requirements > of the main protocol, i.e., an incremental addition of zero? > > -Ben > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000a858d905905986a3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I do not think this needs to be a PS specification. T= he code points here do not require a standards track RFC.

Note that advancing this at PS would require a new IETF LC.

-Ekr



On Sun, Aug 18, 2019 at = 1:07 AM Benjamin Kaduk <kaduk@mit.edu> wrote:
On= Fri, Aug 16, 2019 at 09:35:09AM +0200, Mirja Kuehlewind wrote:
> Hi Ben,
>
> Thanks for the explanation.
>
> I would think this is actually a PS given it extents a protocol based = on the extension point this protocol provides. Maybe it is not really addin= g a new function but it also kind of is: I would call probing for non-compl= iant implementations a protocol function. I mean if we would specify greasi= ng for a new protocol, I think it would simply be part of the main spec.
Re "part of the main spec", perhaps, but presumably not a
mandatory-to-implement one?
To look at it a different way, what kind of interoperability requirements does GREASE mandate?=C2=A0 Isn't it just the same interoperability requ= irements
of the main protocol, i.e., an incremental addition of zero?

-Ben

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000a858d905905986a3-- From nobody Sun Aug 18 01:09:34 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23B0B120041 for ; Sun, 18 Aug 2019 01:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alibaba-inc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tv1Ftn-yPvsm for ; Sun, 18 Aug 2019 01:09:29 -0700 (PDT) Received: from out0-148.mail.aliyun.com (out0-148.mail.aliyun.com [140.205.0.148]) (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 5188112001A for ; Sun, 18 Aug 2019 01:09:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1566115762; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; bh=e5ghcgxhq7vLkLcH5aQ4uABDjn+KoQggbKRR/ZbyaXQ=; b=OhlDzULaQ70nBBGFBmM2p2Ho7F6aW9PFVVkKaIJHN1ItkKakoH+4uIRsZ1HH3f50o26eXSdXQMftg5Icq3wh8sFyC4Mtm6UEoMpGyhV/cdHGFPDPZDsdf8piW/uQGPRD8pcGQCbslC2Om58/BOziYI7gbm0MvZjx5rndOMw1S00= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R681e4; CH=green; DM=||false|; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03275; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DW; RN=3; SR=0; TI=dingding_android.COREAPId97b0a46aeea488e929d9023e45cbc73; Received: from WS-web (kepeng.lkp@alibaba-inc.com[dingding_android.COREAPId97b0a46aeea488e929d9023e45cbc73]) by e01l04452.eu6 at Sun, 18 Aug 2019 16:09:17 +0800 Date: Sun, 18 Aug 2019 16:09:17 +0800 From: "Kepeng Li" To: "=?UTF-8?B?U2FseiwgUmljaA==?=" , "Kepeng Li" Cc: "'tls@ietf.org'" Message-ID: X-Priority: 3 X-Mailer: [Alimail-Mailagent] MIME-Version: 1.0 In-Reply-To: References: <3350587b-f768-425f-a759-3ed7ce2e6b27.kepeng.lkp@alibaba-inc.com> <1e07a7cc-b316-6a1d-6f59-b352ffbd74b8@gmail.com>, Content-Type: multipart/alternative; boundary="----=ALIBOUNDARY_28735_483fa940_5d5907ad_1987141" Archived-At: Subject: Re: [TLS] =?utf-8?q?=28offline=29_Re=3A__Draft_for_SM_cipher_suites_?= =?utf-8?q?used_in_TLS1=2E3?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 18 Aug 2019 08:09:31 -0000 ------=ALIBOUNDARY_28735_483fa940_5d5907ad_1987141 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 PkNhbiB5b3UgcG9pbnQgdG8gc3BlY2lmaWMgZHJhZnRzIHdoZXJlICpub3JtYXRpdmUqIHJlZmVy ZW5jZXMgYXJlIG9ubHkgYXZhaWxhYmxlIGZvciBwYXlpbmcgYSBmZWU/ICBJIGd1ZXNzIHRoYXQg dGhlcmUgYXJlIHNvbWUsIGJ1dCBJIGRvbuKAmXQga25vdyBvZiBhbnkuIApUaGlzIGlzIG9uZSBl eGFtcGxlOiBodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9yZmMvcmZjODQyOC50eHQKW1JOQ107 IElTTy9JRUMsICJJbmZvcm1hdGlvbiB0ZWNobm9sb2d5IC0tIERvY3VtZW50IFNjaGVtYSBEZWZp bml0aW9uIExhbmd1YWdlIChEU0RMKSAtLSBQYXJ0IDI6IFJlZ3VsYXItZ3JhbW1hci1iYXNlZCB2 YWxpZGF0aW9uIC0tIFJFTEFYIE5HIiwgSVNPL0lFQyAxOTc1Ny0yLCBBbm5leCBDOiBSRUxBWCBO RyBDb21wYWN0IHN5bnRheCwgRGVjZW1iZXIgMjAwOC4KS2luZCBSZWdhcmRzCktlcGVuZwoKLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0K5Y+R5Lu25Lq6OlNhbHosIFJpY2g8cnNhbHpAYWthbWFp LmNvbT4K5pel5pyf77yaOOaciDE25pelIDIzOjA2CuaUtuS7tuS6uu+8mktlcGVuZyBMaTxrZXBl bmcubGtwQGFsaWJhYmEtaW5jLmNvbT4K6L6T5YWl5Li76aKYUmU6IFtUTFNdIChvZmZsaW5lKSBS ZTogRHJhZnQgZm9yIFNNIGNpcGhlciBzdWl0ZXMgdXNlZCBpbiBUTFMxLjMKCgo+SG93IGRvZXMg dGhlIG90aGVyIElFVEYgZHJhZnRzIG1ha2UgdGhlIHJlZmVyZW5jZXMgdG8gSVNPIGRvY3VtZW50 cz8gSVNPIGRvY3VtZW50cyBhcmUgb2Z0ZW4gcmVmZXJlbmNlZCBieSBJRVRGIGRyYWZ0cy4KIApD YW4geW91IHBvaW50IHRvIHNwZWNpZmljIGRyYWZ0cyB3aGVyZSAqbm9ybWF0aXZlKiByZWZlcmVu Y2VzIGFyZSBvbmx5IGF2YWlsYWJsZSBmb3IgcGF5aW5nIGEgZmVlPyAgSSBndWVzcyB0aGF0IHRo ZXJlIGFyZSBzb21lLCBidXQgSSBkb27igJl0IGtub3cgb2YgYW55LiBZb3VyIGNsYWltIGltcGxp ZXMgZGVmaW5pdGl2ZSBrbm93bGVkZ2UsIGhvd2V2ZXIuCiAKSW4gZ2VuZXJhbCwgdGhlIElFVEYg dGVuZHMgdG8gZGlzbGlrZSB1c2luZyBzdGFuZGFyZHMgd2hlcmUgdGhlIHNwZWNpZmljYXRpb24g aXMgbm90IGZyZWVseSBhdmFpbGFibGUgaW4gRW5nbGlzaC4gVGhhdCBsYXN0IHBhcnQsIGluIEVu Z2xpc2gsIGlzIHBlcmhhcHMgbmFycm93LW1pbmRlZCB0aGVzZSBkYXlzLCBidXQgdGhlIElFVEYg d29ya3MgaW4gRW5nbGlzaC4gIEFsc28sIG5vdGUgdGhhdCBJIHNhaWQg4oCcdGVuZHMgdG8gZGlz bGlrZeKAnSBhbmQgZGlkbuKAmXQgY2xhaW0gYSBoYXJkIHJ1bGUgYWx3YXlzIGVuZm9yY2VkLiAg SW4gdGhlIHBhc3QsIHdoZXJlIHRoZXJlIGhhdmUgYmVlbiBpc3N1ZXMsIGl0IGhhcyBiZWVuIG5v dCB1bmNvbW1vbiB0byB3cml0ZSBpbnRlcm5ldC1kcmFmdHMgYW5kIHB1Ymxpc2ggdGhyb3VnaCBD RlJHOyBzZWUgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9yZy9jZnJnL2RvY3VtZW50cy8g Zm9yIG1hbnkgZXhhbXBsZXMuIFNvbWV0aW1lcyB0aGV5IGFyZSBwdWJsaXNoZWQgYXMgaW5kaXZp ZHVhbCBzdHJlYW0gUkZD4oCZczsgc2VlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3 MDkxIGZvciBhIGhpZ2hseSBhcHBsaWNhYmxlIGV4YW1wbGUuCiAgIA== ------=ALIBOUNDARY_28735_483fa940_5d5907ad_1987141 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBjbGFzcz0idXNlcmlucHV0Ij48cHJlIHN0eWxlPSJmb250LXNpemU6IG1lZGl1bTsiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBjYWxpYnJpLCBzYW5zLXNl cmlmOyI+Jmd0O0NhbiB5b3UgcG9pbnQgdG8gc3BlY2lmaWMgZHJhZnRzIHdoZXJlICo8Yj5ub3Jt YXRpdmU8L2I+KiByZWZlcmVuY2VzIGFyZSBvbmx5IGF2YWlsYWJsZSBmb3IgcGF5aW5nIGEgZmVl PyZuYnNwOyBJIGd1ZXNzIHRoYXQgdGhlcmUgYXJlIHNvbWUsIGJ1dCBJIGRvbuKAmXQga25vdyBv ZiBhbnkuIDwvc3Bhbj48L3ByZT48cHJlIHN0eWxlPSIiPjxmb250IGZhY2U9ImNhbGlicmksIHNh bnMtc2VyaWYiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDE0LjY2NjdweDsiPlRoaXMgaXMgb25l IGV4YW1wbGU6IGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmM4NDI4LnR4dDwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyI+PGJyPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+ PC9kaXY+PGRpdiBjbGFzcz0idXNlcmlucHV0Ij5bUk5DXTsgSVNPL0lFQywgIkluZm9ybWF0aW9u IHRlY2hub2xvZ3kgLS0gRG9jdW1lbnQgU2NoZW1hIERlZmluaXRpb24gTGFuZ3VhZ2UgKERTREwp IC0tIFBhcnQgMjogUmVndWxhci1ncmFtbWFyLWJhc2VkIHZhbGlkYXRpb24gLS0gUkVMQVggTkci LCBJU08vSUVDIDE5NzU3LTIsIEFubmV4IEM6IFJFTEFYIE5HIENvbXBhY3Qgc3ludGF4LCBEZWNl bWJlciAyMDA4LjwvZGl2Pjxicj5LaW5kIFJlZ2FyZHM8YnI+S2VwZW5nPGJyPjxicj4tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLTxicj48ZGl2IGNsYXNzPSJxdW90ZUhlYWRlciIgPHN0cm9uZz0i Ij7lj5Hku7bkuro6U2FseiwgUmljaCZsdDtyc2FsekBha2FtYWkuY29tJmd0Ozxicj48Yj7ml6Xm nJ/vvJo8L2I+OOaciDE25pelIDIzOjA2PGJyPjxiPuaUtuS7tuS6uu+8mjwvYj5LZXBlbmcgTGkm bHQ7a2VwZW5nLmxrcEBhbGliYWJhLWluYy5jb20mZ3Q7PGJyPjxiPui+k+WFpeS4u+mimDwvYj5S ZTogW1RMU10gKG9mZmxpbmUpIFJlOiAgRHJhZnQgZm9yIFNNIGNpcGhlciBzdWl0ZXMgdXNlZCBp biBUTFMxLjM8YnI+PC9kaXY+PGJyPjxicj4KCgo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPgo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAxLjBpbjtiYWNrZ3JvdW5k OiB3aGl0ZTsiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEyLjBwdDtjb2xvcjogYmxhY2s7 Ij4mZ3Q7PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7Zm9udC1mYW1p bHk6IGFyaWFsICwgc2Fucy1zZXJpZjtjb2xvcjogYmxhY2s7Ij5Ib3cgZG9lcyB0aGUgb3RoZXIg SUVURiBkcmFmdHMgbWFrZSB0aGUgcmVmZXJlbmNlcyB0byBJU08gZG9jdW1lbnRzPwogSVNPIGRv Y3VtZW50cyBhcmUgb2Z0ZW4gcmVmZXJlbmNlZCBieSBJRVRGIGRyYWZ0cy48L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0O2ZvbnQtZmFtaWx5OiBhcmlhbCAsIHNhbnMtc2VyaWY7 Ij48L3NwYW4+PC9wPgo8cHJlPiZuYnNwOzwvcHJlPgo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNp emU6IDExLjBwdDtmb250LWZhbWlseTogY2FsaWJyaSAsIHNhbnMtc2VyaWY7Ij5DYW4geW91IHBv aW50IHRvIHNwZWNpZmljIGRyYWZ0cyB3aGVyZSAqPGI+bm9ybWF0aXZlPC9iPiogcmVmZXJlbmNl cyBhcmUgb25seSBhdmFpbGFibGUgZm9yIHBheWluZyBhIGZlZT8mbmJzcDsgSSBndWVzcyB0aGF0 IHRoZXJlIGFyZSBzb21lLCBidXQgSSBkb27igJl0IGtub3cgb2YgYW55LiBZb3VyIGNsYWltIGlt cGxpZXMgZGVmaW5pdGl2ZSBrbm93bGVkZ2UsIGhvd2V2ZXIuPC9zcGFuPjwvcHJlPgo8cHJlPjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDExLjBwdDtmb250LWZhbWlseTogY2FsaWJyaSAsIHNhbnMt c2VyaWY7Ij4mbmJzcDs8L3NwYW4+PC9wcmU+CjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog MTEuMHB0O2ZvbnQtZmFtaWx5OiBjYWxpYnJpICwgc2Fucy1zZXJpZjsiPkluIGdlbmVyYWwsIHRo ZSBJRVRGIHRlbmRzIHRvIGRpc2xpa2UgdXNpbmcgc3RhbmRhcmRzIHdoZXJlIHRoZSBzcGVjaWZp Y2F0aW9uIGlzIG5vdCBmcmVlbHkgYXZhaWxhYmxlIGluIEVuZ2xpc2guIFRoYXQgbGFzdCBwYXJ0 LCBpbiBFbmdsaXNoLCBpcyBwZXJoYXBzIG5hcnJvdy1taW5kZWQgdGhlc2UgZGF5cywgYnV0IHRo ZSBJRVRGIHdvcmtzIGluIEVuZ2xpc2guJm5ic3A7IEFsc28sIG5vdGUgdGhhdCBJIHNhaWQg4oCc dGVuZHMgdG8gZGlzbGlrZeKAnSBhbmQgZGlkbuKAmXQgY2xhaW0gYSBoYXJkIHJ1bGUgYWx3YXlz IGVuZm9yY2VkLiZuYnNwOyBJbiB0aGUgcGFzdCwgd2hlcmUgdGhlcmUgaGF2ZSBiZWVuIGlzc3Vl cywgaXQgaGFzIGJlZW4gbm90IHVuY29tbW9uIHRvIHdyaXRlIGludGVybmV0LWRyYWZ0cyBhbmQg cHVibGlzaCB0aHJvdWdoIENGUkc7IHNlZSA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL3JnL2NmcmcvZG9jdW1lbnRzLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvcmcvY2ZyZy9kb2N1bWVudHMvPC9hPiBmb3IgbWFueSBleGFtcGxlcy4g U29tZXRpbWVzIHRoZXkgYXJlIHB1Ymxpc2hlZCBhcyBpbmRpdmlkdWFsIHN0cmVhbSBSRkPigJlz OyBzZWUgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcwOTEiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzA5MTwvYT4gZm9yIGEg aGlnaGx5IGFwcGxpY2FibGUgZXhhbXBsZS48L3NwYW4+PC9wcmU+CjxwcmU+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTEuMHB0O2ZvbnQtZmFtaWx5OiBjYWxpYnJpICwgc2Fucy1zZXJpZjsiPiZu YnNwOzwvc3Bhbj48L3ByZT4KPC9kaXY+CgoK ------=ALIBOUNDARY_28735_483fa940_5d5907ad_1987141-- From nobody Sun Aug 18 02:44:40 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1060E120019 for ; Sun, 18 Aug 2019 02:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmzUKqgp5IzE for ; Sun, 18 Aug 2019 02:44:37 -0700 (PDT) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C093A120013 for ; Sun, 18 Aug 2019 02:44:36 -0700 (PDT) Received: by mail-wm1-x329.google.com with SMTP id g67so525156wme.1 for ; Sun, 18 Aug 2019 02:44:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=QfJKrfrpYo8aptHFc4V7axJif8BOTfLAFwKU4BmHVJE=; b=CQlQfvAGz3IHv5asTzwBBytLVw5tq/LByubWmUm3svUrYwZlfvgrmrWgB18H/c7yj1 Td/tV2r9HtzLJZxoVxHUuuaHY4FuZyYg5R48+yBnQcbjaTj5uvfDuzcXLwAL9bSbhKYS toE056R2Z11VOYnydNW7i0rVFMpI/ghKMAFZ9Vp4T82yxLQmKCvdV5wffuw3qJO4DJC2 OubO4afy+hK8Hg2XVOYHTwmxGD/3QWCdTMZMqP2SBQvv0l8eCfoK8v4bJELu7iKFJHQ3 qUR8PM0LwYZQsOL2CQrvSPzGfxh4UUg4RDDbpWHarq+hV4XJqMsb3jSHrexGNjyJNCCK 6/lQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=QfJKrfrpYo8aptHFc4V7axJif8BOTfLAFwKU4BmHVJE=; b=kEfNUHX1TYYxmU7QLJI9Q5TLZOtj3POarwNdksrcI33H7fpTlFj1HjHI2DlajVIZWf DlcgCopS7wBrsH2CwYOXTkIhaFOl1SolG4OeT+/i6trHgROI/zKn/ion1GfLRKWhkK0c c9ZUjK3zJZp4mlovQfpM25wlLVd+Hqkqe688TiVit8BWrJEuQNW8f6td3wctM32jDGy3 3R0h8KyoTrHJzyC3ShQ2DucspFd7os3Z39fi4H9eIE+3os6P/4X6N4pxajm5rbctEdf2 lvs+Z61Ao/X5wBFN4oHqmDf5lUNRBCyBiF6bTHh0lxsrFqBzI6wewVoTy5PVU0C2SXev l6Mw== X-Gm-Message-State: APjAAAU9qyCrWge5KoEOI+p77la8OrG3Axd1krfIo6e8AgAJwy8QtfKR +yk7tQytu7P/mn+cd0sHrDLeYq+5 X-Google-Smtp-Source: APXvYqxriOaXX9/FWS1w/f90BpKXTOyQjshxWrX85xEKkQAWq6RtGUeehuFKHWZVVNDglL70POtHeQ== X-Received: by 2002:a05:600c:204:: with SMTP id 4mr15797603wmi.167.1566121474866; Sun, 18 Aug 2019 02:44:34 -0700 (PDT) Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id i66sm9559835wmg.2.2019.08.18.02.44.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Aug 2019 02:44:34 -0700 (PDT) To: Kepeng Li , "Salz, Rich" Cc: "'tls@ietf.org'" References: <3350587b-f768-425f-a759-3ed7ce2e6b27.kepeng.lkp@alibaba-inc.com> <1e07a7cc-b316-6a1d-6f59-b352ffbd74b8@gmail.com> From: Anders Rundgren Message-ID: Date: Sun, 18 Aug 2019 11:44:29 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] (offline) Re: Draft for SM cipher suites used in TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 18 Aug 2019 09:44:39 -0000 Couldn't a group petition from the IETF request ISO and their member states to reconsider the use fee based standards? This concept is incompatible with most current standards developments, be it in the IETF, W3C, or industry consortia as well a with Open Source. Fee based standards represent an hurdle for innovation and adoption of new technology. thanx, Anders Rundgren On 2019-08-18 10:09, Kepeng Li wrote: >>Can you point to specific drafts where **normative** references are only available for paying a fee?Ā  I guess that there are some, but I donā€™t know of any. > > This is one example: https://www.rfc-editor.org/rfc/rfc8428.txt > > [RNC]; ISO/IEC, "Information technology -- Document Schema Definition Language (DSDL) -- Part 2: Regular-grammar-based validation -- RELAX NG", ISO/IEC 19757-2, Annex C: RELAX NG Compact syntax, December 2008. > > Kind Regards > Kepeng > > -------------------------- > 发件äŗŗ:Salz, Rich > *ę—„ęœŸļ¼š*8꜈16ę—„ 23:06 > *ꔶ件äŗŗļ¼š*Kepeng Li > *č¾“å…„äø»é¢˜*Re: [TLS] (offline) Re: Draft for SM cipher suites used in TLS1.3 > > > *>*How does the other IETF drafts make the references to ISO documents? ISO documents are often referenced by IETF drafts. > > > > Can you point to specific drafts where **normative** references are only available for paying a fee?Ā  I guess that there are some, but I donā€™t know of any. Your claim implies definitive knowledge, however. > > In general, the IETF tends to dislike using standards where the specification is not freely available in English. That last part, in English, is perhaps narrow-minded these days, but the IETF works in English.Ā  Also, note that I said ā€œtends to dislikeā€ and didnā€™t claim a hard rule always enforced.Ā  In the past, where there have been issues, it has been not uncommon to write internet-drafts and publish through CFRG; see https://datatracker.ietf.org/rg/cfrg/documents/ for many examples. Sometimes they are published as individual stream RFCā€™s; see https://tools.ietf.org/html/rfc7091 for a highly applicable example. > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Sun Aug 18 04:55:32 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFF6A120077 for ; Sun, 18 Aug 2019 04:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ycwlqTxXDx0 for ; Sun, 18 Aug 2019 04:55:27 -0700 (PDT) Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::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 8131E120180 for ; Sun, 18 Aug 2019 04:55:27 -0700 (PDT) Received: by mail-oi1-x22e.google.com with SMTP id g128so162742oib.1 for ; Sun, 18 Aug 2019 04:55:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=/N5IIBnT0E/wwlKUQrzdBAlhguTFJkTPNbQ7kz7hPkY=; b=Hv8Vq4Xob04Vj0nmW+0Eul7bfAcWyUtTicGBYbqJzptamtb8aOLWE0Io9Qtu2l3qot oXFbAb849DxIs1s1ptEiMD0o9qBp3QnNgg5raS+HO0nFOHYol6k12Tr6mbcTpv0VsrqE +QplOIIaXcOXzBJlldPkY3/9wMxbZgz4pnmJWg4+eWXhkiaq0bGye1RoxSetRb+C7Xzm a8cfYqlFcLKfJrAbaS/HeHJoF2tKWFd23EUIQ+zFIfYpQq6L2wNRFPREd7dPW6iAeV2C dUqP/BZq6EL9RW+RHmyXLiC0Q8nezGr6eC1nWwQUl3Dvac2uvppl1vzbDf/YPnSxgJ/E a9zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=/N5IIBnT0E/wwlKUQrzdBAlhguTFJkTPNbQ7kz7hPkY=; b=aql7TLmDZ5qgRZicGWM4YZLRrwWXSsSV94zs7aNTL4JR00cpL8er0tEKZBmNwBQx3A VnSU2rfa9quv8//0ojEhBBsFsVfNooe83E0JD00DX2zfviUjKq4e+uCh+jgZvbBZjyQt UZP/mOkuF0gHsoJOEKrMBhERmrdnrY33lb9mmi1MyENLsYZxqdY1fCFPe570xkv8oW0E pqcR9hcNpy1LgNj5nwkPTnRcre3MTY2iwpSDnl7b/0Vb+Sg7WHWlN/2Ci7XGQjwBEJ9t 7Lldfyf5WFMgEZ2vHq0hc0x04XfJv+i1a/1y0DGLGLWFUvyvXJFJIkKlD+zlcVDBmbI7 acRQ== X-Gm-Message-State: APjAAAUU57oSlsfe3m2gBkEtiWiMMaBKaRbW5d44/eYobIzr/Sv6I4Ro OaMTqCVTXVDxloNxJrpKbQlelmnpb7+tTFZR0ts= X-Google-Smtp-Source: APXvYqylh9qsWWhpyQyI/wXMn/fq7D83uvBQ2XJkf2LuAKHerLJ8SJF7bv7q9EQcJw5rQctHpfcmhIiuOx6PC9CLOCo= X-Received: by 2002:aca:1a0b:: with SMTP id a11mr10622277oia.128.1566129326823; Sun, 18 Aug 2019 04:55:26 -0700 (PDT) MIME-Version: 1.0 References: <3350587b-f768-425f-a759-3ed7ce2e6b27.kepeng.lkp@alibaba-inc.com> <1e07a7cc-b316-6a1d-6f59-b352ffbd74b8@gmail.com> In-Reply-To: From: Paul Yang Date: Sun, 18 Aug 2019 19:55:11 +0800 Message-ID: To: Kepeng Li Cc: "Salz, Rich" , "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] (offline) Re: Draft for SM cipher suites used in TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 18 Aug 2019 11:55:30 -0000 No, I just found the 'RelaxNG' (The [RNC] ISO/IEC reference in RFC8428) has free specifications (Standardized by OASIS) other than the ISO version, check: https://relaxng.org/#specs. So it's not only available for paying a fee. I think we need to provide such stuffs alongside the ISO files mentioned in our draft. On Sun, Aug 18, 2019 at 4:10 PM Kepeng Li wrot= e: > > >Can you point to specific drafts where *normative* references are only a= vailable for paying a fee? I guess that there are some, but I don=E2=80=99= t know of any. > > This is one example: https://www.rfc-editor.org/rfc/rfc8428.txt > > [RNC]; ISO/IEC, "Information technology -- Document Schema Definition Lan= guage (DSDL) -- Part 2: Regular-grammar-based validation -- RELAX NG", ISO/= IEC 19757-2, Annex C: RELAX NG Compact syntax, December 2008. > > Kind Regards > Kepeng > > -------------------------- > =E5=8F=91=E4=BB=B6=E4=BA=BA:Salz, Rich > =E6=97=A5=E6=9C=9F=EF=BC=9A8=E6=9C=8816=E6=97=A5 23:06 > =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9AKepeng Li > =E8=BE=93=E5=85=A5=E4=B8=BB=E9=A2=98Re: [TLS] (offline) Re: Draft for SM = cipher suites used in TLS1.3 > > > >How does the other IETF drafts make the references to ISO documents? ISO= documents are often referenced by IETF drafts. > > > > Can you point to specific drafts where *normative* references are only av= ailable for paying a fee? I guess that there are some, but I don=E2=80=99t= know of any. Your claim implies definitive knowledge, however. > > > > In general, the IETF tends to dislike using standards where the specifica= tion is not freely available in English. That last part, in English, is per= haps narrow-minded these days, but the IETF works in English. Also, note t= hat I said =E2=80=9Ctends to dislike=E2=80=9D and didn=E2=80=99t claim a ha= rd rule always enforced. In the past, where there have been issues, it has= been not uncommon to write internet-drafts and publish through CFRG; see h= ttps://datatracker.ietf.org/rg/cfrg/documents/ for many examples. Sometimes= they are published as individual stream RFC=E2=80=99s; see https://tools.i= etf.org/html/rfc7091 for a highly applicable example. > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --=20 Regards Paul Yang From nobody Sun Aug 18 05:52:27 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83827120220 for ; Sun, 18 Aug 2019 05:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MvbDU_QO-sBe for ; Sun, 18 Aug 2019 05:52:17 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B04A12022C for ; Sun, 18 Aug 2019 05:52:17 -0700 (PDT) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x7ICq1QW003829; Sun, 18 Aug 2019 13:52:12 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=bwwJXfcg8YLgifTTO2mz4TtcjuV5VWs4lel+NB7AYj0=; b=D85/NnUE9yRARKZZIkYqESNIqZwd1bhxuq+6EpEnVtKsJloO4wOmpKwZiIFuw3CYeqaa HXZj729Oc6a7HJqdQxsVqV7mfvCoTKik/UcGtF7GCvCrcxougSWc6CRvoDL9vA0F0NJm n1W/+HsZ0ax/X7uhtU4XC0mq97TMTfv0C3vlHjquxP+UvhFzfIwyrSv147NAfdncoG0e ZDthnLgT91i4TL4IIN1C/cbPzg0E3KkFfygMP+aHXY+feAi09/5B3SEgdDuANSubNfrg aNAdHuLi7LXrxeHnRF0KTYbhdvdBP7r+1pwQX6xJY01Y2UjbX+eDknqzPt5zfbCbb0z1 lQ== Received: from prod-mail-ppoint7 (prod-mail-ppoint7.akamai.com [96.6.114.121] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2ue6es5mw8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 18 Aug 2019 13:52:12 +0100 Received: from pps.filterd (prod-mail-ppoint7.akamai.com [127.0.0.1]) by prod-mail-ppoint7.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x7IClCDA029871; Sun, 18 Aug 2019 08:52:11 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.57]) by prod-mail-ppoint7.akamai.com with ESMTP id 2uecwvqfrn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 18 Aug 2019 08:52:10 -0400 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.1473.3; Sun, 18 Aug 2019 08:52:07 -0400 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.1473.005; Sun, 18 Aug 2019 08:52:07 -0400 From: "Salz, Rich" To: Kepeng Li CC: "'tls@ietf.org'" Thread-Topic: [TLS] (offline) Re: Draft for SM cipher suites used in TLS1.3 Thread-Index: AQHVVEMWHZ8LpEHPb025DYn6/X4p8Kb93+8AgALzDoCAAAv4gA== Date: Sun, 18 Aug 2019 12:52:07 +0000 Message-ID: <8EE550E4-20E6-4D83-89E6-A43F63E3A593@akamai.com> References: <3350587b-f768-425f-a759-3ed7ce2e6b27.kepeng.lkp@alibaba-inc.com> <1e07a7cc-b316-6a1d-6f59-b352ffbd74b8@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1c.0.190812 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.79] Content-Type: multipart/alternative; boundary="_000_8EE550E420E64D8389E6A43F63E3A593akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-18_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=721 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908180142 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:5.22.84,1.0.8 definitions=2019-08-18_07:2019-08-16,2019-08-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 impostorscore=0 clxscore=1015 priorityscore=1501 adultscore=0 malwarescore=0 spamscore=0 mlxscore=0 suspectscore=0 bulkscore=0 mlxlogscore=704 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1906280000 definitions=main-1908180143 Archived-At: Subject: Re: [TLS] (offline) Re: Draft for SM cipher suites used in TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 18 Aug 2019 12:52:26 -0000 --_000_8EE550E420E64D8389E6A43F63E3A593akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCsOYICBUaGlzIGlzIG9uZSBleGFtcGxlOiBodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9y ZmMvcmZjODQyOC50eHQNCg0KDQoNClRoYW5rIHlvdS4NCg0KDQoNClRoYXQgaXMgYSBiaXQgZGlm ZmVyZW50IHNpbmNlIFJOQyBpc27igJl0IG5lZWRlZCB0byBpbXBsZW1lbnQgdGhlIFJGQywgYW5k IGEgd2ViIHNlYXJjaCBmb3Ig4oCccmVsYXhuZ+KAnSBmaW5kcyB0aG91c2FuZHMgb2YgcmVmZXJl bmNlcy4gIFRoZSBTTTIsIGV0Yy4sIHNpdHVhdGlvbiBpcyBkaWZmZXJlbnQgYmVjYXVzZSB5b3Ug Y2Fubm90IGltcGxlbWVudCB0aGUgY2lwaGVyIHdpdGhvdXQgdGhlIGRlZmluaXRpb24gb2YgaXQu DQoNCg0K --_000_8EE550E420E64D8389E6A43F63E3A593akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <387F112C38065941A483AEDB9B19600D@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEx LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv bGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFs MA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJn aW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1l OiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9 DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0 LWlkOjIxMDIwOTkwMjU7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOi04MjcxODAzMzggMTAwOTc5ODYzNiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2 NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDps ZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1z by1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6Q2Fs aWJyaTt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVs NQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K QGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJn aW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox My41cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwh W2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OldpbmdkaW5ncyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+w5g8c3BhbiBzdHls ZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyA8L3NwYW4+ PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGlzIGlzIG9uZSBleGFt cGxlOiA8YSBocmVmPSJodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9yZmMvcmZjODQyOC50eHQi Pmh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmM4NDI4LnR4dDwvYT48L3NwYW4+PG86 cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGFuayB5b3UuPG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhhdCBpcyBhIGJpdCBkaWZmZXJlbnQg c2luY2UgUk5DIGlzbuKAmXQgbmVlZGVkIHRvIGltcGxlbWVudCB0aGUgUkZDLCBhbmQgYSB3ZWIg c2VhcmNoIGZvciDigJxyZWxheG5n4oCdIGZpbmRzIHRob3VzYW5kcyBvZiByZWZlcmVuY2VzLiZu YnNwOyBUaGUgU00yLCBldGMuLCBzaXR1YXRpb24gaXMgZGlmZmVyZW50IGJlY2F1c2UgeW91IGNh bm5vdCBpbXBsZW1lbnQgdGhlIGNpcGhlciB3aXRob3V0IHRoZSBkZWZpbml0aW9uIG9mIGl0Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPGRpdj4NCjxwcmU+PGI+PG86cD4mbmJzcDs8L286cD48 L2I+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_8EE550E420E64D8389E6A43F63E3A593akamaicom_-- From nobody Sun Aug 18 06:48:21 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E695912008C for ; Sun, 18 Aug 2019 06:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zz_q8kM9ZJ9y for ; Sun, 18 Aug 2019 06:48:18 -0700 (PDT) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91DFF120024 for ; Sun, 18 Aug 2019 06:48:17 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id c19so7073371lfm.10 for ; Sun, 18 Aug 2019 06:48:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rhsbTLfeXQZmQ2HWPBI+u3RGzRbJgxiBRsOtXRDuXd0=; b=xtE81n/pG+Cq5NKJBsypwJlDN6Ig2sUV+qcfSLYiD+5euse4qIVbeqe9VS6IubT4wX XlJKgp9sqiusz5AWwWoU9xUgvIAjUhedybkMhQ8SCnQx1x39R8VpWIuBsmUGFs2wOJqQ pkZAhoNrcZmAJ+8FDBhd2l5LuoDHc2KThYaDwMYA9Kw+6KyAE5fmTAhJyoSErszL4i6u ivnwMtHhm0lPt+d3tZ8pxUuWMU1Ft8IdkEvzOM0+uf4wOdN0zxDuJjAO7C5M7fTHCybm 37iq3q9cNZ6RoeuNhxoFTLhBnEIqWHbvMzMHZJ0uqqSaYNg7m4WnhZgMRkZc6K25oykY eiJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rhsbTLfeXQZmQ2HWPBI+u3RGzRbJgxiBRsOtXRDuXd0=; b=DxoYLug0H/A+26O2MKfAtWKRiiYCwqZVpP/1cSpHehPrUKnlvsKk9RUqhJLE8/SIKw sGj1T0y/2rH2QpkBF2dFwd/u+IfTDXmSzaik3U+hKvldCPvnDk9wATwO4DeFf2WZphuB YfD/pInEcL9BGk1ySKNy0cR0HVprk2sWOpLiodrvx7bjehtcyMTPjLiYXhovgxZPTFuJ Gpk6haKy0DiqQtRiOfYC2in9PhvCIuXxFomuQeuEmU2F8gJMbAmxWX/tGrSy3HMqanQP 6MC9UFdXFdqRlasjaAWKcwrwSj7XAc5JusFJRfSAyoQYWtNGi3fcbG5cRDy5sxxPl6HU Uu4A== X-Gm-Message-State: APjAAAVLsKTrsvQZ4gT5GWNRbAcU/91fZnVk/5p3yMkeq/XiCiPFv9tY uBs+7eADKaEWt8qaXlaqIcwhJnwSJWnojMblJwCGNw== X-Google-Smtp-Source: APXvYqz+LmbO2wMrEhmVo2NdIWB8Tcr7sVhuHVxAc8w6Vv4sOQlfkAE/Qz+YF64Mmov/tYofN2ef29nuGGHVr+Mtrko= X-Received: by 2002:ac2:51a3:: with SMTP id f3mr9384635lfk.94.1566136095733; Sun, 18 Aug 2019 06:48:15 -0700 (PDT) MIME-Version: 1.0 References: <3350587b-f768-425f-a759-3ed7ce2e6b27.kepeng.lkp@alibaba-inc.com> <1e07a7cc-b316-6a1d-6f59-b352ffbd74b8@gmail.com> <8EE550E4-20E6-4D83-89E6-A43F63E3A593@akamai.com> In-Reply-To: <8EE550E4-20E6-4D83-89E6-A43F63E3A593@akamai.com> From: Eric Rescorla Date: Sun, 18 Aug 2019 15:47:39 +0200 Message-ID: To: "Salz, Rich" Cc: Kepeng Li , "tls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a80cc005906479d3" Archived-At: Subject: Re: [TLS] (offline) Re: Draft for SM cipher suites used in TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 18 Aug 2019 13:48:20 -0000 --000000000000a80cc005906479d3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The intent of the "Specification Required" requirement for registration is that sufficient public information be available to allow an interoperable implementation. Specifically, the text says: https://tools.ietf.org/html/rfc8126#section-4.6 For the Specification Required policy, review and approval by a designated expert (see Section 5) is required, and the values and their meanings must be documented in a permanent and readily available public specification, in sufficient detail so that interoperability between independent implementations is possible. This policy is the same as Expert Review, with the additional requirement of a formal public specification. In addition to the normal review of such a request, the designated expert will review the public specification and evaluate whether it is sufficiently stable and permanent, and sufficiently clear and technically sound to allow interoperable implementations. I don't think that a for-pay specification meets that threshold, though I'm not aware of any IETF-wide policy on that (although I may just have missed it). In the absence of that, it would as stated above, be on the Expert to determine the standard. -Ekr On Sun, Aug 18, 2019 at 2:52 PM Salz, Rich wrote: > > > =C3=98 This is one example: https://www.rfc-editor.org/rfc/rfc8428.txt > > > > Thank you. > > > > That is a bit different since RNC isn=E2=80=99t needed to implement the R= FC, and a web search for =E2=80=9Crelaxng=E2=80=9D finds thousands of refer= ences. The SM2, etc., situation is different because you cannot implement = the cipher without the definition of it. > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000a80cc005906479d3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The intent of the "Specification Required" = requirement for registration is that sufficient public information be avail= able to allow an interoperable implementation. Specifically, the text says:=

=C2=A0=C2=A0 For the Specification Required policy, review and= approval by a
=C2=A0 =C2=A0designated expert (see Section 5) is require= d, and the values and
=C2=A0 =C2=A0their meanings must be documented in = a permanent and readily
=C2=A0 =C2=A0available public specification, in = sufficient detail so that
=C2=A0 =C2=A0interoperability between independ= ent implementations is possible.
=C2=A0 =C2=A0This policy is the same as= Expert Review, with the additional
=C2=A0 =C2=A0requirement of a formal= public specification.=C2=A0 In addition to the
=C2=A0 =C2=A0normal revi= ew of such a request, the designated expert will review
=C2=A0 =C2=A0the= public specification and evaluate whether it is sufficiently
=C2=A0 =C2= =A0stable and permanent, and sufficiently clear and technically sound to=C2=A0 =C2=A0allow interoperable implementations.

I don't think that a for-pay specification meets that threshold, thoug= h I'm
not aware of any IETF-wide policy on that (although I m= ay just have missed
it).

In the absence = of that, it would as stated above, be on the Expert to determine
= the standard.

-Ekr




=
On Sun, Aug 18, 2019 at 2:52 PM Salz,= Rich <rsalz@akamai.com> wrot= e:
=C2=A0
=C3=98=C2=A0 This is one example: https://www.rf=
c-editor.org/rfc/rfc8428.txt
=C2=A0
Thank you.
=C2=A0
That is a bit different since RNC isn=E2=80=99t needed to implement the=
 RFC, and a web search for =E2=80=9Crelaxng=E2=80=9D finds thousands of ref=
erences.=C2=A0 The SM2, etc., situation is different because you cannot imp=
lement the cipher without the definition of it.
=C2=A0
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000a80cc005906479d3-- From nobody Sun Aug 18 07:08:06 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E13E120098 for ; Sun, 18 Aug 2019 07:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.195 X-Spam-Level: X-Spam-Status: No, score=-4.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bfSeysOGEoAy for ; Sun, 18 Aug 2019 07:08:02 -0700 (PDT) Received: from llmx3.ll.mit.edu (LLMX3.LL.MIT.EDU [129.55.12.49]) (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 B4A5C1200B5 for ; Sun, 18 Aug 2019 07:08:01 -0700 (PDT) Received: from LLE2K16-MBX02.mitll.ad.local (LLE2K16-MBX02.mitll.ad.local) by llmx3.ll.mit.edu (unknown) with ESMTPS id x7IE7tYm020079; Sun, 18 Aug 2019 10:07:55 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: Paul Yang CC: "tls@ietf.org" Thread-Topic: [TLS] (offline) Re: Draft for SM cipher suites used in TLS1.3 Thread-Index: AQHVVEMkQx/1Aj5YGkWg05vuYkTmS6b/DDyAgAIq8oA= Date: Sun, 18 Aug 2019 14:07:54 +0000 Message-ID: <3AA3FCE5-729F-4DA9-A3B9-52CC0CEB5571@ll.mit.edu> References: <3350587b-f768-425f-a759-3ed7ce2e6b27.kepeng.lkp@alibaba-inc.com> <1e07a7cc-b316-6a1d-6f59-b352ffbd74b8@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 Content-Type: multipart/signed; boundary="Apple-Mail-24DACA0A-ED0E-4961-9AC4-EC558C1C96A7"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-18_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908180157 Archived-At: Subject: Re: [TLS] (offline) Re: Draft for SM cipher suites used in TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 18 Aug 2019 14:08:05 -0000 --Apple-Mail-24DACA0A-ED0E-4961-9AC4-EC558C1C96A7 Content-Type: multipart/alternative; boundary=Apple-Mail-4658E7C9-9165-48A6-8B57-A84F33C561FC Content-Transfer-Encoding: 7bit --Apple-Mail-4658E7C9-9165-48A6-8B57-A84F33C561FC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SU1ITywgcGxhY2luZyB0aGUgZG9jdW1lbnRzIG9uIEdpdEh1YiB3b3VsZCBiZSBwZXJmZWN0LCBh bmQgcXVpdGUgc3VmZmljaWVudC4gDQoNClBsZWFzZSBtYWtlIHN1cmUgdG8gcG9zdCB0aGUgbmFt ZSBvZiB0aGUgcmVwbyBoZXJlLiA7LykNCg0KSSBsZWF2ZSBpdCB0byBvdGhlcnMgdG8gZGVjaWRl IHdoZXRoZXIgdGhleSdkIHdhbnQgY29waWVzIG9mIHRvZGF5IFBERiBmaWxlcyBzZW50IHRvIHRo ZSBtYWlsaW5nIGxpc3QgZGlyZWN0bHkuDQoNClJlZ2FyZHMsDQpVcmkNCg0KU2VudCBmcm9tIG15 IGlQaG9uZQ0KDQo+IE9uIEF1ZyAxNywgMjAxOSwgYXQgMDE6MDMsIFBhdWwgWWFuZyA8a2Fpc2hl bi55eT00MGFsaXBheS5jb21AZG1hcmMuaWV0Zi5vcmc+IHdyb3RlOg0KPiANCj4gR29vZCBwb2lu dHMuDQo+IA0KPiBUaGUgZ29vZCBuZXdzIGlzIHRoYXQgd2UgaGF2ZSBmb3VuZCBzb21lIEVuZ2xp c2ggUERGcyBvZiBTTTIsIGluY2x1ZGluZyB0aGUgbWlzc2luZyBwYXJ0IDEgYW5kIHBhcnQgMy4g V2lsbCBjb250aW51ZSB0byBmaW5kIEVuZ2xpc2ggdHJhbnNsYXRpb25zIG9mIG90aGVyIFNNIHN0 YW5kYXJkcyBtZW50aW9uZWQgaW4gdGhlIGRyYWZ0Lg0KPiANCj4gU28sIGlmIHdlIGhvc3QgYSBm cmVlIHdlYnNpdGUsIHNheSBvbiBHaXRodWIgb3Igc28sIHRvIHByb3ZpZGUgdGhvc2UgZG9jcywg aXMgaXQgY29udmVuaWVudCBmb3IgeW91IGd1eXM/IE9yIHNob3VsZCB3ZSBqdXN0IGRyb3AgdGhl ICAgUERGIGZpbGVzIHRvIHRoaXMgbWFpbGluZyBsaXN0IGFzIGF0dGFjaG1lbnRzPw0KPiANCj4+ IE9uIEF1ZyAxNiwgMjAxOSwgYXQgMTA6NTggUE0sIFJlbmUgU3RydWlrIDxyc3RydWlrLmV4dEBn bWFpbC5jb20+IHdyb3RlOg0KPj4gDQo+PiBBcmd1YWJseSwgIm5hdGlvbmFsIiBjcnlwdG8gc3Bl Y2lmaWNhdGlvbnMgZ2FybmlzaCBtb3JlIHN0YXR1cmUgaWYgdGhlc2UgYXJlIG1hZGUgYXZhaWxh YmxlIHRvIHRoZSBwdWJpYyBieSB0aGF0IHN0YW5kYXJkLXNldHRpbmcgYm9keSBpdHNlbGYgKHdo bywgdGhlcmVieSwgYWN0cyBhcyBpdHMgYXV0aG9yaXRhdGl2ZSBzb3VyY2UpLCB3aXRob3V0IGRl ZmVyZW5jZSB0byBhIHRoaXJkIHBhcnR5ICh0aGF0IG1heSwgaW5kZXBlbmRlbnRseSBmcm9tIHRo ZSBvcmlnaW5hdG9yLCBlbmZvcmNlIGRvY3VtZW50IGNvbnRyb2wgW2UuZy4sIGJ5IGVmZmVjdHVh dGluZyB0ZWNobmljYWwgY2hhbmdlcyBvciBlbmZvcmNpbmcgY29udHJvbGxlZCBkaXNzZW1pbmF0 aW9uXSkuIA0KPj4gDQo+PiBTaW5jZSB5b3VyIGRyYWZ0IGludHJvZHVjaW5nIFNNIGNpcGhlciBz dWl0ZXMgd2l0aCBUTFMxLjMgYXBwZWFscyB0byB0aGUgYXV0aG9yaXR5IG9mIGEgc3RhbmRhcmQt c2V0dGluZyBhdXRob3JpdHksIGVhc3kgYXZhaWxhYmlsaXR5IG9mIHRoZSBmdWxsIGFuZCBhY2Ny ZWRpdGVkIHRlY2huaWNhbCBkb2N1bWVudGF0aW9uIHRvIHRoZSBJRVRGIGNvbW11bml0eSBoZWxw cyBpbiBzY3J1dGlueSBhbmQsIGUuZy4sIGV2YWx1YXRpbmcgY2xhaW1zIGluIHRoZSBzZWN1cml0 eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uLg0KPj4gDQo+Pj4gT24gOC8xNi8yMDE5IDM6MDYgQU0s IEtlcGVuZyBMaSB3cm90ZToNCj4+PiBIaSBSZW5lIGFuZCBhbGwsDQo+Pj4gDQo+Pj4gPiBTaW5j ZSB0aGUgSVNPIGRvY3VtZW50cyBhcmUgbm90IGF2YWlsYWJsZSB0byB0aGUgZ2VuZXJhbCANCj4+ PiA+IHB1YmxpYyB3aXRob3V0IHBheW1lbnQsIGl0IHdvdWxkIGJlIGhlbHBmdWwgdG8gaGF2ZSBh IGZyZWVseSBhdmFpbGFibGUgDQo+Pj4gPiBkb2N1bWVudCAoaW4gRW5nbGlzaCkgZnJvbSBhbiBh dXRob3JpdGF0aXZlIHNvdXJjZS4gSGF2aW5nIHN1Y2ggYSANCj4+PiA+IHJlZmVyZW5jZSBhdmFp bGFibGUgd291bGQgYmUgaGVscGZ1bCB0byB0aGUgSUVURiBjb21tdW5pdHkgKGFuZCANCj4+PiA+ IHJlc2VhcmNoZXJzKS4NCj4+PiBBYm91dCB0aGUgcmVmZXJlbmNlcyB0byBJU08gZG9jdW1lbnMs IEkgdGhpbmsgaXQgaXMgYSBnZW5lcmFsIGlzc3VlIGZvciBJRVRGIGRyYWZ0cy4NCj4+PiANCj4+ PiBIb3cgZG9lcyB0aGUgb3RoZXIgSUVURiBkcmFmdHMgbWFrZSB0aGUgcmVmZXJlbmNlcyB0byBJ U08gZG9jdW1lbnRzPyBJU08gZG9jdW1lbnRzIGFyZSBvZnRlbiByZWZlcmVuY2VkIGJ5IElFVEYg ZHJhZnRzLg0KPj4+IA0KPj4+IFRoYW5rcywNCj4+PiANCj4+PiBLaW5kIFJlZ2FyZHMNCj4+PiBL ZXBlbmcNCj4+PiDigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTi gJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTi gJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTi gJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJQNCj4+PiBSZTogW1RMU10gRHJh ZnQgZm9yIFNNIGNpcGhlciBzdWl0ZXMgdXNlZCBpbiBUTFMxLjMNCj4+PiANCj4+PiBSZW5lIFN0 cnVpayA8cnN0cnVpay5leHRAZ21haWwuY29tPiBUaHUsIDE1IEF1Z3VzdCAyMDE5IDE1OjM0IFVU Q1Nob3cgaGVhZGVyDQo+Pj4gDQo+Pj4gSGkgUGF1bDoNCj4+PiANCj4+PiBJIHRyaWVkIGFuZCBs b29rIHVwIHRoZSBkb2N1bWVudHMgR01ULjAwMDktMjAxMiBhbmQgR0JULjMyOTE4LjUtMjAxNiBv biANCj4+PiB0aGUgKG5vbi1zZWN1cmVkKSB3ZWJzaXRlcyB5b3UgcmVmZXJlbmNlZCwgYnV0IG9u bHkgZm91bmQgQ2hpbmVzZSANCj4+PiB2ZXJzaW9ucyAoYW5kIENoaW5lc2Ugd2Vic2l0ZSBuYXZp Z2F0aW9uIHBhbmVscyBbcGFyZG9uIG15IHBvb3IgbGFuZ3VhZ2UgDQo+Pj4gc2tpbGxzIGhlcmVd KS4gU2luY2UgdGhlIElTTyBkb2N1bWVudHMgYXJlIG5vdCBhdmFpbGFibGUgdG8gdGhlIGdlbmVy YWwgDQo+Pj4gcHVibGljIHdpdGhvdXQgcGF5bWVudCwgaXQgd291bGQgYmUgaGVscGZ1bCB0byBo YXZlIGEgZnJlZWx5IGF2YWlsYWJsZSANCj4+PiBkb2N1bWVudCAoaW4gRW5nbGlzaCkgZnJvbSBh biBhdXRob3JpdGF0aXZlIHNvdXJjZS4gSGF2aW5nIHN1Y2ggYSANCj4+PiByZWZlcmVuY2UgYXZh aWxhYmxlIHdvdWxkIGJlIGhlbHBmdWwgdG8gdGhlIElFVEYgY29tbXVuaXR5IChhbmQgDQo+Pj4g cmVzZWFyY2hlcnMpLiBQbGVhc2Ugbm90ZSB0aGF0IEJTSSBwcm92aWRlcyBpdHMgc3BlY2lmaWNh dGlvbnMgaW4gR2VybWFuIA0KPj4+IGFuZCBFbmdsaXNoLCBzbyBhcyB0byBmb3N0ZXIgdXNlL3N0 dWR5IGJ5IHRoZSBjb21tdW5pdHkuIElmIHRoZSBDaGluZXNlIA0KPj4+IG5hdGlvbmFsIGFsZ29y aXRobXMgd291bGQgYmUgYXZhaWxhYmxlIGluIHNpbWlsYXIgZm9ybSwgdGhpcyB3b3VsZCBzZXJ2 ZSANCj4+PiBhIHNpbWlsYXIgcHVycG9zZS4NCj4+PiANCj4+PiBGWUkgLSBJIGFtIGludGVyZXN0 ZWQgaW4gZnVsbCBkZXRhaWxzIGFuZCBzb21lIHRpbWUgbGFzdCB5ZWFyIEkgdHJpZWQgdG8gDQo+ Pj4gZG93bmxvYWQgc3BlY3MsIGJ1dCBvbmx5IFBhcnRzIDIsIDQsIGFuZCA1IHdlcmUgYXZhaWxh YmxlIFsxXSwgWzJdLCBbM10sIA0KPj4+IG5vdCBQYXJ0cyAxIGFuZCAzLg0KPj4+IA0KPj4+IEJl c3QgcmVnYXJkcywgUmVuZQ0KPj4+IA0KPj4+IFsxXSBDaGluYSBFQ0MgLSBQdWJsaWMgS2V5IENy eXB0b2dyYXBoaWMgQWxnb3JpdGhtIFNNMiBCYXNlZCBvbiBFQ0MgLSANCj4+PiBQYXJ0IDUgLSBQ YXJhbWV0ZXIgRGVmaW5pdGlvbiAoU0VNQiwgSnVseSAyNCwgMjAxOCkNCj4+PiBbMl0gQ2hpbmEg RUNDIC0gUHVibGljIEtleSBDcnlwdG9ncmFwaGljIEFsZ29yaXRobSBTTTIgQmFzZWQgb24gRUND IC0gDQo+Pj4gUGFydCAyIC0gRGlnaXRhbCBTaWduYXR1cmUgQWxnb3JpdGhtIChTRU1CLCBKdWx5 IDI0LCAyMDE4KQ0KPj4+IFszXSBDaGluYSBFQ0MgLSBQdWJsaWMgS2V5IENyeXB0b2dyYXBoaWMg QWxnb3JpdGhtIFNNMiBCYXNlZCBvbiBFQ0MgLSANCj4+PiBQYXJ0IDQgLSBQdWJsaWMgS2V5IEVu Y3J5cHRpb24gQWxnb3JpdGhtIChTRU1CLCBKdWx5IDI0LCAyMDE4KQ0KPj4+IA0KPj4+IE9uIDgv MTUvMjAxOSAxMDoxNiBBTSwgUGF1bCBZYW5nIHdyb3RlOg0KPj4+ID4gSGkgYWxsLA0KPj4+ID4N Cj4+PiA+IEkgaGF2ZSBzdWJtaXR0ZWQgYSBuZXcgaW50ZXJuZXQgZHJhZnQgdG8gaW50cm9kdWNl IHRoZSBTTSBjaXBoZXIgDQo+Pj4gPiBzdWl0ZXMgaW50byBUTFMgMS4zIHByb3RvY29sLg0KPj4+ ID4NCj4+PiA+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC15YW5nLXRscy10bHMx My1zbS1zdWl0ZXMtMDANCj4+PiA+DQo+Pj4gPiBTTSBjcnlwdG9ncmFwaGljIGFsZ29yaXRobXMg YXJlIG9yaWdpbmFsbHkgYSBzZXQgb2YgQ2hpbmVzZSBuYXRpb25hbCANCj4+PiA+IGFsZ29yaXRo bXMgYW5kIG5vdyBoYXZlIGJlZW4gKG9yIGJlaW5nKSBhY2NlcHRlZCBieSBJU08gYXMgDQo+Pj4g PiBpbnRlcm5hdGlvbmFsIHN0YW5kYXJkcywgaW5jbHVkaW5nIFNNMiBzaWduYXR1cmUgYWxnb3Jp dGhtLCBTTTMgaGFzaCANCj4+PiA+IGZ1bmN0aW9uIGFuZCBTTTQgYmxvY2sgY2lwaGVyLiBUaGVz ZSBhbGdvcml0aG1zIGhhdmUgYWxyZWFkeSBiZWVuIA0KPj4+ID4gc3VwcG9ydGVkIHNvbWUgdGlt ZSBhZ28gYnkgc2V2ZXJhbCB3aWRlbHkgdXNlZCBvcGVuIHNvdXJjZSANCj4+PiA+IGNyeXB0b2dy YXBoaWMgbGlicmFyaWVzIGluY2x1ZGluZyBPcGVuU1NMLCBCb3VuY3lDYXN0bGUsIEJvdGFuLCBl dGMuDQo+Pj4gPg0KPj4+ID4gQ29uc2lkZXJpbmcgVExTMS4zIGlzIGJlaW5nIGdyYWR1YWxseSBh ZG9wdGVkIGluIENoaW5hJ3MgaW50ZXJuZXQgDQo+Pj4gPiBpbmR1c3RyeSwgaXQncyBpbXBvcnRh bnQgdG8gaGF2ZSBhIG5vcm1hdGl2ZSBkZWZpbml0aW9uIG9uIGhvdyB0byB1c2UgDQo+Pj4gPiB0 aGUgU00gYWxnb3JpdGhtcyB3aXRoIFRMUzEuMywgZXNwZWNpYWxseSBmb3IgdGhlIG1vYmlsZSBp bnRlcm5ldCANCj4+PiA+IHNjZW5hcmlvLiBBbnQgRmluYW5jaWFsIGlzIHRoZSBjb21wYW55IHdo byBkZXZlbG9wcyB0aGUgbWFya2V0IGxlYWRpbmcgDQo+Pj4gPiBtb2JpbGUgYXBwICdBbGlwYXkn IGFuZCBzdXBwb3J0cyBwYXltZW50IHNlcnZpY2VzIGZvciBBbGliYWJhIA0KPj4+ID4gZS1jb21t ZXJjZSBidXNpbmVzcy4gV2UgaGlnaGx5IGFyZSBkZXBlbmRpbmcgb24gdGhlIG5ldyBUTFMxLjMg DQo+Pj4gPiBwcm90b2NvbCBmb3IgYm90aCBwZXJmb3JtYW5jZSBhbmQgc2VjdXJpdHkgcHVycG9z ZXMuIFdlIGV4cGVjdCB0byBoYXZlIA0KPj4+ID4gbW9yZSBkZXBsb3ltZW50IG9mIFRMUzEuMyBj YXBhYmxlIGFwcGxpY2F0aW9ucyBpbiBDaGluYSdzIGludGVybmV0IA0KPj4+ID4gaW5kdXN0cnkg YnkgdGhpcyBzdGFuZGFyZGl6YXRpb24gYXR0ZW1wdHMuDQo+Pj4gPg0KPj4+ID4gSXQncyB2ZXJ5 IGFwcHJlY2lhdGVkIHRvIGhhdmUgY29tbWVudHMgZnJvbSB0aGUgSUVURiBUTFMgbGlzdCA6LSkN Cj4+PiA+DQo+Pj4gPiBNYW55IHRoYW5rcyENCj4+PiA+DQo+Pj4gPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ID4gVExTIG1haWxpbmcgbGlzdA0K Pj4+ID4gVExTQGlldGYub3JnDQo+Pj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3Rscw0KPj4+IA0KPj4gDQo+PiAtLSANCj4+IGVtYWlsOiByc3RydWlrLmV4dEBnbWFp bC5jb20gfCBTa3lwZTogcnN0cnVpaw0KPj4gY2VsbDogKzEgKDY0NykgODY3LTU2NTggfCBVUzog KzEgKDQxNSkgNjkwLTczNjMNCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+PiBUTFMgbWFpbGluZyBsaXN0DQo+PiBUTFNAaWV0Zi5vcmcNCj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQo+IA0KPiANCj4gUmVnYXJk cywNCj4gDQo+IFBhdWwgWWFuZw0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gVExTIG1haWxpbmcgbGlzdA0KPiBUTFNAaWV0Zi5vcmcNCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMNCg== --Apple-Mail-4658E7C9-9165-48A6-8B57-A84F33C561FC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPklNSE8sIHBsYWNp bmcgdGhlIGRvY3VtZW50cyBvbiBHaXRIdWIgd291bGQgYmUgcGVyZmVjdCwgYW5kIHF1aXRlIHN1 ZmZpY2llbnQuJm5ic3A7PGRpdj48YnI+PC9kaXY+PGRpdj5QbGVhc2UgbWFrZSBzdXJlIHRvIHBv c3QgdGhlIG5hbWUgb2YgdGhlIHJlcG8gaGVyZS4gOy8pPGRpdj48YnI+PC9kaXY+PGRpdj5JIGxl YXZlIGl0IHRvIG90aGVycyB0byBkZWNpZGUgd2hldGhlciB0aGV5J2Qgd2FudCBjb3BpZXMgb2Yg dG9kYXkgUERGIGZpbGVzIHNlbnQgdG8gdGhlIG1haWxpbmcgbGlzdCBkaXJlY3RseS48YnI+PGJy PjxkaXYgZGlyPSJsdHIiIGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPlJlZ2FyZHMsPGRpdj5Vcmk8 L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlNlbnQgZnJvbSBteSBpUGhvbmU8L2Rpdj48L2Rpdj48 ZGl2IGRpcj0ibHRyIj48YnI+T24gQXVnIDE3LCAyMDE5LCBhdCAwMTowMywgUGF1bCBZYW5nICZs dDs8YSBocmVmPSJtYWlsdG86a2Fpc2hlbi55eT00MGFsaXBheS5jb21AZG1hcmMuaWV0Zi5vcmci PmthaXNoZW4ueXk9NDBhbGlwYXkuY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3JvdGU6PGJy Pjxicj48L2Rpdj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48ZGl2IGRpcj0ibHRyIj48bWV0YSBo dHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYt OCI+R29vZCBwb2ludHMuPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+PC9kaXY+PGRpdiBjbGFz cz0iIj5UaGUgZ29vZCBuZXdzIGlzIHRoYXQgd2UgaGF2ZSBmb3VuZCBzb21lIEVuZ2xpc2ggUERG cyBvZiBTTTIsIGluY2x1ZGluZyB0aGUgbWlzc2luZyBwYXJ0IDEgYW5kIHBhcnQgMy4gV2lsbCBj b250aW51ZSB0byBmaW5kIEVuZ2xpc2ggdHJhbnNsYXRpb25zIG9mIG90aGVyIFNNIHN0YW5kYXJk cyBtZW50aW9uZWQgaW4gdGhlIGRyYWZ0LjwvZGl2PjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi PjwvZGl2PjxkaXYgY2xhc3M9IiI+U28sIGlmIHdlIGhvc3QgYSBmcmVlIHdlYnNpdGUsIHNheSBv biBHaXRodWIgb3Igc28sIHRvIHByb3ZpZGUgdGhvc2UgZG9jcywgaXMgaXQgY29udmVuaWVudCBm b3IgeW91IGd1eXM/IE9yIHNob3VsZCB3ZSBqdXN0IGRyb3AgdGhlICZuYnNwOyBQREYgZmlsZXMg dG8gdGhpcyBtYWlsaW5nIGxpc3QgYXMgYXR0YWNobWVudHM/PGJyIGNsYXNzPSIiPjxkaXY+PGJy IGNsYXNzPSIiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPjxkaXYgY2xhc3M9IiI+ T24gQXVnIDE2LCAyMDE5LCBhdCAxMDo1OCBQTSwgUmVuZSBTdHJ1aWsgJmx0OzxhIGhyZWY9Im1h aWx0bzpyc3RydWlrLmV4dEBnbWFpbC5jb20iIGNsYXNzPSIiPnJzdHJ1aWsuZXh0QGdtYWlsLmNv bTwvYT4mZ3Q7IHdyb3RlOjwvZGl2PjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGlu ZSI+PGRpdiBjbGFzcz0iIj4NCiAgDQogICAgPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBl IiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVRGLTgiIGNsYXNzPSIiPg0KICANCiAgPGRp diB0ZXh0PSIjMDAwMDAwIiBiZ2NvbG9yPSIjRkZGRkZGIiBjbGFzcz0iIj4NCiAgICA8ZGl2IGNs YXNzPSJtb3otY2l0ZS1wcmVmaXgiPkFyZ3VhYmx5LCAibmF0aW9uYWwiIGNyeXB0bw0KICAgICAg c3BlY2lmaWNhdGlvbnMgZ2FybmlzaCBtb3JlIHN0YXR1cmUgaWYgdGhlc2UgYXJlIG1hZGUgYXZh aWxhYmxlIHRvDQogICAgICB0aGUgcHViaWMgYnkgdGhhdCBzdGFuZGFyZC1zZXR0aW5nIGJvZHkg aXRzZWxmICh3aG8sIHRoZXJlYnksIGFjdHMNCiAgICAgIGFzIGl0cyBhdXRob3JpdGF0aXZlIHNv dXJjZSksIHdpdGhvdXQgZGVmZXJlbmNlIHRvIGEgdGhpcmQgcGFydHkNCiAgICAgICh0aGF0IG1h eSwgaW5kZXBlbmRlbnRseSBmcm9tIHRoZSBvcmlnaW5hdG9yLCBlbmZvcmNlIGRvY3VtZW50DQog ICAgICBjb250cm9sIFtlLmcuLCBieSBlZmZlY3R1YXRpbmcgdGVjaG5pY2FsIGNoYW5nZXMgb3Ig ZW5mb3JjaW5nDQogICAgICBjb250cm9sbGVkIGRpc3NlbWluYXRpb25dKS4gPGJyIGNsYXNzPSIi Pg0KICAgIDwvZGl2Pg0KICAgIDxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZpeCI+PGJyIGNsYXNz PSIiPg0KICAgIDwvZGl2Pg0KICAgIDxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZpeCI+U2luY2Ug eW91ciBkcmFmdCBpbnRyb2R1Y2luZyBTTSBjaXBoZXINCiAgICAgIHN1aXRlcyB3aXRoIFRMUzEu MyBhcHBlYWxzIHRvIHRoZSBhdXRob3JpdHkgb2YgYSBzdGFuZGFyZC1zZXR0aW5nDQogICAgICBh dXRob3JpdHksIGVhc3kgYXZhaWxhYmlsaXR5IG9mIHRoZSBmdWxsIGFuZCBhY2NyZWRpdGVkIHRl Y2huaWNhbA0KICAgICAgZG9jdW1lbnRhdGlvbiB0byB0aGUgSUVURiBjb21tdW5pdHkgaGVscHMg aW4gc2NydXRpbnkgYW5kLCBlLmcuLA0KICAgICAgZXZhbHVhdGluZyBjbGFpbXMgaW4gdGhlIHNl Y3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24uPGJyIGNsYXNzPSIiPg0KICAgIDwvZGl2Pg0K ICAgIDxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZpeCI+PGJyIGNsYXNzPSIiPg0KICAgIDwvZGl2 Pg0KICAgIDxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZpeCI+T24gOC8xNi8yMDE5IDM6MDYgQU0s IEtlcGVuZyBMaSB3cm90ZTo8YnIgY2xhc3M9IiI+DQogICAgPC9kaXY+DQogICAgPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSIgY2l0ZT0ibWlkOjMzNTA1ODdiLWY3NjgtNDI1Zi1hNzU5LTNlZDdjZTJl NmIyNy5rZXBlbmcubGtwQGFsaWJhYmEtaW5jLmNvbSIgY2xhc3M9IiI+DQogICAgICA8bWV0YSBo dHRwLWVxdWl2PSJjb250ZW50LXR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1VVEYt OCIgY2xhc3M9IiI+DQogICAgICA8ZGl2IGNsYXNzPSJfX2FsaXl1bl9lbWFpbF9ib2R5X2Jsb2Nr Ij4NCiAgICAgICAgPGRpdiBzdHlsZT0iY2xlYXI6Ym90aDsiIGNsYXNzPSIiPg0KICAgICAgICAg IDxkaXYgc3R5bGU9ImZvbnQtdmFyaWFudC1saWdhdHVyZXM6bm9ybWFsO2ZvbnQtdmFyaWFudC1j YXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50Oi4wcHg7d2lkb3dzOjI7YmFj a2dyb3VuZC1jb2xvcjojZmZmZmZmO3RleHQtZGVjb3JhdGlvbi1zdHlsZTppbml0aWFsO3RleHQt ZGVjb3JhdGlvbi1jb2xvcjppbml0aWFsO2NsZWFyOmJvdGg7IiBjbGFzcz0iIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOiAxNHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiA0MDA7 IHRleHQtdHJhbnNmb3JtOiBub25lOyBmb250LWZhbWlseTogYXJpYWw7IiBjbGFzcz0iIj5IaQ0K ICAgICAgICAgICAgICBSZW5lIGFuZCBhbGwsPC9zcGFuPjwvZGl2Pg0KICAgICAgICA8L2Rpdj4N CiAgICAgICAgPGRpdiBzdHlsZT0iY2xlYXI6Ym90aDsiIGNsYXNzPSIiPg0KICAgICAgICAgIDxk aXYgc3R5bGU9ImZvbnQtdmFyaWFudC1saWdhdHVyZXM6bm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBz Om5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50Oi4wcHg7d2lkb3dzOjI7YmFja2dy b3VuZC1jb2xvcjojZmZmZmZmO3RleHQtZGVjb3JhdGlvbi1zdHlsZTppbml0aWFsO3RleHQtZGVj b3JhdGlvbi1jb2xvcjppbml0aWFsO2NsZWFyOmJvdGg7IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOiAxNHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiA0MDA7IHRl eHQtdHJhbnNmb3JtOiBub25lOyBmb250LWZhbWlseTogYXJpYWw7IiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQogICAgICAgICAgICA8L3NwYW4+PC9kaXY+DQogICAgICAgIDwvZGl2Pg0KICAgICAg ICA8ZGl2IHN0eWxlPSJjbGVhcjpib3RoOyIgY2xhc3M9IiI+DQogICAgICAgICAgPGRpdiBzdHls ZT0iZm9udC12YXJpYW50LWxpZ2F0dXJlczpub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFs O3RleHQtYWxpZ246c3RhcnQ7dGV4dC1pbmRlbnQ6LjBweDt3aWRvd3M6MjtiYWNrZ3JvdW5kLWNv bG9yOiNmZmZmZmY7dGV4dC1kZWNvcmF0aW9uLXN0eWxlOmluaXRpYWw7dGV4dC1kZWNvcmF0aW9u LWNvbG9yOmluaXRpYWw7Y2xlYXI6Ym90aDsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6IDE0cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IDQwMDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IGZvbnQtZmFtaWx5OiBhcmlhbDsiIGNsYXNzPSIiPjwvc3Bhbj48L2Rpdj4N CiAgICAgICAgICA8ZGl2IHN0eWxlPSJmb250LXZhcmlhbnQtbGlnYXR1cmVzOm5vcm1hbDtmb250 LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDouMHB4O3dp ZG93czoyO2JhY2tncm91bmQtY29sb3I6I2ZmZmZmZjt0ZXh0LWRlY29yYXRpb24tc3R5bGU6aW5p dGlhbDt0ZXh0LWRlY29yYXRpb24tY29sb3I6aW5pdGlhbDtjbGVhcjpib3RoOyIgY2xhc3M9IiI+ DQogICAgICAgICAgICA8cHJlIGNsYXNzPSJ3b3Jkd3JhcCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjIw LjdweDtmb250LXZhcmlhbnQtbGlnYXR1cmVzOm5vcm1hbDtmb250LXZhcmlhbnQtY2Fwczpub3Jt YWw7dGV4dC1hbGlnbjpsZWZ0O3RleHQtaW5kZW50Oi4wcHg7d2lkb3dzOjI7dGV4dC1kZWNvcmF0 aW9uLXN0eWxlOmluaXRpYWw7dGV4dC1kZWNvcmF0aW9uLWNvbG9yOmluaXRpYWw7Ym94LXNpemlu Zzpib3JkZXItYm94O21hcmdpbi10b3A6LjBweDttYXJnaW4tYm90dG9tOjEuMHJlbTtvdmVyZmxv dzphdXRvO2Rpc3BsYXk6YmxvY2s7b3ZlcmZsb3ctd3JhcDpub3JtYWw7d29yZC1icmVhazpub3Jt YWw7cGFkZGluZzouMHB4OyI+PHNwYW4gc3R5bGU9ImNvbG9yOiMyMTI1Mjk7Zm9udC1zdHlsZTpu b3JtYWw7Zm9udC13ZWlnaHQ6NDAwO3RleHQtdHJhbnNmb3JtOm5vbmU7Zm9udC1mYW1pbHk6YXJp YWw7Zm9udC1zaXplOjE0LjBweDsiIGNsYXNzPSIiPiZndDsgU2luY2UgdGhlIElTTyBkb2N1bWVu dHMgYXJlIG5vdCBhdmFpbGFibGUgdG8gdGhlIGdlbmVyYWwgDQomZ3Q7IHB1YmxpYyB3aXRob3V0 IHBheW1lbnQsIGl0IHdvdWxkIGJlIGhlbHBmdWwgdG8gaGF2ZSBhIGZyZWVseSBhdmFpbGFibGUg DQomZ3Q7IGRvY3VtZW50IChpbiBFbmdsaXNoKSBmcm9tIGFuIGF1dGhvcml0YXRpdmUgc291cmNl LiBIYXZpbmcgc3VjaCBhIA0KJmd0OyByZWZlcmVuY2UgYXZhaWxhYmxlIHdvdWxkIGJlIGhlbHBm dWwgdG8gdGhlIElFVEYgY29tbXVuaXR5IChhbmQgDQomZ3Q7IHJlc2VhcmNoZXJzKS48L3NwYW4+ PC9wcmU+DQogICAgICAgICAgPC9kaXY+DQogICAgICAgICAgPGRpdiBzdHlsZT0iZm9udC12YXJp YW50LWxpZ2F0dXJlczpub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246 c3RhcnQ7dGV4dC1pbmRlbnQ6LjBweDt3aWRvd3M6MjtiYWNrZ3JvdW5kLWNvbG9yOiNmZmZmZmY7 dGV4dC1kZWNvcmF0aW9uLXN0eWxlOmluaXRpYWw7dGV4dC1kZWNvcmF0aW9uLWNvbG9yOmluaXRp YWw7Y2xlYXI6Ym90aDsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXN0eWxlOiBub3JtYWw7 IGZvbnQtd2VpZ2h0OiA0MDA7IHRleHQtdHJhbnNmb3JtOiBub25lOyBmb250LXNpemU6IDE0cHg7 IGZvbnQtZmFtaWx5OiBhcmlhbDsiIGNsYXNzPSIiPkFib3V0DQogICAgICAgICAgICAgIHRoZSBy ZWZlcmVuY2VzIHRvIElTTyBkb2N1bWVucywgSSB0aGluayBpdCBpcyBhIGdlbmVyYWwNCiAgICAg ICAgICAgICAgaXNzdWUgZm9yIElFVEYgZHJhZnRzLjwvc3Bhbj48L2Rpdj4NCiAgICAgICAgPC9k aXY+DQogICAgICAgIDxkaXYgc3R5bGU9ImNsZWFyOmJvdGg7IiBjbGFzcz0iIj4NCiAgICAgICAg ICA8ZGl2IHN0eWxlPSJmb250LXZhcmlhbnQtbGlnYXR1cmVzOm5vcm1hbDtmb250LXZhcmlhbnQt Y2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDouMHB4O3dpZG93czoyO2Jh Y2tncm91bmQtY29sb3I6I2ZmZmZmZjt0ZXh0LWRlY29yYXRpb24tc3R5bGU6aW5pdGlhbDt0ZXh0 LWRlY29yYXRpb24tY29sb3I6aW5pdGlhbDtjbGVhcjpib3RoOyIgY2xhc3M9IiI+PHNwYW4gc3R5 bGU9ImZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IDQwMDsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1mYW1pbHk6IGFyaWFsOyIgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KICAgICAgICAgICAgPC9zcGFuPjwvZGl2Pg0KICAgICAgICA8L2Rpdj4NCiAg ICAgICAgPGRpdiBzdHlsZT0iY2xlYXI6Ym90aDsiIGNsYXNzPSIiPg0KICAgICAgICAgIDxkaXYg c3R5bGU9ImZvbnQtdmFyaWFudC1saWdhdHVyZXM6bm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBzOm5v cm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50Oi4wcHg7d2lkb3dzOjI7YmFja2dyb3Vu ZC1jb2xvcjojZmZmZmZmO3RleHQtZGVjb3JhdGlvbi1zdHlsZTppbml0aWFsO3RleHQtZGVjb3Jh dGlvbi1jb2xvcjppbml0aWFsO2NsZWFyOmJvdGg7IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9u dC1zdHlsZTogbm9ybWFsOyBmb250LXdlaWdodDogNDAwOyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsg Zm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogYXJpYWw7IiBjbGFzcz0iIj48L3NwYW4+PC9k aXY+DQogICAgICAgICAgPGRpdiBzdHlsZT0iZm9udC12YXJpYW50LWxpZ2F0dXJlczpub3JtYWw7 Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4dC1pbmRlbnQ6LjBw eDt3aWRvd3M6MjtiYWNrZ3JvdW5kLWNvbG9yOiNmZmZmZmY7dGV4dC1kZWNvcmF0aW9uLXN0eWxl OmluaXRpYWw7dGV4dC1kZWNvcmF0aW9uLWNvbG9yOmluaXRpYWw7Y2xlYXI6Ym90aDsiIGNsYXNz PSIiPjxzcGFuIHN0eWxlPSJmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiA0MDA7IHRl eHQtdHJhbnNmb3JtOiBub25lOyBmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5OiBhcmlhbDsi IGNsYXNzPSIiPkhvdw0KICAgICAgICAgICAgICBkb2VzIHRoZSBvdGhlciBJRVRGIGRyYWZ0cyBt YWtlIHRoZSByZWZlcmVuY2VzIHRvIElTTw0KICAgICAgICAgICAgICBkb2N1bWVudHM/IElTTyBk b2N1bWVudHMgYXJlIG9mdGVuIHJlZmVyZW5jZWQgYnkgSUVURg0KICAgICAgICAgICAgICBkcmFm dHMuPC9zcGFuPjwvZGl2Pg0KICAgICAgICAgIDxkaXYgc3R5bGU9ImZvbnQtdmFyaWFudC1saWdh dHVyZXM6bm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3Rl eHQtaW5kZW50Oi4wcHg7d2lkb3dzOjI7YmFja2dyb3VuZC1jb2xvcjojZmZmZmZmO3RleHQtZGVj b3JhdGlvbi1zdHlsZTppbml0aWFsO3RleHQtZGVjb3JhdGlvbi1jb2xvcjppbml0aWFsO2NsZWFy OmJvdGg7IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXdl aWdodDogNDAwOyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgZm9udC1zaXplOiAxNHB4OyBmb250LWZh bWlseTogYXJpYWw7IiBjbGFzcz0iIj48L3NwYW4+PC9kaXY+DQogICAgICAgIDwvZGl2Pg0KICAg ICAgICA8ZGl2IHN0eWxlPSJjbGVhcjpib3RoOyIgY2xhc3M9IiI+DQogICAgICAgICAgPGRpdiBz dHlsZT0iZm9udC12YXJpYW50LWxpZ2F0dXJlczpub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6bm9y bWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4dC1pbmRlbnQ6LjBweDt3aWRvd3M6MjtiYWNrZ3JvdW5k LWNvbG9yOiNmZmZmZmY7dGV4dC1kZWNvcmF0aW9uLXN0eWxlOmluaXRpYWw7dGV4dC1kZWNvcmF0 aW9uLWNvbG9yOmluaXRpYWw7Y2xlYXI6Ym90aDsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250 LXN0eWxlOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiA0MDA7IHRleHQtdHJhbnNmb3JtOiBub25lOyBm b250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5OiBhcmlhbDsiIGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCiAgICAgICAgICAgIDwvc3Bhbj48L2Rpdj4NCiAgICAgICAgPC9kaXY+DQogICAgICAgIDxk aXYgc3R5bGU9ImNsZWFyOmJvdGg7IiBjbGFzcz0iIj4NCiAgICAgICAgICA8ZGl2IHN0eWxlPSJm b250LXZhcmlhbnQtbGlnYXR1cmVzOm5vcm1hbDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4 dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDouMHB4O3dpZG93czoyO2JhY2tncm91bmQtY29sb3I6 I2ZmZmZmZjt0ZXh0LWRlY29yYXRpb24tc3R5bGU6aW5pdGlhbDt0ZXh0LWRlY29yYXRpb24tY29s b3I6aW5pdGlhbDtjbGVhcjpib3RoOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc3R5bGU6 IG5vcm1hbDsgZm9udC13ZWlnaHQ6IDQwMDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IGZvbnQtc2l6 ZTogMTRweDsgZm9udC1mYW1pbHk6IGFyaWFsOyIgY2xhc3M9IiI+VGhhbmtzLDwvc3Bhbj48L2Rp dj4NCiAgICAgICAgPC9kaXY+DQogICAgICAgIDxkaXYgc3R5bGU9ImNsZWFyOmJvdGg7IiBjbGFz cz0iIj4NCiAgICAgICAgICA8ZGl2IHN0eWxlPSJmb250LXZhcmlhbnQtbGlnYXR1cmVzOm5vcm1h bDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDou MHB4O3dpZG93czoyO2JhY2tncm91bmQtY29sb3I6I2ZmZmZmZjt0ZXh0LWRlY29yYXRpb24tc3R5 bGU6aW5pdGlhbDt0ZXh0LWRlY29yYXRpb24tY29sb3I6aW5pdGlhbDtjbGVhcjpib3RoOyIgY2xh c3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IDQwMDsg dGV4dC10cmFuc2Zvcm06IG5vbmU7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1mYW1pbHk6IGFyaWFs OyIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KICAgICAgICAgICAgPC9zcGFuPjwvZGl2Pg0KICAg ICAgICA8L2Rpdj4NCiAgICAgICAgPGRpdiBzdHlsZT0iY2xlYXI6Ym90aDsiIGNsYXNzPSIiPg0K ICAgICAgICAgIDxkaXYgc3R5bGU9ImZvbnQtdmFyaWFudC1saWdhdHVyZXM6bm9ybWFsO2ZvbnQt dmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50Oi4wcHg7d2lk b3dzOjI7YmFja2dyb3VuZC1jb2xvcjojZmZmZmZmO3RleHQtZGVjb3JhdGlvbi1zdHlsZTppbml0 aWFsO3RleHQtZGVjb3JhdGlvbi1jb2xvcjppbml0aWFsO2NsZWFyOmJvdGg7IiBjbGFzcz0iIj48 c3BhbiBzdHlsZT0iZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXdlaWdodDogNDAwOyB0ZXh0LXRy YW5zZm9ybTogbm9uZTsgZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogYXJpYWw7IiBjbGFz cz0iIj48L3NwYW4+PC9kaXY+DQogICAgICAgICAgPGRpdiBzdHlsZT0iZm9udC12YXJpYW50LWxp Z2F0dXJlczpub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7 dGV4dC1pbmRlbnQ6LjBweDt3aWRvd3M6MjtiYWNrZ3JvdW5kLWNvbG9yOiNmZmZmZmY7dGV4dC1k ZWNvcmF0aW9uLXN0eWxlOmluaXRpYWw7dGV4dC1kZWNvcmF0aW9uLWNvbG9yOmluaXRpYWw7Y2xl YXI6Ym90aDsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt d2VpZ2h0OiA0MDA7IHRleHQtdHJhbnNmb3JtOiBub25lOyBmb250LXNpemU6IDE0cHg7IGZvbnQt ZmFtaWx5OiBhcmlhbDsiIGNsYXNzPSIiPktpbmQNCiAgICAgICAgICAgICAgUmVnYXJkczwvc3Bh bj48L2Rpdj4NCiAgICAgICAgICA8ZGl2IHN0eWxlPSJmb250LXZhcmlhbnQtbGlnYXR1cmVzOm5v cm1hbDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVu dDouMHB4O3dpZG93czoyO2JhY2tncm91bmQtY29sb3I6I2ZmZmZmZjt0ZXh0LWRlY29yYXRpb24t c3R5bGU6aW5pdGlhbDt0ZXh0LWRlY29yYXRpb24tY29sb3I6aW5pdGlhbDtjbGVhcjpib3RoOyIg Y2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IDQw MDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1mYW1pbHk6IGFy aWFsOyIgY2xhc3M9IiI+S2VwZW5nPC9zcGFuPjwvZGl2Pg0KICAgICAgICAgIDxkaXYgc3R5bGU9 ImZvbnQtdmFyaWFudC1saWdhdHVyZXM6bm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0 ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50Oi4wcHg7d2lkb3dzOjI7YmFja2dyb3VuZC1jb2xv cjojZmZmZmZmO3RleHQtZGVjb3JhdGlvbi1zdHlsZTppbml0aWFsO3RleHQtZGVjb3JhdGlvbi1j b2xvcjppbml0aWFsO2NsZWFyOmJvdGg7IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1zdHls ZTogbm9ybWFsOyBmb250LXdlaWdodDogNDAwOyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgZm9udC1m YW1pbHk6IFRhaG9tYSwgQXJpYWwsIFNUSGVpdGksIFNpbVN1bjsgZm9udC1zaXplOiAxNHB4OyIg Y2xhc3M9IiI+4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU 4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU 4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU 4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCUPC9zcGFuPjwvZGl2Pg0KICAgICAg ICAgIDxkaXYgc3R5bGU9ImZvbnQtdmFyaWFudC1saWdhdHVyZXM6bm9ybWFsO2ZvbnQtdmFyaWFu dC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50Oi4wcHg7d2lkb3dzOjI7 YmFja2dyb3VuZC1jb2xvcjojZmZmZmZmO3RleHQtZGVjb3JhdGlvbi1zdHlsZTppbml0aWFsO3Rl eHQtZGVjb3JhdGlvbi1jb2xvcjppbml0aWFsO2NsZWFyOmJvdGg7IiBjbGFzcz0iIj4NCiAgICAg ICAgICAgIDxoMyBzdHlsZT0ibWFyZ2luOjIuMHB4DQouLi4wcHg7Ym94LXNpemluZzpib3JkZXIt Ym94O2xpbmUtaGVpZ2h0OjEuMjtmb250LXZhcmlhbnQtbGlnYXR1cmVzOm5vcm1hbDtmb250LXZh cmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGlnbjpsZWZ0O3RleHQtaW5kZW50Oi4wcHg7d2lkb3dz OjI7YmFja2dyb3VuZC1jb2xvcjojZmZmZmZmO3RleHQtZGVjb3JhdGlvbi1zdHlsZTppbml0aWFs O3RleHQtZGVjb3JhdGlvbi1jb2xvcjppbml0aWFsOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5Omx1Y2lkYQ0KR3JhbmRlLFZlcmRhbmE7Zm9udC1zaXplOjE4LjBweDtmb250LXdl aWdodDpub3JtYWw7Y29sb3I6IzIxMjUyOTtmb250LXN0eWxlOm5vcm1hbDt0ZXh0LXRyYW5zZm9y bTpub25lOyIgY2xhc3M9IiI+UmU6DQogICAgICAgICAgICAgICAgW1RMU10gRHJhZnQgZm9yIFNN IGNpcGhlciBzdWl0ZXMgdXNlZCBpbiBUTFMxLjM8L3NwYW4+PC9oMz48cCBjbGFzcz0ibXNnLWhl YWRlciIgaWQ9Im1zZy1pbmZvIiBzdHlsZT0ibGluZS1oZWlnaHQ6MjMuOHB4O2JveC1zaXppbmc6 Ym9yZGVyLWJveDttYXJnaW46LjBweA0KICAgICAgICAgICAgICAuMHB4DQoyMC4wcHg7Zm9udC12 YXJpYW50LWxpZ2F0dXJlczpub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxp Z246bGVmdDt0ZXh0LWluZGVudDouMHB4O3dpZG93czoyO2JhY2tncm91bmQtY29sb3I6I2ZmZmZm Zjt0ZXh0LWRlY29yYXRpb24tc3R5bGU6aW5pdGlhbDt0ZXh0LWRlY29yYXRpb24tY29sb3I6aW5p dGlhbDsiPjxzcGFuIGNsYXNzPSJwaXBlIiBpZD0ibXNnLWZyb20iIHN0eWxlPSJmb250LWZhbWls eTpsdWNpZGENCkdyYW5kZSxWZXJkYW5hO2NvbG9yOiM4MDgwODA7Zm9udC1zaXplOjE0LjBweDtm b250LXN0eWxlOm5vcm1hbDtmb250LXdlaWdodDo0MDA7dGV4dC10cmFuc2Zvcm06bm9uZTtib3gt c2l6aW5nOmJvcmRlci1ib3g7Ij5SZW5lDQogICAgICAgICAgICAgICAgU3RydWlrICZsdDs8YSBo cmVmPSJtYWlsdG86cnN0cnVpay5leHRAZ21haWwuY29tIiByZWw9Im5vb3BlbmVyIiB0YXJnZXQ9 Il9ibGFuayIgc3R5bGU9Im91dGxpbmU6bm9uZTt0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO2Nv bG9yOiMxZTU0OTQ7IiBtb3otZG8tbm90LXNlbmQ9InRydWUiIGNsYXNzPSIiPnJzdHJ1aWsuZXh0 QDx3YnIgY2xhc3M9IiI+Z21haWwuY29tPC9hPiZndDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5Omx1Y2lkYQ0KR3JhbmRlLFZlcmRhbmE7Y29sb3I6IzgwODA4MDtmb250LXNpemU6MTQu MHB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtd2VpZ2h0OjQwMDt0ZXh0LXRyYW5zZm9ybTpub25l OyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGNsYXNzPSJwaXBlIiBpZD0ibXNnLWRhdGUi IHN0eWxlPSJmb250LWZhbWlseTpsdWNpZGENCkdyYW5kZSxWZXJkYW5hO2NvbG9yOiM4MDgwODA7 Zm9udC1zaXplOjE0LjBweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXdlaWdodDo0MDA7dGV4dC10 cmFuc2Zvcm06bm9uZTtib3gtc2l6aW5nOmJvcmRlci1ib3g7Ij5UaHUsDQogICAgICAgICAgICAg ICAgMTUgQXVndXN0IDIwMTkgMTU6MzQgVVRDPC9zcGFuPjxhIGNsYXNzPSJ0b2dnbGUiIGhyZWY9 Imh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9icm93c2UvdGxzLz9pbmRleD1OSGJI T0d0c1IxUzVjQ3I5bldOOV9zZHlUZ2cmYW1wO2didD0xIyIgaWQ9InRvZ2dsZS1tc2ctaGVhZGVy IiByZWw9Im5vb3BlbmVyIiB0YXJnZXQ9Il9ibGFuayIgc3R5bGU9ImZvbnQtZmFtaWx5Omx1Y2lk YQ0KR3JhbmRlLFZlcmRhbmE7Zm9udC1zaXplOjE0LjBweDtmb250LXN0eWxlOm5vcm1hbDtmb250 LXdlaWdodDo0MDA7dGV4dC10cmFuc2Zvcm06bm9uZTtvdXRsaW5lOm5vbmU7dGV4dC1kZWNvcmF0 aW9uOm5vbmU7Y29sb3I6IzMzN2FiNztib3gtc2l6aW5nOmJvcmRlci1ib3g7YmFja2dyb3VuZC1j b2xvcjp0cmFuc3BhcmVudDsiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+U2hvdyBoZWFkZXI8L2E+ PC9wPg0KICAgICAgICAgICAgPGRpdiBjbGFzcz0ibXNnLXBheWxvYWQiIHN0eWxlPSJib3gtc2l6 aW5nOmJvcmRlci1ib3g7Zm9udC12YXJpYW50LWxpZ2F0dXJlczpub3JtYWw7Zm9udC12YXJpYW50 LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246bGVmdDt0ZXh0LWluZGVudDouMHB4O3dpZG93czoyO2Jh Y2tncm91bmQtY29sb3I6I2ZmZmZmZjt0ZXh0LWRlY29yYXRpb24tc3R5bGU6aW5pdGlhbDt0ZXh0 LWRlY29yYXRpb24tY29sb3I6aW5pdGlhbDsiPg0KICAgICAgICAgICAgICA8cHJlIGNsYXNzPSJ3 b3Jkd3JhcCIgc3R5bGU9ImZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtd2VpZ2h0OjQwMDt0ZXh0LXRy YW5zZm9ybTpub25lO2xpbmUtaGVpZ2h0OjIwLjdweDtib3gtc2l6aW5nOmJvcmRlci1ib3g7Zm9u dC1mYW1pbHk6U0ZNb25vLVJlZ3VsYXIsTWVubG8sTW9uYWNvLENvbnNvbGFzLExpYmVyYXRpb24g TW9ubyxDb3VyaWVyIE5ldyxtb25vc3BhY2U7Zm9udC1zaXplOjEyLjJweDttYXJnaW4tdG9wOi4w cHg7bWFyZ2luLWJvdHRvbToxLjByZW07b3ZlcmZsb3c6YXV0bztkaXNwbGF5OmJsb2NrO2NvbG9y OiMyMTI1Mjk7b3ZlcmZsb3ctd3JhcDpub3JtYWw7d29yZC1icmVhazpub3JtYWw7cGFkZGluZzou MHB4OyI+SGkgUGF1bDoNCg0KSSB0cmllZCBhbmQgbG9vayB1cCB0aGUgZG9jdW1lbnRzIEdNVC4w MDA5LTIwMTIgYW5kIEdCVC4zMjkxOC41LTIwMTYgb24gDQp0aGUgKG5vbi1zZWN1cmVkKSB3ZWJz aXRlcyB5b3UgcmVmZXJlbmNlZCwgYnV0IG9ubHkgZm91bmQgQ2hpbmVzZSANCnZlcnNpb25zIChh bmQgQ2hpbmVzZSB3ZWJzaXRlIG5hdmlnYXRpb24gcGFuZWxzIFtwYXJkb24gbXkgcG9vciBsYW5n dWFnZSANCnNraWxscyBoZXJlXSkuIFNpbmNlIHRoZSBJU08gZG9jdW1lbnRzIGFyZSBub3QgYXZh aWxhYmxlIHRvIHRoZSBnZW5lcmFsIA0KcHVibGljIHdpdGhvdXQgcGF5bWVudCwgaXQgd291bGQg YmUgaGVscGZ1bCB0byBoYXZlIGEgZnJlZWx5IGF2YWlsYWJsZSANCmRvY3VtZW50IChpbiBFbmds aXNoKSBmcm9tIGFuIGF1dGhvcml0YXRpdmUgc291cmNlLiBIYXZpbmcgc3VjaCBhIA0KcmVmZXJl bmNlIGF2YWlsYWJsZSB3b3VsZCBiZSBoZWxwZnVsIHRvIHRoZSBJRVRGIGNvbW11bml0eSAoYW5k IA0KcmVzZWFyY2hlcnMpLiBQbGVhc2Ugbm90ZSB0aGF0IEJTSSBwcm92aWRlcyBpdHMgc3BlY2lm aWNhdGlvbnMgaW4gR2VybWFuIA0KYW5kIEVuZ2xpc2gsIHNvIGFzIHRvIGZvc3RlciB1c2Uvc3R1 ZHkgYnkgdGhlIGNvbW11bml0eS4gSWYgdGhlIENoaW5lc2UgDQpuYXRpb25hbCBhbGdvcml0aG1z IHdvdWxkIGJlIGF2YWlsYWJsZSBpbiBzaW1pbGFyIGZvcm0sIHRoaXMgd291bGQgc2VydmUgDQph IHNpbWlsYXIgcHVycG9zZS4NCg0KRllJIC0gSSBhbSBpbnRlcmVzdGVkIGluIGZ1bGwgZGV0YWls cyBhbmQgc29tZSB0aW1lIGxhc3QgeWVhciBJIHRyaWVkIHRvIA0KZG93bmxvYWQgc3BlY3MsIGJ1 dCBvbmx5IFBhcnRzIDIsIDQsIGFuZCA1IHdlcmUgYXZhaWxhYmxlIFsxXSwgWzJdLCBbM10sIA0K bm90IFBhcnRzIDEgYW5kIDMuDQoNCkJlc3QgcmVnYXJkcywgUmVuZQ0KDQpbMV0gQ2hpbmEgRUND IC0gUHVibGljIEtleSBDcnlwdG9ncmFwaGljIEFsZ29yaXRobSBTTTIgQmFzZWQgb24gRUNDIC0g DQpQYXJ0IDUgLSBQYXJhbWV0ZXIgRGVmaW5pdGlvbiAoU0VNQiwgSnVseSAyNCwgMjAxOCkNClsy XSBDaGluYSBFQ0MgLSBQdWJsaWMgS2V5IENyeXB0b2dyYXBoaWMgQWxnb3JpdGhtIFNNMiBCYXNl ZCBvbiBFQ0MgLSANClBhcnQgMiAtIERpZ2l0YWwgU2lnbmF0dXJlIEFsZ29yaXRobSAoU0VNQiwg SnVseSAyNCwgMjAxOCkNClszXSBDaGluYSBFQ0MgLSBQdWJsaWMgS2V5IENyeXB0b2dyYXBoaWMg QWxnb3JpdGhtIFNNMiBCYXNlZCBvbiBFQ0MgLSANClBhcnQgNCAtIFB1YmxpYyBLZXkgRW5jcnlw dGlvbiBBbGdvcml0aG0gKFNFTUIsIEp1bHkgMjQsIDIwMTgpDQoNCk9uIDgvMTUvMjAxOSAxMDox NiBBTSwgUGF1bCBZYW5nIHdyb3RlOg0KJmd0OyBIaSBhbGwsDQomZ3Q7DQomZ3Q7IEkgaGF2ZSBz dWJtaXR0ZWQgYSBuZXcgaW50ZXJuZXQgZHJhZnQgdG8gaW50cm9kdWNlIHRoZSBTTSBjaXBoZXIg DQomZ3Q7IHN1aXRlcyBpbnRvIFRMUyAxLjMgcHJvdG9jb2wuDQomZ3Q7DQomZ3Q7IDxhIGhyZWY9 Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC15YW5nLXRscy10bHMxMy1zbS1zdWl0 ZXMtMDAiIHJlbD0ibm9vcGVuZXIiIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0ib3V0bGluZTpub25l O3RleHQtZGVjb3JhdGlvbjpub25lO2NvbG9yOiMzMzdhYjc7Ym94LXNpemluZzpib3JkZXItYm94 O2JhY2tncm91bmQtY29sb3I6dHJhbnNwYXJlbnQ7IiBtb3otZG8tbm90LXNlbmQ9InRydWUiIGNs YXNzPSIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC15YW5nLXRscy10bHMxMy1z bS1zdWl0ZXMtMDA8L2E+DQomZ3Q7DQomZ3Q7IFNNIGNyeXB0b2dyYXBoaWMgYWxnb3JpdGhtcyBh cmUgb3JpZ2luYWxseSBhIHNldCBvZiBDaGluZXNlIG5hdGlvbmFsIA0KJmd0OyBhbGdvcml0aG1z IGFuZCBub3cgaGF2ZSBiZWVuIChvciBiZWluZykgYWNjZXB0ZWQgYnkgSVNPIGFzIA0KJmd0OyBp bnRlcm5hdGlvbmFsIHN0YW5kYXJkcywgaW5jbHVkaW5nIFNNMiBzaWduYXR1cmUgYWxnb3JpdGht LCBTTTMgaGFzaCANCiZndDsgZnVuY3Rpb24gYW5kIFNNNCBibG9jayBjaXBoZXIuIFRoZXNlIGFs Z29yaXRobXMgaGF2ZSBhbHJlYWR5IGJlZW4gDQomZ3Q7IHN1cHBvcnRlZCBzb21lIHRpbWUgYWdv IGJ5IHNldmVyYWwgd2lkZWx5IHVzZWQgb3BlbiBzb3VyY2UgDQomZ3Q7IGNyeXB0b2dyYXBoaWMg bGlicmFyaWVzIGluY2x1ZGluZyBPcGVuU1NMLCBCb3VuY3lDYXN0bGUsIEJvdGFuLCBldGMuDQom Z3Q7DQomZ3Q7IENvbnNpZGVyaW5nIFRMUzEuMyBpcyBiZWluZyBncmFkdWFsbHkgYWRvcHRlZCBp biBDaGluYSdzIGludGVybmV0IA0KJmd0OyBpbmR1c3RyeSwgaXQncyBpbXBvcnRhbnQgdG8gaGF2 ZSBhIG5vcm1hdGl2ZSBkZWZpbml0aW9uIG9uIGhvdyB0byB1c2UgDQomZ3Q7IHRoZSBTTSBhbGdv cml0aG1zIHdpdGggVExTMS4zLCBlc3BlY2lhbGx5IGZvciB0aGUgbW9iaWxlIGludGVybmV0IA0K Jmd0OyBzY2VuYXJpby4gQW50IEZpbmFuY2lhbCBpcyB0aGUgY29tcGFueSB3aG8gZGV2ZWxvcHMg dGhlIG1hcmtldCBsZWFkaW5nIA0KJmd0OyBtb2JpbGUgYXBwICdBbGlwYXknIGFuZCBzdXBwb3J0 cyBwYXltZW50IHNlcnZpY2VzIGZvciBBbGliYWJhIA0KJmd0OyBlLWNvbW1lcmNlIGJ1c2luZXNz LiBXZSBoaWdobHkgYXJlIGRlcGVuZGluZyBvbiB0aGUgbmV3IFRMUzEuMyANCiZndDsgcHJvdG9j b2wgZm9yIGJvdGggcGVyZm9ybWFuY2UgYW5kIHNlY3VyaXR5IHB1cnBvc2VzLiBXZSBleHBlY3Qg dG8gaGF2ZSANCiZndDsgbW9yZSBkZXBsb3ltZW50IG9mIFRMUzEuMyBjYXBhYmxlIGFwcGxpY2F0 aW9ucyBpbiBDaGluYSdzIGludGVybmV0IA0KJmd0OyBpbmR1c3RyeSBieSB0aGlzIHN0YW5kYXJk aXphdGlvbiBhdHRlbXB0cy4NCiZndDsNCiZndDsgSXQncyB2ZXJ5IGFwcHJlY2lhdGVkIHRvIGhh dmUgY29tbWVudHMgZnJvbSB0aGUgSUVURiBUTFMgbGlzdCA6LSkNCiZndDsNCiZndDsgTWFueSB0 aGFua3MhDQomZ3Q7DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQomZ3Q7IFRMUyBtYWlsaW5nIGxpc3QNCiZndDsgPGEgaHJlZj0ibWFpbHRvOlRM U0BpZXRmLm9yZyIgcmVsPSJub29wZW5lciIgdGFyZ2V0PSJfYmxhbmsiIHN0eWxlPSJvdXRsaW5l Om5vbmU7dGV4dC1kZWNvcmF0aW9uOm5vbmU7Y29sb3I6IzMzN2FiNztib3gtc2l6aW5nOmJvcmRl ci1ib3g7YmFja2dyb3VuZC1jb2xvcjp0cmFuc3BhcmVudDsiIG1vei1kby1ub3Qtc2VuZD0idHJ1 ZSIgY2xhc3M9IiI+VExTQGlldGYub3JnPC9hPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RscyIgcmVsPSJub29wZW5lciIgdGFyZ2V0PSJfYmxh bmsiIHN0eWxlPSJvdXRsaW5lOm5vbmU7dGV4dC1kZWNvcmF0aW9uOm5vbmU7Y29sb3I6IzMzN2Fi Nztib3gtc2l6aW5nOmJvcmRlci1ib3g7YmFja2dyb3VuZC1jb2xvcjp0cmFuc3BhcmVudDsiIG1v ei1kby1ub3Qtc2VuZD0idHJ1ZSIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby90bHM8L2E+PC9wcmU+DQogICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICA8 L2Rpdj4NCiAgICAgICAgICA8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IFRhaG9tYSwgQXJpYWws IFNUSGVpdGksIFNpbVN1bjsgZm9udC1zaXplOiAxNHB4OyIgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KICAgICAgICAgIDwvc3Bhbj48L2Rpdj4NCiAgICAgIDwvZGl2Pg0KICAgIDwvYmxvY2txdW90 ZT48cCBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQogICAgPC9wPg0KICAgIDxwcmUgY2xhc3M9Im1v ei1zaWduYXR1cmUiIGNvbHM9IjcyIj4tLSANCmVtYWlsOiA8YSBjbGFzcz0ibW96LXR4dC1saW5r LWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86cnN0cnVpay5leHRAZ21haWwuY29tIj5yc3RydWlr LmV4dEBnbWFpbC5jb208L2E+IHwgU2t5cGU6IHJzdHJ1aWsNCmNlbGw6ICsxICg2NDcpIDg2Ny01 NjU4IHwgVVM6ICsxICg0MTUpIDY5MC03MzYzPC9wcmU+DQogIDwvZGl2Pg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj5UTFMgbWFp bGluZyBsaXN0PGJyIGNsYXNzPSIiPjxhIGhyZWY9Im1haWx0bzpUTFNAaWV0Zi5vcmciIGNsYXNz PSIiPlRMU0BpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vdGxzPC9hPjxiciBjbGFzcz0iIj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9kaXY+PGJy IGNsYXNzPSIiPjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAs IDAsIDApOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250 LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1h bDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczog YXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3Jt OiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzog MHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyI+PGJyIGNsYXNzPSJBcHBsZS1pbnRl cmNoYW5nZS1uZXdsaW5lIj5SZWdhcmRzLDwvZGl2PjxkaXYgc3R5bGU9ImNhcmV0LWNvbG9yOiBy Z2IoMCwgMCwgMCk7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7 IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczog bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBo YW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFj aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7Ij48YnIgY2xhc3M9IiI+PC9k aXY+PGRpdiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgY29sb3I6IHJnYigwLCAw LCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxl OiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7 IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0 OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v cm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUt YWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3Jh dGlvbjogbm9uZTsiPlBhdWwgWWFuZzwvZGl2Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+PC9kaXY+ PC9kaXY+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXYgZGlyPSJsdHIi PjxzcGFuPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9z cGFuPjxicj48c3Bhbj5UTFMgbWFpbGluZyBsaXN0PC9zcGFuPjxicj48c3Bhbj48YSBocmVmPSJt YWlsdG86VExTQGlldGYub3JnIj5UTFNAaWV0Zi5vcmc8L2E+PC9zcGFuPjxicj48c3Bhbj48YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RscyI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHM8L2E+PC9zcGFuPjxicj48L2Rpdj48L2Js b2NrcXVvdGU+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --Apple-Mail-4658E7C9-9165-48A6-8B57-A84F33C561FC-- --Apple-Mail-24DACA0A-ED0E-4961-9AC4-EC558C1C96A7 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCE6Iw ggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEBBQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZN SVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3Qg Q0EwHhcNMTMxMjE3MDAwMDAwWhcNMjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UE ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBD QS0zMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQ AAtoHCkvUpUEX6jFvBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDc LBFIn0nppOu9RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKag vm9zTybP6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXS GoCAmhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12BmDntJ jXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYDVR0PAQH/ BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5sbC5taXQuZWR1 L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQuZWR1L29jc3AwMwYD VR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybD9MTFJDQTCBkgYDVR0g BIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0GCyqGSIb3EgIBAwEHMA0GCyqG SIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIBAwELMA0GCyqGSIb3EgIBAwEOMA0G CyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqGSIb3DQEBBQUAA4IBAQAsf9HBn72qU7UT gkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/LTCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZ OFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZcEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAc MS77E5H62yyxK1WPPgcBipGVnu1xSHbTiHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F 4snAoqQMI98MzDYeLOkjlzKRs77r/aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvR J/g22r1MV8RR1PktjMsNOsPfMIIEvDCCA6SgAwIBAgIBKTANBgkqhkiG9w0BAQUFADBUMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYw FAYDVQQDEw1NSVRMTCBSb290IENBMB4XDTEzMTIxNzAwMDAwMFoXDTIwMTIzMTIzNTk1OVowUTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BL STETMBEGA1UEAxMKTUlUTEwgQ0EtMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANow UnVtfLbltbTcRuofAdJKnJBWUAALaBwpL1KVBF+oxbwXfJkCOdxsi2EbgKOB1iaXu/4sxVzn0iQ7 OlDOaL7wjn14NmyYA2JQQvSQ3CwRSJ9J6aTrvUb6Y1kosbQuenK8CeVLOUD3bcbSnXpOSyV5dqCs N8PJYoVIsXj28VmndZu2TCimoL5vc08mz+hbpikcXmCY0qQdvnAGI6BhhG0lR8sfLsx5usQKATB8 WvG8vsg8/Cc5OrD/YopYD94l0hqAgJocgc75UEOUDTVj/hJqPY8/7pCoWFQf1cHcbaKrjwKp+Inw wCGjPXbW9OXMtYFwBUj92f4lJMcgWWVDkX8CAwEAAaOCAZowggGWMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFNdgZg57SY11TA39z0beyMcSh8q/MB8GA1UdIwQYMBaAFGeqes/0Cqa5crWK oNKd8hDDQ+0pMA4GA1UdDwEB/wQEAwIBhjBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0 dHA6Ly9jcmwubGwubWl0LmVkdS9nZXR0bz9MTFJDQTAnBggrBgEFBQcwAYYbaHR0cDovL29jc3Au bGwubWl0LmVkdS9vY3NwMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9n ZXRjcmw/TExSQ0EwgZIGA1UdIASBijCBhzANBgsqhkiG9xICAQMBBjANBgsqhkiG9xICAQMBCDAN BgsqhkiG9xICAQMBBzANBgsqhkiG9xICAQMBCTANBgsqhkiG9xICAQMBCjANBgsqhkiG9xICAQMB CzANBgsqhkiG9xICAQMBDjANBgsqhkiG9xICAQMBDzANBgsqhkiG9xICAQMBEDANBgkqhkiG9w0B AQUFAAOCAQEALH/RwZ+9qlO1E4JMWq4wHO4sp4XAxIFsHs2CrXf0ixkkNA4bcyFfy0wsalC4znfh /h06jCVwfPpx584cqkON0bJxmThU+UX8z4feHW/2Sd6pduOA8JSSO8lwQNg5GXBBIDlgvWx3KxJc 1OjZ4oGoUluaHVSa4Zh/14UAHDEu+xOR+tsssStVjz4HAYqRlZ7tcUh204h3uw6n1kNrVTC1H9t1 2ISLmveJCbEHeI0oe9TVQ9HuxeLJwKKkDCPfDMw2HizpI5cykbO+6/2jLDwCsepzGjr0S+wstD46 edYtqhZGxpl/KH54dpHq40070Sf4Ntq9TFfEUdT5LYzLDTrD3zCCBO0wggPVoAMCAQICCjM4lI8A AAAAbpYwDQYJKoZIhvcNAQELBQAwUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xu IExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwgQ0EtMzAeFw0xNjAxMTQx NzMwMzlaFw0xOTAxMTMxNzMwMzlaMGExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29s biBMYWJvcmF0b3J5MQ8wDQYDVQQLEwZQZW9wbGUxIDAeBgNVBAMTF0JsdW1lbnRoYWwuVXJpLjUw MDEwNTg0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4xQ2hom9O5hwXTWlTDaY/fuI iWvivQHEzd8volNcoLbxxuHKLXgwX++2TdbsHbfpaHVtAvF8huN7Lkn6Taf6MCzlBJRWoAJz6hwL wFCMLJeQI853KST/u/FIuLt+GjDbHXT/kGbvRyNkIPj+njA9uY5I8m0/XUDMV2aTtqEwc55Vo2CC LXWYStQ1maiEdGre59mIwkkLGTV9JSeCcK7Yx2Ba2D552QtH9QdjO1eeCEvOtwhMn7uV6LaGcfGL h8GKSkhavNEhIenDAy3U3tWQI1sbJ28iguuK63krciNj1TfbgVnfjpXhqCAI1aIKTCiotKUkR3Ar sA8BnpKUFbmyvQIDAQABo4IBtTCCAbEwHQYDVR0OBBYEFPFPxYiZomy2ZdvinDW1VhNj2YqbMA4G A1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAWgBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFow WDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUF BzABhhtodHRwOi8vb2NzcC5sbC5taXQuZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGC NxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQUwJQYDVR0lBB4wHAYEVR0lAAYI KwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAZBgNVHREEEjAQ gQ51cmlAbGwubWl0LmVkdTAnBgkrBgEEAYI3FAIEGh4YAEwATABVAHMAZQByAEUAbgBjAC0AUwBX MA0GCSqGSIb3DQEBCwUAA4IBAQAW7r7PZtIEuVPCSblXPqrbVdgVkNIw3qV6WHz/8TfK1UnETx3t kjFGhR+TjEYYXhiZHaIFlTZzK4x8UH6X3NM/MqLZQ98cFxDVlGOTKEJqRBgdpLBaoDHddtW6s0d1 mPOC3KLH6MNDKKZV7PJrzu056M8DPj7RmbNJqadj8wZL1nTW7Nq/+8FyT+v6S3ecz78sETYU4KFX tWjeIryJFPLL5CjIIL+WWjrKJ2lvCUunVGJr75NELwyUSEDUUdM6UKTiqfuFf14TGUYcUCdw41U4 4fUP6RypuwERYRa90ACeqHAo8syxeYrLGtVbIcexJQSJNHF4XqepizC6hjV92swJMIIFLTCCBBWg AwIBAgIKGnTEIAAAAACtAzANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMW TUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0z MB4XDTE3MDMwMTE4MjUwNloXDTIwMTIzMTIzNTk1OVowbDELMAkGA1UEBhMCVVMxHzAdBgNVBAoT Fk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTErMCkGA1UEAxMiQmx1bWVu dGhhbC5VcmkuNTAwMTA1ODQgKE1vYmlsaXR5KTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAIPvGwQfo8knxsqsf3y/Wufeqk3qvXxn2FyNsiRGai8yWs81dbuqC06DJyUOqYQiJEBqZT7D PvT6cyHMOZzfBmoRz1OhV109wUq+v258uIX7RrtOcv5/w1lpT5KLOj4UjQAfFhty/umt5h3KfcmL pj5HbTNtPtPKIlPUujoRa+gaBRaHhYyhHBYb76L5vRnEc0N4NXFx6K3uaerpgQixsWYtHBoQSP+2 ciZiVFKOdGwDynaVEamErIFO6ehsQoKSHGQVJU8QkpYjzv9E6ogTGfOezBeDnHoaRuy7sbnw9Kfo NNrl+2dGiH2Jxh5ZJt2OzYLxepVtlsQj5JaimpG9n7sCAwEAAaOCAeowggHmMB0GA1UdDgQWBBT2 4hQz+9byQZkS4cbSlPwlhEq/rTAOBgNVHQ8BAf8EBAMCBsAwHwYDVR0jBBgwFoAU12BmDntJjXVM Df3PRt7IxxKHyr8wMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bC9MTENBMzBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVk dS9nZXR0by9MTENBMzAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3NwMD0G CSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYWB4ECG18ZNAgFk AgEJMCwGA1UdJQEB/wQiMCAGCCsGAQUFBwMEBgorBgEEAYI3CgMMBggrBgEFBQcDAjAYBgNVHSAE ETAPMA0GCyqGSIb3EgIBAwEIMEEGA1UdEQQ6MDiBDnVyaUBsbC5taXQuZWR1oCYGCisGAQQBgjcU AgOgGAwWVVIyMDk4MEBtaXRsbC5hZC5sb2NhbDAtBgkrBgEEAYI3FAIEIB4eAEwATABNAG8AYgBp AGwAZQBTAGkAZwBBAHUAdABoMA0GCSqGSIb3DQEBCwUAA4IBAQA24maNQ5H6oQQOC2JJQfouPZOn Yey/pwxIN1nXmfwkWQKJ/Rt4T7FFneWCLLn0aaGFFSQAXFaLPO5F2ZpBdUYx/LyzRThFfGVXDcW1 guQ4gOnU7MCBIVzEhxbsqd7REb7ts+vn/RQuI72bbWMi8oqwSQuCsD/wDi5uNhp+JS3ja2OBMfJ6 tgId8YwfkKr6cQ9pNWmqEdH1mg8b9ma3WhUeN8djE5InnvsEdXYmexgOxvx8iYPTFLpCqtt6pumL NFSUHCbClNUNv0yy/fRUUWtfKLqwbxcCc3JZS4U3Kp722sFrenGBLxiCfQ7M8c+y0BAlyNCqz6TO 8d9krpTCY7dWMYIC2TCCAtUCAQEwXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNv bG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zAgoadMQgAAAA AK0DMA0GCWCGSAFlAwQCAQUAoIIBSzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xOTA4MTgxNDA3NTNaMC8GCSqGSIb3DQEJBDEiBCCnvm80DTkRNklu9U65SGaLnlo6 +LgIwdhTqamVTYz1WDBuBgkrBgEEAYI3EAQxYTBfMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZN SVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMC CjM4lI8AAAAAbpYwcAYLKoZIhvcNAQkQAgsxYaBfMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZN SVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMC CjM4lI8AAAAAbpYwDQYJKoZIhvcNAQEBBQAEggEAGY/jQRG8tAxVosH9d5BlCat71HWlupQdgkZk GYsq9SX7NMoIzWP+WxK9bxcTLRX9UzZi3iqyD7p+cKL8nG+oW2LWjm1RmD+vuIO3AqscsvTMkMG9 qCavf78I1uEokxnrAY/gU90klUrKqOmPlbRistV7A4cjKQ/rikmYwgvykyHduVCLkONx3YvIxYJE Yvl3yXh+8A6m/ODFNEsJtxTgqJmVUy7rQmrCRF6s2SI7S00DxAOPtWM/VrKX9qHyg8cwPHELaqoG WVAcWkPn3tZyXSQRLG2OZsK2Dgzeaofo5A+CNc1U3kvgFr5HoaJpBEUM9qyRVQixt9v4lyoWTsw7 4QAAAAAAAA== --Apple-Mail-24DACA0A-ED0E-4961-9AC4-EC558C1C96A7-- From nobody Mon Aug 19 00:51:21 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8240B120072; Mon, 19 Aug 2019 00:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jyvzpkzOAFV; Mon, 19 Aug 2019 00:51:09 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A843120110; Mon, 19 Aug 2019 00:51:09 -0700 (PDT) Received: from 200116b82c4ebb005df5fa3ef969d67c.dip.versatel-1u1.de ([2001:16b8:2c4e:bb00:5df5:fa3e:f969:d67c]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hzcRU-0000iE-RO; Mon, 19 Aug 2019 09:51:04 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: Date: Mon, 19 Aug 2019 09:51:04 +0200 Cc: draft-ietf-tls-grease@ietf.org, "" , Benjamin Kaduk , tls-chairs , Sean Turner , The IESG Content-Transfer-Encoding: quoted-printable Message-Id: References: <156588205271.15865.9243229289426203471.idtracker@ietfa.amsl.com> <20190815152405.GS88236@kduck.mit.edu> <44BDC996-0E18-48BE-A700-C49A101330F8@kuehlewind.net> <6BD4AC5B-BA54-4BED-8B9B-ECA298E8BF0F@kuehlewind.net> To: David Benjamin X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1566201069;8d5c65e9; X-HE-SMSGID: 1hzcRU-0000iE-RO Archived-At: Subject: Re: [TLS] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-tls-grease-03=3A_=28with_COMMENT=29?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Aug 2019 07:51:12 -0000 Hi David, > On 16. Aug 2019, at 18:16, David Benjamin = wrote: >=20 > On Fri, Aug 16, 2019 at 3:39 AM Mirja Kuehlewind = wrote: > > >> One comment/question: I think I didn't quite understand what a = client is > > >> supposed to do if the connection fails with use of greasing = values...? The > > >> security considerations seems to indicate that you should not try = to re-connect > > >> without use of grease but rather just fail completely...? Also = should you cache > > >> the information that greasing failed maybe? > > >=20 > > > I'll let the authors chime in, but I think the sense of the = security > > > considerations is more that we are preventing the fallback from = being > > > needed "in production due to "real" negotiation failures. Falling = back on > > > GREASE failure is not as bad, provided that you follow-up with the = failing > > > peer out of band to try to get it fixed. > > > I don't know how much value there would be in caching the = grease-intolerate > > > status; ideally it would almost-never happen. > >=20 > > Okay, then I think it would be nice to say something more in the = document, about fallback at least. > >=20 > > Ben's description is right. If deploying a new TLS feature results = in too many interop failures with existing buggy servers, that feature = becomes difficult to deploy and there is a lot of pressure to apply some = sort of mitigation like a fallback. That's no good. GREASE's goal is to = avoid the interop failures to begin with. The text was not meant to = imply that you should do any sort of fallback. > >=20 > > What change did you have in mind? The current text says: > >=20 > > > Historically, when interoperability problems arise in deploying = new TLS features, implementations have used a fallback retry on error = with the feature disabled. This allows an active attacker to silently = disable the new feature. By preventing a class of such interoperability = problems, GREASE reduces the need for this kind of fallback. > >=20 > > That reads to me as describing historical fallbacks, rather than = recommending new ones. (Indeed you shouldn't do fallbacks. Fallbacks are = bad.. They break downgrade protection.) >=20 > I was thinking about adding some new text somewhere else in the = document that give a recommendation if you should fallback on grease and = when. >=20 > I mean, the answer to that is "don't" and "never", just as is = unstatedly true for any other TLS extension. TLS's downgrade protection = doesn't work if you do fallbacks. While downgrading from GREASE doesn't = matter per se, it defeats the purpose, so the usual rules for TLS apply. For me this wasn=E2=80=99t clear because this is not just a =E2=80=9Cnorma= l=E2=80=9D extension. If you want to be sure that it is clear to = everybody, you should write it down in the draft. However, that my view = and this was a just a comment to consider, so the authors (and group) = need to decide. Mirja >=20 > David From nobody Mon Aug 19 04:51:44 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87BAA12003F for ; Mon, 19 Aug 2019 04:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alibaba-inc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fr4tb13RxFW1 for ; Mon, 19 Aug 2019 04:51:38 -0700 (PDT) Received: from out0-144.mail.aliyun.com (out0-144.mail.aliyun.com [140.205.0.144]) (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 674B5120090 for ; Mon, 19 Aug 2019 04:51:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1566215493; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; bh=sPhVvGz3aiqb10Ut73CYHccY8QkR/2rfZ5PK5RhjJCo=; b=vN4VG8rAFt6CQIiqxrVBQUTiHWQfRQMzKIZ4chldRC2MvkJoy7rLj1XZ4aDDONe7+OO/2iYwzqnETJ+soMrWGi18IVAIVPOc9offps2AGR9N4I1+b3kGc8sYT+jfrnN6O9MD7jER3NHfnNTIGL+kkT6ZhJTaU6yDMlkBLQ7edhk= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R111e4; CH=green; DM=||false|; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03267; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DW; RN=7; SR=0; TI=W4_5657687_DEFAULT_0A930E4A_1566215087863_o7001c3542; Received: from WS-web (kepeng.lkp@alibaba-inc.com[W4_5657687_DEFAULT_0A930E4A_1566215087863_o7001c3542]) by e02c03278.eu6 at Mon, 19 Aug 2019 19:51:31 +0800 Date: Mon, 19 Aug 2019 19:51:31 +0800 From: "Kepeng Li" To: "sean+ietf" , "joe" , "caw" , "rstruik.ext" Cc: "tls@ietf.org" , "=?UTF-8?B?Qmx1bWVudGhhbCwgVXJpIC0gMDU1MyAtIE1JVExM?=" , "=?UTF-8?B?5p2o5rSLKOWHr+eUsyk=?=" Reply-To: "Kepeng Li" Message-ID: <20a27f61-98cf-4b2c-b6a8-e25aabd56099.kepeng.lkp@alibaba-inc.com> X-Mailer: [Alimail-Mailagent][W4_5657687][DEFAULT][Chrome] MIME-Version: 1.0 x-aliyun-mail-creator: W4_5657687_DEFAULT_M3LTW96aWxsYS81LjAgKE1hY2ludG9zaDsgSW50ZWwgTWFjIE9TIFggMTBfMTRfNSkgQXBwbGVXZWJLaXQvNTM3LjM2IChLSFRNTCwgbGlrZSBHZWNrbykgQ2hyb21lLzc2LjAuMzgwOS4xMDAgU2FmYXJpLzUzNy4zNg==vN Content-Type: multipart/alternative; boundary="----=ALIBOUNDARY_896_4a039940_5d5a8d43_19b8900" Archived-At: Subject: [TLS] =?utf-8?q?Re=EF=BC=9A_=28offline=29_Re=3A__Draft_for_SM_ci?= =?utf-8?q?pher_suites_used_in_TLS1=2E3?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Aug 2019 11:51:42 -0000 ------=ALIBOUNDARY_896_4a039940_5d5a8d43_19b8900 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Q3VycmVudGx5LCB3ZSB1cGxvYWRlZCBzb21lIG9mIHRoZSByZWZlcmVuY2VkIGRvY3VtZW50cyBo ZXJlOgpodHRwczovL2dpdGh1Yi5jb20vYWxpcGF5L3RsczEzLXNtLXNwZWMKCkBSZW5lLCBQYXJ0 cyAxIGFuZCAzIGNhbiBiZSBmb3VuZCBpbiB0aGUgbGluayBhYm92ZS4KCkhvcGUgaXQgaGVscHMu CgpUaGFua3MsCgpLaW5kIFJlZ2FyZHMKS2VwZW5nCgoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCuWPkeS7tuS6uu+8muad juWFi+m5jyjmmJPmt7EpIDxrZXBlbmcubGtwQGFudGZpbi5jb20+CuWPkemAgeaXtumXtO+8mjIw MTnlubQ45pyIMTnml6Uo5pif5pyf5LiAKSAxNzozOArmlLbku7bkurrvvJpzZWFuK2lldGYgPHNl YW4raWV0ZkBzbjNyZC5jb20+OyBqb2UgPGpvZUBzYWxvd2V5Lm5ldD47IGNhdyA8Y2F3QGhlYXBp bmdiaXRzLm5ldD4K5oqE44CA6YCB77yadGxzQGlldGYub3JnIDx0bHNAaWV0Zi5vcmc+OyAiQmx1 bWVudGhhbCwgVXJpIC0gMDU1MyAtIE1JVExMIiA8dXJpQGxsLm1pdC5lZHU+OyBQYXVsIFlhbmcg PGthaXNoZW4ueXk9NDBhbGlwYXkuY29tQGRtYXJjLmlldGYub3JnPgrkuLvjgIDpopjvvJpSZTog W1RMU10gKG9mZmxpbmUpIFJlOiBEcmFmdCBmb3IgU00gY2lwaGVyIHN1aXRlcyB1c2VkIGluIFRM UzEuMwoKCkhpIFdHIGNoYWlycywKCkNhbiB3ZSBwbGFjZSB0aGUgcmVmZXJlbmNlZCBkb2N1bWVu dHMgaW4gdGhlIFRMUyBXRyBHaXRIdWI/Cmh0dHBzOi8vZ2l0aHViLmNvbS90bHN3ZwoKQWNjb3Jk aW5nIHRvIHRoZSBkaXNjdXNzaW9uIGJlbG93LCB0aGlzIGNhbiBoZWxwIHBlb3BsZSB0byByZWFk IGFuZCB1bmRlcnN0YW5kIHRoZSByZWZlcmVuY2VkIHNwZWNpZmljYXRpb25zLgoKVGhhbmtzLAoK S2luZCBSZWdhcmRzCktlcGVuZyAKCuWPkeS7tuS6ujogVExTIDx0bHMtYm91bmNlc0BpZXRmLm9y Zz4g5Luj6KGoICJCbHVtZW50aGFsLCBVcmkgLSAwNTUzIC0gTUlUTEwiIDx1cmlAbGwubWl0LmVk dT4K5pel5pyfOiAyMDE55bm0OOaciDE45pelIOaYn+acn+aXpSAyMjowOArmlLbku7bkuro6IFBh dWwgWWFuZyA8a2Fpc2hlbi55eT00MGFsaXBheS5jb21AZG1hcmMuaWV0Zi5vcmc+CuaKhOmAgTog InRsc0BpZXRmLm9yZyIgPHRsc0BpZXRmLm9yZz4K5Li76aKYOiBSZTogW1RMU10gKG9mZmxpbmUp IFJlOiBEcmFmdCBmb3IgU00gY2lwaGVyIHN1aXRlcyB1c2VkIGluIFRMUzEuMwpJTUhPLCBwbGFj aW5nIHRoZSBkb2N1bWVudHMgb24gR2l0SHViIHdvdWxkIGJlIHBlcmZlY3QsIGFuZCBxdWl0ZSBz dWZmaWNpZW50LiAKUGxlYXNlIG1ha2Ugc3VyZSB0byBwb3N0IHRoZSBuYW1lIG9mIHRoZSByZXBv IGhlcmUuIDsvKQpJIGxlYXZlIGl0IHRvIG90aGVycyB0byBkZWNpZGUgd2hldGhlciB0aGV5J2Qg d2FudCBjb3BpZXMgb2YgdG9kYXkgUERGIGZpbGVzIHNlbnQgdG8gdGhlIG1haWxpbmcgbGlzdCBk aXJlY3RseS4KUmVnYXJkcywKVXJpClNlbnQgZnJvbSBteSBpUGhvbmUKCk9uIEF1ZyAxNywgMjAx OSwgYXQgMDE6MDMsIFBhdWwgWWFuZyA8a2Fpc2hlbi55eT00MGFsaXBheS5jb21AZG1hcmMuaWV0 Zi5vcmc+IHdyb3RlOgpHb29kIHBvaW50cy4KVGhlIGdvb2QgbmV3cyBpcyB0aGF0IHdlIGhhdmUg Zm91bmQgc29tZSBFbmdsaXNoIFBERnMgb2YgU00yLCBpbmNsdWRpbmcgdGhlIG1pc3NpbmcgcGFy dCAxIGFuZCBwYXJ0IDMuIFdpbGwgY29udGludWUgdG8gZmluZCBFbmdsaXNoIHRyYW5zbGF0aW9u cyBvZiBvdGhlciBTTSBzdGFuZGFyZHMgbWVudGlvbmVkIGluIHRoZSBkcmFmdC4KU28sIGlmIHdl IGhvc3QgYSBmcmVlIHdlYnNpdGUsIHNheSBvbiBHaXRodWIgb3Igc28sIHRvIHByb3ZpZGUgdGhv c2UgZG9jcywgaXMgaXQgY29udmVuaWVudCBmb3IgeW91IGd1eXM/IE9yIHNob3VsZCB3ZSBqdXN0 IGRyb3AgdGhlICAgUERGIGZpbGVzIHRvIHRoaXMgbWFpbGluZyBsaXN0IGFzIGF0dGFjaG1lbnRz PwoKCk9uIEF1ZyAxNiwgMjAxOSwgYXQgMTA6NTggUE0sIFJlbmUgU3RydWlrIDxyc3RydWlrLmV4 dEBnbWFpbC5jb20+IHdyb3RlOgpBcmd1YWJseSwgIm5hdGlvbmFsIiBjcnlwdG8gc3BlY2lmaWNh dGlvbnMgZ2FybmlzaCBtb3JlIHN0YXR1cmUgaWYgdGhlc2UgYXJlIG1hZGUgYXZhaWxhYmxlIHRv IHRoZSBwdWJpYyBieSB0aGF0IHN0YW5kYXJkLXNldHRpbmcgYm9keSBpdHNlbGYgKHdobywgdGhl cmVieSwgYWN0cyBhcyBpdHMgYXV0aG9yaXRhdGl2ZSBzb3VyY2UpLCB3aXRob3V0IGRlZmVyZW5j ZSB0byBhIHRoaXJkIHBhcnR5ICh0aGF0IG1heSwgaW5kZXBlbmRlbnRseSBmcm9tIHRoZSBvcmln aW5hdG9yLCBlbmZvcmNlIGRvY3VtZW50IGNvbnRyb2wgW2UuZy4sIGJ5IGVmZmVjdHVhdGluZyB0 ZWNobmljYWwgY2hhbmdlcyBvciBlbmZvcmNpbmcgY29udHJvbGxlZCBkaXNzZW1pbmF0aW9uXSku IApTaW5jZSB5b3VyIGRyYWZ0IGludHJvZHVjaW5nIFNNIGNpcGhlciBzdWl0ZXMgd2l0aCBUTFMx LjMgYXBwZWFscyB0byB0aGUgYXV0aG9yaXR5IG9mIGEgc3RhbmRhcmQtc2V0dGluZyBhdXRob3Jp dHksIGVhc3kgYXZhaWxhYmlsaXR5IG9mIHRoZSBmdWxsIGFuZCBhY2NyZWRpdGVkIHRlY2huaWNh bCBkb2N1bWVudGF0aW9uIHRvIHRoZSBJRVRGIGNvbW11bml0eSBoZWxwcyBpbiBzY3J1dGlueSBh bmQsIGUuZy4sIGV2YWx1YXRpbmcgY2xhaW1zIGluIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9u cyBzZWN0aW9uLgpPbiA4LzE2LzIwMTkgMzowNiBBTSwgS2VwZW5nIExpIHdyb3RlOgpIaSBSZW5l IGFuZCBhbGwsCj4gU2luY2UgdGhlIElTTyBkb2N1bWVudHMgYXJlIG5vdCBhdmFpbGFibGUgdG8g dGhlIGdlbmVyYWwgCj4gcHVibGljIHdpdGhvdXQgcGF5bWVudCwgaXQgd291bGQgYmUgaGVscGZ1 bCB0byBoYXZlIGEgZnJlZWx5IGF2YWlsYWJsZSAKPiBkb2N1bWVudCAoaW4gRW5nbGlzaCkgZnJv bSBhbiBhdXRob3JpdGF0aXZlIHNvdXJjZS4gSGF2aW5nIHN1Y2ggYSAKPiByZWZlcmVuY2UgYXZh aWxhYmxlIHdvdWxkIGJlIGhlbHBmdWwgdG8gdGhlIElFVEYgY29tbXVuaXR5IChhbmQgCj4gcmVz ZWFyY2hlcnMpLgpBYm91dCB0aGUgcmVmZXJlbmNlcyB0byBJU08gZG9jdW1lbnMsIEkgdGhpbmsg aXQgaXMgYSBnZW5lcmFsIGlzc3VlIGZvciBJRVRGIGRyYWZ0cy4KSG93IGRvZXMgdGhlIG90aGVy IElFVEYgZHJhZnRzIG1ha2UgdGhlIHJlZmVyZW5jZXMgdG8gSVNPIGRvY3VtZW50cz8gSVNPIGRv Y3VtZW50cyBhcmUgb2Z0ZW4gcmVmZXJlbmNlZCBieSBJRVRGIGRyYWZ0cy4KVGhhbmtzLApLaW5k IFJlZ2FyZHMKS2VwZW5nCuKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKA lOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKA lOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKA lOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlApSZTogW1RMU10gRHJh ZnQgZm9yIFNNIGNpcGhlciBzdWl0ZXMgdXNlZCBpbiBUTFMxLjMKUmVuZSBTdHJ1aWsgPHJzdHJ1 aWsuZXh0QGdtYWlsLmNvbT4gVGh1LCAxNSBBdWd1c3QgMjAxOSAxNTozNCBVVENTaG93IGhlYWRl cgpIaSBQYXVsOgogCkkgdHJpZWQgYW5kIGxvb2sgdXAgdGhlIGRvY3VtZW50cyBHTVQuMDAwOS0y MDEyIGFuZCBHQlQuMzI5MTguNS0yMDE2IG9uIAp0aGUgKG5vbi1zZWN1cmVkKSB3ZWJzaXRlcyB5 b3UgcmVmZXJlbmNlZCwgYnV0IG9ubHkgZm91bmQgQ2hpbmVzZSAKdmVyc2lvbnMgKGFuZCBDaGlu ZXNlIHdlYnNpdGUgbmF2aWdhdGlvbiBwYW5lbHMgW3BhcmRvbiBteSBwb29yIGxhbmd1YWdlIApz a2lsbHMgaGVyZV0pLiBTaW5jZSB0aGUgSVNPIGRvY3VtZW50cyBhcmUgbm90IGF2YWlsYWJsZSB0 byB0aGUgZ2VuZXJhbCAKcHVibGljIHdpdGhvdXQgcGF5bWVudCwgaXQgd291bGQgYmUgaGVscGZ1 bCB0byBoYXZlIGEgZnJlZWx5IGF2YWlsYWJsZSAKZG9jdW1lbnQgKGluIEVuZ2xpc2gpIGZyb20g YW4gYXV0aG9yaXRhdGl2ZSBzb3VyY2UuIEhhdmluZyBzdWNoIGEgCnJlZmVyZW5jZSBhdmFpbGFi bGUgd291bGQgYmUgaGVscGZ1bCB0byB0aGUgSUVURiBjb21tdW5pdHkgKGFuZCAKcmVzZWFyY2hl cnMpLiBQbGVhc2Ugbm90ZSB0aGF0IEJTSSBwcm92aWRlcyBpdHMgc3BlY2lmaWNhdGlvbnMgaW4g R2VybWFuIAphbmQgRW5nbGlzaCwgc28gYXMgdG8gZm9zdGVyIHVzZS9zdHVkeSBieSB0aGUgY29t bXVuaXR5LiBJZiB0aGUgQ2hpbmVzZSAKbmF0aW9uYWwgYWxnb3JpdGhtcyB3b3VsZCBiZSBhdmFp bGFibGUgaW4gc2ltaWxhciBmb3JtLCB0aGlzIHdvdWxkIHNlcnZlIAphIHNpbWlsYXIgcHVycG9z ZS4KIApGWUkgLSBJIGFtIGludGVyZXN0ZWQgaW4gZnVsbCBkZXRhaWxzIGFuZCBzb21lIHRpbWUg bGFzdCB5ZWFyIEkgdHJpZWQgdG8gCmRvd25sb2FkIHNwZWNzLCBidXQgb25seSBQYXJ0cyAyLCA0 LCBhbmQgNSB3ZXJlIGF2YWlsYWJsZSBbMV0sIFsyXSwgWzNdLCAKbm90IFBhcnRzIDEgYW5kIDMu CiAKQmVzdCByZWdhcmRzLCBSZW5lCiAKWzFdIENoaW5hIEVDQyAtIFB1YmxpYyBLZXkgQ3J5cHRv Z3JhcGhpYyBBbGdvcml0aG0gU00yIEJhc2VkIG9uIEVDQyAtIApQYXJ0IDUgLSBQYXJhbWV0ZXIg RGVmaW5pdGlvbiAoU0VNQiwgSnVseSAyNCwgMjAxOCkKWzJdIENoaW5hIEVDQyAtIFB1YmxpYyBL ZXkgQ3J5cHRvZ3JhcGhpYyBBbGdvcml0aG0gU00yIEJhc2VkIG9uIEVDQyAtIApQYXJ0IDIgLSBE aWdpdGFsIFNpZ25hdHVyZSBBbGdvcml0aG0gKFNFTUIsIEp1bHkgMjQsIDIwMTgpClszXSBDaGlu YSBFQ0MgLSBQdWJsaWMgS2V5IENyeXB0b2dyYXBoaWMgQWxnb3JpdGhtIFNNMiBCYXNlZCBvbiBF Q0MgLSAKUGFydCA0IC0gUHVibGljIEtleSBFbmNyeXB0aW9uIEFsZ29yaXRobSAoU0VNQiwgSnVs eSAyNCwgMjAxOCkKIApPbiA4LzE1LzIwMTkgMTA6MTYgQU0sIFBhdWwgWWFuZyB3cm90ZToKPiBI aSBhbGwsCj4gCj4gSSBoYXZlIHN1Ym1pdHRlZCBhIG5ldyBpbnRlcm5ldCBkcmFmdCB0byBpbnRy b2R1Y2UgdGhlIFNNIGNpcGhlciAKPiBzdWl0ZXMgaW50byBUTFMgMS4zIHByb3RvY29sLgo+IAo+ IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC15YW5nLXRscy10bHMxMy1zbS1zdWl0 ZXMtMDAKPiAKPiBTTSBjcnlwdG9ncmFwaGljIGFsZ29yaXRobXMgYXJlIG9yaWdpbmFsbHkgYSBz ZXQgb2YgQ2hpbmVzZSBuYXRpb25hbCAKPiBhbGdvcml0aG1zIGFuZCBub3cgaGF2ZSBiZWVuIChv ciBiZWluZykgYWNjZXB0ZWQgYnkgSVNPIGFzIAo+IGludGVybmF0aW9uYWwgc3RhbmRhcmRzLCBp bmNsdWRpbmcgU00yIHNpZ25hdHVyZSBhbGdvcml0aG0sIFNNMyBoYXNoIAo+IGZ1bmN0aW9uIGFu ZCBTTTQgYmxvY2sgY2lwaGVyLiBUaGVzZSBhbGdvcml0aG1zIGhhdmUgYWxyZWFkeSBiZWVuIAo+ IHN1cHBvcnRlZCBzb21lIHRpbWUgYWdvIGJ5IHNldmVyYWwgd2lkZWx5IHVzZWQgb3BlbiBzb3Vy Y2UgCj4gY3J5cHRvZ3JhcGhpYyBsaWJyYXJpZXMgaW5jbHVkaW5nIE9wZW5TU0wsIEJvdW5jeUNh c3RsZSwgQm90YW4sIGV0Yy4KPiAKPiBDb25zaWRlcmluZyBUTFMxLjMgaXMgYmVpbmcgZ3JhZHVh bGx5IGFkb3B0ZWQgaW4gQ2hpbmEncyBpbnRlcm5ldCAKPiBpbmR1c3RyeSwgaXQncyBpbXBvcnRh bnQgdG8gaGF2ZSBhIG5vcm1hdGl2ZSBkZWZpbml0aW9uIG9uIGhvdyB0byB1c2UgCj4gdGhlIFNN IGFsZ29yaXRobXMgd2l0aCBUTFMxLjMsIGVzcGVjaWFsbHkgZm9yIHRoZSBtb2JpbGUgaW50ZXJu ZXQgCj4gc2NlbmFyaW8uIEFudCBGaW5hbmNpYWwgaXMgdGhlIGNvbXBhbnkgd2hvIGRldmVsb3Bz IHRoZSBtYXJrZXQgbGVhZGluZyAKPiBtb2JpbGUgYXBwICdBbGlwYXknIGFuZCBzdXBwb3J0cyBw YXltZW50IHNlcnZpY2VzIGZvciBBbGliYWJhIAo+IGUtY29tbWVyY2UgYnVzaW5lc3MuIFdlIGhp Z2hseSBhcmUgZGVwZW5kaW5nIG9uIHRoZSBuZXcgVExTMS4zIAo+IHByb3RvY29sIGZvciBib3Ro IHBlcmZvcm1hbmNlIGFuZCBzZWN1cml0eSBwdXJwb3Nlcy4gV2UgZXhwZWN0IHRvIGhhdmUgCj4g bW9yZSBkZXBsb3ltZW50IG9mIFRMUzEuMyBjYXBhYmxlIGFwcGxpY2F0aW9ucyBpbiBDaGluYSdz IGludGVybmV0IAo+IGluZHVzdHJ5IGJ5IHRoaXMgc3RhbmRhcmRpemF0aW9uIGF0dGVtcHRzLgo+ IAo+IEl0J3MgdmVyeSBhcHByZWNpYXRlZCB0byBoYXZlIGNvbW1lbnRzIGZyb20gdGhlIElFVEYg VExTIGxpc3QgOi0pCj4gCj4gTWFueSB0aGFua3MhCj4gCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KPiBUTFMgbWFpbGluZyBsaXN0Cj4gVExTQGlldGYu b3JnCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMKLS0gCmVtYWls OiByc3RydWlrLmV4dEBnbWFpbC5jb20gfCBTa3lwZTogcnN0cnVpawpjZWxsOiArMSAoNjQ3KSA4 NjctNTY1OCB8IFVTOiArMSAoNDE1KSA2OTAtNzM2MwpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXwpUTFMgbWFpbGluZyBsaXN0ClRMU0BpZXRmLm9yZwpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RscwoKUmVnYXJkcywKClBhdWwgWWFu ZwpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpUTFMgbWFp bGluZyBsaXN0ClRMU0BpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3RscwpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBU TFMgbWFpbGluZyBsaXN0IFRMU0BpZXRmLm9yZyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3RscwoK ------=ALIBOUNDARY_896_4a039940_5d5a8d43_19b8900 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBjbGFzcz0iX19hbGl5dW5fZW1haWxfYm9keV9ibG9jayI+PGRpdiAgc3R5bGU9ImNsZWFy OmJvdGg7Ij48c3BhbiAgc3R5bGU9ImNvbG9yOiMwMDAwMDA7Zm9udC1zaXplOjE2LjBweDtmb250 LWZhbWlseTphcmlhbDsiPkN1cnJlbnRseSwgd2UgdXBsb2FkZWQgc29tZSBvZiB0aGUgcmVmZXJl bmNlZCBkb2N1bWVudHMgaGVyZTo8L3NwYW4+PC9kaXY+PGRpdiAgc3R5bGU9ImNsZWFyOmJvdGg7 Ij48c3BhbiAgc3R5bGU9ImNvbG9yOiMwMDAwMDA7Zm9udC1zaXplOjE2LjBweDtmb250LWZhbWls eTphcmlhbDsiPjxhICBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vYWxpcGF5L3RsczEzLXNtLXNw ZWMiPmh0dHBzOi8vZ2l0aHViLmNvbS9hbGlwYXkvdGxzMTMtc20tc3BlYzwvYT48L3NwYW4+PC9k aXY+PGRpdiAgc3R5bGU9ImNsZWFyOmJvdGg7Ij48YnIgPjwvZGl2PjxkaXYgIHN0eWxlPSJjbGVh cjpib3RoOyI+PHNwYW4gIHN0eWxlPSJmb250LXNpemU6MTYuMHB4O2ZvbnQtZmFtaWx5OmFyaWFs OyI+QFJlbmUsJm5ic3A7PHNwYW4gIHN0eWxlPSJjb2xvcjojMjEyNTI5O2ZvbnQtZmFtaWx5OmFy aWFsO2ZvbnQtc2l6ZToxNi4wcHg7Ij5QYXJ0cyAxIGFuZCAzIGNhbiBiZSBmb3VuZCBpbiB0aGUg bGluayBhYm92ZS48L3NwYW4+PC9zcGFuPjwvZGl2PjxkaXYgIHN0eWxlPSJjbGVhcjpib3RoOyI+ PHNwYW4gIHN0eWxlPSJjb2xvcjojMDAwMDAwO2ZvbnQtc2l6ZToxNi4wcHg7Zm9udC1mYW1pbHk6 YXJpYWw7Ij48YnIgPjwvc3Bhbj48L2Rpdj48ZGl2ICBzdHlsZT0iY2xlYXI6Ym90aDsiPjxzcGFu ICBzdHlsZT0iZm9udC1zaXplOjE2LjBweDtmb250LWZhbWlseTphcmlhbDsiPkhvcGUgaXQgaGVs cHMuPC9zcGFuPjwvZGl2PjxkaXYgIHN0eWxlPSJjbGVhcjpib3RoOyI+PGJyID48L2Rpdj48ZGl2 ICBzdHlsZT0iY2xlYXI6Ym90aDsiPjxzcGFuICBzdHlsZT0iZm9udC1zaXplOjE2LjBweDtmb250 LWZhbWlseTphcmlhbDsiPlRoYW5rcyw8L3NwYW4+PC9kaXY+PGRpdiAgc3R5bGU9ImNsZWFyOmJv dGg7Ij48YnIgPjwvZGl2PjxkaXYgIHN0eWxlPSJjbGVhcjpib3RoOyI+PHNwYW4gIHN0eWxlPSJm b250LXNpemU6MTYuMHB4O2ZvbnQtZmFtaWx5OmFyaWFsOyI+S2luZCBSZWdhcmRzPC9zcGFuPjwv ZGl2PjxkaXYgIHN0eWxlPSJjbGVhcjpib3RoOyI+PHNwYW4gIHN0eWxlPSJmb250LXNpemU6MTYu MHB4O2ZvbnQtZmFtaWx5OmFyaWFsOyI+S2VwZW5nPC9zcGFuPjwvZGl2PjxkaXYgIHN0eWxlPSJj bGVhcjpib3RoOyI+PHNwYW4gIHN0eWxlPSJmb250LWZhbWlseTpUYWhvbWEsQXJpYWwsU1RIZWl0 aSxTaW1TdW47Zm9udC1zaXplOjE0LjBweDtjb2xvcjojMDAwMDAwOyI+PGJyID48L3NwYW4+PC9k aXY+PGJsb2NrcXVvdGUgIHN0eWxlPSJtYXJnaW4tcmlnaHQ6LjBweDttYXJnaW4tdG9wOi4wcHg7 bWFyZ2luLWJvdHRvbTouMHB4OyI+PGRpdiAgc3R5bGU9ImNsZWFyOmJvdGg7Ij48c3BhbiAgc3R5 bGU9ImZvbnQtZmFtaWx5OlRhaG9tYSxBcmlhbCxTVEhlaXRpLFNpbVN1bjtmb250LXNpemU6MTQu MHB4O2NvbG9yOiMwMDAwMDA7Ij4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L3NwYW4+PC9kaXY+PGRpdiAgc3R5bGU9ImNs ZWFyOmJvdGg7Ij48c3BhbiAgc3R5bGU9ImZvbnQtZmFtaWx5OlRhaG9tYSxBcmlhbCxTVEhlaXRp LFNpbVN1bjtmb250LXNpemU6MTQuMHB4O2NvbG9yOiMwMDAwMDA7Ij7lj5Hku7bkurrvvJrmnY7l hYvpuY8o5piT5rexKSAmbHQ7a2VwZW5nLmxrcEBhbnRmaW4uY29tJmd0Ozwvc3Bhbj48L2Rpdj48 ZGl2ICBzdHlsZT0iY2xlYXI6Ym90aDsiPjxzcGFuICBzdHlsZT0iZm9udC1mYW1pbHk6VGFob21h LEFyaWFsLFNUSGVpdGksU2ltU3VuO2ZvbnQtc2l6ZToxNC4wcHg7Y29sb3I6IzAwMDAwMDsiPuWP kemAgeaXtumXtO+8mjIwMTnlubQ45pyIMTnml6Uo5pif5pyf5LiAKSAxNzozODwvc3Bhbj48L2Rp dj48ZGl2ICBzdHlsZT0iY2xlYXI6Ym90aDsiPjxzcGFuICBzdHlsZT0iZm9udC1mYW1pbHk6VGFo b21hLEFyaWFsLFNUSGVpdGksU2ltU3VuO2ZvbnQtc2l6ZToxNC4wcHg7Y29sb3I6IzAwMDAwMDsi PuaUtuS7tuS6uu+8mnNlYW4raWV0ZiAmbHQ7c2VhbitpZXRmQHNuM3JkLmNvbSZndDs7IGpvZSAm bHQ7am9lQHNhbG93ZXkubmV0Jmd0OzsgY2F3ICZsdDtjYXdAaGVhcGluZ2JpdHMubmV0Jmd0Ozwv c3Bhbj48L2Rpdj48ZGl2ICBzdHlsZT0iY2xlYXI6Ym90aDsiPjxzcGFuICBzdHlsZT0iZm9udC1m YW1pbHk6VGFob21hLEFyaWFsLFNUSGVpdGksU2ltU3VuO2ZvbnQtc2l6ZToxNC4wcHg7Y29sb3I6 IzAwMDAwMDsiPuaKhOOAgOmAge+8mnRsc0BpZXRmLm9yZyAmbHQ7dGxzQGlldGYub3JnJmd0Ozsg IkJsdW1lbnRoYWwsIFVyaSAtIDA1NTMgLSBNSVRMTCIgJmx0O3VyaUBsbC5taXQuZWR1Jmd0Ozsg UGF1bCBZYW5nICZsdDtrYWlzaGVuLnl5PTQwYWxpcGF5LmNvbUBkbWFyYy5pZXRmLm9yZyZndDs8 L3NwYW4+PC9kaXY+PGRpdiAgc3R5bGU9ImNsZWFyOmJvdGg7Ij48c3BhbiAgc3R5bGU9ImZvbnQt ZmFtaWx5OlRhaG9tYSxBcmlhbCxTVEhlaXRpLFNpbVN1bjtmb250LXNpemU6MTQuMHB4O2NvbG9y OiMwMDAwMDA7Ij7kuLvjgIDpopjvvJpSZTogW1RMU10gKG9mZmxpbmUpIFJlOiAgRHJhZnQgZm9y IFNNIGNpcGhlciBzdWl0ZXMgdXNlZCBpbiBUTFMxLjM8L3NwYW4+PC9kaXY+PGRpdiAgc3R5bGU9 ImNsZWFyOmJvdGg7Ij48c3BhbiAgc3R5bGU9ImZvbnQtZmFtaWx5OlRhaG9tYSxBcmlhbCxTVEhl aXRpLFNpbVN1bjtmb250LXNpemU6MTQuMHB4O2NvbG9yOiMwMDAwMDA7Ij48YnIgPjwvc3Bhbj48 L2Rpdj48c3R5bGUgPiEtLSAgQGZvbnQtZmFjZXtmb250LWZhbWlseTpIZWx2ZXRpY2E7cGFub3Nl LTE6MCAwIDAgMCAwIDAgMCAwIDAgMDt9e2ZvbnQtZmFtaWx5OuWui+S9kztwYW5vc2UtMToyIDEg NiAwIDMgMSAxIDEgMSAxO317Zm9udC1mYW1pbHk6Q2FtYnJpYSBNYXRoO3Bhbm9zZS0xOjIgNCA1 IDMgNSA0IDYgMyAyIDQ7fXtmb250LWZhbWlseTpEZW5nWGlhbjtwYW5vc2UtMToyIDEgNiAwIDMg MSAxIDEgMSAxO317Zm9udC1mYW1pbHk6Q2FsaWJyaTtwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9e2ZvbnQtZmFtaWx5OlRhaG9tYTtwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9 e2ZvbnQtZmFtaWx5Omx1Y2lkYSBHcmFuZGU7cGFub3NlLTE6MiAxMSA2IDAgNCA1IDIgMiAyIDQ7 fXtmb250LWZhbWlseTpNZW5sbztwYW5vc2UtMToyIDExIDYgOSAzIDggNCAyIDIgNDt9e2ZvbnQt ZmFtaWx5OlxA562J57q/O3Bhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fXtmb250LWZhbWls eTpcQOWui+S9kztwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO31wLk1zb05vcm1hbCwgbGku TXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFse21hcmdpbjouMGNtO21hcmdpbi1ib3R0b206LjBwdDtm b250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kzt9aDN7bXNvLXN0eWxlLXByaW9yaXR5 Ojk7bXNvLXN0eWxlLWxpbms65qCH6aKYIDMg5a2X56ymO21zby1tYXJnaW4tdG9wLWFsdDphdXRv O21hcmdpbi1yaWdodDouMGNtO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0 Oi4wY207Zm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTrlrovkvZM7fWE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmt7bXNvLXN0eWxlLXByaW9yaXR5Ojk5O2NvbG9yOmJsdWU7dGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2Vke21zby1z dHlsZS1wcmlvcml0eTo5OTtjb2xvcjpwdXJwbGU7dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 cHJle21zby1zdHlsZS1wcmlvcml0eTo5OTttc28tc3R5bGUtbGluazpIVE1MIOmihOiuvuagvOW8 jyDlrZfnrKY7bWFyZ2luOi4wY207bWFyZ2luLWJvdHRvbTouMHB0O2ZvbnQtc2l6ZToxMi4wcHQ7 Zm9udC1mYW1pbHk65a6L5L2TO31wLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29u b3JtYWwwe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt YXJnaW4tcmlnaHQ6LjBjbTttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDou MGNtO2ZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TO31zcGFuLkhUTUx7bXNvLXN0 eWxlLW5hbWU6SFRNTCDpooTorr7moLzlvI8g5a2X56ymO21zby1zdHlsZS1wcmlvcml0eTo5OTtt c28tc3R5bGUtbGluazpIVE1MIOmihOiuvuagvOW8jztmb250LWZhbWlseTpDb3VyaWVyIE5ldzt9 c3Bhbi4ze21zby1zdHlsZS1uYW1lOuagh+mimCAzIOWtl+espjttc28tc3R5bGUtcHJpb3JpdHk6 OTttc28tc3R5bGUtbGluazrmoIfpopggMztmb250LWZhbWlseTrlrovkvZM7Zm9udC13ZWlnaHQ6 Ym9sZDt9cC5tc2ctaGVhZGVyLCBsaS5tc2ctaGVhZGVyLCBkaXYubXNnLWhlYWRlcnttc28tc3R5 bGUtbmFtZTptc2ctaGVhZGVyO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1yaWdodDou MGNtO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi4wY207Zm9udC1zaXpl OjEyLjBwdDtmb250LWZhbWlseTrlrovkvZM7fXNwYW4ucGlwZXttc28tc3R5bGUtbmFtZTpwaXBl O31zcGFuLkVtYWlsU3R5bGUyM3ttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTtmb250LWZh bWlseTpEZW5nWGlhbjtjb2xvcjp3aW5kb3d0ZXh0O30uTXNvQ2hwRGVmYXVsdHttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTtmb250LXNpemU6MTAuMHB0O31AcGFnZSBXb3JkU2VjdGlvbjF7c2l6 ZTo2MTIuMHB0IDc5Mi4wcHQ7bWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9ZGl2 LldvcmRTZWN0aW9uMXtwYWdlOldvcmRTZWN0aW9uMTt9LS0+PC9zdHlsZT48ZGl2ICBjbGFzcz0i V29yZFNlY3Rpb24xIj48cCAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gIHN0eWxlPSJmb250LXNp emU6MTkuMHB4O2ZvbnQtZmFtaWx5OkRlbmdYaWFuOyI+SGkgV0cgY2hhaXJzLDwvc3Bhbj48L3A+ PHAgIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuICBzdHlsZT0iZm9udC1zaXplOjE5LjBweDtmb250 LWZhbWlseTpEZW5nWGlhbjsiPiZuYnNwOzwvc3Bhbj48L3A+PHAgIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuICBzdHlsZT0iZm9udC1zaXplOjE5LjBweDtmb250LWZhbWlseTpEZW5nWGlhbjsiPkNh biB3ZSBwbGFjZSB0aGUgcmVmZXJlbmNlZCBkb2N1bWVudHMgaW4gdGhlIFRMUyBXRyBHaXRIdWI/ PC9zcGFuPjwvcD48cCAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gIHN0eWxlPSJmb250LXNpemU6 MTkuMHB4O2ZvbnQtZmFtaWx5OkRlbmdYaWFuOyI+PGEgIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNv bS90bHN3ZyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZ2l0aHViLmNvbS90bHN3ZzwvYT48L3Nw YW4+PC9wPjxwICBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiAgc3R5bGU9ImZvbnQtc2l6ZToxOS4w cHg7Zm9udC1mYW1pbHk6RGVuZ1hpYW47Ij4mbmJzcDs8L3NwYW4+PC9wPjxwICBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiAgc3R5bGU9ImZvbnQtc2l6ZToxOS4wcHg7Zm9udC1mYW1pbHk6RGVuZ1hp YW47Ij5BY2NvcmRpbmcgdG8gdGhlIGRpc2N1c3Npb24gYmVsb3csIHRoaXMgY2FuIGhlbHAgcGVv cGxlIHRvIHJlYWQgYW5kIHVuZGVyc3RhbmQgdGhlIHJlZmVyZW5jZWQgc3BlY2lmaWNhdGlvbnMu PC9zcGFuPjwvcD48cCAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gIHN0eWxlPSJmb250LXNpemU6 MTkuMHB4O2ZvbnQtZmFtaWx5OkRlbmdYaWFuOyI+Jm5ic3A7PC9zcGFuPjwvcD48cCAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gIHN0eWxlPSJmb250LXNpemU6MTkuMHB4O2ZvbnQtZmFtaWx5OkRl bmdYaWFuOyI+VGhhbmtzLDwvc3Bhbj48L3A+PHAgIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuICBz dHlsZT0iZm9udC1zaXplOjE5LjBweDtmb250LWZhbWlseTpEZW5nWGlhbjsiPiZuYnNwOzwvc3Bh bj48L3A+PHAgIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuICBzdHlsZT0iZm9udC1zaXplOjE5LjBw eDtmb250LWZhbWlseTpEZW5nWGlhbjsiPktpbmQgUmVnYXJkczwvc3Bhbj48L3A+PHAgIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuICBzdHlsZT0iZm9udC1zaXplOjE5LjBweDtmb250LWZhbWlseTpE ZW5nWGlhbjsiPktlcGVuZyA8L3NwYW4+PC9wPjxwICBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiAg c3R5bGU9ImZvbnQtc2l6ZToxNC4wcHg7Zm9udC1mYW1pbHk6RGVuZ1hpYW47Ij4mbmJzcDs8L3Nw YW4+PC9wPjxkaXYgIHN0eWxlPSJib3JkZXItcmlnaHQ6bm9uZTtib3JkZXItYm90dG9tOm5vbmU7 Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXItaW1hZ2U6aW5pdGlhbDtib3JkZXItdG9wOjEuMHB4IHNv bGlkICNiNWM0ZGY7cGFkZGluZzouMHB4IC4wY20gLjBjbTsiPjxwICBjbGFzcz0iTXNvTm9ybWFs Ij48YiA+PHNwYW4gIHN0eWxlPSJjb2xvcjpibGFjazsiPuWPkeS7tuS6ujwvc3Bhbj48L2I+PGIg PjxzcGFuICBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr OyI+OiA8L3NwYW4+PC9iPjxzcGFuICBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrOyI+VExTICZsdDt0bHMtYm91bmNlc0BpZXRmLm9yZyZndDsgPC9zcGFu PjxzcGFuICBzdHlsZT0iY29sb3I6YmxhY2s7Ij7ku6Pooag8L3NwYW4+PHNwYW4gIHN0eWxlPSJm b250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7Y29sb3I6YmxhY2s7Ij4gIkJsdW1lbnRoYWws IFVyaSAtIDA1NTMgLSBNSVRMTCIgJmx0O3VyaUBsbC5taXQuZWR1Jmd0OzxiciA+PC9zcGFuPjxi ID48c3BhbiAgc3R5bGU9ImNvbG9yOmJsYWNrOyI+5pel5pyfPC9zcGFuPjwvYj48YiA+PHNwYW4g IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7Y29sb3I6YmxhY2s7Ij46IDwv c3Bhbj48L2I+PHNwYW4gIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7Y29s b3I6YmxhY2s7Ij4yMDE5PC9zcGFuPjxzcGFuICBzdHlsZT0iY29sb3I6YmxhY2s7Ij7lubQ8L3Nw YW4+PHNwYW4gIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2s7Ij44PC9zcGFuPjxzcGFuICBzdHlsZT0iY29sb3I6YmxhY2s7Ij7mnIg8L3NwYW4+PHNwYW4g IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7Y29sb3I6YmxhY2s7Ij4xODwv c3Bhbj48c3BhbiAgc3R5bGU9ImNvbG9yOmJsYWNrOyI+5pelPC9zcGFuPjxzcGFuICBzdHlsZT0i Zm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrOyI+IDwvc3Bhbj48c3Bh biAgc3R5bGU9ImNvbG9yOmJsYWNrOyI+5pif5pyf5pelPC9zcGFuPjxzcGFuICBzdHlsZT0iZm9u dC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrOyI+IDIyOjA4PGJyID48L3Nw YW4+PGIgPjxzcGFuICBzdHlsZT0iY29sb3I6YmxhY2s7Ij7mlLbku7bkuro8L3NwYW4+PC9iPjxi ID48c3BhbiAgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjtjb2xvcjpibGFj azsiPjogPC9zcGFuPjwvYj48c3BhbiAgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1z ZXJpZjtjb2xvcjpibGFjazsiPlBhdWwgWWFuZyAmbHQ7a2Fpc2hlbi55eT00MGFsaXBheS5jb21A ZG1hcmMuaWV0Zi5vcmcmZ3Q7PGJyID48L3NwYW4+PGIgPjxzcGFuICBzdHlsZT0iY29sb3I6Ymxh Y2s7Ij7mioTpgIE8L3NwYW4+PC9iPjxiID48c3BhbiAgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGli cmksc2Fucy1zZXJpZjtjb2xvcjpibGFjazsiPjogPC9zcGFuPjwvYj48c3BhbiAgc3R5bGU9ImZv bnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjtjb2xvcjpibGFjazsiPiJ0bHNAaWV0Zi5vcmci ICZsdDt0bHNAaWV0Zi5vcmcmZ3Q7PGJyID48L3NwYW4+PGIgPjxzcGFuICBzdHlsZT0iY29sb3I6 YmxhY2s7Ij7kuLvpopg8L3NwYW4+PC9iPjxiID48c3BhbiAgc3R5bGU9ImZvbnQtZmFtaWx5OkNh bGlicmksc2Fucy1zZXJpZjtjb2xvcjpibGFjazsiPjogPC9zcGFuPjwvYj48c3BhbiAgc3R5bGU9 ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjtjb2xvcjpibGFjazsiPlJlOiBbVExTXSAo b2ZmbGluZSkgUmU6IERyYWZ0IGZvciBTTSBjaXBoZXIgc3VpdGVzIHVzZWQgaW4gVExTMS4zPC9z cGFuPjwvcD48L2Rpdj48ZGl2ID48cCAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPjwvZGl2 PjxwICBjbGFzcz0iTXNvTm9ybWFsIj5JTUhPLCBwbGFjaW5nIHRoZSBkb2N1bWVudHMgb24gR2l0 SHViIHdvdWxkIGJlIHBlcmZlY3QsIGFuZCBxdWl0ZSBzdWZmaWNpZW50LiZuYnNwOzwvcD48ZGl2 ID48cCAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPjwvZGl2PjxkaXYgPjxwICBjbGFzcz0i TXNvTm9ybWFsIj5QbGVhc2UgbWFrZSBzdXJlIHRvIHBvc3QgdGhlIG5hbWUgb2YgdGhlIHJlcG8g aGVyZS4gOy8pPC9wPjxkaXYgPjxwICBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+PC9kaXY+ PGRpdiA+PHAgIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjE2LjBweDsi PkkgbGVhdmUgaXQgdG8gb3RoZXJzIHRvIGRlY2lkZSB3aGV0aGVyIHRoZXknZCB3YW50IGNvcGll cyBvZiB0b2RheSBQREYgZmlsZXMgc2VudCB0byB0aGUgbWFpbGluZyBsaXN0IGRpcmVjdGx5Ljwv cD48ZGl2ICBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj48cCAgY2xhc3M9Ik1zb05vcm1hbCI+UmVn YXJkcyw8L3A+PGRpdiA+PHAgIGNsYXNzPSJNc29Ob3JtYWwiPlVyaTwvcD48L2Rpdj48ZGl2ID48 cCAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPjwvZGl2PjxkaXYgPjxwICBjbGFzcz0iTXNv Tm9ybWFsIj5TZW50IGZyb20gbXkgaVBob25lPC9wPjwvZGl2PjwvZGl2PjxkaXYgPjxwICBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxNi4wcHg7Ij48YnIgPk9uIEF1ZyAx NywgMjAxOSwgYXQgMDE6MDMsIFBhdWwgWWFuZyAmbHQ7PGEgIGhyZWY9Im1haWx0bzprYWlzaGVu Lnl5PTQwYWxpcGF5LmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmthaXNoZW4u eXk9NDBhbGlwYXkuY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3JvdGU6PC9wPjwvZGl2Pjxk aXYgPjxwICBjbGFzcz0iTXNvTm9ybWFsIj5Hb29kIHBvaW50cy48L3A+PGRpdiA+PHAgIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzwvcD48L2Rpdj48ZGl2ID48cCAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhlIGdvb2QgbmV3cyBpcyB0aGF0IHdlIGhhdmUgZm91bmQgc29tZSBFbmdsaXNoIFBERnMgb2Yg U00yLCBpbmNsdWRpbmcgdGhlIG1pc3NpbmcgcGFydCAxIGFuZCBwYXJ0IDMuIFdpbGwgY29udGlu dWUgdG8gZmluZCBFbmdsaXNoIHRyYW5zbGF0aW9ucyBvZiBvdGhlciBTTSBzdGFuZGFyZHMgbWVu dGlvbmVkIGluIHRoZSBkcmFmdC48L3A+PC9kaXY+PGRpdiA+PHAgIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzwvcD48L2Rpdj48ZGl2ID48cCAgY2xhc3M9Ik1zb05vcm1hbCI+U28sIGlmIHdlIGhv c3QgYSBmcmVlIHdlYnNpdGUsIHNheSBvbiBHaXRodWIgb3Igc28sIHRvIHByb3ZpZGUgdGhvc2Ug ZG9jcywgaXMgaXQgY29udmVuaWVudCBmb3IgeW91IGd1eXM/IE9yIHNob3VsZCB3ZSBqdXN0IGRy b3AgdGhlICZuYnNwOyBQREYgZmlsZXMgdG8gdGhpcyBtYWlsaW5nIGxpc3QgYXMgYXR0YWNobWVu dHM/PC9wPjxkaXYgPjxwICBjbGFzcz0iTXNvTm9ybWFsIj48YnIgPjxiciA+PC9wPjxkaXYgPjxw ICBjbGFzcz0iTXNvTm9ybWFsIj5PbiBBdWcgMTYsIDIwMTksIGF0IDEwOjU4IFBNLCBSZW5lIFN0 cnVpayAmbHQ7PGEgIGhyZWY9Im1haWx0bzpyc3RydWlrLmV4dEBnbWFpbC5jb20iIHRhcmdldD0i X2JsYW5rIj5yc3RydWlrLmV4dEBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8L3A+PC9kaXY+PHAg IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwvcD48ZGl2ID48ZGl2ID48ZGl2ID48cCAgY2xhc3M9 Ik1zb05vcm1hbCI+QXJndWFibHksICJuYXRpb25hbCIgY3J5cHRvIHNwZWNpZmljYXRpb25zIGdh cm5pc2ggbW9yZSBzdGF0dXJlIGlmIHRoZXNlIGFyZSBtYWRlIGF2YWlsYWJsZSB0byB0aGUgcHVi aWMgYnkgdGhhdCBzdGFuZGFyZC1zZXR0aW5nIGJvZHkgaXRzZWxmICh3aG8sIHRoZXJlYnksIGFj dHMgYXMgaXRzIGF1dGhvcml0YXRpdmUgc291cmNlKSwgd2l0aG91dCBkZWZlcmVuY2UgdG8gYSB0 aGlyZCBwYXJ0eSAodGhhdCBtYXksIGluZGVwZW5kZW50bHkgZnJvbSB0aGUgb3JpZ2luYXRvciwg ZW5mb3JjZSBkb2N1bWVudCBjb250cm9sIFtlLmcuLCBieSBlZmZlY3R1YXRpbmcgdGVjaG5pY2Fs IGNoYW5nZXMgb3IgZW5mb3JjaW5nIGNvbnRyb2xsZWQgZGlzc2VtaW5hdGlvbl0pLiA8L3A+PC9k aXY+PGRpdiA+PHAgIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwvcD48L2Rpdj48ZGl2ID48cCAg Y2xhc3M9Ik1zb05vcm1hbCI+U2luY2UgeW91ciBkcmFmdCBpbnRyb2R1Y2luZyBTTSBjaXBoZXIg c3VpdGVzIHdpdGggVExTMS4zIGFwcGVhbHMgdG8gdGhlIGF1dGhvcml0eSBvZiBhIHN0YW5kYXJk LXNldHRpbmcgYXV0aG9yaXR5LCBlYXN5IGF2YWlsYWJpbGl0eSBvZiB0aGUgZnVsbCBhbmQgYWNj cmVkaXRlZCB0ZWNobmljYWwgZG9jdW1lbnRhdGlvbiB0byB0aGUgSUVURiBjb21tdW5pdHkgaGVs cHMgaW4gc2NydXRpbnkgYW5kLCBlLmcuLCBldmFsdWF0aW5nIGNsYWltcyBpbiB0aGUgc2VjdXJp dHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbi48L3A+PC9kaXY+PGRpdiA+PHAgIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzwvcD48L2Rpdj48ZGl2ID48cCAgY2xhc3M9Ik1zb05vcm1hbCI+T24gOC8x Ni8yMDE5IDM6MDYgQU0sIEtlcGVuZyBMaSB3cm90ZTo8L3A+PC9kaXY+PGRpdiA+PGRpdiA+PGRp diA+PHAgIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlOyI+PHNwYW4g IHN0eWxlPSJmb250LXNpemU6MTQuMHB4O2ZvbnQtZmFtaWx5OkFyaWFsLHNhbnMtc2VyaWY7Ij5I aSBSZW5lIGFuZCBhbGwsPC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48ZGl2ID48ZGl2ID48cCAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGU7Ij4mbmJzcDs8L3A+PC9kaXY+ PC9kaXY+PGRpdiA+PGRpdiA+PHByZSAgc3R5bGU9ImxpbmUtaGVpZ2h0OjIxLjBweDtiYWNrZ3Jv dW5kOndoaXRlOyI+PHNwYW4gIHN0eWxlPSJmb250LXNpemU6MTQuMHB4O2ZvbnQtZmFtaWx5OkFy aWFsLHNhbnMtc2VyaWY7Y29sb3I6IzIxMjUyOTsiPiZndDsgU2luY2UgdGhlIElTTyBkb2N1bWVu dHMgYXJlIG5vdCBhdmFpbGFibGUgdG8gdGhlIGdlbmVyYWwgPC9zcGFuPjwvcHJlPjxwcmUgIHN0 eWxlPSJsaW5lLWhlaWdodDoyMS4wcHg7YmFja2dyb3VuZDp3aGl0ZTsiPjxzcGFuICBzdHlsZT0i Zm9udC1zaXplOjE0LjBweDtmb250LWZhbWlseTpBcmlhbCxzYW5zLXNlcmlmO2NvbG9yOiMyMTI1 Mjk7Ij4mZ3Q7IHB1YmxpYyB3aXRob3V0IHBheW1lbnQsIGl0IHdvdWxkIGJlIGhlbHBmdWwgdG8g aGF2ZSBhIGZyZWVseSBhdmFpbGFibGUgPC9zcGFuPjwvcHJlPjxwcmUgIHN0eWxlPSJsaW5lLWhl aWdodDoyMS4wcHg7YmFja2dyb3VuZDp3aGl0ZTsiPjxzcGFuICBzdHlsZT0iZm9udC1zaXplOjE0 LjBweDtmb250LWZhbWlseTpBcmlhbCxzYW5zLXNlcmlmO2NvbG9yOiMyMTI1Mjk7Ij4mZ3Q7IGRv Y3VtZW50IChpbiBFbmdsaXNoKSBmcm9tIGFuIGF1dGhvcml0YXRpdmUgc291cmNlLiBIYXZpbmcg c3VjaCBhIDwvc3Bhbj48L3ByZT48cHJlICBzdHlsZT0ibGluZS1oZWlnaHQ6MjEuMHB4O2JhY2tn cm91bmQ6d2hpdGU7Ij48c3BhbiAgc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHg7Zm9udC1mYW1pbHk6 QXJpYWwsc2Fucy1zZXJpZjtjb2xvcjojMjEyNTI5OyI+Jmd0OyByZWZlcmVuY2UgYXZhaWxhYmxl IHdvdWxkIGJlIGhlbHBmdWwgdG8gdGhlIElFVEYgY29tbXVuaXR5IChhbmQgPC9zcGFuPjwvcHJl PjxwcmUgIHN0eWxlPSJsaW5lLWhlaWdodDoyMS4wcHg7YmFja2dyb3VuZDp3aGl0ZTsiPjxzcGFu ICBzdHlsZT0iZm9udC1zaXplOjE0LjBweDtmb250LWZhbWlseTpBcmlhbCxzYW5zLXNlcmlmO2Nv bG9yOiMyMTI1Mjk7Ij4mZ3Q7IHJlc2VhcmNoZXJzKS48L3NwYW4+PC9wcmU+PC9kaXY+PGRpdiA+ PHAgIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlOyI+PHNwYW4gIHN0 eWxlPSJmb250LXNpemU6MTQuMHB4O2ZvbnQtZmFtaWx5OkFyaWFsLHNhbnMtc2VyaWY7Ij5BYm91 dCB0aGUgcmVmZXJlbmNlcyB0byBJU08gZG9jdW1lbnMsIEkgdGhpbmsgaXQgaXMgYSBnZW5lcmFs IGlzc3VlIGZvciBJRVRGIGRyYWZ0cy48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxkaXYgPjxkaXYg PjxwICBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZTsiPiZuYnNwOzwv cD48L2Rpdj48L2Rpdj48ZGl2ID48ZGl2ID48cCAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGU7Ij48c3BhbiAgc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHg7Zm9udC1mYW1p bHk6QXJpYWwsc2Fucy1zZXJpZjsiPkhvdyBkb2VzIHRoZSBvdGhlciBJRVRGIGRyYWZ0cyBtYWtl IHRoZSByZWZlcmVuY2VzIHRvIElTTyBkb2N1bWVudHM/IElTTyBkb2N1bWVudHMgYXJlIG9mdGVu IHJlZmVyZW5jZWQgYnkgSUVURiBkcmFmdHMuPC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48ZGl2ID48 ZGl2ID48cCAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGU7Ij4mbmJz cDs8L3A+PC9kaXY+PC9kaXY+PGRpdiA+PGRpdiA+PHAgIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlOyI+PHNwYW4gIHN0eWxlPSJmb250LXNpemU6MTQuMHB4O2ZvbnQt ZmFtaWx5OkFyaWFsLHNhbnMtc2VyaWY7Ij5UaGFua3MsPC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48 ZGl2ID48ZGl2ID48cCAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGU7 Ij4mbmJzcDs8L3A+PC9kaXY+PC9kaXY+PGRpdiA+PGRpdiA+PHAgIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlOyI+PHNwYW4gIHN0eWxlPSJmb250LXNpemU6MTQuMHB4 O2ZvbnQtZmFtaWx5OkFyaWFsLHNhbnMtc2VyaWY7Ij5LaW5kIFJlZ2FyZHM8L3NwYW4+PC9wPjwv ZGl2PjxkaXYgPjxwICBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZTsi PjxzcGFuICBzdHlsZT0iZm9udC1zaXplOjE0LjBweDtmb250LWZhbWlseTpBcmlhbCxzYW5zLXNl cmlmOyI+S2VwZW5nPC9zcGFuPjwvcD48L2Rpdj48ZGl2ID48cCAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGU7Ij48c3BhbiAgc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHg7 Zm9udC1mYW1pbHk6VGFob21hLHNhbnMtc2VyaWY7Ij7igJTigJTigJTigJTigJTigJTigJTigJTi gJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTi gJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTi gJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTi gJQ8L3NwYW4+PC9wPjwvZGl2PjxkaXYgPjxoMyAgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGU7Ij48 c3BhbiAgc3R5bGU9ImZvbnQtZmFtaWx5Omx1Y2lkYSBHcmFuZGUsc2Fucy1zZXJpZjtjb2xvcjoj MjEyNTI5O2ZvbnQtd2VpZ2h0Om5vcm1hbDsiPlJlOiBbVExTXSBEcmFmdCBmb3IgU00gY2lwaGVy IHN1aXRlcyB1c2VkIGluIFRMUzEuMzwvc3Bhbj48L2gzPjxwICBjbGFzcz0ibXNnLWhlYWRlciIg aWQ9Im1zZy1pbmZvIiBzdHlsZT0ibWFyZ2luLXJpZ2h0Oi4wcHg7bWFyZ2luLWJvdHRvbToyMC4w cHg7bWFyZ2luLWxlZnQ6LjBweDtsaW5lLWhlaWdodDoyNC4wcHg7YmFja2dyb3VuZDp3aGl0ZTti b3gtc2l6aW5nOmJvcmRlci1ib3g7Zm9udC12YXJpYW50LWxpZ2F0dXJlczpub3JtYWw7Zm9udC12 YXJpYW50LWNhcHM6bm9ybWFsO3dpZG93czoyO3RleHQtZGVjb3JhdGlvbi1zdHlsZTppbml0aWFs O3RleHQtZGVjb3JhdGlvbi1jb2xvcjppbml0aWFsOyI+PHNwYW4gIHN0eWxlPSJmb250LXNpemU6 MTQuMHB4O2ZvbnQtZmFtaWx5Omx1Y2lkYSBHcmFuZGUsc2Fucy1zZXJpZjtjb2xvcjpncmF5OyI+ UmVuZSBTdHJ1aWsgJmx0OzxhICBocmVmPSJtYWlsdG86cnN0cnVpay5leHRAZ21haWwuY29tIiB0 YXJnZXQ9Il9ibGFuayI+PHNwYW4gIHN0eWxlPSJjb2xvcjojMWU1NDk0OyI+cnN0cnVpay5leHRA Z21haWwuY29tPC9zcGFuPjwvYT4mZ3Q7Jm5ic3A7VGh1LCAxNSBBdWd1c3QgMjAxOSAxNTozNCBV VEM8L3NwYW4+PGEgIGhyZWY9Imh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9icm93 c2UvdGxzLz9pbmRleD1OSGJIT0d0c1IxUzVjQ3I5bldOOV9zZHlUZ2cmYW1wO2didD0xIiB0YXJn ZXQ9Il9ibGFuayI+PHNwYW4gIHN0eWxlPSJmb250LXNpemU6MTQuMHB4O2ZvbnQtZmFtaWx5Omx1 Y2lkYSBHcmFuZGUsc2Fucy1zZXJpZjtjb2xvcjojMzM3YWI3O3RleHQtZGVjb3JhdGlvbjpub25l OyI+U2hvdyBoZWFkZXI8L3NwYW4+PC9hPjwvcD48cHJlICBzdHlsZT0ibGluZS1oZWlnaHQ6MjEu MHB4O2JhY2tncm91bmQ6d2hpdGU7Ym94LXNpemluZzpib3JkZXItYm94O21hcmdpbi1ib3R0b206 MS4wcmVtO292ZXJmbG93LXdyYXA6bm9ybWFsO292ZXJmbG93OmF1dG87Ij48c3BhbiAgc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHg7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOTsiPkhpIFBh dWw6PC9zcGFuPjwvcHJlPjxwcmUgIHN0eWxlPSJsaW5lLWhlaWdodDoyMS4wcHg7YmFja2dyb3Vu ZDp3aGl0ZTsiPjxzcGFuICBzdHlsZT0iZm9udC1zaXplOjEyLjBweDtmb250LWZhbWlseTpNZW5s bztjb2xvcjojMjEyNTI5OyI+Jm5ic3A7PC9zcGFuPjwvcHJlPjxwcmUgIHN0eWxlPSJsaW5lLWhl aWdodDoyMS4wcHg7YmFja2dyb3VuZDp3aGl0ZTsiPjxzcGFuICBzdHlsZT0iZm9udC1zaXplOjEy LjBweDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5OyI+SSB0cmllZCBhbmQgbG9vayB1 cCB0aGUgZG9jdW1lbnRzIEdNVC4wMDA5LTIwMTIgYW5kIEdCVC4zMjkxOC41LTIwMTYgb24gPC9z cGFuPjwvcHJlPjxwcmUgIHN0eWxlPSJsaW5lLWhlaWdodDoyMS4wcHg7YmFja2dyb3VuZDp3aGl0 ZTsiPjxzcGFuICBzdHlsZT0iZm9udC1zaXplOjEyLjBweDtmb250LWZhbWlseTpNZW5sbztjb2xv cjojMjEyNTI5OyI+dGhlIChub24tc2VjdXJlZCkgd2Vic2l0ZXMgeW91IHJlZmVyZW5jZWQsIGJ1 dCBvbmx5IGZvdW5kIENoaW5lc2UgPC9zcGFuPjwvcHJlPjxwcmUgIHN0eWxlPSJsaW5lLWhlaWdo dDoyMS4wcHg7YmFja2dyb3VuZDp3aGl0ZTsiPjxzcGFuICBzdHlsZT0iZm9udC1zaXplOjEyLjBw eDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5OyI+dmVyc2lvbnMgKGFuZCBDaGluZXNl IHdlYnNpdGUgbmF2aWdhdGlvbiBwYW5lbHMgW3BhcmRvbiBteSBwb29yIGxhbmd1YWdlIDwvc3Bh bj48L3ByZT48cHJlICBzdHlsZT0ibGluZS1oZWlnaHQ6MjEuMHB4O2JhY2tncm91bmQ6d2hpdGU7 Ij48c3BhbiAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHg7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6 IzIxMjUyOTsiPnNraWxscyBoZXJlXSkuIFNpbmNlIHRoZSBJU08gZG9jdW1lbnRzIGFyZSBub3Qg YXZhaWxhYmxlIHRvIHRoZSBnZW5lcmFsIDwvc3Bhbj48L3ByZT48cHJlICBzdHlsZT0ibGluZS1o ZWlnaHQ6MjEuMHB4O2JhY2tncm91bmQ6d2hpdGU7Ij48c3BhbiAgc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHg7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOTsiPnB1YmxpYyB3aXRob3V0IHBh eW1lbnQsIGl0IHdvdWxkIGJlIGhlbHBmdWwgdG8gaGF2ZSBhIGZyZWVseSBhdmFpbGFibGUgPC9z cGFuPjwvcHJlPjxwcmUgIHN0eWxlPSJsaW5lLWhlaWdodDoyMS4wcHg7YmFja2dyb3VuZDp3aGl0 ZTsiPjxzcGFuICBzdHlsZT0iZm9udC1zaXplOjEyLjBweDtmb250LWZhbWlseTpNZW5sbztjb2xv cjojMjEyNTI5OyI+ZG9jdW1lbnQgKGluIEVuZ2xpc2gpIGZyb20gYW4gYXV0aG9yaXRhdGl2ZSBz b3VyY2UuIEhhdmluZyBzdWNoIGEgPC9zcGFuPjwvcHJlPjxwcmUgIHN0eWxlPSJsaW5lLWhlaWdo dDoyMS4wcHg7YmFja2dyb3VuZDp3aGl0ZTsiPjxzcGFuICBzdHlsZT0iZm9udC1zaXplOjEyLjBw eDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5OyI+cmVmZXJlbmNlIGF2YWlsYWJsZSB3 b3VsZCBiZSBoZWxwZnVsIHRvIHRoZSBJRVRGIGNvbW11bml0eSAoYW5kIDwvc3Bhbj48L3ByZT48 cHJlICBzdHlsZT0ibGluZS1oZWlnaHQ6MjEuMHB4O2JhY2tncm91bmQ6d2hpdGU7Ij48c3BhbiAg c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHg7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOTsi PnJlc2VhcmNoZXJzKS4gUGxlYXNlIG5vdGUgdGhhdCBCU0kgcHJvdmlkZXMgaXRzIHNwZWNpZmlj YXRpb25zIGluIEdlcm1hbiA8L3NwYW4+PC9wcmU+PHByZSAgc3R5bGU9ImxpbmUtaGVpZ2h0OjIx LjBweDtiYWNrZ3JvdW5kOndoaXRlOyI+PHNwYW4gIHN0eWxlPSJmb250LXNpemU6MTIuMHB4O2Zv bnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1Mjk7Ij5hbmQgRW5nbGlzaCwgc28gYXMgdG8gZm9z dGVyIHVzZS9zdHVkeSBieSB0aGUgY29tbXVuaXR5LiBJZiB0aGUgQ2hpbmVzZSA8L3NwYW4+PC9w cmU+PHByZSAgc3R5bGU9ImxpbmUtaGVpZ2h0OjIxLjBweDtiYWNrZ3JvdW5kOndoaXRlOyI+PHNw YW4gIHN0eWxlPSJmb250LXNpemU6MTIuMHB4O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1 Mjk7Ij5uYXRpb25hbCBhbGdvcml0aG1zIHdvdWxkIGJlIGF2YWlsYWJsZSBpbiBzaW1pbGFyIGZv cm0sIHRoaXMgd291bGQgc2VydmUgPC9zcGFuPjwvcHJlPjxwcmUgIHN0eWxlPSJsaW5lLWhlaWdo dDoyMS4wcHg7YmFja2dyb3VuZDp3aGl0ZTsiPjxzcGFuICBzdHlsZT0iZm9udC1zaXplOjEyLjBw eDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5OyI+YSBzaW1pbGFyIHB1cnBvc2UuPC9z cGFuPjwvcHJlPjxwcmUgIHN0eWxlPSJsaW5lLWhlaWdodDoyMS4wcHg7YmFja2dyb3VuZDp3aGl0 ZTsiPjxzcGFuICBzdHlsZT0iZm9udC1zaXplOjEyLjBweDtmb250LWZhbWlseTpNZW5sbztjb2xv cjojMjEyNTI5OyI+Jm5ic3A7PC9zcGFuPjwvcHJlPjxwcmUgIHN0eWxlPSJsaW5lLWhlaWdodDoy MS4wcHg7YmFja2dyb3VuZDp3aGl0ZTsiPjxzcGFuICBzdHlsZT0iZm9udC1zaXplOjEyLjBweDtm b250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5OyI+RllJIC0gSSBhbSBpbnRlcmVzdGVkIGlu IGZ1bGwgZGV0YWlscyBhbmQgc29tZSB0aW1lIGxhc3QgeWVhciBJIHRyaWVkIHRvIDwvc3Bhbj48 L3ByZT48cHJlICBzdHlsZT0ibGluZS1oZWlnaHQ6MjEuMHB4O2JhY2tncm91bmQ6d2hpdGU7Ij48 c3BhbiAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHg7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIx MjUyOTsiPmRvd25sb2FkIHNwZWNzLCBidXQgb25seSBQYXJ0cyAyLCA0LCBhbmQgNSB3ZXJlIGF2 YWlsYWJsZSBbMV0sIFsyXSwgWzNdLCA8L3NwYW4+PC9wcmU+PHByZSAgc3R5bGU9ImxpbmUtaGVp Z2h0OjIxLjBweDtiYWNrZ3JvdW5kOndoaXRlOyI+PHNwYW4gIHN0eWxlPSJmb250LXNpemU6MTIu MHB4O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1Mjk7Ij5ub3QgUGFydHMgMSBhbmQgMy48 L3NwYW4+PC9wcmU+PHByZSAgc3R5bGU9ImxpbmUtaGVpZ2h0OjIxLjBweDtiYWNrZ3JvdW5kOndo aXRlOyI+PHNwYW4gIHN0eWxlPSJmb250LXNpemU6MTIuMHB4O2ZvbnQtZmFtaWx5Ok1lbmxvO2Nv bG9yOiMyMTI1Mjk7Ij4mbmJzcDs8L3NwYW4+PC9wcmU+PHByZSAgc3R5bGU9ImxpbmUtaGVpZ2h0 OjIxLjBweDtiYWNrZ3JvdW5kOndoaXRlOyI+PHNwYW4gIHN0eWxlPSJmb250LXNpemU6MTIuMHB4 O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1Mjk7Ij5CZXN0IHJlZ2FyZHMsIFJlbmU8L3Nw YW4+PC9wcmU+PHByZSAgc3R5bGU9ImxpbmUtaGVpZ2h0OjIxLjBweDtiYWNrZ3JvdW5kOndoaXRl OyI+PHNwYW4gIHN0eWxlPSJmb250LXNpemU6MTIuMHB4O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9y OiMyMTI1Mjk7Ij4mbmJzcDs8L3NwYW4+PC9wcmU+PHByZSAgc3R5bGU9ImxpbmUtaGVpZ2h0OjIx LjBweDtiYWNrZ3JvdW5kOndoaXRlOyI+PHNwYW4gIHN0eWxlPSJmb250LXNpemU6MTIuMHB4O2Zv bnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1Mjk7Ij5bMV0gQ2hpbmEgRUNDIC0gUHVibGljIEtl eSBDcnlwdG9ncmFwaGljIEFsZ29yaXRobSBTTTIgQmFzZWQgb24gRUNDIC0gPC9zcGFuPjwvcHJl PjxwcmUgIHN0eWxlPSJsaW5lLWhlaWdodDoyMS4wcHg7YmFja2dyb3VuZDp3aGl0ZTsiPjxzcGFu ICBzdHlsZT0iZm9udC1zaXplOjEyLjBweDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5 OyI+UGFydCA1IC0gUGFyYW1ldGVyIERlZmluaXRpb24gKFNFTUIsIEp1bHkgMjQsIDIwMTgpPC9z cGFuPjwvcHJlPjxwcmUgIHN0eWxlPSJsaW5lLWhlaWdodDoyMS4wcHg7YmFja2dyb3VuZDp3aGl0 ZTsiPjxzcGFuICBzdHlsZT0iZm9udC1zaXplOjEyLjBweDtmb250LWZhbWlseTpNZW5sbztjb2xv cjojMjEyNTI5OyI+WzJdIENoaW5hIEVDQyAtIFB1YmxpYyBLZXkgQ3J5cHRvZ3JhcGhpYyBBbGdv cml0aG0gU00yIEJhc2VkIG9uIEVDQyAtIDwvc3Bhbj48L3ByZT48cHJlICBzdHlsZT0ibGluZS1o ZWlnaHQ6MjEuMHB4O2JhY2tncm91bmQ6d2hpdGU7Ij48c3BhbiAgc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHg7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOTsiPlBhcnQgMiAtIERpZ2l0YWwg U2lnbmF0dXJlIEFsZ29yaXRobSAoU0VNQiwgSnVseSAyNCwgMjAxOCk8L3NwYW4+PC9wcmU+PHBy ZSAgc3R5bGU9ImxpbmUtaGVpZ2h0OjIxLjBweDtiYWNrZ3JvdW5kOndoaXRlOyI+PHNwYW4gIHN0 eWxlPSJmb250LXNpemU6MTIuMHB4O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1Mjk7Ij5b M10gQ2hpbmEgRUNDIC0gUHVibGljIEtleSBDcnlwdG9ncmFwaGljIEFsZ29yaXRobSBTTTIgQmFz ZWQgb24gRUNDIC0gPC9zcGFuPjwvcHJlPjxwcmUgIHN0eWxlPSJsaW5lLWhlaWdodDoyMS4wcHg7 YmFja2dyb3VuZDp3aGl0ZTsiPjxzcGFuICBzdHlsZT0iZm9udC1zaXplOjEyLjBweDtmb250LWZh bWlseTpNZW5sbztjb2xvcjojMjEyNTI5OyI+UGFydCA0IC0gUHVibGljIEtleSBFbmNyeXB0aW9u IEFsZ29yaXRobSAoU0VNQiwgSnVseSAyNCwgMjAxOCk8L3NwYW4+PC9wcmU+PHByZSAgc3R5bGU9 ImxpbmUtaGVpZ2h0OjIxLjBweDtiYWNrZ3JvdW5kOndoaXRlOyI+PHNwYW4gIHN0eWxlPSJmb250 LXNpemU6MTIuMHB4O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1Mjk7Ij4mbmJzcDs8L3Nw YW4+PC9wcmU+PHByZSAgc3R5bGU9ImxpbmUtaGVpZ2h0OjIxLjBweDtiYWNrZ3JvdW5kOndoaXRl OyI+PHNwYW4gIHN0eWxlPSJmb250LXNpemU6MTIuMHB4O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9y OiMyMTI1Mjk7Ij5PbiA4LzE1LzIwMTkgMTA6MTYgQU0sIFBhdWwgWWFuZyB3cm90ZTo8L3NwYW4+ PC9wcmU+PHByZSAgc3R5bGU9ImxpbmUtaGVpZ2h0OjIxLjBweDtiYWNrZ3JvdW5kOndoaXRlOyI+ PHNwYW4gIHN0eWxlPSJmb250LXNpemU6MTIuMHB4O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMy MTI1Mjk7Ij4mZ3Q7IEhpIGFsbCw8L3NwYW4+PC9wcmU+PHByZSAgc3R5bGU9ImxpbmUtaGVpZ2h0 OjIxLjBweDtiYWNrZ3JvdW5kOndoaXRlOyI+PHNwYW4gIHN0eWxlPSJmb250LXNpemU6MTIuMHB4 O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1Mjk7Ij4mZ3Q7Jm5ic3A7PC9zcGFuPjwvcHJl PjxwcmUgIHN0eWxlPSJsaW5lLWhlaWdodDoyMS4wcHg7YmFja2dyb3VuZDp3aGl0ZTsiPjxzcGFu ICBzdHlsZT0iZm9udC1zaXplOjEyLjBweDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5 OyI+Jmd0OyBJIGhhdmUgc3VibWl0dGVkIGEgbmV3IGludGVybmV0IGRyYWZ0IHRvIGludHJvZHVj ZSB0aGUgU00gY2lwaGVyIDwvc3Bhbj48L3ByZT48cHJlICBzdHlsZT0ibGluZS1oZWlnaHQ6MjEu MHB4O2JhY2tncm91bmQ6d2hpdGU7Ij48c3BhbiAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHg7Zm9u dC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOTsiPiZndDsgc3VpdGVzIGludG8gVExTIDEuMyBw cm90b2NvbC48L3NwYW4+PC9wcmU+PHByZSAgc3R5bGU9ImxpbmUtaGVpZ2h0OjIxLjBweDtiYWNr Z3JvdW5kOndoaXRlOyI+PHNwYW4gIHN0eWxlPSJmb250LXNpemU6MTIuMHB4O2ZvbnQtZmFtaWx5 Ok1lbmxvO2NvbG9yOiMyMTI1Mjk7Ij4mZ3Q7Jm5ic3A7PC9zcGFuPjwvcHJlPjxwcmUgIHN0eWxl PSJsaW5lLWhlaWdodDoyMS4wcHg7YmFja2dyb3VuZDp3aGl0ZTsiPjxzcGFuICBzdHlsZT0iZm9u dC1zaXplOjEyLjBweDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5OyI+Jmd0OyA8YSAg aHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXlhbmctdGxzLXRsczEzLXNt LXN1aXRlcy0wMCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuICBzdHlsZT0iY29sb3I6IzMzN2FiNzt0 ZXh0LWRlY29yYXRpb246bm9uZTsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC15 YW5nLXRscy10bHMxMy1zbS1zdWl0ZXMtMDA8L3NwYW4+PC9hPjwvc3Bhbj48L3ByZT48cHJlICBz dHlsZT0ibGluZS1oZWlnaHQ6MjEuMHB4O2JhY2tncm91bmQ6d2hpdGU7Ij48c3BhbiAgc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHg7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOTsiPiZndDsm bmJzcDs8L3NwYW4+PC9wcmU+PHByZSAgc3R5bGU9ImxpbmUtaGVpZ2h0OjIxLjBweDtiYWNrZ3Jv dW5kOndoaXRlOyI+PHNwYW4gIHN0eWxlPSJmb250LXNpemU6MTIuMHB4O2ZvbnQtZmFtaWx5Ok1l bmxvO2NvbG9yOiMyMTI1Mjk7Ij4mZ3Q7IFNNIGNyeXB0b2dyYXBoaWMgYWxnb3JpdGhtcyBhcmUg b3JpZ2luYWxseSBhIHNldCBvZiBDaGluZXNlIG5hdGlvbmFsIDwvc3Bhbj48L3ByZT48cHJlICBz dHlsZT0ibGluZS1oZWlnaHQ6MjEuMHB4O2JhY2tncm91bmQ6d2hpdGU7Ij48c3BhbiAgc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHg7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOTsiPiZndDsg YWxnb3JpdGhtcyBhbmQgbm93IGhhdmUgYmVlbiAob3IgYmVpbmcpIGFjY2VwdGVkIGJ5IElTTyBh cyA8L3NwYW4+PC9wcmU+PHByZSAgc3R5bGU9ImxpbmUtaGVpZ2h0OjIxLjBweDtiYWNrZ3JvdW5k OndoaXRlOyI+PHNwYW4gIHN0eWxlPSJmb250LXNpemU6MTIuMHB4O2ZvbnQtZmFtaWx5Ok1lbmxv O2NvbG9yOiMyMTI1Mjk7Ij4mZ3Q7IGludGVybmF0aW9uYWwgc3RhbmRhcmRzLCBpbmNsdWRpbmcg U00yIHNpZ25hdHVyZSBhbGdvcml0aG0sIFNNMyBoYXNoIDwvc3Bhbj48L3ByZT48cHJlICBzdHls ZT0ibGluZS1oZWlnaHQ6MjEuMHB4O2JhY2tncm91bmQ6d2hpdGU7Ij48c3BhbiAgc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHg7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOTsiPiZndDsgZnVu Y3Rpb24gYW5kIFNNNCBibG9jayBjaXBoZXIuIFRoZXNlIGFsZ29yaXRobXMgaGF2ZSBhbHJlYWR5 IGJlZW4gPC9zcGFuPjwvcHJlPjxwcmUgIHN0eWxlPSJsaW5lLWhlaWdodDoyMS4wcHg7YmFja2dy b3VuZDp3aGl0ZTsiPjxzcGFuICBzdHlsZT0iZm9udC1zaXplOjEyLjBweDtmb250LWZhbWlseTpN ZW5sbztjb2xvcjojMjEyNTI5OyI+Jmd0OyBzdXBwb3J0ZWQgc29tZSB0aW1lIGFnbyBieSBzZXZl cmFsIHdpZGVseSB1c2VkIG9wZW4gc291cmNlIDwvc3Bhbj48L3ByZT48cHJlICBzdHlsZT0ibGlu ZS1oZWlnaHQ6MjEuMHB4O2JhY2tncm91bmQ6d2hpdGU7Ij48c3BhbiAgc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHg7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOTsiPiZndDsgY3J5cHRvZ3Jh cGhpYyBsaWJyYXJpZXMgaW5jbHVkaW5nIE9wZW5TU0wsIEJvdW5jeUNhc3RsZSwgQm90YW4sIGV0 Yy48L3NwYW4+PC9wcmU+PHByZSAgc3R5bGU9ImxpbmUtaGVpZ2h0OjIxLjBweDtiYWNrZ3JvdW5k OndoaXRlOyI+PHNwYW4gIHN0eWxlPSJmb250LXNpemU6MTIuMHB4O2ZvbnQtZmFtaWx5Ok1lbmxv O2NvbG9yOiMyMTI1Mjk7Ij4mZ3Q7Jm5ic3A7PC9zcGFuPjwvcHJlPjxwcmUgIHN0eWxlPSJsaW5l LWhlaWdodDoyMS4wcHg7YmFja2dyb3VuZDp3aGl0ZTsiPjxzcGFuICBzdHlsZT0iZm9udC1zaXpl OjEyLjBweDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5OyI+Jmd0OyBDb25zaWRlcmlu ZyBUTFMxLjMgaXMgYmVpbmcgZ3JhZHVhbGx5IGFkb3B0ZWQgaW4gQ2hpbmEncyBpbnRlcm5ldCA8 L3NwYW4+PC9wcmU+PHByZSAgc3R5bGU9ImxpbmUtaGVpZ2h0OjIxLjBweDtiYWNrZ3JvdW5kOndo aXRlOyI+PHNwYW4gIHN0eWxlPSJmb250LXNpemU6MTIuMHB4O2ZvbnQtZmFtaWx5Ok1lbmxvO2Nv bG9yOiMyMTI1Mjk7Ij4mZ3Q7IGluZHVzdHJ5LCBpdCdzIGltcG9ydGFudCB0byBoYXZlIGEgbm9y bWF0aXZlIGRlZmluaXRpb24gb24gaG93IHRvIHVzZSA8L3NwYW4+PC9wcmU+PHByZSAgc3R5bGU9 ImxpbmUtaGVpZ2h0OjIxLjBweDtiYWNrZ3JvdW5kOndoaXRlOyI+PHNwYW4gIHN0eWxlPSJmb250 LXNpemU6MTIuMHB4O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1Mjk7Ij4mZ3Q7IHRoZSBT TSBhbGdvcml0aG1zIHdpdGggVExTMS4zLCBlc3BlY2lhbGx5IGZvciB0aGUgbW9iaWxlIGludGVy bmV0IDwvc3Bhbj48L3ByZT48cHJlICBzdHlsZT0ibGluZS1oZWlnaHQ6MjEuMHB4O2JhY2tncm91 bmQ6d2hpdGU7Ij48c3BhbiAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHg7Zm9udC1mYW1pbHk6TWVu bG87Y29sb3I6IzIxMjUyOTsiPiZndDsgc2NlbmFyaW8uIEFudCBGaW5hbmNpYWwgaXMgdGhlIGNv bXBhbnkgd2hvIGRldmVsb3BzIHRoZSBtYXJrZXQgbGVhZGluZyA8L3NwYW4+PC9wcmU+PHByZSAg c3R5bGU9ImxpbmUtaGVpZ2h0OjIxLjBweDtiYWNrZ3JvdW5kOndoaXRlOyI+PHNwYW4gIHN0eWxl PSJmb250LXNpemU6MTIuMHB4O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1Mjk7Ij4mZ3Q7 IG1vYmlsZSBhcHAgJ0FsaXBheScgYW5kIHN1cHBvcnRzIHBheW1lbnQgc2VydmljZXMgZm9yIEFs aWJhYmEgPC9zcGFuPjwvcHJlPjxwcmUgIHN0eWxlPSJsaW5lLWhlaWdodDoyMS4wcHg7YmFja2dy b3VuZDp3aGl0ZTsiPjxzcGFuICBzdHlsZT0iZm9udC1zaXplOjEyLjBweDtmb250LWZhbWlseTpN ZW5sbztjb2xvcjojMjEyNTI5OyI+Jmd0OyBlLWNvbW1lcmNlIGJ1c2luZXNzLiBXZSBoaWdobHkg YXJlIGRlcGVuZGluZyBvbiB0aGUgbmV3IFRMUzEuMyA8L3NwYW4+PC9wcmU+PHByZSAgc3R5bGU9 ImxpbmUtaGVpZ2h0OjIxLjBweDtiYWNrZ3JvdW5kOndoaXRlOyI+PHNwYW4gIHN0eWxlPSJmb250 LXNpemU6MTIuMHB4O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1Mjk7Ij4mZ3Q7IHByb3Rv Y29sIGZvciBib3RoIHBlcmZvcm1hbmNlIGFuZCBzZWN1cml0eSBwdXJwb3Nlcy4gV2UgZXhwZWN0 IHRvIGhhdmUgPC9zcGFuPjwvcHJlPjxwcmUgIHN0eWxlPSJsaW5lLWhlaWdodDoyMS4wcHg7YmFj a2dyb3VuZDp3aGl0ZTsiPjxzcGFuICBzdHlsZT0iZm9udC1zaXplOjEyLjBweDtmb250LWZhbWls eTpNZW5sbztjb2xvcjojMjEyNTI5OyI+Jmd0OyBtb3JlIGRlcGxveW1lbnQgb2YgVExTMS4zIGNh cGFibGUgYXBwbGljYXRpb25zIGluIENoaW5hJ3MgaW50ZXJuZXQgPC9zcGFuPjwvcHJlPjxwcmUg IHN0eWxlPSJsaW5lLWhlaWdodDoyMS4wcHg7YmFja2dyb3VuZDp3aGl0ZTsiPjxzcGFuICBzdHls ZT0iZm9udC1zaXplOjEyLjBweDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5OyI+Jmd0 OyBpbmR1c3RyeSBieSB0aGlzIHN0YW5kYXJkaXphdGlvbiBhdHRlbXB0cy48L3NwYW4+PC9wcmU+ PHByZSAgc3R5bGU9ImxpbmUtaGVpZ2h0OjIxLjBweDtiYWNrZ3JvdW5kOndoaXRlOyI+PHNwYW4g IHN0eWxlPSJmb250LXNpemU6MTIuMHB4O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMyMTI1Mjk7 Ij4mZ3Q7Jm5ic3A7PC9zcGFuPjwvcHJlPjxwcmUgIHN0eWxlPSJsaW5lLWhlaWdodDoyMS4wcHg7 YmFja2dyb3VuZDp3aGl0ZTsiPjxzcGFuICBzdHlsZT0iZm9udC1zaXplOjEyLjBweDtmb250LWZh bWlseTpNZW5sbztjb2xvcjojMjEyNTI5OyI+Jmd0OyBJdCdzIHZlcnkgYXBwcmVjaWF0ZWQgdG8g aGF2ZSBjb21tZW50cyBmcm9tIHRoZSBJRVRGIFRMUyBsaXN0IDotKTwvc3Bhbj48L3ByZT48cHJl ICBzdHlsZT0ibGluZS1oZWlnaHQ6MjEuMHB4O2JhY2tncm91bmQ6d2hpdGU7Ij48c3BhbiAgc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHg7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOTsiPiZn dDsmbmJzcDs8L3NwYW4+PC9wcmU+PHByZSAgc3R5bGU9ImxpbmUtaGVpZ2h0OjIxLjBweDtiYWNr Z3JvdW5kOndoaXRlOyI+PHNwYW4gIHN0eWxlPSJmb250LXNpemU6MTIuMHB4O2ZvbnQtZmFtaWx5 Ok1lbmxvO2NvbG9yOiMyMTI1Mjk7Ij4mZ3Q7IE1hbnkgdGhhbmtzITwvc3Bhbj48L3ByZT48cHJl ICBzdHlsZT0ibGluZS1oZWlnaHQ6MjEuMHB4O2JhY2tncm91bmQ6d2hpdGU7Ij48c3BhbiAgc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHg7Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6IzIxMjUyOTsiPiZn dDsmbmJzcDs8L3NwYW4+PC9wcmU+PHByZSAgc3R5bGU9ImxpbmUtaGVpZ2h0OjIxLjBweDtiYWNr Z3JvdW5kOndoaXRlOyI+PHNwYW4gIHN0eWxlPSJmb250LXNpemU6MTIuMHB4O2ZvbnQtZmFtaWx5 Ok1lbmxvO2NvbG9yOiMyMTI1Mjk7Ij4mZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPC9zcGFuPjwvcHJlPjxwcmUgIHN0eWxlPSJsaW5lLWhlaWdodDoy MS4wcHg7YmFja2dyb3VuZDp3aGl0ZTsiPjxzcGFuICBzdHlsZT0iZm9udC1zaXplOjEyLjBweDtm b250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5OyI+Jmd0OyBUTFMgbWFpbGluZyBsaXN0PC9z cGFuPjwvcHJlPjxwcmUgIHN0eWxlPSJsaW5lLWhlaWdodDoyMS4wcHg7YmFja2dyb3VuZDp3aGl0 ZTsiPjxzcGFuICBzdHlsZT0iZm9udC1zaXplOjEyLjBweDtmb250LWZhbWlseTpNZW5sbztjb2xv cjojMjEyNTI5OyI+Jmd0OyA8YSAgaHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPjxzcGFuICBzdHlsZT0iY29sb3I6IzMzN2FiNzt0ZXh0LWRlY29yYXRpb246bm9uZTsi PlRMU0BpZXRmLm9yZzwvc3Bhbj48L2E+PC9zcGFuPjwvcHJlPjxwcmUgIHN0eWxlPSJsaW5lLWhl aWdodDoyMS4wcHg7YmFja2dyb3VuZDp3aGl0ZTsiPjxzcGFuICBzdHlsZT0iZm9udC1zaXplOjEy LjBweDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMjEyNTI5OyI+Jmd0OyA8YSAgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMiIHRhcmdldD0iX2JsYW5rIj48 c3BhbiAgc3R5bGU9ImNvbG9yOiMzMzdhYjc7dGV4dC1kZWNvcmF0aW9uOm5vbmU7Ij5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rsczwvc3Bhbj48L2E+PC9zcGFuPjwvcHJl PjwvZGl2PjxwICBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+PC9kaXY+PC9kaXY+PHAgIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwvcD48cHJlID4tLSA8L3ByZT48cHJlID5lbWFpbDogPGEg IGhyZWY9Im1haWx0bzpyc3RydWlrLmV4dEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5yc3Ry dWlrLmV4dEBnbWFpbC5jb208L2E+IHwgU2t5cGU6IHJzdHJ1aWs8L3ByZT48cHJlID5jZWxsOiAr MSAoNjQ3KSA4NjctNTY1OCB8IFVTOiArMSAoNDE1KSA2OTAtNzM2MzwvcHJlPjwvZGl2PjxwICBj bGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxiciA+VExTIG1haWxpbmcgbGlzdDxiciA+PGEgIGhyZWY9Im1haWx0bzpUTFNAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5UTFNAaWV0Zi5vcmc8L2E+PGJyID48YSAgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RsczwvYT48L3A+PC9kaXY+PC9k aXY+PHAgIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwvcD48ZGl2ID48ZGl2ID48cCAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gIHN0eWxlPSJmb250LXNpemU6MTIuMHB4O2ZvbnQtZmFtaWx5Okhl bHZldGljYTtjb2xvcjpibGFjazsiPjxiciA+UmVnYXJkcyw8L3NwYW4+PC9wPjwvZGl2PjxkaXYg PjxwICBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiAgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHg7Zm9u dC1mYW1pbHk6SGVsdmV0aWNhO2NvbG9yOmJsYWNrOyI+Jm5ic3A7PC9zcGFuPjwvcD48L2Rpdj48 ZGl2ID48cCAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gIHN0eWxlPSJmb250LXNpemU6MTIuMHB4 O2ZvbnQtZmFtaWx5OkhlbHZldGljYTtjb2xvcjpibGFjazsiPlBhdWwgWWFuZzwvc3Bhbj48L3A+ PC9kaXY+PC9kaXY+PHAgIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwvcD48L2Rpdj48L2Rpdj48 ZGl2ID48cCAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnIgPlRMUyBtYWlsaW5nIGxpc3Q8YnIgPjxhICBocmVmPSJtYWls dG86VExTQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+VExTQGlldGYub3JnPC9hPjxiciA+PGEg IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHM8L2E+PC9w PjwvZGl2PjwvZGl2PjwvZGl2PjxwICBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBUTFMgbWFpbGluZyBsaXN0IFRMU0BpZXRm Lm9yZyA8YSAgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rs czwvYT4gPC9wPjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2ID48YnIgPjwvZGl2PjwvZGl2Pg== ------=ALIBOUNDARY_896_4a039940_5d5a8d43_19b8900-- From nobody Mon Aug 19 05:20:26 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 732261200CE for ; Mon, 19 Aug 2019 05:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id veOY9E1OQNeG for ; Mon, 19 Aug 2019 05:20:21 -0700 (PDT) Received: from out0-145.mail.aliyun.com (out0-145.mail.aliyun.com [140.205.0.145]) (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 40618120020 for ; Mon, 19 Aug 2019 05:20:19 -0700 (PDT) X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R671e4; CH=green; DM=||false|; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03307; MF=kaishen.yy@antfin.com; NM=1; PH=DS; RN=7; SR=0; TI=SMTPD_---.FEaGCre_1566217214; Received: from 10.15.232.120(mailfrom:kaishen.yy@antfin.com fp:SMTPD_---.FEaGCre_1566217214) by smtp.aliyun-inc.com(127.0.0.1); Mon, 19 Aug 2019 20:20:14 +0800 From: Paul Yang Message-Id: <83CBB97A-A3D3-48AC-9B1B-35557EE4CC95@antfin.com> Content-Type: multipart/signed; boundary="Apple-Mail=_0A4904A4-62C2-490A-A4D7-F4534A8D9500"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 19 Aug 2019 20:20:13 +0800 In-Reply-To: <20a27f61-98cf-4b2c-b6a8-e25aabd56099.kepeng.lkp@alibaba-inc.com> Cc: "tls@ietf.org" To: Kepeng Li , sean+ietf , joe , "Blumenthal, Uri - 0553 - MITLL" , "rstruik.ext" , caw References: <20a27f61-98cf-4b2c-b6a8-e25aabd56099.kepeng.lkp@alibaba-inc.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] (offline) Re: Draft for SM cipher suites used in TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Aug 2019 12:20:24 -0000 --Apple-Mail=_0A4904A4-62C2-490A-A4D7-F4534A8D9500 Content-Type: multipart/alternative; boundary="Apple-Mail=_F87C758C-2111-46A1-8E91-0B133C781E4F" --Apple-Mail=_F87C758C-2111-46A1-8E91-0B133C781E4F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 A side note: we will also upload the Markdown file of this draft into = the same git repository at https://github.com/alipay/tls13-sm-spec = later to make it a totally = public involved progress. > On Aug 19, 2019, at 7:51 PM, Kepeng Li = wrote: >=20 > Currently, we uploaded some of the referenced documents here: > https://github.com/alipay/tls13-sm-spec = >=20 > @Rene, Parts 1 and 3 can be found in the link above. >=20 > Hope it helps. >=20 > Thanks, >=20 > Kind Regards > Kepeng >=20 > ------------------------------------------------------------------ > =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A=E6=9D=8E=E5=85=8B=E9=B9=8F(=E6=98=93= =E6=B7=B1) > > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4=EF=BC=9A2019=E5=B9=B48=E6=9C=8819=E6= =97=A5(=E6=98=9F=E6=9C=9F=E4=B8=80) 17:38 > =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9Asean+ietf >; joe >; caw > > =E6=8A=84=E3=80=80=E9=80=81=EF=BC=9Atls@ietf.org = >; "Blumenthal, Uri - 0553 - MITLL" = >; Paul Yang = > > =E4=B8=BB=E3=80=80=E9=A2=98=EF=BC=9ARe: [TLS] (offline) Re: Draft for = SM cipher suites used in TLS1.3 >=20 > Hi WG chairs, >=20 > Can we place the referenced documents in the TLS WG GitHub? > https://github.com/tlswg >=20 > According to the discussion below, this can help people to read and = understand the referenced specifications. >=20 > Thanks, >=20 > Kind Regards > Kepeng >=20 > =E5=8F=91=E4=BB=B6=E4=BA=BA: TLS > =E4=BB=A3=E8=A1=A8 "Blumenthal, Uri - = 0553 - MITLL" > > =E6=97=A5=E6=9C=9F: 2019=E5=B9=B48=E6=9C=8818=E6=97=A5 =E6=98=9F=E6=9C=9F= =E6=97=A5 22:08 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Paul Yang = > > =E6=8A=84=E9=80=81: "tls@ietf.org " > > =E4=B8=BB=E9=A2=98: Re: [TLS] (offline) Re: Draft for SM cipher suites = used in TLS1.3 >=20 > IMHO, placing the documents on GitHub would be perfect, and quite = sufficient. >=20 > Please make sure to post the name of the repo here. ;/) >=20 > I leave it to others to decide whether they'd want copies of today PDF = files sent to the mailing list directly. >=20 > Regards, > Uri >=20 > Sent from my iPhone >=20 > On Aug 17, 2019, at 01:03, Paul Yang = > wrote: >=20 > Good points. >=20 > The good news is that we have found some English PDFs of SM2, = including the missing part 1 and part 3. Will continue to find English = translations of other SM standards mentioned in the draft. >=20 > So, if we host a free website, say on Github or so, to provide those = docs, is it convenient for you guys? Or should we just drop the PDF = files to this mailing list as attachments? >=20 >=20 > On Aug 16, 2019, at 10:58 PM, Rene Struik > wrote: >=20 > Arguably, "national" crypto specifications garnish more stature if = these are made available to the pubic by that standard-setting body = itself (who, thereby, acts as its authoritative source), without = deference to a third party (that may, independently from the originator, = enforce document control [e.g., by effectuating technical changes or = enforcing controlled dissemination]). >=20 > Since your draft introducing SM cipher suites with TLS1.3 appeals to = the authority of a standard-setting authority, easy availability of the = full and accredited technical documentation to the IETF community helps = in scrutiny and, e.g., evaluating claims in the security considerations = section. >=20 > On 8/16/2019 3:06 AM, Kepeng Li wrote: > Hi Rene and all, >=20 > > Since the ISO documents are not available to the general > > public without payment, it would be helpful to have a freely = available > > document (in English) from an authoritative source. Having such a > > reference available would be helpful to the IETF community (and > > researchers). > About the references to ISO documens, I think it is a general issue = for IETF drafts. >=20 > How does the other IETF drafts make the references to ISO documents? = ISO documents are often referenced by IETF drafts. >=20 > Thanks, >=20 > Kind Regards > Kepeng > = =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 > Re: [TLS] Draft for SM cipher suites used in TLS1.3 >=20 > Rene Struik > = Thu, 15 August 2019 15:34 UTCShow header = > Hi Paul: >=20 > I tried and look up the documents GMT.0009-2012 and GBT.32918.5-2016 = on > the (non-secured) websites you referenced, but only found Chinese > versions (and Chinese website navigation panels [pardon my poor = language > skills here]). Since the ISO documents are not available to the = general > public without payment, it would be helpful to have a freely available > document (in English) from an authoritative source. Having such a > reference available would be helpful to the IETF community (and > researchers). Please note that BSI provides its specifications in = German > and English, so as to foster use/study by the community. If the = Chinese > national algorithms would be available in similar form, this would = serve > a similar purpose. >=20 > FYI - I am interested in full details and some time last year I tried = to > download specs, but only Parts 2, 4, and 5 were available [1], [2], = [3], > not Parts 1 and 3. >=20 > Best regards, Rene >=20 > [1] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC - > Part 5 - Parameter Definition (SEMB, July 24, 2018) > [2] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC - > Part 2 - Digital Signature Algorithm (SEMB, July 24, 2018) > [3] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC - > Part 4 - Public Key Encryption Algorithm (SEMB, July 24, 2018) >=20 > On 8/15/2019 10:16 AM, Paul Yang wrote: > > Hi all, > > > > I have submitted a new internet draft to introduce the SM cipher > > suites into TLS 1.3 protocol. > > > > https://tools.ietf.org/html/draft-yang-tls-tls13-sm-suites-00 = > > > > SM cryptographic algorithms are originally a set of Chinese national > > algorithms and now have been (or being) accepted by ISO as > > international standards, including SM2 signature algorithm, SM3 hash > > function and SM4 block cipher. These algorithms have already been > > supported some time ago by several widely used open source > > cryptographic libraries including OpenSSL, BouncyCastle, Botan, etc. > > > > Considering TLS1.3 is being gradually adopted in China's internet > > industry, it's important to have a normative definition on how to = use > > the SM algorithms with TLS1.3, especially for the mobile internet > > scenario. Ant Financial is the company who develops the market = leading > > mobile app 'Alipay' and supports payment services for Alibaba > > e-commerce business. We highly are depending on the new TLS1.3 > > protocol for both performance and security purposes. We expect to = have > > more deployment of TLS1.3 capable applications in China's internet > > industry by this standardization attempts. > > > > It's very appreciated to have comments from the IETF TLS list :-) > > > > Many thanks! > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls = >=20 >=20 > -- > email: rstruik.ext@gmail.com | Skype: = rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls = >=20 >=20 > Regards, >=20 > Paul Yang >=20 > _______________________________________________ > 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 = Regards, Paul Yang --Apple-Mail=_F87C758C-2111-46A1-8E91-0B133C781E4F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 A = side note: we will also upload the Markdown file of this draft into the = same git repository at https://github.com/alipay/tls13-sm-spec later to = make it a totally public involved progress.

On Aug = 19, 2019, at 7:51 PM, Kepeng Li <kepeng.lkp@alibaba-inc.com> wrote:

Currently, we = uploaded some of the referenced documents here:
https://github.com/alipay/tls13-sm-spec

@Rene, Parts = 1 and 3 can be found in the link above.

Hope it helps.

Thanks,

Kind Regards
Kepeng

---------------------------------------------------------------= ---
=E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A=E6=9D=8E=E5=85=8B=E9=B9=8F= (=E6=98=93=E6=B7=B1) <kepeng.lkp@antfin.com>
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4=EF=BC=9A2019=E5=B9=B48=E6=9C= =8819=E6=97=A5(=E6=98=9F=E6=9C=9F=E4=B8=80) 17:38
=E6=94=B6=E4=BB=B6=E4= =BA=BA=EF=BC=9Asean+ietf <sean+ietf@sn3rd.com>; joe <joe@salowey.net>; caw <caw@heapingbits.net>
=E6=8A=84=E3=80=80=E9=80=81=EF=BC=9A<= a href=3D"mailto:tls@ietf.org" style=3D"color: purple; text-decoration: = underline;" class=3D"">tls@ietf.org <tls@ietf.org>; "Blumenthal, Uri - 0553 - = MITLL" <uri@ll.mit.edu>; Paul = Yang <kaishen.yy=3D40alipay.com@dmarc.ietf.org>
=E4=B8=BB=E3=80=80=E9= =A2=98=EF=BC=9ARe: [TLS] (offline) Re: Draft for SM cipher suites used = in TLS1.3

Hi WG = chairs,

 

Can we = place the referenced documents in the TLS WG GitHub?
https://github.com/tlswg

 

According = to the discussion below, this can help people to read and understand the = referenced specifications.

 

Thanks,

 

Kind = Regards
Kepeng 

 

=E5=8F=91=E4=BB=B6=E4=BA=BA: TLS <tls-bounces@ietf.org> =E4=BB=A3=E8=A1=A8 "Blumenthal, Uri - 0553 - = MITLL" <uri@ll.mit.edu>
=E6=97=A5=E6=9C=9F: 2019=E5=B9=B48=E6=9C=8818=E6=97=A5 =E6=98=9F=E6=9C=9F=E6=97=A5 22:08
=E6=94=B6=E4=BB=B6=E4=BA=BA= : Paul Yang <kaishen.yy=3D40alipay.com@dmarc.ietf.org>
=E6=8A=84=E9=80=81: "tls@ietf.org" <tls@ietf.org>
=E4=B8=BB=E9=A2=98: Re: [TLS] = (offline) Re: Draft for SM cipher suites used in = TLS1.3

 

IMHO, = placing the documents on GitHub would be perfect, and quite = sufficient. 

 

Please make sure to post the name of the repo here. = ;/)

 

I leave it to others = to decide whether they'd want copies of today PDF files sent to the = mailing list directly.

Regards,
Uri

 

Sent from my iPhone


On Aug 17, 2019, at = 01:03, Paul Yang <kaishen.yy=3D40alipay.com@dmarc.ietf.org> = wrote:

Good = points.

 

The good news is that we = have found some English PDFs of SM2, including the missing part 1 and = part 3. Will continue to find English translations of other SM standards = mentioned in the draft.

 

So, if we host a free website, say on Github or so, to = provide those docs, is it convenient for you guys? Or should we just = drop the   PDF files to this mailing list as attachments?


On Aug 16, = 2019, at 10:58 PM, Rene Struik <rstruik.ext@gmail.com> wrote:

 

Arguably, "national" = crypto specifications garnish more stature if these are made available = to the pubic by that standard-setting body itself (who, thereby, acts as = its authoritative source), without deference to a third party (that may, = independently from the originator, enforce document control [e.g., by = effectuating technical changes or enforcing controlled = dissemination]).

 

Since your draft introducing SM cipher suites with TLS1.3 = appeals to the authority of a standard-setting authority, easy = availability of the full and accredited technical documentation to the = IETF community helps in scrutiny and, e.g., evaluating claims in the = security considerations section.

 

On 8/16/2019 3:06 AM, Kepeng Li wrote:
Hi Rene and all,

 

> Since the ISO documents are not available to the general =

> public without =
payment, it would be helpful to have a freely available =

> document (in =
English) from an authoritative source. Having such a 
> reference available would be helpful to the =
IETF community (and 
> researchers).
About the references = to ISO documens, I think it is a general issue for IETF = drafts.

 

How does the other = IETF drafts make the references to ISO documents? ISO documents are = often referenced by IETF drafts.

 

Thanks,

 

Kind Regards
Kepeng
=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94

Re: [TLS] Draft for SM = cipher suites used in TLS1.3

Rene Struik <rstruik.ext@gmail.com> Thu, 15 August 2019 = 15:34 UTCShow header

Hi Paul:
 
I tried =
and look up the documents GMT.0009-2012 and GBT.32918.5-2016 on =

the (non-secured) websites you =
referenced, but only found Chinese 
versions (and Chinese website navigation panels [pardon my =
poor language 
skills =
here]). Since the ISO documents are not available to the general =

public without payment, it would be =
helpful to have a freely available 
document (in English) from an authoritative source. Having =
such a 
reference available would be helpful =
to the IETF community (and 
researchers). Please note that BSI provides its =
specifications in German 
and =
English, so as to foster use/study by the community. If the Chinese =

national algorithms would be =
available in similar form, this would serve 
a similar purpose.
 
FYI - I am =
interested in full details and some time last year I tried to =

download specs, but only Parts 2, 4, =
and 5 were available [1], [2], [3], 
not Parts 1 and 3.
 
Best =
regards, Rene
 
[1] China =
ECC - Public Key Cryptographic Algorithm SM2 Based on ECC - =

Part 5 - Parameter Definition (SEMB, =
July 24, 2018)
[2] China =
ECC - Public Key Cryptographic Algorithm SM2 Based on ECC - =

Part 2 - Digital Signature Algorithm =
(SEMB, July 24, 2018)
[3] China =
ECC - Public Key Cryptographic Algorithm SM2 Based on ECC - =

Part 4 - Public Key Encryption =
Algorithm (SEMB, July 24, 2018)
 
On =
8/15/2019 10:16 AM, Paul Yang wrote:
> Hi all,
> 
> I =
have submitted a new internet draft to introduce the SM cipher =

> suites into TLS 1.3 =
protocol.
> 
> https://tools.ietf.org/html/draft-yang-tls-tls13-sm-suites-00
> 
> SM =
cryptographic algorithms are originally a set of Chinese national =

> algorithms and now have been =
(or being) accepted by ISO as 
> =
international standards, including SM2 signature algorithm, SM3 hash =

> function and SM4 block cipher. =
These algorithms have already been 
> supported some time ago by several widely used open =
source 
> cryptographic libraries =
including OpenSSL, BouncyCastle, Botan, etc.
> 
> =
Considering TLS1.3 is being gradually adopted in China's internet =

> industry, it's important to =
have a normative definition on how to use 
> the SM algorithms with TLS1.3, especially for the mobile =
internet 
> =
scenario. Ant Financial is the company who develops the market leading =

> mobile app 'Alipay' and =
supports payment services for Alibaba 
> e-commerce business. We highly are depending on the new =
TLS1.3 
> protocol for both performance =
and security purposes. We expect to have 
> more deployment of TLS1.3 capable applications in =
China's internet 
> =
industry by this standardization attempts.
> 
> It's =
very appreciated to have comments from the IETF TLS list =
:-)
> 
> Many thanks!
> 
> =
_______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

 

 

-- =

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

 


Regards,

 

Paul = Yang

 

_______________________________________________
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


Regards,

Paul Yang

= --Apple-Mail=_F87C758C-2111-46A1-8E91-0B133C781E4F-- --Apple-Mail=_0A4904A4-62C2-490A-A4D7-F4534A8D9500 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEndC1x/yVcklg1DZ15HtIVEj/IsoFAl1ak/0ACgkQ5HtIVEj/ IsrCuw//ZpdxXqXHy5+AyI3hUjLucGINFZ6XMQqsFgVz809Vu9Ib1nHW129UGuCy YsxJLCQYR62Iu5Co20c+1evbJjFPZpfioMLZyhAxlBGT0FAB+PFxBMyoVqAwSPg6 Uo/hNd6/tiYvfTT4fKM6IkzERYHpFv9TqLfd9XchDt787HCGfq3P3f0GoZ7LdOUW O0ZApPtd9aF3MAYsamA32QnXzBEY3tB+mqJF8pnJ4U4DmwHix6VfnpbTOY3kd7Ro PqdHLOVLP97KPPro4OJISMf9KT5E+76GYZxf5bHGYjKF2gAk2HfG6r5LBXLfYeHZ qtaqSfoMY4NIP3hFJ6k4dR3b96HMSJNjDi6BuCKN0FJafgo1ZyzTVge0gCuVlnm9 HJFrskhnyuql5v4y23pl3CS9DoZ9I5MA0iCxMNkbeWPxRa/JycHp5V1TBx2Ekm4h OuP+tcGaq0FWCdJAosaut5OSkPqHL1PqkOkMX0BJpvObSub+T+QAZm8X3VRzJC4i 7T4n/7ij9mcZmMZtyCKqdVuA3XnnNIy7MPIDRmmJ9mPFd6eyLqtFK4AU8p5WX+2+ al+c2LyiHViXkyf3yLdzcpVhFcpCdwUH9St+Ii8QF2b+1i7j903+WCyLg7AzUL6+ aUMYspm511E3qaJRC0S0ygXfiXyphlg6BZKsi7I86vthbfrN/Eo= =x/Jf -----END PGP SIGNATURE----- --Apple-Mail=_0A4904A4-62C2-490A-A4D7-F4534A8D9500-- From nobody Mon Aug 19 06:59:14 2019 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 E4FA91200CE; Mon, 19 Aug 2019 06:59:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Sender: CC: draft-ietf-tls-sni-encryption@ietf.org, tls-chairs@ietf.org, Sean Turner , Joseph Salowey , kaduk@mit.edu, joe@salowey.net, tls@ietf.org Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <156622314492.19744.12076098510309117385.idtracker@ietfa.amsl.com> Date: Mon, 19 Aug 2019 06:59:04 -0700 Archived-At: Subject: [TLS] Last Call: (Issues and Requirements for SNI Encryption in TLS) to Informational RFC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list for 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 Aug 2019 13:59:05 -0000 The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Issues and Requirements for SNI Encryption in TLS' as Informational RFC 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 2019-09-02. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This draft describes the general problem of encrypting the Server Name Identification (SNI) TLS parameter. The proposed solutions hide a Hidden Service behind a fronting service, only disclosing the SNI of the fronting service to external observers. The draft lists known attacks against SNI encryption, discusses the current "co-tenancy fronting" solution, and presents requirements for future TLS layer solutions. In practice, it may well be that no solution can meet every requirement, and that practical solutions will have to make some compromises. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Aug 19 07:32:33 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1556120142 for ; Mon, 19 Aug 2019 07:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alipay.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzRwmDuWVx_R for ; Mon, 19 Aug 2019 07:32:28 -0700 (PDT) Received: from out0-144.mail.aliyun.com (out0-144.mail.aliyun.com [140.205.0.144]) (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 75B4312016E for ; Mon, 19 Aug 2019 07:32:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alipay.com; s=default; t=1566225144; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:To; bh=oeI7du1Z0+2oIzkRgad00pmr/BqbLgzGW7SF5mLLsCA=; b=Gqsa7WDiexnzuk5AgJ9oeW7a71bJ/pSN9jPhIGaR6t6a216bbqGdOKy0FxVTRdtyy7Mmj+AkltChkSYp94+ZyMyJmCeTIM94OeHS58boySvpHQy00fuKKPEUsX/BPKnyK/SPus04mG9k7+9ZBwn2qXQ/Zzto3t6zBRqff+22/7g= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R631e4; CH=green; DM=||false|; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03303; MF=kaishen.yy@alipay.com; NM=1; PH=DS; RN=3; SR=0; TI=SMTPD_---.FEcqJ.O_1566225142; Received: from 10.15.232.120(mailfrom:kaishen.yy@alipay.com fp:SMTPD_---.FEcqJ.O_1566225142) by smtp.aliyun-inc.com(127.0.0.1); Mon, 19 Aug 2019 22:32:22 +0800 From: Paul Yang Message-Id: <57CCBFBA-328E-470E-B3FA-B1088ED2971F@alipay.com> Content-Type: multipart/signed; boundary="Apple-Mail=_7792A6F8-C9BF-414F-ABFB-3E3054393E85"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 19 Aug 2019 22:32:21 +0800 In-Reply-To: Cc: Rich Salz , "tls@ietf.org" To: Eric Rescorla References: <3350587b-f768-425f-a759-3ed7ce2e6b27.kepeng.lkp@alibaba-inc.com> <1e07a7cc-b316-6a1d-6f59-b352ffbd74b8@gmail.com> <8EE550E4-20E6-4D83-89E6-A43F63E3A593@akamai.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] (offline) Re: Draft for SM cipher suites used in TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Aug 2019 14:32:31 -0000 --Apple-Mail=_7792A6F8-C9BF-414F-ABFB-3E3054393E85 Content-Type: multipart/alternative; boundary="Apple-Mail=_8FAD9A1D-CD3E-4857-921C-51AFAA30A26A" --Apple-Mail=_8FAD9A1D-CD3E-4857-921C-51AFAA30A26A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 18, 2019, at 9:47 PM, Eric Rescorla wrote: >=20 > The intent of the "Specification Required" requirement for = registration is that sufficient public information be available to allow = an interoperable implementation. Specifically, the text says: >=20 > https://tools.ietf.org/html/rfc8126#section-4.6 = >=20 > For the Specification Required policy, review and approval by a > designated expert (see Section 5) is required, and the values and > their meanings must be documented in a permanent and readily > available public specification, in sufficient detail so that > interoperability between independent implementations is possible. > This policy is the same as Expert Review, with the additional > requirement of a formal public specification. In addition to the > normal review of such a request, the designated expert will review > the public specification and evaluate whether it is sufficiently > stable and permanent, and sufficiently clear and technically sound = to > allow interoperable implementations. >=20 > I don't think that a for-pay specification meets that threshold, = though I'm > not aware of any IETF-wide policy on that (although I may just have = missed > it). Makes sense, so we added new public documents now ;-) Just one question, do implementations count as the =E2=80=98public = specification=E2=80=99? For instance, something like the crypto = libraries which support the algorithms with full documentation = describing it... >=20 > In the absence of that, it would as stated above, be on the Expert to = determine > the standard. >=20 > -Ekr >=20 >=20 >=20 >=20 >=20 > On Sun, Aug 18, 2019 at 2:52 PM Salz, Rich > wrote: >=20 > =C3=98 This is one example: = https://www.rfc-editor.org/rfc/rfc8428.txt = >=20 > Thank you. >=20 > That is a bit different since RNC isn=E2=80=99t needed to implement = the RFC, and a web search for =E2=80=9Crelaxng=E2=80=9D finds thousands = of references. The SM2, etc., situation is different because you cannot = implement the cipher without the definition of it. >=20 > _______________________________________________ > 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 Regards, Paul Yang --Apple-Mail=_8FAD9A1D-CD3E-4857-921C-51AFAA30A26A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Aug 18, 2019, at 9:47 PM, Eric Rescorla <ekr@rtfm.com> = wrote:

The intent of the "Specification = Required" requirement for registration is that sufficient public = information be available to allow an interoperable implementation. = Specifically, the text says:

https://tools.ietf.org/html/rfc8126#section-4.6

   For the = Specification Required policy, review and approval by a
   designated expert (see Section 5) is required, = and the values and
   their meanings must be = documented in a permanent and readily
  =  available public specification, in sufficient detail so that
   interoperability between independent = implementations is possible.
   This policy is = the same as Expert Review, with the additional
  =  requirement of a formal public specification.  In addition to = the
   normal review of such a request, the = designated expert will review
   the public = specification and evaluate whether it is sufficiently
 =  stable and permanent, and sufficiently clear and technically = sound to
   allow interoperable = implementations.

I don't think that a for-pay specification meets that = threshold, though I'm
not aware of any IETF-wide = policy on that (although I may just have missed
it).

Makes sense, so we added new public documents now = ;-)

Just one question, do = implementations count as the =E2=80=98public specification=E2=80=99? For = instance, something like the crypto libraries which support the = algorithms with full documentation describing it...


In the absence of that, it would as stated above, be on the = Expert to determine
the standard.

-Ekr





On Sun, Aug = 18, 2019 at 2:52 PM Salz, Rich <rsalz@akamai.com> wrote:
 
=C3=98  This is one example: https://www.rfc-editor.org/rfc/rfc8428.txt
 
Thank you.
 
That is a bit different since RNC isn=E2=80=99t needed to =
implement the RFC, and a web search for =E2=80=9Crelaxng=E2=80=9D finds =
thousands of references.  The SM2, etc., situation is different =
because you cannot implement the cipher without the definition of it.
 
_______________________________________________
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


Regards,

Paul Yang

= --Apple-Mail=_8FAD9A1D-CD3E-4857-921C-51AFAA30A26A-- --Apple-Mail=_7792A6F8-C9BF-414F-ABFB-3E3054393E85 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEndC1x/yVcklg1DZ15HtIVEj/IsoFAl1asvUACgkQ5HtIVEj/ Isr1EQ//TNjIjYRW6TXGcxEdbQrdeaUqaC7dq7l7P5hytwRm3338/EJPTDCTeeFH d/6yRLB9xjafCZvQfHHUIKKlk+vvCnQX7+RQ+HwnGvGLoVWQbegNyfpPa51T1Oh1 12YBOblY/uIGuxiEPKxMNVuMbU3EvsvD3PwBpzO4rxTQ7tDfEK73XmuiJZzDHg0D K/PUlWAVPUKLdOtGYPWoqjwbMWr+kAtdl4sNMn7OR8iM+1lJv97ssdD683aGoMgo YXGlhC/WLvAKwFScWjck1F9NW5Br5KCxvJQF7iV4V7e/PFi0v5iW3Xlu6FOaH4UH Z3bWphnpJzFqE+WL/Dn/HPlOgIrPLcQJSPV3IsTeenGdmLXSjqm96uOua5F2Z76w DvPWaOGvPTQ2W0xwulpHJwenNrpoPSBKbDllXhz3B7h6sDQiuYet5NPD1GAoUsy3 HgC35ZQAs7+Oyj2TiNRvqJBiIsF+2YM8D1ZT7EAI++D+7DR6gGCJQCddrPPtVTaw 0z987Iba6TTQBM0w6nAIYLPBd94JLdKWZBIWhpmlnY4FSvrFDl6iOZQ4ZDzi+wSU oREXOoiEPCNuZZ8ncfFl9bsx6UikuxHY9cnzFpLZHcItWjtyVxQkGEiZ/rm0YCX0 pJ5MFghxH9uUzslJESK+JatLvpZbBpeGSsZH0k8MDptNaC7pBdQ= =RZ0W -----END PGP SIGNATURE----- --Apple-Mail=_7792A6F8-C9BF-414F-ABFB-3E3054393E85-- From nobody Mon Aug 19 07:57:33 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8803A120818 for ; Mon, 19 Aug 2019 07:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.195 X-Spam-Level: X-Spam-Status: No, score=-4.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFK1y2Al9Cga for ; Mon, 19 Aug 2019 07:57:24 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) (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 2DC7C1207FF for ; Mon, 19 Aug 2019 07:57:23 -0700 (PDT) Received: from LLE2K16-MBX02.mitll.ad.local (LLE2K16-MBX02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTPS id x7JEvErL019732; Mon, 19 Aug 2019 10:57:14 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: Paul Yang , Kepeng Li CC: "tls@ietf.org" Thread-Topic: [TLS] (offline) Re: Draft for SM cipher suites used in TLS1.3 Thread-Index: AQHVVoiRgPOVgkNCX0KUphhkA4o1JKcCj7IA Date: Mon, 19 Aug 2019 14:57:13 +0000 Message-ID: References: <20a27f61-98cf-4b2c-b6a8-e25aabd56099.kepeng.lkp@alibaba-inc.com> <83CBB97A-A3D3-48AC-9B1B-35557EE4CC95@antfin.com> In-Reply-To: <83CBB97A-A3D3-48AC-9B1B-35557EE4CC95@antfin.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1b.0.190715 x-originating-ip: [172.25.1.85] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3649057033_738423711" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-19_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908190168 Archived-At: Subject: Re: [TLS] (offline) Re: Draft for SM cipher suites used in TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Aug 2019 14:57:30 -0000 --B_3649057033_738423711 Content-type: multipart/alternative; boundary="B_3649057032_645832155" --B_3649057032_645832155 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable >=C2=A0 A side note: we will also upload the Markdown file of this draft into t= he same git=20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0 repository at https://github.com/alipay/tls13-sm-spec l= ater to make it a totally =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 public involved progress. =20 I think this is exactly what was needed/asked-for. Thank you! On Aug 19, 2019, at 7:51 PM, Kepeng Li wrote: =20 Currently, we uploaded some of the referenced documents here: https://github.com/alipay/tls13-sm-spec =20 @Rene, Parts 1 and 3 can be found in the link above. =20 Hope it helps. =20 Thanks, =20 Kind Regards Kepeng =20 ------------------------------------------------------------------ =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A=E6=9D=8E=E5=85=8B=E9=B9=8F(=E6=98=93=E6=B7=B1) =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4=EF=BC=9A2019=E5=B9=B48=E6=9C=8819=E6=97=A5(=E6=98=9F=E6=9C=9F=E4=B8=80) 17:38 =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9Asean+ietf ; joe ; caw =E6=8A=84=E3=80=80=E9=80=81=EF=BC=9Atls@ietf.org ; "Blumenthal, Uri - 0553 - MITLL" <= uri@ll.mit.edu>; Paul Yang =E4=B8=BB=E3=80=80=E9=A2=98=EF=BC=9ARe: [TLS] (offline) Re: Draft for SM cipher suites used in TLS1= .3 =20 Hi WG chairs, =20 Can we place the referenced documents in the TLS WG GitHub? https://github.com/tlswg =20 According to the discussion below, this can help people to read and underst= and the referenced specifications. =20 Thanks, =20 Kind Regards Kepeng=20 =20 =E5=8F=91=E4=BB=B6=E4=BA=BA: TLS =E4=BB=A3=E8=A1=A8 "Blumenthal, Uri - 0553 - MITL= L" =E6=97=A5=E6=9C=9F: 2019=E5=B9=B48=E6=9C=8818=E6=97=A5 =E6=98=9F=E6=9C=9F=E6=97=A5 22:08 =E6=94=B6=E4=BB=B6=E4=BA=BA: Paul Yang =E6=8A=84=E9=80=81: "tls@ietf.org" =E4=B8=BB=E9=A2=98: Re: [TLS] (offline) Re: Draft for SM cipher suites used in TLS1.3 =20 IMHO, placing the documents on GitHub would be perfect, and quite sufficien= t.=20 =20 Please make sure to post the name of the repo here. ;/) =20 I leave it to others to decide whether they'd want copies of today PDF file= s sent to the mailing list directly. Regards, Uri =20 Sent from my iPhone On Aug 17, 2019, at 01:03, Paul Yang wrote: Good points. =20 The good news is that we have found some English PDFs of SM2, including the= missing part 1 and part 3. Will continue to find English translations of ot= her SM standards mentioned in the draft. =20 So, if we host a free website, say on Github or so, to provide those docs, = is it convenient for you guys? Or should we just drop the PDF files to thi= s mailing list as attachments? =20 On Aug 16, 2019, at 10:58 PM, Rene Struik wrote: =20 Arguably, "national" crypto specifications garnish more stature if these ar= e made available to the pubic by that standard-setting body itself (who, the= reby, acts as its authoritative source), without deference to a third party = (that may, independently from the originator, enforce document control [e.g.= , by effectuating technical changes or enforcing controlled dissemination]). =20 Since your draft introducing SM cipher suites with TLS1.3 appeals to the au= thority of a standard-setting authority, easy availability of the full and a= ccredited technical documentation to the IETF community helps in scrutiny an= d, e.g., evaluating claims in the security considerations section. =20 On 8/16/2019 3:06 AM, Kepeng Li wrote: Hi Rene and all, =20 > Since the ISO documents are not available to the general=20 > public without payment, it would be helpful to have a freely available=20 > document (in English) from an authoritative source. Having such a=20 > reference available would be helpful to the IETF community (and=20 > researchers). About the references to ISO documens, I think it is a general issue for IET= F drafts. =20 How does the other IETF drafts make the references to ISO documents? ISO do= cuments are often referenced by IETF drafts. =20 Thanks, =20 Kind Regards Kepeng =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 Re: [TLS] Draft for SM cipher suites used in TLS1.3 Rene Struik Thu, 15 August 2019 15:34 UTCShow heade= r Hi Paul: =20 I tried and look up the documents GMT.0009-2012 and GBT.32918.5-2016 on=20 the (non-secured) websites you referenced, but only found Chinese=20 versions (and Chinese website navigation panels [pardon my poor language=20 skills here]). Since the ISO documents are not available to the general=20 public without payment, it would be helpful to have a freely available=20 document (in English) from an authoritative source. Having such a=20 reference available would be helpful to the IETF community (and=20 researchers). Please note that BSI provides its specifications in German=20 and English, so as to foster use/study by the community. If the Chinese=20 national algorithms would be available in similar form, this would serve=20 a similar purpose. =20 FYI - I am interested in full details and some time last year I tried to=20 download specs, but only Parts 2, 4, and 5 were available [1], [2], [3],=20 not Parts 1 and 3. =20 Best regards, Rene =20 [1] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC -=20 Part 5 - Parameter Definition (SEMB, July 24, 2018) [2] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC -=20 Part 2 - Digital Signature Algorithm (SEMB, July 24, 2018) [3] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC -=20 Part 4 - Public Key Encryption Algorithm (SEMB, July 24, 2018) =20 On 8/15/2019 10:16 AM, Paul Yang wrote: > Hi all, >=20 > I have submitted a new internet draft to introduce the SM cipher=20 > suites into TLS 1.3 protocol. >=20 > https://tools.ietf.org/html/draft-yang-tls-tls13-sm-suites-00 >=20 > SM cryptographic algorithms are originally a set of Chinese national=20 > algorithms and now have been (or being) accepted by ISO as=20 > international standards, including SM2 signature algorithm, SM3 hash=20 > function and SM4 block cipher. These algorithms have already been=20 > supported some time ago by several widely used open source=20 > cryptographic libraries including OpenSSL, BouncyCastle, Botan, etc. >=20 > Considering TLS1.3 is being gradually adopted in China's internet=20 > industry, it's important to have a normative definition on how to use=20 > the SM algorithms with TLS1.3, especially for the mobile internet=20 > scenario. Ant Financial is the company who develops the market leading=20 > mobile app 'Alipay' and supports payment services for Alibaba=20 > e-commerce business. We highly are depending on the new TLS1.3=20 > protocol for both performance and security purposes. We expect to have=20 > more deployment of TLS1.3 capable applications in China's internet=20 > industry by this standardization attempts. >=20 > It's very appreciated to have comments from the IETF TLS list :-) >=20 > Many thanks! >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls =20 =20 --=20 email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls =20 Regards, =20 Paul Yang =20 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.o= rg https://www.ietf.org/mailman/listinfo/tls =20 Regards, =20 Paul Yang --B_3649057032_645832155 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

>=C2=A0 A side n= ote: we will also upload the Markdown file of this draft into the same git <= o:p>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0>=C2=A0 repository at h= ttps://github.com/alipay/tls13-sm-spec later to make it a totally

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 >=C2=A0 public involved progress.

&nb= sp;

I think this is exactly what was needed/aske= d-for. Thank you!



<= /p>

On Aug 19, 2019, at 7:51 PM, Kepeng Li <= kepeng.lkp@alibaba-inc.com&g= t; wrote:

 

Currently, w= e uploaded some of the referenced documents here:

https://github.com/alipay/tls13-sm-spec

<= /div>

 

@Rene, Parts 1 and 3= can be found in the link above.

<= o:p> 

Hope it = helps.=

 

=

Thanks,

 

Kind = Regards

Kepeng

<= p class=3DMsoNormal style=3D'margin-left:.5in'> 

--------------------------= ----------------------------------------

=E5= =8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A=E6=9D=8E= =E5=85=8B=E9=B9=8F(=E6=98=93=E6=B7=B1) <kepeng.lkp@antfin.com>= ;

=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B42= 019=E5=B9=B4<= span style=3D'font-size:10.5pt;font-family:"Tahoma",sans-serif'>8=E6=9C=8819=E6=97=A5(=E6=98=9F=E6=9C=9F=E4=B8=80) 17:38

=E6=94=B6=E4=BB=B6=E4=BA=BA= =EF=BC=9Asea= n+ietf <s= ean+ietf@sn3rd.com>; joe <= joe@salowey.net>; caw <caw@heapingbits.net>

=E6=8A=84=E3=80=80=E9=80=81=EF=BC=9Atls@ietf.org <tls@ietf.org>; "Blumenthal, Uri - 0553 = - MITLL" <uri@ll.mit.edu>; Paul Yang <kaishen.yy=3D40alipay.com= @dmarc.ietf.org>

=E4=B8=BB=E3=80=80<= /span>=E9=A2=98=EF=BC=9ARe: [TLS] (offline) Re: Draft for= SM cipher suites used in TLS1.3

&nb= sp;

<= span style=3D'font-size:14.5pt;font-family:DengXian'>Hi WG chairs,

 

<= span style=3D'font-size:14.5pt;font-family:DengXian'>Can we place the referenc= ed documents in the TLS WG GitHub?

 

According to the discussion below, this can help people to r= ead and understand the referenced specifications.

 =

Thanks,

&nbs= p;

Kind Regards

= Kepeng 

 

=E5=8F=91=E4=BB=B6=E4=BA=BA: TLS <tls-bounces@ietf.org> =E4=BB=A3=E8=A1=A8 &q= uot;Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
=E6=97=A5=E6=9C=9F: <= /b>2019=E5=B9=B48=E6=9C=8818=E6=97=A5=  =E6=98=9F=E6=9C=9F=E6=97=A5<= span class=3Dapple-converted-space> 22:08
=E6=94=B6=E4=BB=B6=E4=BA=BA: Paul Yang <kaishen.yy=3D40alipay.com@dmarc.i= etf.org>
=E6=8A=84=E9=80=81: &= quot;tls@ietf.org" <tls@ietf.org>
=E4=B8=BB=E9=A2=98: Re: [TLS] (offline) Re: Draft for SM cipher suites used in TLS1.3

 

IMHO, placing the documents on GitHub would be perfect, and qui= te sufficient. 

 = ;

Please make sure to= post the name of the repo here. ;/)

 

I leave it to others to= decide whether they'd want copies of today PDF files sent to the mailing li= st directly.

Regards,<= /o:p>

= Uri

<= /div>

 

Sent from my iPhone


On Aug 17, 2019, at 01:03, Paul Yang <kaishen.yy=3D40alipay.com@dmarc.ietf.org> wrote:

Good points.

 

The good news is that we have found some English PDFs of SM2= , including the missing part 1 and part 3. Will continue to find English tra= nslations of other SM standards mentioned in the draft.

 

<= div>

So, if we host a free website, say on Github or so, to= provide those docs, is it convenient for you guys? Or should we just drop t= he   PDF files to this mailing list as attachments?

 

On Aug 16, 2019, at 10:58 PM, Rene Struik <rstruik.ext@gmail= .com> wrote:

 

Arguably= , "national" crypto specifications garnish more stature if these a= re made available to the pubic by that standard-setting body itself (who, th= ereby, acts as its authoritative source), without deference to a third party= (that may, independently from the originator, enforce document control [e.g= ., by effectuating technical changes or enforcing controlled dissemination])= .

 <= /span>

Since your draft introducing SM = cipher suites with TLS1.3 appeals to the authority of a standard-setting aut= hority, easy availability of the full and accredited technical documentation= to the IETF community helps in scrutiny and, e.g., evaluating claims in the= security considerations section.

 

= On 8/16/2019 3:06 AM, Kepeng Li wrote:

H= i Rene and all,

 

> Since the ISO documents are not available to=
 the general <=
/o:p>
> public without payment, it would be helpful to have a freely availab=
le 
> do=
cument (in English) from an authoritative source. Having such a 
> reference availab=
le would be helpful to the IETF community (and 
> researchers).
=

About the referen= ces to ISO documens, I think it is a general issue for IETF drafts.

=

 =

How does the other IETF drafts make the references to ISO documents? I= SO documents are often referenced by IETF drafts.

<= div>

 

=

Thanks,

 

=

Kind Regards

Kepeng

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94

<= span style=3D'font-family:"lucida Grande",sans-serif;color:#212529;font-weight= :normal'>Re: [TLS] Draft for SM cipher suites used in TLS1.3

Rene Struik = <rstruik.ext@gmail.com> Thu, 15 August 2019 15:= 34 UTC<= a href=3D"https://mailarchive.ietf.org/arch/browse/tls/?index=3DNHbHOGtsR1S5cCr9= nWN9_sdyTgg&gbt=3D1" target=3D"_blank">Show hea= der= 

Hi Paul:
 
I tried and look up the documents GMT.0009-2012 and=
 GBT.32918.5-2016 on 
the=
 (non-secured) websites you referenced, but only found Chinese 
versions (and Chinese website navigat=
ion panels [pardon my poor language 
skills here]). Since the ISO documents are not available to the =
general =

public without p=
ayment, it would be helpful to have a freely available 
document (in English) from an authoritative s=
ource. Having such a 
ref=
erence available would be helpful to the IETF community (and 
researchers). Please note that BSI prov=
ides its specifications in German 
and English, so as to foster use/study by the community. If the Ch=
inese 
national algorithm=
s would be available in similar form, this would serve 
a similar purpose.
 
FYI - I am interested in full details and some time last year I tried=
 to 
download specs, but =
only Parts 2, 4, and 5 were available [1], [2], [3], 
not Parts 1 and 3.
 
Best regards, Rene
&=
nbsp;
[1] China ECC - Pub=
lic Key Cryptographic Algorithm SM2 Based on ECC - 
Part 5 - Parameter Definition (SEMB, July 24, 201=
8)
[2] China ECC - Public=
 Key Cryptographic Algorithm SM2 Based on ECC - 
Part 2 - Digital Signature Algorithm (SEMB, July 24,=
 2018)
[3] China ECC - Pu=
blic Key Cryptographic Algorithm SM2 Based on ECC - 
Part 4 - Public Key Encryption Algorithm (SEMB, =
July 24, 2018)=

 
On 8/15/2019 10:16 AM, Paul =
Yang wrote:
> Hi all,<=
/span>
> 
> I have submitted a new internet dr=
aft to introduce the SM cipher 
> suites into TLS 1.3 protocol.
> 
> https:/=
/tools.ietf.org/html/draft-yang-tls-tls13-sm-suites-00
> 
> SM cryptographic algorithms are originally a=
 set of Chinese national 
> algorithms and now have been (or being) accepted by ISO as 
> international standards, inclu=
ding SM2 signature algorithm, SM3 hash 
> function and SM4 block cipher. These algorithms have alr=
eady been 
=
> supported=
 some time ago by several widely used open source 
> cryptographic libraries including OpenSSL, Bo=
uncyCastle, Botan, etc.
&=
gt; 
<=
span style=3D'font-size:9.0pt;font-family:Menlo;color:#212529'>> Considerin=
g TLS1.3 is being gradually adopted in China's internet 
> industry, it's important to have a norm=
ative definition on how to use 
> the SM algorithms with TLS1.3, especially for the mobile interne=
t 
> scenario. Ant Fin=
ancial is the company who develops the market leading 
> mobile app 'Alipay' and supports payment =
services for Alibaba 
>=
; e-commerce business. We highly are depending on the new TLS1.3 
> protocol for both performance =
and security purposes. We expect to have 
> more deployment of TLS1.3 capable applications in Chin=
a's internet <=
/o:p>
> indust=
ry by this standardization attempts.
> 
&g=
t; It's very appreciated to have comments from the IETF TLS list :-)<=
span style=3D'font-size:12.0pt;font-family:SimSun'>
> 
> Many thanks!
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls<=
/a>

 

 

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

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

<= /div>

 


Regards,

&n= bsp;

Paul Yang

 

_______________________________________________
TLS mailing listT= LS@ietf.org
https://www.ietf.org/mailman/li= stinfo/tls

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

 =


Regards,=

 

<= /div>

Paul Yang



=
--B_3649057032_645832155-- --B_3649057033_738423711 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUfQYJKoZIhvcNAQcCoIIUbjCCFGoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghJDMIIE8zCCA9ugAwIBAgITWQADyHaxtc8GrYDIrgAAAAPIdjANBgkqhkiG9w0BAQsF ADBRMQswCQYDVQQGEwJVUzEfMB0GA1UECgwWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoG A1UECwwDUEtJMRMwEQYDVQQDDApNSVRMTCBDQS01MB4XDTE5MDMyNjE4NDEwMVoXDTIyMDMy NTE4NDEwMVowYTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRv cnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCzD7FJptOjLaaidxt9QIIH/dAblMrT ESMm4ggEBR0KqbmSkRY+x45ed8E2u9fJuFWKAgwU+vJo//kzavEpAAuyhe61Z+4noWIvV0sY WkUs+ffLh+29MxDs8Mt1++mDAC1+NyLCPN8QNPRJVu7ECRtmKu3DiAtuEKva3J7lZyVVNE+3 e9HQJlr/3alifN4sg/NxOFMTKMMEq15RgOhDyAudnNSs2IesRnoKTZq/Jykwbm0fg06ePSBR /k2JuYNW8/UZnU7d/Ez2n1NEtZkQw5QzWrC27ijf7FFQxM9yLToJneFVK+krQsfvtMbHGpnz Yo9keqc3Uxb13P4mpDbZiIBTAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUMzH1HGnW9jHVrCuy FAmJhhljwLcwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFC/vu8YNHbvpav6sZ/MHOwh2 9ktZMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvbGxj YTUwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUv Z2V0dG8vbGxjYTUwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9 BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+K cwIBZAIBCDAiBgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAZBgNVHREEEjAQ gQ51cmlAbGwubWl0LmVkdTAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMCcGCSsGAQQBgjcU AgQaHhgATABMAFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBACztsHHc HX+FTwlhjHUUU+AcLyX3hgIdnTovNmPWVhVgzpN25AotcwODhCwuaLNoLsC0OHRISFUvkqHg 7aeZ9CiDOL4KwlNZgzGpDlqZ/AgMJ+JodWz0XqoNm4wYNs2rl7sEzLe70yPVyzTYlhECYnex UxE4hL334w/cx+Mb8vKn+/EQ9NFKVfCJ8X1dDkCA19EkZu2DbFF2oAM0kr6JX2dNx1rChTMZ iOSkGkKKpnVNFBMl/uw8qH8XrD+slPhLpTQg5t9l0pCtkJSMnrMovPvgwhlOP7yCLdPYYTwY IjwvUeqj1VAvid80L9vevRY1D6NDz/eWfoqCxXxPvtue//owggTAMIIDqKADAgECAgEGMA0G CSqGSIb3DQEBCwUAMFYxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJv cmF0b3J5MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD01JVExMIFJvb3QgQ0EtMjAeFw0xNzAz MDIxMjAwMDBaFw0yNjAzMDIyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQg TGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLDANQS0kxEzARBgNVBAMMCk1JVExMIENBLTUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCnmoMOvTkfw7nq19mrWazGaa+Q83Uv 0+ATXT3q6kr+WExIMIZ87C74WCcRXpvO7uvx7HvMsYWAFHW93wQwhjytxHIOZgKNJ4VnGVDU l+KI7g0n9+Zjt3hB3HhHbcvbe9+Y4jz+XzCiLl2OaYvICKbxvbBSCLtPEeZQ6x6Tb6EK0ym0 gvYeHO3kuuY+SJHJMltbrLnIVLxjZrNVS77zXKvu6Q3hSdkRIB7kJgEXfL+p/z/2p94bEEZ2 TnQz0TkOjG+Jq7UlXlFRtvsYcDPEQD3UNkZsWcXgC1hXG8TGknUcAhlGxVhlKlFLmNd7342s eGy2s9YxNDnSE+eXTtb0I5LLAgMBAAGjggGcMIIBmDASBgNVHRMBAf8ECDAGAQH/AgEAMB0G A1UdDgQWBBQv77vGDR276Wr+rGfzBzsIdvZLWTAfBgNVHSMEGDAWgBT/ycllTFOA8akMPCGu girH7vgy+zAOBgNVHQ8BAf8EBAMCAYYwZwYIKwYBBQUHAQEEWzBZMC4GCCsGAQUFBzAChiJo dHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExSQ0EyMCcGCCsGAQUFBzABhhtodHRwOi8v b2NzcC5sbC5taXQuZWR1L29jc3AwNAYDVR0fBC0wKzApoCegJYYjaHR0cDovL2NybC5sbC5t aXQuZWR1L2dldGNybC9MTFJDQTIwgZIGA1UdIASBijCBhzANBgsqhkiG9xICAQMBBjANBgsq hkiG9xICAQMBCDANBgsqhkiG9xICAQMBBzANBgsqhkiG9xICAQMBCTANBgsqhkiG9xICAQMB CjANBgsqhkiG9xICAQMBCzANBgsqhkiG9xICAQMBDjANBgsqhkiG9xICAQMBDzANBgsqhkiG 9xICAQMBEDANBgkqhkiG9w0BAQsFAAOCAQEAMJYRwLPJ91K7e2mA2Nj10W0o5JMHYkaa+ctL 8/xY8QzIHFI5Ij+iydpPN9KCYn/4Sy80T3aNoYkFlS0GRQXhf0nsiY7TWJwAKw4AiO/yJ37/ oRKRgtyRicvaJ6RjlHCXBOalFLw9UtpodP4/idC51lxzsolaQZraBjVe7PL95PhS7D+22Nff InzLdIb1DBf54NwOVfPIgABtxH1fhZrja7EhR9RoUw5E1O6iWaAuP/xWhSTQFWlhyA0/kkIi 9/HXaY0hYnhcjcbPPqjpyfIhSFjjXhjqK7t2wPrSrBFLFUbnLiNlgQHrvNYF5IqgIfnSBWIr m3rfLhpZZJ/xJ7Yf6DCCA4owggJyoAMCAQICAQEwDQYJKoZIhvcNAQELBQAwVjELMAkGA1UE BhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEY MBYGA1UEAxMPTUlUTEwgUm9vdCBDQS0yMB4XDTE2MDQyMDEyMDAwMFoXDTM1MDQxOTIzNTk1 OVowVjELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAK BgNVBAsTA1BLSTEYMBYGA1UEAxMPTUlUTEwgUm9vdCBDQS0yMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAv3WoBEGOOJtm4ucvaf6vKIFPs8watCd6Smwq/XeRNo7P3jPIxNPw F398RGDUmPJIXA7idzD6j0opFIW+kLqYye9e788PV0dqaJlX8818fNDbSE+8B6hieqKTR7Vf OI74UVQEUKVRFuRFw6uVYuvgew2Tj/C2dEee37eruQl5nHkbV2OsWnZ7O+yt+etd6HRcaXLl P9q8WKgA3B7vkOVIMCKoAuaWj+BFq7K+WNkiyi/KdOH9JmOpbyRK4jcA7xbLnF8JFUSNg5c4 Y1BJrFaZtkCeG6Nm9p524GllkRFzPgpj8VicV+AK+9rY07dTx02kYotTnKuy0YxBAwsUXxAQ EwIDAQABo2MwYTAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBT/ycllTFOA8akMPCGugirH 7vgy+zAfBgNVHSMEGDAWgBT/ycllTFOA8akMPCGugirH7vgy+zAOBgNVHQ8BAf8EBAMCAYYw DQYJKoZIhvcNAQELBQADggEBAHqYfEf/3J5aMKhlYQ0PnUAbMB8jZSr9/HvjfOF00crFUCfS rqG8JQwo+S/iq66gcp62FEgJ0fQkDgVg6m+C2ETo1LoWiSxhYCfcSIQECljlXwR8wFSayF82 2S69IqvHhdq4d58jU6gYi6ssjU4vwsvsVLRJKk/m/Cg/w8gW6YHM5ahBD6/5Ccel2fI7oSms kO991+otrC11YfDwCFvz7Am0r+K9iVhSWta4hmIuV0YBia07eZKSO02LPgQ8YOz3ku0Yt+mh 8VWRKux2CcYjMpk+WDV0BMp75tqb6pqBFkcKvEBXqxg+8+G/umjii4H0c5kvJhaQyykbmOKm xO9IcJIwggT2MIID3qADAgECAhNZAAA7OX5fo0OiIK0RAAAAADs5MA0GCSqGSIb3DQEBCwUA MFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYD VQQLDANQS0kxEzARBgNVBAMMCk1JVExMIENBLTUwHhcNMTgwODI4MjE0NTI5WhcNMjEwODI3 MjE0NTI5WjBhMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9y eTEPMA0GA1UECxMGUGVvcGxlMSAwHgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAI5Vc19RKc/69lmwhogDOjjzPQbmc8s6 Z6rzP6oUHAswDICqZWwPt+FTbKr0YTAqRNsTEN4YiW0fORK+fNRvClo0pdiCqj3DwDQZLRI4 Dak1yTsUtVe35oomQbXtO+0A0L/CowYri/UKeRG1i1/0cXSf4mAx0ed9wh2SordAb8o2FuOU 0B2ppnqjro1VFugHHX6QOggaeLFOprT5gnTZUmqM37/d4DGB9XDdTQi144zQSwSWKkaUThsy D9CHSRNcB79HBvlZGSM+BkIbayPdhQAuz4yKsOZEWPx/6LnMotzBevSswnCDf+u9ajCgMnje WbrZRN+xoYEuhycXyK2b8/MCAwEAAaOCAbUwggGxMB0GA1UdDgQWBBTZUpq7Rsccv42yU9UQ 4wvojOl4pzAOBgNVHQ8BAf8EBAMCBSAwHwYDVR0jBBgwFoAUL++7xg0du+lq/qxn8wc7CHb2 S1kwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9sbGNh NTBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9n ZXR0by9sbGNhNTAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3NwMD0G CSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXr0HCD6+0g AgFkAgEJMCUGA1UdJQQeMBwGBFUdJQAGCCsGAQUFBwMEBgorBgEEAYI3CgMEMBkGA1UdEQQS MBCBDnVyaUBsbC5taXQuZWR1MBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgwJwYJKwYBBAGC NxQCBBoeGABMAEwAVQBzAGUAcgBFAG4AYwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEACyN6 Yhi9LApOPpf60ypSV2WmV3sqnrsrdlPTW+am4wMK/M/5PZmt5jFVtXaErkWYdrbMdjeo2o/G 9N2DnrFOhz7kDYM9HC9AH/rWCfoSkI/C2N6Rq/uDnRJfao61wyv37qKtanNdkp+reyLxdVPn foVrD/VZli4UV28u4XBuYDkjXPyyiH+bb395FnxOtTA3Uz41Ohpdvr6oLPEuy0IP4MPfK5wD mS6GXcB+ze9sYEp+DJxE7WAbkW5Y536WPl/rfWm/k6ZC1KPVSRM7mS+atk44VOgzPLXkl6Tu 6zY8tMczfr5F0om1JfN8G50s4QDUGtsMgzW+LXVDhFD24xnUojGCAf4wggH6AgEBMGgwUTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoMFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsM A1BLSTETMBEGA1UEAwwKTUlUTEwgQ0EtNQITWQADyHaxtc8GrYDIrgAAAAPIdjANBglghkgB ZQMEAgEFAKBpMC8GCSqGSIb3DQEJBDEiBCCPfgKDJOTym/zt/BhjYgm4CuFhTytBVYcXjFsN smFydDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xOTA4MTkx NDU3MTJaMA0GCSqGSIb3DQEBAQUABIIBAH6CrYxSQRalBpgvxSN0F1EGt1aucrIcK8ZuNDRe IxgRo0g3LyA5p/FiPp6tLUahcsH5Jq5yfwAJjdwvnCuPGfwnveiYH+lf08u857su4mhrJXWm PksrrZvar57ci5ewpqck2V4AcY3siPojHPZlxBnG+rWS6jC1jWW57tiq21TS+X/rFdCmZbU4 OIW1T6OmLnQ7qJ/mvFh/B8fQVlPmkII2uIDy5SLakPnzhac2dg//XIKMzC7iDP79r2jBYCHj sAmtEkyTtFdYi/bK0xqZ6aUuo65MLYGMRFLqSvrathjg/qmcO3iNyMo9wthc1beeI19/x3qj jCgTmp0pQvtret0= --B_3649057033_738423711-- From nobody Mon Aug 19 08:05:23 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 578951200D7 for ; Mon, 19 Aug 2019 08:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFEi_0skTxJh for ; Mon, 19 Aug 2019 08:05:20 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::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 CC30D120096 for ; Mon, 19 Aug 2019 08:05:19 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id m24so2085258ljg.8 for ; Mon, 19 Aug 2019 08:05:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=h6VA3b+H40bTJMoaQ5BEzHMMVpuRHJAEUwhovbeQNAE=; b=MUl05k/p5GfzIQe3+v1RtYk/cIlCPbD6u1zKWEQXBVBMANkY9EdmuyQqUuTT7TGNan jlcZ3/S/Vt+r97l1jVL3w/y4E5+IT1xslEi+yDF8qlOXcJvOUb5I8k3d7uvq5PMV1Cll /sy8Jphug2+W9xl/7XPDmQSl2IEf1etvJ/fsse4CUPPwioYcSpLlK147zae/6M2U+Qt1 OQxTv1fTiAIQAJGSjyVTrK7l4w6EoWI8TO8pBam5vtlNPImAN+cnawvDLlemM/U72Ouu 967LtyLa5B/5zc66nkDF8srLXmDCi7QMOL8k/KFMvQatm4F3G/BzYxmoOvLDcqyoKbJs toww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=h6VA3b+H40bTJMoaQ5BEzHMMVpuRHJAEUwhovbeQNAE=; b=NfOx/OLXH3H5w1fZ3BWAgRg49bDGZWpVEJvDrT7ZKYmDFZMqiYD5vsm7Wv2ju/R9xi 1YjyrNTxdV5jPtlhkj8ZQyXox4oLNqViSry4a/TJSkWUeNb1LTwHECuGkUkaAe2tUMOS 6eVghocWs3xtRsvOREsFHJ4B4T6YWPXojzQyHvpA6LrdF904El3WS7Bj8yn4iGWQk/0Y zAuXBHoB33ExmIb9rnClrwd6tqkSWKWTn6IhfVsjFK/GcP3Ti8FxMBZAy3PALfEEmtU0 DNw5EwKolzqvfSUKBuadB7fSuO/e0GZ2ExX+rZCN6zu0nRsO86p1xiKur27N2fB2xAJQ BWqQ== X-Gm-Message-State: APjAAAVY/CNGnRBDXUpm/jmk6Z+HkaidTmU7GKrna2BT873HUWA42LRN aGkhmpp3b+c2Q4JvHtP73IKglMUMUiEJilEIB0AS4CZN X-Google-Smtp-Source: APXvYqzXmlHnAcXXjDIWnTEPYXeONBHxxcEVZ56i3V9mwA7kl23/dRpHMLSI0JzICjnbvmAyUrWgbNQdBjVfSjwnouU= X-Received: by 2002:a2e:8957:: with SMTP id b23mr12292821ljk.206.1566227117599; Mon, 19 Aug 2019 08:05:17 -0700 (PDT) MIME-Version: 1.0 From: Watson Ladd Date: Mon, 19 Aug 2019 08:05:06 -0700 Message-ID: To: TLS List Content-Type: multipart/alternative; boundary="000000000000fb77c7059079aa6f" Archived-At: Subject: [TLS] On the difficulty of technical Mandarin (SM3 related) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Aug 2019 15:05:22 -0000 --000000000000fb77c7059079aa6f Content-Type: text/plain; charset="UTF-8" Dear all, I see no reason why English alone should be accepted for standards documents we reference. French and German pose few difficulties, and one can always learn Russian. What I don't know is how difficult Mandarin is at a level to read a standards document. I expect the mechanics of using the dictionary to dominate. I'm concerned about the traceability of unofficial Englidh PDFs on some website: could the Chinese body responsible host them instead? I fully expect this to be a more general IETF problem. Sincerely, Watson --000000000000fb77c7059079aa6f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

I see no= reason why English alone should be accepted for standards documents we ref= erence. French and German pose few difficulties, and one can always learn R= ussian.=C2=A0

What I don= 't know is how difficult Mandarin is at a level to read a standards doc= ument. I expect the mechanics of using the dictionary to dominate.

I'm concerned about the trac= eability of unofficial Englidh PDFs on some website: could the Chinese body= responsible host them instead?

I fully expect this to be a more general IETF problem.

Sincerely,
= Watson
--000000000000fb77c7059079aa6f-- From nobody Mon Aug 19 10:10:54 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B16212084B for ; Mon, 19 Aug 2019 10:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dq-pufuoRI0q for ; Mon, 19 Aug 2019 10:10:50 -0700 (PDT) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C28B12083B for ; Mon, 19 Aug 2019 10:10:50 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id a30so1939538lfk.12 for ; Mon, 19 Aug 2019 10:10:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eZLeAdarvu27rVs1XICgLKQVaVfw/8HFI/FKUMoh3XQ=; b=Rptymy4TQzgiSdxYBitwM8Cso1246xCk5S5gdUWmaIg1m6gbqCoh7zMZlLbqvhXCJj RUHgpAY3kPJcefDwcJuJJfxZfP++LN8675mcV7+i++lJfX4HZHycg0uS0GeAdOsxXm/Z ANAhHuGJmJtkuEG5Q49f9YtDeU97rmkTBHMxp4PUHdHgL8Cf3X2qT46R8s+NeBy+TbSP kp/HO54Su8Gv3joau2tz1+uFlbvGJU/IFurKaW/lC0LJWuVUjtyJcDqJOOL93TtesSll JGkh91sPHHCUhiM7GW5jadLjrYb0l5HqeRcHtJSjr/Cp+JiGwGnb0zMOXaHajDZph9fd QYfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eZLeAdarvu27rVs1XICgLKQVaVfw/8HFI/FKUMoh3XQ=; b=TD5EDPsAGU2YWegE66N/urPo8RiloP+UJgpvZmJZjLsq3lKE3Z8zlVmfEnSjaEaQbs 0eYdoSFa/oFsZoQjpvVipoaFt90PusLZc4YbNlh3YF6uHUluWt7iebte8SYS2mPaGjp+ OPDm6XCEI2PxO8k+Lj9IIlTZBSp5Z0ovXerI3zwwIeIxYSlBa7LSyBjncvEzfSPb2MWn IOM9nhlT+p35zICfuSUc5JY79b/ejuHrSVJaZMFfysonovdRQDN1YW45Ng7kWmCUSulg 21EczfpBcI5fafujSRnp87MH7f3qeUv7XsdvlJCKmRdwv7bjLCHxMR1pTo6x2CIqSPoM 48Gw== X-Gm-Message-State: APjAAAXbp/QvSVn8JF/eUjZtOJnV4dnqNmKLQSvYtksrpnldiO9ySczQ PA5OMFxnwT+jQ8tMV4BDlKkO85rEbPcwpyomluUPaw== X-Google-Smtp-Source: APXvYqx9PihmfGJwirxg36+/eGbS+bGMgv4KoIiZsk5RXRdrpZDqmjPu2Hq4LnEfbw7s6Qf7LRls1IFDOt69uqa6BQs= X-Received: by 2002:a19:7908:: with SMTP id u8mr12773184lfc.178.1566234648341; Mon, 19 Aug 2019 10:10:48 -0700 (PDT) MIME-Version: 1.0 References: <3350587b-f768-425f-a759-3ed7ce2e6b27.kepeng.lkp@alibaba-inc.com> <1e07a7cc-b316-6a1d-6f59-b352ffbd74b8@gmail.com> <8EE550E4-20E6-4D83-89E6-A43F63E3A593@akamai.com> <57CCBFBA-328E-470E-B3FA-B1088ED2971F@alipay.com> In-Reply-To: <57CCBFBA-328E-470E-B3FA-B1088ED2971F@alipay.com> From: Eric Rescorla Date: Mon, 19 Aug 2019 10:10:12 -0700 Message-ID: To: Paul Yang Cc: Rich Salz , "tls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d9860905907b6b52" Archived-At: Subject: Re: [TLS] (offline) Re: Draft for SM cipher suites used in TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Aug 2019 17:10:53 -0000 --000000000000d9860905907b6b52 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Aug 19, 2019 at 7:32 AM Paul Yang wrote: > > > On Aug 18, 2019, at 9:47 PM, Eric Rescorla wrote: > > The intent of the "Specification Required" requirement for registration i= s > that sufficient public information be available to allow an interoperable > implementation. Specifically, the text says: > > https://tools.ietf.org/html/rfc8126#section-4.6 > > For the Specification Required policy, review and approval by a > designated expert (see Section 5) is required, and the values and > their meanings must be documented in a permanent and readily > available public specification, in sufficient detail so that > interoperability between independent implementations is possible. > This policy is the same as Expert Review, with the additional > requirement of a formal public specification. In addition to the > normal review of such a request, the designated expert will review > the public specification and evaluate whether it is sufficiently > stable and permanent, and sufficiently clear and technically sound to > allow interoperable implementations. > > I don't think that a for-pay specification meets that threshold, though I= 'm > not aware of any IETF-wide policy on that (although I may just have misse= d > it). > > > Makes sense, so we added new public documents now ;-) > > Just one question, do implementations count as the =E2=80=98public specif= ication=E2=80=99? > For instance, something like the crypto libraries which support the > algorithms with full documentation describing it... > I do not think so, no. -Ekr > > In the absence of that, it would as stated above, be on the Expert to > determine > the standard. > > -Ekr > > > > > > On Sun, Aug 18, 2019 at 2:52 PM Salz, Rich wrote: > >> >> >> =C3=98 This is one example: https://www.rfc-editor.org/rfc/rfc8428.txt >> >> >> >> Thank you. >> >> >> >> That is a bit different since RNC isn=E2=80=99t needed to implement the = RFC, and a web search for =E2=80=9Crelaxng=E2=80=9D finds thousands of refe= rences. The SM2, etc., situation is different because you cannot implement= the cipher without the definition of it. >> >> >> >> _______________________________________________ >> 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 > > > > Regards, > > Paul Yang > > --000000000000d9860905907b6b52 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Aug 19, 2019 at 7:32 AM Paul = Yang <kaishen.yy@alipay.com= > wrote:


On Aug 18, 2019, at 9:47 PM, Eric Rescorla <ekr@rtfm.com> wrote:

The intent of the "Specification Required" requirement for = registration is that sufficient public information be available to allow an= interoperable implementation. Specifically, the text says:

<= /div>
=
=C2=A0=C2=A0 For the Specification Required policy, review a= nd approval by a
=C2=A0 =C2=A0designated expert (see Section 5) is requi= red, and the values and
=C2=A0 =C2=A0their meanings must be documented i= n a permanent and readily
=C2=A0 =C2=A0available public specification, i= n sufficient detail so that
=C2=A0 =C2=A0interoperability between indepe= ndent implementations is possible.
=C2=A0 =C2=A0This policy is the same = as Expert Review, with the additional
=C2=A0 =C2=A0requirement of a form= al public specification.=C2=A0 In addition to the
=C2=A0 =C2=A0normal re= view of such a request, the designated expert will review
=C2=A0 =C2=A0t= he public specification and evaluate whether it is sufficiently
=C2=A0 = =C2=A0stable and permanent, and sufficiently clear and technically sound to=
=C2=A0 =C2=A0allow interoperable implementations.

<= div>I don't think that a for-pay specification meets that threshold, th= ough I'm
not aware of any IETF-wide policy on that (although = I may just have missed
it).
Makes sense, so we added new public documents now ;-)

Just one question, do implementations count as the =E2=80= =98public specification=E2=80=99? For instance, something like the crypto l= ibraries which support the algorithms with full documentation describing it= ...

I do not think so, no= .

-Ekr

<= br>

In t= he absence of that, it would as stated above, be on the Expert to determine=
the standard.

-Ekr





On Sun, Aug 18, 2019 at 2:= 52 PM Salz, Rich <= rsalz@akamai.com> wrote:
=C2=A0
=C3=98=C2=A0 This is one example: https://www.rf=
c-editor.org/rfc/rfc8428.txt
=C2=A0
Thank you.
=C2=A0
That is a bit different since RNC isn=E2=80=99t needed to implement the=
 RFC, and a web search for =E2=80=9Crelaxng=E2=80=9D finds thousands of ref=
erences.=C2=A0 The SM2, etc., situation is different because you cannot imp=
lement the cipher without the definition of it.
=C2=A0
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://ww= w.ietf.org/mailman/listinfo/tls


Regards,

Paul Yang

--000000000000d9860905907b6b52-- From nobody Mon Aug 19 10:22:05 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7C031200D7 for ; Mon, 19 Aug 2019 09:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rI7eXZdLZvhs for ; Mon, 19 Aug 2019 09:24:14 -0700 (PDT) Received: from mail-yw1-xc42.google.com (mail-yw1-xc42.google.com [IPv6:2607:f8b0:4864:20::c42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0257E12010E for ; Mon, 19 Aug 2019 09:24:14 -0700 (PDT) Received: by mail-yw1-xc42.google.com with SMTP id m11so979047ywh.3 for ; Mon, 19 Aug 2019 09:24:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4FCtdCrMyTwy0b4ix3NfmqHUhQQuFEWEXTZZkvPPVIc=; b=ZxQt7Y1RI41Yh2elVFHuZkG8ElSgDHQggytKfowbxOZpsBc0V+i3ZawoiyA9JFFl5X ZgZ2+TP/tZH47VcRfpqvTEsefV+6qf20XGrZWzSR8GU6v1ebF8R7v1LaXMQnR35X77gJ /F6w2T7PVPlmCNQwuF+/CgMocsxAbZkW6oZTU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4FCtdCrMyTwy0b4ix3NfmqHUhQQuFEWEXTZZkvPPVIc=; b=n7cDRgWfhtjm3RurwBFIR2DLWFe51waryNXcQrloRRbvy04pjdwrpRcb++4HB51dAy zPPiAgKS/UxFphgkvuWhypW3XcPQ5H7brUtLx4yDgHwVR4g8grI0gk3+Cy1uhU9ah+EE /AWGN8dMgGpph6fgoAaiNNuVI2zbK8mbQHGOyJhGq6yvCD6gLnH4y71a9xw8G6XfS5Um tm2PAqI3WGwSr6OrsdHTgIXoCOYujyB15LWOlamjK64M0xdrILhIo6AB+8yN9pss0fdp Cxp2GIlQuev4J9YsSZSc50tVlpgWV54zrjhaiS9HDRapaN0mhbqLSadPm177xNk72uew eVWA== X-Gm-Message-State: APjAAAV2RUHbO/4t7XPDdnY5Q8kme9ueEPNUNz4+ZCtCTgR/2u9nXsIr w1pKnVS6rL+0+3LfRZuQqERWdfGPFdU+Jy8CIdxWWg== X-Google-Smtp-Source: APXvYqyY+9KEqtwzq34POTQWodUgv9AMcK33tu++rDna/wCiPRkoSHWg7qEs8MZ7zEjeG98mMRVdXgf4EAWZYXl45Wo= X-Received: by 2002:a81:9b49:: with SMTP id s70mr16633618ywg.51.1566231852988; Mon, 19 Aug 2019 09:24:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Kyle Rose Date: Mon, 19 Aug 2019 12:24:01 -0400 Message-ID: To: Watson Ladd Cc: rfc-interest@ietf.org Content-Type: multipart/alternative; boundary="0000000000003bd41905907ac508" Archived-At: X-Mailman-Approved-At: Mon, 19 Aug 2019 10:22:04 -0700 Subject: Re: [TLS] On the difficulty of technical Mandarin (SM3 related) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Aug 2019 16:24:16 -0000 --0000000000003bd41905907ac508 Content-Type: text/plain; charset="UTF-8" Moving tls to bcc, and adding rfc-interest. (This is the kind of discussion that is likely to ignite a dumpster fire, and it's not specific to TLS work.) On Mon, Aug 19, 2019 at 11:05 AM Watson Ladd wrote: > I see no reason why English alone should be accepted for standards > documents we reference. French and German pose few difficulties, and one > can always learn Russian. > > What I don't know is how difficult Mandarin is at a level to read a > standards document. I expect the mechanics of using the dictionary to > dominate. > > I'm concerned about the traceability of unofficial Englidh PDFs on some > website: could the Chinese body responsible host them instead? > > I fully expect this to be a more general IETF problem. > For purely practical reasons, within a knowledge domain it makes sense to have a single language in which normative documents are written, with fluency in that language an implicit requirement of direct participation. Otherwise, the number of people who will be able to contribute to IETF work (writing or reviewing) will be very small, limiting the throughput, shared knowledge base, and overall utility of the SDO. For historical reasons, that single language is English. This isn't something unique to the IETF, either: for a variety of reasons too numerous to cover here, English has become the default shared language in a multilingual world when actual work needs to get done between people with different native tongues. The IETF exists in this reality: fair or not, there's really no other practical choice. Informational documents and upstream references are maybe a different story as they are not required to implement IETF protocols, but I suspect similar issues would crop up even there, given how important many informational documents are. Kyle --0000000000003bd41905907ac508 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Moving tls to bcc, and adding rfc-interest. (This is = the kind of discussion that is likely to ignite a dumpster fire, and it'= ;s not specific to TLS work.)

On Mon, Aug 19, 2019 at 11:05 AM Watson Ladd <watsonbladd@gmail.com> wro= te:
I see no reason why English alone should b= e accepted for standards documents we reference. French and German pose few= difficulties, and one can always learn Russian.=C2=A0

What I don't know is how dif= ficult Mandarin is at a level to read a standards document. I expect the me= chanics of using the dictionary to dominate.

I'm concerned about the traceability of unofficial= Englidh PDFs on some website: could the Chinese body responsible host them= instead?

I fully expect= this to be a more general IETF problem.

For purely practical reasons, within a knowledge domai= n it makes=20 sense to have a single language in which normative documents are=20 written, with fluency in that language an implicit requirement of direct participation. Otherwise, the number of people who will be able to=20 contribute to IETF work (writing or reviewing) will be very=20 small, limiting the throughput, shared knowledge base, and overall utility = of=20 the SDO.

For historical reasons, that single l= anguage=20 is English. This isn't something unique to the IETF, either: for a=20 variety of reasons too numerous to cover here, English has become the=20 default shared language in a multilingual world when actual work needs=20 to get done between people with different native tongues. The IETF=20 exists in this reality: fair or not, there's really no other practical= =20 choice.

Informational documents and upstream r= eferences are maybe a different story as they are not required to implement= IETF protocols, but I suspect similar issues would crop up even there, giv= en how important many informational documents are.

K= yle

--0000000000003bd41905907ac508-- From nobody Mon Aug 19 10:41:15 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 922CB120045 for ; Mon, 19 Aug 2019 02:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2kX6gNi8-P8 for ; Mon, 19 Aug 2019 02:54:25 -0700 (PDT) Received: from out0-157.mail.aliyun.com (out0-157.mail.aliyun.com [140.205.0.157]) (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 5F24712001A for ; Mon, 19 Aug 2019 02:54:24 -0700 (PDT) X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R191e4; CH=green; DM=||false|; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03292; MF=kepeng.lkp@antfin.com; NM=1; PH=DS; RN=6; SR=0; TI=SMTPD_---.FEY13Mk_1566207520; Received: from 10.15.240.253(mailfrom:kepeng.lkp@antfin.com fp:SMTPD_---.FEY13Mk_1566207520) by smtp.aliyun-inc.com(127.0.0.1); Mon, 19 Aug 2019 17:38:40 +0800 User-Agent: Microsoft-MacOutlook/10.10.d.190811 Date: Mon, 19 Aug 2019 17:38:40 +0800 From: "Kepeng Li" To: , , CC: "tls@ietf.org" , "Blumenthal, Uri - 0553 - MITLL" , Paul Yang Message-ID: Thread-Topic: [TLS] (offline) Re: Draft for SM cipher suites used in TLS1.3 References: <3350587b-f768-425f-a759-3ed7ce2e6b27.kepeng.lkp@alibaba-inc.com> <1e07a7cc-b316-6a1d-6f59-b352ffbd74b8@gmail.com> <3AA3FCE5-729F-4DA9-A3B9-52CC0CEB5571@ll.mit.edu> In-Reply-To: <3AA3FCE5-729F-4DA9-A3B9-52CC0CEB5571@ll.mit.edu> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3649081120_146984714" Archived-At: X-Mailman-Approved-At: Mon, 19 Aug 2019 10:41:14 -0700 Subject: Re: [TLS] (offline) Re: Draft for SM cipher suites used in TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Aug 2019 09:54:27 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3649081120_146984714 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi WG chairs, =20 Can we place the referenced documents in the TLS WG GitHub? https://github.com/tlswg =20 According to the discussion below, this can help people to read and underst= and the referenced specifications. =20 Thanks, =20 Kind Regards Kepeng=20 =20 =E5=8F=91=E4=BB=B6=E4=BA=BA: TLS =E4=BB=A3=E8=A1=A8 "Blumenthal, Uri - 0553 - MITL= L" =E6=97=A5=E6=9C=9F: 2019=E5=B9=B48=E6=9C=8818=E6=97=A5 =E6=98=9F=E6=9C=9F=E6=97=A5 22:08 =E6=94=B6=E4=BB=B6=E4=BA=BA: Paul Yang =E6=8A=84=E9=80=81: "tls@ietf.org" =E4=B8=BB=E9=A2=98: Re: [TLS] (offline) Re: Draft for SM cipher suites used in TLS1.3 =20 IMHO, placing the documents on GitHub would be perfect, and quite sufficien= t.=20 =20 Please make sure to post the name of the repo here. ;/) =20 I leave it to others to decide whether they'd want copies of today PDF file= s sent to the mailing list directly. Regards, Uri =20 Sent from my iPhone On Aug 17, 2019, at 01:03, Paul Yang wrote: Good points. =20 The good news is that we have found some English PDFs of SM2, including the= missing part 1 and part 3. Will continue to find English translations of ot= her SM standards mentioned in the draft. =20 So, if we host a free website, say on Github or so, to provide those docs, = is it convenient for you guys? Or should we just drop the PDF files to thi= s mailing list as attachments? On Aug 16, 2019, at 10:58 PM, Rene Struik wrote: =20 Arguably, "national" crypto specifications garnish more stature if these ar= e made available to the pubic by that standard-setting body itself (who, the= reby, acts as its authoritative source), without deference to a third party = (that may, independently from the originator, enforce document control [e.g.= , by effectuating technical changes or enforcing controlled dissemination]).= =20 =20 Since your draft introducing SM cipher suites with TLS1.3 appeals to the au= thority of a standard-setting authority, easy availability of the full and a= ccredited technical documentation to the IETF community helps in scrutiny an= d, e.g., evaluating claims in the security considerations section. =20 On 8/16/2019 3:06 AM, Kepeng Li wrote: Hi Rene and all, =20 > Since the ISO documents are not available to the general=20 > public without payment, it would be helpful to have a freely available=20 > document (in English) from an authoritative source. Having such a=20 > reference available would be helpful to the IETF community (and=20 > researchers). About the references to ISO documens, I think it is a general issue for IET= F drafts. =20 How does the other IETF drafts make the references to ISO documents? ISO do= cuments are often referenced by IETF drafts. =20 Thanks, =20 Kind Regards Kepeng =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 Re: [TLS] Draft for SM cipher suites used in TLS1.3 Rene Struik Thu, 15 August 2019 15:34 UTCShow heade= r Hi Paul: =20 I tried and look up the documents GMT.0009-2012 and GBT.32918.5-2016 on=20 the (non-secured) websites you referenced, but only found Chinese=20 versions (and Chinese website navigation panels [pardon my poor language=20 skills here]). Since the ISO documents are not available to the general=20 public without payment, it would be helpful to have a freely available=20 document (in English) from an authoritative source. Having such a=20 reference available would be helpful to the IETF community (and=20 researchers). Please note that BSI provides its specifications in German=20 and English, so as to foster use/study by the community. If the Chinese=20 national algorithms would be available in similar form, this would serve=20 a similar purpose. =20 FYI - I am interested in full details and some time last year I tried to=20 download specs, but only Parts 2, 4, and 5 were available [1], [2], [3],=20 not Parts 1 and 3. =20 Best regards, Rene =20 [1] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC -=20 Part 5 - Parameter Definition (SEMB, July 24, 2018) [2] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC -=20 Part 2 - Digital Signature Algorithm (SEMB, July 24, 2018) [3] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC -=20 Part 4 - Public Key Encryption Algorithm (SEMB, July 24, 2018) =20 On 8/15/2019 10:16 AM, Paul Yang wrote: > Hi all, >=20 > I have submitted a new internet draft to introduce the SM cipher=20 > suites into TLS 1.3 protocol. >=20 > https://tools.ietf.org/html/draft-yang-tls-tls13-sm-suites-00 >=20 > SM cryptographic algorithms are originally a set of Chinese national=20 > algorithms and now have been (or being) accepted by ISO as=20 > international standards, including SM2 signature algorithm, SM3 hash=20 > function and SM4 block cipher. These algorithms have already been=20 > supported some time ago by several widely used open source=20 > cryptographic libraries including OpenSSL, BouncyCastle, Botan, etc. >=20 > Considering TLS1.3 is being gradually adopted in China's internet=20 > industry, it's important to have a normative definition on how to use=20 > the SM algorithms with TLS1.3, especially for the mobile internet=20 > scenario. Ant Financial is the company who develops the market leading=20 > mobile app 'Alipay' and supports payment services for Alibaba=20 > e-commerce business. We highly are depending on the new TLS1.3=20 > protocol for both performance and security purposes. We expect to have=20 > more deployment of TLS1.3 capable applications in China's internet=20 > industry by this standardization attempts. >=20 > It's very appreciated to have comments from the IETF TLS list :-) >=20 > Many thanks! >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls =20 =20 --=20 email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls =20 Regards, =20 Paul Yang =20 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.o= rg https://www.ietf.org/mailman/listinfo/tls=20 --B_3649081120_146984714 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi WG chairs,

 

Can we place the referenced documents in the TLS WG GitHub?=

https://github.com= /tlswg

 

Acco= rding to the discussion below, this can help people to read and understand t= he referenced specifications.

 

Thanks,

 

Kind Regards

Kepeng

 

=E5=8F=91=E4=BB=B6=E4=BA=BA: TLS <tls-bounces@ietf.org> =E4=BB=A3=E8=A1=A8 "Blumenthal, Uri - 0553 - MITLL"= ; <uri@ll.mit.edu>
=E6=97=A5=E6=9C=9F: 2019=E5=B9=B48=E6=9C=8818=E6=97=A5 =E6=98= =9F=E6=9C=9F=E6=97=A5 22:08
=E6=94=B6=E4=BB=B6=E4=BA=BA: Paul Yang <kaishen.yy=3D40alipay.com@dmarc.ietf.org>
=E6=8A=84=E9=80=81: "tls@ietf.org" <tls@= ietf.org>
=E4=B8=BB=E9=A2=98: <= /b>Re:= [TLS] (offline) Re: Draft for SM cipher suites used in TLS1.3

 

IMHO, placing the documents= on GitHub would be perfect, and quite sufficient. 

 

Please make sure to post the name = of the repo here. ;/)

 

I leave it to others to decide whether t= hey'd want copies of today PDF files sent to the mailing list directly.=

Regards,

U= ri

=  

Sent f= rom my iPhone


On Aug 17, 2019, at 01:03, Paul= Yang <kaishen.yy= =3D40alipay.com@dmarc.ietf.org> wrote:

= Good points.

<= span lang=3DEN-US> 

The good news is that we have found some English PDFs of SM2,= including the missing part 1 and part 3. Will continue to find English tran= slations of other SM standards mentioned in the draft.

=

 

<= /div>

So, if we host a free website,= say on Github or so, to provide those docs, is it convenient for you guys? = Or should we just drop the   PDF files to this mailing list as attachme= nts?



<= o:p>

On Aug 16, 2019, at 10:58 PM, Ren= e Struik <rstruik.ext@gmail.com> wrote:

=  

=

Kind Regards

Kepeng

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94

Re: [TLS] Draft for SM cipher suites = used in TLS1.3

Rene Struik <rstruik.ext@gmail.com> Thu, 15 August 2019 15:34 UTCShow header

Hi Paul:
 
I tried and look up the documents =
GMT.0009-2012 and GBT.32918.5-2016 on 
the (non-secured) websites you referenced, =
but only found Chinese 
versions (and Chinese website navigation panels [pardon my=
 poor language 
skills here]). Since the ISO documents are not available to the ge=
neral 
public without payment, it would be helpful to have a freely available 
document =
(in English) from an authoritative source. Having such a <=
/pre>
reference available woul=
d be helpful to the IETF community (and 
researchers). Please note that BSI provid=
es its specifications in German 
and English, so as to foster use/study by the com=
munity. If the Chinese 
national algorithms would be available in similar form, th=
is would serve 
a similar purpose.
 
FYI - I am interested in full details and some time =
last year I tried to 
download specs, but only Parts 2, 4, and 5 were available [1=
], [2], [3], 
not Parts 1 and 3.
 
Best regards, Rene
 
[1] China ECC - Public Key Cryptographic=
 Algorithm SM2 Based on ECC - 
Part 5 - Parameter Definition (SEMB, July 24, 2018)=

[2] C=
hina ECC - Public Key Cryptographic Algorithm SM2 Based on ECC - =

Part 2 - Digital=
 Signature Algorithm (SEMB, July 24, 2018)
[3] China ECC - Public Key Cryptographi=
c Algorithm SM2 Based on ECC - 
Part 4 - Public Key Encryption Algorithm (SEMB, Ju=
ly 24, 2018)
 
On 8/15/2019 10:16 AM, Paul Yang wrote:
> Hi all,
> 
> I have submitted =
a new internet draft to introduce the SM cipher 
> suites into TLS 1.3 protocol=
.
<=
span lang=3DEN-US style=3D'font-size:9.0pt;font-family:Menlo;color:#212529'>>=
 
> https://t=
ools.ietf.org/html/draft-yang-tls-tls13-sm-suites-00
> 
> SM crypt=
ographic algorithms are originally a set of Chinese national 
> algorithms and =
now have been (or being) accepted by ISO as 
> international standards, includi=
ng SM2 signature algorithm, SM3 hash 
> function and SM4 block cipher. These al=
gorithms have already been 
> supported some time ago by several widely used op=
en source 
> cryptographic libraries including OpenSSL, BouncyCastle, Botan, et=
c.
=
>=
; 
> Considering TLS1.3 is being gradually adopted in China's internet 
> ind=
ustry, it's important to have a normative definition on how to use 
> the SM al=
gorithms with TLS1.3, especially for the mobile internet <=
/pre>
> scenario. Ant Finan=
cial is the company who develops the market leading 
=

> mobile app 'Alipay' and =
supports payment services for Alibaba 
> e-commerce business. We highly are dep=
ending on the new TLS1.3 
> protocol for both performance and security purposes=
. We expect to have 
> more deployment of TLS1.3 capable applications in China'=
s internet 
> industry by this standardization attempts.
> =

> It's very apprecia=
ted to have comments from the IETF TLS list :-)
> 
=

> Many thanks!<=
/span>
> 
> _______=
________________________________________
> TLS mailing list
> T=
LS@ietf.org
> https://www.i=
etf.org/mailman/listinfo/tls

 

 

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

_________= ______________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls<= /p>

 <= /o:p>


Regards,

 

Paul Yang

 

_______________________________________________
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

--B_3649081120_146984714-- From nobody Mon Aug 19 10:43:38 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC171200CE for ; Mon, 19 Aug 2019 10:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUi8Rpqt1m-6 for ; Mon, 19 Aug 2019 10:43:34 -0700 (PDT) Received: from mail-qk1-x741.google.com (mail-qk1-x741.google.com [IPv6:2607:f8b0:4864:20::741]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4A6A1200B1 for ; Mon, 19 Aug 2019 10:43:33 -0700 (PDT) Received: by mail-qk1-x741.google.com with SMTP id m2so2125165qkd.10 for ; Mon, 19 Aug 2019 10:43:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nRvBBKQxTQiaaxDJKiUP0owbZ7Om8mP/+W0JLuLv5hc=; b=RnTaXYpcPUFCP6ZACva2XP1Os0gbDGkHbzCBhlnieKod2JfvBi5mWsCmTno2tNnpXO zm73paUVW9fuyNpVe73OpaD6W6TF9VyyWgyG43Q0VIkmzPqO2v0aINs40bKOxXMJ5JYU sgeyaFOtF0lXpzy8UwZzJhHcmvOg8Jkv7Yl1Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nRvBBKQxTQiaaxDJKiUP0owbZ7Om8mP/+W0JLuLv5hc=; b=rV/deP3QkI0pFo6/mTghgqEKQIA1Ekv7AxjWLo1zgQfQpaJ5X91DcXHnMUfCEz/eqD jD3HMZZnk/CHgz31qEndoykIiyJ3ZkAWemt7T1hgvFTCKLEQytZuDjJQTruAXF5PtV4a mTeFda6IXDgO2LaAvQ+skt883jZp0jfCJK1cqMTzER71LDGu860RXdy+qnULkmUi99W2 427nCbstTXlHO6HXJygr5np0RjaaIKC0f6CajiiZRkuA/z0Q5lPZcgZyCOcDko8ok4is yPUaKlIIMNjTAAMqaVt+LiYGsC+SWN2qbdW9mN+GuWqqO9V9dLBTxM2TjuMAALtBFEZ9 f84Q== X-Gm-Message-State: APjAAAUMbdJM+FdoYkvLoziwsX6XUgMEiJmPmVLZLRyPsBof77yxEeLv 8Y+U20oV+ZdG0i4dlB5dnZ6nlA== X-Google-Smtp-Source: APXvYqzT8qunaEp8Dm668Esf88OaKl70oCLdZYmyHj9ssrtuw9QzNALueIb0wgUAUjo3oLYUCkbJaA== X-Received: by 2002:ae9:f441:: with SMTP id z1mr21728707qkl.211.1566236612790; Mon, 19 Aug 2019 10:43:32 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.36]) by smtp.gmail.com with ESMTPSA id s64sm7407544qke.125.2019.08.19.10.43.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Aug 2019 10:43:32 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Sean Turner In-Reply-To: Date: Mon, 19 Aug 2019 13:43:31 -0400 Cc: "tls@ietf.org" , TLS Chairs Content-Transfer-Encoding: quoted-printable Message-Id: References: <3350587b-f768-425f-a759-3ed7ce2e6b27.kepeng.lkp@alibaba-inc.com> <1e07a7cc-b316-6a1d-6f59-b352ffbd74b8@gmail.com> <3AA3FCE5-729F-4DA9-A3B9-52CC0CEB5571@ll.mit.edu> To: Kepeng Li X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] (offline) Re: Draft for SM cipher suites used in TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Aug 2019 17:43:36 -0000 Kepeng, It seems that this request is OBE (over taken by events) now that = you=E2=80=99ve posted the referenced specifications to: https://github.com/alipay/tls13-sm-spec Cheers, spt > On Aug 19, 2019, at 05:38, Kepeng Li wrote: >=20 > Hi WG chairs, > =20 > Can we place the referenced documents in the TLS WG GitHub? > https://github.com/tlswg > =20 > According to the discussion below, this can help people to read and = understand the referenced specifications. > =20 > Thanks, > =20 > Kind Regards > Kepeng=20 > =20 > =E5=8F=91=E4=BB=B6=E4=BA=BA: TLS =E4=BB=A3=E8=A1=A8= "Blumenthal, Uri - 0553 - MITLL" > =E6=97=A5=E6=9C=9F: 2019=E5=B9=B48=E6=9C=8818=E6=97=A5 =E6=98=9F=E6=9C=9F= =E6=97=A5 22:08 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Paul Yang = > =E6=8A=84=E9=80=81: "tls@ietf.org" > =E4=B8=BB=E9=A2=98: Re: [TLS] (offline) Re: Draft for SM cipher suites = used in TLS1.3 > =20 > IMHO, placing the documents on GitHub would be perfect, and quite = sufficient.=20 > =20 > Please make sure to post the name of the repo here. ;/) > =20 > I leave it to others to decide whether they'd want copies of today PDF = files sent to the mailing list directly. >=20 > Regards, > Uri > =20 > Sent from my iPhone >=20 > On Aug 17, 2019, at 01:03, Paul Yang = wrote: >=20 >> Good points. >> =20 >> The good news is that we have found some English PDFs of SM2, = including the missing part 1 and part 3. Will continue to find English = translations of other SM standards mentioned in the draft. >> =20 >> So, if we host a free website, say on Github or so, to provide those = docs, is it convenient for you guys? Or should we just drop the PDF = files to this mailing list as attachments? >>=20 >>=20 >>> On Aug 16, 2019, at 10:58 PM, Rene Struik = wrote: >>> =20 >>> Arguably, "national" crypto specifications garnish more stature if = these are made available to the pubic by that standard-setting body = itself (who, thereby, acts as its authoritative source), without = deference to a third party (that may, independently from the originator, = enforce document control [e.g., by effectuating technical changes or = enforcing controlled dissemination]).=20 >>> =20 >>> Since your draft introducing SM cipher suites with TLS1.3 appeals to = the authority of a standard-setting authority, easy availability of the = full and accredited technical documentation to the IETF community helps = in scrutiny and, e.g., evaluating claims in the security considerations = section. >>> =20 >>> On 8/16/2019 3:06 AM, Kepeng Li wrote: >>>> Hi Rene and all, >>>> =20 >>>> > Since the ISO documents are not available to the general=20 >>>> > public without payment, it would be helpful to have a freely = available=20 >>>> > document (in English) from an authoritative source. Having such a=20= >>>> > reference available would be helpful to the IETF community (and=20= >>>> > researchers). >>>> About the references to ISO documens, I think it is a general issue = for IETF drafts. >>>> =20 >>>> How does the other IETF drafts make the references to ISO = documents? ISO documents are often referenced by IETF drafts. >>>> =20 >>>> Thanks, >>>> =20 >>>> Kind Regards >>>> Kepeng >>>> = =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 >>>> Re: [TLS] Draft for SM cipher suites used in TLS1.3 >>>>=20 >>>> Rene Struik Thu, 15 August 2019 15:34 = UTCShow header >>>>=20 >>>> Hi Paul: >>>> =20 >>>> I tried and look up the documents GMT.0009-2012 and = GBT.32918.5-2016 on=20 >>>> the (non-secured) websites you referenced, but only found Chinese=20= >>>> versions (and Chinese website navigation panels [pardon my poor = language=20 >>>> skills here]). Since the ISO documents are not available to the = general=20 >>>> public without payment, it would be helpful to have a freely = available=20 >>>> document (in English) from an authoritative source. Having such a=20= >>>> reference available would be helpful to the IETF community (and=20 >>>> researchers). Please note that BSI provides its specifications in = German=20 >>>> and English, so as to foster use/study by the community. If the = Chinese=20 >>>> national algorithms would be available in similar form, this would = serve=20 >>>> a similar purpose. >>>> =20 >>>> FYI - I am interested in full details and some time last year I = tried to=20 >>>> download specs, but only Parts 2, 4, and 5 were available [1], [2], = [3],=20 >>>> not Parts 1 and 3. >>>> =20 >>>> Best regards, Rene >>>> =20 >>>> [1] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC = -=20 >>>> Part 5 - Parameter Definition (SEMB, July 24, 2018) >>>> [2] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC = -=20 >>>> Part 2 - Digital Signature Algorithm (SEMB, July 24, 2018) >>>> [3] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC = -=20 >>>> Part 4 - Public Key Encryption Algorithm (SEMB, July 24, 2018) >>>> =20 >>>> On 8/15/2019 10:16 AM, Paul Yang wrote: >>>> > Hi all, >>>> >=20 >>>> > I have submitted a new internet draft to introduce the SM cipher=20= >>>> > suites into TLS 1.3 protocol. >>>> >=20 >>>> > https://tools.ietf.org/html/draft-yang-tls-tls13-sm-suites-00 >>>> >=20 >>>> > SM cryptographic algorithms are originally a set of Chinese = national=20 >>>> > algorithms and now have been (or being) accepted by ISO as=20 >>>> > international standards, including SM2 signature algorithm, SM3 = hash=20 >>>> > function and SM4 block cipher. These algorithms have already been=20= >>>> > supported some time ago by several widely used open source=20 >>>> > cryptographic libraries including OpenSSL, BouncyCastle, Botan, = etc. >>>> >=20 >>>> > Considering TLS1.3 is being gradually adopted in China's internet=20= >>>> > industry, it's important to have a normative definition on how to = use=20 >>>> > the SM algorithms with TLS1.3, especially for the mobile internet=20= >>>> > scenario. Ant Financial is the company who develops the market = leading=20 >>>> > mobile app 'Alipay' and supports payment services for Alibaba=20 >>>> > e-commerce business. We highly are depending on the new TLS1.3=20 >>>> > protocol for both performance and security purposes. We expect to = have=20 >>>> > more deployment of TLS1.3 capable applications in China's = internet=20 >>>> > industry by this standardization attempts. >>>> >=20 >>>> > It's very appreciated to have comments from the IETF TLS list :-) >>>> >=20 >>>> > Many thanks! >>>> >=20 >>>> > _______________________________________________ >>>> > TLS mailing list >>>> > TLS@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/tls >>>> =20 >>> =20 >>> --=20 >>> email: rstruik.ext@gmail.com | Skype: rstruik >>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >> =20 >>=20 >> Regards, >> =20 >> Paul Yang >> =20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list = TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Mon Aug 19 13:26:05 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE9571207FF for ; Mon, 19 Aug 2019 13:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3p4KpNhsvgVu for ; Mon, 19 Aug 2019 13:26:02 -0700 (PDT) Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08CAD120048 for ; Mon, 19 Aug 2019 13:26:02 -0700 (PDT) Received: by mail-pl1-x62b.google.com with SMTP id go14so1505708plb.0 for ; Mon, 19 Aug 2019 13:26:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:date:subject:message-id :references:in-reply-to:to; bh=vqITb2BC8YAloy3LcAJ/TmK8QKALozNGuhiIdyebUPg=; b=0eMVp9dHu2eIN3Ve4PIbiaUxKnKd97+3OwMpZsWOF/Y8eEW4Vl8dL8GF+LiIfurvh0 rwk1GfEJ91ayftetkPmpSKxwK6sPCVV4c3TVHFpa0xxAHnP54QS22OESRTTj+K7xh+xP fwoXl0GE9wEmvo/GmC7cuGJiL74Do2hHOL7wtx9AJGIwVXBrm8fmamv2aHlgQyP0F2cL UQwF32rIN4H0ASPTCioMiHTInC15G1kDOY1AXz/TuXXJnQ9Xelo9r3HI5MxfZV6vyrG2 QsnKLBFei1Kzccbmbx42KlClK5TfWYlgT4t2yTC8yM37wj6NaivhCLl0N3JVfoPExwNU rh8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:message-id:references:in-reply-to:to; bh=vqITb2BC8YAloy3LcAJ/TmK8QKALozNGuhiIdyebUPg=; b=sC6Jvxfvz+tSICFF2gO19trkc4/LUDUp/XPjkmmPPBGBv03kFGS+iz64/s+Cj39LcD RVG5U0tbtHRX5koWbP7R2QH6sx+LHfIBddGoBoMFpPF8YbtCAuyBy77YSE5LJqIdstfe bVU+nXyLC2DL/dCcJeIhK2La6Ejzws8g9YJ70tMWBWLUSkV8QKI3/Hdi4MA7E+d1yh8j N3+0Y0GvOsNwB1oWiUQ/rJXm57kj1dl++OAMlcAbI3HWw7vOKTih0CYkpjySc64Db3xy aVf+Tayg1GoR8fhM/E3wJRRkNaKHBUzwB+bzk5m/G07GjiPqXbgcJS0W2GEPpQ4DbfJX wNBA== X-Gm-Message-State: APjAAAWYMSJecws+17ynN+yuWe/sFqwwEIoXVa0A4VCvR5MRNUuu/YMC 96EOqNjd9kwNcw2ZKmDrFc0sx4E3530= X-Google-Smtp-Source: APXvYqzna57cmNLTL/lbOzaBHptWuulEwdKW6I3jvgfq8SUqpnlMaJVSw7nhzEdXlYzyrG2SJ6rk4Q== X-Received: by 2002:a17:902:f096:: with SMTP id go22mr25085592plb.58.1566246361190; Mon, 19 Aug 2019 13:26:01 -0700 (PDT) Received: from [192.168.0.123] (243-1-237-24.gci.net. [24.237.1.243]) by smtp.gmail.com with ESMTPSA id a11sm4795758pju.2.2019.08.19.13.26.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Aug 2019 13:26:00 -0700 (PDT) From: Joseph Salowey Content-Type: multipart/alternative; boundary=Apple-Mail-C3F173C8-943C-4FCE-99A6-2C1FDA1F74B2 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Date: Mon, 19 Aug 2019 12:25:59 -0800 Message-Id: <1EED4534-F7D0-42C9-9E06-2527754ED2F6@salowey.net> References: <3350587b-f768-425f-a759-3ed7ce2e6b27.kepeng.lkp@alibaba-inc.com> <1e07a7cc-b316-6a1d-6f59-b352ffbd74b8@gmail.com> <3AA3FCE5-729F-4DA9-A3B9-52CC0CEB5571@ll.mit.edu> In-Reply-To: To: "tls@ietf.org" X-Mailer: iPhone Mail (16G77) Archived-At: Subject: [TLS] Regarding the reference to SM ciphers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Aug 2019 20:26:04 -0000 --Apple-Mail-C3F173C8-943C-4FCE-99A6-2C1FDA1F74B2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Folks, It is in the hands of the designated experts and not the working group at la= rge to determine what is an acceptable reference. Because of this we're aski= ng participants to limit their discussion on this particular aspect of this t= opic. =20 The registry policy for cipher suites is specification required as determine= d by the designated experts. The role of the designated expert is described= in [RFC8447] as: "The designated expert [RFC8126] ensures that the specification is publicly available. It is sufficient to have an Internet-Draft that is post= ed=20 and never published as an RFC) or a document from another standards body, industry consortium, university site, etc. The expert may provide more in-depth reviews, but their approval should not be taken as an endorsement of the cipher suite." Thanks,=20 Sean, Chis, and Joe [RFC8447] https://tools.ietf.org/html/rfc8447 [RFC8126] https://tools.ietf.org/html/rfc8126= --Apple-Mail-C3F173C8-943C-4FCE-99A6-2C1FDA1F74B2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Folks,

It is in the hands of the design= ated experts and not the working group at large to determine what is an acce= ptable reference. Because of this we're asking participants to limit their d= iscussion on this particular aspect of this topic.  

The registr= y policy for cipher suites is specification required as determined by the de= signated experts.  The role of the designated expert is described in [R= FC8447] as:

"The designated expert [RFC8126] ensures that the specifi= cation is
publicly available.  It is sufficient to have an Internet-= Draft that is posted 
and never published as an RFC) or a document f= rom
another standards body, industry consortium, university site, etc.The expert may provide more in-depth reviews, but their approval
should n= ot be taken as an endorsement of the cipher suite."

 Thanks,
Sean, Chis, and Joe


[RFC8447] https://tools.ietf.org/html/rfc8447
[RFC8126] https://tools.ietf.org/html/rfc81= 26
= --Apple-Mail-C3F173C8-943C-4FCE-99A6-2C1FDA1F74B2-- From nobody Tue Aug 20 02:27:01 2019 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 3228C120923; Tue, 20 Aug 2019 02:26:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Dan Romascanu via Datatracker To: Cc: draft-ietf-tls-sni-encryption.all@ietf.org, ietf@ietf.org, tls@ietf.org, dromasca@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Dan Romascanu Message-ID: <156629321117.398.16133825870734319457@ietfa.amsl.com> Date: Tue, 20 Aug 2019 02:26:51 -0700 Archived-At: Subject: [TLS] Opsdir last call review of draft-ietf-tls-sni-encryption-05 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 09:26:51 -0000 Reviewer: Dan Romascanu Review result: Ready This document targets Informational status. It is Ready from an OPS-DIR perspective and it offers valuable information for operators deploying TLS. It does not define a new protocol, thus a full RFC 5706 OPS-DIR review does not apply. It does however raise a number of operational issues in the deployment of multiplexed servers that rely on the Service Name Information (SNI) TLS extension which is a protocol element transmitted in clear text. Section 3 details the different type of attacks and lists encryption requirements for SNI that would prevent these, but notes that not all can be simultaneously met by implementations and deployments. Section 4 describes the HTTP Co-Tenancy Fronting as a solution that could be deployed in the absence of TLS-level SNI encryption. The HTTP fronting solution can be deployed without modification to the TLS protocol, and does not require using any specific version of TLS. There are however a few issues regarding discovery, client implementations, trust, and applicability which are further discussed. Operators should note that Section 5 states that 'The current HTTP based solutions described in Section 4 only meet some of these requirements. In practice, it may well be that no solution can meet every requirement, and that practical solutions will have to make some compromises.' From nobody Tue Aug 20 10:39:16 2019 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 D1FAD12011C; Tue, 20 Aug 2019 10:39:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-tls-grease@ietf.org, Sean Turner , tls-chairs@ietf.org, sean@sn3rd.com, tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <156632275485.502.9271987365148891210.idtracker@ietfa.amsl.com> Date: Tue, 20 Aug 2019 10:39:14 -0700 Archived-At: Subject: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-grease-03: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 17:39:15 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-tls-grease-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-grease/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (1) Per the following: Section 3.1 says ā€œNote that this requires no special processing on the client. Clients are already required to reject unknown values selected by the server.ā€ Section 4.1 says ā€œNote that this requires no special processing on the server. Server are already required to reject unknown values selected by the client.ā€ These statement donā€™t seem precisely right. Per Section 3.1, if a client understands GREASE enough to put it into a message to the server, and the server for some reason tries to negotiate this value, isnā€™t there ā€˜special processing' required in the client to the degree that it knows it shouldnā€™t accept the value it requested in the negotiation? (2) Section 7. Per ā€œGREASE values may not be negotiated ā€¦ā€, is there a reason this isnā€™t ā€œmust not be negotiatedā€? From nobody Wed Aug 21 11:18:24 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8575120CE0 for ; Wed, 21 Aug 2019 11:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oX2Uq9buXek2 for ; Wed, 21 Aug 2019 11:18:20 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-eopbgr810114.outbound.protection.outlook.com [40.107.81.114]) (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 5582A120DE5 for ; Wed, 21 Aug 2019 11:18:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XFxOHdTep0gdKeOVh9lnwu0YUXz1buZGRP/jvj95z8+qJS8q19cjty6fqHxLIw5p3AIiZI7rcvJO9QIRNsW4OAb2rtba3RvHcwrPwvnhkeJwslHZhOYLONeMqJNH3CNReHkEdzq3eL+jxfg/puJZkq1OVYvEiAg9rtgtQxRwgZb7XE0TaLcEV/r0k82a1A1tnr6D282Z+OLKdwnkHkjBrDajApf6TL7DpWS6a4lWOeCkqdQhNv+PO7cP6OSu7CkYGt5TtNJ9hmEn7x7QC2fEl914n+Uz7OrlxqrZUB84cpTIEcbSyqhAXl294+H/BSbasPjCWYO2zJxVjwSlMEoBTA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dNNwtbouzmtX3pIDM+TZgJd1bZnhkis3x9mZy/7+q0A=; b=PVdSHK6ZL0Z/8Je/C8A4a1fsdOe9MCn5Q6sqx//j9yUeR7hQnWDEeDNrbv68gsvRy9CFqaTEqycsK95cXh8ZSLe1Mwg4R3hcmQD91sWURJqHLkYaKrcHXETItTfbneXqvdKt3kfFCzwcUYqLWKRPbyA5cWNoWbTXq+cQiKfWPYkCdI0J0ipVrX3r6FE9Owfdbi4R8uFOdaMHhM++odXOK1Sm5/z92I9+LmGJFQ/0R80aZGRzOYfVBb1VygF490NlCM11Lh+s/bgtMQEOAB3YVGV4RmQkA41MloMFlkwE2O/2fXXGlZsQHM3r2MEbyz+8ZED9Qk5/QYO97H76eduXsQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=evequefou.be; dmarc=pass action=none header.from=evequefou.be; dkim=pass header.d=evequefou.be; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector2-evequefou-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dNNwtbouzmtX3pIDM+TZgJd1bZnhkis3x9mZy/7+q0A=; b=NUqrWKETMulhcTb0otIKwEQ/4x3T7n+M7EFC4tKBWx3D5xR5DIzmt2Tt/y/SC/t11GAyF8stWC1LVcGd1pj3HEznwH5S3xSJdfh/GiD0ovC59GJC76rNz5qUrITFw8kMm2QBwCpwi4vMkNAe1y1tbmSwHoYi1ev2CIvmqk2Tyco= Received: from BN6PR2201MB1202.namprd22.prod.outlook.com (10.174.80.146) by BN6PR2201MB1747.namprd22.prod.outlook.com (10.161.158.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2178.16; Wed, 21 Aug 2019 18:18:07 +0000 Received: from BN6PR2201MB1202.namprd22.prod.outlook.com ([fe80::b191:8036:dc83:9103]) by BN6PR2201MB1202.namprd22.prod.outlook.com ([fe80::b191:8036:dc83:9103%12]) with mapi id 15.20.2178.020; Wed, 21 Aug 2019 18:18:07 +0000 From: Mike Bishop To: Watson Ladd , TLS List Thread-Topic: [TLS] On the difficulty of technical Mandarin (SM3 related) Thread-Index: AQHVVp+V94tqVGbMFU2izzF4hE2zc6cF6zKg Date: Wed, 21 Aug 2019 18:18:07 +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=mbishop@evequefou.be; x-originating-ip: [74.215.149.36] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 33eec978-845a-4aef-ff60-08d72663eab4 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BN6PR2201MB1747; x-ms-traffictypediagnostic: BN6PR2201MB1747: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0136C1DDA4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(396003)(346002)(39830400003)(136003)(189003)(199004)(25786009)(8676002)(76116006)(5660300002)(53546011)(66446008)(446003)(71190400001)(66946007)(55016002)(102836004)(11346002)(99286004)(71200400001)(110136005)(66476007)(66556008)(64756008)(6436002)(52536014)(6506007)(316002)(229853002)(256004)(476003)(790700001)(6116002)(3846002)(53936002)(6246003)(14454004)(186003)(508600001)(2906002)(33656002)(66066001)(9686003)(81166006)(81156014)(8936002)(76176011)(6306002)(54896002)(86362001)(74316002)(7696005)(486006)(26005)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR2201MB1747; H:BN6PR2201MB1202.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: i1G8KbNmIb4uKt+E3CDQJOujRyJJzUyrqbPGf1HoZ6bh42qg1DDKqghpFfyVNyv4SPsOBR7aBmKUAeyOgvy3XZHStXVCCzFLz1V9cz/BNAPSGyREykHLU4Aksi+j9Rk4uQ5Gmodyom1XRwxTv91WzUb04kjcytffhbe97lTy185PdLMpiDNLzOhecSXd9+1l7WKh3UDeIXJfzz5BXIj1C4JFB5PhOkInM2MyT2ijGoSjDkVZFyReonFHebcDG51gM96VDMQbZjZ3o5ELEzNnDdRGUZUFqMdDbxQ8dN77i21jkPtNShrnDiq6zhm2AbNhtQ9Lz2bKRdQfUgW3Q+9JvYBdymQvD8zTj/EFZ+dm5N16n68Cx0ZGgKjsfQ2LpJD6K3LvC6XBeXcVc6kfq5x/eKp0TFTnh+dBeHXB38z0Hg4= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BN6PR2201MB1202A9F7C5C4872C185A6923DAAA0BN6PR2201MB1202_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 33eec978-845a-4aef-ff60-08d72663eab4 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Aug 2019 18:18:07.5623 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: +7xl7aaCfHfBJ9CR1KJP35y0UH6F4Ir5w0+VMM8Jn0C1vNo3jSObEIOLj3CDHHrQfc0ljkdQKMloo1ANsg4V5Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR2201MB1747 Archived-At: Subject: Re: [TLS] On the difficulty of technical Mandarin (SM3 related) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 18:18:23 -0000 --_000_BN6PR2201MB1202A9F7C5C4872C185A6923DAAA0BN6PR2201MB1202_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGFjdHVhbCByZXF1aXJlbWVudCBpbiBSRkMgODEyNiBkb2VzbuKAmXQgc2F5IHRoZSBwdWJs aWMgc3BlY2lmaWNhdGlvbiBuZWVkcyB0byBiZSBpbiBFbmdsaXNoLCBidXQgaXQgZG9lcyBzYXkg dGhhdCDigJx0aGUgZGVzaWduYXRlZCBleHBlcnQgd2lsbCByZXZpZXcgdGhlIHB1YmxpYyBzcGVj aWZpY2F0aW9uLuKAnSAgVGhpcyBzdWdnZXN0cyB0aGF0IHdoYXRldmVyIGxhbmd1YWdlIHRoZSBh dXRob3JpdGF0aXZlIHNwZWNpZmljYXRpb24gbWlnaHQgYmUgcG9zdGVkIGluLCB0aGUgZGVzaWdu YXRlZCBleHBlcnQgbmVlZHMgdG8gYmUgYWJsZSB0byB1bmRlcnN0YW5kIGl0IGFuZC9vciB0aGUg V0cgd291bGQgbmVlZCB0byBkZXNpZ25hdGUgYW4gYWx0ZXJuYXRlIGV4cGVydCBhYmxlIHRvIHJl dmlldyBpdCBhcHByb3ByaWF0ZWx5Lg0KDQpPYnZpb3VzbHksIGdpdmVuIHRoYXQgdGhlIElFVEYg d29ya3MgaW4gRW5nbGlzaCwgYW4gYXV0aG9yaXRhdGl2ZSBFbmdsaXNoLWxhbmd1YWdlIHNwZWNp ZmljYXRpb24gbWFrZXMgdGhhdCBlYXNpZXIgdG8gYWNoaWV2ZS4gIEJ1dCBhIHRyYW5zbGF0aW9u LCBldmVuIG9uZSBob3N0ZWQgYnkgYSByZXNwb25zaWJsZSBib2R5LCBhbG1vc3QgYWx3YXlzIGNv bnRhaW5zIHZlcmJpYWdlIHRoYXQgb25seSB0aGUgb3JpZ2luYWwgbGFuZ3VhZ2UgaXMgY29uc2lk ZXJlZCBhdXRob3JpdGF0aXZlLg0KDQpGcm9tOiBUTFMgPHRscy1ib3VuY2VzQGlldGYub3JnPiBP biBCZWhhbGYgT2YgV2F0c29uIExhZGQNClNlbnQ6IE1vbmRheSwgQXVndXN0IDE5LCAyMDE5IDEx OjA1IEFNDQpUbzogVExTIExpc3QgPHRsc0BpZXRmLm9yZz4NClN1YmplY3Q6IFtUTFNdIE9uIHRo ZSBkaWZmaWN1bHR5IG9mIHRlY2huaWNhbCBNYW5kYXJpbiAoU00zIHJlbGF0ZWQpDQoNCkRlYXIg YWxsLA0KDQpJIHNlZSBubyByZWFzb24gd2h5IEVuZ2xpc2ggYWxvbmUgc2hvdWxkIGJlIGFjY2Vw dGVkIGZvciBzdGFuZGFyZHMgZG9jdW1lbnRzIHdlIHJlZmVyZW5jZS4gRnJlbmNoIGFuZCBHZXJt YW4gcG9zZSBmZXcgZGlmZmljdWx0aWVzLCBhbmQgb25lIGNhbiBhbHdheXMgbGVhcm4gUnVzc2lh bi4NCg0KV2hhdCBJIGRvbid0IGtub3cgaXMgaG93IGRpZmZpY3VsdCBNYW5kYXJpbiBpcyBhdCBh IGxldmVsIHRvIHJlYWQgYSBzdGFuZGFyZHMgZG9jdW1lbnQuIEkgZXhwZWN0IHRoZSBtZWNoYW5p Y3Mgb2YgdXNpbmcgdGhlIGRpY3Rpb25hcnkgdG8gZG9taW5hdGUuDQoNCkknbSBjb25jZXJuZWQg YWJvdXQgdGhlIHRyYWNlYWJpbGl0eSBvZiB1bm9mZmljaWFsIEVuZ2xpZGggUERGcyBvbiBzb21l IHdlYnNpdGU6IGNvdWxkIHRoZSBDaGluZXNlIGJvZHkgcmVzcG9uc2libGUgaG9zdCB0aGVtIGlu c3RlYWQ/DQoNCkkgZnVsbHkgZXhwZWN0IHRoaXMgdG8gYmUgYSBtb3JlIGdlbmVyYWwgSUVURiBw cm9ibGVtLg0KDQpTaW5jZXJlbHksDQpXYXRzb24NCg== --_000_BN6PR2201MB1202A9F7C5C4872C185A6923DAAA0BN6PR2201MB1202_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5t c29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWlu IDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V UyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBhY3R1YWwgcmVxdWlyZW1lbnQgaW4gUkZD IDgxMjYgZG9lc27igJl0IHNheSB0aGUgcHVibGljIHNwZWNpZmljYXRpb24gbmVlZHMgdG8gYmUg aW4gRW5nbGlzaCwgYnV0IGl0IGRvZXMgc2F5IHRoYXQg4oCcdGhlIGRlc2lnbmF0ZWQgZXhwZXJ0 IHdpbGwgcmV2aWV3IHRoZSBwdWJsaWMgc3BlY2lmaWNhdGlvbi7igJ0mbmJzcDsgVGhpcyBzdWdn ZXN0cyB0aGF0IHdoYXRldmVyIGxhbmd1YWdlIHRoZSBhdXRob3JpdGF0aXZlIHNwZWNpZmljYXRp b24NCiBtaWdodCBiZSBwb3N0ZWQgaW4sIHRoZSBkZXNpZ25hdGVkIGV4cGVydCBuZWVkcyB0byBi ZSBhYmxlIHRvIHVuZGVyc3RhbmQgaXQgYW5kL29yIHRoZSBXRyB3b3VsZCBuZWVkIHRvIGRlc2ln bmF0ZSBhbiBhbHRlcm5hdGUgZXhwZXJ0IGFibGUgdG8gcmV2aWV3IGl0IGFwcHJvcHJpYXRlbHku PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9idmlvdXNseSwgZ2l2ZW4gdGhhdCB0aGUgSUVURiB3 b3JrcyBpbiBFbmdsaXNoLCBhbiBhdXRob3JpdGF0aXZlIEVuZ2xpc2gtbGFuZ3VhZ2Ugc3BlY2lm aWNhdGlvbiBtYWtlcyB0aGF0IGVhc2llciB0byBhY2hpZXZlLiZuYnNwOyBCdXQgYSB0cmFuc2xh dGlvbiwgZXZlbiBvbmUgaG9zdGVkIGJ5IGEgcmVzcG9uc2libGUgYm9keSwgYWxtb3N0IGFsd2F5 cyBjb250YWlucyB2ZXJiaWFnZSB0aGF0IG9ubHkgdGhlIG9yaWdpbmFsDQogbGFuZ3VhZ2UgaXMg Y29uc2lkZXJlZCBhdXRob3JpdGF0aXZlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9t OjwvYj4gVExTICZsdDt0bHMtYm91bmNlc0BpZXRmLm9yZyZndDsgPGI+T24gQmVoYWxmIE9mIDwv Yj4NCldhdHNvbiBMYWRkPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgQXVndXN0IDE5LCAyMDE5 IDExOjA1IEFNPGJyPg0KPGI+VG86PC9iPiBUTFMgTGlzdCAmbHQ7dGxzQGlldGYub3JnJmd0Ozxi cj4NCjxiPlN1YmplY3Q6PC9iPiBbVExTXSBPbiB0aGUgZGlmZmljdWx0eSBvZiB0ZWNobmljYWwg TWFuZGFyaW4gKFNNMyByZWxhdGVkKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGVh ciBhbGwsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBzZWUgbm8gcmVh c29uIHdoeSBFbmdsaXNoIGFsb25lIHNob3VsZCBiZSBhY2NlcHRlZCBmb3Igc3RhbmRhcmRzIGRv Y3VtZW50cyB3ZSByZWZlcmVuY2UuIEZyZW5jaCBhbmQgR2VybWFuIHBvc2UgZmV3IGRpZmZpY3Vs dGllcywgYW5kIG9uZSBjYW4gYWx3YXlzIGxlYXJuIFJ1c3NpYW4uJm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoYXQgSSBkb24ndCBr bm93IGlzIGhvdyBkaWZmaWN1bHQgTWFuZGFyaW4gaXMgYXQgYSBsZXZlbCB0byByZWFkIGEgc3Rh bmRhcmRzIGRvY3VtZW50LiBJIGV4cGVjdCB0aGUgbWVjaGFuaWNzIG9mIHVzaW5nIHRoZSBkaWN0 aW9uYXJ5IHRvIGRvbWluYXRlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JJ20gY29uY2VybmVkIGFib3V0IHRoZSB0cmFjZWFiaWxpdHkgb2Yg dW5vZmZpY2lhbCBFbmdsaWRoIFBERnMgb24gc29tZSB3ZWJzaXRlOiBjb3VsZCB0aGUgQ2hpbmVz ZSBib2R5IHJlc3BvbnNpYmxlIGhvc3QgdGhlbSBpbnN0ZWFkPzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGZ1bGx5IGV4cGVjdCB0aGlzIHRv IGJlIGEgbW9yZSBnZW5lcmFsIElFVEYgcHJvYmxlbS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2luY2VyZWx5LDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2F0c29uPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BN6PR2201MB1202A9F7C5C4872C185A6923DAAA0BN6PR2201MB1202_-- From nobody Wed Aug 21 14:25:57 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71C7712001E for ; Wed, 21 Aug 2019 14:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNhisfXpW_ec for ; Wed, 21 Aug 2019 14:25:46 -0700 (PDT) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC0DD120091 for ; Wed, 21 Aug 2019 14:25:46 -0700 (PDT) Received: by mail-pg1-x52b.google.com with SMTP id e11so2089354pga.5 for ; Wed, 21 Aug 2019 14:25:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pC5wIJq1Y3EGMtSMEwjkyVJrNlLOIzb/bvCDBD4i2to=; b=kwYcI3OA6b4uGxOJ2rTgD2XXEzB2lrOjlnq7uQjxUzOxc6bwxazeKBayp5NnQ/1qIB MQ6cbDeZhaX2OMw/F0QHXFS85nj4wRJjoIlmuPBgSGsLOIMHyeK6l4pHyxnVaBg/lwZJ JY9YVMLLrYZ+FhSL8g8dv/8JmvqJ0I55OPIA+2jxnJ7bctise31OnXuXOV6estW6fgsm uW3WbwF5lX5AzeHdnb46zCbXujIbZ/fpGq8pgX5m0YTraxx4Vy7qNMhElXSl8UI2huDc U0kBrGk0l4NvjWcIdwp+ok04yMq2pbTDk9jxOeNTVJ/Btv3KsEpzZb3UlOi6VwPgrxAI XGdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pC5wIJq1Y3EGMtSMEwjkyVJrNlLOIzb/bvCDBD4i2to=; b=DCnTe6nnx1nTrZmxDVJQV68qt/f+nq30HcSDBBcn7a6sBGWkjZ5Y3StEq+F27bFAln uVIBse2WE9sX1VtyNsxSjyyKrn1J9lL19CE4l7sQUZ5HgB8rROoGOKAbf7//6RUHviDx jT/wFsmPn9d0YCzF485hvI6STPPesgdSn4fR9cuN6SWNLgLsmW1jsDzH7j+yX4GhnGZJ rRbdlR66p5eFkg4XYl4Er2sZsvlA8X9v6ksaabPmpbPIz0rOHgnO2PZCN5+8Cgoqe8Kw yVSxHrwRq/aBYZjpfpiqGL4iXiNGsrJFotYsDedQEOi1FqEk3+SqxhdVTwg+TpgSR4oe sEbA== X-Gm-Message-State: APjAAAUIAhT9OA8sv4uOKNtUK6EQWRLvVv6u5dutc3nb8tjaW9WjKNSj 88Y36gn3QNWmi7g2BgKemgs+AxPA/TI0PNXql1xX X-Google-Smtp-Source: APXvYqx8zJmwnkc8JmCe09jM3A4+bOjRze+xO+6gtrfvv02LVWip7uhI/X47IS1jKxMkuQdYdk81frCLh+pGY8FJSFE= X-Received: by 2002:a17:90a:24ed:: with SMTP id i100mr2016168pje.47.1566422745821; Wed, 21 Aug 2019 14:25:45 -0700 (PDT) MIME-Version: 1.0 References: <156603473416.11195.18372949069778788332.idtracker@ietfa.amsl.com> In-Reply-To: <156603473416.11195.18372949069778788332.idtracker@ietfa.amsl.com> From: David Benjamin Date: Wed, 21 Aug 2019 17:25:28 -0400 Message-ID: To: Alexey Melnikov Cc: The IESG , draft-ietf-tls-grease@ietf.org, Sean Turner , tls-chairs , "" Content-Type: multipart/alternative; boundary="000000000000558bf60590a73755" Archived-At: Subject: Re: [TLS] Alexey Melnikov's Yes on draft-ietf-tls-grease-03: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 21:25:50 -0000 --000000000000558bf60590a73755 Content-Type: text/plain; charset="UTF-8" On Sat, Aug 17, 2019 at 5:38 AM Alexey Melnikov via Datatracker < noreply@ietf.org> wrote: > I am looking forward to this being deployed. > It already is deployed in Chrome. :-) > TLS 1.2 should be a Normative reference, despite being obsolete, as some > of the > requirements only apply to TLS 1.2. > Fair enough. Added in my local copy, which I'll upload as -04 once all the comments come in. --000000000000558bf60590a73755 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Aug 17, 2019 at 5:38 AM Alexey Me= lnikov via Datatracker <noreply@ietf= .org> wrote:
I am looking forward to this being deployed.

It already is deployed in Chrome. :-)
=C2=A0
TLS 1.2 should be a Normative reference, despite being obsolete, as some of= the
requirements only apply to TLS 1.2.

Fai= r enough. Added in my local copy, which I'll upload as -04 once all the= comments come in.
--000000000000558bf60590a73755-- From nobody Wed Aug 21 14:34:41 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03508120099 for ; Wed, 21 Aug 2019 14:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-BEtY0bWY90 for ; Wed, 21 Aug 2019 14:34:28 -0700 (PDT) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACEE1120089 for ; Wed, 21 Aug 2019 14:34:28 -0700 (PDT) Received: by mail-pf1-x435.google.com with SMTP id w16so2302679pfn.7 for ; Wed, 21 Aug 2019 14:34:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MRJiHsWXjhstB5ngxHaEh4TCrtXjmn2vcMbatuOabzM=; b=jXZweP24PKml+bbYzV59R0KQK618YJjyWsUmztGMZ/piMkZncLVEuhhhbozElbfVA9 8IpqqWHv6c46uIIYmcsx5J3Nef6rc7TuFdoDKRb0LJynwGEaRDS1yxSg9G2er6C0J9H4 9ftJ3WZ6y0B570O3tp9zG2i7rjP6RSbwNCOdi6jgOTBSU5oyNNeqfQ7l1OeLZ+UlZvqY aP0Q6Z+ixF5bgon3391BVGK8dxdFkZaJN2xyj9co3SMdo34sOe2KgI8fC4D1LWeB0h/y trJ1EIJ3UiJC51S325mZBu34DVARuhnRsinqZR2HY+a4FIHzEoAu7okQ+vQLWx6gY3am qcVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MRJiHsWXjhstB5ngxHaEh4TCrtXjmn2vcMbatuOabzM=; b=jwRPLga0sheD/aMmuA4aO56+s9VVUr4mnqX94EVeAlb1V7GKXOeJ6hlAMo8GrCthfE ysDp/MJdiba9CSJ71ZLdncY5ATmnSwA0fKF6WPm/97GAJbOrNghYBLpL+0zILIzC+DDY diHxuTxZrOJnateSNXVp5XCaj+Wxcp7fdWIfDYzBb0bVRcEkCKMOZs7ZaxEN/hg2Nmnt TDveSpMLt9ZpQ1BF2DjZc6TjnyaKIPJkojVbmt0lQtlZYKzOjn0Gdpue6I0Hqm3US2b6 gJaJ4cZYVXE+Xmo9qHAkjtbys4SmWQhzm1oGDw1dcfYRFwj1KdmrEi2TLIzWcFXvW/o8 461g== X-Gm-Message-State: APjAAAWjbTV4JC0ThF2/ETB6lzXlwM8nIefU9aNKxhM9OXl9Up/ORH8f JHIEobv4sWn95zoP4ArWsBEfIopIyjbu0oyFDWeP X-Google-Smtp-Source: APXvYqywbI2rVZ4kkuPf/17rxCqv+Him9ixqcAvvlOBeshvz4/hOLDn8CMf1iOqZRBOPRjwcl7NZzHEVyMTspaecgCI= X-Received: by 2002:aa7:8144:: with SMTP id d4mr39130801pfn.6.1566423267930; Wed, 21 Aug 2019 14:34:27 -0700 (PDT) MIME-Version: 1.0 References: <156588205271.15865.9243229289426203471.idtracker@ietfa.amsl.com> <20190815152405.GS88236@kduck.mit.edu> <44BDC996-0E18-48BE-A700-C49A101330F8@kuehlewind.net> <6BD4AC5B-BA54-4BED-8B9B-ECA298E8BF0F@kuehlewind.net> In-Reply-To: From: David Benjamin Date: Wed, 21 Aug 2019 17:34:11 -0400 Message-ID: To: Mirja Kuehlewind Cc: David Benjamin , draft-ietf-tls-grease@ietf.org, "" , Benjamin Kaduk , tls-chairs , Sean Turner , The IESG Content-Type: multipart/alternative; boundary="000000000000745e300590a75634" Archived-At: Subject: Re: [TLS] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-tls-grease-03=3A_=28with_COMMENT=29?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 21:34:31 -0000 --000000000000745e300590a75634 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Aug 19, 2019 at 3:51 AM Mirja Kuehlewind wrote: > Hi David, > > > > On 16. Aug 2019, at 18:16, David Benjamin 40google.com@dmarc.ietf.org> wrote: > > > > On Fri, Aug 16, 2019 at 3:39 AM Mirja Kuehlewind > wrote: > > > >> One comment/question: I think I didn't quite understand what a > client is > > > >> supposed to do if the connection fails with use of greasing > values...? The > > > >> security considerations seems to indicate that you should not try > to re-connect > > > >> without use of grease but rather just fail completely...? Also > should you cache > > > >> the information that greasing failed maybe? > > > > > > > > I'll let the authors chime in, but I think the sense of the securit= y > > > > considerations is more that we are preventing the fallback from bei= ng > > > > needed "in production due to "real" negotiation failures. Falling > back on > > > > GREASE failure is not as bad, provided that you follow-up with the > failing > > > > peer out of band to try to get it fixed. > > > > I don't know how much value there would be in caching the > grease-intolerate > > > > status; ideally it would almost-never happen. > > > > > > Okay, then I think it would be nice to say something more in the > document, about fallback at least. > > > > > > Ben's description is right. If deploying a new TLS feature results in > too many interop failures with existing buggy servers, that feature becom= es > difficult to deploy and there is a lot of pressure to apply some sort of > mitigation like a fallback. That's no good. GREASE's goal is to avoid the > interop failures to begin with. The text was not meant to imply that you > should do any sort of fallback. > > > > > > What change did you have in mind? The current text says: > > > > > > > Historically, when interoperability problems arise in deploying new > TLS features, implementations have used a fallback retry on error with th= e > feature disabled. This allows an active attacker to silently disable the > new feature. By preventing a class of such interoperability problems, > GREASE reduces the need for this kind of fallback. > > > > > > That reads to me as describing historical fallbacks, rather than > recommending new ones. (Indeed you shouldn't do fallbacks. Fallbacks are > bad.. They break downgrade protection.) > > > > I was thinking about adding some new text somewhere else in the documen= t > that give a recommendation if you should fallback on grease and when. > > > > I mean, the answer to that is "don't" and "never", just as is unstatedl= y > true for any other TLS extension. TLS's downgrade protection doesn't work > if you do fallbacks. While downgrading from GREASE doesn't matter per se, > it defeats the purpose, so the usual rules for TLS apply. > > > For me this wasn=E2=80=99t clear because this is not just a =E2=80=9Cnorm= al=E2=80=9D extension. If > you want to be sure that it is clear to everybody, you should write it do= wn > in the draft. However, that my view and this was a just a comment to > consider, so the authors (and group) need to decide. > Fair enough. I've added the following to that paragraph in my local copy. Implementations SHOULD NOT retry with GREASE disabled on connection failure. While allowing a= n attacker to disable GREASE is unlikely to have immediate security consequences, such a fallback would prevent GREASE from defending against extensibility failures. I'll upload it as -04 after all the comments come in. --000000000000745e300590a75634 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Aug 19, 2019 at 3:51 AM Mirja Kue= hlewind <ietf@kuehlewind.net&= gt; wrote:
Hi David,


> On 16. Aug 2019, at 18:16, David Benjamin <davidben=3D40google.com@dmarc.ietf= .org> wrote:
>
> On Fri, Aug 16, 2019 at 3:39 AM Mirja Kuehlewind <ietf@kuehlewind.net> wrote:<= br> > > >> One comment/question: I think I didn't quite underst= and what a client is
> > >> supposed to do if the connection fails with use of greas= ing values...? The
> > >> security considerations seems to indicate that you shoul= d not try to re-connect
> > >> without use of grease but rather just fail completely...= ? Also should you cache
> > >> the information that greasing failed maybe?
> > >
> > > I'll let the authors chime in, but I think the sense of = the security
> > > considerations is more that we are preventing the fallback f= rom being
> > > needed "in production due to "real" negotiati= on failures.=C2=A0 Falling back on
> > > GREASE failure is not as bad, provided that you follow-up wi= th the failing
> > > peer out of band to try to get it fixed.
> > > I don't know how much value there would be in caching th= e grease-intolerate
> > > status; ideally it would almost-never happen.
> >
> > Okay, then I think it would be nice to say something more in the = document, about fallback at least.
> >
> > Ben's description is right. If deploying a new TLS feature re= sults in too many interop failures with existing buggy servers, that featur= e becomes difficult to deploy and there is a lot of pressure to apply some = sort of mitigation like a fallback. That's no good. GREASE's goal i= s to avoid the interop failures to begin with. The text was not meant to im= ply that you should do any sort of fallback.
> >
> > What change did you have in mind? The current text says:
> >
> > > Historically, when interoperability problems arise in deploy= ing new TLS features, implementations have used a fallback retry on error w= ith the feature disabled. This allows an active attacker to silently disabl= e the new feature. By preventing a class of such interoperability problems,= GREASE reduces the need for this kind of fallback.
> >
> > That reads to me as describing historical fallbacks, rather than = recommending new ones. (Indeed you shouldn't do fallbacks. Fallbacks ar= e bad.. They break downgrade protection.)
>
> I was thinking about adding some new text somewhere else in the docume= nt that give a recommendation if you should fallback on grease and when. >
> I mean, the answer to that is "don't" and "never&qu= ot;, just as is unstatedly true for any other TLS extension. TLS's down= grade protection doesn't work if you do fallbacks. While downgrading fr= om GREASE doesn't matter per se, it defeats the purpose, so the usual r= ules for TLS apply.


For me this wasn=E2=80=99t clear because this is not just a =E2=80=9Cnormal= =E2=80=9D extension. If you want to be sure that it is clear to everybody, = you should write it down in the draft. However, that my view and this was a= just a comment to consider, so the authors (and group) need to decide.
=

Fair enough. I've added the following = to that paragraph in my local copy.

=C2=A0 =C2=A0 =C2=A0Implementati= ons SHOULD
=C2=A0 =C2=A0 =C2=A0NOT retry with GREASE disabled on c= onnection failure. While allowing an
=C2=A0 =C2=A0 =C2=A0attacker to dis= able GREASE is unlikely to have immediate security
=C2=A0 =C2=A0 =C2=A0c= onsequences, such a fallback would prevent GREASE from defending against=C2=A0 =C2=A0 =C2=A0extensibility failures.

I'll upload it= as -04 after all the comments come in.=C2=A0
--000000000000745e300590a75634-- From nobody Wed Aug 21 14:44:49 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02F52120098 for ; Wed, 21 Aug 2019 14:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jCQJWemn95R for ; Wed, 21 Aug 2019 14:44:39 -0700 (PDT) Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E309120091 for ; Wed, 21 Aug 2019 14:44:39 -0700 (PDT) Received: by mail-pf1-x429.google.com with SMTP id 196so2316459pfz.8 for ; Wed, 21 Aug 2019 14:44:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=s3DzIaG5yn1/1CgtHSJ8fuYut6oe/+M36oT5YVx4LJw=; b=EKXouLbdnmchoRKkzR9VQpsWDB8wp/zaU8nLDVuOAclDiHt/7tgWgmYThg3xwaSEvq L9qwZMVVDQxyteT7FzYTQUe3MZXi57rgTbxG4txBtS1uMpVGOuddgt/p12e6Zo+apvVu +RnqK+ch4lv4/xQL4Hj6A5kwPD/Lgp+mYOX9zd3PYISwNxIpNh8s+kXkCJUWblxztCnj fJpLzXirVOrXCoRAcj4qeESKFiCmU5heG7MisgFHvsmBmbl/cNzvqEuyCbm8GHHrH6Ju 6hGLT/6ugO01nS1QXxu0TC1dZRl7WzduznHzWQiDVh+jrNm4KIEtZHRS2IfyqHRFzyOT ypTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=s3DzIaG5yn1/1CgtHSJ8fuYut6oe/+M36oT5YVx4LJw=; b=irlR3TdZCY2SKkaGB7Fkl7NA4vuEZf39CEKnyBdeXj1tHl8CT6amFWVX7Ola6c1kW7 ynAY3BOF2ZhRyzgixnDEbKsR/Fixdj7vrKXU/TeCM7JWCTBJoJGQH6Pnjzsa6ihd02Rl QX4jnSdMEzjnW5zF/yDuwLhlH+dIOyXjOjJB926ySk310ky38tadxR5K/sskZFho3zKf PAntKWRluPGynWXhDiPkLFgZ+4UB8043mUPYyNv/nswQUTnNCZekrxNKdg3GoqfE+p4v J2Y9Z75WFAvgU/78rlwhSTvuCh20pmGdpn6SIc6dj0ZJzEL20QmRvdvXJwBq7fNmCusQ AFQA== X-Gm-Message-State: APjAAAWVcNUyXLIh8PM95JGlXC1aIyOKWwbFJmTAiAaTPAqk7STyBePu jKHJQzRupGnMTt5ASXJaM4cbMPH+qhyUNMBUA0E+ X-Google-Smtp-Source: APXvYqxxXMajTppysLAE0Ntkg+GuFgXQ1Mo8qJsXUUtsugHtJjCfzF5bn8tKoeVs21PreAJMwc1bewBaKJ8BwCj5eyY= X-Received: by 2002:a17:90a:19c4:: with SMTP id 4mr2126875pjj.20.1566423878666; Wed, 21 Aug 2019 14:44:38 -0700 (PDT) MIME-Version: 1.0 References: <156632275485.502.9271987365148891210.idtracker@ietfa.amsl.com> In-Reply-To: <156632275485.502.9271987365148891210.idtracker@ietfa.amsl.com> From: David Benjamin Date: Wed, 21 Aug 2019 17:44:22 -0400 Message-ID: To: Roman Danyliw Cc: The IESG , draft-ietf-tls-grease@ietf.org, Sean Turner , tls-chairs , "" Content-Type: multipart/alternative; boundary="000000000000db8d250590a77a52" Archived-At: Subject: Re: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-grease-03: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 21:44:42 -0000 --000000000000db8d250590a77a52 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Aug 20, 2019 at 1:39 PM Roman Danyliw via Datatracker < noreply@ietf.org> wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > (1) Per the following: > > Section 3.1 says =E2=80=9CNote that this requires no special processing o= n the > client. > Clients are already required to reject unknown values selected by the > server.=E2=80=9D > > Section 4.1 says =E2=80=9CNote that this requires no special processing o= n the > server. > Server are already required to reject unknown values selected by the > client.=E2=80=9D > > These statement don=E2=80=99t seem precisely right. Per Section 3.1, if = a client > understands GREASE enough to put it into a message to the server, and the > server for some reason tries to negotiate this value, isn=E2=80=99t there= =E2=80=98special > processing' required in the client to the degree that it knows it shouldn= =E2=80=99t > accept the value it requested in the negotiation? > I suppose it depends on how one implements it. We implemented it by just making our ClientHello, etc., serializer put add extra junk in there, so the logic for deciding what extensions are acceptable does not see it at all. I suppose, sure, if you implemented it by actually registering a fake curve, that would be a lot more complexity and probably a bad plan. How's this rephrasing? Note that this can be implemented without special processing on the client. The client is already required to reject unknown server-selected values, so it may leave GREASE values as unknown and reuse the existing logic. (And analogously for the server section.) > (2) Section 7. Per =E2=80=9CGREASE values may not be negotiated =E2=80= =A6=E2=80=9D, is there a > reason > this isn=E2=80=99t =E2=80=9Cmust not be negotiated=E2=80=9D? > That clause was meant to be descriptive of the other bits of the document. "[Such-and-such] may not be [such-and-such]ed, so [some consequence of this]". Using "must not" reads odd to me: "GREASE values must not be negotiated, so they do not directly impact the security of TLS connections.= " David --000000000000db8d250590a77a52 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Aug 20, 2019 at 1:39 PM Roman Dan= yliw via Datatracker <noreply@ietf.org> wrote:
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(1) Per the following:

Section 3.1 says =E2=80=9CNote that this requires no special processing on = the client.
Clients are already required to reject unknown values=C2=A0 selected by the= server.=E2=80=9D

Section 4.1 says =E2=80=9CNote that this requires no special processing on = the server.
Server are already required to reject unknown values selected by the client= .=E2=80=9D

These statement don=E2=80=99t seem precisely right.=C2=A0 Per Section 3.1, = if a client
understands GREASE enough to put it into a message to the server, and the server for some reason tries to negotiate this value, isn=E2=80=99t there = =E2=80=98special
processing' required in the client to the degree that it knows it shoul= dn=E2=80=99t
accept the value it requested in the negotiation?

=
I suppose it depends on how one implements it. We implemented it= by just making our ClientHello, etc., serializer put add extra junk in the= re, so the logic for deciding what extensions are acceptable does not see i= t at all. I suppose, sure, if you implemented it by actually registering a = fake curve, that would be a lot more complexity and probably a bad plan.

How's this rephrasing?

= =C2=A0 =C2=A0 =C2=A0Note that this can be implemented without special proce= ssing on the client. The client
=C2=A0 =C2=A0 =C2=A0is already required = to reject unknown server-selected values, so it
=C2=A0 =C2=A0 =C2=A0may = leave GREASE values as unknown and reuse the existing logic.
=
(And analogously for the server section.)
=C2=A0
(2) Section 7.=C2=A0 Per =E2=80=9CGREASE values may not be negotiated =E2= =80=A6=E2=80=9D, is there a reason
this isn=E2=80=99t =E2=80=9Cmust not be negotiated=E2=80=9D?

=C2=A0That clause was meant to be descriptive of the = other bits of the document. "[Such-and-such] may not be [such-and-such= ]ed, so [some consequence of this]". Using "must not" reads = odd to me: "GREASE values must not be negotiated, so they do not direc= tly impact the security of TLS connections."

= David
--000000000000db8d250590a77a52-- From nobody Wed Aug 21 17:02:35 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6EA120131; Wed, 21 Aug 2019 17:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=mTpJwKLI; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=BeIP1zPE Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ky41xBPcK-yX; Wed, 21 Aug 2019 17:02:22 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46350120125; Wed, 21 Aug 2019 17:02:22 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 870E521AF2; Wed, 21 Aug 2019 20:02:21 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Wed, 21 Aug 2019 20:02:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm3; bh=NgU/LjO+iLYdyloFmfyjOofvhDzN 7hD3tKuNZYILBWc=; b=mTpJwKLIVLD2ebkCYXHbqfuqnbK5+BpqtgRTxfah9oC6 uJ/j10uufDYC7AUxvibJH3i2PMUbp0cA9t7OAC2LrPO6+QpgDUpat1mlp4kh3Lmk cjzz3Cx8oK1WwMMw33ChMB0s8j+vzi6cZeBKuUh+/j1JWqdH+vxHVWgLWqGbRE1N tqvVdIH6ce2UNZ1zA1rJToNEZlSoFD9dhol6s+hW/Ay3a91b1OMBgyJZdHDzbfQE vBmXBC5LZ6dsuReIUXVBX2l1H3N0WGc4A8SfiRQ1Ka4zNn81KbiuWSVEJnGCK2h2 +tJYGeen5P3VgmsG66cctmWl5c5xw5bXmdKyp0enlA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=NgU/Lj O+iLYdyloFmfyjOofvhDzN7hD3tKuNZYILBWc=; b=BeIP1zPEPZ7hCIsmuEwl7H I4+CbPyBNlPRXMbNq21C5BhmmJB4Tvm69ayXVaRAhPuiFfeGbgroHJr7ndd4nB+l W6KfrIIXvffztPWNhUrny00VfEAKzf/bZS9W8Ai+RqiQSF0F+GV+adSuPHc2vACb MXD488wsdKvzF7Ag5HW7WGrjZSPPdhkZuGj7Nke1xg6+NnWC4ksKhYVUD7PyTBdW ZU2OTYm2JiqYWdf+IdANQmz3I6N5cIpYsHauHC9P3LASuAlEUG2svRZSlVQ1PmEj l+/3VHCoMXqblpKOeA60DNvixblE2dlzAeM2VWFZ0uVVV1NyJFyNXuBIpExgHy6Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudeggedgfeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreerjeenucfhrhhomhepfdforghr thhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecurf grrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvghtnecuvehl uhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id C816DE00A3; Wed, 21 Aug 2019 20:02:20 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-916-g49fca03-fmstable-20190821v7 Mime-Version: 1.0 Message-Id: <50ce91d2-bba8-4e9d-96fc-311795d89f69@www.fastmail.com> In-Reply-To: References: <156632275485.502.9271987365148891210.idtracker@ietfa.amsl.com> Date: Thu, 22 Aug 2019 10:02:01 +1000 From: "Martin Thomson" To: "David Benjamin" , "Roman Danyliw" Cc: draft-ietf-tls-grease@ietf.org, "" , "The IESG" , tls-chairs Content-Type: text/plain Archived-At: Subject: Re: [TLS] =?utf-8?q?Roman_Danyliw=27s_No_Objection_on_draft-ietf-tls?= =?utf-8?q?-grease-03=3A_=28with_COMMENT=29?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Aug 2019 00:02:24 -0000 On Thu, Aug 22, 2019, at 07:44, David Benjamin wrote: > That clause was meant to be descriptive of the other bits of the > document. "[Such-and-such] may not be [such-and-such]ed, so [some > consequence of this]". Using "must not" reads odd to me: "GREASE values > must not be negotiated, so they do not directly impact the security of > TLS connections." Perhaps what you are looking for is "cannot": "GREASE values cannot be negotiated, ..." From nobody Wed Aug 21 20:19:02 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9057120018; Wed, 21 Aug 2019 20:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCWBy7UOnNqQ; Wed, 21 Aug 2019 20:18:53 -0700 (PDT) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBB56120048; Wed, 21 Aug 2019 20:18:52 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x7M3Io2c031546; Wed, 21 Aug 2019 23:18:50 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu x7M3Io2c031546 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1566443931; bh=wNm75Pz6N5pBD5GgVdRqXMuygFwzhMGLy+AruJrLURQ=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=jjAyf73ZUwf8Y+g3ydIt9VscUPMbQyv2GzSKazSpR4lx9EaFPoMmSy72KLg1QrGR/ I0ZNLeCP5oy61BuUIhKjWPHfJXjJ0+EsgdMsnkXHpqQDtwwT7OthYemP3bPSaxiSvf Y9j54UfKAvpSCOkCFuS+bxc3056ufz746LkhSbtw= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x7M3ImBq009620; Wed, 21 Aug 2019 23:18:48 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0468.000; Wed, 21 Aug 2019 23:18:48 -0400 From: Roman Danyliw To: Martin Thomson , David Benjamin CC: "draft-ietf-tls-grease@ietf.org" , "" , The IESG , tls-chairs Thread-Topic: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-grease-03: (with COMMENT) Thread-Index: AQHVV348PAvhpEvIREShTBbFYftYbqcGZ0EAgAAmdYD///PBYA== Date: Thu, 22 Aug 2019 03:18:47 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B3439C0F@marathon> References: <156632275485.502.9271987365148891210.idtracker@ietfa.amsl.com> <50ce91d2-bba8-4e9d-96fc-311795d89f69@www.fastmail.com> In-Reply-To: <50ce91d2-bba8-4e9d-96fc-311795d89f69@www.fastmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-grease-03: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Aug 2019 03:18:55 -0000 > -----Original Message----- > From: Martin Thomson [mailto:mt@lowentropy.net] > Sent: Wednesday, August 21, 2019 8:02 PM > To: David Benjamin ; Roman > Danyliw > Cc: draft-ietf-tls-grease@ietf.org; ; The IE= SG > ; tls-chairs > Subject: Re: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-grease-= 03: > (with COMMENT) >=20 > On Thu, Aug 22, 2019, at 07:44, David Benjamin wrote: > > That clause was meant to be descriptive of the other bits of the > > document. "[Such-and-such] may not be [such-and-such]ed, so [some > > consequence of this]". Using "must not" reads odd to me: "GREASE > > values must not be negotiated, so they do not directly impact the > > security of TLS connections." >=20 > Perhaps what you are looking for is "cannot": "GREASE values cannot be > negotiated, ..." A "cannot" would make sense to me. Roman From nobody Wed Aug 21 20:31:42 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E390120018; Wed, 21 Aug 2019 20:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7QZVSD3nSevz; Wed, 21 Aug 2019 20:31:38 -0700 (PDT) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B7A01200B2; Wed, 21 Aug 2019 20:31:38 -0700 (PDT) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x7M3VaG2000497; Wed, 21 Aug 2019 23:31:36 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu x7M3VaG2000497 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1566444697; bh=wGFuHmdQogXcsb62fGcri+MewS94zVsolh1KJs8qGoM=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=raNg24bxfN6at/p43/2uo5JsxWTAs/NXrsd3B5YbkjsHx3ZknmOPvY3qq+LpFwApB EoxQMD4FVti5zx0lGIneUw1zvWVwc/pD0KZE+oCLU3+1MDC7KyOSvO426/bZANeMwe lkIaEeB4UFNzylIbne2e0Mzpeh6qh7By6eaCakcw= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x7M3VTkm016402; Wed, 21 Aug 2019 23:31:29 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0468.000; Wed, 21 Aug 2019 23:31:28 -0400 From: Roman Danyliw To: David Benjamin CC: "draft-ietf-tls-grease@ietf.org" , "" , The IESG , Sean Turner , tls-chairs Thread-Topic: Roman Danyliw's No Objection on draft-ietf-tls-grease-03: (with COMMENT) Thread-Index: AQHVV348PAvhpEvIREShTBbFYftYbqcGZ0EAgAAbK7A= Date: Thu, 22 Aug 2019 03:31:27 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B3439C82@marathon> References: <156632275485.502.9271987365148891210.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: multipart/alternative; boundary="_000_359EC4B99E040048A7131E0F4E113AFC01B3439C82marathon_" MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-grease-03: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Aug 2019 03:31:40 -0000 --_000_359EC4B99E040048A7131E0F4E113AFC01B3439C82marathon_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRGF2aWQhDQoNCkZyb206IGllc2cgW21haWx0bzppZXNnLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBEYXZpZCBCZW5qYW1pbg0KU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMjEsIDIw MTkgNTo0NCBQTQ0KVG86IFJvbWFuIERhbnlsaXcgPHJkZEBjZXJ0Lm9yZz4NCkNjOiBkcmFmdC1p ZXRmLXRscy1ncmVhc2VAaWV0Zi5vcmc7IDx0bHNAaWV0Zi5vcmc+IDx0bHNAaWV0Zi5vcmc+OyBU aGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz47IFNlYW4gVHVybmVyIDxzZWFuQHNuM3JkLmNvbT47IHRs cy1jaGFpcnMgPHRscy1jaGFpcnNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogUm9tYW4gRGFueWxp dydzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLXRscy1ncmVhc2UtMDM6ICh3aXRoIENPTU1F TlQpDQoNCk9uIFR1ZSwgQXVnIDIwLCAyMDE5IGF0IDE6MzkgUE0gUm9tYW4gRGFueWxpdyB2aWEg RGF0YXRyYWNrZXIgPG5vcmVwbHlAaWV0Zi5vcmc8bWFpbHRvOm5vcmVwbHlAaWV0Zi5vcmc+PiB3 cm90ZToNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCkNPTU1FTlQ6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCigxKSBQZXIg dGhlIGZvbGxvd2luZzoNCg0KU2VjdGlvbiAzLjEgc2F5cyDigJxOb3RlIHRoYXQgdGhpcyByZXF1 aXJlcyBubyBzcGVjaWFsIHByb2Nlc3Npbmcgb24gdGhlIGNsaWVudC4NCkNsaWVudHMgYXJlIGFs cmVhZHkgcmVxdWlyZWQgdG8gcmVqZWN0IHVua25vd24gdmFsdWVzICBzZWxlY3RlZCBieSB0aGUg c2VydmVyLuKAnQ0KDQpTZWN0aW9uIDQuMSBzYXlzIOKAnE5vdGUgdGhhdCB0aGlzIHJlcXVpcmVz IG5vIHNwZWNpYWwgcHJvY2Vzc2luZyBvbiB0aGUgc2VydmVyLg0KU2VydmVyIGFyZSBhbHJlYWR5 IHJlcXVpcmVkIHRvIHJlamVjdCB1bmtub3duIHZhbHVlcyBzZWxlY3RlZCBieSB0aGUgY2xpZW50 Li7igJ0NCg0KVGhlc2Ugc3RhdGVtZW50IGRvbuKAmXQgc2VlbSBwcmVjaXNlbHkgcmlnaHQuICBQ ZXIgU2VjdGlvbiAzLjEsIGlmIGEgY2xpZW50DQp1bmRlcnN0YW5kcyBHUkVBU0UgZW5vdWdoIHRv IHB1dCBpdCBpbnRvIGEgbWVzc2FnZSB0byB0aGUgc2VydmVyLCBhbmQgdGhlDQpzZXJ2ZXIgZm9y IHNvbWUgcmVhc29uIHRyaWVzIHRvIG5lZ290aWF0ZSB0aGlzIHZhbHVlLCBpc27igJl0IHRoZXJl IOKAmHNwZWNpYWwNCnByb2Nlc3NpbmcnIHJlcXVpcmVkIGluIHRoZSBjbGllbnQgdG8gdGhlIGRl Z3JlZSB0aGF0IGl0IGtub3dzIGl0IHNob3VsZG7igJl0DQphY2NlcHQgdGhlIHZhbHVlIGl0IHJl cXVlc3RlZCBpbiB0aGUgbmVnb3RpYXRpb24/DQoNCkkgc3VwcG9zZSBpdCBkZXBlbmRzIG9uIGhv dyBvbmUgaW1wbGVtZW50cyBpdC4gV2UgaW1wbGVtZW50ZWQgaXQgYnkganVzdCBtYWtpbmcgb3Vy IENsaWVudEhlbGxvLCBldGMuLCBzZXJpYWxpemVyIHB1dCBhZGQgZXh0cmEganVuayBpbiB0aGVy ZSwgc28gdGhlIGxvZ2ljIGZvciBkZWNpZGluZyB3aGF0IGV4dGVuc2lvbnMgYXJlIGFjY2VwdGFi bGUgZG9lcyBub3Qgc2VlIGl0IGF0IGFsbC4gSSBzdXBwb3NlLCBzdXJlLCBpZiB5b3UgaW1wbGVt ZW50ZWQgaXQgYnkgYWN0dWFsbHkgcmVnaXN0ZXJpbmcgYSBmYWtlIGN1cnZlLCB0aGF0IHdvdWxk IGJlIGEgbG90IG1vcmUgY29tcGxleGl0eSBhbmQgcHJvYmFibHkgYSBiYWQgcGxhbi4NCg0KSG93 J3MgdGhpcyByZXBocmFzaW5nPw0KDQogICAgIE5vdGUgdGhhdCB0aGlzIGNhbiBiZSBpbXBsZW1l bnRlZCB3aXRob3V0IHNwZWNpYWwgcHJvY2Vzc2luZyBvbiB0aGUgY2xpZW50LiBUaGUgY2xpZW50 DQogICAgIGlzIGFscmVhZHkgcmVxdWlyZWQgdG8gcmVqZWN0IHVua25vd24gc2VydmVyLXNlbGVj dGVkIHZhbHVlcywgc28gaXQNCiAgICAgbWF5IGxlYXZlIEdSRUFTRSB2YWx1ZXMgYXMgdW5rbm93 biBhbmQgcmV1c2UgdGhlIGV4aXN0aW5nIGxvZ2ljLg0KDQooQW5kIGFuYWxvZ291c2x5IGZvciB0 aGUgc2VydmVyIHNlY3Rpb24uKQ0KDQpbUm9tYW5dIFRoaXMgdGV4dCB3b3JrcyBmb3IgbWUuICBU aGFuayB5b3UuDQoNCigyKSBTZWN0aW9uIDcuICBQZXIg4oCcR1JFQVNFIHZhbHVlcyBtYXkgbm90 IGJlIG5lZ290aWF0ZWQg4oCm4oCdLCBpcyB0aGVyZSBhIHJlYXNvbg0KdGhpcyBpc27igJl0IOKA nG11c3Qgbm90IGJlIG5lZ290aWF0ZWTigJ0/DQoNCiBUaGF0IGNsYXVzZSB3YXMgbWVhbnQgdG8g YmUgZGVzY3JpcHRpdmUgb2YgdGhlIG90aGVyIGJpdHMgb2YgdGhlIGRvY3VtZW50LiAiW1N1Y2gt YW5kLXN1Y2hdIG1heSBub3QgYmUgW3N1Y2gtYW5kLXN1Y2hdZWQsIHNvIFtzb21lIGNvbnNlcXVl bmNlIG9mIHRoaXNdIi4gVXNpbmcgIm11c3Qgbm90IiByZWFkcyBvZGQgdG8gbWU6ICJHUkVBU0Ug dmFsdWVzIG11c3Qgbm90IGJlIG5lZ290aWF0ZWQsIHNvIHRoZXkgZG8gbm90IGRpcmVjdGx5IGlt cGFjdCB0aGUgc2VjdXJpdHkgb2YgVExTIGNvbm5lY3Rpb25zLiINCg0KW1JvbWFuXSBVbmRlcnN0 b29kLiAgVW5kZXIgc2VwYXJhdGUgY292ZXIsIE1hcnRpbiBzdWdnZXN0ZWQg4oCcY2Fubm904oCd LiAgSeKAmW0gZmxleGlibGUgb24gdGhlIGVkaXQgKGkuZS4sIGNvbnNpZGVyIHdoYXQgSSBzYWlk IGEgc3VnZ2VzdGlvbikgZ2l2ZW4gdGhlIGNsYXJpdHkgb2YgeW91ciBleHBsYW5hdGlvbiAoYW5k IHRoaXMgaXMgb25seSBhIGNvbW1lbnQpLiAgVGhhbmsgeW91Lg0K --_000_359EC4B99E040048A7131E0F4E113AFC01B3439C82marathon_ 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 dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIERhdmlkITxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48 L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IGllc2cgW21haWx0bzppZXNnLWJvdW5jZXNAaWV0Zi5v cmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkRhdmlkIEJlbmphbWluPGJyPg0KPGI+U2VudDo8L2I+ IFdlZG5lc2RheSwgQXVndXN0IDIxLCAyMDE5IDU6NDQgUE08YnI+DQo8Yj5Ubzo8L2I+IFJvbWFu IERhbnlsaXcgJmx0O3JkZEBjZXJ0Lm9yZyZndDs8YnI+DQo8Yj5DYzo8L2I+IGRyYWZ0LWlldGYt dGxzLWdyZWFzZUBpZXRmLm9yZzsgJmx0O3Rsc0BpZXRmLm9yZyZndDsgJmx0O3Rsc0BpZXRmLm9y ZyZndDs7IFRoZSBJRVNHICZsdDtpZXNnQGlldGYub3JnJmd0OzsgU2VhbiBUdXJuZXIgJmx0O3Nl YW5Ac24zcmQuY29tJmd0OzsgdGxzLWNoYWlycyAmbHQ7dGxzLWNoYWlyc0BpZXRmLm9yZyZndDs8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFJvbWFuIERhbnlsaXcncyBObyBPYmplY3Rpb24gb24g ZHJhZnQtaWV0Zi10bHMtZ3JlYXNlLTAzOiAod2l0aCBDT01NRU5UKTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBBdWcg MjAsIDIwMTkgYXQgMTozOSBQTSBSb21hbiBEYW55bGl3IHZpYSBEYXRhdHJhY2tlciAmbHQ7PGEg aHJlZj0ibWFpbHRvOm5vcmVwbHlAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5ub3JlcGx5QGll dGYub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo dDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCkNPTU1FTlQ6 PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCjxicj4NCigxKSBQZXIgdGhlIGZvbGxvd2luZzo8YnI+ DQo8YnI+DQpTZWN0aW9uIDMuMSBzYXlzIOKAnE5vdGUgdGhhdCB0aGlzIHJlcXVpcmVzIG5vIHNw ZWNpYWwgcHJvY2Vzc2luZyBvbiB0aGUgY2xpZW50LiA8YnI+DQpDbGllbnRzIGFyZSBhbHJlYWR5 IHJlcXVpcmVkIHRvIHJlamVjdCB1bmtub3duIHZhbHVlcyZuYnNwOyBzZWxlY3RlZCBieSB0aGUg c2VydmVyLuKAnTxicj4NCjxicj4NClNlY3Rpb24gNC4xIHNheXMg4oCcTm90ZSB0aGF0IHRoaXMg cmVxdWlyZXMgbm8gc3BlY2lhbCBwcm9jZXNzaW5nIG9uIHRoZSBzZXJ2ZXIuIDxicj4NClNlcnZl ciBhcmUgYWxyZWFkeSByZXF1aXJlZCB0byByZWplY3QgdW5rbm93biB2YWx1ZXMgc2VsZWN0ZWQg YnkgdGhlIGNsaWVudC4u4oCdPGJyPg0KPGJyPg0KVGhlc2Ugc3RhdGVtZW50IGRvbuKAmXQgc2Vl bSBwcmVjaXNlbHkgcmlnaHQuJm5ic3A7IFBlciBTZWN0aW9uIDMuMSwgaWYgYSBjbGllbnQ8YnI+ DQp1bmRlcnN0YW5kcyBHUkVBU0UgZW5vdWdoIHRvIHB1dCBpdCBpbnRvIGEgbWVzc2FnZSB0byB0 aGUgc2VydmVyLCBhbmQgdGhlPGJyPg0Kc2VydmVyIGZvciBzb21lIHJlYXNvbiB0cmllcyB0byBu ZWdvdGlhdGUgdGhpcyB2YWx1ZSwgaXNu4oCZdCB0aGVyZSDigJhzcGVjaWFsPGJyPg0KcHJvY2Vz c2luZycgcmVxdWlyZWQgaW4gdGhlIGNsaWVudCB0byB0aGUgZGVncmVlIHRoYXQgaXQga25vd3Mg aXQgc2hvdWxkbuKAmXQ8YnI+DQphY2NlcHQgdGhlIHZhbHVlIGl0IHJlcXVlc3RlZCBpbiB0aGUg bmVnb3RpYXRpb24/PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JIHN1cHBvc2UgaXQgZGVwZW5kcyBvbiBob3cgb25lIGltcGxlbWVu dHMgaXQuIFdlIGltcGxlbWVudGVkIGl0IGJ5IGp1c3QgbWFraW5nIG91ciBDbGllbnRIZWxsbywg ZXRjLiwgc2VyaWFsaXplciBwdXQgYWRkIGV4dHJhIGp1bmsgaW4gdGhlcmUsIHNvIHRoZSBsb2dp YyBmb3IgZGVjaWRpbmcgd2hhdCBleHRlbnNpb25zIGFyZSBhY2NlcHRhYmxlIGRvZXMgbm90IHNl ZSBpdCBhdCBhbGwuIEkgc3VwcG9zZSwgc3VyZSwNCiBpZiB5b3UgaW1wbGVtZW50ZWQgaXQgYnkg YWN0dWFsbHkgcmVnaXN0ZXJpbmcgYSBmYWtlIGN1cnZlLCB0aGF0IHdvdWxkIGJlIGEgbG90IG1v cmUgY29tcGxleGl0eSBhbmQgcHJvYmFibHkgYSBiYWQgcGxhbi48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SG93J3MgdGhpcyByZXBocmFzaW5n PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDsgJm5ic3A7ICZuYnNwO05vdGUgdGhhdCB0aGlzIGNhbiBiZSBpbXBsZW1lbnRlZCB3aXRo b3V0IHNwZWNpYWwgcHJvY2Vzc2luZyBvbiB0aGUgY2xpZW50LiBUaGUgY2xpZW50PGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDtpcyBhbHJlYWR5IHJlcXVpcmVkIHRvIHJlamVjdCB1bmtub3duIHNl cnZlci1zZWxlY3RlZCB2YWx1ZXMsIHNvIGl0PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDttYXkg bGVhdmUgR1JFQVNFIHZhbHVlcyBhcyB1bmtub3duIGFuZCByZXVzZSB0aGUgZXhpc3RpbmcgbG9n aWMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PihBbmQgYW5hbG9nb3VzbHkgZm9yIHRoZSBzZXJ2ZXIgc2VjdGlvbi4pPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5b Um9tYW5dIFRoaXMgdGV4dCB3b3JrcyBmb3IgbWUuJm5ic3A7IFRoYW5rIHlvdS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KDIpIFNlY3Rpb24gNy4mbmJzcDsgUGVyIOKAnEdSRUFT RSB2YWx1ZXMgbWF5IG5vdCBiZSBuZWdvdGlhdGVkIOKApuKAnSwgaXMgdGhlcmUgYSByZWFzb248 YnI+DQp0aGlzIGlzbuKAmXQg4oCcbXVzdCBub3QgYmUgbmVnb3RpYXRlZOKAnT88bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw O1RoYXQgY2xhdXNlIHdhcyBtZWFudCB0byBiZSBkZXNjcmlwdGl2ZSBvZiB0aGUgb3RoZXIgYml0 cyBvZiB0aGUgZG9jdW1lbnQuICZxdW90O1tTdWNoLWFuZC1zdWNoXSBtYXkgbm90IGJlIFtzdWNo LWFuZC1zdWNoXWVkLCBzbyBbc29tZSBjb25zZXF1ZW5jZSBvZiB0aGlzXSZxdW90Oy4gVXNpbmcg JnF1b3Q7bXVzdCBub3QmcXVvdDsgcmVhZHMgb2RkIHRvIG1lOiAmcXVvdDtHUkVBU0UgdmFsdWVz IG11c3Qgbm90IGJlIG5lZ290aWF0ZWQsIHNvIHRoZXkNCiBkbyBub3QgZGlyZWN0bHkgaW1wYWN0 IHRoZSBzZWN1cml0eSBvZiBUTFMgY29ubmVjdGlvbnMuJnF1b3Q7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltSb21hbl0gVW5kZXJzdG9vZC4mbmJzcDsg VW5kZXIgc2VwYXJhdGUgY292ZXIsIE1hcnRpbiBzdWdnZXN0ZWQg4oCcY2Fubm904oCdLiZuYnNw OyBJ4oCZbSBmbGV4aWJsZSBvbiB0aGUgZWRpdCAoaS5lLiwgY29uc2lkZXIgd2hhdCBJIHNhaWQg YSBzdWdnZXN0aW9uKSBnaXZlbiB0aGUgY2xhcml0eSBvZg0KIHlvdXIgZXhwbGFuYXRpb24gKGFu ZCB0aGlzIGlzIG9ubHkgYSBjb21tZW50KS4mbmJzcDsgVGhhbmsgeW91LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_359EC4B99E040048A7131E0F4E113AFC01B3439C82marathon_-- From nobody Thu Aug 22 00:48:57 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 761A81201E0; Thu, 22 Aug 2019 00:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUkKPcwXCJ4f; Thu, 22 Aug 2019 00:48:46 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 298C3120169; Thu, 22 Aug 2019 00:48:46 -0700 (PDT) Received: from 200116b82c40a900448e91e6d3aed04e.dip.versatel-1u1.de ([2001:16b8:2c40:a900:448e:91e6:d3ae:d04e]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1i0hpm-00061l-8n; Thu, 22 Aug 2019 09:48:38 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: Date: Thu, 22 Aug 2019 09:48:37 +0200 Cc: draft-ietf-tls-grease@ietf.org, Benjamin Kaduk , tls-chairs , The IESG , Sean Turner , "" Content-Transfer-Encoding: quoted-printable Message-Id: <98ECFB35-5D77-433F-A902-B96E5EB3F33A@kuehlewind.net> References: <156588205271.15865.9243229289426203471.idtracker@ietfa.amsl.com> <20190815152405.GS88236@kduck.mit.edu> <44BDC996-0E18-48BE-A700-C49A101330F8@kuehlewind.net> <6BD4AC5B-BA54-4BED-8B9B-ECA298E8BF0F@kuehlewind.net> To: David Benjamin X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1566460126;08214a05; X-HE-SMSGID: 1i0hpm-00061l-8n Archived-At: Subject: Re: [TLS] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-tls-grease-03=3A_=28with_COMMENT=29?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Aug 2019 07:48:49 -0000 Thanks! > On 21. Aug 2019, at 23:34, David Benjamin = wrote: >=20 > On Mon, Aug 19, 2019 at 3:51 AM Mirja Kuehlewind = wrote: > Hi David, >=20 >=20 > > On 16. Aug 2019, at 18:16, David Benjamin = wrote: > >=20 > > On Fri, Aug 16, 2019 at 3:39 AM Mirja Kuehlewind = wrote: > > > >> One comment/question: I think I didn't quite understand what a = client is > > > >> supposed to do if the connection fails with use of greasing = values...? The > > > >> security considerations seems to indicate that you should not = try to re-connect > > > >> without use of grease but rather just fail completely...? Also = should you cache > > > >> the information that greasing failed maybe? > > > >=20 > > > > I'll let the authors chime in, but I think the sense of the = security > > > > considerations is more that we are preventing the fallback from = being > > > > needed "in production due to "real" negotiation failures. = Falling back on > > > > GREASE failure is not as bad, provided that you follow-up with = the failing > > > > peer out of band to try to get it fixed. > > > > I don't know how much value there would be in caching the = grease-intolerate > > > > status; ideally it would almost-never happen. > > >=20 > > > Okay, then I think it would be nice to say something more in the = document, about fallback at least. > > >=20 > > > Ben's description is right. If deploying a new TLS feature results = in too many interop failures with existing buggy servers, that feature = becomes difficult to deploy and there is a lot of pressure to apply some = sort of mitigation like a fallback. That's no good. GREASE's goal is to = avoid the interop failures to begin with. The text was not meant to = imply that you should do any sort of fallback. > > >=20 > > > What change did you have in mind? The current text says: > > >=20 > > > > Historically, when interoperability problems arise in deploying = new TLS features, implementations have used a fallback retry on error = with the feature disabled. This allows an active attacker to silently = disable the new feature. By preventing a class of such interoperability = problems, GREASE reduces the need for this kind of fallback. > > >=20 > > > That reads to me as describing historical fallbacks, rather than = recommending new ones. (Indeed you shouldn't do fallbacks. Fallbacks are = bad.. They break downgrade protection.) > >=20 > > I was thinking about adding some new text somewhere else in the = document that give a recommendation if you should fallback on grease and = when. > >=20 > > I mean, the answer to that is "don't" and "never", just as is = unstatedly true for any other TLS extension. TLS's downgrade protection = doesn't work if you do fallbacks. While downgrading from GREASE doesn't = matter per se, it defeats the purpose, so the usual rules for TLS apply. >=20 >=20 > For me this wasn=E2=80=99t clear because this is not just a = =E2=80=9Cnormal=E2=80=9D extension. If you want to be sure that it is = clear to everybody, you should write it down in the draft. However, that = my view and this was a just a comment to consider, so the authors (and = group) need to decide. >=20 > Fair enough. I've added the following to that paragraph in my local = copy. >=20 > Implementations SHOULD > NOT retry with GREASE disabled on connection failure. While = allowing an > attacker to disable GREASE is unlikely to have immediate security > consequences, such a fallback would prevent GREASE from defending = against > extensibility failures. >=20 > I'll upload it as -04 after all the comments come in.=20 From nobody Thu Aug 22 08:04:12 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0921208CD for ; Thu, 22 Aug 2019 08:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbbJlrpaT9h1 for ; Thu, 22 Aug 2019 08:04:08 -0700 (PDT) Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FEC01208C6 for ; Thu, 22 Aug 2019 08:04:08 -0700 (PDT) Received: by mail-pf1-x429.google.com with SMTP id w26so4133277pfq.12 for ; Thu, 22 Aug 2019 08:04:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BeUcM3ZxxtdF68m0si98PE8hkHJVO9Lvb3Kf1MU9Ywo=; b=Rr6Gv8SfDulrxvvq064xvW7Kdkoup7Ljl23hFMyoxQpfHSQdR8Gqr/mjub0gTsBjuK gu4lQTBgRBMUFZLN0dG8zYNriwEyNeuXJ7K9PRh87GSG3xDeAlGvrNfb8AA4vZjcZSrg OHUZfbZBdsnuaCLG6fpT6Nl1i518VS4N8WUcGJEm+BHTXt4cw0YKqAMQEgNmLV7DS8U5 +385bH5zkVKhFNOcQSqL3HHT7FTI/fD36PFEY1+mQy+CIU5va0XRpKEh9i9BQ6DI4lSg 75hcPVq8Uiflv+RDNOtjATJFykniA++peRPYRFaFSSvAOxuUZgWcPINjkeCIz6Gi+Xm/ yuyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BeUcM3ZxxtdF68m0si98PE8hkHJVO9Lvb3Kf1MU9Ywo=; b=eONCkfuKQ09LkCoGSm1+EJ8vsMRPHtJpHUc3yPl0isKyA7E4P0Wqz10eR86ZhIHi39 BXkQKsk6lR6GEMboVHpOyxe3Pa+ZlYG36t+SdZD4Qf8tIV0vJ45DtRuLAMXo8LrdCe22 SRJsnTR37iIOkq8G4ooiMvMtsRKb9wjVLLPzaIZ0XSbiLbiOtxg8E+1Hcr0Hu77iVR2y zAHJ7sciHpyniZIfhVVKiZja2yaSib4HY8bOgzYLdjEMDbu5olhCCfUTxLDcXd8RGd9i xXR59lW+FYz9yPFV6CnaMraKCLlcxTySSS/0nPuhKgg0RqcwVCNWV+XA82Hso+wQqp6X YqgQ== X-Gm-Message-State: APjAAAXgCLMVm6YEw4sikpmASIQp2x1v4lczbtFS3EDrydx6u/eTm9Uw BpLfxdumzMSCGczjtvMyHtrz3M1S9kbNCpcH3B4Y X-Google-Smtp-Source: APXvYqxHt98RtrKkY0vuoIDQVK8uvFmDspTs2hL4BgiQIPzoTw5fouHoDeUGSijonSMv6FbNn1Y2mmSa5vWXqz2Q480= X-Received: by 2002:a63:7b4d:: with SMTP id k13mr33425289pgn.182.1566486247199; Thu, 22 Aug 2019 08:04:07 -0700 (PDT) MIME-Version: 1.0 References: <156632275485.502.9271987365148891210.idtracker@ietfa.amsl.com> <50ce91d2-bba8-4e9d-96fc-311795d89f69@www.fastmail.com> <359EC4B99E040048A7131E0F4E113AFC01B3439C0F@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01B3439C0F@marathon> From: David Benjamin Date: Thu, 22 Aug 2019 11:03:50 -0400 Message-ID: To: Roman Danyliw Cc: Martin Thomson , David Benjamin , "draft-ietf-tls-grease@ietf.org" , "" , The IESG , tls-chairs Content-Type: multipart/alternative; boundary="0000000000004fd0cb0590b60036" Archived-At: Subject: Re: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-grease-03: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Aug 2019 15:04:10 -0000 --0000000000004fd0cb0590b60036 Content-Type: text/plain; charset="UTF-8" On Wed, Aug 21, 2019 at 11:18 PM Roman Danyliw wrote: > > > > -----Original Message----- > > From: Martin Thomson [mailto:mt@lowentropy.net] > > Sent: Wednesday, August 21, 2019 8:02 PM > > To: David Benjamin ; Roman > > Danyliw > > Cc: draft-ietf-tls-grease@ietf.org; ; The > IESG > > ; tls-chairs > > Subject: Re: [TLS] Roman Danyliw's No Objection on > draft-ietf-tls-grease-03: > > (with COMMENT) > > > > On Thu, Aug 22, 2019, at 07:44, David Benjamin wrote: > > > That clause was meant to be descriptive of the other bits of the > > > document. "[Such-and-such] may not be [such-and-such]ed, so [some > > > consequence of this]". Using "must not" reads odd to me: "GREASE > > > values must not be negotiated, so they do not directly impact the > > > security of TLS connections." > > > > Perhaps what you are looking for is "cannot": "GREASE values cannot be > > negotiated, ..." > > A "cannot" would make sense to me. > "cannot" it is! :-) David --0000000000004fd0cb0590b60036 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Aug 21, 2019 at 11:18 PM Roman Da= nyliw <rdd@cert.org> wrote:


> -----Original Message-----
> From: Martin Thomson [mailto:mt@lowentropy.net]
> Sent: Wednesday, August 21, 2019 8:02 PM
> To: David Benjamin <davidben=3D40google.com@dmarc.ietf.org>; Roman
> Danyliw <rdd@cert= .org>
> Cc: draft-ietf-tls-grease@ietf.org; <tls@ietf.org> <tls@ietf.org>; The IESG
> <iesg@ietf.org>; tls-chairs <tls-chairs@ietf.org>
> Subject: Re: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-= grease-03:
> (with COMMENT)
>
> On Thu, Aug 22, 2019, at 07:44, David Benjamin wrote:
> >=C2=A0 That clause was meant to be descriptive of the other bits o= f the
> > document. "[Such-and-such] may not be [such-and-such]ed, so = [some
> > consequence of this]". Using "must not" reads odd = to me: "GREASE
> > values must not be negotiated, so they do not directly impact the=
> > security of TLS connections."
>
> Perhaps what you are looking for is "cannot": "GREASE v= alues cannot be
> negotiated, ..."

A "cannot" would make sense to me.

"cannot" it is! :-)

David=C2=A0
--0000000000004fd0cb0590b60036-- From nobody Thu Aug 22 09:08:40 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDFCC1200F5 for ; Thu, 22 Aug 2019 09:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZrvPLsW-W0fr for ; Thu, 22 Aug 2019 09:08:34 -0700 (PDT) Received: from out0-157.mail.aliyun.com (out0-157.mail.aliyun.com [140.205.0.157]) (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 8B9821208B3 for ; Thu, 22 Aug 2019 09:08:32 -0700 (PDT) X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R121e4; CH=green; DM=||false|; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03275; MF=kaishen.yy@antfin.com; NM=1; PH=DS; RN=3; SR=0; TI=SMTPD_---.FGWOn3j_1566490103; Received: from 10.65.141.48(mailfrom:kaishen.yy@antfin.com fp:SMTPD_---.FGWOn3j_1566490103) by smtp.aliyun-inc.com(127.0.0.1); Fri, 23 Aug 2019 00:08:24 +0800 From: Paul Yang Message-Id: <6C74B593-C6D7-4D2E-97D8-90935E01A65E@antfin.com> Content-Type: multipart/signed; boundary="Apple-Mail=_E463D031-AB81-4461-AA1F-601D0C588D69"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 23 Aug 2019 00:08:23 +0800 In-Reply-To: Cc: Kepeng Li , "tls@ietf.org" To: "Blumenthal, Uri - 0553 - MITLL" References: <20a27f61-98cf-4b2c-b6a8-e25aabd56099.kepeng.lkp@alibaba-inc.com> <83CBB97A-A3D3-48AC-9B1B-35557EE4CC95@antfin.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] (offline) Re: Draft for SM cipher suites used in TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Aug 2019 16:08:39 -0000 --Apple-Mail=_E463D031-AB81-4461-AA1F-601D0C588D69 Content-Type: multipart/alternative; boundary="Apple-Mail=_B1AC7792-1F7F-45A0-B4AC-653A95A85542" --Apple-Mail=_B1AC7792-1F7F-45A0-B4AC-653A95A85542 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi there, Just to keep the it consistent with what previous email said - the = Markdown file of the draft has been pushed to the repo: https://github.com/alipay/tls13-sm-spec = Please check: https://github.com/alipay/tls13-sm-spec/blob/master/BUILD.md = for detailed information. Thanks. > On Aug 19, 2019, at 10:57 PM, Blumenthal, Uri - 0553 - MITLL = wrote: >=20 > > A side note: we will also upload the Markdown file of this draft = into the same git > > repository at https://github.com/alipay/tls13-sm-spec = later to make it a totally > > public involved progress. >=20 > I think this is exactly what was needed/asked-for. Thank you! >=20 >=20 >> On Aug 19, 2019, at 7:51 PM, Kepeng Li > wrote: >>=20 >> Currently, we uploaded some of the referenced documents here: >> https://github.com/alipay/tls13-sm-spec = >>=20 >> @Rene, Parts 1 and 3 can be found in the link above. >>=20 >> Hope it helps. >>=20 >> Thanks, >>=20 >> Kind Regards >> Kepeng >>=20 >>> ------------------------------------------------------------------ >>> =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A=E6=9D=8E=E5=85=8B=E9=B9=8F(=E6=98= =93=E6=B7=B1) > >>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4=EF=BC=9A2019=E5=B9=B48=E6=9C=8819= =E6=97=A5(=E6=98=9F=E6=9C=9F=E4=B8=80) 17:38 >>> =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9Asean+ietf >; joe >; caw > >>> =E6=8A=84=E3=80=80=E9=80=81=EF=BC=9Atls@ietf.org = >; "Blumenthal, = Uri - 0553 - MITLL" >; Paul Yang = > >>> =E4=B8=BB=E3=80=80=E9=A2=98=EF=BC=9ARe: [TLS] (offline) Re: Draft = for SM cipher suites used in TLS1.3 >>>=20 >>> Hi WG chairs, >>>=20 >>> Can we place the referenced documents in the TLS WG GitHub? >>> https://github.com/tlswg >>>=20 >>> According to the discussion below, this can help people to read and = understand the referenced specifications. >>>=20 >>> Thanks, >>>=20 >>> Kind Regards >>> Kepeng >>>=20 >>> =E5=8F=91=E4=BB=B6=E4=BA=BA: TLS > =E4=BB=A3=E8=A1=A8 "Blumenthal, Uri - = 0553 - MITLL" > >>> =E6=97=A5=E6=9C=9F: 2019=E5=B9=B48=E6=9C=8818=E6=97=A5 =E6=98=9F=E6=9C= =9F=E6=97=A5 22:08 >>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Paul Yang = > >>> =E6=8A=84=E9=80=81: "tls@ietf.org " = > >>> =E4=B8=BB=E9=A2=98: Re: [TLS] (offline) Re: Draft for SM cipher = suites used in TLS1.3 >>>=20 >>> IMHO, placing the documents on GitHub would be perfect, and quite = sufficient. >>>=20 >>> Please make sure to post the name of the repo here. ;/) >>>=20 >>> I leave it to others to decide whether they'd want copies of today = PDF files sent to the mailing list directly. >>>=20 >>> Regards, >>> Uri >>>=20 >>> Sent from my iPhone >>>=20 >>> On Aug 17, 2019, at 01:03, Paul Yang = > wrote: >>>=20 >>> Good points. >>>=20 >>> The good news is that we have found some English PDFs of SM2, = including the missing part 1 and part 3. Will continue to find English = translations of other SM standards mentioned in the draft. >>>=20 >>> So, if we host a free website, say on Github or so, to provide those = docs, is it convenient for you guys? Or should we just drop the PDF = files to this mailing list as attachments? >>>=20 >>>=20 >>> On Aug 16, 2019, at 10:58 PM, Rene Struik > wrote: >>>=20 >>> Arguably, "national" crypto specifications garnish more stature if = these are made available to the pubic by that standard-setting body = itself (who, thereby, acts as its authoritative source), without = deference to a third party (that may, independently from the originator, = enforce document control [e.g., by effectuating technical changes or = enforcing controlled dissemination]). >>>=20 >>> Since your draft introducing SM cipher suites with TLS1.3 appeals to = the authority of a standard-setting authority, easy availability of the = full and accredited technical documentation to the IETF community helps = in scrutiny and, e.g., evaluating claims in the security considerations = section. >>>=20 >>> On 8/16/2019 3:06 AM, Kepeng Li wrote: >>> Hi Rene and all, >>>=20 >>> > Since the ISO documents are not available to the general >>> > public without payment, it would be helpful to have a freely = available >>> > document (in English) from an authoritative source. Having such a >>> > reference available would be helpful to the IETF community (and >>> > researchers). >>> About the references to ISO documens, I think it is a general issue = for IETF drafts. >>>=20 >>> How does the other IETF drafts make the references to ISO documents? = ISO documents are often referenced by IETF drafts. >>>=20 >>> Thanks, >>>=20 >>> Kind Regards >>> Kepeng >>> = =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 >>> Re: [TLS] Draft for SM cipher suites used in TLS1.3 >>>=20 >>> Rene Struik > = Thu, 15 August 2019 15:34 UTCShow header = >>> Hi Paul: >>>=20 >>> I tried and look up the documents GMT.0009-2012 and GBT.32918.5-2016 = on >>> the (non-secured) websites you referenced, but only found Chinese >>> versions (and Chinese website navigation panels [pardon my poor = language >>> skills here]). Since the ISO documents are not available to the = general >>> public without payment, it would be helpful to have a freely = available >>> document (in English) from an authoritative source. Having such a >>> reference available would be helpful to the IETF community (and >>> researchers). Please note that BSI provides its specifications in = German >>> and English, so as to foster use/study by the community. If the = Chinese >>> national algorithms would be available in similar form, this would = serve >>> a similar purpose. >>>=20 >>> FYI - I am interested in full details and some time last year I = tried to >>> download specs, but only Parts 2, 4, and 5 were available [1], [2], = [3], >>> not Parts 1 and 3. >>>=20 >>> Best regards, Rene >>>=20 >>> [1] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC = - >>> Part 5 - Parameter Definition (SEMB, July 24, 2018) >>> [2] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC = - >>> Part 2 - Digital Signature Algorithm (SEMB, July 24, 2018) >>> [3] China ECC - Public Key Cryptographic Algorithm SM2 Based on ECC = - >>> Part 4 - Public Key Encryption Algorithm (SEMB, July 24, 2018) >>>=20 >>> On 8/15/2019 10:16 AM, Paul Yang wrote: >>> > Hi all, >>> > >>> > I have submitted a new internet draft to introduce the SM cipher >>> > suites into TLS 1.3 protocol. >>> > >>> > https://tools.ietf.org/html/draft-yang-tls-tls13-sm-suites-00 = >>> > >>> > SM cryptographic algorithms are originally a set of Chinese = national >>> > algorithms and now have been (or being) accepted by ISO as >>> > international standards, including SM2 signature algorithm, SM3 = hash >>> > function and SM4 block cipher. These algorithms have already been >>> > supported some time ago by several widely used open source >>> > cryptographic libraries including OpenSSL, BouncyCastle, Botan, = etc. >>> > >>> > Considering TLS1.3 is being gradually adopted in China's internet >>> > industry, it's important to have a normative definition on how to = use >>> > the SM algorithms with TLS1.3, especially for the mobile internet >>> > scenario. Ant Financial is the company who develops the market = leading >>> > mobile app 'Alipay' and supports payment services for Alibaba >>> > e-commerce business. We highly are depending on the new TLS1.3 >>> > protocol for both performance and security purposes. We expect to = have >>> > more deployment of TLS1.3 capable applications in China's internet >>> > industry by this standardization attempts. >>> > >>> > It's very appreciated to have comments from the IETF TLS list :-) >>> > >>> > Many thanks! >>> > >>> > _______________________________________________ >>> > TLS mailing list >>> > TLS@ietf.org >>> > https://www.ietf.org/mailman/listinfo/tls = >>>=20 >>>=20 >>> -- >>> email: rstruik.ext@gmail.com | Skype: = rstruik >>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls = >>>=20 >>>=20 >>> Regards, >>>=20 >>> Paul Yang >>>=20 >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls = >>> _______________________________________________ TLS mailing list = TLS@ietf.org = https://www.ietf.org/mailman/listinfo/tls = >=20 >=20 > Regards, >=20 > Paul Yang Regards, Paul Yang --Apple-Mail=_B1AC7792-1F7F-45A0-B4AC-653A95A85542 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = there,

Just to keep = the it consistent with what previous email said - the Markdown file of = the draft has been pushed to the repo:

https://github.com/alipay/tls13-sm-spec

Please check:

https://github.com/alipay/tls13-sm-spec/blob/master/BUILD.md

for detailed = information.

Thanks.

On Aug 19, 2019, at 10:57 PM, = Blumenthal, Uri - 0553 - MITLL <uri@ll.mit.edu> wrote:

>  = A side note: we will also upload the Markdown file of this draft into = the same git 
        >  = repository at https://github.com/alipay/tls13-sm-spec later to = make it a totally
        >  public involved = progress.
 
I think this is exactly what was needed/asked-for. Thank = you!


On Aug 19, 2019, at 7:51 PM, Kepeng Li = <kepeng.lkp@alibaba-inc.com> wrote:
 
Currently, we uploaded some of the referenced documents = here:
https://github.com/alipay/tls13-sm-spec
 
@Rene, Parts 1 and 3 can be found in the link = above.
 
Hope it helps.
 
Thanks,
 
Kind Regards
Kepeng
 
---------------------------------------------------------------= ---
=E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A=E6=9D=8E=E5=85=8B=E9=B9=8F(=E6=98=93=E6=B7=B1) <kepeng.lkp@antfin.com>
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4=EF=BC=9A2019=E5=B9=B48=E6=9C=8819=E6=97=A5(=E6=98=9F=E6=9C=9F=E4=B8=80) 17:38
=E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9Asean+ietf <sean+ietf@sn3rd.com>; = joe <joe@salowey.net>; caw <caw@heapingbits.net>
=E6=8A=84=E3=80=80=E9=80=81=EF=BC=9Atls@ietf.org <tls@ietf.org>; "Blumenthal, Uri - 0553 - MITLL" = <uri@ll.mit.edu>; Paul Yang <kaishen.yy=3D40alipay.com@dmarc.ietf.org><= span style=3D"font-size: 9pt; font-family: Helvetica;" class=3D"">
=E4=B8=BB=E3=80=80=E9=A2=98=EF=BC=9ARe: [TLS] (offline) Re: Draft for SM cipher suites used in = TLS1.3
 
Hi WG chairs,
 
Can we = place the referenced documents in the TLS WG GitHub?
https://github.com/tlswg
 
According = to the discussion below, this can help people to read and understand the = referenced specifications.
 
Thanks,
 
Kind Regards
Kepeng 
 
=E5=8F=91=E4=BB=B6=E4=BA=BA: TLS <tls-bounces@ietf.org> =E4=BB=A3=E8=A1=A8 "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
=E6=97=A5=E6=9C=9F: 2019=E5=B9=B48=E6=9C=8818=E6=97=A5 =E6=98=9F=E6=9C=9F=E6=97=A5 22:08
=E6=94=B6=E4=BB=B6=E4=BA=BA: Paul Yang <kaishen.yy=3D40alipay.com@dmarc.ietf.org>
=E6=8A=84=E9=80=81: "tls@ietf.org" <tls@ietf.org>
=E4=B8=BB=E9=A2=98: Re: [TLS] (offline) Re: Draft for = SM cipher suites used in TLS1.3
 
IMHO, placing the documents on GitHub would be = perfect, and quite sufficient. 
 
Please make = sure to post the name of the repo here. ;/)
 

I leave it to = others to decide whether they'd want copies of today PDF files sent to = the mailing list directly.

Regards,
Uri
 
Sent from my iPhone


On Aug 17, 2019, at = 01:03, Paul Yang <kaishen.yy=3D40alipay.com@dmarc.ietf.org> = wrote:

Good = points.
 
The good news is that we have found = some English PDFs of SM2, including the missing part 1 and part 3. Will = continue to find English translations of other SM standards mentioned in = the draft.
 
So, if we host a free website, say on = Github or so, to provide those docs, is it convenient for you guys? Or = should we just drop the   PDF files to this mailing list as = attachments?

 

On Aug 16, = 2019, at 10:58 PM, Rene Struik <rstruik.ext@gmail.com> wrote:
 
Arguably, "national" crypto specifications garnish more = stature if these are made available to the pubic by that = standard-setting body itself (who, thereby, acts as its authoritative = source), without deference to a third party (that may, independently = from the originator, enforce document control [e.g., by effectuating = technical changes or enforcing controlled dissemination]).
 
Since your draft introducing SM cipher = suites with TLS1.3 appeals to the authority of a standard-setting = authority, easy availability of the full and accredited technical = documentation to the IETF community helps in scrutiny and, e.g., = evaluating claims in the security considerations section.
 
On 8/16/2019 3:06 AM, Kepeng Li = wrote:
Hi Rene and all,
 
> Since the ISO documents are not available to the general =

> public =
without payment, it would be helpful to have a freely available =

> document (in =
English) from an authoritative source. Having such a 
> reference available would be helpful =
to the IETF community (and 
> =
researchers).
About the references to ISO documens, I think it = is a general issue for IETF drafts.
 
How does the other IETF = drafts make the references to ISO documents? ISO documents are often = referenced by IETF drafts.
 
Thanks,
 
Kind Regards
Kepeng
=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94

Re: [TLS] Draft for SM cipher suites used in = TLS1.3

Rene Struik <rstruik.ext@gmail.com> Thu, 15 August 2019 = 15:34 UTCShow = header

Hi Paul:
 
I tried and look up the documents GMT.0009-2012 and =
GBT.32918.5-2016 on 
the (non-secured) websites you =
referenced, but only found Chinese 
versions (and Chinese website navigation panels [pardon my =
poor language 
skills here]). Since the ISO =
documents are not available to the general 
public without payment, it would be helpful to have a freely =
available 
document (in English) from an =
authoritative source. Having such a 
reference available would be helpful to the IETF community =
(and 
researchers). Please note that BSI =
provides its specifications in German 
and English, so as to foster use/study by the community. If =
the Chinese 
national algorithms would be =
available in similar form, this would serve 
a similar purpose.
 
FYI - I am interested in full details and some time last year =
I tried to 
download specs, but only Parts 2, 4, =
and 5 were available [1], [2], [3], 
not Parts 1 and 3.
 
Best regards, Rene
 
[1] China ECC - Public Key Cryptographic Algorithm SM2 Based =
on ECC - 
Part 5 - Parameter Definition (SEMB, =
July 24, 2018)
[2] China ECC - Public Key =
Cryptographic Algorithm SM2 Based on ECC - 
Part 2 - Digital Signature Algorithm (SEMB, July 24, =
2018)
[3] China ECC - Public Key =
Cryptographic Algorithm SM2 Based on ECC - 
Part 4 - Public Key Encryption Algorithm (SEMB, July 24, =
2018)
 
On 8/15/2019 10:16 AM, Paul Yang wrote:
> Hi all,
> 
> I have submitted a new internet draft to introduce the =
SM cipher 
> suites into TLS 1.3 =
protocol.
> 
> https://tools.ietf.org/html/draft-yang-tls-tls13-sm-suites-00
> 
> SM cryptographic algorithms are originally a set of =
Chinese national 
> algorithms and now have been =
(or being) accepted by ISO as 
> international standards, =
including SM2 signature algorithm, SM3 hash 
> function and SM4 block cipher. These algorithms have =
already been 
> supported some time ago by =
several widely used open source 
> cryptographic libraries =
including OpenSSL, BouncyCastle, Botan, etc.
> 
> Considering TLS1.3 is being =
gradually adopted in China's internet 
> industry, it's important to have a normative definition =
on how to use 
> the SM algorithms with TLS1.3, =
especially for the mobile internet 
> scenario. Ant Financial is the company who develops the =
market leading 
> mobile app 'Alipay' and =
supports payment services for Alibaba 
> e-commerce business. We highly are depending on the new =
TLS1.3 
> protocol for both performance =
and security purposes. We expect to have 
> more deployment of TLS1.3 capable applications in =
China's internet 
> industry by this =
standardization attempts.
> 
> It's very appreciated to have comments from the IETF TLS =
list :-)
> 
> Many thanks!
> 
> =
_______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
 
 
-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
 

Regards,
 
Paul Yang
 
_______________________________________________
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
=
 

Regards,
 
Paul = Yang


Regards,

Paul Yang

= --Apple-Mail=_B1AC7792-1F7F-45A0-B4AC-653A95A85542-- --Apple-Mail=_E463D031-AB81-4461-AA1F-601D0C588D69 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEndC1x/yVcklg1DZ15HtIVEj/IsoFAl1evfcACgkQ5HtIVEj/ IsoMMxAAjIYI35VV/WDcym3bwsOgslMvXZmtmDtbRnZlmDJDToOhwTEpm7ZieBc6 WfKwGn2TzTfNBhgdj1FXzaJtLmVfdBGIjUmsWUjqThdm/Xm7nL9Itq/rET95n3+9 1orf43OIfpofHIi1uNsQr6dYtlXxO/a+w78EtTBWlXfXYuuf3Qvj9og37f/ywzEQ RRpZ53QXWqKwwSxTIa/zBYGqWLKDs2ovBNKnt+I+nnolLdtDW4OVZYnKU4HCYcbG 5lVnFRgd9OXKH9oRznxLg6wz/5SujdA100Ou19OBC8nxioEhUkWsBlCG3yOdhwmT tXb0HM7+CrSU4zfuVfZ6xLOzjwEjdlapvEWQv6g7Kp11SjxdknXFOR66kgC4+q0g CMshY/A6uShcUweax9XMrE4oNzfOzIC8PWEMnx6dki3Geaz72hoLRqgy6S6ZxYL6 s0E7fzk0qbO+Sy3Uc6Gi6IM0UllTX5NXrj9NFF1HgZSGDErdlO9NE7Nas6frEQjz v9vDGQAHH+j9n7I9sU3bPx01x2VjM2rFj0aGvd9iyzZIKMeVdnOedUdY7UYnhFT4 2loKe/3zywtbNP6vUbSmx0DXwULFg7gRecEpjyvF0Bo7KWLMh2oRCpm3sMRLkx3Z YLwtCcabVXFc5adMwd4FfQklylOVn+yFA7lUHnSDo+KDidkbLIM= =zcG8 -----END PGP SIGNATURE----- --Apple-Mail=_E463D031-AB81-4461-AA1F-601D0C588D69-- From nobody Thu Aug 22 10:42:12 2019 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 A92CC120A9B; Thu, 22 Aug 2019 10:42:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <156649572460.14874.7686895862190865773@ietfa.amsl.com> Date: Thu, 22 Aug 2019 10:42:04 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-grease-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list for 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 Aug 2019 17:42:05 -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 WG of the IETF. Title : Applying GREASE to TLS Extensibility Author : David Benjamin Filename : draft-ietf-tls-grease-04.txt Pages : 12 Date : 2019-08-22 Abstract: This document describes GREASE (Generate Random Extensions And Sustain Extensibility), a mechanism to prevent extensibility failures in the TLS ecosystem. It reserves a set of TLS protocol values that may be advertised to ensure peers correctly handle unknown values. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-grease/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-grease-04 https://datatracker.ietf.org/doc/html/draft-ietf-tls-grease-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-grease-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Aug 22 11:22:10 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34E1A120ABB for ; Thu, 22 Aug 2019 11:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adaqyz5t1dGw for ; Thu, 22 Aug 2019 11:22:00 -0700 (PDT) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 517D7120ABC for ; Thu, 22 Aug 2019 11:22:00 -0700 (PDT) Received: by mail-pf1-x435.google.com with SMTP id v12so4494858pfn.10 for ; Thu, 22 Aug 2019 11:22:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5yIFDH0Eqdn/bNZS6Dl4gTA7zV8PMJYUS4EHKWN5lIc=; b=WVchl5ZNzejvvaRl0++RkL+HiMtSc+xUW2iDkb211Lm3syGXUupSlm33WPc69GCPEj 6kPXV+tkGJxzIXpX9j3mep+l1g/M0d0ADDfvlWwyKmFYyK+z655wnBGxhQzymSJVxvRg +W/9osjwWeJTvBz4LQzIoL8eydCl5pXO+NP/P6fJgWr0Lbl+XqBkEygp4BInNDi1oEdj utmu/+62vgNBxzeA1wbKbCQ6/zEytIRz/qqR5HaOPz+aXZeHE7JgkZDuznB+9OYbC0qm Gj8XAEabGMafRnMTpN8l4/rmhqI2CyqudQnTSsCKRFa3cjfcHdNOQVZ/UDyWXQ5JlsFy 0XdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5yIFDH0Eqdn/bNZS6Dl4gTA7zV8PMJYUS4EHKWN5lIc=; b=THau6V/uoaM4nWAlAjihJg4nxY0ROjx/vpyVwV9PKIiZO7DeLN3WU4Y7wLUNihktNP E/mw2jMDBhDxHYhAQK0Z1guNbF2iZM+1go5gOaoF0legBQQh7zaMlsNBQmGyXZrzCJqt K8db6Lnj+HKDdIBjE95KWrEskmKTlC9KhYkZZj4eoJ6jA2JTcANggUVulBSnt5Eq0Abc mWLRpIlXjJaQbyrrkWtrIqpotLutNkpb9LncAmzVitCE9sEuNTaIISKij98J/5ya0Lts QKZqKIqw5gk4Vnw8x4an5vet5FTcCLaOHkIZMzrGkR1PO4yOKAk1YHYT9Fs6Q62Pc9Nh 5Byw== X-Gm-Message-State: APjAAAU54NQhXTCGhBzIxx+ULLMVuUi2SH+M4WD5aQMxV5Ax0dF4OP1y DCTuthDUIjqfXAfJnVS0La30GF4yIP0F6MgB9aQl X-Google-Smtp-Source: APXvYqxTCtpgm86Xvnyjo0FJG6NQPBTInhY4eLvooM4Cf4DHJC0nMy4cDOuLzfBDAO4HUoGXhml+wuCxxFBlDf5t2oU= X-Received: by 2002:aa7:8490:: with SMTP id u16mr621174pfn.6.1566498119398; Thu, 22 Aug 2019 11:21:59 -0700 (PDT) MIME-Version: 1.0 References: <156603473416.11195.18372949069778788332.idtracker@ietfa.amsl.com> In-Reply-To: From: David Benjamin Date: Thu, 22 Aug 2019 14:21:42 -0400 Message-ID: To: Alexey Melnikov Cc: The IESG , draft-ietf-tls-grease@ietf.org, Sean Turner , tls-chairs , "" , Benjamin Kaduk Content-Type: multipart/alternative; boundary="000000000000f312130590b8c3a3" Archived-At: Subject: Re: [TLS] Alexey Melnikov's Yes on draft-ietf-tls-grease-03: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Aug 2019 18:22:03 -0000 --000000000000f312130590b8c3a3 Content-Type: text/plain; charset="UTF-8" On Wed, Aug 21, 2019 at 5:25 PM David Benjamin wrote: > On Sat, Aug 17, 2019 at 5:38 AM Alexey Melnikov via Datatracker < > noreply@ietf.org> wrote: > >> I am looking forward to this being deployed. >> > > It already is deployed in Chrome. :-) > > >> TLS 1.2 should be a Normative reference, despite being obsolete, as some >> of the >> requirements only apply to TLS 1.2. >> > > Fair enough. Added in my local copy, which I'll upload as -04 once all the > comments come in. > Uploaded: https://www.ietf.org/rfcdiff?url1=draft-ietf-tls-grease-03&url2=draft-ietf-tls-grease-04 --000000000000f312130590b8c3a3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Aug 21, 2019 at 5:25 PM David Ben= jamin <davidben= @google.com> wrote:
On = Sat, Aug 17, 2019 at 5:38 AM Alexey Melnikov via Datatracker <noreply@ietf.org> wrote:=
I am looking forward to this being deployed.

It already is deployed in Chrome. :-)
=C2=A0
TLS 1.2 should be a Normative reference, despite being obsolete, as some of= the
requirements only apply to TLS 1.2.

Fai= r enough. Added in my local copy, which I'll upload as -04 once all the= comments come in.

--000000000000f312130590b8c3a3-- From nobody Thu Aug 22 11:23:21 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8300E12082D for ; Thu, 22 Aug 2019 11:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ce12en9akfVO for ; Thu, 22 Aug 2019 11:23:16 -0700 (PDT) Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4577120ABF for ; Thu, 22 Aug 2019 11:23:16 -0700 (PDT) Received: by mail-pl1-x632.google.com with SMTP id 4so3908339pld.10 for ; Thu, 22 Aug 2019 11:23:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GzI3uX+AtvwmgCTMsImGSbhDaS99jybRKrQAAHLuiU0=; b=eZ5XQsHUJWOg6haHQrTOEjphL2d+ayriEDBp796dhv2AJvQc3xH5YeNZ4CoX2JP7wq 9CFJsZIrStfLPdRgBE3rncb7D4muKjuhaBuQHFvr/7g537CacGPQ1CIsU8hbLccL1yxN y/xttYA0o53Woq6MBwquC/T0jfW6RXGvoKDglFmSXHFVtoGRptt3ClxeXfifNQalsIGp 2UhkUMnBiwhorggfG/nLzM+iBcWU2r+ETExAi6KJish1pMIqK8+Q2SfHmKZn34Hj/fXN XENy7DiSKxWHzFxtDiXcpMNbPkc25JhBi8v/bv9YFEvKIkcKyq48lMO6ZUOPC2Ds+9zh GIIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GzI3uX+AtvwmgCTMsImGSbhDaS99jybRKrQAAHLuiU0=; b=U1GGIQbpJD+BXeDpiUrypuvnAXVBewcHByDr6apJNcghXTHFQNFIxmwQtV7rUfZsLm g80YRSAfPlj5Gxbfuv0SVBMjgswzAXFhyfsMf/zZpMENrHeeeFpWDMxFcw+Zrm8ggl9N uB526Hrua72Czpqti1KYZSYRHfaKgZx7HtVCunlUTu4vjw1MssxWsH/4t5UUzh85GYLW /YvkjUhnehymp6DinsAkDondN0GqsCu2eP+87VjR0u0JQEbvlX0orBnTH0nAmPEor5rb TiTbD5gzsGSy5MhcPOVE3zTfAtrk5Kq3M1jVplqVvmsTzftdaA+IYJD6DMTzXDoRXuCF DYWQ== X-Gm-Message-State: APjAAAWdMxBs0P9CIvsFbgCfh6zyGd7e+BNptNEC+yTtdmA3SZJpU5l1 xsSWRZagKMuzZarL45Oa9UebJ3VQq3j8jr5ctXKe X-Google-Smtp-Source: APXvYqy5mCnASGcaQthoMh7w6nvwTCbhZtmmuVhNcN0Ss4hMER77Juunn/I4BTSTnSWcMnyEpJKIfYH16qDmNquNik0= X-Received: by 2002:a17:902:f64:: with SMTP id 91mr156959ply.334.1566498195837; Thu, 22 Aug 2019 11:23:15 -0700 (PDT) MIME-Version: 1.0 References: <156588205271.15865.9243229289426203471.idtracker@ietfa.amsl.com> <20190815152405.GS88236@kduck.mit.edu> <44BDC996-0E18-48BE-A700-C49A101330F8@kuehlewind.net> <6BD4AC5B-BA54-4BED-8B9B-ECA298E8BF0F@kuehlewind.net> <98ECFB35-5D77-433F-A902-B96E5EB3F33A@kuehlewind.net> In-Reply-To: <98ECFB35-5D77-433F-A902-B96E5EB3F33A@kuehlewind.net> From: David Benjamin Date: Thu, 22 Aug 2019 14:22:59 -0400 Message-ID: To: Mirja Kuehlewind Cc: David Benjamin , draft-ietf-tls-grease@ietf.org, Benjamin Kaduk , tls-chairs , The IESG , Sean Turner , "" Content-Type: multipart/alternative; boundary="0000000000008180860590b8c8ef" Archived-At: Subject: Re: [TLS] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-tls-grease-03=3A_=28with_COMMENT=29?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for 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 Aug 2019 18:23:20 -0000 --0000000000008180860590b8c8ef Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Aug 22, 2019 at 3:48 AM Mirja Kuehlewind wrote: > Thanks! > > > On 21. Aug 2019, at 23:34, David Benjamin 40google.com@dmarc.ietf.org> wrote: > > > > On Mon, Aug 19, 2019 at 3:51 AM Mirja Kuehlewind > wrote: > > Hi David, > > > > > > > On 16. Aug 2019, at 18:16, David Benjamin > wrote: > > > > > > On Fri, Aug 16, 2019 at 3:39 AM Mirja Kuehlewind > wrote: > > > > >> One comment/question: I think I didn't quite understand what a > client is > > > > >> supposed to do if the connection fails with use of greasing > values...? The > > > > >> security considerations seems to indicate that you should not tr= y > to re-connect > > > > >> without use of grease but rather just fail completely...? Also > should you cache > > > > >> the information that greasing failed maybe? > > > > > > > > > > I'll let the authors chime in, but I think the sense of the > security > > > > > considerations is more that we are preventing the fallback from > being > > > > > needed "in production due to "real" negotiation failures. Fallin= g > back on > > > > > GREASE failure is not as bad, provided that you follow-up with th= e > failing > > > > > peer out of band to try to get it fixed. > > > > > I don't know how much value there would be in caching the > grease-intolerate > > > > > status; ideally it would almost-never happen. > > > > > > > > Okay, then I think it would be nice to say something more in the > document, about fallback at least. > > > > > > > > Ben's description is right. If deploying a new TLS feature results > in too many interop failures with existing buggy servers, that feature > becomes difficult to deploy and there is a lot of pressure to apply some > sort of mitigation like a fallback. That's no good. GREASE's goal is to > avoid the interop failures to begin with. The text was not meant to imply > that you should do any sort of fallback. > > > > > > > > What change did you have in mind? The current text says: > > > > > > > > > Historically, when interoperability problems arise in deploying > new TLS features, implementations have used a fallback retry on error wit= h > the feature disabled. This allows an active attacker to silently disable > the new feature. By preventing a class of such interoperability problems, > GREASE reduces the need for this kind of fallback. > > > > > > > > That reads to me as describing historical fallbacks, rather than > recommending new ones. (Indeed you shouldn't do fallbacks. Fallbacks are > bad.. They break downgrade protection.) > > > > > > I was thinking about adding some new text somewhere else in the > document that give a recommendation if you should fallback on grease and > when. > > > > > > I mean, the answer to that is "don't" and "never", just as is > unstatedly true for any other TLS extension. TLS's downgrade protection > doesn't work if you do fallbacks. While downgrading from GREASE doesn't > matter per se, it defeats the purpose, so the usual rules for TLS apply. > > > > > > For me this wasn=E2=80=99t clear because this is not just a =E2=80=9Cno= rmal=E2=80=9D extension. > If you want to be sure that it is clear to everybody, you should write it > down in the draft. However, that my view and this was a just a comment to > consider, so the authors (and group) need to decide. > > > > Fair enough. I've added the following to that paragraph in my local cop= y. > > > > Implementations SHOULD > > NOT retry with GREASE disabled on connection failure. While > allowing an > > attacker to disable GREASE is unlikely to have immediate security > > consequences, such a fallback would prevent GREASE from defending > against > > extensibility failures. > > > > I'll upload it as -04 after all the comments come in. > Uploaded: https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-tls-grease-03&url2=3Ddraft-i= etf-tls-grease-04 --0000000000008180860590b8c8ef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Aug 22, 2019 at 3:48 AM Mirja Kue= hlewind <ietf@kuehlewind.net&= gt; wrote:
Thanks!

> On 21. Aug 2019, at 23:34, David Benjamin <davidben=3D40google.com@dmarc.ietf= .org> wrote:
>
> On Mon, Aug 19, 2019 at 3:51 AM Mirja Kuehlewind <ietf@kuehlewind.net> wrote:<= br> > Hi David,
>
>
> > On 16. Aug 2019, at 18:16, David Benjamin <davidben=3D40google= .com@dmarc.ietf..org> wrote:
> >
> > On Fri, Aug 16, 2019 at 3:39 AM Mirja Kuehlewind <ietf@kuehlewind.net> wr= ote:
> > > >> One comment/question: I think I didn't quite un= derstand what a client is
> > > >> supposed to do if the connection fails with use of = greasing values...? The
> > > >> security considerations seems to indicate that you = should not try to re-connect
> > > >> without use of grease but rather just fail complete= ly...? Also should you cache
> > > >> the information that greasing failed maybe?
> > > >
> > > > I'll let the authors chime in, but I think the sens= e of the security
> > > > considerations is more that we are preventing the fallb= ack from being
> > > > needed "in production due to "real" nego= tiation failures.=C2=A0 Falling back on
> > > > GREASE failure is not as bad, provided that you follow-= up with the failing
> > > > peer out of band to try to get it fixed.
> > > > I don't know how much value there would be in cachi= ng the grease-intolerate
> > > > status; ideally it would almost-never happen.
> > >
> > > Okay, then I think it would be nice to say something more in= the document, about fallback at least.
> > >
> > > Ben's description is right. If deploying a new TLS featu= re results in too many interop failures with existing buggy servers, that f= eature becomes difficult to deploy and there is a lot of pressure to apply = some sort of mitigation like a fallback. That's no good. GREASE's g= oal is to avoid the interop failures to begin with. The text was not meant = to imply that you should do any sort of fallback.
> > >
> > > What change did you have in mind? The current text says:
> > >
> > > > Historically, when interoperability problems arise in d= eploying new TLS features, implementations have used a fallback retry on er= ror with the feature disabled. This allows an active attacker to silently d= isable the new feature. By preventing a class of such interoperability prob= lems, GREASE reduces the need for this kind of fallback.
> > >
> > > That reads to me as describing historical fallbacks, rather = than recommending new ones. (Indeed you shouldn't do fallbacks. Fallbac= ks are bad.. They break downgrade protection.)
> >
> > I was thinking about adding some new text somewhere else in the d= ocument that give a recommendation if you should fallback on grease and whe= n.
> >
> > I mean, the answer to that is "don't" and "nev= er", just as is unstatedly true for any other TLS extension. TLS's= downgrade protection doesn't work if you do fallbacks. While downgradi= ng from GREASE doesn't matter per se, it defeats the purpose, so the us= ual rules for TLS apply.
>
>
> For me this wasn=E2=80=99t clear because this is not just a =E2=80=9Cn= ormal=E2=80=9D extension. If you want to be sure that it is clear to everyb= ody, you should write it down in the draft. However, that my view and this = was a just a comment to consider, so the authors (and group) need to decide= .
>
> Fair enough. I've added the following to that paragraph in my loca= l copy.
>
>=C2=A0 =C2=A0 =C2=A0 Implementations SHOULD
>=C2=A0 =C2=A0 =C2=A0 NOT retry with GREASE disabled on connection failu= re. While allowing an
>=C2=A0 =C2=A0 =C2=A0 attacker to disable GREASE is unlikely to have imm= ediate security
>=C2=A0 =C2=A0 =C2=A0 consequences, such a fallback would prevent GREASE= from defending against
>=C2=A0 =C2=A0 =C2=A0 extensibility failures.
>
> I'll upload it as -04 after all the comments come in.

--0000000000008180860590b8c8ef-- From nobody Fri Aug 23 11:23:25 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B35C212087A for ; Fri, 23 Aug 2019 11:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id msujoKjISaKT for ; Fri, 23 Aug 2019 11:23:19 -0700 (PDT) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62ECE12086D for ; Fri, 23 Aug 2019 11:23:19 -0700 (PDT) Received: by mail-pg1-x532.google.com with SMTP id n9so6210947pgc.1 for ; Fri, 23 Aug 2019 11:23:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=KpTopGGykd588uydxsjMfhL4Rrg4h+r/6aR94b1GcDw=; b=ds7ff8DfSWIVFIvZHJ45IoUOXDX0+9iZk/2vmW+jwOrwT/bkdyfc4Dp12RBzju1lXs p5pHT8iMn/GHX82IbUyH77pYMrP/1cDlmFKNk1WhDU3+qaiF5WbYEHzcYefoivPS3aLf Pm6L1Aw5pVkR2XM8H/Rt3DgkAY0mGMtU1bF0RMRiDaAJ/jowHz4jlHC3Q7iSZDXNRoCG wzeV8lQ+ScpNXeJQqjHnM8HKKKxr0NDpYoBVPQeBD0rjadC+eUvLUhrBhC611qaIA2A2 PlIZRGOoSnaA8FugXghdR1PeQzlKsHETDw1zUCoMEW8bo4cbMEbVV2zdS3cBBu3nMjG2 HHAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=KpTopGGykd588uydxsjMfhL4Rrg4h+r/6aR94b1GcDw=; b=HdHMpIh/80d8kXgIU1W87fB8cY1V5GF/TsUiOiWjT7hF9z3PJdS/kiFZeMFRFce7uh Ts5ozAzhFin8YouErqUR4F8Gg4rxPui+V33Z4BQ5+sRWFqTYeZrY48zHtxUmpLq3JMF2 b4yGAY9nMAL0UYiTkKrSCoiLfWLoHjDW7OuMB1ulnWdDQPGRdzYcB40TctJu6BXbWJbw LBQOotZ1r4pwnIMRMzGc2q8r/uQZaouwvqFemmMQF3Dxv1VbXSKxf2hACKLihnswJatw iknF3zC32eBqZnQhXQixxKfm9XvDrjrrF+qruNjIHzNXlwb568diKfTXKode1qsHnoVV S+0w== X-Gm-Message-State: APjAAAWQqN6JXOacKV+wUrorsF5WQNMR+6aNL+0Y7zKFjQsuoIAcC73V M6a+l9ipSCSda4Qnpzcr7Ek= X-Google-Smtp-Source: APXvYqz++n2pZibjsWq2iWc+c5QjbHUG2EjiwMCh46/YZH7IQ9PrK7CFj50q6pMlG7bW0OVkjiTXUA== X-Received: by 2002:a63:e010:: with SMTP id e16mr5039965pgh.285.1566584598864; Fri, 23 Aug 2019 11:23:18 -0700 (PDT) Received: from [10.211.55.11] (gpsslvpn.mednet.ucla.edu. [149.142.80.30]) by smtp.gmail.com with ESMTPSA id u26sm2949237pgl.79.2019.08.23.11.23.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Aug 2019 11:23:18 -0700 (PDT) To: tls@ietf.org, bascule@gmail.com, ncamwing@cisco.com References: <6AF48228-19C2-41C7-BA86-BA16940C3CFF@cisco.com> From: N6Ghost Message-ID: <111ad7c8-4000-00b6-92a2-9cbc4fff9210@gmail.com> Date: Fri, 23 Aug 2019 11:23:17 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1C37A5F9D533EBEA0F9630AF" Content-Language: en-US Archived-At: Subject: Re: [TLS] TLS Impact on Network Security draft updated X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 18:23:23 -0000 This is a multi-part message in MIME format. --------------1C37A5F9D533EBEA0F9630AF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 7/23/19 1:05 PM, Tony Arcieri wrote: > On Sun, Jul 21, 2019 at 6:51 AM Nancy Cam-Winget (ncamwing) > > wrote: > > Hi, > > Thanks to all the feedback provided, we have updated the > https://tools.ietf.org/html/draft-camwinget-tls-use-cases-04 > > draft. At this point, we believe the draft is stable and would > like to request its publication as an informational draft. > > > I read this draft as the latest attempt in a disinformation campaign > by manufacturers and users of middleboxes that passively decrypt TLS > connections to politicize and reframe the argument around what is, at > its core, a fundamentally insecure practice which is incompatible with > technically sound and highly desirable protocol improvements to TLS. > > I implore you stop using overly broad terminology, euphemisms, weasel > words, and other deceptive language to argue your points. > > This draft is titled "TLS 1.3 Impact on Network-Based Security", but > the subtext is quite clearly the much narrower subfield of middlebox > TLS decryption. By using such a grandiose title which is deceptively > hiding the true subject matter, you are implying that middleboxes are > the sum total of network security. > > The draft begins "Enterprises [...] need to defend their information > systems from attacks originating from both inside and outside their > networks." I am co-owner of a company which heavily leverages > firewalls for layer 3/4 network security in conjunction with TLS. We > care deeply about network security, and believe that our network is > *more secure* specifically because we *don't* perform middlebox > interception of TLS. > > I consider our company to be in the category of enterprise TLS users, > and as an enterprise TLS user who cares deeply about network security, > I do not identify whatsoever with the claims this draft is making > about the needs of enterprise TLS users as a whole. In as much as what > it describes to "network security", it is but one niche consideration > within a vastly broader field, and one which is increasingly > controversial. > > I will point out, since you appear to work at Cisco, that your company > works on approaches to network security (e.g. malware detection) which > avoid decrypting TLS: > > https://blogs.cisco.com/security/detecting-encrypted-malware-traffic-without-decryption > > There is an entire world of network IDS systems beyond middleboxes > which passively decrypt TLS. > > It is factually inaccurate for this draft to be described as "TLS 1.3 > Impact on Network-Based Security". If you are going to write a draft > about the impact of TLS 1.3 on middleboxes for passive TLS decryption, > please call a spade a spade and don't try to hide your true intentions > under a bunch of weasel words and overly broad claims that make it > sound like middlebox-related TLS decryption problems are the end of > network security as we know it. > > My 2c, on behalf of non-middlebox-using enterprise TLS users who feel > that attempts by middlebox-using enterprise TLS users to weaken TLS in > order to retain compatibility with their traffic decryption appliances > is a threat to the security of our enterprise TLS deployments. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls agreed, to many people think that TLS decryption at the border is critical to the network security program.Ā  they think that they need to "decrypt" everything so they can run packet inspection on the traffic looking for bad packets or bad actors. they problem with this, is at the border, those devices that can, and are; doing decryption see all plaintext traffic, so a compromise at that point, negates just about everything your doing. I firmly believe, that TLS/SSL decryption at the border is like NAT, it needs to die for the betterment of mankind. -N6Ghost --------------1C37A5F9D533EBEA0F9630AF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 7/23/19 1:05 PM, Tony Arcieri wrote:
On Sun, Jul 21, 2019 at 6:51 AM Nancy Cam-Winget (ncamwing) <ncamwing@cisco..com> wrote:

Hi,

Thanks to all the feedback provided, we have updated the https://tools.ietf.org/html/draft-camwinget-tls-use-cases-04

draft.Ā  At this point, we believe the draft is stable and would like to request its publication as an informational draft.


I read this draft as the latest attempt in a disinformation campaign by manufacturers and users of middleboxes that passively decrypt TLS connections to politicize and reframe the argument around what is, at its core, a fundamentally insecure practice which is incompatible with technically sound and highly desirable protocol improvements to TLS.

I implore you stop using overly broad terminology, euphemisms, weasel words, and other deceptive language to argue your points.

This draft is titled "TLS 1.3 Impact on Network-Based Security", but the subtext is quite clearly the much narrower subfield of middlebox TLS decryption. By using such a grandiose title which is deceptively hiding the true subject matter, you are implying that middleboxes are the sum total of network security.

The draft begins "Enterprises [...] need to defend their information systems from attacks originating from both inside and outside their networks." I am co-owner of a company which heavily leverages firewalls for layer 3/4 network security in conjunction with TLS. We care deeply about network security, and believe that our network is *more secure* specifically because we *don't* perform middlebox interception of TLS.

I consider our company to be in the category of enterprise TLS users, and as an enterprise TLS user who cares deeply about network security, I do not identify whatsoever with the claims this draft is making about the needs of enterprise TLS users as a whole. In as much as what it describes to "network security", it is but one niche consideration within a vastly broader field, and one which is increasingly controversial.

I will point out, since you appear to work at Cisco, that your company works on approaches to network security (e.g. malware detection) which avoid decrypting TLS:

https://blogs.cisco.com/security/detecting-encrypted-malware-traffic-without-decryption

There is an entire world of network IDS systems beyond middleboxes which passively decrypt TLS.

It is factually inaccurate for this draft to be described as "TLS 1.3 Impact on Network-Based Security". If you are going to write a draft about the impact of TLS 1.3 on middleboxes for passive TLS decryption, please call a spade a spade and don't try to hide your true intentions under a bunch of weasel words and overly broad claims that make it sound like middlebox-related TLS decryption problems are the end of network security as we know it.

My 2c, on behalf of non-middlebox-using enterprise TLS users who feel that attempts by middlebox-using enterprise TLS users to weaken TLS in order to retain compatibility with their traffic decryption appliances is a threat to the security of our enterprise TLS deployments.

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


agreed, to many people think that TLS decryption at the border is critical to the network security program.Ā  they think that they need to "decrypt" everything so they can run packet inspection on the traffic looking for bad packets or bad actors.

they problem with this, is at the border, those devices that can, and are; doing decryption see all plaintext traffic, so a compromise at that point, negates just about everything your doing.

I firmly believe, that TLS/SSL decryption at the border is like NAT, it needs to die for the betterment of mankind.


-N6Ghost






--------------1C37A5F9D533EBEA0F9630AF-- From nobody Mon Aug 26 15:00:21 2019 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 AD80E12001A; Mon, 26 Aug 2019 15:00:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Cc: draft-ietf-tls-grease@ietf.org, The IESG , tls-chairs@ietf.org, Sean Turner , tls@ietf.org, rfc-editor@rfc-editor.org, sean@sn3rd.com, kaduk@mit.edu Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <156685680470.2419.15616762322693582572.idtracker@ietfa.amsl.com> Date: Mon, 26 Aug 2019 15:00:04 -0700 Archived-At: Subject: [TLS] Document Action: 'Applying GREASE to TLS Extensibility' to Informational RFC (draft-ietf-tls-grease-04.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list for 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 Aug 2019 22:00:05 -0000 The IESG has approved the following document: - 'Applying GREASE to TLS Extensibility' (draft-ietf-tls-grease-04.txt) as Informational RFC This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Benjamin Kaduk and Roman Danyliw. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-grease/ Technical Summary The GREASE (Generate Random Extensions And Sustain Extensibility) mechanism is intended to prevent extensibility failures in the TLS ecosystem. This document reserves some currently unused values for TLS implementations to advertise at random. Correctly implemented peers will ignore these values and interoperate. Peers that do not tolerate unknown values will fail to interoperate, revealing the mistake before it is widespread. Working Group Summary The concept is well understood and was reviewed and adopted by the WG. But, there's not much to the draft so there was no controversy (thankfully). Document Quality This draft has successfully been implemented in Google Chrome, and is expected to be adopted by other actors with large deployment base and interest in sustaining the maintainability of the ecosystem. Personnel Sean Turner is the Document Shepherd. Benjamin Kaduk is the Responsible AD. From nobody Wed Aug 28 05:24:25 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB12120111 for ; Wed, 28 Aug 2019 05:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVwDsifn6RSF for ; Wed, 28 Aug 2019 05:24:20 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D52A61200B5 for ; Wed, 28 Aug 2019 05:24:20 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3F4C1308FB9D; Wed, 28 Aug 2019 12:24:20 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-200-52.brq.redhat.com [10.40.200.52]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8D20E5C1D6; Wed, 28 Aug 2019 12:24:19 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Date: Wed, 28 Aug 2019 14:24:13 +0200 Message-ID: <261169543.NYn7jz4KrQ@pintsize.usersys.redhat.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1668945.OgxAqpt2kI"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.43]); Wed, 28 Aug 2019 12:24:20 +0000 (UTC) Archived-At: Subject: Re: [TLS] On the difficulty of technical Mandarin (SM3 related) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 12:24:24 -0000 --nextPart1668945.OgxAqpt2kI Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Monday, 19 August 2019 17:05:06 CEST Watson Ladd wrote: > Dear all, >=20 > I see no reason why English alone should be accepted for standards > documents we reference. French and German pose few difficulties, and one > can always learn Russian. >=20 > What I don't know is how difficult Mandarin is at a level to read a > standards document. I expect the mechanics of using the dictionary to > dominate. I am familiar with few languages, the issue is even finding dictionary able= to=20 translate the technical terms correctly. Specialist texts are full of jargo= n=20 and jargon is very hard to translate correctly. It's not as simple as chuck= ing=20 the text sentence by sentence at google translate[1] and fixing few grammar= =20 mistakes. > I'm concerned about the traceability of unofficial Englidh PDFs on some > website: could the Chinese body responsible host them instead? >=20 > I fully expect this to be a more general IETF problem. one of the primary objectives of IETF is interoperability given that, and the fact the the TLS specification is written in English,=20 there should be a specification of any algorithm that is supposed to be=20 integrated with it and published under the auspice of IETF to also be=20 available in English it's a matter of practicality, not politics 1 - other automated internet translation services are available =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 115, 612 00 Brno, Czech Republic --nextPart1668945.OgxAqpt2kI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAl1mcm0ACgkQkqjRuAHS 9fVKIg//TjU/Qk68uvbLL/Jcxd5xduWWdd9dCa+bO51nc+/2ZWcJC5G8kKvKEP1Y QYdivoDBMZ/UcN9DGdjjcAF/R8Zd3DaQqc0XGDvmHvEwK6TyuWzDFzoY1XHFCsiA XOIiZC5sAdaDtqfkBL/vpWnq7aaeTOyP+KOKohdvO0RcWv4jQrSTvWOp4uesbQ4B PHPXwFNEwNg5MaBdJf+9U6kPNEYzk6YYYefnJyzj04ao7/avdwM6S5ggWDWnJoA6 pJkTl2d6jo6LJVpWGCl+YrlKPsEIEJttFKGGk0+KXmpiF+nLY6m3MOSslPZE0/x5 CT3lzek39tEy8Iaa6cH22PBo7AJfXPyiTd/H9UAAofUjw4tllXy+yWmpHQguEs1q PPkEdycv8m6zu6RwDcbYfWq1/fCwZxHwExB0Wv0CNHJBEikT3cvvHrXpJDzvWGtY a1oDYf8LIGiFOjxLdx0wVo7mSztYOKUYhifSiFxmw00gsCJ1UyGZH08SiIoblAN+ gn2NNxKM/t4rd1qj+ytW+fIc8xUPN6Hv0v5j/sAQvo0STq/F5lOWSFZScQPtfBS/ HzFjYGB5G9jcBmM9IjQ2fFyKt5xyvZKyfUd35aImjJbXElduVNYPNo6I464Cis+K P6I19+Xjnn8DqjiNliinNdTCSsZnjQbLe+pumdRsDtcLZwhXp44= =YVPu -----END PGP SIGNATURE----- --nextPart1668945.OgxAqpt2kI-- From nobody Wed Aug 28 07:47:17 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 444CA120043 for ; Wed, 28 Aug 2019 07:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bouncycastle.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VnqYBPjZ7HYR for ; Wed, 28 Aug 2019 07:47:12 -0700 (PDT) Received: from tauceti.org.au (mail.tauceti.org.au [203.32.61.25]) by ietfa.amsl.com (Postfix) with ESMTP id CAAE012001E for ; Wed, 28 Aug 2019 07:47:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bouncycastle.org; s=default; t=1567003632; bh=XfoLxroqbN4I9Ko9NcivppOt0oCHv1RzAss6o88sLlI=; h=From:Subject:To:References:Date:In-Reply-To; b=OEppKtXGvBcZp8/FoFj5LJVEQyWsXL9af+9br09RMmtXXHKgW+YLiILZnPVAqQfch 3IrW0Xkp+gt+odxA98LLiTDh8g1RMbK4Rk7fL5nnRgNct5GpVgGsegwlqZMzyRPuGo f1pLJfbeqSoAvn/5SXsKjXBrbfEhwQGygd0gzqRY= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=dsl-203-113-194-216-static.VIC.netspace.net.au; From: David Hook To: tls@ietf.org References: <261169543.NYn7jz4KrQ@pintsize.usersys.redhat.com> Openpgp: preference=signencrypt Autocrypt: addr=dgh@bouncycastle.org; prefer-encrypt=mutual; keydata= mQMuBFXzr6IRCAC3yVBmJnQs1bTjo7pc2SCqc4phaGn9CQfELrY/xxD+6Gyr5900cZHhFMJf 9tZO2wMOpi9E+zL9OZftp99NvlJMy50HMLV7/89I0UL2fwjYJCkYhKXusaA0SjxprHvWjQq+ AC6FliFZUWKBnfbm7rAU6pXEk5UBObliZh+Wymz3nkqsEx3bi9g0wS0Hg0SjDPwhDMvO8Ig5 2sqGikFMQ0SKAN6Q+gWMTwuj+JTOdRiGdPfUIEuKOO0chSIe7oo6bxk2E5g33sxvNNiJKF+n g/pNM2r+EEgl+4qsQW4mCofHPn1jgqTwC8UnTGzTgS3bLwVvlTlSuqGUQhvalrbE3CZrAQCT Z0rayqiuofdyruV0amsUwmaRiDRyUb9DpxVvw4P34wf+MOk0GTGmbB0kjlyAqpgeHbMSl6Hn wT+rAzb9Z4Lg/6yFwjKIrmk+tDEzyE3vNIPqZHBR0cCzpFfoqAn2bOSU8pgCX6vqWYEmFn+K pPfN3uGEc7YHjTCnfvF69fNSvW4d29DM1f8EBliwB1p9vSznmN5VwK/WnrRcK6czpLpFkYQO Hw2fMqkiQJ8rBqzukJzjOMxeDOnJJ/2tS3GtUgTV1g421dFADmorhbg6/BwAT2vyl2dNn1b3 FhMOkswZiJbMac6GfiHEkJJOn3nf2ogEfx1qF8DfP0zUlJOHsdeYfEiJIPIBWnNeYFe14mfy PDM0Vqu2fO7tpUmI4mO9Fg3EuAgArE8lfT1X8sS8gi4ugUwcURphl3o/EWTgUtjnA7qhWyCw xbnMcX+equ352N1Ycysh0EU/eAd8777ya6/bAy5BhDVVBU5W23mjtyEWe3ZLyPFTEmLITDNk oXUAg5DC2oJ8KVlGHJLStZNlIZA4zXsBl31ZG5Y5vv6lndVcY0fWFmLju53hE89LnDRPd5p2 xtO4e3EaSL/yXmrXhCSEgPKetN8fDBvcUcOF8+gQ4PO4PR53R76BeELAm0CcPqDToG3+/sGe OS+nYyA/r9iLE/apVoGgWm3Zdl8SdvbMue5OcvaMRuArKHebJQeMzuM36fGRfikLxYJ3wLOI chdq8T9frbRERGF2aWQgSG9vayAoTGVnaW9uIG9mIHRoZSBCb3VuY3kgQ2FzdGxlIEluYy4p IDxkZ2hAYm91bmN5Y2FzdGxlLm9yZz6IegQTEQgAIgUCVfOvogIbAwYLCQgHAwIGFQgCCQoL BBYCAwECHgECF4AACgkQbqHzoYMuRw5t0QEAie5/YuoYbyYmjd60oQrEUcgIZo/SkYRQwa1c UFxqwmoA/3Qc2p2KdMZRWuBtmbbaaIyEtIFKoqJ5/3G6LPr//fLVuQINBFXzr6IQCACrfJ5Y S5UIwx4IvjQH1so9i6dWZnBAM26nq5NJUaVx0R1T9yMPzXX4CDhPf7r7bUBuj8rnEoDNYcbw uLl046lBfawUNWIfli/WnZcbm5npAGpNhp+fwjrzm4N7LLINV1l5SWaIG/ip4jb+OcTyXWjW Fffdg6cVIjzWbh189fKcnqn3CFYH/WNZsJqcsJcYxMn/Cf0zc4jxv2JLP/Wx/3TvQY1BgQDL 2ZJGWRlHtNwVauovX50uEAmEBTyjhoGYS9bv/LPfeerRB+BuMc01wa0IcMmgciHc2KZ5hNUu Ww9Oti/jtL++WT7sLZBL/uWlp2ENJStKFHycbay4S0+abo9TAAMFB/9qoKm9wsVcxy7DfEeq vA+w8kkF1ZH51SqQNIT3nDXfrXnxBds5N5eUxl3+1jeyA/bHoi46E0Iw07+3ahU6sI/HWgz/ D2V17KsqJ9YkDprwj8iFFJChL+u5nfhJdrNjo0JTqrZfCdHBqF728pTqxQEV2wIqqwMdxHJz PVo82WnlSsxGyKUIhH5JTx0wpMFkAN2ADuz0JNwOv6dFCm+GOEFmOth1Ka3tWTmBgIfTnYat SsZrpZQ8Ze9/c3VD3ehAOjwZDiMlvBXclybUeZsvxHwNkUKdWr0QWdufd67nof243SosPFU1 KhUvRkeJkkKIZQ8fZah6g72qOqa4Nm07sU6EiGEEGBEIAAkFAlXzr6ICGwwACgkQbqHzoYMu Rw5WzQD/f0N/uQW62hvRXMuTJokzNCzt+5tnexlhqd/kqt71704A/36lBpZVxKh8J60zWoXz yKg+swupstMKq+8Jhmwxsirb Organization: The Legion of the Bouncy Castle Inc. Message-ID: <437517de-1253-dfa6-6817-c5ec0f80ef94@bouncycastle.org> Date: Thu, 29 Aug 2019 00:47:09 +1000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <261169543.NYn7jz4KrQ@pintsize.usersys.redhat.com> Content-Type: multipart/alternative; boundary="------------EC63329AB985979A131FA770" Content-Language: en-US X-Authenticated-User: david@planethook.com Archived-At: Subject: Re: [TLS] On the difficulty of technical Mandarin (SM3 related) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 14:47:15 -0000 This is a multi-part message in MIME format. --------------EC63329AB985979A131FA770 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit For what it's worth we on the Bouncy Castle project have managed to implement most of the SM* standards already. I'll admit there were some minor language issues (ignorance on our part), but for most of us I think we'd agree that maths and tests vectors (while still based around ASCII Hex/base64) are really quite familiar in any language (now at least) and in most cases all that are required to produce a working implementation. So we believe our C#, Java APIs, and Kotlin APIs can already produce signatures, and certificates, in line with the current draft for SM TLS 1.3 Cipher Suite already. We'd certainly welcome feedback on whether we've been successful as well. The code is available under https://github.com/bcgit I would stress that this is not to say that there are not subtletys around parameter choices that can be missed in trying to manage a standard in another language (parameter choices that can affect security for example), but if the first stage is interop and there is a mechanism for validation, interop can easily dealt with. After that it's about validation. Validation is going to be about something that rulesĀ  out invalid parameter choices and chooses representative test vectors. It's rarely about a standards document though. I can understand the pain about the cost of ISO standards as well, but having gone down the FIPS path also one realizes it's more about what you test against than where you got the description of what you implemented from, to that end a "not so definitive standard" can fill in the gap. Even if you have the definitive reference it's still easy to get it wrong, sometimes standard authors don't write the things we need to hear, ultimately it's really about testing and analysis. Regards, David On 28/8/19 10:24 pm, Hubert Kario wrote: > On Monday, 19 August 2019 17:05:06 CEST Watson Ladd wrote: >> Dear all, >> >> I see no reason why English alone should be accepted for standards >> documents we reference. French and German pose few difficulties, and one >> can always learn Russian. >> >> What I don't know is how difficult Mandarin is at a level to read a >> standards document. I expect the mechanics of using the dictionary to >> dominate. > I am familiar with few languages, the issue is even finding dictionary able to > translate the technical terms correctly. Specialist texts are full of jargon > and jargon is very hard to translate correctly. It's not as simple as chucking > the text sentence by sentence at google translate[1] and fixing few grammar > mistakes. > >> I'm concerned about the traceability of unofficial Englidh PDFs on some >> website: could the Chinese body responsible host them instead? >> >> I fully expect this to be a more general IETF problem. > one of the primary objectives of IETF is interoperability > > given that, and the fact the the TLS specification is written in English, > there should be a specification of any algorithm that is supposed to be > integrated with it and published under the auspice of IETF to also be > available in English > > it's a matter of practicality, not politics > > 1 - other automated internet translation services are available > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --------------EC63329AB985979A131FA770 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

For what it's worth we on the Bouncy Castle project have managed to implement most of the SM* standards already. I'll admit there were some minor language issues (ignorance on our part), but for most of us I think we'd agree that maths and tests vectors (while still based around ASCII Hex/base64) are really quite familiar in any language (now at least) and in most cases all that are required to produce a working implementation. So we believe our C#, Java APIs, and Kotlin APIs can already produce signatures, and certificates, in line with the current draft for SM TLS 1.3 Cipher Suite already. We'd certainly welcome feedback on whether we've been successful as well. The code is available under https://github.com/bcgit

I would stress that this is not to say that there are not subtletys around parameter choices that can be missed in trying to manage a standard in another language (parameter choices that can affect security for example), but if the first stage is interop and there is a mechanism for validation, interop can easily dealt with. After that it's about validation. Validation is going to be about something that rulesĀ  out invalid parameter choices and chooses representative test vectors. It's rarely about a standards document though.

I can understand the pain about the cost of ISO standards as well, but having gone down the FIPS path also one realizes it's more about what you test against than where you got the description of what you implemented from, to that end a "not so definitive standard" can fill in the gap. Even if you have the definitive reference it's still easy to get it wrong, sometimes standard authors don't write the things we need to hear, ultimately it's really about testing and analysis.

Regards,

David

On 28/8/19 10:24 pm, Hubert Kario wrote:
On Monday, 19 August 2019 17:05:06 CEST Watson Ladd wrote:

Dear all,

I see no reason why English alone should be accepted for standards
documents we reference. French and German pose few difficulties, and one
can always learn Russian.

What I don't know is how difficult Mandarin is at a level to read a
standards document. I expect the mechanics of using the dictionary to
dominate.

I am familiar with few languages, the issue is even finding dictionary able to 
translate the technical terms correctly. Specialist texts are full of jargon 
and jargon is very hard to translate correctly. It's not as simple as chucking 
the text sentence by sentence at google translate[1] and fixing few grammar 
mistakes.


I'm concerned about the traceability of unofficial Englidh PDFs on some
website: could the Chinese body responsible host them instead?

I fully expect this to be a more general IETF problem.

one of the primary objectives of IETF is interoperability

given that, and the fact the the TLS specification is written in English, 
there should be a specification of any algorithm that is supposed to be 
integrated with it and published under the auspice of IETF to also be 
available in English

it's a matter of practicality, not politics

 1 - other automated internet translation services are available


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


--------------EC63329AB985979A131FA770-- From nobody Wed Aug 28 08:49:28 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E93321200B3 for ; Wed, 28 Aug 2019 08:49:26 -0700 (PDT) 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8doaJxg_Nz9Y for ; Wed, 28 Aug 2019 08:49:25 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 590DD1200E3 for ; Wed, 28 Aug 2019 08:49:25 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id x7SFmcMD005295; Wed, 28 Aug 2019 16:49:15 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=HSCP4vphE03avgZ6Bhq62IcJ4h56QxYH5A9j8QzokqQ=; b=Lmre/BqNr5oAxUooqVnlwHTxkkQqE4FDDG37Oene4i3COXcJrVa7Ck1KUgwIUfLOh6PQ yZyE13P0HuHx1DN+RA4LRwa/9tPnopkxxb50Cf8ZUEHXrzzCe75yFod18aeOt+ytkhiz 1P+R1cbCrT21/blKMgHe/lfz0T4S5ChlpohLOC1R/vod5OxV0sLDGe/sC90q60Wz3b3q cfu9Am7r+2ojdKEbuXE/8cSHEgylYvg7Nzb15oPD3JMyC6H8SHv1FqOhdNlWFONoqMI4 eJKak+RJqZuLopOpRyUHfJlxFAgoRYYcwpr47LCmO0PVK8oxkAbW7LhzCdKrq7dl2ZED /A== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2ujwn6gub8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 28 Aug 2019 16:49:15 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x7SFkr11004424; Wed, 28 Aug 2019 11:49:14 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2uk0jw4ka7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 28 Aug 2019 11:49:14 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 28 Aug 2019 11:49:13 -0400 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.1473.005; Wed, 28 Aug 2019 11:49:13 -0400 From: "Salz, Rich" To: David Hook , "tls@ietf.org" Thread-Topic: [TLS] On the difficulty of technical Mandarin (SM3 related) Thread-Index: AQHVXZuRFk5+v/y5QkalyZ9/QKX3wKcQ5saA///OSAA= Date: Wed, 28 Aug 2019 15:49:12 +0000 Message-ID: References: <261169543.NYn7jz4KrQ@pintsize.usersys.redhat.com> <437517de-1253-dfa6-6817-c5ec0f80ef94@bouncycastle.org> In-Reply-To: <437517de-1253-dfa6-6817-c5ec0f80ef94@bouncycastle.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1c.0.190812 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.203] Content-Type: multipart/alternative; boundary="_000_D3EC1F7B932E4CFAA0F7992D4C8E0618akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-28_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=945 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908280160 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.70,1.0.8 definitions=2019-08-28_08:2019-08-28,2019-08-28 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 bulkscore=0 mlxscore=0 suspectscore=0 impostorscore=0 priorityscore=1501 mlxlogscore=928 clxscore=1011 lowpriorityscore=0 adultscore=0 spamscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1906280000 definitions=main-1908280160 Archived-At: Subject: Re: [TLS] On the difficulty of technical Mandarin (SM3 related) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 15:49:27 -0000 --_000_D3EC1F7B932E4CFAA0F7992D4C8E0618akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXMgdGhlcmUgYW55IGNoYW5jZSB5b3UgY291bGQgcG9zdCBzb21lIHNhbXBsZXMuICBJdCB3b3Vs ZCBiZSB3b25kZXJmdWwgaWYgdGhlIEFsaWJhYmEgZm9sa3Mgd291bGQgd29yayB0byBtYWtlIGEg 4oCcdGVzdCB2ZWN0b3Jz4oCdIGRyYWZ0LCB1c2luZyB5b3VyIGRhdGEuICBIaW50IGhpbnQuDQoN Cg== --_000_D3EC1F7B932E4CFAA0F7992D4C8E0618akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFz Ow0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxl LW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0K CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K c3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3Jt YXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI VE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPklzIHRoZXJlIGFueSBjaGFuY2UgeW91IGNvdWxkIHBvc3Qgc29tZSBzYW1wbGVzLiZuYnNw OyBJdCB3b3VsZCBiZSB3b25kZXJmdWwgaWYgdGhlIEFsaWJhYmEgZm9sa3Mgd291bGQgd29yayB0 byBtYWtlIGEg4oCcdGVzdCB2ZWN0b3Jz4oCdIGRyYWZ0LCB1c2luZyB5b3VyIGRhdGEuJm5ic3A7 IEhpbnQgaGludC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D3EC1F7B932E4CFAA0F7992D4C8E0618akamaicom_-- From nobody Fri Aug 30 15:24:10 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6942120A84 for ; Fri, 30 Aug 2019 15:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQkwNvTiaA-F for ; Fri, 30 Aug 2019 15:24:07 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.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 D1517120803 for ; Fri, 30 Aug 2019 15:24:06 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x7UMO2Uk031207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 30 Aug 2019 18:24:05 -0400 Date: Fri, 30 Aug 2019 17:24:02 -0500 From: Benjamin Kaduk To: tls@ietf.org Message-ID: <20190830222401.GR84368@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: [TLS] FYI: new TLS HandshakeType allocation, from draft-ietf-perc-srtp-ekt-diet X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 22:24:09 -0000 Hi all, New values for core types like TLS HandshakeType and ContentType don't happen very often, so I thought people might be interested to know that draft-ietf-perc-srtp-ekt-diet (currently in IESG evaluation) is allocating a HandshakeType, to carry key information used to encrypt SRTP media key material. Obviously "it's never too late to change until the RFC is published", but I think there would need to be some pretty serious issues in order to change it at this point, so this is expected to just be an "FYI". -Ben From nobody Fri Aug 30 15:57:40 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5BC4120073 for ; Fri, 30 Aug 2019 15:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWkUas3jWPsC for ; Fri, 30 Aug 2019 15:57:36 -0700 (PDT) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D85E812004C for ; Fri, 30 Aug 2019 15:57:35 -0700 (PDT) Received: by mail-qk1-x72d.google.com with SMTP id 4so7623751qki.6 for ; Fri, 30 Aug 2019 15:57:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eD4KMZ9mY6rbLBWDWc0n4kJ5/iVTrxFWBvW37ZjJ3h8=; b=L5eMcsLBd4SGYoxAzE392uFDtrUYvHKzcNXms8kkwC7E2XdSNUX3+8Y5mU7kMNKgMp dp9MaENAo7VI6GtRPJjmPUxzHV4MTobjRGat7IsvE8pUJ61wIZyyMuDVN65HYnHwmXKQ CsKWsD3H9FGkfE2b9SWgwjh4cY5t7dwd6/WIE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eD4KMZ9mY6rbLBWDWc0n4kJ5/iVTrxFWBvW37ZjJ3h8=; b=rnjIo+AwA+NpKjUBMTDj3fs8rehF4NOVRMKJkvtbUMShIniT/aRd69DUt3lzdwfQJe jxF6WDxpRbglXke7MtE2qx2AXyaHjtAJPWfkuUYyagekvBtExUOS0nIFajQLhscXJNaB VRnAsWodNu/F98tKfbEOukirstUZ3bsYEIGNWzZurBqPa/dQV1E504jIxPDRev0/8Toi aZGc5gfnsFgXdLuIfRYeVoDuK1E4Zw4sW4cFeAIiVyn+Jr+IROpMocAUt4AtqYlZHtPC 00jE2S13VXbhwJWK0BDeZhTIkjtnfHNBVRrTYF5r76JhN3/eTAIy3HYTn67YnCOrvFWK nDew== X-Gm-Message-State: APjAAAXgM77OZgRJBRJqD6N4qauM1IamCgnk+JkPgRBxE4zuHkQKwSRO dZ992ut59qywhkqyrBZzoq9orKY5k1igZMmFvPkaWw== X-Google-Smtp-Source: APXvYqwBvY8z7UuOiSndK65sum6QYB7LtyOVkT5TXd6raY0zFBdV5B7tf9UgbTSrti/1BtR37dnxmgt565NLeHIQ0V0= X-Received: by 2002:a37:a48e:: with SMTP id n136mr386441qke.223.1567205854914; Fri, 30 Aug 2019 15:57:34 -0700 (PDT) MIME-Version: 1.0 References: <20190830222401.GR84368@kduck.mit.edu> In-Reply-To: <20190830222401.GR84368@kduck.mit.edu> From: Watson Ladd Date: Fri, 30 Aug 2019 15:57:23 -0700 Message-ID: To: Benjamin Kaduk Cc: tls@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] FYI: new TLS HandshakeType allocation, from draft-ietf-perc-srtp-ekt-diet X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 22:57:38 -0000 On Fri, Aug 30, 2019 at 3:24 PM Benjamin Kaduk wrote: > > Hi all, > > New values for core types like TLS HandshakeType and ContentType don't > happen very often, so I thought people might be interested to know that > draft-ietf-perc-srtp-ekt-diet (currently in IESG evaluation) is allocating > a HandshakeType, to carry key information used to encrypt SRTP media key > material. > Obviously "it's never too late to change until the RFC is published", but I > think there would need to be some pretty serious issues in order to change > it at this point, so this is expected to just be an "FYI". Design issues: Am I reading the doc right, that this handshake message goes after the finished? And then contains a key that is used to decrypt another key that is then used to decrypt (some) traffic, but doesn't change the DTLS keys? Why is this a handshake message and not some protocol framing in the protocol carried over DTLS? It just seems funny to make it be a handshake type and not something else. It's entirely possible this makes more sense if you know about DTLS-SRTP which I do not very much. > > -Ben > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Fri Aug 30 16:05:27 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D51261200A3 for ; Fri, 30 Aug 2019 16:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhYk9IeMvJRv for ; Fri, 30 Aug 2019 16:05:24 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.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 2DAEA120073 for ; Fri, 30 Aug 2019 16:05:23 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x7UN5JTY009593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 30 Aug 2019 19:05:21 -0400 Date: Fri, 30 Aug 2019 18:05:18 -0500 From: Benjamin Kaduk To: Watson Ladd Cc: tls@ietf.org Message-ID: <20190830230518.GT84368@kduck.mit.edu> References: <20190830222401.GR84368@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [TLS] FYI: new TLS HandshakeType allocation, from draft-ietf-perc-srtp-ekt-diet X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 23:05:26 -0000 On Fri, Aug 30, 2019 at 03:57:23PM -0700, Watson Ladd wrote: > On Fri, Aug 30, 2019 at 3:24 PM Benjamin Kaduk wrote: > > > > Hi all, > > > > New values for core types like TLS HandshakeType and ContentType don't > > happen very often, so I thought people might be interested to know that > > draft-ietf-perc-srtp-ekt-diet (currently in IESG evaluation) is allocating > > a HandshakeType, to carry key information used to encrypt SRTP media key > > material. > > Obviously "it's never too late to change until the RFC is published", but I > > think there would need to be some pretty serious issues in order to change > > it at this point, so this is expected to just be an "FYI". > > Design issues: Am I reading the doc right, that this handshake message > goes after the finished? And then contains a key that is used to > decrypt another key that is then used to decrypt (some) traffic, but > doesn't change the DTLS keys? Why is this a handshake message and not I think that's "yes" on all counts. > some protocol framing in the protocol carried over DTLS? It just seems > funny to make it be a handshake type and not something else. It's > entirely possible this makes more sense if you know about DTLS-SRTP > which I do not very much. I don't consider myself an SRTP expert, but I think to zeroth order you can model DTLS-SRTP as being a single "hybrid" protocol that takes the DTLS handshake for key exchange and slots in a SRTP message-protection layer that is analogous to the traditional TLS Record layer. RFC 5764 even has a pretty picture: https://tools.ietf.org/html/rfc5764#section-4.1 . If you consider the "DTLS-SRTP hybrid protocol", then this new HandshakeType becomes a way for the handshake layer to supply cryptographic input to the SRTP record layer, which is not so crazy of a request. You're right, of course, that it could be done in some protocol framing at the DTLS application data layer or within the SRTP framing layer, but I'm pretty confident that the authors/WG have considered those options and still picked this one. That said, I'm pretty sure some people who are more familiar with that history than me are on this list, and hopefully not afraid to chime in and correct me or clarify as needed. Thanks for looking, Ben From nobody Fri Aug 30 16:25:16 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C776120091 for ; Fri, 30 Aug 2019 16:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AlHosz6PYYLv for ; Fri, 30 Aug 2019 16:25:10 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CED9E12004C for ; Fri, 30 Aug 2019 16:25:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5586CBE39; Sat, 31 Aug 2019 00:25:06 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id btCC2tQ2yWxx; Sat, 31 Aug 2019 00:25:04 +0100 (IST) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 60F55BE2F; Sat, 31 Aug 2019 00:25:04 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1567207504; bh=2ylKcmCf/dwWnpqbIVNaJKBR27WjWs/ay67Qy1Z5H1c=; h=Subject:To:References:From:Date:In-Reply-To:From; b=sxx20M+AJ/x/0cBoiRw8E1M3fVStM20JZ4lisNzJ/lMo3F+Bki7klMXRNwhL+zWD1 nx+VvNKUYH0PQgCvvGhETcI3LEw+CG/+Z+0X5aidgxgd6Un7mpk4vzLzeN62vfpayB KYnaCu1seiieHzgll2dYkg3K9mNsNHXsCahg8JDQ= To: Benjamin Kaduk , tls@ietf.org References: <20190830222401.GR84368@kduck.mit.edu> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <948a07a6-87b1-9f91-d0a6-fa83a7a25e3d@cs.tcd.ie> Date: Sat, 31 Aug 2019 00:25:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20190830222401.GR84368@kduck.mit.edu> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="GifSfurtHyi891xnMiw78VGOufU0syDuD" Archived-At: Subject: Re: [TLS] FYI: new TLS HandshakeType allocation, from draft-ietf-perc-srtp-ekt-diet X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 23:25:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GifSfurtHyi891xnMiw78VGOufU0syDuD Content-Type: multipart/mixed; boundary="FKmtObTiDUoytVsnKtpDbqmukwB8Mpyln"; protected-headers="v1" From: Stephen Farrell To: Benjamin Kaduk , tls@ietf.org Message-ID: <948a07a6-87b1-9f91-d0a6-fa83a7a25e3d@cs.tcd.ie> Subject: Re: [TLS] FYI: new TLS HandshakeType allocation, from draft-ietf-perc-srtp-ekt-diet References: <20190830222401.GR84368@kduck.mit.edu> In-Reply-To: <20190830222401.GR84368@kduck.mit.edu> --FKmtObTiDUoytVsnKtpDbqmukwB8Mpyln Content-Type: multipart/mixed; boundary="------------22817F1DF7E0A7EC476240B7" Content-Language: en-GB This is a multi-part message in MIME format. --------------22817F1DF7E0A7EC476240B7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 30/08/2019 23:24, Benjamin Kaduk wrote: > Hi all, >=20 > New values for core types like TLS HandshakeType and ContentType don't > happen very often, so I thought people might be interested to know that= > draft-ietf-perc-srtp-ekt-diet (currently in IESG evaluation) is allocat= ing > a HandshakeType, to carry key information used to encrypt SRTP media ke= y > material. > Obviously "it's never too late to change until the RFC is published", b= ut I > think there would need to be some pretty serious issues in order to cha= nge > it at this point, so this is expected to just be an "FYI". I guess I ought read the draft properly, but a scan of the draft doesn't seem to show any references to the kind of analyses that were done for tls1.3. I'm not clear why that's ok. Is there a reason why that is ok? It was great that many people worked to do security proofs for tls1.3. It'd be a shame to lose that via extensions that are less well analysed. Thanks, S. >=20 > -Ben >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --------------22817F1DF7E0A7EC476240B7 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------22817F1DF7E0A7EC476240B7-- --FKmtObTiDUoytVsnKtpDbqmukwB8Mpyln-- --GifSfurtHyi891xnMiw78VGOufU0syDuD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl1psE4ACgkQWrL68XsX K+ryQRAAxBdFg/RQEMWlFO82WDzUUSTpFo658wm9zB8Vz1M7SqTLYzgvTHvTsUnn sOPJy289no+uQQCLZ5fvudn9dTLO+QxfM+9sgfNxuAd+5murn9QUZO9Qe2MpgOZi 8m0gnoOuZ5ZLO7JPLMZ9NEfejrfL0h/U8iYUFUNWMppHV5g1CGCwE9hg569cMbiO V3k/8Qf7lsLZ9RC8QD4LlbRbqbOUdYxA/BVfr4SOROQQu0WrJJaP/cNKGpwNAle8 SbKGOGtWHhDuL2CyyrKPxY8/wCAZm22MxGnNpxm7QP5h1C8lUIBWNqb4kCk8/YpP 3PRW3FqarTmw/84nwg9VnGD++KjVCPdvVNPiCksOCXMzzmbOwn9z4BxcZsZD64mV kHPCIMrytYXfufZMDxzoRmi4PrT5zYJGiXoeco3hlunDRQW9ExHTyFMfB8vVeIjf v5K259W7VkLvn0oaSHohu0tJ2LnsfkNScAyAGq0r7y4/OmKBQqJdYRb8+ng73TKZ wh+Rwkp+faiW3NZHZJnkI60XP7QAkrPCEJuBftCbx7fk5C1tH1rGjIyrTz3CtE8Y IT8IxBEmSWakR80RvsGvupGyfP0i7cSf6N2I5Wm4G83lJcjQKU9vjTCe/MWJKrpd uMoZ1OceY1CrQ9fnzCXNxW0F/j9rNulR/AcPXni1SLXf4dhLV6c= =tMkr -----END PGP SIGNATURE----- --GifSfurtHyi891xnMiw78VGOufU0syDuD--