From nobody Mon Apr 1 03:40: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 D0EED12007A for ; Mon, 1 Apr 2019 03:40:18 -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 QH8Bb7CXhPz1 for ; Mon, 1 Apr 2019 03:40:17 -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 3137C12001A for ; Mon, 1 Apr 2019 03:40:17 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A5A6F30842D1; Mon, 1 Apr 2019 10:40:16 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.83]) by smtp.corp.redhat.com (Postfix) with ESMTP id 17E425D9C8; Mon, 1 Apr 2019 10:40:15 +0000 (UTC) From: Hubert Kario To: Martin Thomson Cc: tls@ietf.org Date: Mon, 01 Apr 2019 12:40:14 +0200 Message-ID: <2085296.XJS2PnzaK5@pintsize.usersys.redhat.com> In-Reply-To: <293068b3-99df-4a02-a840-2c90793a1171@www.fastmail.com> References: <2095110.rQzEGthnPs@pintsize.usersys.redhat.com> <293068b3-99df-4a02-a840-2c90793a1171@www.fastmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1824628.v0PoJAiZ1z"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.40]); Mon, 01 Apr 2019 10:40:16 +0000 (UTC) Archived-At: Subject: Re: [TLS] A flags extension 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, 01 Apr 2019 10:40:19 -0000 --nextPart1824628.v0PoJAiZ1z Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Friday, 29 March 2019 10:23:51 CEST Martin Thomson wrote: > On Thu, Mar 28, 2019, at 14:54, Hubert Kario wrote: > > what about making sure that the legacy and flags remain in-sync? we will > > have to send the legacy encoding for many years to come, so only thing = it > > would possibly reduce the size of is ServerHello or EncryptedExtensions >=20 > Those are messages where we have size pressure. why? in what use case? =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 --nextPart1824628.v0PoJAiZ1z 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+dkqjRuAHS9fUFAlyh6o4ACgkQkqjRuAHS 9fVnng/8C2+NUqVbGUAVLL9QYE9MMz3KCh/19qqDHkWL2lC1VtTu1luXk3gcNjE8 u6o96iYcw8onV43+EmSRzRTmdZZwHOsX/L+4wvav8EZw8ozSB0BKr78NPkNEDxiA dW9M6VgGSNofNuoxn8NrMYqEkX6Y83yoD/oehjSZYOVPkwEAiyKcyNsGmwvTlrrx ObTyetySVyvfGG0Stj3pb4t78u8+y1cMvQV+1euNZU0FFAdkebZbn+/ItGa1MW7Y AYzxcQvV/l5KYF67xqlE33tt2JjmfGRFxH0xY/KuhqQf5vldv8P79a+nCFuRsaUh DPZwbb8Mr5tZ0Y41WiHLEbhXMXC/hJXylaOUNZiWD83N0D+u9bQ12SIy8wz0PkYp 4HiuBmcYdXClKs00TOTxkwGqegklNpfZNDmMDVpNVR4X0ZUx2XnFq+pRCcuKfu6w rkw0IGc7Bdm16VuRsmSAqPfhtlRjbIYUQ+m0RcnMhZsC8HUABE+kHMTmXg+npwi5 ghcwfdI6XpODxY8ov60+FDTC5XQTHejN1+FZedUIAEqp3+j70M47KC4lY+CWGi04 Z4QWMI0l9QcsCBl+bKqGMpXACeEJDXJlf/hD+P/FF8pgS0mA5WXCK0RuDQtpJ2jE 9drjd2MtPznGyPpsWcwlhfdwGjdv1r+g+4jlNw5v0LEhwPbyRM8= =V2qn -----END PGP SIGNATURE----- --nextPart1824628.v0PoJAiZ1z-- From nobody Mon Apr 1 03:42: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 23E6E12008F for ; Mon, 1 Apr 2019 03:42:30 -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 cb8G_AHuEbRZ for ; Mon, 1 Apr 2019 03:42:29 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03BD912007A for ; Mon, 1 Apr 2019 03:42:29 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 96E20308621B; Mon, 1 Apr 2019 10:42:28 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.83]) by smtp.corp.redhat.com (Postfix) with ESMTP id 12EB71092001; Mon, 1 Apr 2019 10:42:27 +0000 (UTC) From: Hubert Kario To: Martin Thomson Cc: tls@ietf.org Date: Mon, 01 Apr 2019 12:42:26 +0200 Message-ID: <6732593.DcerBX1UX3@pintsize.usersys.redhat.com> In-Reply-To: <86b45147-da94-4b1c-9b5c-86f46e1950ac@www.fastmail.com> References: <5199904f-8072-480c-9ef0-a64dd2d9f2b8@www.fastmail.com> <4520688.N9SPo35rRr@pintsize.usersys.redhat.com> <86b45147-da94-4b1c-9b5c-86f46e1950ac@www.fastmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3269769.8OlyVAruD6"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.42]); Mon, 01 Apr 2019 10:42:28 +0000 (UTC) Archived-At: Subject: Re: [TLS] A use of flags 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, 01 Apr 2019 10:42:30 -0000 --nextPart3269769.8OlyVAruD6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Friday, 29 March 2019 10:24:44 CEST Martin Thomson wrote: > On Thu, Mar 28, 2019, at 14:46, Hubert Kario wrote: > > what about resumption and renegotiation? >=20 > No certificates in resumption. >=20 > No resumption in TLS 1.3 (and I don't care about TLS 1.2 any more). then say explicitly that it's not allowed in TLS 1.2 and we do have resumption in TLS 1.3, the behaviour of which is not specifi= ed =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 --nextPart3269769.8OlyVAruD6 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+dkqjRuAHS9fUFAlyh6xIACgkQkqjRuAHS 9fU3mA/+K6WD11Z/pLjKOc4C+RRYG4Ja1UI5QiWwFet5OZsFUYqOJ/GtRmDhEbKy ekaNUYSI7JWuNubp3wh8e8IbUsuNe0z8E/FXpPBRfCFe71BEELEiGM2i/X/uUmkE WzPytBDhY3TmPg489J5YBexXjRuOKHhj7r6Ov9Yhyz34YqTmC0+FacMbqqo0Ws8V aFpbr9dS+gXtELZVMqp/4nR5rG0J3emaCyV++mUX3egXmg61QSZASIBOWuOC9aAN S06hcRL0a/GumUw5ff6JkiCQMwInvWnjA2b95MJc538pnonZwFq73xFWJXLc7Y5u wzcpEUi3UB1k2HHG8/piqnv4ZI0nqWe2ss6+SQhCyv35wHrhzmaX1rx3UxnEA/LD axxz6M8NdGfJudtxMWd+jvPu8zoN7KuZMlZswZv2MAQdZeooJhbCpV8hSAE+sGqC 0Xa4t2+6Nds81o1v5oCKbql+k7L82EEs5AVOqOh6moK8GBABuVH44a11h+Vfx8hW NlWhM51tiJ8wRH+9Nd24UqNOWVj+RL/cny07GZUKy/7Kio2WG7pAokX8xXfVy2x8 byDblYF1Q1Y5vOVV9467/2zwDV60YfqpS+ufUyDC9qnZHNqF/s2/wQymw2cnnNWD SgzIXrA8+4DR/0Za3TbCndAx0BIFiNfWfDEdbbW0FzMjaBxCRKA= =cqhS -----END PGP SIGNATURE----- --nextPart3269769.8OlyVAruD6-- From nobody Mon Apr 1 06:04: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 4874A12015F for ; Mon, 1 Apr 2019 06:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 Dx9Q_lwnb7_L for ; Mon, 1 Apr 2019 06:04:25 -0700 (PDT) Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C899512010E for ; Mon, 1 Apr 2019 06:04:25 -0700 (PDT) Received: by mail-yb1-xb2c.google.com with SMTP id b18so3361543yba.12 for ; Mon, 01 Apr 2019 06:04:25 -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 :content-transfer-encoding; bh=yjYcfI8V18oEEOFZy79wOZHTONqfjXzmzh4J6gogRoo=; b=TOf7d5MgX1whm10wVpHpkbXfHgAVdJ87A2sV6bRnNQ0MwQgUOeAV3uxBgnA4VMyBoS RGK6UlXyd+kgpfg34AtjfmUrt7MEZ8QCrMCqhNIzT01GFB7Lg+9iuWH+inJM5g1xzBp6 ww6Kw81kfKu6IgdN/IRYGAjQbYe7B7/QlfBKw47aOKMwyV4spfAbHSSgaxZnjhYBisRX YaSO1KAqMwxHUkokg++OcKoQqJGaQCV5uzNtf+iCqzWniAZ8yblB3QsCqikTORrByfXN Pd0g3TRTrxvFJ5F4LTFLSqbYOGPulhz9CZFwrVIiwV2LLLueIlTUhmNC03AVGthlIck1 RpHA== 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 :content-transfer-encoding; bh=yjYcfI8V18oEEOFZy79wOZHTONqfjXzmzh4J6gogRoo=; b=hDWTqxj1aNZO7LAaref2UE5BvCIUicXRkaykj69/0pPziTNnDVdPtC3Vgibl0PHZoX 40H1ho6AmMWfu5HmVs+V82VXj+iUYTKY+IFWNDeMYqAhTiFcwViUayNRfAi6Q4qXFbzN aClhT1Y/jro9BXVUmISM+Wd1VjGTP0mrelWmkn1/+Xw7bZue4blcOjKlaEJvtR3vNout NjXzuXHeTYNaLNXnuY8cj8tGzu8VLAlHqEbRK34RRCaTHQNGhZrJGIpIRv9lEoGrP1zU A6xi7+/gt+yczWYRrRZHgS8oIeuHlwvZokEIPYkLkt3gws2rXQI5vM3W0nV2iWMdHzSC pp2w== X-Gm-Message-State: APjAAAXvSSrSH8/JHELAvx+WBwixXcSs2CHYUqTLDM+Zx3Bnv5D51oZV CPyDrRlHJQLe1ekHjNxOeZk8j+1Vk6SpcXeZWW6U+DPh X-Google-Smtp-Source: APXvYqzIVFO8mOedF2tyVqJy2vFRTpHZ1J8M3QTsic+ABotDR+4pbsr/lqQDT9D6wkxf3bxv30Z3nnrZjh+XWBrPSFU= X-Received: by 2002:a25:9a45:: with SMTP id r5mr9047897ybo.434.1554123863486; Mon, 01 Apr 2019 06:04:23 -0700 (PDT) MIME-Version: 1.0 From: Christopher Wood Date: Mon, 1 Apr 2019 06:04:03 -0700 Message-ID: To: "" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [TLS] Minutes from IETF 104 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, 01 Apr 2019 13:04:35 -0000 Minutes from last week's TLS meetings in Prague are now online [1]. They're also copied at the end of this message. Please have a look and send any issues to the list. Many thanks to Richard Barnes and Robin Wilton for taking notes! Best, Chris, Joe, and Sean [1] https://datatracker.ietf.org/doc/minutes-104-tls/ ----- TLS working Group IETF 104 Monday, 25 March, 2019 Prague, CZ # Working Group Drafts ## TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key - Russ Housley - Draft defines an extension to the TLS handshake, adding an optional parameter allowing the External PSK to be combined with EC(DHE) as secret inputs to the key schedule. - Watson Ladd: does this enable the sending of early data? - RH: No; explicitly stated to be out of scope in the draft. - ANO: formal review would be desirable. - Ekr: don=E2=80=99t think we should pass this until someone has implemente= d it. - RH: as the first slide notes, this is experimental. - one hand in response to question about implementations. - * Next Steps: additional review (probably WGLC). # Individual Drafts ## TLS Resumption across Server Name Indications for TLS 1.3 - Erik Sy - TLS 1.3 recommends against, but doesn=E2=80=99t give a good indication of what criteria to consider, or a signalling mechanism to say if the server supports Resumption. - Performance benefits, CPU time and elapsed time improvements may be valid criteria - TLS extension would be needed to signal that this option is available, e.g, a simple flag. - Privacy impact could be reduced by enforcing shorter session lengths. - Ekr: where should the extension go? - in the EE. Needs to be made clearer in the doc. - Ekr: should also be clear about whether resumption should require a fresh DNS request - Ekr: is a 1-bit flag really sufficient? - yes, otherwise would need to specify a list of values for which Resumption is OK, and that would make implementation harder. - Ekr: should TLS, in principle, define a general-purpose extension space rather than a bunch of specific flags? - Yoav Nir: 1-bit flag may introduce address space/scope clashes at the server, and different servers might have different requirements. Not a good idea to allow reconnection to =E2=80=9Cany server=E2=80=9D. - Se= rver identification could be aided by reference to the X.509 cert. - Viktor: recommends using a session ticket extension for this, not the handshake itself. - Viktor: shortening the acceptable resumption period, as proposed, is rational, but privacy implications probably need further examination. - 10 muinutes is a figure of merit. - Nick Sullivan: Where an X.509 cert has broad scope (across multiple servers), additional parameters may be needed to ensure Yoav=E2=80=99s conc= ern isn=E2=80=99t an issue. Relying only on the -.509 cert makes unreasonable assumptions. ## Importing External PSKs for TLS - Christopher Wood - TLS 1.3 imposes restriction on PSK usage with hash functions; TLS 1.2 did not impose this restriction - so the resulting incompatibility (and potential for inappropriate use of PSKs) must be handled (ideally) without changing the key schedule. - Christian Huitema: working on a draft that generalizes DNS-SD technique for external PSK identifiers in TLS. - Jon Mattsson: question about using one hash algorithm to generate keys for use with another. - ANO: Does the PSK constitute a channel binding? Depending how the External PSK is generated, this and the Resumption issue may overlap. A subsequent session has no way of knowing how the previous session was established. - Ekr: reusing hashes as proposed is secure. [Discussion inconclusive, needs further examination]. - * No objections to adoption as a work item. Take to list. ## TLS Client Network Address Extension - Tommy Pauly - Purpose: NAT detection in secure transport protocols - Relates to these drafts specifying extensions: - TLS, draft-kinnear-tls-client-net-address - QUIC, draft-pauly-quic-address-extension - Wes H.: is this specific to NATv4? - it applies everywhere. - Wes H: Why is this a TLS-specific problem? - for QUIC, this is a transport handshake question. For TLS, it would be more complicated to put it elsewhere (?). - DKG: what would a client do with this information? - the only real purpose of this is to check that you=E2=80=99re not behind a NAT. - * Discussion moved to the list for timekeeping reasons. ## Using Identity as Raw Public Key in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) - Haiguang Wang - Using Identity Based Signature exempts the server from having to maintain records of the binding between a raw public key and the entity presenting it. - * Next steps: ask to reserve specific code points for this mechanism to use in implementation and testing. Tuesday, 26 March, 2019 # Working Group Drafts ## Deprecating TLS 1.0 and 1.1 - TODO: update to deprecate DTLS 1.0 - Update to require NNTP to do the right thing - * Hearing no objection, headed for WGLC ## DTLS 1.3 - Issue 78 - we will say MUST limit amplification until the path is validated somehow. - - =E2=80=A6 and we will separately say that though there is a CID, there = is not a migration piece - that is, endpoints don't send to new addresses in response to receiving valid records from those addresses. - Issue 72 - No change. - Implementation status - NSS, Mint, mbedTLS. ## Cert Compression - Add decompressed certificate to transcript? No. - * Will write up changes, then WGLC. ## Delegated credentials - * Ready for LC? Yes, most likely. ## ESNI - Current solution with PR#137 as an extension? Unclear from the room. - Will an ESNI RRType Diverge from the A/AAAA results? - [[lots of discussion, no resolutions]] # Individual Drafts ## OPAQUE in TLS 1.3 - We should wait for CFRG to opine. - Cisco has a use case, some possibility of web API? - * No action, due to novelty. ## Hybrid key exchange - Probably too early, given that research on combinations still active. ## CWTs in TLS / DTLS - Would need to restrict to PoP tokens. - * No action, due to novelty ## Fake SNI - Should be compared to earlier draft on attacks against SNI approaches. - * No action, due to novelty. From nobody Mon Apr 1 11:13: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 41AB0120075 for ; Mon, 1 Apr 2019 11:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Y4Mm8iRhbGi4 for ; Mon, 1 Apr 2019 11:13:43 -0700 (PDT) Received: from mail.felixhandte.com (felixhandte.com [54.172.180.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1050F120188 for ; Mon, 1 Apr 2019 11:13:43 -0700 (PDT) Received: from [172.30.220.221] (unknown [199.201.65.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.felixhandte.com (Postfix) with ESMTPSA id F3AD82E2EA for ; Mon, 1 Apr 2019 18:13:41 +0000 (UTC) To: tls@ietf.org From: "W. Felix Handte" Message-ID: <270001f2-1b81-652c-8f43-f03d9b00ac2a@felixhandte.com> Date: Mon, 1 Apr 2019 14:13:41 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [TLS] Certificate Compression: Add Zstd Code Point? 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, 01 Apr 2019 18:13:45 -0000 Hello all, I know that draft-ietf-tls-certificate-compression is (almost?) in last call, so I apologize for jumping in so late. I would like to propose adding an additional codepoint to the Certificate Compression Algorithm IDs registry, for Zstd (RFC 8478). Briefly, Zstandard seems like a good fit for this use case since decompression is extremely fast, while compression exceeds Gzip significantly and roughly matches Brotli. Thanks, Felix From nobody Mon Apr 1 12:01:14 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 CECBE1204FD for ; Mon, 1 Apr 2019 12:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 2MetpEwNEYHa for ; Mon, 1 Apr 2019 12:01:01 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30089.outbound.protection.outlook.com [40.107.3.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5505120515 for ; Mon, 1 Apr 2019 12:01:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eaNxkK8drmh5sBgn7srJe9xG7BC8P8hPk2LAyTjy/SU=; b=Dkq4zHniFNRvoZ6twWYjCa07/0Y3ipl7+l6w17Eh/sJMPOnQPgppurIz5u4gEY4ePA587/hiQ1Ncqtbe2uDDMCR1zWj4Rd95hUZNi/K6BBypLD5NTpsngolkLyRSzGxm8Z38U3DL8GbYj9OHXIZ2NEtvrQSDUS7i3118a4OAwXo= Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.166.22) by HE1PR07MB3193.eurprd07.prod.outlook.com (10.170.245.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.6; Mon, 1 Apr 2019 19:00:58 +0000 Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::91bd:a367:2414:b4bc]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::91bd:a367:2414:b4bc%5]) with mapi id 15.20.1771.007; Mon, 1 Apr 2019 19:00:58 +0000 From: John Mattsson To: "TLS@ietf.org" Thread-Topic: Comments on draft-wood-tls-external-psk-importer-01 Thread-Index: AQHU6L09RDZKHT8Ksk2niB+rgTbbFA== Date: Mon, 1 Apr 2019 19:00:58 +0000 Message-ID: <89127FF7-CE3F-4DF1-98A5-B1006C5FF56B@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.17.0.190309 x-originating-ip: [82.214.46.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2fee17e7-b1ae-4ac7-118b-08d6b6d46022 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600139)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:HE1PR07MB3193; x-ms-traffictypediagnostic: HE1PR07MB3193: x-microsoft-antispam-prvs: x-forefront-prvs: 0994F5E0C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(376002)(366004)(136003)(396003)(189003)(199004)(476003)(58126008)(106356001)(53936002)(3846002)(2616005)(6116002)(7736002)(6436002)(71200400001)(102836004)(14454004)(86362001)(25786009)(5660300002)(256004)(305945005)(5640700003)(486006)(68736007)(2906002)(478600001)(6512007)(26005)(99286004)(2501003)(8936002)(97736004)(81166006)(44832011)(6916009)(66066001)(6506007)(33656002)(36756003)(316002)(83716004)(6346003)(82746002)(6486002)(81156014)(2351001)(71190400001)(8676002)(186003)(105586002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3193; H:HE1PR07MB4169.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: QVVDn6vw+57cJ/J1EcnM3xDc89QhHUZEzOqCdX7rJu7t24/Z6f17t9bqXnQ/A2tPhofuiBxYA+hjtq9JdCrCoUpi8byqTAalI1DLUMezasQPOT/0A5yhz6cA2Dm5f24qo8ahbRytCsisNF11bOnGotTSd+SVivLHW/LiVfwTNaijOjXDKSyTAiCS5zOvEw7bHjZajGWx77zE/gh4Rlb2HOFU++wZY2zziNARTH1wTsND1D6g3PKlLZeGPv7+ni1LfpGreMILS2jQb8DGNg2RpgalaTDZsOx9IEOOIv7ydva2ZR7d+H2181KVAQiejUZSC1h/dKtz3zXXcKfYhptt52rcQv7TiXbmPbjeLiv5UZWbIFcVFi2TSqTxIcG1Gpi9FnfnnfeO0hgDeeutWgf6lc8JyvIF7iNBiR7ev3zH5pI= Content-Type: text/plain; charset="utf-8" Content-ID: <00DA62CE39CDF1408BAC135FF50CF526@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2fee17e7-b1ae-4ac7-118b-08d6b6d46022 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2019 19:00:58.0130 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3193 Archived-At: Subject: [TLS] Comments on draft-wood-tls-external-psk-importer-01 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, 01 Apr 2019 19:01:12 -0000 IEhpLA0KDQpUaGFua3MgZm9yIHRyeWluZyB0byBzb2x2ZSB0aGlzIHByb2JsZW0hIE5vdCBoYXZp bmcgYSB3YXkgdG8gdXNlIHRoZSBzYW1lIGV4dGVybmFsIFBTSyBmb3IgZGlmZmVyZW50IGNpcGhl ciBzdWl0ZXMgaXMgZGVmaW5pdGVseSBhIHRoaW5nIG1pc3NpbmcgZnJvbSBUTFMgMS4zLg0KDQpB cyBJIHN0YXRlZCBkdXJpbmcgdGhlIHdnIHNlc3Npb24sIDNHUFAgaGF2ZSBhIGZldyB1c2UgY2Fz ZXMgdGhhdCB1c2UgUFNLLUVDREhFIGJldHdlZW4gcGhvbmUgYW5kIGNvcmUgbmV0d29yay4gQ29u dHJhcnkgdG8gd2hhdCBJRVRGIHBlb3BsZSBzb21ldGltZXMgYmVsaWV2ZSwgbW9zdCAzR1BQIHVz ZSBvZiBUTFMgKGJldHdlZW4gcGhvbmUgYW5kIGNvcmUgbmV0d29yaywgYmV0d2VlbiBjb3JlIG5v ZGVzLCBhbmQgYmV0d2VlbiBkaWZmZXJlbnQgb3BlcmF0b3JzKSB1c2UgbXV0dWFsIGF1dGhlbnRp Y2F0aW9uIHdpdGggY2VydGlmaWNhdGVzLg0KDQpBY2NvcmRpbmcgdG8gdGhlIGN1cnJlbnQgM0dQ UCBzcGVjaWZpY2F0aW9uLCB0aGUgcGhvbmUgYW5kIHRoZSBjb3JlIG5ldHdvcmsgd291bGQgc2hh cmUgYW4gZXh0ZXJuYWwgUFNLIGFuZCBhbiBleHRlcm5hbCBpZGVudGl0eS4gVGhlIGhhc2ggZnVu Y3Rpb24gaXMgdW5kZWZpbmVkLCBpLmUuIFNIQS0yNTYgaXMgdXNlZCBmb3IgVExTIDEuMy4gVGhl IHBob25lIGFuZCB0aGUgbmV0d29yayB3b3VsZCB0aGVuIG5lZ290aWF0ZSBUTFMgMS4yIHdpdGgg YW55IGNpcGhlciBzdWl0ZSBvciBUTFMgMS4zIHdpdGggU0hBLTI1Ni4NCg0KU29tZSBjb21tZW50 cw0KDQotIFRoZSBkcmFmdCBzaG91bGQgbWFrZSBjbGVhciBpZiB0aGUgRXh0ZXJuYWwgUFNLIGFu ZCBleHRlcm5hbCBpZGVudGl0eSBjYW4gYmUgdXNlZCB0b2dldGhlciB3aXRoIHRoZSBpbXBvcnRl ZCBpZGVudGl0aWVzLiBJIGFzc3VtZSB0aGUgaWRlYSBpcyB0aGF0IHRoZXkgY2Fu4oCZdCBidXQg SSBjYW7igJl0IHNlZSBhbnkgdGV4dCBzcGVjaWZ5aW5nIHRoaXMuDQoNCi0g4oCdSW1wb3J0ZWQg a2V5cyBkbyBub3QgcmVxdWlyZSBuZWdvdGlhdGlvbiBmb3IgdXNlLCBhcyBhIGNsaWVudCBhbmQN CnNlcnZlciB3aWxsIG5vdCBhZ3JlZSB1cG9uIGlkZW50aXRpZXMgaWYgbm90IGltcG9ydGVkIGNv cnJlY3RseS4NClRodXMsIGltcG9ydGVycyBpbmR1Y2Ugbm8gcHJvdG9jb2wgY2hhbmdlcyB3aXRo IHRoZSBleGNlcHRpb24gb2YNCmV4cGFuZGluZyB0aGUgc2V0IG9mIFBTSyBpZGVudGl0aWVzIHNl bnQgb24gdGhlIHdpcmUu4oCdDQoNCldoaWxlIEkgc2VlIGhvdyB0aGUgZGVmaW5lZCBtZWNoYW5p c20gY2FuIGJlIGRlcGxveWVkIGluIGEgbmV3IGRlcGxveW1lbnQsIEkgZG8gbm90IHNlZSBob3cg dG8gaW50cm9kdWNlIGl0IGluIGFuIGV4aXN0aW5nIGRlcGxveW1lbnQuIEFzc3VtaW5nIHRoYXQg dGhlIGV4dGVybmFsIFBTSyBjYW5ub3QgYmUgdXNlZCB0b2dldGhlciB3aXRoIHRoZSBpbXBvcnRl ZCBpZGVudGl0aWVzLCB0aGUgVExTIGNsaWVudCBhbmQgc2VydmVyIG11c3QgaW50cm9kdWNlIHRo ZSBtZWNoYW5pc20gYXQgdGhlIHNhbWUgdGltZSwgdGhhdCBpcyBvZnRlbiBub3QgcG9zc2libGUg dG8gY29udHJvbC4NCg0KLSDigJxzdHJ1Y3Qgew0KICAgICAgIG9wYXF1ZSBleHRlcm5hbF9pZGVu dGl0eTwxLi4uMl4xNi0xPjsNCiAgICAgICBvcGFxdWUgbGFiZWw8MC4uMl44LTE+Ow0KICAgICAg IEhhc2hBbGdvcml0aG0gaGFzaDsNCiAgIH0gSW1wb3J0ZWRJZGVudGl0eTsNCiAg4oCdDQoNClRo aXMgc2NhbGVzIHBvb3JseSwgQSBjbGllbnQgaGFzIHRvIHNlbmQgbiptIGlkZW50aXRpZXMgd2hl cmUgbiBpcyB0aGUgbnVtYmVyIG9mIHN1cHBvcnRlZCB2ZXJzaW9ucyBhbmQgbSBpcyB0aGUgbnVt YmVyIG9mIHN1cHBvcnRlZCBoYXNoIGFsZ29yaXRobXMuLi4NCg0KLSBXb3VsZCBpdCBub3QgYmUg cG9zc2libGUgdG8ganVzdCB1c2UgdGhlIHZlcnNpb24gbnVtYmVyIGFzIGxhYmVsPyBJLmUuIDB4 MDMwNCBpbnN0ZWFkIG9mIOKAnHRsczEz4oCdLiBJbiB0aGF0IHdheSB5b3UgZG8gYXQgbGVhc3Qg bm90IGhhdmUgdG8gZGVmaW5lIGEgbmV3IGxhYmVscy4NCg0KLSDigJxUTFMgMS4zIFtSRkM4NDQ2 XSBzdXBwb3J0cyBwcmUtc2hhcmVkIGtleSAoUFNLKSByZXN1bXB0aW9uLCB3aGVyZWluDQpQU0tz IGNhbiBiZSBlc3RhYmxpc2hlZCB2aWEgc2Vzc2lvbiB0aWNrZXRzIGZyb20gcHJpb3IgY29ubmVj dGlvbnMgb3INCmV4dGVybmFsbHkgdmlhIHNvbWUgb3V0LW9mLWJhbmQgbWVjaGFuaXNtLuKAnQ0K DQpUaGlzIHNlZW1zIHRvIGluZGljYXRlIHRoYXQgYWxsIHVzZSBvZiBQU0sgaXMgcmVzdW1wdGlv biB3aGljaCBpcyBub3QgY29ycmVjdC4gSSBzdWdnZXN0IGNoYW5naW5nIHRvIOKAnFRMUyAxLjMg W1JGQzg0NDZdIHN1cHBvcnRzIHByZS1zaGFyZWQga2V5IChQU0spIGF1dGhlbnRpY2F0aW9u4oCd DQoNCi0g4oCcaW1wb3J0aW5nIGV4dGVybmFsIFBTSyAoUHJlLVNoYXJlZCBLZXkpIGludG8gVExT LuKAnQ0KDQpOb3Qgc3VyZSBpZiDigJxpbnRv4oCdIGlzIHRoZSByaWdodCB3b3JkLCBJIHRoaW5r IOKAnGZvcuKAnSBhcyBpbiB0aGUgdGl0bGUgaXMgYmV0dGVyLiBUaGUgbWVjaGFuaXNtIHNlZW1z IHZlcnkgbXVjaCBleHRlcm5hbCB0byBUTFMgaXRzZWxmLiBJIHNlZSBpdCBhcyBhIG1lY2hhbmlz bSB0byBkZXJpdmUgc2V2ZXJhbCBleHRlcm5hbCBQU0tzIGZyb20gYSBzaW5nbGUgZXh0ZXJuYWwg UFNLLg0KDQotIOKAnFNpbWlsYXJseSwgVExTIDEuMiBhbmQgYWxsIHByaW9yIFRMUyB2ZXJzaW9u cyBzaG91bGQgdXNlICJ0bHMxMiIg4oCcDQoNClRoZSB2ZXJzaW9ucyBwcmlvciB0byBUTFMgMS4y IHdpbGwgc29vbiBiZSBkZXByZWNhdGVkLiBBbmQgd2h5IHNwZW5kIHRpbWUgdXBkYXRpbmcgdGhl IFRMUyAxLjIgY29kZSBiYXNlIGluc3RlYWQgb2YgbW92aW5nIHRvIFRMUyAxLjM/IA0KDQoNClN1 Z2dlc3Rpb246DQoNCkluc3RlYWQgb2YgZGVyaXZpbmcgYSBsYXJnZSBzZXQgb2YgbmV3IGV4dGVy bmFsIFBTS3MsIHdvdWxkbuKAmXQgaXQgYmUgcG9zc2libGUgdG8ganVzdCB1c2UgZGlmZmVyZW50 IGhhc2ggZnVuY3Rpb25zIGluIGRpZmZlcmVudCBwYXJ0cyBvZiB0aGUga2V5IGhpZXJhcmNoeT8g SS5lLiBpZiBTSEEtMjU2IGlzIGFzc29jaWF0ZWQgd2l0aCB0aGUgZXh0ZXJuYWwgUFNLIGFuZCBT SEEtMzg0IGlzIHRoZSBoYXNoIGFsZ29yaXRobXMgaW4gdGhlIGNob3NlbiBjaXBoZXIgc3VpdGU6 DQoNClBTSyAtPiAgSEtERi1FeHRyYWN0KFNIQS0yNTYpID0gRWFybHkgU2VjcmV0DQogICAgICAg ICAgfA0KICAgICAgICAgICstLS0tLT4gRGVyaXZlLVNlY3JldCguLCAiZXh0IGJpbmRlciIgfCAi cmVzIGJpbmRlciIsICIiKQ0KICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICA9IGJpbmRl cl9rZXkNCiAgICAgICAgICB8DQogICAgICAgICAgKy0tLS0tPiBEZXJpdmUtU2VjcmV0KC4sICJj IGUgdHJhZmZpYyIsIENsaWVudEhlbGxvKQ0KICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAg ICA9IGNsaWVudF9lYXJseV90cmFmZmljX3NlY3JldA0KICAgICAgICAgIHwNCiAgICAgICAgICAr LS0tLS0+IERlcml2ZS1TZWNyZXQoLiwgImUgZXhwIG1hc3RlciIsIENsaWVudEhlbGxvKQ0KICAg ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICA9IGVhcmx5X2V4cG9ydGVyX21hc3Rlcl9zZWNy ZXQNCiAgICAgICAgICB2DQogICAgRGVyaXZlLVNlY3JldCguLCAiZGVyaXZlZCIsICIiKQ0KICAg ICAgICAgIHwNCiAgICAgICAgICB2DQooRUMpREhFIC0+IEhLREYtRXh0cmFjdChTSEEtMzg0KSA9 IEhhbmRzaGFrZSBTZWNyZXQNCg0KU3VwcG9ydCBvZiB0aGlzIGNvdWxkIGJlIHNpZ25hbGxlZCB3 aXRoIHRoZSB0bHNfZmxhZ3MgZXh0ZW5zaW9uLiBJZiB0aGUgc2VydmVyIGRvZXMgbm90IHN1cHBv cnQgdGhlIGV4dGVuc2lvbiBpdCBtdXN0IGFjY29yZGluZyB0byBSRkMgODQ0NiBjaG9zZSBhIGNp cGhlciBzdWl0ZSB3aXRoIFNIQS0yNTYuDQoNCkNoZWVycywNCkpvaG4NCg0K From nobody Mon Apr 1 12:49: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 F3DD11204CD for ; Mon, 1 Apr 2019 12:49:38 -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_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 VFK4AJmAB3xr for ; Mon, 1 Apr 2019 12:49:37 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D63D120187 for ; Mon, 1 Apr 2019 12:49:37 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 4FC2DB81F70; Mon, 1 Apr 2019 12:49:23 -0700 (PDT) To: ekr@rtfm.com, rdd@cert.org, kaduk@mit.edu, christopherwood07@gmail.com, joe@salowey.net, sean+ietf@sn3rd.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: rlb@ipv.sx, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20190401194923.4FC2DB81F70@rfc-editor.org> Date: Mon, 1 Apr 2019 12:49:23 -0700 (PDT) Archived-At: Subject: [TLS] [Technical Errata Reported] RFC8446 (5682) 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, 01 Apr 2019 19:49:39 -0000 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/eid5682 -------------------------------------- Type: Technical Reported by: Richard Barnes Section: 4.3.2, B.3.2 Original Text ------------- --- rfc8446.txt 2018-08-10 20:12:08.000000000 -0400 +++ rfc8446.erratum.txt 2019-04-01 15:44:54.000000000 -0400 @@ -3341,7 +3341,7 @@ struct { opaque certificate_request_context<0..2^8-1>; - Extension extensions<2..2^16-1>; + Extension extensions<0..2^16-1>; } CertificateRequest; @@ -7309,7 +7309,7 @@ struct { opaque certificate_request_context<0..2^8-1>; - Extension extensions<2..2^16-1>; + Extension extensions<0..2^16-1>; } CertificateRequest; Corrected Text -------------- --- rfc8446.txt 2018-08-10 20:12:08.000000000 -0400 +++ rfc8446.erratum.txt 2019-04-01 15:44:54.000000000 -0400 @@ -3341,7 +3341,7 @@ struct { opaque certificate_request_context<0..2^8-1>; - Extension extensions<2..2^16-1>; + Extension extensions<0..2^16-1>; } CertificateRequest; @@ -7309,7 +7309,7 @@ struct { opaque certificate_request_context<0..2^8-1>; - Extension extensions<2..2^16-1>; + Extension extensions<0..2^16-1>; } CertificateRequest; Notes ----- The length of this vector can never 2. It is either 0, if the vector is empty, or >=4, if the vector has at least one extension. Nothing elsewhere in the spec requires a non-zero number of extensions here, so this syntax should allow a zero-length vector. 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 From nobody Mon Apr 1 13:47: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 9FDC81201E0 for ; Mon, 1 Apr 2019 13:47:23 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 1tihJ1VJmhpJ for ; Mon, 1 Apr 2019 13:47:21 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 156261201B1 for ; Mon, 1 Apr 2019 13:47:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A2B99300ADF for ; Mon, 1 Apr 2019 16:29:02 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id bA5NxmlZaQmj for ; Mon, 1 Apr 2019 16:28:57 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 88105300474; Mon, 1 Apr 2019 16:28:57 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_00F2B034-82CA-49E0-AB46-4C4243F23D3B" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Mon, 1 Apr 2019 16:47:14 -0400 In-Reply-To: <89127FF7-CE3F-4DF1-98A5-B1006C5FF56B@ericsson.com> Cc: IETF TLS To: John Mattsson References: <89127FF7-CE3F-4DF1-98A5-B1006C5FF56B@ericsson.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [TLS] Comments on draft-wood-tls-external-psk-importer-01 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, 01 Apr 2019 20:47:24 -0000 --Apple-Mail=_00F2B034-82CA-49E0-AB46-4C4243F23D3B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii John: >=20 > The draft should make clear if the External PSK and external identity = can be used together with the imported identities. I think that draft-ietf-tls-tls13-cert-with-extern-psk would be needed = with TLS 1,3 for the certificate-based authentication to be used with an = external PSK. Russ --Apple-Mail=_00F2B034-82CA-49E0-AB46-4C4243F23D3B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii John:

The draft should make clear if = the External PSK and external identity can be used together with the = imported identities.

I = think that draft-ietf-tls-tls13-cert-with-extern-psk would be = needed with TLS 1,3 for the certificate-based authentication to be used = with an external PSK.

Russ

= --Apple-Mail=_00F2B034-82CA-49E0-AB46-4C4243F23D3B-- From nobody Mon Apr 1 14:05: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 BE16E120033 for ; Mon, 1 Apr 2019 14:05:46 -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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=G8yAmJ0c; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=t1wpf1IX Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yp9feZXmUYC8 for ; Mon, 1 Apr 2019 14:05:45 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21E0712000E for ; Mon, 1 Apr 2019 14:05:45 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 1C92F21F3A; Mon, 1 Apr 2019 17:05:44 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Mon, 01 Apr 2019 17:05:44 -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=fm1; bh=oRu9kVm05+3s91WlslB9VuL2d/QW jdh74mYXuStuHNY=; b=G8yAmJ0ciZac9CbdeF8tpiznDb0Ql1XFpP35HIZszJ94 w7G+57Tq2c/kWdqhf6Y0ApMR3bzZeEgnkPEooE/17oM8o8wuzIllywwkwD+JzU2K BwboP5zdEa28oOw0ygfNWMsD9wGaQv0RNsqdJqNCACn5BWZasL20EobUdRhbwd7s hfEsAwhoXRaVYeMxXA3pRQGaF7u8wwdP3WpsXDtCXI2NF66l/YQYwxy23Zd3RRUw NGjxo/mMQws74F6MqknbhCXQrmCbRO2NLClL+S+jOqmDK9Pha4mL11N0tq0EoPxg q1bA9l7SBdntkHsdiu7BvEepQ1hVdfK/4g5iQjRHnA== 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=fm2; bh=oRu9kV m05+3s91WlslB9VuL2d/QWjdh74mYXuStuHNY=; b=t1wpf1IXAPum38Y2qAZnM0 nEF3tbfyGH5/7SCt9nuIQj8/ZxFxWxOR59VPX8tZXyRVKIBTeycTLuXsrW09/H0c ofFdzq2nj24Sxa682Nl9U7OSGDyHiLMNjaRHEAbS04yBS0VJMZSR8Hb9GuZfInWN 0V0HWW3IVRPSYgWbPUYWY5YywSmenUCjqAcEpg+hQaZxtbGQdAR1MXYwapunJbjj IMFMhufAIztwnNLop+ueQ1FWsH3BGaAbTSRJSrV6BXOqM00MhimY1cmN6eKWg6xK F+8DDkti2uYv2jGdTqBwx9kB3TL6WoSF5BccunWesI0Hu6pcKyXnZPt0kWzs82NA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrleeggdduheegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdforghr thhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecurf grrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvghtnecuvehl uhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 8D6497C1B7; Mon, 1 Apr 2019 17:05:43 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-329-gf4aae99-fmstable-20190329v1 Mime-Version: 1.0 X-Me-Personality: 92534000 Message-Id: <5dbade3c-da1d-42d4-bbd4-b5355681bd56@www.fastmail.com> In-Reply-To: <2085296.XJS2PnzaK5@pintsize.usersys.redhat.com> References: <2095110.rQzEGthnPs@pintsize.usersys.redhat.com> <293068b3-99df-4a02-a840-2c90793a1171@www.fastmail.com> <2085296.XJS2PnzaK5@pintsize.usersys.redhat.com> Date: Mon, 01 Apr 2019 17:05:41 -0400 From: "Martin Thomson" To: "Hubert Kario" Cc: tls@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [TLS] A flags extension 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, 01 Apr 2019 21:05:47 -0000 On Mon, Apr 1, 2019, at 12:40, Hubert Kario wrote: > > > would possibly reduce the size of is ServerHello or EncryptedExtensions > > > > Those are messages where we have size pressure. > > why? in what use case? QUIC. We have 3600 bytes to play with in that flight. And Certificate is often more than that. From nobody Mon Apr 1 14:30: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 A5DD1120033 for ; Mon, 1 Apr 2019 14:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_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=ericsson.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 1ZSIgTOGhON8 for ; Mon, 1 Apr 2019 14:29:57 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80051.outbound.protection.outlook.com [40.107.8.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89E1D12000E for ; Mon, 1 Apr 2019 14:29:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=asQbpsVbkNdQ+jjtRQ6EjBPzx/HR5QSI6ALVJ9MEreg=; b=eDO08fLoKKc3spBIRPVQQA4cgIxHyB6sncVwDx18A4/9ViK8BJ7EftImBRUQv5MVKS1faNFTSf4Xu2VwKSo9Yzr8bLWSShlbBF8sCS2JUgINIFq8HhhvPJxIUQoIx+r5etrsuOH0zX0S5w1u9Pf+0/ePUGkgF5GTwAKvuVgeAw8= Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.166.22) by HE1PR07MB3180.eurprd07.prod.outlook.com (10.170.245.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.9; Mon, 1 Apr 2019 21:29:53 +0000 Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::91bd:a367:2414:b4bc]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::91bd:a367:2414:b4bc%5]) with mapi id 15.20.1771.007; Mon, 1 Apr 2019 21:29:53 +0000 From: John Mattsson To: Russ Housley CC: IETF TLS Thread-Topic: [TLS] Comments on draft-wood-tls-external-psk-importer-01 Thread-Index: AQHU6L09RDZKHT8Ksk2niB+rgTbbFKYnxrEAgAAtcAA= Date: Mon, 1 Apr 2019 21:29:53 +0000 Message-ID: <3F4ABC0C-9510-4A38-B917-04A481CC58D4@ericsson.com> References: <89127FF7-CE3F-4DF1-98A5-B1006C5FF56B@ericsson.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.17.0.190309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [82.214.46.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 77945ef1-bb28-4f42-b509-08d6b6e92e04 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600139)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:HE1PR07MB3180; x-ms-traffictypediagnostic: HE1PR07MB3180: x-microsoft-antispam-prvs: x-forefront-prvs: 0994F5E0C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(396003)(376002)(136003)(366004)(189003)(199004)(51444003)(8676002)(6436002)(81166006)(81156014)(7736002)(8936002)(229853002)(6486002)(5660300002)(106356001)(71190400001)(71200400001)(25786009)(33656002)(6916009)(58126008)(68736007)(316002)(14454004)(83716004)(99286004)(105586002)(66066001)(36756003)(478600001)(6246003)(53936002)(6512007)(54896002)(6306002)(11346002)(446003)(186003)(53546011)(476003)(26005)(102836004)(2616005)(486006)(86362001)(14444005)(44832011)(6506007)(256004)(97736004)(4326008)(82746002)(6116002)(790700001)(3846002)(2906002)(76176011); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3180; H:HE1PR07MB4169.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Ba7OcKDIAV5v389VTtyIN8rzgO/Gzd89X4y6sPSj18f6j77M5iHy205HIHRrb04XhEFDtQHN7YwOOZIAapXIY9eHNS9CEUD+fwOe3LH51NwYT2bS6HIJ16xCspaOsiRev454Fk7uQysyYgGN1tqpEYvkJhYP/5mXfuaHq5lS+DiOAZwQmSnyhWwuMqObgeyLXfXytYOKCQCCdJ7G+M0zjVU6jCRmVK6+lDLYT0b3fGcKnaCZBFiItEgUNG1QjPs9wuCUP+1U+msWj/ly3rMMA9ng9TGrrxOlzbfeDM+Otn3gegLBEcJVev1I1j5rIugJZcZCNGZhnDr24BgQ3foqiDHWZGLgwAw5AXR+dJJUXpixCX7YKnJXan3EACOE2oZYLS9mZx0Urmq829JuWwyToklju+Wu76E++Bn+3yhmT/w= Content-Type: multipart/alternative; boundary="_000_3F4ABC0C95104A38B91704A481CC58D4ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 77945ef1-bb28-4f42-b509-08d6b6e92e04 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2019 21:29:53.3908 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3180 Archived-At: Subject: Re: [TLS] Comments on draft-wood-tls-external-psk-importer-01 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, 01 Apr 2019 21:30:01 -0000 --_000_3F4ABC0C95104A38B91704A481CC58D4ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUnVzcywNCg0KSSB3YXMgbm90IHRhbGtpbmcgYWJvdXQgY2VydGlmaWNhdGVzIGF0IGFsbC4g TXkgY29tbWVudCB3YXMgYWJvdXQgdXNpbmcgYm90aCBleHRlcm5hbF9pZGVudGl0eSBhbmQgb25l IG9mIGl0cyBkZXJpdmVkIEltcG9ydGVkSWRlbnRpdHkgaW4gT2ZmZXJlZFBza3MNCg0KZHJhZnQt d29vZC10bHMtZXh0ZXJuYWwtcHNrLWltcG9ydGVyLTAxOg0KDQogICAgIHN0cnVjdCB7DQogICAg ICAgICAgb3BhcXVlIGV4dGVybmFsX2lkZW50aXR5PDEuLi4yXjE2LTE+Ow0KICAgICAgICAgIG9w YXF1ZSBsYWJlbDwwLi4yXjgtMT47DQogICAgICAgICAgSGFzaEFsZ29yaXRobSBoYXNoOw0KICAg ICAgfSBJbXBvcnRlZElkZW50aXR5Ow0KDQoNClJGQyA4NDQ2Og0KDQogICAgICBzdHJ1Y3Qgew0K ICAgICAgICAgIFBza0lkZW50aXR5IGlkZW50aXRpZXM8Ny4uMl4xNi0xPjsNCiAgICAgICAgICBQ c2tCaW5kZXJFbnRyeSBiaW5kZXJzPDMzLi4yXjE2LTE+Ow0KICAgICAgfSBPZmZlcmVkUHNrczsN Cg0KICAgICAgc3RydWN0IHsNCiAgICAgICAgICBvcGFxdWUgaWRlbnRpdHk8MS4uMl4xNi0xPjsN CiAgICAgICAgICB1aW50MzIgb2JmdXNjYXRlZF90aWNrZXRfYWdlOw0KICAgICAgfSBQc2tJZGVu dGl0eTsNCg0KSm9obg0KDQpGcm9tOiBSdXNzIEhvdXNsZXkgPGhvdXNsZXlAdmlnaWxzZWMuY29t Pg0KRGF0ZTogTW9uZGF5LCAxIEFwcmlsIDIwMTkgYXQgMjI6NDcNClRvOiBKb2huIE1hdHRzc29u IDxqb2huLm1hdHRzc29uQGVyaWNzc29uLmNvbT4NCkNjOiAiVExTQGlldGYub3JnIiA8VExTQGll dGYub3JnPg0KU3ViamVjdDogUmU6IFtUTFNdIENvbW1lbnRzIG9uIGRyYWZ0LXdvb2QtdGxzLWV4 dGVybmFsLXBzay1pbXBvcnRlci0wMQ0KDQpKb2huOg0KDQpUaGUgZHJhZnQgc2hvdWxkIG1ha2Ug Y2xlYXIgaWYgdGhlIEV4dGVybmFsIFBTSyBhbmQgZXh0ZXJuYWwgaWRlbnRpdHkgY2FuIGJlIHVz ZWQgdG9nZXRoZXIgd2l0aCB0aGUgaW1wb3J0ZWQgaWRlbnRpdGllcy4NCg0KSSB0aGluayB0aGF0 IGRyYWZ0LWlldGYtdGxzLXRsczEzLWNlcnQtd2l0aC1leHRlcm4tcHNrIHdvdWxkIGJlIG5lZWRl ZCB3aXRoIFRMUyAxLDMgZm9yIHRoZSBjZXJ0aWZpY2F0ZS1iYXNlZCBhdXRoZW50aWNhdGlvbiB0 byBiZSB1c2VkIHdpdGggYW4gZXh0ZXJuYWwgUFNLLg0KDQpSdXNzDQoNCg0K --_000_3F4ABC0C95104A38B91704A481CC58D4ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <738C05944F7EAC4E8C8F846B6676B72C@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1h dHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5tc29ub3JtYWww LCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3Jt YWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEx LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5 bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uSFRNTFByZWZvcm1h dHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQi Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3 MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJTViIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRG NzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUdCIj5IaSBSdXNzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+SSB3YXMgbm90IHRh bGtpbmcgYWJvdXQgY2VydGlmaWNhdGVzIGF0IGFsbC4gTXkgY29tbWVudCB3YXMgYWJvdXQgdXNp bmcgYm90aCBleHRlcm5hbF9pZGVudGl0eSBhbmQgb25lIG9mIGl0cyBkZXJpdmVkIEltcG9ydGVk SWRlbnRpdHkgaW4gT2ZmZXJlZFBza3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPmRyYWZ0LXdvb2QtdGxz LWV4dGVybmFsLXBzay1pbXBvcnRlci0wMTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBzdHJ1Y3QgezxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb3BhcXVlIGV4dGVybmFsX2lkZW50aXR5Jmx0OzEu Li4yXjE2LTEmZ3Q7OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgb3BhcXVlIGxhYmVsJmx0OzAuLjJeOC0xJmd0Ozs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEhhc2hB bGdvcml0aG0gaGFzaDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH0gSW1w b3J0ZWRJZGVudGl0eTs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5SRkMgODQ0Njo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzdHJ1Y3Qg ezxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgUHNrSWRlbnRpdHkgaWRlbnRpdGllcyZsdDs3Li4yXjE2LTEmZ3Q7OzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUHNrQmlu ZGVyRW50cnkgYmluZGVycyZsdDszMy4uMl4xNi0xJmd0Ozs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IH0gT2ZmZXJlZFBza3M7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3RydWN0IHs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9wYXF1ZSBpZGVudGl0eSZsdDsx Li4yXjE2LTEmZ3Q7OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgdWludDMyIG9iZnVzY2F0ZWRfdGlja2V0X2FnZTs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH0gUHNrSWRlbnRpdHk7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIj5Kb2huPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xv cjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5SdXNzIEhvdXNsZXkgJmx0O2hvdXNsZXlAdmlnaWxz ZWMuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5Nb25kYXksIDEgQXByaWwgMjAxOSBhdCAyMjo0 Nzxicj4NCjxiPlRvOiA8L2I+Sm9obiBNYXR0c3NvbiAmbHQ7am9obi5tYXR0c3NvbkBlcmljc3Nv bi5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDtUTFNAaWV0Zi5vcmcmcXVvdDsgJmx0O1RM U0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtUTFNdIENvbW1lbnRzIG9u IGRyYWZ0LXdvb2QtdGxzLWV4dGVybmFsLXBzay1pbXBvcnRlci0wMTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPkpvaG46PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+VGhlIGRyYWZ0IHNob3Vs ZCBtYWtlIGNsZWFyIGlmIHRoZSBFeHRlcm5hbCBQU0sgYW5kIGV4dGVybmFsIGlkZW50aXR5IGNh biBiZSB1c2VkIHRvZ2V0aGVyIHdpdGggdGhlIGltcG9ydGVkIGlkZW50aXRpZXMuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PkkgdGhpbmsgdGhhdCZuYnNwO2RyYWZ0LWlldGYtdGxzLXRsczEzLWNlcnQtd2l0aC1leHRlcm4t cHNrIHdvdWxkIGJlIG5lZWRlZCB3aXRoIFRMUyAxLDMgZm9yIHRoZSBjZXJ0aWZpY2F0ZS1iYXNl ZCBhdXRoZW50aWNhdGlvbiB0byBiZSB1c2VkIHdpdGggYW4gZXh0ZXJuYWwgUFNLLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5SdXNzPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_3F4ABC0C95104A38B91704A481CC58D4ericssoncom_-- From nobody Mon Apr 1 14:54: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 8895A1200D8 for ; Mon, 1 Apr 2019 14:54: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_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 E18zjD4BO2LI for ; Mon, 1 Apr 2019 14:54:56 -0700 (PDT) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BF7712000E for ; Mon, 1 Apr 2019 14:54:56 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id r24so9671432ljg.3 for ; Mon, 01 Apr 2019 14:54:56 -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=g3dOqxNqdxExL20WFgZUGpqK563/1qp8/MGN5Yh6n1w=; b=LW0yDtb6c2yIVb4YWlzUk1gn5B9HtwCmDfUPhH0x7WSgNMOXtkJM+y5NN327lnp1uq ceJS8uBgxY6yRWUWlWND89jEotYMZbXRKl58e+vN0md969JoRzrfJ79oXgWxUUddHKTV bKuUc4DIGy1lIZqMR7A4y7Y/ACSqhttR7B7ArLFm2zM+s/g4alX/SyculPvIK6ggRrdx Y6PoTsOLLy5Wy4m1Vtrp14O88cPa5vUT2EyIi7O1KoMqzdIwRk+sAzPJ0LWWtx8rumoA Iq3mHFojN62UnKRIiQaiwQYSNVkVHZ0tBRQI/ZbTYkFDajuGISj1UH/ZKnjrfbeB9JPD 2bLQ== 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=g3dOqxNqdxExL20WFgZUGpqK563/1qp8/MGN5Yh6n1w=; b=X2Tpq+NQAZgyG6iKq688Bob0bt2GQNi4tt4s4qDV9rYdqnGeuhhak6hoSDACJAMSVo tlcVjI+UTI6+O0yqdfDzWPSpARkpVGCZnKpPsjouqTQPtpAZLyBor7T4XGYoDXEdRPN/ /BSJ6RuZApZNqJqB/uYMNhHT2Ai3xDGTr8jSp9sxn5SGY7V3A+brME4Ox0Wb+CYp1NtK 8Jp3uYUun+xfIXZxi/sk0GpINhgENyQQvByZcPbEm6e8qAb6u8ryCZFtc1mXhLEKYWpL QCOTzXHn/j76K16zBRRWSSPDcJfklcvL0fwPcfCnNX/KjSfgJ2oBhEBmHpHHfrnBl01n yJNQ== X-Gm-Message-State: APjAAAWRl9Ktlqy+mKtZZHPa1fXziZMXxJJmO+FlNIg4V/duT8mYK1AQ qAwWgBjKc0kqe9pIJtzotQ5jTwJMwiobVQhlL1h30w== X-Google-Smtp-Source: APXvYqwma1oG8eYSwzy7ToOJ5CktF+NZaBvPPzpE/JHw2VfkgFnDA1T206mmvUeEZgNMUyps7FjQtN26fiY283bna9E= X-Received: by 2002:a2e:3c0a:: with SMTP id j10mr11985067lja.164.1554155693938; Mon, 01 Apr 2019 14:54:53 -0700 (PDT) MIME-Version: 1.0 References: <8EE5F87F-E6D8-4B15-91DA-4AA89B6E62AF@ericsson.com> In-Reply-To: <8EE5F87F-E6D8-4B15-91DA-4AA89B6E62AF@ericsson.com> From: Victor Vasiliev Date: Mon, 1 Apr 2019 17:54:42 -0400 Message-ID: To: John Mattsson Cc: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="0000000000001088fd05857f12de" Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-04.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, 01 Apr 2019 21:54:59 -0000 --0000000000001088fd05857f12de Content-Type: text/plain; charset="UTF-8" Thank you for your comments! I've opened a PR to address them: https://github.com/tlswg/certificate-compression/pull/25 On Sat, Mar 30, 2019 at 2:26 AM John Mattsson wrote: > Two short comments: > > - Would be good to mention that the document does not specify any > preset dictionaries. > > - Would be good to mention the reason to have the uncompressed > length. Reading the document I had the same thought that EKR earlier > expressed on the list: that it was some sort of not so good sanity check. > > Cheers, > John > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000001088fd05857f12de Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you for your comments!

I've o= pened a PR to address them:=C2=A0https://github.com/tlswg/certificate-compression= /pull/25

On Sat, Mar 30, 2019 at 2:26 AM John Mattsson <john.mattsson@ericsson.com> w= rote:
Two short = comments:

-=C2=A0 =C2=A0 =C2=A0 =C2=A0Would be good to mention that the document does= not specify any preset dictionaries.

-=C2=A0 =C2=A0 =C2=A0 =C2=A0Would be good to mention the reason to have the= uncompressed length. Reading the document I had the same thought that EKR = earlier expressed on the list: that it was some sort of not so good sanity = check.

Cheers,
John




_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000001088fd05857f12de-- From nobody Mon Apr 1 15:04: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 8F7C2120047 for ; Mon, 1 Apr 2019 15:04:08 -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, 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 3dqgFpsImqt0 for ; Mon, 1 Apr 2019 15:04:06 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F9F0120021 for ; Mon, 1 Apr 2019 15:04:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 53B87300ADB for ; Mon, 1 Apr 2019 17:45:48 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id NY5LQ8WREzL5 for ; Mon, 1 Apr 2019 17:45:42 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id D498A3005AB; Mon, 1 Apr 2019 17:45:42 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_69691301-F3A0-4B0E-81A3-5C79CC956B73" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Mon, 1 Apr 2019 18:03:59 -0400 In-Reply-To: <3F4ABC0C-9510-4A38-B917-04A481CC58D4@ericsson.com> Cc: IETF TLS To: John Mattsson References: <89127FF7-CE3F-4DF1-98A5-B1006C5FF56B@ericsson.com> <3F4ABC0C-9510-4A38-B917-04A481CC58D4@ericsson.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [TLS] Comments on draft-wood-tls-external-psk-importer-01 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, 01 Apr 2019 22:04:09 -0000 --Apple-Mail=_69691301-F3A0-4B0E-81A3-5C79CC956B73 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii John: Okay, I misread the first note. Sorry for the noise. Russ > On Apr 1, 2019, at 5:29 PM, John Mattsson = wrote: >=20 > Hi Russ, > =20 > I was not talking about certificates at all. My comment was about = using both external_identity and one of its derived ImportedIdentity in = OfferedPsks > =20 > draft-wood-tls-external-psk-importer-01: > =20 > struct { > opaque external_identity<1...2^16-1>; > opaque label<0..2^8-1>; > HashAlgorithm hash; > } ImportedIdentity; > =20 > =20 > RFC 8446: > =20 > struct { > PskIdentity identities<7..2^16-1>; > PskBinderEntry binders<33..2^16-1>; > } OfferedPsks; > =20 > struct { > opaque identity<1..2^16-1>; > uint32 obfuscated_ticket_age; > } PskIdentity; > =20 > John > =20 > From: Russ Housley > > Date: Monday, 1 April 2019 at 22:47 > To: John Mattsson > > Cc: "TLS@ietf.org " > > Subject: Re: [TLS] Comments on draft-wood-tls-external-psk-importer-01 > =20 > John: >> =20 >> The draft should make clear if the External PSK and external identity = can be used together with the imported identities. > =20 > I think that draft-ietf-tls-tls13-cert-with-extern-psk would be needed = with TLS 1,3 for the certificate-based authentication to be used with an = external PSK. > =20 > Russ --Apple-Mail=_69691301-F3A0-4B0E-81A3-5C79CC956B73 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii John:

Okay,= I misread the first note.  Sorry for the noise.

Russ


On Apr 1, 2019, at 5:29 PM, John Mattsson = <john.mattsson@ericsson.com> wrote:

Hi Russ,
 
I was not talking about = certificates at all. My comment was about using both external_identity = and one of its derived ImportedIdentity in OfferedPsks
 
draft-wood-tls-external-psk-importer-01:
 
     struct {
          opaque = external_identity<1...2^16-1>;
          opaque = label<0..2^8-1>;
          = HashAlgorithm hash;
      } ImportedIdentity;
 
 
RFC 8446:
 
      struct {
          = PskIdentity identities<7..2^16-1>;
          = PskBinderEntry binders<33..2^16-1>;
      } = OfferedPsks;
 
      = struct {
          opaque = identity<1..2^16-1>;
          uint32 = obfuscated_ticket_age;
      } PskIdentity;
 
John
 
From: Russ Housley <housley@vigilsec.com>
Date: Monday, 1 April 2019 at = 22:47
To: John Mattsson <john.mattsson@ericsson.com>
Cc: "TLS@ietf.org" <TLS@ietf.org>
Subject: Re: [TLS] Comments on = draft-wood-tls-external-psk-importer-01
 
John:
 
The draft should make clear if the External PSK and external = identity can be used together with the imported identities.
 
I think = that draft-ietf-tls-tls13-cert-with-extern-psk would be needed with = TLS 1,3 for the certificate-based authentication to be used with an = external PSK.
 
Russ
= --Apple-Mail=_69691301-F3A0-4B0E-81A3-5C79CC956B73-- From nobody Mon Apr 1 15:09: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 1315E120021 for ; Mon, 1 Apr 2019 15:09:32 -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_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 c0dOnVxUXsdS for ; Mon, 1 Apr 2019 15:09:30 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD5B3120003 for ; Mon, 1 Apr 2019 15:09:29 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id y6so9648308ljd.12 for ; Mon, 01 Apr 2019 15:09:29 -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=xyHwI++eVkb8dUKPDN2jWkXi3XFyfkM0XWgobR2bMCM=; b=d0vIvgNVIaq42GsfGPELuBrF2vXmOcUqEygheCXYK8yWOmj0B4ZWGcg7MYHBfMwrZw X4guExX8UeXnSBeL3rrZG0TzPu6Yg1x6M68OhLCerSRvgSrBGu7okANGM0QskrX8cwZF vyihDg51sHIk13pA8qmbUucVNvR66pb8JM1Zi59PIdxPPn5oAb8adsK4C4JYNZovCRhO b3hYYpxS0cKKXDqwcJFIGmdQTw+vwE25BjNEt9x8gAO6oyBt9WGBafwGouLeN1LLVhs/ kx7cr/oDvjCHe766Fqh/8hCRDWJ57yxfXBiK+/kIxKejR0DcaQh9dVkjq/w8zlWDTYNe MNqA== 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=xyHwI++eVkb8dUKPDN2jWkXi3XFyfkM0XWgobR2bMCM=; b=XLnnt3OQ1+8/FNH+/4tsEWrS63NqXWMbeLmWYxm3Ewn30jIplwShZcS4TpHSJ3xuil 1XQbOquXL6qtwccQyjeUtNwwQBASCnXEJklmwU+rgPDt+ksLcxtYRSEPHikTuX69TwjE WmpXhh2XQ9/HBeL+1Wq8OtXzhlMdp1O1uyb33wipxdqo1GkXEAjyAcU6+iGf3d/U38B2 iLwxoVngT92qwQJ+zTjONBIp0j/XCT/GaEK5LNsEvXCTTwogEW2GGQ7sCEYpaSjY5icP yn+SNte1U2WAXniwFquu0trqVck/Ek87A0DaqDdsvPHII+EwCQx+qfkDHjvIXitEvBLu Mz+A== X-Gm-Message-State: APjAAAVL6P+Oiva2elMRsMLTnLKw/CHCg920ukbwyCA845RsJXRe2sCe BYvG8eDU19BKe0kvWJNNKEdidRAPYPvBhQy1Kg/pjtSeXm8= X-Google-Smtp-Source: APXvYqx5XGgS8MT5Q/M7whf3QiCRLlCh/jcWiy6pW7l9KwdwkK94O5bpbkL1BWf+xhu/QWwIxucTF3omQUX/ATWZUZo= X-Received: by 2002:a2e:93c7:: with SMTP id p7mr27757178ljh.32.1554156567392; Mon, 01 Apr 2019 15:09:27 -0700 (PDT) MIME-Version: 1.0 References: <270001f2-1b81-652c-8f43-f03d9b00ac2a@felixhandte.com> In-Reply-To: <270001f2-1b81-652c-8f43-f03d9b00ac2a@felixhandte.com> From: Victor Vasiliev Date: Mon, 1 Apr 2019 18:09:16 -0400 Message-ID: To: "W. Felix Handte" Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000206ff805857f46ab" Archived-At: Subject: Re: [TLS] Certificate Compression: Add Zstd Code Point? 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, 01 Apr 2019 22:09:32 -0000 --000000000000206ff805857f46ab Content-Type: text/plain; charset="UTF-8" This sounds reasonable to me. I currently don't have a plan for implementing this, but since zstd is well-defined and has an RFC published (that I can easily cite), I see no reason not to add it. I wrote up a PR: https://github.com/tlswg/certificate-compression/pull/26. I will merge it before the last call, unless there are objections. On Mon, Apr 1, 2019 at 2:14 PM W. Felix Handte wrote: > Hello all, > > I know that draft-ietf-tls-certificate-compression is (almost?) in last > call, so I apologize for jumping in so late. > > I would like to propose adding an additional codepoint to the > Certificate Compression Algorithm IDs registry, for Zstd (RFC 8478). > > Briefly, Zstandard seems like a good fit for this use case since > decompression is extremely fast, while compression exceeds Gzip > significantly and roughly matches Brotli. > > Thanks, > Felix > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000206ff805857f46ab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This sounds reasonable to me.=C2=A0 I currently don't = have a plan for implementing this, but since zstd is well-defined and has a= n RFC published (that I can easily cite), I see no reason not to add it.
I wrote up a PR:=C2=A0https://github.com/tlswg/certificate-compr= ession/pull/26.=C2=A0 I will merge it before the last call,=C2=A0unless= there are objections.

On Mon, Apr 1, 2019 at 2:14 PM W. Felix Handt= e <w@felixhandte.com> wrote:=
Hello all,

I know that draft-ietf-tls-certificate-compression is (almost?) in last call, so I apologize for jumping in so late.

I would like to propose adding an additional codepoint to the
Certificate Compression Algorithm IDs registry, for Zstd (RFC 8478).

Briefly, Zstandard seems like a good fit for this use case since
decompression is extremely fast, while compression exceeds Gzip
significantly and roughly matches Brotli.

Thanks,
Felix

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000206ff805857f46ab-- From nobody Tue Apr 2 04:43: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 0E2721200DB for ; Tue, 2 Apr 2019 04:43:11 -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 BBpHyQjWNqSy for ; Tue, 2 Apr 2019 04:43:08 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FDFC12015A for ; Tue, 2 Apr 2019 04:43:08 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 89DAE59447; Tue, 2 Apr 2019 11:43:06 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.83]) by smtp.corp.redhat.com (Postfix) with ESMTP id 01BB8848E4; Tue, 2 Apr 2019 11:43:05 +0000 (UTC) From: Hubert Kario To: Martin Thomson Cc: tls@ietf.org Date: Tue, 02 Apr 2019 13:42:59 +0200 Message-ID: <2719088.tQPqK0Ev7F@pintsize.usersys.redhat.com> In-Reply-To: <5dbade3c-da1d-42d4-bbd4-b5355681bd56@www.fastmail.com> References: <2085296.XJS2PnzaK5@pintsize.usersys.redhat.com> <5dbade3c-da1d-42d4-bbd4-b5355681bd56@www.fastmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4027448.x3sNSZYTVQ"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Tue, 02 Apr 2019 11:43:06 +0000 (UTC) Archived-At: Subject: Re: [TLS] A flags extension 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, 02 Apr 2019 11:43:11 -0000 --nextPart4027448.x3sNSZYTVQ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Monday, 1 April 2019 23:05:41 CEST Martin Thomson wrote: > On Mon, Apr 1, 2019, at 12:40, Hubert Kario wrote: > > > > would possibly reduce the size of is ServerHello or > > > > EncryptedExtensions > > >=20 > > > Those are messages where we have size pressure. > >=20 > > why? in what use case? >=20 > QUIC. We have 3600 bytes to play with in that flight. And Certificate is > often more than that. then maybe it's QUIC that should be modified to allow for more than 3600 by= tes=20 to actually make it deployable? I mean, seriously, if you you need to be bit-pinching now, what will happen= =20 when PQC gets deployed?! =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 --nextPart4027448.x3sNSZYTVQ 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+dkqjRuAHS9fUFAlyjSsMACgkQkqjRuAHS 9fXSWQ//QPQCtIN4Zs4b4ahO3Fru+V0gQBcW4YTnaQbNI8kpRSbln5u0JuYKf/On CBDtxzpdlIdz/8DZqyUcoLAdaJF4ZDNK+1Ry98Hr/UOaJxrCasjx2lsPoSH72dWz makNc9nlfOMSoid7k0oRJTBX5HLeR7enW4ROqHYmmlhBPw/Q5ofF7PcxKHk6Fqbh EDptJj1Zoq5rlg5vnN7TmpE9/5X2ZcvrwrhV7f/uDllR4F1nkTS4P9t1UlFPJKzZ 8nf9KaPsvsmORXcLSegBL/a0tDEu71CT9s5qGzqgGwagoi0BHQxyQBuquMB2d5II Zw0clkANttkBWvmsoEl0asNMm0jwAYyoYuh9CuLxIVCL8A0GCznHa7DTzEMfOqzy B+gyumPwkx/UZGbJsXnrFkTGBsaehK1g/pMM6C4BLevBaM+y/UrIFhlmDWJkBfTN BiHZe5/+C/izZYLDr0rzhSrN0txyRKnMiQn0ZotosAbQPPCZunLS6R5miffi5onf Tb8fROiRPawnxSknMlMlsAEAbwO8R1Du81ldxgy17W5RAdalyGD77n33MVMmmg8v 5cmxI7tRxUGwXXkyhhTbgBe4ydOZqs2Kw2mt6CE+wpU5AnxjXdfSyBPr7AcHI1M2 KrvTsCjvdCOuq5N8UqtcxEHRb1oHFaStNS+5RnOvcZpxUMlDQGU= =6qfo -----END PGP SIGNATURE----- --nextPart4027448.x3sNSZYTVQ-- From nobody Tue Apr 2 09:20: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 C582B120110 for ; Tue, 2 Apr 2019 09:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 68LUJhhde7Fr for ; Tue, 2 Apr 2019 09:20:40 -0700 (PDT) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2912A120052 for ; Tue, 2 Apr 2019 09:20:40 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id v22so7474942lje.9 for ; Tue, 02 Apr 2019 09:20:40 -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=orzJLAgpKiLkheoPi4Lk7+hWOXyGgvWh/Auau+RolOE=; b=ve5CPLvomoI3PdKNhRDc7lMDnKj3zT4wNwcTeOyhJ6I2MYkc6kKqjzqwJQ12ZzpuqR O07c1h/lbyzFEUxTRjo+LFxOzvT2cXY8SYGfoXJbZJJfmf1oXrcr8B4nY2k15x5J6zNW 3PaU011Sp4uU/JP19eorPaJtB1FfsIT6akEdTIg50uKO/fJYheAM8bMIE/0CvL0ilvR6 ovYotkCRzt8lSt3qNa+XdtUBZ+bLS7wX+QrVEpuSGHq254iyjuyze0wXlhIVZLDcAtde Oq8UY/Q0U3j405/SVklNl/bUbx9SlKklYYs3NCe3QaeqOqeBfxtNzAggU/YN3WE+jI6m gQ7Q== 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=orzJLAgpKiLkheoPi4Lk7+hWOXyGgvWh/Auau+RolOE=; b=InVlbPoo9XC3eUNZWsrzeSuWOlmcXote4t1IJbBcC2Z6Null+TQW48DqmegpqhwjOB 2jdwhQMPQOxZspwIZer4D6F8BUziwgBRw45AlUBC3mf0NpyRb1RGqMNGWVZGuNWy6Rh9 LnsTSDMphBRsEI13KZs3flPymz5AhoWgIssS3+UDaGqwHYAdNivea7n6x3A+Esi4t48b 4g8FEQ4TC4Ut8NgI3nNA0BWqCVgzVlGWgyHqvCdnMpCYzquxHmyWsSenql/CDdcvoXRd AnW8MDtViISyq2NHRVLRb6KkIyaxQETHkE9/zz5UOXmPNZRk1kRImZyb65fOO/wHsyLJ G/5Q== X-Gm-Message-State: APjAAAXqWrjUrnX3ZyO9Z3k6UJP8uvV9BvX5cSuKHlCexJ3lRZYS+BDF FlzDlGUgW+pm+6OhPqVraFUDdxhTx/XW7oBvPMO58ZSM X-Google-Smtp-Source: APXvYqwWJbe17oQ9doU/hSDAG1kLiDZ/www6f1QRZh/vjODaRMyqy5FR9gd/XZx2yDgUhULbQqLo7AqDN7UnLc3clAU= X-Received: by 2002:a2e:b042:: with SMTP id d2mr22807086ljl.0.1554222037830; Tue, 02 Apr 2019 09:20:37 -0700 (PDT) MIME-Version: 1.0 From: M K Saravanan Date: Wed, 3 Apr 2019 00:20:26 +0800 Message-ID: To: tls@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [TLS] TLSv1.3 - purpose of _0 in {client, server}_application_traffic_secret_0 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, 02 Apr 2019 16:20:42 -0000 Hi, In TLSv1.3, what is the purpose of _0 suffix in the following: client_application_traffic_secret_0 server_application_traffic_secret_0 with regards, Saravanan From nobody Tue Apr 2 09:29: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 9B95612014A for ; Tue, 2 Apr 2019 09:29:53 -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_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 qQgeVKCTbH4E for ; Tue, 2 Apr 2019 09:29:51 -0700 (PDT) Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B32B3120052 for ; Tue, 2 Apr 2019 09:29:51 -0700 (PDT) Received: by mail-ot1-x331.google.com with SMTP id f10so5000082otb.6 for ; Tue, 02 Apr 2019 09:29:51 -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=B+0/N4V3ur+nXXS70s4CJSyHTyFPBN6poemOs7FQ1Ao=; b=JXqSZiRBn/lcj0TcGj2UxmDhimMapo7teO10hmyf9tt8zOLt6Yngup9VIK/hCVVv5k qcx/oXDOWQhsuZNpPKkcX8zyjVWfXpX18rUb3a9kbj2emm1NJBNLVja83XbxrSEIZj94 r1wz6IuOqDOI4y23ThJS6/Vo0uGN2wJYpn32EXubMgeEMByM6FifQZWs4iL9ZmVBsEZU CmRwt2PrSJGJ7tisdRvZK7OVMryWZV8NekASShrH6o2fJ1xMVOBBV0HZbqoAAhFGWssS xJArCgaMoxf1bkb/zJASlOni0cxDJjRRG11qB801tKd/HiKZkENwQjYCahcGV5RBYNIU MxOA== 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=B+0/N4V3ur+nXXS70s4CJSyHTyFPBN6poemOs7FQ1Ao=; b=JInNS+HkoRRBuoUxWjSjiaTt/hx+6QCr1eELxEXOZA2a14PYbbY81KcoWCaf8DZhlL YkBovRtd8zWUXXJYQXtZjm87tMdQnGHN0HY2mcJeUuXZ+Jg3EQ1emVmYUKMj5bA1SCNY yIi919sQqlwSJf2qTpPPvnIiAIi9rbw1IdToPA2/jr33498RmtlQrNHRkjWF/KZ+fB20 2nrnNQ9kVkEUH2hNwI2ecRU2RlXec9tje5GcZihV6Fft8A8aJXAcfJOwaU8ycOwoPtZd WBA+EC1jNeOY5kx6XdcBKV0CMWfLi9Ii2Ytu5cQBcQFMZpKBjieCv2X2284nYl3cHhZW RWzA== X-Gm-Message-State: APjAAAVv5ZIH9R6ZWS2pqWyBML0SzbhPObA1eIyWgMepCBEIs0Uj9npp 09Xd1Ej1E+7r8NKXidJNzNfaEnR1h6Yj4Av+IGo9qQ== X-Google-Smtp-Source: APXvYqzQH9GF9TGnhsK3VqayTeDKOWEk+S+5mVspH5gXq56sPG/O6LRld7l8quIjx1rsVSgfe44UmX4hDRCMXVl2ddQ= X-Received: by 2002:a9d:4044:: with SMTP id o4mr19201097oti.10.1554222590856; Tue, 02 Apr 2019 09:29:50 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Steven Valdez Date: Tue, 2 Apr 2019 12:29:39 -0400 Message-ID: To: M K Saravanan Cc: "" Content-Type: multipart/alternative; boundary="0000000000006e561305858ea55e" Archived-At: Subject: Re: [TLS] TLSv1.3 - purpose of _0 in {client, server}_application_traffic_secret_0 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, 02 Apr 2019 16:29:53 -0000 --0000000000006e561305858ea55e Content-Type: text/plain; charset="UTF-8" They indicate that those are the initial client/server application traffic secrets, which are then updated via KeyUpdates (section 7.2, https://tools.ietf.org/html/draft-ietf-tls-tls13#section-7.2). On Tue, Apr 2, 2019 at 12:20 PM M K Saravanan wrote: > Hi, > > In TLSv1.3, what is the purpose of _0 suffix in the following: > > client_application_traffic_secret_0 > server_application_traffic_secret_0 > > with regards, > Saravanan > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Steven Valdez | Chrome Networking | svaldez@google.com | 210-692-4742 --0000000000006e561305858ea55e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
They indicate that those are the initial client/server app= lication traffic secrets, which are then updated via KeyUpdates (section 7.= 2,=C2=A0https://tools.ietf.org/html/draft-ietf-tls-tls13#section-7.2).
On = Tue, Apr 2, 2019 at 12:20 PM M K Saravanan <mksarav@gmail.com> wrote:
Hi,

In TLSv1.3, what is the purpose of _0 suffix in the following:

client_application_traffic_secret_0
server_application_traffic_secret_0

with regards,
Saravanan

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


--

= Steven Valdez=C2=A0|=C2=A0Chrome Networking |=C2=A0svaldez@google.com=C2=A0|=C2=A0210-692-4742
--0000000000006e561305858ea55e-- From nobody Tue Apr 2 09:30:04 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 44145120169 for ; Tue, 2 Apr 2019 09:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 2xoeCUJjneka for ; Tue, 2 Apr 2019 09:29:53 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 36DDC120143 for ; Tue, 2 Apr 2019 09:29:53 -0700 (PDT) Received: from xsmtp04.mail2web.com ([168.144.250.231]) by mx147.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1hBMIC-0003Ue-Hb for tls@ietf.org; Tue, 02 Apr 2019 18:29:49 +0200 Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1hBMI6-00031j-1W for tls@ietf.org; Tue, 02 Apr 2019 12:29:39 -0400 Received: (qmail 11233 invoked from network); 2 Apr 2019 16:29:32 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.204]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 2 Apr 2019 16:29:31 -0000 To: Hubert Kario , Martin Thomson Cc: tls@ietf.org References: <2085296.XJS2PnzaK5@pintsize.usersys.redhat.com> <5dbade3c-da1d-42d4-bbd4-b5355681bd56@www.fastmail.com> <2719088.tQPqK0Ev7F@pintsize.usersys.redhat.com> From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: Date: Tue, 2 Apr 2019 09:29:18 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <2719088.tQPqK0Ev7F@pintsize.usersys.redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="II8C7fsemDPupoj81LbjImYVAxZ33zVr6" X-Originating-IP: 168.144.250.231 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.16) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5rDNYyL2j+H/mVxNca0cn2l602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO5IcVwV4jjVcAOtIXxgohGFVMZsRZacTbJPGp/MBC6BxuGJgFlSA3T7mh7q8Zrob8Eh5 mNm/WjPqhYqCeBiCKwwnRtk/d5gNfEtjtud5V8jpF98f/88+i0ieTUe+G30t8h/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8l4YBmPrqPoeRXD34azf1rYZv5uZUEePrXZkexHL9EC3AAJAfA 9MMVcQ9WVjD1q+Rbd9IPG/DQ2p+GU04sTuYFs91jhnM/Mbva2XLV/LIEzaKyLm0zESXAkIAT8ZKA DvsGI5uh86ZVnyOrYkLMWyEaRt9fxN2oReTDHAyOynaY0CmHJLVH4DfVNbPXJmiLfub/IRFsicyJ MEhQFtD8PLoiniWmsFByBoXAuCZEyg59LM/9rUJrEbVA84BZVscMTXpbpuxXJTL417vaJWq5kk+j cuidX4Ts4xdG+C13IyWeZaKyT6mr9s8qAGwXQyBE3k02JDShanNdh9kX4jsWPKXlEwGohaj45S5i iS4NkeLTLwKAImxrekFydH4DojSCKJXVXfdz0+Q1eHsqtFQKXUaZ+h596SWGosiQ15/fAFUBngWU swziTuoonQBgr0dS5AZLiwQzKw+6v3CaIMG6s7LqJPLqe/HyF4yCXBK2jRALLk1SyaRgIwuFZktu hI3SFVknVcWxie7mlFOxFldCdxnaRtYkw5I8sngdZAlE29tX0iXtOuTWXXIj0TpQpfUxR/zGl2P3 1+l14O7iHVplqGBFgz5Gegm2Di+XkC+U0gjMGGKXropzY46klYCXI3beBVahrNLMkKiSx4DbX99P +gh4iWPT5m4OdqWMdE0b4Joz08+J+cv73CChOPjKA0/DVd830vHLIFSGGMV7x6CHvZpJG/9P/4OG qJ5dkO1xTEy0joEwyGTHIAoNFX+jcW7DGmdEezpuI9IICsCKA/p66v7fhw== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: Subject: Re: [TLS] A flags extension 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, 02 Apr 2019 16:29:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --II8C7fsemDPupoj81LbjImYVAxZ33zVr6 Content-Type: multipart/mixed; boundary="1ac4uJcn8wQNyqogyEvR4KURMa4DNQzE1"; protected-headers="v1" From: Christian Huitema To: Hubert Kario , Martin Thomson Cc: tls@ietf.org Message-ID: Subject: Re: [TLS] A flags extension References: <2085296.XJS2PnzaK5@pintsize.usersys.redhat.com> <5dbade3c-da1d-42d4-bbd4-b5355681bd56@www.fastmail.com> <2719088.tQPqK0Ev7F@pintsize.usersys.redhat.com> In-Reply-To: <2719088.tQPqK0Ev7F@pintsize.usersys.redhat.com> --1ac4uJcn8wQNyqogyEvR4KURMa4DNQzE1 Content-Type: multipart/alternative; boundary="------------7A0BADF57C9C8748F677A8F6" Content-Language: en-US This is a multi-part message in MIME format. --------------7A0BADF57C9C8748F677A8F6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 4/2/2019 4:42 AM, Hubert Kario wrote: > On Monday, 1 April 2019 23:05:41 CEST Martin Thomson wrote: >> On Mon, Apr 1, 2019, at 12:40, Hubert Kario wrote: >>>>> would possibly reduce the size of is ServerHello or >>>>> EncryptedExtensions >>>> Those are messages where we have size pressure. >>> why? in what use case? >> QUIC. We have 3600 bytes to play with in that flight. And Certificate = is >> often more than that. > then maybe it's QUIC that should be modified to allow for more than 360= 0 bytes=20 > to actually make it deployable? > > I mean, seriously, if you you need to be bit-pinching now, what will ha= ppen=20 > when PQC gets deployed?! The problem is "amplification" -- how much data the server is willing to send without assurance that the client's address is not spoofed. The current decision is "no more than 3 times the size of the data sent by the client", which is enforced to be at least 1200 bytes. Quic does work if the server flight is longer than that, but then the handshake takes at least 2*RTT instead of 1*RTT. That said, yes, there is a problem if PQC requires the client hello to be larger than 1200 bytes. -- Christian Huitema --------------7A0BADF57C9C8748F677A8F6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On 4/2/2019 4:42 AM, Hubert Kario wrote:
On Monday, 1 April 2019 23:0=
5:41 CEST Martin Thomson wrote:

On Mon, Apr 1, 2019, at 12=
:40, Hubert Kario wrote:

would possibly reduc=
e the size of is ServerHello or
EncryptedExtensions

Those are messages whe=
re we have size pressure.

why? in what use case?

QUIC. We have 3600 bytes t=
o play with in that flight. And Certificate is
often more than that.

then maybe it's QUIC that sh=
ould be modified to allow for more than 3600 bytes=20
to actually make it deployable?

I mean, seriously, if you you need to be bit-pinching now, what will happ=
en=20
when PQC gets deployed?!


The problem is "amplification" -- how much data the server is willing to send without assurance that the client's address is not spoofed. The current decision is "no more than 3 times the size of the data sent by the client", which is enforced to be at least 1200 bytes. Quic does work if the server flight is longer than that, but then the handshake takes at least 2*RTT instead of 1*RTT.

That said, yes, there is a problem if PQC requires the client hello to be larger than 1200 bytes.

-- Christian Huitema


--------------7A0BADF57C9C8748F677A8F6-- --1ac4uJcn8wQNyqogyEvR4KURMa4DNQzE1-- --II8C7fsemDPupoj81LbjImYVAxZ33zVr6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJco43rAAoJELba05IUOHVQl8gH/3++8O/rBSckWZBIOt2Uesbj EKrLQ2cxKxV6F3ODr/ghlTJ6CC5iInPMswI1gZBF9ZdBpvk+B5Knaae439GWVmOT NaqJWYdkU+Rg/hFhMawkeksGNZ3chCeFf65PS3p4H8Wtf8eM9rn69q9SSN1/nUVL yw4+RUCjl+SjTomjvTGR0BvWu5NSlNxpUfkKGuVrtvyPG0fa0Vu+mxvPfZfW6ASb ITyzAZO8o94FTRv+MlBdGtY/ljuXA46wdMF5r6io59aOZRqvCp7UGft1f9bhqkzB Vn+N6oMxLpuBc/VkXDv2P6UhUhalADmzqNIBSfOArbYHpGy1j1qWwgTb6oikogA= =vufa -----END PGP SIGNATURE----- --II8C7fsemDPupoj81LbjImYVAxZ33zVr6-- From nobody Wed Apr 3 04:03: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 D7B1812008B for ; Wed, 3 Apr 2019 04:03:30 -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 RHFir4Zv5Or7 for ; Wed, 3 Apr 2019 04:03:28 -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 83203120091 for ; Wed, 3 Apr 2019 04:03:28 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D7E5D308427C; Wed, 3 Apr 2019 11:03:17 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.83]) by smtp.corp.redhat.com (Postfix) with ESMTP id 00D24608AD; Wed, 3 Apr 2019 11:03:14 +0000 (UTC) From: Hubert Kario To: Christian Huitema Cc: Martin Thomson , tls@ietf.org Date: Wed, 03 Apr 2019 13:03:07 +0200 Message-ID: <6301899.6P8vclEgcA@pintsize.usersys.redhat.com> In-Reply-To: References: <2719088.tQPqK0Ev7F@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2138393.kk4MFY0jaO"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.40]); Wed, 03 Apr 2019 11:03:22 +0000 (UTC) Archived-At: Subject: Re: [TLS] A flags extension 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, 03 Apr 2019 11:03:31 -0000 --nextPart2138393.kk4MFY0jaO Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Tuesday, 2 April 2019 18:29:18 CEST Christian Huitema wrote: > On 4/2/2019 4:42 AM, Hubert Kario wrote: > > On Monday, 1 April 2019 23:05:41 CEST Martin Thomson wrote: > >> On Mon, Apr 1, 2019, at 12:40, Hubert Kario wrote: > >>>>> would possibly reduce the size of is ServerHello or > >>>>> EncryptedExtensions > >>>>=20 > >>>> Those are messages where we have size pressure. > >>>=20 > >>> why? in what use case? > >>=20 > >> QUIC. We have 3600 bytes to play with in that flight. And Certificate = is > >> often more than that. > >=20 > > then maybe it's QUIC that should be modified to allow for more than 3600 > > bytes to actually make it deployable? > >=20 > > I mean, seriously, if you you need to be bit-pinching now, what will > > happen > > when PQC gets deployed?! >=20 > The problem is "amplification" -- how much data the server is willing to > send without assurance that the client's address is not spoofed. The > current decision is "no more than 3 times the size of the data sent by > the client", which is enforced to be at least 1200 bytes. Quic does work > if the server flight is longer than that, but then the handshake takes > at least 2*RTT instead of 1*RTT. so how many connections will end up with a 2RTT instead of 1RTT handshake i= f=20 the server response is not smaller by those 12 bytes or so? how many connections will actually end up with larger server response becau= se=20 they need to send just one flag? =20 > That said, yes, there is a problem if PQC requires the client hello to > be larger than 1200 bytes. or the server has certificates with PQC signatures that are few KiB long... the more PQC is deployed, to more the balance will be skewed towards the=20 server, as far as data sent is concerned =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 --nextPart2138393.kk4MFY0jaO 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+dkqjRuAHS9fUFAlykkusACgkQkqjRuAHS 9fUu9xAAj8HJdEpNRq4UHDQ2V9qmtkRaI/kZSzggKdYydnd/1clpo+j8vVu+OI6o yyiJ+5PM+NnYlLPOzSkC1PhXeeAgEy1vuAe9S9cO9ut7bX6XAequThUXxdcELa6H YUCHVUCc5CzKsLdVVVy+UL7KTWSU8Ugd1obgWxl+Wo7doSEIRem6yxfguKk63bOX 9Kxh2csjXdpNzz1l/dysFz2LxFFqaY+nns/OxysH4RuiAunrHCHn5O/MQTKoWwNR lgM2npCTi91Z1lH768wi/t1XIP0hr7eDqgBgW1zyPdjYjBFe/fHvRctkpANtDeZe lbJGaiovf8ekTemAWwNAPzkQZ3kpipughk+bwSCqdK+by1ZZlz7o34XfWBPtXrQC /pTNpfce1ck2THkFNKgoAKvzuM4QxGbX8ZWYw4NlYFhscKi9XX4DXTFtjzx6LVK2 WkB0i79O6rrZaIV42FcNUFcBjEOiwD+OfOPRPPjSzr0V1UoUEO6ZGCmzp5gX1rfn AkM0fIuRHh+999KllfTZf/Xx/llnReu4D2r1tbpsG8xucLR6DWW6NkLezBBMUzub 7vWzLBEIExXfEZLH8UH2TxXp+tvn3pyEJP+u8Ozle4AUOC8X/EFOpAiV/yXWoD2b wge1jLX3O+9JzSKb2T6W1XB+FLNJCjy+zr69n+KDl03qu6PQFLg= =vmIL -----END PGP SIGNATURE----- --nextPart2138393.kk4MFY0jaO-- From nobody Wed Apr 3 07:25: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 1B1AF1200A2 for ; Wed, 3 Apr 2019 07:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.79 X-Spam-Level: X-Spam-Status: No, score=-0.79 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_FROM_FMBLA_NEWDOM=0.01, 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=LLixYXCB; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=X//r6qhn Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crJb45bc317k for ; Wed, 3 Apr 2019 07:25:32 -0700 (PDT) Received: from new4-smtp.messagingengine.com (new4-smtp.messagingengine.com [66.111.4.230]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CE9F120003 for ; Wed, 3 Apr 2019 07:25:32 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailnew.nyi.internal (Postfix) with ESMTP id 4D151C5F3; Wed, 3 Apr 2019 10:25:31 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Wed, 03 Apr 2019 10:25:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=fm1; bh= hoTkabl/rhUPH5M3jZQfPjy2FiJud88bxAekwxmfdmQ=; b=LLixYXCBu2KwppaL H29wnc/nJo7Hijk5WLP9KXTrXDCQM9ywAfGbt0G16A0Dp6Uc0pNErpgA3/Vhy5xp Ji6nOPHPCCnVRGCIvptw5E75fwOg7qHUjMqvtqdrQbF921jWm1LfW+0J9QpGEXNx R9JuOYxxI4EsdXFXGCIWww8rbSLl97lFRjrCYdBPcEspJls8Q2NxJdeOv38RIlkP x11GJXuEETdoU+mSdcFOpRwz0aEDnflcL20DbRWGcKmiUarDhneSgF5rPRuY97HJ SQhcnDKJH1G1mRjY4Cv7NytTD6MKmpDZO1S9QW1LIaTRazVoSEtyGt6oPKXVF05G YJApLg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding: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=fm2; bh=hoTkabl/rhUPH5M3jZQfPjy2FiJud88bxAekwxmfd mQ=; b=X//r6qhnPGwGh4Unn4sWY1/qfO/lV94TLZEu2E2n0/53uvABz+/AEtbkB sa16WwqE9MI3MM5fOXXR7fKGF0qYRP3ijcR1GfNmxlF2wG3kgKKtwvHMpuJmMTkO yOxnHrTytv1lBbpRMZy5VgD5v20AOOEV8PYZ1isHdzfmTT1MxAM7ZuCP0U1WPGde eZuBhAfzCDoyODdOZC/v10BxOr5GwQ0/Z1IuehDAswAZXCwQ6iypcgm7xtQWCdBS 3axT7PnLI2Qx6vDKagmwEd413H0jI3STtijzE5NXcovT4s6kRaj+3slrevfdELOw rxweQDj9slG+tM9ikJ9VBp/dgx3RA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrtdefgdehtdculddtuddrgedutddrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg hnthhsucdlqddutddtmdenucfjughrpefhvffufffokfgjfhggtgfgsehtkehmtdertdej necuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgifsehhvggrph hinhhgsghithhsrdhnvghtqeenucffohhmrghinhepghhithhhuhgsrdgtohhmpdhivght fhdrohhrghenucfkphepudeggedrudejkedrvdekrdduudenucfrrghrrghmpehmrghilh hfrhhomheptggrfieshhgvrghpihhnghgsihhtshdrnhgvthenucevlhhushhtvghrufhi iigvpedt X-ME-Proxy: Received: from [172.16.29.43] (unknown [144.178.28.11]) by mail.messagingengine.com (Postfix) with ESMTPA id 0C2B6E4176; Wed, 3 Apr 2019 10:25:28 -0400 (EDT) From: "Christopher Wood" To: "John Mattsson" Cc: TLS@ietf.org Date: Wed, 03 Apr 2019 07:25:17 -0700 X-Mailer: MailMate (1.12.4r5594) Message-ID: In-Reply-To: <89127FF7-CE3F-4DF1-98A5-B1006C5FF56B@ericsson.com> References: <89127FF7-CE3F-4DF1-98A5-B1006C5FF56B@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] Comments on draft-wood-tls-external-psk-importer-01 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, 03 Apr 2019 14:25:35 -0000 Thanks for the feedback, John. I filed issues on the GitHub draft located at [1]. Please see inline below for comments. On 1 Apr 2019, at 12:00, John Mattsson wrote: > Hi, > > Thanks for trying to solve this problem! Not having a way to use the > same external PSK for different cipher suites is definitely a thing > missing from TLS 1.3. > > As I stated during the wg session, 3GPP have a few use cases that use > PSK-ECDHE between phone and core network. Contrary to what IETF people > sometimes believe, most 3GPP use of TLS (between phone and core > network, between core nodes, and between different operators) use > mutual authentication with certificates. > > According to the current 3GPP specification, the phone and the core > network would share an external PSK and an external identity. The hash > function is undefined, i.e. SHA-256 is used for TLS 1.3. The phone and > the network would then negotiate TLS 1.2 with any cipher suite or TLS > 1.3 with SHA-256. > > Some comments > > - The draft should make clear if the External PSK and external > identity can be used together with the imported identities. I assume > the idea is that they can’t but I can’t see any text specifying > this. Indeed, that was the intent. > > - ”Imported keys do not require negotiation for use, as a client and > server will not agree upon identities if not imported correctly. > Thus, importers induce no protocol changes with the exception of > expanding the set of PSK identities sent on the wire.” > > While I see how the defined mechanism can be deployed in a new > deployment, I do not see how to introduce it in an existing > deployment. Assuming that the external PSK cannot be used together > with the imported identities, the TLS client and server must introduce > the mechanism at the same time, that is often not possible to control. You’re correct that this requires both endpoints to adopt the change simultaneously. However, that does not contradict the quoted text, which states that the protocol is not changed. > > - “struct { > opaque external_identity<1...2^16-1>; > opaque label<0..2^8-1>; > HashAlgorithm hash; > } ImportedIdentity; > ” > > This scales poorly, A client has to send n*m identities where n is the > number of supported versions and m is the number of supported hash > algorithms... Yes, this is a tradeoff we made by opting to not modify the key schedule. > > - Would it not be possible to just use the version number as label? > I.e. 0x0304 instead of “tls13”. In that way you do at least not > have to define a new labels. We probably could, though since the labels are subject to change (see the TODO about possibly including the HashAlgorithm in the label), we kept it as is. > > - “TLS 1.3 [RFC8446] supports pre-shared key (PSK) resumption, > wherein > PSKs can be established via session tickets from prior connections or > externally via some out-of-band mechanism.” > > This seems to indicate that all use of PSK is resumption which is not > correct. I suggest changing to “TLS 1.3 [RFC8446] supports > pre-shared key (PSK) authentication” Good suggestion! We’ll fix it. > > - “importing external PSK (Pre-Shared Key) into TLS.” > > Not sure if “into” is the right word, I think “for” as in th e > title is better. The mechanism seems very much external to TLS itself. > I see it as a mechanism to derive several external PSKs from a single > external PSK. Ditto. > > - “Similarly, TLS 1.2 and all prior TLS versions should use "tls12" > “ > > The versions prior to TLS 1.2 will soon be deprecated. And why spend > time updating the TLS 1.2 code base instead of moving to TLS 1.3? We’re just covering our bases here. I tend to agree that the focus should be on updating to TLS 1.3 instead of “patching” TLS 1.2 stacks. > > > Suggestion: > > Instead of deriving a large set of new external PSKs, wouldn’t it be > possible to just use different hash functions in different parts of > the key hierarchy? I.e. if SHA-256 is associated with the external PSK > and SHA-384 is the hash algorithms in the chosen cipher suite: > > PSK -> HKDF-Extract(SHA-256) = Early Secret > | > +-----> Derive-Secret(., "ext binder" | "res binder", "") > | = binder_key > | > +-----> Derive-Secret(., "c e traffic", ClientHello) > | = client_early_traffic_secret > | > +-----> Derive-Secret(., "e exp master", ClientHello) > | = early_exporter_master_secret > v > Derive-Secret(., "derived", "") > | > v > (EC)DHE -> HKDF-Extract(SHA-384) = Handshake Secret > > Support of this could be signalled with the tls_flags extension. If > the server does not support the extension it must according to RFC > 8446 chose a cipher suite with SHA-256. Modifying the key schedule was discussed in the context of [2]. At the time, it seemed the desire to not touch the key schedule outweighed the desire to not inflate the ClientHello. Best, Chris [1] https://github.com/chris-wood/draft-wood-tls-external-psk-importer [2] https://tools.ietf.org/html/draft-davidben-tls-universal-psk-00 From nobody Wed Apr 3 12:43: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 378DC12022C for ; Wed, 3 Apr 2019 12:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.5 X-Spam-Level: X-Spam-Status: No, score=-9.5 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.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham 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 xa2ytaD34NRp for ; Wed, 3 Apr 2019 12:43:07 -0700 (PDT) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E85C1201EB for ; Wed, 3 Apr 2019 12:43:07 -0700 (PDT) Received: by mail-qt1-x82b.google.com with SMTP id w30so424460qta.8 for ; Wed, 03 Apr 2019 12:43:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:from:date:message-id:subject:to; bh=0hdPccNwDJGlXyqzk4qYKyMbDFAYM10AwP9UlEgH4WM=; b=MSdMrRGJk7XUJXxp11Q3JtqBn/pGRg/qy04WSPTmatE9+QcIsmtmwOP7nRqfMSIiQS W/jitt58G/vbZ75b4g++1zT2ennsummq4nTKwJwD1oKZ/PZaXjz8NxwzWtDk1F6wxgtJ +Q8Bj8wpA6hH4nzI19hU1pV8wWJNwkKJkbrKs= 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=0hdPccNwDJGlXyqzk4qYKyMbDFAYM10AwP9UlEgH4WM=; b=UcB4OEHFe8ZcGBi+/k/UcNXWmFXRfF3C/3xtJ3BSrxz+P8Qydyrd2xQK2jIqjFj0OG QDHPE5LsuwdLSjchpdU0XJFy9I0JCMgtlhEDMEmlhD0hTDUfnrQIv+3Ezde1k5zGiGQb 7eP7kh8EH7wPMPWpidsg86ydxkLQkK7rDFP7nTR0nvb6oW9hXi/tMZiR5CrHZyHnsdnR cboxFBDYkALqzHgRrYMjwnIMm6/sOws4wzhk96x6/cH3cTveIO0s0WplXv21OSFZTU0E xSRdCdlKhMKwWewVazV6r9/JNtWftQPQ03foeJ7PtOGEr7gKnRpIWMRqNZUWp98DhIie Kylw== X-Gm-Message-State: APjAAAVDASowxY6CP41hW8eOI1O9J6CpHBFjxC1NABLmTrGzcS/kZsJ9 ufZBnFwlkgJY+qpgKd8NZm9I+6kRn1R3hMyxdKFWTyY3pA== X-Google-Smtp-Source: APXvYqxrl31Q9TcN2l91xOvclfGyOiI9UkGia454hHpg/SQHew+dEuuEmCKTxuhQEm4GJ5VUaUBSB2PA1TUKsxvfaDY= X-Received: by 2002:a0c:ac83:: with SMTP id m3mr1255506qvc.85.1554320586066; Wed, 03 Apr 2019 12:43:06 -0700 (PDT) MIME-Version: 1.0 From: David Benjamin Date: Wed, 3 Apr 2019 14:42:50 -0500 Message-ID: To: "" Content-Type: multipart/alternative; boundary="000000000000669bb60585a5762e" Archived-At: Subject: [TLS] draft-ietf-tls-dtls13-31 comments 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, 03 Apr 2019 19:43:10 -0000 --000000000000669bb60585a5762e Content-Type: text/plain; charset="UTF-8" Hi all, I read through draft-ietf-tls-dtls13-31 and gathered a bunch of comments. I uploaded https://github.com/tlswg/dtls13-spec/pull/85 for the easy bits. The remainder I figured I should send to the list. Hopefully this is a usable format. Apologies for the very late look over it. I haven't had time to page it in before now. In section 4, I assume that if not negotiated, CID cannot be present and the receiver rejects any records with it? It might be worth spelling that out explicitly. Section 4.2.1 reads odd to me. I assume the references to 1 and 2 are just as an example and not a particular oddity from those epochs. Maybe stick a "for example" or say "earlier and later epoch". It also says that during the handshake, "implementations MUST accept packets from the old epoch", which is ambiguous as there are several epochs in the handshake. That sentence also runs counter to the SHOULD immediately at the start of the paragraph, which is odd. Section 4.5.1 talks about timing channels for the sequence number. Note even uncompressing the sequence number (finding the right upper bytes) introduces a timing channel. Granted, it is a much much weaker one than record deprotection, but invalid DTLS records being non-fatal means signals can be amplified... Section 5 says that implementations MUST ignore ChangeCipherSpec messages. This contradicts section 4.1, which does not include change_cipher_spec as one of the possible record rtypes for DTLSPlaintext. It does fall through to section 4.5.2, but 4.5.2 allows for implementations to reject these. (Is there actually a need to ignore them in DTLS 1.3 if the middlebox hacks aren't applicable?) I don't understand the last paragraph of section 5.1. What's it trying to describe? If the client got its hands on an invalid cookie, there's no recovering that handshake. The server won't accept the cookie, and the client won't accept a second HRR. Section 5.3 says that the supported_versions extension is used without modification from TLS 1.3, but that still leaves its contents ambiguous. Is DTLS 1.3 0304 or fefc? I assume 0304 since fefc isn't mentioned. But then how are DTLS 1.0 and DTLS 1.2 encoded? (One could imagine omitting them, but that doesn't match how TLS 1.3 did it.) I assume they remain feff and fefd, so we don't need to answer whether DTLS 1.0 is 0301 or 0302. Either way, this should probably be spelled out. This is a nitpick and exists in DTLS 1.2 too, but section 5.4 uses the term "maximum handshake fragment size", but nowhere else in the document is the term defined or referenced. This means the largest handshake fragment such that the resulting DTLS record fits in a packet. (Though even that's incomplete because you might have previously allocated a smaller fragment and then have less room left for the next fragment. It gets further messier when packing fragments into records and having to worry about when you are and aren't forced to add a record boundary for epoch change...) Section 5.9 is weird. With warning alerts gone, all alerts are fatal. Either you've torn down all local state and don't resend alerts (I suspect most applications just do this, for better or worse), or maybe you're hanging around for a while to resend them. If the latter, you probably don't want to be trying to detect that the offending record got resent, since that involves processing records out of a connection in an error state. It seems better to blindly retransmit on every packet until you get bored. Relatedly, what does close_notify mean in DTLS? This draft and DTLS 1.2 don't seem to make any mention of it. Bidirectional shutdown doesn't make much sense. Not sure if unidirectional is meaningful, given lack of retransmits. Maybe a best effort thing to save the peer a timeout. Section 6.1 says: Implementations that receive a payload with an epoch value for which no corresponding cipher state can be determined MUST generate a "unexpected_message" alert. This seems to be cover data from the next epoch, which contradicts section 4.2.1. (If I receive, say, EncryptedExtensions before ServerHello, I can't determine the cipher state for that epoch.) Section 4.2.1 says you should either buffer or drop those records, not reject them. Section 7 defines ACKs with a uint64 record_number. I assume this is a concatenated epoch and sequence number, but I don't see anywhere defines this. Perhaps just write it as: struct { uint16 epoch; uint48 sequence_number; } RecordNumber; struct { RecordNumber record_numbers<0..2^16-1>; } ACK; Relatedly, what is the "record sequence number" input to the AEAD (RFC 8446, section 5.3)? DTLS believes that the "sequence number" is 48 bits, but the rest of TLS 1.3 is written expecting a 64-bit sequence number. Using the concatenation is simplest and also matches RFC 7905, but should be mentioned explicitly. (RFC 6347 didn't have text to this effect because it only had AES-GCM which, in (D)TLS 1.2, used explicit IVs.) (I will probably have other comments on the ACK bits, but I think I need to digest it more carefully to try to understand what's going on. It does seem a little overkill for what is ultimately a small handful of packets...) David --000000000000669bb60585a5762e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

I r= ead through draft-ietf-tls-dtls13-31 and gathered a bunch of comments. I up= loaded https://git= hub.com/tlswg/dtls13-spec/pull/85 for the easy bits. The remainder I fi= gured I should send to the list. Hopefully this is a usable format. Apologi= es for the very late look over it. I haven't had time to page it in bef= ore now.

In section 4, I assume that if not negoti= ated, CID cannot be present and the receiver rejects any records with it? I= t might be worth spelling that out explicitly.

Sec= tion 4.2.1 reads odd to me. I assume the references to 1 and 2 are just as = an example and not a particular oddity from those epochs. Maybe stick a &qu= ot;for example" or say "earlier and later epoch". It also sa= ys that during the handshake, "implementations MUST accept packets fro= m the old epoch", which is ambiguous as there are several epochs in th= e handshake. That sentence also runs counter to the SHOULD immediately at t= he start of the paragraph, which is odd.

Section 4= .5.1 talks about timing channels for the sequence number. Note even uncompr= essing the sequence number (finding the right upper bytes) introduces a tim= ing channel. Granted, it is a much much weaker one than record deprotection= , but invalid DTLS records being non-fatal means signals can be amplified..= .

Section 5 says that implementations MUST ignore = ChangeCipherSpec messages. This contradicts section 4.1, which does not inc= lude change_cipher_spec as one of the possible record rtypes for DTLSPlaint= ext. It does fall through to section 4.5.2, but 4.5.2 allows for implementa= tions to reject these. (Is there actually a need to ignore them in DTLS 1.3= if the middlebox hacks aren't applicable?)

I = don't understand the last paragraph of section 5.1. What's it tryin= g to describe? If the client got its hands on an invalid cookie, there'= s no recovering that handshake. The server won't accept the cookie, and= the client won't accept a second HRR.

Section= 5.3 says that the supported_versions extension is used without modificatio= n from TLS 1.3, but that still leaves its contents ambiguous. Is DTLS 1.3 0= 304 or fefc? I assume 0304 since fefc isn't mentioned. But then how are= DTLS 1.0 and DTLS 1.2 encoded? (One could imagine omitting them, but that = doesn't match how TLS 1.3 did it.) I assume they remain feff and fefd, = so we don't need to answer whether DTLS 1.0 is 0301 or 0302. Either way= , this should probably be spelled out.

This is a n= itpick and exists in DTLS 1.2 too, but section 5.4 uses the term "maxi= mum handshake fragment size", but nowhere else in the document is the = term defined or referenced. This means the largest handshake fragment such = that the resulting DTLS record fits in a packet. (Though even that's in= complete because you might have previously allocated a smaller fragment and= then have less room left for the next fragment. It gets further messier wh= en packing fragments into records and having to worry about when you are an= d aren't forced to add a record boundary for epoch change...)

Section 5.9 is weird. With warning alerts gone, all alerts = are fatal. Either you've torn down all local state and don't resend= alerts (I suspect most applications just do this, for better or worse), or= maybe you're hanging around for a while to resend them. If the latter,= you probably don't want to be trying to detect that the offending reco= rd got resent, since that involves processing records out of a connection i= n an error state. It seems better to blindly retransmit on every packet unt= il you get bored.

Relatedly, what does close_notif= y mean in DTLS? This draft and DTLS 1.2 don't seem to make any mention = of it. Bidirectional shutdown doesn't make much sense. Not sure if unid= irectional is meaningful, given lack of retransmits. Maybe a best effort th= ing to save the peer a timeout.

Section 6.1 says:<= /div>

=C2=A0 Implementations that receive a payload with= an epoch value for which
=C2=A0 =C2=A0no corresponding cipher st= ate can be determined MUST generate a
=C2=A0 =C2=A0"unexpect= ed_message" alert.

This seems to be cover dat= a from the next epoch, which contradicts section 4.2.1. (If I receive, say,= EncryptedExtensions before ServerHello, I can't determine the cipher s= tate for that epoch.) Section 4.2.1 says you should either buffer or drop t= hose records, not reject them.

Section 7 defines A= CKs with a uint64 record_number. I assume this is a concatenated epoch and = sequence number, but I don't see anywhere defines this. Perhaps just wr= ite it as:

=C2=A0 =C2=A0 struct {
=C2=A0= =C2=A0 =C2=A0 =C2=A0 uint16 epoch;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 u= int48 sequence_number;
=C2=A0 =C2=A0 } RecordNumber;
=C2=A0 =C2=A0 struct {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 R= ecordNumber record_numbers<0..2^16-1>;
=C2=A0 =C2=A0 } ACK;=

Relatedly, what is the "record sequence numb= er" input to the AEAD (RFC 8446, section 5.3)? DTLS believes that the = "sequence number" is 48 bits, but the rest of TLS 1.3 is written = expecting a 64-bit sequence number. Using the concatenation is simplest and= also matches RFC 7905, but should be mentioned explicitly. (RFC 6347 didn&= #39;t have text to this effect because it only had AES-GCM which, in (D)TLS= 1.2, used explicit IVs.)

(I will probably have ot= her comments on the ACK bits, but I think I need to digest it more carefull= y to try to understand what's going on. It does seem a little overkill = for what is ultimately a small handful of packets...)

<= div>David
--000000000000669bb60585a5762e-- From nobody Wed Apr 3 23:22: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 4DC65120320 for ; Wed, 3 Apr 2019 23:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_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=ericsson.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 XmxfQFNoB97e for ; Wed, 3 Apr 2019 23:22:32 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00080.outbound.protection.outlook.com [40.107.0.80]) (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 A9AFA120338 for ; Wed, 3 Apr 2019 23:22:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BkOxE/RLmJm4qAgCO8/AcF3MKTXObMiRnCVCyUtdCFM=; b=cokM2IFaSB52KbSYlvzf+ecOFsIvu++vRrL1l2k4uV6IVgu8OljAh/iQOph6hxocvkai+WZSGp2fQ+y+ILf8s9wM734239D/xBblmdqYUwG3ZT7syerSI81cgBtQQu3V56/K7emG1haFM3nVaY0Or8FdV9Xiya10hL0EKjlaWLA= Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.166.22) by HE1PR07MB4380.eurprd07.prod.outlook.com (20.176.167.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.6; Thu, 4 Apr 2019 06:22:29 +0000 Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::91bd:a367:2414:b4bc]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::91bd:a367:2414:b4bc%5]) with mapi id 15.20.1771.007; Thu, 4 Apr 2019 06:22:28 +0000 From: John Mattsson To: Christopher Wood CC: "TLS@ietf.org" Thread-Topic: [TLS] Comments on draft-wood-tls-external-psk-importer-01 Thread-Index: AQHU6L09RDZKHT8Ksk2niB+rgTbbFKYqgKOAgAEs9wA= Date: Thu, 4 Apr 2019 06:22:28 +0000 Message-ID: References: <89127FF7-CE3F-4DF1-98A5-B1006C5FF56B@ericsson.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.17.1.190326 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [82.214.46.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7bdbf200-9716-4bfb-c729-08d6b8c5e9c2 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR07MB4380; x-ms-traffictypediagnostic: HE1PR07MB4380: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 0997523C40 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(39860400002)(366004)(346002)(376002)(396003)(199004)(189003)(51914003)(13464003)(25786009)(229853002)(86362001)(71190400001)(8936002)(83716004)(71200400001)(8676002)(33656002)(3846002)(6116002)(36756003)(6486002)(256004)(106356001)(105586002)(14454004)(2906002)(5660300002)(6436002)(44832011)(81166006)(81156014)(966005)(6916009)(6512007)(6306002)(53546011)(478600001)(6506007)(53936002)(66066001)(2616005)(186003)(97736004)(26005)(102836004)(82746002)(6246003)(7736002)(486006)(11346002)(476003)(446003)(305945005)(4326008)(99286004)(58126008)(316002)(68736007)(76176011); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4380; H:HE1PR07MB4169.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 4gfEMnAWVuJaVvIqoYEalpjMnSk+TyR6cbBtC8HQ65jGC4gwdAaCAbXbmrPtZuoc3bjiwSyylEyzZ9TK11Dgsv6OeikfU/SxhLwzdczdsbdKxWhyabWXnfsr020XjnO1fBcQQFQU3gXWRxTVIEwgM7pSQoDakvrEB/FLkbjjJFdJauCLTPnLFcRsroTK6tJ1ViZA62rRGXFqtOAHUMwXNn/PvzcWecL7cBq1nHILlhxsISWbH0mhAU8kl0Ih6hYo+0+Lu9e3ac15MfjgNG8/7SJemfanpoOX5kRAXkrkdaTJRhFLSfgvQ2VlAB5KCMj54d2jiLhQkjHlZW6x2RBdLi9hF5v20AlKC54xx5dQxcOZWENI3RnSkRDzjxiPIcZOFRYBqpsZcTvYZTaPaS0sjF5z+bVLPa295alWIKXwNoI= Content-Type: text/plain; charset="utf-8" Content-ID: <9C384550DFD44542AC03920CC3A71235@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7bdbf200-9716-4bfb-c729-08d6b8c5e9c2 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2019 06:22:28.7697 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4380 Archived-At: Subject: Re: [TLS] Comments on draft-wood-tls-external-psk-importer-01 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, 04 Apr 2019 06:22:35 -0000 SGkgQ2hyaXN0b3BoZXIsDQoNClRoYW5rcyBmb3IgdGhlIGNsYXJpZmljYXRpb25zLg0KDQo+WW91 4oCZcmUgY29ycmVjdCB0aGF0IHRoaXMgcmVxdWlyZXMgYm90aCBlbmRwb2ludHMgdG8gYWRvcHQg dGhlIGNoYW5nZSANCj5zaW11bHRhbmVvdXNseS4gSG93ZXZlciwgdGhhdCBkb2VzIG5vdCBjb250 cmFkaWN0IHRoZSBxdW90ZWQgdGV4dCwgd2hpY2ggDQo+c3RhdGVzIHRoYXQgdGhlIHByb3RvY29s IGlzIG5vdCBjaGFuZ2VkLg0KDQpJIHRoaW5rICJ0aGlzIHJlcXVpcmVzIGJvdGggZW5kcG9pbnRz IHRvIGFkb3B0IHRoZSBjaGFuZ2Ugc2ltdWx0YW5lb3VzbHkiIGlzIGEgcHJvYmxlbSBhcyBpdCBt YWtlcyBpdCBpbXBvc3NpYmxlIHRvIGludHJvZHVjZSB0aGlzIG1lY2hhbmlzbSBpbiBtYW55IGV4 aXN0aW5nIGRlcGxveW1lbnRzLiBJIHdvdWxkIGV4cGVjdCBhIHNvbHV0aW9uIHRoYXQgY2FuIGJl IGludHJvZHVjZWQgZ3JhZHVhbGx5IChzb21lIG5vZGVzIGF0IGEgdGltZSkgaW4gZXhpc3Rpbmcg ZGVwbG95bWVudHMgc3VwcG9ydGluZyBSRkMgODQ0NiBhbmQvb3IgUkZDIDUyNDYuDQoNCkJ1dCwg aWYgeW91IHdhbnQgdG8gY2hhbmdlIHRoZSBiZWhhdmlvdXIgb2YgdGhlIHVzaW5nIHRoZSBzYW1l IGV4dGVybmFsIFBTSyBpbiBib3RoIFRMUyAxLjIgYW5kIFRMUyAxLjMgYXMgYWxsb3dlZCBieSBS RkMgODQ0NiwgYSBzb2x1dGlvbiBub3QgcmVxdWlyaW5nICJzaW11bHRhbmVvdXMgY2hhbmdlIiBp cyBwcm9iYWJseSBub3QgcG9zc2libGUuDQoNClRoZSByZXF1aXJlbWVudCB0aGF0ICJ0aGlzIHJl cXVpcmVzIGJvdGggZW5kcG9pbnRzIHRvIGFkb3B0IHRoZSBjaGFuZ2Ugc2ltdWx0YW5lb3VzbHki IHNob3VsZCBwcm9iYWJseSBiZSBoaWdobGlnaHRlZCBpbiB0aGUgZG9jdW1lbnQuDQoNClRoZSBj dXJyZW50IG1lY2hhbmlzbSBkb2VzIG5vdCBzZWVtIHRvIGJlIGRlcGxveWFibGUgZm9yIGUuZy4g M0dQUCB1bnRpbCBUTFMgMS40IGlzIGludHJvZHVjZWQsIGFuZCB0aGVuIG9ubHkgZm9yIFRMUyAx LjQgYW5kIGxhdGVyLi4uICBvbiB0aGUgb3RoZXIgaGFuZCwgYmVpbmcgbGltaXRlZCB0byBTSEEt MjU2IGZvciBQU0sgbWF5IGJlIG9rIGZvciAzR1BQLiAoYW5kIDNHUFAgY291bGQganVzdCBkZXJp dmUgYSBTZXBhcmF0ZSBTSEEtMzg0IFBTSyBpZiBuZWVkZWQpLg0KDQpTb21lIG1vcmUgY29tbWVu dDoNCg0KLSBXaGljaCBsYWJlbCBzaG91bGQgYmUgdXNlZCBieSB2YXJpb3VzIHZlcnNpb25zIG9m IERUTFM/DQoNCi0gIklmIGEgY2xpZW50IG9yIHNlcnZlciB3aXNoIHRvIGRlcHJlY2F0ZSBhIGhh c2ggZnVuY3Rpb24gYW5kIG5vIGxvbmdlcg0KdXNlIGl0IGZvciBUTFMgMS4zLCB0aGV5IG1heSBy ZW1vdmUgdGhpcyBoYXNoIGZ1bmN0aW9uIGZyb20gdGhlIHNldA0Kb2YgaGFzaGVzIHVzZWQgZHVy aW5nIHdoaWxlIGltcG9ydGluZyBrZXlzLiAgVGhpcyBkb2VzIG5vdCBhZmZlY3QgdGhlDQpLREYg b3BlcmF0aW9uIHVzZWQgdG8gZGVyaXZlIGNvbmNyZXRlIFBTS3MuIg0KDQpJZiBzb21lb25lIGRl cHJlY2F0ZXMgdGhlIHVzZSBvZiBhIGhhc2ggZnVuY3Rpb24gaW5zaWRlIFRMUyAxLjMgKHVzZWQg YnkgVHJhbnNjcmlwdC1IYXNoIGFuZCBIS0RGKSwgZG9lcyBpdCB0aGVuIG1ha2VzIHNlbnNlIHRv IGtlZXAgZGVyaXZpbmcga2V5cyBvdXRzaWRlIG9mIFRMUyB3aXRoIHRoYXQgc2FtZSBkZXByZWNh dGVkIGhhc2ggZnVuY3Rpb24/DQoNCi0gIlRvIG1pdGlnYXRlIHRoZXNlIHByb2JsZW1zLCBleHRl cm5hbCBQU0tzIGNhbiBiZSBib3VuZCB0byBhIHNwZWNpZmljIGhhc2ggZnVuY3Rpb24gd2hlbiB1 c2VkIGluIFRMUyAxLjMiDQoNCkkgd291bGQgY2hhbmdlIHRvICJhcmUgYm91bmQgdG8gYSBzcGVj aWZpYyIuIElmIHRoZSBhcHBsaWNhdGlvbiBkb2VzIG5vdCBzcGVjaWZ5IGFueXRoaW5nLCB0aGUg a2V5cyBhcmUgYm91bmQgdG8gU0hBLTI1Ni4NCg0KQ2hlZXJzLA0KSm9obg0KDQrvu78tLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQ2hyaXN0b3BoZXIgV29vZCA8Y2F3QGhlYXBpbmdi aXRzLm5ldD4NCkRhdGU6IFdlZG5lc2RheSwgMyBBcHJpbCAyMDE5IGF0IDE2OjI1DQpUbzogSm9o biBNYXR0c3NvbiA8am9obi5tYXR0c3NvbkBlcmljc3Nvbi5jb20+DQpDYzogIlRMU0BpZXRmLm9y ZyIgPFRMU0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbVExTXSBDb21tZW50cyBvbiBkcmFmdC13 b29kLXRscy1leHRlcm5hbC1wc2staW1wb3J0ZXItMDENCg0KICAgIFRoYW5rcyBmb3IgdGhlIGZl ZWRiYWNrLCBKb2huLiBJIGZpbGVkIGlzc3VlcyBvbiB0aGUgR2l0SHViIGRyYWZ0IA0KICAgIGxv Y2F0ZWQgYXQgWzFdLiBQbGVhc2Ugc2VlIGlubGluZSBiZWxvdyBmb3IgY29tbWVudHMuDQogICAg DQogICAgT24gMSBBcHIgMjAxOSwgYXQgMTI6MDAsIEpvaG4gTWF0dHNzb24gd3JvdGU6DQogICAg DQogICAgPiAgSGksDQogICAgPg0KICAgID4gVGhhbmtzIGZvciB0cnlpbmcgdG8gc29sdmUgdGhp cyBwcm9ibGVtISBOb3QgaGF2aW5nIGEgd2F5IHRvIHVzZSB0aGUgDQogICAgPiBzYW1lIGV4dGVy bmFsIFBTSyBmb3IgZGlmZmVyZW50IGNpcGhlciBzdWl0ZXMgaXMgZGVmaW5pdGVseSBhIHRoaW5n IA0KICAgID4gbWlzc2luZyBmcm9tIFRMUyAxLjMuDQogICAgPg0KICAgID4gQXMgSSBzdGF0ZWQg ZHVyaW5nIHRoZSB3ZyBzZXNzaW9uLCAzR1BQIGhhdmUgYSBmZXcgdXNlIGNhc2VzIHRoYXQgdXNl IA0KICAgID4gUFNLLUVDREhFIGJldHdlZW4gcGhvbmUgYW5kIGNvcmUgbmV0d29yay4gQ29udHJh cnkgdG8gd2hhdCBJRVRGIHBlb3BsZSANCiAgICA+IHNvbWV0aW1lcyBiZWxpZXZlLCBtb3N0IDNH UFAgdXNlIG9mIFRMUyAoYmV0d2VlbiBwaG9uZSBhbmQgY29yZSANCiAgICA+IG5ldHdvcmssIGJl dHdlZW4gY29yZSBub2RlcywgYW5kIGJldHdlZW4gZGlmZmVyZW50IG9wZXJhdG9ycykgdXNlIA0K ICAgID4gbXV0dWFsIGF1dGhlbnRpY2F0aW9uIHdpdGggY2VydGlmaWNhdGVzLg0KICAgID4NCiAg ICA+IEFjY29yZGluZyB0byB0aGUgY3VycmVudCAzR1BQIHNwZWNpZmljYXRpb24sIHRoZSBwaG9u ZSBhbmQgdGhlIGNvcmUgDQogICAgPiBuZXR3b3JrIHdvdWxkIHNoYXJlIGFuIGV4dGVybmFsIFBT SyBhbmQgYW4gZXh0ZXJuYWwgaWRlbnRpdHkuIFRoZSBoYXNoIA0KICAgID4gZnVuY3Rpb24gaXMg dW5kZWZpbmVkLCBpLmUuIFNIQS0yNTYgaXMgdXNlZCBmb3IgVExTIDEuMy4gVGhlIHBob25lIGFu ZCANCiAgICA+IHRoZSBuZXR3b3JrIHdvdWxkIHRoZW4gbmVnb3RpYXRlIFRMUyAxLjIgd2l0aCBh bnkgY2lwaGVyIHN1aXRlIG9yIFRMUyANCiAgICA+IDEuMyB3aXRoIFNIQS0yNTYuDQogICAgPg0K ICAgID4gU29tZSBjb21tZW50cw0KICAgID4NCiAgICA+IC0gVGhlIGRyYWZ0IHNob3VsZCBtYWtl IGNsZWFyIGlmIHRoZSBFeHRlcm5hbCBQU0sgYW5kIGV4dGVybmFsIA0KICAgID4gaWRlbnRpdHkg Y2FuIGJlIHVzZWQgdG9nZXRoZXIgd2l0aCB0aGUgaW1wb3J0ZWQgaWRlbnRpdGllcy4gSSBhc3N1 bWUgDQogICAgPiB0aGUgaWRlYSBpcyB0aGF0IHRoZXkgY2Fu4oCZdCBidXQgSSBjYW7igJl0IHNl ZSBhbnkgdGV4dCBzcGVjaWZ5aW5nIA0KICAgID4gdGhpcy4NCiAgICANCiAgICBJbmRlZWQsIHRo YXQgd2FzIHRoZSBpbnRlbnQuDQogICAgDQogICAgPg0KICAgID4gLSDigJ1JbXBvcnRlZCBrZXlz IGRvIG5vdCByZXF1aXJlIG5lZ290aWF0aW9uIGZvciB1c2UsIGFzIGEgY2xpZW50IGFuZA0KICAg ID4gc2VydmVyIHdpbGwgbm90IGFncmVlIHVwb24gaWRlbnRpdGllcyBpZiBub3QgaW1wb3J0ZWQg Y29ycmVjdGx5Lg0KICAgID4gVGh1cywgaW1wb3J0ZXJzIGluZHVjZSBubyBwcm90b2NvbCBjaGFu Z2VzIHdpdGggdGhlIGV4Y2VwdGlvbiBvZg0KICAgID4gZXhwYW5kaW5nIHRoZSBzZXQgb2YgUFNL IGlkZW50aXRpZXMgc2VudCBvbiB0aGUgd2lyZS7igJ0NCiAgICA+DQogICAgPiBXaGlsZSBJIHNl ZSBob3cgdGhlIGRlZmluZWQgbWVjaGFuaXNtIGNhbiBiZSBkZXBsb3llZCBpbiBhIG5ldyANCiAg ICA+IGRlcGxveW1lbnQsIEkgZG8gbm90IHNlZSBob3cgdG8gaW50cm9kdWNlIGl0IGluIGFuIGV4 aXN0aW5nIA0KICAgID4gZGVwbG95bWVudC4gQXNzdW1pbmcgdGhhdCB0aGUgZXh0ZXJuYWwgUFNL IGNhbm5vdCBiZSB1c2VkIHRvZ2V0aGVyIA0KICAgID4gd2l0aCB0aGUgaW1wb3J0ZWQgaWRlbnRp dGllcywgdGhlIFRMUyBjbGllbnQgYW5kIHNlcnZlciBtdXN0IGludHJvZHVjZSANCiAgICA+IHRo ZSBtZWNoYW5pc20gYXQgdGhlIHNhbWUgdGltZSwgdGhhdCBpcyBvZnRlbiBub3QgcG9zc2libGUg dG8gY29udHJvbC4NCiAgICANCiAgICBZb3XigJlyZSBjb3JyZWN0IHRoYXQgdGhpcyByZXF1aXJl cyBib3RoIGVuZHBvaW50cyB0byBhZG9wdCB0aGUgY2hhbmdlIA0KICAgIHNpbXVsdGFuZW91c2x5 LiBIb3dldmVyLCB0aGF0IGRvZXMgbm90IGNvbnRyYWRpY3QgdGhlIHF1b3RlZCB0ZXh0LCB3aGlj aCANCiAgICBzdGF0ZXMgdGhhdCB0aGUgcHJvdG9jb2wgaXMgbm90IGNoYW5nZWQuDQogICAgDQog ICAgPg0KICAgID4gLSDigJxzdHJ1Y3Qgew0KICAgID4gICAgICAgIG9wYXF1ZSBleHRlcm5hbF9p ZGVudGl0eTwxLi4uMl4xNi0xPjsNCiAgICA+ICAgICAgICBvcGFxdWUgbGFiZWw8MC4uMl44LTE+ Ow0KICAgID4gICAgICAgIEhhc2hBbGdvcml0aG0gaGFzaDsNCiAgICA+ICAgIH0gSW1wb3J0ZWRJ ZGVudGl0eTsNCiAgICA+ICAg4oCdDQogICAgPg0KICAgID4gVGhpcyBzY2FsZXMgcG9vcmx5LCBB IGNsaWVudCBoYXMgdG8gc2VuZCBuKm0gaWRlbnRpdGllcyB3aGVyZSBuIGlzIHRoZSANCiAgICA+ IG51bWJlciBvZiBzdXBwb3J0ZWQgdmVyc2lvbnMgYW5kIG0gaXMgdGhlIG51bWJlciBvZiBzdXBw b3J0ZWQgaGFzaCANCiAgICA+IGFsZ29yaXRobXMuLi4NCiAgICANCiAgICBZZXMsIHRoaXMgaXMg YSB0cmFkZW9mZiB3ZSBtYWRlIGJ5IG9wdGluZyB0byBub3QgbW9kaWZ5IHRoZSBrZXkgDQogICAg c2NoZWR1bGUuDQogICAgDQogICAgPg0KICAgID4gLSBXb3VsZCBpdCBub3QgYmUgcG9zc2libGUg dG8ganVzdCB1c2UgdGhlIHZlcnNpb24gbnVtYmVyIGFzIGxhYmVsPyANCiAgICA+IEkuZS4gMHgw MzA0IGluc3RlYWQgb2Yg4oCcdGxzMTPigJ0uIEluIHRoYXQgd2F5IHlvdSBkbyBhdCBsZWFzdCBu b3QgDQogICAgPiBoYXZlIHRvIGRlZmluZSBhIG5ldyBsYWJlbHMuDQogICAgDQogICAgV2UgcHJv YmFibHkgY291bGQsIHRob3VnaCBzaW5jZSB0aGUgbGFiZWxzIGFyZSBzdWJqZWN0IHRvIGNoYW5n ZSAoc2VlIA0KICAgIHRoZSBUT0RPIGFib3V0IHBvc3NpYmx5IGluY2x1ZGluZyB0aGUgSGFzaEFs Z29yaXRobSBpbiB0aGUgbGFiZWwpLCB3ZSANCiAgICBrZXB0IGl0IGFzIGlzLg0KICAgIA0KICAg ID4NCiAgICA+IC0g4oCcVExTIDEuMyBbUkZDODQ0Nl0gc3VwcG9ydHMgcHJlLXNoYXJlZCBrZXkg KFBTSykgcmVzdW1wdGlvbiwgDQogICAgPiB3aGVyZWluDQogICAgPiBQU0tzIGNhbiBiZSBlc3Rh Ymxpc2hlZCB2aWEgc2Vzc2lvbiB0aWNrZXRzIGZyb20gcHJpb3IgY29ubmVjdGlvbnMgb3INCiAg ICA+IGV4dGVybmFsbHkgdmlhIHNvbWUgb3V0LW9mLWJhbmQgbWVjaGFuaXNtLuKAnQ0KICAgID4N CiAgICA+IFRoaXMgc2VlbXMgdG8gaW5kaWNhdGUgdGhhdCBhbGwgdXNlIG9mIFBTSyBpcyByZXN1 bXB0aW9uIHdoaWNoIGlzIG5vdCANCiAgICA+IGNvcnJlY3QuIEkgc3VnZ2VzdCBjaGFuZ2luZyB0 byDigJxUTFMgMS4zIFtSRkM4NDQ2XSBzdXBwb3J0cyANCiAgICA+IHByZS1zaGFyZWQga2V5IChQ U0spIGF1dGhlbnRpY2F0aW9u4oCdDQogICAgDQogICAgR29vZCBzdWdnZXN0aW9uISBXZeKAmWxs IGZpeCBpdC4NCiAgICANCiAgICA+DQogICAgPiAtIOKAnGltcG9ydGluZyBleHRlcm5hbCBQU0sg KFByZS1TaGFyZWQgS2V5KSBpbnRvIFRMUy7igJ0NCiAgICA+DQogICAgPiBOb3Qgc3VyZSBpZiDi gJxpbnRv4oCdIGlzIHRoZSByaWdodCB3b3JkLCBJIHRoaW5rIOKAnGZvcuKAnSBhcyBpbiB0aCBl IA0KICAgID4gdGl0bGUgaXMgYmV0dGVyLiBUaGUgbWVjaGFuaXNtIHNlZW1zIHZlcnkgbXVjaCBl eHRlcm5hbCB0byBUTFMgaXRzZWxmLiANCiAgICA+IEkgc2VlIGl0IGFzIGEgbWVjaGFuaXNtIHRv IGRlcml2ZSBzZXZlcmFsIGV4dGVybmFsIFBTS3MgZnJvbSBhIHNpbmdsZSANCiAgICA+IGV4dGVy bmFsIFBTSy4NCiAgICANCiAgICBEaXR0by4NCiAgICANCiAgICA+DQogICAgPiAtIOKAnFNpbWls YXJseSwgVExTIDEuMiBhbmQgYWxsIHByaW9yIFRMUyB2ZXJzaW9ucyBzaG91bGQgdXNlICJ0bHMx MiIgDQogICAgPiDigJwNCiAgICA+DQogICAgPiBUaGUgdmVyc2lvbnMgcHJpb3IgdG8gVExTIDEu MiB3aWxsIHNvb24gYmUgZGVwcmVjYXRlZC4gQW5kIHdoeSBzcGVuZCANCiAgICA+IHRpbWUgdXBk YXRpbmcgdGhlIFRMUyAxLjIgY29kZSBiYXNlIGluc3RlYWQgb2YgbW92aW5nIHRvIFRMUyAxLjM/ DQogICAgDQogICAgV2XigJlyZSBqdXN0IGNvdmVyaW5nIG91ciBiYXNlcyBoZXJlLiBJIHRlbmQg dG8gYWdyZWUgdGhhdCB0aGUgZm9jdXMgDQogICAgc2hvdWxkIGJlIG9uIHVwZGF0aW5nIHRvIFRM UyAxLjMgaW5zdGVhZCBvZiDigJxwYXRjaGluZ+KAnSBUTFMgMS4yIA0KICAgIHN0YWNrcy4NCiAg ICANCiAgICA+DQogICAgPg0KICAgID4gU3VnZ2VzdGlvbjoNCiAgICA+DQogICAgPiBJbnN0ZWFk IG9mIGRlcml2aW5nIGEgbGFyZ2Ugc2V0IG9mIG5ldyBleHRlcm5hbCBQU0tzLCB3b3VsZG7igJl0 IGl0IGJlIA0KICAgID4gcG9zc2libGUgdG8ganVzdCB1c2UgZGlmZmVyZW50IGhhc2ggZnVuY3Rp b25zIGluIGRpZmZlcmVudCBwYXJ0cyBvZiANCiAgICA+IHRoZSBrZXkgaGllcmFyY2h5PyBJLmUu IGlmIFNIQS0yNTYgaXMgYXNzb2NpYXRlZCB3aXRoIHRoZSBleHRlcm5hbCBQU0sgDQogICAgPiBh bmQgU0hBLTM4NCBpcyB0aGUgaGFzaCBhbGdvcml0aG1zIGluIHRoZSBjaG9zZW4gY2lwaGVyIHN1 aXRlOg0KICAgID4NCiAgICA+IFBTSyAtPiAgSEtERi1FeHRyYWN0KFNIQS0yNTYpID0gRWFybHkg U2VjcmV0DQogICAgPiAgICAgICAgICAgfA0KICAgID4gICAgICAgICAgICstLS0tLT4gRGVyaXZl LVNlY3JldCguLCAiZXh0IGJpbmRlciIgfCAicmVzIGJpbmRlciIsICIiKQ0KICAgID4gICAgICAg ICAgIHwgICAgICAgICAgICAgICAgICAgICA9IGJpbmRlcl9rZXkNCiAgICA+ICAgICAgICAgICB8 DQogICAgPiAgICAgICAgICAgKy0tLS0tPiBEZXJpdmUtU2VjcmV0KC4sICJjIGUgdHJhZmZpYyIs IENsaWVudEhlbGxvKQ0KICAgID4gICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICA9IGNs aWVudF9lYXJseV90cmFmZmljX3NlY3JldA0KICAgID4gICAgICAgICAgIHwNCiAgICA+ICAgICAg ICAgICArLS0tLS0+IERlcml2ZS1TZWNyZXQoLiwgImUgZXhwIG1hc3RlciIsIENsaWVudEhlbGxv KQ0KICAgID4gICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICA9IGVhcmx5X2V4cG9ydGVy X21hc3Rlcl9zZWNyZXQNCiAgICA+ICAgICAgICAgICB2DQogICAgPiAgICAgRGVyaXZlLVNlY3Jl dCguLCAiZGVyaXZlZCIsICIiKQ0KICAgID4gICAgICAgICAgIHwNCiAgICA+ICAgICAgICAgICB2 DQogICAgPiAoRUMpREhFIC0+IEhLREYtRXh0cmFjdChTSEEtMzg0KSA9IEhhbmRzaGFrZSBTZWNy ZXQNCiAgICA+DQogICAgPiBTdXBwb3J0IG9mIHRoaXMgY291bGQgYmUgc2lnbmFsbGVkIHdpdGgg dGhlIHRsc19mbGFncyBleHRlbnNpb24uIElmIA0KICAgID4gdGhlIHNlcnZlciBkb2VzIG5vdCBz dXBwb3J0IHRoZSBleHRlbnNpb24gaXQgbXVzdCBhY2NvcmRpbmcgdG8gUkZDIA0KICAgID4gODQ0 NiBjaG9zZSBhIGNpcGhlciBzdWl0ZSB3aXRoIFNIQS0yNTYuDQogICAgDQogICAgTW9kaWZ5aW5n IHRoZSBrZXkgc2NoZWR1bGUgd2FzIGRpc2N1c3NlZCBpbiB0aGUgY29udGV4dCBvZiBbMl0uIEF0 IHRoZSANCiAgICB0aW1lLCBpdCBzZWVtZWQgdGhlIGRlc2lyZSB0byBub3QgdG91Y2ggdGhlIGtl eSBzY2hlZHVsZSBvdXR3ZWlnaGVkIHRoZSANCiAgICBkZXNpcmUgdG8gbm90IGluZmxhdGUgdGhl IENsaWVudEhlbGxvLg0KICAgIA0KICAgIEJlc3QsDQogICAgQ2hyaXMNCiAgICANCiAgICBbMV0g aHR0cHM6Ly9naXRodWIuY29tL2NocmlzLXdvb2QvZHJhZnQtd29vZC10bHMtZXh0ZXJuYWwtcHNr LWltcG9ydGVyDQogICAgWzJdIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1kYXZp ZGJlbi10bHMtdW5pdmVyc2FsLXBzay0wMA0KICAgIA0KDQo= From nobody Thu Apr 4 02:32: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 9716D12047B for ; Thu, 4 Apr 2019 02:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 g7diWZsNsqQd for ; Thu, 4 Apr 2019 02:32:32 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10082.outbound.protection.outlook.com [40.107.1.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3175120479 for ; Thu, 4 Apr 2019 02:32:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XE9ouXo5D+lA1IX0GnJudijksetrqpvOsVgDzw921Xo=; b=USlq2jFw6RVyLnwD1AFWQiZwWNzzowb2djNeNw765FkilN0dmY5EkbREcsv2nXHCmUTkj3OX6s5MlgVHwiD2+jhSfKJA/O6kAXMOPoqJ7cJjrZlsWs+GSAwb377ovUmh4kMBf2mUWgJy5Yhk66eQ5nUkZ8BKg1vkJYmqSqmHp88= Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.166.22) by HE1PR07MB4394.eurprd07.prod.outlook.com (20.176.167.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.6; Thu, 4 Apr 2019 09:32:28 +0000 Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::91bd:a367:2414:b4bc]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::91bd:a367:2414:b4bc%5]) with mapi id 15.20.1771.007; Thu, 4 Apr 2019 09:32:28 +0000 From: John Mattsson To: "TLS@ietf.org" Thread-Topic: [TLS] Fwd: New Version Notification for draft-ietf-tls-subcerts-03.txt Thread-Index: AQHU6slRzH8y+q8uF0qL4CX3/sObuQ== Date: Thu, 4 Apr 2019 09:32:28 +0000 Message-ID: <3E47BF4C-48DA-4FEB-8845-A449EABA274D@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.17.1.190326 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [82.214.46.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b1dab7c3-8e2d-4016-5941-08d6b8e07491 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR07MB4394; x-ms-traffictypediagnostic: HE1PR07MB4394: x-microsoft-antispam-prvs: x-forefront-prvs: 0997523C40 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(136003)(366004)(39860400002)(346002)(189003)(199004)(8936002)(33656002)(14444005)(256004)(5660300002)(106356001)(26005)(97736004)(99286004)(6486002)(81156014)(81166006)(68736007)(6436002)(476003)(2616005)(71200400001)(486006)(2906002)(71190400001)(66066001)(36756003)(478600001)(83716004)(7736002)(53936002)(25786009)(102836004)(305945005)(82746002)(58126008)(229853002)(8676002)(44832011)(15650500001)(5640700003)(86362001)(105586002)(6246003)(6916009)(2351001)(3846002)(6116002)(2501003)(316002)(6506007)(14454004)(6512007)(186003); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4394; H:HE1PR07MB4169.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: YMT30yclgg9WyDxkMn1i9BMjH+bRYv7h9e4QDxl/poztHcaw1EWgGYd7O/i+o1GmqG9wfr9nrrky2OqIBCYQXZY3P9s2uTRgZMNmR5ftrY/YPctOZAUCMzkuT32C+Xc/HtOs4+Od+tsgWYZO88wHsGo+hH/wR1MhAMMVtBBTtgywh7LKWrHGVhz8QzGT25c6xM5qzjPq3LFuJEbGAC39q98KNWdhUEAtDH+ABQnDUtxoHxNz0k55kAxlqIA7jUissG9QvZ0F4UCWISfJrwox7awasSpq7bmGwWufu7XenrUWGsHsv06con4bfTuXWpqv1eo9CHayw8GC4z29QoUJxq4kGc3SrNDOOkAanYzIV9DDbzywwy8CZ2DyyGI/UYRHbrwkj5glLaLnLf/l57yqzwBpxoIp0FTPpg1gnlc7pi4= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: b1dab7c3-8e2d-4016-5941-08d6b8e07491 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2019 09:32:28.5660 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4394 Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-ietf-tls-subcerts-03.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: Thu, 04 Apr 2019 09:32:34 -0000 SGksDQoNClRoaXMgZHJhZnQgaXMgdmVyeSB3ZWxsIHdyaXR0ZW4sIEkgbWFpbmx5IGhhdmUgaGln aCBsZXZlbCBjb21tZW50czoNCg0KLSBJIHRoaW5rIHRoZXJlIGlzIGFuIG92ZXJsYXAgYmV0d2Vl biBkcmFmdC1pZXRmLXRscy1zdWJjZXJ0cyBhbmQgZHJhZnQtdHNjaG9mZW5pZy10bHMtY3d0LCB3 aGljaCBhbHNvIHByb3Bvc2UgYSBmb3JtIG9mIGRlbGVnYXRlZCBjcmVkZW50aWFscy4gQ1dUIGlz IGFuIGV4aXN0aW5nIGZvcm1hdCwgdGhhdCBkcmFmdCBzdXBwb3J0cyBkZWxlZ2F0aW9uIG9uIGJv dGggdGhlIGNsaWVudCBhbmQgc2VydmVyIHNpZGUsIGFuZCBkb2VzIG5vdCByZXF1aXJlIHRoZSBj ZXJ0aWZpY2F0ZSB0byBiZSBzZW50LiBPbiB0aGUgb3RoZXIgaGFuZCB0aGUgQ1dUIGRyYWZ0IGxh Y2tzIGEgbG90IG9mIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBvZiB0aGUgREMgZHJhZnQu IENvdWxkIHRoZXNlIGlkZWFzIGJlIGNvbWJpbmVkPyBIYXZpbmcgdHdvIGRlbGVnYXRlZCBjcmVk ZW50aWFsIGZvcm1hdHMgaW4gVExTIGRvZXMgbm90IHNlZW0gb3B0aW1hbCB1bmxlc3MgdGhlIGJl bGllZiBpcyB0aGF0IHRoZXkgc2VydmUgdmVyeSBkaWZmZXJlbnQgdXNlIGNhc2VzLg0KDQotIE9u bHkgc3VwcG9ydGluZyBkZWxlZ2F0ZWQgY3JlZGVudGlhbHMgZm9yIHRoZSBzZXJ2ZXIgc2VlbXMg dmVyeSBsaW1pdGluZy4gV2hhdCBpZiBJIGhhdmUgYSB2aXJ0dWFsaXplZCBUTFMgY2xpZW50IHRh bGtpbmcgdG8gYSB2aXJ0dWFsaXplZCBUTFMgc2VydmVyPyBJIHNlZSB0aGF0IHRoaXMgd2FzIHJl Y2VudGx5IGFkZGVkIGFzIGlzc3VlICMyNCwgSSBzdXBwb3J0IHNvbHZpbmcgaXNzdWUgIzI0Lg0K DQotIEFic3RyYWN0OiAid2l0aG91dCBicmVha2luZyBjb21wYXRpYmlsaXR5IHdpdGggY2xpZW50 cyB0aGF0IGRvIG5vdCBzdXBwb3J0IHRoaXMgc3BlY2lmaWNhdGlvbi4iDQoNCkkgZG8gbm90IHNl ZSBob3cuLi4gVGhlIGRlcGxveW1lbnQgc2NlbmFyaW8gaXMgdGhhdCB0aGUgQ0ROIG9yIHJlbW90 ZSBkYXRhIGNlbnRlciBoYXMgdGhlIERDIHByaXZhdGUga2V5LCBidXQgbm90IHRoZSBjZXJ0aWZp Y2F0ZSBwcml2YXRlIGtleSAoYXMgaXQgaXMgbm90IHRydXN0ZWQgZW5vdWdoKS4gTFVSSy9LZXls ZXNzIFNTTCBjbGVhcmx5IGJlbmVmaXRzIGZyb20gREMsIGJ1dCB3aGlsZSBMVVJLL0tleWxlc3Mg U1NMIGNhbiBiZSB1c2VkIHdpdGhvdXQgREMsIHVzZSBvZiBEQyB3aXRoIGFueSBjbGllbnRzIG5v dCBzdXBwb3J0aW5nIERDIG1vcmUgb3IgbGVzcyByZXF1aXJlcyBMVVJLL0tleWxlc3MgU1NMLiBO b3QgZ2l2aW5nIGd1aWRhbmNlIG9uIGhvdyB0byBkbyB0aGUgaW50ZXJmYWNlIGJldHdlZW4gRnJv bnQtZW5kIGFuZCBCYWNrLWVuZCBzZWVtcyBsaWtlIGEgYmFkIGlkZWEuIA0KDQpJIHRoaW5rIHRo ZSB0ZXh0IGFib3V0IGNvbXBhdGliaWxpdHkgbmVlZCB0byBiZSBjaGFuZ2VkLiBJIHRoaW5rIGl0 IG5lZWRzIHRvIGJlIGNsZWFyIHRoYXQgdW50aWwgMTAwICUgb2YgY2xpZW50cyBzdXBwb3J0IERD LCBMVVJLL0tleWxlc3MgU1NMIGlzIGEgcmVxdWlyZW1lbnQuDQoNCi0gU2VjdGlvbiAxIC0gQ291 bGQgYWRkICJUaGUgc2VydmVyIG9wZXJhdG9yIGNhbiBvbmx5IHVzZSB2YWxpZGl0eSBwZXJpb2Rz IHN1cHBvcnRlZCBieSB0aGUgQ0EiIHRvIHRoZSBleGFtcGxlcyBhcyB0aGF0IGlzIG9uZSBvZiB0 aGUgYmVuZWZpdHMgb2YgREMgaGlnaGxpZ2h0ZWQgYmVsb3cuDQoNCi0gU2VjdGlvbiAzLjEgImlm IHRoZSBleHRlbnNpb24gaXMgbm90IHByZXNlbnQsIHRoZSBzZXJ2ZXIgTVVTVCBOT1Qgc2VuZCBh IGRlbGVnYXRlZCBjcmVkZW50aWFsLiINCg0KQXMgb2Z0ZW4gcmVxdWVzdGVkIGJ5IEppbSBTY2hh YWQsIGNvdWxkIHlvdSBmb3JtdWxhdGUgdGhpcyBhcyBhIHBvc2l0aXZlIHNlbnRlbmNlIGluc3Rl YWQuIFdoYXQgc2hvdWxkIHRoZSBzZXJ2ZXIgZG8gaW4gdGhpcyBjYXNlLCB0ZXJtaW5hdGUgdGhl IGNvbm5lY3Rpb24/IFVzZSBMVVJLPyANCg0KU2VjdXJpdHkgY29uc2lkZXJhdGlvbnM6DQoNCi0g IlRMUyBwcml2YXRlIGtleSIgaXMgbm90IGRlZmluZWQgYW5kIGluIGZhY3QgVExTIHVzZXMgbWFu eSBkaWZmZXJlbnQgcHJpdmF0ZSBrZXlzLg0KDQotIEFkZCAiVGhlIGV4dGVuc2lvbiBjcmVhdGVz IGFuIHVuZW5jcnlwdGVkIHNpZ25hbCB0aGF0IG1pZ2h0IGJlIHVzZWQgdG8gaWRlbnRpZnkgd2hp Y2ggY2xpZW50cyBzdXBwb3J0IGRlbGVnYXRlZCBjcmVkZW50aWFscy4iICh0ZXh0IGJvcnJvd2Vk IGZyb20gdGhlIHNpYyBleHRlbnNpb24pDQoNCkNoZWVycywNCkpvaG4NCg0K From nobody Thu Apr 4 06:00: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 16A111204D4 for ; Thu, 4 Apr 2019 06:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 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_LOW=-0.7, SPF_PASS=-0.001, T_FROM_FMBLA_NEWDOM=0.01, 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=wuHtQ5K2; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=z2wnagmL Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wzj7IGp_KiEV for ; Thu, 4 Apr 2019 06:00:52 -0700 (PDT) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 291071204ED for ; Thu, 4 Apr 2019 06:00:51 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailnew.nyi.internal (Postfix) with ESMTP id 934F0FF57; Thu, 4 Apr 2019 09:00:48 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Thu, 04 Apr 2019 09:00:48 -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 :cc:subject:content-type; s=fm1; bh=+ARHYNV4VO1daGliqqNfw5OnQSg8 bt9/eD/gBG46EF4=; b=wuHtQ5K2E6vSVl1kscKsIgQ6hi0A+MxgKU/o+23BFmNR 3HDO5jebmWSMdG6M0T0xh3eeVjztFA38Ipr6spNmpPhuwWRGdHO7Wxuw5yf4dc+e 4BTz6P78187in/zapsLCsIMqR96nGzeHQHiWKz6loUkQyUIsrrnzFyfcxS8CXGTq 2/DOWyctGVW6dMYfQlKy+zGmbFJvwboqMGg131/qbJE9+mV77W7kMfP1zSWEM12V nda6mZKSaV4tgswow5rC62XYM7UwXTsFj28gR3OHm+iStDUwTOcWaOIlrk1x+iuv q6BJ7WAh3zzkTafU6/QvlahHoeTRUHWs88wmpCDR2g== 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=fm2; bh=+ARHYN V4VO1daGliqqNfw5OnQSg8bt9/eD/gBG46EF4=; b=z2wnagmLvjhryuejyc2+0s izZ5i4rsQ31tkypjvPRz2to70J3TPg+DaXtikfZXq0Om2RxXf0QYqvzIxXQrCesZ pq/Wgmo9zLhXe5plCwz70PwQ013y+tm6uxRIy3ZtGF9JxgTtvmHbPAUYf+7EEOwV a6qjf9UhbATSnUBQ0uXWsYKGfypZymj+5DBW2ixB1LpwrWGf+df91uIcmBPmtWMp MVDJXTcbRmpA8jmzVW/yyNEX1bJ4KVHnfwCgTaHiim1h/YkuwFhaBZRQdbbNCbF6 7ycW/Thga8734SmGHypuM9d0mu4zd2+VUO3dCKTINn7xFUWdL/9EOAL4I5eHTO4A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrtdehgdehkeculddtuddrgedutddrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg hnthhsucdlqddutddtmdenucfjughrpefofgggkfgjfhffhffvufgtsegrtderreerreej necuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgifsehhvggrph hinhhgsghithhsrdhnvghtqeenucfrrghrrghmpehmrghilhhfrhhomheptggrfieshhgv rghpihhnghgsihhtshdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2A3062602F; Thu, 4 Apr 2019 09:00:46 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-329-gf4aae99-fmstable-20190329v1 Mime-Version: 1.0 X-Me-Personality: 94902928 Message-Id: In-Reply-To: References: <89127FF7-CE3F-4DF1-98A5-B1006C5FF56B@ericsson.com> Date: Thu, 04 Apr 2019 09:00:45 -0400 From: "Christopher Wood" To: "John Mattsson" Cc: "TLS@ietf.org" Content-Type: multipart/alternative; boundary=843e2817e4cb4bdd8c3654245d697589 Archived-At: Subject: Re: [TLS] Comments on draft-wood-tls-external-psk-importer-01 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, 04 Apr 2019 13:00:56 -0000 --843e2817e4cb4bdd8c3654245d697589 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed, Apr 3, 2019, at 11:22 PM, John Mattsson wrote: > Hi Christopher, >=20 > Thanks for the clarifications. >=20 > >You=E2=80=99re correct that this requires both endpoints to adopt the= change=20 > >simultaneously. However, that does not contradict the quoted text, wh= ich=20 > >states that the protocol is not changed. >=20 > I think "this requires both endpoints to adopt the change simultaneous= ly" is a problem as it makes it impossible to introduce this mechanism i= n many existing deployments. I would expect a solution that can be intro= duced gradually (some nodes at a time) in existing deployments supportin= g RFC 8446 and/or RFC 5246. I think perhaps my response was unclear. In your scenario, adding key im= port support is essentially the same as adding a new PSK to a node. Some= nodes may offer (or accept) the PSK, while others do not. Successful us= e of an imported PSK will only occur if both endpoints have imported the= same PSK. Gradual deployment is possible. >=20 > But, if you want to change the behaviour of the using the same externa= l PSK in both TLS 1.2 and TLS 1.3 as allowed by RFC 8446, a solution not= requiring "simultaneous change" is probably not possible. >=20 > The requirement that "this requires both endpoints to adopt the change= simultaneously" should probably be highlighted in the document. >=20 > The current mechanism does not seem to be deployable for e.g. 3GPP unt= il TLS 1.4 is introduced, and then only for TLS 1.4 and later... on the = other hand, being limited to SHA-256 for PSK may be ok for 3GPP. (and 3G= PP could just derive a Separate SHA-384 PSK if needed). >=20 > Some more comment: >=20 > - Which label should be used by various versions of DTLS? Likely the same labels as the TLS counterparts, since the label more or = less specifies the *handshake* variant. >=20 > - "If a client or server wish to deprecate a hash function and no long= er > use it for TLS 1.3, they may remove this hash function from the set > of hashes used during while importing keys. This does not affect the > KDF operation used to derive concrete PSKs." >=20 > If someone deprecates the use of a hash function inside TLS 1.3 (used = by Transcript-Hash and HKDF), does it then makes sense to keep deriving = keys outside of TLS with that same deprecated hash function? No. If this deprecation occurs, then they would follow the advisory text= and not use the old hash when importing keys. >=20 > - "To mitigate these problems, external PSKs can be bound to a specifi= c hash function when used in TLS 1.3" >=20 > I would change to "are bound to a specific". If the application does n= ot specify anything, the keys are bound to SHA-256. Works for me. I=E2=80=99ll file an issue to track the change. Thanks, Chris=20 >=20 > Cheers, > John >=20 > -----Original Message----- > From: Christopher Wood > Date: Wednesday, 3 April 2019 at 16:25 > To: John Mattsson > Cc: "TLS@ietf.org" > Subject: Re: [TLS] Comments on draft-wood-tls-external-psk-importer-01= >=20 > Thanks for the feedback, John. I filed issues on the GitHub draft=20 > located at [1]. Please see inline below for comments. >=20 > On 1 Apr 2019, at 12:00, John Mattsson wrote: >=20 > > Hi, > > > > Thanks for trying to solve this problem! Not having a way to use th= e=20 > > same external PSK for different cipher suites is definitely a thing= =20 > > missing from TLS 1.3. > > > > As I stated during the wg session, 3GPP have a few use cases that u= se=20 > > PSK-ECDHE between phone and core network. Contrary to what IETF peo= ple=20 > > sometimes believe, most 3GPP use of TLS (between phone and core=20 > > network, between core nodes, and between different operators) use=20= > > mutual authentication with certificates. > > > > According to the current 3GPP specification, the phone and the core= =20 > > network would share an external PSK and an external identity. The h= ash=20 > > function is undefined, i.e. SHA-256 is used for TLS 1.3. The phone = and=20 > > the network would then negotiate TLS 1.2 with any cipher suite or T= LS=20 > > 1.3 with SHA-256. > > > > Some comments > > > > - The draft should make clear if the External PSK and external=20 > > identity can be used together with the imported identities. I assum= e=20 > > the idea is that they can=E2=80=99t but I can=E2=80=99t see any tex= t specifying=20 > > this. >=20 > Indeed, that was the intent. >=20 > > > > - =E2=80=9DImported keys do not require negotiation for use, as a c= lient and > > server will not agree upon identities if not imported correctly. > > Thus, importers induce no protocol changes with the exception of > > expanding the set of PSK identities sent on the wire.=E2=80=9D > > > > While I see how the defined mechanism can be deployed in a new=20 > > deployment, I do not see how to introduce it in an existing=20 > > deployment. Assuming that the external PSK cannot be used together=20= > > with the imported identities, the TLS client and server must introd= uce=20 > > the mechanism at the same time, that is often not possible to contr= ol. >=20 > You=E2=80=99re correct that this requires both endpoints to adopt the= change=20 > simultaneously. However, that does not contradict the quoted text, wh= ich=20 > states that the protocol is not changed. >=20 > > > > - =E2=80=9Cstruct { > > opaque external_identity<1...2^16-1>; > > opaque label<0..2^8-1>; > > HashAlgorithm hash; > > } ImportedIdentity; > > =E2=80=9D > > > > This scales poorly, A client has to send n*m identities where n is = the=20 > > number of supported versions and m is the number of supported hash=20= > > algorithms... >=20 > Yes, this is a tradeoff we made by opting to not modify the key=20 > schedule. >=20 > > > > - Would it not be possible to just use the version number as label?= =20 > > I.e. 0x0304 instead of =E2=80=9Ctls13=E2=80=9D. In that way you do = at least not=20 > > have to define a new labels. >=20 > We probably could, though since the labels are subject to change (see= =20 > the TODO about possibly including the HashAlgorithm in the label), we= =20 > kept it as is. >=20 > > > > - =E2=80=9CTLS 1.3 [RFC8446] supports pre-shared key (PSK) resumpti= on,=20 > > wherein > > PSKs can be established via session tickets from prior connections = or > > externally via some out-of-band mechanism.=E2=80=9D > > > > This seems to indicate that all use of PSK is resumption which is n= ot=20 > > correct. I suggest changing to =E2=80=9CTLS 1.3 [RFC8446] supports=20= > > pre-shared key (PSK) authentication=E2=80=9D >=20 > Good suggestion! We=E2=80=99ll fix it. >=20 > > > > - =E2=80=9Cimporting external PSK (Pre-Shared Key) into TLS.=E2=80=9D= > > > > Not sure if =E2=80=9Cinto=E2=80=9D is the right word, I think =E2=80= =9Cfor=E2=80=9D as in th e=20 > > title is better. The mechanism seems very much external to TLS itse= lf.=20 > > I see it as a mechanism to derive several external PSKs from a sing= le=20 > > external PSK. >=20 > Ditto. >=20 > > > > - =E2=80=9CSimilarly, TLS 1.2 and all prior TLS versions should use= "tls12"=20 > > =E2=80=9C > > > > The versions prior to TLS 1.2 will soon be deprecated. And why spen= d=20 > > time updating the TLS 1.2 code base instead of moving to TLS 1.3? >=20 > We=E2=80=99re just covering our bases here. I tend to agree that the = focus=20 > should be on updating to TLS 1.3 instead of =E2=80=9Cpatching=E2=80=9D= TLS 1.2=20 > stacks. >=20 > > > > > > Suggestion: > > > > Instead of deriving a large set of new external PSKs, wouldn=E2=80=99= t it be=20 > > possible to just use different hash functions in different parts of= =20 > > the key hierarchy? I.e. if SHA-256 is associated with the external = PSK=20 > > and SHA-384 is the hash algorithms in the chosen cipher suite: > > > > PSK -> HKDF-Extract(SHA-256) =3D Early Secret > > | > > +-----> Derive-Secret(., "ext binder" | "res binder", "") > > | =3D binder_key > > | > > +-----> Derive-Secret(., "c e traffic", ClientHello) > > | =3D client_early_traffic_secret > > | > > +-----> Derive-Secret(., "e exp master", ClientHello) > > | =3D early_exporter_master_secret > > v > > Derive-Secret(., "derived", "") > > | > > v > > (EC)DHE -> HKDF-Extract(SHA-384) =3D Handshake Secret > > > > Support of this could be signalled with the tls_flags extension. If= =20 > > the server does not support the extension it must according to RFC=20= > > 8446 chose a cipher suite with SHA-256. >=20 > Modifying the key schedule was discussed in the context of [2]. At th= e=20 > time, it seemed the desire to not touch the key schedule outweighed t= he=20 > desire to not inflate the ClientHello. >=20 > Best, > Chris >=20 > [1] https://github.com/chris-wood/draft-wood-tls-external-psk-importe= r > [2] https://tools.ietf.org/html/draft-davidben-tls-universal-psk-00 >=20 >=20 >=20 --843e2817e4cb4bdd8c3654245d697589 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable

=
On Wed, Apr 3, 2019, at 11:22 PM, John Mattsson wrote:
Hi Christop= her,

Thanks for the clarifications.

>You=E2=80=99re correct that this requires both= endpoints to adopt the change 
>simultaneously. H= owever, that does not contradict the quoted text, which 
<= div>>states that the protocol is not changed.

I think "this requires both endpoints to adopt the change simultan= eously" is a problem as it makes it impossible to introduce this mechani= sm in many existing deployments. I would expect a solution that can be i= ntroduced gradually (some nodes at a time) in existing deployments suppo= rting RFC 8446 and/or RFC 5246.

I think perhaps my response was unclear. In your scenario, adding key = import support is essentially the same as adding a new PSK to a node. So= me nodes may offer (or accept) the PSK, while others do not. Successful = use of an imported PSK will only occur if both endpoints have imported t= he same PSK. Gradual deployment is possible.


But, i= f you want to change the behaviour of the using the same external PSK in= both TLS 1.2 and TLS 1.3 as allowed by RFC 8446, a solution not requiri= ng "simultaneous change" is probably not possible.

The requirement that "this requires both endpoints to adopt the = change simultaneously" should probably be highlighted in the document.

The current mechanism does not seem to be de= ployable for e.g. 3GPP until TLS 1.4 is introduced, and then only for TL= S 1.4 and later...  on the other hand, being limited to SHA-256 for= PSK may be ok for 3GPP. (and 3GPP could just derive a Separate SHA-384 = PSK if needed).

Some more comment:

- Which label should be used by various versions of= DTLS?

Likely the same labels = as the TLS counterparts, since the label more or less specifies the *han= dshake* variant.


- "If a client or server wish to depre= cate a hash function and no longer
use it for TLS 1.3, the= y may remove this hash function from the set
of hashes use= d during while importing keys.  This does not affect the
<= div>KDF operation used to derive concrete PSKs."

If someone deprecates the use of a hash function inside TLS 1.3 (u= sed by Transcript-Hash and HKDF), does it then makes sense to keep deriv= ing keys outside of TLS with that same deprecated hash function?

No. If this deprecation occurs, then = they would follow the advisory text and not use the old hash when import= ing keys.


- "To mitigate these problems, external PSKs = can be bound to a specific hash function when used in TLS 1.3"
=

I would change to "are bound to a specific". If the = application does not specify anything, the keys are bound to SHA-256.

Works for me. I=E2=80=99ll file = an issue to track the change.

Thanks,
Chris 


Cheers,
John

=EF=BB=BF-----Original Message-----
= From: Christopher Wood <caw@heapingbits.net>
Date: W= ednesday, 3 April 2019 at 16:25
To: John Mattsson <john= .mattsson@ericsson.com>
Cc: "TLS@ietf.org" <TLS@ietf= .org>
Subject: Re: [TLS] Comments on draft-wood-tls-ext= ernal-psk-importer-01

    Th= anks for the feedback, John. I filed issues on the GitHub draft 
    located at [1]. Please see inline below f= or comments.
    
 =    On 1 Apr 2019, at 12:00, John Mattsson wrote:
    
    >  Hi= ,
    >
   = > Thanks for trying to solve this problem! Not having a way to use t= he 
    > same external PSK for dif= ferent cipher suites is definitely a thing 
 &nb= sp;  > missing from TLS 1.3.
    &g= t;
    > As I stated during the wg sessi= on, 3GPP have a few use cases that use 
  &= nbsp; > PSK-ECDHE between phone and core network. Contrary to what IE= TF people 
    > sometimes believe,= most 3GPP use of TLS (between phone and core 
 =    > network, between core nodes, and between different ope= rators) use 
    > mutual authentic= ation with certificates.
    >
=
    > According to the current 3GPP specification= , the phone and the core 
    > net= work would share an external PSK and an external identity. The hash = ;
    > function is undefined, i.e. SHA-= 256 is used for TLS 1.3. The phone and 
  &= nbsp; > the network would then negotiate TLS 1.2 with any cipher suit= e or TLS 
    > 1.3 with SHA-256.
    >
    &g= t; Some comments
    >
&nb= sp;   > - The draft should make clear if the External PSK a= nd external 
    > identity can be = used together with the imported identities. I assume 
    > the idea is that they can=E2=80=99t but I can=E2= =80=99t see any text specifying 
    &= gt; this.
    
 &nb= sp;  Indeed, that was the intent.
   &= nbsp;
    >
  &n= bsp; > - =E2=80=9DImported keys do not require negotiation for use, a= s a client and
    > server will not agr= ee upon identities if not imported correctly.
  =   > Thus, importers induce no protocol changes with the exceptio= n of
    > expanding the set of PSK iden= tities sent on the wire.=E2=80=9D
    ><= br>
    > While I see how the defined mechan= ism can be deployed in a new 
    >= deployment, I do not see how to introduce it in an existing 
    > deployment. Assuming that the external = PSK cannot be used together 
    > = with the imported identities, the TLS client and server must introduce&n= bsp;
    > the mechanism at the same tim= e, that is often not possible to control.
  &nbs= p; 
    You=E2=80=99re correct that th= is requires both endpoints to adopt the change 
 = ;   simultaneously. However, that does not contradict the quot= ed text, which 
    states that the pr= otocol is not changed.
    
<= div>    >
    > - =E2=80= =9Cstruct {
    >    = ;    opaque external_identity<1...2^16-1>;
    >        = opaque label<0..2^8-1>;
    > = ;       HashAlgorithm hash;
=     >    } ImportedIdentity;
<= div>    >   =E2=80=9D
 &n= bsp;  >
    > This scales poorly= , A client has to send n*m identities where n is the 
    > number of supported versions and m is the numbe= r of supported hash 
    > algorith= ms...
    
  &= nbsp; Yes, this is a tradeoff we made by opting to not modify the key&nb= sp;
    schedule.
  = ;  
    >
 =    > - Would it not be possible to just use the version num= ber as label? 
    > I.e. 0x0304 in= stead of =E2=80=9Ctls13=E2=80=9D. In that way you do at least not <= br>
    > have to define a new labels.
    
    We pr= obably could, though since the labels are subject to change (see 
    the TODO about possibly including the Ha= shAlgorithm in the label), we 
    kep= t it as is.
    
 &= nbsp;  >
    > - =E2=80=9CTLS 1.= 3 [RFC8446] supports pre-shared key (PSK) resumption, 
    > wherein
    > = PSKs can be established via session tickets from prior connections or
    > externally via some out-of-band mech= anism.=E2=80=9D
    >
&nbs= p;   > This seems to indicate that all use of PSK is resump= tion which is not 
    > correct. I= suggest changing to =E2=80=9CTLS 1.3 [RFC8446] supports 
=
    > pre-shared key (PSK) authentication=E2=80=9D=
    
   = Good suggestion! We=E2=80=99ll fix it.
   =  
    >
  &= nbsp; > - =E2=80=9Cimporting external PSK (Pre-Shared Key) into TLS.=E2= =80=9D
    >
  &= nbsp; > Not sure if =E2=80=9Cinto=E2=80=9D is the right word, I think= =E2=80=9Cfor=E2=80=9D as in th e 
   = > title is better. The mechanism seems very much external to TLS its= elf. 
    > I see it as a mechanism= to derive several external PSKs from a single 
 = ;   > external PSK.
    <= br>
    Ditto.
   =  
    >
  &= nbsp; > - =E2=80=9CSimilarly, TLS 1.2 and all prior TLS versions shou= ld use "tls12" 
    > =E2=80=9C
=
    >
    >= The versions prior to TLS 1.2 will soon be deprecated. And why spend&nb= sp;
    > time updating the TLS 1.2 code= base instead of moving to TLS 1.3?
   &nbs= p;
    We=E2=80=99re just covering our base= s here. I tend to agree that the focus 
  &= nbsp; should be on updating to TLS 1.3 instead of =E2=80=9Cpatching=E2=80= =9D TLS 1.2 
    stacks.
    
    >
    >
    > Sugg= estion:
    >
  =   > Instead of deriving a large set of new external PSKs, wouldn= =E2=80=99t it be 
    > possible to= just use different hash functions in different parts of 
=
    > the key hierarchy? I.e. if SHA-256 is assoc= iated with the external PSK 
    > = and SHA-384 is the hash algorithms in the chosen cipher suite:
=
    >
    > PSK -= >  HKDF-Extract(SHA-256) =3D Early Secret
 &n= bsp;  >         &nb= sp; |
    >     = ;      +-----> Derive-Secret(., "ext binder"= | "res binder", "")
    >  &n= bsp;        |    =             =      =3D binder_key
   = >           |
<= /div>
    >      &nb= sp;    +-----> Derive-Secret(., "c e traffic", ClientH= ello)
    >     = ;      |      &nb= sp;           &nb= sp;  =3D client_early_traffic_secret
  &nbs= p; >           |
    >      &= nbsp;    +-----> Derive-Secret(., "e exp master", Clie= ntHello)
    >    &n= bsp;      |      =             =    =3D early_exporter_master_secret
  =   >           = v
    >     Derive-S= ecret(., "derived", "")
    >  = ;         |
 =    >         &= nbsp; v
    > (EC)DHE -> HKDF-Extract= (SHA-384) =3D Handshake Secret
    >
=
    > Support of this could be signalled wi= th the tls_flags extension. If 
    &g= t; the server does not support the extension it must according to RFC&nb= sp;
    > 8446 chose a cipher suite with= SHA-256.
    
 &nb= sp;  Modifying the key schedule was discussed in the context of [2]= . At the 
    time, it seemed the desi= re to not touch the key schedule outweighed the 
&nbs= p;   desire to not inflate the ClientHello.
&nbs= p;   
    Best,
    Chris
    
    [1] https://github.com/chris-wood/draft-wood-= tls-external-psk-importer
    [2] https://t= ools.ietf.org/html/draft-davidben-tls-universal-psk-00
&nb= sp;   



--843e2817e4cb4bdd8c3654245d697589-- From nobody Thu Apr 4 06:18: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 7EB6A1200FA for ; Thu, 4 Apr 2019 06:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 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_LOW=-0.7, SPF_PASS=-0.001, T_FROM_FMBLA_NEWDOM=0.01, 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=mYykfNu6; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=IqEJnR3N Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZhGT6gQzcu8J for ; Thu, 4 Apr 2019 06:18:46 -0700 (PDT) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61ADC12006E for ; Thu, 4 Apr 2019 06:18:46 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailnew.nyi.internal (Postfix) with ESMTP id A996C51DC for ; Thu, 4 Apr 2019 09:18:45 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Thu, 04 Apr 2019 09:18:45 -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=fm1; bh=DmNISjEbC1e6EZkZVqlKb7CXKCF1zZ0 yWDYky2Ybxv8=; b=mYykfNu6kCYYDLVIE4g4LtPRC7+n/1LkYhLDRcdU0NDcw/q XwnLROgQxrTLeA+BUhydqgjs3jXPU09cNJAZRxmcVpon/8D3xywg73ghGl+Djh3H PHdUSfFu2n6j8nlJ204OFFVDNUwyeYDWIqJr5pDEMxi4YsPfmhMZQh7Elu4ElCLm 6OQDJToSdNpekDJUxRj9JLgdCbXRYPhFIUWtReb1WuMZqEizDhyNhIyqsm2x0dWB RTGcogNdzQvNhFX5nIb+qKioP+poptslKto0/aKBgvAqR93s+v1o9lFSVX2lNRg9 VrwhWsH56m8eH5SBlimkOUnV9m30vwekD5R/VTA== 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=fm2; bh=DmNISj EbC1e6EZkZVqlKb7CXKCF1zZ0yWDYky2Ybxv8=; b=IqEJnR3N3kBkMeXNOSyDdm YZgEHomQxN/fxvDMk5wsKvSnHgRLve8L4SwrPTnXvw1IjjBfbUd1roXsG9NkvCmz SPQdly1f4Gm00dCABb7w1G98C6pfCoxzw30ToCXrBk6pjae4UPUo1rJzDZM2oyni KVkPry20o0SjxiA0+IK0g4KFTOnTAAi/VjIUp/JTik+VITa7wad0t9zCdPgIrQu0 y9wVSD4wkZh8WT4ezi81W51ekcQnZWv08Z1ITzwId/sO/8IJMDk6stXaiemCg17k 6SnYTj0zF62ebHoMmC+ePBIjsdh1RbCLWFJrWLcMoq2zj+0AjI7qbxPUOSQS7L2w == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrtdehgdeivdculddtuddrgedutddrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfgg fkjghffffhvffutgesrgdtreerreerjeenucfhrhhomhepfdevhhhrihhsthhophhhvghr ucghohhougdfuceotggrfieshhgvrghpihhnghgsihhtshdrnhgvtheqnecurfgrrhgrmh epmhgrihhlfhhrohhmpegtrgifsehhvggrphhinhhgsghithhsrdhnvghtnecuvehluhhs thgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 518002602F; Thu, 4 Apr 2019 09:18:42 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-329-gf4aae99-fmstable-20190329v1 Mime-Version: 1.0 X-Me-Personality: 94902928 Message-Id: In-Reply-To: References: <89127FF7-CE3F-4DF1-98A5-B1006C5FF56B@ericsson.com> Date: Thu, 04 Apr 2019 09:18:41 -0400 From: "Christopher Wood" To: "TLS@ietf.org" Content-Type: multipart/alternative; boundary=32c40413e1924ba1a4a50e6e814dbb80 Archived-At: Subject: Re: [TLS] Comments on draft-wood-tls-external-psk-importer-01 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, 04 Apr 2019 13:18:50 -0000 --32c40413e1924ba1a4a50e6e814dbb80 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Thu, Apr 4, 2019, at 6:01 AM, Christopher Wood wrote: >=20 >=20 > On Wed, Apr 3, 2019, at 11:22 PM, John Mattsson wrote: > > Hi Christopher, > >=20 > > Thanks for the clarifications. > >=20 > > >You=E2=80=99re correct that this requires both endpoints to adopt t= he change=20 > > >simultaneously. However, that does not contradict the quoted text, = which=20 > > >states that the protocol is not changed. > >=20 > > I think "this requires both endpoints to adopt the change simultaneo= usly" is a problem as it makes it impossible to introduce this mechanism= in many existing deployments. I would expect a solution that can be int= roduced gradually (some nodes at a time) in existing deployments support= ing RFC 8446 and/or RFC 5246. >=20 > I think perhaps my response was unclear. In your scenario, adding key = import support is essentially the same as adding a new PSK to a node. So= me nodes may offer (or accept) the PSK, while others do not. Successful = use of an imported PSK will only occur if both endpoints have imported t= he same PSK. Gradual deployment is possible. To clarify further since this too may be misleading: This assumes the im= ported PSKs are offered alongside the existing external PSKs. So, to you= r previous question regarding simultaneous use of imported keys and exte= rnal PSKs, gradual deployment is only applicable with stacks supporting = 1.3 and 1.2, where imported keys apply to 1.3. Nodes supporting 1.2 and = 1.3 without the imported keys will offer 1.2 PSKs, whereas nodes with im= ported keys will offer 1.2 and imported 1.3 PSKs. You=E2=80=99re right that it=E2=80=99s not possible to deploy gradually = if one is currently using external PSKs for only 1.3 or 1.2, wants to ad= opt the importer API, and is prohibited from using both imported and ext= ernal PSKs at the same time. >=20 > >=20 > > But, if you want to change the behaviour of the using the same exter= nal PSK in both TLS 1.2 and TLS 1.3 as allowed by RFC 8446, a solution n= ot requiring "simultaneous change" is probably not possible. > >=20 > > The requirement that "this requires both endpoints to adopt the chan= ge simultaneously" should probably be highlighted in the document. > >=20 > > The current mechanism does not seem to be deployable for e.g. 3GPP u= ntil TLS 1.4 is introduced, and then only for TLS 1.4 and later... on th= e other hand, being limited to SHA-256 for PSK may be ok for 3GPP. (and = 3GPP could just derive a Separate SHA-384 PSK if needed). > >=20 > > Some more comment: > >=20 > > - Which label should be used by various versions of DTLS? >=20 > Likely the same labels as the TLS counterparts, since the label more o= r less specifies the *handshake* variant. >=20 > >=20 > > - "If a client or server wish to deprecate a hash function and no lo= nger > > use it for TLS 1.3, they may remove this hash function from the set > > of hashes used during while importing keys. This does not affect the= > > KDF operation used to derive concrete PSKs." > >=20 > > If someone deprecates the use of a hash function inside TLS 1.3 (use= d by Transcript-Hash and HKDF), does it then makes sense to keep derivin= g keys outside of TLS with that same deprecated hash function? >=20 > No. If this deprecation occurs, then they would follow the advisory te= xt and not use the old hash when importing keys. >=20 > >=20 > > - "To mitigate these problems, external PSKs can be bound to a speci= fic hash function when used in TLS 1.3" > >=20 > > I would change to "are bound to a specific". If the application does= not specify anything, the keys are bound to SHA-256. >=20 > Works for me. I=E2=80=99ll file an issue to track the change. >=20 > Thanks, > Chris=20 >=20 > >=20 > > Cheers, > > John > >=20 > > -----Original Message----- > > From: Christopher Wood > > Date: Wednesday, 3 April 2019 at 16:25 > > To: John Mattsson > > Cc: "TLS@ietf.org" > > Subject: Re: [TLS] Comments on draft-wood-tls-external-psk-importer-= 01 > >=20 > > Thanks for the feedback, John. I filed issues on the GitHub draft=20= > > located at [1]. Please see inline below for comments. > >=20 > > On 1 Apr 2019, at 12:00, John Mattsson wrote: > >=20 > > > Hi, > > > > > > Thanks for trying to solve this problem! Not having a way to use t= he=20 > > > same external PSK for different cipher suites is definitely a thin= g=20 > > > missing from TLS 1.3. > > > > > > As I stated during the wg session, 3GPP have a few use cases that = use=20 > > > PSK-ECDHE between phone and core network. Contrary to what IETF pe= ople=20 > > > sometimes believe, most 3GPP use of TLS (between phone and core=20= > > > network, between core nodes, and between different operators) use=20= > > > mutual authentication with certificates. > > > > > > According to the current 3GPP specification, the phone and the cor= e=20 > > > network would share an external PSK and an external identity. The = hash=20 > > > function is undefined, i.e. SHA-256 is used for TLS 1.3. The phone= and=20 > > > the network would then negotiate TLS 1.2 with any cipher suite or = TLS=20 > > > 1.3 with SHA-256. > > > > > > Some comments > > > > > > - The draft should make clear if the External PSK and external=20 > > > identity can be used together with the imported identities. I assu= me=20 > > > the idea is that they can=E2=80=99t but I can=E2=80=99t see any te= xt specifying=20 > > > this. > >=20 > > Indeed, that was the intent. > >=20 > > > > > > - =E2=80=9DImported keys do not require negotiation for use, as a = client and > > > server will not agree upon identities if not imported correctly. > > > Thus, importers induce no protocol changes with the exception of > > > expanding the set of PSK identities sent on the wire.=E2=80=9D > > > > > > While I see how the defined mechanism can be deployed in a new=20 > > > deployment, I do not see how to introduce it in an existing=20 > > > deployment. Assuming that the external PSK cannot be used together= =20 > > > with the imported identities, the TLS client and server must intro= duce=20 > > > the mechanism at the same time, that is often not possible to cont= rol. > >=20 > > You=E2=80=99re correct that this requires both endpoints to adopt th= e change=20 > > simultaneously. However, that does not contradict the quoted text, w= hich=20 > > states that the protocol is not changed. > >=20 > > > > > > - =E2=80=9Cstruct { > > > opaque external_identity<1...2^16-1>; > > > opaque label<0..2^8-1>; > > > HashAlgorithm hash; > > > } ImportedIdentity; > > > =E2=80=9D > > > > > > This scales poorly, A client has to send n*m identities where n is= the=20 > > > number of supported versions and m is the number of supported hash= =20 > > > algorithms... > >=20 > > Yes, this is a tradeoff we made by opting to not modify the key=20 > > schedule. > >=20 > > > > > > - Would it not be possible to just use the version number as label= ?=20 > > > I.e. 0x0304 instead of =E2=80=9Ctls13=E2=80=9D. In that way you do= at least not=20 > > > have to define a new labels. > >=20 > > We probably could, though since the labels are subject to change (se= e=20 > > the TODO about possibly including the HashAlgorithm in the label), w= e=20 > > kept it as is. > >=20 > > > > > > - =E2=80=9CTLS 1.3 [RFC8446] supports pre-shared key (PSK) resumpt= ion,=20 > > > wherein > > > PSKs can be established via session tickets from prior connections= or > > > externally via some out-of-band mechanism.=E2=80=9D > > > > > > This seems to indicate that all use of PSK is resumption which is = not=20 > > > correct. I suggest changing to =E2=80=9CTLS 1.3 [RFC8446] supports= =20 > > > pre-shared key (PSK) authentication=E2=80=9D > >=20 > > Good suggestion! We=E2=80=99ll fix it. > >=20 > > > > > > - =E2=80=9Cimporting external PSK (Pre-Shared Key) into TLS.=E2=80= =9D > > > > > > Not sure if =E2=80=9Cinto=E2=80=9D is the right word, I think =E2=80= =9Cfor=E2=80=9D as in th e=20 > > > title is better. The mechanism seems very much external to TLS its= elf.=20 > > > I see it as a mechanism to derive several external PSKs from a sin= gle=20 > > > external PSK. > >=20 > > Ditto. > >=20 > > > > > > - =E2=80=9CSimilarly, TLS 1.2 and all prior TLS versions should us= e "tls12"=20 > > > =E2=80=9C > > > > > > The versions prior to TLS 1.2 will soon be deprecated. And why spe= nd=20 > > > time updating the TLS 1.2 code base instead of moving to TLS 1.3? > >=20 > > We=E2=80=99re just covering our bases here. I tend to agree that the= focus=20 > > should be on updating to TLS 1.3 instead of =E2=80=9Cpatching=E2=80=9D= TLS 1.2=20 > > stacks. > >=20 > > > > > > > > > Suggestion: > > > > > > Instead of deriving a large set of new external PSKs, wouldn=E2=80= =99t it be=20 > > > possible to just use different hash functions in different parts o= f=20 > > > the key hierarchy? I.e. if SHA-256 is associated with the external= PSK=20 > > > and SHA-384 is the hash algorithms in the chosen cipher suite: > > > > > > PSK -> HKDF-Extract(SHA-256) =3D Early Secret > > > | > > > +-----> Derive-Secret(., "ext binder" | "res binder", "") > > > | =3D binder_key > > > | > > > +-----> Derive-Secret(., "c e traffic", ClientHello) > > > | =3D client_early_traffic_secret > > > | > > > +-----> Derive-Secret(., "e exp master", ClientHello) > > > | =3D early_exporter_master_secret > > > v > > > Derive-Secret(., "derived", "") > > > | > > > v > > > (EC)DHE -> HKDF-Extract(SHA-384) =3D Handshake Secret > > > > > > Support of this could be signalled with the tls_flags extension. I= f=20 > > > the server does not support the extension it must according to RFC= =20 > > > 8446 chose a cipher suite with SHA-256. > >=20 > > Modifying the key schedule was discussed in the context of [2].. At = the=20 > > time, it seemed the desire to not touch the key schedule outweighed = the=20 > > desire to not inflate the ClientHello. > >=20 > > Best, > > Chris > >=20 > > [1] https://github.com/chris-wood/draft-wood-tls-external-psk-import= er > > [2] https://tools.ietf.org/html/draft-davidben-tls-universal-psk-00 > >=20 > >=20 > >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --32c40413e1924ba1a4a50e6e814dbb80 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable

=

On Thu, Apr 4, 2019, at 6:01 AM, Christopher Wood wr= ote:

=

On Wed, Apr 3, 2019, at 11:22 PM, John Mattsso= n wrote:
> Hi Christopher,
> 
=
> Thanks for the clarifications.
> <= br>
> >You=E2=80=99re correct that this requires both en= dpoints to adopt the change 
> >simultaneously.= However, that does not contradict the quoted text, which 
> >states that the protocol is not changed.
&g= t; 
> I think "this requires both endpoints to ado= pt the change simultaneously" is a problem as it makes it impossible to = introduce this mechanism in many existing deployments. I would expect a = solution that can be introduced gradually (some nodes at a time) in exis= ting deployments supporting RFC 8446 and/or RFC 5246.

=
I think perhaps my response was unclear. In your scenario, ad= ding key import support is essentially the same as adding a new PSK to a= node. Some nodes may offer (or accept) the PSK, while others do not. Su= ccessful use of an imported PSK will only occur if both endpoints have i= mported the same PSK. Gradual deployment is possible.

To clarify further since this too may be mislead= ing: This assumes the imported PSKs are offered alongside the existing e= xternal PSKs. So, to your previous question regarding simultaneous use o= f imported keys and external PSKs, gradual deployment is only applicable= with stacks supporting 1.3 and 1.2, where imported keys apply to 1.3. N= odes supporting 1.2 and 1.3 without the imported keys will offer 1.2 PSK= s, whereas nodes with imported keys will offer 1.2 and imported 1.3 PSKs= .

You=E2=80=99re right that it=E2=80=99s no= t possible to deploy gradually if one is currently using external PSKs f= or only 1.3 or 1.2, wants to adopt the importer API, and is prohibited f= rom using both imported and external PSKs at the same time.


> 
> But, if you want to change the be= haviour of the using the same external PSK in both TLS 1.2 and TLS 1.3 a= s allowed by RFC 8446, a solution not requiring "simultaneous change" is= probably not possible.
> 
> The = requirement that "this requires both endpoints to adopt the change simul= taneously" should probably be highlighted in the document.
> 
> The current mechanism does not seem to be= deployable for e.g. 3GPP until TLS 1.4 is introduced, and then only for= TLS 1.4 and later... on the other hand, being limited to SHA-256 for PS= K may be ok for 3GPP. (and 3GPP could just derive a Separate SHA-384 PSK= if needed).
> 
> Some more comme= nt:
> 
> - Which label should be = used by various versions of DTLS?

Likely th= e same labels as the TLS counterparts, since the label more or less spec= ifies the *handshake* variant.

> 
> - "If a client or server wish to deprecate a hash func= tion and no longer
> use it for TLS 1.3, they may remov= e this hash function from the set
> of hashes used duri= ng while importing keys. This does not affect the
> KDF= operation used to derive concrete PSKs."
> 
> If someone deprecates the use of a hash function inside TL= S 1.3 (used by Transcript-Hash and HKDF), does it then makes sense to ke= ep deriving keys outside of TLS with that same deprecated hash function?=

No. If this deprecation occurs, then they = would follow the advisory text and not use the old hash when importing k= eys.

> 
> - "To mi= tigate these problems, external PSKs can be bound to a specific hash fun= ction when used in TLS 1.3"
> 
> = I would change to "are bound to a specific". If the application does not= specify anything, the keys are bound to SHA-256.

Works for me. I=E2=80=99ll file an issue to track the change.
=

Thanks,
Chris 

> 
> Cheers,
>= ; John
> 
>  -----Original M= essage-----
> From: Christopher Wood <caw@heapingbit= s.net>
> Date: Wednesday, 3 April 2019 at 16:25
<= /div>
> To: John Mattsson <john..mattsson@ericsson.com>
=
> Cc: "TLS@ietf.org" <TLS@ietf..org>
&= gt; Subject: Re: [TLS] Comments on draft-wood-tls-external-psk-importer-= 01
> 
>  Thanks for the feed= back, John. I filed issues on the GitHub draft 
>&= nbsp; located at [1]. Please see inline below for comments.
> 
>  On 1 Apr 2019, at 12:00, John Matt= sson wrote:
> 
>  > Hi,
>  >
>  > Thanks for tr= ying to solve this problem! Not having a way to use the 
<= div>>  > same external PSK for different cipher suites is def= initely a thing 
>  > missing from TLS 1.3= .
>  >
>  > As I state= d during the wg session, 3GPP have a few use cases that use 
>  > PSK-ECDHE between phone and core network. Contra= ry to what IETF people 
>  > sometimes bel= ieve, most 3GPP use of TLS (between phone and core 
&= gt;  > network, between core nodes, and between different operat= ors) use 
>  > mutual authentication with = certificates.
>  >
>  >= ; According to the current 3GPP specification, the phone and the core&nb= sp;
>  > network would share an external PSK an= d an external identity. The hash 
>  > fun= ction is undefined, i.e. SHA-256 is used for TLS 1.3. The phone and = ;
>  > the network would then negotiate TLS 1.2= with any cipher suite or TLS 
>  > 1.3 wi= th SHA-256.
>  >
>  > = Some comments
>  >
>  >= ; - The draft should make clear if the External PSK and external 
>  > identity can be used together with the impo= rted identities. I assume 
>  > the idea i= s that they can=E2=80=99t but I can=E2=80=99t see any text specifying&nb= sp;
>  > this.
> 
>  Indeed, that was the intent.
> <= br>
>  >
>  > - =E2=80=9DI= mported keys do not require negotiation for use, as a client and
>  > server will not agree upon identities if not impo= rted correctly.
>  > Thus, importers induce no = protocol changes with the exception of
>  > exp= anding the set of PSK identities sent on the wire.=E2=80=9D
>  >
>  > While I see how the defi= ned mechanism can be deployed in a new 
>  &g= t; deployment, I do not see how to introduce it in an existing 
=
>  > deployment. Assuming that the external PSK ca= nnot be used together 
>  > with the impor= ted identities, the TLS client and server must introduce 
=
>  > the mechanism at the same time, that is often not p= ossible to control.
> 
>  Yo= u=E2=80=99re correct that this requires both endpoints to adopt the chan= ge 
>  simultaneously. However, that does not= contradict the quoted text, which 
>  states= that the protocol is not changed.
> 
>  >
>  > - =E2=80=9Cstruct {
<= /div>
>  > opaque external_identity<1...2^16-1>;
>  > opaque label<0..2^8-1>;
= >  > HashAlgorithm hash;
>  > } Impo= rtedIdentity;
>  > =E2=80=9D
>=   >
>  > This scales poorly, A client h= as to send n*m identities where n is the 
>  = > number of supported versions and m is the number of supported hash&= nbsp;
>  > algorithms...
>&nbs= p;
>  Yes, this is a tradeoff we made by opting to= not modify the key 
>  schedule.
> 
>  >
>  >= ; - Would it not be possible to just use the version number as label?&nb= sp;
>  > I.e. 0x0304 instead of =E2=80=9Ctls13=E2= =80=9D. In that way you do at least not 
>  &= gt; have to define a new labels.
> 
= >  We probably could, though since the labels are subject to cha= nge (see 
>  the TODO about possibly includin= g the HashAlgorithm in the label), we 
>  kep= t it as is.
> 
>  >
>  > - =E2=80=9CTLS 1.3 [RFC8446] supports pre-share= d key (PSK) resumption, 
>  > wherein
<= /div>
>  > PSKs can be established via session tickets fr= om prior connections or
>  > externally via som= e out-of-band mechanism.=E2=80=9D
>  >
>  > This seems to indicate that all use of PSK is resu= mption which is not 
>  > correct. I sugge= st changing to =E2=80=9CTLS 1.3 [RFC8446] supports 
&= gt;  > pre-shared key (PSK) authentication=E2=80=9D
> 
>  Good suggestion! We=E2=80=99ll fix= it.
> 
>  >
>  > - =E2=80=9Cimporting external PSK (Pre-Shared Key) int= o TLS.=E2=80=9D
>  >
>  &= gt; Not sure if =E2=80=9Cinto=E2=80=9D is the right word, I think =E2=80= =9Cfor=E2=80=9D as in th e 
>  > title is = better. The mechanism seems very much external to TLS itself. 
<= /div>
>  > I see it as a mechanism to derive several exte= rnal PSKs from a single 
>  > external PSK= .
> 
>  Ditto.
> 
>  >
>  > = - =E2=80=9CSimilarly, TLS 1.2 and all prior TLS versions should use "tls= 12" 
>  > =E2=80=9C
>&nbs= p; >
>  > The versions prior to TLS 1.2 will= soon be deprecated. And why spend 
>  > t= ime updating the TLS 1.2 code base instead of moving to TLS 1.3?
> 
>  We=E2=80=99re just covering o= ur bases here. I tend to agree that the focus 
>&n= bsp; should be on updating to TLS 1.3 instead of =E2=80=9Cpatching=E2=80= =9D TLS 1.2 
>  stacks.
>&nb= sp;
>  >
>  >
>  > Suggestion:
>  >
>  > Instead of deriving a large set of new external PS= Ks, wouldn=E2=80=99t it be 
>  > possible = to just use different hash functions in different parts of 
>  > the key hierarchy? I.e. if SHA-256 is associated = with the external PSK 
>  > and SHA-384 is= the hash algorithms in the chosen cipher suite:
> = ; >
>  > PSK -> HKDF-Extract(SHA-256) =3D= Early Secret
>  > |
>  &= gt; +-----> Derive-Secret(., "ext binder" | "res binder", "")
>  > | =3D binder_key
>  > |<= br>
>  > +-----> Derive-Secret(., "c e traffic",= ClientHello)
>  > | =3D client_early_traffic_s= ecret
>  > |
>  > +---= --> Derive-Secret(., "e exp master", ClientHello)
>&= nbsp; > | =3D early_exporter_master_secret
>  &= gt; v
>  > Derive-Secret(., "derived", "")
<= /div>
>  > |
>  > v
>  > (EC)DHE -> HKDF-Extract(SHA-384) =3D Handshake Secr= et
>  >
>  > Support o= f this could be signalled with the tls_flags extension. If 
>  > the server does not support the extension it must= according to RFC 
>  > 8446 chose a ciphe= r suite with SHA-256.
> 
>  = Modifying the key schedule was discussed in the context of [2].. At the&= nbsp;
>  time, it seemed the desire to not touch t= he key schedule outweighed the 
>  desire to = not inflate the ClientHello.
> 
>=   Best,
>  Chris
> 
=
>  [1] https://github.com/chris-wood/draft-wood-tls-e= xternal-psk-importer
>  [2] https://tools.ietf.org= /html/draft-davidben-tls-universal-psk-00
> 
> 
> 

_______________________________________________
TLS mail= ing list
TLS@ietf.org
https://www.ietf.org/m= ailman/listinfo/tls


= --32c40413e1924ba1a4a50e6e814dbb80-- From nobody Thu Apr 4 09:42: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 13A1B1206C2 for ; Thu, 4 Apr 2019 09:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 ZQr_U4dpoKRQ for ; Thu, 4 Apr 2019 09:42:31 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) (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 78AED12065D for ; Thu, 4 Apr 2019 09:42:31 -0700 (PDT) Received: from [47.143.125.151] (helo=Williams-MacBook-Pro.local) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4) (envelope-from ) id 1hC5Rd-0009bf-Tk; Thu, 04 Apr 2019 12:42:30 -0400 Date: Thu, 4 Apr 2019 09:42:29 -0700 From: Bill Frantz To: John Mattsson cc: TLS@ietf.org X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4.3 (480) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79285609adbaadc33a18800fd6261caff1350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 47.143.125.151 Archived-At: Subject: Re: [TLS] Comments on draft-wood-tls-external-psk-importer-01 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, 04 Apr 2019 16:42:39 -0000 On 4/4/19 at 11:22 PM, john.mattsson@ericsson.com (John=20 Mattsson) wrote: >I think "this requires both endpoints to adopt the change=20 >simultaneously" is a problem as it makes it impossible to=20 >introduce this mechanism in many existing deployments. I would=20 >expect a solution that can be introduced gradually (some nodes=20 >at a time) in existing deployments supporting RFC 8446 and/or=20 >RFC 5246. Having seen a successful deployment and migration to a new=20 incompatible version of a protocol, I think we too rapidly=20 dismiss the possibility. In security protocols, we gain a lot of=20 simplicity, and therefore security, by not having a=20 compatibility mode. I wrote a short paper about this deployment=20 for an amateur radio publication which I have included below. Cheers - Bill ----------------------------------------------------- =46lag Day with FT8 Bill Frantz, AE6JV West Valley Amateur Radio Association Northern California DX Club Northern California Contest Club Abstract Recently a community of over 20,000 users did a conversion=20 between release 1 and release 2 of a amateur radio digital=20 communications protocol called FT8. The old version of the=20 protocol was not compatible with the new version, resulting in a=20 "flag day" event for users. However, the conversion was rapid=20 and proceeded smoothly. Lessons from this conversion should be=20 useful for other software projects. -------------------------------------------------- Introduction The new FT8 digital transmission mode has taken the amateur=20 radio world by storm. Adoption has been overwhelmingly rapid,=20 going from nothing at its first release in July 2017 to the most=20 popular mode for many uses in December 2018. =46T8 is the invention of Steven Franke, K9AN, and Joe Taylor,=20 K1JT. (Joe won the Nobel Prize in Physics laureate for his=20 discovery with Russell Hulse of a "new type of pulsar, a=20 discovery that has opened up new possibilities for the study of=20 gravitation."[1]) It is a "weak signal" mode using 50 Hz=20 bandwidth for each signal, and can decode stations that are 24=20 dB below the voice signal bandwidth noise level. It is an evolving protocol and has recently been through a major=20 change, from 75 bit messages to 77 bit messages. When you make a=20 major change in a computer protocol, and indeed, FT8 is a=20 computer protocol, there are two ways to introduce the change.=20 (1) You can code the new protocol to inter-operate with the old=20 protocol, or (2) you can have a "Flag Day" where everyone=20 changes to the new protocol at the same time. (A "flag day" is=20 when everyone has to adopt the new protocol at about the same=20 time or lose connection with those who have adopted it.) Historically, computer engineers have avoided flag days like the=20 plague. Getting everyone to change at the same time is almost=20 impossible, and it is easier to design inter-operation. The FT8=20 implementors made the other choice; to have a flag day. It is=20 interesting examine why they made that choice and how they=20 succeeded with that choice. Bill Somerville, G4WJS reported on January 16, 2019 [2] "The situation with the 75-bit to 77-bit update of the FT8=20 protocol has several constraints that are uncommon elsewhere and particularly uncommon when they are all combined, including: "1) It is a communications protocol where every user wishes=20 to be able to communicate with any other, 2) the old version will not understand the new protocol, at least without an upgrade, 3) WSJT-X is FOSS [Freee Open Source Software] with no charges for use or=20 upgrade, 4) the core WSJT development team is tiny and has no wish to support multiple GA [General Availability] versions. "Given these constraints and a desire not to consume extra valuable digital modes bandwidth, any opportunity for old protocol=20 users who do not wish to upgrade should be avoided. Having a new version=20 that still talks the old protocol just exacerbates the potential schism=20 of users since it allows those reluctant to upgrade to continue using=20 the old protocol, at least until the number of indecipherable signals which are QRM [interference] to their decoder overwhelms them." Joe Taylor reported on January 17, 2019 [2]: "1. We published a schedule, three months in advance,=20 specifying target dates for intermediate candidate releases for beta testing. We publicized this schedule as widely as possible, and we stuck=20 to it. "2. The first three candidate releases included "bi-lingual" capability for the old and new protocols. This helped to encourage beta testing and feedback from interested users, and helped to show users that upgrading was a simple drop-in replacement. "3. Candidate releases 4 and 5 were "new protocol only". =20 They allowed us to eliminate large amounts of obsolete code and fix most=20 of the bugs introduced by these wholesale changes." Operations are usually a lot more pleasant when everyone is=20 running the same version of a protocol. As Bill Somerville notes=20 above, keeping the community of users together has a significant=20 long-term value. Inter-operation logic tends to be buggy as noted by Joe Taylor=20 above, and those problems "just go away" with a flag day. A flag=20 day also allows a development team to concentrate on more=20 valuable tasks. Also, with only 77 bits in a message, spending a bit or several=20 on a message format ID is very expensive. Considering that it=20 takes 15 seconds to send each of these messages, and another 15=20 seconds to receive the reply, every bit is precious. Another consideration is that the old and new formats can=20 coexist operating on different frequencies. They just can't talk=20 to each other. People who haven't converted can still=20 communicate with others who haven't converted, somewhat easing=20 the need for everyone to change "at once". However seeing a lot=20 of strong signals that can't be decoded is a significant=20 incentive to find out what the problem is and fix it. -------------------------------------------------- Changeover Time Line So what was the result when the team announced they would have=20 Release 2.0 available on December 10, 2018 and expected everyone=20 to convert by January 1, 2019? In a word, success! From the=20 wsjt-x developer email list: Joe Tailor reported [3]: "Monitoring 20 meters just 3 hours after WSJT-X 2.0 had been released, I found that nearly half of the active stations were already=20 using it. I made 18 QSOs [contacts] in about half an hour. "According to PSK Reporter* statistics, at least 1620=20 callsigns have been making QSOs with the new version. This is now ~7.5=20 hours after the v2.0 GA release." Dwight NS9I reported [4]: 70 q's [contacts] and all is well ...=20 amazed at the activity, including DX [foreign stations] on all=20 the bands. On December 12, Tom OH6VDA reported [5]: And right now=20 aproximately 8000 V2.0 users of a total of 21 000 WSJT-X users,=20 according to Pskreporter.info#. :) On December 12, Richard KF5OIM reported [6]: wjstx 2.0.0 has=20 landed in the Fedora testing repositories for Fedora 28, 29,=20 Rawhide and Fedora EPEL 7 (CentOS,SL,etc) On December 12, Ted K9IMM reported [7]: I have a multi-band FT8 skimmer. It skims 7 bands from 160M-15M (excluding 60M). I converted the skimmer to V2.0.0 yesterday about this time. Ordinarily, my V1.9.1 spot rate was about 10,000-12,000 spots=20 per day. In the last 24 hours my V2.0.0 spot rate is 7700/day. So...Either there are a huge amount of new FT8 users running V2.0.0, or users are converting to the new version at a very satisfyingly rapid rate. Pretty amazing for a release 2 days old. On December 14, Joe Taylor reported [8]: This morning I ran an instance of WSJT-X v1.9.1 in parallel with WSJT-X 2.0. An informal count of decodes in the old and new protocols shows far more activity using the new 77-bit messages. Here=20 are the rough statistics, given as the ratio of new- to old-style decodes: For FT8: ----------- 17m: 10:1 20m: 3:1 30m: 6:1 40m 20:1 On December, 14, Charlie WD5BJT reported [9]: I mostly operate=20 on the 6 meter band using FT-8. Of the many operators on the=20 band last night, I decoded only two users of the old protocol. On January 2, 2019, a late adopter reported [10]: My version of=20 WSJT-X is 1.8.0=C2=A0 I don't decode anything, WF [Waterfall, a way=20 of seeing all the signals on a band] clearly has big signals on=20 it that come and go every 15 sec.=C2=A0 Do I need to upgrade? -------------------------------------------------- Conclusions This change was a very successful flag day. There is almost no=20 one using the old version after the end of the cut-over period.=20 There are almost no complaints about the need to change. Things that made this success possible: Most of the usage of FT8 is concentrated in a small=20 percentage of the users. This small percentage of users were=20 early adopters. As a result, nearly half to the signals on one=20 band were in the new format only 3 hours after the release of=20 the new version. There were a number of features in the new version of the=20 software that would attract users to convert. These included=20 better classification of a received station's location (for=20 people interested in long distance communication) and support=20 for more kinds of on-the-air ham radio activities. Conversion was a simple drop-in replacement without a lot of=20 effort required from the user. File data formats did not change except for the details of=20 some debugging information. Information about contacts made with=20 the old version were available to the new version. A use could easily switch back and forth between the old and=20 new version, easing concerns of early adopters. Software developers with similar advantages should give more=20 consideration to having a flag day instead of including=20 inter-operation code in their applications. A flag day might be=20 particularly attractive if there is a strong desire to keep from=20 splitting the user community, or if the development team is small. -------------------------------------------------- * PSK Reporter is a world-wide amateur radio service which=20 listens for digital signals and reports which ones it hears via=20 the Internet. See: and # PSK Reporter can take up to a week to notice that a station is=20 using the new version. -------------------------------------------------- Acknowledgements Thanks to Joe Taylor K1JT and Bill Somerville G4WJS for their=20 comments. Their insite into the development process was very=20 valuable in developing this paper. Thanks to Wolfgang Meister OE1MWW for information about PSK=20 Reporter and other software supporting FT8. Thanks to Gary Hinson ZL2iFB's "FT8 Operating Guide"=20 for some=20 of the early history of FT8 -------------------------------------------------- References [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] Post to the Northern California Contest Club reflector on=20 January 2, 2019 at 1533 PDT. ----------------------------------------------------- --------------------------------------------------------------------------- Bill Frantz |"After all, if the conventional wisdom was=20 working, the 408-356-8506 | rate of systems being compromised would be=20 going down, www.pwpconsult.com | wouldn't it?" -- Marcus Ranum From nobody Thu Apr 4 11:10: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 7D0A71200C5 for ; Thu, 4 Apr 2019 11:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_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 tI4ezNzxrtCY for ; Thu, 4 Apr 2019 11:10:41 -0700 (PDT) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 420C6120052 for ; Thu, 4 Apr 2019 11:10:41 -0700 (PDT) Received: by mail-qk1-x72f.google.com with SMTP id c20so2215480qkc.10 for ; Thu, 04 Apr 2019 11:10:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=Mw1FQ8GTvO6cnbo9PXDHVtHWrWGVuQGXWJJory6hIt0=; b=W5wOfB2gLwFXIJogovti88Y7jrteduiCKesKb9bMvFNUAV3mY59FhMyxwnp2L+7oZT 5WUD9hMQ/knH8szYOpeJIYmG62j78pO6zF/1Oi1EEmeICvtfvZsV0sjAQlOG+kDf5Yyk yj90kjrQOeREGRyPPnUTIt+0Mswpze2pGmr8E= 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=Mw1FQ8GTvO6cnbo9PXDHVtHWrWGVuQGXWJJory6hIt0=; b=GTHc/UEOA7vQnQZt+/FM+v+gr0D9c9j3i4tSbztIhukn6wHm2s5xi5qQuAsH0+HCEb NY48PDvKSDOx3d9WzdVOVLmtvEOtxbovX/AC2QF/3HE2U65xbLi6k0jSf4taza2H7Gf3 TpJm0jvYnmUE6Az4TphnCZWXi9yuY72koPrzAD9tL2Xyus9w/1bcjfy7d8i7x8iqbnvo 3KEZd1stqHp7IWlIkXIMtKTC2tr/R6JC0vT6M7C4J02epUV5nH+Zu2PmB5DAZSof01qd 4xWXEjtL4WHTUk8GTuif3LpStNx0oThl8He/5H7+8IOk2OJRGrUF4fa6CXcnDbSyryEI ef3A== X-Gm-Message-State: APjAAAW2zlvCf2OeUTF1KgGd7FGEc28mHYdgwYQyOyng9Y2oNePHZ2id n109zFlRa4n9CAcj5tWia2F65r6JTe09n/PB5Qx7LA0ZqQQ= X-Google-Smtp-Source: APXvYqyclhyN0RgMltzlBAfWj93s/5u3Mktv+RZtJqqxhwZw1Wfx+ymGlm8YRZDLYZDPzlWEQFwnBbis4juW9vDF2cQ= X-Received: by 2002:a37:b444:: with SMTP id d65mr6376197qkf.125.1554401440087; Thu, 04 Apr 2019 11:10:40 -0700 (PDT) MIME-Version: 1.0 From: Watson Ladd Date: Thu, 4 Apr 2019 11:10:29 -0700 Message-ID: To: tls@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [TLS] kc2kdm.com has interop with other implementations 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, 04 Apr 2019 18:10:42 -0000 Dear all, Apologies for the premature announcements, but kc2kdm.com is working with delegated credentials version -03 (although the certificate has an extra two bytes in the extension) Thanks to Christopher Patton and Illari Liusvaara who have both confirmed it works with different implementations. The extension being used is 0xff02. I look forward to hearing reports of interoperability or issues. Sincerely, Watson Ladd From nobody Thu Apr 4 13:45: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 1D6D7120251 for ; Thu, 4 Apr 2019 13:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ghedini.me Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dP5WvatESMu for ; Thu, 4 Apr 2019 13:45:49 -0700 (PDT) Received: from blastoise.ghedini.me (blastoise.ghedini.me [IPv6:2001:19f0:6c01:a56:5400:1ff:fe4a:5694]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 142A0120241 for ; Thu, 4 Apr 2019 13:45:49 -0700 (PDT) Received: from localhost (unknown [IPv6:2a02:8010:6241:0:e87a:d33d:95f4:3fb6]) by blastoise.ghedini.me (Postfix) with ESMTPSA id C334ADF4FF; Thu, 4 Apr 2019 20:45:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ghedini.me; s=mail; t=1554410745; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ipUiILXDeB9bRBYo1Jm5DkoTspEDVPmIaPGnGi6gLpg=; b=YUbilA67wf6wQ/m5p4neI5uqT86gmkgkfvnZHUykgtKirrCtMFkVfg+OU7Qkrd7PhhFsmN H3sukNJnqw/+ZBjHiVSZC7dAIE667uRXcNmNktoAhHTgeYBurC1UklFDsa+O259qi6nLdx G8gyxtft4KB6pC+44DN3X/IPcC2pLXk= Date: Thu, 4 Apr 2019 21:45:42 +0100 From: Alessandro Ghedini To: Victor Vasiliev Cc: "W. Felix Handte" , "tls@ietf.org" Message-ID: <20190404204542.GA7403@pinky.flat11.house> References: <270001f2-1b81-652c-8f43-f03d9b00ac2a@felixhandte.com> 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] Certificate Compression: Add Zstd Code Point? 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, 04 Apr 2019 20:45:51 -0000 On Mon, Apr 01, 2019 at 06:09:16PM -0400, Victor Vasiliev wrote: > This sounds reasonable to me. I currently don't have a plan for > implementing this, but since zstd is well-defined and has an RFC published > (that I can easily cite), I see no reason not to add it. > > I wrote up a PR: https://github.com/tlswg/certificate-compression/pull/26. > I will merge it before the last call, unless there are objections. This seems pretty inoffensive (just one more allocated codepoint), and it's already been a few days and nobody seems to object. We'd like to submit a new draft version so we can finally go to WGLC, so if nobody objects by tomorrow I'll just merge the PR and upload the draft. Cheers From nobody Fri Apr 5 03:03:28 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 24276120045; Fri, 5 Apr 2019 03:03:27 -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.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <155445860706.13142.18114741162189514330@ietfa.amsl.com> Date: Fri, 05 Apr 2019 03:03:27 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-certificate-compression-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: Fri, 05 Apr 2019 10:03:27 -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 : TLS Certificate Compression Authors : Alessandro Ghedini Victor Vasiliev Filename : draft-ietf-tls-certificate-compression-05.txt Pages : 7 Date : 2019-04-05 Abstract: In TLS handshakes, certificate chains often take up the majority of the bytes transmitted. This document describes how certificate chains can be compressed to reduce the amount of data transmitted and avoid some round trips. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-certificate-compression/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-certificate-compression-05 https://datatracker.ietf.org/doc/html/draft-ietf-tls-certificate-compression-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-certificate-compression-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 Fri Apr 5 03:11: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 7C9BA120183 for ; Fri, 5 Apr 2019 03:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=ghedini.me Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9E5IxzxmVS-o for ; Fri, 5 Apr 2019 03:11:47 -0700 (PDT) Received: from blastoise.ghedini.me (blastoise.ghedini.me [45.32.158.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D18D120086 for ; Fri, 5 Apr 2019 03:11:47 -0700 (PDT) Received: from localhost (unknown [217.138.62.245]) by blastoise.ghedini.me (Postfix) with ESMTPSA id DA7BBDF399 for ; Fri, 5 Apr 2019 10:11:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ghedini.me; s=mail; t=1554459106; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=BbDYEyPTCECV4vKcf+BTT/h1upDaFsFq4HObTzt2W4Q=; b=RxkBgc0MbOkdlIRIB3I7oFGdARJ44/Kd0C+wf23eSsNayR5TJAIgAWE4o4swJZG4Z6KZjQ W7z+ESCSjbQL1fE5W+d5mNH0G1EsjZMfFaqdpkr0fEiPWXWN7hXK3rkWSdYEj8pF78w8qB eN7klhp7aJhdCoSp/s2USfuC02wMhRo= Date: Fri, 5 Apr 2019 11:11:42 +0100 From: Alessandro Ghedini To: tls@ietf.org Message-ID: <20190405101142.GA4036@mandy.flat11.house> References: <155445860706.13142.18114741162189514330@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <155445860706.13142.18114741162189514330@ietfa.amsl.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-05.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: Fri, 05 Apr 2019 10:11:49 -0000 On Fri, Apr 05, 2019 at 03:03:27AM -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 : TLS Certificate Compression > Authors : Alessandro Ghedini > Victor Vasiliev > Filename : draft-ietf-tls-certificate-compression-05.txt > Pages : 7 > Date : 2019-04-05 > > Abstract: > In TLS handshakes, certificate chains often take up the majority of > the bytes transmitted. > > This document describes how certificate chains can be compressed to > reduce the amount of data transmitted and avoid some round trips. This new version addresses the latest round of comments from both the session at IETF 104 as well as varios discussions on the list. CHanges include: * Fix in the definition of CertificateCompressionAlgorithms. * Clarifications on certain design decisions behnd the spec. * Definition of requirements on the allowed compression functions. * Inclusion of code point for the zstd compression algorithm. We think all of the outstanding issues have now been addressed, so WGLC maybe? Cheers From nobody Fri Apr 5 03:34: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 0AAF01203B0 for ; Fri, 5 Apr 2019 03:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wizmail.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 s7sIl-OZUGjK for ; Fri, 5 Apr 2019 03:34:41 -0700 (PDT) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (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 55F35120369 for ; Fri, 5 Apr 2019 03:34:41 -0700 (PDT) ARC-Seal: i=1; cv=none; a=rsa-sha256; d=wizmail.org; s=r201803; t=1554460481; b=Qsb2MYvSdH9hg/b17px2xpOi1AM2elfV0qFJ8jZJN73s+3kgX2pviD/aFK2odwf2W56HSUQowA MOcEKUkaL9JTyyTCUvRNsoO5N6qrwiogBwdkFctemoTG8ICqx3sLIyjbfc1ZWltl6KWNlQx6xG yzfIsdTQAniq0tcrXH9Df8s=; ARC-Authentication-Results: i=1; wizmail.org; iprev=fail smtp.remote-ip=2a00:b900:109e:0:855c:1404:1b9d:3a94; auth=pass (PLAIN) smtp.auth=jgh@wizmail.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=wizmail.org; s=r201803; t=1554460481; bh=RXoZpJD00YgfVwcaLShE1ryvoaBF+kO8GNc4RXb2Cmk=; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:DKIM-Signature; b=FTxhRHU5TWz+KsHWnO/RmBam02sd42wH+CiKZLEy2Zq8rlpSje8ZIMET+3zlRQSyRdRq8ZrbMs +WBARHll9+j5htofPxWcsaBuWcAlK9AuUsK3uwDQ4qcqUIp1RGQjl675dbrqBM5tMdFVgHTCB6 NFgfxTqo25AXFc62Tqi+lRI=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org ; s=r201803; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:To:Subject:From:Sender:Reply-To: Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive; bh=GdqXYQ44iBM57FztwI/O0nOo4sj5+x0JaoYQHbzcBQc=; b=E SSG0dFHLZu53y3Fp3cAr9wg3uxRsEPNYi836NDR8b9Cg0MP59E/zd2L2IRZtPNiR5Q5PpSGenBeam LlN5GGE73No8u3BefIA/2C1OnVtdwbvZyX47I7L6BDvaUz+It2QhHYIGPoJ2jphVweuYIQwYp7dea 1FwICh80vzcAM7Is=; Authentication-Results: wizmail.org; iprev=fail smtp.remote-ip=2a00:b900:109e:0:855c:1404:1b9d:3a94; auth=pass (PLAIN) smtp.auth=jgh@wizmail.org Received: from [2a00:b900:109e:0:855c:1404:1b9d:3a94] (helo=lap.dom.ain) by wizmail.org (Exim 4.92.106) (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) with esmtpsa id 1hCMBC-0006oB-SQ for tls@ietf.org (return-path ); Fri, 05 Apr 2019 10:34:39 +0000 To: tls@ietf.org References: <155445860706.13142.18114741162189514330@ietfa.amsl.com> From: Jeremy Harris Openpgp: preference=signencrypt Autocrypt: addr=jgh@wizmail.org; prefer-encrypt=mutual; keydata= mQENBFWABsQBCADTFfb9EHGGiDel/iFzU0ag1RuoHfL/09z1y7iQlLynOAQTRRNwCWezmqpD p6zDFOf1Ldp0EdEQtUXva5g2lm3o56o+mnXrEQr11uZIcsfGIck7yV/y/17I7ApgXMPg/mcj ifOTM9C7+Ptghf3jUhj4ErYMFQLelBGEZZifnnAoHLOEAH70DENCI08PfYRRG6lZDB09nPW7 vVG8RbRUWjQyxQUWwXuq4gQohSFDqF4NE8zDHE/DgPJ/yFy+wFr2ab90DsE7vOYb42y95keK tTBp98/Y7/2xbzi8EYrXC+291dwZELMHnYLF5sO/fDcrDdwrde2cbZ+wtpJwtSYPNvVxABEB AAG0JkplcmVteSBIYXJyaXMgKG5vbmUpIDxqZ2hAd2l6bWFpbC5vcmc+iQE7BBMBAgAlAhsD BgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAUCVYAYBAIZAQAKCRC85YyM5B8y34iFB/9wozIY RogNdY1aejFFixb6++y4b1riyjMvWEULeEzDlQ0lMT6Z3PxXhZILD4y4aP7Kzx0ozXa5qaKy 41EAPKQoPipnRAH04QytJbIERvz8Tot/LeCVKUc0G9DVxOPBD03czTgqgz4EjV2qvnLF+rTU 0YBevrNCluKosGSd+3RvLWVu0hBhn9pELKfXJNSQXZb+TpHDhSDZ/gCrglBEOhA6YWbDb/4g z+5TFKdk+B++iAQZSHv7zISabjN+BPYgI47A+MU4JycoXaAUnMc0l5ba6fGNaIrzruE4aAZr lP5o+7mlU9Mm0QJqdqYxYPAiplJGrZv+YXH1fp5ueEK3l+NGuQENBFWABsQBCADphLHaKToR uR/E7THerBiCjDatwCaETOKOTY2zRBQpaQ32p/F2XIGLS8Cc27+grZSKQ6ZX0ZN47O+AFyFH F8DH90IXZFpJR3Rb8zgXT8jnLX08DM31eECZHnRzFhGlOmq6WAUlqB3GKCPUCY2c4eTRXyoX LteTxrXCYoj45y/YmvlZrlonBNjPBAyHiO/LNz+V7fZtNsN7N/XGrnLbcdNfNd+SD1ENmbLJ 8RvyymxguTyB/ka9JdjHHIoQEJ6L166B3hhfCHpt8iC0GPZkti9IMl0NoJ029jJm3Jq1qEce EBn5H5QMGn6Fq64iXwTsO1TMNUwpWx8pjvV7wVIxjI8ZABEBAAGJAR8EGAECAAkFAlWABsQC GwwACgkQvOWMjOQfMt9N6Af8CS2CTrMQFdhkGEtBXmL4ifD8UHFkBRBGmM8ZL2fWUBTZXT8m rdRMOK6tcPnKWaCvWvKr0knt970j/DyAgFmH8hgOi3yctigFecVDjjilAeCJMq38s1tYKYiL DbBdHWtdkA9uHZwq3lfd3QxcEEO3QamQF+dO7h8gAOXlG+po87Hm+E0wz4swIB8+S37Jzrx9 uu0LSFDfJCTK+TIKGa5Un8LxPxyq9WnnNDh72zK7BiRidk/s40KcNod83NM4Hn/sbGfyLa8s S0F3ME0S+ocSMOiu/ZHHOiwpLYNbwTJ7stZxGsrguWeT9P+amxbA/YlK95LedstwvN+WcHZ7 d++Arg== Message-ID: <740c8243-395d-61ee-ad64-58557ec99526@wizmail.org> Date: Fri, 5 Apr 2019 11:34:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <155445860706.13142.18114741162189514330@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Pcms-Received-Sender: [2a00:b900:109e:0:855c:1404:1b9d:3a94] (helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-05.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: Fri, 05 Apr 2019 10:34:43 -0000 On 05/04/2019 11:03, internet-drafts@ietf.org wrote: > In TLS handshakes, certificate chains often take up the majority of > the bytes transmitted. > > This document describes how certificate chains can be compressed to > reduce the amount of data transmitted and avoid some round trips. Reducing the number of bytes (and possibly packets) is a good thing, but how does this reduce roundtrips? -- Thanks, Jeremy From nobody Fri Apr 5 04:04: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 A5C091203CE for ; Fri, 5 Apr 2019 04:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_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=ericsson.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 hQ4kQ0yRAVuL for ; Fri, 5 Apr 2019 04:04:02 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00051.outbound.protection.outlook.com [40.107.0.51]) (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 CC59D1203CD for ; Fri, 5 Apr 2019 04:04:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5a1W/QVQc0o3b2nOXfJF32CDtPiZMnMyLKZGqYfYRMU=; b=MWk8jbOCRnwi0vqO8jn2ag67k5XLDLW0KtGJKVwXJ9Fn+LV2UsHpAPitsvvthYT3/UHk6zWGr97fIyGqX4NGA4ISDBt5LQHoh2+JSlFx0/ok9YeBKrb1HMgwWDdnncwDsexT9439uSnjValXAU3QMh8PTvoPPYMNpoPtQOGMf+E= Received: from VI1PR07MB4175.eurprd07.prod.outlook.com (20.176.6.24) by VI1PR07MB5693.eurprd07.prod.outlook.com (20.178.120.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.8; Fri, 5 Apr 2019 11:03:58 +0000 Received: from VI1PR07MB4175.eurprd07.prod.outlook.com ([fe80::6df6:7394:f531:2436]) by VI1PR07MB4175.eurprd07.prod.outlook.com ([fe80::6df6:7394:f531:2436%2]) with mapi id 15.20.1771.011; Fri, 5 Apr 2019 11:03:58 +0000 From: John Mattsson To: Jeremy Harris , "tls@ietf.org" Thread-Topic: [TLS] I-D Action: draft-ietf-tls-certificate-compression-05.txt Thread-Index: AQHU65bmUD0chwOOnEeIC41x2K33zaYtXyQAgAApvgA= Date: Fri, 5 Apr 2019 11:03:58 +0000 Message-ID: <187E4B97-9285-4399-A74A-110886486AD6@ericsson.com> References: <155445860706.13142.18114741162189514330@ietfa.amsl.com> <740c8243-395d-61ee-ad64-58557ec99526@wizmail.org> In-Reply-To: <740c8243-395d-61ee-ad64-58557ec99526@wizmail.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.17.1.190326 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [192.176.1.85] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: af40dd18-0ef5-4963-fcde-08d6b9b66756 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:VI1PR07MB5693; x-ms-traffictypediagnostic: VI1PR07MB5693: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 0998671D02 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(39860400002)(136003)(376002)(366004)(189003)(199004)(13464003)(66066001)(71190400001)(229853002)(71200400001)(97736004)(7736002)(110136005)(14454004)(68736007)(82746002)(14444005)(2501003)(256004)(316002)(966005)(5660300002)(58126008)(25786009)(66574012)(478600001)(305945005)(81166006)(81156014)(8676002)(83716004)(2906002)(6486002)(3846002)(476003)(6512007)(486006)(106356001)(36756003)(53546011)(11346002)(2616005)(6306002)(6506007)(186003)(86362001)(8936002)(76176011)(105586002)(6246003)(6436002)(26005)(446003)(53936002)(99286004)(44832011)(33656002)(6116002)(102836004); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB5693; H:VI1PR07MB4175.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: qh1Q3RfpgTrV3DK6vdifRTlcAmn+xv43yN4jmSG2Or6hnqKsGMh/PQvB4VQsAJyZ/erCNJfANM30CYZPaGlYe8UhvuTLLdLCTX+CGfWtC9qNCtpUdD5Rl6kbbPcfW1CC+6PV4MFBdXl06Ry4n7a+xZdeG+Ts6j0CIFU31zf6cKQi2UGpy+O7LdCPsfkgCvitn+ehjg0ecWmfEi5gk3o2vHUllHyaVtdxg4YObofsNv3zbmxvXUOxUo19rVUiXjoF5QMboce0MUNmCnEou9v5hsAh6v3q3cDE4a1pbsKjLpPKx4VHK/KPZon5tQcGNxnlrBBCfClleCD2hHiSLeOEGJkvgvkE2QO+JcDxk/enloGaHABwDZCkslHmxlEgBwQddM5w9vpYYtJ293xstons5adMCs1EQiOmqeh8gRFoaVI= Content-Type: text/plain; charset="utf-8" Content-ID: <83C5A72ED37C8A419777D8FA2A8BC2A7@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: af40dd18-0ef5-4963-fcde-08d6b9b66756 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2019 11:03:58.6753 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5693 Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-05.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: Fri, 05 Apr 2019 11:04:05 -0000 SWYgZnJhZ21lbnRhdGlvbiBpcyB1c2VkIG9uIHNvbWUgbGF5ZXIsIGxvd2VyaW5nIHRoZSBudW1i ZXIgb2YgYnl0ZXMgY2FuIGRlZmluaXRlbHkgcmVkdWNlIHRoZSBudW1iZXIgb2Ygcm91bmQtdHJp cHMuIFRoaXMgc2hvdWxkIHByb2JhYmx5IGJlIGV4cGxhaW5lZCBhIGJpdCBtb3JlLg0KDQpJZiB1 c2VkIGluIGFueSBvZiB0aGUgVExTIGJhc2VkIEVBUCBtZXRob2RzLCB0aGUgdXNlIG9mIGNvbXBy ZXNzaW9uIG1heSBldmVuIGJlIG5lZWRlZCB0byBtYWtlIHRoZSBoYW5kc2hha2UgY29tcGxldGUg YXQgYWxsIGFzIG1hbnkgYWNjZXNzIHBvaW50cyBkcm9wIEVBUCBjb25uZWN0aW9ucyBhZnRlciA0 MC01MCBwYWNrZXRzLg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1zLWVtdS1l YXB0bHNjZXJ0LTAyDQoNCkpvaG4NCg0K77u/LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IFRMUyA8dGxzLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBKZXJlbXkgSGFycmlz IDxqZ2hAd2l6bWFpbC5vcmc+DQpEYXRlOiBGcmlkYXksIDUgQXByaWwgMjAxOSBhdCAxMjozNQ0K VG86ICJUTFNAaWV0Zi5vcmciIDx0bHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1RMU10gSS1E IEFjdGlvbjogZHJhZnQtaWV0Zi10bHMtY2VydGlmaWNhdGUtY29tcHJlc3Npb24tMDUudHh0DQoN CiAgICBPbiAwNS8wNC8yMDE5IDExOjAzLCBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgd3JvdGU6 DQogICAgPiAgICBJbiBUTFMgaGFuZHNoYWtlcywgY2VydGlmaWNhdGUgY2hhaW5zIG9mdGVuIHRh a2UgdXAgdGhlIG1ham9yaXR5IG9mDQogICAgPiAgICB0aGUgYnl0ZXMgdHJhbnNtaXR0ZWQuDQog ICAgPiANCiAgICA+ICAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGhvdyBjZXJ0aWZpY2F0ZSBj aGFpbnMgY2FuIGJlIGNvbXByZXNzZWQgdG8NCiAgICA+ICAgIHJlZHVjZSB0aGUgYW1vdW50IG9m IGRhdGEgdHJhbnNtaXR0ZWQgYW5kIGF2b2lkIHNvbWUgcm91bmQgdHJpcHMuDQogICAgDQogICAg UmVkdWNpbmcgdGhlIG51bWJlciBvZiBieXRlcyAoYW5kIHBvc3NpYmx5IHBhY2tldHMpIGlzIGEg Z29vZCB0aGluZywNCiAgICBidXQgaG93IGRvZXMgdGhpcyByZWR1Y2Ugcm91bmR0cmlwcz8NCiAg ICAtLSANCiAgICBUaGFua3MsDQogICAgICBKZXJlbXkNCiAgICANCiAgICBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIFRMUyBtYWlsaW5nIGxpc3QN CiAgICBUTFNAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3Rscw0KICAgIA0KDQo= From nobody Fri Apr 5 04:44: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 14C621203D4 for ; Fri, 5 Apr 2019 04:44:56 -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_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=ducksong.com header.b=FG060byb; dkim=pass (2048-bit key) header.d=outbound.mailhop.org header.b=aUrQNuK6 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQFY4VU6AwgZ for ; Fri, 5 Apr 2019 04:44:53 -0700 (PDT) Received: from outbound2r.ore.mailhop.org (outbound2r.ore.mailhop.org [54.200.129.228]) (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 0F754120013 for ; Fri, 5 Apr 2019 04:44:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554464692; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=SYzM/VyYWHGKlDw4dnBiaAY+QZ0hQqlZQilm/tQwtPZx3ErPd1Go7LoLxbgr5PvnH2rNN74/i7yZ8 c9Ix3o3C5lmt0mWnh1AJhGCiXqRHJVgao8L96LfMwRKq7FpCXi4+wjyKAyH5C3pG4d4dUrB440xtWt AE1EYCMQEv1IbfqrukeP2Id0jvOx9wM5lA6oqB9SHkTuJT2YGR7Mb+UiW+0pQ7OlJLl1ZnBR0qdoqR 7ryFJAP0l9CMIgiyWdLvj1gfgDnNiewuwrdt/T6QUHTvZt0TvRxXEXnq1zOn8a6XwqVkv4TRtKXsDJ IjULj+AnSwKowTqCzrwwYMoUGd1T6XA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:dkim-signature:dkim-signature:from; bh=kC9XHZYXdbn2sKtuGqByBtfaqx43Dyn0nwvv3myMsNc=; b=LSPKReUgNEPLWCyKaVz4Izn6dIczkm6w4JlonHD9q5Utanw4qL5Be4MAn9n0ASIa46800WvMtZZj/ YqoY1RMyU2AUl2BADgD1iSS/fyfCrKhi7B1wNrro55vIwk2zrNDjsxbQmWRoIdFvv9eVa3iGNs7/pO vy9UQp6I/QDCUMNIO2a725e8dPw8AuccFAm04QkxAA7Vj3n0jrfArlY7+rmxNHNjlqEOXQeSiE20HO nVGTtFsP2nuPYgApaWabhH2bmW6a0JjwIdUTUcEF7/9TnPPfPoVsv7kYLbN78v1xCm34dLuTugHPYS vvS2NnV2VE1VJO8Kkv4GYRM7F6Wibgw== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=pass smtp.mailfrom=ducksong.com smtp.remote-ip=209.85.210.43; dmarc=none header.from=ducksong.com; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ducksong.com; s=duo-1537391512170-ea99bbb3; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=kC9XHZYXdbn2sKtuGqByBtfaqx43Dyn0nwvv3myMsNc=; b=FG060byb+ZcFSUSKHwYs9UY25bCQkMNwVf0Zqpvpm++3PTD5KEzYIwtKHmNjsRGwZT7RrFUteBvSk lS27DReOMZ4JMRl/DbDTVugVXzZaV7As4U/CPqBHg7EqASwfY3on4vV6sonhLNmzj+o1JmNC4ojvpM cx4aUnioqqZPUv/k= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=kC9XHZYXdbn2sKtuGqByBtfaqx43Dyn0nwvv3myMsNc=; b=aUrQNuK6T//D54FtjxbqXMGNxdvMX5fM5w+H+VGWmaiTAxJ9xaIeUrh08RlvxRPfWj4R9ChBQkVKM iNJFRje32NOh7S+QP5EH4KVnde0BuItSRw4QUHafNEyJiYmMD7d+4PLpr2XYYe88NeD0mARWVVK9Aa w79qQ79JmhFlOdZ2fbCp9y+jXzOHADsrZrPe04BvRv8BYME5SpzAxlQNOhcal90tUl8FVaXcU3Fb2E jrr4vWznu6K3/iBCciNlgZbbY4yX+ny2F3SmjyYgJVBmk368rNN0LZKixkGi5UgwXI/fYjdxbA0GuW /bRSvv4elg6b7hHVskM0P+C0GlagUgw== X-MHO-RoutePath: bWNtYW51cw== X-MHO-User: 383f797f-5798-11e9-befd-af03bedce89f X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 209.85.210.43 X-Mail-Handler: DuoCircle Outbound SMTP Received: from mail-ot1-f43.google.com (unknown [209.85.210.43]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id 383f797f-5798-11e9-befd-af03bedce89f; Fri, 05 Apr 2019 11:44:50 +0000 (UTC) Received: by mail-ot1-f43.google.com with SMTP id j10so5366572otq.0 for ; Fri, 05 Apr 2019 04:44:50 -0700 (PDT) X-Gm-Message-State: APjAAAXaIwPSJjMcCeeF70EIg9hMFx8O746osTEZ9O+gzxtwK6ljdqKk WZWGsvQfEDZAKrn7Lj77QI1sb2D8eWXv21Dpbbc= X-Google-Smtp-Source: APXvYqys9fOqzdQNpimFFn+0tVsTrsPJ5l2AAs9n1WX92qSlnkIT20RTbRDAkk7HFfuF5EYWg2K7XjhYIRdRKBpxEtY= X-Received: by 2002:a9d:2c28:: with SMTP id f37mr8247963otb.126.1554464690037; Fri, 05 Apr 2019 04:44:50 -0700 (PDT) MIME-Version: 1.0 References: <155445860706.13142.18114741162189514330@ietfa.amsl.com> <740c8243-395d-61ee-ad64-58557ec99526@wizmail.org> <187E4B97-9285-4399-A74A-110886486AD6@ericsson.com> In-Reply-To: <187E4B97-9285-4399-A74A-110886486AD6@ericsson.com> From: Patrick McManus Date: Fri, 5 Apr 2019 13:44:37 +0200 X-Gmail-Original-Message-ID: Message-ID: To: John Mattsson Cc: Jeremy Harris , "tls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000aa67e40585c70346" Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-05.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: Fri, 05 Apr 2019 11:44:56 -0000 --000000000000aa67e40585c70346 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable also congestion control interaction will typically cause more bytes to incur extra round trips - especially early in the connection. On Fri, Apr 5, 2019 at 1:04 PM John Mattsson wrote: > If fragmentation is used on some layer, lowering the number of bytes can > definitely reduce the number of round-trips. This should probably be > explained a bit more. > > If used in any of the TLS based EAP methods, the use of compression may > even be needed to make the handshake complete at all as many access point= s > drop EAP connections after 40-50 packets. > https://tools.ietf.org/html/draft-ms-emu-eaptlscert-02 > > John > > =EF=BB=BF-----Original Message----- > From: TLS on behalf of Jeremy Harris < > jgh@wizmail.org> > Date: Friday, 5 April 2019 at 12:35 > To: "TLS@ietf.org" > Subject: Re: [TLS] I-D Action: > draft-ietf-tls-certificate-compression-05.txt > > On 05/04/2019 11:03, internet-drafts@ietf.org wrote: > > In TLS handshakes, certificate chains often take up the majority > of > > the bytes transmitted. > > > > This document describes how certificate chains can be compressed > to > > reduce the amount of data transmitted and avoid some round trips= . > > Reducing the number of bytes (and possibly packets) is a good thing, > but how does this reduce roundtrips? > -- > Thanks, > Jeremy > > _______________________________________________ > 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 > --000000000000aa67e40585c70346 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
also congestion control interaction will typically cause m= ore bytes to incur extra round trips - especially early in the connection.<= /div>
O= n Fri, Apr 5, 2019 at 1:04 PM John Mattsson <john.mattsson@ericsson.com> wrote:
If fragmentation is used on so= me layer, lowering the number of bytes can definitely reduce the number of = round-trips. This should probably be explained a bit more.

If used in any of the TLS based EAP methods, the use of compression may eve= n be needed to make the handshake complete at all as many access points dro= p EAP connections after 40-50 packets.
https://tools.ietf.org/html/draft-ms-emu-eaptl= scert-02

John

=EF=BB=BF-----Original Message-----
From: TLS <tls= -bounces@ietf.org> on behalf of Jeremy Harris <jgh@wizmail.org>
Date: Friday, 5 April 2019 at 12:35
To: "TLS@ietf.org" <tls@ietf.org<= /a>>
Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-05.tx= t

=C2=A0 =C2=A0 On 05/04/2019 11:03, internet-drafts@ietf.org wrote:
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 In TLS handshakes, certificate chains often= take up the majority of
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 the bytes transmitted.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 This document describes how certificate cha= ins can be compressed to
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 reduce the amount of data transmitted and a= void some round trips.

=C2=A0 =C2=A0 Reducing the number of bytes (and possibly packets) is a good= thing,
=C2=A0 =C2=A0 but how does this reduce roundtrips?
=C2=A0 =C2=A0 --
=C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 Jeremy

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


_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000aa67e40585c70346-- From nobody Fri Apr 5 13:18: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 3F45F1200A4 for ; Fri, 5 Apr 2019 13:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 QYXo5iP9NoZT for ; Fri, 5 Apr 2019 13:18:48 -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 7CF8D120092 for ; Fri, 5 Apr 2019 13:18:48 -0700 (PDT) Received: by mail-qk1-x72d.google.com with SMTP id y5so4600918qkc.11 for ; Fri, 05 Apr 2019 13:18:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=0F0V3XrM6wTczJ0AUKcu9cagSKYVAki4ppieBnny6FU=; b=okRggJzSerkn3nb3CRTQ9gRrX1GuZtmlks/7LFimSE/OMEu36OzwU12oXB3MhJsK6R M/V+6RwueTeVharSK7JpX1ttpcLy+gFY239lhMihu3iZzbZYyxdA03llORvdmt0AyHRs /eVP7Q1S8E62/PEHVZVDx8+RQUYf8WQWcfMQ8Lg4YGliE3jQkhFUZ9aNfzvM9jOGVBJc DfWz0ZYPpS6fZejLkiqIBJXatxeNXau48i5Nd0JO9h1jzwgI7tfAc0Tu2WxwINXKdJdB PVEBSRnEqNUxnpfnrha9QutasSAzmD7488E/+8iPUwhuO7lL5zyjExWTJ+qZi6YAanwm tF0w== 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=0F0V3XrM6wTczJ0AUKcu9cagSKYVAki4ppieBnny6FU=; b=qjphsFZRrZ30J9zUY0ltADE6M+qm2xqYPAT+De5VF++HUymCyIDfZUl4FtjkxvwVcW YmFu6LBfT/kwF4E5aXkGde70q7tP92PT9VnZFbtquVmdvIMnAOmmwZdoWi6HLs3NTca2 pm/83AzqPk1hrooPOWGZsaU+NjWMvg/wuO1zGaM8Ekfu7QWOWkvSg80CJOrZd+4yfQNk jFCqkUzsmmwo6tjq5NfnKRRozMWBpWOUsGAhWwsnXZRcAb/vgEAFQLxaekXXV8uPUHj1 PjlOeEJ6eoVrg0HKTmerKT0T9H+X3O2WJPSeSanbUL3Y7SXcU4BpzCj7oESXpHt24M9d AlWw== X-Gm-Message-State: APjAAAXBbhd4mEFDBnFP17q+v/xqLHIEJyqJwNs/7KOWqsKXzcTR+RAY dhadt+46WDECC7rMJTOxyIOIgo26Yy7JgMz2hfWsvqp5QTsJ6g== X-Google-Smtp-Source: APXvYqyFOJZ6ZPwwTgnvXeDSV6/vOlrG1akE1QIt00UCjyIdiH+16AfB3XqTEv9FpwR2Ghcv0hO5TprCjmNETHzRrZo= X-Received: by 2002:a37:6381:: with SMTP id x123mr8408303qkb.110.1554495527314; Fri, 05 Apr 2019 13:18:47 -0700 (PDT) MIME-Version: 1.0 From: Joseph Salowey Date: Fri, 5 Apr 2019 13:18:36 -0700 Message-ID: To: "" Content-Type: multipart/alternative; boundary="000000000000b5fbe40585ce31f3" Archived-At: Subject: [TLS] early code-point assignment request for draft-ietf-tls-dtls-connection-id-04 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, 05 Apr 2019 20:18:50 -0000 --000000000000b5fbe40585ce31f3 Content-Type: text/plain; charset="UTF-8" We have received a request for early code-point assignment of values for draft-ietf-tls-dtls-connection-id-04. We believe that only editorial changes are pending. Please respond to this list of you have concerns about these assignments by April 12, 2019. Thanks, Joe, Sean and Chris --000000000000b5fbe40585ce31f3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We have = received a request for early code-point assignment of values for draft-ietf= -tls-dtls-connection-id-04.=C2=A0 We believe that only editorial changes ar= e pending. Please respond to this list of you have concerns about these ass= ignments by April 12, 2019.=C2=A0=C2=A0

Thanks,

Joe, Sean and Chris=
--000000000000b5fbe40585ce31f3-- From nobody Mon Apr 8 17:52:39 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 21A581201D1 for ; Mon, 8 Apr 2019 17:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=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 uDM4giPVXWQp for ; Mon, 8 Apr 2019 17:52:36 -0700 (PDT) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 529E512018E for ; Mon, 8 Apr 2019 17:52:36 -0700 (PDT) Received: by mail-qt1-x836.google.com with SMTP id w5so17781192qtb.11 for ; Mon, 08 Apr 2019 17:52:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=WOZ5BBCt3Nmr+r7+9s6FOTsY47e5HDqC5xwN1oJrI0s=; b=GK2eQuxpk86SjbWvW8ncmGPhWkWeHEWsauM+MUXaQ2wXYxlKsX7t4XhS7XuO3+jGvq 5OhziCD9FfNz7WeP8X+dXPUbput/VVrBbmBXZbX9ZVwuYpRHeXshT1RGh3dZtC1iUWca TADjnhf3kDMmYTtZCUbvMEVngUXDM70VQwInU= 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:message-id:date:to; bh=WOZ5BBCt3Nmr+r7+9s6FOTsY47e5HDqC5xwN1oJrI0s=; b=Nadh6En6c0ux/W8mIryjMWFlR3M/YLiU9jgI3GNbODJzg/vQjI3V5+Q4QyoSTRq3Qd eZtx7ygENAjm0DUIBNbwO8Eh7EYxPIGmDU1Uk7kiahkVxqLY/5VGQzTb60eg8BwgWm6l PbxyyyXyD1Lyr0/+4XvVj+9YlPa+o5AHA797sdWVHqJhpzbApgHMZ5SrYtknUuJBg77P WbifpC4oexQydecmUWIozby9sSaKfUGWFwNYcuY+FxfT6tuNKvNhSP3ARKJkQEcFysTH nWIU688KnseTLw27sQeSpnu7F8U51JmBgDaD5VvGvIPQde1wcsQRsGPOeQ3si2zduFjG Wqdg== X-Gm-Message-State: APjAAAXdUjlhZQ39hbWlWbOjgFDHL7s7t7jHCuIKv4/yaVYN0o5ksh5L eHP+5irR5CoqJgmPJi+KgdzHzDr/Xhw= X-Google-Smtp-Source: APXvYqyHqavwLhTRpLy6BLawguozGBDwLslmvgxZaVLy2d9hhZJrw6uu3XR5+S9J7CL2aKSar4teNA== X-Received: by 2002:a0c:8199:: with SMTP id 25mr27211663qvd.76.1554771155345; Mon, 08 Apr 2019 17:52:35 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.36]) by smtp.gmail.com with ESMTPSA id w18sm26512732qta.2.2019.04.08.17.52.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Apr 2019 17:52:34 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Message-Id: Date: Mon, 8 Apr 2019 20:52:33 -0400 To: TLS List X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: [TLS] WGLC for draft-ietf-tls-certificate-compression 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, 09 Apr 2019 00:52:38 -0000 This is the working group last call for the "TLS Certificate = Compression=E2=80=9D draft available at = https://datatracker.ietf.org/doc/draft-ietf-tls-certificate-compression/. Please review the document and send your comments to the list by 2359 = UTC on 22 April 2019. Issue and PRs can also be filed in the GH repo for this draft, which can = be found here: https://github.com/tlswg/certificate-compression Thanks, Chris, Joe, and Sean= From nobody Mon Apr 8 17:56: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 BA63C120188 for ; Mon, 8 Apr 2019 17:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 2YP-uYwx7jOc for ; Mon, 8 Apr 2019 17:56:48 -0700 (PDT) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08F9612003E for ; Mon, 8 Apr 2019 17:56:48 -0700 (PDT) Received: by mail-qt1-x831.google.com with SMTP id z17so17771763qts.13 for ; Mon, 08 Apr 2019 17:56:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=8j4KvZ1Z/zcCwKCxal6ssEa4sX53V+S0rgxnqfZGsxM=; b=dfETk7zFjxc292cauiFecjiAEpMmgpEoueoniFmyODyORuHYdviv05Uv6PTeGdRdL6 Rxwvte5I17UEb24mNgboFI/O5rToEWsf7oqpR24H3olOEw6fvRzB09KkCUZ92RAQB0us cDFOqkzwVVDhfELlplkzBlT8Nf08HpDISw8Co= 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:message-id:date:to; bh=8j4KvZ1Z/zcCwKCxal6ssEa4sX53V+S0rgxnqfZGsxM=; b=Z9zSQOBAovWnkd14mi+78ks/7uHKhpAJgv8bOBjl1ELZmme8fCCU/2RElk/9fn3Bq+ MLoW6YvRh4dOarDXsJKMs2EibRk7X9WrIrILAvdj0UhFvozHO4I+U9yAktYwp+hPwgdM Lr3/2eYeqDKZ417BlDYF8Hi/6cbt5RRijci/lBYDv5edxmxcvMA4jKLCnZaOBx8nr+cn /mmFatLvBH+st8IvzK3K27apDO40fI5HyHWYqEYzL2U+VoayRNRv0O/Cyz7HJfUzQkp8 20nPu6M5B3Pqwg+yE0U+V0YYu7ReQEHeCIw4Su/NnihkePO8khATL6ZSMBK85eyxcvyh ftAw== X-Gm-Message-State: APjAAAU25zC+dAAfBsDIKWhxC58dtxGRKEe8O2LVdBW8rZrNnoI6mYfc /9gU/oBKAHi6LD/9qd2B482xgCfAy90= X-Google-Smtp-Source: APXvYqyZooggEXJfc+QcKiRgjwz8nA+IZV/uhz6x5V2kSn4hjuP+nQl8iVXjHFbyn53rTP7r2zN66A== X-Received: by 2002:a0c:afa2:: with SMTP id s31mr26479334qvc.118.1554771407079; Mon, 08 Apr 2019 17:56:47 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.36]) by smtp.gmail.com with ESMTPSA id l59sm18849975qte.6.2019.04.08.17.56.46 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Apr 2019 17:56:46 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Message-Id: Date: Mon, 8 Apr 2019 20:56:45 -0400 To: TLS List X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: [TLS] WG adoption call: draft-wood-tls-external-psk-importer 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, 09 Apr 2019 00:56:50 -0000 At TLS@IETF104, there was consensus in the room to adopt = draft-wood-tls-external-psk-importer. This message is to confirm that = consensus. If you do not support adoption of = draft-wood-tls-external-psk-importer as WG item please say so by 2359UTC = on 22 April 2019 (and say why). Thanks, Joe and Sean= From nobody Mon Apr 8 17:57:33 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 CAE741201E2; Mon, 8 Apr 2019 17:57:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155477145082.30014.4292813340548820527.idtracker@ietfa.amsl.com> Date: Mon, 08 Apr 2019 17:57:30 -0700 Archived-At: Subject: [TLS] The TLS WG has placed draft-wood-tls-external-psk-importer in state "Call For Adoption By WG Issued" 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, 09 Apr 2019 00:57:31 -0000 The TLS WG has placed draft-wood-tls-external-psk-importer in state Call For Adoption By WG Issued (entered by Sean Turner) The document is available at https://datatracker.ietf.org/doc/draft-wood-tls-external-psk-importer/ From nobody Mon Apr 8 20:45: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 59F331206B0 for ; Mon, 8 Apr 2019 20:45:13 -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=lowentropy.net header.b=UNohQKt0; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=iOlKmZlL Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pdm_i999yFkU for ; Mon, 8 Apr 2019 20:45:12 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E42DB1206B7 for ; Mon, 8 Apr 2019 20:44:58 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 7AB39B22 for ; Mon, 8 Apr 2019 23:44:58 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Mon, 08 Apr 2019 23:44:58 -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 :subject:content-type; s=fm1; bh=eDudfXJPz/lYyUkhjYsfXELfM7llShT in0qyrHyrvDg=; b=UNohQKt0KpGtikVKMeq8POdyffsQIXRlPQ4qMtbP+Jbi1VA +e+/VPec9zKp5Ebi9zrXgeZx4PmmnkoBw2/BT0VSP7G+dwcgDO6/NkfB2PTjmcmP yRJpwVN3c1gxxodzhh/oxjMoog7g8u4aYguwqjP26IoUcFKWxcV07Hr1F86TEoxX Id7mfZsudbgiE/T560Db7FdFwGnTpkNMjtxwkuJbjCnrml1HPPxDjlJQw93uLoY4 QLs+Xwrrm7evRLyBrin2B6CNmHhFlDxlK5H+KTRDOfGcvF2/mv1mmbVsvs+tBH4n xqpDZJraYTgKqLj+rrWSAr2BmSq2x3k4dS0XKAg== 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=fm2; bh=eDudfX JPz/lYyUkhjYsfXELfM7llShTin0qyrHyrvDg=; b=iOlKmZlLY53ezizjOD5lTc l7CYSoBAG0gaTjj5ODqMBNevecSDoEJrPf0vGHOIE1af4FRs9v4BaEPd5SisMSC6 jZyoz4tzqq3/JXHlE03ZufHBxM84mYnhMaigqdE+HxHwXDqGW6QjsxJdxcoURxd8 ru4vUuk565UdFNdIE6I2XaZGE1OVQiqpvrwzs7oMO2hj49zXynFaP7A107+yGf63 CYULf3su1A1yPkzNSbsjbN5KjblRIs4fLkucSgeqXX19Ntybz9cxkwZ81VsKSrAU +Lxch+WAFIlrfC85kGVeY/yqY3nb+8SjeMqch2IaDfffPDorEciwb+RcIRRifzoA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudeggdejvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehivghtfhdrohhrghenucfrrghrrg hmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvthenucevlhhushht vghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id C102B7C1B9; Mon, 8 Apr 2019 23:44:57 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-329-gf4aae99-fmstable-20190329v1 Mime-Version: 1.0 X-Me-Personality: 92534000 Message-Id: In-Reply-To: References: Date: Mon, 08 Apr 2019 23:44:58 -0400 From: "Martin Thomson" To: tls@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [TLS] WG adoption call: draft-wood-tls-external-psk-importer 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, 09 Apr 2019 03:45:13 -0000 Adopt. On Tue, Apr 9, 2019, at 10:57, Sean Turner wrote: > At TLS@IETF104, there was consensus in the room to adopt > draft-wood-tls-external-psk-importer. This message is to confirm that > consensus. If you do not support adoption of > draft-wood-tls-external-psk-importer as WG item please say so by > 2359UTC on 22 April 2019 (and say why). > > Thanks, > Joe and Sean > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Mon Apr 8 22:45:18 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 7A00C120730 for ; Mon, 8 Apr 2019 22:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nomountain-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 00SgNGoaNqg8 for ; Mon, 8 Apr 2019 22:45:14 -0700 (PDT) Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BAF612071D for ; Mon, 8 Apr 2019 22:45:14 -0700 (PDT) Received: by mail-pf1-x42b.google.com with SMTP id 8so9022166pfr.4 for ; Mon, 08 Apr 2019 22:45:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=giKvDDQc0JRuKwo1f13DGmLyaLCyZj9eteJcQU3Z8QE=; b=cakVVMuWhlki2mZunKdMbrpkA0FhNxzQrqgkKNMfP++ZhEtDsa3D9J/KiYkJ212ocM VhRTwRwMGcfBbBNxBkysg6wD019C+0Y+Isy8DNH+IgquOU2WbAwvYJk7YNDnWjnxSqwY Hci0JgFBMcven6UTSvJdrVPQRfJ0TjSgFhPS0437bXF9V/FqhA5qhhWjui7II+WceX0w WSffydGM5iarGpuZQR2UHpQk0NtpD0387j25idz8xfwczAUsLRFSa5JX048mcxaiUnaW 2UIOCxqwyfYXxWA1xsj6AKXr3fV5WeNDcTvKs8Z9iXbsP49vhjE30QUSyyaLFqBmxwi2 v1bQ== 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 :content-transfer-encoding; bh=giKvDDQc0JRuKwo1f13DGmLyaLCyZj9eteJcQU3Z8QE=; b=MU+EC5PzKKhybXgg94OwS9bHzqRzXxJ8ZRKS6AI6N++c28xcES9COGk09LeERvJepM wUUc5TuGTnMWffw9NcB3aSTit9JFdnzFvlQS5cXj9S+Pc1gpwxHdUnyuL1HB6BY/kTMx GcNcy5kWoCxZwg+iUbeatfc90ovKOPkTuHMlHkbAkKfwFZ78GMuAMyHqKYBar3677UmU X9tJYJtARwb7C1nnYZUStZORFMLMC1yBPwuUAfwLxjvOEMlf0+mlBo8F456v8no4uhqd BN+WQhh+clnQHF6OGcbCsbqETd7KfMGyyiXfOky26IcwnXY709wMfMsmaQ22ykG3s5OF d5mQ== X-Gm-Message-State: APjAAAV7K/PZbEXWWyZ8n0eGd+9tSnyCV7pfrHKd6aHXFNEhM3NYgHzf qsD9n8mAasRWCFvHmp1OdEzrQnFrhA== X-Google-Smtp-Source: APXvYqxmi5+Dp5EAETZvKZ7zXy/EERoOEpOZnOOFX8tHfUKIRLekM9wABO8CnKltZfZrflzMNzbVLw== X-Received: by 2002:a63:4144:: with SMTP id o65mr30996034pga.241.1554788713499; Mon, 08 Apr 2019 22:45:13 -0700 (PDT) Received: from aspen.local ([216.67.81.206]) by smtp.gmail.com with ESMTPSA id b1sm21852pgq.15.2019.04.08.22.45.12 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Apr 2019 22:45:13 -0700 (PDT) To: tls@ietf.org References: From: Melinda Shore Message-ID: <7d640638-c1eb-b430-e084-e3808220ab88@nomountain.net> Date: Mon, 8 Apr 2019 21:45:11 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] WG adoption call: draft-wood-tls-external-psk-importer 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, 09 Apr 2019 05:45:16 -0000 On Tue, Apr 9, 2019, at 10:57, Sean Turner wrote: > At TLS@IETF104, there was consensus in the room to adopt > draft-wood-tls-external-psk-importer. This message is to confirm that > consensus. If you do not support adoption of > draft-wood-tls-external-psk-importer as WG item please say so by > 2359UTC on 22 April 2019 (and say why). I support adoption. Melinda -- Melinda Shore melinda.shore@nomountain.net Software longa, hardware brevis From nobody Tue Apr 9 11:53: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 117D312031F for ; Tue, 9 Apr 2019 11:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_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=ericsson.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 Iykii1yxb-NM for ; Tue, 9 Apr 2019 11:53:13 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10051.outbound.protection.outlook.com [40.107.1.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C1D212031E for ; Tue, 9 Apr 2019 11:53:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mfh8N2Gezak0LGDF3WlL6/WYdBa2JZ+5JCJK4iHSFUU=; b=DucmapYzbCWY3j3TAFWDMQjsfwFPe/mKHcR06M4mC2GwL5sMGJJscS6xnOvCM79OCKMov54FrEH+dzOlU5h08Z3Fy3yqI4jzjx6EdNiq6/esD1etq8AcILcPh6x2rrfY9RVdzOGZZdFysbrQ7ZFi9bvilDokpYXgX8mUduF97Z4= Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.166.22) by HE1PR07MB3323.eurprd07.prod.outlook.com (10.170.247.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.7; Tue, 9 Apr 2019 18:53:09 +0000 Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::d49e:f22a:1e0b:f888]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::d49e:f22a:1e0b:f888%5]) with mapi id 15.20.1792.007; Tue, 9 Apr 2019 18:53:09 +0000 From: John Mattsson To: Christopher Wood , "TLS@ietf.org" Thread-Topic: [TLS] Comments on draft-wood-tls-external-psk-importer-01 Thread-Index: AQHU6L09RDZKHT8Ksk2niB+rgTbbFKYqgKOAgAEs9wCAAE3AgIAABQOAgAhaoQA= Date: Tue, 9 Apr 2019 18:53:09 +0000 Message-ID: <008538AB-FBE0-4132-A9FD-18BAE1F3F4FC@ericsson.com> References: <89127FF7-CE3F-4DF1-98A5-B1006C5FF56B@ericsson.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.17.1.190326 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [82.214.46.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a4282130-19d9-482c-2b6e-08d6bd1c9bf3 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600139)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:HE1PR07MB3323; x-ms-traffictypediagnostic: HE1PR07MB3323: x-microsoft-antispam-prvs: x-forefront-prvs: 000227DA0C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(136003)(39860400002)(376002)(366004)(346002)(189003)(199004)(51914003)(13464003)(2616005)(446003)(7736002)(82746002)(229853002)(8936002)(44832011)(14454004)(97736004)(2501003)(316002)(26005)(186003)(478600001)(476003)(68736007)(33656002)(11346002)(71190400001)(81166006)(8676002)(966005)(81156014)(2906002)(93886005)(36756003)(71200400001)(6436002)(6486002)(83716004)(105586002)(58126008)(106356001)(86362001)(25786009)(99286004)(6246003)(30864003)(5660300002)(6512007)(53936002)(3846002)(6116002)(66066001)(6306002)(53946003)(6506007)(102836004)(486006)(256004)(76176011)(53546011)(110136005)(54896002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3323; H:HE1PR07MB4169.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: cPYb2wgIuF+WRPG8xQ+368Nlci9gWIiPTMGE5ODfdfrAr/AzGhcDnc/OJ22eEs7+GwMAkhMOG7MXMC9OamREhoLJoguXO32dvbqHAmqAF/5KceCJqpTn4qt5gN+s8ugINSDjVasn1lbeXEPDXoKHuwYP/z54wQ+WIxMhMXSsBFXt3tNaFWl+nJmtpoAann8iXLK5VJwymA60md69YSD1TDgbD7PY4QbkoIaAyZYGR5S5Oj8tYahrAMKAA8R30ftzjUf+dpiiJ3n46byR8eu5+t/zUDQaprA9Ga61iVDuauX98QuD+hSydC2e8Dhi2RWr81eK62cYctOgCAV1smqqt51V3Xzb3AGV/ik8lZs44g3fPICoXnqCHJMl5D8dct1rrUY8sM3WvafNDYQ/34krzei9hiGudQ5AVITruqEAiOU= Content-Type: multipart/alternative; boundary="_000_008538ABFBE04132A9FD18BAE1F3F4FCericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: a4282130-19d9-482c-2b6e-08d6bd1c9bf3 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2019 18:53:09.2222 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3323 Archived-At: Subject: Re: [TLS] Comments on draft-wood-tls-external-psk-importer-01 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, 09 Apr 2019 18:53:18 -0000 --_000_008538ABFBE04132A9FD18BAE1F3F4FCericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQ2hyaXMsDQoNClRoYW5rcyBmb3IgdGhlIGRpc2N1c3Npb24uIFdvdWxkIGJlIGdvb2QgaWYg YSBmdXR1cmUgdmVyc2lvbjoNCg0KLSBNYWRlIGNsZWFyIGlmIHRoZSBpbXBvcnRlZCBQU0tzIE1V U1QgTk9UIC8gU0hPVUxEIE5PVCAvIE1BWSAvIFNIT1VMRCAvIE1VU1QgYmUgb2ZmZXJlZCBhbG9u Z3NpZGUgdGhlIGV4aXN0aW5nIGV4dGVybmFsIFBTS3MuIFdoaWxlIG9mZmVyaW5nIGJvdGggd291 bGQgbWFrZSBhIG1pZ3JhdGlvbiBwYXRoIHBvc3NpYmxlIEkgZG9u4oCZdCB0aGluayBpdCBpcyB0 aGUgd2F5IHRvIGdvLg0KLSBJZiBNVVNUIE5PVCwgdGhlIGRvY3VtZW50IHNob3VsZCBtYXliZSBh bHNvIHN0YXRlIHdoYXQgdGhlIGNsaWVudCBkbyBpZiBpdCByZWNlaXZlcyBhIHVua25vd25fcHNr X2lkZW50aXR5IGFsZXJ0LCBpcyBpdCBhbGxvd2VkIHRvIHRyeSBhZ2FpbiB3aXRoIHRoZSBleHRl cm5hbCAobm9uLWltcG9ydGVkIGlkZW50aXR5KSBvciBpcyBpdCBmb3JiaWRkZW4gdG8gZG8gc28/ DQoNCi0gTWFkZSBjbGVhciBpZiB1c2Ugb2YgZHJhZnQtd29vZC10bHMtZXh0ZXJuYWwtcHNrLWlt cG9ydGVyIGlzIGEgcHJvcGVydHkgb2YgdGhlIFRMUyBpbXBsZW1lbnRhdGlvbiAoaS5lLiB1c2Vk IG9uIGFsbCBQU0spIG9yIGEgcHJvcGVydHkgb2YgdGhlIGV4dGVybmFsIFBTSyAoaS5lLiBvbmx5 IHVzZWQgb24ga2V5cyB3aXRoIHRoaXMgcHJvcGVydHkpLg0KDQotIFN0YXRlIHRoYXQgInRsczEy IiBpcyB1c2VkIGZvciBEVExTIDEuMiBhbmQgInRsczEzIiBpcyB1c2VkIGZvciBEVExTIDEuMy4N Cg0KQ2hlZXJzLA0KSm9obg0KDQpGcm9tOiBUTFMgPHRscy1ib3VuY2VzQGlldGYub3JnPiBvbiBi ZWhhbGYgb2YgQ2hyaXN0b3BoZXIgV29vZCA8Y2F3QGhlYXBpbmdiaXRzLm5ldD4NCkRhdGU6IFRo dXJzZGF5LCA0IEFwcmlsIDIwMTkgYXQgMTU6MTkNClRvOiAiVExTQGlldGYub3JnIiA8dGxzQGll dGYub3JnPg0KU3ViamVjdDogUmU6IFtUTFNdIENvbW1lbnRzIG9uIGRyYWZ0LXdvb2QtdGxzLWV4 dGVybmFsLXBzay1pbXBvcnRlci0wMQ0KDQoNCg0KT24gVGh1LCBBcHIgNCwgMjAxOSwgYXQgNjow MSBBTSwgQ2hyaXN0b3BoZXIgV29vZCB3cm90ZToNCg0KDQpPbiBXZWQsIEFwciAzLCAyMDE5LCBh dCAxMToyMiBQTSwgSm9obiBNYXR0c3NvbiB3cm90ZToNCj4gSGkgQ2hyaXN0b3BoZXIsDQo+DQo+ IFRoYW5rcyBmb3IgdGhlIGNsYXJpZmljYXRpb25zLg0KPg0KPiA+WW914oCZcmUgY29ycmVjdCB0 aGF0IHRoaXMgcmVxdWlyZXMgYm90aCBlbmRwb2ludHMgdG8gYWRvcHQgdGhlIGNoYW5nZQ0KPiA+ c2ltdWx0YW5lb3VzbHkuIEhvd2V2ZXIsIHRoYXQgZG9lcyBub3QgY29udHJhZGljdCB0aGUgcXVv dGVkIHRleHQsIHdoaWNoDQo+ID5zdGF0ZXMgdGhhdCB0aGUgcHJvdG9jb2wgaXMgbm90IGNoYW5n ZWQuDQo+DQo+IEkgdGhpbmsgInRoaXMgcmVxdWlyZXMgYm90aCBlbmRwb2ludHMgdG8gYWRvcHQg dGhlIGNoYW5nZSBzaW11bHRhbmVvdXNseSIgaXMgYSBwcm9ibGVtIGFzIGl0IG1ha2VzIGl0IGlt cG9zc2libGUgdG8gaW50cm9kdWNlIHRoaXMgbWVjaGFuaXNtIGluIG1hbnkgZXhpc3RpbmcgZGVw bG95bWVudHMuIEkgd291bGQgZXhwZWN0IGEgc29sdXRpb24gdGhhdCBjYW4gYmUgaW50cm9kdWNl ZCBncmFkdWFsbHkgKHNvbWUgbm9kZXMgYXQgYSB0aW1lKSBpbiBleGlzdGluZyBkZXBsb3ltZW50 cyBzdXBwb3J0aW5nIFJGQyA4NDQ2IGFuZC9vciBSRkMgNTI0Ni4NCg0KSSB0aGluayBwZXJoYXBz IG15IHJlc3BvbnNlIHdhcyB1bmNsZWFyLiBJbiB5b3VyIHNjZW5hcmlvLCBhZGRpbmcga2V5IGlt cG9ydCBzdXBwb3J0IGlzIGVzc2VudGlhbGx5IHRoZSBzYW1lIGFzIGFkZGluZyBhIG5ldyBQU0sg dG8gYSBub2RlLiBTb21lIG5vZGVzIG1heSBvZmZlciAob3IgYWNjZXB0KSB0aGUgUFNLLCB3aGls ZSBvdGhlcnMgZG8gbm90LiBTdWNjZXNzZnVsIHVzZSBvZiBhbiBpbXBvcnRlZCBQU0sgd2lsbCBv bmx5IG9jY3VyIGlmIGJvdGggZW5kcG9pbnRzIGhhdmUgaW1wb3J0ZWQgdGhlIHNhbWUgUFNLLiBH cmFkdWFsIGRlcGxveW1lbnQgaXMgcG9zc2libGUuDQoNClRvIGNsYXJpZnkgZnVydGhlciBzaW5j ZSB0aGlzIHRvbyBtYXkgYmUgbWlzbGVhZGluZzogVGhpcyBhc3N1bWVzIHRoZSBpbXBvcnRlZCBQ U0tzIGFyZSBvZmZlcmVkIGFsb25nc2lkZSB0aGUgZXhpc3RpbmcgZXh0ZXJuYWwgUFNLcy4gU28s IHRvIHlvdXIgcHJldmlvdXMgcXVlc3Rpb24gcmVnYXJkaW5nIHNpbXVsdGFuZW91cyB1c2Ugb2Yg aW1wb3J0ZWQga2V5cyBhbmQgZXh0ZXJuYWwgUFNLcywgZ3JhZHVhbCBkZXBsb3ltZW50IGlzIG9u bHkgYXBwbGljYWJsZSB3aXRoIHN0YWNrcyBzdXBwb3J0aW5nIDEuMyBhbmQgMS4yLCB3aGVyZSBp bXBvcnRlZCBrZXlzIGFwcGx5IHRvIDEuMy4gTm9kZXMgc3VwcG9ydGluZyAxLjIgYW5kIDEuMyB3 aXRob3V0IHRoZSBpbXBvcnRlZCBrZXlzIHdpbGwgb2ZmZXIgMS4yIFBTS3MsIHdoZXJlYXMgbm9k ZXMgd2l0aCBpbXBvcnRlZCBrZXlzIHdpbGwgb2ZmZXIgMS4yIGFuZCBpbXBvcnRlZCAxLjMgUFNL cy4uDQoNCllvdeKAmXJlIHJpZ2h0IHRoYXQgaXTigJlzIG5vdCBwb3NzaWJsZSB0byBkZXBsb3kg Z3JhZHVhbGx5IGlmIG9uZSBpcyBjdXJyZW50bHkgdXNpbmcgZXh0ZXJuYWwgUFNLcyBmb3Igb25s eSAxLjMgb3IgMS4yLCB3YW50cyB0byBhZG9wdCB0aGUgaW1wb3J0ZXIgQVBJLCBhbmQgaXMgcHJv aGliaXRlZCBmcm9tIHVzaW5nIGJvdGggaW1wb3J0ZWQgYW5kIGV4dGVybmFsIFBTS3MgYXQgdGhl IHNhbWUgdGltZS4NCg0KDQo+DQo+IEJ1dCwgaWYgeW91IHdhbnQgdG8gY2hhbmdlIHRoZSBiZWhh dmlvdXIgb2YgdGhlIHVzaW5nIHRoZSBzYW1lIGV4dGVybmFsIFBTSyBpbiBib3RoIFRMUyAxLjIg YW5kIFRMUyAxLjMgYXMgYWxsb3dlZCBieSBSRkMgODQ0NiwgYSBzb2x1dGlvbiBub3QgcmVxdWly aW5nICJzaW11bHRhbmVvdXMgY2hhbmdlIiBpcyBwcm9iYWJseSBub3QgcG9zc2libGUuDQo+DQo+ IFRoZSByZXF1aXJlbWVudCB0aGF0ICJ0aGlzIHJlcXVpcmVzIGJvdGggZW5kcG9pbnRzIHRvIGFk b3B0IHRoZSBjaGFuZ2Ugc2ltdWx0YW5lb3VzbHkiIHNob3VsZCBwcm9iYWJseSBiZSBoaWdobGln aHRlZCBpbiB0aGUgZG9jdW1lbnQuDQo+DQo+IFRoZSBjdXJyZW50IG1lY2hhbmlzbSBkb2VzIG5v dCBzZWVtIHRvIGJlIGRlcGxveWFibGUgZm9yIGUuZy4gM0dQUCB1bnRpbCBUTFMgMS40IGlzIGlu dHJvZHVjZWQsIGFuZCB0aGVuIG9ubHkgZm9yIFRMUyAxLjQgYW5kIGxhdGVyLi4uIG9uIHRoZSBv dGhlciBoYW5kLCBiZWluZyBsaW1pdGVkIHRvIFNIQS0yNTYgZm9yIFBTSyBtYXkgYmUgb2sgZm9y IDNHUFAuIChhbmQgM0dQUCBjb3VsZCBqdXN0IGRlcml2ZSBhIFNlcGFyYXRlIFNIQS0zODQgUFNL IGlmIG5lZWRlZCkuDQo+DQo+IFNvbWUgbW9yZSBjb21tZW50Og0KPg0KPiAtIFdoaWNoIGxhYmVs IHNob3VsZCBiZSB1c2VkIGJ5IHZhcmlvdXMgdmVyc2lvbnMgb2YgRFRMUz8NCg0KTGlrZWx5IHRo ZSBzYW1lIGxhYmVscyBhcyB0aGUgVExTIGNvdW50ZXJwYXJ0cywgc2luY2UgdGhlIGxhYmVsIG1v cmUgb3IgbGVzcyBzcGVjaWZpZXMgdGhlICpoYW5kc2hha2UqIHZhcmlhbnQuDQoNCj4NCj4gLSAi SWYgYSBjbGllbnQgb3Igc2VydmVyIHdpc2ggdG8gZGVwcmVjYXRlIGEgaGFzaCBmdW5jdGlvbiBh bmQgbm8gbG9uZ2VyDQo+IHVzZSBpdCBmb3IgVExTIDEuMywgdGhleSBtYXkgcmVtb3ZlIHRoaXMg aGFzaCBmdW5jdGlvbiBmcm9tIHRoZSBzZXQNCj4gb2YgaGFzaGVzIHVzZWQgZHVyaW5nIHdoaWxl IGltcG9ydGluZyBrZXlzLiBUaGlzIGRvZXMgbm90IGFmZmVjdCB0aGUNCj4gS0RGIG9wZXJhdGlv biB1c2VkIHRvIGRlcml2ZSBjb25jcmV0ZSBQU0tzLiINCj4NCj4gSWYgc29tZW9uZSBkZXByZWNh dGVzIHRoZSB1c2Ugb2YgYSBoYXNoIGZ1bmN0aW9uIGluc2lkZSBUTFMgMS4zICh1c2VkIGJ5IFRy YW5zY3JpcHQtSGFzaCBhbmQgSEtERiksIGRvZXMgaXQgdGhlbiBtYWtlcyBzZW5zZSB0byBrZWVw IGRlcml2aW5nIGtleXMgb3V0c2lkZSBvZiBUTFMgd2l0aCB0aGF0IHNhbWUgZGVwcmVjYXRlZCBo YXNoIGZ1bmN0aW9uPw0KDQpOby4gSWYgdGhpcyBkZXByZWNhdGlvbiBvY2N1cnMsIHRoZW4gdGhl eSB3b3VsZCBmb2xsb3cgdGhlIGFkdmlzb3J5IHRleHQgYW5kIG5vdCB1c2UgdGhlIG9sZCBoYXNo IHdoZW4gaW1wb3J0aW5nIGtleXMuDQoNCj4NCj4gLSAiVG8gbWl0aWdhdGUgdGhlc2UgcHJvYmxl bXMsIGV4dGVybmFsIFBTS3MgY2FuIGJlIGJvdW5kIHRvIGEgc3BlY2lmaWMgaGFzaCBmdW5jdGlv biB3aGVuIHVzZWQgaW4gVExTIDEuMyINCj4NCj4gSSB3b3VsZCBjaGFuZ2UgdG8gImFyZSBib3Vu ZCB0byBhIHNwZWNpZmljIi4gSWYgdGhlIGFwcGxpY2F0aW9uIGRvZXMgbm90IHNwZWNpZnkgYW55 dGhpbmcsIHRoZSBrZXlzIGFyZSBib3VuZCB0byBTSEEtMjU2Lg0KDQpXb3JrcyBmb3IgbWUuIEni gJlsbCBmaWxlIGFuIGlzc3VlIHRvIHRyYWNrIHRoZSBjaGFuZ2UuDQoNClRoYW5rcywNCkNocmlz DQoNCj4NCj4gQ2hlZXJzLA0KPiBKb2huDQo+DQo+ICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBDaHJpc3RvcGhlciBXb29kIDxjYXdAaGVhcGluZ2JpdHMubmV0Pg0KPiBEYXRl OiBXZWRuZXNkYXksIDMgQXByaWwgMjAxOSBhdCAxNjoyNQ0KPiBUbzogSm9obiBNYXR0c3NvbiA8 am9obi4ubWF0dHNzb25AZXJpY3Nzb24uY29tPg0KPiBDYzogIlRMU0BpZXRmLm9yZyIgPFRMU0Bp ZXRmLi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBbVExTXSBDb21tZW50cyBvbiBkcmFmdC13b29kLXRs cy1leHRlcm5hbC1wc2staW1wb3J0ZXItMDENCj4NCj4gIFRoYW5rcyBmb3IgdGhlIGZlZWRiYWNr LCBKb2huLiBJIGZpbGVkIGlzc3VlcyBvbiB0aGUgR2l0SHViIGRyYWZ0DQo+ICBsb2NhdGVkIGF0 IFsxXS4gUGxlYXNlIHNlZSBpbmxpbmUgYmVsb3cgZm9yIGNvbW1lbnRzLg0KPg0KPiAgT24gMSBB cHIgMjAxOSwgYXQgMTI6MDAsIEpvaG4gTWF0dHNzb24gd3JvdGU6DQo+DQo+ICA+IEhpLA0KPiAg Pg0KPiAgPiBUaGFua3MgZm9yIHRyeWluZyB0byBzb2x2ZSB0aGlzIHByb2JsZW0hIE5vdCBoYXZp bmcgYSB3YXkgdG8gdXNlIHRoZQ0KPiAgPiBzYW1lIGV4dGVybmFsIFBTSyBmb3IgZGlmZmVyZW50 IGNpcGhlciBzdWl0ZXMgaXMgZGVmaW5pdGVseSBhIHRoaW5nDQo+ICA+IG1pc3NpbmcgZnJvbSBU TFMgMS4zLi4NCj4gID4NCj4gID4gQXMgSSBzdGF0ZWQgZHVyaW5nIHRoZSB3ZyBzZXNzaW9uLCAz R1BQIGhhdmUgYSBmZXcgdXNlIGNhc2VzIHRoYXQgdXNlDQo+ICA+IFBTSy1FQ0RIRSBiZXR3ZWVu IHBob25lIGFuZCBjb3JlIG5ldHdvcmsuIENvbnRyYXJ5IHRvIHdoYXQgSUVURiBwZW9wbGUNCj4g ID4gc29tZXRpbWVzIGJlbGlldmUsIG1vc3QgM0dQUCB1c2Ugb2YgVExTIChiZXR3ZWVuIHBob25l IGFuZCBjb3JlDQo+ICA+IG5ldHdvcmssIGJldHdlZW4gY29yZSBub2RlcywgYW5kIGJldHdlZW4g ZGlmZmVyZW50IG9wZXJhdG9ycykgdXNlDQo+ICA+IG11dHVhbCBhdXRoZW50aWNhdGlvbiB3aXRo IGNlcnRpZmljYXRlcy4NCj4gID4NCj4gID4gQWNjb3JkaW5nIHRvIHRoZSBjdXJyZW50IDNHUFAg c3BlY2lmaWNhdGlvbiwgdGhlIHBob25lIGFuZCB0aGUgY29yZQ0KPiAgPiBuZXR3b3JrIHdvdWxk IHNoYXJlIGFuIGV4dGVybmFsIFBTSyBhbmQgYW4gZXh0ZXJuYWwgaWRlbnRpdHkuIFRoZSBoYXNo DQo+ICA+IGZ1bmN0aW9uIGlzIHVuZGVmaW5lZCwgaS5lLiBTSEEtMjU2IGlzIHVzZWQgZm9yIFRM UyAxLjMuIFRoZSBwaG9uZSBhbmQNCj4gID4gdGhlIG5ldHdvcmsgd291bGQgdGhlbiBuZWdvdGlh dGUgVExTIDEuMiB3aXRoIGFueSBjaXBoZXIgc3VpdGUgb3IgVExTDQo+ICA+IDEuMyB3aXRoIFNI QS0yNTYuDQo+ICA+DQo+ICA+IFNvbWUgY29tbWVudHMNCj4gID4NCj4gID4gLSBUaGUgZHJhZnQg c2hvdWxkIG1ha2UgY2xlYXIgaWYgdGhlIEV4dGVybmFsIFBTSyBhbmQgZXh0ZXJuYWwNCj4gID4g aWRlbnRpdHkgY2FuIGJlIHVzZWQgdG9nZXRoZXIgd2l0aCB0aGUgaW1wb3J0ZWQgaWRlbnRpdGll cy4gSSBhc3N1bWUNCj4gID4gdGhlIGlkZWEgaXMgdGhhdCB0aGV5IGNhbuKAmXQgYnV0IEkgY2Fu 4oCZdCBzZWUgYW55IHRleHQgc3BlY2lmeWluZw0KPiAgPiB0aGlzLg0KPg0KPiAgSW5kZWVkLCB0 aGF0IHdhcyB0aGUgaW50ZW50Lg0KPg0KPiAgPg0KPiAgPiAtIOKAnUltcG9ydGVkIGtleXMgZG8g bm90IHJlcXVpcmUgbmVnb3RpYXRpb24gZm9yIHVzZSwgYXMgYSBjbGllbnQgYW5kDQo+ICA+IHNl cnZlciB3aWxsIG5vdCBhZ3JlZSB1cG9uIGlkZW50aXRpZXMgaWYgbm90IGltcG9ydGVkIGNvcnJl Y3RseS4NCj4gID4gVGh1cywgaW1wb3J0ZXJzIGluZHVjZSBubyBwcm90b2NvbCBjaGFuZ2VzIHdp dGggdGhlIGV4Y2VwdGlvbiBvZg0KPiAgPiBleHBhbmRpbmcgdGhlIHNldCBvZiBQU0sgaWRlbnRp dGllcyBzZW50IG9uIHRoZSB3aXJlLuKAnQ0KPiAgPg0KPiAgPiBXaGlsZSBJIHNlZSBob3cgdGhl IGRlZmluZWQgbWVjaGFuaXNtIGNhbiBiZSBkZXBsb3llZCBpbiBhIG5ldw0KPiAgPiBkZXBsb3lt ZW50LCBJIGRvIG5vdCBzZWUgaG93IHRvIGludHJvZHVjZSBpdCBpbiBhbiBleGlzdGluZw0KPiAg PiBkZXBsb3ltZW50LiBBc3N1bWluZyB0aGF0IHRoZSBleHRlcm5hbCBQU0sgY2Fubm90IGJlIHVz ZWQgdG9nZXRoZXINCj4gID4gd2l0aCB0aGUgaW1wb3J0ZWQgaWRlbnRpdGllcywgdGhlIFRMUyBj bGllbnQgYW5kIHNlcnZlciBtdXN0IGludHJvZHVjZQ0KPiAgPiB0aGUgbWVjaGFuaXNtIGF0IHRo ZSBzYW1lIHRpbWUsIHRoYXQgaXMgb2Z0ZW4gbm90IHBvc3NpYmxlIHRvIGNvbnRyb2wuDQo+DQo+ ICBZb3XigJlyZSBjb3JyZWN0IHRoYXQgdGhpcyByZXF1aXJlcyBib3RoIGVuZHBvaW50cyB0byBh ZG9wdCB0aGUgY2hhbmdlDQo+ICBzaW11bHRhbmVvdXNseS4gSG93ZXZlciwgdGhhdCBkb2VzIG5v dCBjb250cmFkaWN0IHRoZSBxdW90ZWQgdGV4dCwgd2hpY2gNCj4gIHN0YXRlcyB0aGF0IHRoZSBw cm90b2NvbCBpcyBub3QgY2hhbmdlZC4NCj4NCj4gID4NCj4gID4gLSDigJxzdHJ1Y3Qgew0KPiAg PiBvcGFxdWUgZXh0ZXJuYWxfaWRlbnRpdHk8MS4uLjJeMTYtMT47DQo+ICA+IG9wYXF1ZSBsYWJl bDwwLi4yXjgtMT47DQo+ICA+IEhhc2hBbGdvcml0aG0gaGFzaDsNCj4gID4gfSBJbXBvcnRlZElk ZW50aXR5Ow0KPiAgPiDigJ0NCj4gID4NCj4gID4gVGhpcyBzY2FsZXMgcG9vcmx5LCBBIGNsaWVu dCBoYXMgdG8gc2VuZCBuKm0gaWRlbnRpdGllcyB3aGVyZSBuIGlzIHRoZQ0KPiAgPiBudW1iZXIg b2Ygc3VwcG9ydGVkIHZlcnNpb25zIGFuZCBtIGlzIHRoZSBudW1iZXIgb2Ygc3VwcG9ydGVkIGhh c2gNCj4gID4gYWxnb3JpdGhtcy4uLg0KPg0KPiAgWWVzLCB0aGlzIGlzIGEgdHJhZGVvZmYgd2Ug bWFkZSBieSBvcHRpbmcgdG8gbm90IG1vZGlmeSB0aGUga2V5DQo+ICBzY2hlZHVsZS4NCj4NCj4g ID4NCj4gID4gLSBXb3VsZCBpdCBub3QgYmUgcG9zc2libGUgdG8ganVzdCB1c2UgdGhlIHZlcnNp b24gbnVtYmVyIGFzIGxhYmVsPw0KPiAgPiBJLmUuIDB4MDMwNCBpbnN0ZWFkIG9mIOKAnHRsczEz 4oCdLiBJbiB0aGF0IHdheSB5b3UgZG8gYXQgbGVhc3Qgbm90DQo+ICA+IGhhdmUgdG8gZGVmaW5l IGEgbmV3IGxhYmVscy4NCj4NCj4gIFdlIHByb2JhYmx5IGNvdWxkLCB0aG91Z2ggc2luY2UgdGhl IGxhYmVscyBhcmUgc3ViamVjdCB0byBjaGFuZ2UgKHNlZQ0KPiAgdGhlIFRPRE8gYWJvdXQgcG9z c2libHkgaW5jbHVkaW5nIHRoZSBIYXNoQWxnb3JpdGhtIGluIHRoZSBsYWJlbCksIHdlDQo+ICBr ZXB0IGl0IGFzIGlzLg0KPg0KPiAgPg0KPiAgPiAtIOKAnFRMUyAxLjMgW1JGQzg0NDZdIHN1cHBv cnRzIHByZS1zaGFyZWQga2V5IChQU0spIHJlc3VtcHRpb24sDQo+ICA+IHdoZXJlaW4NCj4gID4g UFNLcyBjYW4gYmUgZXN0YWJsaXNoZWQgdmlhIHNlc3Npb24gdGlja2V0cyBmcm9tIHByaW9yIGNv bm5lY3Rpb25zIG9yDQo+ICA+IGV4dGVybmFsbHkgdmlhIHNvbWUgb3V0LW9mLWJhbmQgbWVjaGFu aXNtLuKAnQ0KPiAgPg0KPiAgPiBUaGlzIHNlZW1zIHRvIGluZGljYXRlIHRoYXQgYWxsIHVzZSBv ZiBQU0sgaXMgcmVzdW1wdGlvbiB3aGljaCBpcyBub3QNCj4gID4gY29ycmVjdC4gSSBzdWdnZXN0 IGNoYW5naW5nIHRvIOKAnFRMUyAxLjMgW1JGQzg0NDZdIHN1cHBvcnRzDQo+ICA+IHByZS1zaGFy ZWQga2V5IChQU0spIGF1dGhlbnRpY2F0aW9u4oCdDQo+DQo+ICBHb29kIHN1Z2dlc3Rpb24hIFdl 4oCZbGwgZml4IGl0Lg0KPg0KPiAgPg0KPiAgPiAtIOKAnGltcG9ydGluZyBleHRlcm5hbCBQU0sg KFByZS1TaGFyZWQgS2V5KSBpbnRvIFRMUy7igJ0NCj4gID4NCj4gID4gTm90IHN1cmUgaWYg4oCc aW50b+KAnSBpcyB0aGUgcmlnaHQgd29yZCwgSSB0aGluayDigJxmb3LigJ0gYXMgaW4gdGggZQ0K PiAgPiB0aXRsZSBpcyBiZXR0ZXIuIFRoZSBtZWNoYW5pc20gc2VlbXMgdmVyeSBtdWNoIGV4dGVy bmFsIHRvIFRMUyBpdHNlbGYuDQo+ICA+IEkgc2VlIGl0IGFzIGEgbWVjaGFuaXNtIHRvIGRlcml2 ZSBzZXZlcmFsIGV4dGVybmFsIFBTS3MgZnJvbSBhIHNpbmdsZQ0KPiAgPiBleHRlcm5hbCBQU0su Lg0KPg0KPiAgRGl0dG8uDQo+DQo+ICA+DQo+ICA+IC0g4oCcU2ltaWxhcmx5LCBUTFMgMS4yIGFu ZCBhbGwgcHJpb3IgVExTIHZlcnNpb25zIHNob3VsZCB1c2UgInRsczEyIg0KPiAgPiDigJwNCj4g ID4NCj4gID4gVGhlIHZlcnNpb25zIHByaW9yIHRvIFRMUyAxLjIgd2lsbCBzb29uIGJlIGRlcHJl Y2F0ZWQuIEFuZCB3aHkgc3BlbmQNCj4gID4gdGltZSB1cGRhdGluZyB0aGUgVExTIDEuMiBjb2Rl IGJhc2UgaW5zdGVhZCBvZiBtb3ZpbmcgdG8gVExTIDEuMz8NCj4NCj4gIFdl4oCZcmUganVzdCBj b3ZlcmluZyBvdXIgYmFzZXMgaGVyZS4gSSB0ZW5kIHRvIGFncmVlIHRoYXQgdGhlIGZvY3VzDQo+ ICBzaG91bGQgYmUgb24gdXBkYXRpbmcgdG8gVExTIDEuMyBpbnN0ZWFkIG9mIOKAnHBhdGNoaW5n 4oCdIFRMUyAxLjINCj4gIHN0YWNrcy4NCj4NCj4gID4NCj4gID4NCj4gID4gU3VnZ2VzdGlvbjoN Cj4gID4NCj4gID4gSW5zdGVhZCBvZiBkZXJpdmluZyBhIGxhcmdlIHNldCBvZiBuZXcgZXh0ZXJu YWwgUFNLcywgd291bGRu4oCZdCBpdCBiZQ0KPiAgPiBwb3NzaWJsZSB0byBqdXN0IHVzZSBkaWZm ZXJlbnQgaGFzaCBmdW5jdGlvbnMgaW4gZGlmZmVyZW50IHBhcnRzIG9mDQo+ICA+IHRoZSBrZXkg aGllcmFyY2h5PyBJLmUuIGlmIFNIQS0yNTYgaXMgYXNzb2NpYXRlZCB3aXRoIHRoZSBleHRlcm5h bCBQU0sNCj4gID4gYW5kIFNIQS0zODQgaXMgdGhlIGhhc2ggYWxnb3JpdGhtcyBpbiB0aGUgY2hv c2VuIGNpcGhlciBzdWl0ZToNCj4gID4NCj4gID4gUFNLIC0+IEhLREYtRXh0cmFjdChTSEEtMjU2 KSA9IEVhcmx5IFNlY3JldA0KPiAgPiB8DQo+ICA+ICstLS0tLT4gRGVyaXZlLVNlY3JldCguLCAi ZXh0IGJpbmRlciIgfCAicmVzIGJpbmRlciIsICIiKQ0KPiAgPiB8ID0gYmluZGVyX2tleQ0KPiAg PiB8DQo+ICA+ICstLS0tLT4gRGVyaXZlLVNlY3JldCguLCAiYyBlIHRyYWZmaWMiLCBDbGllbnRI ZWxsbykNCj4gID4gfCA9IGNsaWVudF9lYXJseV90cmFmZmljX3NlY3JldA0KPiAgPiB8DQo+ICA+ ICstLS0tLT4gRGVyaXZlLVNlY3JldCguLCAiZSBleHAgbWFzdGVyIiwgQ2xpZW50SGVsbG8pDQo+ ICA+IHwgPSBlYXJseV9leHBvcnRlcl9tYXN0ZXJfc2VjcmV0DQo+ICA+IHYNCj4gID4gRGVyaXZl LVNlY3JldCguLCAiZGVyaXZlZCIsICIiKQ0KPiAgPiB8DQo+ICA+IHYNCj4gID4gKEVDKURIRSAt PiBIS0RGLUV4dHJhY3QoU0hBLTM4NCkgPSBIYW5kc2hha2UgU2VjcmV0DQo+ICA+DQo+ICA+IFN1 cHBvcnQgb2YgdGhpcyBjb3VsZCBiZSBzaWduYWxsZWQgd2l0aCB0aGUgdGxzX2ZsYWdzIGV4dGVu c2lvbi4gSWYNCj4gID4gdGhlIHNlcnZlciBkb2VzIG5vdCBzdXBwb3J0IHRoZSBleHRlbnNpb24g aXQgbXVzdCBhY2NvcmRpbmcgdG8gUkZDDQo+ICA+IDg0NDYgY2hvc2UgYSBjaXBoZXIgc3VpdGUg d2l0aCBTSEEtMjU2Lg0KPg0KPiAgTW9kaWZ5aW5nIHRoZSBrZXkgc2NoZWR1bGUgd2FzIGRpc2N1 c3NlZCBpbiB0aGUgY29udGV4dCBvZiBbMl0uLiBBdCB0aGUNCj4gIHRpbWUsIGl0IHNlZW1lZCB0 aGUgZGVzaXJlIHRvIG5vdCB0b3VjaCB0aGUga2V5IHNjaGVkdWxlIG91dHdlaWdoZWQgdGhlDQo+ ICBkZXNpcmUgdG8gbm90IGluZmxhdGUgdGhlIENsaWVudEhlbGxvLg0KPg0KPiAgQmVzdCwNCj4g IENocmlzDQo+DQo+ICBbMV0gaHR0cHM6Ly9naXRodWIuY29tL2NocmlzLXdvb2QvZHJhZnQtd29v ZC10bHMtZXh0ZXJuYWwtcHNrLWltcG9ydGVyDQo+ICBbMl0gaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWRhdmlkYmVuLXRscy11bml2ZXJzYWwtcHNrLTAwDQo+DQo+DQo+DQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUTFMgbWFpbGlu ZyBsaXN0DQpUTFNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vdGxzDQoNCg0K --_000_008538ABFBE04132A9FD18BAE1F3F4FCericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <0915317FA1A5AF47B9D2EDC5A06EFE0D@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw Lk1zb05vU3BhY2luZywgbGkuTXNvTm9TcGFjaW5nLCBkaXYuTXNvTm9TcGFjaW5nDQoJe21zby1z dHlsZS1wcmlvcml0eToxOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K cC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFn cmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2lu LXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYu bXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3At YWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLmZhc3RtYWlsLXF1b3RlZC1tc29ub3JtYWwsIGxpLmZh c3RtYWlsLXF1b3RlZC1tc29ub3JtYWwsIGRpdi5mYXN0bWFpbC1xdW90ZWQtbXNvbm9ybWFsDQoJ e21zby1zdHlsZS1uYW1lOmZhc3RtYWlsLXF1b3RlZC1tc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLmZhc3RtYWlsLXF1b3RlZC1tc29ub3NwYWNpbmcs IGxpLmZhc3RtYWlsLXF1b3RlZC1tc29ub3NwYWNpbmcsIGRpdi5mYXN0bWFpbC1xdW90ZWQtbXNv bm9zcGFjaW5nDQoJe21zby1zdHlsZS1uYW1lOmZhc3RtYWlsLXF1b3RlZC1tc29ub3NwYWNpbmc7 DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjExLjBw dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLmZhc3RtYWlsLXF1b3Rl ZC1tc29ub3JtYWwxLCBsaS5mYXN0bWFpbC1xdW90ZWQtbXNvbm9ybWFsMSwgZGl2LmZhc3RtYWls LXF1b3RlZC1tc29ub3JtYWwxDQoJe21zby1zdHlsZS1uYW1lOmZhc3RtYWlsLXF1b3RlZC1tc29u b3JtYWwxOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5mYXN0bWFp bC1xdW90ZWQtbXNvbm9zcGFjaW5nMSwgbGkuZmFzdG1haWwtcXVvdGVkLW1zb25vc3BhY2luZzEs IGRpdi5mYXN0bWFpbC1xdW90ZWQtbXNvbm9zcGFjaW5nMQ0KCXttc28tc3R5bGUtbmFtZTpmYXN0 bWFpbC1xdW90ZWQtbXNvbm9zcGFjaW5nMTsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3Rl eHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4w cHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iU1YiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+ SGkgQ2hyaXMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5UaGFua3MgZm9yIHRoZSBkaXNjdXNzaW9uLiBX b3VsZCBiZSBnb29kIGlmIGEgZnV0dXJlIHZlcnNpb246PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4tIE1h ZGUgY2xlYXIgaWYgdGhlIGltcG9ydGVkIFBTS3MgTVVTVCBOT1QgLyBTSE9VTEQgTk9UIC8gTUFZ IC8gU0hPVUxEIC8gTVVTVCBiZSBvZmZlcmVkIGFsb25nc2lkZSB0aGUgZXhpc3RpbmcgZXh0ZXJu YWwgUFNLcy4gV2hpbGUgb2ZmZXJpbmcgYm90aCB3b3VsZCBtYWtlIGEgbWlncmF0aW9uIHBhdGgg cG9zc2libGUgSSBkb27igJl0IHRoaW5rIGl0IGlzIHRoZSB3YXkgdG8gZ28uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC Ij4tIElmIE1VU1QgTk9ULCB0aGUgZG9jdW1lbnQgc2hvdWxkIG1heWJlIGFsc28gc3RhdGUgd2hh dCB0aGUgY2xpZW50IGRvIGlmIGl0IHJlY2VpdmVzIGEgdW5rbm93bl9wc2tfaWRlbnRpdHkgYWxl cnQsIGlzIGl0IGFsbG93ZWQgdG8gdHJ5IGFnYWluIHdpdGggdGhlIGV4dGVybmFsIChub24taW1w b3J0ZWQgaWRlbnRpdHkpIG9yIGlzIGl0IGZvcmJpZGRlbiB0byBkbyBzbz88bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiPi0gTWFkZSBjbGVhciBpZiB1c2Ugb2YgZHJhZnQtd29vZC10bHMtZXh0ZXJuYWwtcHNr LWltcG9ydGVyIGlzIGEgcHJvcGVydHkgb2YgdGhlIFRMUyBpbXBsZW1lbnRhdGlvbiAoaS5lLiB1 c2VkIG9uIGFsbCBQU0spIG9yIGEgcHJvcGVydHkgb2YgdGhlIGV4dGVybmFsIFBTSyAoaS5lLiBv bmx5IHVzZWQgb24ga2V5cyB3aXRoIHRoaXMgcHJvcGVydHkpLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+ LSBTdGF0ZSB0aGF0ICZxdW90O3RsczEyJnF1b3Q7IGlzIHVzZWQgZm9yIERUTFMgMS4yIGFuZCAm cXVvdDt0bHMxMyZxdW90OyBpcyB1c2VkIGZvciBEVExTIDEuMy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii PkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiI+Sm9objxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpi bGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29s b3I6YmxhY2siPlRMUyAmbHQ7dGxzLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBD aHJpc3RvcGhlciBXb29kICZsdDtjYXdAaGVhcGluZ2JpdHMubmV0Jmd0Ozxicj4NCjxiPkRhdGU6 IDwvYj5UaHVyc2RheSwgNCBBcHJpbCAyMDE5IGF0IDE1OjE5PGJyPg0KPGI+VG86IDwvYj4mcXVv dDtUTFNAaWV0Zi5vcmcmcXVvdDsgJmx0O3Rsc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0 OiA8L2I+UmU6IFtUTFNdIENvbW1lbnRzIG9uIGRyYWZ0LXdvb2QtdGxzLWV4dGVybmFsLXBzay1p bXBvcnRlci0wMTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPk9uIFRodSwgQXByIDQsIDIwMTksIGF0IDY6MDEgQU0sIENocmlzdG9waGVy IFdvb2Qgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiIGlkPSJmYXN0bWFpbC1xdW90ZWQi Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij5PbiBXZWQsIEFwciAzLCAyMDE5LCBhdCAxMToyMiBQTSwgSm9obiBNYXR0c3NvbiB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPiZndDsgSGkgQ2hyaXN0b3BoZXIsPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij4mZ3Q7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mZ3Q7IFRoYW5rcyBmb3Ig dGhlIGNsYXJpZmljYXRpb25zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jmd0OyZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+Jmd0OyAmZ3Q7WW914oCZcmUgY29ycmVjdCB0aGF0IHRoaXMgcmVx dWlyZXMgYm90aCBlbmRwb2ludHMgdG8gYWRvcHQgdGhlIGNoYW5nZSZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+Jmd0OyAmZ3Q7c2ltdWx0YW5lb3VzbHkuIEhvd2V2ZXIsIHRoYXQgZG9lcyBu b3QgY29udHJhZGljdCB0aGUgcXVvdGVkIHRleHQsIHdoaWNoJm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij4mZ3Q7ICZndDtzdGF0ZXMgdGhhdCB0aGUgcHJvdG9jb2wgaXMgbm90IGNoYW5nZWQu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mZ3Q7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4m Z3Q7IEkgdGhpbmsgJnF1b3Q7dGhpcyByZXF1aXJlcyBib3RoIGVuZHBvaW50cyB0byBhZG9wdCB0 aGUgY2hhbmdlIHNpbXVsdGFuZW91c2x5JnF1b3Q7IGlzIGEgcHJvYmxlbSBhcyBpdCBtYWtlcyBp dCBpbXBvc3NpYmxlIHRvIGludHJvZHVjZSB0aGlzIG1lY2hhbmlzbSBpbiBtYW55IGV4aXN0aW5n IGRlcGxveW1lbnRzLiBJIHdvdWxkIGV4cGVjdCBhIHNvbHV0aW9uIHRoYXQgY2FuIGJlDQogaW50 cm9kdWNlZCBncmFkdWFsbHkgKHNvbWUgbm9kZXMgYXQgYSB0aW1lKSBpbiBleGlzdGluZyBkZXBs b3ltZW50cyBzdXBwb3J0aW5nIFJGQyA4NDQ2IGFuZC9vciBSRkMgNTI0Ni48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SSB0aGluayBwZXJoYXBzIG15 IHJlc3BvbnNlIHdhcyB1bmNsZWFyLiBJbiB5b3VyIHNjZW5hcmlvLCBhZGRpbmcga2V5IGltcG9y dCBzdXBwb3J0IGlzIGVzc2VudGlhbGx5IHRoZSBzYW1lIGFzIGFkZGluZyBhIG5ldyBQU0sgdG8g YSBub2RlLiBTb21lIG5vZGVzIG1heSBvZmZlciAob3IgYWNjZXB0KSB0aGUgUFNLLCB3aGlsZSBv dGhlcnMgZG8gbm90LiBTdWNjZXNzZnVsDQogdXNlIG9mIGFuIGltcG9ydGVkIFBTSyB3aWxsIG9u bHkgb2NjdXIgaWYgYm90aCBlbmRwb2ludHMgaGF2ZSBpbXBvcnRlZCB0aGUgc2FtZSBQU0suIEdy YWR1YWwgZGVwbG95bWVudCBpcyBwb3NzaWJsZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+VG8gY2xhcmlmeSBmdXJ0aGVy IHNpbmNlIHRoaXMgdG9vIG1heSBiZSBtaXNsZWFkaW5nOiBUaGlzIGFzc3VtZXMgdGhlIGltcG9y dGVkIFBTS3MgYXJlIG9mZmVyZWQgYWxvbmdzaWRlIHRoZSBleGlzdGluZyBleHRlcm5hbCBQU0tz LiBTbywgdG8geW91ciBwcmV2aW91cyBxdWVzdGlvbiByZWdhcmRpbmcgc2ltdWx0YW5lb3VzIHVz ZSBvZiBpbXBvcnRlZCBrZXlzIGFuZA0KIGV4dGVybmFsIFBTS3MsIGdyYWR1YWwgZGVwbG95bWVu dCBpcyBvbmx5IGFwcGxpY2FibGUgd2l0aCBzdGFja3Mgc3VwcG9ydGluZyAxLjMgYW5kIDEuMiwg d2hlcmUgaW1wb3J0ZWQga2V5cyBhcHBseSB0byAxLjMuIE5vZGVzIHN1cHBvcnRpbmcgMS4yIGFu ZCAxLjMgd2l0aG91dCB0aGUgaW1wb3J0ZWQga2V5cyB3aWxsIG9mZmVyIDEuMiBQU0tzLCB3aGVy ZWFzIG5vZGVzIHdpdGggaW1wb3J0ZWQga2V5cyB3aWxsIG9mZmVyIDEuMiBhbmQgaW1wb3J0ZWQN CiAxLjMgUFNLcy4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPllvdeKAmXJlIHJpZ2h0IHRoYXQgaXTigJlzIG5vdCBwb3NzaWJsZSB0byBkZXBsb3kg Z3JhZHVhbGx5IGlmIG9uZSBpcyBjdXJyZW50bHkgdXNpbmcgZXh0ZXJuYWwgUFNLcyBmb3Igb25s eSAxLjMgb3IgMS4yLCB3YW50cyB0byBhZG9wdCB0aGUgaW1wb3J0ZXIgQVBJLCBhbmQgaXMgcHJv aGliaXRlZCBmcm9tIHVzaW5nIGJvdGggaW1wb3J0ZWQgYW5kIGV4dGVybmFsIFBTS3MNCiBhdCB0 aGUgc2FtZSB0aW1lLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiIGlkPSJmYXN0bWFpbC1xdW90ZWQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jmd0OyBCdXQsIGlmIHlvdSB3YW50 IHRvIGNoYW5nZSB0aGUgYmVoYXZpb3VyIG9mIHRoZSB1c2luZyB0aGUgc2FtZSBleHRlcm5hbCBQ U0sgaW4gYm90aCBUTFMgMS4yIGFuZCBUTFMgMS4zIGFzIGFsbG93ZWQgYnkgUkZDIDg0NDYsIGEg c29sdXRpb24gbm90IHJlcXVpcmluZyAmcXVvdDtzaW11bHRhbmVvdXMgY2hhbmdlJnF1b3Q7IGlz IHByb2JhYmx5IG5vdCBwb3NzaWJsZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZndDsmbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPiZndDsgVGhlIHJlcXVpcmVtZW50IHRoYXQgJnF1b3Q7dGhp cyByZXF1aXJlcyBib3RoIGVuZHBvaW50cyB0byBhZG9wdCB0aGUgY2hhbmdlIHNpbXVsdGFuZW91 c2x5JnF1b3Q7IHNob3VsZCBwcm9iYWJseSBiZSBoaWdobGlnaHRlZCBpbiB0aGUgZG9jdW1lbnQu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mZ3Q7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4m Z3Q7IFRoZSBjdXJyZW50IG1lY2hhbmlzbSBkb2VzIG5vdCBzZWVtIHRvIGJlIGRlcGxveWFibGUg Zm9yIGUuZy4gM0dQUCB1bnRpbCBUTFMgMS40IGlzIGludHJvZHVjZWQsIGFuZCB0aGVuIG9ubHkg Zm9yIFRMUyAxLjQgYW5kIGxhdGVyLi4uIG9uIHRoZSBvdGhlciBoYW5kLCBiZWluZyBsaW1pdGVk IHRvIFNIQS0yNTYgZm9yIFBTSyBtYXkgYmUgb2sgZm9yIDNHUFAuDQogKGFuZCAzR1BQIGNvdWxk IGp1c3QgZGVyaXZlIGEgU2VwYXJhdGUgU0hBLTM4NCBQU0sgaWYgbmVlZGVkKS48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPiZndDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZndDsgU29tZSBt b3JlIGNvbW1lbnQ6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mZ3Q7Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij4mZ3Q7IC0gV2hpY2ggbGFiZWwgc2hvdWxkIGJlIHVzZWQgYnkgdmFyaW91cyB2 ZXJzaW9ucyBvZiBEVExTPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij5MaWtlbHkgdGhlIHNhbWUgbGFiZWxzIGFzIHRoZSBUTFMgY291bnRlcnBhcnRz LCBzaW5jZSB0aGUgbGFiZWwgbW9yZSBvciBsZXNzIHNwZWNpZmllcyB0aGUgKmhhbmRzaGFrZSog dmFyaWFudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jmd0OyAtICZxdW90O0lmIGEgY2xp ZW50IG9yIHNlcnZlciB3aXNoIHRvIGRlcHJlY2F0ZSBhIGhhc2ggZnVuY3Rpb24gYW5kIG5vIGxv bmdlcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jmd0OyB1c2UgaXQgZm9yIFRMUyAxLjMsIHRoZXkg bWF5IHJlbW92ZSB0aGlzIGhhc2ggZnVuY3Rpb24gZnJvbSB0aGUgc2V0PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij4mZ3Q7IG9mIGhhc2hlcyB1c2VkIGR1cmluZyB3aGlsZSBpbXBvcnRpbmcga2V5cy4g VGhpcyBkb2VzIG5vdCBhZmZlY3QgdGhlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mZ3Q7IEtERiBv cGVyYXRpb24gdXNlZCB0byBkZXJpdmUgY29uY3JldGUgUFNLcy4mcXVvdDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPiZndDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZndDsgSWYgc29tZW9u ZSBkZXByZWNhdGVzIHRoZSB1c2Ugb2YgYSBoYXNoIGZ1bmN0aW9uIGluc2lkZSBUTFMgMS4zICh1 c2VkIGJ5IFRyYW5zY3JpcHQtSGFzaCBhbmQgSEtERiksIGRvZXMgaXQgdGhlbiBtYWtlcyBzZW5z ZSB0byBrZWVwIGRlcml2aW5nIGtleXMgb3V0c2lkZSBvZiBUTFMgd2l0aCB0aGF0IHNhbWUgZGVw cmVjYXRlZCBoYXNoIGZ1bmN0aW9uPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij5Oby4gSWYgdGhpcyBkZXByZWNhdGlvbiBvY2N1cnMsIHRoZW4gdGhl eSB3b3VsZCBmb2xsb3cgdGhlIGFkdmlzb3J5IHRleHQgYW5kIG5vdCB1c2UgdGhlIG9sZCBoYXNo IHdoZW4gaW1wb3J0aW5nIGtleXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPiZndDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZndDsgLSAm cXVvdDtUbyBtaXRpZ2F0ZSB0aGVzZSBwcm9ibGVtcywgZXh0ZXJuYWwgUFNLcyBjYW4gYmUgYm91 bmQgdG8gYSBzcGVjaWZpYyBoYXNoIGZ1bmN0aW9uIHdoZW4gdXNlZCBpbiBUTFMgMS4zJnF1b3Q7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mZ3Q7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4m Z3Q7IEkgd291bGQgY2hhbmdlIHRvICZxdW90O2FyZSBib3VuZCB0byBhIHNwZWNpZmljJnF1b3Q7 LiBJZiB0aGUgYXBwbGljYXRpb24gZG9lcyBub3Qgc3BlY2lmeSBhbnl0aGluZywgdGhlIGtleXMg YXJlIGJvdW5kIHRvIFNIQS0yNTYuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPldvcmtzIGZvciBtZS4gSeKAmWxsIGZpbGUgYW4gaXNzdWUgdG8gdHJh Y2sgdGhlIGNoYW5nZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Q2hyaXMmbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jmd0OyZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jmd0OyBDaGVlcnMsPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4m Z3Q7IEpvaG48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZndDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPiZndDsmbmJzcDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPiZndDsgRnJvbTogQ2hyaXN0b3BoZXIgV29vZCAmbHQ7Y2F3QGhlYXBpbmdiaXRz Lm5ldCZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZndDsgRGF0ZTogV2VkbmVzZGF5LCAzIEFw cmlsIDIwMTkgYXQgMTY6MjU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZndDsgVG86IEpvaG4gTWF0 dHNzb24gJmx0O2pvaG4uLm1hdHRzc29uQGVyaWNzc29uLmNvbSZndDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPiZndDsgQ2M6ICZxdW90O1RMU0BpZXRmLm9yZyZxdW90OyAmbHQ7VExTQGlldGYuLm9y ZyZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZndDsgU3ViamVjdDogUmU6IFtUTFNdIENvbW1l bnRzIG9uIGRyYWZ0LXdvb2QtdGxzLWV4dGVybmFsLXBzay1pbXBvcnRlci0wMTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jmd0OyZuYnNwOyBU aGFua3MgZm9yIHRoZSBmZWVkYmFjaywgSm9obi4gSSBmaWxlZCBpc3N1ZXMgb24gdGhlIEdpdEh1 YiBkcmFmdCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jmd0OyZuYnNwOyBsb2NhdGVkIGF0 IFsxXS4gUGxlYXNlIHNlZSBpbmxpbmUgYmVsb3cgZm9yIGNvbW1lbnRzLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jmd0OyZuYnNwOyBPbiAx IEFwciAyMDE5LCBhdCAxMjowMCwgSm9obiBNYXR0c3NvbiB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPiZndDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZndDsmbmJzcDsgJmd0OyBI aSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZndDsmbmJzcDsgJmd0OzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+Jmd0OyZuYnNwOyAmZ3Q7IFRoYW5rcyBmb3IgdHJ5aW5nIHRvIHNvbHZlIHRoaXMgcHJv YmxlbSEgTm90IGhhdmluZyBhIHdheSB0byB1c2UgdGhlJm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij4mZ3Q7Jm5ic3A7ICZndDsgc2FtZSBleHRlcm5hbCBQU0sgZm9yIGRpZmZlcmVudCBjaXBo ZXIgc3VpdGVzIGlzIGRlZmluaXRlbHkgYSB0aGluZyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+Jmd0OyZuYnNwOyAmZ3Q7IG1pc3NpbmcgZnJvbSBUTFMgMS4zLi48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPiZndDsmbmJzcDsgJmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jmd0OyZuYnNwOyAm Z3Q7IEFzIEkgc3RhdGVkIGR1cmluZyB0aGUgd2cgc2Vzc2lvbiwgM0dQUCBoYXZlIGEgZmV3IHVz ZSBjYXNlcyB0aGF0IHVzZSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jmd0OyZuYnNwOyAm Z3Q7IFBTSy1FQ0RIRSBiZXR3ZWVuIHBob25lIGFuZCBjb3JlIG5ldHdvcmsuIENvbnRyYXJ5IHRv IHdoYXQgSUVURiBwZW9wbGUmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZndDsmbmJzcDsg Jmd0OyBzb21ldGltZXMgYmVsaWV2ZSwgbW9zdCAzR1BQIHVzZSBvZiBUTFMgKGJldHdlZW4gcGhv bmUgYW5kIGNvcmUmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZndDsmbmJzcDsgJmd0OyBu ZXR3b3JrLCBiZXR3ZWVuIGNvcmUgbm9kZXMsIGFuZCBiZXR3ZWVuIGRpZmZlcmVudCBvcGVyYXRv cnMpIHVzZSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jmd0OyZuYnNwOyAmZ3Q7IG11dHVh bCBhdXRoZW50aWNhdGlvbiB3aXRoIGNlcnRpZmljYXRlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PiZndDsmbmJzcDsgJmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jmd0OyZuYnNwOyAmZ3Q7IEFj Y29yZGluZyB0byB0aGUgY3VycmVudCAzR1BQIHNwZWNpZmljYXRpb24sIHRoZSBwaG9uZSBhbmQg dGhlIGNvcmUmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZndDsmbmJzcDsgJmd0OyBuZXR3 b3JrIHdvdWxkIHNoYXJlIGFuIGV4dGVybmFsIFBTSyBhbmQgYW4gZXh0ZXJuYWwgaWRlbnRpdHku IFRoZSBoYXNoJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mZ3Q7Jm5ic3A7ICZndDsgZnVu Y3Rpb24gaXMgdW5kZWZpbmVkLCBpLmUuIFNIQS0yNTYgaXMgdXNlZCBmb3IgVExTIDEuMy4gVGhl IHBob25lIGFuZCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jmd0OyZuYnNwOyAmZ3Q7IHRo ZSBuZXR3b3JrIHdvdWxkIHRoZW4gbmVnb3RpYXRlIFRMUyAxLjIgd2l0aCBhbnkgY2lwaGVyIHN1 aXRlIG9yIFRMUyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jmd0OyZuYnNwOyAmZ3Q7IDEu MyB3aXRoIFNIQS0yNTYuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mZ3Q7Jm5ic3A7ICZndDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPiZndDsmbmJzcDsgJmd0OyBTb21lIGNvbW1lbnRzPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij4mZ3Q7Jm5ic3A7ICZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZndDsm bmJzcDsgJmd0OyAtIFRoZSBkcmFmdCBzaG91bGQgbWFrZSBjbGVhciBpZiB0aGUgRXh0ZXJuYWwg UFNLIGFuZCBleHRlcm5hbCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jmd0OyZuYnNwOyAm Z3Q7IGlkZW50aXR5IGNhbiBiZSB1c2VkIHRvZ2V0aGVyIHdpdGggdGhlIGltcG9ydGVkIGlkZW50 aXRpZXMuIEkgYXNzdW1lJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mZ3Q7Jm5ic3A7ICZn dDsgdGhlIGlkZWEgaXMgdGhhdCB0aGV5IGNhbuKAmXQgYnV0IEkgY2Fu4oCZdCBzZWUgYW55IHRl eHQgc3BlY2lmeWluZyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jmd0OyZuYnNwOyAmZ3Q7 IHRoaXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mZ3Q7Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij4mZ3Q7Jm5ic3A7IEluZGVlZCwgdGhhdCB3YXMgdGhlIGludGVudC48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPiZndDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZndDsmbmJzcDsgJmd0 OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jmd0OyZuYnNwOyAmZ3Q7IC0g4oCdSW1wb3J0ZWQga2V5 cyBkbyBub3QgcmVxdWlyZSBuZWdvdGlhdGlvbiBmb3IgdXNlLCBhcyBhIGNsaWVudCBhbmQ8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPiZndDsmbmJzcDsgJmd0OyBzZXJ2ZXIgd2lsbCBub3QgYWdyZWUg dXBvbiBpZGVudGl0aWVzIGlmIG5vdCBpbXBvcnRlZCBjb3JyZWN0bHkuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij4mZ3Q7Jm5ic3A7ICZndDsgVGh1cywgaW1wb3J0ZXJzIGluZHVjZSBubyBwcm90b2Nv bCBjaGFuZ2VzIHdpdGggdGhlIGV4Y2VwdGlvbiBvZjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jmd0 OyZuYnNwOyAmZ3Q7IGV4cGFuZGluZyB0aGUgc2V0IG9mIFBTSyBpZGVudGl0aWVzIHNlbnQgb24g dGhlIHdpcmUu4oCdPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mZ3Q7Jm5ic3A7ICZndDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPiZndDsmbmJzcDsgJmd0OyBXaGlsZSBJIHNlZSBob3cgdGhlIGRlZmlu ZWQgbWVjaGFuaXNtIGNhbiBiZSBkZXBsb3llZCBpbiBhIG5ldyZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+Jmd0OyZuYnNwOyAmZ3Q7IGRlcGxveW1lbnQsIEkgZG8gbm90IHNlZSBob3cgdG8g aW50cm9kdWNlIGl0IGluIGFuIGV4aXN0aW5nJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4m Z3Q7Jm5ic3A7ICZndDsgZGVwbG95bWVudC4gQXNzdW1pbmcgdGhhdCB0aGUgZXh0ZXJuYWwgUFNL IGNhbm5vdCBiZSB1c2VkIHRvZ2V0aGVyJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mZ3Q7 Jm5ic3A7ICZndDsgd2l0aCB0aGUgaW1wb3J0ZWQgaWRlbnRpdGllcywgdGhlIFRMUyBjbGllbnQg YW5kIHNlcnZlciBtdXN0IGludHJvZHVjZSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jmd0 OyZuYnNwOyAmZ3Q7IHRoZSBtZWNoYW5pc20gYXQgdGhlIHNhbWUgdGltZSwgdGhhdCBpcyBvZnRl biBub3QgcG9zc2libGUgdG8gY29udHJvbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZndDsmbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZndDsmbmJzcDsgWW914oCZcmUgY29ycmVjdCB0aGF0 IHRoaXMgcmVxdWlyZXMgYm90aCBlbmRwb2ludHMgdG8gYWRvcHQgdGhlIGNoYW5nZSZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jmd0OyZuYnNwOyBzaW11bHRhbmVvdXNseS4gSG93ZXZlciwg dGhhdCBkb2VzIG5vdCBjb250cmFkaWN0IHRoZSBxdW90ZWQgdGV4dCwgd2hpY2gmbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPiZndDsmbmJzcDsgc3RhdGVzIHRoYXQgdGhlIHByb3RvY29sIGlz IG5vdCBjaGFuZ2VkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jmd0OyZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+Jmd0OyZuYnNwOyAmZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mZ3Q7Jm5i c3A7ICZndDsgLSDigJxzdHJ1Y3QgezxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jmd0OyZuYnNwOyAm Z3Q7IG9wYXF1ZSBleHRlcm5hbF9pZGVudGl0eSZsdDsxLi4uMl4xNi0xJmd0Ozs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPiZndDsmbmJzcDsgJmd0OyBvcGFxdWUgbGFiZWwmbHQ7MC4uMl44LTEmZ3Q7 OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jmd0OyZuYnNwOyAmZ3Q7IEhhc2hBbGdvcml0aG0gaGFz aDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZndDsmbmJzcDsgJmd0OyB9IEltcG9ydGVkSWRlbnRp dHk7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mZ3Q7Jm5ic3A7ICZndDsg4oCdPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij4mZ3Q7Jm5ic3A7ICZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZndDsmbmJz cDsgJmd0OyBUaGlzIHNjYWxlcyBwb29ybHksIEEgY2xpZW50IGhhcyB0byBzZW5kIG4qbSBpZGVu dGl0aWVzIHdoZXJlIG4gaXMgdGhlJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mZ3Q7Jm5i c3A7ICZndDsgbnVtYmVyIG9mIHN1cHBvcnRlZCB2ZXJzaW9ucyBhbmQgbSBpcyB0aGUgbnVtYmVy IG9mIHN1cHBvcnRlZCBoYXNoJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mZ3Q7Jm5ic3A7 ICZndDsgYWxnb3JpdGhtcy4uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jmd0OyZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+Jmd0OyZuYnNwOyBZZXMsIHRoaXMgaXMgYSB0cmFkZW9mZiB3ZSBt YWRlIGJ5IG9wdGluZyB0byBub3QgbW9kaWZ5IHRoZSBrZXkmbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPiZndDsmbmJzcDsgc2NoZWR1bGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mZ3Q7Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mZ3Q7Jm5ic3A7ICZndDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPiZndDsmbmJzcDsgJmd0OyAtIFdvdWxkIGl0IG5vdCBiZSBwb3NzaWJsZSB0byBqdXN0 IHVzZSB0aGUgdmVyc2lvbiBudW1iZXIgYXMgbGFiZWw/Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij4mZ3Q7Jm5ic3A7ICZndDsgSS5lLiAweDAzMDQgaW5zdGVhZCBvZiDigJx0bHMxM+KAnS4g SW4gdGhhdCB3YXkgeW91IGRvIGF0IGxlYXN0IG5vdCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+Jmd0OyZuYnNwOyAmZ3Q7IGhhdmUgdG8gZGVmaW5lIGEgbmV3IGxhYmVscy48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPiZndDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZndDsmbmJzcDsg V2UgcHJvYmFibHkgY291bGQsIHRob3VnaCBzaW5jZSB0aGUgbGFiZWxzIGFyZSBzdWJqZWN0IHRv IGNoYW5nZSAoc2VlJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mZ3Q7Jm5ic3A7IHRoZSBU T0RPIGFib3V0IHBvc3NpYmx5IGluY2x1ZGluZyB0aGUgSGFzaEFsZ29yaXRobSBpbiB0aGUgbGFi ZWwpLCB3ZSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jmd0OyZuYnNwOyBrZXB0IGl0IGFz IGlzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+Jmd0OyZuYnNwOyAmZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mZ3Q7Jm5ic3A7ICZndDsg LSDigJxUTFMgMS4zIFtSRkM4NDQ2XSBzdXBwb3J0cyBwcmUtc2hhcmVkIGtleSAoUFNLKSByZXN1 bXB0aW9uLCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jmd0OyZuYnNwOyAmZ3Q7IHdoZXJl aW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZndDsmbmJzcDsgJmd0OyBQU0tzIGNhbiBiZSBlc3Rh Ymxpc2hlZCB2aWEgc2Vzc2lvbiB0aWNrZXRzIGZyb20gcHJpb3IgY29ubmVjdGlvbnMgb3I8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPiZndDsmbmJzcDsgJmd0OyBleHRlcm5hbGx5IHZpYSBzb21lIG91 dC1vZi1iYW5kIG1lY2hhbmlzbS7igJ08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZndDsmbmJzcDsg Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jmd0OyZuYnNwOyAmZ3Q7IFRoaXMgc2VlbXMgdG8g aW5kaWNhdGUgdGhhdCBhbGwgdXNlIG9mIFBTSyBpcyByZXN1bXB0aW9uIHdoaWNoIGlzIG5vdCZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jmd0OyZuYnNwOyAmZ3Q7IGNvcnJlY3QuIEkgc3Vn Z2VzdCBjaGFuZ2luZyB0byDigJxUTFMgMS4zIFtSRkM4NDQ2XSBzdXBwb3J0cyZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+Jmd0OyZuYnNwOyAmZ3Q7IHByZS1zaGFyZWQga2V5IChQU0spIGF1 dGhlbnRpY2F0aW9u4oCdPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mZ3Q7Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij4mZ3Q7Jm5ic3A7IEdvb2Qgc3VnZ2VzdGlvbiEgV2XigJlsbCBmaXggaXQu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mZ3Q7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4m Z3Q7Jm5ic3A7ICZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZndDsmbmJzcDsgJmd0OyAtIOKA nGltcG9ydGluZyBleHRlcm5hbCBQU0sgKFByZS1TaGFyZWQgS2V5KSBpbnRvIFRMUy7igJ08bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPiZndDsmbmJzcDsgJmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ Jmd0OyZuYnNwOyAmZ3Q7IE5vdCBzdXJlIGlmIOKAnGludG/igJ0gaXMgdGhlIHJpZ2h0IHdvcmQs IEkgdGhpbmsg4oCcZm9y4oCdIGFzIGluIHRoIGUmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PiZndDsmbmJzcDsgJmd0OyB0aXRsZSBpcyBiZXR0ZXIuIFRoZSBtZWNoYW5pc20gc2VlbXMgdmVy eSBtdWNoIGV4dGVybmFsIHRvIFRMUyBpdHNlbGYuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij4mZ3Q7Jm5ic3A7ICZndDsgSSBzZWUgaXQgYXMgYSBtZWNoYW5pc20gdG8gZGVyaXZlIHNldmVy YWwgZXh0ZXJuYWwgUFNLcyBmcm9tIGEgc2luZ2xlJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij4mZ3Q7Jm5ic3A7ICZndDsgZXh0ZXJuYWwgUFNLLi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZn dDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZndDsmbmJzcDsgRGl0dG8uPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij4mZ3Q7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mZ3Q7Jm5ic3A7 ICZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZndDsmbmJzcDsgJmd0OyAtIOKAnFNpbWlsYXJs eSwgVExTIDEuMiBhbmQgYWxsIHByaW9yIFRMUyB2ZXJzaW9ucyBzaG91bGQgdXNlICZxdW90O3Rs czEyJnF1b3Q7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mZ3Q7Jm5ic3A7ICZndDsg4oCc PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mZ3Q7Jm5ic3A7ICZndDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPiZndDsmbmJzcDsgJmd0OyBUaGUgdmVyc2lvbnMgcHJpb3IgdG8gVExTIDEuMiB3aWxsIHNv b24gYmUgZGVwcmVjYXRlZC4gQW5kIHdoeSBzcGVuZCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+Jmd0OyZuYnNwOyAmZ3Q7IHRpbWUgdXBkYXRpbmcgdGhlIFRMUyAxLjIgY29kZSBiYXNlIGlu c3RlYWQgb2YgbW92aW5nIHRvIFRMUyAxLjM/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mZ3Q7Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mZ3Q7Jm5ic3A7IFdl4oCZcmUganVzdCBjb3Zlcmlu ZyBvdXIgYmFzZXMgaGVyZS4gSSB0ZW5kIHRvIGFncmVlIHRoYXQgdGhlIGZvY3VzJm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij4mZ3Q7Jm5ic3A7IHNob3VsZCBiZSBvbiB1cGRhdGluZyB0byBU TFMgMS4zIGluc3RlYWQgb2Yg4oCccGF0Y2hpbmfigJ0gVExTIDEuMiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+Jmd0OyZuYnNwOyBzdGFja3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mZ3Q7 Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mZ3Q7Jm5ic3A7ICZndDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPiZndDsmbmJzcDsgJmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jmd0OyZuYnNw OyAmZ3Q7IFN1Z2dlc3Rpb246PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mZ3Q7Jm5ic3A7ICZndDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPiZndDsmbmJzcDsgJmd0OyBJbnN0ZWFkIG9mIGRlcml2aW5n IGEgbGFyZ2Ugc2V0IG9mIG5ldyBleHRlcm5hbCBQU0tzLCB3b3VsZG7igJl0IGl0IGJlJm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mZ3Q7Jm5ic3A7ICZndDsgcG9zc2libGUgdG8ganVzdCB1 c2UgZGlmZmVyZW50IGhhc2ggZnVuY3Rpb25zIGluIGRpZmZlcmVudCBwYXJ0cyBvZiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jmd0OyZuYnNwOyAmZ3Q7IHRoZSBrZXkgaGllcmFyY2h5PyBJ LmUuIGlmIFNIQS0yNTYgaXMgYXNzb2NpYXRlZCB3aXRoIHRoZSBleHRlcm5hbCBQU0smbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPiZndDsmbmJzcDsgJmd0OyBhbmQgU0hBLTM4NCBpcyB0aGUg aGFzaCBhbGdvcml0aG1zIGluIHRoZSBjaG9zZW4gY2lwaGVyIHN1aXRlOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+Jmd0OyZuYnNwOyAmZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mZ3Q7Jm5ic3A7 ICZndDsgUFNLIC0mZ3Q7IEhLREYtRXh0cmFjdChTSEEtMjU2KSA9IEVhcmx5IFNlY3JldDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+Jmd0OyZuYnNwOyAmZ3Q7IHw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PiZndDsmbmJzcDsgJmd0OyAmIzQzOy0tLS0tJmd0OyBEZXJpdmUtU2VjcmV0KC4sICZxdW90O2V4 dCBiaW5kZXImcXVvdDsgfCAmcXVvdDtyZXMgYmluZGVyJnF1b3Q7LCAmcXVvdDsmcXVvdDspPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij4mZ3Q7Jm5ic3A7ICZndDsgfCA9IGJpbmRlcl9rZXk8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPiZndDsmbmJzcDsgJmd0OyB8PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4m Z3Q7Jm5ic3A7ICZndDsgJiM0MzstLS0tLSZndDsgRGVyaXZlLVNlY3JldCguLCAmcXVvdDtjIGUg dHJhZmZpYyZxdW90OywgQ2xpZW50SGVsbG8pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mZ3Q7Jm5i c3A7ICZndDsgfCA9IGNsaWVudF9lYXJseV90cmFmZmljX3NlY3JldDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+Jmd0OyZuYnNwOyAmZ3Q7IHw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZndDsmbmJzcDsg Jmd0OyAmIzQzOy0tLS0tJmd0OyBEZXJpdmUtU2VjcmV0KC4sICZxdW90O2UgZXhwIG1hc3RlciZx dW90OywgQ2xpZW50SGVsbG8pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mZ3Q7Jm5ic3A7ICZndDsg fCA9IGVhcmx5X2V4cG9ydGVyX21hc3Rlcl9zZWNyZXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZn dDsmbmJzcDsgJmd0OyB2PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mZ3Q7Jm5ic3A7ICZndDsgRGVy aXZlLVNlY3JldCguLCAmcXVvdDtkZXJpdmVkJnF1b3Q7LCAmcXVvdDsmcXVvdDspPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij4mZ3Q7Jm5ic3A7ICZndDsgfDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jmd0 OyZuYnNwOyAmZ3Q7IHY8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZndDsmbmJzcDsgJmd0OyAoRUMp REhFIC0mZ3Q7IEhLREYtRXh0cmFjdChTSEEtMzg0KSA9IEhhbmRzaGFrZSBTZWNyZXQ8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPiZndDsmbmJzcDsgJmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jmd0 OyZuYnNwOyAmZ3Q7IFN1cHBvcnQgb2YgdGhpcyBjb3VsZCBiZSBzaWduYWxsZWQgd2l0aCB0aGUg dGxzX2ZsYWdzIGV4dGVuc2lvbi4gSWYmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZndDsm bmJzcDsgJmd0OyB0aGUgc2VydmVyIGRvZXMgbm90IHN1cHBvcnQgdGhlIGV4dGVuc2lvbiBpdCBt dXN0IGFjY29yZGluZyB0byBSRkMmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZndDsmbmJz cDsgJmd0OyA4NDQ2IGNob3NlIGEgY2lwaGVyIHN1aXRlIHdpdGggU0hBLTI1Ni48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPiZndDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZndDsmbmJzcDsg TW9kaWZ5aW5nIHRoZSBrZXkgc2NoZWR1bGUgd2FzIGRpc2N1c3NlZCBpbiB0aGUgY29udGV4dCBv ZiBbMl0uLiBBdCB0aGUmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZndDsmbmJzcDsgdGlt ZSwgaXQgc2VlbWVkIHRoZSBkZXNpcmUgdG8gbm90IHRvdWNoIHRoZSBrZXkgc2NoZWR1bGUgb3V0 d2VpZ2hlZCB0aGUmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZndDsmbmJzcDsgZGVzaXJl IHRvIG5vdCBpbmZsYXRlIHRoZSBDbGllbnRIZWxsby48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZn dDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZndDsmbmJzcDsgQmVzdCw8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPiZndDsmbmJzcDsgQ2hyaXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZndDsm bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZndDsmbmJzcDsgWzFdIGh0dHBzOi8vZ2l0aHVi LmNvbS9jaHJpcy13b29kL2RyYWZ0LXdvb2QtdGxzLWV4dGVybmFsLXBzay1pbXBvcnRlcjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+Jmd0OyZuYnNwOyBbMl0gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWRhdmlkYmVuLXRscy11bml2ZXJzYWwtcHNrLTAwPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij4mZ3Q7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mZ3Q7Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij4mZ3Q7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5UTFMgbWFpbGluZyBsaXN0PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij5UTFNAaWV0Zi5vcmc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_008538ABFBE04132A9FD18BAE1F3F4FCericssoncom_-- From nobody Tue Apr 9 18:36: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 8F79912014D for ; Tue, 9 Apr 2019 18:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.691 X-Spam-Level: X-Spam-Status: No, score=-2.691 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_FROM_FMBLA_NEWDOM14=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=RJq2EKDr; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Ybsu2Y48 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAIf3G0M5uXs for ; Tue, 9 Apr 2019 18:36:54 -0700 (PDT) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2625B12014A for ; Tue, 9 Apr 2019 18:36:51 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailnew.nyi.internal (Postfix) with ESMTP id 607B514B10; Tue, 9 Apr 2019 21:36:50 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Tue, 09 Apr 2019 21:36:50 -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:content-transfer-encoding; s=fm1; bh=DNFZn 65qSZjl8D3DB+IpTqAh5Bqriw4iAkTgXbfHVE8=; b=RJq2EKDrxF/JGgFkBZtI9 iI3Qvy1zuPpiuK6J/SF7gDHT/+YmWPlP7lA6FlpFyRNFRLan7LWx3vDvl/F3t/ZA WyV+qI1gG0YC0ucmZydl+jCt24HBmuxxPVIMVNwj2ZFj0YYm8Ssnyamh2+u+xlG0 ipwkFEv+SYVKmmjCgvgmMRlNdDumH/9ymafluKi0+tIlrEFK0vDdTTQ5l07SFYxk pTjHtxoAwMPZERLoZXDJzV4KNTCAXtXYfE8RL3XXiesKGSIYezAKFRW2VX5zWZkI 2k6eZNJZRSnG5kHILbkNYhwLjDjlUQCCsG0T6AiwgXRUri8jOYG0nC1TgAu0xdpa A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding: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=fm2; bh=DNFZn65qSZjl8D3DB+IpTqAh5Bqriw4iAkTgXbfHV E8=; b=Ybsu2Y48WvV08h8zuxnun55+EVBrS99eaPuj0l4TiX3mqp3inKQajoZza 305VT4TO2te1KnlaujHRvtX0/vvcGL819E2Ljc8XdYhnuhI/sqHAoczhaQJL0p+/ VdL2xf41S/EW0DVelgjtcgnVGKpX5mT6Cy3pR/eznR/36D8ro0/yyD76kAbfdqMg Xh3wKJUMQAOUjgh8e4g8amkxB0gOIVzMuAMezu9mgwR559jh2nB6iaTww+NJx/bp L9i6oY2FTJ+QDqF3Wyrg5M+5/K0K9EHAN3fPW+W7rCF2B5vms6E2gE+SePoYuEsL zfkle6ETVB6fq6/rqTLIbH2c0/dOg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudeigdeglecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdevhhhr ihhsthhophhhvghrucghohhougdfuceotggrfieshhgvrghpihhnghgsihhtshdrnhgvth eqnecurfgrrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrphhinhhgsghithhsrdhn vghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id AD9812602F; Tue, 9 Apr 2019 21:36:49 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-329-gf4aae99-fmstable-20190329v1 Mime-Version: 1.0 X-Me-Personality: 94902928 Message-Id: <77f45fd4-3311-4edb-bfea-d74984fcf4eb@www.fastmail.com> In-Reply-To: <008538AB-FBE0-4132-A9FD-18BAE1F3F4FC@ericsson.com> References: <89127FF7-CE3F-4DF1-98A5-B1006C5FF56B@ericsson.com> <008538AB-FBE0-4132-A9FD-18BAE1F3F4FC@ericsson.com> Date: Tue, 09 Apr 2019 21:36:04 -0400 From: "Christopher Wood" To: "John Mattsson" , "TLS@ietf.org" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Comments on draft-wood-tls-external-psk-importer-01 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, 10 Apr 2019 01:36:57 -0000 Hi John, On Tue, Apr 9, 2019, at 11:53 AM, John Mattsson wrote: > =20 > Hi Chris, >=20 > Thanks for the discussion. Would be good if a future version: Likewise -- thank you for the comments! > - Made clear if the imported PSKs MUST NOT / SHOULD NOT / MAY / SHOULD= =20 > / MUST be offered alongside the existing external PSKs. While offering= =20 > both would make a migration path possible I don=E2=80=99t think it is = the way=20 > to go. Yep, we'll clear this up. (I'm currently leaning towards *not* allowing = it.) > - If MUST NOT, the document should maybe also state what the client do= =20 > if it receives a unknown_psk_identity alert, is it allowed to try agai= n=20 > with the external (non-imported identity) or is it forbidden to do so?= Good question! I'll file an issue to track and resolve this.=20 > - Made clear if use of draft-wood-tls-external-psk-importer is a=20 > property of the TLS implementation (i.e. used on all PSK) or a propert= y=20 > of the external PSK (i.e. only used on keys with this property). It's the former, for all external PSKs. We'll try to clarify this. > - State that "tls12" is used for DTLS 1.2 and "tls13" is used for DTLS= 1.3. +1=20 Thanks again for the comments and review. Best, Chris From nobody Tue Apr 9 20:52: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 915E71202F9 for ; Tue, 9 Apr 2019 20:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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 (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 5Fj7mlVFNRwg for ; Tue, 9 Apr 2019 20:51:59 -0700 (PDT) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07F0512022D for ; Tue, 9 Apr 2019 20:51:58 -0700 (PDT) Received: by mail-qt1-x82e.google.com with SMTP id k2so1339660qtm.1 for ; Tue, 09 Apr 2019 20:51:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=/5r2sn5aTO/3APmS86AES522tKCquVDMcXHgxECjcTI=; b=JYMOeRoVpbPGs6jJOx390V/+TgJK/Lu5DS/uLHE+65E5dadzu0otP0KWha2KT2c3Si cpEcSUQ1g7bU4emz+8H9q8vEkyjAxejtRsntxLoNNLTPaPdS0j9HG/kWY1gQzSLjVMy2 62nxmmqFLcr1B96cktTZInllBN3F0QeTE3J2Oz9rixU7hK/WMp6nlWUJ5NFLrrVq1NAo BqSDLmDI1BUZrZjGUzHEch9aT4ijobzMebyP9BDhg/6WLd7q3W81fNcp81KZlW4kwsy1 fxi0Kc8XT5WfHzY6eNt50gp6QRUbpvVXSo/iLXa32XWq7tkoQ7oiXHtUiyvhzkS4xnVE 3/9g== 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=/5r2sn5aTO/3APmS86AES522tKCquVDMcXHgxECjcTI=; b=fJI7FmhcZ8nhlDkHFOJcL/sff3UQFXXj7uI5Pf6cgksYAFKxfc/xhRpcesb1RuK5Lo kupJcrWNqC4y313qKkBGcZP2HsBwofV6YfF0Ek8PFoly5DAsKRrzOP9DRbmwWGp7em81 q2j4rdQfGNLzC148OIvztLjxy65kge7isHvxLqz2AU5GO8XYTM0ATTlePuiWI4LsrYXA I5nn4+SEUrHol/ORzCO7G/5/WKR1/kyIg1UXBBZVb+DxoIG+4mJd6YHC9RtWH/nVOEXb StEqYyVjSjTNHBxyzjjQBdlEe2ZUD0wJX9pdmPKPRmoH4504cO3HkPo1LcxcYKkdH/we IyeQ== X-Gm-Message-State: APjAAAXMuc/WmLvBiGlls2vaP/2jJSXU66bSb3xO4JxO3pyjrCItQ98c FPrQ0nwGfVtcJWjDmQw6eSbWqvpl5FhGfmRB3NrOq7iv9Dw= X-Google-Smtp-Source: APXvYqxT08nZ94asM+eGBI7QDCnSNquKkiq1/TAnLl8z1HGgsMdzMKygUZ7uDDBzes2nd7o+YbideMfkB3eCITDhIDQ= X-Received: by 2002:a0c:92e2:: with SMTP id c31mr359591qvc.87.1554868317695; Tue, 09 Apr 2019 20:51:57 -0700 (PDT) MIME-Version: 1.0 From: Joseph Salowey Date: Tue, 9 Apr 2019 20:51:46 -0700 Message-ID: To: "" Content-Type: multipart/alternative; boundary="000000000000bfc51b058624fd93" Archived-At: Subject: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk 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, 10 Apr 2019 03:52:01 -0000 --000000000000bfc51b058624fd93 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This is the working group last call for the "TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key=E2=80=9D d= raft available at https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk/= . Please review the document and send your comments to the list by 2359 UTC on 23 April 2019. Thanks, Chris, Joe, and Sean --000000000000bfc51b058624fd93 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is the wo= rking group last call for the "TLS 1.3 Extension for Certificate-based= Authentication with an External Pre-Shared Key=E2=80=9D draft available at= =C2=A0https://datatracker.ietf.org/doc/draft= -ietf-tls-tls13-cert-with-extern-psk/. Please review the document and s= end your comments to the list by 2359 UTC on 23 April 2019.
=
Thanks,
Chris, Joe, and Sean
--000000000000bfc51b058624fd93-- From nobody Tue Apr 9 23:28: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 06AF5120149 for ; Tue, 9 Apr 2019 23:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_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=ericsson.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 RIpc2kQwDmU9 for ; Tue, 9 Apr 2019 23:28:26 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20067.outbound.protection.outlook.com [40.107.2.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6285120048 for ; Tue, 9 Apr 2019 23:28:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AtVPv3HE5dZ3rgxz8l4rcM0ISyUMzfIJBwoANJPfNTw=; b=MV2CXVShGgn2Vm24+2NzIR7dMgI2V1fv013HTEvAP+DCJGTveMV43PBp4gs4/SAyaQEA72V1HSiZNXeoKQo3EPATZ7tHaJBEX6+Ni5NnBKCy8OZaK7jiLKzTSXN4VHGq6SzViEOPR88xicC44A3/7ppbukxsMId8NKE38rkh3Fo= Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.166.22) by HE1PR07MB4187.eurprd07.prod.outlook.com (20.176.166.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.8; Wed, 10 Apr 2019 06:28:22 +0000 Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::d49e:f22a:1e0b:f888]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::d49e:f22a:1e0b:f888%5]) with mapi id 15.20.1792.007; Wed, 10 Apr 2019 06:28:22 +0000 From: John Mattsson To: Melinda Shore , "tls@ietf.org" Thread-Topic: [TLS] WG adoption call: draft-wood-tls-external-psk-importer Thread-Index: AQHU7m8vhBtBKh81KEOxzhJN6LesdaYzMFUAgAAhl4CAAb/rgA== Date: Wed, 10 Apr 2019 06:28:22 +0000 Message-ID: References: <7d640638-c1eb-b430-e084-e3808220ab88@nomountain.net> In-Reply-To: <7d640638-c1eb-b430-e084-e3808220ab88@nomountain.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.17.1.190326 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [82.214.46.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8d10ad64-3522-45d9-53f1-08d6bd7dbb12 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR07MB4187; x-ms-traffictypediagnostic: HE1PR07MB4187: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 00032065B2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(366004)(136003)(396003)(376002)(13464003)(199004)(189003)(58126008)(4744005)(6306002)(6246003)(82746002)(5660300002)(2906002)(7736002)(53936002)(6512007)(44832011)(25786009)(305945005)(14444005)(97736004)(110136005)(256004)(229853002)(316002)(486006)(6506007)(105586002)(11346002)(6436002)(99286004)(66066001)(102836004)(33656002)(478600001)(53546011)(68736007)(26005)(106356001)(966005)(86362001)(81166006)(2501003)(476003)(71190400001)(186003)(14454004)(2616005)(83716004)(81156014)(71200400001)(36756003)(8936002)(446003)(3846002)(6116002)(8676002)(6486002)(76176011); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4187; H:HE1PR07MB4169.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: ScxlltQNCNnc2PvzJ6y9gLASzd0GkxjAv5dw3+7wNIIR3MdgRBQt1TpJNWqv8PPkIIm3Wla3WKSQ/JTLkt7qCQP3ShNrTEAQVoIbirDWj2lRID6NObJkUV9FTbWsElgo4mBwZdJKyT8FknBZBIkCbbtToFppHmxQQaZP+EG+bVJ8gq4XCNmM1aFFH7sKPVrR2y5ddxXqSsJNDXuYFBV2nkXcd9K1BHxrANNB5/YUIx1ITL0nqR878dgAIqezK26R13KhWtOCJ9tE0rwb5DHgv0c8NyJJ690rG141QoOjyM/NAOu6dvQ6bgWAxjlmnWIu7FEg4Xj77dD4JWY1stUedUVFSXXxwRq6JmKALyuzfZojIhY8ccrDO7ApD9iDj2ZNwiCs436R3v/JpI09SYwTtnq1pRcWBN4sNPEp4ZN5V/U= Content-Type: text/plain; charset="utf-8" Content-ID: <87D870062E63D245BFD947B3B4322EA4@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8d10ad64-3522-45d9-53f1-08d6bd7dbb12 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2019 06:28:22.4884 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4187 Archived-At: Subject: Re: [TLS] WG adoption call: draft-wood-tls-external-psk-importer 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, 10 Apr 2019 06:28:29 -0000 KzENCg0KKEkgYW0gbm90IHN1cmUgdGhpcyBpcyB0aGUgYmVzdCB3YXkgdG8gaGFuZGxlIGV4dGVy bmFsIFBTSyBsb25nIHRlcm0sIGJ1dCBpdCBzZWVtcyBsaWtlIGdvb2Qgd2F5IHRvIGFkZHJlc3Mg dGhpcyBpc3N1ZSBmb3IgdGhlIG1vbWVudCB3aXRob3V0IG1ha2luZyBjaGFuZ2VzIHRvIFRMUyAx LjMpDQoNCu+7vy0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBUTFMgPHRscy1ib3Vu Y2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgTWVsaW5kYSBTaG9yZSA8bWVsaW5kYS5zaG9yZUBu b21vdW50YWluLm5ldD4NCkRhdGU6IFR1ZXNkYXksIDkgQXByaWwgMjAxOSBhdCAwNzo0NQ0KVG86 ICJUTFNAaWV0Zi5vcmciIDx0bHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1RMU10gV0cgYWRv cHRpb24gY2FsbDogZHJhZnQtd29vZC10bHMtZXh0ZXJuYWwtcHNrLWltcG9ydGVyDQoNCiAgICBP biBUdWUsIEFwciA5LCAyMDE5LCBhdCAxMDo1NywgU2VhbiBUdXJuZXIgd3JvdGU6DQogICAgPiBB dCBUTFNASUVURjEwNCwgdGhlcmUgd2FzIGNvbnNlbnN1cyBpbiB0aGUgcm9vbSB0byBhZG9wdCAN CiAgICA+IGRyYWZ0LXdvb2QtdGxzLWV4dGVybmFsLXBzay1pbXBvcnRlci4gIFRoaXMgbWVzc2Fn ZSBpcyB0byBjb25maXJtIHRoYXQgDQogICAgPiBjb25zZW5zdXMuICBJZiB5b3UgZG8gbm90IHN1 cHBvcnQgYWRvcHRpb24gb2YgDQogICAgPiBkcmFmdC13b29kLXRscy1leHRlcm5hbC1wc2staW1w b3J0ZXIgYXMgV0cgaXRlbSBwbGVhc2Ugc2F5IHNvIGJ5IA0KICAgID4gMjM1OVVUQyBvbiAyMiBB cHJpbCAyMDE5IChhbmQgc2F5IHdoeSkuDQogICAgDQogICAgSSBzdXBwb3J0IGFkb3B0aW9uLg0K ICAgIA0KICAgIE1lbGluZGENCiAgICANCiAgICAtLSANCiAgICBNZWxpbmRhIFNob3JlDQogICAg bWVsaW5kYS5zaG9yZUBub21vdW50YWluLm5ldA0KICAgIA0KICAgIFNvZnR3YXJlIGxvbmdhLCBo YXJkd2FyZSBicmV2aXMNCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KICAgIFRMUyBtYWlsaW5nIGxpc3QNCiAgICBUTFNAaWV0Zi5vcmcN CiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rscw0KICAgIA0KDQo= From nobody Wed Apr 10 19:57: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 96CC1120471 for ; Wed, 10 Apr 2019 19:57:52 -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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=n0Qdg9rf; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ghQU7h0Z Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzLtC6m6aHbB for ; Wed, 10 Apr 2019 19:57:51 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E94F512046F for ; Wed, 10 Apr 2019 19:57:50 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id D5E5920EF7 for ; Wed, 10 Apr 2019 22:57:49 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Wed, 10 Apr 2019 22:57:49 -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 :subject:content-type; s=fm1; bh=camT3B+xczvUipuemyUBJmbQ9oe5PcG TtcAcJpUkeDA=; b=n0Qdg9rf2Aa0K9CvMaytXRzcsVXP6kXLeLwccU6iNdBLw2o 55gtyUzLztrTuWa+tglr3tTjtQDXBd0q548jbCWIhXmZavEbbpAsRwst0SBBN2lE kT0MqigL15d/WHoCX+4e9EMoasmZob/NPlw73iwbDXJK629Iz1pA2w9WD8wXJiu8 X5bKvt5G1LMylgDbHShUh6H+/2h2+RCmAl2ErT4JWxYuYsVQFYM4WluxtyM0/AgO 8uflBmY5b4AqzNTp4T3rp0wBYbtSCdj9Jl8xWgqRNno+uyytJkjqXwI3bbygX1Qt m5tDb3x1nuhjBPZOhDoCPMmfacWmDFS+Uoq8NXw== 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=fm2; bh=camT3B +xczvUipuemyUBJmbQ9oe5PcGTtcAcJpUkeDA=; b=ghQU7h0ZoXikeoEVdrYGLk NyNZi1ajrPdZR8t/G6aGlA5tb2m9xu5n3Z6yYuQS/EMdrcIYd1UHsPXuodexyyPm yW4ZmyzuBFYt1D0h42Lc6fFF7840TvQWUDU1iJKXn66nPrkfI2yv50uoog21p+XX dJwGVyDdUdcR+RQdFo7LR+MOUpUa1+n4dipTY4CH3IFWqEf5HUlEq8eF4yRbU25Z t+tN7SzUqUlFeN+VMl+cVvCH2WSF/tGUIqC6JGRB+8er3xIaTHj5USJegIR6U6si cGCQO3y+o3nX9mvakbuE/mxwKNXSXad+tAk0j0I/mmmF8gwXfGQBDoPCc8VTzV6A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudekgdehkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofi gvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 8130F7C130; Wed, 10 Apr 2019 22:57:49 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-329-gf4aae99-fmstable-20190329v1 Mime-Version: 1.0 X-Me-Personality: 92534000 Message-Id: <523c1d42-c4bb-4206-b9be-bcec93973424@www.fastmail.com> In-Reply-To: <3C099064-52D9-49C3-9180-A01FBDEE876A@ericsson.com> References: <745ED9FE-9C31-4687-BD64-836155A28AEC@ericsson.com> <3C099064-52D9-49C3-9180-A01FBDEE876A@ericsson.com> Date: Wed, 10 Apr 2019 22:57:52 -0400 From: "Martin Thomson" To: tls@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [TLS] Comment on draft-thomson-tls-sic-00 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, 11 Apr 2019 02:57:53 -0000 On Sat, Mar 30, 2019, at 06:05, John Mattsson wrote: > And one more.... > > "The 0xTBD flag can only be send in a ClientHello or CertificateRequest > message. Endpoints that receive a value of 1 in any other handshake > message MUST generate a fatal illegal_parameter alert." > > This goes against draft-nir-tls-tlsflags > > "A server that supports this extension and also supports at least one > of the flag-type features that use this extension and that were > declared by the ClientHello extension SHALL send this extension with > the intersection of the flags it supports with the flags declared by > the client." > > I assume the sic sic extension should be sent in EncryptedExtensions. I think that this is a problem in draft-nir-tls-tlsflags. Extensions in ClientHello are "answered" in two places: EncryptedExtensions and Certificate. The requirement that the flag be echoed creates a problem in that context. We could define separate "Handshake flags" and "Certificate flags", but that complicates things. If you look at extension usage, you see that not all "flags" are echoed. In this case, a requirement to echo would just increase the size of Certificate for no good reason - the extension can be omitted completely. We should only require the presence of the flag where it carries semantics. The requirement should be stated as Implementations MUST NOT set flags in extension responses if the remote endpoint did not send the corresponding flag in extension requests. Upon receiving a flag that is incorrectly set, an endpoint MUST abort the handshake with an "unsupported_extension" [?] alert. Mirroring the language from RFC 8446. From nobody Fri Apr 12 00:12:14 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 B887812016F for ; Fri, 12 Apr 2019 00:12:11 -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_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 lZ5waJlH8-SK for ; Fri, 12 Apr 2019 00:12:09 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 BA91B120173 for ; Fri, 12 Apr 2019 00:12:09 -0700 (PDT) Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id DE5B71D0215B66CFBA75 for ; Fri, 12 Apr 2019 08:12:04 +0100 (IST) Received: from SINEML704-CAH.china.huawei.com (10.223.161.54) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 12 Apr 2019 08:12:04 +0100 Received: from SINEML521-MBX.china.huawei.com ([169.254.1.173]) by SINEML704-CAH.china.huawei.com ([10.223.161.54]) with mapi id 14.03.0415.000; Fri, 12 Apr 2019 15:12:02 +0800 From: Wang Haiguang To: "tls@ietf.org" Thread-Topic: A new version of draft-wang-tls-raw-public-key-with-ibc has been uploaded to data tracker Thread-Index: AdTw/ijAOlZUg9JhTCC82NS64Sw14Q== Date: Fri, 12 Apr 2019 07:12:01 +0000 Message-ID: <0AE05CBFB1A6A0468C8581DAE58A31309E3A8C50@SINEML521-MBX.china.huawei.com> Accept-Language: en-SG, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.215.37.82] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [TLS] A new version of draft-wang-tls-raw-public-key-with-ibc has been uploaded to data tracker 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, 12 Apr 2019 07:12:12 -0000 Dear all,=20 A new version of draft-wang-tls-raw-public-key-with-ibc has been updated to= data tracker.=20 You can download it with following link: https://www.ietf.org/id/draft-wang-tls-raw-public-key-with-ibc-09.txt.=20 We have updated the draft based on the comments received from mailing list = and face-to-face discussions in last IETF meeting.=20 The major changes are: 1. We changed the intended status from standard to informational based on t= he concern raised in the mailing list.=20 2. We added one section for Identity format, which includes the expiring ti= me in the identity.=20 3. In security consideration part, we added in the security concerns discus= sed in the mailing list.=20 4. In IANA consideration, we remove OID requirement part since IANA has alr= eady assigned an OID for RFC 6507. Furthermore, we added request for the TL= S code point assignment.=20 Best regards. Haiguang From nobody Fri Apr 12 16:28: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 C1AC11203EB for ; Fri, 12 Apr 2019 16:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.69 X-Spam-Level: X-Spam-Status: No, score=-2.69 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_FROM_FMBLA_NEWDOM14=0.01, 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=HBvA1lQI; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=APOR4CUk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMg4jkPArG7X for ; Fri, 12 Apr 2019 16:28:38 -0700 (PDT) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6ED01203F5 for ; Fri, 12 Apr 2019 16:28:38 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailnew.nyi.internal (Postfix) with ESMTP id 0E7297F11 for ; Fri, 12 Apr 2019 19:28:38 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Fri, 12 Apr 2019 19:28:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:date:from:to:subject:content-type :content-transfer-encoding; s=fm1; bh=LsvL+TFv4yWBhrdxgYdHI+yjxO La6Rh+inb7wmLeRJA=; b=HBvA1lQI88x0Fl7eJm6dxyqrmy2gys+kZ9GrtVFxt3 MKMvuw77oCVE6UtrSsNnmJlsbQXS12kxDiwIF4xx4rUoWps9XTmaL1lRuWIElV+/ SYAligZkssbRAv+4m+LyLPTlWma0YJkV4XgnAPGCx333fU2YNvzJlIG1mFciJO5E m0yecy8sXXhl7ITV9IYNHjZXRCLcmU71lxrvE4UgVfUXXmIj+8Z+N/pE46UlH+cc 7A6YHv7PX5TcklH5CPToZDXqtYGWY1WFbeXPk8klCyRfz9srrdPHd+Lh5W2O0u+a aq6FIh+9xYIF2IUuVr2L9CxxiUyDP0TR1dw0juCWsN7Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=LsvL+T Fv4yWBhrdxgYdHI+yjxOLa6Rh+inb7wmLeRJA=; b=APOR4CUkVh8iyBmR2gibIR bhSMXTrB5iIouNnQJbqWKROzxprockyYg5YuozcSC7mb9LoRpYLNQ05oqrEj4co3 J5AS4UrA1V97EbDLtUtFCcP52eNWzt7FzeSJHms1Tl7IZO2V8RPiHZY21ftOl8m1 4WL1xjM1p5cLA1jCpIuq22oVpHeV76HMflIKdCwe5riwNt+Gh1xSlh6ZpsI+qFpx UniejGF0OLrqbv+B8qoEI7wPQv7IDid6moQ6aUREoDyGmZsihEDAnhgzRjugegcY XQEZQQqFXyvqTWUlv+rqm00Wrj69pUNu6Iu2EXkNFFo6LYbynaYw1dD0HI2OyYZA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrvdefgddulecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgfgsehtqhertd erreejnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgifsehh vggrphhinhhgsghithhsrdhnvghtqeenucffohhmrghinhepihgvthhfrdhorhhgnecurf grrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrphhinhhgsghithhsrdhnvghtnecu vehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1779A2602F; Fri, 12 Apr 2019 19:28:37 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-332-g22ddc6a-fmstable-20190412v1 Mime-Version: 1.0 X-Me-Personality: 94902928 Message-Id: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> Date: Fri, 12 Apr 2019 19:28:36 -0400 From: "Christopher Wood" To: "TLS@ietf.org" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [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, 12 Apr 2019 23:28:41 -0000 This is the working group last call for the "Deprecating TLSv1.0 and TLS= v1.1=E2=80=9D draft available at: https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecat= e/ Please review the document and send your comments to the list by April 2= 6, 2019. Thanks, Chris, Joe, and Sean From nobody Fri Apr 12 16:35: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 D0E421203EB for ; Fri, 12 Apr 2019 16:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.69 X-Spam-Level: X-Spam-Status: No, score=-2.69 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_FROM_FMBLA_NEWDOM14=0.01, 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=HZbB//4q; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=amw2oj2c Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0XEBbuEIT-a for ; Fri, 12 Apr 2019 16:35:42 -0700 (PDT) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EA9C12016A for ; Fri, 12 Apr 2019 16:35:42 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailnew.nyi.internal (Postfix) with ESMTP id B162A92FE for ; Fri, 12 Apr 2019 19:35:41 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Fri, 12 Apr 2019 19:35:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:date:from:to:subject:content-type; s= fm1; bh=pXiuFWJTP0mIcwsUFHNrn9efahV1DnwzxZ/hKOM/MVM=; b=HZbB//4q HyQVSwtU3arOe4SXvAa8RWlEPWwAb9+vCj8Nw55ARqvgkRo8VhWmwB6dAmexVDsv pq4tkEKdk9e/tpRtNiut9nx1XFF3dRCidg+jkieflT5PMXG0KEIITxPgDtbq55vz i8zHrzjLOMZ7jMCRZk8uhE3foIPTXOlKxcfdlvpLzLyEjn4ibBX8I2rH+XDWmDWX Ct6VNWF93bN0RtaTdUUMl7qvgaYMcD/oGfjUXH7CR8ln+uhSrBY/DwgMrBggUOtr kYpdDIVmqV7vTVIGt4I9NxfnX2qDQglO3FJq8cdYxn6V4GIDpKMEBw5xdpqjfZdp 0VCvxaguIZOBYw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=pXiuFWJTP0mIcwsUFHNrn9efahV1D nwzxZ/hKOM/MVM=; b=amw2oj2cW9frwpj0wRvcRDkgc6BjSavGUmJnzZqXRv/2c YqLyleO2GaAK0eEnLAQPqPZ8mSrrcELbu+fY3uMVKkWqjwlZgLLmQDy5zoJzXfUb kIHUz99BesDAKCWbYl8L6n+YCjyWk9VnyCN6i2+KI7OCG3nd3P1td1qoI/Tl8Ykk S5EAKuWBDV1amSxU5FTA8sJaK/P5Blle4reNiumQKPsB2PStlaxMmXfAhRpi6CPu y9nTFluFEGPbIW64dBkSkDRtQVbRuLw8n6Nc0v7mH0gLJDjbYcjAntgOz6cFiVEL +PvlLUHcVFXuQeiqbr66CvjqiN1ulnrYQJBKDSUgQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrvdefgddvudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesthdtredtre ertdenucfhrhhomhepfdevhhhrihhsthhophhhvghrucghohhougdfuceotggrfieshhgv rghpihhnghgsihhtshdrnhgvtheqnecuffhomhgrihhnpehivghtfhdrohhrghenucfrrg hrrghmpehmrghilhhfrhhomheptggrfieshhgvrghpihhnghgsihhtshdrnhgvthenucev lhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7DE7E2602F; Fri, 12 Apr 2019 19:35:40 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-332-g22ddc6a-fmstable-20190412v1 Mime-Version: 1.0 X-Me-Personality: 94902928 Message-Id: <4f21da8a-a30c-4255-9400-aab3a599fb9b@www.fastmail.com> Date: Fri, 12 Apr 2019 19:33:51 -0400 From: "Christopher Wood" To: "TLS@ietf.org" Content-Type: text/plain Archived-At: Subject: [TLS] Adoption call for draft-sy-tls-resumption-group 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, 12 Apr 2019 23:35:44 -0000 At TLS@IETF104, there was interest in the room to adopt draft-sy-tls-resumption-group as a WG item. The draft can be found here: https://datatracker.ietf.org/doc/draft-sy-tls-resumption-group/ This email starts the call for adoption. It will run until April 26, 2019. Please indicate whether or not you would like to see this draft adopted. Thanks, Chris, Joe, and Sean From nobody Fri Apr 12 18:59: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 D79CD1201AE for ; Fri, 12 Apr 2019 18:59:45 -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_PASS=-0.001, URIBL_RED=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 YAxdUt2fHi2p for ; Fri, 12 Apr 2019 18:59:44 -0700 (PDT) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2AF81200E3 for ; Fri, 12 Apr 2019 18:59:43 -0700 (PDT) Received: by mail-lf1-x12a.google.com with SMTP id h18so8832920lfj.11 for ; Fri, 12 Apr 2019 18:59:43 -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=XsiOAWgtjm6kO6JsNMI9A4wK/2rPtw6PGGP4M8YKHMs=; b=U6r6UQdXjRYvlbgYbHTNO0EpKOBplIFGf8QI2+jXps+3wnyXvTXiHz2mHYiiXcaYqo tKybv2weQC/z3Pkz6g1855e5++t1iNnrZgkbZotcg1S5OtHt09F/3laRvC0fdml3vtkT tHcuSsqfSAx4GQGpb3CmQ8v2cDFscLccXyzcRD3c11350Yv8c+8th8438IUvAjyI7mjW Q/Vo7joWZWDSG9ZXUhcV5Chve+lfC2bwS0Bd812tLh2WG0YbD5UofhfImS0mEdRRQXfs 5AzWH6KUskjGSes6jU/Hq3sOKIWd+g9xYBIsATLknlytJhAvccA3UaAWCI7w3K0Dxb24 mowA== 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=XsiOAWgtjm6kO6JsNMI9A4wK/2rPtw6PGGP4M8YKHMs=; b=j1a6iDSPUqIl0fXqYh8fk16lzAhZePRz4FWt426tREWo8fFx2RvlKKE7rr0kj1y6G8 CgHcGNpcFSNjs9tAq/GgxO7UKu+PMFYeXJANJS1XhRCYQ7ZiDir4gr8RMHCqZ4w7cX6W wYBIusORcKUGSDbolrVdkAHmFD7Kp3Cg7naojEqWymVCBgA8K8knL/LOY6Nogjm1wLQF rxxKFto6vqEOT1FF3AUu/56SSqU7TzCsyw7rQhkHLt08tZRmtIov+tPAScvIrIgYjtRB iHxmnx84s455ClcVoild/Sn8p7l3KiCWmD4ScxJt2uxF3KtZKGROtojDh1CCUOOWvYNH QV0A== X-Gm-Message-State: APjAAAUWU3GxMzMdfjfFvLF1GsgcdmAIkfC/Ovuph8eVQ4bBF1WXwXKA 17ft8ADEuJKDxnRa5SljtDqiPVrBeTF6KhNeutw9Cw== X-Google-Smtp-Source: APXvYqxwUMaPRJVUzqaXyuoc5Xi6NQccdUZc9gKOmAEfZFiJurtUZdqMUzPMyjCPbVqi3Tp3visPw8BD3xX17qG5GFE= X-Received: by 2002:a19:e30a:: with SMTP id a10mr15456042lfh.58.1555120781986; Fri, 12 Apr 2019 18:59:41 -0700 (PDT) MIME-Version: 1.0 References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> In-Reply-To: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> From: Watson Ladd Date: Fri, 12 Apr 2019 18:59:29 -0700 Message-ID: To: Christopher Wood Cc: TLS@ietf.org Content-Type: multipart/alternative; boundary="000000000000cb187d05865fc50e" 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, 13 Apr 2019 01:59:46 -0000 --000000000000cb187d05865fc50e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Apr 12, 2019, 4:28 PM Christopher Wood wrote: > This is the working group last call for the "Deprecating TLSv1.0 and > TLSv1.1=E2=80=9D draft available at: > > https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate= / > > Please review the document and send your comments to the list by April 26= , > 2019. > Do it! It's time to end the Vaudenay attack before it's old enough to vote. > > Thanks, > Chris, Joe, and Sean > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000cb187d05865fc50e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Apr 12, 2019, 4:28 PM Christopher Wood <caw@heapingbits.net> wrote:
<= /div>
This is the working group last call for= the "Deprecating TLSv1.0 and TLSv1.1=E2=80=9D draft available at:

=C2=A0 =C2=A0 https= ://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/

Please review the document and send your comments to the list by April 26, = 2019.

Do it! It's time to end the Vaudenay attack before it's old en= ough to vote.

Thanks,
Chris, Joe, and Sean

_______________________________________________
TLS mailing list
TLS@ie= tf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000cb187d05865fc50e-- From nobody Fri Apr 12 21:10: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 A056C120466 for ; Fri, 12 Apr 2019 21:10:04 -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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=Y3r5+xwE; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=O+hzE4/l Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwJfaKA_IFVY for ; Fri, 12 Apr 2019 21:10:02 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 593B4120465 for ; Fri, 12 Apr 2019 21:10:02 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 88F0452E for ; Sat, 13 Apr 2019 00:10:01 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Sat, 13 Apr 2019 00:10:01 -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 :subject:content-type; s=fm2; bh=DvJzoEdJxtLaBLaOCbCcHa5RzeKnTLt 6bSJPxLITmGU=; b=Y3r5+xwEAUP3lw+3iTXox+NsMbytu6NB2RRM+43weAfrGH1 Dn78MOJFsQnHoe/yeUWuQr/2VvIxQLP0I7D6o1aJWRpOp/2f6+36pISnBxOyoex5 j+s4TWPI8HOXlrH0ibQn1nED9Ho6pDMSPXOFdx3r2ar/XDWQzp3mBmD+arzTYTzX IEHyIPYC86T656ZFMEhkxGgvvrYGFT9xQPtW/Na6Su1m6PT6CS7gEsaGii39jutb /h4EXJVmvpePZI4HuvmJ2bB8DnUWniwBxnCsM4tcZDvlTxxqzM+c12uwC2joXR6z jiI6qAoZGsmc9Iq/ciCAXcoxXUCMSjK1mSw/JJQ== 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=fm2; bh=DvJzoE dJxtLaBLaOCbCcHa5RzeKnTLt6bSJPxLITmGU=; b=O+hzE4/lUKiq1XsoTqDaFL qlZe+gEsWgKlXSPSbhPBeGcbW1dazPimNibed+D+g0NbQsl2L2VgVxxMUWSbzQtD bD2uKWE9X95owda3UJidAsV2P5Wf7oWotE3BjdLWNCq7sLtDvJzAMGCctZlaqUsV rUR4b/U6WldnCe5UVNTE9RDyWxWtK3qeKfvplf0UZ/794ifGi8rKbMA3N3fbm2KM 2BvFyaLMhGra/9mVRjOI47ZSQ497r4UxopW5sNuckDKZRd+KVOUAHuespPSKiFXh wxpPEtkcH1rKDN2bmbJKU+CNUzS3PnJvk5WrbunRoNFyQePkpEJwKa2RkNGEfgCQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrvdeggddujecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehivghtfhdrohhrghenucfrrghrrg hmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvthenucevlhhushht vghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 83F817C132; Sat, 13 Apr 2019 00:10:00 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-332-g22ddc6a-fmstable-20190412v1 Mime-Version: 1.0 X-Me-Personality: 92534000 Message-Id: <9ae5725b-c0a7-4602-bd0a-da04509db62a@www.fastmail.com> In-Reply-To: <4f21da8a-a30c-4255-9400-aab3a599fb9b@www.fastmail.com> References: <4f21da8a-a30c-4255-9400-aab3a599fb9b@www.fastmail.com> Date: Sat, 13 Apr 2019 00:10:01 -0400 From: "Martin Thomson" To: tls@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [TLS] Adoption call for draft-sy-tls-resumption-group 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, 13 Apr 2019 04:10:05 -0000 I like the basic idea, but I don't think that this is the right solution. I realize that we can adopt and fix, but I my preference is to have a little more time to discuss solutions before we adopt anything. On Sat, Apr 13, 2019, at 09:35, Christopher Wood wrote: > At TLS@IETF104, there was interest in the room to adopt > draft-sy-tls-resumption-group as a WG item. The draft can be found here: > > https://datatracker.ietf.org/doc/draft-sy-tls-resumption-group/ > > This email starts the call for adoption. It will run until April 26, > 2019. Please indicate whether or not you would like to see this draft > adopted. > > Thanks, > Chris, Joe, and Sean > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Fri Apr 12 21:15: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 9BCB512004C for ; Fri, 12 Apr 2019 21:15:57 -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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=Gsqwc32b; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=auEr6Lnj Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEz0UCL8z_9O for ; Fri, 12 Apr 2019 21:15:55 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8774912000F for ; Fri, 12 Apr 2019 21:15:55 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id E54765C2 for ; Sat, 13 Apr 2019 00:15:54 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Sat, 13 Apr 2019 00:15:55 -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 :subject:content-type:content-transfer-encoding; s=fm2; bh=dNYTR TlrRogXBP2ImRvuvjNLTVTBSTkEZeQIZ4HCv28=; b=Gsqwc32bAG0l7whfReNGH nP9fp/6yks1LqIzNfV2gzAsS0aTLHPh00F8R84ENkozXM867/6+ISkCM2gS0O1NF N1UrvwvUb6TltNdkWXIpqmn5taJkeVyCy4Tl24AzbaEtxnrq1U/bI2P1h970m8VH 0zwj+1QEO17nOhz+S9X9Gtcc+CBpnZuulcw32qqOm5ylw4f5pcYBZb+UF0eBpJ+M 6PHgzdkrreFyS/QNse/vGKYdq0ajJFU83c+B8RTNRTIh8lE3NFa3AqIT5YDXdXEj lXE6rK8whLr/FVCxRmXTVRvpRuEEdaEYrGsx7JCE7jtGcP+FYJhO4VwoKvfYaxbW g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding: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=fm2; bh=dNYTRTlrRogXBP2ImRvuvjNLTVTBSTkEZeQIZ4HCv 28=; b=auEr6Lnjoi8BG+jnRj0WDjS3zt0h+caVY0r/MtsG95g6pjOZif8SX95OR R+DXmIGpwbaQpZs//5c8ykQTAPEa5uMC5FlLBnRNtqwxVtyr4vNkJ/LuAANtRkJ+ EqPLQ+A6AIKORYbu5rNXv+t9mJ7SQMW6RaeZ2pi9gka8Tbp06n+pY4nm16YG98LJ pa2L15rvHdJqj8Opgpf851tefgxUvyE7a2ZbJbs7zN7b//8hhJ9oVpxZ4MftiUD9 f9bxZm9weUnW8Xh/HJpVbeUXcSSG18YtRK2iYyxLftrSaTCtDX19RbmkCqToA4xr XZPi3MmGKBZneX+/FpDf2IZv44mjg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrvdeggddukecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucffohhmrghinhepihgvthhfrdhorhhgnecurfgrrh grmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvghtnecuvehluhhs thgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E6A1F7C132; Sat, 13 Apr 2019 00:15:53 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-332-g22ddc6a-fmstable-20190412v1 Mime-Version: 1.0 X-Me-Personality: 92534000 Message-Id: <4d34a22a-3d77-4fe8-9c8e-e2128a7a80f8@www.fastmail.com> In-Reply-To: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> Date: Sat, 13 Apr 2019 00:15:55 -0400 From: "Martin Thomson" To: tls@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable 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, 13 Apr 2019 04:15:58 -0000 Section 1.1 doesn't say *how* those listed documents are updated. Might= pay to include a few works on how. Section 2 can be cut down a lot. The quote from another document is lon= ger than the rest of the text. In many ways, saying that the IETF is mo= ving last is not a great thing to memorialize in RFC, as much as it is u= seful in an Internet-Draft or in argumentation in support of publication= of the doc. The title of Section 3 could be a bit clearer. It might pay to explain what RFC 7525 is in Section 6. Why does that do= cument warrant special attention over the 70-odd other ones. Otherwise, publish this. On Sat, Apr 13, 2019, at 09:28, Christopher Wood wrote: > This is the working group last call for the "Deprecating TLSv1.0 and=20= > TLSv1.1=E2=80=9D draft available at: >=20 > https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprec= ate/ >=20 > Please review the document and send your comments to the list by April= 26, 2019. >=20 > Thanks, > Chris, Joe, and Sean >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Sat Apr 13 00: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 4D3B4120074 for ; Sat, 13 Apr 2019 00:43: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_RED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 J201lnUBxHh8 for ; Sat, 13 Apr 2019 00:43:34 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00063.outbound.protection.outlook.com [40.107.0.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB4D6120043 for ; Sat, 13 Apr 2019 00:43:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gVEQy1iHUQNT49GMuBUEJ58aLHN/Xh/N9C7kTqYND6c=; b=TpUE2Vbk/3vimJ4QO0TnFt1OvQiOQ8PG6/Z6GZ04onVuGvBRMrgNf0Lm37cKUZOrDrGeX6bc50GEVWB8HV4R2kpVm2R27szFStGttdGWngAR0aM2r+nZKnPtNRlX387e7fUszE6zFWKoFUq8GGlBF8C+KQ4EiSNLld87FWdc1ks= Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.166.22) by HE1PR07MB3483.eurprd07.prod.outlook.com (10.170.247.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.11; Sat, 13 Apr 2019 07:43:30 +0000 Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::d49e:f22a:1e0b:f888]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::d49e:f22a:1e0b:f888%6]) with mapi id 15.20.1813.009; Sat, 13 Apr 2019 07:43:30 +0000 From: John Mattsson To: Christopher Wood , "TLS@ietf.org" Thread-Topic: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" Thread-Index: AQHU8YelvLafCQ/+LkqPNFR0njz53aY5th0N Date: Sat, 13 Apr 2019 07:43:30 +0000 Message-ID: <8750F2CB-85A2-486E-9BF4-B037BD85E369@ericsson.com> References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> In-Reply-To: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [82.214.46.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 188825d7-8208-4431-ddf2-08d6bfe3b938 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR07MB3483; x-ms-traffictypediagnostic: HE1PR07MB3483: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-forefront-prvs: 00064751B6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(136003)(346002)(366004)(396003)(39860400002)(189003)(199004)(6436002)(8676002)(11346002)(26005)(6512007)(14454004)(236005)(446003)(186003)(476003)(478600001)(2616005)(25786009)(54896002)(8936002)(99286004)(2501003)(6506007)(966005)(105586002)(6486002)(5660300002)(76176011)(6306002)(53546011)(229853002)(2906002)(316002)(606006)(66066001)(102836004)(71190400001)(7736002)(6116002)(53936002)(71200400001)(305945005)(3846002)(106356001)(68736007)(81166006)(83716004)(81156014)(486006)(33656002)(86362001)(4744005)(44832011)(256004)(36756003)(82746002)(110136005)(6246003)(97736004); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3483; H:HE1PR07MB4169.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: TMnrYH6LGmL4LzGxQI0dRdMtgvGubSnhWCS27vlgYaNRwvpqp/PNTfVSL/Fk3485gAKmKHgEmZUwPCbJtrZy84I3uOo/n8TD1kW+uCp2uSSF81ksbjUETU0OieoQGdA5BknUxMtHR1BSDCmZuk7JU3jQspCSJGb+D2WX/OU1hYHGxmhpWAiQDyx0KqahMZJ0ORzFFEG00xoNa4PwKjU9y5o7LU4iZU6U6iir6vKJrrJPpwxtUfdLHypM9L7PzEKzbyWZjVEGBjDebVoHSinOojuj6I6MkQ0dh/jIgaAkPB/k03OwHKQAp83cbsMMdwzpCs2/tNxjfzNBLanM3l4R/II32V2TWWxQm3D5Iioe1c/GirDCl8PIrwlpSiNUDwLZQ010RlQ66MIWBAfKNmCcDuuaLwPGfrDgObhEyagHVbQ= Content-Type: multipart/alternative; boundary="_000_8750F2CB85A2486E9BF4B037BD85E369ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 188825d7-8208-4431-ddf2-08d6bfe3b938 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Apr 2019 07:43:30.3645 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3483 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, 13 Apr 2019 07:43:37 -0000 --_000_8750F2CB85A2486E9BF4B037BD85E369ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UHVibGlzaCENCg0KDQotLS0NClNlbnQgZnJvbSBXb3Jrc3BhY2UgT05FIEJveGVyPGh0dHBzOi8v d2hhdGlzd29ya3NwYWNlb25lLmNvbS9ib3hlcj4NCg0KT24gMTMgQXByaWwgMjAxOSBhdCAwMToy OTo1OSBDRVNULCBDaHJpc3RvcGhlciBXb29kIDxjYXdAaGVhcGluZ2JpdHMubmV0PiB3cm90ZToN ClRoaXMgaXMgdGhlIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGZvciB0aGUgIkRlcHJlY2F0aW5n IFRMU3YxLjAgYW5kIFRMU3YxLjHigJ0gZHJhZnQgYXZhaWxhYmxlIGF0Og0KDQogICAgaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10bHMtb2xkdmVyc2lvbnMtZGVw cmVjYXRlLw0KDQpQbGVhc2UgcmV2aWV3IHRoZSBkb2N1bWVudCBhbmQgc2VuZCB5b3VyIGNvbW1l bnRzIHRvIHRoZSBsaXN0IGJ5IEFwcmlsIDI2LCAyMDE5Lg0KDQpUaGFua3MsDQpDaHJpcywgSm9l LCBhbmQgU2Vhbg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KVExTIG1haWxpbmcgbGlzdA0KVExTQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3Rscw0K --_000_8750F2CB85A2486E9BF4B037BD85E369ericssoncom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdiBkaXI9Imx0 ciI+UHVibGlzaCE8L2Rpdj4NCjxzcGFuIGlkPSJkcmFmdC1icmVhayI+PC9zcGFuPjxicj4NCjxi cj4NCi0tLTxicj4NClNlbnQgZnJvbSA8YSBocmVmPSJodHRwczovL3doYXRpc3dvcmtzcGFjZW9u ZS5jb20vYm94ZXIiPldvcmtzcGFjZSBPTkUgQm94ZXI8L2E+PHNwYW4gaWQ9ImRyYWZ0LWJyZWFr Ij48L3NwYW4+PGJyPg0KPGJyPg0KPGRpdj4NCjxkaXYgY2xhc3M9Im51bGwiIGRpcj0iYXV0byI+ T24gMTMgQXByaWwgMjAxOSBhdCAwMToyOTo1OSBDRVNULCBDaHJpc3RvcGhlciBXb29kICZsdDtj YXdAaGVhcGluZ2JpdHMubmV0Jmd0OyB3cm90ZTo8YnIgY2xhc3M9Im51bGwiPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBzdHlsZT0iYm9yZGVyLWxlZnQtc3R5bGU6c29saWQ7Ym9y ZGVyLXdpZHRoOjFweDttYXJnaW4tbGVmdDowcHg7cGFkZGluZy1sZWZ0OjEwcHg7IiBjbGFzcz0i bnVsbCI+DQo8ZGl2IGNsYXNzPSJudWxsIiBkaXI9ImF1dG8iPg0KPGRpdiBjbGFzcz0ibnVsbCI+ DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9Ik1pY3Jvc29mdCBFeGNoYW5nZSBTZXJ2 ZXIiIGNsYXNzPSJudWxsIj4NCjwhLS0gY29udmVydGVkIGZyb20gdGV4dCAtLT4NCjxkaXYgY2xh c3M9Im51bGwiPjxmb250IHNpemU9IjIiIGNsYXNzPSJudWxsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExcHQ7IiBjbGFzcz0ibnVsbCI+DQo8ZGl2IG5vcD0iUGxhaW5UZXh0IiBjbGFzcz0ibnVs bCI+VGhpcyBpcyB0aGUgd29ya2luZyBncm91cCBsYXN0IGNhbGwgZm9yIHRoZSAmcXVvdDtEZXBy ZWNhdGluZyBUTFN2MS4wIGFuZCBUTFN2MS4x4oCdIGRyYWZ0IGF2YWlsYWJsZSBhdDo8YnIgY2xh c3M9Im51bGwiPg0KPGJyIGNsYXNzPSJudWxsIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVm PSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXRscy1vbGR2ZXJz aW9ucy1kZXByZWNhdGUvIiB0YXJnZXQ9Il9CTEFOSyIgY2xhc3M9Im51bGwiPg0KaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10bHMtb2xkdmVyc2lvbnMtZGVwcmVj YXRlLzwvYT48YnIgY2xhc3M9Im51bGwiPg0KPGJyIGNsYXNzPSJudWxsIj4NClBsZWFzZSByZXZp ZXcgdGhlIGRvY3VtZW50IGFuZCBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIGxpc3QgYnkgQXBy aWwgMjYsIDIwMTkuPGJyIGNsYXNzPSJudWxsIj4NCjxiciBjbGFzcz0ibnVsbCI+DQpUaGFua3Ms PGJyIGNsYXNzPSJudWxsIj4NCkNocmlzLCBKb2UsIGFuZCBTZWFuPGJyIGNsYXNzPSJudWxsIj4N CjxiciBjbGFzcz0ibnVsbCI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxiciBjbGFzcz0ibnVsbCI+DQpUTFMgbWFpbGluZyBsaXN0PGJyIGNsYXNzPSJu dWxsIj4NClRMU0BpZXRmLm9yZzxiciBjbGFzcz0ibnVsbCI+DQo8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RscyIgdGFyZ2V0PSJfQkxBTksiIGNsYXNzPSJu dWxsIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RsczwvYT48YnIgY2xh c3M9Im51bGwiPg0KPC9kaXY+DQo8L3NwYW4+PC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_8750F2CB85A2486E9BF4B037BD85E369ericssoncom_-- From nobody Sun Apr 14 16:38: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 1A9651200C1 for ; Sun, 14 Apr 2019 16:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 (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 vg5e7kpcIek6 for ; Sun, 14 Apr 2019 16:38:38 -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 130DC1200A2 for ; Sun, 14 Apr 2019 16:38:38 -0700 (PDT) Received: by mail-lf1-x12c.google.com with SMTP id o19so7252514lfl.4 for ; Sun, 14 Apr 2019 16:38:37 -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=JjYn4yFb8tKCnK6d7OExAffEWqXwh5YJsfmQGX4uFm8=; b=WpSr9RkGmFrbHaR/I7rxWz+tPeX07XkR8xv6iRMml3dQUQg8R23oYUk6b8gBiBStm7 p1CurDGuKHnDQ2UdiVHsHSItGBcrqTJCnwthL2sDsED40bbHcnAI9HGFsZikYxt4h2Dg QdCNOvsGJS5YliXqgF4U7wOngHWoTuLMLdjRYdaUyxeKfhqB2JGqKHwxzGcBvcNyRS/D lFR9OkCPQ7wud40YTVlbSuhzgoSpJ3dbX3w6+3ssUmzqd2k+cRqLIt1JoG1Gw95aC7eU N277wLsPZlaIuBsVNS7hNWxTsKTYRQir4Gbq34RInmQ7C4EwEv6gWawWv+pdhHhXY9qH fkRg== 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=JjYn4yFb8tKCnK6d7OExAffEWqXwh5YJsfmQGX4uFm8=; b=JtN9chL6CHNJqAr3FzjX3r6iVW8U2SSpe3Ou4e+xPKmL3FVq08fIrhTB2KSZTR70AA klacHI79XRaOELzziXmuijqkm7A1iFH4SFgpFO9OsAk7bro4d/ufmBxhv35GvODF3sS2 0hMgGO4BfIdcr94jRpsmR5ZqU9vm2aURf5N7I6pup1bgBBJtlTURPYmr2Yce6yVgGYpu Qn179FL6B4cEvgEI8NPA92EhtuB7SxhixOuKc6RauPL4aS7kXsh3LxeUFYII5utHYSA1 hTnAcmdlWR8n6v13c0sRZXUnZbIiI32GmME+mE/m3GP+tSl7rBguWPDXyoiYWy1NRfL4 tcbA== X-Gm-Message-State: APjAAAWn1IhYk1j5VQptRig0W3z/2Fg458PSeCz8LBrhfGKxpfmrszMS shIp6j5ZwdMAsKKN4bT8OLveKXzall1edRu8z3w= X-Google-Smtp-Source: APXvYqwEGDMPx5m9pzXAofb5OS4AMHHKbTb3C/Tj0Vd2OXCiggRlFZBdfmHD51wBUMXYiWZaEKwGq0u/dIsnyhVlUTY= X-Received: by 2002:ac2:592b:: with SMTP id v11mr14621611lfi.85.1555285116195; Sun, 14 Apr 2019 16:38:36 -0700 (PDT) MIME-Version: 1.0 References: <6ADEC907-1273-41AF-A964-68E654103645@ncl.ac.uk> In-Reply-To: From: Watson Ladd Date: Sun, 14 Apr 2019 16:38:24 -0700 Message-ID: To: Feng Hao Cc: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Elliptic Curve J-PAKE 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, 14 Apr 2019 23:38:41 -0000 On Wed, Mar 27, 2019 at 11:36 PM Feng Hao wrote: > > Hi Watson, > > When the attacker knows the relation, besides the active attack, there ma= y > be other things he can exploit. This however is not usually analysed as b= y > the assumption of the proof, this should never happen. Random self-reducibility seems relevant here, as does the fact an attacker should be able to solve any discrete logarithm problems over a group one is using. > > You=C2=B9re correct that J-PAKE uses Shamir-Fiat heuristics, hence the pr= oof is > in ROM. The key design principle in J-PAKE is based on understanding the > importance of zero-knowledge proof. The use of Shamir-Fiat heuristics to > make ZKP non-interactive is a standard technique in cryptography. In the > field of secure two/multi-party computation, ZKP is almost universally > used in every protocol. However, in the field of PAKE, to my knowledge, > J-PAKE is the only protocol that uses ZKP. On the other hand, if you thin= k > about PAKE, it=C2=B9s fundamentally a two-party secure computation proble= m on > an equality function (with the side benefit that both sides produce a > common session key when the equality holds). This paragraph is not responsive to my assertion that ROM=3D> common random string. J-PAKE is an instance of a generic design approach where an honest but curious protocol is transformed into a malicious party secure on through adding proofs of correctness. Each of those proofs and verifications is expensive. Hence J-PAKE is expensive. The security of JPAKE versus SPAKE2 is the same: both are secure in the ROM. > > Cheers, > Feng > > On 27/03/2019, 20:08, "Watson Ladd" wrote: > > >On Wed, Mar 27, 2019 at 7:56 PM Feng Hao wrot= e: > >> > >> Hi Hugo, > >> > >> > >> > >> Thanks for your comments. > >> > >> > >> Just to clarify the difference between SPAKE2 and J-PAKE - The proof o= f > >>SPAKE2 depends on the assumption of a trusted setup: the discrete > >>logarithm between the two group generators must be unknown by anyone. > > > >The above is not true: we rely on the common random string model, not > >the common reference model. This matters for below. > > > >>If a powerful adversary (3 letter agency) gathers sufficient resources > >>and time (say 1 year) to break one instance of discrete logarithm, it > >>will be a class attack, breaking all >instances of SPAKE2 without anyon= e > >>knowing it. By contrast, they can only break one session in J-PAKE, > >>since by design the randomness is refreshed in every session >rather > >>than being built into a static setup. This explain why J-PAKE requires > >>more computation than SPAKE2. Hope it clarifies. > > > >I don't know of a JPAKE proof that doesn't rely on Shamir-Fiat > >heuristic, which implies common random string. Your proof is in the > >ROM no? Also I do not see how one recovers the password from past > >sessions or recovers the negotiated key in this case: certainly an > >active attack is possible knowing a relation! > > > >> > >> > >> Regards, > >> > >> Feng > >> > >> > >> > >> From: TLS on behalf of Hugo Krawczyk > >> > >> Date: Wednesday, 27 March 2019 at 02:49 > >> To: Hannes Tschofenig > >> Cc: "tls@ietf.org" > >> Subject: Re: [TLS] Elliptic Curve J-PAKE > >> > >> > >> > >> Hi Hannes, > >> > >> > >> > >> J-PAKE is a symmetric PAKE. Both parties store the same password. It i= s > >>not suitable for most client-server scenarios where using J-PAKE would > >>mean that an attacker that breaks into the server simply steals all > >>plaintext passwords. OPAQUE is an asymmetric (or augmented) PAKE where > >>user remembers a password (and nothing else, including no public key of > >>the server) while the server stores a one-way image of the password. > >>Security requires that if the server is compromised, the attacker needs > >>to run an offline dictionary attack for each user in the database to > >>find the password. > >> > >> > >> > >> If what you need is a symmetric PAKE then there are better candidates > >>than J-PAKE such as SPAKE2 described in draft-irtf-cfrg-spake2-08. > >>SPAKE2 is *much* more efficient than J-PAKE and while both J-PAKE and > >>SPAKE2 have proofs of security, SPAKE2 is proven in a stronger security > >>model relative to J-PAKE. > >> > >> > >> > >> I am not aware of any advantage of J-PAKE over SPAKE2 - but I may be > >>missing something. Maybe the PAKE presentation in cfrg will clarify > >>these issues further. > >> > >> > >> > >> Hugo > >> > >> > >> > >> > >> > >> > >> > >> On Tue, Mar 26, 2019 at 1:03 PM Hannes Tschofenig > >> wrote: > >> > >> Hi all, > >> > >> in context of the OPAQUE talk by Nick today at the TLS WG meeting I > >>mentioned that the Thread Group has used the Elliptic Curve J-PAKE for > >>IoT device onboarding. > >> Here is the draft written for TLS 1.2: > >> https://tools.ietf.org/html/draft-cragie-tls-ecjpake-01 > >> > >> The mechanism is described in https://tools.ietf.org/html/rfc8236 > >> > >> @Nick & Richard: Have a look at it and see whether it fits your needs. > >> > >> Ciao > >> Hannes > >> > >> IMPORTANT NOTICE: The contents of this email and any attachments are > >>confidential and may also be privileged. If you are not the intended > >>recipient, please notify the sender immediately and do not disclose the > >>contents to any other person, use it for any purpose, or store or copy > >>the information in any medium. Thank you. > >> > >> _______________________________________________ > >> 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 > > > > > > > >-- > >"Man is born free, but everywhere he is in chains". > >--Rousseau. > -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Mon Apr 15 02:09: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 6BBD912015D for ; Mon, 15 Apr 2019 02:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Qyqd73PKd7B7 for ; Mon, 15 Apr 2019 02:09:34 -0700 (PDT) Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3B3F12008A for ; Mon, 15 Apr 2019 02:09:33 -0700 (PDT) Received: by mail-vs1-xe2a.google.com with SMTP id g187so9013717vsc.8 for ; Mon, 15 Apr 2019 02:09:33 -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=kOge/3aPywOin3hJYwQnqisnq+rV9ePrz4GoBvppBkc=; b=uupXgBs/NG/eCoqX+CAqPD0gxNKho8RHtQsT6rXy1jjHIJw6CE6zEOhMk11bp4QBnG rq8BNs/7lYaKcQSDwZIw2zs0aDDcZ7MHllzmzmCWJb2msZuWbx8e2oWYwYT1ZuAlAp3x C8P0W3BQ1OXD6hAv/4qzrLruBT6OCLJ8OXrq+4K0qHZKOqHKLWDVaFs/DIoBH8G8wbAo ETH6fA+Uw2T2m6H9vdh1ZTLRg6wmxsQ6JhNRe+hlYl1rR+njLxQDiNPbVZsezrJPeehF GRLGthAtmVre6zY2egd4Wh3cQtVzm1/zbP8a6Y2hN1si4GTzmxR/SKspzYa52rrrkm5B A1ag== 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=kOge/3aPywOin3hJYwQnqisnq+rV9ePrz4GoBvppBkc=; b=GhbG04snJ+T9m1BSpC6VcVSaxPTamGtlF1EwBzitB74O+MQCifVj4v8aUjfXox6/Mo p/0nw+1OJDnNkKVZjNS/appk8iV9tcJmoZ7FmMpK58aGtxBbA7ksEB8xi3IFQKMPsz1P a1hPaFiaYOrUmtVyyXPfsDtyGi9yq+zPnL946L70Fs7P6VFFcjwRI04UpWmtv8kdhEsm ue0mUUOWczRQ9Cx/JugGEZgXhuskFeHZ0jGYqcjTdzaNh2YU41xC7wVfeijT2wi1ShFf 33UZvBfG9PJZKqfLoiL2VugE8jwH5ic3a9FRk22r781YtTNpEzqP19Ld85SQy+3BGhsd SohQ== X-Gm-Message-State: APjAAAX7WwV5P91CtFygqfj1mN+AorRG5kRJaEHi2z3icqCgW4XvBzR8 tzYH/Fz2FbqTQ83KuIJyvLmLVDF+rqMl4/RpjV32HFTK X-Google-Smtp-Source: APXvYqxuInW1GRep5P6ZMuZeyCgrp+HR8mbYg/u/R3W8y8+llXELKqf3MnZF+ltkLJpqeRF/XXFdqiax6U0yGs+GKKQ= X-Received: by 2002:a67:e3cf:: with SMTP id k15mr38251850vsm.185.1555319372683; Mon, 15 Apr 2019 02:09:32 -0700 (PDT) MIME-Version: 1.0 References: <745ED9FE-9C31-4687-BD64-836155A28AEC@ericsson.com> <3C099064-52D9-49C3-9180-A01FBDEE876A@ericsson.com> <523c1d42-c4bb-4206-b9be-bcec93973424@www.fastmail.com> In-Reply-To: <523c1d42-c4bb-4206-b9be-bcec93973424@www.fastmail.com> From: Jonathan Hoyland Date: Mon, 15 Apr 2019 10:09:21 +0100 Message-ID: To: Martin Thomson Cc: "" Content-Type: multipart/alternative; boundary="000000000000b8a09905868e021c" Archived-At: Subject: Re: [TLS] Comment on draft-thomson-tls-sic-00 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, 15 Apr 2019 09:09:35 -0000 --000000000000b8a09905868e021c Content-Type: text/plain; charset="UTF-8" Hi Martin, Could you comment on how the client and server know they agree on the certificate chain? Would it be possible for the client and server to resolve the certificate chain down two distinct paths, for example in the case of cross signed certificates? If so, is there a security risk here, as in, does it matter if the client and server disagree on the chains? Could an attacker perform some shenanigans with disjoint roots of trust, or by finding paths with differing policy constraints (if that even makes sense)? Would it help anything if the server included a digest of the certificate chain in its EncryptedExtensions? Regards, Jonathan On Thu, 11 Apr 2019 at 03:58, Martin Thomson wrote: > On Sat, Mar 30, 2019, at 06:05, John Mattsson wrote: > > And one more.... > > > > "The 0xTBD flag can only be send in a ClientHello or CertificateRequest > > message. Endpoints that receive a value of 1 in any other handshake > > message MUST generate a fatal illegal_parameter alert." > > > > This goes against draft-nir-tls-tlsflags > > > > "A server that supports this extension and also supports at least one > > of the flag-type features that use this extension and that were > > declared by the ClientHello extension SHALL send this extension with > > the intersection of the flags it supports with the flags declared by > > the client." > > > > I assume the sic sic extension should be sent in EncryptedExtensions. > > I think that this is a problem in draft-nir-tls-tlsflags. Extensions in > ClientHello are "answered" in two places: EncryptedExtensions and > Certificate. The requirement that the flag be echoed creates a problem in > that context. > > We could define separate "Handshake flags" and "Certificate flags", but > that complicates things. > > If you look at extension usage, you see that not all "flags" are echoed. > In this case, a requirement to echo would just increase the size of > Certificate for no good reason - the extension can be omitted completely. > > We should only require the presence of the flag where it carries > semantics. The requirement should be stated as > > Implementations MUST NOT set flags in extension responses if the remote > endpoint did not send the corresponding flag in extension requests. > Upon > receiving a flag that is incorrectly set, an endpoint MUST abort the > handshake > with an "unsupported_extension" [?] alert. > > Mirroring the language from RFC 8446. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000b8a09905868e021c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Martin,

Could you comment on ho= w the client and server know they agree on the certificate chain?
Would it be possible for the client and server to resolve the certificate = chain down two distinct paths, for example in the case of cross signed cert= ificates?

If so, is there a security risk here, as= in, does it matter if the client and server disagree on the chains?=C2=A0<= /div>
Could an attacker perform some shenanigans with disjoint roots of= trust, or by finding paths with differing policy constraints (if that even= makes sense)?

Would it help anything if the serve= r included a digest of the certificate chain in its EncryptedExtensions?

Regards,

Jonathan

On T= hu, 11 Apr 2019 at 03:58, Martin Thomson <mt@lowentropy.net> wrote:
On Sat, Mar 30, 2019, at 06:05, John Mattsson wrote= :
> And one more....
>
> "The 0xTBD flag can only be send in a ClientHello or CertificateR= equest
> message.=C2=A0 Endpoints that receive a value of 1 in any other handsh= ake
> message MUST generate a fatal illegal_parameter alert."
>
> This goes against draft-nir-tls-tlsflags
>
> "A server that supports this extension and also supports at least= one
> of the flag-type features that use this extension and that were
> declared by the ClientHello extension SHALL send this extension with <= br> > the intersection of the flags it supports with the flags declared by <= br> > the client."
>
> I assume the sic sic extension should be sent in EncryptedExtensions.<= br>
I think that this is a problem in draft-nir-tls-tlsflags.=C2=A0 Extensions = in ClientHello are "answered" in two places: EncryptedExtensions = and Certificate.=C2=A0 The requirement that the flag be echoed creates a pr= oblem in that context.

We could define separate "Handshake flags" and "Certificate = flags", but that complicates things.

If you look at extension usage, you see that not all "flags" are = echoed.=C2=A0 In this case, a requirement to echo would just increase the s= ize of Certificate for no good reason - the extension can be omitted comple= tely.

We should only require the presence of the flag where it carries semantics.= =C2=A0 The requirement should be stated as

=C2=A0 =C2=A0Implementations MUST NOT set flags in extension responses if t= he remote
=C2=A0 =C2=A0endpoint did not send the corresponding flag in extension requ= ests.=C2=A0 Upon
=C2=A0 =C2=A0receiving a flag that is incorrectly set, an endpoint MUST abo= rt the handshake
=C2=A0 =C2=A0with an "unsupported_extension" [?] alert.

Mirroring the language from RFC 8446.

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000b8a09905868e021c-- From nobody Mon Apr 15 05:50: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 B53D0120157 for ; Mon, 15 Apr 2019 05:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 5KSePLdVnTbI for ; Mon, 15 Apr 2019 05:50:40 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60048.outbound.protection.outlook.com [40.107.6.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF646120143 for ; Mon, 15 Apr 2019 05:50:39 -0700 (PDT) Received: from DB7PR01MB5435.eurprd01.prod.exchangelabs.com (20.178.106.208) by DB7PR01MB5045.eurprd01.prod.exchangelabs.com (20.177.194.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.14; Mon, 15 Apr 2019 12:50:36 +0000 Received: from DB7PR01MB5435.eurprd01.prod.exchangelabs.com ([fe80::8084:42e1:c111:4950]) by DB7PR01MB5435.eurprd01.prod.exchangelabs.com ([fe80::8084:42e1:c111:4950%4]) with mapi id 15.20.1792.018; Mon, 15 Apr 2019 12:50:36 +0000 From: "Hao, Feng" To: Watson Ladd CC: "tls@ietf.org" Thread-Topic: [TLS] Elliptic Curve J-PAKE Thread-Index: AQHU8xtJDaWZUd9YGUGG8fMPvKb5EaY9PjAA Date: Mon, 15 Apr 2019 12:50:36 +0000 Message-ID: References: <6ADEC907-1273-41AF-A964-68E654103645@ncl.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.8.190312 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Feng.Hao@warwick.ac.uk; x-originating-ip: [137.205.238.55] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b97e6980-7ced-46c5-b1b2-08d6c1a0f4e5 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600140)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:DB7PR01MB5045; x-ms-traffictypediagnostic: DB7PR01MB5045: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-forefront-prvs: 000800954F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(136003)(366004)(39860400002)(376002)(346002)(189003)(199004)(53754006)(5024004)(446003)(11346002)(6306002)(53936002)(6512007)(25786009)(81156014)(6436002)(6916009)(486006)(93886005)(1411001)(186003)(6116002)(476003)(3846002)(105586002)(106356001)(26005)(81166006)(256004)(97736004)(8676002)(14444005)(76176011)(6246003)(8936002)(6486002)(99286004)(229853002)(102836004)(4326008)(5660300002)(786003)(68736007)(305945005)(86362001)(478600001)(58126008)(33656002)(71200400001)(966005)(72206003)(82746002)(7736002)(74482002)(14454004)(2906002)(66066001)(53546011)(6506007)(316002)(71190400001)(83716004); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR01MB5045; H:DB7PR01MB5435.eurprd01.prod.exchangelabs.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: warwick.ac.uk does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: JVI1Iz+/6tei7mzSrBsNOfY5WhVrU/w6G9ibhRekMFNAV8AQFGHM4S4n6kMuHXgfkI/Zq6a3EZ61Q3ysMEBoKTbftXC8PAYnnV4a+NZy6iFr7XDQP84yNDhBGD2r64wOd8F42yS7CLWiLizPd7MHhmMrN/FrxbaaWKFX8i9DvayvD+ZFRZekvembS8UOYeW2sgmFTyOqoKRUdrcsYXB9LbSSX1RiZ0xyNZdn7cpsbd4nb7VqzOUd3hp73XLHYgag1bb+U0jwUHmHxx8BD8eG/hKObTaiWWWJwXe6SoWhxSXdPAlUOLKdsQU6h5hi//TFYVvAenFSsoT1LmRcu8xpaLquc9Ux7Ko+vMTgjxkxefiw7wi3IY/ysPEjidZ0izxTkfntdVBUGP/BOBz2cNXDzdvOnQb71xz/NOg5lE+CMws= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: warwick.ac.uk X-MS-Exchange-CrossTenant-Network-Message-Id: b97e6980-7ced-46c5-b1b2-08d6c1a0f4e5 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2019 12:50:36.6745 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 09bacfbd-47ef-4465-9265-3546f2eaf6bc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR01MB5045 Archived-At: Subject: Re: [TLS] Elliptic Curve J-PAKE 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, 15 Apr 2019 12:50:45 -0000 SGkgV2F0c29uLA0KDQrvu79PbiAxNS8wNC8yMDE5LCAwMDozOSwgIlRMUyBvbiBiZWhhbGYgb2Yg V2F0c29uIExhZGQiIDx0bHMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Ygd2F0c29uYmxh ZGRAZ21haWwuY29tPiB3cm90ZToNCg0KICAgIE9uIFdlZCwgTWFyIDI3LCAyMDE5IGF0IDExOjM2 IFBNIEZlbmcgSGFvIDxmZW5nLmhhb0BuZXdjYXN0bGUuYWMudWs+IHdyb3RlOg0KICAgID4NCiAg ICA+IEhpIFdhdHNvbiwNCiAgICA+DQogICAgPiBXaGVuIHRoZSBhdHRhY2tlciBrbm93cyB0aGUg cmVsYXRpb24sIGJlc2lkZXMgdGhlIGFjdGl2ZSBhdHRhY2ssIHRoZXJlIG1heQ0KICAgID4gYmUg b3RoZXIgdGhpbmdzIGhlIGNhbiBleHBsb2l0LiBUaGlzIGhvd2V2ZXIgaXMgbm90IHVzdWFsbHkg YW5hbHlzZWQgYXMgYnkNCiAgICA+IHRoZSBhc3N1bXB0aW9uIG9mIHRoZSBwcm9vZiwgdGhpcyBz aG91bGQgbmV2ZXIgaGFwcGVuLg0KICAgIA0KICAgIFJhbmRvbSBzZWxmLXJlZHVjaWJpbGl0eSBz ZWVtcyByZWxldmFudCBoZXJlLCBhcyBkb2VzIHRoZSBmYWN0IGFuDQogICAgYXR0YWNrZXIgc2hv dWxkIGJlIGFibGUgdG8gc29sdmUgYW55IGRpc2NyZXRlIGxvZ2FyaXRobSBwcm9ibGVtcyBvdmVy DQogICAgYSBncm91cCBvbmUgaXMgdXNpbmcuDQogICAgDQpPSywgamFyZ29ucyBhcGFydCAtIG15 IHBvaW50IHdhcyBhYm91dCB0aGUgYXNzdW1wdGlvbi4gSWYgdGhlIHJlbGF0aW9uIG9mIHRoZSB0 d28gc3lzdGVtIGdlbmVyYXRvcnMgaXMga25vd24sIHRoZSBhc3N1bXB0aW9uIG9mIHRoZSBwcm9v ZiBpcyB2aW9sYXRlZCwgYW5kIHRoZSBwcm9vZiBiZWNvbWVzIGludmFsaWQuDQoNCiAgICA+IFlv dcK5cmUgY29ycmVjdCB0aGF0IEotUEFLRSB1c2VzIFNoYW1pci1GaWF0IGhldXJpc3RpY3MsIGhl bmNlIHRoZSBwcm9vZiBpcw0KICAgID4gaW4gUk9NLiBUaGUga2V5IGRlc2lnbiBwcmluY2lwbGUg aW4gSi1QQUtFIGlzIGJhc2VkIG9uIHVuZGVyc3RhbmRpbmcgdGhlDQogICAgPiBpbXBvcnRhbmNl IG9mIHplcm8ta25vd2xlZGdlIHByb29mLiBUaGUgdXNlIG9mIFNoYW1pci1GaWF0IGhldXJpc3Rp Y3MgdG8NCiAgICA+IG1ha2UgWktQIG5vbi1pbnRlcmFjdGl2ZSBpcyBhIHN0YW5kYXJkIHRlY2hu aXF1ZSBpbiBjcnlwdG9ncmFwaHkuIEluIHRoZQ0KICAgID4gZmllbGQgb2Ygc2VjdXJlIHR3by9t dWx0aS1wYXJ0eSBjb21wdXRhdGlvbiwgWktQIGlzIGFsbW9zdCB1bml2ZXJzYWxseQ0KICAgID4g dXNlZCBpbiBldmVyeSBwcm90b2NvbC4gSG93ZXZlciwgaW4gdGhlIGZpZWxkIG9mIFBBS0UsIHRv IG15IGtub3dsZWRnZSwNCiAgICA+IEotUEFLRSBpcyB0aGUgb25seSBwcm90b2NvbCB0aGF0IHVz ZXMgWktQLiBPbiB0aGUgb3RoZXIgaGFuZCwgaWYgeW91IHRoaW5rDQogICAgPiBhYm91dCBQQUtF LCBpdMK5cyBmdW5kYW1lbnRhbGx5IGEgdHdvLXBhcnR5IHNlY3VyZSBjb21wdXRhdGlvbiBwcm9i bGVtIG9uDQogICAgPiBhbiBlcXVhbGl0eSBmdW5jdGlvbiAod2l0aCB0aGUgc2lkZSBiZW5lZml0 IHRoYXQgYm90aCBzaWRlcyBwcm9kdWNlIGENCiAgICA+IGNvbW1vbiBzZXNzaW9uIGtleSB3aGVu IHRoZSBlcXVhbGl0eSBob2xkcykuDQogICAgDQogICAgVGhpcyBwYXJhZ3JhcGggaXMgbm90IHJl c3BvbnNpdmUgdG8gbXkgYXNzZXJ0aW9uIHRoYXQgUk9NPT4gY29tbW9uDQogICAgcmFuZG9tIHN0 cmluZy4NCiAgICANCiAgICBKLVBBS0UgaXMgYW4gaW5zdGFuY2Ugb2YgYSBnZW5lcmljIGRlc2ln biBhcHByb2FjaCB3aGVyZSBhbiBob25lc3QgYnV0DQogICAgY3VyaW91cyBwcm90b2NvbCBpcyB0 cmFuc2Zvcm1lZCBpbnRvIGEgbWFsaWNpb3VzIHBhcnR5IHNlY3VyZSBvbg0KICAgIHRocm91Z2gg YWRkaW5nIHByb29mcyBvZiBjb3JyZWN0bmVzcy4gRWFjaCBvZiB0aG9zZSBwcm9vZnMgYW5kDQog ICAgdmVyaWZpY2F0aW9ucyBpcyBleHBlbnNpdmUuIEhlbmNlIEotUEFLRSBpcyBleHBlbnNpdmUu IFRoZSBzZWN1cml0eSBvZg0KICAgIEpQQUtFIHZlcnN1cyBTUEFLRTIgaXMgdGhlIHNhbWU6IGJv dGggYXJlIHNlY3VyZSBpbiB0aGUgUk9NLg0KDQpBcyBleHBsYWluZWQgZWFybGllciwgdGhlIGRp ZmZlcmVuY2UgaXMgdGhlICJhc3N1bXB0aW9uIiBpbiB0aGUgcHJvb2YuIEZyb20gdGhlIGVuZ2lu ZWVyaW5nIHBlcnNwZWN0aXZlLCB3ZSBvdWdodCB0byBwcmVwYXJlIGZvciB0aGUgd29yc3QuIFdo ZW4gb25lIHNwZWNpZmljIGluc3RhbmNlIG9mIHRoZSBkaXNjcmV0ZSBsb2dhcml0aG0gaXMgcmVz b2x2ZWQsIHRoZXJlIGlzIGEgYmlnIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgY2xhc3MgYXR0YWNr IGFuZCB0aGUgc2Vzc2lvbiBhdHRhY2suIFRoaXMgaXMgaW4gbm8gd2F5IHRvIHNheSB0aGUgU1BB S0UyIGRyYWZ0IHRoYXQgeW91J3JlIHdvcmtpbmcgb24gaXMgbm90IHVzZWZ1bCAob24gdGhlIGNv bnRyYXJ5LCBJIHRoaW5rIGl0IGNhbiBiZSB1c2VmdWwgaW4gc29tZSBzcGVjaWZpYyBhcHBsaWNh dGlvbnMgd2hlcmUgdGhlIGVmZmVjdCBvZiBhIGNsYXNzIGF0dGFjayBpcyB0b2xlcmFibGUpLCBi dXQgSSBqdXN0IHdhbnQgdG8gcG9pbnQgb3V0IHRoZSBmYWN0dWFsIGRpZmZlcmVuY2VzIGJldHdl ZW4gdGhlIHR3by4NCg0KICAgID4NCiAgICA+IENoZWVycywNCiAgICA+IEZlbmcNCiAgICA+DQog ICAgPiBPbiAyNy8wMy8yMDE5LCAyMDowOCwgIldhdHNvbiBMYWRkIiA8d2F0c29uYmxhZGRAZ21h aWwuY29tPiB3cm90ZToNCiAgICA+DQogICAgPiA+T24gV2VkLCBNYXIgMjcsIDIwMTkgYXQgNzo1 NiBQTSBGZW5nIEhhbyA8ZmVuZy5oYW9AbmV3Y2FzdGxlLmFjLnVrPiB3cm90ZToNCiAgICA+ID4+ DQogICAgPiA+PiBIaSBIdWdvLA0KICAgID4gPj4NCiAgICA+ID4+DQogICAgPiA+Pg0KICAgID4g Pj4gVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLg0KICAgID4gPj4NCiAgICA+ID4+DQogICAgPiA+ PiBKdXN0IHRvIGNsYXJpZnkgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBTUEFLRTIgYW5kIEotUEFL RSAtIFRoZSBwcm9vZiBvZg0KICAgID4gPj5TUEFLRTIgZGVwZW5kcyBvbiB0aGUgYXNzdW1wdGlv biBvZiBhIHRydXN0ZWQgc2V0dXA6IHRoZSBkaXNjcmV0ZQ0KICAgID4gPj5sb2dhcml0aG0gYmV0 d2VlbiB0aGUgdHdvIGdyb3VwIGdlbmVyYXRvcnMgbXVzdCBiZSB1bmtub3duIGJ5IGFueW9uZS4N CiAgICA+ID4NCiAgICA+ID5UaGUgYWJvdmUgaXMgbm90IHRydWU6IHdlIHJlbHkgb24gdGhlIGNv bW1vbiByYW5kb20gc3RyaW5nIG1vZGVsLCBub3QNCiAgICA+ID50aGUgY29tbW9uIHJlZmVyZW5j ZSBtb2RlbC4gVGhpcyBtYXR0ZXJzIGZvciBiZWxvdy4NCiAgICA+ID4NCiAgICA+ID4+SWYgYSBw b3dlcmZ1bCBhZHZlcnNhcnkgKDMgbGV0dGVyIGFnZW5jeSkgZ2F0aGVycyBzdWZmaWNpZW50IHJl c291cmNlcw0KICAgID4gPj5hbmQgdGltZSAoc2F5IDEgeWVhcikgdG8gYnJlYWsgb25lIGluc3Rh bmNlIG9mIGRpc2NyZXRlIGxvZ2FyaXRobSwgaXQNCiAgICA+ID4+d2lsbCBiZSBhIGNsYXNzIGF0 dGFjaywgYnJlYWtpbmcgYWxsID5pbnN0YW5jZXMgb2YgU1BBS0UyIHdpdGhvdXQgYW55b25lDQog ICAgPiA+Pmtub3dpbmcgaXQuIEJ5IGNvbnRyYXN0LCB0aGV5IGNhbiBvbmx5IGJyZWFrIG9uZSBz ZXNzaW9uIGluIEotUEFLRSwNCiAgICA+ID4+c2luY2UgYnkgZGVzaWduIHRoZSByYW5kb21uZXNz IGlzIHJlZnJlc2hlZCBpbiBldmVyeSBzZXNzaW9uID5yYXRoZXINCiAgICA+ID4+dGhhbiBiZWlu ZyBidWlsdCBpbnRvIGEgc3RhdGljIHNldHVwLiBUaGlzIGV4cGxhaW4gd2h5IEotUEFLRSByZXF1 aXJlcw0KICAgID4gPj5tb3JlIGNvbXB1dGF0aW9uIHRoYW4gU1BBS0UyLiBIb3BlIGl0IGNsYXJp Zmllcy4NCiAgICA+ID4NCiAgICA+ID5JIGRvbid0IGtub3cgb2YgYSBKUEFLRSBwcm9vZiB0aGF0 IGRvZXNuJ3QgcmVseSBvbiBTaGFtaXItRmlhdA0KICAgID4gPmhldXJpc3RpYywgd2hpY2ggaW1w bGllcyBjb21tb24gcmFuZG9tIHN0cmluZy4gWW91ciBwcm9vZiBpcyBpbiB0aGUNCiAgICA+ID5S T00gbm8/IEFsc28gSSBkbyBub3Qgc2VlIGhvdyBvbmUgcmVjb3ZlcnMgdGhlIHBhc3N3b3JkIGZy b20gcGFzdA0KICAgID4gPnNlc3Npb25zIG9yIHJlY292ZXJzIHRoZSBuZWdvdGlhdGVkIGtleSBp biB0aGlzIGNhc2U6IGNlcnRhaW5seSBhbg0KICAgID4gPmFjdGl2ZSBhdHRhY2sgaXMgcG9zc2li bGUga25vd2luZyBhIHJlbGF0aW9uIQ0KICAgID4gPg0KICAgID4gPj4NCiAgICA+ID4+DQogICAg PiA+PiBSZWdhcmRzLA0KICAgID4gPj4NCiAgICA+ID4+IEZlbmcNCiAgICA+ID4+DQogICAgPiA+ Pg0KICAgID4gPj4NCiAgICA+ID4+IEZyb206IFRMUyA8dGxzLWJvdW5jZXNAaWV0Zi5vcmc+IG9u IGJlaGFsZiBvZiBIdWdvIEtyYXdjenlrDQogICAgPiA+PjxodWdvQGVlLnRlY2huaW9uLmFjLmls Pg0KICAgID4gPj4gRGF0ZTogV2VkbmVzZGF5LCAyNyBNYXJjaCAyMDE5IGF0IDAyOjQ5DQogICAg PiA+PiBUbzogSGFubmVzIFRzY2hvZmVuaWcgPEhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20+DQog ICAgPiA+PiBDYzogInRsc0BpZXRmLm9yZyIgPHRsc0BpZXRmLm9yZz4NCiAgICA+ID4+IFN1Ympl Y3Q6IFJlOiBbVExTXSBFbGxpcHRpYyBDdXJ2ZSBKLVBBS0UNCiAgICA+ID4+DQogICAgPiA+Pg0K ICAgID4gPj4NCiAgICA+ID4+IEhpIEhhbm5lcywNCiAgICA+ID4+DQogICAgPiA+Pg0KICAgID4g Pj4NCiAgICA+ID4+IEotUEFLRSBpcyBhIHN5bW1ldHJpYyBQQUtFLiBCb3RoIHBhcnRpZXMgc3Rv cmUgdGhlIHNhbWUgcGFzc3dvcmQuIEl0IGlzDQogICAgPiA+Pm5vdCBzdWl0YWJsZSBmb3IgbW9z dCBjbGllbnQtc2VydmVyIHNjZW5hcmlvcyB3aGVyZSB1c2luZyBKLVBBS0Ugd291bGQNCiAgICA+ ID4+bWVhbiB0aGF0IGFuIGF0dGFja2VyIHRoYXQgYnJlYWtzIGludG8gdGhlIHNlcnZlciBzaW1w bHkgc3RlYWxzIGFsbA0KICAgID4gPj5wbGFpbnRleHQgcGFzc3dvcmRzLiBPUEFRVUUgaXMgYW4g YXN5bW1ldHJpYyAob3IgYXVnbWVudGVkKSBQQUtFIHdoZXJlDQogICAgPiA+PnVzZXIgcmVtZW1i ZXJzIGEgcGFzc3dvcmQgKGFuZCBub3RoaW5nIGVsc2UsIGluY2x1ZGluZyBubyBwdWJsaWMga2V5 IG9mDQogICAgPiA+PnRoZSBzZXJ2ZXIpIHdoaWxlIHRoZSBzZXJ2ZXIgc3RvcmVzIGEgb25lLXdh eSBpbWFnZSBvZiB0aGUgcGFzc3dvcmQuDQogICAgPiA+PlNlY3VyaXR5IHJlcXVpcmVzIHRoYXQg aWYgdGhlIHNlcnZlciBpcyBjb21wcm9taXNlZCwgdGhlIGF0dGFja2VyIG5lZWRzDQogICAgPiA+ PnRvIHJ1biBhbiBvZmZsaW5lIGRpY3Rpb25hcnkgYXR0YWNrIGZvciBlYWNoIHVzZXIgaW4gdGhl IGRhdGFiYXNlIHRvDQogICAgPiA+PmZpbmQgdGhlIHBhc3N3b3JkLg0KICAgID4gPj4NCiAgICA+ ID4+DQogICAgPiA+Pg0KICAgID4gPj4gSWYgd2hhdCB5b3UgbmVlZCBpcyBhIHN5bW1ldHJpYyBQ QUtFIHRoZW4gdGhlcmUgYXJlIGJldHRlciBjYW5kaWRhdGVzDQogICAgPiA+PnRoYW4gSi1QQUtF IHN1Y2ggYXMgU1BBS0UyIGRlc2NyaWJlZCBpbiBkcmFmdC1pcnRmLWNmcmctc3Bha2UyLTA4Lg0K ICAgID4gPj5TUEFLRTIgaXMgKm11Y2gqIG1vcmUgZWZmaWNpZW50IHRoYW4gSi1QQUtFIGFuZCB3 aGlsZSBib3RoIEotUEFLRSBhbmQNCiAgICA+ID4+U1BBS0UyIGhhdmUgcHJvb2ZzIG9mIHNlY3Vy aXR5LCBTUEFLRTIgaXMgcHJvdmVuIGluIGEgc3Ryb25nZXIgc2VjdXJpdHkNCiAgICA+ID4+bW9k ZWwgcmVsYXRpdmUgdG8gSi1QQUtFLg0KICAgID4gPj4NCiAgICA+ID4+DQogICAgPiA+Pg0KICAg ID4gPj4gSSBhbSBub3QgYXdhcmUgb2YgYW55IGFkdmFudGFnZSBvZiBKLVBBS0Ugb3ZlciBTUEFL RTIgLSBidXQgSSBtYXkgYmUNCiAgICA+ID4+bWlzc2luZyBzb21ldGhpbmcuIE1heWJlIHRoZSBQ QUtFIHByZXNlbnRhdGlvbiBpbiBjZnJnIHdpbGwgY2xhcmlmeQ0KICAgID4gPj50aGVzZSBpc3N1 ZXMgZnVydGhlci4NCiAgICA+ID4+DQogICAgPiA+Pg0KICAgID4gPj4NCiAgICA+ID4+IEh1Z28N CiAgICA+ID4+DQogICAgPiA+Pg0KICAgID4gPj4NCiAgICA+ID4+DQogICAgPiA+Pg0KICAgID4g Pj4NCiAgICA+ID4+DQogICAgPiA+PiBPbiBUdWUsIE1hciAyNiwgMjAxOSBhdCAxOjAzIFBNIEhh bm5lcyBUc2Nob2ZlbmlnDQogICAgPiA+PjxIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPiB3cm90 ZToNCiAgICA+ID4+DQogICAgPiA+PiBIaSBhbGwsDQogICAgPiA+Pg0KICAgID4gPj4gaW4gY29u dGV4dCBvZiB0aGUgT1BBUVVFIHRhbGsgYnkgTmljayB0b2RheSBhdCB0aGUgVExTIFdHIG1lZXRp bmcgSQ0KICAgID4gPj5tZW50aW9uZWQgdGhhdCB0aGUgVGhyZWFkIEdyb3VwIGhhcyB1c2VkIHRo ZSBFbGxpcHRpYyBDdXJ2ZSBKLVBBS0UgZm9yDQogICAgPiA+PklvVCBkZXZpY2Ugb25ib2FyZGlu Zy4NCiAgICA+ID4+IEhlcmUgaXMgdGhlIGRyYWZ0IHdyaXR0ZW4gZm9yIFRMUyAxLjI6DQogICAg PiA+PiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY3JhZ2llLXRscy1lY2pwYWtl LTAxDQogICAgPiA+Pg0KICAgID4gPj4gVGhlIG1lY2hhbmlzbSBpcyBkZXNjcmliZWQgaW4gaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzgyMzYNCiAgICA+ID4+DQogICAgPiA+PiBATmlj ayAmIFJpY2hhcmQ6IEhhdmUgYSBsb29rIGF0IGl0IGFuZCBzZWUgd2hldGhlciBpdCBmaXRzIHlv dXIgbmVlZHMuDQogICAgPiA+Pg0KICAgID4gPj4gQ2lhbw0KICAgID4gPj4gSGFubmVzDQogICAg PiA+Pg0KICAgID4gPj4gSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1h aWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUNCiAgICA+ID4+Y29uZmlkZW50aWFsIGFuZCBtYXkg YWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQNCiAgICA+ID4+ cmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5v dCBkaXNjbG9zZSB0aGUNCiAgICA+ID4+Y29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNl IGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weQ0KICAgID4gPj50aGUgaW5mb3Jt YXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KICAgID4gPj4NCiAgICA+ID4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPiA+PiBUTFMg bWFpbGluZyBsaXN0DQogICAgPiA+PiBUTFNAaWV0Zi5vcmcNCiAgICA+ID4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQogICAgPiA+Pg0KICAgID4gPj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+ID4+IFRMUyBt YWlsaW5nIGxpc3QNCiAgICA+ID4+IFRMU0BpZXRmLm9yZw0KICAgID4gPj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMNCiAgICA+ID4NCiAgICA+ID4NCiAgICA+ID4N CiAgICA+ID4tLQ0KICAgID4gPiJNYW4gaXMgYm9ybiBmcmVlLCBidXQgZXZlcnl3aGVyZSBoZSBp cyBpbiBjaGFpbnMiLg0KICAgID4gPi0tUm91c3NlYXUuDQogICAgPg0KICAgIA0KICAgIA0KICAg IC0tDQogICAgIk1hbiBpcyBib3JuIGZyZWUsIGJ1dCBldmVyeXdoZXJlIGhlIGlzIGluIGNoYWlu cyIuDQogICAgLS1Sb3Vzc2VhdS4NCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KICAgIFRMUyBtYWlsaW5nIGxpc3QNCiAgICBUTFNAaWV0 Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rscw0KICAg IA0KDQo= From nobody Mon Apr 15 06:55:31 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 9FDB51202CE for ; Mon, 15 Apr 2019 06:55:30 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-BmBKnBcNQ9 for ; Mon, 15 Apr 2019 06:55:28 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09F2F120234 for ; Mon, 15 Apr 2019 06:55:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1555336523; bh=MNZQ/j5LiTA1T/70RMA33COWK+lvOTqPJr3D5OtKDCw=; h=X-UI-Sender-Class:Subject:To:References:Cc:From:Date:In-Reply-To; b=VOWeh56HeHryrW/JGjYfnrs/lSU2W0FtQfmVKDjT9Hmqfxx/4OQWuWCbBR42GN1Wi VknpPe8KtoQiM6Fa7JRwXNowWcEVgIqBQrAbjtetpWUzZFQ4aAeVJhhAu6Jy2uRDor b4AAdVCd62TACLJYBXTjZXZcyqjvZW0tN7p6nFhU= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.107] ([178.7.132.0]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M2Glc-1gxGF52oCa-00s7QU; Mon, 15 Apr 2019 15:55:23 +0200 To: joe@salowey.net References: Cc: tls@ietf.org From: Achim Kraus Message-ID: Date: Mon, 15 Apr 2019 15:55:22 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-AT-frami Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:nPn/N01V6rXW5pzmvuvAnYN8o4NdV3sxDgfqWdSIPgTMKFruV0w F+mThw7KJg1xQJfY2wc7eaED7Gwl3m4f71zIgA2Su8qI3outjFb6SojNPnOs8AQE3c9Srk3 5cw9Fu1JiKc5JIgLIRavh6qxmdYJJt3RbD+3nZ1f1IUblgHURp6cxvd5TZARVavvbSDDs8T xe7Lxx+zCMzyca7jFoefQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:IoCRDSCgGAU=:6Mv6G5CZFiGl6I/CjL1pEy VBKcN3+6KPwtJz6O6nhP+nrygQzZ9rbZ5q0m8yEOyizgDSiiyUslIkKTKm0ZGyXgKjTi6Ycqt Q7G5Hn4+VVsz32ScnMenUtqBmgyJRTNNyJP/SuLE9SYQ1HvXIghfLQi5ArtskbxTCylNYNRBM g662I7Fx33cSFY2j8lEEq26gH07a0cTdfp1U6uevQBdxdvcHWFs/MDkubhRnfXrPVr0VIAjRj EV/a+WMH5w8k0RX881fCz7qyX1BbgNkVDSdip0djsqN87KTmpz4DtqIp5CfurwaZQjK5T51ih QsePzp2TUj1p49emEy1obYjW0YwJ5QnWP9dMG2wb72D8vFF14sVBW5u4vuhDBmoeb7AuKSdxm FKCI/in2l7ChK+pYdt62xUZ7WHn81ceMTvM9Rsar0H+/cC2u/l5yMjzxIkWxrtgbDX1NbyWYV LSpfYUjM/wMDFkBxGulp+pbMhnJ03IvyRqRmbvAP5zr6S5bjoLk44o2MAwSGSiODlRM6TTF+0 5m8mKUe18lzIM/LELXmJKbQJaXGzCQPkt6g5SCB55tGDCQSOPRDv6R6uQn6RezgkckNID6C/v Ze4dxACz2Gg4tdkO8pMHJuTIpUglPeh3WAisHYa/pSiGOFLzMTJH2f/Y5AISFd5BwF3qYebUY jZRLQonsPMQ9gJrsKwopoo09c/zHHXElKO+vaYo4HVpSiVqHia5X4NOrXYwyk+9k+Z3bG7XUA XfoTlphUq8Mc2Ob4ny1bnqjnQA5GApVR+ynQOqV1W6TRhz95OoDwVUVP2FHSqPYsRk3hyS/4K xgUw3VimdtjQky5tY6v6gbEKwLHqe4Koy5EpcVaK/rc0iVNWQMzkSRroc1rLjDMJu/IVIkRbY 0b00/GL4792lw1kzFuAF8y7ipMypFaBFQDCTGa81UA2dmfC7gzImo1oFcupAmD2VyM7yWV+SS hksclJkOy7w== Archived-At: Subject: Re: [TLS] early code-point assignment request for draft-ietf-tls-dtls-connection-id-04 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, 15 Apr 2019 13:55:30 -0000 Hello Joe, did the working group receive any concerns about the early code-point assignment? I hope not. Hannes did again a very great job and so I closed my open issues on the github repo. Is there any schedule for the early code-point assignment? I plan a next eclipse-californium milestone release and it would be very great, if I could include the values of the early assigned code-points. best regards Achim Kraus Am 05.04.19 um 22:18 schrieb Joseph Salowey: > We have received a request for early code-point assignment of values for > draft-ietf-tls-dtls-connection-id-04.=C2=A0 We believe that only editori= al > changes are pending. Please respond to this list of you have concerns > about these assignments by April 12, 2019. > > Thanks, > > Joe, Sean and Chris > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Mon Apr 15 08:18: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 8950D1203D3 for ; Mon, 15 Apr 2019 08:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 bi9cAQmsNDL1 for ; Mon, 15 Apr 2019 08:18:22 -0700 (PDT) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 904271203A1 for ; Mon, 15 Apr 2019 08:18:22 -0700 (PDT) Received: by mail-qk1-x736.google.com with SMTP id c189so10074246qke.6 for ; Mon, 15 Apr 2019 08:18:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Wk9glp6yUHR1Xcd0kGt/8+uPzQ4Nc5WQoySjCOq66hg=; b=FjrIecXE7L8bINhiXDg36GnpNRWskj8sL4yIwlzugl2GDF7eA7E24fbtE/4LuPJZyj jVmpZzdNFYE8m2E6c31HAmnlTPgUB6kuMjH88P57fnJ3gdWslPZhy6oRc3UgSCqSCeEp 3+FLWOtEHV6Ad3wg1a3HbJaN+InF+xu1fPY2Z1/nA/RrYKhJfY4OMabit/LDNIfYFbzU 6+LR5qHE1pRTDMditc7KkQuRfdk559gaTJs+I/T/cLY/PqhW8AuARTt2XC8xHr4fDx9m XJ3bRb7La8cpK9+2fSP3SeM/wJHA3odD0rC+I52rT9n8KTiid3fc2hnBjXqIhy25lHEp 436g== 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=Wk9glp6yUHR1Xcd0kGt/8+uPzQ4Nc5WQoySjCOq66hg=; b=BuW9p5BU/zSjTtP6RmM7fngLn0qmk58z+3HrEi5ot2XCNDHgQN/shau9/CenS9/h4t 4KBvRU9Jw7qchaJWZTNpIsfKqfAwpZVLgMTTyPRZymoimrZ0SSf0wk5PuNXQweTsXfdi OvHjo3Jq4M/7Y2dzLOdC9NsuxrKp3X6bQAjNltp3qREfAiQScYsiXE++pnD2nMMVJ9jf +ditTmNFKREpKZ+loY4MmbE5tLhdnWoQCtzWa4AubXx3sT8Y8okNNaQAi/IQ2HMdnVPg RGx5k31W8vuKBaB5njwlUqZmop68lemYYfZTrjA3FxEcHvjYBYMiaA6K3L0AL4+shG8W IEOA== X-Gm-Message-State: APjAAAVaT2+qLBfOk+nI7QsqMfbkUIzh4P5Owq9KG7kw+/+zeOXhQS2u 6kqqnl8vvruf7MtnNIx+oSNe6ayq5vrMbWzU3svZdw== X-Google-Smtp-Source: APXvYqxEyWrO+WqlgoLLhK7xrFbUJ40ymRcrMFFdYp5OG1OHwDkWo3fD6cdbaCuL2hhSMZBVkgSl1NFTQ9atpE3yr9k= X-Received: by 2002:a37:441:: with SMTP id 62mr50954414qke.204.1555341501646; Mon, 15 Apr 2019 08:18:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Joseph Salowey Date: Mon, 15 Apr 2019 08:18:10 -0700 Message-ID: To: Achim Kraus Cc: "" Content-Type: multipart/alternative; boundary="000000000000b5de52058693298b" Archived-At: Subject: Re: [TLS] early code-point assignment request for draft-ietf-tls-dtls-connection-id-04 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, 15 Apr 2019 15:18:25 -0000 --000000000000b5de52058693298b Content-Type: text/plain; charset="UTF-8" No concerns from the working group so I made the request to our AD. Cheers, Joe On Mon, Apr 15, 2019 at 6:55 AM Achim Kraus wrote: > Hello Joe, > > did the working group receive any concerns about the early code-point > assignment? I hope not. Hannes did again a very great job and so I > closed my open issues on the github repo. > Is there any schedule for the early code-point assignment? > I plan a next eclipse-californium milestone release and it would be very > great, if I could include the values of the early assigned code-points. > > best regards > Achim Kraus > > Am 05.04.19 um 22:18 schrieb Joseph Salowey: > > We have received a request for early code-point assignment of values for > > draft-ietf-tls-dtls-connection-id-04. We believe that only editorial > > changes are pending. Please respond to this list of you have concerns > > about these assignments by April 12, 2019. > > > > Thanks, > > > > Joe, Sean and Chris > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > --000000000000b5de52058693298b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
No concerns from the working group so I made the request t= o our AD.=C2=A0=C2=A0

Cheers,

J= oe

On Mon, Apr 15, 2019 at 6:55 AM Achim Kraus <achimkraus@gmx.net> wrote:
Hello Joe,

did the working group receive any concerns about the early code-point
assignment? I hope not. Hannes did again a very great job and so I
closed my open issues on the github repo.
Is there any schedule for the early code-point assignment?
I plan a next eclipse-californium milestone release and it would be very great, if I could include the values of the early assigned code-points.

best regards
Achim Kraus

Am 05.04.19 um 22:18 schrieb Joseph Salowey:
> We have received a request for early code-point assignment of values f= or
> draft-ietf-tls-dtls-connection-id-04.=C2=A0 We believe that only edito= rial
> changes are pending. Please respond to this list of you have concerns<= br> > about these assignments by April 12, 2019.
>
> Thanks,
>
> Joe, Sean and Chris
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--000000000000b5de52058693298b-- From nobody Mon Apr 15 08:53:55 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 E637312038F for ; Mon, 15 Apr 2019 08:53: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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 RoOiy8-0OZ0n for ; Mon, 15 Apr 2019 08:53:50 -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 4306812038B for ; Mon, 15 Apr 2019 08:53:50 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id t4so7645576ljc.2 for ; Mon, 15 Apr 2019 08:53:50 -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=9HYBJjFGxQ887vNRslrxKdWUA7foYJBSLHiyhlxFw2A=; b=h1gM9v6GP9jGgeiQw2rCbNU/mMyNnqmXFaUU4C3bXAaFSPESEkc7FD8EwIK4CYbZ3/ hOUhLPmHLeS2fvUfO61UMNWRFCNF1KSCWXtCJC6voNST0KWjkOupKpb8zwVdLPVtcDAC unNTpj2eisVG7HmxdXC3rjjNimkMI8VTysYTreHHhtnNxKhq2DJu9tfnlzugGpROtVu/ ewm0wNkQVmeOItn8jDl+QMIUd/b4LO/YwQ75Ft8wF/XGOQ2gT1rkhu+de+m1YmOB6g1i gIcCbXPsJXzI74tfswvvK7EnQZ2UwJc9AG6lSvLGZ/NdX5w3GV4jmlp3XH8+utr5chi2 ovAQ== 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=9HYBJjFGxQ887vNRslrxKdWUA7foYJBSLHiyhlxFw2A=; b=LLI4DUdG/EpmDDerV7SoAFDzQJd/26jUPC0RUCuJ01dduN8rEPhL028keYosng/Rd6 VUj/AqZ9ezn077iQRnXZaniN8dha1iAdAltiXSKL9TezDvKMufUgb3gUwB0cA/095mLc Ir/iusA+vRMTkh8jGpH29HSlfIjrDjqrljUdCOeugD136uIPl5ln+8OJ6mN0DltiQ2YQ X7qi68L5V9oi5wTYc5YbJEvKeRJScWJnKJ55rHLOoRubdbGDCeHUBcWwXjeUlF6LHF0N v2NSzdpSSOlM6KfBka9Gwcb10pRccDWLVpAPUk2W8UnIhsuHACJv67vurbGLCOryzgsB Tj/Q== X-Gm-Message-State: APjAAAWB92UGC9Aw8jWBKesrvu0CnAQh8XAJZF+eCpdT84IchzlSuRps GnVthhOKUfNI3g24WNElDyW9X6E+abYKuBE0PSM= X-Google-Smtp-Source: APXvYqycbOHc/OlfPvRV2hhqJMbh6IDfGH4pP0JUZVaJ/FoPM6Nm7E0sZiqtf7q5UcwTvkPlX6a7wvHKblhPbIF5X40= X-Received: by 2002:a2e:97d3:: with SMTP id m19mr1392259ljj.63.1555343628449; Mon, 15 Apr 2019 08:53:48 -0700 (PDT) MIME-Version: 1.0 References: <6ADEC907-1273-41AF-A964-68E654103645@ncl.ac.uk> In-Reply-To: From: Watson Ladd Date: Mon, 15 Apr 2019 08:53:34 -0700 Message-ID: To: "Hao, Feng" Cc: tls@ietf.org Content-Type: multipart/alternative; boundary="0000000000007a3f62058693a817" Archived-At: Subject: Re: [TLS] Elliptic Curve J-PAKE 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, 15 Apr 2019 15:53:54 -0000 --0000000000007a3f62058693a817 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Apr 15, 2019, 5:50 AM Hao, Feng wrote: > Hi Watson, > > =EF=BB=BFOn 15/04/2019, 00:39, "TLS on behalf of Watson Ladd" < > tls-bounces@ietf.org on behalf of watsonbladd@gmail.com> wrote: > > On Wed, Mar 27, 2019 at 11:36 PM Feng Hao > wrote: > > > > Hi Watson, > > > > When the attacker knows the relation, besides the active attack, > there may > > be other things he can exploit. This however is not usually analyse= d > as by > > the assumption of the proof, this should never happen. > > Random self-reducibility seems relevant here, as does the fact an > attacker should be able to solve any discrete logarithm problems over > a group one is using. > > OK, jargons apart - my point was about the assumption. If the relation of > the two system generators is known, the assumption of the proof is > violated, and the proof becomes invalid. > > > You=C2=B9re correct that J-PAKE uses Shamir-Fiat heuristics, hence = the > proof is > > in ROM. The key design principle in J-PAKE is based on understandin= g > the > > importance of zero-knowledge proof. The use of Shamir-Fiat > heuristics to > > make ZKP non-interactive is a standard technique in cryptography. I= n > the > > field of secure two/multi-party computation, ZKP is almost > universally > > used in every protocol. However, in the field of PAKE, to my > knowledge, > > J-PAKE is the only protocol that uses ZKP. On the other hand, if yo= u > think > > about PAKE, it=C2=B9s fundamentally a two-party secure computation > problem on > > an equality function (with the side benefit that both sides produce= a > > common session key when the equality holds). > > This paragraph is not responsive to my assertion that ROM=3D> common > random string. > > J-PAKE is an instance of a generic design approach where an honest bu= t > curious protocol is transformed into a malicious party secure on > through adding proofs of correctness. Each of those proofs and > verifications is expensive. Hence J-PAKE is expensive. The security o= f > JPAKE versus SPAKE2 is the same: both are secure in the ROM. > > As explained earlier, the difference is the "assumption" in the proof. > From the engineering perspective, we ought to prepare for the worst. When > one specific instance of the discrete logarithm is resolved, there is a b= ig > difference between the class attack and the session attack. This is in no > way to say the SPAKE2 draft that you're working on is not useful (on the > contrary, I think it can be useful in some specific applications where th= e > effect of a class attack is tolerable), but I just want to point out the > factual differences between the two. > Attackers shouldn't be able to compute any discrete logs, and they cannot go back and break old SPAKE2 sessions with that information (DH reduction I should write up). > > > > Cheers, > > Feng > > > > On 27/03/2019, 20:08, "Watson Ladd" wrote: > > > > >On Wed, Mar 27, 2019 at 7:56 PM Feng Hao > wrote: > > >> > > >> Hi Hugo, > > >> > > >> > > >> > > >> Thanks for your comments. > > >> > > >> > > >> Just to clarify the difference between SPAKE2 and J-PAKE - The > proof of > > >>SPAKE2 depends on the assumption of a trusted setup: the discrete > > >>logarithm between the two group generators must be unknown by > anyone. > > > > > >The above is not true: we rely on the common random string model, > not > > >the common reference model. This matters for below. > > > > > >>If a powerful adversary (3 letter agency) gathers sufficient > resources > > >>and time (say 1 year) to break one instance of discrete logarithm= , > it > > >>will be a class attack, breaking all >instances of SPAKE2 without > anyone > > >>knowing it. By contrast, they can only break one session in J-PAK= E, > > >>since by design the randomness is refreshed in every session > >rather > > >>than being built into a static setup. This explain why J-PAKE > requires > > >>more computation than SPAKE2. Hope it clarifies. > > > > > >I don't know of a JPAKE proof that doesn't rely on Shamir-Fiat > > >heuristic, which implies common random string. Your proof is in th= e > > >ROM no? Also I do not see how one recovers the password from past > > >sessions or recovers the negotiated key in this case: certainly an > > >active attack is possible knowing a relation! > > > > > >> > > >> > > >> Regards, > > >> > > >> Feng > > >> > > >> > > >> > > >> From: TLS on behalf of Hugo Krawczyk > > >> > > >> Date: Wednesday, 27 March 2019 at 02:49 > > >> To: Hannes Tschofenig > > >> Cc: "tls@ietf.org" > > >> Subject: Re: [TLS] Elliptic Curve J-PAKE > > >> > > >> > > >> > > >> Hi Hannes, > > >> > > >> > > >> > > >> J-PAKE is a symmetric PAKE. Both parties store the same password= . > It is > > >>not suitable for most client-server scenarios where using J-PAKE > would > > >>mean that an attacker that breaks into the server simply steals a= ll > > >>plaintext passwords. OPAQUE is an asymmetric (or augmented) PAKE > where > > >>user remembers a password (and nothing else, including no public > key of > > >>the server) while the server stores a one-way image of the > password. > > >>Security requires that if the server is compromised, the attacker > needs > > >>to run an offline dictionary attack for each user in the database > to > > >>find the password. > > >> > > >> > > >> > > >> If what you need is a symmetric PAKE then there are better > candidates > > >>than J-PAKE such as SPAKE2 described in draft-irtf-cfrg-spake2-08= . > > >>SPAKE2 is *much* more efficient than J-PAKE and while both J-PAKE > and > > >>SPAKE2 have proofs of security, SPAKE2 is proven in a stronger > security > > >>model relative to J-PAKE. > > >> > > >> > > >> > > >> I am not aware of any advantage of J-PAKE over SPAKE2 - but I ma= y > be > > >>missing something. Maybe the PAKE presentation in cfrg will clari= fy > > >>these issues further. > > >> > > >> > > >> > > >> Hugo > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> On Tue, Mar 26, 2019 at 1:03 PM Hannes Tschofenig > > >> wrote: > > >> > > >> Hi all, > > >> > > >> in context of the OPAQUE talk by Nick today at the TLS WG meetin= g > I > > >>mentioned that the Thread Group has used the Elliptic Curve J-PAK= E > for > > >>IoT device onboarding. > > >> Here is the draft written for TLS 1.2: > > >> https://tools.ietf.org/html/draft-cragie-tls-ecjpake-01 > > >> > > >> The mechanism is described in https://tools.ietf.org/html/rfc823= 6 > > >> > > >> @Nick & Richard: Have a look at it and see whether it fits your > needs. > > >> > > >> Ciao > > >> Hannes > > >> > > >> IMPORTANT NOTICE: The contents of this email and any attachments > are > > >>confidential and may also be privileged. If you are not the > intended > > >>recipient, please notify the sender immediately and do not > disclose the > > >>contents to any other person, use it for any purpose, or store or > copy > > >>the information in any medium. Thank you. > > >> > > >> _______________________________________________ > > >> 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 > > > > > > > > > > > >-- > > >"Man is born free, but everywhere he is in chains". > > >--Rousseau. > > > > > -- > "Man is born free, but everywhere he is in chains". > --Rousseau. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > --0000000000007a3f62058693a817 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Apr 15, 2019, 5:50 AM Hao, Feng <Feng.Hao@warwick.ac.uk> wrote:
Hi Watson,

=EF=BB=BFOn 15/04/2019, 00:39, "TLS on behalf of Watson Ladd" <= ;tls-bounces@ietf.org on behalf of watsonbladd@gmail.com> w= rote:

=C2=A0 =C2=A0 On Wed, Mar 27, 2019 at 11:36 PM Feng Hao <feng.hao@= newcastle.ac.uk> wrote:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Hi Watson,
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > When the attacker knows the relation, besides the active= attack, there may
=C2=A0 =C2=A0 > be other things he can exploit. This however is not usua= lly analysed as by
=C2=A0 =C2=A0 > the assumption of the proof, this should never happen.
=C2=A0 =C2=A0 Random self-reducibility seems relevant here, as does the fac= t an
=C2=A0 =C2=A0 attacker should be able to solve any discrete logarithm probl= ems over
=C2=A0 =C2=A0 a group one is using.

OK, jargons apart - my point was about the assumption. If the relation of t= he two system generators is known, the assumption of the proof is violated,= and the proof becomes invalid.

=C2=A0 =C2=A0 > You=C2=B9re correct that J-PAKE uses Shamir-Fiat heurist= ics, hence the proof is
=C2=A0 =C2=A0 > in ROM. The key design principle in J-PAKE is based on u= nderstanding the
=C2=A0 =C2=A0 > importance of zero-knowledge proof. The use of Shamir-Fi= at heuristics to
=C2=A0 =C2=A0 > make ZKP non-interactive is a standard technique in cryp= tography. In the
=C2=A0 =C2=A0 > field of secure two/multi-party computation, ZKP is almo= st universally
=C2=A0 =C2=A0 > used in every protocol. However, in the field of PAKE, t= o my knowledge,
=C2=A0 =C2=A0 > J-PAKE is the only protocol that uses ZKP. On the other = hand, if you think
=C2=A0 =C2=A0 > about PAKE, it=C2=B9s fundamentally a two-party secure c= omputation problem on
=C2=A0 =C2=A0 > an equality function (with the side benefit that both si= des produce a
=C2=A0 =C2=A0 > common session key when the equality holds).

=C2=A0 =C2=A0 This paragraph is not responsive to my assertion that ROM=3D&= gt; common
=C2=A0 =C2=A0 random string.

=C2=A0 =C2=A0 J-PAKE is an instance of a generic design approach where an h= onest but
=C2=A0 =C2=A0 curious protocol is transformed into a malicious party secure= on
=C2=A0 =C2=A0 through adding proofs of correctness. Each of those proofs an= d
=C2=A0 =C2=A0 verifications is expensive. Hence J-PAKE is expensive. The se= curity of
=C2=A0 =C2=A0 JPAKE versus SPAKE2 is the same: both are secure in the ROM.<= br>
As explained earlier, the difference is the "assumption" in the p= roof. From the engineering perspective, we ought to prepare for the worst. = When one specific instance of the discrete logarithm is resolved, there is = a big difference between the class attack and the session attack. This is i= n no way to say the SPAKE2 draft that you're working on is not useful (= on the contrary, I think it can be useful in some specific applications whe= re the effect of a class attack is tolerable), but I just want to point out= the factual differences between the two.

Attackers shouldn't be able to= compute any discrete logs, and they cannot go back and break old SPAKE2 se= ssions with that information (DH reduction I should write up).


=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Cheers,
=C2=A0 =C2=A0 > Feng
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > On 27/03/2019, 20:08, "Watson Ladd" <wat= sonbladd@gmail.com> wrote:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > >On Wed, Mar 27, 2019 at 7:56 PM Feng Hao <f= eng.hao@newcastle.ac.uk> wrote:
=C2=A0 =C2=A0 > >>
=C2=A0 =C2=A0 > >> Hi Hugo,
=C2=A0 =C2=A0 > >>
=C2=A0 =C2=A0 > >>
=C2=A0 =C2=A0 > >>
=C2=A0 =C2=A0 > >> Thanks for your comments.
=C2=A0 =C2=A0 > >>
=C2=A0 =C2=A0 > >>
=C2=A0 =C2=A0 > >> Just to clarify the difference between SPAKE2 a= nd J-PAKE - The proof of
=C2=A0 =C2=A0 > >>SPAKE2 depends on the assumption of a trusted se= tup: the discrete
=C2=A0 =C2=A0 > >>logarithm between the two group generators must = be unknown by anyone.
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >The above is not true: we rely on the common random = string model, not
=C2=A0 =C2=A0 > >the common reference model. This matters for below.<= br> =C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >>If a powerful adversary (3 letter agency) gather= s sufficient resources
=C2=A0 =C2=A0 > >>and time (say 1 year) to break one instance of d= iscrete logarithm, it
=C2=A0 =C2=A0 > >>will be a class attack, breaking all >instanc= es of SPAKE2 without anyone
=C2=A0 =C2=A0 > >>knowing it. By contrast, they can only break one= session in J-PAKE,
=C2=A0 =C2=A0 > >>since by design the randomness is refreshed in e= very session >rather
=C2=A0 =C2=A0 > >>than being built into a static setup. This expla= in why J-PAKE requires
=C2=A0 =C2=A0 > >>more computation than SPAKE2. Hope it clarifies.=
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >I don't know of a JPAKE proof that doesn't r= ely on Shamir-Fiat
=C2=A0 =C2=A0 > >heuristic, which implies common random string. Your = proof is in the
=C2=A0 =C2=A0 > >ROM no? Also I do not see how one recovers the passw= ord from past
=C2=A0 =C2=A0 > >sessions or recovers the negotiated key in this case= : certainly an
=C2=A0 =C2=A0 > >active attack is possible knowing a relation!
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >>
=C2=A0 =C2=A0 > >>
=C2=A0 =C2=A0 > >> Regards,
=C2=A0 =C2=A0 > >>
=C2=A0 =C2=A0 > >> Feng
=C2=A0 =C2=A0 > >>
=C2=A0 =C2=A0 > >>
=C2=A0 =C2=A0 > >>
=C2=A0 =C2=A0 > >> From: TLS <tls-bounces@ietf.org> on= behalf of Hugo Krawczyk
=C2=A0 =C2=A0 > >><hugo@ee.technion.ac.il>
=C2=A0 =C2=A0 > >> Date: Wednesday, 27 March 2019 at 02:49
=C2=A0 =C2=A0 > >> To: Hannes Tschofenig <Hannes.Tschofe= nig@arm.com>
=C2=A0 =C2=A0 > >> Cc: "tls@ietf.org" <tls@ietf.org> =C2=A0 =C2=A0 > >> Subject: Re: [TLS] Elliptic Curve J-PAKE
=C2=A0 =C2=A0 > >>
=C2=A0 =C2=A0 > >>
=C2=A0 =C2=A0 > >>
=C2=A0 =C2=A0 > >> Hi Hannes,
=C2=A0 =C2=A0 > >>
=C2=A0 =C2=A0 > >>
=C2=A0 =C2=A0 > >>
=C2=A0 =C2=A0 > >> J-PAKE is a symmetric PAKE. Both parties store = the same password. It is
=C2=A0 =C2=A0 > >>not suitable for most client-server scenarios wh= ere using J-PAKE would
=C2=A0 =C2=A0 > >>mean that an attacker that breaks into the serve= r simply steals all
=C2=A0 =C2=A0 > >>plaintext passwords. OPAQUE is an asymmetric (or= augmented) PAKE where
=C2=A0 =C2=A0 > >>user remembers a password (and nothing else, inc= luding no public key of
=C2=A0 =C2=A0 > >>the server) while the server stores a one-way im= age of the password.
=C2=A0 =C2=A0 > >>Security requires that if the server is compromi= sed, the attacker needs
=C2=A0 =C2=A0 > >>to run an offline dictionary attack for each use= r in the database to
=C2=A0 =C2=A0 > >>find the password.
=C2=A0 =C2=A0 > >>
=C2=A0 =C2=A0 > >>
=C2=A0 =C2=A0 > >>
=C2=A0 =C2=A0 > >> If what you need is a symmetric PAKE then there= are better candidates
=C2=A0 =C2=A0 > >>than J-PAKE such as SPAKE2 described in draft-ir= tf-cfrg-spake2-08.
=C2=A0 =C2=A0 > >>SPAKE2 is *much* more efficient than J-PAKE and = while both J-PAKE and
=C2=A0 =C2=A0 > >>SPAKE2 have proofs of security, SPAKE2 is proven= in a stronger security
=C2=A0 =C2=A0 > >>model relative to J-PAKE.
=C2=A0 =C2=A0 > >>
=C2=A0 =C2=A0 > >>
=C2=A0 =C2=A0 > >>
=C2=A0 =C2=A0 > >> I am not aware of any advantage of J-PAKE over = SPAKE2 - but I may be
=C2=A0 =C2=A0 > >>missing something. Maybe the PAKE presentation i= n cfrg will clarify
=C2=A0 =C2=A0 > >>these issues further.
=C2=A0 =C2=A0 > >>
=C2=A0 =C2=A0 > >>
=C2=A0 =C2=A0 > >>
=C2=A0 =C2=A0 > >> Hugo
=C2=A0 =C2=A0 > >>
=C2=A0 =C2=A0 > >>
=C2=A0 =C2=A0 > >>
=C2=A0 =C2=A0 > >>
=C2=A0 =C2=A0 > >>
=C2=A0 =C2=A0 > >>
=C2=A0 =C2=A0 > >>
=C2=A0 =C2=A0 > >> On Tue, Mar 26, 2019 at 1:03 PM Hannes Tschofen= ig
=C2=A0 =C2=A0 > >><Hannes.Tschofenig@arm.com> wro= te:
=C2=A0 =C2=A0 > >>
=C2=A0 =C2=A0 > >> Hi all,
=C2=A0 =C2=A0 > >>
=C2=A0 =C2=A0 > >> in context of the OPAQUE talk by Nick today at = the TLS WG meeting I
=C2=A0 =C2=A0 > >>mentioned that the Thread Group has used the Ell= iptic Curve J-PAKE for
=C2=A0 =C2=A0 > >>IoT device onboarding.
=C2=A0 =C2=A0 > >> Here is the draft written for TLS 1.2:
=C2=A0 =C2=A0 > >> https:= //tools.ietf.org/html/draft-cragie-tls-ecjpake-01
=C2=A0 =C2=A0 > >>
=C2=A0 =C2=A0 > >> The mechanism is described in https://tools.ietf.org/html/rfc8236
=C2=A0 =C2=A0 > >>
=C2=A0 =C2=A0 > >> @Nick & Richard: Have a look at it and see = whether it fits your needs.
=C2=A0 =C2=A0 > >>
=C2=A0 =C2=A0 > >> Ciao
=C2=A0 =C2=A0 > >> Hannes
=C2=A0 =C2=A0 > >>
=C2=A0 =C2=A0 > >> IMPORTANT NOTICE: The contents of this email an= d any attachments are
=C2=A0 =C2=A0 > >>confidential and may also be privileged. If you = are not the intended
=C2=A0 =C2=A0 > >>recipient, please notify the sender immediately = and do not disclose the
=C2=A0 =C2=A0 > >>contents to any other person, use it for any pur= pose, or store or copy
=C2=A0 =C2=A0 > >>the information in any medium. Thank you.
=C2=A0 =C2=A0 > >>
=C2=A0 =C2=A0 > >> _______________________________________________=
=C2=A0 =C2=A0 > >> TLS mailing list
=C2=A0 =C2=A0 > >> TLS@ietf.org
=C2=A0 =C2=A0 > >> https://www.ietf.org= /mailman/listinfo/tls
=C2=A0 =C2=A0 > >>
=C2=A0 =C2=A0 > >> _______________________________________________=
=C2=A0 =C2=A0 > >> TLS mailing list
=C2=A0 =C2=A0 > >> TLS@ietf.org
=C2=A0 =C2=A0 > >> https://www.ietf.org= /mailman/listinfo/tls
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >--
=C2=A0 =C2=A0 > >"Man is born free, but everywhere he is in chai= ns".
=C2=A0 =C2=A0 > >--Rousseau.
=C2=A0 =C2=A0 >


=C2=A0 =C2=A0 --
=C2=A0 =C2=A0 "Man is born free, but everywhere he is in chains".=
=C2=A0 =C2=A0 --Rousseau.

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 TLS mailing list
=C2=A0 =C2=A0 TLS@ietf.org
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listi= nfo/tls


--0000000000007a3f62058693a817-- From nobody Tue Apr 16 01:36: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 1B1C7120361 for ; Tue, 16 Apr 2019 01:36:00 -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_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 NAGT5Xx7F6ST for ; Tue, 16 Apr 2019 01:35:57 -0700 (PDT) Received: from mailhost.informatik.uni-hamburg.de (mailhost.informatik.uni-hamburg.de [134.100.9.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 422BC120354 for ; Tue, 16 Apr 2019 01:35:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTP id 5CAAAFBC; Tue, 16 Apr 2019 10:35:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at informatik.uni-hamburg.de Received: from mailhost.informatik.uni-hamburg.de ([127.0.0.1]) by localhost (mailhost.informatik.uni-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id mCwhHm85YziZ; Tue, 16 Apr 2019 10:35:54 +0200 (CEST) Received: from svs26.informatik.uni-hamburg.de (svs26.informatik.uni-hamburg.de [134.100.15.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: sy) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTPSA id 8647EFBB; Tue, 16 Apr 2019 10:35:53 +0200 (CEST) Reply-To: sy@informatik.uni-hamburg.de To: Martin Thomson , tls@ietf.org References: <4f21da8a-a30c-4255-9400-aab3a599fb9b@www.fastmail.com> <9ae5725b-c0a7-4602-bd0a-da04509db62a@www.fastmail.com> From: Erik Sy Openpgp: preference=signencrypt Autocrypt: addr=sy@informatik.uni-hamburg.de; prefer-encrypt=mutual; keydata= mQENBFdYdRoBCADpTVcxZw2Z+3IEm8QgmYNdzKQdCPnDm3mvV+dskI2vNuhAM7eTHE62Ibl8 TD08JJ0Q5DbaHLZBYZR7dVc6Vw+p5Ns5YM5MpDH4rcJTm9FR/QgJ94dH0dOKwtq9gMhLdlhV N0v/OgDb7YdfNYzhthVc3MUxBEznspDaBsGXCASM98SvCaovrhDU05OyIIq6yaIZc6W1ad8z oLn3kZ1O0NkJFuS2H6W1Sg6+af2980SagRTEntr/U6y9wKrKMr0woPBkgYjjivW31yRpjbW0 FClGr/WamdETrJFMTnn6Zc4tELj4pI5T/3jsSCuJ+Mf0fxGIoznG1xW09E5KoT4RBQZ7ABEB AAG0JkVyaWsgU3kgPHN5QGluZm9ybWF0aWsudW5pLWhhbWJ1cmcuZGU+iQFBBBMBCgArAhsD BQkFo5qABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAUCV8aJfQIZAQAKCRB4ziXHIWIRJSVz B/wJ1qq82vLrjp+4GOUJf3w23FGK3gtK0THs7VVwtZD+xRGYOzoMG+my0TscPZI5drHnZJeK vYmx+bz0IvJSW9DgYib5kUKtz2qPmj0HR6qW7o5opbIMWmkZJO0ACUEI3pAX+j7O3nEApijT 6dg3XhkLdRBgKVHD6x7n8a0ZbYEta6Co0vmPSpIU8XL1B0MmC9fC/L85kH3MBU0bNA4QU0b+ I9ojylgLnqHhIL39mqpJ/cRfCkuzWeeyFvvD+EGMBVxVKVu7ULNk4sKvqutsoYV6GQ7pAx+O pCKQO87M8aeMF7ytpQ67WGscqCO6IWO5tqDXX3aV9MCswPsuwn+PGjAguQENBFdYdRoBCADQ HO0cmKfEv9y5WW6sXJdnn7PEknFyiI9HoCULGVJi4vWyqYoQBGAM8wWRAVstm8zhqIWTlKR2 EntH6JBQB9dkUtmvuVRBBXs9SSloZU4R7SDysuTmDo3derqbIcomtyTkbfxYI50EQayL8TgR sA6jj9OJzyeywX3c+Nr6G8a0kVvCB97I1qLO5RA1tTIxTiXJMbL+E3CurUIMAakxbuqfH3SV mtH+lmlvGzvUF9mI4a5xti1Jkl/k6p2Q5z3nLt6MgkC9n47BSvrzelIr526FzNTamFIVb4fT /QnC33IydbaVQZaOYD9wi9dHTRBaeAF5a+zY5MCUu17GV3jR36SVABEBAAGJASUEGAECAA8F AldYdRoCGwwFCQWjmoAACgkQeM4lxyFiESV1zwf+PwKloXwIb7450kQq/OukJ90o9jkfGMz1 uC84E/HoYaz8KBUJVmx07zYi0zopAn2Pvh+HtTB6NzoGoRvmvajVa3lWRVeytgtJp+YqdcJq mKa+c1MsrJD2iMr3jMLB70bWT+GA8Moe1Slw4+/c+BndlwnfA5B54PVHjnZtaJDVsyVO1dnj gPReP6YNOQP/AgGexfSqUMYI/ni1QKwMT8e806hc48zT2A1ZnBit5PkGjzvQU0Qoel6Cwj3R uzZJgC5iEdX6kxMEOB0mD6zSKzBg4FNn2r3kUQ24IhbTuMm6/aCv6YlObR8HHkqXcQF6/BTH jlkuqsjIxOXZXqe4DeUnhw== Message-ID: <2e691b63-2108-2d25-4b2d-7c56ce79d583@informatik.uni-hamburg.de> Date: Tue, 16 Apr 2019 10:35:52 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <9ae5725b-c0a7-4602-bd0a-da04509db62a@www.fastmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [TLS] Adoption call for draft-sy-tls-resumption-group 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, 16 Apr 2019 08:36:00 -0000 Hi Martin, can you please explain, why you think this is not the right solution? To start the discussion, I provide below some insights on why I ended up with this solution. Question 1: Shall the problem be solved by a cross-layer solution or by a TLS-only approach? Arguments for a TLS-only approach: + It is simpler to solve the problem within TLS + TLS resumptions across SNI values are available for every use case of TLS + So far, there does not exist a mechanism in another protocol which can be directly used to indicate feasible session resumptions across SNI values Arguments for a cross-layer solution: + Context information of other protocols such as HTTP and IP can be used to fine-tune resumptions across SNI values Question 2: Shall the TLS resumption group be defined as a separate list provided by the server or cover the entire SAN list of the certificate? Note, that it is a strict requirement that resumptions across SNI values are only conducted if the involved SNI values are valid for the server certificate presented during the initial connection establishment. Arguments for a separate list: + Flexibility, to define the resumption group without some entries of the SAN list Arguments for defining the resumption group as the entire SAN list: + smaller overhead in terms of data traffic + Simpler and hopefully avoids new security errors that implementations allow to conduct session resumptions to illegitimate SNI values Finally, I ended up with a TLS-only approach using the entire SAN list a resumption group. However, I do not claim that the provided lists of arguments are complete and would like to encourage you to contribute to this list. Thanks, Erik On 4/13/19 06:10, Martin Thomson wrote: > I like the basic idea, but I don't think that this is the right solution. I realize that we can adopt and fix, but I my preference is to have a little more time to discuss solutions before we adopt anything. > > On Sat, Apr 13, 2019, at 09:35, Christopher Wood wrote: >> At TLS@IETF104, there was interest in the room to adopt >> draft-sy-tls-resumption-group as a WG item. The draft can be found here: >> >> https://datatracker.ietf.org/doc/draft-sy-tls-resumption-group/ >> >> This email starts the call for adoption. It will run until April 26, >> 2019. Please indicate whether or not you would like to see this draft >> adopted. >> >> Thanks, >> Chris, Joe, and Sean >> >> _______________________________________________ >> 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 Apr 22 16:07: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 28D7F120168 for ; Mon, 22 Apr 2019 16:07:37 -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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=v3LimzH1; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=s5i8p+oc Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xuWVNCTZOa6K for ; Mon, 22 Apr 2019 16:07:34 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B71121200B1 for ; Mon, 22 Apr 2019 16:07:34 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 9760521ADD; Mon, 22 Apr 2019 19:07:32 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Mon, 22 Apr 2019 19:07:32 -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=fm2; bh=AhL5ilBKHxnbIro0IB+r3JA5sJnB wuhgikMa8LJfDyk=; b=v3LimzH1f6bVSEz76uUANyjPwxa1gY/R9dq7dYTlMPQA 0YtEWAEfV/l0jSfGVwlID2f0dPfxwrxF//TCEshRFdZqN1d0igbKyF2uJHZblovn SGq6pdu9ijfLBjtr1NlrmgFck6cYEg7woBN0b4o6K8RguiYnqV+/nu8523SrC9J9 Ln2ZTrduRMdItWoALCPy3Xh92u6C+q44HgSEhLzcddqwEl/MhORoqbssUEF7x7te 0v3r2nDPZe4YguJmC4AQckrc/GeVbxexxgo0HgkH5AQIfYjSWmxTBvZFU3ExZDAc jMJEgZRtxUQn5G1t3gE2tCZhwj/K4IsBpxU7IeEv7g== 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=fm2; bh=AhL5il BKHxnbIro0IB+r3JA5sJnBwuhgikMa8LJfDyk=; b=s5i8p+oc69SbppnDarywB4 zBRpnQyFStmJn9p+rROal3kU91Q6BQuEgtDe4xUoaGSoBgkoj/+9yO0G82Uv12qT /LFpVGqgP7FqKYVYINmBuVvDpIfaJWj/QjpDyd/7vsQEQ89/ioIEFYevFrKqMFNf ZHD1bawBk3mx4dZXRNjafcPWdUuSV34uylh4BQbPWJm3H5r710U6/+Isvwo3tzsT DjsJDtLk9ohcZ/cfJ9R9WnbhblGW5ljllXusjuA4TFKj01tp9sgrld9eLFg9wAmK J3Gki/Oz/fYmdGvBL05yhKpFZoVsBAYpN1QKGq/DfvTuXm0Pa6htXTAsfqcpA0nA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrgeejgddutdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfofgrrhht ihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenucffoh hmrghinhepihgvthhfrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhho figvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0274A7C539; Mon, 22 Apr 2019 19:07:31 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-443-g918f9d3-fmstable-20190416v3 Mime-Version: 1.0 X-Me-Personality: 92534000 Message-Id: In-Reply-To: References: <745ED9FE-9C31-4687-BD64-836155A28AEC@ericsson.com> <3C099064-52D9-49C3-9180-A01FBDEE876A@ericsson.com> <523c1d42-c4bb-4206-b9be-bcec93973424@www.fastmail.com> Date: Mon, 22 Apr 2019 19:07:34 -0400 From: "Martin Thomson" To: "Jonathan Hoyland" Cc: "" Content-Type: text/plain Archived-At: Subject: Re: [TLS] Comment on draft-thomson-tls-sic-00 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, 22 Apr 2019 23:07:37 -0000 Yes, digesting the chain is likely to fail. The set of "intermediates" that are included are not a strictly deterministic set. Counter-signing of trust anchors and other such practices mean that the client and server wouldn't be able to agree to the point that a digest would be reliable. There are two things that you might want agreement on here, if you want agreement about anything. 1. Agreement on what was put into the handshake messages, or the contents of a Certificate message. 2. Agreement on what the certification path is. If the server omits intermediates, then we still get agreement on the content of the message, but whether we agree on the identity of the intermediate that the client ultimately uses is what you are concerned with. However, if we look at the second, we already lack TLS transcript protection for the full certification path because trust anchors are in practice (and by recommendation) omitted from the Certificate message anyway. This proposal just moves that one step further down the chain. So your question is more of a general question with TLS. If we don't include certain elements of the certification path in the handshake transcript, how do we know that the client and server agree on how the server identity was validated? The current answer, which might not seem satisfactory, is that there is no agreement or understanding. The various ways in which certification paths are recovered (see AIA chasing, missing intermediates) and then constructed is something of a mystery. In practice, people shove certificates into Certificate until the clients they care about accept the chain. And I would contend that agreeing on how authentication is performed is not entirely necessary[1]. The decision about whether a peer identity is valid is made by each participant independently. The information in Certificate is input to that process, but not the only input. We might also have other things, like pinned keys or CT policies, that also read on that decision. --Martin [1] We do, as much as possible, try to even this out, but the fact is that there are a number of subtle differences in client requirements. On Mon, Apr 15, 2019, at 19:09, Jonathan Hoyland wrote: > Hi Martin, > > Could you comment on how the client and server know they agree on the > certificate chain? > Would it be possible for the client and server to resolve the > certificate chain down two distinct paths, for example in the case of > cross signed certificates? > > If so, is there a security risk here, as in, does it matter if the > client and server disagree on the chains? > Could an attacker perform some shenanigans with disjoint roots of > trust, or by finding paths with differing policy constraints (if that > even makes sense)? > > Would it help anything if the server included a digest of the > certificate chain in its EncryptedExtensions? > > Regards, > > Jonathan > > On Thu, 11 Apr 2019 at 03:58, Martin Thomson wrote: > > On Sat, Mar 30, 2019, at 06:05, John Mattsson wrote: > > > And one more.... > > > > > > "The 0xTBD flag can only be send in a ClientHello or CertificateRequest > > > message. Endpoints that receive a value of 1 in any other handshake > > > message MUST generate a fatal illegal_parameter alert." > > > > > > This goes against draft-nir-tls-tlsflags > > > > > > "A server that supports this extension and also supports at least one > > > of the flag-type features that use this extension and that were > > > declared by the ClientHello extension SHALL send this extension with > > > the intersection of the flags it supports with the flags declared by > > > the client." > > > > > > I assume the sic sic extension should be sent in EncryptedExtensions. > > > > I think that this is a problem in draft-nir-tls-tlsflags. Extensions in ClientHello are "answered" in two places: EncryptedExtensions and Certificate. The requirement that the flag be echoed creates a problem in that context. > > > > We could define separate "Handshake flags" and "Certificate flags", but that complicates things. > > > > If you look at extension usage, you see that not all "flags" are echoed. In this case, a requirement to echo would just increase the size of Certificate for no good reason - the extension can be omitted completely. > > > > We should only require the presence of the flag where it carries semantics. The requirement should be stated as > > > > Implementations MUST NOT set flags in extension responses if the remote > > endpoint did not send the corresponding flag in extension requests. Upon > > receiving a flag that is incorrectly set, an endpoint MUST abort the handshake > > with an "unsupported_extension" [?] alert. > > > > Mirroring the language from RFC 8446. > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Apr 23 10:05: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 B9A87120359 for ; Tue, 23 Apr 2019 10:05:42 -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_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 W5jB76iexHzq for ; Tue, 23 Apr 2019 10:05:41 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F56F12011A for ; Tue, 23 Apr 2019 10:05:41 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 3C735B80E45; Tue, 23 Apr 2019 10:05:34 -0700 (PDT) To: ynir.ietf@gmail.com, simon@josefsson.org, mpg@elzevir.fr, rdd@cert.org, kaduk@mit.edu, caw@heapingbits.net, joe@salowey.net, sean+ietf@sn3rd.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: Frank.Theinen@web.de, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20190423170534.3C735B80E45@rfc-editor.org> Date: Tue, 23 Apr 2019 10:05:34 -0700 (PDT) Archived-At: Subject: [TLS] [Technical Errata Reported] RFC8422 (5703) 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, 23 Apr 2019 17:05:43 -0000 The following errata report has been submitted for RFC8422, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5703 -------------------------------------- Type: Technical Reported by: Frank Theinen Section: 5.10. Original Text ------------- All RSA signatures must be generated and verified according to Section 7.2 of [RFC8017]. Corrected Text -------------- All RSA signatures must be generated and verified according to Section 8.2 of [RFC8017]. Notes ----- Section 7.2 of RFC 8017 describes the RSAES-PKCS1-v1_5 encryption scheme. Section 8.2 of RFC 8017 describes the RSASSA-PKCS1-v1_5 signature scheme. The original text contradicts the natural expectation and is probably wrong. If it was intended, there should have been a thorough explanation (like in the well-known case of IKEv1 using the encryption scheme for signing). 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. -------------------------------------- RFC8422 (draft-ietf-tls-rfc4492bis-17) -------------------------------------- Title : Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier Publication Date : August 2018 Author(s) : Y. Nir, S. Josefsson, M. Pegourie-Gonnard Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Tue Apr 23 11:21:07 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 4C85A12046F; Tue, 23 Apr 2019 11:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 85Pk78yxxhHg; Tue, 23 Apr 2019 11:21:02 -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 99B0C12046D; Tue, 23 Apr 2019 11:20:59 -0700 (PDT) Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x3NIKtYJ021761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 Apr 2019 14:20:57 -0400 Date: Tue, 23 Apr 2019 13:20:55 -0500 From: Benjamin Kaduk To: draft-ietf-tls-exported-authenticator.all@ietf.org Cc: tls@ietf.org Message-ID: <20190423182055.GC49657@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] AD review of draft-ietf-tls-exported-authenticator-08 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, 23 Apr 2019 18:21:05 -0000 Hi all, I don't think there's anything earth-shattering in here; mostly just places where we can tighten things up before it gets to a broader set of reviewers. Thanks! -Ben Abstract, Introduction Maybe s/other party/peer/? Section 1 This document provides a way to authenticate one party of a Transport Layer Security (TLS) communication to another using a certificate after the session has been established. This allows both the client and server to prove ownership of additional identities at any time after the handshake has completed. This proof of authentication can be exported and transmitted out of band from one party to be validated by the other party. We need to be careful about what exactly is being proved when, and how it synchronizes (or doesn't) with other events/data. This will be a general theme throughout... multiple identities - Endpoints that are authoritative for multiple identities - but do not have a single certificate that includes all of the identities - can authenticate with those identities over a single connection. (The RFC Editor will do two-hyphen em dashes.) I didn't go back and reread the formal analysis that Jonathan sent out, but my recollection was that the semantics around being "jointly authoritative" over multiple identities are quite subtle, and that the wording here may be doing the reader a disservice. This document intends to replace much of the functionality of renegotiation in previous versions of TLS. It has the advantages over renegotiation of not requiring additional on-the-wire changes during a connection. For simplicity, only TLS 1.2 and later are supported. Well, renegotiation does many things. We need to say why we claim that renegotiation was widely used and for what purpose(s), and only then say that we provide an alternative. Also, the wording about "previous versions of TLS" is pretty vague -- is it intended to be "prior to TLS 1.3"? Post-handshake authentication is defined in TLS 1.3, but it has the disadvantage of requiring additional state to be stored in the TLS state machine and it composes poorly with multiplexed connection protocols like HTTP/2 [RFC7540]. It is also only available for We should probably be more explicit about "composes poorly" being due to the authentication not being tied to a specific event at the higher layer (among other things). Section 3 The authenticator request is a structured message that can be exported from either party of a TLS connection. It can be transmitted to the other party of the TLS connection at the application layer. The application layer protocol used to send the authenticator SHOULD use TLS as its underlying transport to keep the request confidential. Also to indicate which TLS connection to pull key material from? This message does not include the TLS record layer and is therefore not encrypted with a handshake key. We should probably reword this -- "include the TLS record layer" is going to confuse people. It may be as simple as just adding "framing". The CertificateRequest is used to define the parameters in a request for an authenticator. The definition for TLS 1.3 is: struct { opaque certificate_request_context<0..2^8-1>; Extension extensions<2..2^16-1>; } CertificateRequest; I think we need some filler paragraph in here noting that we re-use the data structure but assign slightly different meanings to the fields ("as follows") -- otherwise it sounds like we're just repeating the whole definition including field descriptions, which we clearly are not ("[t]his value is unrelated to the certificate_request_context used in post-handshake authentication"). from pre-computing valid authenticators. This value is unrelated to the certificate_request_context used in post-handshake authentication and collisions do not need to be avoided. This text seems to invite the reader to ask "collisions between what". Perhaps we should just say "there is no need to ensure uniqueness between values used in post-handshake authentication and values used for exported authenticators". Though if we do that, maybe we want to follow up by reiterating the need for uniqueness within each class on its own. extensions: The extensions that are allowed in this structure include the extensions defined for CertificateRequest messages defined in Section 4.2. of [TLS13] and the server_name [RFC6066] extension, which is allowed for client-generated authenticator requests. Do we need to create a new "message type" for the "TLS 1.3" column in the registry (https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml) for future extensibility? Section 4 An authenticator message can be constructed by either the client or the server given an established TLS connection, a certificate, and a corresponding private key. Clients MUST NOT send an authenticator without a preceding authenticator request; for servers an authenticator request is optional. The authenticator uses the I think at this point in the document we haven't indicated what context value to use for unsolicited exported authenticators from the server. Do we want to say something here? Section 4.1 The context_value used for the exporter is empty (zero length) for all four values. The length of the exported value is equal to the When I first read this I felt a need to think through the consequences of using the empty context_value here. A statement to the effect of "the exporter value is used as a standard API to obtain a value that includes the TLS handshake transcript hash. There is no need to include additional context information at this stage, since the application-supplied context is included in the actual authenticator object" would probably alleviate the concerns of many readers. length of the output of the hash function selected in TLS for the pseudorandom function (PRF). Cipher suites that do not use the TLS PRF MUST define a hash function that can be used for this purpose or Process-wise this is not great wording, seemingly attempting to bind the specifications of (already extant?) TLS ciphers to do more work. It's probably better to phrase it like "exported authenticators cannot be used with cipher suites that do not use the TLS PRF and have not defined a hash function for this purpose". If the connection is TLS 1.2, the master secret MUST have been computed with the extended master secret [RFC7627] to avoid key synchronization attacks. Let's rephrase this as "Exported Authenticators MUST NOT be generated or accepted on connectons not using the extended master secret [RFC7627] extension, to avoid key synchronization attacks", to be very explicit about the prohibited behavior. section 4.2 If an authenticator request is present, the extensions used to guide the construction of these messages are taken from the authenticator request. Unrecognized extensions MUST be ignored. If the certificate_request_context from the authenticator request has already been used in the connection, then no authenticator should be What does "used" mean? Only servers can provide an authenticator without a corresponding request. [...] This statement duplicates a requirement already stated above. ClientHello extensions are used to determine permissible extensions in the Certificate message. I'd suggest reiterating the "negotiation" model for extensions, and that you generally can't send something in a response that you didn't receive in a request (with, of course, the hardcoded exceptions listed in the initial spec for that functionality). Section 4.2.1 In addition to "signature_algorithms" and "signature_algorithms_cert", the "server_name" [RFC6066], "certificate_authorities" (Section 4.2.4. of [TLS13]), and "oid_filters" (Section 4.2.5. of [TLS13]) extensions are used to guide certificate selection. The extensions, or others that might affect certificate selection, are taken from the authenticator request if present, or the TLS handshake if not. The text about "taken from the authenticator request if present, or the TLS handshake if not" seems to be duplicating previous discussions. Maybe go with "commonly used [to guide certifciate selection]"? We don't limit what can be used for that purpose in core spec, IIRC. I'm a little reluctant to bring this up, as it's fairly tangential to this document, but there seems to be some general disagreement in the community about whether the SNI usage model is a proper "negotiation", where the recipient has to ack the offered value in order for both parties to agree what server name is in use, versus an assertive model where the sender just says "this is who I'm trying to talk to" and decides from the received certificate whether that's the case. But it doesn't look like we have a way to echo back the accepted SNI in this message flow.... Alternative certificate formats such as [RFC7250] Raw Public Keys are not supported in this version of the specification. Even if we call out some things that aren't supported, we probably still want to explicitly state what format we do support. If an authenticator request was provided, the Certificate message MUST contain only extensions present in the authenticator request. Otherwise, the Certificate message MUST contain only extensions present in the TLS handshake. "Present in the TLS handshake" could mean SH or EE, too (but we just mean CH). Also, this is the third time we say that! Section 4.2.2 If an authenticator request is present, the signature algorithm MUST be chosen from one of the signature schemes in the authenticator request. Otherwise, the signature algorithm used should be chosen from the "signature_algorithms" sent by the peer in the TLS handshake. This text could probably be tightened up. Specifically, we mean in the CH if we are falling back to the handshake values, and I don't think we say what to do if we're using TLS 1.2 and "signature_algorithms" wasn't sent in the ClientHello. Where Hash is the hash function negotiated by TLS. If the authenticator request is not present, it is omitted from this construction (that is, it is zero length). Above, we say that this Hash could be defined on a per-ciphersuite basis post-facto; does this text need to be changed to be consistent? failed CertificateVerify validation, it may be helpful for the application to confirm that both peers share the same connection using a value derived from the connection secrets before taking a user-visible action. We may want to define a new exporter for that, here, to keep people from rolling their own custom (read: broken) scheme. Also, we could say something about needing to identify (by context?) which TLS connection to use for a given EA validation... Section 4.2.3 Maybe give the hash output a good name so we don't get confused about Hash vs. HMAC? The HMAC is computed using the same hash function using the Finished MAC Key as a key. comma after "function"? Section 4.2.4 Do we want to reiterate that the record layer framing is not used? A given authenticator can be validated by checking the validity of the CertificateVerify message given the authenticator request (if used) and recomputing the Finished message to see if it matches. "can be" is not very strong language; do we want to be more proscriptive about what needs to be done for proper validation? Also, is a constant time comparison going to be needed? Section 5 Same comments as above about a comma, and naming the Hash output. Section 6 it is possible to implement it at the application layer. TLS implementations supporting the use of exported authenticators MUST provide application programming interfaces by which clients and servers may request and verify exported authenticator messages. Some people will complain that the MUST is not enforcable by the peer. Perhaps saying why we want that property would help, though. o the connection is TLS 1.2 and the extended master secret [RFC7627] was not used nit: "extension", "negotiated" Section 6.1 The "request" API takes as input: o certificate_request_context (from 0 to 255 bytes) How do I pick this context value? Is it always going to be input from the application layer or might I need to pick something (randomly) within the TLS stack? o set of extensions to include (this MUST include signature_algorithms) It returns an authenticator request, which is a sequence of octets that includes a CertificateRequest message. "includes" or "is"/"comprises"? Section 6.3 The "authenticate" takes as input: nit: "API" o a signer (either the private key associated with the certificate, or interface to perform private key operation) for each chain If I'm doing a spontaneous server-driven EA but I have multiple possible chains I could use, is there guidance to give about who should do the picking (application vs. TLS stack) and what the choice should be? o an optional authenticator request or certificate_request_context (from 0 to 255 bytes) Why the choice? It returns either the exported authenticator or an empty authenticator as a sequence of octets. It is RECOMMENDED that the logic for selecting the certificates and extensions to include in the exporter is implemented in the TLS library. Implementing this in the TLS library lets the implementer take advantage of existing extension and certificate selection logic. Also to more easily remember what extensions were in CH, right? It is also possible to implement this API outside of the TLS library using TLS exporters. This may be preferable in cases where the application does not have access to a TLS library with these APIs or when TLS is handled independently of the application layer protocol. It's harder to remember what extensions were sent in the ClientHello in this case, though. Section 6.4 What do we do if a triggered and spontaneous EA race, w.r.t. the input to the validation process. Do we need to check the context that we're trying to validate? It returns the certificate chain and extensions and a status to indicate whether the authenticator is valid or not. If the authenticator was empty - that is, it did not contain a certificate - the certificate chain will contain no certificates. Should we say what we expect the caller to be doing with the certificate chain? Also, is an empty authenticator going to be considered "valid"? Section 8 The Certificate/Verify/Finished pattern intentionally looks like the TLS 1.3 pattern which now has been analyzed several times. In the case where the client presents an authenticator to a server, [SIGMAC] presents a relevant framework for analysis. Why is it only in that case? o This property makes it difficult to formally prove that a server is jointly authoritative over multiple certificates, rather than individually authoritative over each. I mentioned this already, but these difficulties should be mentioned earlier/throughout, and we should think about providing some usage guidance for use patterns believed to be safe. o There is no indication in the TLS layer about which point in time an authenticator was computed. Any feedback about the time of creation or validation of the authenticator should be tracked as part of the application layer semantics if required. IIUC, all we know is that it's tied to this connection, plus the semantics of whatever additional data the application put into the context field. Should we say that more explicitly? From nobody Wed Apr 24 00:36: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 5EBDC1200F6 for ; Wed, 24 Apr 2019 00:36:48 -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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=ysJ/ThvD; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=V0Mq42kS Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBzZrUM8kmSb for ; Wed, 24 Apr 2019 00:36:46 -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 8DE8A12006F for ; Wed, 24 Apr 2019 00:36:46 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id A67E2220FD; Wed, 24 Apr 2019 03:36:45 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Wed, 24 Apr 2019 03:36:45 -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 :subject:content-type; s=fm2; bh=kMYrjAbnM4CToD3o27n57D05kwGqwTj aSPsnKjrgUdw=; b=ysJ/ThvD3Sj5G2vzXltS21JW4xXn7YOME2ZvytsLeHTpDl/ 8fGusH0mKWwMZcHstp0LORLbYoyxc8/aBnhSET+DHxeba+dh4inT1Q4R5QMgmIen ZPWY1ILxqaNkmPcqbAMzpI6b/dehh6lk/26p1SuwIRrUXypjcooWc5CVnG4GFHgG 1XjrtmjsgFoAvU7GBHqiLptHyY1iygq/lOtCSer2XOn0mzgz2dkFnvLCr1kiLtb2 n65zh/QvvgaolHv74WK43KJ3ZnYOPMblgZQunQR3dDDRsmKlSe2ZtISNSD2ygswO sckNyicb2vbSTHW+cCjn4wrmwAYJxA4Jqz+7jAQ== 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=fm2; bh=kMYrjA bnM4CToD3o27n57D05kwGqwTjaSPsnKjrgUdw=; b=V0Mq42kS+PDD9bk4MwW7X2 aV0/+TKcuO4Ncsztb4o/yVWQuFVN04A0avmWb2xLeHFQx2B2RsJow0TErunPEjb1 vh3s06mBv0Fw/aYK174Fux7anzaiUNW6ugaskMy535hVdZWdWHOSl+cD3J3z4jOS xgmkfKyYfNbSqQiJHPY2NcVghS/AKzQtb2PPfeOIRbiqg+8ygWd8wlfV3jb0ecjB /9rPeGoNf41s5BB0jOWypLqkadiinhck1Xv2f4gVvxmdYAVITGZ7XLkrUxURdSko xAg8wc2Xc8jHOCqVlq92Myge3IAkuqNqh2x/jXTvXhPCxaxH8QDDj8cjWDcNzTRQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrgeelgdduvdduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehloh ifvghnthhrohhphidrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id C936F7C199; Wed, 24 Apr 2019 03:36:44 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-444-g755619f-fmstable-20190423v1 Mime-Version: 1.0 Message-Id: <47a2773b-8943-4fc0-a024-d8c81a3dc627@www.fastmail.com> In-Reply-To: <2e691b63-2108-2d25-4b2d-7c56ce79d583@informatik.uni-hamburg.de> References: <4f21da8a-a30c-4255-9400-aab3a599fb9b@www.fastmail.com> <9ae5725b-c0a7-4602-bd0a-da04509db62a@www.fastmail.com> <2e691b63-2108-2d25-4b2d-7c56ce79d583@informatik.uni-hamburg.de> Date: Wed, 24 Apr 2019 03:36:45 -0400 From: "Martin Thomson" To: "Erik Sy" , tls@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [TLS] Adoption call for draft-sy-tls-resumption-group 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, 24 Apr 2019 07:36:48 -0000 On Tue, Apr 16, 2019, at 18:36, Erik Sy wrote: > Hi Martin, > > can you please explain, why you think this is not the right solution? To recap, the draft proposes an empty extension in ClientHello, which the server, at its discretion, includes in Certificate. There are two insights that are important here: 1. The client could, if it chose, send any session ticket from any server to any other server[1]. The reasons for not doing that are primarily linkability: by using a session ticket it links the connection where it is used with the connection where it was acquired. 2. The linkability thing means that clients can't reuse session tickets because that changes the set of entities that can link sessions from (issuer+consumer) to (issuer+consumer+network path). This is what leads us to strongly recommend using tickets at most once. The second observation is what drives the signal. We want to have a signal so that the client can make the resumption attempt without wasting the ticket on a server that simply cannot use it. I think that the signal could be attached to NewSessionTicket instead: The server MAY also send unsolicited extensions in the NewSessionTicket, though the client does not respond directly to these. [1] What it means to resume with a completely different server identity, where the client has seen no previous authentication, is a separable question. And I don't think that the current draft goes far enough to address this complex question. It currently says: This resumption group is formed of all SNI values that are valid for the presented server certificate. That is convenient and probably ultimately a good baseline for this, but it doesn't capture some of the things we learned about the scope of server authority out of HTTP/2 and the ensuing work. I think that this needs to transition - at least conceptually - into the application layer and rely on the client's understanding of what identities the server holds. I'm OK with adoption without addressing that concern, but it does need to be addressed. Finally, there is some text in the draft that I think needs to be removed. For example, the normative text on cache lifetime here: According to [RFC8446], clients MUST NOT cache tickets longer than seven days. Note, that TLS resumption enables a server to link resumed connections to the same client. A study on the feasibility of this tracking mechanism can be found in [TRAC]. To protect the client's privacy against tracking via this mechanism, it is RECOMMENDED to cache resumption tickets only for ten minutes. ...or this: To optimize the performance benefit of this extension, the server's certificate is RECOMMENDED to only include SNI values that mutually support the resumption of their TLS connections. There's enough there that I think that another iteration would be wise before adoption, that's all. From nobody Wed Apr 24 00:43: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 730441200A4 for ; Wed, 24 Apr 2019 00:43: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, RCVD_IN_DNSWL_NONE=-0.0001, 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 (2048-bit key) header.d=ncsc.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGtyTD3aEw-Z for ; Wed, 24 Apr 2019 00:43:17 -0700 (PDT) Received: from min1.ncsc.nl (min1.ncsc.nl [147.181.97.77]) (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 292AC12006F for ; Wed, 24 Apr 2019 00:43:17 -0700 (PDT) Received: from mailer DKIM-Filter: OpenDKIM Filter v2.11.0 min1.ncsc.nl 724F2E0003 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncsc.nl; s=ncsc201806; t=1556091795; bh=PmwiESx072pFmxQ1sfS0WXFLgNVaOTMrftz5IvJlwWU=; h=Subject:To:References:From:Date:In-Reply-To:From; b=axfM0S2Yh3mvp8lkngTP1a3UFIvpIEEFggEstiV5gqMyQ+006oNe/7T6adDnmwqlA gXECfbgGgktqLqzXOXmtTVZ34c1ut3ZE3sNSZyuUQIqUXDYYPcEvAIgzI886Yvv/4J 5z00Kz+ndY90EFUwYCC/S7+pFG+k/q8NYrlZXKwCMGPagg5xR5T4TQmC7nHli4479K fUOr53Nl3ewSExmqyjfkB0dtRFD363BTGXL3M4TSpNJdClBABSk9VvSz0PfdFqy3kZ 6Yras1CRg/lqBcGroe9dQsNpkI47fznvBwb/8aEk0DyQ2jYQOqvi19LHZ4//rcsbMd oGLLYOFLmAI8g== Received: from mailer To: References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> From: "Maarten Aertsen (NCSC-NL)" Message-ID: <5c4ff718-e063-4799-507c-04e38a47f83f@ncsc.nl> Date: Wed, 24 Apr 2019 09:42:58 +0200 MIME-Version: 1.0 In-Reply-To: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit 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: Wed, 24 Apr 2019 07:43:20 -0000 Hi, On 13-4-2019 01:28, Christopher Wood wrote: > This is the working group last call for the "Deprecating TLSv1.0 and TLSv1.1” draft available at: > > https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/ > > Please review the document and send your comments to the list by April 26, 2019. I'd like to see this published. @Kathleen, Stephen: in case there's any value in an additional ref for section 2, we published updated TLS-guidelines yesterday, with clear advice to phase out TLSv1, TLSv1.1. https://www.ncsc.nl/english/current-topics/news/future-proof-tls-configuration-using-the-updated-tls-guidelines-from-ncsc.html kind regards, Maarten From nobody Wed Apr 24 01:45: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 2A31F120230 for ; Wed, 24 Apr 2019 01:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 rMYIkLD5RnKy for ; Wed, 24 Apr 2019 01:45:28 -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 322021200A4 for ; Wed, 24 Apr 2019 01:45:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 83263BED5; Wed, 24 Apr 2019 09:45:16 +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 vgUo_c8EFXss; Wed, 24 Apr 2019 09:45:11 +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 C7B2CBE20; Wed, 24 Apr 2019 09:45:10 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1556095511; bh=KWv24plueePXRKsd0XCDmqCAi4ghc3k5v29VKwpVnZ0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=pf5/LCQlbBMzfmfmRZO/pIQuqvnE8ysG4PlFOYP/CijoxtCPsiFgVLjjhjp6/ReBx BlgUuKPK7uIm9K0dEzv7ddVYAHnHCoNReOB8uYJC1g0KPWZ08SP6AWzbvIVhvI9hd/ Rhts+PowIP/S8e5Jx7MK9+cGhSW8v0IBGVGs2IF8= To: "Maarten Aertsen (NCSC-NL)" , tls@ietf.org References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <5c4ff718-e063-4799-507c-04e38a47f83f@ncsc.nl> 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: <0d330eec-3579-1aae-5582-2482512eda4d@cs.tcd.ie> Date: Wed, 24 Apr 2019 09:44:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <5c4ff718-e063-4799-507c-04e38a47f83f@ncsc.nl> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="4iX9fcazmcWSG3XNMHJclO15r1UitPJYM" 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: Wed, 24 Apr 2019 08:45:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4iX9fcazmcWSG3XNMHJclO15r1UitPJYM Content-Type: multipart/mixed; boundary="aJOyfOQzEtIYUaj6D9Zc3gsLoajj43paM"; protected-headers="v1" From: Stephen Farrell To: "Maarten Aertsen (NCSC-NL)" , tls@ietf.org Message-ID: <0d330eec-3579-1aae-5582-2482512eda4d@cs.tcd.ie> Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <5c4ff718-e063-4799-507c-04e38a47f83f@ncsc.nl> In-Reply-To: <5c4ff718-e063-4799-507c-04e38a47f83f@ncsc.nl> --aJOyfOQzEtIYUaj6D9Zc3gsLoajj43paM Content-Type: multipart/mixed; boundary="------------16A0FE80951DECED095626A0" Content-Language: en-GB This is a multi-part message in MIME format. --------------16A0FE80951DECED095626A0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 24/04/2019 08:42, Maarten Aertsen (NCSC-NL) wrote: > Hi, >=20 > On 13-4-2019 01:28, Christopher Wood wrote: >> This is the working group last call for the "Deprecating TLSv1.0 and >> TLSv1.1=E2=80=9D draft available at: >> >> =C2=A0=C2=A0=C2=A0=C2=A0 >> https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/= >> >> Please review the document and send your comments to the list by April= >> 26, 2019. >=20 > I'd like to see this published. >=20 > @Kathleen, Stephen: in case there's any value in an additional ref for > section 2, we published updated TLS-guidelines yesterday, with clear > advice to phase out TLSv1, TLSv1.1. >=20 > https://www.ncsc.nl/english/current-topics/news/future-proof-tls-config= uration-using-the-updated-tls-guidelines-from-ncsc.html >=20 Thanks. Will take a peek when I go over the LC comments (most likely over the w/e). Funnily enough, the substantive LC comments so far as I recall 'em are all from folks named Martin/Maarten - any other similarly named folks out there with a comment? :-) Cheers, S. >=20 > kind regards, Maarten >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --------------16A0FE80951DECED095626A0 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----- --------------16A0FE80951DECED095626A0-- --aJOyfOQzEtIYUaj6D9Zc3gsLoajj43paM-- --4iX9fcazmcWSG3XNMHJclO15r1UitPJYM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlzAIgkACgkQWrL68XsX K+rEbBAApcdfIm2kU/qwZJVUSET8UuyfY1XuLSnTaR7hNgS9uccMF494jWe0Rh7Z VqM22VNgJJnX/QgmK291z7jYpzKng+44m4XHJzWCJ4PJrf7FVTPUooXDuEbYnjGw x21nHiMWpfzbOwrYU1w+UC57APw5vTGzIl8ffEExIJOT/LJNGLA+AlNhbhZRO7Sm oxZ3p1lqF2HNZJAHX2CsfRo7qkS+5UTcp8hd5pgIFwWFYBWOt1r8P/Dzpud5aSia hWK7gvxU1coTcQFg43XV6qg8Bp+Gu+paN8oD3+UkUqZEWqugXp2VYQYl+NBzVpMB O9o//nSlzA4aK8rEY+/Y6jtzuQfrCBOG6Ki8FJaKOTyXqp16P1X1H6g+vCjylMbB X8vg6aZcmAqE4FIekGolxXO2B+Wmcmq8cxc6b/pEacsh17Xy0wMMmsd+mWUC4L4F W4wD0YWLNjq9eOMnnKUUIuJ0PElRzSLeV4VKUdUKd1RbFQu+kCbgXVoIF8EA7AVN NyjiBguvl85uxrx80o1GWSJCffplGqiqImittsBULx47O8Oftet6pD3j6kshvI5P q2Rde7PgSeytv9VpFhr3mEpyRYAiWujuuylPYF7qqWYnldDSYBUGDpDaCVuqBqjA jI14hZTtfHPMVqH7UzRzVHFWtPlJvX6gs7iy7E6FbWk1+B4gy6E= =ejQs -----END PGP SIGNATURE----- --4iX9fcazmcWSG3XNMHJclO15r1UitPJYM-- From nobody Wed Apr 24 06:51: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 4E1C212015F for ; Wed, 24 Apr 2019 06:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.176 X-Spam-Level: X-Spam-Status: No, score=-1.176 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 Nn32rqKW1dIq for ; Wed, 24 Apr 2019 06:51:34 -0700 (PDT) Received: from server276.com (server276.com [192.252.144.26]) (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 E764F120020 for ; Wed, 24 Apr 2019 06:51:33 -0700 (PDT) Received: (qmail 29970 invoked by uid 503); 24 Apr 2019 13:51:30 -0000 Received: from unknown (HELO nuc7i7bnh.650ncr.com) (gary@garygapinski.com@66.119.109.100) by server276.com with ESMTPA; 24 Apr 2019 13:51:30 -0000 To: tls@ietf.org References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> From: Gary Gapinski Message-ID: <7f76d36c-962b-78fe-87ab-e17c31430cb3@garygapinski.com> Date: Wed, 24 Apr 2019 09:51:28 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> Content-Type: text/html; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit 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: Wed, 24 Apr 2019 13:51:35 -0000
On 4/12/19 7:28 PM, Christopher Wood wrote:
This is the working group last call for the "Deprecating TLSv1.0 and TLSv1.1” draft available at:

    https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/

Please review the document and send your comments to the list by April 26, 2019.

I think the document should be published.

I agree with Martin Thomson's observation that the SP 800-52r2 quotes in Section 2 are a bit prolix considering the relatively small content that would remain if excised, and that NIST document has been in draft for a prolonged time (reducing its authority). The quotes imply but do not demand disuse of TLS 1.0 and TLS 1.1, and could inadvertently be interpreted to mean that use of TLS 1.2 rather than TLS 1.3 is sinful.

An additional (congenial) informative reference could be BSI TR-02102-2 found at

https://www.bsi.bund.de/EN/Publications/TechnicalGuidelines/tr02102/index_htm.html

which in §3.2 states "TLS 1.0 and TLS 1.1 are not recommended".

Regards,

Gary

From nobody Wed Apr 24 07:18: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 74ABA120338 for ; Wed, 24 Apr 2019 07:17:52 -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_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 YCaJvegYVBU6 for ; Wed, 24 Apr 2019 07:17:49 -0700 (PDT) Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0: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 9C43E12033F for ; Wed, 24 Apr 2019 07:17:49 -0700 (PDT) Received: by mail-oi1-x22b.google.com with SMTP id v7so14395136oie.8 for ; Wed, 24 Apr 2019 07:17:49 -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=0P3J98tBdn7HC8eFJ+UUjkY9dpFub/S9KhG54h8NGWo=; b=G+HwZBlTBB8F86waB97JTw+yAKnAQBTFw/wreKOfqJwP+zkDxhvNQlJzXkM0LhmcH4 1/U5PHkFtDbJeaFUoQkXquF9G5CKaxQxNaDjbjwfqd7pAqeoWsrlbJFvzeGrudTZVK+6 j4BBFGB0HDhStAulUDpuJi8XYYUhfRrXzs/kdZt9eC2Sc5XL4hlI7m28AwR+/2RC8PoN 5gZ+0Np9BkqPXB3TsTZlHLf0sy3HRFg4HdPkTTEwTq1hb2OboZMUD4jRYRX54SjW9kMf aIzCYLJpCsLEOSzFamqAAALlDNd49lWqwOpZO3f/C4Gqu+wB2x8xjsqvoLu7Obz+PFC+ iACw== 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=0P3J98tBdn7HC8eFJ+UUjkY9dpFub/S9KhG54h8NGWo=; b=PBwgJ7vFa6XMxVcnui/EMxUifAlx/n9hGwIHStTJei3vFlEvmS6uIU+JlOjt1040+H OZvFYhqbmuTgY3a4deNyXGdQiNJ0yU6t5XZFLUjmsOsTh9BcYrcAaX5IxSviJ9uc3NJW mftVjDa0NaBf5dGuhFrffeymUzxap3UoQD8El+0zt65s1YR6oarJzHKhViVRG1zbHsuV BjRfFIV6m1Ej073UK+LL4ESG/dt4HlCyngyz17JDBGM0nQBwVWx3btyAjjqDDgCXBgNf bIiv6YcCz5AnY4cUge0xH5fuufFq6QrHCV/xJ6rZm2CTxwnXZKz4oBjjR09HOBhGGXID RmyQ== X-Gm-Message-State: APjAAAWi728/KvgIaaEWFJWwXGlEJ4jObyRiJuR+H2JUd3itDRqkZqVk UMCvKDiVdd2tbAnlzNg2Or3gT2kFs+UeXPwveFAy6o0Q X-Google-Smtp-Source: APXvYqzcu072hdamjwQeJ+wJTed2OxnMqlKNYST/2N4UfRPYmZJ6LPvIsZC9ZJyLFovb7BwTyERQPu+rm8DEAVaKNrs= X-Received: by 2002:aca:b156:: with SMTP id a83mr4792995oif.119.1556115468652; Wed, 24 Apr 2019 07:17:48 -0700 (PDT) MIME-Version: 1.0 References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <7f76d36c-962b-78fe-87ab-e17c31430cb3@garygapinski.com> In-Reply-To: <7f76d36c-962b-78fe-87ab-e17c31430cb3@garygapinski.com> From: Kathleen Moriarty Date: Wed, 24 Apr 2019 10:17:11 -0400 Message-ID: To: Gary Gapinski Cc: "" Content-Type: multipart/alternative; boundary="000000000000bd17150587475db2" 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: Wed, 24 Apr 2019 14:17:59 -0000 --000000000000bd17150587475db2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks, Gary and others for the helpful feedback and support! I like Stephen can look at integrating the suggestions this weekend/early next week. Please do keep the comments coming. Best regards, Kathleen On Wed, Apr 24, 2019 at 9:51 AM Gary Gapinski wrote: > On 4/12/19 7:28 PM, Christopher Wood wrote: > > This is the working group last call for the "Deprecating TLSv1.0 and TLSv= 1.1=E2=80=9D draft available at: > > https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate= / > > Please review the document and send your comments to the list by April 26= , 2019. > > I think the document should be published. > > I agree with Martin Thomson's observation that the SP 800-52r2 quotes in > Section 2 are a bit prolix considering the relatively small content that > would remain if excised, and that NIST document has been in draft for a > prolonged time (reducing its authority). The quotes imply but do not dema= nd > disuse of TLS 1.0 and TLS 1.1, and could inadvertently be interpreted to > mean that use of TLS 1.2 rather than TLS 1.3 is sinful. > > An additional (congenial) informative reference could be BSI TR-02102-2 > found at > > > https://www.bsi.bund.de/EN/Publications/TechnicalGuidelines/tr02102/index= _htm.html > > which in =C2=A73.2 states "TLS 1.0 and TLS 1.1 are *not recommended*". > > Regards, > > Gary > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --=20 Best regards, Kathleen --000000000000bd17150587475db2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks, Gary and others for the helpful feedback and suppo= rt!=C2=A0 I like Stephen can look at integrating the suggestions this weeke= nd/early next week.=C2=A0 Please do keep the comments coming.

Best regards,
Kathleen

On Wed, Apr 24, 2019 at 9:51 AM= Gary Gapinski <gary=3D40garygapinski.com@dmarc.ietf.org> wrote:
=20 =20 =20
On 4/12/19 7:= 28 PM, Christopher Wood wrote:
This is the w=
orking group last call for the "Deprecating TLSv1.0 and TLSv1.1=E2=80=
=9D draft available at:

    https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-d=
eprecate/

Please review the document and send your comments to the list by April 26, =
2019.

I think the document should be published.

I agree with Martin Thomson's observation that the SP 800-52r2 quotes in Section 2 are a bit prolix considering the relatively small content that would remain if excised, and that NIST document has been in draft for a prolonged time (reducing its authority). The quotes imply but do not demand disuse of TLS 1.0 and TLS 1.1, and could inadvertently be interpreted to mean that use of TLS 1.2 rather than TLS 1.3 is sinful.

An additional (congenial) informative reference could be BSI TR-02102-2 found at

https://www.bsi.bund.de/EN/Pub= lications/TechnicalGuidelines/tr02102/index_htm.html

which in =C2=A73.2 states "TLS 1.0 and TLS 1.1 are not recom= mended".

Regards,

Gary

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


--

Best regards,
Kathleen
--000000000000bd17150587475db2-- From nobody Thu Apr 25 09:16: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 8ECE5120048 for ; Thu, 25 Apr 2019 09:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 l7FfC-xgJF0j for ; Thu, 25 Apr 2019 09:16:47 -0700 (PDT) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C27701201A4 for ; Thu, 25 Apr 2019 09:16:47 -0700 (PDT) Received: by mail-qt1-x82e.google.com with SMTP id c35so753068qtk.3 for ; Thu, 25 Apr 2019 09:16:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=DPStQO8KvK46ka9ktrnhpysNtjXNUZCodfttOMz5/wM=; b=lZIuKRXEGGNxX66HloifR5D/nbh27C5L3CL80/iaXBrDuZSXAVHTp2Wjs1LYOx2+Ly 4kp5xT79U3QhOW/cWYsUacOsKqkpBdHp/lruxVg37i4sLDiwq0XlbZPSmyXcQAhcqaoZ AVMybSux7xIHx36otY7vk4x076v21Mt1rzYc8= 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=DPStQO8KvK46ka9ktrnhpysNtjXNUZCodfttOMz5/wM=; b=XoTWvEn2hLGhcV5Y4jl4p6gWs6biaBvVANmjon8jmUIAIzvRzEq7T7Bq3mJFJgJFoX YCUtqBgWHyEKZHrp0SMk3T1r7fmwxrET/KIj1CGykCAZpoauzl4iyv72F+dvgpxAMGzR BOtyXCmyWMh1EwhpIAHksWi/Z/0qPYDiZvsiL7ovJMJPyTvD6CH83IAFfzyf6/B808UD 00XWVuCbWDKpbJbFgZsvP7Hrax7Z3UxbSYkeiH1lS7Tqh4yi0uMIhtn73qIDAdeNfgAS G0FXJFBmEQEyUM9Vs74xUm+KzankN2IfViPYubr98T+6R8bo2yTJYyQbk+ZTTOQDl0Rc euJQ== X-Gm-Message-State: APjAAAVvC18FabSlp3DZPdAAb4RJygXW1FgqBhgg7ipO28nDpkxEnaJn Mfa1vPejbBVD769HGBW38kNnQgmvKDk= X-Google-Smtp-Source: APXvYqwKdlHnKKAXtx5iWn9J7Y9hfGSlY6BJYcWQZQL85AP2e3N5UABwzekzK61AXfSpyor95NaVDQ== X-Received: by 2002:ac8:3971:: with SMTP id t46mr679673qtb.84.1556209006481; Thu, 25 Apr 2019 09:16:46 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.36]) by smtp.gmail.com with ESMTPSA id 25sm16159928qtw.70.2019.04.25.09.16.45 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Apr 2019 09:16:45 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Thu, 25 Apr 2019 12:16:44 -0400 References: To: TLS List In-Reply-To: Message-Id: <2BE383C5-6A00-4B94-8BC9-15EBE4308A62@sn3rd.com> X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-certificate-compression 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, 25 Apr 2019 16:16:50 -0000 The WGLC for draft-ietf-tls-certificate-compression ended on 22 April = 2019 We will be working on the shepherd write-up and forwarding it to = our AD shortly. If you have any last minute comments please get them in = ASAP. Cheers, Chris, Joe, and Sean > On Apr 8, 2019, at 20:52, Sean Turner wrote: >=20 > This is the working group last call for the "TLS Certificate = Compression=E2=80=9D draft > available at = https://datatracker.ietf.org/doc/draft-ietf-tls-certificate-compression/. > Please review the document and send your comments to the list by 2359 = UTC > on 22 April 2019. >=20 > Issue and PRs can also be filed in the GH repo for this draft, which = can be > found here: https://github.com/tlswg/certificate-compression >=20 > Thanks, > Chris, Joe, and Sean From nobody Thu Apr 25 18:30: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 8AC391200A1 for ; Thu, 25 Apr 2019 18:30:06 -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_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 TCb9OeI1BOpD for ; Thu, 25 Apr 2019 18:30:03 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6BF0120086 for ; Thu, 25 Apr 2019 18:30:03 -0700 (PDT) Received: from [10.200.0.109] (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id 8DF832AF5C8 for ; Thu, 25 Apr 2019 21:30:01 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Viktor Dukhovni In-Reply-To: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> Date: Thu, 25 Apr 2019 21:30:00 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: IETF TLS WG Message-Id: <2EF7433E-DB94-497F-80D7-2A060097261B@dukhovni.org> References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> To: IETF TLS WG X-Mailer: Apple Mail (2.3445.104.8) 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, 26 Apr 2019 01:30:07 -0000 > On Apr 12, 2019, at 7:28 PM, Christopher Wood = wrote: >=20 > This is the working group last call for the "Deprecating TLSv1.0 and = TLSv1.1=E2=80=9D draft available at: >=20 > = https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/ >=20 > Please review the document and send your comments to the list by April = 26, 2019. My concern is whether the time is yet nigh for TLS 1.0 to be disabled in opportunistic TLS in SMTP, or whether TLS 1.0 remains sufficiently common to cause deprecation to do more harm than good via unnecessary downgrades to cleartext. I don't have survey numbers for SMTP TLS protocol versions across MTAs generally to shed light on this, perhaps someone does. What I do have is numbers for those MTAs (not a representative sample) that have DANE TLSA records (so presumably a greater focus on security). The observed version frequencies are approximately: TLS 1.0: 1% TLS 1.1: 0% TLS 1.2: 87% TLS 1.3: 12% essentially regardless of whether I deduplicate by name, IP or name and = IP. The respective sample sizes are 5435, 6938 and 7959. So if a DANE-enabled sender were to disable TLS 1.0 today, approximately 1% of the destination MX hosts would be broken and need remediation. = These handle just of 189 mostly small SOHO domains out of the ~1.1 million = total DANE SMTP domains, but four handle enough email to show up on the Gmail SMTP transparency report: tu-darmstadt.de t-2.net t-2.com t-2.si So on the whole, the draft should proceed, but some caution may be = appropriate outside the browser space, before operators start switching off TLS 1.0 = support. I don't see an operational considerations section. Nor much discussion = of "less mainstream" (than Web browser) TLS application protocols. Would a = few words of caution be appropriate, or is it expected that by the time the = RFC starts to change operator behaviour the "market share" of TLS 1.0 will = be substantially lower than I see today even with SMTP, XMPP, NTTP and the = like. [ I would speculate that TLS 1.0's share is noticeably higher among MTAs generally than among the bleeding-edge MTAs that have published DANE = TLSA RRs. ] --=20 Viktor. From nobody Thu Apr 25 18:48: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 9F9CB1200A0 for ; Thu, 25 Apr 2019 18:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 VHV4qX0MxFzq for ; Thu, 25 Apr 2019 18:48:34 -0700 (PDT) Received: from mail-lj1-f170.google.com (mail-lj1-f170.google.com [209.85.208.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2CD31200BA for ; Thu, 25 Apr 2019 18:48:33 -0700 (PDT) Received: by mail-lj1-f170.google.com with SMTP id f23so1437224ljc.0 for ; Thu, 25 Apr 2019 18:48:33 -0700 (PDT) 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=Lm1nVKcf1THa0auuij9ooh4Psi+wIew32IgFw8P5+aQ=; b=VbYV2rdparn8eF9VlgcLElmsYwP+Wh8FIRiE8GEsVamCVU5IWOJz3PmeTyQYvYVwU2 fDivl89OMZYHqKUb/Iafd96j7MWOWCnytyEfRuF540Mz1eiJSmyiPg/zO0IE0fAnMrZ7 1cx3DTSzgmLMG/7MHnIjsgIny8hsx3aHIKGYk/SM52box6OPoxbXp2PqCOaRNCRnvt8t IcyCQ3EbwlLz03KHNYOp5kkdSyC4nDAoA4ji1fcIhpV6hSxbzgwsndjoSD2EC/KxSIwM yOhMjP4sDH4k+PEmn/UIWVhIqMLGVCG0+fL1hDosDpKFGR1SE/EZNXSOw0SLqHR0HKMj Cg9A== X-Gm-Message-State: APjAAAUs2u/Zw9f0WgrBpRLvqzBHND1Mgn8DPN3L/k6y9u6tA48hwc5o xLCbtLKY/kcsMkn7FdARuex/VPtX99Fwz/e6jW8m7w== X-Google-Smtp-Source: APXvYqzavzjUrrF9EPLQ5m6YaktyvmDF0X2//3x+5+oXIaajPeE+l4KJqU4uKeGDP9J8Bu1jVmM4Nm2YBawrEttN1d0= X-Received: by 2002:a2e:9e03:: with SMTP id e3mr830653ljk.180.1556243311638; Thu, 25 Apr 2019 18:48:31 -0700 (PDT) MIME-Version: 1.0 References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <2EF7433E-DB94-497F-80D7-2A060097261B@dukhovni.org> In-Reply-To: <2EF7433E-DB94-497F-80D7-2A060097261B@dukhovni.org> From: Daniel Migault Date: Thu, 25 Apr 2019 21:48:20 -0400 Message-ID: To: IETF TLS WG Content-Type: multipart/alternative; boundary="000000000000c63ea80587652111" 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, 26 Apr 2019 01:48:37 -0000 --000000000000c63ea80587652111 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I believe the doc is fine as it is. Yours, Daniel On Thu, Apr 25, 2019 at 9:30 PM Viktor Dukhovni wrote: > > On Apr 12, 2019, at 7:28 PM, Christopher Wood > wrote: > > > > This is the working group last call for the "Deprecating TLSv1.0 and > TLSv1.1=E2=80=9D draft available at: > > > > > https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/ > > > > Please review the document and send your comments to the list by April > 26, 2019. > > My concern is whether the time is yet nigh for TLS 1.0 to be disabled > in opportunistic TLS in SMTP, or whether TLS 1.0 remains sufficiently > common to cause deprecation to do more harm than good via unnecessary > downgrades to cleartext. > > I don't have survey numbers for SMTP TLS protocol versions across MTAs > generally to shed light on this, perhaps someone does. What I do have > is numbers for those MTAs (not a representative sample) that have DANE > TLSA records (so presumably a greater focus on security). > > The observed version frequencies are approximately: > > TLS 1.0: 1% > TLS 1.1: 0% > TLS 1.2: 87% > TLS 1.3: 12% > > essentially regardless of whether I deduplicate by name, IP or name and I= P. > The respective sample sizes are 5435, 6938 and 7959. > > So if a DANE-enabled sender were to disable TLS 1.0 today, approximately > 1% of the destination MX hosts would be broken and need remediation. The= se > handle just of 189 mostly small SOHO domains out of the ~1.1 million tota= l > DANE SMTP domains, but four handle enough email to show up on the Gmail > SMTP transparency report: > > tu-darmstadt.de > t-2.net > t-2.com > t-2.si > > So on the whole, the draft should proceed, but some caution may be > appropriate > outside the browser space, before operators start switching off TLS 1.0 > support. > > I don't see an operational considerations section. Nor much discussion o= f > "less mainstream" (than Web browser) TLS application protocols. Would a > few > words of caution be appropriate, or is it expected that by the time the R= FC > starts to change operator behaviour the "market share" of TLS 1.0 will be > substantially lower than I see today even with SMTP, XMPP, NTTP and the > like. > > [ I would speculate that TLS 1.0's share is noticeably higher among MTAs > generally than among the bleeding-edge MTAs that have published DANE TL= SA > RRs. ] > > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000c63ea80587652111 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I believe the doc is fine as it is.=C2=A0
Yours,=C2=A0=
Daniel

On Thu, Apr 25, 2019 at 9:30 PM Viktor Dukhovni <= ietf-dane@dukhovni.org> wr= ote:
> On Apr= 12, 2019, at 7:28 PM, Christopher Wood <caw@heapingbits.net> wrote:
>
> This is the working group last call for the "Deprecating TLSv1.0 = and TLSv1.1=E2=80=9D draft available at:
>
>=C2=A0 =C2=A0 https://data= tracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/
>
> Please review the document and send your comments to the list by April= 26, 2019.

My concern is whether the time is yet nigh for TLS 1.0 to be disabled
in opportunistic TLS in SMTP, or whether TLS 1.0 remains sufficiently
common to cause deprecation to do more harm than good via unnecessary
downgrades to cleartext.

I don't have survey numbers for SMTP TLS protocol versions across MTAs<= br> generally to shed light on this, perhaps someone does.=C2=A0 What I do have=
is numbers for those MTAs (not a representative sample) that have DANE
TLSA records (so presumably a greater focus on security).

The observed version frequencies are approximately:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 TLS 1.0:=C2=A0 1%
=C2=A0 =C2=A0 =C2=A0 =C2=A0 TLS 1.1:=C2=A0 0%
=C2=A0 =C2=A0 =C2=A0 =C2=A0 TLS 1.2: 87%
=C2=A0 =C2=A0 =C2=A0 =C2=A0 TLS 1.3: 12%

essentially regardless of whether I deduplicate by name, IP or name and IP.=
The respective sample sizes are 5435, 6938 and 7959.

So if a DANE-enabled sender were to disable TLS 1.0 today, approximately 1% of the destination MX hosts would be broken and need remediation.=C2=A0 = These
handle just of 189 mostly small SOHO domains out of the ~1.1 million total<= br> DANE SMTP domains, but four handle enough email to show up on the Gmail
SMTP transparency report:

=C2=A0 tu-darmstadt.de
=C2=A0 t-2.= net
=C2=A0 t-2.= com
=C2=A0 t-2.s= i

So on the whole, the draft should proceed, but some caution may be appropri= ate
outside the browser space, before operators start switching off TLS 1.0 sup= port.

I don't see an operational considerations section.=C2=A0 Nor much discu= ssion of
"less mainstream" (than Web browser) TLS application protocols.= =C2=A0 Would a few
words of caution be appropriate, or is it expected that by the time the RFC=
starts to change operator behaviour the "market share" of TLS 1.0= will be
substantially lower than I see today even with SMTP, XMPP, NTTP and the lik= e.

[ I would speculate that TLS 1.0's share is noticeably higher among MTA= s
=C2=A0 generally than among the bleeding-edge MTAs that have published DANE= TLSA
=C2=A0 RRs. ]

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

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000c63ea80587652111-- From nobody Thu Apr 25 23:25: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 612B612016C for ; Thu, 25 Apr 2019 23:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 (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 Fjs4bn25-GrR for ; Thu, 25 Apr 2019 23:16:19 -0700 (PDT) Received: from mail-it1-x129.google.com (mail-it1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 963C81202A3 for ; Thu, 25 Apr 2019 23:16:18 -0700 (PDT) Received: by mail-it1-x129.google.com with SMTP id v8so3810142itf.0 for ; Thu, 25 Apr 2019 23:16:18 -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=wO5NSm7M1ZRnx0PFSnw5bzB4cJ1rmkFZhGM8MvtPxvU=; b=YX25mQEphxqTPKkmPGuQdoWK53d2wk/H2tMyuk5Mzb50zY2SwwbeKXZlYnWULASXw0 S2IuSpVNGPSUnrd2NJKfpHBZyTQwX0RK7M7/Ww0hkHAl8nevlGt4oczhktNrLnD31DVg j8RUrskm2m7/MIcRgVc1GFPu2Sz+87Z1DJ2sZvdklm5aqQwbO8ep2e/EBuO0qy1j1/iU IzHmeyI8gTBgoCgLhgEfK7Vt3FG0tlNp7hJ/0kZTCXQvFaLXVytcLlg8GapTM3nTp+zL NULvVvWKfI2EljQ5xDup32ymFJNXml8nudXcxWAPGisETp49izlW9Bo5wc0Fmf50awsi hdLg== 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=wO5NSm7M1ZRnx0PFSnw5bzB4cJ1rmkFZhGM8MvtPxvU=; b=htC6sGsOcv2s1/kyo6rszbtahW5MYCbSQMTfnjkwkEexhgL87lMBF/Rzp7ej8qxkEl fUrSKBvgUpTWDM5916xHtVD3v/u+31xm8KW5FYgbaRZ75h5P4W83HT5ELUyllHaG/0M5 Ys8gPk40sAJATXSyv2fJykDFX6KTVnrsQJa/uJ2GQTiQCIYCIT3LnGhFLO8JI7RgZnXr +Tdh2wKRntmOEEyPdVj/4nv/3xZMAhhfko2bCAg1TrwaYYQPyBSqe9aJG30J8Scffrpb TxqWhDuzJuOCfSbDm6X8z+pZP5k4EEZJUvKZ1aaXW6S5HXNmTLjygRGLj7XsyaAXpGB3 m64g== X-Gm-Message-State: APjAAAVsLPXJbJglq5mC2PLd575gX5QFASnQ9PPL1nye3x1zC5O3PbHQ dUW5DMXTicM3oGWf+Hue2US8yEHmv/dXHK5cwNU= X-Google-Smtp-Source: APXvYqy9f6RTJkh/54o24oUt3/eMZXxFDkVYZ4x3iZUTxNFbMbDHrb8RsSOBrBdZhoXwZ2KAD3+tGt+o4EpW16fhzGU= X-Received: by 2002:a24:424c:: with SMTP id i73mr7160538itb.91.1556259377889; Thu, 25 Apr 2019 23:16:17 -0700 (PDT) MIME-Version: 1.0 References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <2EF7433E-DB94-497F-80D7-2A060097261B@dukhovni.org> In-Reply-To: From: Loganaden Velvindron Date: Fri, 26 Apr 2019 10:16:06 +0400 Message-ID: To: Daniel Migault Cc: IETF TLS WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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, 26 Apr 2019 06:16:22 -0000 I also believe that it's ready. On Fri, Apr 26, 2019 at 5:49 AM Daniel Migault wrote: > > I believe the doc is fine as it is. > Yours, > Daniel > > On Thu, Apr 25, 2019 at 9:30 PM Viktor Dukhovni = wrote: >> >> > On Apr 12, 2019, at 7:28 PM, Christopher Wood wr= ote: >> > >> > This is the working group last call for the "Deprecating TLSv1.0 and T= LSv1.1=E2=80=9D draft available at: >> > >> > https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-depreca= te/ >> > >> > Please review the document and send your comments to the list by April= 26, 2019. >> >> My concern is whether the time is yet nigh for TLS 1.0 to be disabled >> in opportunistic TLS in SMTP, or whether TLS 1.0 remains sufficiently >> common to cause deprecation to do more harm than good via unnecessary >> downgrades to cleartext. >> >> I don't have survey numbers for SMTP TLS protocol versions across MTAs >> generally to shed light on this, perhaps someone does. What I do have >> is numbers for those MTAs (not a representative sample) that have DANE >> TLSA records (so presumably a greater focus on security). >> >> The observed version frequencies are approximately: >> >> TLS 1.0: 1% >> TLS 1.1: 0% >> TLS 1.2: 87% >> TLS 1.3: 12% >> >> essentially regardless of whether I deduplicate by name, IP or name and = IP. >> The respective sample sizes are 5435, 6938 and 7959. >> >> So if a DANE-enabled sender were to disable TLS 1.0 today, approximately >> 1% of the destination MX hosts would be broken and need remediation. Th= ese >> handle just of 189 mostly small SOHO domains out of the ~1.1 million tot= al >> DANE SMTP domains, but four handle enough email to show up on the Gmail >> SMTP transparency report: >> >> tu-darmstadt.de >> t-2.net >> t-2.com >> t-2.si >> >> So on the whole, the draft should proceed, but some caution may be appro= priate >> outside the browser space, before operators start switching off TLS 1.0 = support. >> >> I don't see an operational considerations section. Nor much discussion = of >> "less mainstream" (than Web browser) TLS application protocols. Would a= few >> words of caution be appropriate, or is it expected that by the time the = RFC >> starts to change operator behaviour the "market share" of TLS 1.0 will b= e >> substantially lower than I see today even with SMTP, XMPP, NTTP and the = like. >> >> [ I would speculate that TLS 1.0's share is noticeably higher among MTAs >> generally than among the bleeding-edge MTAs that have published DANE T= LSA >> RRs. ] >> >> -- >> Viktor. >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu Apr 25 23:46:07 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 1A3C01200BA for ; Thu, 25 Apr 2019 23:46:06 -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_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 xT4dO9Eqy3CT for ; Thu, 25 Apr 2019 23:46:04 -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 8ED15120106 for ; Thu, 25 Apr 2019 23:46:03 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id y6so1841738ljd.12 for ; Thu, 25 Apr 2019 23:46:03 -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=qPa6qA4zSYe27l+e/Q99MUqesoMLEJ6q5wCvGD2rzXY=; b=qfHfVFAj4T1WYDlscwUxsqGiYzkHGqevZ398NQ0QY1GtFd36WfMBZrFPAHl7ek7GYO qrBaFU/o+LUeJRp0Ic1+3fQwcztjcPZl6z9XnKqF0xKG82leXKpvLnujkMyW43mJsV57 vHR0r94F4a85KeQ28MTs3lhzmX2zZFY7Bs4/vd0umSYMaSiW5gKL9XPQxBMD+G7KDroy GZzspUFVnchpWfAzxoOqd2E+OGP1gsQXg3yvesIllU044Jibamjs9hmrq37o4vimoEos r6F+U6dtPlFsaKZ7oKrTONCw3/4R8PRDWPAl4NuVsDa+vYlZ7tqttsalE/+KIUU32zg6 pvCg== 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=qPa6qA4zSYe27l+e/Q99MUqesoMLEJ6q5wCvGD2rzXY=; b=kHjxHyBDldjoYuDhn7mlVFKQRKRQ4R/rT//8PVBU/rrTErR64mNeWcCV1l2+7Ti8Zr ybiKqlgF48GF+bAvQrw6AOKzKSzmGL3w1MQTNCCJFkzRylk8VRBtSw4UAbXHCJpZ/snu fpYf69tPOiUSWzdFgDfag8BjiBpC4/mGf/kWDD+eBXmphmgpy+S47Gk2selXxN02J8YS En6aIgwFBBKw/XkblKVLOI8aEFaGGGDv/OaWKfXLixM3Sr5Q6ebatSSZyylO3XCwvgpi 0HEOR909ik7qIH4fF715iHthtQ5m3qbbPxd457xsVfolGtwgmdxFIo3N1ZH2PdSob2eM g3JA== X-Gm-Message-State: APjAAAVQ3SpxXgIueUAHeWrh4Bf1qBtmkd3qiHxOuPChXK1b826UrO2N cZY+moequKgJu1N5KV4v547dbifPdScQSyxYkPeJk5hiFhA= X-Google-Smtp-Source: APXvYqzx1TvAPg3eJ3kjIDa9nbNzCf2kyMDIKpo2W527e6jVEEWp8XpDFMK+Js0ilmbnv1k7no7e/tcpShdJW6R0MgY= X-Received: by 2002:a2e:8496:: with SMTP id b22mr4302038ljh.9.1556261161068; Thu, 25 Apr 2019 23:46:01 -0700 (PDT) MIME-Version: 1.0 References: <4f21da8a-a30c-4255-9400-aab3a599fb9b@www.fastmail.com> In-Reply-To: <4f21da8a-a30c-4255-9400-aab3a599fb9b@www.fastmail.com> From: Victor Vasiliev Date: Fri, 26 Apr 2019 02:45:49 -0400 Message-ID: To: Christopher Wood Cc: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000af59270587694987" Archived-At: Subject: Re: [TLS] Adoption call for draft-sy-tls-resumption-group 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, 26 Apr 2019 06:46:06 -0000 --000000000000af59270587694987 Content-Type: text/plain; charset="UTF-8" Hello everyone, I believe that the problem this draft addresses is important, and I believe the working group should take on this work. For various operational reasons, websites often use different IPs for different resources they need to fetch. Resumption across different SNI values could allow them to use 0-RTT, reducing penalty for new connections they have to make. A particular case I want to address is a situation when there is a CDN (say cdn.example.com) that has multiple shards (say shard101.cdn.example.com and shard102.cdn.example.com), and the client gets load balanced to a specific shard based on requested resource. In the current situation, unless shard101 and shard102 share the same physical IP, they'd have to pay connection startup cost for each request. Cross-domain resumption would allow 0-RTT to the second shard accessed, provided all shards have a wildcard certificate. >From the technical standpoint, I agree with Martin that a NewSessionTicket extension would be a better fit, but this is something that we can figure out later without much trouble. The policy questions (when *should* the client resume?) are more difficult here, and there are multiple aspects to this. One is, as Martin pointed out, is clarifying the notion of server identity from application perspective in cross-domain scenario. Another is ensuring that the linkability properties are not altered in ways we don't understand. On the surface, one can argue that this is semantically the same procedure as HTTP/2 connection pooling, but without the IP match requirement. This is good, because we can build on the analysis of an existing mechanism. Still, in practice, this might open us up to attacks that with the IP match were impractical. We should ensure that the document describes things we've learned from connection pooling, too. As I've said before, I am happy to help with this draft. -- Victor. On Fri, Apr 12, 2019 at 7:36 PM Christopher Wood wrote: > At TLS@IETF104, there was interest in the room to adopt > draft-sy-tls-resumption-group as a WG item. The draft can be found here: > > https://datatracker.ietf.org/doc/draft-sy-tls-resumption-group/ > > This email starts the call for adoption. It will run until April 26, 2019. > Please indicate whether or not you would like to see this draft > adopted. > > Thanks, > Chris, Joe, and Sean > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000af59270587694987 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello everyone,

I believe that the prob= lem this draft addresses is important, and I believe the working group shou= ld take on this work.

For various opera= tional reasons, websites often use different IPs for different resources th= ey need to fetch.=C2=A0 Resumption across different SNI values could allow = them to use 0-RTT, reducing penalty for new connections they have to make.<= /div>

A particular case I want to address is a situation= when there is a=C2=A0CDN (say cdn.example.com) that has multiple shards (say shard101.cdn.example.com= and shard102= .cdn.example.com), and the client gets load balanced to a specific shar= d based on requested resource.=C2=A0 In the current situation, unless shard= 101 and shard102 share the same physical IP, they'd have to pay connect= ion startup cost for each request.=C2=A0 Cross-domain resumption would allo= w 0-RTT to the second shard accessed, provided all shards have a wildcard c= ertificate.

From the technical standpoint, I agree= with Martin that a NewSessionTicket extension would be a better fit, but t= his is something that we can figure out later without much trouble.

The policy questions (when should the client resum= e?) are more difficult here, and there are multiple aspects to this.=C2=A0 = One is, as Martin pointed out, is clarifying the notion of server identity = from application perspective in cross-domain scenario.=C2=A0 Another is ens= uring that the linkability properties are not altered in ways we don't = understand.=C2=A0 On the surface, one can argue that this is semantically t= he same procedure as HTTP/2 connection pooling, but without the IP match re= quirement.=C2=A0 This is good, because we can build on the=C2=A0analysis of= an existing mechanism.=C2=A0 Still, in practice, this might open us up to = attacks that with the IP match were impractical.=C2=A0 We should ensure tha= t the document describes things we've learned from connection pooling, = too.

As I've said before, I am happy to help w= ith this draft.

=C2=A0 -- Victor.
=

= On Fri, Apr 12, 2019 at 7:36 PM Christopher Wood <caw@heapingbits.net> wrote:
At TLS@IETF104, there= was interest in the room to adopt draft-sy-tls-resumption-group as a WG it= em. The draft can be found here:

=C2=A0 =C2=A0 https://datatracker.iet= f.org/doc/draft-sy-tls-resumption-group/

This email starts the call for adoption. It will run until April 26, 2019. = Please indicate whether or not you would like to see this draft
adopted.

Thanks,
Chris, Joe, and Sean

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000af59270587694987-- From nobody Fri Apr 26 02:30: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 7ED47120335 for ; Fri, 26 Apr 2019 02:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 fmWhm9CfWwSR for ; Fri, 26 Apr 2019 02:30:02 -0700 (PDT) Received: from mailhost.informatik.uni-hamburg.de (mailhost.informatik.uni-hamburg.de [134.100.9.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1AEB1202F0 for ; Fri, 26 Apr 2019 02:30:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTP id 114F8B3B for ; Fri, 26 Apr 2019 11:29:59 +0200 (CEST) X-Virus-Scanned: amavisd-new at informatik.uni-hamburg.de Received: from mailhost.informatik.uni-hamburg.de ([127.0.0.1]) by localhost (mailhost.informatik.uni-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id wI4rR-8SKGP1 for ; Fri, 26 Apr 2019 11:29:58 +0200 (CEST) Received: from svs26.informatik.uni-hamburg.de (svs26.informatik.uni-hamburg.de [134.100.15.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: sy) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTPSA id 55C18B3A for ; Fri, 26 Apr 2019 11:29:57 +0200 (CEST) Reply-To: sy@informatik.uni-hamburg.de To: tls@ietf.org References: <4f21da8a-a30c-4255-9400-aab3a599fb9b@www.fastmail.com> From: Erik Sy Openpgp: preference=signencrypt Autocrypt: addr=sy@informatik.uni-hamburg.de; prefer-encrypt=mutual; keydata= mQENBFdYdRoBCADpTVcxZw2Z+3IEm8QgmYNdzKQdCPnDm3mvV+dskI2vNuhAM7eTHE62Ibl8 TD08JJ0Q5DbaHLZBYZR7dVc6Vw+p5Ns5YM5MpDH4rcJTm9FR/QgJ94dH0dOKwtq9gMhLdlhV N0v/OgDb7YdfNYzhthVc3MUxBEznspDaBsGXCASM98SvCaovrhDU05OyIIq6yaIZc6W1ad8z oLn3kZ1O0NkJFuS2H6W1Sg6+af2980SagRTEntr/U6y9wKrKMr0woPBkgYjjivW31yRpjbW0 FClGr/WamdETrJFMTnn6Zc4tELj4pI5T/3jsSCuJ+Mf0fxGIoznG1xW09E5KoT4RBQZ7ABEB AAG0JkVyaWsgU3kgPHN5QGluZm9ybWF0aWsudW5pLWhhbWJ1cmcuZGU+iQFBBBMBCgArAhsD BQkFo5qABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAUCV8aJfQIZAQAKCRB4ziXHIWIRJSVz B/wJ1qq82vLrjp+4GOUJf3w23FGK3gtK0THs7VVwtZD+xRGYOzoMG+my0TscPZI5drHnZJeK vYmx+bz0IvJSW9DgYib5kUKtz2qPmj0HR6qW7o5opbIMWmkZJO0ACUEI3pAX+j7O3nEApijT 6dg3XhkLdRBgKVHD6x7n8a0ZbYEta6Co0vmPSpIU8XL1B0MmC9fC/L85kH3MBU0bNA4QU0b+ I9ojylgLnqHhIL39mqpJ/cRfCkuzWeeyFvvD+EGMBVxVKVu7ULNk4sKvqutsoYV6GQ7pAx+O pCKQO87M8aeMF7ytpQ67WGscqCO6IWO5tqDXX3aV9MCswPsuwn+PGjAguQENBFdYdRoBCADQ HO0cmKfEv9y5WW6sXJdnn7PEknFyiI9HoCULGVJi4vWyqYoQBGAM8wWRAVstm8zhqIWTlKR2 EntH6JBQB9dkUtmvuVRBBXs9SSloZU4R7SDysuTmDo3derqbIcomtyTkbfxYI50EQayL8TgR sA6jj9OJzyeywX3c+Nr6G8a0kVvCB97I1qLO5RA1tTIxTiXJMbL+E3CurUIMAakxbuqfH3SV mtH+lmlvGzvUF9mI4a5xti1Jkl/k6p2Q5z3nLt6MgkC9n47BSvrzelIr526FzNTamFIVb4fT /QnC33IydbaVQZaOYD9wi9dHTRBaeAF5a+zY5MCUu17GV3jR36SVABEBAAGJASUEGAECAA8F AldYdRoCGwwFCQWjmoAACgkQeM4lxyFiESV1zwf+PwKloXwIb7450kQq/OukJ90o9jkfGMz1 uC84E/HoYaz8KBUJVmx07zYi0zopAn2Pvh+HtTB6NzoGoRvmvajVa3lWRVeytgtJp+YqdcJq mKa+c1MsrJD2iMr3jMLB70bWT+GA8Moe1Slw4+/c+BndlwnfA5B54PVHjnZtaJDVsyVO1dnj gPReP6YNOQP/AgGexfSqUMYI/ni1QKwMT8e806hc48zT2A1ZnBit5PkGjzvQU0Qoel6Cwj3R uzZJgC5iEdX6kxMEOB0mD6zSKzBg4FNn2r3kUQ24IhbTuMm6/aCv6YlObR8HHkqXcQF6/BTH jlkuqsjIxOXZXqe4DeUnhw== Message-ID: <3cab1508-1c81-3a9f-afb9-9d8bc55871bd@informatik.uni-hamburg.de> Date: Fri, 26 Apr 2019 11:29:56 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [TLS] Adoption call for draft-sy-tls-resumption-group 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, 26 Apr 2019 09:30:05 -0000 On 4/26/19 08:45, Victor Vasiliev wrote: > > From the technical standpoint, I agree with Martin that a > NewSessionTicket extension would be a better fit, but this is > something that we can figure out later without much trouble. I agree with Martin and Victor, that the NewSessionTicket extension is the better fit to signal support for this TLS extension. > > The policy questions (when /should/ the client resume?) are more > difficult here, and there are multiple aspects to this.  One is, as > Martin pointed out, is clarifying the notion of server identity from > application perspective in cross-domain scenario.  Another is ensuring > that the linkability properties are not altered in ways we don't > understand.  On the surface, one can argue that this is semantically > the same procedure as HTTP/2 connection pooling, but without the IP > match requirement.  This is good, because we can build on the analysis > of an existing mechanism.  Still, in practice, this might open us up > to attacks that with the IP match were impractical.  We should ensure > that the document describes things we've learned from connection > pooling, too. > I agree, that the new feature of this extension for web browsing is to conduct HTTP/2 connection pooling without the IP match requirement. However, we should consider a network attacker to be anyway in control of DNS. Thus, the requirement of a matching IP does not provide security benefits against this attacker. As learnings from connection pooling I'm aware of origin confusion attacks against virtual hosting. Can somebody point out other relevant attacks in this context? Best, Erik From nobody Fri Apr 26 08:07: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 3C20912042C for ; Fri, 26 Apr 2019 08:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 FyHHi83E_kzF for ; Fri, 26 Apr 2019 08:07:40 -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 7807F12006D for ; Fri, 26 Apr 2019 08:07:40 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C419E3086202; Fri, 26 Apr 2019 15:07:39 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.83]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0F8FD600D4; Fri, 26 Apr 2019 15:07:38 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Date: Fri, 26 Apr 2019 17:07:32 +0200 Message-ID: <50206934.V7594Szvhb@pintsize.usersys.redhat.com> In-Reply-To: <2EF7433E-DB94-497F-80D7-2A060097261B@dukhovni.org> References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <2EF7433E-DB94-497F-80D7-2A060097261B@dukhovni.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1560282.D2MQDi6fVP"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.42]); Fri, 26 Apr 2019 15:07:39 +0000 (UTC) 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, 26 Apr 2019 15:07:44 -0000 --nextPart1560282.D2MQDi6fVP Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" I think it's fine as it is. This use case is very specific and the impact f= or=20 it is limited. So yes, I think that the delay between publishing and now wi= ll=20 change the situation even more out of favour of TLS 1.0. On Friday, 26 April 2019 03:30:00 CEST Viktor Dukhovni wrote: > > On Apr 12, 2019, at 7:28 PM, Christopher Wood wro= te: > >=20 > > This is the working group last call for the "Deprecating TLSv1.0 and=20 TLSv1.1=E2=80=9D draft available at: > > https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecat= e/ > >=20 > > Please review the document and send your comments to the list by April = 26, > > 2019. > My concern is whether the time is yet nigh for TLS 1.0 to be disabled > in opportunistic TLS in SMTP, or whether TLS 1.0 remains sufficiently > common to cause deprecation to do more harm than good via unnecessary > downgrades to cleartext. >=20 > I don't have survey numbers for SMTP TLS protocol versions across MTAs > generally to shed light on this, perhaps someone does. What I do have > is numbers for those MTAs (not a representative sample) that have DANE > TLSA records (so presumably a greater focus on security). >=20 > The observed version frequencies are approximately: >=20 > TLS 1.0: 1% > TLS 1.1: 0% > TLS 1.2: 87% > TLS 1.3: 12% >=20 > essentially regardless of whether I deduplicate by name, IP or name and I= P. > The respective sample sizes are 5435, 6938 and 7959. >=20 > So if a DANE-enabled sender were to disable TLS 1.0 today, approximately > 1% of the destination MX hosts would be broken and need remediation. The= se > handle just of 189 mostly small SOHO domains out of the ~1.1 million total > DANE SMTP domains, but four handle enough email to show up on the Gmail > SMTP transparency report: >=20 > tu-darmstadt.de > t-2.net > t-2.com > t-2.si >=20 > So on the whole, the draft should proceed, but some caution may be > appropriate outside the browser space, before operators start switching o= ff > TLS 1.0 support. >=20 > I don't see an operational considerations section. Nor much discussion of > "less mainstream" (than Web browser) TLS application protocols. Would a = few > words of caution be appropriate, or is it expected that by the time the R= =46C > starts to change operator behaviour the "market share" of TLS 1.0 will be > substantially lower than I see today even with SMTP, XMPP, NTTP and the > like. >=20 > [ I would speculate that TLS 1.0's share is noticeably higher among MTAs > generally than among the bleeding-edge MTAs that have published DANE TL= SA > RRs. ] =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 --nextPart1560282.D2MQDi6fVP 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+dkqjRuAHS9fUFAlzDHrQACgkQkqjRuAHS 9fWfcA/+MjlT4/VvFY3vJ2wkax0h1R/aCoAtwArakUBD4UvuzJAWAVk42sCQFlLG TBMOhmwMC+0HDFw424VV/bo1G4Z3ljK2Di4Xra7oI/2Br+ZqwGguiI1fGJGbiAxJ 3FonVW4TGj+naf0V1JLV9ksq7EbrOYU7hvkdMMlSOm8QPUYpnn2XkrlKswXrhETg Lcz4spaBuEKa1CkntN6LmybslDhSwVS+qcWoWGmp5yf82CQdX2NvDc6jnMNfEKND 6skS9Cuf0ywrQ3+zIaOt7fG+dAk36rpXJerhCmAmfQs0HyeJBx55nJt35f3d7RcN 0TEVFWxoJHm9Ky8DJbl8eef6d7Jv039W9Dxl3DsbM7EKyeCg/Or0pdCsXjylQoKj BPzRsqH73IPV6a79JdCsaVRwxGnIVivUZ78PHJYg6RqScjcnWDZgxaVuXtlpp01x SYzlH+gqTpALsHQXGiILbTv5G1w9qPswzcDz57YcxWQN1qVnjJAcGjFC+zIHm+qQ rC1dvS8ynxlfuh+6PmyRPJU8o/8hSy1BgsjaJLWwgY+zbPpuHLPshQ2LXhfa9yLs N7ciGEwX9NXApvWUxGdrzYkHWWDw95V4fzQ3uyE6v19e3n2kMUR/RqnFCN0LZOMn i0Bk8fow/yDzMI9kos6ocErde8kdmFn61sgP3EOUzqOGWHy16qc= =87/5 -----END PGP SIGNATURE----- --nextPart1560282.D2MQDi6fVP-- From nobody Fri Apr 26 08:14:39 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 59BD2120438 for ; Fri, 26 Apr 2019 08:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 zO06ser_loZV for ; Fri, 26 Apr 2019 08:14:35 -0700 (PDT) Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40268120432 for ; Fri, 26 Apr 2019 08:14:35 -0700 (PDT) Received: by mail-yb1-xb2b.google.com with SMTP id x71so1377087ybe.6 for ; Fri, 26 Apr 2019 08:14:35 -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=PnnEcpMCeNv3fpcCJFR9Hgj+S0Dyt4WdPg/WeIxxlzE=; b=gLxaLVSkK53FPcvuT2sWx+VlxGyl2GH4Xg+PEpBgUG+aUSaHMxuqVyktBFI1KCNa65 KAjE0TYJMngIkRSAvWAMCoufcslySFyKM3jAs3NWXwMHsWNguLYzYvz/xBQ08nnlXov3 tyAEbgkEpVnJXBpAjz56TBQkpZo1EQ/AhLQcjOMY1JPY4zgpwiWAn3O2/bWyeG54MZCk fKNzMgke/8vsHm9uc4loJ5LKMgW1Aney61wfCRWwQHpOGvnuzuwGUgAZNUugWNm/fb1P kG2NKfEKxveg0QL7d3ZGhRdRcEheYN90Y71dzQIQEDGIE9PEcJo8095H0yd7tq/250pd l8kA== 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=PnnEcpMCeNv3fpcCJFR9Hgj+S0Dyt4WdPg/WeIxxlzE=; b=jC5B2mEY/jIbp+u3CVW0PuxfV9HaM8x1VBhO2EjpnCdJo2HCfpOQpulQ5c0saFDhtw 2e7PukbtkwBO3dCC5DBIBxqxEnP0M2fgut9EILimUYVXnUUWDKnJqrhQ2Evjz//iytzt vhM8OaROghk95gB7ZTRgcUfB1zcTBny0qQBHxRXFO03Ndpp5uHtXzRy9Xfw+pKqnuwej 7BdoxsYIXqRcve1EQqVDrkdsSZhsTNEXJvXNoi7JDLKfeGYdEgpdG+dIroZAxtJGDRIA LTT5W2cxmc/Kfmue/Z9NK2n5204ACqRWe9VlcE3N4dws4kntsVp58sRb/ODwsJvGNDF4 oEuw== X-Gm-Message-State: APjAAAXdZv5+U3kS/X5fNPUn6DXsfg+k5fvU5jVmEsNxd2Z1pXbiFsrS ColMp37Q19E5MfPu3AIvezHUYJBCowetb6SdOwo= X-Google-Smtp-Source: APXvYqyTCYhjiE/i9txP65Ar2atz+nC8EEzZPmO1qs4g4Gicgr9bR+PvdlLZa0G8C8Xxx2OIVYw4/15R03v5TTSllyo= X-Received: by 2002:a25:814e:: with SMTP id j14mr37820435ybm.482.1556291674009; Fri, 26 Apr 2019 08:14:34 -0700 (PDT) MIME-Version: 1.0 References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <2EF7433E-DB94-497F-80D7-2A060097261B@dukhovni.org> <50206934.V7594Szvhb@pintsize.usersys.redhat.com> In-Reply-To: <50206934.V7594Szvhb@pintsize.usersys.redhat.com> From: =?UTF-8?Q?T=C3=B6ma_Gavrichenkov?= Date: Fri, 26 Apr 2019 18:14:21 +0300 Message-ID: To: Hubert Kario Cc: "" Content-Type: multipart/alternative; boundary="00000000000065768e058770648f" 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, 26 Apr 2019 15:14:37 -0000 --00000000000065768e058770648f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Peace, On Fri, Apr 26, 2019, 6:08 PM Hubert Kario wrote: > I think it's fine as it is. This use case is very specific and the impact > for > it is limited. So yes, I think that the delay between publishing and now > will > change the situation even more out of favour of TLS 1.0. > Exactly my thought: polishing it further would hardly make the document significantly better, taking in the account the delay necessary to do that. -- T=C3=B6ma > --00000000000065768e058770648f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Peace,

On Fri, Apr 26, 2019, 6:08 PM Hubert Kario <<= a href=3D"mailto:hkario@redhat.com">hkario@redhat.com> wrote:
I think it's fine as it is. This use = case is very specific and the impact for
it is limited. So yes, I think that the delay between publishing and now wi= ll
change the situation even more out of favour of TLS 1.0.

Exactly my thought:= polishing it further would hardly make the document significantly better, = taking in the account the delay necessary to do that.

--
T=C3=B6ma
--00000000000065768e058770648f-- From nobody Fri Apr 26 08:24: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 43F4712043F for ; Fri, 26 Apr 2019 08:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.338 X-Spam-Level: X-Spam-Status: No, score=-1.338 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, KHOP_DYNAMIC=1.363, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 oTJyttmryw0W for ; Fri, 26 Apr 2019 08:24:55 -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 EF2FF1200A3 for ; Fri, 26 Apr 2019 08:24:54 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.27/8.16.0.27) with SMTP id x3QFMKVm023186; Fri, 26 Apr 2019 16:24:49 +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=hzovD3hZ6hww65SwQS0ern3cjuMmlABj7K2eWmRNIVg=; b=Ge2AoOtZjSN7qUvojk1CWnMLYCbJQ/31Pd9nI/YnYEho2LmUnoOJbOVZhVuPdnspQtu4 5rof70uoVoEbtm2lIMX3xIBpic9dMmH87lAUF6IBNthyAMFdEkF8MP3XjVv1EDaqhXbE vkYD5CjmhM3TCYQzJ3ff1gxSUZ7IDZZhIKX4uP1ct+TAkbRopFJOulxyAJfOfUxl+noA Suu5tfdgx/bTwQYDDgXLLZ8Vs9+bonhofD2lweJRQ583wW9valpP94DxxkObDWhaPD3R 3QE1I+CTkjQluJxVrzssLyf4w5bBfIZJerEqS8ovwX5s+aj7yZ1WZ0NorWhYR5Kk3QEA yw== Received: from prod-mail-ppoint3 (prod-mail-ppoint3.akamai.com [96.6.114.86] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2s3mwskcgh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 26 Apr 2019 16:24:49 +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 x3QFHk0R018141; Fri, 26 Apr 2019 11:24:47 -0400 Received: from email.msg.corp.akamai.com ([172.27.27.25]) by prod-mail-ppoint3.akamai.com with ESMTP id 2ryxrvbggf-5 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 26 Apr 2019 11:24:47 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.27.102) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 26 Apr 2019 10:24:36 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1473.003; Fri, 26 Apr 2019 10:24:36 -0500 From: "Salz, Rich" To: Daniel Migault , IETF TLS WG Thread-Topic: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1" Thread-Index: AQHU8YeAvZdXo+2j6ke3RCIqFp6FaaZOD+MAgAAFHwCAAKEBgA== Date: Fri, 26 Apr 2019 15:24:35 +0000 Message-ID: <5C3C015B-88B9-4502-861B-C59120B2F151@akamai.com> References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <2EF7433E-DB94-497F-80D7-2A060097261B@dukhovni.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.18.0.190414 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.208] Content-Type: multipart/alternative; boundary="_000_5C3C015B88B94502861BC59120B2F151akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-26_10:, , 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=839 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904260104 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-26_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=845 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904260105 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, 26 Apr 2019 15:24:57 -0000 --_000_5C3C015B88B94502861BC59120B2F151akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWYgdGhleSBoYXZlbuKAmXQgYWxyZWFkeSBtb3ZlZCBvZmYgVExTIDEgdGhlbiBtYXliZSB0aGlz IGRvY3VtZW50IHdpbGwgZ2l2ZSB0aGUgcmlnaHQgcGVvcGxlIGEgcHVzaCB0byBkbyBzby4NCg0K Tm9ib2R5IGlzIGdvaW5nIHRvIGFycmVzdCBhbiBNVEEgZm9yIG5vbiBjb21wbGlhbmNlLg0K --_000_5C3C015B88B94502861BC59120B2F151akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <3783C42BD4A08B40809F54854D5E158E@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPklmIHRoZXkgaGF2ZW7igJl0IGFscmVhZHkgbW92ZWQgb2ZmIFRMUyAxIHRoZW4g bWF5YmUgdGhpcyBkb2N1bWVudCB3aWxsIGdpdmUgdGhlIHJpZ2h0IHBlb3BsZSBhIHB1c2ggdG8g ZG8gc28uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vYm9keSBpcyBnb2luZyB0byBhcnJlc3Qg YW4gTVRBIGZvciBub24gY29tcGxpYW5jZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_5C3C015B88B94502861BC59120B2F151akamaicom_-- From nobody Fri Apr 26 14:28:55 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 626F312060C for ; Fri, 26 Apr 2019 14:28:42 -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_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 jzD2b1a3GnSR for ; Fri, 26 Apr 2019 14:28:40 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 763D0120611 for ; Fri, 26 Apr 2019 14:28:40 -0700 (PDT) Received: from [192.168.1.161] (unknown [192.168.1.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id B0C362B025B for ; Fri, 26 Apr 2019 17:28:39 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Viktor Dukhovni In-Reply-To: <5C3C015B-88B9-4502-861B-C59120B2F151@akamai.com> Date: Fri, 26 Apr 2019 17:28:39 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: IETF TLS WG Message-Id: References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <2EF7433E-DB94-497F-80D7-2A060097261B@dukhovni.org> <5C3C015B-88B9-4502-861B-C59120B2F151@akamai.com> To: IETF TLS WG X-Mailer: Apple Mail (2.3445.104.8) 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, 26 Apr 2019 21:28:54 -0000 > On Apr 26, 2019, at 11:24 AM, Salz, Rich wrote: >=20 > If they haven=E2=80=99t already moved off TLS 1 then maybe this = document will give the right people a push to do so. > =20 > Nobody is going to arrest an MTA for non compliance. Of course. And as I said, I'd like to see the document move forward, I just wanted to see whether there was any appetite for adding some operator guidance. It's not an issue of internet policing, rather it is a question of whether there should advice for operators who are considering disabling the legacy protocols. The sound-bite version is: first raise the ceiling, *then* the floor. The advice would therefore be for everyone to first make sure that their systems support at least TLS 1.2, and not just the now deprecated versions. And then check whether the same holds true for their = application ecosystem and if so disable the protocols at that time. In unauthenticated opportunistic TLS where cleartext is used when TLS handshakes fail, removing support for TLS 1.0 can reduce security in the short term (some messages needlessly going in cleartext). Yes, this may be what it takes to finally get the long tail procrastinators to = upgrade. The operational question then boils down to timing: when is your = application ecosystem ready to drop the training wheels. Anyway, it does not look like there's much interest in adding = operational considerations, which users will then perhaps learn about elsewhere if need be. That's fine... --=20 Viktor. From nobody Fri Apr 26 14:55: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 0618D12061F for ; Fri, 26 Apr 2019 14:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=zinks.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnbBF9uozNvF for ; Fri, 26 Apr 2019 14:55:40 -0700 (PDT) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3D7A120385 for ; Fri, 26 Apr 2019 14:55:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1556315736; s=strato-dkim-0002; d=zinks.de; h=In-Reply-To:Date:Message-ID:From:References:To:Subject: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=vsXpSG310VdzHgJaCp82tN76LTNJG5BKCvQATvHvAys=; b=ix74Kl7eX5Aow0QX4ZXtYlLpAIkYcK+qdhmQcpo7LCV3+KlAvqtpXLDOBzU3qkrqsi 2Ro/KNX+qaGzQDJBgIyrCZad+TPs8mmz83zilEOtkF/5N0Q64oHTpcOqJVLMZODySBOy kP/lsVeREADM6akSkzIW8OxyLtJwnA+ZxP+abyMzeNnJfMIRqcBPUIosFTFBVb8y30Xk k1TAbVzShdrLLNlZCdpBjPzRnbQHzRauCtNyOX1HmSyMdfjdUttrnmE4Y9nSxrMlOqJB XLvxLuQnpqpK+e0+7FNj81f+O6rEmPV3aDqM4HSafSI+BDJnl94J+oZU5tmyBgh9F/wq 8bqg== X-RZG-AUTH: ":PmMIdE6sW+WWP9q/oR3Lt+I+9LAZzXrcq8knhvfmBiJzkmKt0Zib1EwEOzr8+BFkrcJW7I5JPWMnT76bq3qN05dsOKc74aUOuQ==" X-RZG-CLASS-ID: mo00 Received: from [IPv6:2003:f4:73c3:6700:bc54:aadd:3bec:7d69] by smtp.strato.de (RZmta 44.18 AUTH) with ESMTPSA id Y09727v3QLtar7h (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Fri, 26 Apr 2019 23:55:36 +0200 (CEST) To: tls@ietf.org References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <2EF7433E-DB94-497F-80D7-2A060097261B@dukhovni.org> <5C3C015B-88B9-4502-861B-C59120B2F151@akamai.com> From: Roland Zink Message-ID: Date: Fri, 26 Apr 2019 23:55:36 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <5C3C015B-88B9-4502-861B-C59120B2F151@akamai.com> Content-Type: multipart/alternative; boundary="------------699D42EF4A143C1424C70F8B" 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, 26 Apr 2019 21:55:43 -0000 This is a multi-part message in MIME format. --------------699D42EF4A143C1424C70F8B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit This is of cause true. The MTA will not be arrested the question is if somebody will arrest the administrator or the owner. This will become part of the "push" the right people. Regards, Roland Am 26.04.2019 um 17:24 schrieb Salz, Rich: > > If they haven’t already moved off TLS 1 then maybe this document will > give the right people a push to do so. > > Nobody is going to arrest an MTA for non compliance. > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --------------699D42EF4A143C1424C70F8B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

This is of cause true. The MTA will not be arrested the question is if somebody will arrest the administrator or the owner. This will become part of the "push" the right people.


Regards,

Roland


Am 26.04.2019 um 17:24 schrieb Salz, Rich:

If they haven’t already moved off TLS 1 then maybe this document will give the right people a push to do so.

 

Nobody is going to arrest an MTA for non compliance.


_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--------------699D42EF4A143C1424C70F8B-- From nobody Sun Apr 28 16:27: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 2943012010D for ; Sun, 28 Apr 2019 16:27:00 -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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=pzZGowru; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=7oDUc/e2 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUE9IHhK680k for ; Sun, 28 Apr 2019 16:26:57 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4B33120058 for ; Sun, 28 Apr 2019 16:26:57 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 5E416210D8 for ; Sun, 28 Apr 2019 19:26:56 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Sun, 28 Apr 2019 19:26:56 -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 :subject:content-type; s=fm2; bh=rBOPbmCBuVZWlHXicw4SjL0p62U7ypU iawA+Y7GdGNY=; b=pzZGowruaHbC1Fg4LJMgXCTIXWszKUwTYv7Nu1Le0Q50TPf 5ruuE93Jm8j373/3y20gb2Vl3DGfbaLdRwV4gj3bhMVt8JuLANiIp/uTdYBk04x1 QmLvSYx4d0fp+WksmlA6TT8E9XGAgxPoMt+dk0EokmUtLccX/qkxV8u04Z8WSaX6 rwcpiX0ULz8iw/Gcbqfaqw0X0JX6w7JbZUe/bG/H7PY9+6RV9PdUp17KxqVz09AT 5fy065AFOpzK5BGiscfa1wWEP3P0uaY0TzcujWH/AXFOysmJDShch29SVs7XjPNN wsstr1jbfejtjmozLgviCTRqV2OkA+ykgzZwjHg== 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=fm2; bh=rBOPbm CBuVZWlHXicw4SjL0p62U7ypUiawA+Y7GdGNY=; b=7oDUc/e2fGhMyFu3IRt/SD aROlsBtH7/ht/yMBbloi/Z6L8ns7TT6HRp1aaeOuHwcRLu6g0FnBVkg3/L4gmBOg aK9sUuuC8p2+bCSLcC6c+8qlDuG5Ea3OyHEUg0m3q9fbpk/QU5ZxcetMWi8rUbTQ /5iqtCm2pfhJpXP7AenMiKTIoUCnm5QWDHqpFjJACf7g19R6pDNXn/QOnWI+MEDw FMMb1ewq4ImB95UFXNZi/6/ym+RX/SAyeNUHiq423B7s5CiocVVak3xpfTvwI6d6 ddzC3Zhjh+Elr6xsZKCndzrZDXdaHP0wzWspNZfhLAlQTEUWyg2wWGx0fg1NS4xA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddriedugddukecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofi gvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5FBE07C199; Sun, 28 Apr 2019 19:26:55 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-444-g755619f-fmstable-20190423v1 Mime-Version: 1.0 Message-Id: <7d37f7ca-e253-4c95-9cf7-2d16b0b6a0aa@www.fastmail.com> In-Reply-To: References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <2EF7433E-DB94-497F-80D7-2A060097261B@dukhovni.org> <5C3C015B-88B9-4502-861B-C59120B2F151@akamai.com> Date: Sun, 28 Apr 2019 19:26:58 -0400 From: "Martin Thomson" To: tls@ietf.org Content-Type: text/plain 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: Sun, 28 Apr 2019 23:27:00 -0000 On Sat, Apr 27, 2019, at 07:29, Viktor Dukhovni wrote: > The sound-bite version is: first raise the ceiling, *then* the floor. Yep. We've done the ceiling bit twice now. Once in 2008 when we published TLS 1.2 and then in 2018 with the publication of TLS 1.3. I'd say we're overdue for the floor bit. From nobody Mon Apr 29 09:21: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 5F523120402 for ; Mon, 29 Apr 2019 09:21:22 -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=FGpfU+TW; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QqU2y/Hg Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GNEcoz8_Oc1 for ; Mon, 29 Apr 2019 09:21:20 -0700 (PDT) Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com [66.111.4.224]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 495B71203D6 for ; Mon, 29 Apr 2019 09:21:20 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailnew.nyi.internal (Postfix) with ESMTP id 92C3229E8A for ; Mon, 29 Apr 2019 12:21:17 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Mon, 29 Apr 2019 12:21:17 -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:content-transfer-encoding; s=fm1; bh=1heWa LNARSfhAl33f5m5H3aHt+s1VQ2Q1fUQqXRM86Q=; b=FGpfU+TWkIzSYueH9kQEW RGtd79FOWFcdhGpww75mbV9VyrtEYhBy4JBhhReYSuHBAS1nykxjsK5VvZBWSidE jq12U6YNT1SuL5+oAl2qc4RbwpeVjDAqwL3wvdDoS/fEvq64cAIhc/4BQNx9IeFR lIcquhCsPykvYlC27Vskk/dpXnyZwyGUL8yfrLIT+IGAODvWgnhu/Kea+3oFLYMj hEdhJ9Ki/gwlqtqfNGtQD5ilJd3rnO7pDNbmT+Cv+/m0fVbJhSAf5JrVJlrcBJR1 dhQRDDhnYbMggU63LJCPsrOb8f3ZNKEsrXpI9LTtqDoEu7QlfUIYFxIqQ+safwXS Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding: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=fm2; bh=1heWaLNARSfhAl33f5m5H3aHt+s1VQ2Q1fUQqXRM8 6Q=; b=QqU2y/HgyCXH8L49VzmATndzMRo+RDPRqkZtevwY0/ieL6D/1eGf0UpqJ A36Ap8CNJq85Oh58xwzz4uknVW+hl9rInuPUMdGS2PLamNP+BzTFTCpAUzpOd0ti TGNM/pJSA/iCSd5k/m8kBelpPdWrCMg1IdSQ06Ni23wzNAmGKDmqxtIFRauxZcNG zOFbmvmzcIxUtcpfOYPtuMjfXcxPslZ6qTF5s5kbTsywDqAiDNxAzNG1o2aapdYb 9a/gfWCcsM0yzqovYA2wU9X6CLMWptEnS34mHWwaE0hSSl6RlWEnLY1Z43EPGHSu RjrF+6lCU+PnZWa9NdOVy0WfAWK0A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddriedvgddutddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdevhhhrihhsthhophhhvghrucghohhougdfuceotggr fieshhgvrghpihhnghgsihhtshdrnhgvtheqnecuffhomhgrihhnpehivghtfhdrohhrgh enucfrrghrrghmpehmrghilhhfrhhomheptggrfieshhgvrghpihhnghgsihhtshdrnhgv thenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E73BD26274; Mon, 29 Apr 2019 12:21:16 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-448-g5cc1c91-fmstable-20190429v1 Mime-Version: 1.0 Message-Id: In-Reply-To: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> Date: Mon, 29 Apr 2019 12:20:56 -0400 From: "Christopher Wood" To: "TLS@ietf.org" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: Mon, 29 Apr 2019 16:21:22 -0000 The WGLC is finished with no substantial blockers. We'll work with the a= uthors in moving this document to the next stage in the process. Thanks to everyone who reviewed and commented on this document.=20 Best, Chris, Joe, and Sean On Fri, Apr 12, 2019, at 4:28 PM, Christopher Wood wrote: > This is the working group last call for the "Deprecating TLSv1.0 and=20= > TLSv1.1=E2=80=9D draft available at: >=20 > https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprec= ate/ >=20 > Please review the document and send your comments to the list by April= 26, 2019. >=20 > Thanks, > Chris, Joe, and Sean From nobody Mon Apr 29 09:24: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 884AB120423 for ; Mon, 29 Apr 2019 09:24:30 -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=AEeg/y88; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KnRLlGdi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K_YJyA8vhCc0 for ; Mon, 29 Apr 2019 09:24:29 -0700 (PDT) Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com [66.111.4.224]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F109120418 for ; Mon, 29 Apr 2019 09:24:29 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailnew.nyi.internal (Postfix) with ESMTP id 20DC227411 for ; Mon, 29 Apr 2019 12:24:28 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Mon, 29 Apr 2019 12:24:28 -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=fm1; bh=6QAshuhJ515XOftqrs2UcUcaHG1zdzD gEqw+pwLFXYE=; b=AEeg/y88bD3w5OPkXJdPIYf7CafEvgm/iC9k/UT6gl299OK eaulwhOvAgpm2XOxcwe1E319Tkb8e2aothtRFfdgM/DXqxOOCDn77WdfQXSqWL3x kS5NvYWkSTSnlvCsCDA4AuOCh5duM3S3lERMHUajicAnjagyXRpUqSod5sfTz8hn 1N+BFviGoUpJU7UTJh1denN7+snjtUvUcQUFQ0D2qFO+cQ5TX5J+XbS/fX74pI+v ieiWy3qb8od22k7tPgev9IfIfpb6h25Pi3zDeWzDiTrPda1Dc+E6PRvLYz/YLlEv j0GhFP1tWNqIw28pnncLvHrSZLjSbjwVqK9wKuQ== 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=fm2; bh=6QAshu hJ515XOftqrs2UcUcaHG1zdzDgEqw+pwLFXYE=; b=KnRLlGdiuHwdjmussfmD1H FniQDX/taFoK/zxFNODv23STXI77iSMkHf4rNDDLjb8z7N4dZYSzns8uLlUchT3m /oioCxHwO+MS29fqglzfg9pwF+RpGRQl449HboybTgQspzqgTa4GwbHOz5q4wkNe //IEOQCodWJ3kojJQvhZreohS1WUQbf26bl+TLRcvZGkPxV1PZFeFuVhMpe1QrJR HEoOsJLbJYETCZzqd0kcfY24VXPl4I2nY1+vcbhY+aPIWYYgMbkVItoJS3b7D052 krxHH3+meuJS+H7+VlXPK0t02EZj4PYQ2PyBUaHNt267SyTeiRAhGahPkg0jc+jQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddriedvgddutddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgif sehhvggrphhinhhgsghithhsrdhnvghtqeenucffohhmrghinhepihgvthhfrdhorhhgne curfgrrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrphhinhhgsghithhsrdhnvght necuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 77C0C260C3; Mon, 29 Apr 2019 12:24:27 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-448-g5cc1c91-fmstable-20190429v1 Mime-Version: 1.0 Message-Id: In-Reply-To: <4f21da8a-a30c-4255-9400-aab3a599fb9b@www.fastmail.com> References: <4f21da8a-a30c-4255-9400-aab3a599fb9b@www.fastmail.com> Date: Mon, 29 Apr 2019 12:24:27 -0400 From: "Christopher Wood" To: "TLS@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [TLS] Adoption call for draft-sy-tls-resumption-group 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, 29 Apr 2019 16:24:31 -0000 The adoption call for this document is finished. Due to the lack of comments and some concern raised over the existing design, the chairs feel the draft needs more discussion and possible revision(s) before the WG adopts this as an active work item. Best, Chris, Joe, and Sean On Fri, Apr 12, 2019, at 4:33 PM, Christopher Wood wrote: > At TLS@IETF104, there was interest in the room to adopt > draft-sy-tls-resumption-group as a WG item. The draft can be found here: > > https://datatracker.ietf.org/doc/draft-sy-tls-resumption-group/ > > This email starts the call for adoption. It will run until April 26, > 2019. Please indicate whether or not you would like to see this draft > adopted. > > Thanks, > Chris, Joe, and Sean From nobody Mon Apr 29 11:57: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 B5071120318 for ; Mon, 29 Apr 2019 11:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, RCVD_IN_DNSWL_MED=-2.3, 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 zfNe5QRrcFGM for ; Mon, 29 Apr 2019 11:57:25 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27272120100 for ; Mon, 29 Apr 2019 11:57:24 -0700 (PDT) Received: from [10.200.0.109] (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id D9E1D2B19C7 for ; Mon, 29 Apr 2019 14:57:23 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Viktor Dukhovni In-Reply-To: <7d37f7ca-e253-4c95-9cf7-2d16b0b6a0aa@www.fastmail.com> Date: Mon, 29 Apr 2019 11:55:05 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: IETF TLS WG Message-Id: <7EC9390C-2B1C-442F-96EF-30B743A830CF@dukhovni.org> References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <2EF7433E-DB94-497F-80D7-2A060097261B@dukhovni.org> <5C3C015B-88B9-4502-861B-C59120B2F151@akamai.com> <7d37f7ca-e253-4c95-9cf7-2d16b0b6a0aa@www.fastmail.com> To: IETF TLS WG X-Mailer: Apple Mail (2.3445.104.8) 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: Mon, 29 Apr 2019 18:57:27 -0000 > On Apr 28, 2019, at 7:26 PM, Martin Thomson wrote: >=20 >> The sound-bite version is: first raise the ceiling, *then* the floor. >=20 > Yep. We've done the ceiling bit twice now. Once in 2008 when we = published TLS 1.2 and then in 2018 with the publication of TLS 1.3. I'd = say we're overdue for the floor bit. Agreed. That comment was about the *operators* and application = ecosystems, not the TLS WG. --=20 Viktor. From nobody Mon Apr 29 14:09: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 141A4120694 for ; Mon, 29 Apr 2019 14:09: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, 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_NONE=-0.0001, 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=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 0jRtB8ELjBhE for ; Mon, 29 Apr 2019 14:09:29 -0700 (PDT) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29DF3120145 for ; Mon, 29 Apr 2019 14:09:28 -0700 (PDT) Received: by mail-wm1-x336.google.com with SMTP id h11so1062466wmb.5 for ; Mon, 29 Apr 2019 14:09:28 -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=MroX2Ew3lA0Jm6ZTRGl1byJtm3+TrAQnG2nTb9kxUAw=; b=iMoMH1VWceXPlN6OvnqZSJbUsN0GaHlr8N4zxmWAk1V+ZyE2sTKfv4uUHv/WunbOgW gKKCL1acTz406pAW7YOUw+owDj8JHYhuTZz8m+h4HR8jMfYYPf8nD40CBbUBccXh2fai hCAaZ8/qcYHOWZVmGNgr5lJ0beqHkdnCv45LE= 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=MroX2Ew3lA0Jm6ZTRGl1byJtm3+TrAQnG2nTb9kxUAw=; b=bPJhZo07BqF+dbsWuFj5Y44j1bB5GEK0QC1kSDNxpJlOf2iAZNQhBL8a34ORN4sh3z Mf/FPJ8Y5kTTHFEp+q6bfBLUtpRO8LdJPoJWt2sNRgj70yhwckket0BUPRcECT/uklvl 0VRTKnnlGCfjipQri7Fssd6fpBJI9dN0COylaRSueNv9AQPypkB/R2nz/qUMNSwnzUMt qKpNSVDJOoqccCf3AlRHcXt3Wf/u9AIA0r/ww5oVjHwnhlLdG5DfZIjzK69s43ypot/5 vPKtbWGUPeMrOdS6ZQB2EMV1B3psqQTk49/msex98xs60cjDPxYF2TapGRXXuHohRRHw Gxxg== X-Gm-Message-State: APjAAAXlBukSszFQ9DfO2AAxI5inqVTSdvde7ZgV9FXrJ/Cufhd7/7Yv XvHLtmUiOxECOp/dbvI783fC9jkmmrs9C3RQgyCisw== X-Google-Smtp-Source: APXvYqxV3YpqSiI+20nt7Db0T4HAiVBAx1qh9z7xCMbNubktfIgjfOCY5wkWBkhdlwoZ0IzWcIceqckuYDUmERhpAdY= X-Received: by 2002:a7b:cc91:: with SMTP id p17mr648904wma.147.1556572165932; Mon, 29 Apr 2019 14:09:25 -0700 (PDT) MIME-Version: 1.0 References: <20190423182055.GC49657@kduck.mit.edu> In-Reply-To: <20190423182055.GC49657@kduck.mit.edu> From: Nick Sullivan Date: Mon, 29 Apr 2019 14:09:14 -0700 Message-ID: To: Benjamin Kaduk Cc: draft-ietf-tls-exported-authenticator.all@ietf.org, "" Content-Type: multipart/alternative; boundary="00000000000004bb900587b1b3ca" Archived-At: Subject: Re: [TLS] AD review of draft-ietf-tls-exported-authenticator-08 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, 29 Apr 2019 21:09:36 -0000 --00000000000004bb900587b1b3ca Content-Type: text/plain; charset="UTF-8" Ben, Thank you for the thorough review. I've added responses/comments inline and a PR to the spec https://github.com/tlswg/tls-exported-authenticator/pull/46. Feel free to respond in the PR for specific changes or on this thread for structural comments. On Tue, Apr 23, 2019 at 11:21 AM Benjamin Kaduk wrote: > > Hi all, > > I don't think there's anything earth-shattering in here; mostly just places > where we can tighten things up before it gets to a broader set of > reviewers. > > Thanks! > > -Ben > > Abstract, Introduction > > Maybe s/other party/peer/? How about: This document provides a way to authenticate one party of a Transport Layer Security (TLS) communication to its peer using a certificate > Section 1 > > This document provides a way to authenticate one party of a Transport > Layer Security (TLS) communication to another using a certificate > after the session has been established. This allows both the client > and server to prove ownership of additional identities at any time > after the handshake has completed. This proof of authentication can > be exported and transmitted out of band from one party to be > validated by the other party. > > We need to be careful about what exactly is being proved when, and how it > synchronizes (or doesn't) with other events/data. > This will be a general theme throughout... > > multiple identities - Endpoints that are authoritative for multiple > identities - but do not have a single certificate that includes > all of the identities - can authenticate with those identities > over a single connection. > > (The RFC Editor will do two-hyphen em dashes.) > I didn't go back and reread the formal analysis that Jonathan sent out, > but my recollection was that the semantics around being "jointly > authoritative" over multiple identities are quite subtle, and that the > wording here may be doing the reader a disservice. Here's a suggested edit: can authenticate with those identities over a single connection -> can authenticate additional identities over a single connection Jonathan's analysis showed that the protocol provides "joint authentication" between the certificate used in the handshake and one added as an EA. It does not provide "joint authentication" between two EAs. That's a subtle point, but I think it maps cleanly to this text. > > > > This document intends to replace much of the functionality of > renegotiation in previous versions of TLS. It has the advantages > over renegotiation of not requiring additional on-the-wire changes > during a connection. For simplicity, only TLS 1.2 and later are > supported. > > Well, renegotiation does many things. We need to say why we claim that > renegotiation was widely used and for what purpose(s), and only then say > that we provide an alternative. > Also, the wording about "previous versions of TLS" is pretty vague -- is > it intended to be "prior to TLS 1.3"? Very good point. How about: Versions of TLS prior to TLS 1.3 used renegotiation as a way to enable post-handshake client authentication given an existing TLS connection. The mechanism described in this document may be used to replace the post-handshake authentication functionality provided by renegotiation. Unlike renegotiation, exported Authenticator-based post-handshake authentication does not require any on-the-wire changes. For simplicity, only TLS 1.2 and later are supported. > > > > Post-handshake authentication is defined in TLS 1.3, but it has the > disadvantage of requiring additional state to be stored in the TLS > state machine and it composes poorly with multiplexed connection > protocols like HTTP/2 [RFC7540]. It is also only available for > > We should probably be more explicit about "composes poorly" being due to > the authentication not being tied to a specific event at the higher > layer (among other things). How about: Post-handshake authentication is defined in TLS 1.3, but it has the disadvantage of requiring additional state to be stored in the TLS state machine. Furthermore, the authentication boundaries of TLS 1.3 post-handshake authentication align with TLS record boundaries, which are often not aligned with the authentication boundaries of the higher-layer protocol. For example, multiplexed connection protocols like HTTP/2 [RFC7540] do not have a notion of which TLS record a given message is a part of. > > > Section 3 > > > The authenticator request is a structured message that can be > exported from either party of a TLS connection. It can be > transmitted to the other party of the TLS connection at the > application layer. The application layer protocol used to send the > authenticator SHOULD use TLS as its underlying transport to keep the > request confidential. > > Also to indicate which TLS connection to pull key material from? How about: The authenticator request is a structured message that can be created by either party of a TLS connection using data exported from that connection. > > This message does not include the TLS record layer and is therefore > not encrypted with a handshake key. > > We should probably reword this -- "include the TLS record layer" is > going to confuse people. It may be as simple as just adding "framing". How about: This message does not include any TLS framing and is not encrypted with a handshake key. > > > The CertificateRequest is used to define the parameters in a request > for an authenticator. The definition for TLS 1.3 is: > > struct { > opaque certificate_request_context<0..2^8-1>; > Extension extensions<2..2^16-1>; > } CertificateRequest; > > I think we need some filler paragraph in here noting that we re-use the > data structure but assign slightly different meanings to the fields ("as > follows") -- otherwise it sounds like we're just repeating the whole > definition including field descriptions, which we clearly are not > ("[t]his value is unrelated to the certificate_request_context used in > post-handshake authentication"). > > > from pre-computing valid authenticators. This value is unrelated > to the certificate_request_context used in post-handshake > authentication and collisions do not need to be avoided. > > This text seems to invite the reader to ask "collisions between what". > Perhaps we should just say "there is no need to ensure uniqueness > between values used in post-handshake authentication and values used for > exported authenticators". Though if we do that, maybe we want to follow > up by reiterating the need for uniqueness within each class on its own. I think it's important to note that this *is* a recap of the CertificateRequest message in TLS 1.3. Maybe it would be clear if the same or similar description was used. How about an introduction: This message reuses the structure to the CertificateRequest message in [TLS13]. The uniqueness requirements of the certificate_request_context apply only to CertificateRequest messages that are used as part of authenticator requests. There is no impact if the value of a certificate_request_context used in an authenticator request matches the value of a certificate_request_context in the handshake or in a post-handshake message. And then a shorter description: message. A certificate_request_context value MUST be unique for each authenticator request within the scope of a connection (preventing replay and context confusion). The certificate_request_context SHOULD be chosen to be unpredictable to the peer (e.g., by randomly generating it) in order to prevent an attacker who has temporary access to the peer's private key from pre-computing valid authenticators. > > > > extensions: The extensions that are allowed in this structure > include the extensions defined for CertificateRequest messages > defined in Section 4.2. of [TLS13] and the server_name [RFC6066] > extension, which is allowed for client-generated authenticator > requests. > > Do we need to create a new "message type" for the "TLS 1.3" column in > the registry > ( https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml ) > for future extensibility? This should support the same extensions supported by the corresponding messages in TLS. > > > Section 4 > > An authenticator message can be constructed by either the client or > the server given an established TLS connection, a certificate, and a > corresponding private key. Clients MUST NOT send an authenticator > without a preceding authenticator request; for servers an > authenticator request is optional. The authenticator uses the > > I think at this point in the document we haven't indicated what context > value to use for unsolicited exported authenticators from the server. > Do we want to say something here? Sure. We can say that it is chosen by the server here, then later the uniqueness requirement is stated. Text: corresponding private key. Clients MUST NOT send an authenticator without a preceding authenticator request; for servers an authenticator request is optional. For authenticators that do not correspond to authenticator requests, the certificate_request_context is chosen by the server. > > > Section 4.1 > > The context_value used for the exporter is empty (zero length) for > all four values. The length of the exported value is equal to the > > When I first read this I felt a need to think through the consequences > of using the empty context_value here. A statement to the effect of > "the exporter value is used as a standard API to obtain a value that > includes the TLS handshake transcript hash. There is no need to include > additional context information at this stage, since the > application-supplied context is included in the actual authenticator > object" would probably alleviate the concerns of many readers. Good addition. How about: The context_value used for the exporter is empty (zero length) for all four values. There is no need to include additional context information at this stage since the application-supplied context is included in the authenticator itself. The length of the exported value is equal to the... > > > length of the output of the hash function selected in TLS for the > pseudorandom function (PRF). Cipher suites that do not use the TLS > PRF MUST define a hash function that can be used for this purpose or > > Process-wise this is not great wording, seemingly attempting to bind the > specifications of (already extant?) TLS ciphers to do more work. It's > probably better to phrase it like "exported authenticators cannot be > used with cipher suites that do not use the TLS PRF and have not defined > a hash function for this purpose". Good simplification, I'll take it: length of the output of the hash function selected in TLS for the pseudorandom function (PRF). Exported authenticators cannot be used with cipher suites that do not use the TLS PRF and have not defined a hash function for this purpose. Call this hash function the authenticator hash. The last line was added to make references to this hash easier. > > > If the connection is TLS 1.2, the master secret MUST have been > computed with the extended master secret [RFC7627] to avoid key > synchronization attacks. > > Let's rephrase this as "Exported Authenticators MUST NOT be generated or > accepted on connectons not using the extended master secret [RFC7627] > extension, to avoid key synchronization attacks", to be very explicit > about the prohibited behavior. Agreed. > > > section 4.2 > > If an authenticator request is present, the extensions used to guide > the construction of these messages are taken from the authenticator > request. Unrecognized extensions MUST be ignored. If the > certificate_request_context from the authenticator request has > already been used in the connection, then no authenticator should be > > What does "used" mean? How about: If the peer creating the certificate_request_context has already created or correctly validated an authenticator with the same value, then no authenticator > > > Only servers can provide an > authenticator without a corresponding request. [...] > > This statement duplicates a requirement already stated above. We can safely remove this line. > > > ClientHello extensions are used to determine permissible extensions > in the Certificate message. > > I'd suggest reiterating the "negotiation" model for extensions, and that > you generally can't send something in a response that you didn't receive > in a request (with, of course, the hardcoded exceptions listed in the > initial spec for that functionality). Not sure the right way to word this. Here's a shot: ClientHello extensions are used to determine permissible extensions in the Certificate message. This follows the general model for extensions in TLS in which extensions can only be included as part of a Certificate message if they were previously sent as part of a CertificateRequest message or ClientHello message. > > > Section 4.2.1 > > In addition to "signature_algorithms" and > "signature_algorithms_cert", the "server_name" [RFC6066], > "certificate_authorities" (Section 4.2.4. of [TLS13]), and > "oid_filters" (Section 4.2.5. of [TLS13]) extensions are used to > guide certificate selection. The extensions, or others that might > affect certificate selection, are taken from the authenticator > request if present, or the TLS handshake if not. > > The text about "taken from the authenticator request if present, or the > TLS handshake if not" seems to be duplicating previous discussions. > > Maybe go with "commonly used [to guide certifciate selection]"? We > don't limit what can be used for that purpose in core spec, IIRC. How about we just remove that sentence? > > > I'm a little reluctant to bring this up, as it's fairly tangential to > this document, but there seems to be some general disagreement in the > community about whether the SNI usage model is a proper "negotiation", > where the recipient has to ack the offered value in order for both > parties to agree what server name is in use, versus an assertive model > where the sender just says "this is who I'm trying to talk to" and > decides from the received certificate whether that's the case. > But it doesn't look like we have a way to echo back the accepted SNI in > this message flow.... > > Alternative certificate formats such as [RFC7250] Raw Public Keys are > not supported in this version of the specification. > > Even if we call out some things that aren't supported, we probably still > want to explicitly state what format we do support. Let's use: Only the X509 certificate type in [TLS13] is supported. Alternative certificate formats such as [RFC7250] Raw Public Keys are not supported in this version of the specification. > > > If an authenticator request was provided, the Certificate message > MUST contain only extensions present in the authenticator request. > Otherwise, the Certificate message MUST contain only extensions > present in the TLS handshake. > > "Present in the TLS handshake" could mean SH or EE, too (but we just > mean CH). Also, this is the third time we say that! If we're not exactly repeating anymore since the earlier statement only applies to extensions, and this to the certificate itself. I'll re-word to make sure it's specific to the Certificate message: If an authenticator request is present, the signature algorithm MUST be chosen from one of the signature schemes present in the authenticator request. Otherwise, the signature algorithm used should be chosen from the "signature_algorithms" sent by the peer in the TLS ClientHello. > > > Section 4.2.2 > > If an authenticator request is present, the signature algorithm MUST > be chosen from one of the signature schemes in the authenticator > request. Otherwise, the signature algorithm used should be chosen > from the "signature_algorithms" sent by the peer in the TLS > handshake. > > This text could probably be tightened up. Specifically, we mean in the > CH if we are falling back to the handshake values, and I don't think we > say what to do if we're using TLS 1.2 and "signature_algorithms" wasn't > sent in the ClientHello. Proposed change: Otherwise, the signature algorithm used should be chosen from the "signature_algorithms" sent by the peer in the ClientHello of the TLS handshake. There are no available signature algorithms, then no authenticator should be constructed. > > > Where Hash is the hash function negotiated by TLS. If the > authenticator request is not present, it is omitted from this > construction (that is, it is zero length). > > Above, we say that this Hash could be defined on a per-ciphersuite > basis post-facto; does this text need to be changed to be consistent? Yes. Change: Where Hash is the authenticator hash defined in section 4.1. > > failed CertificateVerify validation, it may be helpful for the > application to confirm that both peers share the same connection > using a value derived from the connection secrets before taking a > user-visible action. > > We may want to define a new exporter for that, here, to keep people from > rolling their own custom (read: broken) scheme. Hmm. Maybe that should be a separate spec? I'm not sure we should add additional mechanisms of this sort into this spec. > > > Also, we could say something about needing to identify (by context?) > which TLS connection to use for a given EA validation... I'm not sure we need to be prescriptive about this. It should be clear which connection is used from the validate/authenticate API (noticed this was missing and added it in the PR). > > > Section 4.2.3 > > Maybe give the hash output a good name so we don't get confused about > Hash vs. HMAC? > > The HMAC is computed using the same hash function using the Finished > MAC Key as a key. > Change: The HMAC is computed using the authenticator hash with the Finished MAC Key as a key. > > > comma after "function"? > > Section 4.2.4 > > Do we want to reiterate that the record layer framing is not used? Ok: This message does not include any TLS framing. > > > A given authenticator can be validated by checking the validity of > the CertificateVerify message given the authenticator request (if > used) and recomputing the Finished message to see if it matches. > > "can be" is not very strong language; do we want to be more proscriptive > about what needs to be done for proper validation? Sure: An authenticator is valid if the CertificateVerify message is correctly constructed given the authenticator request (if used) and the Finished message matches the expected value. When validating an authenticator, a constant-time comparison SHOULD be used. > > > Also, is a constant time comparison going to be needed? Yes, I think so. Otherwise, some bits of the correct finished message may leak. > > > Section 5 > > Same comments as above about a comma, and naming the Hash output. Noted. > > > Section 6 > > it is possible to implement it at the application layer. TLS > implementations supporting the use of exported authenticators MUST > provide application programming interfaces by which clients and > servers may request and verify exported authenticator messages. > > Some people will complain that the MUST is not enforcable by the peer. > Perhaps saying why we want that property would help, though. Good point. I think a SHOULD is more appropriate because the existence of the API is not enforceable by the peer. > > > > o the connection is TLS 1.2 and the extended master secret [RFC7627] > was not used > > nit: "extension", "negotiated" Will add. > > > Section 6.1 > > The "request" API takes as input: > > o certificate_request_context (from 0 to 255 bytes) > > How do I pick this context value? Is it always going to be input from > the application layer or might I need to pick something (randomly) > within the TLS stack? Application layer. > > > o set of extensions to include (this MUST include > signature_algorithms) > > It returns an authenticator request, which is a sequence of octets > that includes a CertificateRequest message. > > "includes" or "is"/"comprises"? Comprises. Changed. > > Section 6.3 > > The "authenticate" takes as input: > > nit: "API" Will add. > > > o a signer (either the private key associated with the certificate, > or interface to perform private key operation) for each chain > > If I'm doing a spontaneous server-driven EA but I have multiple possible > chains I could use, is there guidance to give about who should do the > picking (application vs. TLS stack) and what the choice should be? I don't think TLS provides any guidance, I don't think we need to either. > > > o an optional authenticator request or certificate_request_context > (from 0 to 255 bytes) > > Why the choice? This could be phrased better. The authenticator needs a certificate_request_context, so you can send it explicitly (spontaneous) or extract it from the authenticator request. Removing optional fixes this. > > > It returns either the exported authenticator or an empty > authenticator as a sequence of octets. It is RECOMMENDED that the > logic for selecting the certificates and extensions to include in the > exporter is implemented in the TLS library. Implementing this in the > TLS library lets the implementer take advantage of existing extension > and certificate selection logic. > > Also to more easily remember what extensions were in CH, right? Yes. > > > It is also possible to implement this API outside of the TLS library > using TLS exporters. This may be preferable in cases where the > application does not have access to a TLS library with these APIs or > when TLS is handled independently of the application layer protocol. > > It's harder to remember what extensions were sent in the ClientHello in > this case, though. Right. There might be a need for another API to expose the set of client hello extensions that were present. > > > Section 6.4 > > What do we do if a triggered and spontaneous EA race, w.r.t. the input > to the validation process. Do we need to check the context that we're > trying to validate? Do you mean if they both have the same context should this API fail for the second one? We don't explicitly fail if the context is repeated here. We should spell out what happens: The API MUST return a failure if the certificate_request_context of the authenticator was used in a previously validated authenticator. > > It returns the certificate chain and extensions and a status to > indicate whether the authenticator is valid or not. If the > authenticator was empty - that is, it did not contain a certificate - > the certificate chain will contain no certificates. > > Should we say what we expect the caller to be doing with the certificate > chain? I don't think it's necessary. > > Also, is an empty authenticator going to be considered "valid"? Yes. > > > Section 8 > > The Certificate/Verify/Finished pattern intentionally looks like the > TLS 1.3 pattern which now has been analyzed several times. In the > case where the client presents an authenticator to a server, [SIGMAC] > presents a relevant framework for analysis. > > Why is it only in that case? I guess it covers both. How about: The Certificate/Verify/Finished pattern intentionally looks like the TLS 1.3 pattern which now has been analyzed several times. For example, [SIGMAC] presents a relevant framework for analysis. > > > o This property makes it difficult to formally prove that a server > is jointly authoritative over multiple certificates, rather than > individually authoritative over each. > > I mentioned this already, but these difficulties should be mentioned > earlier/throughout, and we should think about providing some usage > guidance for use patterns believed to be safe. > > o There is no indication in the TLS layer about which point in time > an authenticator was computed. Any feedback about the time of > creation or validation of the authenticator should be tracked as > part of the application layer semantics if required. > > IIUC, all we know is that it's tied to this connection, plus the > semantics of whatever additional data the application put into the > context field. Should we say that more explicitly? Yes. I like that phrasing. At the end of the paragraph before the bullets: Authenticators are independent and unidirectional. There is no explicit state change inside TLS when an authenticator is either created or validated. The application in possession of a validated authenticator can rely on any semantics associated with data in the certificate_request_context. Nick --00000000000004bb900587b1b3ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ben,

Thank you for the thorough review. I've added res= ponses/comments inline and a PR to the spec=C2=A0https://github.com/tlswg/tls-= exported-authenticator/pull/46. Feel free to respond in the PR for spec= ific changes or on this thread for structural comments.

On Tue, Apr 23, 2019 at 11:21 AM Benjamin Kaduk <kaduk@mit.edu> wrote:
>
= > Hi all,
>
> I don't think there's anything earth-s= hattering in here; mostly just places
> where we can tighten things u= p before it gets to a broader set of
> reviewers.
>
> Tha= nks!
>
> -Ben
>
> Abstract, Introduction
>> Maybe s/other party/peer/?

How about:

This document pro= vides a way to authenticate one party of a Transport
Layer Security (TLS= ) communication to its peer using a certificate

> Section 1
&g= t;
> =C2=A0 =C2=A0This document provides a way to authenticate one pa= rty of a Transport
> =C2=A0 =C2=A0Layer Security (TLS) communication = to another using a certificate
> =C2=A0 =C2=A0after the session has b= een established.=C2=A0 This allows both the client
> =C2=A0 =C2=A0and= server to prove ownership of additional identities at any time
> =C2= =A0 =C2=A0after the handshake has completed.=C2=A0 This proof of authentica= tion can
> =C2=A0 =C2=A0be exported and transmitted out of band from = one party to be
> =C2=A0 =C2=A0validated by the other party.
><= br>> We need to be careful about what exactly is being proved when, and = how it
> synchronizes (or doesn't) with other events/data.
>= ; This will be a general theme throughout...
>
> =C2=A0 =C2=A0m= ultiple identities - =C2=A0Endpoints that are authoritative for multiple> =C2=A0 =C2=A0 =C2=A0 identities - but do not have a single certificat= e that includes
> =C2=A0 =C2=A0 =C2=A0 all of the identities - can au= thenticate with those identities
> =C2=A0 =C2=A0 =C2=A0 over a single= connection.
>
> (The RFC Editor will do two-hyphen em dashes.)=
> I didn't go back and reread the formal analysis that Jonathan = sent out,
> but my recollection was that the semantics around being &= quot;jointly
> authoritative" over multiple identities are quite= subtle, and that the
> wording here may be doing the reader a disser= vice.


Here's a suggested edit:
can authenticate with thos= e identities over a single connection ->
can authenticate additional = identities over a single connection

Jonathan's analysis showed t= hat the protocol provides "joint authentication" between the cert= ificate used in the handshake and one added as an EA. It does not provide &= quot;joint authentication" between two EAs. That's a subtle point,= but I think it maps cleanly to this text.

=C2=A0
>
>>
> =C2=A0 =C2=A0This document intends to replace much of the fun= ctionality of
> =C2=A0 =C2=A0renegotiation in previous versions of TL= S.=C2=A0 It has the advantages
> =C2=A0 =C2=A0over renegotiation of n= ot requiring additional on-the-wire changes
> =C2=A0 =C2=A0during a c= onnection.=C2=A0 For simplicity, only TLS 1.2 and later are
> =C2=A0 = =C2=A0supported.
>
> Well, renegotiation does many things.=C2= =A0 We need to say why we claim that
> renegotiation was widely used = and for what purpose(s), and only then say
> that we provide an alter= native.
> Also, the wording about "previous versions of TLS"= ; is pretty vague -- is
> it intended to be "prior to TLS 1.3&qu= ot;?


Very good point.

How about:
=C2=A0 Versions of TL= S prior to TLS 1.3 used renegotiation as a way to enable
=C2=A0 post-han= dshake client authentication given an existing TLS connection.
=C2=A0 Th= e mechanism described in this document may be used to replace the
=C2=A0= post-handshake authentication functionality provided by renegotiation.
= =C2=A0 Unlike renegotiation, exported Authenticator-based post-handshake=C2=A0 authentication does not require any on-the-wire changes.=C2=A0 For = simplicity,
=C2=A0 only TLS 1.2 and later are supported.
=C2=A0
&g= t;
>
>
> =C2=A0 =C2=A0Post-handshake authentication is de= fined in TLS 1.3, but it has the
> =C2=A0 =C2=A0disadvantage of requi= ring additional state to be stored in the TLS
> =C2=A0 =C2=A0state ma= chine and it composes poorly with multiplexed connection
> =C2=A0 =C2= =A0protocols like HTTP/2 [RFC7540].=C2=A0 It is also only available for
= >
> We should probably be more explicit about "composes poorl= y" being due to
> the authentication not being tied to a specifi= c event at the higher
> layer (among other things).


How ab= out:
=C2=A0 =C2=A0Post-handshake authentication is defined in TLS 1.3, b= ut it has the
=C2=A0 =C2=A0disadvantage of requiring additional state to= be stored in the TLS
=C2=A0 =C2=A0state machine.=C2=A0 Furthermore, the= authentication boundaries of TLS
=C2=A0 =C2=A01.3 post-handshake authen= tication align with TLS record boundaries,
=C2=A0 =C2=A0which are often = not aligned with the authentication boundaries of the
=C2=A0 =C2=A0highe= r-layer protocol. For example, multiplexed connection protocols
=C2=A0 = =C2=A0like HTTP/2 [RFC7540] do not have a notion of which TLS record
=C2= =A0 =C2=A0a given message is a part of.

>
>
> Sectio= n 3
>
>
> =C2=A0 =C2=A0The authenticator request is a str= uctured message that can be
> =C2=A0 =C2=A0exported from either party= of a TLS connection.=C2=A0 It can be
> =C2=A0 =C2=A0transmitted to t= he other party of the TLS connection at the
> =C2=A0 =C2=A0applicatio= n layer.=C2=A0 The application layer protocol used to send the
> =C2= =A0 =C2=A0authenticator SHOULD use TLS as its underlying transport to keep = the
> =C2=A0 =C2=A0request confidential.
>
> Also to indi= cate which TLS connection to pull key material from?

How about:
= =C2=A0 =C2=A0The authenticator request is a structured message that can be<= br>=C2=A0 =C2=A0created by either party of a TLS connection using data expo= rted
=C2=A0 =C2=A0from that connection.

>
> =C2=A0 =C2= =A0This message does not include the TLS record layer and is therefore
&= gt; =C2=A0 =C2=A0not encrypted with a handshake key.
>
> We sho= uld probably reword this -- "include the TLS record layer" is
= > going to confuse people.=C2=A0 It may be as simple as just adding &quo= t;framing".

How about:
=C2=A0 =C2=A0This message does not in= clude any TLS framing and is
=C2=A0 =C2=A0not encrypted with a handshake= key.
=C2=A0
>
>
> =C2=A0 =C2=A0The CertificateRequest= is used to define the parameters in a request
> =C2=A0 =C2=A0for an = authenticator.=C2=A0 The definition for TLS 1.3 is:
>
> =C2=A0 = =C2=A0 =C2=A0 struct {
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0opaque cer= tificate_request_context<0..2^8-1>;
> =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Extension extensions<2..2^16-1>;
> =C2=A0 =C2=A0 =C2= =A0 } CertificateRequest;
>
> I think we need some filler parag= raph in here noting that we re-use the
> data structure but assign sl= ightly different meanings to the fields ("as
> follows") --= otherwise it sounds like we're just repeating the whole
> defini= tion including field descriptions, which we clearly are not
> ("= [t]his value is unrelated to the certificate_request_context used in
>= ; post-handshake authentication").
>
>
> =C2=A0 =C2= =A0 =C2=A0 from pre-computing valid authenticators.=C2=A0 This value is unr= elated
> =C2=A0 =C2=A0 =C2=A0 to the certificate_request_context used= in post-handshake
> =C2=A0 =C2=A0 =C2=A0 authentication and collisio= ns do not need to be avoided.
>
> This text seems to invite the= reader to ask "collisions between what".
> Perhaps we shou= ld just say "there is no need to ensure uniqueness
> between val= ues used in post-handshake authentication and values used for
> expor= ted authenticators".=C2=A0 Though if we do that, maybe we want to foll= ow
> up by reiterating the need for uniqueness within each class on i= ts own.

I think it's important to note that this *is* a recap of= the CertificateRequest
message in TLS 1.3. Maybe it would be clear if t= he same or similar description
was used.

How about an introductio= n:
=C2=A0 =C2=A0This message reuses the structure to the CertificateRequ= est message in [TLS13].
=C2=A0 =C2=A0The uniqueness requirements of the= certificate_request_context apply
=C2=A0 =C2=A0only to CertificateReque= st messages that are used as part of authenticator requests.
=C2=A0 =C2= =A0There is no impact if the value of a certificate_request_context used in= an authenticator
=C2=A0 =C2=A0request matches the value of a certificat= e_request_context in the handshake or
=C2=A0 =C2=A0in a post-handshake m= essage.

And then a shorter description:
=C2=A0 =C2=A0message.=C2= =A0 A certificate_request_context value MUST be unique for
=C2=A0 =C2=A0= each authenticator request within the scope of a connection
=C2=A0 =C2= =A0(preventing replay and context confusion).=C2=A0 The
=C2=A0 =C2=A0cer= tificate_request_context SHOULD be chosen to be unpredictable
=C2=A0 =C2= =A0to the peer (e.g., by randomly generating it) in order to prevent
=C2= =A0 =C2=A0an attacker who has temporary access to the peer's private ke= y
=C2=A0 =C2=A0from pre-computing valid authenticators. =C2=A0
=C2=A0=
>
>
>
> =C2=A0 =C2=A0extensions: =C2=A0The extensi= ons that are allowed in this structure
> =C2=A0 =C2=A0 =C2=A0 include= the extensions defined for CertificateRequest messages
> =C2=A0 =C2= =A0 =C2=A0 defined in Section 4.2. of [TLS13] and the server_name [RFC6066]=
> =C2=A0 =C2=A0 =C2=A0 extension, which is allowed for client-genera= ted authenticator
> =C2=A0 =C2=A0 =C2=A0 requests.
>
> Do= we need to create a new "message type" for the "TLS 1.3&quo= t; column in
> the registry
> (https://www.iana.org/assignments/tls-extensiontype-values/tls-e= xtensiontype-values.xhtml)
> for future extensibility?

Thi= s should support the same extensions supported by the corresponding message= s in TLS.

>
>
> Section 4
>
> =C2= =A0 =C2=A0An authenticator message can be constructed by either the client = or
> =C2=A0 =C2=A0the server given an established TLS connection, a c= ertificate, and a
> =C2=A0 =C2=A0corresponding private key.=C2=A0 Cli= ents MUST NOT send an authenticator
> =C2=A0 =C2=A0without a precedin= g authenticator request; for servers an
> =C2=A0 =C2=A0authenticator = request is optional.=C2=A0 The authenticator uses the
>
> I thi= nk at this point in the document we haven't indicated what context
&= gt; value to use for unsolicited exported authenticators from the server.> Do we want to say something here?

Sure. We can say that it is= chosen by the server here, then later the uniqueness requirement is stated= . Text:
=C2=A0 =C2=A0corresponding private key.=C2=A0 Clients MUS= T NOT send an authenticator
=C2=A0 =C2=A0without a preceding authenticat= or request; for servers an
=C2=A0 =C2=A0authenticator request is optiona= l.=C2=A0 For authenticators that do not correspond
=C2=A0 =C2=A0to authe= nticator requests, the certificate_request_context is chosen by
=C2=A0 = =C2=A0the server.

>
>
> Section 4.1
>
> = =C2=A0 =C2=A0The context_value used for the exporter is empty (zero length)= for
> =C2=A0 =C2=A0all four values.=C2=A0 The length of the exported= value is equal to the
>
> When I first read this I felt a need= to think through the consequences
> of using the empty context_value= here.=C2=A0 A statement to the effect of
> "the exporter value = is used as a standard API to obtain a value that
> includes the TLS h= andshake transcript hash.=C2=A0 There is no need to include
> additio= nal context information at this stage, since the
> application-suppli= ed context is included in the actual authenticator
> object" wou= ld probably alleviate the concerns of many readers.

Good addition. H= ow about:
=C2=A0 =C2=A0The context_value used for the exporter is empty = (zero length) for
=C2=A0 =C2=A0all four values.=C2=A0 There is no need t= o include additional context
=C2=A0 =C2=A0information at this stage sinc= e the application-supplied context
=C2=A0 is included in the authenticat= or itself. The length of the exported
=C2=A0 value is equal to the...=C2=A0
>
>
> =C2=A0 =C2=A0length of the output of the ha= sh function selected in TLS for the
> =C2=A0 =C2=A0pseudorandom funct= ion (PRF).=C2=A0 Cipher suites that do not use the TLS
> =C2=A0 =C2= =A0PRF MUST define a hash function that can be used for this purpose or
= >
> Process-wise this is not great wording, seemingly attempting t= o bind the
> specifications of (already extant?) TLS ciphers to do mo= re work.=C2=A0 It's
> probably better to phrase it like "exp= orted authenticators cannot be
> used with cipher suites that do not = use the TLS PRF and have not defined
> a hash function for this purpo= se".

Good simplification, I'll take it:
=C2=A0 = =C2=A0length of the output of the hash function selected in TLS for the
= =C2=A0 =C2=A0pseudorandom function (PRF).=C2=A0 Exported authenticators can= not be
=C2=A0 =C2=A0used with cipher suites that do not use the TLS PRF = and have not defined
=C2=A0 =C2=A0a hash function for this purpose. Call= this hash function the authenticator hash.

The last line was added = to make references to this hash easier.

>
>
> =C2=A0 = =C2=A0If the connection is TLS 1.2, the master secret MUST have been
>= ; =C2=A0 =C2=A0computed with the extended master secret [RFC7627] to avoid = key
> =C2=A0 =C2=A0synchronization attacks.
>
> Let's= rephrase this as "Exported Authenticators MUST NOT be generated or> accepted on connectons not using the extended master secret [RFC7627]=
> extension, to avoid key synchronization attacks", to be very = explicit
> about the prohibited behavior.

Agreed.

>
>
> section 4.2
>
> =C2=A0 =C2=A0If an = authenticator request is present, the extensions used to guide
> =C2= =A0 =C2=A0the construction of these messages are taken from the authenticat= or
> =C2=A0 =C2=A0request.=C2=A0 Unrecognized extensions MUST be igno= red.=C2=A0 If the
> =C2=A0 =C2=A0certificate_request_context from the= authenticator request has
> =C2=A0 =C2=A0already been used in the co= nnection, then no authenticator should be
>
> What does "u= sed" mean?

How about:
=C2=A0 =C2=A0If the peer creating the = certificate_request_context has already created or
=C2=A0 =C2=A0correctl= y validated an authenticator with the same value, then no authenticator
= =C2=A0
>
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Only servers can provide an
> =C2=A0 =C2=A0au= thenticator without a corresponding request. =C2=A0[...]
>
> Th= is statement duplicates a requirement already stated above.

We can s= afely remove this line.

>
>
> =C2=A0 =C2=A0Cli= entHello extensions are used to determine permissible extensions
> = =C2=A0 =C2=A0in the Certificate message.
>
> I'd suggest re= iterating the "negotiation" model for extensions, and that
>= ; you generally can't send something in a response that you didn't = receive
> in a request (with, of course, the hardcoded exceptions lis= ted in the
> initial spec for that functionality).

Not sure th= e right way to word this. Here's a shot:
=C2=A0 =C2=A0ClientHello ex= tensions are used to determine permissible extensions
=C2=A0 =C2=A0in th= e Certificate message.=C2=A0 This follows the general model for
=C2=A0 = =C2=A0extensions in TLS in which extensions can only be included
=C2=A0 = =C2=A0as part of a Certificate message if they were previously sent as
= =C2=A0 =C2=A0part of a CertificateRequest message or ClientHello message.
>
>
> Section 4.2.1
>
> =C2=A0 =C2=A0In ad= dition to "signature_algorithms" and
> =C2=A0 =C2=A0"s= ignature_algorithms_cert", the "server_name" [RFC6066],
&= gt; =C2=A0 =C2=A0"certificate_authorities" (Section 4.2.4. of [TL= S13]), and
> =C2=A0 =C2=A0"oid_filters" (Section 4.2.5. of = [TLS13]) extensions are used to
> =C2=A0 =C2=A0guide certificate sele= ction.=C2=A0 The extensions, or others that might
> =C2=A0 =C2=A0affe= ct certificate selection, are taken from the authenticator
> =C2=A0 = =C2=A0request if present, or the TLS handshake if not.
>
> The = text about "taken from the authenticator request if present, or the> TLS handshake if not" seems to be duplicating previous discussio= ns.
>
> Maybe go with "commonly used [to guide certifciate= selection]"?=C2=A0 We
> don't limit what can be used for th= at purpose in core spec, IIRC.

How about we just remove that sentenc= e?

>
>
> I'm a little reluctant to bring t= his up, as it's fairly tangential to
> this document, but there s= eems to be some general disagreement in the
> community about whether= the SNI usage model is a proper "negotiation",
> where the= recipient has to ack the offered value in order for both
> parties t= o agree what server name is in use, versus an assertive model
> where= the sender just says "this is who I'm trying to talk to" and=
> decides from the received certificate whether that's the case.=
> But it doesn't look like we have a way to echo back the accept= ed SNI in
> this message flow....
>
> =C2=A0 =C2=A0Altern= ative certificate formats such as [RFC7250] Raw Public Keys are
> =C2= =A0 =C2=A0not supported in this version of the specification.
>
&g= t; Even if we call out some things that aren't supported, we probably s= till
> want to explicitly state what format we do support.

Let= 's use:
=C2=A0 =C2=A0Only the X509 certificate type in [TLS13] is su= pported.
=C2=A0 =C2=A0Alternative certificate formats such as [RFC7250] = Raw Public Keys are
=C2=A0 =C2=A0not supported in this version of the sp= ecification.
=C2=A0
>
>
> =C2=A0 =C2=A0If an authentic= ator request was provided, the Certificate message
> =C2=A0 =C2=A0MUS= T contain only extensions present in the authenticator request.
> =C2= =A0 =C2=A0Otherwise, the Certificate message MUST contain only extensions> =C2=A0 =C2=A0present in the TLS handshake.
>
> "Pre= sent in the TLS handshake" could mean SH or EE, too (but we just
&g= t; mean CH).=C2=A0 Also, this is the third time we say that!

If we&#= 39;re not exactly repeating anymore since the earlier statement only applie= s to extensions, and this to the certificate itself. I'll re-word to ma= ke sure it's specific to the Certificate message:
=C2=A0= =C2=A0If an authenticator request is present, the signature algorithm MUST= be chosen
=C2=A0 =C2=A0from one of the signature schemes present= in the authenticator request.=C2=A0 Otherwise, the
=C2=A0 =C2=A0= signature algorithm used should be chosen from the "signature_algorith= ms" sent
=C2=A0 =C2=A0by the peer in the TLS ClientHello.

>
>
> Section 4.2.2
>
> =C2=A0= =C2=A0If an authenticator request is present, the signature algorithm MUST=
> =C2=A0 =C2=A0be chosen from one of the signature schemes in the au= thenticator
> =C2=A0 =C2=A0request.=C2=A0 Otherwise, the signature al= gorithm used should be chosen
> =C2=A0 =C2=A0from the "signature= _algorithms" sent by the peer in the TLS
> =C2=A0 =C2=A0handshak= e.
>
> This text could probably be tightened up.=C2=A0 Specific= ally, we mean in the
> CH if we are falling back to the handshake val= ues, and I don't think we
> say what to do if we're using TLS= 1.2 and "signature_algorithms" wasn't
> sent in the Cl= ientHello.

Proposed change:
=C2=A0 =C2=A0Otherwise, the signature= algorithm used should be chosen
=C2=A0 =C2=A0from the "signature_a= lgorithms" sent by the peer in the ClientHello of the TLS
=C2=A0 = =C2=A0handshake. There are no available signature algorithms, then no
= =C2=A0 =C2=A0authenticator should be constructed.
=C2=A0
>
>=
> =C2=A0 =C2=A0Where Hash is the hash function negotiated by TLS.=C2= =A0 If the
> =C2=A0 =C2=A0authenticator request is not present, it is= omitted from this
> =C2=A0 =C2=A0construction (that is, it is zero l= ength).
>
> Above, we say that this Hash could be defined on a = per-ciphersuite
> basis post-facto; does this text need to be changed= to be consistent?

Yes. Change:
=C2=A0 =C2=A0 Where Hash i= s the authenticator hash defined in section 4.1.

>
> =C2=A0= =C2=A0failed CertificateVerify validation, it may be helpful for the
&g= t; =C2=A0 =C2=A0application to confirm that both peers share the same conne= ction
> =C2=A0 =C2=A0using a value derived from the connection secret= s before taking a
> =C2=A0 =C2=A0user-visible action.
>
>= We may want to define a new exporter for that, here, to keep people from> rolling their own custom (read: broken) scheme.

Hmm. Maybe th= at should be a separate spec? I'm not sure we should add additional mec= hanisms of this sort into this spec.=C2=A0
=C2=A0
>
>
>= ; Also, we could say something about needing to identify (by context?)
&= gt; which TLS connection to use for a given EA validation...

I'm= not sure we need to be prescriptive about this. It should be clear which c= onnection is used from the validate/authenticate API (noticed this was miss= ing and added it in the PR).

>
>
> Section 4.2.3
&= gt;
> Maybe give the hash output a good name so we don't get conf= used about
> Hash vs. HMAC?
>
> =C2=A0 =C2=A0The HMAC is = computed using the same hash function using the Finished
> =C2=A0 =C2= =A0MAC Key as a key.
>

Change:
=C2= =A0 =C2=A0 The HMAC is computed using the authenticator hash with the Finis= hed=C2=A0MAC Key as a key.

>
>
> co= mma after "function"?
>
> Section 4.2.4
>
&g= t; Do we want to reiterate that the record layer framing is not used?
Ok:
=C2=A0 =C2=A0This message does not include any TLS framing.=

>
>
> =C2=A0 =C2=A0A given authenticator can = be validated by checking the validity of
> =C2=A0 =C2=A0the Certifica= teVerify message given the authenticator request (if
> =C2=A0 =C2=A0u= sed) and recomputing the Finished message to see if it matches.
>
= > "can be" is not very strong language; do we want to be more = proscriptive
> about what needs to be done for proper validation?
=
Sure:
=C2=A0 =C2=A0An authenticator is valid if the CertificateVerif= y message is correctly constructed given the authenticator request (if
= =C2=A0 =C2=A0used) and the Finished message matches the expected value.=C2= =A0 When validating an authenticator, a constant-time
=C2=A0 =C2=A0compa= rison SHOULD be used.
>
>
> Also, is a constant time comp= arison going to be needed?

Yes, I think so. Otherwise, some bits of = the correct finished message may leak.
=C2=A0
>
>
> Se= ction 5
>
> Same comments as above about a comma, and naming th= e Hash output.

Noted.=C2=A0

>
>
> Secti= on 6
>
> =C2=A0 =C2=A0it is possible to implement it at the app= lication layer.=C2=A0 TLS
> =C2=A0 =C2=A0implementations supporting t= he use of exported authenticators MUST
> =C2=A0 =C2=A0provide applica= tion programming interfaces by which clients and
> =C2=A0 =C2=A0serve= rs may request and verify exported authenticator messages.
>
> = Some people will complain that the MUST is not enforcable by the peer.
&= gt; Perhaps saying why we want that property would help, though.

Goo= d point. I think a SHOULD is more appropriate because the existence of the = API is not enforceable by the peer.
=C2=A0
>
>
>
&g= t; =C2=A0 =C2=A0o =C2=A0the connection is TLS 1.2 and the extended master s= ecret [RFC7627]
> =C2=A0 =C2=A0 =C2=A0 was not used
>
> n= it: "extension", "negotiated"

Will add.

<= /div>
>
>
> Section 6.1
>
> =C2=A0 =C2=A0The= "request" API takes as input:
>
> =C2=A0 =C2=A0o =C2= =A0certificate_request_context (from 0 to 255 bytes)
>
> How do= I pick this context value?=C2=A0 Is it always going to be input from
&g= t; the application layer or might I need to pick something (randomly)
&g= t; within the TLS stack?

Application layer.=C2=A0

>=
>
> =C2=A0 =C2=A0o =C2=A0set of extensions to include (this MU= ST include
> =C2=A0 =C2=A0 =C2=A0 signature_algorithms)
>
&g= t; =C2=A0 =C2=A0It returns an authenticator request, which is a sequence of= octets
> =C2=A0 =C2=A0that includes a CertificateRequest message.>
> "includes" or "is"/"comprises"?=

Comprises. Changed.
=C2=A0
>
> Section 6.3
>> =C2=A0 =C2=A0The "authenticate" takes as input:
>> nit: "API"

Will add.=C2=A0

>
>= ;
> =C2=A0 =C2=A0o =C2=A0a signer (either the private key associated = with the certificate,
> =C2=A0 =C2=A0 =C2=A0 or interface to perform = private key operation) for each chain
>
> If I'm doing a sp= ontaneous server-driven EA but I have multiple possible
> chains I co= uld use, is there guidance to give about who should do the
> picking = (application vs. TLS stack) and what the choice should be?

I don'= ;t think TLS provides any guidance, I don't think we need to either.

>
>
> =C2=A0 =C2=A0o =C2=A0an optional authentic= ator request or certificate_request_context
> =C2=A0 =C2=A0 =C2=A0 (f= rom 0 to 255 bytes)
>
> Why the choice?

This could be ph= rased better. The authenticator needs a certificate_request_context, so you= can send it explicitly (spontaneous) or extract it from the authenticator = request. Removing optional fixes this.
=C2=A0
>
>
> = =C2=A0 =C2=A0It returns either the exported authenticator or an empty
&g= t; =C2=A0 =C2=A0authenticator as a sequence of octets.=C2=A0 It is RECOMMEN= DED that the
> =C2=A0 =C2=A0logic for selecting the certificates and = extensions to include in the
> =C2=A0 =C2=A0exporter is implemented i= n the TLS library.=C2=A0 Implementing this in the
> =C2=A0 =C2=A0TLS = library lets the implementer take advantage of existing extension
> = =C2=A0 =C2=A0and certificate selection logic.
>
> Also to more = easily remember what extensions were in CH, right?

Yes.=C2=A0
<= div>
>
>
> =C2=A0 =C2=A0It is also possible to implement = this API outside of the TLS library
> =C2=A0 =C2=A0using TLS exporter= s.=C2=A0 This may be preferable in cases where the
> =C2=A0 =C2=A0app= lication does not have access to a TLS library with these APIs or
> = =C2=A0 =C2=A0when TLS is handled independently of the application layer pro= tocol.
>
> It's harder to remember what extensions were sen= t in the ClientHello in
> this case, though.

Right. There migh= t be a need for another API to expose the set of client hello extensions th= at were present.

>
>
> Section 6.4<= br>>
> What do we do if a triggered and spontaneous EA race, w.r.t= . the input
> to the validation process.=C2=A0 Do we need to check th= e context that we're
> trying to validate?

Do you mean if = they both have the same context should this API fail for the second one? We= don't explicitly fail if the context is repeated here. We should spell= out what happens:
=C2=A0 =C2=A0The API MUST return a failur= e if the certificate_request_context of the authenticator was used in a
=C2=A0 =C2=A0previously validated authenticator.
>
> =C2=A0 =C2=A0It returns the certificate chain and extensions = and a status to
> =C2=A0 =C2=A0indicate whether the authenticator is = valid or not.=C2=A0 If the
> =C2=A0 =C2=A0authenticator was empty - t= hat is, it did not contain a certificate -
> =C2=A0 =C2=A0the certifi= cate chain will contain no certificates.
>
> Should we say what= we expect the caller to be doing with the certificate
> chain?
I don't think it's necessary.
=C2=A0
>
> Also, is = an empty authenticator going to be considered "valid"?

Yes= .
=C2=A0
>
>
> Section 8
>
> =C2=A0 =C2=A0= The Certificate/Verify/Finished pattern intentionally looks like the
>= ; =C2=A0 =C2=A0TLS 1.3 pattern which now has been analyzed several times.= =C2=A0 In the
> =C2=A0 =C2=A0case where the client presents an authen= ticator to a server, [SIGMAC]
> =C2=A0 =C2=A0presents a relevant fram= ework for analysis.
>
> Why is it only in that case?

I g= uess it covers both. How about:
=C2=A0 =C2=A0The Certificate/Verify/Fini= shed pattern intentionally looks like the
=C2=A0 =C2=A0TLS 1.3 pattern w= hich now has been analyzed several times. For example,
=C2=A0 =C2=A0[SIG= MAC] presents a relevant framework for analysis.

>
>
>= ; =C2=A0 =C2=A0o =C2=A0This property makes it difficult to formally prove t= hat a server
> =C2=A0 =C2=A0 =C2=A0 is jointly authoritative over mul= tiple certificates, rather than
> =C2=A0 =C2=A0 =C2=A0 individually a= uthoritative over each.
>
> I mentioned this already, but these= difficulties should be mentioned
> earlier/throughout, and we should= think about providing some usage
> guidance for use patterns believe= d to be safe.
>
> =C2=A0 =C2=A0o =C2=A0There is no i= ndication in the TLS layer about which point in time
> =C2=A0 =C2=A0 = =C2=A0 an authenticator was computed.=C2=A0 Any feedback about the time of<= br>> =C2=A0 =C2=A0 =C2=A0 creation or validation of the authenticator sh= ould be tracked as
> =C2=A0 =C2=A0 =C2=A0 part of the application lay= er semantics if required.
>
> IIUC, all we know is that it'= s tied to this connection, plus the
> semantics of whatever additiona= l data the application put into the
> context field.=C2=A0 Should we = say that more explicitly?

Yes. I like that phrasing. At the end of t= he paragraph before the bullets:
=C2=A0 =C2=A0Authenticators are in= dependent and unidirectional.=C2=A0 There is no explicit state change
=
=C2=A0 =C2=A0inside TLS when an authenticator is either created or val= idated.=C2=A0 The application in
=C2=A0 =C2=A0possession of a val= idated authenticator can rely on any semantics associated with data
=C2=A0 =C2=A0in the certificate_request_context.


Nick
--00000000000004bb900587b1b3ca-- From nobody Tue Apr 30 16:49: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 BA8DE1203E8 for ; Tue, 30 Apr 2019 16:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 QNmw1LTWvwcE for ; Tue, 30 Apr 2019 16:49:54 -0700 (PDT) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A27661200D8 for ; Tue, 30 Apr 2019 16:49:54 -0700 (PDT) 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 smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 44tytm3vmjzyPL; Wed, 1 May 2019 01:49:52 +0200 (CEST) X-purgate-ID: 152705::1556668192-00000214-3368DD79/0/0 X-purgate-size: 738 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 AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail07.wdf.sap.corp (Postfix) with ESMTPS id 44tytm1Tz8zGpC5; Wed, 1 May 2019 01:49:52 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 21F5C404C; Wed, 1 May 2019 01:49:52 +0200 (CEST) In-Reply-To: <7d37f7ca-e253-4c95-9cf7-2d16b0b6a0aa@www.fastmail.com> References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <2EF7433E-DB94-497F-80D7-2A060097261B@dukhovni.org> <5C3C015B-88B9-4502-861B-C59120B2F151@akamai.com> <7d37f7ca-e253-4c95-9cf7-2d16b0b6a0aa@www.fastmail.com> To: Martin Thomson Date: Wed, 1 May 2019 01:49:52 +0200 (CEST) CC: tls@ietf.org Reply-To: mrex@sap.com MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20190430234952.21F5C404C@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: Tue, 30 Apr 2019 23:49:57 -0000 Martin Thomson wrote: > On Sat, Apr 27, 2019, at 07:29, Viktor Dukhovni wrote: >> The sound-bite version is: first raise the ceiling, *then* the floor. > > Yep. We've done the ceiling bit twice now. > Once in 2008 when we published TLS 1.2 and then in 2018 > with the publication of TLS 1.3. I'd say we're overdue for the floor bit. Just that this rationale is a blatant lie. It is formally provable that from the three protocol versions: TLSv1.0, TLSv1.1, TLSv1.2 the weakest one is TLSv1.2, because of the royally stupid downgrade in the strength of digitally signed. Disabling TLSv1.0 will only result in lots of interop failures and pain, but no improvement in security. -Martin From nobody Tue Apr 30 17:35: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 6909F1201A9 for ; Tue, 30 Apr 2019 17:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Mx4AVXVBKFlg for ; Tue, 30 Apr 2019 17:35:24 -0700 (PDT) Received: from mail-yw1-xc41.google.com (mail-yw1-xc41.google.com [IPv6:2607:f8b0:4864:20::c41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD97F120189 for ; Tue, 30 Apr 2019 17:35:24 -0700 (PDT) Received: by mail-yw1-xc41.google.com with SMTP id n188so4727969ywe.2 for ; Tue, 30 Apr 2019 17:35:24 -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=/kL1ielmH7uXMkHuFoB2+WS7CHDTbshix6YGbkf9/Xs=; b=BCVe/UW0JjPZntaBVDoKFpTdYSla55AuqJF7eVierX+k+YHYG9ox3r5FVQ0QBT4/Ln mTaLvJuUMCUCN13C+O4MbOU9nwJBH3M7LBII6fQWl37drjJNSHIGiU9FP+Of6qGdMbTJ 6NrJNJCuhCczM1ZY3NVqPWXqt65VRV8ItIsEZijFsGa/YOHRytLh28FeCTqZaELeuYkq rukKzEydiKBLxLen4Iv1Cq3MKotH6UNxRITm1MIXD8GpTfBkSLxqhvdhHBu8yPSPAcAb q2aCQ6x6ICPl8txdiYyaOV8n5Qw1k5IJs+N/8Yi/lAcOQizbzFyzEiiDnmyGig1udWsG iLig== 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=/kL1ielmH7uXMkHuFoB2+WS7CHDTbshix6YGbkf9/Xs=; b=qHQwf3XHr1Er38sOFsAsj33LIK4m+TUxgxGcPTYHepUxIhp7+F4cNXRt4VaSWsELFk zmO5cHiaJouZt8o9zcoUxZjB3ojlAqsmWiU7e6YJVMp1WhO4Qnt/2df4Ro0DnaPw2sF+ 40/ZteoSskNc/6fzHxB5VVex4QM/JlTWgJhsS1TEVzDf1hS+ADWKzI/0rNjTjNT+fdBE +mfP4b9syCuxRXhnnZFC4/x/LiNIyBd7ZftKui3xV8nIz5LzTACM3XirLQzDvNPrTIwx ptV1h1OF/IpbaoaTe+lf0MS879YPXJUeD7quP2nV+juJ29Yv+hTGbOYv2U+DLQp9SoJY GmOg== X-Gm-Message-State: APjAAAVUefnsNLAiRPx4nvMn6Xnh5Lk3Uo0LSIENreSuVPXKcYF0GW1X fh+0J4cEGS3LqbyZ+vDI7HqnbJpjBUjPjW+p3k0= X-Google-Smtp-Source: APXvYqybJwESutfL2G0isAOW7fyRegraKkljLxx95dcnBM/abW1KT+ctlsBTR/9UJpOXhwYTgCtrx46NiTQjuDmCvhc= X-Received: by 2002:a25:1f02:: with SMTP id f2mr59184882ybf.111.1556670923889; Tue, 30 Apr 2019 17:35:23 -0700 (PDT) MIME-Version: 1.0 References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <2EF7433E-DB94-497F-80D7-2A060097261B@dukhovni.org> <5C3C015B-88B9-4502-861B-C59120B2F151@akamai.com> <7d37f7ca-e253-4c95-9cf7-2d16b0b6a0aa@www.fastmail.com> <20190430234952.21F5C404C@ld9781.wdf.sap.corp> In-Reply-To: <20190430234952.21F5C404C@ld9781.wdf.sap.corp> From: =?UTF-8?Q?T=C3=B6ma_Gavrichenkov?= Date: Wed, 1 May 2019 03:35:00 +0300 Message-ID: To: mrex@sap.com Cc: Martin Thomson , "" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: Wed, 01 May 2019 00:35:27 -0000 On Wed, May 1, 2019 at 2:50 AM Martin Rex wrote: > It is formally provable Everything must be accounted for as provable until it's proved unless it's proved to be false. Do you possess an external (academic?) reference? -- T=C3=B6ma