From nobody Sat Aug 1 16:56:58 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC2123A1069 for ; Sat, 1 Aug 2020 16:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nomountain-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3lVTdPAVHReI for ; Sat, 1 Aug 2020 16:56:52 -0700 (PDT) Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0: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 CD55B3A106F for ; Sat, 1 Aug 2020 16:56:52 -0700 (PDT) Received: by mail-pg1-x534.google.com with SMTP id p3so17950978pgh.3 for ; Sat, 01 Aug 2020 16:56:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to; bh=Knh//J7UTCkcP0Ww/vRpoxUO14qhiA5YRXUUfRGQDUQ=; b=GVzY1tpfyedf59MdfRkZ5Wg3c0ypu833ZMWihtaExEZQzXQz6egg+mPLFrjr7psx6T gyZGEmfKNrvU9dUrqY1xftZ+e4YKbumoDY7xKdhXO6ZWZOIRfRkhZhRLFhzqD6NYczP1 M6Nyw42F3RTZBpmEjSFbnrwOmvG1FaZ9LMcvyJ6dDxSh2JrS5KTD+JpX3OM3S0z5f1fj 8PT3RiypSYG4t7DjqYjnwRwpBbhb+YdHndco6uFo3TGF/3J363LO8t2F4lEJZJemjd54 6JWgkn6BCxk4daQuNNIuDGf1SRhVCQuBWAdJN0ZL9PESPnxhLsYPGL3l3QUPkUXn4k++ osow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=Knh//J7UTCkcP0Ww/vRpoxUO14qhiA5YRXUUfRGQDUQ=; b=GEygsGWyyHXPpVwZ3peyK2mETuSAgCKQQnrwDfrjvmPaAb4VpyVf83+S0bEevG+HOn irmZ370AEmQkdklEcAatT4j+dg07qaNsEm7Fk4GvrcXM8obu67sEN3AOJq72Bah1OWhw Nmt/lE0/LvdkfQDc9pHb5DMOLykgA+BfIeUqxOkqNOQIEoJtUxgYlp3teP0Z0oYJlqKf w3OpWQ+3uUxservk8HFPNIDQPTtIr+gtMJxuxPQSVN0/sNHMIufOIgEnC64Stlf7Yeuy JGsdUuppgU31j9BXavg8ulaXi1fsWWYrWeK8QRfEqVYuuslXE6AI4/eDcNhoZctepObP m7oA== X-Gm-Message-State: AOAM530CD5skgEW45/i4fQjnthDfR4XiSEtmV5Am9HIUhyuEOT64FVgV iQPDhRdDbHzDnfVwBVa3Kl2jHnh5ew== X-Google-Smtp-Source: ABdhPJwD3s/910Iol89gEJEfDt7DKzR3qYGofsLPwy7XD4VIdBe93LDehux2u1ThOrZhdJtiUNzxFg== X-Received: by 2002:a63:ab0d:: with SMTP id p13mr9446466pgf.327.1596326211732; Sat, 01 Aug 2020 16:56:51 -0700 (PDT) Received: from aspen.local (63-140-73-54-rb1.jnu.dsl.dynamic.acsalaska.net. [63.140.73.54]) by smtp.gmail.com with ESMTPSA id h15sm15086474pfo.192.2020.08.01.16.56.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 01 Aug 2020 16:56:51 -0700 (PDT) To: "Schanzenbach, Martin" Cc: secdispatch@ietf.org References: <00a64a56-3c85-49ca-636c-25e39d4f659f@nomountain.net> From: Melinda Shore Autocrypt: addr=melinda.shore@nomountain.net; prefer-encrypt=mutual; keydata= mQINBFppZ0gBEADFwxAi5szDOsM/6+CH4pbYTX7D+2gjLY4xEE7ydQcAF1WVLvcWXrpZM0GO /eA4N1PJ+OT5o8o9zVr7izMJkiLwcnQmxHdlYgZ9E+Cm8hDtMyEPBQwsYTkE5kpbGCmBAZ+W rHNHjvDg366uZQHzJejenB1/V4+rxMZs1Ak34Az2MVOz9Doecaiadpw3NpH3+1VXY/qilqnM lznINSANqD0ktxB/CVKjxl3/K5JnVnLp0h2kiUqt19hQPX2JmLcgaHzu+Ceb34/HZWhs0CiF c4auhQ3A9PcccOprQh6IGW1xo6RP3OEbeRFqeovgBWS+DIWzMIM0a3G2LDid0889QYwEv0zZ RPDCcF3g15mlkeUUmwKQ6eAagPyTqLtTiOKULqy9bQahyX2eqlySrF+HqlwGeNoG+A4l1Z2Y S7NCBLPIzUk2RuSKMBaKw86ORzvg2Advrw4bdv7kbDkArGzywky61SEB/q+GqR466mekXx2F O+m8RuoSnWrBsKvD/bhELHcneorIBleGz+VL7i5adU0rIydG3jPTfUeXoCZIeNx1LannxnAR ihKdh5+FE26WiiK6VmZWkvFjaPFwWGjvAsi82Pd9QgHhnG/XzINpXw/3HF4wtBTU5nIExMzC +FbJxCPq1kXpqSxJqg7hgUFvD5jUD9lpN5Br/S2dUgJj95bbPQARAQABtCxNZWxpbmRhIFNo b3JlIDxtZWxpbmRhLnNob3JlQG5vbW91bnRhaW4ubmV0PokCVAQTAQoAPgIbAwUJCWdTAAUL CQgHAwUVCgkICwUWAgMBAAIeAQIXgBYhBE9oLZMqF5b4IPI0wN+4kXKadtuPBQJaaXRaAAoJ EN+4kXKadtuPVioP/3nVzx33yjiEtqLKTEHwofnLT15CV5wAcGa0DTbqgiomVKzSRkkhbF3Z KIHYrnjVpTcYJuW+PmFSIjNizNVr+vvjNP6ptRqx5orWmK4EBe/B9mrpmIshxUwkYr46uwN4 h06xJS3KCzhfhSsnesH5vlGBkUod0+nQhbSLyLRpxmaKaeAl4dxFSBLU0vUJMLH8PXTZVNof 5Yo+ThqCzu1pwOkBQ8gST2J6zdy4PjU9ENQ9RLAamlAG/6rGHEKLFcnUpEg7Tcu1hSzAsqR8 kjX2Prpu4A9DyLCjTOvfOPQa8WjZy18ZdYOxuPxdrTazeCRVJIvYRflhBCZb744jhMyfAiSW eckwRBVSCnBuvWBJl9Ua1wp8SOUXXhgGI8WGvSkvul6kKSkHQKDggd4cojAhxWLfvmjxn5pz 0BNbvrEBGqgWwO1ZMuJpmv3P8YK5Aytsl85NZoMMUJIDxEQhBUgYz5QTQANBKPi8RsfOntho rhzXLqnPPQcE4Xf9O9XIyy077F0JoyiPx74Zsl1dTxmT73pezpfhKUQR7/QlmJ/FAADpb6SO V0tlgBtR6FAZToBYPDiss57AcKM1zzyJ7sHIZkxQelykYSet6hp2WGcwMXQveWqFMQ4fiGQx XNEPO+KZKNj+0sfINzSLP88O5TniM/l/JrjZZNT/lVAQDTdkCBGyuQINBFppZ0gBEACgZuM1 8ghzSuhuv+n0kWyWCeEWrx9Ey03EgFj5alBt55+OLv3dOsdyBHJxjtd0cZS1XaKZlgr1YZ0O pQNv/Wyy8uSW2BZ6hyG1SKN9/1MmfJLNnjjxaBQP4yaMwDdS3wX7hoWY19IpVPZHYDR35FAg SnG/s6we+IOITM1TJoOJs4+ygeK5dC7LfRoj+lkEHYrTcglYVuwsyK2FNz/sF8kJW1fEZHM6 6phSbhCvwbECWbb4eDGXbKZY92W1RTQ5U5td8DMLXyYipQphrcoeRXpb18DbOnE0WwIQV0yB gc/rTiUt/wVjasd1RrsCPBQC/uJ+ZHknvr2MoxIWBBsRtKYHG66aOL+nDV8X1miuF6j4cztv gmdqrwPHpAKVxhfwd/G4suNBunYw4/kAV9b2+eidX5em3NtPPNl/qNjsmEHQGn/5JKRHRvQs 0yuigXDhN2N0keoHrbGCE8kyA/d83L7E9d95hsf3JxpRzmeaTze+NpcIaX5uXdKOaCBjLtx1 tOrDA4XX7Y3nY+waKZYa3RvC7yulFJiKfYWDSriWeQXcXj06p8H6vF6sy9LeX9xRRjTI7qDH FxwuMQIKGqgufXtxu0pxxcMqXTEUPZnxUWUvuFjjYvEmtO92+Ot/NuotV8JvRPwg2OnYjMJo dU1X7hzEs8djtgZG+t3FEGK3i1EJUQARAQABiQI8BBgBCgAmFiEET2gtkyoXlvgg8jTA37iR cpp2248FAlppZ0gCGwwFCQlnUwAACgkQ37iRcpp2248krg/9H896KtAQCAV0RcV3QqZ75iY5 pCxpRyxAaR0PjE5jiYV5gUHPCKtr9UPZt4Bi+bzNLQ2KJK6Rx4XNf5lQWopEo1IxtOiFPjkr QIpNkYmFWyOGpKpSIDhgsJpswZqxPDLpo+59GNlSUG6v3sMAnx+Gvtvqczkvg6UPDN/JYK75 BIGoCGZMyor1B0EmRYj98LdwjT95dQZXjZvWBDeIx+NxUZKoA7AlR/xgsN3PHGq4SApMLL0R /qbiLIzUPnTPt5sBs0peflVvMrtgIMiZ9FdYPE+VWy5+X2AmeFg6Zl5W76HQUP6eYZQV5abZ +iiW9lY1TmqsqpTIDu/ZMy7pLknxV5E1vQy+wsihluDYydaQ4HWoNaY7QFb+x7TsvjJRi+cH 7By4jxohTWUuaukuMmT0eEaesWJSraAmxsffqJwDpsi0chZskuXjEm9gX6rY7MhzOZl7Vz9F +6MYTtTmT1mpkLAMWf1/JuKUCfnSAHRlDxUOAG6QSJoHWAGqYy3XiF9bN63yQ6xllloSbbMv P9VW0e/iFKMKEIvfIvAg0IrlPcfKAGuuT1axwIU7da/N7LOcXyDDSEUuSzvXL/BkWyjxuLzd LY6eTvC6ZT/fA5iS/PAUj0WbrWNrHQtQ5OY2+al2v6JdLu/w6IZJCBpTosOAOzzmre+31fk1 HKwqd9xRxC8= Message-ID: <695d3ee9-3708-7d86-4862-34895d95aca2@nomountain.net> Date: Sat, 1 Aug 2020 15:56:47 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="JMUvx68eRa9T0nHhY21AAgp6GSfq7YoTA" Archived-At: Subject: Re: [Secdispatch] GNS at dinrg X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Aug 2020 23:56:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --JMUvx68eRa9T0nHhY21AAgp6GSfq7YoTA Content-Type: multipart/mixed; boundary="CeLnNeyrHJAsUwK7Qtmv1P8NZhiV49Tqw" --CeLnNeyrHJAsUwK7Qtmv1P8NZhiV49Tqw Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 7/31/20 8:31 AM, Schanzenbach, Martin wrote: > I hope I understand all of your points. The way I read the charter > of DINRG correctly, our draft would fit into the goals and > objectives of this WG, right?=20 Well, maybe. I'm not really sure what your goals are for the document. If it's to standardize a protocol, dinrg is definitely not the right place. If it's to refine the document, contribute to the research community, and find collaborators, sure, but that needn't entail draft adoption, or even publication as an internet draft. Note that it's actually possible to do both, although it's rare in practice (HIP had a research group for a few years, as one example). Also note that while CFRG occasionally publishes standards, I think it's alone in that among IRTF research groups, and is something of a (much-loved) aberration. Melinda --=20 Melinda Shore melinda.shore@nomountain.net Software longa, hardware brevis --CeLnNeyrHJAsUwK7Qtmv1P8NZhiV49Tqw-- --JMUvx68eRa9T0nHhY21AAgp6GSfq7YoTA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEET2gtkyoXlvgg8jTA37iRcpp2248FAl8mAUAACgkQ37iRcpp2 248Mdg//Xel/cJhvR+UrKMgu66v8eCFUzwavPtxvGpBZk2tA0Fz75U+LEhY2Qtpm 4J/rydZduN+F2XPecncT06HF1Djew+/5MpBn4GSoOcvcw2Xq4gVdVlfuSfIbN5Nx 6Xcb9vU8DeeG8QsWN33YW3ZI+qio3zi95QMV371QuWn+y6S6tT9bOgNoEtAtX/D3 m2577RzG7ZAAcilL4rPY9b5vBG/M4L305eKq4GuD76AYMiRiVhAosn4nihrbXxnN lCblCVr9SpQ2Sy9YYg5URua0qJxxNQuS2LCVNgsJZ2RoKzAlt1HtmyrVb2SDsKbn EVxA9Ya23nPpxet66ZFJ5jaAjYMzV0rQcajz1zZs3f0iHxe1z4UILhcsgQUqRwLz QipkJ23o1N4e/sDnR1a/1yc1rKt9za5EeUL6/dhY8J4JET850/YIfZcl2L88UFmm BPvamQG13/OH/ERE/iAs6bT5hXjJrCZooJh0yrHsHEyAHR7XPF9QOQj14VDUQmyX xCSKRhRFN3rNmt0No6ou4IbYDsforbEkz2FO2wdymSc5vAfvNczSLSGRJ9K/PyO4 832m8kJSBGLDvAujiRnPV4Llt5sWysO8IqreHRFhua7hur9dD3nVVYF7FTU8ySPv CY9WgIWZsokPABSrOUO29TB3VQt6wl6Na4nYwRCQxYO1kwyet0c= =3JhQ -----END PGP SIGNATURE----- --JMUvx68eRa9T0nHhY21AAgp6GSfq7YoTA-- From nobody Sat Aug 1 17:40:53 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68F603A07F4 for ; Sat, 1 Aug 2020 17:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.915 X-Spam-Level: X-Spam-Status: No, score=-1.915 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4w8HWGPvxX7L for ; Sat, 1 Aug 2020 17:40:48 -0700 (PDT) Received: from mail-ot1-f44.google.com (mail-ot1-f44.google.com [209.85.210.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE59E3A07F2 for ; Sat, 1 Aug 2020 17:40:48 -0700 (PDT) Received: by mail-ot1-f44.google.com with SMTP id y16so584834otj.12 for ; Sat, 01 Aug 2020 17:40:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5bFzK4k2YquaJn3aoOJXIMXDEBGuyaVfaLwhcHLIi80=; b=VW+Z6Eg+hsI42lPIIviOCXkftKD76M22uMswr/L2my97Fm9SWYN9ku6PhISqPq2Hmo +Tzlu9RHr8pROZQxptGm/qGnwnafn6BG34S7UfgYt4Y8CBguABWkjRGOOOIReJeWazuG 0hxh+g+BkQHd2nRoPM6TrAXUk2WWQlhBap3AKhmYyM0xtOGsmmiz1qxnJNeQpKs1wDMb oVy6p/DNXHn+DoYmUUJTFgotXwTrRFmK7qmk9IfdUSh601B+983l93PWIdOvhUWQUGox FLaGOzQ8OUwGNuZl39p6p1+m1+o/Pxaavoli56CB4HrDnHV1wkrM2/QMNlKV/KpEeUeL G+lg== X-Gm-Message-State: AOAM533XnuuRor/tz5KZSvPeUgbngyBETZ0d2lOaqVa+F1gz37iXuGNN KaUQ458OWXObSJG5Ony7HRIcZR/scxVvXAAPb0o= X-Google-Smtp-Source: ABdhPJycp4Sg6KFsyaQ45NbvEQyNL1+WIySiEPhFVG0FTJAZl2+JVyWRKzfkEREe8uQWPWkUsrKQ0La9l9ISvOZVWJs= X-Received: by 2002:a9d:7319:: with SMTP id e25mr9074218otk.155.1596328848070; Sat, 01 Aug 2020 17:40:48 -0700 (PDT) MIME-Version: 1.0 References: <00a64a56-3c85-49ca-636c-25e39d4f659f@nomountain.net> <695d3ee9-3708-7d86-4862-34895d95aca2@nomountain.net> In-Reply-To: <695d3ee9-3708-7d86-4862-34895d95aca2@nomountain.net> From: Phillip Hallam-Baker Date: Sat, 1 Aug 2020 20:40:37 -0400 Message-ID: To: Melinda Shore Cc: "Schanzenbach, Martin" , IETF SecDispatch Content-Type: multipart/alternative; boundary="000000000000ef1c9805abda4502" Archived-At: Subject: Re: [Secdispatch] GNS at dinrg X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2020 00:40:51 -0000 --000000000000ef1c9805abda4502 Content-Type: text/plain; charset="UTF-8" I second the proposal to consider an IRTF group. One Way Sequence based naming is something we should have been looking at since the Haber Stornetta Surety patent expired. Could apply the same approach to RPKI and even (one day) DNS. On Sat, Aug 1, 2020 at 7:57 PM Melinda Shore wrote: > On 7/31/20 8:31 AM, Schanzenbach, Martin wrote: > > I hope I understand all of your points. The way I read the charter > > of DINRG correctly, our draft would fit into the goals and > > objectives of this WG, right? > > Well, maybe. I'm not really sure what your goals are > for the document. If it's to standardize a protocol, dinrg > is definitely not the right place. If it's to refine > the document, contribute to the research community, and > find collaborators, sure, but that needn't entail draft > adoption, or even publication as an internet draft. Note > that it's actually possible to do both, although it's rare > in practice (HIP had a research group for a few years, as > one example). Also note that while CFRG occasionally > publishes standards, I think it's alone in that among IRTF > research groups, and is something of a (much-loved) > aberration. > > Melinda > > -- > Melinda Shore > melinda.shore@nomountain.net > > Software longa, hardware brevis > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch > --000000000000ef1c9805abda4502 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I s= econd the proposal to consider an IRTF group.=C2=A0

One Way Sequence based naming is something we sh= ould have been looking at since the Haber Stornetta Surety patent expired. = Could apply the same approach=C2=A0to RPKI and even (one day) DNS.

On = Sat, Aug 1, 2020 at 7:57 PM Melinda Shore <melinda.shore@nomountain.net> wrote:
On 7/31/20 8:31 AM, Schanzen= bach, Martin wrote:
> I hope I understand all of your points. The way I read the charter
> of DINRG correctly, our draft would fit into the goals and
> objectives of this WG, right?

Well, maybe.=C2=A0 I'm not really sure what your goals are
for the document.=C2=A0 If it's to standardize a protocol, dinrg
is definitely not the right place.=C2=A0 If it's to refine
the document, contribute to the research community, and
find collaborators, sure, but that needn't entail draft
adoption, or even publication as an internet draft.=C2=A0 Note
that it's actually possible to do both, although it's rare
in practice (HIP had a research group for a few years, as
one example).=C2=A0 Also note that while CFRG occasionally
publishes standards, I think it's alone in that among IRTF
research groups, and is something of a (much-loved)
aberration.

Melinda

--
Melinda Shore
melinda.s= hore@nomountain.net

Software longa, hardware brevis

_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch
--000000000000ef1c9805abda4502-- From nobody Sun Aug 2 11:48:53 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4C863A0AC2 for ; Sun, 2 Aug 2020 11:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.005 X-Spam-Level: X-Spam-Status: No, score=0.005 tagged_above=-999 required=5 tests=[FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3RO-CC2rgdP for ; Sun, 2 Aug 2020 11:48:49 -0700 (PDT) Received: from mail-oi1-f196.google.com (mail-oi1-f196.google.com [209.85.167.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D07463A0AC1 for ; Sun, 2 Aug 2020 11:48:49 -0700 (PDT) Received: by mail-oi1-f196.google.com with SMTP id l84so18925429oig.10 for ; Sun, 02 Aug 2020 11:48:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=dCnEOmVhjcJHqYGe+A38AWfFpwFRwfh2Fhkauqd6jXY=; b=QWDuoE++ev7JWG41RYd/DBA+03/85euLISjQIwnV6AA+YJy6UealpJIbvmkpWsT2Of wpWL2OuIfio5izQZPxg2nwEAQunN1W7zfoJnU0JEolE4b6PLy24G+JIx2j6pmjdNRlUh G2sP3+vLNmXicdFQQXwFM71sngnqJeWGxx2BT3/Y68+IShnebxcDfzSakVoy19tJV3IV 7HzYQhWHQ26b8vzhZtOcBqogJgs6CK/PiPJxcUwnKYpGavmKW311X8HCBT/7XnHwP+77 mkOu90veBE1sRGOZQzTl6N/ynXSlVinXgAsF/KRQ486c3Iwg+iCsy1SZ9s2E0bQ81VWh rfDQ== X-Gm-Message-State: AOAM531/OFulLJAtdK6IGUCTjg7dCXHMZq9bpKFk+Nhaqn0S510usqbo F4irDs+gS7G7Kw3dAEHnWh6oEpAgJVkZGpFb6TEKAGQ6M/E= X-Google-Smtp-Source: ABdhPJwmEA55wlBsQJqC1fg4su/Py7HHJ/LzJYZWjnC0T3+WagJAhbqidjsXEQTzm9FgDZsk8eCEUYwkuBspDNmJI+Q= X-Received: by 2002:aca:fcd2:: with SMTP id a201mr10448638oii.166.1596394128588; Sun, 02 Aug 2020 11:48:48 -0700 (PDT) MIME-Version: 1.0 From: Phillip Hallam-Baker Date: Sun, 2 Aug 2020 14:48:38 -0400 Message-ID: To: IETF SecDispatch Content-Type: multipart/alternative; boundary="000000000000f4c41e05abe97851" Archived-At: Subject: [Secdispatch] One way sequence based naming X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2020 18:48:52 -0000 --000000000000f4c41e05abe97851 Content-Type: text/plain; charset="UTF-8" I was doing HOPE and IETF in parallel. I support doing research work on new naming schemes but I think we should limit I*TF input to research at this stage. Among the naming infrastructures that currently interest me: * Routing: AS to IP Address block mapping * Trusted discovery: Validated real world names -> Internet Services * Portable accounts: Text identifiers -> key fingerprint When looking at these issues, the first concern of many is of course the risk that their own business model might be threatened. That is why I never come to IETF for permission to do anything. Of course, the DNS is not going to disappear overnight. Nor is the RPKI. But that doesn't mean that these are the only naming systems that can ever exist on the Internet. It will be a very long time before telephone numbers disappear entirely. The gap in the registry market at present is in portable account identifiers. I am hallam@gmail.com and phill@hallambaker.com. The first name exists only as long as gmail.com wills it, I am at their mercy. hallambaker.com belongs to me, I have autonomy but that costs me $10/year and the name doesn't actually belong to me, I merely have use of it. I believe that there is value in a personal identifier registry offering irrevocable identifiers. So being a Bond/TNG fan and wishing to reclaim the id from a bigot, I have the handle Q, thus: q: udf: MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4 service: cryptomesh.com dns: ipv4:10.1.2.3 suffix: .not-an-icann-domain I will get back to the interpretation later. For now, the point is that this allows me to resolve names of the form @q (to message me) or @q.www and these names are fixed in all time and do not depend on ICANN's DNS product in any shape or form. Having worked on DNS, WebPKI, etc, I think I have some understanding of where the costs come from. The DNS is expensive to run because the DNS protocol supports three very different types of service in a single protocol and that means that the infrastructure that supports discovery of the microsoft.com name server has to meet the low latency and rapid up date requirements of discovery of a service www.microsoft.com. I am pretty sure the world would manage just fine if the rules for updating domains in .com were that updates take 60 seconds to process with a (small) charge for each update. These constraints allow a zone file to be represented as an authenticated append only sequence. Updates are consolidated into blocks with a new block being added once a minute. Authentication is provided by a Merkle tree over the sequence of blocks meaning that the cryptographic overhead of authenticating the service is fixed regardless of load. If the number of updates were limited to an average of one per domain per year, the entire .com domain would generate less than 100GB of data per year. Every recursive resolver operated at the ISP level can keep a complete copy. Names do not expire and all costs of the registry depend only on the number of updates. The ruinous costs of running core DNS have been avoided because the registry operator is insulated from DDoS attacks. Open Source software works because the marginal cost of providing service is essentially nil. Open services are more difficult because 5 billion users times a small cost is a large cost. Based on my experience, I expect running such a registry would cost less than $250,000/yr + $0.01 per transaction. So the registry would break-even at 2.5 million registrations a year at $0.10 each. I am not going to go into the business model further here. The point is merely to show that this doesn't depend on me continuing to fund the Mesh Foundation. When I started designing this system, my goal was limited to providing a registry that allows Mesh messaging users to interact using names that give them personal autonomy. So I could use the free service and be q@cryptomesh.com or I could pay cryptomesh for their paid premium service and they would register @q for me. And now I can change my mesh service provider any time I like and nobody needs to change their contact. What this gives here is a human intelligible, life-long permanent identifier that people could use to contact others for Mesh Messaging that has a strong binding to a signature verification key. The same approach can be applied to services to make them censorship proof: I have my personal Web site at https://hallambaker.com/. We can convert that into a domain name as follows: To resolve @q.www 1) @q.www + q.not-an-icann-domain -> www.q.not-an-icann-domain 2) Resolve www.q.not-an-icann-domain using the authoritative DNS service at 10.1.2.3 So all we need to make this approach compatible with existing Web Browsers is a way of encoding @q.www in some reserved partition of the DNS space: http://www.q.mesh.arpa/ This can all be fixed up to provide a seamless experience for users of legacy browsers. Basically, mesh.arpa would have to be delegated to some organization that provides a DNS resolver that provides the necessary redirect. But the objective here would be for browsers to use a resolution protocol that performs validation of that chain against the trust root for @q. Oh and as for anonymity. Threshold key generation provides a simple means of using one signature key to manage any number of domains using a different key for each. People already do this with bitcoin wallets. So I can run @q and @phb without disclosing that they are both me. The chief cost of running such a registry would be the inevitable trademark issues. But these can also be handled on a fee per transaction basis starting with a significant fee for registering a claim. If someone is paying a lawyer $600/hr to police a trademark, they can reimburse the registry for the cost of processing claims. That is a separate can of worms to the technical side of things. --000000000000f4c41e05abe97851 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I was doing HOPE and IETF in p= arallel. I support doing research work on new naming schemes but I think we= should limit I*TF input to research at this stage.

Among the naming infrastructures that currently = interest me:
* Routing: A= S to IP Address block mapping

* Trusted discovery: Validated real world names -> Internet Service= s=C2=A0

* Portable accoun= ts: Text identifiers -> key fingerprint

When looking at these issues, the first concern of many i= s of course the risk that their own business model might be threatened. Tha= t is why I never come to IETF for permission to do anything. Of course, the= DNS is not going to disappear overnight. Nor is the RPKI. But that doesn&#= 39;t mean that these are the only naming systems that can ever exist on the= Internet. It will be a very long time before telephone numbers disappear e= ntirely.

The gap in the r= egistry market at present is in portable account identifiers. I am hallam@gmail.com and phill@hallambaker.com. The first name exists only a= s long as gmail.com wills it, I am at thei= r mercy. hallambaker.com belongs to = me, I have autonomy but that costs me $10/year and the name doesn't act= ually belong to me, I merely have use of it.

I believe that there is value in a personal identifier= registry offering irrevocable identifiers. So being a Bond/TNG fan and wis= hing to reclaim the id from a bigot, I have the handle Q, thus:

q:=C2=A0
=C2=A0 =C2=A0udf:=C2=A0=C2=A0MB5S-R4AJ-3FB= T-7NHO-T26Z-2E6Y-WFH4
=C2=A0 =C2=A0service: cryptomesh.c= om
=C2=A0 = =C2=A0dns:
=C2= =A0 =C2=A0 =C2=A0 =C2=A0ipv4:10.1.2.3
=C2=A0 =C2=A0 =C2=A0 =C2=A0suffix: .not-an-icann-dom= ain

<= div class=3D"gmail_default" style=3D"font-size:small">I will get back to th= e interpretation later. For now, the point is that this allows me to resolv= e names of the form=C2=A0@q (to message me) or=C2=A0@q.www and these names = are fixed in all time and do not depend on ICANN's DNS product in any s= hape or form.
<= br>
Having work= ed on DNS, WebPKI, etc, I think I have some understanding of where the cost= s come from. The DNS is expensive to run because the DNS protocol supports = three very different types of service in a single protocol and that means t= hat the infrastructure that supports discovery of the microsoft.com name server has to meet the low latency and r= apid up date requirements of discovery of a service www.microsoft.com.

I am pretty sure the world would manage just fine if the rules = for updating domains in .com were that updates take 60 seconds to process w= ith a (small) charge for each update.

These constraints allow a zone file to be represented as an au= thenticated append only sequence. Updates are consolidated into blocks with= a new block being added once a minute. Authentication is provided by a Mer= kle tree over the sequence of blocks meaning that the cryptographic overhea= d of authenticating the service is fixed regardless of load.

If the number of updates were limited t= o an average of one per domain per year, the entire .com domain would gener= ate less than 100GB of data per year. Every recursive resolver operated at = the ISP level can keep a complete copy.

Names do not expire and all=C2=A0costs of the registry depen= d only on the number of updates. The ruinous costs of running core DNS have= been avoided because the registry operator is insulated from DDoS attacks.= =C2=A0

Open Source softwa= re works because the marginal cost of providing service is essentially nil.= Open services are more difficult because 5 billion users times a small cos= t is a large cost.

Ba= sed on my experience, I expect running such a registry would cost less than= $250,000/yr=C2=A0+=C2=A0$0.01 per transaction. So the registry would break= -even at 2.5 million registrations a year at $0.10 each. I am not going to = go into the business model further here. The point is merely to show that t= his doesn't depend on me continuing to fund the Mesh Foundation.
=

When I started designing this = system, my goal was limited to providing a registry that allows Mesh messag= ing users to interact using names that give them personal autonomy. So I co= uld use the free service and be q@crypt= omesh.com or I could pay cryptomesh for their paid premium service and = they would register=C2=A0@q for me. And now I can change my mesh service pr= ovider any time I like and nobody needs to change their contact.

What this gives here is a human int= elligible, life-long permanent identifier that people could use to contact = others for Mesh Messaging that has a strong binding to a signature verifica= tion key.

<= /div>
The same approa= ch can be applied to services to make them censorship proof:

I have my personal Web site=C2=A0at https://hallambaker.com/. We can conv= ert that into a domain name as follows:

To resolve @q.www

1) @q.www=C2=A0+=C2=A0q.not-an-icann-domain -> www.q.not-an-ican= n-domain
2) Res= olve=C2=A0www.q.not-an-icann-domain using the authoritative DNS service at = 10.1.2.3

So all we need t= o make this approach compatible with existing Web Browsers is a way of enco= ding=C2=A0@q.www in some reserved partition of the DNS space:

ht= tp://www.q.mesh.arpa/

This can all be fixed up to provide a seamless experience for users of leg= acy browsers. Basically, mesh.arpa would have to be delegated to some organ= ization that provides a DNS resolver that provides the necessary redirect.<= /div>

But the objective here wo= uld be for browsers to use a resolution protocol that performs validation o= f that chain against the trust root for=C2=A0@q.

Oh and as for anonymity. Threshold key generation p= rovides a simple means of using one signature key to manage any number of d= omains using a different key for each. People already do this with bitcoin = wallets. So I can run=C2=A0@q and=C2=A0@phb without disclosing that they ar= e both me.

=

The chief cost of runnin= g such a registry would be the inevitable trademark issues. But these can a= lso be handled on a fee per transaction basis starting with a significant f= ee for registering a claim. If someone is paying a lawyer $600/hr to police= a trademark, they can reimburse the registry for the cost of processing cl= aims. That is a separate can of worms to the technical side of things.
--000000000000f4c41e05abe97851-- From nobody Mon Aug 3 10:58:57 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8133A080E for ; Mon, 3 Aug 2020 10:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.201 X-Spam-Level: X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 iQyjLIP7CD8k for ; Mon, 3 Aug 2020 10:58:54 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650126.outbound.protection.outlook.com [40.107.65.126]) (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 83D6B3A07F7 for ; Mon, 3 Aug 2020 10:58:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kEpD3tFYcFpZTJup8I26GX8gXSp8KMAQFPt0qfa1hw8xImxHdNVguFCcIS/McCl5cVfpB7oNrcN8KpcK9EhnrfeSWWx7xoR6mm6JoCJtWemUp49bRIuS3r696KZmBD+TNVguX8h+0GIpDO6wyu53EQ9O6A3/MFAQN0ILF3AsDKVc+SeJWEUePlgvCtcqJunbgo4KWNiZx0oczQHhia0vZNTyQ7Jqpy+jY8J7he3M9gMQP3HChJk9Q/ap2aFOR4EW3gTmVWdXOMstn8nrDU0/fxKJdEz1dVm62oNHsg36MlPrLoxlM+UZDxwWKtNpHxL7YYjFu5vIpOi33763JUXKYg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4lIaxqOh6fqXd59THuTJqUQWYjbUQoLL+dP1oAu+XB0=; b=R6IIhHAuq8bpUtmPwHlDSB7+L5DI1iSdCYUJ5CWGyTWeKjWJ2JeyD2phnNFFFZFCJ0En17DKAVEsahiTxNsgjbzJ6dLLEVA+7i6ostgsudSWZX4sZSkDXZhhXljg5C2OXFnbncykQFIKYf4I14DboJ8vH5wij/W/9+ZoDbxGt593gz1tzgv445DRVgWprpWKCsb5/AhxxNDZ59Wj/nUbcMYZ8nsUFzUmU4hh6kAOkbXro/xQbv1CLyiOwHxuW3meLiKcCh6HS/9z1KoTAKfvMPJBNJzIvgDdi+c1SYfsrooKPnZIQKicd+wgRfU4emCgoJZ7DUhvIpYeMG3wB7rQ9A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4lIaxqOh6fqXd59THuTJqUQWYjbUQoLL+dP1oAu+XB0=; b=QNjQUk8Vc81MbzAzJ6Zb0CESdz8cQSk/q3PFoPfNavmmjdLnCz4FlVOeJtqaGI6bXOKI2lODKgSnSoAWrZyZntsQmkYhSRu+gTd/cYy3TNOQXXQeJXoWOq0v54u0SibSAk6G+4imvfClxgvsrnbeygeBfijVTvvExc8a5JN54Sw= Received: from DM6PR00MB0781.namprd00.prod.outlook.com (2603:10b6:5:1b5::20) by DM6PR00MB0604.namprd00.prod.outlook.com (2603:10b6:5:161::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3293.0; Mon, 3 Aug 2020 17:58:51 +0000 Received: from DM6PR00MB0781.namprd00.prod.outlook.com ([fe80::e898:2d46:56a9:b23e]) by DM6PR00MB0781.namprd00.prod.outlook.com ([fe80::e898:2d46:56a9:b23e%4]) with mapi id 15.20.3297.000; Mon, 3 Aug 2020 17:58:51 +0000 From: Tommy Jensen To: "secdispatch@ietf.org" Thread-Topic: Appropriate WG for secure communication between networks and unknown clients Thread-Index: AQHWab6UEZ3ibCpa+UClcdav7HSkhA== Date: Mon, 3 Aug 2020 17:58:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-08-03T17:58:51.637Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2601:600:a080:aff0:298e:f227:e512:f71d] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 2c3e44f1-b0ab-417c-b058-08d837d6e179 x-ms-traffictypediagnostic: DM6PR00MB0604: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: g4pNsYwwABSKD6KfGrNo41WO3pq3QbxgtipACnLi+fNJeYvukFGxizjtQM96QbWPC/QJ7fC3sdvzfrjs7Tj3c+ejavY/l7QIDOM69k2WW6R02AkSdSB0m3PvT3NcHuwL20jwUayT93lFqHcw353ZexvOe93o3oKtB0768Pnrk5b4UyQfQmlbPhh5CQZMD+l3ssC2KYCYh+zFv3K8dHHTr88QV9BDOBhA85OmnUnRrzAeZGqG4aTiUU7Qu6e1le+BvLu1qJ7LSOC0teohiutJya6LmGNQ8P/VekQv6Tl2hQurXhrL6bP2a8HhrwSB0HsbO4s8QwQgsaO5J7bUSXOrQg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR00MB0781.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(376002)(136003)(39860400002)(366004)(396003)(6916009)(71200400001)(82950400001)(82960400001)(478600001)(55016002)(9686003)(5660300002)(52536014)(2906002)(6506007)(66446008)(7696005)(8676002)(316002)(8990500004)(33656002)(64756008)(86362001)(83380400001)(76116006)(66476007)(66946007)(186003)(91956017)(8936002)(19627405001)(66556008)(10290500003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 8eyDmeFFGaPrNAyG3IGZh4IQJhrT2Ah9Z7R/gY6mfgSohjSIMyFhotGVS29YQ3LQzpsRN7n58+bfO00Bb/ow7VnGt1RS3Ot0Rki3Hl6+j1HKzSVy8rvDoNPe6tAKAbUbkTCI9FUhfPub/jOP2sxb0N2TdbsEgHSXrg6rccLwoADs3qkx+jSZbg38CNkr23f+KtClau5mphwFCiP7qcQKvk2O7cq+6/bfPwDy0gt140flbKmAnE9b/4h7Bw2wXlTNY8brbwPo2jxt2idl/TFDYS0IKamwf/obQGpK8Hmme/qnxx5JBrIoCdDRys7w1gk+dsxf52Q+cgvCcaSboPSUBU9nhpbd40pdfD24G67mqFqe1pxpR9jjef9371ftlCUwHIvEFJJA7o4hd6yCb+H7Rb4I8kwQhS0UULCVMkaqTIxP0F1CZjxhleZsnLgCXNonvxDPTN6VsKOvBgnpvMbCkMmr+HXPuHwOnoIcyPHDp8qIgqF2EhrrvVOLTPPo/r7IMOTiGfNe3MPqlmA1YnehxqgKsNxQdbuBZquz6n4Q0ARCMW1Hg8KTOcfRpXAOPipxoojRFJUzxHSxGSB7gU0dOv+MO5vzuQQ7mwHPE2S1u/fRmfjbYaLNh0Mr574uBcpiikFibTZiqT49P2oQpBstIeZn6USD+P51PXC4aFD0HyIu5L8JyhnnFTuvihrVOnttI9hP8fw1w7JHGRILY/yHHQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR00MB0781A2E5741B0C0D4CC5D2B3FA4D0DM6PR00MB0781namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR00MB0781.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2c3e44f1-b0ab-417c-b058-08d837d6e179 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2020 17:58:51.7516 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Atr3tOmO3o4etTvvz4AmNr26OmLVhmGCxUV/Q92DoKpiRK5jNyUx9gL5dJX9Pw4m8A2uRFFScSdvKJUEyM4sKg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0604 Archived-At: Subject: [Secdispatch] Appropriate WG for secure communication between networks and unknown clients X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2020 17:58:56 -0000 --_000_DM6PR00MB0781A2E5741B0C0D4CC5D2B3FA4D0DM6PR00MB0781namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hey SECDISPATCH, In the ADD WG, there's been a lot of discussion on the topic of secure comm= unication between networks and clients that aren't preconfigured. The conte= xt is how a network can convince a client, which has no out-of-channel conf= iguration to use for confirming network identity, that it has recommendatio= ns that can be distinguished from an attacker on the network. This was brought up in our WG as part of the "Network A recommends DNS serv= er B" which is done over DHCP or RAs today. With encrypted DNS protocols no= w available, we want to allow a network to advertise its own encrypted DNS = servers. However, if we use DHCP or RAs as they are defined today, this can= be hijacked by an attacker to convince clients to setup secure connection = to an attacker's server. We know secured network configuration without out-of-band configuration is = a hard problem but want to discuss it in a larger context than just DNS so = we don't try to define a mechanism that cannot be reused by other scenarios= . This mailing list was recommended in our IETF 108 WG session as a good co= ntact for helping us find the right audience for this discussion. Any thoug= hts? Thanks, Tommy Jensen --_000_DM6PR00MB0781A2E5741B0C0D4CC5D2B3FA4D0DM6PR00MB0781namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hey SECDISPATCH,

In the ADD WG, there's been a lot of discussion on the topic of secure comm= unication between networks and clients that aren't preconfigured. The conte= xt is how a network can convince a client, which has no out-of-channel conf= iguration to use for confirming network identity, that it has recommendations that can be distinguished fr= om an attacker on the network.

This was brought up in our WG as part of the "Network A recommends DNS= server B" which is done over DHCP or RAs today. With encrypted DNS pr= otocols now available, we want to allow a network to advertise its own encr= ypted DNS servers. However, if we use DHCP or RAs as they are defined today, this can be hijacked by an attacker to c= onvince clients to setup secure connection to an attacker's server.

We know secured network configuration without out-of-band configuration is = a hard problem but want to discuss it in a larger context than just DNS so = we don't try to define a mechanism that cannot be reused by other scenarios= . This mailing list was recommended in our IETF 108 WG session as a good contact for helping us find the right= audience for this discussion. Any thoughts?

Thanks,=
Tommy Jensen
--_000_DM6PR00MB0781A2E5741B0C0D4CC5D2B3FA4D0DM6PR00MB0781namp_-- From nobody Mon Aug 3 12:36:42 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F26CF3A10B9 for ; Mon, 3 Aug 2020 12:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.004 X-Spam-Level: X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 PvwZWAwk-bwK for ; Mon, 3 Aug 2020 12:36:38 -0700 (PDT) Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F65C3A10AE for ; Mon, 3 Aug 2020 12:36:37 -0700 (PDT) Received: by mail-qv1-xf35.google.com with SMTP id a19so11910667qvy.3 for ; Mon, 03 Aug 2020 12:36:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=z5dpzAdhXQoHV0Nq6H6J96TO50htivcw5yz4KaXz7Wo=; b=p9hP0UDFTK+MRJC4KYEn5FTlZhdQwp/5LiP+YNOl6Vq9Ci0TUwAmA5XtV738zJ1hsH 3iV7aqmS9yxXvuB562V3/VxLN0AVFIMvqzK7PtdK0yAReFQuOZp8IWdIsKgAlgArlMtc 4GYRiLCQddg40I6phjncm959J0cTjad2qTkmkA+dtew4SHaZIG24Wr87sfV/w+BLxfXT afU//8opgKP3se21TPzfh7t/TSaWSRS6f0PY4h3cdCF3lzg2+aN4zasqMOyk+YUfpISM yOgwV5VmVUrZV1Uv4muLqs2V4YoujzUG6XUhASTKSG2bFXLTBqt6nnptoAZF/AQuVs8n h9Fw== 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=z5dpzAdhXQoHV0Nq6H6J96TO50htivcw5yz4KaXz7Wo=; b=s8Eu+g6n1pSMuB3hsRNUhJUil1uVHDxob7O//bHd2z/YUU68ckVWOYYuFQRvhBHPWh A5okirnwSCTrWWm/Wscci9GdulskXy7XvjvtcpkmFKVi2QwnSbGZaulkdXBeduisCXwP KdzLGjKcAPrjx5CjjSWV9ZOZdrw6ycp/GSsJqGp6icKUI8yHajXYA5Muy2tB7Dcso0zE Im1xHL5zek/flVqW1dOLeOM+rbbfHSYRpjF8HUCd+V9oSMnZnfGC6qI9C2/d/4GMyLQm Ctw8axwbTq8LI3Us5QGOpZNddowNpG/MwPKLgcn1zVSvzgkSclIz0CjIjMNMu2aS3YY6 BRWw== X-Gm-Message-State: AOAM533jq/OFAJVR95bTip0arYh5IoKjrLD1fLIjZZpGBhfDXN71BsMF Ohh76CzRy1wdWJZf7h+JnL3wj0Dl/ROQQNndiOP0v2msMBI= X-Google-Smtp-Source: ABdhPJwMj78HK4h28AQruoqMKc2zcV2LviTezsmnKdkoEOLFrUx0DDLKRDoU0nltRp2g8+wLpWZIZhk4U9XKekKEQ/g= X-Received: by 2002:ad4:564d:: with SMTP id bl13mr17726105qvb.60.1596483396647; Mon, 03 Aug 2020 12:36:36 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Mon, 3 Aug 2020 15:36:25 -0400 Message-ID: To: Tommy Jensen Cc: "secdispatch@ietf.org" Content-Type: multipart/alternative; boundary="000000000000bf566005abfe4132" Archived-At: Subject: Re: [Secdispatch] Appropriate WG for secure communication between networks and unknown clients X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2020 19:36:41 -0000 --000000000000bf566005abfe4132 Content-Type: text/plain; charset="UTF-8" Hey Tommy, Good question. It seems like there's a threshold question here of how the endpoint gets configured so that it can authenticate the network. In that regard, I don't think you're going to be able to avoid *some* out of band configuration. The silver lining seems to be, though, that there are lots of existing OOB-configured things available that one could imagine relying on -- from full 802.1X to simple WEP passwords. Also, if we can get a robust mechanism here, it would be useful for multiple things (just like DHCP is); for example, you could distribute captive portal / network access information that way. All of which sounds like a big enough piece of work to merit its own working group. Between the multiplicity of bootstrapping approachs you'll want to cover and the generality of the solution. Honestly, it might not even belong in the SEC area, since a lot of the considerations are more INT-like -- one way to read this is as S-DHCP. But this is a problem I would like to see solved. --Richard On Mon, Aug 3, 2020 at 1:59 PM Tommy Jensen wrote: > Hey SECDISPATCH, > > In the ADD WG, there's been a lot of discussion on the topic of secure > communication between networks and clients that aren't preconfigured. The > context is how a network can convince a client, which has no out-of-channel > configuration to use for confirming network identity, that it has > recommendations that can be distinguished from an attacker on the network. > > This was brought up in our WG as part of the "Network A recommends DNS > server B" which is done over DHCP or RAs today. With encrypted DNS > protocols now available, we want to allow a network to advertise its own > encrypted DNS servers. However, if we use DHCP or RAs as they are defined > today, this can be hijacked by an attacker to convince clients to setup > secure connection to an attacker's server. > > We know secured network configuration without out-of-band configuration is > a hard problem but want to discuss it in a larger context than just DNS so > we don't try to define a mechanism that cannot be reused by other > scenarios.. This mailing list was recommended in our IETF 108 WG session as > a good contact for helping us find the right audience for this discussion. > Any thoughts? > > Thanks, > Tommy Jensen > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch > --000000000000bf566005abfe4132 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Tommy,

Good question.=C2= =A0 It seems like there's a threshold question here of how the endpoint= gets configured so that it can authenticate the network.=C2=A0 In that reg= ard, I don't think you're going to be able to avoid *some* out of b= and configuration.=C2=A0 The silver lining seems to be, though, that there = are lots of existing OOB-configured things available that one could imagine= relying on -- from full 802.1X to simple WEP passwords.=C2=A0 Also, if we = can get a robust mechanism here, it would be useful for multiple things (ju= st like DHCP is); for example, you could distribute captive portal / networ= k access information that way.

All of which sounds= like a big enough piece of work to merit its own working group.=C2=A0 Betw= een the multiplicity of bootstrapping approachs you'll want to cover an= d the generality of the solution.=C2=A0 Honestly, it might not even belong = in the SEC area, since a lot of the considerations are more INT-like -- one= way to read this is as S-DHCP.

But this is a= problem I would like to see solved.

--Richard=


On Mon, Aug 3, 2020 at 1:59 PM Tommy Jensen <Je= nsen.Thomas=3D40microsoft= .com@dmarc.ietf.org> wrote:
Hey SECDISPATCH,

In the ADD WG, there's been a lot of discussion on the topic of secure = communication between networks and clients that aren't preconfigured. T= he context is how a network can convince a client, which has no out-of-chan= nel configuration to use for confirming network identity, that it has recommendations that can be distinguished fr= om an attacker on the network.

This was brought up in our WG as part of the "Network A recommends DNS= server B" which is done over DHCP or RAs today. With encrypted DNS pr= otocols now available, we want to allow a network to advertise its own encr= ypted DNS servers. However, if we use DHCP or RAs as they are defined today, this can be hijacked by an attacker to c= onvince clients to setup secure connection to an attacker's server.

We know secured network configuration without out-of-band configuration is = a hard problem but want to discuss it in a larger context than just DNS so = we don't try to define a mechanism that cannot be reused by other scena= rios.. This mailing list was recommended in our IETF 108 WG session as a good contact for helping us find the right= audience for this discussion. Any thoughts?

Thanks,
Tommy Jensen
_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch
--000000000000bf566005abfe4132-- From nobody Tue Aug 4 02:14:28 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D05E03A101A for ; Tue, 4 Aug 2020 02:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.949, 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=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TS1TlX7RRYuQ for ; Tue, 4 Aug 2020 02:14:25 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150082.outbound.protection.outlook.com [40.107.15.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6DE33A0C9D for ; Tue, 4 Aug 2020 02:14:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WgKrlx3uY30N2W/jRe8Db3x+P0AIjl0D0ozeQIOZhHmRfOuSvfD69rbVso2dKMMxMZYH2B8CYUOssJdQvUEvs0hw7YY9AcRWZHXoVUxwhRwm5SV6VlyaI0Sn+YZM/WpSld7o7LCe7lQFPrCdGmXUTX607e91eKysOwtsqhhn5qu9YFaEGJJvKBP9ACV/ARzw9w4Mec82Ub3a6gaXGk3jlkXxo6SBkG+2CcPRJ1ZM5/ox3QLO1B50jHvkH48UjrgMSQUhizf2iB+BZsKc1qIx5JIodni7BNEefMlup5pqog1uIy7jEZ1rbKs9AVBPlHcS2czYjbmc1CPVKZLzydf6pg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CzR3VTIKee+Pmkh1AQwOyTWClbHBwBV4HYvHP0qWLgg=; b=GTg1celnmN5aL3F1dUpYe9el4vMEFcyajZagnM+nWBBimwedrkVEhxhZEsiSWUqw3b36LmNa0/BOYHw2NtDGQfCjM+IMMck5ohmawQXedfGGzfDY9nSSCO5sp048WoVnbOmmRd11sVsJ4b3Xq4LGlnYM8sx72pmlDMcqn4oysNh8Em5c5a2aQUPKX4En/S0qNarl4IU5LZ0OgQWDnsUm0HS+mp91do6mdJMC5WCIVyYq3whnrJLCKQeWVb5zPqIiJtIVaeOhEDYuIsFc6adwvA9qtYAQa9F1xmgO4ez8e+DtJqHNRbGDtCrIbvDFwkxWkGF8rC2UlCfdwlejm9dfNA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none 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=CzR3VTIKee+Pmkh1AQwOyTWClbHBwBV4HYvHP0qWLgg=; b=cAvghm7wRctVVmMxkvUWzmCCDx4e2NnPviqNa8zxFhTcL+qz57ZRWsOAq68h/DPQHhGp5SIaPUHRZOzjHI3J9PnnEEsiczyEeem2SD/1QO06De9/IUSzT4PfnoZZAHJZU6RuoumnV561FKNaprINz2BbvbLrGkMCrGkNJN5Wbn0= Received: from HE1PR07MB3386.eurprd07.prod.outlook.com (2603:10a6:7:2d::25) by HE1PR0701MB2444.eurprd07.prod.outlook.com (2603:10a6:3:74::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.13; Tue, 4 Aug 2020 09:14:22 +0000 Received: from HE1PR07MB3386.eurprd07.prod.outlook.com ([fe80::e01c:9809:43db:67d3]) by HE1PR07MB3386.eurprd07.prod.outlook.com ([fe80::e01c:9809:43db:67d3%6]) with mapi id 15.20.3261.015; Tue, 4 Aug 2020 09:14:22 +0000 From: Mohit Sethi M To: Tommy Jensen , "secdispatch@ietf.org" Thread-Topic: [Secdispatch] Appropriate WG for secure communication between networks and unknown clients Thread-Index: AQHWaj+jQ94W82SDX0uDRvo9NBjbvg== Date: Tue, 4 Aug 2020 09:14:22 +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: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [2001:14bb:190:1611:c268:154d:c886:2d7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 53af6559-998b-4310-08ed-08d83856c6c9 x-ms-traffictypediagnostic: HE1PR0701MB2444: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: aqDgw1/3XUP7CcrBIwmQXVWuw2cPnSCLRq4wT9jq7EiXlJHlQs1DWrAB/ohTESS3fr0qHIVak9sWmFRgzU0IyPyjG4x1g21A79rZx5zDhC7d7oZIpa+U+W9W2IoMARQhz9zdFwEYemoDtuFSHmGPiz/Vprvc3GlU0ii6H2u7TUV3sCkkUpm6JpQx7AvH0V0g3hRA5lC/kXAH5OqfNFQguMS9y7GStJQCzG4GRahiahdU/sv+3jDLxO2dOK/k3laJhCGuhGBZkFXFKUG5TFI5/ot/LCwAYtTkZcww5j2wxg30oTZL6EXYNzF/HN5PBczgek/7dYqcUTK3GazL4bVYo1519OMv/ZB2hyW9VOIcB/7CXzJJLL1q5ZrGsKGVQSqS5NUZ6XafEkj24z7bmz/jJWk4GOGQaQQAQvB6i3T7AesvZAJ2vH5YmLQq8+6SAgxuUHx/ET+cIRiyNJlZy2uJRA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB3386.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(39860400002)(136003)(346002)(366004)(376002)(8676002)(2906002)(186003)(316002)(31686004)(83380400001)(31696002)(2616005)(86362001)(6486002)(166002)(110136005)(71200400001)(478600001)(966005)(8936002)(53546011)(6512007)(6506007)(76116006)(66476007)(66556008)(64756008)(66446008)(36756003)(66946007)(19627405001)(5660300002)(43740500002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: a14Dl8B9KXa8Q4YPREoUfJwjfdRRmm46FTBFrkEMx8hKE0AXIJhmKTNFmdmuFzLQZrJfAXgciSOIVwBxHDmiioa2Fav2Wx8KVpSaTw15HYvibmIBKzTLPxPTh3k3glq0++hky7/sLbKaASbJ0OxMtjuq1U0/TmA0LB2pxkLNcyXuXdrRjCkOkyx8sebjV8a9mKOEjTuSJdINQ3qlzliJCSZ8cSM/J4Bm6OOVghyjalLTvxbthu6X9ROmIRgFeVHtZRnZfyCiW1NhrazfnScuEioLDGIvCO9H3Lw5nRmeFUvrnUKtCP52+3u5yewv5Lh/iKDzUFvsLvVbKPt/xoxCgVzvHe67UkG+f9DM4lNXAS6wkm26UPkRK/EbzzPaWJ5kPal+5sYlnF9dx4IJc1/AUZJA98cNofAEQ2cGcENGE+aRZyJFZKYNldBdQMQKX2Jb2oQNCBhtgIcwkjdRttaY/Kf47XONiylagcP5mNXxV/PSF5wj04OvAhhTWtLVZZ7SSi8HEGZT9aZjnu5PZnLHSwwPsygPmqJjbeE638ocZR1CXOX3Qktxj7Ktn9BwioDM8GE8Z4VXzJDwfsEMsPttgOACk27F7b0RZIj7OPqbQcw3k+pRIadXZZ/zKUg6FtfmZpXe589afzcsjgwo1rWTgQzr2JcArDk289qjks6UqeYwCW39Dmlur+4rmv61He+m3uE7dkLvpn8xtyu4vJ5KeQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_d6e4b41f032e5325bed8e5454f7a5c83ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB3386.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 53af6559-998b-4310-08ed-08d83856c6c9 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2020 09:14:22.4452 (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-CrossTenant-userprincipalname: UBuHhQ2R+bOZdNejdNnzW4mi/+tOvq1t1QqMKbbkKbymBttarl39v7UinMGv9TQD6jAg+4Hp2KhPds5nE3G0IbWU7ifcEeGa4WRtgi05XJI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2444 Archived-At: Subject: Re: [Secdispatch] Appropriate WG for secure communication between networks and unknown clients X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 09:14:27 -0000 --_000_d6e4b41f032e5325bed8e5454f7a5c83ericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Tommy, Would it be fair to summarize your requirements as: - Client devices don't have any pre-configured credentials or information a= bout the network - No out-of-band configuration of any sort is possible In that case, I guess I don't have any black magic to offer. The only techn= iques that I am aware of are in research literature: see secure in-band pai= ring: https://www.usenix.org/legacy/events/sec11/tech/full_papers/Gollakota= .pdf --Mohit On 8/3/20 8:58 PM, Tommy Jensen wrote: Hey SECDISPATCH, In the ADD WG, there's been a lot of discussion on the topic of secure comm= unication between networks and clients that aren't preconfigured. The conte= xt is how a network can convince a client, which has no out-of-channel conf= iguration to use for confirming network identity, that it has recommendatio= ns that can be distinguished from an attacker on the network. This was brought up in our WG as part of the "Network A recommends DNS serv= er B" which is done over DHCP or RAs today. With encrypted DNS protocols no= w available, we want to allow a network to advertise its own encrypted DNS = servers. However, if we use DHCP or RAs as they are defined today, this can= be hijacked by an attacker to convince clients to setup secure connection = to an attacker's server. We know secured network configuration without out-of-band configuration is = a hard problem but want to discuss it in a larger context than just DNS so = we don't try to define a mechanism that cannot be reused by other scenarios= .. This mailing list was recommended in our IETF 108 WG session as a good c= ontact for helping us find the right audience for this discussion. Any thou= ghts? Thanks, Tommy Jensen _______________________________________________ Secdispatch mailing list Secdispatch@ietf.org https://www.ietf.org/mailman/listinfo/secdispatch --_000_d6e4b41f032e5325bed8e5454f7a5c83ericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi Tommy,


Would it be fair to summarize your requirements as:

- Client devices don't have any pre-configured credentials or informatio= n about the network

- No out-of-band configuration of any sort is possible


In that case, I guess I don't have any black magic to offer. The only te= chniques that I am aware of are in research literature: see secure in-band = pairing: https://www.usenix.org/legacy/events/sec11/tech/full_papers/Gollakota.pdf


--Mohit

On 8/3/20 8:58 PM, Tommy Jensen wrote:
Hey SECDISPATCH,

In the ADD WG, there's been a lot of discussion on the topic of secure comm= unication between networks and clients that aren't preconfigured. The conte= xt is how a network can convince a client, which has no out-of-channel conf= iguration to use for confirming network identity, that it has recommendations that can be distinguished fr= om an attacker on the network.

This was brought up in our WG as part of the "Network A recommends DNS= server B" which is done over DHCP or RAs today. With encrypted DNS pr= otocols now available, we want to allow a network to advertise its own encr= ypted DNS servers. However, if we use DHCP or RAs as they are defined today, this can be hijacked by an attacker to c= onvince clients to setup secure connection to an attacker's server.

We know secured network configuration without out-of-band configuration is = a hard problem but want to discuss it in a larger context than just DNS so = we don't try to define a mechanism that cannot be reused by other scenarios= .. This mailing list was recommended in our IETF 108 WG session as a good contact for helping us find the right= audience for this discussion. Any thoughts?

Thanks,=
Tommy Jensen

____________________________________=
___________
Secdispatch mailing list
=
Secdispatch@ietf.org
https://www.ietf.org/mailman/listinfo/secdispatch
--_000_d6e4b41f032e5325bed8e5454f7a5c83ericssoncom_-- From nobody Tue Aug 4 02:15:04 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 362C33A101E for ; Tue, 4 Aug 2020 02:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.949, 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=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PN3G9CJ45UBl for ; Tue, 4 Aug 2020 02:15:00 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2073.outbound.protection.outlook.com [40.107.20.73]) (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 D94E93A101D for ; Tue, 4 Aug 2020 02:14:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bqVxCsR+0cWzWD0pXsmwPrs5ToGnTu8LhdXc+81alXn8ywgRBn3e9Jm71Rd6Sxg3QQKldGsvZ5hH9vTnl3mAvX4TNLqNkiYpsIDQZn2dGAcYg8WkKUm+8zMVB+xKdq/tNaUd1PjyDvqmjIWilDkYwsqHso9CYRmDkK89MWXAnTHh4u+FkTxK9GvhrrmXsoHW8di4FjCKtzgvfFguvfo9giluyd9Bd7Cldw/U94gmS1cR60C5Ojf8++4MGvqfmdSkdSi3N6E19Y+rsLCJ2UjuDSr8sVEi1/9S8lMtw3pvhrKU+K8hHhVptuHgPFZ0nRrjeQtxm5060yQtjVnTQd7u/g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=P7QqP5WW+x2svbpDOukUqL8Km1Jt3C8wj/TkycMSIlA=; b=Ob95t1CEMwEHrYq+UQE4hgocxzTVnrPn5DnOe2O2u75cmLIk1NJWou6NNooG3nMxa+jowuYLAUFEaS059tND8IcQdRshRbEMou6jo86lR3CMe+g1DWCEJRQCJx3SR5vMqV0BKyZLfqNdgf6raYO2DV0CxMvFPMMfaZm21hWTvUkBbwV4aJUEUdI5SiWy2LFqgEfxGOcSToQHq+FSpWCul6szEfHuOHOR8ZpAQAMIT4oNyWlhNg+O7zFcNt15oytMlPhx23ocqliMMaoC7DTFoGopBvoB7TCJ4nKocz03xy8xgDTAxq2AGDFUWVi68aGEPXxErmxyLkQmWg1VIdgUYA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none 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=P7QqP5WW+x2svbpDOukUqL8Km1Jt3C8wj/TkycMSIlA=; b=p0bLGvCcffdH/uIoNHp886YzWe8xXwNsvrv2qtegb3N76E9VW+dS+XtVzRPwMDs2UxSYr0ORVMM3xH2FzJOYupfvZi7GZ8QOTKgj88rAmoj4bcpvYRlxVGYgUI46mQ3oxwD/uxmpcGqNoQcFIrjQkhXNKUxtTua5lmyJTeVZLUo= Received: from HE1PR07MB3386.eurprd07.prod.outlook.com (2603:10a6:7:2d::25) by HE1PR0701MB2444.eurprd07.prod.outlook.com (2603:10a6:3:74::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.13; Tue, 4 Aug 2020 09:14:57 +0000 Received: from HE1PR07MB3386.eurprd07.prod.outlook.com ([fe80::e01c:9809:43db:67d3]) by HE1PR07MB3386.eurprd07.prod.outlook.com ([fe80::e01c:9809:43db:67d3%6]) with mapi id 15.20.3261.015; Tue, 4 Aug 2020 09:14:57 +0000 From: Mohit Sethi M To: Richard Barnes , Tommy Jensen CC: "secdispatch@ietf.org" Thread-Topic: [Secdispatch] Appropriate WG for secure communication between networks and unknown clients Thread-Index: AQHWaj+4Q94W82SDX0uDRvo9NBjbvg== Date: Tue, 4 Aug 2020 09:14:57 +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: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 authentication-results: ipv.sx; dkim=none (message not signed) header.d=none;ipv.sx; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [2001:14bb:190:1611:c268:154d:c886:2d7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: de0779e4-b73c-4f4a-8dce-08d83856dbb3 x-ms-traffictypediagnostic: HE1PR0701MB2444: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: UU75vdWymudd1HHB/2ps7rAYXqplepHGaW0tnpt69AoPpCX0JHyE+sZn/omRyey3MB8yJBNw9uxXNDTUCo0L1MYvygLqEDR/6NUeBebMxIVfSmx7a0nJlqnPzw2F/ORKoaXhlJ0HtW9nU6uO/9KoqSOSzilGYqMlQ+rX1NNLzhljRUnj7lKaBig19G/yHXItLOx+RBfwlPhhQLMlTET4AN1heielfKjuOr6bf6H0DlSN+vsvCDUIw0xal84hmXBcxV4LNq7DMxhlKkg3wNuyi2Izj7OwzoQdazb65/PUCAQ1dOOIVh4idhqcSf9BxemMGv+XoKS14ZH9wOtnOoD/7O5ghp+OIoLY8hbYrHEqrcnq00CsEXS88MF0RWbmilEIwuD2CoXDKQaOPAS1A6XGCOOLSFwcrdjsAqAxgOLImLYOplHtyPB7008XRY3YiPMzeOwIxlj4U4L7aovFtkgSSA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB3386.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(39860400002)(136003)(346002)(366004)(376002)(8676002)(2906002)(186003)(316002)(31686004)(83380400001)(31696002)(2616005)(86362001)(6486002)(166002)(110136005)(71200400001)(478600001)(966005)(8936002)(53546011)(6512007)(6506007)(76116006)(4326008)(66476007)(66556008)(64756008)(66446008)(36756003)(66946007)(5660300002)(43740500002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: d05n0wGKC/XWg6by8Eb8FPuSgYN7AU+XMM7lLi7N4E3lCiTv59tUUsvA6OJi6GdrjRu8ZtxG2HeNIk1XzJR0GcHd6qJQLG28EEIkCOtIZ93EZxn/hXPCGdOePAad0AA+6zEGpig5QAlWHL+hNwYBJZUZSbiR7fYEqPJi2EvlGEF7njE3LEJ8yu2zTDI2fMlyg6GqCM5Lggm7rMjUNsmmPQmeMDbfIEM4mC4/86cyZllcNnc/G2RuGWsf0pgBnexSLBcocYOZCJVQ8OinfmfqbTqQEHOg+0ymitEBQPF/R8mhqjWK7/VjRyy1o7RVxQ1aOMFnJkSieaVwzqiIfV8cuRIhEO+xM686fEJ9bjeYPNHZuBM/owl4M7fozv76l1F9vwzaBqjGdavDXzpccDsZhpj9aWveK0kFa9qgpZLTgRHgREtFR7yvfyYTMUh+3UcYfxuFi9sceYjfOkBFtWuwCfWgCbeAHIUusjSnKt0AA+eRfJG9hWpMUNwedGFzEyypITcViQFE3ItzVidD9YedBxuIbWPBK9rKtPhGyiadCmc+SBGo+ehBZj7UBxQ7OE9MQs0+mOowwdx5OGqQNL0lXpg8Wc8/F+evKBeEPZb2MQjyU0zpts8Nj8Itg+4Q5YOJ7EJuvJz3STq40zPA6Z5i56UgC9yCHEkpGk7zspLkfw0RcaZO5FQWjUl4lUdxUrjnXClUoMGoHVPS4tqx0/8AAg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_c069bc56e0d80bd3ec121a0937de2b78ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB3386.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: de0779e4-b73c-4f4a-8dce-08d83856dbb3 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2020 09:14:57.5786 (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-CrossTenant-userprincipalname: I9T3JPXyFVkKmhCtjvPWUA9xMV+RHf/xPpOBUYBzgUmDEW3sjfSx/3xZAWTMPraiQrYQJFR2SXzNV8TMOL9G3qn6xAALpfIkb7OPq+EV9+I= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2444 Archived-At: Subject: Re: [Secdispatch] Appropriate WG for secure communication between networks and unknown clients X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 09:15:02 -0000 --_000_c069bc56e0d80bd3ec121a0937de2b78ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgYWdyZWUgdGhhdCBpdCB3b3VsZCBiZSBuaWNlIHRvIHNvbHZlIHRoaXMgcHJvYmxl bS4gSG93ZXZlciwgSSB3b3VsZCBsaWtlIHVzIHRvIHJlc2lzdCB0aGUgdGVtcHRhdGlvbiBvZiBk ZXNpZ25pbmcgeWV0LWFub3RoZXItcHJvdG9jb2wuDQoNCkFzIFJpY2hhcmQgbWVudGlvbmVkLCBJ RUVFIDgwMi4xWCBpcyBhIGdyZWF0IHRvb2wgYm94IHdoaWNoIGNhbiBwcm92aWRlOg0KLSBwZXIt ZGV2aWNlIGluZGl2aWR1YWwgY3JlZGVudGlhbHMgKHZzLiBuZXR3b3JrLXdpZGUgc2VjcmV0cykN Ci0gb3ZlciA1MiBFQVAgYXV0aGVudGljYXRpb24gbWV0aG9kcyB0byBjaG9vc2UgZnJvbQ0KLSBy ZXZvY2F0aW9uIG9mIGFjY2VzcyBvZiBpbmRpdmlkdWFsIGRldmljZXMgaXMgc3RyYWlnaHRmb3J3 YXJkDQotIHBvc3NpYmlsaXR5IG9mIGRldmljZSBpc29sYXRpb24gaW50byBzZXBhcmF0ZSBWTEFO cy4NCg0KVGhlIHBvcHVsYXIgNCAod2luZG93cywgaU9TLCBhbmRyb2lkLCBhbmQgbGludXgpIHN1 cHBvcnQgaXQgbmF0aXZlbHkuIEl0IGlzIHdpZGVseSBkZXBsb3llZCBpbiBlbnRlcnByaXNlIG5l dHdvcmtzLg0KDQpXaHkgbm90IHJldXNlIGl0IGluIHRoZSBuZXR3b3JrcyB0aGF0IHlvdSBoYXZl IGluIG1pbmQ/IEFuZCBhcyBzb21lb25lIHNhaWQgb24gdGhlIEFERCBtYWlsaW5nIGxpc3QsIGhv bWUgaXMgdGhlIG5ldyBvZmZpY2UgYW5kIGhvbWUgbmV0d29ya3MgYXJlIHRoZSBuZXcgZW50ZXJw cmlzZSBuZXR3b3Jrcy4gQWRtaXR0ZWRseSwgdGhlcmUgYXJlIHNvbWUgc3R1bWJsaW5nIGJsb2Nr cyB0aGF0IG1ha2UgdGhlIGRlcGxveW1lbnQgb2YgODAyLjF4IGNoYWxsZW5naW5nIGZvciBvcmRp bmFyeSB1c2Vycy4gSXQgd291bGQgYmUgZ3JlYXQgaWYgd2UgY291bGQgc29sdmUgdGhhdC4NCg0K LS1Nb2hpdA0KDQpPbiA4LzMvMjAgMTA6MzYgUE0sIFJpY2hhcmQgQmFybmVzIHdyb3RlOg0KSGV5 IFRvbW15LA0KDQpHb29kIHF1ZXN0aW9uLiAgSXQgc2VlbXMgbGlrZSB0aGVyZSdzIGEgdGhyZXNo b2xkIHF1ZXN0aW9uIGhlcmUgb2YgaG93IHRoZSBlbmRwb2ludCBnZXRzIGNvbmZpZ3VyZWQgc28g dGhhdCBpdCBjYW4gYXV0aGVudGljYXRlIHRoZSBuZXR3b3JrLiAgSW4gdGhhdCByZWdhcmQsIEkg ZG9uJ3QgdGhpbmsgeW91J3JlIGdvaW5nIHRvIGJlIGFibGUgdG8gYXZvaWQgKnNvbWUqIG91dCBv ZiBiYW5kIGNvbmZpZ3VyYXRpb24uICBUaGUgc2lsdmVyIGxpbmluZyBzZWVtcyB0byBiZSwgdGhv dWdoLCB0aGF0IHRoZXJlIGFyZSBsb3RzIG9mIGV4aXN0aW5nIE9PQi1jb25maWd1cmVkIHRoaW5n cyBhdmFpbGFibGUgdGhhdCBvbmUgY291bGQgaW1hZ2luZSByZWx5aW5nIG9uIC0tIGZyb20gZnVs bCA4MDIuMVggdG8gc2ltcGxlIFdFUCBwYXNzd29yZHMuICBBbHNvLCBpZiB3ZSBjYW4gZ2V0IGEg cm9idXN0IG1lY2hhbmlzbSBoZXJlLCBpdCB3b3VsZCBiZSB1c2VmdWwgZm9yIG11bHRpcGxlIHRo aW5ncyAoanVzdCBsaWtlIERIQ1AgaXMpOyBmb3IgZXhhbXBsZSwgeW91IGNvdWxkIGRpc3RyaWJ1 dGUgY2FwdGl2ZSBwb3J0YWwgLyBuZXR3b3JrIGFjY2VzcyBpbmZvcm1hdGlvbiB0aGF0IHdheS4N Cg0KQWxsIG9mIHdoaWNoIHNvdW5kcyBsaWtlIGEgYmlnIGVub3VnaCBwaWVjZSBvZiB3b3JrIHRv IG1lcml0IGl0cyBvd24gd29ya2luZyBncm91cC4gIEJldHdlZW4gdGhlIG11bHRpcGxpY2l0eSBv ZiBib290c3RyYXBwaW5nIGFwcHJvYWNocyB5b3UnbGwgd2FudCB0byBjb3ZlciBhbmQgdGhlIGdl bmVyYWxpdHkgb2YgdGhlIHNvbHV0aW9uLiAgSG9uZXN0bHksIGl0IG1pZ2h0IG5vdCBldmVuIGJl bG9uZyBpbiB0aGUgU0VDIGFyZWEsIHNpbmNlIGEgbG90IG9mIHRoZSBjb25zaWRlcmF0aW9ucyBh cmUgbW9yZSBJTlQtbGlrZSAtLSBvbmUgd2F5IHRvIHJlYWQgdGhpcyBpcyBhcyBTLURIQ1AuDQoN CkJ1dCB0aGlzIGlzIGEgcHJvYmxlbSBJIHdvdWxkIGxpa2UgdG8gc2VlIHNvbHZlZC4NCg0KLS1S aWNoYXJkDQoNCg0KT24gTW9uLCBBdWcgMywgMjAyMCBhdCAxOjU5IFBNIFRvbW15IEplbnNlbiA8 SmVuc2VuLlRob21hcz00MG1pY3Jvc29mdC4uY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MG1p Y3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCkhleSBTRUNESVNQQVRDSCwNCg0K SW4gdGhlIEFERCBXRywgdGhlcmUncyBiZWVuIGEgbG90IG9mIGRpc2N1c3Npb24gb24gdGhlIHRv cGljIG9mIHNlY3VyZSBjb21tdW5pY2F0aW9uIGJldHdlZW4gbmV0d29ya3MgYW5kIGNsaWVudHMg dGhhdCBhcmVuJ3QgcHJlY29uZmlndXJlZC4gVGhlIGNvbnRleHQgaXMgaG93IGEgbmV0d29yayBj YW4gY29udmluY2UgYSBjbGllbnQsIHdoaWNoIGhhcyBubyBvdXQtb2YtY2hhbm5lbCBjb25maWd1 cmF0aW9uIHRvIHVzZSBmb3IgY29uZmlybWluZyBuZXR3b3JrIGlkZW50aXR5LCB0aGF0IGl0IGhh cyByZWNvbW1lbmRhdGlvbnMgdGhhdCBjYW4gYmUgZGlzdGluZ3Vpc2hlZCBmcm9tIGFuIGF0dGFj a2VyIG9uIHRoZSBuZXR3b3JrLg0KDQpUaGlzIHdhcyBicm91Z2h0IHVwIGluIG91ciBXRyBhcyBw YXJ0IG9mIHRoZSAiTmV0d29yayBBIHJlY29tbWVuZHMgRE5TIHNlcnZlciBCIiB3aGljaCBpcyBk b25lIG92ZXIgREhDUCBvciBSQXMgdG9kYXkuIFdpdGggZW5jcnlwdGVkIEROUyBwcm90b2NvbHMg bm93IGF2YWlsYWJsZSwgd2Ugd2FudCB0byBhbGxvdyBhIG5ldHdvcmsgdG8gYWR2ZXJ0aXNlIGl0 cyBvd24gZW5jcnlwdGVkIEROUyBzZXJ2ZXJzLiBIb3dldmVyLCBpZiB3ZSB1c2UgREhDUCBvciBS QXMgYXMgdGhleSBhcmUgZGVmaW5lZCB0b2RheSwgdGhpcyBjYW4gYmUgaGlqYWNrZWQgYnkgYW4g YXR0YWNrZXIgdG8gY29udmluY2UgY2xpZW50cyB0byBzZXR1cCBzZWN1cmUgY29ubmVjdGlvbiB0 byBhbiBhdHRhY2tlcidzIHNlcnZlci4NCg0KV2Uga25vdyBzZWN1cmVkIG5ldHdvcmsgY29uZmln dXJhdGlvbiB3aXRob3V0IG91dC1vZi1iYW5kIGNvbmZpZ3VyYXRpb24gaXMgYSBoYXJkIHByb2Js ZW0gYnV0IHdhbnQgdG8gZGlzY3VzcyBpdCBpbiBhIGxhcmdlciBjb250ZXh0IHRoYW4ganVzdCBE TlMgc28gd2UgZG9uJ3QgdHJ5IHRvIGRlZmluZSBhIG1lY2hhbmlzbSB0aGF0IGNhbm5vdCBiZSBy ZXVzZWQgYnkgb3RoZXIgc2NlbmFyaW9zLi4gVGhpcyBtYWlsaW5nIGxpc3Qgd2FzIHJlY29tbWVu ZGVkIGluIG91ciBJRVRGIDEwOCBXRyBzZXNzaW9uIGFzIGEgZ29vZCBjb250YWN0IGZvciBoZWxw aW5nIHVzIGZpbmQgdGhlIHJpZ2h0IGF1ZGllbmNlIGZvciB0aGlzIGRpc2N1c3Npb24uIEFueSB0 aG91Z2h0cz8NCg0KVGhhbmtzLA0KVG9tbXkgSmVuc2VuDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KU2VjZGlzcGF0Y2ggbWFpbGluZyBsaXN0DQpTZWNk aXNwYXRjaEBpZXRmLm9yZzxtYWlsdG86U2VjZGlzcGF0Y2hAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NlY2Rpc3BhdGNoDQoNCg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KU2VjZGlzcGF0Y2ggbWFpbGlu ZyBsaXN0DQpTZWNkaXNwYXRjaEBpZXRmLm9yZzxtYWlsdG86U2VjZGlzcGF0Y2hAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NlY2Rpc3BhdGNoDQoNCg== --_000_c069bc56e0d80bd3ec121a0937de2b78ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPHA+SGksPC9wPg0K PHA+SSBhZ3JlZSB0aGF0IGl0IHdvdWxkIGJlIG5pY2UgdG8gc29sdmUgdGhpcyBwcm9ibGVtLiBI b3dldmVyLCBJIHdvdWxkIGxpa2UgdXMgdG8gcmVzaXN0IHRoZSB0ZW1wdGF0aW9uIG9mIGRlc2ln bmluZyB5ZXQtYW5vdGhlci1wcm90b2NvbC4NCjxicj4NCjwvcD4NCjxwPkFzIFJpY2hhcmQgbWVu dGlvbmVkLCBJRUVFIDgwMi4xWCBpcyBhIGdyZWF0IHRvb2wgYm94IHdoaWNoIGNhbiBwcm92aWRl Ojxicj4NCi0gcGVyLWRldmljZSBpbmRpdmlkdWFsIGNyZWRlbnRpYWxzICh2cy4gbmV0d29yay13 aWRlIHNlY3JldHMpPGJyPg0KLSBvdmVyIDUyIEVBUCBhdXRoZW50aWNhdGlvbiBtZXRob2RzIHRv IGNob29zZSBmcm9tIDxicj4NCi0gcmV2b2NhdGlvbiBvZiBhY2Nlc3Mgb2YgaW5kaXZpZHVhbCBk ZXZpY2VzIGlzIHN0cmFpZ2h0Zm9yd2FyZCA8YnI+DQotIHBvc3NpYmlsaXR5IG9mIGRldmljZSBp c29sYXRpb24gaW50byBzZXBhcmF0ZSBWTEFOcy4gPGJyPg0KPC9wPg0KPHA+VGhlIHBvcHVsYXIg NCAod2luZG93cywgaU9TLCBhbmRyb2lkLCBhbmQgbGludXgpIHN1cHBvcnQgaXQgbmF0aXZlbHku IEl0IGlzIHdpZGVseSBkZXBsb3llZCBpbiBlbnRlcnByaXNlIG5ldHdvcmtzLg0KPGJyPg0KPC9w Pg0KPHA+V2h5IG5vdCByZXVzZSBpdCBpbiB0aGUgbmV0d29ya3MgdGhhdCB5b3UgaGF2ZSBpbiBt aW5kPyBBbmQgYXMgc29tZW9uZSBzYWlkIG9uIHRoZSBBREQgbWFpbGluZyBsaXN0LCBob21lIGlz IHRoZSBuZXcgb2ZmaWNlIGFuZCBob21lIG5ldHdvcmtzIGFyZSB0aGUgbmV3IGVudGVycHJpc2Ug bmV0d29ya3MuIEFkbWl0dGVkbHksIHRoZXJlIGFyZSBzb21lIHN0dW1ibGluZyBibG9ja3MgdGhh dCBtYWtlIHRoZSBkZXBsb3ltZW50IG9mIDgwMi4xeA0KIGNoYWxsZW5naW5nIGZvciBvcmRpbmFy eSB1c2Vycy4gSXQgd291bGQgYmUgZ3JlYXQgaWYgd2UgY291bGQgc29sdmUgdGhhdC4gPGJyPg0K PC9wPg0KPHA+LS1Nb2hpdDxicj4NCjwvcD4NCjxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZpeCI+ T24gOC8zLzIwIDEwOjM2IFBNLCBSaWNoYXJkIEJhcm5lcyB3cm90ZTo8YnI+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNpdGU9Im1pZDpDQUwwMmNnUVB4V0JZN2RMNWZ0NmRRUFZu SmZDZmh3TVRIb1J2T2Z1amZaQnN6Qzg5eHdAbWFpbC5nbWFpbC5jb20iPg0KPGRpdiBkaXI9Imx0 ciI+DQo8ZGl2PkhleSBUb21teSw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pkdvb2Qg cXVlc3Rpb24uJm5ic3A7IEl0IHNlZW1zIGxpa2UgdGhlcmUncyBhIHRocmVzaG9sZCBxdWVzdGlv biBoZXJlIG9mIGhvdyB0aGUgZW5kcG9pbnQgZ2V0cyBjb25maWd1cmVkIHNvIHRoYXQgaXQgY2Fu IGF1dGhlbnRpY2F0ZSB0aGUgbmV0d29yay4mbmJzcDsgSW4gdGhhdCByZWdhcmQsIEkgZG9uJ3Qg dGhpbmsgeW91J3JlIGdvaW5nIHRvIGJlIGFibGUgdG8gYXZvaWQgKnNvbWUqIG91dCBvZiBiYW5k IGNvbmZpZ3VyYXRpb24uJm5ic3A7IFRoZSBzaWx2ZXIgbGluaW5nDQogc2VlbXMgdG8gYmUsIHRo b3VnaCwgdGhhdCB0aGVyZSBhcmUgbG90cyBvZiBleGlzdGluZyBPT0ItY29uZmlndXJlZCB0aGlu Z3MgYXZhaWxhYmxlIHRoYXQgb25lIGNvdWxkIGltYWdpbmUgcmVseWluZyBvbiAtLSBmcm9tIGZ1 bGwgODAyLjFYIHRvIHNpbXBsZSBXRVAgcGFzc3dvcmRzLiZuYnNwOyBBbHNvLCBpZiB3ZSBjYW4g Z2V0IGEgcm9idXN0IG1lY2hhbmlzbSBoZXJlLCBpdCB3b3VsZCBiZSB1c2VmdWwgZm9yIG11bHRp cGxlIHRoaW5ncyAoanVzdCBsaWtlDQogREhDUCBpcyk7IGZvciBleGFtcGxlLCB5b3UgY291bGQg ZGlzdHJpYnV0ZSBjYXB0aXZlIHBvcnRhbCAvIG5ldHdvcmsgYWNjZXNzIGluZm9ybWF0aW9uIHRo YXQgd2F5LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QWxsIG9mIHdoaWNoIHNvdW5k cyBsaWtlIGEgYmlnIGVub3VnaCBwaWVjZSBvZiB3b3JrIHRvIG1lcml0IGl0cyBvd24gd29ya2lu ZyBncm91cC4mbmJzcDsgQmV0d2VlbiB0aGUgbXVsdGlwbGljaXR5IG9mIGJvb3RzdHJhcHBpbmcg YXBwcm9hY2hzIHlvdSdsbCB3YW50IHRvIGNvdmVyIGFuZCB0aGUgZ2VuZXJhbGl0eSBvZiB0aGUg c29sdXRpb24uJm5ic3A7IEhvbmVzdGx5LCBpdCBtaWdodCBub3QgZXZlbiBiZWxvbmcgaW4gdGhl IFNFQyBhcmVhLCBzaW5jZQ0KIGEgbG90IG9mIHRoZSBjb25zaWRlcmF0aW9ucyBhcmUgbW9yZSBJ TlQtbGlrZSAtLSBvbmUgd2F5IHRvIHJlYWQgdGhpcyBpcyBhcyBTLURIQ1AuDQo8YnI+DQo8L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkJ1dCB0aGlzIGlzIGEgcHJvYmxlbSBJIHdvdWxk IGxpa2UgdG8gc2VlIHNvbHZlZC48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 Pi0tUmljaGFyZDxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJyPg0K PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9ImdtYWlsX2F0 dHIiPk9uIE1vbiwgQXVnIDMsIDIwMjAgYXQgMTo1OSBQTSBUb21teSBKZW5zZW4gJmx0O0plbnNl bi5UaG9tYXM9PGEgaHJlZj0ibWFpbHRvOjQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZyIg bW96LWRvLW5vdC1zZW5kPSJ0cnVlIj40MG1pY3Jvc29mdC4uY29tQGRtYXJjLmlldGYub3JnPC9h PiZndDsgd3JvdGU6PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUi IHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHgNCiAgICAgICAgICAwLjhleDtib3JkZXItbGVmdDox cHggc29saWQgcmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgZGlyPSJs dHIiPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxBcmlhbCxIZWx2ZXRpY2Esc2Fu cy1zZXJpZjtmb250LXNpemU6MTJwdDtjb2xvcjpyZ2IoMCwwLDApO2JhY2tncm91bmQtY29sb3I6 cmdiKDI1NSwyNTUsMjU1KSI+DQpIZXkgU0VDRElTUEFUQ0gsPC9kaXY+DQo8ZGl2IHN0eWxlPSJm b250LWZhbWlseTpDYWxpYnJpLEFyaWFsLEhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTox MnB0O2NvbG9yOnJnYigwLDAsMCk7YmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDI1NSwyNTUpIj4N Cjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxBcmlhbCxIZWx2 ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6MTJwdDtjb2xvcjpyZ2IoMCwwLDApO2JhY2tncm91 bmQtY29sb3I6cmdiKDI1NSwyNTUsMjU1KSI+DQpJbiB0aGUgQUREIFdHLCB0aGVyZSdzIGJlZW4g YSBsb3Qgb2YgZGlzY3Vzc2lvbiBvbiB0aGUgdG9waWMgb2Ygc2VjdXJlIGNvbW11bmljYXRpb24g YmV0d2VlbiBuZXR3b3JrcyBhbmQgY2xpZW50cyB0aGF0IGFyZW4ndCBwcmVjb25maWd1cmVkLiBU aGUgY29udGV4dCBpcyBob3cgYSBuZXR3b3JrIGNhbiBjb252aW5jZSBhIGNsaWVudCwgd2hpY2gg aGFzIG5vIG91dC1vZi1jaGFubmVsIGNvbmZpZ3VyYXRpb24gdG8gdXNlIGZvciBjb25maXJtaW5n DQogbmV0d29yayBpZGVudGl0eSwgdGhhdCBpdCBoYXMgcmVjb21tZW5kYXRpb25zIHRoYXQgY2Fu IGJlIGRpc3Rpbmd1aXNoZWQgZnJvbSBhbiBhdHRhY2tlciBvbiB0aGUgbmV0d29yay48L2Rpdj4N CjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksQXJpYWwsSGVsdmV0aWNhLHNhbnMtc2Vy aWY7Zm9udC1zaXplOjEycHQ7Y29sb3I6cmdiKDAsMCwwKTtiYWNrZ3JvdW5kLWNvbG9yOnJnYigy NTUsMjU1LDI1NSkiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxp YnJpLEFyaWFsLEhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZToxMnB0O2NvbG9yOnJnYigw LDAsMCk7YmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDI1NSwyNTUpIj4NClRoaXMgd2FzIGJyb3Vn aHQgdXAgaW4gb3VyIFdHIGFzIHBhcnQgb2YgdGhlICZxdW90O05ldHdvcmsgQSByZWNvbW1lbmRz IEROUyBzZXJ2ZXIgQiZxdW90OyB3aGljaCBpcyBkb25lIG92ZXIgREhDUCBvciBSQXMgdG9kYXku IFdpdGggZW5jcnlwdGVkIEROUyBwcm90b2NvbHMgbm93IGF2YWlsYWJsZSwgd2Ugd2FudCB0byBh bGxvdyBhIG5ldHdvcmsgdG8gYWR2ZXJ0aXNlIGl0cyBvd24gZW5jcnlwdGVkIEROUyBzZXJ2ZXJz LiBIb3dldmVyLCBpZiB3ZSB1c2UgREhDUA0KIG9yIFJBcyBhcyB0aGV5IGFyZSBkZWZpbmVkIHRv ZGF5LCB0aGlzIGNhbiBiZSBoaWphY2tlZCBieSBhbiBhdHRhY2tlciB0byBjb252aW5jZSBjbGll bnRzIHRvIHNldHVwIHNlY3VyZSBjb25uZWN0aW9uIHRvIGFuIGF0dGFja2VyJ3Mgc2VydmVyLjwv ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxBcmlhbCxIZWx2ZXRpY2Esc2Fu cy1zZXJpZjtmb250LXNpemU6MTJwdDtjb2xvcjpyZ2IoMCwwLDApO2JhY2tncm91bmQtY29sb3I6 cmdiKDI1NSwyNTUsMjU1KSI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5 OkNhbGlicmksQXJpYWwsSGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOjEycHQ7Y29sb3I6 cmdiKDAsMCwwKTtiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1LDI1NSkiPg0KV2Uga25vdyBz ZWN1cmVkIG5ldHdvcmsgY29uZmlndXJhdGlvbiB3aXRob3V0IG91dC1vZi1iYW5kIGNvbmZpZ3Vy YXRpb24gaXMgYSBoYXJkIHByb2JsZW0gYnV0IHdhbnQgdG8gZGlzY3VzcyBpdCBpbiBhIGxhcmdl ciBjb250ZXh0IHRoYW4ganVzdCBETlMgc28gd2UgZG9uJ3QgdHJ5IHRvIGRlZmluZSBhIG1lY2hh bmlzbSB0aGF0IGNhbm5vdCBiZSByZXVzZWQgYnkgb3RoZXIgc2NlbmFyaW9zLi4gVGhpcyBtYWls aW5nIGxpc3Qgd2FzIHJlY29tbWVuZGVkDQogaW4gb3VyIElFVEYgMTA4IFdHIHNlc3Npb24gYXMg YSBnb29kIGNvbnRhY3QgZm9yIGhlbHBpbmcgdXMgZmluZCB0aGUgcmlnaHQgYXVkaWVuY2UgZm9y IHRoaXMgZGlzY3Vzc2lvbi4gQW55IHRob3VnaHRzPzwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImZvbnQtZmFtaWx5OkNhbGlicmksQXJpYWwsSGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXpl OjEycHQ7Y29sb3I6cmdiKDAsMCwwKSI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgaWQ9ImdtYWlsLW1f Mzc3ODEyOTI3NjY3MTI3MjYwNVNpZ25hdHVyZSI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1m YW1pbHk6Q2FsaWJyaSxBcmlhbCxIZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6MTJwdDtj b2xvcjpyZ2IoMCwwLDApIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLEhlbHZl dGljYSxzYW5zLXNlcmlmIj5UaGFua3MsPC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1m YW1pbHk6Q2FsaWJyaSxBcmlhbCxIZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6MTJwdDtj b2xvcjpyZ2IoMCwwLDApIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLEhlbHZl dGljYSxzYW5zLXNlcmlmIj5Ub21teSBKZW5zZW48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KU2VjZGlzcGF0Y2ggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFp bHRvOlNlY2Rpc3BhdGNoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgbW96LWRvLW5vdC1zZW5k PSJ0cnVlIj5TZWNkaXNwYXRjaEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NlY2Rpc3BhdGNoIiByZWw9Im5vcmVmZXJyZXIi IHRhcmdldD0iX2JsYW5rIiBtb3otZG8tbm90LXNlbmQ9InRydWUiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2VjZGlzcGF0Y2g8L2E+PGJyPg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8YnI+DQo8ZmllbGRzZXQgY2xhc3M9Im1pbWVBdHRhY2htZW50SGVhZGVyIj48L2Zp ZWxkc2V0Pg0KPHByZSBjbGFzcz0ibW96LXF1b3RlLXByZSIgd3JhcD0iIj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KU2VjZGlzcGF0Y2ggbWFpbGluZyBs aXN0DQo8YSBjbGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86U2Vj ZGlzcGF0Y2hAaWV0Zi5vcmciPlNlY2Rpc3BhdGNoQGlldGYub3JnPC9hPg0KPGEgY2xhc3M9Im1v ei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zZWNkaXNwYXRjaCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zZWNkaXNwYXRjaDwvYT4NCjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_c069bc56e0d80bd3ec121a0937de2b78ericssoncom_-- From nobody Tue Aug 4 02:20:27 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 369083A1022 for ; Tue, 4 Aug 2020 02:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GK5JB1JFlEwF for ; Tue, 4 Aug 2020 02:20:24 -0700 (PDT) Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 291E83A101E for ; Tue, 4 Aug 2020 02:20:24 -0700 (PDT) Received: by mail-yb1-xb30.google.com with SMTP id v89so7354731ybi.8 for ; Tue, 04 Aug 2020 02:20:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JChfZp3LQe+QbBkNXBkZLqnhunjBcNS295DtLVRafos=; b=vAtERbTxVGK+qzAAdNdjQve6ct1roAn4Tg5JJGl2oVdoSTBQaCRaaB40hM9npBFp7X 7xj12B1+vsv1pWUFAdkzJQ88Ewm6aI/g0Fz7EBJmPvFj73QyoZVCc5ESIHHnsMF/E9eN 1slGRGxcBweOG/uwVMv5cIZOYKJqJ6cQmCJfwNigpp3KqfrXuUeHsRLfWjrABKKTEtww QbX0/a7FhgsMN7SBdhywclBM7zDUv/ihU3PDKIKjedCdHn8mIVZ8mzKOV2cFqoVG/uNw u+eOyjq6vYzcSRFYybLbzCKjz+SP59PAlFXcTDINfESiJHAKknu4w7suttY2/A3c2H5o CcqQ== 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=JChfZp3LQe+QbBkNXBkZLqnhunjBcNS295DtLVRafos=; b=g8GV00v9t8bvWPuXOJ8gYrteuYF8PU3wPYOqEoUJV2T+pOXr9L3Qm4h+2ZGOsCUlaP 9fLGyhMagGnnEDmxsRPcWa3/k9FkF5l3p8Kww2wL2wOjQKZPms86nv5/J+3mP8e4+ynU pBNaBTvmFEoR7qRul6kZDbSiHAH/ELQRYet7stlNBIo4UDysUWgXRvtCKZczt55ujlD6 P3stu3hvDtBvFF8bldS6nUMSt97+jmjagzv8M+dv1MkoAxrufOVL9MN6jMNLT2OjZflE 8WtJiE7/6aH96kgm3Tc/0GdRAKRmk8OmukCsj3X/VBCP44m8FSiIOyZPoQRkdFCVYlal vvPQ== X-Gm-Message-State: AOAM530/lRcW7qQespKWPQXsrYjL1Pg3mX8i+tEThNH9zGa0sOWDDaHs hQ+d76Y2OgQn0C92UyDASwnMw2ve0+s2ufKRB4M= X-Google-Smtp-Source: ABdhPJw1tqkndqMp1N0oW8TYUqdbPzoRRI0TBKEy7m8d5xLQOknmLkbEIiYkOzmXP00fA2MEmNkEcWq44DfROC6GrGI= X-Received: by 2002:a25:905:: with SMTP id 5mr21315942ybj.22.1596532823174; Tue, 04 Aug 2020 02:20:23 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?T=C3=B6ma_Gavrichenkov?= Date: Tue, 4 Aug 2020 12:20:10 +0300 Message-ID: To: Tommy Jensen Cc: secdispatch Content-Type: multipart/alternative; boundary="000000000000cc365d05ac09c3c8" Archived-At: Subject: Re: [Secdispatch] Appropriate WG for secure communication between networks and unknown clients X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 09:20:25 -0000 --000000000000cc365d05ac09c3c8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Peace, On Mon, Aug 3, 2020, 8:59 PM Tommy Jensen wrote: > In the ADD WG, there's been a lot of discussion on the topic of secure > communication between networks and clients that aren't preconfigured. > While this is an interesting area to develop, it seems like current efforts belong more to IRTF than IETF, don't they? -- T=C3=B6ma > --000000000000cc365d05ac09c3c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Peace,

On Mon, Aug 3, 2020, 8:59 PM Tommy Jense= n <Jensen.Thomas=3D40m= icrosoft.com@dmarc.ietf.org> wrote:
In the ADD WG, there's been a lot of discussion on the topic of secure = communication between networks and clients that aren't preconfigured.

= While this is an interesting area to develop, it seems like current efforts= belong more to IRTF than IETF, don't they?

=
--
T=C3=B6ma
--000000000000cc365d05ac09c3c8-- From nobody Wed Aug 5 20:35:25 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1FC03A0DC9; Wed, 5 Aug 2020 20:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhZRs6MvVBI9; Wed, 5 Aug 2020 20:35:03 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B46F63A0DCA; Wed, 5 Aug 2020 20:35:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 00C6B389AA; Wed, 5 Aug 2020 23:14:21 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id r2qNV-yGByKc; Wed, 5 Aug 2020 23:14:19 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 68A3F389A9; Wed, 5 Aug 2020 23:14:19 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A669C63E; Wed, 5 Aug 2020 23:34:58 -0400 (EDT) From: Michael Richardson To: "saag\@ietf.org" , t2trg@irtf.org, secdispatch@ietf.org CC: Leif Johansson , Robin Wilton In-Reply-To: <47C264DC-D59D-49E8-B087-BAF0E23527DD@ericsson.com> References: <47C264DC-D59D-49E8-B087-BAF0E23527DD@ericsson.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Secdispatch] idevid-considerations at -- SecDispatch/IETF108 X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2020 03:35:05 -0000 --=-=-= Content-Type: text/plain Francesca Palombini wrote: > The SECDISPATCH WG met on Thursday July 30. The agenda items were dispatched as follows: > (1) IDevID considerations (Michael Richardson) > * specification: https://tools.ietf.org/html/draft-richardson-secdispatch-idevid-considerations-00 --> Needs vendor involvement - get more people from the industry and then > possibly bring it back. Hi, so I heard the feedback strongly to go talk to more industrial/manufacturing types. It was also suggested that T2TRG would welcome it. https://mailarchive.ietf.org/arch/msg/t2trg/E05g95AX3DUlS0_mBQH4DwcfLBc/ with a possible title of: A Toxonomy of Operational Security of manufacturer installed keys and anchors A pointer was sent me about RFC6711: An IANA Registry for Level of Assurance (LoA) Profiles This might be fine as a place to store/reference the palette of mechanisms, but it does not, I think, help in creating the content of each palette. It references: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-assurance-profile.html But, I didn't quite understand it. I think that it's about communicating between verifiers and relying parties, the degree to which the verifier has validated the identity of a SAML Identity. Kantara Initiative Identity Assurange Framework (KIIAF) was referenced, and Kantara Initiative was also mentioned by private message during secdispatch. Kantara is, as far as I can understand, a conformity assessment and assurance entity, which works against NIST 800-63-3. I hope to have further conversations with them. So, going to that NIST document, which was also mentioned: https://pages.nist.gov/800-63-3/ This document has a lot of commonalities, but yet it is not about how keys are protected. It is about how to communicate about the confidence an entity has about the identities it is asserting. It is "Identity Proofing" for humans. Now, NIST SP 800-63B _Authentication and Lifecycle Management_, has lots and lots of good stuff. Nothing that says how to evaluate how many intermediate CAs are appropriate when issuing certificates to put into the hardware authenticators. It's clear that this document is relevant to a manufacturer who might need to consider how to authenticate and authorize access to private keys. For instance, AAL2 (maybe even AAL3) is probably appropriate for access to the signing key for a software update. (There is an interesting recursive element here where where cryptographic authenticators are used...) NIST Special Publication 800-63C: _Digital Identity Guidelines: Federation and Assertions_ deals in SAML, OpenID Connect, and Kerberos, at the level of assertions, not keys. Really nice diagrams. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8remIACgkQgItw+93Q 3WWgiwgAwIHq5SJlanSdyL5TaGBaJkPXrMF8c32sZRwpDGMzFIVe4ZyAX6hvRies Ud4h9bOVNFwlcWLhFEcGFhHdPu8xq1lkLXTFheGztMRjVItOh4ofqrfJQSMvTIOd XWVV4p+rUFMBMPCCyUKD6AZR6euAK/UsSrXELYvmnlAXIYenxW41S63yNWmtIPd+ 0f065oIMPmwBReKNIDnZqpOtxITg1EQTHvIsnW1K4OL576NSEhbhL7hGz2XrJP2e aTJQj5nfwrI7i5LYinQ5Mfl4e0AVgq0L1Pv/4BxxxL7MiNEYP2B5YQrwZFaSH18z 3NR7Bf54B6bjL5VF+LLoDYCwe/eC5w== =GlfP -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 26 16:51:02 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 750B73A0B94 for ; Wed, 26 Aug 2020 16:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWgcnhBMePGm for ; Wed, 26 Aug 2020 16:50:54 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C09E83A0B92 for ; Wed, 26 Aug 2020 16:50:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 86DC1389A5; Wed, 26 Aug 2020 19:29:54 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id xYrkAayLlZzj; Wed, 26 Aug 2020 19:29:52 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2AAF33899F; Wed, 26 Aug 2020 19:29:52 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 86C95476; Wed, 26 Aug 2020 19:50:50 -0400 (EDT) From: Michael Richardson To: secdispatch@ietf.org, t2trg@irtf.org Reply-To: t2trg@irtf.org In-Reply-To: <8D7A3382-FB95-485D-BD77-E66FE17E429B@island-resort.com> References: <7115.1595643186@localhost> <8D7A3382-FB95-485D-BD77-E66FE17E429B@island-resort.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Secdispatch] some more comments received on Re: richardson-secdispatch-idevid-considerations X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2020 23:50:57 -0000 --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Laurence Lundblade wrote: > I think there is an enormous difference between these two: > 1) Trust Anchor where public key is in the device > - Code signature verification > - Trusted / secured / xxx boot > 2) Trust Anchor where private key is in the device > - RATS / EAT > - IDevID > - (also DRM) Absolutely. 1) =3D> TRUST ANCHOR 2) =3D> ROOT OF TRUST I'm not keen on the second term, as it confuses many. I would love another term that is less TCG/RATS specific. > I=E2=80=99m not sure I=E2=80=99d even call the second one a trust anc= hor or the RFC > 4949=E2=80=99s definition of trust anchor aligns with it. At Qualcomm= we called > the second one =E2=80=9Ckey provisioning=E2=80=9D. I never tried to call them both trust anchors! If I did, please tell me where, so I can correct it. But, I want to note that *BOTH* involve the manufactuer maintaining some ki= nd of PKI (whether it's RFC5280/PKIX based, or CWT/EAT based, or OpenPGP) to sign the public key part. For IDevID, the infrastructure needs to sign the certificate loaded. For code-signing trust-anchors, the infrastructure needs to maintain the signing keys. In both cases, there are keys at the "factory" (or "key provisioning facility" as we wrote this week in the RATS architecture). --=-=-= Content-Type: text/plain Content-Disposition: inline Content-Description: Signature -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ --=-=-=-- --==-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl9G9VoACgkQgItw+93Q 3WU1xwgArBcNrXah7tNo5ZhWmTP3Hcs06veBQJLh4KaukWmILffMgh++sSMFhZmU fnVC3msz3li1v3ndYAx9/07+9RrxfDbVf//0byaKzVZqsRC0U0Cwl89r8AARR5xi e4ZAErgP6YhhOCh5VQIv7fouwTbKoqyWsmbStQVVqi3+izsj3UoIQpqnBlkn/tMb 2s4p9/IEu9IO6qdSUhRVlWtgvV/lGtxMGlDLFGa+OOYhRCtyUPAtseI+kvMB4QTv YR0jkhM0TUEOPR0wGkt3BrbUId8NkIysMi0jSpDJFXHztYHAO9CkSJQ2Een+iiS8 bouqYHSPKC/Fj2pP4jmgk+paShaiPA== =4yqB -----END PGP SIGNATURE----- --==-=-=--