From nobody Thu Mar 1 01:59:24 2018 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C599412DA49 for ; Thu, 1 Mar 2018 01:58:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01, 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 OR4O4Y25qjqg for ; Thu, 1 Mar 2018 01:58:43 -0800 (PST) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) (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 1D32D120721 for ; Thu, 1 Mar 2018 01:58:42 -0800 (PST) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.86_2) (envelope-from ) id 1erKz2-0004zv-RA for secdispatch@ietf.org; Thu, 01 Mar 2018 10:58:40 +0100 Date: Thu, 1 Mar 2018 10:58:40 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: IETF SEC DISPATCH list Message-ID: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Archived-At: Subject: [Secdispatch] Opportunistic encryption for email with pEp X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2018 09:58:57 -0000 Please be informed that the follwoing pEp (pretty Easy pricacy) work is on the way and may end up in SecDispatch for dispatching. Therefore, Richard asked me to inform also this list (besides saag and dispatch). After an introduction in SAAG during IETF-99 https://datatracker.ietf.org/meeting/99/materials/minutes-99-saag , a successful BarBoF in Singapore and many hallway discussions we learned that there is considerable interest for secure interpersonal messaging, which is at the same time also usable and interoperable with systems already deployed out in the wild. The main concept of the pretty Easy privacy (pEp) work has already been published as I-D: https://tools.ietf.org/html/draft-birk-pep Basically it is about enhanced opportunistic encryption in email (and other messaging). The Internet Society (ISOC) is diretly supporting the pEp work and it has been selected as an Innovative Projects for Beyond the Net Funding. Please find more information on: https://www.internetsociety.org/blog/2017/06/12-innovative-projects-selected-for-beyond-the-net-funding/ Just recently we published another piece out of the overall pEp work as I-D: - Trustwords (similar to the PGP wordlist or RFC 2289) to make authenticated communications easy for end-users: https://datatracker.ietf.org/doc/draft-birk-pep-trustwords/ There has been question some discusion on the saag mailing list on this. In addtion (and among further I-Ds to come in the near future), we are currently working on the following I-D (to be published as I-Ds shortly), whose early drafts your may access already: - New privacy-enhancing formats for email based upon already existing standards, e.g. PGP/MIME (minimizing unnecessarily exposed meta data, including encrypting the subject): https://pep.foundation/dev/repos/internet-drafts/file/tip/pep-email/draft-birk-pep-email-NN.txt - Rating System and Privacy Status to label secure / private types of communications: https://pep.foundation/dev/repos/internet-drafts/file/tip/pep-rating/draft-birk-pep-rating-NN.txt We are seeking more feedback on our existing work as well to find the right venue (and scope) for this work to continue in the IETF. We are also still trying to figure out whether this this work should be rather in SEC or ART. What do you think of the pEp work in general? Is this something you consider useful also for you and/or your work? If the pEp approach is interestig to you, we kindly ask you to express your opinion to this list. Looking forward to your feedback! Best, Bernie et al. From nobody Thu Mar 8 18:06:34 2018 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97DA2128954 for ; Thu, 8 Mar 2018 18:06:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y9KG7YiZUZ5Z for ; Thu, 8 Mar 2018 18:06:32 -0800 (PST) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1931012895E for ; Thu, 8 Mar 2018 18:06:31 -0800 (PST) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id w2926Usp028010 for ; Thu, 8 Mar 2018 21:06:30 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu w2926Usp028010 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1520561190; bh=V8BHkqI3OH3YGvAcKy0SYY26J7CvqWZWcbQINmVBnPw=; h=From:To:Subject:Date:From; b=g7SwElJOWwXpDcZCuSQV/O94u+fqJGM3zCREuaIekW3tWjJQfN8/sEda0CoJlujZZ Ld0QS6IebzqBncpgIB1g1rRlCRkBcwjqI0KMIbavhiFnfUDZQl6vczaFRXOu90uH+Y wjxwqYx3li/AjM4Dxiasiu4cHTt1kH5Y1ToezF9U= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id w2926TnO004137 for ; Thu, 8 Mar 2018 21:06:29 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0361.001; Thu, 8 Mar 2018 21:06:29 -0500 From: Roman Danyliw To: "secdispatch@ietf.org" Thread-Topic: Draft agenda for IETF 101 Thread-Index: AdO3SrocwuYKIQIrRLmSOUZdvTiAAQ== Date: Fri, 9 Mar 2018 02:06:28 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC0137F72A07@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Secdispatch] Draft agenda for IETF 101 X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2018 02:06:33 -0000 Hello! SecDispatch plans to meet on Tuesday, March 20, 2018 from 9:30 - 12:00. Th= e working agenda [1] is as follows: --[ draft agenda ]-- 1. Logistics and introduction (chairs, 10 min) 2. Dispatch items (Each item is 15 minutes =3D 7 min presentation + 8 min discussion) (a) A Method for Web Security Policies (security.txt) draft: draft-foudil-securitytxt-03 presenter: Yakov Shafranovich (b) Considerations For Using Short Term Certificates draft: draft-nir-saag-star-00, Yoav Nir presenter: Yoav Nir (c) Use of the Hash-based Merkle Tree Signature (MTS) Algorithm in the Cryptographic Message Syntax (CMS) draft: draft-housley-cms-mts-hash-sig presenter: Russ Housley (d) pretty Easy privacy (pEp): Trustwords concept draft: draft-birk-pep-trustwords-00 presenter: Birk Volker 3. Closing (chairs, 5 min) --[end]-- Regards, Roman and Richard [1] https://datatracker.ietf.org/meeting/101/materials/agenda-101-secdispat= ch From nobody Fri Mar 9 09:28:34 2018 Return-Path: X-Original-To: secdispatch@ietf.org Delivered-To: secdispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 81979127333; Fri, 9 Mar 2018 09:28:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.74.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , secdispatch@ietf.org, secdispatch-chairs@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <152061650352.11064.11876783383900013307.idtracker@ietfa.amsl.com> Date: Fri, 09 Mar 2018 09:28:23 -0800 Archived-At: Subject: [Secdispatch] WG Action: Formed Security Dispatch (secdispatch) X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2018 17:28:24 -0000 A new IETF WG has been formed in the Security Area. For additional information, please contact the Area Directors or the WG Chairs. Security Dispatch (secdispatch) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: Roman Danyliw Richard Barnes Assigned Area Director: Eric Rescorla Security Area Directors: Kathleen Moriarty Eric Rescorla Mailing list: Address: secdispatch@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/secdispatch Archive: https://mailarchive.ietf.org/arch/browse/secdispatch/ Group page: https://datatracker.ietf.org/group/secdispatch/ Charter: https://datatracker.ietf.org/doc/charter-ietf-secdispatch/ The Security Dispatch working group is a DISPATCH-style WG (see [RFC7957]) chartered to consider proposals for new work in the SEC area and if the work is appropriate for the IETF and there is sufficient interest, identify, or help create, an appropriate venue for the work. In order to help the proposed new work succeed, the working group aims to assist the proposed new work in: 1. Providing a clear problem statement, motivation and deliverables. 2. Ensuring that there has been adequate mailing list discussion reflecting sufficient interest, a sufficient number of individuals have expressed a willingness to contribute, and there is WG consensus before the proposed new work can be dispatched. 3. Looking for and identifying commonalities and overlap amongst published or ongoing protocol work and the proposed new work. Such commonalities may indicate the possibility of reusing existing protocols or elements thereof published by other WGs, or expanding and/or refactoring the scope of deliverables in an existing active WG. 4. Protecting the architectural integrity of IETF protocols and ensuring that new work has general applicability. 5. Ensuring that the new work considers and seeks to improve security and privacy. Precedence will be given to documents which have evidence of interest in the form of active drafts and list discussion. Options for handling new work include: - Directing the work to an existing WG. - Developing a proposal for a BOF. - Developing a charter for a new WG. - Making recommendations that documents be AD-sponsored (which ADs may or may not choose to follow). - By agreement with SEC ADs, processing simple administrative documents. - Deferring the decision for the new work. - Rejecting the new work. The WG will attempt to come to a prompt resolution of the appropriate disposition of each proposal, either on the mailing list or or during the WG meeting where it is presented. If the group decides that a particular topic needs to be addressed by a new WG, the normal IETF chartering process will be followed, including, for instance, IETF-wide review of the proposed charter. Proposals for large work efforts SHOULD lead to a BOF where the topic can be discussed in front of the entire IETF community. The SECDISPATCH WG will not do any protocol work. Specifically, SECDISPATCH will always opt to find a location for technical work; the only work that SECDISPATCH is not required to delegate (or defer, or reject) is administrative work such as IANA actions. Documents progressed as AD-sponsored would typically include those that do not have general applicability to IETF protocols, but rather are only applicable to specific use cases and network deployments, for which the scope must be clearly specified. Proposed new work may be deferred in cases where the WG does not have enough information for the chairs to determine consensus. New work may be rejected in cases where there is not sufficient WG interest or the proposal has been considered and rejected in the past, unless a substantially revised proposal is put forth, including compelling new reasons for accepting the work. A major objective of the SECDISPATCH WG is to provide timely, clear dispositions of new efforts. Thus, where there is consensus to take on new work, the WG will strive to quickly find a home for it. While most new work in the SEC area is expected to be considered in the SECDISPATCH working group, there may be times where that is not appropriate. At the discretion of the area directors, new efforts may follow other paths beside SECDISPATCH. For example work may go directly to BoFs (this is appropriate in cases of major new work which would clearly need a new WG), may be initiated in other working groups when it clearly belongs in that group, or may be directly AD sponsored. From nobody Tue Mar 20 02:14:20 2018 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 170D012420B for ; Tue, 20 Mar 2018 02:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24rt0Kz8lc7Y for ; Tue, 20 Mar 2018 02:14:16 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E87D120227 for ; Tue, 20 Mar 2018 02:14:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4091; q=dns/txt; s=iport; t=1521537256; x=1522746856; h=from:to:cc:subject:date:message-id:mime-version; bh=WKyO9qjbynChVXp8BxXLfHaIH7z7Gqa2DhvPDP9xeGg=; b=hZJjq5cYadOolH5orjxRtxR0Z143Gy3yXhxgJh1pkBM7ZyXGPVQIa7oH Z5XvgI6RyBiNyZ/2reMp7EG45ElHULwGpdYjRER/EHVwaPcYLaWxzOuQs tCk7rC4M90xpVonvVV6HJjanMuWq3XZdiIwb2cexGYDdnmTi/17dxmIsb M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CQAQBv0LBa/49dJa1eGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYJadmZyMo1wjX2DGY5zhQ+CEguFEYNKITQYAQIBAQEBAQE?= =?us-ascii?q?Cax0LhVlMEgEMdCYBBA4NhC5kql2IX4IOhTOCFYFVgVSODwOYOwkCjyqNPZA?= =?us-ascii?q?SAhETAYEpAR44gVJwFYJ+kGqQPoEYAQEB?= X-IronPort-AV: E=Sophos;i="5.48,334,1517875200"; d="scan'208,217";a="369818235" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Mar 2018 09:14:15 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id w2K9EFRl010637 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 20 Mar 2018 09:14:15 GMT Received: from xch-rcd-012.cisco.com (173.37.102.22) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 20 Mar 2018 04:14:15 -0500 Received: from xch-rcd-012.cisco.com ([173.37.102.22]) by XCH-RCD-012.cisco.com ([173.37.102.22]) with mapi id 15.00.1320.000; Tue, 20 Mar 2018 04:14:15 -0500 From: "Owen Friel (ofriel)" To: "secdispatch@ietf.org" CC: Hannes Tschofenig Thread-Topic: ATLS interest Thread-Index: AdPAK6XzWBrvaqnqS7usm4tSFXh4Fw== Date: Tue, 20 Mar 2018 09:14:14 +0000 Message-ID: <8d55e2018d5746febec06192344da493@XCH-RCD-012.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.58.98] Content-Type: multipart/alternative; boundary="_000_8d55e2018d5746febec06192344da493XCHRCD012ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [Secdispatch] ATLS interest X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2018 09:14:18 -0000 --_000_8d55e2018d5746febec06192344da493XCHRCD012ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We had a working lunch review of ATLS (draft-friel-tls-atls-00) yesterday a= nd there was sufficient interest in the room to continue refining the propo= sal. ATLS is seen as addressing some real world problems but there are some= concerns and issues with the approach that require further discussion. We = would like to raise and discuss this at SECDISPATCH and hopefully reach con= sensus on one of the following paths forward: - dispatch to an existing WG - make a new mini-WG Rgds, Owen, Hannes --_000_8d55e2018d5746febec06192344da493XCHRCD012ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We had a working lunch review of ATLS (draft-friel-tls-atls-00) y= esterday and there was sufficient interest in the room to continue refining the proposal. ATLS is seen as addressing some re= al world problems but there are some concerns and issues with the approach = that require further discussion. We would like to raise and discuss this at= SECDISPATCH and hopefully reach consensus on one of the following paths forward:

- dispatch to an existing WG

- make a new mini-WG

 

Rgds,

Owen, Hannes

--_000_8d55e2018d5746febec06192344da493XCHRCD012ciscocom_-- From nobody Tue Mar 20 04:35:15 2018 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC23B126DC2 for ; Tue, 20 Mar 2018 04:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] 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 H64DQgXcBSS2 for ; Tue, 20 Mar 2018 04:35:11 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) (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 A9E8D1200F1 for ; Tue, 20 Mar 2018 04:35:11 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.86_2) (envelope-from ) id 1eyFXp-0005NX-Rt for secdispatch@ietf.org; Tue, 20 Mar 2018 12:35:09 +0100 Date: Tue, 20 Mar 2018 12:35:09 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: IETF SEC DISPATCH list Message-ID: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Archived-At: Subject: [Secdispatch] Hands-on Session pEp & Trustwords / Wed 21.03.2018 / 10:30 / Waterloo X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2018 11:35:14 -0000 For those of you who want to know more about the pEp architecture and how Trustwords are used in this context we offer a short demonstration of the running code on Wed 21.03.2018 / 10:30-11:30 in meeting room Waterloo. c.u. Bernie et al. -- http://ucom.ch/ Modern Telephony Solutions and Tech Consulting for Internet Technology From nobody Thu Mar 29 09:45:39 2018 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB7B012E044; Thu, 29 Mar 2018 09:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, 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=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 GIxH2NeJiHZN; Thu, 29 Mar 2018 09:45:32 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2A5212420B; Thu, 29 Mar 2018 09:45:31 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id e8-v6so5723565oii.4; Thu, 29 Mar 2018 09:45:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=n2jEbCixnUbo5RYP2TxSJUD4d0mZgYNuPNTn1qcphBg=; b=K6nnmxdCQ9kEh2+hXo1hxPZcbVJKh0romqQvLuCf9SCTxW+vBw+k/Z3xAiLDS+JKIf DU7amunwHDjc3lallGX/FDQgTfkHhH7GWtkMj9QbUzf8wBDZSpvNnLc3vJ96P8qw7lum b57+81/swk0Xlx6micATVZ1Es8M4It3QgRTtrIEfJzAHexBuuv6oMhNujnx1qR6kAnt6 z5PV8QZK0RxP7/NX7FfENxKaweaezGHkE6vs75oyqXlyCPE2/V8rcBwFKghQbSyHNpxy m12I0xz8Rf1j1U3WVw3a5X4fYfu984ma1c3HLUMPiARu02DafQyJph50CM1S0uCRjMuV RbcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=n2jEbCixnUbo5RYP2TxSJUD4d0mZgYNuPNTn1qcphBg=; b=AMStZwCZkkjGv/QvStDezaXgZcTAA9s70apBq+beWZ48OrIvtWqb2iGX2HNuD/MNLg WgemLTdodLuYTZsmpK3ytIs6StbSrC8rpoN9kqG6+8iUhavSgO0IHbPKVBEVlMQVZ4wG P1TwZJTBIZ6FutZnTjOoq8uzdXxvqqZvCuBlxhNDfRYzowA+vJ1QK2LiSUWPXelPbyoj iq/P3Y4jSrHDb3JGOxdKt3I5h85CflQt0mg+lG0qFl2ngwX1K+b9+V/KIbGl/Ld8pxDj 5PaFbDuPxR8ECzJJxEUf+eHnX06OgdFv7gbAl+AKjRdZvGVKCfSiUqzrn+hijtcYy33D GXqQ== X-Gm-Message-State: ALQs6tB5WiOq3MzrwqEfMKKr2yGhG0BivD9Qq/rv/SCzwKoVA9axCkyk 9VKQIhBdNX0rjikEwrdisWEtWk90Jg6xQbG4faMIuw== X-Google-Smtp-Source: AIpwx491/s9HdFzFLkvJMRIjMQpd8Gy0R6zQwfWuOsNrEu48TBOxhOBUlY6fH9MwNej36hc9ILHoGCFNt4AblNjjKGI= X-Received: by 10.202.168.207 with SMTP id r198mr5118714oie.180.1522341930595; Thu, 29 Mar 2018 09:45:30 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 2002:a9d:233c:0:0:0:0:0 with HTTP; Thu, 29 Mar 2018 09:45:30 -0700 (PDT) From: Phillip Hallam-Baker Date: Thu, 29 Mar 2018 12:45:30 -0400 X-Google-Sender-Auth: oiFKc_f7LgGyK2r7wn_6E-huAVs Message-ID: To: dnsop , secdispatch@ietf.org Content-Type: multipart/alternative; boundary="001a113cd5e00002e405688fdad3" Archived-At: Subject: [Secdispatch] Request for guidance on SIN X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2018 16:45:36 -0000 --001a113cd5e00002e405688fdad3 Content-Type: text/plain; charset="UTF-8" Strong Internet Names is a concept that I have been developing for about 4 years now. It is an extension of concepts that Brian LaMachia and team applied to the design of dotNET security with great success and I think it has value applied at the network level. The current draft can be found in HTML format here: http://mathmesh.com/Documents/draft-hallambaker-sin.html The related draft describing UDFs can be found here: http://mathmesh.com/Documents/draft-hallambaker-udf.html The question I would like to pose is which group to raise the work in as it is a security specification with DNS implications. This is one of the technologies I am using to build the mathematical mesh but it is not limited to that application. The relationship is similar to that of URIs to HTTP, they are both used in the Web but URIs are much wider in scope. The basic concept of a SIN is to bind together an Internet address and a security policy that constrains the interpretation and use of that address. For example, Example Inc holds the domain name example.com and has deployed a private CA whose root of trust is a PKIX certificate with the UDF fingerprint MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ. Alice is an employee of Example Inc., she uses three email addresses: alice@example.com A regular email address (not a SIN). alice@mm--mb2gk-6duf5-ygyyl-jny5e-rwshz.example.com A strong email address that is backwards compatible. alice@example.com.mm--mb2gk-6duf5-ygyyl-jny5e-rwshz A strong email address that is backwards incompatible. These are addresses that can be entered into the contacts directory of any existing email client. Note the use of the mm-- prefix to identify this as a SIN. Existing policy means these labels cannot be issued as ICANN TLDs etc. That coupled with the fact that accidental collisions are statistically improbable and these names are as robust as is possible. Putting what is functionally a superset of an OpenPGP fingerprint into a domain name means that we can cryptographically harden any system. This is not necessarily a construct that would be put in front of a user, most of the time we use SINs in the mesh it is to record the outcome of a trust decision. So in the example above, Alice might give me her business card, I send her an email and when she replies, there is a header giving me her Strong email address which is bound to a security policy such as 'always use end-to-end encryption with either S/MIME or OpenPGP and here are my keys'. Certificate Authorities are currently employed as trust providers. In the SIN model, we can limit their role to that of Trusted Introducers who are only required to make the initial connection. There is of course an infinite amount of complexity in the specification and application of security policies. And the design of UDFs takes account of that with a construction that provides for isolation of semantic domains. What I want to do at this point is to get the foundations laid to allow us to build interesting stuff. The interesting stuff itself is a separate matter. --001a113cd5e00002e405688fdad3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Strong Internet Names is a co= ncept that I have been developing for about 4 years now. It is an extension= of concepts that Brian LaMachia and team applied to the design of dotNET s= ecurity with great success and I think it has value applied at the network = level.

The current draft can be found in HTML format here:
http://mathmesh.com/Documents/draft-hallambaker-sin.html
<= /div>

Th= e related draft describing UDFs can be found here:
http://mathmesh.com/Documents/draft-hallambaker-udf.html
<= div class=3D"gmail_default">

The question I would like to pose is which g= roup to raise the work in as it is a security specification with DNS implic= ations.

This is one of the technologies I am using to build the mathematical = mesh but it is not limited to that application. The relationship is similar= to that of URIs to HTTP, they are both used in the Web but URIs are much w= ider in scope.


The basic concept of a = SIN is to bind together an Internet address and a security policy that cons= trains the interpretation and use of that address.

example.com and has deployed a private CA whose root of trust is a= PKIX certificate with the UDF fingerprint MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ.

Alice is an employee of Example Inc., she uses three email addre= sses:

a= lice@example.com
A regular email address (not a SIN).
alice@mm--mb2gk-6duf5-ygyyl-jny5e-rwshz.example.= com
A strong email address that is backwards compatible.
alice@example.com.mm--mb2gk-6duf5-ygyyl-j= ny5e-rwshz
A strong email address that is backwards incompatib= le.
These are addresses that can be entered into the contacts directory of any = existing email client. Note the use of the mm-- prefix to identify this as = a SIN. Existing policy means these labels cannot be issued as ICANN TLDs et= c. That coupled with the fact that accidental collisions are statistically = improbable and these names are as robust as is possible.

Putting what is func= tionally a superset of an OpenPGP fingerprint into a domain name means that= we can cryptographically harden any system.


This is not necessarily a construct that would be put in front of a = user, most of the time we use SINs in the mesh it is to record the outcome = of a trust decision.

So in the example above, Alice might give me her busines= s card, I send her an email and when she replies, there is a header giving = me her Strong email address which is bound to a security policy such as = 9;always use end-to-end encryption with either S/MIME or OpenPGP and here a= re my keys'.

Certificate Authorities are currently employed as trust prov= iders. In the SIN model, we can limit their role to that of Trusted Introdu= cers who are only required to make the initial connection.

There is of cours= e an infinite amount of complexity in the specification and application of = security policies. And the design of UDFs takes account of that with a cons= truction that provides for isolation of semantic domains.

What I want to do= at this point is to get the foundations laid to allow us to build interest= ing stuff. The interesting stuff itself is a separate matter.
--001a113cd5e00002e405688fdad3--