From nobody Sat Feb 2 08:39:59 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 D97731200D7; Sat, 2 Feb 2019 08:39:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: kaduk@mit.edu, tls-chairs@ietf.org, cawood@apple.com, tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154912559785.18408.6365918337726013023.idtracker@ietfa.amsl.com> Date: Sat, 02 Feb 2019 08:39:57 -0800 Archived-At: Subject: [TLS] tls - Update to a Meeting Session Request for IETF 104 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2019 16:39:58 -0000 An update to a meeting session request has just been submitted by Christopher A. Wood, a Chair of the tls working group. --------------------------------------------------------- Working Group Name: Transport Layer Security Area Name: Security Area Session Requester: Christopher Wood Number of Sessions: 2 Length of Session(s): 2 Hours, 1 Hour Number of Attendees: 120 Conflicts to Avoid: First Priority: tokbind teep taps suit secdispatch saag stir rtcweb quic perc mls httpbis dnsop dispatch curdle cfrg acme uta git Second Priority: dprive ace Third Priority: tcpinc lamps sidrops People who must be present: Eric Rescorla Rich Salz Sean Turner Joseph A. Salowey Yoav Nir Benjamin Kaduk Christopher A. Wood Nick Sullivan Resources Requested: Special Requests: --------------------------------------------------------- From nobody Thu Feb 7 09:40: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 D865612D861 for ; Thu, 7 Feb 2019 09:39:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[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 lHq8LCOYwmt8 for ; Thu, 7 Feb 2019 09:39:58 -0800 (PST) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FDDA1295EC for ; Thu, 7 Feb 2019 09:39:58 -0800 (PST) Received: by mail-qk1-x730.google.com with SMTP id w204so451365qka.2 for ; Thu, 07 Feb 2019 09:39:58 -0800 (PST) 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=zfqQM0jYUnqvRe/9SB7h/qfeOHravwuS/4KiNvsG6BQ=; b=MvGvxtudTPfuGP1gD7frxibKy63Ab9jlRbYxHHILbGPw6W8CZjOC7yRcicJAlIQZ/o iRjUJum8eV5tKtJogZHs1Z/soPFEIJEOc2CygjPVvaIlHUvWEgv6/ghv4kkik936SlCA m42ljaButrXxLjhRwAqfzwdEuvtwhs7AsHQBo= 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=zfqQM0jYUnqvRe/9SB7h/qfeOHravwuS/4KiNvsG6BQ=; b=l2MOX9S4idKHeCL01+UB7qdTBC8gkiwv2/HI+aOPHv9fKfCXRvG2IswOpw39uLqQEO zWVsJT0GYj+lCMdQmT8IKxTR0oCODDITCq7hqypkCFYN5fx8kKsl4LqUmJ+MUnqr4xYD Lya/iwqsf4ks4nWlqSkCCUI78/iIMLVVGxyzItWWuWyGfBk7MgpdVH3C9fJ71xgjcY0j ZfsNmqSyszlujW8t34mPRqlVWsg1qZEpKfURUlmpnmYlc2XRFv8n5wgPEh5DsjA0yI1k IN1wjfUlPaHZ+skN/Z5F380uKXHLHMmSX6Md8oFkb1VPkiJdYcQWFxpBeL3IDh5YW3is 8o1A== X-Gm-Message-State: AHQUAubbaWToQFhDEwbuVWHYmnSLq4l4f/oK6KrOi4oWSAec90IPlgCx Z7BDrjma0qv+YUicfgckjURyEcuqbRE= X-Google-Smtp-Source: AHgI3Ib05XootuECcgg0LvIigWfQi84bAa3u47rIy2Un5dNTJTsuqcVNOuzWbaZii3bZnN6oJyZVTg== X-Received: by 2002:a37:4751:: with SMTP id u78mr12315363qka.280.1549561197008; Thu, 07 Feb 2019 09:39:57 -0800 (PST) Received: from [172.16.0.18] ([96.231.217.246]) by smtp.gmail.com with ESMTPSA id k55sm4537998qtc.53.2019.02.07.09.39.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Feb 2019 09:39:56 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-Id: Date: Thu, 7 Feb 2019 12:39:54 -0500 To: TLS List X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: [TLS] TLS@IETF104: Agenda Topics 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, 07 Feb 2019 17:40:00 -0000 The TLS WG will be meeting @ IETF 104 in Prague. To help the chairs get = a better handle on how much time we will need for our session, please = send in your agenda requests to tls-chairs@ietf.org. Along with your = request please provide an estimate for how much time you will need. Cheers, Chris, Joe, and Sean= From nobody Thu Feb 7 19:31:23 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB18130F1D for ; Thu, 7 Feb 2019 19:31:22 -0800 (PST) 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=TE7UkZLn; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=L8DnDVlK Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNfBgzY-5C6B for ; Thu, 7 Feb 2019 19:31:20 -0800 (PST) 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 5D5E3128B01 for ; Thu, 7 Feb 2019 19:31:20 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 2692E22089; Thu, 7 Feb 2019 22:31:19 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute1.internal (MEProxy); Thu, 07 Feb 2019 22:31:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:from:to:mime-version:content-transfer-encoding :content-type:date:subject; s=fm1; bh=VYs/XpX7mGLU4H+brhonOfog0F f4iGQRupyodE4lQ+o=; b=TE7UkZLnhHyB2jgxY2wWLLH8Qj77NSd+hI0qo0uQys r+g78JWmHflGN9p9TF5PUEawNUSfSorGe755yYQVHFpsOjPtSMpM9FS9yhq8Q2gH NZHefvyAvegOaP52srwINpQv4Nxm42nGJkaL6LhwHNEg21kIE9qgxYHup/6t4+Kh io8cPPR3LWZrguqYa62wbQ3LqPiDe7GZiXRbgkHLyTmii7Ultvvd67MwGAQNxr8a Jq4nMSYKuD7BVLoyhn1KAO1QVWMT1qUO77KTQCrDjV/nma7hKrAhwGqaCF/zxETF bvGE/y5mwaMqsUjuCTgF6KO/oWu16Ip0wx9ftICTFrpQ== 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=VYs/Xp X7mGLU4H+brhonOfog0Ff4iGQRupyodE4lQ+o=; b=L8DnDVlKRBWWGCOT25tNXg bdzm07ykFxJVcDolOAhtHeYPYldYJVFES8KrOpXXa/nWOj4O5PYpMuP6sI5puZ3W fS64daDyzRummhVnG9TEhVHK2+x9UNMpKWYhq/49YCSxOp6mx3uzRemOLLYPrBaQ 5fkltCu1XNMTl9GUs2u+l7ND5DQ7MPxMuhqQ/fn9X5FXdXcmMK+4Q2JY6NmbzI0U YMHCh7OJcBd1nugDqLiQ2W7+WX18UCVWIB54pJ+8F9lRbEV3r/asElIqFNjXN+4r lcdoJgiZT5PowbaEVtvf8ux+llcnJlSTIYtm3+pWe7ODfMEZveI0Q326ZgzWJkkA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrledugdehkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucenucfjughrpefkhffvggfgtgfofffusehtjeertdertdejnecuhfhrohhmpeforg hrthhinhcuvfhhohhmshhonhcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenucfr rghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvthenucevlh hushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 9822F9E595; Thu, 7 Feb 2019 22:31:18 -0500 (EST) Message-Id: <1549596678.898774.1653407000.2B2ACE8E@webmail.messagingengine.com> From: Martin Thomson To: tls@ietf.org, hkario@redhat.com MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-e6290ad1 Date: Fri, 08 Feb 2019 14:31:18 +1100 Archived-At: Subject: [TLS] Server validation of a second ClientHello 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, 08 Feb 2019 03:31:22 -0000 TLS 1.3 is pretty firm about what you can change in a second ClientHello. It lists a small set of allowed changes to extensions (cookie, PSK binder, key shares, early data, and padding). For the rest it says that nothing can change. So clearly a client is in the wrong if it changes, adds, or removes an extension that isn't on this list. The first question is whether a server should be required to check that only permitted changes are made to a second ClientHello. The second question is - if the server is not required to check for consistency - which ClientHello the server uses. The third question is - if we allow checking at all - what the consistency check looks like. My position is that the check cannot be mandatory, but we should allow servers to check. One feature that we put significant effort into supporting was the notion of a stateless HelloRetryRequest, which I believe to be incompatible with checking (or at best extraordinately inconvenient). With that answer in mind, if the second ClientHello might differ, I assert that the server uses that. Hubert observes that this behaviour is not specified at all, which is entirely true. I think that using the first ClientHello would be nonsensical, because the server needs to use the second ClientHello for those extensions that can change, like key share. If we require or allow checking - and I think that we should definitely allow a check - the details of the conditions under which a check might fail aren't completely obvious for new extensions. A new extension might be defined that has special handling in HelloRetryRequest, so it might be reasonable to allow new extensions to be changed. Conversely, we might assume that anything that changes is going to be present in the HelloRetryRequest. Therefore, only extensions that the server understands and includes in HelloRetryRequest can change. That's not true for the early data extension, which is removed after HelloRetryRequest without any requirement for a server indicating support, but we might assume that extensions in the core spec have special status in this regard. The simplest thing here seems to be a prohibition on checking unknown extensions for consistency between ClientHello1 and ClientHello2. A final observation about checking extensions: it's not clear that we require consistent extension ordering. If the key share extension changes, can it be reordered? Can unchanged extensions be reordered? Clearly neither results in a semantic change, but if a server that is required to check, might need to aggressively compress information about the first ClientHello in order to comply and extension ordering is an obvious thing to erase to save space in the cookie. From nobody Fri Feb 8 04:53: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 2BF0C12EB11 for ; Fri, 8 Feb 2019 04:53:55 -0800 (PST) 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 dXXg0Ea35udm for ; Fri, 8 Feb 2019 04:53:53 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1A011288BD for ; Fri, 8 Feb 2019 04:53:52 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4393212BB3; Fri, 8 Feb 2019 12:53:52 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.83]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7C49A60FDF; Fri, 8 Feb 2019 12:53:51 +0000 (UTC) From: Hubert Kario To: Martin Thomson Cc: tls@ietf.org Date: Fri, 08 Feb 2019 13:53:44 +0100 Message-ID: <3192766.6rApcoU5jf@pintsize.usersys.redhat.com> In-Reply-To: <1549596678.898774.1653407000.2B2ACE8E@webmail.messagingengine.com> References: <1549596678.898774.1653407000.2B2ACE8E@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3239363.Bl4TAJnl3i"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Fri, 08 Feb 2019 12:53:52 +0000 (UTC) Archived-At: Subject: Re: [TLS] Server validation of a second ClientHello 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, 08 Feb 2019 12:53:55 -0000 --nextPart3239363.Bl4TAJnl3i Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Friday, 8 February 2019 04:31:18 CET Martin Thomson wrote: > TLS 1.3 is pretty firm about what you can change in a second ClientHello.= =20 > It lists a small set of allowed changes to extensions (cookie, PSK binder, > key shares, early data, and padding). For the rest it says that nothing > can change. So clearly a client is in the wrong if it changes, adds, or > removes an extension that isn't on this list. >=20 > The first question is whether a server should be required to check that o= nly > permitted changes are made to a second ClientHello. given need for GREASE and two dozen flags across OpenSSL history for=20 workarounds for bugs in different implementations, the lesson seems to be t= hat=20 the receiving side should be as strict as it can (within protocol confines)= or=20 we risk making the non-conforming behaviour common =20 > The second question is - if the server is not required to check for > consistency - which ClientHello the server uses. >=20 > The third question is - if we allow checking at all - what the consistency > check looks like. >=20 > My position is that the check cannot be mandatory, but we should allow > servers to check. One feature that we put significant effort into > supporting was the notion of a stateless HelloRetryRequest, which I belie= ve > to be incompatible with checking (or at best extraordinately inconvenient= ). "extraordinarily inconvenient" is description of the process of implementin= g=20 any crypto and cryptographic protocols properly... =20 > With that answer in mind, if the second ClientHello might differ, I assert > that the server uses that. Hubert observes that this behaviour is not > specified at all, which is entirely true. I think that using the first > ClientHello would be nonsensical, because the server needs to use the > second ClientHello for those extensions that can change, like key share. And I say that when you have already parsed, verified and sanity-checked th= e=20 first set of extensions, it is much saner to reuse that work and only updat= e=20 the values that can change and ignore all other extensions... There are multiple ways to look at this, and given that the standard is ver= y=20 firm that the 2nd CH needs to be as similar to the first one as possible, i= t=20 is thus silent on which takes precedence in case they differ in general,=20 because they can't. =20 > If we require or allow checking - and I think that we should definitely > allow a check - the details of the conditions under which a check might > fail aren't completely obvious for new extensions. A new extension might > be defined that has special handling in HelloRetryRequest, so it might be > reasonable to allow new extensions to be changed. yes, and we already had discussion on this ML about this: if the extension= =20 needs to change (based on protocol definition), the server MUST include it = in=20 HRR to signal to client, "yes, I do know about it, you can update it" and=20 client MUST NOT change it otherwise =20 > The simplest thing here seems to be a prohibition on checking unknown > extensions for consistency between ClientHello1 and ClientHello2. that's definitely too harsh > A final observation about checking extensions: it's not clear that we > require consistent extension ordering. the reordering is not in the list of allowed changes listed by the RFC > If the key share extension changes, > can it be reordered? no > Can unchanged extensions be reordered?=20 no > Clearly > neither results in a semantic change, but if a server that is required to > check, might need to aggressively compress information about the first > ClientHello in order to comply and extension ordering is an obvious thing > to erase to save space in the cookie. the cookie can be up to 2^16 bytes long, even if client sends all 50=20 extensions and spaces them with unknown extensions between, that's at most = 20=20 bytes per extension =3D 1000 bytes total extra space needed in cookie (32 b= ytes=20 and 1600 bytes if you want to be very conservative) and that's the excessive case, in usual case the server will not have to de= al=20 with more than half a dozen unknown extensions =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 --nextPart3239363.Bl4TAJnl3i 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+dkqjRuAHS9fUFAlxde9gACgkQkqjRuAHS 9fXtUw//a3kjx47z/38o1U48BI75KkqgxmfGZ9gxKPOHk3ht5nxkEEVsSOplisu6 gY5TS7+ns/5jmseNHnH2cqb8tYEufVTrpCwMMT27q1QnD5bZVmq0u8mfYrPWvEiZ WTJ5kD9fXHI1ljGnpXZCRmTVeoHTZqBUGbERafVPgDUDGwFvnzttYWSO4ZP2wen3 ioh2i7uDHWQGg0wzx0MNf/jurUH7TOHZkbgfymKf0D66sE75Onz90zbp3n2Ongkd VYJ7/1JsF/eYyMrj9NDfYJm1q2qySFxtkjFveyUFnJBH4uywY28SEhraaNvMNBLy VJHxxi3aH380uhL67tNYPdhkrjqjI8qud1Tpc6iBMjWLlK4ZJt92E3e1U9/2UJ47 kAai3qRMISlBZV72Sq7Fo4Lpw4r2a1bjrOTklX103vny+WBTpV6L8FGIs/+b+Z79 7R6t4CkvhDTEuXlrFmvJ+cstK3+Wqp5rrtRuFONlWCePYAyaQaqrNPLwgddocfnv Xzzx/dp/1DQNKR6v4sz6c2VPC6CIU1lB90LHiNh9l2dlI74GHASBvIxoIQqXpgbN xqJ+PVXf5SuK1lW42lADuBZuWVbRZmgMIiX/dgN2qvdWbmB/s7HBu2bsy/f45Oof 6ZK9QQkPOEiC8OWHyvcleWXkMnULWpVEsPhz9HPuqBdntym8z5M= =yA96 -----END PGP SIGNATURE----- --nextPart3239363.Bl4TAJnl3i-- From nobody Fri Feb 8 08:58: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 97B38126C15 for ; Fri, 8 Feb 2019 08:58:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6PQ6M77f-xI for ; Fri, 8 Feb 2019 08:58:55 -0800 (PST) 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 D547A1200ED for ; Fri, 8 Feb 2019 08:58:54 -0800 (PST) Received: by mail-lj1-x22e.google.com with SMTP id f24-v6so3628534ljk.0 for ; Fri, 08 Feb 2019 08:58:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=m+xcqyU/CUURWgkrZXdVXA1XvtzNS6kRFZfAOzgHmZA=; b=SNnGTRppQTJ38dyAKHr1lTWwCpwxDNxMT6lYR15vi+7gjAKt7nGIM/UwxYO7s3rBAB ZNEX7D9ppJeafVv4H8nUzvOt0JmVikWcMlzOvy0AoRYt9uZ7FLlxKFdFFbPsXUpHNHDK ERGgagmGmsZoMt12Bj5CItix+xQ7HMfYUsGOAaDhfKKY7TfKh42yo6D8tR4g2ju40noI rMJsH5rs02HQPrNZoLFGJSeNNrtM6cMKiRJGzlAl4RmhslFBdG3vWMIoOvx0GQAjNJKQ 2sQLjGFFhofPIp9gkWTILFTwJjiZ8VB0unWkoQD4eUOQcqqLGF9Xitn+rnF9Jw608RBZ L+qg== 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=m+xcqyU/CUURWgkrZXdVXA1XvtzNS6kRFZfAOzgHmZA=; b=o8u8OIOgpyfYRt6ZEjfKavri4hTjxoeTmvPAO6ZeQZYp9JxyNdHW+7xKBxtdHz8Lce 13xf/Cdag0LA0n82lL4a25JAmCrRhT9O5p1XR09fhNUqoaUvFkdAhMxBr9EqBffx9+h/ v5QUmP13cPQYXHu+JmiCrlKlPBu2aKpoQ+7VvfCegdaU2lbvsPm3UD0KxCr59BzmzHCu 3bBBrjUU57hcD/M3l824FMOhw67twa6OmgO6DhDaQWg5j6tsADnRCLZmwRf80PD9f8Ji 0MvYoB3J/xK5WPBG1gwug1GfjHI2rVNLsfbktvgo35dC8mm4o3HjiwqC/JHtwPvUiyaH ODlw== X-Gm-Message-State: AHQUAuYe5UFHyVSivcvWc94lsDReNUXFVdAf8DlbNkp5lQwTrdgwBOBC klcqJk3kfsww4xz40IYtt1lexaDFuBUapMvZzBRqlA== X-Google-Smtp-Source: AHgI3IaQbIw+63hWG8MsRhiepc8BOo19ieX+ltoqq2iZvcX/T6OXqJW/ub8JggU+7Mg2VmOnyTcNnfqqojav/X61OzM= X-Received: by 2002:a2e:9001:: with SMTP id h1-v6mr9924440ljg.28.1549645132796; Fri, 08 Feb 2019 08:58:52 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Fri, 8 Feb 2019 08:58:12 -0800 Message-ID: To: Christopher Wood Cc: "" Content-Type: multipart/alternative; boundary="000000000000ab3663058164df91" Archived-At: Subject: Re: [TLS] Call for Adoption: TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key 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, 08 Feb 2019 16:58:58 -0000 --000000000000ab3663058164df91 Content-Type: text/plain; charset="UTF-8" I'd like to hear from some people who plan to implement and deploy this. Absent that, I'm not sure we should adopt it. Code points are free, so it doesn't need to be a TLS WG item unless the TLS WG and community are going to do substantial work on it. -Ekr On Fri, Jan 25, 2019 at 10:12 AM Christopher Wood < christopherwood07@gmail.com> wrote: > At the TLS@IETF103 session, there was interest in adopting > draft-housley-tls-tls13-cert-with-extern-psk as an experimental WG > item, provided that it's limited to external PSKs with certificates > for the initial handshake. This email is to determine whether there is > WG consensus to adopt this draft (as is) as a WG item. > > If you would like for this draft to become a WG document and you are > willing to review it as it moves through the process, then please let > the list know by 2359UTC 20180208. If you are opposed to this being a > WG document, please say so (and say why). > > Thanks, > Chris, Joe and Sean > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000ab3663058164df91 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'd like to hear from some people who plan to imp= lement and deploy this. Absent that, I'm not sure we should adopt it. C= ode points are free, so it doesn't need to be a TLS WG item unless the = TLS WG and community are going to do substantial work on it.
=
-Ekr


On Fri, Jan 25, 2019 at 10:12 AM Ch= ristopher Wood <christoph= erwood07@gmail.com> wrote:
At the TLS@IETF103 session, there was interest in adoptin= g
draft-housley-tls-tls13-cert-with-extern-psk as an experimental WG
item, provided that it's limited to external PSKs with certificates
for the initial handshake. This email is to determine whether there is
WG consensus to adopt this draft (as is) as a WG item.

If you would like for this draft to become a WG document and you are
willing to review it as it moves through the process, then please let
the list know by 2359UTC 20180208. If you are opposed to this being a
WG document, please say so (and say why).

Thanks,
Chris, Joe and Sean

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000ab3663058164df91-- From nobody Fri Feb 8 11:10: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 B1B4F130E96 for ; Fri, 8 Feb 2019 11:10:18 -0800 (PST) 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 IIn6BrlnqtLi for ; Fri, 8 Feb 2019 11:10:17 -0800 (PST) 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 364E6130E6E for ; Fri, 8 Feb 2019 11:10:17 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 7723FB81D94; Fri, 8 Feb 2019 11:10:10 -0800 (PST) To: ekr@rtfm.com, kaduk@mit.edu, ekr@rtfm.com, christopherwood07@gmail.com, joe@salowey.net, sean+ietf@sn3rd.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: dkg@fifthhorseman.net, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20190208191010.7723FB81D94@rfc-editor.org> Date: Fri, 8 Feb 2019 11:10:10 -0800 (PST) Archived-At: Subject: [TLS] [Editorial Errata Reported] RFC8446 (5627) 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, 08 Feb 2019 19:10:19 -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/eid5627 -------------------------------------- Type: Editorial Reported by: Daniel Kahn Gillmor Section: 4.2.11 Original Text ------------- In TLS versions prior to TLS 1.3, the Server Name Identification (SNI) value Corrected Text -------------- In TLS versions prior to TLS 1.3, the Server Name Indication (SNI) value Notes ----- RFC 6066 and many other places indicate that the correct expansion for "SNI" is "Server Name Indication", not "Server Name Identification". 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 Fri Feb 8 11:43: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 4A22A130F58; Fri, 8 Feb 2019 11:43:13 -0800 (PST) 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 6PoK6oomK42c; Fri, 8 Feb 2019 11:43:11 -0800 (PST) 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 E4862130F1A; Fri, 8 Feb 2019 11:43:11 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 3BAE9B80104; Fri, 8 Feb 2019 11:43:05 -0800 (PST) To: dkg@fifthhorseman.net, ekr@rtfm.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: kaduk@mit.edu, iesg@ietf.org, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20190208194305.3BAE9B80104@rfc-editor.org> Date: Fri, 8 Feb 2019 11:43:05 -0800 (PST) Archived-At: Subject: [TLS] [Errata Held for Document Update] RFC8446 (5627) 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, 08 Feb 2019 19:43:13 -0000 The following errata report has been held for document update 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/eid5627 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Daniel Kahn Gillmor Date Reported: 2019-02-08 Held by: Benjamin Kaduk (IESG) Section: 4.2.11 Original Text ------------- In TLS versions prior to TLS 1.3, the Server Name Identification (SNI) value Corrected Text -------------- In TLS versions prior to TLS 1.3, the Server Name Indication (SNI) value Notes ----- RFC 6066 and many other places indicate that the correct expansion for "SNI" is "Server Name Indication", not "Server Name Identification". -------------------------------------- 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 Sun Feb 10 13:40:09 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 33C6A12941A for ; Sun, 10 Feb 2019 13:40:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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] 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 apuPzGmqDPIM for ; Sun, 10 Feb 2019 13:40:06 -0800 (PST) Received: from mail-yw1-xc2f.google.com (mail-yw1-xc2f.google.com [IPv6:2607:f8b0:4864:20::c2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DAA61286E7 for ; Sun, 10 Feb 2019 13:40:06 -0800 (PST) Received: by mail-yw1-xc2f.google.com with SMTP id f65so3412938ywc.8 for ; Sun, 10 Feb 2019 13:40:06 -0800 (PST) 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 :content-transfer-encoding; bh=9L1PbK6PKQlU1+lefaR7Fc/GeP8A0OX6nljZnmcuamw=; b=FVCXGXzCp5UILElLPPBTa2+5z4WRJzdiJA6XLvhaFFej2gc+i2YSlMO141t2hgD8Ri v31+BLk1ZLpX5TezTx5H/jSyyM9fhvYoWxVhjnp/NxSU1YFLl1D/5UkqWJAOYNeZtAdn GdFsuDauoNcg42pmYhA8Jfd7H91YKNfH8AqFOFUmBfozN8Ja3uQqX1uvHDhuPEz9tSWA 9V8VXrMW0AnD+HZ1L1O4G96utbPL3HtNBRn0SE6h+ZFzXV20U4BqjQg0sKBRp23lN9SD TniGjAI/92nR8YNAoQUgoFNhRojodmn6GOZssO2CPVlz2849DEDqPS4A56aYbLTONLQI 1xkQ== 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:content-transfer-encoding; bh=9L1PbK6PKQlU1+lefaR7Fc/GeP8A0OX6nljZnmcuamw=; b=sfiBq+sEfl+cUrZHSr0by/jcu6YiP7UHuT6rHYcA6hQbzqx+MsyQkJNX5dk+svkFe3 +MDWsXFP1Z1FILx9Nu9rTYHQ8pBRK1o+IgUMEoGYZcJQ+uP+GYKBChrs2D0ZXliDD5QO zs0TIacLxY/+BLhqJdoAPfTlOD3dGP0ga2Yw7zHU21cZx+qd2D5WE0HbM55h1vKpzRmk TPLDxRmOQctXllUXeETT0Sb2lYmInKYzFgwizIEetvNVi6JvtXhoic+lny6EWwQr208r NC/Aa3FqNsXtUXDbOWjenxj/U+e30crHUDgW3ltMLmUEUr4cz/e2oSSyqIaLX6KpG0H8 8vMg== X-Gm-Message-State: AHQUAuawll4VTYqxuMKIadydquBKmNrZSdQRrEYDIK4tIvLep8XgTl5c JJ0zp+PP6zwZqJ9cfodvxju/rsneHnrd+213HtQRtO6X X-Google-Smtp-Source: AHgI3IZUQk6w38ZNqWXgoO2Z5R1wXVxbkZ5oj0AZ9cNRgoIIfzAA8SetrJLxYLtHUA6cgjthziv+GauRWVapN1kZAdY= X-Received: by 2002:a81:7801:: with SMTP id t1mr26126545ywc.298.1549834804840; Sun, 10 Feb 2019 13:40:04 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Christopher Wood Date: Sun, 10 Feb 2019 13:39:50 -0800 Message-ID: To: "" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Call for Adoption: TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key 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, 10 Feb 2019 21:40:08 -0000 Given the low amount of responses, we=E2=80=99re going to extend this adopt= ion call for another two weeks. As a reminder, if you would like for this draft to become a WG document and you are willing to review it as it moves through the process, then please let the list know by 2359UTC 20180222. If you are opposed to this being a WG document, please say so (and say why). Thanks, Chris, Joe, and Sean On Fri, Feb 8, 2019 at 8:58 AM Eric Rescorla wrote: > > I'd like to hear from some people who plan to implement and deploy this. = Absent that, I'm not sure we should adopt it. Code points are free, so it d= oesn't need to be a TLS WG item unless the TLS WG and community are going t= o do substantial work on it. > > -Ekr > > > On Fri, Jan 25, 2019 at 10:12 AM Christopher Wood wrote: >> >> At the TLS@IETF103 session, there was interest in adopting >> draft-housley-tls-tls13-cert-with-extern-psk as an experimental WG >> item, provided that it's limited to external PSKs with certificates >> for the initial handshake. This email is to determine whether there is >> WG consensus to adopt this draft (as is) as a WG item. >> >> If you would like for this draft to become a WG document and you are >> willing to review it as it moves through the process, then please let >> the list know by 2359UTC 20180208. If you are opposed to this being a >> WG document, please say so (and say why). >> >> Thanks, >> Chris, Joe and Sean >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls From nobody Sun Feb 10 15:43: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 D4D271295D8 for ; Sun, 10 Feb 2019 15:43:43 -0800 (PST) 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=QYoLSYoj; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=rzS5kEzG Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtvLcSDVGw-h for ; Sun, 10 Feb 2019 15:43:41 -0800 (PST) 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 92A7012958B for ; Sun, 10 Feb 2019 15:43:41 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 40297216A6; Sun, 10 Feb 2019 18:43:40 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute1.internal (MEProxy); Sun, 10 Feb 2019 18:43:40 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:from:to:cc:mime-version:content-transfer-encoding :content-type:subject:references:date:in-reply-to; s=fm1; bh=Rvp z2kwsMn285tI3tRhPUUko8EuKRjAnWUU63IwMrL4=; b=QYoLSYojnLxSw7jJwTY DogQ9sIhBaL8/U8Xn6cenZYPqVR1Wutyq49DHuKTevlnBJDAYBCSgbLHvQ73U2Fy f85uUqqAKxgUl0NGsFm5n7It9tvWjX6SQksTQjtTYQq0q3gsJqXpJfynFER1Ur56 E1rV28B9gtXKYapgagJC7FRwY0C1NdHKpFs5pgeSpQy4id/u6gULTbV0VaY5GLik FRgH0Obs3MKCuzYgG+KsECq8X4jIzmKocf+ESmM9sOXNep6YygO8PUFe3xhWl8wl HyNegBnHGIWzHitcE6BwUTV4GyepN+MNriw01mGVBVqaS/stIH+tcR3iWK/S5hBc DdQ== 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=Rvpz2kwsMn285tI3tRhPUUko8EuKRjAnWUU63IwMr L4=; b=rzS5kEzGJMpTH/Ko4Iv7DXSu/0grC7p4jR/2h4KO65qnRCkCKjKX334UV V6BueDpbHJ3MSeEmw86OG19Ya9kvxl3pDNn61dgtwRPAARmIeeamgP93mPYoXYcz of8/vsXGPP8Qcqi/jH5mAZMZsoiVff3s90A8jPvDXDFwzV1oPiSYi2xRju4GQhO4 MgABV47/Q5H4VKr9W8vImLEQfUPAN0ZLPUPEVgup3DmXt0Aye9oJw2AezG26jNEH 4wF+11aUhaUEutJPgbq3W/UlbSHK2peCNWHMQ7xpzj1Qe2SBdV+DV0sud+pgSJgo CV4J2lYTgsZDCHpKL0uQ6wtVoY6zw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrleejgdduvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepkffhvfgggfgtof fufhffjgesthejredtredtjeenucfhrhhomhepofgrrhhtihhnucfvhhhomhhsohhnuceo mhhtsehlohifvghnthhrohhphidrnhgvtheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hmtheslhhofigvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 8C9F09E567; Sun, 10 Feb 2019 18:43:39 -0500 (EST) Message-Id: <1549842219.465443.1655100776.7BADB4DA@webmail.messagingengine.com> From: Martin Thomson To: Hubert Kario Cc: tls@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-e6290ad1 References: <1549596678.898774.1653407000.2B2ACE8E@webmail.messagingengine.com> <3192766.6rApcoU5jf@pintsize.usersys.redhat.com> Date: Mon, 11 Feb 2019 10:43:39 +1100 In-Reply-To: <3192766.6rApcoU5jf@pintsize.usersys.redhat.com> Archived-At: Subject: Re: [TLS] Server validation of a second ClientHello 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, 10 Feb 2019 23:43:44 -0000 On Fri, Feb 8, 2019, at 23:53, Hubert Kario wrote: > given need for GREASE and two dozen flags across OpenSSL history for > workarounds for bugs in different implementations, the lesson seems to be that > the receiving side should be as strict as it can (within protocol confines) or > we risk making the non-conforming behaviour common I take something different from that experience. There is value in having some implementations do strict checks, certainly. However, in this case, I don't believe that it is reasonable to perform these checks (more below). > > With that answer in mind, if the second ClientHello might differ, I assert > > that the server uses that. Hubert observes that this behaviour is not > > specified at all, which is entirely true. I think that using the first > > ClientHello would be nonsensical, because the server needs to use the > > second ClientHello for those extensions that can change, like key share. > > And I say that when you have already parsed, verified and sanity-checked the > first set of extensions, it is much saner to reuse that work and only update > the values that can change and ignore all other extensions... As I mentioned, NSS does that work, at least partially, and then throws all of that state away when it sends HelloRetryRequest. It does that so that HelloRetryRequest can be truly stateless (an advantage for DTLS). Doing that work all over is trivial, bundling the necessary state, not. > There are multiple ways to look at this, and given that the standard is very > firm that the 2nd CH needs to be as similar to the first one as possible, it > is thus silent on which takes precedence in case they differ in general, > because they can't. > > If we require or allow checking - and I think that we should definitely > > allow a check - the details of the conditions under which a check might > > fail aren't completely obvious for new extensions. A new extension might > > be defined that has special handling in HelloRetryRequest, so it might be > > reasonable to allow new extensions to be changed. > > yes, and we already had discussion on this ML about this: if the extension > needs to change (based on protocol definition), the server MUST include it in > HRR to signal to client, "yes, I do know about it, you can update it" and > client MUST NOT change it otherwise I remember having that discussion, but I guess the only way it made it into the spec was as: - Other modifications that may be allowed by an extension defined in the future and present in the HelloRetryRequest. Which isn't particularly direct, but I guess that's enough. > the cookie can be up to 2^16 bytes long, even if client sends all 50 > extensions and spaces them with unknown extensions between, that's at most 20 > bytes per extension = 1000 bytes total extra space needed in cookie (32 bytes > and 1600 bytes if you want to be very conservative) Yeah, that's ridiculously large. With quite a few extensions supported, and many more unknown to us, the only way we might realistically ensure that the ClientHello doesn't change is to save a hash snapshot at every boundary where the cookie extension might be inserted or where an extension might be changed. SHA-2 has a fairly small state to capture, but that's still nearly unbounded state. With an amplification factor of up to 8, meaning that it could be more efficient to send the client its entire ClientHello in the cookie. From nobody Mon Feb 11 08:41: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 D758E131117 for ; Mon, 11 Feb 2019 08:40:50 -0800 (PST) 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, 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 0GJKSOPqwHtX for ; Mon, 11 Feb 2019 08:40:47 -0800 (PST) Received: from p3plsmtpa12-02.prod.phx3.secureserver.net (p3plsmtpa12-02.prod.phx3.secureserver.net [68.178.252.231]) (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 4B3561310F4 for ; Mon, 11 Feb 2019 08:40:43 -0800 (PST) Received: from spectre ([173.8.184.78]) by :SMTPAUTH: with ESMTPSA id tEdMgrHES8pUxtEdMgVcMD; Mon, 11 Feb 2019 09:40:40 -0700 From: "Peter Yee" To: "'Christopher Wood'" , References: In-Reply-To: Date: Mon, 11 Feb 2019 08:40:41 -0800 Message-ID: <097d01d4c228$872ef930$958ceb90$@akayla.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDcjlBlHVnZeURAnVAeuCkMjnq6FQJFHMigAiMSNI2np/Kl4A== Content-Language: en-us X-CMAE-Envelope: MS4wfCyAqH6GtMMJQCLzsKjbaQFr/jaKgR9ct/NhF3Ixd1XztjW+6tlfV5+QQR1zmaV7bRXOiEi+czjb4G4Bm3J1Sgt58S077W/tT5/ZTfIxMssB+vigRkvf ADPplPK59TeAa9IxAue1iRAwtarK1BAFrraql+W5juylbLpV9OXoFYYjBL2ePcuBQiUec2BTiwlg+g== Archived-At: Subject: Re: [TLS] Call for Adoption: TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key 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, 11 Feb 2019 16:41:01 -0000 I support adoption of this draft and am willing to review it. -Peter -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Christopher Wood Sent: Sunday, February 10, 2019 1:40 PM To: Subject: Re: [TLS] Call for Adoption: TLS 1.3 Extension for = Certificate-based Authentication with an External Pre-Shared Key Given the low amount of responses, we=E2=80=99re going to extend this = adoption call for another two weeks. As a reminder, if you would like for this draft to become a WG document and you are willing to review it as it moves through the process, then please let the list know by 2359UTC 20180222. If you are opposed to this being a WG document, please say so (and say why). Thanks, Chris, Joe, and Sean On Fri, Feb 8, 2019 at 8:58 AM Eric Rescorla wrote: > > I'd like to hear from some people who plan to implement and deploy = this. Absent that, I'm not sure we should adopt it. Code points are = free, so it doesn't need to be a TLS WG item unless the TLS WG and = community are going to do substantial work on it. > > -Ekr > > > On Fri, Jan 25, 2019 at 10:12 AM Christopher Wood = wrote: >> >> At the TLS@IETF103 session, there was interest in adopting >> draft-housley-tls-tls13-cert-with-extern-psk as an experimental WG >> item, provided that it's limited to external PSKs with certificates >> for the initial handshake. This email is to determine whether there = is >> WG consensus to adopt this draft (as is) as a WG item. >> >> If you would like for this draft to become a WG document and you are >> willing to review it as it moves through the process, then please let >> the list know by 2359UTC 20180208. If you are opposed to this being a >> WG document, please say so (and say why). >> >> 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 Tue Feb 12 04:53: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 C418F12F1A6 for ; Tue, 12 Feb 2019 04:53:11 -0800 (PST) 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 M7rMvaX4swZX for ; Tue, 12 Feb 2019 04:53:10 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF45512DF71 for ; Tue, 12 Feb 2019 04:53:09 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7E75E37E88; Tue, 12 Feb 2019 12:53:09 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.83]) by smtp.corp.redhat.com (Postfix) with ESMTP id EFFFB19C7D; Tue, 12 Feb 2019 12:53:08 +0000 (UTC) From: Hubert Kario To: Martin Thomson Cc: tls@ietf.org Date: Tue, 12 Feb 2019 13:52:43 +0100 Message-ID: <1549980018.5oto7EOJll@pintsize.usersys.redhat.com> In-Reply-To: <1549842219.465443.1655100776.7BADB4DA@webmail.messagingengine.com> References: <1549596678.898774.1653407000.2B2ACE8E@webmail.messagingengine.com> <3192766.6rApcoU5jf@pintsize.usersys.redhat.com> <1549842219.465443.1655100776.7BADB4DA@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4181887.LOKayHmXMs"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Tue, 12 Feb 2019 12:53:09 +0000 (UTC) Archived-At: Subject: Re: [TLS] Server validation of a second ClientHello 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, 12 Feb 2019 12:53:12 -0000 --nextPart4181887.LOKayHmXMs Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Monday, 11 February 2019 00:43:39 CET Martin Thomson wrote: > On Fri, Feb 8, 2019, at 23:53, Hubert Kario wrote: > > the cookie can be up to 2^16 bytes long, even if client sends all 50 > > extensions and spaces them with unknown extensions between, that's at m= ost > > 20 bytes per extension =3D 1000 bytes total extra space needed in cookie > > (32 bytes and 1600 bytes if you want to be very conservative) >=20 > Yeah, that's ridiculously large. With quite a few extensions supported, = and > many more unknown to us, the only way we might realistically ensure that > the ClientHello doesn't change is to save a hash snapshot at every bounda= ry > where the cookie extension might be inserted or where an extension might = be > changed. SHA-2 has a fairly small state to capture, but that's still > nearly unbounded state. With an amplification factor of up to 8, meaning > that it could be more efficient to send the client its entire ClientHello > in the cookie. I definitely won't claim that it is easy or straight-forward to do, I do cl= aim=20 that it is possible. Yes, sometimes it may mean that sending the literal CH= in=20 cookie may be more bandwidth efficient. And regarding the specific extension in question, to verify that it didn't= =20 change between Hello's it is only 2 bytes extra in cookie. If that is too m= uch=20 already, I don't think that stateless HRR is something we will see in=20 implementations for years to come. =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 --nextPart4181887.LOKayHmXMs 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+dkqjRuAHS9fUFAlxiwZsACgkQkqjRuAHS 9fWUphAAkbOe6eFxE7yG8kkGK7MG5BKgCEAxpA4LMFn7qtdoh0E+bO998mP6I60T mV8TlHYj1GfgRFe/Nnc04nKZosPmaL+hckgLT5oPnfEV828Q8taMg4brA6TWb9kE Tp0vMfINscYK1hkPJ7SKXLvB7idr3+VZllexdQQQ0+deUWDEmwsaF4rU7ybDhPrl LCUZrQU/zsPbaPDBx6ZFU9aFOvxHIJA0uH7/Toto7/VUR6BUk95H5H99M+n8tIJJ +PY1wF3JzGpg1zxhGz9FFT07fPXLcW3OgNnifi9dB/hQhJbsh8R695VkYl1FHM4E qL9gRLzHKH00FnHWGhyoLhmiNrk1zeuCH3ph3iRt+7Ajmo5f9NyG5hLMMccxAmZx AGn2X/JiaP04yyUIL2YYjm9M+T9t8daxKQzrx/VwuKzeIbJr2BAs/By4+ZnjDqUJ Dq3MhBnK4+ALw2trOcsAfIyTOjqpo4uujJriS/VC9lP7ACrXFmujenacStZXy1n/ AZ60V3KMT3UvLvNDtpSxraXLMujrbUWvaOFloX8ysTr/NwQ3V4N1DRWK8uTXTSGX 3P1LdpQHOKGTc7aQikYC5uabhDI+WfJZWbZ+uPVMHkoukFDuwVEvu6vBERFnY61k B2FY+7GxQJAaAkP7sSY/OF+VZK/xgi0H645uir93iahhdko3bKk= =Rpla -----END PGP SIGNATURE----- --nextPart4181887.LOKayHmXMs-- From nobody Tue Feb 12 16:32: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 757E6130E30 for ; Tue, 12 Feb 2019 16:32:23 -0800 (PST) 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35RaWqMT2aWP for ; Tue, 12 Feb 2019 16:32:21 -0800 (PST) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A5F1130E16 for ; Tue, 12 Feb 2019 16:32:20 -0800 (PST) Received: by mail-lf1-x130.google.com with SMTP id q11so434126lfd.3 for ; Tue, 12 Feb 2019 16:32:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RpVUf4G3PEU87j2/+U8fnhTrYWG6wel8PaN6b5YWaI8=; b=gM2QnG2+BeyuKi8jnITW5fwP77uc2LICKFa0Gaq77LtGIGFszolF70VFhTBib2DEYK oXFWamX6DHSwmDaPrrJ5uffwy46YDaf1iFuDAOzVs9CY25Y0OP1+X6HgIAX5BEsErZsQ piXScY9TWFGjl0BnMFsdyQ3bO6sHb4nixeYXHMEeDkqFHJ2IHsik1qt/e3oqgSgFURLI lz3kXPRJ7YBkGllKCRhFEiF9rxxsrmVerTZIeiD8Go90IhHYI8+LqQ0QWaZoeNQ88/SB YqJsz3hy6LDWLTRbhV7B3LC4YGxdBTIMHvj49VrcE56zRbSJicDSjUyo1BoD+HJ/e04+ 6rFA== 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=RpVUf4G3PEU87j2/+U8fnhTrYWG6wel8PaN6b5YWaI8=; b=HOs56C7up8+wneSs0OyrpzHjuTusGE7yFVthKHLOtNZhkjXpj9Xtr7uDQOyXrca5lg Ragno3D6L3VrWvNXKtK+WxfWW/JgGIFvp0M+viTDA/pzcd7pvbW86ijkgT/s0zKkR6rq Vu/ddV7kzzDG9VJIOFM3UrfmuMNeiJT9lt5HmQGpO40DMfjyrthV2Zcot2na04gzESqG Px5AOKzcgFda7E9ONVUCmk8QhUb3HZ3iPObsG+zwY+g+fajFoalT8JXNMh9IpAS/iE7W 90lATDURtPZLwbjFGz3vlBOKSGtRS5SUtYRZ50owA3E1s/8Z08kULYQ3IOjX6f/lfGNy nudw== X-Gm-Message-State: AHQUAuYBzcjlftbCbqRAjiqGCrn7TLg9TmBlLEA4mIia/qpQUC1PQH65 HPvCjqQWLw3L2hll8fG9DSmyPeJdlh7NUKSgn1dkaQ== X-Google-Smtp-Source: AHgI3IZKaqIWFQYH+gi7PgreffQLGq3m4Tt7Ebd6C03Bj40T902Nq0f0B6IcPtWVaPV8pGzTi/8MJ2CmCRJXB1+qXNE= X-Received: by 2002:a19:911c:: with SMTP id t28mr3055181lfd.78.1550017938307; Tue, 12 Feb 2019 16:32:18 -0800 (PST) MIME-Version: 1.0 References: <1549596678.898774.1653407000.2B2ACE8E@webmail.messagingengine.com> <3192766.6rApcoU5jf@pintsize.usersys.redhat.com> <1549842219.465443.1655100776.7BADB4DA@webmail.messagingengine.com> <1549980018.5oto7EOJll@pintsize.usersys.redhat.com> In-Reply-To: <1549980018.5oto7EOJll@pintsize.usersys.redhat.com> From: Eric Rescorla Date: Tue, 12 Feb 2019 16:31:41 -0800 Message-ID: To: Hubert Kario Cc: Martin Thomson , "" Content-Type: multipart/alternative; boundary="0000000000009bd4ce0581bbacf0" Archived-At: Subject: Re: [TLS] Server validation of a second ClientHello 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, 13 Feb 2019 00:32:23 -0000 --0000000000009bd4ce0581bbacf0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I concur with what I take to be MT's position here: 1. The client is clearly prohibited from changing most elements of the CH (except for listed exceptions). 2. It's reasonable to check for and fail the handshake on any spec violation except those where checking is explicitly forbidden (e.g., Must Be Zero but Must be Ignored) 3. Nothing in the spec requires the server to check for this condition. -Ekr On Tue, Feb 12, 2019 at 4:53 AM Hubert Kario wrote: > On Monday, 11 February 2019 00:43:39 CET Martin Thomson wrote: > > On Fri, Feb 8, 2019, at 23:53, Hubert Kario wrote: > > > the cookie can be up to 2^16 bytes long, even if client sends all 50 > > > extensions and spaces them with unknown extensions between, that's at > most > > > 20 bytes per extension =3D 1000 bytes total extra space needed in coo= kie > > > (32 bytes and 1600 bytes if you want to be very conservative) > > > > Yeah, that's ridiculously large. With quite a few extensions supported= , > and > > many more unknown to us, the only way we might realistically ensure tha= t > > the ClientHello doesn't change is to save a hash snapshot at every > boundary > > where the cookie extension might be inserted or where an extension migh= t > be > > changed. SHA-2 has a fairly small state to capture, but that's still > > nearly unbounded state. With an amplification factor of up to 8, meani= ng > > that it could be more efficient to send the client its entire ClientHel= lo > > in the cookie. > > I definitely won't claim that it is easy or straight-forward to do, I do > claim > that it is possible. Yes, sometimes it may mean that sending the literal > CH in > cookie may be more bandwidth efficient. > > And regarding the specific extension in question, to verify that it didn'= t > change between Hello's it is only 2 bytes extra in cookie. If that is too > much > already, I don't think that stateless HRR is something we will see in > implementations for years to come. > > -- > 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_______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000009bd4ce0581bbacf0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I concur with what I take to be MT&#= 39;s position here:

1. The client is clearly prohi= bited from changing most elements of the CH (except for listed exceptions).=
2. It's reasonable to check for and fail the handshake o= n any spec violation except those where checking is explicitly forbidden (e= .g., Must Be Zero but Must be Ignored)
3. Nothing in the spec req= uires the server to check for this condition.

-Ekr=


On Tue, Feb 12, 2019 at 4:53 AM Hubert Kario <hkario@redhat.com>= wrote:
On Monda= y, 11 February 2019 00:43:39 CET Martin Thomson wrote:
> On Fri, Feb 8, 2019, at 23:53, Hubert Kario wrote:
> > the cookie can be up to 2^16 bytes long, even if client sends all= 50
> > extensions and spaces them with unknown extensions between, that&= #39;s at most
> > 20 bytes per extension =3D 1000 bytes total extra space needed in= cookie
> > (32 bytes and 1600 bytes if you want to be very conservative)
>
> Yeah, that's ridiculously large.=C2=A0 With quite a few extensions= supported, and
> many more unknown to us, the only way we might realistically ensure th= at
> the ClientHello doesn't change is to save a hash snapshot at every= boundary
> where the cookie extension might be inserted or where an extension mig= ht be
> changed.=C2=A0 SHA-2 has a fairly small state to capture, but that'= ;s still
> nearly unbounded state.=C2=A0 With an amplification factor of up to 8,= meaning
> that it could be more efficient to send the client its entire ClientHe= llo
> in the cookie.

I definitely won't claim that it is easy or straight-forward to do, I d= o claim
that it is possible. Yes, sometimes it may mean that sending the literal CH= in
cookie may be more bandwidth efficient.

And regarding the specific extension in question, to verify that it didn= 9;t
change between Hello's it is only 2 bytes extra in cookie. If that is t= oo much
already, I don't think that stateless HRR is something we will see in <= br> implementations for years to come.

--
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=C2=A0 Brno, Czech Republic= _______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000009bd4ce0581bbacf0-- From nobody Wed Feb 13 01:31:42 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 016B4131084 for ; Wed, 13 Feb 2019 01:31:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=cdt.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 FSsd-C0aWNQg for ; Wed, 13 Feb 2019 01:31:30 -0800 (PST) Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A75CD13106D for ; Wed, 13 Feb 2019 01:31:30 -0800 (PST) Received: by mail-ot1-x335.google.com with SMTP id w25so2743033otm.13 for ; Wed, 13 Feb 2019 01:31:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:from:date:message-id:subject:to; bh=OAzotw7FxDb5YuJ+MupZ5DcTsLWesGqPkjHmBmjPV2A=; b=VL/Jh194vQ1nIPFXgxnOK9o0qtszIcVf2gxICGsjdlydJGKEmS11nGbDK/Skg+hG4R CZwtXjPN0EWkCezYY5If2+PAe6q/IBjwiMLX3n80FDEeAsCcsv9WvgsS98LZUthuBqYC TuIOOOL9TEl5mp3lk2dK5OrrU8uR4pddoTmrc= 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=OAzotw7FxDb5YuJ+MupZ5DcTsLWesGqPkjHmBmjPV2A=; b=sk4JcbIKHQEdhHA0xvPAXXSzJ1ds91Hskxrct5BZQyulWzorAA4hGXb8btfA7S8pD+ ofK7EtLpoGZBybAB8YIo1Wxmn6wnJiNShZ7vzwWJ5afWqq3eV4OOcgoWT7pJ7XQ7h3UO h37Ehs2s/4QHjaWtAKoola21XJWMsEz0vXgU6XAkKUVsmsnOuhpB3Uy6gANAX+gX09Sg +0dlY7+bzuj9t4XvNVK/lw7Gyuv717pp39cL9NdOTn+pzZPpGLGEZmxl1kUjjD5i6Mil DELQJiVVdNeK1PaVorAZyJ8FIdJz4R3laYSDKKjvOERxLMJydXGGEkMIH6nuVgFnTHpO towA== X-Gm-Message-State: AHQUAub1HARX6Xtpp+hFM3qvao+5gY/tsJiyRP6WS6E95ZG2HRkado/9 Itz5trUdfECQCzGDAU99S2MJdgMkP2rgPy3pHGUo2RVf X-Google-Smtp-Source: AHgI3IbFPWk49tZ90cPxevFUffD5UP8asfu4KgFNrzzy2QNX4HLsjtlf9odf+Y+Ie+tBxv3LiXXMfDJEtVSfKxtUSLQ= X-Received: by 2002:a9d:17ca:: with SMTP id j68mr7331640otj.268.1550050288782; Wed, 13 Feb 2019 01:31:28 -0800 (PST) MIME-Version: 1.0 From: Joseph Lorenzo Hall Date: Wed, 13 Feb 2019 04:31:17 -0500 Message-ID: To: TLS WG Content-Type: multipart/alternative; boundary="000000000000d8e71c0581c334ff" Archived-At: Subject: [TLS] SK filtering on SNI, blocking ESNI 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, 13 Feb 2019 09:31:41 -0000 --000000000000d8e71c0581c334ff Content-Type: text/plain; charset="UTF-8" It appears South Korea has started censoring traffic across all ISPs based on SNI [1], [2]. Nick points out that they seem to be blocking ESNI entirely [3]. [1]: https://bugzil.la/1494901#c3 [2]: https://news.joins.com/article/23363557 [3]: https://twitter.com/grittygrease/status/1095530153319358465?s=21 -- Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] 1401 K ST NW STE 200, Washington DC 20005-3497 e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 -- Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] 1401 K ST NW STE 200, Washington DC 20005-3497 e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 --000000000000d8e71c0581c334ff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It appears South Korea has started censoring tr= affic across all ISPs based on SNI [1], [2]. Nick points out that they seem= to be blocking ESNI entirely [3].

<= div>

--
Joseph Lorenzo Hall
Chief Technologist, Center = for Democracy & Technology [https://www.cdt.org]
1401 K ST NW STE 200, Washington DC 2000= 5-3497
e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9F= 6D DBD3 4B10=C2=A0 1607 5F86 6987 40A9 A871
--
Joseph Lorenzo Hall
Chief Technologist, Center for Democ= racy & Technology [https://www.cdt.org<= /a>]
1401 K ST NW STE 200, Washington DC 20005-3497
e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: = 3CA2 8D7B 9F6D DBD3 4B10=C2=A0 1607 5F86 6987 40A9 A871
--000000000000d8e71c0581c334ff-- From nobody Wed Feb 13 01:50:29 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 82AA4124BAA for ; Wed, 13 Feb 2019 01:50:28 -0800 (PST) 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 bokyUMJZB0Uc for ; Wed, 13 Feb 2019 01:50:26 -0800 (PST) Received: from mail-it1-x12e.google.com (mail-it1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD02D124408 for ; Wed, 13 Feb 2019 01:50:25 -0800 (PST) Received: by mail-it1-x12e.google.com with SMTP id o131so4350923itc.5 for ; Wed, 13 Feb 2019 01:50:25 -0800 (PST) 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=iy7sElPq64YlOgYdaceFbSpF6dwHOXRSgz0Kb8IS6qM=; b=hD9MDLdy7WcmMy5Nlku9CUwoTUxjoWRowbiF2ax6WC1pC6QQSyneccVcI+5M+cu72d r8g41GpBXjfC5dNrZIAw4Sk+rDmK6l33Zy16+Va9obIHOcR9tpRbH7FDVx2MTJae17Uf K1ocbDvo1aPSi9rpPHKgV/pdyfYcTl/kz1cBLznmjtcyI6Xv4w7jYGWT4N/PDyNwdBfW /mdiIjjjAI70MW70ddRG3CH0cslyoaiGV0rVI1RNeYWDKY5jl8O5ckz4giaAxP8KCh0y C/rXJdQbh4VtM6AsNZEHhbyFyWMQsyiPhZH+P+haYiKBp1bX86N4pemQTIeLWeU8Bfpi fGhQ== 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=iy7sElPq64YlOgYdaceFbSpF6dwHOXRSgz0Kb8IS6qM=; b=jnNNew8NJNbAZemmECV6ib9i1kQIfxxqc6yg6eLLI7xNwhBDa2d47t7R9qOTHIeQnc dcO7aWReRHfCn3ITrCpE531tLS1D/96+dIMbroCdiEI2XoYLKfrIAURJsBzD2EfgLq25 1WfgGc6Lg+fEn1AiddaP9C3sRQvMJUIHHqDluCLj+wNJOeA8Skk3qwm5sLURAMxHDX/U mVpMqbuesRFyej8iGbVQHdCeL8TWi39VeNt/XWt9+ud68G7VR1h2ksD209I7XwxwWG88 GG5UiLsl+MTQVeCF4gQnJFNcI9Yf6DNmmvm2FpC5uxQxwnIdGkRlbGAUcfg9gIjHfuvZ FqjQ== X-Gm-Message-State: AHQUAuYPOYq0+TgpNTnA1yf71AEPhkPY99jMBcsgVgXzZDSYTRFB3mMJ Q7Cv3iCN194jsbclQxn20VNBeqjF/R/2jS6u4WM= X-Google-Smtp-Source: AHgI3IZsNkd7WhBcvwexKqRo3tyr/V8n/h7seOTb8HYORlxeRsAczNvxsdVJ9fyy8gZKeGyswnmH9svWEu7iPzG3+NU= X-Received: by 2002:a24:248:: with SMTP id 69mr1774565itu.91.1550051424912; Wed, 13 Feb 2019 01:50:24 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Loganaden Velvindron Date: Wed, 13 Feb 2019 13:50:13 +0400 Message-ID: To: Joseph Lorenzo Hall Cc: TLS WG Content-Type: multipart/alternative; boundary="00000000000090ca610581c3789a" Archived-At: Subject: Re: [TLS] SK filtering on SNI, blocking ESNI 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, 13 Feb 2019 09:50:29 -0000 --00000000000090ca610581c3789a Content-Type: text/plain; charset="UTF-8" On Wed, Feb 13, 2019 at 1:32 PM Joseph Lorenzo Hall wrote: > It appears South Korea has started censoring traffic across all ISPs based > on SNI [1], [2]. Nick points out that they seem to be blocking ESNI > entirely [3]. > > [1]: https://bugzil.la/1494901#c3 > [2]: https://news.joins.com/article/23363557 > [3]: https://twitter.com/grittygrease/status/1095530153319358465?s=21 > > That's quite extreme. > -- > Joseph Lorenzo Hall > Chief Technologist, Center for Democracy & Technology [https://www.cdt.org > ] > 1401 K ST NW STE 200, Washington DC 20005-3497 > e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key > Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 > -- > Joseph Lorenzo Hall > Chief Technologist, Center for Democracy & Technology [https://www.cdt.org > ] > 1401 K ST NW STE 200, Washington DC 20005-3497 > e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key > Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --00000000000090ca610581c3789a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Feb 13, 2019 at 1:32 PM Josep= h Lorenzo Hall <joe@cdt.org> wrote= :
It appears South Korea has started censoring traffic across a= ll ISPs based on SNI [1], [2]. Nick points out that they seem to be blockin= g ESNI entirely [3].



<= /div>
That's quite extreme.=C2=A0=C2=A0
--
Joseph Lorenzo = Hall
Chief Technologist, Center for Democracy & Technology [https://www.cdt.org]
1401= K ST NW STE 200, Washington DC 20005-3497
e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-= key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10=C2=A0 1607 5F86 6987 40A9 = A871
--
Joseph Lorenzo Hall
Chief Technologist, Center for Democracy &am= p; Technology [https://ww= w.cdt.org]
1401 K ST NW STE 200, Washington DC 20005-3497
e: joe@cdt.org, p: 202.407.88= 25, pgp: https= ://josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10=C2= =A0 1607 5F86 6987 40A9 A871
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--00000000000090ca610581c3789a-- From nobody Wed Feb 13 04:12: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 2831E12DDA3 for ; Wed, 13 Feb 2019 04:12:46 -0800 (PST) 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 3m_7fdbAiqdX for ; Wed, 13 Feb 2019 04:12:44 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDD45128CB7 for ; Wed, 13 Feb 2019 04:12:43 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5CEC6C059B7A; Wed, 13 Feb 2019 12:12:43 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.83]) by smtp.corp.redhat.com (Postfix) with ESMTP id 6328C5D6B3; Wed, 13 Feb 2019 12:12:42 +0000 (UTC) From: Hubert Kario To: Eric Rescorla Cc: Martin Thomson , "" Date: Wed, 13 Feb 2019 13:12:34 +0100 Message-ID: <103341275.xSgb4icBHy@pintsize.usersys.redhat.com> In-Reply-To: References: <1549596678.898774.1653407000.2B2ACE8E@webmail.messagingengine.com> <1549980018.5oto7EOJll@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart25838277.KSJJiFsezQ"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Wed, 13 Feb 2019 12:12:43 +0000 (UTC) Archived-At: Subject: Re: [TLS] Server validation of a second ClientHello 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, 13 Feb 2019 12:12:46 -0000 --nextPart25838277.KSJJiFsezQ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Wednesday, 13 February 2019 01:31:41 CET Eric Rescorla wrote: > I concur with what I take to be MT's position here: >=20 > 1. The client is clearly prohibited from changing most elements of the CH > (except for listed exceptions). > 2. It's reasonable to check for and fail the handshake on any spec > violation except those where checking is explicitly forbidden (e.g., Must > Be Zero but Must be Ignored) > 3. Nothing in the spec requires the server to check for this condition. and what about values that technically can't change (as you noted yourself)= =20 but they do change and the server does use them? you are not suggesting that which value will be used (from first or second= =20 CH), or if the connection will be aborted, to be implementation dependant=20 *by design* , do you? =20 > -Ekr >=20 > On Tue, Feb 12, 2019 at 4:53 AM Hubert Kario wrote: > > On Monday, 11 February 2019 00:43:39 CET Martin Thomson wrote: > > > On Fri, Feb 8, 2019, at 23:53, Hubert Kario wrote: > > > > the cookie can be up to 2^16 bytes long, even if client sends all 50 > > > > extensions and spaces them with unknown extensions between, that's = at > >=20 > > most > >=20 > > > > 20 bytes per extension =3D 1000 bytes total extra space needed in c= ookie > > > > (32 bytes and 1600 bytes if you want to be very conservative) > > >=20 > > > Yeah, that's ridiculously large. With quite a few extensions support= ed, > >=20 > > and > >=20 > > > many more unknown to us, the only way we might realistically ensure t= hat > > > the ClientHello doesn't change is to save a hash snapshot at every > >=20 > > boundary > >=20 > > > where the cookie extension might be inserted or where an extension mi= ght > >=20 > > be > >=20 > > > changed. SHA-2 has a fairly small state to capture, but that's still > > > nearly unbounded state. With an amplification factor of up to 8, > > > meaning > > > that it could be more efficient to send the client its entire > > > ClientHello > > > in the cookie. > >=20 > > I definitely won't claim that it is easy or straight-forward to do, I do > > claim > > that it is possible. Yes, sometimes it may mean that sending the literal > > CH in > > cookie may be more bandwidth efficient. > >=20 > > And regarding the specific extension in question, to verify that it did= n't > > change between Hello's it is only 2 bytes extra in cookie. If that is t= oo > > much > > already, I don't think that stateless HRR is something we will see in > > implementations for years to come. > >=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_______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls =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 --nextPart25838277.KSJJiFsezQ 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+dkqjRuAHS9fUFAlxkCbIACgkQkqjRuAHS 9fVSIg//e6GPLDzgeLaD/uGY3feufg2tFIuue+OpRu/8yFVEPcWpSzQnu7UrW+WC OBOgZDN9Q54c9lJxOUZNOIU6iAonOqhXNSRrZgLdGt5DROuWUnAMo3x/qzSx3yq6 vGw7+EQCKs1y/FaUAeGDLhvXbke//BSBHOBNA+oNVEBazUEzTLFQXnBLVio836cV 566DwXkhTG9XeN1E0/d7byHMX0HJm17WSQGBIXe4HCb15nEqSz9nY2BkSHrhwuYd 5+bkwiMWYfX3PYeLmE5GtyzAspBLqJF5xDDJOk/12k1D6GpXmVPfjWzxKxHBNEXF 63bdZ71nt9QcDs9BaobnBNKXeEmdHaomkk16bhwDMi4Qu8Oc2rtEXS60TXhi9+XU ujqiIsPsuZlzH403KQAGpGl7kQGcfjlYr5hvhs5WL7m2ZWWLAlt0r0l2znZWwL5O QlUpW+WqETf1/dkdZsvX1Z56EDmwxzsoN9eyUSqNj/2nY2NkUrbIaHRv1l4Ek5HV Iqy23do6HDZOwdW2FKBtWiZWWJwMCeZml4brJLplEeBaoj7dPdGGdWW6s3rvwQlQ 7yz60r5sgYPlleRlSoma/95MNhcEvygbENEoObjnnLPaenPKVVA6wT1bejcYJ+/R WO4ci1JsUSQ9pu58PlxjQe9OgCyrpCtEmE/bh/5Tr0vPI4iwOpE= =6U/N -----END PGP SIGNATURE----- --nextPart25838277.KSJJiFsezQ-- From nobody Wed Feb 13 06:39:47 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 621E5129441 for ; Wed, 13 Feb 2019 06:39:46 -0800 (PST) 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0165e6rdlVth for ; Wed, 13 Feb 2019 06:39:43 -0800 (PST) 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 BA8E9126C7E for ; Wed, 13 Feb 2019 06:39:42 -0800 (PST) Received: by mail-lj1-x22e.google.com with SMTP id f24-v6so2240637ljk.0 for ; Wed, 13 Feb 2019 06:39:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6Ng13XbHiYGvt49ozAyCUqOeUdMY18ZmdPYGXbdmq4c=; b=js0KDWDXwcYMBp6ZlCUqcXrF5b1G04HNmANwi2pT5WAUZB8DhU5IirUKtgXHGpCa1e Oj+UWkHT2AMYstONNBk+2HwUvBSjQn97l3Qa6sAMzwQI145hecAu3dLIT2RFqrYd7OKr Iu3MFUZqaeVIzhz0pmvA43Xjqr5oKWuni65K/4NLSZMtJoO3NohIxsVn/12hEQfG4Sz3 ln7h2EtSBmVQV91zlgDdFwiEVKIMfCG77eTV7kVUa3clzNBLAGhK0KMgg+NKnJRbbPFo 9CnfmlvpgdOT99kxgLsdNmW01kfRO08nWat785wW9X9T1WbHvpsjVe7Fmnmy/aCLPMYl zH0Q== 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=6Ng13XbHiYGvt49ozAyCUqOeUdMY18ZmdPYGXbdmq4c=; b=YtCALCj+QCBrh1BDE/e35vrr1NdY6aLnm9YfFRdqmJkd9yZvFeCb4sM5Do1M+L/LNp ll1KJ5qYJf93PVxYJl6j1McAYYSRBLvIogbaqCB8V46xy3lQ1oJHXBXj0wwDcLL212Xl kd2Gme4ymku8pxdrCoH4VKhS6eVRJ1ejCvlU+L9pzx5Q9A+Gcp7/ShKFlU0jm4D/OQeg Bouhfcuvfitd3xGY6lTmf3YnBGaXC1tyPN3eifyzxWkc+nrmQE9dEbw0oQj7sd2foTgt 1EDvC9Vzfq8oYkYl8+nQIYeUtFB1L3m5ifETXT3wvrAyJvn8bfXPmlyDSEP07j2VLJYa /sUw== X-Gm-Message-State: AHQUAuZ+aOeHC3kQ/CXMXTUnPT6IFsa7LKL+22Dl73SKuUx2KO1Iu4ez nMKOdKV9sa6dXxdWJ7WkKP7TLh789qqDFs249y7jpw== X-Google-Smtp-Source: AHgI3IZS9uTdksZXWDgGZ4xPAI2Rr4imcbDqE9UvEloVQ2WpPGhq2pPb4biDmdlA2hsl+a9OyL2GnTyWIZH/fWKYhp8= X-Received: by 2002:a2e:965a:: with SMTP id z26mr462352ljh.59.1550068780855; Wed, 13 Feb 2019 06:39:40 -0800 (PST) MIME-Version: 1.0 References: <1549596678.898774.1653407000.2B2ACE8E@webmail.messagingengine.com> <1549980018.5oto7EOJll@pintsize.usersys.redhat.com> <103341275.xSgb4icBHy@pintsize.usersys.redhat.com> In-Reply-To: <103341275.xSgb4icBHy@pintsize.usersys.redhat.com> From: Eric Rescorla Date: Wed, 13 Feb 2019 06:39:03 -0800 Message-ID: To: Hubert Kario Cc: Martin Thomson , "" Content-Type: multipart/alternative; boundary="0000000000000f88a90581c78331" Archived-At: Subject: Re: [TLS] Server validation of a second ClientHello 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, 13 Feb 2019 14:39:46 -0000 --0000000000000f88a90581c78331 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 13, 2019 at 4:12 AM Hubert Kario wrote: > On Wednesday, 13 February 2019 01:31:41 CET Eric Rescorla wrote: > > I concur with what I take to be MT's position here: > > > > 1. The client is clearly prohibited from changing most elements of the = CH > > (except for listed exceptions). > > 2. It's reasonable to check for and fail the handshake on any spec > > violation except those where checking is explicitly forbidden (e.g., Mu= st > > Be Zero but Must be Ignored) > > 3. Nothing in the spec requires the server to check for this condition. > > and what about values that technically can't change (as you noted > yourself) > but they do change and the server does use them? > > you are not suggesting that which value will be used (from first or secon= d > CH), or if the connection will be aborted, to be implementation dependant > *by design* , do you? > I'n not sure I understand your question, but I'll try to answer what I think it says. 1. I do think that whether you continue the connection or abort it is an implementation decision and I think that the way the spec is written says that. 2. I think the spec leaves open whether you should use the first or second values, but I think implementations should use the second value. It's not clear why one would want to use the first. To my knowledge, there was never a WG discussion about this exact question, so we only have the spec to guide us. Were we pre-publication I would have advocated for (a) leaving open whether to abort and (b) requiring you to use the second value. -Ekr > > -Ekr > > > > On Tue, Feb 12, 2019 at 4:53 AM Hubert Kario wrote: > > > On Monday, 11 February 2019 00:43:39 CET Martin Thomson wrote: > > > > On Fri, Feb 8, 2019, at 23:53, Hubert Kario wrote: > > > > > the cookie can be up to 2^16 bytes long, even if client sends all > 50 > > > > > extensions and spaces them with unknown extensions between, that'= s > at > > > > > > most > > > > > > > > 20 bytes per extension =3D 1000 bytes total extra space needed in > cookie > > > > > (32 bytes and 1600 bytes if you want to be very conservative) > > > > > > > > Yeah, that's ridiculously large. With quite a few extensions > supported, > > > > > > and > > > > > > > many more unknown to us, the only way we might realistically ensure > that > > > > the ClientHello doesn't change is to save a hash snapshot at every > > > > > > boundary > > > > > > > where the cookie extension might be inserted or where an extension > might > > > > > > be > > > > > > > changed. SHA-2 has a fairly small state to capture, but that's sti= ll > > > > nearly unbounded state. With an amplification factor of up to 8, > > > > meaning > > > > that it could be more efficient to send the client its entire > > > > ClientHello > > > > in the cookie. > > > > > > I definitely won't claim that it is easy or straight-forward to do, I > do > > > claim > > > that it is possible. Yes, sometimes it may mean that sending the > literal > > > CH in > > > cookie may be more bandwidth efficient. > > > > > > And regarding the specific extension in question, to verify that it > didn't > > > change between Hello's it is only 2 bytes extra in cookie. If that is > too > > > much > > > already, I don't think that stateless HRR is something we will see in > > > implementations for years to come. > > > > > > -- > > > 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_______________________________________________ > > > TLS mailing list > > > TLS@ietf.org > > > https://www.ietf.org/mailman/listinfo/tls > > > -- > 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 --0000000000000f88a90581c78331 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Feb 13, 2019 at 4:12 AM Huber= t Kario <hkario@redhat.com> = wrote:
On Wednes= day, 13 February 2019 01:31:41 CET Eric Rescorla wrote:
> I concur with what I take to be MT's position here:
>
> 1. The client is clearly prohibited from changing most elements of the= CH
> (except for listed exceptions).
> 2. It's reasonable to check for and fail the handshake on any spec=
> violation except those where checking is explicitly forbidden (e.g., M= ust
> Be Zero but Must be Ignored)
> 3. Nothing in the spec requires the server to check for this condition= .

and what about values that technically can't change (as you noted yours= elf)
but they do change and the server does use them?

you are not suggesting that which value will be used (from first or second =
CH), or if the connection will be aborted, to be implementation dependant <= br> *by design* , do you?

I'n not sure = I understand your question, but I'll try to answer what I think it says= .

1. I do think that whether you continue the conn= ection or abort it is an implementation decision and I think that the way t= he spec is written says that.
2. I think the spec leaves open whe= ther you should use the first or second values, but I think implementations= should use the second value. It's not clear why one would want to use = the first.

To my knowledge, there was never a = WG discussion about this exact question, so we only have the spec to guide = us. Were we pre-publication I would have advocated for (a) leaving open whe= ther to abort and (b) requiring you to use the second value.
=
-Ekr



=


> -Ekr
>
> On Tue, Feb 12, 2019 at 4:53 AM Hubert Kario <hkario@redhat.com> wrote:
> > On Monday, 11 February 2019 00:43:39 CET Martin Thomson wrote: > > > On Fri, Feb 8, 2019, at 23:53, Hubert Kario wrote:
> > > > the cookie can be up to 2^16 bytes long, even if client= sends all 50
> > > > extensions and spaces them with unknown extensions betw= een, that's at
> >
> > most
> >
> > > > 20 bytes per extension =3D 1000 bytes total extra space= needed in cookie
> > > > (32 bytes and 1600 bytes if you want to be very conserv= ative)
> > >
> > > Yeah, that's ridiculously large.=C2=A0 With quite a few = extensions supported,
> >
> > and
> >
> > > many more unknown to us, the only way we might realistically= ensure that
> > > the ClientHello doesn't change is to save a hash snapsho= t at every
> >
> > boundary
> >
> > > where the cookie extension might be inserted or where an ext= ension might
> >
> > be
> >
> > > changed.=C2=A0 SHA-2 has a fairly small state to capture, bu= t that's still
> > > nearly unbounded state.=C2=A0 With an amplification factor o= f up to 8,
> > > meaning
> > > that it could be more efficient to send the client its entir= e
> > > ClientHello
> > > in the cookie.
> >
> > I definitely won't claim that it is easy or straight-forward = to do, I do
> > claim
> > that it is possible. Yes, sometimes it may mean that sending the = literal
> > CH in
> > cookie may be more bandwidth efficient.
> >
> > And regarding the specific extension in question, to verify that = it didn't
> > change between Hello's it is only 2 bytes extra in cookie. If= that is too
> > much
> > already, I don't think that stateless HRR is something we wil= l see in
> > implementations for years to come.
> >
> > --
> > 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=C2=A0 Brno, Czec= h
> > Republic_______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls


--
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=C2=A0 Brno, Czech Republic=
--0000000000000f88a90581c78331-- From nobody Wed Feb 13 06:52:19 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D25FE128701 for ; Wed, 13 Feb 2019 06:52:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 wLhpXdzk31-O for ; Wed, 13 Feb 2019 06:52:15 -0800 (PST) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6382F1274D0 for ; Wed, 13 Feb 2019 06:52:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 3D7FDBA3F for ; Wed, 13 Feb 2019 16:52:12 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id LdKFPNws4EZY for ; Wed, 13 Feb 2019 16:52:11 +0200 (EET) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id DB5362309 for ; Wed, 13 Feb 2019 16:52:10 +0200 (EET) Date: Wed, 13 Feb 2019 16:52:10 +0200 From: Ilari Liusvaara To: "" Message-ID: <20190213145210.GA17286@LK-Perkele-VII> References: <1549596678.898774.1653407000.2B2ACE8E@webmail.messagingengine.com> <1549980018.5oto7EOJll@pintsize.usersys.redhat.com> <103341275.xSgb4icBHy@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Server validation of a second ClientHello 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, 13 Feb 2019 14:52:18 -0000 On Wed, Feb 13, 2019 at 06:39:03AM -0800, Eric Rescorla wrote: > On Wed, Feb 13, 2019 at 4:12 AM Hubert Kario wrote: > > > you are not suggesting that which value will be used (from first or second > > CH), or if the connection will be aborted, to be implementation dependant > > *by design* , do you? > > > > I'n not sure I understand your question, but I'll try to answer what I > think it says. > > 1. I do think that whether you continue the connection or abort it is an > implementation decision and I think that the way the spec is written says > that. > 2. I think the spec leaves open whether you should use the first or second > values, but I think implementations should use the second value. It's not > clear why one would want to use the first. One reason is that if one has state-machine handshake processing, it is not difficult to do all the negotiation on the first pass, and then only grab the share on second pass, if it was missing (as it is the only retry condition). That is what I initially implemented in TLS library I did (later versions use stateless approach, with checks that the CHs match). -Ilari From nobody Wed Feb 13 07:05: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 A03F412867A for ; Wed, 13 Feb 2019 07:04:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Z4Yf5j0OS5N for ; Wed, 13 Feb 2019 07:04:58 -0800 (PST) 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 EA917126C7E for ; Wed, 13 Feb 2019 07:04:56 -0800 (PST) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x1DF1Ufx014733; Wed, 13 Feb 2019 15:04:56 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=wD5SmBq6M3v6T4uuFZ7Vn9yeN8SwOJih+NhFkhOeLB0=; b=GlhFKV6CdWqQecWfmpIjcz1UuwfXhz/FcjlAHYm0M/9Opm6zxBaZtZB7pAZniHUpbuPa ZoakIF36FubRajuFeaXdmFlvCvlyvJeUX0Q9Qt4zXWtv9eRitDkRmPPiuSDQMRj4/hKj f1dLkVRGzsv8JcAGs/FJfETX0GnZ6chOHSpAQdHznvQWCeRHArXWTZr3LrG6Gam7Amzn Qm2iuCeWLORt08MCGYBL/PR1otjrbb9RKqssSpYzPsKCBrvi1DFI2dOa1qFxfV/dkfO1 4TYKlU96W0HNVexVk1DNaRbVGIY1QvZNaoqcYS0XdDLI/7j7AaUKKPZmxkq2d2FCA9ke vQ== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0a-00190b01.pphosted.com with ESMTP id 2qm9mj9ys0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 13 Feb 2019 15:04:56 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x1DF1hmD024650; Wed, 13 Feb 2019 10:04:55 -0500 Received: from prod-mail-relay11.akamai.com ([172.27.118.250]) by prod-mail-ppoint1.akamai.com with ESMTP id 2qhu319emv-1; Wed, 13 Feb 2019 10:04:55 -0500 Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 060151FC74; Wed, 13 Feb 2019 15:04:55 +0000 (GMT) Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1gtw5m-00074x-BW; Wed, 13 Feb 2019 09:04:54 -0600 Date: Wed, 13 Feb 2019 09:04:54 -0600 From: Benjamin Kaduk To: Martin Thomson Cc: Hubert Kario , tls@ietf.org Message-ID: <20190213150454.GH13623@akamai.com> References: <1549596678.898774.1653407000.2B2ACE8E@webmail.messagingengine.com> <3192766.6rApcoU5jf@pintsize.usersys.redhat.com> <1549842219.465443.1655100776.7BADB4DA@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1549842219.465443.1655100776.7BADB4DA@webmail.messagingengine.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-13_08:, , 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=810 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902130109 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-13_08:, , 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=836 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902130109 Archived-At: Subject: Re: [TLS] Server validation of a second ClientHello 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, 13 Feb 2019 15:05:00 -0000 On Mon, Feb 11, 2019 at 10:43:39AM +1100, Martin Thomson wrote: > On Fri, Feb 8, 2019, at 23:53, Hubert Kario wrote: > > > > If we require or allow checking - and I think that we should definitely > > > allow a check - the details of the conditions under which a check might > > > fail aren't completely obvious for new extensions. A new extension might > > > be defined that has special handling in HelloRetryRequest, so it might be > > > reasonable to allow new extensions to be changed. > > > > yes, and we already had discussion on this ML about this: if the extension > > needs to change (based on protocol definition), the server MUST include it in > > HRR to signal to client, "yes, I do know about it, you can update it" and > > client MUST NOT change it otherwise > > I remember having that discussion, but I guess the only way it made it into the spec was as: > > - Other modifications that may be allowed by an extension defined in > the future and present in the HelloRetryRequest. > > Which isn't particularly direct, but I guess that's enough. I think I pressed for that text, on the grounds that the core spec should state the core expectations but try to assume as little as possible about future extensions' needs. It's pretty clear that this implies that (with the current set of extensions) a current server can rely on the "only extensions in HRR can change" property (modulo the existing exceptions in the core spec). -Ben From nobody Wed Feb 13 07:40: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 2FF1812D826 for ; Wed, 13 Feb 2019 07:40:00 -0800 (PST) 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 mZxJRnyFR9Wp for ; Wed, 13 Feb 2019 07:39:58 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D327129441 for ; Wed, 13 Feb 2019 07:39:58 -0800 (PST) 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 CB83A66967; Wed, 13 Feb 2019 15:39:57 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.83]) by smtp.corp.redhat.com (Postfix) with ESMTP id AFA2A60466; Wed, 13 Feb 2019 15:39:56 +0000 (UTC) From: Hubert Kario To: Eric Rescorla Cc: Martin Thomson , "" Date: Wed, 13 Feb 2019 16:39:49 +0100 Message-ID: <25414967.ZWlNe5bkUN@pintsize.usersys.redhat.com> In-Reply-To: References: <1549596678.898774.1653407000.2B2ACE8E@webmail.messagingengine.com> <103341275.xSgb4icBHy@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1674281.7d03IiLBUj"; 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.38]); Wed, 13 Feb 2019 15:39:57 +0000 (UTC) Archived-At: Subject: Re: [TLS] Server validation of a second ClientHello 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, 13 Feb 2019 15:40:00 -0000 --nextPart1674281.7d03IiLBUj Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Wednesday, 13 February 2019 15:39:03 CET Eric Rescorla wrote: > On Wed, Feb 13, 2019 at 4:12 AM Hubert Kario wrote: > > On Wednesday, 13 February 2019 01:31:41 CET Eric Rescorla wrote: > > > I concur with what I take to be MT's position here: > > >=20 > > > 1. The client is clearly prohibited from changing most elements of the > > > CH > > > (except for listed exceptions). > > > 2. It's reasonable to check for and fail the handshake on any spec > > > violation except those where checking is explicitly forbidden (e.g., > > > Must > > > Be Zero but Must be Ignored) > > > 3. Nothing in the spec requires the server to check for this conditio= n. > >=20 > > and what about values that technically can't change (as you noted > > yourself) > > but they do change and the server does use them? > >=20 > > you are not suggesting that which value will be used (from first or sec= ond > > CH), or if the connection will be aborted, to be implementation dependa= nt > > *by design* , do you? >=20 > I'n not sure I understand your question, but I'll try to answer what I > think it says. >=20 > 1. I do think that whether you continue the connection or abort it is an > implementation decision and I think that the way the spec is written says > that. > 2. I think the spec leaves open whether you should use the first or second > values, but I think implementations should use the second value. It's not > clear why one would want to use the first. because you have already parsed, verified and sanity-checked the first hell= o,=20 you already decided what kind of parameters will the connection use and you= 're=20 expecting just the values that can change to change and ignoring everything= =20 else, thus not wasting cycles on verifying the extensions twice... so it's not clear to me why you'd ever want to use the second one > To my knowledge, there was never a WG discussion about this exact questio= n, > so we only have the spec to guide us. Were we pre-publication I would have > advocated for (a) leaving open whether to abort and (b) requiring you to > use the second value. so you don't think this qualifies for Errata? side note: it is actually possible to check if the 2nd CH has minimal chang= es=20 in stateless HRR by replacing the extensions that can change with the hashe= s=20 of their values and then storing the overall hash of CH message together wi= th=20 hashes of the extensions that can change. When receiving the 2nd CH, we can= =20 replace the extensions that can change with respective hash values and then= =20 check if the overall hash still matches. That translates to something like = 4=20 hashes, two positions and two flags (for padding and early_data). Only this= =20 much is necessary to check perfectly if the CH is unchanged. The only=20 exception is pre_shared_key, but server behaviour with it is clearly define= d -=20 the server must use the values from 2nd CH as the selected_identity wouldn'= t=20 match otherwise and binders couldn't be verified. With addition of one more= =20 hash in the cookie the server may easily ensure that the identity it planne= d=20 to select remained in the CH. That's like 165 bytes when using non-truncate= d=20 sha-256 hashes. =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 --nextPart1674281.7d03IiLBUj 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+dkqjRuAHS9fUFAlxkOkUACgkQkqjRuAHS 9fWbWBAAndlMChb/mJfDKcG9UdWCbmppFjTxUB6do+M8UuKjxDjDPEXIqZdU0pz1 p2yJfjSFFfIenEMX8ZGTMcd6GcDnAXhPXXU3vXZuaZDwzyFw6pJVKPdKnIQ+I1iU cDTXw6KTmhixPYVm6dNuBgeATNpqSklp6ISaEGiyXD9+SJuo+mrlL2MC3BXDORN7 PPUk+Hubad2eUcyB4K0efo9hHV0Ra45LnJzbLTYjB8QPsSgGGXij9eSGMY39fHHM Nmd+Fq8LfYMTvVc8hZnYOr2+MV+TW95+oG5wtohF72M893Cd3KzQK37ZjEWypxe6 uNSAOElU5VcikYGdq9P8XX8muVh0euTBxCHOsMK5cPc7lMqs0EO+TUNLA5GecPC8 sBVs4CyuFEcciydscifJNw4TEsCf1RNnEXGLBNmry0z3hGP7pkz/JClHQEKYCvyU 6ec4bmMV2NMOFuUj3YsxbBZAnm7rmurAWI6alAPJgZUavLQadgJTQut8HmVZiV2m vVp9j07c0jiL3a4s8cG4UELFa7tLhxQEd/ZibLE/IyrJnVW66AiyfU/cU3aurHP7 YETt0sI9scn6Qd0xwc9XE+bFZDCszmMB93ZI1ws6dyyoWx+sGTMOEoderqdCO+tK s8VhKCxqVZDtI0miNsQCj6Gw9MVSUVDy8OdckA1Z+gUHbdjcXCg= =5SDV -----END PGP SIGNATURE----- --nextPart1674281.7d03IiLBUj-- From nobody Wed Feb 13 08:17: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 0741C130E6E for ; Wed, 13 Feb 2019 08:17:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cfFdn0zYngzP for ; Wed, 13 Feb 2019 08:17:46 -0800 (PST) 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 57B77131094 for ; Wed, 13 Feb 2019 08:17:46 -0800 (PST) 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 x1DGCxlw010573; Wed, 13 Feb 2019 16:17:46 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=ABdqySBC8UVdB4fcOAZX4fjU2P8idMqT0eO2aXvA9vo=; b=j1Z929tOjlePA5eABsxm/WyYvlvqiRGAF+bTXJ4M9CqJtLb2oRy26+ShMQ6tkBCfX+6Z pmJvF4c1waWs3nRP5clT/GI+CQa8MpTG/gy1mqsupTiAMUTB3F0BmZp/GgT7pep6J2oc osno4oCCRlsRx3YZRJhsi1SRLsY/1dKBfDkaGzgUA3tX7bEMtVZ4sqsEuP/a7wKON9sN /zTPeemC9p/ZTp4LoHSXA01RH5tNkzmlyeyLtWDYBYW2NtY02Ru0Cc9MjtJOAx1ZomAP EjET0lXiVSfxBqJ22k2GHk0fW+nnDfXdpw5cwpcoa3NjH/Y6O0kB9zmiTXVobsflTsu5 eg== Received: from prod-mail-ppoint4 (a96-6-114-87.deploy.static.akamaitechnologies.com [96.6.114.87] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2qm9m9aaxk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 13 Feb 2019 16:17:45 +0000 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x1DGGbJT030415; Wed, 13 Feb 2019 11:17:44 -0500 Received: from prod-mail-relay14.akamai.com ([172.27.17.39]) by prod-mail-ppoint4.akamai.com with ESMTP id 2qhu323dsj-1; Wed, 13 Feb 2019 11:17:44 -0500 Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay14.akamai.com (Postfix) with ESMTP id A3BEF8122C; Wed, 13 Feb 2019 16:17:44 +0000 (GMT) Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1gtxEF-0007Cz-OV; Wed, 13 Feb 2019 10:17:43 -0600 Date: Wed, 13 Feb 2019 10:17:43 -0600 From: Benjamin Kaduk To: Hubert Kario Cc: Eric Rescorla , "" Message-ID: <20190213161743.GI13623@akamai.com> References: <1549596678.898774.1653407000.2B2ACE8E@webmail.messagingengine.com> <103341275.xSgb4icBHy@pintsize.usersys.redhat.com> <25414967.ZWlNe5bkUN@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <25414967.ZWlNe5bkUN@pintsize.usersys.redhat.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-13_09:, , 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=743 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902130117 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-13_09:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=766 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902130116 Archived-At: Subject: Re: [TLS] Server validation of a second ClientHello 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, 13 Feb 2019 16:17:48 -0000 On Wed, Feb 13, 2019 at 04:39:49PM +0100, Hubert Kario wrote: > On Wednesday, 13 February 2019 15:39:03 CET Eric Rescorla wrote: > > > To my knowledge, there was never a WG discussion about this exact question, > > so we only have the spec to guide us. Were we pre-publication I would have > > advocated for (a) leaving open whether to abort and (b) requiring you to > > use the second value. > > so you don't think this qualifies for Errata? Errata are used for things that were errors at the time of publication (and, presumably, had WG consensus for being errors). Since there was apparently no WG consensus on this specific topic at time of publication, the errata process seems inappropriate. -Ben From nobody Wed Feb 13 08:32:35 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76D381271FF for ; Wed, 13 Feb 2019 08:32:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRSi7qPOkpqH for ; Wed, 13 Feb 2019 08:32:32 -0800 (PST) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5D7A1275F3 for ; Wed, 13 Feb 2019 08:32:31 -0800 (PST) Received: by mail-lj1-x232.google.com with SMTP id s5-v6so2527635ljd.12 for ; Wed, 13 Feb 2019 08:32:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9KsL+GJNYn1ZvOwah66mYua+37By2Dj0MAN59i1J3Fo=; b=eF2gxA44rQfNYjYDVOJ7Kozg8qRDz9gQ9GFz+Hjjvo7XTXpq0uFZ0T4l1tYWhGg2lH +dSTBI+8pU6hGbyySXMPkpCRxsUHev/x+xBZGeDOuINaEngDYBAQH+D4aAsPY51VY2Dm rsaHPOClJT0pHJRBVf1JF71F5tEBCZIUkZEq9sbDManmdUfA9cCBFEs9uimJP2UKnM04 LGFanWrLyV/nkEMgGM+pd+cQKtktGq1OYlKrYJFviQY1xzTMd7LGaMRJvBpSI+NcHPRZ 8rTqaSNegm++izM+w1RcaSOqEwAuLwPTj1IDHLE6SQ3lNTfAqoahbZdTFcO+aHq4iLHV 3ktg== 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=9KsL+GJNYn1ZvOwah66mYua+37By2Dj0MAN59i1J3Fo=; b=nlRIJeEanxxNB5gImRJ1olWRL7mdMcYpmFiyohcYUMiwsbvBLvL+M1L9+WQcBl860j 59cDww/dDkq3K5qeQ3Z85q2MJmlLV+5An9Ga9Pi3qY8BYUjzK7g7S+Ed7d5GenJM2v9u xl6K5pEF/M0Qbiw8eBoAq8BD53T+rdOEJchJ2ZnnnmuqrpdtExumKk4jgu215QVcY6Ru PF/YSPYnLv+mWAZB4IQVpumKKBMg7m8ojB1Ovi79OICWRy/Bgz9Y5eKP8j2onCS930tR eorF9haO+zMdmN9jbrs6qLGNwDiOza43aQlajXSI2uc5CCJhUsatTPhIexDLWZPzvlwR leUA== X-Gm-Message-State: AHQUAubkQ1Ekl9vTg70hukSNxYyQJspKPBAj887iELCNgWgvKudNHJ52 +OzuNHTCdxSRGD6B0KX0wGPufyAuksZ5tcoKueaHW2MZ X-Google-Smtp-Source: AHgI3IYoEPbGMDtLXh/li+fSCUVvUHkkICJByBUvrOxUIcCRYdp2KUFwNKcHlWJMdAsKKBaU7hNA+Og2RMar5w8cA9I= X-Received: by 2002:a2e:3c19:: with SMTP id j25mr840756lja.72.1550075549658; Wed, 13 Feb 2019 08:32:29 -0800 (PST) MIME-Version: 1.0 References: <1549596678.898774.1653407000.2B2ACE8E@webmail.messagingengine.com> <103341275.xSgb4icBHy@pintsize.usersys.redhat.com> <25414967.ZWlNe5bkUN@pintsize.usersys.redhat.com> In-Reply-To: <25414967.ZWlNe5bkUN@pintsize.usersys.redhat.com> From: Eric Rescorla Date: Wed, 13 Feb 2019 08:31:52 -0800 Message-ID: To: Hubert Kario Cc: Martin Thomson , "" Content-Type: multipart/alternative; boundary="000000000000834d8b0581c916ec" Archived-At: Subject: Re: [TLS] Server validation of a second ClientHello 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, 13 Feb 2019 16:32:34 -0000 --000000000000834d8b0581c916ec Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 13, 2019 at 7:39 AM Hubert Kario wrote: > On Wednesday, 13 February 2019 15:39:03 CET Eric Rescorla wrote: > > On Wed, Feb 13, 2019 at 4:12 AM Hubert Kario wrote: > > > On Wednesday, 13 February 2019 01:31:41 CET Eric Rescorla wrote: > > > > I concur with what I take to be MT's position here: > > > > > > > > 1. The client is clearly prohibited from changing most elements of > the > > > > CH > > > > (except for listed exceptions). > > > > 2. It's reasonable to check for and fail the handshake on any spec > > > > violation except those where checking is explicitly forbidden (e.g.= , > > > > Must > > > > Be Zero but Must be Ignored) > > > > 3. Nothing in the spec requires the server to check for this > condition. > > > > > > and what about values that technically can't change (as you noted > > > yourself) > > > but they do change and the server does use them? > > > > > > you are not suggesting that which value will be used (from first or > second > > > CH), or if the connection will be aborted, to be implementation > dependant > > > *by design* , do you? > > > > I'n not sure I understand your question, but I'll try to answer what I > > think it says. > > > > 1. I do think that whether you continue the connection or abort it is a= n > > implementation decision and I think that the way the spec is written sa= ys > > that. > > 2. I think the spec leaves open whether you should use the first or > second > > values, but I think implementations should use the second value. It's n= ot > > clear why one would want to use the first. > > because you have already parsed, verified and sanity-checked the first > hello, > you already decided what kind of parameters will the connection use and > you're > expecting just the values that can change to change and ignoring > everything > else, thus not wasting cycles on verifying the extensions twice... > As MT says, we use a stateless design, and we don't necessarily verify the entire CH prior to sending HRR. For instance, it's not necessary to do certificate selection and hence not to look at signature_algorithms. > so it's not clear to me why you'd ever want to use the second one > Well, clearly views differ on this, then. > > To my knowledge, there was never a WG discussion about this exact > question, > > so we only have the spec to guide us. Were we pre-publication I would > have > > advocated for (a) leaving open whether to abort and (b) requiring you t= o > > use the second value. > > so you don't think this qualifies for Errata? > What Ben said. -Ekr > > side note: it is actually possible to check if the 2nd CH has minimal > changes > in stateless HRR by replacing the extensions that can change with the > hashes > of their values and then storing the overall hash of CH message together > with > hashes of the extensions that can change. When receiving the 2nd CH, we > can > replace the extensions that can change with respective hash values and > then > check if the overall hash still matches. That translates to something lik= e > 4 > hashes, two positions and two flags (for padding and early_data). Only > this > much is necessary to check perfectly if the CH is unchanged. The only > exception is pre_shared_key, but server behaviour with it is clearly > defined - > the server must use the values from 2nd CH as the selected_identity > wouldn't > match otherwise and binders couldn't be verified. With addition of one > more > hash in the cookie the server may easily ensure that the identity it > planned > to select remained in the CH. That's like 165 bytes when using > non-truncated > sha-256 hashes. > > -- > 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 --000000000000834d8b0581c916ec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Feb 13, 2019 at 7:39 AM Huber= t Kario <hkario@redhat.com> = wrote:
On Wednes= day, 13 February 2019 15:39:03 CET Eric Rescorla wrote:
> On Wed, Feb 13, 2019 at 4:12 AM Hubert Kario <hkario@redhat.com> wrote:
> > On Wednesday, 13 February 2019 01:31:41 CET Eric Rescorla wrote:<= br> > > > I concur with what I take to be MT's position here:
> > >
> > > 1. The client is clearly prohibited from changing most eleme= nts of the
> > > CH
> > > (except for listed exceptions).
> > > 2. It's reasonable to check for and fail the handshake o= n any spec
> > > violation except those where checking is explicitly forbidde= n (e.g.,
> > > Must
> > > Be Zero but Must be Ignored)
> > > 3. Nothing in the spec requires the server to check for this= condition.
> >
> > and what about values that technically can't change (as you n= oted
> > yourself)
> > but they do change and the server does use them?
> >
> > you are not suggesting that which value will be used (from first = or second
> > CH), or if the connection will be aborted, to be implementation d= ependant
> > *by design* , do you?
>
> I'n not sure I understand your question, but I'll try to answe= r what I
> think it says.
>
> 1. I do think that whether you continue the connection or abort it is = an
> implementation decision and I think that the way the spec is written s= ays
> that.
> 2. I think the spec leaves open whether you should use the first or se= cond
> values, but I think implementations should use the second value. It= 9;s not
> clear why one would want to use the first.

because you have already parsed, verified and sanity-checked the first hell= o,
you already decided what kind of parameters will the connection use and you= 're
expecting just the values that can change to change and ignoring everything=
else, thus not wasting cycles on verifying the extensions twice...

As MT says, we use a stateless design, and we d= on't necessarily verify the entire
CH prior to sending HRR. F= or instance, it's not necessary to do certificate selection
a= nd hence not to look at signature_algorithms.

= =C2=A0
so it's not clear to me why you'd ever want to use the second one

Well, clearly views differ on this, then= .

=C2=A0
> To my knowledge, there was never a WG discussion about this exact ques= tion,
> so we only have the spec to guide us. Were we pre-publication I would = have
> advocated for (a) leaving open whether to abort and (b) requiring you = to
> use the second value.

so you don't think this qualifies for Errata?

=
What Ben said.

-Ekr



side note: it is actually possible to check if the 2nd CH has minimal chang= es
in stateless HRR by replacing the extensions that can change with the hashe= s
of their values and then storing the overall hash of CH message together wi= th
hashes of the extensions that can change. When receiving the 2nd CH, we can=
replace the extensions that can change with respective hash values and then=
check if the overall hash still matches. That translates to something like = 4
hashes, two positions and two flags (for padding and early_data). Only this=
much is necessary to check perfectly if the CH is unchanged. The only
exception is pre_shared_key, but server behaviour with it is clearly define= d -
the server must use the values from 2nd CH as the selected_identity wouldn&= #39;t
match otherwise and binders couldn't be verified. With addition of one = more
hash in the cookie the server may easily ensure that the identity it planne= d
to select remained in the CH. That's like 165 bytes when using non-trun= cated
sha-256 hashes.

--
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=C2=A0 Brno, Czech Republic=
--000000000000834d8b0581c916ec-- From nobody Wed Feb 13 08:48:12 2019 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4301200B3; Wed, 13 Feb 2019 08:48:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Liaison Statement Management Tool To: "Christopher Wood" , "Sean Turner" , "Joseph Salowey" Cc: Transport Layer Security Discussion List , itu-t-liaison@iab.org, Scott Mansfield , Sean Turner , Benjamin Kaduk , Christopher Wood , Joseph Salowey , Eric Rescorla , jhbaek@kisa.or.kr X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155007649018.9437.4803586925919644164.idtracker@ietfa.amsl.com> Date: Wed, 13 Feb 2019 08:48:10 -0800 Archived-At: Subject: [TLS] New Liaison Statement, "LS on SG17 work item X.ibc-iot: Security framework for using Identity Based Cryptography for IoT services over telecom networks" 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: Wed, 13 Feb 2019 16:48:10 -0000 Title: LS on SG17 work item X.ibc-iot: Security framework for using Identity Based Cryptography for IoT services over telecom networks Submission Date: 2019-02-13 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1629/ Please reply by 2019-06-30 From: Xiaoya Yang To: Christopher Wood ,Joseph Salowey ,Sean Turner Cc: Transport Layer Security Discussion List ,Scott Mansfield ,Sean Turner ,Benjamin Kaduk ,Christopher Wood ,Joseph Salowey ,itu-t-liaison@iab.org,Eric Rescorla Response Contacts: jhbaek@kisa.or.kr Technical Contacts: Purpose: For action Body: In our meeting (Geneva, 22-30 January 2019), ITU-T SG17 revised draft Recommendation of ITU-T X.ibc-iot Security framework for using identity based cryptography for IoT services over telecom networks which is now being developed in Q6/17, and targets its completion in next SG17 meeting in 27 August – 5 September 2019. The Recommendation includes using TLS 1.3 with identity-based signature algorithms for IoT security in Annex D. To facilitate the protocol with such capabilities, according to the TLS 1.3 specification, the SignatureScheme should be extended with values for such algorithms. Four algorithms have been considered, which are ECCSI specified in RFC 6507, IBS1, IBS2 and SM9_IBS standardized in ISO/IEC 14888-3. It would be very helpful if the values for the following signature schemes are assigned or reserved under your assistance: eccsi_sha256 ibs1_sha256 ibs2_sha256 sm9_ibs_sm3 Attachments: SG17-LS173-att https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2019-02-13-itu-t-sg-17-tls-ls-on-sg17-work-item-xibc-iot-security-framework-for-using-identity-based-cryptography-for-iot-services-over-tele-attachment-1.pdf From nobody Wed Feb 13 10:23:48 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9C78128766 for ; Wed, 13 Feb 2019 10:23:46 -0800 (PST) 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 OHBFmZMHo1MC for ; Wed, 13 Feb 2019 10:23:44 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D20601200B3 for ; Wed, 13 Feb 2019 10:23:44 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5AC8D356E5; Wed, 13 Feb 2019 18:23:44 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.83]) by smtp.corp.redhat.com (Postfix) with ESMTP id 696C660BE2; Wed, 13 Feb 2019 18:23:43 +0000 (UTC) From: Hubert Kario To: Eric Rescorla Cc: Martin Thomson , "" Date: Wed, 13 Feb 2019 19:23:42 +0100 Message-ID: <1676094.U5iVg0WcKh@pintsize.usersys.redhat.com> In-Reply-To: References: <1549596678.898774.1653407000.2B2ACE8E@webmail.messagingengine.com> <25414967.ZWlNe5bkUN@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2303770.9QZj3TJqWz"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Wed, 13 Feb 2019 18:23:44 +0000 (UTC) Archived-At: Subject: Re: [TLS] Server validation of a second ClientHello 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, 13 Feb 2019 18:23:47 -0000 --nextPart2303770.9QZj3TJqWz Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Wednesday, 13 February 2019 17:31:52 CET Eric Rescorla wrote: > On Wed, Feb 13, 2019 at 7:39 AM Hubert Kario wrote: > > On Wednesday, 13 February 2019 15:39:03 CET Eric Rescorla wrote: > > > I'n not sure I understand your question, but I'll try to answer what I > > > think it says. > > >=20 > > > 1. I do think that whether you continue the connection or abort it is= an > > > implementation decision and I think that the way the spec is written > > > says > > > that. > > > 2. I think the spec leaves open whether you should use the first or > > > second > > > values, but I think implementations should use the second value. It's > > > not > > > clear why one would want to use the first. > >=20 > > because you have already parsed, verified and sanity-checked the first > > hello, > > you already decided what kind of parameters will the connection use and > > you're > > expecting just the values that can change to change and ignoring > > everything > > else, thus not wasting cycles on verifying the extensions twice... > >=20 > > so it's not clear to me why you'd ever want to use the second one >=20 > Well, clearly views differ on this, then. yes, that was my point, and the reason why I'd like to see clarification or= =20 agreement on expected behaviour so if my understanding is correct, to do that, we would need to agree on a = new=20 RFC that clarifies such issues =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 --nextPart2303770.9QZj3TJqWz 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+dkqjRuAHS9fUFAlxkYK4ACgkQkqjRuAHS 9fUamQ//YbthzpGrTYeVSgLGk50ceJoS7GAm0VqBdiCDk1zTytBNJkEDjeSUTD+1 pYAkhcbQ5FgwI7kHmO7zFMBsoXn8fAY5gV6lV4JjirO/nc6XI0RfDF1nap+90h1j 9r/qDvG5E5ALPW4hVjcte9u5qloj66juAXDlew4h/B6i8gEbsJEEjNm2KxWUafj0 H46hYl4WRQmScJDQ9GeMDKQzywAk2VTXpYFG/Dpv1FkALrwRKC2sb+61Aq40msQ1 QjLJSS1qS26877xlwQ8gdx8bV2Db52RLDpn8PKNh/CxWJZUYDqRHUpn0HpgufDwk 7XUioGABeGvlyoXymcJ8wY2kGmzxNiyquXoZ7MBSs4l3YQEhofQUQLWNLM57Iw7d jKEkpQLPM+UBwS19S8YmpLv1WZ8Gic8HdgXR3EiEV64FaAPfRZQxshD7NmBLHQ0C Na/ssCkNe+7QoNJSgIZnlqvZV38uwTaMDA/T8hDo3HB1w60aHcKiFTt+oKCq/03a rYajz/R0Adv09uk2zqhHamvVfkLbZm+OCi/+KfwWPPsIaxc3cwiSdNOwijMFy22C IefVoGTPIyiDGNqQvzpaKD7nlK2eCA52Lgy0JNOQ8pTepr/RuaDklmhey7aXYRki LxwGY+q22qNR1z9B/Fe45pNxw8cFyc4453JPX20VVf5m80BkD4A= =Fyfa -----END PGP SIGNATURE----- --nextPart2303770.9QZj3TJqWz-- From nobody Wed Feb 13 11:01:56 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18CB5126F72 for ; Wed, 13 Feb 2019 11:01:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRtb0_Tj8v6R for ; Wed, 13 Feb 2019 11:01:52 -0800 (PST) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D9C11200D7 for ; Wed, 13 Feb 2019 11:01:52 -0800 (PST) Received: by mail-lj1-x231.google.com with SMTP id v16so2948154ljg.13 for ; Wed, 13 Feb 2019 11:01:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wECeznk6gKzx04vHbYtacO/DjLLgz0bkn6tWZnP37L0=; b=pctnhmZOllsKORPmuMkEYFHOKc5XIBMSg3uRNKvjeWjkwV6c9sXc2NTB3wUjYwhEft 99zHwAXoHrFunEZs2I+9c0mARqHOQJ3VUCukup2swGQMHtYRJbMZKA3vHGGx8/+gk6Fb tdqtYV5qYjxvA1UpIWOi8L5Lt9OidktSygR5ANC/9Pl1bwXfKqS2q1SSFgao2ANxM94V ylaiK6Gp06AAIInEWHxArKEMAOk0TIRsY45eGQxxLx91WH8oicLoxZ2sH2DGhRyO9WST AzfPuGmERjTikiY4ByiNWZaCfPaIwVgaR+YvJJauTB6EXPcnkfDhrfnjevPpg19pYORR M7ig== 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=wECeznk6gKzx04vHbYtacO/DjLLgz0bkn6tWZnP37L0=; b=jayGVkxnbwIuNLAVOzwUVzzTiDLBplc9gpER9arONr+fHvXCYBUoQUheyChF7kE0Q5 e0sXXj9vqK09xzEA0JRYSyzUcS5MIw+DXVhko04ocLRjnopykEfi0XqJUlXE0IJlBAg/ tbErzwk8Q+VeHicFnwIOlTYbCIb+k4MjqYY/fOHK/9nTTRXOChFSPJ58ff8Fm6PUBfsD nue9Kgmc2/sFTWSN6kLBdwdQ0nI7JuBVAgqV+LaztXqCATCyV1A8k9mATZFXSJfhsckS 9614kAVvJ2horX8ofmdfPOTbpm7QbjDOej9POWEpWDU1K2ZWeo7DHU8e7fdfJoLkrIlx 6JDQ== X-Gm-Message-State: AHQUAuZAf0z0KFTD83xu1ZUV9TJtEEpEiZQZRvphNFgsD6qY/TdzmYrs kRO1o790pQV6nfbfaMbXleWgaSqa31ExUJU0+q08tQ== X-Google-Smtp-Source: AHgI3IbLbykzpR2ITZWuU4dN9/z9R2p0D7uSUeSLP6NEDxXppx3yCL5t91BXxUCtmwQFOO+gZYe5h7j8d5rPYLG7gyc= X-Received: by 2002:a2e:8951:: with SMTP id b17-v6mr1189376ljk.86.1550084509004; Wed, 13 Feb 2019 11:01:49 -0800 (PST) MIME-Version: 1.0 References: <1549596678.898774.1653407000.2B2ACE8E@webmail.messagingengine.com> <25414967.ZWlNe5bkUN@pintsize.usersys.redhat.com> <1676094.U5iVg0WcKh@pintsize.usersys.redhat.com> In-Reply-To: <1676094.U5iVg0WcKh@pintsize.usersys.redhat.com> From: Eric Rescorla Date: Wed, 13 Feb 2019 11:01:10 -0800 Message-ID: To: Hubert Kario Cc: Martin Thomson , "" Content-Type: multipart/alternative; boundary="0000000000008808c60581cb2c72" Archived-At: Subject: Re: [TLS] Server validation of a second ClientHello 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, 13 Feb 2019 19:01:55 -0000 --0000000000008808c60581cb2c72 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 13, 2019 at 10:23 AM Hubert Kario wrote: > On Wednesday, 13 February 2019 17:31:52 CET Eric Rescorla wrote: > > On Wed, Feb 13, 2019 at 7:39 AM Hubert Kario wrote: > > > On Wednesday, 13 February 2019 15:39:03 CET Eric Rescorla wrote: > > > > I'n not sure I understand your question, but I'll try to answer wha= t > I > > > > think it says. > > > > > > > > 1. I do think that whether you continue the connection or abort it > is an > > > > implementation decision and I think that the way the spec is writte= n > > > > says > > > > that. > > > > 2. I think the spec leaves open whether you should use the first or > > > > second > > > > values, but I think implementations should use the second value. It= 's > > > > not > > > > clear why one would want to use the first. > > > > > > because you have already parsed, verified and sanity-checked the firs= t > > > hello, > > > you already decided what kind of parameters will the connection use a= nd > > > you're > > > expecting just the values that can change to change and ignoring > > > everything > > > else, thus not wasting cycles on verifying the extensions twice... > > > > > > so it's not clear to me why you'd ever want to use the second one > > > > Well, clearly views differ on this, then. > > yes, that was my point, and the reason why I'd like to see clarification > or > agreement on expected behaviour > > so if my understanding is correct, to do that, we would need to agree on = a > new > RFC that clarifies such issues > I'm not so sure. - I don't think that the specification ought to require checking and/or not checking. - I don't think it should require using the first CH, and unsure whether we should require use of the second CH, but it doesn't sound like there's consensus on that. -Ekr --=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 --0000000000008808c60581cb2c72 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Feb 13, 2019 at 10:23 AM Hube= rt Kario <hkario@redhat.com>= wrote:
On Wedne= sday, 13 February 2019 17:31:52 CET Eric Rescorla wrote:
> On Wed, Feb 13, 2019 at 7:39 AM Hubert Kario <hkario@redhat.com> wrote:
> > On Wednesday, 13 February 2019 15:39:03 CET Eric Rescorla wrote:<= br> > > > I'n not sure I understand your question, but I'll tr= y to answer what I
> > > think it says.
> > >
> > > 1. I do think that whether you continue the connection or ab= ort it is an
> > > implementation decision and I think that the way the spec is= written
> > > says
> > > that.
> > > 2. I think the spec leaves open whether you should use the f= irst or
> > > second
> > > values, but I think implementations should use the second va= lue. It's
> > > not
> > > clear why one would want to use the first.
> >
> > because you have already parsed, verified and sanity-checked the = first
> > hello,
> > you already decided what kind of parameters will the connection u= se and
> > you're
> > expecting just the values that can change to change and ignoring<= br> > > everything
> > else, thus not wasting cycles on verifying the extensions twice..= .
> >
> > so it's not clear to me why you'd ever want to use the se= cond one
>
> Well, clearly views differ on this, then.

yes, that was my point, and the reason why I'd like to see clarificatio= n or
agreement on expected behaviour

so if my understanding is correct, to do that, we would need to agree on a = new
RFC that clarifies such issues

I'm = not so sure.

- I don't think that the spe= cification ought to require checking and/or not checking.
- I don= 't think it should require using the first CH, and unsure whether we sh= ould require use of the second CH, but it doesn't sound like there'= s consensus on that.

-Ekr

=


--
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=C2=A0 Brno, Czech Republic=
--0000000000008808c60581cb2c72-- From nobody Wed Feb 13 11:37:48 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4163012E036 for ; Wed, 13 Feb 2019 11:37:47 -0800 (PST) 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 T6D21NzmbjmQ for ; Wed, 13 Feb 2019 11:37:44 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF752129532 for ; Wed, 13 Feb 2019 11:37:44 -0800 (PST) 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 8113789AD9; Wed, 13 Feb 2019 19:37:43 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.83]) by smtp.corp.redhat.com (Postfix) with ESMTP id 5F01C5D9C6; Wed, 13 Feb 2019 19:37:42 +0000 (UTC) From: Hubert Kario To: Eric Rescorla Cc: Martin Thomson , "" Date: Wed, 13 Feb 2019 20:37:41 +0100 Message-ID: <3869497.s3jJ9zoz9Q@pintsize.usersys.redhat.com> In-Reply-To: References: <1549596678.898774.1653407000.2B2ACE8E@webmail.messagingengine.com> <1676094.U5iVg0WcKh@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3141772.xzWd99NtH6"; 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.26]); Wed, 13 Feb 2019 19:37:43 +0000 (UTC) Archived-At: Subject: Re: [TLS] Server validation of a second ClientHello 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, 13 Feb 2019 19:37:47 -0000 --nextPart3141772.xzWd99NtH6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Wednesday, 13 February 2019 20:01:10 CET Eric Rescorla wrote: > On Wed, Feb 13, 2019 at 10:23 AM Hubert Kario wrote: > > On Wednesday, 13 February 2019 17:31:52 CET Eric Rescorla wrote: > > > On Wed, Feb 13, 2019 at 7:39 AM Hubert Kario wrot= e: > > > > On Wednesday, 13 February 2019 15:39:03 CET Eric Rescorla wrote: > > > > > I'n not sure I understand your question, but I'll try to answer w= hat > >=20 > > I > >=20 > > > > > think it says. > > > > >=20 > > > > > 1. I do think that whether you continue the connection or abort it > >=20 > > is an > >=20 > > > > > implementation decision and I think that the way the spec is writ= ten > > > > > says > > > > > that. > > > > > 2. I think the spec leaves open whether you should use the first = or > > > > > second > > > > > values, but I think implementations should use the second value. > > > > > It's > > > > > not > > > > > clear why one would want to use the first. > > > >=20 > > > > because you have already parsed, verified and sanity-checked the fi= rst > > > > hello, > > > > you already decided what kind of parameters will the connection use > > > > and > > > > you're > > > > expecting just the values that can change to change and ignoring > > > > everything > > > > else, thus not wasting cycles on verifying the extensions twice... > > > >=20 > > > > so it's not clear to me why you'd ever want to use the second one > > >=20 > > > Well, clearly views differ on this, then. > >=20 > > yes, that was my point, and the reason why I'd like to see clarification > > or > > agreement on expected behaviour > >=20 > >=20 > > so if my understanding is correct, to do that, we would need to agree o= n a > > new > > RFC that clarifies such issues >=20 > I'm not so sure. I said "I'd like", yes, I am aware that not everybody shares my views on th= ose=20 topics, but *if* we reach a conclusion and decide to update/clarify RFC 844= 6,=20 it would require publishing a new RFC (depending on intrusiveness of it, it= =20 may be just "Informational" or it may need to be "Standards Track", with=20 everything that it entails), wouldn't it? =20 > - I don't think that the specification ought to require checking and/or n= ot > checking. > - I don't think it should require using the first CH, and unsure whether = we > should require use of the second CH, but it doesn't sound like there's > consensus on that. it all depends on your threat model, if leaking information which kind of=20 implementation you are running is useful information to the attacker, then= =20 having multiple implementations that are indistinguishable on protocol leve= l=20 may be very desirable and in this specific example of record_size_limit, lack of agreement over=20 extension from which Client Hello takes precedence will easily lead to=20 interoperability failures =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 --nextPart3141772.xzWd99NtH6 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+dkqjRuAHS9fUFAlxkcgUACgkQkqjRuAHS 9fWp5xAAmCM2vEd1WHQOx6He5AIwRI3SQAp0RzVWMsICTROHZ0ZY/cAJneD4pgZj PvWn6Wt+c9US1SHE2vpje8BxyNKDt9yefORzgxWCdUMFdfgpvKF8rdl51s9Wmfv+ sng1YofXtuv2uGlU4PuHzBhUc59mKxdbQjlz9NFlJRBFzLA6lklGtPzgU3OIyv5i ilDKRetM2b9c92eaanQnOSvo5S8FPfkKhH3CdnXzmqq02oaHZOpxVBMZt48o3CUt 9c22wbAw7rZRPrnNWzWRDLCIG6LKcfR02ByodsQ0fJBUb12a7Zo3Nu3GYWC/3KQB LpIcgdWvUOmVFWbsmpqfi2WD589Druh1mgrI+kiA+Xw4MN15QqGKHce/9BwtgD3X mfynu0gWtoB120xolWjBncIBdbrfWwgHw33o3epr/7uoz+GxSXMyn3qdDOxTQv2a btgNX35j2gHAOkROpYUHfapMHgdyFe00+y136V0YPeYlq4pzYnU+LuobseZI4B3I jR6Ay1CrGMEOzYfwo8r0NoCjMsF0GNBuYJfrRB4xRK+uq1wH8UWMXqGN3wgTFIZZ Vki+18felUEJSFO3apc9MdSUTU47pHzkRK0r5CznhwOAWRXfv5BawRbVyYcz7hID KSpHQHA3U2Z4fv7po1pnuaGCj1oJIpX2f92PvZsn5+6P2rqCiXc= =kUrH -----END PGP SIGNATURE----- --nextPart3141772.xzWd99NtH6-- From nobody Wed Feb 13 12:28: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 B7F8D1200B3 for ; Wed, 13 Feb 2019 12:28:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2htWtabfKNkO for ; Wed, 13 Feb 2019 12:28:28 -0800 (PST) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 373E5128B01 for ; Wed, 13 Feb 2019 12:28:28 -0800 (PST) Received: by mail-lf1-x12d.google.com with SMTP id q12so2845897lfm.0 for ; Wed, 13 Feb 2019 12:28:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gFMtgZY8qnFT4d/yAtYxGXK+zlojAtAGzWbI0yVSlwE=; b=BmSDsxJrwLzkPTNZ4BVCQWk4PwyAlH3+vuWgWFf2YaC/ZhyfNXPcIPXcrnlBKm2Kk7 qZ5Poi80pKeEpVE9GoyI/FGPiYrsvZ2PMG+cUyNqQL5lEHA9VfkQRip7s3uUHA4k3/3r Ve7Fxmbe0x17GQQqyvqNU31/gc1wtUY4RBK4RRD6fFdcyuRZeSuO7P0N9X9MNzFQcyFh ljHtmkGFhdgXk25oG4TXPM+3YLimg+DEsUUeNc02nJSKMZ88rH8jJ+tRwUGj8Uo29DnO 3QQn6VjUp0qZ+M6iLvelQy+Uh8Y339nN86M5TYnF08DHzV551iE0WTQMOP6mHIlF/mKr 05Gg== 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=gFMtgZY8qnFT4d/yAtYxGXK+zlojAtAGzWbI0yVSlwE=; b=eHYCf9DlBkG9YosQBOYHlA8Vx5o7u1hT9LeiqL1dy6NHkW+XKBmaX4ZPQdV+RA1nLB sZXm7LXjZSaG6kkyPKWIvhu5/Jsa28G3QSPQHSmzzDWI6M2gCuSJk0dv8gmIS4vsGlz/ Yoxcu6q92y88OcuqqWQWytFWaTLtyoYb59LoJwmuB6jB8pz+A3f5MoW0m3FD9jbI3ZKS mab2zDhIs+hgbEJsmZVRIeB72Sixb8+n+VAjWWnYS2tp+tMW7lxKHk8ZuFhyK6kFFjdy 2QYiMRuXXHGFcMgoZGKrNhU7FPariwjMC/rTN1eOoPzIyvFelg6ALxQnKig6VEDlw3jm 1yEg== X-Gm-Message-State: AHQUAuY985m5XazbxMqRfg3WWYJXV6l/MdDFD4ajcHfi6U9FYaMcUTC9 J8gMt4GpTx5sNHHDIPCU0r5EHcGWU9A77oO7qNzFkA== X-Google-Smtp-Source: AHgI3IYodFeaoamPiuQ3WG9pJw26LwZJKSPWS0NDI0uTAnEAY0cgIIG0XxxsalQBKaY5D2lfg+TJAdUklNZBGztnX24= X-Received: by 2002:a19:2d44:: with SMTP id t4mr4202lft.90.1550089705865; Wed, 13 Feb 2019 12:28:25 -0800 (PST) MIME-Version: 1.0 References: <1549596678.898774.1653407000.2B2ACE8E@webmail.messagingengine.com> <1676094.U5iVg0WcKh@pintsize.usersys.redhat.com> <3869497.s3jJ9zoz9Q@pintsize.usersys.redhat.com> In-Reply-To: <3869497.s3jJ9zoz9Q@pintsize.usersys.redhat.com> From: Eric Rescorla Date: Wed, 13 Feb 2019 12:27:46 -0800 Message-ID: To: Hubert Kario Cc: Martin Thomson , "" Content-Type: multipart/alternative; boundary="00000000000049e04f0581cc621a" Archived-At: Subject: Re: [TLS] Server validation of a second ClientHello 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, 13 Feb 2019 20:28:32 -0000 --00000000000049e04f0581cc621a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 13, 2019 at 11:37 AM Hubert Kario wrote: > On Wednesday, 13 February 2019 20:01:10 CET Eric Rescorla wrote: > > On Wed, Feb 13, 2019 at 10:23 AM Hubert Kario wrote= : > > > On Wednesday, 13 February 2019 17:31:52 CET Eric Rescorla wrote: > > > > On Wed, Feb 13, 2019 at 7:39 AM Hubert Kario > wrote: > > > > > On Wednesday, 13 February 2019 15:39:03 CET Eric Rescorla wrote: > > > > > > I'n not sure I understand your question, but I'll try to answer > what > > > > > > I > > > > > > > > > think it says. > > > > > > > > > > > > 1. I do think that whether you continue the connection or abort > it > > > > > > is an > > > > > > > > > implementation decision and I think that the way the spec is > written > > > > > > says > > > > > > that. > > > > > > 2. I think the spec leaves open whether you should use the firs= t > or > > > > > > second > > > > > > values, but I think implementations should use the second value= . > > > > > > It's > > > > > > not > > > > > > clear why one would want to use the first. > > > > > > > > > > because you have already parsed, verified and sanity-checked the > first > > > > > hello, > > > > > you already decided what kind of parameters will the connection u= se > > > > > and > > > > > you're > > > > > expecting just the values that can change to change and ignoring > > > > > everything > > > > > else, thus not wasting cycles on verifying the extensions twice..= . > > > > > > > > > > so it's not clear to me why you'd ever want to use the second one > > > > > > > > Well, clearly views differ on this, then. > > > > > > yes, that was my point, and the reason why I'd like to see > clarification > > > or > > > agreement on expected behaviour > > > > > > > > > so if my understanding is correct, to do that, we would need to agree > on a > > > new > > > RFC that clarifies such issues > > > > I'm not so sure. > > I said "I'd like", yes, I am aware that not everybody shares my views on > those > topics, but *if* we reach a conclusion and decide to update/clarify RFC > 8446, > it would require publishing a new RFC (depending on intrusiveness of it, > it > may be just "Informational" or it may need to be "Standards Track", with > everything that it entails), wouldn't it? > The current document does not mandate any particular implementation. If you want to require a specific implementation then would need a new standards track RFC. > > - I don't think that the specification ought to require checking and/or > not > > checking. > > - I don't think it should require using the first CH, and unsure whethe= r > we > > should require use of the second CH, but it doesn't sound like there's > > consensus on that. > > it all depends on your threat model, if leaking information which kind of > implementation you are running is useful information to the attacker, the= n > having multiple implementations that are indistinguishable on protocol > level > may be very desirable > There are an enormous number of ways in which TLS stacks can vary and requiring indistinguishable behavior is not a goal of the TLS spec. > and in this specific example of record_size_limit, lack of agreement over > extension from which Client Hello takes precedence will easily lead to > interoperability failures > You're forbidden to change that value, so you'll only see interop failures if the client is already nonconformant. -Ekr > -- > 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 --00000000000049e04f0581cc621a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Feb 13, 2019 at 11:37 AM Hube= rt Kario <hkario@redhat.com>= wrote:
On Wedne= sday, 13 February 2019 20:01:10 CET Eric Rescorla wrote:
> On Wed, Feb 13, 2019 at 10:23 AM Hubert Kario <hkario@redhat.com> wrote:
> > On Wednesday, 13 February 2019 17:31:52 CET Eric Rescorla wrote:<= br> > > > On Wed, Feb 13, 2019 at 7:39 AM Hubert Kario <hkario@redhat.com> wrote= :
> > > > On Wednesday, 13 February 2019 15:39:03 CET Eric Rescor= la wrote:
> > > > > I'n not sure I understand your question, but I= 'll try to answer what
> >
> > I
> >
> > > > > think it says.
> > > > >
> > > > > 1. I do think that whether you continue the connec= tion or abort it
> >
> > is an
> >
> > > > > implementation decision and I think that the way t= he spec is written
> > > > > says
> > > > > that.
> > > > > 2. I think the spec leaves open whether you should= use the first or
> > > > > second
> > > > > values, but I think implementations should use the= second value.
> > > > > It's
> > > > > not
> > > > > clear why one would want to use the first.
> > > >
> > > > because you have already parsed, verified and sanity-ch= ecked the first
> > > > hello,
> > > > you already decided what kind of parameters will the co= nnection use
> > > > and
> > > > you're
> > > > expecting just the values that can change to change and= ignoring
> > > > everything
> > > > else, thus not wasting cycles on verifying the extensio= ns twice...
> > > >
> > > > so it's not clear to me why you'd ever want to = use the second one
> > >
> > > Well, clearly views differ on this, then.
> >
> > yes, that was my point, and the reason why I'd like to see cl= arification
> > or
> > agreement on expected behaviour
> >
> >
> > so if my understanding is correct, to do that, we would need to a= gree on a
> > new
> > RFC that clarifies such issues
>
> I'm not so sure.

I said "I'd like", yes, I am aware that not everybody shares = my views on those
topics, but *if* we reach a conclusion and decide to update/clarify RFC 844= 6,
it would require publishing a new RFC (depending on intrusiveness of it, it=
may be just "Informational" or it may need to be "Standards = Track", with
everything that it entails), wouldn't it?

The current document does not mandate any particular implementation.= If you want to require a specific implementation then would need a new sta= ndards track RFC.


> - I don't think that the specification ought to require checking a= nd/or not
> checking.
> - I don't think it should require using the first CH, and unsure w= hether we
> should require use of the second CH, but it doesn't sound like the= re's
> consensus on that.

it all depends on your threat model, if leaking information which kind of <= br> implementation you are running is useful information to the attacker, then =
having multiple implementations that are indistinguishable on protocol leve= l
may be very desirable

There are an enor= mous number of ways in which TLS stacks can vary and requiring indistinguis= hable behavior is not a goal of the TLS spec.

=C2= =A0
and in this specific example of record_size_limit, lack of agreement over <= br> extension from which Client Hello takes precedence will easily lead to
interoperability failures

You're fo= rbidden to change that value, so you'll only see interop failures if th= e client is already nonconformant.

-Ekr
=

--
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=C2=A0 Brno, Czech Republic=
--00000000000049e04f0581cc621a-- From nobody Wed Feb 13 14:16: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 4BD2912F18C for ; Wed, 13 Feb 2019 14:16:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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] 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 chsP2NG7U7VY for ; Wed, 13 Feb 2019 14:16:04 -0800 (PST) Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A7DB12F295 for ; Wed, 13 Feb 2019 14:16:04 -0800 (PST) Received: by mail-pl1-x636.google.com with SMTP id s1so1871578plp.9 for ; Wed, 13 Feb 2019 14:16:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=/4EgQj3374JDghZOUsryHGkt6VWeOmTJc9WWmXVhmaA=; b=MNv+7aJC2XRvALGGoHVVj/xWJ8S6BfzBcwyr83HHzL/OlTjELkOoDvT51cFc/YeVh6 OaxD8QWGW+hadIIK/jmzDiNADNoVOid51tGF5iNdmzJlFEVoattQY0KrScJgWqVXyK2I 4K8eKpgdOqDw5vSKCnVR/3N4Yaj1+FjCIZK79Yco1eu6iaZjZotJVkbsrssfQlUMhC0E 8CM2enOlMR8HXKkSOCbzHClpZnmj8/KUIYO2Z/+t54jSLyS5UWYj/xJBLpHJmhR8TTwc sfcD2cUxo+YiGhVQoUi55jZzsLbmhj1sx7X/mjZIMEuatUE6gL/DdNuzfFH/6RV8nadq x4lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=/4EgQj3374JDghZOUsryHGkt6VWeOmTJc9WWmXVhmaA=; b=nEYG4hhVSAlPvmcntmOWqWCvgWUOpCsrF7Y6OZ9WrQewmD3T0CTXVOpch08uQhJXRc NpnejoMGQOC8XxxnB2nk4MyPC+QwERQITwyygBmfFGuwyxiwR1yi90vuOTmSVS8Xlkfi btjCSTSah+4h0u4u4OsgLUEeOvszV334bHfKYJnQd65tfMS5ntx443/Mc5YIVfPGVqIz B+kT6F3wI2RYIaZa6GzivIpVsNBjjyh8x2wi/RfDMEayj2kKkVAqrWe0Hddv1ZEYJeY9 TQ3NEz3U/wUgS0vI35BO1CQWd6aZLQLx+IvMRqjscjG1/1eBLmdq3t2R7slk6ClxaPpQ 8VDg== X-Gm-Message-State: AHQUAuaX0ejrBCKsC5LwnvCQo/Ac+3GNRsBp63j1j5WHy9BIhUvwyPKQ odXXarxOsqK0pGARU2c05d0+2N+j X-Google-Smtp-Source: AHgI3IYwMOFr8JwZdn2clc1mDF/WP+5QSAmu72mkTJYXjpJOCZ5M2lQSeqDnO0c+HL5MizleP+oByg== X-Received: by 2002:a17:902:2dc3:: with SMTP id p61mr481500plb.166.1550096163087; Wed, 13 Feb 2019 14:16:03 -0800 (PST) Received: from [172.16.33.70] ([144.178.28.6]) by smtp.gmail.com with ESMTPSA id d26sm423865pfn.12.2019.02.13.14.16.01 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Feb 2019 14:16:02 -0800 (PST) From: "Christopher Wood" To: "TLS WG" Date: Wed, 13 Feb 2019 14:15:57 -0800 X-Mailer: MailMate (1.12.4r5594) Message-ID: <714E43FA-3660-485A-8E50-04EE43F8DA2E@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [TLS] ESNI PRs #124 and #125: Improving ESNI Robustness and GREASE 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, 13 Feb 2019 22:16:07 -0000 Hi folks, PRs [1] and [2] need a little more review before we merge since they’re non-trivial changes. Please have a look and let the list know if you have objections with the contents therein. Otherwise, we will merge them by the end of the next week. Thanks! Chris (no hat) [1] https://github.com/tlswg/draft-ietf-tls-esni/pull/124 [2] https://github.com/tlswg/draft-ietf-tls-esni/pull/125 From nobody Wed Feb 13 15:00:19 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 529E0130E90 for ; Wed, 13 Feb 2019 15:00:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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] 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 A_4Fkvc16SSJ for ; Wed, 13 Feb 2019 15:00:14 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2EA4130DC4 for ; Wed, 13 Feb 2019 15:00:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 46679BE2F; Wed, 13 Feb 2019 23:00:07 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBemAu6B5LsN; Wed, 13 Feb 2019 23:00:05 +0000 (GMT) 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 67A30BE2C; Wed, 13 Feb 2019 23:00:05 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1550098805; bh=IIbv1OwjgOnPyI7Q1seUKdPw1a3jGn6hybGu63556fQ=; h=To:References:From:Subject:Date:In-Reply-To:From; b=o86skkfihW4SzhxOFbjhYtzc+KJrg4becL/7PW0SgZUgvJrlAMRxKAH1INyUCi7we U6CFzSHUUk+nA4T8WC6yvQ80ypv+ausCjaf4RCxUO5K7lBIxFUeOxQQAi2T3kuKNfQ jt993J3oeXO6OKkp/+KY3UGctRiHRYsqHxCxqqzg= To: Christopher Wood , TLS WG References: <714E43FA-3660-485A-8E50-04EE43F8DA2E@gmail.com> 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: Date: Wed, 13 Feb 2019 23:00:04 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <714E43FA-3660-485A-8E50-04EE43F8DA2E@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="x43yYuFBtZyA5SLeGc7UDDQkaYBCNPhua" Archived-At: Subject: Re: [TLS] ESNI PRs #124 and #125: Improving ESNI Robustness and GREASE 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, 13 Feb 2019 23:00:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --x43yYuFBtZyA5SLeGc7UDDQkaYBCNPhua Content-Type: multipart/mixed; boundary="bZ08MGbKYdkX1hT379PQOHzCdSFrl9SM9"; protected-headers="v1" From: Stephen Farrell To: Christopher Wood , TLS WG Message-ID: Subject: Re: [TLS] ESNI PRs #124 and #125: Improving ESNI Robustness and GREASE References: <714E43FA-3660-485A-8E50-04EE43F8DA2E@gmail.com> In-Reply-To: <714E43FA-3660-485A-8E50-04EE43F8DA2E@gmail.com> --bZ08MGbKYdkX1hT379PQOHzCdSFrl9SM9 Content-Type: multipart/mixed; boundary="------------5FEB9696DA20499C41B6A853" Content-Language: en-GB This is a multi-part message in MIME format. --------------5FEB9696DA20499C41B6A853 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 13/02/2019 22:15, Christopher Wood wrote: >=20 >=20 > [1] https://github.com/tlswg/draft-ietf-tls-esni/pull/124 I just re-read that. I've a question: why tie the version change to this PR and not the I-D rev? I'd prefer if we make the change to 0xff02 when -03 is published. (I don't care which PR does that, but wouldn't like to see every PR bump that number.) Aside from that I think it's ok (though I may find other issues when implementing later) with two caveats that can be handled now or later: 1. The DNS RR structure still needs fixing but that is likely better handled separately. (By "fixing" I mean a new RR type but also that it needs to be designed for DNS admins as well and not only for TLS implementers which is the current case. (I'm not saying what might or might not make it more dnsops friendly, just that that needs to be checked/done sometime.) 2. I don't think the text below ought be included, it's not the job of this WG to design MITM attacks. (Or maybe I've misinterpreted it?) "The public name, however, makes this protocol compatible with deployments that use correctly-implemented MITM proxies. If the client has cached an ESNIKey for the origin server, the MITM proxy will process the cleartext SNI field and terminate a connection to the public name instead. If the client is configured to trust the proxy's certificate, it will accept the connection as valid for the public name and retry with ESNI disabled." I also don't think I'd implement that fallback in my openssl fork. Earlier text says to complete the h/s but to not make that visible to the application layer and the above seems to conflict with that. I could hold my nose were that in -03 as it has no effect really, but I'll whine about it later for sure;-) > [2] https://github.com/tlswg/draft-ietf-tls-esni/pull/125 I like this one. But the "SHOULD send" and "MUST pad to 260" seem a bit OTT to me, though I could live with 'em for now. So consider these nits, not objections: - Rather than "SHOULD send", it may be better to say something like "SHOULD frequently send" and leave it to clients to decide how often to grease. Wouldn't that have the same effect? - Maybe add that even TLS1.3 clients that don't really do ESNI MAY grease ESNI? (A bit weird but hey why not?:-) - Padding to 260 is IIRC the max that works. A CH with such padding is ~600 bytes. Seems like a waste of bytes to me and it could stick out depending on real ESNI padding_lengths. Maybe consider something like "pad to a length that matches recent traffic" and leave it to clients to figure out what might stick out less. (I'm not sure every server will ask for padding to 260 as CF do;-) Cheers, S. --------------5FEB9696DA20499C41B6A853 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 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5tDJTdGVwaGVuIEZhcnJlbGwgKDIwMTcp IDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJCZQmAAUL CQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1yw aps8HGUNhLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG +48od+Xn7qg6LT7GrHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXk kTFaSGYJj3yIP4R6IgwBYGMzDXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRr pZtXB1XQc23ZZmrlTkl2HaThL6w3YKdiTi1NbuMeOxZqtXcUshII45sANm4HuWNT iRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS3MmGgVS4ZoX8+VaPGpXdQVFy BMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml3OEuIQiP2ehRt/HV LMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi2/Jrsz6M zh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6 TzKjGjruq8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxIkBHAQQAQgABgUCWj1SoAAK CRAvPIc2gF+NovMcCACVZPo1cQa3D+vWaIo0ZyinO/MgtD2gHysoj1T0Qvq05//L ZXmhh578bJANvdl2g/HFhhwl/5HKIfWcyipQhmJklp/dsleKcNnn4B18T75RHY0G +po3ILq7evbiOjUH+xqApti1aCxi1GocsPghaLfsxmtXKMG4Xu7XhDTv66GOrqZf Y7+0ekJjD9Dza1t5NE/JR/VZA4B8PWR8Glb0+8C9rkjD0VZ5ekJdHPDGcJmFh8Z+ q25LDoI8Fgt1uKSowvoVnsQO5MFv/y6bXArtj1uB4hAL4JiOFgHlFdrW0MlFpvYm ziW4K9JHTD8KAfDbrb3e2W97ZDpROuYfE/lTbYOWiQI9BBMBCAAnBQJaPVAyAhsD BQkJlCYABQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEFqy+vF7Fyvq0mkP/ius gsf6Z4/Tu+vHzBbl5i6oKI8ZieH8JfEgXx4ut9t7l3hBGC2r7DpR5A8zLMpEhGIK gFcHagksFkfLEE/FmWDfd1MysQafxBYrHaI27P2tkxfI5JYV6247TV39pQ93kGds tsjIrmh/zEJCVczoofxtz72BDt51H2Z8tN28F/YVHnbaGDwFEEzWKYpze87y/f36 ogcdGO6LDEEEIA6Ee0dGxleuKlLS4UDTt0zjo6L8TyiyPHp9C3+UfnP8837Zp3Fh KstIBd+vWgPdHFg2G5aDIYUvrj9UJBvVgaN/RnkwE+dab2OBSg5jkr141JLQvzdZ 4mOUXn5D9Y6AH6tvj0+ubYMV6j35L1/ZXncuXPVYiylcmDp/6f2WYcT3gx9CPUYA cLMjQV4vX2W8z4uEPyMlIJuGsLf7KhvLL8BQ6zlncT6eONfUUX9UJUCzqI5rqL5c b5jWGHeKvbLWRyQnlq5PXQxJTwYRm71rJTgzejc33LE6Nqg/Q25Dgwwsv+f+7i73 gB5loc80Fef+FV9VFGalFe0Yq8m0UASmkYRh7MH5ssoibpeWk+SGfBjOV4tnsAwR yjYLpAzxA8HeDcmlLeypGEDmsQ/iUvXoGaKOYX4Ieg8T/PCAplsqnJUOq8hbkgOC 98gLZfiltkNG8YhQpoZIHj6SxmBRSc3K99CvanuOiQIzBBABCAAdFiEEfhcKBFyE z0YOK3mgEO952f2DUxIFAlu3JJsACgkQEO952f2DUxJ4qRAAmbjiO3WTAeBCB4ME p2N2+XQCMTTFURDGuJnqU/+X//fhhPRq4V/OxgisKFKlBcAS2hsECvg6HDVSz4Fl 74fk/y+botG4/CjMLdKPB9fgh5zz72i3q0hWDixt50NKBv8IIVWOyYgZxDU/vcks lMEnqbFgJX+CfdALpvAM4WjuQP0UMcKNE3xd+EdDhD1xjK3Tq4XfWob9q6aBZgL2 B4IaADCIeDDE1hv0agnSJmMJE7Bti8tNxCCxVRbZtOaxVHXdRUoOx2XTaxFXupxV hbpHRrdFrwq51f6e3bkfkNEZ3fzYpnlbynJ2zL++JO8P3Pq/S6UKEFjEB50i8YgK WuFvGUsQ+YiDgiZU4saqxSBWbfYn3lY6MSSTg8RnXbFIMG3CFImqYk1uhaV+bDjc p0htjzM2F98g7c3o7sWx0bGarId4uhOmpj7JJVQ+lu7Jby6Ocj8n//7qF1Nn11Cw QlCVaeAq5Y5DmZrnww9I3zzOWWyqFkAVCM3GqeRLMvplD6/+O+5FF7XoHzQB47nk OyZtawy/9gssPWZKLv4qHLYS0wGGCiNbCsYy90s3pfeafM0kSxxjIvEz21KT6LJI /awu2ErQFWCkDMFJ1p/97MjPrQ/6d4cPO140V/wyfuWaBiTVqa9mgnb2zn6fYfDH JEvl1UzIx3JCae25tty1+qtnS0i0LlN0ZXBoZW4gRmFycmVsbCA8c3RlcGhlbkB0 b2xlcmFudG5ldHdvcmtzLmNvbT6JAj0EEwEIACcFAlo9UVoCGwMFCQmUJgAFCwkI BwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+o7HBAAxHAdFkBGZ9gJK8w7 NUYS9C6enGYtAYoKH5G3Bn3YScjErNfQtHYb53KwBQpVSOv1HcN8hbQ8mLTgn9lt zNwNSuv0XxIswi807HRSIZ4vYDiS5VKV1YkLYK5bLY5O4alVdzqM+AZQqkuHBu63 6n+C0ED6UwLhVBFfSNvBQVAdoq6gvr+IE8rCIKTMNGwNcgVPbF+YxP7UZM6p7s2a 5MIqGw7URSfaqfuztibXGOBLFbSwLGqHSSnOXBfEeDrwdZ+ur8cXIIPRIeCTVmeO 8bGgpgBqNQXG9oyGN+TrYAC+4Ahi0UjCk7QGj8tf3xICKoQpYyfceNBZJ/969gV9 tVgvRxUjxUwc9kZbi0c8XYMTq5GCvBIh1D6BOW9QBM2SsNgG3l36+e3+c2LDdyKn 20C1IzGLVDdcCtz42/onQ/e9sMlzFrfLjs5SO2/TnLvp2JtsIQXyb/T5qd0GE5j8 /iwfZR+uVTVVEsUl1a+Yllzt6sdR7RIhhKpKaKzEAk4d0+VHdz7zEkQRRSjbPVoS fy8c/kld9Fi8Buna+ZkKpcwIW+D4XP83pGcl0XUv6AyqwS1LnEt+jv/+PSXskYtU Lzn8Z35iKkSAH/5Nz6GCZk6ORPNv/6+UI92BpUbu/G2tBwK8bPgAg+gJxBx3G7MK W7VRCmM5UrtAK9A3O70VjPyMkHSJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLC LAf/X/9vRTZWtwSXxiBCA54a6hg9IvW0mvPUqgXfvrhtOk0IFucLKrTXK8J/NcmU 6ulxOovVbQ+Bin6gtHeCmSa/W523g/NXCOuFTnS/MyVibNL4+RCFwqGysl++Cm+L nj1MmasE9kO+CNdervx8APfxV7D6OYrG4eGag+LdFR6VpJn6tRT0/WvyT8l+Oqiq gdhXHv+0MvkkD9TX5LlJW4VB/yRvWkkmL5N5c5zYh+NcfTPhQ5S9dOorVzrm65d6 Itn0937Ennau7s7fiFdA0BHjWqEAFLsBIXQfCFjjKjdsKA4xlSiX7X7ElmPYpWa5 wwTQ66dL0anMd9y1DJCMOHe4gYkCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9 g1MSBQJbtyScAAoJEBDvedn9g1MSY7sP+gKR0rFU1g+GtB+hSdtwPRbacvml2eL2 Jc5Eq37J9hAqxHyt5V0If7s8IyVA2GXgdfwULBWbXGDUDiUkh20OPQRUS8G9Sf8A WRuG25q5C8ZzWygykL88RKXJZDFtA49CeqO5Bq5syBhq4QfiSTffQHIp3h0boPGU hSBEUQpooMXYQClNARQ+z/uRzR5bUi9wxdXNnxTn9ia4ASlaBPvUYTGY1jW2HrRR SwpI12+UaWsvc3jJtQ8X0kxgJ7jsFF1uqquIZ5eflQv+PHHg2RJSy37u0UFGb+OK ZEkzlmbPokKCYhzBR5PcD6sgdlaJNcidmto9u1oV6yZT8J2W4CTuUclgxt6f3lZq ZeVLnNnbHyKUdeypwLlqYISulfnMhZ3A6Bgpf2BtjL6KJbFtPBYmYdxI+HZyY49u U2ZHhRu+CSQ1y7zGKSX0gRp5hE7+A4XJtsT6lTLhbi9aiZTG1S6zKNhl3qNNzszc r27PrvFiyGhpuYQuzdQl2PMGbOI6Ojif3sab53NO3RLsLOM09wIlr95yKLlkXkUr WcvUJGrw6HKm8j5opXHTwmJOAbDpc6cMDu+ITRu4spdCnQJcE8RkO8tKyaLuh2Gt U5kYSBK97yr5VviX1FK6rY14LLmnE16OPiK2tiVBKy9nGM0DKtY+K9WcoRZ7s/d7 O0bMfzcNPtGLuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiez GPuBHmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9Wf pHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC 6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2 D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFe A7PbTuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ /Vf3vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbpt PEcmoazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKr em5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96 Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYgh x8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQ oqj1gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P /1tF6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8 Wpfdn3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJ gx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5 SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2 oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIA ypqYo3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoM eDQkd0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS /qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZ IMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XO KVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DJ121 -----END PGP PUBLIC KEY BLOCK----- --------------5FEB9696DA20499C41B6A853-- --bZ08MGbKYdkX1hT379PQOHzCdSFrl9SM9-- --x43yYuFBtZyA5SLeGc7UDDQkaYBCNPhua Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlxkoXQACgkQWrL68XsX K+rWKA//T3fKLr6MRovk+EWepm4BOL63glRbH9/G+XVJ2hJuot1jYvAVwKqJNAlp Vn8CpdwrNmmoJjmVkuWliluPzkuK8KUUkD0WNtCUbZLddQmiOrCMHoMNz0DjZjMP Aat2Bhbc20ua5lkP5wsdhlHkvNT6KvjCcCA0I5W7Vh9hI+TxAXAtbdLmnYk18zZw JZL6CXAq/+U4gTS9+DxYplk+vliyYsQcrB4wLAibW2VwAaX34cT3aAb+uC9pvinb RiuNaiWj03U4TFnBTxm2AMI196Pt8u9AQMXuTRpG2ieNMxNJoba7wG4MIAWAh653 //fGIdj1G6x6fAN4MaeScvCyHiLUGtKrG0Ac6D8sYbqwePKx0WCM7BfzdSyywsOp eSjcQL7JzAZlQekrNYrrxb3HvJAgt3UVzNreAXE1reE3fFJWBpdQzX3qBlPnb7UV 6nKtYT3vC3BBZ3D3AqNu6S8xzLOf4JhDOjx7BQFAE5crbvPAQI4xnysM8ZqSJcZg rfbGSDeA74wabXcvLBXH1/lRllBvKQbo4RhN0buo843mEF/QmKWh8k9Y3qOc6KBe GnI+iDaG+Jd3CD7Gwf+eOrJODrp0421WFzV+g5SoQAycheT3Pgmgwc/MdvLPvpBE AFsHQTwohz5z/AMqu7Rgtij+52bLbjZn6UtZOYdrBOtAuHphAco= =Tc9d -----END PGP SIGNATURE----- --x43yYuFBtZyA5SLeGc7UDDQkaYBCNPhua-- From nobody Wed Feb 13 15:56: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 1C725130E85 for ; Wed, 13 Feb 2019 15:56:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.499 X-Spam-Level: X-Spam-Status: No, score=-9.499 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, URIBL_BLOCKED=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 p-lM4ZuXlrSk for ; Wed, 13 Feb 2019 15:56:06 -0800 (PST) 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 5AB34130E58 for ; Wed, 13 Feb 2019 15:56:06 -0800 (PST) Received: by mail-qt1-x82e.google.com with SMTP id v10so4856264qtp.8 for ; Wed, 13 Feb 2019 15:56:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=s7mdsiRp/Jf0X6KmEWccCWAHLqfV2zacUudqv/Tz1jc=; b=ZUJeZwHU2gFCSusOjaAlihyhlWtiHXuxoskZQ17uny+xmAn/cFDnWks5qs02Ioi7Of BfbL8QtnBEQFHZwyGJfG2t4hJg1soNFZuMKK2HVxwTCfXGI/f295toS1ZB0Gvzs3TyfK zl2yYjKH3vzAgUNwfEhL0N8qMh88TK3hRDyl4= 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=s7mdsiRp/Jf0X6KmEWccCWAHLqfV2zacUudqv/Tz1jc=; b=hLsqg0MsHYx3R1ql/oc0nL//yZb1mGTV3H+KJLFFmjPhgG/s9haKNQPwCCdepzBSAR 7CL5+v6HRZaoTPiENm53bs7WzTVvwD7dZ5J6h9krUPkDb/GO14Ki6AoJi87rusLaPrpt c0iX3rGOX0dVky428o/ZdfEvej9/+c7ZV1MTP4qzhgYozDR6yC7SdHbofGuMwjBeFjLm jPfkoKQcQzDi+iM8FcF8vE9H/Jko/xE6GfcJUej77u/6kD8tDPpGC9G3Iv7zdpiasT2g D4XwX7QrV5P58m7jGKsgrYJJ7TzgjuHPX7eJS41LuUIK5nz6vhLANlSpam9uxM/Ukkao x/Sw== X-Gm-Message-State: AHQUAua2GZgR463uKoUTDZmaBro8aw2z8V9OIuvxSZgu6J95tLAxKqDw CA6r+hVEvmP82fMU0khOI/M4ir9ar2hnrnG26Esr X-Google-Smtp-Source: AHgI3Ia7hMKNg6E22j1qdG3IAvbqiMVeUxpmfmUEh/VJgNqHeMZ2XhCKiaJ36yCMUorPodUXhbtrSNdqBqp9RtNX90M= X-Received: by 2002:ac8:3665:: with SMTP id n34mr679993qtb.72.1550102164356; Wed, 13 Feb 2019 15:56:04 -0800 (PST) MIME-Version: 1.0 References: <714E43FA-3660-485A-8E50-04EE43F8DA2E@gmail.com> In-Reply-To: From: David Benjamin Date: Wed, 13 Feb 2019 17:55:52 -0600 Message-ID: To: Stephen Farrell Cc: Christopher Wood , TLS WG Content-Type: multipart/alternative; boundary="000000000000dfab0a0581cf48cc" Archived-At: Subject: Re: [TLS] ESNI PRs #124 and #125: Improving ESNI Robustness and GREASE 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, 13 Feb 2019 23:56:09 -0000 --000000000000dfab0a0581cf48cc Content-Type: text/plain; charset="UTF-8" Thanks for the comments! Responses inline. On Wed, Feb 13, 2019 at 5:00 PM Stephen Farrell wrote: > > Hiya, > > On 13/02/2019 22:15, Christopher Wood wrote: > > > > > > [1] https://github.com/tlswg/draft-ietf-tls-esni/pull/124 > > I just re-read that. I've a question: why tie the version > change to this PR and not the I-D rev? I'd prefer if we > make the change to 0xff02 when -03 is published. (I don't > care which PR does that, but wouldn't like to see every > PR bump that number.) > I bumped it because the PR was making a wire-incompatible change, but batching them up to I-D revs makes sense too. No preferences here. (Spec editors, do you care? I can remove that part of the change.) > Aside from that I think it's ok (though I may find other > issues when implementing later) with two caveats that can > be handled now or later: > > 1. The DNS RR structure still needs fixing but that is likely > better handled separately. (By "fixing" I mean a new RR type > but also that it needs to be designed for DNS admins as well > and not only for TLS implementers which is the current case. > (I'm not saying what might or might not make it more dnsops > friendly, just that that needs to be checked/done sometime.) > I'm guessing this is to do with the various discussions around multi-CDN and whatnot? That seems orthogonal to that PR. (I don't personally have particularly strong opinions or experience there.) > 2. I don't think the text below ought be included, it's not > the job of this WG to design MITM attacks. (Or maybe I've > misinterpreted it?) > > "The public name, however, makes this protocol compatible with > deployments that use correctly-implemented MITM proxies. If the > client has cached an ESNIKey for the origin server, the MITM > proxy will process the cleartext SNI field and terminate a > connection to the public name instead. If the client is > configured to trust the proxy's certificate, it will accept > the connection as valid for the public name and retry with > ESNI disabled." > That text isn't prescribing any particular behavior. It's just describing the effect the rest of the text has on "trusted MITM proxies" and the like. Note this is specifically about "MITM proxies" which control a root certificate that the client is configured to trust. I will refrain from commenting on whether this deployment model is at all wise, but it does exist (antivirus, etc). The text itself is just an updated version of existing bits here: https://tools.ietf.org/html/draft-ietf-tls-esni-02#section-6.2 As for where this effect comes from, it's a consequence of the rollback and partial deployment robustness mechanism in the PR: > If the server negotiates an earlier version of TLS, or if it does not > provide an "encrypted_server_name" extension in EncryptedExtensions, the > client proceeds with the handshake, verifying the certificate against > ESNIKeys.public_name as described in {{verify-public-name}}. The client MUST > NOT enable the False Start optimization {{RFC7918}}. If the handshake completes > successfully, the client MUST abort the connection with an "esni_required" alert. > It then SHOULD retry the handshake with a new transport connection and ESNI > disabled." Or, in other words, IF the server is able to speak authoritatively for the public name (relatively to the client's trust anchors) but appears to not understand ESNI at all, that is a signal to the client that ESNI got turned off or hasn't fully been turned on yet. ESNI involves client state and, without this, it's risky for a server operator to deploy ESNI. Deployments are complex systems, and complex systems react to change unpredictably. For most changes, if some show-stopping problem is found, it is safe to rollback the change. For instance, clients naturally tolerate servers turning TLS 1.3 on and off, a fact I'm sure every early adopter of TLS 1.3 has used many times. ESNI, a priori, breaks this property. The intent of this text is to restore it, without totally breaking it (the stop signal is authenticated under the public name, the same standard this PR sets for replacing the key). It turns out that a user moving in and out of one of these "trusted MITMs" looks the same as a rollback, so we get robustness to that scenario too. The current draft attempted to handle this case too, but did so with extra machinery. From the link above: > A Web client client can securely detect case (2) because it will > result in a connection which has an invalid identity (most likely) > but which is signed by a certificate which does not chain to a > publicly known trust anchor. The client can detect this case and > disable ESNI while in that network configuration Here, there is no name check, so any publicly known root that the client trusts can be used to trigger that fallback, even if it's just, say, an intranet server and not a MITM proxy. The PR fixes this by checking the public name. It only counts as a signal if the server can speak for the service's public name, not any arbitrary name. I also don't think I'd implement that fallback in my openssl > fork. Earlier text says to complete the h/s but to not make > that visible to the application layer and the above seems to > conflict with that. I could hold my nose were that in -03 as it > has no effect really, but I'll whine about it later for sure;-) > I'm guessing you're referring to this? > Note that verifying a connection for the public name does not verify it for the > origin. The TLS implementation MUST NOT surface such connections as successful to > the application. That just says you can't report it as successful. Whether you report it to the application at all depends on your API shape. For a low-level TLS library that doesn't create transport connections, I'm envisioning it report failure with a special error code, which higher-level logic can interpret as a retry. (This is how we handle 0-RTT rejects in BoringSSL. 0-RTT rejects affect connection usage, such as if you thought you were speaking HTTP/2, but the server rejected and then negotiated HTTP/1.1. It's ultimately a very funny retry.) For higher-level code that knows how to make transport connections, one option then is for the retry to be handled more transparently. > > [2] https://github.com/tlswg/draft-ietf-tls-esni/pull/125 > > I like this one. But the "SHOULD send" and "MUST pad to 260" > seem a bit OTT to me, though I could live with 'em for now. > So consider these nits, not objections: > (260 is just a SHOULD rather than a MUST. More below.) > - Rather than "SHOULD send", it may be better to say something > like "SHOULD frequently send" and leave it to clients to decide > how often to grease. Wouldn't that have the same effect? > Is there any reason not to just do it in every ClientHello? > - Maybe add that even TLS1.3 clients that don't really do ESNI > MAY grease ESNI? (A bit weird but hey why not?:-) > Indeed! The PR currently says: > If the client attempts to connect to a server and does not have an ESNIKeys > structure available for the server, Knowing what ESNI is but not really doing it I think counts as "does not have an ESNIKeys structure available". Do you think it should be called out more explicitly? > - Padding to 260 is IIRC the max that works. A CH with such > padding is ~600 bytes. Seems like a waste of bytes to me and > it could stick out depending on real ESNI padding_lengths. > Maybe consider something like "pad to a length that matches > recent traffic" and leave it to clients to figure out what > might stick out less. (I'm not sure every server will ask > for padding to 260 as CF do;-) > 260 comes from elsewhere which says: > The length to pad the ServerNameList value to prior to encryption. > This value SHOULD be set to the largest ServerNameList the server > expects to support rounded up the nearest multiple of 16. If the > server supports wildcard names, it SHOULD set this value to 260. I figured that assuming, by default, that the server supports wildcard names seemed reasonable so the text mirrored the other SHOULD. Though maybe that's a bit much? I don't have strong feelings here. What do you think the text should say? Perhaps it should pick a random multiple-of-16 length between 64 and 260? Or maybe we should decrease the wildcard value... a 260-byte SNI name is kind of excessive, honestly. David --000000000000dfab0a0581cf48cc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank= s for the comments! Responses inline.

On Wed, Feb 13, 2019 = at 5:00 PM Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

Hiya,

On 13/02/2019 22:15, Christopher Wood wrote:
>
>
> [1] https://github.com/tlswg/draft-ietf-tl= s-esni/pull/124

I just re-read that. I've a question: why tie the version
change to this PR and not the I-D rev? I'd prefer if we
make the change to 0xff02 when -03 is published. (I don't
care which PR does that, but wouldn't like to see every
PR bump that number.)

I bumped it becau= se the PR was making a wire-incompatible change, but batching them up to I-= D revs makes sense too. No preferences here. (Spec editors, do you care? I = can remove that part of the change.)
=C2=A0
Aside from that I think it's ok (though I may find other
issues when implementing later) with two caveats that can
be handled now or later:

1. The DNS RR structure still needs fixing but that is likely
better handled separately. (By "fixing" I mean a new RR type
but also that it needs to be designed for DNS admins as well
and not only for TLS implementers which is the current case.
(I'm not saying what might or might not make it more dnsops
friendly, just that that needs to be checked/done sometime.)

I'm guessing this is to do with the various discu= ssions around multi-CDN and whatnot? That seems orthogonal to that PR. (I d= on't personally have particularly strong opinions or experience there.)=
=C2=A0
2. I don't think the text below ought be included, it's not
the job of this WG to design MITM attacks. (Or maybe I've
misinterpreted it?)

"The public name, however, makes this protocol compatible with
deployments that use correctly-implemented MITM proxies. If the
client has cached an ESNIKey for the origin server, the MITM
proxy will process the cleartext SNI field and terminate a
connection to the public name instead. If the client is
configured to trust the proxy's certificate, it will accept
the connection as valid for the public name and retry with
ESNI disabled."

That text isn= 't prescribing any particular behavior. It's just describing the ef= fect the rest of the text has on "trusted MITM proxies" and the l= ike. Note this is specifically about "MITM proxies" which control= a root certificate that the client is configured to trust. I will refrain = from commenting on whether this deployment model is at all wise, but it doe= s exist (antivirus, etc). The text itself is just an updated version of exi= sting bits here:

As for where this effect co= mes from, it's a consequence of the rollback and partial deployment rob= ustness mechanism in the PR:=C2=A0

> If the ser= ver negotiates an earlier version of TLS, or if it does not
> = provide an "encrypted_server_name" extension in EncryptedExtensio= ns, the
> client proceeds with the handshake, verifying the ce= rtificate against
> ESNIKeys.public_name as described in {{ver= ify-public-name}}. The client MUST
> NOT enable the False Star= t optimization {{RFC7918}}. If the handshake completes
> succe= ssfully, the client MUST abort the connection with an "esni_required&q= uot; alert.
> It then SHOULD retry the handshake with a new tr= ansport connection and ESNI
> disabled."

Or, in other words, IF the server is able to speak authoritatively= for the public name (relatively to the client's trust anchors) but app= ears to not understand ESNI at all, that is a signal to the client that ESN= I got turned off or hasn't fully been turned on yet. ESNI involves clie= nt state and, without this, it's risky for a server operator to deploy = ESNI. Deployments are complex systems, and complex systems react to change = unpredictably. For most changes, if some show-stopping problem is found, it= is safe to rollback the change. For instance, clients naturally tolerate s= ervers turning TLS 1.3 on and off, a fact I'm sure every early adopter = of TLS 1.3 has used many times. ESNI, a priori, breaks this property. The i= ntent of this text is to restore it, without totally breaking it (the stop = signal is authenticated under the public name, the same standard this PR se= ts for replacing the key).

It turns out that a use= r moving in and out of one of these "trusted MITMs" looks the sam= e as a rollback, so we get robustness to that scenario too. The current dra= ft attempted to handle this case too, but did so with extra machinery. From= the link above:

>=C2=A0 =C2=A0A Web clien= t client can securely detect case (2) because it will
>=C2=A0 = =C2=A0result in a connection which has an invalid identity (most likely)
>=C2=A0 =C2=A0but which is signed by a certificate which does no= t chain to a
>=C2=A0 =C2=A0publicly known trust anchor.=C2=A0 = The client can detect this case and
>=C2=A0 =C2=A0disable ESNI= while in that network configuration

Here, t= here is no name check, so any publicly known root that the client trusts ca= n be used to trigger that fallback, even if it's just, say, an intranet= server and not a MITM proxy. The PR fixes this by checking the public name= . It only counts as a signal if the server can speak for the service's = public name, not any arbitrary name.

I also don't think I'd implement that fallback in my openssl
fork. Earlier text says to complete the h/s but to not make
that visible to the application layer and the above seems to
conflict with that. I could hold my nose were that in -03 as it
has no effect really, but I'll whine about it later for sure;-)

I'm guessing you're referring to this?=

> Note that verifying a connection fo= r the public name does not verify it for the
> origin. The TLS= implementation MUST NOT surface such connections as successful to
> the application.

That just says you c= an't report it as successful. Whether you report it to the application = at all depends on your API shape. For a low-level TLS library that doesn= 9;t create transport connections, I'm envisioning it report failure wit= h a special error code, which higher-level logic can interpret as a retry. = (This is how we handle 0-RTT rejects in BoringSSL. 0-RTT rejects affect con= nection usage, such as if you thought you were speaking HTTP/2, but the ser= ver rejected and then negotiated HTTP/1.1. It's ultimately a very funny= retry.) For higher-level code that knows how to make transport connections= , one option then is for the retry to be handled more transparently.
<= div>=C2=A0
> [2] https://github.com/tlswg/draft-ietf-tl= s-esni/pull/125

I like this one. But the "SHOULD send" and "MUST pad to 260&= quot;
seem a bit OTT to me, though I could live with 'em for now.
So consider these nits, not objections:

(260 is just a SHOULD rather than a MUST. More below.)
=C2=A0
- Rather than "SHOULD send", it may be better to say something like "SHOULD frequently send" and leave it to clients to decide how often to grease. Wouldn't that have the same effect?

Is there any reason not to just do it in every Client= Hello?
=C2=A0
- Maybe add that even TLS1.3 clients that don't really do ESNI
MAY grease ESNI? (A bit weird but hey why not?:-)

=
Indeed! The PR currently says:

>= ; If the client attempts to connect to a server and does not have an ESNIKe= ys
> structure available for the server,

<= /div>
Knowing what ESNI is but not really doing it I think counts as &q= uot;does not have an ESNIKeys structure available". Do you think it sh= ould be called out more explicitly?
=C2=A0
- Padding to 260 is IIRC the max that works. A CH with such
padding is ~600 bytes. Seems like a waste of bytes to me and
it could stick out depending on real ESNI padding_lengths.
Maybe consider something like "pad to a length that matches
recent traffic" and leave it to clients to figure out what
might stick out less. (I'm not sure every server will ask
for padding to 260 as CF do;-)

260 come= s from elsewhere which says:

> The length = to pad the ServerNameList value to prior to encryption.
> This= value SHOULD be set to the largest ServerNameList the server
>= ; expects to support rounded up the nearest multiple of 16. If the
> server supports wildcard names, it SHOULD set this value to 260.

I figured that assuming, by default, that the s= erver supports wildcard names seemed reasonable so the text mirrored the ot= her SHOULD. Though maybe that's a bit much? I don't have strong fee= lings here. What do you think the text should say? Perhaps it should pick a= random multiple-of-16 length between 64 and 260? Or maybe we should decrea= se the wildcard value... a 260-byte SNI name is kind of excessive, honestly= .

David
--000000000000dfab0a0581cf48cc-- From nobody Wed Feb 13 16:24: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 01BC2130E0A for ; Wed, 13 Feb 2019 16:24:19 -0800 (PST) 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 G1ZdlbYtwVAb for ; Wed, 13 Feb 2019 16:24:15 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D102130DBE for ; Wed, 13 Feb 2019 16:24:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 41328BE2F; Thu, 14 Feb 2019 00:24:13 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FcY2m47Yt5AH; Thu, 14 Feb 2019 00:24:11 +0000 (GMT) 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 BB2CCBE20; Thu, 14 Feb 2019 00:24:10 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1550103850; bh=sWLcII3QQ80jEPPWp5ZJ/SOsuGPwRf1OMKxDMx1fvc8=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=b8q7Xer1Rrs4Mtv+MaMnPpj7NzW+qHxIKnmzOCNANWKLx+qlMGQTdIm/pfEHlz1TY RxT1utk18eR+zQx1qZ5m9vSeMICE5Ts1pBi4tCYcVaiQSZvNFfGz/NHwMJTYha3KY8 lpa2RBfE5/00Q4aINQ/70FRjfKP/MwLva3Td3jjw= To: David Benjamin Cc: Christopher Wood , TLS WG References: <714E43FA-3660-485A-8E50-04EE43F8DA2E@gmail.com> 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: Date: Thu, 14 Feb 2019 00:24:09 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="TLLNDuNgfJtQzjybvNobA9GSEdfle1nma" Archived-At: Subject: Re: [TLS] ESNI PRs #124 and #125: Improving ESNI Robustness and GREASE 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, 14 Feb 2019 00:24:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TLLNDuNgfJtQzjybvNobA9GSEdfle1nma Content-Type: multipart/mixed; boundary="U4jxalB2D8q6SB3qKfIjIswO3ysxMqtc5"; protected-headers="v1" From: Stephen Farrell To: David Benjamin Cc: Christopher Wood , TLS WG Message-ID: Subject: Re: [TLS] ESNI PRs #124 and #125: Improving ESNI Robustness and GREASE References: <714E43FA-3660-485A-8E50-04EE43F8DA2E@gmail.com> In-Reply-To: --U4jxalB2D8q6SB3qKfIjIswO3ysxMqtc5 Content-Type: multipart/mixed; boundary="------------8D20989A6BA5DE98374F1D07" Content-Language: en-GB This is a multi-part message in MIME format. --------------8D20989A6BA5DE98374F1D07 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, Various bits'n'pieces below... On 13/02/2019 23:55, David Benjamin wrote: > Thanks for the comments! Responses inline. >=20 > On Wed, Feb 13, 2019 at 5:00 PM Stephen Farrell > wrote: >=20 >> >> Hiya, >> >> On 13/02/2019 22:15, Christopher Wood wrote: >>> >>> >>> [1] https://github.com/tlswg/draft-ietf-tls-esni/pull/124 >> >> I just re-read that. I've a question: why tie the version >> change to this PR and not the I-D rev? I'd prefer if we >> make the change to 0xff02 when -03 is published. (I don't >> care which PR does that, but wouldn't like to see every >> PR bump that number.) >> >=20 > I bumped it because the PR was making a wire-incompatible change, but > batching them up to I-D revs makes sense too. No preferences here. (Spe= c > editors, do you care? I can remove that part of the change.) >=20 >=20 >> Aside from that I think it's ok (though I may find other >> issues when implementing later) with two caveats that can >> be handled now or later: >> >> 1. The DNS RR structure still needs fixing but that is likely >> better handled separately. (By "fixing" I mean a new RR type >> but also that it needs to be designed for DNS admins as well >> and not only for TLS implementers which is the current case. >> (I'm not saying what might or might not make it more dnsops >> friendly, just that that needs to be checked/done sometime.) >> >=20 > I'm guessing this is to do with the various discussions around multi-CD= N > and whatnot? That seems orthogonal to that PR. (I don't personally have= > particularly strong opinions or experience there.) Not just that. ESNIKeys is a fairly complex structure that has a number sets/sequences of values. There are various possible deployment models. The current structure assumes that it's ok to encode all that stuff up in one TLS style blob and then put that in the DNS. That might not make sense for some deployments in particular where the DNS operator is not closely tied to the TLS server admin or where there's 1 DNS operator and N TLS server admins (for the same origin). And then there's the use of the TXT RR. But I agree this is orthogonal - I was mostly saying that in agreeing with this PR I continue to think the DNS RR stuff needs other work. >=20 >=20 >> 2. I don't think the text below ought be included, it's not >> the job of this WG to design MITM attacks. (Or maybe I've >> misinterpreted it?) >> >> "The public name, however, makes this protocol compatible with >> deployments that use correctly-implemented MITM proxies. If the >> client has cached an ESNIKey for the origin server, the MITM >> proxy will process the cleartext SNI field and terminate a >> connection to the public name instead. If the client is >> configured to trust the proxy's certificate, it will accept >> the connection as valid for the public name and retry with >> ESNI disabled." >> >=20 > That text isn't prescribing any particular behavior.=20 Then delete it:-) > It's just describing > the effect the rest of the text has on "trusted MITM proxies" and the l= ike. Disagree. "Just describing" does not match the use of a meaningless marketing term like "trusted blah proxy" sorry. Better to avoid all that fuss really, no? > Note this is specifically about "MITM proxies" which control a root > certificate that the client is configured to trust. I will refrain from= > commenting on whether this deployment model is at all wise, but it does= > exist (antivirus, etc). The text itself is just an updated version of > existing bits here: > https://tools.ietf.org/html/draft-ietf-tls-esni-02#section-6.2 I don't recall that having a concept of it being possible to "correctly" implement breaking the TLS protocol? (As is inherent in being an MITM.) >=20 > As for where this effect comes from, it's a consequence of the rollback= and > partial deployment robustness mechanism in the PR: >=20 >> If the server negotiates an earlier version of TLS, or if it does not >> provide an "encrypted_server_name" extension in EncryptedExtensions, t= he >> client proceeds with the handshake, verifying the certificate against >> ESNIKeys.public_name as described in {{verify-public-name}}. The clien= t > MUST >> NOT enable the False Start optimization {{RFC7918}}. If the handshake > completes >> successfully, the client MUST abort the connection with an > "esni_required" alert. >> It then SHOULD retry the handshake with a new transport connection and= > ESNI >> disabled." >=20 > Or, in other words, IF the server is able to speak authoritatively for = the > public name (relatively to the client's trust anchors) but appears to n= ot > understand ESNI at all, that is a signal to the client that ESNI got tu= rned > off or hasn't fully been turned on yet. ESNI involves client state and,= > without this, it's risky for a server operator to deploy ESNI. Deployme= nts > are complex systems, and complex systems react to change unpredictably.= For > most changes, if some show-stopping problem is found, it is safe to > rollback the change. For instance, clients naturally tolerate servers > turning TLS 1.3 on and off, a fact I'm sure every early adopter of TLS = 1.3 > has used many times. ESNI, a priori, breaks this property. The intent o= f > this text is to restore it, without totally breaking it (the stop signa= l is > authenticated under the public name, the same standard this PR sets for= > replacing the key). It may be ok to live with such fallback whilst ESNI is being introduced but I think ongoing support for it would be unwise. And such a fallback requires no discussion of MITM attacks. (Other than as an attack.) >=20 > It turns out that a user moving in and out of one of these "trusted MIT= Ms" I object to that term again, sorry:-) It's marketing meaninglessness. > looks the same as a rollback, so we get robustness to that scenario too= =2E > The current draft attempted to handle this case too, but did so with ex= tra > machinery. From the link above: >=20 >> A Web client client can securely detect case (2) because it will >> result in a connection which has an invalid identity (most likely) >> but which is signed by a certificate which does not chain to a >> publicly known trust anchor. The client can detect this case and >> disable ESNI while in that network configuration >=20 > Here, there is no name check, so any publicly known root that the clien= t > trusts can be used to trigger that fallback, even if it's just, say, an= > intranet server and not a MITM proxy. The PR fixes this by checking the= > public name. It only counts as a signal if the server can speak for the= > service's public name, not any arbitrary name. >=20 > I also don't think I'd implement that fallback in my openssl >> fork. Earlier text says to complete the h/s but to not make >> that visible to the application layer and the above seems to >> conflict with that. I could hold my nose were that in -03 as it >> has no effect really, but I'll whine about it later for sure;-) >> >=20 > I'm guessing you're referring to this? >=20 >> Note that verifying a connection for the public name does not verify i= t > for the >> origin. The TLS implementation MUST NOT surface such connections as > successful to >> the application. >=20 > That just says you can't report it as successful.=20 "MUST NOT surface" seems like bad phrasing then. > Whether you report it to > the application at all depends on your API shape. For a low-level TLS > library that doesn't create transport connections, I'm envisioning it > report failure with a special error code, which higher-level logic can > interpret as a retry.=20 That would be ok. Saying that requires no discussion of MITM attacks. (My openssl code would actually make that visible to the application if the application called a status API, but the TLS h/s would have failed from the application POV even if the h/s looks like it worked on the wire.) > (This is how we handle 0-RTT rejects in BoringSSL. > 0-RTT rejects affect connection usage, such as if you thought you were > speaking HTTP/2, but the server rejected and then negotiated HTTP/1.1. = It's > ultimately a very funny retry.) For higher-level code that knows how to= > make transport connections, one option then is for the retry to be hand= led > more transparently. >=20 >=20 >>> [2] https://github.com/tlswg/draft-ietf-tls-esni/pull/125 >> >> I like this one. But the "SHOULD send" and "MUST pad to 260" >> seem a bit OTT to me, though I could live with 'em for now. >> So consider these nits, not objections: >> >=20 > (260 is just a SHOULD rather than a MUST. More below.) >=20 >=20 >> - Rather than "SHOULD send", it may be better to say something >> like "SHOULD frequently send" and leave it to clients to decide >> how often to grease. Wouldn't that have the same effect? >> >=20 > Is there any reason not to just do it in every ClientHello? I'd guess that some implementers may be put off by the wasted bandwidth. Others won't care but if it's the case that sending a bogus ESNI x% of the time gets as good a result as sending all the time (which is how I interpret what the SHOULD calls for) then it seems better to encourage x% and not 100%. >=20 >=20 >> - Maybe add that even TLS1.3 clients that don't really do ESNI >> MAY grease ESNI? (A bit weird but hey why not?:-) >> >=20 > Indeed! The PR currently says: >=20 >> If the client attempts to connect to a server and does not have an > ESNIKeys >> structure available for the server, "The client" in almost all IETF specs means a thing that really implements the spec. So in this case, yeah, I think it might be good to say that a TLS client implementer who only has time to grease and not do the real thing is still doing good overall by just doing that. (That said, I've no idea if there'd ever be such an implementer, though when we did DKIM there were many mail receivers who parsed but didn't actually check signatures - maybe mail implementers are more slapdash though:-) >=20 > Knowing what ESNI is but not really doing it I think counts as "does no= t > have an ESNIKeys structure available". Do you think it should be called= out > more explicitly? >=20 >=20 >> - Padding to 260 is IIRC the max that works. A CH with such >> padding is ~600 bytes. Seems like a waste of bytes to me and >> it could stick out depending on real ESNI padding_lengths. >> Maybe consider something like "pad to a length that matches >> recent traffic" and leave it to clients to figure out what >> might stick out less. (I'm not sure every server will ask >> for padding to 260 as CF do;-) >> >=20 > 260 comes from elsewhere which says: >=20 >> The length to pad the ServerNameList value to prior to encryption. >> This value SHOULD be set to the largest ServerNameList the server >> expects to support rounded up the nearest multiple of 16. If the >> server supports wildcard names, it SHOULD set this value to 260. Yeah, and I disagree with that too:-) > I figured that assuming, by default, that the server supports wildcard > names seemed reasonable so the text mirrored the other SHOULD. Though m= aybe > that's a bit much? I don't have strong feelings here. What do you think= the > text should say? Perhaps it should pick a random multiple-of-16 length > between 64 and 260? Or maybe we should decrease the wildcard value... a= > 260-byte SNI name is kind of excessive, honestly. Regardless of the above disagreement about 260, if a client has been sending a bunch of CH's including real ESNI that are about 400 bytes because some server's ESNIKeys says to pad to 160, and that client then sends 600 bytes CH's to everyone else, I think it'd be crystal clear which is grease and which not. Cheers, S. >=20 > David >=20 --------------8D20989A6BA5DE98374F1D07 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 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5tDJTdGVwaGVuIEZhcnJlbGwgKDIwMTcp IDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJCZQmAAUL CQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1yw aps8HGUNhLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG +48od+Xn7qg6LT7GrHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXk kTFaSGYJj3yIP4R6IgwBYGMzDXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRr pZtXB1XQc23ZZmrlTkl2HaThL6w3YKdiTi1NbuMeOxZqtXcUshII45sANm4HuWNT iRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS3MmGgVS4ZoX8+VaPGpXdQVFy BMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml3OEuIQiP2ehRt/HV LMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi2/Jrsz6M zh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6 TzKjGjruq8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxIkBHAQQAQgABgUCWj1SoAAK CRAvPIc2gF+NovMcCACVZPo1cQa3D+vWaIo0ZyinO/MgtD2gHysoj1T0Qvq05//L ZXmhh578bJANvdl2g/HFhhwl/5HKIfWcyipQhmJklp/dsleKcNnn4B18T75RHY0G +po3ILq7evbiOjUH+xqApti1aCxi1GocsPghaLfsxmtXKMG4Xu7XhDTv66GOrqZf Y7+0ekJjD9Dza1t5NE/JR/VZA4B8PWR8Glb0+8C9rkjD0VZ5ekJdHPDGcJmFh8Z+ q25LDoI8Fgt1uKSowvoVnsQO5MFv/y6bXArtj1uB4hAL4JiOFgHlFdrW0MlFpvYm ziW4K9JHTD8KAfDbrb3e2W97ZDpROuYfE/lTbYOWiQI9BBMBCAAnBQJaPVAyAhsD BQkJlCYABQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEFqy+vF7Fyvq0mkP/ius gsf6Z4/Tu+vHzBbl5i6oKI8ZieH8JfEgXx4ut9t7l3hBGC2r7DpR5A8zLMpEhGIK gFcHagksFkfLEE/FmWDfd1MysQafxBYrHaI27P2tkxfI5JYV6247TV39pQ93kGds tsjIrmh/zEJCVczoofxtz72BDt51H2Z8tN28F/YVHnbaGDwFEEzWKYpze87y/f36 ogcdGO6LDEEEIA6Ee0dGxleuKlLS4UDTt0zjo6L8TyiyPHp9C3+UfnP8837Zp3Fh KstIBd+vWgPdHFg2G5aDIYUvrj9UJBvVgaN/RnkwE+dab2OBSg5jkr141JLQvzdZ 4mOUXn5D9Y6AH6tvj0+ubYMV6j35L1/ZXncuXPVYiylcmDp/6f2WYcT3gx9CPUYA cLMjQV4vX2W8z4uEPyMlIJuGsLf7KhvLL8BQ6zlncT6eONfUUX9UJUCzqI5rqL5c b5jWGHeKvbLWRyQnlq5PXQxJTwYRm71rJTgzejc33LE6Nqg/Q25Dgwwsv+f+7i73 gB5loc80Fef+FV9VFGalFe0Yq8m0UASmkYRh7MH5ssoibpeWk+SGfBjOV4tnsAwR yjYLpAzxA8HeDcmlLeypGEDmsQ/iUvXoGaKOYX4Ieg8T/PCAplsqnJUOq8hbkgOC 98gLZfiltkNG8YhQpoZIHj6SxmBRSc3K99CvanuOiQIzBBABCAAdFiEEfhcKBFyE z0YOK3mgEO952f2DUxIFAlu3JJsACgkQEO952f2DUxJ4qRAAmbjiO3WTAeBCB4ME p2N2+XQCMTTFURDGuJnqU/+X//fhhPRq4V/OxgisKFKlBcAS2hsECvg6HDVSz4Fl 74fk/y+botG4/CjMLdKPB9fgh5zz72i3q0hWDixt50NKBv8IIVWOyYgZxDU/vcks lMEnqbFgJX+CfdALpvAM4WjuQP0UMcKNE3xd+EdDhD1xjK3Tq4XfWob9q6aBZgL2 B4IaADCIeDDE1hv0agnSJmMJE7Bti8tNxCCxVRbZtOaxVHXdRUoOx2XTaxFXupxV hbpHRrdFrwq51f6e3bkfkNEZ3fzYpnlbynJ2zL++JO8P3Pq/S6UKEFjEB50i8YgK WuFvGUsQ+YiDgiZU4saqxSBWbfYn3lY6MSSTg8RnXbFIMG3CFImqYk1uhaV+bDjc p0htjzM2F98g7c3o7sWx0bGarId4uhOmpj7JJVQ+lu7Jby6Ocj8n//7qF1Nn11Cw QlCVaeAq5Y5DmZrnww9I3zzOWWyqFkAVCM3GqeRLMvplD6/+O+5FF7XoHzQB47nk OyZtawy/9gssPWZKLv4qHLYS0wGGCiNbCsYy90s3pfeafM0kSxxjIvEz21KT6LJI /awu2ErQFWCkDMFJ1p/97MjPrQ/6d4cPO140V/wyfuWaBiTVqa9mgnb2zn6fYfDH JEvl1UzIx3JCae25tty1+qtnS0i0LlN0ZXBoZW4gRmFycmVsbCA8c3RlcGhlbkB0 b2xlcmFudG5ldHdvcmtzLmNvbT6JAj0EEwEIACcFAlo9UVoCGwMFCQmUJgAFCwkI BwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+o7HBAAxHAdFkBGZ9gJK8w7 NUYS9C6enGYtAYoKH5G3Bn3YScjErNfQtHYb53KwBQpVSOv1HcN8hbQ8mLTgn9lt zNwNSuv0XxIswi807HRSIZ4vYDiS5VKV1YkLYK5bLY5O4alVdzqM+AZQqkuHBu63 6n+C0ED6UwLhVBFfSNvBQVAdoq6gvr+IE8rCIKTMNGwNcgVPbF+YxP7UZM6p7s2a 5MIqGw7URSfaqfuztibXGOBLFbSwLGqHSSnOXBfEeDrwdZ+ur8cXIIPRIeCTVmeO 8bGgpgBqNQXG9oyGN+TrYAC+4Ahi0UjCk7QGj8tf3xICKoQpYyfceNBZJ/969gV9 tVgvRxUjxUwc9kZbi0c8XYMTq5GCvBIh1D6BOW9QBM2SsNgG3l36+e3+c2LDdyKn 20C1IzGLVDdcCtz42/onQ/e9sMlzFrfLjs5SO2/TnLvp2JtsIQXyb/T5qd0GE5j8 /iwfZR+uVTVVEsUl1a+Yllzt6sdR7RIhhKpKaKzEAk4d0+VHdz7zEkQRRSjbPVoS fy8c/kld9Fi8Buna+ZkKpcwIW+D4XP83pGcl0XUv6AyqwS1LnEt+jv/+PSXskYtU Lzn8Z35iKkSAH/5Nz6GCZk6ORPNv/6+UI92BpUbu/G2tBwK8bPgAg+gJxBx3G7MK W7VRCmM5UrtAK9A3O70VjPyMkHSJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLC LAf/X/9vRTZWtwSXxiBCA54a6hg9IvW0mvPUqgXfvrhtOk0IFucLKrTXK8J/NcmU 6ulxOovVbQ+Bin6gtHeCmSa/W523g/NXCOuFTnS/MyVibNL4+RCFwqGysl++Cm+L nj1MmasE9kO+CNdervx8APfxV7D6OYrG4eGag+LdFR6VpJn6tRT0/WvyT8l+Oqiq gdhXHv+0MvkkD9TX5LlJW4VB/yRvWkkmL5N5c5zYh+NcfTPhQ5S9dOorVzrm65d6 Itn0937Ennau7s7fiFdA0BHjWqEAFLsBIXQfCFjjKjdsKA4xlSiX7X7ElmPYpWa5 wwTQ66dL0anMd9y1DJCMOHe4gYkCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9 g1MSBQJbtyScAAoJEBDvedn9g1MSY7sP+gKR0rFU1g+GtB+hSdtwPRbacvml2eL2 Jc5Eq37J9hAqxHyt5V0If7s8IyVA2GXgdfwULBWbXGDUDiUkh20OPQRUS8G9Sf8A WRuG25q5C8ZzWygykL88RKXJZDFtA49CeqO5Bq5syBhq4QfiSTffQHIp3h0boPGU hSBEUQpooMXYQClNARQ+z/uRzR5bUi9wxdXNnxTn9ia4ASlaBPvUYTGY1jW2HrRR SwpI12+UaWsvc3jJtQ8X0kxgJ7jsFF1uqquIZ5eflQv+PHHg2RJSy37u0UFGb+OK ZEkzlmbPokKCYhzBR5PcD6sgdlaJNcidmto9u1oV6yZT8J2W4CTuUclgxt6f3lZq ZeVLnNnbHyKUdeypwLlqYISulfnMhZ3A6Bgpf2BtjL6KJbFtPBYmYdxI+HZyY49u U2ZHhRu+CSQ1y7zGKSX0gRp5hE7+A4XJtsT6lTLhbi9aiZTG1S6zKNhl3qNNzszc r27PrvFiyGhpuYQuzdQl2PMGbOI6Ojif3sab53NO3RLsLOM09wIlr95yKLlkXkUr WcvUJGrw6HKm8j5opXHTwmJOAbDpc6cMDu+ITRu4spdCnQJcE8RkO8tKyaLuh2Gt U5kYSBK97yr5VviX1FK6rY14LLmnE16OPiK2tiVBKy9nGM0DKtY+K9WcoRZ7s/d7 O0bMfzcNPtGLuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiez GPuBHmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9Wf pHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC 6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2 D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFe A7PbTuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ /Vf3vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbpt PEcmoazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKr em5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96 Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYgh x8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQ oqj1gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P /1tF6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8 Wpfdn3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJ gx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5 SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2 oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIA ypqYo3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoM eDQkd0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS /qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZ IMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XO KVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DJ121 -----END PGP PUBLIC KEY BLOCK----- --------------8D20989A6BA5DE98374F1D07-- --U4jxalB2D8q6SB3qKfIjIswO3ysxMqtc5-- --TLLNDuNgfJtQzjybvNobA9GSEdfle1nma Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlxktSoACgkQWrL68XsX K+qPXA/+NhBlXXIQMh70t7sJhadB+oz3ycvTh6AGpJH6zvdIEUGCKyYG/xN9jhMM LUQBtyY5CQqrDmNKGqSu3+JpS2Xpxf3r35OdKab40gJxnGIVDhm3wwzGIatwqNhJ 28sGmuzfS+3wt2REMVJZKojQ9eYR+L0822eqnuyIRS84cxEotgZAzmIstloblZ/9 S06JJ9FV5UxTHoE6aOAQOqm5dX4gwJ0HKsTYNd69ZQxbjd+DvFchYpPmUPRsK3Hw rXxS+zzc0ZR/vJurJ6mEfejPXGcRyWAJ3etRT/ax4wnHqanCkU8KWco0ZT1Do4bv YiAaK5wLTsMqfGrdn7H0QH5eecBpVPTO0y5jNMEMX+IcugLxQ16eUSAiv2EG7D+n h9WHmK+ltPEK35hSyEEEaVtHiEfgWWkAPL9cUCyB0tzV1lDrTG/V3fuuXwHEFmPb kmk7qZD1aF+vLuCFm3CArFsWha+ruIFYI17qei4WRAHhdrMDnks/TtLcmxew5b+I gxTJnWijZ9BCkG1Vf8jl7bZajH6IXyepux/98HHqM2VbFrXuULry8JDR9H2+6Bhk +X5/4sDLcz3lx512Pcdsb99s1h0dZcQuVvJnrROzf/jY78GOpoFVqRbtE3vWLz5f e5Ec2Wz7b/TdhGq9kvX7yjgFsDHby0j1HW6v5uLTZHGdp1okMxY= =Fmx6 -----END PGP SIGNATURE----- --TLLNDuNgfJtQzjybvNobA9GSEdfle1nma-- From nobody Wed Feb 13 16:59: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 1C7BB130E2B for ; Wed, 13 Feb 2019 16:59:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=Gk1Vpofd; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=dWdbK7qA Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wy7hi9BYw91j for ; Wed, 13 Feb 2019 16:59:49 -0800 (PST) Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (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 AE0241310F4 for ; Wed, 13 Feb 2019 16:59:49 -0800 (PST) Received: from pps.filterd (m0001255.ppops.net [127.0.0.1]) by mx0b-00082601.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x1E0vYLW025291; Wed, 13 Feb 2019 16:59:48 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=4D2Dsqy6D5jRUUbwoErlUtiYXZGPtSuAM0bjKEnlT9Y=; b=Gk1VpofdfRoy3VdaSd9GPLq0w46BkPvh0ap9+0XoAq2wLH57E2VA0Zffm6te0G0yB5m5 0Ud3VH0GvzPd/hXJDU0RSeABBUoJbFz5/Lc8WhpylyY8wkUaCYO7BV9yKduSyp1HnscE sPz5OPCx7Mycglh5yJ5FonB9hlcceFuGmGw= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0b-00082601.pphosted.com with ESMTP id 2qmw778631-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 13 Feb 2019 16:59:47 -0800 Received: from frc-mbx01.TheFacebook.com (2620:10d:c0a1:f82::25) by frc-hub04.TheFacebook.com (2620:10d:c021:18::174) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3; Wed, 13 Feb 2019 16:59:45 -0800 Received: from frc-hub06.TheFacebook.com (2620:10d:c021:18::176) by frc-mbx01.TheFacebook.com (2620:10d:c0a1:f82::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3; Wed, 13 Feb 2019 16:59:45 -0800 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.76) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3 via Frontend Transport; Wed, 13 Feb 2019 16:59:45 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4D2Dsqy6D5jRUUbwoErlUtiYXZGPtSuAM0bjKEnlT9Y=; b=dWdbK7qA+/p3PV230w6sWJXbvHsqUo5+6zWmPvClfKOXd3C+dY+15HzkBZzJtFncCPO5Bt5nKQuha5emWDVYTgNIjE/iCFSDOszr0vmVQPPML/y7y/Ey46BrFUWcegF7Hkj7nYMKin8P9xnHMN/BiDazM6B75pagCsa+QjS7aJ8= Received: from MWHPR15MB1821.namprd15.prod.outlook.com (10.174.255.137) by MWHPR15MB1504.namprd15.prod.outlook.com (10.173.235.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1601.22; Thu, 14 Feb 2019 00:59:43 +0000 Received: from MWHPR15MB1821.namprd15.prod.outlook.com ([fe80::e4f1:9986:a3d:178b]) by MWHPR15MB1821.namprd15.prod.outlook.com ([fe80::e4f1:9986:a3d:178b%8]) with mapi id 15.20.1601.023; Thu, 14 Feb 2019 00:59:43 +0000 From: Subodh Iyengar To: Nick Sullivan CC: Martin Thomson , "tls@ietf.org" Thread-Topic: [TLS] Version pinning and indicating the signing algorithm in draft-ietf-tls-subcerts-02 Thread-Index: AQHUrTjO5Xfdo/YFZ0WGZmDoo9VjL6WxKkyZgAAVfwCAAEa3kIANlqIAgB+JTzg= Date: Thu, 14 Feb 2019 00:59:43 +0000 Message-ID: References: <1547609984.2756240.1635793576.0E070413@webmail.messagingengine.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c090:200::5:6a51] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4ff8e66a-9101-4270-9310-08d69217b4f0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600110)(711020)(4605077)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:MWHPR15MB1504; x-ms-traffictypediagnostic: MWHPR15MB1504: x-ms-exchange-purlcount: 3 x-microsoft-exchange-diagnostics: 1; MWHPR15MB1504; 20:qy0jaHmubpmQNG2qhIPXzk8oApLmD0X8c2lXJR4uzhKA5DN4tejaOuEUs3CZmgka255o4CipJ9xLjIFz1yOM6GSWBoCCXL+A7V4uT53fK7aC7tqr9szAs5/pTPIcBIYTSMSBVh//VwRAGT4FssACAcAt0D2+tOD6Hvcc/zxltrA= x-microsoft-antispam-prvs: x-forefront-prvs: 09480768F8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(396003)(39860400002)(136003)(346002)(189003)(199004)(19627405001)(33656002)(71200400001)(53546011)(486006)(46003)(93886005)(6346003)(105004)(71190400001)(966005)(6246003)(8936002)(6436002)(6916009)(733005)(14454004)(186003)(6506007)(6116002)(97736004)(53936002)(478600001)(54906003)(9686003)(86362001)(68736007)(229853002)(14444005)(99286004)(81166006)(4326008)(256004)(54896002)(7736002)(6306002)(76176011)(8676002)(74316002)(7696005)(25786009)(106356001)(11346002)(105586002)(446003)(476003)(606006)(236005)(102836004)(55016002)(2906002)(316002)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1504; H:MWHPR15MB1821.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Nawuia8J3WVEgnRU8zZKvogLMrSt7nghgYChRRqrrUeA8IaFtKynbq6XTQXzNRxjoCPdEgqngJi/kLkbeZswALiQUfoqh/dl71ljeVwtUcp1nGyJP493yzh+4bTJUMj+gN7hPYZ4y+ydj/lPDQlXCG3iy8LnRtXv7X383a2UUGYwoahQ6lgyWFzf7sYd7NmHVaIIdVsWZg23Ci/LxWYJGAziYVgr87UZLqdGMKOdzljm4OfbI1Uw4ewFGOKgJJeqeTaJewpJpFfATY3itrBqNfWulQuN1thja0VhuSRL/MTNVWMZb2DAxeUdT9JYYBYu7a1uUQ0pwlNzbUzr/yPtsshEgVG6GeiClrJyITuBgKaJ95knTLtMnmzY9f0H/dS8jCgIfBdxDujeN40o0aCWMgdp8z9DRdGkvUK9QCf/rpE= Content-Type: multipart/alternative; boundary="_000_MWHPR15MB18217D273246D69E0251EC76B6670MWHPR15MB1821namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4ff8e66a-9101-4270-9310-08d69217b4f0 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2019 00:59:43.5150 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1504 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-14_01:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: Subject: Re: [TLS] Version pinning and indicating the signing algorithm in draft-ietf-tls-subcerts-02 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, 14 Feb 2019 00:59:53 -0000 --_000_MWHPR15MB18217D273246D69E0251EC76B6670MWHPR15MB1821namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Watson put up a PR https://github.com/tlswg/tls-subcerts/pull/21. I'm going= to merge it tomorrow if there's no other feedback on it. [https://avatars3.githubusercontent.com/u/1123811?s=3D400&v=3D4] Remove protocol from the structure by wbl =B7 Pull Request #21 =B7 tlswg/tl= s-subcerts As discussed in https://mailarchive.ietf.org/arch/msg/tls/h6DiWQvw7Cc0TXUtc= 7fNfB0fFNg and subsequent. github.com Subodh ________________________________ From: Nick Sullivan Sent: Thursday, January 24, 2019 3:23 PM To: Subodh Iyengar Cc: Martin Thomson; tls@ietf.org Subject: Re: [TLS] Version pinning and indicating the signing algorithm in = draft-ietf-tls-subcerts-02 I'm also fine with removing the field and would welcome a PR to that effect= . Putting in a version to protect a DC from future cross-protocol attacks tha= t exploit TLS 1.3 smells a bit like over-engineering anyway. Nick On Tue, Jan 15, 2019 at 11:54 PM Subodh Iyengar > wrote: I don't feel too strongly about the tls version binding and I'd be fine wit= h removing it to favor operational simplification. Subodh ________________________________ From: TLS > on behalf of = Martin Thomson > Sent: Tuesday, January 15, 2019 7:39:44 PM To: tls@ietf.org Subject: Re: [TLS] Version pinning and indicating the signing algorithm in = draft-ietf-tls-subcerts-02 On Wed, Jan 16, 2019, at 13:35, Subodh Iyengar wrote: > Usually the negotiation happens during the processing of the client hello= . I don't think that the problem here is a code problem. It's an operational= one. In many ways, the decision to use TLS 1.3 over TLS 1.2 is one that can be m= ade in isolation. You decide to flip the switch and flip it. But if you a= re doing delegated credentials, deploying a new version depends on having a= fallback in place for that version, or getting the vendor of delegated cre= dentials to start supplying new credentials. And that assumes that all the= necessary stores are keyed correctly (though this highlights the case wher= e that might not happen), and the code has been written. It's not that it'= s impossible, but more that it complicates what was previously uncomplicate= d. As you say, the decision to use a delegated credential is fairly simple. _______________________________________________ TLS mailing list TLS@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_tls&d=3DDwICAg&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3Dh3Ju9EBS7mHtwg-wAyN= 7fQ&m=3DqOxPqAH-53XWS1ivRMVW5YPWzTYrcOjqXPcoImyDlnM&s=3DLwnVFi-5giNs_anA6Dy= KhcbiJ5NCSU5T1oZyDjx33Nw&e=3D _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --_000_MWHPR15MB18217D273246D69E0251EC76B6670MWHPR15MB1821namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Watson put up a PR https://github.com/tlswg/tls-subcerts/pull/21= . I'm going to merge it tomorrow if there's no other feedback on it.
3D""
As discussed in https://mailarchive.ietf.org/arch/msg/tls/h6DiWQvw7Cc0TXUtc= 7fNfB0fFNg and subsequent.
github.com
Subodh
From: Nick Sullivan <nic= k@cloudflare.com>
Sent: Thursday, January 24, 2019 3:23 PM
To: Subodh Iyengar
Cc: Martin Thomson; tls@ietf.org
Subject: Re: [TLS] Version pinning and indicating the signing algori= thm in draft-ietf-tls-subcerts-02
 
I'm also fine with removing the field and would welcome a = PR to that effect.

Putting in a version to protect a DC from future cross-protocol attack= s that exploit TLS 1.3 smells a bit like over-engineering anyway.

Nick

On Tue, Jan 15, 2019 at 11:54 PM Su= bodh Iyengar <subodh@fb.com> wro= te:
I don't feel too strongly about = the tls version binding and I'd be fine with removing it to favor operation= al simplification.


Subodh

On Wed, Jan 16, 2019, at 13= :35, Subodh Iyengar wrote:
> Usually the negotiation happens during the processing of the client he= llo.

I don't think that the problem here is a code problem.  It's an operat= ional one.

In many ways, the decision to use TLS 1.3 over TLS 1.2 is one that can be m= ade in isolation.  You decide to flip the switch and flip it.  Bu= t if you are doing delegated credentials, deploying a new version depends o= n having a fallback in place for that version, or getting the vendor of delegated credentials to start supplying new cred= entials.  And that assumes that all the necessary stores are keyed cor= rectly (though this highlights the case where that might not happen), and t= he code has been written.  It's not that it's impossible, but more that it complicates what was previously uncompli= cated.

As you say, the decision to use a delegated credential is fairly simple.
_______________________________________________
TLS mailing list
TLS@ietf.org
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--_000_MWHPR15MB18217D273246D69E0251EC76B6670MWHPR15MB1821namp_-- From nobody Wed Feb 13 17:00: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 21709130E2B for ; Wed, 13 Feb 2019 16:59:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-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=evequefou.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qEKW0ZqhqJNw for ; Wed, 13 Feb 2019 16:59:49 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-eopbgr740117.outbound.protection.outlook.com [40.107.74.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71B6D1310E8 for ; Wed, 13 Feb 2019 16:59:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KP8Zysy416+KMyf2bQVhJlBnKeN65ahMuKcTFu2Vf44=; b=AeC5iK1ZC9qwh/DHhPu2SDjfD+Rm8M3n0PV++nGyE5SP59g01JZmWSJoIhbuL/T8rK0PjiNZLPSW53vKvpiSs8vhthUNIZwO40a7IlxQbIehzRDqdZC3J/wWVLRrcO/1R9MWuoZJeAKF7GsRuHlqCBGZpeTK9fw1rHIxBxx2yLs= Received: from MWHPR22MB0991.namprd22.prod.outlook.com (10.171.145.21) by MWHPR22MB0927.namprd22.prod.outlook.com (10.171.150.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.16; Thu, 14 Feb 2019 00:59:45 +0000 Received: from MWHPR22MB0991.namprd22.prod.outlook.com ([fe80::31b1:b2c0:74a2:772e]) by MWHPR22MB0991.namprd22.prod.outlook.com ([fe80::31b1:b2c0:74a2:772e%5]) with mapi id 15.20.1601.023; Thu, 14 Feb 2019 00:59:45 +0000 From: Mike Bishop To: Stephen Farrell , David Benjamin CC: TLS WG Thread-Topic: [TLS] ESNI PRs #124 and #125: Improving ESNI Robustness and GREASE Thread-Index: AQHUw+nNk/eOTe+V+kCWfTYTMe1ZNqXeV+IAgAAPlwCAAAfngIAACR9w Date: Thu, 14 Feb 2019 00:59:45 +0000 Message-ID: References: <714E43FA-3660-485A-8E50-04EE43F8DA2E@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [2601:600:8080:701:9d06:2915:dd48:2d23] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fe057233-253e-4394-261a-08d69217b615 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:MWHPR22MB0927; x-ms-traffictypediagnostic: MWHPR22MB0927: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-forefront-prvs: 09480768F8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39830400003)(396003)(376002)(346002)(136003)(13464003)(189003)(199004)(51914003)(6306002)(110136005)(105586002)(6436002)(316002)(25786009)(11346002)(106356001)(9686003)(446003)(55016002)(30864003)(46003)(476003)(86362001)(6506007)(486006)(93886005)(7736002)(6116002)(14454004)(4326008)(256004)(6246003)(102836004)(71190400001)(99286004)(8936002)(81156014)(81166006)(76176011)(229853002)(966005)(33656002)(53936002)(14444005)(74316002)(2906002)(508600001)(7696005)(68736007)(71200400001)(8676002)(74482002)(186003)(97736004)(305945005)(53546011); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR22MB0927; H:MWHPR22MB0991.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-microsoft-exchange-diagnostics: =?utf-8?B?MTtNV0hQUjIyTUIwOTI3OzIzOkViQUhqZjJsbXh4N2NXanpqaGtoZTVFVHM1?= =?utf-8?B?RUlzM2xxL0JLY0pNWDVqc0NaakJWNzBybVZaODFUYXlUejhEM1NrM1hnNU03?= =?utf-8?B?SEFFTjZtSWt2RnNMV0NHRktTNFhrOVBOVFBNS0dkWWxBR3FOWEtERWFXM3Br?= =?utf-8?B?Q3RaWEQ0MzgrNjh6NVNZaW95Wm11V2htZ1lFWWwxb1V0eUtzekJyVDNTK09M?= =?utf-8?B?TnF2VWF5OG1LTTRZMk1vUklEbEZKNUlVb09HUmdCVGR3MGRDdHJSaHZzM051?= =?utf-8?B?MUdhSFhjV1E5QXNCUUZIZ052di9wa296SldGNnhCMmsxT3lHZjI4aGZndTdn?= =?utf-8?B?R05SRXI4aVRoeFh4NlR5b0trWHl4aVArT0hWVyt1ODlWM1N2cGpoOXBzQUl1?= =?utf-8?B?VE9JYU56dDRNcWNsejdQMDR6aTY0NklXZXc5NjVoT3Uzc2huRkJYYlpucmY5?= =?utf-8?B?N05DTlFIRDlZT1hNZlE4UFNwYWtxcTZRY0cycDhWVElsMEVxZHc4ZHhNODlm?= =?utf-8?B?aGptaU1nWDkrS3ZFWGZPL0UrWndCZEdidGIvYXgyZHVUdzZHYmVXeC9jdFNi?= =?utf-8?B?WlRvWkt5UzFrWThjK2hoYk4zNEpIQU1lZVpObk1VWU1UMnVUZ0h4NU1paEF5?= =?utf-8?B?ektoTTFKcHg4VHhMNlBUMWdXcVNjUFB1blZaTi9mdkhwTlNjYktYQmhCM0dk?= =?utf-8?B?UTBLb0JJOC9zSkZ6bkRQZzNvbnVUZ1c0dE9ueG9tNEM1VGNybEpYNFRURm1v?= =?utf-8?B?MmcwZ0puU1EwdlFCTi94RzZPeUkvZmZHTVl2YU9QcEpoK2tOVWdoM1hBQ3ls?= =?utf-8?B?VHN6UXZKelVZRUl4dWNRTXdUam1NTVpYUlBNQlhReW5jcXBFYk53YS93eHdh?= =?utf-8?B?ZmJuU0xUMzdwLzdtTFhlOHFNSXA2RUsyM0ZSbXh2UkZqOExFTGZoMzBjalI5?= =?utf-8?B?T0hlQlovMlI5Q09zL2s5cUpyckMxcE9yRFBockRNTkxITEJCRzROM2o0R0dN?= =?utf-8?B?YW9ORWNMK0M3am51MXNzdlBLR2tZbS93d0ZmRGphbWRXSGlwQmRiVWlkRTJ5?= =?utf-8?B?QmRJampYKzc4RWF3R1E3cTdYMDM0NVdEcGdEQm9HTWxkR2xadkhsZEpwUTNL?= =?utf-8?B?azF1bGx4ZlhCakVoUGROYVNEbEp0ZDcreWp4MUxVUzluVUpORURDOW50Ny9J?= =?utf-8?B?YjJsV09zMGo0aHRRV0wxblQrcks4dXlaOHNYYmZPYXVVdmY0eTN3cllaY0JV?= =?utf-8?B?b3UyT1JhUUNzQ2VuREY5ZU51djV6S2I0V0srUHpHVXNCaGZKVldrSVgvWHJB?= =?utf-8?B?dXd4bGlxVGdVZEhEMXRDeEVsQ2hlQ1lVQ0RPYjJyM1hDU3pTMXUyWEhwellv?= =?utf-8?B?SUU5ZmxibU1SN2ZIRWpsY1o3NElXOWRiQThJVXlWN0Q5MG5vVmZ1YkRDbTl4?= =?utf-8?B?eThScS96TWk4MlQ2M1ZSM3dHSG9uelNjQ0E4SUEyYmFZT1FTNmp5ckFQWTUx?= =?utf-8?B?aTBweENLaGxtTkIrUTA4L0tZSjVYVkhVRlRKc1c0SVZadlRVcEE0TXlIMURy?= =?utf-8?B?NHFDODVsNFFaSXJ2elY4Q01HWm1DSCtOVU1Wa0ovY1ZINGZSREdyNjN6ZFlH?= =?utf-8?B?UUhmUEFyOEw3UldRSXJPa1dpczhjM1F1ZnZML3hEL1pndGpoczFDbXBjdkE2?= =?utf-8?B?NnY0LzdkbnpsRWUwOEMwb1MrM3VoSkQ1aDJ2SjZMaGlkWHppdCtRbnVOQ0pB?= =?utf-8?B?OVdNSlAyNXBrK01wbU02UT09?= x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: KPI/mSt7QkysoU5I3rgKhHI2QdTNkZnnFoVQhmMUL/hs7yIaf5usSEfbghMAP/MY7eKMoP7BQhMEOKo4M6534dzJlECOvzEUUWxaM+uBXcUh/VlAWFE7qsAtAa4xbW4Fu8aJDBXiPam1rUdzuUkpJ+Crgxb1jWnq2q6ar328n1lPE/L917yOfe6i8ZtKR6bLKV4fdhiTQNLQJMHNHZvqxFipMI46Xv54KO+HCN7Bp2f1Sf7Puob/f87aY15wTo4T3grEUr8UQsi+DsSQymwpge1+9f1pW38UhTFWKl3RQBf85ievVubda3jGOE7JL/UTnD3JojTtVWBqWl+GPwD6DfQ59QZbWpi3lF8YuCOKPXPPgKksx6XyDO7ZcZ8ix82YOQiGHvsr9+lp5R1CysHIQvT2lgvXOgA2jNIiJfibrYE= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: fe057233-253e-4394-261a-08d69217b615 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2019 00:59:45.2633 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR22MB0927 Archived-At: Subject: Re: [TLS] ESNI PRs #124 and #125: Improving ESNI Robustness and GREASE 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, 14 Feb 2019 00:59:54 -0000 UGVyaGFwcyBhIGJldHRlciB3YXkgdG8gcGhyYXNlIGl0IGlzIHRoYXQgYSBzZXJ2ZXIgd2hpY2gg c3VjY2Vzc2Z1bGx5IGF1dGhlbnRpY2F0ZXMgYXMgdGhlIHB1YmxpY19uYW1lIGJ1dCBkb2VzIG5v dCBzdXBwb3J0IEVTTkkgaGFzIHNlY3VyZWx5IGRpc2FibGVkIEVTTkkgZm9yIHRoYXQgb3JpZ2lu LCBzdWJqZWN0IHRvIHRoZSBzYW1lIHJ1bGVzIGFzIGlmIGl0IGhhZCBzdXBwbGllZCBhIG5ldyBF U05JIGtleSAoaS5lLiB1c2UgZm9yIG5vdywgYnV0IGRvbid0IHBlcnNpc3QpLiAgTGVhdmUgYXMg YW4gaW1wbGVtZW50YXRpb24gZGV0YWlsIGhldXJpc3RpY3MgdG8gZXh0cmFwb2xhdGUgdGhhdCB0 aGUgY3VycmVudCBuZXR3b3JrIHdpbGwgc2VjdXJlbHkgZGlzYWJsZSBFU05JIGZvciBhbGwgb3Jp Z2lucy4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFRMUyA8dGxzLWJvdW5j ZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBTdGVwaGVuIEZhcnJlbGwNClNlbnQ6IFdlZG5lc2Rh eSwgRmVicnVhcnkgMTMsIDIwMTkgNDoyNCBQTQ0KVG86IERhdmlkIEJlbmphbWluIDxkYXZpZGJl bkBjaHJvbWl1bS5vcmc+DQpDYzogVExTIFdHIDx0bHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTog W1RMU10gRVNOSSBQUnMgIzEyNCBhbmQgIzEyNTogSW1wcm92aW5nIEVTTkkgUm9idXN0bmVzcyBh bmQgR1JFQVNFDQoNCg0KSGl5YSwNCg0KVmFyaW91cyBiaXRzJ24ncGllY2VzIGJlbG93Li4uDQoN Ck9uIDEzLzAyLzIwMTkgMjM6NTUsIERhdmlkIEJlbmphbWluIHdyb3RlOg0KPiBUaGFua3MgZm9y IHRoZSBjb21tZW50cyEgUmVzcG9uc2VzIGlubGluZS4NCj4gDQo+IE9uIFdlZCwgRmViIDEzLCAy MDE5IGF0IDU6MDAgUE0gU3RlcGhlbiBGYXJyZWxsIA0KPiA8c3RlcGhlbi5mYXJyZWxsQGNzLnRj ZC5pZT4NCj4gd3JvdGU6DQo+IA0KPj4NCj4+IEhpeWEsDQo+Pg0KPj4gT24gMTMvMDIvMjAxOSAy MjoxNSwgQ2hyaXN0b3BoZXIgV29vZCB3cm90ZToNCj4+Pg0KPj4+DQo+Pj4gWzFdIGh0dHBzOi8v Z2l0aHViLmNvbS90bHN3Zy9kcmFmdC1pZXRmLXRscy1lc25pL3B1bGwvMTI0DQo+Pg0KPj4gSSBq dXN0IHJlLXJlYWQgdGhhdC4gSSd2ZSBhIHF1ZXN0aW9uOiB3aHkgdGllIHRoZSB2ZXJzaW9uIGNo YW5nZSB0byANCj4+IHRoaXMgUFIgYW5kIG5vdCB0aGUgSS1EIHJldj8gSSdkIHByZWZlciBpZiB3 ZSBtYWtlIHRoZSBjaGFuZ2UgdG8gDQo+PiAweGZmMDIgd2hlbiAtMDMgaXMgcHVibGlzaGVkLiAo SSBkb24ndCBjYXJlIHdoaWNoIFBSIGRvZXMgdGhhdCwgYnV0IA0KPj4gd291bGRuJ3QgbGlrZSB0 byBzZWUgZXZlcnkgUFIgYnVtcCB0aGF0IG51bWJlci4pDQo+Pg0KPiANCj4gSSBidW1wZWQgaXQg YmVjYXVzZSB0aGUgUFIgd2FzIG1ha2luZyBhIHdpcmUtaW5jb21wYXRpYmxlIGNoYW5nZSwgYnV0 IA0KPiBiYXRjaGluZyB0aGVtIHVwIHRvIEktRCByZXZzIG1ha2VzIHNlbnNlIHRvby4gTm8gcHJl ZmVyZW5jZXMgaGVyZS4gDQo+IChTcGVjIGVkaXRvcnMsIGRvIHlvdSBjYXJlPyBJIGNhbiByZW1v dmUgdGhhdCBwYXJ0IG9mIHRoZSBjaGFuZ2UuKQ0KPiANCj4gDQo+PiBBc2lkZSBmcm9tIHRoYXQg SSB0aGluayBpdCdzIG9rICh0aG91Z2ggSSBtYXkgZmluZCBvdGhlciBpc3N1ZXMgd2hlbiANCj4+ IGltcGxlbWVudGluZyBsYXRlcikgd2l0aCB0d28gY2F2ZWF0cyB0aGF0IGNhbiBiZSBoYW5kbGVk IG5vdyBvciANCj4+IGxhdGVyOg0KPj4NCj4+IDEuIFRoZSBETlMgUlIgc3RydWN0dXJlIHN0aWxs IG5lZWRzIGZpeGluZyBidXQgdGhhdCBpcyBsaWtlbHkgYmV0dGVyIA0KPj4gaGFuZGxlZCBzZXBh cmF0ZWx5LiAoQnkgImZpeGluZyIgSSBtZWFuIGEgbmV3IFJSIHR5cGUgYnV0IGFsc28gdGhhdCAN Cj4+IGl0IG5lZWRzIHRvIGJlIGRlc2lnbmVkIGZvciBETlMgYWRtaW5zIGFzIHdlbGwgYW5kIG5v dCBvbmx5IGZvciBUTFMgDQo+PiBpbXBsZW1lbnRlcnMgd2hpY2ggaXMgdGhlIGN1cnJlbnQgY2Fz ZS4NCj4+IChJJ20gbm90IHNheWluZyB3aGF0IG1pZ2h0IG9yIG1pZ2h0IG5vdCBtYWtlIGl0IG1v cmUgZG5zb3BzIGZyaWVuZGx5LCANCj4+IGp1c3QgdGhhdCB0aGF0IG5lZWRzIHRvIGJlIGNoZWNr ZWQvZG9uZSBzb21ldGltZS4pDQo+Pg0KPiANCj4gSSdtIGd1ZXNzaW5nIHRoaXMgaXMgdG8gZG8g d2l0aCB0aGUgdmFyaW91cyBkaXNjdXNzaW9ucyBhcm91bmQgDQo+IG11bHRpLUNETiBhbmQgd2hh dG5vdD8gVGhhdCBzZWVtcyBvcnRob2dvbmFsIHRvIHRoYXQgUFIuIChJIGRvbid0IA0KPiBwZXJz b25hbGx5IGhhdmUgcGFydGljdWxhcmx5IHN0cm9uZyBvcGluaW9ucyBvciBleHBlcmllbmNlIHRo ZXJlLikNCg0KTm90IGp1c3QgdGhhdC4gRVNOSUtleXMgaXMgYSBmYWlybHkgY29tcGxleCBzdHJ1 Y3R1cmUgdGhhdCBoYXMgYSBudW1iZXIgc2V0cy9zZXF1ZW5jZXMgb2YgdmFsdWVzLiBUaGVyZSBh cmUgdmFyaW91cyBwb3NzaWJsZSBkZXBsb3ltZW50IG1vZGVscy4gVGhlIGN1cnJlbnQgc3RydWN0 dXJlIGFzc3VtZXMgdGhhdCBpdCdzIG9rIHRvIGVuY29kZSBhbGwgdGhhdCBzdHVmZiB1cCBpbiBv bmUgVExTIHN0eWxlIGJsb2IgYW5kIHRoZW4gcHV0IHRoYXQgaW4gdGhlIEROUy4gVGhhdCBtaWdo dCBub3QgbWFrZSBzZW5zZSBmb3Igc29tZSBkZXBsb3ltZW50cyBpbiBwYXJ0aWN1bGFyIHdoZXJl IHRoZSBETlMgb3BlcmF0b3IgaXMgbm90IGNsb3NlbHkgdGllZCB0byB0aGUgVExTIHNlcnZlciBh ZG1pbiBvciB3aGVyZSB0aGVyZSdzDQoxIEROUyBvcGVyYXRvciBhbmQgTiBUTFMgc2VydmVyIGFk bWlucyAoZm9yIHRoZSBzYW1lIG9yaWdpbikuDQpBbmQgdGhlbiB0aGVyZSdzIHRoZSB1c2Ugb2Yg dGhlIFRYVCBSUi4gQnV0IEkgYWdyZWUgdGhpcyBpcyBvcnRob2dvbmFsIC0gSSB3YXMgbW9zdGx5 IHNheWluZyB0aGF0IGluIGFncmVlaW5nIHdpdGggdGhpcyBQUiBJIGNvbnRpbnVlIHRvIHRoaW5r IHRoZSBETlMgUlIgc3R1ZmYgbmVlZHMgb3RoZXIgd29yay4NCg0KPiANCj4gDQo+PiAyLiBJIGRv bid0IHRoaW5rIHRoZSB0ZXh0IGJlbG93IG91Z2h0IGJlIGluY2x1ZGVkLCBpdCdzIG5vdCB0aGUg am9iIA0KPj4gb2YgdGhpcyBXRyB0byBkZXNpZ24gTUlUTSBhdHRhY2tzLiAoT3IgbWF5YmUgSSd2 ZSBtaXNpbnRlcnByZXRlZCBpdD8pDQo+Pg0KPj4gIlRoZSBwdWJsaWMgbmFtZSwgaG93ZXZlciwg bWFrZXMgdGhpcyBwcm90b2NvbCBjb21wYXRpYmxlIHdpdGggDQo+PiBkZXBsb3ltZW50cyB0aGF0 IHVzZSBjb3JyZWN0bHktaW1wbGVtZW50ZWQgTUlUTSBwcm94aWVzLiBJZiB0aGUgDQo+PiBjbGll bnQgaGFzIGNhY2hlZCBhbiBFU05JS2V5IGZvciB0aGUgb3JpZ2luIHNlcnZlciwgdGhlIE1JVE0g cHJveHkgDQo+PiB3aWxsIHByb2Nlc3MgdGhlIGNsZWFydGV4dCBTTkkgZmllbGQgYW5kIHRlcm1p bmF0ZSBhIGNvbm5lY3Rpb24gdG8gDQo+PiB0aGUgcHVibGljIG5hbWUgaW5zdGVhZC4gSWYgdGhl IGNsaWVudCBpcyBjb25maWd1cmVkIHRvIHRydXN0IHRoZSANCj4+IHByb3h5J3MgY2VydGlmaWNh dGUsIGl0IHdpbGwgYWNjZXB0IHRoZSBjb25uZWN0aW9uIGFzIHZhbGlkIGZvciB0aGUgDQo+PiBw dWJsaWMgbmFtZSBhbmQgcmV0cnkgd2l0aCBFU05JIGRpc2FibGVkLiINCj4+DQo+IA0KPiBUaGF0 IHRleHQgaXNuJ3QgcHJlc2NyaWJpbmcgYW55IHBhcnRpY3VsYXIgYmVoYXZpb3IuIA0KDQpUaGVu IGRlbGV0ZSBpdDotKQ0KDQo+IEl0J3MganVzdCBkZXNjcmliaW5nDQo+IHRoZSBlZmZlY3QgdGhl IHJlc3Qgb2YgdGhlIHRleHQgaGFzIG9uICJ0cnVzdGVkIE1JVE0gcHJveGllcyIgYW5kIHRoZSBs aWtlLg0KDQpEaXNhZ3JlZS4gIkp1c3QgZGVzY3JpYmluZyIgZG9lcyBub3QgbWF0Y2ggdGhlIHVz ZSBvZiBhIG1lYW5pbmdsZXNzIG1hcmtldGluZyB0ZXJtIGxpa2UgInRydXN0ZWQgYmxhaCBwcm94 eSIgc29ycnkuIEJldHRlciB0byBhdm9pZCBhbGwgdGhhdCBmdXNzIHJlYWxseSwgbm8/DQoNCj4g Tm90ZSB0aGlzIGlzIHNwZWNpZmljYWxseSBhYm91dCAiTUlUTSBwcm94aWVzIiB3aGljaCBjb250 cm9sIGEgcm9vdCANCj4gY2VydGlmaWNhdGUgdGhhdCB0aGUgY2xpZW50IGlzIGNvbmZpZ3VyZWQg dG8gdHJ1c3QuIEkgd2lsbCByZWZyYWluIA0KPiBmcm9tIGNvbW1lbnRpbmcgb24gd2hldGhlciB0 aGlzIGRlcGxveW1lbnQgbW9kZWwgaXMgYXQgYWxsIHdpc2UsIGJ1dCANCj4gaXQgZG9lcyBleGlz dCAoYW50aXZpcnVzLCBldGMpLiBUaGUgdGV4dCBpdHNlbGYgaXMganVzdCBhbiB1cGRhdGVkIA0K PiB2ZXJzaW9uIG9mIGV4aXN0aW5nIGJpdHMgaGVyZToNCj4gaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtdGxzLWVzbmktMDIjc2VjdGlvbi02LjINCg0KSSBkb24ndCByZWNh bGwgdGhhdCBoYXZpbmcgYSBjb25jZXB0IG9mIGl0IGJlaW5nIHBvc3NpYmxlIHRvICJjb3JyZWN0 bHkiIGltcGxlbWVudCBicmVha2luZyB0aGUgVExTIHByb3RvY29sPyAoQXMgaXMgaW5oZXJlbnQg aW4gYmVpbmcgYW4gTUlUTS4pDQoNCj4gDQo+IEFzIGZvciB3aGVyZSB0aGlzIGVmZmVjdCBjb21l cyBmcm9tLCBpdCdzIGEgY29uc2VxdWVuY2Ugb2YgdGhlIA0KPiByb2xsYmFjayBhbmQgcGFydGlh bCBkZXBsb3ltZW50IHJvYnVzdG5lc3MgbWVjaGFuaXNtIGluIHRoZSBQUjoNCj4gDQo+PiBJZiB0 aGUgc2VydmVyIG5lZ290aWF0ZXMgYW4gZWFybGllciB2ZXJzaW9uIG9mIFRMUywgb3IgaWYgaXQg ZG9lcyBub3QgDQo+PiBwcm92aWRlIGFuICJlbmNyeXB0ZWRfc2VydmVyX25hbWUiIGV4dGVuc2lv biBpbiBFbmNyeXB0ZWRFeHRlbnNpb25zLCANCj4+IHRoZSBjbGllbnQgcHJvY2VlZHMgd2l0aCB0 aGUgaGFuZHNoYWtlLCB2ZXJpZnlpbmcgdGhlIGNlcnRpZmljYXRlIA0KPj4gYWdhaW5zdCBFU05J S2V5cy5wdWJsaWNfbmFtZSBhcyBkZXNjcmliZWQgaW4ge3t2ZXJpZnktcHVibGljLW5hbWV9fS4g DQo+PiBUaGUgY2xpZW50DQo+IE1VU1QNCj4+IE5PVCBlbmFibGUgdGhlIEZhbHNlIFN0YXJ0IG9w dGltaXphdGlvbiB7e1JGQzc5MTh9fS4gSWYgdGhlIGhhbmRzaGFrZQ0KPiBjb21wbGV0ZXMNCj4+ IHN1Y2Nlc3NmdWxseSwgdGhlIGNsaWVudCBNVVNUIGFib3J0IHRoZSBjb25uZWN0aW9uIHdpdGgg YW4NCj4gImVzbmlfcmVxdWlyZWQiIGFsZXJ0Lg0KPj4gSXQgdGhlbiBTSE9VTEQgcmV0cnkgdGhl IGhhbmRzaGFrZSB3aXRoIGEgbmV3IHRyYW5zcG9ydCBjb25uZWN0aW9uIA0KPj4gYW5kDQo+IEVT TkkNCj4+IGRpc2FibGVkLiINCj4gDQo+IE9yLCBpbiBvdGhlciB3b3JkcywgSUYgdGhlIHNlcnZl ciBpcyBhYmxlIHRvIHNwZWFrIGF1dGhvcml0YXRpdmVseSBmb3IgDQo+IHRoZSBwdWJsaWMgbmFt ZSAocmVsYXRpdmVseSB0byB0aGUgY2xpZW50J3MgdHJ1c3QgYW5jaG9ycykgYnV0IGFwcGVhcnMg DQo+IHRvIG5vdCB1bmRlcnN0YW5kIEVTTkkgYXQgYWxsLCB0aGF0IGlzIGEgc2lnbmFsIHRvIHRo ZSBjbGllbnQgdGhhdCANCj4gRVNOSSBnb3QgdHVybmVkIG9mZiBvciBoYXNuJ3QgZnVsbHkgYmVl biB0dXJuZWQgb24geWV0LiBFU05JIGludm9sdmVzIA0KPiBjbGllbnQgc3RhdGUgYW5kLCB3aXRo b3V0IHRoaXMsIGl0J3Mgcmlza3kgZm9yIGEgc2VydmVyIG9wZXJhdG9yIHRvIA0KPiBkZXBsb3kg RVNOSS4gRGVwbG95bWVudHMgYXJlIGNvbXBsZXggc3lzdGVtcywgYW5kIGNvbXBsZXggc3lzdGVt cyANCj4gcmVhY3QgdG8gY2hhbmdlIHVucHJlZGljdGFibHkuIEZvciBtb3N0IGNoYW5nZXMsIGlm IHNvbWUgc2hvdy1zdG9wcGluZyANCj4gcHJvYmxlbSBpcyBmb3VuZCwgaXQgaXMgc2FmZSB0byBy b2xsYmFjayB0aGUgY2hhbmdlLiBGb3IgaW5zdGFuY2UsIA0KPiBjbGllbnRzIG5hdHVyYWxseSB0 b2xlcmF0ZSBzZXJ2ZXJzIHR1cm5pbmcgVExTIDEuMyBvbiBhbmQgb2ZmLCBhIGZhY3QgDQo+IEkn bSBzdXJlIGV2ZXJ5IGVhcmx5IGFkb3B0ZXIgb2YgVExTIDEuMyBoYXMgdXNlZCBtYW55IHRpbWVz LiBFU05JLCBhIA0KPiBwcmlvcmksIGJyZWFrcyB0aGlzIHByb3BlcnR5LiBUaGUgaW50ZW50IG9m IHRoaXMgdGV4dCBpcyB0byByZXN0b3JlIA0KPiBpdCwgd2l0aG91dCB0b3RhbGx5IGJyZWFraW5n IGl0ICh0aGUgc3RvcCBzaWduYWwgaXMgYXV0aGVudGljYXRlZCANCj4gdW5kZXIgdGhlIHB1Ymxp YyBuYW1lLCB0aGUgc2FtZSBzdGFuZGFyZCB0aGlzIFBSIHNldHMgZm9yIHJlcGxhY2luZyB0aGUg a2V5KS4NCg0KSXQgbWF5IGJlIG9rIHRvIGxpdmUgd2l0aCBzdWNoIGZhbGxiYWNrIHdoaWxzdCBF U05JIGlzIGJlaW5nIGludHJvZHVjZWQgYnV0IEkgdGhpbmsgb25nb2luZyBzdXBwb3J0IGZvciBp dCB3b3VsZCBiZSB1bndpc2UuDQpBbmQgc3VjaCBhIGZhbGxiYWNrIHJlcXVpcmVzIG5vIGRpc2N1 c3Npb24gb2YgTUlUTSBhdHRhY2tzLg0KKE90aGVyIHRoYW4gYXMgYW4gYXR0YWNrLikNCg0KPiAN Cj4gSXQgdHVybnMgb3V0IHRoYXQgYSB1c2VyIG1vdmluZyBpbiBhbmQgb3V0IG9mIG9uZSBvZiB0 aGVzZSAidHJ1c3RlZCBNSVRNcyINCg0KSSBvYmplY3QgdG8gdGhhdCB0ZXJtIGFnYWluLCBzb3Jy eTotKSBJdCdzIG1hcmtldGluZyBtZWFuaW5nbGVzc25lc3MuDQoNCj4gbG9va3MgdGhlIHNhbWUg YXMgYSByb2xsYmFjaywgc28gd2UgZ2V0IHJvYnVzdG5lc3MgdG8gdGhhdCBzY2VuYXJpbyB0b28u DQo+IFRoZSBjdXJyZW50IGRyYWZ0IGF0dGVtcHRlZCB0byBoYW5kbGUgdGhpcyBjYXNlIHRvbywg YnV0IGRpZCBzbyB3aXRoIA0KPiBleHRyYSBtYWNoaW5lcnkuIEZyb20gdGhlIGxpbmsgYWJvdmU6 DQo+IA0KPj4gICBBIFdlYiBjbGllbnQgY2xpZW50IGNhbiBzZWN1cmVseSBkZXRlY3QgY2FzZSAo MikgYmVjYXVzZSBpdCB3aWxsDQo+PiAgIHJlc3VsdCBpbiBhIGNvbm5lY3Rpb24gd2hpY2ggaGFz IGFuIGludmFsaWQgaWRlbnRpdHkgKG1vc3QgbGlrZWx5KQ0KPj4gICBidXQgd2hpY2ggaXMgc2ln bmVkIGJ5IGEgY2VydGlmaWNhdGUgd2hpY2ggZG9lcyBub3QgY2hhaW4gdG8gYQ0KPj4gICBwdWJs aWNseSBrbm93biB0cnVzdCBhbmNob3IuICBUaGUgY2xpZW50IGNhbiBkZXRlY3QgdGhpcyBjYXNl IGFuZA0KPj4gICBkaXNhYmxlIEVTTkkgd2hpbGUgaW4gdGhhdCBuZXR3b3JrIGNvbmZpZ3VyYXRp b24NCj4gDQo+IEhlcmUsIHRoZXJlIGlzIG5vIG5hbWUgY2hlY2ssIHNvIGFueSBwdWJsaWNseSBr bm93biByb290IHRoYXQgdGhlIA0KPiBjbGllbnQgdHJ1c3RzIGNhbiBiZSB1c2VkIHRvIHRyaWdn ZXIgdGhhdCBmYWxsYmFjaywgZXZlbiBpZiBpdCdzIGp1c3QsIA0KPiBzYXksIGFuIGludHJhbmV0 IHNlcnZlciBhbmQgbm90IGEgTUlUTSBwcm94eS4gVGhlIFBSIGZpeGVzIHRoaXMgYnkgDQo+IGNo ZWNraW5nIHRoZSBwdWJsaWMgbmFtZS4gSXQgb25seSBjb3VudHMgYXMgYSBzaWduYWwgaWYgdGhl IHNlcnZlciBjYW4gDQo+IHNwZWFrIGZvciB0aGUgc2VydmljZSdzIHB1YmxpYyBuYW1lLCBub3Qg YW55IGFyYml0cmFyeSBuYW1lLg0KPiANCj4gSSBhbHNvIGRvbid0IHRoaW5rIEknZCBpbXBsZW1l bnQgdGhhdCBmYWxsYmFjayBpbiBteSBvcGVuc3NsDQo+PiBmb3JrLiBFYXJsaWVyIHRleHQgc2F5 cyB0byBjb21wbGV0ZSB0aGUgaC9zIGJ1dCB0byBub3QgbWFrZSB0aGF0IA0KPj4gdmlzaWJsZSB0 byB0aGUgYXBwbGljYXRpb24gbGF5ZXIgYW5kIHRoZSBhYm92ZSBzZWVtcyB0byBjb25mbGljdCB3 aXRoIA0KPj4gdGhhdC4gSSBjb3VsZCBob2xkIG15IG5vc2Ugd2VyZSB0aGF0IGluIC0wMyBhcyBp dCBoYXMgbm8gZWZmZWN0IA0KPj4gcmVhbGx5LCBidXQgSSdsbCB3aGluZSBhYm91dCBpdCBsYXRl ciBmb3Igc3VyZTstKQ0KPj4NCj4gDQo+IEknbSBndWVzc2luZyB5b3UncmUgcmVmZXJyaW5nIHRv IHRoaXM/DQo+IA0KPj4gTm90ZSB0aGF0IHZlcmlmeWluZyBhIGNvbm5lY3Rpb24gZm9yIHRoZSBw dWJsaWMgbmFtZSBkb2VzIG5vdCB2ZXJpZnkgDQo+PiBpdA0KPiBmb3IgdGhlDQo+PiBvcmlnaW4u IFRoZSBUTFMgaW1wbGVtZW50YXRpb24gTVVTVCBOT1Qgc3VyZmFjZSBzdWNoIGNvbm5lY3Rpb25z IGFzDQo+IHN1Y2Nlc3NmdWwgdG8NCj4+IHRoZSBhcHBsaWNhdGlvbi4NCj4gDQo+IFRoYXQganVz dCBzYXlzIHlvdSBjYW4ndCByZXBvcnQgaXQgYXMgc3VjY2Vzc2Z1bC4gDQoNCiJNVVNUIE5PVCBz dXJmYWNlIiBzZWVtcyBsaWtlIGJhZCBwaHJhc2luZyB0aGVuLg0KDQo+IFdoZXRoZXIgeW91IHJl cG9ydCBpdCB0bw0KPiB0aGUgYXBwbGljYXRpb24gYXQgYWxsIGRlcGVuZHMgb24geW91ciBBUEkg c2hhcGUuIEZvciBhIGxvdy1sZXZlbCBUTFMgDQo+IGxpYnJhcnkgdGhhdCBkb2Vzbid0IGNyZWF0 ZSB0cmFuc3BvcnQgY29ubmVjdGlvbnMsIEknbSBlbnZpc2lvbmluZyBpdCANCj4gcmVwb3J0IGZh aWx1cmUgd2l0aCBhIHNwZWNpYWwgZXJyb3IgY29kZSwgd2hpY2ggaGlnaGVyLWxldmVsIGxvZ2lj IGNhbiANCj4gaW50ZXJwcmV0IGFzIGEgcmV0cnkuDQoNClRoYXQgd291bGQgYmUgb2suIFNheWlu ZyB0aGF0IHJlcXVpcmVzIG5vIGRpc2N1c3Npb24gb2YgTUlUTSBhdHRhY2tzLg0KKE15IG9wZW5z c2wgY29kZSB3b3VsZCBhY3R1YWxseSBtYWtlIHRoYXQgdmlzaWJsZSB0byB0aGUgYXBwbGljYXRp b24gaWYgdGhlIGFwcGxpY2F0aW9uIGNhbGxlZCBhIHN0YXR1cyBBUEksIGJ1dCB0aGUgVExTIGgv cyB3b3VsZCBoYXZlIGZhaWxlZCBmcm9tIHRoZSBhcHBsaWNhdGlvbiBQT1YgZXZlbiBpZiB0aGUg aC9zIGxvb2tzIGxpa2UgaXQgd29ya2VkIG9uIHRoZSB3aXJlLikNCg0KPiAoVGhpcyBpcyBob3cg d2UgaGFuZGxlIDAtUlRUIHJlamVjdHMgaW4gQm9yaW5nU1NMLg0KPiAwLVJUVCByZWplY3RzIGFm ZmVjdCBjb25uZWN0aW9uIHVzYWdlLCBzdWNoIGFzIGlmIHlvdSB0aG91Z2h0IHlvdSB3ZXJlIA0K PiBzcGVha2luZyBIVFRQLzIsIGJ1dCB0aGUgc2VydmVyIHJlamVjdGVkIGFuZCB0aGVuIG5lZ290 aWF0ZWQgSFRUUC8xLjEuIA0KPiBJdCdzIHVsdGltYXRlbHkgYSB2ZXJ5IGZ1bm55IHJldHJ5Likg Rm9yIGhpZ2hlci1sZXZlbCBjb2RlIHRoYXQga25vd3MgDQo+IGhvdyB0byBtYWtlIHRyYW5zcG9y dCBjb25uZWN0aW9ucywgb25lIG9wdGlvbiB0aGVuIGlzIGZvciB0aGUgcmV0cnkgdG8gDQo+IGJl IGhhbmRsZWQgbW9yZSB0cmFuc3BhcmVudGx5Lg0KPiANCj4gDQo+Pj4gWzJdIGh0dHBzOi8vZ2l0 aHViLmNvbS90bHN3Zy9kcmFmdC1pZXRmLXRscy1lc25pL3B1bGwvMTI1DQo+Pg0KPj4gSSBsaWtl IHRoaXMgb25lLiBCdXQgdGhlICJTSE9VTEQgc2VuZCIgYW5kICJNVVNUIHBhZCB0byAyNjAiDQo+ PiBzZWVtIGEgYml0IE9UVCB0byBtZSwgdGhvdWdoIEkgY291bGQgbGl2ZSB3aXRoICdlbSBmb3Ig bm93Lg0KPj4gU28gY29uc2lkZXIgdGhlc2Ugbml0cywgbm90IG9iamVjdGlvbnM6DQo+Pg0KPiAN Cj4gKDI2MCBpcyBqdXN0IGEgU0hPVUxEIHJhdGhlciB0aGFuIGEgTVVTVC4gTW9yZSBiZWxvdy4p DQo+IA0KPiANCj4+IC0gUmF0aGVyIHRoYW4gIlNIT1VMRCBzZW5kIiwgaXQgbWF5IGJlIGJldHRl ciB0byBzYXkgc29tZXRoaW5nIGxpa2UgDQo+PiAiU0hPVUxEIGZyZXF1ZW50bHkgc2VuZCIgYW5k IGxlYXZlIGl0IHRvIGNsaWVudHMgdG8gZGVjaWRlIGhvdyBvZnRlbiANCj4+IHRvIGdyZWFzZS4g V291bGRuJ3QgdGhhdCBoYXZlIHRoZSBzYW1lIGVmZmVjdD8NCj4+DQo+IA0KPiBJcyB0aGVyZSBh bnkgcmVhc29uIG5vdCB0byBqdXN0IGRvIGl0IGluIGV2ZXJ5IENsaWVudEhlbGxvPw0KDQpJJ2Qg Z3Vlc3MgdGhhdCBzb21lIGltcGxlbWVudGVycyBtYXkgYmUgcHV0IG9mZiBieSB0aGUgd2FzdGVk IGJhbmR3aWR0aC4gT3RoZXJzIHdvbid0IGNhcmUgYnV0IGlmIGl0J3MgdGhlIGNhc2UgdGhhdCBz ZW5kaW5nIGEgYm9ndXMgRVNOSSB4JSBvZiB0aGUgdGltZSBnZXRzIGFzIGdvb2QgYSByZXN1bHQg YXMgc2VuZGluZyBhbGwgdGhlIHRpbWUgKHdoaWNoIGlzIGhvdyBJIGludGVycHJldCB3aGF0IHRo ZSBTSE9VTEQgY2FsbHMgZm9yKSB0aGVuIGl0IHNlZW1zIGJldHRlciB0byBlbmNvdXJhZ2UgeCUg YW5kIG5vdCAxMDAlLg0KDQo+IA0KPiANCj4+IC0gTWF5YmUgYWRkIHRoYXQgZXZlbiBUTFMxLjMg Y2xpZW50cyB0aGF0IGRvbid0IHJlYWxseSBkbyBFU05JIE1BWSANCj4+IGdyZWFzZSBFU05JPyAo QSBiaXQgd2VpcmQgYnV0IGhleSB3aHkgbm90PzotKQ0KPj4NCj4gDQo+IEluZGVlZCEgVGhlIFBS IGN1cnJlbnRseSBzYXlzOg0KPiANCj4+IElmIHRoZSBjbGllbnQgYXR0ZW1wdHMgdG8gY29ubmVj dCB0byBhIHNlcnZlciBhbmQgZG9lcyBub3QgaGF2ZSBhbg0KPiBFU05JS2V5cw0KPj4gc3RydWN0 dXJlIGF2YWlsYWJsZSBmb3IgdGhlIHNlcnZlciwNCg0KIlRoZSBjbGllbnQiIGluIGFsbW9zdCBh bGwgSUVURiBzcGVjcyBtZWFucyBhIHRoaW5nIHRoYXQgcmVhbGx5IGltcGxlbWVudHMgdGhlIHNw ZWMuIFNvIGluIHRoaXMgY2FzZSwgeWVhaCwgSSB0aGluayBpdCBtaWdodCBiZSBnb29kIHRvIHNh eSB0aGF0IGEgVExTIGNsaWVudCBpbXBsZW1lbnRlciB3aG8gb25seSBoYXMgdGltZSB0byBncmVh c2UgYW5kIG5vdCBkbyB0aGUgcmVhbCB0aGluZyBpcyBzdGlsbCBkb2luZyBnb29kIG92ZXJhbGwg YnkganVzdCBkb2luZyB0aGF0LiAoVGhhdCBzYWlkLCBJJ3ZlIG5vIGlkZWEgaWYgdGhlcmUnZCBl dmVyIGJlIHN1Y2ggYW4gaW1wbGVtZW50ZXIsIHRob3VnaCB3aGVuIHdlIGRpZCBES0lNIHRoZXJl IHdlcmUgbWFueSBtYWlsIHJlY2VpdmVycyB3aG8gcGFyc2VkIGJ1dCBkaWRuJ3QgYWN0dWFsbHkg Y2hlY2sgc2lnbmF0dXJlcyAtIG1heWJlIG1haWwgaW1wbGVtZW50ZXJzIGFyZSBtb3JlIHNsYXBk YXNoIHRob3VnaDotKQ0KDQo+IA0KPiBLbm93aW5nIHdoYXQgRVNOSSBpcyBidXQgbm90IHJlYWxs eSBkb2luZyBpdCBJIHRoaW5rIGNvdW50cyBhcyAiZG9lcyANCj4gbm90IGhhdmUgYW4gRVNOSUtl eXMgc3RydWN0dXJlIGF2YWlsYWJsZSIuIERvIHlvdSB0aGluayBpdCBzaG91bGQgYmUgDQo+IGNh bGxlZCBvdXQgbW9yZSBleHBsaWNpdGx5Pw0KPiANCj4gDQo+PiAtIFBhZGRpbmcgdG8gMjYwIGlz IElJUkMgdGhlIG1heCB0aGF0IHdvcmtzLiBBIENIIHdpdGggc3VjaCBwYWRkaW5nIA0KPj4gaXMg fjYwMCBieXRlcy4gU2VlbXMgbGlrZSBhIHdhc3RlIG9mIGJ5dGVzIHRvIG1lIGFuZCBpdCBjb3Vs ZCBzdGljayANCj4+IG91dCBkZXBlbmRpbmcgb24gcmVhbCBFU05JIHBhZGRpbmdfbGVuZ3Rocy4N Cj4+IE1heWJlIGNvbnNpZGVyIHNvbWV0aGluZyBsaWtlICJwYWQgdG8gYSBsZW5ndGggdGhhdCBt YXRjaGVzIHJlY2VudCANCj4+IHRyYWZmaWMiIGFuZCBsZWF2ZSBpdCB0byBjbGllbnRzIHRvIGZp Z3VyZSBvdXQgd2hhdCBtaWdodCBzdGljayBvdXQgDQo+PiBsZXNzLiAoSSdtIG5vdCBzdXJlIGV2 ZXJ5IHNlcnZlciB3aWxsIGFzayBmb3IgcGFkZGluZyB0byAyNjAgYXMgQ0YgDQo+PiBkbzstKQ0K Pj4NCj4gDQo+IDI2MCBjb21lcyBmcm9tIGVsc2V3aGVyZSB3aGljaCBzYXlzOg0KPiANCj4+IFRo ZSBsZW5ndGggdG8gcGFkIHRoZSBTZXJ2ZXJOYW1lTGlzdCB2YWx1ZSB0byBwcmlvciB0byBlbmNy eXB0aW9uLg0KPj4gVGhpcyB2YWx1ZSBTSE9VTEQgYmUgc2V0IHRvIHRoZSBsYXJnZXN0IFNlcnZl ck5hbWVMaXN0IHRoZSBzZXJ2ZXIgDQo+PiBleHBlY3RzIHRvIHN1cHBvcnQgcm91bmRlZCB1cCB0 aGUgbmVhcmVzdCBtdWx0aXBsZSBvZiAxNi4gSWYgdGhlIA0KPj4gc2VydmVyIHN1cHBvcnRzIHdp bGRjYXJkIG5hbWVzLCBpdCBTSE9VTEQgc2V0IHRoaXMgdmFsdWUgdG8gMjYwLg0KDQpZZWFoLCBh bmQgSSBkaXNhZ3JlZSB3aXRoIHRoYXQgdG9vOi0pDQoNCj4gSSBmaWd1cmVkIHRoYXQgYXNzdW1p bmcsIGJ5IGRlZmF1bHQsIHRoYXQgdGhlIHNlcnZlciBzdXBwb3J0cyB3aWxkY2FyZCANCj4gbmFt ZXMgc2VlbWVkIHJlYXNvbmFibGUgc28gdGhlIHRleHQgbWlycm9yZWQgdGhlIG90aGVyIFNIT1VM RC4gVGhvdWdoIA0KPiBtYXliZSB0aGF0J3MgYSBiaXQgbXVjaD8gSSBkb24ndCBoYXZlIHN0cm9u ZyBmZWVsaW5ncyBoZXJlLiBXaGF0IGRvIA0KPiB5b3UgdGhpbmsgdGhlIHRleHQgc2hvdWxkIHNh eT8gUGVyaGFwcyBpdCBzaG91bGQgcGljayBhIHJhbmRvbSANCj4gbXVsdGlwbGUtb2YtMTYgbGVu Z3RoIGJldHdlZW4gNjQgYW5kIDI2MD8gT3IgbWF5YmUgd2Ugc2hvdWxkIGRlY3JlYXNlIA0KPiB0 aGUgd2lsZGNhcmQgdmFsdWUuLi4gYSAyNjAtYnl0ZSBTTkkgbmFtZSBpcyBraW5kIG9mIGV4Y2Vz c2l2ZSwgaG9uZXN0bHkuDQoNClJlZ2FyZGxlc3Mgb2YgdGhlIGFib3ZlIGRpc2FncmVlbWVudCBh Ym91dCAyNjAsIGlmIGEgY2xpZW50IGhhcyBiZWVuIHNlbmRpbmcgYSBidW5jaCBvZiBDSCdzIGlu Y2x1ZGluZyByZWFsIEVTTkkgdGhhdCBhcmUgYWJvdXQNCjQwMCBieXRlcyBiZWNhdXNlIHNvbWUg c2VydmVyJ3MgRVNOSUtleXMgc2F5cyB0byBwYWQgdG8gMTYwLCBhbmQgdGhhdCBjbGllbnQgdGhl biBzZW5kcyA2MDAgYnl0ZXMgQ0gncyB0byBldmVyeW9uZSBlbHNlLCBJIHRoaW5rIGl0J2QgYmUg Y3J5c3RhbCBjbGVhciB3aGljaCBpcyBncmVhc2UgYW5kIHdoaWNoIG5vdC4NCg0KQ2hlZXJzLA0K Uy4NCg0KPiANCj4gRGF2aWQNCj4gDQo= From nobody Wed Feb 13 17:05: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 D6896130E27 for ; Wed, 13 Feb 2019 17:05:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.499 X-Spam-Level: X-Spam-Status: No, score=-9.499 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, URIBL_BLOCKED=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 a_1P1q7r-UFL for ; Wed, 13 Feb 2019 17:05:32 -0800 (PST) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B1CD130DD8 for ; Wed, 13 Feb 2019 17:05:30 -0800 (PST) Received: by mail-qk1-x72e.google.com with SMTP id y140so2621377qkb.9 for ; Wed, 13 Feb 2019 17:05:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JbyxOCGWpUWjfFpHNxVaERE+SWQvzGgq3U1fRwWWARU=; b=ZC1JS8MjkqvLKWNXqxn4fxG+H4BQ7ebVihXl8payYGoR/y1dkAYX9gNkBY9GQr8XgF Rjg5HtH3JULkgBGkWOgbYcoWO7++cUT7Op2aEDQihISnfkiOFxXOQWA6dfgr9QEz3Xme df1p0jgY//qFS7t7dZw3uTL+KVLifq8TyvmVc= 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=JbyxOCGWpUWjfFpHNxVaERE+SWQvzGgq3U1fRwWWARU=; b=s5vEc0ihXmd44pidwm+04DZJoGHsWekGOxvItThCGi4Hc/sj3+Q6wcV72V3gn3jZM/ 4vgf3hZBufhX+FJYjuVrHXM5tvKYHQ347ALMLdBlPOiNUmpbwdc95j1zjjtBDB2T660A 6vxzXzThx1uR950muR+pn4mzymIocs7OKz8Z+pKSiqiItFpgQdjvH/No/Dcxko5OV4um M6Qri7jasIXyFQ/ieS1swzMFvYFQ5flijQV8F2I+ryeLsT6X6FpTK6Gf/7rAAU11+1z0 di3fUgRjzGZ2+ZOPqIUGozi4TyN/XDff6HRjmrVHBry8HNak2kqYNswgOPbYJgC6dQEq UCUA== X-Gm-Message-State: AHQUAuY4vaOS2ieXgv+ogrADshayqwxIOvVkCDR3Ba5opmY2hy7TvTaQ kpNcq/76o83ho+B5Lq+BH8zicNiGPwcvbEujQI4c4Zrx8A== X-Google-Smtp-Source: AHgI3IZjTxwxAkXGQkZoK6oLTd0d39Ve5EA9UZ6Nq5ExRlIA7bBtbfFFja6+0IIujciw15jjETaiubKl1L7ofXI6g+c= X-Received: by 2002:a37:4d47:: with SMTP id a68mr757393qkb.349.1550106329320; Wed, 13 Feb 2019 17:05:29 -0800 (PST) MIME-Version: 1.0 References: <714E43FA-3660-485A-8E50-04EE43F8DA2E@gmail.com> In-Reply-To: From: David Benjamin Date: Wed, 13 Feb 2019 19:05:16 -0600 Message-ID: To: Mike Bishop Cc: Stephen Farrell , TLS WG Content-Type: multipart/alternative; boundary="000000000000201a720581d041f6" Archived-At: Subject: Re: [TLS] ESNI PRs #124 and #125: Improving ESNI Robustness and GREASE 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, 14 Feb 2019 01:05:38 -0000 --000000000000201a720581d041f6 Content-Type: text/plain; charset="UTF-8" To be clear, the intent of the PR is definitely not to extrapolate any signals about the current network. That way lies attacks. It's only ever that one origin. If it turns out that all origins securely disable ESNI, then that's what happens, but they each have to do so individually. (A bit late here, so I'll go through the rest of Stephen's response tomorrow. Wanted to clarify this detail quickly.) On Wed, Feb 13, 2019 at 6:59 PM Mike Bishop wrote: > Perhaps a better way to phrase it is that a server which successfully > authenticates as the public_name but does not support ESNI has securely > disabled ESNI for that origin, subject to the same rules as if it had > supplied a new ESNI key (i.e. use for now, but don't persist). Leave as an > implementation detail heuristics to extrapolate that the current network > will securely disable ESNI for all origins. > > -----Original Message----- > From: TLS On Behalf Of Stephen Farrell > Sent: Wednesday, February 13, 2019 4:24 PM > To: David Benjamin > Cc: TLS WG > Subject: Re: [TLS] ESNI PRs #124 and #125: Improving ESNI Robustness and > GREASE > > > Hiya, > > Various bits'n'pieces below... > > On 13/02/2019 23:55, David Benjamin wrote: > > Thanks for the comments! Responses inline. > > > > On Wed, Feb 13, 2019 at 5:00 PM Stephen Farrell > > > > wrote: > > > >> > >> Hiya, > >> > >> On 13/02/2019 22:15, Christopher Wood wrote: > >>> > >>> > >>> [1] https://github.com/tlswg/draft-ietf-tls-esni/pull/124 > >> > >> I just re-read that. I've a question: why tie the version change to > >> this PR and not the I-D rev? I'd prefer if we make the change to > >> 0xff02 when -03 is published. (I don't care which PR does that, but > >> wouldn't like to see every PR bump that number.) > >> > > > > I bumped it because the PR was making a wire-incompatible change, but > > batching them up to I-D revs makes sense too. No preferences here. > > (Spec editors, do you care? I can remove that part of the change.) > > > > > >> Aside from that I think it's ok (though I may find other issues when > >> implementing later) with two caveats that can be handled now or > >> later: > >> > >> 1. The DNS RR structure still needs fixing but that is likely better > >> handled separately. (By "fixing" I mean a new RR type but also that > >> it needs to be designed for DNS admins as well and not only for TLS > >> implementers which is the current case. > >> (I'm not saying what might or might not make it more dnsops friendly, > >> just that that needs to be checked/done sometime.) > >> > > > > I'm guessing this is to do with the various discussions around > > multi-CDN and whatnot? That seems orthogonal to that PR. (I don't > > personally have particularly strong opinions or experience there.) > > Not just that. ESNIKeys is a fairly complex structure that has a number > sets/sequences of values. There are various possible deployment models. The > current structure assumes that it's ok to encode all that stuff up in one > TLS style blob and then put that in the DNS. That might not make sense for > some deployments in particular where the DNS operator is not closely tied > to the TLS server admin or where there's > 1 DNS operator and N TLS server admins (for the same origin). > And then there's the use of the TXT RR. But I agree this is orthogonal - I > was mostly saying that in agreeing with this PR I continue to think the DNS > RR stuff needs other work. > > > > > > >> 2. I don't think the text below ought be included, it's not the job > >> of this WG to design MITM attacks. (Or maybe I've misinterpreted it?) > >> > >> "The public name, however, makes this protocol compatible with > >> deployments that use correctly-implemented MITM proxies. If the > >> client has cached an ESNIKey for the origin server, the MITM proxy > >> will process the cleartext SNI field and terminate a connection to > >> the public name instead. If the client is configured to trust the > >> proxy's certificate, it will accept the connection as valid for the > >> public name and retry with ESNI disabled." > >> > > > > That text isn't prescribing any particular behavior. > > Then delete it:-) > > > It's just describing > > the effect the rest of the text has on "trusted MITM proxies" and the > like. > > Disagree. "Just describing" does not match the use of a meaningless > marketing term like "trusted blah proxy" sorry. Better to avoid all that > fuss really, no? > > > Note this is specifically about "MITM proxies" which control a root > > certificate that the client is configured to trust. I will refrain > > from commenting on whether this deployment model is at all wise, but > > it does exist (antivirus, etc). The text itself is just an updated > > version of existing bits here: > > https://tools.ietf.org/html/draft-ietf-tls-esni-02#section-6.2 > > I don't recall that having a concept of it being possible to "correctly" > implement breaking the TLS protocol? (As is inherent in being an MITM.) > > > > > As for where this effect comes from, it's a consequence of the > > rollback and partial deployment robustness mechanism in the PR: > > > >> If the server negotiates an earlier version of TLS, or if it does not > >> provide an "encrypted_server_name" extension in EncryptedExtensions, > >> the client proceeds with the handshake, verifying the certificate > >> against ESNIKeys.public_name as described in {{verify-public-name}}. > >> The client > > MUST > >> NOT enable the False Start optimization {{RFC7918}}. If the handshake > > completes > >> successfully, the client MUST abort the connection with an > > "esni_required" alert. > >> It then SHOULD retry the handshake with a new transport connection > >> and > > ESNI > >> disabled." > > > > Or, in other words, IF the server is able to speak authoritatively for > > the public name (relatively to the client's trust anchors) but appears > > to not understand ESNI at all, that is a signal to the client that > > ESNI got turned off or hasn't fully been turned on yet. ESNI involves > > client state and, without this, it's risky for a server operator to > > deploy ESNI. Deployments are complex systems, and complex systems > > react to change unpredictably. For most changes, if some show-stopping > > problem is found, it is safe to rollback the change. For instance, > > clients naturally tolerate servers turning TLS 1.3 on and off, a fact > > I'm sure every early adopter of TLS 1.3 has used many times. ESNI, a > > priori, breaks this property. The intent of this text is to restore > > it, without totally breaking it (the stop signal is authenticated > > under the public name, the same standard this PR sets for replacing the > key). > > It may be ok to live with such fallback whilst ESNI is being introduced > but I think ongoing support for it would be unwise. > And such a fallback requires no discussion of MITM attacks. > (Other than as an attack.) > > > > > It turns out that a user moving in and out of one of these "trusted > MITMs" > > I object to that term again, sorry:-) It's marketing meaninglessness. > > > looks the same as a rollback, so we get robustness to that scenario too. > > The current draft attempted to handle this case too, but did so with > > extra machinery. From the link above: > > > >> A Web client client can securely detect case (2) because it will > >> result in a connection which has an invalid identity (most likely) > >> but which is signed by a certificate which does not chain to a > >> publicly known trust anchor. The client can detect this case and > >> disable ESNI while in that network configuration > > > > Here, there is no name check, so any publicly known root that the > > client trusts can be used to trigger that fallback, even if it's just, > > say, an intranet server and not a MITM proxy. The PR fixes this by > > checking the public name. It only counts as a signal if the server can > > speak for the service's public name, not any arbitrary name. > > > > I also don't think I'd implement that fallback in my openssl > >> fork. Earlier text says to complete the h/s but to not make that > >> visible to the application layer and the above seems to conflict with > >> that. I could hold my nose were that in -03 as it has no effect > >> really, but I'll whine about it later for sure;-) > >> > > > > I'm guessing you're referring to this? > > > >> Note that verifying a connection for the public name does not verify > >> it > > for the > >> origin. The TLS implementation MUST NOT surface such connections as > > successful to > >> the application. > > > > That just says you can't report it as successful. > > "MUST NOT surface" seems like bad phrasing then. > > > Whether you report it to > > the application at all depends on your API shape. For a low-level TLS > > library that doesn't create transport connections, I'm envisioning it > > report failure with a special error code, which higher-level logic can > > interpret as a retry. > > That would be ok. Saying that requires no discussion of MITM attacks. > (My openssl code would actually make that visible to the application if > the application called a status API, but the TLS h/s would have failed from > the application POV even if the h/s looks like it worked on the wire.) > > > (This is how we handle 0-RTT rejects in BoringSSL. > > 0-RTT rejects affect connection usage, such as if you thought you were > > speaking HTTP/2, but the server rejected and then negotiated HTTP/1.1. > > It's ultimately a very funny retry.) For higher-level code that knows > > how to make transport connections, one option then is for the retry to > > be handled more transparently. > > > > > >>> [2] https://github.com/tlswg/draft-ietf-tls-esni/pull/125 > >> > >> I like this one. But the "SHOULD send" and "MUST pad to 260" > >> seem a bit OTT to me, though I could live with 'em for now. > >> So consider these nits, not objections: > >> > > > > (260 is just a SHOULD rather than a MUST. More below.) > > > > > >> - Rather than "SHOULD send", it may be better to say something like > >> "SHOULD frequently send" and leave it to clients to decide how often > >> to grease. Wouldn't that have the same effect? > >> > > > > Is there any reason not to just do it in every ClientHello? > > I'd guess that some implementers may be put off by the wasted bandwidth. > Others won't care but if it's the case that sending a bogus ESNI x% of the > time gets as good a result as sending all the time (which is how I > interpret what the SHOULD calls for) then it seems better to encourage x% > and not 100%. > > > > > > >> - Maybe add that even TLS1.3 clients that don't really do ESNI MAY > >> grease ESNI? (A bit weird but hey why not?:-) > >> > > > > Indeed! The PR currently says: > > > >> If the client attempts to connect to a server and does not have an > > ESNIKeys > >> structure available for the server, > > "The client" in almost all IETF specs means a thing that really implements > the spec. So in this case, yeah, I think it might be good to say that a TLS > client implementer who only has time to grease and not do the real thing is > still doing good overall by just doing that. (That said, I've no idea if > there'd ever be such an implementer, though when we did DKIM there were > many mail receivers who parsed but didn't actually check signatures - maybe > mail implementers are more slapdash though:-) > > > > > Knowing what ESNI is but not really doing it I think counts as "does > > not have an ESNIKeys structure available". Do you think it should be > > called out more explicitly? > > > > > >> - Padding to 260 is IIRC the max that works. A CH with such padding > >> is ~600 bytes. Seems like a waste of bytes to me and it could stick > >> out depending on real ESNI padding_lengths. > >> Maybe consider something like "pad to a length that matches recent > >> traffic" and leave it to clients to figure out what might stick out > >> less. (I'm not sure every server will ask for padding to 260 as CF > >> do;-) > >> > > > > 260 comes from elsewhere which says: > > > >> The length to pad the ServerNameList value to prior to encryption. > >> This value SHOULD be set to the largest ServerNameList the server > >> expects to support rounded up the nearest multiple of 16. If the > >> server supports wildcard names, it SHOULD set this value to 260. > > Yeah, and I disagree with that too:-) > > > I figured that assuming, by default, that the server supports wildcard > > names seemed reasonable so the text mirrored the other SHOULD. Though > > maybe that's a bit much? I don't have strong feelings here. What do > > you think the text should say? Perhaps it should pick a random > > multiple-of-16 length between 64 and 260? Or maybe we should decrease > > the wildcard value... a 260-byte SNI name is kind of excessive, honestly. > > Regardless of the above disagreement about 260, if a client has been > sending a bunch of CH's including real ESNI that are about > 400 bytes because some server's ESNIKeys says to pad to 160, and that > client then sends 600 bytes CH's to everyone else, I think it'd be crystal > clear which is grease and which not. > > Cheers, > S. > > > > > David > > > --000000000000201a720581d041f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To be clear, the intent of the PR is definitely not to ext= rapolate any signals about the current network. That way lies attacks. It&#= 39;s only ever that one origin. If it turns out that all origins securely d= isable ESNI, then that's what happens, but they each have to do so indi= vidually.

(A bit late here, so I'll go through= the rest of Stephen's response tomorrow. Wanted to clarify this detail= quickly.)

On Wed, Feb 13, 2019 at 6:59 PM= Mike Bishop <= mbishop@evequefou.be> wrote:
Perhaps a better way to phrase it is that a server which successfully auth= enticates as the public_name but does not support ESNI has securely disable= d ESNI for that origin, subject to the same rules as if it had supplied a n= ew ESNI key (i.e. use for now, but don't persist).=C2=A0 Leave as an im= plementation detail heuristics to extrapolate that the current network will= securely disable ESNI for all origins.

-----Original Message-----
From: TLS <tls= -bounces@ietf.org> On Behalf Of Stephen Farrell
Sent: Wednesday, February 13, 2019 4:24 PM
To: David Benjamin <davidben@chromium.org>
Cc: TLS WG <tls@ietf.o= rg>
Subject: Re: [TLS] ESNI PRs #124 and #125: Improving ESNI Robustness and GR= EASE


Hiya,

Various bits'n'pieces below...

On 13/02/2019 23:55, David Benjamin wrote:
> Thanks for the comments! Responses inline.
>
> On Wed, Feb 13, 2019 at 5:00 PM Stephen Farrell
> <ste= phen.farrell@cs.tcd.ie>
> wrote:
>
>>
>> Hiya,
>>
>> On 13/02/2019 22:15, Christopher Wood wrote:
>>>
>>>
>>> [1] https://github.com/tlswg/draft= -ietf-tls-esni/pull/124
>>
>> I just re-read that. I've a question: why tie the version chan= ge to
>> this PR and not the I-D rev? I'd prefer if we make the change = to
>> 0xff02 when -03 is published. (I don't care which PR does that= , but
>> wouldn't like to see every PR bump that number.)
>>
>
> I bumped it because the PR was making a wire-incompatible change, but =
> batching them up to I-D revs makes sense too. No preferences here. > (Spec editors, do you care? I can remove that part of the change.)
>
>
>> Aside from that I think it's ok (though I may find other issue= s when
>> implementing later) with two caveats that can be handled now or >> later:
>>
>> 1. The DNS RR structure still needs fixing but that is likely bett= er
>> handled separately. (By "fixing" I mean a new RR type bu= t also that
>> it needs to be designed for DNS admins as well and not only for TL= S
>> implementers which is the current case.
>> (I'm not saying what might or might not make it more dnsops fr= iendly,
>> just that that needs to be checked/done sometime.)
>>
>
> I'm guessing this is to do with the various discussions around > multi-CDN and whatnot? That seems orthogonal to that PR. (I don't =
> personally have particularly strong opinions or experience there.)

Not just that. ESNIKeys is a fairly complex structure that has a number set= s/sequences of values. There are various possible deployment models. The cu= rrent structure assumes that it's ok to encode all that stuff up in one= TLS style blob and then put that in the DNS. That might not make sense for= some deployments in particular where the DNS operator is not closely tied = to the TLS server admin or where there's
1 DNS operator and N TLS server admins (for the same origin).
And then there's the use of the TXT RR. But I agree this is orthogonal = - I was mostly saying that in agreeing with this PR I continue to think the= DNS RR stuff needs other work.

>
>
>> 2. I don't think the text below ought be included, it's no= t the job
>> of this WG to design MITM attacks. (Or maybe I've misinterpret= ed it?)
>>
>> "The public name, however, makes this protocol compatible wit= h
>> deployments that use correctly-implemented MITM proxies. If the >> client has cached an ESNIKey for the origin server, the MITM proxy=
>> will process the cleartext SNI field and terminate a connection to=
>> the public name instead. If the client is configured to trust the =
>> proxy's certificate, it will accept the connection as valid fo= r the
>> public name and retry with ESNI disabled."
>>
>
> That text isn't prescribing any particular behavior.

Then delete it:-)

> It's just describing
> the effect the rest of the text has on "trusted MITM proxies"= ; and the like.

Disagree. "Just describing" does not match the use of a meaningle= ss marketing term like "trusted blah proxy" sorry. Better to avoi= d all that fuss really, no?

> Note this is specifically about "MITM proxies" which control= a root
> certificate that the client is configured to trust. I will refrain > from commenting on whether this deployment model is at all wise, but <= br> > it does exist (antivirus, etc). The text itself is just an updated > version of existing bits here:
> https://tools.ietf.org/html/draft= -ietf-tls-esni-02#section-6.2

I don't recall that having a concept of it being possible to "corr= ectly" implement breaking the TLS protocol? (As is inherent in being a= n MITM.)

>
> As for where this effect comes from, it's a consequence of the > rollback and partial deployment robustness mechanism in the PR:
>
>> If the server negotiates an earlier version of TLS, or if it does = not
>> provide an "encrypted_server_name" extension in Encrypte= dExtensions,
>> the client proceeds with the handshake, verifying the certificate =
>> against ESNIKeys.public_name as described in {{verify-public-name}= }.
>> The client
> MUST
>> NOT enable the False Start optimization {{RFC7918}}. If the handsh= ake
> completes
>> successfully, the client MUST abort the connection with an
> "esni_required" alert.
>> It then SHOULD retry the handshake with a new transport connection=
>> and
> ESNI
>> disabled."
>
> Or, in other words, IF the server is able to speak authoritatively for=
> the public name (relatively to the client's trust anchors) but app= ears
> to not understand ESNI at all, that is a signal to the client that > ESNI got turned off or hasn't fully been turned on yet. ESNI invol= ves
> client state and, without this, it's risky for a server operator t= o
> deploy ESNI. Deployments are complex systems, and complex systems
> react to change unpredictably. For most changes, if some show-stopping=
> problem is found, it is safe to rollback the change. For instance, > clients naturally tolerate servers turning TLS 1.3 on and off, a fact =
> I'm sure every early adopter of TLS 1.3 has used many times. ESNI,= a
> priori, breaks this property. The intent of this text is to restore > it, without totally breaking it (the stop signal is authenticated
> under the public name, the same standard this PR sets for replacing th= e key).

It may be ok to live with such fallback whilst ESNI is being introduced but= I think ongoing support for it would be unwise.
And such a fallback requires no discussion of MITM attacks.
(Other than as an attack.)

>
> It turns out that a user moving in and out of one of these "trust= ed MITMs"

I object to that term again, sorry:-) It's marketing meaninglessness.
> looks the same as a rollback, so we get robustness to that scenario to= o.
> The current draft attempted to handle this case too, but did so with <= br> > extra machinery. From the link above:
>
>>=C2=A0 =C2=A0A Web client client can securely detect case (2) becau= se it will
>>=C2=A0 =C2=A0result in a connection which has an invalid identity (= most likely)
>>=C2=A0 =C2=A0but which is signed by a certificate which does not ch= ain to a
>>=C2=A0 =C2=A0publicly known trust anchor.=C2=A0 The client can dete= ct this case and
>>=C2=A0 =C2=A0disable ESNI while in that network configuration
>
> Here, there is no name check, so any publicly known root that the
> client trusts can be used to trigger that fallback, even if it's j= ust,
> say, an intranet server and not a MITM proxy. The PR fixes this by > checking the public name. It only counts as a signal if the server can=
> speak for the service's public name, not any arbitrary name.
>
> I also don't think I'd implement that fallback in my openssl >> fork. Earlier text says to complete the h/s but to not make that <= br> >> visible to the application layer and the above seems to conflict w= ith
>> that. I could hold my nose were that in -03 as it has no effect >> really, but I'll whine about it later for sure;-)
>>
>
> I'm guessing you're referring to this?
>
>> Note that verifying a connection for the public name does not veri= fy
>> it
> for the
>> origin. The TLS implementation MUST NOT surface such connections a= s
> successful to
>> the application.
>
> That just says you can't report it as successful.

"MUST NOT surface" seems like bad phrasing then.

> Whether you report it to
> the application at all depends on your API shape. For a low-level TLS =
> library that doesn't create transport connections, I'm envisio= ning it
> report failure with a special error code, which higher-level logic can=
> interpret as a retry.

That would be ok. Saying that requires no discussion of MITM attacks.
(My openssl code would actually make that visible to the application if the= application called a status API, but the TLS h/s would have failed from th= e application POV even if the h/s looks like it worked on the wire.)

> (This is how we handle 0-RTT rejects in BoringSSL.
> 0-RTT rejects affect connection usage, such as if you thought you were=
> speaking HTTP/2, but the server rejected and then negotiated HTTP/1.1.=
> It's ultimately a very funny retry.) For higher-level code that kn= ows
> how to make transport connections, one option then is for the retry to=
> be handled more transparently.
>
>
>>> [2] https://github.com/tlswg/draft= -ietf-tls-esni/pull/125
>>
>> I like this one. But the "SHOULD send" and "MUST pa= d to 260"
>> seem a bit OTT to me, though I could live with 'em for now. >> So consider these nits, not objections:
>>
>
> (260 is just a SHOULD rather than a MUST. More below.)
>
>
>> - Rather than "SHOULD send", it may be better to say som= ething like
>> "SHOULD frequently send" and leave it to clients to deci= de how often
>> to grease. Wouldn't that have the same effect?
>>
>
> Is there any reason not to just do it in every ClientHello?

I'd guess that some implementers may be put off by the wasted bandwidth= . Others won't care but if it's the case that sending a bogus ESNI = x% of the time gets as good a result as sending all the time (which is how = I interpret what the SHOULD calls for) then it seems better to encourage x%= and not 100%.

>
>
>> - Maybe add that even TLS1.3 clients that don't really do ESNI= MAY
>> grease ESNI? (A bit weird but hey why not?:-)
>>
>
> Indeed! The PR currently says:
>
>> If the client attempts to connect to a server and does not have an=
> ESNIKeys
>> structure available for the server,

"The client" in almost all IETF specs means a thing that really i= mplements the spec. So in this case, yeah, I think it might be good to say = that a TLS client implementer who only has time to grease and not do the re= al thing is still doing good overall by just doing that. (That said, I'= ve no idea if there'd ever be such an implementer, though when we did D= KIM there were many mail receivers who parsed but didn't actually check= signatures - maybe mail implementers are more slapdash though:-)

>
> Knowing what ESNI is but not really doing it I think counts as "d= oes
> not have an ESNIKeys structure available". Do you think it should= be
> called out more explicitly?
>
>
>> - Padding to 260 is IIRC the max that works. A CH with such paddin= g
>> is ~600 bytes. Seems like a waste of bytes to me and it could stic= k
>> out depending on real ESNI padding_lengths.
>> Maybe consider something like "pad to a length that matches r= ecent
>> traffic" and leave it to clients to figure out what might sti= ck out
>> less. (I'm not sure every server will ask for padding to 260 a= s CF
>> do;-)
>>
>
> 260 comes from elsewhere which says:
>
>> The length to pad the ServerNameList value to prior to encryption.=
>> This value SHOULD be set to the largest ServerNameList the server =
>> expects to support rounded up the nearest multiple of 16. If the <= br> >> server supports wildcard names, it SHOULD set this value to 260.
Yeah, and I disagree with that too:-)

> I figured that assuming, by default, that the server supports wildcard=
> names seemed reasonable so the text mirrored the other SHOULD. Though =
> maybe that's a bit much? I don't have strong feelings here. Wh= at do
> you think the text should say? Perhaps it should pick a random
> multiple-of-16 length between 64 and 260? Or maybe we should decrease =
> the wildcard value... a 260-byte SNI name is kind of excessive, honest= ly.

Regardless of the above disagreement about 260, if a client has been sendin= g a bunch of CH's including real ESNI that are about
400 bytes because some server's ESNIKeys says to pad to 160, and that c= lient then sends 600 bytes CH's to everyone else, I think it'd be c= rystal clear which is grease and which not.

Cheers,
S.

>
> David
>
--000000000000201a720581d041f6-- From nobody Wed Feb 13 17:37:03 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA82A130E92 for ; Wed, 13 Feb 2019 17:37:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=nerd.ninja Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OyRPZh-Sf-_C for ; Wed, 13 Feb 2019 17:36:59 -0800 (PST) Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D09D7130E91 for ; Wed, 13 Feb 2019 17:36:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550108210; cv=none; d=zoho.com; s=zohoarc; b=M+ttDNKR/9DMXEZtM35ErB3HoOryaGZaTiNR7hnqQhOb1kOcljenQewg0+66NwKQbRw2wTXeRia2SdEE09GwdafRSCv89xJxbMjcjXeYBbK+w5gQPVvw4pcVOwEzM7PXBTMF6K+HVyeUc0YI8fmkzErf8qPKEe8ODdV9wOrn2do= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1550108210; h=Content-Type:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results; bh=EFR29uYb9i00xt37I/0kq3TCTBBBBNRPW/Tv1ksnoi0=; b=IKZG5yGOfZSVHN3We1N0WhOz9MKZlPxdyYwDqUm1dV/WTv905OmoKgFwK5ZRpz8Lf51WPXwZpMy1arY5XNKsUPX9LP2DOQeaC2TkpqgGS5/1CvUxz3jFXKOM0DywT8t35hMNsImjxRAFzQSFG2PM92cA4ZFQHqB/7SMzXWXPpPs= ARC-Authentication-Results: i=1; mx.zoho.com; dkim=pass header.i=nerd.ninja; spf=pass smtp.mailfrom=r@nerd.ninja; dmarc=pass header.from= header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1550108210; s=zoho; d=nerd.ninja; i=r@nerd.ninja; h=Date:From:To:Message-Id:In-Reply-To:References:Subject:MIME-Version:Content-Type; l=5070; bh=EFR29uYb9i00xt37I/0kq3TCTBBBBNRPW/Tv1ksnoi0=; b=qsa0C8FFtHwkm+sWaGbjYTl7/FjVyvr6o/kh8pp6O1K8ojznfCyS73WqXcbnoEHP OtnG+11gr/Prg+HT3qdt8PJuDkOWs82bLoTRIp+WGif9iSvBJS/fCcVyNezGV7r8G/1 cvKe76Lyy6YkHQ6LYuynkRDMYJxnJ7lPH2kl/uNQ= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1550108204321126.51661078843495; Wed, 13 Feb 2019 17:36:44 -0800 (PST) Date: Wed, 13 Feb 2019 20:36:44 -0500 From: Roelof DuToit To: "Christopher Wood" , "TLS WG" Message-Id: <168e9a61d1e.cce5c9ea206228.28832954982140191@nerd.ninja> In-Reply-To: <714E43FA-3660-485A-8E50-04EE43F8DA2E@gmail.com> References: <714E43FA-3660-485A-8E50-04EE43F8DA2E@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_670212_550301185.1550108204318" X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail Archived-At: Subject: Re: [TLS] ESNI PRs #124 and #125: Improving ESNI Robustness and GREASE 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, 14 Feb 2019 01:37:01 -0000 ------=_Part_670212_550301185.1550108204318 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Questions for PR [1]: * Regarding this text: The client MUST NOT use the server-provided retry keys until the handshake = completes successfully. On success, it MUST NOT overwrite the DNS-provided = keys with the retry keys. It MUST use the retry keys at most once and conti= nue offering DNS-provided keys for subsequent connections. This avoids intr= oducing a tracking vector, should a malicious server present client-specifi= c retry keys. .. specifically this part: ".. use the retry keys at most once".=C2=A0=20 Q1: Are you saying the client should persistently remember which public_nam= e values triggered retry keys?=C2=A0 For how long? Q2: What happens if fronting server A sent retry keys, and the subsequent t= ransport connection ends up on server B, which also sends retry keys? --Roelof ---- On Wed, 13 Feb 2019 17:15:57 -0500=C2=A0Christopher Wood wrote ---- Hi folks, PRs [1] and [2] need a little more review before we merge since=20 they=E2=80=99re non-trivial changes. Please have a look and let the list kn= ow=20 if you have objections with the contents therein. Otherwise, we will=20 merge them by the end of the next week. Thanks! Chris (no hat) [1] https://github.com/tlswg/draft-ietf-tls-esni/pull/124 [2] https://github.com/tlswg/draft-ietf-tls-esni/pull/125 _______________________________________________ TLS mailing list mailto:TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls ------=_Part_670212_550301185.1550108204318 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Questions for PR [1]:

* Regarding this text:
The client MUST= NOT use the server-provided retry keys until the handshake completes succe= ssfully. On success, it MUST NOT overwrite the DNS-provided keys with the r= etry keys. It MUST use the retry keys at most once and continue offering DN= S-provided keys for subsequent connections. This avoids introducing a track= ing vector, should a malicious server present client-specific retry keys.

.. specifically thi= s part: ".. use the retry keys at most once". 
Q1: Are = you saying the client should persistently remember which public_name values= triggered retry keys?  For how long?
Q2: What happens i= f fronting server A sent retry keys, and the subsequent transport connectio= n ends up on server B, which also sends retry keys?


--Roelof


---- On Wed, 13 Feb 2019 17:= 15:57 -0500 Christopher Wood <christopherwood07@gmail.com> wrote ----

Hi folk= s,

PRs [1] and [2] need a little more review b= efore we merge since
they=E2=80=99re non-trivial changes. Pl= ease have a look and let the list know
if you have objection= s with the contents therein. Otherwise, we will
merge them b= y the end of the next week.

Thanks!
<= div>Chris (no hat)


_______________________________________________
TLS m= ailing list


------=_Part_670212_550301185.1550108204318-- From nobody Thu Feb 14 10:00:35 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41AAE13117F for ; Thu, 14 Feb 2019 10:00:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.499 X-Spam-Level: X-Spam-Status: No, score=-9.499 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, URIBL_BLOCKED=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 UILTvkG6gs7G for ; Thu, 14 Feb 2019 10:00:30 -0800 (PST) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58CD8131170 for ; Thu, 14 Feb 2019 10:00:30 -0800 (PST) Received: by mail-qt1-x82f.google.com with SMTP id y4so7852335qtc.10 for ; Thu, 14 Feb 2019 10:00:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=96zKrUJKpX641Qbp5cXff+RLCMOkkF26dp4o/nm8emk=; b=DPrmdJKik+ZmlPy2KUdfFaYXhHtjQyHDHBODuUU4zLxZgJVJHkrvNe85g4vil37m8p MQKe03kWM8NEquSleHSKkTRoYETo3RnxOHb0B75vRCPWnytPLa/85z3Wv/CDquIT3mFe betFdhOno/Rc/VlyVh86vmNcGnvWwXt36Nhyk= 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=96zKrUJKpX641Qbp5cXff+RLCMOkkF26dp4o/nm8emk=; b=tAu78f5s1PoNEBej+RIiFeLPKLWK4iwU5kUPBjPwVuA2AQLI8HOPNSoZPudf1rmPBU 4LMPgULa0DgK9HCEz48BM6DLYX4ORQyCW94RtCamaW2nEybhhbuwzFqX5pIJtflg7P9w HCrLDFGeaGRPrCZINRKDIQFxrryQ95UB+zZyPphy3XOvjeGFPR7AcFx29pPvXXiSo/AD J2VqsU8qfAayWusYK6dSsWYpmmaRLGJmlg+cnX96xIRyWUcH4by3Y2coAvnhr+EafyCf oeFg0KtWSdPu1jpRDgrehgBZ98ai3PaF5HRNSjIe5APVq3VEpxJFjNb8WOdsUi7asf7A CJpA== X-Gm-Message-State: AHQUAuaBcJ5+9iX9A2HCUyJC5ob4wgED5c83dedGCi57svwu/Xor3fbG twPpwv5pewFI0b/So66RDjRtC/pLBkxq0kDMGjwQ X-Google-Smtp-Source: AHgI3IYu7zatOKGqdRQIMYCxOOQNzOTAjvH2lyjWwr50QY09ImruC1VlWhwaElimwqvrL72G5i5tWlxIV4xJm39YQdk= X-Received: by 2002:ac8:33f1:: with SMTP id d46mr4076382qtb.319.1550167229049; Thu, 14 Feb 2019 10:00:29 -0800 (PST) MIME-Version: 1.0 References: <714E43FA-3660-485A-8E50-04EE43F8DA2E@gmail.com> <168e9a61d1e.cce5c9ea206228.28832954982140191@nerd.ninja> In-Reply-To: <168e9a61d1e.cce5c9ea206228.28832954982140191@nerd.ninja> From: David Benjamin Date: Thu, 14 Feb 2019 12:00:16 -0600 Message-ID: To: Roelof DuToit Cc: Christopher Wood , TLS WG Content-Type: multipart/alternative; boundary="0000000000000811d30581de6fe6" Archived-At: Subject: Re: [TLS] ESNI PRs #124 and #125: Improving ESNI Robustness and GREASE 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, 14 Feb 2019 18:00:33 -0000 --0000000000000811d30581de6fe6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 13, 2019 at 7:37 PM Roelof DuToit wrote: > Questions for PR [1]: > > * Regarding this text: > The client MUST NOT use the server-provided retry keys until the handshak= e > completes successfully. On success, it MUST NOT overwrite the DNS-provide= d > keys with the retry keys. It MUST use the retry keys at most once and > continue offering DNS-provided keys for subsequent connections. This avoi= ds > introducing a tracking vector, should a malicious server present > client-specific retry keys. > > .. specifically this part: ".. use the retry keys at most once". > Q1: Are you saying the client should persistently remember which > public_name values triggered retry keys? For how long? > No, exactly the opposite. You use the retry key for just the retry and then forget about it. https://mailarchive.ietf.org/arch/msg/tls/xBEHe1_CcYEYinZQHxWGq8vjA0Q Q2: What happens if fronting server A sent retry keys, and the subsequent > transport connection ends up on server B, which also sends retry keys? > You keep retrying. And hen you hit the text which says: > Clients SHOULD implement a limit on retries caused by "esni_retry_request" or > servers which do not acknowledge the "encrypted_server_name" extension. This is an error-correcting mechanism to avoid deployment risks. If your TLS deployment is so out of sync with itself that: - It deployed ESNI keys in the DNS that your servers do not understand. - Even on a retry to presumably the same IP address, you hit a different server node. - Your load balancer keeps bouncing between different server nodes connections right after each other. - Each of your server nodes believes in a totally disjoint set of ESNI keys= . Then I think giving up and failing the connection is not the end of the world. > > --Roelof > > > ---- On Wed, 13 Feb 2019 17:15:57 -0500 *Christopher Wood > >* wrote ---- > > Hi folks, > > PRs [1] and [2] need a little more review before we merge since > they=E2=80=99re non-trivial changes. Please have a look and let the list = know > if you have objections with the contents therein. Otherwise, we will > merge them by the end of the next week. > > Thanks! > Chris (no hat) > > [1] https://github..com/tlswg/draft-ietf-tls-esni/pull/124 > > > [2] https://github.com/tlswg/draft-ietf-tls-esni/pull/125 > > _______________________________________________ > 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 > --0000000000000811d30581de6fe6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Feb 13, 2019 at 7:37 PM Roelof DuToit <r@nerd.ninja> w= rote:
Questions for PR [1]:

* Regarding this text= :
The client MUST NOT use the server-provided ret= ry keys until the handshake completes successfully. On success, it MUST NOT= overwrite the DNS-provided keys with the retry keys. It MUST use the retry= keys at most once and continue offering DNS-provided keys for subsequent c= onnections. This avoids introducing a tracking vector, should a malicious s= erver present client-specific retry keys.

.. specifically this part: ".. use the retry k= eys at most once".=C2=A0
Q1: Are you saying the client = should persistently remember which public_name values triggered retry keys?= =C2=A0 For how long?

= No, exactly the opposite. You use the retry key for just the retry and then= forget about it.

Q2: What happens if fronting = server A sent retry keys, and the subsequent transport connection ends up o= n server B, which also sends retry keys?

You keep retrying. And hen you hit the text which says:

> Clients SHOULD implement a limit on retries= caused by "esni_retry_request" or
> servers which d= o not acknowledge the "encrypted_server_name" extension.

This is an error-correcting mechanism to avoid deplo= yment risks. If your TLS deployment is so out of sync with itself that:

- It deployed ESNI keys in the DNS that your servers = do not understand.
- Even on a retry to presumably the same IP ad= dress, you hit a different server node.
- Your load balancer keep= s bouncing between different server nodes connections right after each othe= r.
- Each of your server nodes believes in a totally disjoint set= of ESNI keys.

Then I think giving up and failing = the connection is not the end of the world.

=C2=A0=

--Roelof


---- = On Wed, 13 Feb 2019 17:15:57 -0500=C2=A0Christopher Wood <christopherwood07@gma= il.com> wrote ----

Hi folks,

PRs [1] and [2] need a little more review before we merge s= ince
they=E2=80=99re non-trivial changes. Please have a look= and let the list know
if you have objections with the conte= nts therein. Otherwise, we will
merge them by the end of the= next week.

Thanks!
Chris (no ha= t)

__________________________= _____________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000000811d30581de6fe6-- From nobody Thu Feb 14 11:21: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 DAEB91288BD for ; Thu, 14 Feb 2019 11:21:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.499 X-Spam-Level: X-Spam-Status: No, score=-9.499 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, URIBL_BLOCKED=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 NNltrRzVTEWG for ; Thu, 14 Feb 2019 11:21:19 -0800 (PST) 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 7320712426A for ; Thu, 14 Feb 2019 11:21:19 -0800 (PST) Received: by mail-qk1-x72f.google.com with SMTP id a15so4314450qkc.1 for ; Thu, 14 Feb 2019 11:21:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=peP7Y9DDO5awLNmkOkJ1+Zk2M9Xsm8Wjr8rPtzqhLzM=; b=DaS8ScPYIQ7LcjHSH0GCW/+FKinhhjq56Tf6B4ehMAaP/b5lAPAtDriGzFpbQEDbHp +Frz7Yj5Bs1i1ytGTw6K1tT5RHwzTZUSKOEgnZ45a6MCSrw9kAfEldEXXLr8Z1GDV3dG RE1d8OARVtSnJtrIzqn7ZH96lr7XrOyuL8ua0= 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=peP7Y9DDO5awLNmkOkJ1+Zk2M9Xsm8Wjr8rPtzqhLzM=; b=CDBK5oc/FyJl/sv4e97yFDoXHvG6eiWtkf83s6CI7JL8m6/Nei0Xb/4CzY4MjrLLcf Xz3tvUtvj9RQf/3f9dOGdABDC30lq6BjqC58XGRGvs5zGuWjozqcqlJVYVEaAZXZGhf6 yZPHXDSU8QHyy6J+SJoJm1sEOgks4uGCfbuYxzDLiVnAp+iW6S/AqqXxYnyC/vKY0zCD YRIfyognPB4ZOYxdtUNOnYavv+FUU1BrcjwizxkuPbSBqN8u6QwVcz9Gz//i8MqSLfrF DFmdgqqPEHXK1goTprITg2BSgmTZqBCUYgM8ccNnnJ/iaRnUzu+ESHtlBycgNlnzr8GO 2njQ== X-Gm-Message-State: AHQUAuaJYOZlib621YOz4DlfhEdGqTYJvUUC42bxELu3Ng2IGNOp8Q+v SgpMMgZfptlOw5P+KOtHAJSV30p4TIc6l0ZCFb+FJhou+A== X-Google-Smtp-Source: AHgI3IZHMMzpHvUdXwBpQ6fRiqYkzkc8oCrAtu1G52RTTr5cV/JyF4AFBxXrXGaQrdFm7lGtTqm++1RINlWdIsHO1Lg= X-Received: by 2002:a05:620a:11b8:: with SMTP id c24mr4217302qkk.57.1550172078153; Thu, 14 Feb 2019 11:21:18 -0800 (PST) MIME-Version: 1.0 References: <714E43FA-3660-485A-8E50-04EE43F8DA2E@gmail.com> In-Reply-To: From: David Benjamin Date: Thu, 14 Feb 2019 13:21:05 -0600 Message-ID: To: Stephen Farrell Cc: Christopher Wood , TLS WG Content-Type: multipart/alternative; boundary="0000000000000f92560581df9042" Archived-At: Subject: Re: [TLS] ESNI PRs #124 and #125: Improving ESNI Robustness and GREASE 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, 14 Feb 2019 19:21:36 -0000 --0000000000000f92560581df9042 Content-Type: text/plain; charset="UTF-8" On Wed, Feb 13, 2019 at 6:24 PM Stephen Farrell wrote: > On 13/02/2019 23:55, David Benjamin wrote: > > On Wed, Feb 13, 2019 at 5:00 PM Stephen Farrell < > stephen.farrell@cs.tcd.ie> > > wrote: > > That text isn't prescribing any particular behavior. > > Then delete it:-) > It's just describing > > the effect the rest of the text has on "trusted MITM proxies" and the > like. > > Disagree. "Just describing" does not match the use of a meaningless > marketing term like "trusted blah proxy" sorry. Better to avoid all > that fuss really, no? > > > Note this is specifically about "MITM proxies" which control a root > > certificate that the client is configured to trust. I will refrain from > > commenting on whether this deployment model is at all wise, but it does > > exist (antivirus, etc). The text itself is just an updated version of > > existing bits here: > > https://tools.ietf.org/html/draft-ietf-tls-esni-02#section-6.2 > > I don't recall that having a concept of it being possible to > "correctly" implement breaking the TLS protocol? (As is inherent > in being an MITM.) > > > > > As for where this effect comes from, it's a consequence of the rollback > and > > partial deployment robustness mechanism in the PR: > > > >> If the server negotiates an earlier version of TLS, or if it does not > >> provide an "encrypted_server_name" extension in EncryptedExtensions, the > >> client proceeds with the handshake, verifying the certificate against > >> ESNIKeys.public_name as described in {{verify-public-name}}. The client > > MUST > >> NOT enable the False Start optimization {{RFC7918}}. If the handshake > > completes > >> successfully, the client MUST abort the connection with an > > "esni_required" alert. > >> It then SHOULD retry the handshake with a new transport connection and > > ESNI > >> disabled." > > > > Or, in other words, IF the server is able to speak authoritatively for > the > > public name (relatively to the client's trust anchors) but appears to not > > understand ESNI at all, that is a signal to the client that ESNI got > turned > > off or hasn't fully been turned on yet. ESNI involves client state and, > > without this, it's risky for a server operator to deploy ESNI. > Deployments > > are complex systems, and complex systems react to change unpredictably. > For > > most changes, if some show-stopping problem is found, it is safe to > > rollback the change. For instance, clients naturally tolerate servers > > turning TLS 1.3 on and off, a fact I'm sure every early adopter of TLS > 1.3 > > has used many times. ESNI, a priori, breaks this property. The intent of > > this text is to restore it, without totally breaking it (the stop signal > is > > authenticated under the public name, the same standard this PR sets for > > replacing the key). > > It may be ok to live with such fallback whilst ESNI is being > introduced but I think ongoing support for it would be unwise. > And such a fallback requires no discussion of MITM attacks. > (Other than as an attack.) > > > > > It turns out that a user moving in and out of one of these "trusted > MITMs" > > I object to that term again, sorry:-) It's marketing meaninglessness. > I have been using air quotes for a reason... :-P My personal view on these things is very far from positive. The intent was simply to update the existing text talking about this same scenario ("A more serious problem is MITM proxies [...] The client can detect this case and disable ESNI while in that network configuration"). In so far as it made sense for the original document to talk about this, among the many complex compatibility considerations in ESNI, I think it continues to makes sense for the PR to do so. That said, you have a good point about the word "correct". I was using that just to invert the existing sentence which begins "A non-conformant MITM proxy [...]", but you are right that the phrasing in the PR has different implications. I need to go through the comments on GitHub and update the PR. In doing so, I will also take another stab at wordsmithing this. Hopefully I can come up with something less objectionable. > > I'm guessing you're referring to this? > > > >> Note that verifying a connection for the public name does not verify it > > for the > >> origin. The TLS implementation MUST NOT surface such connections as > > successful to > >> the application. > > > > That just says you can't report it as successful. > > "MUST NOT surface" seems like bad phrasing then. > I'm blanking on better wording. I wanted to keep the wording independent of whether your TLS stack knows how to open transport connections or not, which changes things a bunch, which constrained things a bit. Any thoughts? > > Is there any reason not to just do it in every ClientHello? > > I'd guess that some implementers may be put off by the > wasted bandwidth. Others won't care but if it's the case > that sending a bogus ESNI x% of the time gets as good a > result as sending all the time (which is how I interpret > what the SHOULD calls for) then it seems better to encourage > x% and not 100%. > When Chrome sends GREASE extensions today, we do it unconditionally on all ClientHellos. I think x% doesn't give a great result. Then implementation bugs get papered over with some probability on retry. The world is full of transparent retries, so this is a poor enforcement of protocol invariants. But, in terms of interop, nothing goes wrong if you choose not to send it sometimes (maybe you're doing a field trial, I dunno). Hence SHOULD, not MUST. >> - Padding to 260 is IIRC the max that works. A CH with such > >> padding is ~600 bytes. Seems like a waste of bytes to me and > >> it could stick out depending on real ESNI padding_lengths. > >> Maybe consider something like "pad to a length that matches > >> recent traffic" and leave it to clients to figure out what > >> might stick out less. (I'm not sure every server will ask > >> for padding to 260 as CF do;-) > >> > > > 260 comes from elsewhere which says: > > > >> The length to pad the ServerNameList value to prior to encryption. > >> This value SHOULD be set to the largest ServerNameList the server > >> expects to support rounded up the nearest multiple of 16. If the > >> server supports wildcard names, it SHOULD set this value to 260. > > Yeah, and I disagree with that too:-) > > > I figured that assuming, by default, that the server supports wildcard > > names seemed reasonable so the text mirrored the other SHOULD. Though > maybe > > that's a bit much? I don't have strong feelings here. What do you think > the > > text should say? Perhaps it should pick a random multiple-of-16 length > > between 64 and 260? Or maybe we should decrease the wildcard value... a > > 260-byte SNI name is kind of excessive, honestly. > > Regardless of the above disagreement about 260, if a client has > been sending a bunch of CH's including real ESNI that are about > 400 bytes because some server's ESNIKeys says to pad to 160, and > that client then sends 600 bytes CH's to everyone else, I think > it'd be crystal clear which is grease and which not. > This is precisely why client and server recommendations should align. It sounds like you believe that the server recommendation of 260 is too much. I would support a change to that (together with a matching client change). What do you think it should say instead? I don't think "pad to a length that matches recent traffic" works well because that adds a bit of correlation between multiple services. It's a minor correlation, but such things still aren't great for privacy and doesn't seem worth adding here. I certainly would not want to implement such a thing. I'm fine with recommending a fixed value, or picking randomly within a range. Beyond that, I think the problem should be solved at both recommendations together. David --0000000000000f92560581df9042 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Feb 13, 2019 at 6:24 PM Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
=
On 13/02/2019 23:55, David Benjamin wrote:
> On Wed, Feb 13, 2019 at = 5:00 PM Stephen Farrell <stephen.farrell@cs.tcd.ie>
> wrote:
> That text isn't prescribing any particular behavior= .

Then delete it:-)=C2=A0
=C2=A0
> It's just describing
> the effect the rest of the text has on "trusted MITM proxies"= ; and the like.

Disagree. "Just describing" does not match the use of a meaningle= ss
marketing term like "trusted blah proxy" sorry. Better to avoid a= ll
that fuss really, no?

> Note this is specifically about "MITM proxies" which control= a root
> certificate that the client is configured to trust. I will refrain fro= m
> commenting on whether this deployment model is at all wise, but it doe= s
> exist (antivirus, etc). The text itself is just an updated version of<= br> > existing bits here:
> https://tools.ietf.org/html/draft= -ietf-tls-esni-02#section-6.2

I don't recall that having a concept of it being possible to
"correctly" implement breaking the TLS protocol? (As is inherent<= br> in being an MITM.)

>
> As for where this effect comes from, it's a consequence of the rol= lback and
> partial deployment robustness mechanism in the PR:
>
>> If the server negotiates an earlier version of TLS, or if it does = not
>> provide an "encrypted_server_name" extension in Encrypte= dExtensions, the
>> client proceeds with the handshake, verifying the certificate agai= nst
>> ESNIKeys.public_name as described in {{verify-public-name}}. The c= lient
> MUST
>> NOT enable the False Start optimization {{RFC7918}}. If the handsh= ake
> completes
>> successfully, the client MUST abort the connection with an
> "esni_required" alert.
>> It then SHOULD retry the handshake with a new transport connection= and
> ESNI
>> disabled."
>
> Or, in other words, IF the server is able to speak authoritatively for= the
> public name (relatively to the client's trust anchors) but appears= to not
> understand ESNI at all, that is a signal to the client that ESNI got t= urned
> off or hasn't fully been turned on yet. ESNI involves client state= and,
> without this, it's risky for a server operator to deploy ESNI. Dep= loyments
> are complex systems, and complex systems react to change unpredictably= . For
> most changes, if some show-stopping problem is found, it is safe to > rollback the change. For instance, clients naturally tolerate servers<= br> > turning TLS 1.3 on and off, a fact I'm sure every early adopter of= TLS 1.3
> has used many times. ESNI, a priori, breaks this property. The intent = of
> this text is to restore it, without totally breaking it (the stop sign= al is
> authenticated under the public name, the same standard this PR sets fo= r
> replacing the key).

It may be ok to live with such fallback whilst ESNI is being
introduced but I think ongoing support for it would be unwise.
And such a fallback requires no discussion of MITM attacks.
(Other than as an attack.)

>
> It turns out that a user moving in and out of one of these "trust= ed MITMs"

I object to that term again, sorry:-) It's marketing meaninglessness.

I have been using air quotes for a reaso= n... :-P My personal view on these things is very far from positive.
<= div>

The intent was simply to update the existing text talking abou= t this same scenario ("A more serious problem is MITM proxies [...] Th= e client can detect this case and disable ESNI while in that network config= uration"). In so far as it made sense for the original document to tal= k about this, among the many complex compatibility considerations in ESNI, = I think it continues to makes sense for the PR to do so.

That said, you have a good point about the word "correct". I wa= s using that just to invert the existing sentence which begins "A=C2= =A0non-conformant MITM proxy [...]", but you are right that the phrasi= ng in the PR has different implications. I need to go through the comments = on GitHub and update the PR. In doing so, I will also take another stab at = wordsmithing this. Hopefully I can come up with something less objectionabl= e.
=C2=A0
> I'm guessing you're referring to this?
>
>> Note that verifying a connection for the public name does not veri= fy it
> for the
>> origin. The TLS implementation MUST NOT surface such connections a= s
> successful to
>> the application.
>
> That just says you can't report it as successful.

"MUST NOT surface" seems like bad phrasing then.
=

I'm blanking on better wording. I wanted to keep th= e wording independent of whether your TLS stack knows how to open transport= connections or not, which changes things a bunch, which constrained things= a bit. Any thoughts?
=C2=A0
= > Is there any reason not to just do it in every ClientHello?

I'd guess that some implementers may be put off by the
wasted bandwidth. Others won't care but if it's the case
that sending a bogus ESNI x% of the time gets as good a
result as sending all the time (which is how I interpret
what the SHOULD calls for) then it seems better to encourage
x% and not 100%.

When Chrome sends GREA= SE extensions today, we do it unconditionally on all ClientHellos.

I think x% doesn't give a great result. Then imple= mentation bugs get papered over with some probability on retry. The world i= s full of transparent retries, so this is a poor enforcement of protocol in= variants. But, in terms of interop, nothing goes wrong if you choose not to= send it sometimes (maybe you're doing a field trial, I dunno). Hence S= HOULD, not MUST.

>>= ; - Padding to 260 is IIRC the max that works. A CH with such
>> padding is ~600 bytes. Seems like a waste of bytes to me and
>> it could stick out depending on real ESNI padding_lengths.
>> Maybe consider something like "pad to a length that matches >> recent traffic" and leave it to clients to figure out what >> might stick out less. (I'm not sure every server will ask
>> for padding to 260 as CF do;-)
>>
>=C2=A0
> 260 comes from e= lsewhere which says:
>
>> The length to pad the ServerNameList value to prior to encryption.=
>> This value SHOULD be set to the largest ServerNameList the server<= br> >> expects to support rounded up the nearest multiple of 16. If the >> server supports wildcard names, it SHOULD set this value to 260.
Yeah, and I disagree with that too:-)

> I figured that assuming, by default, that the server supports wildcard=
> names seemed reasonable so the text mirrored the other SHOULD. Though = maybe
> that's a bit much? I don't have strong feelings here. What do = you think the
> text should say? Perhaps it should pick a random multiple-of-16 length=
> between 64 and 260? Or maybe we should decrease the wildcard value... = a
> 260-byte SNI name is kind of excessive, honestly.

Regardless of the above disagreement about 260, if a client has
been sending a bunch of CH's including real ESNI that are about
400 bytes because some server's ESNIKeys says to pad to 160, and
that client then sends 600 bytes CH's to everyone else, I think
it'd be crystal clear which is grease and which not.

This is precisely why client and server recommendations s= hould align. It sounds like you believe that the server recommendation of 2= 60 is too much. I would support a change to that (together with a matching = client change). What do you think it should say instead?

I don't think "pad to a length that matches recent traffic&= quot; works well because that adds a bit of correlation between multiple se= rvices. It's a minor correlation, but such things still aren't grea= t for privacy and doesn't seem worth adding here. I certainly would not= want to implement such a thing. I'm fine with recommending a fixed val= ue, or picking randomly within a range. Beyond that, I think the problem sh= ould be solved at both recommendations together.

D= avid
--0000000000000f92560581df9042-- From nobody Thu Feb 14 11:27: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 5AF4013107D for ; Thu, 14 Feb 2019 11:27:14 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ViZ5cvL1Vfw for ; Thu, 14 Feb 2019 11:27:12 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 468DF131197 for ; Thu, 14 Feb 2019 11:27:12 -0800 (PST) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x1EJD77H020103; Thu, 14 Feb 2019 19:27:05 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=hGMSJC6ZX/IjRydFe9enT75ItYytprPjxcfEwnWSo+g=; b=X4LzFsFRjXR/o5Y9P/H+32TmUKPEdYaNyLVd/qWZLdKSoFky1AM71r8fD1D2C8P1eChD 5R52ZYU9cMLRmgzSmXpih1pD7xBLvFBuC8f7oHPTK4ri2F2eu6GPxGRsEDdaQo6bjh+g oDyEU7oqg6mE05o+aD6YauECwP53Xvnnhj9hH76xbLVh7MZAeQ5/d/Bimw0Vwc7xSt2E HCm8kYfI4RtHnoZXJrGn/YX3S1vM3UNqd+R+gqG7ou3WcXnqS+k/UazA97EStMn7lrSi PqOgqTY7GwhEviF7FRz61YM3c/CeNOh+KmdoyE+pOMVR0Rj4YCTFIdFHxoPPiOfC7NA0 xA== Received: from prod-mail-ppoint3 (a96-6-114-86.deploy.static.akamaitechnologies.com [96.6.114.86] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2qnctj8bv9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 14 Feb 2019 19:27:05 +0000 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 x1EJIHlk015544; Thu, 14 Feb 2019 14:27:05 -0500 Received: from email.msg.corp.akamai.com ([172.27.25.30]) by prod-mail-ppoint3.akamai.com with ESMTP id 2qhu32s308-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 14 Feb 2019 14:27:04 -0500 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.1395.4; Thu, 14 Feb 2019 13:26:57 -0600 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.1395.000; Thu, 14 Feb 2019 13:26:57 -0600 From: "Salz, Rich" To: David Benjamin , Stephen Farrell CC: TLS WG Thread-Topic: [TLS] ESNI PRs #124 and #125: Improving ESNI Robustness and GREASE Thread-Index: AQHUw+m/JHT3XTe+OUuQDqIM8jd8ZKXevHcAgAAPlwCAAAfngIABPaiA//+t0QA= Date: Thu, 14 Feb 2019 19:26:56 +0000 Message-ID: References: <714E43FA-3660-485A-8E50-04EE43F8DA2E@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.0.190211 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.122] Content-Type: multipart/alternative; boundary="_000_B74E86245A9442BE901D8BE2351B41C8akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-14_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=777 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902140128 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-14_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=782 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902140128 Archived-At: Subject: Re: [TLS] ESNI PRs #124 and #125: Improving ESNI Robustness and GREASE 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, 14 Feb 2019 19:27:19 -0000 --_000_B74E86245A9442BE901D8BE2351B41C8akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBUaGF0IGp1c3Qgc2F5cyB5b3UgY2FuJ3QgcmVwb3J0IGl0IGFzIHN1Y2Nlc3NmdWwuDQoNCiJN VVNUIE5PVCBzdXJmYWNlIiBzZWVtcyBsaWtlIGJhZCBwaHJhc2luZyB0aGVuLg0KDQoNCiAgKiAg IEknbSBibGFua2luZyBvbiBiZXR0ZXIgd29yZGluZy4gSSB3YW50ZWQgdG8ga2VlcCB0aGUgd29y ZGluZyBpbmRlcGVuZGVudCBvZiB3aGV0aGVyIHlvdXIgVExTIHN0YWNrIGtub3dzIGhvdyB0byBv cGVuIHRyYW5zcG9ydCBjb25uZWN0aW9ucyBvciBub3QsIHdoaWNoIGNoYW5nZXMgdGhpbmdzIGEg YnVuY2gsIHdoaWNoIGNvbnN0cmFpbmVkIHRoaW5ncyBhIGJpdC4gQW55IHRob3VnaHRzPw0KDQpS ZXByZXNlbnQgaW5zdGVhZCBvZiBzdXJmYWNlPw0K --_000_B74E86245A9442BE901D8BE2351B41C8akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <8744978F3DBE284189327583043296A8@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNv TGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDou NWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFs MCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRp b25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoyMTU3MDgxMDY7DQoJbXNvLWxpc3QtdHlw ZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjg3OTgyNDU2IDEwNTQ5MDA3NTIgNjc2 OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2 OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAbGlzdCBsMDps ZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1 bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgVGhhdCBqdXN0IHNheXMgeW91IGNh bid0IHJlcG9ydCBpdCBhcyBzdWNjZXNzZnVsLiA8YnI+DQo8YnI+DQomcXVvdDtNVVNUIE5PVCBz dXJmYWNlJnF1b3Q7IHNlZW1zIGxpa2UgYmFkIHBocmFzaW5nIHRoZW4uPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBj bGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDps MCBsZXZlbDEgbGZvMSI+SSdtIGJsYW5raW5nIG9uIGJldHRlciB3b3JkaW5nLiBJIHdhbnRlZCB0 byBrZWVwIHRoZSB3b3JkaW5nIGluZGVwZW5kZW50IG9mIHdoZXRoZXIgeW91ciBUTFMgc3RhY2sg a25vd3MgaG93IHRvIG9wZW4gdHJhbnNwb3J0IGNvbm5lY3Rpb25zIG9yIG5vdCwgd2hpY2ggY2hh bmdlcyB0aGluZ3MgYSBidW5jaCwgd2hpY2gNCiBjb25zdHJhaW5lZCB0aGluZ3MgYSBiaXQuIEFu eSB0aG91Z2h0cz88bzpwPjwvbzpwPjwvbGk+PC91bD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ UmVwcmVzZW50IGluc3RlYWQgb2Ygc3VyZmFjZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_B74E86245A9442BE901D8BE2351B41C8akamaicom_-- From nobody Thu Feb 14 11:37: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 C59961311A0 for ; Thu, 14 Feb 2019 11:37:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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] 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 lyE-ZTfRvTf6 for ; Thu, 14 Feb 2019 11:37:38 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9953A13119D for ; Thu, 14 Feb 2019 11:37:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 805D5BE39; Thu, 14 Feb 2019 19:37:33 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6DAPTpYBX6e; Thu, 14 Feb 2019 19:37:32 +0000 (GMT) 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 2F9E7BE38; Thu, 14 Feb 2019 19:37:32 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1550173052; bh=BvdEKIClHvvqraadGoGCQScAx4JYL65o8a5N20mkOtY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=D8etPq4RU5oAwIJPj5E3f2qd5XXwRvdmKnedAdNsLtVaRRgJSIH2O/HhRmvD631yR N4hmWlWJXnsAvN/LB+yIZz2BRUbrV40uwdcGsIZbaI0qp/Xt/Q19Yu751D1LOMcx6E vlPi/kgyFsuMleScuqehAsX47Qt6rCkqLQ5nqDew= To: "Salz, Rich" , David Benjamin Cc: TLS WG References: <714E43FA-3660-485A-8E50-04EE43F8DA2E@gmail.com> 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: <1a1a9e34-1511-b1a6-659b-20e3db513022@cs.tcd.ie> Date: Thu, 14 Feb 2019 19:37:31 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="UcB1SrNrADiKFqEkfwAUzgc84nRG63tIy" Archived-At: Subject: Re: [TLS] ESNI PRs #124 and #125: Improving ESNI Robustness and GREASE 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, 14 Feb 2019 19:37:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UcB1SrNrADiKFqEkfwAUzgc84nRG63tIy Content-Type: multipart/mixed; boundary="sfRw3UFPM5p77NCWLpHUMaCs5pLQydErV"; protected-headers="v1" From: Stephen Farrell To: "Salz, Rich" , David Benjamin Cc: TLS WG Message-ID: <1a1a9e34-1511-b1a6-659b-20e3db513022@cs.tcd.ie> Subject: Re: [TLS] ESNI PRs #124 and #125: Improving ESNI Robustness and GREASE References: <714E43FA-3660-485A-8E50-04EE43F8DA2E@gmail.com> In-Reply-To: --sfRw3UFPM5p77NCWLpHUMaCs5pLQydErV Content-Type: multipart/mixed; boundary="------------ACD20503246037C7284B013B" Content-Language: en-GB This is a multi-part message in MIME format. --------------ACD20503246037C7284B013B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 14/02/2019 19:26, Salz, Rich wrote: >> That just says you can't report it as successful. >=20 > "MUST NOT surface" seems like bad phrasing then. >=20 >=20 > * I'm blanking on better wording. I wanted to keep the wording inde= pendent of whether your TLS stack knows how to open transport connections= or not, which changes things a bunch, which constrained things a bit. An= y thoughts? >=20 > Represent instead of surface? I'd be fine if the PR wasn't fully wordsmithed, e.g. I've often written drafts that have text like "[[this needs more right, "surface" isn't quite right]]" - there will, after all, be a -04 and so on when we can fix that. Cheers, S. --------------ACD20503246037C7284B013B 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 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5tDJTdGVwaGVuIEZhcnJlbGwgKDIwMTcp IDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJCZQmAAUL CQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1yw aps8HGUNhLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG +48od+Xn7qg6LT7GrHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXk kTFaSGYJj3yIP4R6IgwBYGMzDXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRr pZtXB1XQc23ZZmrlTkl2HaThL6w3YKdiTi1NbuMeOxZqtXcUshII45sANm4HuWNT iRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS3MmGgVS4ZoX8+VaPGpXdQVFy BMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml3OEuIQiP2ehRt/HV LMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi2/Jrsz6M zh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6 TzKjGjruq8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxIkBHAQQAQgABgUCWj1SoAAK CRAvPIc2gF+NovMcCACVZPo1cQa3D+vWaIo0ZyinO/MgtD2gHysoj1T0Qvq05//L ZXmhh578bJANvdl2g/HFhhwl/5HKIfWcyipQhmJklp/dsleKcNnn4B18T75RHY0G +po3ILq7evbiOjUH+xqApti1aCxi1GocsPghaLfsxmtXKMG4Xu7XhDTv66GOrqZf Y7+0ekJjD9Dza1t5NE/JR/VZA4B8PWR8Glb0+8C9rkjD0VZ5ekJdHPDGcJmFh8Z+ q25LDoI8Fgt1uKSowvoVnsQO5MFv/y6bXArtj1uB4hAL4JiOFgHlFdrW0MlFpvYm ziW4K9JHTD8KAfDbrb3e2W97ZDpROuYfE/lTbYOWiQI9BBMBCAAnBQJaPVAyAhsD BQkJlCYABQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEFqy+vF7Fyvq0mkP/ius gsf6Z4/Tu+vHzBbl5i6oKI8ZieH8JfEgXx4ut9t7l3hBGC2r7DpR5A8zLMpEhGIK gFcHagksFkfLEE/FmWDfd1MysQafxBYrHaI27P2tkxfI5JYV6247TV39pQ93kGds tsjIrmh/zEJCVczoofxtz72BDt51H2Z8tN28F/YVHnbaGDwFEEzWKYpze87y/f36 ogcdGO6LDEEEIA6Ee0dGxleuKlLS4UDTt0zjo6L8TyiyPHp9C3+UfnP8837Zp3Fh KstIBd+vWgPdHFg2G5aDIYUvrj9UJBvVgaN/RnkwE+dab2OBSg5jkr141JLQvzdZ 4mOUXn5D9Y6AH6tvj0+ubYMV6j35L1/ZXncuXPVYiylcmDp/6f2WYcT3gx9CPUYA cLMjQV4vX2W8z4uEPyMlIJuGsLf7KhvLL8BQ6zlncT6eONfUUX9UJUCzqI5rqL5c b5jWGHeKvbLWRyQnlq5PXQxJTwYRm71rJTgzejc33LE6Nqg/Q25Dgwwsv+f+7i73 gB5loc80Fef+FV9VFGalFe0Yq8m0UASmkYRh7MH5ssoibpeWk+SGfBjOV4tnsAwR yjYLpAzxA8HeDcmlLeypGEDmsQ/iUvXoGaKOYX4Ieg8T/PCAplsqnJUOq8hbkgOC 98gLZfiltkNG8YhQpoZIHj6SxmBRSc3K99CvanuOiQIzBBABCAAdFiEEfhcKBFyE z0YOK3mgEO952f2DUxIFAlu3JJsACgkQEO952f2DUxJ4qRAAmbjiO3WTAeBCB4ME p2N2+XQCMTTFURDGuJnqU/+X//fhhPRq4V/OxgisKFKlBcAS2hsECvg6HDVSz4Fl 74fk/y+botG4/CjMLdKPB9fgh5zz72i3q0hWDixt50NKBv8IIVWOyYgZxDU/vcks lMEnqbFgJX+CfdALpvAM4WjuQP0UMcKNE3xd+EdDhD1xjK3Tq4XfWob9q6aBZgL2 B4IaADCIeDDE1hv0agnSJmMJE7Bti8tNxCCxVRbZtOaxVHXdRUoOx2XTaxFXupxV hbpHRrdFrwq51f6e3bkfkNEZ3fzYpnlbynJ2zL++JO8P3Pq/S6UKEFjEB50i8YgK WuFvGUsQ+YiDgiZU4saqxSBWbfYn3lY6MSSTg8RnXbFIMG3CFImqYk1uhaV+bDjc p0htjzM2F98g7c3o7sWx0bGarId4uhOmpj7JJVQ+lu7Jby6Ocj8n//7qF1Nn11Cw QlCVaeAq5Y5DmZrnww9I3zzOWWyqFkAVCM3GqeRLMvplD6/+O+5FF7XoHzQB47nk OyZtawy/9gssPWZKLv4qHLYS0wGGCiNbCsYy90s3pfeafM0kSxxjIvEz21KT6LJI /awu2ErQFWCkDMFJ1p/97MjPrQ/6d4cPO140V/wyfuWaBiTVqa9mgnb2zn6fYfDH JEvl1UzIx3JCae25tty1+qtnS0i0LlN0ZXBoZW4gRmFycmVsbCA8c3RlcGhlbkB0 b2xlcmFudG5ldHdvcmtzLmNvbT6JAj0EEwEIACcFAlo9UVoCGwMFCQmUJgAFCwkI BwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+o7HBAAxHAdFkBGZ9gJK8w7 NUYS9C6enGYtAYoKH5G3Bn3YScjErNfQtHYb53KwBQpVSOv1HcN8hbQ8mLTgn9lt zNwNSuv0XxIswi807HRSIZ4vYDiS5VKV1YkLYK5bLY5O4alVdzqM+AZQqkuHBu63 6n+C0ED6UwLhVBFfSNvBQVAdoq6gvr+IE8rCIKTMNGwNcgVPbF+YxP7UZM6p7s2a 5MIqGw7URSfaqfuztibXGOBLFbSwLGqHSSnOXBfEeDrwdZ+ur8cXIIPRIeCTVmeO 8bGgpgBqNQXG9oyGN+TrYAC+4Ahi0UjCk7QGj8tf3xICKoQpYyfceNBZJ/969gV9 tVgvRxUjxUwc9kZbi0c8XYMTq5GCvBIh1D6BOW9QBM2SsNgG3l36+e3+c2LDdyKn 20C1IzGLVDdcCtz42/onQ/e9sMlzFrfLjs5SO2/TnLvp2JtsIQXyb/T5qd0GE5j8 /iwfZR+uVTVVEsUl1a+Yllzt6sdR7RIhhKpKaKzEAk4d0+VHdz7zEkQRRSjbPVoS fy8c/kld9Fi8Buna+ZkKpcwIW+D4XP83pGcl0XUv6AyqwS1LnEt+jv/+PSXskYtU Lzn8Z35iKkSAH/5Nz6GCZk6ORPNv/6+UI92BpUbu/G2tBwK8bPgAg+gJxBx3G7MK W7VRCmM5UrtAK9A3O70VjPyMkHSJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLC LAf/X/9vRTZWtwSXxiBCA54a6hg9IvW0mvPUqgXfvrhtOk0IFucLKrTXK8J/NcmU 6ulxOovVbQ+Bin6gtHeCmSa/W523g/NXCOuFTnS/MyVibNL4+RCFwqGysl++Cm+L nj1MmasE9kO+CNdervx8APfxV7D6OYrG4eGag+LdFR6VpJn6tRT0/WvyT8l+Oqiq gdhXHv+0MvkkD9TX5LlJW4VB/yRvWkkmL5N5c5zYh+NcfTPhQ5S9dOorVzrm65d6 Itn0937Ennau7s7fiFdA0BHjWqEAFLsBIXQfCFjjKjdsKA4xlSiX7X7ElmPYpWa5 wwTQ66dL0anMd9y1DJCMOHe4gYkCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9 g1MSBQJbtyScAAoJEBDvedn9g1MSY7sP+gKR0rFU1g+GtB+hSdtwPRbacvml2eL2 Jc5Eq37J9hAqxHyt5V0If7s8IyVA2GXgdfwULBWbXGDUDiUkh20OPQRUS8G9Sf8A WRuG25q5C8ZzWygykL88RKXJZDFtA49CeqO5Bq5syBhq4QfiSTffQHIp3h0boPGU hSBEUQpooMXYQClNARQ+z/uRzR5bUi9wxdXNnxTn9ia4ASlaBPvUYTGY1jW2HrRR SwpI12+UaWsvc3jJtQ8X0kxgJ7jsFF1uqquIZ5eflQv+PHHg2RJSy37u0UFGb+OK ZEkzlmbPokKCYhzBR5PcD6sgdlaJNcidmto9u1oV6yZT8J2W4CTuUclgxt6f3lZq ZeVLnNnbHyKUdeypwLlqYISulfnMhZ3A6Bgpf2BtjL6KJbFtPBYmYdxI+HZyY49u U2ZHhRu+CSQ1y7zGKSX0gRp5hE7+A4XJtsT6lTLhbi9aiZTG1S6zKNhl3qNNzszc r27PrvFiyGhpuYQuzdQl2PMGbOI6Ojif3sab53NO3RLsLOM09wIlr95yKLlkXkUr WcvUJGrw6HKm8j5opXHTwmJOAbDpc6cMDu+ITRu4spdCnQJcE8RkO8tKyaLuh2Gt U5kYSBK97yr5VviX1FK6rY14LLmnE16OPiK2tiVBKy9nGM0DKtY+K9WcoRZ7s/d7 O0bMfzcNPtGLuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiez GPuBHmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9Wf pHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC 6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2 D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFe A7PbTuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ /Vf3vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbpt PEcmoazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKr em5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96 Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYgh x8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQ oqj1gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P /1tF6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8 Wpfdn3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJ gx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5 SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2 oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIA ypqYo3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoM eDQkd0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS /qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZ IMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XO KVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DJ121 -----END PGP PUBLIC KEY BLOCK----- --------------ACD20503246037C7284B013B-- --sfRw3UFPM5p77NCWLpHUMaCs5pLQydErV-- --UcB1SrNrADiKFqEkfwAUzgc84nRG63tIy Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlxlw3sACgkQWrL68XsX K+qzyw//S2UzodT9QpLrjaUG7X6JcPIdMBn4Le2RnelXFwJ68YxO7oKYMpBj13tY y8msI3w6godcSz6VytgUgUCavqxw4pDQCDoYDFhTnLqtNui9b8CDsINXv6saLfkD OIDH1yrJ92pdL9OgbENlBbIpEq+Dwp8pkI2FZzvKaXTbU7USj4Hr6qKoUpVpUNRW AAipNb54rRUem3UGEY2hp1+Sfg3h6LjPlIxcLOhD8vAbpX3QViMAu9ABA7k+Cf3I dQVI2fXhXDNFrZGeEn14gE+o/F6Wb8o3fwSxozkk7g1OlRIrSzpDHgDoogm4aUO1 84a1iDjlgoHv8wlYaY9PnH4h08VOc5VzJolYxyaAAsAznVT5FMm6TpXCq59acK4N rpvCZ4zCCFSHCIo5oFm3Fp9lSS7nPAho1H6PLd2baHsLxqS2PeoaPd/g1FtPtaQr XdEDH/XIZuPkchDxRoJHSzTYFiecHGE2fy/q5MBVISnHVsngXYhhwbyH0akIQYht RYdWck1cOwo+ZchHhxL+Rm5R97vfh14qJwYJJystQgt1mZs3OXD+fM5WkDaf9gjA 2xUdlVIPjz1opDExOjkpuhOH6jH0sh7tjpiOHHQ5XmkrlyqeUnGma7VQ7v9T9beo qQi9bkQkDL+Khm7scUzluDZ65poAk9W3KbybgLE9WisYizsaHmk= =wMks -----END PGP SIGNATURE----- --UcB1SrNrADiKFqEkfwAUzgc84nRG63tIy-- From nobody Thu Feb 14 11:46:40 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB4471292F1 for ; Thu, 14 Feb 2019 11:46:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=nerd.ninja Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zw_vtcGf1FoV for ; Thu, 14 Feb 2019 11:46:34 -0800 (PST) Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0B95126F72 for ; Thu, 14 Feb 2019 11:46:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550173588; cv=none; d=zoho.com; s=zohoarc; b=FQJeXAdDz+qBuaaCiA0eE3bXwsGCDyM76Ge1fQYDeaQMRxToAFkzZ2AW4a2Dr/Q13/uxY6C0097cjMq5Ms5Zge/ndX+XyyRdN5zpUQ3+/3lWJL3NJqFPwO1BBQV+MktuxvSiIhOWtSBluIalj7dnSxLw81nZVG4JtS5n1yeewUw= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1550173588; h=Content-Type:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results; bh=kCJEnDBOvCd8V8fpspfr06xKcNWdiiOSLq9K8UW61dU=; b=VYv4BcD/CjOk1f7u+UHQyD/2tXwqPGv1KL/Be0VT4DmavcLpkhivZlGf5IlOnDH7OtdSxqxy8Qogek/tgkDGMzpvGhFDwmoXxG4PvFKn2MrDUGaJx77rDWu/fkUiQs0IqqEd8Vm4aK338khcgMJJffUJFEBC069IAJPd5OoEsK0= ARC-Authentication-Results: i=1; mx.zoho.com; dkim=pass header.i=nerd.ninja; spf=pass smtp.mailfrom=r@nerd.ninja; dmarc=pass header.from= header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1550173588; s=zoho; d=nerd.ninja; i=r@nerd.ninja; h=Date:From:To:Cc:Message-Id:In-Reply-To:References:Subject:MIME-Version:Content-Type; l=12379; bh=kCJEnDBOvCd8V8fpspfr06xKcNWdiiOSLq9K8UW61dU=; b=Re14eNHUIFXP8hc5q2baJnBU3RM5Rm/mH7Ip8U0fXacDvjJffwkVoyhjTi7v+bJe NZp2J+9YN5BI+KffsfToRLoH0urS4sSUA0C6ucXNM0y+9ti8NYI7NP48cmrn/IVPPaw m7HyrqHUdHTReWz+zURUJMvymIjUHkhSFbevT94k= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1550173581560252.91370305098224; Thu, 14 Feb 2019 11:46:21 -0800 (PST) Date: Thu, 14 Feb 2019 14:46:21 -0500 From: Roelof DuToit To: "David Benjamin" Cc: "Christopher Wood" , "TLS WG" Message-Id: <168ed8bb0f5.1026877c920218.3245439195642672251@nerd.ninja> In-Reply-To: References: <714E43FA-3660-485A-8E50-04EE43F8DA2E@gmail.com> <168e9a61d1e.cce5c9ea206228.28832954982140191@nerd.ninja> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_65956_221876537.1550173581557" X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail Archived-At: Subject: Re: [TLS] ESNI PRs #124 and #125: Improving ESNI Robustness and GREASE 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, 14 Feb 2019 19:46:37 -0000 ------=_Part_65956_221876537.1550173581557 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ---- On Thu, 14 Feb 2019 13:00:16 -0500=C2=A0David Benjamin wrote ---- On Wed, Feb 13, 2019 at 7:37 PM Roelof DuToit wrote: Questions for PR [1]: * Regarding this text: The client MUST NOT use the server-provided retry keys until the handshake = completes successfully. On success, it MUST NOT overwrite the DNS-provided = keys with the retry keys. It MUST use the retry keys at most once and conti= nue offering DNS-provided keys for subsequent connections. This avoids intr= oducing a tracking vector, should a malicious server present client-specifi= c retry keys. .. specifically this part: ".. use the retry keys at most once".=C2=A0=20 Q1: Are you saying the client should persistently remember which public_nam= e values triggered retry keys?=C2=A0 For how long? No, exactly the opposite. You use the retry key for just the retry and then= forget about it. https://mailarchive.ietf.org/arch/msg/tls/xBEHe1_CcYEYinZQHxWGq8vjA0Q I understood that part.=C2=A0 =C2=A0Let my clarify my question with an exam= ple: A1. Client uses DNS-provided keys, and server returns retry keys A2. Client uses retry keys, and everything works.. A3. Client restarts A4. Client uses DNS-provided keys, and server returns the same retry keys a= s in A1 A5. Client violates spec by using those retry keys for a second time? And what about this example: B1. Client uses DNS-provided keys, and server returns retry keys B2. Client uses retry keys, and everything works.. B3. Client uses DNS-provided keys, and server returns retry keys B4. Client violates spec by using those retry keys for a second time? Q2: What happens if fronting server A sent retry keys, and the subsequent t= ransport connection ends up on server B, which also sends retry keys? You keep retrying. And hen you hit the text which says: > Clients SHOULD implement a limit on retries caused by "esni_retry_request= " or > servers which do not acknowledge the "encrypted_server_name" extension. This is an error-correcting mechanism to avoid deployment risks. If your TL= S deployment is so out of sync with itself that: - It deployed ESNI keys in the DNS that your servers do not understand. - Even on a retry to presumably the same IP address, you hit a different se= rver node. - Your load balancer keeps bouncing between different server nodes connecti= ons right after each other. - Each of your server nodes believes in a totally disjoint set of ESNI keys= . Then I think giving up and failing the connection is not the end of the wor= ld. =C2=A0 --Roelof ---- On Wed, 13 Feb 2019 17:15:57 -0500=C2=A0Christopher Wood wrote ---- Hi folks, PRs [1] and [2] need a little more review before we merge since=20 they=E2=80=99re non-trivial changes. Please have a look and let the list kn= ow=20 if you have objections with the contents therein. Otherwise, we will=20 merge them by the end of the next week. Thanks! Chris (no hat) [1] https://github.com/tlswg/draft-ietf-tls-esni/pull/124 [2] https://github.com/tlswg/draft-ietf-tls-esni/pull/125 _______________________________________________ TLS mailing list mailto:TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list mailto:TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls ------=_Part_65956_221876537.1550173581557 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =



---- On Thu, 14 Feb 2019 13:00:16 -0500&n= bsp;David Benjamin <davidben@chromium.org> wrote ----

On Wed, Feb 13, 2019 at 7:= 37 PM Roelof DuToit <r= @nerd.ninja> wrote:

Questions for PR [1]:

* Regarding this text:
The client MUST NOT use the server-provided retry keys until the han= dshake completes successfully. On success, it MUST NOT overwrite the DNS-pr= ovided keys with the retry keys. It MUST use the retry keys at most once an= d continue offering DNS-provided keys for subsequent connections. This avoi= ds introducing a tracking vector, should a malicious server present client-= specific retry keys.

.. specifically this part: ".. use the retry keys at most once".  <= br>
Q1: Are you saying the client should persistently remember wh= ich public_name values triggered retry keys?  For how long?
<= /div>

No, exactly the opposite. You u= se the retry key for just the retry and then forget about it.
https://mailarchive.ietf.org/arch/msg/tls/xBEHe1_= CcYEYinZQHxWGq8vjA0Q

I understood that part.   Let my clarify my quest= ion with an example:

A1. Client uses DNS-provi= ded keys, and server returns retry keys
A2. Client uses retry= keys, and everything works..
A3. Client restarts
A4. Client uses DNS-provided keys, and server returns the same retry key= s as in A1
A5. Client violates spec by using those retry keys= for a second time?

And what about this example:

B1. Client uses DNS-provided keys, and server r= eturns retry keys
B2. Client uses retry keys, and everything = works..
B3. Client uses DNS-provided keys, and server returns= retry keys
B4. Client violates spec by using those retry keys fo= r a second time?





Q2: What happens if fronting server A s= ent retry keys, and the subsequent transport connection ends up on server B= , which also sends retry keys?

<= /div>
You keep retrying. And hen you hit the text which says:
=

> Clients SHOULD implement a limit on retries c= aused by "esni_retry_request" or
> servers which do not ac= knowledge the "encrypted_server_name" extension.

This is an error-correcting mechanism to avoid deployment risks. I= f your TLS deployment is so out of sync with itself that:
- It deployed ESNI keys in the DNS that your servers do not und= erstand.
- Even on a retry to presumably the same IP address,= you hit a different server node.
- Your load balancer keeps = bouncing between different server nodes connections right after each other.=
- Each of your server nodes believes in a totally disjoint s= et of ESNI keys.

Then I think giving up and fa= iling the connection is not the end of the world.

<= div> 

--Roelof


---- On Wed, 13= Feb 2019 17:15:57 -0500 Christopher Wood <christopherwood07@gmail.com= > wrote ----

Hi f= olks,

PRs [1] and [2] need a little more revie= w before we merge since
they=E2=80=99re non-trivial changes.= Please have a look and let the list know
if you have object= ions with the contents therein. Otherwise, we will
merge the= m by the end of the next week.

Thanks!
Chris (no hat)

<= div>
<= /div>
_______________________________________________
TLS mailing list
=

------=_Part_65956_221876537.1550173581557-- From nobody Thu Feb 14 12:08: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 7C6E512867A for ; Thu, 14 Feb 2019 12:08:49 -0800 (PST) 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 hdliLop1BT-5 for ; Thu, 14 Feb 2019 12:08:45 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46075127287 for ; Thu, 14 Feb 2019 12:08:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 40808BE39; Thu, 14 Feb 2019 20:08:43 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kF_Y2OnINLCQ; Thu, 14 Feb 2019 20:08:41 +0000 (GMT) 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 6EC31BE38; Thu, 14 Feb 2019 20:08:41 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1550174921; bh=vhfSWgxs9yJAzXN8apInSo0ZLYtQbSgsPGoDGw1Qdjw=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=l01wO4kCKXkP8TJSmGjmb2huF37Xgd+mCFm9cvxB+n7QDr6OR4F2ZO/m1lczXbHZ+ /p09SArNFrtLA/5f6iLVRSUjxLTNybsMBTRDHHCPHLMURI7PaOqEOmThIfAMJUmSQ9 7WnFhnF8W7QYsDlJMhJpKLkVFKtRXRTHUXLkMQZI= To: David Benjamin Cc: Christopher Wood , TLS WG References: <714E43FA-3660-485A-8E50-04EE43F8DA2E@gmail.com> 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: <8659f24d-80c8-a741-cf0a-d4c08e090c10@cs.tcd.ie> Date: Thu, 14 Feb 2019 20:08:40 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6NkQ6iTVmfRAMMcA0nBUMcTtjLlKEpEu8" Archived-At: Subject: Re: [TLS] ESNI PRs #124 and #125: Improving ESNI Robustness and GREASE 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, 14 Feb 2019 20:08:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6NkQ6iTVmfRAMMcA0nBUMcTtjLlKEpEu8 Content-Type: multipart/mixed; boundary="x17cgioUWFXWkDnrQpVl8LGAwy0SS5dB4"; protected-headers="v1" From: Stephen Farrell To: David Benjamin Cc: Christopher Wood , TLS WG Message-ID: <8659f24d-80c8-a741-cf0a-d4c08e090c10@cs.tcd.ie> Subject: Re: [TLS] ESNI PRs #124 and #125: Improving ESNI Robustness and GREASE References: <714E43FA-3660-485A-8E50-04EE43F8DA2E@gmail.com> In-Reply-To: --x17cgioUWFXWkDnrQpVl8LGAwy0SS5dB4 Content-Type: multipart/mixed; boundary="------------661903C97DF338D46D1232C0" Content-Language: en-GB This is a multi-part message in MIME format. --------------661903C97DF338D46D1232C0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 14/02/2019 19:21, David Benjamin wrote: > On Wed, Feb 13, 2019 at 6:24 PM Stephen Farrell > wrote: >=20 > I have been using air quotes for a reason... :-P My personal view on th= ese > things is very far from positive. That's what I thought. You're right there anyway:-) >=20 > The intent was simply to update the existing text talking about this sa= me > scenario ("A more serious problem is MITM proxies [...] The client can > detect this case and disable ESNI while in that network configuration")= =2E In > so far as it made sense for the original document to talk about this, a= mong > the many complex compatibility considerations in ESNI, I think it conti= nues > to makes sense for the PR to do so. >=20 > That said, you have a good point about the word "correct". I was using = that > just to invert the existing sentence which begins "A non-conformant MIT= M > proxy [...]", but you are right that the phrasing in the PR has differe= nt > implications. I need to go through the comments on GitHub and update th= e > PR. In doing so, I will also take another stab at wordsmithing this. > Hopefully I can come up with something less objectionable. Fair enough. >>> Is there any reason not to just do it in every ClientHello? >> >> I'd guess that some implementers may be put off by the >> wasted bandwidth. Others won't care but if it's the case >> that sending a bogus ESNI x% of the time gets as good a >> result as sending all the time (which is how I interpret >> what the SHOULD calls for) then it seems better to encourage >> x% and not 100%. >> >=20 > When Chrome sends GREASE extensions today, we do it unconditionally on = all > ClientHellos. >=20 > I think x% doesn't give a great result. Then implementation bugs get > papered over with some probability on retry. The world is full of > transparent retries, so this is a poor enforcement of protocol invarian= ts. > But, in terms of interop, nothing goes wrong if you choose not to send = it > sometimes (maybe you're doing a field trial, I dunno). Hence SHOULD, no= t > MUST. Also fair. I guess we can see what's folks do in other cases. >>> - Padding to 260 is IIRC the max that works. A CH with such >>>> padding is ~600 bytes. Seems like a waste of bytes to me and >>>> it could stick out depending on real ESNI padding_lengths. >>>> Maybe consider something like "pad to a length that matches >>>> recent traffic" and leave it to clients to figure out what >>>> might stick out less. (I'm not sure every server will ask >>>> for padding to 260 as CF do;-) >>>> >>> >=20 >> 260 comes from elsewhere which says: >>> >>>> The length to pad the ServerNameList value to prior to encryption. >>>> This value SHOULD be set to the largest ServerNameList the server >>>> expects to support rounded up the nearest multiple of 16. If the >>>> server supports wildcard names, it SHOULD set this value to 260. >> >> Yeah, and I disagree with that too:-) >> >>> I figured that assuming, by default, that the server supports wildcar= d >>> names seemed reasonable so the text mirrored the other SHOULD. Though= >> maybe >>> that's a bit much? I don't have strong feelings here. What do you thi= nk >> the >>> text should say? Perhaps it should pick a random multiple-of-16 lengt= h >>> between 64 and 260? Or maybe we should decrease the wildcard value...= a >>> 260-byte SNI name is kind of excessive, honestly. >> >> Regardless of the above disagreement about 260, if a client has >> been sending a bunch of CH's including real ESNI that are about >> 400 bytes because some server's ESNIKeys says to pad to 160, and >> that client then sends 600 bytes CH's to everyone else, I think >> it'd be crystal clear which is grease and which not. >> As a possible side-note, isn't this greasing a little different from others - this is also really chaff that functions to discourage blocking all ESNI (as well as the usual greasing) by causing real uses of ESNI to "not stand out" as per the section in Christian's draft. I think that comes into play here. > This is precisely why client and server recommendations should align. I= t > sounds like you believe that the server recommendation of 260 is too mu= ch. That, but moreso that I don't think a per-server padding_length is really a good design choice. If it's there, different services will choose different values. That means greasers need to pick a value, and either that forces all services to pick whatever the best greaser chooses (or real use of ESNI with that service stands out), or else it forces greasers to use whatever is the most commonly used padding_length (current whatever CF deploy I guess, which is 260), and that again means the non grease uses out stand out. Either way we all end up at 260 or risk getting blocked. > I would support a change to that (together with a matching client chang= e). > What do you think it should say instead? Drop paddling_length entirely and replace it with some MUST level thing that everyone does. E.g. for real uses of ESNI could be "padding MUST be to a multiple of 64 octets and SHOULD be minimal" perhaps with "greasers MUST send some percentage I don't think "pad to a length that matches recent traffic" works well > because that adds a bit of correlation between multiple services. It's = a > minor correlation, but such things still aren't great for privacy and > doesn't seem worth adding here. I certainly would not want to implement= > such a thing. I'm fine with recommending a fixed value, or picking rand= omly > within a range. Beyond that, I think the problem should be solved at bo= th > recommendations together. Fair point. I was trying to suggest something that'd work within the scope of this PR. Let me try argue for it a little bit more: If paddling_length remains as-is, then ISTM that a particular client will recently have been seen emitting mostly grease-padding lengths, but also a few different lengths as determined by real services. In order to stop use of those services sticking out, I think the greaser needs to emit some CHs matching the lengths of those real services too. So I'd suggest maybe keeping a set of (padding_length, probability) tuples and randomly picking from that when greasing, with that table updated based on traffic seen/sent. Bit complex yes, but I think that's the consequence of per service padding_length in ESNIKeys. Sound any better? Cheers, S. >=20 > David >=20 --------------661903C97DF338D46D1232C0 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 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5tDJTdGVwaGVuIEZhcnJlbGwgKDIwMTcp IDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJCZQmAAUL CQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1yw aps8HGUNhLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG +48od+Xn7qg6LT7GrHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXk kTFaSGYJj3yIP4R6IgwBYGMzDXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRr pZtXB1XQc23ZZmrlTkl2HaThL6w3YKdiTi1NbuMeOxZqtXcUshII45sANm4HuWNT iRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS3MmGgVS4ZoX8+VaPGpXdQVFy BMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml3OEuIQiP2ehRt/HV LMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi2/Jrsz6M zh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6 TzKjGjruq8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxIkBHAQQAQgABgUCWj1SoAAK CRAvPIc2gF+NovMcCACVZPo1cQa3D+vWaIo0ZyinO/MgtD2gHysoj1T0Qvq05//L ZXmhh578bJANvdl2g/HFhhwl/5HKIfWcyipQhmJklp/dsleKcNnn4B18T75RHY0G +po3ILq7evbiOjUH+xqApti1aCxi1GocsPghaLfsxmtXKMG4Xu7XhDTv66GOrqZf Y7+0ekJjD9Dza1t5NE/JR/VZA4B8PWR8Glb0+8C9rkjD0VZ5ekJdHPDGcJmFh8Z+ q25LDoI8Fgt1uKSowvoVnsQO5MFv/y6bXArtj1uB4hAL4JiOFgHlFdrW0MlFpvYm ziW4K9JHTD8KAfDbrb3e2W97ZDpROuYfE/lTbYOWiQI9BBMBCAAnBQJaPVAyAhsD BQkJlCYABQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEFqy+vF7Fyvq0mkP/ius gsf6Z4/Tu+vHzBbl5i6oKI8ZieH8JfEgXx4ut9t7l3hBGC2r7DpR5A8zLMpEhGIK gFcHagksFkfLEE/FmWDfd1MysQafxBYrHaI27P2tkxfI5JYV6247TV39pQ93kGds tsjIrmh/zEJCVczoofxtz72BDt51H2Z8tN28F/YVHnbaGDwFEEzWKYpze87y/f36 ogcdGO6LDEEEIA6Ee0dGxleuKlLS4UDTt0zjo6L8TyiyPHp9C3+UfnP8837Zp3Fh KstIBd+vWgPdHFg2G5aDIYUvrj9UJBvVgaN/RnkwE+dab2OBSg5jkr141JLQvzdZ 4mOUXn5D9Y6AH6tvj0+ubYMV6j35L1/ZXncuXPVYiylcmDp/6f2WYcT3gx9CPUYA cLMjQV4vX2W8z4uEPyMlIJuGsLf7KhvLL8BQ6zlncT6eONfUUX9UJUCzqI5rqL5c b5jWGHeKvbLWRyQnlq5PXQxJTwYRm71rJTgzejc33LE6Nqg/Q25Dgwwsv+f+7i73 gB5loc80Fef+FV9VFGalFe0Yq8m0UASmkYRh7MH5ssoibpeWk+SGfBjOV4tnsAwR yjYLpAzxA8HeDcmlLeypGEDmsQ/iUvXoGaKOYX4Ieg8T/PCAplsqnJUOq8hbkgOC 98gLZfiltkNG8YhQpoZIHj6SxmBRSc3K99CvanuOiQIzBBABCAAdFiEEfhcKBFyE z0YOK3mgEO952f2DUxIFAlu3JJsACgkQEO952f2DUxJ4qRAAmbjiO3WTAeBCB4ME p2N2+XQCMTTFURDGuJnqU/+X//fhhPRq4V/OxgisKFKlBcAS2hsECvg6HDVSz4Fl 74fk/y+botG4/CjMLdKPB9fgh5zz72i3q0hWDixt50NKBv8IIVWOyYgZxDU/vcks lMEnqbFgJX+CfdALpvAM4WjuQP0UMcKNE3xd+EdDhD1xjK3Tq4XfWob9q6aBZgL2 B4IaADCIeDDE1hv0agnSJmMJE7Bti8tNxCCxVRbZtOaxVHXdRUoOx2XTaxFXupxV hbpHRrdFrwq51f6e3bkfkNEZ3fzYpnlbynJ2zL++JO8P3Pq/S6UKEFjEB50i8YgK WuFvGUsQ+YiDgiZU4saqxSBWbfYn3lY6MSSTg8RnXbFIMG3CFImqYk1uhaV+bDjc p0htjzM2F98g7c3o7sWx0bGarId4uhOmpj7JJVQ+lu7Jby6Ocj8n//7qF1Nn11Cw QlCVaeAq5Y5DmZrnww9I3zzOWWyqFkAVCM3GqeRLMvplD6/+O+5FF7XoHzQB47nk OyZtawy/9gssPWZKLv4qHLYS0wGGCiNbCsYy90s3pfeafM0kSxxjIvEz21KT6LJI /awu2ErQFWCkDMFJ1p/97MjPrQ/6d4cPO140V/wyfuWaBiTVqa9mgnb2zn6fYfDH JEvl1UzIx3JCae25tty1+qtnS0i0LlN0ZXBoZW4gRmFycmVsbCA8c3RlcGhlbkB0 b2xlcmFudG5ldHdvcmtzLmNvbT6JAj0EEwEIACcFAlo9UVoCGwMFCQmUJgAFCwkI BwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+o7HBAAxHAdFkBGZ9gJK8w7 NUYS9C6enGYtAYoKH5G3Bn3YScjErNfQtHYb53KwBQpVSOv1HcN8hbQ8mLTgn9lt zNwNSuv0XxIswi807HRSIZ4vYDiS5VKV1YkLYK5bLY5O4alVdzqM+AZQqkuHBu63 6n+C0ED6UwLhVBFfSNvBQVAdoq6gvr+IE8rCIKTMNGwNcgVPbF+YxP7UZM6p7s2a 5MIqGw7URSfaqfuztibXGOBLFbSwLGqHSSnOXBfEeDrwdZ+ur8cXIIPRIeCTVmeO 8bGgpgBqNQXG9oyGN+TrYAC+4Ahi0UjCk7QGj8tf3xICKoQpYyfceNBZJ/969gV9 tVgvRxUjxUwc9kZbi0c8XYMTq5GCvBIh1D6BOW9QBM2SsNgG3l36+e3+c2LDdyKn 20C1IzGLVDdcCtz42/onQ/e9sMlzFrfLjs5SO2/TnLvp2JtsIQXyb/T5qd0GE5j8 /iwfZR+uVTVVEsUl1a+Yllzt6sdR7RIhhKpKaKzEAk4d0+VHdz7zEkQRRSjbPVoS fy8c/kld9Fi8Buna+ZkKpcwIW+D4XP83pGcl0XUv6AyqwS1LnEt+jv/+PSXskYtU Lzn8Z35iKkSAH/5Nz6GCZk6ORPNv/6+UI92BpUbu/G2tBwK8bPgAg+gJxBx3G7MK W7VRCmM5UrtAK9A3O70VjPyMkHSJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLC LAf/X/9vRTZWtwSXxiBCA54a6hg9IvW0mvPUqgXfvrhtOk0IFucLKrTXK8J/NcmU 6ulxOovVbQ+Bin6gtHeCmSa/W523g/NXCOuFTnS/MyVibNL4+RCFwqGysl++Cm+L nj1MmasE9kO+CNdervx8APfxV7D6OYrG4eGag+LdFR6VpJn6tRT0/WvyT8l+Oqiq gdhXHv+0MvkkD9TX5LlJW4VB/yRvWkkmL5N5c5zYh+NcfTPhQ5S9dOorVzrm65d6 Itn0937Ennau7s7fiFdA0BHjWqEAFLsBIXQfCFjjKjdsKA4xlSiX7X7ElmPYpWa5 wwTQ66dL0anMd9y1DJCMOHe4gYkCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9 g1MSBQJbtyScAAoJEBDvedn9g1MSY7sP+gKR0rFU1g+GtB+hSdtwPRbacvml2eL2 Jc5Eq37J9hAqxHyt5V0If7s8IyVA2GXgdfwULBWbXGDUDiUkh20OPQRUS8G9Sf8A WRuG25q5C8ZzWygykL88RKXJZDFtA49CeqO5Bq5syBhq4QfiSTffQHIp3h0boPGU hSBEUQpooMXYQClNARQ+z/uRzR5bUi9wxdXNnxTn9ia4ASlaBPvUYTGY1jW2HrRR SwpI12+UaWsvc3jJtQ8X0kxgJ7jsFF1uqquIZ5eflQv+PHHg2RJSy37u0UFGb+OK ZEkzlmbPokKCYhzBR5PcD6sgdlaJNcidmto9u1oV6yZT8J2W4CTuUclgxt6f3lZq ZeVLnNnbHyKUdeypwLlqYISulfnMhZ3A6Bgpf2BtjL6KJbFtPBYmYdxI+HZyY49u U2ZHhRu+CSQ1y7zGKSX0gRp5hE7+A4XJtsT6lTLhbi9aiZTG1S6zKNhl3qNNzszc r27PrvFiyGhpuYQuzdQl2PMGbOI6Ojif3sab53NO3RLsLOM09wIlr95yKLlkXkUr WcvUJGrw6HKm8j5opXHTwmJOAbDpc6cMDu+ITRu4spdCnQJcE8RkO8tKyaLuh2Gt U5kYSBK97yr5VviX1FK6rY14LLmnE16OPiK2tiVBKy9nGM0DKtY+K9WcoRZ7s/d7 O0bMfzcNPtGLuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiez GPuBHmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9Wf pHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC 6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2 D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFe A7PbTuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ /Vf3vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbpt PEcmoazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKr em5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96 Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYgh x8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQ oqj1gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P /1tF6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8 Wpfdn3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJ gx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5 SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2 oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIA ypqYo3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoM eDQkd0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS /qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZ IMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XO KVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DJ121 -----END PGP PUBLIC KEY BLOCK----- --------------661903C97DF338D46D1232C0-- --x17cgioUWFXWkDnrQpVl8LGAwy0SS5dB4-- --6NkQ6iTVmfRAMMcA0nBUMcTtjLlKEpEu8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlxlysgACgkQWrL68XsX K+qSRg//UI2U+ov4W/SPdQbdFPrHkD7Wyi7l/P7ARB9kKPGWipWO6NNGv2fitITv kP9/EAdmhi2gxgyXi+hyw7kGb4qY1luiAR5qig0Cu77lKm28of8Fwtf9CHGxdxh2 VgjXGzXx1UPkhIJyIyLIShHWOfGDp49zHc1R52H9B3sS54A3BqXG1AuEr+Vstksq 9I/lGaCu7l2Oa6dAXxeQRf10XVqEkLDc0NkRrosqlcSSUrL/Au6rZS7ogRUZti+b bJyUNFQVTPb/Hbm8iZbTqUgasWeDXIfVBY61x2S5axzZO5IAb1o3o3tgmQ4UH8R+ QNpu5v0Xp4k/yLOmqsBKu0jtF9szxo5gHQ572M35DjkJ/DfzbDDAUHXC47hvrBi5 RkBclv5niNuqluDmPbj5ChaP8vHoFQE8TnabrZm2FFhZPB6EN9LRch15XYW6My43 SSS02kDe4z9jjSXLOQcN0tKmOY19f3PoFWqJ+A3wTF7IZsCA26S9NZPgVL+MxB04 vuq3DVkRSVSDbis1k8tuyGqRLDWNFsYiYidGkA9a87/Gp7ee+1tl1iZd0RSBc/NJ SQjJDccxN9sMobkAiJ+XAtXgw727WL3jgqCf9fQ/aneDE6WetjXcZnFVzQD6fzdE iqTJHY/WyxQqmRYNy3O/hlpXr2anAam6aYIk/f5VSj5NxR2Xp20= =QbFz -----END PGP SIGNATURE----- --6NkQ6iTVmfRAMMcA0nBUMcTtjLlKEpEu8-- From nobody Thu Feb 14 12:13: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 0F1D612867A for ; Thu, 14 Feb 2019 12:13:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.499 X-Spam-Level: X-Spam-Status: No, score=-9.499 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, URIBL_BLOCKED=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 ssC0gVLu2Jak for ; Thu, 14 Feb 2019 12:13:25 -0800 (PST) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 069F3128D52 for ; Thu, 14 Feb 2019 12:13:25 -0800 (PST) Received: by mail-qk1-x732.google.com with SMTP id i5so4356083qkd.13 for ; Thu, 14 Feb 2019 12:13:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ljgc82odNCC8dxeP/iudbHGB8gu5KqhLTGGvlJGhflM=; b=B9EZ4oFvYYSrcRoFEMnuMG17Z5qmaEH9kcYWxBar3831x4PbVuyi3QvzcP4i2AMiyF Orft/I+PZw5hGhy4THhROW7i7GRBAQI5rw0AWsQz3cytegZ4CZYdsT0xHsjezMbAemEI YVNIDpLBvVDjlZN6FGpxjK1R2hy427euh2jxU= 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=ljgc82odNCC8dxeP/iudbHGB8gu5KqhLTGGvlJGhflM=; b=eDpzow/gYc5allewyzz1aIeueUZDSMvngYq1nf8+V7bsCsMd/fh19VibNYieJSNVId t4D9sdTziT3RrqE82BbR8eDTHFsGHjXzMJ8SQzF6uiW+AvI2TiLYIwt3xj5sw+znB/Ji P1i3BqOVD5AKzpsU6t+6riCx8s/K0lhStfroZdjz1CEIT3gEw0SW7SoRiZa9jmLkstFo Letze0o0DxgvSERLHVVJub+FKl26YXWXfypJnIunccuvknCvyp76J8Ntc60OyTuUtiL2 veS/gmGF8mL/YXVfZCkV4H97zNuy6rrn5cLtF+RNqLBtL04UnsqPizu7fjv6c2fy5tDW tBPg== X-Gm-Message-State: AHQUAubo/Q0p7LHrj+SvJEomHq8E/c6v/2bZnyJGa7//iQDIjRmbzVFa bi6EhAyvYqvxadn4ZtvnCI3/4HIhlagDKAIdpgHY X-Google-Smtp-Source: AHgI3IaNttCxAqVV17yoBcNLpm1BQ4T+HHVfRmC6jPG5bp+i/la+6CgzPnnOUzK+gAvq7Xzen6+2d3MOtUJvVU3NQTQ= X-Received: by 2002:a37:98c6:: with SMTP id a189mr4167106qke.31.1550175203859; Thu, 14 Feb 2019 12:13:23 -0800 (PST) MIME-Version: 1.0 References: <714E43FA-3660-485A-8E50-04EE43F8DA2E@gmail.com> <168e9a61d1e.cce5c9ea206228.28832954982140191@nerd.ninja> <168ed8bb0f5.1026877c920218.3245439195642672251@nerd.ninja> In-Reply-To: <168ed8bb0f5.1026877c920218.3245439195642672251@nerd.ninja> From: David Benjamin Date: Thu, 14 Feb 2019 14:13:11 -0600 Message-ID: To: Roelof DuToit Cc: Christopher Wood , TLS WG Content-Type: multipart/alternative; boundary="0000000000005e0ce90581e04a19" Archived-At: Subject: Re: [TLS] ESNI PRs #124 and #125: Improving ESNI Robustness and GREASE 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, 14 Feb 2019 20:13:28 -0000 --0000000000005e0ce90581e04a19 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Feb 14, 2019 at 1:46 PM Roelof DuToit wrote: > > > > ---- On Thu, 14 Feb 2019 13:00:16 -0500 *David Benjamin > >* wrote ---- > > On Wed, Feb 13, 2019 at 7:37 PM Roelof DuToit wrote: > >> >> Questions for PR [1]: >> >> * Regarding this text: >> The client MUST NOT use the server-provided retry keys until the >> handshake completes successfully. On success, it MUST NOT overwrite the >> DNS-provided keys with the retry keys. It MUST use the retry keys at mos= t >> once and continue offering DNS-provided keys for subsequent connections. >> This avoids introducing a tracking vector, should a malicious server >> present client-specific retry keys. >> >> .. specifically this part: ".. use the retry keys at most once". >> Q1: Are you saying the client should persistently remember which >> public_name values triggered retry keys? For how long? >> > > No, exactly the opposite. You use the retry key for just the retry and > then forget about it. > https://mailarchive.ietf.org/arch/msg/tls/xBEHe1_CcYEYinZQHxWGq8vjA0Q > > > I understood that part. Let my clarify my question with an example: > > A1. Client uses DNS-provided keys, and server returns retry keys > A2. Client uses retry keys, and everything works.. > A3. Client restarts > A4. Client uses DNS-provided keys, and server returns the same retry keys > as in A1 > A5. Client violates spec by using those retry keys for a second time? > > And what about this example: > > B1. Client uses DNS-provided keys, and server returns retry keys > B2. Client uses retry keys, and everything works.. > B3. Client uses DNS-provided keys, and server returns retry keys > B4. Client violates spec by using those retry keys for a second time? > Oh, I see. Yeah, that's just a mistake in the text. A5 and B4 aren't meant to be violations, since the client saw the retry keys again. I'll wordsmith that too in the next iteration. > > > >> Q2: What happens if fronting server A sent retry keys, and the subsequen= t >> transport connection ends up on server B, which also sends retry keys? >> > > You keep retrying. And hen you hit the text which says: > > > Clients SHOULD implement a limit on retries caused by > "esni_retry_request" or > > servers which do not acknowledge the "encrypted_server_name" extension. > > This is an error-correcting mechanism to avoid deployment risks. If your > TLS deployment is so out of sync with itself that: > > - It deployed ESNI keys in the DNS that your servers do not understand. > - Even on a retry to presumably the same IP address, you hit a different > server node. > - Your load balancer keeps bouncing between different server nodes > connections right after each other. > - Each of your server nodes believes in a totally disjoint set of ESNI > keys. > > Then I think giving up and failing the connection is not the end of the > world. > > > >> >> --Roelof >> >> >> ---- On Wed, 13 Feb 2019 17:15:57 -0500 *Christopher Wood >> >* wrote ---- >> >> >> Hi folks, >> >> PRs [1] and [2] need a little more review before we merge since >> they=E2=80=99re non-trivial changes. Please have a look and let the list= know >> if you have objections with the contents therein. Otherwise, we will >> merge them by the end of the next week. >> >> Thanks! >> Chris (no hat) >> >> [1] https://github..com/tlswg/draft-ietf-tls-esni/pull/124 >> >> >> [2] https://github.com/tlswg/draft-ietf-tls-esni/pull/125 >> >> _______________________________________________ >> 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 >> > > --0000000000005e0ce90581e04a19 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, Feb 14, 2019 at 1:46 PM Roelof DuToit <r@nerd.ninja&g= t; wrote:

---- On Thu, 14 Feb 2019 13:00:16 -0500=C2= =A0David Benjamin <davidben@chromium.org> wrote ----
=

On Wed, Feb 13, 2019 at 7:37 PM= Roelof DuToit <r@nerd= .ninja> wrote:
=

Questions for PR [1]:

<= /div>
* Regarding this text:
The client M= UST NOT use the server-provided retry keys until the handshake completes su= ccessfully. On success, it MUST NOT overwrite the DNS-provided keys with th= e retry keys. It MUST use the retry keys at most once and continue offering= DNS-provided keys for subsequent connections. This avoids introducing a tr= acking vector, should a malicious server present client-specific retry keys= .

.. specifically = this part: ".. use the retry keys at most once".=C2=A0
=
Q1: Are you saying the client should persistently remember which publi= c_name values triggered retry keys?=C2=A0 For how long?

No, exactly the opposite. You use the re= try key for just the retry and then forget about it.
=
=

I understood that part.=C2=A0 =C2=A0Let my clarify my q= uestion with an example:

A1. Client uses DNS-p= rovided keys, and server returns retry keys
A2. Client uses r= etry keys, and everything works..
A3. Client restarts
A4. Client uses DNS-provided keys, and server returns the same retry= keys as in A1
A5. Client violates spec by using those retry = keys for a second time?

And what about this exampl= e:

B1. Client uses DNS-provided keys, and serv= er returns retry keys
B2. Client uses retry keys, and everyth= ing works..
B3. Client uses DNS-provided keys, and server ret= urns retry keys
B4. Client violates spec by using those retry key= s for a second time?

Oh, = I see. Yeah, that's just a mistake in the text. A5 and B4 aren't me= ant to be violations, since the client saw the retry keys again. I'll w= ordsmith that too in the next iteration.
=C2=A0



Q2: What happens if fronting server A sent retry ke= ys, and the subsequent transport connection ends up on server B, which also= sends retry keys?

Yo= u keep retrying. And hen you hit the text which says:

> Clients SHOULD implement a limit on retries caused by &qu= ot;esni_retry_request" or
> servers which do not ackn= owledge the "encrypted_server_name" extension.

This is an error-correcting mechanism to avoid deployment = risks. If your TLS deployment is so out of sync with itself that:
=

- It deployed ESNI keys in the DNS that your servers do= not understand.
- Even on a retry to presumably the same IP = address, you hit a different server node.
- Your load balance= r keeps bouncing between different server nodes connections right after eac= h other.
- Each of your server nodes believes in a totally di= sjoint set of ESNI keys.

Then I think giving u= p and failing the connection is not the end of the world.
=C2=A0

--Roelof


---- On Wed, 13 Feb 2019 17:15:57 -0500=C2=A0Christopher Wood <christopherwoo= d07@gmail.com> wrote ----


Hi folks,

PRs [1] and [2] nee= d a little more review before we merge since
they=E2=80=99re= non-trivial changes. Please have a look and let the list know
if you have objections with the contents therein. Otherwise, we will
merge them by the end of the next week.

Thanks!
Chris (no hat)

=

--0000000000005e0ce90581e04a19-- From nobody Thu Feb 14 12:25: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 DF7DE13118D for ; Thu, 14 Feb 2019 12:25:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=nerd.ninja Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbhiLE6ww3hc for ; Thu, 14 Feb 2019 12:25:24 -0800 (PST) Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DCB71311EA for ; Thu, 14 Feb 2019 12:25:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550175914; cv=none; d=zoho.com; s=zohoarc; b=LOXFnxSBGDQKZSEKmbfCYYheBykem+JKKq6EXYuiV78EUOfl1mWVH9pNrULopE7y+28OCwtMpXUVNDLoJG33AR9GDZEAtrIZeEmMGvg0rE/aBzDQ5wC86oP/yxZ9SmUYGeOspxrTjsyxvAJXPI7Br87J7vnzg6WTHrQucNXi8bg= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1550175914; h=Content-Type:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results; bh=ypP9VBNSDzuy7NOdIhbiDuiCXV45zR7mj4qCuyvnRho=; b=SQ3x81ES9v2dLoSYoPH41h+bkxXa1GkeLtLohUVtENv6zA2Qk/dxnqCMlLtERiOp6DDPfjUSjMAnngLgMMi/em5vGPnaAAelo3zWpN3cStmWbtXAXwWBemGRUKMX1pEZi5PpMICefkaFHbAMXweysqK9Sl4VXinHyXNYKGPCXAI= ARC-Authentication-Results: i=1; mx.zoho.com; dkim=pass header.i=nerd.ninja; spf=pass smtp.mailfrom=r@nerd.ninja; dmarc=pass header.from= header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1550175914; s=zoho; d=nerd.ninja; i=r@nerd.ninja; h=Date:From:To:Cc:Message-Id:In-Reply-To:References:Subject:MIME-Version:Content-Type; l=15506; bh=ypP9VBNSDzuy7NOdIhbiDuiCXV45zR7mj4qCuyvnRho=; b=pVR6YvLXnPPaZYi1W6198GQESwEwt9KXf7kziTXjTmVNH8zqMmM6fl/vdriFSsfw tvNrbGtBwdkpwOgl+t1du1+AB/aNkfnng8apFE+/fRGAm0Yd3A9VruypxIua6TDdTd4 4QGgjWbGxCh68FJioz41NOxfeBuLdE4nda7p/uUc= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1550175908407321.3607987078998; Thu, 14 Feb 2019 12:25:08 -0800 (PST) Date: Thu, 14 Feb 2019 15:25:08 -0500 From: Roelof DuToit To: "David Benjamin" Cc: "Christopher Wood" , "TLS WG" Message-Id: <168edaf3233.104d73d5e24703.2816492539373755558@nerd.ninja> In-Reply-To: References: <714E43FA-3660-485A-8E50-04EE43F8DA2E@gmail.com> <168e9a61d1e.cce5c9ea206228.28832954982140191@nerd.ninja> <168ed8bb0f5.1026877c920218.3245439195642672251@nerd.ninja> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_80932_982993558.1550175908403" X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail Archived-At: Subject: Re: [TLS] ESNI PRs #124 and #125: Improving ESNI Robustness and GREASE 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, 14 Feb 2019 20:25:28 -0000 ------=_Part_80932_982993558.1550175908403 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ---- On Thu, 14 Feb 2019 15:13:11 -0500=C2=A0David Benjamin wrote ---- On Thu, Feb 14, 2019 at 1:46 PM Roelof DuToit wrote: ---- On Thu, 14 Feb 2019 13:00:16 -0500=C2=A0David Benjamin wrote ---- On Wed, Feb 13, 2019 at 7:37 PM Roelof DuToit wrote: Questions for PR [1]: * Regarding this text: The client MUST NOT use the server-provided retry keys until the handshake = completes successfully. On success, it MUST NOT overwrite the DNS-provided = keys with the retry keys. It MUST use the retry keys at most once and conti= nue offering DNS-provided keys for subsequent connections. This avoids intr= oducing a tracking vector, should a malicious server present client-specifi= c retry keys. .. specifically this part: ".. use the retry keys at most once".=C2=A0=20 Q1: Are you saying the client should persistently remember which public_nam= e values triggered retry keys?=C2=A0 For how long? No, exactly the opposite. You use the retry key for just the retry and then= forget about it. https://mailarchive.ietf.org/arch/msg/tls/xBEHe1_CcYEYinZQHxWGq8vjA0Q I understood that part.=C2=A0 =C2=A0Let my clarify my question with an exam= ple: A1. Client uses DNS-provided keys, and server returns retry keys A2. Client uses retry keys, and everything works.. A3. Client restarts A4. Client uses DNS-provided keys, and server returns the same retry keys a= s in A1 A5. Client violates spec by using those retry keys for a second time? And what about this example: B1. Client uses DNS-provided keys, and server returns retry keys B2. Client uses retry keys, and everything works.. B3. Client uses DNS-provided keys, and server returns retry keys B4. Client violates spec by using those retry keys for a second time? Oh, I see. Yeah, that's just a mistake in the text. A5 and B4 aren't meant = to be violations, since the client saw the retry keys again. I'll wordsmith= that too in the next iteration. Could a MITM (the kind that can finish the handshake) set esni_retry_reques= t every time it sees an unknown record_digest in the ESNI extension, and es= sentially use the retry mechanism to subvert the intent of ESNI? =C2=A0 Q2: What happens if fronting server A sent retry keys, and the subsequent t= ransport connection ends up on server B, which also sends retry keys? You keep retrying. And hen you hit the text which says: > Clients SHOULD implement a limit on retries caused by "esni_retry_request= " or > servers which do not acknowledge the "encrypted_server_name" extension. This is an error-correcting mechanism to avoid deployment risks. If your TL= S deployment is so out of sync with itself that: - It deployed ESNI keys in the DNS that your servers do not understand. - Even on a retry to presumably the same IP address, you hit a different se= rver node. - Your load balancer keeps bouncing between different server nodes connecti= ons right after each other. - Each of your server nodes believes in a totally disjoint set of ESNI keys= . Then I think giving up and failing the connection is not the end of the wor= ld. =C2=A0 --Roelof ---- On Wed, 13 Feb 2019 17:15:57 -0500=C2=A0Christopher Wood wrote ---- Hi folks, PRs [1] and [2] need a little more review before we merge since=20 they=E2=80=99re non-trivial changes. Please have a look and let the list kn= ow=20 if you have objections with the contents therein. Otherwise, we will=20 merge them by the end of the next week. Thanks! Chris (no hat) [1] https://github.com/tlswg/draft-ietf-tls-esni/pull/124 [2] https://github.com/tlswg/draft-ietf-tls-esni/pull/125 _______________________________________________ TLS mailing list mailto:TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list mailto:TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls ------=_Part_80932_982993558.1550175908403 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =



---- On Thu, 14 Feb 2019 15:13:11 -0500&n= bsp;David Benjamin <davidben@chromium.org> wrote ----


<= div class=3D"gmail_quote">
On Thu, Feb= 14, 2019 at 1:46 PM Roelof DuToit <r@nerd.ninja> wrote:




---- On Thu, 14 Feb 2019 13:00:16 -0500 David Benja= min <davidben= @chromium.org> wrote ----
=

On Wed, Feb 13, 2019 at 7:37 PM Roelof = DuToit <r@nerd.ninja> wrote:
<= div>

<= div style=3D"font-size: 10pt; font-family: Verdana, Arial, Helvetica, sans-= serif">


=
I understood that part.   Let my clarify my question w= ith an example:

A1. Client uses DNS-provided k= eys, and server returns retry keys
A2. Client uses retry keys= , and everything works..
A3. Client restarts
A4= . Client uses DNS-provided keys, and server returns the same retry keys as = in A1
A5. Client violates spec by using those retry keys for = a second time?

And what about this example:

B1. Client uses DNS-provided keys, and server re= turns retry keys
B2. Client uses retry keys, and everything w= orks..
B3. Client uses DNS-provided keys, and server returns = retry keys
B4. Client violates spec by using those retry keys= for a second time?

O= h, I see. Yeah, that's just a mistake in the text. A5 and B4 aren't meant t= o be violations, since the client saw the retry keys again. I'll wordsmith = that too in the next iteration.

Could a MITM (the kind that can finish the handshake= ) set esni_retry_request every time it sees an unknown record_digest in the= ESNI extension, and essentially use the retry mechanism to subvert the int= ent of ESNI?



 



Q2: What happens if fronting= server A sent retry keys, and the subsequent transport connection ends up = on server B, which also sends retry keys?

You keep retrying. And hen you hit the text which says= :

> Clients SHOULD implement a limit o= n retries caused by "esni_retry_request" or
> servers whic= h do not acknowledge the "encrypted_server_name" extension.
=

This is an error-correcting mechanism to avoid deployme= nt risks. If your TLS deployment is so out of sync with itself that:

- It deployed ESNI keys in the DNS that your servers= do not understand.
- Even on a retry to presumably the same = IP address, you hit a different server node.
- Your load bala= ncer keeps bouncing between different server nodes connections right after = each other.
- Each of your server nodes believes in a totally= disjoint set of ESNI keys.

Then I think givin= g up and failing the connection is not the end of the world.
=
 

--Roelof


---- On Wed, 13 Feb 2019 17:15:57 -0500 Christoph= er Wood <christopherwood07@gmail.com> wrote ----

=
Hi folks,
=
PRs [1] and [2] need a little more review before we merge si= nce
they=E2=80=99re non-trivial changes. Please have a look = and let the list know
if you have objections with the conten= ts therein. Otherwise, we will
merge them by the end of the = next week.

Thanks!
Chris (no hat= )


____= ___________________________________________
TLS mailing list<= br>
____________________________________= ___________
TLS mailing list



------=_Part_80932_982993558.1550175908403-- From nobody Thu Feb 14 12:40: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 D7F061311A8 for ; Thu, 14 Feb 2019 12:40:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.499 X-Spam-Level: X-Spam-Status: No, score=-9.499 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, URIBL_BLOCKED=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 Yl6NNzSoTuGX for ; Thu, 14 Feb 2019 12:40:37 -0800 (PST) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F3271311BF for ; Thu, 14 Feb 2019 12:40:37 -0800 (PST) Received: by mail-qt1-x82c.google.com with SMTP id p48so8501424qtk.2 for ; Thu, 14 Feb 2019 12:40:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zv5FOSXIr/5qJG+z85rcm+jzpu+60TLP0taG6r9NKzs=; b=g3cKUZxaM4KeBbfzt4yEwbXHmI/4LLsgM6S3hSKetLYGayjfSPkJkWoS3CO2AHsXqc Lzp6jSBwFrB2tK/ijkL+hPjc2N8x9pJGXmY1BDHKVgPRVOOClmEAk9CxlqYF58B6Hv3Z rWfoipuwWkYtPMaHqAniEZy7W9IgQ/l3h04as= 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=zv5FOSXIr/5qJG+z85rcm+jzpu+60TLP0taG6r9NKzs=; b=FJAKGc/uzTV2bKT4+ryA+Ha2oNwDW7995cjp/WgXTuLZVaBWTUp1tU9LB1WgiavMbg DwD6I99SB0wTnI3DAFGXvOigFXayn9NgmYlZKRLcLQRKqAarqQ8fgjU7kp/ScaGDati5 vVhqhyxZpuJnW+BpkCjFantMIYgFuXqHrVDA2vj2kpFKVl9BkJA8mNd8ycBDTuxGj6Fp Y7QYcfSRk47eQ1xTSqj1Y5Vvh9SFWixz7FHb04LhL1NEzSpQgKXXtn2wLHf9Jc4sbAqs iwcTbYIkV3gqNI/21JfLKi5w8Nr1/NvjeC+DRZIMNgTxqIDaiu77ZuT9ykQu3nwE0d7X mMDQ== X-Gm-Message-State: AHQUAuZn75nmMm/Az3OFjdXYZgDCYOlZvXU5RQrfa3QH2ajJvtD6Hilb 7EDJwGB90R3gZrHs/rLpjYqRwObgiNaOqAC3oYEu X-Google-Smtp-Source: AHgI3IaLtcXKNj7pWN1JD6+SZRtvPegXtA8jWuWC8oTHL5jHK72Nq1dHjIfy44Gutqd5SJ1HmnYygMCA+5rhdnC360g= X-Received: by 2002:a0c:c584:: with SMTP id a4mr4480791qvj.227.1550176836428; Thu, 14 Feb 2019 12:40:36 -0800 (PST) MIME-Version: 1.0 References: <714E43FA-3660-485A-8E50-04EE43F8DA2E@gmail.com> <168e9a61d1e.cce5c9ea206228.28832954982140191@nerd.ninja> <168ed8bb0f5.1026877c920218.3245439195642672251@nerd.ninja> <168edaf3233.104d73d5e24703.2816492539373755558@nerd.ninja> In-Reply-To: <168edaf3233.104d73d5e24703.2816492539373755558@nerd.ninja> From: David Benjamin Date: Thu, 14 Feb 2019 14:40:25 -0600 Message-ID: To: Roelof DuToit Cc: Christopher Wood , TLS WG Content-Type: multipart/alternative; boundary="000000000000ad181f0581e0ab60" Archived-At: Subject: Re: [TLS] ESNI PRs #124 and #125: Improving ESNI Robustness and GREASE 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, 14 Feb 2019 20:40:46 -0000 --000000000000ad181f0581e0ab60 Content-Type: text/plain; charset="UTF-8" On Thu, Feb 14, 2019 at 2:25 PM Roelof DuToit wrote: > ---- On Thu, 14 Feb 2019 15:13:11 -0500 *David Benjamin > >* wrote ---- > > On Thu, Feb 14, 2019 at 1:46 PM Roelof DuToit wrote: > >> ---- On Thu, 14 Feb 2019 13:00:16 -0500 *David Benjamin >> >* wrote ---- >> >> On Wed, Feb 13, 2019 at 7:37 PM Roelof DuToit wrote: >> >>> >>> Questions for PR [1]: >>> >>> * Regarding this text: >>> The client MUST NOT use the server-provided retry keys until the >>> handshake completes successfully. On success, it MUST NOT overwrite the >>> DNS-provided keys with the retry keys. It MUST use the retry keys at most >>> once and continue offering DNS-provided keys for subsequent connections. >>> This avoids introducing a tracking vector, should a malicious server >>> present client-specific retry keys. >>> >>> .. specifically this part: ".. use the retry keys at most once". >>> Q1: Are you saying the client should persistently remember which >>> public_name values triggered retry keys? For how long? >>> >> >> No, exactly the opposite. You use the retry key for just the retry and >> then forget about it. >> https://mailarchive.ietf.org/arch/msg/tls/xBEHe1_CcYEYinZQHxWGq8vjA0Q >> >> >> >> I understood that part. Let my clarify my question with an example: >> >> A1. Client uses DNS-provided keys, and server returns retry keys >> A2. Client uses retry keys, and everything works.. >> A3. Client restarts >> A4. Client uses DNS-provided keys, and server returns the same retry keys >> as in A1 >> A5. Client violates spec by using those retry keys for a second time? >> >> And what about this example: >> >> B1. Client uses DNS-provided keys, and server returns retry keys >> B2. Client uses retry keys, and everything works.. >> B3. Client uses DNS-provided keys, and server returns retry keys >> B4. Client violates spec by using those retry keys for a second time? >> > > Oh, I see. Yeah, that's just a mistake in the text. A5 and B4 aren't meant > to be violations, since the client saw the retry keys again. I'll wordsmith > that too in the next iteration. > > > Could a MITM (the kind that can finish the handshake) set > esni_retry_request every time it sees an unknown record_digest in the ESNI > extension, and essentially use the retry mechanism to subvert the intent of > ESNI? > It would need to be able to authenticate as the public name for the client to pay any attention to this. The public name is the name of the entity trusted to update the ESNI keys. (Presumably the name of the hosting provider or so.) The point is to give a secure retry signal, in hopes of getting both deployability and security. David --000000000000ad181f0581e0ab60 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Feb 14, 2019 at 2:25 PM Roelof DuToit <r@nerd.ninja> w= rote:
---- On Thu, 14 Feb 2019 15:13= :11 -0500=C2=A0David Benjamin <davidben@chromium.org> wrote ----
On Thu, Feb 14, 2019 at 1:46 PM Roelof = DuToit <r@nerd.ninja> wrote:
=
On Wed, Feb 13, 2019 at 7:37 PM Roelof DuToit &= lt;r@nerd.ninja> w= rote:

=
Questions for PR [1]:

* Rega= rding this text:
The client MUST NOT use the serv= er-provided retry keys until the handshake completes successfully. On succe= ss, it MUST NOT overwrite the DNS-provided keys with the retry keys. It MUS= T use the retry keys at most once and continue offering DNS-provided keys f= or subsequent connections. This avoids introducing a tracking vector, shoul= d a malicious server present client-specific retry keys.

.. specifically this part: ".. = use the retry keys at most once".=C2=A0
Q1: Are you say= ing the client should persistently remember which public_name values trigge= red retry keys?=C2=A0 For how long?
=
No, exactly the opposite. You use the retry key for just the= retry and then forget about it.


=
I understood that part.=C2=A0 =C2=A0Let my clarify my question w= ith an example:

A1. Client uses DNS-provided k= eys, and server returns retry keys
A2. Client uses retry keys= , and everything works..
A3. Client restarts
A4= . Client uses DNS-provided keys, and server returns the same retry keys as = in A1
A5. Client violates spec by using those retry keys for = a second time?

And what about this example:

B1. Client uses DNS-provided keys, and server re= turns retry keys
B2. Client uses retry keys, and everything w= orks..
B3. Client uses DNS-provided keys, and server returns = retry keys
B4. Client violates spec by using those retry keys= for a second time?

O= h, I see. Yeah, that's just a mistake in the text. A5 and B4 aren't= meant to be violations, since the client saw the retry keys again. I'l= l wordsmith that too in the next iteration.

Could a MITM (the kind that c= an finish the handshake) set esni_retry_request every time it sees an unkno= wn record_digest in the ESNI extension, and essentially use the retry mecha= nism to subvert the intent of ESNI?

=
It would need to be able to authenticate as the public name for = the client to pay any attention to this. The public name is the name of the= entity trusted to update the ESNI keys. (Presumably the name of the hostin= g provider or so.)

The point is to give a secure r= etry signal, in hopes of getting both deployability and security.

David
--000000000000ad181f0581e0ab60-- From nobody Thu Feb 14 22:36: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 862DD130F94 for ; Thu, 14 Feb 2019 22:36:53 -0800 (PST) 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 9XeqHT2ci689 for ; Thu, 14 Feb 2019 22:36:50 -0800 (PST) Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 707B1130F8E for ; Thu, 14 Feb 2019 22:36:50 -0800 (PST) Received: by mail-ot1-x32c.google.com with SMTP id 98so14920898oty.1 for ; Thu, 14 Feb 2019 22:36:50 -0800 (PST) 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=stOUEM+Fjbx/GBedyiUsKBu5Jcn8FkMEf4qG5or5Ttk=; b=fL1tVOFrFXYZcnifbyctRSzfIf4E5Tu04tqb7px9TQvNnOmWTEO0acIMQZz1xpiK5d 6yDn9WNBXL1hWMWLO3eFuBME4ZHky/NvePSOSiuC3cK8TENT88cAxbMkZ1vbMEGJJPOh MbIflF6L+P83PJcuFtZu3qyg8VxFPwqXVajLbc+aSIU7HUz1QVMXcfWqD0DvG9mOrcXs 3ytgNtm5P/mhW72RwTi8P4Sn4u/2WQSAl6s6RRmzwCmJ4ikGLPLmdUZQxh8EWoRZrdFu oUNlv213M0qj1ZlZ5WxsDcJ/1QdNX3daHZ1KmpdNI+WH6+LMz9KYFn6hpucan3SElEwW /oQQ== 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=stOUEM+Fjbx/GBedyiUsKBu5Jcn8FkMEf4qG5or5Ttk=; b=CQAHQ2S3K+5hf2smPHv3uMtag1rtmy3Zuwhexa6Y+g8IjKYeYGNKiq3kXLOPFAQP4o HndqEoxAO+TrTZDSacE9eNErzfcRcCG2ym7a0ylj0YKUmeso8SocT9zXd/isXrB9wNj3 O1tKjsY9stlfeGe+ogkrHWGKad6pAlK3ett/Ey4SBTDjth2FjkFcmu00JhFILTV5Pgm1 LA3kpzh829ifuB7I9cVHEbzCmu+dm39aJffa6p1LnxwC8o7FOH+9w+jFCK1k8xGqjIBW pGd1Fs4kLC4RR/GrSHuiC+V0q5XgKHqfEh8nAMfTd3StKfAAkXn2iECQUxO15thwOGVI 6Aig== X-Gm-Message-State: AHQUAuYT/o7a5Q+1REym7ZfUk2Mj5R3Ffy0gKz63C0KNchLra5CR+R5w j53OW8B7usJP58abczDW0lGM/jQPLChZ3Z6EO4+z4zN6 X-Google-Smtp-Source: AHgI3IaEU2gt18fGSq6biq73EwwoJOSaHCPl0yVyeq9qZA0LN/YNvRv1ViV9tB321NaVboANhikxipiy7Jd0toOqwWM= X-Received: by 2002:aca:eb01:: with SMTP id j1mr4678905oih.165.1550212609168; Thu, 14 Feb 2019 22:36:49 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Sankalp Bagaria Date: Fri, 15 Feb 2019 12:04:36 +0530 Message-ID: To: tls@ietf.org Cc: Balaji R Content-Type: multipart/alternative; boundary="000000000000e55b300581e8ffa3" Archived-At: Subject: Re: [TLS] Call for Adoption: TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key 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, 15 Feb 2019 06:36:54 -0000 --000000000000e55b300581e8ffa3 Content-Type: text/plain; charset="UTF-8" Hi, I support the adoption of this draft. I would like to see it develop.. Thanks, Sankalp Bagaria. > > > Message: 3 > Date: Mon, 11 Feb 2019 08:40:41 -0800 > From: "Peter Yee" > To: "'Christopher Wood'" , > Subject: Re: [TLS] Call for Adoption: TLS 1.3 Extension for > Certificate-based Authentication with an External Pre-Shared Key > Message-ID: <097d01d4c228$872ef930$958ceb90$@akayla.com> > Content-Type: text/plain; charset="UTF-8" > > I support adoption of this draft and am willing to review it. > > -Peter > > -----Original Message----- > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Christopher Wood > Sent: Sunday, February 10, 2019 1:40 PM > To: > Subject: Re: [TLS] Call for Adoption: TLS 1.3 Extension for > Certificate-based Authentication with an External Pre-Shared Key > > Given the low amount of responses, we?re going to extend this adoption > call for another two weeks. As a reminder, if you would like for this > draft to become a WG document and you are willing to review it as it > moves through the process, then please let the list know by 2359UTC > 20180222. If you are opposed to this being a WG document, please say > so (and say why). > > Thanks, > Chris, Joe, and Sean > > On Fri, Feb 8, 2019 at 8:58 AM Eric Rescorla wrote: > > > > I'd like to hear from some people who plan to implement and deploy this. > Absent that, I'm not sure we should adopt it. Code points are free, so it > doesn't need to be a TLS WG item unless the TLS WG and community are going > to do substantial work on it. > > > > -Ekr > > > > > > On Fri, Jan 25, 2019 at 10:12 AM Christopher Wood < > christopherwood07@gmail.com> wrote: > >> > >> At the TLS@IETF103 session, there was interest in adopting > >> draft-housley-tls-tls13-cert-with-extern-psk as an experimental WG > >> item, provided that it's limited to external PSKs with certificates > >> for the initial handshake. This email is to determine whether there is > >> WG consensus to adopt this draft (as is) as a WG item. > >> > >> If you would like for this draft to become a WG document and you are > >> willing to review it as it moves through the process, then please let > >> the list know by 2359UTC 20180208. If you are opposed to this being a > >> WG document, please say so (and say why). > >> > >> 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 > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > ------------------------------ > > End of TLS Digest, Vol 175, Issue 5 > *********************************** > --000000000000e55b300581e8ffa3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

= I support the adoption of this draft.=C2=A0
I would like to see i= t develop..

Thanks,
Sankalp Bagaria.=C2= =A0




Message: 3
Date: Mon, 11 Feb 2019 08:40:41 -0800
From: "Peter Yee" <peter@akayla.com>
To: "'Christopher Wood'" <christopherwood07@gmail.com>, &= lt;tls@ietf.org> Subject: Re: [TLS] Call for Adoption: TLS 1.3 Extension for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Certificate-based Authentication with an Extern= al Pre-Shared Key
Message-ID: <097d01d4c228$872ef930$958ceb90$@akayla.com>
Content-Type: text/plain;=C2=A0 =C2=A0 =C2=A0 =C2=A0charset=3D"UTF-8&q= uot;

I support adoption of this draft and am willing to review it.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -Peter

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Christopher Wood
Sent: Sunday, February 10, 2019 1:40 PM
To: <tls@ietf.org&= gt;
Subject: Re: [TLS] Call for Adoption: TLS 1.3 Extension for Certificate-bas= ed Authentication with an External Pre-Shared Key

Given the low amount of responses, we?re going to extend this adoption
call for another two weeks. As a reminder, if you would like for this
draft to become a WG document and you are willing to review it as it
moves through the process, then please let the list know by 2359UTC
20180222. If you are opposed to this being a WG document, please say
so (and say why).

Thanks,
Chris, Joe, and Sean

On Fri, Feb 8, 2019 at 8:58 AM Eric Rescorla <ekr@rtfm.com> wrote:
>
> I'd like to hear from some people who plan to implement and deploy= this. Absent that, I'm not sure we should adopt it. Code points are fr= ee, so it doesn't need to be a TLS WG item unless the TLS WG and commun= ity are going to do substantial work on it.
>
> -Ekr
>
>
> On Fri, Jan 25, 2019 at 10:12 AM Christopher Wood <christopherwood07@gmail.co= m> wrote:
>>
>> At the TLS@IETF103 session, there was interest in adopting
>> draft-housley-tls-tls13-cert-with-extern-psk as an experimental WG=
>> item, provided that it's limited to external PSKs with certifi= cates
>> for the initial handshake. This email is to determine whether ther= e is
>> WG consensus to adopt this draft (as is) as a WG item.
>>
>> If you would like for this draft to become a WG document and you a= re
>> willing to review it as it moves through the process, then please = let
>> the list know by 2359UTC 20180208. If you are opposed to this bein= g a
>> WG document, please say so (and say why).
>>
>> 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



------------------------------

Subject: Digest Footer

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


------------------------------

End of TLS Digest, Vol 175, Issue 5
***********************************
--000000000000e55b300581e8ffa3-- From nobody Fri Feb 15 21:07: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 57C77130EED for ; Fri, 15 Feb 2019 21:07:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, LOTS_OF_MONEY=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 eOxV7aOoae4t for ; Fri, 15 Feb 2019 21:07:06 -0800 (PST) Received: from mail-ot1-x341.google.com (mail-ot1-x341.google.com [IPv6:2607:f8b0:4864:20::341]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A35DE130E46 for ; Fri, 15 Feb 2019 21:07:06 -0800 (PST) Received: by mail-ot1-x341.google.com with SMTP id g1so20122610otj.11 for ; Fri, 15 Feb 2019 21:07:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=SU5MD14atKo8tPr4vANtd+16zLye4Qy0qDWDa5SGpxY=; b=hdVyflJoNI2FgVOi9OSdFo/+Ku/kbE4L7N/iUIDrqigVZAyE2ax28Tz9zOFX+20tS+ 9XmPTfzUlrvGOF4Vv+o8hdxJONU98nVDDKllNxMeUn1hLgQGAlqjjQHFYr9ANHM9/BPl nxg8jw+9Wc0z1cw7pXUsH39ok2bMmpo67zvP4E+sOypkPS9p7TiwpxRkFIeWi03pTipr ljoEDw9g9Fmf80bebGTX05/yk5/Wgf1RAo802mJTvF6gJnVjUk0dBhT+G9uIExm0iUc3 eVUDaVG19dHP9dCu8hM0JryDaEb45jwS4UI6IREIIKQ1EYowESPpHtryDG5XpcCGgKOc +kOA== 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:cc; bh=SU5MD14atKo8tPr4vANtd+16zLye4Qy0qDWDa5SGpxY=; b=Wc6aXuypuBPRCnn852TK44fyP6626A/DPZ6FK29D/FxUufmXvoSVSTvPLD2129Xos2 xlIBerdDaWN8U4d+2OSyE0a6IgJamBbAiyeAYnD4ton+yxi/nCqVkr5wh80yH68U0QXU cbCY10BzTyqIZ7JnDj7+j7b7sXLt6odVwOXUTZdUPCt8BnyIgdC7cQhIXSWpZggeg75x 7cRGKUtfVcP1yRDMZnqoi+GeBvfzlBIBfGVBN22VMdpqWBrG3AtNy3n0V6yCu+iLHCpn OhGWOXjDT7za71bNIQVZ7cc0yNx38gh1VQIQaE3wS5aCNamn4kMtxCcliyELD6Cy0Xhu ZVVA== X-Gm-Message-State: AHQUAuZj7hAlQtfgr3gtrJJLT/VFOpEcnGa9OsV1v9rnLy5WjrOn0lS5 pjvSmrDMYi1gekhJXjxR4bKPTrmHpuuOSXyPLZz9GnDz X-Google-Smtp-Source: AHgI3IY9Dzkehvvyrq4Q9z9uNYNNXyWf+AQV5vBSNQ56uuh1RQNxpvSrE3QDZM1hxbV82TqRrBD2gP4pFUrUWomLFMo= X-Received: by 2002:aca:c5cf:: with SMTP id v198mr8215432oif.32.1550293625483; Fri, 15 Feb 2019 21:07:05 -0800 (PST) MIME-Version: 1.0 From: Sankalp Bagaria Date: Sat, 16 Feb 2019 10:36:53 +0530 Message-ID: To: tls@ietf.org, T2TRG@irtf.org Content-Type: multipart/alternative; boundary="000000000000d835c80581fbdc8c" Archived-At: Subject: [TLS] ITDA - IoT Device Authentication 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, 16 Feb 2019 05:07:10 -0000 --000000000000d835c80581fbdc8c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable *Hello,* *Please take a look at this and advise if it is a good idea and whether it should be pursued.* *Thanks,* *Sankalp Bagaria.* *ITDA - IoT Device Authentication* *Abstract: *We propose that the server is authenticated using X509 certificate in a TLS 1.3 like protocol. The Server sends 32-byte Challenge. Client replies by sending 32-byte Response. Thus the client is authenticated. In the transfer of the application data, the client may send more challenge-response pairs as encrypted data for updating database of server. Client doesn=E2=80=99t store challenge/response or key or certifica= te. Both the server and the client can initiate the handshake. *Background* Traditionally, there are two ways to authenticate a device: a centralised CA issuing certificates and block-chain. Both require costly infrastructure and can=E2=80=99t be used to authenticate IoT devices, which are of low cos= t. While block-chain provides non-repudiation, transactions are distributed all over the net. X.509 certificates are costlier than many sensors. Another option is Physically Uncloneable Functions (PUF). Because of the random variations taking place during the manufacturing process of an IC, no two ICs are same. For instance, the impurities present in the IC can affect the doping level of an IC and thus cause signal paths to change. These slight variations in the signal path can affect the delay in the propagation of a signal which can be measured and used to identify the chip. This uniqueness of an IC can be used to authenticate the device in which the IC has been placed. *PUF: The Concept* *[image: P02.JPG]* Figure 1: PUF =E2=80=93 Multiplexer pair=E2=80=99s output delay compared b= y arbiter (latch) When the same input is fed to two adjacent multiplexers, depending on the impurities and other manufacturing variations, the delay observed in the propagation of the signal to one multiplexer output is different from that of the other. This delay can be compared using an arbiter (latch) and the final output generated. Several pairs of multiplexers can be operated in parallel or a series of inputs can be fed to the same pair of multiplexer. Thus, a set of output bits is generated that is specific to the chip. The set of input bits is called challenge and the set of output bits is called response. A challenge/ response pair is specific to the chip. The experimental results [4] show that two identical PUF circuits on two different chips have different outputs for the same input with a probability of 23% (inter-chip variation). On the other hand, multiple measurements on the same chip are different only with 0.7% probability. As both the multiplexers on the chip are in the same environment, the PUF output is mostly independent of the environmental variations. *Limitations of current PUF implementation* To prevent the replay attack, a challenge =E2=80=93 response pair can be us= ed only once. To enable this, a large set of challenge =E2=80=93 response pairs hav= e to be generated at the installation time and pre-stored in the server. A server can have many devices connected to it. So, it has to have a large database and computational power. Moreover, this setting is inflexible. There is the problem of distributing challenge/ response pairs from client to server. When the PUF is commissioned, challenge/ response pairs have to be generated at the chip and taken to server. If the server exhausts its supply of challenge-response pairs, it cannot be easily renewed. *Our solution* Thus in our solution, we combine the best of X.509 certificate and PUF. Certificate is well-tested technology and provides flexible way to distribute keys. PUF is relatively new but allows a cheap solution to IoT authentication problem. Moreover, there is no need to store keys or certificates at the client-side. *The Protocol Combining TLS 1.3 and Challenge/ Response of PUF* *The Protocol with Client Starting the Connection* Client starts by generating its key_share and sends it to Server for normal TLS connection. It also sends acceptable ciphersuites. Server generates its own private key and joins with client's keyshare to get the shared secret. It takes this share-secret and combines with hash of the handshake till that point to generate handshake keys. The connection is encrypted from this point on. The server sends its X.509 certificate, CertificateVerify and PUF_Challenge. The client also generates the handshake key from its private key and server's public key. It then verifies the certificate, generates PUF_Response. It encrypts the PUF_Response and sends to the Server. Server verifies it, generates Application Key from Handshake_key and hash of the Handshake. The Client also generates the Application Keys similarly. The Application data flows in encrypted form. To start, Server requires only one pair of Challenge/ Response. When server's stock is depleting it may request more challenge/ response pairs in application data. Client may generate more pairs and send them as encrypted data to server which stores in its database for future use. Client should delete its copy permanently so that an adversary can't recover it by attacking hardware. Client Server ClientHello + key_share --------> ServerHello + key_share {Encrypted Extensions} {Certifica= te} {CertificateVerify} <--------- {PUF_Challenge} PUF_Response ----------> {Finis= hed} <--------- [Application Data] {Finished} [Application Data} <--------> [Application Data] *The Protocol with Server Starting the Connection* The Server may also initiate connection by sending Server Hello. Client replies by sending Client Hello with its key_share and list of acceptable ciphersuites. When server receives Client_Hello, it proceeds just like the above use-case. Client Server <----------- ServerHello ClientHello + key_share ----------> key_share {Encrypted Extensions} {Certifica= te} {CertificateVerify} <----------- {PUF_Challenge} {PUF_Response} ----------=C3=A0 {Finis= hed} <--------- [Application Data] {Finished} [Application Data} <--------> [Application Data] The Client doesn't store the Keys, Challenge/ Response or the Certificate. Each session is a unit in itself. Everything is calculated on the fly. This may create latency but this minimizes the resource requirement. It is required that when the IoT device is commissioned, atleast one Challenge/ Response pair is generated and stored in Server Database. Whenever the challenge - response pairs are depleting, on Server's request, the Client can generate them and send to the Server as encrypted data. After sending, the Client deletes its copy of Challenge / Response. *Future Work:* 1) Complete the development of protocol described above by including use cases like when does the Handshake fails and Challenge/ Response has to be re-negotiated; when Resumption happens etc. 2) Adapt other IoT protocols like QUIC, DTLS to work with PUF. 3) Validate the solution with PUF-enabled Evaluation kits. References =E2=80=93 [1] RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. https://tools.ietf.org/html/rfc5280 [2] 50 Billion IoT devices will be connected by 2020 =E2=80=93 Post =E2=80= =93 The Things Network. https://www.thethingsnetwork.org/community/thessaloniki/post/50-billion-iot= -devices-will-be-connected-by-2020 [3] https://en.wikipedia.org/wiki/Physical_unclonable_function [4] G. E. Suh and S. Devadas, =E2=80=9CPhysical unclonable functions for de= vice authentication and secret key generation,=E2=80=9D in Proceedings of the 44= th annual Design Automation Conference, San Diego, CA, Jun. 2007, pp.9=E2=80= =9314 https://people.csail.mit.edu/devadas/pubs/puf-dac07.pdf [5] http://people.csail.mit.edu/rudolph/Teaching/Lectures/Security/Lecture-Secu= rity-PUFs-2.pdf [5] Blaise Gassend, Dwaine Clarke, Marten van Dijk and Srinivas Devadas. Silicon Physical Random Functions. Proceedings of the Computer and Communications Security Conference, November 2002 http://csg.csail.mit.edu/pubs/memos/Memo-456/memo-456.pdf [6] C. Herder, L. Ren, M. van Dijk, M-D. Yu, and S. Devadas, "Trapdoor Computational Fuzzy Extractors and Cryptographically-Secure Physical Unclonable Functions", IEEE Transactions on Dependable and Secure Computing, January 2017 https://people.csail.mit.edu/devadas/pubs/trapdoor.pdf [7] Helfmeier, Clemens; Nedospasov, Dmitry; Boit, Christian; Seifert, Jean-Pierre (2013). Cloning Physically Unclonable Functions (PDF). IEEE Hardware Oriented Security and Trust (IEEE HOST 2013). June 2=E2=80=933, 20= 13 Austin, TX, USA http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=3D6581556 [8] Merchan Jorge Guajardo , Shankaran S. Kumar , Pim T. Tuyls , Geert J. Schrijen Identification of devices using physically unclonable functions WO 2009024913 A2 [9] M. Fyrbiak, C. Kison, W. Adi. Construction of Software-Based Digital Physical Clone Resistant Functions. 2013 Fourth International Conference on Emerging Security Technologies http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=3D6680199 [10] https://www.esat.kuleuven.be/cosic/thesis/2011/mai/CloningTheUnclonable_en.= pdf [11] Srinivas Devadas, Edward Suh, Sid Paral, Richard Sowell, Tom Ziola, Vivek Khandelwal . Design and Implementation of PUF-Based =E2=80=9CUnclonab= le=E2=80=9D RFID ICs for Anti-Counterfeiting and Security Applications. http://verayo.com/pdf/2008_Verayo_IEEE_RFID_Paper.pdf [12] Rishab Nithyanand, John Solis. A Theoretical Analysis: Physical Unclonable Functions and The Software Protection Problem. SANDIA REPORT SAND2011-6673. Printed in 2011. http://prod.sandia.gov/techlib/access-control.cgi/2011/116673.pdf [13] Shahriar B. Shokouhi. Cooperative Artificial Immune System And Recurrent Neural Network Error Correction Scheme For Generating Robust Hardware Key. International Journal Of Electrical, Electronics And Data Communication. ISSN: 2320-2084. Volume-4, Issue-5,May 2016 http://www.iraj.in/journal/journal_file/journal_pdf/1-254-146502604154-59.p= df [15] D. Lim. Extracting secret keys from integrated circuits. Master=E2=80= =99s thesis, Massachusetts Institute of Technology, May 2004. http://csg.csail.mit.edu/pubs/memos/Memo-476/DaihyunLimThesis.pdf [16] Ulrich Ruhrmair. On the Formal Foundations of PUFs and Related Primitives. October 19, 2016. https://depositonce.tu-berlin.de/bitstream/11303/5994/4/ruehrmair_ulrich.pd= f [17] https://patents.google.com/patent/US20090083833A1/en?q=3DPUF&q=3Dphysically= +unclonable+function&oq=3DPUF+physically+unclonable+function [18] https://patents.google.com/patent/US8290150B2/en?q=3Dauthentication&q=3DPUF= &q=3Dphysically+unclonable+function&oq=3Dauthentication+PUF+physically+uncl= onable+function [19] https://patents.google.com/patent/US20140279532A1/en?q=3Dauthentication&q= =3DPUF&q=3Dphysically+unclonable+function&oq=3Dauthentication+PUF+physicall= y+unclonable+function [20] RFC 8446 =E2=80=93 The Transport Layer Security (TLS) Protocol Version= 1.3 https://datatracker.ietf.org/doc/rfc8446/ [21] The New Illustrated TLS Connection https://tls13.ulfheim.net/ [22] Internet-draft: State-of-the-Art and Challenges for the Internet of Things Security draft-irtf-t2trg-iot-seccons-16 [23] Internet-draft: TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key. draft-housley-tls-tls13-cert-with-extern-psk-03 --000000000000d835c80581fbdc8c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hello,

Please take a look at this and advise if it is a good idea and= whether it should be pursued.

Tha= nks,

Sankalp Bagaria.

=


<= p class=3D"MsoNormal" align=3D"center" style=3D"text-align:center;margin:0c= m 0cm 10pt;line-height:115%;font-size:11pt;font-family:Calibri,sans-serif">= ITDA - IoT Device Aut= hentication

Abstract: We propose that the server is authenticated = using X509 certificate in a TLS 1.3 like protocol. The Server sends 32-byte Challenge.= Client replies by sending 32-byte Response. Thus the client is authenticated. In t= he transfer of the application data, the client may send more challenge-respon= se pairs as encrypted data for updating database of server. Client doesn=E2=80= =99t store challenge/response or key or certificate. Both the server and the client ca= n initiate the handshake.

Background

Traditionally, there are two ways to authe= nticate a device: a centralised CA issuing certificates and block-chain. Both require costly infrastructure and can=E2=80=99t be used to authenticate IoT devices, which= are of low cost. While block-chain provides non-repudiation, transactions are distribu= ted all over the net. X.509 certificates are costlier than many sensors.=

Another option is Physically Uncloneable F= unctions (PUF). Because of the random variations taking place during the manufacturing process of a= n IC, no two ICs are same. For instance, the impurities present in the IC can affect the doping level of an IC and thus cause signal paths to change. The= se slight variations in the signal path can affect the delay in the propagatio= n of a signal which can be measured and used to identify the chip. This uniquene= ss of an IC can be used to authenticate the device in which the IC has been placed.

=C2=A0

PUF: The Concept

=3D"P02.JPG"=

=C2=A0Figure 1: PUF =E2=80=93 Multiplexer pair=E2=80=99s output delay compared by arbiter (latch)<= /p>

When the same input is fed to two adjacent= multiplexers, depending on the impurities and other manufacturing variations, the delay observed in the propagation of the signal to one multiplexer output is different from that of the other. This delay can be compared using an arbit= er (latch) and the final output generated. Several pairs of multiplexers can b= e operated in parallel or a series of inputs can be fed to the same pair of multiplexer. Thus, a set of output bits is generated that is specific to th= e chip.

The set of input bits is called challenge = and the set of output bits is called response. A challenge/ response pair is specific to t= he chip. The experimental results [4] show that two identical PUF circuits on = two different chips have different outputs for the same input with a probabilit= y of 23% (inter-chip variation). On the other hand, multiple measurements on the same chip are different only with 0.7% probability. As both the multiplexer= s on the chip are in the same environment, the PUF output is mostly independent = of the environmental variations.

Limitations of current PUF implementat= ion

To prevent the replay attack, a challenge = =E2=80=93 response pair can be used only once. To enable this, a large set of challenge =E2=80=93 respo= nse pairs have to be generated at the installation time and pre-stored in the server.= A server can have many devices connected to it. So, it has to have a large database and computational power.

Moreover, this setting is inflexible. Ther= e is the problem of distributing challenge/ response pairs from client to server. When the PUF = is commissioned, challenge/ response pairs have to be generated at the chip an= d taken to server.=C2=A0 If the server exhausts its supply of challenge-response pairs, it cannot be easily renewed.

=C2=A0

Our solution

Thus in our solution, we combine the best = of X.509 certificate and PUF. Certificate is well-tested technology and provides flexible way to distribute keys. PUF is relatively new but allows a cheap solution to IoT authentication problem. Moreover, there is no need to store keys or certificates at the client-side.

The Protocol Combining TLS 1.3 and Cha= llenge/ Response of PUF

The Protocol with Client Starting the = Connection

Client starts by generating its key_share = and sends it to Server for normal TLS connection. It also sends acceptable ciphersuites. Se= rver generates its own private key and joins with client's keyshare to get t= he shared secret. It takes this share-secret and combines with hash of the handshake till that point to generate handshake keys. The connection is encrypted from this point on.

=C2=A0

The server sends its X.509 certificate, Ce= rtificateVerify and PUF_Challenge. The client also generates the handshake key from its private= key and server's public key. It then verifies the certificate, generates PU= F_Response. It encrypts the PUF_Response and sends to the Server. Server verifies it, generates Application Key from Handshake_key and hash of the Handshake.

=C2=A0

The Client also generates the Application = Keys similarly. The Application data flows in encrypted form. To start, Server requires only on= e pair of Challenge/ Response. When server's stock is depleting it may re= quest more challenge/ response pairs in application data. Client may generate mor= e pairs and send them as encrypted data to server which stores in its databas= e for future use. Client should delete its copy permanently so that an advers= ary can't recover it by attacking hardware.

Client=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Server

ClientHello=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

+ key_share=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 -------->=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ServerHello

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0+ key_share=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0{Encrypted Extensions}

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0{Certificate}

=C2=A0=C2=A0=C2=A0 {CertificateVerify}

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<--------= -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {PUF_Challenge}

PUF_Response=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0---------->=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0{Finished}

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<---------=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[Application Data]

{Finished}=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

[Application Data} =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0<-------->=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0[Application Data]

=C2=A0

=C2=A0

The Protocol with Server Starting the = Connection

The Server may also initiate connection by= sending Server Hello. Client replies by sending Client Hello with its key_share and list o= f acceptable ciphersuites. When server receives Client_Hello, it proceeds jus= t like the above use-case.

=C2=A0

Client=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Server

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<-----= ------=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0ServerHello

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

ClientHello=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

+ key_share=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0------= ---->=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=

=C2=A0key_share=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0{Encrypted Extensions}

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0{Certificate}

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0{CertificateVerify}

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0<-----------=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0{PUF_Challenge}

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

{PUF_Response}=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= ----------=C3=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0{Finished}

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<---------=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[Application Data]

=C2=A0=C2=A0=C2=A0 =C2=A0{Finished}=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

[Application Data}=C2=A0 =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0<-------->=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[Application Data]

=C2=A0

The Client doesn't store the Keys, Cha= llenge/ Response or the Certificate. Each session is a unit in itself. Everything is calculated on = the fly. This may create latency but this minimizes the resource requirement. I= t is required that when the IoT device is commissioned, atleast one Challenge/ Response pair is generated and stored in Server Database. Whenever the challenge - response pairs are depleting, on Server's request, the Clie= nt can generate them and send to the Server as encrypted data. After sending, the Client deletes its copy of Challenge / Response.

Future Work:

1)=C2=A0=C2=A0=C2=A0 Complete the development of protocol described above by including use cases like when does the Handshake fails a= nd Challenge/ Response has to be re-negotiated; when Resumption happens etc.

2)=C2=A0=C2=A0=C2=A0 Adapt other IoT protocols like QUIC, DTLS to work with PUF.

3)=C2=A0=C2=A0=C2=A0 Validate the solution with PUF-enabled Evaluation kits.

References =E2=80=93

[1] RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. https://tools.ietf.org/html/rfc5280

[2] 50 Billion IoT devices will be connected by 2020 =E2=80= =93 Post =E2=80=93 The Things Network. https://www.thethingsnetwork.org/community/thessaloniki/post/50-bil= lion-iot-devices-will-be-connected-by-2020

[3] https://en.wikipedia.org/wiki/Physical_unclonable_function

[4] G. E. Suh and S. Devadas, =E2=80=9CPhysical unclonable functions for device authentication and secret key generation,=E2=80=9D in = Proceedings of the 44th annual Design Automation Conference, San Diego, CA, Jun. 2007, pp.9=E2=80=9314 https://people.csail.mit.edu/devadas/pubs/puf-dac07.pdf

[5] http://people.csail.mit.edu/= rudolph/Teaching/Lectures/Security/Lecture-Security-PUFs-2.pdf

[5] Blaise Gassend, Dwaine Clarke, Marten van Dijk and Srinivas Devadas. Silicon Physical Random Functions. Proceedings of the Computer and Communications Security Conference, November 2002 http://csg.csail= .mit.edu/pubs/memos/Memo-456/memo-456.pdf

[6] C. Herder, L. Ren, M. van Dijk, M-D. Yu, and S. Devadas, "Trapdoor Computational Fuzzy Extractors and Cryptographically-Secure Physical Unclonable Functions", IEEE Transact= ions on Dependable and Secure Computing, January 2017 https://people.csail.mit.edu/deva= das/pubs/trapdoor.pdf=

[7] Helfmeier, Clemens; Nedospasov, Dmitry; Boit, Christian; Seifert, Jean-Pierre (2013). Cloning Physically Unclonable Functions (PDF). IEEE Hardware Oriented Security and Trust (IEEE HOST 2013= ). June 2=E2=80=933, 2013 Austin, TX, USA

=C2=A0http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=3D6= 581556

=C2=A0[8] M= erchan Jorge Guajardo, Shankaran S. Kumar, Pim T. Tuyls, Geert J. Schrijen Identificati= on of devices using physically unclonable functions
WO 2009024913 A2

[9] M. Fyrbiak, C. Kison, W. Adi. Construction of Software-Based Digital Physical Clone Resistant Functions. 2013 Fourth International Conference on Emerging Security Technologies http://ieeexpl= ore.ieee.org/stamp/stamp.jsp?arnumber=3D6680199

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [10]https://www.esat.kuleuven.be/co= sic/thesis/2011/mai/CloningTheUnclonable_en.pdf

[11] Srinivas Devadas, Edward Suh, Sid Paral, Richard Sowell, Tom Ziola, Vivek Khandelwal . Design and Implementation of PUF-Base= d =E2=80=9CUnclonable=E2=80=9D RFID ICs for Anti-Counterfeiting and Security = Applications.=C2=A0 http://verayo.com/pdf/2008_Verayo_IEEE_RFID_Paper.pdf

[12] Rishab Nithyanand, John Solis. A Theoretical Analysis: Physical Unclonable Functions and The Software Protection Problem. SANDIA REPORT SAND2011-6673. Printed in 2011. http://prod.sandia.gov/techlib/a= ccess-control.cgi/2011/116673.pdf

[13] Shahriar B. Shokouhi. Cooperative Artificial Immune System And Recurrent Neural Network Error Correction Scheme For Generating Robust Hardware Key. International Journal Of Electrical, Electronics And D= ata Communication. ISSN: 2320-2084. Volume-4, Issue-5,May 2016 http://www.iraj.in/journal/journal_file/journal_pdf/1-254-146502604154-59= .pdf

[15] D. Lim. Extracting secret keys from integrated circuits. Master=E2=80=99s thesis, Massachusetts Institute of Technology, M= ay 2004. http://csg.csail.mit.edu/pubs/memos/Memo-476/DaihyunLimThesis.= pdf

[16] Ulrich Ruhrmair. On the Formal Foundations of PUFs and Related Primitives. October 19, 2016. =C2=A0https://depo= sitonce.tu-berlin.de/bitstream/11303/5994/4/ruehrmair_ulrich.pdf=

[17] https://patents.google.com/patent/US20090083833A1= /en?q=3DPUF&q=3Dphysically+unclonable+function&oq=3DPUF+physically+= unclonable+function

[18]=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://patents.google.com/patent/US8290150B2/en?q=3Dauthent= ication&q=3DPUF&q=3Dphysically+unclonable+function&oq=3Dauthent= ication+PUF+physically+unclonable+function

[19] https://pat= ents.google.com/patent/US20140279532A1/en?q=3Dauthentication&q=3DPUF&am= p;q=3Dphysically+unclonable+function&oq=3Dauthentication+PUF+physically= +unclonable+function<= /span>

[20] RFC 8446 =E2=80=93 The Transport Layer Security (TLS) Protocol Version 1.3 https://datatracker.ietf.org/doc/rfc8446/

[21] The New Illustrated TLS Connection https://tls13.ulfheim.net/

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 [22] Internet-draft: State-of-the-Art and Challenges for the Internet of=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Things Security draft-irtf-t2trg-iot-seccons-16

[23] Internet-draft: TLS 1.3 Extension for Certificate-based Authentication with=C2=A0 an External Pre-Shared Key. draft-housley-tls-tls13-cert-with-ex= tern-psk-03

--000000000000d835c80581fbdc8c-- From nobody Sat Feb 16 07:48:40 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE4CE130EF9; Sat, 16 Feb 2019 07:48:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.018, 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=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 4mWv4_k17F0T; Sat, 16 Feb 2019 07:48:02 -0800 (PST) Received: from mail-lj1-f174.google.com (mail-lj1-f174.google.com [209.85.208.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BEDF1275F3; Sat, 16 Feb 2019 07:48:02 -0800 (PST) Received: by mail-lj1-f174.google.com with SMTP id z25so3028546ljk.8; Sat, 16 Feb 2019 07:48:02 -0800 (PST) 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=fjM90OsfjVfZcKva1VBJ7ZCVovtil0kJiZnlpMYkzSc=; b=aNM6sPcNw1BJi/dPnUu+spBnayGBVVyPlh1Xi8WOBEm/G3fbasIYMUFF7+qTpU3yRb +2dRtZO8I5qJl5CDu98JnvErJk4UTEV+ewGzGnXhOu2+alTGoHPNTKD57bcSdEKNfDj0 azAf096WbDYiP1dThqZcPrQ0IdNXTpnBKX7lkgi/vlR0hSebcRCwW7dp+cwSYd9g5uZN F/QxurovDVKVuHH2bmRY4M/YljU9I3W+i/PP0Dk4Uv5zb2+kK2WYFFJdJ1hrvG0McNOw pKB8hub+d18MFJx0sxvT7D/mrr7Int9uHhZZByP1jfEVfMf5f97GI26p5SMlyawjhV1d S4oA== X-Gm-Message-State: AHQUAuYth/C+iXlXl8Ihx2JQj+6LuLzMKoI4o4uKwQeFCNEdeQfdVCL8 g/FXI42hDh+UGurxeurLZ6OOSniWaMLvoTajxUaWVNWU X-Google-Smtp-Source: AHgI3IYWU738Zm0AxQrUky2fQHoe0kn2kE0Xl0R+ytlv5W56dYdQozHkNO7agwKz054zFLAZqiFhW2+bAeEdANOx8pI= X-Received: by 2002:a2e:6505:: with SMTP id z5mr3413640ljb.180.1550332079900; Sat, 16 Feb 2019 07:47:59 -0800 (PST) MIME-Version: 1.0 From: Daniel Migault Date: Sat, 16 Feb 2019 10:47:48 -0500 Message-ID: To: tls , IPsecME WG , saag@ietf.org, nvo3@ietf.org, sfc@ietf.org, quic@ietf.org Content-Type: multipart/alternative; boundary="000000000000e80cf2058204d014" Archived-At: Subject: [TLS] netdev0x13 - ietf related topics 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, 16 Feb 2019 15:48:05 -0000 --000000000000e80cf2058204d014 Content-Type: text/plain; charset="UTF-8" Hi, Please find among many others some IETF related topics [1] that will be discussed at netdev0x13 just before the IETF meeting in Pragues. Early bird registration is open until February 20. !!!! Netdev 0x13 will be held at Hotel Grandium in Prague, this spring March 20th - 22th, 2019 Yours, Daniel [1] https://www.netdevconf.org/0x13/IETF-relevant-talks.html --000000000000e80cf2058204d014 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi,

=C2=A0

Please find among many others some IET= F related topics [1] that will be discussed at netdev0x13 just before the IETF meeting in Pragues.

=C2=A0

Early bird registration is open until= =C2=A0February 20.=C2=A0!!!!

=C2=A0

Netdev 0x13 will be held at Hotel Grandium in Prague, this spring March 2= 0th - 22th, 2019=C2=A0


=

Yours,

Daniel

=C2=A0

[1] https://www.netdevconf.org/0x13/IETF-relevant-talks.html


--000000000000e80cf2058204d014-- From nobody Sat Feb 16 17:00: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 7E63012F18C for ; Sat, 16 Feb 2019 17:00:49 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kfgb50qCe9hS for ; Sat, 16 Feb 2019 17:00:47 -0800 (PST) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B89B712D4EA for ; Sat, 16 Feb 2019 17:00:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1550365247; x=1581901247; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=v/LiKqd5qGMsW/vN8r/yC33eDL0XZ09xg8K4+9/DfPY=; b=b3YX6Nawf9OJiRhkCxjIG+Ai9eengRQaaSo6kCon1XFUMg61H/3Zyzh/ liXPGIMuOU0cszXiWSKdTI42DD9iUHKo4ULM1zOt5eFhJtW0wkxdhnaU/ QCD18f8nGiTHbdOea7/p7/PZUN/Olfqm9wOX1/ao5+07L48sojoCz8MsX A+Yjzhh4vkpVUFanrOa3k+trjW7EAIchU6cZ24MxcFcPpWwqXDamNut7E oqQAycOTlisEtD38my9QNZsH4TcCBYynrHyJ/KK5YyTyAncJuPjHZnT7B RVZnzSZG8oRmmKm/Pl64VFdtFA8SrfXMTHAJ3sqrLBpxwXyNmC1k4jCL9 A==; X-IronPort-AV: E=Sophos;i="5.58,378,1544439600"; d="scan'208";a="48632780" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.9 - Outgoing - Outgoing Received: from uxcn13-tdc-e.uoa.auckland.ac.nz ([10.6.3.9]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 17 Feb 2019 14:00:43 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-e.UoA.auckland.ac.nz (10.6.3.9) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sun, 17 Feb 2019 14:00:43 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Sun, 17 Feb 2019 14:00:43 +1300 From: Peter Gutmann To: Sankalp Bagaria , "tls@ietf.org" , "T2TRG@irtf.org" Thread-Topic: [TLS] ITDA - IoT Device Authentication Thread-Index: AQHUxbWbR5ulgtoOAkKB1eLsJ8OVH6XjLMBs Date: Sun, 17 Feb 2019 01:00:42 +0000 Message-ID: <1550365230138.15157@cs.auckland.ac.nz> References: In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] ITDA - IoT Device Authentication 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, 17 Feb 2019 01:00:50 -0000 Sankalp Bagaria writes:=0A= =0A= >We propose that the server is authenticated using X509 certificate in a TL= S=0A= >1.3 like protocol. The Server sends 32-byte Challenge. Client replies by= =0A= >sending 32-byte Response.=0A= =0A= Something very similar to this already exists in the form of CHAP/MSCHAP ov= er=0A= PEAP/EAP-TLS/EAP-TTLS.=A0 It's supported by every Radius server and vast nu= mbers=0A= (probably billions) of clients.=A0 To compete against this huge installed b= ase, any=0A= new proposal would have to be pretty spectacular...=0A= =0A= Peter.=0A= From nobody Sat Feb 16 23:04: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 3B9CE12941A for ; Sat, 16 Feb 2019 23:03:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 OhiBWzF5FvCM for ; Sat, 16 Feb 2019 23:03:54 -0800 (PST) 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 C6B5C128B01 for ; Sat, 16 Feb 2019 23:03:53 -0800 (PST) Received: by mail-ot1-x331.google.com with SMTP id t7so6959195otk.8 for ; Sat, 16 Feb 2019 23:03:53 -0800 (PST) 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=nNhUOZ2PTDCWTMDxq5Yk5I/T3akNge9jwY+x814MmRk=; b=kq1WEeQgIZDCQB3iuoGAU4aj2Jl3WjLu/Xh58jKYH6bwu9hEKgU4nxaN0OP1hZUqri qm7phARBCpFpSSaRfYDoMqMIME/hSu4UVS59dVESmuC0LND64WMCN5BMOktLuW07aPz7 IfFd0b+RZf0NKQoekFlK6EUnHaRQfAwtQLHr9K+1AHq7t2AwWL+be/C+m6673GN2meWy HDAwE8NAksdhEQFO9P5xo3be2ez+XSOffiAaGqcWLr3u0AurQK1KXY+vNGzeSXzJz3tm 0eg91V2J1U5WPcnrejXNfGi5XzYqrU/gSZlVhkYL8ru+SedTfSOeNEMibTFIUrgYN5l5 8rhw== 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=nNhUOZ2PTDCWTMDxq5Yk5I/T3akNge9jwY+x814MmRk=; b=rseqX0NVxN80PZGEJ7tOk+jFOA93kFBc02r+Up+8ZR/wz8JV8Hkwl+NZU6jiGbnSN7 68oZRgBPhZZ8yon5kd4nkg/D6H6s1jg8Dvqp1laMxuS8paThwuBSrFnWCN1aGDH5TWQj BnhmwpAeK2QumPedSmnFNKBa4NhxlJo4AXezSHVCRGIbhRj31cx4UNaEJq2P+ISlPakp cCq6XgxRoVUX5wM8f1GVn6y+TowSAJxV0bRC6SjOUk4Egf5lztdohOzjBLGOJQoir95V Lo6QCyH6Y+sIPtOHLg4YZT+GEW9aZWVUUaqUMgWHJUxRCe2f04T/DnTa0FRhwjPW71/B 6lkw== X-Gm-Message-State: AHQUAuZN96J0Jgz54cdMZFvR0pVbzJCoRwiMwxbNWkK3WeEDJFu7tikh XhrHiI8rUBLbldVEBOUbQh+u8mbX+3zhQo4qFKI= X-Google-Smtp-Source: AHgI3IZ1vFyCuRz1vOYG1ME99rzoCN+qk5uI7xonirqJjUNuWt9yf5agGNqxIZXdzYJyGMbeOWB/YfMnVj1C6NXPyas= X-Received: by 2002:a9d:61c7:: with SMTP id h7mr10109257otk.363.1550387032696; Sat, 16 Feb 2019 23:03:52 -0800 (PST) MIME-Version: 1.0 References: <1550365230138.15157@cs.auckland.ac.nz> In-Reply-To: <1550365230138.15157@cs.auckland.ac.nz> From: Sankalp Bagaria Date: Sun, 17 Feb 2019 12:33:40 +0530 Message-ID: To: Peter Gutmann Cc: tls@ietf.org, T2TRG@irtf.org Content-Type: multipart/alternative; boundary="000000000000592a9a0582119cb2" Archived-At: Subject: Re: [TLS] ITDA - IoT Device Authentication 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, 17 Feb 2019 07:03:57 -0000 --000000000000592a9a0582119cb2 Content-Type: text/plain; charset="UTF-8" Hello Mr Peter, Thank you for your reply. It was my first attempt to develop a protocol. Hence, the mistake. I hope to do better work next time. Although PUF is not my idea, I would like to know if it is a good idea. I thought it was the future of IoT world. Should we invest time, money and energy in it ? Please advise. Thanks and Regards, Sankalp Bagaria. On Sun 17 Feb, 2019, 6:30 AM Peter Gutmann, wrote: > Sankalp Bagaria writes: > > >We propose that the server is authenticated using X509 certificate in a > TLS > >1.3 like protocol. The Server sends 32-byte Challenge. Client replies by > >sending 32-byte Response. > > Something very similar to this already exists in the form of CHAP/MSCHAP > over > PEAP/EAP-TLS/EAP-TTLS. It's supported by every Radius server and vast > numbers > (probably billions) of clients. To compete against this huge installed > base, any > new proposal would have to be pretty spectacular... > > Peter. > --000000000000592a9a0582119cb2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Mr Peter,

Thank you for your reply. It was my first attempt to develop a protocol= . Hence, the mistake. I hope to do better work next time.

Although PUF is not my idea, I would like= to know if it is a good idea. I thought it was the future of IoT world. Sh= ould we invest time, money and energy in it ? Please advise.

Thanks and Regards,
Sankalp Bagaria.

On Sun 17 Feb, 2019, 6:30 AM Peter Gutmann, <pgut001@cs.auckland.ac.nz> wrote:
Sankalp Bagaria <sankalp.nitt@gmail= .com> writes:

>We propose that the server is authenticated using X509 certificate in a= TLS
>1.3 like protocol. The Server sends 32-byte Challenge. Client replies b= y
>sending 32-byte Response.

Something very similar to this already exists in the form of CHAP/MSCHAP ov= er
PEAP/EAP-TLS/EAP-TTLS.=C2=A0 It's supported by every Radius server and = vast numbers
(probably billions) of clients.=C2=A0 To compete against this huge installe= d base, any
new proposal would have to be pretty spectacular...

Peter.
--000000000000592a9a0582119cb2-- From nobody Sun Feb 17 10:50:35 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C748A129AA0; Sun, 17 Feb 2019 10:50:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rG99upIn4iI0; Sun, 17 Feb 2019 10:50:30 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8626912426E; Sun, 17 Feb 2019 10:50:30 -0800 (PST) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.27/8.16.0.27) with SMTP id x1HIlM8C001884; Sun, 17 Feb 2019 18:50:22 GMT 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 : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=n/z8PhUi//sQ5XLSWs/P2mO4r7ltcXaJherJLCsX+kc=; b=RMiIvrDwBCWSVNkhRplZ6Oy0gCgM7DSTPEMJL6SuvoiuI835LvKRBBYkOSVPSu/kXZYf PWvpiYLVGb4n/pQCVK2efeXlIi7TOZ4S3GqoLMNsx0fUazqicRKBt4+9xNi8VOC57yRe qAccPZ/BUfsqCpzJ67xyTbscw0MottW/Je35j9+2+Y7OkXeVzTnwku7pvITEAanjCl50 W4/ZnFdzI7jPxNrgkF3rmauntqSBIBrF/0pPcOiQmLWL0t+RTop1yctRx86rUK34W42H eQrUDEnKOa/cgXv+LE4rXR3Qn07QG6YfinVictECUbiTBoV31YZpfR+5xejM8+ujzFjN cw== Received: from prod-mail-ppoint4 (a96-6-114-87.deploy.static.akamaitechnologies.com [96.6.114.87] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2qp8fkwrv1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 17 Feb 2019 18:50:22 +0000 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x1HIkwIu011739; Sun, 17 Feb 2019 13:50:22 -0500 Received: from email.msg.corp.akamai.com ([172.27.27.25]) by prod-mail-ppoint4.akamai.com with ESMTP id 2qper45nf9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 17 Feb 2019 13:50:21 -0500 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.1395.4; Sun, 17 Feb 2019 12:50:21 -0600 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.1395.000; Sun, 17 Feb 2019 12:50:21 -0600 From: "Salz, Rich" To: Peter Gutmann , Sankalp Bagaria , "tls@ietf.org" , "T2TRG@irtf.org" Thread-Topic: [TLS] ITDA - IoT Device Authentication Thread-Index: AQHUxbWDTVzMaXNIX0ehxkA72mk1DqXjkZMAgADXCAA= Date: Sun, 17 Feb 2019 18:50:20 +0000 Message-ID: References: <1550365230138.15157@cs.auckland.ac.nz> In-Reply-To: <1550365230138.15157@cs.auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.0.190211 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.45.102] Content-Type: text/plain; charset="utf-8" Content-ID: <156C3FD5546232469DFD8D38453F2ECC@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-17_12:, , 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=893 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902170145 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-17_12:, , 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=957 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902170145 Archived-At: Subject: Re: [TLS] ITDA - IoT Device Authentication 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, 17 Feb 2019 18:50:33 -0000 SSB3b3VsZCBhbHNvIGJlIGNvbmNlcm5lZCBhYm91dCBhZGRpbmcgYSAibmV3IiBzY2hlbWUgdGhh dCBlYXNpbHkgZnVuY3Rpb25zIGFzIGFuIG9yYWNsZS4NCg0K77u/T24gMi8xNi8xOSwgODowMSBQ TSwgIlBldGVyIEd1dG1hbm4iIDxwZ3V0MDAxQGNzLmF1Y2tsYW5kLmFjLm56PiB3cm90ZToNCg0K ICAgIFNhbmthbHAgQmFnYXJpYSA8c2Fua2FscC5uaXR0QGdtYWlsLmNvbT4gd3JpdGVzOg0KICAg IA0KICAgID5XZSBwcm9wb3NlIHRoYXQgdGhlIHNlcnZlciBpcyBhdXRoZW50aWNhdGVkIHVzaW5n IFg1MDkgY2VydGlmaWNhdGUgaW4gYSBUTFMNCiAgICA+MS4zIGxpa2UgcHJvdG9jb2wuIFRoZSBT ZXJ2ZXIgc2VuZHMgMzItYnl0ZSBDaGFsbGVuZ2UuIENsaWVudCByZXBsaWVzIGJ5DQogICAgPnNl bmRpbmcgMzItYnl0ZSBSZXNwb25zZS4NCiAgICANCiAgICBTb21ldGhpbmcgdmVyeSBzaW1pbGFy IHRvIHRoaXMgYWxyZWFkeSBleGlzdHMgaW4gdGhlIGZvcm0gb2YgQ0hBUC9NU0NIQVAgb3Zlcg0K ICAgIFBFQVAvRUFQLVRMUy9FQVAtVFRMUy4gIEl0J3Mgc3VwcG9ydGVkIGJ5IGV2ZXJ5IFJhZGl1 cyBzZXJ2ZXIgYW5kIHZhc3QgbnVtYmVycw0KICAgIChwcm9iYWJseSBiaWxsaW9ucykgb2YgY2xp ZW50cy4gIFRvIGNvbXBldGUgYWdhaW5zdCB0aGlzIGh1Z2UgaW5zdGFsbGVkIGJhc2UsIGFueQ0K ICAgIG5ldyBwcm9wb3NhbCB3b3VsZCBoYXZlIHRvIGJlIHByZXR0eSBzcGVjdGFjdWxhci4uLg0K ICAgIA0KICAgIFBldGVyLg0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQogICAgVExTIG1haWxpbmcgbGlzdA0KICAgIFRMU0BpZXRmLm9y Zw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQogICAgDQoN Cg== From nobody Sun Feb 17 17:38:11 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97A91130E86 for ; Sun, 17 Feb 2019 17:38:09 -0800 (PST) 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 EiTXURtPV64H for ; Sun, 17 Feb 2019 17:38:07 -0800 (PST) Received: from mail-ot1-x341.google.com (mail-ot1-x341.google.com [IPv6:2607:f8b0:4864:20::341]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7825130E94 for ; Sun, 17 Feb 2019 17:38:06 -0800 (PST) Received: by mail-ot1-x341.google.com with SMTP id i5so25648844oto.9 for ; Sun, 17 Feb 2019 17:38:06 -0800 (PST) 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=zIheLh3CCN4aD8aviI8TqKeETE6GNpc3FhQyW3Nvrfw=; b=m/SWN4QmIE4vkC+1exyB9jvz9soy/a9us8yXNHSEjUaEEZwy/abu5e2N2d/AukaF2k NBTdFm5TMsCMj+607l3i6ZHqJ5YSKAlM5RxPbKatQwnqZpbmCQ5RWrygNv2uVbapJxEd s8lNevLOP/fLPxKXCKOs86psAgAR/k8Ra5A5fDOdAhT27XWk3Fdx3oOglZ33tlFywHpx Q2ppKzDPpZWf6qKeOtpskVVWfwiH7P0TUhZvNwNvN+hhru1ZTnYLwuM3oOhbDQRGUGBC Q3KjELQ6Z3rvI5o96tUIF3oUHERtxW8zXBWimH13zzlm/ypa1QeoX7LJbDCExWHAw1DF /orw== 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=zIheLh3CCN4aD8aviI8TqKeETE6GNpc3FhQyW3Nvrfw=; b=LRPdvcxSYUKXe0jiqiPgE8rA+W7BPF5GHUw1BK34pXeb7a2+gGOf100Rr5PomiNYMD 9FomrG7k79fO5mT+N75JBm1rlWw0bAioDjSc8SM+53FTafaLuwc+QMyejXO2E0UCefMK j8ypjEDy+UY7StZdDbDBvjeU+Lbgh2niHmCYU1Ucv7weuTIg7QmVux4BMIlBV0hOxyiV S6nHswsH9lNoqnr0asudeThKQbniRWeXqcN6bs76+gfFhKrJtkIUBIGh6PVOa+CRiZEH 0rgRYl1uJKW2csgQGS/SR3vcgYXWsRO50w5cBfdy2coZlduArXVU2rSF1eQ//QReqY8p b7qQ== X-Gm-Message-State: AHQUAuYXy30FD7PPcq1xivTXRC91pIhQ25vtOn/Br+WfBtqBMuP7fCQt ltRhR4sVTLjn/rS7LoKZmJdCrM586gmdyNJUlbw= X-Google-Smtp-Source: AHgI3IYmmlaxzph/GYzyBZFRm+uY/EU3CWuSssQyX3kDuaXygDoYwYE9HBZnxwo2UB2uUbauv7Bg09bxAUUPu/8o2Io= X-Received: by 2002:a9d:130:: with SMTP id 45mr12925383otu.355.1550453885900; Sun, 17 Feb 2019 17:38:05 -0800 (PST) MIME-Version: 1.0 References: <1550365230138.15157@cs.auckland.ac.nz> In-Reply-To: From: Sankalp Bagaria Date: Mon, 18 Feb 2019 07:07:53 +0530 Message-ID: To: "Salz, Rich" Cc: Peter Gutmann , tls@ietf.org, "T2TRG@irtf.org" Content-Type: multipart/alternative; boundary="0000000000001c1b210582212d38" Archived-At: Subject: Re: [TLS] ITDA - IoT Device Authentication 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, 18 Feb 2019 01:38:10 -0000 --0000000000001c1b210582212d38 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Servers are usually more secure and can store challenge/ response pairs for all clients it connects with in Oracle. Remote IoT devices can be attacked physically and keys retrieved from them. To prevent this, costly and complex tamper proof cryptographic circuitry is used. PUF provides a cheaper alternative to complex and expensive cryptographic circuitry. As keys need not be stored at the IoT device. When PUF receives a challenge from server, it calculates response and sends it to server. Thanks and Regards, Sankalp Bagaria.. On Mon 18 Feb, 2019, 12:20 AM Salz, Rich, wrote: > I would also be concerned about adding a "new" scheme that easily > functions as an oracle. > > =EF=BB=BFOn 2/16/19, 8:01 PM, "Peter Gutmann" = wrote: > > Sankalp Bagaria writes: > > >We propose that the server is authenticated using X509 certificate i= n > a TLS > >1.3 like protocol. The Server sends 32-byte Challenge. Client replie= s > by > >sending 32-byte Response. > > Something very similar to this already exists in the form of > CHAP/MSCHAP over > PEAP/EAP-TLS/EAP-TTLS. It's supported by every Radius server and vas= t > numbers > (probably billions) of clients. To compete against this huge > installed base, any > new proposal would have to be pretty spectacular... > > Peter. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > --0000000000001c1b210582212d38 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Servers = are usually more secure and can store challenge/ response pairs for all cli= ents it connects with in Oracle.

Remote IoT devices can be attacked physically and keys retrieved = from them. To prevent this, costly and complex tamper proof cryptographic c= ircuitry is used.

PUF pr= ovides a cheaper alternative to complex and expensive cryptographic circuit= ry. As keys need not be stored at the IoT device. When PUF receives a chall= enge from server, it calculates response and sends it to server.

Thanks and Regards,
Sankalp Bagaria..



On Mon = 18 Feb, 2019, 12:20 AM Salz, Rich, <= rsalz@akamai.com> wrote:
I w= ould also be concerned about adding a "new" scheme that easily fu= nctions as an oracle.

=EF=BB=BFOn 2/16/19, 8:01 PM, "Peter Gutmann" <pgut001@= cs.auckland.ac.nz> wrote:

=C2=A0 =C2=A0 Sankalp Bagaria <sankalp.nitt@gmail.com> writes= :

=C2=A0 =C2=A0 >We propose that the server is authenticated using X509 ce= rtificate in a TLS
=C2=A0 =C2=A0 >1.3 like protocol. The Server sends 32-byte Challenge. Cl= ient replies by
=C2=A0 =C2=A0 >sending 32-byte Response.

=C2=A0 =C2=A0 Something very similar to this already exists in the form of = CHAP/MSCHAP over
=C2=A0 =C2=A0 PEAP/EAP-TLS/EAP-TTLS.=C2=A0 It's supported by every Radi= us server and vast numbers
=C2=A0 =C2=A0 (probably billions) of clients.=C2=A0 To compete against this= huge installed base, any
=C2=A0 =C2=A0 new proposal would have to be pretty spectacular...

=C2=A0 =C2=A0 Peter.

=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


--0000000000001c1b210582212d38-- From nobody Sun Feb 17 17:45: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 63A28130EA7; Sun, 17 Feb 2019 17:45:49 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQsZHFt9JYVz; Sun, 17 Feb 2019 17:45:47 -0800 (PST) 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 3B98D130EA2; Sun, 17 Feb 2019 17:45:46 -0800 (PST) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x1I1hWkl004235; Mon, 18 Feb 2019 01:45:43 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=hGE8H8960DX8l5wZU/ClrtAc9afvuiwCa1z02gC0Vqc=; b=O5o+fc2mx1yEY00KvmImClUApG9JnFvsrTB1mVIlU/jdkp6pb56qSlE1jEzXoA5iUsGy P1+KwtbzgDFKo1nCTKItxbcOrnWa1+DpEosM8/kbqP8uG7wfGayZ518He95p2KGM4dOA VlxYEp7QtQaVkNM3A3eSBuhXsQWekcI19c5jD0aYAvDcMY1iXLuc5d5348RbSUc32AVO t+2EosC7l5FhYNgGjIqY84Er056meZhe+b+IRPbPck82/97Ym2AiO2ublUaL571DGBOJ dQNPLwBRdNhtSkZQH8gRklP97nYN0h+HuLSjqg6r/JZrJ5lt99xZQivAknNscy4VFyOO /A== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0a-00190b01.pphosted.com with ESMTP id 2qpbekp050-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 18 Feb 2019 01:45:42 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x1I1WBDJ017171; Sun, 17 Feb 2019 20:45:41 -0500 Received: from email.msg.corp.akamai.com ([172.27.25.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 2qpeqyvkp1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 17 Feb 2019 20:45:40 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.27.105) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sun, 17 Feb 2019 19:45:38 -0600 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.1395.000; Sun, 17 Feb 2019 19:45:37 -0600 From: "Salz, Rich" To: Sankalp Bagaria CC: Peter Gutmann , "tls@ietf.org" , "T2TRG@irtf.org" Thread-Topic: [TLS] ITDA - IoT Device Authentication Thread-Index: AQHUxbWDTVzMaXNIX0ehxkA72mk1DqXjkZMAgADXCACAAMWwgP//rleA Date: Mon, 18 Feb 2019 01:45:36 +0000 Message-ID: References: <1550365230138.15157@cs.auckland.ac.nz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.0.190211 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.45.102] Content-Type: multipart/alternative; boundary="_000_D7C57420DAAD4DD69F1A1A357270CC0Eakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-18_01:, , 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=610 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902180010 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-18_01:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=619 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902180012 Archived-At: Subject: Re: [TLS] ITDA - IoT Device Authentication 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, 18 Feb 2019 01:45:49 -0000 --_000_D7C57420DAAD4DD69F1A1A357270CC0Eakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RG8geW91IGtub3cgd2hhdCBJIG1lYW4gYnkgYW4gb3JhY2xlPw0KDQoNCiAgKiAgIFBVRiBwcm92 aWRlcyBhIGNoZWFwZXIgYWx0ZXJuYXRpdmUgdG8gY29tcGxleCBhbmQgZXhwZW5zaXZlIGNyeXB0 b2dyYXBoaWMgY2lyY3VpdHJ5LiBBcyBrZXlzIG5lZWQgbm90IGJlIHN0b3JlZCBhdCB0aGUgSW9U IGRldmljZS4gV2hlbiBQVUYgcmVjZWl2ZXMgYSBjaGFsbGVuZ2UgZnJvbSBzZXJ2ZXIsIGl0IGNh bGN1bGF0ZXMgcmVzcG9uc2UgYW5kIHNlbmRzIGl0IHRvIHNlcnZlci4NCg== --_000_D7C57420DAAD4DD69F1A1A357270CC0Eakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <3225C2D70FE4E746A137FFDE77054F52@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNv TGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDou NWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFs MCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRp b25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMDc2MDA0NTsNCgltc28tbGlzdC10eXBl Omh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE4NzE4MTg3ODYgLTEyODkyODYzMCA2 NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5 ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCW1zby1iaWRpLWZv bnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWFuc2ktZm9udC13ZWlnaHQ6Ym9sZDt9DQpAbGlzdCBs MDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9 DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRvIHlvdSBrbm93IHdoYXQgSSBtZWFu IGJ5IGFuIG9yYWNsZT88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGlu IiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+UFVGIHByb3ZpZGVzIGEgY2hlYXBl ciBhbHRlcm5hdGl2ZSB0byBjb21wbGV4IGFuZCBleHBlbnNpdmUgY3J5cHRvZ3JhcGhpYyBjaXJj dWl0cnkuIEFzIGtleXMgbmVlZCBub3QgYmUgc3RvcmVkIGF0IHRoZSBJb1QgZGV2aWNlLiBXaGVu IFBVRiByZWNlaXZlcyBhIGNoYWxsZW5nZSBmcm9tIHNlcnZlciwgaXQgY2FsY3VsYXRlcw0KIHJl c3BvbnNlIGFuZCBzZW5kcyBpdCB0byBzZXJ2ZXIuPG86cD48L286cD48L2xpPjwvdWw+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D7C57420DAAD4DD69F1A1A357270CC0Eakamaicom_-- From nobody Sun Feb 17 19:00:11 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C37D130EB0 for ; Sun, 17 Feb 2019 19:00:10 -0800 (PST) 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 IEIaEEA0UaH5 for ; Sun, 17 Feb 2019 19:00:08 -0800 (PST) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 374861295EC for ; Sun, 17 Feb 2019 19:00:08 -0800 (PST) Received: by mail-ot1-x329.google.com with SMTP id g1so25838402otj.11 for ; Sun, 17 Feb 2019 19:00:08 -0800 (PST) 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=qB0Uguyr+YiLJCY9RufVbuZlfOUU94LRYcxNOd/Qsf0=; b=a6t4N1cJg2g7AqOFRO/k4iWj6qCI7x/SZ3C6DAUwHiFWz7VLyP+RnS8wln9rI06NIt LuJ13TToDtJrsNAPPPBz3tVgEIrSFyQVOGxhZ0NFW2vFEka/OPVEVu4J1eaM0nP2PPwo wzPERSCV8KikYZHfByWPOgKaZxUeazw8pmZA1O73F1C8VcffSD8sK/HrIxcwobLCPIjZ 6JbE8D2o7dVzQm672vsXsJXye42Hh8YsP92ZX5QggAnHJaxecPEj49/dVnCT4jEbGJJM sCtpS+4uMMeZmeXi9Gl3HGSJkxINSG1q4mxipfYgr1RNm07S5KGfUlo33pRMHH0OMNo6 6m1Q== 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=qB0Uguyr+YiLJCY9RufVbuZlfOUU94LRYcxNOd/Qsf0=; b=QbhnUo+7IOaKvdA2eB0RLm63Gv3II+5OHhknVsjUkxeRQhrtr/oN/4WawsVtmrj6Jj lX3SusN7nhGAAkEwGkPzottw8hCr02ItHmgNWnS4SP5lA5CBiDK7AJvxFN17ugNqd+Xw a1BMGD3GM9XLJ8Bow35HUJsjwY5x1DoDM6gp90VEDY9FIzqVuFVZ0vrcrmKOEAX4Pm6T yfj41vQkvBYZ1RCdyc24wH51snz9U+Dj7V9WMTJL6ISJNLKCZzgV73KuRsWOvFQS8M6s YWNCnf8MPnVx9v4TDGThGgK6TSnQ5XBMq0HCTzNWR0GNtc1Uj+bb7tQDmN7g+fMT3h/5 7yQQ== X-Gm-Message-State: AHQUAuYXi5bvxhg+zfiOlGpp+fLAmVuNKbutkwrdYC+5z6zVsOu4aZUC VUKWpECZ4oIJPYWkBz3WmKuX+4I3jB7UKv9XxKU= X-Google-Smtp-Source: AHgI3IbREYhLHZRprWSMTJXh05oe1pPibcO2Yxr2sbhP1loOQvx7qkQIHcJ9r20rDvE5WXVYMacRGhIRThQX//zrwSs= X-Received: by 2002:aca:f2c5:: with SMTP id q188mr3318311oih.150.1550458807235; Sun, 17 Feb 2019 19:00:07 -0800 (PST) MIME-Version: 1.0 References: <1550365230138.15157@cs.auckland.ac.nz> In-Reply-To: From: Sankalp Bagaria Date: Mon, 18 Feb 2019 08:29:54 +0530 Message-ID: To: "Salz, Rich" Cc: Peter Gutmann , tls@ietf.org, "T2TRG@irtf.org" Content-Type: multipart/alternative; boundary="00000000000071b99a05822252e2" Archived-At: Subject: Re: [TLS] ITDA - IoT Device Authentication 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, 18 Feb 2019 03:00:10 -0000 --00000000000071b99a05822252e2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I looked in net for Oracle and found the following limitation. PUF depends on physical variations of chip at time of manufacturing and after processing, should function as a better Oracle than any other algorithm. Limitations (as per wikipedia)Edit According to the Church=E2=80=93Turing thesis , no function computable by a finite algorithm can implement a true random oracle (which by definition requires an infinite description because it has infinitely many possible inputs, and its outputs are all independent from each other and need to be individually specified by any description). Thanks and Regards, Sankalp Bagaria. On Mon 18 Feb, 2019, 7:15 AM Salz, Rich, wrote: > Do you know what I mean by an oracle? > > > > - PUF provides a cheaper alternative to complex and expensive > cryptographic circuitry. As keys need not be stored at the IoT device.= When > PUF receives a challenge from server, it calculates response and sends= it > to server. > > --00000000000071b99a05822252e2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I looked= in net for Oracle and found the following limitation. PUF depends on physi= cal variations of chip at time of manufacturing and after processing, shoul= d function as a better Oracle than any other algorithm.=C2=A0

Limitat= ions (as per wikipedia)Edit

Acco= rding to the=C2=A0Church=E2=80=93Turing thesis, no function comput= able by a finite algorithm can implement a true random oracle (which by def= inition requires an infinite description because it has infinitely many pos= sible inputs, and its outputs are all independent from each other and need = to be individually specified by any description).

Thanks and Regards,

Sankalp Bagaria.


On Mon 18 Feb, 2019, 7:15 AM Salz, Rich, <= ;rsalz@akamai.com> wrote:

Do you know what I mean by an oracle?<= /p>

=C2=A0

  • PUF provides a cheaper alternative to complex and expensive cryptograph= ic circuitry. As keys need not be stored at the IoT device. When PUF receiv= es a challenge from server, it calculates response and sends it to server.
--00000000000071b99a05822252e2-- From nobody Sun Feb 17 19:30: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 CCB9D130EBB; Sun, 17 Feb 2019 19:29:59 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AXd-B2Mmx8D9; Sun, 17 Feb 2019 19:29:57 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B36801289FA; Sun, 17 Feb 2019 19:29:57 -0800 (PST) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.27/8.16.0.27) with SMTP id x1I3RZn2021797; Mon, 18 Feb 2019 03:29:49 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=XJVUN19cJaLdxlBhSBZtJz7fSdPQmr8/1q9IxGdugx8=; b=PtSVVgorkHxid8hlIVxzHEdR6/Oc/iWhqYSzZY0t8YgF2udwPDN6sX12rx1JHDTLzU3u g5aTMNGcN6VRlO34EN2smZgFsVXRQlavUmBL5hTfwR4QZjZveMVtCZkoxXBe8kTiQJeY +c1udakFCQJPoUyyHUKmjVJlmhrkS0kyBLridYxqk1d+JqJ6C5fproIRRFya5qNoxCyK 3aTxChuO0quclZw8xNXljGreYh4VJx89Y78rLLvdgr6tGUxw4jor2e5EdR9yGBiyLwOJ KAXmko0l30r++J1Wot0jbDhklcAdYIyMU92/vTKIhPQq2mZhuP9wRD6BFvOBYlW3mqdf EA== Received: from prod-mail-ppoint3 (a96-6-114-86.deploy.static.akamaitechnologies.com [96.6.114.86] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2qpbtax8x2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 18 Feb 2019 03:29:49 +0000 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 x1I3I3RN004622; Sun, 17 Feb 2019 22:29:48 -0500 Received: from email.msg.corp.akamai.com ([172.27.27.25]) by prod-mail-ppoint3.akamai.com with ESMTP id 2qper2exkj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 17 Feb 2019 22:29:48 -0500 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.1395.4; Sun, 17 Feb 2019 21:29:47 -0600 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.1395.000; Sun, 17 Feb 2019 21:29:47 -0600 From: "Salz, Rich" To: Sankalp Bagaria CC: Peter Gutmann , "tls@ietf.org" , "T2TRG@irtf.org" Thread-Topic: [TLS] ITDA - IoT Device Authentication Thread-Index: AQHUxbWDTVzMaXNIX0ehxkA72mk1DqXjkZMAgADXCACAAMWwgP//rleAgABokwD//7SEAA== Date: Mon, 18 Feb 2019 03:29:45 +0000 Message-ID: <1EEEF408-9654-4D44-BF71-447B821F56E6@akamai.com> References: <1550365230138.15157@cs.auckland.ac.nz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.0.190211 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.45.102] Content-Type: multipart/alternative; boundary="_000_1EEEF40896544D44BF71447B821F56E6akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-18_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=663 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902180024 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-18_03:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=660 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902180025 Archived-At: Subject: Re: [TLS] ITDA - IoT Device Authentication 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, 18 Feb 2019 03:30:00 -0000 --_000_1EEEF40896544D44BF71447B821F56E6akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWYgYSBjbGllbnQgd2lsbCBzaWduIGFueSBjaGFsbGVuZ2UgcHJlc2VudGVkIGJ5IGFueSBzZXJ2 ZXIsIGl0IG9wZW4gdXAgYSBiaWcgaG9sZS4gIEFuIGF0dGFja2VyIGNhbiBwcmVzZW50IGEgY2hh bGxlbmdlIHRoYXQgYSAoZnV0dXJlKSB2YWxpZCBzZXJ2ZXIgd2lsbCBwcmVzZW50LCBhbmQgdGhl IGF0dGFja2VyLCBoYXZpbmcgdGhlIGFuc3dlciwgY2FuIHRoZW4gYWN0IGFzIHRoZSBkZXZpY2Ug dG8gdGhlIHNlcnZlci4gRm9yIGV4YW1wbGUsIHRoZSBhdHRhY2tlciBjYW4gaW50ZXJjZXB0IHRo ZSBzZXJ2ZXIvY2xpZW50IGNvbW11bmljYXRpb24sIHByZXNlbnQgdGhlIGNoYWxsZW5nZSBvbiBp dHMgb3duLCBhbmQgdGhlbiBhY3QgYXMgdGhlIGNsaWVudC4NCg0K --_000_1EEEF40896544D44BF71447B821F56E6akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <42608D01AFBD9E4FA4D2FE64E8839923@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmgyDQoJe21zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1s aW5rOiJIZWFkaW5nIDIgQ2hhciI7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu LXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow aW47DQoJZm9udC1zaXplOjE4LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCglmb250LXdlaWdodDpib2xkO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0 eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1y aWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGlu Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0Kc3Bhbi5IZWFkaW5nMkNoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhlYWRpbmcgMiBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUtbGluazoiSGVhZGluZyAyIjsNCglm b250LWZhbWlseToiQ2FsaWJyaSBMaWdodCIsc2Fucy1zZXJpZjsNCgljb2xvcjojMkY1NDk2O30N CnAubS0zODQyNjUyNjE3ODA3NzYwNDc3bXNvbGlzdHBhcmFncmFwaCwgbGkubS0zODQyNjUyNjE3 ODA3NzYwNDc3bXNvbGlzdHBhcmFncmFwaCwgZGl2Lm0tMzg0MjY1MjYxNzgwNzc2MDQ3N21zb2xp c3RwYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLW5hbWU6bV8tMzg0MjY1MjYxNzgwNzc2MDQ3N21zb2xp c3RwYXJhZ3JhcGg7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBp bjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9u dC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFu LkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjg4 NzEwMzcyMjsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTQ1MDg0ODU5MDt9DQpAbGlzdCBsMDps ZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGww OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCm9s DQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwv c3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SWYgYSBjbGllbnQgd2lsbCBzaWduIGFueSBjaGFsbGVuZ2UgcHJlc2VudGVkIGJ5IGFueSBzZXJ2 ZXIsIGl0IG9wZW4gdXAgYSBiaWcgaG9sZS4mbmJzcDsgQW4gYXR0YWNrZXIgY2FuIHByZXNlbnQg YSBjaGFsbGVuZ2UgdGhhdCBhIChmdXR1cmUpIHZhbGlkIHNlcnZlciB3aWxsIHByZXNlbnQsIGFu ZCB0aGUgYXR0YWNrZXIsIGhhdmluZyB0aGUgYW5zd2VyLCBjYW4gdGhlbiBhY3QgYXMgdGhlIGRl dmljZSB0byB0aGUgc2VydmVyLg0KIEZvciBleGFtcGxlLCB0aGUgYXR0YWNrZXIgY2FuIGludGVy Y2VwdCB0aGUgc2VydmVyL2NsaWVudCBjb21tdW5pY2F0aW9uLCBwcmVzZW50IHRoZSBjaGFsbGVu Z2Ugb24gaXRzIG93biwgYW5kIHRoZW4gYWN0IGFzIHRoZSBjbGllbnQuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_1EEEF40896544D44BF71447B821F56E6akamaicom_-- From nobody Sun Feb 17 19:58:11 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5ECB126C01 for ; Sun, 17 Feb 2019 19:58:09 -0800 (PST) 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 shyCypVRiD7m for ; Sun, 17 Feb 2019 19:58:08 -0800 (PST) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0: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 17030124C04 for ; Sun, 17 Feb 2019 19:58:08 -0800 (PST) Received: by mail-ot1-x336.google.com with SMTP id n71so26018220ota.10 for ; Sun, 17 Feb 2019 19:58:07 -0800 (PST) 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=JTDF1+Y7XZE25ILNW+8j0gp8nUWVu3oHUhn6eIJUfqU=; b=dDwviqgIK6tmtY2NdyLegfUdxaOTZKSHpIWztjAZKEZS8D2a/WMwkLsAFcULLm/bDG cyQBrazqV89vknyKB5ekDlUzgWcJgc6o6ZelcHpiGJiYNqZeL7ox1OlzXKxJqV5qZ4mZ A6wsVlIubZ5GYPZKfuIDM8dYal5jtxD4ScOp0NHaOfFoGfQP6x9w+SVHl6jSMNIWST66 PpPjkH/k9PsPULKIIpsnso1mSXJAYhOJgZ8Yl6HQsTxhrybzX92NGMs8aNZtWaunJ1vF LiiDiKSIE6kPFSV/cXSDuaxTP5lVYJkb95VBkhhNivboukyu67aWaLQssfb9mdR4+qlB vvTg== 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=JTDF1+Y7XZE25ILNW+8j0gp8nUWVu3oHUhn6eIJUfqU=; b=ejS7BF97V1+FIs9hHdqhyqLPsJrJGC5BovdJaGsYAOdloZ7CqBjvzMqNK5GP/UgALe 2xrVJH5g8pQM7eI4QPD4Ekbla6Ykl5CALw+8c1UFyBClW4xW8kZaYMKmWbgctf0K5sbe PdRQ+ykmaRCdlIDxkYpPadiEOnHyvqRo19qlFKRD/czdct5szS8fjlUkW7MuK5sWWnGy V1YfcNDZZvJgmCfB8qVcOzUxh5CKDUYynFwlrbK19ELjzuYYAb/wJpmSAfTrnsbHByHR yioZb6MsRBdZajijSJbaiBz5zMEknWPEIe7JXUO/JnC0RMnQDGkCD0zVPxw17+38w6Ir +xWA== X-Gm-Message-State: AHQUAuYKrgeh/bmtGz8ivWJ5mY7O3Qe9oX5olkw1RdUyY+fWre3IQ87r Du6Q4kXu+i+vP5CgXJReAHYHLgLDtim086lnkLg= X-Google-Smtp-Source: AHgI3IZ5talZddYeD0LIMCklDtcLZ1BM7pYx7RE5xeabILx5LYZHTy3Lgf21tVDHcy6cMs6GBJjnK0RJc3y1/LrVgUQ= X-Received: by 2002:a05:6830:118f:: with SMTP id u15mr12517794otq.309.1550462286743; Sun, 17 Feb 2019 19:58:06 -0800 (PST) MIME-Version: 1.0 References: <1550365230138.15157@cs.auckland.ac.nz> <1EEEF408-9654-4D44-BF71-447B821F56E6@akamai.com> In-Reply-To: <1EEEF408-9654-4D44-BF71-447B821F56E6@akamai.com> From: Sankalp Bagaria Date: Mon, 18 Feb 2019 09:27:54 +0530 Message-ID: To: "Salz, Rich" Cc: Peter Gutmann , tls@ietf.org, "T2TRG@irtf.org" Content-Type: multipart/alternative; boundary="000000000000d6cc5f05822321f4" Archived-At: Subject: Re: [TLS] ITDA - IoT Device Authentication 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, 18 Feb 2019 03:58:10 -0000 --000000000000d6cc5f05822321f4 Content-Type: text/plain; charset="UTF-8" Hi, Please see the comments inline. On Mon 18 Feb, 2019, 8:59 AM Salz, Rich, wrote: > If a client will sign any challenge presented by any server, it open up a > big hole. An attacker can present a challenge that a (future) valid server > will present, and the attacker, having the answer, can then act as the > device to the server. > Replay attack is avoided by using a challenge/ response pair only once. 2^32 combinations possible for 32 byte challenge. Server is authenticated by its certificate. An attacker will not be able to do so. > For example, the attacker can intercept the server/client communication, > present the challenge on its own, and then act as the client. > MiTM attack is not possible since server is authenticated by certificate. > An attacker will not have the private key of the server. > Thanks and Regards, Sankalp Bagaria.. > --000000000000d6cc5f05822321f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Please see the comments inline.

On Mon 18 Feb, 2019, 8:59 AM Salz, Rich, <rsalz@akamai.com> wrote:

If a client will sign any challenge presented by any= server, it open up a big hole.=C2=A0 An attacker can present a challenge t= hat a (future) valid server will present, and the attacker, having the answ= er, can then act as the device to the server.

Replay attack is= avoided by using a challenge/ response pair only once. 2^32 combinations p= ossible for 32 byte challenge.=C2=A0

Server is authenticated by its certificate. An attacker will n= ot be able to do so.

= For example, the attacker can intercept the server/client communication, p= resent the challenge on its own, and then act as the client.


=C2=A0MiTM attack is not possible since serve= r is authenticated by certificate. An attacker will not have the private ke= y of the server.

= Thanks and Regards,
Sankalp Bagaria..

--000000000000d6cc5f05822321f4-- From nobody Sun Feb 17 21:14:17 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66075130EC3 for ; Sun, 17 Feb 2019 21:14:15 -0800 (PST) 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, 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=nymbus-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 c5R_uCfXdd1t for ; Sun, 17 Feb 2019 21:14:11 -0800 (PST) Received: from mail-pf1-x442.google.com (mail-pf1-x442.google.com [IPv6:2607:f8b0:4864:20::442]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8559130EC1 for ; Sun, 17 Feb 2019 21:14:10 -0800 (PST) Received: by mail-pf1-x442.google.com with SMTP id n125so653015pfn.5 for ; Sun, 17 Feb 2019 21:14:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nymbus-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=y/zFAhhTKankbPbki4tEjBSqd31uZJa8cUaCOer61xc=; b=zUKsg7USOhtCBUYz2VmOZquDYmsb/+7TDi0vuGpcYZ9tFefkTu0EDAB0M4hBPG4rIN wP3Gf/CMJYO0PUF/K+8hVEPE3N+QV+b14MlQwjz9sY+rIS6mfWP4JXrAVMrynvjSsXts OosuRBE3AHW+QI2uFgv2ALrZUGs5WQhN/hW8OzinubbNwCRwQTzlNzHXs7ukxCK4rYbI 1jzpv4gZ9yG7NPBIC4w6DicPIaJDNMy1BGLE0Kbi5wGG866irG8NdCHWmyEswllHzIRP VGUBAqJ15UcB6Xy86WOKlAkmT/knSpgwXhYNwWpgBxKU0gWz0mjCxJKaEWSPQpo/mwRu aAcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=y/zFAhhTKankbPbki4tEjBSqd31uZJa8cUaCOer61xc=; b=IL8tPqFdCini/PkXfSruh9sUkP5gK/YFTrs7ZTiwoUs1en0BFXa4dmpxevdje78/ey af7kgtI2MRSTjmo/r65RJri8PZCUtO4EbIpR6Pr1lzD55TUlfLyFkW/uGK5Ej7a9pWtl nKnR63nHodYaFOUJboGI9W/fpLrmzpK+7ZCTCxkLnnotDA+85qUTrFwtmLcb0p+APhD/ w38QxHU2DovohUWv4Km0Qy4ur1UwmtuXS7sd72A/9KGmSIslJBT5GSTg/+2T3xtIZE2T 95x/CpU016RMTrK0TYvLRJvw1wKJHQOfzAUCj2VyscDM0ElcK3DsAkC6tKrCW9g9eBV7 aZ0w== X-Gm-Message-State: AHQUAubiz2uvlf5wBIAVzTgkYHsuzR8Wb6HhG+hKt/kwkpuZJjeqCWvU Km9Ix4+oE6rdZGN0aJFZU9oPmw== X-Google-Smtp-Source: AHgI3Ia8uJYIQwihKKboWMIh/exP8gERnIrCA5Pr3e5Q00rfX4GZy8l/ED7ojm4lmumxkawqkk+7/A== X-Received: by 2002:a63:4346:: with SMTP id q67mr16725345pga.92.1550466850249; Sun, 17 Feb 2019 21:14:10 -0800 (PST) Received: from [192.168.1.97] (172-125-76-95.lightspeed.sntcca.sbcglobal.net. [172.125.76.95]) by smtp.gmail.com with ESMTPSA id e65sm17089228pfc.184.2019.02.17.21.14.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 17 Feb 2019 21:14:09 -0800 (PST) From: Paul Lambert Message-Id: <00F86909-D260-4267-AC79-D5D63AD6DBAD@nymbus.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_79A3FFD5-9578-4B4B-A7CC-681160980C15" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Sun, 17 Feb 2019 21:14:45 -0800 In-Reply-To: Cc: tls@ietf.org, T2TRG@irtf.org, Russell Housley To: Sankalp Bagaria References: X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [TLS] [T2TRG] ITDA - IoT Device Authentication 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, 18 Feb 2019 05:14:15 -0000 --Apple-Mail=_79A3FFD5-9578-4B4B-A7CC-681160980C15 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Sankalp, The schema below is the wrong way to use PUF technology for IoT device = authentication.=20 PUF is already being used in many fielded IoT systems. You simply use = the device unique PUF secret to create a public/private key pair. The = public key is then extracted and used to authentic the device. This = enables tracking and identification of the device through its full = life-cycle. Early observation of the device-unique public key mitigates = a variety of supply chain attacks. The extracted public key may be = certified by a X.509 CA. The PUF derived identity may then be used = directly in a TLS protocol exchange.=20 Early assignment of public key certificate to a device enables strong = protection of the device during manufacturing. The PUF device keys may = be used as part of the boot process to enable per-device protection of = sensitive firmware or other cryptographic secrets. =20 PUF may be instantiated as HW or SW. Your scheme mentions " signal path = can affect the delay in the propagation of a signal=E2=80=9D =E2=80=A6 = the seems to imply a HW based implementation (perhaps a Butterfly PUF). = A simpler implementation would be to use SRAM PUF where the entropy in = uninitialized SRAM is used to generate the device unique secrets. SRAM = based PUF can be readily integrated into existing MCU devices. The simplest application of PUF in IoT uses a device unique symmetric = secret key to serve as a key to encrypt sensitive data in unprotected NV = memory. This is basically a low-level key vault that provides = confidential and non-non-maleable secure device storage. This is a very = attractive alternative to OTP memory that s more expensive and of = limited size.=20 PUF is just one way for a device to obtain unique secrets (symmetric or = asymmetric). It has been standard practice to =E2=80=9Cinject=E2=80=99 = secrets during manufacturing. Injection requires more trust in the key = distribution and provisioning process than approaches that generate keys = on device and never expose these secrets.=20 Long-lived device unique public keys and certificates that provide = protection through the full manufacturing life-cycle are an interesting = topic area =E2=80=A6 Challenge/response PUF protocols are not useful or = interesting for standardization. Paul > On Feb 15, 2019, at 9:06 PM, Sankalp Bagaria = wrote: >=20 > Hello, >=20 > Please take a look at this and advise if it is a good idea and whether = it should be pursued. >=20 > Thanks, >=20 > Sankalp Bagaria. >=20 >=20 >=20 > ITDA - IoT Device Authentication >=20 > Abstract: We propose that the server is authenticated using X509 = certificate in a TLS 1.3 like protocol. The Server sends 32-byte = Challenge. Client replies by sending 32-byte Response. Thus the client = is authenticated. In the transfer of the application data, the client = may send more challenge-response pairs as encrypted data for updating = database of server. Client doesn=E2=80=99t store challenge/response or = key or certificate. Both the server and the client can initiate the = handshake. >=20 > Background >=20 > Traditionally, there are two ways to authenticate a device: a = centralised CA issuing certificates and block-chain. Both require costly = infrastructure and can=E2=80=99t be used to authenticate IoT devices, = which are of low cost. While block-chain provides non-repudiation, = transactions are distributed all over the net. X.509 certificates are = costlier than many sensors. >=20 > Another option is Physically Uncloneable Functions (PUF). Because of = the random variations taking place during the manufacturing process of = an IC, no two ICs are same. For instance, the impurities present in the = IC can affect the doping level of an IC and thus cause signal paths to = change. These slight variations in the signal path can affect the delay = in the propagation of a signal which can be measured and used to = identify the chip. This uniqueness of an IC can be used to authenticate = the device in which the IC has been placed. >=20 > =20 > PUF: The Concept >=20 >=20 >=20 > Figure 1: PUF =E2=80=93 Multiplexer pair=E2=80=99s output delay = compared by arbiter (latch) >=20 > When the same input is fed to two adjacent multiplexers, depending on = the impurities and other manufacturing variations, the delay observed in = the propagation of the signal to one multiplexer output is different = from that of the other. This delay can be compared using an arbiter = (latch) and the final output generated. Several pairs of multiplexers = can be operated in parallel or a series of inputs can be fed to the same = pair of multiplexer. Thus, a set of output bits is generated that is = specific to the chip. >=20 > The set of input bits is called challenge and the set of output bits = is called response. A challenge/ response pair is specific to the chip. = The experimental results [4] show that two identical PUF circuits on two = different chips have different outputs for the same input with a = probability of 23% (inter-chip variation). On the other hand, multiple = measurements on the same chip are different only with 0.7% probability. = As both the multiplexers on the chip are in the same environment, the = PUF output is mostly independent of the environmental variations. >=20 > Limitations of current PUF implementation >=20 > To prevent the replay attack, a challenge =E2=80=93 response pair can = be used only once. To enable this, a large set of challenge =E2=80=93 = response pairs have to be generated at the installation time and = pre-stored in the server. A server can have many devices connected to = it. So, it has to have a large database and computational power. >=20 > Moreover, this setting is inflexible. There is the problem of = distributing challenge/ response pairs from client to server. When the = PUF is commissioned, challenge/ response pairs have to be generated at = the chip and taken to server. If the server exhausts its supply of = challenge-response pairs, it cannot be easily renewed. >=20 > =20 > Our solution >=20 > Thus in our solution, we combine the best of X.509 certificate and = PUF. Certificate is well-tested technology and provides flexible way to = distribute keys. PUF is relatively new but allows a cheap solution to = IoT authentication problem. Moreover, there is no need to store keys or = certificates at the client-side. >=20 > The Protocol Combining TLS 1.3 and Challenge/ Response of PUF >=20 > The Protocol with Client Starting the Connection >=20 > Client starts by generating its key_share and sends it to Server for = normal TLS connection. It also sends acceptable ciphersuites. Server = generates its own private key and joins with client's keyshare to get = the shared secret. It takes this share-secret and combines with hash of = the handshake till that point to generate handshake keys. The connection = is encrypted from this point on. >=20 > =20 > The server sends its X.509 certificate, CertificateVerify and = PUF_Challenge. The client also generates the handshake key from its = private key and server's public key. It then verifies the certificate, = generates PUF_Response. It encrypts the PUF_Response and sends to the = Server. Server verifies it, generates Application Key from Handshake_key = and hash of the Handshake. >=20 > =20 > The Client also generates the Application Keys similarly. The = Application data flows in encrypted form. To start, Server requires only = one pair of Challenge/ Response. When server's stock is depleting it may = request more challenge/ response pairs in application data. Client may = generate more pairs and send them as encrypted data to server which = stores in its database for future use. Client should delete its copy = permanently so that an adversary can't recover it by attacking hardware. >=20 > Client = Server >=20 > ClientHello =20 >=20 > + key_share --------> =20 >=20 > = ServerHello >=20 > = + key_share =20 >=20 > = {Encrypted Extensions} >=20 > = {Certificate} >=20 > {CertificateVerify} >=20 > <--------- = {PUF_Challenge} >=20 > PUF_Response ----------> =20 >=20 > = {Finished} >=20 > <--------- = [Application Data] >=20 > {Finished} = =20 >=20 > [Application Data} <--------> = [Application Data] >=20 > =20 >=20 > =20 >=20 > The Protocol with Server Starting the Connection >=20 > The Server may also initiate connection by sending Server Hello. = Client replies by sending Client Hello with its key_share and list of = acceptable ciphersuites. When server receives Client_Hello, it proceeds = just like the above use-case. >=20 > =20 > Client = Server >=20 > <----------- = ServerHello >=20 > =20= > ClientHello =20 >=20 > + key_share ----------> = =20 >=20 > key_share =20 >=20 > = {Encrypted Extensions} >=20 > = {Certificate} >=20 > = {CertificateVerify} >=20 > = <----------- {PUF_Challenge} >=20 > =20 > {PUF_Response} ----------=C3=A0 >=20 > = {Finished} >=20 > = <--------- [Application Data] >=20 > {Finished} = =20 >=20 > [Application Data} <--------> = [Application Data] >=20 > =20 > The Client doesn't store the Keys, Challenge/ Response or the = Certificate. Each session is a unit in itself. Everything is calculated = on the fly. This may create latency but this minimizes the resource = requirement. It is required that when the IoT device is commissioned, = atleast one Challenge/ Response pair is generated and stored in Server = Database. Whenever the challenge - response pairs are depleting, on = Server's request, the Client can generate them and send to the Server as = encrypted data. After sending, the Client deletes its copy of Challenge = / Response. >=20 > Future Work: >=20 > 1) Complete the development of protocol described above by = including use cases like when does the Handshake fails and Challenge/ = Response has to be re-negotiated; when Resumption happens etc. > 2) Adapt other IoT protocols like QUIC, DTLS to work with PUF. > 3) Validate the solution with PUF-enabled Evaluation kits. >=20 > References =E2=80=93 >=20 > [1] RFC 5280 - Internet X.509 Public Key Infrastructure Certificate = and Certificate Revocation List (CRL) Profile. = https://tools.ietf.org/html/rfc5280 = > [2] 50 Billion IoT devices will be connected by 2020 =E2=80=93 Post = =E2=80=93 The Things Network. = https://www.thethingsnetwork.org/community/thessaloniki/post/50-billion-io= t-devices-will-be-connected-by-2020 = > [3] https://en.wikipedia.org/wiki/Physical_unclonable_function = > [4] G. E. Suh and S. Devadas, =E2=80=9CPhysical unclonable functions = for device authentication and secret key generation,=E2=80=9D in = Proceedings of the 44th annual Design Automation Conference, San Diego, = CA, Jun. 2007, pp.9=E2=80=9314 = https://people.csail.mit.edu/devadas/pubs/puf-dac07.pdf = > [5] = http://people.csail.mit.edu/rudolph/Teaching/Lectures/Security/Lecture-Sec= urity-PUFs-2.pdf = > [5] Blaise Gassend, Dwaine Clarke, Marten van Dijk and Srinivas = Devadas. Silicon Physical Random Functions. Proceedings of the Computer = and Communications Security Conference, November 2002 = http://csg.csail..mit.edu/pubs/memos/Memo-456/memo-456.pdf = > [6] C. Herder, L. Ren, M. van Dijk, M-D. Yu, and S. Devadas, "Trapdoor = Computational Fuzzy Extractors and Cryptographically-Secure Physical = Unclonable Functions", IEEE Transactions on Dependable and Secure = Computing, January 2017 = https://people.csail.mit.edu/devadas/pubs/trapdoor.pdf = > [7] Helfmeier, Clemens; Nedospasov, Dmitry; Boit, Christian; Seifert, = Jean-Pierre (2013). Cloning Physically Unclonable Functions = (PDF). IEEE = Hardware Oriented Security and Trust (IEEE HOST 2013). June 2=E2=80=933, = 2013 Austin, TX, USA >=20 > http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=3D6581556 = > [8] Merchan Jorge Guajardo = , Shankaran S. Kumar = , Pim T. Tuyls = , Geert J. Schrijen = Identification of devices using physically = unclonable functions=20 > WO 2009024913 A2 >=20 > [9] M. Fyrbiak, C. Kison, W. Adi. Construction of Software-Based = Digital Physical Clone Resistant Functions. 2013 Fourth International = Conference on Emerging Security Technologies = http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=3D6680199 = > = [10]https://www.esat.kuleuven.be/cosic/thesis/2011/mai/CloningTheUnclonabl= e_en.pdf = > [11] Srinivas Devadas, Edward Suh, Sid Paral, Richard Sowell, Tom = Ziola, Vivek Khandelwal . Design and Implementation of PUF-Based = =E2=80=9CUnclonable=E2=80=9D RFID ICs for Anti-Counterfeiting and = Security Applications. = http://verayo.com/pdf/2008_Verayo_IEEE_RFID_Paper.pdf = > [12] Rishab Nithyanand, John Solis. A Theoretical Analysis: Physical = Unclonable Functions and The Software Protection Problem. SANDIA REPORT = SAND2011-6673. Printed in 2011. = http://prod.sandia.gov/techlib/access-control.cgi/2011/116673.pdf = > [13] Shahriar B. Shokouhi. Cooperative Artificial Immune System And = Recurrent Neural Network Error Correction Scheme For Generating Robust = Hardware Key. International Journal Of Electrical, Electronics And Data = Communication. ISSN: 2320-2084. Volume-4, Issue-5,May 2016 = http://www.iraj.in/journal/journal_file/journal_pdf/1-254-146502604154-59.= .pdf = > [15] D. Lim. Extracting secret keys from integrated circuits. = Master=E2=80=99s thesis, Massachusetts Institute of Technology, May = 2004. http://csg.csail.mit.edu/pubs/memos/Memo-476/DaihyunLimThesis.pdf = > [16] Ulrich Ruhrmair. On the Formal Foundations of PUFs and Related = Primitives. October 19, 2016. = https://depositonce.tu-berlin.de/bitstream/11303/5994/4/ruehrmair_ulrich.p= df = > [17] = https://patents.google.com/patent/US20090083833A1/en?q=3DPUF&q=3Dphysicall= y+unclonable+function&oq=3DPUF+physically+unclonable+function = > [18] = https://patents.google.com/patent/US8290150B2/en?q=3Dauthentication&q=3DPU= F&q=3Dphysically+unclonable+function&oq=3Dauthentication+PUF+physically+un= clonable+function = > [19] = https://patents.google.com/patent/US20140279532A1/en?q=3Dauthentication&q=3D= PUF&q=3Dphysically+unclonable+function&oq=3Dauthentication+PUF+physically+= unclonable+function = > [20] RFC 8446 =E2=80=93 The Transport Layer Security (TLS) Protocol = Version 1.3 https://datatracker.ietf.org/doc/rfc8446/ = > [21] The New Illustrated TLS Connection https://tls13.ulfheim.net/ = > [22] Internet-draft: State-of-the-Art and Challenges for the = Internet of Things Security draft-irtf-t2trg-iot-seccons-16 >=20 > [23] Internet-draft: TLS 1.3 Extension for Certificate-based = Authentication with an External Pre-Shared Key. = draft-housley-tls-tls13-cert-with-extern-psk-03 >=20 > _______________________________________________ > T2TRG mailing list > T2TRG@irtf.org > https://www.irtf.org/mailman/listinfo/t2trg --Apple-Mail=_79A3FFD5-9578-4B4B-A7CC-681160980C15 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Sankalp,

The schema below is the wrong way to use PUF technology for = IoT device authentication. 

PUF is already being used in many fielded IoT systems. You = simply use the device unique PUF secret to create a public/private key = pair. The public key is then extracted and used to authentic the device. = This enables tracking and identification of the device through its full = life-cycle. Early observation of the device-unique public key mitigates = a variety of supply chain attacks. The extracted public key may be = certified by a X.509 CA. The PUF derived identity may then be used = directly in a TLS protocol exchange. 

Early assignment of public key = certificate to a device enables strong protection of the device during = manufacturing. The PUF device keys may be used as part of the boot = process to enable per-device protection of sensitive firmware or other = cryptographic secrets.  

PUF may be instantiated as HW or SW. = Your scheme mentions " signal path can affect the delay in the = propagation of a signal=E2=80=9D =E2=80=A6 the seems to imply a HW based = implementation (perhaps a Butterfly PUF). A simpler implementation would = be to use SRAM PUF where the entropy in uninitialized SRAM is used to = generate the device unique secrets. SRAM based PUF can be readily = integrated into existing MCU devices.

The simplest application of PUF in IoT = uses a device unique symmetric secret key to serve as a key to encrypt = sensitive data in unprotected NV memory.  This is basically a = low-level key vault  that provides confidential and = non-non-maleable secure device storage. This is a very attractive = alternative to OTP memory that s more expensive and of limited = size. 

PUF = is just one way for a device to obtain unique secrets (symmetric or = asymmetric). It has been standard practice to =E2=80=9Cinject=E2=80=99 = secrets during manufacturing. Injection requires more trust in the key = distribution and provisioning process than approaches that generate keys = on device and never expose these secrets. 

Long-lived device unique public keys = and certificates that provide protection through the full manufacturing = life-cycle are an interesting topic area =E2=80=A6 =  Challenge/response PUF protocols are not useful or interesting for = standardization.

Paul





On Feb 15, 2019, at 9:06 PM, Sankalp Bagaria = <sankalp.nitt@gmail.com> wrote:

Hello,

Please take a = look at this and advise if it is a good idea and whether it should be = pursued.

Thanks,

Sankalp = Bagaria.


ITDA - IoT = Device Authentication

Abstract: We propose that the = server is authenticated using X509 certificate in a TLS 1.3 like protocol. The Server sends 32-byte = Challenge. Client replies by sending 32-byte Response. Thus the client is authenticated. = In the transfer of the application data, the client may send more = challenge-response pairs as encrypted data for updating database of server. Client = doesn=E2=80=99t store challenge/response or key or certificate. Both the server and the client = can initiate the handshake.

Background

Traditionally, = there are two ways to authenticate a device: a centralised CA issuing certificates and block-chain. Both require costly infrastructure and can=E2=80=99t be used to authenticate IoT devices, = which are of low cost. While block-chain provides non-repudiation, transactions are = distributed all over the net. X.509 certificates are costlier than many = sensors.

Another option is = Physically Uncloneable Functions (PUF). Because of the random variations taking place during the manufacturing process = of an IC, no two ICs are same. For instance, the impurities present in the IC = can affect the doping level of an IC and thus cause signal paths to change. = These slight variations in the signal path can affect the delay in the = propagation of a signal which can be measured and used to identify the chip. This = uniqueness of an IC can be used to authenticate the device in which the IC has been placed.

 

PUF:= The Concept

 Figure 1: = PUF =E2=80=93 Multiplexer pair=E2=80=99s output delay compared by arbiter = (latch)

When the same = input is fed to two adjacent multiplexers, depending on the impurities and other manufacturing variations, the = delay observed in the propagation of the signal to one multiplexer output is different from that of the other. This delay can be compared using an = arbiter (latch) and the final output generated. Several pairs of multiplexers = can be operated in parallel or a series of inputs can be fed to the same pair = of multiplexer. Thus, a set of output bits is generated that is specific to = the chip.

The set of input = bits is called challenge and the set of output bits is called response. A challenge/ response pair is specific = to the chip. The experimental results [4] show that two identical PUF circuits = on two different chips have different outputs for the same input with a = probability of 23% (inter-chip variation). On the other hand, multiple measurements on = the same chip are different only with 0.7% probability. As both the = multiplexers on the chip are in the same environment, the PUF output is mostly = independent of the environmental variations.

Limitations of current PUF implementation

To prevent the = replay attack, a challenge =E2=80=93 response pair can be used only once. To enable this, a large set of challenge =E2=80=93 = response pairs have to be generated at the installation time and pre-stored in the = server. A server can have many devices connected to it. So, it has to have a large database and computational power.

Moreover, this = setting is inflexible. There is the problem of distributing challenge/ response pairs from client to server. When the = PUF is commissioned, challenge/ response pairs have to be generated at the chip = and taken to server.  If the server exhausts its supply of challenge-response pairs, it cannot be easily renewed. =

 

Our = solution

Thus in our = solution, we combine the best of X.509 certificate and PUF. Certificate is well-tested technology and provides flexible way to distribute keys. PUF is relatively new but allows a = cheap solution to IoT authentication problem. Moreover, there is no need to = store keys or certificates at the client-side.

The = Protocol Combining TLS 1.3 and Challenge/ Response of = PUF

The = Protocol with Client Starting the Connection

Client starts by = generating its key_share and sends it to Server for normal TLS connection. It also sends acceptable ciphersuites. = Server generates its own private key and joins with client's keyshare to get = the shared secret. It takes this share-secret and combines with hash of the handshake till that point to generate handshake keys. The connection is encrypted from this point on.

 

The server sends = its X.509 certificate, CertificateVerify and PUF_Challenge. The client also generates the handshake key from its = private key and server's public key. It then verifies the certificate, generates = PUF_Response. It encrypts the PUF_Response and sends to the Server. Server verifies = it, generates Application Key from Handshake_key and hash of the = Handshake.

 

The Client also = generates the Application Keys similarly. The Application data flows in encrypted form. To start, Server requires only = one pair of Challenge/ Response. When server's stock is depleting it may = request more challenge/ response pairs in application data. Client may generate = more pairs and send them as encrypted data to server which stores in its = database for future use. Client should delete its copy permanently so that an = adversary can't recover it by attacking hardware.

Client         &nb= sp;     =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;          Server

ClientHello        &nbs= p;            =             &n= bsp;     

+ = key_share          -------->           = =           

          &nb= sp;           =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;      ServerHello

          &nb= sp; =             &n= bsp;           &nbs= p;            =          =             &n= bsp;           &nbs= p;            =             &n= bsp;      + key_share      

          &nb= sp;            = ;      =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;  {Encrypted Extensions}

          &nb= sp;            = ;            &= nbsp;           &nb= sp;  =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;   {Certificate}

    {CertificateVerify}

          &nb= sp;     =             &n= bsp;           &nbs= p;  <---------        = ;     =             &n= bsp;           &nbs= p;      {PUF_Challenge}

PUF_Response          =     ---------->      =             &n= bsp;           =

          &nb= sp;            = ;            &= nbsp;         =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;       {Finished}

          &nb= sp;          =             &n= bsp;       <---------  &nb= sp;          =             &n= bsp;           &nbs= p;           [Appli= cation Data]

{Finished}  =             &n= bsp;           &nbs= p;            =             &n= bsp; =             

[Application Data} =         <--------> &nbs= p;           =             &n= bsp;           &nbs= p;      [Application Data]

 

 

The = Protocol with Server Starting the Connection

The Server may = also initiate connection by sending Server Hello. Client replies by sending Client Hello with its key_share and = list of acceptable ciphersuites. When server receives Client_Hello, it proceeds = just like the above use-case.

 

Client         &nb= sp;            = ;      =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =  Server

          &nb= sp;        =             &n= bsp;           &nbs= p;            = <-----------  =             &n= bsp;           &nbs= p;            = ServerHello

     =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;   
ClientHello        &nbs= p;            =             &n= bsp;     

+ = key_share    =             &n= bsp;           &nbs= p; ---------->        &nbs= p;    =             &n= bsp;           &nbs= p;            =

 key_share        =         

          &nb= sp;            = ;            &= nbsp;            =   =             &n= bsp;           &nbs= p;            =            {Encrypt= ed Extensions}

          &nb= sp;            = ;            &= nbsp;           =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;   {Certificate}

          &nb= sp;            = ;            &= nbsp;            =      =             &n= bsp;           &nbs= p;            =             &n= bsp;  {CertificateVerify}

          &nb= sp;         =             &n= bsp;           &nbs= p;            =      <-----------     = ;       =             &n= bsp; {PUF_Challenge}

          &nb= sp;            = ;            &= nbsp;            =             =

{PUF_Response}        =             &n= bsp;         ----------=C3=A0

          &nb= sp;            = ;            &= nbsp;         =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;       {Finished}

          &nb= sp;          =             &n= bsp;           &nbs= p;            =         <---------  &= nbsp;         =           [Application = Data]

    =  {Finished}  =             &n= bsp;           &nbs= p;            =             &n= bsp;        =             

[Application = Data}  =             &n= bsp;           &nbs= p;   <-------->      &n= bsp;     =             &n= bsp;   [Application Data]

 

The Client doesn't = store the Keys, Challenge/ Response or the Certificate. Each session is a unit in itself. Everything is calculated = on the fly. This may create latency but this minimizes the resource = requirement. It is required that when the IoT device is commissioned, atleast one = Challenge/ Response pair is generated and stored in Server Database. Whenever the challenge - response pairs are depleting, on Server's request, the = Client can generate them and send to the Server as encrypted data. After sending, = the Client deletes its copy of Challenge / Response.

Future Work:

1)    Complete the = development of protocol described above by including use cases like when does the Handshake = fails and Challenge/ Response has to be re-negotiated; when Resumption happens = etc.
2)    Adapt other IoT = protocols like QUIC, DTLS to work with PUF.

3)    Validate the = solution with PUF-enabled Evaluation kits.

References = =E2=80=93

[1] RFC 5280 - Internet X.509 = Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. https://tools.ietf.org/html/rfc5280

[2] 50 Billion IoT devices will = be connected by 2020 =E2=80=93 Post =E2=80=93 The Things Network. https://www.thethingsnetwork.org/community/thessaloniki/post/50= -billion-iot-devices-will-be-connected-by-2020

[3] https://en.wikipedia.org/wiki/Physical_unclonable_function

[4] G. E. Suh and S. Devadas, = =E2=80=9CPhysical unclonable functions for device authentication and secret key generation,=E2=80=9D = in Proceedings of the 44th annual Design Automation Conference, San Diego, CA, Jun. = 2007, pp.9=E2=80=9314 https://people.csail.mit.edu/devadas/pubs/puf-dac07.pdf<= /a>

[5] http://people.csail.mit.edu/rudolph/Teaching/Lectures/Security/= Lecture-Security-PUFs-2.pdf

[5] Blaise Gassend, Dwaine = Clarke, Marten van Dijk and Srinivas Devadas. Silicon Physical Random Functions. Proceedings of the Computer and Communications Security Conference, November 2002 http://csg.csail..mit.edu/pubs/memos/Memo-456/memo-456.pdf

[6] C. Herder, L. Ren, M. van = Dijk, M-D. Yu, and S. Devadas, "Trapdoor Computational Fuzzy Extractors and Cryptographically-Secure Physical Unclonable Functions", IEEE = Transactions on Dependable and Secure Computing, January 2017 https://people.csail.mit.edu/devadas/pubs/trapdoor.pdf

[7] Helfmeier, Clemens; = Nedospasov, Dmitry; Boit, Christian; Seifert, Jean-Pierre (2013). Cloning Physically Unclonable Functions (PDF). IEEE Hardware Oriented Security and Trust = (IEEE HOST 2013). June 2=E2=80=933, 2013 Austin, TX, USA

 http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=3D6581556

 [8] Merchan Jorge Guajardo, = Shankaran S. Kumar, Pim T. Tuyls, Geert J. Schrijen = Identification of devices using physically unclonable functions
WO 2009024913 A2

[9] M. Fyrbiak, C. Kison, W. Adi. = Construction of Software-Based Digital Physical Clone Resistant Functions. 2013 Fourth International Conference on Emerging Security Technologies http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=3D6680199

      = [10]https://www.esat.kuleuven.be/cosic/thesis/2011/mai/CloningTheUn= clonable_en.pdf

[11] Srinivas Devadas, Edward = Suh, Sid Paral, Richard Sowell, Tom Ziola, Vivek Khandelwal . Design and Implementation of = PUF-Based =E2=80=9CUnclonable=E2=80=9D RFID ICs for Anti-Counterfeiting and = Security Applications.  http://verayo.com/pdf/2008_Verayo_IEEE_RFID_Paper.pdf

[12] Rishab Nithyanand, John = Solis. A Theoretical Analysis: Physical Unclonable Functions and The Software Protection Problem. = SANDIA REPORT SAND2011-6673. Printed in 2011. http://prod.sandia.gov/techlib/access-control.cgi/2011/116673.p= df

[13] Shahriar B. Shokouhi. = Cooperative Artificial Immune System And Recurrent Neural Network Error Correction Scheme For = Generating Robust Hardware Key. International Journal Of Electrical, Electronics = And Data Communication. ISSN: 2320-2084. Volume-4, Issue-5,May 2016 http://www.iraj.in/journal/journal_file/journal_pdf/1-254-14650= 2604154-59..pdf

[15] D. Lim. Extracting secret = keys from integrated circuits. Master=E2=80=99s thesis, Massachusetts Institute of = Technology, May 2004. http://csg.csail.mit.edu/pubs/memos/Memo-476/DaihyunLimThesis.p= df

[16] Ulrich Ruhrmair. On the = Formal Foundations of PUFs and Related Primitives. October 19, 2016.  https://depositonce.tu-berlin.de/bitstream/11303/5994/4/ruehrma= ir_ulrich.pdf

[17] https://patents.google.com/patent/US20090083833A1/en?q=3DPUF&am= p;q=3Dphysically+unclonable+function&oq=3DPUF+physically+unclonable+fu= nction

[18]      = https://patents.google.com/patent/US8290150B2/en?q=3Dauthentica= tion&q=3DPUF&q=3Dphysically+unclonable+function&oq=3Dauthentic= ation+PUF+physically+unclonable+function

[19] https://patents.google.com/patent/US20140279532A1/en?q=3Dauthen= tication&q=3DPUF&q=3Dphysically+unclonable+function&oq=3Dauthe= ntication+PUF+physically+unclonable+function

[20] RFC 8446 =E2=80=93 The = Transport Layer Security (TLS) Protocol Version 1.3 https://datatracker.ietf.org/doc/rfc8446/

[21] The New Illustrated TLS = Connection https://tls13.ulfheim.net/

      [22] Internet-draft: State-of-the-Art and Challenges for the Internet of      Things Security draft-irtf-t2trg-iot-seccons-16

[23] Internet-draft: TLS 1.3 Extension for Certificate-based Authentication with  an External Pre-Shared Key. = draft-housley-tls-tls13-cert-with-extern-psk-03

_______________________________________________
T2TRG = mailing list
T2TRG@irtf.org
https://www.irtf.org/mailman/listinfo/t2trg

= --Apple-Mail=_79A3FFD5-9578-4B4B-A7CC-681160980C15-- From nobody Mon Feb 18 00:21: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 B0CFE12D4EB for ; Mon, 18 Feb 2019 00:21:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 uh6Am9qhJR1j for ; Mon, 18 Feb 2019 00:21:05 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C333128CF2 for ; Mon, 18 Feb 2019 00:21:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7366; q=dns/txt; s=iport; t=1550478065; x=1551687665; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=ZiTnBWyaZQE+qU0XpsVRCjBK0/9RnFxRjNR1s8bUgso=; b=O864ZQJHkxxYtdH5q20sG1nQdHiFN7y75Nf6aQZ1fGcTcey3w1/EZ6X1 pSMAyPTHo/rrHTCNePzojiHu+mqQorswO/wCfGyBIms84CjABq1AKdH18 5K6nb/Jgs9/vSyTt56x5N8y23DQInvAJFh+VlRPk9hii2GQJ706iWkDDK k=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A8AAAXampc/xbLJq1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVAEBAQEBAQsBgQ2BXFEgEieMf4xsJZIphgWBZwgDAQE?= =?us-ascii?q?YAQqESQKEETcGDQEDAQECAQECbRwMhUoBAQEBAgEBAWwLBQsLGCcHJx8RBhO?= =?us-ascii?q?DIAGBaggPrFKELwGBFIRTD4JtiW6Bf4ERJwwTgkyDHgEBgSUmg1CCJgKMC4U?= =?us-ascii?q?IkVVcCYRLgnKLGhmCRpA6gycCjGSJRYJsAgQGBQIUgVwigVYzGggbFTsqAYJ?= =?us-ascii?q?BCTWFTIQIgQyFQD4DMI9lAQE?= X-IronPort-AV: E=Sophos;i="5.58,383,1544486400"; d="asc'?scan'208,217";a="10135615" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Feb 2019 08:21:02 +0000 Received: from ams3-vpn-dhcp1174.cisco.com (ams3-vpn-dhcp1174.cisco.com [10.61.68.150]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x1I8L163001871 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 18 Feb 2019 08:21:01 GMT From: Eliot Lear Message-Id: <4B89EADD-4947-4DF6-943D-9AC555FA944A@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_FB9BB288-F592-49DA-8BA4-9A4EEBAA589F"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Mon, 18 Feb 2019 09:21:00 +0100 In-Reply-To: <1EEEF408-9654-4D44-BF71-447B821F56E6@akamai.com> Cc: Sankalp Bagaria , "T2TRG@irtf.org" , "tls@ietf.org" , Peter Gutmann To: "Salz, Rich" References: <1550365230138.15157@cs.auckland.ac.nz> <1EEEF408-9654-4D44-BF71-447B821F56E6@akamai.com> X-Mailer: Apple Mail (2.3445.102.3) X-Outbound-SMTP-Client: 10.61.68.150, ams3-vpn-dhcp1174.cisco.com X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [TLS] [T2TRG] ITDA - IoT Device Authentication 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, 18 Feb 2019 08:21:09 -0000 --Apple-Mail=_FB9BB288-F592-49DA-8BA4-9A4EEBAA589F Content-Type: multipart/alternative; boundary="Apple-Mail=_72C36E9F-4CBE-4DF2-A401-B31E854A44BA" --Apple-Mail=_72C36E9F-4CBE-4DF2-A401-B31E854A44BA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Just to add- this is what the plethora of BRSKI drafts are attempting to = address in 6tisch, ANIMA, and EMU. If there is to be a new mechanism, I = encourage that it be listed on the GitHub page at = https://github.com/iot-onboarding/catalog = . Both the README.md file = and the Onboard-Table file should be updated. PRs welcome. > On 18 Feb 2019, at 04:29, Salz, Rich wrote: >=20 > If a client will sign any challenge presented by any server, it open = up a big hole. An attacker can present a challenge that a (future) = valid server will present, and the attacker, having the answer, can then = act as the device to the server. For example, the attacker can intercept = the server/client communication, present the challenge on its own, and = then act as the client. >=20 > _______________________________________________ > T2TRG mailing list > T2TRG@irtf.org > https://www.irtf.org/mailman/listinfo/t2trg = --Apple-Mail=_72C36E9F-4CBE-4DF2-A401-B31E854A44BA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Just = to add- this is what the plethora of BRSKI drafts are attempting to = address in 6tisch, ANIMA, and EMU.  If there is to be a new = mechanism, I encourage that it be listed on the GitHub page at https://github.com/iot-onboarding/catalog.  Both the = README.md file and the Onboard-Table file should be updated.  PRs = welcome.

On 18 Feb 2019, at 04:29, Salz, Rich <rsalz@akamai.com> = wrote:

If a = client will sign any challenge presented by any server, it open up a big = hole.  An attacker can present a challenge that a (future) valid = server will present, and the attacker, having the answer, can then act = as the device to the server. For example, the attacker can intercept the = server/client communication, present the challenge on its own, and then = act as the client.
 
_______________________________________________
T2TRG mailing list
T2TRG@irtf.org
https://www.irtf.org/mailman/listinfo/t2trg

= --Apple-Mail=_72C36E9F-4CBE-4DF2-A401-B31E854A44BA-- --Apple-Mail=_FB9BB288-F592-49DA-8BA4-9A4EEBAA589F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlxqauwACgkQh7ZrRtnS ejOBBgf9GfWOfsPWXLIBLk3sGw0D7tRPrPQ94iNtMOzYOgUESCg9awhOWI2yeRz3 bbnvQVH6Y1P6bzykKohydo4FGVND8B6JM4V1t6Wx/P/OYrXDcee5yNoAQrtC7QZW jCqTHdoZ8To0C5VFZwCZxf4STP0RVQ3IynRdT8t03MD2iBU70YOfWwcSaORTzzdW l8KW94JiuMBcKacDHaT8ETW3MttH3ciOuLRgR4AxRfehLBns7wQSIi6k54JUglET 0V2tepnowkgd4MWnHPUqagdXUqdQhbpydM4vJ9eUcRUQbVSZDeLaEk5zCa0NqAG/ 5pHyaBCeRytHYFO7CBHYKj8z6KkKZQ== =zDiF -----END PGP SIGNATURE----- --Apple-Mail=_FB9BB288-F592-49DA-8BA4-9A4EEBAA589F-- From nobody Mon Feb 18 03:28: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 C7E7B130EF3 for ; Mon, 18 Feb 2019 03:28:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, LOTS_OF_MONEY=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 d42WCJTg6QDu for ; Mon, 18 Feb 2019 03:28:03 -0800 (PST) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D4AE130ED4 for ; Mon, 18 Feb 2019 03:28:03 -0800 (PST) Received: by mail-ot1-x32f.google.com with SMTP id v62so18838150otb.3 for ; Mon, 18 Feb 2019 03:28:03 -0800 (PST) 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=PcdK62lsPKipg2MDy5ito2PdKPTAZtWg7dJMblu5WmM=; b=BBpGBNncCpLYLgKoL0gSaohc1RGuahK4RTcFatpDaeBs6NqywAiFhx63l8sHD/x78D wRDICrcCXMSf3ZSTQBvTnb331Jvxw/sAT603U8zhvP+93seLmgtBXCrfp2WIAvhuOony kX9I6nYLZMtzirokaqJMgJDs2SwB6FOoysf+Er48iVD/ZT0jmStfSCYKvFwKQjZve6gm G1UK5e+2UrLDNq/P4/AC61+n3EQhruj4gi3oY4nc2l9t/EtSc3iV40GKqMZ3ln4ivi6d MmrtxXPkfiNrd07FsPyJrS9uDlyk1FOzOT3JSx9of+IqShkgOskeQSeyRmFbqyNaaHyg WmeQ== 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=PcdK62lsPKipg2MDy5ito2PdKPTAZtWg7dJMblu5WmM=; b=BcUCty36IO2LS9rQsGerQRxZLKP6/CA68jQZX6hwH51n2m7BazT3MFM8aJ3OiuUv/b EryNs7oVPJhrnRHG/lhTWKh9HzW6Je9VfctVUsdH5vInn6+2b1ez6xeXemGugT8t/Fqq JQd3aibHBuaxlBYfNM4ZdX/lRezror0YWpYeuIhFJLi9k3O7EVVKcN21TR8bAVg8mMId 3n0dmI16SgO7xtJo/bbpbRRgJzNIdRaB7brGKOoNDYUZQ9iZX2sOud/CuaYyjGoIcVjv wQy8ze6J3lrtfIOg4AD3lxNMb+jiScWd0XsME+dRZlvQrH/1ZzI7hbe9Q8l+1SFk62K8 D7zg== X-Gm-Message-State: AHQUAuZApX6fBOPZ38R31Hz+BYNpbNM3dhNUkTMHTU8lGueWWjHYCTIo FBSgBI0rlwjrZ4wYCJJaY+vCsz6J5CidjAi7f4gZRw== X-Google-Smtp-Source: AHgI3IZyzMnnEjKu+W1S5YZ/VP63/QmiTElD1UH26L966RzsU1KVXD4DDJcL9qa0wt58W8+z/awKrs7ytL7TfYfhRTQ= X-Received: by 2002:a9d:130:: with SMTP id 45mr14060666otu.355.1550489282037; Mon, 18 Feb 2019 03:28:02 -0800 (PST) MIME-Version: 1.0 References: <00F86909-D260-4267-AC79-D5D63AD6DBAD@nymbus.net> In-Reply-To: <00F86909-D260-4267-AC79-D5D63AD6DBAD@nymbus.net> From: Sankalp Bagaria Date: Mon, 18 Feb 2019 16:57:48 +0530 Message-ID: To: Paul Lambert Cc: tls@ietf.org, T2TRG@irtf.org, Russell Housley Content-Type: multipart/alternative; boundary="000000000000e24e840582296abb" Archived-At: Subject: Re: [TLS] [T2TRG] ITDA - IoT Device Authentication 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, 18 Feb 2019 11:28:07 -0000 --000000000000e24e840582296abb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Thank you for your insight. It will help me give direction to my work. I need to do my homework better. Will look from public/private pair angle instead of challenge/response. Looking forward to similar guidance in future also, Thanks and Regards, Sankalp Bagaria. On Mon 18 Feb, 2019, 10:44 AM Paul Lambert, wrote: > Sankalp, > > The schema below is the wrong way to use PUF technology for IoT device > authentication. > > PUF is already being used in many fielded IoT systems. You simply use the > device unique PUF secret to create a public/private key pair. The public > key is then extracted and used to authentic the device. This enables > tracking and identification of the device through its full life-cycle. > Early observation of the device-unique public key mitigates a variety of > supply chain attacks. The extracted public key may be certified by a X.50= 9 > CA. The PUF derived identity may then be used directly in a TLS protocol > exchange. > > Early assignment of public key certificate to a device enables strong > protection of the device during manufacturing. The PUF device keys may be > used as part of the boot process to enable per-device protection of > sensitive firmware or other cryptographic secrets. > > PUF may be instantiated as HW or SW. Your scheme mentions " signal path > can affect the delay in the propagation of a signal=E2=80=9D =E2=80=A6 th= e seems to imply a > HW based implementation (perhaps a Butterfly PUF). A simpler implementati= on > would be to use SRAM PUF where the entropy in uninitialized SRAM is used = to > generate the device unique secrets. SRAM based PUF can be readily > integrated into existing MCU devices. > > The simplest application of PUF in IoT uses a device unique symmetric > secret key to serve as a key to encrypt sensitive data in unprotected NV > memory. This is basically a low-level key vault that provides > confidential and non-non-maleable secure device storage. This is a very > attractive alternative to OTP memory that s more expensive and of limited > size. > > PUF is just one way for a device to obtain unique secrets (symmetric or > asymmetric). It has been standard practice to =E2=80=9Cinject=E2=80=99 se= crets during > manufacturing. Injection requires more trust in the key distribution and > provisioning process than approaches that generate keys on device and nev= er > expose these secrets. > > Long-lived device unique public keys and certificates that provide > protection through the full manufacturing life-cycle are an interesting > topic area =E2=80=A6 Challenge/response PUF protocols are not useful or > interesting for standardization. > > Paul > > > > > > On Feb 15, 2019, at 9:06 PM, Sankalp Bagaria > wrote: > > *Hello,* > > *Please take a look at this and advise if it is a good idea and whether i= t > should be pursued.* > > *Thanks,* > > *Sankalp Bagaria.* > > > *ITDA - IoT Device Authentication* > > *Abstract: *We propose that the server is authenticated using X509 > certificate in a TLS 1.3 like protocol. The Server sends 32-byte Challeng= e. > Client replies by sending 32-byte Response. Thus the client is > authenticated. In the transfer of the application data, the client may se= nd > more challenge-response pairs as encrypted data for updating database of > server. Client doesn=E2=80=99t store challenge/response or key or certifi= cate. Both > the server and the client can initiate the handshake. > > *Background* > > Traditionally, there are two ways to authenticate a device: a centralised > CA issuing certificates and block-chain. Both require costly infrastructu= re > and can=E2=80=99t be used to authenticate IoT devices, which are of low c= ost. While > block-chain provides non-repudiation, transactions are distributed all ov= er > the net. X.509 certificates are costlier than many sensors. > > Another option is Physically Uncloneable Functions (PUF). Because of the > random variations taking place during the manufacturing process of an IC, > no two ICs are same. For instance, the impurities present in the IC can > affect the doping level of an IC and thus cause signal paths to change. > These slight variations in the signal path can affect the delay in the > propagation of a signal which can be measured and used to identify the > chip. This uniqueness of an IC can be used to authenticate the device in > which the IC has been placed. > > > *PUF: The Concept* > > *[image: P02.JPG]* > > Figure 1: PUF =E2=80=93 Multiplexer pair=E2=80=99s output delay compared= by arbiter > (latch) > > When the same input is fed to two adjacent multiplexers, depending on the > impurities and other manufacturing variations, the delay observed in the > propagation of the signal to one multiplexer output is different from tha= t > of the other. This delay can be compared using an arbiter (latch) and the > final output generated. Several pairs of multiplexers can be operated in > parallel or a series of inputs can be fed to the same pair of multiplexer= . > Thus, a set of output bits is generated that is specific to the chip. > > The set of input bits is called challenge and the set of output bits is > called response. A challenge/ response pair is specific to the chip. The > experimental results [4] show that two identical PUF circuits on two > different chips have different outputs for the same input with a > probability of 23% (inter-chip variation). On the other hand, multiple > measurements on the same chip are different only with 0.7% probability. A= s > both the multiplexers on the chip are in the same environment, the PUF > output is mostly independent of the environmental variations. > > *Limitations of current PUF implementation* > > To prevent the replay attack, a challenge =E2=80=93 response pair can be = used only > once. To enable this, a large set of challenge =E2=80=93 response pairs h= ave to be > generated at the installation time and pre-stored in the server. A server > can have many devices connected to it. So, it has to have a large databas= e > and computational power. > > Moreover, this setting is inflexible. There is the problem of distributin= g > challenge/ response pairs from client to server. When the PUF is > commissioned, challenge/ response pairs have to be generated at the chip > and taken to server. If the server exhausts its supply of > challenge-response pairs, it cannot be easily renewed. > > > *Our solution* > > Thus in our solution, we combine the best of X.509 certificate and PUF. > Certificate is well-tested technology and provides flexible way to > distribute keys. PUF is relatively new but allows a cheap solution to IoT > authentication problem. Moreover, there is no need to store keys or > certificates at the client-side. > > *The Protocol Combining TLS 1.3 and Challenge/ Response of PUF* > > *The Protocol with Client Starting the Connection* > > Client starts by generating its key_share and sends it to Server for > normal TLS connection. It also sends acceptable ciphersuites. Server > generates its own private key and joins with client's keyshare to get the > shared secret. It takes this share-secret and combines with hash of the > handshake till that point to generate handshake keys. The connection is > encrypted from this point on. > > > The server sends its X.509 certificate, CertificateVerify and > PUF_Challenge. The client also generates the handshake key from its priva= te > key and server's public key. It then verifies the certificate, generates > PUF_Response. It encrypts the PUF_Response and sends to the Server. Serve= r > verifies it, generates Application Key from Handshake_key and hash of the > Handshake. > > > The Client also generates the Application Keys similarly. The Application > data flows in encrypted form. To start, Server requires only one pair of > Challenge/ Response. When server's stock is depleting it may request more > challenge/ response pairs in application data. Client may generate more > pairs and send them as encrypted data to server which stores in its > database for future use. Client should delete its copy permanently so tha= t > an adversary can't recover it by attacking hardware. > > Client > = Server > > ClientHello > > + key_share --------> > > > = ServerHello > > > + key_share > > > {Encrypte= d > Extensions} > > > {Certifi= cate} > > {CertificateVerify} > > <--------- > {PUF_Challenge} > > PUF_Response ----------> > > > {Fin= ished} > > <--------- > [Application Data] > > {Finished} > > [Application Data} <--------> > [Application Data] > > > > > > *The Protocol with Server Starting the Connection* > > The Server may also initiate connection by sending Server Hello. Client > replies by sending Client Hello with its key_share and list of acceptable > ciphersuites. When server receives Client_Hello, it proceeds just like th= e > above use-case. > > > Client > = Server > > <----------- > ServerHello > > > ClientHello > > + key_share ----------> > > > key_share > > > {Encrypted Extensions} > > > {Certifi= cate} > > > {CertificateVerify} > > > <----------- > {PUF_Challenge} > > > {PUF_Response} ----------=C3=A0 > > > {Fin= ished} > > > <--------- > [Application Data] > > {Finished} > > > [Application Data} <--------> > [Application Data] > > > The Client doesn't store the Keys, Challenge/ Response or the Certificate= . > Each session is a unit in itself. Everything is calculated on the fly. Th= is > may create latency but this minimizes the resource requirement. It is > required that when the IoT device is commissioned, atleast one Challenge/ > Response pair is generated and stored in Server Database. Whenever the > challenge - response pairs are depleting, on Server's request, the Client > can generate them and send to the Server as encrypted data. After sending= , > the Client deletes its copy of Challenge / Response. > > *Future Work:* > 1) Complete the development of protocol described above by including > use cases like when does the Handshake fails and Challenge/ Response has = to > be re-negotiated; when Resumption happens etc. > 2) Adapt other IoT protocols like QUIC, DTLS to work with PUF. > > 3) Validate the solution with PUF-enabled Evaluation kits. > > References =E2=80=93 > > [1] RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and > Certificate Revocation List (CRL) Profile. > https://tools.ietf.org/html/rfc5280 > > [2] 50 Billion IoT devices will be connected by 2020 =E2=80=93 Post =E2= =80=93 The Things > Network. > https://www.thethingsnetwork.org/community/thessaloniki/post/50-billion-i= ot-devices-will-be-connected-by-2020 > > [3] https://en.wikipedia.org/wiki/Physical_unclonable_function > > [4] G. E. Suh and S. Devadas, =E2=80=9CPhysical unclonable functions for = device > authentication and secret key generation,=E2=80=9D in Proceedings of the = 44th > annual Design Automation Conference, San Diego, CA, Jun. 2007, pp.9=E2=80= =9314 > https://people.csail.mit.edu/devadas/pubs/puf-dac07.pdf > > [5] > http://people.csail.mit.edu/rudolph/Teaching/Lectures/Security/Lecture-Se= curity-PUFs-2.pdf > > [5] Blaise Gassend, Dwaine Clarke, Marten van Dijk and Srinivas Devadas. > Silicon Physical Random Functions. Proceedings of the Computer and > Communications Security Conference, November 2002 > http://csg.csail..mit.edu/pubs/memos/Memo-456/memo-456.pdf > > > [6] C. Herder, L. Ren, M. van Dijk, M-D. Yu, and S. Devadas, "Trapdoor > Computational Fuzzy Extractors and Cryptographically-Secure Physical > Unclonable Functions", IEEE Transactions on Dependable and Secure > Computing, January 2017 > https://people.csail.mit.edu/devadas/pubs/trapdoor.pdf > > [7] Helfmeier, Clemens; Nedospasov, Dmitry; Boit, Christian; Seifert, > Jean-Pierre (2013). Cloning Physically Unclonable Functions > (PDF). IEEE > Hardware Oriented Security and Trust (IEEE HOST 2013). June 2=E2=80=933, = 2013 > Austin, TX, USA > > http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=3D6581556 > > [8] Merchan Jorge Guajardo > , > Shankaran S. Kumar > , > Pim T. Tuyls > , > Geert J. Schrijen > > Identification of devices using physically unclonable functions > WO 2009024913 A2 > > [9] M. Fyrbiak, C. Kison, W. Adi. Construction of Software-Based Digital > Physical Clone Resistant Functions. 2013 Fourth International Conference = on > Emerging Security Technologies > http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=3D6680199 > > [10] > https://www.esat.kuleuven.be/cosic/thesis/2011/mai/CloningTheUnclonable_e= n.pdf > > [11] Srinivas Devadas, Edward Suh, Sid Paral, Richard Sowell, Tom Ziola, > Vivek Khandelwal . Design and Implementation of PUF-Based =E2=80=9CUnclon= able=E2=80=9D RFID > ICs for Anti-Counterfeiting and Security Applications. > http://verayo.com/pdf/2008_Verayo_IEEE_RFID_Paper.pdf > > [12] Rishab Nithyanand, John Solis. A Theoretical Analysis: Physical > Unclonable Functions and The Software Protection Problem. SANDIA REPORT > SAND2011-6673. Printed in 2011. > http://prod.sandia.gov/techlib/access-control.cgi/2011/116673.pdf > > > [13] Shahriar B. Shokouhi. Cooperative Artificial Immune System And > Recurrent Neural Network Error Correction Scheme For Generating Robust > Hardware Key. International Journal Of Electrical, Electronics And Data > Communication. ISSN: 2320-2084. Volume-4, Issue-5,May 2016 > http://www.iraj.in/journal/journal_file/journal_pdf/1-254-146502604154-59= ..pdf > > > [15] D. Lim. Extracting secret keys from integrated circuits. Master=E2= =80=99s > thesis, Massachusetts Institute of Technology, May 2004. > http://csg.csail.mit.edu/pubs/memos/Memo-476/DaihyunLimThesis.pdf > > [16] Ulrich Ruhrmair. On the Formal Foundations of PUFs and Related > Primitives. October 19, 2016. > https://depositonce.tu-berlin.de/bitstream/11303/5994/4/ruehrmair_ulrich.= pdf > > [17] > https://patents.google.com/patent/US20090083833A1/en?q=3DPUF&q=3Dphysical= ly+unclonable+function&oq=3DPUF+physically+unclonable+function > > [18] > https://patents.google.com/patent/US8290150B2/en?q=3Dauthentication&q=3DP= UF&q=3Dphysically+unclonable+function&oq=3Dauthentication+PUF+physically+un= clonable+function > > [19] > https://patents.google.com/patent/US20140279532A1/en?q=3Dauthentication&q= =3DPUF&q=3Dphysically+unclonable+function&oq=3Dauthentication+PUF+physicall= y+unclonable+function > > [20] RFC 8446 =E2=80=93 The Transport Layer Security (TLS) Protocol Versi= on 1.3 > https://datatracker.ietf.org/doc/rfc8446/ > > [21] The New Illustrated TLS Connection https://tls13.ulfheim.net/ > [22] Internet-draft: State-of-the-Art and Challenges for the > Internet of Things Security draft-irtf-t2trg-iot-seccons-16 > > [23] Internet-draft: TLS 1.3 Extension for Certificate-based > Authentication with an External Pre-Shared Key. > draft-housley-tls-tls13-cert-with-extern-psk-03 > _______________________________________________ > T2TRG mailing list > T2TRG@irtf.org > https://www.irtf.org/mailman/listinfo/t2trg > > > --000000000000e24e840582296abb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
Thank you for your insight. It will help = me give direction to my work. I need to do my homework better. Will look fr= om public/private pair angle instead of challenge/response.

Looking forward to similar guidance in future = also,
Thanks and Re= gards,
Sankalp Baga= ria.


On Mon 18 Feb= , 2019, 10:44 AM Paul Lambert, <paul@= nymbus.net> wrote:
Sankalp,

<= /div>
The schema below is the wrong way to use PUF technology for IoT d= evice authentication.=C2=A0

PUF is already being used in= many fielded IoT systems. You simply use the device unique PUF secret to c= reate a public/private key pair. The public key is then extracted and used = to authentic the device. This enables tracking and identification of the de= vice through its full life-cycle. Early observation of the device-unique pu= blic key mitigates a variety of supply chain attacks. The extracted public = key may be certified by a X.509 CA. The PUF derived identity may then be us= ed directly in a TLS protocol exchange.=C2=A0

Earl= y assignment of public key certificate to a device enables strong protectio= n of the device during manufacturing. The PUF device keys may be used as pa= rt of the boot process to enable per-device protection of sensitive firmwar= e or other cryptographic secrets. =C2=A0

PUF may b= e instantiated as HW or SW. Your scheme mentions " signal path can aff= ect the delay in the propagation of a signal=E2=80=9D =E2=80=A6 the seems t= o imply a HW based implementation (perhaps a Butterfly PUF). A simpler impl= ementation would be to use SRAM PUF where the entropy in uninitialized SRAM= is used to generate the device unique secrets. SRAM based PUF can be readi= ly integrated into existing MCU devices.

The simpl= est application of PUF in IoT uses a device unique symmetric secret key to = serve as a key to encrypt sensitive data in unprotected NV memory.=C2=A0 Th= is is basically a low-level key vault =C2=A0that provides confidential and = non-non-maleable secure device storage. This is a very attractive alternati= ve to OTP memory that s more expensive and of limited size.=C2=A0

PUF is just one way for a device to obtain unique secrets (= symmetric or asymmetric). It has been standard practice to =E2=80=9Cinject= =E2=80=99 secrets during manufacturing. Injection requires more trust in th= e key distribution and provisioning process than approaches that generate k= eys on device and never expose these secrets.=C2=A0

Long-lived device unique public keys and certificates that provide protec= tion through the full manufacturing life-cycle are an interesting topic are= a =E2=80=A6 =C2=A0Challenge/response PUF protocols are not useful or intere= sting for standardization.

Paul





On Feb 15, 2019, at 9:06 PM, Sankalp Bagaria <sankalp.nitt@gma= il.com> wrote:

Hello,

Please take a look at this and advise if it= is a good idea and whether it should be pursued.

Thanks,

Sankalp Bagari= a.

ITDA= - IoT Device Authentication

Abstract: We= propose that the server is authenticated using X509 certificate in a TLS 1.3 like protocol. The Server sends 32-byte Challenge.= Client replies by sending 32-byte Response. Thus the client is authenticated. In t= he transfer of the application data, the client may send more challenge-respon= se pairs as encrypted data for updating database of server. Client doesn=E2=80= =99t store challenge/response or key or certificate. Both the server and the client ca= n initiate the handshake.

Background

Traditionally, there are two wa= ys to authenticate a device: a centralised CA issuing certificates and block-chain. Both require costly infrastructure and can=E2=80=99t be used to authenticate IoT devices, which= are of low cost. While block-chain provides non-repudiation, transactions are distribu= ted all over the net. X.509 certificates are costlier than many sensors.=

Another option is Physically Uncloneab= le Functions (PUF). Because of the random variations taking place during the manufacturing process of a= n IC, no two ICs are same. For instance, the impurities present in the IC can affect the doping level of an IC and thus cause signal paths to change. The= se slight variations in the signal path can affect the delay in the propagatio= n of a signal which can be measured and used to identify the chip. This uniquene= ss of an IC can be used to authenticate the device in which the IC has been placed.

=C2=A0

P= UF: The Concept

3D"P02.JPG"

=C2=A0Figure 1: PUF =E2=80=93 Multiplexer pair=E2=80=99s output delay compared by arbiter (latch)<= /p>

When the same input is fed to two adja= cent multiplexers, depending on the impurities and other manufacturing variations, the delay observed in the propagation of the signal to one multiplexer output is different from that of the other. This delay can be compared using an arbit= er (latch) and the final output generated. Several pairs of multiplexers can b= e operated in parallel or a series of inputs can be fed to the same pair of multiplexer. Thus, a set of output bits is generated that is specific to th= e chip.

The set of input bits is = called challenge and the set of output bits is called response. A challenge/ response pair is specific to t= he chip. The experimental results [4] show that two identical PUF circuits on = two different chips have different outputs for the same input with a probabilit= y of 23% (inter-chip variation). On the other hand, multiple measurements on the same chip are different only with 0.7% probability. As both the multiplexer= s on the chip are in the same environment, the PUF output is mostly independent = of the environmental variations.

Limitations of current PUF implementation

To prevent the replay attack, a challenge =E2=80=93 respons= e pair can be used only once. To enable this, a large set of challenge =E2=80=93 respo= nse pairs have to be generated at the installation time and pre-stored in the server.= A server can have many devices connected to it. So, it has to have a large database and computational power.

Moreover, this setting is inflexible. There is the problem of distributing challenge/ response pairs from client to server. When the PUF = is commissioned, challenge/ response pairs have to be generated at the chip an= d taken to server.=C2=A0 If the server exhausts its supply of challenge-response pairs, it cannot be easily renewed.

=C2=A0

Our solution

Thus in our solution, we comb= ine the best of X.509 certificate and PUF. Certificate is well-tested technology and provides flexible way to distribute keys. PUF is relatively new but allows a cheap solution to IoT authentication problem. Moreover, there is no need to store keys or certificates at the client-side.

The Protocol Combining TLS 1.3 and Challenge/ Response of PUF

The Protocol with Client S= tarting the Connection

Clien= t starts by generating its key_share and sends it to Server for normal TLS connection. It also sends acceptable ciphersuites. Se= rver generates its own private key and joins with client's keyshare to get t= he shared secret. It takes this share-secret and combines with hash of the handshake till that point to generate handshake keys. The connection is encrypted from this point on.

=C2=A0

The server sends its X.509 certificate, CertificateVerify= and PUF_Challenge. The client also generates the handshake key from its private= key and server's public key. It then verifies the certificate, generates PU= F_Response. It encrypts the PUF_Response and sends to the Server. Server verifies it, generates Application Key from Handshake_key and hash of the Handshake.

=C2=A0

The Client also= generates the Application Keys similarly. The Application data flows in encrypted form. To start, Server requires only on= e pair of Challenge/ Response. When server's stock is depleting it may re= quest more challenge/ response pairs in application data. Client may generate mor= e pairs and send them as encrypted data to server which stores in its databas= e for future use. Client should delete its copy permanently so that an advers= ary can't recover it by attacking hardware.

Client=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0Server

ClientHello=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=

+ key_share=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -------->=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ServerHello

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0+ key_share=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0{Encrypted Extensions}

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0{Certificate}

=C2=A0=C2=A0=C2=A0 {CertificateVerify}

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0<---------=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {PUF_Challe= nge}

= PUF_Response=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0---------->= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= {Finished}

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<= ;---------=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0[Application Data]

{Finished}=C2=A0 =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

[Application Data} =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<-------->=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0[Application Data]

=C2=A0

=C2=A0

The Protocol with Server Starting the Connection=

The Server may also initiate connectio= n by sending Server Hello. Client replies by sending Client Hello with its key_share and list o= f acceptable ciphersuites. When server receives Client_Hello, it proceeds jus= t like the above use-case.

=C2=A0

Client=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Server

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<-----------=C2=A0 =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ServerHello

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

ClientHello=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

+ key_share=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0---------->=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

= =C2=A0key_share=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0{Encrypted Extensions}

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0{Certificate}

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2= =A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0{CertificateVerify}

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0<-----------=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0{PUF_Challenge}

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

{PUF_Response}=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0----------=C3=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0{Finished}

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0<---------=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0[Application Data]

= =C2=A0=C2=A0=C2=A0 =C2=A0{Finished}=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

[Application Data}=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<-------->=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0[Application Data]

=C2=A0

The Client doesn't store the Keys, Challenge/ Respon= se or the Certificate. Each session is a unit in itself. Everything is calculated on = the fly. This may create latency but this minimizes the resource requirement. I= t is required that when the IoT device is commissioned, atleast one Challenge/ Response pair is generated and stored in Server Database. Whenever the challenge - response pairs are depleting, on Server's request, the Clie= nt can generate them and send to the Server as encrypted data. After sending, the Client deletes its copy of Challenge / Response.

Future Work:

1)=C2=A0=C2=A0=C2=A0 Complete the development of protocol described above by including use cases like when does the Handshake fails a= nd Challenge/ Response has to be re-negotiated; when Resumption happens etc.
2)=C2=A0=C2=A0=C2=A0= Adapt other = IoT protocols like QUIC, DTLS to work with PUF.

3)=C2=A0=C2=A0= =C2=A0 Valida= te the solution with PUF-enabled Evaluation kits.

Ref= erences =E2=80=93

<= span style=3D"font-size:14pt">[1] RFC 5280 - Internet X.509 Public Key Infr= astructure Certificate and Certificate Revocation List (CRL) Profile. https://tools.ietf.org/html/rfc5280

[2] 50 Billion IoT devices= will be connected by 2020 =E2=80=93 Post =E2=80=93 The Things Network. https://www.thethingsnetwork.org/community/thessaloniki/post/50-bill= ion-iot-devices-will-be-connected-by-2020

[3] https://en.wikipedia.org/wiki/Physical_unclonable_func= tion

[4] G. E. Suh an= d S. Devadas, =E2=80=9CPhysical unclonable functions for device authentication and secret key generation,=E2=80=9D in = Proceedings of the 44th annual Design Automation Conference, San Diego, CA, Jun. 2007, pp.9=E2=80=9314 https://people.csail.mit.edu/devadas/pubs/puf-dac07.pdf=

[5] http://people.csail.mit.edu/rudolph/Teaching/Lectures/Security/Lecture-Sec= urity-PUFs-2.pdf

[5] = Blaise Gassend, Dwaine Clarke, Marten van Dijk and Srinivas Devadas. Silicon Physical Random Functions. Proceedings of the Computer and Communications Security Conference, November 2002 http://csg.csail.= .mit.edu/pubs/memos/Memo-456/memo-456.pdf

[6] C. Herder, L. Ren, M. van Dijk, M-D. Yu, and S. Devadas, "Trapdoor Computational Fuzzy Extractors and Cryptographically-Secure Physical Unclonable Functions", IEEE Transact= ions on Dependable and Secure Computing, January 2017 https://people.csail.mit.edu/devad= as/pubs/trapdoor.pdf

= [7] Helfmeier, Clemens; Nedospasov, Dmitry; Boit, Christian; Seifert, Jean-Pierre (2013). Cloning Physically Unclonable Functions (= PDF). IEEE Hardware Oriented Security and Trust (IEEE HOST 2013). June 2=E2=80=933, 2013 Austin, TX, USA

=C2=A0http://ieeexplore.ieee.o= rg/stamp/stamp.jsp?arnumber=3D6581556

=C2=A0[8] Merchan Jorge Guajardo, Shankaran S. Kumar, Pim T. Tuyls, Geert J. Schrijen Identification of device= s using physically unclonable functions
WO 2009024913 A2

[9] M. Fyrbiak, C. Kison, W. Adi. Construction= of Software-Based Digital Physical Clone Resistant Functions. 2013 Fourth International Conference on Emerging Security Technologies http://ieeexp= lore.ieee.org/stamp/stamp.jsp?arnumber=3D6680199

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [10]https://www.esat.kuleuven.be= /cosic/thesis/2011/mai/CloningTheUnclonable_en.pdf

[= 11] Srinivas Devadas, Edward Suh, Sid Paral, Richard Sowell, Tom Ziola, Vivek Khandelwal . Design and Implementation of PUF-Base= d =E2=80=9CUnclonable=E2=80=9D RFID ICs for Anti-Counterfeiting and Security = Applications.=C2=A0 http://verayo.com/pdf/2008_Verayo_IEEE_RFID_Paper.pdf=

[12] Rishab Nithyanand, John So= lis. A Theoretical Analysis: Physical Unclonable Functions and The Software Protection Problem. SANDIA REPORT SAND2011-6673. Printed in 2011. http://prod.sandia.gov/techlib/a= ccess-control.cgi/2011/116673.pdf=

[13] Shahriar B. Shokouhi. Cooperative Artificial Immune System And Recurrent Neural Network Error Correction Scheme For Generating Robust Hardware Key. International Journal Of Electrical, Electronics And D= ata Communication. ISSN: 2320-2084. Volume-4, Issue-5,May 2016 http://www.iraj.in/journal/journal_file/journal_pdf/1-254-146502604154-59.= .pdf

[15] D. Lim. Ext= racting secret keys from integrated circuits. Master=E2=80=99s thesis, Massachusetts Institute of Technology, M= ay 2004. http://csg.csail.mit.edu/pubs/memos/Memo-476/DaihyunLimThesis.p= df

[16] Ulrich Ruhrma= ir. On the Formal Foundations of PUFs and Related Primitives. October 19, 2016. =C2=A0https://depos= itonce.tu-berlin.de/bitstream/11303/5994/4/ruehrmair_ulrich.pdf<= span style=3D"font-size:14pt">

[17] https://patents.googl= e.com/patent/US20090083833A1/en?q=3DPUF&q=3Dphysically+unclonable+funct= ion&oq=3DPUF+physically+unclonable+function

[18]=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://patents.google.com/patent/US8290150B2/en= ?q=3Dauthentication&q=3DPUF&q=3Dphysically+unclonable+function&= oq=3Dauthentication+PUF+physically+unclonable+function

[19] https://patents.google.com/patent/US20140279532A1/en?q=3Dauthentica= tion&q=3DPUF&q=3Dphysically+unclonable+function&oq=3Dauthentica= tion+PUF+physically+unclonable+function

[20] RFC 8446 =E2=80=93 The Transport Layer Security (T= LS) Protocol Version 1.3 = https://datatracker.ietf.org/doc/rfc8446/

[21] The New Illustrated TLS Connection https://tls13.ulfheim.net/

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [22] Internet-draft: State-of-the-Art and Challenges for the Internet of=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Things Security draft-irtf-t2trg-iot-seccons-16

[23] Internet-draft: TLS 1.3 Extension for Certificate-based Authentication with=C2=A0 an External Pre-Shared Key. draft-housley-tls-tls13-cert-with-ex= tern-psk-03

_______________________________________________
T2TRG mailing list
T2TRG@= irtf.org
https://www.irtf.org/mailman/listinfo/t2t= rg

--000000000000e24e840582296abb-- From nobody Mon Feb 18 03:33: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 C3CCF12867A for ; Mon, 18 Feb 2019 03:33:38 -0800 (PST) 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=unavailable 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 P86HKs_h5eiI for ; Mon, 18 Feb 2019 03:33:36 -0800 (PST) Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E7DA130EB0 for ; Mon, 18 Feb 2019 03:33:36 -0800 (PST) Received: by mail-ot1-x335.google.com with SMTP id 98so27782410oty.1 for ; Mon, 18 Feb 2019 03:33:36 -0800 (PST) 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=cmtR/ge1XcL5+R+fcsdeLzLQiz+AkwHiJWLqaFBGgG4=; b=CnPjnXW6B+AtQTySHikJS91HzQ9SonGC0oFn7LQ37gRoSnw+/RVIr4snQ0didWAbOi ILoISMzoMrsgkTz9YeLqRjkHNC26M8OmgKryV+dWVAXMzv3eTtdrSJDHsbBWaR6RJb7M py13cRhTK1aKv2TZmyLcftN0mekECWGkKXl440lhSFAfAVeIaj5JbWoypJY6GJKID/R/ lG4cKSSsED+pPagW1YLphRh8H9oNSYKXK5xXZuXqnaGs+/QqPi/aSOYdd/O0HsMDkhq4 NdxGc84LW5XDba1Hi9fxWKzg16c+0FqOPaqme6gzJvHpjbA933iKIHHTPBfoDDae9ns/ s5cw== 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=cmtR/ge1XcL5+R+fcsdeLzLQiz+AkwHiJWLqaFBGgG4=; b=feknCxHHEZuv1QlviwWKkSiMivxdxsMoAan57bnQRNnAadjORgY3SBuuxde7BUkoWK cuhP4/XPsZcR7ID0t9jutPzETU5Dj0r2gEN/1Ime7Xkfq29SNWKPbYzUZa8FpFLtgfxV pzY0tUG/wNVYDQAoTLuqi3P5n27Jn2YtV9ctnM5VTiR61JwqBq8IXhv8+Bjze7Fxi37V TNd/UJLKYf1/j7kw/LpdF9FhznGEYKVzQv6RuD3p3QfYxwvTfvXKgwlmFEmsBYWLwvwb dIADkDvf1L1dvOHVhsw2xiD0eTSAyNnFP6vcOuCn0ZDEdjm5WSxmLISMJwU66V1P6HTr 43+A== X-Gm-Message-State: AHQUAuYFP6ZHNQaIt9iwOqfi1iMF63xnuZUmJQi9f6NWBvV3j15u9T5C jDLlslrVdLiUA9FUO/G6zGYKRMUStSkPrc0r6N4= X-Google-Smtp-Source: AHgI3IYOcdleFng7s7aIb/H+1D58IiCA7O5bujsyknmfIDaLtU/CWCdTBFfuwqpLr5D2y02JMDpPPu8jyErc8wQpF4w= X-Received: by 2002:a9d:6e93:: with SMTP id a19mr409879otr.7.1550489615107; Mon, 18 Feb 2019 03:33:35 -0800 (PST) MIME-Version: 1.0 References: <1550365230138.15157@cs.auckland.ac.nz> <1EEEF408-9654-4D44-BF71-447B821F56E6@akamai.com> <4B89EADD-4947-4DF6-943D-9AC555FA944A@cisco.com> In-Reply-To: <4B89EADD-4947-4DF6-943D-9AC555FA944A@cisco.com> From: Sankalp Bagaria Date: Mon, 18 Feb 2019 17:03:23 +0530 Message-ID: To: Eliot Lear , rsalz@akamai.com Cc: T2TRG@irtf.org, tls@ietf.org, Peter Gutmann Content-Type: multipart/alternative; boundary="000000000000bc8d260582297ecb" Archived-At: Subject: Re: [TLS] [T2TRG] ITDA - IoT Device Authentication 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, 18 Feb 2019 11:33:39 -0000 --000000000000bc8d260582297ecb Content-Type: text/plain; charset="UTF-8" Hi, My apologies if I appeared a little aggressive in pursuing my incorrect idea. I have to learn a lot. Looking forward to your guidance in future also, Thanks and Regards, Sankalp Bagaria. On Mon 18 Feb, 2019, 1:51 PM Eliot Lear, wrote: > Just to add- this is what the plethora of BRSKI drafts are attempting to > address in 6tisch, ANIMA, and EMU. If there is to be a new mechanism, I > encourage that it be listed on the GitHub page at > https://github.com/iot-onboarding/catalog. Both the README.md file and > the Onboard-Table file should be updated. PRs welcome. > > On 18 Feb 2019, at 04:29, Salz, Rich wrote: > > If a client will sign any challenge presented by any server, it open up a > big hole. An attacker can present a challenge that a (future) valid server > will present, and the attacker, having the answer, can then act as the > device to the server. For example, the attacker can intercept the > server/client communication, present the challenge on its own, and then act > as the client. > > _______________________________________________ > T2TRG mailing list > T2TRG@irtf.org > https://www.irtf.org/mailman/listinfo/t2trg > > > --000000000000bc8d260582297ecb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

My apologies if I appeared a little aggressive= in pursuing my incorrect idea. I have to learn a lot.

Looking forward to your guidance in future also,
Thanks and Regards,
Sankalp Bagaria.
=

On Mon 18 Feb, 2019, = 1:51 PM Eliot Lear, <lear@cisco.com> wrote:
Just to add- this is what the pl= ethora of BRSKI drafts are attempting to address in 6tisch, ANIMA, and EMU.= =C2=A0 If there is to be a new mechanism, I encourage that it be listed on = the GitHub page at=C2=A0https://github.com/iot-onboarding/c= atalog.=C2=A0 Both the README.md file and the Onboard-Table file should= be updated.=C2=A0 PRs welcome.

= On 18 Feb 2019, at 04:29, Salz, Rich <rsalz@akamai.com> wrote:
If a c= lient will sign any challenge presented by any server, it open up a big hol= e.=C2=A0 An attacker can present a challenge that a (future) valid server w= ill present, and the attacker, having the answer, can then act as the devic= e to the server. For example, the attacker can intercept the server/client = communication, present the challenge on its own, and then act as the client= .
=C2=A0
____________________________= ___________________
T2TRG mailing list
<= a href=3D"mailto:T2TRG@irtf.org" style=3D"color:purple;text-decoration:unde= rline;font-family:Helvetica;font-size:16px;font-style:normal;font-variant-c= aps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-i= ndent:0px;text-transform:none;white-space:normal;word-spacing:0px" target= =3D"_blank" rel=3D"noreferrer">T2TRG@irtf.org
https://www.irtf.org/mailman/= listinfo/t2trg

--000000000000bc8d260582297ecb-- From nobody Mon Feb 18 05:30: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 99635128B14; Mon, 18 Feb 2019 05:30:32 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YjFnceX553f5; Mon, 18 Feb 2019 05:30:31 -0800 (PST) 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 1D31212870E; Mon, 18 Feb 2019 05:30:30 -0800 (PST) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x1IDMMPN019794; Mon, 18 Feb 2019 13:30:23 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=VhCDhnf+IPViBTWs8aC1Gxq9t6V+yZv7eTbdp2nm4m8=; b=RCk0ndJyGL2RFEbDbS9bV70B++PVpilMiMxVLZ7cQnK/zzWOOLDweHEHHMzT9/nCdgz1 2d+QpDfcgR+WuvHarKzRJEAGp5WLcyuVWK0v3d7iJ8vyS72WE1j1Mg6BAqq6zTuzFZG8 d0wMvlv+ilH7lOwFOCxyh5oDvIOl3ju8OJREKo1SeG+0zjjOkyes/BUC+32DPfpWj8fq GXOhlHxgchUaDAI6ft0Upun33H1AoysgWClfeKuOBV5m5FhnXksM9IYq9BFB0QZr2ZHD C3yuDt2oGjYDSRJu5MP4r5aXZiNqfSaMQdUa86JtFpPTpDXnRuIwUcPvb1IEvo/AfyaM XQ== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0a-00190b01.pphosted.com with ESMTP id 2qpbekqk9n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 18 Feb 2019 13:30:23 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x1IDGpWN025470; Mon, 18 Feb 2019 08:30:22 -0500 Received: from email.msg.corp.akamai.com ([172.27.25.34]) by prod-mail-ppoint1.akamai.com with ESMTP id 2qpeqyxa2s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 18 Feb 2019 08:30:21 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.27.107) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 18 Feb 2019 05:30:19 -0800 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.1395.000; Mon, 18 Feb 2019 07:30:19 -0600 From: "Salz, Rich" To: Sankalp Bagaria CC: Peter Gutmann , "tls@ietf.org" , "T2TRG@irtf.org" Thread-Topic: [TLS] ITDA - IoT Device Authentication Thread-Index: AQHUxbWDTVzMaXNIX0ehxkA72mk1DqXjkZMAgADXCACAAMWwgP//rleAgABokwD//7SEAIAAW7EAgABMGwA= Date: Mon, 18 Feb 2019 13:30:18 +0000 Message-ID: <91B7CDCD-9F7E-4317-A9FF-52B67822BDB7@akamai.com> References: <1550365230138.15157@cs.auckland.ac.nz> <1EEEF408-9654-4D44-BF71-447B821F56E6@akamai.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.16.0.190211 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.43.148] Content-Type: multipart/alternative; boundary="_000_91B7CDCD9F7E4317A9FF52B67822BDB7akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-18_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=740 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902180100 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-18_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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=741 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902180101 Archived-At: Subject: Re: [TLS] ITDA - IoT Device Authentication 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, 18 Feb 2019 13:30:32 -0000 --_000_91B7CDCD9F7E4317A9FF52B67822BDB7akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgUmVwbGF5IGF0dGFjayBpcyBhdm9pZGVkIGJ5IHVzaW5nIGEgY2hhbGxlbmdlLyByZXNw b25zZSBwYWlyIG9ubHkgb25jZS4gMl4zMiBjb21iaW5hdGlvbnMgcG9zc2libGUgZm9yIDMyIGJ5 dGUgY2hhbGxlbmdlLg0KDQpIb3cgaXMgdGhhdCBlbmZvcmNlZD8NCg0KDQogICogICBTZXJ2ZXIg aXMgYXV0aGVudGljYXRlZCBieSBpdHMgY2VydGlmaWNhdGUuIEFuIGF0dGFja2VyIHdpbGwgbm90 IGJlIGFibGUgdG8gZG8gc28uDQoNCkRpZCBJIG1pc3Mgd2hlcmUgeW91IGV4cGxhaW5lZCB0aGlz Pw0K --_000_91B7CDCD9F7E4317A9FF52B67822BDB7akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNv TGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDou NWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFs MCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRp b25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxNDQ5MzUzNzc5Ow0KCW1zby1saXN0LXR5 cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo0NzUxOTA1MDYgMjExNDMzMTEwNiA2 NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5 ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCW1zby1iaWRpLWZv bnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWFuc2ktZm9udC13ZWlnaHQ6Ym9sZDt9DQpAbGlzdCBs MDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9 DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxp IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0 OmwwIGxldmVsMSBsZm8xIj5SZXBsYXkgYXR0YWNrIGlzIGF2b2lkZWQgYnkgdXNpbmcgYSBjaGFs bGVuZ2UvIHJlc3BvbnNlIHBhaXIgb25seSBvbmNlLiAyXjMyIGNvbWJpbmF0aW9ucyBwb3NzaWJs ZSBmb3IgMzIgYnl0ZSBjaGFsbGVuZ2UuJm5ic3A7PG86cD48L286cD48L2xpPjwvdWw+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5Ib3cgaXMgdGhhdCBlbmZvcmNlZD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHVsIHN0 eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPlNl cnZlciBpcyBhdXRoZW50aWNhdGVkIGJ5IGl0cyBjZXJ0aWZpY2F0ZS4gQW4gYXR0YWNrZXIgd2ls bCBub3QgYmUgYWJsZSB0byBkbyBzby48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+RGlkIEkgbWlzcyB3aGVyZSB5b3UgZXhwbGFpbmVkIHRoaXM/PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_91B7CDCD9F7E4317A9FF52B67822BDB7akamaicom_-- From nobody Tue Feb 19 12:04: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 6FC2C129A85; Tue, 19 Feb 2019 12:04:22 -0800 (PST) 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 wmjm_2rsytOW; Tue, 19 Feb 2019 12:04:20 -0800 (PST) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1954E12894E; Tue, 19 Feb 2019 12:04:20 -0800 (PST) Received: by mail-ed1-x535.google.com with SMTP id f2so17831591edy.13; Tue, 19 Feb 2019 12:04:20 -0800 (PST) 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; bh=kBNBNIFPcwU4wj25UqXUz8Ca72YFHi0oqdkC7AJdPZM=; b=vCV2prm6xUDgis843+kAW82pbiyWHOXySOwgX1/8Uur/bEESfzU+Y8r+I+fumhlWft LhP+/RwgcGw8gRTM/YNv7FACE7dDzgvnViQ1r1eU2ZhlWGD81y2Iawi8ryNrkykV2MyJ Xt3DzHnJX/FAd77Kem6+zTbP26b2/lKt3nrjtp90nJa2UPpUJ32kbixVel0J7yrYV0B8 sj7kAS+DH6j/WaJsPjhftzh0+WmHZEV5k0tOJECgfRuoEv+1OZfGEyGXFpVKJc9MguSN rtLkVZBXND3J+yeR0cF9vrJx5lFXoTcYCB2ubo04Y/ztfnF7XcTUhH7hWnIymrvaeai7 marA== 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=kBNBNIFPcwU4wj25UqXUz8Ca72YFHi0oqdkC7AJdPZM=; b=NPnLhnGV2MyKFD6lzymViHeaI3n43W4Hv1ZAlwM8PDp9uxXj7oHsX7U84bXX6Sb83n I2qTINjuAyzt7G2aEjhfJewrmcPpBGdTaS69FG51r+vg0I1c8orF8HLUp5AXAsYhwALg CC46Mr+hvU2S25ut+tPYjfwO/0WmS3F78X0nHfdQp02jU37YJqEdKOc+56Y6W/1PYwZs /DVh8MQcmqwtaSgFPVGKcAQCW+VFVK3CnJiYHUmWY0nvn8oqkDKsFcIYQINPFmQgs1eQ AZGrsNZ4EDrmu+9bInDLr6PY/I0tb+Ee0dIZgwT3+meJ+MNfbaUSInFwA1WJjZmhcSHC r4Kg== X-Gm-Message-State: AHQUAuahuepc36Ktlrj9LNpT0K5gQQC6q8qzua813IaJr4mkGiAh4XAY TUdnUygDcw72G/Oehxjr7Ro6UlSXi2Ad8Q1jfmOroT70 X-Google-Smtp-Source: AHgI3IZKSvuhVp5IWg0L53pAiu79Kz5zf0BmVEb44N9NTA/Y+qBDgaQx6tiiIQw2ISuCHOkIRLcx7DTLOTFSqVNMzrI= X-Received: by 2002:a50:98a6:: with SMTP id j35mr24479763edb.141.1550606658347; Tue, 19 Feb 2019 12:04:18 -0800 (PST) MIME-Version: 1.0 References: <155060540091.20709.12797700493315209480.idtracker@ietfa.amsl.com> In-Reply-To: <155060540091.20709.12797700493315209480.idtracker@ietfa.amsl.com> From: Dmitry Belyavsky Date: Tue, 19 Feb 2019 23:04:06 +0300 Message-ID: To: TLS Mailing List , secdispatch@ietf.org Content-Type: multipart/alternative; boundary="0000000000000ea858058244bf6e" Archived-At: Subject: [TLS] Fwd: New Version Notification for draft-belyavskiy-fakesni-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2019 20:04:22 -0000 --0000000000000ea858058244bf6e Content-Type: text/plain; charset="UTF-8" Hello, Please take a look at an initial submission of the draft. The draft describes a Fake SNI mechanism intended to cheat DPI systems in a case when a DPI system blocks the connection if ESNI is present. ---------- Forwarded message --------- From: Date: Tue, Feb 19, 2019 at 10:43 PM Subject: New Version Notification for draft-belyavskiy-fakesni-00.txt To: Dmitry Belyavskiy A new version of I-D, draft-belyavskiy-fakesni-00.txt has been successfully submitted by Dmitry Belyavskiy and posted to the IETF repository. Name: draft-belyavskiy-fakesni Revision: 00 Title: Fake Server Name Indication Document date: 2019-02-19 Group: Individual Submission Pages: 3 URL: https://www.ietf.org/internet-drafts/draft-belyavskiy-fakesni-00.txt Status: https://datatracker.ietf.org/doc/draft-belyavskiy-fakesni/ Htmlized: https://tools.ietf.org/html/draft-belyavskiy-fakesni-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-belyavskiy-fakesni Abstract: The document provides a specification of the Fake Server Name Indication. Being implemented, the Fake SNI specification provides a way to work around the monitoring solutions without providing any additional information to external observers. 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. The IETF Secretariat -- SY, Dmitry Belyavsky --0000000000000ea858058244bf6e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

Please take a look at an initial= submission of the draft.
The draft describes a Fake SNI mechanis= m intended to cheat DPI systems in a=C2=A0case=C2=A0
when a DPI s= ystem blocks the connection if ESNI is present.

---------- Forwarded message -= --------
From: <internet-drafts@ietf.org>
Date:= Tue, Feb 19, 2019 at 10:43 PM
Subject: New Version Notification for dra= ft-belyavskiy-fakesni-00.txt
To: Dmitry Belyavskiy <beldmit@gmail.com>


A new version of I-D, draft-belyavskiy-fakesni-00.txt
has been= successfully submitted by Dmitry Belyavskiy and posted to the
IETF repo= sitory.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-belyavskiy-fakesni<= br>Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Fake Server Name Indication
Document date:=C2=A0 2019-02-19Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 https://www.ietf.org/= internet-drafts/draft-belyavskiy-fakesni-00.txt
Status:=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0https://datatracker.i= etf.org/doc/draft-belyavskiy-fakesni/
Htmlized:=C2=A0 =C2=A0 =C2=A0 = =C2=A0https://tools.ietf.org/html/draft-belya= vskiy-fakesni-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-belyavski= y-fakesni


Abstract:
=C2=A0 =C2=A0The document provides a specification of the = Fake Server Name
=C2=A0 =C2=A0Indication.=C2=A0 Being implemented, the F= ake SNI specification provides a
=C2=A0 =C2=A0way to work around the mon= itoring solutions without providing any
=C2=A0 =C2=A0additional informat= ion to external observers.




Please note that it may take a couple of minutes from the time of submi= ssion
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



--
SY, D= mitry Belyavsky
--0000000000000ea858058244bf6e-- From nobody Tue Feb 19 15:34:00 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 835CE13104A; Tue, 19 Feb 2019 15:33:53 -0800 (PST) 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.91.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <155061923350.20777.5880362976599310587@ietfa.amsl.com> Date: Tue, 19 Feb 2019 15:33:53 -0800 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-subcerts-03.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: Tue, 19 Feb 2019 23:33:54 -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 : Delegated Credentials for TLS Authors : Richard Barnes Subodh Iyengar Nick Sullivan Eric Rescorla Filename : draft-ietf-tls-subcerts-03.txt Pages : 12 Date : 2019-02-19 Abstract: The organizational separation between the operator of a TLS server and the certification authority can create limitations. For example, the lifetime of certificates, how they may be used, and the algorithms they support are ultimately determined by the certification authority. This document describes a mechanism by which operators may delegate their own credentials for use in TLS, without breaking compatibility with clients that do not support this specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-subcerts-03 https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-subcerts-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Feb 19 15:40: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 C140E131063 for ; Tue, 19 Feb 2019 15:40:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=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 4nQqnHDL2z_S for ; Tue, 19 Feb 2019 15:40:25 -0800 (PST) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A29F131058 for ; Tue, 19 Feb 2019 15:40:25 -0800 (PST) Received: by mail-wr1-x431.google.com with SMTP id w17so23836969wrn.12 for ; Tue, 19 Feb 2019 15:40:25 -0800 (PST) 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; bh=QJVJaxu4oi6fStlZ1w8w9kEcuA9kguizsnkUMV00RvI=; b=i2GMvxKThYc1MbHIiUoajAbYJetMzwiaCapM2dKyNoiR5Ue2LmAAL31D2zVi3OAZit 5hHq5Hf7rX0XUZuCB/16gE/RIrQ78zfjsnb8hVQIYRycpYr10nXQDHUDmv0d8bQYg3FA W+/hvXSwxIIhHFck6desyPicgPI4dZNI2XyqI= 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=QJVJaxu4oi6fStlZ1w8w9kEcuA9kguizsnkUMV00RvI=; b=KTqC8M+HN5dFrvxl9HvqySbuHo8wPLNPxt79O+bCIblpSTo6NG433oCwnwlAvCdFHv THRfTB477spoXBz6z+KRLumeIqojtg+qp+G8YSAJUUTkMOjpRfqCN9O5qk601cPEdxne nAN4J6lgNIFWIwTGDjIDgdule2qKXur+fXv5herA5Xt3d0IrcEaQr0cwHxPbx5XgLSmO 5yyRRan1809BnkGd689Q4Jrby7u45Ow7vwm+3gaCDrfTLEqTRLMSUoKuAiKygBzABur4 ZaGI2ysC8P23XoPej5rhfhrCu4/8hZo/TR03NzUV3Fpyowl4gi277j+MrbhTUc6ZyG/E 6QzA== X-Gm-Message-State: AHQUAuYA78OBT9QtfrkxKdAT0Fl7Br6KY78wZ9IyrYslBCiBpRiWjAo7 fGxogJD0yW6KLKNO/a0pnecfBE6Vvr2/+I25n7c/fzVqUxI= X-Google-Smtp-Source: AHgI3IbU0BvXkFwx0txxenKj83S5Yxd+fBwzlE1VTUyW7B6ixSACLU+bJhd5WsH0i1NEJaGwiumiJojZSETr1x3MRbU= X-Received: by 2002:a05:6000:92:: with SMTP id m18mr22079525wrx.258.1550619623251; Tue, 19 Feb 2019 15:40:23 -0800 (PST) MIME-Version: 1.0 References: <155061923361.20777.11715963540029472578.idtracker@ietfa.amsl.com> In-Reply-To: <155061923361.20777.11715963540029472578.idtracker@ietfa.amsl.com> From: Nick Sullivan Date: Tue, 19 Feb 2019 15:40:11 -0800 Message-ID: To: "" Content-Type: multipart/alternative; boundary="000000000000d38fbe058247c373" Archived-At: Subject: [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: Tue, 19 Feb 2019 23:40:28 -0000 --000000000000d38fbe058247c373 Content-Type: text/plain; charset="UTF-8" TLSWG, We've posted draft -03 of the Delegated Credentials draft. It includes some editorial improvements (thanks Christopher Patton) and two changes discussed on the list: 1) fixing the text around covering the credential in the signature 2) removing the TLS version from the structure We hope to discuss this draft in Prague. Nick ---------- Forwarded message --------- From: Date: Tue, Feb 19, 2019 at 3:33 PM Subject: New Version Notification for draft-ietf-tls-subcerts-03.txt To: Subodh Iyengar , Richard Barnes , Eric Rescorla , Nick Sullivan A new version of I-D, draft-ietf-tls-subcerts-03.txt has been successfully submitted by Nick Sullivan and posted to the IETF repository. Name: draft-ietf-tls-subcerts Revision: 03 Title: Delegated Credentials for TLS Document date: 2019-02-19 Group: tls Pages: 12 URL: https://www.ietf.org/internet-drafts/draft-ietf-tls-subcerts-03.txt Status: https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/ Htmlized: https://tools.ietf.org/html/draft-ietf-tls-subcerts-03 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-subcerts-03 Abstract: The organizational separation between the operator of a TLS server and the certification authority can create limitations. For example, the lifetime of certificates, how they may be used, and the algorithms they support are ultimately determined by the certification authority. This document describes a mechanism by which operators may delegate their own credentials for use in TLS, without breaking compatibility with clients that do not support this specification. 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. The IETF Secretariat --000000000000d38fbe058247c373 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
TLSWG,

We've posted draft -03 of th= e Delegated Credentials draft. It includes some editorial improvements (tha= nks Christopher Patton) and two changes discussed on the list:
1)= fixing the text around covering the credential in the signature
= 2) removing the TLS version from the structure

We = hope to discuss this draft in Prague.

Nick

---= ------- Forwarded message ---------
From: <internet-drafts@ietf.org>
Date: Tue, Feb 19, 20= 19 at 3:33 PM
Subject: New Version Notification for draft-ietf-tls-subce= rts-03.txt
To: Subodh Iyengar <subod= h@fb.com>, Richard Barnes <rlb@ipv.sx>, Eric Rescorla <ekr@rtfm.com>, Nick Sullivan <nick@cloudflare.com>


A new version of I-D, draft-ietf-tls-subcerts-03.txt
has been succ= essfully submitted by Nick Sullivan and posted to the
IETF repository.
Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-tls-subcertsRevision:=C2=A0 =C2=A0 =C2=A0 =C2=A003
Title:=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Delegated Credentials for TLS
Document date:=C2=A0 2019-02-19=
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 tls
Pages:=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 12
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/d= raft-ietf-tls-subcerts-03.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0https://datatracker.ietf.org/doc/draft-i= etf-tls-subcerts/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-ietf-tls-subcerts-03Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0h= ttps://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts
Diff:= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-subcerts-03

Abstract:
=C2=A0 =C2=A0The organizational separation between the ope= rator of a TLS server
=C2=A0 =C2=A0and the certification authority can c= reate limitations.=C2=A0 For example,
=C2=A0 =C2=A0the lifetime of certi= ficates, how they may be used, and the
=C2=A0 =C2=A0algorithms they supp= ort are ultimately determined by the
=C2=A0 =C2=A0certification authorit= y.=C2=A0 This document describes a mechanism by
=C2=A0 =C2=A0which opera= tors may delegate their own credentials for use in TLS,
=C2=A0 =C2=A0wit= hout breaking compatibility with clients that do not support this
=C2=A0= =C2=A0specification.




Please note that it may take a couple of minutes from the time of submi= ssion
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--000000000000d38fbe058247c373-- From nobody Tue Feb 19 16:10: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 A1AD2130FD0 for ; Tue, 19 Feb 2019 16:10:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=comcastmailservice.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 q392ap1kxdVq for ; Tue, 19 Feb 2019 16:10:27 -0800 (PST) Received: from resqmta-po-04v.sys.comcast.net (resqmta-po-04v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66654128B33 for ; Tue, 19 Feb 2019 16:10:27 -0800 (PST) Received: from resomta-po-19v.sys.comcast.net ([96.114.154.243]) by resqmta-po-04v.sys.comcast.net with ESMTP id wBTSgtEztzQkcwFT0g9nuh; Wed, 20 Feb 2019 00:10:26 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1550621426; bh=68vF+6h2XUOQ6mmPYfsBaaNOLS9T9hdgy6BLUSR1BQA=; h=Received:Received:To:From:Subject:Message-ID:Date:MIME-Version: Content-Type; b=gucbm/yVE3kdNL4y1Xx/9PQKP+zKVMeRQtGAMz+BTQhLmdVEWyS432P4sb/2idt8u QN9E3qHaGNJtBjlEdvg7PJrf7Pf4v1SBk9u2KWpGeNc4Ax024DDjg8ZU/rR0lp9nqx M57A0WFruZiwf9M9+etSxecb9zIcH2C4G6zD+2djqE3F3mboNapuB2J/bccZV0dneL 9pwIjw6LABMb7md+Wo7d2midSxdRdGvbbRcPVeFEOmllXxXdX9vKHM9iMCxEYjVa0c 5U3DmtRrVBQm++myHzYLuPeXEV/+x5yJeAqCpnjoYRBp+qtIjN2eQhktKJBSTYbfzk 9bxr9hSZj/4Tg== Received: from [IPv6:::1] ([73.222.32.57]) by resomta-po-19v.sys.comcast.net with ESMTPSA id wFSygFKXXzVxawFSzg6AxY; Wed, 20 Feb 2019 00:10:26 +0000 X-Xfinity-VAAS: gggruggvucftvghtrhhoucdtuddrgedutddrtdehgddulecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucevohhmtggrshhtqdftvghsihdpqfgfvfdppffquffrtefokffrnecuuegrihhlohhuthemuceftddtnecunecujfgurhepvffhuffkffgfgggtgfesthekredttdefjeenucfhrhhomheptehnughrvgihucflihhvshhovhcuoegtrhihphhtohessghrrghinhhhuhgsrdhorhhgqeenucffohhmrghinhepihgvthhfrdhorhhgnecukfhppeejfedrvddvvddrfedvrdehjeenucfrrghrrghmpehhvghloheplgfkrfhvieemmeemudgnpdhinhgvthepjeefrddvvddvrdefvddrheejpdhmrghilhhfrhhomheptghrhihpthhosegsrhgrihhnhhhusgdrohhrghdprhgtphhtthhopehtlhhssehivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedt X-Xfinity-VMeta: sc=??;st=legit To: "tls@ietf.org" From: Andrey Jivsov Openpgp: preference=signencrypt Autocrypt: addr=crypto@brainhub.org; prefer-encrypt=mutual; keydata= mQENBFbFIDkBCAC8U4isfYajmIZOZW/aX9IuLhfGiAkteTTTEUyjSwyC4MvJl+wfWLeoY4FG F5kyQNmVRidkXIq9R1YA6fWXTGMZLGRZ9u3TaBhngdkck9g8x+uloRV7FROQ5Qu8CrlmURB+ Sp1yK3thaKayFmGfglCFuygeCCHfrHkdjOM64bi93NC2vANOUtwZ8bwbCk3RP/twG9yjzevc ZXoYvnzbib0ct9lgOVO+na28F+LvAsLjxQjSEN6Z+BiuF8Uniq27uKeDPWu6/gvVkl3iZJJA 7SFvr8r/AHEl2EoDGzRT/zL/VtRM1neU2G3RpS6Vm1EDez3rRAPmFmDHcLkXoKKYuJ/dABEB AAG0I0FuZHJleSBKaXZzb3YgPGNyeXB0b0BicmFpbmh1Yi5vcmc+iQE4BBMBAgAiBQJWxSA5 AhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRC4BFp9tvLDS4AUCAC6c6zQsm9/gGDW IQy67jMCzKLci9R1GJS5r13vgUHCWdZeZivd0iMuYR/feAV52eqUPWKUZAr6J61QXKfoxyr2 5nK8pk/LJU3nWCPfVsxEHXUnYPYHKpHzlEgbrtyOh/M5eIWGskZDxRBbyxJHV1+Ci5kG/o0s t+DKM4zWOwD+RcO2ktjjXKE/YjAqfoped3JKpzAKyz2OKXsR6QZy0f+lJmRsEU7B6vPBQBnH TRg+4DwkM8MZTKbbygrKPjfaZ0TOBHNzEvjOcyH9OC0jPu0cUOfNoU2ksBPC6aqoSTTFTpV+ 4zAPQtPtUgEir5I73rG8wdAnF828t/GBwraVbQ94uQENBFbFIDkBCADlZHIVKgQsTVQJu6p/ K0iGQA+YpaMaGqp3+BCrScW2rsgauF8ZLJE5tYM6a42bJ1kIq7+PtXm4tq4E7YOcMoVdln6x eta+3La4yKZn3tn6it8YYVK63rG1zQL9epnNPFEfmWH5QWgsLpo2EwQ+Eaue3EvpC9QKImbW vtCHcpZToyYiFLmKusi/njVRUPkr99TCFdMnVrJI7EjPR6vycrlJnIz0ovoOsUm0j9ZRSdax ikUKd1F/h+RMSXpCzx8y6RjR8B8v3zrX9lScygmn1nww54IJtz2ocTIDfLRaqSdViYi/U/sU EYQQoW2Fx5wr9HZo88kJVTB+2sD6ly0ZqfAjABEBAAGJAR8EGAECAAkFAlbFIDkCGwwACgkQ uARafbbyw0vcxwf8DGQVz0FU4/ZJk7PPsHnBtR0oL9PMLfPByQGDTpYFkXMoBh75Yp8EQp6J /ZMRBTwCpbt+amJeahR3IJSWUWomVcHzoVZql4PkphSipp4a6xR0Ah6qtpltviv3ZaAEysvI /JvUc/8wiw9sQwG9GyCQxeH+4npspgXQ2hYjaJOfl4F4P0FzZ3c9xTv0tiBfrdqBzNXu4QY/ jRHxEZzUxPYBvCpEBj1b8j2ZlYEsLEO3Rp8br3WpOhGlhuDOkW3MKtL7tpc749SN8WqiR4Yc JrBwKKi/bfAf4OkMF6+4ZB2fsxyrRWmNc6d2io4+sWsnyFF2NfVbwB6Hcwj46vEmu0SYvA== Message-ID: <6fff39d3-649d-867a-db71-b0faa18185a5@brainhub.org> Date: Tue, 19 Feb 2019 16:10:24 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [TLS] Negotiated Finite Field Diffie-Hellman shared secret calculation 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, 20 Feb 2019 00:10:30 -0000 Greetings. it's unclear to me how is the shared secret g^xy calculated for groups in https://tools.ietf.org/html/rfc7919 . If you recall, the TLS 1.1 uses this method the https://tools.ietf.org/html/rfc4346#section-8.1.2 , causing some interoperability problems that are hard to fix. The RFC 7919 doesn't specify what to do here. So, the question is, assuming that ffdhe2048 is negotiated, - is g^xy padded to 256 bytes (more sound method) or - the leading zero bytes of g^xy must be stripped (legacy method, used for historic reasons)? Thank you. From nobody Tue Feb 19 19:44: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 7AAA0129619; Tue, 19 Feb 2019 19:44:07 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytq0oihp4mAQ; Tue, 19 Feb 2019 19:44:04 -0800 (PST) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB91712E7C1; Tue, 19 Feb 2019 19:44:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1550634244; x=1582170244; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ZJJdKqgJ7s9eNWYPFMVeUu/vOgofkEWdEjoG9ZxJgYs=; b=1xthqVqoJ+TkZyGOuNgDDXRBUxHMrQZJaCfpX4yQ516hCJM3YSFwsWBs 93JBpSBvh9jYHp+XvHkN8Jc8wa+asm56RTimie8bqiJ9+h0Y68WczreoK CHJnN2bcOpRJUNcmfL8hopN92p0VmSt3mLawPRTfSXj6swQKmbmIHcBJa dV4ywj9oGsqj2/kceLfJg+R+q0BN/yYJjEZEKCG+RXpt5s1iiXr1db+ld 6n5GnWpNHCYfvWXMGvelHQnleVvZAvDNVexwvdXKvhAhorjzlsJyIeWDX Xjt4okWmSJRx3SIOeGR8jxReMajSp9iJE5u+xn51eAh1mbzsyw7J8NW45 Q==; X-IronPort-AV: E=Sophos;i="5.58,388,1544439600"; d="scan'208";a="48991172" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.3 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-b.UoA.auckland.ac.nz) ([10.6.3.3]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 20 Feb 2019 16:43:56 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-b.UoA.auckland.ac.nz (10.6.3.3) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 20 Feb 2019 16:43:56 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Wed, 20 Feb 2019 16:43:56 +1300 From: Peter Gutmann To: Dmitry Belyavsky , TLS Mailing List , "secdispatch@ietf.org" Thread-Topic: [TLS] Fwd: New Version Notification for draft-belyavskiy-fakesni-00.txt Thread-Index: AQHUyI5pabpF922zn0mI1OlKDvKL0qXoC8MR Date: Wed, 20 Feb 2019 03:43:56 +0000 Message-ID: <1550634231892.18369@cs.auckland.ac.nz> References: <155060540091.20709.12797700493315209480.idtracker@ietfa.amsl.com>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-belyavskiy-fakesni-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 03:44:08 -0000 Dmitry Belyavsky writes:=0A= =0A= >The draft describes a Fake SNI mechanism intended to cheat DPI systems in = a=0A= >case when a DPI system blocks the connection if ESNI is present.=0A= =0A= Since this mechanism advertises the fact that a fake SNI is present, wouldn= 't=0A= the DPI then also block the connection for that?=0A= =0A= Peter.=0A= =0A= From nobody Tue Feb 19 23:01:56 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E621294FA; Tue, 19 Feb 2019 23:01:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 H4pmwxBbC9bZ; Tue, 19 Feb 2019 23:01:47 -0800 (PST) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48877127287; Tue, 19 Feb 2019 23:01:47 -0800 (PST) Received: by mail-ed1-x52d.google.com with SMTP id m12so18930567edv.4; Tue, 19 Feb 2019 23:01:47 -0800 (PST) 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=fmgvQ2fwxKIjCfG8hOeuGHFlUmA0xHz57MlK81GRA6I=; b=XvTmlYlpWeAUvG2rugQuvspo6MNnpbnKBEGpRc7WeNfLm4TOGGdvkRfeaNC8DyCEP3 NqR72inBvF8VYrdpH0oZIzs8ZqVvOHaaAbyv6uYL+hInv7cZ6ZjtkE3sUvKVWnFuYmEN rZZb8pro0/DdyBA9V3lXQWjNNsLQwVYOtHh3xvBgGbu72JHfoaoDfDhjsFhy+xbIIPOt sRZE7WvSmiiE5o3xpHHv2KFG3jqOzUTvbNq9TLchmhjM22+AIyuOnUnNxOxv89y7Zyu1 4R4nI/wXXxuRzg8FM3gsLFKoaqiO1as36PZOTbhkMSXMEDnwZMwScQP3Ico0DtQqRmXA 0fdw== 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=fmgvQ2fwxKIjCfG8hOeuGHFlUmA0xHz57MlK81GRA6I=; b=fuoA6c7+3F6Ba6jh070TWEev4FvGh8BHVwprVDrw1iKqzBs46X8YnsrA8cAeyrmvhW E+4gC6b2oGLjGWNjziKTLxxnbWj7lhshKKAuGXkg8t/pDBT5uVT3a7OGQuX3fU+N4qMB cOJXlBDgwN+LQrYM95B66BkxxNO9R0N30O8WXaKNROq/fX5uh2rsgb3HfG2hqOTfYg2H UIfaP3QWMghkeeJfLNhjVa7wkSxmi8hcO9T4SROaG6z1BOTBA1EyxEDaOvrZ9X5LQIvv kcqUBtoSggwVkpRw11OHLNHSuA7/xX98akPn937BPs9LsRe6gsxHC3lof+rxPF70iaRf bZIw== X-Gm-Message-State: AHQUAuZMdfESnT4KZNzYXuan3+4fA4K6z+tfTkld9jAdBE89kFvyProc 2FT22p+/2lstLpNYBfVQiIlht+6tJl7jc5cmWzI= X-Google-Smtp-Source: AHgI3Ian6jKs/caKKQQlCGGN9HFb74DBAKJYw+rWPezBfs2kDU0CulCa7WzuVWFGxL8Am+nLXPBI155uHyELHuTsrwE= X-Received: by 2002:a17:906:5944:: with SMTP id g4mr1786825ejr.105.1550646105348; Tue, 19 Feb 2019 23:01:45 -0800 (PST) MIME-Version: 1.0 References: <155060540091.20709.12797700493315209480.idtracker@ietfa.amsl.com> <1550634231892.18369@cs.auckland.ac.nz> In-Reply-To: <1550634231892.18369@cs.auckland.ac.nz> From: Dmitry Belyavsky Date: Wed, 20 Feb 2019 10:01:34 +0300 Message-ID: To: Peter Gutmann Cc: TLS Mailing List , "secdispatch@ietf.org" Content-Type: multipart/alternative; boundary="000000000000481f4205824dee5e" Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-belyavskiy-fakesni-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 07:01:50 -0000 --000000000000481f4205824dee5e Content-Type: text/plain; charset="UTF-8" Dear Peter, On Wed, Feb 20, 2019 at 6:43 AM Peter Gutmann wrote: > Dmitry Belyavsky writes: > > >The draft describes a Fake SNI mechanism intended to cheat DPI systems in > a > >case when a DPI system blocks the connection if ESNI is present. > > Since this mechanism advertises the fact that a fake SNI is present, > wouldn't > the DPI then also block the connection for that? > The suggested mechanism does not advertise the presence of a Fake SNI. Fake SNI is delivered out-of-band for the handshake and an observer has to discover that ClientHello message contains a SNI extension that does not match to any host present at the IP address where we try to connect. Passive collection and blocking the Fake SNI values also has little sense because the value can be changed relatively easily. -- SY, Dmitry Belyavsky --000000000000481f4205824dee5e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Peter,

On Wed, Feb 20, 2019 at 6:43 A= M Peter Gutmann <pgut001@cs= .auckland.ac.nz> wrote:
Dmitry Belyavsky <beldmit@gmail.com> writes:

>The draft describes a Fake SNI mechanism intended to cheat DPI syst= ems in a
>case when a DPI system blocks the connection if ESNI is pre= sent.

Since this mechanism advertises the fact that a fake SNI is present, wo= uldn't
the DPI then also block the connection for that?

The suggested mechanism does not advertise the pres= ence=C2=A0of a Fake SNI.=C2=A0
Fake SNI is delivered out-of-band = for the handshake and an observer has to discover
that ClientHell= o message contains a SNI extension that does not match to any host
present at the IP address where we try to connect.

Passive collection and blocking the Fake SNI values also has little sens= e
because the value can be changed relatively easily.
<= br>
--
SY, Dmitry= Belyavsky
--000000000000481f4205824dee5e-- From nobody Tue Feb 19 23:26:09 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 CF879130DC2; Tue, 19 Feb 2019 23:21:29 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYfDWJXwGmr8; Tue, 19 Feb 2019 23:21:27 -0800 (PST) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 099B112F1A2; Tue, 19 Feb 2019 23:21:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1550647287; x=1582183287; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ZAbqX3gG/waC4UUJev2pUilAgMUEmLfeHplbPGyziKs=; b=bSufxJOcJleAoI+Te9FXysoKO38ZtLAXLNGKaGBwxFD5XENPJGAiz1p4 vaez3JvC/iXgVaHKJ3qbcSs74lnjn2He4fbvqZzfwMo2h436XoqYITvVr xvHvtwaQkO2wG+/eCYXlgBzyvUe9W0O/OrWX2TKrzIHLXkpD/i1x0WMwB GUFZYznbQt3tFgZ+B9zKW/U0NB6Cu0YD820NOuG81U4spMuPS2BppCgff L+lPQNXD7IJV9VeMX+GL3wNxwJgcvjHOX5M+hVkFymX8RLrQJaTm97zs7 FT5yTQA6n5q4umM9+v58uL0YOD3Z/ZdlGkLDIERs2n1W6NOitDk3x1+1C A==; X-IronPort-AV: E=Sophos;i="5.58,388,1544439600"; d="scan'208";a="49003002" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.9 - Outgoing - Outgoing Received: from uxcn13-tdc-e.uoa.auckland.ac.nz ([10.6.3.9]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 20 Feb 2019 20:21:21 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-e.UoA.auckland.ac.nz (10.6.3.9) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 20 Feb 2019 20:21:21 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Wed, 20 Feb 2019 20:21:20 +1300 From: Peter Gutmann To: Dmitry Belyavsky CC: TLS Mailing List , "secdispatch@ietf.org" Thread-Topic: [TLS] Fwd: New Version Notification for draft-belyavskiy-fakesni-00.txt Thread-Index: AQHUyI5pabpF922zn0mI1OlKDvKL0qXoC8MR//9dbACAAN8ehw== Date: Wed, 20 Feb 2019 07:21:20 +0000 Message-ID: <1550647276159.53158@cs.auckland.ac.nz> References: <155060540091.20709.12797700493315209480.idtracker@ietfa.amsl.com> <1550634231892.18369@cs.auckland.ac.nz>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-belyavskiy-fakesni-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 07:21:30 -0000 4oCLRG1pdHJ5IEJlbHlhdnNreSA8YmVsZG1pdEBnbWFpbC5jb20+IHdyaXRlczoKCj5GYWtlIFNO SSBpcyBkZWxpdmVyZWQgb3V0LW9mLWJhbmQgZm9yIHRoZSBoYW5kc2hha2UKCkJ1dCB0aGVuIHdv bid0IHRoZSBEUEkgY2hlY2sgdGhlIG91dC1vZi1iYW5kIHNvdXJjZSBhcyB3ZWxsPyAgSWYgeW91 J3ZlIGdvdCBhCk1JVE0gc2l0dGluZyB0aGVyZSB0aGVuIHRoZXkgY2FuIGRvIHRoZSBzYW1lIGxv b2t1cHMgYW5kIHdoYXRub3QgdGhhdCB0aGUKY2xpZW50IGRvZXMsIHVubGVzcyB5b3UncmUgcmVs eWluZyBvbiB0aGUgY2xpZW50IGJlaW5nIG9mZi1wYXRoLCB3aGljaCBzZWVtcyBhCmJpdCBvZiBh IGxlYXAuICBZb3UnZCBuZWVkIHRvIGltcGxlbWVudCBpdCB2aWEgc29tZSBzb3J0IG9mIHN1Ymxp bWluYWwKc2lnbmFsbGluZyBtZWNoYW5pc20gdGhhdCB0aGUgRFBJIGNhbid0IGRldGVjdC4KClBl dGVyLgo= From nobody Tue Feb 19 23:35:56 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79561130DC2; Tue, 19 Feb 2019 23:35:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 p2A1f2JBua0Q; Tue, 19 Feb 2019 23:35:47 -0800 (PST) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4786B12F1A2; Tue, 19 Feb 2019 23:35:47 -0800 (PST) Received: by mail-ed1-x536.google.com with SMTP id c55so1266688edb.0; Tue, 19 Feb 2019 23:35:47 -0800 (PST) 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=Bpds3bAYsMVY7XlAaaU2wh6ufd1aQ8Kc4B/QfNRLibI=; b=TuvFzWBJOjj1u4Tt5KdypxLKPCtzB5zVmPgS3Rs6Kw7dTWqWusSRGsO5OiCYZ8DN2e YYejcjlx/OarXboO/G/wiZmqkmyegTWVXW3DkOtr66NnZAbtxcj6wiA0UOVZsCDAHFIN MWcuccJhm686CbiV20vKG1jePvT2iNGrQ+Ab7ptzFf/ohQp0abOjIO2wVzAw8rw84Mhg MMLCAao1X1SLbJhuM8kOTjd2dd6bgPIVM7EatlLylepgSRUSg8UiN5gAbABVd4Pn2ZNr Ha6lyP+BuzPyHyK4p2S+T3QPcfXZTJZWU56gpiMWCQwnMfnB/rNjY3zGKuNrHOtVGL/F RJPg== 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=Bpds3bAYsMVY7XlAaaU2wh6ufd1aQ8Kc4B/QfNRLibI=; b=Lw98m3fYPQ83JpwtBj3NL5M16gHouRfiVBuQKhkPBDFQNv+6hm/vUQjScsfXKzTiAe cn0aZOfT6ya9xH3oWS8SZTn7NvaB+6XUs8bGfHDN1gEaOBbOv0OAJdsNRZBrP+dUYzvy sX4cGOFtJJg0W9nA1dt3C/IIDvdbTkRI74hrytnpPszF6i6gmYyce7YxnG2ij1ZIGrIs KPZ5twF12iJiJwgsFKHoUe1i6tOfpMkDcMrOwdLwGq0EaQk9GpUydQ0dyZvRRplYLTo3 oxTUl891hLm3zVFecrk697dwGpqvaWlQ43bBmsfx6VFWEjv1vuEsORo4+1dsNmMDEpXm zr8A== X-Gm-Message-State: AHQUAub8DHg2aiQa4o2qd266MorP3RgMx3HUooDz/yc2rFly64DirRhA KCb7YHs3Ey3urh+kLcNF+vZ8FBeSDyHyZmz3O6k= X-Google-Smtp-Source: AHgI3IYXlMMRlkid9FbtXSvH1tmRFVkEzaHn3Wti3zj/WfznQZ2eqhKoCz4vDXP+K+e9rMPa6p0FmK8/gxJBF4h9QOo= X-Received: by 2002:a05:6402:1682:: with SMTP id a2mr12283222edv.158.1550648145402; Tue, 19 Feb 2019 23:35:45 -0800 (PST) MIME-Version: 1.0 References: <155060540091.20709.12797700493315209480.idtracker@ietfa.amsl.com> <1550634231892.18369@cs.auckland.ac.nz> <1550647276159.53158@cs.auckland.ac.nz> In-Reply-To: <1550647276159.53158@cs.auckland.ac.nz> From: Dmitry Belyavsky Date: Wed, 20 Feb 2019 10:35:34 +0300 Message-ID: To: Peter Gutmann Cc: TLS Mailing List , "secdispatch@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e0e10105824e67eb" Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-belyavskiy-fakesni-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 07:35:50 -0000 --000000000000e0e10105824e67eb Content-Type: text/plain; charset="UTF-8" On Wed, Feb 20, 2019 at 10:21 AM Peter Gutmann wrote: > Dmitry Belyavsky writes: > > >Fake SNI is delivered out-of-band for the handshake > > But then won't the DPI check the out-of-band source as well? If you've > got a > MITM sitting there then they can do the same lookups and whatnot that the > client does, unless you're relying on the client being off-path, which > seems a > bit of a leap. You'd need to implement it via some sort of subliminal > signalling mechanism that the DPI can't detect. > > In fact if DPI begins to poll domains whether FakeSNI record is present, we have a race between changing the value in FakeSNI and DPI polling. And DoH/DoT ensures that DPI has to poll. -- SY, Dmitry Belyavsky --000000000000e0e10105824e67eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Feb 20, 2019 at 10:21 AM Pete= r Gutmann <pgut001@cs.auckl= and.ac.nz> wrote:
Dmitry Belyavsky <beldmit@gmail.com> writes:

>Fake SNI is delivered out-of-band for the handshake

But then won't the DPI check the out-of-band source as well?=C2=A0 = If you've got a
MITM sitting there then they can do the same lookups= and whatnot that the
client does, unless you're relying on the clie= nt being off-path, which seems a
bit of a leap.=C2=A0 You'd need to = implement it via some sort of subliminal
signalling mechanism that the D= PI can't detect.

=C2=A0
In fact if DPI begins to poll domain= s whether FakeSNI record is present,
we have a race between chang= ing the value in FakeSNI and DPI polling.=C2=A0
And DoH/DoT ensur= es that DPI has to poll.


--
SY, Dmitry Belyavsky
--000000000000e0e10105824e67eb-- From nobody Wed Feb 20 03:06:34 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66F91124B0C; Wed, 20 Feb 2019 03:06:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 mrRXKhIl0fsP; Wed, 20 Feb 2019 03:06:24 -0800 (PST) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 797F612DDA3; Wed, 20 Feb 2019 03:06:24 -0800 (PST) Received: by mail-ed1-x534.google.com with SMTP id j89so10106091edb.9; Wed, 20 Feb 2019 03:06:24 -0800 (PST) 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=HzSX3Q+rFzHbR5GhhBiQ5kLhu+EPgFAVL7k0WUVz4nI=; b=ckLWU1RsDfzkzBRjOLfypD/I2e6HRR3kh/dMhWntx+MJLJ2hKp9IC4yCTeP84VrcYV O966fCfsnnmBPlH4rku43CLfT7sA4MhZFrRzMrzF8F8P0xN5dzxSI9q3wI9eYCt+mGL7 fah6A/sn1Xbww2f351N+fHjm+oQqA0Uu1PhektmtFoPdh1FbWi4f8lFLWeU1Kb3cHXlf gkGh8vykjmhR3rhm+X60Lt2m2pXxjiJNWBPLwtiZE8SUHmqGHpby/EaOOidV+wvnYtlH fb6NfXfCWQV4xGXJJnEo5k6FGP0OgVKRvN2EclR3A3rQTf9G72CyxzYffPE/0ZDCpfNu FBEA== 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=HzSX3Q+rFzHbR5GhhBiQ5kLhu+EPgFAVL7k0WUVz4nI=; b=Q5f6zOxr87NSrnAPOrs7VNStg6RDDuZvaaep6S+HRNZP4K8uXHUzueYCYxZ0aTfQEH F0ldaVmleigYedo/J8ST+sTSGiid0aF3opsYCWasMiOQ553s6py8dW/HRf3lK8aN9C9n clImzLkdVR42/A1h15NcfMbWUYUG4JPYS3Zk+5ShE05guSoVDJApvNYxu4Z0TwjU7+jH 08UrikPJWMdt8Y2qkLuOy4Ydvc/a0rZs/DsGATNSqPYzx+TpXwOKbCVaE2G8rQ6EPwhq Pwj5qhsiBHIGyPPLDUVxD1zrPikTM8yTP3IVtnKtHmcOqcOSE3dY/VKR/83aDP3s8Lhg JCVg== X-Gm-Message-State: AHQUAuZeN1BxmtLAE9sC3N3lb1WhkkGjDjTjMs/fdfBvgBH1wA1/CSgZ lqOtt2Z4UKpkTG3BzquwT5GsoO73nQcZAqgajUU= X-Google-Smtp-Source: AHgI3IapKPELsuAcrkE6rNRarNBIsY2DhEPQnlyIp8vpaEFYtaxdzTsuS0jDTdYKTr656X9vzl7OQaAexoq6ISZxrjY= X-Received: by 2002:a50:b6f4:: with SMTP id f49mr1667322ede.80.1550660782820; Wed, 20 Feb 2019 03:06:22 -0800 (PST) MIME-Version: 1.0 References: <155060540091.20709.12797700493315209480.idtracker@ietfa.amsl.com> <1550634231892.18369@cs.auckland.ac.nz> <1550647276159.53158@cs.auckland.ac.nz> In-Reply-To: From: Dmitry Belyavsky Date: Wed, 20 Feb 2019 14:06:20 +0300 Message-ID: To: Peter Gutmann Cc: TLS Mailing List , "secdispatch@ietf.org" Content-Type: multipart/alternative; boundary="00000000000020938a05825159be" Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-belyavskiy-fakesni-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 11:06:27 -0000 --00000000000020938a05825159be Content-Type: text/plain; charset="UTF-8" On Wed, Feb 20, 2019 at 10:35 AM Dmitry Belyavsky wrote: > > > On Wed, Feb 20, 2019 at 10:21 AM Peter Gutmann > wrote: > >> Dmitry Belyavsky writes: >> >> >Fake SNI is delivered out-of-band for the handshake >> >> But then won't the DPI check the out-of-band source as well? If you've >> got a >> MITM sitting there then they can do the same lookups and whatnot that the >> client does, unless you're relying on the client being off-path, which >> seems a >> bit of a leap. You'd need to implement it via some sort of subliminal >> signalling mechanism that the DPI can't detect. >> >> > In fact if DPI begins to poll domains whether FakeSNI record is present, > we have a race between changing the value in FakeSNI and DPI polling. > And DoH/DoT ensures that DPI has to poll. > > Let me clarify. I understand that the solution I propose is not perfect. But there is no silver bullet, and this is just another way to make a life of DPI harder. -- SY, Dmitry Belyavsky --00000000000020938a05825159be Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Feb 20, 2019 at 10:35 AM Dmit= ry Belyavsky <beldmit@gmail.com= > wrote:


On Wed, Feb 20, 2019 at 10:21 AM Peter Gu= tmann <pg= ut001@cs.auckland.ac.nz> wrote:
Dmitry Belyavsky <beldmit@gmail.com> writes:

>Fake SNI is delivered out-of-band for the handshake

But then won't the DPI check the out-of-band source as well?=C2=A0 = If you've got a
MITM sitting there then they can do the same lookups= and whatnot that the
client does, unless you're relying on the clie= nt being off-path, which seems a
bit of a leap.=C2=A0 You'd need to = implement it via some sort of subliminal
signalling mechanism that the D= PI can't detect.

=C2=A0
In fact if DPI begins to poll domain= s whether FakeSNI record is present,
we have a race between chang= ing the value in FakeSNI and DPI polling.=C2=A0
And DoH/DoT ensur= es that DPI has to poll.

=
Let me clarify. I understand that the solution I propose is = not perfect.=C2=A0
But there is no silver bullet, and this is jus= t another way to make a life of DPI harder.

--
SY, Dmitry Belyavsky
--00000000000020938a05825159be-- From nobody Wed Feb 20 10:29:27 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8156F130E2F for ; Wed, 20 Feb 2019 10:29:25 -0800 (PST) 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 P3KrmjoRGPBC for ; Wed, 20 Feb 2019 10:29:23 -0800 (PST) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8DC9130E6A for ; Wed, 20 Feb 2019 10:29:22 -0800 (PST) Received: by mail-qk1-x731.google.com with SMTP id o125so2630034qkf.3 for ; Wed, 20 Feb 2019 10:29:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Rkrg2fXVzjPo52A6GHFj025fj7ykz6Lqs1D52eyE1j4=; b=Br+SE7nmVNb3II6P22loNt8rdYpTayZyFsT3t8cBQMOaXyjheSPMrtOcNALsBYuVyH H16qjGKHhPPiCiMQCQCpEtxuiKIHa4O4e//FE9McBMl1VQ0QnGoUmTYJ0Jz6pm3zYC1u euRnxX+q5+f8FefUWIc8Qv19OkfEB4BQh5GQY= 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=Rkrg2fXVzjPo52A6GHFj025fj7ykz6Lqs1D52eyE1j4=; b=BWhFtOlydSpsyWzqDnn1CQ571ouVYisAE5VGWhbBA6l897oNJ/8c9K7GwPrHg7vAAU Yjw9GDwuuxNUFFQfXRcPn5vdgAKlJYiMOLkIxv1L7d3Aa/pKKvFPyeTUFCX/AwXlMfp7 IhoKJBr+Ge5UzYxepHyWi7JuIUWXM9HMC/SohHNzefIPhSGwKP26bZ4D24b/fCB/ITxU NV/hkEaWKCZNm2PY2FsDB8vGHRk/21m4uxK6aZrFYzSkaoZWXZOaVjm6TDSd9wQp/pCM lvPLFZrK7w+uumSE0mPol0NR4mz9FzhxSYHcfIa764KCuV6t6cyM7hZRi7DHCW+L9aa1 rL3A== X-Gm-Message-State: AHQUAuawgNml2LeYlLmP9gmC9hYtMHlOFxAK34FOgeI3/p3jb0zIfICw 0QoO88qc3wfDFd1BrNryoiur4aVl10Ry1a/G9vlk78JcC2ix X-Google-Smtp-Source: AHgI3Ibb2PSNDXBG3HFAJ6eQczW812/LvpMgQeUUFzmtweHPOh38xdfNUibyxa/EqZuzFliIM+Io6foDezdwLGtHjVc= X-Received: by 2002:a37:5ac2:: with SMTP id o185mr12937003qkb.349.1550687361475; Wed, 20 Feb 2019 10:29:21 -0800 (PST) MIME-Version: 1.0 References: <6fff39d3-649d-867a-db71-b0faa18185a5@brainhub.org> In-Reply-To: <6fff39d3-649d-867a-db71-b0faa18185a5@brainhub.org> From: David Benjamin Date: Wed, 20 Feb 2019 12:29:09 -0600 Message-ID: To: Andrey Jivsov Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="00000000000057115105825789df" Archived-At: Subject: Re: [TLS] Negotiated Finite Field Diffie-Hellman shared secret calculation 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, 20 Feb 2019 18:29:26 -0000 --00000000000057115105825789df Content-Type: text/plain; charset="UTF-8" (We haven't actually implemented RFC 7919 and have no plans to, so I'm just going by the document.) RFC 7919 doesn't say anything, so I think the only reasonable interpretation is to continue with the legacy option for TLS 1.2 and below. It's also the only interoperable option given how the document is set up. RFC 7919 repurposed the existing DHE scheme with no directly visible server differences, so the client cannot tell if it is talking to a post-7919 server, or a pre-7919 server that happened to use a well-known parameter. That means 7919 cannot change how DHE works. (This isn't the only consequence of that decision. See https://mailarchive.ietf.org/arch/msg/tls/bAOJD281iGc2HuEVq0uUlpYL2Mo. DHE in TLS 1.2 is a mess and RFC 7919 failed to repair it.) Note all this only applies to TLS 1.2. TLS 1.3 is free to use the more sound method and does: https://tools.ietf.org/html/rfc8446#section-7.4.1 On Tue, Feb 19, 2019 at 6:10 PM Andrey Jivsov wrote: > Greetings. > > it's unclear to me how is the shared secret g^xy calculated for groups > in https://tools.ietf.org/html/rfc7919 . > > If you recall, the TLS 1.1 uses this method the > https://tools.ietf.org/html/rfc4346#section-8.1.2 , causing some > interoperability problems that are hard to fix. > > The RFC 7919 doesn't specify what to do here. > > So, the question is, assuming that ffdhe2048 is negotiated, > > - is g^xy padded to 256 bytes (more sound method) or > - the leading zero bytes of g^xy must be stripped (legacy method, used > for historic reasons)? > > Thank you. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --00000000000057115105825789df Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(We haven't actually= implemented RFC 7919 and have no plans to, so I'm just going by the do= cument.)

RFC 7919 doesn= 9;t say anything, so I think the only reasonable interpretation is to conti= nue with the legacy option for TLS 1.2 and below. It's also the only in= teroperable option given how the document is set up. RFC 7919 repurposed th= e existing DHE scheme with no directly visible server differences, so the c= lient cannot tell if it is talking to a post-7919 server, or a pre-7919 ser= ver that happened to use a well-known parameter. That means 7919 cannot cha= nge how DHE works. (This isn't the only consequence of that decision. S= ee=C2=A0https://mailarchive.ietf.org/arch/msg/tls/= bAOJD281iGc2HuEVq0uUlpYL2Mo. DHE in TLS 1.2 is a mess and RFC 7919 fail= ed to repair it.)

Note all this only applies to TLS 1.2. TLS 1.3 is = free to use the more sound method and does:
https://tools.ietf.org/= html/rfc8446#section-7.4.1

On Tue, Feb 19, 2019 at 6:10 = PM Andrey Jivsov <crypto@brainhub.org> wrote:
Greetings.

it's unclear to me how is the shared secret g^xy calculated for groups<= br> in https://tools.ietf.org/html/rfc7919 .

If you recall, the TLS 1.1 uses this method the
https://tools.ietf.org/html/rfc4346#section-8.1.2 , causing some
interoperability problems that are hard to fix.

The RFC 7919 doesn't specify what to do here.

So, the question is, assuming that ffdhe2048 is negotiated,

- is g^xy padded to 256 bytes (more sound method) or
- the leading zero bytes of g^xy must be stripped (legacy method, used
for historic reasons)?

Thank you.

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--00000000000057115105825789df-- From nobody Wed Feb 20 10:48: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 94C2B130E7A for ; Wed, 20 Feb 2019 10:48:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=comcastmailservice.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 GYc0I50r_uIo for ; Wed, 20 Feb 2019 10:48:44 -0800 (PST) Received: from resqmta-po-09v.sys.comcast.net (resqmta-po-09v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:168]) (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 B96CA130E77 for ; Wed, 20 Feb 2019 10:48:44 -0800 (PST) Received: from resomta-po-15v.sys.comcast.net ([96.114.154.239]) by resqmta-po-09v.sys.comcast.net with ESMTP id wSvygMFL0uXuhwWvDglFDf; Wed, 20 Feb 2019 18:48:43 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1550688523; bh=ydSTA24JUUe3b2rKZ9UgWXhXEFq3fPxfuqvtF1NuVFs=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=hCopxnCZ8hD0GfOFYll9NxUf6yEY0XaYojvqLGZaguBecvurBllMsbjvsIrWMJbZc HihabbcPARxZZU8gg7YPKeXGDqvxsnIM9qmGqDYDwHFaI1WnW7LI+ZaGvWeUdaWAFV MqzF4NZLEsWl0SfR3tKib+P0uMYv+qOXmBBNLGcJkrovFzIyOZ7vtJ/oN0xtCmH6g5 Y32kwqDOGjbaMUtlajPmNrHVtIj19hJOZBN+M5mzUGXcUa+0i0UVvH8ZydRtle2c2p q9pZoH2sspQGqImC+cLNvb9oq358xmeCxgGDuhKtMcvcHvSvn/P5uL5RS96g5MIaTS RMZQlViDhM3Xw== Received: from [IPv6:::1] ([73.222.32.57]) by resomta-po-15v.sys.comcast.net with ESMTPSA id wWvCgp82OPENhwWvCgRlBw; Wed, 20 Feb 2019 18:48:43 +0000 X-Xfinity-VAAS: gggruggvucftvghtrhhoucdtuddrgedutddrtdeigdduudekucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuvehomhgtrghsthdqtfgvshhipdfqfgfvpdfpqffurfetoffkrfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepufhfvffhkffffgggjggtgfesthekredttdefjeenucfhrhhomheptehnughrvgihucflihhvshhovhcuoegtrhihphhtohessghrrghinhhhuhgsrdhorhhgqeenucffohhmrghinhepihgvthhfrdhorhhgnecukfhppeejfedrvddvvddrfedvrdehjeenucfrrghrrghmpehhvghloheplgfkrfhvieemmeemudgnpdhinhgvthepjeefrddvvddvrdefvddrheejpdhmrghilhhfrhhomheptghrhihpthhosegsrhgrihhnhhhusgdrohhrghdprhgtphhtthhopegurghvihgusggvnhestghhrhhomhhiuhhmrdhorhhgpdhrtghpthhtohepthhlshesihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptd X-Xfinity-VMeta: sc=??;st=legit References: <6fff39d3-649d-867a-db71-b0faa18185a5@brainhub.org> To: "tls@ietf.org" From: Andrey Jivsov Openpgp: preference=signencrypt Autocrypt: addr=crypto@brainhub.org; prefer-encrypt=mutual; keydata= mQENBFbFIDkBCAC8U4isfYajmIZOZW/aX9IuLhfGiAkteTTTEUyjSwyC4MvJl+wfWLeoY4FG F5kyQNmVRidkXIq9R1YA6fWXTGMZLGRZ9u3TaBhngdkck9g8x+uloRV7FROQ5Qu8CrlmURB+ Sp1yK3thaKayFmGfglCFuygeCCHfrHkdjOM64bi93NC2vANOUtwZ8bwbCk3RP/twG9yjzevc ZXoYvnzbib0ct9lgOVO+na28F+LvAsLjxQjSEN6Z+BiuF8Uniq27uKeDPWu6/gvVkl3iZJJA 7SFvr8r/AHEl2EoDGzRT/zL/VtRM1neU2G3RpS6Vm1EDez3rRAPmFmDHcLkXoKKYuJ/dABEB AAG0I0FuZHJleSBKaXZzb3YgPGNyeXB0b0BicmFpbmh1Yi5vcmc+iQE4BBMBAgAiBQJWxSA5 AhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRC4BFp9tvLDS4AUCAC6c6zQsm9/gGDW IQy67jMCzKLci9R1GJS5r13vgUHCWdZeZivd0iMuYR/feAV52eqUPWKUZAr6J61QXKfoxyr2 5nK8pk/LJU3nWCPfVsxEHXUnYPYHKpHzlEgbrtyOh/M5eIWGskZDxRBbyxJHV1+Ci5kG/o0s t+DKM4zWOwD+RcO2ktjjXKE/YjAqfoped3JKpzAKyz2OKXsR6QZy0f+lJmRsEU7B6vPBQBnH TRg+4DwkM8MZTKbbygrKPjfaZ0TOBHNzEvjOcyH9OC0jPu0cUOfNoU2ksBPC6aqoSTTFTpV+ 4zAPQtPtUgEir5I73rG8wdAnF828t/GBwraVbQ94uQENBFbFIDkBCADlZHIVKgQsTVQJu6p/ K0iGQA+YpaMaGqp3+BCrScW2rsgauF8ZLJE5tYM6a42bJ1kIq7+PtXm4tq4E7YOcMoVdln6x eta+3La4yKZn3tn6it8YYVK63rG1zQL9epnNPFEfmWH5QWgsLpo2EwQ+Eaue3EvpC9QKImbW vtCHcpZToyYiFLmKusi/njVRUPkr99TCFdMnVrJI7EjPR6vycrlJnIz0ovoOsUm0j9ZRSdax ikUKd1F/h+RMSXpCzx8y6RjR8B8v3zrX9lScygmn1nww54IJtz2ocTIDfLRaqSdViYi/U/sU EYQQoW2Fx5wr9HZo88kJVTB+2sD6ly0ZqfAjABEBAAGJAR8EGAECAAkFAlbFIDkCGwwACgkQ uARafbbyw0vcxwf8DGQVz0FU4/ZJk7PPsHnBtR0oL9PMLfPByQGDTpYFkXMoBh75Yp8EQp6J /ZMRBTwCpbt+amJeahR3IJSWUWomVcHzoVZql4PkphSipp4a6xR0Ah6qtpltviv3ZaAEysvI /JvUc/8wiw9sQwG9GyCQxeH+4npspgXQ2hYjaJOfl4F4P0FzZ3c9xTv0tiBfrdqBzNXu4QY/ jRHxEZzUxPYBvCpEBj1b8j2ZlYEsLEO3Rp8br3WpOhGlhuDOkW3MKtL7tpc749SN8WqiR4Yc JrBwKKi/bfAf4OkMF6+4ZB2fsxyrRWmNc6d2io4+sWsnyFF2NfVbwB6Hcwj46vEmu0SYvA== Message-ID: <797b3723-3257-1b08-6f78-5752922fb7d3@brainhub.org> Date: Wed, 20 Feb 2019 10:48:42 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] Negotiated Finite Field Diffie-Hellman shared secret calculation 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, 20 Feb 2019 18:48:48 -0000 Why isn't the "The server indicates the choice of group to the client by sending the group's parameters as usual in the ServerKeyExchange" https://tools.ietf.org/html/rfc7919#section-4 an evidence that the server supports RFC 7919? On 2/20/19 10:29 AM, David Benjamin wrote: > (We haven't actually implemented RFC 7919 and have no plans to, so I'm > just going by the document.) > > RFC 7919 doesn't say anything, so I think the only reasonable > interpretation is to continue with the legacy option for TLS 1.2 and > below. It's also the only interoperable option given how the document is > set up. RFC 7919 repurposed the existing DHE scheme with no directly > visible server differences, so the client cannot tell if it is talking > to a post-7919 server, or a pre-7919 server that happened to use a > well-known parameter. That means 7919 cannot change how DHE works. (This > isn't the only consequence of that decision. > See https://mailarchive.ietf.org/arch/msg/tls/bAOJD281iGc2HuEVq0uUlpYL2Mo. > DHE in TLS 1.2 is a mess and RFC 7919 failed to repair it.) > > Note all this only applies to TLS 1.2. TLS 1.3 is free to use the more > sound method and does: > https://tools.ietf.org/html/rfc8446#section-7.4.1 > > On Tue, Feb 19, 2019 at 6:10 PM Andrey Jivsov > wrote: > > Greetings. > > it's unclear to me how is the shared secret g^xy calculated for groups > in https://tools.ietf.org/html/rfc7919 . > > If you recall, the TLS 1.1 uses this method the > https://tools.ietf.org/html/rfc4346#section-8.1.2 , causing some > interoperability problems that are hard to fix. > > The RFC 7919 doesn't specify what to do here. > > So, the question is, assuming that ffdhe2048 is negotiated, > > - is g^xy padded to 256 bytes (more sound method) or > - the leading zero bytes of g^xy must be stripped (legacy method, used > for historic reasons)? > > Thank you. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Wed Feb 20 11:08: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 DD35D130E7B for ; Wed, 20 Feb 2019 11:08:23 -0800 (PST) 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 vopd5W7xN2uf for ; Wed, 20 Feb 2019 11:08:21 -0800 (PST) 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 9A2C4130E7A for ; Wed, 20 Feb 2019 11:08:21 -0800 (PST) Received: by mail-qt1-x82e.google.com with SMTP id z39so28584211qtz.0 for ; Wed, 20 Feb 2019 11:08:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GnJ4CGT3gk5j3PrBruiREC1jlnPB0uO8qYipMPdQnDc=; b=MeSNtfTaVgZmrDnQ8sT4pLL5yeH6IJq06XVsOKKhwv7oM19aECY42PnIXAKZm0KuGk 1ZWR6CZZou9KVxFVqshXwnPdsyWnsgPyfImdyBCrizOwjHJoT8V5eTSlRhouYmusIcx3 /QpF1ACxHmEb+ovitDoDdJSTlQkOO5/ACqybQ= 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=GnJ4CGT3gk5j3PrBruiREC1jlnPB0uO8qYipMPdQnDc=; b=VkAEGCtkd8Y+xaP0v6Dh7JBeKIRNme/iJAIKT4y8HRg/lbCV1DQIHsvZBXDbHpdhoP YX26ZcNCPsG2nJ6TlXlRiI0hfTA4OqgvoBoJ0LNgj/hH2o2jI1tf4CTQKNtmoqIdjvmY AVuIsqP+iQskWGx0O/ka2SHwepntapkUUqk4UJOgP0yx4BhJrTMIYFJHME1JYFrleV3g yr/BJfSdwCsymCmUYsAI0DBFqxItG4QMUR1XchhL22GBwIhS8XWU4YKvJOzeZaD22SpA Y+94W0vkKylk7cgH3VgOMaaIOXD3XFRQJyzn/5ZbY2QWcsX4oQXTptlvSBbdJ2NCOavX P3GQ== X-Gm-Message-State: AHQUAuaIIdmz09ywFx9V9mXIv+pz/teTKRBWoEPE5YqHe94MgOXqH75p eZqWKFKQdo7xK9AG991FQqrIaIV70a7vLLNLhzLI X-Google-Smtp-Source: AHgI3IZEE3FL/ZNQaYBut3DprLrELyUPDyJSPGHGSFIa8wZyhtHalxuYibKj3gzfsJhI+a6182zdBcduDYodS+6uMSA= X-Received: by 2002:ac8:3775:: with SMTP id p50mr15379128qtb.202.1550689700535; Wed, 20 Feb 2019 11:08:20 -0800 (PST) MIME-Version: 1.0 References: <6fff39d3-649d-867a-db71-b0faa18185a5@brainhub.org> <797b3723-3257-1b08-6f78-5752922fb7d3@brainhub.org> In-Reply-To: <797b3723-3257-1b08-6f78-5752922fb7d3@brainhub.org> From: David Benjamin Date: Wed, 20 Feb 2019 13:08:09 -0600 Message-ID: To: Andrey Jivsov Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c24a4005825814bd" Archived-At: Subject: Re: [TLS] Negotiated Finite Field Diffie-Hellman shared secret calculation 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, 20 Feb 2019 19:08:24 -0000 --000000000000c24a4005825814bd Content-Type: text/plain; charset="UTF-8" It is some evidence, but the server may have been configured with that group anyway. Regardless, the specification doesn't say anything, so I think the only reasonable interpretation is the existing TLS 1.2 mechanism, sadly. On Wed, Feb 20, 2019 at 12:48 PM Andrey Jivsov wrote: > Why isn't the > > "The server indicates > the choice of group to the client by sending the group's parameters > as usual in the ServerKeyExchange" > https://tools.ietf.org/html/rfc7919#section-4 > > an evidence that the server supports RFC 7919? > > On 2/20/19 10:29 AM, David Benjamin wrote: > > (We haven't actually implemented RFC 7919 and have no plans to, so I'm > > just going by the document.) > > > > RFC 7919 doesn't say anything, so I think the only reasonable > > interpretation is to continue with the legacy option for TLS 1.2 and > > below. It's also the only interoperable option given how the document is > > set up. RFC 7919 repurposed the existing DHE scheme with no directly > > visible server differences, so the client cannot tell if it is talking > > to a post-7919 server, or a pre-7919 server that happened to use a > > well-known parameter. That means 7919 cannot change how DHE works. (This > > isn't the only consequence of that decision. > > See > https://mailarchive.ietf.org/arch/msg/tls/bAOJD281iGc2HuEVq0uUlpYL2Mo. > > DHE in TLS 1.2 is a mess and RFC 7919 failed to repair it.) > > > > Note all this only applies to TLS 1.2. TLS 1.3 is free to use the more > > sound method and does: > > https://tools.ietf.org/html/rfc8446#section-7.4.1 > > > > On Tue, Feb 19, 2019 at 6:10 PM Andrey Jivsov > > wrote: > > > > Greetings. > > > > it's unclear to me how is the shared secret g^xy calculated for > groups > > in https://tools.ietf.org/html/rfc7919 . > > > > If you recall, the TLS 1.1 uses this method the > > https://tools.ietf.org/html/rfc4346#section-8.1.2 , causing some > > interoperability problems that are hard to fix. > > > > The RFC 7919 doesn't specify what to do here. > > > > So, the question is, assuming that ffdhe2048 is negotiated, > > > > - is g^xy padded to 256 bytes (more sound method) or > > - the leading zero bytes of g^xy must be stripped (legacy method, > used > > for historic reasons)? > > > > Thank you. > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > --000000000000c24a4005825814bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It is some evidence, but the server may have been configur= ed with that group anyway. Regardless, the specification doesn't say an= ything, so I think the only reasonable interpretation is the existing TLS 1= .2 mechanism, sadly.

On Wed, Feb 20, 2019 at 12:48 PM Andrey Jivsov <= crypto@brainhub.org> wrote:
Why isn't the=

"The server indicates
the choice of group to the client by sending the group's parameters
as usual in the ServerKeyExchange"
https://tools.ietf.org/html/rfc7919#section-4

an evidence that the server supports RFC 7919?

On 2/20/19 10:29 AM, David Benjamin wrote:
> (We haven't actually implemented RFC 7919 and have no plans to, so= I'm
> just going by the document.)
>
> RFC 7919 doesn't say anything, so I think the only reasonable
> interpretation is to continue with the legacy option for TLS 1.2 and > below. It's also the only interoperable option given how the docum= ent is
> set up. RFC 7919 repurposed the existing DHE scheme with no directly > visible server differences, so the client cannot tell if it is talking=
> to a post-7919 server, or a pre-7919 server that happened to use a
> well-known parameter. That means 7919 cannot change how DHE works. (Th= is
> isn't the only consequence of that decision.
> See=C2=A0https://mailarchi= ve.ietf.org/arch/msg/tls/bAOJD281iGc2HuEVq0uUlpYL2Mo.
> DHE in TLS 1.2 is a mess and RFC 7919 failed to repair it.)
>
> Note all this only applies to TLS 1.2. TLS 1.3 is free to use the more=
> sound method and does:
> https://tools.ietf.org/html/rfc8446#section-7.= 4.1
>
> On Tue, Feb 19, 2019 at 6:10 PM Andrey Jivsov <crypto@brainhub.org
> <mailto:cr= ypto@brainhub.org>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Greetings.
>
>=C2=A0 =C2=A0 =C2=A0it's unclear to me how is the shared secret g^x= y calculated for groups
>=C2=A0 =C2=A0 =C2=A0in https://tools.ietf.org/html/rfc7919 .
>
>=C2=A0 =C2=A0 =C2=A0If you recall, the TLS 1.1 uses this method the
>=C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html= /rfc4346#section-8.1.2 , causing some
>=C2=A0 =C2=A0 =C2=A0interoperability problems that are hard to fix.
>
>=C2=A0 =C2=A0 =C2=A0The RFC 7919 doesn't specify what to do here. >
>=C2=A0 =C2=A0 =C2=A0So, the question is, assuming that ffdhe2048 is neg= otiated,
>
>=C2=A0 =C2=A0 =C2=A0- is g^xy padded to 256 bytes (more sound method) o= r
>=C2=A0 =C2=A0 =C2=A0- the leading zero bytes of g^xy must be stripped (= legacy method, used
>=C2=A0 =C2=A0 =C2=A0for historic reasons)?
>
>=C2=A0 =C2=A0 =C2=A0Thank you.
>
>=C2=A0 =C2=A0 =C2=A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0TLS mailing list
>=C2=A0 =C2=A0 =C2=A0T= LS@ietf.org <mailto:TLS@ietf.org>
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listin= fo/tls
>

--000000000000c24a4005825814bd-- From nobody Wed Feb 20 13:24: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 707EF128CF3 for ; Wed, 20 Feb 2019 13:24:11 -0800 (PST) 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=fMayLsdQ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nrrNtc4b Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k73sXyjVHghI for ; Wed, 20 Feb 2019 13:24:09 -0800 (PST) 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 AEE2812D4E7 for ; Wed, 20 Feb 2019 13:24:07 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id BC8B622BE4 for ; Wed, 20 Feb 2019 16:24:06 -0500 (EST) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Wed, 20 Feb 2019 16:24:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:in-reply-to:references:date:from:to:subject :content-type; s=fm1; bh=7UevuSrCITcyjCWmJxXJTbCZ+n+G6BPx46sKWyT 6wDY=; b=fMayLsdQPwusgjKSrO5unHE0kMpcGsowjeE0HsFx8iKjmsgBlNZEo36 iuOQqHB/sc4ZALTYy73W58S0HT3ksD/It4EzbC+Ae7H/PtJj3zQj24szgJ6ujrBe uwGGBA6vnpQTXDxHGuOUKDgRV88cKqEFNAB75jdq+9CC45IUvc8m2yjx9EGNqgBY +mRYp39PXN6gE/Jlgrl284M414EaJ+jPsxO6tRot+2/mRXmyFrZoEGjPuzqLs51Z Jk9DfWvVtx6YGMfFJxjJJzGbI37NcotgztNen/4CS+OAEFRQZUXCj/gq+hBNVjhl gCQNfHrzHxYkUgwWt7rfCJk8CIjRRKQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=7UevuSrCITcyjCWmJ xXJTbCZ+n+G6BPx46sKWyT6wDY=; b=nrrNtc4bVAgEvvijbXhhRqkovuTZEBWhF SbbGMSLSpb3b7v6KO8E4eXsuRUFpVtm8aFTxww1Qn8ZxoE9nrDurgqZY0k9wNeXc WDYi33LOqHdQ3HEjiuPnJn0X7OajVLih6hVMhNTZW1jyJ3HwCkYijueIhOhRyGKc icCrtNCdif6bHsZ10ZVctF/0pPHRbmJuaomzv4h1+9H3Aiq1NHY873RBL6e76w2I jexQFrWanBsJgoWjugOtVLX8x24iHYU2XetZAX3Rb6cI3kUZIRq5I2URqlHoIohD +RgIW9DPRjstE+bPiTVqJjo9R8ONYqlc0PVAHqNP4LZHiLxWPLTgw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrtdeigddugeekucdltddurdegtdelrddttd dmucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhht necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfkfgjfhffhffvufgtsehttd ertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucffohhmrghinhepihgvthhfrdhorhhgnecurfgrrh grmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvghtnecuvehluhhs thgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 596E67C22A; Wed, 20 Feb 2019 16:24:06 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-895-g0d23ba6-fmstable-20190213v1 X-Me-Personality: 92534000 Message-Id: In-Reply-To: References: <6fff39d3-649d-867a-db71-b0faa18185a5@brainhub.org> <797b3723-3257-1b08-6f78-5752922fb7d3@brainhub.org> Date: Wed, 20 Feb 2019 16:24:06 -0500 From: "Martin Thomson" To: tls@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [TLS] =?utf-8?q?Negotiated_Finite_Field_Diffie-Hellman_shared_se?= =?utf-8?q?cret_calculation?= 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, 20 Feb 2019 21:24:11 -0000 What David said. We implement 7919, which includes an option to only accept server shares from the 7919 groups. With that option a simple comparison is used to determine if the group is one from the spec, rejecting all else, but we otherwise just treat the share as normal. I'm not aware of anyone seriously using it though, so the usual concerns about it's use in TLS 1.2 remain. --Martin On Wed, Feb 20, 2019, at 11:08, David Benjamin wrote: > It is some evidence, but the server may have been configured with that > group anyway. Regardless, the specification doesn't say anything, so I > think the only reasonable interpretation is the existing TLS 1..2 > mechanism, sadly. > > On Wed, Feb 20, 2019 at 12:48 PM Andrey Jivsov wrote: > > Why isn't the > > > > "The server indicates > > the choice of group to the client by sending the group's parameters > > as usual in the ServerKeyExchange" > > https://tools.ietf.org/html/rfc7919#section-4 > > > > an evidence that the server supports RFC 7919? > > > > On 2/20/19 10:29 AM, David Benjamin wrote: > > > (We haven't actually implemented RFC 7919 and have no plans to, so I'm > > > just going by the document.) > > > > > > RFC 7919 doesn't say anything, so I think the only reasonable > > > interpretation is to continue with the legacy option for TLS 1.2 and > > > below. It's also the only interoperable option given how the document is > > > set up. RFC 7919 repurposed the existing DHE scheme with no directly > > > visible server differences, so the client cannot tell if it is talking > > > to a post-7919 server, or a pre-7919 server that happened to use a > > > well-known parameter. That means 7919 cannot change how DHE works. (This > > > isn't the only consequence of that decision. > > > See https://mailarchive.ietf.org/arch/msg/tls/bAOJD281iGc2HuEVq0uUlpYL2Mo. > > > DHE in TLS 1.2 is a mess and RFC 7919 failed to repair it.) > > > > > > Note all this only applies to TLS 1.2. TLS 1.3 is free to use the more > > > sound method and does: > > > https://tools.ietf.org/html/rfc8446#section-7.4.1 > > > > > > On Tue, Feb 19, 2019 at 6:10 PM Andrey Jivsov > > > wrote: > > > > > > Greetings. > > > > > > it's unclear to me how is the shared secret g^xy calculated for groups > > > in https://tools.ietf.org/html/rfc7919 . > > > > > > If you recall, the TLS 1.1 uses this method the > > > https://tools.ietf.org/html/rfc4346#section-8.1.2 , causing some > > > interoperability problems that are hard to fix. > > > > > > The RFC 7919 doesn't specify what to do here. > > > > > > So, the question is, assuming that ffdhe2048 is negotiated, > > > > > > - is g^xy padded to 256 bytes (more sound method) or > > > - the leading zero bytes of g^xy must be stripped (legacy method, used > > > for historic reasons)? > > > > > > 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 > From nobody Wed Feb 20 15:48:34 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29407130E66 for ; Wed, 20 Feb 2019 15:48:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 IyYH_zbfiDxN for ; Wed, 20 Feb 2019 15:48:30 -0800 (PST) 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 E26A0130E58 for ; Wed, 20 Feb 2019 15:48:29 -0800 (PST) Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx65.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1gwbbH-0003nv-79 for tls@ietf.org; Thu, 21 Feb 2019 00:48:28 +0100 Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1gwbbA-0006WW-JF for tls@ietf.org; Wed, 20 Feb 2019 18:48:24 -0500 Received: (qmail 7436 invoked from network); 20 Feb 2019 23:48:17 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[208.54.5.227]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 20 Feb 2019 23:48:17 -0000 To: tls@ietf.org References: <155060540091.20709.12797700493315209480.idtracker@ietfa.amsl.com> <1550634231892.18369@cs.auckland.ac.nz> <1550647276159.53158@cs.auckland.ac.nz> 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: <0e9b3999-0e0a-d3e0-e9e3-a6c691fa37d1@huitema.net> Date: Wed, 20 Feb 2019 15:48:18 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------FD19DF617787F60F724517B9" Content-Language: en-US X-Originating-IP: 168.144.250.232 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.32) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5tGFSqEhg7bj9jF01s/oDtV602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO5IcVwV4jjVcAOtIXxgohGFVMZsRZacTbJPGp/MBC6BxbdrUP2dRNvMGcInFEqRIMkh5 mNm/WjPqhYqCeBiCKwzwNnO0oYiZjOnC1Xa7kCO2cFBJ33PyTEulbj2AjstEIPvRa7MR4hgRIg8N 1QlY4G7x1YBTEs55LirRLgpsvCFt8i77Wu2Jb/TI0CxS53moc/SlgXpNwUDmiieE9G+9VqfZ1kay mqFCHRp6u+mIhIXg5jssJAnfERZ2C5vj1sOdsnQOD0r6/AaHZiEtdTMtMljoSvSqrGwueTSCQFid cy15jQ4HwbF4aWaRl0axA525ouWBOXp8nHKe0R+FkIqN7hkgzj0zEmu34GPXR572RNl5VgW9/bkt U41htiJ8fk7NkHmplbyYh4+w03es32OzjfSo5Jhwk+hMTKYppuA2BaWeipTPWMHGUquOFNpW9R6n Md9TLrF9l3ItGfA/WrnALV71dGJ7HPnOCWRaxVuHANylPwUimsNGvJJilSn4u6QSZC6DVgRB+0A7 4t0wvmvPOhIs95DGoDQyh90npG6wuAU16Y3oZJdQ0WXQEIKhyt8GANo5bn0tFTz4SVUdCy2MVE6+ P+NMWgh0hdHFCOgNkMJ392PNDpgLsd6Ddd/s7VM53uY0TTxj2gGBZlqXYSmNS2/AMgFPp7+h3kLe NmBV53UG2C90E9ynzQCrR2g2RwPVA7rOQSTng8OBaitK4BXGFIxRXxKF5tPxTxfD0dMN+t5ZP6zO upSxHMPsAHfGhZAC/ELfT40IeeXtXsko+FU3ueL7G3ch6MdB0XuALpEgtIRS9gE9qVUwhDs/Gbvv EKtxst40eTXlWiUAYdLmsJdAoPJHNvQfAjIDptXbNSradnS0Zqm0mOdPl1LeUTNmkYtBTuxv0/1e /nzlq13wYTxncOSJHdsd+cwIgRT6euCWiMrA+4FHNKsiy9wMVtQ6ai8zTQ== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-belyavskiy-fakesni-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 23:48:32 -0000 This is a multi-part message in MIME format. --------------FD19DF617787F60F724517B9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2/20/2019 3:06 AM, Dmitry Belyavsky wrote: > > > On Wed, Feb 20, 2019 at 10:35 AM Dmitry Belyavsky > wrote: > > > > On Wed, Feb 20, 2019 at 10:21 AM Peter Gutmann > > wrot= e: > > Dmitry Belyavsky > writes: > > >Fake SNI is delivered out-of-band for the handshake > > But then won't the DPI check the out-of-band source as well?=C2= =A0 > If you've got a > MITM sitting there then they can do the same lookups and > whatnot that the > client does, unless you're relying on the client being > off-path, which seems a > bit of a leap.=C2=A0 You'd need to implement it via some sort o= f > subliminal > signalling mechanism that the DPI can't detect. > > =C2=A0 > In fact if DPI begins to poll domains whether FakeSNI record is > present, > we have a race between changing the value in FakeSNI and DPI pollin= g.=C2=A0 > And DoH/DoT ensures that DPI has to poll. > > > Let me clarify. I understand that the solution I propose is not perfect= =2E=C2=A0 > But there is no silver bullet, and this is just another way to make a > life of DPI harder. Out of all the requirements listed in the encryption requirements draft, the requirement to "not stand out" is probably the hardest to comply with. The current ESNI draft works but usage of ESNI can still be detected. As Dmitri points out, there are locales where standing out will enable censorship. So, what to do? Well, if we want to not stand out yet carry some information, that's pretty much the definition of a hidden channel. Would it be possible to engineer a hidden channel in the TLS 1.3 Hello? I bet that's quite doable. I am sure that fields like "opaque Random[32]" or "opaque legacy_session_id<0..32>" could be used creatively, and there are other fields in common extensions that could also be of service. Of course, "could be done" does not mean that the IETF will want to standardize it. -- Christian Huitema --------------FD19DF617787F60F724517B9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 2/20/2019 3:06 AM, Dmitry Belyavsky wrote:


On Wed, Feb 20, 2019 at 10:35 AM Dmitry Belyavsky <beldmit@gmail.com> wrote:


On Wed, Feb 20, 2019 at 10:21 AM Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
Dmitry Belyavsky <beldmit@gmail.com> writes:

>Fake SNI is delivered out-of-band for the handshake

But then won't the DPI check the out-of-band source as well?  If you've got a
MITM sitting there then they can do the same lookups and whatnot that the
client does, unless you're relying on the client being off-path, which seems a
bit of a leap.  You'd need to implement it via some sort of subliminal
signalling mechanism that the DPI can't detect.

 
In fact if DPI begins to poll domains whether FakeSNI record is present,
we have a race between changing the value in FakeSNI and DPI polling. 
And DoH/DoT ensures that DPI has to poll.


Let me clarify. I understand that the solution I propose is not perfect. 
But there is no silver bullet, and this is just another way to make a life of DPI harder.


Out of all the requirements listed in the encryption requirements draft, the requirement to "not stand out" is probably the hardest to comply with. The current ESNI draft works but usage of ESNI can still be detected. As Dmitri points out, there are locales where standing out will enable censorship. So, what to do? Well, if we want to not stand out yet carry some information, that's pretty much the definition of a hidden channel.

Would it be possible to engineer a hidden channel in the TLS 1.3 Hello? I bet that's quite doable. I am sure that fields like "opaque Random[32]" or "opaque legacy_session_id<0..32>" could be used creatively, and there are other fields in common extensions that could also be of service. Of course, "could be done" does not mean that the IETF will want to standardize it.

-- Christian Huitema


--------------FD19DF617787F60F724517B9-- From nobody Wed Feb 20 15:51: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 48A77130E2F for ; Wed, 20 Feb 2019 15:51:15 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHk__eGtOMXM for ; Wed, 20 Feb 2019 15:51:13 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E3C71274D0 for ; Wed, 20 Feb 2019 15:51:13 -0800 (PST) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x1KNhFbC011555; Wed, 20 Feb 2019 23:51:08 GMT 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=Hhlc4/JjlVBfjJB+KfH+B8Hw+TgY4ZNLSXGhEQnTjOQ=; b=N97B38a02bVi57uwKYUajVSseHbxE9InLkxr/iB32fd2tviBm2+lIOlFIrOs6g49zv56 x3Qv0vpOLBXBWit1yMjp0pTRnmEkH/fUdh5Gj604gLh0dzjjWxMiWsJaHOUy1pllcCGV qBXKkDnCHvhQzg0qpn7DjR+noTxH8z3ORKknuaFYYmd7erMqKOcEYI/5M3NQWfvpC9p9 mrs2xfeIDjK8nL2e88DSkgCc3YqNIRuIZLglmAkMFKULrG5avUozuvyxQ3B7ZLtnwIvU UzVt9xppNWrNwvp9sgzCznX6ClPsxPTCPAJMuxiPPk8i40bYMH6ECM/yJKbF/0R453Ix Vw== Received: from prod-mail-ppoint4 (a96-6-114-87.deploy.static.akamaitechnologies.com [96.6.114.87] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2qs8ntt28q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 20 Feb 2019 23:51:07 +0000 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x1KNlilr006189; Wed, 20 Feb 2019 18:51:07 -0500 Received: from email.msg.corp.akamai.com ([172.27.25.31]) by prod-mail-ppoint4.akamai.com with ESMTP id 2qper4p3qa-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 20 Feb 2019 18:51:07 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.27.107) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 20 Feb 2019 15:51:06 -0800 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.1395.000; Wed, 20 Feb 2019 17:51:06 -0600 From: "Salz, Rich" To: Christian Huitema , "tls@ietf.org" Thread-Topic: [TLS] Fwd: New Version Notification for draft-belyavskiy-fakesni-00.txt Thread-Index: AQHUyXbSqsJ37V5YDEGnmTcAERAkdKXpbB0A Date: Wed, 20 Feb 2019 23:51:05 +0000 Message-ID: References: <155060540091.20709.12797700493315209480.idtracker@ietfa.amsl.com> <1550634231892.18369@cs.auckland.ac.nz> <1550647276159.53158@cs.auckland.ac.nz> <0e9b3999-0e0a-d3e0-e9e3-a6c691fa37d1@huitema.net> In-Reply-To: <0e9b3999-0e0a-d3e0-e9e3-a6c691fa37d1@huitema.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.0.190211 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.43.124] Content-Type: multipart/alternative; boundary="_000_A262AF2284444480BA6B5C4F8A23F1C3akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-20_19:, , 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=706 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902200160 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-20_19:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=710 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902200160 Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-belyavskiy-fakesni-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 23:51:15 -0000 --_000_A262AF2284444480BA6B5C4F8A23F1C3akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXTigJlzIGFuIGFybXMgcmFjZSwgcHJpdmFjeSBhZ2FpbnN0IGluc3BlY3Rpb24vYmxvY2tpbmcu ICBUaGVyZeKAmXMgbm8gd2F5IHRvIGF2b2lkIGl0LiBJRVRGIHNwZWNzIGJlaW5nIG9wZW4gZG9j dW1lbnRzIGZyZWVseSBhdmFpbGFibGUgbWFrZSB0aGUg4oCcZ29vZCBndXlz4oCdIGpvYiBhIGxp dHRsZSBoYXJkZXIsIG1heWJlLiA6KQ0K --_000_A262AF2284444480BA6B5C4F8A23F1C3akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: 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 bWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkl04oCZcyBhbiBhcm1zIHJhY2UsIHByaXZhY3kgYWdhaW5zdCBpbnNwZWN0aW9u L2Jsb2NraW5nLiZuYnNwOyBUaGVyZeKAmXMgbm8gd2F5IHRvIGF2b2lkIGl0LiBJRVRGIHNwZWNz IGJlaW5nIG9wZW4gZG9jdW1lbnRzIGZyZWVseSBhdmFpbGFibGUgbWFrZSB0aGUg4oCcZ29vZCBn dXlz4oCdIGpvYiBhIGxpdHRsZSBoYXJkZXIsIG1heWJlLiA6KTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_A262AF2284444480BA6B5C4F8A23F1C3akamaicom_-- From nobody Wed Feb 20 15:51: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 989F1130F29 for ; Wed, 20 Feb 2019 15:51:41 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDU1FuGFiPcj for ; Wed, 20 Feb 2019 15:51:39 -0800 (PST) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7525130EC1 for ; Wed, 20 Feb 2019 15:51:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1550706698; x=1582242698; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=P1xIkw4m8u+5ybo1+26+pojQN0VlPwWql72qjRDgZNw=; b=haTgnhJU8B09auwWreOvcm+3CKg8Vujh7ui+k/ASjNJLjbOhbGYznAxl 4jKTUcHxokc6Etz6QqoLRnYiZ36Fs4mdheHhBjZteFY6BHUnMl09xRVb8 06z9jl/4kBbwjdN3gFJSQMHXR30WXvVUg6eDKa2XLnlT6f788qYgw5ZnV qxkIbTkIVZ4etsCO5+tt4gkG4xskpprKvnBSWhDQ8YVyQ04h6sBtM0ce2 o8OaLjwLJfjeKv91OpxZfHANGwrVlkTnVjOCtK7/2b036LzYDTtHRob+4 zJH3NERPbi1ZmVXv1albev+0Kw3AHRPtzU6i4CipWv89Uu+nDUIMqNIHF g==; X-IronPort-AV: E=Sophos;i="5.58,392,1544439600"; d="scan'208";a="49074032" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.3 - Outgoing - Outgoing Received: from uxcn13-ogg-b.uoa.auckland.ac.nz ([10.6.2.3]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 21 Feb 2019 12:51:35 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-b.UoA.auckland.ac.nz (10.6.2.3) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 21 Feb 2019 12:51:35 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Thu, 21 Feb 2019 12:51:35 +1300 From: Peter Gutmann To: Christian Huitema , "tls@ietf.org" Thread-Topic: [TLS] Fwd: New Version Notification for draft-belyavskiy-fakesni-00.txt Thread-Index: AQHUyI5pabpF922zn0mI1OlKDvKL0qXoC8MR//9dbACAAN8eh///KmIAgAA64wCAANTlAIAA2qcM Date: Wed, 20 Feb 2019 23:51:34 +0000 Message-ID: <1550706689085.90498@cs.auckland.ac.nz> References: <155060540091.20709.12797700493315209480.idtracker@ietfa.amsl.com> <1550634231892.18369@cs.auckland.ac.nz> <1550647276159.53158@cs.auckland.ac.nz> , <0e9b3999-0e0a-d3e0-e9e3-a6c691fa37d1@huitema.net> In-Reply-To: <0e9b3999-0e0a-d3e0-e9e3-a6c691fa37d1@huitema.net> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-belyavskiy-fakesni-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 23:51:46 -0000 Christian Huitema writes:=0A= =0A= >Would it be possible to engineer a hidden channel in the TLS 1.3 Hello? I = bet=0A= >that's quite doable. I am sure that fields like "opaque Random[32]" or "op= aque=0A= >legacy_session_id<0..32>" could be used creatively, and there are other fi= elds=0A= >in common extensions that could also be of service.=0A= =0A= I'd thought about that too, thus my comment about subliminal signalling, th= e=0A= problem is that if you've got a standardised subliminal message than it's n= ot=0A= really a subliminal message any more.=0A= =0A= Peter.=0A= From nobody Wed Feb 20 16:17: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 4D1B9130E66 for ; Wed, 20 Feb 2019 16:17:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Vn2GQkZpyGt for ; Wed, 20 Feb 2019 16:16:59 -0800 (PST) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62282130E2F for ; Wed, 20 Feb 2019 16:16:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1550708218; x=1582244218; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=NV68xFuwOZqkdPpK3N7CStiitEIqTYnWGeQesxqYP00=; b=fp2glCjS9eTKkVkw+dDhj+zcVumpt/2rD9QIjSCgQL5w5OKjboO6PZzP R6CQAH/KyxkTRYVpK2I2VPSFxbS6YZp+4mOBuL4DlkiNHrl34oQjyhqom 1F2VofyvAF1kDt8tl7voG/lvXj/3GYoOl4+L446xU9jxTdjFlH44bAYWJ mkeYyLDAIJs1ox3kqdGy/sjthocFWAR+Xxrvz9XVPyfqMeEotKw4DZ9ad hka1Xux/oo645KtwrbpOJ+J1ndyn0JM8JXpEn0hhjpK6TO8JZUfCnX9P3 Wciz5KjnMpCqGSCrb8Phy2niBuu0bz+G7vxe4SXAi3B8NGX+o5Ir6XD9U w==; X-IronPort-AV: E=Sophos;i="5.58,392,1544439600"; d="scan'208";a="49077650" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.4 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-ogg-c.UoA.auckland.ac.nz) ([10.6.2.4]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 21 Feb 2019 13:16:55 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-c.UoA.auckland.ac.nz (10.6.2.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 21 Feb 2019 13:16:55 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Thu, 21 Feb 2019 13:16:55 +1300 From: Peter Gutmann To: Martin Thomson , "tls@ietf.org" Thread-Topic: [TLS] Negotiated Finite Field Diffie-Hellman shared secret calculation Thread-Index: AQHUyWK0JZQEdd0ER0C6pUY5t2vhPaXpYo6X Date: Thu, 21 Feb 2019 00:16:54 +0000 Message-ID: <1550708208818.4475@cs.auckland.ac.nz> References: <6fff39d3-649d-867a-db71-b0faa18185a5@brainhub.org> <797b3723-3257-1b08-6f78-5752922fb7d3@brainhub.org> , In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Negotiated Finite Field Diffie-Hellman shared secret calculation 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, 21 Feb 2019 00:17:00 -0000 Martin Thomson writes:=0A= =0A= >We implement 7919, which includes an option to only accept server shares f= rom=0A= >the 7919 groups. With that option a simple comparison is used to determin= e if=0A= >the group is one from the spec, rejecting all else, but we otherwise just= =0A= >treat the share as normal. =0A= =0A= My code fast-paths known-good primes, for example the RFC 3526 ones, and on= ly=0A= does full checking on unknown ones (that is, it recognises things like the= =0A= 3526 primes in the hello and uses its built-in values for them). I don't d= o=0A= 7919 for the same reason that most other implementations don't, although I'= ve=0A= been thinking about adding the 7919 primes to the known-good set.=0A= =0A= (A side-note about the 3526 values, they've been independently verified=0A= outside of their publication in the RFC, has anyone done this for the 7919= =0A= ones? Not saying they're suspicious, but it'd be good to get independent= =0A= verification that the data values match what's described in the RFC).=0A= =0A= >I'm not aware of anyone seriously using it though, =0A= =0A= That's a weird thing about 7919, throughout the draft process lots of peopl= e=0A= pointed out, again and again, that it wasn't going to work if published in= =0A= that form. So it got published anyway...=0A= =0A= Peter.=0A= From nobody Wed Feb 20 16:40: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 6B94B130F12 for ; Wed, 20 Feb 2019 16:40:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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] 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 DlKgDZfSgnqu for ; Wed, 20 Feb 2019 16:40:02 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18AEF130F39 for ; Wed, 20 Feb 2019 16:40:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1D748BE3E; Thu, 21 Feb 2019 00:39:59 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRZi8fNYRJ3v; Thu, 21 Feb 2019 00:39:57 +0000 (GMT) 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 4CA4BBE39; Thu, 21 Feb 2019 00:39:57 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1550709597; bh=1aRTb33nCOLkJoKiYM86gfdGhvthsWmVTeYeCKXDhXA=; h=To:References:From:Subject:Date:In-Reply-To:From; b=38q6gb2QRwhsTLznC/134LGJuBGHZIh7YldKOGmzFzf/GG5uY0OllQ5oiYCiJ4m6g nqImL/VDZk8xJGqq6O6ufMc4ngcrN03eLK+0ndDCdZi0FCtxD4Fyp/YkLI9fKIJen0 d1zxHO8T+M3DTOsUdr7MwSONzLf8Aa26Iv2TevgA= To: Christian Huitema , tls@ietf.org References: <155060540091.20709.12797700493315209480.idtracker@ietfa.amsl.com> <1550634231892.18369@cs.auckland.ac.nz> <1550647276159.53158@cs.auckland.ac.nz> <0e9b3999-0e0a-d3e0-e9e3-a6c691fa37d1@huitema.net> 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: <7519be36-2cb1-af8e-a313-a8ae9e799c70@cs.tcd.ie> Date: Thu, 21 Feb 2019 00:39:56 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <0e9b3999-0e0a-d3e0-e9e3-a6c691fa37d1@huitema.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="au1RPrfKu3u3Sz0HNEBR5BgmFo88dS8CF" Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-belyavskiy-fakesni-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2019 00:40:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --au1RPrfKu3u3Sz0HNEBR5BgmFo88dS8CF Content-Type: multipart/mixed; boundary="2qcAwu8TYUClEBj25Ns0cXlQ0btXhMLMJ"; protected-headers="v1" From: Stephen Farrell To: Christian Huitema , tls@ietf.org Message-ID: <7519be36-2cb1-af8e-a313-a8ae9e799c70@cs.tcd.ie> Subject: Re: [TLS] Fwd: New Version Notification for draft-belyavskiy-fakesni-00.txt References: <155060540091.20709.12797700493315209480.idtracker@ietfa.amsl.com> <1550634231892.18369@cs.auckland.ac.nz> <1550647276159.53158@cs.auckland.ac.nz> <0e9b3999-0e0a-d3e0-e9e3-a6c691fa37d1@huitema.net> In-Reply-To: <0e9b3999-0e0a-d3e0-e9e3-a6c691fa37d1@huitema.net> --2qcAwu8TYUClEBj25Ns0cXlQ0btXhMLMJ Content-Type: multipart/mixed; boundary="------------8BB36DB56CF7E47A1422BAAC" Content-Language: en-GB This is a multi-part message in MIME format. --------------8BB36DB56CF7E47A1422BAAC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 20/02/2019 23:48, Christian Huitema wrote: >=20 > Out of all the requirements listed in the encryption requirements draft= , > the requirement to "not stand out" is probably the hardest to comply > with.=20 Yep. I think it'd be worthwhile spending a bit of time to see if we could do better on that based on the esni -02 draft and how we guess that'll evolve. The ESNI greasing PR would help here as it'd mean plenty of ESNI extensions in ClientHello's if people really did grease in sufficient numbers. If that got to the level where blocking all ESNI wasn't feasible, then maybe that's good enough. But there is something attractive about a stealthy-ESNI scheme so maybe it's worth spending a bit of time trying to see if we can find one. I'd be up for taking a shot at that in Prague if any other interested folks'll be there, are familiar enough with esni-02 and it's PRs and would like to give it a shot over a beer. (Just informally, it's a bit of a stretch-goal I figure, so not worth getting excited about for now - anyway ping me offlist if you'll be there and would be interested and I'll suggest a time/place for a stealthy beer & chat.) > The current ESNI draft works but usage of ESNI can still be > detected. As Dmitri points out, there are locales where standing out > will enable censorship. So, what to do? Well, if we want to not stand > out yet carry some information, that's pretty much the definition of a > hidden channel. >=20 > Would it be possible to engineer a hidden channel in the TLS 1.3 Hello?= > I bet that's quite doable. I am sure that fields like "opaque > Random[32]" or "opaque legacy_session_id<0..32>" could be used > creatively, and there are other fields in common extensions that could > also be of service. Of course, "could be done" does not mean that the > IETF will want to standardize it. Right. And even if the IETF did want to standardise something, that doesn't mean people would implement nor deploy. It's a hard problem. Dave Plonka and I were chatting over beer recently and came up with the idea below that we raised offlist with a few folks who're interested in ESNI. It got a "mixed" response is the best I could claim, where "mixed" varied from some enthusiasm from one person to a very clear "no, don't like/want that" from another but with silence in-between (the silence being the real killer;-) But maybe if we get a few folks and beers together a better analysis will emerge... Cheers, S. The idea is an extension to the ESNI scheme that can work in some cases, is more bandwidth efficient and is stealthier in that one cannot tell just from passively watching one TLS h/s that ESNI is in use. Unless all the conditions required below are met, ESNI works according to the (evolution of the) -02 draft. (I.e. if you can, then do this, if not, use the approach that's in -02 or whatever that turns into.) The TLS client needs to have a working IPv6 address. The TLS server needs to be contactable on any address that matches its /64 prefix. The TLS server probably needs to sort of randomly change the AAAA it publishes in a yet to be determined manner. That might be like an IPv6 privacy address or might have to be a new flavour of server privacy address. ESNI calls for a key share to be published in the DNS below the name of the TLS server. Let's call that public key share g^D. (Even if using ECC, I find it easier to think in terms of multiplicative groups;-) This is the same as the -02 draft. Similarly, let's use g^A for the client key share in the ClientHello and g^B for the server's equivalent share. Assume that all public shares are from the same group, so g^AD makes just as much sense as g^AB. (We'd need to mandate that the client MUST first pick the group for g^A ignoring what's possible based on ESNIKeys as we don't want the ESNI tail wagging the TLS1.3 dog.) We add another (optional) field to the ESNIKeys RR value that contains an IPv6 /64 prefix for the TLS server. And perhaps a flag that says that clobbering the low-order 64 bits of the IPv6 address is ok, i.e. a flag that says a client can use this trick instead of the (evolution of) the -02 scheme. The idea is to use g^AD and the TLS ClientHello random number to encrypt (a truncated hash of) the name that would otherwise be sent as an SNI value. That encryption has to produce a 64-bit output. The output of the encryption is used as the IID of the IPv6 address used to contact the server. So something like: Z =3D g^AD K =3D KDF(Z,client-random) IID =3D E64(K,H64(servername)) H64 could be a simple truncated SHA-256. E64 could be 3-DES in ECB mode:-) Instead of a client-chosen random challenge (as per the -02 draft), in this case the EncryptedExtensions returned by the server contains the full (non-truncated) hash of the servername. Some notes on the above: - layering, smayering:-) - yes, this is IPv6-only which puts off at least some implementers - yes, the server needs to know the hashed SNI ahead of getting the first flight from the client for this scheme to be workable - yes, not all wildcard cert scenarios might work with this (but some would) - if it's ok for the EncryptedExtensions ESNI value to be fixed per hidden server (as proposed above) then that maybe makes the split-server mode much easier and more realistic, but... - the above may be vulnerable to some attacks from which the -02 version doesn't suffer (e.g. that allow an attacker to confirm that a client's CH is for some hidden service if the bad actor has guessed the right server already) - pondering such needs more work --------------8BB36DB56CF7E47A1422BAAC 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 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5tDJTdGVwaGVuIEZhcnJlbGwgKDIwMTcp IDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJCZQmAAUL CQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1yw aps8HGUNhLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG +48od+Xn7qg6LT7GrHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXk kTFaSGYJj3yIP4R6IgwBYGMzDXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRr pZtXB1XQc23ZZmrlTkl2HaThL6w3YKdiTi1NbuMeOxZqtXcUshII45sANm4HuWNT iRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS3MmGgVS4ZoX8+VaPGpXdQVFy BMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml3OEuIQiP2ehRt/HV LMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi2/Jrsz6M zh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6 TzKjGjruq8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxIkBHAQQAQgABgUCWj1SoAAK CRAvPIc2gF+NovMcCACVZPo1cQa3D+vWaIo0ZyinO/MgtD2gHysoj1T0Qvq05//L ZXmhh578bJANvdl2g/HFhhwl/5HKIfWcyipQhmJklp/dsleKcNnn4B18T75RHY0G +po3ILq7evbiOjUH+xqApti1aCxi1GocsPghaLfsxmtXKMG4Xu7XhDTv66GOrqZf Y7+0ekJjD9Dza1t5NE/JR/VZA4B8PWR8Glb0+8C9rkjD0VZ5ekJdHPDGcJmFh8Z+ q25LDoI8Fgt1uKSowvoVnsQO5MFv/y6bXArtj1uB4hAL4JiOFgHlFdrW0MlFpvYm ziW4K9JHTD8KAfDbrb3e2W97ZDpROuYfE/lTbYOWiQI9BBMBCAAnBQJaPVAyAhsD BQkJlCYABQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEFqy+vF7Fyvq0mkP/ius gsf6Z4/Tu+vHzBbl5i6oKI8ZieH8JfEgXx4ut9t7l3hBGC2r7DpR5A8zLMpEhGIK gFcHagksFkfLEE/FmWDfd1MysQafxBYrHaI27P2tkxfI5JYV6247TV39pQ93kGds tsjIrmh/zEJCVczoofxtz72BDt51H2Z8tN28F/YVHnbaGDwFEEzWKYpze87y/f36 ogcdGO6LDEEEIA6Ee0dGxleuKlLS4UDTt0zjo6L8TyiyPHp9C3+UfnP8837Zp3Fh KstIBd+vWgPdHFg2G5aDIYUvrj9UJBvVgaN/RnkwE+dab2OBSg5jkr141JLQvzdZ 4mOUXn5D9Y6AH6tvj0+ubYMV6j35L1/ZXncuXPVYiylcmDp/6f2WYcT3gx9CPUYA cLMjQV4vX2W8z4uEPyMlIJuGsLf7KhvLL8BQ6zlncT6eONfUUX9UJUCzqI5rqL5c b5jWGHeKvbLWRyQnlq5PXQxJTwYRm71rJTgzejc33LE6Nqg/Q25Dgwwsv+f+7i73 gB5loc80Fef+FV9VFGalFe0Yq8m0UASmkYRh7MH5ssoibpeWk+SGfBjOV4tnsAwR yjYLpAzxA8HeDcmlLeypGEDmsQ/iUvXoGaKOYX4Ieg8T/PCAplsqnJUOq8hbkgOC 98gLZfiltkNG8YhQpoZIHj6SxmBRSc3K99CvanuOiQIzBBABCAAdFiEEfhcKBFyE z0YOK3mgEO952f2DUxIFAlu3JJsACgkQEO952f2DUxJ4qRAAmbjiO3WTAeBCB4ME p2N2+XQCMTTFURDGuJnqU/+X//fhhPRq4V/OxgisKFKlBcAS2hsECvg6HDVSz4Fl 74fk/y+botG4/CjMLdKPB9fgh5zz72i3q0hWDixt50NKBv8IIVWOyYgZxDU/vcks lMEnqbFgJX+CfdALpvAM4WjuQP0UMcKNE3xd+EdDhD1xjK3Tq4XfWob9q6aBZgL2 B4IaADCIeDDE1hv0agnSJmMJE7Bti8tNxCCxVRbZtOaxVHXdRUoOx2XTaxFXupxV hbpHRrdFrwq51f6e3bkfkNEZ3fzYpnlbynJ2zL++JO8P3Pq/S6UKEFjEB50i8YgK WuFvGUsQ+YiDgiZU4saqxSBWbfYn3lY6MSSTg8RnXbFIMG3CFImqYk1uhaV+bDjc p0htjzM2F98g7c3o7sWx0bGarId4uhOmpj7JJVQ+lu7Jby6Ocj8n//7qF1Nn11Cw QlCVaeAq5Y5DmZrnww9I3zzOWWyqFkAVCM3GqeRLMvplD6/+O+5FF7XoHzQB47nk OyZtawy/9gssPWZKLv4qHLYS0wGGCiNbCsYy90s3pfeafM0kSxxjIvEz21KT6LJI /awu2ErQFWCkDMFJ1p/97MjPrQ/6d4cPO140V/wyfuWaBiTVqa9mgnb2zn6fYfDH JEvl1UzIx3JCae25tty1+qtnS0i0LlN0ZXBoZW4gRmFycmVsbCA8c3RlcGhlbkB0 b2xlcmFudG5ldHdvcmtzLmNvbT6JAj0EEwEIACcFAlo9UVoCGwMFCQmUJgAFCwkI BwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+o7HBAAxHAdFkBGZ9gJK8w7 NUYS9C6enGYtAYoKH5G3Bn3YScjErNfQtHYb53KwBQpVSOv1HcN8hbQ8mLTgn9lt zNwNSuv0XxIswi807HRSIZ4vYDiS5VKV1YkLYK5bLY5O4alVdzqM+AZQqkuHBu63 6n+C0ED6UwLhVBFfSNvBQVAdoq6gvr+IE8rCIKTMNGwNcgVPbF+YxP7UZM6p7s2a 5MIqGw7URSfaqfuztibXGOBLFbSwLGqHSSnOXBfEeDrwdZ+ur8cXIIPRIeCTVmeO 8bGgpgBqNQXG9oyGN+TrYAC+4Ahi0UjCk7QGj8tf3xICKoQpYyfceNBZJ/969gV9 tVgvRxUjxUwc9kZbi0c8XYMTq5GCvBIh1D6BOW9QBM2SsNgG3l36+e3+c2LDdyKn 20C1IzGLVDdcCtz42/onQ/e9sMlzFrfLjs5SO2/TnLvp2JtsIQXyb/T5qd0GE5j8 /iwfZR+uVTVVEsUl1a+Yllzt6sdR7RIhhKpKaKzEAk4d0+VHdz7zEkQRRSjbPVoS fy8c/kld9Fi8Buna+ZkKpcwIW+D4XP83pGcl0XUv6AyqwS1LnEt+jv/+PSXskYtU Lzn8Z35iKkSAH/5Nz6GCZk6ORPNv/6+UI92BpUbu/G2tBwK8bPgAg+gJxBx3G7MK W7VRCmM5UrtAK9A3O70VjPyMkHSJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLC LAf/X/9vRTZWtwSXxiBCA54a6hg9IvW0mvPUqgXfvrhtOk0IFucLKrTXK8J/NcmU 6ulxOovVbQ+Bin6gtHeCmSa/W523g/NXCOuFTnS/MyVibNL4+RCFwqGysl++Cm+L nj1MmasE9kO+CNdervx8APfxV7D6OYrG4eGag+LdFR6VpJn6tRT0/WvyT8l+Oqiq gdhXHv+0MvkkD9TX5LlJW4VB/yRvWkkmL5N5c5zYh+NcfTPhQ5S9dOorVzrm65d6 Itn0937Ennau7s7fiFdA0BHjWqEAFLsBIXQfCFjjKjdsKA4xlSiX7X7ElmPYpWa5 wwTQ66dL0anMd9y1DJCMOHe4gYkCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9 g1MSBQJbtyScAAoJEBDvedn9g1MSY7sP+gKR0rFU1g+GtB+hSdtwPRbacvml2eL2 Jc5Eq37J9hAqxHyt5V0If7s8IyVA2GXgdfwULBWbXGDUDiUkh20OPQRUS8G9Sf8A WRuG25q5C8ZzWygykL88RKXJZDFtA49CeqO5Bq5syBhq4QfiSTffQHIp3h0boPGU hSBEUQpooMXYQClNARQ+z/uRzR5bUi9wxdXNnxTn9ia4ASlaBPvUYTGY1jW2HrRR SwpI12+UaWsvc3jJtQ8X0kxgJ7jsFF1uqquIZ5eflQv+PHHg2RJSy37u0UFGb+OK ZEkzlmbPokKCYhzBR5PcD6sgdlaJNcidmto9u1oV6yZT8J2W4CTuUclgxt6f3lZq ZeVLnNnbHyKUdeypwLlqYISulfnMhZ3A6Bgpf2BtjL6KJbFtPBYmYdxI+HZyY49u U2ZHhRu+CSQ1y7zGKSX0gRp5hE7+A4XJtsT6lTLhbi9aiZTG1S6zKNhl3qNNzszc r27PrvFiyGhpuYQuzdQl2PMGbOI6Ojif3sab53NO3RLsLOM09wIlr95yKLlkXkUr WcvUJGrw6HKm8j5opXHTwmJOAbDpc6cMDu+ITRu4spdCnQJcE8RkO8tKyaLuh2Gt U5kYSBK97yr5VviX1FK6rY14LLmnE16OPiK2tiVBKy9nGM0DKtY+K9WcoRZ7s/d7 O0bMfzcNPtGLuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiez GPuBHmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9Wf pHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC 6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2 D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFe A7PbTuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ /Vf3vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbpt PEcmoazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKr em5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96 Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYgh x8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQ oqj1gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P /1tF6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8 Wpfdn3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJ gx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5 SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2 oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIA ypqYo3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoM eDQkd0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS /qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZ IMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XO KVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DJ121 -----END PGP PUBLIC KEY BLOCK----- --------------8BB36DB56CF7E47A1422BAAC-- --2qcAwu8TYUClEBj25Ns0cXlQ0btXhMLMJ-- --au1RPrfKu3u3Sz0HNEBR5BgmFo88dS8CF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlxt81wACgkQWrL68XsX K+oxxA/9E2xiliSpc7yNfDEu5I3jfQ9avXHPrJ/K73zrjlygnjcBkx3uDcVB7UCA q5wl9qFXJwrdIv3D5FeOKWKqw82z3IRgomd7xfTe3wLhd4bZDl+qz78VjaDIf0Os l6zZvlxgpW0Pa+H47HDsp4IQvsOftA1egJAle6rHo529sgOlVOG4Q4mlvHY9TzKY kmeGLLCStRbl9aUdunBOPRBPq6DV13MHjm3xX07SPfmUOBobzyEpXZbCZTBm/6fH mlzQcOjra1xw+2o9oG7pYsHxI+4AcLY2lt8xnjjnaR8uReuQ1egnl5bQpLX1Lhr9 461J7xfsrjkBpqtGjJXmuS8YggshAHKm8N2CyzdjeHkIzJNwMxX17dCwgigzgSUz xogMf8ZB9XQ4z+FKft5cmCtb8nXQQThl2TdaypWJm8yScKYiA4+NGjrapuyI979p YhkkaZ3qJ+1p7bhibYplQfooR+jTmaBEjCdtcMYw46CoCA0BB2oi6u/SHx1f6OcX x4uiodggk3Pb/PeqACyCpOe9y4OuOVkXK1Yr3kn/ldvlUrT230VUxIL5unhU4VKt B+FwbRfTj1BPloh6jLLMbrpa+30xOkgfCIrygOpOngtVw3ORbtPK8IaZ3fP85Ppq Hmi8/WOP0WGhowr3hbQ5az1glIYvmM1Opc77eKWdFZPYWgCesoM= =x50Z -----END PGP SIGNATURE----- --au1RPrfKu3u3Sz0HNEBR5BgmFo88dS8CF-- From nobody Thu Feb 21 20:49: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 CFF051292F1 for ; Thu, 21 Feb 2019 20:49:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=V88fAh0C; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=1N7o9H7q Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnAJrrgCXN4o for ; Thu, 21 Feb 2019 20:49:03 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 051961286D8 for ; Thu, 21 Feb 2019 20:49:03 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1550810942; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=MIeu8ghERgIvVgshO3kAXcUS2NjOueXT+A8C3BT8SFs=; b=V88fAh0CCI2HD9GRDpUw6LKoQ84O2C/8AC/7TsMtz+76xP8IJd2pM7jV SzlG301fYftZ2RlTSd4DqaMPJlX3AA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1550810942; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=MIeu8ghERgIvVgshO3kAXcUS2NjOueXT+A8C3BT8SFs=; b=1N7o9H7qz7VhVSa3gEe5cUwspanbrrTPkVWPDRv8adh92iapI4Q9p1GO G8vcXiB0miCJe6TXqAfLTGI3R4g7O1vUSBInx4gDngc8/ggpqUHT7lnpAQ TYjcrQa3mvH2m3EiAtVeVsRwj5TG4aIdVSbQlj+2LnrDlfijJxTkOMdevR +BIjkOcEka7U5WlsnDogXlRdzuk6j5OL3m1SaA0U2ZlNRr1cMHd48MiJi/ lhyHSQ9oncAiGnKEe2OkrPge812JCIUNNxTL5WqKs8lweoNi0IZCmNdpjA o+54McWA06H49m9floWw+T7kfvCmrfT49lPpefq701CRL6yMd1bwHw== Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 7365BF99F; Thu, 21 Feb 2019 23:49:00 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 8C63220553; Thu, 21 Feb 2019 21:17:03 -0500 (EST) From: Daniel Kahn Gillmor To: Peter Gutmann , Martin Thomson , "tls\@ietf.org" In-Reply-To: <1550708208818.4475@cs.auckland.ac.nz> References: <6fff39d3-649d-867a-db71-b0faa18185a5@brainhub.org> <797b3723-3257-1b08-6f78-5752922fb7d3@brainhub.org> <1550708208818.4475@cs.auckland.ac.nz> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Thu, 21 Feb 2019 21:17:02 -0500 Message-ID: <87mumor2ht.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [TLS] Negotiated Finite Field Diffie-Hellman shared secret calculation 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, 22 Feb 2019 04:49:05 -0000 --=-=-= Content-Type: text/plain On Thu 2019-02-21 00:16:54 +0000, Peter Gutmann wrote: > (A side-note about the 3526 values, they've been independently verified > outside of their publication in the RFC, has anyone done this for the 7919 > ones? Not saying they're suspicious, but it'd be good to get independent > verification that the data values match what's described in the RFC). i'd welcome any additional double-checks. iirc, at the time of publication, Tero Kivinen checked them independently, but i'd welcome any additional checks people want to do. I also published primality proofs (via primo) of the groups here: https://dkg.fifthhorseman.net/ffdhe-primality-proofs/ > That's a weird thing about 7919, throughout the draft process lots of people > pointed out, again and again, that it wasn't going to work if published in > that form. So it got published anyway... i agree that it would have been functionally stronger to define ciphersuite values that identify the use of named FFDHE groups. This would allow clients to signal to servers that they will *only* accept DHE if the server uses the named groups, and would avoid getting DHE handshakes from non-compliant servers. However, the mechanism is still useful as-is for clients that want to signal their preference for a known group to a cooperating server. This is still useful in a world where some clients were failing to accept server-offered DHE shares > 1024-bits (sigh, Java). IIRC, the sense at the time was also that codepoints were scarce resources, and replicating all the _DHE_RSA_ ciphersuites alone would consume another 25 codepoints (replicating all of the _DHE_ ciphersuites would consume 70 additional ones), and then it would also require haggling over how the handshake messages would differ from the standard in those variants, which might then increase implementation complexity. Too bad! At any rate, it turned out to be useful preparation for TLS 1.3, though i presume today the named DHE groups will really only come in handy in case ECDHE turns out to have some kind of serious cryptanalytic setback. --dkg, the guilty party --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXG9bngAKCRB2GBllKa5f +Oe5AP9TU9ZQJMZoaw92z0qFchtfvBWLfMhvfnq3k+8/kuut3gEAtaOwRfRQ09mj m8MAFFKo5Zb3EFX+YItxp4mG2yq0Iw4= =3IU3 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Feb 22 06:41: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 B60AF12D4EA; Fri, 22 Feb 2019 06:41:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-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=comodoca.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQIm55je13va; Fri, 22 Feb 2019 06:41:16 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-eopbgr790072.outbound.protection.outlook.com [40.107.79.72]) (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 BDCC2129A87; Fri, 22 Feb 2019 06:41:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comodoca.onmicrosoft.com; s=selector1-sectigo-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dtdpZt18ulNDdZhdWhYoiozG5U55OdMlKHJHi/8JOWo=; b=Fh1cjUzg8ypfXfdVQjmkdQZjlzohE1N60akw4XX3ZQAJzkOaNnGYmu95wBKWdnhUOHFsrXPCb7JzatbB/cHl2bhY63yiv1KjVmvmyWuw4DSstYhYlDEGxQxgkvl6x6ODzDeAbYDeVNrWpRyfU4OS+sKbb+1vkhsjyFIS3yu7Izc= Received: from DM6PR17MB2716.namprd17.prod.outlook.com (20.178.224.155) by DM6PR17MB2236.namprd17.prod.outlook.com (20.176.92.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.15; Fri, 22 Feb 2019 14:41:12 +0000 Received: from DM6PR17MB2716.namprd17.prod.outlook.com ([fe80::80e1:4c3b:1fac:22b9]) by DM6PR17MB2716.namprd17.prod.outlook.com ([fe80::80e1:4c3b:1fac:22b9%6]) with mapi id 15.20.1643.014; Fri, 22 Feb 2019 14:41:12 +0000 From: Rob Stradling To: Eric Rescorla , Martin Thomson , Trans CC: "" Thread-Topic: [TLS] ct_compliant cached info field Thread-Index: AQHUng4AiTlMjhjKyU+rxTv7bjD+jKWYYcaAgACOqgCAU0y3AA== Date: Fri, 22 Feb 2019 14:41:12 +0000 Message-ID: <1f481215-9a30-dd91-7039-8e2ac5351cbe@sectigo.com> References: <1546236377.2848619.1621803360.25FE2839@webmail.messagingengine.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P265CA0175.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a::19) To DM6PR17MB2716.namprd17.prod.outlook.com (2603:10b6:5:122::27) authentication-results: spf=none (sender IP is ) smtp.mailfrom=rob@sectigo.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2a02:1788:4ff:1000:f68e:38ff:fe7a:a226] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: dc975829-0780-4e6d-36d2-08d698d3ca94 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:DM6PR17MB2236; x-ms-traffictypediagnostic: DM6PR17MB2236: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-forefront-prvs: 09565527D6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(136003)(366004)(396003)(39850400004)(376002)(189003)(199004)(81166006)(53546011)(386003)(6506007)(446003)(102836004)(99286004)(36756003)(71200400001)(31696002)(4326008)(6116002)(46003)(6436002)(305945005)(8936002)(86362001)(106356001)(476003)(68736007)(2616005)(486006)(11346002)(105586002)(186003)(6246003)(31686004)(71190400001)(6306002)(6486002)(6512007)(76176011)(2906002)(53936002)(110136005)(97736004)(7736002)(14444005)(256004)(8676002)(316002)(52116002)(478600001)(966005)(25786009)(81156014)(5660300002)(14454004)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR17MB2236; H:DM6PR17MB2716.namprd17.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: sectigo.com does not designate permitted sender hosts) x-microsoft-exchange-diagnostics: =?utf-8?B?MTtETTZQUjE3TUIyMjM2OzIzOlVMaDR6VkIyVzZ0QTBzdGFYSm0rdnlpcDVk?= =?utf-8?B?K2F0bjBjendvaVY1dG8xcVNMMUJjc3JweEYwZk85azdSY3FDd3dmU1lJMUdY?= =?utf-8?B?K3EyMndHdFdwWVpyTkVBVlBhZHhTWjJBRnRESzZlMTV5RVJ6U1pKd2gzOXhZ?= =?utf-8?B?TDRGUUdORGt2UWFhVy8vTUxpRW5zZ3lPYWZxampDcVNsSmhEV1QyTFBsalRS?= =?utf-8?B?eU5ocmlOUGJibldlRU5tY0JxSnp4RmxrM2J3bldUV1A5cGlyenYya3g3Wm5w?= =?utf-8?B?S01tTm9IVVJRQWJCc0ExQ1l0MG9XL1hndnNNZzFBNlZlMkJIa0MrWWZUbkR5?= =?utf-8?B?VEc1SDFkQWZKVERrTnIzUkswcXdoQnRhY3NLMm1iRzZ6RzlBUW9YWHZESDUv?= =?utf-8?B?ajNTNndmSmcvRkNBN0QzeEppT3c2cE0wVEw1QWl4ZytiQWdGYWl4OGRFdTZo?= =?utf-8?B?YmFjdkxwZExORVY0RWV4WTRsbzgyWFRjS3BWUjBBMHFZM2YvWE4vUWVjM0JD?= =?utf-8?B?ZndaSHlwWlNYVUdjU2xydjRyaTdBVjBBOWlmeEhwZFMrOVZQeEhueUJld1pC?= =?utf-8?B?R05KeFBkVXpucTRVWFRhcFRBT2lnTE5Zak5BcEh0Nk0xS0VHRThLRHVVZDJE?= =?utf-8?B?RXV4ZkFrOUU2SnVCNHV0QmREWGlOUS9OMnlybWkxS0pXTFJ3a2k3U0FoUDVF?= =?utf-8?B?NU5qSFZDWnB5bmNvQmVuMU9ybXIvbXVsSFFtZXVnZTBBQ3JlRHRSL2NPMVpz?= =?utf-8?B?WnBnWFNMcmQ1OCtoWlZKbU5kUTk4ZGJCeFovb29OdnZpR2ZKcW9DQUwrYndG?= =?utf-8?B?dURJME9QdGM0cUYzWHZZam01RnBOSHp5N0ppZmkxVXk1QUNNaDhBSnUyV1RB?= =?utf-8?B?NHdyZG1WeXd1aElBSy85Qk9VRGNyMHpPMkdtUHF0NmpnYUZpaHJENzNRYVFD?= =?utf-8?B?eVVtMTZwWjYxcGtsOXQxT1R5bjQ3WW5HZ2hLa05EK3pLWndXeXZyM3ZibExy?= =?utf-8?B?UllRQjNqKzJQV3dVcHRCaUhxL0pvNStNaUsxaDN2QXA1YUpaNjVkRFR2WkF5?= =?utf-8?B?dWxER0NNZDhMZjA1T0N4Rjc5cVBXN3ZSV1RRUzFvaDFBdGgwTkVVZHZUUmpS?= =?utf-8?B?T0l3cjd6dnkvMWpaU1NHZU1mb0pmdHNNMXdkd1lOWURqWCtsQW9vWHZTcjJu?= =?utf-8?B?cUUrMUJYTzN3b0wvS0M1dnl2TFYrZWN6dVkxdnIxb0t0MHBiZmM3MlU0eDR5?= =?utf-8?B?WEFXcWhKaktDOUExWDBiTDdvZW12cS8vbmUxU2JvTEJYNE0rbldRY2UzOVFN?= =?utf-8?B?dVVNQ3RpcVlVbWRFT0ZXSU9IVERFNDdxV3dJUFd3UGZsM1JGNjNOUlB1RzFm?= =?utf-8?B?ZTc2UEp0RkV6Y25yU0RqNlllR1h0THF0d3plL0N1WnROUFRvSk1ndlFJck9C?= =?utf-8?B?Y1BmVEVlcjZwWWJQMnp4Q1FDNnU4dURERVNTalEwZVVobmRBWVlkMzQ5ck9G?= =?utf-8?B?MERWa1VSWlozOEM3MFJUQXJHTXJ5QXlEQmYrd1NTbEdRYnFvWnl5STRUZHhV?= =?utf-8?B?QjNoTnNBYVk2dmcyNURVeE5GSkRXeUU4d05rcDRyaG9tUUE5TkZ5ZzNUU3dx?= =?utf-8?B?OTVXNnE2UGtJdXhJWXhPTEc0ZklFdEtaZWt1QjNOKzBzbVdlSm9obmcyc1Er?= =?utf-8?Q?DBGSyNxB8cP2ManYElCnpKzMILIxwbUMqbmEmjl?= x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: pM5u8O96LXC9RRUQIZg+g7KeGV8ckREqQvYAr0REs2/TSo3lXTBqSf/uQ+knnOlia9fkJwqBVgU4OvBCoJ/tyjj98TR785v2faR8kV/UGwkuTNar9I4k8fgsnDZ4qSoi4yfraHJPQwXc7qPQaapju1wviB79hp+tY56LqOIgQs1Fx/ahZ4sGouUUAYWAdnqUMdfrAxnAGW/PGSCkmVjnuGUJ+PApx9tbTILhz25sJzh5t9cCNPumDRPZeLBf6RZHVdFszlq2wSi1oq6X4/9JDSxe0jRtz/4Fqu03lOHUpLsF6446I/BdOHK9lSEA3G60DrxMF0Nh9YFThZgrKR8ey1oK2Nwz/dCdAa9aU5AhwK+fpCfXFlv+NQscEwbJSc/eMuAFqyvORFzi7f8PVmcd5/O8mzAe4aCDVpauOUSWBw0= Content-Type: text/plain; charset="utf-8" Content-ID: <47AE95E7F813554DA8AF5141AB2216D6@namprd17.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sectigo.com X-MS-Exchange-CrossTenant-Network-Message-Id: dc975829-0780-4e6d-36d2-08d698d3ca94 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Feb 2019 14:41:10.7124 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-id: 0e9c4894-6caa-465d-9660-4b6968b49fb7 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR17MB2236 Archived-At: Subject: Re: [TLS] ct_compliant cached info field 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, 22 Feb 2019 14:41:19 -0000 RUtSLCBNYXJ0aW4sDQoNCkhpLCBhbmQgc29ycnkgZm9yIHRoZSBsb25nIGRlbGF5IGluIHJlcGx5 aW5nLg0KDQpUaGlzIG9yaWdpbmF0ZWQgaW4gWzFdIGFuZCB3YXMgYWRkZWQgdG8gNjk2Mi1iaXMg aW4gWzJdLiAgVGhlIG1vdGl2YXRpb24gDQp3YXMgdG8gcHJvdmlkZSBhIG1lY2hhbmlzbSB0byBw ZXJtaXQgYSBUTFMgc2VydmVyIHRvIGF2b2lkIHNlbmRpbmcgQ1QgDQphcnRpZmFjdHMgKFNDVHMs IFNUSHMsIGluY2x1c2lvbiBwcm9vZnMpIHRoYXQgaXQga25vd3MgdGhlIFRMUyBjbGllbnQgDQph bHJlYWR5IGhhcyBvciBkb2Vzbid0IG5lZWQsIHRoZXJlYnkgcmVkdWNpbmcgYnl0ZXMgb24gdGhl IHdpcmUgZm9yIA0KY29uc3RyYWluZWQgYW5kIGhpZ2gtdm9sdW1lIGVudmlyb25tZW50cy4NCg0K VGhlIGFwcHJvYWNoIGVudmlzYWdlZCBieSBSRkM3OTI0IHNlZW1zIHRvIGJlOiAiaGVyZSdzIGEg bGlzdCBvZiBUTFMgDQptZXNzYWdlIGZpbmdlcnByaW50cyBJJ3ZlIHJlY2VpdmVkIHByZXZpb3Vz bHk7IHBsZWFzZSBkb24ndCBzZW5kIHRoZXNlIA0KZXhhY3QgbWVzc2FnZXMgdG8gbWUgYWdhaW4i LiAgVGhpcyB3b3JrcyBmb3Igc3RhbmQtYWxvbmUgbWVzc2FnZXMgdGhhdCANCmNvbnRhaW4gb25l IGl0ZW0sIHN1Y2ggYXMgdGhlIHNlcnZlcidzIENlcnRpZmljYXRlIG1lc3NhZ2UgKHdoaWNoIA0K Y29udGFpbnMgMSBzZXJ2ZXIgY2VydGlmaWNhdGUgY2hhaW4pLg0KDQpIb3dldmVyLCBpbiA2OTYy LWJpcydzIGNhc2UsIFNDVHMgYW5kIGluY2x1c2lvbiBwcm9vZnMgYXJlIG5vdCANCnN0YW5kLWFs b25lIGl0ZW1zOyBpbnN0ZWFkLCB0aGV5IGNvcnJlc3BvbmQgdG8gcGFydGljdWxhciBjZXJ0aWZp Y2F0ZXMuIA0KRWFjaCByZWxldmFudCBUTFMgbWVzc2FnZSB3aWxsIGNvbnRhaW4gYSBUcmFuc0l0 ZW1MaXN0LCB3aGljaCB3aWxsIA0KcHJvYmFibHkgY29udGFpbiBhdCBsZWFzdCBhIHNldCBvZiBz ZXZlcmFsIFNDVHM7IGFuZCB3aGlsc3QgZWFjaCBTQ1QgaXMgDQpzdGF0aWMsIHRoZSBzZXQgKGFu ZCB0aGUgb3JkZXIgd2l0aGluIHRoZSBzZXQpIGlzIG5vdC4gIFRoZXJlZm9yZSwgdGhlIA0KYXBw cm9hY2ggb2YgY2FjaGluZyBUTFMgbWVzc2FnZXMgYnkgZmluZ2VycHJpbnQgZGlkbid0IGxvb2sg bGlrZSBpdCANCndvdWxkIHdvcmsgZm9yIHVzLg0KDQpXZSBjb25jbHVkZWQgdGhhdCBpdCB3b3Vs ZCBtYWtlIG1vcmUgc2Vuc2UgZm9yIHRoZSBjbGllbnQgdG8gbWFrZSBhIG1vcmUgDQpoaWdoLWxl dmVsIHN0YXRlbWVudDogImhlcmUncyBhIGxpc3Qgb2YgY2VydGlmaWNhdGUgZmluZ2VycHJpbnRz IHRoYXQgDQpJJ3ZlIHJlY2VpdmVkIHByZXZpb3VzbHkgYW5kIHRoYXQgSSBhbHJlYWR5IHJlZ2Fy ZCBhcyBiZWluZyBDVC1jb21wbGlhbnQiLg0KDQpUaGlzIGlzbid0IGFuIGVzc2VudGlhbCBwYXJ0 IG9mIDY5NjItYmlzLiAgT3RoZXIgdGhhbiBCZW4gTCdzICJTb3VuZHMgDQpsaWtlIGEgZ29vZCBp ZGVhIiBjb21tZW50IGluIFsxXSwgSSBkb24ndCByZWNhbGwgYW55b25lIGNvbW1lbnRpbmcgb24g aXQgDQp1bnRpbCBFS1Igc3RhcnRlZCB0aGlzIHRocmVhZC4NCg0KSSBwcm9wb3NlIHRvIHJlbW92 ZSB0aGlzIGNhY2hlZC1pbmZvIG1lY2hhbmlzbSBmcm9tIDY5NjItYmlzLCBpZiBub2JvZHkgDQpv YmplY3RzLiAgKEl0IGNvdWxkIG9mIGNvdXJzZSBiZSByZXZpc2l0ZWQgaW4gc29tZSBmdXR1cmUg ZG9jdW1lbnQsIGlmIA0KdGhlcmUncyBpbnRlcmVzdCkuDQoNCg0KWzFdIGh0dHBzOi8vdHJhYy5p ZXRmLm9yZy90cmFjL3RyYW5zL3RpY2tldC8xMTENCg0KWzJdIGh0dHBzOi8vZ2l0aHViLmNvbS9n b29nbGUvY2VydGlmaWNhdGUtdHJhbnNwYXJlbmN5LXJmY3MvcHVsbC8xODYNCg0KT24gMzEvMTIv MjAxOCAxNDozNiwgRXJpYyBSZXNjb3JsYSB3cm90ZToNCj4gKyB0cmFucw0KPiANCj4gT24gU3Vu LCBEZWMgMzAsIDIwMTggYXQgMTA6MDYgUE0gTWFydGluIFRob21zb24gPG10QGxvd2VudHJvcHku bmV0IA0KPiA8bWFpbHRvOm10QGxvd2VudHJvcHkubmV0Pj4gd3JvdGU6DQo+IA0KPiANCj4gICAg IE9uIEZyaSwgRGVjIDI4LCAyMDE4LCBhdCAwNDo1OCwgRXJpYyBSZXNjb3JsYSB3cm90ZToNCj4g ICAgICA+IFBsZWFzZSB0YWtlIGEgbG9vayBhdA0KPiAgICAgID4NCj4gICAgIGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRyYW5zLXJmYzY5NjItYmlzLTMwI3NlY3Rpb24t Ni41DQo+IA0KPiAgICAgQXQgYSBtaW5pbXVtLCB0aGlzIHdvdWxkIHNlZW0gdG8gdXBkYXRlIGNh Y2hlZF9pbmZvLg0KPiANCj4gICAgIFRoZXJlJ3Mgbm90IGEgbG90IG9mIG1lYXQgb24gdGhpcyB0 ZXh0LsKgIEl0IHNlZW1zIHRvIGJlIHNheWluZyB0aGF0DQo+ICAgICBpZiB5b3UgYXJlIHByb3Zp ZGluZyB0cmFuc3BhcmVuY3lfaW5mbywgdGhlbiB5b3UgY2FuIHByb3ZpZGUgYQ0KPiAgICAgY2Vy dGlmaWNhdGUgb3RoZXIgdGhhbiBhbnkgb2YgdGhlIGNlcnRpZmljYXRlcyB0aGF0IHRoZSBjbGll bnQNCj4gICAgIGJlbGlldmVzIHRvIGJlIENUIGNvbXBsaWFudC7CoCBBbHNvLCB5b3UgZG9uJ3Qg cHJvdmlkZSAieDUwOV9zY3RfdjIiDQo+ICAgICBvciAicHJlY2VydF9zY3RfdjIiIGluIHRyYW5z cGFyZW5jeV9pbmZvLg0KPiANCj4gICAgIEhvdyBpcyB0aGUgY2xpZW50IHRoZW4gYWJsZSB0byBk ZXRlcm1pbmUgdGhhdCB0aGlzIG5ldyBjZXJ0aWZpY2F0ZQ0KPiAgICAgaXMgQ1QgY29tcGxpYW50 P8KgIFVzaW5nwqAgImluY2x1c2lvbl9wcm9vZl92MiIgYW5kDQo+ICAgICAic2lnbmVkX3RyZWVf aGVhZF92MiIgKG9yIG9uZSBvciBvdGhlcik/wqAgSWYgc28sIHRoZSB0ZXh0IGRvZXNuJ3QNCj4g ICAgIHBvaW50IGluIHRoYXQgZGlyZWN0aW9uLg0KPiANCj4gICAgIFRoZXJlJ3MgYSBsb3Qgb2Yg IndoeSIgbWlzc2luZyBpbiB0aGlzIGRvY3VtZW50LsKgIFdoeSB3b3VsZCBhIGNsaWVudA0KPiAg ICAgY2hvb3NlIHRvIGluZGljYXRlICJjdF9jb21wbGlhbnQiP8KgIFdoeSBpcyBjYWNoZWRfaW5m byBiZWluZw0KPiAgICAgZXh0ZW5kZWQgaW4gdGhpcyB3YXk/DQo+IA0KPiAgICAgSSBtaWdodCBn dWVzcyB0aGF0IHRoZSByZWFzb24gaGVyZSBpcyB0aGF0IHRoZSBkcmFmdCBhaW1zIHRvIGF2b2lk DQo+ICAgICBpbmNsdWRpbmcgaW5mb3JtYXRpb24gdGhhdCBtaWdodCBjaGFuZ2Ugb3ZlciB0aW1l LCB3aGljaCB3b3VsZA0KPiAgICAgcmVuZGVyIGNhY2hlcyBpbnZhbGlkLsKgIElzbid0IHRoYXQg bW90aXZhdGlvbiB0byByZWNvbW1lbmQgYW4gU0NUDQo+ICAgICBvdmVyIGFuIFNUSD8NCj4gDQo+ ICAgICBTZXBhcmF0ZWx5LCB3aHkgZG9lcyB0aGlzIGVzdGFibGlzaCBhIG5ldyByZWdpc3RyeSBm b3Igc2lnbmF0dXJlDQo+ICAgICBzY2hlbWVzP8KgIEl0IGlzIG9idmlvdXNseSB0cnlpbmcgdG8g a2VlcCBUTFMgY29tcGF0aWJpbGl0eSwgYmFzZWQgb24NCj4gICAgIHRoZSBjb2RlcG9pbnRzLCBi dXQgZm9ya2luZyB0aGUgcmVnaXN0cnkgaXMgYSBncmVhdCB3YXkgdG8gY3JlYXRlDQo+ICAgICBw cm9ibGVtcy4NCg0KLS0gDQpSb2IgU3RyYWRsaW5nDQpTZW5pb3IgUmVzZWFyY2ggJiBEZXZlbG9w bWVudCBTY2llbnRpc3QNCkVtYWlsOiByb2JAc2VjdGlnby5jb20NCg0K From nobody Fri Feb 22 06:52: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 BED8F1200D7 for ; Fri, 22 Feb 2019 06:52:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IML7519YAtE8 for ; Fri, 22 Feb 2019 06:52:05 -0800 (PST) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81644130DD8 for ; Fri, 22 Feb 2019 06:52:01 -0800 (PST) Received: by mail-lf1-x12d.google.com with SMTP id v7so1927660lfd.2 for ; Fri, 22 Feb 2019 06:52:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=b03JlfeVyCL3hcPcYAX5nPdn+BsL77mHYkSh3SYhyX0=; b=esrzi+fxUqWgD82yjqw4v9wPlZZ5CQJWwHE7+gbj8Eepx8TIl2fEfFPKmzf9Y+L8ow xEPaLr5SrYnGprFHoqfAfYUUHbYbqnbWc6c2UTBpc0ZdzoYdBPzBXWW2wcssN5VXdtkJ Q/j91dbUdi7yPytMCF1N6A/hFm5kjLzc5JydN8Z84fu6/zoc4hX+sUZmq2F4Iyz69lK3 WXe4uw0Dg+1MlUsgQqowVFwIVMyQrjYv9WJ6TkwmlPcMFTdrl7nKHIkR8bNv//14XGPR 8L0d0bv0e54W3d6h0EwKkZOTuTRR2BRcuzotlu1Pi3IFqGNXHCpH+fDB7HsmJ2cD786x P9/g== 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=b03JlfeVyCL3hcPcYAX5nPdn+BsL77mHYkSh3SYhyX0=; b=PtZKWkV54vca2zkg2yGG17mT841IBCFbieaFwsxajpJDnq2qmHC7xajWzLPjgvhwX5 jI7PyUqFpJVN9966U/gP6DMCUNxlSoOiYD4/fOBV1bwogeJvAFF27UzGrtl3ztpvwpl0 NXsFQDDA6+nwbgv3RK5Ge2rEuzP387Giq7JmJK/vq+u5zrSbLX6/5GRGy8+QuSFCRrgA 2kQYy+6GQuhvV4BJyQrP9/BZGDSW7353S2ilfg0bnW0lh5m8pkhk8Trv+faH8kmf8gTM HVhMmYXufOExuWoIgV0QUbXNENNEsIBtlm24pIHiPbVRCL1/dN8kXJjXuxDK5ppUVWiD +wCQ== X-Gm-Message-State: AHQUAuYY8wVzxz8gk1fF8eQDXkk89eTZMMjbccbcpfdhMemI+aOlwclY bDqY3CNQFO3+ILC7kB2AwopwFfzfkp6D+1kvb2kFKW0j X-Google-Smtp-Source: AHgI3Ib/1DB8FPtUxnOp4aoU9Uj+JA+R94VZPcOaiCjLwm2Ludg/pQnU/UIfrYe8J3/ky4vxtw3RBFImFU+V0GQBxZE= X-Received: by 2002:ac2:4191:: with SMTP id z17mr2063267lfh.78.1550847119565; Fri, 22 Feb 2019 06:51:59 -0800 (PST) MIME-Version: 1.0 References: <1546236377.2848619.1621803360.25FE2839@webmail.messagingengine.com> <1f481215-9a30-dd91-7039-8e2ac5351cbe@sectigo.com> In-Reply-To: <1f481215-9a30-dd91-7039-8e2ac5351cbe@sectigo.com> From: Eric Rescorla Date: Fri, 22 Feb 2019 06:51:20 -0800 Message-ID: To: Rob Stradling Cc: Martin Thomson , Trans , "" Content-Type: multipart/alternative; boundary="000000000000a9bc5805827cbbe8" Archived-At: Subject: Re: [TLS] ct_compliant cached info field 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, 22 Feb 2019 14:52:10 -0000 --000000000000a9bc5805827cbbe8 Content-Type: text/plain; charset="UTF-8" That works for me -Ekr On Fri, Feb 22, 2019 at 6:41 AM Rob Stradling wrote: > EKR, Martin, > > Hi, and sorry for the long delay in replying. > > This originated in [1] and was added to 6962-bis in [2]. The motivation > was to provide a mechanism to permit a TLS server to avoid sending CT > artifacts (SCTs, STHs, inclusion proofs) that it knows the TLS client > already has or doesn't need, thereby reducing bytes on the wire for > constrained and high-volume environments. > > The approach envisaged by RFC7924 seems to be: "here's a list of TLS > message fingerprints I've received previously; please don't send these > exact messages to me again". This works for stand-alone messages that > contain one item, such as the server's Certificate message (which > contains 1 server certificate chain). > > However, in 6962-bis's case, SCTs and inclusion proofs are not > stand-alone items; instead, they correspond to particular certificates. > Each relevant TLS message will contain a TransItemList, which will > probably contain at least a set of several SCTs; and whilst each SCT is > static, the set (and the order within the set) is not. Therefore, the > approach of caching TLS messages by fingerprint didn't look like it > would work for us. > > We concluded that it would make more sense for the client to make a more > high-level statement: "here's a list of certificate fingerprints that > I've received previously and that I already regard as being CT-compliant". > > This isn't an essential part of 6962-bis. Other than Ben L's "Sounds > like a good idea" comment in [1], I don't recall anyone commenting on it > until EKR started this thread. > > I propose to remove this cached-info mechanism from 6962-bis, if nobody > objects. (It could of course be revisited in some future document, if > there's interest). > > > [1] https://trac.ietf.org/trac/trans/ticket/111 > > [2] https://github.com/google/certificate-transparency-rfcs/pull/186 > > On 31/12/2018 14:36, Eric Rescorla wrote: > > + trans > > > > On Sun, Dec 30, 2018 at 10:06 PM Martin Thomson > > wrote: > > > > > > On Fri, Dec 28, 2018, at 04:58, Eric Rescorla wrote: > > > Please take a look at > > > > > > https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-30#section-6.5 > > > > At a minimum, this would seem to update cached_info. > > > > There's not a lot of meat on this text. It seems to be saying that > > if you are providing transparency_info, then you can provide a > > certificate other than any of the certificates that the client > > believes to be CT compliant. Also, you don't provide "x509_sct_v2" > > or "precert_sct_v2" in transparency_info. > > > > How is the client then able to determine that this new certificate > > is CT compliant? Using "inclusion_proof_v2" and > > "signed_tree_head_v2" (or one or other)? If so, the text doesn't > > point in that direction. > > > > There's a lot of "why" missing in this document. Why would a client > > choose to indicate "ct_compliant"? Why is cached_info being > > extended in this way? > > > > I might guess that the reason here is that the draft aims to avoid > > including information that might change over time, which would > > render caches invalid. Isn't that motivation to recommend an SCT > > over an STH? > > > > Separately, why does this establish a new registry for signature > > schemes? It is obviously trying to keep TLS compatibility, based on > > the codepoints, but forking the registry is a great way to create > > problems. > > -- > Rob Stradling > Senior Research & Development Scientist > Email: rob@sectigo.com > > --000000000000a9bc5805827cbbe8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That works for me

-Ekr
=


On Fri, Feb 22, 2019 at 6:41 AM Rob Stradling <rob@sectigo.com> wrote:
EKR, Martin,

Hi, and sorry for the long delay in replying.

This originated in [1] and was added to 6962-bis in [2].=C2=A0 The motivati= on
was to provide a mechanism to permit a TLS server to avoid sending CT
artifacts (SCTs, STHs, inclusion proofs) that it knows the TLS client
already has or doesn't need, thereby reducing bytes on the wire for constrained and high-volume environments.

The approach envisaged by RFC7924 seems to be: "here's a list of T= LS
message fingerprints I've received previously; please don't send th= ese
exact messages to me again".=C2=A0 This works for stand-alone messages= that
contain one item, such as the server's Certificate message (which
contains 1 server certificate chain).

However, in 6962-bis's case, SCTs and inclusion proofs are not
stand-alone items; instead, they correspond to particular certificates. Each relevant TLS message will contain a TransItemList, which will
probably contain at least a set of several SCTs; and whilst each SCT is static, the set (and the order within the set) is not.=C2=A0 Therefore, the=
approach of caching TLS messages by fingerprint didn't look like it would work for us.

We concluded that it would make more sense for the client to make a more high-level statement: "here's a list of certificate fingerprints t= hat
I've received previously and that I already regard as being CT-complian= t".

This isn't an essential part of 6962-bis.=C2=A0 Other than Ben L's = "Sounds
like a good idea" comment in [1], I don't recall anyone commenting= on it
until EKR started this thread.

I propose to remove this cached-info mechanism from 6962-bis, if nobody objects.=C2=A0 (It could of course be revisited in some future document, if=
there's interest).


[1] https://trac.ietf.org/trac/trans/ticket/111

[2] https://github.com/google/certif= icate-transparency-rfcs/pull/186

On 31/12/2018 14:36, Eric Rescorla wrote:
> + trans
>
> On Sun, Dec 30, 2018 at 10:06 PM Martin Thomson <mt@lowentropy.net
> <mailto:mt@l= owentropy.net>> wrote:
>
>
>=C2=A0 =C2=A0 =C2=A0On Fri, Dec 28, 2018, at 04:58, Eric Rescorla wrote= :
>=C2=A0 =C2=A0 =C2=A0 > Please take a look at
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0https= ://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-30#section-6.5
>
>=C2=A0 =C2=A0 =C2=A0At a minimum, this would seem to update cached_info= .
>
>=C2=A0 =C2=A0 =C2=A0There's not a lot of meat on this text.=C2=A0 I= t seems to be saying that
>=C2=A0 =C2=A0 =C2=A0if you are providing transparency_info, then you ca= n provide a
>=C2=A0 =C2=A0 =C2=A0certificate other than any of the certificates that= the client
>=C2=A0 =C2=A0 =C2=A0believes to be CT compliant.=C2=A0 Also, you don= 9;t provide "x509_sct_v2"
>=C2=A0 =C2=A0 =C2=A0or "precert_sct_v2" in transparency_info.=
>
>=C2=A0 =C2=A0 =C2=A0How is the client then able to determine that this = new certificate
>=C2=A0 =C2=A0 =C2=A0is CT compliant?=C2=A0 Using=C2=A0 "inclusion_= proof_v2" and
>=C2=A0 =C2=A0 =C2=A0"signed_tree_head_v2" (or one or other)?= =C2=A0 If so, the text doesn't
>=C2=A0 =C2=A0 =C2=A0point in that direction.
>
>=C2=A0 =C2=A0 =C2=A0There's a lot of "why" missing in thi= s document.=C2=A0 Why would a client
>=C2=A0 =C2=A0 =C2=A0choose to indicate "ct_compliant"?=C2=A0 = Why is cached_info being
>=C2=A0 =C2=A0 =C2=A0extended in this way?
>
>=C2=A0 =C2=A0 =C2=A0I might guess that the reason here is that the draf= t aims to avoid
>=C2=A0 =C2=A0 =C2=A0including information that might change over time, = which would
>=C2=A0 =C2=A0 =C2=A0render caches invalid.=C2=A0 Isn't that motivat= ion to recommend an SCT
>=C2=A0 =C2=A0 =C2=A0over an STH?
>
>=C2=A0 =C2=A0 =C2=A0Separately, why does this establish a new registry = for signature
>=C2=A0 =C2=A0 =C2=A0schemes?=C2=A0 It is obviously trying to keep TLS c= ompatibility, based on
>=C2=A0 =C2=A0 =C2=A0the codepoints, but forking the registry is a great= way to create
>=C2=A0 =C2=A0 =C2=A0problems.

--
Rob Stradling
Senior Research & Development Scientist
Email: rob@sectigo.com=

--000000000000a9bc5805827cbbe8-- From nobody Mon Feb 25 03:46:17 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F17D1200B3; Mon, 25 Feb 2019 03:46:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-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=comodoca.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uM28D5vpM0Ba; Mon, 25 Feb 2019 03:46:06 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-eopbgr810085.outbound.protection.outlook.com [40.107.81.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8B1312F295; Mon, 25 Feb 2019 03:46:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comodoca.onmicrosoft.com; s=selector1-sectigo-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3NXJgYh27jB3nGh5Si6tq5Qu3fQkteCyWDvJdsn1PSE=; b=httSwaLQH9JZg04wOslflPPWE/IoQYVDbAzkVCl93K2PtN2xZNWNaLDlGTgJCVqyZ0QF0aHB2g2ClZ/ZSq5FGbYJ9zVE0JkJvZma7QJHpYJIBzU4AlbYNr2p3Pj39g4wVXIHFSFYPBq1rzFpCF7mRZ8NoSgeAobCzyYzOUQFBUM= Received: from DM6PR17MB2716.namprd17.prod.outlook.com (20.178.224.155) by DM6PR17MB3355.namprd17.prod.outlook.com (20.176.127.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.14; Mon, 25 Feb 2019 11:46:04 +0000 Received: from DM6PR17MB2716.namprd17.prod.outlook.com ([fe80::80e1:4c3b:1fac:22b9]) by DM6PR17MB2716.namprd17.prod.outlook.com ([fe80::80e1:4c3b:1fac:22b9%6]) with mapi id 15.20.1643.019; Mon, 25 Feb 2019 11:46:04 +0000 From: Rob Stradling To: Eric Rescorla CC: Martin Thomson , Trans , "" Thread-Topic: [TLS] ct_compliant cached info field Thread-Index: AQHUng4AiTlMjhjKyU+rxTv7bjD+jKWYYcaAgACOqgCAU0y3AIAAAuEAgASDJ4A= Date: Mon, 25 Feb 2019 11:46:03 +0000 Message-ID: <6bf40eed-54f1-c04c-6e60-8bf67503036a@sectigo.com> References: <1546236377.2848619.1621803360.25FE2839@webmail.messagingengine.com> <1f481215-9a30-dd91-7039-8e2ac5351cbe@sectigo.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P265CA0451.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:e::31) To DM6PR17MB2716.namprd17.prod.outlook.com (2603:10b6:5:122::27) authentication-results: spf=none (sender IP is ) smtp.mailfrom=rob@sectigo.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2a02:1788:4ff:1000:f68e:38ff:fe7a:a226] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4bd16097-ff7f-4f48-62e1-08d69b16d205 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:DM6PR17MB3355; x-ms-traffictypediagnostic: DM6PR17MB3355: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-forefront-prvs: 095972DF2F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(346002)(39850400004)(366004)(396003)(376002)(189003)(199004)(81166006)(2616005)(54906003)(8676002)(476003)(256004)(6116002)(14444005)(71190400001)(71200400001)(93886005)(6246003)(186003)(6916009)(305945005)(316002)(25786009)(229853002)(7736002)(97736004)(11346002)(4326008)(86362001)(5660300002)(486006)(81156014)(46003)(386003)(53546011)(31686004)(6506007)(68736007)(6512007)(6306002)(478600001)(53936002)(14454004)(6486002)(76176011)(99286004)(52116002)(105586002)(106356001)(8936002)(36756003)(966005)(2906002)(446003)(102836004)(31696002)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR17MB3355; H:DM6PR17MB2716.namprd17.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: sectigo.com does not designate permitted sender hosts) x-microsoft-exchange-diagnostics: =?utf-8?B?MTtETTZQUjE3TUIzMzU1OzIzOlYvbHZ3SmdvTnRUOVoxamsrMENXWEdhYkNp?= =?utf-8?B?a1c0RmlSNUJjVU8rVFY4a3Rid2Z2VmJWVW1rM0tzN2lZM3dPSlBBbHJxWU1R?= =?utf-8?B?SklZQ0lpRmNvbDZ5VmUweEM1TkR5b2dQT1pXcnIvamdwZmRNdk5zV1dVR056?= =?utf-8?B?NTFGSXpzd2pqSmIrcnB0cTRNVDdvaFNtWVlMT09ZNStrU0lNVFVBdnhiVXl3?= =?utf-8?B?MU5NSThjbjNlbTZQVktBNXNoUFROdHNZZktGOHppZDdIYTlUbUlseXo4ejkv?= =?utf-8?B?YitNWGlyT3ZCQ2VrYWtRNTlrbnQxeEMxL29uVGpPNUhKUW1RS3dvOW9BMStX?= =?utf-8?B?VXo3U0gwK0ViZUU4Q3VHMU1SSWFKandCTmhtMitEcVpxNkVFQm5wYXpZcCsx?= =?utf-8?B?bXFZdWJIVXlTZ1UrWjYwalh4RVRMNmhvSFExU3hyTWpLaFFtMnRSQStrRWxF?= =?utf-8?B?ZFArOHlaMXpHU3dIbm9MZmpFcmQzak54SCtZMVE3TkoxOE84T0lwaEFPSWdI?= =?utf-8?B?NzNFOGtoWDdKODd1eElyd2lpcjMvbFNkdHh2S05aVUFpM2pJQUtmOVRxUExK?= =?utf-8?B?WkYvclVrMGxpRGV4R1ZwQlc0TWxnV3FLbXhFUVo4dWxFczlNMVJ4UWNTRmRZ?= =?utf-8?B?R3pkYXJsenI2eVM4Q1RxNEVWa1g3UzlUaWxMbXJuZTgyejJxMmZyUjdrSkVp?= =?utf-8?B?RzZzdlEvTlBZN2Y4WDQ0aU9RWC8rVEtaTUZWSFhQa1NwbWQyeEYvUEhwRmZJ?= =?utf-8?B?UHlZRnZEQnh0bG9VVjU0QUZqWG9KbUdMcXlwVTlLM3Q2VCtEVGRpN2ZEa01r?= =?utf-8?B?b1lGRnlTWDdKZDgraUdkMldGVzVhS1dNS2xRRDRFZ25memw4Z1ZSRi9NQlB4?= =?utf-8?B?YlMrbHRnc2g0SXF4RmxjNkU4aWppSjBlb2VwL3VxU281eDNxdk9zeU02UzNN?= =?utf-8?B?NTRrbVBRaC8ycyttc043K0hxS1VZMUgzZXh3MmJjUmFzYVl2cWJwRUdFeWVK?= =?utf-8?B?M1BwRjBaTm83b1lSdWRCMTU2OFdQTWx0MDhrcG9QQkt1TWJyVzRzK3E0TmRG?= =?utf-8?B?bzJLMFplYnlHaW42R0hISlkwRmp3L1djeHJ5TUxQc25RaGZ4Qnk0OGVRV09U?= =?utf-8?B?WUgyTGZMZCttWFRRNTIzTjMrS2cvdWJid0FSVkRuTlVmaEtSRFRLWkJhNklh?= =?utf-8?B?WTltdTFoMWlJNnZyVXRJeFNwM3NwV1ZSZkdxZGxGb0ZUTGk1TWcwNFRoV3lq?= =?utf-8?B?WDBNY2t5UE8xRUlXOWFmeWo5NDBMWmpMTlJ2ei82ZWUyMUU2M0drWXgyZUo5?= =?utf-8?B?OUNOZjh1NFNobThSbkdzdjhWTTFyOEFmc0tEUjAwMFV2WGdrdUV4dktSUWFh?= =?utf-8?B?aStUM0NqbUorOEU4b25xemh3dEZvbzRWTFgvSGQ0OUdraCtMOE1yZnBualBH?= =?utf-8?B?WVhCTUpZdEFBTnJ2U29OcUZKY05GTlVaU3Nna2RJMWc0RGR4d2FKNThQcStm?= =?utf-8?B?OUZhWXlLMmxNaWovaWt0WEg5TWhTUGdqRHNKVjdLemwrOWpsRG5paU03U2dU?= =?utf-8?B?alNBYS9HV08vaXg0YmhlMVhPT0Z2VTZWR3hPamZ6Y3BKN1hkdWVpSm0vdzZP?= =?utf-8?B?elhNOWtJY2xab1NrMlF4MFZIWng4bFZGcE1YbnVCbmJ2WVBJbGd4NDh2MWZD?= =?utf-8?B?bVRJNEY3dUg0RkFERmhkS3cwQ0FxcklTVExXdnRBNHpZMWRCZVFWSHFZR3pa?= =?utf-8?Q?1uQDMTTHB9UlKtLcdYtBwe0cFNWSP4Zp3qaag=3D?= x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: tU3gJ8tFy/KfjPPD3iimrgifF7YqxA+VQ/hyPQLAWSMxMuG5jrsLajDVYaorn3Jdsyiht4aZaCudN3SgTulKEYT1j3NOoLWeWrKydM9p3sTt3il+rj7m3pVLoTajEafuNnyp3jcZhRJ7X5tg433HIy4i7xdd5IpyDdpf5j8tK3HTooLMYET3fVYYaQ2O5ufZ7/bSpumCbThCgIWdACd/4+kP8z6Z6N9T/xmBbxlmse48RKy7PjAfCqr1d4q2g06hDk7O3mYDH0DGu3w2any4CBzVI1nUNbWrSzj8dqM2hWo5/D8kYR2FeLdcf6ZG7aBQac1mNclfxu0CP+K44W8VXTI8v6dMIsgFa9YELSIppCQToBsGZZPa3S5jAvCsfXpiNu6Sb2YdCZpa+fLtHeReuaCrOIZnTaodHkKY+F7E4B0= Content-Type: text/plain; charset="utf-8" Content-ID: <665BF445716C274299E47C4D3C87F282@namprd17.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sectigo.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4bd16097-ff7f-4f48-62e1-08d69b16d205 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Feb 2019 11:46:01.8056 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-id: 0e9c4894-6caa-465d-9660-4b6968b49fb7 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR17MB3355 Archived-At: Subject: Re: [TLS] ct_compliant cached info field 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, 25 Feb 2019 11:46:10 -0000 VGhhbmtzIEVLUi4NCg0KRG9uZSwgaW4gaHR0cHM6Ly9naXRodWIuY29tL2dvb2dsZS9jZXJ0aWZp Y2F0ZS10cmFuc3BhcmVuY3ktcmZjcy9wdWxsLzMwNw0KDQpPbiAyMi8wMi8yMDE5IDE0OjUxLCBF cmljIFJlc2NvcmxhIHdyb3RlOg0KPiBUaGF0IHdvcmtzIGZvciBtZQ0KPiANCj4gLUVrcg0KPiAN Cj4gDQo+IE9uIEZyaSwgRmViIDIyLCAyMDE5IGF0IDY6NDEgQU0gUm9iIFN0cmFkbGluZyA8cm9i QHNlY3RpZ28uY29tIA0KPiA8bWFpbHRvOnJvYkBzZWN0aWdvLmNvbT4+IHdyb3RlOg0KPiANCj4g ICAgIEVLUiwgTWFydGluLA0KPiANCj4gICAgIEhpLCBhbmQgc29ycnkgZm9yIHRoZSBsb25nIGRl bGF5IGluIHJlcGx5aW5nLg0KPiANCj4gICAgIFRoaXMgb3JpZ2luYXRlZCBpbiBbMV0gYW5kIHdh cyBhZGRlZCB0byA2OTYyLWJpcyBpbiBbMl0uwqAgVGhlDQo+ICAgICBtb3RpdmF0aW9uDQo+ICAg ICB3YXMgdG8gcHJvdmlkZSBhIG1lY2hhbmlzbSB0byBwZXJtaXQgYSBUTFMgc2VydmVyIHRvIGF2 b2lkIHNlbmRpbmcgQ1QNCj4gICAgIGFydGlmYWN0cyAoU0NUcywgU1RIcywgaW5jbHVzaW9uIHBy b29mcykgdGhhdCBpdCBrbm93cyB0aGUgVExTIGNsaWVudA0KPiAgICAgYWxyZWFkeSBoYXMgb3Ig ZG9lc24ndCBuZWVkLCB0aGVyZWJ5IHJlZHVjaW5nIGJ5dGVzIG9uIHRoZSB3aXJlIGZvcg0KPiAg ICAgY29uc3RyYWluZWQgYW5kIGhpZ2gtdm9sdW1lIGVudmlyb25tZW50cy4NCj4gDQo+ICAgICBU aGUgYXBwcm9hY2ggZW52aXNhZ2VkIGJ5IFJGQzc5MjQgc2VlbXMgdG8gYmU6ICJoZXJlJ3MgYSBs aXN0IG9mIFRMUw0KPiAgICAgbWVzc2FnZSBmaW5nZXJwcmludHMgSSd2ZSByZWNlaXZlZCBwcmV2 aW91c2x5OyBwbGVhc2UgZG9uJ3Qgc2VuZCB0aGVzZQ0KPiAgICAgZXhhY3QgbWVzc2FnZXMgdG8g bWUgYWdhaW4iLsKgIFRoaXMgd29ya3MgZm9yIHN0YW5kLWFsb25lIG1lc3NhZ2VzIHRoYXQNCj4g ICAgIGNvbnRhaW4gb25lIGl0ZW0sIHN1Y2ggYXMgdGhlIHNlcnZlcidzIENlcnRpZmljYXRlIG1l c3NhZ2UgKHdoaWNoDQo+ICAgICBjb250YWlucyAxIHNlcnZlciBjZXJ0aWZpY2F0ZSBjaGFpbiku DQo+IA0KPiAgICAgSG93ZXZlciwgaW4gNjk2Mi1iaXMncyBjYXNlLCBTQ1RzIGFuZCBpbmNsdXNp b24gcHJvb2ZzIGFyZSBub3QNCj4gICAgIHN0YW5kLWFsb25lIGl0ZW1zOyBpbnN0ZWFkLCB0aGV5 IGNvcnJlc3BvbmQgdG8gcGFydGljdWxhciBjZXJ0aWZpY2F0ZXMuDQo+ICAgICBFYWNoIHJlbGV2 YW50IFRMUyBtZXNzYWdlIHdpbGwgY29udGFpbiBhIFRyYW5zSXRlbUxpc3QsIHdoaWNoIHdpbGwN Cj4gICAgIHByb2JhYmx5IGNvbnRhaW4gYXQgbGVhc3QgYSBzZXQgb2Ygc2V2ZXJhbCBTQ1RzOyBh bmQgd2hpbHN0IGVhY2ggU0NUIGlzDQo+ICAgICBzdGF0aWMsIHRoZSBzZXQgKGFuZCB0aGUgb3Jk ZXIgd2l0aGluIHRoZSBzZXQpIGlzIG5vdC7CoCBUaGVyZWZvcmUsIHRoZQ0KPiAgICAgYXBwcm9h Y2ggb2YgY2FjaGluZyBUTFMgbWVzc2FnZXMgYnkgZmluZ2VycHJpbnQgZGlkbid0IGxvb2sgbGlr ZSBpdA0KPiAgICAgd291bGQgd29yayBmb3IgdXMuDQo+IA0KPiAgICAgV2UgY29uY2x1ZGVkIHRo YXQgaXQgd291bGQgbWFrZSBtb3JlIHNlbnNlIGZvciB0aGUgY2xpZW50IHRvIG1ha2UgYQ0KPiAg ICAgbW9yZQ0KPiAgICAgaGlnaC1sZXZlbCBzdGF0ZW1lbnQ6ICJoZXJlJ3MgYSBsaXN0IG9mIGNl cnRpZmljYXRlIGZpbmdlcnByaW50cyB0aGF0DQo+ICAgICBJJ3ZlIHJlY2VpdmVkIHByZXZpb3Vz bHkgYW5kIHRoYXQgSSBhbHJlYWR5IHJlZ2FyZCBhcyBiZWluZw0KPiAgICAgQ1QtY29tcGxpYW50 Ii4NCj4gDQo+ICAgICBUaGlzIGlzbid0IGFuIGVzc2VudGlhbCBwYXJ0IG9mIDY5NjItYmlzLsKg IE90aGVyIHRoYW4gQmVuIEwncyAiU291bmRzDQo+ICAgICBsaWtlIGEgZ29vZCBpZGVhIiBjb21t ZW50IGluIFsxXSwgSSBkb24ndCByZWNhbGwgYW55b25lIGNvbW1lbnRpbmcNCj4gICAgIG9uIGl0 DQo+ICAgICB1bnRpbCBFS1Igc3RhcnRlZCB0aGlzIHRocmVhZC4NCj4gDQo+ICAgICBJIHByb3Bv c2UgdG8gcmVtb3ZlIHRoaXMgY2FjaGVkLWluZm8gbWVjaGFuaXNtIGZyb20gNjk2Mi1iaXMsIGlm IG5vYm9keQ0KPiAgICAgb2JqZWN0cy7CoCAoSXQgY291bGQgb2YgY291cnNlIGJlIHJldmlzaXRl ZCBpbiBzb21lIGZ1dHVyZSBkb2N1bWVudCwgaWYNCj4gICAgIHRoZXJlJ3MgaW50ZXJlc3QpLg0K PiANCj4gDQo+ICAgICBbMV0gaHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvdHJhbnMvdGlja2V0 LzExMQ0KPiANCj4gICAgIFsyXSBodHRwczovL2dpdGh1Yi5jb20vZ29vZ2xlL2NlcnRpZmljYXRl LXRyYW5zcGFyZW5jeS1yZmNzL3B1bGwvMTg2DQo+IA0KPiAgICAgT24gMzEvMTIvMjAxOCAxNDoz NiwgRXJpYyBSZXNjb3JsYSB3cm90ZToNCj4gICAgICA+ICsgdHJhbnMNCj4gICAgICA+DQo+ICAg ICAgPiBPbiBTdW4sIERlYyAzMCwgMjAxOCBhdCAxMDowNiBQTSBNYXJ0aW4gVGhvbXNvbg0KPiAg ICAgPG10QGxvd2VudHJvcHkubmV0IDxtYWlsdG86bXRAbG93ZW50cm9weS5uZXQ+DQo+ICAgICAg PiA8bWFpbHRvOm10QGxvd2VudHJvcHkubmV0IDxtYWlsdG86bXRAbG93ZW50cm9weS5uZXQ+Pj4g d3JvdGU6DQo+ICAgICAgPg0KPiAgICAgID4NCj4gICAgICA+wqAgwqAgwqBPbiBGcmksIERlYyAy OCwgMjAxOCwgYXQgMDQ6NTgsIEVyaWMgUmVzY29ybGEgd3JvdGU6DQo+ICAgICAgPsKgIMKgIMKg ID4gUGxlYXNlIHRha2UgYSBsb29rIGF0DQo+ICAgICAgPsKgIMKgIMKgID4NCj4gICAgICA+DQo+ ICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10cmFucy1yZmM2OTYy LWJpcy0zMCNzZWN0aW9uLTYuNQ0KPiAgICAgID4NCj4gICAgICA+wqAgwqAgwqBBdCBhIG1pbmlt dW0sIHRoaXMgd291bGQgc2VlbSB0byB1cGRhdGUgY2FjaGVkX2luZm8uDQo+ICAgICAgPg0KPiAg ICAgID7CoCDCoCDCoFRoZXJlJ3Mgbm90IGEgbG90IG9mIG1lYXQgb24gdGhpcyB0ZXh0LsKgIEl0 IHNlZW1zIHRvIGJlDQo+ICAgICBzYXlpbmcgdGhhdA0KPiAgICAgID7CoCDCoCDCoGlmIHlvdSBh cmUgcHJvdmlkaW5nIHRyYW5zcGFyZW5jeV9pbmZvLCB0aGVuIHlvdSBjYW4gcHJvdmlkZSBhDQo+ ICAgICAgPsKgIMKgIMKgY2VydGlmaWNhdGUgb3RoZXIgdGhhbiBhbnkgb2YgdGhlIGNlcnRpZmlj YXRlcyB0aGF0IHRoZSBjbGllbnQNCj4gICAgICA+wqAgwqAgwqBiZWxpZXZlcyB0byBiZSBDVCBj b21wbGlhbnQuwqAgQWxzbywgeW91IGRvbid0IHByb3ZpZGUNCj4gICAgICJ4NTA5X3NjdF92MiIN Cj4gICAgICA+wqAgwqAgwqBvciAicHJlY2VydF9zY3RfdjIiIGluIHRyYW5zcGFyZW5jeV9pbmZv Lg0KPiAgICAgID4NCj4gICAgICA+wqAgwqAgwqBIb3cgaXMgdGhlIGNsaWVudCB0aGVuIGFibGUg dG8gZGV0ZXJtaW5lIHRoYXQgdGhpcyBuZXcNCj4gICAgIGNlcnRpZmljYXRlDQo+ICAgICAgPsKg IMKgIMKgaXMgQ1QgY29tcGxpYW50P8KgIFVzaW5nwqAgImluY2x1c2lvbl9wcm9vZl92MiIgYW5k DQo+ICAgICAgPsKgIMKgIMKgInNpZ25lZF90cmVlX2hlYWRfdjIiIChvciBvbmUgb3Igb3RoZXIp P8KgIElmIHNvLCB0aGUgdGV4dCBkb2Vzbid0DQo+ICAgICAgPsKgIMKgIMKgcG9pbnQgaW4gdGhh dCBkaXJlY3Rpb24uDQo+ICAgICAgPg0KPiAgICAgID7CoCDCoCDCoFRoZXJlJ3MgYSBsb3Qgb2Yg IndoeSIgbWlzc2luZyBpbiB0aGlzIGRvY3VtZW50LsKgIFdoeSB3b3VsZCBhDQo+ICAgICBjbGll bnQNCj4gICAgICA+wqAgwqAgwqBjaG9vc2UgdG8gaW5kaWNhdGUgImN0X2NvbXBsaWFudCI/wqAg V2h5IGlzIGNhY2hlZF9pbmZvIGJlaW5nDQo+ICAgICAgPsKgIMKgIMKgZXh0ZW5kZWQgaW4gdGhp cyB3YXk/DQo+ICAgICAgPg0KPiAgICAgID7CoCDCoCDCoEkgbWlnaHQgZ3Vlc3MgdGhhdCB0aGUg cmVhc29uIGhlcmUgaXMgdGhhdCB0aGUgZHJhZnQgYWltcyB0bw0KPiAgICAgYXZvaWQNCj4gICAg ICA+wqAgwqAgwqBpbmNsdWRpbmcgaW5mb3JtYXRpb24gdGhhdCBtaWdodCBjaGFuZ2Ugb3ZlciB0 aW1lLCB3aGljaCB3b3VsZA0KPiAgICAgID7CoCDCoCDCoHJlbmRlciBjYWNoZXMgaW52YWxpZC7C oCBJc24ndCB0aGF0IG1vdGl2YXRpb24gdG8gcmVjb21tZW5kIGFuIFNDVA0KPiAgICAgID7CoCDC oCDCoG92ZXIgYW4gU1RIPw0KPiAgICAgID4NCj4gICAgICA+wqAgwqAgwqBTZXBhcmF0ZWx5LCB3 aHkgZG9lcyB0aGlzIGVzdGFibGlzaCBhIG5ldyByZWdpc3RyeSBmb3Igc2lnbmF0dXJlDQo+ICAg ICAgPsKgIMKgIMKgc2NoZW1lcz/CoCBJdCBpcyBvYnZpb3VzbHkgdHJ5aW5nIHRvIGtlZXAgVExT IGNvbXBhdGliaWxpdHksDQo+ICAgICBiYXNlZCBvbg0KPiAgICAgID7CoCDCoCDCoHRoZSBjb2Rl cG9pbnRzLCBidXQgZm9ya2luZyB0aGUgcmVnaXN0cnkgaXMgYSBncmVhdCB3YXkgdG8gY3JlYXRl DQo+ICAgICAgPsKgIMKgIMKgcHJvYmxlbXMuDQo+IA0KPiAgICAgLS0gDQo+ICAgICBSb2IgU3Ry YWRsaW5nDQo+ICAgICBTZW5pb3IgUmVzZWFyY2ggJiBEZXZlbG9wbWVudCBTY2llbnRpc3QNCj4g ICAgIEVtYWlsOiByb2JAc2VjdGlnby5jb20gPG1haWx0bzpyb2JAc2VjdGlnby5jb20+DQo+IA0K DQotLSANClJvYiBTdHJhZGxpbmcNClNlbmlvciBSZXNlYXJjaCAmIERldmVsb3BtZW50IFNjaWVu dGlzdA0KRW1haWw6IHJvYkBzZWN0aWdvLmNvbQ0KQnJhZGZvcmQsIFVLDQpPZmZpY2U6ICs0NDEy NzQwMjQ3MDcNClNlY3RpZ28gTGltaXRlZA0KDQpUaGlzIG1lc3NhZ2UgYW5kIGFueSBmaWxlcyBh c3NvY2lhdGVkIHdpdGggaXQgbWF5IGNvbnRhaW4gbGVnYWxseSANCnByaXZpbGVnZWQsIGNvbmZp ZGVudGlhbCwgb3IgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24uIElmIHlvdSBhcmUgbm90IHRoZSAN CmludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBub3QgcGVybWl0dGVkIHRvIHVzZSwgY29weSwg b3IgZm9yd2FyZCBpdCwgDQppbiB3aG9sZSBvciBpbiBwYXJ0IHdpdGhvdXQgdGhlIGV4cHJlc3Mg Y29uc2VudCBvZiB0aGUgc2VuZGVyLiBQbGVhc2UgDQpub3RpZnkgdGhlIHNlbmRlciBieSByZXBs eSBlbWFpbCwgZGlzcmVnYXJkIHRoZSBmb3JlZ29pbmcgbWVzc2FnZXMsIGFuZCANCmRlbGV0ZSBp dCBpbW1lZGlhdGVseS4NCg== From nobody Mon Feb 25 10:44: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 BD533130EFE for ; Mon, 25 Feb 2019 10:44:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 SoNPfpxTxXa3 for ; Mon, 25 Feb 2019 10:44:39 -0800 (PST) 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 8029812426A for ; Mon, 25 Feb 2019 10:44:39 -0800 (PST) Received: by mail-yb1-xb2b.google.com with SMTP id f5so4200934ybf.3 for ; Mon, 25 Feb 2019 10:44:39 -0800 (PST) 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 :content-transfer-encoding; bh=+/11zfAzBw9PRJJLte538gXxkHNW86MoGKKmBjCuq7o=; b=ir2GM+O1ixOdkg9PbjdYoqyuuBb1XCSu3p21iXs8PH2TZ1bozfqk3sUhYWBtGSMwwx EohAar0jOSfc92M81qP5GpKb267bQtxprfE/XEkszgF7eapEAOcjljtnQYOgxdxnUYHz 199cpaVvT7ns5J71Jwj2NzILovl9K7qcgQOGNZLHeFNV09NIEICsHsHzmiUP8TMpzJ80 PV4WEV4EwxUnsZ3Pt6vxWMTMVbRrL4VVEA+yOKNfNiDOUndmToBtsk9BVkhM+uEbtY3n OXBL05KdCeNaeMmURguJGnFRTZ2mz8IGc6G6OBwmAfiQFAbp6tFAJ105w0SkuZjf5BWg /cwA== 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:content-transfer-encoding; bh=+/11zfAzBw9PRJJLte538gXxkHNW86MoGKKmBjCuq7o=; b=LGgywX9Q+eyp4gzXZh56vTv9vCCZMOgZpTB2FhO5pEUDxmTe8EU8ZBRWr9nwTvKH/g 0xRGp2cLnP51Nw9w0oHz/nkM8It3+ScxBPudS8NXRpkGqPrQCXA2FGs3vP74Zy9jUbhS 73gR5OaKCKFzV5olOk0TXkgwhW1v4Q5XNh3Lh+ASOh3j0gEnhRFMtq3j1bLHP50Lwyft bi2VKlTERpYB/h1b3eaREBGS8go3eyZGZTJ+lkGk0RPdBJLZsnbInuAX6hvH64bhY+Cs SUP/o0MTHxVuRS3AzCvRJGYQUr2U9GfOwYiXtBaKSdcyxIuSU2NpoP7wCa04QhdzQWZI pfTA== X-Gm-Message-State: AHQUAuaEv2wiJ+vYfVKd49fELMwnOnW9Lg4ZYFwgZ7FMHu2c2gGyEdB3 XkfFxL69jtqK810trCfY3hPvQcQaPB+ZhJXwd7jptxJF X-Google-Smtp-Source: AHgI3IY4U4xHZcDBw8ewZoL6FYQneWxMdbJEe56k7ix55D2e3b+nZGyIM1TxnIR9lvIJEOC4QYU4Gl3p9450kzABs3Y= X-Received: by 2002:a25:d64e:: with SMTP id n75mr9659716ybg.199.1551120278081; Mon, 25 Feb 2019 10:44:38 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Christopher Wood Date: Mon, 25 Feb 2019 10:44:27 -0800 Message-ID: To: "" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Call for Adoption: TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key 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, 25 Feb 2019 18:44:42 -0000 It looks like we have consensus to adopt this as an experimental WG item. Russ, please submit the draft as draft-ietf-tls-tls13-cert-with-extern-psk. Thanks, Chris, Joe, and Sean On Sun, Feb 10, 2019 at 1:39 PM Christopher Wood wrote: > > Given the low amount of responses, we=E2=80=99re going to extend this ado= ption > call for another two weeks. As a reminder, if you would like for this > draft to become a WG document and you are willing to review it as it > moves through the process, then please let the list know by 2359UTC > 20180222. If you are opposed to this being a WG document, please say > so (and say why). > > Thanks, > Chris, Joe, and Sean > > On Fri, Feb 8, 2019 at 8:58 AM Eric Rescorla wrote: > > > > I'd like to hear from some people who plan to implement and deploy this= . Absent that, I'm not sure we should adopt it. Code points are free, so it= doesn't need to be a TLS WG item unless the TLS WG and community are going= to do substantial work on it. > > > > -Ekr > > > > > > On Fri, Jan 25, 2019 at 10:12 AM Christopher Wood wrote: > >> > >> At the TLS@IETF103 session, there was interest in adopting > >> draft-housley-tls-tls13-cert-with-extern-psk as an experimental WG > >> item, provided that it's limited to external PSKs with certificates > >> for the initial handshake. This email is to determine whether there is > >> WG consensus to adopt this draft (as is) as a WG item. > >> > >> If you would like for this draft to become a WG document and you are > >> willing to review it as it moves through the process, then please let > >> the list know by 2359UTC 20180208. If you are opposed to this being a > >> WG document, please say so (and say why). > >> > >> Thanks, > >> Chris, Joe and Sean > >> > >> _______________________________________________ > >> TLS mailing list > >> TLS@ietf.org > >> https://www.ietf.org/mailman/listinfo/tls From nobody Tue Feb 26 12:54: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 27BF0129741 for ; Tue, 26 Feb 2019 12:54:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (1024-bit key) header.d=ra.rockwell.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 G6NsyGMlepeQ for ; Tue, 26 Feb 2019 12:54:22 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-eopbgr810079.outbound.protection.outlook.com [40.107.81.79]) (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 38AB712941A for ; Tue, 26 Feb 2019 12:54:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ra.rockwell.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=p6vSBy3SKXr8T79hZP3f+mlXj0xd/eL6VFE2WmyeoiM=; b=a8BN2b42X0T5HXbrIbUsr5GcZa3nwqfmAV0TiwQWSkdc4EC7axC8tKK0s6gxeIdJMHSXsnQ+ln8AqlaREUtbDt2SKtBzxHmpRVEGHrfmVYsY1tLX9gIpmJKRi//ATyIxftHdXjjUh7NoHvRnwr1fBqgwSvAiGTtDoR8payw+DSI= Received: from BN6PR2201MB1092.namprd22.prod.outlook.com (10.174.88.29) by BN6PR2201MB1441.namprd22.prod.outlook.com (10.174.90.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.14; Tue, 26 Feb 2019 20:54:20 +0000 Received: from BN6PR2201MB1092.namprd22.prod.outlook.com ([fe80::dd5e:b340:8fa8:b113]) by BN6PR2201MB1092.namprd22.prod.outlook.com ([fe80::dd5e:b340:8fa8:b113%5]) with mapi id 15.20.1643.019; Tue, 26 Feb 2019 20:54:20 +0000 From: Jack Visoky To: "tls@ietf.org" Thread-Topic: Authentication Only Ciphersuites RFC Thread-Index: AdTOFIIaiE+qoBOKQdSotuuQ5A30qA== Date: Tue, 26 Feb 2019 20:54:20 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [205.175.250.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bac8cf07-f13f-443f-9840-08d69c2c94a7 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7153060)(7193020); SRVR:BN6PR2201MB1441; x-ms-traffictypediagnostic: BN6PR2201MB1441: x-ms-exchange-purlcount: 1 x-microsoft-exchange-diagnostics: =?us-ascii?Q?1; BN6PR2201MB1441; 23:qvpsGquzOwOs7m4jAy3f5i9gfZmgjI9EAKgCBYK?= =?us-ascii?Q?V6xeQR7OtCBIE1j2RhTMo/uv0fftLkXn/XAYIiieoGWUi/Cvh/f8DdS5uadT?= =?us-ascii?Q?Z3Dms5UXpIx1e5VSoHpwRj9+ABcFQ9nBq1MkD+n6PwVM6tIC9ppy6fXv+pxj?= =?us-ascii?Q?CgNszF+ymlV31Tze/UOFdSdHhuXCXWicUhjFEIv8gM26MN/DP1GpU5AVWebX?= =?us-ascii?Q?NvbJnOKh2Jn52ihg9097ouopraw6cTyJbZwByXPa6vukH7WRTfNMsB/4OmW/?= =?us-ascii?Q?fz0bCzlVOe+bCWjkVTXIXRrgYjqEo5p5FF8XeTtL7PNSPiAlzzQ3TTd7YpUz?= =?us-ascii?Q?pEO2MnUGasK167WTWDqG5AicmqUtN3/XN+sCulwEwAsFQhajreb0dgv2oovt?= =?us-ascii?Q?SqUg94ubNv2gSBLejjGue9bER5RYWJZvEa4IXxjwn5eNu915dUJBUje5hFN3?= =?us-ascii?Q?wkGLaNu+Pjhl0lyHD9pXjDDAJT6KQhSQIqcetEyvw56tKk2W6Yx+tFJ38yXF?= =?us-ascii?Q?tEfmdcr9spofF/SSVBB/msbyzlT1d3SplCIMKtND2Y/XZ2lgOXur7hAhUG/o?= =?us-ascii?Q?VPPEU1GtFOgYcekAinmmRwUJi7sFLXMB4HEGApkzMmxl4FobdJzCcIU+H7CC?= =?us-ascii?Q?muurLNHKhJ1uXHMT147uQu1X0JwIr7t5OvdFxnhYHaL+mWHHgQFKLNRs4xFZ?= =?us-ascii?Q?uVPf1MrgeRgfjd8MwLghZGyHmm5FD+5a2x3y3JXBjseGfrUSiwodWk8EjjRn?= =?us-ascii?Q?TAuiN3GIcsAnx+S2LGRc4IMM4kvrUfuYe1RlHAkA2zxlrze/JBoUFpuEOieN?= =?us-ascii?Q?ARDmT+LWoScgQNhU5c7gIBGxL5k9XbJlTntYoMabRKpCKStpdGPVIpFbz3+y?= =?us-ascii?Q?gP6udhfljfaX4uQms5m0mCqzaxuoIiOIdPcf3zerYVYUHgbxOFHbt7AJyE35?= =?us-ascii?Q?321r7uW7IB0oRIbskp9Bb9Wx5NTPfNeaPjJ1nBwBoTZH6Ml7a4tlz/DXuEEt?= =?us-ascii?Q?TkZTz05auE7WjvkLuXxYenGov9xrKJ2IaIvItewdATNYDKMatU3CcNlfyxk7?= =?us-ascii?Q?/PQrMIn/jrVLiTJ/L0y0kpJcu5XZL9jQzuceYzsWgUAd02gEoLg16cwdRJrx?= =?us-ascii?Q?rj4GPFjlPBWqXmcoioixWCDNWU2kn5EyBXGwWeHpeUfshv7eIlNnTFKcsX4T?= =?us-ascii?Q?g7nLYEWzuY6IzwN//fmip9vuMAtty9vRBmFvn4TgQyzohJU0AZmT6VoxTY2z?= =?us-ascii?Q?+HRH6cDuBCWtEwkoqMH/uPJgD8WFDj2ShdEBz62XGsNeR6ZvkQm/zjbDWW2h?= =?us-ascii?Q?cQfX1bC3Z4qmNib3AnoV4Ybdo2PRpaJj3HI7xT64AupPlXF2qnDjenk4EVpB?= =?us-ascii?Q?VI6SCAQ=3D=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 096029FF66 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(136003)(376002)(366004)(346002)(39860400002)(189003)(199004)(1730700003)(33656002)(86362001)(2351001)(106356001)(14444005)(256004)(105586002)(2501003)(4326008)(3846002)(71200400001)(74316002)(6116002)(478600001)(71190400001)(25786009)(790700001)(7736002)(53936002)(316002)(68736007)(66066001)(186003)(8676002)(476003)(81156014)(5660300002)(14454004)(26005)(6436002)(966005)(8936002)(6306002)(6916009)(606006)(52536013)(54896002)(486006)(4744005)(2906002)(7696005)(3480700005)(102836004)(99286004)(6506007)(97736004)(81166006)(6346003)(55016002)(5640700003)(236005)(9686003); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR2201MB1441; H:BN6PR2201MB1092.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ra.rockwell.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=jmvisoky@ra.rockwell.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: tVlIU4Q8JEBzEbQa85J6BuXr2joeZwITxTnsoHCVyMZITRYyYR//5C6s+5PHyZcpy9FduPBAOumRPsHvPsfh5wkwblyvseZLtK7Gsw2uduL7a/xqKoigVdzGf408qpZT41d6QB8cYrSp/3c4lW98a18rIkMRfVgRLaIPk/J4U24wh4G5r5LkZyhWar87YjemNeK28s8EBXleDO4vpaBfKjTm1GzQldTe3qD2JKn51LwsuuQzeDR6KoP8tXUd4PHArFYZoJYYtb2FSU+07U8Pqv0wCdXut3Te9fJUw4r1LiLuqOHQc8a3fI/gwmMZy9DDK0NZu8v6FfdB1TbPY4KCyPXJ1SQlcAAcojvJTo5GdUGVEVHDfe4l6mY6r+Tui2Wk5lbosX3V/TNsFGJYjTp0WhDCPZFRVW9veVBHCYhReFE= Content-Type: multipart/alternative; boundary="_000_BN6PR2201MB1092B0FAD8AB0334CF151996997B0BN6PR2201MB1092_" MIME-Version: 1.0 X-OriginatorOrg: ra.rockwell.com X-MS-Exchange-CrossTenant-Network-Message-Id: bac8cf07-f13f-443f-9840-08d69c2c94a7 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2019 20:54:20.3507 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 855b093e-7340-45c7-9f0c-96150415893e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR2201MB1441 Archived-At: Subject: [TLS] Authentication Only Ciphersuites RFC 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, 26 Feb 2019 20:54:25 -0000 --_000_BN6PR2201MB1092B0FAD8AB0334CF151996997B0BN6PR2201MB1092_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable TLS Colleagues, If you recall we discussed a draft for authentication only ciphersuites ove= r email back in August of 2018. We've since made some updates to that draf= t. We also have gotten IANA assignments to the authentication only ciphers= uites for TLS 1.3 and have updated the draft to reflect the new assignments= . To that extent, as the IoT community is looking to adopt these ciphersuites= , we would like to solicit review of the draft: https://tools.ietf.org/html/draft-camwinget-tls-ts13-macciphersuites-02 and request that it be published as informational draft given that the IoT = forums are looking to adopt its use and the draft can serve as the guide fo= r use and interoperability. Thanks and Best Regards, --Jack (and Nancy) --_000_BN6PR2201MB1092B0FAD8AB0334CF151996997B0BN6PR2201MB1092_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

TLS Colleagues,

If you recall we discussed a = draft for authentication only ciphersuites over email back in August of 201= 8.  We've since made some updates to that draft.  We also have go= tten IANA assignments to the authentication only ciphersuites for TLS 1.3 and have updated the draft to reflect the ne= w assignments.

To that extent, as the IoT co= mmunity is looking to adopt these ciphersuites, we would like to solicit re= view of the draft:

   

    https://tools.ietf.org/html/draft-camwinget-tls-ts13-macciphersuites-02=

   

and request that it be publis= hed as informational draft given that the IoT forums are looking to adopt i= ts use and the draft can serve as the guide for use and interoperability.

 

Thanks and Best Regards,

 

--Jack (and Nancy)

 

 

--_000_BN6PR2201MB1092B0FAD8AB0334CF151996997B0BN6PR2201MB1092_-- From nobody Tue Feb 26 13:03: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 BE4411288BD for ; Tue, 26 Feb 2019 13:03:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_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 0W5hTQIsHIj4 for ; Tue, 26 Feb 2019 13:03:39 -0800 (PST) Received: from zucker2.schokokeks.org (zucker2.schokokeks.org [178.63.68.90]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D56812941A for ; Tue, 26 Feb 2019 13:03:38 -0800 (PST) Received: from computer ([2a02:8109:83c0:4bfd:dc27:39b2:705d:72e7]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1.3, 256bits, TLS_AES_256_GCM_SHA384) by zucker.schokokeks.org with ESMTPSA id 00000000000000C7.000000005C75A9A8.000077BE; Tue, 26 Feb 2019 22:03:36 +0100 Date: Tue, 26 Feb 2019 22:03:35 +0100 From: Hanno =?iso-8859-1?q?B=F6ck?= To: tls@ietf.org Message-ID: <20190226220335.0d75968f@computer> In-Reply-To: References: X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Authentication Only Ciphersuites RFC 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, 26 Feb 2019 21:03:42 -0000 I think I have raised my concerns before, but I have serious doubts there's real need for such ciphersuites. The reasoning seems to be that performance constrained devices are unable to do "normal" TLS. I don't have benchmarks, but it's my experience that people vastly overestimate the costs of symmetric encryption operations (by far the largest computational cost of TLS is the asymmetric handshake). I wonder if the people who believe they need an authentication only ciphersuite ever ran tests. I also see a non-neglegible risk in standardizing such ciphersuites. Some implementations will end up adding them and coupled with implementation flaws we may end up in a situation where inadvertently insecure ciphersuites are chosen. --=20 Hanno B=C3=B6ck https://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 From nobody Tue Feb 26 13:26: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 C05ED12D7F8 for ; Tue, 26 Feb 2019 13:26:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=ra.rockwell.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 5xf4Vg4_7wE2 for ; Tue, 26 Feb 2019 13:26:47 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-eopbgr790087.outbound.protection.outlook.com [40.107.79.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BB8A12941A for ; Tue, 26 Feb 2019 13:26:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ra.rockwell.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QKKgI8CSfCZAblVTlWsLG5F0ymPCH7EKLKnTbZ7K8yI=; b=VbiTOTfIdxUNUftTIJW5SDd+E1wwCZtnblBeU/73vLk4YFzrrDd+MTbQ+avlp5pmhRBwzoDZ6xMwGLNbx5abOeixfDL6rAieaj9H3SWoL/+u0+JgSa9gxRlwYJh8W9TPwrhwsl2IgiPOM87M/xiWrIsiHYzUZGDcCWzmPNtXTwM= Received: from BN6PR2201MB1092.namprd22.prod.outlook.com (10.174.88.29) by BN6PR2201MB1553.namprd22.prod.outlook.com (10.174.82.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.15; Tue, 26 Feb 2019 21:26:45 +0000 Received: from BN6PR2201MB1092.namprd22.prod.outlook.com ([fe80::dd5e:b340:8fa8:b113]) by BN6PR2201MB1092.namprd22.prod.outlook.com ([fe80::dd5e:b340:8fa8:b113%5]) with mapi id 15.20.1643.019; Tue, 26 Feb 2019 21:26:45 +0000 From: Jack Visoky To: =?utf-8?B?SGFubm8gQsO2Y2s=?= , "tls@ietf.org" Thread-Topic: EXTERNAL: Re: [TLS] Authentication Only Ciphersuites RFC Thread-Index: AdTOFIIaiE+qoBOKQdSotuuQ5A30qAAAjqKAAAB8szA= Date: Tue, 26 Feb 2019 21:26:45 +0000 Message-ID: References: <20190226220335.0d75968f@computer> In-Reply-To: <20190226220335.0d75968f@computer> 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=jmvisoky@ra.rockwell.com; x-originating-ip: [205.175.250.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7f971054-12c8-4e6b-d35f-08d69c311bf6 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7153060)(7193020); SRVR:BN6PR2201MB1553; x-ms-traffictypediagnostic: BN6PR2201MB1553: x-ms-exchange-purlcount: 2 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtCTjZQUjIyMDFNQjE1NTM7MjM6SEdBWW5WejRVRE1pcm1Na3hpbTNNLzl6?= =?utf-8?B?WTliVGV3QWhJMmVyZS9UNHp6bXlFTlRrd0NpWEtYS25ISHN5YjFIdEV4TTM3?= =?utf-8?B?ZWVsVUJYUmR1RVk0eEdhNGQxaEhRY05NRkF1U2pIb2lHWXJvZDRsQXU0R1lo?= =?utf-8?B?YmVYQjBQOTkxSnFuV21YNTVqVXUra1NZd1BjTGw1RmNxRHUwaE1WdzBQNHo3?= =?utf-8?B?eVBqZzZoeXo1dXY2TU1hZHd3ZkxLNEpFcEkwTlNNUTZ1Ykp0VHoraDNGQ0l5?= =?utf-8?B?dXVEY2FuelN4aVFXeThVUTdDT2R3RG1IWUJlT08yN29FZ1BjaHF0R3NpWWs0?= =?utf-8?B?UDN2ajIrNThlaXpuRm1YZFdXaEx4YXB0U3M4MmlsTjc2OHd3Z2pFSnV6dHhi?= =?utf-8?B?ZWZDUnlXNGRkbjgzRWJBMW5FamliZXpjNlFJRHJtOSsxMzFpMDhYRE9GK1Av?= =?utf-8?B?aVZiNEdQQkZkdGtaVjJ1OThPT2NlZ3BLczhnVm0yQjZrTE1UWG5yNGdCc1ZM?= =?utf-8?B?aDFOLzdubjVTVzZhVjhRYkh2Z0N1UkRXZ1ZzaWZCZXNqTDZMRCtJSllSUHUw?= =?utf-8?B?cTI5QTZiMHc0cVl6N01xcSttOEZybk5ud2FvenlOT0xDUzhDR0Q0REF6dVhn?= =?utf-8?B?dTNydzFENjZGcUVDcXRpMmI3L3JCNHBmdCtETU9rNHcxdkRFbkNXeDNWTWdn?= =?utf-8?B?M0tHTlZ3NkdsZWVoMVp6YVdSZDZ0TTRqRzd5UUNJUkJhS0lkaTJOaDZmaG5y?= =?utf-8?B?MG5rUzFpYXlVVXVNWTJXT2hQY3hjRnFzd2dGcld3YkptZ1dMUFcyZEhOWFNa?= =?utf-8?B?dlQxODBaVDNzNkFVQ29kWXgxZGx1K0h5M2crN1NaUFRWNFpTYUtUYjk1ZUlJ?= =?utf-8?B?UC81N0dCMjdqalVDNENhSnJYQlhJUTZDMWFUSDl3NW5PS01IaG5ObzREVVNS?= =?utf-8?B?ZTRvSE5TNlJzZVc5NGJWMHlUNzF2Vkg3Z2wzZFgzRWFSQ0ViYXBZZnQvZ0w0?= =?utf-8?B?MmZYV0lreGEvcU1zM3R3MlE5WTNFbHphcEliVGlIYUNZbElqNWczazl2WXFq?= =?utf-8?B?QmU0Q3pGMU5uR0pLbHI0U1ljM2xvdDZCZ3dkVWE0WHF2bldZSGJMT1VkazlM?= =?utf-8?B?NXBBL1pPa2IzUjIxZkovQXAwRWZWT0xUNzY0dHNsM1VpME55MEY0Zk1xTXpL?= =?utf-8?B?dEl1bXkyWnRLeDNxZU9HejRmQ3pjZEt1Rzg3bTIzbG5CMW5sVWlONkRuSlRS?= =?utf-8?B?bm9Lc1FDdEFrVU1FZXRyVHlXMENsTzkxQ1JwM1NYT2RkMjNHdHVhK1VnREd6?= =?utf-8?B?eU1Vekl1a1dZMTdoQkh5aGdNZEVLY2ZVaVhMQWh2UWNJQzdPWmRoQ0tSQUJZ?= =?utf-8?B?YS9mRWk2RFExQ1lKRjZKQ3VEWU1aS3BRVGlEU3YxclJwd3FEQ2FLNXJwU2VR?= =?utf-8?B?VjFSZ1dNTHRkemxTM254dGVwYnNjMGc3c21QK3JjU0pkS1F1cE5hWXd1MEpS?= =?utf-8?B?K2pCWG9OL0dLZUpNNTdDQVdRdUlLTi9ya2Q3UDMzd25EdGVCMGxlMWVpNWtT?= =?utf-8?B?Q1NVZjJvSEd0Rkc5eHNLUXJYSmVxOURnb2xTMFdMMVJGVEFvY1N5L0xiWUpL?= =?utf-8?B?Y3VqSkhFVkNHakRWTVNoRFNEU0RhMk5jZ3A5OGoxM0wxSHBEN0liOG5pc0Rj?= =?utf-8?B?SjBEZnhBYlpHSklCYTZPVUVaZWhOcWw5NGJJK0MyUS95clNEaUdJakcvRlN4?= =?utf-8?B?N1ZJOXIvUVRVbnZIaUJjd1o1eWxnb01MVU8zR3BFK2VHTzkxcGh4K0swTUVi?= =?utf-8?B?ME1xQlA5N09VQXRlQ0lDVlNhVXBrVkFCT1ZiTUliTm80TUpDZz09?= x-microsoft-antispam-prvs: x-forefront-prvs: 096029FF66 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(136003)(366004)(39860400002)(376002)(346002)(189003)(199004)(13464003)(54094003)(6436002)(26005)(7736002)(53936002)(446003)(55016002)(74316002)(71200400001)(9686003)(6306002)(53546011)(6506007)(102836004)(476003)(186003)(14444005)(76176011)(86362001)(25786009)(229853002)(71190400001)(305945005)(52536013)(5024004)(486006)(11346002)(6246003)(256004)(5660300002)(316002)(2906002)(97736004)(7696005)(110136005)(966005)(66574012)(105586002)(106356001)(99286004)(3846002)(6116002)(81166006)(81156014)(478600001)(68736007)(2501003)(14454004)(33656002)(8676002)(8936002)(66066001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR2201MB1553; H:BN6PR2201MB1092.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ra.rockwell.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: /VQiundTs3McbWPA+QNTos/d81WOOQ9/245BIgehvzbSFbtBVK2L16bM//aDaLiERGKCKlDuzHJ9qb15ndcEUQuRJiMqn7MKR3QL9Qyj/2/RAC+v5w7Tb4J0USd0hQfTv9vXE/gzq7nx7X0AHb8za4zwxHDY/VxJ9dfED3Ha/QQH1CD1CvLmPJ7Xsn7Jlsb5FmLYFK4yy1i6tFgY7XKv2ZPYInAkJigLEogFn84gs9YTfkaeTVhZvPuvfpBPEkW40vUjB2t+E8t86J0WDzZNGmeqSfcE9vJfuuKKoAF0yrrQE/2XN/zzTVV314kw9On2E/BOx6WrxHVzl6EEP5BhEyqo6HZzG22kPKBJIk9XrP3GMReUyNClSMy1NSWMqQYdaffeXHz75p8A42VKPme5XDnlx0sljTnwOZbe79OS9VI= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ra.rockwell.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7f971054-12c8-4e6b-d35f-08d69c311bf6 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2019 21:26:45.3473 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 855b093e-7340-45c7-9f0c-96150415893e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR2201MB1553 Archived-At: Subject: Re: [TLS] EXTERNAL: Re: Authentication Only Ciphersuites RFC 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, 26 Feb 2019 21:26:51 -0000 SGkgSGFubm8sDQoNCldlIGhhdmUgZG9uZSB0ZXN0cyBvbiB0aGlzIGFuZCBpdCB0aGVyZSBpcyBh IGRpZmZlcmVuY2UuICBGb3Igc29tZSBpbmR1c3RyaWVzIChpbmR1c3RyaWFsIGF1dG9tYXRpb24p IHRocm91Z2hwdXQgaXMgdmVyeSBzZW5zaXRpdmUgc28gd2hhdCBtaWdodCBhcHBlYXIgYXMgYSBz bWFsbCBkaWZmZXJlbmNlIGNhbiBhY3R1YWxseSBiZSBxdWl0ZSBzaWduaWZpY2FudC4gIE9uIHRo YXQgc2FtZSBub3RlLCB5ZXMgeW91IGFyZSBhYnNvbHV0ZWx5IGNvcnJlY3QgdGhhdCB0aGUgYXN5 bW1ldHJpYyBoYW5kc2hha2UgaXMgZmFyIG1vcmUgY29tcHV0YXRpb25hbGx5IGV4cGVuc2l2ZS4g IEhvd2V2ZXIsIHRoaXMgZ2VuZXJhbGx5IGhhcHBlbnMgYXQgdGhlIHN0YXJ0IG9mIGEgY29ubmVj dGlvbiB3aGVyZSB0aW1pbmcgaXMgbGVzcyBzZW5zaXRpdmUuICBPbmNlIHRoZSBhcHBsaWNhdGlv biBJL08gaXMgYWN0dWFsbHkgYmVpbmcgc2VudC9yZWNlaXZlZCBpcyB3aGVuIHRoZSBwZXJmb3Jt YW5jZSByZWFsbHkgYmVjb21lcyBzZW5zaXRpdmUuIA0KDQpQb2ludCB0YWtlbiB0aGF0IHRoZSBj aXBoZXJzdWl0ZXMgY291bGQgYmUgdXNlZCB3aXRoaW4gYW4gYXBwbGljYXRpb24gd2hlcmUgaXQg aXNuJ3QgYXBwcm9wcmlhdGUsIGhvd2V2ZXIgdGhpcyB3b3VsZCBoYXZlIHRvIGJlIHdlaWdoZWQg YWdhaW5zdCB0aGUgYmVuZWZpdCBvZiBpbmR1c3RyaWVzIGFkb3B0aW5nIFRMUyAxLjMgYW5kIHNl Y3VyaW5nIHRoZSBtYW55IElvVCBhcHBsaWNhdGlvbnMgdGhhdCBkZXNpcmUgdGhpcy4gIFRoaXMg cHJvYmFibHkgZ29lcyB3aXRob3V0IHNheWluZyBidXQgb2YgY291cnNlIHRoZSBiZXN0IGxpbmUg b2YgZGVmZW5zZSBpcyB0byBwcm9wZXJseSBkZXNpZ24sIGJ1aWxkLCBhbmQgY29uZmlndXJlIHRo ZSBpbXBsZW1lbnRhdGlvbi4gIEkgcmVjb2duaXplIHRoYXQgZG9lc24ndCBjb21wbGV0ZWx5IG9i dmlhdGUgeW91ciBwb2ludCBidXQgaXQgZG9lcyBzZWVtIHJlbGV2YW50Lg0KDQpUaGFua3MsDQoN Ci0tSmFjaw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogVExTIDx0bHMtYm91 bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEhhbm5vIELDtmNrDQpTZW50OiBUdWVzZGF5LCBG ZWJydWFyeSAyNiwgMjAxOSA0OjA0IFBNDQpUbzogdGxzQGlldGYub3JnDQpTdWJqZWN0OiBFWFRF Uk5BTDogUmU6IFtUTFNdIEF1dGhlbnRpY2F0aW9uIE9ubHkgQ2lwaGVyc3VpdGVzIFJGQw0KDQpb VXNlIGNhdXRpb24gd2l0aCBsaW5rcyAmIGF0dGFjaG1lbnRzXQ0KDQoNCg0KSSB0aGluayBJIGhh dmUgcmFpc2VkIG15IGNvbmNlcm5zIGJlZm9yZSwgYnV0IEkgaGF2ZSBzZXJpb3VzIGRvdWJ0cyB0 aGVyZSdzIHJlYWwgbmVlZCBmb3Igc3VjaCBjaXBoZXJzdWl0ZXMuDQoNClRoZSByZWFzb25pbmcg c2VlbXMgdG8gYmUgdGhhdCBwZXJmb3JtYW5jZSBjb25zdHJhaW5lZCBkZXZpY2VzIGFyZSB1bmFi bGUgdG8gZG8gIm5vcm1hbCIgVExTLiBJIGRvbid0IGhhdmUgYmVuY2htYXJrcywgYnV0IGl0J3Mg bXkgZXhwZXJpZW5jZSB0aGF0IHBlb3BsZSB2YXN0bHkgb3ZlcmVzdGltYXRlIHRoZSBjb3N0cyBv ZiBzeW1tZXRyaWMgZW5jcnlwdGlvbiBvcGVyYXRpb25zIChieSBmYXIgdGhlIGxhcmdlc3QgY29t cHV0YXRpb25hbCBjb3N0IG9mIFRMUyBpcyB0aGUgYXN5bW1ldHJpYyBoYW5kc2hha2UpLiBJIHdv bmRlciBpZiB0aGUgcGVvcGxlIHdobyBiZWxpZXZlIHRoZXkgbmVlZCBhbiBhdXRoZW50aWNhdGlv biBvbmx5IGNpcGhlcnN1aXRlIGV2ZXIgcmFuIHRlc3RzLg0KDQpJIGFsc28gc2VlIGEgbm9uLW5l Z2xlZ2libGUgcmlzayBpbiBzdGFuZGFyZGl6aW5nIHN1Y2ggY2lwaGVyc3VpdGVzLg0KU29tZSBp bXBsZW1lbnRhdGlvbnMgd2lsbCBlbmQgdXAgYWRkaW5nIHRoZW0gYW5kIGNvdXBsZWQgd2l0aCBp bXBsZW1lbnRhdGlvbiBmbGF3cyB3ZSBtYXkgZW5kIHVwIGluIGEgc2l0dWF0aW9uIHdoZXJlIGlu YWR2ZXJ0ZW50bHkgaW5zZWN1cmUgY2lwaGVyc3VpdGVzIGFyZSBjaG9zZW4uDQoNCi0tDQpIYW5u byBCw7Zjaw0KaHR0cHM6Ly9oYm9lY2suZGUvDQoNCm1haWwvamFiYmVyOiBoYW5ub0BoYm9lY2su ZGUNCkdQRzogRkU3Mzc1N0ZBNjBFNEUyMUI5Mzc1NzlGQTU4ODAwNzJCQkI1MUU0Mg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVExTIG1haWxpbmcg bGlzdA0KVExTQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3Rscw0K From nobody Tue Feb 26 14:20: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 D811F1200D8 for ; Tue, 26 Feb 2019 14:20:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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] 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 7ibyxPx74R9r for ; Tue, 26 Feb 2019 14:20:33 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98CA812D4F3 for ; Tue, 26 Feb 2019 14:20:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5CF55BE53; Tue, 26 Feb 2019 22:20:30 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLAm2cFmcplo; Tue, 26 Feb 2019 22:20:28 +0000 (GMT) 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 08B92BE4C; Tue, 26 Feb 2019 22:20:28 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1551219628; bh=MrianR3BlLz/V6EOvIUTiGbqDS+232bzY5n+o/8uxQM=; h=Subject:To:References:From:Date:In-Reply-To:From; b=pBOu8SoIfG2ifRyvS+HF36/shSl03XRRxAxeoSrww2NiRu/kPsGcOdJIvIld+g0et JU78Vdh+y4qt0Tj+3PX4EC4KYg0+YSFSsCvq4zOJN6J4WaVGhfmdDHUy77KIIt8MeQ Mrdgy1pTvwFyK0Quy9jW4G+R8LPnVw8Kq3AzQ2EE= To: Jack Visoky , =?UTF-8?Q?Hanno_B=c3=b6ck?= , "tls@ietf.org" References: <20190226220335.0d75968f@computer> 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: <2707f00f-70da-f57c-18a3-49b22652adb8@cs.tcd.ie> Date: Tue, 26 Feb 2019 22:20:26 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="T3c2d8wRLLWftnVz5ApW9nkzvkipPhyuD" Archived-At: Subject: Re: [TLS] EXTERNAL: Re: Authentication Only Ciphersuites RFC 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, 26 Feb 2019 22:20:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --T3c2d8wRLLWftnVz5ApW9nkzvkipPhyuD Content-Type: multipart/mixed; boundary="3LJ2uda7ewofxZuWKVg5KM1oh3Vq8lyJd"; protected-headers="v1" From: Stephen Farrell To: Jack Visoky , =?UTF-8?Q?Hanno_B=c3=b6ck?= , "tls@ietf.org" Message-ID: <2707f00f-70da-f57c-18a3-49b22652adb8@cs.tcd.ie> Subject: Re: [TLS] EXTERNAL: Re: Authentication Only Ciphersuites RFC References: <20190226220335.0d75968f@computer> In-Reply-To: --3LJ2uda7ewofxZuWKVg5KM1oh3Vq8lyJd Content-Type: multipart/mixed; boundary="------------904EF7662283FA809A6EACBB" Content-Language: en-GB This is a multi-part message in MIME format. --------------904EF7662283FA809A6EACBB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable FWIW I tend to agree with Hanno. Sending this to the ISE is likely better if an RFC is even needed. We already opened up the ciphersuite registration process to allow this kind of thing without the WG having to try (and sometimes fail to) reach rough consensus on things like this. On 26/02/2019 21:26, Jack Visoky wrote: > Hi Hanno, >=20 > We have done tests on this and it there is a difference. For some=20 > industries (industrial automation) throughput is very sensitive so=20 > what might appear as a small difference can actually be quite=20 > significant. On that same note, yes you are absolutely correct that=20 > the asymmetric handshake is far more computationally expensive.=20 > However, this generally happens at the start of a connection where=20 > timing is less sensitive. Once the application I/O is actually > being sent/received is when the performance really becomes > sensitive. >=20 > Point taken that the ciphersuites could be used within an > application where it isn't appropriate, however this would have to be > weighed against the benefit of industries adopting TLS 1.3 and > securing the many IoT applications that desire this. That last appears to contradict the text in the draft itself that says that these ciphersuites are for niche use cases. For non-niche cases we really don't want to see use of these ciphersuites. Cheers, S. > This probably goes without saying but of course the best line of > defense is to properly design, build, and configure the > implementation. I recognize that doesn't completely obviate your > point but it does seem relevant. >=20 > Thanks, >=20 > --Jack >=20 > -----Original Message----- From: TLS On > Behalf Of Hanno B=C3=B6ck Sent: Tuesday, February 26, 2019 4:04 PM To: = > tls@ietf.org Subject: EXTERNAL: Re: [TLS] Authentication Only=20 > Ciphersuites RFC >=20 > [Use caution with links & attachments] >=20 >=20 >=20 > I think I have raised my concerns before, but I have serious doubts=20 > there's real need for such ciphersuites. >=20 > The reasoning seems to be that performance constrained devices are=20 > unable to do "normal" TLS. I don't have benchmarks, but it's my=20 > experience that people vastly overestimate the costs of symmetric=20 > encryption operations (by far the largest computational cost of TLS=20 > is the asymmetric handshake). I wonder if the people who believe > they need an authentication only ciphersuite ever ran tests. >=20 > I also see a non-neglegible risk in standardizing such ciphersuites. > Some implementations will end up adding them and coupled with=20 > implementation flaws we may end up in a situation where > inadvertently insecure ciphersuites are chosen. >=20 > -- Hanno B=C3=B6ck https://hboeck.de/ >=20 > mail/jabber: hanno@hboeck.de GPG:=20 > FE73757FA60E4E21B937579FA5880072BBB51E42 >=20 > _______________________________________________ TLS mailing list=20 > TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls=20 > _______________________________________________ TLS mailing list=20 > TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls >=20 --------------904EF7662283FA809A6EACBB 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 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5tDJTdGVwaGVuIEZhcnJlbGwgKDIwMTcp IDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJCZQmAAUL CQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1yw aps8HGUNhLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG +48od+Xn7qg6LT7GrHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXk kTFaSGYJj3yIP4R6IgwBYGMzDXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRr pZtXB1XQc23ZZmrlTkl2HaThL6w3YKdiTi1NbuMeOxZqtXcUshII45sANm4HuWNT iRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS3MmGgVS4ZoX8+VaPGpXdQVFy BMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml3OEuIQiP2ehRt/HV LMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi2/Jrsz6M zh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6 TzKjGjruq8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxIkBHAQQAQgABgUCWj1SoAAK CRAvPIc2gF+NovMcCACVZPo1cQa3D+vWaIo0ZyinO/MgtD2gHysoj1T0Qvq05//L ZXmhh578bJANvdl2g/HFhhwl/5HKIfWcyipQhmJklp/dsleKcNnn4B18T75RHY0G +po3ILq7evbiOjUH+xqApti1aCxi1GocsPghaLfsxmtXKMG4Xu7XhDTv66GOrqZf Y7+0ekJjD9Dza1t5NE/JR/VZA4B8PWR8Glb0+8C9rkjD0VZ5ekJdHPDGcJmFh8Z+ q25LDoI8Fgt1uKSowvoVnsQO5MFv/y6bXArtj1uB4hAL4JiOFgHlFdrW0MlFpvYm ziW4K9JHTD8KAfDbrb3e2W97ZDpROuYfE/lTbYOWiQI9BBMBCAAnBQJaPVAyAhsD BQkJlCYABQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEFqy+vF7Fyvq0mkP/ius gsf6Z4/Tu+vHzBbl5i6oKI8ZieH8JfEgXx4ut9t7l3hBGC2r7DpR5A8zLMpEhGIK gFcHagksFkfLEE/FmWDfd1MysQafxBYrHaI27P2tkxfI5JYV6247TV39pQ93kGds tsjIrmh/zEJCVczoofxtz72BDt51H2Z8tN28F/YVHnbaGDwFEEzWKYpze87y/f36 ogcdGO6LDEEEIA6Ee0dGxleuKlLS4UDTt0zjo6L8TyiyPHp9C3+UfnP8837Zp3Fh KstIBd+vWgPdHFg2G5aDIYUvrj9UJBvVgaN/RnkwE+dab2OBSg5jkr141JLQvzdZ 4mOUXn5D9Y6AH6tvj0+ubYMV6j35L1/ZXncuXPVYiylcmDp/6f2WYcT3gx9CPUYA cLMjQV4vX2W8z4uEPyMlIJuGsLf7KhvLL8BQ6zlncT6eONfUUX9UJUCzqI5rqL5c b5jWGHeKvbLWRyQnlq5PXQxJTwYRm71rJTgzejc33LE6Nqg/Q25Dgwwsv+f+7i73 gB5loc80Fef+FV9VFGalFe0Yq8m0UASmkYRh7MH5ssoibpeWk+SGfBjOV4tnsAwR yjYLpAzxA8HeDcmlLeypGEDmsQ/iUvXoGaKOYX4Ieg8T/PCAplsqnJUOq8hbkgOC 98gLZfiltkNG8YhQpoZIHj6SxmBRSc3K99CvanuOiQIzBBABCAAdFiEEfhcKBFyE z0YOK3mgEO952f2DUxIFAlu3JJsACgkQEO952f2DUxJ4qRAAmbjiO3WTAeBCB4ME p2N2+XQCMTTFURDGuJnqU/+X//fhhPRq4V/OxgisKFKlBcAS2hsECvg6HDVSz4Fl 74fk/y+botG4/CjMLdKPB9fgh5zz72i3q0hWDixt50NKBv8IIVWOyYgZxDU/vcks lMEnqbFgJX+CfdALpvAM4WjuQP0UMcKNE3xd+EdDhD1xjK3Tq4XfWob9q6aBZgL2 B4IaADCIeDDE1hv0agnSJmMJE7Bti8tNxCCxVRbZtOaxVHXdRUoOx2XTaxFXupxV hbpHRrdFrwq51f6e3bkfkNEZ3fzYpnlbynJ2zL++JO8P3Pq/S6UKEFjEB50i8YgK WuFvGUsQ+YiDgiZU4saqxSBWbfYn3lY6MSSTg8RnXbFIMG3CFImqYk1uhaV+bDjc p0htjzM2F98g7c3o7sWx0bGarId4uhOmpj7JJVQ+lu7Jby6Ocj8n//7qF1Nn11Cw QlCVaeAq5Y5DmZrnww9I3zzOWWyqFkAVCM3GqeRLMvplD6/+O+5FF7XoHzQB47nk OyZtawy/9gssPWZKLv4qHLYS0wGGCiNbCsYy90s3pfeafM0kSxxjIvEz21KT6LJI /awu2ErQFWCkDMFJ1p/97MjPrQ/6d4cPO140V/wyfuWaBiTVqa9mgnb2zn6fYfDH JEvl1UzIx3JCae25tty1+qtnS0i0LlN0ZXBoZW4gRmFycmVsbCA8c3RlcGhlbkB0 b2xlcmFudG5ldHdvcmtzLmNvbT6JAj0EEwEIACcFAlo9UVoCGwMFCQmUJgAFCwkI BwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+o7HBAAxHAdFkBGZ9gJK8w7 NUYS9C6enGYtAYoKH5G3Bn3YScjErNfQtHYb53KwBQpVSOv1HcN8hbQ8mLTgn9lt zNwNSuv0XxIswi807HRSIZ4vYDiS5VKV1YkLYK5bLY5O4alVdzqM+AZQqkuHBu63 6n+C0ED6UwLhVBFfSNvBQVAdoq6gvr+IE8rCIKTMNGwNcgVPbF+YxP7UZM6p7s2a 5MIqGw7URSfaqfuztibXGOBLFbSwLGqHSSnOXBfEeDrwdZ+ur8cXIIPRIeCTVmeO 8bGgpgBqNQXG9oyGN+TrYAC+4Ahi0UjCk7QGj8tf3xICKoQpYyfceNBZJ/969gV9 tVgvRxUjxUwc9kZbi0c8XYMTq5GCvBIh1D6BOW9QBM2SsNgG3l36+e3+c2LDdyKn 20C1IzGLVDdcCtz42/onQ/e9sMlzFrfLjs5SO2/TnLvp2JtsIQXyb/T5qd0GE5j8 /iwfZR+uVTVVEsUl1a+Yllzt6sdR7RIhhKpKaKzEAk4d0+VHdz7zEkQRRSjbPVoS fy8c/kld9Fi8Buna+ZkKpcwIW+D4XP83pGcl0XUv6AyqwS1LnEt+jv/+PSXskYtU Lzn8Z35iKkSAH/5Nz6GCZk6ORPNv/6+UI92BpUbu/G2tBwK8bPgAg+gJxBx3G7MK W7VRCmM5UrtAK9A3O70VjPyMkHSJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLC LAf/X/9vRTZWtwSXxiBCA54a6hg9IvW0mvPUqgXfvrhtOk0IFucLKrTXK8J/NcmU 6ulxOovVbQ+Bin6gtHeCmSa/W523g/NXCOuFTnS/MyVibNL4+RCFwqGysl++Cm+L nj1MmasE9kO+CNdervx8APfxV7D6OYrG4eGag+LdFR6VpJn6tRT0/WvyT8l+Oqiq gdhXHv+0MvkkD9TX5LlJW4VB/yRvWkkmL5N5c5zYh+NcfTPhQ5S9dOorVzrm65d6 Itn0937Ennau7s7fiFdA0BHjWqEAFLsBIXQfCFjjKjdsKA4xlSiX7X7ElmPYpWa5 wwTQ66dL0anMd9y1DJCMOHe4gYkCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9 g1MSBQJbtyScAAoJEBDvedn9g1MSY7sP+gKR0rFU1g+GtB+hSdtwPRbacvml2eL2 Jc5Eq37J9hAqxHyt5V0If7s8IyVA2GXgdfwULBWbXGDUDiUkh20OPQRUS8G9Sf8A WRuG25q5C8ZzWygykL88RKXJZDFtA49CeqO5Bq5syBhq4QfiSTffQHIp3h0boPGU hSBEUQpooMXYQClNARQ+z/uRzR5bUi9wxdXNnxTn9ia4ASlaBPvUYTGY1jW2HrRR SwpI12+UaWsvc3jJtQ8X0kxgJ7jsFF1uqquIZ5eflQv+PHHg2RJSy37u0UFGb+OK ZEkzlmbPokKCYhzBR5PcD6sgdlaJNcidmto9u1oV6yZT8J2W4CTuUclgxt6f3lZq ZeVLnNnbHyKUdeypwLlqYISulfnMhZ3A6Bgpf2BtjL6KJbFtPBYmYdxI+HZyY49u U2ZHhRu+CSQ1y7zGKSX0gRp5hE7+A4XJtsT6lTLhbi9aiZTG1S6zKNhl3qNNzszc r27PrvFiyGhpuYQuzdQl2PMGbOI6Ojif3sab53NO3RLsLOM09wIlr95yKLlkXkUr WcvUJGrw6HKm8j5opXHTwmJOAbDpc6cMDu+ITRu4spdCnQJcE8RkO8tKyaLuh2Gt U5kYSBK97yr5VviX1FK6rY14LLmnE16OPiK2tiVBKy9nGM0DKtY+K9WcoRZ7s/d7 O0bMfzcNPtGLuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiez GPuBHmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9Wf pHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC 6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2 D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFe A7PbTuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ /Vf3vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbpt PEcmoazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKr em5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96 Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYgh x8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQ oqj1gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P /1tF6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8 Wpfdn3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJ gx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5 SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2 oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIA ypqYo3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoM eDQkd0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS /qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZ IMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XO KVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DJ121 -----END PGP PUBLIC KEY BLOCK----- --------------904EF7662283FA809A6EACBB-- --3LJ2uda7ewofxZuWKVg5KM1oh3Vq8lyJd-- --T3c2d8wRLLWftnVz5ApW9nkzvkipPhyuD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlx1u6sACgkQWrL68XsX K+pjlw//Rc5M0uh8IjADWmnxoVnGjbCHfsW9oxVecrEHuwUcNEyGhne3wflboRBg IoiKUbyjd153//CEX/1yaT6mIQK2U9fp13oCxHiMN3Quoz8YcVNK1IAo9BZP5DaA YLU9YHs1v9AqfCLt00Rve2oVga7CxiHCTzffSbMA2T9qmwJZyS6xm79KpqvznyiK BCz/4b25S7l06kg6/ilorVO21uZT2q7QtgMNal9EZcz+lmdaRekbOdTe7k6Fzeux L1kwrgBHfOqZzAoSMCNkrHSj8RNsMAhrKPUlgtb/u4s0lM/qEbs4HruD1vp2RCot gjxM6wJc58skczA6vVZe+/nY95kjhv4SxtVn+DgkrkD5G/rFlR37VaCbPL45oiZA 9yK2Zw/3dV0VYyK2b8idoRSSinTntu1n6IHMbI771gSjNPlmyGjnL/uH8xEgrHQe Qt2IIdDzp9YeM82XW+Cuu3cd1q6BZL15RJ5jGFyw8YEhT/YPJutwE3WYpyDvqo8c YF5h6WueRXd+y+TpCu5Z4xEGvvx2bkK9dmoP1L6/9SfFBK7wAkVJjeMlz0Tn1ens 6ZTGTegsjrNcSPMFSXEvcafdZiI29c/VdsYtry3FqFS9hy+74s5y92g25aIz2q/V 8XVN0UkKl0YJEHR2Jy3hOMhfmLd/qllmbFfHApu0e4nYCrpbVSc= =z5/H -----END PGP SIGNATURE----- --T3c2d8wRLLWftnVz5ApW9nkzvkipPhyuD-- From nobody Tue Feb 26 14:53: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 373F5130EAB for ; Tue, 26 Feb 2019 14:53:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sX-JymAi6NkH for ; Tue, 26 Feb 2019 14:53:22 -0800 (PST) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 183C21279E6 for ; Tue, 26 Feb 2019 14:53:22 -0800 (PST) Received: by mail-lj1-x22f.google.com with SMTP id v10so12296439lji.3 for ; Tue, 26 Feb 2019 14:53:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gIlxuPzTC8axjPc33Vx0UbdNAa7zw8owV4tsEQhHuO0=; b=Do0gahb1qw7WCoMQu8nw8P7kyxceVLxMAeXllM+86KMdVcMinehUnEFN9XeIDWwonA B2jAupiTw8CC9P60nT1laXPDjCWRpNVdWzRkKgJnfUZdGuGxRqAlBoo3gIkVl02dDm+G NV/Tx3gf8hd/+J+/t73JM2lKLPBso9Q09tWk4IMvXDBXtPVcM4yoGZht5FNYeaj3dLN5 fcisllG/cpvbKxOZkaSxnwPbCx7B8ldswtHONo3UcyRR8Cz4nqXZioBT5G6i68NkquMu g5xvDzHvr4OMdVsuoFidjBAgmlQf5fhTlLml9vhiIa/3FsodQ3OvR4TaZWIoxzAorJTa ayvQ== 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=gIlxuPzTC8axjPc33Vx0UbdNAa7zw8owV4tsEQhHuO0=; b=Rk7ekvNmDNBskp2oGOL9RIDh4roiRTlleDgyXt2JHifJLCgWzG5uaM4EFlwKr0ezGk gjZ6uhvBeBj/ApL3d+zvUj22SO/hanXSoUaOsakhk0M23DvSn5nYUovsRu9exR8ZkDBk 58cF5OGmEIQm4Jui9H9Puj8nGerRMrAGK2mKMPTeC/hYfvan2RE/CjWuaQRTTJzh0ZIB LgMjy2h0vpCxqHnjj+5Qk40cow3IEOc3v7TFqTbZS2PirF9SR5Gyu/VW08OPhoK0C1Xq k2WuNR25plgGCg+fYBwSgl96WhuVx6jur7+4Uv65Z33Z8vBCE8cml1eIh9Y9Leg3O6qO kILA== X-Gm-Message-State: AHQUAubxAQ2blYHlLZ6qo+jNX7SWI8NyzsqjtPxDdpV4xHUwd+9CpGZg UMIhmBsKjOQ6HRczjO4kEjiwaILORXby4NS1O2QOtQ== X-Google-Smtp-Source: AHgI3IapIaHOo0yRd3C7/0Fp1XFLZuCAatO6tfCa09j40Uo2LKGtOIOo/bPuf7VcjjOvAcF5Nge4HCw+sBV9LYVuF4w= X-Received: by 2002:a2e:47c4:: with SMTP id u187mr9044572lja.10.1551221599892; Tue, 26 Feb 2019 14:53:19 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Tue, 26 Feb 2019 14:52:42 -0800 Message-ID: To: Jack Visoky Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="0000000000006e148e0582d3ec19" Archived-At: Subject: Re: [TLS] Authentication Only Ciphersuites RFC 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, 26 Feb 2019 22:53:24 -0000 --0000000000006e148e0582d3ec19 Content-Type: text/plain; charset="UTF-8" On Tue, Feb 26, 2019 at 12:54 PM Jack Visoky wrote: > TLS Colleagues, > > If you recall we discussed a draft for authentication only ciphersuites > over email back in August of 2018. We've since made some updates to that > draft. We also have gotten IANA assignments to the authentication only > ciphersuites for TLS 1.3 and have updated the draft to reflect the new > assignments. > > To that extent, as the IoT community is looking to adopt these > ciphersuites, we would like to solicit review of the draft: > > > > > https://tools.ietf.org/html/draft-camwinget-tls-ts13-macciphersuites-02 > > > > and request that it be published as informational draft given that the IoT > forums are looking to adopt its use and the draft can serve as the guide > for use and interoperability. > It seems to me that there four somewhat distinct questions: 1. Code points 2. Document level (Info, Exp, PS, etc.) 3. Recommended status 4. WG status >From my perspective, you have code points and you've asked for an Informational document, but than can only get you Not Recommended, so what's the value of having this be a WG document? Why can't you submit it to the ISE or alternately just have people reference the draft? -Ekr > > Thanks and Best Regards, > > > > --Jack (and Nancy) > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000006e148e0582d3ec19 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Feb 26, 2019 at 12:54 PM Jack Visoky <= jmvisoky@ra.rockwell.com>= ; wrote:

TLS Colleagues,

If you recall we discussed a draft for= authentication only ciphersuites over email back in August of 2018.=C2=A0 = We've since made some updates to that draft.=C2=A0 We also have gotten = IANA assignments to the authentication only ciphersuites for TLS 1.3 and have updated the draft to reflect the ne= w assignments.

To that extent, as the IoT community i= s looking to adopt these ciphersuites, we would like to solicit review of t= he draft:

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

=C2=A0=C2=A0=C2=A0=C2=A0https://tools.ietf.org/html/draft-camwinget-tls-ts13-maccipher= suites-02

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

and request that it be published as in= formational draft given that the IoT forums are looking to adopt its use an= d the draft can serve as the guide for use and interoperability.

<= /div>

It seems to me that there four somewh= at distinct questions:

1. Code points
2.= Document level (Info, Exp, PS, etc.)
3. Recommended status
4. WG status

From my perspective, you hav= e code points and you've asked for an Informational document, but than = can only get you Not Recommended, so what's the value of having this be= a WG document? Why can't you submit it to the ISE or alternately just = have people reference the draft?

-Ekr

=C2=A0

Thanks and Best Regards,

=C2=A0

--Jack (and Nancy)

=C2=A0

=C2=A0

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000006e148e0582d3ec19-- From nobody Tue Feb 26 14:54: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 4D80A130F15 for ; Tue, 26 Feb 2019 14:53:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 RkYDqn55rt7c for ; Tue, 26 Feb 2019 14:53:55 -0800 (PST) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B97A130F14 for ; Tue, 26 Feb 2019 14:53:54 -0800 (PST) Received: by mail-ed1-x534.google.com with SMTP id f19so2869187eds.12 for ; Tue, 26 Feb 2019 14:53:54 -0800 (PST) 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=q+Ya8mLgYviaT3xTvcQ9EHkVzzTs14jLd3jrFLHp3Ck=; b=ZcoitvZAANztlF5y22tfCyoQP1wI9rk66n22CuQ68uAeaV0T+djKWKy69saGftko2a 7pW8CSH0OSEYLE8C9fg+1sKIKgAGo5dgsJSwc0Fjfir+2UA7JOsQwDKMZMtHUZcJhREa dJ9L0rBV7s6AVcdF0KsPaWLJ9AIA/4FuxrZoRnOoHj11/rLozr5wACk0orNTS1CtBX1e WJvHXOS+040j8fpDWT3RB+SXngjgUILxJDsDdZaWpvrEQnOvg7eu0vX7ml6jALqLHo/e dm8VbTF25j7UiqZfcfg670X915kEyhIzIDNADcUsA6czxxVbD5C30YUQcp1E/Nu5DswX +DCQ== 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=q+Ya8mLgYviaT3xTvcQ9EHkVzzTs14jLd3jrFLHp3Ck=; b=mVGJHpLm1JN9LZ+MxyqrqcdrFpMvAUAwNZVkDgUX1N9nQD7MYzIryBxd9pWBhg0DFq zJKVsOyC/dQCP06AEKHyqRTCHcGQGSKXzQOn0315nf+KXXTo4g7GSR/4AqrRrwvS1wXg 7VyfnH1cW7KGnx9Cu52d/PsrAhTRq78qwFCF9UeN2fy446CPqvzXFbRbzK6UzRe5ZkIw sFoOYxyYGFXrlNARxY3uHFieEsv1afsMM8oUUeh/QbA8kE3vd4Tl9BhCImPnxLrt0y+v 2gqCeUJLiLYhjQSby2xYRnYUpY4MvUxXXU7Vfilh4cu8opSmVgiZhGa8YXTJ3huTnnEr SCmA== X-Gm-Message-State: AHQUAuafPevGoLPS4RNZBKQEqLqQOVJm84M7ORc/UXJHgX5iCfyQtunO HcuoXaN7zNgfeLTQFlVQG60ZAg8virlF3IZP/ck3/ltoWos= X-Google-Smtp-Source: AHgI3IZxiWJUrURuHFi/8AbB5OGs1k17CnL6AEF4uwruVTwGYHsnd7KM9cFvTWKC4ZF42uxUGqFFfIM5Q3lrOeKy1iY= X-Received: by 2002:a17:906:e9cc:: with SMTP id kb12mr18678446ejb.81.1551221632979; Tue, 26 Feb 2019 14:53:52 -0800 (PST) MIME-Version: 1.0 References: <20190226220335.0d75968f@computer> In-Reply-To: <20190226220335.0d75968f@computer> From: David Wong Date: Tue, 26 Feb 2019 23:53:39 +0100 Message-ID: To: =?UTF-8?Q?Hanno_B=C3=B6ck?= Cc: "" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Authentication Only Ciphersuites RFC 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, 26 Feb 2019 22:54:04 -0000 Shameless plug, but have you looked at constructions like Disco (https://eprint.iacr.org/2019/180) that target specifically this issue? David On Tue, Feb 26, 2019 at 10:04 PM Hanno B=C3=B6ck wrote: > > I think I have raised my concerns before, but I have serious doubts > there's real need for such ciphersuites. > > The reasoning seems to be that performance constrained devices are > unable to do "normal" TLS. I don't have benchmarks, but it's my > experience that people vastly overestimate the costs of symmetric > encryption operations (by far the largest computational cost of TLS is > the asymmetric handshake). I wonder if the people who believe they need > an authentication only ciphersuite ever ran tests. > > I also see a non-neglegible risk in standardizing such ciphersuites. > Some implementations will end up adding them and coupled with > implementation flaws we may end up in a situation where inadvertently > insecure ciphersuites are chosen. > > -- > Hanno B=C3=B6ck > https://hboeck.de/ > > mail/jabber: hanno@hboeck.de > GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Feb 26 17:58: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 21409129C6A for ; Tue, 26 Feb 2019 17:58:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 LBmW0ZbrGSAy for ; Tue, 26 Feb 2019 17:58:03 -0800 (PST) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C773A128B14 for ; Tue, 26 Feb 2019 17:58:02 -0800 (PST) Received: by mail-qt1-x834.google.com with SMTP id j36so17461364qta.7 for ; Tue, 26 Feb 2019 17:58:02 -0800 (PST) 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=KwWkvhQTH060O3vocmd58QI+VJtkzMFMRGUPvuP7LVI=; b=OdZdL+Rcs1keVjmKEDuMnMGGZYhDYo3tsjwyCXefb4NRsQTO7ljk9Ug0oJ2k3rJR4d VnKsksWAgwSvDQJhPIkXeb4y0JQBg3kkdDfSAy6iyTKMLaor/b8uNHxoBQZwbXiKRyqk ifLu/lNRJiBY94/Rv1xPcoc7Dx4Kb+Ye+usKQ= 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=KwWkvhQTH060O3vocmd58QI+VJtkzMFMRGUPvuP7LVI=; b=CjMX4rOA8P+AcIN+7ssaS98VwAlHzzs1uR2onnYYUgrviBcnhcNY7/HgrZ1YvrHiGB 4vlSnjyJZjznBxEiDCWlj+bOeLlq3EYobsAxhrT9aJSUgeWmFO2PyofBfp5fuz2Phh+9 TqC9/QgXipZXaMruxrDU+NydR0Fbh9jdLih7klIjDLrLmnOxqQhmIlXpvmjReokRQZhp 14n1LedYZ+Hy/1xC8LSXQsTTc56mcTokOn9ik9ACZrZ8loDJBPwPxF+erMubgqmAULbZ fFQI3sW4SpigjV8hZzSAoHOI6+sa0tlBl3N6+YnZR8kDIMEYwjw2YcRTRxO+b9AOv0Tu 1u3Q== X-Gm-Message-State: AHQUAuZYBsVvvV/EL3EcGmPCjujqL/iVU/TRCjGebRagaDrBGc+B9DGQ PXPjKq2s4sZ6glk78ID1ISj2nk47i8rTkw== X-Google-Smtp-Source: AHgI3IasDQlErvix8/jVgR1rqdDqirQTv9MnU2ozIM0R4932+c5tvYxmxY1wLcduTxITJfkoa4SCKA== X-Received: by 2002:ac8:1015:: with SMTP id z21mr20523725qti.102.1551232681630; Tue, 26 Feb 2019 17:58:01 -0800 (PST) Received: from [172.16.0.18] ([96.231.217.246]) by smtp.gmail.com with ESMTPSA id 70sm17476289qkb.39.2019.02.26.17.58.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Feb 2019 17:58:00 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Tue, 26 Feb 2019 20:57:59 -0500 References: To: TLS List In-Reply-To: Message-Id: <04D78BE6-2048-4EC0-A191-68AFD8D71A68@sn3rd.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-grease 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, 27 Feb 2019 01:58:05 -0000 This messages closes the WGLC for draft-ietf-tls-grease. The draft will = progress as is because we received no WGLC comments. spt > On Jan 24, 2019, at 10:50, Sean Turner wrote: >=20 > This is the working group last call for the "Applying GREASE to TLS = Extensibility" draft available at = https://datatracker.ietf.org/doc/draft-ietf-tls-grease/. Please review = the document and send your comments to the list by 2359 UTC on 8 = February 2019. >=20 > NOTE: There is one outstanding issue raised by Hubert [0]. Please = chime in there or here so that we can address his comment one way or the = other. >=20 > Thanks, > Chris, Joe, and Sean >=20 > [0] = https://mailarchive.ietf.org/arch/msg/tls/nr4dA2JqcpqAjh-oY_1z2l6ZMFo From nobody Tue Feb 26 18:29:59 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 EC81E130FA8; Tue, 26 Feb 2019 18:29:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Sean Turner To: X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Cc: Sean Turner , iesg-secretary@ietf.org, tls-chairs@ietf.org, sean@sn3rd.com, tls@ietf.org Message-ID: <155123459696.699.7983755633479275500.idtracker@ietfa.amsl.com> Date: Tue, 26 Feb 2019 18:29:56 -0800 Archived-At: Subject: [TLS] Publication has been requested for draft-ietf-tls-grease-02 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: Wed, 27 Feb 2019 02:29:57 -0000 Sean Turner has requested publication of draft-ietf-tls-grease-02 as Informational on behalf of the TLS working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-tls-grease/ From nobody Wed Feb 27 00:54: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 4ECDA130E6E for ; Wed, 27 Feb 2019 00:54:27 -0800 (PST) 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 gkXjghq3c6cM for ; Wed, 27 Feb 2019 00:54:24 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF0EB128B33 for ; Wed, 27 Feb 2019 00:54:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CE43DBE51; Wed, 27 Feb 2019 08:54:20 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZvU3juLemzG; Wed, 27 Feb 2019 08:54:19 +0000 (GMT) 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 F17E4BE4C; Wed, 27 Feb 2019 08:54:18 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1551257659; bh=K8uJl2FEmUUbj8mxMnikvUz8jEcu935kRy2YHQ4E5KM=; h=Subject:To:References:From:Date:In-Reply-To:From; b=rNEllKEbr+GsXRo+voDysJ6HSNj6A+7IEJ5gDZBqbWkNAdacl5dnUHrNAm6M3BMi/ SIXEN1uas4IZYoYr/bQ6i4PLbLgRvXxrslduYa3U6UEhtVeaHtwhzN6pUHxcTZqw6V ECN6dXNsgyv0gf2HY8mJtL9WXswgNkiubPMJbAm8= To: Sean Turner , TLS List References: <04D78BE6-2048-4EC0-A191-68AFD8D71A68@sn3rd.com> 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: Date: Wed, 27 Feb 2019 08:54:17 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <04D78BE6-2048-4EC0-A191-68AFD8D71A68@sn3rd.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="nSU83hzpUCvyYUydyWdiyNlPSixIomf1H" Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-grease 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, 27 Feb 2019 08:54:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nSU83hzpUCvyYUydyWdiyNlPSixIomf1H Content-Type: multipart/mixed; boundary="yweArkdubvovrg7aFRJYU18MZBx1WuJCR"; protected-headers="v1" From: Stephen Farrell To: Sean Turner , TLS List Message-ID: Subject: Re: [TLS] WGLC for draft-ietf-tls-grease References: <04D78BE6-2048-4EC0-A191-68AFD8D71A68@sn3rd.com> In-Reply-To: <04D78BE6-2048-4EC0-A191-68AFD8D71A68@sn3rd.com> --yweArkdubvovrg7aFRJYU18MZBx1WuJCR Content-Type: multipart/mixed; boundary="------------891438A3DF6A654AAF434E63" Content-Language: en-GB This is a multi-part message in MIME format. --------------891438A3DF6A654AAF434E63 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 27/02/2019 01:57, Sean Turner wrote: > This messages closes the WGLC for draft-ietf-tls-grease. The draft > will progress as is because we received no WGLC comments. Apologies for missing the WGLC. I've just read this and fully support it progressing. I have one question though: The drafts says: 'A client MAY select one or more GREASE extension values and advertise corresponding extensions with varying length and contents' and 'For each of these, the "key_exchange" field MAY be any value.' and 'Implementations advertising GREASE values SHOULD select them at random.' I was left wondering what ranges of lengths and what values are recommended to be sent for greasy extension bytes and key_exchange values. Reason to ask is I happened to be looking at a few handshakes and noticed those lengths being zero in all cases IIRC. (It was only 3 cases being one 1 h/s from each of 3 browsers so could be I was just unlucky or missed a non-zero greasy length.) I've no strong opinion as to what'd be best to say about those lengths but I guess maybe we'd want to see some greasy lengths that are shorter than all real values, some that are longer and many in between, and value octets that that are random when lengths are non-zero. Does that match what people do? If so, would it be worth adding something about that to the document? Cheers, S. PS: Since I'm late to the game I'm fine if the above's treated as a random last call comment. > spt >=20 >> On Jan 24, 2019, at 10:50, Sean Turner wrote: >>=20 >> This is the working group last call for the "Applying GREASE to TLS >> Extensibility" draft available at >> https://datatracker.ietf.org/doc/draft-ietf-tls-grease/. Please >> review the document and send your comments to the list by 2359 UTC >> on 8 February 2019. >>=20 >> NOTE: There is one outstanding issue raised by Hubert [0]. Please >> chime in there or here so that we can address his comment one way >> or the other. >>=20 >> Thanks, Chris, Joe, and Sean >>=20 >> [0] >> https://mailarchive.ietf.org/arch/msg/tls/nr4dA2JqcpqAjh-oY_1z2l6ZMFo > >>=20 > _______________________________________________ TLS mailing list=20 > TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls >=20 --------------891438A3DF6A654AAF434E63 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 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5tDJTdGVwaGVuIEZhcnJlbGwgKDIwMTcp IDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJCZQmAAUL CQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1yw aps8HGUNhLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG +48od+Xn7qg6LT7GrHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXk kTFaSGYJj3yIP4R6IgwBYGMzDXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRr pZtXB1XQc23ZZmrlTkl2HaThL6w3YKdiTi1NbuMeOxZqtXcUshII45sANm4HuWNT iRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS3MmGgVS4ZoX8+VaPGpXdQVFy BMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml3OEuIQiP2ehRt/HV LMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi2/Jrsz6M zh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6 TzKjGjruq8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxIkBHAQQAQgABgUCWj1SoAAK CRAvPIc2gF+NovMcCACVZPo1cQa3D+vWaIo0ZyinO/MgtD2gHysoj1T0Qvq05//L ZXmhh578bJANvdl2g/HFhhwl/5HKIfWcyipQhmJklp/dsleKcNnn4B18T75RHY0G +po3ILq7evbiOjUH+xqApti1aCxi1GocsPghaLfsxmtXKMG4Xu7XhDTv66GOrqZf Y7+0ekJjD9Dza1t5NE/JR/VZA4B8PWR8Glb0+8C9rkjD0VZ5ekJdHPDGcJmFh8Z+ q25LDoI8Fgt1uKSowvoVnsQO5MFv/y6bXArtj1uB4hAL4JiOFgHlFdrW0MlFpvYm ziW4K9JHTD8KAfDbrb3e2W97ZDpROuYfE/lTbYOWiQI9BBMBCAAnBQJaPVAyAhsD BQkJlCYABQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEFqy+vF7Fyvq0mkP/ius gsf6Z4/Tu+vHzBbl5i6oKI8ZieH8JfEgXx4ut9t7l3hBGC2r7DpR5A8zLMpEhGIK gFcHagksFkfLEE/FmWDfd1MysQafxBYrHaI27P2tkxfI5JYV6247TV39pQ93kGds tsjIrmh/zEJCVczoofxtz72BDt51H2Z8tN28F/YVHnbaGDwFEEzWKYpze87y/f36 ogcdGO6LDEEEIA6Ee0dGxleuKlLS4UDTt0zjo6L8TyiyPHp9C3+UfnP8837Zp3Fh KstIBd+vWgPdHFg2G5aDIYUvrj9UJBvVgaN/RnkwE+dab2OBSg5jkr141JLQvzdZ 4mOUXn5D9Y6AH6tvj0+ubYMV6j35L1/ZXncuXPVYiylcmDp/6f2WYcT3gx9CPUYA cLMjQV4vX2W8z4uEPyMlIJuGsLf7KhvLL8BQ6zlncT6eONfUUX9UJUCzqI5rqL5c b5jWGHeKvbLWRyQnlq5PXQxJTwYRm71rJTgzejc33LE6Nqg/Q25Dgwwsv+f+7i73 gB5loc80Fef+FV9VFGalFe0Yq8m0UASmkYRh7MH5ssoibpeWk+SGfBjOV4tnsAwR yjYLpAzxA8HeDcmlLeypGEDmsQ/iUvXoGaKOYX4Ieg8T/PCAplsqnJUOq8hbkgOC 98gLZfiltkNG8YhQpoZIHj6SxmBRSc3K99CvanuOiQIzBBABCAAdFiEEfhcKBFyE z0YOK3mgEO952f2DUxIFAlu3JJsACgkQEO952f2DUxJ4qRAAmbjiO3WTAeBCB4ME p2N2+XQCMTTFURDGuJnqU/+X//fhhPRq4V/OxgisKFKlBcAS2hsECvg6HDVSz4Fl 74fk/y+botG4/CjMLdKPB9fgh5zz72i3q0hWDixt50NKBv8IIVWOyYgZxDU/vcks lMEnqbFgJX+CfdALpvAM4WjuQP0UMcKNE3xd+EdDhD1xjK3Tq4XfWob9q6aBZgL2 B4IaADCIeDDE1hv0agnSJmMJE7Bti8tNxCCxVRbZtOaxVHXdRUoOx2XTaxFXupxV hbpHRrdFrwq51f6e3bkfkNEZ3fzYpnlbynJ2zL++JO8P3Pq/S6UKEFjEB50i8YgK WuFvGUsQ+YiDgiZU4saqxSBWbfYn3lY6MSSTg8RnXbFIMG3CFImqYk1uhaV+bDjc p0htjzM2F98g7c3o7sWx0bGarId4uhOmpj7JJVQ+lu7Jby6Ocj8n//7qF1Nn11Cw QlCVaeAq5Y5DmZrnww9I3zzOWWyqFkAVCM3GqeRLMvplD6/+O+5FF7XoHzQB47nk OyZtawy/9gssPWZKLv4qHLYS0wGGCiNbCsYy90s3pfeafM0kSxxjIvEz21KT6LJI /awu2ErQFWCkDMFJ1p/97MjPrQ/6d4cPO140V/wyfuWaBiTVqa9mgnb2zn6fYfDH JEvl1UzIx3JCae25tty1+qtnS0i0LlN0ZXBoZW4gRmFycmVsbCA8c3RlcGhlbkB0 b2xlcmFudG5ldHdvcmtzLmNvbT6JAj0EEwEIACcFAlo9UVoCGwMFCQmUJgAFCwkI BwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+o7HBAAxHAdFkBGZ9gJK8w7 NUYS9C6enGYtAYoKH5G3Bn3YScjErNfQtHYb53KwBQpVSOv1HcN8hbQ8mLTgn9lt zNwNSuv0XxIswi807HRSIZ4vYDiS5VKV1YkLYK5bLY5O4alVdzqM+AZQqkuHBu63 6n+C0ED6UwLhVBFfSNvBQVAdoq6gvr+IE8rCIKTMNGwNcgVPbF+YxP7UZM6p7s2a 5MIqGw7URSfaqfuztibXGOBLFbSwLGqHSSnOXBfEeDrwdZ+ur8cXIIPRIeCTVmeO 8bGgpgBqNQXG9oyGN+TrYAC+4Ahi0UjCk7QGj8tf3xICKoQpYyfceNBZJ/969gV9 tVgvRxUjxUwc9kZbi0c8XYMTq5GCvBIh1D6BOW9QBM2SsNgG3l36+e3+c2LDdyKn 20C1IzGLVDdcCtz42/onQ/e9sMlzFrfLjs5SO2/TnLvp2JtsIQXyb/T5qd0GE5j8 /iwfZR+uVTVVEsUl1a+Yllzt6sdR7RIhhKpKaKzEAk4d0+VHdz7zEkQRRSjbPVoS fy8c/kld9Fi8Buna+ZkKpcwIW+D4XP83pGcl0XUv6AyqwS1LnEt+jv/+PSXskYtU Lzn8Z35iKkSAH/5Nz6GCZk6ORPNv/6+UI92BpUbu/G2tBwK8bPgAg+gJxBx3G7MK W7VRCmM5UrtAK9A3O70VjPyMkHSJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLC LAf/X/9vRTZWtwSXxiBCA54a6hg9IvW0mvPUqgXfvrhtOk0IFucLKrTXK8J/NcmU 6ulxOovVbQ+Bin6gtHeCmSa/W523g/NXCOuFTnS/MyVibNL4+RCFwqGysl++Cm+L nj1MmasE9kO+CNdervx8APfxV7D6OYrG4eGag+LdFR6VpJn6tRT0/WvyT8l+Oqiq gdhXHv+0MvkkD9TX5LlJW4VB/yRvWkkmL5N5c5zYh+NcfTPhQ5S9dOorVzrm65d6 Itn0937Ennau7s7fiFdA0BHjWqEAFLsBIXQfCFjjKjdsKA4xlSiX7X7ElmPYpWa5 wwTQ66dL0anMd9y1DJCMOHe4gYkCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9 g1MSBQJbtyScAAoJEBDvedn9g1MSY7sP+gKR0rFU1g+GtB+hSdtwPRbacvml2eL2 Jc5Eq37J9hAqxHyt5V0If7s8IyVA2GXgdfwULBWbXGDUDiUkh20OPQRUS8G9Sf8A WRuG25q5C8ZzWygykL88RKXJZDFtA49CeqO5Bq5syBhq4QfiSTffQHIp3h0boPGU hSBEUQpooMXYQClNARQ+z/uRzR5bUi9wxdXNnxTn9ia4ASlaBPvUYTGY1jW2HrRR SwpI12+UaWsvc3jJtQ8X0kxgJ7jsFF1uqquIZ5eflQv+PHHg2RJSy37u0UFGb+OK ZEkzlmbPokKCYhzBR5PcD6sgdlaJNcidmto9u1oV6yZT8J2W4CTuUclgxt6f3lZq ZeVLnNnbHyKUdeypwLlqYISulfnMhZ3A6Bgpf2BtjL6KJbFtPBYmYdxI+HZyY49u U2ZHhRu+CSQ1y7zGKSX0gRp5hE7+A4XJtsT6lTLhbi9aiZTG1S6zKNhl3qNNzszc r27PrvFiyGhpuYQuzdQl2PMGbOI6Ojif3sab53NO3RLsLOM09wIlr95yKLlkXkUr WcvUJGrw6HKm8j5opXHTwmJOAbDpc6cMDu+ITRu4spdCnQJcE8RkO8tKyaLuh2Gt U5kYSBK97yr5VviX1FK6rY14LLmnE16OPiK2tiVBKy9nGM0DKtY+K9WcoRZ7s/d7 O0bMfzcNPtGLuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiez GPuBHmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9Wf pHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC 6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2 D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFe A7PbTuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ /Vf3vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbpt PEcmoazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKr em5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96 Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYgh x8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQ oqj1gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P /1tF6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8 Wpfdn3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJ gx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5 SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2 oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIA ypqYo3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoM eDQkd0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS /qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZ IMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XO KVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DJ121 -----END PGP PUBLIC KEY BLOCK----- --------------891438A3DF6A654AAF434E63-- --yweArkdubvovrg7aFRJYU18MZBx1WuJCR-- --nSU83hzpUCvyYUydyWdiyNlPSixIomf1H Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlx2UDoACgkQWrL68XsX K+penBAApIk8L8Qg0ZLrWrNyhExy9FNpI8shbmoRMz8z9lpq3fbYTCJFg3e93lSL 5eqDCy/dI94UQURVDQzXZrlbP+I/3qFK0mBfRTjx0avi904dmLZv4H0KtmrL+BXi XqPSm1JDFVFq/cmwUoDrTVps6L6jAujCNfElY1zNc/sMpC/amx4mkvANX4THfvqI d/f8bvbxuUwlynEdILUULb3nGlAntzLKMflfTrCRkTZhR5Sc2mVzsx81MUyjZHYV jmioMAcrLVwnxtJTpJgcioepwAIwvkRc4ydaoqea3yakNyn45MVaUUJuCtq37i2w cVAsNx8tEuoR8Fv/WnQ7Yw7unXyg6Ij3swUeAwliHxnNg++Oh8bhUQkcv88EwKUc Yy59BvtBLsOa7Y3Fc+Cjbt+3N2p0DL11Dau3RUTQhxIeh3SDOHo9+hzjKUuXpGoN Vsc4TYaAOdIWwnmhKAugY90KiAfZZhLalTZFwpxvPV+fs0GnAoRqgkrEvnTtb0NN ZRFYJsoStGzyCJOdvYxRj8zAb8SujCRIEut2Y/NWptDc+xxzv0uytvPeGqENTeT2 uRF6wFdwJi2EgsvtWAKV/40UXUWmUxaJPyt6eUOyYBDAQ/w12qu8woSU553Rpbn+ X4obEpp9U4o6fU+rRGi8Q3BPhzWEZRH0Izj3ROBxNGsea1ivkD8= =mSHO -----END PGP SIGNATURE----- --nSU83hzpUCvyYUydyWdiyNlPSixIomf1H-- From nobody Wed Feb 27 01:31: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 B97C5130E6E for ; Wed, 27 Feb 2019 01:31:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 stDFxYXBILF9 for ; Wed, 27 Feb 2019 01:31:27 -0800 (PST) Received: from zucker2.schokokeks.org (zucker2.schokokeks.org [178.63.68.90]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E946C130E8C for ; Wed, 27 Feb 2019 01:31:26 -0800 (PST) Received: from computer ([2a02:8109:83c0:4bfd:dc27:39b2:705d:72e7]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1.3, 256bits, TLS_AES_256_GCM_SHA384) by zucker.schokokeks.org with ESMTPSA id 000000000000005F.000000005C7658EC.0000276B; Wed, 27 Feb 2019 10:31:24 +0100 Date: Wed, 27 Feb 2019 10:31:23 +0100 From: Hanno =?iso-8859-1?q?B=F6ck?= To: Jack Visoky Cc: "tls@ietf.org" Message-ID: <20190227103123.3b2af774@computer> In-Reply-To: References: <20190226220335.0d75968f@computer> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] EXTERNAL: Re: Authentication Only Ciphersuites RFC 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, 27 Feb 2019 09:31:30 -0000 Hi, On Tue, 26 Feb 2019 21:26:45 +0000 Jack Visoky wrote: > We have done tests on this and it there is a difference. Have these tests in any way been published? Because otherwise it's a very weak argument. There are some obvious questions, e.g.: * What algorithm implementation was tested, was it optimized for the architecture in question and was it considered whether the optimization could be improved or maybe even whether already a more optimized implementation exists? * Have you tried both AES and chacha20? And in both cases the most optimized implementation for the target plattform? * If the bottleneck is the cipher have you considered whether a different cipher that provides reasonable security, but can be implemented better on lightweight hardware, would be an alternative? (Not keen having that option, I believe fewer options are better.) > This probably goes without > saying but of course the best line of defense is to properly design, > build, and configure the implementation. I'm inclined to say that this is an outdated view of how to best do security in protocols. We had plenty of situations in the past where the TLS spec was a minefield of possible implementation mistakes that led to long descriptions on how to properly design things to avoid these mistakes. History shows it didn't work. (Let me just throw in "Padding Oracles" or "Bleichenbacher attacks" as very obvious examples.) My takeaway and I believe that of many people is that the protocol should avoid implementation pitfalls whereever possible. And I believe an authentication-only ciphersuite is a dangerous implementation pitfall. --=20 Hanno B=C3=B6ck https://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 From nobody Wed Feb 27 02:16: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 BB394130EA1 for ; Wed, 27 Feb 2019 02:16:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 0Nfh-PiesmvL for ; Wed, 27 Feb 2019 02:16:50 -0800 (PST) Received: from esa2.dyson.c3s2.iphmx.com (esa2.dyson.c3s2.iphmx.com [68.232.133.94]) (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 027E4130E27 for ; Wed, 27 Feb 2019 02:16:49 -0800 (PST) X-IronPort-SPF: SKIP X-IronPort-AV: E=McAfee;i="5900,7806,9179"; a="46848613" X-IronPort-AV: E=Sophos; i="5.58,419,1544486400"; d="scan'208,217"; a="46848613" Received: from unknown (HELO uk-dlp-smtp-01.dyson.global.corp) ([62.189.202.16]) by esa2.dyson.c3s2.iphmx.com with ESMTP; 27 Feb 2019 10:17:47 +0000 Received: from uk-dlp-smtp-01.dyson.global.corp (uk-dlp-smtp-01.dyson.global.corp [127.0.0.1]) by uk-dlp-smtp-01.dyson.global.corp (Service) with ESMTP id B7083FA10; Wed, 27 Feb 2019 07:45:10 +0000 (GMT) Received: from UK-MAL-CAS-01.dyson.global.corp (unknown [10.1.108.2]) by uk-dlp-smtp-01.dyson.global.corp (Service) with ESMTP id 9720AFA02; Wed, 27 Feb 2019 07:45:10 +0000 (GMT) Received: from UK-MAL-OWA-02.dyson.global.corp (10.1.108.7) by UK-MAL-CAS-01.dyson.global.corp (10.1.108.2) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 27 Feb 2019 10:16:39 +0000 Received: from UK-MAL-MBOX-01.dyson.global.corp ([fe80::3975:cbc9:490b:523a]) by UK-MAL-OWA-02.dyson.global.corp ([fe80::64d5:21cc:e3cf:37f2%14]) with mapi id 14.03.0319.002; Wed, 27 Feb 2019 10:16:39 +0000 From: Tony Putman To: Jack Visoky CC: "tls@ietf.org" Thread-Topic: Authentication Only Ciphersuites RFC Thread-Index: AdTOFIIaiE+qoBOKQdSotuuQ5A30qAAb/o5A Date: Wed, 27 Feb 2019 10:16:39 +0000 Message-ID: <140080C241BAA1419B58F093108F9EDC5858AE40@UK-MAL-MBOX-01.dyson.global.corp> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.108.27] Content-Type: multipart/alternative; boundary="_000_140080C241BAA1419B58F093108F9EDC5858AE40UKMALMBOX01dyso_" MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Authentication Only Ciphersuites RFC 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, 27 Feb 2019 10:16:53 -0000 --_000_140080C241BAA1419B58F093108F9EDC5858AE40UKMALMBOX01dyso_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable I take no position on whether this is a good idea or not. Regarding the dra= ft itself, I was expecting to see a clear definition of the integrity check= computation in terms of an AEAD-Encrypt computation. Something along the l= ines of: AEAD-Encrypt-HMAC(write_key, nonce, additional_data, plaintext) =3D plaintext || HMAC(write_key, nonce || additional_data || plaintext) In particular, AIUI, nonce must be included to prevent replay attacks. Also= include N_MIN =3D N_MAX =3D 8 bytes. -- Tony From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Jack Visoky Sent: 26 February 2019 20:54 To: tls@ietf.org Subject: [External Mail] [TLS] Authentication Only Ciphersuites RFC TLS Colleagues, If you recall we discussed a draft for authentication only ciphersuites ove= r email back in August of 2018. We've since made some updates to that draf= t. We also have gotten IANA assignments to the authentication only ciphers= uites for TLS 1.3 and have updated the draft to reflect the new assignments. To that extent, as the IoT community is looking to adopt these ciphersuites= , we would like to solicit review of the draft: https://tools.ietf.org/html/draft-camwinget-tls-ts13-macciphersuites-02 and request that it be published as informational draft given that the IoT = forums are looking to adopt its use and the draft can serve as the guide fo= r use and interoperability. Thanks and Best Regards, --Jack (and Nancy) Dyson Technology Limited, company number 01959090, Tetbury Hill, Malmesbury= , SN16 0RP, UK. This message is intended solely for the addressee and may contain confident= ial information. If you have received this message in error, please immedia= tely and permanently delete it, and do not use, copy or disclose the inform= ation contained in this message or in any attachment. Dyson may monitor email traffic data and content for security & training. --_000_140080C241BAA1419B58F093108F9EDC5858AE40UKMALMBOX01dyso_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

I take no position on whether this is a good idea or= not. Regarding the draft itself, I was expecting to see a clear definition= of the integrity check computation in terms of an AEAD-Encrypt computation= . Something along the lines of:

  AEAD-Encrypt-HMAC(write_key, nonce, additiona= l_data, plaintext) =3D

    plaintext || HMAC(write_key,= nonce || additional_data || plaintext)

 

In particular, AIUI, nonce must be included to preve= nt replay attacks. Also include N_MIN =3D N_MAX =3D 8 bytes.

 

-- Tony

 

From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Jack Visoky
Sent: 26 February 2019 20:54
To: tls@ietf.org
Subject: [External Mail] [TLS] Authentication Only Ciphersuites RFC<= o:p>

 

TLS Coll= eagues,

If you r= ecall we discussed a draft for authentication only ciphersuites over email = back in August of 2018.  We've since made some updates to that draft.&= nbsp; We also have gotten IANA assignments to the authentication only ciphersuites for TLS 1.3 and have updated the draf= t to reflect the new assignments.

To that = extent, as the IoT community is looking to adopt these ciphersuites, we wou= ld like to solicit review of the draft:

 &n= bsp; 

 &n= bsp;  https://tools.ietf.org/html/draft-camwinget-tls-ts= 13-macciphersuites-02

 &n= bsp; 

and requ= est that it be published as informational draft given that the IoT forums a= re looking to adopt its use and the draft can serve as the guide for use an= d interoperability.

 

Thanks and Best Regards,

 

--Jack (and Nancy)

 

 


Dyson Technology Limited, company number 01959090, Tetbury Hill, Malmesbury= , SN16 0RP, UK.
This message is intended solely for the addressee and may contain confident= ial information. If you have received this message in error, please immedia= tely and permanently delete it, and do not use, copy or disclose the inform= ation contained in this message or in any attachment.
Dyson may monitor email traffic data and content for security & trainin= g. --_000_140080C241BAA1419B58F093108F9EDC5858AE40UKMALMBOX01dyso_-- From nobody Wed Feb 27 04:23:29 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 54AD1130EB8 for ; Wed, 27 Feb 2019 04:23:27 -0800 (PST) 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, 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_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=ericsson.com header.b=BWdpaRxg; dkim=pass (1024-bit key) header.d=ericsson.com header.b=G4qcsSVp Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LI7r76Il8Jtl for ; Wed, 27 Feb 2019 04:23:24 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 950EA130EB4 for ; Wed, 27 Feb 2019 04:23:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1551270201; x=1553862201; h=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=G+Hh4Zqyztj6Vu/6HKLwkL7+/1RmUSFLbwJ27JvM3U4=; b=BWdpaRxgFY3QAb7IJYtWUseO97epNdP/Ow04CktWy1CaBcwQb/GZoJ37P39wz7NM SK6oq9sUjhJp0Nr6KfIfTpqt12/Dc8VUhzsZjwqEM9V95RHWWwX1lBLz0P4k07tV 6uWhE3l+RBGTPc+ABS2RDNENYRlwrL67xTMbAAghj3g=; X-AuditID: c1b4fb30-f93ff7000000355c-94-5c768139c193 Received: from ESESSMB503.ericsson.se (Unknown_Domain [153.88.183.121]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 05.24.13660.931867C5; Wed, 27 Feb 2019 13:23:21 +0100 (CET) Received: from ESESSMB502.ericsson.se (153.88.183.163) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 27 Feb 2019 13:23:21 +0100 Received: from EUR02-AM5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Wed, 27 Feb 2019 13:23:21 +0100 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=G+Hh4Zqyztj6Vu/6HKLwkL7+/1RmUSFLbwJ27JvM3U4=; b=G4qcsSVpqtLug2RV6bqDpS1Io+ybX0/jtpVKnwN8NatpXE/kb0kDl04CDdLrmr9oC3wnGGv4tOkCO/PVD76dvIdhwBoCLQfrCk5F526Mis6PkaPL/iRRzHn04S8PCSDKtWbwFFiuZoK0comf1vcvGG6LBdlj9p9IAkfQhPKi3bg= Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.166.22) by HE1PR07MB3484.eurprd07.prod.outlook.com (10.170.247.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.5; Wed, 27 Feb 2019 12:23:20 +0000 Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::49f9:ba7d:bd7d:2ffc]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::49f9:ba7d:bd7d:2ffc%5]) with mapi id 15.20.1665.012; Wed, 27 Feb 2019 12:23:20 +0000 From: John Mattsson To: Tony Putman , Jack Visoky CC: "tls@ietf.org" Thread-Topic: [TLS] Authentication Only Ciphersuites RFC Thread-Index: AQHUzpc5W2pxSTaBS0OsWyhr6Jy/Mw== Date: Wed, 27 Feb 2019 12:23:20 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.0.190211 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [192.176.1.92] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0c183cdb-3ae8-45cd-7567-08d69cae5c11 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB3484; x-ms-traffictypediagnostic: HE1PR07MB3484: x-ms-exchange-purlcount: 2 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtIRTFQUjA3TUIzNDg0OzIzOjRtem56L1VLeGxucUMrYVVpSXdpSEZNK2pj?= =?utf-8?B?S3pOcVVuTXFQNnhSWHd4a3h1ay9LaVJLdGNyUW8rZWVxVUI4UTF3OHJzYU5n?= =?utf-8?B?QkVGUmZBWHBFdEpTcWhXeEQ3VE9IKzE1bVo3OXRYa1R1UGsyeFgwVzFKaDNJ?= =?utf-8?B?QmhPcGEybm5lSnFmUlo5Q2NrVDhudjNtdG1EM1lxT0Uwekh2UFVlM2dCZmNH?= =?utf-8?B?NDU5ZmZQR1ZTeGh2dkRxYzFXUHlMaXA2M1p4TEhaeWdRWWt0eU5sL05vbGF0?= =?utf-8?B?S0htWlBnU0dJVXVaWURvOGxOcDBIWlRQcllpdDlMQVFRWTgvSEp0eFBOSkt3?= =?utf-8?B?U2MzdGQxbU8zNkpiTWdHSk9ZZ0xoK1UzYlQ1NGVmcXFPRHBZRWkrOEdMcWpi?= =?utf-8?B?ZC92UTZ5bmpxM2EzRGxYeEZDOFh4Z0RLc1JMOXBNTGRTbnQvZ0JHUTdOTjRa?= =?utf-8?B?SXEyRWVGRjJiK3E5WUloUnV6TjBGYVFvM3JoS2x2TGZRUE5oTFNOTlpSZE1T?= =?utf-8?B?UjJFTzJpcWhiTUZIak42U1pDN2dKcWhMTFJKckxlWDdrSGFkSVBlMEpib01B?= =?utf-8?B?MHk1TWxucGNTNmRWenBlcFlDNjNmOGxCYmZWMXFkMUh2YVAwcnNNbDFZUnFV?= =?utf-8?B?TWJOSWFzVlY1a3VLWWxpM05hd2RJS0MzSXNKVGNIYUlWSmpsZG44NXplbUty?= =?utf-8?B?SHZXUWxsN3NzVUV0MlNkVkZDcFFiTmJTc1h4aGVlQ3ZoZVhreXpmeVpYUjNp?= =?utf-8?B?ZmRLeEU2R2swZ1JESGRFYnNYRFRyUlZLRHRwclV3QlBVT0h5K3ZaTkRNSHRl?= =?utf-8?B?QlRFcnJ5MGp2VnoyMHpkMzJJMmdSSUFWTnJTSXJhNGhBcUhwTjVRbzZuWnRF?= =?utf-8?B?SFltTFJNaFY4NDZIU2grTVBCSW4vMjg5ZXVEemlud3psUmZtK3hNVHB6QzVL?= =?utf-8?B?VnZhc2VhVGRBT2RZKzluRjdybStoRHM2WThtQzE2R2NtTk1FVWdWREljT0NB?= =?utf-8?B?dEprTXE2RGZrQzFjTGpNcHhwaEJQeWc0V1VQQW5DMWZuclhwMUcxS1RpR2lI?= =?utf-8?B?SWhqbjZGRndCM1NKdEZaeGN6b0pDWXEydk5SQ2V1WllleFRza0pGZ0N6Skhj?= =?utf-8?B?Yk00ci9wckNoaHZvczQ1NG4wblY4bmFscS9EeVN6WXl1U3hHNHVLTmRMMGpW?= =?utf-8?B?L3ZqVEJDdTgxNzF5aE82b0FQVk0rR2dMaW82enUwL3lRalVzTnpnbXRBV3pU?= =?utf-8?B?WDNOYWVUaXlJdXZDbmxyWHFNTWtKNXpVNW1JSU5tSE9yTy9IRER5c0dQTlUx?= =?utf-8?B?VFRvZ3Aya3c0cFJBWU1rUW5kbU1JQkRwMThnQlZWemU1T0pyV0FjVExHMVdu?= =?utf-8?B?Z3pEZm10Q2g5amtXQ0xvSmora2NzdDRrMnYxUDVrcncxWHE1TkVuclE0KzFR?= =?utf-8?B?VDZlbkxHTkVZOGI0c1BLVnVrcUo5dEpTQlZ0MVgrMDQ0VXV1eFM3SEZNQ2dI?= =?utf-8?B?S0txWFpiS1hsZkljZHVEaTlVNENwUXRyNW5YWmRWalFrUXYrZHVXN3F5TW1z?= =?utf-8?B?bUxvd3NvMzRzU3FtSWtxWW1LckZ0bDlINk42RGRrckx2S09hZ3paOWlGUytJ?= =?utf-8?B?V0VLOU5NUXRzR0dTaFRsQ1h5SFE2QWx5YlJ4ZFhBL1kvMFJyWG40ZXFqeVZ6?= =?utf-8?B?TEZIK2dwcFNJaTZTN29SYStzSG5TVnpnbnFDem9rQVpkOWJkblQ0U2xIZjNX?= =?utf-8?B?cVZ3b1JnTHUzRXV6c0RSL0QyZ0FXVVJHZVZ1YThSbWlISXptbVI2aURQb0U4?= =?utf-8?B?MXRJQmgxK05makY0SHV2VVFKaUppUFlXd1JnSVB0a0hoMFE9PQ==?= x-microsoft-antispam-prvs: x-forefront-prvs: 0961DF5286 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(366004)(136003)(39860400002)(376002)(189003)(199004)(33656002)(44832011)(5024004)(14444005)(256004)(105586002)(54896002)(6512007)(236005)(6306002)(478600001)(53936002)(6246003)(14454004)(106356001)(97736004)(2906002)(316002)(6436002)(6486002)(606006)(66066001)(966005)(486006)(476003)(110136005)(83716004)(68736007)(71200400001)(5660300002)(58126008)(71190400001)(81166006)(2616005)(81156014)(102836004)(6116002)(4326008)(790700001)(186003)(3846002)(8676002)(36756003)(99286004)(7736002)(25786009)(6506007)(53546011)(8936002)(86362001)(26005)(229853002)(82746002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3484; 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: FTcV+fEwPert01JePzk3f6zC4eEjohAqGJrMwZPtGO3FL6dO040rHfKwAv+Ce2aFbcS+AYUC8cIfjHWpIlfr1pPISbhRtlop5NmdWG0xn5xXWGUvhMuIkod2zutSaLXWc/MG3Ze66ue8f+Ug5xuel8SccYjItcXsHYjxAi53OtEFI2I+QLzhPYIzId4nU8yK0WcjoLwJ4ZzdzJR3itEt6/N31cdoLfDBOrkPx2Nm2B2w3QtXjI+kvxsvruonqfDzkg3FB6fXidLcBmVzUqgnQDPK9ZTeXTzl5bCzoBs4EcJUuxZwhSuR1PelJTXtQA0lHisEQ3mcYBZetNJ/GDxly2ObXvbw1mO18eSRooGLWZgJcGxEbsQrPYHsMm9+T1lbcwRgBIwpk9JHMW64T8SzLgqXyX1qREt9x9ZHslUKmAI= Content-Type: multipart/alternative; boundary="_000_C75F0D1890FB46F280EB850DF3C76607ericssoncom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 0c183cdb-3ae8-45cd-7567-08d69cae5c11 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2019 12:23:20.0643 (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: HE1PR07MB3484 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHe3fOtuNw9Xp0+WQWuhJKvCdkZJrRBwmkEunGukw96HBuutlI oXKQCoo3lMS5acYoM8WlxaS84DBBSSQRRUWlTVIp8vJBkUTa9i7wy+H3vP/fed7zPByGYof4 AYxCVcBpVHKlVCCiG+9YC8Mv6HWyKP3gubjF1mVh3NZEOYqzfligL1PJtt1dXrLZ7Hz09wwI blD3RPGZnFKh4zSRCY9E2Y6+ESqvuQo9KbPa6WLUU47KkRcDOBbaulf55UjEsHgYgcWywnMF LN5GMLqVQgIzD8pa9LSroHENBfqBYgFJ6ngw92IXkcKOYPrrGO16X4CjwNTnsrwYP3wTuseN lIspHAzrk81uxxefh4V3VRRx4uDL+ktEOAIMn9rc30HjEPi1NO/uI8aJ0O8wux2Ej8LOWAeP 9PSHueUWHhkIg7lvgiIsgTXHPt/FEhwJXcvER/g+lJQ08IkTBHuTdgHhEzDZUuFZTAoMDiy6 pwQ8i6DK2Oq5IBRmmqeEhANgx7EpJFIHC6WjI56uOfC63uIMGCcHwkZ1CHH2+VDRPY7Ihjl4 21mCalCY4cAQhDNguvYnZXAP7QOjjcu0wdmKwmeh63OkwbPH+oofQsJnoMRo8nAyTBnqhAed V4hpRxItp03PzYqJieA0igytVq2KUHEF3cj5Yw19/BvVi9ZWkmwIM0jqLQ7U6GQsX67TFuba EDCU1E9c6ToSZ8oLiziN+qHmsZLT2tBxhpb6i/dYHxmLs+QFXA7H5XGa/ymP8QooRmnvS7nh jd7nq1f6fDLRd98076Btvg6KVGNJXY7mUzPTaWxH9YMEZaKpQXY4/mI+m99zZPbZ0rTXn07G cm0z+lhjeurp6+mKk1fTQ/jhpm9qfXvLreDfA29sh5Kanvbn2Ttm0lKaYs1BlZK7tWqBMZWd X+paTRgOvn3JulUnDpPS2mx5dCil0cr/Aaw5CO5UAwAA Archived-At: Subject: Re: [TLS] Authentication Only Ciphersuites RFC 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, 27 Feb 2019 12:23:27 -0000 --_000_C75F0D1890FB46F280EB850DF3C76607ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClRoZSBkb2N1bWVudCByZXBlYXRzIHRoZSByZXF1aXJlbWVudCBvZiBsb3cgbGF0ZW5j eSBzZXZlcmFsIHRpbWVzLiBJdCB3b3VsZCBiZSBpbnRlcmVzdGluZyB0byBrbm93IHdoaWNoIHBs YXRmb3Jtcy9uZXR3b3Jrcy9kZXBsb3ltZW50cyB5b3UgaGF2ZSBpbiBtaW5kLiBNeSB1bmRlcnN0 YW5kaW5nIGlzIHRoYXQgSE1BQy1TSEEtMjU2IG9ubHkgaGF2ZSBiZXR0ZXIgbGF0ZW5jeSB0aGFu IEFFUyBvbiBhIGxpdHRsZSBiaXQgbG9uZ2VyIG1lc3NhZ2VzIHdoZXJlIHRoZSBsYXJnZXIgYmxv Y2sgc2l6ZSBtYXR0ZXJzLiBTaG9ydCBtZXNzYWdlcyBhcmUgY29tbW9uIGluIG1hbnkgSW9UIGRl cGxveW1lbnRzLiBMb29raW5nIGUuZy4gYXQgdGhlIGJlbmNobWFya3MgYXQgaHR0cHM6Ly9iZW5j aC5jci55cC50byBmb3IgImFybWVhYmk7IENvcnRleC1BNSAoNDE3ZmMwNTEpIiBvbiA2NCBieXRl IG1lc3NhZ2VzLCBTSEEtMjU2IGFsb25lIHJlcXVpcmVzIHNpZ25pZmljYW50bHkgbW9yZSBjeWNs ZXMgdGhhbiBBRVMtR0NNIGZvciA2NCBieXRlIG1lc3NhZ2VzLg0KDQpDeWNsZXMvYnl0ZSBmb3Ig NjQgYnl0ZXMNCjg2LjE0ICAgICA4Ni43MyAgICAgOTMuNTkgICAgIHNoYTI1Ng0KDQpDeWNsZXMv Ynl0ZSBmb3IgNjQrMCBlbmNyeXB0DQoyNC4yMCAgICAgMjQuMjAgICAgIDI0LjM0ICAgICBhZXMx MjhnY212MQ0KDQpPbiBtb3JlIGNvbnN0cmFpbmVkIHByb2Nlc3NvcnMgc3VjaCBhcyB0aGUgQ29y dGV4LU0wLCBBRVMxMjgtQ0NNIGFsc28gc2VlbXMgdG8gaGF2ZSBsb3dlciBsYXRlbmN5IHRoYW4g SE1BQy1TSEEtMjU2IG9uIHNob3J0IG1lc3NhZ2VzICgzNzY3NyBjeWNsZXMgdnMuIDQ4OTI0IGN5 Y2xlcykgaHR0cHM6Ly9naXRodWIuY29tL2N0ei9jaWZyYS4gT24gbG9uZ2VyIG1lc3NhZ2VzLCBI TUFDLVNIQS0yNTYgbGlrZWx5IGhhdmUgbG93ZXIgbGF0ZW5jeSAoaHR0cHM6Ly9jc3JjLm5pc3Qu Z292L2NzcmMvbWVkaWEvZXZlbnRzL2xpZ2h0d2VpZ2h0LWNyeXB0b2dyYXBoeS13b3Jrc2hvcC0y MDE1L2RvY3VtZW50cy9wcmVzZW50YXRpb25zL3Nlc3Npb243LXZpbmNlbnQucGRmKS4gTm90ZSB0 aGF0IHRoaXMgcGRmIHNob3dzIHRpbWluZyBmb3IgU0hBLTI1Niwgbm90IEhNQUMtU0hBLTI1Ni4N Cg0KSW5jcmVhc2luZyB0aGUgdGFnIHNpemUgZnJvbSA4IGJ5dGVzIChDQ01fOCkgb3IgMTYgKEdD TSkgdG8gMzIgb3IgNjQgbWF5IGFsc28gaW5jcmVhc2UgdGhlIGxhdGVuY3kgYXMgdGhlc2UgYWRk aXRpb25hbCBieXRlcyBoYXZlIHRvIGJlIHRyYW5zbWl0dGVkLg0KDQovSm9obg0KDQpGcm9tOiBU TFMgPHRscy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgVG9ueSBQdXRtYW4gPFRvbnku UHV0bWFuQGR5c29uLmNvbT4NCkRhdGU6IFdlZG5lc2RheSwgMjcgRmVicnVhcnkgMjAxOSBhdCAx MToxNw0KVG86IEphY2sgVmlzb2t5IDxqbXZpc29reUByYS5yb2Nrd2VsbC5jb20+DQpDYzogIlRM U0BpZXRmLm9yZyIgPHRsc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbVExTXSBBdXRoZW50aWNh dGlvbiBPbmx5IENpcGhlcnN1aXRlcyBSRkMNCg0KSSB0YWtlIG5vIHBvc2l0aW9uIG9uIHdoZXRo ZXIgdGhpcyBpcyBhIGdvb2QgaWRlYSBvciBub3QuIFJlZ2FyZGluZyB0aGUgZHJhZnQgaXRzZWxm LCBJIHdhcyBleHBlY3RpbmcgdG8gc2VlIGEgY2xlYXIgZGVmaW5pdGlvbiBvZiB0aGUgaW50ZWdy aXR5IGNoZWNrIGNvbXB1dGF0aW9uIGluIHRlcm1zIG9mIGFuIEFFQUQtRW5jcnlwdCBjb21wdXRh dGlvbi4uIFNvbWV0aGluZyBhbG9uZyB0aGUgbGluZXMgb2Y6DQogIEFFQUQtRW5jcnlwdC1ITUFD KHdyaXRlX2tleSwgbm9uY2UsIGFkZGl0aW9uYWxfZGF0YSwgcGxhaW50ZXh0KSA9DQogICAgcGxh aW50ZXh0IHx8IEhNQUMod3JpdGVfa2V5LCBub25jZSB8fCBhZGRpdGlvbmFsX2RhdGEgfHwgcGxh aW50ZXh0KQ0KDQpJbiBwYXJ0aWN1bGFyLCBBSVVJLCBub25jZSBtdXN0IGJlIGluY2x1ZGVkIHRv IHByZXZlbnQgcmVwbGF5IGF0dGFja3MuIEFsc28gaW5jbHVkZSBOX01JTiA9IE5fTUFYID0gOCBi eXRlcy4NCg0KLS0gVG9ueQ0KDQpGcm9tOiBUTFMgW21haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIEphY2sgVmlzb2t5DQpTZW50OiAyNiBGZWJydWFyeSAyMDE5IDIwOjU0 DQpUbzogdGxzQGlldGYub3JnDQpTdWJqZWN0OiBbRXh0ZXJuYWwgTWFpbF0gW1RMU10gQXV0aGVu dGljYXRpb24gT25seSBDaXBoZXJzdWl0ZXMgUkZDDQoNCg0KVExTIENvbGxlYWd1ZXMsDQoNCklm IHlvdSByZWNhbGwgd2UgZGlzY3Vzc2VkIGEgZHJhZnQgZm9yIGF1dGhlbnRpY2F0aW9uIG9ubHkg Y2lwaGVyc3VpdGVzIG92ZXIgZW1haWwgYmFjayBpbiBBdWd1c3Qgb2YgMjAxOC4gIFdlJ3ZlIHNp bmNlIG1hZGUgc29tZSB1cGRhdGVzIHRvIHRoYXQgZHJhZnQuICBXZSBhbHNvIGhhdmUgZ290dGVu IElBTkEgYXNzaWdubWVudHMgdG8gdGhlIGF1dGhlbnRpY2F0aW9uIG9ubHkgY2lwaGVyc3VpdGVz IGZvciBUTFMgMS4zIGFuZCBoYXZlIHVwZGF0ZWQgdGhlIGRyYWZ0IHRvIHJlZmxlY3QgdGhlIG5l dyBhc3NpZ25tZW50cy4NCg0KVG8gdGhhdCBleHRlbnQsIGFzIHRoZSBJb1QgY29tbXVuaXR5IGlz IGxvb2tpbmcgdG8gYWRvcHQgdGhlc2UgY2lwaGVyc3VpdGVzLCB3ZSB3b3VsZCBsaWtlIHRvIHNv bGljaXQgcmV2aWV3IG9mIHRoZSBkcmFmdDoNCg0KDQoNCiAgICBodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtY2Ftd2luZ2V0LXRscy10czEzLW1hY2NpcGhlcnN1aXRlcy0wMg0KDQoN Cg0KYW5kIHJlcXVlc3QgdGhhdCBpdCBiZSBwdWJsaXNoZWQgYXMgaW5mb3JtYXRpb25hbCBkcmFm dCBnaXZlbiB0aGF0IHRoZSBJb1QgZm9ydW1zIGFyZSBsb29raW5nIHRvIGFkb3B0IGl0cyB1c2Ug YW5kIHRoZSBkcmFmdCBjYW4gc2VydmUgYXMgdGhlIGd1aWRlIGZvciB1c2UgYW5kIGludGVyb3Bl cmFiaWxpdHkuDQoNClRoYW5rcyBhbmQgQmVzdCBSZWdhcmRzLA0KDQotLUphY2sgKGFuZCBOYW5j eSkNCg0KDQoNCkR5c29uIFRlY2hub2xvZ3kgTGltaXRlZCwgY29tcGFueSBudW1iZXIgMDE5NTkw OTAsIFRldGJ1cnkgSGlsbCwgTWFsbWVzYnVyeSwgU04xNiAwUlAsIFVLLg0KVGhpcyBtZXNzYWdl IGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIGFkZHJlc3NlZSBhbmQgbWF5IGNvbnRhaW4gY29u ZmlkZW50aWFsIGluZm9ybWF0aW9uLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1lc3NhZ2Ug aW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIGl0LCBh bmQgZG8gbm90IHVzZSwgY29weSBvciBkaXNjbG9zZSB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVk IGluIHRoaXMgbWVzc2FnZSBvciBpbiBhbnkgYXR0YWNobWVudC4NCkR5c29uIG1heSBtb25pdG9y IGVtYWlsIHRyYWZmaWMgZGF0YSBhbmQgY29udGVudCBmb3Igc2VjdXJpdHkgJiB0cmFpbmluZy4N Cg== --_000_C75F0D1890FB46F280EB850DF3C76607ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQXJpYWwgTmFycm93IjsNCglwYW5vc2Ut MToyIDExIDYgNiAyIDIgMiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9t YTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9u cyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46 MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQp0dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3Jt YWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5 bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ Y29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iU1YiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+ SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5UaGUgZG9jdW1lbnQgcmVwZWF0cyB0aGUgcmVxdWlyZW1l bnQgb2YgbG93IGxhdGVuY3kgc2V2ZXJhbCB0aW1lcy4gSXQgd291bGQgYmUgaW50ZXJlc3Rpbmcg dG8ga25vdyB3aGljaCBwbGF0Zm9ybXMvbmV0d29ya3MvZGVwbG95bWVudHMgeW91IGhhdmUgaW4g bWluZC4gTXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IEhNQUMtU0hBLTI1NiBvbmx5IGhhdmUgYmV0 dGVyIGxhdGVuY3kNCiB0aGFuIEFFUyBvbiBhIGxpdHRsZSBiaXQgbG9uZ2VyIG1lc3NhZ2VzIHdo ZXJlIHRoZSBsYXJnZXIgYmxvY2sgc2l6ZSBtYXR0ZXJzLiBTaG9ydCBtZXNzYWdlcyBhcmUgY29t bW9uIGluIG1hbnkgSW9UIGRlcGxveW1lbnRzLiBMb29raW5nIGUuZy4gYXQgdGhlIGJlbmNobWFy a3MgYXQgaHR0cHM6Ly9iZW5jaC5jci55cC50byBmb3IgJnF1b3Q7YXJtZWFiaTsgQ29ydGV4LUE1 ICg0MTdmYzA1MSkmcXVvdDsgb24gNjQgYnl0ZSBtZXNzYWdlcywgU0hBLTI1NiBhbG9uZQ0KIHJl cXVpcmVzIHNpZ25pZmljYW50bHkgbW9yZSBjeWNsZXMgdGhhbiBBRVMtR0NNIGZvciA2NCBieXRl IG1lc3NhZ2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+Q3ljbGVzL2J5dGUgZm9yIDY0IGJ5dGVzPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiPjg2LjE0Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDg2LjczJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDkzLjU5Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNoYTI1NjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiI+Q3ljbGVzL2J5dGUgZm9yIDY0JiM0MzswIGVuY3J5cHQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+MjQuMjAmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgMjQuMjAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMjQuMzQmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgYWVzMTI4Z2NtdjE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPk9uIG1v cmUgY29uc3RyYWluZWQgcHJvY2Vzc29ycyBzdWNoIGFzIHRoZSBDb3J0ZXgtTTAsIEFFUzEyOC1D Q00gYWxzbyBzZWVtcyB0byBoYXZlIGxvd2VyIGxhdGVuY3kgdGhhbiBITUFDLVNIQS0yNTYgb24g c2hvcnQgbWVzc2FnZXMgKDM3Njc3IGN5Y2xlcyB2cy4gNDg5MjQgY3ljbGVzKQ0KPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vY3R6L2NpZnJhIj5o dHRwczovL2dpdGh1Yi5jb20vY3R6L2NpZnJhPC9hPi4gT24gbG9uZ2VyIG1lc3NhZ2VzLA0KPC9z cGFuPjxzcGFuIGxhbmc9IkVOLUdCIj5ITUFDLVNIQS0yNTYgbGlrZWx5IGhhdmUgbG93ZXIgbGF0 ZW5jeSAoaHR0cHM6Ly9jc3JjLm5pc3QuZ292L2NzcmMvbWVkaWEvZXZlbnRzL2xpZ2h0d2VpZ2h0 LWNyeXB0b2dyYXBoeS13b3Jrc2hvcC0yMDE1L2RvY3VtZW50cy9wcmVzZW50YXRpb25zL3Nlc3Np b243LXZpbmNlbnQucGRmKS4gTm90ZSB0aGF0IHRoaXMgcGRmIHNob3dzIHRpbWluZyBmb3IgU0hB LTI1Niwgbm90IEhNQUMtU0hBLTI1Ni48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiI+SW5jcmVhc2luZyB0aGUgdGFnIHNpemUgZnJvbSA4IGJ5dGVzIChDQ01fOCkg b3IgMTYgKEdDTSkgdG8gMzIgb3IgNjQgbWF5IGFsc28gaW5jcmVhc2UgdGhlIGxhdGVuY3kgYXMg dGhlc2UgYWRkaXRpb25hbCBieXRlcyBoYXZlIHRvIGJlIHRyYW5zbWl0dGVkLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiI+L0pvaG48L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+ RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFj ayI+VExTICZsdDt0bHMtYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIFRvbnkgUHV0 bWFuICZsdDtUb255LlB1dG1hbkBkeXNvbi5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPldlZG5l c2RheSwgMjcgRmVicnVhcnkgMjAxOSBhdCAxMToxNzxicj4NCjxiPlRvOiA8L2I+SmFjayBWaXNv a3kgJmx0O2ptdmlzb2t5QHJhLnJvY2t3ZWxsLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90 O1RMU0BpZXRmLm9yZyZxdW90OyAmbHQ7dGxzQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6 IDwvYj5SZTogW1RMU10gQXV0aGVudGljYXRpb24gT25seSBDaXBoZXJzdWl0ZXMgUkZDPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGFrZSBu byBwb3NpdGlvbiBvbiB3aGV0aGVyIHRoaXMgaXMgYSBnb29kIGlkZWEgb3Igbm90LiBSZWdhcmRp bmcgdGhlIGRyYWZ0IGl0c2VsZiwgSSB3YXMgZXhwZWN0aW5nIHRvIHNlZSBhIGNsZWFyIGRlZmlu aXRpb24gb2YgdGhlIGludGVncml0eSBjaGVjayBjb21wdXRhdGlvbiBpbiB0ZXJtcyBvZiBhbiBB RUFELUVuY3J5cHQgY29tcHV0YXRpb24uLiBTb21ldGhpbmcgYWxvbmcgdGhlIGxpbmVzIG9mOjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IEFFQUQtRW5jcnlwdC1I TUFDKHdyaXRlX2tleSwgbm9uY2UsIGFkZGl0aW9uYWxfZGF0YSwgcGxhaW50ZXh0KSA9DQo8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O3BsYWludGV4dCB8fCBITUFDKHdyaXRlX2tleSwgbm9uY2UgfHwgYWRkaXRpb25hbF9kYXRhIHx8 IHBsYWludGV4dCk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gcGFydGljdWxhciwgQUlVSSwg bm9uY2UgbXVzdCBiZSBpbmNsdWRlZCB0byBwcmV2ZW50IHJlcGxheSBhdHRhY2tzLiBBbHNvIGlu Y2x1ZGUgTl9NSU4gPSBOX01BWCA9IDggYnl0ZXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0t IFRvbnk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+IFRMUyBbbWFpbHRvOnRscy1ib3VuY2VzQGlldGYu b3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5KYWNrIFZpc29reTxicj4NCjxiPlNlbnQ6PC9iPiAy NiBGZWJydWFyeSAyMDE5IDIwOjU0PGJyPg0KPGI+VG86PC9iPiB0bHNAaWV0Zi5vcmc8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gW0V4dGVybmFsIE1haWxdIFtUTFNdIEF1dGhlbnRpY2F0aW9uIE9ubHkg Q2lwaGVyc3VpdGVzIFJGQzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJn aW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRMUyBDb2xs ZWFndWVzLCA8L3NwYW4+DQo8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGNtO21h cmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPklmIHlvdSByZWNhbGwgd2Ug ZGlzY3Vzc2VkIGEgZHJhZnQgZm9yIGF1dGhlbnRpY2F0aW9uIG9ubHkgY2lwaGVyc3VpdGVzIG92 ZXIgZW1haWwgYmFjayBpbiBBdWd1c3Qgb2YgMjAxOC4mbmJzcDsgV2UndmUgc2luY2UgbWFkZSBz b21lIHVwZGF0ZXMgdG8gdGhhdCBkcmFmdC4mbmJzcDsgV2UgYWxzbyBoYXZlIGdvdHRlbiBJQU5B IGFzc2lnbm1lbnRzIHRvDQogdGhlIGF1dGhlbnRpY2F0aW9uIG9ubHkgY2lwaGVyc3VpdGVzIGZv ciBUTFMgMS4zIGFuZCBoYXZlIHVwZGF0ZWQgdGhlIGRyYWZ0IHRvIHJlZmxlY3QgdGhlIG5ldyBh c3NpZ25tZW50cy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTtt YXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5UbyB0aGF0IGV4dGVudCwg YXMgdGhlIElvVCBjb21tdW5pdHkgaXMgbG9va2luZyB0byBhZG9wdCB0aGVzZSBjaXBoZXJzdWl0 ZXMsIHdlIHdvdWxkIGxpa2UgdG8gc29saWNpdCByZXZpZXcgb2YgdGhlIGRyYWZ0Ojwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFw dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2Ftd2luZ2V0LXRscy10czEzLW1hY2NpcGhlcnN1aXRl cy0wMiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNhbXdpbmdldC10bHMtdHMx My1tYWNjaXBoZXJzdWl0ZXMtMDI8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9 Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46 MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPmFuZCByZXF1ZXN0 IHRoYXQgaXQgYmUgcHVibGlzaGVkIGFzIGluZm9ybWF0aW9uYWwgZHJhZnQgZ2l2ZW4gdGhhdCB0 aGUgSW9UIGZvcnVtcyBhcmUgbG9va2luZyB0byBhZG9wdCBpdHMgdXNlIGFuZCB0aGUgZHJhZnQg Y2FuIHNlcnZlIGFzIHRoZSBndWlkZSBmb3IgdXNlIGFuZCBpbnRlcm9wZXJhYmlsaXR5Ljwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+VGhhbmtzIGFuZCBCZXN0IFJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij4tLUphY2sgKGFuZCBOYW5jeSk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCBOYXJyb3cmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjwvYj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0Ij5EeXNvbiBUZWNobm9sb2d5IExpbWl0ZWQsIGNvbXBhbnkgbnVtYmVyIDAxOTU5MDkw LCBUZXRidXJ5IEhpbGwsIE1hbG1lc2J1cnksIFNOMTYgMFJQLCBVSy4NCjxicj4NClRoaXMgbWVz c2FnZSBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBhZGRyZXNzZWUgYW5kIG1heSBjb250YWlu IGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbi4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtZXNz YWdlIGluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSBp dCwgYW5kIGRvIG5vdCB1c2UsIGNvcHkgb3IgZGlzY2xvc2UgdGhlIGluZm9ybWF0aW9uIGNvbnRh aW5lZCBpbiB0aGlzIG1lc3NhZ2UNCiBvciBpbiBhbnkgYXR0YWNobWVudC4gPGJyPg0KRHlzb24g bWF5IG1vbml0b3IgZW1haWwgdHJhZmZpYyBkYXRhIGFuZCBjb250ZW50IGZvciBzZWN1cml0eSAm YW1wOyB0cmFpbmluZy4gPC9zcGFuPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_C75F0D1890FB46F280EB850DF3C76607ericssoncom_-- From nobody Wed Feb 27 04:30: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 76E64130EC8 for ; Wed, 27 Feb 2019 04:30:26 -0800 (PST) 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 Zokt8M-6g6S3 for ; Wed, 27 Feb 2019 04:30:20 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0078130EC5 for ; Wed, 27 Feb 2019 04:30:19 -0800 (PST) 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 7918FC0ABF51; Wed, 27 Feb 2019 12:30:19 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.83]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4331B5DE86; Wed, 27 Feb 2019 12:30:18 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Date: Wed, 27 Feb 2019 13:30:16 +0100 Message-ID: <2350834.CDpgWZAquZ@pintsize.usersys.redhat.com> In-Reply-To: References: <04D78BE6-2048-4EC0-A191-68AFD8D71A68@sn3rd.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart70516280.FWkIIZ7GgO"; 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.31]); Wed, 27 Feb 2019 12:30:19 +0000 (UTC) Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-grease 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, 27 Feb 2019 12:30:26 -0000 --nextPart70516280.FWkIIZ7GgO Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Wednesday, 27 February 2019 09:54:17 CET Stephen Farrell wrote: > Hiya, >=20 > On 27/02/2019 01:57, Sean Turner wrote: > > This messages closes the WGLC for draft-ietf-tls-grease. The draft > > will progress as is because we received no WGLC comments. >=20 > Apologies for missing the WGLC. I've just read this and fully > support it progressing. I have one question though: >=20 > The drafts says: 'A client MAY select one or more GREASE extension > values and advertise corresponding extensions with varying length > and contents' and 'For each of these, the "key_exchange" field MAY > be any value.' and 'Implementations advertising GREASE values > SHOULD select them at random.' >=20 > I was left wondering what ranges of lengths and what values are > recommended to be sent for greasy extension bytes and key_exchange > values. >=20 > Reason to ask is I happened to be looking at a few handshakes and > noticed those lengths being zero in all cases IIRC. (It was only > 3 cases being one 1 h/s from each of 3 browsers so could be I was > just unlucky or missed a non-zero greasy length.) I'm not sure which part for the key_share extension you mean as being empty= ,=20 but the key_exchange in the KeyShareEntry can't be empty, per RFC 8446,=20 Section 4.2.8: struct { NamedGroup group; opaque key_exchange<1..2^16-1>; } KeyShareEntry; Only the client_shares inside the KeyShareClientHello may be empty: struct { KeyShareEntry client_shares<0..2^16-1>; } KeyShareClientHello; =20 > I've no strong opinion as to what'd be best to say about those > lengths but I guess maybe we'd want to see some greasy lengths > that are shorter than all real values, some that are longer and > many in between, and value octets that that are random when > lengths are non-zero. >=20 > Does that match what people do? If so, would it be worth adding > something about that to the document? >=20 > Cheers, > S. >=20 > PS: Since I'm late to the game I'm fine if the above's treated as > a random last call comment. >=20 > > spt > >=20 > >> On Jan 24, 2019, at 10:50, Sean Turner wrote: > >>=20 > >> This is the working group last call for the "Applying GREASE to TLS > >> Extensibility" draft available at > >> https://datatracker.ietf.org/doc/draft-ietf-tls-grease/. Please > >> review the document and send your comments to the list by 2359 UTC > >> on 8 February 2019. > >>=20 > >> NOTE: There is one outstanding issue raised by Hubert [0]. Please > >> chime in there or here so that we can address his comment one way > >> or the other. > >>=20 > >> Thanks, Chris, Joe, and Sean > >>=20 > >> [0] > >> https://mailarchive.ietf.org/arch/msg/tls/nr4dA2JqcpqAjh-oY_1z2l6ZMFo > >=20 > > _______________________________________________ TLS mailing list > > TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls =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 --nextPart70516280.FWkIIZ7GgO 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+dkqjRuAHS9fUFAlx2gtgACgkQkqjRuAHS 9fXavBAAlqlsshRETHQyxrHc5cZM+UJ+m9WF1LCjALb5Zpx+zaBRtPsyjIaaPaaV Ril/3hmnAgdyRD6PEumKPyAjPvEdpmke3orTmT/neRyIIz8SCFRn+IKD79K2dkb+ SQPM55XLfZnboUtTi7BFq+hZDbkTgEdMztZV1tDiP4u9mNMt6Sqqh91e/IwL6IHg Q124OKmM6Q4peVZw892saUPAneWBL10E/mOyIdKBhkuKIf26NbnaKQ6JxaCl1nn5 szn13ylSKyl1p3e3NnPv4xY5LUzJDZWSaXW0CRCKMlxSfv9dRK0hIZr6P+aIr0nX p1K/9W+YGnFD/UQ969MO0kyOxONyNBLFv8rfLJWy6vCgmjHz9takQRg3a9SETzg7 VgXO30grU9ff47FuVxy4LN1B/PukIRFh20Do42T00QaY4Xqud/jvwoSV0E8uN3Y/ 4g5AC3O9pDTTMghA/B0cIf3A3HF41ykupbzkCVzClrzpXjkEcH8Kem7QLqcSiNx0 gid9Fk8N4IWCyR3n2g50/UaS54fppKWGkvO8GL0HCocoNDgAjLsBip0jZyoQDP0Z oCKq8J1kqoYYEqDdTClO7pzfPYhTUCnY6dn6hyxspDiydjHRe48ogJ9oo4SkJMgR urmyG+pCT3j4ISWXZSHosdka6N6Sx2WfizSqyfm/HGtcTPGS1iY= =a+/2 -----END PGP SIGNATURE----- --nextPart70516280.FWkIIZ7GgO-- From nobody Wed Feb 27 04:53: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 D7A3F130E8F for ; Wed, 27 Feb 2019 04:53:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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] 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 g7QYa_pRKHaO for ; Wed, 27 Feb 2019 04:53:02 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43E8F128D52 for ; Wed, 27 Feb 2019 04:53:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C8257BE55; Wed, 27 Feb 2019 12:52:59 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6cfnZOEExcnq; Wed, 27 Feb 2019 12:52:59 +0000 (GMT) Received: from [134.226.36.93] (unknown [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8B5CFBE53; Wed, 27 Feb 2019 12:52:59 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1551271979; bh=z6SFoNik0N3uSpgr27En+7zarfHbHTNggeM17N0OmZc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=B4dMHhGXbuL5yYdP+UzcoPpUvWNOFum9kwSsWwJ6qi+Urd1q+LcYiH+20yPOkc6Fz 9tmpgXhj+JZlJ3jWy4bzHdjc5VGb5vlmyeNgBO1vfaWkM0jdNtmVlHtp/0+JBEKtFh GMKJF+wTkL655ByjxO/DDhJSdyeaG10IiVh6UT1U= To: Hubert Kario , tls@ietf.org References: <04D78BE6-2048-4EC0-A191-68AFD8D71A68@sn3rd.com> <2350834.CDpgWZAquZ@pintsize.usersys.redhat.com> 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: Date: Wed, 27 Feb 2019 12:52:57 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <2350834.CDpgWZAquZ@pintsize.usersys.redhat.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="H4w9fCbt2EP1peeuxLHjCf675SaZIDB8A" Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-grease 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, 27 Feb 2019 12:53:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --H4w9fCbt2EP1peeuxLHjCf675SaZIDB8A Content-Type: multipart/mixed; boundary="mWkvqaOyekq504jiJEhqAlF6ApxBlKqVG"; protected-headers="v1" From: Stephen Farrell To: Hubert Kario , tls@ietf.org Cc: Sean Turner Message-ID: Subject: Re: [TLS] WGLC for draft-ietf-tls-grease References: <04D78BE6-2048-4EC0-A191-68AFD8D71A68@sn3rd.com> <2350834.CDpgWZAquZ@pintsize.usersys.redhat.com> In-Reply-To: <2350834.CDpgWZAquZ@pintsize.usersys.redhat.com> --mWkvqaOyekq504jiJEhqAlF6ApxBlKqVG Content-Type: multipart/mixed; boundary="------------E342B167BFD4A5376D00165B" Content-Language: en-GB This is a multi-part message in MIME format. --------------E342B167BFD4A5376D00165B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 27/02/2019 12:30, Hubert Kario wrote: > I'm not sure which part for the key_share extension you mean as being e= mpty,=20 > but the key_exchange in the KeyShareEntry can't be empty, per RFC 8446,= =20 > Section 4.2.8: >=20 > struct { > NamedGroup group; > opaque key_exchange<1..2^16-1>; > } KeyShareEntry; Ah sorry, you're right - there is one byte in the key_exchange with a value 0x00 in a greasy KeyShareEntry I just looked at. And a different browser doing tls1.2 sent 2 greasy extensions, one with no data and another with a single byte (0x00 again). I guess my question remains though, as to whether more bytes ought be sent in these fields sometimes and whether or not they also ought be random values. FWIW, I guess it'd make sense to send a range of random length random values some of the time, but mostly I'm wondering what other folks are doing/expecting. Cheers, S. --------------E342B167BFD4A5376D00165B 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 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5tDJTdGVwaGVuIEZhcnJlbGwgKDIwMTcp IDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJCZQmAAUL CQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1yw aps8HGUNhLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG +48od+Xn7qg6LT7GrHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXk kTFaSGYJj3yIP4R6IgwBYGMzDXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRr pZtXB1XQc23ZZmrlTkl2HaThL6w3YKdiTi1NbuMeOxZqtXcUshII45sANm4HuWNT iRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS3MmGgVS4ZoX8+VaPGpXdQVFy BMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml3OEuIQiP2ehRt/HV LMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi2/Jrsz6M zh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6 TzKjGjruq8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxIkBHAQQAQgABgUCWj1SoAAK CRAvPIc2gF+NovMcCACVZPo1cQa3D+vWaIo0ZyinO/MgtD2gHysoj1T0Qvq05//L ZXmhh578bJANvdl2g/HFhhwl/5HKIfWcyipQhmJklp/dsleKcNnn4B18T75RHY0G +po3ILq7evbiOjUH+xqApti1aCxi1GocsPghaLfsxmtXKMG4Xu7XhDTv66GOrqZf Y7+0ekJjD9Dza1t5NE/JR/VZA4B8PWR8Glb0+8C9rkjD0VZ5ekJdHPDGcJmFh8Z+ q25LDoI8Fgt1uKSowvoVnsQO5MFv/y6bXArtj1uB4hAL4JiOFgHlFdrW0MlFpvYm ziW4K9JHTD8KAfDbrb3e2W97ZDpROuYfE/lTbYOWiQI9BBMBCAAnBQJaPVAyAhsD BQkJlCYABQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEFqy+vF7Fyvq0mkP/ius gsf6Z4/Tu+vHzBbl5i6oKI8ZieH8JfEgXx4ut9t7l3hBGC2r7DpR5A8zLMpEhGIK gFcHagksFkfLEE/FmWDfd1MysQafxBYrHaI27P2tkxfI5JYV6247TV39pQ93kGds tsjIrmh/zEJCVczoofxtz72BDt51H2Z8tN28F/YVHnbaGDwFEEzWKYpze87y/f36 ogcdGO6LDEEEIA6Ee0dGxleuKlLS4UDTt0zjo6L8TyiyPHp9C3+UfnP8837Zp3Fh KstIBd+vWgPdHFg2G5aDIYUvrj9UJBvVgaN/RnkwE+dab2OBSg5jkr141JLQvzdZ 4mOUXn5D9Y6AH6tvj0+ubYMV6j35L1/ZXncuXPVYiylcmDp/6f2WYcT3gx9CPUYA cLMjQV4vX2W8z4uEPyMlIJuGsLf7KhvLL8BQ6zlncT6eONfUUX9UJUCzqI5rqL5c b5jWGHeKvbLWRyQnlq5PXQxJTwYRm71rJTgzejc33LE6Nqg/Q25Dgwwsv+f+7i73 gB5loc80Fef+FV9VFGalFe0Yq8m0UASmkYRh7MH5ssoibpeWk+SGfBjOV4tnsAwR yjYLpAzxA8HeDcmlLeypGEDmsQ/iUvXoGaKOYX4Ieg8T/PCAplsqnJUOq8hbkgOC 98gLZfiltkNG8YhQpoZIHj6SxmBRSc3K99CvanuOiQIzBBABCAAdFiEEfhcKBFyE z0YOK3mgEO952f2DUxIFAlu3JJsACgkQEO952f2DUxJ4qRAAmbjiO3WTAeBCB4ME p2N2+XQCMTTFURDGuJnqU/+X//fhhPRq4V/OxgisKFKlBcAS2hsECvg6HDVSz4Fl 74fk/y+botG4/CjMLdKPB9fgh5zz72i3q0hWDixt50NKBv8IIVWOyYgZxDU/vcks lMEnqbFgJX+CfdALpvAM4WjuQP0UMcKNE3xd+EdDhD1xjK3Tq4XfWob9q6aBZgL2 B4IaADCIeDDE1hv0agnSJmMJE7Bti8tNxCCxVRbZtOaxVHXdRUoOx2XTaxFXupxV hbpHRrdFrwq51f6e3bkfkNEZ3fzYpnlbynJ2zL++JO8P3Pq/S6UKEFjEB50i8YgK WuFvGUsQ+YiDgiZU4saqxSBWbfYn3lY6MSSTg8RnXbFIMG3CFImqYk1uhaV+bDjc p0htjzM2F98g7c3o7sWx0bGarId4uhOmpj7JJVQ+lu7Jby6Ocj8n//7qF1Nn11Cw QlCVaeAq5Y5DmZrnww9I3zzOWWyqFkAVCM3GqeRLMvplD6/+O+5FF7XoHzQB47nk OyZtawy/9gssPWZKLv4qHLYS0wGGCiNbCsYy90s3pfeafM0kSxxjIvEz21KT6LJI /awu2ErQFWCkDMFJ1p/97MjPrQ/6d4cPO140V/wyfuWaBiTVqa9mgnb2zn6fYfDH JEvl1UzIx3JCae25tty1+qtnS0i0LlN0ZXBoZW4gRmFycmVsbCA8c3RlcGhlbkB0 b2xlcmFudG5ldHdvcmtzLmNvbT6JAj0EEwEIACcFAlo9UVoCGwMFCQmUJgAFCwkI BwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+o7HBAAxHAdFkBGZ9gJK8w7 NUYS9C6enGYtAYoKH5G3Bn3YScjErNfQtHYb53KwBQpVSOv1HcN8hbQ8mLTgn9lt zNwNSuv0XxIswi807HRSIZ4vYDiS5VKV1YkLYK5bLY5O4alVdzqM+AZQqkuHBu63 6n+C0ED6UwLhVBFfSNvBQVAdoq6gvr+IE8rCIKTMNGwNcgVPbF+YxP7UZM6p7s2a 5MIqGw7URSfaqfuztibXGOBLFbSwLGqHSSnOXBfEeDrwdZ+ur8cXIIPRIeCTVmeO 8bGgpgBqNQXG9oyGN+TrYAC+4Ahi0UjCk7QGj8tf3xICKoQpYyfceNBZJ/969gV9 tVgvRxUjxUwc9kZbi0c8XYMTq5GCvBIh1D6BOW9QBM2SsNgG3l36+e3+c2LDdyKn 20C1IzGLVDdcCtz42/onQ/e9sMlzFrfLjs5SO2/TnLvp2JtsIQXyb/T5qd0GE5j8 /iwfZR+uVTVVEsUl1a+Yllzt6sdR7RIhhKpKaKzEAk4d0+VHdz7zEkQRRSjbPVoS fy8c/kld9Fi8Buna+ZkKpcwIW+D4XP83pGcl0XUv6AyqwS1LnEt+jv/+PSXskYtU Lzn8Z35iKkSAH/5Nz6GCZk6ORPNv/6+UI92BpUbu/G2tBwK8bPgAg+gJxBx3G7MK W7VRCmM5UrtAK9A3O70VjPyMkHSJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLC LAf/X/9vRTZWtwSXxiBCA54a6hg9IvW0mvPUqgXfvrhtOk0IFucLKrTXK8J/NcmU 6ulxOovVbQ+Bin6gtHeCmSa/W523g/NXCOuFTnS/MyVibNL4+RCFwqGysl++Cm+L nj1MmasE9kO+CNdervx8APfxV7D6OYrG4eGag+LdFR6VpJn6tRT0/WvyT8l+Oqiq gdhXHv+0MvkkD9TX5LlJW4VB/yRvWkkmL5N5c5zYh+NcfTPhQ5S9dOorVzrm65d6 Itn0937Ennau7s7fiFdA0BHjWqEAFLsBIXQfCFjjKjdsKA4xlSiX7X7ElmPYpWa5 wwTQ66dL0anMd9y1DJCMOHe4gYkCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9 g1MSBQJbtyScAAoJEBDvedn9g1MSY7sP+gKR0rFU1g+GtB+hSdtwPRbacvml2eL2 Jc5Eq37J9hAqxHyt5V0If7s8IyVA2GXgdfwULBWbXGDUDiUkh20OPQRUS8G9Sf8A WRuG25q5C8ZzWygykL88RKXJZDFtA49CeqO5Bq5syBhq4QfiSTffQHIp3h0boPGU hSBEUQpooMXYQClNARQ+z/uRzR5bUi9wxdXNnxTn9ia4ASlaBPvUYTGY1jW2HrRR SwpI12+UaWsvc3jJtQ8X0kxgJ7jsFF1uqquIZ5eflQv+PHHg2RJSy37u0UFGb+OK ZEkzlmbPokKCYhzBR5PcD6sgdlaJNcidmto9u1oV6yZT8J2W4CTuUclgxt6f3lZq ZeVLnNnbHyKUdeypwLlqYISulfnMhZ3A6Bgpf2BtjL6KJbFtPBYmYdxI+HZyY49u U2ZHhRu+CSQ1y7zGKSX0gRp5hE7+A4XJtsT6lTLhbi9aiZTG1S6zKNhl3qNNzszc r27PrvFiyGhpuYQuzdQl2PMGbOI6Ojif3sab53NO3RLsLOM09wIlr95yKLlkXkUr WcvUJGrw6HKm8j5opXHTwmJOAbDpc6cMDu+ITRu4spdCnQJcE8RkO8tKyaLuh2Gt U5kYSBK97yr5VviX1FK6rY14LLmnE16OPiK2tiVBKy9nGM0DKtY+K9WcoRZ7s/d7 O0bMfzcNPtGLuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiez GPuBHmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9Wf pHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC 6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2 D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFe A7PbTuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ /Vf3vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbpt PEcmoazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKr em5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96 Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYgh x8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQ oqj1gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P /1tF6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8 Wpfdn3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJ gx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5 SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2 oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIA ypqYo3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoM eDQkd0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS /qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZ IMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XO KVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DJ121 -----END PGP PUBLIC KEY BLOCK----- --------------E342B167BFD4A5376D00165B-- --mWkvqaOyekq504jiJEhqAlF6ApxBlKqVG-- --H4w9fCbt2EP1peeuxLHjCf675SaZIDB8A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlx2iCkACgkQWrL68XsX K+o/Bw/9EXSgDiOLYk+0MRXBdPXBDzMmYTSuJgQWq6qrowKSsvh2Rsma12FLkwZg TQ7UilCx2z+IYOC/nE87/EAd9289RCNF6n0H5U/l061BGxlvLGzLYrplcqgP4if1 9ofJlwXqCebXJVf75xpt8QaEIIjYMdPFlhGBPksTNs9QQNd7qHDLfQwoUZQLszru /mm2ch8/4YAD8+N9hsAf3GVT2/0fHhIa5jZavJAiFnw2Ikg5MD9yRqGcC1GJV7FG OSBC1He+Ct4SlAiIyYEzDuy31wU/nUUf/wPRgRJSOpTnD4XoGfmNF6Awq5lsp1dj 5xeathhTyhMQnzpKJZKP0A1nm0nfluU2hcMlxMDEli0W2kVlTofdtrAVHUlYxf26 Gl+62JyS6AFcR1lsPDwpXniglU1k/bJ+w9CzhhiIYn7IZ/BNhlWKGbeP2VrX2NCo iLWknkUfbzPAqPmMXF84i1UjidLNKm4k5ylVoL619EHu2hLR9IrvjlNU+ppBDtpO VoQAE1OWV0DWHKgasTz7J1D1lxJv1kRGLQzWS+viz/NgGRuVAz0TaazexxuKfwkK vC91MKI+q+W2XiQGCko9qmzD/Xzc5RZLKG58vaPcj1wHV5kGqsK9hLjdUz3LjVC5 qnsxPQDMfDYJADoTfvwVdRIVO0wrZm1me4phdfwFIErWDg12wvw= =EWiH -----END PGP SIGNATURE----- --H4w9fCbt2EP1peeuxLHjCf675SaZIDB8A-- From nobody Wed Feb 27 05:04: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 F0953130ED8 for ; Wed, 27 Feb 2019 05:04:48 -0800 (PST) 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 N9jBjV5-CsTN for ; Wed, 27 Feb 2019 05:04:47 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80058130EFE for ; Wed, 27 Feb 2019 05:04:47 -0800 (PST) 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 1CD20309CC34; Wed, 27 Feb 2019 13:04:47 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.83]) by smtp.corp.redhat.com (Postfix) with ESMTP id 5D1705DE74; Wed, 27 Feb 2019 13:04:45 +0000 (UTC) From: Hubert Kario To: Stephen Farrell Cc: tls@ietf.org, Sean Turner Date: Wed, 27 Feb 2019 14:04:35 +0100 Message-ID: <1872983.0tcYmgc3Yv@pintsize.usersys.redhat.com> In-Reply-To: References: <2350834.CDpgWZAquZ@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart18694012.8YQ8GdCfQY"; 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.48]); Wed, 27 Feb 2019 13:04:47 +0000 (UTC) Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-grease 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, 27 Feb 2019 13:04:49 -0000 --nextPart18694012.8YQ8GdCfQY Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Wednesday, 27 February 2019 13:52:57 CET Stephen Farrell wrote: > On 27/02/2019 12:30, Hubert Kario wrote: > > I'm not sure which part for the key_share extension you mean as being > > empty, but the key_exchange in the KeyShareEntry can't be empty, per RFC > > 8446,>=20 > > Section 4.2.8: > > struct { > > =20 > > NamedGroup group; > > opaque key_exchange<1..2^16-1>; > > =20 > > } KeyShareEntry; >=20 > Ah sorry, you're right - there is one byte in the > key_exchange with a value 0x00 in a greasy KeyShareEntry > I just looked at. >=20 > And a different browser doing tls1.2 sent 2 greasy > extensions, one with no data and another with a single > byte (0x00 again). that's ok, the extensions in general can have empty payloads =20 > I guess my question remains though, as to whether more > bytes ought be sent in these fields sometimes and whether > or not they also ought be random values. >=20 > FWIW, I guess it'd make sense to send a range of random > length random values some of the time, but mostly I'm > wondering what other folks are doing/expecting. for extensions doing an empty one and one with just few bytes should be=20 sufficient =46or key_share, to simulate actual use I'd say the values should be at lea= st=20 few dozen bytes long. That does inflate unnecessarily the ClientHello, so i= t's=20 a balancing act... =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 --nextPart18694012.8YQ8GdCfQY 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+dkqjRuAHS9fUFAlx2iuMACgkQkqjRuAHS 9fWn/Q/+Iows0MXhz2FcDKoppk1BN5FzSLGA5HOrNd71b3rHdiZOP0zoKwBKmxLS /zI8VC1pbGQ2Qp+ioXvm6BUF3ldgsFMEIzg0hr3wMY5dXu9/gHomSrqlX1ceKgMD 0ijEnJnupRbMNeiYMHLtclgjHc3iADBpzPy+y70S7q6mAOeh3H5tOcDuj4+wIC22 Uifgd+ipO+E1weEbdNhmjb2wTmKEYOCAA/mJGm3vEci6wwFN7n6j8d3FX+PPCgFZ LvRLYiiZ+AdZNh1c5DDTbLIN+1rjz1zry7WvazLNeLZ6YRoYw1DRTRDGrDzL6Aju 3Lf1A4fU+OUwEyW2I3zY2ghEDplByz27dx2P9+MAn8t/LKF2u8rjLBskr50AFwda WQqTgugIUor49cDzOx7dWa6GF3+Ph6jVBstBQezhCRmRkidkuJYA3kqgVMUaWTlk y8k6k1EnugL8CAnGguRUIOBwQRo9Ay3eDryOaYh3TRRTzKLp6M7WL9JZGXxidkHK 0IBpwPIBDNrWOBOklTbrb186PhYYlREWGdmCCBeX0Jd3z3+yXHxAA3jVCjPZATJc kPSz4J9Fe6jfRxbcOONLKwM+7fBRjahrjkhY8qu0Sh9lnIQpzDZB5cbrqAZj2ABD dgx2edCtfSs6gRdo2/nBNgrFt4SN6aNU4BzKeJDcJp45T3B/Fxc= =57Yr -----END PGP SIGNATURE----- --nextPart18694012.8YQ8GdCfQY-- From nobody Wed Feb 27 08:18: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 9024C130FF0 for ; Wed, 27 Feb 2019 08:18:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 gXc_Csoiufsr for ; Wed, 27 Feb 2019 08:18:40 -0800 (PST) Received: from mail-yw1-xc35.google.com (mail-yw1-xc35.google.com [IPv6:2607:f8b0:4864:20::c35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B80DA1200B3 for ; Wed, 27 Feb 2019 08:18:40 -0800 (PST) Received: by mail-yw1-xc35.google.com with SMTP id v201so8517076ywa.9 for ; Wed, 27 Feb 2019 08:18:40 -0800 (PST) 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=YtiTG7OsAjcDXUuhfmoLYaQNF47FPXl5vLFTVuoRFZg=; b=gm0URsij2pyEoqaUin1hnJjD534zHiALzdYGW1V9lNCQnOrXN/lm9jin4rXT9t4x57 tOZKF5yOYaEUZcBkcuMyYjn9yoPZYCpM4+h7GUmQWIa1vXku3+Og5dUBHbUOS8geg0n0 +FVaBbatUBEzhs68fdBscnSo01sfsIZ1/DyM3tePbCKjrBPRSA2XXVSW+IynZghbpAVD r/cDoHagA4gjDUq+8S/K6pyW4cIxxf7VB5nu8d9TYrd/GG0iSyZwMWQrhgNn4ZKgYx1D l9M4H3TJmXe6/utRwVeVfaSssaOD2LJZtoyzJbwmzdMp9krnVYYqQZtnvGhAkEeBCspk Z8jA== 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=YtiTG7OsAjcDXUuhfmoLYaQNF47FPXl5vLFTVuoRFZg=; b=XMaqeupO8irqB7wR3u2oFPja5bpLmckGIBd+U1MFXl46Gg3i5PgFs5npbC/lXV+Tc8 wdiSbwkO1uCrh5K6uhCH/nm3y0EnS/CObcuivg8fyJmvMUS8Zd0PoiVPZ9rEux6buXmE 1jN82+qL4t1fs21bXfhCKi+1PEFj+cW0KGroqcl6EXdT0nhfaQmeVc2W7Xa9cun8YNlL 4KPUqPjYUiUEVnwtRiUsxgL8qlvICKUZsBGsZS3E3jNTpiZSjQEo12OtKlDCLV5DSiwy eUtXy+5DutXCnB3gDlAaXIuT1KrokZ5H73lTKSNq9sWeNiO0AxKOcoN9OXbboId7ithU WjNA== X-Gm-Message-State: AHQUAuZgQhnUsPqZGAn+P3spfnOwPzUhzzPNdmqJS1H+SvLjHOxcU5+G z9leVAMhzwYajGwuIzF+CBswCWHZBGTUXMOaTF01EJqZb7k= X-Google-Smtp-Source: AHgI3IYVw0lfCvKk7HGsSefE2+JdmBbFC9O1lC6MMEC7512ssCUih86iHPGDaJytYHaB7YaevomWeax8IiXeW7G78b4= X-Received: by 2002:a81:83c1:: with SMTP id t184mr1811259ywf.350.1551284319502; Wed, 27 Feb 2019 08:18:39 -0800 (PST) MIME-Version: 1.0 From: Christopher Wood Date: Wed, 27 Feb 2019 08:18:28 -0800 Message-ID: To: "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [TLS] Two Multi-CDN proposals 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, 27 Feb 2019 16:18:43 -0000 Hi folks, Below are two PRs that seek to address the multi-CDN issue discussed on this list and in meetings: 1. https://github.com/tlswg/draft-ietf-tls-esni/pull/136 2. https://github.com/tlswg/draft-ietf-tls-esni/pull/137 #136 implements the combined or stapled record approach discussed several times, most recently in [1]. It includes these via an ESNIKeys extension. #137 builds on this design with a mechanism that lets clients detect and recover from A/AAAA and ESNI mismatch (if desired). It is certainly more complex in several respects. A third variant, which is not (yet) in PR form, is a simplification of #137 wherein ESNIKeys addresses are only used as filters, instead of filters *or* complete addresses. We are asking for feedback on these PRs, as we would like to merge one of them for the next draft version. As #136 is simpler and permits extensibility, that is the current preference. Thanks in advance for your feedback. Best, Chris (no hat, on behalf of the authors) [1] https://mailarchive.ietf.org/arch/msg/tls/WXrPgaIsIPItDw3IQthmJk9VRlw From nobody Wed Feb 27 09: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 29A72131041 for ; Wed, 27 Feb 2019 09:04:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ra.rockwell.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 pyfjtcjiQIcc for ; Wed, 27 Feb 2019 09:04:01 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-eopbgr790051.outbound.protection.outlook.com [40.107.79.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 628EF131023 for ; Wed, 27 Feb 2019 09:04:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ra.rockwell.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=i23Me99LLrVAuxDUKPUkRB5g1TrJ6/rbzpeBsgZWGfw=; b=TIzaTZRICh1A7pN9jrJ703jUc+QCI5EfYNAGNX5oAejlE61jJLDvlHfN0Reb3hHU+tHrvAGRJb8oC5RT0OAyRFbyTWpSUoOXZqwzfTUZtdW4iJdr5+1QJnfrs3XCrODXTSPrE3cFPMJwA3Eu5B8so/YRDXz59l4bFDc5UfajWHc= Received: from BN6PR2201MB1092.namprd22.prod.outlook.com (10.174.88.29) by BN6PR2201MB1492.namprd22.prod.outlook.com (10.174.89.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.14; Wed, 27 Feb 2019 17:03:59 +0000 Received: from BN6PR2201MB1092.namprd22.prod.outlook.com ([fe80::dd5e:b340:8fa8:b113]) by BN6PR2201MB1092.namprd22.prod.outlook.com ([fe80::dd5e:b340:8fa8:b113%5]) with mapi id 15.20.1665.015; Wed, 27 Feb 2019 17:03:59 +0000 From: Jack Visoky To: =?utf-8?B?SGFubm8gQsO2Y2s=?= CC: "tls@ietf.org" Thread-Topic: EXTERNAL: Re: [TLS] Authentication Only Ciphersuites RFC Thread-Index: AdTOFIIaiE+qoBOKQdSotuuQ5A30qAAAjqKAAAB8szAAGaEngAAPRODQ Date: Wed, 27 Feb 2019 17:03:59 +0000 Message-ID: References: <20190226220335.0d75968f@computer> <20190227103123.3b2af774@computer> In-Reply-To: <20190227103123.3b2af774@computer> 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=jmvisoky@ra.rockwell.com; x-originating-ip: [205.175.250.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6088dbdf-fef9-4229-1ca7-08d69cd5914e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7153060)(7193020); SRVR:BN6PR2201MB1492; x-ms-traffictypediagnostic: BN6PR2201MB1492: x-ms-exchange-purlcount: 1 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtCTjZQUjIyMDFNQjE0OTI7MjM6VVhsRTFWbi9WVnc0STZrZmZoSXVVSWhS?= =?utf-8?B?UGgzUHliRUg4UExOZGNpajBUaXhZRnRrZlNSNkhNcS93RW45VEhmTUNOcHlj?= =?utf-8?B?cTdjZk44Q2hZWEV5UmJTMFJqVmV6TjQwSkhpRGdhUFNEd2FxdE5Jc2NISm5C?= =?utf-8?B?dEJYWEJxWkMvS2g5N2xuMyt6bVd5VFhGR0dCbG44c0tiV0tOWlZrM2RDOXU3?= =?utf-8?B?T0dGWlM0dWpwMG5TcUtFbW5hRDRaYVIyU1IyRmxPY3hVN1FFeWg5MDVXYW95?= =?utf-8?B?YTZmR2JYdFpLcEQ5aVFObDFnckkwNEgzNmtzV3lxcElJNFRiaEdCV05UT1NF?= =?utf-8?B?OE0yQmZKSlhUY1Z3Z1o0aU9sNzJvMUZzcHVWQ0RFbXJNSE9lZTFkVnNOVWVi?= =?utf-8?B?ZFk1RERRNWpiY3Z3ZHdsYno3OXFieGl3TlBuRFZmM0srd1ZrNXJ0STlmY1V6?= =?utf-8?B?bThEcWZYL2dLOWdOMW1WR29rb0NPT1pvbTlZcnljZ0k0ekpFeDhCeXdUWWMx?= =?utf-8?B?dUZOKzVPYVZ0M0lueFUzbnhYcCtnRU9BT3htMUovd2tNYjRCRngrR1c4cS9R?= =?utf-8?B?NFZzSnZVOGFMUGhnTkg0NGRJNlF0T0l0YjNscnVkZEs2dkE3ZHoyNXRXblJO?= =?utf-8?B?d0JVTXRxc2YvbG1BTGhwTk5Xa3g5YnFzQzdTTElGMDJYS3U1MVJ4UWlGbE5I?= =?utf-8?B?c2hmZk5mSlpCdzBTQ2txWk00VGxYazBEN2VvRW9rR2VIczI4TitydGwyejVs?= =?utf-8?B?NjZ0Mk5Ubm9wYzVESi94c0hKQldURGczNEIvMStSSGZrNnNZMDB5MkpMNmZM?= =?utf-8?B?VUJDbmRXUjZnOGtRWDVWZEFUY1FNRzFidmprUU9YR043cUxEZko1SE94QWkz?= =?utf-8?B?eG5tc2c4S05KYUVXZm1kcXFURktqcTdMNlV5SlZSLy9Pcm5hQm9UUWtZTm9W?= =?utf-8?B?WGNacmpzL0ZCZ2UyU0dnVHVtcFErbE9aaGRsR0JCYnZRbzN2NW1DMEN4TC9T?= =?utf-8?B?ZTJ6b3dLNWNQTEM5Q0VKVWpIYmFaNVhJZndrQmlNem5SelRac2Z6cEZ5ajdP?= =?utf-8?B?VEtrQUVSZVFVUU5HRmp2ZFNvYitHNzEwdlJlbHQ1cUM3SVZ2SWhkRGtjUERq?= =?utf-8?B?SFcrN2x6V3REdDlWZldoL0phNkxpd3krTHhwWkxTVENJMENMandmSXIrZ0wy?= =?utf-8?B?TXBSQ3J0SUdIMmVDS2x1NGNLQlZPS3dJWGw0VFA0YnVLcnIxZElzQU5jOUxz?= =?utf-8?B?cng1MmoxY0lCVEp2cWRIeldFaTVaYmJGQVRHTEhubWlNS3ZUNVAxY3JpQnkw?= =?utf-8?B?YytjZXhYbmJZb3FWeHpsT2RqL1hjUUdSOFAyaXVPOU9hdUNsbWdGY3R4V2l3?= =?utf-8?B?KzdxM1pxV3FrTTU2WjNDTmFzclRLeTJ4T3p2UThUajNiNGtCZndST0JkeWl0?= =?utf-8?B?UEZNUmFmUnM2dWplR1ZycVJBMXZPY3VSc3BzVHR1YUROb3JUUElDWnVyY1pp?= =?utf-8?B?UmxRQyt0Kzg3c3cxWWF6SlJkdVdjL2FKdDhqUUFhL2JhS1JmKzIzOW01OTlE?= =?utf-8?B?T25Sbk1xeGtHdHIxN1JuQkYwOS9PMW1sODZKUmwzeDN1QmV5eENKYjgxWk9C?= =?utf-8?B?MFpoYVpMRzFydVE2K09aa2wzUGM5bFM4QjNEcG9CUGhQb3FRNFdaQlZDREpv?= =?utf-8?B?R2VFYjhzMEw4NDBQaVFqKzZDWVJMZis5N1o5TzgzSE14Mis1eWhDZC9TUnJB?= =?utf-8?B?ZzBnRWk1dktTKzZVN1MyOWZqM3BnY2NNV0pNYXB0SzBNVU5rTmJ5bEtHZnNj?= =?utf-8?Q?ur8qRuM15zyvFXc?= x-microsoft-antispam-prvs: x-forefront-prvs: 0961DF5286 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(366004)(346002)(136003)(376002)(189003)(199004)(13464003)(102836004)(25786009)(6916009)(93886005)(6506007)(316002)(97736004)(66066001)(33656002)(86362001)(53546011)(68736007)(14444005)(5660300002)(6246003)(478600001)(256004)(71190400001)(71200400001)(4326008)(305945005)(14454004)(6306002)(105586002)(52536013)(26005)(8676002)(966005)(9686003)(81166006)(66574012)(53936002)(11346002)(3846002)(76176011)(6116002)(446003)(186003)(81156014)(99286004)(8936002)(229853002)(6436002)(55016002)(2906002)(7696005)(476003)(486006)(7736002)(106356001)(74316002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR2201MB1492; H:BN6PR2201MB1092.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ra.rockwell.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: yquN+2oXKjAtBI3SAYcln+AcUN+npF5RL7Kb2bY+F8pWNRK6GC5yF1XrG3I8G439nt8uIa7//R0EfMIO1IUBOeseknGJ/943GOUPDc7cZL12aDPUny2VggDfIzksDntXyn2/Og1e4HGSdqx6a7lwZcCCVCtqqDCtQjT/xP6RlGdGPWeSu1PUoB4zkP6JQVOG5kp9dhskC9cy66ckeBBe4CSZYykbnCCm3kJcavTnJ4GncD6diYLKhg9dks6ins6nLPZFYqwDqc29Et5qk17b29ww99upwEe/5hgpB4j2tDtB+tb777HN2gp2OBRnroH4TQawdg0FZJ1Jz5LWWKDlORbl1J4ScNS7wza4sek5er6IOi7DVMkIrTMSBeXogR8rFD5jhb91CnCVYrHhItuQXwXFPyaYy0NACJhnr1o7jOg= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ra.rockwell.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6088dbdf-fef9-4229-1ca7-08d69cd5914e X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2019 17:03:59.7865 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 855b093e-7340-45c7-9f0c-96150415893e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR2201MB1492 Archived-At: Subject: Re: [TLS] EXTERNAL: Re: Authentication Only Ciphersuites RFC 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, 27 Feb 2019 17:04:08 -0000 SGkgSGFubm8sDQoNCk5vLCB0aGUgdGVzdHMgaGF2ZSBub3QgYmVlbiBwdWJsaXNoZWQuICBJIGNh biBsb29rIGF0IHRyeWluZyB0byBtYWtlIHRoaXMgZGF0YSBwdWJsaWNseSBhdmFpbGFibGUgYnV0 IEkgY2Fubm90IGd1YXJhbnRlZSB0aGF0Lg0KDQpUZXN0cyB3ZXJlIGdlbmVyYWxseSBkb25lIHdp dGggQUVTIGFuZCBTSEEgaGFzaGluZy4gIE9uZSByZWFzb24gZm9yIHRoaXMgaXMgdGhhdCBtYW55 IGluIHRoaXMgaW5kdXN0cnkgaGF2ZSBpbmNvcnBvcmF0ZWQgc29tZSBoYXJkd2FyZS1iYXNlZCBj cnlwdG8gYWNjZWxlcmF0aW9uIGludG8gcHJvZHVjdHMsIGFuZCBpdCdzIGJlZW4gdGhlIGNhc2Ug dGhhdCB0aGlzIGhhcmR3YXJlIGhhcyBub3QgaW5jbHVkZWQgQ2hhQ2hhMjAuICBBbHRob3VnaCBm dXR1cmUgcHJvZHVjdHMgY2FuIGluY2x1ZGUgQ2hhQ2hhMjAsIGluIHNvbWUgaW5kdXN0cmllcyAo bGlrZSBJbmR1c3RyaWFsIEF1dG9tYXRpb24pIGhhcmR3YXJlIHN1cHBvcnQgY2FuIGVhc2lseSBz cGFuIDIwIHllYXJzLCBzbyB0aGUgaW5zdGFsbCBiYXNlIG9mIHByb2R1Y3RzIHdpdGhvdXQgQ2hh Q2hhMjAgaXMgbm9uLXRyaXZpYWwuDQoNCkkgZG8gdGFrZSB5b3VyIHBvaW50IGFyb3VuZCBpbXBs ZW1lbnRhdGlvbiBwaXRmYWxscywgYW5kIEkgcmVhbGl6ZSB0aGF0IGZvciB0aGUgdXNlIGNhc2Vz IHRoYXQgbW9zdCBvbiB0aGlzIGxpc3QgaGF2ZSBpbiBtaW5kIChlLmcuIEludGVybmV0LWJhc2Vk IHdlYiBjb21tdW5pY2F0aW9ucykgYSBjaXBoZXIgbGlrZSB0aGlzIGRvZXMgbm90IHNlZW0gdXNl ZnVsIGF0IGFsbC4gIEhvd2V2ZXIgdGhlcmUgYXJlIGEgbG90IG9mIElvVCBkZXZpY2VzLCBhbmQg ZXNwZWNpYWxseSBpbmR1c3RyaWFsIGRldmljZXMsIHRoYXQgd291bGQgcmVhbGx5IGJlbmVmaXQg ZnJvbSBiZWluZyBhYmxlIHRvIHVzZSBUTFMgMS4zIHRvIHNlY3VyZSB0aGVpciBjb21tdW5pY2F0 aW9ucy4gIFRoZXNlIGRldmljZXMgYXJlIGdyb3dpbmcgcmFwaWRseSBpbiBjb25uZWN0aXZpdHkg c28gY29tbXVuaWNhdGlvbnMgc2VjdXJpdHkgaXMgYmVjb21pbmcgbW9yZSBhbmQgbW9yZSBpbXBv cnRhbnQvcHJlc3NpbmcuICBJIGRvbid0IHJlcHJlc2VudCBhIGxpYnJhcnkgdmVuZG9yIGJ1dCBJ J2QgdGhpbmsgdGhpcyBiZWluZyBvcHRpb25hbCB3b3VsZCBsZW5kIGl0c2VsZiB3ZWxsIHRvIGJl aW5nIGNvbXBpbGVkIG91dCBvZiBhIGxpYnJhcnkgdW5sZXNzIG5lZWRlZC4NCg0KVGhhbmtzLA0K DQotLUphY2sgIA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSGFubm8gQsO2 Y2sgPGhhbm5vQGhib2Vjay5kZT4gDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI3LCAyMDE5 IDQ6MzEgQU0NClRvOiBKYWNrIFZpc29reSA8am12aXNva3lAcmEucm9ja3dlbGwuY29tPg0KQ2M6 IHRsc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IEVYVEVSTkFMOiBSZTogW1RMU10gQXV0aGVudGlj YXRpb24gT25seSBDaXBoZXJzdWl0ZXMgUkZDDQoNCkhpLA0KDQpPbiBUdWUsIDI2IEZlYiAyMDE5 IDIxOjI2OjQ1ICswMDAwDQpKYWNrIFZpc29reSA8am12aXNva3lAcmEucm9ja3dlbGwuY29tPiB3 cm90ZToNCg0KPiBXZSBoYXZlIGRvbmUgdGVzdHMgb24gdGhpcyBhbmQgaXQgdGhlcmUgaXMgYSBk aWZmZXJlbmNlLg0KDQpIYXZlIHRoZXNlIHRlc3RzIGluIGFueSB3YXkgYmVlbiBwdWJsaXNoZWQ/ IEJlY2F1c2Ugb3RoZXJ3aXNlIGl0J3MgYSB2ZXJ5IHdlYWsgYXJndW1lbnQuDQoNClRoZXJlIGFy ZSBzb21lIG9idmlvdXMgcXVlc3Rpb25zLCBlLmcuOg0KKiBXaGF0IGFsZ29yaXRobSBpbXBsZW1l bnRhdGlvbiB3YXMgdGVzdGVkLCB3YXMgaXQgb3B0aW1pemVkIGZvciB0aGUNCiAgYXJjaGl0ZWN0 dXJlIGluIHF1ZXN0aW9uIGFuZCB3YXMgaXQgY29uc2lkZXJlZCB3aGV0aGVyIHRoZQ0KICBvcHRp bWl6YXRpb24gY291bGQgYmUgaW1wcm92ZWQgb3IgbWF5YmUgZXZlbiB3aGV0aGVyIGFscmVhZHkg YSBtb3JlDQogIG9wdGltaXplZCBpbXBsZW1lbnRhdGlvbiBleGlzdHM/DQoqIEhhdmUgeW91IHRy aWVkIGJvdGggQUVTIGFuZCBjaGFjaGEyMD8gQW5kIGluIGJvdGggY2FzZXMgdGhlIG1vc3QNCiAg b3B0aW1pemVkIGltcGxlbWVudGF0aW9uIGZvciB0aGUgdGFyZ2V0IHBsYXR0Zm9ybT8NCiogSWYg dGhlIGJvdHRsZW5lY2sgaXMgdGhlIGNpcGhlciBoYXZlIHlvdSBjb25zaWRlcmVkIHdoZXRoZXIg YQ0KICBkaWZmZXJlbnQgY2lwaGVyIHRoYXQgcHJvdmlkZXMgcmVhc29uYWJsZSBzZWN1cml0eSwg YnV0IGNhbiBiZQ0KICBpbXBsZW1lbnRlZCBiZXR0ZXIgb24gbGlnaHR3ZWlnaHQgaGFyZHdhcmUs IHdvdWxkIGJlIGFuIGFsdGVybmF0aXZlPw0KICAoTm90IGtlZW4gaGF2aW5nIHRoYXQgb3B0aW9u LCBJIGJlbGlldmUgZmV3ZXIgb3B0aW9ucyBhcmUgYmV0dGVyLikNCg0KPiBUaGlzIHByb2JhYmx5 IGdvZXMgd2l0aG91dA0KPiBzYXlpbmcgYnV0IG9mIGNvdXJzZSB0aGUgYmVzdCBsaW5lIG9mIGRl ZmVuc2UgaXMgdG8gcHJvcGVybHkgZGVzaWduLCANCj4gYnVpbGQsIGFuZCBjb25maWd1cmUgdGhl IGltcGxlbWVudGF0aW9uLg0KDQpJJ20gaW5jbGluZWQgdG8gc2F5IHRoYXQgdGhpcyBpcyBhbiBv dXRkYXRlZCB2aWV3IG9mIGhvdyB0byBiZXN0IGRvIHNlY3VyaXR5IGluIHByb3RvY29scy4NCldl IGhhZCBwbGVudHkgb2Ygc2l0dWF0aW9ucyBpbiB0aGUgcGFzdCB3aGVyZSB0aGUgVExTIHNwZWMg d2FzIGEgbWluZWZpZWxkIG9mIHBvc3NpYmxlIGltcGxlbWVudGF0aW9uIG1pc3Rha2VzIHRoYXQg bGVkIHRvIGxvbmcgZGVzY3JpcHRpb25zIG9uIGhvdyB0byBwcm9wZXJseSBkZXNpZ24gdGhpbmdz IHRvIGF2b2lkIHRoZXNlIG1pc3Rha2VzLg0KSGlzdG9yeSBzaG93cyBpdCBkaWRuJ3Qgd29yay4g KExldCBtZSBqdXN0IHRocm93IGluICJQYWRkaW5nIE9yYWNsZXMiIG9yICJCbGVpY2hlbmJhY2hl ciBhdHRhY2tzIiBhcyB2ZXJ5IG9idmlvdXMgZXhhbXBsZXMuKQ0KDQpNeSB0YWtlYXdheSBhbmQg SSBiZWxpZXZlIHRoYXQgb2YgbWFueSBwZW9wbGUgaXMgdGhhdCB0aGUgcHJvdG9jb2wgc2hvdWxk IGF2b2lkIGltcGxlbWVudGF0aW9uIHBpdGZhbGxzIHdoZXJlZXZlciBwb3NzaWJsZS4gQW5kIEkg YmVsaWV2ZSBhbiBhdXRoZW50aWNhdGlvbi1vbmx5IGNpcGhlcnN1aXRlIGlzIGEgZGFuZ2Vyb3Vz IGltcGxlbWVudGF0aW9uIHBpdGZhbGwuDQoNCg0KLS0NCkhhbm5vIELDtmNrDQpodHRwczovL2hi b2Vjay5kZS8NCg0KbWFpbC9qYWJiZXI6IGhhbm5vQGhib2Vjay5kZQ0KR1BHOiBGRTczNzU3RkE2 MEU0RTIxQjkzNzU3OUZBNTg4MDA3MkJCQjUxRTQyDQo= From nobody Wed Feb 27 09:05:22 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 E0D52131068 for ; Wed, 27 Feb 2019 09:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=ra.rockwell.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 KRhQv5t8eqhI for ; Wed, 27 Feb 2019 09:05:12 -0800 (PST) Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-eopbgr690049.outbound.protection.outlook.com [40.107.69.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23EDB1310CA for ; Wed, 27 Feb 2019 09:05:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ra.rockwell.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=as2wFEQDpwjhIZJjtQ1qSr6GS+w7AlUQuB+0YuJmSzQ=; b=KQ5TVRvIuU8stin8SA+IEqmb1uc2dbkJTXgE6xqyhyb/aaGo2kbAkhZ/Sr3iGoG9sFRPJsJdqQ+RFXUFneuay9eWvdN22O4bU7etfWCfymsWu4/GwQunTXxvCaTeCwCpdYll4mZEDyPy5itPAldnrY+FrlAXZ0NI2vM+/ZUvFM4= Received: from BN6PR2201MB1092.namprd22.prod.outlook.com (10.174.88.29) by BN6PR2201MB1186.namprd22.prod.outlook.com (10.174.85.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.15; Wed, 27 Feb 2019 17:05:10 +0000 Received: from BN6PR2201MB1092.namprd22.prod.outlook.com ([fe80::dd5e:b340:8fa8:b113]) by BN6PR2201MB1092.namprd22.prod.outlook.com ([fe80::dd5e:b340:8fa8:b113%5]) with mapi id 15.20.1665.015; Wed, 27 Feb 2019 17:05:10 +0000 From: Jack Visoky To: David Wong , =?utf-8?B?SGFubm8gQsO2Y2s=?= CC: "" Thread-Topic: EXTERNAL: Re: [TLS] Authentication Only Ciphersuites RFC Thread-Index: AdTOFIIaiE+qoBOKQdSotuuQ5A30qAAAjqKAAAPYEoAAJhYTEA== Date: Wed, 27 Feb 2019 17:05:10 +0000 Message-ID: References: <20190226220335.0d75968f@computer> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jmvisoky@ra.rockwell.com; x-originating-ip: [205.175.250.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0e2d5f78-d2f3-4531-fb90-08d69cd5bb63 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7153060)(7193020); SRVR:BN6PR2201MB1186; x-ms-traffictypediagnostic: BN6PR2201MB1186: x-ms-exchange-purlcount: 3 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtCTjZQUjIyMDFNQjExODY7MjM6Ny9VM0pIQ1NWZ3hEQW5XSUpvVHBDQW9W?= =?utf-8?B?bTQ5YUV5QWhEei9KNkt1RDlTbFg3QnBXbVJlS1IxOHJiMHkrTXlyaDhaTG5E?= =?utf-8?B?dVZqUFVoeUI2NDFGcGxDTHpLc053bjAxNFpPWXFLVEJ3andKTzh6bnFjVldQ?= =?utf-8?B?NDQrWlVUb0xidmhldWUwc3BEZEJhTGc1NEx0bElqdURFdldUQ3J4d1RDRGQ3?= =?utf-8?B?MU1MQjl1UWlYS2wxRnVnZ3BiY0V4QTFVQXZpdGR0VVF5NWlsVkJpa1VxUDh1?= =?utf-8?B?MUNnREp3SDlweE1oRHZ6SlVYSUFUSkZ5bmttUUVGTGZTRUJsRFNhWGI1Rm1O?= =?utf-8?B?dEdBSlUySlJtUjA4U3YxZis4TW9abWFla1VTd1NNeUJScGtHRU1CK0Z2VWEx?= =?utf-8?B?UytXN0FpWWtIb0oxSDlWcGY5SExEQk1tRmJoMzB1WlJDa1pFL1d2NjIwdWwx?= =?utf-8?B?V3c0dXhaQWtpWmRFSHBiNkVZWGE3WWxXeGVSWWhjbDJTRXhFbE84YTZuOGVl?= =?utf-8?B?WnFIQnVDM2hDYzVONGYzQ1Z1ekZJUEU3WkZkK3BvdTgwdjAwcjZuSmVTTW1U?= =?utf-8?B?c29Ibk1CeStyVm5ER01ZWXdGY0tPMlVGODBESEJJN3lobit6TTI3R3NEazA4?= =?utf-8?B?dnBISWpaUWNOQmNkUW5OZmc2WEFEcjNoNkpmNzVEbThvaXFVTXdPT3hwZWFq?= =?utf-8?B?RDZkcCtvdFF5RGZ3SFFmTjZxUzhtR0dFYUlYVXBzRXBMa2dsRnJXVkVBdkJz?= =?utf-8?B?Yy9ickFOeElZMzQ2VGpRdXVXSTZEMUQ0U3l5T1BDSnNHY3IvNk9KZE1YeUdH?= =?utf-8?B?c0JxWG5sQ294RnNQMlN0T01WdEdVNG4yaWVGcmhwcHJNNFg0bVZwUUNMVkRM?= =?utf-8?B?anFGS0Z6ZE16b0JPbDNnZTBaN2hzQXFPUzN0ams3dHMyVEkwNTd2RlBXSmZI?= =?utf-8?B?MzduNGEvV1g5NjFtdjJmVk1KZGxIRzdwK3dCNnVwMVhjSXZnODVjUXpoWWg3?= =?utf-8?B?TXAxSHFNUTBkSXIzNnJ4N1RZVnhnTUF6b2dJcUZoNGhXajBrVnRkQ2sveHda?= =?utf-8?B?NEl6MlJVZmhOa1pzL05SL05xcnFSL0YyZUYxbzhvYm52VmxDLzN1ZUpwaU5B?= =?utf-8?B?K1hjSHZ5WlNrdkZMb3c0UmlCUnUwVWRGMGZXY2R6emFXOXEwQUtIUU5Ra3gr?= =?utf-8?B?YXlRdGNUVjZmOHczMEdaaisxMG1WRnhaL05hNEFIME9qYllYSm41SDlDRnht?= =?utf-8?B?TVpielRTZXFOVkZ4dmdpU093ZFcva2tCU1luald6Yk5Xd2lyeXp6QWJ4NFN6?= =?utf-8?B?cEp0TGM0N0NMY1ExNVRUNFJJdGYvU0N5NHFqNCtyVFhpZWFwMTJWeXRUTCtN?= =?utf-8?B?clJyRUowVUxYWWpKMVZwYmgvd2pEdXhJakpkTUZlOXpoakNXanBka2ZBanRu?= =?utf-8?B?cklkMHRpand1eTYrOWNNSlZwSkRhVTBxUmNJR2dEcVhJVXFPMWs4RVlQclk0?= =?utf-8?B?aW1peUdHQ2lIV090MStZR0JmYmgweU4rRzNpUmJKWGk5RlpYRk1nd2ZuNWtZ?= =?utf-8?B?cmZGNTRjQ3MyMEZpVlIxalIrZTBVbFZ3STBldUR5Vko4RVdxallES1k2cGdX?= =?utf-8?B?N0NMa3pyVWtYRXZFTjRsM2laNzBaRkIrVnEwKy9rd0tWKzJHMEY5SHR6YzRz?= =?utf-8?B?dHRaWDNKSm1hVlpuZUFyTUwrRlhCYVJUOUFjdndidEM1S1FrbjZrcEdFRWRy?= =?utf-8?B?VnowNjlmMXRoa1I2RThwbVl0by9rTWVMTndFZVkrTSt0S3BBZytKZmNFSklh?= =?utf-8?B?dUo2RFRjOTdFYy9lNjhzT1NXaU5UaXY0ZFU0OEs5dEhwWFExZz09?= x-microsoft-antispam-prvs: x-forefront-prvs: 0961DF5286 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(39860400002)(376002)(136003)(346002)(54094003)(189003)(199004)(13464003)(33656002)(6436002)(6246003)(105586002)(5024004)(14444005)(86362001)(25786009)(229853002)(256004)(106356001)(4326008)(99286004)(110136005)(7696005)(76176011)(8676002)(81166006)(81156014)(74316002)(305945005)(7736002)(8936002)(53936002)(316002)(68736007)(9686003)(55016002)(6306002)(14454004)(478600001)(97736004)(966005)(66066001)(3846002)(6116002)(2906002)(476003)(446003)(486006)(66574012)(11346002)(71190400001)(71200400001)(186003)(26005)(102836004)(5660300002)(53546011)(52536013)(6506007); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR2201MB1186; H:BN6PR2201MB1092.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ra.rockwell.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: QcR8Q3YYRo7zFGwnftgWNqmS0D6vQySaQpJ3uwcbu+Wf9NKblfKVtdyKzKnyGuuRwfeDII6XFO9+8eXyAAXga1l7TjEckJQVs9kT4hCrc8IwogQyoPbgK6rz2nqceIVayhpU4sFCrUsEAcYVbolxyiFXES9AAUwvAim4FqWotLUv/wJalVvZek+s+/zkoMAmcP9mfcuEi6/mHKpMm8+UvKeQXDLqj1VQ28bqeWrxbbKlZZkLHNeqTubk0xx3fChr+K5rkgKFHkiTPEvLrKdP6HtF8vhXDsQgSuv7RXateOblh6JwKdLfSKNjZvQnngMer6a5Dt0cWJAU6iZS3STGWODxb/1iRYotwfqKPxoiad150m1pMe56oirEcSZwWQ4uQ/VylbdD55KoCUCLubD8+pyni67Z5x900JG0n/jYLQo= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ra.rockwell.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0e2d5f78-d2f3-4531-fb90-08d69cd5bb63 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2019 17:05:10.4071 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 855b093e-7340-45c7-9f0c-96150415893e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR2201MB1186 Archived-At: Subject: Re: [TLS] EXTERNAL: Re: Authentication Only Ciphersuites RFC 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, 27 Feb 2019 17:05:21 -0000 SGkgRGF2aWQsDQoNClRoYW5rcyBmb3Igc2hhcmluZyB0aGlzLCBhbHRob3VnaCB0aGUgc3Ryb25n IHByZWZlcmVuY2UgaXMgdG8gdXNlIHN0YW5kYXJkIFRMUyBmb3Igc2VjdXJpbmcgdGhlIGNvbW11 bmljYXRpb25zLg0KDQpUaGFua3MsDQoNCi0tSmFjaw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogVExTIDx0bHMtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIERhdmlk IFdvbmcNClNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDI2LCAyMDE5IDU6NTQgUE0NClRvOiBIYW5u byBCw7ZjayA8aGFubm9AaGJvZWNrLmRlPg0KQ2M6IDx0bHNAaWV0Zi5vcmc+IDx0bHNAaWV0Zi5v cmc+DQpTdWJqZWN0OiBFWFRFUk5BTDogUmU6IFtUTFNdIEF1dGhlbnRpY2F0aW9uIE9ubHkgQ2lw aGVyc3VpdGVzIFJGQw0KDQpbVXNlIGNhdXRpb24gd2l0aCBsaW5rcyAmIGF0dGFjaG1lbnRzXQ0K DQoNCg0KU2hhbWVsZXNzIHBsdWcsIGJ1dCBoYXZlIHlvdSBsb29rZWQgYXQgY29uc3RydWN0aW9u cyBsaWtlIERpc2NvDQooaHR0cHM6Ly9lcHJpbnQuaWFjci5vcmcvMjAxOS8xODApIHRoYXQgdGFy Z2V0IHNwZWNpZmljYWxseSB0aGlzIGlzc3VlPw0KDQpEYXZpZA0KDQoNCk9uIFR1ZSwgRmViIDI2 LCAyMDE5IGF0IDEwOjA0IFBNIEhhbm5vIELDtmNrIDxoYW5ub0BoYm9lY2suZGU+IHdyb3RlOg0K Pg0KPiBJIHRoaW5rIEkgaGF2ZSByYWlzZWQgbXkgY29uY2VybnMgYmVmb3JlLCBidXQgSSBoYXZl IHNlcmlvdXMgZG91YnRzIA0KPiB0aGVyZSdzIHJlYWwgbmVlZCBmb3Igc3VjaCBjaXBoZXJzdWl0 ZXMuDQo+DQo+IFRoZSByZWFzb25pbmcgc2VlbXMgdG8gYmUgdGhhdCBwZXJmb3JtYW5jZSBjb25z dHJhaW5lZCBkZXZpY2VzIGFyZSANCj4gdW5hYmxlIHRvIGRvICJub3JtYWwiIFRMUy4gSSBkb24n dCBoYXZlIGJlbmNobWFya3MsIGJ1dCBpdCdzIG15IA0KPiBleHBlcmllbmNlIHRoYXQgcGVvcGxl IHZhc3RseSBvdmVyZXN0aW1hdGUgdGhlIGNvc3RzIG9mIHN5bW1ldHJpYyANCj4gZW5jcnlwdGlv biBvcGVyYXRpb25zIChieSBmYXIgdGhlIGxhcmdlc3QgY29tcHV0YXRpb25hbCBjb3N0IG9mIFRM UyBpcyANCj4gdGhlIGFzeW1tZXRyaWMgaGFuZHNoYWtlKS4gSSB3b25kZXIgaWYgdGhlIHBlb3Bs ZSB3aG8gYmVsaWV2ZSB0aGV5IA0KPiBuZWVkIGFuIGF1dGhlbnRpY2F0aW9uIG9ubHkgY2lwaGVy c3VpdGUgZXZlciByYW4gdGVzdHMuDQo+DQo+IEkgYWxzbyBzZWUgYSBub24tbmVnbGVnaWJsZSBy aXNrIGluIHN0YW5kYXJkaXppbmcgc3VjaCBjaXBoZXJzdWl0ZXMuDQo+IFNvbWUgaW1wbGVtZW50 YXRpb25zIHdpbGwgZW5kIHVwIGFkZGluZyB0aGVtIGFuZCBjb3VwbGVkIHdpdGggDQo+IGltcGxl bWVudGF0aW9uIGZsYXdzIHdlIG1heSBlbmQgdXAgaW4gYSBzaXR1YXRpb24gd2hlcmUgaW5hZHZl cnRlbnRseSANCj4gaW5zZWN1cmUgY2lwaGVyc3VpdGVzIGFyZSBjaG9zZW4uDQo+DQo+IC0tDQo+ IEhhbm5vIELDtmNrDQo+IGh0dHBzOi8vaGJvZWNrLmRlLw0KPg0KPiBtYWlsL2phYmJlcjogaGFu bm9AaGJvZWNrLmRlDQo+IEdQRzogRkU3Mzc1N0ZBNjBFNEUyMUI5Mzc1NzlGQTU4ODAwNzJCQkI1 MUU0Mg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBUTFMgbWFpbGluZyBsaXN0DQo+IFRMU0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rscw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KVExTIG1haWxpbmcgbGlzdA0KVExTQGlldGYub3JnDQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rscw0K From nobody Wed Feb 27 11:49:40 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7E06127AC2 for ; Wed, 27 Feb 2019 11:49:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=ra.rockwell.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 O8G99SmWCEvz for ; Wed, 27 Feb 2019 11:49:35 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on061a.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe49::61a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC97F1310D2 for ; Wed, 27 Feb 2019 11:49:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ra.rockwell.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AKEPt3G24h0Pk6Zya2ywPJ0zt9RF2yO/Q4ODermO1qE=; b=d3YrQVag5uf0ub44cXFa4WZJEEqruOCdrZYS6qod+8NKQ8UoK6GUdMEQfapul1TaATRakMIV3PgWNxugllifK8g3mtpM3ppT0v5Ng8xT5xJLxf7KeSYsFrMv2YQkDDofPxHDU2kIwnzSLEBWq4JS84TFxpVF4zTQLibcid2TLOc= Received: from BN6PR2201MB1092.namprd22.prod.outlook.com (10.174.88.29) by BN6PR2201MB1635.namprd22.prod.outlook.com (10.174.85.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.16; Wed, 27 Feb 2019 19:49:33 +0000 Received: from BN6PR2201MB1092.namprd22.prod.outlook.com ([fe80::dd5e:b340:8fa8:b113]) by BN6PR2201MB1092.namprd22.prod.outlook.com ([fe80::dd5e:b340:8fa8:b113%5]) with mapi id 15.20.1665.015; Wed, 27 Feb 2019 19:49:33 +0000 From: Jack Visoky To: Eric Rescorla CC: "tls@ietf.org" Thread-Topic: EXTERNAL: Re: [TLS] Authentication Only Ciphersuites RFC Thread-Index: AdTOFIIaiE+qoBOKQdSotuuQ5A30qAAEXjYAACu+W6A= Date: Wed, 27 Feb 2019 19:49:33 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jmvisoky@ra.rockwell.com; x-originating-ip: [205.175.250.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 734327e3-ae5c-49f7-5440-08d69cecb1ff x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7153060)(7193020); SRVR:BN6PR2201MB1635; x-ms-traffictypediagnostic: BN6PR2201MB1635: x-ms-exchange-purlcount: 2 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtCTjZQUjIyMDFNQjE2MzU7MjM6Ykc0RE5KUklTalMzanFLbVVOUEVKcTBl?= =?utf-8?B?U2VCZzNaMTV3MTAxSnFwS3gxWkpXcENwSDNlZ3FIVHljSC9uREZSOG5SWWNM?= =?utf-8?B?d0pnbXlZMlhLV1RsRi80eEEvWTBuNFF3YUdLakVURXhGSU5WdElqZm1kU3ZJ?= =?utf-8?B?K0N2REo1SHZRK3ptTDhXQ2MzUEVsbkFlSEE5N1l5d1htNjNYVzUrZ3orMXJE?= =?utf-8?B?eWd0V2tZdmsrblU2RFJLN0lUSnRKbVJZTTNTTUpndkZWcDhjZGI4elZNU0d4?= =?utf-8?B?VU9ySkZad1VCSmxpMFdoOUlNY3FtSTQ3S2E3Q0JJeTd1VTdLbHBTWmpjTElz?= =?utf-8?B?eXVRNUFtU2dNa1JSQUpWL0VuU2gvZWx3QldwbUs3TVJLNXRYcGlicUp4eThu?= =?utf-8?B?RDQyNEZxWHhqUlpHc0dqOHVLQ2RmN3NETExZN1ZkMVFwc1NXUE1jNUVyVGVr?= =?utf-8?B?MjFhQ0F5WGJoTUNCNXMvRmtYOHZJdjZOYUtEditzc25ONTRPWlNTaWFLOHBB?= =?utf-8?B?L2sxaU0yK1ZQditMSWx1cHUxWWtZOXFjcEw3SHoxbS8zY283OXVDKzFDQWgv?= =?utf-8?B?cHhyQmhQUExnODd2V1ViMDRZWFJWcDN4b3hXVm1iaE11T2hFdXhRZ1ZZVzJq?= =?utf-8?B?WTkxTnlxNUovODdhVXFxMjJBcnlYMFIvYXdWbTdOejcyZGJoSXowRGZycWt0?= =?utf-8?B?bXJFem9NT0tablBwQkdpYmY1RWxOWElDeVhjRGpkd2JiYVVKZ0xWT3hCdUNT?= =?utf-8?B?WFFsRERNV2R3Zm9pKzg4L3V6aS9vOGZKTkJ2aXgrbjhyc2RHV1JqTWdUcHp0?= =?utf-8?B?c1ZDV2srSDZ0ZnZXS005Y3pSTk1ESy9aS08wVUIzaHhzNlphVXdIUnBnRmRv?= =?utf-8?B?aFFMc2xzdWl1aGVPNmFCbmxtRjNjS1NvTEwvL3hlK0RaLzN0V1F6Q2pYc0lV?= =?utf-8?B?YXFkaXJlbkpPV2t0MUlORWl2SE9qSWt5ek9oTUFwZjlpTUZlY2JmQnpFdGEr?= =?utf-8?B?cmFGZ1MrN1hsYXNlSjJ1K25oelZjUFBrSDFLWkRXdERTVGQxRFgwZXJVQk4y?= =?utf-8?B?VWFCZmpnOGF4eFBXc2wzM0wzUnpWa1F5a1d3blJndTA4K1ZSZW1NSkRQU3Rt?= =?utf-8?B?ZEFTY3VBRlY4b01iUlFuU3EwUVJ6N2lUZmlPYWhZakVHby9OSm5zc0tWbDU5?= =?utf-8?B?NXU2UUs1aDJIenE3d0hQU09halU3N3gzVEVlNkRTUWFJSmxyS1hVMU93Vitl?= =?utf-8?B?MWFJVFFXM2tpYmlieEsvb3lBYVo0TDY1Ynp4cG1iMysweldURzQzaUgwNzUz?= =?utf-8?B?TkwzNVQwbFBzT1c2eTB3bFRJMnlWNlhTTEVYRDJQdWRMZGFPUUkyY0I1TTlj?= =?utf-8?B?ZmdGcVJ0eDg1OS81QXVTbDh3YUZYYlpoK2pPMGhma09JNGI1SGROSEJld3kx?= =?utf-8?B?SlVXK0ZTZEtXRUxoVmNCQkp5UC85ZU4rS1FRd280bHEyWlo1ZFNWY0FybVdS?= =?utf-8?B?N1lWSkJzMXpvdWw0aTQ4S2FmMmw4VnNGeFAwVHM2RFhac1I2SkNFUTRtekFF?= =?utf-8?B?Vkd6OEs1VGdUL3BhdU13TXJUSU5ZNWp3OG8rejcvOURqdTkzT2FUOVhCcDVG?= =?utf-8?B?K291UHdQU3l2cHZJVmpRMnJWbHBRWXZuYmJuUnpkSW1pWEdxZ2s2cjhpSm1N?= =?utf-8?B?Y0R2akNmcWoybFQ1eVFVeTFKdFUyZ0FIRXJyUUhrWk56TWl2YXZiaFBITDlK?= =?utf-8?B?SWtCV1VKaW9obEkwMEtGeG5tOGZpaDZwcCt1Qk84dEhRQUNRYkRyR2RsOE9P?= =?utf-8?B?UzhsV21yM255VXRWYmdtd3ZqbWQzelQzdS9RQXJubEd6OXcrUT09?= x-microsoft-antispam-prvs: x-forefront-prvs: 0961DF5286 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(366004)(136003)(376002)(346002)(199004)(189003)(486006)(25786009)(7736002)(26005)(81166006)(81156014)(66066001)(8676002)(4326008)(76176011)(7696005)(6916009)(106356001)(14444005)(5024004)(71190400001)(256004)(86362001)(71200400001)(316002)(52536013)(14454004)(6246003)(606006)(6506007)(102836004)(478600001)(53546011)(74316002)(966005)(97736004)(6306002)(68736007)(5660300002)(236005)(54896002)(55016002)(33656002)(6436002)(6116002)(105586002)(790700001)(99286004)(3846002)(229853002)(2906002)(53936002)(9326002)(8936002)(186003)(446003)(476003)(9686003)(11346002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR2201MB1635; H:BN6PR2201MB1092.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ra.rockwell.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: n9pLAxyWJkPvUp4Sw6B1oWoRoU28cvtf/TZj8WpkjG8ImO7WFPp029bXxv6QSfWRm9NyNuMhReirnjBN8sto33jAGU/6pznh+rarkvjPeLbnp/mY7D1FLHqjIE/uDFB0yKbuGOUza4WnOF3DmV0L3i6hMZafJqQ+iQK58TPa3Bu2fnmZMnhmKGmXDFYUaKrx8xYr7D0moSMKZqncqPLIXeazlB/yd5x2NXiO7ISpmVvpJWdFSEjNQLcq0lnoNMx/iJUDzH88bGNmozXzlvjYf4EPv3JUrsdS6+ge/cCSQ51KSCX0JAtCfKKeieN9DFpaAO//JzXpO2XJNWFIAV8Jy6BCB4A2u84RTvNUxzpxuTIYWexxYkpVnwWi5N7Pd1bo2koNkm2TrKKz+rWy5c27vGqDPl2ZmJnzTzoyjzjsmjk= Content-Type: multipart/alternative; boundary="_000_BN6PR2201MB10920B409B6E38A36BB2DDC499740BN6PR2201MB1092_" MIME-Version: 1.0 X-OriginatorOrg: ra.rockwell.com X-MS-Exchange-CrossTenant-Network-Message-Id: 734327e3-ae5c-49f7-5440-08d69cecb1ff X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2019 19:49:33.0628 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 855b093e-7340-45c7-9f0c-96150415893e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR2201MB1635 Archived-At: Subject: Re: [TLS] EXTERNAL: Re: Authentication Only Ciphersuites RFC 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, 27 Feb 2019 19:49:38 -0000 --_000_BN6PR2201MB10920B409B6E38A36BB2DDC499740BN6PR2201MB1092_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRXJpYywNCg0KT3VyIGdvYWwgaXMgdG8gaGF2ZSBhbiBSRkMgcHVibGlzaGVkIGFzIEluZm9y bWF0aW9uYWwgYW5kIHdpdGggdGhlIE5vdCBSZWNvbW1lbmRlZCBzdGF0dXMuICBXZSBmZWx0IGhh dmluZyB0aGlzIGFwcHJvdmVkIHRocm91Z2ggdGhlIElFVEYgcHJvY2VzcyB2cyBqdXN0IElTRSB3 b3VsZCBiZSBiZW5lZmljaWFsIHRvIHRob3NlIHdpc2hpbmcgdG8gYWRvcHQsIGFuZCBnZXR0aW5n IGNvbW11bml0eSByZXZpZXcgaXMgYWxzbyBoZWxwZnVsIHRvIHVzIGFuZCB0aG9zZSB3ZSByZXBy ZXNlbnQuDQoNCkkgc3VwcG9zZSBvbmUgcXVlc3Rpb24gaXMgd2hldGhlciBvciBub3Qgd2UgbmVl ZCB0aGlzIHRvIGJlIGEgV0cgaXRlbSBvciBpZiB3ZSBjYW4gc29saWNpdCBpbmRlcGVuZGVudCBz aGVwaGVyZGluZyBmcm9tIGEgY2hhaXIgb3IgQUQgdG8gZ2V0IHRvIHRoZSBnb2FsIG9mIGFuIElu Zm9ybWF0aW9uIFJGQyB3aXRoIE5vdCBSZWNvbW1lbmRlZCBzdGF0dXMuDQoNCkFsc28sIEkgYXBv bG9naXplIGlmIEnigJl2ZSBtaXN1bmRlcnN0b29kIG9yIG1pc3N0YXRlZCBhbnl0aGluZywgSeKA mW0gbmV3IHRvIHRoZSBJRVRGIHByb2Nlc3NlcyBzbyBjZXJ0YWlubHkgY291bGQgaGF2ZSBtYWRl IGEgbWlzdGFrZS4NCg0KVGhhbmtzLA0KDQotLUphY2sNCg0KRnJvbTogRXJpYyBSZXNjb3JsYSA8 ZWtyQHJ0Zm0uY29tPg0KU2VudDogVHVlc2RheSwgRmVicnVhcnkgMjYsIDIwMTkgNTo1MyBQTQ0K VG86IEphY2sgVmlzb2t5IDxqbXZpc29reUByYS5yb2Nrd2VsbC5jb20+DQpDYzogdGxzQGlldGYu b3JnDQpTdWJqZWN0OiBFWFRFUk5BTDogUmU6IFtUTFNdIEF1dGhlbnRpY2F0aW9uIE9ubHkgQ2lw aGVyc3VpdGVzIFJGQw0KDQoNCltVc2UgY2F1dGlvbiB3aXRoIGxpbmtzICYgYXR0YWNobWVudHNd DQoNCg0KDQoNCk9uIFR1ZSwgRmViIDI2LCAyMDE5IGF0IDEyOjU0IFBNIEphY2sgVmlzb2t5IDxq bXZpc29reUByYS5yb2Nrd2VsbC5jb208bWFpbHRvOmptdmlzb2t5QHJhLnJvY2t3ZWxsLmNvbT4+ IHdyb3RlOg0KDQpUTFMgQ29sbGVhZ3VlcywNCg0KSWYgeW91IHJlY2FsbCB3ZSBkaXNjdXNzZWQg YSBkcmFmdCBmb3IgYXV0aGVudGljYXRpb24gb25seSBjaXBoZXJzdWl0ZXMgb3ZlciBlbWFpbCBi YWNrIGluIEF1Z3VzdCBvZiAyMDE4LiAgV2UndmUgc2luY2UgbWFkZSBzb21lIHVwZGF0ZXMgdG8g dGhhdCBkcmFmdC4gIFdlIGFsc28gaGF2ZSBnb3R0ZW4gSUFOQSBhc3NpZ25tZW50cyB0byB0aGUg YXV0aGVudGljYXRpb24gb25seSBjaXBoZXJzdWl0ZXMgZm9yIFRMUyAxLjMgYW5kIGhhdmUgdXBk YXRlZCB0aGUgZHJhZnQgdG8gcmVmbGVjdCB0aGUgbmV3IGFzc2lnbm1lbnRzLg0KDQpUbyB0aGF0 IGV4dGVudCwgYXMgdGhlIElvVCBjb21tdW5pdHkgaXMgbG9va2luZyB0byBhZG9wdCB0aGVzZSBj aXBoZXJzdWl0ZXMsIHdlIHdvdWxkIGxpa2UgdG8gc29saWNpdCByZXZpZXcgb2YgdGhlIGRyYWZ0 Og0KDQoNCg0KICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jYW13aW5nZXQt dGxzLXRzMTMtbWFjY2lwaGVyc3VpdGVzLTAyDQoNCg0KDQphbmQgcmVxdWVzdCB0aGF0IGl0IGJl IHB1Ymxpc2hlZCBhcyBpbmZvcm1hdGlvbmFsIGRyYWZ0IGdpdmVuIHRoYXQgdGhlIElvVCBmb3J1 bXMgYXJlIGxvb2tpbmcgdG8gYWRvcHQgaXRzIHVzZSBhbmQgdGhlIGRyYWZ0IGNhbiBzZXJ2ZSBh cyB0aGUgZ3VpZGUgZm9yIHVzZSBhbmQgaW50ZXJvcGVyYWJpbGl0eS4NCg0KSXQgc2VlbXMgdG8g bWUgdGhhdCB0aGVyZSBmb3VyIHNvbWV3aGF0IGRpc3RpbmN0IHF1ZXN0aW9uczoNCg0KMS4gQ29k ZSBwb2ludHMNCjIuIERvY3VtZW50IGxldmVsIChJbmZvLCBFeHAsIFBTLCBldGMuKQ0KMy4gUmVj b21tZW5kZWQgc3RhdHVzDQo0LiBXRyBzdGF0dXMNCg0KRnJvbSBteSBwZXJzcGVjdGl2ZSwgeW91 IGhhdmUgY29kZSBwb2ludHMgYW5kIHlvdSd2ZSBhc2tlZCBmb3IgYW4gSW5mb3JtYXRpb25hbCBk b2N1bWVudCwgYnV0IHRoYW4gY2FuIG9ubHkgZ2V0IHlvdSBOb3QgUmVjb21tZW5kZWQsIHNvIHdo YXQncyB0aGUgdmFsdWUgb2YgaGF2aW5nIHRoaXMgYmUgYSBXRyBkb2N1bWVudD8gV2h5IGNhbid0 IHlvdSBzdWJtaXQgaXQgdG8gdGhlIElTRSBvciBhbHRlcm5hdGVseSBqdXN0IGhhdmUgcGVvcGxl IHJlZmVyZW5jZSB0aGUgZHJhZnQ/DQoNCi1Fa3INCg0KDQpUaGFua3MgYW5kIEJlc3QgUmVnYXJk cywNCg0KLS1KYWNrIChhbmQgTmFuY3kpDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NClRMUyBtYWlsaW5nIGxpc3QNClRMU0BpZXRmLm9yZzxtYWls dG86VExTQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90 bHMNCg== --_000_BN6PR2201MB10920B409B6E38A36BB2DDC499740BN6PR2201MB1092_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj b250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEt LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2Ft YnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6RGVuZ1hpYW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBEZW5nWGlhbiI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OiJBcmlhbCBOYXJyb3ciOw0KCXBhbm9zZS0xOjIgMTEgNiA2IDIgMiAyIDMgMiA0O30NCi8qIFN0 eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYu bXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3At YWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zZ2JvcmRlciwgbGkubXNnYm9yZGVyLCBkaXYubXNn Ym9yZGVyDQoJe21zby1zdHlsZS1uYW1lOm1zZ2JvcmRlcjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBpbjsNCglib3JkZXI6bm9uZTsNCglwYWRkaW5nOjBpbjsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1h aWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu MGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhp IEVyaWMsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk91ciBnb2FsIGlzIHRvIGhhdmUgYW4gUkZD IHB1Ymxpc2hlZCBhcyBJbmZvcm1hdGlvbmFsIGFuZCB3aXRoIHRoZSBOb3QgUmVjb21tZW5kZWQg c3RhdHVzLiZuYnNwOyBXZSBmZWx0IGhhdmluZyB0aGlzIGFwcHJvdmVkIHRocm91Z2ggdGhlIElF VEYgcHJvY2VzcyB2cyBqdXN0IElTRSB3b3VsZCBiZSBiZW5lZmljaWFsIHRvIHRob3NlIHdpc2hp bmcgdG8gYWRvcHQsIGFuZCBnZXR0aW5nIGNvbW11bml0eSByZXZpZXcgaXMNCiBhbHNvIGhlbHBm dWwgdG8gdXMgYW5kIHRob3NlIHdlIHJlcHJlc2VudC4mbmJzcDsgPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkkgc3VwcG9zZSBvbmUgcXVlc3Rpb24gaXMgd2hldGhlciBvciBub3Qgd2UgbmVlZCB0 aGlzIHRvIGJlIGEgV0cgaXRlbSBvciBpZiB3ZSBjYW4gc29saWNpdCBpbmRlcGVuZGVudCBzaGVw aGVyZGluZyBmcm9tIGEgY2hhaXIgb3IgQUQgdG8gZ2V0IHRvIHRoZSBnb2FsIG9mIGFuIEluZm9y bWF0aW9uIFJGQyB3aXRoIE5vdCBSZWNvbW1lbmRlZCBzdGF0dXMuJm5ic3A7DQo8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QWxzbywgSSBhcG9sb2dpemUgaWYgSeKAmXZlIG1pc3VuZGVyc3Rvb2Qg b3IgbWlzc3RhdGVkIGFueXRoaW5nLCBJ4oCZbSBuZXcgdG8gdGhlIElFVEYgcHJvY2Vzc2VzIHNv IGNlcnRhaW5seSBjb3VsZCBoYXZlIG1hZGUgYSBtaXN0YWtlLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGFua3MsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tSmFjazxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+ IEVyaWMgUmVzY29ybGEgJmx0O2VrckBydGZtLmNvbSZndDsgPGJyPg0KPGI+U2VudDo8L2I+IFR1 ZXNkYXksIEZlYnJ1YXJ5IDI2LCAyMDE5IDU6NTMgUE08YnI+DQo8Yj5Ubzo8L2I+IEphY2sgVmlz b2t5ICZsdDtqbXZpc29reUByYS5yb2Nrd2VsbC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiB0bHNA aWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gRVhURVJOQUw6IFJlOiBbVExTXSBBdXRoZW50 aWNhdGlvbiBPbmx5IENpcGhlcnN1aXRlcyBSRkM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJtc28tZWxlbWVudDpwYXJhLWJvcmRlci1kaXY7Ym9yZGVyOnNvbGlkICNCQjIz MjIgMi4yNXB0O3BhZGRpbmc6Mi4wcHQgMi4wcHQgMi4wcHQgMi4wcHQ7YmFja2dyb3VuZDojRThF OEU4Ij4NCjxwIGNsYXNzPSJtc2dib3JkZXIiIHN0eWxlPSJsaW5lLWhlaWdodDoxMi4wcHQ7YmFj a2dyb3VuZDojRThFOEU4Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFj ayI+W1VzZSBjYXV0aW9uIHdpdGggbGlua3MgJmFtcDsgYXR0YWNobWVudHNdPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIEZlYiAyNiwgMjAxOSBh dCAxMjo1NCBQTSBKYWNrIFZpc29reSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptdmlzb2t5QHJhLnJv Y2t3ZWxsLmNvbSI+am12aXNva3lAcmEucm9ja3dlbGwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIHN0eWxlPSJt YXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+VExTIENvbGxlYWd1ZXMsIDxvOnA+PC9v OnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij5JZiB5 b3UgcmVjYWxsIHdlIGRpc2N1c3NlZCBhIGRyYWZ0IGZvciBhdXRoZW50aWNhdGlvbiBvbmx5IGNp cGhlcnN1aXRlcyBvdmVyIGVtYWlsIGJhY2sgaW4gQXVndXN0IG9mIDIwMTguJm5ic3A7IFdlJ3Zl IHNpbmNlIG1hZGUgc29tZSB1cGRhdGVzIHRvIHRoYXQgZHJhZnQuJm5ic3A7IFdlIGFsc28gaGF2 ZSBnb3R0ZW4gSUFOQSBhc3NpZ25tZW50cyB0byB0aGUgYXV0aGVudGljYXRpb24NCiBvbmx5IGNp cGhlcnN1aXRlcyBmb3IgVExTIDEuMyBhbmQgaGF2ZSB1cGRhdGVkIHRoZSBkcmFmdCB0byByZWZs ZWN0IHRoZSBuZXcgYXNzaWdubWVudHMuPG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2lu OjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPlRvIHRoYXQgZXh0ZW50LCBhcyB0aGUgSW9UIGNv bW11bml0eSBpcyBsb29raW5nIHRvIGFkb3B0IHRoZXNlIGNpcGhlcnN1aXRlcywgd2Ugd291bGQg bGlrZSB0byBzb2xpY2l0IHJldmlldyBvZiB0aGUgZHJhZnQ6PG86cD48L286cD48L3A+DQo8cCBz dHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPiZuYnNwOyZuYnNwOyZuYnNw OyA8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAw MDFwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWNhbXdpbmdldC10bHMtdHMxMy1tYWNjaXBoZXJzdWl0ZXMtMDIiIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2Ftd2luZ2V0 LXRscy10czEzLW1hY2NpcGhlcnN1aXRlcy0wMjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxl PSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxv OnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0 Ij5hbmQgcmVxdWVzdCB0aGF0IGl0IGJlIHB1Ymxpc2hlZCBhcyBpbmZvcm1hdGlvbmFsIGRyYWZ0 IGdpdmVuIHRoYXQgdGhlIElvVCBmb3J1bXMgYXJlIGxvb2tpbmcgdG8gYWRvcHQgaXRzIHVzZSBh bmQgdGhlIGRyYWZ0IGNhbiBzZXJ2ZSBhcyB0aGUgZ3VpZGUgZm9yIHVzZSBhbmQgaW50ZXJvcGVy YWJpbGl0eS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBzZWVtcyB0byBtZSB0aGF0IHRoZXJlIGZv dXIgc29tZXdoYXQgZGlzdGluY3QgcXVlc3Rpb25zOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xLiBDb2RlIHBvaW50czxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Mi4gRG9jdW1lbnQgbGV2ZWwg KEluZm8sIEV4cCwgUFMsIGV0Yy4pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4zLiBSZWNvbW1lbmRlZCBzdGF0dXM8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjQuIFdHIHN0YXR1czxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gcm9tIG15IHBlcnNw ZWN0aXZlLCB5b3UgaGF2ZSBjb2RlIHBvaW50cyBhbmQgeW91J3ZlIGFza2VkIGZvciBhbiBJbmZv cm1hdGlvbmFsIGRvY3VtZW50LCBidXQgdGhhbiBjYW4gb25seSBnZXQgeW91IE5vdCBSZWNvbW1l bmRlZCwgc28gd2hhdCdzIHRoZSB2YWx1ZSBvZiBoYXZpbmcgdGhpcyBiZSBhIFdHIGRvY3VtZW50 PyBXaHkgY2FuJ3QgeW91IHN1Ym1pdCBpdCB0byB0aGUgSVNFIG9yIGFsdGVybmF0ZWx5DQoganVz dCBoYXZlIHBlb3BsZSByZWZlcmVuY2UgdGhlIGRyYWZ0PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tRWtyPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhhbmtzIGFuZCBC ZXN0IFJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tLUphY2sgKGFuZCBOYW5j eSk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsIE5hcnJvdyZxdW90OyxzYW5zLXNlcmlmIj4m bmJzcDs8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KVExTIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpUTFNAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5UTFNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RsczwvYT48bzpwPjwvbzpwPjwvcD4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_BN6PR2201MB10920B409B6E38A36BB2DDC499740BN6PR2201MB1092_-- From nobody Wed Feb 27 12:43:48 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 F2251131123; Wed, 27 Feb 2019 12:43:46 -0800 (PST) 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.92.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <155130022683.13920.2446301335516183607@ietfa.amsl.com> Date: Wed, 27 Feb 2019 12:43:46 -0800 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-dtls-connection-id-03.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: Wed, 27 Feb 2019 20:43:47 -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 : Connection Identifiers for DTLS 1.2 Authors : Eric Rescorla Hannes Tschofenig Thomas Fossati Filename : draft-ietf-tls-dtls-connection-id-03.txt Pages : 14 Date : 2019-02-27 Abstract: This document specifies the Connection ID (CID) construct for the Datagram Transport Layer Security (DTLS) protocol version 1.2. A CID is an identifier carried in the record layer header that gives the recipient additional information for selecting the appropriate security association. In "classical" DTLS, selecting a security association of an incoming DTLS record is accomplished with the help of the 5-tuple. If the source IP address and/or source port changes during the lifetime of an ongoing DTLS session then the receiver will be unable to locate the correct security context. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-dtls-connection-id-03 https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls-connection-id-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-dtls-connection-id-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 27 16:36: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 0A5B11311FE for ; Wed, 27 Feb 2019 16:36:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 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, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNeWyqOF8E_t for ; Wed, 27 Feb 2019 16:36:47 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-eopbgr800107.outbound.protection.outlook.com [40.107.80.107]) (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 E8B201311EF for ; Wed, 27 Feb 2019 16:36:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vQGhSn3XTcz4MxYLDtLfa880b3K7yu+oDDJZnom6uLk=; b=jIPN7YJxeJhrgRtjC3Vf0T7dNFwlbKEFjqba1Qwiz/j6uXgBR248EX9Z4xVFQkFivEoh2LojixEGH4HDtt5f/EXaRjcc2uhgIit+GKwQPyzmc/n0fBqAV3TtI1kA8yfo4b7aQEk6Zt9H2rfqFoQ4M/0jFpZRhxjdWKpJ/zM07To= Received: from CY4PR22MB0983.namprd22.prod.outlook.com (10.171.164.151) by CY4PR22MB0806.namprd22.prod.outlook.com (10.171.169.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.16; Thu, 28 Feb 2019 00:36:42 +0000 Received: from CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::76:e309:d27f:23e6]) by CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::76:e309:d27f:23e6%2]) with mapi id 15.20.1665.015; Thu, 28 Feb 2019 00:36:42 +0000 From: Mike Bishop To: Christopher Wood , "" Thread-Topic: [TLS] Two Multi-CDN proposals Thread-Index: AQHUzrgq/mj86VpJpU6F+CUABXSdh6X0XA7g Date: Thu, 28 Feb 2019 00:36:42 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [38.134.241.6] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ead8a407-4737-4466-5046-08d69d14cf85 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:CY4PR22MB0806; x-ms-traffictypediagnostic: CY4PR22MB0806: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-forefront-prvs: 0962D394D2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39830400003)(376002)(346002)(136003)(366004)(396003)(13464003)(51874003)(189003)(199004)(606006)(33656002)(74316002)(7736002)(256004)(14444005)(110136005)(316002)(508600001)(14454004)(966005)(71190400001)(71200400001)(86362001)(66066001)(53936002)(486006)(81166006)(81156014)(8676002)(25786009)(74482002)(6436002)(236005)(9686003)(6306002)(54896002)(55016002)(229853002)(5660300002)(6506007)(53546011)(11346002)(446003)(26005)(102836004)(99286004)(106356001)(476003)(7696005)(76176011)(186003)(97736004)(52536013)(68736007)(8936002)(105586002)(3846002)(6116002)(790700001)(2906002)(6246003)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR22MB0806; H:CY4PR22MB0983.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-microsoft-exchange-diagnostics: =?us-ascii?Q?1; CY4PR22MB0806; 23:f0xSjh25Dg8C7eedFf1fdp7KLq2D6OZf6cSj9nTHO?= =?us-ascii?Q?hUCjCdZoQVmpydmlByQ6CXbgQjO1lWkd2kJNm4zyxpZRsl8iBD79huhtIZZk?= =?us-ascii?Q?8d5/NHCyPYxhEZletsWMZbgpcrUKQqkOMhNoyT7sUXRjKB0jGpRiIGaTWzbH?= =?us-ascii?Q?4XnrFVg6vRuVfq2rQ+SRDU/1BbcjeEFR09ITYqdpBT8hM8t/nZH3CDwnA3z+?= =?us-ascii?Q?OIdo5QIPcomMi2LL0nosfxdaCUSZ2UiWs0BW6yzYJgNbDpXEvVNch0CHhRY+?= =?us-ascii?Q?+U5vy+voAyiSG6DJFP96W5c4AWrkplIFoeE88sM+B0qKwN2e1RpGJLIKdnMX?= =?us-ascii?Q?aLvyj8hr1O4Tyj48it4rwDSvRaasClEv0e02OhDTN0yz7rIFz2r7szJFZ3jI?= =?us-ascii?Q?vbFw034MthE8be1e/iGX5wVBGgaZ+xABAdRnYvH7ILBIfK71PzBWth+JJPPB?= =?us-ascii?Q?iZowxlCBKMLl8LqtZZRll+MKZvbhpMFpJ4nMwBo1vsEgLARMmtNloZLJZfRj?= =?us-ascii?Q?fxb+IPbdInFGUOX4n/I8auaZEmohVzKiCJZ4lUvo/csKe5r8xn5chHdNxndl?= =?us-ascii?Q?bbFrmZVsRzexS6H65calskNnXlhjTZrWkw2qAdL7p9f9rbwkNGwfg6YCKo84?= =?us-ascii?Q?at5TmW2cQ8xA/t00jxhhCMoG7VohZ3ZRmdBHSWSeAaNbPJs5ht2/3INBYzRL?= =?us-ascii?Q?qRwCe0ZczFthmHcQ+tjLYt4VMco16pvW0SGzx1fXDCZ7Fvy8KkllGCYf5AFS?= =?us-ascii?Q?QMOgcnjIY/Bz4Ix6KGOjLXnleqr/rDYl93HJsbWSu9f+euf3XSGK0LmEQyzk?= =?us-ascii?Q?QUtcctaGJuE3d2RxQBb+xJ4Ojyr0Cxn3J99RJ9gQaBgX1+/FDqNcxw/lmPQN?= =?us-ascii?Q?wH7MYMjBQZrFhBx2okyQzIkyfC5xxavHyCubnil6BiODJzi+nvJSr0oChA5k?= =?us-ascii?Q?LNWC/iDhtTFu9v6nMXesMgqwebkBuF7xa0KvOwSY4FCVtETHMFVF2rmvwGPZ?= =?us-ascii?Q?35kLiNKxHxbY7ythNUEpnvKjmhftrVTmj5y5WRvT7zb4Ntl1BKTT8cwguD2s?= =?us-ascii?Q?LUsZ3FExweCfF2zGxSvSilejkFgq3w1jS5wm1aTAd3Ks4luBRpkfiGddzIty?= =?us-ascii?Q?4iIfv0J86cMzYgmVti9YMvZJZ5iFJ5a5H71+P+7l5jNBa+Nr2ywT1SikUpSW?= =?us-ascii?Q?7aT7H1DOq/7Y7UbqZXwi18PmIJceNV0uqpWiSm603vhtu0STKiGeYzhZgZdd?= =?us-ascii?Q?zV1ZbtAsQxV28STm3cMixlJ8tw3xL5IpKTldmP+wbjj7H+S+c9NlIWu7xdSL?= =?us-ascii?Q?Dw1I2uiD6otlY8yBKfbDrE/OnBPW4Os+XEzdinjA7XVgSFcYwIJ1+yjE1xWI?= =?us-ascii?Q?r3K/3hRSy92PFE4f0DBaMEt55g=3D?= x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: mxmgZTogUr+wUqrGFygKSPihzFF8bm7S/KvYuYo8mEnaa7Bd3dfvxz42gqJ6H5afhlUu9+6I9Dbb+bQJormypHvujgA7HoUi4ujCJnJiv0kFjpLsyDj5jEEyAQ6sXNM4//0KGg3ga8KV+hrrxJ58FwOdtyRUiB+n5REINUcLI/I6laVvyx61whRDoDGDiCRxy4cIwdftbpBU1v0KD6+nwyJM/XssGa/8qxrS09/4NJTdnU8e0zny7qz90OTnx45kG0TH9E8L6q+7O9TPClsDvj4iT28B0H68pFjns5eufVhuMbTf3Fi2MZnxIMExB+pW6yup2MM70iTd0IDU51KmHpw+iSE390IVIjG1W+acBHYgdojDD2EpVfD4HX+Yk8U+oWbSXoH0jooRQRD/AOCK2X0KpoT4waswotqxzBq+8pk= Content-Type: multipart/alternative; boundary="_000_CY4PR22MB098340D8B4C6FD7D9EB9C32EDA750CY4PR22MB0983namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: ead8a407-4737-4466-5046-08d69d14cf85 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2019 00:36:42.5120 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR22MB0806 Archived-At: Subject: Re: [TLS] Two Multi-CDN proposals 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, 28 Feb 2019 00:36:51 -0000 --_000_CY4PR22MB098340D8B4C6FD7D9EB9C32EDA750CY4PR22MB0983namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Despite the additional complexity of #137, I think it's probably the better= approach (and I would be fine with the simplification, if that makes it mo= re palatable). Particularly when multi-CDN is used, there's a lot of logic= involved in generating the "right" A/AAAA record in response to a request.= #136 essentially lets the ESNIKeys result override the A/AAAA, which mean= s ESNIKeys needs to be equally tailored and duplicate all the existing logi= c for a new record type. In #137, the ESNIKeys essentially contains enough= information to check that the A/AAAA results came from the same entity as = the ESNIKeys result but leaves the DNS complexity where it already exists. = (It has the option to override, and removing that would be the simplificat= ion.) The tripping point of #137, however, is that it may need a recovery path (i= .e. a second A/AAAA resolution) in case the records come from mismatched pr= oviders. We don't currently have data on how often that would happen -- wh= ether it's 10% or 0.001% of the time would make a big difference. -----Original Message----- From: TLS On Behalf Of Christopher Wood Sent: Wednesday, February 27, 2019 8:18 AM To: Subject: [TLS] Two Multi-CDN proposals Hi folks, Below are two PRs that seek to address the multi-CDN issue discussed on thi= s list and in meetings: 1. https://github.com/tlswg/draft-ietf-tls-esni/pull/136 2. https://github.com/tlswg/draft-ietf-tls-esni/pull/137 #136 implements the combined or stapled record approach discussed several t= imes, most recently in [1]. It includes these via an ESNIKeys extension. #1= 37 builds on this design with a mechanism that lets clients detect and reco= ver from A/AAAA and ESNI mismatch (if desired). It is certainly more complex in several respects. A third variant, which is= not (yet) in PR form, is a simplification of #137 wherein ESNIKeys address= es are only used as filters, instead of filters *or* complete addresses. We are asking for feedback on these PRs, as we would like to merge one of t= hem for the next draft version. As #136 is simpler and permits extensibilit= y, that is the current preference. Thanks in advance for your feedback. Best, Chris (no hat, on behalf of the authors) [1] https://mailarchive.ietf.org/arch/msg/tls/WXrPgaIsIPItDw3IQthmJk9VRlw _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --_000_CY4PR22MB098340D8B4C6FD7D9EB9C32EDA750CY4PR22MB0983namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Despite the additional complexity of #137, I thin= k it's probably the better approach (and I would be fine with the simplific= ation, if that makes it more palatable).  Particularly when multi-CDN = is used, there's a lot of logic involved in generating the "right" A/AAAA record in response to a request= .  #136 essentially lets the ESNIKeys result override the A/AAAA, whic= h means ESNIKeys needs to be equally tailored and duplicate all the existin= g logic for a new record type.  In #137, the ESNIKeys essentially contains enough information to check that the A/AAAA results c= ame from the same entity as the ESNIKeys result but leaves the DNS complexi= ty where it already exists.  (It has the option to override, and removing that would be the simplification.)<= o:p>

 

The tripping point of #137, however, is that it m= ay need a recovery path (i.e. a second A/AAAA resolution) in case the recor= ds come from mismatched providers.  We don't currently have data on ho= w often that would happen -- whether it's 10% or 0.001% of the time would make a big difference.

 

-----Original Message-----
From: TLS <tls-bounces@ietf.org> On Behalf Of Christopher Wood
Sent: Wednesday, February 27, 2019 8:18 AM
To: <tls@ietf.org> <tls@ietf.org>
Subject: [TLS] Two Multi-CDN proposals

 

Hi folks,

 

Below are two PRs that seek to address the multi-= CDN issue discussed on this list and in meetings:

 

   1. https://github.com/tl= swg/draft-ietf-tls-esni/pull/136

   2. https://github.com/tl= swg/draft-ietf-tls-esni/pull/137

 

#136 implements the combined or stapled record ap= proach discussed several times, most recently in [1]. It includes these via= an ESNIKeys extension. #137 builds on this design with a mechanism that le= ts clients detect and recover from A/AAAA and ESNI mismatch (if desired).

It is certainly more complex in several respects.= A third variant, which is not (yet) in PR form, is a simplification of #13= 7 wherein ESNIKeys addresses are only used as filters, instead of filters *= or* complete addresses.

 

We are asking for feedback on these PRs, as we wo= uld like to merge one of them for the next draft version. As #136 is simple= r and permits extensibility, that is the current preference.

 

Thanks in advance for your feedback.

 

Best,

Chris (no hat, on behalf of the authors)

 

[1] https://mailarchive.i= etf.org/arch/msg/tls/WXrPgaIsIPItDw3IQthmJk9VRlw

 

_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf= .org/mailman/listinfo/tls

--_000_CY4PR22MB098340D8B4C6FD7D9EB9C32EDA750CY4PR22MB0983namp_-- From nobody Wed Feb 27 16:54: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 6A77012D829 for ; Wed, 27 Feb 2019 16:54:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 cm1D57laeEjS for ; Wed, 27 Feb 2019 16:54:54 -0800 (PST) Received: from mail-yw1-xc35.google.com (mail-yw1-xc35.google.com [IPv6:2607:f8b0:4864:20::c35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F242126C15 for ; Wed, 27 Feb 2019 16:54:54 -0800 (PST) Received: by mail-yw1-xc35.google.com with SMTP id x21so9732335ywx.11 for ; Wed, 27 Feb 2019 16:54:54 -0800 (PST) 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=F1ukMzSCQEEp5aQgkX8jUhC1paNE2IjaOxHdu1apFU8=; b=Gx4zEaR8XBr22dPIe5lKjHJJHC2Rc7VUYHbao59ve8nes2MDcM5mPjWp8JsDTZhxXY pmbP/0Bc4IFtPJJPAT/WOCoDGQ3gt/785MIG5Cd1j9PqNL7b6iVh6UzWr3qh4WjhAmjm B1VRW5FibgwFzHRSYAztFwqK27aZj8vReYmh+3lOBdF7BYjaWSQV0wFFoHrslbJYXzh/ aTepLLHrN+5VBsyOqRCv41XUOHgMkrOCWd0AlNUn72IaVR3ueYctlRYePxr5jyr1kS8m 8kzTLQJFj2vNf5qKq2CXXciFbfMp8Ic1fMndFy6XwG6UqWmzpwH4qa3UrEPS6iaqtKhf cYVQ== 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=F1ukMzSCQEEp5aQgkX8jUhC1paNE2IjaOxHdu1apFU8=; b=Vz/bK9kAhjlY8cgBiSJUFntdvLi42f0thGW1akK3ga+7yhZHf8pQicPdSyicg7VJjq 17EuI5ccloIyaiwCGfEU8PeOnL+8/FCLwLXrdDTqSlDUDqpBD6N5qR8bxH0eBvVnRjV+ vWW7nTykZGSHSrkQouhmzFPfLVe7MkUkqv9dRKaA9XZs3adIt7L2kYEBpMSO7rcUdrpk JTBeBYBoFHWOyhGRaisnBzXEm+IBx1DZTcj2d6Bya1vqZnRCohnzanpjZZW9XL77gbqQ j3Tu8hngJsew6gwuudVJ+ABGnj/KaSfumc4hvFn0SCUIS98z/0YWgVlpxMiAapzAZBSH udeQ== X-Gm-Message-State: AHQUAuYoQVBh2O+wY20lvb79j94xt7wWcravopMi3spkWEP8iBUYMToF iEtKam6wG0VcuC1MbnMsW+uhOgrNuh/47YYNgZ+28Mh8NZ8= X-Google-Smtp-Source: AHgI3IYNhZhwDGxHdyWQwujcbpVchF9Cn6burWU3AQo+kYvvOs/Mx8lut62OavILghfL/OvUVld890AnAP8JX2SGXso= X-Received: by 2002:a25:7650:: with SMTP id r77mr4419275ybc.206.1551315292906; Wed, 27 Feb 2019 16:54:52 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Christopher Wood Date: Wed, 27 Feb 2019 16:54:41 -0800 Message-ID: To: Mike Bishop Cc: "" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Two Multi-CDN proposals 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, 28 Feb 2019 00:54:56 -0000 On Wed, Feb 27, 2019 at 4:36 PM Mike Bishop wrote: > > Despite the additional complexity of #137, I think it's probably the bett= er approach (and I would be fine with the simplification, if that makes it = more palatable). Particularly when multi-CDN is used, there's a lot of log= ic involved in generating the "right" A/AAAA record in response to a reques= t. #136 essentially lets the ESNIKeys result override the A/AAAA, which me= ans ESNIKeys needs to be equally tailored and duplicate all the existing lo= gic for a new record type. In #137, the ESNIKeys essentially contains enou= gh information to check that the A/AAAA results came from the same entity a= s the ESNIKeys result but leaves the DNS complexity where it already exists= . (It has the option to override, and removing that would be the simplific= ation.) > > The tripping point of #137, however, is that it may need a recovery path = (i.e. a second A/AAAA resolution) in case the records come from mismatched = providers. We don't currently have data on how often that would happen -- = whether it's 10% or 0.001% of the time would make a big difference. Thanks, Mike! I agree with the technical descriptions of both approaches. Since each design uses an extension, could we pursue them simultaneously? I'm not sure we must necessarily choose one or the other here. (Perhaps I should have emphasized that in my original message. Oops.) Best, Chris From nobody Wed Feb 27 17:24: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 57AE01277D2 for ; Wed, 27 Feb 2019 17:24:24 -0800 (PST) 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 Zw2iORywDeYA for ; Wed, 27 Feb 2019 17:24:21 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2628130EB3 for ; Wed, 27 Feb 2019 17:24:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 929CABE2E; Thu, 28 Feb 2019 01:24:17 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yt6eDVjNLRzj; Thu, 28 Feb 2019 01:24:15 +0000 (GMT) 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 99BD7BE24; Thu, 28 Feb 2019 01:24:15 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1551317055; bh=ciJTFBL1xDYz1BcUBapQboJwkGEvr37Z3MDh+0mvwsE=; h=To:References:From:Subject:Date:In-Reply-To:From; b=w2A7Y+npINJysps0IetOr4I9kxEpUktZ+XGnxXK+d4MsdKxf7IrPFO4nOYs1yD9oG Y9iaM6pida7ptEgRTDN1gVrC6U3JRrm9xsVWF54xczx5kcMBzkgxro8Fwh1piPJHku rDQSyYoCS/mUwiZYB1NtBVgZce4W+gbnVz34HZSg= To: Christopher Wood , "" References: 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: <0b19d021-8101-23ee-2899-450d103a8906@cs.tcd.ie> Date: Thu, 28 Feb 2019 01:24:14 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="uleOLZzm10i7qUvJPnxxp9f7MrRFWXsE1" Archived-At: Subject: Re: [TLS] Two Multi-CDN proposals 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, 28 Feb 2019 01:24:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uleOLZzm10i7qUvJPnxxp9f7MrRFWXsE1 Content-Type: multipart/mixed; boundary="w84DlxyF0uVn18OndMa5UvDGGZedpZ2OI"; protected-headers="v1" From: Stephen Farrell To: Christopher Wood , "" Message-ID: <0b19d021-8101-23ee-2899-450d103a8906@cs.tcd.ie> Subject: Re: [TLS] Two Multi-CDN proposals References: In-Reply-To: --w84DlxyF0uVn18OndMa5UvDGGZedpZ2OI Content-Type: multipart/mixed; boundary="------------F80606CF08A198BF855AECBA" Content-Language: en-GB This is a multi-part message in MIME format. --------------F80606CF08A198BF855AECBA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, First, I think both are wrong:-) If there are really different ESNI private value holders, then each of those should provide separate ESNIKeys RR value instances and the set of all of those should be in the RRset returned when the ESNIKeys are queried. Requiring different private value holders to find some entity to wrap up all their crap into one single TLS blob is not, IMO, a good design. That said, we can fix that later I guess, even though we will have to fix it sometime. (Fixing it now would be better!) So I regard these ESNIKeys syntax decisions as only holding temporarily. On 27/02/2019 16:18, Christopher Wood wrote: > Hi folks, >=20 > Below are two PRs that seek to address the multi-CDN issue discussed > on this list and in meetings: >=20 > 1. https://github.com/tlswg/draft-ietf-tls-esni/pull/136 > 2. https://github.com/tlswg/draft-ietf-tls-esni/pull/137 I'm not sure of the details of #137 but I think I prefer that one a bit. I suspect either of them will be a pain to code given how we'll be mixing names and addresses. #136 seems broken to me in that it gives the new AddressSet invention priority over A/AAAA resolution. I think that'd need much more justification as it essentially calls for duplicating A/AAAA information over two administrative domains which seems like a recipe for failure. If #137 is adding mandatory extensions that are analogous to X.509 extension criticality, then I think that's an error. Despite good arguments, that has not worked out well and this seems like the same mistake. (But as stated above, I think all syntax here is temporary until we've made it DNS admin friendly which it is not.) My reason for preferring #137 is that (if I'm reading it right, and I'm not sure!), it resolves a CNAME and then compares the resulting A/AAAA acquired via normal CNAME chasing to a mask from the ESNIKeys stuff. I think that is a better approach than replicating A/AAAA values inside a novel repetitive structure like ESNIKeys. Lastly, we will need to fix the TLS-developer-friendly but DNS-admin-unfriendly ESNIKeys structure, so why not do that now too, as we're modifying it? IMO the way to do that is for each ESNI private value holder's stuff to be a separate RR value in the RRset (and so each is likely a separate stanza in a zone file). I also think if we did that we'd be able to simplify the ESNIKeys structure a good bit all of which should lead to more robust and simpler code. My current code for handling ESNIKeys is very complex and long even though I've ignored the supposed ways in which things can be extended - were I to have to add real extension handling, it'd be even worse. Changing to >1 RR value in the answer could make all this an awful lot simpler and much better match the multi-CDN (or more properly multi-private-value) scenarios. So in summary: - both are wrong:-) - if I had to pick one to proceed with temporarily, I'd go with #137 despite it being unclear - I'd rather we fix the ESNIKeys to be DNS friendly now too and not wait to have to inevitably fight that battle later (but fight I will:-) Cheers, S. >=20 > #136 implements the combined or stapled record approach discussed > several times, most recently in [1]. It includes these via an ESNIKeys > extension. #137 builds on this design with a mechanism that lets > clients detect and recover from A/AAAA and ESNI mismatch (if desired). > It is certainly more complex in several respects. A third variant, > which is not (yet) in PR form, is a simplification of #137 wherein > ESNIKeys addresses are only used as filters, instead of filters *or* > complete addresses. >=20 > We are asking for feedback on these PRs, as we would like to merge one > of them for the next draft version. As #136 is simpler and permits > extensibility, that is the current preference. >=20 > Thanks in advance for your feedback. >=20 > Best, > Chris (no hat, on behalf of the authors) >=20 > [1] https://mailarchive.ietf.org/arch/msg/tls/WXrPgaIsIPItDw3IQthmJk9VR= lw >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --------------F80606CF08A198BF855AECBA 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 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5tDJTdGVwaGVuIEZhcnJlbGwgKDIwMTcp IDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJCZQmAAUL CQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1yw aps8HGUNhLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG +48od+Xn7qg6LT7GrHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXk kTFaSGYJj3yIP4R6IgwBYGMzDXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRr pZtXB1XQc23ZZmrlTkl2HaThL6w3YKdiTi1NbuMeOxZqtXcUshII45sANm4HuWNT iRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS3MmGgVS4ZoX8+VaPGpXdQVFy BMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml3OEuIQiP2ehRt/HV LMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi2/Jrsz6M zh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6 TzKjGjruq8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxIkBHAQQAQgABgUCWj1SoAAK CRAvPIc2gF+NovMcCACVZPo1cQa3D+vWaIo0ZyinO/MgtD2gHysoj1T0Qvq05//L ZXmhh578bJANvdl2g/HFhhwl/5HKIfWcyipQhmJklp/dsleKcNnn4B18T75RHY0G +po3ILq7evbiOjUH+xqApti1aCxi1GocsPghaLfsxmtXKMG4Xu7XhDTv66GOrqZf Y7+0ekJjD9Dza1t5NE/JR/VZA4B8PWR8Glb0+8C9rkjD0VZ5ekJdHPDGcJmFh8Z+ q25LDoI8Fgt1uKSowvoVnsQO5MFv/y6bXArtj1uB4hAL4JiOFgHlFdrW0MlFpvYm ziW4K9JHTD8KAfDbrb3e2W97ZDpROuYfE/lTbYOWiQI9BBMBCAAnBQJaPVAyAhsD BQkJlCYABQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEFqy+vF7Fyvq0mkP/ius gsf6Z4/Tu+vHzBbl5i6oKI8ZieH8JfEgXx4ut9t7l3hBGC2r7DpR5A8zLMpEhGIK gFcHagksFkfLEE/FmWDfd1MysQafxBYrHaI27P2tkxfI5JYV6247TV39pQ93kGds tsjIrmh/zEJCVczoofxtz72BDt51H2Z8tN28F/YVHnbaGDwFEEzWKYpze87y/f36 ogcdGO6LDEEEIA6Ee0dGxleuKlLS4UDTt0zjo6L8TyiyPHp9C3+UfnP8837Zp3Fh KstIBd+vWgPdHFg2G5aDIYUvrj9UJBvVgaN/RnkwE+dab2OBSg5jkr141JLQvzdZ 4mOUXn5D9Y6AH6tvj0+ubYMV6j35L1/ZXncuXPVYiylcmDp/6f2WYcT3gx9CPUYA cLMjQV4vX2W8z4uEPyMlIJuGsLf7KhvLL8BQ6zlncT6eONfUUX9UJUCzqI5rqL5c b5jWGHeKvbLWRyQnlq5PXQxJTwYRm71rJTgzejc33LE6Nqg/Q25Dgwwsv+f+7i73 gB5loc80Fef+FV9VFGalFe0Yq8m0UASmkYRh7MH5ssoibpeWk+SGfBjOV4tnsAwR yjYLpAzxA8HeDcmlLeypGEDmsQ/iUvXoGaKOYX4Ieg8T/PCAplsqnJUOq8hbkgOC 98gLZfiltkNG8YhQpoZIHj6SxmBRSc3K99CvanuOiQIzBBABCAAdFiEEfhcKBFyE z0YOK3mgEO952f2DUxIFAlu3JJsACgkQEO952f2DUxJ4qRAAmbjiO3WTAeBCB4ME p2N2+XQCMTTFURDGuJnqU/+X//fhhPRq4V/OxgisKFKlBcAS2hsECvg6HDVSz4Fl 74fk/y+botG4/CjMLdKPB9fgh5zz72i3q0hWDixt50NKBv8IIVWOyYgZxDU/vcks lMEnqbFgJX+CfdALpvAM4WjuQP0UMcKNE3xd+EdDhD1xjK3Tq4XfWob9q6aBZgL2 B4IaADCIeDDE1hv0agnSJmMJE7Bti8tNxCCxVRbZtOaxVHXdRUoOx2XTaxFXupxV hbpHRrdFrwq51f6e3bkfkNEZ3fzYpnlbynJ2zL++JO8P3Pq/S6UKEFjEB50i8YgK WuFvGUsQ+YiDgiZU4saqxSBWbfYn3lY6MSSTg8RnXbFIMG3CFImqYk1uhaV+bDjc p0htjzM2F98g7c3o7sWx0bGarId4uhOmpj7JJVQ+lu7Jby6Ocj8n//7qF1Nn11Cw QlCVaeAq5Y5DmZrnww9I3zzOWWyqFkAVCM3GqeRLMvplD6/+O+5FF7XoHzQB47nk OyZtawy/9gssPWZKLv4qHLYS0wGGCiNbCsYy90s3pfeafM0kSxxjIvEz21KT6LJI /awu2ErQFWCkDMFJ1p/97MjPrQ/6d4cPO140V/wyfuWaBiTVqa9mgnb2zn6fYfDH JEvl1UzIx3JCae25tty1+qtnS0i0LlN0ZXBoZW4gRmFycmVsbCA8c3RlcGhlbkB0 b2xlcmFudG5ldHdvcmtzLmNvbT6JAj0EEwEIACcFAlo9UVoCGwMFCQmUJgAFCwkI BwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+o7HBAAxHAdFkBGZ9gJK8w7 NUYS9C6enGYtAYoKH5G3Bn3YScjErNfQtHYb53KwBQpVSOv1HcN8hbQ8mLTgn9lt zNwNSuv0XxIswi807HRSIZ4vYDiS5VKV1YkLYK5bLY5O4alVdzqM+AZQqkuHBu63 6n+C0ED6UwLhVBFfSNvBQVAdoq6gvr+IE8rCIKTMNGwNcgVPbF+YxP7UZM6p7s2a 5MIqGw7URSfaqfuztibXGOBLFbSwLGqHSSnOXBfEeDrwdZ+ur8cXIIPRIeCTVmeO 8bGgpgBqNQXG9oyGN+TrYAC+4Ahi0UjCk7QGj8tf3xICKoQpYyfceNBZJ/969gV9 tVgvRxUjxUwc9kZbi0c8XYMTq5GCvBIh1D6BOW9QBM2SsNgG3l36+e3+c2LDdyKn 20C1IzGLVDdcCtz42/onQ/e9sMlzFrfLjs5SO2/TnLvp2JtsIQXyb/T5qd0GE5j8 /iwfZR+uVTVVEsUl1a+Yllzt6sdR7RIhhKpKaKzEAk4d0+VHdz7zEkQRRSjbPVoS fy8c/kld9Fi8Buna+ZkKpcwIW+D4XP83pGcl0XUv6AyqwS1LnEt+jv/+PSXskYtU Lzn8Z35iKkSAH/5Nz6GCZk6ORPNv/6+UI92BpUbu/G2tBwK8bPgAg+gJxBx3G7MK W7VRCmM5UrtAK9A3O70VjPyMkHSJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLC LAf/X/9vRTZWtwSXxiBCA54a6hg9IvW0mvPUqgXfvrhtOk0IFucLKrTXK8J/NcmU 6ulxOovVbQ+Bin6gtHeCmSa/W523g/NXCOuFTnS/MyVibNL4+RCFwqGysl++Cm+L nj1MmasE9kO+CNdervx8APfxV7D6OYrG4eGag+LdFR6VpJn6tRT0/WvyT8l+Oqiq gdhXHv+0MvkkD9TX5LlJW4VB/yRvWkkmL5N5c5zYh+NcfTPhQ5S9dOorVzrm65d6 Itn0937Ennau7s7fiFdA0BHjWqEAFLsBIXQfCFjjKjdsKA4xlSiX7X7ElmPYpWa5 wwTQ66dL0anMd9y1DJCMOHe4gYkCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9 g1MSBQJbtyScAAoJEBDvedn9g1MSY7sP+gKR0rFU1g+GtB+hSdtwPRbacvml2eL2 Jc5Eq37J9hAqxHyt5V0If7s8IyVA2GXgdfwULBWbXGDUDiUkh20OPQRUS8G9Sf8A WRuG25q5C8ZzWygykL88RKXJZDFtA49CeqO5Bq5syBhq4QfiSTffQHIp3h0boPGU hSBEUQpooMXYQClNARQ+z/uRzR5bUi9wxdXNnxTn9ia4ASlaBPvUYTGY1jW2HrRR SwpI12+UaWsvc3jJtQ8X0kxgJ7jsFF1uqquIZ5eflQv+PHHg2RJSy37u0UFGb+OK ZEkzlmbPokKCYhzBR5PcD6sgdlaJNcidmto9u1oV6yZT8J2W4CTuUclgxt6f3lZq ZeVLnNnbHyKUdeypwLlqYISulfnMhZ3A6Bgpf2BtjL6KJbFtPBYmYdxI+HZyY49u U2ZHhRu+CSQ1y7zGKSX0gRp5hE7+A4XJtsT6lTLhbi9aiZTG1S6zKNhl3qNNzszc r27PrvFiyGhpuYQuzdQl2PMGbOI6Ojif3sab53NO3RLsLOM09wIlr95yKLlkXkUr WcvUJGrw6HKm8j5opXHTwmJOAbDpc6cMDu+ITRu4spdCnQJcE8RkO8tKyaLuh2Gt U5kYSBK97yr5VviX1FK6rY14LLmnE16OPiK2tiVBKy9nGM0DKtY+K9WcoRZ7s/d7 O0bMfzcNPtGLuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiez GPuBHmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9Wf pHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC 6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2 D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFe A7PbTuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ /Vf3vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbpt PEcmoazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKr em5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96 Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYgh x8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQ oqj1gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P /1tF6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8 Wpfdn3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJ gx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5 SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2 oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIA ypqYo3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoM eDQkd0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS /qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZ IMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XO KVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DJ121 -----END PGP PUBLIC KEY BLOCK----- --------------F80606CF08A198BF855AECBA-- --w84DlxyF0uVn18OndMa5UvDGGZedpZ2OI-- --uleOLZzm10i7qUvJPnxxp9f7MrRFWXsE1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlx3OD4ACgkQWrL68XsX K+qYiBAAl28rNDtDmTYVIAkfQRR2KCoKEN5kel7xeoxCwya4bujfe0y9xytu7EIE SeiHXEvH1k4Tka6BbZ7XPrJmOahnXNXLyYI+khnW5kFs8xh4bySDbBIRKWaU04K+ oRrUX1B9sQ2UI4JyqlB0qC8y6fKULUT1qrxoFlq7btAz05kS3Lr5mbZbELUFi+iW MUI+Zgtow9q4Dcs3yq+bbgFXESK6tk6RRGy7UdbuZk7cZLntw6A+jstkT86U6R9q aiWuFb4jGZ35r2WpEkjkhnzx7ZBfuRcnnxzD6YqpgDtYVuvlqd6bS4sqAvf92EoV vLBmP+TrhSyoejqUEJgB6eRmETfpzsDz4nI5xvdr73pw+mbptvDMuXIU/MokVPer u1IwZIHRN9sFYWcmOV8Y8mfmdikMRHp179qWSQWV/qniVxRneD1ZjVYQgu3Znuq2 rHDBB8JupNot3Fg7x3lBjlrHO1n+JrkDPAoMzQoQipG4gMRmRTc8k4HWGcqamLyQ zNVmuVo7FWj7GMQnyKx5idsyKKvvZhb/K0UtlCgFAVzXxAiUTx+5+Zx48GGcFmY4 lYeSxNE6aMuPgzUmdd1v4tKHXNNRR9awinlYjDDmdlvHOn93vnoTvt0qfHT3SDqe wApDZLsRqAQTyWaYJyGN6gZZb/tvhWiQw+8O6ssEeo8rTX/7MVA= =V5tl -----END PGP SIGNATURE----- --uleOLZzm10i7qUvJPnxxp9f7MrRFWXsE1-- From nobody Wed Feb 27 17:42: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 A5A87130EAB for ; Wed, 27 Feb 2019 17:42:40 -0800 (PST) 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwRwEi44iQsL for ; Wed, 27 Feb 2019 17:42:37 -0800 (PST) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 650551277D2 for ; Wed, 27 Feb 2019 17:42:36 -0800 (PST) Received: by mail-lf1-x136.google.com with SMTP id x206so5962299lff.3 for ; Wed, 27 Feb 2019 17:42:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9kaWs7gKrLyJ9agiC0++HXt6kkJwLfV1sFDsB6eaa58=; b=xTqZal19z1PEFwsl54dSkugyOuRWkfUq5MOxeLuWDC0C0HyJoCVE+neQI/tkWR+YSZ 76dUlcDpbGeBZheDIWW8m+aM8KAMijcjJldK2y9GxLroFghVcG9Xys4P7g+aKzDwOQ+P IRZVoW8+E9DPp4/t+KOG9GsESsuTyq3j1fRRy7nAUd4x/Qx92Ik966CggcEXg8c8CEiR v5DfHDb1DCOBxSbDSYVSVcIYHsDhw+nQlMljXNFp29Wf+F4Gj1eXUMUlh8Mn0h9ajk2S vzAdNUPDAud5RXJL7xwYVZrKG54Ryal1xLTcF21mgPJ90h9559fqevpUKnhuNQMJnxke mvdQ== 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=9kaWs7gKrLyJ9agiC0++HXt6kkJwLfV1sFDsB6eaa58=; b=ZC4MCUGSP4+kfPKffLWLKIpo//x5UTfk2pqTvgd4nlMs5PR74PIlX0XU54Jd+hc5ig KFEYSN+0EVjG8+1+89ebNLNzgujVzbpeDJZkaCvio7fUjBugLNGGdm39DfSocb882fse TplyPcwpD8SfLZfU0xRdxFP47kS3h+taqaSDhofjQ5qfytqPu6u7LKRg1SHmyEvtybSm vpHZx0+hcZmRxlYTspd2YOIf1RO0K5IPAnq7I/iW7QE/6oOed9IsshhrCvVAowYD7Xle Xz9PU6faVQOkH/I6utjb8RGr5Mg5VsE9kVWbza5R9MGG6V1VMV36tIMuXt6cug44W53W CErA== X-Gm-Message-State: AHQUAuYkTVR6PXVBbXv0fWDIzXeODyR2fXlq2tTEcK/TJNKnOmBse8nR VaYMlJnzcyr35P5FnC2uCBlDUjElKhTuA+YkS6dN6w== X-Google-Smtp-Source: AHgI3Iaoi9/vLpdYu0ueVarts8Mr3umobwewj0DrT3mV45bUO0NsaJHFTqOPtjlDI2awehpv+8XdnyjjtNNXyyIdCsE= X-Received: by 2002:ac2:51bc:: with SMTP id f28mr2724288lfk.123.1551318154354; Wed, 27 Feb 2019 17:42:34 -0800 (PST) MIME-Version: 1.0 References: <0b19d021-8101-23ee-2899-450d103a8906@cs.tcd.ie> In-Reply-To: <0b19d021-8101-23ee-2899-450d103a8906@cs.tcd.ie> From: Eric Rescorla Date: Wed, 27 Feb 2019 17:41:56 -0800 Message-ID: To: Stephen Farrell Cc: Christopher Wood , "" Content-Type: multipart/alternative; boundary="0000000000008635710582ea6785" Archived-At: Subject: Re: [TLS] Two Multi-CDN proposals 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, 28 Feb 2019 01:42:41 -0000 --0000000000008635710582ea6785 Content-Type: text/plain; charset="UTF-8" On Wed, Feb 27, 2019 at 5:24 PM Stephen Farrell wrote: > > Hiya, > > First, I think both are wrong:-) > > If there are really different ESNI private value holders, > then each of those should provide separate ESNIKeys RR value > instances Yes, this is the idea and the set of all of those should be in the RRset > returned when the ESNIKeys are queried. > I think you're misunderstanding the scenario here: we have two CDNs A and B, and some switching service in front, so that when you lookup example.com, you get a CNAME to A or B, and then you get the ESNIKeySet for A or B as the case may be. So you're not going to get both ESNIKeys values. > Requiring different private value holders to find some > entity to wrap up all their crap into one single TLS blob > is not, IMO, a good design. > That's not the way this works. > On 27/02/2019 16:18, Christopher Wood wrote: > > Hi folks, > > > > Below are two PRs that seek to address the multi-CDN issue discussed > > on this list and in meetings: > > > > 1. https://github.com/tlswg/draft-ietf-tls-esni/pull/136 > > 2. https://github.com/tlswg/draft-ietf-tls-esni/pull/137 > > I'm not sure of the details of #137 but I think I prefer > that one a bit. I suspect either of them will be a pain to > code given how we'll be mixing names and addresses. > > #136 seems broken to me in that it gives the new AddressSet > invention priority over A/AAAA resolution. I think that'd > need much more justification as it essentially calls for > duplicating A/AAAA information over two administrative > domains which seems like a recipe for failure. > This is not correct for the reasons I indicated above. What happens is that the terminal CDN is responsible for publishing a record with its keys and its A/AAAA values. Indeed, the source of the problem we are trying to solve is that you might in successive resolutions get the CNAME for A and B, thus having a keys/A mismatch. > > My reason for preferring #137 is that (if I'm reading it > right, and I'm not sure!), it resolves a CNAME and then > compares the resulting A/AAAA acquired via normal CNAME > chasing to a mask from the ESNIKeys stuff. I think that > is a better approach than replicating A/AAAA values inside > a novel repetitive structure like ESNIKeys. > > Lastly, we will need to fix the TLS-developer-friendly > but DNS-admin-unfriendly ESNIKeys structure, [Citation needed] IMO the way to do > that is for each ESNI private value holder's stuff to be > a separate RR value in the RRset (and so each is likely a > separate stanza in a zone file). This seems to rest on the same misunderstanding of the scenario in question. -Ekr So in summary: > > - both are wrong:-) > - if I had to pick one to proceed with temporarily, > I'd go with #137 despite it being unclear > - I'd rather we fix the ESNIKeys to be DNS friendly > now too and not wait to have to inevitably fight > that battle later (but fight I will:-) > > Cheers, > S. > > > > > #136 implements the combined or stapled record approach discussed > > several times, most recently in [1]. It includes these via an ESNIKeys > > extension. #137 builds on this design with a mechanism that lets > > clients detect and recover from A/AAAA and ESNI mismatch (if desired). > > It is certainly more complex in several respects. A third variant, > > which is not (yet) in PR form, is a simplification of #137 wherein > > ESNIKeys addresses are only used as filters, instead of filters *or* > > complete addresses. > > > > We are asking for feedback on these PRs, as we would like to merge one > > of them for the next draft version. As #136 is simpler and permits > > extensibility, that is the current preference. > > > > Thanks in advance for your feedback. > > > > Best, > > Chris (no hat, on behalf of the authors) > > > > [1] > https://mailarchive.ietf.org/arch/msg/tls/WXrPgaIsIPItDw3IQthmJk9VRlw > > > > _______________________________________________ > > 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 > --0000000000008635710582ea6785 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Feb 27, 2019 at 5:24 PM Steph= en Farrell <stephen.farrell= @cs.tcd.ie> wrote:

Hiya,

First, I think both are wrong:-)

If there are really different ESNI private value holders,
then each of those should provide separate ESNIKeys RR value
instances

Yes, this is the idea
=

and the set of all of those should be in the RRset
returned when the ESNIKeys are queried.

I think you're misunderstanding the scenario here: we have two CDNs A = and B, and some switching service in front, so that when you lookup example.com, you get a CNAME to A or B, and the= n you get the ESNIKeySet for A or B as the case may be. So you're not g= oing to get both ESNIKeys values.



Requiring different private value holders to find some
entity to wrap up all their crap into one single TLS blob
is not, IMO, a good design.

That's = not the way this works.


=C2=A0
On 27/02/2019 16:18, Christopher Wood wrote:
> Hi folks,
>
> Below are two PRs that seek to address the multi-CDN issue discussed > on this list and in meetings:
>
>=C2=A0 =C2=A0 1. https://github.com/tlswg/d= raft-ietf-tls-esni/pull/136
>=C2=A0 =C2=A0 2. https://github.com/tlswg/d= raft-ietf-tls-esni/pull/137

I'm not sure of the details of #137 but I think I prefer
that one a bit. I suspect either of them will be a pain to
code given how we'll be mixing names and addresses.

#136 seems broken to me in that it gives the new AddressSet
invention priority over A/AAAA resolution. I think that'd
need much more justification as it essentially calls for
duplicating A/AAAA information over two administrative
domains which seems like a recipe for failure.

This is not correct for the reasons I indicated above. What happens= is that the terminal CDN is responsible for publishing a record with its k= eys and its A/AAAA values. Indeed, the source of the problem we are trying = to solve is that you might in successive resolutions get the CNAME for A an= d B, thus having a keys/A mismatch.


=
=C2=A0

My reason for preferring #137 is that (if I'm reading it
right, and I'm not sure!), it resolves a CNAME and then
compares the resulting A/AAAA acquired via normal CNAME
chasing to a mask from the ESNIKeys stuff. I think that
is a better approach than replicating A/AAAA values inside
a novel repetitive structure like ESNIKeys.

Lastly, we will need to fix the TLS-developer-friendly
but DNS-admin-unfriendly ESNIKeys structure,

[Citation needed]



IMO the way to do
that is for each ESNI private value holder's stuff to be
a separate RR value in the RRset (and so each is likely a
separate stanza in a zone file).

This seem= s to rest on the same misunderstanding of the scenario in question.

-Ekr


So in summary:

- both are wrong:-)
- if I had to pick one to proceed with temporarily,
=C2=A0 I'd go with #137 despite it being unclear
- I'd rather we fix the ESNIKeys to be DNS friendly
=C2=A0 now too and not wait to have to inevitably fight
=C2=A0 that battle later (but fight I will:-)

Cheers,
S.

>
> #136 implements the combined or stapled record approach discussed
> several times, most recently in [1]. It includes these via an ESNIKeys=
> extension. #137 builds on this design with a mechanism that lets
> clients detect and recover from A/AAAA and ESNI mismatch (if desired).=
> It is certainly more complex in several respects. A third variant,
> which is not (yet) in PR form, is a simplification of #137 wherein
> ESNIKeys addresses are only used as filters, instead of filters *or* > complete addresses.
>
> We are asking for feedback on these PRs, as we would like to merge one=
> of them for the next draft version. As #136 is simpler and permits
> extensibility, that is the current preference.
>
> Thanks in advance for your feedback.
>
> Best,
> Chris (no hat, on behalf of the authors)
>
> [1] https://mailarchive.ie= tf.org/arch/msg/tls/WXrPgaIsIPItDw3IQthmJk9VRlw
>
> _______________________________________________
> 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
--0000000000008635710582ea6785-- From nobody Wed Feb 27 17:56: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 6BA7C130ECF for ; Wed, 27 Feb 2019 17:56:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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] 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 YjPTwj_CL4sm for ; Wed, 27 Feb 2019 17:56:03 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 608F31277D2 for ; Wed, 27 Feb 2019 17:56:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 91B84BE38; Thu, 28 Feb 2019 01:56:00 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omGVxEIMygqF; Thu, 28 Feb 2019 01:55:59 +0000 (GMT) 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 3A394BE2E; Thu, 28 Feb 2019 01:55:59 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1551318959; bh=ToEIf/lnC967jT5tAdJE6K52KX34K3+gnyZsGHll/1s=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=jK0ZxTto2zyODmRhpYYptPyswUkVOEJLbhLYDBqYj+55+WPDs1QYTzTAgutMOugca TrTY3kOEHSi6T/X+xejmmeXwXdaR6vfs1dUkTeG341XftQZ5Ad4WWYFssXBUkBpQeK 3JKYpag85h6WOZd4NQ0DLKXii4RhiAjPOqtLPYwc= To: Eric Rescorla Cc: Christopher Wood , "" References: <0b19d021-8101-23ee-2899-450d103a8906@cs.tcd.ie> 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: <0b854704-8f93-f9ad-c067-67f7f73cbbbf@cs.tcd.ie> Date: Thu, 28 Feb 2019 01:55:57 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="i6JMLsfjxe9XVv7OwNEAv2lf2tD4MzHP5" Archived-At: Subject: Re: [TLS] Two Multi-CDN proposals 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, 28 Feb 2019 01:56:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --i6JMLsfjxe9XVv7OwNEAv2lf2tD4MzHP5 Content-Type: multipart/mixed; boundary="dEODZyL9qsVMmKnRC5HyvMkgqYYwa5knn"; protected-headers="v1" From: Stephen Farrell To: Eric Rescorla Cc: Christopher Wood , "" Message-ID: <0b854704-8f93-f9ad-c067-67f7f73cbbbf@cs.tcd.ie> Subject: Re: [TLS] Two Multi-CDN proposals References: <0b19d021-8101-23ee-2899-450d103a8906@cs.tcd.ie> In-Reply-To: --dEODZyL9qsVMmKnRC5HyvMkgqYYwa5knn Content-Type: multipart/mixed; boundary="------------C6E615408A45351CAA8FBF72" Content-Language: en-GB This is a multi-part message in MIME format. --------------C6E615408A45351CAA8FBF72 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 28/02/2019 01:41, Eric Rescorla wrote: > I think you're misunderstanding the scenario here: we have two CDNs A a= nd > B, and some switching service in front, so that when you lookup example= =2Ecom, > you get a CNAME to A or B, and then you get the ESNIKeySet=20 (ESNIKeySet is a type you've just invented I guess?) > for A or B as > the case may be. So you're not going to get both ESNIKeys values. Yes, that's not the model I had in mind. I don't recall that having been written down but maybe I missed it. (Where should I look?) The model I had in mind was where the hidden site has it's own DNS operator but >1 CDN/front-site with each of those having a private ESNI value. (And if there's some front-end DNS cleverness, it'd kick in when the CNAME from #137 is being chased down.) Cheers, S. PS: I nonetheless maintain my points about the current ESNIKeys structure - it's over generic and over complex and these PRs can only make that worse:-) --------------C6E615408A45351CAA8FBF72 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 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5tDJTdGVwaGVuIEZhcnJlbGwgKDIwMTcp IDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJCZQmAAUL CQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1yw aps8HGUNhLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG +48od+Xn7qg6LT7GrHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXk kTFaSGYJj3yIP4R6IgwBYGMzDXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRr pZtXB1XQc23ZZmrlTkl2HaThL6w3YKdiTi1NbuMeOxZqtXcUshII45sANm4HuWNT iRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS3MmGgVS4ZoX8+VaPGpXdQVFy BMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml3OEuIQiP2ehRt/HV LMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi2/Jrsz6M zh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6 TzKjGjruq8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxIkBHAQQAQgABgUCWj1SoAAK CRAvPIc2gF+NovMcCACVZPo1cQa3D+vWaIo0ZyinO/MgtD2gHysoj1T0Qvq05//L ZXmhh578bJANvdl2g/HFhhwl/5HKIfWcyipQhmJklp/dsleKcNnn4B18T75RHY0G +po3ILq7evbiOjUH+xqApti1aCxi1GocsPghaLfsxmtXKMG4Xu7XhDTv66GOrqZf Y7+0ekJjD9Dza1t5NE/JR/VZA4B8PWR8Glb0+8C9rkjD0VZ5ekJdHPDGcJmFh8Z+ q25LDoI8Fgt1uKSowvoVnsQO5MFv/y6bXArtj1uB4hAL4JiOFgHlFdrW0MlFpvYm ziW4K9JHTD8KAfDbrb3e2W97ZDpROuYfE/lTbYOWiQI9BBMBCAAnBQJaPVAyAhsD BQkJlCYABQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEFqy+vF7Fyvq0mkP/ius gsf6Z4/Tu+vHzBbl5i6oKI8ZieH8JfEgXx4ut9t7l3hBGC2r7DpR5A8zLMpEhGIK gFcHagksFkfLEE/FmWDfd1MysQafxBYrHaI27P2tkxfI5JYV6247TV39pQ93kGds tsjIrmh/zEJCVczoofxtz72BDt51H2Z8tN28F/YVHnbaGDwFEEzWKYpze87y/f36 ogcdGO6LDEEEIA6Ee0dGxleuKlLS4UDTt0zjo6L8TyiyPHp9C3+UfnP8837Zp3Fh KstIBd+vWgPdHFg2G5aDIYUvrj9UJBvVgaN/RnkwE+dab2OBSg5jkr141JLQvzdZ 4mOUXn5D9Y6AH6tvj0+ubYMV6j35L1/ZXncuXPVYiylcmDp/6f2WYcT3gx9CPUYA cLMjQV4vX2W8z4uEPyMlIJuGsLf7KhvLL8BQ6zlncT6eONfUUX9UJUCzqI5rqL5c b5jWGHeKvbLWRyQnlq5PXQxJTwYRm71rJTgzejc33LE6Nqg/Q25Dgwwsv+f+7i73 gB5loc80Fef+FV9VFGalFe0Yq8m0UASmkYRh7MH5ssoibpeWk+SGfBjOV4tnsAwR yjYLpAzxA8HeDcmlLeypGEDmsQ/iUvXoGaKOYX4Ieg8T/PCAplsqnJUOq8hbkgOC 98gLZfiltkNG8YhQpoZIHj6SxmBRSc3K99CvanuOiQIzBBABCAAdFiEEfhcKBFyE z0YOK3mgEO952f2DUxIFAlu3JJsACgkQEO952f2DUxJ4qRAAmbjiO3WTAeBCB4ME p2N2+XQCMTTFURDGuJnqU/+X//fhhPRq4V/OxgisKFKlBcAS2hsECvg6HDVSz4Fl 74fk/y+botG4/CjMLdKPB9fgh5zz72i3q0hWDixt50NKBv8IIVWOyYgZxDU/vcks lMEnqbFgJX+CfdALpvAM4WjuQP0UMcKNE3xd+EdDhD1xjK3Tq4XfWob9q6aBZgL2 B4IaADCIeDDE1hv0agnSJmMJE7Bti8tNxCCxVRbZtOaxVHXdRUoOx2XTaxFXupxV hbpHRrdFrwq51f6e3bkfkNEZ3fzYpnlbynJ2zL++JO8P3Pq/S6UKEFjEB50i8YgK WuFvGUsQ+YiDgiZU4saqxSBWbfYn3lY6MSSTg8RnXbFIMG3CFImqYk1uhaV+bDjc p0htjzM2F98g7c3o7sWx0bGarId4uhOmpj7JJVQ+lu7Jby6Ocj8n//7qF1Nn11Cw QlCVaeAq5Y5DmZrnww9I3zzOWWyqFkAVCM3GqeRLMvplD6/+O+5FF7XoHzQB47nk OyZtawy/9gssPWZKLv4qHLYS0wGGCiNbCsYy90s3pfeafM0kSxxjIvEz21KT6LJI /awu2ErQFWCkDMFJ1p/97MjPrQ/6d4cPO140V/wyfuWaBiTVqa9mgnb2zn6fYfDH JEvl1UzIx3JCae25tty1+qtnS0i0LlN0ZXBoZW4gRmFycmVsbCA8c3RlcGhlbkB0 b2xlcmFudG5ldHdvcmtzLmNvbT6JAj0EEwEIACcFAlo9UVoCGwMFCQmUJgAFCwkI BwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+o7HBAAxHAdFkBGZ9gJK8w7 NUYS9C6enGYtAYoKH5G3Bn3YScjErNfQtHYb53KwBQpVSOv1HcN8hbQ8mLTgn9lt zNwNSuv0XxIswi807HRSIZ4vYDiS5VKV1YkLYK5bLY5O4alVdzqM+AZQqkuHBu63 6n+C0ED6UwLhVBFfSNvBQVAdoq6gvr+IE8rCIKTMNGwNcgVPbF+YxP7UZM6p7s2a 5MIqGw7URSfaqfuztibXGOBLFbSwLGqHSSnOXBfEeDrwdZ+ur8cXIIPRIeCTVmeO 8bGgpgBqNQXG9oyGN+TrYAC+4Ahi0UjCk7QGj8tf3xICKoQpYyfceNBZJ/969gV9 tVgvRxUjxUwc9kZbi0c8XYMTq5GCvBIh1D6BOW9QBM2SsNgG3l36+e3+c2LDdyKn 20C1IzGLVDdcCtz42/onQ/e9sMlzFrfLjs5SO2/TnLvp2JtsIQXyb/T5qd0GE5j8 /iwfZR+uVTVVEsUl1a+Yllzt6sdR7RIhhKpKaKzEAk4d0+VHdz7zEkQRRSjbPVoS fy8c/kld9Fi8Buna+ZkKpcwIW+D4XP83pGcl0XUv6AyqwS1LnEt+jv/+PSXskYtU Lzn8Z35iKkSAH/5Nz6GCZk6ORPNv/6+UI92BpUbu/G2tBwK8bPgAg+gJxBx3G7MK W7VRCmM5UrtAK9A3O70VjPyMkHSJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLC LAf/X/9vRTZWtwSXxiBCA54a6hg9IvW0mvPUqgXfvrhtOk0IFucLKrTXK8J/NcmU 6ulxOovVbQ+Bin6gtHeCmSa/W523g/NXCOuFTnS/MyVibNL4+RCFwqGysl++Cm+L nj1MmasE9kO+CNdervx8APfxV7D6OYrG4eGag+LdFR6VpJn6tRT0/WvyT8l+Oqiq gdhXHv+0MvkkD9TX5LlJW4VB/yRvWkkmL5N5c5zYh+NcfTPhQ5S9dOorVzrm65d6 Itn0937Ennau7s7fiFdA0BHjWqEAFLsBIXQfCFjjKjdsKA4xlSiX7X7ElmPYpWa5 wwTQ66dL0anMd9y1DJCMOHe4gYkCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9 g1MSBQJbtyScAAoJEBDvedn9g1MSY7sP+gKR0rFU1g+GtB+hSdtwPRbacvml2eL2 Jc5Eq37J9hAqxHyt5V0If7s8IyVA2GXgdfwULBWbXGDUDiUkh20OPQRUS8G9Sf8A WRuG25q5C8ZzWygykL88RKXJZDFtA49CeqO5Bq5syBhq4QfiSTffQHIp3h0boPGU hSBEUQpooMXYQClNARQ+z/uRzR5bUi9wxdXNnxTn9ia4ASlaBPvUYTGY1jW2HrRR SwpI12+UaWsvc3jJtQ8X0kxgJ7jsFF1uqquIZ5eflQv+PHHg2RJSy37u0UFGb+OK ZEkzlmbPokKCYhzBR5PcD6sgdlaJNcidmto9u1oV6yZT8J2W4CTuUclgxt6f3lZq ZeVLnNnbHyKUdeypwLlqYISulfnMhZ3A6Bgpf2BtjL6KJbFtPBYmYdxI+HZyY49u U2ZHhRu+CSQ1y7zGKSX0gRp5hE7+A4XJtsT6lTLhbi9aiZTG1S6zKNhl3qNNzszc r27PrvFiyGhpuYQuzdQl2PMGbOI6Ojif3sab53NO3RLsLOM09wIlr95yKLlkXkUr WcvUJGrw6HKm8j5opXHTwmJOAbDpc6cMDu+ITRu4spdCnQJcE8RkO8tKyaLuh2Gt U5kYSBK97yr5VviX1FK6rY14LLmnE16OPiK2tiVBKy9nGM0DKtY+K9WcoRZ7s/d7 O0bMfzcNPtGLuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiez GPuBHmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9Wf pHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC 6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2 D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFe A7PbTuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ /Vf3vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbpt PEcmoazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKr em5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96 Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYgh x8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQ oqj1gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P /1tF6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8 Wpfdn3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJ gx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5 SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2 oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIA ypqYo3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoM eDQkd0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS /qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZ IMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XO KVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DJ121 -----END PGP PUBLIC KEY BLOCK----- --------------C6E615408A45351CAA8FBF72-- --dEODZyL9qsVMmKnRC5HyvMkgqYYwa5knn-- --i6JMLsfjxe9XVv7OwNEAv2lf2tD4MzHP5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlx3P60ACgkQWrL68XsX K+ohSA//YvYmLe2J8kAbvCIpdtNwoU+U8pQT/XEujVhAM7tr+HsMWVV7xOM2KdG5 wOUXCcERXLlEmXE/GI5YpIelLwjuzm2n+4ftcnp6oRNt0y/VfOVwOoeOAvsKaaBh Fy7LjFNaB1okoGcAvRp7gg5XDq+JWJmIJAIXqtN9qJQmwdYiAJgYWy2uXHwPxiol RFRBBAcOURPUIPorRHjDjsei6zDblddJyZHYztghCO4RAg7c4gBZp8L20C7piRvE /K0lat82VSrlJq/JVVG+NA0AYXk2MXrcZWgmPU9zz8bz2uI32EMj3X5wa8zcdLuD 7Luz9fZo1C2qQEhVHsgInruNDmkUTDwuGtByEFNR7ej3Y+X0oah5oSgUR0ry1Xrb y3ZOC8vliYRWTJ1pP1UABCvBZlBAeHXU+HiOkPLAcnwLgmZx79xKzEv4wrptHfyw NOKVbZenIdyDpLNRg3bRzXEWAkpdB4zOf+VQ/0SRp/GH3VpGLe0N3supTyPy3usP 3fFycxQm0Xs8F+kqdbcUxfAeMHcScVEOo888yIeAGi9nBPJdEZle046C26XYCNvG atmIIhMRHz93+hwM6nPM8KzemUbeeA0CbDRXnWORwTb46XPP1TATdJdL2WXXqWIl S7uVoDgqEa9LP564BVfcDKqI6JLD5cuazZIAaGjRw/hWS7o1Z04= =4+KO -----END PGP SIGNATURE----- --i6JMLsfjxe9XVv7OwNEAv2lf2tD4MzHP5-- From nobody Wed Feb 27 18:41: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 A5A1E130ECF for ; Wed, 27 Feb 2019 18:41:05 -0800 (PST) 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3L34L2OkW3k for ; Wed, 27 Feb 2019 18:41:03 -0800 (PST) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D2D9130EE3 for ; Wed, 27 Feb 2019 18:41:03 -0800 (PST) Received: by mail-lj1-x234.google.com with SMTP id j19so15745236ljg.5 for ; Wed, 27 Feb 2019 18:41:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jr5xvyV532nWbPVEiMOQnSIvpPAh9ZyLkqW+ZGKTJxk=; b=vdbXBmRDZGyta2wbdr4XFqL61FCPpYdYF4ENoKOzRX7avrMi/Zpc7c/e/ouDJ32aJq RjMPeGq7wfla6QBKPW6w5TH4eyzkQOPyOHn1JAxqDy/1/EJAAIGaSqxVdIWlcBcK9jr0 VPD3WRQ9Dg+Ny4n+8FB2s5YwD+K3RH1rxXH8pmL878KxV1Vt8jEbBIuvuoP/4FKAAhtk kl+ReQBh/8rfdgQl6DIGPw+aeOUBfl5yu9LZlt2bkjMTpZnEqxBgi/quKvBoNNlWf0Vx CsaTUg1PNHV/9pdxgOC91oUV4VmWuFE6FoWXH2oxVjBj3Pr/53jvz3OKVju2lzk283i5 XZsQ== 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=jr5xvyV532nWbPVEiMOQnSIvpPAh9ZyLkqW+ZGKTJxk=; b=RXcZQB3ZJuopN13mSjSHQbx+CzmEDYH4VDcrbVDmd2UFZXgiQskp50Io78CJqlNr/Q 0P2xVBM/Cvz3MRLTtWvoQANIX3JWcGPEIjUnXt72O4EKNjJNeIyav4bVHizZZ+GJsOOy X6WKGfQEm1H1Oo1J+xPVkhjm6lhqKZJ50JW7xbP0qYVEC2k6Q2a+cFVLgy+GcUbYuCLE yHMoBO2EJydDFesT94as9omNTMA3VwQuZEeaX5jaNViRZSbxf7oXcG46ABd67tchW/xx lwuKBAJ3L8+I3f1A3mFwzkZn3Bm5Q5ZJ5l+/QXto7F8FmH5RuAJdw+prIBVXKH4oWYAH SYAg== X-Gm-Message-State: AHQUAuYcGCt2iKBbrtzD0+Xb46vbo3GFWbzzsh4aHDcKanzu6fNvoqK8 gxiiRyHD7HWs6Hl1bJfe11nl4CcNkOoFZx4aU7cc7A== X-Google-Smtp-Source: AHgI3IbaO2TiTftScLBspkYMuzTQdl7HpUSUpV7GL+vUKLR52qggkEV6qyTJUXvrGaPrUoxCBGgZg5XS5iO9CbrXYWE= X-Received: by 2002:a2e:7202:: with SMTP id n2mr3112112ljc.28.1551321661249; Wed, 27 Feb 2019 18:41:01 -0800 (PST) MIME-Version: 1.0 References: <0b19d021-8101-23ee-2899-450d103a8906@cs.tcd.ie> <0b854704-8f93-f9ad-c067-67f7f73cbbbf@cs.tcd.ie> In-Reply-To: <0b854704-8f93-f9ad-c067-67f7f73cbbbf@cs.tcd.ie> From: Eric Rescorla Date: Wed, 27 Feb 2019 18:40:23 -0800 Message-ID: To: Stephen Farrell Cc: Christopher Wood , "" Content-Type: multipart/alternative; boundary="0000000000008d32720582eb38e5" Archived-At: Subject: Re: [TLS] Two Multi-CDN proposals 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, 28 Feb 2019 02:41:06 -0000 --0000000000008d32720582eb38e5 Content-Type: text/plain; charset="UTF-8" On Wed, Feb 27, 2019 at 5:56 PM Stephen Farrell wrote: > > Hiya, > > On 28/02/2019 01:41, Eric Rescorla wrote: > > I think you're misunderstanding the scenario here: we have two CDNs A and > > B, and some switching service in front, so that when you lookup > example.com, > > you get a CNAME to A or B, and then you get the ESNIKeySet > > (ESNIKeySet is a type you've just invented I guess?) > No. I forgot it was named ESNIKeys > > for A or B as > > the case may be. So you're not going to get both ESNIKeys values. > > Yes, that's not the model I had in mind. I don't recall that having > been written down but maybe I missed it. (Where should I look?) > I believe this was discussed in Bangkok during the discussion of problems with the current structure. > The model I had in mind was where the hidden site has it's own DNS > operator but >1 CDN/front-site with each of those having a private > ESNI value. (And if there's some front-end DNS cleverness, it'd > kick in when the CNAME from #137 is being chased down.) > I don't see how this is conflicts with what I said above, as that server still needs to ensure consistency. In any case, the model I am describing has a consistency problem which needs to be addressed. > PS: I nonetheless maintain my points about the current ESNIKeys > structure - it's over generic and over complex and these PRs can > only make that worse:-) > Yes, I am aware this is your opinion, but I don't agree. -Ekr --0000000000008d32720582eb38e5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Feb 27, 2019 at 5:56 PM Steph= en Farrell <stephen.farrell= @cs.tcd.ie> wrote:

Hiya,

On 28/02/2019 01:41, Eric Rescorla wrote:
> I think you're misunderstanding the scenario here: we have two CDN= s A and
> B, and some switching service in front, so that when you lookup example.com,
> you get a CNAME to A or B, and then you get the ESNIKeySet

(ESNIKeySet is a type you've just invented I guess?)

<= div>
> for A or B as
> the case may be. So you're not going to get both ESNIKeys values.<= br>
Yes, that's not the model I had in mind. I don't recall that having=
been written down but maybe I missed it. (Where should I look?)

I believe this was discussed in Bangkok during the= discussion of problems with the current structure.


=C2=A0
The model I had in mind was where the hidden site has it's own DNS
operator but >1 CDN/front-site with each of those having a private
ESNI value. (And if there's some front-end DNS cleverness, it'd
kick in when the CNAME from #137 is being chased down.)

I don't see how this is conflicts with what I said above, a= s that server still needs to ensure consistency. In any case, the model I a= m describing has a consistency problem which needs to be addressed.


=C2=A0
PS: I nonetheless maintain my points about the current ESNIKeys
structure - it's over generic and over complex and these PRs can
only make that worse:-)

Yes, I am aware= this is your opinion, but I don't agree.

= -Ekr


--0000000000008d32720582eb38e5-- From nobody Wed Feb 27 22:21: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 0485E130DEC for ; Wed, 27 Feb 2019 22:21:14 -0800 (PST) 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 Xl9_vvsQdOCV for ; Wed, 27 Feb 2019 22:21:12 -0800 (PST) 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 46192129508 for ; Wed, 27 Feb 2019 22:21:12 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id CEED9B81D2D; Wed, 27 Feb 2019 22:20:51 -0800 (PST) To: martin.thomson@gmail.com, kaduk@mit.edu, ekr@rtfm.com, christopherwood07@gmail.com, joe@salowey.net, sean+ietf@sn3rd.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: Mai_Anthony@hotmail.com, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20190228062051.CEED9B81D2D@rfc-editor.org> Date: Wed, 27 Feb 2019 22:20:51 -0800 (PST) Archived-At: Subject: [TLS] [Technical Errata Reported] RFC8448 (5645) 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, 28 Feb 2019 06:21:14 -0000 The following errata report has been submitted for RFC8448, "Example Handshake Traces for TLS 1.3". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5645 -------------------------------------- Type: Technical Reported by: Anthony Mai Section: 2 Original Text ------------- Ephemeral private keys are shown as they are generated in the traces. Corrected Text -------------- Ephemeral private keys are shown as they are generated in the traces. Note that X25519 private keys are trimmed in accordance to [RFC 7748] Section 5, before use. This is done by clearing bit 0 to 2 of the first byte and bit 7 of the last byte. And then set bit 6 of the last byte. Notes ----- On page 3,5,16,20,29,43,44,55,57, there are ten X25519 ephemeral private keys listed. None of these private key value, when used directly in X25519 calculation, will yield the associated public key listed. These private key values are not the actual values used. Instead up to 5 bits are modified as recommended by RFC 7748 section 5. Some implementations may choose NOT to do such trimming, and it does not affect the connectivity, as the private keys are never sent over the wire and does not affect network behavior. Not clarifying how the X25519 private keys were modified before using could cause serious confusion. I personally struggled for a day before figuring out this little obscure detail. 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. -------------------------------------- RFC8448 (draft-ietf-tls-tls13-vectors-07) -------------------------------------- Title : Example Handshake Traces for TLS 1.3 Publication Date : January 2019 Author(s) : M. Thomson Category : INFORMATIONAL Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Wed Feb 27 23:34: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 2ECB112D84D for ; Wed, 27 Feb 2019 23:34:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 3JLzJBgkSGhU for ; Wed, 27 Feb 2019 23:34:53 -0800 (PST) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 479BD129AA0 for ; Wed, 27 Feb 2019 23:34:53 -0800 (PST) Received: by mail-lf1-x136.google.com with SMTP id r123so6087836lff.6 for ; Wed, 27 Feb 2019 23:34:52 -0800 (PST) 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=K3UFDXJGH+BCbjM+o53pfnG6rnTWDhiOHzPUMHFFaU0=; b=ZLjLF2PDmyA8+KzraAL/yfaxhEkXvzPqy+cmhP/tTYaaIaZ3FRiLV/BuCHXDLrFDSb mB8Oetsm8lVx3pf5hMV8y/TmnIbShMCvgyaPNSnHJairZRLgvMj3lhPpn6ZT6RxnBXSh 9khOjjCsQiUTl9WpgwN2tFtzAI3GvwouYg1ddc9FHUv/gYvePY3QNGVnntf98bA0w/8r 8nGmdALQD/j7P5/yHkWQiWGgx2jhnOL2z8csaJYheZO+WiL4EfgVZECEGSIqnZcJv5Tg jFpOwjE80rWJPeKhgQ3bkVsKmR9uUO7DDOKzHTBkClCOR/mZpck6R7tsPYuCpahwHWki IpoQ== 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=K3UFDXJGH+BCbjM+o53pfnG6rnTWDhiOHzPUMHFFaU0=; b=jc6BCOr56xhKZ4GjASVOyH3oWtkx03mmCLCoP4TubvAxaflmcdvGLgpDwqhFijdgzO 4iXBYIpi10CmN0u3NW/TFcv/DBFqNCkRwiNNxv8AinU/22TPKBXn+GgJyGU7q5jzQLg3 ieUZvZ4HLd1FYRFlXyCaNluJbP2Rv469c7xFD4wuDoaNsllWkVgjpgpNi3VCMrKDq5Vw lwxoSwsuPTh5jqTi6eOojdMOHRwuw5HAZZaWz38YFxVIYGJEmdhBvYFQwXgreqT84OJF YB9CT+0Wh71iZBCG0wmzahDKpl44b0VX2dnUsQCMfj7+oo3Q10xqFHyCJVM4X7Y0Z6X5 TrGQ== X-Gm-Message-State: AHQUAubgiaKmvTFuD73Yx5DIPxROTNlwFk0daHTZJdZK+y3qlxjIiCO9 iwMp91gvTwkj5gz+Z9ahPDmUoIUQINQiqSVV8uE= X-Google-Smtp-Source: AHgI3IbBIbncPvsVMFUjPQ0AF3zsdBwTrr4F409wTRCJEizcfhLyeIRlOtgHF4Cff2s0r15s62rhsmQoI8+Yrk+jkGM= X-Received: by 2002:ac2:42d7:: with SMTP id n23mr3275424lfl.162.1551339291136; Wed, 27 Feb 2019 23:34:51 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Kazuho Oku Date: Wed, 27 Feb 2019 23:34:39 -0800 Message-ID: To: Christopher Wood Cc: "" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Two Multi-CDN proposals 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, 28 Feb 2019 07:34:56 -0000 Hi Chris, Thank you for writing down the PRs describing possible designs that we might adopt. I think it helps a lot in understanding the details and making accurate comparisons. My comments inline. 2019=E5=B9=B42=E6=9C=8827=E6=97=A5(=E6=B0=B4) 8:19 Christopher Wood : > > Hi folks, > > Below are two PRs that seek to address the multi-CDN issue discussed > on this list and in meetings: > > 1. https://github.com/tlswg/draft-ietf-tls-esni/pull/136 > 2. https://github.com/tlswg/draft-ietf-tls-esni/pull/137 > > #136 implements the combined or stapled record approach discussed > several times, most recently in [1]. It includes these via an ESNIKeys > extension. Reading the PR, I think that there is a mild privacy concern. The issue with the unified record proposal is that it incentivizes the operators to create more ESNI records possibly using different keys, which is against the design principle of ESNI: provide anonymity set by using the least number of keys. Retaining address resolution unbundled with ESNI incentivizes the operator to use less number of keys; for example they might just use one key at a time. That would be a nice property to have, especially in terms of transparency. It would help third parties verify that an operator is actually providing an anonymity set (rather than just pretending to use ESNI). Also, I would like to point out that it is only when one key is used by each of the provider at a given time that it would be possible to use ESNI from a network that blocks DoH or DoT; a user can write the IP addresses of services he/she wants to access in the hosts file, and supply the ESNI key to the client he/she uses. Such a hack becomes difficult under the unified approach, where operators could synthesize different keys based on various conditions. At the least, if we are to adopt #136, I think we should change the definition of record digest included in the ClientHello extension so that it does not cover the "address_set" extension of the ESNI record. Otherwise, we would be exposing to the wire the fingerprint of the set of IP addresses contained in the DNS response the client received through a secure channel, whereas in the split record approach you only leak the ESNI key being used and the IP address the client has chosen. As much as I like the idea of bundling IP addresses and ESNI key, I am concerned if the requirement to bundle different types of records is a requirement specific to ESNI. If not, I think we should (in the long term) try to create a generic solution, while in the short time we could rely on a more limited mechanism as proposed in #137. > #137 builds on this design with a mechanism that lets > clients detect and recover from A/AAAA and ESNI mismatch (if desired). > It is certainly more complex in several respects. A third variant, > which is not (yet) in PR form, is a simplification of #137 wherein > ESNIKeys addresses are only used as filters, instead of filters *or* > complete addresses. I think using IP address blocks to limit the validity of the ESNI key is a fine approach. I do not oppose to having a name-based filter if it's impossible for certain operators to apply the IP address-based filtering approach. > We are asking for feedback on these PRs, as we would like to merge one > of them for the next draft version. As #136 is simpler and permits > extensibility, that is the current preference. > > Thanks in advance for your feedback. > > Best, > Chris (no hat, on behalf of the authors) > > [1] https://mailarchive.ietf.org/arch/msg/tls/WXrPgaIsIPItDw3IQthmJk9VRlw > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --=20 Kazuho Oku From nobody Thu Feb 28 01:58:48 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F63130E86 for ; Thu, 28 Feb 2019 01:58:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=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=telecom-paristech.fr Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-n_fTIa_Zv9 for ; Thu, 28 Feb 2019 01:58:42 -0800 (PST) Received: from zproxy120.enst.fr (zproxy120.enst.fr [137.194.2.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2D60130E6B for ; Thu, 28 Feb 2019 01:58:41 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by zproxy120.enst.fr (Postfix) with ESMTP id 8A86B80907; Thu, 28 Feb 2019 10:58:40 +0100 (CET) Received: from zproxy120.enst.fr ([IPv6:::1]) by localhost (zproxy120.enst.fr [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id QFjNLpmpEJL1; Thu, 28 Feb 2019 10:58:39 +0100 (CET) Received: from localhost (localhost [IPv6:::1]) by zproxy120.enst.fr (Postfix) with ESMTP id DBD2480C13; Thu, 28 Feb 2019 10:58:38 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.10.3 zproxy120.enst.fr DBD2480C13 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telecom-paristech.fr; s=A6AEC2EE-1106-11E5-B10E-D103FDDA8F2E; t=1551347918; bh=n4jy1I+CtRdDDawJs+YdRQdYGBTK8n6WfjrqY/ztvdw=; h=Date:From:To:Message-ID:MIME-Version; b=zYVTkS/fvFuIcsgMWVFYBAkZiGXM5xjmQ3339SB1H3MJCEDO2485vzltWwnJmrlho 2Lxw5GvFFnk3af1JsSDGTQ57OMifW0X0ItIsJMuDRhejCvaC2KhH+PCbpPWZKexnrc qImgBg3oRxevktDCLv82mWaW/Inz9ggk9djxAa44= X-Virus-Scanned: amavisd-new at zproxy120.enst.fr Received: from zproxy120.enst.fr ([IPv6:::1]) by localhost (zproxy120.enst.fr [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id vV7gRc-XoIvt; Thu, 28 Feb 2019 10:58:38 +0100 (CET) Received: from zmail112.enst.fr (zmail112.enst.fr [137.194.2.205]) by zproxy120.enst.fr (Postfix) with ESMTP id 8871C80804; Thu, 28 Feb 2019 10:58:38 +0100 (CET) Date: Thu, 28 Feb 2019 10:58:38 +0100 (CET) From: Mounira Msahli To: tls@ietf.org Cc: William Whyte Message-ID: <1577207312.20127859.1551347918482.JavaMail.zimbra@enst.fr> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_20127857_78738775.1551347918481" X-Originating-IP: [::ffff:137.194.73.93] X-Mailer: Zimbra 8.8.9_GA_3717 (ZimbraWebClient - FF65 (Win)/8.8.9_GA_3744) Thread-Index: uK8P2jHs+ZpwLWeXeQDFfQSIr4/iFA== Thread-Topic: TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates Archived-At: Subject: [TLS] TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates 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, 28 Feb 2019 09:58:46 -0000 ------=_Part_20127857_78738775.1551347918481 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, Please find attached a new version of the draft "TLS Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates". In the new version, we consider 1609.2 cert signing applicable for TLS 1.3 see section "5. Certificate Verification". In accordance with instructions from the reviewers of IANA, the following entry to the TLS Certificate Types registry were added: Value: 3 Extension Name: 1609Dot2 Recommended: N Reference: [draft-tls-certieee1609] https://www.iana.org/assignments/tls-extensiontype-values We are soliciting feedback from the WG. Kind regards Mounira ------=_Part_20127857_78738775.1551347918481 Content-Type: text/plain; name=draft-msahli-TLS-IEEE1609-03.txt Content-Disposition: attachment; filename=draft-msahli-TLS-IEEE1609-03.txt Content-Transfer-Encoding: base64 CgoKClRMUyBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBNLiBNc2FobGksIEVkLgpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgVGVsZWNvbSBQYXJpc1RlY2gKSW50ZW5kZWQgc3RhdHVzOiBJbmZv cm1hdGlvbmFsICAgICAgICAgICAgICAgICAgICAgICAgUC4gS2FtcGFuYWtpcywgRWQuCkV4cGly ZXM6IEF1Z3VzdCAyMiwgMjAxOSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBDaXNjbwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgSC4gTGFiaW9kLCBFZC4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFRlbGVjb20gUGFyaXNUZWNoCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE4uIENhbS1XaW5nZXQsIEVk LgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgQ2lzY28KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBBLiBTZXJocm91Y2huaSwgRWQuCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUZWxlY29tIFBhcmlzVGVjaAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFcuIFdo eXRlLCBFZC4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBPbmJvYXJkIFNlY3VyaXR5CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBGZWJydWFyeSAxOCwgMjAxOQoKCiBUTFMgQXV0aGVudGlj YXRpb24gdXNpbmcgRVRTSSBUUyAxMDMgMDk3IGFuZCBJRUVFIDE2MDkuMiBjZXJ0aWZpY2F0ZXMK ICAgICAgICAgICAgICAgICAgICBkcmFmdC1tc2FobGktdGxzLWllZWUxNjA5LTAzLnR4dAoKQWJz dHJhY3QKCiAgIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIHRoZSB1c2Ugb2YgYSBuZXcgY2VydGlm aWNhdGUgdHlwZSB0bwogICBhdXRoZW50aWNhdGUgVExTIGVudGl0aWVzLiAgVGhlIGZpcnN0IHR5 cGUgZW5hYmxlcyB0aGUgdXNlIG9mIGEKICAgY2VydGlmaWNhdGUgc3BlY2lmaWVkIGJ5IHRoZSBJ RUVFIGFuZCB0aGUgRXVyb3BlYW4gVGVsZWNvbW11bmljYXRpb25zCiAgIFN0YW5kYXJkcyBJbnN0 aXR1dGUgKEVUU0kpLgoKU3RhdHVzIG9mIFRoaXMgTWVtbwoKICAgVGhpcyBJbnRlcm5ldC1EcmFm dCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZQogICBwcm92aXNpb25z IG9mIEJDUCA3OCBhbmQgQkNQIDc5LgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRv Y3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcKICAgVGFzayBGb3JjZSAoSUVURiku ICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUKICAgd29ya2luZyBk b2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5l dC0KICAgRHJhZnRzIGlzIGF0IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZHJhZnRzL2N1 cnJlbnQvLgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9y IGEgbWF4aW11bSBvZiBzaXggbW9udGhzCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQs IG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55CiAgIHRpbWUuICBJdCBpcyBp bmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlCiAgIG1hdGVy aWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiIKCiAg IFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gQXVndXN0IDIyLCAyMDE5LgoKQ29w eXJpZ2h0IE5vdGljZQoKICAgQ29weXJpZ2h0IChjKSAyMDE5IElFVEYgVHJ1c3QgYW5kIHRoZSBw ZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlCiAgIGRvY3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRz IHJlc2VydmVkLgoKCgoKCk1zYWhsaSwgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAy MiwgMjAxOSAgICAgICAgICAgICAgICBbUGFnZSAxXQoMCkludGVybmV0LURyYWZ0ICAgSUVFRSBh bmQgRVRTSSBDZXJ0aWZpY2F0ZSBUeXBlcyBmb3IgVExTICAgRmVicnVhcnkgMjAxOQoKCiAgIFRo aXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVn YWwKICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50cwogICAoaHR0cHM6Ly90 cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mCiAg IHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRvY3Vt ZW50cwogICBjYXJlZnVsbHksIGFzIHRoZXkgZGVzY3JpYmUgeW91ciByaWdodHMgYW5kIHJlc3Ry aWN0aW9ucyB3aXRoIHJlc3BlY3QKICAgdG8gdGhpcyBkb2N1bWVudC4gIENvZGUgQ29tcG9uZW50 cyBleHRyYWN0ZWQgZnJvbSB0aGlzIGRvY3VtZW50IG11c3QKICAgaW5jbHVkZSBTaW1wbGlmaWVk IEJTRCBMaWNlbnNlIHRleHQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC5lIG9mCiAgIHRoZSBU cnVzdCBMZWdhbCBQcm92aXNpb25zIGFuZCBhcmUgcHJvdmlkZWQgd2l0aG91dCB3YXJyYW50eSBh cwogICBkZXNjcmliZWQgaW4gdGhlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UuCgpUYWJsZSBvZiBD b250ZW50cwoKICAgMS4gIEludHJvZHVjdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gICAyCiAgIDIuICBSZXF1aXJlbWVudHMgVGVybWlub2xvZ3kg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMwogICAzLiAgRXh0ZW5zaW9u IE92ZXJ2aWV3ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDMK ICAgNC4gIFRMUyBDbGllbnQgYW5kIFNlcnZlciBIYW5kc2hha2UgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gICA0CiAgICAgNC4xLiAgQ2xpZW50IEhlbGxvICAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNQogICAgIDQuMi4gIFNlcnZlciBIZWxsbyAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDYKICAgNS4gIENl cnRpZmljYXRlIFZlcmlmaWNhdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gICA3CiAgIDYuICBFeGFtcGxlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICAgNwogICAgIDYuMS4gIFRMUyBTZXJ2ZXIgYW5kIFRMUyBDbGll bnQgdXNlIHRoZSAxNjA5RG90MiBDZXJ0aWZpY2F0ZSAgLiAgIDcKICAgICA2LjIuICBUTFMgQ2xp ZW50IHVzZXMgdGhlIElFRUUgMTYwOS4yIGNlcnRpZmljYXRlIGFuZCBUTFMKICAgICAgICAgICBT ZXJ2ZXIgdXNlcyB0aGUgWCA1MDkgY2VydGlmaWNhdGUgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g ICA4CiAgIDcuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICAgOAogICA4LiAgUHJpdmFjeSBDb25zaWRlcmF0aW9ucyAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDkKICAgOS4gIElBTkEgQ29uc2lkZXJh dGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA5CiAgIDEw LiBBY2tub3dsZWRnZW1lbnRzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAgOQogICAxMS4gUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDkKICAgICAxMS4xLiAgTm9ybWF0aXZlIFJlZmVyZW5j ZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA5CiAgICAgMTEuMi4gIElu Zm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAx MAogICBBdXRob3JzJyBBZGRyZXNzZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgMTAKCjEuICBJbnRyb2R1Y3Rpb24KCiAgIFRoZSBUTFMgcHJvdG9jb2wg W1JGQzg0NDZdIFtSRkM1MjQ2XSB1c2VzIFg1MDkgYW5kIFJhdyBQdWJsaWMgS2V5IGluCiAgIG9y ZGVyIHRvIGF1dGhlbnRpY2F0ZSBzZXJ2ZXJzIGFuZCBjbGllbnRzLiAgVGhpcyBkb2N1bWVudCBk ZXNjcmliZXMKICAgdGhlIHVzZSBvZiB0aGUgY2VydGlmaWNhdGUgc3BlY2lmaWVkIGJ5IHRoZSBJ RUVFIGluIFtJRUVFMTYwOS4yXSBhbmQKICAgcHJvZmlsZWQgYnkgdGhlIEV1cm9wZWFuIFRlbGVj b21tdW5pY2F0aW9ucyBTdGFuZGFyZHMgSW5zdGl0dXRlCiAgIChFVFNJKSBpbiBbVFMxMDMwOTdd LiAgVGhlc2Ugc3RhbmRhcmRzIHNwZWNpZnkgc2VjdXJlIGNvbW11bmljYXRpb25zCiAgIGluIHZl aGljdWxhciBlbnZpcm9ubWVudHMuICBUaGUgY2VydGlmaWNhdGUgdHlwZXMgYXJlIG9wdGltaXpl ZCBmb3IKICAgYmFuZHdpZHRoIGFuZCBwcm9jZXNzaW5nIHRpbWUgdG8gc3VwcG9ydCBkZWxheS1z ZW5zaXRpdmUKICAgYXBwbGljYXRpb25zLCBhbmQgYWxzbyBwcm92aWRlIGJvdGggYXV0aGVudGlj YXRpb24gYW5kIGF1dGhvcml6YXRpb24KICAgaW5mb3JtYXRpb24gdG8gZW5hYmxlIGZhc3QgYWNj ZXNzIGNvbnRyb2wgZGVjaXNpb25zIGluIGFkIGhvYwogICBuZXR3b3JrcyBzdWNoIGFzIGFyZSBm b3VuZCBpbiBJbnRlbGxpZ2VudCBUcmFuc3BvcnRhdGlvbiBTeXN0ZW0KICAgKElUUykuICBUaGUg ZXh0ZW5zaW9uIGlzIGZvbGxvd2luZyB0aGUgW1JGQzYwNjZdLgoKCgoKCgpNc2FobGksIGV0IGFs LiAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjIsIDIwMTkgICAgICAgICAgICAgICAgW1BhZ2Ug Ml0KDApJbnRlcm5ldC1EcmFmdCAgIElFRUUgYW5kIEVUU0kgQ2VydGlmaWNhdGUgVHlwZXMgZm9y IFRMUyAgIEZlYnJ1YXJ5IDIwMTkKCgoyLiAgUmVxdWlyZW1lbnRzIFRlcm1pbm9sb2d5CgogICBU aGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNI QUxMIE5PVCIsCiAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVki LCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzCiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRl ZCBhcyBkZXNjcmliZWQgaW4gW1JGQzIxMTldLgoKMy4gIEV4dGVuc2lvbiBPdmVydmlldwoKICAg VGhpcyBzcGVjaWZpY2F0aW9uIGV4dGVuZHMgdGhlIENsaWVudCBIZWxsbyBhbmQgU2VydmVyIEhl bGxvCiAgIG1lc3NhZ2VzLCBieSB1c2luZyB0aGUgImV4dGVuc2lvbl9kYXRhIiBmaWVsZCBvZiB0 aGUgQ2xpZW50Q2VydFR5cGUKICAgRXh0ZW5zaW9uIGFuZCB0aGUgU2VydmVyQ2VydFR5cGUgRXh0 ZW5zaW9uIHN0cnVjdHVyZXMgZGVmaW5lZCBpbgogICBSRkM3MjUwLiAgSW4gb3JkZXIgdG8gbmVn b3RpYXRlIHRoZSBzdXBwb3J0IG9mIElFRUUgMTYwOS4yIG9yIEVUU0kgVFMKICAgMTAzMDk3IGNl cnRpZmljYXRlLWJhc2VkIGF1dGhlbnRpY2F0aW9uLCB0aGUgY2xpZW50cyBhbmQgdGhlIHNlcnZl cnMKICAgTUFZIGluY2x1ZGUgdGhlIGV4dGVuc2lvbiBvZiB0eXBlICJjbGllbnRfY2VydGlmaWNh dGVfdHlwZSIgYW5kCiAgICJzZXJ2ZXJfY2VydGlmaWNhdGVfdHlwZSIgaW4gdGhlIGV4dGVuZGVk IENsaWVudCBIZWxsbyBhbmQKICAgIkVuY3J5cHRlZEV4dGVuc2lvbnMiLiAgVGhlICJleHRlbnNp b25fZGF0YSIgZmllbGQgb2YgdGhpcyBleHRlbnNpb24KICAgU0hBTEwgY29udGFpbiBhIGxpc3Qg b2Ygc3VwcG9ydGVkIGNlcnRpZmljYXRlIHR5cGVzIHByb3Bvc2VkIGJ5IHRoZQogICBjbGllbnQg YXMgcHJvdmlkZWQgaW4gdGhlIGZpZ3VyZSBiZWxvdzoKCgogICAgIC8qIE1hbmFnZWQgYnkgSUFO QSAqLwogICAgICBlbnVtIHsKICAgICAgICAgIFg1MDkoMCksCiAgICAgICAgICBSYXdQdWJsaWNL ZXkoMiksCiAgICAgICAgICAxNjA5RG90MigzKSwKICAgICAgICAgICgyNTUpCiAgICAgIH0gQ2Vy dGlmaWNhdGVUeXBlOwoKICAgICAgc3RydWN0IHsKICAgICAgICAgIHNlbGVjdCAoY2VydGlmaWNh dGVfdHlwZSkgewoKICAgICAgICAgICAgICAvKiBjZXJ0aWZpY2F0ZSB0eXBlIGRlZmluZWQgaW4g dGhpcyBkb2N1bWVudC4qLwogICAgICAgICAgICAgICBjYXNlIDE2MDlEb3QyOgogICAgICAgICAg ICAgICBvcGFxdWUgY2VydF9kYXRhPDEuLjJeMjQtMT47CgogICAgICAgICAgICAgICAvKiBSYXdQ dWJsaWNLZXkgZGVmaW5lZCBpbiBSRkMgNzI1MCovCiAgICAgICAgICAgICAgY2FzZSBSYXdQdWJs aWNLZXk6CiAgICAgICAgICAgICAgb3BhcXVlIEFTTi4xX3N1YmplY3RQdWJsaWNLZXlJbmZvPDEu LjJeMjQtMT47CgogICAgICAgICAgICAgIC8qIFguNTA5IGNlcnRpZmljYXRlIGRlZmluZWQgaW4g UkZDIDUyNDYqLwogICAgICAgICAgICAgIGNhc2UgWC41MDk6CiAgICAgICAgICAgICAgb3BhcXVl IGNlcnRfZGF0YTwxLi4yXjI0LTE+OwoKICAgICAgICAgICAgICAgfTsKCiAgICAgICAgICAgICBF eHRlbnNpb24gZXh0ZW5zaW9uczwwLi4yXjE2LTE+OwogICAgICAgICB9IENlcnRpZmljYXRlRW50 cnk7CgoKCgpNc2FobGksIGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjIsIDIwMTkg ICAgICAgICAgICAgICAgW1BhZ2UgM10KDApJbnRlcm5ldC1EcmFmdCAgIElFRUUgYW5kIEVUU0kg Q2VydGlmaWNhdGUgVHlwZXMgZm9yIFRMUyAgIEZlYnJ1YXJ5IDIwMTkKCgogICBJbiBjYXNlIHdo ZXJlIHRoZSBUTFMgc2VydmVyIGFjY2VwdHMgdGhlIGRlc2NyaWJlZCBleHRlbnNpb24sIGl0CiAg IHNlbGVjdHMgb25lIG9mIHRoZSBjZXJ0aWZpY2F0ZSB0eXBlcyBpbiB0aGUgZXh0ZW5zaW9uIGRl c2NyaWJlZAogICBhYm92ZS4gIE5vdGUgdGhhdCBhIHNlcnZlciBNQVkgYXV0aGVudGljYXRlIHRo ZSBjbGllbnQgdXNpbmcgb3RoZXIKICAgYXV0aGVudGljYXRpb24gbWV0aG9kcy4gIFRoZSBlbmQt ZW50aXR5IGNlcnRpZmljYXRlJ3MgcHVibGljIGtleSBoYXMKICAgdG8gYmUgY29tcGF0aWJsZSB3 aXRoIG9uZSBvZiB0aGUgY2VydGlmaWNhdGUgdHlwZXMgbGlzdGVkIGluIHRoZQogICBleHRlbnNp b24gZGVzY3JpYmVkIGFib3ZlLgoKNC4gIFRMUyBDbGllbnQgYW5kIFNlcnZlciBIYW5kc2hha2UK CiAgIFRoZSAiY2xpZW50X2NlcnRpZmljYXRlX3R5cGUiIGFuZCAic2VydmVyX2NlcnRpZmljYXRl X3R5cGUiCiAgIGV4dGVuc2lvbnMgTVVTVCBiZSBzZW50IGluIGhhbmRzaGFrZSBwaGFzZSBhcyBp bGx1c3RyYXRlZCBpbiBGaWd1cmUgMQogICBiZWxvdy4gIFRoZSBzYW1lIGV4dGVuc2lvbiBzaGFs bCBiZSBzZW50IGluIFNlcnZlciBIZWxsbyBmb3IgVExTIDEuMi4KCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKTXNhaGxpLCBldCBhbC4gICAgICAgICAgIEV4cGlyZXMgQXVn dXN0IDIyLCAyMDE5ICAgICAgICAgICAgICAgIFtQYWdlIDRdCgwKSW50ZXJuZXQtRHJhZnQgICBJ RUVFIGFuZCBFVFNJIENlcnRpZmljYXRlIFR5cGVzIGZvciBUTFMgICBGZWJydWFyeSAyMDE5CgoK ICAgQ2xpZW50ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFNlcnZl cgoKIEtleSAgXiBDbGllbnRIZWxsbwogRXhjaCB8ICsgc2VydmVyX2NlcnRpZmljYXRlX3R5cGUq CiAgICAgIHwgKyBjbGllbnRfY2VydGlmaWNhdGVfdHlwZSoKICAgICAgfCArIGtleV9zaGFyZSoK ICAgICAgdiArIHNpZ25hdHVyZV9hbGdvcml0aG1zKiAgICAgICAtLS0tLS0tLT4KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU2VydmVySGVsbG8gIF4g S2V5CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKyBr ZXlfc2hhcmUqICB2IEV4Y2gKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB7RW5jcnlwdGVkRXh0ZW5zaW9uc30gIF4gU2VydmVyCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHsrIHNlcnZlcl9jZXJ0aWZpY2F0ZV90eXBlKn18IFBhcmFtcwogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB7KyBjbGllbnRfY2VydGlmaWNhdGVfdHlwZSp9 fAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHtDZXJ0aWZpY2F0ZVJl cXVlc3QqfSAgdgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB7Q2VydGlmaWNhdGUqfSAgXgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB7Q2VydGlmaWNhdGVWZXJpZnkqfSAgfCBBdXRoCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB7RmluaXNoZWR9ICB2CiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgPC0tLS0tLS0gICBbQXBwbGljYXRpb24gRGF0YSpdCiAgICAgIF4g e0NlcnRpZmljYXRlKn0KIEF1dGggfCB7Q2VydGlmaWNhdGVWZXJpZnkqfQogICAgICB2IHtGaW5p c2hlZH0gICAgICAgICAgICAgIC0tLS0tLS0tPgogICAgICAgIFtBcHBsaWNhdGlvbiBEYXRhXSAg ICAgIDwtLS0tLS0tPiAgIFtBcHBsaWNhdGlvbiBEYXRhXQoKICAgICAgICAgICAgICAgKyAgSW5k aWNhdGVzIG5vdGV3b3J0aHkgZXh0ZW5zaW9ucyBzZW50IGluIHRoZQogICAgICAgICAgICAgICAg ICBwcmV2aW91c2x5IG5vdGVkIG1lc3NhZ2UuCgogICAgICAgICAgICAgICAqICBJbmRpY2F0ZXMg b3B0aW9uYWwgb3Igc2l0dWF0aW9uLWRlcGVuZGVudAogICAgICAgICAgICAgICAgICBtZXNzYWdl cy9leHRlbnNpb25zIHRoYXQgYXJlIG5vdCBhbHdheXMgc2VudC4KCiAgICAgICAgICAgICAgIHt9 IEluZGljYXRlcyBtZXNzYWdlcyBwcm90ZWN0ZWQgdXNpbmcga2V5cwogICAgICAgICAgICAgICAg ICBkZXJpdmVkIGZyb20gYSBbc2VuZGVyXV9oYW5kc2hha2VfdHJhZmZpY19zZWNyZXQuCgogICAg ICAgICAgICAgICBbXSBJbmRpY2F0ZXMgbWVzc2FnZXMgcHJvdGVjdGVkIHVzaW5nIGtleXMKICAg ICAgICAgICAgICAgICAgZGVyaXZlZCBmcm9tIFtzZW5kZXJdX2FwcGxpY2F0aW9uX3RyYWZmaWNf c2VjcmV0X04uCgoKCiAgICBGaWd1cmUgMTogTWVzc2FnZSBGbG93IHdpdGggY2VydGlmaWNhdGUg dHlwZSBleHRlbnNpb24gZm9yIEZ1bGwgVExTCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAxLjMgSGFuZHNoYWtlCgo0LjEuICBDbGllbnQgSGVsbG8KCiAgIEluIG9yZGVyIHRvIGluZGlj YXRlIHRoZSBzdXBwb3J0IG9mIElFRUUgMTYwOS4yIG9yIEVUU0kgVFMgMTAzMDk3CiAgIGNlcnRp ZmljYXRlcywgY2xpZW50IE1VU1QgaW5jbHVkZSBhbiBleHRlbnNpb24gb2YgdHlwZQogICAiY2xp ZW50X2NlcnRpZmljYXRlX3R5cGUiIGFuZCAic2VydmVyX2NlcnRpZmljYXRlX3R5cGUiIGluIHRo ZQogICBleHRlbmRlZCBDbGllbnQgSGVsbG8gbWVzc2FnZS4gIFRoZSBIZWxsbyBleHRlbnNpb24g aXMgZGVzY3JpYmVkIGluCiAgIFNlY3Rpb24gNC4xLjIgb2YgVExTIDEuMyBbUkZDODQ0Nl0uCgoK CgoKTXNhaGxpLCBldCBhbC4gICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDIyLCAyMDE5ICAgICAg ICAgICAgICAgIFtQYWdlIDVdCgwKSW50ZXJuZXQtRHJhZnQgICBJRUVFIGFuZCBFVFNJIENlcnRp ZmljYXRlIFR5cGVzIGZvciBUTFMgICBGZWJydWFyeSAyMDE5CgoKICAgVGhlIGV4dGVuc2lvbiAn Y2xpZW50X2NlcnRpZmljYXRlX3R5cGUnIHNlbnQgaW4gdGhlIGNsaWVudCBoZWxsbyBNQVkKICAg Y2FycnkgYSBsaXN0IG9mIHN1cHBvcnRlZCBjZXJ0aWZpY2F0ZSB0eXBlcywgc29ydGVkIGJ5IGNs aWVudAogICBwcmVmZXJlbmNlLiAgSXQgaXMgYSBsaXN0IGluIHRoZSBjYXNlIHdoZXJlIHRoZSBj bGllbnQgc3VwcG9ydHMKICAgbXVsdGlwbGUgY2VydGlmaWNhdGUgdHlwZXMuCgogICBDbGllbnQg TUFZIHJlc3BvbmQgYWxvbmcgd2l0aCBzdXBwb3J0ZWQgY2VydGlmaWNhdGVzIGJ5IHNlbmRpbmcg YQogICAiQ2VydGlmaWNhdGUiIG1lc3NhZ2UgaW1tZWRpYXRlbHkgZm9sbG93ZWQgYnkgdGhlICJD ZXRpZmljYXRlVmVyaWZ5IgogICBtZXNzYWdlLiAgVGhlc2Ugc3BlY2lmaWNhdGlvbnMgYXJlIHZh bGlkIGZvciBUTFMgMS4yIGFuZCBUTFMgMS4zLgoKICAgQWxsIGltcGxlbWVudGF0aW9ucyBTSE9V TEQgYmUgcHJlcGFyZWQgdG8gaGFuZGxlIGV4dHJhbmVvdXMKICAgY2VydGlmaWNhdGVzIGFuZCBh cmJpdHJhcnkgb3JkZXJpbmdzIGZyb20gYW55IFRMUyB2ZXJzaW9uLCB3aXRoIHRoZQogICBleGNl cHRpb24gb2YgdGhlIGVuZC1lbnRpdHkgY2VydGlmaWNhdGUgd2hpY2ggTVVTVCBiZSBmaXJzdC4K CjQuMi4gIFNlcnZlciBIZWxsbwoKICAgV2hlbiB0aGUgc2VydmVyIHJlY2VpdmVzIHRoZSBDbGll bnQgSGVsbG8gY29udGFpbmluZyB0aGUKICAgY2xpZW50X2NlcnRpZmljYXRlX3R5cGUgZXh0ZW5z aW9uIGFuZC9vciB0aGUgc2VydmVyX2NlcnRpZmljYXRlX3R5cGUKICAgZXh0ZW5zaW9uLCB0aGUg Zm9sbG93aW5nIG9wdGlvbnMgYXJlIHBvc3NpYmxlOgoKICAgICAgLSBUaGUgc2VydmVyIHN1cHBv cnRzIHRoZSBleHRlbnNpb24gZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQuCiAgICAgIEl0IHNl bGVjdHMgYSBjZXJ0aWZpY2F0ZSB0eXBlIGZyb20gdGhlIGNsaWVudF9jZXJ0aWZpY2F0ZV90eXBl CiAgICAgIGZpZWxkIGluIHRoZSBleHRlbmRlZCBDbGllbnQgSGVsbG8gYW5kIG11c3QgdGFrZSBp bnRvIGFjY291bnQgdGhlCiAgICAgIGNsaWVudCBhdXRoZW50aWNhdGlvbiBsaXN0IHByaW9yaXR5 LgoKICAgICAgLSBUaGUgc2VydmVyIGRvZXMgbm90IHN1cHBvcnQgdGhlIHByb3Bvc2VkIGNlcnRp ZmljYXRlIHR5cGUgYW5kCiAgICAgIHRlcm1pbmF0ZXMgdGhlIHNlc3Npb24gd2l0aCBhIGZhdGFs IGFsZXJ0IG9mIHR5cGUKICAgICAgInVuc3VwcG9ydGVkX2NlcnRpZmljYXRlIi4KCiAgICAgIC0g VGhlIHNlcnZlciBkb2VzIG5vdCBzdXBwb3J0IHRoZSBleHRlbnNpb24gZGVmaW5lZCBpbiB0aGlz CiAgICAgIGRvY3VtZW50LiAgSW4gdGhpcyBjYXNlLCB0aGUgc2VydmVyIHJldHVybnMgdGhlIHNl cnZlciBoZWxsbwogICAgICB3aXRob3V0IHRoZSBleHRlbnNpb25zIGRlZmluZWQgaW4gdGhpcyBk b2N1bWVudC4KCiAgICAgIC0gVGhlIHNlcnZlciBzdXBwb3J0cyB0aGUgZXh0ZW5zaW9uIGRlZmlu ZWQgaW4gdGhpcyBkb2N1bWVudCwgYnV0CiAgICAgIGl0IGRvZXMgbm90IGhhdmUgYW55IGNlcnRp ZmljYXRlIHR5cGUgaW4gY29tbW9uIHdpdGggdGhlIGNsaWVudC4KICAgICAgVGhlbiwgdGhlIHNl cnZlciB0ZXJtaW5hdGVzIHRoZSBzZXNzaW9uIHdpdGggYSBmYXRhbCBhbGVydCBvZiB0eXBlCiAg ICAgICJ1bnN1cHBvcnRlZF9jZXJ0aWZpY2F0ZSIuCgogICAgICAtIFRoZSBzZXJ2ZXIgc3VwcG9y dHMgdGhlIGV4dGVuc2lvbnMgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50IGFuZAogICAgICBoYXMg YXQgbGVhc3Qgb25lIGNlcnRpZmljYXRlIHR5cGUgaW4gY29tbW9uIHdpdGggdGhlIGNsaWVudC4g IEluCiAgICAgIHRoaXMgY2FzZSwgdGhlIHNlcnZlciBNQVkgaW5jbHVkZSB0aGUgY2xpZW50X2Nl cnRpZmljYXRlX3R5cGUKICAgICAgZXh0ZW5zaW9uIGluIHRoZSBTZXJ2ZXIgSGVsbG8gZm9yIFRM UyAxLjIgb3IgaW4gRW5jcnlwdGVkCiAgICAgIEV4dGVuc2lvbiBmb3IgVExTIDEuMy4gIFRoZW4s IHRoZSBzZXJ2ZXIgcmVxdWVzdHMgYSBjZXJ0aWZpY2F0ZQogICAgICBmcm9tIHRoZSBjbGllbnQg KHZpYSB0aGUgY2VydGlmaWNhdGVfcmVxdWVzdCBtZXNzYWdlKQoKICAgSXQgaXMgd29ydGggdG8g bWVudGlvbiB0aGF0IHRoZSBUTFMgY2xpZW50IG9yIHNlcnZlciBwdWJsaWMga2V5cyBhcmUKICAg b2J0YWluZWQgZnJvbSBhIGNlcnRpZmljYXRlIGNoYWluIGZyb20gYSB3ZWIgcGFnZS4KCgoKCgpN c2FobGksIGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjIsIDIwMTkgICAgICAgICAg ICAgICAgW1BhZ2UgNl0KDApJbnRlcm5ldC1EcmFmdCAgIElFRUUgYW5kIEVUU0kgQ2VydGlmaWNh dGUgVHlwZXMgZm9yIFRMUyAgIEZlYnJ1YXJ5IDIwMTkKCgo1LiAgQ2VydGlmaWNhdGUgVmVyaWZp Y2F0aW9uCgogICBWZXJpZmljYXRpb24gb2YgYW4gSUVFRSAxNjA5LjIvIEVUU0kgVFMgMTAzMDk3 IGNlcnRpZmljYXRlcyBvcgogICBjZXJ0aWZpY2F0ZSBjaGFpbiBpcyBkZXNjcmliZWQgaW4gc2Vj dGlvbiA1LjUuMiBvZiBbSUVFRTE2MDkuMl0uICBJbgogICB0aGUgY2FzZSB3aGVyZSB0aGUgY2Vy dGlmaWNhdGVfdHlwZSBpcyAxNjA5RG90MiwgdGhlCiAgIENlcnRpZmljYXRlVmVyaWZ5IG1lc3Nh Z2UgZG9lcyBub3QgY29udGFpbiBhIHJhdyBzaWduYXR1cmUgYnV0CiAgIGluc3RlYWQgY29udGFp bnMgYSBDYW5vbmljYWwgT2N0ZXQgRW5jb2RpbmcgUnVsZXMgKENPRVIpLWVuY29kZWQKICAgSWVl ZTE2MDlEb3QyRGF0YSBvZiB0eXBlIHNpZ25lZCBhcyBzcGVjaWZpZWQgaW4gWzE2MDkuMmJdLCB3 aXRoIHRoZQogICBwZHVGdW5jdGlvbmFsVHlwZSBmaWVsZCBwcmVzZW50IGFuZCBzZXQgdG8gdGxz SGFuZHNoYWtlLiAgQSBmdWxsCiAgIHNwZWNpZmljYXRpb24gb2YgdGhlIGNvbnRlbnRzIG9mIHRo aXMgSWVlZTE2MDlEb3QyRGF0YSwgaW5jbHVkaW5nCiAgIG9wdGlvbmFsIGZpZWxkcywgaXMgZ2l2 ZW4gaW4gWzE2MDkuMmJdLiAgVGhlIG1lc3NhZ2UgaW5wdXQgdG8gdGhlCiAgIHNpZ25hdHVyZSBj YWxjdWxhdGlvbiBpcyB0aGUgdXN1YWwgbWVzc2FnZSBpbnB1dCBmb3IgVExTIDEuMywgYXMKICAg c3BlY2lmaWVkIGluIFtSRkM4NDQ2XSBzZWN0aW9uIDQuNC4zLCBjb25zaXN0aW5nIG9mIHBhZCwg Y29udGV4dAogICBzdHJpbmcsIHNlcGFyYXRvciBhbmQgY29udGVudCwgd2hlcmUgY29udGVudCBp cyBUcmFuc2NyaXB0LQogICBIYXNoKEhhbmRzaGFrZSBDb250ZXh0LCBDZXJ0aWZpY2F0ZSkuCgo2 LiAgRXhhbXBsZXMKCiAgIFNvbWUgb2YgZXhjaGFuZ2VkIG1lc3NhZ2VzIGV4YW1wbGVzIGFyZSBp bGx1c3RyYXRlZCBpbiBGaWd1cmVzIDIgYW5kCiAgIDMuCgo2LjEuICBUTFMgU2VydmVyIGFuZCBU TFMgQ2xpZW50IHVzZSB0aGUgMTYwOURvdDIgQ2VydGlmaWNhdGUKCiAgIFRoaXMgc2VjdGlvbiBz aG93cyBhbiBleGFtcGxlIHdoZXJlIHRoZSBUTFMgY2xpZW50IGFzIHdlbGwgYXMgdGhlIFRMUwog ICBzZXJ2ZXIgdXNlIHRoZSBJRUVFIDE2MDkuMiBjZXJ0aWZpY2F0ZS4gIEluIGNvbnNlcXVlbmNl LCBib3RoIHRoZQogICBzZXJ2ZXIgYW5kIHRoZSBjbGllbnQgcG9wdWxhdGUgdGhlIGNsaWVudF9j ZXJ0aWZpY2F0ZV90eXBlIGFuZAogICBzZXJ2ZXJfY2VydGlmaWNhdGVfdHlwZSB3aXRoIGV4dGVu c2lvbiBJRUVFIDE2MDkuMiBjZXJ0aWZpY2F0ZXMgYXMKICAgbWVudGlvbmVkIGluIGZpZ3VyZSAy LgoKICAgICAgQ2xpZW50ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IFNlcnZlcgoKICAgQ2xpZW50SGVsbG8sCiAgIGNsaWVudF9jZXJ0aWZpY2F0ZV90eXBlKj0xNjA5 RG90MiwKICAgc2VydmVyX2NlcnRpZmljYXRlX3R5cGUqPTE2MDlEb3QyLCAgIC0tLS0tLS0tPiAg ICAgU2VydmVySGVsbG8sCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHtFbmNyeXB0ZWRFeHRlbnNpb25zfQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg e2NsaWVudF9jZXJ0aWZpY2F0ZV90eXBlKj0xNjA5RG90Mn0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHtzZXJ2ZXJfY2VydGlmaWNhdGVfdHlwZSo9MTYwOURvdDJ9CiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHtDZXJ0aWZpY2F0ZVJlcXVlc3QqfQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAge0NlcnRp ZmljYXRlKn0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHtD ZXJ0aWZpY2F0ZVZlcmlmeSp9CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAge0ZpbmlzaGVkfQogICAgIHtDZXJ0aWZpY2F0ZSp9ICAgICAgICAg ICA8LS0tLS0tLSAgICAgICAgIFtBcHBsaWNhdGlvbiBEYXRhKl0KICAgICB7Q2VydGlmaWNhdGVW ZXJpZnkqfQogICAgIHtGaW5pc2hlZH0gICAgICAgICAgICAgIC0tLS0tLS0tPgogICAgIFtBcHBs aWNhdGlvbiBEYXRhXSAgICAgIDwtLS0tLS0tPiAgICAgICAgICBbQXBwbGljYXRpb24gRGF0YV0K CgogICAgRmlndXJlIDI6IFRMUyBDbGllbnQgYW5kIFRMUyBTZXJ2ZXIgdXNlIHRoZSBJRUVFIDE2 MDkuMiBjZXJ0aWZpY2F0ZQoKCgpNc2FobGksIGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBBdWd1 c3QgMjIsIDIwMTkgICAgICAgICAgICAgICAgW1BhZ2UgN10KDApJbnRlcm5ldC1EcmFmdCAgIElF RUUgYW5kIEVUU0kgQ2VydGlmaWNhdGUgVHlwZXMgZm9yIFRMUyAgIEZlYnJ1YXJ5IDIwMTkKCgo2 LjIuICBUTFMgQ2xpZW50IHVzZXMgdGhlIElFRUUgMTYwOS4yIGNlcnRpZmljYXRlIGFuZCBUTFMg U2VydmVyIHVzZXMKICAgICAgdGhlIFggNTA5IGNlcnRpZmljYXRlCgogICBUaGlzIGV4YW1wbGUg c2hvd3MgdGhlIFRMUyBhdXRoZW50aWNhdGlvbiwgd2hlcmUgdGhlIFRMUyBDbGllbnQKICAgcG9w dWxhdGVzIHRoZSBzZXJ2ZXJfY2VydGlmaWNhdGVfdHlwZSBleHRlbnNpb24gd2l0aCB0aGUgWDUw OQogICBjZXJ0aWZpY2F0ZSBhbmQgUmF3IFB1YmxpYyBLZXkgdHlwZSBhcyBwcmVzZW50ZWQgaW4g ZmlndXJlIDMuIHRoZQogICBjbGllbnQgaW5kaWNhdGVzIGl0cyBhYmlsaXR5IHRvIHJlY2VpdmUg YW5kIHRvIHZhbGlkYXRlIGFuIFg1MDkKICAgY2VydGlmaWNhdGUgZnJvbSB0aGUgc2VydmVyLiAg VGhlIHNlcnZlciBjaG9vc2VzIHRoZSBYNTA5CiAgIGNlcnRpZmljYXRldG8gbWFrZSBpdHMgYXV0 aGVudGljYXRpb24gd2l0aCB0aGUgQ2xpZW50LgoKICAgICBDbGllbnQgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgU2VydmVyCgogICBDbGllbnRIZWxsbywKICAgY2xp ZW50X2NlcnRpZmljYXRlX3R5cGUqPSgxNjA5RG90MiksCiAgIHNlcnZlcl9jZXJ0aWZpY2F0ZV90 eXBlKj0oMTYwOS45RG90LAogICBYNTA5LFJhd1B1YmxpY0tleSksICAgICAgICAgLS0tLS0tLS0t LS0+ICAgICAgICAgU2VydmVySGVsbG8sCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB7RW5jcnlwdGVkRXh0ZW5zaW9uc30KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB7Y2xpZW50X2NlcnRpZmljYXRlX3R5cGUqPTE2MDlEb3QyfQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB7c2VydmVyX2NlcnRpZmljYXRlX3R5cGUqPVg1MDl9CiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAge0NlcnRpZmljYXRlKn0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB7Q2VydGlmaWNhdGVW ZXJpZnkqfQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB7RmluaXNoZWR9CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8LS0tLS0tLS0t ICAgIFtBcHBsaWNhdGlvbiBEYXRhKl0KICAge0ZpbmlzaGVkfSAgICAgICAgICAgICAgICAgIC0t LS0tLS0tLT4KICAgW0FwcGxpY2F0aW9uIERhdGFdICAgICAgICAgIDwtLS0tLS0tLT4gICAgIFtB cHBsaWNhdGlvbiBEYXRhXQoKCiAgIEZpZ3VyZSAzOiBUTFMgQ2xpZW50IHVzZXMgdGhlIElFRUUg MTYwOS4yIGNlcnRpZmljYXRlIGFuZCBUTFMgU2VydmVyCiAgICAgICAgICAgICAgICAgICAgICAg IHVzZXMgdGhlIFggNTA5IGNlcnRpZmljYXRlCgo3LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMK CiAgIFRoaXMgc2VjdGlvbiBwcm92aWRlcyBhbiBvdmVydmlldyBvZiB0aGUgYmFzaWMgc2VjdXJp dHkKICAgY29uc2lkZXJhdGlvbnMgd2hpY2ggbmVlZCB0byBiZSB0YWtlbiBpbnRvIGFjY291bnQg YmVmb3JlCiAgIGltcGxlbWVudGluZyB0aGUgbmVjZXNzYXJ5IHNlY3VyaXR5IG1lY2hhbmlzbXMu ICBUaGUgc2VjdXJpdHkKICAgY29uc2lkZXJhdGlvbnMgZGVzY3JpYmVkIHRocm91Z2hvdXQgW1JG Qzg0NDZdIGFuZCBbUkZDNTI0Nl0gYXBwbHkKICAgaGVyZSBhcyB3ZWxsLgoKICAgRm9yIHNlY3Vy aXR5IGNvbnNpZGVyYXRpb25zIGluIGEgdmVoaWN1bGFyIGVudmlyb25tZW50LCB0aGUgbWluaW1h bAogICB1c2Ugb2YgYW55IFRMUyBleHRlbnNpb25zIGlzIHJlY29tbWVuZGVkIHN1Y2ggYXMgOgoK ICAgICAgVGhlICJjbGllbnRfY2VydGlmaWNhdGVfdHlwZSIgW0lBTkEgdmFsdWUgMTldIGV4dGVu c2lvbiB3aG8ncwogICAgICBwdXJwb3NlIHdhcyBwcmV2aW91c2x5IGRlc2NyaWJlZCBpbiBbUkZD NzI1MF0uCgogICAgICBUaGUgInNlcnZlcl9jZXJ0aWZpY2F0ZV90eXBlIiBbSUFOQSB2YWx1ZSAy MF0gZXh0ZW5zaW9uIHdobydzCiAgICAgIHB1cnBvc2Ugd2FzIHByZXZpb3VzbHkgZGVzY3JpYmVk IGluIFtSRkM3MjUwXS4KCgoKCgpNc2FobGksIGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBBdWd1 c3QgMjIsIDIwMTkgICAgICAgICAgICAgICAgW1BhZ2UgOF0KDApJbnRlcm5ldC1EcmFmdCAgIElF RUUgYW5kIEVUU0kgQ2VydGlmaWNhdGUgVHlwZXMgZm9yIFRMUyAgIEZlYnJ1YXJ5IDIwMTkKCgog ICAgICBUaGUgIlNlc3Npb25UaWNrZXQiIFtJQU5BIHZhbHVlIDM1XSBleHRlbnNpb24gZm9yIHNl c3Npb24KICAgICAgcmVzdW1wdGlvbi4KCiAgICAgIEluIGFkZGl0aW9uLCBzZXJ2ZXJzIFNIT1VM RCBub3Qgc3VwcG9ydCByZW5lZ290aWF0aW9uIFtSRkM1NzQ2XQogICAgICB3aGljaCBwcmVzZW50 ZWQgTWFuLUluLVRoZS1NaWRkbGUgKE1JVE0pIHR5cGUgYXR0YWNrcyBvdmVyIHRoZQogICAgICBw YXN0IHllYXJzIGZvciBUTFMgMS4yLgoKOC4gIFByaXZhY3kgQ29uc2lkZXJhdGlvbnMKCiAgIEZv ciBwcml2YWN5IGNvbnNpZGVyYXRpb25zIGluIGEgdmVoaWN1bGFyIGVudmlyb25tZW50IHRoZSB1 c2Ugb2YgRUVFCiAgIDE2MDkuMi9FVFNJIFRTIDEwMzA5NyBjZXJ0aWZpY2F0ZSBpcyByZWNvbW1l bmRlZCBmb3IgbWFueSByZWFzb25zOgoKICAgICAgSW4gb3JkZXIgdG8gYWRkcmVzcyB0aGUgcmlz ayBvZiBhIHBlcnNvbmFsIGRhdGEgbGVha2FnZSwgbWVzc2FnZXMKICAgICAgZXhjaGFuZ2VkIGZv ciBWMlYgY29tbXVuaWNhdGlvbnMgYXJlIHNpZ25lZCB1c2luZyBJRUVFIDE2MDkuMi9FVFNJCiAg ICAgIFRTIDEwMzA5NyBwc2V1ZG9ueW0gY2VydGlmaWNhdGVzCgogICAgICBUaGUgcHVycG9zZSBv ZiB0aGVzZSBjZXJ0aWZpY2F0ZXMgaXMgdG8gcHJvdmlkZSBwcml2YWN5IHJlbHlpbmcgb24KICAg ICAgZ2VvZ3JhcGhpY2FsIGFuZC9vciB0ZW1wb3JhbCB2YWxpZGl0eSBjcml0ZXJpYSwgYW5kIG1p bmltaXppbmcgdGhlCiAgICAgIGV4Y2hhbmdlIG9mIHByaXZhdGUgZGF0YQoKOS4gIElBTkEgQ29u c2lkZXJhdGlvbnMKCiAgIEV4aXN0aW5nIElBTkEgcmVmZXJlbmNlcyBoYXZlIG5vdCBiZWVuIHVw ZGF0ZWQgeWV0IHRvIHBvaW50IHRvIHRoaXMKICAgZG9jdW1lbnQuCgoxMC4gIEFja25vd2xlZGdl bWVudHMKCiAgIFRoZSBhdXRob3JzIHdpc2ggdG8gdGhhbmsgRXJpYyBSZXNjb2xhIGFuZCBJbGFy aSBMaXVzdmFhcmEgZm9yIHRoZWlyCiAgIGZlZWRiYWNrIGFuZCBzdWdnZXN0aW9ucyBvbiBpbXBy b3ZpbmcgdGhpcyBkb2N1bWVudC4gIFRoYW5rcyBhcmUgZHVlCiAgIHRvIFNlYW4gVHVybmVyIGZv ciBoaXMgdmFsdWFibGUgYW5kIGRldGFpbGVkIGNvbW1lbnRzLiAgU3BlY2lhbAogICB0aGFua3Mg dG8gTWFpayBTZWV3YWxkIGZvciB0aGVpciBndWlkYW5jZSBhbmQgc3VwcG9ydCBpbiB0aGUgZWFy bHkKICAgc3RhZ2VzIG9mIHRoZSBkcmFmdC4KCjExLiAgUmVmZXJlbmNlcwoKMTEuMS4gIE5vcm1h dGl2ZSBSZWZlcmVuY2VzCgogICBbSUVFRTE2MDkuMl0KICAgICAgICAgICAgICBJRUVFLCAiSUVF RSBTdGFuZGFyZCBmb3IgV2lyZWxlc3MgQWNjZXNzIGluIFZlaGljdWxhcgogICAgICAgICAgICAg IEVudmlyb25tZW50cyAtIFNlY3VyaXR5IFNlcnZpY2VzIGZvciBBcHBsaWNhdGlvbnMgYW5kCiAg ICAgICAgICAgICAgTWFuYWdlbWVudCBNZXNzYWdlcyIsIDIwMTYuCgogICBbSUVFRTE2MDkuMmJd CiAgICAgICAgICAgICAgSUVFRSwgIkRyYWZ0IFN0YW5kYXJkIGZvciBXaXJlbGVzcyBBY2Nlc3Mg aW4gVmVoaWN1bGFyCiAgICAgICAgICAgICAgRW52aXJvbm1lbnRzIFNlY3VyaXR5IFNlcnZpY2Vz IGZvciBBcHBsaWNhdGlvbnMgYW5kIGZvcgogICAgICAgICAgICAgIE1hbmFnZW1lbnQgTWVzc2Fn ZXMiLCAyMDE4LgoKCgoKCk1zYWhsaSwgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAy MiwgMjAxOSAgICAgICAgICAgICAgICBbUGFnZSA5XQoMCkludGVybmV0LURyYWZ0ICAgSUVFRSBh bmQgRVRTSSBDZXJ0aWZpY2F0ZSBUeXBlcyBmb3IgVExTICAgRmVicnVhcnkgMjAxOQoKCiAgIFtS RkMyMTE5XSAgQnJhZG5lciwgUy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGlj YXRlCiAgICAgICAgICAgICAgUmVxdWlyZW1lbnQgTGV2ZWxzIiwgTWFyY2ggMTk5Ny4KCiAgIFtS RkM0NDkyXSAgQmxha2UtV2lsc29uLCBTLiwgQm9seWFyZCwgTi4sIEd1cHRhLCBWLiwgSGF3aywg Qy4sIGFuZCBCLgogICAgICAgICAgICAgIE1vZWxsZXIsICJFbGxpcHRpYyBDdXJ2ZSBDcnlwdG9n cmFwaHkgKEVDQykgQ2lwaGVyIFN1aXRlcwogICAgICAgICAgICAgIGZvciBUcmFuc3BvcnQgTGF5 ZXIgU2VjdXJpdHkgKFRMUykiLCBNYXkgMjAwNi4KCiAgIFtSRkM1MjQ2XSAgRGllcmtzLCBULiBh bmQgRS4gUmVzY29ybGEsICJUaGUgVHJhbnNwb3J0IExheWVyIFNlY3VyaXR5CiAgICAgICAgICAg ICAgKFRMUykgUHJvdG9jb2wgVmVyc2lvbiAxLjIiLCBBdWd1c3QgMjAwOC4KCiAgIFtSRkM1NzQ2 XSAgUmVzY29ybGEsIEUuLCBSYXksIE0uLCBEaXNwZW5zYSwgUy4sIGFuZCBOLiBPc2tvdiwKICAg ICAgICAgICAgICAiVHJhbnNwb3J0IExheWVyIFNlY3VyaXR5IChUTFMpIFJlbmVnb3RpYXRpb24g SW5kaWNhdGlvbgogICAgICAgICAgICAgIEV4dGVuc2lvbiIiLCBGZWJydWFyeSAyMDEwLgoKICAg W1JGQzYwNjZdICBFYXN0bGFrZSwgRC4sICJUcmFuc3BvcnQgTGF5ZXIgU2VjdXJpdHkgKFRMUykg RXh0ZW5zaW9uczoKICAgICAgICAgICAgICBFeHRlbnNpb24gRGVmaW5pdGlvbnMiLCBKYW51YXJ5 IDIwMTEuCgogICBbUkZDNzI1MF0gIFdvdXRlcnMsIFAuLCBUc2Nob2ZlbmlnLCBILiwgV2VpbGVy LCBTLiwgYW5kIFQuICBLaXZpbmVuLAogICAgICAgICAgICAgICJVc2luZyBSYXcgUHVibGljIEtl eXMgaW4gVHJhbnNwb3J0IExheWVyIFNlY3VyaXR5IChUTFMpCiAgICAgICAgICAgICAgYW5kIERh dGFncmFtIFRyYW5zcG9ydCBMYXllciBTZWN1cml0eSAoRFRMUykiLCBKdW5lIDIwMTQuCgogICBb UkZDODQ0Nl0gIFJlc2NvcmxhLCBFLiwgIlRoZSBUcmFuc3BvcnQgTGF5ZXIgU2VjdXJpdHkgKFRM UykgUHJvdG9jb2wKICAgICAgICAgICAgICBWZXJzaW9uIDEuMyIsIEF1Z3VzdCAyMDE4LgoKICAg W1RTMTAzMDk3XQogICAgICAgICAgICAgIEVUU0ksICJFVFNJIFRTIDEwMyAwOTcgdjEuMy4xICgy MDE3LTEwKTogSW50ZWxsaWdlbnQKICAgICAgICAgICAgICBUcmFuc3BvcnQgU3lzdGVtcyAoSVRT KTsgU2VjdXJpdHk7IFNlY3VyaXR5IGhlYWRlciBhbmQKICAgICAgICAgICAgICBjZXJ0aWZpY2F0 ZSBmb3JtYXRzIiwgT2N0b2JlciAyMDE3LgoKMTEuMi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMK CiAgIFtkcmFmdC1zZXJocm91Y2huaS10bHMtY2VydGllZWUxNjA5LTAwXQogICAgICAgICAgICAg IEtBSVNFUiwgQS4sIExBQklPRCwgSC4sIExPTkMsIEIuLCBNU0FITEksIE0uLCBhbmQgQS4KICAg ICAgICAgICAgICBTRVJIUk9VQ0hOSSwgIlRyYW5zcG9ydCBMYXllciBTZWN1cml0eSAoVExTKQog ICAgICAgICAgICAgIEF1dGhlbnRpY2F0aW9uIHVzaW5nIElUUyBFVFNJIGFuZCBJRUVFIGNlcnRp ZmljYXRlcyIsCiAgICAgICAgICAgICAgYXVndXN0IDIwMTcuCgpBdXRob3JzJyBBZGRyZXNzZXMK CiAgIE1vdW5pcmEgTXNhaGxpIChlZGl0b3IpCiAgIFRlbGVjb20gUGFyaXNUZWNoCiAgIEZyYW5j ZQoKICAgRU1haWw6IG1vdW5pcmEubXNhaGxpQHRlbGVjb20tcGFyaXN0ZWNoLmZyCgoKCgoKCgpN c2FobGksIGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjIsIDIwMTkgICAgICAgICAg ICAgICBbUGFnZSAxMF0KDApJbnRlcm5ldC1EcmFmdCAgIElFRUUgYW5kIEVUU0kgQ2VydGlmaWNh dGUgVHlwZXMgZm9yIFRMUyAgIEZlYnJ1YXJ5IDIwMTkKCgogICBQYW5vcyBLYW1wYW5ha2lzIChl ZGl0b3IpCiAgIENpc2NvCiAgIFVTQQoKICAgRU1haWw6IEVNYWlsOiBwa2FtcGFuYUBjaXNjby5j b20KCgogICBIb3VkYSBMYWJpb2QgKGVkaXRvcikKICAgVGVsZWNvbSBQYXJpc1RlY2gKICAgRnJh bmNlCgogICBFTWFpbDogaG91ZGEubGFiaW9kQHRlbGVjb20tcGFyaXN0ZWNoLmZyCgoKICAgTmFu Y3kgQ2FtLVdpbmdldCAoZWRpdG9yKQogICBDaXNjbwogICBVU0EKCiAgIEVNYWlsOiBFTWFpbDog bmNhbXdpbmdAY2lzY28uY29tCgoKICAgQWhtZWQgU2VyaHJvdWNobmkgKGVkaXRvcikKICAgVGVs ZWNvbSBQYXJpc1RlY2gKICAgRnJhbmNlCgogICBFTWFpbDogYWhtZWQuc2VyaHJvdWNobmlAdGVs ZWNvbS1wYXJpc3RlY2guZnIKCgogICBXaWxsaWFtIFdoeXRlIChlZGl0b3IpCiAgIE9uYm9hcmQg U2VjdXJpdHkKICAgVVNBCgogICBFTWFpbDogd3doeXRlQG9uYm9hcmRzZWN1cml0eS5jb20KCgoK CgoKCgoKCgoKCgoKCgoKTXNhaGxpLCBldCBhbC4gICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDIy LCAyMDE5ICAgICAgICAgICAgICAgW1BhZ2UgMTFdCg== ------=_Part_20127857_78738775.1551347918481-- From nobody Thu Feb 28 02:50: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 D890D130EF1 for ; Thu, 28 Feb 2019 02:50:40 -0800 (PST) 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 4rgJLvV_juyb for ; Thu, 28 Feb 2019 02:50:37 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAEF1130F39 for ; Thu, 28 Feb 2019 02:50:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0DCE8BE4D; Thu, 28 Feb 2019 10:50:34 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBEBQ45-0om0; Thu, 28 Feb 2019 10:50:33 +0000 (GMT) Received: from [134.226.36.93] (unknown [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C011DBE39; Thu, 28 Feb 2019 10:50:33 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1551351033; bh=I6H0fx234K45r71g+nXxPXLn3pVB/n6aSbsZW/ULLv8=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=Zpw5U3qDsufeMuhzNyxpwIq9oV+/F7a66KbT2g71OqsOxy4rqI3Ot670hqnxWlJeN lVMCgwwqrlU62o/RRzFR8OU5Olo7jwjjJYEGBhe/q08BUh563DYzhti0nhaAHQOWoJ EJykXWnArp+L8ynSOuYnscvT0+JSt6xihP/CeUU8= To: Eric Rescorla Cc: Christopher Wood , "" References: <0b19d021-8101-23ee-2899-450d103a8906@cs.tcd.ie> <0b854704-8f93-f9ad-c067-67f7f73cbbbf@cs.tcd.ie> 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: <1eaaebf3-6e8a-ae84-0ab3-f977295c0721@cs.tcd.ie> Date: Thu, 28 Feb 2019 10:50:29 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="9AMpm5saHftohk4TqkJgaOa28wHFJwMAb" Archived-At: Subject: Re: [TLS] Two Multi-CDN proposals 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, 28 Feb 2019 10:50:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9AMpm5saHftohk4TqkJgaOa28wHFJwMAb Content-Type: multipart/mixed; boundary="FzJtkoH9gAfQxjs9FCXy44Zi4vaLzFluV"; protected-headers="v1" From: Stephen Farrell To: Eric Rescorla Cc: Christopher Wood , "" Message-ID: <1eaaebf3-6e8a-ae84-0ab3-f977295c0721@cs.tcd.ie> Subject: Re: [TLS] Two Multi-CDN proposals References: <0b19d021-8101-23ee-2899-450d103a8906@cs.tcd.ie> <0b854704-8f93-f9ad-c067-67f7f73cbbbf@cs.tcd.ie> In-Reply-To: --FzJtkoH9gAfQxjs9FCXy44Zi4vaLzFluV Content-Type: multipart/mixed; boundary="------------92887FFFB4D4DBE1EA5130E6" Content-Language: en-GB This is a multi-part message in MIME format. --------------92887FFFB4D4DBE1EA5130E6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 28/02/2019 02:40, Eric Rescorla wrote: > On Wed, Feb 27, 2019 at 5:56 PM Stephen Farrell > wrote: >=20 >> >> Hiya, >> >> On 28/02/2019 01:41, Eric Rescorla wrote: >>> I think you're misunderstanding the scenario here: we have two CDNs A= and >>> B, and some switching service in front, so that when you lookup >> example.com, >>> you get a CNAME to A or B, and then you get the ESNIKeySet >> >> (ESNIKeySet is a type you've just invented I guess?) >> >=20 > No. I forgot it was named ESNIKeys >=20 Phew:-) >>> for A or B as >>> the case may be. So you're not going to get both ESNIKeys values. >> >> Yes, that's not the model I had in mind. I don't recall that having >> been written down but maybe I missed it. (Where should I look?) >> >=20 > I believe this was discussed in Bangkok during the discussion of proble= ms > with the current structure. FWIW, I didn't take from that discussion that we only want that model to be supported, but it may have passed me by if that was stated. >> The model I had in mind was where the hidden site has it's own DNS >> operator but >1 CDN/front-site with each of those having a private >> ESNI value. (And if there's some front-end DNS cleverness, it'd >> kick in when the CNAME from #137 is being chased down.) >> >=20 > I don't see how this is conflicts with what I said above, as that serve= r > still needs to ensure consistency.=20 I don't think mine conflicts with the model you describe, but I do think it has different consequences for how we ought structure the ESNIKeys stuff. To be more specific, say in my model I have example.com and want to see ESNI used for www.example.com and I publish the zone for example.com including ESNIKeys. Now I want browsers to be able to use either cdn1.example or cdn2.example to front for www.example.com where those are independent CDNs. So I need to update my DNS zone periodically whenever one or other CDN changes their ESNI public key share. In my tiny little case doing this for a few domains, I already have a small infrastructure that allows me to do that kind of thing because of the need for regular DNSSEC re-signing. (Mine currently works at a weekly or daily cadence, but doing it hourly would be fine.) I'd like to do that via a simple update to my zone files without having to unpack and re-pack the data structures I get from cdn1 or cdn2. Now sure, I could write a new tool to munge together what I get from the CDNs but that's more work (that could go wrong) and doesn't match my current work flows. And I suspect others may operate similarly. That's what leads me to think that we'd be better off to have multi-valued answers when a browser looks up the RRset at _esni.www.example.com with each separate value matching one ESNI public share (or one CDN, though I'd argue for one share per zone file stanza). I don't think that conflicts with your model where _esni.www.example.com is one or another CNAME at a given moment but it does differ from it. There is however some dependency on #137 to get what I want I guess using the host_pointer to get the privacy benefit of using a CDN. I guess I might need to publish yet another ESNI public share that matches the private available at the A/AAAA of www.example.com as well as those from the CDN even though that may get me less privacy benefit compared to browsers who go to cdn1 or cdn2. (It's possible that I'm reading #137 wrong though, but I read it as supporting the kind of setup I describe here.) > In any case, the model I am describing > has a consistency problem which needs to be addressed. >> PS: I nonetheless maintain my points about the current ESNIKeys >> structure - it's over generic and over complex and these PRs can >> only make that worse:-) >> >=20 > Yes, I am aware this is your opinion, but I don't agree. Fair enough:-) Personally I think that if we support the kind of model above, such simplifications may well naturally fall out of that work but we'll see I guess. For example, I think that'd allow re-structuring the ESNIKeys thing so the host_pointer in #137 no longer needs to be an extension and hence we don't need the concept of mandatory/critical extensions at all. Cheers, S. >=20 > -Ekr >=20 --------------92887FFFB4D4DBE1EA5130E6 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 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5tDJTdGVwaGVuIEZhcnJlbGwgKDIwMTcp IDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJCZQmAAUL CQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1yw aps8HGUNhLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG +48od+Xn7qg6LT7GrHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXk kTFaSGYJj3yIP4R6IgwBYGMzDXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRr pZtXB1XQc23ZZmrlTkl2HaThL6w3YKdiTi1NbuMeOxZqtXcUshII45sANm4HuWNT iRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS3MmGgVS4ZoX8+VaPGpXdQVFy BMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml3OEuIQiP2ehRt/HV LMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi2/Jrsz6M zh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6 TzKjGjruq8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxIkBHAQQAQgABgUCWj1SoAAK CRAvPIc2gF+NovMcCACVZPo1cQa3D+vWaIo0ZyinO/MgtD2gHysoj1T0Qvq05//L ZXmhh578bJANvdl2g/HFhhwl/5HKIfWcyipQhmJklp/dsleKcNnn4B18T75RHY0G +po3ILq7evbiOjUH+xqApti1aCxi1GocsPghaLfsxmtXKMG4Xu7XhDTv66GOrqZf Y7+0ekJjD9Dza1t5NE/JR/VZA4B8PWR8Glb0+8C9rkjD0VZ5ekJdHPDGcJmFh8Z+ q25LDoI8Fgt1uKSowvoVnsQO5MFv/y6bXArtj1uB4hAL4JiOFgHlFdrW0MlFpvYm ziW4K9JHTD8KAfDbrb3e2W97ZDpROuYfE/lTbYOWiQI9BBMBCAAnBQJaPVAyAhsD BQkJlCYABQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEFqy+vF7Fyvq0mkP/ius gsf6Z4/Tu+vHzBbl5i6oKI8ZieH8JfEgXx4ut9t7l3hBGC2r7DpR5A8zLMpEhGIK gFcHagksFkfLEE/FmWDfd1MysQafxBYrHaI27P2tkxfI5JYV6247TV39pQ93kGds tsjIrmh/zEJCVczoofxtz72BDt51H2Z8tN28F/YVHnbaGDwFEEzWKYpze87y/f36 ogcdGO6LDEEEIA6Ee0dGxleuKlLS4UDTt0zjo6L8TyiyPHp9C3+UfnP8837Zp3Fh KstIBd+vWgPdHFg2G5aDIYUvrj9UJBvVgaN/RnkwE+dab2OBSg5jkr141JLQvzdZ 4mOUXn5D9Y6AH6tvj0+ubYMV6j35L1/ZXncuXPVYiylcmDp/6f2WYcT3gx9CPUYA cLMjQV4vX2W8z4uEPyMlIJuGsLf7KhvLL8BQ6zlncT6eONfUUX9UJUCzqI5rqL5c b5jWGHeKvbLWRyQnlq5PXQxJTwYRm71rJTgzejc33LE6Nqg/Q25Dgwwsv+f+7i73 gB5loc80Fef+FV9VFGalFe0Yq8m0UASmkYRh7MH5ssoibpeWk+SGfBjOV4tnsAwR yjYLpAzxA8HeDcmlLeypGEDmsQ/iUvXoGaKOYX4Ieg8T/PCAplsqnJUOq8hbkgOC 98gLZfiltkNG8YhQpoZIHj6SxmBRSc3K99CvanuOiQIzBBABCAAdFiEEfhcKBFyE z0YOK3mgEO952f2DUxIFAlu3JJsACgkQEO952f2DUxJ4qRAAmbjiO3WTAeBCB4ME p2N2+XQCMTTFURDGuJnqU/+X//fhhPRq4V/OxgisKFKlBcAS2hsECvg6HDVSz4Fl 74fk/y+botG4/CjMLdKPB9fgh5zz72i3q0hWDixt50NKBv8IIVWOyYgZxDU/vcks lMEnqbFgJX+CfdALpvAM4WjuQP0UMcKNE3xd+EdDhD1xjK3Tq4XfWob9q6aBZgL2 B4IaADCIeDDE1hv0agnSJmMJE7Bti8tNxCCxVRbZtOaxVHXdRUoOx2XTaxFXupxV hbpHRrdFrwq51f6e3bkfkNEZ3fzYpnlbynJ2zL++JO8P3Pq/S6UKEFjEB50i8YgK WuFvGUsQ+YiDgiZU4saqxSBWbfYn3lY6MSSTg8RnXbFIMG3CFImqYk1uhaV+bDjc p0htjzM2F98g7c3o7sWx0bGarId4uhOmpj7JJVQ+lu7Jby6Ocj8n//7qF1Nn11Cw QlCVaeAq5Y5DmZrnww9I3zzOWWyqFkAVCM3GqeRLMvplD6/+O+5FF7XoHzQB47nk OyZtawy/9gssPWZKLv4qHLYS0wGGCiNbCsYy90s3pfeafM0kSxxjIvEz21KT6LJI /awu2ErQFWCkDMFJ1p/97MjPrQ/6d4cPO140V/wyfuWaBiTVqa9mgnb2zn6fYfDH JEvl1UzIx3JCae25tty1+qtnS0i0LlN0ZXBoZW4gRmFycmVsbCA8c3RlcGhlbkB0 b2xlcmFudG5ldHdvcmtzLmNvbT6JAj0EEwEIACcFAlo9UVoCGwMFCQmUJgAFCwkI BwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+o7HBAAxHAdFkBGZ9gJK8w7 NUYS9C6enGYtAYoKH5G3Bn3YScjErNfQtHYb53KwBQpVSOv1HcN8hbQ8mLTgn9lt zNwNSuv0XxIswi807HRSIZ4vYDiS5VKV1YkLYK5bLY5O4alVdzqM+AZQqkuHBu63 6n+C0ED6UwLhVBFfSNvBQVAdoq6gvr+IE8rCIKTMNGwNcgVPbF+YxP7UZM6p7s2a 5MIqGw7URSfaqfuztibXGOBLFbSwLGqHSSnOXBfEeDrwdZ+ur8cXIIPRIeCTVmeO 8bGgpgBqNQXG9oyGN+TrYAC+4Ahi0UjCk7QGj8tf3xICKoQpYyfceNBZJ/969gV9 tVgvRxUjxUwc9kZbi0c8XYMTq5GCvBIh1D6BOW9QBM2SsNgG3l36+e3+c2LDdyKn 20C1IzGLVDdcCtz42/onQ/e9sMlzFrfLjs5SO2/TnLvp2JtsIQXyb/T5qd0GE5j8 /iwfZR+uVTVVEsUl1a+Yllzt6sdR7RIhhKpKaKzEAk4d0+VHdz7zEkQRRSjbPVoS fy8c/kld9Fi8Buna+ZkKpcwIW+D4XP83pGcl0XUv6AyqwS1LnEt+jv/+PSXskYtU Lzn8Z35iKkSAH/5Nz6GCZk6ORPNv/6+UI92BpUbu/G2tBwK8bPgAg+gJxBx3G7MK W7VRCmM5UrtAK9A3O70VjPyMkHSJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLC LAf/X/9vRTZWtwSXxiBCA54a6hg9IvW0mvPUqgXfvrhtOk0IFucLKrTXK8J/NcmU 6ulxOovVbQ+Bin6gtHeCmSa/W523g/NXCOuFTnS/MyVibNL4+RCFwqGysl++Cm+L nj1MmasE9kO+CNdervx8APfxV7D6OYrG4eGag+LdFR6VpJn6tRT0/WvyT8l+Oqiq gdhXHv+0MvkkD9TX5LlJW4VB/yRvWkkmL5N5c5zYh+NcfTPhQ5S9dOorVzrm65d6 Itn0937Ennau7s7fiFdA0BHjWqEAFLsBIXQfCFjjKjdsKA4xlSiX7X7ElmPYpWa5 wwTQ66dL0anMd9y1DJCMOHe4gYkCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9 g1MSBQJbtyScAAoJEBDvedn9g1MSY7sP+gKR0rFU1g+GtB+hSdtwPRbacvml2eL2 Jc5Eq37J9hAqxHyt5V0If7s8IyVA2GXgdfwULBWbXGDUDiUkh20OPQRUS8G9Sf8A WRuG25q5C8ZzWygykL88RKXJZDFtA49CeqO5Bq5syBhq4QfiSTffQHIp3h0boPGU hSBEUQpooMXYQClNARQ+z/uRzR5bUi9wxdXNnxTn9ia4ASlaBPvUYTGY1jW2HrRR SwpI12+UaWsvc3jJtQ8X0kxgJ7jsFF1uqquIZ5eflQv+PHHg2RJSy37u0UFGb+OK ZEkzlmbPokKCYhzBR5PcD6sgdlaJNcidmto9u1oV6yZT8J2W4CTuUclgxt6f3lZq ZeVLnNnbHyKUdeypwLlqYISulfnMhZ3A6Bgpf2BtjL6KJbFtPBYmYdxI+HZyY49u U2ZHhRu+CSQ1y7zGKSX0gRp5hE7+A4XJtsT6lTLhbi9aiZTG1S6zKNhl3qNNzszc r27PrvFiyGhpuYQuzdQl2PMGbOI6Ojif3sab53NO3RLsLOM09wIlr95yKLlkXkUr WcvUJGrw6HKm8j5opXHTwmJOAbDpc6cMDu+ITRu4spdCnQJcE8RkO8tKyaLuh2Gt U5kYSBK97yr5VviX1FK6rY14LLmnE16OPiK2tiVBKy9nGM0DKtY+K9WcoRZ7s/d7 O0bMfzcNPtGLuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiez GPuBHmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9Wf pHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC 6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2 D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFe A7PbTuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ /Vf3vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbpt PEcmoazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKr em5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96 Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYgh x8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQ oqj1gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P /1tF6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8 Wpfdn3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJ gx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5 SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2 oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIA ypqYo3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoM eDQkd0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS /qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZ IMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XO KVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DJ121 -----END PGP PUBLIC KEY BLOCK----- --------------92887FFFB4D4DBE1EA5130E6-- --FzJtkoH9gAfQxjs9FCXy44Zi4vaLzFluV-- --9AMpm5saHftohk4TqkJgaOa28wHFJwMAb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlx3vPUACgkQWrL68XsX K+rYZxAAnvyDftNKixIGoRBfYMiEUx/c46Fa+7nBkty1vlsmCsucXHaSBtPVctoA 9S3jrVnyw1r8JK0bYXLr32wsxu7MvGCHo+J4+a9wWMtv6V72lTtwmEQEGPBDVGvw DRA9teEu5js6SkeSZeh6pA4pb8exD5aTVVwmJqTFQHJF9D+TxTwgtCwTB9KBqq1r 3NLXff/+Ts0810BuuJyl1NcDMJwJ2+mvg5CJQWEmA3PU8YEjIqbQ7E4FU0aBD46Z c3wyExTuiw8CSZRqdOkm4FOGwcfQbqZ8JJVQeM+2SHencdMkr8vhe8fqLee+5An7 8z2qhbekSIH/3xlh2vAYeLkTNLYETcdSLILugeHasR8UTXNsTz/DYHFFiT1MzDtr QgTUG0FFM60pXh5n0D3n5QnDYb43oLlqgz1iFCghK9qYxAvm36uVikoMePJxke6V J5kC5ujm6TGQIIz9pxUJv4qeEdmz7bEdRf1NOAUzCz/4cFgq9zAhR3sxxwwcCnyI 4JpuovltZjIcrT68snkyvnQBgDSdH6BwRyH2lQk1TlDUzIl8tRVFzAzOZ5Dr7pMy B8BHPymbRTGZ8uHan7P5WJb8ByIxgK2/B8E2OGgXI0V9aKn70Y1186LvQBMNOm74 7jJq4QZe5+DSF5kC8gsbRqCXnGc5U762KkijSjc8QxoYUpkMl40= =hAcy -----END PGP SIGNATURE----- --9AMpm5saHftohk4TqkJgaOa28wHFJwMAb-- From nobody Thu Feb 28 05:13: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 8D06D130E7F for ; Thu, 28 Feb 2019 05:13:19 -0800 (PST) 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCW28a-oRTvM for ; Thu, 28 Feb 2019 05:13:17 -0800 (PST) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E57EA130E27 for ; Thu, 28 Feb 2019 05:13:16 -0800 (PST) Received: by mail-lf1-x132.google.com with SMTP id x206so7188310lff.3 for ; Thu, 28 Feb 2019 05:13:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sRv9mB2WcfYoxhsmkqdkxcnFocTuTUHzfQIJutzRLgU=; b=febC8V/S+i5v+44Nd4Iq9T0ghGKTeKdRy3zd2MIFPrF0HM4StlPqWr7iY9WkmZQbJx ZJaxTC+PfFWaXbi4LUEE6uqfoPe2BqRfbv+fy6FKcfiWB7o/Vxf7gidPpLxiynYEmeVh 0454g80v+XjzqMRqWE8qwweTB363bab6z2qEXJkvV+eu66FxTzqWZx3o6GVm6Sv+ZpOn pSiEX2qHyVnFzrvsVFB2lAhI5sjrcwquaWaWr2Mc6ulpdwx+wN7f9bOGuWP9UrFfjByo P3QawVfaaayIezWgcF5/F8JNisQkk0EdhVa6NFHRCcdG5Nn7ChZwgkXP9X2NjZsEk1eR zYNg== 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=sRv9mB2WcfYoxhsmkqdkxcnFocTuTUHzfQIJutzRLgU=; b=oGFUc4r+EXaKjhkMUoAJirHesWqKwgxTxmxv/7cfsDeCMMHMmK89q8DGitiHN39NpL opVCYOxlf8XDRXF+o4tCCIa7w48eElzPGRmRdl5RMDEpSF7wLxsCg7lqYzTVxTrH3+0D Qt2AReSr288BBEp+UhjD0dlDtjoxTeFeQtQg0t9iQ+s3a7A2ALEjOMeAXpVhOoxcwJeY WKs9+5OnPu+SlrAGh4CbrtIglXS3vW/9IO1lqfjZhRKIpzVJ+F9DodyB9IjIKqYNC+my RKEE00Q94a2hLw1KmzDtIlVuBK2BTo6c1y6ZlCJYF2YKm1PpKt33ZAK8xRuhHmpOyok9 VQ7A== X-Gm-Message-State: AHQUAua9j0XY2vat2gkKIb7eTHS616hJgXoOzmZQk57L8APEwST1DGA6 IU0kUzbLPF7hCGdLqTEyJHdPxbu65Dwxt/9m3kn2lA== X-Google-Smtp-Source: AHgI3IaXuAm/mdBTw5xf5k6OARWK2nSDVtSbwCZAH6HAWpJvtPE9K6i/89vCFB1BwVdhmkOpb4TCwSabTSRubvi9ph4= X-Received: by 2002:ac2:51bc:: with SMTP id f28mr4495089lfk.123.1551359594860; Thu, 28 Feb 2019 05:13:14 -0800 (PST) MIME-Version: 1.0 References: <0b19d021-8101-23ee-2899-450d103a8906@cs.tcd.ie> <0b854704-8f93-f9ad-c067-67f7f73cbbbf@cs.tcd.ie> <1eaaebf3-6e8a-ae84-0ab3-f977295c0721@cs.tcd.ie> In-Reply-To: <1eaaebf3-6e8a-ae84-0ab3-f977295c0721@cs.tcd.ie> From: Eric Rescorla Date: Thu, 28 Feb 2019 05:12:37 -0800 Message-ID: To: Stephen Farrell Cc: Christopher Wood , "" Content-Type: multipart/alternative; boundary="0000000000009229f30582f40db7" Archived-At: Subject: Re: [TLS] Two Multi-CDN proposals 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, 28 Feb 2019 13:13:19 -0000 --0000000000009229f30582f40db7 Content-Type: text/plain; charset="UTF-8" On Thu, Feb 28, 2019 at 2:50 AM Stephen Farrell wrote: > > Hiya, > > On 28/02/2019 02:40, Eric Rescorla wrote: > > On Wed, Feb 27, 2019 at 5:56 PM Stephen Farrell < > stephen.farrell@cs.tcd.ie> > > wrote: > > > >> > >> Hiya, > >> > >> On 28/02/2019 01:41, Eric Rescorla wrote: > >>> I think you're misunderstanding the scenario here: we have two CDNs A > and > >>> B, and some switching service in front, so that when you lookup > >> example.com, > >>> you get a CNAME to A or B, and then you get the ESNIKeySet > >> > >> (ESNIKeySet is a type you've just invented I guess?) > >> > > > > No. I forgot it was named ESNIKeys > > > > Phew:-) > > >>> for A or B as > >>> the case may be. So you're not going to get both ESNIKeys values. > >> > >> Yes, that's not the model I had in mind. I don't recall that having > >> been written down but maybe I missed it. (Where should I look?) > >> > > > > I believe this was discussed in Bangkok during the discussion of problems > > with the current structure. > > FWIW, I didn't take from that discussion that we only want > that model to be supported, but it may have passed me by > if that was stated. > No, it's merely the most challenging. > >> The model I had in mind was where the hidden site has it's own DNS > >> operator but >1 CDN/front-site with each of those having a private > >> ESNI value. (And if there's some front-end DNS cleverness, it'd > >> kick in when the CNAME from #137 is being chased down.) > >> > > > > I don't see how this is conflicts with what I said above, as that server > > still needs to ensure consistency. > > I don't think mine conflicts with the model you describe, > but I do think it has different consequences for how we > ought structure the ESNIKeys stuff. > > To be more specific, say in my model I have example.com > and want to see ESNI used for www.example.com and I > publish the zone for example.com including ESNIKeys. > > Now I want browsers to be able to use either cdn1.example > or cdn2.example to front for www.example.com where those > are independent CDNs. > > So I need to update my DNS zone periodically whenever > one or other CDN changes their ESNI public key share. > In my tiny little case doing this for a few domains, I > already have a small infrastructure that allows me to > do that kind of thing because of the need for regular > DNSSEC re-signing. (Mine currently works at a weekly > or daily cadence, but doing it hourly would be fine.) > > I'd like to do that via a simple update to my zone files > without having to unpack and re-pack the data structures > I get from cdn1 or cdn2. Now sure, I could write a new > tool to munge together what I get from the CDNs but > that's more work (that could go wrong) and doesn't match > my current work flows. And I suspect others may operate > similarly. > The vast majority of people have someone else manage their DNS, so I'm sure some others do, but I doubt many. > That's what leads me to think that we'd be better off > to have multi-valued answers when a browser looks up > the RRset at _esni.www.example.com with each separate > value matching one ESNI public share (or one CDN, > though I'd argue for one share per zone file stanza). > I don't really understand your point, because this *is* the expected design. > >> PS: I nonetheless maintain my points about the current ESNIKeys > >> structure - it's over generic and over complex and these PRs can > >> only make that worse:-) > >> > > > > Yes, I am aware this is your opinion, but I don't agree. > Fair enough:-) Personally I think that if we support > the kind of model above, such simplifications may well > naturally fall out of that work but we'll see I guess. > For example, I think that'd allow re-structuring the > ESNIKeys thing so the host_pointer in #137 no longer > needs to be an extension and hence we don't need the > concept of mandatory/critical extensions at all. > Well, obviously if you bake all the functionality into the record from the start, you won't need extensions, mandatory or otherwise. But I don't think this piece of functionality is well enough understood to tdo that with. -Ekr > Cheers, > S. > > > > > > > -Ekr > > > --0000000000009229f30582f40db7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Feb 28, 2019 at 2:50 AM Steph= en Farrell <stephen.farrell= @cs.tcd.ie> wrote:

Hiya,

On 28/02/2019 02:40, Eric Rescorla wrote:
> On Wed, Feb 27, 2019 at 5:56 PM Stephen Farrell <stephen.farrell@cs.tcd.ie&= gt;
> wrote:
>
>>
>> Hiya,
>>
>> On 28/02/2019 01:41, Eric Rescorla wrote:
>>> I think you're misunderstanding the scenario here: we have= two CDNs A and
>>> B, and some switching service in front, so that when you looku= p
>> example.com,
>>> you get a CNAME to A or B, and then you get the ESNIKeySet
>>
>> (ESNIKeySet is a type you've just invented I guess?)
>>
>
> No. I forgot it was named ESNIKeys
>

Phew:-)

>>> for A or B as
>>> the case may be. So you're not going to get both ESNIKeys = values.
>>
>> Yes, that's not the model I had in mind. I don't recall th= at having
>> been written down but maybe I missed it. (Where should I look?) >>
>
> I believe this was discussed in Bangkok during the discussion of probl= ems
> with the current structure.

FWIW, I didn't take from that discussion that we only want
that model to be supported, but it may have passed me by
if that was stated.

No, it's merely= the most challenging.


=C2=A0
=
>> The model I had in mind was where the hidden site has it's own= DNS
>> operator but >1 CDN/front-site with each of those having a priv= ate
>> ESNI value. (And if there's some front-end DNS cleverness, it&= #39;d
>> kick in when the CNAME from #137 is being chased down.)
>>
>
> I don't see how this is conflicts with what I said above, as that = server
> still needs to ensure consistency.

I don't think mine conflicts with the model you describe,
but I do think it has different consequences for how we
ought structure the ESNIKeys stuff.

To be more specific, say in my model I have example.com
and want to see ESNI used for www.example.com and I
publish the zone for example.com including ESNIKeys.

Now I want browsers to be able to use either cdn1.example
or cdn2.example to front for www.example.com where those
are independent CDNs.

So I need to update my DNS zone periodically whenever
one or other CDN changes their ESNI public key share.
In my tiny little case doing this for a few domains, I
already have a small infrastructure that allows me to
do that kind of thing because of the need for regular
DNSSEC re-signing. (Mine currently works at a weekly
or daily cadence, but doing it hourly would be fine.)

I'd like to do that via a simple update to my zone files
without having to unpack and re-pack the data structures
I get from cdn1 or cdn2. Now sure, I could write a new
tool to munge together what I get from the CDNs but
that's more work (that could go wrong) and doesn't match
my current work flows. And I suspect others may operate
similarly.

The vast majority of people = have someone else manage their DNS, so I'm sure some others do, but I d= oubt many.


That's what leads me to think that we'd be better off
to have multi-valued answers when a browser looks up
the RRset at _esni.www.example.com with each separate
value matching one ESNI public share (or one CDN,
though I'd argue for one share per zone file stanza).
<= div>
I don't really understand your point, because this *= is* the expected design.

=C2=A0
>> PS: I nonetheless maintain my points about the current ESNIKeys >> structure - it's over generic and over complex and these PRs c= an
>> only make that worse:-)
>>
>
> Yes, I am aware this is your opinion, but I don't agree.
Fair enough:-) Personally I think that if we support
the kind of model above, such simplifications may well
naturally fall out of that work but we'll see I guess.
For example, I think that'd allow re-structuring the
ESNIKeys thing so the host_pointer in #137 no longer
needs to be an extension and hence we don't need the
concept of mandatory/critical extensions at all.

<= /div>
Well, obviously if you bake all the functionality into the record= from the start, you won't need extensions, mandatory or otherwise. But= I don't think this piece of functionality is well enough understood to= tdo that with.

-Ekr


Cheers,
S.



>
> -Ekr
>
--0000000000009229f30582f40db7-- From nobody Thu Feb 28 05:40:19 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEF52130E7F for ; Thu, 28 Feb 2019 05:40:17 -0800 (PST) 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIntvI08QTrS for ; Thu, 28 Feb 2019 05:40:15 -0800 (PST) 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 DDB65130E69 for ; Thu, 28 Feb 2019 05:40:14 -0800 (PST) Received: by mail-lj1-x236.google.com with SMTP id d24so16880663ljc.12 for ; Thu, 28 Feb 2019 05:40:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Xmtt83r6sGwr9l8daOfo9oT57SgQQY3O8P1iwPgq+ig=; b=FRwDA3a+V8DxpW/EUAHZn3pPC82qvX6cyCUTdcgwNh0Tf8QgTcZx5ysjgdu9IyQSgk aAWLGdkcq6Z3YOr2ETBag89gIduJT1GXBvxuhP5Y5ZNqEMx4HbqUe+SCvTF4kpV3XphK nb5iPS+KxL5z55g1C4u+vte/YSr4rWL2PVLA1Z1bFDTvlOD9jEB4yNmBc6a4hTe56dsp 8gh+TsT1byOo+yM7Fiy2RRvDDd8ALPpJb3+xzSchCvK+nBXUxgcbUl/JhDqQN0RYSxat ug5mKHRw8K8He94/kCxKrM/6+AuIKGKrkOH29adgzzaOhjYnzg7PTWu8nAGJ7PUGTwS5 SzFg== 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=Xmtt83r6sGwr9l8daOfo9oT57SgQQY3O8P1iwPgq+ig=; b=m84yVrGdM9HW03+2JGGVY4tle84Vg5aret3qLoKWbNPZcqg2FQZPSLBdwHZNJyEtw8 44HXBamqQXRBXKrj/FcBEi9Oijrj386rddCJKv2nLtOU9IpZ0p7ehLuqn3ZU0/AvUm0a vXLJlcixskNYLGj0mPRu3qGq7mUjVCA8prqCR/D9iWGAiKnszqh1LObCEolWmb/3B8u0 c9fuALGnY/41NVETnbU9SMs4Uld5Q2xNoWGGst1Qqc7w8As8YarBE4g4JICPHy86qvLK fIHoAsajh456rL0GY1rqNQqNduGqQqqQbH9zRwD7j+p+3urZaxKI/oIbb+Qi49PCzQ+U 0N1g== X-Gm-Message-State: APjAAAUhIdaEJLDz8jd7DAbcbnfSdd9xQMnpbjVUEVQXH5A4dQmkpOEW 4o1X11KxZ0ittDPvr63XOmlR3ttr0gy+qCY0UdcW2A== X-Google-Smtp-Source: APXvYqxEsJnWUgwQpHurRNvemrq8uGsXyT8cN7vHKIvLyjsc7UINpPKRIXzkiFYef+js2BVoAazTaM2dcODTICOOyCU= X-Received: by 2002:a2e:4d7:: with SMTP id a84mr4720942ljf.86.1551361211663; Thu, 28 Feb 2019 05:40:11 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Thu, 28 Feb 2019 05:39:34 -0800 Message-ID: To: Jack Visoky Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f0a2b80582f46d1c" Archived-At: Subject: Re: [TLS] EXTERNAL: Re: Authentication Only Ciphersuites RFC 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, 28 Feb 2019 13:40:18 -0000 --000000000000f0a2b80582f46d1c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Jack, There's a bunch here to unpack. First, the purpose of the current registry structure was to allow code point registration without forcing the TLS WG to spend time on documents that don't generally meet its goals. This seems like one such document. WRT to your points about the benefits of RFC status: 1. Having this approved through the IETF process vs, just ISE would be beneficial to those wishing to adopt. Why would this be the case? The only reason I can think of is that having it be an IETF document would imply that the IETF thought it was OK. But this is the situation we are trying to avoid with the Not Recommended label. 2. Having this go through the IETF process would get you community review. Again, here, the idea with the new process is that we don't force the TLS WG to do that work. Obviously, individuals should feel free to review this document or not as they please, but I'm not seeing any compelling reason why TLS-WG should take it on. -Ekr On Wed, Feb 27, 2019 at 11:49 AM Jack Visoky wrote: > Hi Eric, > > > > Our goal is to have an RFC published as Informational and with the Not > Recommended status. We felt having this approved through the IETF proces= s > vs just ISE would be beneficial to those wishing to adopt, and getting > community review is also helpful to us and those we represent. > > > > I suppose one question is whether or not we need this to be a WG item or > if we can solicit independent shepherding from a chair or AD to get to th= e > goal of an Information RFC with Not Recommended status. > > > > Also, I apologize if I=E2=80=99ve misunderstood or misstated anything, I= =E2=80=99m new to > the IETF processes so certainly could have made a mistake. > > > > Thanks, > > > > --Jack > > > > *From:* Eric Rescorla > *Sent:* Tuesday, February 26, 2019 5:53 PM > *To:* Jack Visoky > *Cc:* tls@ietf.org > *Subject:* EXTERNAL: Re: [TLS] Authentication Only Ciphersuites RFC > > > > [Use caution with links & attachments] > > > > > > > > On Tue, Feb 26, 2019 at 12:54 PM Jack Visoky > wrote: > > TLS Colleagues, > > If you recall we discussed a draft for authentication only ciphersuites > over email back in August of 2018. We've since made some updates to that > draft. We also have gotten IANA assignments to the authentication only > ciphersuites for TLS 1.3 and have updated the draft to reflect the new > assignments. > > To that extent, as the IoT community is looking to adopt these > ciphersuites, we would like to solicit review of the draft: > > > > > https://tools.ietf.org/html/draft-camwinget-tls-ts13-macciphersuites-02 > > > > and request that it be published as informational draft given that the Io= T > forums are looking to adopt its use and the draft can serve as the guide > for use and interoperability. > > > > It seems to me that there four somewhat distinct questions: > > > > 1. Code points > > 2. Document level (Info, Exp, PS, etc.) > > 3. Recommended status > > 4. WG status > > > > From my perspective, you have code points and you've asked for an > Informational document, but than can only get you Not Recommended, so > what's the value of having this be a WG document? Why can't you submit it > to the ISE or alternately just have people reference the draft? > > > > -Ekr > > > > > > Thanks and Best Regards, > > > > --Jack (and Nancy) > > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --000000000000f0a2b80582f46d1c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Jack,

There's a bunch he= re to unpack.

First, the purpose of the current re= gistry structure was to allow code point registration without forcing the T= LS WG to spend time on documents that don't generally meet its goals. T= his seems like one such document.

WRT to your poin= ts about the benefits of RFC status:

1. Having thi= s approved through the IETF process vs, just ISE would be beneficial to tho= se wishing to adopt. Why would this be the case? The only reason I can thin= k of is that having it be an IETF document would imply that the IETF though= t it was OK. But this is the situation we are trying to avoid with the Not = Recommended label.
2. Having this go through the IETF process= would get you community review. Again, here, the idea with the new process= is that we don't force the TLS WG to do that work.

Obviously, individuals should feel free to review this document or no= t as they please, but I'm not seeing any compelling reason why TLS-WG s= hould take it on.

-Ekr

On Wed, Feb 27, 2019 at 11:49 AM Jack Visoky <jmvisoky@ra.rockwell.com> wrote:

Hi Eric,

=C2=A0

Our goal is to have an RFC published as Informationa= l and with the Not Recommended status.=C2=A0 We felt having this approved t= hrough the IETF process vs just ISE would be beneficial to those wishing to= adopt, and getting community review is also helpful to us and those we represent.=C2=A0

=C2=A0

I suppose one question is whether or not we need thi= s to be a WG item or if we can solicit independent shepherding from a chair= or AD to get to the goal of an Information RFC with Not Recommended status= .=C2=A0

=C2=A0

Also, I apologize if I=E2=80=99ve misunderstood or m= isstated anything, I=E2=80=99m new to the IETF processes so certainly could= have made a mistake.

=C2=A0

Thanks,

=C2=A0

--Jack

=C2=A0

From: Eric Rescorla <ekr@rtfm.com>
Sent: Tuesday, February 26, 2019 5:53 PM
To: Jack Visoky <jmvisoky@ra.rockwell.com>
Cc: tls@ietf.org
Subject: EXTERNAL: Re: [TLS] Authentication Only Ciphersuites RFC=

=C2=A0

[Use caution with links & attachments]=

=C2=A0

=C2=A0

=C2=A0

TLS Colleagues,

If you recall we discussed a draft for= authentication only ciphersuites over email back in August of 2018.=C2=A0 = We've since made some updates to that draft.=C2=A0 We also have gotten = IANA assignments to the authentication only ciphersuites for TLS 1.3 and have updated the draft to reflect the ne= w assignments.

To that extent, as the IoT community i= s looking to adopt these ciphersuites, we would like to solicit review of t= he draft:

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

=C2=A0=C2=A0=C2=A0=C2=A0https://tools.ietf.org/html/draft-camwinget-tls-ts13-maccipher= suites-02

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

and request that it be published as in= formational draft given that the IoT forums are looking to adopt its use an= d the draft can serve as the guide for use and interoperability.<= /u>

=C2=A0

It seems to me that there four somewhat distinct que= stions:

=C2=A0

1. Code points

2. Document level (Info, Exp, PS, etc.)

3. Recommended status

4. WG status

=C2=A0

From my perspective, you have code points and you= 9;ve asked for an Informational document, but than can only get you Not Rec= ommended, so what's the value of having this be a WG document? Why can&= #39;t you submit it to the ISE or alternately just have people reference the draft?

=C2=A0

-Ekr

=C2=A0

=C2=A0

Thanks and Best Regards,

=C2=A0

--Jack (and Nancy)

=C2=A0

=C2=A0

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

--000000000000f0a2b80582f46d1c-- From nobody Thu Feb 28 05:51: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 5BE22130E69 for ; Thu, 28 Feb 2019 05:51:24 -0800 (PST) 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 2gcDsa1RArkU for ; Thu, 28 Feb 2019 05:51:22 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0F0012F295 for ; Thu, 28 Feb 2019 05:51:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C66DBBE39; Thu, 28 Feb 2019 13:51:18 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SwEgbLqhD3j7; Thu, 28 Feb 2019 13:51:18 +0000 (GMT) Received: from [134.226.36.93] (unknown [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8AB79BE24; Thu, 28 Feb 2019 13:51:18 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1551361878; bh=NomTqJDs3eBmxdugSwj7oiN/MsdUI81XokZ60hviGnQ=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=rOuDQqJwey18JYBtZ2zTHltfnHVBFPjC21m4TjuIX3VxRI6gDa6WGexG8wlAFICmm CB/MV2EUp13rGoA+kx9juVz/PgVRKbeuV3LrUckmbXm3dLnz7gYgg0qjhC53bR3PKM RaehZeBKHVMhWN8kjazjlyliEgoCw2XMq7AhV4ms= To: Eric Rescorla Cc: Christopher Wood , "" References: <0b19d021-8101-23ee-2899-450d103a8906@cs.tcd.ie> <0b854704-8f93-f9ad-c067-67f7f73cbbbf@cs.tcd.ie> <1eaaebf3-6e8a-ae84-0ab3-f977295c0721@cs.tcd.ie> 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: <99af33f1-81d0-d918-9746-568d6ad0c1f0@cs.tcd.ie> Date: Thu, 28 Feb 2019 13:51:16 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="di57TmKKRzdHiNYSZ0c3RFNhptf2GcU8o" Archived-At: Subject: Re: [TLS] Two Multi-CDN proposals 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, 28 Feb 2019 13:51:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --di57TmKKRzdHiNYSZ0c3RFNhptf2GcU8o Content-Type: multipart/mixed; boundary="6Af4IQ9MuXylLILlKoaBZPrNvs9MgffWo"; protected-headers="v1" From: Stephen Farrell To: Eric Rescorla Cc: Christopher Wood , "" Message-ID: <99af33f1-81d0-d918-9746-568d6ad0c1f0@cs.tcd.ie> Subject: Re: [TLS] Two Multi-CDN proposals References: <0b19d021-8101-23ee-2899-450d103a8906@cs.tcd.ie> <0b854704-8f93-f9ad-c067-67f7f73cbbbf@cs.tcd.ie> <1eaaebf3-6e8a-ae84-0ab3-f977295c0721@cs.tcd.ie> In-Reply-To: --6Af4IQ9MuXylLILlKoaBZPrNvs9MgffWo Content-Type: multipart/mixed; boundary="------------98910D8D84C081BF6EDC595D" Content-Language: en-GB This is a multi-part message in MIME format. --------------98910D8D84C081BF6EDC595D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 28/02/2019 13:12, Eric Rescorla wrote: >> That's what leads me to think that we'd be better off >> to have multi-valued answers when a browser looks up >> the RRset at _esni.www.example.com with each separate >> value matching one ESNI public share (or one CDN, >> though I'd argue for one share per zone file stanza). >> > I don't really understand your point, because this *is* the expected > design. >=20 Seems one of us is confused then, likely me:-) Lemme try clarify it out this way: $ dig +short txt _esni.cloudflare.com "/wEXMtleACQAHQAgsKfk/Hy67PiJCb68AVrT C5jXkYnJK5UKCHcF4BAojAwAAhMBAQQAAAAAX HPm0AAAAABce8/QAAA=3D" That's one encoded ESNIKeys value accessed just now. The ietf.org domain has two TXT RR values, (actual content elided below for brevity) so I get: $ dig +short txt ietf.org "somegooglestuff" "lotsofspfstuff" What I'd like to see for my earlier example.com case would be like: $ dig +short txt _esni.www.example.com "/wEXMtleACQAHQAgsKfk/Hy67PiJCb68AVrT C5jXkYnJK5UKCHcF4BAojAwAAhMBAQQAAAAAX HPm0AAAAABce8/QAAA=3D" "/wHHBBOoACQAHQAg4YSfjSyJPNr1z3F8KqzB NBnMejim0mJZaPmria3XsicAAhMBAQQAAAAAW 9pQEAAAAABb4jkQAAA=3D" Where the first is supplied to me by cdn1.example and the second is from cdn2.example. And have browsers and other ESNI clients be able to handle that, picking whatever they consider the best of the usable options presented. Are we still on the same page? If so, great! (And assuming we are: I'd subsequently suggest we can simplify ESNIKeys so that it just has one KeyShareEntry per RR value and not a list of those, since multiples for one CDN or many CDNs can be handled already as above. I think making that change, and perhaps other simplifying changes, at the same time as moving from TXT to a new RRTYPE would be a fine thing, but there's no pressing need to make all those changes for the -03 draft or in #137 though, I'd be happy if we're heading there a little later.) Cheers, S. --------------98910D8D84C081BF6EDC595D 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 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5tDJTdGVwaGVuIEZhcnJlbGwgKDIwMTcp IDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJCZQmAAUL CQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1yw aps8HGUNhLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG +48od+Xn7qg6LT7GrHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXk kTFaSGYJj3yIP4R6IgwBYGMzDXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRr pZtXB1XQc23ZZmrlTkl2HaThL6w3YKdiTi1NbuMeOxZqtXcUshII45sANm4HuWNT iRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS3MmGgVS4ZoX8+VaPGpXdQVFy BMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml3OEuIQiP2ehRt/HV LMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi2/Jrsz6M zh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6 TzKjGjruq8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxIkBHAQQAQgABgUCWj1SoAAK CRAvPIc2gF+NovMcCACVZPo1cQa3D+vWaIo0ZyinO/MgtD2gHysoj1T0Qvq05//L ZXmhh578bJANvdl2g/HFhhwl/5HKIfWcyipQhmJklp/dsleKcNnn4B18T75RHY0G +po3ILq7evbiOjUH+xqApti1aCxi1GocsPghaLfsxmtXKMG4Xu7XhDTv66GOrqZf Y7+0ekJjD9Dza1t5NE/JR/VZA4B8PWR8Glb0+8C9rkjD0VZ5ekJdHPDGcJmFh8Z+ q25LDoI8Fgt1uKSowvoVnsQO5MFv/y6bXArtj1uB4hAL4JiOFgHlFdrW0MlFpvYm ziW4K9JHTD8KAfDbrb3e2W97ZDpROuYfE/lTbYOWiQI9BBMBCAAnBQJaPVAyAhsD BQkJlCYABQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEFqy+vF7Fyvq0mkP/ius gsf6Z4/Tu+vHzBbl5i6oKI8ZieH8JfEgXx4ut9t7l3hBGC2r7DpR5A8zLMpEhGIK gFcHagksFkfLEE/FmWDfd1MysQafxBYrHaI27P2tkxfI5JYV6247TV39pQ93kGds tsjIrmh/zEJCVczoofxtz72BDt51H2Z8tN28F/YVHnbaGDwFEEzWKYpze87y/f36 ogcdGO6LDEEEIA6Ee0dGxleuKlLS4UDTt0zjo6L8TyiyPHp9C3+UfnP8837Zp3Fh KstIBd+vWgPdHFg2G5aDIYUvrj9UJBvVgaN/RnkwE+dab2OBSg5jkr141JLQvzdZ 4mOUXn5D9Y6AH6tvj0+ubYMV6j35L1/ZXncuXPVYiylcmDp/6f2WYcT3gx9CPUYA cLMjQV4vX2W8z4uEPyMlIJuGsLf7KhvLL8BQ6zlncT6eONfUUX9UJUCzqI5rqL5c b5jWGHeKvbLWRyQnlq5PXQxJTwYRm71rJTgzejc33LE6Nqg/Q25Dgwwsv+f+7i73 gB5loc80Fef+FV9VFGalFe0Yq8m0UASmkYRh7MH5ssoibpeWk+SGfBjOV4tnsAwR yjYLpAzxA8HeDcmlLeypGEDmsQ/iUvXoGaKOYX4Ieg8T/PCAplsqnJUOq8hbkgOC 98gLZfiltkNG8YhQpoZIHj6SxmBRSc3K99CvanuOiQIzBBABCAAdFiEEfhcKBFyE z0YOK3mgEO952f2DUxIFAlu3JJsACgkQEO952f2DUxJ4qRAAmbjiO3WTAeBCB4ME p2N2+XQCMTTFURDGuJnqU/+X//fhhPRq4V/OxgisKFKlBcAS2hsECvg6HDVSz4Fl 74fk/y+botG4/CjMLdKPB9fgh5zz72i3q0hWDixt50NKBv8IIVWOyYgZxDU/vcks lMEnqbFgJX+CfdALpvAM4WjuQP0UMcKNE3xd+EdDhD1xjK3Tq4XfWob9q6aBZgL2 B4IaADCIeDDE1hv0agnSJmMJE7Bti8tNxCCxVRbZtOaxVHXdRUoOx2XTaxFXupxV hbpHRrdFrwq51f6e3bkfkNEZ3fzYpnlbynJ2zL++JO8P3Pq/S6UKEFjEB50i8YgK WuFvGUsQ+YiDgiZU4saqxSBWbfYn3lY6MSSTg8RnXbFIMG3CFImqYk1uhaV+bDjc p0htjzM2F98g7c3o7sWx0bGarId4uhOmpj7JJVQ+lu7Jby6Ocj8n//7qF1Nn11Cw QlCVaeAq5Y5DmZrnww9I3zzOWWyqFkAVCM3GqeRLMvplD6/+O+5FF7XoHzQB47nk OyZtawy/9gssPWZKLv4qHLYS0wGGCiNbCsYy90s3pfeafM0kSxxjIvEz21KT6LJI /awu2ErQFWCkDMFJ1p/97MjPrQ/6d4cPO140V/wyfuWaBiTVqa9mgnb2zn6fYfDH JEvl1UzIx3JCae25tty1+qtnS0i0LlN0ZXBoZW4gRmFycmVsbCA8c3RlcGhlbkB0 b2xlcmFudG5ldHdvcmtzLmNvbT6JAj0EEwEIACcFAlo9UVoCGwMFCQmUJgAFCwkI BwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+o7HBAAxHAdFkBGZ9gJK8w7 NUYS9C6enGYtAYoKH5G3Bn3YScjErNfQtHYb53KwBQpVSOv1HcN8hbQ8mLTgn9lt zNwNSuv0XxIswi807HRSIZ4vYDiS5VKV1YkLYK5bLY5O4alVdzqM+AZQqkuHBu63 6n+C0ED6UwLhVBFfSNvBQVAdoq6gvr+IE8rCIKTMNGwNcgVPbF+YxP7UZM6p7s2a 5MIqGw7URSfaqfuztibXGOBLFbSwLGqHSSnOXBfEeDrwdZ+ur8cXIIPRIeCTVmeO 8bGgpgBqNQXG9oyGN+TrYAC+4Ahi0UjCk7QGj8tf3xICKoQpYyfceNBZJ/969gV9 tVgvRxUjxUwc9kZbi0c8XYMTq5GCvBIh1D6BOW9QBM2SsNgG3l36+e3+c2LDdyKn 20C1IzGLVDdcCtz42/onQ/e9sMlzFrfLjs5SO2/TnLvp2JtsIQXyb/T5qd0GE5j8 /iwfZR+uVTVVEsUl1a+Yllzt6sdR7RIhhKpKaKzEAk4d0+VHdz7zEkQRRSjbPVoS fy8c/kld9Fi8Buna+ZkKpcwIW+D4XP83pGcl0XUv6AyqwS1LnEt+jv/+PSXskYtU Lzn8Z35iKkSAH/5Nz6GCZk6ORPNv/6+UI92BpUbu/G2tBwK8bPgAg+gJxBx3G7MK W7VRCmM5UrtAK9A3O70VjPyMkHSJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLC LAf/X/9vRTZWtwSXxiBCA54a6hg9IvW0mvPUqgXfvrhtOk0IFucLKrTXK8J/NcmU 6ulxOovVbQ+Bin6gtHeCmSa/W523g/NXCOuFTnS/MyVibNL4+RCFwqGysl++Cm+L nj1MmasE9kO+CNdervx8APfxV7D6OYrG4eGag+LdFR6VpJn6tRT0/WvyT8l+Oqiq gdhXHv+0MvkkD9TX5LlJW4VB/yRvWkkmL5N5c5zYh+NcfTPhQ5S9dOorVzrm65d6 Itn0937Ennau7s7fiFdA0BHjWqEAFLsBIXQfCFjjKjdsKA4xlSiX7X7ElmPYpWa5 wwTQ66dL0anMd9y1DJCMOHe4gYkCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9 g1MSBQJbtyScAAoJEBDvedn9g1MSY7sP+gKR0rFU1g+GtB+hSdtwPRbacvml2eL2 Jc5Eq37J9hAqxHyt5V0If7s8IyVA2GXgdfwULBWbXGDUDiUkh20OPQRUS8G9Sf8A WRuG25q5C8ZzWygykL88RKXJZDFtA49CeqO5Bq5syBhq4QfiSTffQHIp3h0boPGU hSBEUQpooMXYQClNARQ+z/uRzR5bUi9wxdXNnxTn9ia4ASlaBPvUYTGY1jW2HrRR SwpI12+UaWsvc3jJtQ8X0kxgJ7jsFF1uqquIZ5eflQv+PHHg2RJSy37u0UFGb+OK ZEkzlmbPokKCYhzBR5PcD6sgdlaJNcidmto9u1oV6yZT8J2W4CTuUclgxt6f3lZq ZeVLnNnbHyKUdeypwLlqYISulfnMhZ3A6Bgpf2BtjL6KJbFtPBYmYdxI+HZyY49u U2ZHhRu+CSQ1y7zGKSX0gRp5hE7+A4XJtsT6lTLhbi9aiZTG1S6zKNhl3qNNzszc r27PrvFiyGhpuYQuzdQl2PMGbOI6Ojif3sab53NO3RLsLOM09wIlr95yKLlkXkUr WcvUJGrw6HKm8j5opXHTwmJOAbDpc6cMDu+ITRu4spdCnQJcE8RkO8tKyaLuh2Gt U5kYSBK97yr5VviX1FK6rY14LLmnE16OPiK2tiVBKy9nGM0DKtY+K9WcoRZ7s/d7 O0bMfzcNPtGLuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiez GPuBHmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9Wf pHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC 6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2 D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFe A7PbTuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ /Vf3vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbpt PEcmoazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKr em5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96 Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYgh x8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQ oqj1gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P /1tF6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8 Wpfdn3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJ gx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5 SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2 oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIA ypqYo3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoM eDQkd0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS /qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZ IMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XO KVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DJ121 -----END PGP PUBLIC KEY BLOCK----- --------------98910D8D84C081BF6EDC595D-- --6Af4IQ9MuXylLILlKoaBZPrNvs9MgffWo-- --di57TmKKRzdHiNYSZ0c3RFNhptf2GcU8o Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlx351QACgkQWrL68XsX K+ogyxAAv9u5GFVclR8B+y6cDNv/QJcXA+a/b5vDWDN7NgtIMOBEjHSFTK+OsG/4 N0N26zQkCAyiVYlSsC6WemPFWwoZ2EG+q7JKCdur36KltOqOwlPJZ//rhA3ZDmur K/X5HYRk6a82YS25vf2Fv/0aH7Zp2rRY974Q5vNV7P1OeoRN7k8EC3zUQHLr+Efe SAAbo/dvA00As56LgcMay6rXA0num2+issfNxjaqsp1Sgj+5CGnPoBOZjY9VO3uh UuII1rfwTVdY4g1XtcxTwKcvGSZr1gmzbUv/DwEw95tM0m/P6z3YQnkFSnSKeea0 5owWePs3LYM89Qr12xcvQo+hBom2kZ6hFuS26yH3mS7rYXkUpO/4+CNiQ7kBX6VP vxqArNnnj+9ER81tCPEvu3Qa/lNjEhOBy4IBXNNFU9liZU1G9DRX9e9hqFXFpXaw N3yKsuuPPbjtJRmOu1DFQzP/wGRen5kTt7Pbsp0X9Us+GFEWQ9XrqVxH4tx2ha7z vFUApjR/9lPRBEMOIwPpLHNYN3c0v5c0cqiS/WqfQ1ydX628du5fui9bx3g2Zy1P H+32Hfzy6KIRrl3UR7iXJG5wwNWGTeJtlBX0z8lNp7UjpD9IFsIMAQ5/YSDMLv22 jMf7Eqfv5KwBopWGZ/rocqgRl2xyVoLkjA0e9evC8VVG00pgPFs= =ql1v -----END PGP SIGNATURE----- --di57TmKKRzdHiNYSZ0c3RFNhptf2GcU8o-- From nobody Thu Feb 28 05:54: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 CDF4A130E69 for ; Thu, 28 Feb 2019 05:54:23 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UjhnTKgGUz7Y for ; Thu, 28 Feb 2019 05:54:22 -0800 (PST) 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 3E2B112F295 for ; Thu, 28 Feb 2019 05:54:22 -0800 (PST) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x1SDlYd3003272; Thu, 28 Feb 2019 13:54:22 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=sepl1mSBqFN5vtxqQNTes4YlNiIse/1+vW0xayaFwuU=; b=XOmLBOV93o2xq5WRjpCdgh0a83JnqBAGJjS/LfEU4wjWFtYVPAW8ovcGy95rzXcEZ+8M Hq90WrT+k/pm80qgdCa1nHenDMWYamAKlCpPVkxtpNbRnpUiTbIRgOORJSK4chkHK7cb J9TwhxvbaHuT/KXLM2qyRefJZ2BfwDYU2jHlhzOKduLTkCI3l84Y5eUBCyslEg0bN6za bIVKCqHmNY8P7RBQOfUwqFDfi68TPNRYB1Sf8IVJ/gXd+BVyWJWhslJ8LuLIZaJNgAQq emS/UFhXYnRuHfqgCh1UJl7TFpw2Ut/ZxRhJtJM8NAF81kEaK4/yH9YLSrJaYR676w01 2Q== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0a-00190b01.pphosted.com with ESMTP id 2qwb4xf0vf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 28 Feb 2019 13:54:21 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x1SDlWie020900; Thu, 28 Feb 2019 08:54:20 -0500 Received: from email.msg.corp.akamai.com ([172.27.25.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 2qu2d0au55-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 28 Feb 2019 08:54:20 -0500 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.1395.4; Thu, 28 Feb 2019 07:54:19 -0600 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.1395.000; Thu, 28 Feb 2019 07:54:19 -0600 From: "Salz, Rich" To: Eric Rescorla , Jack Visoky CC: "tls@ietf.org" Thread-Topic: [TLS] EXTERNAL: Re: Authentication Only Ciphersuites RFC Thread-Index: AQHUztWeusV1f16w9ki+yhUpn4RxR6X1nP4A//+wS4A= Date: Thu, 28 Feb 2019 13:54:18 +0000 Message-ID: <150E2CBA-14F6-4953-B6CF-241A117E2325@akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.1.190220 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.6] Content-Type: multipart/alternative; boundary="_000_150E2CBA14F64953B6CF241A117E2325akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-28_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902280096 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-28_06:, , 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=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902280096 Archived-At: Subject: Re: [TLS] EXTERNAL: Re: Authentication Only Ciphersuites RFC 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, 28 Feb 2019 13:54:24 -0000 --_000_150E2CBA14F64953B6CF241A117E2325akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgT2J2aW91c2x5LCBpbmRpdmlkdWFscyBzaG91bGQgZmVlbCBmcmVlIHRvIHJldmlldyB0 aGlzIGRvY3VtZW50IG9yIG5vdCBhcyB0aGV5IHBsZWFzZSwgYnV0IEknbSBub3Qgc2VlaW5nIGFu eSBjb21wZWxsaW5nIHJlYXNvbiB3aHkgVExTLVdHIHNob3VsZCB0YWtlIGl0IG9uDQoNCisxIHRv IGFsbCBFS1Igc2FpZC4NCg0KVGhlIG1lYW5pbmcgb2YgVExTIGhhcyBnb3R0ZW4gc3Ryb25nZXIg b3ZlciB0aGUgeWVhcnMsIGFuZCBUTFMgbm93IGltcGxpZXMgcHJpdmFjeS4gIEF1dGgtb25seSBp cyBub3Qgc29tZXRoaW5nIHRoZSBXRyBzaG91bGQgYmUgc3BlbmRpbmcgdGltZSBvbi4NCg== --_000_150E2CBA14F64953B6CF241A117E2325akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <706A4FEB52C0424C8A2A88740C19E826@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNv TGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDou NWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFs MCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5nbWFpbC1tMTcyNDE2ODMwNDc2NjczOTg3 NW1zZ2JvcmRlciwgbGkuZ21haWwtbTE3MjQxNjgzMDQ3NjY3Mzk4NzVtc2dib3JkZXIsIGRpdi5n bWFpbC1tMTcyNDE2ODMwNDc2NjczOTg3NW1zZ2JvcmRlcg0KCXttc28tc3R5bGUtbmFtZTpnbWFp bC1tXzE3MjQxNjgzMDQ3NjY3Mzk4NzVtc2dib3JkZXI7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCglt YXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0 IGwwDQoJe21zby1saXN0LWlkOjc5MjA5MDUzODsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCglt c28tbGlzdC10ZW1wbGF0ZS1pZHM6LTEwMDcyNzUxOTAgLTE3MDg0NjY5NzggNjc2OTg2OTEgNjc2 OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2 OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDo1MDsNCgltc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7 DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYW5zaS1mb250LXdlaWdodDpi b2xkO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpA bGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdp bi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlw ZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVm dDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPk9idmlvdXNseSwgaW5kaXZpZHVhbHMgc2hv dWxkIGZlZWwgZnJlZSB0byByZXZpZXcgdGhpcyBkb2N1bWVudCBvciBub3QgYXMgdGhleSBwbGVh c2UsIGJ1dCBJJ20gbm90IHNlZWluZyBhbnkgY29tcGVsbGluZyByZWFzb24gd2h5IFRMUy1XRyBz aG91bGQgdGFrZSBpdCBvbjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mIzQzOzEgdG8g YWxsIEVLUiBzYWlkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgbWVhbmluZyBvZiBUTFMg aGFzIGdvdHRlbiBzdHJvbmdlciBvdmVyIHRoZSB5ZWFycywgYW5kIFRMUyBub3cgaW1wbGllcyBw cml2YWN5LiZuYnNwOyBBdXRoLW9ubHkgaXMgbm90IHNvbWV0aGluZyB0aGUgV0cgc2hvdWxkIGJl IHNwZW5kaW5nIHRpbWUgb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_150E2CBA14F64953B6CF241A117E2325akamaicom_-- From nobody Thu Feb 28 05:58: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 5EA99130E7F for ; Thu, 28 Feb 2019 05:58:18 -0800 (PST) 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 nwkdmzNXYE1d for ; Thu, 28 Feb 2019 05:58:15 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B59B12F295 for ; Thu, 28 Feb 2019 05:58:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CB107BE39; Thu, 28 Feb 2019 13:58:12 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1tPkUHyuJO4Y; Thu, 28 Feb 2019 13:58:12 +0000 (GMT) Received: from [134.226.36.93] (unknown [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 70068BE24; Thu, 28 Feb 2019 13:58:12 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1551362292; bh=8WKkqNsME78WB92WeAE3c+buPPFX07um9wyDTVMBrPk=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=xrkScpHN3YQlcsNfSEXbPvpPJ0mQGqxcdBmNBpxrcLEgzKuZkBeHQfxfTjIqdzJi8 ou9MBvBzCM1DUZz0BhX6nx+k3o3AflTudadOvqrYwtkVF7KXQqikI0l6W5LIYvO5cu QMMlAHscBrqVCdukExAG03VvFdEsClisEg0cOx8I= To: "Salz, Rich" , Eric Rescorla , Jack Visoky Cc: "tls@ietf.org" References: <150E2CBA-14F6-4953-B6CF-241A117E2325@akamai.com> 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: Date: Thu, 28 Feb 2019 13:58:10 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <150E2CBA-14F6-4953-B6CF-241A117E2325@akamai.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="H9U7utlKIufUeZpsvgRQ5vvossDlG8hXI" Archived-At: Subject: Re: [TLS] EXTERNAL: Re: Authentication Only Ciphersuites RFC 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, 28 Feb 2019 13:58:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --H9U7utlKIufUeZpsvgRQ5vvossDlG8hXI Content-Type: multipart/mixed; boundary="SiyeTbOQgb3s28n2Vy1U9ywZtwIdniWkD"; protected-headers="v1" From: Stephen Farrell To: "Salz, Rich" , Eric Rescorla , Jack Visoky Cc: "tls@ietf.org" Message-ID: Subject: Re: [TLS] EXTERNAL: Re: Authentication Only Ciphersuites RFC References: <150E2CBA-14F6-4953-B6CF-241A117E2325@akamai.com> In-Reply-To: <150E2CBA-14F6-4953-B6CF-241A117E2325@akamai.com> --SiyeTbOQgb3s28n2Vy1U9ywZtwIdniWkD Content-Type: multipart/mixed; boundary="------------35BEE5CB9DF4688840F5CC6C" Content-Language: en-GB This is a multi-part message in MIME format. --------------35BEE5CB9DF4688840F5CC6C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 28/02/2019 13:54, Salz, Rich wrote: > * Obviously, individuals should feel free to review this document o= r not as they please, but I'm not seeing any compelling reason why TLS-WG= should take it on >=20 > +1 to all EKR said. Same here. S >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --------------35BEE5CB9DF4688840F5CC6C 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 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5tDJTdGVwaGVuIEZhcnJlbGwgKDIwMTcp IDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJCZQmAAUL CQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1yw aps8HGUNhLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG +48od+Xn7qg6LT7GrHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXk kTFaSGYJj3yIP4R6IgwBYGMzDXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRr pZtXB1XQc23ZZmrlTkl2HaThL6w3YKdiTi1NbuMeOxZqtXcUshII45sANm4HuWNT iRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS3MmGgVS4ZoX8+VaPGpXdQVFy BMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml3OEuIQiP2ehRt/HV LMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi2/Jrsz6M zh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6 TzKjGjruq8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxIkBHAQQAQgABgUCWj1SoAAK CRAvPIc2gF+NovMcCACVZPo1cQa3D+vWaIo0ZyinO/MgtD2gHysoj1T0Qvq05//L ZXmhh578bJANvdl2g/HFhhwl/5HKIfWcyipQhmJklp/dsleKcNnn4B18T75RHY0G +po3ILq7evbiOjUH+xqApti1aCxi1GocsPghaLfsxmtXKMG4Xu7XhDTv66GOrqZf Y7+0ekJjD9Dza1t5NE/JR/VZA4B8PWR8Glb0+8C9rkjD0VZ5ekJdHPDGcJmFh8Z+ q25LDoI8Fgt1uKSowvoVnsQO5MFv/y6bXArtj1uB4hAL4JiOFgHlFdrW0MlFpvYm ziW4K9JHTD8KAfDbrb3e2W97ZDpROuYfE/lTbYOWiQI9BBMBCAAnBQJaPVAyAhsD BQkJlCYABQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEFqy+vF7Fyvq0mkP/ius gsf6Z4/Tu+vHzBbl5i6oKI8ZieH8JfEgXx4ut9t7l3hBGC2r7DpR5A8zLMpEhGIK gFcHagksFkfLEE/FmWDfd1MysQafxBYrHaI27P2tkxfI5JYV6247TV39pQ93kGds tsjIrmh/zEJCVczoofxtz72BDt51H2Z8tN28F/YVHnbaGDwFEEzWKYpze87y/f36 ogcdGO6LDEEEIA6Ee0dGxleuKlLS4UDTt0zjo6L8TyiyPHp9C3+UfnP8837Zp3Fh KstIBd+vWgPdHFg2G5aDIYUvrj9UJBvVgaN/RnkwE+dab2OBSg5jkr141JLQvzdZ 4mOUXn5D9Y6AH6tvj0+ubYMV6j35L1/ZXncuXPVYiylcmDp/6f2WYcT3gx9CPUYA cLMjQV4vX2W8z4uEPyMlIJuGsLf7KhvLL8BQ6zlncT6eONfUUX9UJUCzqI5rqL5c b5jWGHeKvbLWRyQnlq5PXQxJTwYRm71rJTgzejc33LE6Nqg/Q25Dgwwsv+f+7i73 gB5loc80Fef+FV9VFGalFe0Yq8m0UASmkYRh7MH5ssoibpeWk+SGfBjOV4tnsAwR yjYLpAzxA8HeDcmlLeypGEDmsQ/iUvXoGaKOYX4Ieg8T/PCAplsqnJUOq8hbkgOC 98gLZfiltkNG8YhQpoZIHj6SxmBRSc3K99CvanuOiQIzBBABCAAdFiEEfhcKBFyE z0YOK3mgEO952f2DUxIFAlu3JJsACgkQEO952f2DUxJ4qRAAmbjiO3WTAeBCB4ME p2N2+XQCMTTFURDGuJnqU/+X//fhhPRq4V/OxgisKFKlBcAS2hsECvg6HDVSz4Fl 74fk/y+botG4/CjMLdKPB9fgh5zz72i3q0hWDixt50NKBv8IIVWOyYgZxDU/vcks lMEnqbFgJX+CfdALpvAM4WjuQP0UMcKNE3xd+EdDhD1xjK3Tq4XfWob9q6aBZgL2 B4IaADCIeDDE1hv0agnSJmMJE7Bti8tNxCCxVRbZtOaxVHXdRUoOx2XTaxFXupxV hbpHRrdFrwq51f6e3bkfkNEZ3fzYpnlbynJ2zL++JO8P3Pq/S6UKEFjEB50i8YgK WuFvGUsQ+YiDgiZU4saqxSBWbfYn3lY6MSSTg8RnXbFIMG3CFImqYk1uhaV+bDjc p0htjzM2F98g7c3o7sWx0bGarId4uhOmpj7JJVQ+lu7Jby6Ocj8n//7qF1Nn11Cw QlCVaeAq5Y5DmZrnww9I3zzOWWyqFkAVCM3GqeRLMvplD6/+O+5FF7XoHzQB47nk OyZtawy/9gssPWZKLv4qHLYS0wGGCiNbCsYy90s3pfeafM0kSxxjIvEz21KT6LJI /awu2ErQFWCkDMFJ1p/97MjPrQ/6d4cPO140V/wyfuWaBiTVqa9mgnb2zn6fYfDH JEvl1UzIx3JCae25tty1+qtnS0i0LlN0ZXBoZW4gRmFycmVsbCA8c3RlcGhlbkB0 b2xlcmFudG5ldHdvcmtzLmNvbT6JAj0EEwEIACcFAlo9UVoCGwMFCQmUJgAFCwkI BwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+o7HBAAxHAdFkBGZ9gJK8w7 NUYS9C6enGYtAYoKH5G3Bn3YScjErNfQtHYb53KwBQpVSOv1HcN8hbQ8mLTgn9lt zNwNSuv0XxIswi807HRSIZ4vYDiS5VKV1YkLYK5bLY5O4alVdzqM+AZQqkuHBu63 6n+C0ED6UwLhVBFfSNvBQVAdoq6gvr+IE8rCIKTMNGwNcgVPbF+YxP7UZM6p7s2a 5MIqGw7URSfaqfuztibXGOBLFbSwLGqHSSnOXBfEeDrwdZ+ur8cXIIPRIeCTVmeO 8bGgpgBqNQXG9oyGN+TrYAC+4Ahi0UjCk7QGj8tf3xICKoQpYyfceNBZJ/969gV9 tVgvRxUjxUwc9kZbi0c8XYMTq5GCvBIh1D6BOW9QBM2SsNgG3l36+e3+c2LDdyKn 20C1IzGLVDdcCtz42/onQ/e9sMlzFrfLjs5SO2/TnLvp2JtsIQXyb/T5qd0GE5j8 /iwfZR+uVTVVEsUl1a+Yllzt6sdR7RIhhKpKaKzEAk4d0+VHdz7zEkQRRSjbPVoS fy8c/kld9Fi8Buna+ZkKpcwIW+D4XP83pGcl0XUv6AyqwS1LnEt+jv/+PSXskYtU Lzn8Z35iKkSAH/5Nz6GCZk6ORPNv/6+UI92BpUbu/G2tBwK8bPgAg+gJxBx3G7MK W7VRCmM5UrtAK9A3O70VjPyMkHSJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLC LAf/X/9vRTZWtwSXxiBCA54a6hg9IvW0mvPUqgXfvrhtOk0IFucLKrTXK8J/NcmU 6ulxOovVbQ+Bin6gtHeCmSa/W523g/NXCOuFTnS/MyVibNL4+RCFwqGysl++Cm+L nj1MmasE9kO+CNdervx8APfxV7D6OYrG4eGag+LdFR6VpJn6tRT0/WvyT8l+Oqiq gdhXHv+0MvkkD9TX5LlJW4VB/yRvWkkmL5N5c5zYh+NcfTPhQ5S9dOorVzrm65d6 Itn0937Ennau7s7fiFdA0BHjWqEAFLsBIXQfCFjjKjdsKA4xlSiX7X7ElmPYpWa5 wwTQ66dL0anMd9y1DJCMOHe4gYkCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9 g1MSBQJbtyScAAoJEBDvedn9g1MSY7sP+gKR0rFU1g+GtB+hSdtwPRbacvml2eL2 Jc5Eq37J9hAqxHyt5V0If7s8IyVA2GXgdfwULBWbXGDUDiUkh20OPQRUS8G9Sf8A WRuG25q5C8ZzWygykL88RKXJZDFtA49CeqO5Bq5syBhq4QfiSTffQHIp3h0boPGU hSBEUQpooMXYQClNARQ+z/uRzR5bUi9wxdXNnxTn9ia4ASlaBPvUYTGY1jW2HrRR SwpI12+UaWsvc3jJtQ8X0kxgJ7jsFF1uqquIZ5eflQv+PHHg2RJSy37u0UFGb+OK ZEkzlmbPokKCYhzBR5PcD6sgdlaJNcidmto9u1oV6yZT8J2W4CTuUclgxt6f3lZq ZeVLnNnbHyKUdeypwLlqYISulfnMhZ3A6Bgpf2BtjL6KJbFtPBYmYdxI+HZyY49u U2ZHhRu+CSQ1y7zGKSX0gRp5hE7+A4XJtsT6lTLhbi9aiZTG1S6zKNhl3qNNzszc r27PrvFiyGhpuYQuzdQl2PMGbOI6Ojif3sab53NO3RLsLOM09wIlr95yKLlkXkUr WcvUJGrw6HKm8j5opXHTwmJOAbDpc6cMDu+ITRu4spdCnQJcE8RkO8tKyaLuh2Gt U5kYSBK97yr5VviX1FK6rY14LLmnE16OPiK2tiVBKy9nGM0DKtY+K9WcoRZ7s/d7 O0bMfzcNPtGLuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiez GPuBHmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9Wf pHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC 6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2 D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFe A7PbTuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ /Vf3vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbpt PEcmoazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKr em5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96 Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYgh x8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQ oqj1gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P /1tF6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8 Wpfdn3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJ gx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5 SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2 oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIA ypqYo3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoM eDQkd0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS /qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZ IMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XO KVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DJ121 -----END PGP PUBLIC KEY BLOCK----- --------------35BEE5CB9DF4688840F5CC6C-- --SiyeTbOQgb3s28n2Vy1U9ywZtwIdniWkD-- --H9U7utlKIufUeZpsvgRQ5vvossDlG8hXI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlx36PIACgkQWrL68XsX K+pp1BAAqxZ69bQ3dFWesfY1anpP3jV4ozbgp8fu2F1SJxeVv0d3AaQUuxQmPou1 qb4JFHv1J1CyumHaYw0wGB091zXuomX4Ttg/GCWr7noGV8daWG5LNwSj5Mgsj8bF 0iqW6UBPVWJoSp0TN3DtnmntXgmm8c/bMzdFXe3YSi8TqCcP/UzeHEB6h6mqm/+x ERGn0heWt9q2btDclPZtTBbvgMQt9idIaFhKDEDN5F62LTGD5AJtM2xSjq9uZ38A dT+wRhFq8OX8cQM5lWPE6D7AcFA5W/bKE7nyy0EX+GvDEjKpVf6zcMF0rIJ2M26U M10aodmxj6J3BMaLnm2FXsTsLRcBCYIOzpkbv1+yP/eWxCngay+c3InuReu4nGtx mZ7O6gMGJsJx9cWQ2QkRSQSyTLgNXO6VNzuOMok3oMzxew+60ZyGKuqxEIeqegiq cIEJvUE3SpKYtDcGoLcFVnQXk3FTTgS5LL2JkkE7+31ZHUiRPkenOy95FVLwSfEF jPQF8eIzUZd/SWQZXLZqoJARORr6VQrBpGpL4kn6EQJWbCh9Q4YcxjG5h1MdQRKP xay+aXQYo5vLEWCc/Q0fnPFgzq1Cobo0fcxUpl1M4uSAXVk5TpNMwhj8Ydxw4f2Q PiinWAaJnhRvbmPdMYjeoBl3oeJqwp7SdLcteXmkbOTTQkO1oek= =eiHx -----END PGP SIGNATURE----- --H9U7utlKIufUeZpsvgRQ5vvossDlG8hXI-- From nobody Thu Feb 28 06:19: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 B707E130EC3 for ; Thu, 28 Feb 2019 06:19:10 -0800 (PST) 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76iBGVYCcS7U for ; Thu, 28 Feb 2019 06:19:04 -0800 (PST) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F5D2130F1E for ; Thu, 28 Feb 2019 06:19:03 -0800 (PST) Received: by mail-lj1-x230.google.com with SMTP id l5so17297650lje.1 for ; Thu, 28 Feb 2019 06:19:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=u1Tlgfzn1R14SZbrfuLeHXk62cAwxFI/q9ZwN7Hg/P0=; b=kbpuV+icqJYVvqDoFo+CudWn2zfOicOLqCaCu18H+feU2+6v/7/JOosJFK4dOa4hLL Oh4TVBu7klDIN5T/qd+zLZTBL7F9Spzjq0TIxR6pRqMdv5P88rXhr8vxtHToPBJFdw16 YFckMPEflo/Kv0ZUdV6RWEFUcjyRLCCd1KA3OWxHwCOfe3l6ANQzQStm+55BdxDHl9yg JIwN9MMvBQDvky35Cjd7VnyJdZa94UOaiCRhpdoZpzn8MMjk9KkYfJOOKbx3GwzVByKu zefk36ElmujvknDx2XJHq4HeUN63YsB0j+NsAtT4bOI6Se9qeLSFe/zK3805lPJ8xZqz MXsQ== 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=u1Tlgfzn1R14SZbrfuLeHXk62cAwxFI/q9ZwN7Hg/P0=; b=BkftdsG5vmWXRXhRE+I35wurVLAg5XGjSXjGJKSrwpVeS6FfiDeX1S+TRh4kgXpTxF z09geP2JLDwZexCQqtGOiOLdIEA719AYggvYIfUGsDtfucZQelaWTdIa2V82wGgsmiF8 2lfdXBSXweAxsWq4SrSfw/Om8+Jn9VSnbtqDW5Lk+gxr5gbNpuE6+lv7aZ5JVwDNTFxF 0KTLwzI73dIS5bWJz7Hi6FFpAAupKz4JPFjSgnARRx286tYz8adqVa8SRihsxmA6q7bT A4lfU+sh8GQEMc7M4U6zwh/ZwvtG2A9ruqhNq6EMpgZ0aQEBvnQ1ffgCZC9halBOmrA+ oCQQ== X-Gm-Message-State: AHQUAuadA0hdLDkyaGq89ofpm8cZthhX9JCAk3/GgnHli9oJvCcw9TJG KsCDYIM800yJHXoPP8IlztlnmbBYvBChbeF4ajkAC9KA X-Google-Smtp-Source: APXvYqzM9FQvO7fwooVgPDZLp88FQGICcl6pCosqS9koSlTamF5sxtpytZ2KJLWpc/SecjZpAPgrKbqYhAeR3BEbv4w= X-Received: by 2002:a2e:965a:: with SMTP id z26mr4408120ljh.59.1551363541419; Thu, 28 Feb 2019 06:19:01 -0800 (PST) MIME-Version: 1.0 References: <0b19d021-8101-23ee-2899-450d103a8906@cs.tcd.ie> <0b854704-8f93-f9ad-c067-67f7f73cbbbf@cs.tcd.ie> <1eaaebf3-6e8a-ae84-0ab3-f977295c0721@cs.tcd.ie> <99af33f1-81d0-d918-9746-568d6ad0c1f0@cs.tcd.ie> In-Reply-To: <99af33f1-81d0-d918-9746-568d6ad0c1f0@cs.tcd.ie> From: Eric Rescorla Date: Thu, 28 Feb 2019 06:18:23 -0800 Message-ID: To: Stephen Farrell Cc: Christopher Wood , "" Content-Type: multipart/alternative; boundary="000000000000cde2220582f4f855" Archived-At: Subject: Re: [TLS] Two Multi-CDN proposals 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, 28 Feb 2019 14:19:18 -0000 --000000000000cde2220582f4f855 Content-Type: text/plain; charset="UTF-8" On Thu, Feb 28, 2019 at 5:51 AM Stephen Farrell wrote: > > Hiya, > > On 28/02/2019 13:12, Eric Rescorla wrote: > >> That's what leads me to think that we'd be better off > >> to have multi-valued answers when a browser looks up > >> the RRset at _esni.www.example.com with each separate > >> value matching one ESNI public share (or one CDN, > >> though I'd argue for one share per zone file stanza). > >> > > I don't really understand your point, because this *is* the expected > > design. > > > > Seems one of us is confused then, likely me:-) > > Lemme try clarify it out this way: > > $ dig +short txt _esni.cloudflare.com > "/wEXMtleACQAHQAgsKfk/Hy67PiJCb68AVrT > C5jXkYnJK5UKCHcF4BAojAwAAhMBAQQAAAAAX > HPm0AAAAABce8/QAAA=" > > That's one encoded ESNIKeys value accessed just now. > > The ietf.org domain has two TXT RR values, (actual content > elided below for brevity) so I get: > > $ dig +short txt ietf.org > "somegooglestuff" > "lotsofspfstuff" > > What I'd like to see for my earlier example.com case would > be like: > > $ dig +short txt _esni.www.example.com > "/wEXMtleACQAHQAgsKfk/Hy67PiJCb68AVrT > C5jXkYnJK5UKCHcF4BAojAwAAhMBAQQAAAAAX > HPm0AAAAABce8/QAAA=" > "/wHHBBOoACQAHQAg4YSfjSyJPNr1z3F8KqzB > NBnMejim0mJZaPmria3XsicAAhMBAQQAAAAAW > 9pQEAAAAABb4jkQAAA=" > > Where the first is supplied to me by cdn1.example and the > second is from cdn2.example. > > And have browsers and other ESNI clients be able to handle > that, picking whatever they consider the best of the usable > options presented. > My understanding is that this is problematic for DNS reasons, namely that you are supposed to concatenate the records, and that we definitely need a way to go above 255 bytes. But I'm no DNS expert and if there's a way to have both of these, then I have no problem with it. (And assuming we are: I'd subsequently suggest we can > simplify ESNIKeys so that it just has one KeyShareEntry per > RR value and not a list of those, since multiples for one > CDN or many CDNs can be handled already as above. Yes, I believe you've made this suggestion before, and I opposed it for the same reason I oppose it now. While technically possible, it requires you to duplicate everything else in the entry, which is bad, and worse the more other stuff you put in the record (for instance, the public name). -Ekr I think > making that change, and perhaps other simplifying changes, > at the same time as moving from TXT to a new RRTYPE would > be a fine thing, but there's no pressing need to make all > those changes for the -03 draft or in #137 though, I'd be > happy if we're heading there a little later.) > > Cheers, > S. > --000000000000cde2220582f4f855 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Feb 28, 2019 at 5:51 AM Steph= en Farrell <stephen.farrell= @cs.tcd.ie> wrote:

Hiya,

On 28/02/2019 13:12, Eric Rescorla wrote:
>> That's what leads me to think that we'd be better off
>> to have multi-valued answers when a browser looks up
>> the RRset at _esni.www.example.com with each separate
>> value matching one ESNI public share (or one CDN,
>> though I'd argue for one share per zone file stanza).
>>
> I don't really understand your point, because this *is* the expect= ed
> design.
>

Seems one of us is confused then, likely me:-)

Lemme try clarify it out this way:

$ dig +short txt _esni.cloudflare.com
"/wEXMtleACQAHQAgsKfk/Hy67PiJCb68AVrT
C5jXkYnJK5UKCHcF4BAojAwAAhMBAQQAAAAAX
HPm0AAAAABce8/QAAA=3D"

That's one encoded ESNIKeys value accessed just now.

The ietf.o= rg domain has two TXT RR values, (actual content
elided below for brevity) so I get:

$ dig +short txt ietf.org
"somegooglestuff"
"lotsofspfstuff"

What I'd like to see for my earlier example.com case would
be like:

$ dig +short txt _esni.www.example.com
"/wEXMtleACQAHQAgsKfk/Hy67PiJCb68AVrT
C5jXkYnJK5UKCHcF4BAojAwAAhMBAQQAAAAAX
HPm0AAAAABce8/QAAA=3D"
"/wHHBBOoACQAHQAg4YSfjSyJPNr1z3F8KqzB
NBnMejim0mJZaPmria3XsicAAhMBAQQAAAAAW
9pQEAAAAABb4jkQAAA=3D"

Where the first is supplied to me by cdn1.example and the
second is from cdn2.example.

And have browsers and other ESNI clients be able to handle
that, picking whatever they consider the best of the usable
options presented.

My understanding is that this is problemat= ic for DNS reasons, namely that you are supposed to concatenate the records= , and that we definitely need a way to go above 255 bytes. But I'm no D= NS expert and if there's a way to have both of these, then I have no pr= oblem with it.


(And assuming we are: I'd subsequently sug= gest we can
simplify ESNIKeys so that it just has one KeyShareEntry per
RR value and not a list of those, since multiples for one
CDN or many CDNs can be handled already as above.

Yes, I believe you've made this suggestion before, and I oppose= d it for the same reason I oppose it now. While technically possible, it re= quires you to duplicate everything else in the entry, which is bad, and wor= se the more other stuff you put in the record (for instance, the public nam= e).

-Ekr


I think
making that change, and perhaps other simplifying changes,
at the same time as moving from TXT to a new RRTYPE would
be a fine thing, but there's no pressing need to make all
those changes for the -03 draft or in #137 though, I'd be
happy if we're heading there a little later.)

Cheers,
S.
--000000000000cde2220582f4f855-- From nobody Thu Feb 28 06:42:53 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 8AF35130EAF for ; Thu, 28 Feb 2019 06:42:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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] 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 ZSwk97Rw17Oi for ; Thu, 28 Feb 2019 06:42:48 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD15D130ED6 for ; Thu, 28 Feb 2019 06:42:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 87FFDBE4D; Thu, 28 Feb 2019 14:42:45 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFof4uhWaj8Q; Thu, 28 Feb 2019 14:42:45 +0000 (GMT) Received: from [134.226.36.93] (unknown [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3CE15BDCF; Thu, 28 Feb 2019 14:42:45 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1551364965; bh=TgSynx5PZ7YZABIW6XwnCzATP/uenOEXjuKqSmOhtsI=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=TDIO9RTjfF8FgwIhPXXVBBJ+ks1xflduWp15hVSNOHbEcFsVSO8kLpw9n2FT8x/6L 7Hzk6c/tAb/VmPv+F7IbO3bNyFaJC5mUtPejzC9H1pBa8A9wHCsfdNmP+3t8CekEHh 7Nr/anA4bPx9jGbxNNjGjk31iA4iZbigqa8kz5i8= To: Eric Rescorla Cc: Christopher Wood , "" References: <0b19d021-8101-23ee-2899-450d103a8906@cs.tcd.ie> <0b854704-8f93-f9ad-c067-67f7f73cbbbf@cs.tcd.ie> <1eaaebf3-6e8a-ae84-0ab3-f977295c0721@cs.tcd.ie> <99af33f1-81d0-d918-9746-568d6ad0c1f0@cs.tcd.ie> 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: <1a45b9f6-1131-b07e-0d53-7b790a2709e3@cs.tcd.ie> Date: Thu, 28 Feb 2019 14:42:43 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="E0SqXerccezwZCZuG2zqGdYcPExojs84V" Archived-At: Subject: Re: [TLS] Two Multi-CDN proposals 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, 28 Feb 2019 14:42:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --E0SqXerccezwZCZuG2zqGdYcPExojs84V Content-Type: multipart/mixed; boundary="CFwfRkN0YNKLTSM96rNJFKlIMxx6vFXtI"; protected-headers="v1" From: Stephen Farrell To: Eric Rescorla Cc: Christopher Wood , "" Message-ID: <1a45b9f6-1131-b07e-0d53-7b790a2709e3@cs.tcd.ie> Subject: Re: [TLS] Two Multi-CDN proposals References: <0b19d021-8101-23ee-2899-450d103a8906@cs.tcd.ie> <0b854704-8f93-f9ad-c067-67f7f73cbbbf@cs.tcd.ie> <1eaaebf3-6e8a-ae84-0ab3-f977295c0721@cs.tcd.ie> <99af33f1-81d0-d918-9746-568d6ad0c1f0@cs.tcd.ie> In-Reply-To: --CFwfRkN0YNKLTSM96rNJFKlIMxx6vFXtI Content-Type: multipart/mixed; boundary="------------70B1380ED4029125D878EEBB" Content-Language: en-GB This is a multi-part message in MIME format. --------------70B1380ED4029125D878EEBB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 28/02/2019 14:18, Eric Rescorla wrote: > My understanding is that this is problematic for DNS reasons, namely th= at > you are supposed to concatenate the records, and that we definitely nee= d a > way to go above 255 bytes. But I'm no DNS expert and if there's a way t= o > have both of these, then I have no problem with it. Cool. And same here wrt DNS expertise, but we can find some of that I expect:-) Cheers, S. --------------70B1380ED4029125D878EEBB 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 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5tDJTdGVwaGVuIEZhcnJlbGwgKDIwMTcp IDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJCZQmAAUL CQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1yw aps8HGUNhLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG +48od+Xn7qg6LT7GrHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXk kTFaSGYJj3yIP4R6IgwBYGMzDXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRr pZtXB1XQc23ZZmrlTkl2HaThL6w3YKdiTi1NbuMeOxZqtXcUshII45sANm4HuWNT iRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS3MmGgVS4ZoX8+VaPGpXdQVFy BMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml3OEuIQiP2ehRt/HV LMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi2/Jrsz6M zh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6 TzKjGjruq8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxIkBHAQQAQgABgUCWj1SoAAK CRAvPIc2gF+NovMcCACVZPo1cQa3D+vWaIo0ZyinO/MgtD2gHysoj1T0Qvq05//L ZXmhh578bJANvdl2g/HFhhwl/5HKIfWcyipQhmJklp/dsleKcNnn4B18T75RHY0G +po3ILq7evbiOjUH+xqApti1aCxi1GocsPghaLfsxmtXKMG4Xu7XhDTv66GOrqZf Y7+0ekJjD9Dza1t5NE/JR/VZA4B8PWR8Glb0+8C9rkjD0VZ5ekJdHPDGcJmFh8Z+ q25LDoI8Fgt1uKSowvoVnsQO5MFv/y6bXArtj1uB4hAL4JiOFgHlFdrW0MlFpvYm ziW4K9JHTD8KAfDbrb3e2W97ZDpROuYfE/lTbYOWiQI9BBMBCAAnBQJaPVAyAhsD BQkJlCYABQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEFqy+vF7Fyvq0mkP/ius gsf6Z4/Tu+vHzBbl5i6oKI8ZieH8JfEgXx4ut9t7l3hBGC2r7DpR5A8zLMpEhGIK gFcHagksFkfLEE/FmWDfd1MysQafxBYrHaI27P2tkxfI5JYV6247TV39pQ93kGds tsjIrmh/zEJCVczoofxtz72BDt51H2Z8tN28F/YVHnbaGDwFEEzWKYpze87y/f36 ogcdGO6LDEEEIA6Ee0dGxleuKlLS4UDTt0zjo6L8TyiyPHp9C3+UfnP8837Zp3Fh KstIBd+vWgPdHFg2G5aDIYUvrj9UJBvVgaN/RnkwE+dab2OBSg5jkr141JLQvzdZ 4mOUXn5D9Y6AH6tvj0+ubYMV6j35L1/ZXncuXPVYiylcmDp/6f2WYcT3gx9CPUYA cLMjQV4vX2W8z4uEPyMlIJuGsLf7KhvLL8BQ6zlncT6eONfUUX9UJUCzqI5rqL5c b5jWGHeKvbLWRyQnlq5PXQxJTwYRm71rJTgzejc33LE6Nqg/Q25Dgwwsv+f+7i73 gB5loc80Fef+FV9VFGalFe0Yq8m0UASmkYRh7MH5ssoibpeWk+SGfBjOV4tnsAwR yjYLpAzxA8HeDcmlLeypGEDmsQ/iUvXoGaKOYX4Ieg8T/PCAplsqnJUOq8hbkgOC 98gLZfiltkNG8YhQpoZIHj6SxmBRSc3K99CvanuOiQIzBBABCAAdFiEEfhcKBFyE z0YOK3mgEO952f2DUxIFAlu3JJsACgkQEO952f2DUxJ4qRAAmbjiO3WTAeBCB4ME p2N2+XQCMTTFURDGuJnqU/+X//fhhPRq4V/OxgisKFKlBcAS2hsECvg6HDVSz4Fl 74fk/y+botG4/CjMLdKPB9fgh5zz72i3q0hWDixt50NKBv8IIVWOyYgZxDU/vcks lMEnqbFgJX+CfdALpvAM4WjuQP0UMcKNE3xd+EdDhD1xjK3Tq4XfWob9q6aBZgL2 B4IaADCIeDDE1hv0agnSJmMJE7Bti8tNxCCxVRbZtOaxVHXdRUoOx2XTaxFXupxV hbpHRrdFrwq51f6e3bkfkNEZ3fzYpnlbynJ2zL++JO8P3Pq/S6UKEFjEB50i8YgK WuFvGUsQ+YiDgiZU4saqxSBWbfYn3lY6MSSTg8RnXbFIMG3CFImqYk1uhaV+bDjc p0htjzM2F98g7c3o7sWx0bGarId4uhOmpj7JJVQ+lu7Jby6Ocj8n//7qF1Nn11Cw QlCVaeAq5Y5DmZrnww9I3zzOWWyqFkAVCM3GqeRLMvplD6/+O+5FF7XoHzQB47nk OyZtawy/9gssPWZKLv4qHLYS0wGGCiNbCsYy90s3pfeafM0kSxxjIvEz21KT6LJI /awu2ErQFWCkDMFJ1p/97MjPrQ/6d4cPO140V/wyfuWaBiTVqa9mgnb2zn6fYfDH JEvl1UzIx3JCae25tty1+qtnS0i0LlN0ZXBoZW4gRmFycmVsbCA8c3RlcGhlbkB0 b2xlcmFudG5ldHdvcmtzLmNvbT6JAj0EEwEIACcFAlo9UVoCGwMFCQmUJgAFCwkI BwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+o7HBAAxHAdFkBGZ9gJK8w7 NUYS9C6enGYtAYoKH5G3Bn3YScjErNfQtHYb53KwBQpVSOv1HcN8hbQ8mLTgn9lt zNwNSuv0XxIswi807HRSIZ4vYDiS5VKV1YkLYK5bLY5O4alVdzqM+AZQqkuHBu63 6n+C0ED6UwLhVBFfSNvBQVAdoq6gvr+IE8rCIKTMNGwNcgVPbF+YxP7UZM6p7s2a 5MIqGw7URSfaqfuztibXGOBLFbSwLGqHSSnOXBfEeDrwdZ+ur8cXIIPRIeCTVmeO 8bGgpgBqNQXG9oyGN+TrYAC+4Ahi0UjCk7QGj8tf3xICKoQpYyfceNBZJ/969gV9 tVgvRxUjxUwc9kZbi0c8XYMTq5GCvBIh1D6BOW9QBM2SsNgG3l36+e3+c2LDdyKn 20C1IzGLVDdcCtz42/onQ/e9sMlzFrfLjs5SO2/TnLvp2JtsIQXyb/T5qd0GE5j8 /iwfZR+uVTVVEsUl1a+Yllzt6sdR7RIhhKpKaKzEAk4d0+VHdz7zEkQRRSjbPVoS fy8c/kld9Fi8Buna+ZkKpcwIW+D4XP83pGcl0XUv6AyqwS1LnEt+jv/+PSXskYtU Lzn8Z35iKkSAH/5Nz6GCZk6ORPNv/6+UI92BpUbu/G2tBwK8bPgAg+gJxBx3G7MK W7VRCmM5UrtAK9A3O70VjPyMkHSJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLC LAf/X/9vRTZWtwSXxiBCA54a6hg9IvW0mvPUqgXfvrhtOk0IFucLKrTXK8J/NcmU 6ulxOovVbQ+Bin6gtHeCmSa/W523g/NXCOuFTnS/MyVibNL4+RCFwqGysl++Cm+L nj1MmasE9kO+CNdervx8APfxV7D6OYrG4eGag+LdFR6VpJn6tRT0/WvyT8l+Oqiq gdhXHv+0MvkkD9TX5LlJW4VB/yRvWkkmL5N5c5zYh+NcfTPhQ5S9dOorVzrm65d6 Itn0937Ennau7s7fiFdA0BHjWqEAFLsBIXQfCFjjKjdsKA4xlSiX7X7ElmPYpWa5 wwTQ66dL0anMd9y1DJCMOHe4gYkCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9 g1MSBQJbtyScAAoJEBDvedn9g1MSY7sP+gKR0rFU1g+GtB+hSdtwPRbacvml2eL2 Jc5Eq37J9hAqxHyt5V0If7s8IyVA2GXgdfwULBWbXGDUDiUkh20OPQRUS8G9Sf8A WRuG25q5C8ZzWygykL88RKXJZDFtA49CeqO5Bq5syBhq4QfiSTffQHIp3h0boPGU hSBEUQpooMXYQClNARQ+z/uRzR5bUi9wxdXNnxTn9ia4ASlaBPvUYTGY1jW2HrRR SwpI12+UaWsvc3jJtQ8X0kxgJ7jsFF1uqquIZ5eflQv+PHHg2RJSy37u0UFGb+OK ZEkzlmbPokKCYhzBR5PcD6sgdlaJNcidmto9u1oV6yZT8J2W4CTuUclgxt6f3lZq ZeVLnNnbHyKUdeypwLlqYISulfnMhZ3A6Bgpf2BtjL6KJbFtPBYmYdxI+HZyY49u U2ZHhRu+CSQ1y7zGKSX0gRp5hE7+A4XJtsT6lTLhbi9aiZTG1S6zKNhl3qNNzszc r27PrvFiyGhpuYQuzdQl2PMGbOI6Ojif3sab53NO3RLsLOM09wIlr95yKLlkXkUr WcvUJGrw6HKm8j5opXHTwmJOAbDpc6cMDu+ITRu4spdCnQJcE8RkO8tKyaLuh2Gt U5kYSBK97yr5VviX1FK6rY14LLmnE16OPiK2tiVBKy9nGM0DKtY+K9WcoRZ7s/d7 O0bMfzcNPtGLuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiez GPuBHmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9Wf pHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC 6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2 D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFe A7PbTuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ /Vf3vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbpt PEcmoazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKr em5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96 Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYgh x8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQ oqj1gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P /1tF6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8 Wpfdn3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJ gx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5 SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2 oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIA ypqYo3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoM eDQkd0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS /qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZ IMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XO KVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DJ121 -----END PGP PUBLIC KEY BLOCK----- --------------70B1380ED4029125D878EEBB-- --CFwfRkN0YNKLTSM96rNJFKlIMxx6vFXtI-- --E0SqXerccezwZCZuG2zqGdYcPExojs84V Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlx382MACgkQWrL68XsX K+oVWw/+LL7sCM84u8i4Fp45X3Yy9YNB8pYicnyfDTjZl2PgXUZpKlm11yvSJjV/ gh9a+kldEDVXVWnC7CxoxrIsJzSp2m6vAhMS+wUrZRSJuImiyOOUehM1JE3vYc95 BGxYa/Udra0TAd+m0tvGHe2Ryp/7r6JX3tzHXivkMntN3fYy3PgiRIoDr3AUu71z DFkv4G6e3zdiJpsKlGnvlf8Tf1vZE2nB4dOLKfcaZy+Z5A0kZ2DSWF3vHGPxdpIH sCxIJjSPxn6klOfsYzBKkfkLIstVoHl7NkaO62xXXF0E+HQa06CuxlzOW7iLxwmN 7Z1WCx2UILHmKqF7SUCJSZJBZDqdxxIZuHKTgGbhzPQo7nJABaQDd4NcjR8r5oTf ZDIgkNZF3NnBYCEDDqi/9GsP19uV9upag2pSirDVSJDFDR/SUej98wzPN81fn09v cFxdJ9Skhdx/QY81J9CKAnvW925D888iN5FOijA9N0t2Y6rzZV2HTPwngC2A1/rT 0pmbynujEPOMb7aUECeJdF9q1FeZnRSSLobI5+x+7PxeM8YccAskGuAWY3ZlZcdX w/l7QlxOyj38ieGmaykWSXn/TteAupD/+Id5bavTaQ2GIgIYuUU5qKE0CBWlm43y Shxr6S+v3jkZFcv6oKbdg3NwzRViw7uN+R1nO/7zg5ENl93UTKc= =2HsN -----END PGP SIGNATURE----- --E0SqXerccezwZCZuG2zqGdYcPExojs84V-- From nobody Thu Feb 28 07:56:34 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E24F130EDB for ; Thu, 28 Feb 2019 07:56:33 -0800 (PST) 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, 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_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=ericsson.com header.b=EkmRF2mL; dkim=pass (1024-bit key) header.d=ericsson.com header.b=TZHfMaD+ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSPoJhSFNozC for ; Thu, 28 Feb 2019 07:56:29 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 07297130ED6 for ; Thu, 28 Feb 2019 07:56:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1551369387; x=1553961387; h=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=U5xilt8FTJSwApQRVYGseVrrtCmpW3hRDpmc5rFF/QE=; b=EkmRF2mLOa9xIqHT9rmtEV6lgaSKnTy1cxvQMEJytLkrMT5Ld8O9BFm0Nd92uurX WTtg723d1tWiIN6yX4TdNGMxR457FCipCB36K8FNi7qPhv82i2UC1uld3ENk1KMJ JWMO2Sr1F2o089GrCznxnIbJdL+/IIf9GeD7s02fhKo=; X-AuditID: c1b4fb2d-2198b9e00000062f-4c-5c7804abc736 Received: from ESESBMB505.ericsson.se (Unknown_Domain [153.88.183.118]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 7B.B7.01583.BA4087C5; Thu, 28 Feb 2019 16:56:27 +0100 (CET) Received: from ESESSMB503.ericsson.se (153.88.183.164) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 28 Feb 2019 16:56:26 +0100 Received: from EUR03-AM5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Thu, 28 Feb 2019 16:56:26 +0100 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=U5xilt8FTJSwApQRVYGseVrrtCmpW3hRDpmc5rFF/QE=; b=TZHfMaD+FU9XPHBilUUY2g277lFF+oeH2gWUw8IKcszZvwDpYEgGXIgn3NV7lURAtbI/l9vxxDtR9SYY26n+2WVrWqHxwf/cWNNOh7XeTPXli5qg+chted7miq2EtvDcQr70+OG/PgIrGFAhi2uFAi2tmJMfdmRonTE2DWSwEdY= Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.166.22) by HE1PR07MB3114.eurprd07.prod.outlook.com (10.170.245.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.12; Thu, 28 Feb 2019 15:56:24 +0000 Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::49f9:ba7d:bd7d:2ffc]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::49f9:ba7d:bd7d:2ffc%5]) with mapi id 15.20.1665.012; Thu, 28 Feb 2019 15:56:24 +0000 From: John Mattsson To: Jack Visoky CC: "tls@ietf.org" Thread-Topic: [TLS] Authentication Only Ciphersuites RFC Thread-Index: AQHUzpc5W2pxSTaBS0OsWyhr6Jy/M6X1b+OA Date: Thu, 28 Feb 2019 15:56:24 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.1.190220 x-originating-ip: [192.176.1.92] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c14948ec-8e73-4bf2-d6f3-08d69d954ab0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB3114; x-ms-traffictypediagnostic: HE1PR07MB3114: x-ms-exchange-purlcount: 2 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtIRTFQUjA3TUIzMTE0OzIzOmdYNlU1ZmZoYzUvRmlHSEhqUXluYkFJemo3?= =?utf-8?B?YlQweTFYckh6b2dBNUJCTFAwTDVGbS9YSm5TMGx5Uy9BcG1XaTVYQlkxOWxl?= =?utf-8?B?UjhiZTdrbGhDOWxCTi9LYjcrUkJJcGxQTlFaK2xBa25ndkJrTzc0QUxWNXZY?= =?utf-8?B?ZllDWEk4M1VCZDJFNXdsTXdkeUNUdGtNQjNqWVF4RVJLOWgwb00xVTl0cXdi?= =?utf-8?B?QTVtV3VPUHlJS3BnWFJhK0phMUYrNmhrYzlYU2FSeUJaUDhvVjc4NmFlY3dH?= =?utf-8?B?MXN4UjZTaDhoWVNFUVc5bHdmS0xQM2RxU3RJRjlvNGZlalVoT2ZzQm1PS3JB?= =?utf-8?B?ZW1EZCsxWHY1d3BwMjg4Z2hYVk9vcTRYUkVBcHlBenVLekN5aHdVdGVHWDVF?= =?utf-8?B?cjRaU29zaTR1dnl6K3FuVDVsZXUxYWJFU0d5UDF2UWRuek9CMmhlSUlNWnQx?= =?utf-8?B?L0t0Qkt4WkQ0SzJHaDFaaElOT1hETXVDb1R4bEw3QTRsZWlJVDdRcDBQSGl2?= =?utf-8?B?aXBaUXpYV2J5M1dKVDR6NUNybmpCWXppdnJOZFFGY3ZIbzJDdUhNNTY4ZUpx?= =?utf-8?B?NDdDRGtpQW5HM2NiUG5UM0gwM25ybUVqMmtVR3Q4RWFNQkY4UlhYbGF3SUxI?= =?utf-8?B?VjdwQWRyY0xLRVE4RmVkMGdkN3lFaThkeVBXT3pZMHNRWnlYY3BqM2VQazhX?= =?utf-8?B?aTdxVVhRQnZ4bXNCU0hPZFFDdWJhampJYUJxQm5VNEU0V1A1Tlo4UFlabW5I?= =?utf-8?B?VExkdVdxenkxUkFQSnBhclh2bzJsTk5EcmNYYXo5TmFJeWV3bno5RU94Zm9i?= =?utf-8?B?Z3VsSnB4SjBsa2pMeEIwbXo1Z2xvbDB5TDlmWHh3WXZyYlNONCtCeEs2Szk3?= =?utf-8?B?dDgrT2c4OVE2QWJWQTI4YTd2bmdCUFNwY1lLcnNLNGxiWEJpVHhTWnRpT0Vs?= =?utf-8?B?QUxEc0RlWUsrVWp3aVp1N2lVTW1GZ0RDclltNUNHYTZmT0xqcXA1K0FITzY4?= =?utf-8?B?dXRaRVc5dlhqN1NZb3V6NWxNWWpDckZnMjRpek01blJMY00vU0FKMFNFL2Yw?= =?utf-8?B?VjVlRUJ4dWR6aEtJUjd1OGZUZ0x5bWJsZjA1R2dDYm5DRlZEcFJYc3lSem1F?= =?utf-8?B?bXFsRFlpcGhxWngveTlzUUU1akJRcGJtb3I2VjFwTkdSSS9PZnpkdnRaeS91?= =?utf-8?B?WldIRUIxaExGUEp1cTlNSjZ5a1JOOGFDSFFWZXBsbDd2enI1VFpnTWk5UTRQ?= =?utf-8?B?SDVRS0tIS2RQclo3QkNBclR5dTJwSzdRZ2dDa20ySjZGdDk3ZjgxeHEzTlQr?= =?utf-8?B?ME01dDJkT0pFZFRnYkdCdE5JNEY1Q2xoNjB0YmM5L01KWFRuWVJzd2JiSjJC?= =?utf-8?B?WlVvSnB2TnIwYmVzZDllZmRpdWQyRjlacEVUMDlSd3h4TWhCajhBcHRyUFkr?= =?utf-8?B?S29tRGxsb1RMU1FTTXFXdGUyek1OeVFzbTc4dmdvcTczVDdPL1FhQkJBZlFj?= =?utf-8?B?ZG9EUVNUV2FkUUZxc2dseXRnckFrRk9GdXBIakJSVmt1SXBJYmpMak1pN2NU?= =?utf-8?B?TGVkeTZiQ201QzhUbjJVKzZ3V2k5QWpUYkF4ZVFTZG0xTGwvQlRDVy8wc3lN?= =?utf-8?B?V1J4aFcvYmNHbWxxRjJCZ2tZY0JrMXRBekpGU3BabmlLSVNVUzA5eFdRZ1FK?= =?utf-8?B?MEkxNkZ4TXVtSW41S3dzRloxWnc5K2ZXNTFPTjZzTGRCMVROQTlUcnc5VmdN?= =?utf-8?B?OUtHZmNPSmRnSzE5c3ZYWnF2SGRIQmxNY3lvVTBkU2pkZm80aXlKNjczdDdO?= =?utf-8?B?YzJNajl5SUh2bU5DMGttUVFldWFaVkpGWnpqS2hwRkZNbFRoNE1abFgvekRB?= =?utf-8?B?UStPci9nNmphUUJoempoRytrVy9LcEE3WmxWVnVxVWJTM3Z5Smw5NW1CUDdY?= =?utf-8?B?dWF2OHNsbllnPT0=?= x-microsoft-antispam-prvs: x-forefront-prvs: 0962D394D2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(136003)(346002)(376002)(396003)(366004)(189003)(199004)(229853002)(71200400001)(966005)(71190400001)(86362001)(6306002)(33656002)(83716004)(478600001)(6512007)(25786009)(76176011)(105586002)(106356001)(2906002)(82746002)(54896002)(6436002)(99286004)(6486002)(8936002)(316002)(14454004)(236005)(58126008)(97736004)(81156014)(66574012)(8676002)(6916009)(81166006)(5660300002)(7736002)(11346002)(486006)(2616005)(6116002)(3846002)(476003)(446003)(606006)(36756003)(4326008)(256004)(14444005)(5024004)(68736007)(26005)(102836004)(6346003)(66066001)(53546011)(6506007)(53936002)(186003)(6246003)(44832011); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3114; 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: BiwYk3Lj3BFekpLRthPvAkdG6uSfNH0UfMvi3pWJgeu+Na9DPHWbfuM5STd641EmGzK01wDrp30j7z/O7KkZTZVEM6ziCP05PYs4G3VwQrY3u26EN+UN8b2pPGw/pP6svolD5MBUaSaZuVSZdZtRJB+/F4uzLSZfD4AJ71p55vfIoNRr5Y6ybc3480FjiJ9TlGWMOkF9gKMfXWhVikMgs1B5Xq41OrYftZqdHW5oyVQGIW6kdFFpTC3QedoneMzWMTopHH6S2xWw0LqQmS2pJq7u2xKZvAN93nMGFfELXwSnepiQ2FHawO9WcKHjnuhrdimv4mSfb6OH6KwPb9Hbbq0wpseJBReNzCnpiqv2ZtwwAkjAIF2ELnO9genKD4WL/boByP41GFwIkV2s5e536p7eVkuMUemVhhIAV6RBpog= Content-Type: multipart/alternative; boundary="_000_EB6FED0C59C9474F817EF85EB5835CB4ericssoncom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c14948ec-8e73-4bf2-d6f3-08d69d954ab0 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2019 15:56:24.7144 (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: HE1PR07MB3114 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHec85bmejwevc8mlq1EIwwUsaaHTRvsSIBCkiEUunHlScU3fM 24eQUjQtL5mV8w4Glq3ENK+ZTkuUzFiEmhfKaVraLKFWptK2s8Bvv+d5/u//ufDSpPiZg4xO UKcxGrVSJecJqcqwjnSvZiozwjf/LhE417DAD1wfL0TBhKKx8Q+heP60jxdKhAuPxTKqhHRG 43MiShi/1FTPT9mYRJndv7uoHFT1DhUiAQ34MIyOv7axGA8hmFiWFCKhhX8haHvxneCCRgJ6 Oxf51oDCpSToGt6SXKWcgIKfVRQXzCNomX5DWM142BdqenN4VpZgT9D1GUgrk3g/rBlqKSs7 4QCYfVBMcppA6Fm7gzj2g8X2XL6VKewOpQ0jNh8RDoK6YaMDN2wQfK022fQCHAyd6xM2T4R3 g3n0EcH1coYPC3UEtyiGxt5xkmMpfDFu23yk2Afaij9SXH4fbBrmeRy7gaGuyH6kEEuvbWRd EvAUgoobw/YHntA+sG1nGZiNP/icqNYJCvp1ls60JUiEpSF/TuMK93Nn7EPU8+DxTShF3tod s3IcA/1TV/la286OMFK5QGktTiQ+CE+6fbT2M94u+sTn2APyqmvsrIDr2lcOOzX1iH6IpCzD sklxfv7ejCYhhmWT1d5qJq0VWX7TQNtfr07UvHJSjzCN5LtEM8sZEWIHZTqblaRHQJNyici8 ZUmJYpVZ2YwmOVJzWcWweuRCU3Jn0abYMUKM45RpTCLDpDCa/1WCFshyUJl/fgc+49XxeV0n Xg0XsBdSJcTgWGjz7FazSm5a7Dv9LTI6KrrVO2X6bM2gB9KP8a69b6kzBWy6nmOSJoznTeHq 2Oy9x1+eCl3F7lNt5bdWLs1OapvKejYU0j1H5rozSlKN+GLDAdI3rMJFKAkvIWevdAlDXO65 yfLMAeKjcoqNVx7yJDWs8h/iMQFXSQMAAA== Archived-At: Subject: Re: [TLS] Authentication Only Ciphersuites RFC 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, 28 Feb 2019 15:56:33 -0000 --_000_EB6FED0C59C9474F817EF85EB5835CB4ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgZGlzbGlrZSBoYXZpbmcgYSBkb2N1bWVudCAoZXZlbiBhIGludGVybmV0LWRyYWZ0 IHdpdGggbm9uLXJlY29tbWVuZGVkIGNpcGhlciBzdWl0ZXMpIHRoYXQga2luZCBvZiBpbXBsaWVz IHRoYXQgY29uZmlkZW50aWFsbHkgbmVlZHMgdG8gYmUgZGlzYWJsZWQgZm9yIGxvdyBsYXRlbmN5 LiBFc3BlY2lhbGx5IGFzIHRoZSBzdWdnZXN0ZWQgY2lwaGVyIHN1aXRlcyB3b3VsZCBpbmNyZWFz ZSBsYXRlbmN5IGluIGEgbG90IG9mIGNhc2VzLiBBbnlib2R5IGdvb2dsaW5nIChvciBEdWNrRHVj a0dvaW5nKSDigJxUTFPigJ0gYW5kIOKAnGxvdyBsYXRlbmN54oCdIGlzIG5vdyBsaWtlbHkgdG8g ZmluZCB0aGlzIGRvY3VtZW504oCmDQoNCklycmVzcGVjdGl2ZWx5IG9mIHdoYXQgaGFwcGVucyB3 aXRoIHRoaXMgZG9jdW1lbnQsIEkgc3VnZ2VzdCBlaXRoZXI6DQoNCg0KICAqICAgUmVtb3Zpbmcg YW55IGNsYWltcyBhYm91dCBsb3cgbGF0ZW5jeS4NCiAgKiAgIERlc2NyaWJlIGV4YWN0bHkgd2hp Y2ggY2FzZXMgdGhlIHN1Z2dlc3RlZCBjaXBoZXIgc3VpdGVzIHByb3ZpZGUgc2lnbmlmaWNhbnRs eSBsb3dlciBsYXRlbmN5Lg0KDQooVGhlIG51bWJlcnMgSSBwb3N0ZWQgeWVzdGVyZGF5IGZvciBh ZXMxMjhnY212MSB3YXMgYWNjaWRlbnRseSB0YWtlbiBmcm9tIENvcnRleC1BNTcsIHRoZSBjb3Jy ZWN0IG51bWJlcnMgZm9yIENvcnRleC1BNSBhcmUgWzE4Ni4xMSwgMTkzLjk0LCAyMDMuMTFdLCBi dXQgdGhhdCBpcyBzdGlsbCBsaWtlbHkgYSBsaXR0bGUgYml0IGZhc3RlciB0aGFuIEhNQUMtU0hB LTI1NikuDQoNCkNoZWVycywNCkpvaG4NCg0KRnJvbTogSm9obiBNYXR0c3NvbiA8am9obi5tYXR0 c3NvbkBlcmljc3Nvbi5jb20+DQpEYXRlOiBXZWRuZXNkYXksIDI3IEZlYnJ1YXJ5IDIwMTkgYXQg MTM6MjMNClRvOiBUb255IFB1dG1hbiA8VG9ueS5QdXRtYW5AZHlzb24uY29tPiwgSmFjayBWaXNv a3kgPGptdmlzb2t5QHJhLnJvY2t3ZWxsLmNvbT4NCkNjOiAiVExTQGlldGYub3JnIiA8dGxzQGll dGYub3JnPg0KU3ViamVjdDogUmU6IFtUTFNdIEF1dGhlbnRpY2F0aW9uIE9ubHkgQ2lwaGVyc3Vp dGVzIFJGQw0KDQpIaSwNCg0KVGhlIGRvY3VtZW50IHJlcGVhdHMgdGhlIHJlcXVpcmVtZW50IG9m IGxvdyBsYXRlbmN5IHNldmVyYWwgdGltZXMuIEl0IHdvdWxkIGJlIGludGVyZXN0aW5nIHRvIGtu b3cgd2hpY2ggcGxhdGZvcm1zL25ldHdvcmtzL2RlcGxveW1lbnRzIHlvdSBoYXZlIGluIG1pbmQu IE15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCBITUFDLVNIQS0yNTYgb25seSBoYXZlIGJldHRlciBs YXRlbmN5IHRoYW4gQUVTIG9uIGEgbGl0dGxlIGJpdCBsb25nZXIgbWVzc2FnZXMgd2hlcmUgdGhl IGxhcmdlciBibG9jayBzaXplIG1hdHRlcnMuIFNob3J0IG1lc3NhZ2VzIGFyZSBjb21tb24gaW4g bWFueSBJb1QgZGVwbG95bWVudHMuIExvb2tpbmcgZS5nLiBhdCB0aGUgYmVuY2htYXJrcyBhdCBo dHRwczovL2JlbmNoLmNyLnlwLnRvIGZvciAiYXJtZWFiaTsgQ29ydGV4LUE1ICg0MTdmYzA1MSki IG9uIDY0IGJ5dGUgbWVzc2FnZXMsIFNIQS0yNTYgYWxvbmUgcmVxdWlyZXMgc2lnbmlmaWNhbnRs eSBtb3JlIGN5Y2xlcyB0aGFuIEFFUy1HQ00gZm9yIDY0IGJ5dGUgbWVzc2FnZXMuDQoNCkN5Y2xl cy9ieXRlIGZvciA2NCBieXRlcw0KODYuMTQgICAgIDg2LjczICAgICA5My41OSAgICAgc2hhMjU2 DQoNCkN5Y2xlcy9ieXRlIGZvciA2NCswIGVuY3J5cHQNCjI0LjIwICAgICAyNC4yMCAgICAgMjQu MzQgICAgIGFlczEyOGdjbXYxDQoNCk9uIG1vcmUgY29uc3RyYWluZWQgcHJvY2Vzc29ycyBzdWNo IGFzIHRoZSBDb3J0ZXgtTTAsIEFFUzEyOC1DQ00gYWxzbyBzZWVtcyB0byBoYXZlIGxvd2VyIGxh dGVuY3kgdGhhbiBITUFDLVNIQS0yNTYgb24gc2hvcnQgbWVzc2FnZXMgKDM3Njc3IGN5Y2xlcyB2 cy4gNDg5MjQgY3ljbGVzKSBodHRwczovL2dpdGh1Yi5jb20vY3R6L2NpZnJhLiBPbiBsb25nZXIg bWVzc2FnZXMsIEhNQUMtU0hBLTI1NiBsaWtlbHkgaGF2ZSBsb3dlciBsYXRlbmN5IChodHRwczov L2NzcmMubmlzdC5nb3YvY3NyYy9tZWRpYS9ldmVudHMvbGlnaHR3ZWlnaHQtY3J5cHRvZ3JhcGh5 LXdvcmtzaG9wLTIwMTUvZG9jdW1lbnRzL3ByZXNlbnRhdGlvbnMvc2Vzc2lvbjctdmluY2VudC5w ZGYpLiBOb3RlIHRoYXQgdGhpcyBwZGYgc2hvd3MgdGltaW5nIGZvciBTSEEtMjU2LCBub3QgSE1B Qy1TSEEtMjU2Lg0KDQpJbmNyZWFzaW5nIHRoZSB0YWcgc2l6ZSBmcm9tIDggYnl0ZXMgKENDTV84 KSBvciAxNiAoR0NNKSB0byAzMiBvciA2NCBtYXkgYWxzbyBpbmNyZWFzZSB0aGUgbGF0ZW5jeSBh cyB0aGVzZSBhZGRpdGlvbmFsIGJ5dGVzIGhhdmUgdG8gYmUgdHJhbnNtaXR0ZWQuDQoNCi9Kb2hu DQoNCkZyb206IFRMUyA8dGxzLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBUb255IFB1 dG1hbiA8VG9ueS5QdXRtYW5AZHlzb24uY29tPg0KRGF0ZTogV2VkbmVzZGF5LCAyNyBGZWJydWFy eSAyMDE5IGF0IDExOjE3DQpUbzogSmFjayBWaXNva3kgPGptdmlzb2t5QHJhLnJvY2t3ZWxsLmNv bT4NCkNjOiAiVExTQGlldGYub3JnIiA8dGxzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtUTFNd IEF1dGhlbnRpY2F0aW9uIE9ubHkgQ2lwaGVyc3VpdGVzIFJGQw0KDQpJIHRha2Ugbm8gcG9zaXRp b24gb24gd2hldGhlciB0aGlzIGlzIGEgZ29vZCBpZGVhIG9yIG5vdC4gUmVnYXJkaW5nIHRoZSBk cmFmdCBpdHNlbGYsIEkgd2FzIGV4cGVjdGluZyB0byBzZWUgYSBjbGVhciBkZWZpbml0aW9uIG9m IHRoZSBpbnRlZ3JpdHkgY2hlY2sgY29tcHV0YXRpb24gaW4gdGVybXMgb2YgYW4gQUVBRC1FbmNy eXB0IGNvbXB1dGF0aW9uLi4gU29tZXRoaW5nIGFsb25nIHRoZSBsaW5lcyBvZjoNCiAgQUVBRC1F bmNyeXB0LUhNQUMod3JpdGVfa2V5LCBub25jZSwgYWRkaXRpb25hbF9kYXRhLCBwbGFpbnRleHQp ID0NCiAgICBwbGFpbnRleHQgfHwgSE1BQyh3cml0ZV9rZXksIG5vbmNlIHx8IGFkZGl0aW9uYWxf ZGF0YSB8fCBwbGFpbnRleHQpDQoNCkluIHBhcnRpY3VsYXIsIEFJVUksIG5vbmNlIG11c3QgYmUg aW5jbHVkZWQgdG8gcHJldmVudCByZXBsYXkgYXR0YWNrcy4gQWxzbyBpbmNsdWRlIE5fTUlOID0g Tl9NQVggPSA4IGJ5dGVzLg0KDQotLSBUb255DQoNCkZyb206IFRMUyBbbWFpbHRvOnRscy1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSmFjayBWaXNva3kNClNlbnQ6IDI2IEZlYnJ1YXJ5 IDIwMTkgMjA6NTQNClRvOiB0bHNAaWV0Zi5vcmcNClN1YmplY3Q6IFtFeHRlcm5hbCBNYWlsXSBb VExTXSBBdXRoZW50aWNhdGlvbiBPbmx5IENpcGhlcnN1aXRlcyBSRkMNCg0KDQpUTFMgQ29sbGVh Z3VlcywNCg0KSWYgeW91IHJlY2FsbCB3ZSBkaXNjdXNzZWQgYSBkcmFmdCBmb3IgYXV0aGVudGlj YXRpb24gb25seSBjaXBoZXJzdWl0ZXMgb3ZlciBlbWFpbCBiYWNrIGluIEF1Z3VzdCBvZiAyMDE4 LiAgV2UndmUgc2luY2UgbWFkZSBzb21lIHVwZGF0ZXMgdG8gdGhhdCBkcmFmdC4gIFdlIGFsc28g aGF2ZSBnb3R0ZW4gSUFOQSBhc3NpZ25tZW50cyB0byB0aGUgYXV0aGVudGljYXRpb24gb25seSBj aXBoZXJzdWl0ZXMgZm9yIFRMUyAxLjMgYW5kIGhhdmUgdXBkYXRlZCB0aGUgZHJhZnQgdG8gcmVm bGVjdCB0aGUgbmV3IGFzc2lnbm1lbnRzLg0KDQpUbyB0aGF0IGV4dGVudCwgYXMgdGhlIElvVCBj b21tdW5pdHkgaXMgbG9va2luZyB0byBhZG9wdCB0aGVzZSBjaXBoZXJzdWl0ZXMsIHdlIHdvdWxk IGxpa2UgdG8gc29saWNpdCByZXZpZXcgb2YgdGhlIGRyYWZ0Og0KDQoNCg0KICAgIGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jYW13aW5nZXQtdGxzLXRzMTMtbWFjY2lwaGVyc3Vp dGVzLTAyDQoNCg0KDQphbmQgcmVxdWVzdCB0aGF0IGl0IGJlIHB1Ymxpc2hlZCBhcyBpbmZvcm1h dGlvbmFsIGRyYWZ0IGdpdmVuIHRoYXQgdGhlIElvVCBmb3J1bXMgYXJlIGxvb2tpbmcgdG8gYWRv cHQgaXRzIHVzZSBhbmQgdGhlIGRyYWZ0IGNhbiBzZXJ2ZSBhcyB0aGUgZ3VpZGUgZm9yIHVzZSBh bmQgaW50ZXJvcGVyYWJpbGl0eS4NCg0KVGhhbmtzIGFuZCBCZXN0IFJlZ2FyZHMsDQoNCi0tSmFj ayAoYW5kIE5hbmN5KQ0KDQoNCg0KRHlzb24gVGVjaG5vbG9neSBMaW1pdGVkLCBjb21wYW55IG51 bWJlciAwMTk1OTA5MCwgVGV0YnVyeSBIaWxsLCBNYWxtZXNidXJ5LCBTTjE2IDBSUCwgVUsuDQpU aGlzIG1lc3NhZ2UgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgYWRkcmVzc2VlIGFuZCBtYXkg Y29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24uIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRo aXMgbWVzc2FnZSBpbiBlcnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBk ZWxldGUgaXQsIGFuZCBkbyBub3QgdXNlLCBjb3B5IG9yIGRpc2Nsb3NlIHRoZSBpbmZvcm1hdGlv biBjb250YWluZWQgaW4gdGhpcyBtZXNzYWdlIG9yIGluIGFueSBhdHRhY2htZW50Lg0KRHlzb24g bWF5IG1vbml0b3IgZW1haWwgdHJhZmZpYyBkYXRhIGFuZCBjb250ZW50IGZvciBzZWN1cml0eSAm IHRyYWluaW5nLg0K --_000_EB6FED0C59C9474F817EF85EB5835CB4ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IkFyaWFsIE5hcnJvdyI7DQoJcGFub3NlLTE6MiAxMSA2IDYgMiAyIDIgMyAyIDQ7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1 IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29O b3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVk LCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KdHQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29MaXN0 UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBj bTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCW1zby1hZGQtc3BhY2U6YXV0bzsNCglmb250LXNpemU6MTEuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAuTXNvTGlzdFBhcmFncmFwaEN4 U3BGaXJzdCwgbGkuTXNvTGlzdFBhcmFncmFwaEN4U3BGaXJzdCwgZGl2Lk1zb0xpc3RQYXJhZ3Jh cGhDeFNwRmlyc3QNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2lu LWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCgltc28tYWRkLXNwYWNlOmF1dG87DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGhDeFNwTWlkZGxlLCBs aS5Nc29MaXN0UGFyYWdyYXBoQ3hTcE1pZGRsZSwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGhDeFNwTWlk ZGxlDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206 MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNv LWFkZC1zcGFjZTphdXRvOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoQ3hTcExhc3QsIGxpLk1zb0xpc3RQ YXJhZ3JhcGhDeFNwTGFzdCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGhDeFNwTGFzdA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6MzQ7DQoJbXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbWFyZ2luLXRv cDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4t bGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCW1zby1hZGQtc3BhY2U6YXV0 bzsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm O30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0 eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2lu ZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N CnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw LjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFy Z2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21z by1saXN0LWlkOjE3NjM4ODIyNjsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10 ZW1wbGF0ZS1pZHM6LTc3ODUzODU4MiAxNTM1MDA5ODMyIDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4 Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0 IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1mb250 LWZhbWlseTpDYWxpYnJpO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDps ZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlz dCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTow Y207fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlNWIiBsaW5rPSIjMDU2M0Mx IiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPkhpLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+SSBkaXNsaWtl IGhhdmluZyBhIGRvY3VtZW50IChldmVuIGEgaW50ZXJuZXQtZHJhZnQgd2l0aCBub24tcmVjb21t ZW5kZWQgY2lwaGVyIHN1aXRlcykgdGhhdCBraW5kIG9mIGltcGxpZXMgdGhhdCBjb25maWRlbnRp YWxseSBuZWVkcyB0byBiZSBkaXNhYmxlZCBmb3IgbG93IGxhdGVuY3kuIEVzcGVjaWFsbHkgYXMg dGhlIHN1Z2dlc3RlZCBjaXBoZXIgc3VpdGVzIHdvdWxkIGluY3JlYXNlDQogbGF0ZW5jeSBpbiBh IGxvdCBvZiBjYXNlcy4gQW55Ym9keSBnb29nbGluZyAob3IgRHVja0R1Y2tHb2luZykg4oCcVExT 4oCdIGFuZCDigJxsb3cgbGF0ZW5jeeKAnSBpcyBub3cgbGlrZWx5IHRvIGZpbmQgdGhpcyBkb2N1 bWVudOKApjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+SXJyZXNwZWN0aXZlbHkgb2Ygd2hhdCBoYXBwZW5z IHdpdGggdGhpcyBkb2N1bWVudCwgSSBzdWdnZXN0IGVpdGhlcjo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBjbSIgdHlwZT0iZGlzYyI+ DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGhDeFNwRmlyc3QiIHN0eWxlPSJtYXJnaW4tbGVm dDowY207bXNvLWFkZC1zcGFjZTphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxzcGFu IGxhbmc9IkVOLUdCIj5SZW1vdmluZyBhbnkgY2xhaW1zIGFib3V0IGxvdyBsYXRlbmN5LjxvOnA+ PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoQ3hTcExhc3QiIHN0 eWxlPSJtYXJnaW4tbGVmdDowY207bXNvLWFkZC1zcGFjZTphdXRvO21zby1saXN0OmwwIGxldmVs MSBsZm8xIj4NCjxzcGFuIGxhbmc9IkVOLUdCIj5EZXNjcmliZSBleGFjdGx5IHdoaWNoIGNhc2Vz IHRoZSBzdWdnZXN0ZWQgY2lwaGVyIHN1aXRlcyBwcm92aWRlIHNpZ25pZmljYW50bHkgbG93ZXIg bGF0ZW5jeS48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPihUaGUgbnVtYmVycyBJIHBvc3RlZCB5 ZXN0ZXJkYXkgZm9yIDwvc3Bhbj4NCjxzcGFuIGxhbmc9IkVOLUdCIj5hZXMxMjhnY212MSB3YXMg YWNjaWRlbnRseSB0YWtlbiBmcm9tIENvcnRleC1BNTcsIHRoZSBjb3JyZWN0IG51bWJlcnMgZm9y IENvcnRleC1BNSBhcmUNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+Wzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1HQiI+MTg2LjExLCAxOTMuOTQsIDIwMy4xMV0sIGJ1dCB0aGF0IGlzIHN0aWxsIGxp a2VseSBhIGxpdHRsZSBiaXQgZmFzdGVyIHRoYW4gSE1BQy1TSEEtMjU2KS48L3NwYW4+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5Kb2huPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9y OmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Nv bG9yOmJsYWNrIj5Kb2huIE1hdHRzc29uICZsdDtqb2huLm1hdHRzc29uQGVyaWNzc29uLmNvbSZn dDs8YnI+DQo8Yj5EYXRlOiA8L2I+V2VkbmVzZGF5LCAyNyBGZWJydWFyeSAyMDE5IGF0IDEzOjIz PGJyPg0KPGI+VG86IDwvYj5Ub255IFB1dG1hbiAmbHQ7VG9ueS5QdXRtYW5AZHlzb24uY29tJmd0 OywgSmFjayBWaXNva3kgJmx0O2ptdmlzb2t5QHJhLnJvY2t3ZWxsLmNvbSZndDs8YnI+DQo8Yj5D YzogPC9iPiZxdW90O1RMU0BpZXRmLm9yZyZxdW90OyAmbHQ7dGxzQGlldGYub3JnJmd0Ozxicj4N CjxiPlN1YmplY3Q6IDwvYj5SZTogW1RMU10gQXV0aGVudGljYXRpb24gT25seSBDaXBoZXJzdWl0 ZXMgUkZDPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5IaSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPlRoZSBkb2N1bWVu dCByZXBlYXRzIHRoZSByZXF1aXJlbWVudCBvZiBsb3cgbGF0ZW5jeSBzZXZlcmFsIHRpbWVzLiBJ dCB3b3VsZCBiZSBpbnRlcmVzdGluZyB0byBrbm93IHdoaWNoIHBsYXRmb3Jtcy9uZXR3b3Jrcy9k ZXBsb3ltZW50cyB5b3UgaGF2ZSBpbiBtaW5kLiBNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgSE1B Qy1TSEEtMjU2IG9ubHkgaGF2ZSBiZXR0ZXIgbGF0ZW5jeQ0KIHRoYW4gQUVTIG9uIGEgbGl0dGxl IGJpdCBsb25nZXIgbWVzc2FnZXMgd2hlcmUgdGhlIGxhcmdlciBibG9jayBzaXplIG1hdHRlcnMu IFNob3J0IG1lc3NhZ2VzIGFyZSBjb21tb24gaW4gbWFueSBJb1QgZGVwbG95bWVudHMuIExvb2tp bmcgZS5nLiBhdCB0aGUgYmVuY2htYXJrcyBhdCBodHRwczovL2JlbmNoLmNyLnlwLnRvIGZvciAm cXVvdDthcm1lYWJpOyBDb3J0ZXgtQTUgKDQxN2ZjMDUxKSZxdW90OyBvbiA2NCBieXRlIG1lc3Nh Z2VzLCBTSEEtMjU2IGFsb25lDQogcmVxdWlyZXMgc2lnbmlmaWNhbnRseSBtb3JlIGN5Y2xlcyB0 aGFuIEFFUy1HQ00gZm9yIDY0IGJ5dGUgbWVzc2FnZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5DeWNs ZXMvYnl0ZSBmb3IgNjQgYnl0ZXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+ODYuMTQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg ODYuNzMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOTMuNTkmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgc2hhMjU2PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5DeWNsZXMvYnl0ZSBmb3IgNjQmIzQzOzAgZW5j cnlwdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIj4yNC4yMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAyNC4yMCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAyNC4zNCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhZXMxMjhnY212MTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiI+T24gbW9yZSBjb25zdHJhaW5lZCBwcm9jZXNzb3JzIHN1Y2ggYXMg dGhlIENvcnRleC1NMCwgQUVTMTI4LUNDTSBhbHNvIHNlZW1zIHRvIGhhdmUgbG93ZXIgbGF0ZW5j eSB0aGFuIEhNQUMtU0hBLTI1NiBvbiBzaG9ydCBtZXNzYWdlcyAoMzc2NzcgY3ljbGVzIHZzLiA0 ODkyNCBjeWNsZXMpDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Imh0dHBzOi8v Z2l0aHViLmNvbS9jdHovY2lmcmEiPmh0dHBzOi8vZ2l0aHViLmNvbS9jdHovY2lmcmE8L2E+LiBP biBsb25nZXIgbWVzc2FnZXMsDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPkhNQUMtU0hBLTI1 NiBsaWtlbHkgaGF2ZSBsb3dlciBsYXRlbmN5IChodHRwczovL2NzcmMubmlzdC5nb3YvY3NyYy9t ZWRpYS9ldmVudHMvbGlnaHR3ZWlnaHQtY3J5cHRvZ3JhcGh5LXdvcmtzaG9wLTIwMTUvZG9jdW1l bnRzL3ByZXNlbnRhdGlvbnMvc2Vzc2lvbjctdmluY2VudC5wZGYpLiBOb3RlIHRoYXQgdGhpcyBw ZGYgc2hvd3MgdGltaW5nIGZvciBTSEEtMjU2LCBub3QgSE1BQy1TSEEtMjU2Ljwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiI+SW5jcmVhc2luZyB0aGUgdGFnIHNpemUgZnJvbSA4IGJ5dGVzIChDQ01fOCkgb3Ig MTYgKEdDTSkgdG8gMzIgb3IgNjQgbWF5IGFsc28gaW5jcmVhc2UgdGhlIGxhdGVuY3kgYXMgdGhl c2UgYWRkaXRpb25hbCBieXRlcyBoYXZlIHRvIGJlIHRyYW5zbWl0dGVkLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiI+L0pvaG48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPlRMUyAmbHQ7dGxzLWJvdW5jZXNAaWV0Zi5v cmcmZ3Q7IG9uIGJlaGFsZiBvZiBUb255IFB1dG1hbiAmbHQ7VG9ueS5QdXRtYW5AZHlzb24uY29t Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5XZWRuZXNkYXksIDI3IEZlYnJ1YXJ5IDIwMTkgYXQgMTE6 MTc8YnI+DQo8Yj5UbzogPC9iPkphY2sgVmlzb2t5ICZsdDtqbXZpc29reUByYS5yb2Nrd2VsbC5j b20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDtUTFNAaWV0Zi5vcmcmcXVvdDsgJmx0O3Rsc0Bp ZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtUTFNdIEF1dGhlbnRpY2F0aW9u IE9ubHkgQ2lwaGVyc3VpdGVzIFJGQzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRha2Ugbm8gcG9zaXRpb24gb24gd2hldGhlciB0aGlzIGlz IGEgZ29vZCBpZGVhIG9yIG5vdC4gUmVnYXJkaW5nIHRoZSBkcmFmdCBpdHNlbGYsIEkgd2FzIGV4 cGVjdGluZyB0byBzZWUgYSBjbGVhciBkZWZpbml0aW9uIG9mIHRoZSBpbnRlZ3JpdHkgY2hlY2sg Y29tcHV0YXRpb24gaW4gdGVybXMgb2YgYW4gQUVBRC1FbmNyeXB0IGNvbXB1dGF0aW9uLi4gU29t ZXRoaW5nIGFsb25nIHRoZSBsaW5lcyBvZjo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyBBRUFELUVuY3J5cHQtSE1BQyh3cml0ZV9rZXksIG5vbmNlLCBhZGRpdGlv bmFsX2RhdGEsIHBsYWludGV4dCkgPQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtwbGFpbnRleHQgfHwgSE1BQyh3cml0ZV9rZXks IG5vbmNlIHx8IGFkZGl0aW9uYWxfZGF0YSB8fCBwbGFpbnRleHQpPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkluIHBhcnRpY3VsYXIsIEFJVUksIG5vbmNlIG11c3QgYmUgaW5jbHVkZWQgdG8gcHJl dmVudCByZXBsYXkgYXR0YWNrcy4gQWxzbyBpbmNsdWRlIE5fTUlOID0gTl9NQVggPSA4IGJ5dGVz LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSBUb255PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNh bnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPiBU TFMgW21haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SmFj ayBWaXNva3k8YnI+DQo8Yj5TZW50OjwvYj4gMjYgRmVicnVhcnkgMjAxOSAyMDo1NDxicj4NCjxi PlRvOjwvYj4gdGxzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtFeHRlcm5hbCBNYWls XSBbVExTXSBBdXRoZW50aWNhdGlvbiBPbmx5IENpcGhlcnN1aXRlcyBSRkM8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQi PjxzcGFuIGxhbmc9IkVOLVVTIj5UTFMgQ29sbGVhZ3VlcywgPC9zcGFuPg0KPG86cD48L286cD48 L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIGxh bmc9IkVOLVVTIj5JZiB5b3UgcmVjYWxsIHdlIGRpc2N1c3NlZCBhIGRyYWZ0IGZvciBhdXRoZW50 aWNhdGlvbiBvbmx5IGNpcGhlcnN1aXRlcyBvdmVyIGVtYWlsIGJhY2sgaW4gQXVndXN0IG9mIDIw MTguJm5ic3A7IFdlJ3ZlIHNpbmNlIG1hZGUgc29tZSB1cGRhdGVzIHRvIHRoYXQgZHJhZnQuJm5i c3A7IFdlIGFsc28gaGF2ZSBnb3R0ZW4gSUFOQSBhc3NpZ25tZW50cyB0bw0KIHRoZSBhdXRoZW50 aWNhdGlvbiBvbmx5IGNpcGhlcnN1aXRlcyBmb3IgVExTIDEuMyBhbmQgaGF2ZSB1cGRhdGVkIHRo ZSBkcmFmdCB0byByZWZsZWN0IHRoZSBuZXcgYXNzaWdubWVudHMuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBs YW5nPSJFTi1VUyI+VG8gdGhhdCBleHRlbnQsIGFzIHRoZSBJb1QgY29tbXVuaXR5IGlzIGxvb2tp bmcgdG8gYWRvcHQgdGhlc2UgY2lwaGVyc3VpdGVzLCB3ZSB3b3VsZCBsaWtlIHRvIHNvbGljaXQg cmV2aWV3IG9mIHRoZSBkcmFmdDo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFy Z2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsm bmJzcDsmbmJzcDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowY207 bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNhbXdp bmdldC10bHMtdHMxMy1tYWNjaXBoZXJzdWl0ZXMtMDIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1jYW13aW5nZXQtdGxzLXRzMTMtbWFjY2lwaGVyc3VpdGVzLTAyPC9hPjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAw MDFwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxz cGFuIGxhbmc9IkVOLVVTIj5hbmQgcmVxdWVzdCB0aGF0IGl0IGJlIHB1Ymxpc2hlZCBhcyBpbmZv cm1hdGlvbmFsIGRyYWZ0IGdpdmVuIHRoYXQgdGhlIElvVCBmb3J1bXMgYXJlIGxvb2tpbmcgdG8g YWRvcHQgaXRzIHVzZSBhbmQgdGhlIGRyYWZ0IGNhbiBzZXJ2ZSBhcyB0aGUgZ3VpZGUgZm9yIHVz ZSBhbmQgaW50ZXJvcGVyYWJpbGl0eS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoYW5rcyBhbmQgQmVz dCBSZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+LS1KYWNrIChhbmQgTmFuY3kpPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0 ZXh0LWF1dG9zcGFjZTpub25lIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwgTmFycm93JnF1b3Q7LHNhbnMtc2VyaWYi PiZuYnNwOzwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+RHlzb24gVGVjaG5vbG9neSBMaW1p dGVkLCBjb21wYW55IG51bWJlciAwMTk1OTA5MCwgVGV0YnVyeSBIaWxsLCBNYWxtZXNidXJ5LCBT TjE2IDBSUCwgVUsuDQo8YnI+DQpUaGlzIG1lc3NhZ2UgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0 aGUgYWRkcmVzc2VlIGFuZCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24uIElm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWVzc2FnZSBpbiBlcnJvciwgcGxlYXNlIGltbWVkaWF0 ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgaXQsIGFuZCBkbyBub3QgdXNlLCBjb3B5IG9yIGRp c2Nsb3NlIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtZXNzYWdlDQogb3IgaW4g YW55IGF0dGFjaG1lbnQuIDxicj4NCkR5c29uIG1heSBtb25pdG9yIGVtYWlsIHRyYWZmaWMgZGF0 YSBhbmQgY29udGVudCBmb3Igc2VjdXJpdHkgJmFtcDsgdHJhaW5pbmcuIDwvc3Bhbj4NCjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_EB6FED0C59C9474F817EF85EB5835CB4ericssoncom_-- From nobody Thu Feb 28 08:56:35 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 41917130EE7; Thu, 28 Feb 2019 08:56:21 -0800 (PST) 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.92.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <155137298119.28625.7551218348811010685@ietfa.amsl.com> Date: Thu, 28 Feb 2019 08:56:21 -0800 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-tls13-cert-with-extern-psk-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 16:56:23 -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 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key Author : Russ Housley Filename : draft-ietf-tls-tls13-cert-with-extern-psk-00.txt Pages : 10 Date : 2019-02-28 Abstract: This document specifies a TLS 1.3 extension that allows a server to authenticate with a combination of a certificate and an external pre- shared key (PSK). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-tls13-cert-with-extern-psk-00 https://datatracker.ietf.org/doc/html/draft-ietf-tls-tls13-cert-with-extern-psk-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 28 10:09: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 AFDF8130F82 for ; Thu, 28 Feb 2019 10:09:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ra.rockwell.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 YHJeEokJvjby for ; Thu, 28 Feb 2019 10:09:46 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0610.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe46::610]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 404CE130F7E for ; Thu, 28 Feb 2019 10:09:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ra.rockwell.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tJbB46KNMkDmchEwTQGfMJDlUDkHyEmk3fBtWvI0JIc=; b=dBa8VT6rryk/pZGmrFe+LxYAUX4LoPeNMx76kxcXagsYo2UihlUVM2U/I8hjO1RyuURpk71ZQo6JyM3twHfygHVngqBiW8RuiVzgygXICrRWeXEEsun0GlGcv1TFgzxfN5KJChGQDvcAE/vmTFt5kH9B0YjKtOq1DWDkpXQixDM= Received: from BN6PR2201MB1092.namprd22.prod.outlook.com (10.174.88.29) by BN6PR2201MB1012.namprd22.prod.outlook.com (10.174.88.38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.15; Thu, 28 Feb 2019 18:09:35 +0000 Received: from BN6PR2201MB1092.namprd22.prod.outlook.com ([fe80::dd5e:b340:8fa8:b113]) by BN6PR2201MB1092.namprd22.prod.outlook.com ([fe80::dd5e:b340:8fa8:b113%5]) with mapi id 15.20.1665.015; Thu, 28 Feb 2019 18:09:35 +0000 From: Jack Visoky To: Eric Rescorla CC: "tls@ietf.org" Thread-Topic: EXTERNAL: Re: [TLS] Authentication Only Ciphersuites RFC Thread-Index: AdTOFIIaiE+qoBOKQdSotuuQ5A30qAAEXjYAACu+W6AAJYV0AAAJXGeA Date: Thu, 28 Feb 2019 18:09:34 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jmvisoky@ra.rockwell.com; x-originating-ip: [205.175.250.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 57f8aa9c-3014-4075-6372-08d69da7e54b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7153060)(7193020); SRVR:BN6PR2201MB1012; x-ms-traffictypediagnostic: BN6PR2201MB1012: x-ms-exchange-purlcount: 2 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtCTjZQUjIyMDFNQjEwMTI7MjM6VXQvTGxPeDU3bkowMXBKbFVWbFJCZzJl?= =?utf-8?B?ZHZTRFpiTEdodG9UcDAwdXNWbG1TNTZsY2F6aG9FbTQ3UmxSR051V3dGUUh6?= =?utf-8?B?YmlIMFNTMG9mbWN5cmdIVW0zRlJka1NSRkJZUlkydHI3a1FkKzJvYUlLWklW?= =?utf-8?B?eGhackhxTXU1THl4U3I5T3FlNDBOckNYL0puVzNiT1IybzF3dWdicGE1bXJU?= =?utf-8?B?b3VvN3pPNTZFN2ExcmROaUhOTGkwRFRJT2FBMXJJa052bkNOL1RhcDNQL2tR?= =?utf-8?B?UUN1azFJbGJvR0tCM1V1d1dvL0N5cUMrMmxmTEdHZHRDK1hIck94aisvbHl3?= =?utf-8?B?WEZYZW5KZ1J0NEdpUG8ybXZRdFZteWhnNmxpZEFjdXZpTTh0cGtzQ2piVVY4?= =?utf-8?B?K3pGRXBUL29rZlFDb0o1amlGK0JaYnZXMklza3haVzNNUzQ2VGtZREcxUExl?= =?utf-8?B?VWJEVFNqSFhnS2pxb09Ua3JpUXNwU0g5UnAyWnQzam9neCtIRkphQXNiNkpT?= =?utf-8?B?eDNyMFpySnkvS2o0eFNjZVhEcU9xdjA5dlNkWE9oWmhnYlIxaWppakhHM3hQ?= =?utf-8?B?OHJNMmFyS2UwOE4zQWw3NUcraXZjTnE3UGZjNTlFa1g5ZVlwSFRZV3pwRENx?= =?utf-8?B?M1VQMVZmdWtIekVJeVYzc0hBTGc2VTNCVGpIUzZzYW1rTlh0ZzNWbXlJUjlW?= =?utf-8?B?OTlvRHRWa2NoQ0tlY3UrNjUvY0dRNDM2bkV5bWU5QlJ5eGpoSGdiMVZEQmcw?= =?utf-8?B?d3dvMC8wYXJXRHhDZVAyNUxwdVFJd3F3cExLOWFJMHFXOS9sMVgzOWZMcFlQ?= =?utf-8?B?dkk2UG9WVTZDYnlUdWRHajFrTVA5S1VYTUswNExNaFR5Y1crWXd3cERuanlp?= =?utf-8?B?WVpJbG13S0huNjYxOVpLcytETnVFKy9PRmNGT0ZkekpaWlRyS1ZQMythSjlj?= =?utf-8?B?RWtZS0RUdDEvamVlMk84RTV3bUl6OGxkazA4OVd3b09PT0RUVjg1a1hYbGtM?= =?utf-8?B?Lzl4VFRaYkJJRFhGK0s4MU9oWmRYdXRGa0s1bkdtSTRyK1lMRW1SRVdSbXYr?= =?utf-8?B?UWNFSkhHaEZmRGQ4WGZ2NXIra21yZGJGVUNkM2FCdVhhS1hhdkRzQTN0Qm5q?= =?utf-8?B?WnZma0J5VmtoTFZ2UTRUdk0rUjNSalVHQURBSHRjNi9WS3MvM3dDZUN6Tjg3?= =?utf-8?B?RmoyaHBpRVFITlNOWjBPREU4VE5TVnh1cWtUZ0xDbGhCZEdEWEtwaVJPK0U3?= =?utf-8?B?NDFlNktjMm5ZRTRiYjNtS09pRlUyYjVwaTI0cUtiWGFibTlBRXlMQnZySm9o?= =?utf-8?B?Ym1kaWpCdzBzOWtSem9henVVTWEwZk51L0RIN044d0Y4akVqWWZ1L2NhdGlN?= =?utf-8?B?QmRlNmowcFlXTXl3ZHhaemt0OWdYU3JXbm94MlBINFN2a0pXN2ZrN0h1dEI1?= =?utf-8?B?b1BkK3JXUnNrTG1obVRSNjdyYkRtVTRUQUFja3cwY2VsaTNCMTBWKzAvbDdh?= =?utf-8?B?S0d6eUovNmVaR3JMdUZ6OWZxTE9hZVF6VVBCMUJtcmRadmdVbG5Md3NGZHdp?= =?utf-8?B?SXFhWTlyTkcyV2EyVzRkTjVkR3FsZjNKMkNJNDNLNVE5My83TjNveVZNU0Yy?= =?utf-8?B?VnNnMXpBbHhPOStxTFkrR2dLSFQxYTdrNTIrSjhDNHpmaWRvNFVPSStWdG5G?= =?utf-8?B?WTNmZmpJVjcydkcwVDYrRUxwdUVqNHhLb0RPUFVhdzhhK2xRSmtNYUxDOVZK?= =?utf-8?B?bFlKazdBZWZHYnIrRkVucUVYNFdLOFFqZWxjbHVtMU1uU3JZN2Jac0lFRUhn?= =?utf-8?B?akkvVktXYUQwU3FEQmtyMVdha3RRUE5aSFM1dDJSSlQ3SmJodmRyNWxBWUJz?= =?utf-8?B?NU5RYmh4TVRTVlFDVjI5dDk5Z2hsazY3OVVMcjlOVk1JVHphSENzT0lPTGJk?= =?utf-8?B?YVVHSGZYa3cwUnc9PQ==?= x-microsoft-antispam-prvs: x-forefront-prvs: 0962D394D2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(376002)(366004)(39860400002)(346002)(396003)(51914003)(199004)(189003)(81156014)(3846002)(86362001)(5024004)(790700001)(6116002)(14454004)(4326008)(8676002)(5070765005)(93886005)(99286004)(6246003)(256004)(14444005)(105586002)(25786009)(11346002)(7736002)(7696005)(106356001)(71200400001)(236005)(186003)(55016002)(9686003)(54896002)(446003)(8936002)(26005)(97736004)(71190400001)(476003)(6306002)(53936002)(6916009)(52536013)(6436002)(76176011)(5660300002)(74316002)(229853002)(53546011)(6506007)(478600001)(486006)(966005)(81166006)(2906002)(316002)(102836004)(33656002)(68736007)(606006)(66066001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR2201MB1012; H:BN6PR2201MB1092.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ra.rockwell.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: blz837aQ93ljYPMchEHWI03WAG5+jmONDmNTENCOcV9Cvv9TMnkFZa4PoE+BiUmqV1KK6kWVHjg2J/i4kzc3m2IBTy8IHrIOg+9NCj7L7T2Guwy46a+m8dfT7/lWgNsUyfw0QU2mFE9zh8wsoOm9lursDlu3zi2DlM47lBq4OYhPDykJoPia0uLzPBFDYK5E9plA4k1JHzZr4kpkzcXReb4vlKwLOvttG5kipWPkQPKll+kqvMZdUg5jELMOMoOfGOYt9KQWDQf0ECyCT0NFETp3uWh9RFbDHu9VgekuT6R1WNI1NQlJGXoAOvDWkOvRu7LO6oPWiTyHVYspVBWV3j8JDrQvXGetCcjYXCGF1BEoJLx/8NoohXO2MgXBg88ZyPagqggmb0DphC3rQ8T69lmydRhO7uYrC756yNPPUXo= Content-Type: multipart/alternative; boundary="_000_BN6PR2201MB10922700366223287BAC29F199750BN6PR2201MB1092_" MIME-Version: 1.0 X-OriginatorOrg: ra.rockwell.com X-MS-Exchange-CrossTenant-Network-Message-Id: 57f8aa9c-3014-4075-6372-08d69da7e54b X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2019 18:09:34.9624 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 855b093e-7340-45c7-9f0c-96150415893e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR2201MB1012 Archived-At: Subject: Re: [TLS] EXTERNAL: Re: Authentication Only Ciphersuites RFC 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, 28 Feb 2019 18:09:50 -0000 --_000_BN6PR2201MB10922700366223287BAC29F199750BN6PR2201MB1092_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRXJpYyAoYW5kIG90aGVycyksDQoNClRoYW5rcyBmb3IgdGhlIGZlZWRiYWNrIG9uIHRoaXMu ICBJ4oCZbGwgbmVlZCB0byB0YWxrIHdpdGggTmFuY3kgYnV0IEkgdGhpbmsgaXTigJlzIGJlY29t ZSBwcmV0dHkgY2xlYXIgdGhhdCB0aGlzIGRyYWZ0IHNob3VsZCBub3QgYmVjb21lIGEgVExTLVdH IGl0ZW0uICBUaGF0IHNhaWQsIEkgYXBwcmVjaWF0ZSB0aGUgZmVlZGJhY2sgdGh1cyBmYXIgYW5k IHdlbGNvbWUgZnVydGhlciBkaXNjdXNzaW9uIGZyb20gdGhvc2UgaW4gdGhpcyBncm91cC4NCg0K VGhhbmtzLA0KDQotLUphY2sNCg0KRnJvbTogRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPg0K U2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDI4LCAyMDE5IDg6NDAgQU0NClRvOiBKYWNrIFZpc29r eSA8am12aXNva3lAcmEucm9ja3dlbGwuY29tPg0KQ2M6IHRsc0BpZXRmLm9yZw0KU3ViamVjdDog UmU6IEVYVEVSTkFMOiBSZTogW1RMU10gQXV0aGVudGljYXRpb24gT25seSBDaXBoZXJzdWl0ZXMg UkZDDQoNCkphY2ssDQoNClRoZXJlJ3MgYSBidW5jaCBoZXJlIHRvIHVucGFjay4NCg0KRmlyc3Qs IHRoZSBwdXJwb3NlIG9mIHRoZSBjdXJyZW50IHJlZ2lzdHJ5IHN0cnVjdHVyZSB3YXMgdG8gYWxs b3cgY29kZSBwb2ludCByZWdpc3RyYXRpb24gd2l0aG91dCBmb3JjaW5nIHRoZSBUTFMgV0cgdG8g c3BlbmQgdGltZSBvbiBkb2N1bWVudHMgdGhhdCBkb24ndCBnZW5lcmFsbHkgbWVldCBpdHMgZ29h bHMuIFRoaXMgc2VlbXMgbGlrZSBvbmUgc3VjaCBkb2N1bWVudC4NCg0KV1JUIHRvIHlvdXIgcG9p bnRzIGFib3V0IHRoZSBiZW5lZml0cyBvZiBSRkMgc3RhdHVzOg0KDQoxLiBIYXZpbmcgdGhpcyBh cHByb3ZlZCB0aHJvdWdoIHRoZSBJRVRGIHByb2Nlc3MgdnMsIGp1c3QgSVNFIHdvdWxkIGJlIGJl bmVmaWNpYWwgdG8gdGhvc2Ugd2lzaGluZyB0byBhZG9wdC4gV2h5IHdvdWxkIHRoaXMgYmUgdGhl IGNhc2U/IFRoZSBvbmx5IHJlYXNvbiBJIGNhbiB0aGluayBvZiBpcyB0aGF0IGhhdmluZyBpdCBi ZSBhbiBJRVRGIGRvY3VtZW50IHdvdWxkIGltcGx5IHRoYXQgdGhlIElFVEYgdGhvdWdodCBpdCB3 YXMgT0suIEJ1dCB0aGlzIGlzIHRoZSBzaXR1YXRpb24gd2UgYXJlIHRyeWluZyB0byBhdm9pZCB3 aXRoIHRoZSBOb3QgUmVjb21tZW5kZWQgbGFiZWwuDQoyLiBIYXZpbmcgdGhpcyBnbyB0aHJvdWdo IHRoZSBJRVRGIHByb2Nlc3Mgd291bGQgZ2V0IHlvdSBjb21tdW5pdHkgcmV2aWV3LiBBZ2Fpbiwg aGVyZSwgdGhlIGlkZWEgd2l0aCB0aGUgbmV3IHByb2Nlc3MgaXMgdGhhdCB3ZSBkb24ndCBmb3Jj ZSB0aGUgVExTIFdHIHRvIGRvIHRoYXQgd29yay4NCg0KT2J2aW91c2x5LCBpbmRpdmlkdWFscyBz aG91bGQgZmVlbCBmcmVlIHRvIHJldmlldyB0aGlzIGRvY3VtZW50IG9yIG5vdCBhcyB0aGV5IHBs ZWFzZSwgYnV0IEknbSBub3Qgc2VlaW5nIGFueSBjb21wZWxsaW5nIHJlYXNvbiB3aHkgVExTLVdH IHNob3VsZCB0YWtlIGl0IG9uLg0KDQotRWtyDQoNCg0KT24gV2VkLCBGZWIgMjcsIDIwMTkgYXQg MTE6NDkgQU0gSmFjayBWaXNva3kgPGptdmlzb2t5QHJhLnJvY2t3ZWxsLmNvbTxtYWlsdG86am12 aXNva3lAcmEucm9ja3dlbGwuY29tPj4gd3JvdGU6DQpIaSBFcmljLA0KDQpPdXIgZ29hbCBpcyB0 byBoYXZlIGFuIFJGQyBwdWJsaXNoZWQgYXMgSW5mb3JtYXRpb25hbCBhbmQgd2l0aCB0aGUgTm90 IFJlY29tbWVuZGVkIHN0YXR1cy4gIFdlIGZlbHQgaGF2aW5nIHRoaXMgYXBwcm92ZWQgdGhyb3Vn aCB0aGUgSUVURiBwcm9jZXNzIHZzIGp1c3QgSVNFIHdvdWxkIGJlIGJlbmVmaWNpYWwgdG8gdGhv c2Ugd2lzaGluZyB0byBhZG9wdCwgYW5kIGdldHRpbmcgY29tbXVuaXR5IHJldmlldyBpcyBhbHNv IGhlbHBmdWwgdG8gdXMgYW5kIHRob3NlIHdlIHJlcHJlc2VudC4NCg0KSSBzdXBwb3NlIG9uZSBx dWVzdGlvbiBpcyB3aGV0aGVyIG9yIG5vdCB3ZSBuZWVkIHRoaXMgdG8gYmUgYSBXRyBpdGVtIG9y IGlmIHdlIGNhbiBzb2xpY2l0IGluZGVwZW5kZW50IHNoZXBoZXJkaW5nIGZyb20gYSBjaGFpciBv ciBBRCB0byBnZXQgdG8gdGhlIGdvYWwgb2YgYW4gSW5mb3JtYXRpb24gUkZDIHdpdGggTm90IFJl Y29tbWVuZGVkIHN0YXR1cy4NCg0KQWxzbywgSSBhcG9sb2dpemUgaWYgSeKAmXZlIG1pc3VuZGVy c3Rvb2Qgb3IgbWlzc3RhdGVkIGFueXRoaW5nLCBJ4oCZbSBuZXcgdG8gdGhlIElFVEYgcHJvY2Vz c2VzIHNvIGNlcnRhaW5seSBjb3VsZCBoYXZlIG1hZGUgYSBtaXN0YWtlLg0KDQpUaGFua3MsDQoN Ci0tSmFjaw0KDQpGcm9tOiBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb208bWFpbHRvOmVrckBy dGZtLmNvbT4+DQpTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAyNiwgMjAxOSA1OjUzIFBNDQpUbzog SmFjayBWaXNva3kgPGptdmlzb2t5QHJhLnJvY2t3ZWxsLmNvbTxtYWlsdG86am12aXNva3lAcmEu cm9ja3dlbGwuY29tPj4NCkNjOiB0bHNAaWV0Zi5vcmc8bWFpbHRvOnRsc0BpZXRmLm9yZz4NClN1 YmplY3Q6IEVYVEVSTkFMOiBSZTogW1RMU10gQXV0aGVudGljYXRpb24gT25seSBDaXBoZXJzdWl0 ZXMgUkZDDQoNCg0KW1VzZSBjYXV0aW9uIHdpdGggbGlua3MgJiBhdHRhY2htZW50c10NCg0KDQoN Cg0KT24gVHVlLCBGZWIgMjYsIDIwMTkgYXQgMTI6NTQgUE0gSmFjayBWaXNva3kgPGptdmlzb2t5 QHJhLnJvY2t3ZWxsLmNvbTxtYWlsdG86am12aXNva3lAcmEucm9ja3dlbGwuY29tPj4gd3JvdGU6 DQoNClRMUyBDb2xsZWFndWVzLA0KDQpJZiB5b3UgcmVjYWxsIHdlIGRpc2N1c3NlZCBhIGRyYWZ0 IGZvciBhdXRoZW50aWNhdGlvbiBvbmx5IGNpcGhlcnN1aXRlcyBvdmVyIGVtYWlsIGJhY2sgaW4g QXVndXN0IG9mIDIwMTguICBXZSd2ZSBzaW5jZSBtYWRlIHNvbWUgdXBkYXRlcyB0byB0aGF0IGRy YWZ0LiAgV2UgYWxzbyBoYXZlIGdvdHRlbiBJQU5BIGFzc2lnbm1lbnRzIHRvIHRoZSBhdXRoZW50 aWNhdGlvbiBvbmx5IGNpcGhlcnN1aXRlcyBmb3IgVExTIDEuMyBhbmQgaGF2ZSB1cGRhdGVkIHRo ZSBkcmFmdCB0byByZWZsZWN0IHRoZSBuZXcgYXNzaWdubWVudHMuDQoNClRvIHRoYXQgZXh0ZW50 LCBhcyB0aGUgSW9UIGNvbW11bml0eSBpcyBsb29raW5nIHRvIGFkb3B0IHRoZXNlIGNpcGhlcnN1 aXRlcywgd2Ugd291bGQgbGlrZSB0byBzb2xpY2l0IHJldmlldyBvZiB0aGUgZHJhZnQ6DQoNCg0K DQogICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNhbXdpbmdldC10bHMtdHMx My1tYWNjaXBoZXJzdWl0ZXMtMDINCg0KDQoNCmFuZCByZXF1ZXN0IHRoYXQgaXQgYmUgcHVibGlz aGVkIGFzIGluZm9ybWF0aW9uYWwgZHJhZnQgZ2l2ZW4gdGhhdCB0aGUgSW9UIGZvcnVtcyBhcmUg bG9va2luZyB0byBhZG9wdCBpdHMgdXNlIGFuZCB0aGUgZHJhZnQgY2FuIHNlcnZlIGFzIHRoZSBn dWlkZSBmb3IgdXNlIGFuZCBpbnRlcm9wZXJhYmlsaXR5Lg0KDQpJdCBzZWVtcyB0byBtZSB0aGF0 IHRoZXJlIGZvdXIgc29tZXdoYXQgZGlzdGluY3QgcXVlc3Rpb25zOg0KDQoxLiBDb2RlIHBvaW50 cw0KMi4gRG9jdW1lbnQgbGV2ZWwgKEluZm8sIEV4cCwgUFMsIGV0Yy4pDQozLiBSZWNvbW1lbmRl ZCBzdGF0dXMNCjQuIFdHIHN0YXR1cw0KDQpGcm9tIG15IHBlcnNwZWN0aXZlLCB5b3UgaGF2ZSBj b2RlIHBvaW50cyBhbmQgeW91J3ZlIGFza2VkIGZvciBhbiBJbmZvcm1hdGlvbmFsIGRvY3VtZW50 LCBidXQgdGhhbiBjYW4gb25seSBnZXQgeW91IE5vdCBSZWNvbW1lbmRlZCwgc28gd2hhdCdzIHRo ZSB2YWx1ZSBvZiBoYXZpbmcgdGhpcyBiZSBhIFdHIGRvY3VtZW50PyBXaHkgY2FuJ3QgeW91IHN1 Ym1pdCBpdCB0byB0aGUgSVNFIG9yIGFsdGVybmF0ZWx5IGp1c3QgaGF2ZSBwZW9wbGUgcmVmZXJl bmNlIHRoZSBkcmFmdD8NCg0KLUVrcg0KDQoNClRoYW5rcyBhbmQgQmVzdCBSZWdhcmRzLA0KDQot LUphY2sgKGFuZCBOYW5jeSkNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KVExTIG1haWxpbmcgbGlzdA0KVExTQGlldGYub3JnPG1haWx0bzpUTFNA aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rscw0K --_000_BN6PR2201MB10922700366223287BAC29F199750BN6PR2201MB1092_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkFyaWFsIE5hcnJv dyI7DQoJcGFub3NlLTE6MiAxMSA2IDYgMiAyIDIgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseToiXEBEZW5nWGlhbiI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwg ZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4t dG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5nbWFpbC1tMTcyNDE2ODMwNDc2NjczOTg3NW1z Z2JvcmRlciwgbGkuZ21haWwtbTE3MjQxNjgzMDQ3NjY3Mzk4NzVtc2dib3JkZXIsIGRpdi5nbWFp bC1tMTcyNDE2ODMwNDc2NjczOTg3NW1zZ2JvcmRlcg0KCXttc28tc3R5bGUtbmFtZTpnbWFpbC1t XzE3MjQxNjgzMDQ3NjY3Mzk4NzVtc2dib3JkZXI7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJn aW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgRXJpYyAoYW5kIG90aGVycyks PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBmb3IgdGhlIGZlZWRiYWNrIG9uIHRoaXMu Jm5ic3A7IEnigJlsbCBuZWVkIHRvIHRhbGsgd2l0aCBOYW5jeSBidXQgSSB0aGluayBpdOKAmXMg YmVjb21lIHByZXR0eSBjbGVhciB0aGF0IHRoaXMgZHJhZnQgc2hvdWxkIG5vdCBiZWNvbWUgYSBU TFMtV0cgaXRlbS4mbmJzcDsgVGhhdCBzYWlkLCBJIGFwcHJlY2lhdGUgdGhlIGZlZWRiYWNrIHRo dXMgZmFyIGFuZCB3ZWxjb21lIGZ1cnRoZXIgZGlzY3Vzc2lvbiBmcm9tIHRob3NlDQogaW4gdGhp cyBncm91cC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4tLUphY2s8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IEVyaWMg UmVzY29ybGEgJmx0O2VrckBydGZtLmNvbSZndDsgPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5 LCBGZWJydWFyeSAyOCwgMjAxOSA4OjQwIEFNPGJyPg0KPGI+VG86PC9iPiBKYWNrIFZpc29reSAm bHQ7am12aXNva3lAcmEucm9ja3dlbGwuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gdGxzQGlldGYu b3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBFWFRFUk5BTDogUmU6IFtUTFNdIEF1dGhlbnRp Y2F0aW9uIE9ubHkgQ2lwaGVyc3VpdGVzIFJGQzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkphY2ssPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoZXJlJ3MgYSBidW5jaCBoZXJlIHRvIHVucGFjay48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rmlyc3QsIHRoZSBwdXJw b3NlIG9mIHRoZSBjdXJyZW50IHJlZ2lzdHJ5IHN0cnVjdHVyZSB3YXMgdG8gYWxsb3cgY29kZSBw b2ludCByZWdpc3RyYXRpb24gd2l0aG91dCBmb3JjaW5nIHRoZSBUTFMgV0cgdG8gc3BlbmQgdGlt ZSBvbiBkb2N1bWVudHMgdGhhdCBkb24ndCBnZW5lcmFsbHkgbWVldCBpdHMgZ29hbHMuIFRoaXMg c2VlbXMgbGlrZSBvbmUgc3VjaCBkb2N1bWVudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V1JUIHRvIHlvdXIgcG9pbnRzIGFib3V0IHRoZSBi ZW5lZml0cyBvZiBSRkMgc3RhdHVzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4xLiBIYXZpbmcgdGhpcyBhcHByb3ZlZCB0aHJvdWdoIHRoZSBJ RVRGIHByb2Nlc3MgdnMsIGp1c3QgSVNFIHdvdWxkIGJlIGJlbmVmaWNpYWwgdG8gdGhvc2Ugd2lz aGluZyB0byBhZG9wdC4gV2h5IHdvdWxkIHRoaXMgYmUgdGhlIGNhc2U/IFRoZSBvbmx5IHJlYXNv biBJIGNhbiB0aGluayBvZiBpcyB0aGF0IGhhdmluZyBpdCBiZSBhbiBJRVRGIGRvY3VtZW50IHdv dWxkIGltcGx5IHRoYXQgdGhlIElFVEYgdGhvdWdodA0KIGl0IHdhcyBPSy4gQnV0IHRoaXMgaXMg dGhlIHNpdHVhdGlvbiB3ZSBhcmUgdHJ5aW5nIHRvIGF2b2lkIHdpdGggdGhlIE5vdCBSZWNvbW1l bmRlZCBsYWJlbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjIuIEhhdmluZyB0aGlzIGdvIHRocm91Z2ggdGhlIElFVEYgcHJvY2VzcyB3b3VsZCBn ZXQgeW91IGNvbW11bml0eSByZXZpZXcuIEFnYWluLCBoZXJlLCB0aGUgaWRlYSB3aXRoIHRoZSBu ZXcgcHJvY2VzcyBpcyB0aGF0IHdlIGRvbid0IGZvcmNlIHRoZSBUTFMgV0cgdG8gZG8gdGhhdCB3 b3JrLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PYnZpb3VzbHksIGluZGl2aWR1YWxzIHNob3VsZCBmZWVsIGZyZWUgdG8gcmV2aWV3IHRoaXMg ZG9jdW1lbnQgb3Igbm90IGFzIHRoZXkgcGxlYXNlLCBidXQgSSdtIG5vdCBzZWVpbmcgYW55IGNv bXBlbGxpbmcgcmVhc29uIHdoeSBUTFMtV0cgc2hvdWxkIHRha2UgaXQgb24uPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ LUVrcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBX ZWQsIEZlYiAyNywgMjAxOSBhdCAxMTo0OSBBTSBKYWNrIFZpc29reSAmbHQ7PGEgaHJlZj0ibWFp bHRvOmptdmlzb2t5QHJhLnJvY2t3ZWxsLmNvbSI+am12aXNva3lAcmEucm9ja3dlbGwuY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGkgRXJpYyw8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPk91ciBnb2FsIGlzIHRvIGhhdmUgYW4gUkZDIHB1Ymxpc2hlZCBhcyBJbmZvcm1h dGlvbmFsIGFuZCB3aXRoIHRoZSBOb3QgUmVjb21tZW5kZWQgc3RhdHVzLiZuYnNwOyBXZSBmZWx0 IGhhdmluZyB0aGlzIGFwcHJvdmVkIHRocm91Z2ggdGhlIElFVEYgcHJvY2VzcyB2cyBqdXN0IElT RSB3b3VsZCBiZSBiZW5lZmljaWFsDQogdG8gdGhvc2Ugd2lzaGluZyB0byBhZG9wdCwgYW5kIGdl dHRpbmcgY29tbXVuaXR5IHJldmlldyBpcyBhbHNvIGhlbHBmdWwgdG8gdXMgYW5kIHRob3NlIHdl IHJlcHJlc2VudC4mbmJzcDsNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBzdXBwb3Nl IG9uZSBxdWVzdGlvbiBpcyB3aGV0aGVyIG9yIG5vdCB3ZSBuZWVkIHRoaXMgdG8gYmUgYSBXRyBp dGVtIG9yIGlmIHdlIGNhbiBzb2xpY2l0IGluZGVwZW5kZW50IHNoZXBoZXJkaW5nIGZyb20gYSBj aGFpciBvciBBRCB0byBnZXQgdG8gdGhlIGdvYWwgb2YgYW4gSW5mb3JtYXRpb24gUkZDIHdpdGgN CiBOb3QgUmVjb21tZW5kZWQgc3RhdHVzLiZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPkFsc28sIEkgYXBvbG9naXplIGlmIEnigJl2ZSBtaXN1bmRlcnN0b29kIG9yIG1pc3N0YXRl ZCBhbnl0aGluZywgSeKAmW0gbmV3IHRvIHRoZSBJRVRGIHByb2Nlc3NlcyBzbyBjZXJ0YWlubHkg Y291bGQgaGF2ZSBtYWRlIGEgbWlzdGFrZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRo YW5rcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0tSmFjazxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbjtib3JkZXItY29sb3I6Y3VycmVudGNvbG9yIGN1cnJlbnRj b2xvciI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPkZyb206PC9iPiBFcmljIFJlc2Nvcmxh ICZsdDs8YSBocmVmPSJtYWlsdG86ZWtyQHJ0Zm0uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZWtyQHJ0 Zm0uY29tPC9hPiZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBGZWJydWFyeSAyNiwg MjAxOSA1OjUzIFBNPGJyPg0KPGI+VG86PC9iPiBKYWNrIFZpc29reSAmbHQ7PGEgaHJlZj0ibWFp bHRvOmptdmlzb2t5QHJhLnJvY2t3ZWxsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmptdmlzb2t5QHJh LnJvY2t3ZWxsLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86dGxz QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dGxzQGlldGYub3JnPC9hPjxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBFWFRFUk5BTDogUmU6IFtUTFNdIEF1dGhlbnRpY2F0aW9uIE9ubHkgQ2lwaGVyc3Vp dGVzIFJGQzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNv bGlkICNCQjIzMjIgMi4yNXB0O3BhZGRpbmc6Mi4wcHQgMi4wcHQgMi4wcHQgMi4wcHQ7YmFja2dy b3VuZC1hdHRhY2htZW50OnNjcm9sbDtiYWNrZ3JvdW5kLXBvc2l0aW9uLXg6MCU7YmFja2dyb3Vu ZC1wb3NpdGlvbi15OjAlIj4NCjxwIGNsYXNzPSJnbWFpbC1tMTcyNDE2ODMwNDc2NjczOTg3NW1z Z2JvcmRlciIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEyLjBwdDtiYWNrZ3JvdW5kOiNFOEU4RTgiPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPltVc2UgY2F1dGlvbiB3 aXRoIGxpbmtzICZhbXA7IGF0dGFjaG1lbnRzXTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVHVlLCBGZWIgMjYsIDIwMTkgYXQgMTI6NTQgUE0g SmFjayBWaXNva3kgJmx0OzxhIGhyZWY9Im1haWx0bzpqbXZpc29reUByYS5yb2Nrd2VsbC5jb20i IHRhcmdldD0iX2JsYW5rIj5qbXZpc29reUByYS5yb2Nrd2VsbC5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFy Z2luLWJvdHRvbTo1LjBwdDtib3JkZXItY29sb3I6Y3VycmVudGNvbG9yIGN1cnJlbnRjb2xvciBj dXJyZW50Y29sb3IgcmdiKDIwNCwyMDQsMjA0KSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIHN0eWxlPSJt YXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+VExTIENvbGxlYWd1ZXMsIDxvOnA+PC9v OnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij5JZiB5 b3UgcmVjYWxsIHdlIGRpc2N1c3NlZCBhIGRyYWZ0IGZvciBhdXRoZW50aWNhdGlvbiBvbmx5IGNp cGhlcnN1aXRlcyBvdmVyIGVtYWlsIGJhY2sgaW4gQXVndXN0IG9mIDIwMTguJm5ic3A7IFdlJ3Zl IHNpbmNlIG1hZGUgc29tZSB1cGRhdGVzIHRvIHRoYXQgZHJhZnQuJm5ic3A7IFdlIGFsc28gaGF2 ZSBnb3R0ZW4gSUFOQSBhc3NpZ25tZW50cyB0byB0aGUgYXV0aGVudGljYXRpb24NCiBvbmx5IGNp cGhlcnN1aXRlcyBmb3IgVExTIDEuMyBhbmQgaGF2ZSB1cGRhdGVkIHRoZSBkcmFmdCB0byByZWZs ZWN0IHRoZSBuZXcgYXNzaWdubWVudHMuPG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2lu OjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPlRvIHRoYXQgZXh0ZW50LCBhcyB0aGUgSW9UIGNv bW11bml0eSBpcyBsb29raW5nIHRvIGFkb3B0IHRoZXNlIGNpcGhlcnN1aXRlcywgd2Ugd291bGQg bGlrZSB0byBzb2xpY2l0IHJldmlldyBvZiB0aGUgZHJhZnQ6PG86cD48L286cD48L3A+DQo8cCBz dHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPiZuYnNwOyZuYnNwOyZuYnNw OyA8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAw MDFwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWNhbXdpbmdldC10bHMtdHMxMy1tYWNjaXBoZXJzdWl0ZXMtMDIiIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2Ftd2luZ2V0 LXRscy10czEzLW1hY2NpcGhlcnN1aXRlcy0wMjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxl PSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxv OnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0 Ij5hbmQgcmVxdWVzdCB0aGF0IGl0IGJlIHB1Ymxpc2hlZCBhcyBpbmZvcm1hdGlvbmFsIGRyYWZ0 IGdpdmVuIHRoYXQgdGhlIElvVCBmb3J1bXMgYXJlIGxvb2tpbmcgdG8gYWRvcHQgaXRzIHVzZSBh bmQgdGhlIGRyYWZ0IGNhbiBzZXJ2ZSBhcyB0aGUgZ3VpZGUgZm9yIHVzZSBhbmQgaW50ZXJvcGVy YWJpbGl0eS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SXQgc2VlbXMgdG8gbWUgdGhhdCB0aGVy ZSBmb3VyIHNvbWV3aGF0IGRpc3RpbmN0IHF1ZXN0aW9uczo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjEuIENvZGUgcG9pbnRzPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjIuIERvY3Vt ZW50IGxldmVsIChJbmZvLCBFeHAsIFBTLCBldGMuKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4zLiBSZWNvbW1lbmRlZCBzdGF0dXM8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+NC4gV0cgc3Rh dHVzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5Gcm9tIG15IHBlcnNwZWN0aXZlLCB5b3UgaGF2ZSBjb2RlIHBvaW50cyBhbmQgeW91J3Zl IGFza2VkIGZvciBhbiBJbmZvcm1hdGlvbmFsIGRvY3VtZW50LCBidXQgdGhhbiBjYW4gb25seSBn ZXQgeW91IE5vdCBSZWNvbW1lbmRlZCwgc28gd2hhdCdzIHRoZSB2YWx1ZSBvZiBoYXZpbmcgdGhp cyBiZSBhIFdHIGRvY3VtZW50Pw0KIFdoeSBjYW4ndCB5b3Ugc3VibWl0IGl0IHRvIHRoZSBJU0Ug b3IgYWx0ZXJuYXRlbHkganVzdCBoYXZlIHBlb3BsZSByZWZlcmVuY2UgdGhlIGRyYWZ0PzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LUVr cjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDow aW47bWFyZ2luLWJvdHRvbTo1LjBwdDtib3JkZXItY29sb3I6Y3VycmVudGNvbG9yIGN1cnJlbnRj b2xvciBjdXJyZW50Y29sb3IgcmdiKDIwNCwyMDQsMjA0KSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPlRoYW5rcyBhbmQgQmVzdCBSZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+LS1KYWNrIChhbmQgTmFuY3kpPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCBOYXJyb3cm cXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KVExTIG1haWxpbmcgbGlzdDxicj4NCjxhIGhy ZWY9Im1haWx0bzpUTFNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5UTFNAaWV0Zi5vcmc8L2E+ PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rs czwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BN6PR2201MB10922700366223287BAC29F199750BN6PR2201MB1092_-- From nobody Thu Feb 28 10:20: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 A4915130F61 for ; Thu, 28 Feb 2019 10:19:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=ra.rockwell.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 j2UIFsrquaWg for ; Thu, 28 Feb 2019 10:19:51 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-eopbgr750071.outbound.protection.outlook.com [40.107.75.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59490130F8A for ; Thu, 28 Feb 2019 10:19:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ra.rockwell.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DhJPWBkTkZL+CmDzBxK3YAPYmT6C+/ThxMt8epFCyP8=; b=3QCQ6GIju+3jKIzc6auXnoTzb/4rIKDjF9L5/AloJuGMA26pF5lgaLnGtyAxxHObm/4mIoooVIsiKx7OwxHkUCQ2egEbNfiHsraN7BpxKN5WiIpTxNxkTMVpH3uWHM/R0M4K16XKa7Gyzksn1/71/WIGtQR/4hdPk0wYTz0mQ/c= Received: from BN6PR2201MB1092.namprd22.prod.outlook.com (10.174.88.29) by BN6PR2201MB1747.namprd22.prod.outlook.com (10.161.158.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.16; Thu, 28 Feb 2019 18:19:49 +0000 Received: from BN6PR2201MB1092.namprd22.prod.outlook.com ([fe80::dd5e:b340:8fa8:b113]) by BN6PR2201MB1092.namprd22.prod.outlook.com ([fe80::dd5e:b340:8fa8:b113%5]) with mapi id 15.20.1665.015; Thu, 28 Feb 2019 18:19:49 +0000 From: Jack Visoky To: John Mattsson CC: "tls@ietf.org" Thread-Topic: EXTERNAL: Re: [TLS] Authentication Only Ciphersuites RFC Thread-Index: AQHUzpc5W2pxSTaBS0OsWyhr6Jy/M6X1b+OAgAAUgPA= Date: Thu, 28 Feb 2019 18:19:49 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jmvisoky@ra.rockwell.com; x-originating-ip: [205.175.250.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fe7099e5-4a4c-4ebd-c11e-08d69da95357 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7153060)(7193020); SRVR:BN6PR2201MB1747; x-ms-traffictypediagnostic: BN6PR2201MB1747: x-ms-exchange-purlcount: 4 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtCTjZQUjIyMDFNQjE3NDc7MjM6dTZndTJ3MkkwMDZtdXV1Y2VycUI2ank1?= =?utf-8?B?UDZkbFF3YThWYWp1RzljSkJUdGFoNWI4NWhFU0xzcHhFOXN4ZXlodWFXemNx?= =?utf-8?B?KzY2OXlGWU9qVHFiUnhQb2p0cEE4VFdxY0FnRThvK2N5MGY0TEtEZmFsRmpC?= =?utf-8?B?MEJOWFg4dERTdEg3aWJUOWwzWVN1K05aQnV5SGpidGpUWEdHMjlHWnVqVDFW?= =?utf-8?B?Z0o5VlhTWWtjVGRTRHRZOTM2QXVOQ25IU2ZtUmRjYVRyS1FMeFlpd1gvUSs4?= =?utf-8?B?bFVkUWpyNks4Z0VDQUlPNHh3VlpweEh4aEpTcFBET2FDVEZRMzJNSWhFNVRH?= =?utf-8?B?TUJFTUFGb01FdEVTc1d3eHJIcCs1clVBWXVVWEwyRHJuUmV0UzFCRVJlVG1C?= =?utf-8?B?Q0JHRDRqclBSN3ZyR2Q5bTduNi9jRGFIalhjM3YyU3o5bnJkZDI2eUdPTlk2?= =?utf-8?B?L0hhNC9VOFlqRitTOStHL0Z1d2hTcktHSUFVdTN3ZzFxZ2JJVEpSNzZsYk5I?= =?utf-8?B?V3ZWRVg3OERneVJuTjArWk1rODIwVlI4MzNOMncvSzRBMHV4aTBSM2ZCZFBV?= =?utf-8?B?bHI1SUFUYzFZYUtLVEwySkhQZzBlWFJMOENkWjcrMmMxeEhtZU5OaDFMd0N6?= =?utf-8?B?d1d4UFJzT0FQQkgyeWFmUkJhb2FkUWpKV1JYOHMwNVZpWkcwd1JTa3d1MnVv?= =?utf-8?B?Q2hNUjI1YUJadVdlVnlvVmFQT0lzbzdZcnJxRUFHT2ZPMGcrMmlsSXIyam5o?= =?utf-8?B?RmhBbng1aE9ndExRWlV4WEttZWs1TjNNZTNkbWU4VzBQR1pySTEvQ3hKK2M1?= =?utf-8?B?QWRTWkZWMCtBN0QwSUhweTdDckg0SEVlMVFVb1lLczZnc2lRMUpEQmgwZ3ZE?= =?utf-8?B?aXZjZ2hkT2lXSWI5WWtVd2NnREdDWlFoa2h1ZXpFeGZDakR0ZzFaTkFUUGY2?= =?utf-8?B?Mko4WXYwZVBOSitxMDRmM0lrVDkxT1M2NWU4Y2dUc2xMNkU0OWtsZjArU2Np?= =?utf-8?B?eWEzbUpEK29DWi9wbS93c0Y1U2tBQUZxcTVkblVNVU9NeWs0dlVaV3haQ0Ju?= =?utf-8?B?UEhqME4xaFl5dHhiTHh2elB0OGJZbWdCNEFxNHpPeVpsN3lxeGxiMnpuM2Vy?= =?utf-8?B?MnhkMjg3dGRPYVJ6SUpiVDhPQXJ6bVZZZlRFMVZsUmI5dVNrblRqTXV0MXV1?= =?utf-8?B?MkdaV0FybWQ1anFybkt3alFBY1ZpTTRkdWgvVTBYUjE2Q3N2ZkFzdXVPMUpR?= =?utf-8?B?MC95bjdmMEpJRWs4ZVVrVWd4Q245OUlFSWthay9LWDdxbDhQMzljNXdEbWpt?= =?utf-8?B?d3VMZjVHNzF3NDNJODNOTE5WUHFLbktsM0lQQXZEOER0ZGl1UzhnL3IwQVJX?= =?utf-8?B?SVIrSzYrMFNpMDQ0NzIvZ0M1MnByZHVWeEFnSTdZaTRqNnNHSktxaDVPOVlx?= =?utf-8?B?OE1hNUdIWmdzM0R4eHhveVAzakxZRGl6c1dEbUlnb3RpOCtlUTFVcTRSRzdU?= =?utf-8?B?eHB6WjBIUElnOXhmSDBsVEFiU3ZUOXdxY2JuZlZ0RU56MzRtUHNaT0lJUWE4?= =?utf-8?B?dHpvbEt3WWJxMVQ0bWswNWptekdYZkJOeWtUSmdQSTRDbzh0T0FGUi8rVGxP?= =?utf-8?B?UnpYcVVibTdVbjhvcnc0R0k5elpaOXo1OWRPZUMxVGJDQUI0OEtaeCtTbkF6?= =?utf-8?B?YnorQ3JzK1lDSkFINm9vVm4yeG5QaTU1VjcxeE9qcUNJdDdiRkh2V1M4ZTBn?= =?utf-8?B?djhRcnpKaVVRNEpFYWVjWEsxczVEcVpwTTkrUzlLTXQwNVBYYk1wYWU0MVNi?= =?utf-8?B?VkNESWp5Z0pUdDVSbENqUUtESklJWUJTdjBXYWJ2NWMrSXRFc3YyYUhQS1l0?= =?utf-8?Q?KkGbMw/uQ+WI4=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 0962D394D2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(39860400002)(366004)(376002)(136003)(189003)(199004)(476003)(6306002)(52536013)(55016002)(7736002)(81166006)(53936002)(66574012)(97736004)(54896002)(5660300002)(6246003)(9326002)(9686003)(236005)(8936002)(86362001)(68736007)(2906002)(33656002)(6436002)(229853002)(81156014)(8676002)(14454004)(25786009)(486006)(71200400001)(446003)(11346002)(71190400001)(186003)(76176011)(7696005)(53546011)(102836004)(6506007)(26005)(316002)(4326008)(606006)(966005)(105586002)(99286004)(106356001)(478600001)(74316002)(66066001)(14444005)(5024004)(6116002)(3846002)(6916009)(790700001)(256004); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR2201MB1747; H:BN6PR2201MB1092.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ra.rockwell.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: MRhQAhGxvtdxirTnByJDilOzo6esjEcLDbJ9rMWbgEok3HfhFreirgCg6VjKtyFUcIR4+aE3/r50lVREIfYcNg+cH8DxfAtW7Vn7un2EziF7jrGlgA8/D/m0vSKR/8laIVsK9jFcSPkknoJaEF1be7kv+UGMvyA+W2tT2P9Hzyr6bBWy2Nhe3eXbNL4OWJBWjETSKK0tcSVu0lsnHYkA5SLPJ0K8nmnVrHBL0bevlHqU8Mku6veLlZfPz8xWWo9dRDtpGYiSnWgqDCgov6w66qwFH+6KTqn78J9lcf8Khx8O/AZbwtzw3l09rPeMdSVPnPkWjngctjqVdR4lYJDrGWCmbwB7gOYYvBNVILKWT8zSgtsDS6fXHHML8Tx5GHSEAqDS6NWkdKMVOL2HXdDKpcBKYDPXKolT0IH/brnGnMc= Content-Type: multipart/alternative; boundary="_000_BN6PR2201MB1092D75139ECFF6B2070169F99750BN6PR2201MB1092_" MIME-Version: 1.0 X-OriginatorOrg: ra.rockwell.com X-MS-Exchange-CrossTenant-Network-Message-Id: fe7099e5-4a4c-4ebd-c11e-08d69da95357 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2019 18:19:49.1236 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 855b093e-7340-45c7-9f0c-96150415893e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR2201MB1747 Archived-At: Subject: Re: [TLS] EXTERNAL: Re: Authentication Only Ciphersuites RFC 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, 28 Feb 2019 18:20:05 -0000 --_000_BN6PR2201MB1092D75139ECFF6B2070169F99750BN6PR2201MB1092_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSm9obiwNCg0KTWVzc2FnZXMgaW4gdGhpcyBjYXRlZ29yeSBvZiBjb21tdW5pY2F0aW9ucyBy YW5nZSBpbiBzaXplIGZyb20gYSBjb3VwbGUgb2YgYnl0ZXMgdG8gYXJvdW5kIGEgaHVuZHJlZCBv ciBzbyAoSSBzdXBwb3NlIHRoZXJlIGNvdWxkIGJlIGV2ZW4gbGFyZ2VyIG1lc3NhZ2VzIGJ1dCB0 aGF0IHdvdWxkIGJlIHByZXR0eSB1bmNvbW1vbikuICBQbGF0Zm9ybXMgcmFuZ2UgcXVpdGUgYSBi aXQsIGJ1dCBJIHdvdWxkIHNheSBzb21lIGZsYXZvciBvZiBBUk0gaXMgcHJldHR5IGNvbW1vbiwg d2l0aCBlaXRoZXIgbm8gT1Mgb3Igc29tZSB2YXJpYW50IG9mIHJlYWx0aW1lIE9TLiAgQXMgSSBt ZW50aW9uZWQgYmVmb3JlIHRoZXJl4oCZcyBhbHNvIGEgbm9uLXRyaXZpYWwgYW1vdW50IG9mIHBy b2R1Y3RzIHdpdGggc29tZSBzb3J0IG9mIGhhcmR3YXJlIGNyeXB0b2dyYXBoaWMgYWNjZWxlcmF0 aW9uLiAgR2l2ZW4gdGhlIGxhcmdlIG51bWJlciBvZiBwbGF0Zm9ybXMgYW5kIGNvbW11bmljYXRp b24gY29uZGl0aW9ucyBJ4oCZZCBleHBlY3QgdGhhdCB0aGVyZSBhcmUgY2FzZXMgd2hlcmUgYXV0 aGVudGljYXRlZCBlbmNyeXB0aW9uIHdvdWxkIGJlIGp1c3QgYXMgcGVyZm9ybWFudCwgYnV0IEni gJltIHN1cmUgdGhlcmUgYXJlIGNhc2VzIHdoZXJlIGp1c3QgU0hBLTI1NiBITUFDIGlzIG1vcmUg cGVyZm9ybWFudC4NCg0KSW4gdGhlIGRyYWZ0IHdlIHRhbGsgYWJvdXQgdGhlIGR1YWwgY29uZGl0 aW9ucyBvZiBuZWVkaW5nIGxvdyBsYXRlbmN5IGJ1dCBoYXZpbmcgYSB3ZWFrIG5lZWQgZm9yIGNv bmZpZGVudGlhbGl0eS4gIFRoZSB0aG91Z2h0IHdhcyB0aGF0IHdoZW4gYm90aCB0aGVzZSBjb25k aXRpb25zIGFyZSBwcmVzZW50IHRoZW4gdGhlIGF1dGhlbnRpY2F0aW9uIG9ubHkgY29tbXVuaWNh dGlvbnMgbWFrZXMgc2Vuc2UuICBJIHdvdWxkIG5vdCBzdXBwb3J0IHVzYWdlIG9mIHRoZXNlIGNp cGhlcnN1aXRlcyBpbiBhIGNhc2Ugd2hlcmUgbGF0ZW5jeSB3YXMgaW1wb3J0YW50IGJ1dCBjb25m aWRlbnRpYWxpdHkgd2FzIGFsc28gbmVlZGVkLiAgV2XigJl2ZSBkZXNjcmliZWQgYSBmZXcgb2Yg dGhlc2UgY2FzZXMgd2l0aGluIHRoZSBkcmFmdCwgYnV0IEkgZG9u4oCZdCB0aGluayBhbiBleGhh dXN0aXZlIGVudW1lcmF0aW9uIG9mIGNhc2VzIHdvdWxkIGJlIHBvc3NpYmxlLiAgV2hhdCBhcmUg eW91IHRoaW5raW5nPyAgU2hvdWxkIHdlIHB1dCBhZGRlZCBlbXBoYXNpcyBvbiB0aGUgaWRlYSB0 aGF0IHRoaXMgaXMgb25seSB0byBiZSB1c2VkIGlmIGNvbmZpZGVudGlhbGl0eSBpcyBub3QgYSBj b25jZXJuPw0KDQpUaGFua3MsDQoNCi0tSmFjaw0KDQpGcm9tOiBKb2huIE1hdHRzc29uIDxqb2hu Lm1hdHRzc29uQGVyaWNzc29uLmNvbT4NClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAyOCwgMjAx OSAxMDo1NiBBTQ0KVG86IEphY2sgVmlzb2t5IDxqbXZpc29reUByYS5yb2Nrd2VsbC5jb20+DQpD YzogdGxzQGlldGYub3JnDQpTdWJqZWN0OiBFWFRFUk5BTDogUmU6IFtUTFNdIEF1dGhlbnRpY2F0 aW9uIE9ubHkgQ2lwaGVyc3VpdGVzIFJGQw0KDQoNCltVc2UgY2F1dGlvbiB3aXRoIGxpbmtzICYg YXR0YWNobWVudHNdDQoNCg0KSGksDQoNCkkgZGlzbGlrZSBoYXZpbmcgYSBkb2N1bWVudCAoZXZl biBhIGludGVybmV0LWRyYWZ0IHdpdGggbm9uLXJlY29tbWVuZGVkIGNpcGhlciBzdWl0ZXMpIHRo YXQga2luZCBvZiBpbXBsaWVzIHRoYXQgY29uZmlkZW50aWFsbHkgbmVlZHMgdG8gYmUgZGlzYWJs ZWQgZm9yIGxvdyBsYXRlbmN5LiBFc3BlY2lhbGx5IGFzIHRoZSBzdWdnZXN0ZWQgY2lwaGVyIHN1 aXRlcyB3b3VsZCBpbmNyZWFzZSBsYXRlbmN5IGluIGEgbG90IG9mIGNhc2VzLiBBbnlib2R5IGdv b2dsaW5nIChvciBEdWNrRHVja0dvaW5nKSDigJxUTFPigJ0gYW5kIOKAnGxvdyBsYXRlbmN54oCd IGlzIG5vdyBsaWtlbHkgdG8gZmluZCB0aGlzIGRvY3VtZW504oCmDQoNCklycmVzcGVjdGl2ZWx5 IG9mIHdoYXQgaGFwcGVucyB3aXRoIHRoaXMgZG9jdW1lbnQsIEkgc3VnZ2VzdCBlaXRoZXI6DQoN Cg0KICAqICAgUmVtb3ZpbmcgYW55IGNsYWltcyBhYm91dCBsb3cgbGF0ZW5jeS4NCiAgKiAgIERl c2NyaWJlIGV4YWN0bHkgd2hpY2ggY2FzZXMgdGhlIHN1Z2dlc3RlZCBjaXBoZXIgc3VpdGVzIHBy b3ZpZGUgc2lnbmlmaWNhbnRseSBsb3dlciBsYXRlbmN5Lg0KDQooVGhlIG51bWJlcnMgSSBwb3N0 ZWQgeWVzdGVyZGF5IGZvciBhZXMxMjhnY212MSB3YXMgYWNjaWRlbnRseSB0YWtlbiBmcm9tIENv cnRleC1BNTcsIHRoZSBjb3JyZWN0IG51bWJlcnMgZm9yIENvcnRleC1BNSBhcmUgWzE4Ni4xMSwg MTkzLjk0LCAyMDMuMTFdLCBidXQgdGhhdCBpcyBzdGlsbCBsaWtlbHkgYSBsaXR0bGUgYml0IGZh c3RlciB0aGFuIEhNQUMtU0hBLTI1NikuDQoNCkNoZWVycywNCkpvaG4NCg0KRnJvbTogSm9obiBN YXR0c3NvbiA8am9obi5tYXR0c3NvbkBlcmljc3Nvbi5jb208bWFpbHRvOmpvaG4ubWF0dHNzb25A ZXJpY3Nzb24uY29tPj4NCkRhdGU6IFdlZG5lc2RheSwgMjcgRmVicnVhcnkgMjAxOSBhdCAxMzoy Mw0KVG86IFRvbnkgUHV0bWFuIDxUb255LlB1dG1hbkBkeXNvbi5jb208bWFpbHRvOlRvbnkuUHV0 bWFuQGR5c29uLmNvbT4+LCBKYWNrIFZpc29reSA8am12aXNva3lAcmEucm9ja3dlbGwuY29tPG1h aWx0bzpqbXZpc29reUByYS5yb2Nrd2VsbC5jb20+Pg0KQ2M6ICJUTFNAaWV0Zi5vcmc8bWFpbHRv OlRMU0BpZXRmLm9yZz4iIDx0bHNAaWV0Zi5vcmc8bWFpbHRvOnRsc0BpZXRmLm9yZz4+DQpTdWJq ZWN0OiBSZTogW1RMU10gQXV0aGVudGljYXRpb24gT25seSBDaXBoZXJzdWl0ZXMgUkZDDQoNCkhp LA0KDQpUaGUgZG9jdW1lbnQgcmVwZWF0cyB0aGUgcmVxdWlyZW1lbnQgb2YgbG93IGxhdGVuY3kg c2V2ZXJhbCB0aW1lcy4gSXQgd291bGQgYmUgaW50ZXJlc3RpbmcgdG8ga25vdyB3aGljaCBwbGF0 Zm9ybXMvbmV0d29ya3MvZGVwbG95bWVudHMgeW91IGhhdmUgaW4gbWluZC4gTXkgdW5kZXJzdGFu ZGluZyBpcyB0aGF0IEhNQUMtU0hBLTI1NiBvbmx5IGhhdmUgYmV0dGVyIGxhdGVuY3kgdGhhbiBB RVMgb24gYSBsaXR0bGUgYml0IGxvbmdlciBtZXNzYWdlcyB3aGVyZSB0aGUgbGFyZ2VyIGJsb2Nr IHNpemUgbWF0dGVycy4gU2hvcnQgbWVzc2FnZXMgYXJlIGNvbW1vbiBpbiBtYW55IElvVCBkZXBs b3ltZW50cy4gTG9va2luZyBlLmcuIGF0IHRoZSBiZW5jaG1hcmtzIGF0IGh0dHBzOi8vYmVuY2gu Y3IueXAudG8gZm9yICJhcm1lYWJpOyBDb3J0ZXgtQTUgKDQxN2ZjMDUxKSIgb24gNjQgYnl0ZSBt ZXNzYWdlcywgU0hBLTI1NiBhbG9uZSByZXF1aXJlcyBzaWduaWZpY2FudGx5IG1vcmUgY3ljbGVz IHRoYW4gQUVTLUdDTSBmb3IgNjQgYnl0ZSBtZXNzYWdlcy4NCg0KQ3ljbGVzL2J5dGUgZm9yIDY0 IGJ5dGVzDQo4Ni4xNCAgICAgODYuNzMgICAgIDkzLjU5ICAgICBzaGEyNTYNCg0KQ3ljbGVzL2J5 dGUgZm9yIDY0KzAgZW5jcnlwdA0KMjQuMjAgICAgIDI0LjIwICAgICAyNC4zNCAgICAgYWVzMTI4 Z2NtdjENCg0KT24gbW9yZSBjb25zdHJhaW5lZCBwcm9jZXNzb3JzIHN1Y2ggYXMgdGhlIENvcnRl eC1NMCwgQUVTMTI4LUNDTSBhbHNvIHNlZW1zIHRvIGhhdmUgbG93ZXIgbGF0ZW5jeSB0aGFuIEhN QUMtU0hBLTI1NiBvbiBzaG9ydCBtZXNzYWdlcyAoMzc2NzcgY3ljbGVzIHZzLiA0ODkyNCBjeWNs ZXMpIGh0dHBzOi8vZ2l0aHViLmNvbS9jdHovY2lmcmEuIE9uIGxvbmdlciBtZXNzYWdlcywgSE1B Qy1TSEEtMjU2IGxpa2VseSBoYXZlIGxvd2VyIGxhdGVuY3kgKGh0dHBzOi8vY3NyYy5uaXN0Lmdv di9jc3JjL21lZGlhL2V2ZW50cy9saWdodHdlaWdodC1jcnlwdG9ncmFwaHktd29ya3Nob3AtMjAx NS9kb2N1bWVudHMvcHJlc2VudGF0aW9ucy9zZXNzaW9uNy12aW5jZW50LnBkZikuIE5vdGUgdGhh dCB0aGlzIHBkZiBzaG93cyB0aW1pbmcgZm9yIFNIQS0yNTYsIG5vdCBITUFDLVNIQS0yNTYuDQoN CkluY3JlYXNpbmcgdGhlIHRhZyBzaXplIGZyb20gOCBieXRlcyAoQ0NNXzgpIG9yIDE2IChHQ00p IHRvIDMyIG9yIDY0IG1heSBhbHNvIGluY3JlYXNlIHRoZSBsYXRlbmN5IGFzIHRoZXNlIGFkZGl0 aW9uYWwgYnl0ZXMgaGF2ZSB0byBiZSB0cmFuc21pdHRlZC4NCg0KL0pvaG4NCg0KRnJvbTogVExT IDx0bHMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBi ZWhhbGYgb2YgVG9ueSBQdXRtYW4gPFRvbnkuUHV0bWFuQGR5c29uLmNvbTxtYWlsdG86VG9ueS5Q dXRtYW5AZHlzb24uY29tPj4NCkRhdGU6IFdlZG5lc2RheSwgMjcgRmVicnVhcnkgMjAxOSBhdCAx MToxNw0KVG86IEphY2sgVmlzb2t5IDxqbXZpc29reUByYS5yb2Nrd2VsbC5jb208bWFpbHRvOmpt dmlzb2t5QHJhLnJvY2t3ZWxsLmNvbT4+DQpDYzogIlRMU0BpZXRmLm9yZzxtYWlsdG86VExTQGll dGYub3JnPiIgPHRsc0BpZXRmLm9yZzxtYWlsdG86dGxzQGlldGYub3JnPj4NClN1YmplY3Q6IFJl OiBbVExTXSBBdXRoZW50aWNhdGlvbiBPbmx5IENpcGhlcnN1aXRlcyBSRkMNCg0KSSB0YWtlIG5v IHBvc2l0aW9uIG9uIHdoZXRoZXIgdGhpcyBpcyBhIGdvb2QgaWRlYSBvciBub3QuIFJlZ2FyZGlu ZyB0aGUgZHJhZnQgaXRzZWxmLCBJIHdhcyBleHBlY3RpbmcgdG8gc2VlIGEgY2xlYXIgZGVmaW5p dGlvbiBvZiB0aGUgaW50ZWdyaXR5IGNoZWNrIGNvbXB1dGF0aW9uIGluIHRlcm1zIG9mIGFuIEFF QUQtRW5jcnlwdCBjb21wdXRhdGlvbi4uIFNvbWV0aGluZyBhbG9uZyB0aGUgbGluZXMgb2Y6DQog IEFFQUQtRW5jcnlwdC1ITUFDKHdyaXRlX2tleSwgbm9uY2UsIGFkZGl0aW9uYWxfZGF0YSwgcGxh aW50ZXh0KSA9DQogICAgcGxhaW50ZXh0IHx8IEhNQUMod3JpdGVfa2V5LCBub25jZSB8fCBhZGRp dGlvbmFsX2RhdGEgfHwgcGxhaW50ZXh0KQ0KDQpJbiBwYXJ0aWN1bGFyLCBBSVVJLCBub25jZSBt dXN0IGJlIGluY2x1ZGVkIHRvIHByZXZlbnQgcmVwbGF5IGF0dGFja3MuIEFsc28gaW5jbHVkZSBO X01JTiA9IE5fTUFYID0gOCBieXRlcy4NCg0KLS0gVG9ueQ0KDQpGcm9tOiBUTFMgW21haWx0bzp0 bHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEphY2sgVmlzb2t5DQpTZW50OiAyNiBG ZWJydWFyeSAyMDE5IDIwOjU0DQpUbzogdGxzQGlldGYub3JnPG1haWx0bzp0bHNAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBbRXh0ZXJuYWwgTWFpbF0gW1RMU10gQXV0aGVudGljYXRpb24gT25seSBDaXBo ZXJzdWl0ZXMgUkZDDQoNCg0KVExTIENvbGxlYWd1ZXMsDQoNCklmIHlvdSByZWNhbGwgd2UgZGlz Y3Vzc2VkIGEgZHJhZnQgZm9yIGF1dGhlbnRpY2F0aW9uIG9ubHkgY2lwaGVyc3VpdGVzIG92ZXIg ZW1haWwgYmFjayBpbiBBdWd1c3Qgb2YgMjAxOC4gIFdlJ3ZlIHNpbmNlIG1hZGUgc29tZSB1cGRh dGVzIHRvIHRoYXQgZHJhZnQuICBXZSBhbHNvIGhhdmUgZ290dGVuIElBTkEgYXNzaWdubWVudHMg dG8gdGhlIGF1dGhlbnRpY2F0aW9uIG9ubHkgY2lwaGVyc3VpdGVzIGZvciBUTFMgMS4zIGFuZCBo YXZlIHVwZGF0ZWQgdGhlIGRyYWZ0IHRvIHJlZmxlY3QgdGhlIG5ldyBhc3NpZ25tZW50cy4NCg0K VG8gdGhhdCBleHRlbnQsIGFzIHRoZSBJb1QgY29tbXVuaXR5IGlzIGxvb2tpbmcgdG8gYWRvcHQg dGhlc2UgY2lwaGVyc3VpdGVzLCB3ZSB3b3VsZCBsaWtlIHRvIHNvbGljaXQgcmV2aWV3IG9mIHRo ZSBkcmFmdDoNCg0KDQoNCiAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2Ft d2luZ2V0LXRscy10czEzLW1hY2NpcGhlcnN1aXRlcy0wMg0KDQoNCg0KYW5kIHJlcXVlc3QgdGhh dCBpdCBiZSBwdWJsaXNoZWQgYXMgaW5mb3JtYXRpb25hbCBkcmFmdCBnaXZlbiB0aGF0IHRoZSBJ b1QgZm9ydW1zIGFyZSBsb29raW5nIHRvIGFkb3B0IGl0cyB1c2UgYW5kIHRoZSBkcmFmdCBjYW4g c2VydmUgYXMgdGhlIGd1aWRlIGZvciB1c2UgYW5kIGludGVyb3BlcmFiaWxpdHkuDQoNClRoYW5r cyBhbmQgQmVzdCBSZWdhcmRzLA0KDQotLUphY2sgKGFuZCBOYW5jeSkNCg0KDQoNCkR5c29uIFRl Y2hub2xvZ3kgTGltaXRlZCwgY29tcGFueSBudW1iZXIgMDE5NTkwOTAsIFRldGJ1cnkgSGlsbCwg TWFsbWVzYnVyeSwgU04xNiAwUlAsIFVLLg0KVGhpcyBtZXNzYWdlIGlzIGludGVuZGVkIHNvbGVs eSBmb3IgdGhlIGFkZHJlc3NlZSBhbmQgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0 aW9uLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIHBsZWFzZSBp bW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIGl0LCBhbmQgZG8gbm90IHVzZSwgY29w eSBvciBkaXNjbG9zZSB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWVzc2FnZSBv ciBpbiBhbnkgYXR0YWNobWVudC4NCkR5c29uIG1heSBtb25pdG9yIGVtYWlsIHRyYWZmaWMgZGF0 YSBhbmQgY29udGVudCBmb3Igc2VjdXJpdHkgJiB0cmFpbmluZy4NCg== --_000_BN6PR2201MB1092D75139ECFF6B2070169F99750BN6PR2201MB1092_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6RGVuZ1hpYW47DQoJcGFub3NlLTE6MiAx IDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQXJpYWwgTmFycm93IjsNCglwYW5vc2UtMToyIDExIDYgNiAyIDIgMiAzIDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0 IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQERlbmdYaWFuIjsNCglwYW5vc2Ut MToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05v cm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CnR0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQ YXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1h cmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLWFkZC1zcGFjZTphdXRvOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5Nc29MaXN0 UGFyYWdyYXBoQ3hTcEZpcnN0LCBsaS5Nc29MaXN0UGFyYWdyYXBoQ3hTcEZpcnN0LCBkaXYuTXNv TGlzdFBhcmFncmFwaEN4U3BGaXJzdA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBp bjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCgltc28tYWRkLXNwYWNlOmF1dG87DQoJZm9udC1zaXplOjExLjBwdDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGhDeFNw TWlkZGxlLCBsaS5Nc29MaXN0UGFyYWdyYXBoQ3hTcE1pZGRsZSwgZGl2Lk1zb0xpc3RQYXJhZ3Jh cGhDeFNwTWlkZGxlDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdp bi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCW1zby1hZGQtc3BhY2U6YXV0bzsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAuTXNvTGlzdFBhcmFncmFwaEN4U3BMYXN0LCBsaS5N c29MaXN0UGFyYWdyYXBoQ3hTcExhc3QsIGRpdi5Nc29MaXN0UGFyYWdyYXBoQ3hTcExhc3QNCgl7 bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1h cmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJ bWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLWFkZC1zcGFj ZTphdXRvOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXtt c28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1t YXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3Rl eHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpwLm1z Z2JvcmRlciwgbGkubXNnYm9yZGVyLCBkaXYubXNnYm9yZGVyDQoJe21zby1zdHlsZS1uYW1lOm1z Z2JvcmRlcjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglib3JkZXI6 bm9uZTsNCglwYWRkaW5nOjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTI3DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4 LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0K QGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTc2Mzg4MjI2Ow0KCW1zby1saXN0LXR5cGU6aHlicmlk Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotNzc4NTM4NTgyIDE1MzUwMDk4MzIgNjc2OTg2OTEg Njc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2 OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNv LWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxl dmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2 ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxMzE0MTM5NTY3Ow0KCW1zby1s aXN0LXRlbXBsYXRlLWlkczotMTM0Mzk4NzY2Mjt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0 LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCm9sDQoJe21hcmdpbi1ib3R0 b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgSm9obiw8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+TWVzc2FnZXMgaW4gdGhpcyBjYXRlZ29yeSBvZiBjb21tdW5pY2F0aW9ucyBy YW5nZSBpbiBzaXplIGZyb20gYSBjb3VwbGUgb2YgYnl0ZXMgdG8gYXJvdW5kIGEgaHVuZHJlZCBv ciBzbyAoSSBzdXBwb3NlIHRoZXJlIGNvdWxkIGJlIGV2ZW4gbGFyZ2VyIG1lc3NhZ2VzIGJ1dCB0 aGF0IHdvdWxkIGJlIHByZXR0eSB1bmNvbW1vbikuJm5ic3A7IFBsYXRmb3JtcyByYW5nZSBxdWl0 ZSBhIGJpdCwgYnV0IEkgd291bGQgc2F5DQogc29tZSBmbGF2b3Igb2YgQVJNIGlzIHByZXR0eSBj b21tb24sIHdpdGggZWl0aGVyIG5vIE9TIG9yIHNvbWUgdmFyaWFudCBvZiByZWFsdGltZSBPUy4m bmJzcDsgQXMgSSBtZW50aW9uZWQgYmVmb3JlIHRoZXJl4oCZcyBhbHNvIGEgbm9uLXRyaXZpYWwg YW1vdW50IG9mIHByb2R1Y3RzIHdpdGggc29tZSBzb3J0IG9mIGhhcmR3YXJlIGNyeXB0b2dyYXBo aWMgYWNjZWxlcmF0aW9uLiZuYnNwOyBHaXZlbiB0aGUgbGFyZ2UgbnVtYmVyIG9mIHBsYXRmb3Jt cyBhbmQgY29tbXVuaWNhdGlvbg0KIGNvbmRpdGlvbnMgSeKAmWQgZXhwZWN0IHRoYXQgdGhlcmUg YXJlIGNhc2VzIHdoZXJlIGF1dGhlbnRpY2F0ZWQgZW5jcnlwdGlvbiB3b3VsZCBiZSBqdXN0IGFz IHBlcmZvcm1hbnQsIGJ1dCBJ4oCZbSBzdXJlIHRoZXJlIGFyZSBjYXNlcyB3aGVyZSBqdXN0IFNI QS0yNTYgSE1BQyBpcyBtb3JlIHBlcmZvcm1hbnQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklu IHRoZSBkcmFmdCB3ZSB0YWxrIGFib3V0IHRoZSBkdWFsIGNvbmRpdGlvbnMgb2YgbmVlZGluZyBs b3cgbGF0ZW5jeSBidXQgaGF2aW5nIGEgd2VhayBuZWVkIGZvciBjb25maWRlbnRpYWxpdHkuJm5i c3A7IFRoZSB0aG91Z2h0IHdhcyB0aGF0IHdoZW4gYm90aCB0aGVzZSBjb25kaXRpb25zIGFyZSBw cmVzZW50IHRoZW4gdGhlIGF1dGhlbnRpY2F0aW9uIG9ubHkgY29tbXVuaWNhdGlvbnMgbWFrZXMg c2Vuc2UuJm5ic3A7IEkgd291bGQNCiBub3Qgc3VwcG9ydCB1c2FnZSBvZiB0aGVzZSBjaXBoZXJz dWl0ZXMgaW4gYSBjYXNlIHdoZXJlIGxhdGVuY3kgd2FzIGltcG9ydGFudCBidXQgY29uZmlkZW50 aWFsaXR5IHdhcyBhbHNvIG5lZWRlZC4mbmJzcDsgV2XigJl2ZSBkZXNjcmliZWQgYSBmZXcgb2Yg dGhlc2UgY2FzZXMgd2l0aGluIHRoZSBkcmFmdCwgYnV0IEkgZG9u4oCZdCB0aGluayBhbiBleGhh dXN0aXZlIGVudW1lcmF0aW9uIG9mIGNhc2VzIHdvdWxkIGJlIHBvc3NpYmxlLiZuYnNwOyBXaGF0 IGFyZSB5b3UNCiB0aGlua2luZz8mbmJzcDsgU2hvdWxkIHdlIHB1dCBhZGRlZCBlbXBoYXNpcyBv biB0aGUgaWRlYSB0aGF0IHRoaXMgaXMgb25seSB0byBiZSB1c2VkIGlmIGNvbmZpZGVudGlhbGl0 eSBpcyBub3QgYSBjb25jZXJuPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MsPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPi0tSmFjazxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IEpvaG4gTWF0dHNzb24gJmx0 O2pvaG4ubWF0dHNzb25AZXJpY3Nzb24uY29tJmd0OyA8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNk YXksIEZlYnJ1YXJ5IDI4LCAyMDE5IDEwOjU2IEFNPGJyPg0KPGI+VG86PC9iPiBKYWNrIFZpc29r eSAmbHQ7am12aXNva3lAcmEucm9ja3dlbGwuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gdGxzQGll dGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IEVYVEVSTkFMOiBSZTogW1RMU10gQXV0aGVudGlj YXRpb24gT25seSBDaXBoZXJzdWl0ZXMgUkZDPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRp diBzdHlsZT0ibXNvLWVsZW1lbnQ6cGFyYS1ib3JkZXItZGl2O2JvcmRlcjpzb2xpZCAjQkIyMzIy IDIuMjVwdDtwYWRkaW5nOjIuMHB0IDIuMHB0IDIuMHB0IDIuMHB0O2JhY2tncm91bmQ6I0U4RThF OCI+DQo8cCBjbGFzcz0ibXNnYm9yZGVyIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTIuMHB0O2JhY2tn cm91bmQ6I0U4RThFOCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2si PltVc2UgY2F1dGlvbiB3aXRoIGxpbmtzICZhbXA7IGF0dGFjaG1lbnRzXTwvc3Bhbj48c3BhbiBs YW5nPSJTViI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwPjxzcGFu IGxhbmc9IlNWIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPkhpLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+SSBkaXNsaWtl IGhhdmluZyBhIGRvY3VtZW50IChldmVuIGEgaW50ZXJuZXQtZHJhZnQgd2l0aCBub24tcmVjb21t ZW5kZWQgY2lwaGVyIHN1aXRlcykgdGhhdCBraW5kIG9mIGltcGxpZXMgdGhhdCBjb25maWRlbnRp YWxseSBuZWVkcyB0byBiZSBkaXNhYmxlZCBmb3IgbG93IGxhdGVuY3kuIEVzcGVjaWFsbHkgYXMg dGhlIHN1Z2dlc3RlZCBjaXBoZXIgc3VpdGVzIHdvdWxkIGluY3JlYXNlDQogbGF0ZW5jeSBpbiBh IGxvdCBvZiBjYXNlcy4gQW55Ym9keSBnb29nbGluZyAob3IgRHVja0R1Y2tHb2luZykg4oCcVExT 4oCdIGFuZCDigJxsb3cgbGF0ZW5jeeKAnSBpcyBub3cgbGlrZWx5IHRvIGZpbmQgdGhpcyBkb2N1 bWVudOKApjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+SXJyZXNwZWN0aXZlbHkgb2Ygd2hhdCBoYXBwZW5z IHdpdGggdGhpcyBkb2N1bWVudCwgSSBzdWdnZXN0IGVpdGhlcjo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+ DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGhDeFNwRmlyc3QiIHN0eWxlPSJtYXJnaW4tbGVm dDowaW47bXNvLWFkZC1zcGFjZTphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8zIj4NCjxzcGFu IGxhbmc9IkVOLUdCIj5SZW1vdmluZyBhbnkgY2xhaW1zIGFib3V0IGxvdyBsYXRlbmN5LjxvOnA+ PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoQ3hTcExhc3QiIHN0 eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWFkZC1zcGFjZTphdXRvO21zby1saXN0OmwwIGxldmVs MSBsZm8zIj4NCjxzcGFuIGxhbmc9IkVOLUdCIj5EZXNjcmliZSBleGFjdGx5IHdoaWNoIGNhc2Vz IHRoZSBzdWdnZXN0ZWQgY2lwaGVyIHN1aXRlcyBwcm92aWRlIHNpZ25pZmljYW50bHkgbG93ZXIg bGF0ZW5jeS48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPihUaGUgbnVtYmVycyBJIHBvc3RlZCB5 ZXN0ZXJkYXkgZm9yIGFlczEyOGdjbXYxIHdhcyBhY2NpZGVudGx5IHRha2VuIGZyb20gQ29ydGV4 LUE1NywgdGhlIGNvcnJlY3QgbnVtYmVycyBmb3IgQ29ydGV4LUE1IGFyZQ0KPC9zcGFuPls8c3Bh biBsYW5nPSJFTi1HQiI+MTg2LjExLCAxOTMuOTQsIDIwMy4xMV0sIGJ1dCB0aGF0IGlzIHN0aWxs IGxpa2VseSBhIGxpdHRsZSBiaXQgZmFzdGVyIHRoYW4gSE1BQy1TSEEtMjU2KS48L3NwYW4+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5Kb2huPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iU1YiIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Kb2huIE1hdHRzc29uICZsdDs8YSBo cmVmPSJtYWlsdG86am9obi5tYXR0c3NvbkBlcmljc3Nvbi5jb20iPmpvaG4ubWF0dHNzb25AZXJp Y3Nzb24uY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+V2VkbmVzZGF5LCAyNyBGZWJydWFy eSAyMDE5IGF0IDEzOjIzPGJyPg0KPGI+VG86IDwvYj5Ub255IFB1dG1hbiAmbHQ7PGEgaHJlZj0i bWFpbHRvOlRvbnkuUHV0bWFuQGR5c29uLmNvbSI+VG9ueS5QdXRtYW5AZHlzb24uY29tPC9hPiZn dDssIEphY2sgVmlzb2t5ICZsdDs8YSBocmVmPSJtYWlsdG86am12aXNva3lAcmEucm9ja3dlbGwu Y29tIj5qbXZpc29reUByYS5yb2Nrd2VsbC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1 b3Q7PGEgaHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9yZyI+VExTQGlldGYub3JnPC9hPiZxdW90OyAm bHQ7PGEgaHJlZj0ibWFpbHRvOnRsc0BpZXRmLm9yZyI+dGxzQGlldGYub3JnPC9hPiZndDs8YnI+ DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtUTFNdIEF1dGhlbnRpY2F0aW9uIE9ubHkgQ2lwaGVyc3Vp dGVzIFJGQzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IlNWIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5IaSw8L3NwYW4+ PHNwYW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iU1YiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC Ij5UaGUgZG9jdW1lbnQgcmVwZWF0cyB0aGUgcmVxdWlyZW1lbnQgb2YgbG93IGxhdGVuY3kgc2V2 ZXJhbCB0aW1lcy4gSXQgd291bGQgYmUgaW50ZXJlc3RpbmcgdG8ga25vdyB3aGljaCBwbGF0Zm9y bXMvbmV0d29ya3MvZGVwbG95bWVudHMgeW91IGhhdmUgaW4gbWluZC4gTXkgdW5kZXJzdGFuZGlu ZyBpcyB0aGF0IEhNQUMtU0hBLTI1NiBvbmx5IGhhdmUgYmV0dGVyIGxhdGVuY3kNCiB0aGFuIEFF UyBvbiBhIGxpdHRsZSBiaXQgbG9uZ2VyIG1lc3NhZ2VzIHdoZXJlIHRoZSBsYXJnZXIgYmxvY2sg c2l6ZSBtYXR0ZXJzLiBTaG9ydCBtZXNzYWdlcyBhcmUgY29tbW9uIGluIG1hbnkgSW9UIGRlcGxv eW1lbnRzLiBMb29raW5nIGUuZy4gYXQgdGhlIGJlbmNobWFya3MgYXQNCjxhIGhyZWY9Imh0dHBz Oi8vYmVuY2guY3IueXAudG8iPmh0dHBzOi8vYmVuY2guY3IueXAudG88L2E+IGZvciAmcXVvdDth cm1lYWJpOyBDb3J0ZXgtQTUgKDQxN2ZjMDUxKSZxdW90OyBvbiA2NCBieXRlIG1lc3NhZ2VzLCBT SEEtMjU2IGFsb25lIHJlcXVpcmVzIHNpZ25pZmljYW50bHkgbW9yZSBjeWNsZXMgdGhhbiBBRVMt R0NNIGZvciA2NCBieXRlIG1lc3NhZ2VzLjwvc3Bhbj48c3BhbiBsYW5nPSJTViI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJTViI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPkN5Y2xlcy9ieXRlIGZvciA2NCBieXRl czwvc3Bhbj48c3BhbiBsYW5nPSJTViI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjg2LjE0Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IDg2LjczJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDkzLjU5Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHNoYTI1Njwvc3Bhbj48c3BhbiBsYW5nPSJTViI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzwvc3Bhbj48 c3BhbiBsYW5nPSJTViI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiPkN5Y2xlcy9ieXRlIGZvciA2NCYjNDM7MCBlbmNyeXB0PC9z cGFuPjxzcGFuIGxhbmc9IlNWIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+MjQuMjAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg MjQuMjAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMjQuMzQmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgYWVzMTI4Z2NtdjE8L3NwYW4+PHNwYW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8L3NwYW4+ PHNwYW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5PbiBtb3JlIGNvbnN0cmFpbmVkIHByb2Nlc3NvcnMgc3Vj aCBhcyB0aGUgQ29ydGV4LU0wLCBBRVMxMjgtQ0NNIGFsc28gc2VlbXMgdG8gaGF2ZSBsb3dlciBs YXRlbmN5IHRoYW4gSE1BQy1TSEEtMjU2IG9uIHNob3J0IG1lc3NhZ2VzICgzNzY3NyBjeWNsZXMg dnMuIDQ4OTI0IGN5Y2xlcykNCjwvc3Bhbj48YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vY3R6 L2NpZnJhIj5odHRwczovL2dpdGh1Yi5jb20vY3R6L2NpZnJhPC9hPi4gT24gbG9uZ2VyIG1lc3Nh Z2VzLA0KPHNwYW4gbGFuZz0iRU4tR0IiPkhNQUMtU0hBLTI1NiBsaWtlbHkgaGF2ZSBsb3dlciBs YXRlbmN5ICg8YSBocmVmPSJodHRwczovL2NzcmMubmlzdC5nb3YvY3NyYy9tZWRpYS9ldmVudHMv bGlnaHR3ZWlnaHQtY3J5cHRvZ3JhcGh5LXdvcmtzaG9wLTIwMTUvZG9jdW1lbnRzL3ByZXNlbnRh dGlvbnMvc2Vzc2lvbjctdmluY2VudC5wZGYiPmh0dHBzOi8vY3NyYy5uaXN0Lmdvdi9jc3JjL21l ZGlhL2V2ZW50cy9saWdodHdlaWdodC1jcnlwdG9ncmFwaHktd29ya3Nob3AtMjAxNS9kb2N1bWVu dHMvcHJlc2VudGF0aW9ucy9zZXNzaW9uNy12aW5jZW50LnBkZjwvYT4pLg0KIE5vdGUgdGhhdCB0 aGlzIHBkZiBzaG93cyB0aW1pbmcgZm9yIFNIQS0yNTYsIG5vdCBITUFDLVNIQS0yNTYuPC9zcGFu PjxzcGFuIGxhbmc9IlNWIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8c3BhbiBsYW5nPSJTViI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPkluY3JlYXNpbmcgdGhlIHRhZyBzaXpl IGZyb20gOCBieXRlcyAoQ0NNXzgpIG9yIDE2IChHQ00pIHRvIDMyIG9yIDY0IG1heSBhbHNvIGlu Y3JlYXNlIHRoZSBsYXRlbmN5IGFzIHRoZXNlIGFkZGl0aW9uYWwgYnl0ZXMgaGF2ZSB0byBiZSB0 cmFuc21pdHRlZC48L3NwYW4+PHNwYW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8L3NwYW4+PHNw YW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIj4vSm9objwvc3Bhbj48c3BhbiBsYW5nPSJTViI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJTViI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0i U1YiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwv Yj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPlRM UyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnIj50bHMtYm91bmNlc0Bp ZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBUb255IFB1dG1hbiAmbHQ7PGEgaHJlZj0ibWFp bHRvOlRvbnkuUHV0bWFuQGR5c29uLmNvbSI+VG9ueS5QdXRtYW5AZHlzb24uY29tPC9hPiZndDs8 YnI+DQo8Yj5EYXRlOiA8L2I+V2VkbmVzZGF5LCAyNyBGZWJydWFyeSAyMDE5IGF0IDExOjE3PGJy Pg0KPGI+VG86IDwvYj5KYWNrIFZpc29reSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptdmlzb2t5QHJh LnJvY2t3ZWxsLmNvbSI+am12aXNva3lAcmEucm9ja3dlbGwuY29tPC9hPiZndDs8YnI+DQo8Yj5D YzogPC9iPiZxdW90OzxhIGhyZWY9Im1haWx0bzpUTFNAaWV0Zi5vcmciPlRMU0BpZXRmLm9yZzwv YT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzp0bHNAaWV0Zi5vcmciPnRsc0BpZXRmLm9yZzwv YT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbVExTXSBBdXRoZW50aWNhdGlvbiBPbmx5 IENpcGhlcnN1aXRlcyBSRkM8L3NwYW4+PHNwYW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlNW Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IlNWIj5JIHRha2Ugbm8gcG9zaXRpb24gb24gd2hldGhlciB0aGlzIGlz IGEgZ29vZCBpZGVhIG9yIG5vdC4gUmVnYXJkaW5nIHRoZSBkcmFmdCBpdHNlbGYsIEkgd2FzIGV4 cGVjdGluZyB0byBzZWUgYSBjbGVhciBkZWZpbml0aW9uIG9mIHRoZSBpbnRlZ3JpdHkgY2hlY2sg Y29tcHV0YXRpb24gaW4gdGVybXMgb2YgYW4gQUVBRC1FbmNyeXB0IGNvbXB1dGF0aW9uLi4gU29t ZXRoaW5nIGFsb25nDQogdGhlIGxpbmVzIG9mOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlNWIj4mbmJzcDsgQUVBRC1FbmNyeXB0LUhNQUMo d3JpdGVfa2V5LCBub25jZSwgYWRkaXRpb25hbF9kYXRhLCBwbGFpbnRleHQpID0NCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlNWIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDtwbGFpbnRleHQgfHwgSE1BQyh3cml0ZV9rZXksIG5vbmNlIHx8 IGFkZGl0aW9uYWxfZGF0YSB8fCBwbGFpbnRleHQpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iU1YiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlNWIj5JbiBwYXJ0aWN1bGFy LCBBSVVJLCBub25jZSBtdXN0IGJlIGluY2x1ZGVkIHRvIHByZXZlbnQgcmVwbGF5IGF0dGFja3Mu IEFsc28gaW5jbHVkZSBOX01JTiA9IE5fTUFYID0gOCBieXRlcy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJTViI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iU1YiPi0tIFRv bnk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJTViI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp biAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPiBUTFMgWzxhIGhyZWY9Im1haWx0bzp0bHMtYm91 bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJl aGFsZiBPZiA8L2I+SmFjayBWaXNva3k8YnI+DQo8Yj5TZW50OjwvYj4gMjYgRmVicnVhcnkgMjAx OSAyMDo1NDxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnRsc0BpZXRmLm9yZyI+dGxz QGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBbRXh0ZXJuYWwgTWFpbF0gW1RMU10g QXV0aGVudGljYXRpb24gT25seSBDaXBoZXJzdWl0ZXMgUkZDPC9zcGFuPjxzcGFuIGxhbmc9IlNW Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iU1YiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0 eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+VExTIENvbGxlYWd1ZXMsIDxz cGFuIGxhbmc9IlNWIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBp bjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPklmIHlvdSByZWNhbGwgd2UgZGlzY3Vzc2VkIGEgZHJh ZnQgZm9yIGF1dGhlbnRpY2F0aW9uIG9ubHkgY2lwaGVyc3VpdGVzIG92ZXIgZW1haWwgYmFjayBp biBBdWd1c3Qgb2YgMjAxOC4mbmJzcDsgV2UndmUgc2luY2UgbWFkZSBzb21lIHVwZGF0ZXMgdG8g dGhhdCBkcmFmdC4mbmJzcDsgV2UgYWxzbyBoYXZlIGdvdHRlbiBJQU5BIGFzc2lnbm1lbnRzIHRv IHRoZSBhdXRoZW50aWNhdGlvbg0KIG9ubHkgY2lwaGVyc3VpdGVzIGZvciBUTFMgMS4zIGFuZCBo YXZlIHVwZGF0ZWQgdGhlIGRyYWZ0IHRvIHJlZmxlY3QgdGhlIG5ldyBhc3NpZ25tZW50cy48c3Bh biBsYW5nPSJTViI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47 bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij5UbyB0aGF0IGV4dGVudCwgYXMgdGhlIElvVCBjb21tdW5p dHkgaXMgbG9va2luZyB0byBhZG9wdCB0aGVzZSBjaXBoZXJzdWl0ZXMsIHdlIHdvdWxkIGxpa2Ug dG8gc29saWNpdCByZXZpZXcgb2YgdGhlIGRyYWZ0OjxzcGFuIGxhbmc9IlNWIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQi PiZuYnNwOyZuYnNwOyZuYnNwOyA8c3BhbiBsYW5nPSJTViI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt Y2Ftd2luZ2V0LXRscy10czEzLW1hY2NpcGhlcnN1aXRlcy0wMiI+aHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWNhbXdpbmdldC10bHMtdHMxMy1tYWNjaXBoZXJzdWl0ZXMtMDI8L2E+ PHNwYW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46 MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxzcGFuIGxhbmc9 IlNWIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4t Ym90dG9tOi4wMDAxcHQiPmFuZCByZXF1ZXN0IHRoYXQgaXQgYmUgcHVibGlzaGVkIGFzIGluZm9y bWF0aW9uYWwgZHJhZnQgZ2l2ZW4gdGhhdCB0aGUgSW9UIGZvcnVtcyBhcmUgbG9va2luZyB0byBh ZG9wdCBpdHMgdXNlIGFuZCB0aGUgZHJhZnQgY2FuIHNlcnZlIGFzIHRoZSBndWlkZSBmb3IgdXNl IGFuZCBpbnRlcm9wZXJhYmlsaXR5LjxzcGFuIGxhbmc9IlNWIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8c3BhbiBsYW5nPSJTViI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzIGFuZCBCZXN0IFJlZ2Fy ZHMsPHNwYW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxzcGFuIGxhbmc9IlNWIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4tLUphY2sgKGFuZCBOYW5jeSk8c3BhbiBsYW5nPSJTViI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PHNwYW4gbGFuZz0i U1YiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0 ZXh0LWF1dG9zcGFjZTpub25lIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCBOYXJyb3cmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFu PjwvYj48c3BhbiBsYW5nPSJTViI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iU1YiPjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJTViIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkR5c29uIFRlY2hub2xvZ3kgTGltaXRlZCwgY29tcGFueSBu dW1iZXIgMDE5NTkwOTAsIFRldGJ1cnkgSGlsbCwgTWFsbWVzYnVyeSwgU04xNiAwUlAsIFVLLg0K PGJyPg0KVGhpcyBtZXNzYWdlIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIGFkZHJlc3NlZSBh bmQgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uLiBJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSBhbmQgcGVybWFu ZW50bHkgZGVsZXRlIGl0LCBhbmQgZG8gbm90IHVzZSwgY29weSBvciBkaXNjbG9zZSB0aGUgaW5m b3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWVzc2FnZQ0KIG9yIGluIGFueSBhdHRhY2htZW50 LiA8YnI+DQpEeXNvbiBtYXkgbW9uaXRvciBlbWFpbCB0cmFmZmljIGRhdGEgYW5kIGNvbnRlbnQg Zm9yIHNlY3VyaXR5ICZhbXA7IHRyYWluaW5nLiA8L3NwYW4+DQo8c3BhbiBsYW5nPSJTViI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BN6PR2201MB1092D75139ECFF6B2070169F99750BN6PR2201MB1092_--