From nobody Tue Apr 2 12:29:15 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFEF4120224 for ; Tue, 2 Apr 2019 12:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTUFKIyhi1Gb for ; Tue, 2 Apr 2019 12:29:12 -0700 (PDT) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD8DE12011C for ; Tue, 2 Apr 2019 12:29:11 -0700 (PDT) Received: by mail-wm1-x32d.google.com with SMTP id 4so4678568wmf.1 for ; Tue, 02 Apr 2019 12:29:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=doFSvAm1lMVSVF4SkrafmLWmTIj8Wl7s5LL+HKddgnI=; b=IRpemFrE4o82wTazYhBxzUvmv8anyFm1VypxtM5ubqdISURicI4v3GyboDhRPPyGZj zouihV+1pYr2KSqPE2+hgpUSopcnmmdfBCKihDGEthsZHNG4FgcLwAcwvvGCdsISJIR6 NR5AvWgZ3kqQtSJ6deFGPSNJCFQ5zCP1ervDuNNJD9ua0doFvcBp/cHmVAJEgjhFwK9w c+HYXID7C0vmPDJJDZFifqVcqcF4fPZ1UFihH9PfwQvkwiLpbmnGUapHsh5JfZafjUB0 jpoXPmb0i6NMuQgjsDreS+n9Y4MqPQwilmD3rhc8mdqFUv3JL7sNDAgQQlUMmMNPIGqa 7qaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=doFSvAm1lMVSVF4SkrafmLWmTIj8Wl7s5LL+HKddgnI=; b=IIoBx6IY3VI+RQZlvjioaxVbk6ZBx4H0UA8N9TUsN8GWrOHw14rM2UCXFbq5N4Q+ht GRk3LZiK+2ngbEYatzYNMgnIySVS4J7xSW+cBXO4CK5JZE6dQCY3WzFrmtHfN8Z5SkNH apvyxRP7vrgaRUQJTPMBUdcV6cAX6jZkmVL+H1Az+1bfymxyh4h3H+ZOYXKrRy1Ogjr3 JijEZy3JxMdPvqCtz6c66pVsj3FEXlOKj350Gww/mKW8c+egdMjFgwUtp/CC+bqZ/pQ6 sQpJHKsfu3Bgodrl79tWn+0sldK12lNltjNbf64Y/dLdsX6p7JeZm0WtCZRTKAh/zmyT ko3w== X-Gm-Message-State: APjAAAXmS7uQjQPbm6yOsh+gHtGIbS9kMZ7MzVOcwOTylTS+Jjp6JDw2 P+YR37n1tN0PR7aOu6yRqgAM9lDEdfI= X-Google-Smtp-Source: APXvYqz0CaDIELCdBtkVEiWPjNkxi3vi6ExeV4UTyaPx8hnF6VLh8jQtac+c03q3B0oG2/N/+XZw6w== X-Received: by 2002:a1c:7d42:: with SMTP id y63mr4839088wmc.113.1554233350028; Tue, 02 Apr 2019 12:29:10 -0700 (PDT) Received: from [192.168.1.13] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id x205sm10391695wmg.9.2019.04.02.12.29.07 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Apr 2019 12:29:08 -0700 (PDT) From: Yoav Nir Content-Type: multipart/alternative; boundary="Apple-Mail=_9D5F1352-8214-41D3-B6CC-3F5FCCF74DEE" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Message-Id: <0BD1753F-9618-4E35-9F53-9ADCA09E0A3A@gmail.com> Date: Tue, 2 Apr 2019 22:29:04 +0300 To: Security Area Advisory Group X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: [saag] Rough outline of a Security Considerations Sunday Tutorial X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2019 19:29:14 -0000 --Apple-Mail=_9D5F1352-8214-41D3-B6CC-3F5FCCF74DEE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi. As I mentioned at the SAAG meeting, we are planning to have a Security = Considerations tutorial on the Sunday of an upcoming meeting. I=E2=80=99ve put a very rough initial draft of an outline on github: https://github.com/IETF-SAAG/SecurityConsiderationsTutorial = Please read and comment (either on this list or in github), and send = PRs. Your input is very much necessary. Yoav --Apple-Mail=_9D5F1352-8214-41D3-B6CC-3F5FCCF74DEE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi.

As I = mentioned at the SAAG meeting, we are planning to have a Security = Considerations tutorial on the Sunday of an upcoming meeting.

I=E2=80=99ve put a very = rough initial draft of an outline on github:

https://github.com/IETF-SAAG/SecurityConsiderationsTutorial=

Please read = and comment (either on this list or in github), and send PRs.  Your = input is very much necessary.

Yoav


= --Apple-Mail=_9D5F1352-8214-41D3-B6CC-3F5FCCF74DEE-- From nobody Tue Apr 2 20:05:20 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E73112045D for ; Tue, 2 Apr 2019 20:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pxsc6lQj6mX1 for ; Tue, 2 Apr 2019 20:05:17 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A11E12044F for ; Tue, 2 Apr 2019 20:05:16 -0700 (PDT) Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x33354R1020489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 2 Apr 2019 23:05:06 -0400 Date: Tue, 2 Apr 2019 22:05:04 -0500 From: Benjamin Kaduk To: Nico Williams , Kazu Yamamoto Cc: Peter Gutmann , "Dr. Pala" , "saag@ietf.org" Message-ID: <20190403030503.GI54777@kduck.mit.edu> References: <20190326164951.GX4211@localhost> <20190326214816.GB4211@localhost> <1553679912618.8510@cs.auckland.ac.nz> <20190327151545.GG4211@localhost> <20190330153101.GT35679@kduck.mit.edu> <20190330222534.GK4211@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190330222534.GK4211@localhost> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [saag] ASN.1 vs. DER Encoding X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2019 03:05:19 -0000 On Sat, Mar 30, 2019 at 05:25:35PM -0500, Nico Williams wrote: > On Sat, Mar 30, 2019 at 10:31:02AM -0500, Benjamin Kaduk wrote: > > On Wed, Mar 27, 2019 at 10:15:46AM -0500, Nico Williams wrote: > > > On Wed, Mar 27, 2019 at 09:45:16AM +0000, Peter Gutmann wrote: > > > > >Thus there is almost zero benefit to self-describing encodings. > > > > > > > > ... apart from the fact that they can be statically analysed to check whether > > > > they're well-formed or not, unlike the encodings in PGP, TLS, IPsec, SSH, ... > > > > > > The protocols you list don't use a formal syntax, which instantly makes > > > validity checking harder (can't generate the code!). But if they had > > > used XDR, or ASN.1 with PER/OER/..., you could in fact automatically > > > check the validity of the encoding of a message. > > > > N.b. that the protocol descriptions in RFC 8446 were run through an > > automated syntax checker (IIRC, by Kazuho, though I'm not confident of that > > and only bought 20MB of data for this plane flight). So I'm not entirely > > convinced that this claim applies to TLS 1.3. > > ISTR hearing about that, but the RFC does say: > > 3. Presentation Language > > This document deals with the formatting of data in an external > representation. The following very basic and somewhat casually > defined presentation syntax will be used. > > which is basically saying it's not a formal syntax. We never bothered to remove the disclaimer, but the meaning is well-defined and that's really all you need to make it a "formal syntax". That text seems unchanged from RFC 5246 (which really was a bit more slapdash about the formal definition). > Now, perhaps it can be be formalized. If so, was that done for the > checking you mentioned, and was it lost? That would be unfortunate. > > Are there implementations that generate codecs for TLS? It looks like (per https://github.com/tlswg/tls13-spec/pull/999) I was thinking of Kazu Yamamoto's https://github.com/kazu-yamamoto/tls13-spec-validator which I guess will generate haskell for the presentation language. https://github.com/tlswg/tlswg-wiki/blob/master/IMPLEMENTATIONS.md does list a Haskell implementation with Kazu as author (if we chase the link). But I don't know if the implementation uses the generated code directly or not. Kazu, can you enlighten us? Thanks, Ben From nobody Thu Apr 4 08:25:23 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C20DE120443 for ; Thu, 4 Apr 2019 08:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AbJHaztrwdtw for ; Thu, 4 Apr 2019 08:25:20 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30064.outbound.protection.outlook.com [40.107.3.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E6441200A2 for ; Thu, 4 Apr 2019 08:25:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1ZV04xugvm9Dy2OH7gHtSNn5S75rmUCHOACqeYWq2j4=; b=jD9oD2c3ZA8s49EZmypyPv1I0gVKHw/F5Af17pOGHqfP9llw6NkL08RWAkvpiGqUS3KFUvFEq5pgWesFhDy4G7rnsyRLrtjTJXpAdKcYiZdBmicx8OwK5OPqn46t3zlh3pLfA7laL3N/69a6YIFflk2yy2Ykz4cG+oSO37OnWPw= Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.166.22) by HE1PR07MB4172.eurprd07.prod.outlook.com (20.176.166.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.6; Thu, 4 Apr 2019 15:25:17 +0000 Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::91bd:a367:2414:b4bc]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::91bd:a367:2414:b4bc%5]) with mapi id 15.20.1771.007; Thu, 4 Apr 2019 15:25:17 +0000 From: John Mattsson To: cfrg , "saag@ietf.org" Thread-Topic: 5G Encryption and the SNOW-V stream cipher Thread-Index: AQHU6vqbZJbLGOsrjkuyZPSHogAdRw== Date: Thu, 4 Apr 2019 15:25:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.17.1.190326 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [82.214.46.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9ee8870d-9884-417d-5b9c-08d6b911be52 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600139)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:HE1PR07MB4172; x-ms-traffictypediagnostic: HE1PR07MB4172: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-forefront-prvs: 0997523C40 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(366004)(396003)(376002)(346002)(39860400002)(189003)(199004)(44832011)(25786009)(86362001)(66066001)(58126008)(110136005)(68736007)(14444005)(256004)(316002)(53936002)(6512007)(6306002)(82746002)(97736004)(33656002)(5660300002)(7736002)(305945005)(3846002)(6116002)(966005)(14454004)(2906002)(478600001)(486006)(476003)(2616005)(71200400001)(71190400001)(2501003)(81166006)(81156014)(6486002)(8676002)(8936002)(83716004)(6436002)(106356001)(105586002)(99286004)(36756003)(102836004)(6506007)(26005)(186003); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4172; H:HE1PR07MB4169.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: AT3pcVMXv+LbR6m9f+aGzHXNrryE1FrBHlf/RSOAKDUdTwSVguFvVhkWn8UMq8gtgBtp2uWEnbYtX5utZU6I7iEixp2p4U1pY3Cf0xmrLd92O9SIMEpHOaliF11zh21budz52dG+JTkklsH0CbkDu/Q7bO8olr5mmY/4ttC0MdOptDcoX9x6+YnQowSqwBA4Ez2u/ywZV6EySoqFwc8I8YhR74muGkiqTCWcfgoNU0BMq+sT2bcPJQYTrlb60WDGe066VJGMVRXKWfJqQCDqThPf8fQp405bM1h8JSPDEPVBFC+1MpcNbFJ14hFT8nUTgKL6nhdzP2/XQpt8O8crsRkvbBoK+/IL8Ef/3r4NYCaA6qtqyXFYNH02RbLePhAotWfEvsNCEmQ3aQM/YJnorheiKa8hy3/vMo9It1r3G6E= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9ee8870d-9884-417d-5b9c-08d6b911be52 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2019 15:25:17.6533 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4172 Archived-At: Subject: [saag] 5G Encryption and the SNOW-V stream cipher X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 15:25:23 -0000 IEhpLA0KDQpJIHByZXNlbnRlZCB0aGlzIGluIFNBQUcgYXQgSUVURiAxMDQgYXMgQ0ZSR3MgYWdl bmRhIHdhcyBjb21wbGV0ZWx5IGZ1bGwuIEluIHRoZSBlbmQgU0FBRyBtYXkgaGF2ZSBiZWVuIGEg YmV0dGVyIHBsYWNlIGZvciBhIHNob3J0IGhpZ2ggbGV2ZWwgcHJlc2VudGF0aW9uLiBUaGFua3Mg Zm9yIGFsbCB0aGUgZ29vZCBmZWVkYmFjayBhbmQgc3VnZ2VzdGlvbnMgZHVyaW5nIGFuZCBhZnRl ciB0aGUgcHJlc2VudGF0aW9uISBTZW5kaW5nIHRoaXMgZW1haWwgZm9yIHBlb3BsZSB0aGF0IGRp ZCBub3QgYXR0ZW5kIFNBQUcuDQoNClRoZSBiYWNrZ3JvdW5kIGlzIHRoYXQgM0dQUCBTQTMgaGFz IGdpdmVuIEVUU0kgU0FHRSB0aGUgdGFzayB0byBhbmFseXNlIGFuZCBzdWdnZXN0IHN1aXRhYmxl IHJhZGlvIGVuY3J5cHRpb24gYWxnb3JpdGhtcyBmb3IgbGF0ZXIgNUcgcmVsZWFzZXMgKHRoZSBm aXJzdCByZWxlYXNlcyByZXVzZSB0aGUgNEcvTFRFIGFsZ29yaXRobXMpLiBUaGUgM0dQUCByYWRp byBhbGdvcml0aG1zIGFyZSB1c2VkIGZyb20gdGhlIFVFIHRvIHRoZSBuZXR3b3JrOg0KDQogIC0g SW4gMkcsIHRoZSBlbmNyeXB0aW9uIGlzIHRlcm1pbmF0ZWQgaW4gdGhlIGJhc2Ugc3RhdGlvbi4N CiAgLSBJbiAzRywgaXQgaXMgd2FzIGRlY2lkZWQgdG8gdGVybWluYXRlZCBlbmNyeXB0aW9uIGRl ZXAgaW4gdGhlIGNvcmUgbmV0d29yayAoZm9yIHNlY3VyaXR5IHJlYXNvbnMpLg0KICAtIEluIDRH LCBpdCB3YXMgZGVjaWRlZCB0byBvbmNlIGFnYWluIHRlcm1pbmF0ZWQgdGhlIGVuY3J5cHRpb24g aW4gdGhlIGJhc2Ugc3RhdGlvbiAoZm9yIHBlcmZvcm1hbmNlIHJlYXNvbnMpLg0KICAtIEluIDVH LCB0aGUgZW5jcnlwdGlvbiBpcyBmb3JtYWxseSB0ZXJtaW5hdGVkIGluIHRoZSBiYXNlIHN0YXRp b24sIGJ1dCBkdWUgdG8gTmV0d29yayBGdW5jdGlvbnMgVmlydHVhbGl6YXRpb24gKE5GVikgaXQg d2lsbCBpbiBwcmFjdGljZSBiZSB0ZXJtaW5hdGVkIGRlZXAgaW4gdGhlIGNvcmUgbmV0d29yay4N Cg0KWzFdIGdpdmVzIGFuIG92ZXJ2aWV3IG9mIHRoZSBjdXJyZW50IDNHUFAvR1NNQSBDcnlwdG9n cmFwaGljIEFsZ29yaXRobXMgdGhhdCBhbGwgb2YgeW91IGFsbCByZWx5IG9uIGV2ZXJ5IHNpbmds ZSBkYXkuIDVHIHB1dHMgYSBsb3Qgb2YgcmVxdWlyZW1lbnRzIG9uIHRoZSBlbmNyeXB0aW9uIGFs Z29yaXRobXMuDQoNCi0gRmlyc3QsIElUTS0yMDIwIHJlcXVpcmVzIHRlY2hub2xvZ2llcyB0byBz dXBwb3J0IGF0IGxlYXN0IDIwIEdicHMgZG93bmxpbmsgdG8gYmUgY2FsbGVkIDVHLiBXaGlsZSB0 aGlzIHdpbGwgbGlrZWx5IG5vdCBiZSBzdXBwb3J0ZWQgaW4gdGhlIGZpcnN0IGRldmljZXMsIGl0 IHdpbGwgdmVyeSBsaWtlbHkgYmUgc3VycGFzc2VkIGJ5IGxhdGVyIDVHIHNwZWNpZmljYXRpb25z IChhdCBsZWFzdCB0aGF0IGlzIHdoYXQgaGFwcGVuZWQgd2l0aCA0RykuIE9wdGltYWxseSB0aGUg YWxnb3JpdGhtcyBzaG91bGQgd29yayBhbHNvIGZvciBmdXR1cmUgZ2VuZXJhdGlvbnMgb2YgY2Vs bHVsYXIgbmV0d29ya3MuDQoNCi0gU2Vjb25kbHksIE5ldHdvcmsgRnVuY3Rpb25zIFZpcnR1YWxp emF0aW9uIChORlYpIG1lYW5zIHRoYXQgdGhlIGVuY3J5cHRpb24gd2lsbCBiZSB0ZXJtaW5hdGVk IGluIGRhdGEgY2VudGVycyB3aXRoIHZhcmlvdXMgYW1vdW50IG9mIHNwZWNpYWxpemVkIGhhcmR3 YXJlLiBUaGUgY3VycmVudCAzR1BQIGFsZ29yaXRobXMgbGlrZSBBRVMtQ1RSICsgQUVTLUNNQUMg YW5kIFNOT1cgM0cgZG9lcyBub3QgbWVldCB0aGUgcGVyZm9ybWFuY2UgcmVxdWlyZW1lbnRzLg0K DQpBbm90aGVyIHJlYXNvbiBmb3IgM0dQUCB0byBzdGFuZGFyZGl6ZSBuZXcgYWxnb3JpdGhtcyBh cmUgcmVxdWlyZW1lbnRzIG9uIDI1Ni1iaXQgYWxnb3JpdGhtcyBmcm9tIGdvdmVybm1lbnRzIHdh bnRpbmcgdG8gdXNlIDVHLiBBIHRoaXJkIHJlYXNvbiBpcyBmdXR1cmUgcHJvb2ZpbmcsIGJ1dCAz R1BQIHJlY2VudGx5IGNvbmNsdWRlZCB0aGF0IHRoZXJlIGlzIG5vIGltbWluZW50IG5lZWQgdG8g cmVwbGFjZSAxMjgtYml0IHN5bW1ldHJpYyBjcnlwdG9ncmFwaHkuIEEgY3VycmVudCB3b3JraW5n IGFzc3VtcHRpb24gaXMgdGhhdCBFVFNJIFNBR0Ugd2lsbCByZWNvbW1lbmQgYWxnb3JpdGhtcyBi YXNlZCBvbiBBRVMsIFNOT1csIGFuZCBaVUMuDQoNClRoYW5rcyBZb2F2IE5pciBmb3IgcG9pbnRp bmcgb3V0IHRoYXQgdGhlIHBlcmZvcm1hbmNlIG51bWJlcnMgZnJvbSAyMDE3IHdhcyBhbHJlYWR5 IHNpZ25pZmljYW50bHkgb3V0ZGF0ZWQuIEFtYXppbmcgaG93IGZhc3QgZW5jcnlwdGlvbiBpcyBv biBtb2Rlcm4gQ1BVcyBhbmQgdGhhdCBCb3RoIEdDTSBhbmQgT0NCIHJlYWxseSBvZmZlcnMgaW50 ZWdyaXR5IHByb3RlY3Rpb24gZm9yIGZyZWUuIFRoZSBudW1iZXJzIGZvciBhdXRoZW50aWNhdGVk IGVuY3J5cHRpb24gYXJlIHRoZSByZWxldmFudCBvbmVzIGluIHByYWN0aWNlLiBOdW1iZXJzIGJl bG93IGZyb20gT3BlblNTTCAxLjEuMWIgb24gYW5kIGk3LTY3MDBLLg0KDQogICAgICAgICAgICAg ICAgICAgICAgICAxMDI0IGJ5dGVzICAgICAgICAgIDE2Mzg0IGJ5dGVzIA0KYWVzLTI1Ni1jdHIg ICAgICAgICAgICAgMzIuMjMgR2JwcyAgICAgICAgICAzNi41OSBHYnBzDQphZXMtMjU2LWdjbSAg ICAgICAgICAgICAyOC40OCBHYnBzICAgICAgICAgIDM2LjAxIEdicHMNCmFlcy0yNTYtb2NiICAg ICAgICAgICAgIDMxLjAyIEdicHMgICAgICAgICAgMzYuMjQgR2Jwcw0KY2hhY2hhMjAgICAgICAg ICAgICAgICAgMjYuMTcgR2JwcyAgICAgICAgICAyNy43MiBHYnBzDQpjaGFjaGEyMC1wb2x5MTMw NSAgICAgICAxNy42MSBHYnBzICAgICAgICAgIDE5LjI5IEdicHMNCg0KQUVTLTI1Ni1HQ00gd2ls bCB2ZXJ5IGxpa2VseSBiZSBhIG1haW4gY2FuZGlkYXRlIGFzIGl0cyBwZXJmb3JtYW5jZSBldmVu IG9uIGEgc2luZ2xlIGNvcmUgaXMgd2VsbCBhYm92ZSB0aGUgY3VycmVudCByZXF1aXJlbWVudHMu IEFub3RoZXIgY2FuZGlkYXRlIGlzIGFuIHVwZGF0ZSBbMl0gdG8gdGhlIFNOT1cgZmFtaWx5IG9m IGFsZ29yaXRobXMgKFNOT1cgM0cgaXMgdXNlZCBpbiAyRywgM0csIDRHLCBhbmQgNUcpLiBXaGVu IHRoZSBTTk9XIHRlYW0gdHJpZWQgdG8gc2VlIGhvdyBmYXN0IFNOT1cgM0cgY291bGQgYmUgb24g bW9kZXJuIENQVSB0aGV5IHJlYWxpemVkIHRoYXQgYSBzbGlnaHRseSB1cGRhdGVkIHZlcnNpb24g ZGVzaWduZWQgZm9yIG1vZGVybiBDUFVzIGNvdWxkIGJlIGV4dHJlbWVseSBmYXN0LiBUaGUgY3Vy cmVudCBDKysgY29kZSBvZiBTTk9XLVYgc2lnbmlmaWNhbnRseSBvdXRwZXJmb3JtcyBldmVuIG9w dGltaXplZCBhc3NlbWJseSBpbXBsZW1lbnRhdGlvbnMgb2YgQUVTLUNUUiBhbmQgQUVTLUdDTSBv biBtb2Rlcm4geDY0IHByb2Nlc3NvcnMuIEFuIG9wdGltaXplZCBhc3NlbWJseSBpbXBsZW1lbnRh dGlvbiBvZiBTTk9XLVYtR0NNIHdvdWxkIGxpa2VseSBiZSBldmVuIGZhc3RlciwgYnV0IGl0IGlz IGhhcmQgdG8gc2F5IGhvdyBtdWNoLiANCg0KU05PVy1WICAgICAgICAgICAgICAgICAgNjQuMDEg R2JwcyAgICAgICAgICBDKyssIEFsZXhhbmRlciBNYXhpbW92DQpTTk9XLVYtR0NNICAgICAgICAg ICAgICA0Mi40MCBHYnBzICAgICAgICAgIEMrKywgQWxleGFuZGVyIE1heGltb3YNCkFFUy0yNTYt Q1RSICAgICAgICAgICAgIDM1Ljc1IEdicHMgICAgICAgICAgQysrLCBBbGV4YW5kZXIgTWF4aW1v dg0KQUVTLTI1Ni1HQ00gICAgICAgICAgICAgMjUuNTAgR2JwcyAgICAgICAgICBDKyssIEFsZXhh bmRlciBNYXhpbW92DQogDQpBRVMtMjU2LUNUUiAgICAgICAgICAgICAzNC43OCBHYnBzICAgICAg ICAgIEFzc2VtYmx5LCBPcGVuU1NMIDEuMS4xDQpBRVMtMjU2LUdDTSAgICAgICAgICAgICAzNC41 OCBHYnBzICAgICAgICAgIEFzc2VtYmx5LCBPcGVuU1NMIDEuMS4xDQoNClNOT1ctViBpcyBhbHNv IGV4dHJlbWVseSBmYXN0IGluIGhhcmR3YXJlIHdpdGggcXVpdGUgc21hbGwgYW5kIGVmZmljaWVu dCBpbXBsZW1lbnRhdGlvbnMuIDNHUFAgaGFzIHRyYWRpdGlvbmFsbHkgc3RhbmRhcmRpemVkIGFu ZCBkZXBsb3llZCBtb3JlIHRoYW4gb25lIGFsZ29yaXRobSB0byBiZSBhYmxlIHRvIGltbWVkaWF0 ZWx5IHN3aXRjaCBpbiBjYXNlIGFueSBzZXJpb3VzIHdlYWtuZXNzZXMgYXJlIGZvdW5kLg0KDQpB bnkgc3VnZ2VzdGlvbiBvciBjb21tZW50cyBvbiBhbnl0aGluZyBvZiB0aGUgYWJvdmUgYXJlIHZl cnkgd2VsY29tZSEgSSBhc3N1bWUgdGhlIGFyZSBtYW55IHBlb3BsZSB0cnlpbmcgdG8gZ2V0IGZh c3QgZW5vdWdoIGVuY3J5cHRpb24gaW4gYm90aCBzb2Z0d2FyZSBhbmQgaGFyZHdhcmUuDQoNCihB cyBIYW5uZXMgVHNjaG9mZW5pZyBwb2ludGVkIG91dCwgNyBtbSBpbiB0aGUgcHJlc2VudGF0aW9u IHNob3VsZCBiZSA3IG5tLiBBIDcgbW0gcHJvY2VzcyAgd291bGQgbGVhZCB0byB2ZXJ5IGxhcmdl LCBzbG93LCBhbmQgcG93ZXIgaHVuZ3J5IGNoaXBzZXRzIDspDQoNCkNoZWVycywNCkpvaG4NCg0K WzFdIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy8xMDQvbWF0ZXJpYWxzL3Ns aWRlcy0xMDQtc2FhZy1zbm93LXYtc3RyZWFtLWNpcGhlci0wMA0KWzJdIGh0dHBzOi8vZXByaW50 LmlhY3Iub3JnLzIwMTgvMTE0My5wZGYNClszXSBodHRwczovL3d3dy5laXQubHRoLnNlL2ZpbGVh ZG1pbi9laXQvaG9tZS9ocy50am8vcHJlc2VudGF0aW9uLnBkZg0KDQo= From nobody Thu Apr 4 08:49:20 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB1931200A0 for ; Thu, 4 Apr 2019 08:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yF1Oz2OnvJeo for ; Thu, 4 Apr 2019 08:49:16 -0700 (PDT) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E1A712007A for ; Thu, 4 Apr 2019 08:49:16 -0700 (PDT) Received: by mail-wr1-x430.google.com with SMTP id k17so4394488wrx.10 for ; Thu, 04 Apr 2019 08:49:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=TrNnovDshjarRfw78EPJ4KPFrefjPOCN1cVaZXYopCs=; b=fcj5Z6DVqF1h677XbORtLXYrMZkJtY+lHfUsXghKi+OLx7zCzc7PaUAYPNaf/GBeId HCC1BsknR9neo6Md6YL68ClQuHrKyIBG/6R5S4AkVAxlBHCExTXBgbP2B5pfO513b+GG z53tWVpSbo8iaUX9KIGZXE5q/aHy7QlesgtwLSvv1dExyrWqDpsuBf0HIPzJk4xYuSvS nMzMQ28nyfDikcqYEJPhaxZCwY1QOkG+9p6ly1vfljjXO/YWZDhf7X9P8y2yTeFT6fsG eGjK427ZBcwxTPaVY4vgskKcPDwqF9jXMcgjxgUFCewEJFLIYkIgTzIiOjDzA+fKyz1G G+xA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=TrNnovDshjarRfw78EPJ4KPFrefjPOCN1cVaZXYopCs=; b=pLomnXfZ2Z3udf5dV4m1Nnka+EhxkXTKzTJGk6C9yDU0lvVPlg8kTUL9qCTcvgrT+l qqb6WIDBffNk2x2yBvP72knvT/7hMTXjHFVyem7rgsVIdKV2WN9MXi+O1JzsO2gPcBBr qxr3oEp37T3jHm+LhfCmxzoKGubjMzPm0lVGYZrib4P81M+/Bh7uab0+jlcn6kFpiTOx xiGZVmB9mYGBy2T/yfyFLXRHfoCKdifCwf+oR6s9j9MdaHbcJ8Y7K4Bw8aPY1ltsRLGS kZ8SkMciOs9XSRG26eZsr0rVJmIZ81EzYpdjl3JJXzwOiaAyjJGtFv2hJ27U3NYlCJuZ XH2Q== X-Gm-Message-State: APjAAAWG7yxWKy1TZltotlpuprvtRUuGJwWS4J7Aq6FAAQ0Z7Iz7K64K BT+4U6GMyGe3nw/JRZW2gNwJYfrqiQY= X-Google-Smtp-Source: APXvYqxKKiu6ICBHBb1hTPeqgz3MQB7OHhY13VlCgssW9cj/Lz7cd8VeseGSrH2UXmH8BKCZFNZGqA== X-Received: by 2002:a5d:62c4:: with SMTP id o4mr974189wrv.282.1554392954569; Thu, 04 Apr 2019 08:49:14 -0700 (PDT) Received: from [192.168.1.13] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id e1sm32976765wrw.66.2019.04.04.08.49.13 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Apr 2019 08:49:13 -0700 (PDT) From: Yoav Nir Content-Type: multipart/alternative; boundary="Apple-Mail=_D1B459FC-418F-4FFF-9AFC-4FCF3D1D97F1" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Message-Id: <67FB6578-983F-4494-B5C6-269347CCDF19@gmail.com> Date: Thu, 4 Apr 2019 18:49:11 +0300 To: Security Area Advisory Group X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: [saag] Followup on mic comments X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 15:49:19 -0000 --Apple-Mail=_D1B459FC-418F-4FFF-9AFC-4FCF3D1D97F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi This is following up on my mic comment at the SAAG meeting. In the Snow-V Stream Cipher presentation (SNOW-V Stream Cipher = ), the claim was made that existing ciphers such as = AES-GCM and ChaCha20-Poly1305 were not fast enough for the application. I said that I had recently measured throughput on a relatively new CPU = and got better results. Now that I am back at work, I have the exact = numbers. So the server in question is a regular Intel-based server. The CPU model = is an Intel Xeon Gold 6150 running at 2.7 GHz, a relatively high-end = processor from late 2017. = https://ark.intel.com/content/www/us/en/ark/products/120490/intel-xeon-gol= d-6150-processor-24-75m-cache-2-70-ghz.html = I used the =E2=80=9Copenssl speed=E2=80=9D utility to measure the = throughput, with version 1.1.1b of OpenSSL=20 Results: AES-128-GCM: 5.341661 GB/s AES-256-GCM: 3.907859 GB/s ChaCha20-Poly1305: 2.420072 GB/s=20 Translating to Gb/s these give 42.73, 31.26, and 19.36 Gb/s = respectively. Yoav= --Apple-Mail=_D1B459FC-418F-4FFF-9AFC-4FCF3D1D97F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi

This = is following up on my mic comment at the SAAG meeting.

In the Snow-V Stream = Cipher presentation (SNOW-V Stream Cipher), the = claim was made that existing ciphers such as AES-GCM and = ChaCha20-Poly1305 were not fast enough for the application.

I said that I had = recently measured throughput on a relatively new CPU and got better = results.  Now that I am back at work, I have the exact = numbers.

So = the server in question is a regular Intel-based server. The CPU model is = an Intel Xeon Gold 6150 running at 2.7 GHz, a relatively high-end = processor from late 2017.
https://ark.intel.com/content/www/us/en/ark/products/120490/int= el-xeon-gold-6150-processor-24-75m-cache-2-70-ghz.html

I used the =E2=80=9Copenss= l speed=E2=80=9D utility to measure the throughput, with version 1.1.1b = of OpenSSL 

Results:
  • AES-128-GCM:  5.341661 = GB/s
  • AES-256-GCM: 3.907859 GB/s
  • ChaCha20-Poly1305: 2.420072 GB/s 

Translating to Gb/s these give 42.73, = 31.26, and 19.36 Gb/s respectively.

Yoav
= --Apple-Mail=_D1B459FC-418F-4FFF-9AFC-4FCF3D1D97F1-- From nobody Thu Apr 4 08:53:36 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10CDF1200DE for ; Thu, 4 Apr 2019 08:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 271kC5Rw_Ve7 for ; Thu, 4 Apr 2019 08:53:33 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9984C12007A for ; Thu, 4 Apr 2019 08:53:32 -0700 (PDT) Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x34FrSl2029312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 4 Apr 2019 11:53:30 -0400 Date: Thu, 4 Apr 2019 10:53:28 -0500 From: Benjamin Kaduk To: Yoav Nir Cc: Security Area Advisory Group Message-ID: <20190404155328.GF54777@kduck.mit.edu> References: <67FB6578-983F-4494-B5C6-269347CCDF19@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <67FB6578-983F-4494-B5C6-269347CCDF19@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [saag] Followup on mic comments X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 15:53:35 -0000 On Thu, Apr 04, 2019 at 06:49:11PM +0300, Yoav Nir wrote: > Hi > > This is following up on my mic comment at the SAAG meeting. > > In the Snow-V Stream Cipher presentation (SNOW-V Stream Cipher ), the claim was made that existing ciphers such as AES-GCM and ChaCha20-Poly1305 were not fast enough for the application. > > I said that I had recently measured throughput on a relatively new CPU and got better results. Now that I am back at work, I have the exact numbers. > > So the server in question is a regular Intel-based server. The CPU model is an Intel Xeon Gold 6150 running at 2.7 GHz, a relatively high-end processor from late 2017. > https://ark.intel.com/content/www/us/en/ark/products/120490/intel-xeon-gold-6150-processor-24-75m-cache-2-70-ghz.html > > I used the “openssl speed” utility to measure the throughput, with version 1.1.1b of OpenSSL > > Results: > AES-128-GCM: 5.341661 GB/s > AES-256-GCM: 3.907859 GB/s > ChaCha20-Poly1305: 2.420072 GB/s > > Translating to Gb/s these give 42.73, 31.26, and 19.36 Gb/s respectively. "openssl speed" is not necessarily the best/well-specified benchmark. Please supply the exact command-line used (noting that you tend to need to use '-evp foo' in order to actually use the hardware support). -Ben From nobody Thu Apr 4 08:54:35 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1031112007A for ; Thu, 4 Apr 2019 08:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 SoPHuXMRI1zg for ; Thu, 4 Apr 2019 08:54:28 -0700 (PDT) Received: from eastern.maple.relay.mailchannels.net (eastern.maple.relay.mailchannels.net [23.83.214.55]) (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 5262E1200A0 for ; Thu, 4 Apr 2019 08:54:27 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 22A933E5A7F; Thu, 4 Apr 2019 15:54:26 +0000 (UTC) Received: from pdx1-sub0-mail-a22.g.dreamhost.com (unknown [100.96.11.48]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id B67153E494A; Thu, 4 Apr 2019 15:54:25 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a22.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Thu, 04 Apr 2019 15:54:26 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Fumbling-Keen: 73826c1d025d0f17_1554393265950_1446852543 X-MC-Loop-Signature: 1554393265950:1151906381 X-MC-Ingress-Time: 1554393265950 Received: from pdx1-sub0-mail-a22.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a22.g.dreamhost.com (Postfix) with ESMTP id 3A5AE7F104; Thu, 4 Apr 2019 08:54:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=sIzsp7zx6WgrUW JHoFSLmBgHcWk=; b=pp7dQ8o2BND8jf/MBdwppY/1QwOAuvfAfms3RvbcnkfFwq qvyDMoEEwuBgDpNI2mcgrdy1m+Rf731wEYD/bp8so3m+Trbaxz1BHEkI3MWIGnzY v7+HVRo8A3Hf4aPoAZYIbfD79UpO3/PFbwAUnZNupcTY2B8QtF2wCxM+dWgSs= Received: from localhost (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a22.g.dreamhost.com (Postfix) with ESMTPSA id B0BC97F106; Thu, 4 Apr 2019 08:54:21 -0700 (PDT) Date: Thu, 4 Apr 2019 10:54:20 -0500 X-DH-BACKEND: pdx1-sub0-mail-a22 From: Nico Williams To: Benjamin Kaduk Cc: Kazu Yamamoto , Peter Gutmann , "Dr. Pala" , "saag@ietf.org" Message-ID: <20190404155419.GA2718@localhost> References: <20190326164951.GX4211@localhost> <20190326214816.GB4211@localhost> <1553679912618.8510@cs.auckland.ac.nz> <20190327151545.GG4211@localhost> <20190330153101.GT35679@kduck.mit.edu> <20190330222534.GK4211@localhost> <20190403030503.GI54777@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190403030503.GI54777@kduck.mit.edu> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrtdehgdelfecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppeekrddvrddutdehrddujeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpeekrddvrddutdehrddujedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd Archived-At: Subject: Re: [saag] ASN.1 vs. DER Encoding X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 15:54:32 -0000 On Tue, Apr 02, 2019 at 10:05:04PM -0500, Benjamin Kaduk wrote: > > ISTR hearing about that, but the RFC does say: > > > > 3. Presentation Language > > > > This document deals with the formatting of data in an external > > representation. The following very basic and somewhat casually > > defined presentation syntax will be used. > > > > which is basically saying it's not a formal syntax. > > We never bothered to remove the disclaimer, but the meaning is well-defined > and that's really all you need to make it a "formal syntax". That text > seems unchanged from RFC 5246 (which really was a bit more slapdash about > the formal definition). Good. An informal syntax can be good enough indeed. And the use of a formal syntax can be insufficient (e.g., Heimdal's ASN.1 compiler has support for non-standard ASN.1 usage in RFC1510.) Nico -- From nobody Thu Apr 4 12:50:50 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F40AC1205DB for ; Thu, 4 Apr 2019 12:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g_G8odmKi3iE for ; Thu, 4 Apr 2019 12:50:46 -0700 (PDT) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9338F1205E1 for ; Thu, 4 Apr 2019 12:50:44 -0700 (PDT) Received: by mail-wr1-x430.google.com with SMTP id r4so5278134wrq.8 for ; Thu, 04 Apr 2019 12:50:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=rNLr0DjR2rDBuZ0/ZRF0Chvnq0DFJP2bVhaFAfvsuKo=; b=il5qXgwVOGaUoS0T/DCc+7i6Sj4kLUxo355YkV7y5MVjt0LBHexw9n6Reow8yDL6eZ 4TaBiIo+uG59g8MTIRdLGIz78SBnzRIH2MSBUe0pcLhMMejSdY9MCLmZG5VSp98coiLY oRSS0iEirjG37xXNkZRPwBmKSMKS13/sDEe++CcLINIkbxxasUactCLzJ5JVgPbkjkKu 8gEA51aCrvk8r9XFKs3y+uE99HckyufE1EIqc6l8OOpqcrHFXJbabB4oHSsydpfYeVQT IhtYdz+tYLuWkCMi/roFyl3lynY4Fb4rmL9qp6OjLO0UW/2Gz3Zd8R5ei+/D/hJkXucF 3WEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=rNLr0DjR2rDBuZ0/ZRF0Chvnq0DFJP2bVhaFAfvsuKo=; b=lqu63mcwllzGNCjb0Yu69zxYkILLHmx05IAOldHbp7rogXiA7OL+nXwoZM8+ZPbspS oPyZGPmY4dKyKWu4D1RpvCI7cRzRqCofGk/+xPZdqFRmy2A81W5i6mXDLcE//y68bUDZ wCny3b9RGbWMU045UKLBC9QT2M0lko/B1/PbC4O9ityFuL7s9SoS8GT3J4yBwAzn57pa g2CJmZRwaIQVEa76UhrENCMX2HR7xOgsCRXlcmh0CxW1Ed3NtGnHqW6tpIil5crsE3MT YVhki+MwEDigVWNwIIIHFXecGGKBBwkFhaKkd4zkdUkQwJCRd2BakBos0N9WirIdXQe8 ACMA== X-Gm-Message-State: APjAAAU8yXc9fr0fMYvOWFP3BOGKV2lusL7DYcoXL8tZi64AjZF7e4HV sgtl5hZhsDww3z+D9x/XMK4= X-Google-Smtp-Source: APXvYqzDCrrm/foYveqfi82Ah8XUWpvSDIcMVwvMYCJc3rlu3xt9bVJ6of+cxFs+/uvuD3mvFq1P8g== X-Received: by 2002:adf:e541:: with SMTP id z1mr378846wrm.95.1554407443135; Thu, 04 Apr 2019 12:50:43 -0700 (PDT) Received: from [192.168.1.13] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id y1sm56418064wrd.34.2019.04.04.12.50.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Apr 2019 12:50:41 -0700 (PDT) From: Yoav Nir Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_EF349E72-A4B2-4A76-B04A-29DD49682210" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Thu, 4 Apr 2019 22:50:39 +0300 In-Reply-To: <20190404155328.GF54777@kduck.mit.edu> Cc: Security Area Advisory Group To: Benjamin Kaduk References: <67FB6578-983F-4494-B5C6-269347CCDF19@gmail.com> <20190404155328.GF54777@kduck.mit.edu> X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [saag] Followup on mic comments X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 19:50:49 -0000 --Apple-Mail=_EF349E72-A4B2-4A76-B04A-29DD49682210 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 4 Apr 2019, at 18:53, Benjamin Kaduk wrote: >=20 > On Thu, Apr 04, 2019 at 06:49:11PM +0300, Yoav Nir wrote: >> Hi >>=20 >> This is following up on my mic comment at the SAAG meeting. >>=20 >> In the Snow-V Stream Cipher presentation (SNOW-V Stream Cipher = ), the claim was made that existing ciphers such as = AES-GCM and ChaCha20-Poly1305 were not fast enough for the application. >>=20 >> I said that I had recently measured throughput on a relatively new = CPU and got better results. Now that I am back at work, I have the = exact numbers. >>=20 >> So the server in question is a regular Intel-based server. The CPU = model is an Intel Xeon Gold 6150 running at 2.7 GHz, a relatively = high-end processor from late 2017. >> = https://ark.intel.com/content/www/us/en/ark/products/120490/intel-xeon-gol= d-6150-processor-24-75m-cache-2-70-ghz.html = >>=20 >> I used the =E2=80=9Copenssl speed=E2=80=9D utility to measure the = throughput, with version 1.1.1b of OpenSSL=20 >>=20 >> Results: >> AES-128-GCM: 5.341661 GB/s >> AES-256-GCM: 3.907859 GB/s >> ChaCha20-Poly1305: 2.420072 GB/s=20 >>=20 >> Translating to Gb/s these give 42.73, 31.26, and 19.36 Gb/s = respectively. >=20 > "openssl speed" is not necessarily the best/well-specified benchmark. > Please supply the exact command-line used (noting that you tend to = need to > use '-evp foo' in order to actually use the hardware support). Not the best or most well-specified, but easily the most available. You need the -evp flag to even test AES-GCM or ChaCha20-Poly1305. So = the command-line I used was: openssl speed -evp aes-128-gcm openssl speed -evp aes-256-gcm openssl speed -evp chacha20-poly1305 In all cases I used the value it output for 8192-byte blocks. Yoav --Apple-Mail=_EF349E72-A4B2-4A76-B04A-29DD49682210 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 4 Apr 2019, at 18:53, Benjamin Kaduk <kaduk@mit.edu> = wrote:

On Thu, Apr 04, 2019 at 06:49:11PM +0300, Yoav Nir wrote:
Hi

This is following up on my mic comment at the SAAG = meeting.

In the Snow-V Stream Cipher = presentation (SNOW-V Stream Cipher <https://datatracker.ietf.org/meeting/104/materials/slides-104-s= aag-snow-v-stream-cipher-00>), the claim was made that existing = ciphers such as AES-GCM and ChaCha20-Poly1305 were not fast enough for = the application.

I said that I had recently = measured throughput on a relatively new CPU and got better results. =  Now that I am back at work, I have the exact numbers.

So the server in question is a regular = Intel-based server. The CPU model is an Intel Xeon Gold 6150 running at = 2.7 GHz, a relatively high-end processor from late 2017.
https://ark.intel.com/content/www/us/en/ark/products/120490/int= el-xeon-gold-6150-processor-24-75m-cache-2-70-ghz.html <https://ark.intel.com/content/www/us/en/ark/products/120490/int= el-xeon-gold-6150-processor-24-75m-cache-2-70-ghz.html>

I used the =E2=80=9Copenssl speed=E2=80=9D = utility to measure the throughput, with version 1.1.1b of OpenSSL

Results:
AES-128-GCM: =  5.341661 GB/s
AES-256-GCM: 3.907859 GB/s
ChaCha20-Poly1305: 2.420072 GB/s

Translating to Gb/s these give 42.73, 31.26, and 19.36 Gb/s = respectively.

"openssl speed" = is not necessarily the best/well-specified benchmark.
Please= supply the exact command-line used (noting that you tend to need to
use '-evp foo' in order to actually use the hardware = support).

Not the best or most well-specified, but easily the most = available.

You = need the -evp flag to even test AES-GCM or ChaCha20-Poly1305.  So = the command-line I used was:
  • openssl speed -evp = aes-128-gcm
  • openssl speed -evp aes-256-gcm
  • openssl speed -evp chacha20-poly1305

In all cases I = used the value it output for 8192-byte blocks.

Yoav

= --Apple-Mail=_EF349E72-A4B2-4A76-B04A-29DD49682210-- From nobody Sat Apr 6 03:20:08 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF861201D1 for ; Sat, 6 Apr 2019 03:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 LGZgxMYoWhyg for ; Sat, 6 Apr 2019 03:20:03 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130071.outbound.protection.outlook.com [40.107.13.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E7381200E9 for ; Sat, 6 Apr 2019 03:20:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CtxTa+Ei+YsMuO2ksTmHwxMmbtOiOo4M02rUZ7RVBdE=; b=YTcYzc+vsMjlALgJu8W6fz9q8zrzJ3BD0x/f8+QyZSaVyU5mk2w5gHD9yfYLd+kZa7TNGyOf15Brzhp6OI5b0conmBp8TL/mgjZ6e6Bj/WOhrOEARO5OB6ozq6Io/AKvSvB7fm6pheVw727fm727zh/utlWBv5SaLyR3nUI8a3o= Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.166.22) by HE1PR07MB3483.eurprd07.prod.outlook.com (10.170.247.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.11; Sat, 6 Apr 2019 10:19:59 +0000 Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::d49e:f22a:1e0b:f888]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::d49e:f22a:1e0b:f888%5]) with mapi id 15.20.1792.007; Sat, 6 Apr 2019 10:19:59 +0000 From: John Mattsson To: Yoav Nir , Benjamin Kaduk CC: Security Area Advisory Group Thread-Topic: [saag] Followup on mic comments Thread-Index: AQHU6v4QGq1mx//hMEKwDaRjub3TcqYsJxoAgABCRYCAAqa+AA== Date: Sat, 6 Apr 2019 10:19:59 +0000 Message-ID: <5DFA02D1-E175-484E-B25E-F6CEC09E83D9@ericsson.com> References: <67FB6578-983F-4494-B5C6-269347CCDF19@gmail.com> <20190404155328.GF54777@kduck.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.17.1.190326 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [82.214.46.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: df737248-3b6f-47ec-15e3-08d6ba796cbc x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR07MB3483; x-ms-traffictypediagnostic: HE1PR07MB3483: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 0999136621 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(39860400002)(376002)(136003)(396003)(189003)(199004)(81156014)(81166006)(446003)(6436002)(8676002)(110136005)(476003)(2616005)(316002)(33656002)(486006)(11346002)(53936002)(99286004)(106356001)(6246003)(2171002)(105586002)(58126008)(6306002)(54896002)(6512007)(44832011)(97736004)(4326008)(7736002)(236005)(6486002)(5660300002)(8936002)(21615005)(229853002)(2906002)(14454004)(36756003)(186003)(68736007)(25786009)(71200400001)(83716004)(71190400001)(478600001)(3846002)(6116002)(102836004)(26005)(66066001)(82746002)(256004)(14444005)(966005)(53546011)(6506007)(86362001)(19627235002)(606006)(76176011); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3483; H:HE1PR07MB4169.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 3+gGJn0QHeYn4Xv+T56IatW3cBnrMHHTGzRP+L4Ff+0Nu/fqjKb8GRq5SP3FTf9xkVPC18kxEMLyD1G5AX9x8LlQv/KTPJZvAaMKGCSKPA24h3mM4OJirJSjN2THQp3LuLdqnL2OPdGzN6HcMSVoJ7y4DCGTnnIOkt6pww9kVsz46696qGuySMiGW8tryxUa4pHPs3CnDmmoYACpFHveAzFqtC+6Bvp7JciN63UZi+cI4oKANHObIvtvJuvCepbj7GaChfLGymaS4kBfC0aKnFnLV10L8ITY1qRrJdz9Lt2bAK8UlD8d13Xlp7+20+5L38dTkzbhcBxqVW2dyeUTh2buxQf5f4LZuxgQYqTEfKgib8tHzEV0yzjdC3xgZjiKVPbvtC3tXJIrMIP3ygYKJX44EJq0JHaU/gv91RvNGfc= Content-Type: multipart/alternative; boundary="_000_5DFA02D1E175484EB25EF6CEC09E83D9ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: df737248-3b6f-47ec-15e3-08d6ba796cbc X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2019 10:19:59.7098 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3483 Archived-At: Subject: Re: [saag] Followup on mic comments X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2019 10:20:07 -0000 --_000_5DFA02D1E175484EB25EF6CEC09E83D9ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClRoYW5rcyBhZ2FpbiBmb3IgeW91ciBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMgWW9h di4gQXMgeW91IHNhdyBpbiBteSBmb2xsb3cgdXAgcG9zdCwgSSBoYXZlIGFscmVhZHkgdXBkYXRl ZCB0aGUgcGVyZm9ybWFuY2UgbnVtYmVycyBieSBydW5uaW5nIG15IG93bi4gVGhlIGJlbmNobWFy a3MgdGhhdCBJIGZvdW5kIG9ubGluZSBhbmQgcHJlc2VudGVkIGF0IFNBQUcgdHVybmVkIG91dCB0 byBiZSBMaWJyZVNTTC4gQ29uZnVzaW5nIHRoYXQgdGhlIExpYnJlU1NMIGNvbW1hbmQgbGluZSB1 dGlsaXR5IGlzIGNhbGxlZCAnb3BlbnNzbCcuIExpYnJlU1NMIGlzIHNpZ25pZmljYW50bHkgc2xv d2VyIHRoYXQgT3BlblNTTC4NCg0KPnRoZSBjbGFpbSB3YXMgbWFkZSB0aGF0IGV4aXN0aW5nIGNp cGhlcnMgc3VjaCBhcyBBRVMtR0NNIGFuZCBDaGFDaGEyMC1Qb2x5MTMwNSA+d2VyZSBub3QgZmFz dCBlbm91Z2ggZm9yIHRoZSBhcHBsaWNhdGlvbi4NCg0KVGhlIGNsYWltIHdhcyBvbmx5IHRoYXQg Q2hhQ2hhMjAtUG9seTEzMDUgYXQgNSBHYnBzIHdhcyBub3QgZmFzdCBlbm91Z2guIEFFUy0yNTYt R0NNIGNsZWFybHkgbWVldHMgM0dQUCdzIHJlcXVpcmVtZW50cyBvbiBqdXN0IGEgc2luZ2xlIGNv cmUuIENoYUNoYTIwLVBvbHkxMzA1IGF0IDE4IEdicHMgaXMgZ2V0dGluZyBjbG9zZXIsIGJ1dCAz MCBHYnBzIGlzIGNsZWFybHkgYmV0dGVyIGluIHRlcm1zIG9mIENQVSB1dGlsaXphdGlvbi4NCg0K TnVtYmVycyBiZWxvdyBmcm9tIE9wZW5TU0wgMS4xLjFiIG9uIGFuIGk3LTY3MDBLIDQuMCBHSHou DQoNCm9wZW5zc2wgc3BlZWQgLWV2cCAiY2lwaGVyX25hbWUiDQoNCiAgICAgICAgICAgICAgICAg ICAgICAgIDEwMjQgYnl0ZXMgICAgICAgICAgMTYzODQgYnl0ZXMNCmFlcy0yNTYtY3RyICAgICAg ICAgICAgIDMyLjIzIEdicHMgICAgICAgICAgMzYuNTkgR2Jwcw0KYWVzLTI1Ni1nY20gICAgICAg ICAgICAgMjguNDggR2JwcyAgICAgICAgICAzNi4wMSBHYnBzDQphZXMtMjU2LW9jYiAgICAgICAg ICAgICAzMS4wMiBHYnBzICAgICAgICAgIDM2LjI0IEdicHMNCmNoYWNoYTIwICAgICAgICAgICAg ICAgIDI2LjE3IEdicHMgICAgICAgICAgMjcuNzIgR2Jwcw0KY2hhY2hhMjAtcG9seTEzMDUgICAg ICAgMTcuNjEgR2JwcyAgICAgICAgICAxOS4yOSBHYnBzDQoNCk51bWJlcnMgYmVsb3cgZnJvbSBP cGVuU1NMIDEuMS4xYiBvbiBhbiBpNy04NjUwVSAxLjkgR0h6ICgxNjM4NCBieXRlcykuDQoNCm9w ZW5zc2wgc3BlZWQgLWV2cCAiY2lwaGVyX25hbWUiDQoNCkFFUy0yNTYtQ1RSICAgICAgICAgICAg IDM0Ljc4IEdicHMgICAgICAgICAgQXNzZW1ibHksIE9wZW5TU0wgMS4xLjENCkFFUy0yNTYtR0NN ICAgICAgICAgICAgIDM0LjU4IEdicHMgICAgICAgICAgQXNzZW1ibHksIE9wZW5TU0wgMS4xLjEN Cg0KTnVtYmVycyBiZWxvdyBmcm9tIEMrKyBjb2RlIG9uIGFuIDctODY1MFUgMS45IEdIeiAobG9u ZyBwbGFpbnRleHRzKQ0KDQpTTk9XLVYgICAgICAgICAgICAgICAgICA2NC4wMSBHYnBzICAgICAg ICAgIEMrKywgQWxleGFuZGVyIE1heGltb3YNClNOT1ctVi1HQ00gICAgICAgICAgICAgIDQyLjQw IEdicHMgICAgICAgICAgQysrLCBBbGV4YW5kZXIgTWF4aW1vdg0KQUVTLTI1Ni1DVFIgICAgICAg ICAgICAgMzUuNzUgR2JwcyAgICAgICAgICBDKyssIEFsZXhhbmRlciBNYXhpbW92DQpBRVMtMjU2 LUdDTSAgICAgICAgICAgICAyNS41MCBHYnBzICAgICAgICAgIEMrKywgQWxleGFuZGVyIE1heGlt b3YNCg0KTm90ZSB0aGF0IENQVSBmcmVxdWVuY3kgaXMgbm8gbG9uZ2VyIGZpeGVkIGFuZCB0aGF0 IENQVXMgZHluYW1pY2FsbHkgaW5jcmVhc2UgdGhlaXIgZnJlcXVlbmN5IHRvIG1lZXQgcGVyZm9y bWFuY2UgZGVtYW5kcyBvciBsb3dlciB0aGVpciBmcmVxdWVuY3kgdG8gbWVldCB0aGVybWFsIHJl cXVpcmVtZW50cy4NClRoZSBDUFVzIEkgdGVzdGVkIG9uIG9ubHkgaGF2ZSBBVlgyIHdoaWxlIHlv dXIgQ1BVIGhhcyBBVlgtNTEyLiBTdGlsbCB0aGUgbnVtYmVycyBmb3IgQUVTLUdDTSBhcmUgcXVp dGUgc2ltaWxhciBpZiBvbmUgYXNzdW1lcyB0aGF0IHRoZSBDUFVzIHJhbiBhdCB0aGVpciBUdXJi byBmcmVxdWVuY2llcyBkdXJpbmcgdGhlIGJlbmNobWFya3MuICBUaGlzIHNlZW1zIHRvIGluZGlj YXRlIHRoYXQgQVZYLTUxMiB3ZXJlIG5vdCB1dGlsaXplZCBpbiB5b3VyIGJlbmNobWFya3MgYW5k IHRoYXQgYW4gQUVTLUdDTSBpbXBsZW1lbnRhdGlvbiB0aGF0IG1hZGUgdXNlIG9mIEFWWC01MTIg Y291bGQgYmUgc2lnbmlmaWNhbnRseSBmYXN0ZXIgKHRoZW9yZXRpY2FsbHkgdHdpY2UgYXMgZmFz dCkuIEl0IGNvdWxkIG9mIGNvdXJzZSBhbHNvIGluZGljYXRlIHRoYXQgQVZYLTUxMiBkb2VzIG5v dCBwcm92aWRlIG11Y2ggc3BlZWR1cCBmb3IgQUVTLUdDTS4NCg0KQ2hlZXJzLA0KSm9obg0KDQoN CkZyb206IHNhYWcgPHNhYWctYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIFlvYXYgTmly IDx5bmlyLmlldGZAZ21haWwuY29tPg0KRGF0ZTogVGh1cnNkYXksIDQgQXByaWwgMjAxOSBhdCAy MTo1MQ0KVG86IEJlbmphbWluIEthZHVrIDxrYWR1a0BtaXQuZWR1Pg0KQ2M6IFNlY3VyaXR5IEFy ZWEgQWR2aXNvcnkgR3JvdXAgPHNhYWdAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NhYWddIEZv bGxvd3VwIG9uIG1pYyBjb21tZW50cw0KDQoNCg0KDQpPbiA0IEFwciAyMDE5LCBhdCAxODo1Mywg QmVuamFtaW4gS2FkdWsgPGthZHVrQG1pdC5lZHU8bWFpbHRvOmthZHVrQG1pdC5lZHU+PiB3cm90 ZToNCg0KT24gVGh1LCBBcHIgMDQsIDIwMTkgYXQgMDY6NDk6MTFQTSArMDMwMCwgWW9hdiBOaXIg d3JvdGU6DQoNCkhpDQoNClRoaXMgaXMgZm9sbG93aW5nIHVwIG9uIG15IG1pYyBjb21tZW50IGF0 IHRoZSBTQUFHIG1lZXRpbmcuDQoNCkluIHRoZSBTbm93LVYgU3RyZWFtIENpcGhlciBwcmVzZW50 YXRpb24gKFNOT1ctViBTdHJlYW0gQ2lwaGVyIDxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L21lZXRpbmcvMTA0L21hdGVyaWFscy9zbGlkZXMtMTA0LXNhYWctc25vdy12LXN0cmVhbS1jaXBo ZXItMDA+KSwgdGhlIGNsYWltIHdhcyBtYWRlIHRoYXQgZXhpc3RpbmcgY2lwaGVycyBzdWNoIGFz IEFFUy1HQ00gYW5kIENoYUNoYTIwLVBvbHkxMzA1IHdlcmUgbm90IGZhc3QgZW5vdWdoIGZvciB0 aGUgYXBwbGljYXRpb24uDQoNCkkgc2FpZCB0aGF0IEkgaGFkIHJlY2VudGx5IG1lYXN1cmVkIHRo cm91Z2hwdXQgb24gYSByZWxhdGl2ZWx5IG5ldyBDUFUgYW5kIGdvdCBiZXR0ZXIgcmVzdWx0cy4g IE5vdyB0aGF0IEkgYW0gYmFjayBhdCB3b3JrLCBJIGhhdmUgdGhlIGV4YWN0IG51bWJlcnMuDQoN ClNvIHRoZSBzZXJ2ZXIgaW4gcXVlc3Rpb24gaXMgYSByZWd1bGFyIEludGVsLWJhc2VkIHNlcnZl ci4gVGhlIENQVSBtb2RlbCBpcyBhbiBJbnRlbCBYZW9uIEdvbGQgNjE1MCBydW5uaW5nIGF0IDIu NyBHSHosIGEgcmVsYXRpdmVseSBoaWdoLWVuZCBwcm9jZXNzb3IgZnJvbSBsYXRlIDIwMTcuDQpo dHRwczovL2Fyay5pbnRlbC5jb20vY29udGVudC93d3cvdXMvZW4vYXJrL3Byb2R1Y3RzLzEyMDQ5 MC9pbnRlbC14ZW9uLWdvbGQtNjE1MC1wcm9jZXNzb3ItMjQtNzVtLWNhY2hlLTItNzAtZ2h6Lmh0 bWwgPGh0dHBzOi8vYXJrLmludGVsLmNvbS9jb250ZW50L3d3dy91cy9lbi9hcmsvcHJvZHVjdHMv MTIwNDkwL2ludGVsLXhlb24tZ29sZC02MTUwLXByb2Nlc3Nvci0yNC03NW0tY2FjaGUtMi03MC1n aHouaHRtbD4NCg0KSSB1c2VkIHRoZSDigJxvcGVuc3NsIHNwZWVk4oCdIHV0aWxpdHkgdG8gbWVh c3VyZSB0aGUgdGhyb3VnaHB1dCwgd2l0aCB2ZXJzaW9uIDEuMS4xYiBvZiBPcGVuU1NMDQoNClJl c3VsdHM6DQpBRVMtMTI4LUdDTTogIDUuMzQxNjYxIEdCL3MNCkFFUy0yNTYtR0NNOiAzLjkwNzg1 OSBHQi9zDQpDaGFDaGEyMC1Qb2x5MTMwNTogMi40MjAwNzIgR0Ivcw0KDQpUcmFuc2xhdGluZyB0 byBHYi9zIHRoZXNlIGdpdmUgNDIuNzMsIDMxLjI2LCBhbmQgMTkuMzYgR2IvcyByZXNwZWN0aXZl bHkuDQoNCiJvcGVuc3NsIHNwZWVkIiBpcyBub3QgbmVjZXNzYXJpbHkgdGhlIGJlc3Qvd2VsbC1z cGVjaWZpZWQgYmVuY2htYXJrLg0KUGxlYXNlIHN1cHBseSB0aGUgZXhhY3QgY29tbWFuZC1saW5l IHVzZWQgKG5vdGluZyB0aGF0IHlvdSB0ZW5kIHRvIG5lZWQgdG8NCnVzZSAnLWV2cCBmb28nIGlu IG9yZGVyIHRvIGFjdHVhbGx5IHVzZSB0aGUgaGFyZHdhcmUgc3VwcG9ydCkuDQoNCk5vdCB0aGUg YmVzdCBvciBtb3N0IHdlbGwtc3BlY2lmaWVkLCBidXQgZWFzaWx5IHRoZSBtb3N0IGF2YWlsYWJs ZS4NCg0KWW91IG5lZWQgdGhlIC1ldnAgZmxhZyB0byBldmVuIHRlc3QgQUVTLUdDTSBvciBDaGFD aGEyMC1Qb2x5MTMwNS4gIFNvIHRoZSBjb21tYW5kLWxpbmUgSSB1c2VkIHdhczoNCsK3ICAgICAg ICAgb3BlbnNzbCBzcGVlZCAtZXZwIGFlcy0xMjgtZ2NtDQrCtyAgICAgICAgIG9wZW5zc2wgc3Bl ZWQgLWV2cCBhZXMtMjU2LWdjbQ0KwrcgICAgICAgICBvcGVuc3NsIHNwZWVkIC1ldnAgY2hhY2hh MjAtcG9seTEzMDUNCg0KSW4gYWxsIGNhc2VzIEkgdXNlZCB0aGUgdmFsdWUgaXQgb3V0cHV0IGZv ciA4MTkyLWJ5dGUgYmxvY2tzLg0KDQpZb2F2DQoNCg== --_000_5DFA02D1E175484EB25EF6CEC09E83D9ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXtt c28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFy Z2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVm dDowY207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0 Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxp c3QgbDANCgl7bXNvLWxpc3QtaWQ6MTI5NDQ4NjU0MzsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6 ODc5MzY3Nzg0O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDoxMDguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxNDQu MHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGww OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDoyODguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozMjQuMHB0 Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N Cm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0t Pjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJTViIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhhbmtzIGFnYWluIGZv ciB5b3VyIGNvbW1lbnRzIGFuZCBzdWdnZXN0aW9ucyBZb2F2LiBBcyB5b3Ugc2F3IGluIG15IGZv bGxvdyB1cCBwb3N0LCBJIGhhdmUgYWxyZWFkeSB1cGRhdGVkIHRoZSBwZXJmb3JtYW5jZSBudW1i ZXJzIGJ5IHJ1bm5pbmcgbXkgb3duLiBUaGUgYmVuY2htYXJrcyB0aGF0IEkgZm91bmQgb25saW5l IGFuZCBwcmVzZW50ZWQgYXQgU0FBRyB0dXJuZWQgb3V0DQogdG8gYmUgTGlicmVTU0wuIENvbmZ1 c2luZyB0aGF0IHRoZSBMaWJyZVNTTCBjb21tYW5kIGxpbmUgdXRpbGl0eSBpcyBjYWxsZWQgJ29w ZW5zc2wnLiBMaWJyZVNTTCBpcyBzaWduaWZpY2FudGx5IHNsb3dlciB0aGF0IE9wZW5TU0wuPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj4mZ3Q7dGhlIGNsYWltIHdhcyBtYWRlIHRoYXQgZXhpc3RpbmcgY2lwaGVycyBz dWNoIGFzIEFFUy1HQ00gYW5kIENoYUNoYTIwLVBvbHkxMzA1ICZndDt3ZXJlIG5vdCBmYXN0IGVu b3VnaCBmb3IgdGhlIGFwcGxpY2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIGNsYWltIHdh cyBvbmx5IHRoYXQgQ2hhQ2hhMjAtUG9seTEzMDUgYXQgNSBHYnBzIHdhcyBub3QgZmFzdCBlbm91 Z2guIEFFUy0yNTYtR0NNIGNsZWFybHkgbWVldHMgM0dQUCdzIHJlcXVpcmVtZW50cyBvbiBqdXN0 IGEgc2luZ2xlIGNvcmUuIENoYUNoYTIwLVBvbHkxMzA1IGF0IDE4IEdicHMgaXMgZ2V0dGluZyBj bG9zZXIsIGJ1dCAzMCBHYnBzIGlzIGNsZWFybHkgYmV0dGVyDQogaW4gdGVybXMgb2YgQ1BVIHV0 aWxpemF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+TnVtYmVycyBiZWxvdyBmcm9tIE9wZW5TU0wg MS4xLjFiIG9uIGFuIGk3LTY3MDBLIDQuMCBHSHouPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5vcGVuc3Ns IHNwZWVkIC1ldnAgJnF1b3Q7Y2lwaGVyX25hbWUmcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxMDI0IGJ5dGVzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDE2Mzg0IGJ5dGVzDQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+YWVzLTI1 Ni1jdHImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgMzIuMjMgR2JwcyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAzNi41OSBHYnBzPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPmFlcy0yNTYtZ2Nt Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDI4LjQ4IEdicHMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMzYuMDEgR2JwczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5hZXMtMjU2LW9jYiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAzMS4wMiBHYnBzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDM2LjI0IEdicHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Y2hhY2hhMjAmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgMjYuMTcgR2JwcyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAyNy43MiBHYnBzPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPmNoYWNoYTIwLXBv bHkxMzA1Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDE3LjYxIEdicHMmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMTkuMjkg R2JwczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+TnVtYmVycyBiZWxvdyBmcm9tIE9wZW5TU0wgMS4xLjFi IG9uIGFuIGk3LTg2NTBVIDEuOSBHSHogKDE2Mzg0IGJ5dGVzKS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi Pm9wZW5zc2wgc3BlZWQgLWV2cCAmcXVvdDtjaXBoZXJfbmFtZSZxdW90OzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+QUVTLTI1Ni1DVFImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMzQuNzggR2JwcyZuYnNwOyZuYnNwOyZu YnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtBc3NlbWJseSwgT3BlblNT TCAxLjEuMTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5BRVMtMjU2LUdDTSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAzNC41OCBHYnBzJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFzc2VtYmx5 LCBPcGVuU1NMIDEuMS4xPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5OdW1iZXJzIGJlbG93IGZyb20gQyYj NDM7JiM0MzsgY29kZSBvbiBhbiA3LTg2NTBVIDEuOSBHSHogKGxvbmcgcGxhaW50ZXh0cyk8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPlNOT1ctViZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyA2NC4wMSBHYnBzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IEMmIzQzOyYjNDM7LCBBbGV4YW5kZXIgTWF4aW1vdjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5T Tk9XLVYtR0NNJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOzQyLjQwIEdicHMmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQyYjNDM7JiM0MzssIEFsZXhh bmRlciBNYXhpbW92PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPkFFUy0yNTYtQ1RSJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDM1Ljc1IEdicHMm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQyYj NDM7JiM0MzssIEFsZXhhbmRlciBNYXhpbW92PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkFFUy0yNTYtR0NNJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IDI1LjUwIEdicHMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgQyYjNDM7JiM0MzssIEFsZXhhbmRlciBNYXhpbW92PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5Ob3RlIHRoYXQgQ1BVIGZyZXF1ZW5jeSBpcyBubyBsb25nZXIgZml4ZWQgYW5kIHRoYXQg Q1BVcyBkeW5hbWljYWxseSBpbmNyZWFzZSB0aGVpciBmcmVxdWVuY3kgdG8gbWVldCBwZXJmb3Jt YW5jZSBkZW1hbmRzIG9yIGxvd2VyIHRoZWlyIGZyZXF1ZW5jeSB0byBtZWV0IHRoZXJtYWwgcmVx dWlyZW1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIENQVXMgSSB0ZXN0ZWQgb24gb25seSBoYXZlIEFW WDIgd2hpbGUgeW91ciBDUFUgaGFzIEFWWC01MTIuIFN0aWxsIHRoZSBudW1iZXJzIGZvciBBRVMt R0NNIGFyZSBxdWl0ZSBzaW1pbGFyIGlmIG9uZSBhc3N1bWVzIHRoYXQgdGhlIENQVXMgcmFuIGF0 IHRoZWlyIFR1cmJvIGZyZXF1ZW5jaWVzIGR1cmluZyB0aGUgYmVuY2htYXJrcy4mbmJzcDsgVGhp cyBzZWVtcyB0byBpbmRpY2F0ZQ0KIHRoYXQgQVZYLTUxMiB3ZXJlIG5vdCB1dGlsaXplZCBpbiB5 b3VyIGJlbmNobWFya3MgYW5kIHRoYXQgYW4gQUVTLUdDTSBpbXBsZW1lbnRhdGlvbiB0aGF0IG1h ZGUgdXNlIG9mIEFWWC01MTIgY291bGQgYmUgc2lnbmlmaWNhbnRseSBmYXN0ZXIgKHRoZW9yZXRp Y2FsbHkgdHdpY2UgYXMgZmFzdCkuIEl0IGNvdWxkIG9mIGNvdXJzZSBhbHNvIGluZGljYXRlIHRo YXQgQVZYLTUxMiBkb2VzIG5vdCBwcm92aWRlIG11Y2ggc3BlZWR1cCBmb3IgQUVTLUdDTS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Sm9objxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5zYWFnICZsdDtzYWFnLWJvdW5j ZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBZb2F2IE5pciAmbHQ7eW5pci5pZXRmQGdtYWls LmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VGh1cnNkYXksIDQgQXByaWwgMjAxOSBhdCAyMTo1 MTxicj4NCjxiPlRvOiA8L2I+QmVuamFtaW4gS2FkdWsgJmx0O2thZHVrQG1pdC5lZHUmZ3Q7PGJy Pg0KPGI+Q2M6IDwvYj5TZWN1cml0eSBBcmVhIEFkdmlzb3J5IEdyb3VwICZsdDtzYWFnQGlldGYu b3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW3NhYWddIEZvbGxvd3VwIG9uIG1pYyBj b21tZW50czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPk9uIDQg QXByIDIwMTksIGF0IDE4OjUzLCBCZW5qYW1pbiBLYWR1ayAmbHQ7PGEgaHJlZj0ibWFpbHRvOmth ZHVrQG1pdC5lZHUiPmthZHVrQG1pdC5lZHU8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPk9uIFRodSwgQXByIDA0LCAyMDE5IGF0IDA2OjQ5 OjExUE0gJiM0MzswMzAwLCBZb2F2IE5pciB3cm90ZTo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwv cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SGk8 YnI+DQo8YnI+DQpUaGlzIGlzIGZvbGxvd2luZyB1cCBvbiBteSBtaWMgY29tbWVudCBhdCB0aGUg U0FBRyBtZWV0aW5nLjxicj4NCjxicj4NCkluIHRoZSBTbm93LVYgU3RyZWFtIENpcGhlciBwcmVz ZW50YXRpb24gKFNOT1ctViBTdHJlYW0gQ2lwaGVyICZsdDs8YSBocmVmPSJodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL21lZXRpbmcvMTA0L21hdGVyaWFscy9zbGlkZXMtMTA0LXNhYWctc25v dy12LXN0cmVhbS1jaXBoZXItMDAiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGlu Zy8xMDQvbWF0ZXJpYWxzL3NsaWRlcy0xMDQtc2FhZy1zbm93LXYtc3RyZWFtLWNpcGhlci0wMDwv YT4mZ3Q7KSwNCiB0aGUgY2xhaW0gd2FzIG1hZGUgdGhhdCBleGlzdGluZyBjaXBoZXJzIHN1Y2gg YXMgQUVTLUdDTSBhbmQgQ2hhQ2hhMjAtUG9seTEzMDUgd2VyZSBub3QgZmFzdCBlbm91Z2ggZm9y IHRoZSBhcHBsaWNhdGlvbi48YnI+DQo8YnI+DQpJIHNhaWQgdGhhdCBJIGhhZCByZWNlbnRseSBt ZWFzdXJlZCB0aHJvdWdocHV0IG9uIGEgcmVsYXRpdmVseSBuZXcgQ1BVIGFuZCBnb3QgYmV0dGVy IHJlc3VsdHMuICZuYnNwO05vdyB0aGF0IEkgYW0gYmFjayBhdCB3b3JrLCBJIGhhdmUgdGhlIGV4 YWN0IG51bWJlcnMuPGJyPg0KPGJyPg0KU28gdGhlIHNlcnZlciBpbiBxdWVzdGlvbiBpcyBhIHJl Z3VsYXIgSW50ZWwtYmFzZWQgc2VydmVyLiBUaGUgQ1BVIG1vZGVsIGlzIGFuIEludGVsIFhlb24g R29sZCA2MTUwIHJ1bm5pbmcgYXQgMi43IEdIeiwgYSByZWxhdGl2ZWx5IGhpZ2gtZW5kIHByb2Nl c3NvciBmcm9tIGxhdGUgMjAxNy48YnI+DQo8YSBocmVmPSJodHRwczovL2Fyay5pbnRlbC5jb20v Y29udGVudC93d3cvdXMvZW4vYXJrL3Byb2R1Y3RzLzEyMDQ5MC9pbnRlbC14ZW9uLWdvbGQtNjE1 MC1wcm9jZXNzb3ItMjQtNzVtLWNhY2hlLTItNzAtZ2h6Lmh0bWwiPmh0dHBzOi8vYXJrLmludGVs LmNvbS9jb250ZW50L3d3dy91cy9lbi9hcmsvcHJvZHVjdHMvMTIwNDkwL2ludGVsLXhlb24tZ29s ZC02MTUwLXByb2Nlc3Nvci0yNC03NW0tY2FjaGUtMi03MC1naHouaHRtbDwvYT4gJmx0OzxhIGhy ZWY9Imh0dHBzOi8vYXJrLmludGVsLmNvbS9jb250ZW50L3d3dy91cy9lbi9hcmsvcHJvZHVjdHMv MTIwNDkwL2ludGVsLXhlb24tZ29sZC02MTUwLXByb2Nlc3Nvci0yNC03NW0tY2FjaGUtMi03MC1n aHouaHRtbCI+aHR0cHM6Ly9hcmsuaW50ZWwuY29tL2NvbnRlbnQvd3d3L3VzL2VuL2Fyay9wcm9k dWN0cy8xMjA0OTAvaW50ZWwteGVvbi1nb2xkLTYxNTAtcHJvY2Vzc29yLTI0LTc1bS1jYWNoZS0y LTcwLWdoei5odG1sPC9hPiZndDs8YnI+DQo8YnI+DQpJIHVzZWQgdGhlIOKAnG9wZW5zc2wgc3Bl ZWTigJ0gdXRpbGl0eSB0byBtZWFzdXJlIHRoZSB0aHJvdWdocHV0LCB3aXRoIHZlcnNpb24gMS4x LjFiIG9mIE9wZW5TU0wNCjxicj4NCjxicj4NClJlc3VsdHM6PGJyPg0KQUVTLTEyOC1HQ006ICZu YnNwOzUuMzQxNjYxIEdCL3M8YnI+DQpBRVMtMjU2LUdDTTogMy45MDc4NTkgR0Ivczxicj4NCkNo YUNoYTIwLVBvbHkxMzA1OiAyLjQyMDA3MiBHQi9zIDxicj4NCjxicj4NClRyYW5zbGF0aW5nIHRv IEdiL3MgdGhlc2UgZ2l2ZSA0Mi43MywgMzEuMjYsIGFuZCAxOS4zNiBHYi9zIHJlc3BlY3RpdmVs eS48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxicj4NCiZxdW90O29wZW5zc2wgc3BlZWQmcXVvdDsg aXMgbm90IG5lY2Vzc2FyaWx5IHRoZSBiZXN0L3dlbGwtc3BlY2lmaWVkIGJlbmNobWFyay48YnI+ DQpQbGVhc2Ugc3VwcGx5IHRoZSBleGFjdCBjb21tYW5kLWxpbmUgdXNlZCAobm90aW5nIHRoYXQg eW91IHRlbmQgdG8gbmVlZCB0bzxicj4NCnVzZSAnLWV2cCBmb28nIGluIG9yZGVyIHRvIGFjdHVh bGx5IHVzZSB0aGUgaGFyZHdhcmUgc3VwcG9ydCkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5Ob3QgdGhlIGJlc3Qgb3Ig bW9zdCB3ZWxsLXNwZWNpZmllZCwgYnV0IGVhc2lseSB0aGUgbW9zdCBhdmFpbGFibGUuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPllvdSBuZWVkIHRo ZSAtZXZwIGZsYWcgdG8gZXZlbiB0ZXN0IEFFUy1HQ00gb3IgQ2hhQ2hhMjAtUG9seTEzMDUuICZu YnNwO1NvIHRoZSBjb21tYW5kLWxpbmUgSSB1c2VkIHdhczo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1p bmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExp c3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wiPjxz cGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5vcGVuc3Ns IHNwZWVkIC1ldnAgYWVzLTEyOC1nY208bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBs ZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUi PsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48 L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5vcGVuc3NsIHNwZWVkIC1ldnAgYWVzLTI1Ni1nY208bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4 dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9y dExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wi PjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQg JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5vcGVu c3NsIHNwZWVkIC1ldnAgY2hhY2hhMjAtcG9seTEzMDU8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SW4gYWxsIGNhc2VzIEkgdXNlZCB0aGUgdmFsdWUg aXQgb3V0cHV0IGZvciA4MTkyLWJ5dGUgYmxvY2tzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5Zb2F2PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_5DFA02D1E175484EB25EF6CEC09E83D9ericssoncom_-- From nobody Mon Apr 8 19:51:54 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9B551200CC for ; Mon, 8 Apr 2019 19:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nightwatchcybersecurity-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3hhwiYoADvV for ; Mon, 8 Apr 2019 19:51:50 -0700 (PDT) Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1443120043 for ; Mon, 8 Apr 2019 19:51:50 -0700 (PDT) Received: by mail-pl1-x62a.google.com with SMTP id d1so8477234plj.8 for ; Mon, 08 Apr 2019 19:51:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nightwatchcybersecurity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=HkErrIafArBorosfWtte3eo9EFYkp/HkUSTf6ra4Dl4=; b=YlR91/mDjLM0vHYDhSYbhK+gsUoFE+DK27bRq+1g2A7c+FFH2GRys8m5tAJUCg4VFl M0XaPjxSC/WNlCZr5nR1IbRuYc9w4q+Lw8YP+qnGzeUGE03tZz7qASMAsVKXEmWFlCfv bR6V8Lq3rKTkhYAWbLvJ1qoC1rty8WzPepkZcbEvT8PSYTmLUn1SB3m53zFKEzOKCo5S a8X8o04abR1FBp89kQsY53f4CQVHyv0e5sKjIntkxU3ygOtnXa+K9p5mL0QGpzFYeaj9 Iq8YQUMxbSgu6cm69P1l4pLYrIxJE7VWs7rTnKFSYKfWKewW1brVuHH5x1jnh7OqK1ew oDeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=HkErrIafArBorosfWtte3eo9EFYkp/HkUSTf6ra4Dl4=; b=aAM5gGt0jMIWJv3nOHISPcJXUQCxGOU/bmFpJSMeHncNJPzdpdSQCALsz0JBe21sWq 8jqlrfTljDdJ7jNimRXv7Lor5qJrAxVAEgNw/LH5askNjzJ22qby4s3n2Q3H0r0v0iRj Q8oWK2/7StZhojkHmWnpkDEq6/rXD/ToaT7cjen6p7aB1I3ZBmqwWL7DRKXLP79Iyo41 8K3ugB7Y3JW7lkkzdsvwA588ktmtCd/ujqJ/BGWdcsNbQ1f/oDsoUXJU3be1Wf0qcXw5 jhsIQzqBeIQH0HWIIB48yexTpv2kBmULip4Nb8/106AkbhJyGYBaNwI7AVF+bebceLsN EX5Q== X-Gm-Message-State: APjAAAWNhF9JHCWVt7Jl2y0fGOAigPzv/XM/3bC66zb9lPGDzUNpD44X QmL09jBr8uyCG18qQ20ZUCfNgywcz3ymJ9AABdi9k16vuhEmUA== X-Google-Smtp-Source: APXvYqwGOSZQ4pjlvsWKAapB/6xgPcHPDrXg/zNZCaW4XjcNoFgmjx4Vyx3UrRnz0dvYPQ8nXtNVgLrTHFHfW7ykVxg= X-Received: by 2002:a17:902:2865:: with SMTP id e92mr12467686plb.269.1554778309836; Mon, 08 Apr 2019 19:51:49 -0700 (PDT) MIME-Version: 1.0 References: <155477813951.30177.56723471660902532.idtracker@ietfa.amsl.com> In-Reply-To: <155477813951.30177.56723471660902532.idtracker@ietfa.amsl.com> From: Yakov Shafranovich Date: Mon, 8 Apr 2019 22:51:13 -0400 Message-ID: To: Security Area Advisory Group Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [saag] New version: draft-foudil-securitytxt-06.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 02:51:53 -0000 Many changes were made based on the feedback from this group and others, including mandating HTTPS, and an expanded security considerations section. Thanks ---------- Forwarded message --------- From: Date: Mon, Apr 8, 2019 at 10:49 PM Subject: New Version Notification for draft-foudil-securitytxt-06.txt To: Edwin Foudil , Yakov Shafranovich A new version of I-D, draft-foudil-securitytxt-06.txt has been successfully submitted by Yakov Shafranovich and posted to the IETF repository. Name: draft-foudil-securitytxt Revision: 06 Title: A Method for Web Security Policies Document date: 2019-04-08 Group: Individual Submission Pages: 22 URL: https://www.ietf.org/internet-drafts/draft-foudil-securitytxt-06.txt Status: https://datatracker.ietf.org/doc/draft-foudil-securitytxt/ Htmlized: https://tools.ietf.org/html/draft-foudil-securitytxt-06 Htmlized: https://datatracker.ietf.org/doc/html/draft-foudil-securitytxt Diff: https://www.ietf.org/rfcdiff?url2=draft-foudil-securitytxt-06 Abstract: When security vulnerabilities are discovered by independent security researchers, they often lack the channels to report them properly. As a result, security vulnerabilities may be left unreported. This document defines a format ("security.txt") to help organizations describe the process for security researchers to follow in order to report security vulnerabilities. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Tue Apr 9 11:29:38 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2657120196 for ; Tue, 9 Apr 2019 11:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxSfftyT3KoP for ; Tue, 9 Apr 2019 11:29:35 -0700 (PDT) Received: from mail-it1-f179.google.com (mail-it1-f179.google.com [209.85.166.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9B8E120183 for ; Tue, 9 Apr 2019 11:29:35 -0700 (PDT) Received: by mail-it1-f179.google.com with SMTP id 139so6623351ita.4 for ; Tue, 09 Apr 2019 11:29:35 -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=HiWSuwPnQmV3Fx9pSKJSsTh7kVhok42bcqxaFw470uM=; b=SOo0XE/Y7ARNG3XIoxEyBLvYmbmvRng4wLMewRpspHF9hX1NhyXQuvlpUWFRLB4WOD EC/OHG3kWnsoGZoBqkf8T8FXH4eXDpXgZuRxObOabQIhickZ4iAdtG8vyJPfx9ODb3ii 8U72J74bBJzORvMHqB+gm/XzD5Gs96AdqiM6QIUotCY4qefWQH4kS4Z9w1NbgXSCO6pG 9bxyZHEWXkzTpotqZLBqibTpKzAJHIReFJG8Xo2Sy8s+FQyU4LeXp0v2Ex1hDaK7Rhh5 3fAT1nh0+/NZGZjz2NzrYpRhIEO3y1/+z+OMjyopz/nWGeU6N/YUbeCbhtaC9LXqcelI sCiA== X-Gm-Message-State: APjAAAXVyODDb9qZdP6F3mzD7eVP+XeemgGEfErOWneXj0kuaAlGtVlF YLXpQ06pTu5JMIzVlT+fPPTRY9CAIkyZ2nR2JAoU X-Google-Smtp-Source: APXvYqzUrASs34PBGPSJwP2EC0DcK0FJwM/JhPOa7WAW8++zsjUXo8GQWNHOqunpTojhKBb9fQUtbx2lLmvbiQ9Q7tg= X-Received: by 2002:a24:ad2:: with SMTP id 201mr25181360itw.26.1554834574726; Tue, 09 Apr 2019 11:29:34 -0700 (PDT) MIME-Version: 1.0 From: Michael Richardson Date: Tue, 9 Apr 2019 13:37:23 -0400 Message-ID: To: saag@ietf.org, phill@hallambaker.com Content-Type: multipart/alternative; boundary="00000000000082dde105861d2292" Archived-At: Subject: [saag] draft-hallambaker-mesh-udf-02 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 18:29:37 -0000 --00000000000082dde105861d2292 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Phill, I am reading your UDF document with the idea that IoT devices on constrained networks can send a reference to an IDevID rather than send the IDevID in-band. This would apply to both DTLS and also to EDHOC and HIP (such as for 802.15.9 keying). I was reading section 1.2, and it says: The UDF EARL locator shown above is resolved by first determining the Web Service Endpoint for the mmm-udf service for the domain example.com. =C2=B6 Discover ("example.com", "mmm-udf") =3D https://example.com/.well-known/mmm-udf/ Next the fingerprint of the source UDF is obtained. I was surprised that you went straight to http without a DNS SRV lookup. This is a Greenfield, and adding that in seems like a good thing. Okay, so section 6.2 includes text: The use of DNS Web Discovery permits service providers to make full use of the load balancing and service description capabilities afforded by use of DNS SRV and TXT records in accordance with the approach described in [RFC6763]. Maybe should mention this in section 1, or maybe just make the explanation less authoritive sounding 8-; Section 1.3 will need a forward reference. I really like section 3.2. application/pkix-keyinfo I did not know this was a thing... Ah You are going to register it. You have specified rfc3986 rather than 3987, so your URI are not internationalized. Is there a reason for that? Can you advance the use document without the rest of mmm? --00000000000082dde105861d2292 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Phill, I am reading your UDF document w= ith the idea that IoT devices on constrained networks can send a reference = to an IDevID rather than send the IDevID in-band.=C2=A0 This would apply to= both DTLS and also to EDHOC and HIP (such as for 802.15.9 keying).

I was reading section 1.2, and = it says:



=C2=A0 =C2=A0The UDF EARL locator = shown above is=C2=A0
=C2=A0 =C2=A0resolved by first = determining the Web
=C2=A0 =C2=A0Service Endpoint fo= r the mmm-udf service
=C2=A0 =C2=A0for the domain example.com. =C2=B6

Discover ("example.com", "mmm-udf") =3D=C2=A0
Next the fingerprint of th= e source UDF is obtained.=C2=A0


I was surprised that you went straigh= t to http without a DNS SRV lookup.=C2=A0 This is a Greenfield, and adding = that in seems like a good thing.

Okay, so section 6.2 includes text:
=C2=A0= =C2=A0The use of DNS Web Discovery permits=C2=A0
= =C2=A0 =C2=A0service providers to make full use of the
=C2=A0 =C2=A0load balancing and service description=C2=A0
=C2=A0 =C2=A0capabilities afforded by use of DNS SRV and
=C2=A0 =C2=A0TXT records in accordance with the=C2=A0<= div dir=3D"auto">=C2=A0 =C2=A0approach described in [RFC6763].

Maybe should mention this in sec= tion 1, or maybe just make the explanation less authoritive sounding 8-;=C2= =A0

Section 1.3 will nee= d a forward reference.
I really like section 3.2.=C2= =A0

ap= plication/pkix-keyinfo
I did not know this was a thi= ng... Ah
=C2=A0You are going to register it.

You have specified rfc3986 rath= er than 3987, so your URI are not internationalized.=C2=A0 Is there a reaso= n for that?

Can you adva= nce the use document without the rest of mmm?




--00000000000082dde105861d2292-- From nobody Mon Apr 22 09:58:35 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D261200A0; Mon, 22 Apr 2019 09:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5Mj4y57kp5z; Mon, 22 Apr 2019 09:58:24 -0700 (PDT) Received: from mail-ot1-f65.google.com (mail-ot1-f65.google.com [209.85.210.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8E99120091; Mon, 22 Apr 2019 09:58:23 -0700 (PDT) Received: by mail-ot1-f65.google.com with SMTP id s24so10153336otk.13; Mon, 22 Apr 2019 09:58:23 -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=NANW3Velgj3v0845qkySToXaLou64kAJSaZJYOaNpvE=; b=iKGKGQwp2QtDAp9Vtk6c824fvlBYC2TQYFy5WsbQqKZ5BBPThPKPmOwyIhHeuc2BTc CjMFXMaC+CroDdJy12xDW3ULqAw6tkmVvWlMcRaaRcnmKxkhzkOtbTi4YWWI0eZDiXsP oZ2ugF6k7mdSFVtcQs0H6FIPHjkVzeCiLntO26uEPXdUVrZKwwsnk/UHiCo5cK8eIKNE wM7WNkNVSBx1I/o8qQ1FGt3WX3lOVUj9nBiDhr3fhIisooDrLqhphXYo/yNyLGVS+D/2 OLFLkKLK1dpRBp2ndieXAw39uFIzM1RmIx/He06gh73ZQCguYrVd2Tivw0Fq19VK3nfn 6DaA== X-Gm-Message-State: APjAAAXvyxyOS6OT4G3qNeYmFc6QkJ7Qd85QuCh4r3NQYU4jx9tkedgY ji8d7NZDKwosZdBEEdoGXPy0VkSa4F6BHubmmqGcWtyW X-Google-Smtp-Source: APXvYqy3vY0P2gO0y864k5LORwVNrH15iMK2l+YAGe0vjuOGaZFl8Vd3pq4wJVQGfIRifdoBWthkZLUK8eOOQnep1sU= X-Received: by 2002:a9d:58c5:: with SMTP id s5mr11458716oth.361.1555952302512; Mon, 22 Apr 2019 09:58:22 -0700 (PDT) MIME-Version: 1.0 From: Phillip Hallam-Baker Date: Mon, 22 Apr 2019 12:58:11 -0400 Message-ID: To: secdispatch@ietf.org, saag@ietf.org Content-Type: multipart/alternative; boundary="000000000000475fbf05872160f6" Archived-At: Subject: [saag] The Mathematical Mesh X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2019 16:58:27 -0000 --000000000000475fbf05872160f6 Content-Type: text/plain; charset="UTF-8" Five years ago I started to look at the reasons that Internet users do not use end-to-end secure mail despite the fact that almost every email client in use supported S/MIME and OpenPGP had been available for decades. In answering that question, I quickly realized that we were trying to solve the problems we were interested in rather than the ones that the user actually cared about. And yes, users do really care about security but their security concerns are much broader than the ones raised on the cypherpunks mailing lists. They are concerned about the control that corporations might have over them much more than governments. They are concerned with the risk of losing the pictures of their kids at 5 years old to ransomware. Carl Ellison says that the user base of any security protocol halves for each click required to use it. This led me to ask, 'how can we reduce total user effort' and not just effort required for security. Today we ask the user to configure their email client twice, first to make use of email and again to make email secure (and then we require them to redo the second annually for S/MIME). The result of this approach is an infrastructure I call the Mathematical Mesh which I would like IETF participants to consider as a standards track effort, either in part or in whole. The goal of the Mesh is to make computers easier to use by making them more secure. This is easier than people might imagine. The key here is that every set of instructions that you write down and give to a human can be written as code and given to a suitably authorized computer system. The phrase suitably authorized is key here, often the reason manual intervention is required to configure systems requires is that certain system privileges are needed. Like BitCoin, the Mesh extends the traditional cryptographic repertoire. While all of the cryptographic techniques used in the Mesh are well established in the academic field, this is the first time anyone has (to my knowledge) proposed making use of them in an open standard. The Mesh is designed to make full use of the capabilities of modern computer systems: It is assumed that every user has access to a machine with at least the capability of a Raspberry Pi Zero for purposes of configuring an managing devices. Connection and use of constrained devices of Arduino Mega class and above is also supported by offloading certain security functions to a trusted gateway. I am posting this here to solicit opinions as to whether I should bring some or all of this work to the IETF or if I should take it to other forums. The drafts are available in plaintext or HTML format. Since some of the drafts make extensive use of mathematical notations, I recommend reading them in the HTML format. HTML: http://mathmesh.com/Documents/draft-hallambaker-mesh-architecture.html http://mathmesh.com/Documents/draft-hallambaker-mesh-udf.html http://mathmesh.com/Documents/draft-hallambaker-mesh-dare.html http://mathmesh.com/Documents/draft-hallambaker-mesh-schema.html http://mathmesh.com/Documents/draft-hallambaker-mesh-protocol.html http://mathmesh.com/Documents/draft-hallambaker-mesh-trust.html http://mathmesh.com/Documents/draft-hallambaker-mesh-cryptography.html Plaintext: https://datatracker.ietf.org/doc/draft-hallambaker-mesh-architecture/ https://datatracker.ietf.org/doc/draft-hallambaker-mesh-udf/ https://datatracker.ietf.org/doc/draft-hallambaker-mesh-dare/ https://datatracker.ietf.org/doc/draft-hallambaker-mesh-schema/ https://datatracker.ietf.org/doc/draft-hallambaker-mesh-protocol/ https://datatracker.ietf.org/doc/draft-hallambaker-mesh-trust/ https://datatracker.ietf.org/doc/draft-hallambaker-mesh-cryptography/ These drafts are not yet complete as the example material and schema documentation is still being revised. This will be addressed as the reference code passes the remaining unit tests for each functional unit. The principle adopted being that it is better to have no examples than incorrect ones. The following drafts are planned but not yet written: https://datatracker.ietf.org/doc/draft-hallambaker-mesh-constrained/ https://datatracker.ietf.org/doc/draft-hallambaker-mesh-quantum/ The reference code is open source and runs in C# under .net Core. It is currently tested only on the Windows platform but previous versions have run on OSX and Linux. https://github.com/hallambaker/Mathematical-Mesh The code system is also open source. These tools allowed me to design, implement and document a code base that is capable of performing significant portions of the functions of PKIX, S/MIME, Blockchain, SMTP, IMAP and TLS on my own in a little less than three years. https://github.com/hallambaker/PHB-Build-Tools --000000000000475fbf05872160f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= Five years ago I started to look at the reasons that Internet users do not = use end-to-end secure mail despite the fact that almost every email client = in use supported S/MIME and OpenPGP had been available for decades.

In answering that question, I = quickly realized that we were trying to solve the problems we were interest= ed in rather than the ones that the user actually cared about. And yes, use= rs do really care about security but their security concerns are much broad= er than the ones raised on the cypherpunks mailing lists. They are concerne= d about the control that corporations might have over them much more than g= overnments. They are concerned with the risk of losing the pictures of thei= r kids at 5 years old to ransomware.

Carl Ellison says that the user base of any security protocol h= alves for each click required to use it. This led me to ask, 'how can w= e reduce total user effort' and not just effort required for security. = Today we ask the user to configure their email client twice, first to make = use of email and again to make email secure (and then we require them to re= do the second annually for S/MIME).

The result of this approach is an infrastructure I call the Math= ematical Mesh which I would like IETF participants to consider as a standar= ds track effort, either in part or in whole.

The goal of the Mesh is to make computers easier to us= e by making them more secure. This is easier than people might imagine. The= key here is that every set of instructions that you write down and give to= a human can be written as code and given to a suitably authorized computer= system.

The phrase suita= bly authorized is key here, often the reason manual intervention=C2=A0is required to=C2=A0configure systems requires is = that certain system privileges are needed.

Like BitCoin, the Mesh extends the traditional cryptograp= hic repertoire. While all of the cryptographic techniques used in the Mesh = are well established in the academic field, this is the first time anyone h= as (to my knowledge) proposed making use of them in an open standard.
=

The Mesh is designed to make f= ull use of the capabilities of modern computer systems: It is assumed that = every user has access to a machine with at least the capability of a Raspbe= rry Pi Zero for purposes of configuring an managing devices. Connection and= use of constrained devices of Arduino Mega class and above is also support= ed by offloading certain security functions to a trusted gateway.

I am posting this here to solicit = opinions as to whether I should bring some or all of this work to the IETF = or if I should take it to other forums.

The drafts are available in plaintext or HTML format. Since = some of the drafts make extensive use of mathematical notations, I recommen= d reading them in the HTML format.

HTML:
http://mathmesh.com/Documents/draft-hallambaker-mesh-architecture= .html=C2=A0=C2=A0
http://mathmesh.com/Documents/draft-hallambaker-mesh-udf.html= =C2=A0
http://= mathmesh.com/Documents/draft-hallambaker-mesh-dare.html=C2=A0
http://mathmesh.com/Do= cuments/draft-hallambaker-mesh-schema.html=C2=A0=C2=A0
http://mathmesh.com/Documents/draft= -hallambaker-mesh-cryptography.html=C2=A0=C2=A0

Plaintext:
https://datatracker.ietf.org/doc/draft-ha= llambaker-mesh-architecture/=C2=A0
http= s://datatracker.ietf.org/doc/draft-hallambaker-mesh-udf/
https://datatracker.ietf.org/doc/draft-hallambaker-m= esh-dare/
https://datatracker.ie= tf.org/doc/draft-hallambaker-mesh-schema/
https://datatracker.ietf.org/doc/draft-hallambaker-mesh-protocol/
https://datatracker.ietf.org/doc/d= raft-hallambaker-mesh-trust/
https://datatracker.ietf.org/doc/draft-hallambaker-mesh-cryptography/

These drafts are not yet complete as the example material and schema do= cumentation is still being revised. This will be addressed as the reference= code passes the remaining unit tests for each functional unit. The princip= le adopted being that it is better to have no examples than incorrect ones.=

T= he following drafts are planned but not yet written:

https://datatracke= r.ietf.org/doc/draft-hallambaker-mesh-constrained/
https://datatracker.ietf.org/doc/draft-hallambaker-mes= h-quantum/

The reference code is open source and runs in C# under .= net Core. It is currently tested only on the Windows platform but previous = versions have run on OSX and Linux.

<= /div>
https://github.com/hallambaker/Mathematical-Mesh=C2= =A0=C2=A0

The code system is also open source. These tools allowed me to = design, implement and document a code base that is capable of performing si= gnificant portions of the functions of PKIX, S/MIME, Blockchain, SMTP, IMAP= and TLS on my own in a little less than three years.

https://github.com/hallambaker/PHB-Buil= d-Tools=C2=A0=C2=A0
=
--000000000000475fbf05872160f6-- From nobody Mon Apr 22 10:34:40 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7FA01200DF for ; Mon, 22 Apr 2019 10:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 PbHd8XPcrhbV for ; Mon, 22 Apr 2019 10:34:28 -0700 (PDT) Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3E03120113 for ; Mon, 22 Apr 2019 10:34:27 -0700 (PDT) Received: by mail-oi1-x233.google.com with SMTP id t81so9033418oig.10 for ; Mon, 22 Apr 2019 10:34:27 -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=saXjQWBHFGZpWyT6o8DxU6FtSo4gVf1HfChXtt8kFso=; b=U1arV25jaYod9kYEXSplA78hY0meV/akF5wY5Ar1fYCcurBzdqoqgUb5dJ7EmkSQQ3 t4ddMKys8KePWiyA2xOE1Lpkb6fwz5dsrQa/M8cM2vW2l03nrbiKT29KOjB3ZiquYIjm K3KecIp0IQpsC8XZw9R4bm98dIrtyYpop1Z2iwwvAMZASECIZMAZy9LpfGF3KTIcLHWM cY03ai0vo0CgsCagZ6O0I2CVSygcubqxoL+rzbUrP/lQ6elMOYRYR5rq2LPN+v/d6Hsm tW2WVq9e2SKPZi0Ll1hwKvcuXYk+xXzZ15WZM6ySxS55oFg+lFKbxuair7qgneTAzMuR gDCA== 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=saXjQWBHFGZpWyT6o8DxU6FtSo4gVf1HfChXtt8kFso=; b=C5Ca2i76hkAr/LzbO7V8inlCsVFXzdFkZEH+H/2+OPxt+B5l0I78oZlX2VfNLTm4MH dygMnTX/UQEoGa9q9tZGHJzovS/mJ1dEPMt1+SDwz5tqv0KgxvCxs7liXRVsxCU1H0Uh lgVo7FhAzMXRTEqqunN2y9r6LlEOTuYJMsVYRYQ0uRx7kP8ECJ+84oCUCg7GVXdJmlm3 Y7Jlrt7T1Urw9hq/ZaNsIG0Ep9sM98W7YFY7lYsyndyfrDdbR89kIUO6sx+9YQ3Fnnom XPXXrjLcez1f36QGuSh6AOjjbZf0AQ6T/HsZksCdxc7FPdYqP0hX+jWmxs9gV1jSNJbQ hyvA== X-Gm-Message-State: APjAAAVq4dCqhdz2BsW2TwpdNHAl+d0ZlnLwgU6lsG630wQuzG1iwlsj UNY1K6dzzFsicduLKIZ0NzbmmptTdTTysgdT4EPHLA== X-Google-Smtp-Source: APXvYqwRSyH6CosoZ7P9o3/1GVzxOSF3jUSPg3GhcNgI8Bt8ODl8P7qSnm0+FDK76aze2ePrKKf0Iv2L3tSkPawdgUI= X-Received: by 2002:aca:544b:: with SMTP id i72mr10114079oib.51.1555954466947; Mon, 22 Apr 2019 10:34:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Mon, 22 Apr 2019 13:34:06 -0400 Message-ID: To: Phillip Hallam-Baker Cc: secdispatch@ietf.org, IETF SAAG Content-Type: multipart/alternative; boundary="0000000000004a1e74058721e19e" Archived-At: Subject: Re: [saag] [Secdispatch] The Mathematical Mesh X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2019 17:34:32 -0000 --0000000000004a1e74058721e19e Content-Type: text/plain; charset="UTF-8" Hi Phil, Thanks for the note. The IETF typically works on specifications for interoperability between multiple implementations. Is there more than one party involved / interested in implementing? --Richard On Mon, Apr 22, 2019 at 12:58 PM Phillip Hallam-Baker wrote: > Five years ago I started to look at the reasons that Internet users do not > use end-to-end secure mail despite the fact that almost every email client > in use supported S/MIME and OpenPGP had been available for decades. > > In answering that question, I quickly realized that we were trying to > solve the problems we were interested in rather than the ones that the user > actually cared about. And yes, users do really care about security but > their security concerns are much broader than the ones raised on the > cypherpunks mailing lists. They are concerned about the control that > corporations might have over them much more than governments. They are > concerned with the risk of losing the pictures of their kids at 5 years old > to ransomware. > > Carl Ellison says that the user base of any security protocol halves for > each click required to use it. This led me to ask, 'how can we reduce total > user effort' and not just effort required for security. Today we ask the > user to configure their email client twice, first to make use of email and > again to make email secure (and then we require them to redo the second > annually for S/MIME). > > The result of this approach is an infrastructure I call the Mathematical > Mesh which I would like IETF participants to consider as a standards track > effort, either in part or in whole. > > The goal of the Mesh is to make computers easier to use by making them > more secure. This is easier than people might imagine. The key here is that > every set of instructions that you write down and give to a human can be > written as code and given to a suitably authorized computer system. > > The phrase suitably authorized is key here, often the reason manual > intervention is required to configure systems requires is that certain > system privileges are needed. > > Like BitCoin, the Mesh extends the traditional cryptographic repertoire. > While all of the cryptographic techniques used in the Mesh are well > established in the academic field, this is the first time anyone has (to my > knowledge) proposed making use of them in an open standard. > > The Mesh is designed to make full use of the capabilities of modern > computer systems: It is assumed that every user has access to a machine > with at least the capability of a Raspberry Pi Zero for purposes of > configuring an managing devices. Connection and use of constrained devices > of Arduino Mega class and above is also supported by offloading certain > security functions to a trusted gateway. > > I am posting this here to solicit opinions as to whether I should bring > some or all of this work to the IETF or if I should take it to other forums. > > The drafts are available in plaintext or HTML format. Since some of the > drafts make extensive use of mathematical notations, I recommend reading > them in the HTML format. > > HTML: > http://mathmesh.com/Documents/draft-hallambaker-mesh-architecture..html > > http://mathmesh.com/Documents/draft-hallambaker-mesh-udf.html > http://mathmesh.com/Documents/draft-hallambaker-mesh-dare.html > http://mathmesh.com/Documents/draft-hallambaker-mesh-schema.html > http://mathmesh.com/Documents/draft-hallambaker-mesh-protocol.html > http://mathmesh.com/Documents/draft-hallambaker-mesh-trust.html > > http://mathmesh.com/Documents/draft-hallambaker-mesh-cryptography.html > > Plaintext: > https://datatracker.ietf.org/doc/draft-hallambaker-mesh-architecture/ > https://datatracker.ietf.org/doc/draft-hallambaker-mesh-udf/ > https://datatracker.ietf.org/doc/draft-hallambaker-mesh-dare/ > https://datatracker.ietf.org/doc/draft-hallambaker-mesh-schema/ > https://datatracker.ietf.org/doc/draft-hallambaker-mesh-protocol/ > https://datatracker.ietf.org/doc/draft-hallambaker-mesh-trust/ > https://datatracker.ietf.org/doc/draft-hallambaker-mesh-cryptography/ > > These drafts are not yet complete as the example material and schema > documentation is still being revised. This will be addressed as the > reference code passes the remaining unit tests for each functional unit. > The principle adopted being that it is better to have no examples than > incorrect ones. > > The following drafts are planned but not yet written: > > https://datatracker.ietf.org/doc/draft-hallambaker-mesh-constrained/ > https://datatracker.ietf.org/doc/draft-hallambaker-mesh-quantum/ > > The reference code is open source and runs in C# under .net Core. It is > currently tested only on the Windows platform but previous versions have > run on OSX and Linux. > > https://github.com/hallambaker/Mathematical-Mesh > > The code system is also open source. These tools allowed me to design, > implement and document a code base that is capable of performing > significant portions of the functions of PKIX, S/MIME, Blockchain, SMTP, > IMAP and TLS on my own in a little less than three years. > > https://github.com/hallambaker/PHB-Build-Tools > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch > --0000000000004a1e74058721e19e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Phil,

Thanks for the note= .=C2=A0 The IETF typically works on specifications for interoperability bet= ween multiple implementations.=C2=A0 Is there more than one party involved = / interested in implementing?

--Richard
<= /div>
O= n Mon, Apr 22, 2019 at 12:58 PM Phillip Hallam-Baker <phill@hallambaker.com> wrote:
Five years ago I started to lo= ok at the reasons that Internet users do not use end-to-end secure mail des= pite the fact that almost every email client in use supported S/MIME and Op= enPGP had been available for decades.

In answering that question, I quickly realized that we were tr= ying to solve the problems we were interested in rather than the ones that = the user actually cared about. And yes, users do really care about security= but their security concerns are much broader than the ones raised on the c= ypherpunks mailing lists. They are concerned about the control that corpora= tions might have over them much more than governments. They are concerned w= ith the risk of losing the pictures of their kids at 5 years old to ransomw= are.

=
Carl Ellison says th= at the user base of any security protocol halves for each click required to= use it. This led me to ask, 'how can we reduce total user effort' = and not just effort required for security. Today we ask the user to configu= re their email client twice, first to make use of email and again to make e= mail secure (and then we require them to redo the second annually for S/MIM= E).

<= div class=3D"gmail_default" style=3D"font-size:small">The result of this ap= proach is an infrastructure I call the Mathematical Mesh which I would like= IETF participants to consider as a standards track effort, either in part = or in whole.
The goal of = the Mesh is to make computers easier to use by making them more secure. Thi= s is easier than people might imagine. The key here is that every set of in= structions that you write down and give to a human can be written as code a= nd given to a suitably authorized computer system.

The phrase suitably authorized is key here, often= the reason manual intervention=C2=A0is required to=C2=A0configure systems requires is = that certain system privileges are needed.

Like BitCoin, the Mesh extends the traditional cryptograp= hic repertoire. While all of the cryptographic techniques used in the Mesh = are well established in the academic field, this is the first time anyone h= as (to my knowledge) proposed making use of them in an open standard.
=

The Mesh is designed to make f= ull use of the capabilities of modern computer systems: It is assumed that = every user has access to a machine with at least the capability of a Raspbe= rry Pi Zero for purposes of configuring an managing devices. Connection and= use of constrained devices of Arduino Mega class and above is also support= ed by offloading certain security functions to a trusted gateway.

I am posting this here to solicit = opinions as to whether I should bring some or all of this work to the IETF = or if I should take it to other forums.

The drafts are available in plaintext or HTML format. Since = some of the drafts make extensive use of mathematical notations, I recommen= d reading them in the HTML format.

HTML:
http://mathmesh.com/Documents/draft-hallambaker= -mesh-architecture..html=C2=A0=C2=A0
http://mathmesh.com/Document= s/draft-hallambaker-mesh-udf.html=C2=A0
http://mathmesh.com/Document= s/draft-hallambaker-mesh-dare.html=C2=A0
http://mathmesh.com/Docum= ents/draft-hallambaker-mesh-schema.html=C2=A0=C2=A0
http://m= athmesh.com/Documents/draft-hallambaker-mesh-protocol.html=C2=A0=C2=A0<= br>
http://mathmesh.com/Documents/draft-hallambaker-mesh-trust.html
http://mathmesh.com/Documents/draft-hallambaker-mesh-cry= ptography.html=C2=A0=C2=A0

Plaintext:
https://datatracker.ietf.org/doc/draft-hall= ambaker-mesh-architecture/=C2=A0
https://datatracker.ietf.org/doc/draft-hallambaker-mesh-udf/
https://datatracke= r.ietf.org/doc/draft-hallambaker-mesh-dare/
https://datatracker.ietf.org/doc/draft-hallam= baker-mesh-schema/
https://datatracker.ietf.org/doc/draft-hallambaker-mesh-protocol/
https://datatracker.i= etf.org/doc/draft-hallambaker-mesh-trust/
https://datatracker.ietf.org/doc/draft-ha= llambaker-mesh-cryptography/

=
These drafts are not yet complete as the= example material and schema documentation is still being revised. This wil= l be addressed as the reference code passes the remaining unit tests for ea= ch functional unit. The principle adopted being that it is better to have n= o examples than incorrect ones.

The following drafts are planned but not yet = written:

https://datatracker.ietf.org/doc/draft-halla= mbaker-mesh-constrained/
https://datatracker.ietf.org/doc/draft-hallambaker-mesh-quantu= m/

The reference code is open source and runs in C# under .net Core. = It is currently tested only on the Windows platform but previous versions h= ave run on OSX and Linux.

https://github.com/hallambaker/Mathematical-Mes= h=C2=A0=C2=A0

The code system is also open source. These tools allowe= d me to design, implement and document a code base that is capable of perfo= rming significant portions of the functions of PKIX, S/MIME, Blockchain, SM= TP, IMAP and TLS on my own in a little less than three years.

https://githu= b.com/hallambaker/PHB-Build-Tools=C2=A0=C2=A0
_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch
--0000000000004a1e74058721e19e-- From nobody Mon Apr 22 11:27:23 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04F2D120132; Mon, 22 Apr 2019 11:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iS0G9X2AgFtq; Mon, 22 Apr 2019 11:27:21 -0700 (PDT) Received: from mail-oi1-f171.google.com (mail-oi1-f171.google.com [209.85.167.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF0F0120092; Mon, 22 Apr 2019 11:27:20 -0700 (PDT) Received: by mail-oi1-f171.google.com with SMTP id v84so9197190oif.4; Mon, 22 Apr 2019 11:27:20 -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=giuTtSn7aiziD3JLmH15ClqdXDHXNpqDqkHaC/CXDNs=; b=l3wXmeCZg0Yya4HWNmQxRFFJ+PNF5vFHgYXNp07pH4PgknCU9sBzlR1XFkw79nhBuK 4h+X+CZxFBxTyMmnxZf3jl39fs/y2dJPCd6ibHyrRStE4qT3rI2oi3b49fvepEULmxlp lucB9rp33P+0m3pQAA09FirBGTwETIyg9/8qV5/1K6rasq+s6YABvQ8xfRr6NSqTEdM6 0vJW0a3kI4iTJZz8HFPVRO6R3fxpmjLe8oaFTDFX+Kc/jIznKIXQW5CYnHMsy7ZWL7Nc 3nQlAmR9ZcBGgrV5J8AyGVbxP4WHGVkuwcNsOwQT9408uKENZSzYC16Yb0MEppxdWq9K L4Zw== X-Gm-Message-State: APjAAAWI7RS/ftkd8gZMfX3iYGwm+VVAuLceo89aFIzkZN97+sD2O8xZ aPSVgXT1mIQ1KMAEgYjn89b+9Bf8VFccnC1ZkFwGoRaW X-Google-Smtp-Source: APXvYqyIzQwNedxPpax33enU39mxqYWbF2+PijyXCntvXJK2QklwhX4buGrN5qlGWk6VEGzRkWTx0zWSEXi6mxU3o0o= X-Received: by 2002:aca:b8c4:: with SMTP id i187mr11153733oif.6.1555957639689; Mon, 22 Apr 2019 11:27:19 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Phillip Hallam-Baker Date: Mon, 22 Apr 2019 14:27:08 -0400 Message-ID: To: Richard Barnes Cc: secdispatch@ietf.org, IETF SAAG Content-Type: multipart/alternative; boundary="00000000000066390a0587229e91" Archived-At: Subject: Re: [saag] [Secdispatch] The Mathematical Mesh X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2019 18:27:22 -0000 --00000000000066390a0587229e91 Content-Type: text/plain; charset="UTF-8" At this stage, I am trying to get people to actually look at the documents before I start actively marketing this scheme. I am currently in the process of spinning up my own company. When I worked as a Principal Scientist for two major Internet concerns for a total of over 20 years, one of my main job functions was identifying interesting technologies. The Mesh makes use of a unique set of cryptographic capabilities. It is the first time to my knowledge that anyone has explored the potential of Torben Pedersen or Matt Blaze's work. If people would like this to be an open system based on non-proprietary standards, this is your chance. On Mon, Apr 22, 2019 at 1:34 PM Richard Barnes wrote: > Hi Phil, > > Thanks for the note. The IETF typically works on specifications for > interoperability between multiple implementations. Is there more than one > party involved / interested in implementing? > > --Richard > >> >> --00000000000066390a0587229e91 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
At this stage, I am trying to get people to actually look at = the documents before I start actively marketing this scheme.

I am currently in the process of spinni= ng up my own company. When I worked as a Principal Scientist for two major = Internet concerns for a total of over 20 years, one of my main job function= s was identifying interesting technologies.

The Mesh makes use of a unique set of cryptographic ca= pabilities. It is the first time to my knowledge that anyone has explored t= he potential of Torben Pedersen or Matt Blaze's work.

If people would like this to be an open = system based on non-proprietary standards, this is your chance.


On Mon, Apr 22, = 2019 at 1:34 PM Richard Barnes <rlb@ipv.sx> wrote:
Hi Phil,

Thanks for the note.=C2=A0 The IETF typically works o= n specifications for interoperability between multiple implementations.=C2= =A0 Is there more than one party involved / interested in implementing?

--Richard
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
--00000000000066390a0587229e91-- From nobody Mon Apr 22 12:03:22 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1D1120326; Mon, 22 Apr 2019 12:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 i8zgfuOTGLq7; Mon, 22 Apr 2019 12:03:12 -0700 (PDT) Received: from cichlid.maple.relay.mailchannels.net (cichlid.maple.relay.mailchannels.net [23.83.214.36]) (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 21DF61202CC; Mon, 22 Apr 2019 12:03:11 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 9B73D141317; Mon, 22 Apr 2019 19:03:10 +0000 (UTC) Received: from pdx1-sub0-mail-a9.g.dreamhost.com (100-96-12-146.trex.outbound.svc.cluster.local [100.96.12.146]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 2E038140B68; Mon, 22 Apr 2019 19:03:09 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a9.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Mon, 22 Apr 2019 19:03:10 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Keen-Abiding: 69dae8b3108e2287_1555959789771_2002372353 X-MC-Loop-Signature: 1555959789771:2258660722 X-MC-Ingress-Time: 1555959789771 Received: from pdx1-sub0-mail-a9.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a9.g.dreamhost.com (Postfix) with ESMTP id 21C7A7F7E5; Mon, 22 Apr 2019 12:03:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=OETIs7kBvfzi5y mg2E/S4Qn0UXY=; b=l0t6RBrbRZVmpMjqJznnv6Di4BdbkDFaN3eu3rgsLIhiO6 UOSwTO9dRNKWtROtPGQL6eWXjEASx94XswbGGsZy5Mp0liAhRag4pfeEnJEDxfkA DaBaoLFytfUP4j0UlEqDwbgeiCwnFqgZvI/bkw2uUMyxmI0lUPy7HtCB6ciag= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a9.g.dreamhost.com (Postfix) with ESMTPSA id 177B07F7D4; Mon, 22 Apr 2019 12:03:05 -0700 (PDT) Date: Mon, 22 Apr 2019 14:03:03 -0500 X-DH-BACKEND: pdx1-sub0-mail-a9 From: Nico Williams To: Phillip Hallam-Baker Cc: secdispatch@ietf.org, saag@ietf.org Message-ID: <20190422190302.GA3137@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrgeeigdduvdejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhenucevlhhushhtvghrufhiiigvpedt Archived-At: Subject: Re: [saag] The Mathematical Mesh X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2019 19:03:14 -0000 Is it fair to characterize this as something of a PGP trust mesh on steroids? If not, how does it differ? (Yes, I do see that your scheme has decentralized device management for individuals, which is a bit of a new thing and very welcome.) Nico -- From nobody Mon Apr 22 12:33:37 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 432D2120124; Mon, 22 Apr 2019 12:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75fwr7JsmECN; Mon, 22 Apr 2019 12:33:34 -0700 (PDT) Received: from mail-oi1-f175.google.com (mail-oi1-f175.google.com [209.85.167.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47B5D120123; Mon, 22 Apr 2019 12:33:34 -0700 (PDT) Received: by mail-oi1-f175.google.com with SMTP id v10so9363415oib.1; Mon, 22 Apr 2019 12:33:34 -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=vGnOJfZDvIOCpeXXnimpAv895YNN7/o1N5nVDiI/kBc=; b=sUnXM5uwPZzoTnrwpZl7xhWjai/Plirs1sdUEBnBpXTq5ExiEXfqgDAnxQoXUdFpHY Okn1vsjzBPgteUn1mOZV+uIiHNDm4NEk2Dc49o3LQST0Xie6bmJOTNdGHy5cDs+0ORrp lDaLho+3ViWkhuKDpDiR9iNoGxPyV7h112QuHpuZQWVPy9DHIKfVps1Vde2GH8ivgRZB 5m9s8r8jrUSv7LvBbXVCOtbrXWYrOvBxdEQYK3YLtjJ78t543ea8Dy/I7U05tQBxO7Pk YlrWgpepJD+czAdIGQ8Pe+XYw3YqhkpcFHn/sEA3dTK1UfzM1j3ndk9fSQNX10Dt9jmR AFlw== X-Gm-Message-State: APjAAAXGyXu48UHi1o8E81JOjiLflXFkdrOhDoBanD9E/jIDg3QBmu5D fZrU0QI6zgDRVAJtNotdhwW2/oIqcis/CsBLfmsk81Ig X-Google-Smtp-Source: APXvYqxOhXW8pq7cW8B+4/zwPwvXD1sGCsNyXXKRDAmr+DY9Zh3F1ypTj/DlSJdDvgZSkoDKad97yPtPhM+tEp0JUb8= X-Received: by 2002:aca:b8c4:: with SMTP id i187mr11351077oif.6.1555961613481; Mon, 22 Apr 2019 12:33:33 -0700 (PDT) MIME-Version: 1.0 References: <20190422190302.GA3137@localhost> In-Reply-To: <20190422190302.GA3137@localhost> From: Phillip Hallam-Baker Date: Mon, 22 Apr 2019 15:33:22 -0400 Message-ID: To: Nico Williams Cc: secdispatch@ietf.org, IETF SAAG Content-Type: multipart/alternative; boundary="000000000000417c1d0587238bad" Archived-At: Subject: Re: [saag] The Mathematical Mesh X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2019 19:33:36 -0000 --000000000000417c1d0587238bad Content-Type: text/plain; charset="UTF-8" On Mon, Apr 22, 2019 at 3:03 PM Nico Williams wrote: > Is it fair to characterize this as something of a PGP trust mesh on > steroids? If not, how does it differ? > > (Yes, I do see that your scheme has decentralized device management for > individuals, which is a bit of a new thing and very welcome.) The objective is to give users the power to control their own security environment. This includes but is not limited to the ability to make use of Web-of-Trust approaches or delegated trust, delegated distrust or a combination of all three which is actually the approach I think works best. The primary focus is enabling real users to manage public key pairs on their devices without being aware that they are doing it. Securely establishing a set of public key pairs on each device and providing a validation path to the user's personal axiom of trust is the main idea here. Because if we achieve that, we are 80% of the way to securing almost any communication pattern. Trust topology is something I think we should be opportunistic on and use every available option. For example: * We meet at an IETF and exchange our master profile fingerprint directly using the QR code exchange. * You meet Alice at another meeting and directly exchange credentials using the QR code exchange. * I add Alice to the GitHub repo for the project based on your recommendation. * I add my personal banker to my account based on an Extended Validation certificate authenticating his bank and an assertion issued by the bank credentialing him as a current employee. Right now, I am doing everything in JSON and the Mesh Assertion infrastructure. It is pretty obvious that some of this is SAML territory. But where should the boundary be and should we make use of the XML SAML binding or switch it to a JSON encoding? I don't know what the right decision is there or have time to think about it. I have only scratched the surface as far as applying the key co-generation and splitting techniques I use. We could use them to distribute TLS certificate key pairs as well. --000000000000417c1d0587238bad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Apr 22, 2019 at 3:03 PM Nico Williams <nico@cryptonector.com> wrote:
Is it fair to characterize this as something of a PGP trust mesh= on
steroids?=C2=A0 If not, how does it differ?

(Yes, I do see that your scheme has decentralized device management for
individuals, which is a bit of a new thing and very welcome.)
<= div>
T= he objective is to give users the power to control their own security envir= onment.=C2=A0=C2=A0

T= his includes but is not limited to the ability to make use of Web-of-Trust = approaches or delegated trust, delegated distrust or a combination of all t= hree which is actually the approach I think works best.


The primary focus is enabling real users to manage pub= lic key pairs on their devices without being aware that they are doing it. = Securely establishing a set of public key pairs on each device and providin= g a validation path to the user's personal axiom of trust is the main i= dea here. Because if we achieve that, we are 80% of the way to securing alm= ost any communication pattern.


Trust topology is something I thi= nk we should be opportunistic on and use every available option. For exampl= e:

* We meet at an = IETF and exchange our master profile fingerprint directly using the QR code= exchange.
* Yo= u meet Alice at another meeting and directly exchange credentials using the= QR code exchange.
* I add Alice to the GitHub repo for the project based on your recommen= dation.
* I add= my personal banker to my account based on an Extended Validation certifica= te authenticating his bank and an assertion issued by the bank credentialin= g him as a current employee.


Right = now, I am doing everything in JSON and the Mesh Assertion infrastructure. I= t is pretty obvious that some of this is SAML territory. But where should t= he boundary be and should we make use of the XML SAML binding or switch it = to a JSON encoding? I don't know what the right decision is there or ha= ve time to think about it.

I have only scratched the surface as far as applying the key co-generatio= n and splitting techniques I use. We could use them to distribute TLS certi= ficate key pairs as well.
--000000000000417c1d0587238bad-- From nobody Mon Apr 22 13:23:13 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85E351200C5 for ; Mon, 22 Apr 2019 13:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.646 X-Spam-Level: X-Spam-Status: No, score=-1.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLzKqqHx1CgI for ; Mon, 22 Apr 2019 13:22:57 -0700 (PDT) Received: from mail-ot1-f47.google.com (mail-ot1-f47.google.com [209.85.210.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FDB9120199 for ; Mon, 22 Apr 2019 13:22:57 -0700 (PDT) Received: by mail-ot1-f47.google.com with SMTP id t8so10738195otp.7 for ; Mon, 22 Apr 2019 13:22:57 -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=3Dfpu9A3mUsYaI1Dc0fEMSqLlGPQAifAQzNYuWYDZE0=; b=UMdBJFXDtqA6kYDDBldDvvJnFg3lx2ftqG8KxtlV4AFu3VBVfMgUL9SDJ1k5vV52X2 8bY/igWuu5WB39asR+oq9Uv3aL/Gn06HYgGi8AxA5gGbMAYSBUs/BEQLJNI0uGXO/X76 nOmgCYMm9KjwPThEgHzhjhXJi9rsbUwpbzcOoURkW+3L0kNiovEGMtgKigoEPqKWpILA Jp0pneGIC9i8uXlWP9NSZSzTraBoBbQWADdhpwsx6rfeATw7SVPZsJ+I3RcxRqlvFEm2 1mUAAOfa/xzf/Etbi+iZF4y1rxIlprst/BkyCWzx/Mwur8IU7o9FRcNGOdRgDHEbBjWX GYXA== X-Gm-Message-State: APjAAAV52lw9/t4XwxYCXIeutXLrmBDM5LDUuDRZsYy7fExhn6hiV5xb hXsEMxxrnxL2YGytS0VbpOYfMs9LFTie6SdGyFrutHkb X-Google-Smtp-Source: APXvYqzFm9lbLu3RweK/SalULeb6b+HXIgxzUzO2trxnd3/+VzSYy0Wd0qVAaU+dY4WAvIsETslFJ+/jAE9/lYWwb94= X-Received: by 2002:a9d:58c5:: with SMTP id s5mr12041201oth.361.1555964576018; Mon, 22 Apr 2019 13:22:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Phillip Hallam-Baker Date: Mon, 22 Apr 2019 16:22:45 -0400 Message-ID: To: Michael Richardson Cc: IETF SAAG Content-Type: multipart/alternative; boundary="000000000000d63a050587243b01" Archived-At: Subject: Re: [saag] draft-hallambaker-mesh-udf-02 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2019 20:23:00 -0000 --000000000000d63a050587243b01 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Apr 9, 2019 at 2:29 PM Michael Richardson wrote: > Phill, I am reading your UDF document with the idea that IoT devices on > constrained networks can send a reference to an IDevID rather than send t= he > IDevID in-band. This would apply to both DTLS and also to EDHOC and HIP > (such as for 802.15.9 keying). > If we went down that route, we might want to go full throttle and add in a code point for a verbatim public key rather than a hash of a public key. I have added that to the spec and removed it three times because I do not make use of it in the Mesh. Another capability I left out is the authenticated only Locator form. So the browser follows a link, gets back the result and compares the fingerprint before accepting it. That could be a useful capability for other applications. Again, I left out features that I did not have an immediate use for but I am mentioning them here to save people the bother of having to claim it in a patent application like has happened to so much of my work in the past. This was all discussed in the ni: uri work long ago. I was reading section 1.2, and it says: > The UDF EARL locator shown above is > resolved by first determining the Web > Service Endpoint for the mmm-udf service > for the domain example.com. =C2=B6 > > Discover ("example.com", "mmm-udf") =3D > https://example.com/.well-known/mmm-udf/ > Next the fingerprint of the source UDF is obtained. > > > I was surprised that you went straight to http without a DNS SRV lookup. > This is a Greenfield, and adding that in seems like a good thing. > That would be a mistake I made in drafting. I am very keen to use SRV/TXT as the service discovery mechanism throughout. Not least because it is one of the techniques I hope to rely on in the future to enable transport agility and to push security policy constraints into the DNS. > Okay, so section 6.2 includes text: > The use of DNS Web Discovery permits > service providers to make full use of the > load balancing and service description > capabilities afforded by use of DNS SRV and > TXT records in accordance with the > approach described in [RFC6763]. > > Maybe should mention this in section 1, or maybe just make the explanatio= n > less authoritive sounding 8-; > Ack, yes. I should put a red flag there saying use SRV/TXT style resolution (which is all that the referenced draft really does). Agh... just realized where this issue originates from. It is actually due to a bug in my RFC generator which means that references in examples were mishandled. The example is in a markdown fragment I am pulling in from the Word document... OK will get that fixed... Section 1.3 will need a forward reference. > I will add one. > I really like section 3.2. > Thanks! > application/pkix-keyinfo > I did not know this was a thing... Ah > You are going to register it. > > You have specified rfc3986 rather than 3987, so your URI are not > internationalized. Is there a reason for that? > Lack of confidence in my knowledge of the subject material and lack of time to get to a sufficient understanding. Since the path-abempty of the URI is constrained to be base32 encoded text, with punctuation (-/), the only place where there is scope for internationalization is authority, that is the DNS name. I have no objection to making it an ireg-name. But does that actually add value? If we are forming a QR code, we might as well just use the punycode. The bit I am unclear on is 1) how widely deployed IRI support is and 2) whether the applications simply treat URIs with an internationalized domain name in the desired fashion anyway. > Can you advance the use document without the rest of mmm? > Yes. I have presented the work as a single unit because this is what we told the PeP people that we wanted when they came to SECDispatch. But I am quite happy to go a-la-carte if people prefer. The UDF doc is probably the one that is most easily separated from the rest as it doesn't depend on any other part of the Mesh. It does depend on draft-hallambaker-web-service-discovery but that is actually just a profile of [RFC6763 ] and [RFC5785 ]. The other part that is (almost) standalone is DARE Container which is a way to achieve blockchain type functionality in a JSON-friendly format without the ideological baggage or assumptions that come from the crypto currency world. DARE Container depends on UDF but doesn't require any other part of the Mesh. Another possibility is that people like the technology I am applying but would prefer to look at extending PCKS#7/CMS and retrofitting these ideas to other legacy protocols. I think it best to develop the capabilities first and then look to how they might be retrofitted though. Conversion to ASN.1 would require a sponsor willing to fund the work. --000000000000d63a050587243b01 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Apr 9, 2019 at 2:29 PM Michael Richa= rdson <mcr+ietf@sandelman.ca<= /a>> wrote:


Another capability I left out is the authenticated only Locator form= . So the browser follows a link, gets back the result and compares the fing= erprint before accepting it. That could be a useful capability for other ap= plications.=C2=A0

Again, = I left out features that I did not have an immediate use for but I am menti= oning them here to save people the bother of having to claim it in a patent= application like has happened to so much of my work in the past. This was = all discussed in the ni: uri work long ago.


Discover ("example.com", "mmm-udf") =3D=C2=A0<= /div>
Next the fingerprint of the source UDF is obtained.=C2=A0
=


I= was surprised that you went straight to http without a DNS SRV lookup.=C2= =A0 This is a Greenfield, and adding that in seems like a good thing.
=

That would be a mistake I made in drafting.

I am very= keen to use SRV/TXT as the service discovery mechanism throughout. Not lea= st because it is one of the techniques I hope to rely on in the future to e= nable transport agility and to push security policy constraints into the DN= S.

=C2=A0
Okay, so section 6.2 includes text:
=C2=A0 =C2=A0The use of DNS Web Discovery permits=C2=A0
=C2=A0 =C2=A0service providers to make full use of the<= /div>
=C2=A0 =C2=A0load balancing and service description= =C2=A0
=C2=A0 =C2=A0capabilities afforded by use of = DNS SRV and
=C2=A0 =C2=A0TXT records in accordance w= ith the=C2=A0
=C2=A0 =C2=A0approach described in [RF= C6763].

Maybe should= mention this in section 1, or maybe just make the explanation less authori= tive sounding 8-;=C2=A0

Ack, yes. I should put a re= d flag there saying use SRV/TXT style resolution (which is all that the ref= erenced draft really does).=C2=A0

Agh... just realized where this issue ori= ginates from. It is actually due to a bug in my RFC generator which means t= hat references in examples were mishandled. The example is in a markdown fr= agment I am pulling in from the Word document... OK will get that fixed...<= /div>


Section 1.3 will need a= forward reference.

I will add one.=C2=A0
=C2=A0
I really like section 3.2.=C2=A0
=

Thanks!

=C2=A0
application/pkix-keyinfo
I did not know this = was a thing... Ah
=C2=A0You are going to register it= .

You have specified rfc= 3986 rather than 3987, so your URI are not internationalized.=C2=A0 Is there a reason f= or that?

Lack of confidence in my knowledge o= f the subject material and lack of time to get to a sufficient understandin= g.

Since the=C2=A0path-abempty=C2=A0of the URI is constrained = to be base32 encoded text, with punctuation (-/), the only place where ther= e is scope for internationalization is=C2=A0authority, that is the DNS name.

I have no objection to making it an=C2=A0ireg-name. But does that actually add= value?
=
If we are forming a QR code, we might as well= just use the punycode.

The bit I am unclear on is 1) how widely dep= loyed IRI support is and 2) whether the applications simply treat URIs with= an internationalized domain name in the desired fashion anyway.

<= /div>
=C2=A0
Can you advance the use = document without the rest of mmm?

Yes. I have pres= ented the work as a single unit because this is what we told the PeP people= that we wanted when they came to SECDispatch. But I am quite happy to go a= -la-carte if people prefer.

The UDF doc is probably the one that is most easily separated from the r= est as it doesn't depend on any other part of the Mesh. It does depend = on=C2=A0draft-hallambaker-web-service-discovery but that is actually just a= profile of=C2=A0[RFC6763] and=C2=A0[RFC5785].

T= he other part that is (almost) standalone is DARE Container which is a way = to achieve blockchain type functionality in a JSON-friendly format without = the ideological baggage or assumptions that come from the crypto currency w= orld. DARE Container depends on UDF but doesn't require any other part = of the Mesh.

A= nother possibility is that people like the technology I am applying but wou= ld prefer to look at extending PCKS#7/CMS and retrofitting these ideas to o= ther legacy protocols. I think it best to develop the capabilities first an= d then look to how they might be retrofitted though. Conversion to ASN.1 wo= uld require a sponsor willing to fund the work.=C2=A0=C2=A0
=
--000000000000d63a050587243b01-- From nobody Mon Apr 22 13:38:40 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A44341203AF; Mon, 22 Apr 2019 13:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 S95WiB6Nsmth; Mon, 22 Apr 2019 13:38:27 -0700 (PDT) Received: from orchid.birch.relay.mailchannels.net (orchid.birch.relay.mailchannels.net [23.83.209.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05E311203A3; Mon, 22 Apr 2019 13:38:24 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id E709F5E19C2; Mon, 22 Apr 2019 20:38:23 +0000 (UTC) Received: from pdx1-sub0-mail-a17.g.dreamhost.com (100-96-2-149.trex.outbound.svc.cluster.local [100.96.2.149]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 054285E17DD; Mon, 22 Apr 2019 20:38:22 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a17.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Mon, 22 Apr 2019 20:38:23 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Battle-Stretch: 3c1105ee7658ad00_1555965503764_1072370635 X-MC-Loop-Signature: 1555965503764:3972106718 X-MC-Ingress-Time: 1555965503763 Received: from pdx1-sub0-mail-a17.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a17.g.dreamhost.com (Postfix) with ESMTP id A42297F6CD; Mon, 22 Apr 2019 13:38:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=94TykgqELZq3nI B6AsLc5rQ+SOw=; b=b9kbsijjNZafTwo7uzO+NHKV9t+5pBxJCQmsueok+/6ysR 9eP5TrLk/bdcdwufYPhHR3MrcR8mVpIRnZHAN8uG+k1eWFuDJ7lN3gvAz1U13YcT VKnPx49mjzh2Mmt1izuPyHYPlc4x5/2RA+t0t5wOru3I9I0pG9FL0O1DK2VAY= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a17.g.dreamhost.com (Postfix) with ESMTPSA id 861F07F6EA; Mon, 22 Apr 2019 13:38:16 -0700 (PDT) Date: Mon, 22 Apr 2019 15:38:13 -0500 X-DH-BACKEND: pdx1-sub0-mail-a17 From: Nico Williams To: Phillip Hallam-Baker Cc: secdispatch@ietf.org, IETF SAAG Message-ID: <20190422203812.GB3137@localhost> References: <20190422190302.GA3137@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrgeeigddugeegucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhenucevlhhushhtvghrufhiiigvpedt Archived-At: Subject: Re: [saag] The Mathematical Mesh X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2019 20:38:30 -0000 On Mon, Apr 22, 2019 at 03:33:22PM -0400, Phillip Hallam-Baker wrote: > On Mon, Apr 22, 2019 at 3:03 PM Nico Williams wrote: > > Is it fair to characterize this as something of a PGP trust mesh on > > steroids? If not, how does it differ? > > > > (Yes, I do see that your scheme has decentralized device management for > > individuals, which is a bit of a new thing and very welcome.) > > The objective is to give users the power to control their own security > environment. > > This includes but is not limited to the ability to make use of Web-of-Trust > approaches or delegated trust, delegated distrust or a combination of all > three which is actually the approach I think works best. OK, so, all-of-the-above trust? But there's nothing new yet, besides hierarchical[0], and web-of-trust[1], TOFU, and things in between[2] right? Just a new way of doing all-of-the-above? This is not a critique. I think a simple characterization will help. "All of the above on steroids" seems fair. But I do feel that the device management part is separable, even though it's certainly critical for the UX. [0] E.g., PKI, DNSSEC, Kerberos. [1] E.g., PGP. [2] E.g., WebPKI, which isn't exactly hierarchical, and definitely isn't webby as to trust. > The primary focus is enabling real users to manage public key pairs on > their devices without being aware that they are doing it. Securely > establishing a set of public key pairs on each device and providing a > validation path to the user's personal axiom of trust is the main idea > here. Because if we achieve that, we are 80% of the way to securing almost > any communication pattern. Agreed. Vendors will (already do) gladly help you do this within their walled garden, natch. The result is... a bit lame. > Trust topology is something I think we should be opportunistic on and use > every available option. For example: Ah, "opportunistic". TOFU. Sure. > * We meet at an IETF and exchange our master profile fingerprint directly > using the QR code exchange. > * You meet Alice at another meeting and directly exchange credentials using > the QR code exchange. > * I add Alice to the GitHub repo for the project based on your > recommendation. > > * I add my personal banker to my account based on an Extended Validation > certificate authenticating his bank and an assertion issued by the bank > credentialing him as a current employee. OK, so WebPKI, PKI (if we had it, which, well, we do, since DNSSEC is a PKI). > Right now, I am doing everything in JSON and the Mesh Assertion > infrastructure. It is pretty obvious that some of this is SAML territory. > But where should the boundary be and should we make use of the XML SAML > binding or switch it to a JSON encoding? I don't know what the right > decision is there or have time to think about it. It's always tempting to start from scratch... But it's already been done via OAuth/JWT. Don't feel bad for not using SAML/XML. Just make the right choice. Nico -- From nobody Mon Apr 22 13:47:39 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 899501203BB for ; Mon, 22 Apr 2019 13:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yyx3FPdxQr3e for ; Mon, 22 Apr 2019 13:47:36 -0700 (PDT) Received: from mail-oi1-f180.google.com (mail-oi1-f180.google.com [209.85.167.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99B7C120128 for ; Mon, 22 Apr 2019 13:47:36 -0700 (PDT) Received: by mail-oi1-f180.google.com with SMTP id x188so9480955oia.13 for ; Mon, 22 Apr 2019 13:47:36 -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=ZO+r7iKhHuPb4WZjuW99KAISLMCWSYytA49dPcgsg0A=; b=DWYoAERTvRBDd+8Lu6r3o/qRUeFCHDBFQuOzr/0a/70m3UJVzud4IkKpe3V+AGfk2D /a+OO4vt8OG8Al3GVtrbEdC6gHg320I5LOrzWNQ8XJv2YK2sKkhrWQl5eGaQa5BPA4fI Kq3IepAun8k4Ie+q7edzFog6DAzKp1GDR0SDnfZplIJOKuqeiS6IVxlOeFcYyYwmAYtb FOcTNs9VfaJuDxdX4WYqMnw1yEC/73dK2M9bLc0ntoJoqbZOUqOnnUz8SFPfrLHW2am8 sWtLns9A7PDpn+VDDzb17NK85A5ApNYkKnfzmxa54vpLTmvhV2attXMRgI0CGFY2h5Dt BPpQ== X-Gm-Message-State: APjAAAVNH1P4zS611sLA6A4wW4JurJA+ZpUJq62wO6QRS+qS17QOqlJe lfe8QGV9l1XlBT1CnTqkSt8fp4pwNgwXJS02I0tRFo6O X-Google-Smtp-Source: APXvYqwwGJ+nJco8NjXVO6NqH1GviBToePn23tTPEHZgcj/BMwIgsMtslgCfOYKYM9sYzIvdlMeSkBk066e7Ekh7+KU= X-Received: by 2002:aca:5a89:: with SMTP id o131mr77788oib.17.1555966055767; Mon, 22 Apr 2019 13:47:35 -0700 (PDT) MIME-Version: 1.0 References: <20190326164951.GX4211@localhost> <20190326214816.GB4211@localhost> <1553679912618.8510@cs.auckland.ac.nz> <20190327151545.GG4211@localhost> <20190330153101.GT35679@kduck.mit.edu> <269bee5d-e225-3484-04ed-3e5de6c19081@cs.tcd.ie> In-Reply-To: <269bee5d-e225-3484-04ed-3e5de6c19081@cs.tcd.ie> From: Phillip Hallam-Baker Date: Mon, 22 Apr 2019 16:47:24 -0400 Message-ID: To: Stephen Farrell Cc: "saag@ietf.org" Content-Type: multipart/alternative; boundary="00000000000009676c05872494b7" Archived-At: Subject: Re: [saag] ASN.1 vs. DER Encoding X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2019 20:47:39 -0000 --00000000000009676c05872494b7 Content-Type: text/plain; charset="UTF-8" On Sun, Mar 31, 2019 at 7:36 AM Stephen Farrell wrote: > On 31/03/2019 08:39, Carsten Bormann wrote: > > There is no free lunch in this space. > > Oddly, there sort-of is... if one ignores the ~every-5-years > debate that the new-way (asn.1/der,asn.1/,xml+dtd,xml+ > schema,json,cbor...) is obviously the right answer to everything, > and just go eat your lunch... then that's nearly a free lunch:-) > > I never understood how so many people get so excited by this > topic myself. Seems to me programmers will always find a way > to do as well or badly as ever despite the differences in this > kind of tooling. (Training, experience and other kinds of > tools like more strict compiler options can make a difference.) > Only five? Seems like every six months. Yes, of course write a compiler to parse any data structure, especially IP packets. I can guarantee you that IPv6 packet exploits will be a recurring source of software vulnerabilities for decades into the future. I have written several ASN.1 encoders and decoders over the years. My take: 1) I never touch ASN.1 unless I am being paid to do so and in advance. Nor would I expect anyone else to do so. 2) ASN.1 is a very good idea in principle that is marred with some very unfortunate practice that render it worse than useless. 3) Having six encoding rules is a defect, not a strength. The point of standards is to remove choices that don't really matter. Having six incompatible encodings makes it matter. 4) The DER encoding rules are botched. They require use of nested length delimited fields for a start which is inherently insecure unless the receiver checks every inner structure to make sure that it is correctly nested inside the outer. 5) The botched DER encoding is even worse because the nested lengths is the use of nested variable length length specifiers. This means that the only efficient strategy for encoding ASN.1 is to fill the buffer in the REVERSE order starting with the last item. 6) Since there is no advantage of using ASN.1 over other choices and you will get three years of gripes and debates over schema peculiarities, the only use I can find for ASN.1 is for the small number of legacy applications that require it. The only one that I have not found to be unavoidable being PKIX which requires the worst-of-the-worst DER encoding. 7) To add insult to injury, the canonicalization that DER encoding purports to provide is of absolutely no value. If I am checking the signature of octet sequence X, absolutely harm should come from the possibility that there exist an octet sequence Y that has identical semantics which could have been signed instead. Yes, I can construct ludicrous scenarios in which that would be true but any system that relied on canonicalization is broken. 8) PKIX requires DER but does not provide a canonical form for a certificate. You cannot strip an X.509 certificate to its elements, put those elements into an X.500 directory and then reassemble the cert even if you want to because the extensions are specified as a list, not a set. Given that 1TB of SSD currently costs $125 and certificates are a few KB at most, this would be a very silly thing to want to try in any case even if there were any people still operating X.500 directories. --00000000000009676c05872494b7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Mar 31, 2019 at 7:36 AM Stephen Farrell <stephen.farrell@cs.tcd.ie> wro= te:
On 31/03/2019 08:39, Carsten Bormann wrote:
> There is no free lunch in this space.

Oddly, there sort-of is... if one ignores the ~every-5-years
debate that the new-way (asn.1/der,asn.1/<foo>,xml+dtd,xml+
schema,json,cbor...) is obviously the right answer to everything,
and just go eat your lunch... then that's nearly a free lunch:-)

I never understood how so many people get so excited by this
topic myself. Seems to me programmers will always find a way
to do as well or badly as ever despite the differences in this
kind of tooling. (Training, experience and other kinds of
tools like more strict compiler options can make a difference.)

= Only five? Seems like every six months.

Yes, of course write a compiler to parse any data structure,= especially IP packets. I can guarantee you that IPv6 packet exploits will = be a recurring source of software vulnerabilities for decades into the futu= re.=C2=A0

<= /div>

I have written several AS= N.1 encoders and decoders over the years. My take:

1) I never touch ASN.1 unless I am being paid to = do so and in advance. Nor would I expect anyone else to do so.

2) ASN.1 is a very good idea in princ= iple that is marred with some very unfortunate practice that render it wors= e than useless.

3) Having= six encoding rules is a defect, not a strength. The point of standards is = to remove choices that don't really matter. Having six incompatible enc= odings makes it matter.

4= ) The DER encoding rules are botched. They require use of nested length del= imited fields for a start which is inherently insecure unless the receiver = checks every inner structure to make sure that it is correctly nested insid= e the outer.=C2=A0

5) The= botched DER encoding is even worse because the nested lengths is the use o= f nested variable length length specifiers. This means that the only effici= ent strategy for encoding ASN.1 is to fill the buffer in the REVERSE order = starting with the last item.

6) Since there is no advantage of using ASN.1 over other choices and yo= u will get three years of gripes and debates over schema peculiarities, the= only use I can find for ASN.1 is for the small number of legacy applicatio= ns that require it. The only one that I have not found to be unavoidable be= ing PKIX which requires the worst-of-the-worst DER encoding.

7) To add insult to injury, the canonic= alization that DER encoding purports to provide is of absolutely no value. = If I am checking the signature of octet sequence X, absolutely harm should = come from the possibility that there exist an octet sequence Y that has ide= ntical semantics which could have been signed instead. Yes, I can construct= ludicrous scenarios in which that would be true but any system that relied= on canonicalization is broken.

8) PKIX requires DER but does not provide a canonical form for a cer= tificate. You cannot strip an X.509 certificate to its elements, put those = elements into an X.500 directory and then reassemble the cert even if you w= ant to because the extensions are specified as a list, not a set. Given tha= t 1TB of SSD currently costs $125 and certificates are a few KB at most, th= is would be a very silly thing to want to try in any case even if there wer= e any people still operating X.500 directories.

--00000000000009676c05872494b7-- From nobody Mon Apr 22 13:55:05 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 718751200C4 for ; Mon, 22 Apr 2019 13:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 OlxbhdKlGVEh for ; Mon, 22 Apr 2019 13:55:01 -0700 (PDT) Received: from orchid.birch.relay.mailchannels.net (orchid.birch.relay.mailchannels.net [23.83.209.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6083E120098 for ; Mon, 22 Apr 2019 13:55:01 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 468A56A16BE; Mon, 22 Apr 2019 20:55:00 +0000 (UTC) Received: from pdx1-sub0-mail-a17.g.dreamhost.com (100-96-12-146.trex.outbound.svc.cluster.local [100.96.12.146]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 50FF06A1792; Mon, 22 Apr 2019 20:54:59 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a17.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Mon, 22 Apr 2019 20:55:00 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Absorbed-Daffy: 13f71732417a750c_1555966500085_3263682997 X-MC-Loop-Signature: 1555966500085:3250606534 X-MC-Ingress-Time: 1555966500084 Received: from pdx1-sub0-mail-a17.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a17.g.dreamhost.com (Postfix) with ESMTP id 1C25B7F6FD; Mon, 22 Apr 2019 13:54:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=TUSY3VnQqXuQGf a/cIIFGTCkNbc=; b=j8N+h21dmmldmUkQywouhvdceLIF1yYGH/62YTWSKflSWS 6sCLMyI/X0GX1tupG/F/Y8I7scqR2HxdHioCeGX4+uFXlYYPjcwP2rIzhAqyNWj+ VMpakCi4YZP15VDQvEErGLoj9Piw9ygPBTUlTk+qi/bE7eIHjJ0t9B35x4ds0= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a17.g.dreamhost.com (Postfix) with ESMTPSA id 680F07F6E1; Mon, 22 Apr 2019 13:54:54 -0700 (PDT) Date: Mon, 22 Apr 2019 15:54:51 -0500 X-DH-BACKEND: pdx1-sub0-mail-a17 From: Nico Williams To: Phillip Hallam-Baker Cc: Michael Richardson , IETF SAAG Message-ID: <20190422205451.GC3137@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrgeeigddugeeiucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhenucevlhhushhtvghrufhiiigvpedt Archived-At: Subject: Re: [saag] draft-hallambaker-mesh-udf-02 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2019 20:55:04 -0000 On Mon, Apr 22, 2019 at 04:22:45PM -0400, Phillip Hallam-Baker wrote: > Another possibility is that people like the technology I am applying but > would prefer to look at extending PCKS#7/CMS and retrofitting these ideas > to other legacy protocols. I think it best to develop the capabilities > first and then look to how they might be retrofitted though. Conversion to > ASN.1 would require a sponsor willing to fund the work. It's all the same to me. However, I would on balance prefer that a) no new _encodings_ be created without b) a great deal of knowledge of what came before. I've been toying with this idea: - adapt the Heimdal ASN.1 compiler to output a JSON representation of the input module(s), - then use jq to transform that in various ways, - and lastly, use jq to generate codecs for the [transformed] module representations. Interesting transformations would be to, e.g., - apply code generation controls (e.g., "this INTEGER should be represented as a uint32_t in C, and that one as an in64_t"), - to add private structure fields for application use (for keeping state; this has been a significant driver for hand-coding of codecs). Why jq? Well, because it's a very pithy and accessible, functional, high-level programming language specifically designed for working with JSON data. I would prefer to do the whole thing in Haskell, but I'm not yet fluent in Haskell, and anyways, it's a less accessible language. Of course, too, there's the fact that I'm one of the maintainers of jq, which means I'm very familiar with it and productive in it. But I have a feeling that once I have a sample code generator for such a thing it will be very easy to create new backends out of it -- in fact, that would be a goal. Nico -- From nobody Mon Apr 22 14:15:01 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6412F1200EB for ; Mon, 22 Apr 2019 14:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 3_KTmTdzaquy for ; Mon, 22 Apr 2019 14:14:57 -0700 (PDT) Received: from firebrick.maple.relay.mailchannels.net (firebrick.maple.relay.mailchannels.net [23.83.214.59]) (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 C12AC1200B9 for ; Mon, 22 Apr 2019 14:14:56 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id EC94B125666; Mon, 22 Apr 2019 21:14:55 +0000 (UTC) Received: from pdx1-sub0-mail-a17.g.dreamhost.com (unknown [100.96.11.48]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 9EC8912593D; Mon, 22 Apr 2019 21:14:55 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a17.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Mon, 22 Apr 2019 21:14:55 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Grain-Ruddy: 2cb708214e0f241e_1555967695783_13166951 X-MC-Loop-Signature: 1555967695783:38432849 X-MC-Ingress-Time: 1555967695782 Received: from pdx1-sub0-mail-a17.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a17.g.dreamhost.com (Postfix) with ESMTP id 436527F6EC; Mon, 22 Apr 2019 14:14:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=JwWXPN5N+5llJy ghH/vsbSfvVwM=; b=Xe7MFreRc5OEhoDoKpf/sQJkFMPo5bHZh9ChuDEU4rcUfn TE5yHayvwaT2oeK0Bi8yG6RuHTsBOzXkSHL2JZ+FLx7omNTWi9XF3Iej/Xa0lAa7 hyS3u/+g2eDAlcTCPzLsOz0rRCsCH8qpN3etfsEj44wZxK8WL7uf42u9aQSQY= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a17.g.dreamhost.com (Postfix) with ESMTPSA id 83D377F6DA; Mon, 22 Apr 2019 14:14:52 -0700 (PDT) Date: Mon, 22 Apr 2019 16:14:50 -0500 X-DH-BACKEND: pdx1-sub0-mail-a17 From: Nico Williams To: Phillip Hallam-Baker Cc: Stephen Farrell , "saag@ietf.org" Message-ID: <20190422211449.GD3137@localhost> References: <20190326164951.GX4211@localhost> <20190326214816.GB4211@localhost> <1553679912618.8510@cs.auckland.ac.nz> <20190327151545.GG4211@localhost> <20190330153101.GT35679@kduck.mit.edu> <269bee5d-e225-3484-04ed-3e5de6c19081@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrgeeigddugeelucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhenucevlhhushhtvghrufhiiigvpedt Archived-At: Subject: Re: [saag] ASN.1 vs. DER Encoding X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2019 21:14:59 -0000 On Mon, Apr 22, 2019 at 04:47:24PM -0400, Phillip Hallam-Baker wrote: > 3) Having six encoding rules is a defect, not a strength. The point of > standards is to remove choices that don't really matter. Having six > incompatible encodings makes it matter. Six? I believe there's more. Ever heard of GSER? BER, DER, CER, PER, OER, XER, JER(?), GSER, and who knows what else. You could easily make encoding rules for ASN.1 out of XDR, NDR, CBOR, and many others. It's not a defect of the spec. It's a defect of history. In 1984 the ITU-T crowd loved themselfs some TLV encodings. The IETF crowd did not. Thus PER. But PER never took off because the specs weren't free at the time, and there was no tooling. TLVs at least looked easy. Meanwhile the IETF loved itself some text-based protocols -- lots of them. And while neither XML nor JSON came from the IETF, they found a home here. It turns out there's a great deal of demand for both, a) "textual", and b) binary encodings. And for (b), TLV kinda sucks, but it's what we've done for 30 years in many cases. We also have "bits on the wire" encodings. That's why we have all the ASN.1 encoding rules, XDR, NDR, XML, FastInfoSet, JSON, a whole bunch of "binary JSON" formats (including ones not brought to the IETF, such as PostgreSQL's JSONB, which is actually quite neat), and now all the *buffers rules (protocolbuffers, flatbuffers), and who knows what else I might be missing. Oh, and things like MIME, which in fact are encoding rules. And SSHv2, and TLS, and... And S-expressions, and Perl5 data dumper, and... Easy, safe prediction: we'll have more encoding rules soon. > 4) The DER encoding rules are botched. They require use of nested length > delimited fields for a start which is inherently insecure unless the > receiver checks every inner structure to make sure that it is correctly > nested inside the outer. Yes. The decisions made in both DER and CER make both of them difficult to use in actuality. The ITU-T could have made better choices for a canonical flavor of BER :( > 5) The botched DER encoding is even worse because the nested lengths is the > use of nested variable length length specifiers. This means that the only > efficient strategy for encoding ASN.1 is to fill the buffer in the REVERSE > order starting with the last item. It's worse: you have to realloc as you go, or build a rope, or do one pass to compute length and one to encode. DER is truly awful. > 7) To add insult to injury, the canonicalization that DER encoding purports > to provide is of absolutely no value. If I am checking the signature of > octet sequence X, absolutely harm should come from the possibility that > there exist an octet sequence Y that has identical semantics which could > have been signed instead. Yes, I can construct ludicrous scenarios in which > that would be true but any system that relied on canonicalization is broken. Agreed. And yet even now we find people who want a canonical JSON :( :( > 8) PKIX requires DER but does not provide a canonical form for a > certificate. You cannot strip an X.509 certificate to its elements, put > those elements into an X.500 directory and then reassemble the cert even if > you want to because the extensions are specified as a list, not a set. > Given that 1TB of SSD currently costs $125 and certificates are a few KB at > most, this would be a very silly thing to want to try in any case even if > there were any people still operating X.500 directories. One thing we've learned is that we *don't* want directories or white pages of any kind, not outside the corporate environment. And x.400/x.500 naming is an awful disaster. Another thing is that the specific form a certificate takes is not terribly interesting, but the names and issuer are. And even the issuer wouldn't be that interesting in a properly hierarchical PKI, but we never got one (except for DNSSEC). Nico -- From nobody Mon Apr 22 16:15:31 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 705B812003E for ; Mon, 22 Apr 2019 16:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXsqPxAF_gMW for ; Mon, 22 Apr 2019 16:15:27 -0700 (PDT) Received: from mail-oi1-f174.google.com (mail-oi1-f174.google.com [209.85.167.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 207DC1200B1 for ; Mon, 22 Apr 2019 16:15:27 -0700 (PDT) Received: by mail-oi1-f174.google.com with SMTP id j132so9806546oib.2 for ; Mon, 22 Apr 2019 16:15:27 -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=/uq/BuQtA/f4sBKEQW/kBCLapM8c+5Ier6Z+/sbRN0w=; b=fvWoUuzIt0OssNgVibsZP2R0sj4HLv52CQXc7z8zp9jw5f9409q6s3w9tZGgUGPG5N TbEpCjkODN1MVzx2epwHwjpWlL9nEaYiLWS92dqR8RXWY/U2Z0EoN/CJcJsE2l7Z7gm7 tsH+lf959tUqmHjNlY0hTXUz4H3fDcVkHK2DCcTq8MUif+JWwt7/jxZQI0FyC7mXHQ7P duaJMrg21IqmGXGtljf9IjtypCp6g9jGer5EuNBv6dCbLCE3gLGZ8Ual2QU3muxeuXLD RJHgpbWVJyZmC7l3b6+2xZT/06GTTzCJ2vv/tFGlSdvndr7On2u2KqeqEgP6NRd6m3MB I5iw== X-Gm-Message-State: APjAAAWmPvs3M5dnCeQIdd1AOca360yBMNjq0pJXvAAhzuMSL86R+FA6 rcgJpdIbV/Txvg61qWYU9TfgeIU0WIy3eLW4uZ1H9w== X-Google-Smtp-Source: APXvYqx4++FdgPeTPKHGCuFmR6aok8a374RCbFrdpUp2KE1TKrnMw382DcXHWuOcXxnuCaMh9RQ5SZ05MmdwRedfnpA= X-Received: by 2002:aca:5c55:: with SMTP id q82mr407823oib.95.1555974926116; Mon, 22 Apr 2019 16:15:26 -0700 (PDT) MIME-Version: 1.0 References: <20190326164951.GX4211@localhost> <20190326214816.GB4211@localhost> <1553679912618.8510@cs.auckland.ac.nz> <20190327151545.GG4211@localhost> <20190330153101.GT35679@kduck.mit.edu> <269bee5d-e225-3484-04ed-3e5de6c19081@cs.tcd.ie> <20190422211449.GD3137@localhost> In-Reply-To: <20190422211449.GD3137@localhost> From: Phillip Hallam-Baker Date: Mon, 22 Apr 2019 19:15:14 -0400 Message-ID: To: Nico Williams Cc: Stephen Farrell , "saag@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c02f9a058726a4a3" Archived-At: Subject: Re: [saag] ASN.1 vs. DER Encoding X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2019 23:15:30 -0000 --000000000000c02f9a058726a4a3 Content-Type: text/plain; charset="UTF-8" On Mon, Apr 22, 2019 at 5:15 PM Nico Williams wrote: > On Mon, Apr 22, 2019 at 04:47:24PM -0400, Phillip Hallam-Baker wrote: > > It turns out there's a great deal of demand for both, a) "textual", and > b) binary encodings. And for (b), TLV kinda sucks, but it's what we've > done for 30 years in many cases. We also have "bits on the wire" > encodings. > Hence the reason I decided to smoosh in binary encodings into JSON to create a superset so that one decoder can read either the JSON or the binary version. > That's why we have all the ASN.1 encoding rules, XDR, NDR, XML, > FastInfoSet, JSON, a whole bunch of "binary JSON" formats (including > ones not brought to the IETF, such as PostgreSQL's JSONB, which is > actually quite neat), and now all the *buffers rules (protocolbuffers, > flatbuffers), and who knows what else I might be missing. Oh, and > things like MIME, which in fact are encoding rules. And SSHv2, and TLS, > and... And S-expressions, and Perl5 data dumper, and... > > Easy, safe prediction: we'll have more encoding rules soon. > True. But here is the thing, I have a series of schema driven parsers that use essentially the same schema language to create parse r for ASN.1, XML, JSON, DNS Records, TLS, RFC822, RFC821 etc. I can throw out YANG, SML Schema, Relax etc. if needs be as well. The basic principle is to allow the basic encoding to be specified (e.g. integer) plus hints if needed in addition (e.g. 16bit, 32bit, signed, Little, Big endian, etc.) Yes. The decisions made in both DER and CER make both of them difficult > to use in actuality. The ITU-T could have made better choices for a > canonical flavor of BER :( > Had they chosen to require lists, sets, etc. to use the indefinite length encoding instead, the problems would have gone away. But nobody got round to implementing until after they made that choice. > > 5) The botched DER encoding is even worse because the nested lengths is > the > > use of nested variable length length specifiers. This means that the only > > efficient strategy for encoding ASN.1 is to fill the buffer in the > REVERSE > > order starting with the last item. > > It's worse: you have to realloc as you go, or build a rope, or do one > pass to compute length and one to encode. DER is truly awful. > I use the rope trick. One thing we've learned is that we *don't* want directories or white > pages of any kind, not outside the corporate environment. > I disagree. There is a role for a personal directory mapping local names to devices and users. It just looks nothing like the nonsense of X.500 and LDAP. If I say 'close garage door', it is implicit that it is the one connected to the house I am currently in. And I want my Apple, Google, Microsoft, DEC, etc. devices to all make use of the same local names in the same way which mean that they have to be MY local names from MY directory, not whatever sludge the AI heuristics driving Siri, Alexa, Hal, etc. try to infer. Basically, if we want to sell consumers hundreds of IoT devices then we have to either admit that all that stuff we sold to enterprise customers was unnecessary and they never needed it or decide it is needed and find some way to provide the same sorts of functionalities but without the make work that enterprise software sales require. --000000000000c02f9a058726a4a3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Apr 22, 2019 at 5:15 PM Nico Williams <nico@cryptonector.com> wrote:
On Mon, Apr 22, 2019 at 04:47:24PM -0400, Phillip Hallam-Baker w= rote:

It turns out there's a great deal of demand for both, a) "textual&= quot;, and
b) binary encodings.=C2=A0 And for (b), TLV kinda sucks, but it's what = we've
done for 30 years in many cases.=C2=A0 We also have "bits on the wire&= quot;
encodings.

Hence the reason I decided to smoosh in binary e= ncodings into JSON to create a superset so that one decoder can read either= the JSON or the binary version.

=C2=A0
That's why we have all the ASN.1 encoding rules, XDR, NDR, XML,
FastInfoSet, JSON, a whole bunch of "binary JSON" formats (includ= ing
ones not brought to the IETF, such as PostgreSQL's JSONB, which is
actually quite neat), and now all the *buffers rules (protocolbuffers,
flatbuffers), and who knows what else I might be missing.=C2=A0 Oh, and
things like MIME, which in fact are encoding rules.=C2=A0 And SSHv2, and TL= S,
and...=C2=A0 And S-expressions, and Perl5 data dumper, and...

Easy, safe prediction: we'll have more encoding rules soon.

True. But here is the thing, I have a series of schema driven parsers = that use essentially the same schema language to create parse r for ASN.1, = XML, JSON, DNS Records, TLS, RFC822, RFC821 etc. I can throw out YANG, SML = Schema, Relax etc. if needs be as well.

The basic principle is to allow the basic encoding to be spe= cified (e.g. integer) plus hints if needed in addition (e.g. 16bit, 32bit, = signed, Little, Big endian, etc.)

Yes.=C2=A0 The decisions made in both DER and CER make both of them difficu= lt
to use in actuality.=C2=A0 The ITU-T could have made better choices for a canonical flavor of BER :(

Had they chosen to require lis= ts, sets, etc. to use the indefinite length encoding instead, the problems = would have gone away. But nobody got round to implementing until after they= made that choice.

=C2=A0
> 5) The botched DER encoding is even worse because the nested lengths i= s the
> use of nested variable length length specifiers. This means that the o= nly
> efficient strategy for encoding ASN.1 is to fill the buffer in the REV= ERSE
> order starting with the last item.

It's worse: you have to realloc as you go, or build a rope, or do one pass to compute length and one to encode.=C2=A0 DER is truly awful.

I use the rope trick.

One thing we've learned is that we *don't* want directories = or white
pages of any kind, not outside the corporate environment.
<= div>
I disa= gree. There is a role for a personal directory mapping local names to devic= es and users. It just looks nothing like the nonsense of X.500 and LDAP.

If I say 'close garage = door', it is implicit that it is the one connected to the house I am cu= rrently in. And I want my Apple, Google, Microsoft, DEC, etc. devices to al= l make use of the same local names in the same way which mean that they hav= e to be MY local names from MY directory, not whatever sludge the AI heuris= tics driving Siri, Alexa, Hal, etc. try to infer.

Basically, if we want to sell consumers hundreds o= f IoT devices then we have to either admit that all that stuff we sold to e= nterprise customers was unnecessary and they never needed it or decide it i= s needed and find some way to provide the same sorts of functionalities but= without the make work that enterprise software sales require.
<= /div> --000000000000c02f9a058726a4a3-- From nobody Mon Apr 22 16:54:58 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD91120266 for ; Mon, 22 Apr 2019 16:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u84USPIUzCMs for ; Mon, 22 Apr 2019 16:54:54 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58286120224 for ; Mon, 22 Apr 2019 16:54:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 49BF9300ABD for ; Mon, 22 Apr 2019 19:36:36 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 4IJwa3TlQZ_8 for ; Mon, 22 Apr 2019 19:36:35 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 5AB66300471; Mon, 22 Apr 2019 19:36:35 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Russ Housley In-Reply-To: <20190422211449.GD3137@localhost> Date: Mon, 22 Apr 2019 19:54:52 -0400 Cc: IETF SAAG Content-Transfer-Encoding: quoted-printable Message-Id: <233FB845-976C-49CA-ADA6-C97035A2426F@vigilsec.com> References: <20190326164951.GX4211@localhost> <20190326214816.GB4211@localhost> <1553679912618.8510@cs.auckland.ac.nz> <20190327151545.GG4211@localhost> <20190330153101.GT35679@kduck.mit.edu> <269bee5d-e225-3484-04ed-3e5de6c19081@cs.tcd.ie> <20190422211449.GD3137@localhost> To: Nico Williams X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [saag] ASN.1 vs. DER Encoding X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2019 23:54:57 -0000 > And x.400/x.500 naming is an awful disaster. They are not the same. Once can completely avoid X.400 names, but the = X.500 one are used in certificates. I strongly encourage people to keep = it simple. The bits on the wire sitll get too complicated, but the code = can mostly do exact match processing. Russ From nobody Mon Apr 22 20:17:21 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB381200FE; Mon, 22 Apr 2019 20:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lc1qH7sEUO_J; Mon, 22 Apr 2019 20:17:19 -0700 (PDT) Received: from mail-ot1-f67.google.com (mail-ot1-f67.google.com [209.85.210.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D20C7120075; Mon, 22 Apr 2019 20:17:18 -0700 (PDT) Received: by mail-ot1-f67.google.com with SMTP id u15so11498993otq.10; Mon, 22 Apr 2019 20:17:18 -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=aEyqpNa6IORQoUWGrmIxPYHkXlkb/e8lfJhtd9Pg8WQ=; b=bEfGt3hHPAosCQ1sOEF5ylSPaQ2SX8Pz0Ta8yjTjtZYgkJFfoKwSWrbuiFqamNBx1v lkU2gXYHBuTKhQTN0aWYpBiHo0TIHsZIG7cpAnb8jJpErlcnRlZaHxLql8S/iII4OlNi iLwCiQjP2nD7Oe3QmULPNojzNX/MGcnjF9h00DMqHAoF4MfIahnJ5c7opMXX4wgHRqqE wnvLsvpGdM2rcrQCKBHT+2COo64ngLErHBAFwhBQFqJkadIxIb86hqPnQE82hRJzutUZ jsGCerU7Akw3zMeY1Vip99FV4qrlS64MWXFXsX8v+gwjg4Sb7p6RgGzW7fHw+SD+VfKv 9lsw== X-Gm-Message-State: APjAAAXHgLBibSwFqZTnncxADj60F6yVIb/1otkbpLTam7HE1x8QFf97 uUGqQE/mQ1ViALpH5H0nlSo7gIIfU0ReosF9b4KuFQ== X-Google-Smtp-Source: APXvYqz6jxPoEYZpulY3FlAhcjQV5dWWtsl7p1rXzhEoWL1l/YBZM11mkOHQ19BjeF1h+ChDXyk6H052Qo+CW6/XhPs= X-Received: by 2002:a9d:5a11:: with SMTP id v17mr14131893oth.150.1555989438056; Mon, 22 Apr 2019 20:17:18 -0700 (PDT) MIME-Version: 1.0 References: <20190422190302.GA3137@localhost> <20190422203812.GB3137@localhost> In-Reply-To: <20190422203812.GB3137@localhost> From: Phillip Hallam-Baker Date: Mon, 22 Apr 2019 23:17:07 -0400 Message-ID: To: Nico Williams Cc: secdispatch@ietf.org, IETF SAAG Content-Type: multipart/alternative; boundary="000000000000bacd7e05872a05cc" Archived-At: Subject: Re: [saag] The Mathematical Mesh X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 03:17:20 -0000 --000000000000bacd7e05872a05cc Content-Type: text/plain; charset="UTF-8" On Mon, Apr 22, 2019 at 4:38 PM Nico Williams wrote: > On Mon, Apr 22, 2019 at 03:33:22PM -0400, Phillip Hallam-Baker wrote: > > On Mon, Apr 22, 2019 at 3:03 PM Nico Williams > wrote: > > > Is it fair to characterize this as something of a PGP trust mesh on > > > steroids? If not, how does it differ? > > > > > > (Yes, I do see that your scheme has decentralized device management for > > > individuals, which is a bit of a new thing and very welcome.) > > > > The objective is to give users the power to control their own security > > environment. > > > > This includes but is not limited to the ability to make use of > Web-of-Trust > > approaches or delegated trust, delegated distrust or a combination of all > > three which is actually the approach I think works best. > > OK, so, all-of-the-above trust? > > But there's nothing new yet, besides hierarchical[0], and > web-of-trust[1], TOFU, and things in between[2] right? > > Just a new way of doing all-of-the-above? > > This is not a critique. I think a simple characterization will help. > > "All of the above on steroids" seems fair. > The objective here is to put the user in control and not try to force any particular model on them. One distinction I do feel very strongly on is that the configuration of trust relationships between devices belonging to the same entity is a completely different issue to the problem of trust between entities. Now I accept that there are some weasel words there, 'belonging' and 'entity'. But I still think there are important differences. Lets call the first problem the 'device-trust' problem and the second the 'inter-trust' problem Why I buy a new device I am adding it to my network which is in turn connected to the Internet. So the decision to trust the device is mine and mine alone. I am fairly certain I don't want to outsource the decision to grant trust. But I might under certain circumstances delegate the decision to distrust. So Symantec might tell me that my toaster is trying to kill me or the blender is trading crypto currencies and shut them down on my behalf. > But I do feel that the device management part is separable, even though > it's certainly critical for the UX. > I have no objections to an a-la-carte approach. The device management part is certainly the core here. The basic concept is that let us say that the device ships from the factory with a set of crypto keys burned in at the very chip level, cannot ever be altered or extracted. The protocols I have developed allow those keys to be used in conjunction with an overlay set of keys provided by the administration device. The net effect is that we get all the advantages of keys that are installed during manufacture and all the advantages of application generated keys. The combined key is secure against external attack if either of the key contributions is. The manufacturer key does not provide a backdoor capability unless the user generates a weak overlay key set. > > Right now, I am doing everything in JSON and the Mesh Assertion > > infrastructure. It is pretty obvious that some of this is SAML territory. > > But where should the boundary be and should we make use of the XML SAML > > binding or switch it to a JSON encoding? I don't know what the right > > decision is there or have time to think about it. > > It's always tempting to start from scratch... But it's already been > done via OAuth/JWT. Don't feel bad for not using SAML/XML. Just make > the right choice. > Naturally and this is one of the reasons I have steered clear of the inter-trust problem because it has been the part of the problem we like to beat on most. --000000000000bacd7e05872a05cc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Apr 22, 2019 at 4:38 PM Nico Williams <<= a href=3D"mailto:nico@cryptonector.com">nico@cryptonector.com> wrote= :
On Mon, Apr 22= , 2019 at 03:33:22PM -0400, Phillip Hallam-Baker wrote:
> On Mon, Apr 22, 2019 at 3:03 PM Nico Williams <nico@cryptonector.com> wrote:=
> > Is it fair to characterize this as something of a PGP trust mesh = on
> > steroids?=C2=A0 If not, how does it differ?
> >
> > (Yes, I do see that your scheme has decentralized device manageme= nt for
> > individuals, which is a bit of a new thing and very welcome.)
>
> The objective is to give users the power to control their own security=
> environment.
>
> This includes but is not limited to the ability to make use of Web-of-= Trust
> approaches or delegated trust, delegated distrust or a combination of = all
> three which is actually the approach I think works best.

OK, so, all-of-the-above trust?

But there's nothing new yet, besides hierarchical[0], and
web-of-trust[1], TOFU, and things in between[2] right?

Just a new way of doing all-of-the-above?

This is not a critique.=C2=A0 I think a simple characterization will help.<= br>
"All of the above on steroids" seems fair.
<= br>
The ob= jective here is to put the user in control and not try to force any particu= lar model on them. One distinction I do feel very strongly on is that the c= onfiguration of trust relationships between devices belonging to the same e= ntity is a completely different issue to the problem of trust between entit= ies.

=
Now I accept that th= ere are some weasel words there, 'belonging' and 'entity'. = But I still think there are important differences. Lets call the first prob= lem the 'device-trust'=C2=A0 problem and the second the 'inter-= trust' problem

Why I = buy a new device I am adding it to my network which is in turn connected to= the Internet.
=
So the dec= ision to trust the device is mine and mine alone. I am fairly certain I don= 't want to outsource the decision to grant trust. But I might under cer= tain circumstances delegate the decision to distrust. So Symantec might tel= l me that my toaster is trying to kill me or the blender is trading crypto = currencies and shut them down on my behalf.

=C2=A0
<= /div>
But I do feel that the device management part is separable, even though
it's certainly critical for the UX.

I have no objections to = an a-la-carte approach. The device management part is certainly the core he= re.

<= div class=3D"gmail_default" style=3D"font-size:small">The basic concept is = that let us say that the device ships from the factory with a set of crypto= keys burned in at the very chip level, cannot ever be altered or extracted= . The protocols I have developed allow those keys to be used in conjunction= with an overlay set of keys provided by the administration device.

The net effect is that we get = all the advantages of keys that are installed during manufacture and all th= e advantages of application generated keys. The combined key is secure agai= nst external attack if either of the key contributions is. The manufacturer= key does not provide a backdoor capability unless the user generates a wea= k overlay key set.

=C2=A0
> Right now, I am doing everything in J= SON and the Mesh Assertion
> infrastructure. It is pretty obvious that some of this is SAML territo= ry.
> But where should the boundary be and should we make use of the XML SAM= L
> binding or switch it to a JSON encoding? I don't know what the rig= ht
> decision is there or have time to think about it.

It's always tempting to start from scratch...=C2=A0 But it's alread= y been
done via OAuth/JWT.=C2=A0 Don't feel bad for not using SAML/XML.=C2=A0 = Just make
the right choice.

Naturally and this is one of the reasons I hav= e steered clear of the inter-trust problem because it has been the part of = the problem we like to beat on most.
--000000000000bacd7e05872a05cc-- From nobody Mon Apr 22 20:49:35 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 412CC1202E9; Mon, 22 Apr 2019 20:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 tw8k-3TCbxIJ; Mon, 22 Apr 2019 20:49:25 -0700 (PDT) Received: from eastern.maple.relay.mailchannels.net (eastern.maple.relay.mailchannels.net [23.83.214.55]) (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 08F081200C3; Mon, 22 Apr 2019 20:49:24 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 3476E3E4CA4; Tue, 23 Apr 2019 03:49:23 +0000 (UTC) Received: from pdx1-sub0-mail-a18.g.dreamhost.com (unknown [100.96.28.64]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id B33993E52FC; Tue, 23 Apr 2019 03:49:22 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a18.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Tue, 23 Apr 2019 03:49:23 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Scare-Juvenile: 17cc082d7fd0fc5f_1555991363017_3952312522 X-MC-Loop-Signature: 1555991363017:3502328466 X-MC-Ingress-Time: 1555991363016 Received: from pdx1-sub0-mail-a18.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a18.g.dreamhost.com (Postfix) with ESMTP id 5AAF382663; Mon, 22 Apr 2019 20:49:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=BrWw6SydtVwDsp hO7rCO2V/JhVc=; b=T7BDc1FhAYKnSa5kBxhHbGNaRw/v3+qTrdRwCYDr37PX2e 9rG1t3PCCQzP2mwBz0FwrhiL2FVB9dFh9U//YziPFUxHPzvCYiUTUf923Uqw/jMr Q1ItMQ01yevPgWmgXCH9TbEy2pMH2mxM8yMGaqOhY7q1A5uP6IDPD5GM60iMs= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a18.g.dreamhost.com (Postfix) with ESMTPSA id 15DAB82661; Mon, 22 Apr 2019 20:49:20 -0700 (PDT) Date: Mon, 22 Apr 2019 22:49:18 -0500 X-DH-BACKEND: pdx1-sub0-mail-a18 From: Nico Williams To: Phillip Hallam-Baker Cc: secdispatch@ietf.org, IETF SAAG Message-ID: <20190423034917.GF3137@localhost> References: <20190422190302.GA3137@localhost> <20190422203812.GB3137@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrgeejgdeihecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd Archived-At: Subject: Re: [saag] The Mathematical Mesh X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 03:49:27 -0000 On Mon, Apr 22, 2019 at 11:17:07PM -0400, Phillip Hallam-Baker wrote: > [...]. One distinction I do feel very strongly on is > that the configuration of trust relationships between devices belonging to > the same entity is a completely different issue to the problem of trust > between entities. So much so that it's even separable from the rest. When it comes to one's own devices (for some value of "own"), the introducer problem is trivially solved: one is the introduced, and assuming physical access, the rest is trivial. Indeed, smartphone vendors have even solved that -- within their walled gardens anyways. Getting an interoperable protocol for device key management widely implemented would be a real coup. > > But I do feel that the device management part is separable, even though > > it's certainly critical for the UX. > > I have no objections to an a-la-carte approach. The device management part > is certainly the core here. I'm not asking for it to be separated, just noting that it is separable. Again, I'm looking for a pithy description of the proposal. It's now "all ove the above as to trust" + "open device key management". Anything else? > > > Right now, I am doing everything in JSON and the Mesh Assertion > > > infrastructure. It is pretty obvious that some of this is SAML territory. > > > But where should the boundary be and should we make use of the XML SAML > > > binding or switch it to a JSON encoding? I don't know what the right > > > decision is there or have time to think about it. > > > > It's always tempting to start from scratch... But it's already been > > done via OAuth/JWT. Don't feel bad for not using SAML/XML. Just make > > the right choice. > > Naturally and this is one of the reasons I have steered clear of the > inter-trust problem because it has been the part of the problem we like to > beat on most. On the other hand, to follow an all-of-the-above path means interoperating with existing protocols wherever that helps. For example, there's no need for a replacement for PGP or S/MIME. What is needed is a way to simplify introductions and key exchange, to get it down to scanning a QR code and pressing a button. Ditto TOFU (though that's trickier, naturally). Ditto WebPKI. I've this idea that DANE stapling in TLS could be used to provide not just server authentication to clients, but also user authentication to servers, using client EE certificates with rfc822Name SANs and DANE to authenticate the domainname of a client certificate's rfc822Name SAN(s). (Many don't trust the DNSSEC root any more than others trust WebPKI, but for most users, anything is better than nothing.) The varying levels of trust will surely complicate the UI somewhat. At least power users will want to be able to see some indication of trust strength / how an introduction happened. Nico -- From nobody Mon Apr 22 20:54:30 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD1C2120150 for ; Mon, 22 Apr 2019 20:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 RHDs_Ci97a-m for ; Mon, 22 Apr 2019 20:54:27 -0700 (PDT) Received: from quail.birch.relay.mailchannels.net (quail.birch.relay.mailchannels.net [23.83.209.151]) (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 28BDC1200C3 for ; Mon, 22 Apr 2019 20:54:27 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 65542141BB8; Tue, 23 Apr 2019 03:54:26 +0000 (UTC) Received: from pdx1-sub0-mail-a18.g.dreamhost.com (100-96-7-81.trex.outbound.svc.cluster.local [100.96.7.81]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id D88BF141470; Tue, 23 Apr 2019 03:54:25 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a18.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Tue, 23 Apr 2019 03:54:26 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Befitting-Spot: 79166c69771a7838_1555991666243_4229458605 X-MC-Loop-Signature: 1555991666243:2085895440 X-MC-Ingress-Time: 1555991666243 Received: from pdx1-sub0-mail-a18.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a18.g.dreamhost.com (Postfix) with ESMTP id 83ED48265E; Mon, 22 Apr 2019 20:54:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=3IlgEPVBuwZi3G Sb80B1K6ciTOY=; b=dQdSjTitQYdWJdiXh9BYFE4j/K2Gftqu4CWcVLo2juGtJo cjTpnJ/2gw/lXi6zmrVWOSVczO3M284s1Rzt3+80r9OPjSRjnzQx0Qrb+6P18/Io wDWd09R3XpfHIdAtFmOI5xw77a1qkVAXXWWbgN/pkFqaSp9cv/jf+mo0j1mhw= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a18.g.dreamhost.com (Postfix) with ESMTPSA id 4E6C082661; Mon, 22 Apr 2019 20:54:18 -0700 (PDT) Date: Mon, 22 Apr 2019 22:54:16 -0500 X-DH-BACKEND: pdx1-sub0-mail-a18 From: Nico Williams To: Russ Housley Cc: IETF SAAG Message-ID: <20190423035415.GG3137@localhost> References: <20190326214816.GB4211@localhost> <1553679912618.8510@cs.auckland.ac.nz> <20190327151545.GG4211@localhost> <20190330153101.GT35679@kduck.mit.edu> <269bee5d-e225-3484-04ed-3e5de6c19081@cs.tcd.ie> <20190422211449.GD3137@localhost> <233FB845-976C-49CA-ADA6-C97035A2426F@vigilsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <233FB845-976C-49CA-ADA6-C97035A2426F@vigilsec.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrgeejgdeihecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd Archived-At: Subject: Re: [saag] ASN.1 vs. DER Encoding X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 03:54:29 -0000 On Mon, Apr 22, 2019 at 07:54:52PM -0400, Russ Housley wrote: > > And x.400/x.500 naming is an awful disaster. > > They are not the same. Once can completely avoid X.400 names, but the They are not, but they are similar, and similarly difficult to use. > X.500 one are used in certificates. I strongly encourage people to > keep it simple. The bits on the wire sitll get too complicated, but > the code can mostly do exact match processing. To keep it simple means to leave the subjectName empty and use dNSName and rfc822Name SANs instead wherever possible. Naming is more than half the battle. Internet-style naming of things won long, long ago. It's not just that users can handle domainnames and name@domainname syntax but not x.500, but that x.500 naming is fiendishly difficult to handle in code, or even in specs -- there's not even a lossless textual representation of x.500 names [RFC4514]! Nico -- From nobody Mon Apr 22 21:03:12 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C596E1201EE for ; Mon, 22 Apr 2019 21:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwNiXCSgNJlB for ; Mon, 22 Apr 2019 21:03:08 -0700 (PDT) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 738A6120150 for ; Mon, 22 Apr 2019 21:03:08 -0700 (PDT) Received: by mail-lf1-x12c.google.com with SMTP id k18so10547761lfj.13 for ; Mon, 22 Apr 2019 21:03:08 -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=BlBa9M3rPUpKTf+UnbsbbRG6UkeY66dtK2QAa/07jh8=; b=PFra33YRka4zwW9P2e6ddJOVFPtrhHpqt5IxIm2+VwET/F0cxglsSUaxDsioPp2IpM mNTafDNJWTF2GLNxlq/D78sVLOi5j/6mWLPcygs/hhT89G4KJ02wjbGyu6vYyJUMQGad uDFgMhjxocTW5gz7DvZVCgz74vGU3c6wJl+CA86RBFHv4CXURAdbIz21Kc+uUFvppZgZ glHizTeX4laLWeYcW5QIm9BiHlYJgugzz8rxMZe3iKT5Bp76Tl7XEZsF+b4M8r+7IxCd MxQTbp6L78U8bNc3LqOW7sXX1xFPtjsNF2Ez7hlbGjFfaF6XPsnq4cKQsnvwNm/HNK2X 4QEw== 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=BlBa9M3rPUpKTf+UnbsbbRG6UkeY66dtK2QAa/07jh8=; b=MxU+ce+ODUq1LOziuVRKB4/7Y5aBhaM61FUOwjDtDzOjPeXTuW3T2pH1joPO7TAQHc CXwEFqN2q3rm5kwkiN5iJco4y7r0FqTPebUuoD+k5xDv0BRF32xzhnTiwblsz3YHQ25C mnrgErgsUTF0XPEEfvn1gP36XA0WzGOGT086enkA9a6vK8dJxloe90njlgHEYPZ64ZGW zv1l1ehoESzI1rGsMBJOMepXCK8M3I89whi/S/byI0wgHkBW+Jlb9C+2FX/j+gNQv2mi diFgZhaG+P5ToAtgWpuJgeGiQqTs6bCbCBfulmifMsk7c43XLMxk3BoLq2brPLixEy66 0G3g== X-Gm-Message-State: APjAAAX45KTgrZICoeLY27WiSMRoVqQzq7XS4irHEvBUBOdd5WmJGaXd 4AUqDREqDvVVxq9Yg2jWIriZYoURq3e4FCKNguOs+Q== X-Google-Smtp-Source: APXvYqx9etOhV4w66UTs3B0mJ1N+yseOiQtiqBM+g2KQijKylzn7QLvctMbZCHgdDIqKtQn+g5l5W3qWbveCssbCRKc= X-Received: by 2002:ac2:5326:: with SMTP id f6mr12163307lfh.100.1555992186429; Mon, 22 Apr 2019 21:03:06 -0700 (PDT) MIME-Version: 1.0 References: <20190326214816.GB4211@localhost> <1553679912618.8510@cs.auckland.ac.nz> <20190327151545.GG4211@localhost> <20190330153101.GT35679@kduck.mit.edu> <269bee5d-e225-3484-04ed-3e5de6c19081@cs.tcd.ie> <20190422211449.GD3137@localhost> <233FB845-976C-49CA-ADA6-C97035A2426F@vigilsec.com> <20190423035415.GG3137@localhost> In-Reply-To: <20190423035415.GG3137@localhost> From: Watson Ladd Date: Mon, 22 Apr 2019 21:02:54 -0700 Message-ID: To: Nico Williams Cc: Russ Housley , IETF SAAG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [saag] ASN.1 vs. DER Encoding X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 04:03:11 -0000 On Mon, Apr 22, 2019 at 8:54 PM Nico Williams wrote: > > On Mon, Apr 22, 2019 at 07:54:52PM -0400, Russ Housley wrote: > > > And x.400/x.500 naming is an awful disaster. > > > > They are not the same. Once can completely avoid X.400 names, but the > > They are not, but they are similar, and similarly difficult to use. > > > X.500 one are used in certificates. I strongly encourage people to > > keep it simple. The bits on the wire sitll get too complicated, but > > the code can mostly do exact match processing. > > To keep it simple means to leave the subjectName empty and use dNSName > and rfc822Name SANs instead wherever possible. > > Naming is more than half the battle. Internet-style naming of things > won long, long ago. It's not just that users can handle domainnames and > name@domainname syntax but not x.500, but that x.500 naming is > fiendishly difficult to handle in code, or even in specs -- there's not > even a lossless textual representation of x.500 names [RFC4514]! Let us not forget the valiant battle to enforce the requirements that CAs know that Bremerhaven is in Bremen and not in Niedersachsen. I await the discovery that a small company in Baarle-Hertzog is actually three feet across the border, with dire consequences for the web PKI. (If the border moves and you don't, does the certificate need revocation? Or what about countries being renamed?) > > Nico > -- > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Mon Apr 22 21:29:41 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82A6B1200D7; Mon, 22 Apr 2019 21:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 G9zn8dWodCXo; Mon, 22 Apr 2019 21:29:37 -0700 (PDT) Received: from orchid.birch.relay.mailchannels.net (orchid.birch.relay.mailchannels.net [23.83.209.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 353D8120021; Mon, 22 Apr 2019 21:29:37 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 501A612570E; Tue, 23 Apr 2019 04:29:36 +0000 (UTC) Received: from pdx1-sub0-mail-a18.g.dreamhost.com (unknown [100.96.20.60]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 05262125299; Tue, 23 Apr 2019 04:29:36 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a18.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Tue, 23 Apr 2019 04:29:36 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Suffer-Grain: 2473b2da4b923d79_1555993776158_2600418844 X-MC-Loop-Signature: 1555993776158:2271316949 X-MC-Ingress-Time: 1555993776158 Received: from pdx1-sub0-mail-a18.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a18.g.dreamhost.com (Postfix) with ESMTP id BA73C8266D; Mon, 22 Apr 2019 21:29:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=X6qGsmU0sltQY9 7HudLFbMxB87Y=; b=Ay7woIW5hiPREZh7j3bn/2kNb8uebQpMO9rBMk/RKuLWIN sWMRlyEmKIFJ+kOlPVtbaZOawuDwlcnmK+TgpetwteJOJroCP7uJrWD9zoHSCwp8 UiklHiixr8TRhAir5/WqR5gWOMNpVf9cmg6WgF0HHFgb1XyzUFYj8oaFeeUfw= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a18.g.dreamhost.com (Postfix) with ESMTPSA id C590A8266B; Mon, 22 Apr 2019 21:29:34 -0700 (PDT) Date: Mon, 22 Apr 2019 23:29:32 -0500 X-DH-BACKEND: pdx1-sub0-mail-a18 From: Nico Williams To: Phillip Hallam-Baker Cc: secdispatch@ietf.org, IETF SAAG Message-ID: <20190423042931.GH3137@localhost> References: <20190422190302.GA3137@localhost> <20190422203812.GB3137@localhost> <20190423034917.GF3137@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190423034917.GF3137@localhost> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrgeejgdejfecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd Archived-At: Subject: Re: [saag] The Mathematical Mesh X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 04:29:39 -0000 On Mon, Apr 22, 2019 at 10:49:18PM -0500, Nico Williams wrote: > I've this idea that DANE stapling in TLS could be used to provide not > just server authentication to clients, but also user authentication to > servers, using client EE certificates with rfc822Name SANs and DANE to > authenticate the domainname of a client certificate's rfc822Name SAN(s). Ugh, I meant that DANE would authenticate the client cert's issuer, identified by the domainname of the rfc822Name SAN. From nobody Mon Apr 22 22:08:25 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70AAE120147 for ; Mon, 22 Apr 2019 22:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.645 X-Spam-Level: X-Spam-Status: No, score=-1.645 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j14s6M50aR1z for ; Mon, 22 Apr 2019 22:08:22 -0700 (PDT) Received: from mail-ot1-f54.google.com (mail-ot1-f54.google.com [209.85.210.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 958581200CD for ; Mon, 22 Apr 2019 22:08:22 -0700 (PDT) Received: by mail-ot1-f54.google.com with SMTP id f23so2532219otl.9 for ; Mon, 22 Apr 2019 22:08:22 -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=Z7QRymurBLPeNLQuLe/rVd9Y63W0inUBRlImAPm4xKI=; b=SzfLMAQxBgqVDRmY5MLMvXewGprbz5YpgnoRph1kO+2Wy+Rj7VlpO7cH4wp1BayqcX n1nSdAGTQivgnzxLRlxm5T9lysN2NCrmo+utg/T0ihd+oFbXJ7yYdEKyJLn6lBxV36Xk Ndc+iQpCWXyKG210USpofh76PGhL9E41taytajvtRbdxsBGkMXmNXYRKyHTn6ZbPu+8m ob7dGTSTPNaPrdxOK9a4ry3kaRYTqELfZqXLgN5wJ3r2u3rSom16x1ElGrNudB9YkVuS krUNIorq26dDuqywezJY0Xlua5+f4QAC+lZC2KU+M6U+q4YoKbXg6pTKSAJZyoOys8Tg bC/w== X-Gm-Message-State: APjAAAW7jw5vXUKCg8gtqgiKkvIg/uULf5jeYSnBc8ZCgs+jc4rCWynU mFT2s0mWYDMdhqWMXn8zQVBPP5NDSU7KeI55fHg= X-Google-Smtp-Source: APXvYqw13QdMj976g5X87XIa5oH0DWhOwmHa4Js5Jd8OYkGWaFyDmkWoFgNNUHfkVyrRCyvfmjRhEpU1qnlFiG5A09k= X-Received: by 2002:a9d:58c5:: with SMTP id s5mr13136931oth.361.1555996101795; Mon, 22 Apr 2019 22:08:21 -0700 (PDT) MIME-Version: 1.0 References: <20190326214816.GB4211@localhost> <1553679912618.8510@cs.auckland.ac.nz> <20190327151545.GG4211@localhost> <20190330153101.GT35679@kduck.mit.edu> <269bee5d-e225-3484-04ed-3e5de6c19081@cs.tcd.ie> <20190422211449.GD3137@localhost> <233FB845-976C-49CA-ADA6-C97035A2426F@vigilsec.com> <20190423035415.GG3137@localhost> In-Reply-To: From: Phillip Hallam-Baker Date: Tue, 23 Apr 2019 01:08:11 -0400 Message-ID: To: Watson Ladd Cc: Nico Williams , IETF SAAG Content-Type: multipart/alternative; boundary="000000000000eb67dc05872b92b5" Archived-At: Subject: Re: [saag] ASN.1 vs. DER Encoding X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 05:08:25 -0000 --000000000000eb67dc05872b92b5 Content-Type: text/plain; charset="UTF-8" On Tue, Apr 23, 2019 at 12:03 AM Watson Ladd wrote: > On Mon, Apr 22, 2019 at 8:54 PM Nico Williams > wrote: > > > > On Mon, Apr 22, 2019 at 07:54:52PM -0400, Russ Housley wrote: > > > > And x.400/x.500 naming is an awful disaster. > > > > > > They are not the same. Once can completely avoid X.400 names, but the > > > > They are not, but they are similar, and similarly difficult to use. > > > > > X.500 one are used in certificates. I strongly encourage people to > > > keep it simple. The bits on the wire sitll get too complicated, but > > > the code can mostly do exact match processing. > > > > To keep it simple means to leave the subjectName empty and use dNSName > > and rfc822Name SANs instead wherever possible. > > > > Naming is more than half the battle. Internet-style naming of things > > won long, long ago. It's not just that users can handle domainnames and > > name@domainname syntax but not x.500, but that x.500 naming is > > fiendishly difficult to handle in code, or even in specs -- there's not > > even a lossless textual representation of x.500 names [RFC4514]! > > Let us not forget the valiant battle to enforce the requirements that > CAs know that Bremerhaven is in Bremen and not in Niedersachsen. I > await the discovery that a small company in Baarle-Hertzog is actually > three feet across the border, with dire consequences for the web PKI. > (If the border moves and you don't, does the certificate need > revocation? Or what about countries being renamed?) > The only circumstance in which geography is usually significant in the WebPKI is when the certificate is EV or OV which are supposed to provide a degree of accountability. If you register a business in Germany, or for that matter you merely purport to hold said registration, you are accepting a certain degree of accountability under German law. If you are using a DV certificate and selling fraudulent goods, you may have customers in 100 different countries, none of which consider you to be their problem in particular. If you are using an EV certificate and it says Germany, well we certainly have a nexus in that particular country and their police are more inclined to investigate the fraud and hold the perpetrators accountable if possible. The original design brief for the WebPKI was limited to making online commerce no less safe than bricks and mortar stores. --000000000000eb67dc05872b92b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Apr 23, 2019 at 12:03 AM Watson Ladd <watsonbladd@gmail.com> wrote:=
On Mon, Apr 22,= 2019 at 8:54 PM Nico Williams <nico@cryptonector.com> wrote:
>
> On Mon, Apr 22, 2019 at 07:54:52PM -0400, Russ Housley wrote:
> > > And x.400/x.500 naming is an awful disaster.
> >
> > They are not the same.=C2=A0 Once can completely avoid X.400 name= s, but the
>
> They are not, but they are similar, and similarly difficult to use. >
> > X.500 one are used in certificates.=C2=A0 I strongly encourage pe= ople to
> > keep it simple.=C2=A0 The bits on the wire sitll get too complica= ted, but
> > the code can mostly do exact match processing.
>
> To keep it simple means to leave the subjectName empty and use dNSName=
> and rfc822Name SANs instead wherever possible.
>
> Naming is more than half the battle.=C2=A0 Internet-style naming of th= ings
> won long, long ago.=C2=A0 It's not just that users can handle doma= innames and
> name@domainname syntax but not x.500, but that x.500 naming is
> fiendishly difficult to handle in code, or even in specs -- there'= s not
> even a lossless textual representation of x.500 names [RFC4514]!

Let us not forget the valiant battle to enforce the requirements that
CAs know that Bremerhaven is in Bremen and not in Niedersachsen. I
await the discovery that a small company in Baarle-Hertzog is actually
three feet across the border, with dire consequences for the web PKI.
(If the border moves and you don't, does the certificate need
revocation? Or what about countries being renamed?)
The only cir= cumstance in which geography is usually significant in the WebPKI is when t= he certificate is EV or OV which are supposed to provide a degree of accoun= tability.

<= /div>
If you register= a business in Germany, or for that matter you merely purport to hold said = registration, you are accepting a certain degree of accountability under Ge= rman law.=C2=A0

If you ar= e using a DV certificate and selling fraudulent goods, you may have custome= rs in 100 different countries, none of which consider you to be their probl= em in particular.

If you = are using an EV certificate and it says Germany, well we certainly have a n= exus in that particular country and their police are more inclined to inves= tigate the fraud and hold the perpetrators accountable if possible.

The original design brief for = the WebPKI was limited to making online commerce no less safe than bricks a= nd mortar stores.
--000000000000eb67dc05872b92b5-- From nobody Tue Apr 23 05:16:43 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36855120140 for ; Tue, 23 Apr 2019 05:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OV59Pgqx0kcu for ; Tue, 23 Apr 2019 05:16:39 -0700 (PDT) Received: from mail-yw1-xc33.google.com (mail-yw1-xc33.google.com [IPv6:2607:f8b0:4864:20::c33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE42D1200F4 for ; Tue, 23 Apr 2019 05:16:36 -0700 (PDT) Received: by mail-yw1-xc33.google.com with SMTP id i66so1479080ywe.5 for ; Tue, 23 Apr 2019 05:16:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ABVFw89Elv3WudEC/XI6Fq/nBOWRAPNx8FGz4fzi3Ew=; b=EueJulQNvkRU8XqlR4kMgCByMln/zmlehQVp1/AnRzz55thtOvjit/iXyGW5Yrsig0 IkP8XR8T1+fhbYKDV6UTm2/RofPhXvNwomPNlpFTioas4I1SDNzZ8SD9+ntFj0bkB5tv gZBuvP5jUo5m6XIdA3ibLZE7b93P0It2aYdp1IlrHTT2McyRWq7/zfP6V2CgYrE326GU RxStdX0sgixAZkquBkY2oObPtIU/gBdUM6qpjzoQmsgiV56wOdawxGXmon0D5A7xTeNu c+5oESkQnjxYAs61gQW8AYkKOlFD6KZLmcUhmYgAQIxiJ7tHLCiyK8pgPbEAtIA07tFO kdyw== 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=ABVFw89Elv3WudEC/XI6Fq/nBOWRAPNx8FGz4fzi3Ew=; b=X1Kt1XtjwVslCCpktmgFpukPak++G8WuaUrMvaK2yM0MZ6DBtWE7slZmvJDQZHymVn VSaFdOX4C9urvEkWMZXH/xbHUFUe+Oqmi4/60BLWNJ3qKF0Nki1/5+n1+tPcGMUT2TXl X+JJjflUfFwyhVG197gPS9d5llZuoN7H6cnuCh8ne6o6ahDt4OVoYIMrCLfAP5Is7+KA N9WacbaVWSMIqiGah3pXkWRATVymgD9cHdnt4R/d8PibDrN8fRPBZaSB1uFCyXQv9sUc fSzNJ+zaQkR05JxIAyxttO4jfWmYEsCvU5iTBbPxEQhAu3SKC+e1Kh3n5f0qOZn8CvQG Bo3w== X-Gm-Message-State: APjAAAU/v2obWsfW8PdcBcCxHGSY38Y0GkA6nEIrbJyh4AEp5BdfuH+R NpskJZPovfE0Eui+2xRXNQEx1bnfY65AJgRCoz4soQ== X-Google-Smtp-Source: APXvYqzcD9UHlqR9qNj6vR6f5vlDxVmO/1/O65TTIz2A28d0G4r1mwV6MN3rHZ492NDp6DgoM1DGZbKJn8Z4yGWxArY= X-Received: by 2002:a81:7c55:: with SMTP id x82mr20442279ywc.488.1556021795621; Tue, 23 Apr 2019 05:16:35 -0700 (PDT) MIME-Version: 1.0 References: <20190422190302.GA3137@localhost> In-Reply-To: From: Ben Laurie Date: Tue, 23 Apr 2019 13:16:23 +0100 Message-ID: To: Phillip Hallam-Baker Cc: Nico Williams , secdispatch@ietf.org, IETF SAAG Content-Type: multipart/alternative; boundary="000000000000647f880587318e0f" Archived-At: Subject: Re: [saag] The Mathematical Mesh X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 12:16:41 -0000 --000000000000647f880587318e0f Content-Type: text/plain; charset="UTF-8" On Mon, 22 Apr 2019 at 20:33, Phillip Hallam-Baker wrote: > The primary focus is enabling real users to manage public key pairs on > their devices without being aware that they are doing it. Securely > establishing a set of public key pairs on each device and providing a > validation path to the user's personal axiom of trust is the main idea > here. Because if we achieve that, we are 80% of the way to securing almost > any communication pattern. > Where is the user testing for this? BTW, seems to me if users are not aware that they are doing it, they will also not be aware when they are not doing it. That doesn't seem like a path to security to me. -- I am hiring! Formal methods, UX, management, SWE ... verified s/w and h/w. #VerifyAllTheThings. *https://grow.googleplex.com/jobs/search?query=team:%221944651479079%22 * --000000000000647f880587318e0f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, 22 Apr 2019 at 20:33, Phillip= Hallam-Baker <phill@hallambake= r.com> wrote:
The primary focus is enabling real users to manage public key pairs o= n their devices without being aware that they are doing it. Securely establ= ishing a set of public key pairs on each device and providing a validation = path to the user's personal axiom of trust is the main idea here. Becau= se if we achieve that, we are 80% of the way to securing almost any communi= cation pattern.

Wher= e is the user testing for this? BTW, seems to me if users are not aware tha= t they are doing it, they will also not be aware when they are not doing it= . That doesn't seem like a path to security to me.

=
--
I am hiring! Formal methods, UX, management, SWE ... ve= rified s/w and h/w. #VerifyAllTheThings.

=
--000000000000647f880587318e0f-- From nobody Tue Apr 23 08:08:21 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB20912041E for ; Tue, 23 Apr 2019 08:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 0w3z8zAeURds for ; Tue, 23 Apr 2019 08:08:17 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32A6D120337 for ; Tue, 23 Apr 2019 08:08:15 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [IPv6:2607:f0b0:f:40::aef]) by relay.sandelman.ca (Postfix) with ESMTPS id A9C331F457; Tue, 23 Apr 2019 15:08:13 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id C5FCD1B23; Tue, 23 Apr 2019 11:08:23 -0400 (EDT) From: Michael Richardson To: Nico Williams cc: Russ Housley , IETF SAAG In-reply-to: <20190423035415.GG3137@localhost> References: <20190326214816.GB4211@localhost> <1553679912618.8510@cs.auckland.ac.nz> <20190327151545.GG4211@localhost> <20190330153101.GT35679@kduck.mit.edu> <269bee5d-e225-3484-04ed-3e5de6c19081@cs.tcd.ie> <20190422211449.GD3137@localhost> <233FB845-976C-49CA-ADA6-C97035A2426F@vigilsec.com> <20190423035415.GG3137@localhost> Comments: In-reply-to Nico Williams message dated "Mon, 22 Apr 2019 22:54:16 -0500." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Tue, 23 Apr 2019 11:08:23 -0400 Message-ID: <6958.1556032103@dooku.sandelman.ca> Archived-At: Subject: Re: [saag] ASN.1 vs. DER Encoding X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 15:08:20 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable >> X.500 one are used in certificates. I strongly encourage people to >> keep it simple. The bits on the wire sitll get too complicated, but >> the code can mostly do exact match processing. > To keep it simple means to leave the subjectName empty and use dNSName > and rfc822Name SANs instead wherever possible. Yes, but we can't leave the IssuerDN empty, and if we want chains of certificates (we do), then we need to put something into the subjectDN. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAly/KmcACgkQlUzhVv38 QpDiAAf6Alhhg5vTbR4W/5MYfT6IttawzwdPSytsfx638lqSebDtJXU41BJtfjgM YQEJR/k5u6xU73Of2csutjcermNv36uVsx0l9WInSenoQNzTM/JN5yGjTIjiJl0i 3Q4nOTy2YIfzGP+0docM3llsvVPRYH47+n5zU0CsVbH/2nhABkTa+oHAnUQ6W4cC ZLowFYUpH0H9X7TjXSJJ+zaDsVQoUh93UhMRzHgST07/noNjECfEyIOWnRkkVx5u toVe2UNLv8IpaChqiT6UGLVQvt4EPAc4pIsWldXBg+I10V+UwQjyfLicKcLFIQ7r ZKxONPqcXvkoWoOiKtQ9/KTY87TFUQ== =sj4C -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Apr 23 08:19:41 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94D85120407 for ; Tue, 23 Apr 2019 08:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 qfrUWL2GtxFU for ; Tue, 23 Apr 2019 08:19:39 -0700 (PDT) Received: from catfish.maple.relay.mailchannels.net (catfish.maple.relay.mailchannels.net [23.83.214.32]) (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 494E012001B for ; Tue, 23 Apr 2019 08:19:39 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 60CBE5C3B23; Tue, 23 Apr 2019 15:19:38 +0000 (UTC) Received: from pdx1-sub0-mail-a23.g.dreamhost.com (unknown [100.96.20.60]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id EF55B5C5360; Tue, 23 Apr 2019 15:19:37 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a23.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Tue, 23 Apr 2019 15:19:38 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Descriptive-Coil: 7ca9e4ed078588fb_1556032778187_3328232823 X-MC-Loop-Signature: 1556032778187:2317106856 X-MC-Ingress-Time: 1556032778187 Received: from pdx1-sub0-mail-a23.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a23.g.dreamhost.com (Postfix) with ESMTP id 6CFB08013D; Tue, 23 Apr 2019 08:19:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=59CpbjFf1QCkLI +SAnNzaLjVyFs=; b=tINsnXz8cuD7C3ZgbfiRrxsXgfdSgEbyaLdS3Co0gBtbq6 4I55wwXm1cFIy9UYEg7nsQcAS8s3ul487/qiyOqHZ4mnWtgyNRV2oT7WNyfUaQcN vHzcQVXlRW9E8OTBwWNW7ip6nOupLczrO+fvTYh26eIrwznlB3+1CHed1Fvzk= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a23.g.dreamhost.com (Postfix) with ESMTPSA id A312080138; Tue, 23 Apr 2019 08:19:34 -0700 (PDT) Date: Tue, 23 Apr 2019 10:19:31 -0500 X-DH-BACKEND: pdx1-sub0-mail-a23 From: Nico Williams To: Michael Richardson Cc: Russ Housley , IETF SAAG Message-ID: <20190423151930.GI3137@localhost> References: <20190327151545.GG4211@localhost> <20190330153101.GT35679@kduck.mit.edu> <269bee5d-e225-3484-04ed-3e5de6c19081@cs.tcd.ie> <20190422211449.GD3137@localhost> <233FB845-976C-49CA-ADA6-C97035A2426F@vigilsec.com> <20190423035415.GG3137@localhost> <6958.1556032103@dooku.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6958.1556032103@dooku.sandelman.ca> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrgeekgdejiecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd Archived-At: Subject: Re: [saag] ASN.1 vs. DER Encoding X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 15:19:40 -0000 On Tue, Apr 23, 2019 at 11:08:23AM -0400, Michael Richardson wrote: > >> X.500 one are used in certificates. I strongly encourage people to > >> keep it simple. The bits on the wire sitll get too complicated, but > >> the code can mostly do exact match processing. > > > To keep it simple means to leave the subjectName empty and use dNSName > > and rfc822Name SANs instead wherever possible. > > Yes, but we can't leave the IssuerDN empty, and if we want chains of > certificates (we do), then we need to put something into the subjectDN. Well, there is id-ce-issuerAltName, but indeed, the issuer Name must not be empty. At least we can encode domainnames as DNs, and there's no need to represent, e.g., email addresses as issuer DNs. In any case, issuer names don't leak as much into UIs, so it's less critical that we use dNSName SANs for them. From nobody Tue Apr 23 11:25:36 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 940B3120491 for ; Tue, 23 Apr 2019 11:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPGj_4nEoOth for ; Tue, 23 Apr 2019 11:25:31 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BE9312048E for ; Tue, 23 Apr 2019 11:25:31 -0700 (PDT) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 9B3FF2AD888; Tue, 23 Apr 2019 14:25:30 -0400 (EDT) Date: Tue, 23 Apr 2019 14:25:30 -0400 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20190423182530.GD87116@straasha.imrryr.org> Reply-To: saag@ietf.org References: <20190330153101.GT35679@kduck.mit.edu> <269bee5d-e225-3484-04ed-3e5de6c19081@cs.tcd.ie> <20190422211449.GD3137@localhost> <233FB845-976C-49CA-ADA6-C97035A2426F@vigilsec.com> <20190423035415.GG3137@localhost> <6958.1556032103@dooku.sandelman.ca> <20190423151930.GI3137@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190423151930.GI3137@localhost> User-Agent: Mutt/1.11.4 (2019-03-13) Archived-At: Subject: Re: [saag] ASN.1 vs. DER Encoding X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 18:25:35 -0000 On Tue, Apr 23, 2019 at 10:19:31AM -0500, Nico Williams wrote: > On Tue, Apr 23, 2019 at 11:08:23AM -0400, Michael Richardson wrote: > > >> X.500 one are used in certificates. I strongly encourage people to > > >> keep it simple. The bits on the wire sitll get too complicated, but > > >> the code can mostly do exact match processing. > > > > > To keep it simple means to leave the subjectName empty and use dNSName > > > and rfc822Name SANs instead wherever possible. > > > > Yes, but we can't leave the IssuerDN empty, and if we want chains of > > certificates (we do), then we need to put something into the subjectDN. > > Well, there is id-ce-issuerAltName, but indeed, the issuer Name must not > be empty. Of course the chaining need not in principle have been based on a fictional global X.509 directory tree. It could have been just key ids, with the CA names as commentary for human eyes and audit trails. The only downside would then be loss of the ability to bypass path length constraints via self-issued certificates. Not clear we'd really miss that. But this is of course entirely hypothetical... FWIW, despite clear non-compliance with RFC 5280 and potential interoperability risk, some users seem to manage with "self-signed" (below skid == akid) certificates that have empty DNs for *both* the subject and the issuer (and indeed no SANs of any kind). These are of course outside the WebPKI, used solely for unauthenticated or DANE TLS. A live example below, yes, in continuous use for the last 5 years or so. [ The 4096-bit RSA key and ~1000 year validity is a bold challenge to the coming scalable QC crypto apocalypse. :-) ] -- Viktor. Certificate: Data: Version: 3 (0x2) Serial Number: c3:26:2b:13:ca:b1:36:72 Signature Algorithm: sha256WithRSAEncryption Issuer: Validity Not Before: Jul 27 14:59:59 2014 GMT Not After : Nov 27 14:59:59 3013 GMT Subject: Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public-Key: (4096 bit) Modulus: 00:b6:d3:42:35:68:e9:2a:9e:ba:f8:f0:f4:bf:30: b5:0b:40:cd:10:4b:20:94:aa:fc:e8:d3:b1:b8:15: cc:24:ba:7f:95:b5:85:92:e9:d5:97:70:d3:fd:b3: c9:91:ba:d5:85:5d:c6:6d:98:8b:c3:b3:79:74:a7: 41:c6:f4:df:14:53:bb:90:21:72:71:ba:e2:56:03: 0a:0b:a9:db:d5:92:d3:90:58:4e:eb:a4:8b:51:80: db:5f:56:26:cf:9b:26:a8:2e:42:df:54:14:86:4e: 1f:ad:b2:9c:57:54:16:7a:39:25:a3:b3:90:97:eb: 70:92:04:27:10:b6:fd:9e:70:4f:b2:02:e2:fa:6d: 90:eb:9a:0c:64:3c:31:86:4c:98:99:47:00:75:b6: d0:bb:80:02:13:c7:43:97:24:ec:1e:3e:b1:1c:d6: c7:b7:de:fc:e8:bb:c6:d8:20:74:16:09:27:2d:17: 17:a5:a4:41:d0:f6:60:de:a2:84:fa:e4:8d:dd:1e: 98:7e:19:75:a4:87:52:18:45:d9:6d:39:3e:2c:b2: 64:1a:13:37:26:3f:72:8c:7d:fe:2e:d6:26:d7:cc: 37:aa:06:4a:2f:ea:bc:0f:00:5f:d5:30:79:e8:11: 21:64:03:b9:91:e5:da:47:6b:7d:43:e6:5e:20:e8: 1d:1d:1e:3d:b8:57:62:01:98:13:5b:cc:a8:9f:6b: d2:34:e0:6f:86:b8:ac:9d:89:f1:e9:27:b9:f8:55: ce:a2:8a:33:2b:ac:3a:65:c0:fb:12:b8:f7:5a:47: a6:ea:83:80:88:0f:ca:d4:d5:dc:62:5c:08:d9:cf: e6:ca:fe:32:00:9e:e3:c0:53:99:21:a3:c9:4f:66: 07:fc:61:e2:20:18:01:7f:61:dd:e1:72:b5:fd:c3: 97:23:2a:51:bf:42:58:64:0d:2b:4e:cc:85:a0:5e: 01:52:2b:7b:46:f0:63:19:9b:a3:5e:2c:70:23:36: a3:a9:3a:b3:60:2e:ad:78:68:96:ce:a4:4c:ea:13: 77:02:97:c4:55:82:f3:fd:3b:f3:f4:65:4e:dd:3b: fe:d2:dd:d0:da:29:e8:3e:dd:a9:e3:c6:16:db:eb: f8:90:72:dc:54:37:17:15:c9:43:1f:de:9d:5b:02: 5e:03:a9:3e:78:75:15:4d:bc:84:bf:a0:7e:4a:68: 7d:2b:c6:c5:b5:da:09:8b:f3:45:6e:82:2b:8b:be: e9:5d:b7:b3:f0:e8:0d:04:8c:e3:b8:ca:23:1d:dc: 10:09:09:2e:1e:bf:23:4c:67:be:64:c1:90:fd:62: 57:17:d4:33:e6:1d:4c:70:d7:58:f6:17:5e:d2:4b: d5:1f:9b Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Key Identifier: 98:C6:9B:D5:20:5C:1D:A8:31:39:BD:78:11:37:FF:BD:AD:5B:BD:59 X509v3 Authority Key Identifier: keyid:98:C6:9B:D5:20:5C:1D:A8:31:39:BD:78:11:37:FF:BD:AD:5B:BD:59 X509v3 Basic Constraints: CA:TRUE Signature Algorithm: sha256WithRSAEncryption 8d:47:1d:df:5f:63:ec:db:7b:a3:a3:a6:50:d0:76:f5:1a:86: da:21:bf:78:4d:4c:ab:ef:af:a1:be:e9:a5:29:20:6b:05:a3: 88:85:0e:57:17:9c:e6:8c:f5:87:c7:07:a3:7b:ed:7d:f4:03: 07:5a:6e:b4:bf:9c:db:6d:33:24:ae:4d:0e:39:06:54:9e:71: 68:f6:5d:58:e9:19:ff:ef:e2:e5:7c:a9:b9:da:21:dd:14:19: d8:c1:6b:ab:ae:fd:2f:86:14:b9:8f:bf:77:75:b8:07:cc:0a: 62:8a:00:98:c4:fb:0e:ec:ef:f7:11:88:0a:05:0e:ef:9b:c0: 98:e0:39:47:c0:83:af:5a:f6:aa:3d:8f:2c:5d:b1:95:b4:93: a1:86:bf:1d:b1:45:91:e5:7f:6f:63:ab:59:cf:03:4e:c0:37: fe:ce:9f:2d:cd:64:a1:81:62:00:79:32:4d:b0:43:2e:58:6e: c7:79:f7:b6:74:be:c9:65:c6:2f:d0:e9:b8:56:60:d4:46:48: d8:6d:da:b2:81:59:a9:f4:94:8c:c4:9f:f6:ab:16:6f:f1:04: e7:e9:2a:bb:04:1f:4d:c5:c2:e0:0b:b0:60:d8:1c:31:59:da: c6:32:6c:77:8b:db:e7:77:88:4d:15:45:c9:ea:b8:95:5a:d3: d6:5f:19:ed:cd:5d:84:0d:30:75:70:ac:a3:9a:6d:83:fe:bc: 60:fa:bb:2b:48:d7:12:eb:4a:e3:40:bf:01:56:a9:0d:d4:fc: 49:88:70:6b:0a:24:36:e8:c2:dd:ea:6c:67:cf:5e:d2:0a:7a: 31:b8:92:93:7c:f5:8c:91:8e:e9:d9:39:ec:1f:f2:98:0c:3d: d5:33:33:53:bd:b1:63:b6:18:e3:20:c6:50:2a:f1:09:50:5d: 88:69:76:91:38:a1:c1:47:71:09:12:75:6d:a0:17:72:ad:e6: 78:40:18:d3:04:04:70:3a:bf:74:45:0c:48:7a:7b:fe:0a:fd: ff:cb:ae:f7:85:50:fa:e2:23:73:87:54:ea:80:7e:c9:5f:da: 80:3f:af:04:3a:58:d8:4b:24:75:58:a0:c5:94:0a:b8:8e:62: 15:7e:3e:da:41:a8:a2:80:1b:c6:43:03:ae:2c:8c:fc:c7:83: df:38:df:b8:12:d2:ac:c1:10:b4:66:75:77:c8:a5:6f:49:16: c4:27:04:c2:fe:52:a4:ef:62:86:25:00:e7:ce:02:e7:4d:6c: c8:60:83:1f:4c:ba:d9:1b:83:da:cc:5d:bf:89:37:04:a7:85: 62:de:4d:2c:4e:d0:13:c4:cd:81:51:4a:b0:07:53:95:6f:42: 9e:2e:32:12:7b:1c:c1:c3 -----BEGIN CERTIFICATE----- MIIE1TCCAr2gAwIBAgIJAMMmKxPKsTZyMA0GCSqGSIb3DQEBCwUAMAAwIBcNMTQw NzI3MTQ1OTU5WhgPMzAxMzExMjcxNDU5NTlaMAAwggIiMA0GCSqGSIb3DQEBAQUA A4ICDwAwggIKAoICAQC200I1aOkqnrr48PS/MLULQM0QSyCUqvzo07G4Fcwkun+V tYWS6dWXcNP9s8mRutWFXcZtmIvDs3l0p0HG9N8UU7uQIXJxuuJWAwoLqdvVktOQ WE7rpItRgNtfVibPmyaoLkLfVBSGTh+tspxXVBZ6OSWjs5CX63CSBCcQtv2ecE+y AuL6bZDrmgxkPDGGTJiZRwB1ttC7gAITx0OXJOwePrEc1se33vzou8bYIHQWCSct FxelpEHQ9mDeooT65I3dHph+GXWkh1IYRdltOT4ssmQaEzcmP3KMff4u1ibXzDeq Bkov6rwPAF/VMHnoESFkA7mR5dpHa31D5l4g6B0dHj24V2IBmBNbzKifa9I04G+G uKydifHpJ7n4Vc6iijMrrDplwPsSuPdaR6bqg4CID8rU1dxiXAjZz+bK/jIAnuPA U5kho8lPZgf8YeIgGAF/Yd3hcrX9w5cjKlG/QlhkDStOzIWgXgFSK3tG8GMZm6Ne LHAjNqOpOrNgLq14aJbOpEzqE3cCl8RVgvP9O/P0ZU7dO/7S3dDaKeg+3anjxhbb 6/iQctxUNxcVyUMf3p1bAl4DqT54dRVNvIS/oH5KaH0rxsW12gmL80VugiuLvuld t7Pw6A0EjOO4yiMd3BAJCS4evyNMZ75kwZD9YlcX1DPmHUxw11j2F17SS9UfmwID AQABo1AwTjAdBgNVHQ4EFgQUmMab1SBcHagxOb14ETf/va1bvVkwHwYDVR0jBBgw FoAUmMab1SBcHagxOb14ETf/va1bvVkwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0B AQsFAAOCAgEAjUcd319j7Nt7o6OmUNB29RqG2iG/eE1Mq++vob7ppSkgawWjiIUO Vxec5oz1h8cHo3vtffQDB1putL+c220zJK5NDjkGVJ5xaPZdWOkZ/+/i5Xypudoh 3RQZ2MFrq679L4YUuY+/d3W4B8wKYooAmMT7Duzv9xGICgUO75vAmOA5R8CDr1r2 qj2PLF2xlbSToYa/HbFFkeV/b2OrWc8DTsA3/s6fLc1koYFiAHkyTbBDLlhux3n3 tnS+yWXGL9DpuFZg1EZI2G3asoFZqfSUjMSf9qsWb/EE5+kquwQfTcXC4AuwYNgc MVnaxjJsd4vb53eITRVFyeq4lVrT1l8Z7c1dhA0wdXCso5ptg/68YPq7K0jXEutK 40C/AVapDdT8SYhwawokNujC3epsZ89e0gp6MbiSk3z1jJGO6dk57B/ymAw91TMz U72xY7YY4yDGUCrxCVBdiGl2kTihwUdxCRJ1baAXcq3meEAY0wQEcDq/dEUMSHp7 /gr9/8uu94VQ+uIjc4dU6oB+yV/agD+vBDpY2EskdVigxZQKuI5iFX4+2kGoooAb xkMDriyM/MeD3zjfuBLSrMEQtGZ1d8ilb0kWxCcEwv5SpO9ihiUA584C501syGCD H0y62RuD2sxdv4k3BKeFYt5NLE7QE8TNgVFKsAdTlW9Cni4yEnscwcM= -----END CERTIFICATE----- From nobody Tue Apr 23 13:21:06 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7AA120344 for ; Tue, 23 Apr 2019 13:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 09J4ArmQjDjV for ; Tue, 23 Apr 2019 13:21:02 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3909D12013D for ; Tue, 23 Apr 2019 13:21:01 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [75.98.19.133]) by relay.sandelman.ca (Postfix) with ESMTPS id 251681F457; Tue, 23 Apr 2019 20:21:00 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 8C1D32BF8; Tue, 23 Apr 2019 16:21:10 -0400 (EDT) From: Michael Richardson To: Phillip Hallam-Baker cc: IETF SAAG In-reply-to: References: Comments: In-reply-to Phillip Hallam-Baker message dated "Mon, 22 Apr 2019 16:22:45 -0400." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Tue, 23 Apr 2019 16:21:10 -0400 Message-ID: <31575.1556050870@dooku.sandelman.ca> Archived-At: Subject: Re: [saag] draft-hallambaker-mesh-udf-02 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 20:21:04 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable mcr> Phill, I am reading your UDF document with the idea that IoT mcr> devices on constrained networks can send a reference to an IDevID mcr> rather than send the IDevID in-band.=C2=A0 This would apply to bot= h DTLS and mcr> also to EDHOC and HIP (such as for 802.15.9 keying). Phillip Hallam-Baker wrote: > If we went down that route, we might want to go full throttle and add > in a code point for a verbatim public key rather than a hash of a > public key. I have added that to the spec and removed it three times > because I do not make use of it in the Mesh. I am not opposed to such a thing, but in my use case I would not use it. I actually need the strong connection to the manufacturer, and the extensio= ns that PKIX provides. (Some new CoID would work equally well, but would also = be larger than a raw public key) > Another capability I left out is the authenticated only Locator > form. So the browser follows a link, gets back the result and compares > the fingerprint before accepting it. That could be a useful capability > for other applications.=C2=A0 The fingerprint is in the link, along with the link? That seems bigger, and does not help me. mcr> You have specified rfc3986 rather than 3987, so your URI are n= ot mcr> internationalized.=C2=A0 Is there a reason for that? > Lack of confidence in my knowledge of the subject material and lack of > time to get to a sufficient understanding. > Since the=C2=A0path-abempty=C2=A0of the URI is constrained to be base= 32 encoded > text, with punctuation (-/), the only place where there is scope for > internationalization is=C2=A0authority, that is the DNS name. I am also not an internationalization expert. We referenced iauthority in 3987 in draft-ietf-anima-bootstrap-keyinfra rather than authothority from 3986. This is within a PKIX extension. Maybe we were wrong. > If we are forming a QR code, we might as well just use the punycode. Well that eats up a 30% more bytes, doesn't it? It's not like we have to p= ut it through an ASCII<->EBCDIC gateway like email. mcr> Can you advance the use document without the rest of mmm? > Yes. I have presented the work as a single unit because this is what = we > told the PeP people that we wanted when they came to SECDispatch. But= I > am quite happy to go a-la-carte if people prefer. > The UDF doc is probably the one that is most easily separated from the > rest as it doesn't depend on any other part of the Mesh. It does depe= nd > on=C2=A0draft-hallambaker-web-service-discovery but that is actually = just a > profile of=C2=A0[RFC6763] and=C2=A0[RFC5785]. Can we do that, then? =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAly/c7YACgkQlUzhVv38 QpAJHQf+JvbmiKy/KqKuc6nY53MHw8HVE5fx3JwJZzXDILsbR+H6/3ckjR6yHnDB 1LZzjrtVzo8D2+QwntD91FZloRhbj/Y0cOSmIygh4BchXlAvtt/N8U7Hk5wzrHFn qdCL17FMwnlpiD9A4qLCBUgMB068AJLYsgQC46MNuoK1csmeMStq3DBHU/ZjgZTa 5n+Xff5TacbzH9F7WVprNecJ42/aG+vIxojsmqTQ7beMQB0U48eFEXoJM8AKRtgb GD4CLohYyZqbzp+elpphddgNK87px9xrvRHB3/E8xo40elaQZy/1mKVdrH6eb4Cl hr/BIStGHSOLqg970qu6HgQrCAKYDQ== =m8Ah -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Apr 23 14:23:07 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95F2812038E; Tue, 23 Apr 2019 14:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.645 X-Spam-Level: X-Spam-Status: No, score=-1.645 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3zE3CHuMrGY; Tue, 23 Apr 2019 14:23:04 -0700 (PDT) Received: from mail-ot1-f42.google.com (mail-ot1-f42.google.com [209.85.210.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C84512038D; Tue, 23 Apr 2019 14:23:04 -0700 (PDT) Received: by mail-ot1-f42.google.com with SMTP id t8so14205932otp.7; Tue, 23 Apr 2019 14:23:04 -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=l0lnV4/b3RKKabkgl1MOZEkGE0qfz/+toe0t4rRON24=; b=O2ijX6+RzC3rT22AD8ucUTmK6qTjbFqZ9fTdGyCxI81oLgfrtklc42BMJyNc/BElgy Nxs/Lx8LGqXZMDL7neAcHJjpjar9Lg1Wwhyg8uNFGL0bg1R0hLcP2LLs7ZvHjixDa3do ZOtSk53he/BGNa2N/9FlHQaB4+eekU5sCnv5to4MuLxhRsvP+8h0kj2BDxq13SF7eQgS himO7xuXyJ2WUeb/z7Vn3jHO5LTFjul4DYWNuTGoPQg7UICSWHnbjcCqpFNk1dYp/0PZ 7SQgp1KsoL52nLrlt1gczU941p1BdaP2h+UWxNNvbt3BdbgELy2FhLG1L86vkSLkBi0Y eJPw== X-Gm-Message-State: APjAAAUFXZexjwL/DoZc2NZcTPrdUnqNyxUpjp94xq3L/lN934sAIcWk To+5TyHO2+Ts8qEJOefEaQSASKvTwcyi18hM5m8= X-Google-Smtp-Source: APXvYqxGlLB+4L4bKOc3yxSxpOCnCageSJvIfUMITMzEbj8YvRL9v8Lq74hWbFM0Qi+6mFpzfFGB/NGLje4Arj615Ps= X-Received: by 2002:a05:6830:1017:: with SMTP id a23mr17803530otp.120.1556054583391; Tue, 23 Apr 2019 14:23:03 -0700 (PDT) MIME-Version: 1.0 References: <20190422190302.GA3137@localhost> In-Reply-To: From: Phillip Hallam-Baker Date: Tue, 23 Apr 2019 17:22:52 -0400 Message-ID: To: Ben Laurie Cc: Nico Williams , secdispatch@ietf.org, IETF SAAG Content-Type: multipart/alternative; boundary="000000000000b1bce10587393013" Archived-At: Subject: Re: [saag] The Mathematical Mesh X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 21:23:06 -0000 --000000000000b1bce10587393013 Content-Type: text/plain; charset="UTF-8" On Tue, Apr 23, 2019 at 8:16 AM Ben Laurie wrote: > > > On Mon, 22 Apr 2019 at 20:33, Phillip Hallam-Baker > wrote: > >> The primary focus is enabling real users to manage public key pairs on >> their devices without being aware that they are doing it. Securely >> establishing a set of public key pairs on each device and providing a >> validation path to the user's personal axiom of trust is the main idea >> here. Because if we achieve that, we are 80% of the way to securing almost >> any communication pattern. >> > > Where is the user testing for this? BTW, seems to me if users are not > aware that they are doing it, they will also not be aware when they are not > doing it. That doesn't seem like a path to security to me. > Please make that point to the Chrome team who are busy stripping out the security indicators so users don't know if they are on a secure site or not. I have done extensive user testing and come to the conclusion that almost none of it gives useful results. Most 'usability' testing methodology is designed to enable sales. So in 1980 when they started this, Apple was really interested in how to make the first 20 minutes of use as easy and productive a possible because that is the length of a typical sales session. What concerns me is how people behave in normal use when faced with an attack. The usability people do tests that tell them the security indicators are useless and strip them out so the user has no information to tell them whether something is secure or not. And not just Google's usability people, they all want to make the system easier to use by removing security. If you set up the test to look at people's behavior over short time intervals you will get a certain result. You also get that same result if you keep changing the security indicator. There are two concerns that must be addressed if a system is going to be usably secure: 1) The user must not be required to think about security when they are focused on their tasks. 2) The user must have the information they need to understand if their security concerns have been met. There are currently three device connection protocols, all provide a work factor of 2^120 or better. If we are using QR codes to connect devices, we can transmit the necessary information without the user needing to notice that is what we are doing. Otherwise, there are many existing protocols that make comparison of 15-30 character base 32 encoded strings as the basis for mutual authentication and these have proved effective and acceptable. --000000000000b1bce10587393013 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Apr 23, 2019 at 8:16 AM Ben Laurie <benl@google.com> wrote:


On Mon, 22 Apr 2019 at 20:33, Phillip Hallam-Baker <phill@hallambaker.com&g= t; wrote:
The= primary focus is enabling real users to manage public key pairs on their d= evices without being aware that they are doing it. Securely establishing a = set of public key pairs on each device and providing a validation path to t= he user's personal axiom of trust is the main idea here. Because if we = achieve that, we are 80% of the way to securing almost any communication pa= ttern.
<= br>
Where is the user testing for this? BTW, seems to me if users= are not aware that they are doing it, they will also not be aware when the= y are not doing it. That doesn't seem like a path to security to me.

Please make that point to the Chrome team who are bu= sy stripping out the security indicators so users don't know if they ar= e on a secure site or not.=C2=A0

I have done extensive user testing and come to the conclusion that = almost none of it gives useful results. Most 'usability' testing me= thodology is designed to enable sales. So in 1980 when they started this, A= pple was really interested in how to make the first 20 minutes of use as ea= sy and productive a possible because that is the length of a typical sales = session. What concerns me is how people behave in normal use when faced wit= h an attack.
The usabilit= y people do tests that tell them the security indicators are useless and st= rip them out so the user has no information to tell them whether something = is secure or not. And not just Google's usability people, they all want= to make the system easier to use by removing security. If you set up the t= est to look at people's behavior over short time intervals you will get= a certain result. You also get that same result if you keep changing the s= ecurity indicator.

There = are two concerns that must be addressed if a system is going to be usably s= ecure:

1) The user must n= ot be required to think about security when they are focused on their tasks= .
2) The user m= ust have the information they need to understand if their security concerns= have been met.

There are= currently three device connection protocols, all provide a work factor of = 2^120 or better.

If we ar= e using QR codes to connect devices, we can transmit the necessary informat= ion without the user needing to notice that is what we are doing. Otherwise= , there are many existing protocols that make comparison of 15-30 character= base 32 encoded strings as the basis for mutual authentication and these h= ave proved effective and acceptable.

--000000000000b1bce10587393013-- From nobody Wed Apr 24 01:53:17 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA611202AB; Wed, 24 Apr 2019 01:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1bVh-cm8g4G; Wed, 24 Apr 2019 01:53:13 -0700 (PDT) Received: from mail-qk1-f175.google.com (mail-qk1-f175.google.com [209.85.222.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83A1A120242; Wed, 24 Apr 2019 01:53:13 -0700 (PDT) Received: by mail-qk1-f175.google.com with SMTP id m137so6658742qke.3; Wed, 24 Apr 2019 01:53:13 -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=9wxstN3a8zUR+X9QIslPu+2ElNc1YUs2NBndJn0kRwE=; b=NkRZwZBGbrg5r/hquLUOxev+DSrJ9ZOHmvSQ0KILf2gRFL5CqkWu5GY0cgvpI9MWni pLa0lYTpVMnV0t3GNE4EM2xlmvxIjMf3ykMEBNTZ3tbBWEt9bilOQg9FOYadHDco8XVS /FakmrhWjmqFNA1uL2iVs0T7QsqFiibdEFjRlbUJlna90YNqEcbLxKS53v85OeO+Kadu kE0aja4idnl/EoWV6xZbqZeQCsLoQ3BbaRuTfk7+QjluODqRcMQ8aL05KVhxP+q7Uja1 /cwFfsC1JPYfL8XDyHjg4iH38BUf50iIo50AUTFhiee1iaNHHF0tQUH+dfP8ObBpiMcD U92w== X-Gm-Message-State: APjAAAVrHO55ZbyIAiQ5SzYR8YhmdGUU57TAXZJtqp+K3668SQB8w9UT 9hQo64k69SYCLyNwchxjsKFqRHNgfp2FGYzs9yA= X-Google-Smtp-Source: APXvYqzqN890hnOZQypWFXsxIPetadJXgUBR42MH5wgYsJjEgJ19Q9JiGRJWXv9/eG7vBBt7uKEypqC/6j+8HOc4r/s= X-Received: by 2002:a37:63cf:: with SMTP id x198mr16961396qkb.353.1556095992450; Wed, 24 Apr 2019 01:53:12 -0700 (PDT) MIME-Version: 1.0 References: <20190422190302.GA3137@localhost> In-Reply-To: From: Ben Laurie Date: Wed, 24 Apr 2019 09:53:01 +0100 Message-ID: To: Phillip Hallam-Baker Cc: Ben Laurie , secdispatch@ietf.org, IETF SAAG Content-Type: multipart/alternative; boundary="000000000000ddd5df058742d43c" Archived-At: Subject: Re: [saag] The Mathematical Mesh X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 08:53:15 -0000 --000000000000ddd5df058742d43c Content-Type: text/plain; charset="UTF-8" On Tue, 23 Apr 2019 at 22:23, Phillip Hallam-Baker wrote: > > > On Tue, Apr 23, 2019 at 8:16 AM Ben Laurie wrote: > >> >> >> On Mon, 22 Apr 2019 at 20:33, Phillip Hallam-Baker >> wrote: >> >>> The primary focus is enabling real users to manage public key pairs on >>> their devices without being aware that they are doing it. Securely >>> establishing a set of public key pairs on each device and providing a >>> validation path to the user's personal axiom of trust is the main idea >>> here. Because if we achieve that, we are 80% of the way to securing almost >>> any communication pattern. >>> >> >> Where is the user testing for this? BTW, seems to me if users are not >> aware that they are doing it, they will also not be aware when they are not >> doing it. That doesn't seem like a path to security to me. >> > > Please make that point to the Chrome team who are busy stripping out the > security indicators so users don't know if they are on a secure site or > not. > That is not what is happening. Chrome is switching from showing positive to negative indicators. > > I have done extensive user testing and come to the conclusion that almost > none of it gives useful results. Most 'usability' testing methodology is > designed to enable sales. So in 1980 when they started this, Apple was > really interested in how to make the first 20 minutes of use as easy and > productive a possible because that is the length of a typical sales > session. What concerns me is how people behave in normal use when faced > with an attack. > Indeed. > > The usability people do tests that tell them the security indicators are > useless and strip them out so the user has no information to tell them > whether something is secure or not. > Incorrect. > And not just Google's usability people, they all want to make the system > easier to use by removing security. > Also incorrect. > If you set up the test to look at people's behavior over short time > intervals you will get a certain result. You also get that same result if > you keep changing the security indicator. > > There are two concerns that must be addressed if a system is going to be > usably secure: > > 1) The user must not be required to think about security when they are > focused on their tasks.. > 2) The user must have the information they need to understand if their > security concerns have been met. > I agree with both of these points. I have no idea why you think you can get to this state without doing user testing. > > There are currently three device connection protocols, all provide a work > factor of 2^120 or better. > > If we are using QR codes to connect devices, we can transmit the necessary > information without the user needing to notice that is what we are doing. > Otherwise, there are many existing protocols that make comparison of 15-30 > character base 32 encoded strings as the basis for mutual authentication > and these have proved effective and acceptable. > Oh really? Evidence? --000000000000ddd5df058742d43c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, 23 Apr 2019 at 22:23, Phillip= Hallam-Baker <phill@hallambake= r.com> wrote:

<= /div>

On Tue, Apr 23, 2019 at 8:16 AM Ben Laurie <benl@google.com> wrote:


On Mon, 22 Apr 2019 at 20:33, Phillip Hallam-Baker <phill@hallambaker.com>= ; wrote:
The pr= imary focus is enabling real users to manage public key pairs on their devi= ces without being aware that they are doing it. Securely establishing a set= of public key pairs on each device and providing a validation path to the = user's personal axiom of trust is the main idea here. Because if we ach= ieve that, we are 80% of the way to securing almost any communication patte= rn.
<= /div>

Where is the user testing for this? B= TW, seems to me if users are not aware that they are doing it, they will al= so not be aware when they are not doing it. That doesn't seem like a pa= th to security to me.

Please make that point to the Chrome team who are bu= sy stripping out the security indicators so users don't know if they ar= e on a secure site or not.=C2=A0

That is not what is happening. Chrome is switching from showing pos= itive to negative indicators.
=C2=A0

I have = done extensive user testing and come to the conclusion that almost none of = it gives useful results. Most 'usability' testing methodology is de= signed to enable sales. So in 1980 when they started this, Apple was really= interested in how to make the first 20 minutes of use as easy and producti= ve a possible because that is the length of a typical sales session. What c= oncerns me is how people behave in normal use when faced with an attack.

Indeed.
=C2=A0

The usability people do tests that tell them the secur= ity indicators are useless and strip them out so the user has no informatio= n to tell them whether something is secure or not.

Incorrect.
=C2=A0
And not just Google's usability peop= le, they all want to make the system easier to use by removing security.

Also incorrect.
= =C2=A0
If you set u= p the test to look at people's behavior over short time intervals you w= ill get a certain result. You also get that same result if you keep changin= g the security indicator.

There are two concerns that must be addressed i= f a system is going to be usably secure:

1) The user must not be required= to think about security when they are focused on their tasks..=C2=A0
=
=
= 2) The user must have the information they need to understand if their secu= rity concerns have been met.

<= div>I agree with both of these points. I have no idea why you think you can= get to this state without doing user testing.
=C2=A0

There are currently three device connection protocols, all provid= e a work factor of 2^120 or better.
If we are using QR codes to connect d= evices, we can transmit the necessary information without the user needing = to notice that is what we are doing. Otherwise, there are many existing pro= tocols that make comparison of 15-30 character base 32 encoded strings as t= he basis for mutual authentication and these have proved effective and acce= ptable.

Oh really? Eviden= ce?

--000000000000ddd5df058742d43c-- From nobody Wed Apr 24 09:47:16 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91E55120321; Wed, 24 Apr 2019 09:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.645 X-Spam-Level: X-Spam-Status: No, score=-1.645 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLlCEQE6cUne; Wed, 24 Apr 2019 09:47:13 -0700 (PDT) Received: from mail-ot1-f42.google.com (mail-ot1-f42.google.com [209.85.210.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E061B12024A; Wed, 24 Apr 2019 09:47:12 -0700 (PDT) Received: by mail-ot1-f42.google.com with SMTP id d24so14024408otl.11; Wed, 24 Apr 2019 09:47:12 -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=uLDyotKJNNgcq5CTRgRhsvrmNKLr1soVVzFSzcm56BQ=; b=TmSqVLZY0s2HZkNs/ElfbGYIQNJbvhaO+4X3rHBkNbAtldAyPBjuEf9dSOzt5B8fUP 4cTo6e6ZSGnA6ZgfWPiNT7hzdHEVVoTDayXx/Im4L9MW44yuVORn8STtv0z4Bb88waBM h8UC+em+II+wBmdeqG5ywZUvOmMWDKOZYmWbI78NVFAoMz4kfyHReXC+E6ZciCITsKAm 21jRPaCJ4UsynHJeIFden9wIDkPVLqwAJvICUShuqrN2yRYAti6SQ1Vd8nXqu6Xq4Qoh QyJ1CCC2lzrVYb/mzRcZbRuQer/nSIzMVod8fqg9VOj9uzc/u0kzVhaTNqAXGhE3W3cT 1LEQ== X-Gm-Message-State: APjAAAUTv2o2XYMDUwwU3Q3DekyuOYAvTrManEt59/dzrA6EKWL7mMrS J4ZMak1IGvinlnLnj+iYufzKi5mGFG8gCsJl4ZE= X-Google-Smtp-Source: APXvYqx6eBQaFonVy+zK/3q9GtMrnViRvNKxZNy2NEyb3TUWZS98qYqflrMmOusyAbE6+J7/QkIGcMi0VyqvxoAcO6U= X-Received: by 2002:a9d:58c5:: with SMTP id s5mr18826199oth.361.1556124431174; Wed, 24 Apr 2019 09:47:11 -0700 (PDT) MIME-Version: 1.0 References: <20190422190302.GA3137@localhost> In-Reply-To: From: Phillip Hallam-Baker Date: Wed, 24 Apr 2019 12:47:01 -0400 Message-ID: To: Ben Laurie Cc: Ben Laurie , secdispatch@ietf.org, IETF SAAG Content-Type: multipart/alternative; boundary="000000000000f255d80587497336" Archived-At: Subject: Re: [saag] The Mathematical Mesh X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 16:47:14 -0000 --000000000000f255d80587497336 Content-Type: text/plain; charset="UTF-8" On Wed, Apr 24, 2019 at 4:53 AM Ben Laurie wrote: > If we are using QR codes to connect devices, we can transmit the necessary >> information without the user needing to notice that is what we are doing. >> Otherwise, there are many existing protocols that make comparison of 15-30 >> character base 32 encoded strings as the basis for mutual authentication >> and these have proved effective and acceptable. >> > > Oh really? Evidence? > We Chat has a billion accounts and is conservatively estimated to serve about 50% of the population of China. They use QR codes for contact exchange. https://en.wikipedia.org/wiki/WeChat One of the biggest problems that we have made for ourselves is making the perfect be the enemy of the good. We insisted on end-to-end secure email and got 0.1% of the mail user population enrolled for credentials of which less than 1% use end-to-end email regularly. If you want to offer security usability testing resources to improve on the schemes I am proposing, I would be more than happy to make any changes they suggest. But right now the situation is that it took me over 15 minutes to configure Thunderbird to use S/MIME. And I know what I am doing. It is a 17 step process that requires use of a Web browser and email client and multiple switches between the two. It took me another ten minutes to find the instructions. When the current situation is that users are required to poke themselves in the eye with a sharp stick to get end-to-end security, it doesn't take very much to improve on that. --000000000000f255d80587497336 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Apr 24, 2019 at 4:53 AM Ben Laurie <ben@links.org> wrote:
If we are using QR codes to connect devices, we can transmit the= necessary information without the user needing to notice that is what we a= re doing. Otherwise, there are many existing protocols that make comparison= of 15-30 character base 32 encoded strings as the basis for mutual authent= ication and these have proved effective and acceptable.

Oh really? Evidence?

We Chat has a billion accounts and is conservatively estimated to se= rve about 50% of the population of China. They use QR codes for contact exc= hange.

One of the biggest problems that we have made for our= selves is making the perfect be the enemy of the good. We insisted on end-t= o-end secure email and got 0.1% of the mail user population enrolled for cr= edentials of which less than 1% use end-to-end email regularly.

If you want to offer security usabil= ity testing resources to improve on the schemes I am proposing, I would be = more than happy to make any changes they suggest.

But right now the situation is that it took me ove= r 15 minutes to configure Thunderbird to use S/MIME. And I know what I am d= oing. It is a 17 step process that requires use of a Web browser and email = client and multiple switches between the two. It took me another ten minute= s to find the instructions.

When the current situation is that users are required to poke themselves= in the eye with a sharp stick to get end-to-end security, it doesn't t= ake very much to improve on that.

--000000000000f255d80587497336-- From nobody Wed Apr 24 09:52:50 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFA76120321; Wed, 24 Apr 2019 09:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZAoVZtWynhBu; Wed, 24 Apr 2019 09:52:37 -0700 (PDT) Received: from mail-qt1-f172.google.com (mail-qt1-f172.google.com [209.85.160.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 065BF12034D; Wed, 24 Apr 2019 09:52:34 -0700 (PDT) Received: by mail-qt1-f172.google.com with SMTP id b3so6198315qtc.12; Wed, 24 Apr 2019 09:52:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tFpPR5uf0JdoufkYR8azFQdCri8mvMkH4yWRLJXALZA=; b=XdyO5oAq1WbX19BEnM9ksAXViR+BYbHaMOzkXBWpqd4kj70PyD17QxEra57sDRX7VS Xr/Ax12mS2dXI/C0d+2L5i9huReq4MLICEkWxLlCSd6iTWwbHMTXwZVsSDBrvlCdGCwb 2q5EtcgBI29u0LUpV6tMcSc612IpSX/Vb4T0OoaJV41TZAL2UW17oMV8Rl98qJR4MUV/ sVIPzZr2v4krpZ6guj0lnG9nCkLls+GAT82Yudk5CCPJc0gV+i8LgIeoYTcue+lD0fNn XuIvMwF08bfvNOyJ5OJwFWrDf6cjVg81YT2RM+6vAXpMHx+ZxTE30Cm/ZnwARvaGrMo2 OmRQ== X-Gm-Message-State: APjAAAXUeOwYEVWUGlNjCRtSJUiIuGMbs6NPkX7J/GfW1u7KPI6vk1pI Rel8RYUmx29pJPX70Tc6UuSozxdEHhnkLu25Fi0= X-Google-Smtp-Source: APXvYqzEUYSymcFVD1QmG5kjPPjR1qQqhZcfi1QfGXLfgbXmWYgXufUUJRIQrfIOMhkQpf/bp2LF9Yx1r7oug8ImNoA= X-Received: by 2002:a0c:fe4a:: with SMTP id u10mr5442559qvs.182.1556124752978; Wed, 24 Apr 2019 09:52:32 -0700 (PDT) MIME-Version: 1.0 References: <20190422190302.GA3137@localhost> In-Reply-To: From: Ben Laurie Date: Wed, 24 Apr 2019 17:52:22 +0100 Message-ID: To: Phillip Hallam-Baker Cc: Ben Laurie , secdispatch@ietf.org, IETF SAAG Content-Type: multipart/alternative; boundary="00000000000020a8db058749870f" Archived-At: Subject: Re: [saag] The Mathematical Mesh X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 16:52:39 -0000 --00000000000020a8db058749870f Content-Type: text/plain; charset="UTF-8" On Wed, 24 Apr 2019 at 17:47, Phillip Hallam-Baker wrote: > On Wed, Apr 24, 2019 at 4:53 AM Ben Laurie wrote: > >> If we are using QR codes to connect devices, we can transmit the >>> necessary information without the user needing to notice that is what we >>> are doing. Otherwise, there are many existing protocols that make >>> comparison of 15-30 character base 32 encoded strings as the basis for >>> mutual authentication and these have proved effective and acceptable. >>> >> >> Oh really? Evidence? >> > > We Chat has a billion accounts and is conservatively estimated to serve > about 50% of the population of China. They use QR codes for contact > exchange. > > https://en.wikipedia.org/wiki/WeChat > "In China, digital marketing around QR code is an environmental feature of some international cities, such as Guangzhou, Shanghai and Beijing." Not so much around these parts. > One of the biggest problems that we have made for ourselves is making the > perfect be the enemy of the good. We insisted on end-to-end secure email > and got 0.1% of the mail user population enrolled for credentials of which > less than 1% use end-to-end email regularly. > This I do very much agree with. > > If you want to offer security usability testing resources to improve on > the schemes I am proposing, I would be more than happy to make any changes > they suggest. > > But right now the situation is that it took me over 15 minutes to > configure Thunderbird to use S/MIME. And I know what I am doing. It is a 17 > step process that requires use of a Web browser and email client and > multiple switches between the two. It took me another ten minutes to find > the instructions. > > When the current situation is that users are required to poke themselves > in the eye with a sharp stick to get end-to-end security, it doesn't take > very much to improve on that. > I don't disagree with this, either. I do object, however, to assertions that things are obviously usable. --00000000000020a8db058749870f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, 24 Apr 2019 at 17:47, Phillip= Hallam-Baker <phill@hallambake= r.com> wrote:
On We= d, Apr 24, 2019 at 4:53 AM Ben Laurie <ben@links.org> wrote:
If we are using QR codes to connect devices, we can transmit the ne= cessary information without the user needing to notice that is what we are = doing. Otherwise, there are many existing protocols that make comparison of= 15-30 character base 32 encoded strings as the basis for mutual authentica= tion and these have proved effective and acceptable.

Oh really? Evidence?

We Chat has a billio= n accounts and is conservatively estimated to serve about 50% of the popula= tion of China. They use QR codes for contact exchange.

=

"In China, digital marketing around = QR code is an environmental feature of some international cities, such as G= uangzhou, Shanghai and Beijing."

Not so much around these parts= .


One of the biggest problems that we have made for ours= elves is making the perfect be the enemy of the good. We insisted on end-to= -end secure email and got 0.1% of the mail user population enrolled for cre= dentials of which less than 1% use end-to-end email regularly.
<= /div>

This I do very much agree with.=
=C2=A0

If you want to offer security u= sability testing resources to improve on the schemes I am proposing, I woul= d be more than happy to make any changes they suggest.

But right now the = situation is that it took me over 15 minutes to configure Thunderbird to us= e S/MIME. And I know what I am doing. It is a 17 step process that requires= use of a Web browser and email client and multiple switches between the tw= o. It took me another ten minutes to find the instructions.

When the curr= ent situation is that users are required to poke themselves in the eye with= a sharp stick to get end-to-end security, it doesn't take very much to= improve on that.

I= don't disagree with this, either. I do object, however, to assertions = that things are obviously usable.

--00000000000020a8db058749870f-- From nobody Wed Apr 24 10:28:51 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18DEB12010D; Wed, 24 Apr 2019 10:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=cryptonector.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 nLSgPkMVZtoR; Wed, 24 Apr 2019 10:28:48 -0700 (PDT) Received: from cichlid.maple.relay.mailchannels.net (cichlid.maple.relay.mailchannels.net [23.83.214.36]) (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 0FBB21200F6; Wed, 24 Apr 2019 10:28:47 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 219C52C28C9; Wed, 24 Apr 2019 17:28:47 +0000 (UTC) Received: from pdx1-sub0-mail-a82.g.dreamhost.com (100-96-11-130.trex.outbound.svc.cluster.local [100.96.11.130]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 52D4E2C20E6; Wed, 24 Apr 2019 17:28:46 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a82.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Wed, 24 Apr 2019 17:28:47 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Turn-Dime: 7e8c8d0b7edd552c_1556126926976_1125117772 X-MC-Loop-Signature: 1556126926975:2374531913 X-MC-Ingress-Time: 1556126926975 Received: from pdx1-sub0-mail-a82.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a82.g.dreamhost.com (Postfix) with ESMTP id A94887FE8E; Wed, 24 Apr 2019 10:28:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=2CpHrdAShrvvvH to4JsvGM5PpMo=; b=g/6BeidDdH813gJapOKxMfseh8LT/En4Whd7ZXHgG0R3IK yVZK0dXYr5SVHeY31jCW23HpLL40DlGwwsTe822IYrZSYHN6Qqs9VcobKFSAJu1R RQuAVqP+tbYtHX0Bnwm+7gUpLBZQyEoq+uyzFoOyPq5Y94oaD5BYGujmbuXPE= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a82.g.dreamhost.com (Postfix) with ESMTPSA id 45B437FE77; Wed, 24 Apr 2019 10:28:43 -0700 (PDT) Date: Wed, 24 Apr 2019 12:28:41 -0500 X-DH-BACKEND: pdx1-sub0-mail-a82 From: Nico Williams To: Ben Laurie Cc: Phillip Hallam-Baker , secdispatch@ietf.org, IETF SAAG Message-ID: <20190424172840.GJ3137@localhost> References: <20190422190302.GA3137@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrhedvgddtlecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd Archived-At: Subject: Re: [saag] The Mathematical Mesh X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 17:28:50 -0000 On Wed, Apr 24, 2019 at 09:53:01AM +0100, Ben Laurie wrote: > On Tue, 23 Apr 2019 at 22:23, Phillip Hallam-Baker > wrote: > > On Tue, Apr 23, 2019 at 8:16 AM Ben Laurie wrote: > >> On Mon, 22 Apr 2019 at 20:33, Phillip Hallam-Baker > >> wrote: > >> > >>> The primary focus is enabling real users to manage public key pairs on > >>> their devices without being aware that they are doing it. Securely > >>> establishing a set of public key pairs on each device and providing a > >>> validation path to the user's personal axiom of trust is the main idea > >>> here. Because if we achieve that, we are 80% of the way to securing almost > >>> any communication pattern. > >> > >> Where is the user testing for this? BTW, seems to me if users are not > >> aware that they are doing it, they will also not be aware when they are not > >> doing it. That doesn't seem like a path to security to me. Users absolutely have to be capable of being at least minimally aware. Perhaps we should leave UI issues till much later, provided we get consensus on a few "rules", with these as my proposal: 0) users absolutely have to be [capable of being] at least minimally aware of security 1) security UI indications should be minimally intrusive within constraint (0) I'm sure there are many UI design options, such as: - non-modal positive indicators - non-modal? negative indicators - reject negative interactions outright, with some sort of modal introducer option ("scan your peer's QR code" and such) - etc. Perhaps with different UI choices for different kinds of devices. Changes in device capabilities and form factors may well require re-thinking UI design choices. I don't care as much which if any or even all of the above are used, as long as we get (0) and (1). The degree of security indication UI intrusiveness is up for debate. We should give implementors guidance, but still let them experiment. > > Please make that point to the Chrome team who are busy stripping out the > > security indicators so users don't know if they are on a secure site or > > not. > > > > That is not what is happening. Chrome is switching from showing positive to > negative indicators. Thanks for this. Can you provide a link to justification/blogs/research about that change? Nico -- From nobody Wed Apr 24 10:49:16 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BCE712009E; Wed, 24 Apr 2019 10:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVfS3A34cFeX; Wed, 24 Apr 2019 10:49:05 -0700 (PDT) Received: from mail-oi1-f193.google.com (mail-oi1-f193.google.com [209.85.167.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EE9F120117; Wed, 24 Apr 2019 10:49:05 -0700 (PDT) Received: by mail-oi1-f193.google.com with SMTP id v7so15000247oie.8; Wed, 24 Apr 2019 10:49:05 -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=JLs7u6n0BLda+NKMeHxRGEXqjKQHeTSuL5qvBZULy5Y=; b=qKJB38gEvewNp2jk8Jxuv6DoZThNJpLir7P4vabtXiIt1EYnHsZe7JhM+9HNJQd3P0 gFetEmg8DIJi7xx0bkh+3/6R/jAxyn0Fp5sID+ayDDmJi0DigQp/w/bSWdtFVRD3EiCH gb4tJVH2j6iByKM1zycK6C6KmnXztngOxQ46Ll9u7hFBk/5/vdouZJJKqUW3B8/PWo59 V/thnXEKAAA2jPkW9myBOClto6Wmbk7ECb65OP83NPWp6DeE88fzXPh9w2kJCmhJDedL i3RcvHIVjnWfltXYUTPDairZ/73XelciquQjSbpD/g4CYE5nw2vcG5tooJ9Se1HDq3Kk QFgA== X-Gm-Message-State: APjAAAXhfJjfvQvzt47jR7enOQSARGQdTvhcuRdNleXNP1LiExpT5dFy bxM/4KiXm4uQdbGVbOfodBC0I6b/ji5ptRbmmX0= X-Google-Smtp-Source: APXvYqzte1uUtHyoA0sIWq6BkAkqbAvNSoWSqW4w+aFHDCQzkDEX3llRNWUNOoRJmh2a+IqOJHX05r56zFAZlmWkkpc= X-Received: by 2002:aca:c68b:: with SMTP id w133mr221595oif.58.1556128144012; Wed, 24 Apr 2019 10:49:04 -0700 (PDT) MIME-Version: 1.0 References: <20190422190302.GA3137@localhost> In-Reply-To: From: Phillip Hallam-Baker Date: Wed, 24 Apr 2019 13:48:53 -0400 Message-ID: To: Ben Laurie Cc: Ben Laurie , secdispatch@ietf.org, IETF SAAG Content-Type: multipart/alternative; boundary="0000000000003fbc1405874a514d" Archived-At: Subject: Re: [saag] The Mathematical Mesh X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 17:49:06 -0000 --0000000000003fbc1405874a514d Content-Type: text/plain; charset="UTF-8" On Wed, Apr 24, 2019 at 12:52 PM Ben Laurie wrote: > On Wed, 24 Apr 2019 at 17:47, Phillip Hallam-Baker > wrote: > >> But right now the situation is that it took me over 15 minutes to >> configure Thunderbird to use S/MIME. And I know what I am doing. It is a 17 >> step process that requires use of a Web browser and email client and >> multiple switches between the two. It took me another ten minutes to find >> the instructions. >> > >> When the current situation is that users are required to poke themselves >> in the eye with a sharp stick to get end-to-end security, it doesn't take >> very much to improve on that. >> > > I don't disagree with this, either. I do object, however, to assertions > that things are obviously usable. > My assertion was 'easier' not 'usable'. If a process has 17 steps and 16 are unnecessary, I don't need to do usability testing to know that it will be easier to use if we eliminate them. Well let me tell you what I am going to be doing on Sunday. I am going to be taking the scafolding out of where it is stored in the garage and building a tower in the master suite so that I can take down the #W$)(%$ Nest Protect device and update the WiFi settings to use a different WiFi access point after the old one was stolen. Someone obviously did a heck of a lot of user testing on the device but they never thought about the management and maintenance features that would be needed in the real world. I have connected my device to my WiFi network three separate times. Why does your product insist on tearing up my work and throwing it in my face? You control both the device and the app used to establish the connection. If you switched to using the Mesh approach, I would not need to repeat the process yet again. (And incidentally, the connection process does use QR codes and there is probably no need to change the user experience to enable use of a standards based approach) It is not just your company that has a problem with usability, Apple does as well. I have to go and help people configure the television because the Apple TV assumes that a person watching television can see well enough to read. Which might sound like a really good assumption until a 90 year old partially sighted deaf person wants to watch CNN. I would really like to be able to set out a control that has a limited number of buttons that directly provide the functions he needs but that would require a four or five figure investment in coding on my part. And the reason I brought up Apple and Nest is that they are produced by the companies that are the leaders in the usability field. But here is the thing, I don't think it was the usability testing that made the difference so much as the knowledge that the polo shirted one would have a screaming tantrum if someone had to climb a ladder to reconfigure a device whose very function requires that it be installed in the ceiling. The reason that the World Wide Web exists at all is that Tim Berners-Lee ignored the sage advice of the hypertext community that referential transparency was essential and pressed ahead with 'scruffy links'. Nobody did usability testing to decide whether the gopher or Web UI was the approach to follow until long after we knew the answer. My criticism of usability testing is this: we do not find out if buildings will stay up by building them and seeing if they fall down. That is exactly how it was done in the past which is why the Bent Pyramid collapsed during construction. Usability testing is the scientific approach. We should have moved past science and started practicing engineering. We should be able to predict with some confidence how users will react by applying principles learned from individual tests. Some classes of usability failure are quite easy to analyze. If a user faces two potential situations, case A and case B where one will lead to disaster and the other will perform the intended task and has no means of distinguishing these cases, the product is defective. Right now, I have no means of knowing if an email from my bank is actually an email from my bank or not. And that should be considered a problem. The problem I have with discussions of usability is that the argument is made that because we might not be able to serve every user we should just give up and never try to change anything. Like I said, if you want to propose changes to the protocol based on testing or even just based on advice from usability specialists, I am more than interested. But right now, the Mesh Reference Code is a command line tool and I am pretty sure that is not going to be the means of delivery that is most useful for end users. It is however the most useful means of delivery for people who want to build the Mesh into other applications and tools which is why we stopped developing the GUI tool and wrote the command line tool instead. --0000000000003fbc1405874a514d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Apr 24, 2019 at 12:52 PM Ben Laurie <ben@links.org> wrote:
O= n Wed, 24 Apr 2019 at 17:47, Phillip Hallam-Baker <phill@hallambaker.com> wrote:<= br>
But right now the situatio= n is that it took me over 15 minutes to configure Thunderbird to use S/MIME= . And I know what I am doing. It is a 17 step process that requires use of = a Web browser and email client and multiple switches between the two. It to= ok me another ten minutes to find the instructions.
<= div style=3D"font-size:small">
When= the current situation is that users are required to poke themselves in the= eye with a sharp stick to get end-to-end security, it doesn't take ver= y much to improve on that.

I don't disagree with this, either. I do object, however, to assertio= ns that things are obviously usable.
My asser= tion was 'easier' not 'usable'. If a process has 17 steps a= nd 16 are unnecessary, I don't need to do usability testing to know tha= t it will be easier to use if we eliminate them.


Well let me tell= you what I am going to be doing on Sunday. I am going to be taking the sca= folding out of where it is stored in the garage and building a tower in the= master suite so that I can take down the #W$)(%$ Nest Protect device and u= pdate the WiFi settings to use a different WiFi access point after the old = one was stolen.

Someone o= bviously did a heck of a lot of user testing on the device but they never t= hought about the management and maintenance features that would be needed i= n the real world.

I have = connected my device to my WiFi network three separate times. Why does your = product insist on tearing up my work and throwing it in my face? You contro= l both the device and the app used to establish the connection. If you swit= ched to using the Mesh approach, I would not need to repeat the process yet= again. (And incidentally, the connection process does use QR codes and the= re is probably no need to change the user experience to enable use of a sta= ndards based approach)

It= is not just your company that has a problem with usability, Apple does as = well. I have to go and help people configure the television because the App= le TV assumes that a person watching television can see well enough to read= . Which might sound like a really good assumption until a 90 year old parti= ally sighted deaf person wants to watch CNN. I would really like to be able= to set out a control that has a limited number of buttons that directly pr= ovide the functions he needs but that would require a four or five figure i= nvestment in coding on my part.

And the reason I brought up Apple and Nest is that they are produced= by the companies that are the leaders in the usability field.

But here is the thing, I don't th= ink it was the usability testing that made the difference so much as the kn= owledge that the polo shirted one would have a screaming tantrum if someone= had to climb a ladder to reconfigure a device whose very function requires= that it be installed in the ceiling.

The reason that the World Wide Web exists at all is that Tim B= erners-Lee ignored the sage advice of the hypertext community that referent= ial transparency was essential and pressed ahead with 'scruffy links= 9;. Nobody did usability testing to decide whether the gopher or Web UI was= the approach to follow until long after we knew the answer.


My criticism of usability testing is this: we do = not find out if buildings will stay up by building them and seeing if they = fall down. That is exactly how it was done in the past which is why the Ben= t Pyramid collapsed during construction.

Usability testing is the scientific approach. We should hav= e moved past science and started practicing engineering. We should be able = to predict with some confidence how users will react by applying principles= learned from individual tests.


Som= e classes of usability failure are quite easy to analyze. If a user faces t= wo potential situations, case A and case B where one will lead to disaster = and the other will perform the intended task and has no means of distinguis= hing these cases, the product is defective.

Right now, I have no means of knowing if an email from= my bank is actually an email from my bank or not. And that should be consi= dered a problem. The problem I have with discussions of usability is that t= he argument is made that because we might not be able to serve every user w= e should just give up and never try to change anything.

Like I said, if you want to propose changes = to the protocol based on testing or even just based on advice from usabilit= y specialists, I am more than interested. But right now, the Mesh Reference= Code is a command line tool and I am pretty sure that is not going to be t= he means of delivery that is most useful for end users.

It is however the most useful means of deliv= ery for people who want to build the Mesh into other applications and tools= which is why we stopped developing the GUI tool and wrote the command line= tool instead.
--0000000000003fbc1405874a514d-- From nobody Wed Apr 24 10:51:05 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46954120134 for ; Wed, 24 Apr 2019 10:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03SpsJddJm4z for ; Wed, 24 Apr 2019 10:51:01 -0700 (PDT) Received: from mail-yw1-xc34.google.com (mail-yw1-xc34.google.com [IPv6:2607:f8b0:4864:20::c34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A26412009E for ; Wed, 24 Apr 2019 10:51:01 -0700 (PDT) Received: by mail-yw1-xc34.google.com with SMTP id a62so1795854ywa.4 for ; Wed, 24 Apr 2019 10:51:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bUEuTUeeGg7YmNlU9oCfjaYP5PEjUjo7tdYJfMerZ1A=; b=vWxsHjjbHI2hVruJW1cZMb0LRgAv62tue+R+o6Wl40uRlB4wg5pifnxYJsYGp6Mhkx +tKRpua7hK/dGaF1K4ek+WREhGLXceWL1hDzpDHASeZwAaqC0zV987bdTKi0qAcmXBer xeRV2LJA5TLZsE2JegGYQawuvVXLH9ID+eD/z5Y0tqDQfZcoziBl2j9eetvOzM4HENdI WgvQn+R9gEJlBTK9O88IIraRaFIsVPfe0TVNy6+ndHNJ7Eg4kOorHihHRMm+0EptMIj/ i6r+/nKYQKUQpRvkAHMCKFRFgY+5E/5Rb+ZKU2t4WDsUR3ebWnnBxiFZqMZKphzoOafc O8xw== 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=bUEuTUeeGg7YmNlU9oCfjaYP5PEjUjo7tdYJfMerZ1A=; b=kQ+LGoxeYxy5BpWDFq3OWne+T0N9vabR9Pmo7l78lqKlG+USKT/HFPSE385W4DCcKk el1lFm9LYepQhjS2CFZhK3fNcItXDKP/Xoz8vDY+xo92HUzje0VfCZSvU//6SJ014nhM 5/vvEfmund9rWKafnqgh79eMMNkbXv/7jT81jRyfzenpR8WyvQGTBN6O15VZdFOOvSPz dkgCmsFSLdfo4DsjAx3luAUlMBoa+Glm00waM4UaIStZSTT6dBwkqdDrqJIrjcTgxf6y no9vFpmD5MBbobiOcR0Nd2fG3bbLkqMUxf0gKgaUId6Ewb8jjcEl09aDeFrn4KXotT3k ug4Q== X-Gm-Message-State: APjAAAVaQYy4k5RxjgRga0HcCMbx6ajUVTRM4i5/R/Ao5I2T8puWncDv KzdEqxVYt9emgOaFJA6IBHxZ8/CcXyc9+XNk4cxIgg== X-Google-Smtp-Source: APXvYqxDFRXQL27RqOzAlbwG1kUfwpd9GuwL0AMH0cr3oGZkJWx6/QlVCrFsvHxpWxOG/+5m2I/e4gbxogWqGOo3sdM= X-Received: by 2002:a81:55c1:: with SMTP id j184mr16914355ywb.311.1556128260146; Wed, 24 Apr 2019 10:51:00 -0700 (PDT) MIME-Version: 1.0 References: <20190422190302.GA3137@localhost> <20190424172840.GJ3137@localhost> In-Reply-To: <20190424172840.GJ3137@localhost> From: Ben Laurie Date: Wed, 24 Apr 2019 18:50:45 +0100 Message-ID: To: Nico Williams Cc: Ben Laurie , IETF SAAG , secdispatch@ietf.org Content-Type: multipart/alternative; boundary="0000000000002c3c0505874a588a" Archived-At: Subject: Re: [saag] The Mathematical Mesh X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 17:51:03 -0000 --0000000000002c3c0505874a588a Content-Type: text/plain; charset="UTF-8" On Wed, 24 Apr 2019 at 18:29, Nico Williams wrote: > On Wed, Apr 24, 2019 at 09:53:01AM +0100, Ben Laurie wrote: > > Chrome is switching from showing positive to > > negative indicators. > > Thanks for this. Can you provide a link to justification/blogs/research > about that change? > https://blog.chromium.org/2018/05/evolving-chromes-security-indicators.html is a good starting point. Adrienne Porter Felt's research is also worth looking into. --0000000000002c3c0505874a588a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --0000000000002c3c0505874a588a-- From nobody Wed Apr 24 10:56:55 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFBEC12017D for ; Wed, 24 Apr 2019 10:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.353 X-Spam-Level: *** X-Spam-Status: No, score=3.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, GB_SUMOF=5, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AsatV6v4JffT for ; Wed, 24 Apr 2019 10:56:50 -0700 (PDT) Received: from mail-oi1-f181.google.com (mail-oi1-f181.google.com [209.85.167.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF75412011E for ; Wed, 24 Apr 2019 10:56:50 -0700 (PDT) Received: by mail-oi1-f181.google.com with SMTP id w139so14995286oie.9 for ; Wed, 24 Apr 2019 10:56:50 -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=7vQT5XfQKgad0MPyJyMnR0OHjBTFLgGNePYjgUKeTvQ=; b=VUqHFZUSFgsZ9sJ+r13zOMSakSs5v9WXtfbuBB3Ua0yCzjpB8l68g4cJLdpY1c89sB QFdCDz1v/806ljgnrP0CZ4G39H1azuEJOZgv90Lk6SV6rHJufXnBwcoaBF38gWrnQ+iq 8+4OAVPW1EhCEZdkkXbSTwxN732+dhCakzr0vAOJZqaMunl4ofpMR55yxlaUZPHTQ8bm xtYa6LkFemBFdpsMQL/LS0zKYul/kspLH7vKgVv2gxqFp/0xXO7jcKUNAitzAWcVEbUI DMDJZ00IGvGvWuLJqiAvqMOpm+5vkzGsSHB9ICSrxZWB4pHOBoaj+YpLwyXKymebpCKE PmXQ== X-Gm-Message-State: APjAAAWiA41XEBZcToTfusdM31xQjyke9WtKs9d273X9BkPan3DXakUx 6M2MaEajMI2qYamBs3ryOM+4/FV4Bpy5JC83gUFtdsAP X-Google-Smtp-Source: APXvYqy0dU99ijFv3GfJ1VVvLzA9ORfIJijnAo4Fo3SdHRrRcHWbXHraXqxOLZgMeIHbE7ncm8qQXNwVs/vg1SVuQZo= X-Received: by 2002:aca:5c55:: with SMTP id q82mr205449oib.95.1556128609565; Wed, 24 Apr 2019 10:56:49 -0700 (PDT) MIME-Version: 1.0 From: Phillip Hallam-Baker Date: Wed, 24 Apr 2019 13:56:40 -0400 Message-ID: To: IETF SAAG Content-Type: multipart/alternative; boundary="000000000000ff7ff405874a6cd5" Archived-At: Subject: [saag] Direct trust between users X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 17:56:53 -0000 --000000000000ff7ff405874a6cd5 Content-Type: text/plain; charset="UTF-8" Nico asked about the Mesh Trust model and I said that I was trying to avoid imposing one. I do have metrics for measuring the quality of trust established in terms of a work factor however: http://mathmesh.com/Documents/draft-hallambaker-mesh-trust.html This is not a computational work factor as we are used to. It is a social work factor nominally denominated in currency (USD) and bounded in time. Let us say that we did some key signing even open to IETF meeting attendees only. It would cost an attacker $325 plus travel minimum to impersonate me. Not an impossible sum if they really really want to impersonate me but enough to stop a large number of attacks. Furthermore, there is a significant risk of being caught if they attempt the impersonation on any large scale. So the social work factor might be $1000. Now lets enroll the assertion provided in a blockchain. We don't need proof of work to do blockchain. All we need to do is to have multiple notaries and cross certify between them so that the work factor of each notary reaches the sum of the work factors of all the blockchains on the planet within 24 hours. People can do proof of work if they like but nobody can exceed the work factor of the metanotary because we will add their output to the metanotary as an input. I think we can assume the social work factor for metanotary.com is infinity. So we have an assertion that my public key is MC23-... dated 2019-Jul-18. It would have cost $1000 to forge that assertion before that date and $infinity to forge afterwards. That seems like a useful building block to incorporate into a system of trust. It is not going to be possible to use that approach in every situation but we can almost certainly use it in many situations. So why might we want to do key signing at IETFs? Well we write code and some of that code ends up on GitHub and makes its way into software used in the wild. So credentialling IETF-ers would be pretty useful. Credentialling the Linux Plumbers etc. is probably even more useful. Probably a good thing if we could do something at Black Hat or RSA. We could probably deliver a real improvement in the robustness of the Internet software development ecosystem if we produced a system serving 10,000 or so users and was never used by outside that community. So how might it work? I have done a few sketches but I haven't come to a firm conclusion on how to realize the crypto yet. The simplest user experience to implement would be to have an app for mobile devices that can be used to scan a dynamic QR code presented on a screen near the registration desk. This would provide the necessary crypto info to complete the key signing. We could go further and make it so that scanning the QR code tells the attendee which line to join and causes the registration staff to be told which badges to find next. The registration staff could then check government issued ID, hand over the badge and tell the system the ID matched. --000000000000ff7ff405874a6cd5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Nic= o asked about the Mesh Trust model and I said that I was trying to avoid im= posing one. I do have metrics for measuring the quality of trust establishe= d in terms of a work factor however:

http://mathmesh.com/Documents/draft-hallambaker-mesh-trust.htm= l=C2=A0=C2=A0

Thi= s is not a computational work factor as we are used to. It is a social work= factor nominally denominated in currency (USD) and bounded in time.
<= div class=3D"gmail_default" style=3D"font-size:small">
Let us say that we did some ke= y signing even open to IETF meeting attendees only. It would cost an attack= er $325 plus travel minimum to impersonate me. Not an impossible sum if the= y really really want to impersonate me but enough to stop a large number of= attacks. Furthermore, there is a significant risk of being caught if they = attempt the impersonation on any large scale. So the social work factor mig= ht be $1000.
Now lets enr= oll the assertion provided in a blockchain. We don't need proof of work= to do blockchain. All we need to do is to have multiple notaries and cross= certify between them so that the work factor of each notary reaches the su= m of the work factors of all the blockchains on the planet within 24 hours.= People can do proof of work if they like but nobody can exceed the work fa= ctor of the metanotary because we will add their output to the metanotary a= s an input.
I think we ca= n assume the social work factor for metan= otary.com is infinity.

So we have an assertion that my public key is MC23-... dated 2019-Jul= -18. It would have cost $1000 to forge that assertion before that date and = $infinity to forge afterwards.

That seems like a useful building block to incorporate into a system = of trust. It is not going to be possible to use that approach in every situ= ation but we can almost certainly use it in many situations.


So why might we want to do key signing at IETFs?= =C2=A0

Well we write code= and some of that code ends up on GitHub and makes its way into software us= ed in the wild. So credentialling IETF-ers would be pretty useful. Credenti= alling the Linux Plumbers etc. is probably even more useful. Probably a goo= d thing if we could do something at Black Hat or RSA.

We could probably deliver a real improvement i= n the robustness of the Internet software development ecosystem if we produ= ced a system serving 10,000 or so users and was never used by outside that = community.

=

So how might it work?

I have done a few sketches = but I haven't come to a firm conclusion on how to realize the crypto ye= t.

The simplest user expe= rience to implement would be to have an app for mobile devices that can be = used to scan a dynamic QR code presented on a screen near the registration = desk. This would provide the necessary crypto info to complete the key sign= ing.

=
We could go further = and make it so that scanning the QR code tells the attendee which line to j= oin and causes the registration staff to be told which badges to find next.= The registration staff could then check government issued ID, hand over th= e badge and tell the system the ID matched.

--000000000000ff7ff405874a6cd5-- From nobody Wed Apr 24 11:01:47 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE2A112017D for ; Wed, 24 Apr 2019 11:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JQoDZtY3Pf45 for ; Wed, 24 Apr 2019 11:01:43 -0700 (PDT) Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82C16120118 for ; Wed, 24 Apr 2019 11:01:43 -0700 (PDT) Received: by mail-yb1-xb2e.google.com with SMTP id p134so7461172ybc.4 for ; Wed, 24 Apr 2019 11:01:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=phI0EIwQpAAsAqI+wyYi90h9Pb/udQGPegsf0KeZrQ0=; b=QS6RvMx+EIreyX9Hzs5Ak/K4NTlMtLJrHN2HP61yo5hHIPOs8aE7PlAHJMF+q75YQp DtzM/fnNF9kwlX2UdldFZ1KG9bQ6bFya0tJe1nuVXbAtG2YsT9+QMc+fKud6PB1vLGr1 +EwjEJnjE90f35qWggMGFfpmchBgN/vcu9CrU8BW3fYvgpa6dERiu7AWQxMPpSkIulFq KPZ647tncDKKLptPRmGesAt7iSJSOES855TbQ1SNPH3UDBdd8O3cElb+cl7z0SQXIZ7W +Xu8hsf0awtWjDRz1xOZuG9HTHHyLcs1Tl45/w2EJ9+V0oKeZmiAE5y9jIhDNXNgC6ik 0Tfg== 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=phI0EIwQpAAsAqI+wyYi90h9Pb/udQGPegsf0KeZrQ0=; b=TnzyDqNZQEc0F+EC11+g9fJqnllU7ztV7GoRlGsvcwZKKND/SZq7orb8+l59qBvDJA wJTMGyvZICFEz6qlMIk9p0iQqzLA1/yYd3BYlmrfmNtxgW1qaAJJ0sdjaeeYgMmpbD+2 kalQVFKvP4Tr1Axwlwg74ALcW7Tzpx2mLKwSPfkkBUB/nJcHK/VG4x85xDRwLqS0pIqc 3vooJnjRI5uddD+0Dngchm+nUhGjKJLqw5juhuU+MJmivvwpjWR1nCO395Ltg+1NQxkF sz1qldocKjbpjIRBXdd2h+V4aAYnv+ECKw0za8nvC7e3movNqCJ35bykS714SuuG7sRL Ht0g== X-Gm-Message-State: APjAAAVprTdMJuoFHAYFgqXHVC/430oh36MOgqhJsvAOfkTfYMGFzHFw X2NI0nDl82YCg50a7A5VY3HjgS3GQjLisJ+syM4m6Q== X-Google-Smtp-Source: APXvYqyoeJtO8TQvWStR5jsDWHQDbpEk0adahyKDBUstkk5Cr61TURUzhHQhvZ+CYcs2tm41eyPNNmASHwLq6PhFY68= X-Received: by 2002:a25:b317:: with SMTP id l23mr3125809ybj.513.1556128902404; Wed, 24 Apr 2019 11:01:42 -0700 (PDT) MIME-Version: 1.0 References: <20190422190302.GA3137@localhost> In-Reply-To: From: Ben Laurie Date: Wed, 24 Apr 2019 19:01:28 +0100 Message-ID: To: Phillip Hallam-Baker Cc: Ben Laurie , secdispatch@ietf.org, IETF SAAG Content-Type: multipart/alternative; boundary="00000000000074533805874a7ea5" Archived-At: Subject: Re: [saag] The Mathematical Mesh X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 18:01:46 -0000 --00000000000074533805874a7ea5 Content-Type: text/plain; charset="UTF-8" On Wed, 24 Apr 2019 at 18:49, Phillip Hallam-Baker wrote: > > The reason that the World Wide Web exists at all is that Tim Berners-Lee > ignored the sage advice of the hypertext community that referential > transparency was essential and pressed ahead with 'scruffy links'. Nobody > did usability testing to decide whether the gopher or Web UI was the > approach to follow until long after we knew the answer. > This is a clear case of survivorship bias. The users did the usability testing. WWW survived (despite being technically terrible in many ways), the competitors did not. > My criticism of usability testing is this: we do not find out if buildings > will stay up by building them and seeing if they fall down. That is exactly > how it was done in the past which is why the Bent Pyramid collapsed during > construction. > > Usability testing is the scientific approach. We should have moved past > science and started practicing engineering. We should be able to predict > with some confidence how users will react by applying principles learned > from individual tests. > Indeed, somewhat possible. Some classes of usability failure are quite easy to analyze. If a user > faces two potential situations, case A and case B where one will lead to > disaster and the other will perform the intended task and has no means of > distinguishing these cases, the product is defective. > > Right now, I have no means of knowing if an email from my bank is actually > an email from my bank or not. And that should be considered a problem. The > problem I have with discussions of usability is that the argument is made > that because we might not be able to serve every user we should just give > up and never try to change anything. > Well, the problem I have with discussions of usability is the argument is made that we should leave that until all the tech is figured out, or that we don't need to bother because the thing is obviously better. Going from .1% to 1% is clearly an improvement, but it is not a solution. BTW, my original question was not about QR codes (though I have my doubts about those), but about this assertion about usability: "Otherwise, there are many existing protocols that make comparison of 15-30 character base 32 encoded strings as the basis for mutual authentication and these have proved effective and acceptable." -- I am hiring! Formal methods, UX, management, SWE ... verified s/w and h/w. #VerifyAllTheThings. *https://grow.googleplex.com/jobs/search?query=team:%221944651479079%22 * --00000000000074533805874a7ea5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, 24 Apr 2019 at 18:49, Phillip= Hallam-Baker <phill@hallambake= r.com> wrote:

<= /div>
The re= ason that the World Wide Web exists at all is that Tim Berners-Lee ignored = the sage advice of the hypertext community that referential transparency wa= s essential and pressed ahead with 'scruffy links'. Nobody did usab= ility testing to decide whether the gopher or Web UI was the approach to fo= llow until long after we knew the answer.

This is a clear case of survivorship bias. The users did t= he usability testing. WWW survived (despite being technically terrible in m= any ways), the competitors did not.

=C2=A0
My criticism of usability t= esting is this: we do not find out if buildings will stay up by building th= em and seeing if they fall down. That is exactly how it was done in the pas= t which is why the Bent Pyramid collapsed during construction.

Usability = testing is the scientific approach. We should have moved past science and s= tarted practicing engineering. We should be able to predict with some confi= dence how users will react by applying principles learned from individual t= ests.

Indeed, somewhat po= ssible.

Some classes of usability failure are quite easy to analyze. If a user f= aces two potential situations, case A and case B where one will lead to dis= aster and the other will perform the intended task and has no means of dist= inguishing these cases, the product is defective.

Right now, I have no me= ans of knowing if an email from my bank is actually an email from my bank o= r not. And that should be considered a problem. The problem I have with dis= cussions of usability is that the argument is made that because we might no= t be able to serve every user we should just give up and never try to chang= e anything.

Well, the pro= blem I have with discussions of usability is the argument is made that we s= hould leave that until all the tech is figured out, or that we don't ne= ed to bother because the thing is obviously better. Going from .1% to 1% is= clearly an improvement, but it is not a solution.

BTW, my original question was not about QR codes (though I have my doubts = about those), but about this assertion about usability: "Otherwise, th= ere are many existing protocols that make comparison of 15-30 character bas= e 32 encoded strings as the basis for mutual authentication and these have = proved effective and acceptable."


<= /div>--
I am hiring! Formal methods, UX, management, SWE ... ver= ified s/w and h/w. #VerifyAllTheThings.

--00000000000074533805874a7ea5-- From nobody Wed Apr 24 11:26:55 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41F4B120100 for ; Wed, 24 Apr 2019 11:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 SOa4u9j-hCvS for ; Wed, 24 Apr 2019 11:26:52 -0700 (PDT) Received: from quail.birch.relay.mailchannels.net (quail.birch.relay.mailchannels.net [23.83.209.151]) (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 F24B3120126 for ; Wed, 24 Apr 2019 11:26:51 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id BA68C141CBF; Wed, 24 Apr 2019 18:26:50 +0000 (UTC) Received: from pdx1-sub0-mail-a82.g.dreamhost.com (100-96-12-146.trex.outbound.svc.cluster.local [100.96.12.146]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id EBA23142B8D; Wed, 24 Apr 2019 18:26:49 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a82.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Wed, 24 Apr 2019 18:26:50 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Eyes-Stretch: 6510e1384a10a6c1_1556130410415_3697750952 X-MC-Loop-Signature: 1556130410415:1549506737 X-MC-Ingress-Time: 1556130410414 Received: from pdx1-sub0-mail-a82.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a82.g.dreamhost.com (Postfix) with ESMTP id 269557FE9E; Wed, 24 Apr 2019 11:26:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=mvADs1VtcODK20 YMl4/BcTm5d7k=; b=s7AVJbIKRrDnU1S4LsGjdBy5GgqQyfFPS8UYBtRmpSyShX G7iIE048+UTQ/GE/1adMOMJCBBlOrrDrbmf9K79r0/iZTUcwxNmZj0bjFlBNdJVY r/aDjeHPXQe/xkrHoAKlA9F5QbMcmTCS8LbWm6+Z4zpfY/KFiRf4ggleo3PRw= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a82.g.dreamhost.com (Postfix) with ESMTPSA id DDAB77FE9F; Wed, 24 Apr 2019 11:26:44 -0700 (PDT) Date: Wed, 24 Apr 2019 13:26:42 -0500 X-DH-BACKEND: pdx1-sub0-mail-a82 From: Nico Williams To: Phillip Hallam-Baker Cc: IETF SAAG Message-ID: <20190424182641.GL3137@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrhedvgddvudcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd Archived-At: Subject: Re: [saag] Direct trust between users X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 18:26:54 -0000 On Wed, Apr 24, 2019 at 01:56:40PM -0400, Phillip Hallam-Baker wrote: > So we have an assertion that my public key is MC23-... dated 2019-Jul-18. > It would have cost $1000 to forge that assertion before that date and > $infinity to forge afterwards. ISTM that it's $1000 (or whatever) the first and _every_ time. That's because the blockchain will have to support the "help, I've lost my one and only device!" or "help, I've lost all my devices!" cases. E.g., you're on a plane that lands on the Hudson river and you have to leave everything behind, including your laptop, tablet, and phone, and you're thousands of miles away from your desktop device or backups. Now, you could just cancel everything and fly home (after drying up anyways), but this may be very costly in time and money so you probably won't want to. > So why might we want to do key signing at IETFs? > > Well we write code and some of that code ends up on GitHub and makes its > way into software used in the wild. So credentialling IETF-ers would be > pretty useful. Credentialling the Linux Plumbers etc. is probably even more > useful. Probably a good thing if we could do something at Black Hat or RSA. > > We could probably deliver a real improvement in the robustness of the > Internet software development ecosystem if we produced a system serving > 10,000 or so users and was never used by outside that community. I agree with this. > So how might it work? > > I have done a few sketches but I haven't come to a firm conclusion on how > to realize the crypto yet. It's a PGP-alike with a blockchain and with keyservers that participate in the blockchain, and a few very popular people (or conferences, or even large corporations) who act as notable notaries. Without a work factor this is a like like a distributed Merkle hash tree. > The simplest user experience to implement would be to have an app for > mobile devices that can be used to scan a dynamic QR code presented on a > screen near the registration desk. This would provide the necessary crypto > info to complete the key signing. We're assuming trusted devices, but we practically have to anyways, so, sure. > We could go further and make it so that scanning the QR code tells the > attendee which line to join and causes the registration staff to be told > which badges to find next. The registration staff could then check > government issued ID, hand over the badge and tell the system the ID > matched. The ID check is not going to be that good. As with PGP, having something of a key signing party where people who know you vouch for you (and vice-versa) seems better. This is where a notion of security level starts creeping in: do I trust the IETF registrar more than I trust an IETF participant I've known for decades? If I do take the registrar's say-so at face value and have N>100 interactions with you where I have every reason to think it's you every time, does the security level go up, and do I get to say that or does it happen automatically? Nico -- From nobody Wed Apr 24 14:16:03 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB26E120290; Wed, 24 Apr 2019 14:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.646 X-Spam-Level: X-Spam-Status: No, score=-1.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nvUxaYvHgB3; Wed, 24 Apr 2019 14:15:52 -0700 (PDT) Received: from mail-oi1-f174.google.com (mail-oi1-f174.google.com [209.85.167.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DB7A12014E; Wed, 24 Apr 2019 14:15:52 -0700 (PDT) Received: by mail-oi1-f174.google.com with SMTP id v10so15527242oib.1; Wed, 24 Apr 2019 14:15:52 -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=aH23A9foeZfCYyknRPZWdPQU/jqp+lqDwufuX+TPgjU=; b=HmdVIIeW7ucJOrCc6Mr5rWsOD4ekXk5Dvlxyc8H08J2p8N+qbcB/HuK6nOl5mYjq0V 6t40O3n5qyhu5kJ8xH5TsmygDc07KTHNauXGSeza+b1rQdkwFp5n6Uy1+GA2afNSnkDZ uBqH/NsNi/HhfV/ejrjiqb6TNXdERWTLXId84Ogb1BOYH+HiRgA27sjIvaSS9Gnl2ntY IYtEQXJwol60sZp0Np7XTgtxB+PQeY+8OlUCJuEKlWN0LcywMrJ+jt9B7OYrLqZj9mQg TMOBe+8PimrrsCWGlaxnwymvYesIiNGjzGPYoUUdxofbYlUQhkyTLCdjzme27ZOu4EA0 58HQ== X-Gm-Message-State: APjAAAUPGL61/bpV49J3gGMrZiPVkl+raeL2T6jJcV6RWKAh1rkWDi5k KdsFYmPJ3fOU7Wy5VmgBqeJkWVxeD9qBEv0wp80= X-Google-Smtp-Source: APXvYqyjnBzS2yQSRMcU8bWhwV2QLt3shR+5HaTLbjy0BMDybj+GMwA/+ad3oDBEwRcRTYadxcKtMpTf9fK9f3jxAnE= X-Received: by 2002:aca:43d5:: with SMTP id q204mr838602oia.100.1556140551442; Wed, 24 Apr 2019 14:15:51 -0700 (PDT) MIME-Version: 1.0 References: <20190422190302.GA3137@localhost> In-Reply-To: From: Phillip Hallam-Baker Date: Wed, 24 Apr 2019 17:15:41 -0400 Message-ID: To: Ben Laurie Cc: Ben Laurie , secdispatch@ietf.org, IETF SAAG Content-Type: multipart/alternative; boundary="000000000000ca1a1b05874d349e" Archived-At: Subject: Re: [saag] The Mathematical Mesh X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 21:15:54 -0000 --000000000000ca1a1b05874d349e Content-Type: text/plain; charset="UTF-8" On Wed, Apr 24, 2019 at 2:01 PM Ben Laurie wrote: > > > On Wed, 24 Apr 2019 at 18:49, Phillip Hallam-Baker > wrote: > >> >> The reason that the World Wide Web exists at all is that Tim Berners-Lee >> ignored the sage advice of the hypertext community that referential >> transparency was essential and pressed ahead with 'scruffy links'. Nobody >> did usability testing to decide whether the gopher or Web UI was the >> approach to follow until long after we knew the answer. >> > > This is a clear case of survivorship bias. The users did the usability > testing. WWW survived (despite being technically terrible in many ways), > the competitors did not. > The Web had 100 users in the fall of 1992 when it was first demonstrated in public. There were at least two dozen competing network hypertext systems, most of which were far better financed than the Web which had two full time staff at the time. Nine months later the Web had over a million users and it was game over for every other network hypertext scheme apart from Acrobat which had already begun merging itself with the Web to survive. There was rather more than survivor bias at work there. One of the biggest differences between the Web and everything else was that Eric Binna paid immense attention to the quality of his software distributions. He provided binary distributions for a start and the code compiled from source. We paid a great deal of attention to usability but we never had the resources to test any of it. There was never a testing lab at CERN for a start. Or at NCSA as far as I am aware. Come to think of it, when VeriSign acquired the old Netscape HQ, I pushed for the construction of a usability lab. Which means that there wasn't one in the building when we moved in. Right now, I have no means of knowing if an email from my bank is actually >> an email from my bank or not. And that should be considered a problem. The >> problem I have with discussions of usability is that the argument is made >> that because we might not be able to serve every user we should just give >> up and never try to change anything. >> > > Well, the problem I have with discussions of usability is the argument is > made that we should leave that until all the tech is figured out, or that > we don't need to bother because the thing is obviously better. Going from > .1% to 1% is clearly an improvement, but it is not a solution. > Like I said, I am more than happy to accept input on how to do UI better. But I am not going to be blocked on those resources. At this point I have one employee and a seven figure budget. To start thinking about UI testing I need to have more developers and a bigger budget. > BTW, my original question was not about QR codes (though I have my doubts > about those), but about this assertion about usability: "Otherwise, there > are many existing protocols that make comparison of 15-30 character base 32 > encoded strings as the basis for mutual authentication and these have > proved effective and acceptable." > I have entered product activation keys and lived. Adobe managed to sell software with that requirements for decades. So they are not a show stopper for at least some part of the audience. I am requiring only comparison of two codes, not entry. I accept that this is not the ideal approach and in the spec I suggest using BASE32K encoding based on dictionaries of words or images. Since the connection mechanism only requires comparison for equality, we don't have to be restricted to something that can be entered on a keyboard. Images would be the ideal of course because they can be language independent. 'Are these nine pictures the same' is a pretty easy question to answer. The work factor for the UDF approach would be (9*15)-8 = 127. 2^127 is sufficient for most purposes. Comparing nine pictures for equality is relatively straightforward. I haven't gone into this in detail as yet, but my rough strategy for managing the dictionaries is to 1) Sort the entries into a canonical sort order 2) Form a Merkle tree of the result. 3) Publish the apex of the tree in some tamper-proof fashion. This avoids the need to store the entire dictionary on every device which is important even for unconstrained devices. The image dictionary is going to be huge and word dictionaries have to be customized to the user's language. It has not escaped my notice that I could use this as a funding mechanism for the Mesh itself. The million dollar image dictionary. Companies could pay to contribute images to the corpus, part of which could be reserved for advertising. If the system was used a million times a day, $1 would buy nine exposures of the image per day in perpetuity. Or until someone decided to do an advert-free version. --000000000000ca1a1b05874d349e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Apr 24, 2019 at 2:01 PM Ben Laurie <benl@google.com> wrote:


On Wed, 24 Apr 2019 at 18:49, Phillip Hallam-Baker <phill@hallambaker.com&g= t; wrote:

=
The reason that t= he World Wide Web exists at all is that Tim Berners-Lee ignored the sage ad= vice of the hypertext community that referential transparency was essential= and pressed ahead with 'scruffy links'. Nobody did usability testi= ng to decide whether the gopher or Web UI was the approach to follow until = long after we knew the answer.

This is a clear case of survivorship bias. The users did the usabilit= y testing. WWW survived (despite being technically terrible in many ways), = the competitors did not.

=
The Web had 100 user= s in the fall of 1992 when it was first demonstrated in public. There were = at least two dozen competing network hypertext systems, most of which were = far better financed than the Web which had two full time staff at the time.=

Nine months later the We= b had over a million users and it was game over for every other network hyp= ertext scheme apart from Acrobat which had already begun merging itself wit= h the Web to survive.

The= re was rather more than survivor bias at work there. One of the biggest dif= ferences between the Web and everything else was that Eric Binna paid immen= se attention to the quality of his software distributions. He provided bina= ry distributions for a start and the code compiled from source.

We paid a g= reat deal of attention to usability but we never had the resources to test = any of it. There was never a testing lab at CERN for a start. Or at NCSA as= far as I am aware. Come to think of it, when VeriSign acquired the old Net= scape HQ, I pushed for the construction of a usability lab. Which means tha= t there wasn't one in the building when we moved in.

Right no= w, I have no means of knowing if an email from my bank is actually an email= from my bank or not. And that should be considered a problem. The problem = I have with discussions of usability is that the argument is made that beca= use we might not be able to serve every user we should just give up and nev= er try to change anything.

Well, the problem I have with discussions of usability is the argumen= t is made that we should leave that until all the tech is figured out, or t= hat we don't need to bother because the thing is obviously better. Goin= g from .1% to 1% is clearly an improvement, but it is not a solution.
=

Like I said, I am more than happy to accept input = on how to do UI better. But I am not going to be blocked on those resources= . At this point I have one employee and a seven figure budget. To start thi= nking about UI testing I need to have more developers and a bigger budget.<= /div>
=C2=A0
BTW, my original qu= estion was not about QR codes (though I have my doubts about those), but ab= out this assertion about usability: "Otherwise, there are many existin= g protocols that make comparison of 15-30 character base 32 encoded strings= as the basis for mutual authentication and these have proved effective and= acceptable."

I have entered product act= ivation keys and lived. Adobe managed to sell software with that requiremen= ts for decades. So they are not a show stopper for at least some part of th= e audience. I am requiring only comparison of two codes, not entry.

I accept that this is not the = ideal approach and in the spec I suggest using BASE32K encoding based on di= ctionaries of words or images. Since the connection mechanism only requires= comparison for equality, we don't have to be restricted to something t= hat can be entered on a keyboard. Images would be the ideal of course becau= se they can be language independent. 'Are these nine pictures the same&= #39; is a pretty easy question to answer. The work factor for the UDF appro= ach would be (9*15)-8 =3D 127. 2^127 is sufficient for most purposes. Compa= ring nine pictures for equality is relatively straightforward.

I haven't gone into this in detai= l as yet, but my rough strategy for managing the dictionaries is to

1) Sort the entries into a can= onical sort order
2) Form a Merkle tree of the result.
3) Publish the apex of the tree in some tamper-pro= of fashion.
This avoids t= he need to store the entire dictionary on every device which is important e= ven for unconstrained devices. The image dictionary is going to be huge and= word dictionaries have to be customized to the user's language.
<= div class=3D"gmail_default" style=3D"font-size:small">

It has not escaped my notice that I coul= d use this as a funding mechanism for the Mesh itself. The million dollar i= mage dictionary. Companies could pay to contribute images to the corpus, pa= rt of which could be reserved for advertising. If the system was used a mil= lion times a day, $1 would buy nine exposures of the image per day in perpe= tuity. Or until someone decided to do an advert-free version.

=C2=A0
--000000000000ca1a1b05874d349e-- From nobody Wed Apr 24 14:41:14 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40D17120351 for ; Wed, 24 Apr 2019 14:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qYUYA_Isegn for ; Wed, 24 Apr 2019 14:41:09 -0700 (PDT) Received: from mail-oi1-f177.google.com (mail-oi1-f177.google.com [209.85.167.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1381612034F for ; Wed, 24 Apr 2019 14:41:09 -0700 (PDT) Received: by mail-oi1-f177.google.com with SMTP id l12so4638067oie.13 for ; Wed, 24 Apr 2019 14:41:09 -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=42Xl2yWXOXFRv4Im1zYCCjT03iiZR4b2SOYQuSNi+DM=; b=RPTuwDwItzmfooET+cbbCZX7Ksn+tdBW0ef0hhmsbf1nGBqBchKUKFFjukRKrAuj05 TUjRYd7P5zZhYhPQW8hrZdkMporHIWd63udBWQoF64zhmfvfQVNoJRm+WfhPFSOxGT/W 9ToKnSjyJXdlRT765JMTP+HLnBSe1eu2d4taMuifWa1Paqxyx0Y90Th65BIx4enwCPR/ 742cm1vk0A5jBlRz+k79gq+QKWX8b/u2Aqr0K8JMwpk2Exr891y9Ua0XqfTL1hTDGYov XcCMiAm+GGU8YdBsWCUcFZMi2OQoMFJTIJd9BzODYrDmSKHeRqAHk1p8CnOhIBC5zQ5x SIug== X-Gm-Message-State: APjAAAWFhiSfN125SWe2kGB277n8deBKhplU9PnJxS36+Fws9zjDVwxm vaE/qBA9XC55MmGmkWoQKjuKfIrjsVuGPzD6wdZSpA== X-Google-Smtp-Source: APXvYqxSGKq5RM9CNd4vh+wF3jIgMV4TbalUWddVb8ItfIdi97o/WuuPsM5yGtieczh4mYOTodmt8/75elX8xr24AvE= X-Received: by 2002:aca:43d5:: with SMTP id q204mr911566oia.100.1556142068327; Wed, 24 Apr 2019 14:41:08 -0700 (PDT) MIME-Version: 1.0 References: <20190424182641.GL3137@localhost> In-Reply-To: <20190424182641.GL3137@localhost> From: Phillip Hallam-Baker Date: Wed, 24 Apr 2019 17:40:58 -0400 Message-ID: To: Nico Williams Cc: IETF SAAG Content-Type: multipart/alternative; boundary="00000000000033e97b05874d8f19" Archived-At: Subject: Re: [saag] Direct trust between users X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 21:41:12 -0000 --00000000000033e97b05874d8f19 Content-Type: text/plain; charset="UTF-8" On Wed, Apr 24, 2019 at 2:26 PM Nico Williams wrote: > On Wed, Apr 24, 2019 at 01:56:40PM -0400, Phillip Hallam-Baker wrote: > > So we have an assertion that my public key is MC23-... dated 2019-Jul-18. > > It would have cost $1000 to forge that assertion before that date and > > $infinity to forge afterwards. > > ISTM that it's $1000 (or whatever) the first and _every_ time. That's > because the blockchain will have to support the "help, I've lost my one > and only device!" or "help, I've lost all my devices!" cases. > It would be if I had not designed the Mesh key management system to address precisely that type of issue. There are some constraints I cannot escape. If I provide you with a guarantee that you will be able to recover your keys in all possible circumstances I must also expose you to the risk of coerced disclosure of your key. I cannot eliminate such choices but I can mitigate them and I can give the choice to the user rather than to me. It is not my place to decide what my user's security concerns are for them. My security concerns are not the same as most people's. > E.g., you're on a plane that lands on the Hudson river and you have to > leave everything behind, including your laptop, tablet, and phone, and > you're thousands of miles away from your desktop device or backups. > Now, you could just cancel everything and fly home (after drying up > anyways), but this may be very costly in time and money so you probably > won't want to. > OK so there is the approach in the docs and there is the improved approach I am thinking about that uses key co-generation that I have not yet implemented. Basically, the Mesh has always allowed users to escrow their long term master signature key. This is precisely because the cost of this type of loss is unacceptable. I do not used the disk encryption features on any of my machines at present because I do not trust the key recovery systems and the loss of my data is far more of a concern to me than disclosure. So the revised version I am considering is that instead of escrowing the user's master signature key, I generate a new master key, escrow that. and sign it in the master profile. This means that I can regain control of the account if I lose my master signature key but the fact that I have done this will be visible because I will have to post a new Master profile. > The simplest user experience to implement would be to have an app for > > mobile devices that can be used to scan a dynamic QR code presented on a > > screen near the registration desk. This would provide the necessary > crypto > > info to complete the key signing. > > We're assuming trusted devices, but we practically have to anyways, so, > sure. > Given enough epicycles, I can save this appearance. As a matter of course, every interaction can be traced to an individual device by the owner of the profile. At present the interactions can be traced back to a device by everyone else as well and I am not sure that I like that. I have one scheme in mind that can mitigate that but I really need some crypto folk to advise. > > We could go further and make it so that scanning the QR code tells the > > attendee which line to join and causes the registration staff to be told > > which badges to find next. The registration staff could then check > > government issued ID, hand over the badge and tell the system the ID > > matched. > > The ID check is not going to be that good. As with PGP, having > something of a key signing party where people who know you vouch for you > (and vice-versa) seems better. This is where a notion of security level > starts creeping in: do I trust the IETF registrar more than I trust an > IETF participant I've known for decades? If I do take the registrar's > say-so at face value and have N>100 interactions with you where I have > every reason to think it's you every time, does the security level go > up, and do I get to say that or does it happen automatically? > What I sketched out is a validation process. Just as we have multiple validation processes for WebPKI certificates, we can have multiple validation processes for this as well. And the assertions produced can specify the validation process that was followed. Conference registration desk is one place we could validate. The reception is another. And if you think about it, going round bumping phones to exchange contacts sounds a bit like an ice-breaker activity. If we were going to apply this outside the tech community, the validation process is going to have to be run by someone who knows what they are doing. They will in effect be a cyber notary. And if someone was going to do this at an ABA meeting, they would want to charge them for it. Bigly. And if it provided value, the ABA would want to pay. One of the reasons SSL/TLS took off and other Internet security protocols did not was that there was an industry that was invested in making it take off and marketing the use of crypto. They got greedy when it got to S/MIME but the WebPKI worked. If I train a hundred people to work as conference cybernotaries they would 1) provide some quality control and 2) spend time cold calling conference organizers offering to provide the service. --00000000000033e97b05874d8f19 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Apr 24, 2019 at 2:26 PM Nico Williams <nico@cryptonector.com> wrote:
On Wed, Apr 24, 2019 at 01:56:40PM -0400, Phillip Hallam-Baker w= rote:
> So we have an assertion that my public key is MC23-... dated 2019-Jul-= 18.
> It would have cost $1000 to forge that assertion before that date and<= br> > $infinity to forge afterwards.

ISTM that it's $1000 (or whatever) the first and _every_ time.=C2=A0 Th= at's
because the blockchain will have to support the "help, I've lost m= y one
and only device!" or "help, I've lost all my devices!" c= ases.

It would be if I had not designed the Mesh key manage= ment system to address precisely that type of issue.

There are some constra= ints I cannot escape. If I provide you with a guarantee that you will be ab= le to recover your keys in all possible circumstances I must also expose yo= u to the risk of coerced disclosure of your key.=C2=A0

I cannot eliminate such choices but I can mit= igate them and I can give the choice to the user rather than to me. It is n= ot my place to decide what my user's security concerns are for them. My= security concerns are not the same as most people's.

=C2=A0
E.g., you're on a plane that lands on the Hudson river and you have to<= br> leave everything behind, including your laptop, tablet, and phone, and
you're thousands of miles away from your desktop device or backups.
Now, you could just cancel everything and fly home (after drying up
anyways), but this may be very costly in time and money so you probably
won't want to.

OK so there is the approach in the docs = and there is the improved approach I am thinking about that uses key co-gen= eration that I have not yet implemented.

Basically, the Mesh has always allowed users to escrow thei= r long term master signature key. This is precisely because the cost of thi= s type of loss is unacceptable. I do not used the disk encryption features = on any of my machines at present because I do not trust the key recovery sy= stems and the loss of my data is far more of a concern to me than disclosur= e.

So the revised version= I am considering is that instead of escrowing the user's master signat= ure key, I generate a new master key, escrow that. and sign it in the maste= r profile. This means that I can regain control of the account if I lose my= master signature key but the fact that I have done this will be visible be= cause I will have to post a new Master profile.

> The simplest user experience to = implement would be to have an app for
> mobile devices that can be used to scan a dynamic QR code presented on= a
> screen near the registration desk. This would provide the necessary cr= ypto
> info to complete the key signing.

We're assuming trusted devices, but we practically have to anyways, so,=
sure.

Given enough epicycles, I can save this appearance.

As a matter of course, eve= ry interaction can be traced to an individual device by the owner of the pr= ofile. At present the interactions can be traced back to a device by everyo= ne else as well and I am not sure that I like that. I have one scheme in mi= nd that can mitigate that but I really need some crypto folk to advise.
=C2=A0
> We could go further and make it so that scanning the QR code tells the=
> attendee which line to join and causes the registration staff to be to= ld
> which badges to find next. The registration staff could then check
> government issued ID, hand over the badge and tell the system the ID > matched.

The ID check is not going to be that good.=C2=A0 As with PGP, having
something of a key signing party where people who know you vouch for you (and vice-versa) seems better.=C2=A0 This is where a notion of security lev= el
starts creeping in: do I trust the IETF registrar more than I trust an
IETF participant I've known for decades?=C2=A0 If I do take the registr= ar's
say-so at face value and have N>100 interactions with you where I have every reason to think it's you every time, does the security level go up, and do I get to say that or does it happen automatically?

What I sketched out is a validation process. Just as we have multiple va= lidation processes for WebPKI certificates, we can have multiple validation= processes for this as well. And the assertions produced can specify the va= lidation process that was followed.

Conference registration desk is one place we could validate. The= reception is another. And if you think about it, going round bumping phone= s to exchange contacts sounds a bit like an ice-breaker activity.=C2=A0


If we were going to apply this outside= the tech community, the validation process is going to have to be run by s= omeone who knows what they are doing. They will in effect be a cyber notary= . And if someone was going to do this at an ABA meeting, they would want to= charge them for it. Bigly. And if it provided value, the ABA would want to= pay.

One of the reasons = SSL/TLS took off and other Internet security protocols did not was that the= re was an industry that was invested in making it take off and marketing th= e use of crypto. They got greedy when it got to S/MIME but the WebPKI worke= d. If I train a hundred people to work as conference cybernotaries they wou= ld 1) provide some quality control and 2) spend time cold calling conferenc= e organizers offering to provide the service.

--00000000000033e97b05874d8f19-- From nobody Wed Apr 24 16:33:49 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A90CC12018F for ; Wed, 24 Apr 2019 16:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 AbRzyRZhFUM4 for ; Wed, 24 Apr 2019 16:33:45 -0700 (PDT) Received: from ladybird.maple.relay.mailchannels.net (ladybird.maple.relay.mailchannels.net [23.83.214.98]) (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 192FB12013E for ; Wed, 24 Apr 2019 16:33:44 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id DFFCD12545E; Wed, 24 Apr 2019 23:33:43 +0000 (UTC) Received: from pdx1-sub0-mail-a99.g.dreamhost.com (unknown [100.96.11.48]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 5ED06125475; Wed, 24 Apr 2019 23:33:43 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a99.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Wed, 24 Apr 2019 23:33:43 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Industry-Arithmetic: 77f6addb3ef078c3_1556148823674_1466975413 X-MC-Loop-Signature: 1556148823673:480483661 X-MC-Ingress-Time: 1556148823673 Received: from pdx1-sub0-mail-a99.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a99.g.dreamhost.com (Postfix) with ESMTP id DE4DF7FEC6; Wed, 24 Apr 2019 16:33:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=CFbsGY1iorOaL4 mGabprYKc5b4U=; b=Iz86WQmorFR7gHiDP3//q2uT5Lx8Lil20qOD1SX5AvlD/G phrbakrJgjJlEnDr3LrudYsIYaD8gq/FyC8Ab7x58BfrOsxB2LxwAEDJGT9hu0Xn JoxQmlNMEBLNlVmzAJje7kwXhRu7l4bGd/xNPuQYMGFN9tyJ5YaKIMFIVZdXQ= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a99.g.dreamhost.com (Postfix) with ESMTPSA id 77C8C7FED6; Wed, 24 Apr 2019 16:33:41 -0700 (PDT) Date: Wed, 24 Apr 2019 18:33:39 -0500 X-DH-BACKEND: pdx1-sub0-mail-a99 From: Nico Williams To: Phillip Hallam-Baker Cc: IETF SAAG Message-ID: <20190424233338.GP3137@localhost> References: <20190424182641.GL3137@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrheefgddvvdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd Archived-At: Subject: Re: [saag] Direct trust between users X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 23:33:48 -0000 On Wed, Apr 24, 2019 at 05:40:58PM -0400, Phillip Hallam-Baker wrote: > On Wed, Apr 24, 2019 at 2:26 PM Nico Williams wrote: > > ISTM that it's $1000 (or whatever) the first and _every_ time. That's > > because the blockchain will have to support the "help, I've lost my one > > and only device!" or "help, I've lost all my devices!" cases. > > It would be if I had not designed the Mesh key management system to address > precisely that type of issue. > > There are some constraints I cannot escape. If I provide you with a > guarantee that you will be able to recover your keys in all possible > circumstances I must also expose you to the risk of coerced disclosure of > your key. Indeed. > I cannot eliminate such choices but I can mitigate them and I can give the > choice to the user rather than to me. It is not my place to decide what my > user's security concerns are for them. My security concerns are not the > same as most people's. For most users recovery is more important than non-coercibility, especially since non-coercibility can only be had in the all-devices- lost-or-destroyed scenario. > > E.g., you're on a plane that lands on the Hudson river and you have to > > leave everything behind, including your laptop, tablet, and phone, and > > you're thousands of miles away from your desktop device or backups. > > Now, you could just cancel everything and fly home (after drying up > > anyways), but this may be very costly in time and money so you probably > > won't want to. > > OK so there is the approach in the docs and there is the improved approach > I am thinking about that uses key co-generation that I have not yet > implemented. > > Basically, the Mesh has always allowed users to escrow their long term > master signature key. This is precisely because the cost of this type of > loss is unacceptable. I do not used the disk encryption features on any of > my machines at present because I do not trust the key recovery systems and > the loss of my data is far more of a concern to me than disclosure. > > So the revised version I am considering is that instead of escrowing the > user's master signature key, I generate a new master key, escrow that. and > sign it in the master profile. This means that I can regain control of the > account if I lose my master signature key but the fact that I have done > this will be visible because I will have to post a new Master profile. It will be visible because you'll _use_ the new master key (you might not elect to post a new new master key). > > The simplest user experience to implement would be to have an app for > > > mobile devices that can be used to scan a dynamic QR code presented on a > > > screen near the registration desk. This would provide the necessary > > crypto > > > info to complete the key signing. > > > > We're assuming trusted devices, but we practically have to anyways, so, > > sure. > > Given enough epicycles, I can save this appearance. It was just Security Considerations material, not an exhortation to do better (you can't). > As a matter of course, every interaction can be traced to an individual > device by the owner of the profile. At present the interactions can be > traced back to a device by everyone else as well and I am not sure that I > like that. I have one scheme in mind that can mitigate that but I really > need some crypto folk to advise. Anonymity and pseudonymity can be version 2 features. In fact, pseudonymity can be had immediately by allowing the user to have multiple distinct key sets, and even overlapping device sets. Anonymity can then take the form of ephemeral pseudonyms, perhaps, though since the whole point is to be able to securely communicate *more than once*... anonymity can't really be had! We can't reduce the metadata footprint of communicating users, not really (sure, users can go use onion routing, but good luck with that). I'm not too concerned about traceability, though it is a Security Consideratum. > > > We could go further and make it so that scanning the QR code tells the > > > attendee which line to join and causes the registration staff to be told > > > which badges to find next. The registration staff could then check > > > government issued ID, hand over the badge and tell the system the ID > > > matched. > > > > The ID check is not going to be that good. As with PGP, having > > something of a key signing party where people who know you vouch for you > > (and vice-versa) seems better. This is where a notion of security level > > starts creeping in: do I trust the IETF registrar more than I trust an > > IETF participant I've known for decades? If I do take the registrar's > > say-so at face value and have N>100 interactions with you where I have > > every reason to think it's you every time, does the security level go > > up, and do I get to say that or does it happen automatically? > > > > What I sketched out is a validation process. Just as we have multiple > validation processes for WebPKI certificates, we can have multiple > validation processes for this as well. And the assertions produced can > specify the validation process that was followed. And validators get sloppy. The point is that while you want a simple UI, the moment you look into a range of trust, the UI gets more complex. It may be that a boolean is all we can really hope to get. Perhaps you can hide a range (and details) behind the boolean indicator. What's the right answer? I don't know, but I do like the idea that regardless of how you hopped onto the mesh, once we've had a bunch of interactions I can then say I trust you more than I could have trusted any ID validation you went through at enrolment time. > Conference registration desk is one place we could validate. The reception > is another. And if you think about it, going round bumping phones to > exchange contacts sounds a bit like an ice-breaker activity. Definitely. For the tech community conferences as a incidental key signing parties can be a tremendous facilitator; with network effects you should be able to get a huge number of users very quickly. It just has to be trivial to install the app and enrol. (Eventually this really needs to be a function of the device's OS, and you'll need to be able to let third party apps use (but not see) the keys.) Conferences would be the obvious place to start advertising this. > If we were going to apply this outside the tech community, the validation > process is going to have to be run by someone who knows what they are > doing. They will in effect be a cyber notary. And if someone was going to > do this at an ABA meeting, they would want to charge them for it. Bigly. > And if it provided value, the ABA would want to pay. With an option for non-meatspace identity the cost goes to zero, but you have to accept TOFU or WebPKI / DANE introducers. E.g., if I send you email signed with a key whose certificate is issued by my domain and which is issued by a WebPKI CA and/or is published in a TLSA RR in DNS(SEC) then you can be reasonably certain that the email came from a device that is authorized to send email with that sender address. Even in a TOFU case, if one peer is non-TOFU then a couple of round trips should suffice to bind the device set keys to the TOFU peer's address in an MITM-proof way. The TOFU peer might be an impersonator, but over a long period of time and after many interactions you can conclude that they are not being impersonated. > One of the reasons SSL/TLS took off and other Internet security protocols > did not was that there was an industry that was invested in making it take > off and marketing the use of crypto. They got greedy when it got to S/MIME > but the WebPKI worked. If I train a hundred people to work as conference > cybernotaries they would 1) provide some quality control and 2) spend time > cold calling conference organizers offering to provide the service. I'm a bit skeptical about notaries. Long long ago I used to imagine the U.S. postal service selling what you might call EV user certificates: after all, there are post offices everywhere and their staff are trained in validating government-issued IDs, often they're even notaries public! I supposed one might even be able to get attribute certs attesting that the holder of the key is, e.g., a citizen, or over 18 years of age. Another likely candidate, one that is perhaps easier to get involved, though they are not as convenient for users, is the DMV... But why did this not happen?? Did anyone even try? Would you? How would one make it happen? How much can be done without having to hire a lobbyist to lobby Congress or 50 State legislatures? Has this been done outside the U.S.? If so, was it a success? If so, can that be used to make it happen elsewhere? For example, suppose you gave away to the postal service cheap devices for use at post offices for the purpose of enrolling users, then let the postal service charge a fee for providing the service, with you keeping either a nominal portion or even none of the fee. What would be the legal barriers to making that happen? Upside: you won't need to train their employees in how to validate IDs. Downside: risks being more of a political than business relationship. Nico -- From nobody Wed Apr 24 16:49:50 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B203120478 for ; Wed, 24 Apr 2019 16:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txDmuu6cSelx for ; Wed, 24 Apr 2019 16:49:46 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE7D012046D for ; Wed, 24 Apr 2019 16:49:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 49D50BE7B; Thu, 25 Apr 2019 00:49:43 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTO6oepkWKgH; Thu, 25 Apr 2019 00:49:42 +0100 (IST) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DB8E7BE50; Thu, 25 Apr 2019 00:49:41 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1556149781; bh=KZOZLBFOyVwtx9qRlWvjH4L8hTzRgc/ctjWdaDrlH0s=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Cjr6P0BjGomjUyQONhBxyWCe9wGjIGbLf+2sLMakFDRtGlaAUQXWCjWER2BXBowL0 Rq6zIaNEM8XiYFv5gs0RQoT6rQyyRxvxSbBVGGWSMRXT886pfQ7X6ZE8a52cRoyPuF fsrW7gQ69E3dmjc+FXkKbXExvrsCukFuSDQG7w84= To: Nico Williams Cc: IETF SAAG References: <20190424182641.GL3137@localhost> <20190424233338.GP3137@localhost> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <50e8ec99-9d2c-bdcc-d906-03288a7a50eb@cs.tcd.ie> Date: Thu, 25 Apr 2019 00:49:40 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190424233338.GP3137@localhost> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="MT7bMQnRLzxQaXM8BSooANA9TGXGR4IyC" Archived-At: Subject: Re: [saag] Direct trust between users X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 23:49:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MT7bMQnRLzxQaXM8BSooANA9TGXGR4IyC Content-Type: multipart/mixed; boundary="g8l0pxvtHO7vkoQEeKH9wP9mxQwElbAok"; protected-headers="v1" From: Stephen Farrell To: Nico Williams Cc: IETF SAAG Message-ID: <50e8ec99-9d2c-bdcc-d906-03288a7a50eb@cs.tcd.ie> Subject: Re: [saag] Direct trust between users References: <20190424182641.GL3137@localhost> <20190424233338.GP3137@localhost> In-Reply-To: <20190424233338.GP3137@localhost> --g8l0pxvtHO7vkoQEeKH9wP9mxQwElbAok Content-Type: multipart/mixed; boundary="------------DFB665348DB05D5E34130868" Content-Language: en-GB This is a multi-part message in MIME format. --------------DFB665348DB05D5E34130868 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Just on this point: On 25/04/2019 00:33, Nico Williams wrote: > sure, users can go use onion routing, but good luck with that Loading [1] (which is the local "newspaper of record") just now: - via FF with NoScript and other blockers: 5.12 seconds - via Tor browser bundle (TBB), default settings: 10.24 seconds - via Chromium with out of the box settings 12+ seconds (JS+ads kept it spinning 'till 15s in fact but that was just ads changing I think) Timings are rough, just as shown by n/w debugger UI. But this is consistent with other occasions on which I've measured. ISTM that onion routing is less bad, performance wise, than accepting JS/advertising and tracking. I've started encouraging my students to try TBB and consider using it when doing e.g. health related searches or whatever they'd prefer not be correlated with all the other horrendous amounts of data on them slurped up by mega-providers. Cheers, S. [1] https://irishtimes.com/ --------------DFB665348DB05D5E34130868 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------DFB665348DB05D5E34130868-- --g8l0pxvtHO7vkoQEeKH9wP9mxQwElbAok-- --MT7bMQnRLzxQaXM8BSooANA9TGXGR4IyC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlzA9hQACgkQWrL68XsX K+pF2hAAoyTONTY981PE3SY2eVXKoDmsM2ygPk/IRZ36WR8Xi8oe5WNmjiw8pJ+E ordzeHUMYuLi1n/Yrh9+ERGszTWcZcaONOk2M/CCFX1wYuqD8ktYTjjE+OdFLxux r2V2oIBXdgAIreuob5P6jKEgh4eS0TDxZzkXoeGy9mn3Mts592Ur+2qk2dcOqWiB x3SdsZgFZ/obj3i5/kp4t8x0/iY27tcwuuMH2p8kJOty5WKAS/fFNy0ZuBLPakeO 5k48UbCN6zIqZM7vUnPlNq/06zO1hK0BV56RZvb7vPcFCbMhEyB9VQIF1u+ki68q D4wAwz5YDvY7yh2ZuUE+XYxyXfhpEl/BOvpXoq+uyJU0ir+GmM5JD0VBNRNNGUS0 WJVwHZeUZYwBo1cxHvECvgDtuys/q9tKXl590EAXH7lfFNi6PE2RMwBawnTLalc2 haLJ6kUcIyEC/pUyAhYJ3tsaaQ/AAo/8FyYuhKbyTpcP3nsrHxiZgbd+vECONQYF Lobo28GkPgRwdptJHz96QRiOvpAfPu53gL5wN74PcVSclHN/yrIrrYot8CJHgPw+ ZWrz2BTTLUjVXD0pm85Du6d22ivWBi1tHG0rCiWlSJ9X18YPouMrAV5OmKjV74dQ ipODiOZYuoyFbnjzPiMEOybMZqBm1fsCqwfpUj+Akm8XBcENrW0= =evmx -----END PGP SIGNATURE----- --MT7bMQnRLzxQaXM8BSooANA9TGXGR4IyC-- From nobody Wed Apr 24 17:16:14 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDF6712047D for ; Wed, 24 Apr 2019 17:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJtdHEUxENuf for ; Wed, 24 Apr 2019 17:16:11 -0700 (PDT) Received: from mail-oi1-f172.google.com (mail-oi1-f172.google.com [209.85.167.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D3321201D4 for ; Wed, 24 Apr 2019 17:16:11 -0700 (PDT) Received: by mail-oi1-f172.google.com with SMTP id v10so15770428oib.1 for ; Wed, 24 Apr 2019 17:16:11 -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=P+QUl9lb7mt4lDyWIxrzDkK9UsLQjlxdaU2tK0NLyTI=; b=Vdy1KceQ7lGoSpK7wJcxQjArPYgsuRN1eWevJP+nIWu2Cbkq2Atpj1H90n4OnCN+p2 rWr0Q5eTYD2mnLEslKiODw+yXeUByx7yUgIhKn8xsjCGxAY143lYoqerI0R7QkQTsGeB ZZVIWIedqZYBbKH0RPYzMG+P2pKBfBnkjRF11qssNFm7D2PGdmjzCkFtS4z0hE026GO3 V8vFhDO+GT5PLP9CjBr8+AGq0cRIkYas2HrcS81dnurZuGEWKsHg9pF53wnYddHELwOV ZEQRpNruV2GRHQXMU35M4NT5F+jfODC6poaWxMmUSGf9BfyXVZwuXJeS6fb65y+coxOd oexA== X-Gm-Message-State: APjAAAWx80byDUL3pztrkTqbRdSiFU/nF/2a7MBoAn5zviyWaRxkcytk a6eHlgOzKwFfRXajvem4dW85HlF9Ohp1PvBrOEU= X-Google-Smtp-Source: APXvYqwUh/qVBZlNpabAwb+1mGlJKjZ1qFQXURc7BSMpz7GTX1yGR+cPSyXbHEK3XbjGFB29ioRVfL02PN/lOUiHS44= X-Received: by 2002:aca:5a89:: with SMTP id o131mr1316214oib.17.1556151370550; Wed, 24 Apr 2019 17:16:10 -0700 (PDT) MIME-Version: 1.0 References: <20190424182641.GL3137@localhost> <20190424233338.GP3137@localhost> <50e8ec99-9d2c-bdcc-d906-03288a7a50eb@cs.tcd.ie> In-Reply-To: <50e8ec99-9d2c-bdcc-d906-03288a7a50eb@cs.tcd.ie> From: Phillip Hallam-Baker Date: Wed, 24 Apr 2019 20:15:59 -0400 Message-ID: To: Stephen Farrell Cc: Nico Williams , IETF SAAG Content-Type: multipart/alternative; boundary="000000000000a8920105874fb958" Archived-At: Subject: Re: [saag] Direct trust between users X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2019 00:16:13 -0000 --000000000000a8920105874fb958 Content-Type: text/plain; charset="UTF-8" On Wed, Apr 24, 2019 at 7:50 PM Stephen Farrell wrote: > > Just on this point: > > On 25/04/2019 00:33, Nico Williams wrote: > > sure, users can go use onion routing, but good luck with that > > Loading [1] (which is the local "newspaper of record") just > now: > > - via FF with NoScript and other blockers: 5.12 seconds > - via Tor browser bundle (TBB), default settings: 10.24 seconds > - via Chromium with out of the box settings 12+ seconds > (JS+ads kept it spinning 'till 15s in fact but that was > just ads changing I think) > > Timings are rough, just as shown by n/w debugger UI. But > this is consistent with other occasions on which I've > measured. > > ISTM that onion routing is less bad, performance wise, than > accepting JS/advertising and tracking. > > I've started encouraging my students to try TBB and consider > using it when doing e.g. health related searches or whatever > they'd prefer not be correlated with all the other horrendous > amounts of data on them slurped up by mega-providers. > Onion routing for Web content is tricky because it can be MB Email is potentially easier as most messages are short unless they have attachments. So if we restrict messages to 64KB in size and require anything larger to be sent as an attachment, we can make quite a bit of headway. --000000000000a8920105874fb958 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Apr 24, 2019 at 7:50 PM Stephen Farrell <= ;stephen.farrell@cs.tcd.ie= > wrote:

Just on this point:

On 25/04/2019 00:33, Nico Williams wrote:
> sure, users can go use onion routing, but good luck with that

Loading [1] (which is the local "newspaper of record") just
now:

- via FF with NoScript and other blockers: 5.12 seconds
- via Tor browser bundle (TBB), default settings: 10.24 seconds
- via Chromium with out of the box settings 12+ seconds
=C2=A0 (JS+ads kept it spinning 'till 15s in fact but that was
=C2=A0 just ads changing I think)

Timings are rough, just as shown by n/w debugger UI. But
this is consistent with other occasions on which I've
measured.

ISTM that onion routing is less bad, performance wise, than
accepting JS/advertising and tracking.

I've started encouraging my students to try TBB and consider
using it when doing e.g. health related searches or whatever
they'd prefer not be correlated with all the other horrendous
amounts of data on them slurped up by mega-providers.
=
Onion= routing for Web content is tricky because it can be MB

Email is potential= ly easier as most messages are short unless they have attachments. So if we= restrict messages to 64KB in size and require anything larger to be sent a= s an attachment, we can make quite a bit of headway.

--000000000000a8920105874fb958-- From nobody Wed Apr 24 17:30:41 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C23201200BA for ; Wed, 24 Apr 2019 17:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8JukLmw6-Nt8 for ; Wed, 24 Apr 2019 17:30:38 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B6D61200B9 for ; Wed, 24 Apr 2019 17:30:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8AAA0BE7B; Thu, 25 Apr 2019 01:21:32 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1Ic3dfEleLS; Thu, 25 Apr 2019 01:21:17 +0100 (IST) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 11ABBBE20; Thu, 25 Apr 2019 01:21:17 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1556151677; bh=TvIyO5NLIwfW+9PUJXynjvoSVh2ORh7+icFKmcBbDJ4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=WxQUI4sOkdgJAfpxD6Xk8FR5DpkaOVClGEwVWE4GeXfa3LSQEyWauS5rXCiVQwimj KaFhM7f3U21jL/ieoyvjt3SX0y4OOPGIw0zDkCeY0c7s1O9tqD4sgQJDf/FHzBG03u mqmAH5WHqXiYAmgUTFfWDcyRl52Q0RHXki0NKyEI= To: Phillip Hallam-Baker Cc: Nico Williams , IETF SAAG References: <20190424182641.GL3137@localhost> <20190424233338.GP3137@localhost> <50e8ec99-9d2c-bdcc-d906-03288a7a50eb@cs.tcd.ie> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <3e1dd0c7-f45b-3269-5c9f-f99072542195@cs.tcd.ie> Date: Thu, 25 Apr 2019 01:21:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="SNCFjJY6jpWiKefbjphFbwQ52H9kmJAo4" Archived-At: Subject: Re: [saag] Direct trust between users X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2019 00:30:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --SNCFjJY6jpWiKefbjphFbwQ52H9kmJAo4 Content-Type: multipart/mixed; boundary="0BcfgJ9GF0aaM6MPcb7PW3IRHliNng2va"; protected-headers="v1" From: Stephen Farrell To: Phillip Hallam-Baker Cc: Nico Williams , IETF SAAG Message-ID: <3e1dd0c7-f45b-3269-5c9f-f99072542195@cs.tcd.ie> Subject: Re: [saag] Direct trust between users References: <20190424182641.GL3137@localhost> <20190424233338.GP3137@localhost> <50e8ec99-9d2c-bdcc-d906-03288a7a50eb@cs.tcd.ie> In-Reply-To: --0BcfgJ9GF0aaM6MPcb7PW3IRHliNng2va Content-Type: multipart/mixed; boundary="------------ED7D444CFC46C51AE8E4FE11" Content-Language: en-GB This is a multi-part message in MIME format. --------------ED7D444CFC46C51AE8E4FE11 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 25/04/2019 01:15, Phillip Hallam-Baker wrote: > On Wed, Apr 24, 2019 at 7:50 PM Stephen Farrell > wrote: >=20 >> >> Just on this point: >> >> On 25/04/2019 00:33, Nico Williams wrote: >>> sure, users can go use onion routing, but good luck with that >> >> Loading [1] (which is the local "newspaper of record") just >> now: >> >> - via FF with NoScript and other blockers: 5.12 seconds >> - via Tor browser bundle (TBB), default settings: 10.24 seconds >> - via Chromium with out of the box settings 12+ seconds >> (JS+ads kept it spinning 'till 15s in fact but that was >> just ads changing I think) >> >> Timings are rough, just as shown by n/w debugger UI. But >> this is consistent with other occasions on which I've >> measured. >> >> ISTM that onion routing is less bad, performance wise, than >> accepting JS/advertising and tracking. >> >> I've started encouraging my students to try TBB and consider >> using it when doing e.g. health related searches or whatever >> they'd prefer not be correlated with all the other horrendous >> amounts of data on them slurped up by mega-providers. >> >=20 > Onion routing for Web content is tricky because it can be MB Huh? The out of the box browser (chromium in the above) is *slower* and (far) less privacy friendly than Tor. It's only with a weirdly configured browser (FF+NoScript) that you do much better, and sadly that weird configuration is itself also a privacy leak. Tor used be very very slow. The crap that ads have added to the web means that Tor browser bundle now seems to be quicker. Cheers, S. >=20 > Email is potentially easier as most messages are short unless they have= > attachments. So if we restrict messages to 64KB in size and require > anything larger to be sent as an attachment, we can make quite a bit of= > headway. >=20 --------------ED7D444CFC46C51AE8E4FE11 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------ED7D444CFC46C51AE8E4FE11-- --0BcfgJ9GF0aaM6MPcb7PW3IRHliNng2va-- --SNCFjJY6jpWiKefbjphFbwQ52H9kmJAo4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlzA/XoACgkQWrL68XsX K+rOvhAAzbUqfy9E8KAHkDceXL1jR8SBBgUowDG9TpQ0Sitk0N4RmsYpMnTQL78D wE83OlRYjpDZkCddgbuyjz7xNYAz31lXX3YKKqKbV55AUo4mci0ybO/FhciLW8GP 1zsgm/y34Bu0pXN7+56XhPuRgcI9DhxNKVirnf0XlFBMrPUcfGi9OFW8LU1V9Urn 2DhCTfzQtdce5m2b3gOO+TpnTsEU5RLnV9shZhPfXkOZS0MlSfdbXaowiG/lF3FP suMq8iDh5iztgW+BZNXWHLPZIbq6Lq20fszR5UiE8nu4+yiWKv8OSvdkj+4UOlRB su73S+UXXPlVCZ6SlgHH/hUgbJo93ly+3XQ12Tiv5RPwYhgYWa/KtUVAGp5PmSew qn2lYTwraHp9cS7m1DJB2IGd2PyvuEHatfZuNhPG4JmkUWikRUAa6jcUtRh+pX61 qXENvr9/xiJREUT1yosbAwszFvz5oyv620kttswCftvGVNN2jc22o8hhw9Jtz5b0 tTELdupa+yKU9Mr58+fs+tYCmB5pYAuLtmDRVE17KrBbREIdg9Wf/7HShtYUlMJD /blnaCrqVYevo8DULKoYeDD6ZWh6pQDUgRPTOTVyhpR1W7i2n1zPab4lAUFldz7i v4ZmDzgzdirSozip/OYdUSAAk+ZkXV68641OWKuafnEnH8reVFA= =5Bcn -----END PGP SIGNATURE----- --SNCFjJY6jpWiKefbjphFbwQ52H9kmJAo4-- From nobody Thu Apr 25 08:48:30 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 132BC1203D5 for ; Thu, 25 Apr 2019 08:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncDQOqf0tWTR for ; Thu, 25 Apr 2019 08:48:14 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 490A41202FE for ; Thu, 25 Apr 2019 08:48:02 -0700 (PDT) Received: from dooku.sandelman.ca (ipv6.dooku.sandelman.ca [IPv6:2607:f0b0:f:6::1]) by relay.sandelman.ca (Postfix) with ESMTPS id EA20B1F457; Thu, 25 Apr 2019 15:48:00 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 44C3F184B; Thu, 25 Apr 2019 11:48:11 -0400 (EDT) From: Michael Richardson To: Nico Williams cc: Phillip Hallam-Baker , IETF SAAG In-reply-to: <20190424233338.GP3137@localhost> References: <20190424182641.GL3137@localhost> <20190424233338.GP3137@localhost> Comments: In-reply-to Nico Williams message dated "Wed, 24 Apr 2019 18:33:39 -0500." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Thu, 25 Apr 2019 11:48:11 -0400 Message-ID: <16119.1556207291@dooku.sandelman.ca> Archived-At: Subject: Re: [saag] Direct trust between users X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2019 15:48:28 -0000 --=-=-= Content-Type: text/plain Nico Williams wrote: > Long long ago I used to imagine the U.S. postal service selling what > you might call EV user certificates: after all, there are post offices > everywhere and their staff are trained in validating government-issued > IDs, often they're even notaries public! I supposed one might even be > able to get attribute certs attesting that the holder of the key is, > e.g., a citizen, or over 18 years of age. Canada Post had a key in the browser list for a decade or so, and there was some project with Entrust to do something, but I don't think it ever happened. I also don't understand why I have a scanned PDF from ic.gc.ca as a corporate identity, and not a PKIX certificate. They've had all the software to the PKIX key for 20+ years. The post-office is unique in that it can get a letter to many people within 24h, rather cheaply, and I keep thinking that this is a better 2FA (or 3FA) for account recovery. > But why did this not happen?? Did anyone even try? Would you? How > would one make it happen? How much can be done without having to hire > a lobbyist to lobby Congress or 50 State legislatures? Has this been > done outside the U.S.? If so, was it a success? If so, can that be > used to make it happen elsewhere? Canada Post is among the most technologically incompetent organizations ever. They are captive for big consulting companies, and I think that the big consulting companies couldn't figure how to turn such an effort into a profit center for *them*. I figure that is the reason. > For example, suppose you gave away to the postal service cheap devices > for use at post offices for the purpose of enrolling users, then let > the postal service charge a fee for providing the service, with you > keeping either a nominal portion or even none of the fee. What would > be the legal barriers to making that happen? > Upside: you won't need to train their employees in how to validate IDs. > Downside: risks being more of a political than business relationship. Maybe Amazon has the clout with the Post Office to make that happen :-) [I say with only half tongue-in-cheek] "Alexa, please renew my certificates" -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAlzB1roACgkQlUzhVv38 QpDhQQf9EdYHnL3y2sv841IdOtj3D08YBBDJ9zfhQhSU+DAgQEOjwkoPyD1DjRUS q4v3yl6ie9TWf9RCTuoIr3rpNdHdDXnUIuwb/ZrlS1Ww8tgg2+DxN6CHK98uz0Y7 VasFFxhmu+zCirRtpO7dI8pcRtksbGZ34CKstV+HjclMcmIqr+N7/9rKK2RL67ul XgLF1VkbMRN9Zzsk2WjjJi4N5uY7SMr0S/IHNC+BsAy+ic2vIDxiO8hVHsv5ugZI f/7SHbWxOXnXTNJQidd1Et17NeEfErba0o1ZZ+MDec+8GVOb0AWucV2Aq/Blk5g9 DEj/ixxTKlZ80r1Cx/GMX/niBtBV0Q== =sn9k -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Apr 25 09:14:28 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F008F120225; Thu, 25 Apr 2019 09:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 KRvFeakVwf2R; Thu, 25 Apr 2019 09:14:15 -0700 (PDT) Received: from firebrick.maple.relay.mailchannels.net (firebrick.maple.relay.mailchannels.net [23.83.214.59]) (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 AF6031202FD; Thu, 25 Apr 2019 09:14:13 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 74FD22C2070; Thu, 25 Apr 2019 16:14:12 +0000 (UTC) Received: from pdx1-sub0-mail-a23.g.dreamhost.com (100-96-2-149.trex.outbound.svc.cluster.local [100.96.2.149]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id EA9562C2168; Thu, 25 Apr 2019 16:14:10 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a23.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Thu, 25 Apr 2019 16:14:12 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Sponge-Cellar: 1871ab8c00823e71_1556208851885_4196924436 X-MC-Loop-Signature: 1556208851885:185892603 X-MC-Ingress-Time: 1556208851884 Received: from pdx1-sub0-mail-a23.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a23.g.dreamhost.com (Postfix) with ESMTP id 6036781CE4; Thu, 25 Apr 2019 09:14:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=LhlUWfYOOkKiV5 rgwe05HSL89K8=; b=eBIPYlTT6DnsEwnIXB06FkHcFNm+BH4rQBfoucaUQUc0V9 68x5DefJnGR83aEsCvHgfN6OAltR0oHZWgv55n3DMlTvfXLkGhVHcjUfUpKxT/th L6MpxzWZT3Ujed18B2+JzV3RtmxGDOaNdAZQWc+ogax0oQ+5793KembWz5Vy4= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a23.g.dreamhost.com (Postfix) with ESMTPSA id 1B61F81CE0; Thu, 25 Apr 2019 09:14:07 -0700 (PDT) Date: Thu, 25 Apr 2019 11:14:05 -0500 X-DH-BACKEND: pdx1-sub0-mail-a23 From: Nico Williams To: Phillip Hallam-Baker Cc: secdispatch@ietf.org, saag@ietf.org Message-ID: <20190425161404.GS3137@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrheeggdelkecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd Archived-At: Subject: Re: [saag] The Mathematical Mesh X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2019 16:14:27 -0000 Now that I understand what the proposal is, I have to say that I like it. There are some important new things in it, mostly the use of a blockchain for PGP-style web-of-trust, and an Internet protocol for device key management (which is separable but doesn't need to be separated). The first is a new application of existing ideas, but it is critical to facilitating the use of web-of-trust. The most important thing about the proposal is that it's a synthesis of the above and an all-of-the-above approach to communication security for average users, and that it's a proposal for Standards-Track Internet protocols. As such it has better chance of success than the disparate piecemeal efforts of the industry as a whole until now. Count on me as a reviewer, Nico -- From nobody Thu Apr 25 13:22:18 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D52B91201B3 for ; Thu, 25 Apr 2019 13:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=MWHQlB27; dkim=pass (1536-bit key) header.d=taugh.com header.b=RiCx9Asy Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHKbMacllHnE for ; Thu, 25 Apr 2019 13:22:15 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 179561201A8 for ; Thu, 25 Apr 2019 13:22:15 -0700 (PDT) Received: (qmail 41729 invoked from network); 25 Apr 2019 20:22:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding; s=a2ff.5cc216f4.k1904; i=johnl-iecc.com@submit.iecc.com; bh=kN/IBDJ82nbQwR+9YJZvmj5MGydLUkTKwxLj0JB1afk=; b=MWHQlB278VY+S8R/OVt1LWQ8TWnXp6ef7h92sWknVKHXE+cOGB7wjICMqI5eb2YdSnXrIJgYJMIWsLEzRK75Bc4eInGThQiYB76mMAF+wzluvkd+O6fYI5lRvn4iLHZjMLcuSM1pI1aBQ2tid3KMbnUo/1P75kGirfukQvxXkgSdD3JjnGngns2mqeHGpdL1RYhcbMJMtQE0iGtKbgA3XDZ7nl15CA4kkU+PGbmfi8SVA0voqNcXy0H0sroa64Vc DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding; s=a2ff.5cc216f4.k1904; olt=johnl-iecc.com@submit.iecc.com; bh=kN/IBDJ82nbQwR+9YJZvmj5MGydLUkTKwxLj0JB1afk=; b=RiCx9AsyhWMZ5IOqI733ne+FjZmouNJmFbFUN1PQ2xanXZh7udlcPA0tpJmhMWFhND85cXfxwMA1yfg6s589+tkmjB+7wtcwqt9m5tnGmQYE7RnTqpkW2Ay34WYX6F1BfUmDxgPAgjGyNY/pndjuPzvWb6Fy0aEyjB6dGTxd/j8CKrzS9PnPy/w/vGAym3qxxZDljdv5MEPcZX2CSKLAjMxerdsgk5+MMebvTDchHKv6jkXu52473tCLPPldF4RA Received: from ary.qy ([68.175.130.230]) by imap.iecc.com ([64.57.183.75]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP; 25 Apr 2019 20:22:12 -0000 Received: by ary.qy (Postfix, from userid 501) id 4C6652012F0BD3; Thu, 25 Apr 2019 16:22:11 -0400 (EDT) Date: 25 Apr 2019 16:22:11 -0400 Message-Id: <20190425202212.4C6652012F0BD3@ary.qy> From: "John Levine" To: saag@ietf.org Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: [saag] TLS signing request software other than openssl X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2019 20:22:17 -0000 I know how to use "openssl req" to make a signing request. Is there any other library or package that's used at all widely to create requests? Tnx. -- Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu Apr 25 13:44:31 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5F4C1200CE for ; Thu, 25 Apr 2019 13:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.646 X-Spam-Level: X-Spam-Status: No, score=-1.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fbt-_zrWWAGh for ; Thu, 25 Apr 2019 13:44:27 -0700 (PDT) Received: from mail-ot1-f51.google.com (mail-ot1-f51.google.com [209.85.210.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A99B5120052 for ; Thu, 25 Apr 2019 13:44:27 -0700 (PDT) Received: by mail-ot1-f51.google.com with SMTP id w6so747577otl.7 for ; Thu, 25 Apr 2019 13:44:27 -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=LniILJV1EgRCCTil6vxytJghVeyTEg3LyAAuM7PhzQs=; b=JsOWFRa1MtDqMCFjladE9z+VEQdhp6X1uuhiXVxD6QAE1P3WJeBWDvx3vKYR/ZWApN fBpXGy2QpF1tu4T2bdDWMzKr5kq20phOoXz8dWR/CHwhTzDIO5NWxn3sX24Z6p3iFblY AxjfAtTdvNchOi5njxO+Fw5woCvR+d+zumz8aEaY9kOvx2WfBJXKivOHIORFce8fKInz KxwO9H3kvDsNfAjVkYYylTRm3w9OQ0tuuchXN0C8RgrdKUcxDl5gef7clUeGnJuA6Xy1 NLg52EbMEDV4WZ9fQXeg8qHml17Pt1d/RPpBxa+SocB5qxfWwicvAfUpN3SnVnbKoNvF bRyA== X-Gm-Message-State: APjAAAXf6NuyJvSssbCOoPqqlNyca2xh+m+1cIIgu0LPVTlOveym3z0W IGa3ZZN1gRtGD6T99goU7m5JOy1zoBfgzwQAQFY= X-Google-Smtp-Source: APXvYqxFI+b9mQnWK+hdPQh274uEO3kjVF7ChBFe5nEl0BxorY0tHrihajRwlyjY1hdODO1JWDOx4akMG4RJs73VmRw= X-Received: by 2002:a9d:5a11:: with SMTP id v17mr25176253oth.150.1556225066904; Thu, 25 Apr 2019 13:44:26 -0700 (PDT) MIME-Version: 1.0 References: <20190424182641.GL3137@localhost> <20190424233338.GP3137@localhost> <16119.1556207291@dooku.sandelman.ca> In-Reply-To: <16119.1556207291@dooku.sandelman.ca> From: Phillip Hallam-Baker Date: Thu, 25 Apr 2019 16:44:15 -0400 Message-ID: To: Michael Richardson Cc: Nico Williams , IETF SAAG Content-Type: multipart/alternative; boundary="0000000000004db0de058760e2b5" Archived-At: Subject: Re: [saag] Direct trust between users X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2019 20:44:30 -0000 --0000000000004db0de058760e2b5 Content-Type: text/plain; charset="UTF-8" On Thu, Apr 25, 2019 at 11:48 AM Michael Richardson wrote: > > Nico Williams wrote: > > Long long ago I used to imagine the U.S. postal service selling what > > you might call EV user certificates: after all, there are post > offices > > everywhere and their staff are trained in validating > government-issued > > IDs, often they're even notaries public! I supposed one might even > be > > able to get attribute certs attesting that the holder of the key is, > > e.g., a citizen, or over 18 years of age. > > Canada Post had a key in the browser list for a decade or so, and there was > some project with Entrust to do something, but I don't think it ever > happened. > The US Post office had a series of proposed schemes as well. None of them ever got anywhere because we poached their staff as fast as they could train them. Every 18 months some political appointee would attempt to start some information superhighway effort. A team would be staffed up in the USPO and learn about PKI. About twelve months in, they would be all nicely trained up and we would show up and offer double their salary plus stock. I also don't understand why I have a scanned PDF from ic.gc.ca as a > corporate > identity, and not a PKIX certificate. They've had all the software to the > PKIX key for 20+ years. > Yeah, sorry 'bout that. > The post-office is unique in that it can get a letter to many people within > 24h, rather cheaply, and I keep thinking that this is a better 2FA (or > 3FA) for > account recovery. > There is a classical problem called the innovator's dilemma that actually mitigates against realizing such efficiencies. > Upside: you won't need to train their employees in how to validate > IDs. > > Downside: risks being more of a political than business relationship. > > Maybe Amazon has the clout with the Post Office to make that happen :-) > [I say with only half tongue-in-cheek] > "Alexa, please renew my certificates" > It could be made to happen. But the way to make it happen would be to design a system that is capable of 1) Solving a very small stand alone problem by itself 2) Application to problems of arbitrary size. I am just writing my submission to the deployment workshop (which I wont be able to attend but thought I would submit to anyway). The paper describes the approaches we took in the Web. People think we just sat in our offices at CERN and waited for the Web to take off. We didn't we were busy pushing it as hard as we could long after the Web was a success. One of my big fears was that the press that had been building us up for so long would decide it was time to try and take us down. They did - see the Time-Warner 'Cyberporn' article. --0000000000004db0de058760e2b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Apr 25, 2019 at 11:48 AM Michael Richardson= <mcr+ietf@sandelman.ca&g= t; wrote:

Nico Williams <nico@cryptonector.com> wrote:
=C2=A0 =C2=A0 > Long long ago I used to imagine the U.S. postal service = selling what
=C2=A0 =C2=A0 > you might call EV user certificates: after all, there ar= e post offices
=C2=A0 =C2=A0 > everywhere and their staff are trained in validating gov= ernment-issued
=C2=A0 =C2=A0 > IDs, often they're even notaries public!=C2=A0 I sup= posed one might even be
=C2=A0 =C2=A0 > able to get attribute certs attesting that the holder of= the key is,
=C2=A0 =C2=A0 > e.g., a citizen, or over 18 years of age.

Canada Post had a key in the browser list for a decade or so, and there was=
some project with Entrust to do something, but I don't think it ever happened.

The US Post office had a series of proposed schem= es as well. None of them ever got anywhere because we poached their staff a= s fast as they could train them.=C2=A0

Every 18 months some political appointee would attempt to sta= rt some information superhighway effort. A team would be staffed up in the = USPO and learn about PKI. About twelve months in, they would be all nicely = trained up and we would show up and offer double their salary plus stock.

I also don't understand why I have a scanned PDF from ic.gc.ca as a corporate=
identity, and not a PKIX certificate. They've had all the software to t= he
PKIX key for 20+ years.

Yeah, sorry 'bout that.
=C2=A0
The post-office is unique in that it can get a letter to many people within=
24h, rather cheaply, and I keep thinking that this is a better 2FA (or 3FA)= for
account recovery.

There is a classical problem called the i= nnovator's dilemma that actually mitigates against realizing such effic= iencies.

= =C2=A0 =C2=A0 > Upside: you won't need to train their employees in h= ow to validate IDs.
=C2=A0 =C2=A0 > Downside: risks being more of a political than business = relationship.

Maybe Amazon has the clout with the Post Office to make that happen :-)
[I say with only half tongue-in-cheek]
=C2=A0 "Alexa, please renew my certificates"


It could be made to happen. But the way to make it happen would = be to design a system that is capable of=C2=A0

1) Solving a very small stand alone problem by itself=
2) Application= to problems of arbitrary size.

I am just writing my submission to the depl= oyment workshop (which I wont be able to attend but thought I would submit = to anyway). The paper describes the approaches we took in the Web.

People think we just sat in our o= ffices at CERN and waited for the Web to take off. We didn't we were bu= sy pushing it as hard as we could long after the Web was a success. One of = my big fears was that the press that had been building us up for so long wo= uld decide it was time to try and take us down. They did - see the Time-War= ner 'Cyberporn' article.

--0000000000004db0de058760e2b5-- From nobody Thu Apr 25 14:00:01 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3721200EF for ; Thu, 25 Apr 2019 14:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rtVNca64YXsA for ; Thu, 25 Apr 2019 13:59:58 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC658120228 for ; Thu, 25 Apr 2019 13:59:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id B3D703004E7 for ; Thu, 25 Apr 2019 16:41:38 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id maVHWWdIyDxz for ; Thu, 25 Apr 2019 16:41:37 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 5B231300AB2; Thu, 25 Apr 2019 16:41:37 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Russ Housley In-Reply-To: <20190425202212.4C6652012F0BD3@ary.qy> Date: Thu, 25 Apr 2019 16:59:54 -0400 Cc: IETF SAAG Content-Transfer-Encoding: quoted-printable Message-Id: References: <20190425202212.4C6652012F0BD3@ary.qy> To: John Levine X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [saag] TLS signing request software other than openssl X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2019 21:00:00 -0000 h= ttps://www.namecheap.com/support/knowledgebase/article.aspx/467/67/how-to-= generate-csr-certificate-signing-request-code > On Apr 25, 2019, at 4:22 PM, John Levine wrote: >=20 > I know how to use "openssl req" to make a signing request. >=20 > Is there any other library or package that's used at all widely > to create requests? Tnx. >=20 >=20 >=20 > --=20 > Regards, > John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for = Dummies", > Please consider the environment before reading this e-mail. = https://jl.ly >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Thu Apr 25 14:12:21 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A5312004C; Thu, 25 Apr 2019 14:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wd-TNiiIo_GE; Thu, 25 Apr 2019 14:12:13 -0700 (PDT) Received: from mail-ot1-f45.google.com (mail-ot1-f45.google.com [209.85.210.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 283FE120044; Thu, 25 Apr 2019 14:12:13 -0700 (PDT) Received: by mail-ot1-f45.google.com with SMTP id e5so784985otk.12; Thu, 25 Apr 2019 14:12:13 -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=VHX+0lPDmVg+sXjWF/BgwByYc3WQw+RO3k6xAS5I99c=; b=B/lP7a7ppVZO7nfLsnuobQvEme5xSvXQuEC1H+Yyb3+SicACOML0ACB45ZuwAEZfN8 AZGVA2kWT0LNJ6HroUMu8g2OkV66PavEKgYCmBBSrBlt3d+CpUMj5EWVvgfohXRfS/08 PxA5lDfBFYTf97Qilmrq4cstNcf1qLHiz4HUtydeB7MnU6b/yb11wrftxHVxgdnIkI0W 4vf1uNopUCJiavlHDYNGmaurpMt0m6g9G1LCndKEJSLNmRZPljpLkX4VrclfSKjJTI0C Cut7QdmvE8eSHgXFCP/1G/aSeh1KNfxtBCZflcb3bBn1QQ46c1FXcfHUdE+aY6b4Um4Z PBXA== X-Gm-Message-State: APjAAAWCj2zvqMkdI6j/f6IKUf5AwKIlFc+S3FlgjpNGNFZobC6Q+TSo mqulbHuIsRG6gViuFHxZ8lEcdRGwDuqFDOAO3f8= X-Google-Smtp-Source: APXvYqxxoZmOUQYNwBeLaSt9onH3N1Q75Ois4SwMzob+G5NtKV9EjUMDnnU5fxH0W7rsa50UkGQNi2FeXG/3eHhxrkg= X-Received: by 2002:a05:6830:1017:: with SMTP id a23mr26225817otp.120.1556226732382; Thu, 25 Apr 2019 14:12:12 -0700 (PDT) MIME-Version: 1.0 References: <20190425161404.GS3137@localhost> In-Reply-To: <20190425161404.GS3137@localhost> From: Phillip Hallam-Baker Date: Thu, 25 Apr 2019 17:12:00 -0400 Message-ID: To: Nico Williams Cc: secdispatch@ietf.org, IETF SAAG Content-Type: multipart/alternative; boundary="00000000000092de5e058761454c" Archived-At: Subject: Re: [saag] The Mathematical Mesh X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2019 21:12:15 -0000 --00000000000092de5e058761454c Content-Type: text/plain; charset="UTF-8" On Thu, Apr 25, 2019 at 12:14 PM Nico Williams wrote: > > Now that I understand what the proposal is, I have to say that I like > it. > > There are some important new things in it, mostly the use of a > blockchain for PGP-style web-of-trust, and an Internet protocol for > device key management (which is separable but doesn't need to be > separated). The first is a new application of existing ideas, but it > is critical to facilitating the use of web-of-trust. > Just to be clear: It is a similar approach to blockchain. The encoding used is entirely separate. The DARE Container allows append only logs to be created with individual entries of up to 2^63 bytes in length. So we could use the same format as a file archiving format or even a software distribution format. The encoding allows the container sequence to be read with equal efficiency in the forward or the reverse direction and while every entry can have a separate key exchange and signature, the entire container can be authenticated and encrypted at the entry level using a single key exchange in the first entry and a single signature entry on the last entry. So we could use this as a ZIP file for distributing Web pages. But unlike ZIP, the signatures are based on a Merkle tree so we can validate individual entries. So we could use this as a software distribution format. Put all the files for all the distributions on all platforms into one big file. Then the distribution system can extract the specific set of files needed for specific platforms weeding out the ones that aren't needed. The same approach can be used for software updates. since the containers are append only. All you need to do to push out updates is to synchronize the containers across devices. The reason I was able to simplify the Mesh code was that I realized that all my application protocols could be implemented as instances of synchronizing containers between devices. > The most important thing about the proposal is that it's a synthesis of > the above and an all-of-the-above approach to communication security for > average users, and that it's a proposal for Standards-Track Internet > protocols. As such it has better chance of success than the disparate > piecemeal efforts of the industry as a whole until now. > > Count on me as a reviewer, Thanks, that is greatly appreciated. The status of the current drafts is that the text is more or less complete, there are some missing images and multiple missing examples. The reason for that is that I alternate between writing the documentation and implementing it. I began by writing the documentation, wrote the code, went back and wrote new documentation describing the code and so on. The last set of changes was motivated my my leaving Comodo. Originally, the DARE work was an application that built on the Mesh capabilities. I rewrote the code so that the Mesh is now built on top of DARE. That allowed me to eliminate two thirds of it. --00000000000092de5e058761454c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Apr 25, 2019 at 12:14 PM Nico Williams <nico@cryptonector.com> wrote:

Now that I understand what the proposal is, I have to say that I like
it.

There are some important new things in it, mostly the use of a
blockchain for PGP-style web-of-trust, and an Internet protocol for
device key management (which is separable but doesn't need to be
separated).=C2=A0 The first is a new application of existing ideas, but it<= br> is critical to facilitating the use of web-of-trust.
<= br>
Just t= o be clear: It is a similar approach to blockchain. The encoding used is en= tirely separate.=C2=A0

The DARE Container allows append only logs to be cre= ated with individual entries of up to 2^63 bytes in length. So we could use= the same format as a file archiving format or even a software distribution= format.

The encoding all= ows the container sequence to be read with equal efficiency in the forward = or the reverse direction and while every entry can have a separate key exch= ange and signature, the entire container can be authenticated and encrypted= at the entry level using a single key exchange in the first entry and a si= ngle signature entry on the last entry.=C2=A0

So we could use this as a ZIP file for distributing We= b pages. But unlike ZIP, the signatures are based on a Merkle tree so we ca= n validate individual entries.

So we could use this as a software distribution format. Put all the f= iles for all the distributions on all platforms into one big file. Then the= distribution system can extract the specific set of files needed for speci= fic platforms weeding out the ones that aren't needed.=C2=A0

The same approach can be used for s= oftware updates. since the containers are append only. All you need to do t= o push out updates is to synchronize the containers across devices.


The reason I was able to simplify the Me= sh code was that I realized that all my application protocols could be impl= emented as instances of synchronizing containers between devices.

=

=C2=A0
The most important thing about the proposal is that it's a synthesis of=
the above and an all-of-the-above approach to communication security for average users, and that it's a proposal for Standards-Track Internet protocols.=C2=A0 As such it has better chance of success than the disparate=
piecemeal efforts of the industry as a whole until now.

Count on me as a reviewer,
=C2=A0
Thanks, that is greatly appreciated. Th= e status of the current drafts is that the text is more or less complete, t= here are some missing images and multiple missing examples.

The reason for that is that I alternate = between writing the documentation and implementing it. I began by writing t= he documentation, wrote the code, went back and wrote new documentation des= cribing the code and so on.

The last set of changes was motivated my my leaving Comodo. Originally, = the DARE work was an application that built on the Mesh capabilities. I rew= rote the code so that the Mesh is now built on top of DARE. That allowed me= to eliminate two thirds of it.
--00000000000092de5e058761454c-- From nobody Thu Apr 25 14:28:53 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 687AC120092 for ; Thu, 25 Apr 2019 14:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 nJD8WVRAgTsl for ; Thu, 25 Apr 2019 14:28:47 -0700 (PDT) Received: from goldenrod.birch.relay.mailchannels.net (goldenrod.birch.relay.mailchannels.net [23.83.209.74]) (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 5BF17120025 for ; Thu, 25 Apr 2019 14:28:47 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 0CC9D5C498F; Thu, 25 Apr 2019 21:28:46 +0000 (UTC) Received: from pdx1-sub0-mail-a22.g.dreamhost.com (unknown [100.96.11.48]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 95C255C4F79; Thu, 25 Apr 2019 21:28:45 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a22.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Thu, 25 Apr 2019 21:28:46 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Versed-Little: 1ad5c9ed1cc67ccd_1556227725844_1915684158 X-MC-Loop-Signature: 1556227725844:2349157656 X-MC-Ingress-Time: 1556227725843 Received: from pdx1-sub0-mail-a22.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a22.g.dreamhost.com (Postfix) with ESMTP id 3A18C825D8; Thu, 25 Apr 2019 14:28:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=CbmpQsMG2YV+Cu q/MSPee9s2hSA=; b=N25Kby2lQIPFL83xS4CXyOhgOJlUWksTIxPwAvyPv62qJb IxDexsv41IJTyKpK/b8c4lgYmtedfQT7V2T/BPNnLzgBn+zQea5dYO6TdFQNdlfE vrAmfsSrncJv/kgdakrCwfx9XKs2XUMi3fSPwLHuhV9rMIscKBUm6prBsCnGk= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a22.g.dreamhost.com (Postfix) with ESMTPSA id 2A62C825D6; Thu, 25 Apr 2019 14:28:42 -0700 (PDT) Date: Thu, 25 Apr 2019 16:28:40 -0500 X-DH-BACKEND: pdx1-sub0-mail-a22 From: Nico Williams To: Phillip Hallam-Baker Cc: Michael Richardson , IETF SAAG Message-ID: <20190425212839.GW3137@localhost> References: <20190424182641.GL3137@localhost> <20190424233338.GP3137@localhost> <16119.1556207291@dooku.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrheeggdduiedvucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhenucevlhhushhtvghrufhiiigvpedt Archived-At: Subject: Re: [saag] Direct trust between users X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2019 21:28:49 -0000 On Thu, Apr 25, 2019 at 04:44:15PM -0400, Phillip Hallam-Baker wrote: > On Thu, Apr 25, 2019 at 11:48 AM Michael Richardson > wrote: > > Nico Williams wrote: > > > Long long ago I used to imagine the U.S. postal service selling > > > what you might call EV user certificates: after all, there are > > > post offices everywhere and their staff are trained in validating > > > government-issued IDs, often they're even notaries public! I > > > supposed one might even be able to get attribute certs attesting > > > that the holder of the key is, e.g., a citizen, or over 18 years > > > of age. > > > > Canada Post had a key in the browser list for a decade or so, and > > there was some project with Entrust to do something, but I don't > > think it ever happened. > > The US Post office had a series of proposed schemes as well. None of > them ever got anywhere because we poached their staff as fast as they > could train them. > > Every 18 months some political appointee would attempt to start some > information superhighway effort. A team would be staffed up in the > USPO and learn about PKI. About twelve months in, they would be all > nicely trained up and we would show up and offer double their salary > plus stock. Oh. That's the reason? This is the sort of thing that should be setup via a contract with an external party, then this sort of "sabotage" (no offense intended) is much less likely (the external party won't want to be in breach). > > The post-office is unique in that it can get a letter to many people > > within 24h, rather cheaply, and I keep thinking that this is a > > better 2FA (or 3FA) for account recovery. You don't need them to do anything special for that. And note well that the post service generally doesn't know how to contact people -- it depends on the sender to furnish the recipient's address. I.e., the postal service is like a network layer 3, and there is no DNS for it. If the postal service were to sell certificates and also use postal delivery for 2FA, they'd have to know where you live -- "know" in very different sense from "they seem all the letters go by, so they could know where everyone lives". > There is a classical problem called the innovator's dilemma that > actually mitigates against realizing such efficiencies. That and the fact that postal services are generally publicly owned and operated, so there's very little incentive for them to innovate. > > > Upside: you won't need to train their employees in how to validate > > > IDs. > > > Downside: risks being more of a political than business > > > relationship. > > > > Maybe Amazon has the clout with the Post Office to make that happen :-) > > [I say with only half tongue-in-cheek] > > "Alexa, please renew my certificates" > > It could be made to happen. But the way to make it happen would be to > design a system that is capable of > > 1) Solving a very small stand alone problem by itself > 2) Application to problems of arbitrary size. Hmm, because these certificates couldn't be short-lived... the issuer would have to support revocation, and probably record all issued certificate serial numbers and names. Not trivial, though still not very difficult. OTOH, if such certificates are strongly bound to _devices_, then you can push the revocation burden to that layer, and make the issuer O(1) -- that being key to (2). (1) is already met, I think. Nico -- From nobody Thu Apr 25 14:42:51 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C701120260; Thu, 25 Apr 2019 14:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 uehRfrH6QkE2; Thu, 25 Apr 2019 14:42:40 -0700 (PDT) Received: from ostrich.birch.relay.mailchannels.net (ostrich.birch.relay.mailchannels.net [23.83.209.138]) (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 6717612025C; Thu, 25 Apr 2019 14:42:40 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id E2D6C5C5B28; Thu, 25 Apr 2019 21:42:38 +0000 (UTC) Received: from pdx1-sub0-mail-a22.g.dreamhost.com (unknown [100.96.28.64]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 952935C5AD2; Thu, 25 Apr 2019 21:42:38 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a22.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Thu, 25 Apr 2019 21:42:38 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Arithmetic-Stop: 4dfcbe24222139ea_1556228558719_4189485943 X-MC-Loop-Signature: 1556228558718:3285635047 X-MC-Ingress-Time: 1556228558718 Received: from pdx1-sub0-mail-a22.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a22.g.dreamhost.com (Postfix) with ESMTP id 54E80825D6; Thu, 25 Apr 2019 14:42:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=V4YaBM4/+cFl7+ uSG86P/Zz2RP0=; b=c30Gq3dra2TBG+tA2aR9jXTo2PIzDt9YFI25XwVe6SoSkE fdvFjK30BnjAe6N6/S1j878clOpLnInrgQvri+mvBtSiI+cHEJDMvl3qUZRcy7zC mvVK+FAwrSH5Unl766EbKBqi9XAyB5yl/NZWjBccb6jyvUMsiU4VVW9YZKQBk= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a22.g.dreamhost.com (Postfix) with ESMTPSA id DD610825D8; Thu, 25 Apr 2019 14:42:36 -0700 (PDT) Date: Thu, 25 Apr 2019 16:42:34 -0500 X-DH-BACKEND: pdx1-sub0-mail-a22 From: Nico Williams To: Phillip Hallam-Baker Cc: secdispatch@ietf.org, IETF SAAG Message-ID: <20190425214233.GX3137@localhost> References: <20190425161404.GS3137@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrheehgddtudcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd Archived-At: Subject: Re: [saag] The Mathematical Mesh X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2019 21:42:43 -0000 On Thu, Apr 25, 2019 at 05:12:00PM -0400, Phillip Hallam-Baker wrote: > On Thu, Apr 25, 2019 at 12:14 PM Nico Williams > wrote: > > Just to be clear: It is a similar approach to blockchain. The encoding used > is entirely separate. Understood. The point is that you end up with a cryptographic append-only log. > The reason I was able to simplify the Mesh code was that I realized that > all my application protocols could be implemented as instances of > synchronizing containers between devices. Nice. > > Count on me as a reviewer, > > Thanks, that is greatly appreciated. The status of the current drafts is > that the text is more or less complete, there are some missing images and > multiple missing examples. Is that a request for review sooner than later? > The reason for that is that I alternate between writing the documentation > and implementing it. I began by writing the documentation, wrote the code, > went back and wrote new documentation describing the code and so on. Understood. Nico -- From nobody Thu Apr 25 15:15:00 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53B3E120343; Thu, 25 Apr 2019 15:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMU2Fau5Y55J; Thu, 25 Apr 2019 15:14:49 -0700 (PDT) Received: from mail-ot1-f45.google.com (mail-ot1-f45.google.com [209.85.210.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAF4D1200F8; Thu, 25 Apr 2019 15:14:49 -0700 (PDT) Received: by mail-ot1-f45.google.com with SMTP id u17so982108otj.1; Thu, 25 Apr 2019 15:14: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:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SbupJ67oYGL4CrkcEAz7h1s2KKC5mw30lm7T6hYyzzo=; b=YvNpCxlVN2eM4/ciiZtAcEZWuJ+1yJE7aGz/HvAgvKAYF51j2HslOPyMOMOGuFHImr TgQT4t1vDDurnkY/7lRJFKWNqLQNADJg6vmiK2JQtRHuPCtYDifZRejyguDeZuwCdiLt OwZqDTWFjlEQVMn2mJqSGW6AlV9U3nW94naqRwfL0iK5E6WUJNxYW8sz10rFBuY2O5BT VUQ1wXV1dOCiUbA1yDBQ77Xd9IqZLBewiDmShwB8OjW385z0FQvyD0NveppGm3xLeWti XK7DW/nYqfL6E4tLRVRvAGlbTAJF1ChJLqozVwYRrQoDjyVFns3Aq3lf5K+/X+e6Amn7 9TJg== X-Gm-Message-State: APjAAAUpMaYywbAus2M2TrQP2hqHXhkkuHCUmyMHJPVr215n16zG73BQ G1sU9+AlsBc95uUeHslYDlhJ0bjLVtlMrOR/fq0= X-Google-Smtp-Source: APXvYqzC0hkyYXkFo48KFe/UTSDz7iSpvc47eyzoYaxZdRBku7vOl2GvYTrKE7mT7B2KTxdfIZ1yu/2pUeC+Q4HZ4Zw= X-Received: by 2002:a9d:6543:: with SMTP id q3mr3986649otl.370.1556230488933; Thu, 25 Apr 2019 15:14:48 -0700 (PDT) MIME-Version: 1.0 References: <20190425161404.GS3137@localhost> <20190425214233.GX3137@localhost> In-Reply-To: <20190425214233.GX3137@localhost> From: Phillip Hallam-Baker Date: Thu, 25 Apr 2019 18:14:37 -0400 Message-ID: To: Nico Williams Cc: secdispatch@ietf.org, IETF SAAG Content-Type: multipart/alternative; boundary="0000000000007b4af405876225b2" Archived-At: Subject: Re: [saag] The Mathematical Mesh X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2019 22:14:51 -0000 --0000000000007b4af405876225b2 Content-Type: text/plain; charset="UTF-8" On Thu, Apr 25, 2019 at 5:42 PM Nico Williams wrote: > On Thu, Apr 25, 2019 at 05:12:00PM -0400, Phillip Hallam-Baker wrote: > > On Thu, Apr 25, 2019 at 12:14 PM Nico Williams > > wrote: > > > > Just to be clear: It is a similar approach to blockchain. The encoding > used > > is entirely separate. > > Understood. The point is that you end up with a cryptographic > append-only log. > Yep. > > The reason I was able to simplify the Mesh code was that I realized that > > all my application protocols could be implemented as instances of > > synchronizing containers between devices. > > Nice. > > > > Count on me as a reviewer, > > > > Thanks, that is greatly appreciated. The status of the current drafts is > > that the text is more or less complete, there are some missing images and > > multiple missing examples. > > Is that a request for review sooner than later? The current status is that the UDF and DARE drafts are essentially done. I do not expect to make major changes to those drafts in response to my work. I will of course expect to make changes due to the review cycle so if you are interested in reviewing, those are the drafts to look at. The next one I expect to be ready is the algorithms draft (8). This is pretty complete except that I have moved in work from elsewhere which needs attention and examples. Those will be the next examples generated by the code. If you want to see the scope of the work and how it hangs together, the architecture guide has the text but not the pictures or conversations. > --0000000000007b4af405876225b2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Apr 25, 2019 at 5:42 PM Nico Williams <<= a href=3D"mailto:nico@cryptonector.com">nico@cryptonector.com> wrote= :
On Thu, Apr 25= , 2019 at 05:12:00PM -0400, Phillip Hallam-Baker wrote:
> On Thu, Apr 25, 2019 at 12:14 PM Nico Williams <nico@cryptonector.com>
> wrote:
>
> Just to be clear: It is a similar approach to blockchain. The encoding= used
> is entirely separate.

Understood.=C2=A0 The point is that you end up with a cryptographic
append-only log.

Yep.


=C2=A0
> The reason I was able to simplify the Mesh code was that I realized th= at
> all my application protocols could be implemented as instances of
> synchronizing containers between devices.

Nice.

> > Count on me as a reviewer,
>
> Thanks, that is greatly appreciated. The status of the current drafts = is
> that the text is more or less complete, there are some missing images = and
> multiple missing examples.

Is that a request for review sooner than later?

=
The current sta= tus is that the UDF and DARE drafts are essentially done. I do not expect t= o make major changes to those drafts in response to my work. I will of cour= se expect to make changes due to the review cycle so if you are interested = in reviewing, those are the drafts to look at.

The next one I expect to be ready is the algorithms d= raft (8). This is pretty complete except that I have moved in work from els= ewhere which needs attention and examples. Those will be the next examples = generated by the code.

If= you want to see the scope of the work and how it hangs together, the archi= tecture guide has the text but not the pictures or conversations.

=

=C2=A0
--0000000000007b4af405876225b2-- From nobody Thu Apr 25 15:16:48 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1C4312035E for ; Thu, 25 Apr 2019 15:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 526XooX903gz for ; Thu, 25 Apr 2019 15:16:45 -0700 (PDT) Received: from mail-ot1-f53.google.com (mail-ot1-f53.google.com [209.85.210.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C274120342 for ; Thu, 25 Apr 2019 15:16:44 -0700 (PDT) Received: by mail-ot1-f53.google.com with SMTP id g8so943008otk.8 for ; Thu, 25 Apr 2019 15:16:44 -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=V0IL9jrQW5ZoHevh47pgbs2GgPnrPc6I6Yj536Y8PRU=; b=e5rlxj9ZSq9M1PTDRn6tgBbUtOTlxqPdd5iIL+Bes5IDPUixa/RbOJjS8noxHYGPy3 3q9D9PqxyWvoHpxYOfRgLZM2LQsyRidLP9c8vd62V0GiKv9y1BoNCK8GuBYup3pVhbgc Xn6bukVIKcdqbcYO+p/PDgYRM+BY/XH923SxXm39ci/5JBEyCwYYd9WXceTvmeM9jCIK i30GDQvaMFFALFbINErmezzxBKOOsW4RhxlQB7ut0G/7S+IpCwboTzj+s8BgXT0Uhx+T vp1eisIbHniNbIYXg0jeflknj07+BIqhIAhRtY2piW2vIx33Iki89CstNV+cULSfzO2B fJ0Q== X-Gm-Message-State: APjAAAWPLApG6X0T0B/KYwMWMVzHkyBUF3tqNYLQr+94rmqlycQC0Ejs 8AQn6LLSD+3UWnF+E0wmBBN1k+4eyxrhqNwd+uc= X-Google-Smtp-Source: APXvYqznAr17k9D8vUVYVBdQTrndqRgttFNbAV/0767XKPrlPxEvEnVgQl+Mx0iRFYoIiiYIA1yR+ejX7/2X5VzRGPw= X-Received: by 2002:a9d:58c5:: with SMTP id s5mr23577877oth.361.1556230603518; Thu, 25 Apr 2019 15:16:43 -0700 (PDT) MIME-Version: 1.0 References: <20190424182641.GL3137@localhost> <20190424233338.GP3137@localhost> <16119.1556207291@dooku.sandelman.ca> <20190425212839.GW3137@localhost> In-Reply-To: <20190425212839.GW3137@localhost> From: Phillip Hallam-Baker Date: Thu, 25 Apr 2019 18:16:32 -0400 Message-ID: To: Nico Williams Cc: Michael Richardson , IETF SAAG Content-Type: multipart/alternative; boundary="0000000000004fc2760587622cb4" Archived-At: Subject: Re: [saag] Direct trust between users X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2019 22:16:47 -0000 --0000000000004fc2760587622cb4 Content-Type: text/plain; charset="UTF-8" On Thu, Apr 25, 2019 at 5:28 PM Nico Williams wrote: > On Thu, Apr 25, 2019 at 04:44:15PM -0400, Phillip Hallam-Baker wrote: > > On Thu, Apr 25, 2019 at 11:48 AM Michael Richardson < > mcr+ietf@sandelman.ca> > > wrote: > > > Nico Williams wrote: > > > > Long long ago I used to imagine the U.S. postal service selling > > > > what you might call EV user certificates: after all, there are > > > > post offices everywhere and their staff are trained in validating > > > > government-issued IDs, often they're even notaries public! I > > > > supposed one might even be able to get attribute certs attesting > > > > that the holder of the key is, e.g., a citizen, or over 18 years > > > > of age. > > > > > > Canada Post had a key in the browser list for a decade or so, and > > > there was some project with Entrust to do something, but I don't > > > think it ever happened. > > > > The US Post office had a series of proposed schemes as well. None of > > them ever got anywhere because we poached their staff as fast as they > > could train them. > > > > Every 18 months some political appointee would attempt to start some > > information superhighway effort. A team would be staffed up in the > > USPO and learn about PKI. About twelve months in, they would be all > > nicely trained up and we would show up and offer double their salary > > plus stock. > > Oh. That's the reason? This is the sort of thing that should be setup > via a contract with an external party, then this sort of "sabotage" (no > offense intended) is much less likely (the external party won't want to > be in breach). > It wasn't on purpose. It was only after going into the account for the third time that I suddenly realized it was very unlikely we would make the sale as long as our headhunters were head hunting. Yes, a different structure was needed. --0000000000004fc2760587622cb4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Apr 25, 2019 at 5:28 PM Nico Williams <<= a href=3D"mailto:nico@cryptonector.com">nico@cryptonector.com> wrote= :
On Thu, Apr 25= , 2019 at 04:44:15PM -0400, Phillip Hallam-Baker wrote:
> On Thu, Apr 25, 2019 at 11:48 AM Michael Richardson <mcr+ietf@sandelman.ca>= ;
> wrote:
> > Nico Williams <nico@cryptonector.com> wrote:
> >=C2=A0 > Long long ago I used to imagine the U.S. postal servic= e selling
> >=C2=A0 > what you might call EV user certificates: after all, t= here are
> >=C2=A0 > post offices everywhere and their staff are trained in= validating
> >=C2=A0 > government-issued IDs, often they're even notaries= public!=C2=A0 I
> >=C2=A0 > supposed one might even be able to get attribute certs= attesting
> >=C2=A0 > that the holder of the key is, e.g., a citizen, or ove= r 18 years
> >=C2=A0 > of age.
> >
> > Canada Post had a key in the browser list for a decade or so, and=
> > there was some project with Entrust to do something, but I don= 9;t
> > think it ever happened.
>
> The US Post office had a series of proposed schemes as well. None of > them ever got anywhere because we poached their staff as fast as they<= br> > could train them.
>
> Every 18 months some political appointee would attempt to start some > information superhighway effort. A team would be staffed up in the
> USPO and learn about PKI. About twelve months in, they would be all > nicely trained up and we would show up and offer double their salary > plus stock.

Oh.=C2=A0 That's the reason?=C2=A0 This is the sort of thing that shoul= d be setup
via a contract with an external party, then this sort of "sabotage&quo= t; (no
offense intended) is much less likely (the external party won't want to=
be in breach).

It wasn't on purpose.=C2=A0

It was only after going into the account= for the third time that I suddenly realized it was very unlikely we would = make the sale as long as our headhunters were head hunting.

Yes, a different structure was needed.
--0000000000004fc2760587622cb4-- From nobody Thu Apr 25 18:56:14 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2588B1202ED for ; Thu, 25 Apr 2019 18:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBTlfxt9n1WB for ; Thu, 25 Apr 2019 18:56:10 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDB4D1200A0 for ; Thu, 25 Apr 2019 18:56:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1556243770; x=1587779770; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=H9f8PstLy8v9e5gv5PstrsSVlXTXaEgIqyW2oS/l1TU=; b=AwhPBsfgnN+hXuh4bKCr07DB4hRmR7hRWmvJGmqH36gHsG7rDaVbtdAS UnE32pFbnMSjcUl16qA7CO1Hpy8+euNGfyONBKulmFEEKVf3AHuUmw+cg KkYKImTgGYqkRyJZhl1iJqniq6iTibuEp1h70j1pdvgQj4hqwUUl2ttLJ 5/PdI+yohKXdcGLXDaYoPmdeHb+MMua2f0mUzu8cgnKP37faB65NyVlNa po1MMMQSCOXuF8m5eJrKkBj+FcdhZ56bCLEvOY4UGy7E2nCGynrb1m2Re zYSRMQPITnOIkDjRbJ7z19NA+7w0iqcwMex2DzB/TT4qCbYkxUoCeSmB1 Q==; X-IronPort-AV: E=Sophos;i="5.60,395,1549882800"; d="scan'208";a="58635165" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.4 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-c.UoA.auckland.ac.nz) ([10.6.3.4]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 26 Apr 2019 13:56:05 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-c.UoA.auckland.ac.nz (10.6.3.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 26 Apr 2019 13:56:04 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Fri, 26 Apr 2019 13:56:04 +1200 From: Peter Gutmann To: John Levine , "saag@ietf.org" Thread-Topic: [saag] TLS signing request software other than openssl Thread-Index: AQHU+6SjRiJMGdteMUGaY+LJf5bwpaZNrdFI Date: Fri, 26 Apr 2019 01:56:03 +0000 Message-ID: <1556243760613.77468@cs.auckland.ac.nz> References: <20190425202212.4C6652012F0BD3@ary.qy> In-Reply-To: <20190425202212.4C6652012F0BD3@ary.qy> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [saag] TLS signing request software other than openssl X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2019 01:56:13 -0000 John Levine writes:=0A= =0A= >Is there any other library or package that's used at all widely to create= =0A= >requests? Tnx.=0A= =0A= There's lots, take your pick, OpenSSL obviously, Bouncy Castle, JDK, my own= =0A= cryptlib, even an online tool, https://csrgenerator.com/.=0A= =0A= Alternatively, use the link below:=0A= =0A= http://lmgtfy.com/?q=3Dcreate+pkcs+%2310=0A= =0A= Peter.=0A= From nobody Thu Apr 25 19:40:28 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6407F120394 for ; Thu, 25 Apr 2019 19:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=HNBQ1eiK; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=RG5blgHg Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74n-Tt85I43L for ; Thu, 25 Apr 2019 19:40:24 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65DF412011E for ; Thu, 25 Apr 2019 19:40:24 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 4CAB121D2B for ; Thu, 25 Apr 2019 22:40:23 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Thu, 25 Apr 2019 22:40:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=1ZbTzp4HmzliLIAGl+Zt9AUx7MbyEAv R6gpXDnr5MH4=; b=HNBQ1eiKvDFG4jbQfyzv9p4lS4mj/BJ6TyK9/pfhXCCDWdG ClwkEYjVldKZN+uMevycDiPencudmHmtd/h1pSxXiQDjQ0PFg6DMcue/hJAmPzy+ GrGukpJzVoVmJk0sBTNS8Wr9PH60f88ReGpzgp9v4gW/qG7Qmq0nqH/EuNS6aEcu 50cBTsNimS5yE1z1IDIH+w3Jm1aHkC6yVYwFjWeMoq5LM82Wh0oY21t30SZquM6K wdQivIQwgxCYC1BkH7SfIeDRh82Tm1rxwE49ZTWO4Q+ShniN+HB8hn+BzaZiwdUu GBHhOkomi++uaI8k6CRhz9DeH6W9ctaY7ZtT4wA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=1ZbTzp 4HmzliLIAGl+Zt9AUx7MbyEAvR6gpXDnr5MH4=; b=RG5blgHgy+ffbBn1OFjEsF OMGtBHO07XxH3xf/HSCCAx/czSLsHyZ8BoWqBBxyiDTO8bsGc4CdTBI2iNa2DvJV KdDW+INAR1xQgGS4QdiG5eYX1v2W7wn02uIc22QBcM1lIuaqb18dE8j3fS+Zpw5o d5r18mk5hF9FSVGx8eQjnd9PeQGdn2djd9UPKlgd7/OIl/+ag4pMICby4sq7BcKO qiCwzWsZ/rPjKNn3sZZ6AsqgWZiaGYmCtSCwKPsRywZKqTl+WHxHkOEZsY/odPUM lNIwUHmhgihC8Ki7C91pnBVggwPB7vQPJTf3yQtXSKI6se7lGqhBgg9xt8v/4Xfw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrheehgdeiudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpegtshhrghgvnhgvrhgrthhorhdrtg homhenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgv thenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id C42257C199; Thu, 25 Apr 2019 22:40:22 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-444-g755619f-fmstable-20190423v1 Mime-Version: 1.0 Message-Id: <877832b0-4844-4421-b1f1-097eec9987a1@www.fastmail.com> In-Reply-To: <1556243760613.77468@cs.auckland.ac.nz> References: <20190425202212.4C6652012F0BD3@ary.qy> <1556243760613.77468@cs.auckland.ac.nz> Date: Thu, 25 Apr 2019 22:40:25 -0400 From: "Martin Thomson" To: saag@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [saag] TLS signing request software other than openssl X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2019 02:40:26 -0000 On Fri, Apr 26, 2019, at 11:56, Peter Gutmann wrote: > https://csrgenerator.com/ That's probably OK, but it produces a private key in a context you don't want. Use it for demonstration purposes only. Add NSS `certutil -R` to the list. From nobody Fri Apr 26 01:42:28 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8227120312 for ; Fri, 26 Apr 2019 01:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tm_bv8Io1KbL for ; Fri, 26 Apr 2019 01:42:23 -0700 (PDT) Received: from mail-yw1-xc33.google.com (mail-yw1-xc33.google.com [IPv6:2607:f8b0:4864:20::c33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6303120318 for ; Fri, 26 Apr 2019 01:42:23 -0700 (PDT) Received: by mail-yw1-xc33.google.com with SMTP id d132so907934ywa.2 for ; Fri, 26 Apr 2019 01:42:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BjcJVlhMFIXXzO2sJqgHhV4UHDIBJXLkTlgeuz/TzG4=; b=IRDQ0wp/x13rCHp7aCw+x6bMpzpJIJ/WfrJ5Wesk7+Y8R5w3cdMlhO/KjXwnHCR3Km UWdrpAADS+9W1S8vzgtfNO5KTaJ5t9AWRNCYMdoxSdj2RLOXmcgrSzez/O8DUbVlLCwy 4g1OrOEoMqwxVUcwV04wqx7PcxD5NgbW6UhDB9AwMnvQme1ZjZAMoiKmH/B4WSDTlyH1 PJegY37i6inGmUnSxq10owmdSh97G8FJ6UsyODZOM88gqTbgX9VHck+zS3Xxlor3ZQ46 +0fYvn+N7hZQlw21NJs7WTqB9/6eyInuXt7lihzp6ZxYi5mIoIqBDcUxYTVzFH4eKiXY 7V+Q== 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=BjcJVlhMFIXXzO2sJqgHhV4UHDIBJXLkTlgeuz/TzG4=; b=Ikh+8tX5giNHnYOkvriWNdNYEptdOpNOkVj2/6moHo1nD4A6MEtM+SSVoPbl0IZrkf ssXxayt7t73LqAfcnbuAfdbPfJo/3DNnPcPtG4d+TyIj+33nRK+edQ4oTwuiwgdEng71 SjAG+RjsjGdUAs0P00AJpDcjeqWyrPmAOuevCet8WfbmU70SMzLNPHeTzvNSrj0fgs/g Nzb9aT7ynPnqysGn5KxkYFGrWtvWYs0AciI+5HUnJCBNUO+xJPr2P5DPT7wr4NdXt4Kg Cu7Pkx5+2J5jjA01pFWXk+B0DTCbhW7AJq7ZMbq+/LeuHxLWiYAq+5TF/QuX3B9D5kKe Hb8w== X-Gm-Message-State: APjAAAXgjrgpCefMIBhsdos2f84xsjYYyyVc2qVPioy5nE2wo+izzCvy onA+k6GV10qPVuF4vsxbkiANXIvhcyPsYe5bb4RpNZ3n X-Google-Smtp-Source: APXvYqy9jhFvSNzMLOg8/RjLC6N6byRfCpdpc6uyVMbHXvnznwD4Rnexq+xBscd0tOaReDxutP8cOvlGBYaFMGNKLFE= X-Received: by 2002:a81:a:: with SMTP id 10mr30228938ywa.123.1556268142505; Fri, 26 Apr 2019 01:42:22 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ben Laurie Date: Fri, 26 Apr 2019 09:42:10 +0100 Message-ID: To: Phillip Hallam-Baker Cc: IETF SAAG Content-Type: multipart/alternative; boundary="000000000000cfcdc105876ae9f4" Archived-At: Subject: Re: [saag] Direct trust between users X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2019 08:42:26 -0000 --000000000000cfcdc105876ae9f4 Content-Type: text/plain; charset="UTF-8" On Wed, 24 Apr 2019 at 18:57, Phillip Hallam-Baker wrote: > Nico asked about the Mesh Trust model and I said that I was trying to > avoid imposing one. I do have metrics for measuring the quality of trust > established in terms of a work factor however: > > http://mathmesh.com/Documents/draft-hallambaker-mesh-trust.html > > This is not a computational work factor as we are used to. It is a social > work factor nominally denominated in currency (USD) and bounded in time. > > Let us say that we did some key signing even open to IETF meeting > attendees only. It would cost an attacker $325 plus travel minimum to > impersonate me. Not an impossible sum if they really really want to > impersonate me but enough to stop a large number of attacks. Furthermore, > there is a significant risk of being caught if they attempt the > impersonation on any large scale. So the social work factor might be $1000. > Presumably $1,000 buys more than one impersonation, and of anyone you want (there's no list of who was actually at IETF, AFAIK). -- I am hiring! Formal methods, UX, management, SWE ... verified s/w and h/w. #VerifyAllTheThings. *https://grow.googleplex.com/jobs/search?query=team:%221944651479079%22 * --000000000000cfcdc105876ae9f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, 24 Apr 2019 at 18:57, Phillip= Hallam-Baker <phill@hallambake= r.com> wrote:
Nico asked about the M= esh Trust model and I said that I was trying to avoid imposing one. I do ha= ve metrics for measuring the quality of trust established in terms of a wor= k factor however:


This is not a computatio= nal work factor as we are used to. It is a social work factor nominally den= ominated in currency (USD) and bounded in time.

Let us say that we did so= me key signing even open to IETF meeting attendees only. It would cost an a= ttacker $325 plus travel minimum to impersonate me. Not an impossible sum i= f they really really want to impersonate me but enough to stop a large numb= er of attacks. Furthermore, there is a significant risk of being caught if = they attempt the impersonation on any large scale. So the social work facto= r might be $1000.

Presumably $1= ,000 buys more than one impersonation, and of anyone you want (there's = no list of who was actually at IETF, AFAIK).

-- <= br>
I am hiring! Formal methods, UX, management, SWE ... verified s/w= and h/w. #VerifyAllTheThings.

=
--000000000000cfcdc105876ae9f4-- From nobody Fri Apr 26 01:44:39 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2869120309 for ; Fri, 26 Apr 2019 01:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GC8Oo9eI2Ti6 for ; Fri, 26 Apr 2019 01:44:36 -0700 (PDT) Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D224120293 for ; Fri, 26 Apr 2019 01:44:36 -0700 (PDT) Received: by mail-yb1-xb2d.google.com with SMTP id m204so981772ybc.10 for ; Fri, 26 Apr 2019 01:44:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=t4CFNKjqK0zvEgauiYOmJtw9PMQ+ZOM7R6yTWbl6CRE=; b=kbq8wcRG6mMIFIS+nK0nBpVhA/zmltPHqPfQPc6UZP2SskJJiw9gxzeANNABOa3r8m rSzTlIXw/w6naOnL0vjbVOtOLFt5qjq46cGgAPG77I8QSE45GwUzKjywvAOU37E3IK72 1tJPTYM0DecjJ0YzI0lfTcSxzmI3LpnL9odCBEPxOCFSWR6jsOlufvNR9OR1KqZ5vnRe sGPC1cs6c/88RjXugmUj6crYsX+/5Tl9dzshpZTxkEykFcSBR8/nt+y3+6J0Prg983p4 B2/fTDzM0R3fcR+BKy5i9l7Fji027dGQkb4MDDQxH17g6gaXHEknvA2ghEV1qEmh+R4x vn9w== 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=t4CFNKjqK0zvEgauiYOmJtw9PMQ+ZOM7R6yTWbl6CRE=; b=VshviiTFNywHHJrzQIecb3G3LU7GlDuq7V3lYqxw1RX6u4WfXF4PCIuHLmtORBBAys J8Y6pCEqnwgkc2BKci2jEIIe3VhHq95eNNPwk7g2T3SpR8eAHd9Hi76poWWbdkY8NgC/ ywWD8zzVVuKDtPeeUl5+9Xkskq1Jv63rpv8J1asycmOwU6CA7MU9pUMRcBquSOemLM8f 3oNYtTbZCdliZHaVIefjkY3mig8Lx24eDXytRKcNO4WoYizX/9BWhYE9cIyVpdUypE+Q eQ0SQqf0wUJ+9OQAR/7lSSOlXaVWA9GlpC0WV9Cgb7khqSaZKBonb6cUE6BpmqvqZlyz MEew== X-Gm-Message-State: APjAAAWeruCdOHmLtkkmGVLNKhTCy/xlg16oWI3C9haWmMpgswgus38J CgCdz0KxB9xzTDe2x7BBJCx14mgw9zAx0IszvF8TUQ== X-Google-Smtp-Source: APXvYqy+83kMGOH6u1oA7wlXp8amaowXQCG3XFbzoW3RWFlqsb/2TCWlejaoKsmLhsIvIBi+bADAiP95UlqrxFMTa2s= X-Received: by 2002:a25:41c1:: with SMTP id o184mr36797906yba.183.1556268275064; Fri, 26 Apr 2019 01:44:35 -0700 (PDT) MIME-Version: 1.0 References: <20190424182641.GL3137@localhost> In-Reply-To: <20190424182641.GL3137@localhost> From: Ben Laurie Date: Fri, 26 Apr 2019 09:44:23 +0100 Message-ID: To: Nico Williams Cc: Phillip Hallam-Baker , IETF SAAG Content-Type: multipart/alternative; boundary="000000000000b6691305876af151" Archived-At: Subject: Re: [saag] Direct trust between users X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2019 08:44:38 -0000 --000000000000b6691305876af151 Content-Type: text/plain; charset="UTF-8" On Wed, 24 Apr 2019 at 19:27, Nico Williams wrote: > On Wed, Apr 24, 2019 at 01:56:40PM -0400, Phillip Hallam-Baker wrote: > > So we have an assertion that my public key is MC23-... dated 2019-Jul-18. > > It would have cost $1000 to forge that assertion before that date and > > $infinity to forge afterwards. > > ISTM that it's $1000 (or whatever) the first and _every_ time. That's > because the blockchain will have to support the "help, I've lost my one > and only device!" or "help, I've lost all my devices!" cases. > No, after the first time it costs $infinity. Better not lose your key. --000000000000b6691305876af151 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --000000000000b6691305876af151-- From nobody Fri Apr 26 07:17:31 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2E0A120145 for ; Fri, 26 Apr 2019 07:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LsxPlXIqUQ4n for ; Fri, 26 Apr 2019 07:17:28 -0700 (PDT) Received: from mail-oi1-f179.google.com (mail-oi1-f179.google.com [209.85.167.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDF4C12004B for ; Fri, 26 Apr 2019 07:17:27 -0700 (PDT) Received: by mail-oi1-f179.google.com with SMTP id t81so3025302oig.10 for ; Fri, 26 Apr 2019 07:17:27 -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=5o6OrXVcWg4EoqIzZxXavWSBSP5BKz9Wj2puppX01yI=; b=f2gbaGtTpHzt9JkEzpPaLNj3sB9Ixnr7D4yTu3rVn9NuQQSXjYr6LLxpV1QRKu8u0s v0A+NoyugXVhn62S/nRn2mZ7U+XGegBZVZh/23IDBceIIVJaSL5LQbIDkl8bUp3UfRqo erDTcIi2u73cYNC1gLdsHWoxwsJRVbT+lMHie2H81ZQsoBQX18mFmPd7VlE4untLKlRJ pjMvcvsvRliUfsZGCtsIduCW4WLTpAkqKq9uQUzXlPw5zySfLL5U6U1mYLcWfnjvFMX1 mBMiYxcfuYM77nq2hRFPm0EadMR1RdU3IjtA4sOjnMTfKPVT1Wo3RlQj+BHcwR2w+qu7 vj/w== X-Gm-Message-State: APjAAAVSA3fTjUNwYC12bF7VuAzX68z99dDzZwOHXIMZGt4L/M/6wKvg AYemvUIIocvMLHRlbieu7Lp7vFUWRmFkv8CfV40= X-Google-Smtp-Source: APXvYqwyAc0op9mtJPrkO5Jwj+8FDtQ8VIRnw90NDNbZ7Osn5X1AD6nayg8dIVm2STgwabn1WmhavChuDwmJ80s8tbY= X-Received: by 2002:aca:5a89:: with SMTP id o131mr7529593oib.17.1556288246849; Fri, 26 Apr 2019 07:17:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Phillip Hallam-Baker Date: Fri, 26 Apr 2019 10:17:15 -0400 Message-ID: To: Ben Laurie Cc: IETF SAAG Content-Type: multipart/alternative; boundary="0000000000001f252905876f984f" Archived-At: Subject: Re: [saag] Direct trust between users X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2019 14:17:30 -0000 --0000000000001f252905876f984f Content-Type: text/plain; charset="UTF-8" On Fri, Apr 26, 2019 at 4:42 AM Ben Laurie wrote: > > > On Wed, 24 Apr 2019 at 18:57, Phillip Hallam-Baker > wrote: > >> Nico asked about the Mesh Trust model and I said that I was trying to >> avoid imposing one. I do have metrics for measuring the quality of trust >> established in terms of a work factor however: >> >> http://mathmesh.com/Documents/draft-hallambaker-mesh-trust.html >> >> This is not a computational work factor as we are used to. It is a social >> work factor nominally denominated in currency (USD) and bounded in time. >> >> Let us say that we did some key signing even open to IETF meeting >> attendees only. It would cost an attacker $325 plus travel minimum to >> impersonate me. Not an impossible sum if they really really want to >> impersonate me but enough to stop a large number of attacks. Furthermore, >> there is a significant risk of being caught if they attempt the >> impersonation on any large scale. So the social work factor might be $1000. >> > > Presumably $1,000 buys more than one impersonation, and of anyone you want > (there's no list of who was actually at IETF, AFAIK). > The design of VeriSign Class 3 was intended to mitigate the risk of impersonation by making it unprofitable for the attacker. In particular it was intended to make crime impractical for repeat offenders. So the first step in the chain was to make it so that a party has to commit a crime to obtain a fraudulent certificate. The next was to limit the validity so that they had a narrow window of opportunity to make a return. So if they paid $300 for the cert, they would have to make that back in five days to turn a profit. Not impossible but requires them to make some effort and that adds cost. But even if they get away with a profit of $5K per time, that isn't going to last them long. So they have to do it again and register/impersonate another company etc. etc. And they will probably go about it the same way so that they begin to establish a pattern of behavior. And each time they do it, they are committing more crimes in the registration process. So they are either repeat offenders in one jurisdiction increasing the probability of being investigated or they are offending in multiple jurisdictions increasing the probability of being investigated. So yes, the work factor isn't insurmountable but it isn't zero either. Carl Ellison's point about ceremony may be relevant here. Lets say that the attacker attempts to register themselves multiple times. We could defeat that by binding the assertion to their conference registration number. Perhaps we print the QR code or a part of it on their badge and it can only be used once. Perhaps we also require validation to the email address they registered for the conference. At the end of the day, the data is dumped into a blockchain and so we have a tool that allows us to roll back attacks after the event. Which is why I did not suggest taking pictures of the person registering. --0000000000001f252905876f984f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Apr 26, 2019 at 4:42 AM Ben Laurie <benl@google.com> wrote:


On Wed, 24 Apr 2019 at 18:57, Phillip Hallam-Baker <phill@hallambaker.com&g= t; wrote:
Nico asked about the Mesh Trust m= odel and I said that I was trying to avoid imposing one. I do have metrics = for measuring the quality of trust established in terms of a work factor ho= wever:

This is not a computational work fac= tor as we are used to. It is a social work factor nominally denominated in = currency (USD) and bounded in time.
Let us say that we did some key signi= ng even open to IETF meeting attendees only. It would cost an attacker $325= plus travel minimum to impersonate me. Not an impossible sum if they reall= y really want to impersonate me but enough to stop a large number of attack= s. Furthermore, there is a significant risk of being caught if they attempt= the impersonation on any large scale. So the social work factor might be $= 1000.

Presumably $1,000 buys mo= re than one impersonation, and of anyone you want (there's no list of w= ho was actually at IETF, AFAIK).

The design o= f VeriSign Class 3 was intended to mitigate the risk of impersonation by ma= king it unprofitable for the attacker. In particular it was intended to mak= e crime impractical for repeat offenders.

So the first step in the chain wa= s to make it so that a party has to commit a crime to obtain a fraudulent c= ertificate. The next was to limit the validity so that they had a narrow wi= ndow of opportunity to make a return. So if they paid $300 for the cert, th= ey would have to make that back in five days to turn a profit. Not impossib= le but requires them to make some effort and that adds cost.

But even if they get away with a profit= of $5K per time, that isn't going to last them long. So they have to d= o it again and register/impersonate another company etc. etc. And they will= probably go about it the same way so that they begin to establish a patter= n of behavior. And each time they do it, they are committing more crimes in= the registration process. So they are either repeat offenders in one juris= diction increasing the probability of being investigated or they are offend= ing in multiple jurisdictions increasing the probability of being investiga= ted.

=
So yes, the work fac= tor isn't insurmountable but it isn't zero either. Carl Ellison'= ;s point about ceremony may be relevant here.

Lets say that the attacker attempts to register themse= lves multiple times. We could defeat that by binding the assertion to their= conference registration number. Perhaps we print the QR code or a part of = it on their badge and it can only be used once. Perhaps we also require val= idation to the email address they registered for the conference.

At the end of the day, the da= ta is dumped into a blockchain and so we have a tool that allows us to roll= back attacks after the event. Which is why I did not suggest taking pictur= es of the person registering.
--0000000000001f252905876f984f-- From nobody Fri Apr 26 19:16:28 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB2DD1200B1 for ; Fri, 26 Apr 2019 19:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k649LmM8BbVU for ; Fri, 26 Apr 2019 19:16:24 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4674C120086 for ; Fri, 26 Apr 2019 19:16:24 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id p14so4579687ljg.5 for ; Fri, 26 Apr 2019 19:16: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=Hr1SiMCFiXIVFv9ZpOQqYJ0YKsdbejlG0GW7HAiGlog=; b=Qzo4dTB4jOKo4Qt4EWLSQv+HvMFSEQ4a0i3k4e4hO7hkFYeecPNplWXOr9xT3BRPdt UGkw/gSm4umVgZBH+qnYsHvVnpueRY1BQ3/EoMRuBWqA8MbWhgY4UPD6xdlR4eeeSHhf jltHgnzsH2TutV883nfaU1ifInCvY0tVfyF3Q3G40BFCF6VGCRa3ps8xUyglUQddB8qK QSoI9UjZBJuh9qf7MpUT5+KaMAoHf641vDW53wUwgbeI3ohkLV9fncgNLi4/Tw/P7B8m SELubtibdYafSGF1q9a+wDvZ9qSludOPVnwqt1tqASs/gY0FVHYTZm/qARUho2MKFFYg C05A== 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=Hr1SiMCFiXIVFv9ZpOQqYJ0YKsdbejlG0GW7HAiGlog=; b=a9HG+gJj8fItzlVicUDmz1s5U5l7xfakHxRAUg14AgsB4iVcsVI82HCUaSR328eJlS iRHf9hJKEI+bEPFgF1g/C7C+WDbbvwyCBYLWFwMzgYnuubYmXwSRBwlew8DK5WzQ3FXI alkYZ45Bq/AriVo+rQMrFcwnUwO92ZuW51+E6Mo4Bu2tvjA9agFVr+8BUQ/pawA73Mix Sz/jzf1eg4TXGVLEQCRRU88X6kxBPr7yOOnLeR7m3buuf1W1OzTpHx0NJtLbxqeX68qk FoCNhbESoHY7/Y0ynRtzMVU6qtHr7RGFuQS/YgACK0dSntzmGettjFiDTGoPluYsRlPF 13IQ== X-Gm-Message-State: APjAAAV+0+kCOnN7zTfrdzmx6pU4vaPutHn3SJFv+GqBopNsC+ZqEfDZ PJsWmTXlo5bEmlt1NB8gSQxObPWgtpRTipqu5pqTDiZJ X-Google-Smtp-Source: APXvYqzLFoIdUMDq/8E4p6s+/PyllyPrzTYEb+h+a3+iNra/jR8W/CRxR61jOappEu9XCpE+Ujb7nb7QRXn/yY/t+OU= X-Received: by 2002:a2e:7605:: with SMTP id r5mr5117472ljc.161.1556331382276; Fri, 26 Apr 2019 19:16:22 -0700 (PDT) MIME-Version: 1.0 References: <20190425202212.4C6652012F0BD3@ary.qy> <1556243760613.77468@cs.auckland.ac.nz> <877832b0-4844-4421-b1f1-097eec9987a1@www.fastmail.com> In-Reply-To: <877832b0-4844-4421-b1f1-097eec9987a1@www.fastmail.com> From: Watson Ladd Date: Fri, 26 Apr 2019 19:16:10 -0700 Message-ID: To: Martin Thomson Cc: IETF SAAG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [saag] TLS signing request software other than openssl X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2019 02:16:27 -0000 I've always used https://github.com/cloudflare/cfssl at work (not surprisingly) and found it gets the job done. On Thu, Apr 25, 2019 at 7:40 PM Martin Thomson wrote: > > On Fri, Apr 26, 2019, at 11:56, Peter Gutmann wrote: > > https://csrgenerator.com/ > > That's probably OK, but it produces a private key in a context you don't want. Use it for demonstration purposes only. > > Add NSS `certutil -R` to the list. > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag -- "Man is born free, but everywhere he is in chains". --Rousseau.