From nobody Wed Aug 5 20:35:21 2020 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 F1FC03A0DC9; Wed, 5 Aug 2020 20:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhZRs6MvVBI9; Wed, 5 Aug 2020 20:35:03 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B46F63A0DCA; Wed, 5 Aug 2020 20:35:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 00C6B389AA; Wed, 5 Aug 2020 23:14:21 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id r2qNV-yGByKc; Wed, 5 Aug 2020 23:14:19 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 68A3F389A9; Wed, 5 Aug 2020 23:14:19 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A669C63E; Wed, 5 Aug 2020 23:34:58 -0400 (EDT) From: Michael Richardson To: "saag\@ietf.org" , t2trg@irtf.org, secdispatch@ietf.org CC: Leif Johansson , Robin Wilton In-Reply-To: <47C264DC-D59D-49E8-B087-BAF0E23527DD@ericsson.com> References: <47C264DC-D59D-49E8-B087-BAF0E23527DD@ericsson.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [saag] idevid-considerations at -- SecDispatch/IETF108 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, 06 Aug 2020 03:35:05 -0000 --=-=-= Content-Type: text/plain Francesca Palombini wrote: > The SECDISPATCH WG met on Thursday July 30. The agenda items were dispatched as follows: > (1) IDevID considerations (Michael Richardson) > * specification: https://tools.ietf.org/html/draft-richardson-secdispatch-idevid-considerations-00 --> Needs vendor involvement - get more people from the industry and then > possibly bring it back. Hi, so I heard the feedback strongly to go talk to more industrial/manufacturing types. It was also suggested that T2TRG would welcome it. https://mailarchive.ietf.org/arch/msg/t2trg/E05g95AX3DUlS0_mBQH4DwcfLBc/ with a possible title of: A Toxonomy of Operational Security of manufacturer installed keys and anchors A pointer was sent me about RFC6711: An IANA Registry for Level of Assurance (LoA) Profiles This might be fine as a place to store/reference the palette of mechanisms, but it does not, I think, help in creating the content of each palette. It references: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-assurance-profile.html But, I didn't quite understand it. I think that it's about communicating between verifiers and relying parties, the degree to which the verifier has validated the identity of a SAML Identity. Kantara Initiative Identity Assurange Framework (KIIAF) was referenced, and Kantara Initiative was also mentioned by private message during secdispatch. Kantara is, as far as I can understand, a conformity assessment and assurance entity, which works against NIST 800-63-3. I hope to have further conversations with them. So, going to that NIST document, which was also mentioned: https://pages.nist.gov/800-63-3/ This document has a lot of commonalities, but yet it is not about how keys are protected. It is about how to communicate about the confidence an entity has about the identities it is asserting. It is "Identity Proofing" for humans. Now, NIST SP 800-63B _Authentication and Lifecycle Management_, has lots and lots of good stuff. Nothing that says how to evaluate how many intermediate CAs are appropriate when issuing certificates to put into the hardware authenticators. It's clear that this document is relevant to a manufacturer who might need to consider how to authenticate and authorize access to private keys. For instance, AAL2 (maybe even AAL3) is probably appropriate for access to the signing key for a software update. (There is an interesting recursive element here where where cryptographic authenticators are used...) NIST Special Publication 800-63C: _Digital Identity Guidelines: Federation and Assertions_ deals in SAML, OpenID Connect, and Kerberos, at the level of assertions, not keys. Really nice diagrams. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8remIACgkQgItw+93Q 3WWgiwgAwIHq5SJlanSdyL5TaGBaJkPXrMF8c32sZRwpDGMzFIVe4ZyAX6hvRies Ud4h9bOVNFwlcWLhFEcGFhHdPu8xq1lkLXTFheGztMRjVItOh4ofqrfJQSMvTIOd XWVV4p+rUFMBMPCCyUKD6AZR6euAK/UsSrXELYvmnlAXIYenxW41S63yNWmtIPd+ 0f065oIMPmwBReKNIDnZqpOtxITg1EQTHvIsnW1K4OL576NSEhbhL7hGz2XrJP2e aTJQj5nfwrI7i5LYinQ5Mfl4e0AVgq0L1Pv/4BxxxL7MiNEYP2B5YQrwZFaSH18z 3NR7Bf54B6bjL5VF+LLoDYCwe/eC5w== =GlfP -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 11 15:42:11 2020 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 6FCC23A0D6D for ; Tue, 11 Aug 2020 15:42:09 -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, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 unW9hp3Brdzf for ; Tue, 11 Aug 2020 15:42:08 -0700 (PDT) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 026873A0D66 for ; Tue, 11 Aug 2020 15:42:07 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id t6so76916ljk.9 for ; Tue, 11 Aug 2020 15:42:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Ilmjnxvi68jEfTI+NI/Hllgd/QZlVqRMj7xzMqufDyo=; b=SBMHGzDqABBzZMuKZMA7eMiIVvdA6uZgRSnzKE4beS4NvjCXh/O1sQO+8qpV3xbC5W dKcwmXnL608JmhM9/V3n+aWo81mMcl9JXFtXyE97Mq2JtAqCu/wzM7SUEq5heMe1k6Xd YBXx+QBezDoyBag6cqoewF1L9xYjRobYQczihyHS3sMA1nfJuBc4245XkO9ZsyqjUeBO MeJBWR+ji3mzTUx5MtlG0YyaA9gGJD4gjMQ2b1YrcvcdIwkatRyHjpVPv3vHdbhh6hAn 3kXPavwTeO2S047UAYByvzGh15WKIkSNMbn+1bXnIACunpUhB5ZRhYelr/6fGfzT1q1V JQAw== 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=Ilmjnxvi68jEfTI+NI/Hllgd/QZlVqRMj7xzMqufDyo=; b=FjaVX1VhIAc+ksf/+anCDXGiY4djD+4D8T43zCA/Ti8u5urWUhvqFIjcvWVmfh+aT0 h8wLVydJOa7wRJVmzYe8z7nlCh18a/HzhS47KatZfsD2bANPKsirkcOUkabJ+ZmVBS1F RUvp7sggVEPX/rnuGKDLbeY44yDh7QiAb6DVptE+EU3nZzNECrV5fparDE9IwsnPgVYs S0oQTx1krtM0K3KPMXGvvYOTD6RDZj9pj7cNTCe1k8CvsucoIlp1IncsRAQT9xveRT3p NWu8dlCnOUm/uHBNJCwc7QylFqYHRpXHgxg5yOVGO+7dcrizkFjc/jAqxxQoAY0ZldWe oX5g== X-Gm-Message-State: AOAM532BwPKMXN9JrOWMhdHU6UipZ+NyWr99xJqAeNJBc9zaxOBd3Fgn AIsuRuNl6I5fm7reCgBmgN1Xi5w0v0fF9g1wCvuqF8cYiu8= X-Google-Smtp-Source: ABdhPJwYkuJ6gzDQZeaoYt85bPIqHdnx5e7pDcwTtVj+GoouOX+A7FyKrSa/ea4v2iquX3E2d2lsphKvQqfh5EiDgvI= X-Received: by 2002:a2e:86d6:: with SMTP id n22mr3688511ljj.440.1597185725725; Tue, 11 Aug 2020 15:42:05 -0700 (PDT) MIME-Version: 1.0 From: Watson Ladd Date: Tue, 11 Aug 2020 18:41:54 -0400 Message-ID: To: IETF SAAG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [saag] Author promotion of draft-ietf-ntp-roughtime-01 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, 11 Aug 2020 22:42:10 -0000 Dear SAAG members, I'd like to elaborate on Karen's notes on draft-ietf-ntp-roughtime-01, and explain why members of this group might be interested in it. Roughtime is certificate transparency for time. A roughtime server signs its responses and places them in an linear hash structure permitting incorrect answers to be found and exposed. The security of this mechanism depends on having a broader ecosystem of applications use roughtime. Any application involving approximate global time synchronization for security can make use of roughtime. Applications to X509 certificate, Kerberos, etc. are clear. Consensus mechanisms such as the Tor Directory Service are also interested in making use of it. I'm sure there are many more potential applications readers of this mailing list may think of. If this sounds interesting i'm happy to discuss it further on the NTP WG mailing list or privately. Or here, if it is too off-target. Sincerely, Watson Ladd From nobody Sun Aug 16 23:17:00 2020 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 C46633A09C5 for ; Sun, 16 Aug 2020 23:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 cZpaMZaDj6vL for ; Sun, 16 Aug 2020 23:16:57 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47D573A09C1 for ; Sun, 16 Aug 2020 23:16:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id C8244389E4; Mon, 17 Aug 2020 01:56:05 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id OWD1jEUu2T4D; Mon, 17 Aug 2020 01:56:04 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B4D40389E3; Mon, 17 Aug 2020 01:56:03 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4EEAA373; Mon, 17 Aug 2020 02:16:53 -0400 (EDT) From: Michael Richardson To: Stephen Farrell , Benjamin Kaduk , saag@ietf.org In-Reply-To: <1c4951d6-a67c-47c6-315e-2ad3776c94ec@cs.tcd.ie> References: <20200728191331.GV41010@kduck.mit.edu> <20200728194235.GY41010@kduck.mit.edu> <1c4951d6-a67c-47c6-315e-2ad3776c94ec@cs.tcd.ie> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [saag] On PKI vs. Pinning (SAAG 108 preview) 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, 17 Aug 2020 06:16:59 -0000 --=-=-= Content-Type: text/plain {trying to catch up on this thread} Stephen Farrell wrote: > On 28/07/2020 20:42, Benjamin Kaduk wrote: >> Sorry for the clumsy description. Basically, if you squint hard, you could >> claim that at least some types of pinning are actually a PKI, just a >> degenerate PKI. > Ah gotcha. > ISTM more useful to treat pinning as an adjunct to whatever > PKI is used by the application that can be MITM'd and not > bother with pinning as a potential replacement for that > PKI. There's nothing wrong with an application being based > on it's very-own PKI of course, but seems less useful for > the IETF to try describe pinning for custom protocols where > we don't know the details. Why would the protocol detail matter? It some protocol (could be well known), that has a custom, non-CABForum mediate, trust relationship. So, basically, ALL of IoT: whether Web Connected devices that only ever call home, or Information Centric Network IoT based systems of the future. All of the remote attestation systems are based upon various amounts of private-PKI pinning as well. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl86INUACgkQgItw+93Q 3WWLLQf+LBQIqaLzKv/++W5mysAkxjV+MBussL22Yto9Kcf6xEJP6OxqDd5WiVgO t+bzdn8jsj/MB3/emINUkBzRNLo6KLrgndunS9RmQ8ZGWfsCRl9xlhri2rpzI4z9 NqkKcPfNwhZSAGwTyGEBK2Se7v6hC6DEswG/XgBk22+CLuUKK8c7/j4Fp9lXK+zb 2bCpPlPwsAtE3T0t79vq1Gx8HulSoFKAv2G1mcWTB2OaS44b66l4bp2f0MtERRHC WaT7O1LoDXeppTVqfrRwjo1PYlTPKMg6CypAn9/cOOLb2HdOqiGqOQaxgqsN+KqC O49u2fThb8uVeC0kyK/XTVyGAGbvEg== =O78c -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Aug 16 23:24:14 2020 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 DAB8B3A09C9 for ; Sun, 16 Aug 2020 23:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 nm2ljZaapRQW for ; Sun, 16 Aug 2020 23:24:11 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60B443A09C1 for ; Sun, 16 Aug 2020 23:24:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 3F4B5389E4; Mon, 17 Aug 2020 02:03:20 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ByMkKdzCowud; Mon, 17 Aug 2020 02:03:19 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 04F69389E3; Mon, 17 Aug 2020 02:03:19 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9319F675; Mon, 17 Aug 2020 02:24:08 -0400 (EDT) From: Michael Richardson To: Eric Rescorla , Benjamin Kaduk , IETF SAAG In-Reply-To: References: <20200728191331.GV41010@kduck.mit.edu> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [saag] On PKI vs. Pinning (SAAG 108 preview) 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, 17 Aug 2020 06:24:13 -0000 --=-=-= Content-Type: text/plain Eric Rescorla wrote: > Pinning on the Web [RFC 7469] is now more than five years old and in > the intervening period, opinion has shifted, with people increasingly > believing that pinning was too brittle a feature to deploy safely. > For this reason, Firefox and Chrome have both deprecated pinning (I > believe that Safari and IE never had it). So, to the extent to which > there is a consensus, its that pinning is not a best practice. Are there some reports, threads, or port-mortems that would allow people to understand the nature of the brittle-ness? Without attempting to disagree, I can see all sorts of things that could go wrong, but I'd like to understand what did go wrong. (If this conversation happened in an IETF list, then which one would probably be enough for me to track it down) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl86IogACgkQgItw+93Q 3WUpCwf+Pt5tylw8+mF+iL41kh5eWpHMogYV1u83+d23TSeDaBNlRfvoiPvpLr75 6mLJp9HMs15Tk3K9SCgXYtNcDL3Cs6cPo15DMeNpEo0hhbtIbly4tkG2Hmwfm7LU Pkte09uWqraCyr4zvBnUiXtBf6HHWYeRqZUH110OznkvUnGWjopTj9sjn8rPb46n FfQFl2ut3flzYibi9y4BdFTCcLEEVfBXlt2bx9qudkvNkjDCZQXoEer5th2meSom 60l/d/zhPcxiua23uqZoJqJBv/RKsh/ej0qFZ8RTTOo/S5ZijlxUuHb+x3+xUhOy yCuLoYrWVdTeGrH+o5cg8XGq5NSP1A== =oQOZ -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Aug 16 23:47:16 2020 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 9BC6D3A09F3 for ; Sun, 16 Aug 2020 23:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=F/z8hkQA; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=cNk8cW8n Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J15sFautfk3I for ; Sun, 16 Aug 2020 23:47:13 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 584263A09F2 for ; Sun, 16 Aug 2020 23:47:13 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 8C3575C0098 for ; Mon, 17 Aug 2020 02:47:12 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Mon, 17 Aug 2020 02:47:12 -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=fm3; bh=bZPEwyOobG68VCD2Ft8z1q1m5AhTKzT KbTlGNFexhYg=; b=F/z8hkQAD7StIpLNIAbR08HuBzEJ7ytaNIX0BF/9kk3OEnb bOOduym85DV7my4E+02fS5cCuOReiapnFXWm/DYmnmE4yrGKgUpcZlBWsdBBFXE8 JspjQg3AaJ3sjAL+XN34tG4/5hQESfvhdWhyokzKz/vNPz22U9vh67z3lD1AdtTr uXE62bS1pHJ4kP7RM74m0vlmAbcyVDNroR9CRmqSAAdFaHtEHhVGgPDEPpsN+TJK HPuRaCGDSfIPjGS+Qn5ottOwd0QE6iAEkic8XgjuWrzqyPWlJ+l4yL7IR316Zo43 6U2I2uTAmNX56+SVtpg87CDNTv48f77PEVNE+6w== 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=fm3; bh=bZPEwy OobG68VCD2Ft8z1q1m5AhTKzTKbTlGNFexhYg=; b=cNk8cW8nNrOpy12KInA5xC E/wW9rY2JHznzreQ2p+g/9aqQLqSRnSC8IrqYxsY9UcIQWV0FDMbcCAKWklpugy9 CfxHNO+kZT8pf25z0eiSi8hPwlCVleylQM+HSY2j03+CmQ8VQcw2TCRACroFv9TZ PuVHSkhMkecCOo4gfB04XS/K9f5Fl2CmQCCEw0w4mADStQErt3ed2KDlurHIxEwb 0vFumbl6taIIeW54ocsZPonFLe9ZFy1JvQbbo+jzX6TKKq1MGCo6T+2T/1y2WJ+H RhqIF7uABRKFtt5cWiH2S8ASLWdRGvHp/YMhAGM5RZngun2NJJXuBIEi6Pi0qUaA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddtvddguddtkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecuogfuuhhsphgvtghtffhomhgrihhnucdlgeelmd enucfjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfofgr rhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenuc ggtffrrghtthgvrhhnpefgieevueeiieduleeihfellefgteegfeehveegteejvdelkeel leetjedvleeijeenucffohhmrghinhepghhoohhglhgvrdgtohhmnecuvehluhhsthgvrh fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhp hidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 45467E00BF; Mon, 17 Aug 2020 02:47:12 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-192-gd9d7a78-fm-20200816.001-gd9d7a786 Mime-Version: 1.0 Message-Id: <54338c62-4a3d-4ccf-a555-c40ba95005dc@www.fastmail.com> In-Reply-To: <14373.1597645448@localhost> References: <20200728191331.GV41010@kduck.mit.edu> <14373.1597645448@localhost> Date: Mon, 17 Aug 2020 16:46:52 +1000 From: "Martin Thomson" To: saag@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [saag] On PKI vs. Pinning (SAAG 108 preview) 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, 17 Aug 2020 06:47:15 -0000 On Mon, Aug 17, 2020, at 16:24, Michael Richardson wrote: > Are there some reports, threads, or port-mortems that would allow people to > understand the nature of the brittle-ness? Without attempting to disagree, > I can see all sorts of things that could go wrong, but I'd like to understand > what did go wrong. https://groups.google.com/a/chromium.org/g/blink-dev/c/he9tr7p3rZ8/m/eNMwKPmUBAAJ contains a pretty good summary. From nobody Mon Aug 17 00:02:56 2020 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 4474B3A0808 for ; Mon, 17 Aug 2020 00:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.949, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeaunAacTHeW for ; Mon, 17 Aug 2020 00:02:52 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39BFA3A0801 for ; Mon, 17 Aug 2020 00:02:51 -0700 (PDT) Received: from xse120.mail2web.com ([66.113.196.120] helo=xse.mail2web.com) by mx18.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1k7ZAD-00020n-4d for saag@ietf.org; Mon, 17 Aug 2020 09:02:42 +0200 Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 4BVQ2X5nLBz591j for ; Mon, 17 Aug 2020 00:01:56 -0700 (PDT) Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1k7Z9Y-0002lm-MX for saag@ietf.org; Mon, 17 Aug 2020 00:01:56 -0700 Received: (qmail 32196 invoked from network); 17 Aug 2020 07:01:56 -0000 Received: from unknown (HELO [192.168.1.107]) (Authenticated-user:_huitema@huitema.net@[172.58.43.0]) (envelope-sender ) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 17 Aug 2020 07:01:56 -0000 To: Martin Thomson , saag@ietf.org References: <20200728191331.GV41010@kduck.mit.edu> <14373.1597645448@localhost> <54338c62-4a3d-4ccf-a555-c40ba95005dc@www.fastmail.com> From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mDMEXtavGxYJKwYBBAHaRw8BAQdA1ou9A5MHTP9N3jfsWzlDZ+jPnQkusmc7sfLmWVz1Rmu0 J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PoiWBBMWCAA+FiEEw3G4 Nwi4QEpAAXUUELAmqKBYtJQFAl7WrxsCGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgEC F4AACgkQELAmqKBYtJQbMwD/ebj/qnSbthC/5kD5DxZ/Ip0CGJw5QBz/+fJp3R8iAlsBAMjK r2tmyWyJz0CUkVG24WaR5EAJDvgwDv8h22U6QVkAuDgEXtavGxIKKwYBBAGXVQEFAQEHQJoM 6MUAIqpoqdCIiACiEynZf7nlJg2Eu0pXIhbUGONdAwEIB4h+BBgWCAAmFiEEw3G4Nwi4QEpA AXUUELAmqKBYtJQFAl7WrxsCGwwFCQlmAYAACgkQELAmqKBYtJRm2wD7BzeK5gEXSmBcBf0j BYdSaJcXNzx4yPLbP4GnUMAyl2cBAJzcsR4RkwO4dCRqM9CHpVJCwHtbUDJaa55//E0kp+gH Message-ID: Date: Mon, 17 Aug 2020 00:01:57 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <54338c62-4a3d-4ccf-a555-c40ba95005dc@www.fastmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: 66.113.196.120 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.120/32 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.120/32@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0Uc1Z+hCSaILZIw3vLzlsGSpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDRitNmXY60Gx0fFyUeQSRQrgN zB/4Jkrw1eDLcif59fsw/7YcgiyvdoTW3OQthRppU7Tmz6iKnkQL9gqsxD347235Nhqq+/HvroPq 8GSPg+5hmwN8D4LrepG7AX8WNwY8PM2DmctUkuqITdPZ8a3LuY6jSvfpO+1kZkomjtjB6X5Q5Q9f RUeIpTIC2ySfqvnqLwoxlgatmaBb0rBiK9xbkDrUqzcKIief90MVLZY9LbIZh9+IQ1oS9LBn3VIP 95Jz7ujRlJ9wSMlhvaudJXZ9EIBG/qaR+8r9SKFMmPJLf850OvZYsmoVQuOIhwKLK6IKBNB4LZ0v UHHKTzJX7b1JhLSQQ4vSj0QEim26t/Moy0UPX5E73H1QfrH/5kkrV/Cr0bm2vWdo8usP65i82q1C dZgGrpL44wdx9eXqjQjbvUopOMQJvQ/Ck3iiU+4DQAj3fuQgzT3K9JUHTNiGwfwAmxx/Wk8McinP JEkgAVrOMpbIPHELHGuybVREcKQKsZ6S1kjg+NKRrKIDnF1ThD/8TTJXmqb8O8/nP1Gt+YUjOUQM 7OYFXYdC3tRq275m/U3V7OFvG/1yXVH9RY+SEJToqbdCp3Zd9clP8wSiJZWbJCj+xRrjVmRxpGtS cvUmgj1LQo1sCdgL9lhJm+QsLubW+V2jZAOanSBpz6Rja2u/0jLeWWPm4E48zThm0HLakvqeOw7P HsRiBR86YLF+dfGmLPysta6u1iHEyuS7GD1uvcq3Ec8vk9L+CuOgr19H0qBcJOYIJd4MvQ0Nf4Ec bvHO1diDanHV9KirFAIIecsyj+YNTo81GR+jDXFsz/ZQnbbTizvwlZsrbltGiZoUh+c+5pFVgpT1 b21uZVckGp0ccOa2XhkGbmsUNPNkere1WheNsVXmhO8BzADiszcWR9bz/SDtF09JpSbuuCeiIDK0 C/0= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [saag] On PKI vs. Pinning (SAAG 108 preview) 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, 17 Aug 2020 07:02:54 -0000 On 8/16/2020 11:46 PM, Martin Thomson wrote: > On Mon, Aug 17, 2020, at 16:24, Michael Richardson wrote: >> Are there some reports, threads, or port-mortems that would allow people to >> understand the nature of the brittle-ness? Without attempting to disagree, >> I can see all sorts of things that could go wrong, but I'd like to understand >> what did go wrong. > https://groups.google.com/a/chromium.org/g/blink-dev/c/he9tr7p3rZ8/m/eNMwKPmUBAAJ contains a pretty good summary. The web server prompts for a login. Is there a publicly available version of that document? -- Christian Huitema From nobody Mon Aug 17 04:30:43 2020 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 E07AD3A14D5 for ; Mon, 17 Aug 2020 04:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.524 X-Spam-Level: X-Spam-Status: No, score=-0.524 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, MALFORMED_FREEMAIL=1.573, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZYPJBwnQzP7 for ; Mon, 17 Aug 2020 04:30:40 -0700 (PDT) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 A0D0E3A14C2 for ; Mon, 17 Aug 2020 04:30:40 -0700 (PDT) Received: by mail-wm1-x32a.google.com with SMTP id 184so13598621wmb.0 for ; Mon, 17 Aug 2020 04:30:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:message-id:thread-topic:references :in-reply-to:mime-version:content-transfer-encoding; bh=kJ6RlAQYmHCxwsWsmJV/ToM9fxZEskvMAoTRHPcj3Us=; b=WPjw6vCltam+JXcv7ruLRy0qVlrzPlDJUAT54izAI9al7t4Q3R4lOePf/yYsH6kvFU XpK2coKHb8QFwzXymP6bh/I5YRHZp57ohfMiuEqfrmtyExLUkJmGCXX7jGIW3yoXz+b3 aFzYvDKBxWKJ+z+bTHiuohAp5ieVUDMBWm+7err166RsW6cLHV/y6h7/0G90EKB36K/T Csn0Ox2C7f1GDPaMMy955GFOkaF6CrHZEm9jbMP32k8O4DtiiVSLyrOMxwv8d3r4Qjjg lvhsZAZd3wd+u32IHuFPOGNLpQRro1Fd8+Q5POmHG8Qqwd7c1fdv74SFnjG3Yei3ZJd7 5P7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=kJ6RlAQYmHCxwsWsmJV/ToM9fxZEskvMAoTRHPcj3Us=; b=FHgiHqUszZ+GR6bIWzVetgNTRQhg6ulpGRYmUgLXHqPAxElL3/iY2pQDTqZcKwK5VH 6b2lc1kgoxEKv/T6coQ6FX3obAAax+B09Dzlej/0pou/ynuaj/iUnA6w3cwIyAxDn4Di vAsDHqPG3Hov5I8xJm5vja6Vz1pw0QkUpaEZnyQZcXocJojsYuYJPR12Qa2Xijd3ov5P STjdS7bs2dNP8/NPzVj2fsPTmpU0bI8bjWLfpVo1cKPF4XxcnO9ghdBqgrJT910DfTEZ rFrFzmngcUK9eXo4sXTgvh9Dm8qh2yxH2KbXOqMlOx1kxUExCfsQm9fZ5JwmMaPWcqcW bD6w== X-Gm-Message-State: AOAM533jSAFVTWwkCDTnmP9YHrh7e+lpdnsmN0u5X/TiPd9lLgyduEmR cejSzEqvyJkU23I01XRTVZPU1FkgPp7PMQ== X-Google-Smtp-Source: ABdhPJxy79x/1FdmjH/RnFTQbfbeH1C8oIeiX7vOnTiS4r/5adcDAW44vJeFTfGeOg5eNsasYZlw5A== X-Received: by 2002:a1c:98c1:: with SMTP id a184mr14530637wme.116.1597663838998; Mon, 17 Aug 2020 04:30:38 -0700 (PDT) Received: from [10.0.0.139] (bzq-79-183-65-175.red.bezeqint.net. [79.183.65.175]) by smtp.gmail.com with ESMTPSA id 6sm29244732wmf.4.2020.08.17.04.30.37 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Aug 2020 04:30:38 -0700 (PDT) User-Agent: Microsoft-MacOutlook/16.39.20071300 Date: Mon, 17 Aug 2020 14:30:37 +0300 From: Yaron Sheffer To: Martin Thomson , Message-ID: <2D326320-E29B-4865-AD21-8A13CA68718B@gmail.com> Thread-Topic: [saag] On PKI vs. Pinning (SAAG 108 preview) References: <20200728191331.GV41010@kduck.mit.edu> <14373.1597645448@localhost> <54338c62-4a3d-4ccf-a555-c40ba95005dc@www.fastmail.com> In-Reply-To: <54338c62-4a3d-4ccf-a555-c40ba95005dc@www.fastmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [saag] On PKI vs. Pinning (SAAG 108 preview) 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, 17 Aug 2020 11:30:42 -0000 RFC 8672 ("identity pinning") eliminates the first problem listed, because = certificates are not involved. The two other problems are mitigated, because pinning is time limited, and = should be capped at 31 days. If the operator follows the recommended procedu= res [1], the server is not disabled at all even when recovering from an atta= ck, but pinning - as a second factor security control - is disabled for a wh= ile. Thanks, Yaron [1] https://www.rfc-editor.org/rfc/rfc8672.html#name-server-compromise =EF=BB=BFOn 8/17/20, 09:47, "saag on behalf of Martin Thomson" wrote: On Mon, Aug 17, 2020, at 16:24, Michael Richardson wrote: > Are there some reports, threads, or port-mortems that would allow peo= ple to > understand the nature of the brittle-ness? Without attempting to di= sagree, > I can see all sorts of things that could go wrong, but I'd like to un= derstand > what did go wrong. https://groups.google.com/a/chromium.org/g/blink-dev/c/he9tr7p3rZ8/m/eN= MwKPmUBAAJ contains a pretty good summary. _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From nobody Thu Aug 20 12:57:09 2020 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 700FC3A130E for ; Thu, 20 Aug 2020 12:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 sFjHg6IVfa94 for ; Thu, 20 Aug 2020 12:57:05 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27CF23A0D6E for ; Thu, 20 Aug 2020 12:57:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id E0D3A389D3; Thu, 20 Aug 2020 15:36:08 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id CyHTrz01Id69; Thu, 20 Aug 2020 15:36:08 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id C1EFE389D2; Thu, 20 Aug 2020 15:36:07 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 714C14BA; Thu, 20 Aug 2020 15:57:00 -0400 (EDT) From: Michael Richardson To: Benjamin Kaduk , saag@ietf.org In-Reply-To: <20200728191331.GV41010@kduck.mit.edu> References: <20200728191331.GV41010@kduck.mit.edu> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [saag] On PKI vs. Pinning (SAAG 108 preview) 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, 20 Aug 2020 19:57:07 -0000 --=-=-= Content-Type: text/plain Hi Ben, A long consolidate email. I missed SAAG because of conflicts with gendispatch. I watched the youtube yesterday, and read the thread last week, and I read the NFSv4 thread just now. First, I think that to first order, this is a quality of implementation issue. Having said that, implementations are going to lack quality, and being able to (in a NAFTA/CETA/TPP/etc. compliant government RFP) reference something has great value. The alternative is that someone with minimal clue procures some things and they don't work well together, and the IETF NFSv4 spec gets blamed. NFSv4 is the converged storage system spec. While many of us know it is successful (and helped find the Higgs boson), many do not. I think that the use case scenarios for NFSv4 are largely intra-entraprise rather than inter-enterprise. Scaling *down* to two systems is pretty important. Being able to do it without external systems matters here. And for this being able to pin things matters. That is WHY SSH was so well received. At that scale, you don't need to care what you pin, as if it changes, it is because you did something. At the >10 desktop scale where some technology like Kerberos is hard to justify in terms of human learning resources, the use of either a private CA, or a single public anchor for the server makes sense, and the pinning modes that are described in the thread make sense to me. It's not really bits on the wire, but: a) it may require new error codes to clearly articulate when the pinning is broken. This goes to comments during SAAG as to the need for well articulated APIs. b) while it is sometimes true that: "Modern TLS stacks allow for indicating that a non-root CA and even an end-entity (non-CA) certificate are considered to be trusted as trust anchors, and thus the pinning you desire can be implemented within generic PKI trust frameworks as choice of a single specific trust anchor" the way in which this done even in the so-called "modern" OpenSSL is pretty much a black art. While some applications like curl (and fetchmail) have figured it out, and mostly present this well, it's not universally done well. The blob that I move (with human supervised integrity) from machine A to machine B for the four pin cases described is not standardized. This matters once an administrative interface is placed on top of it. Whether that's a web UI, or a netconf YANG model. I use NFSv4 within my LAN, where I authenticate with IP addresses, and the thing that keeps me from using it from my laptop (vs SSHFS) is that I don't know how to trivially do the right certificate exchange. I'm sure I could figure out, but I'm not sure write a UI for it. As you write: > feel quite confident that putting the entire Mozilla root set in my trust > store is the wrong thing to do for this purpose; the question I'm > interested in asking relates to "what is the right thing for this purpose?". so it seems that we ought to have some nomenclature that describes the recovery cases that are important. Yaron writes: > Exactly! Daniel Migault and I published an RFC [1] on "identity pinning" in > TLS 1.3. This is TOFU pinning seen as a second factor, where the first > factor is PKI. It also happens to be very low maintenance and independent > of certificate (EE and CA certificate) changes. This solution is especially > useful for enterprise use cases, where certificate transparency doesn't do > the job. I think that there are two divergent types of pin, and there were allusions which I missed in the saag meeting as to who is using the term in a different way. Yaron describes pinning as second factor, which assumes that the PKI is minimally valid. It guards, I think, against a different CA issuing a name. The pin is more of a configured name-constraint, I think, but I only browsed that RFC very quickly. The other kind of pinning assumes that the PKI does not reach known root, or rather it configures a new trust anchor for the use of this API. I gave a talk at INTC today about Enterprises and trust anchors, and I think that this is very relevant. Enterprises are mostly lost here. In summary: I think that many non-HTTPS users of TLS would benefit from a common understanding of pinning. The HTTPS uses of the term are different, and are tied up in the WebPKI,CT,etc. uses. We probably need a few new terms. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8+1YwACgkQgItw+93Q 3WWDAQf/QvP9Vf5zT8usXGxqHb6TD1tafaVLx0Nhd8zH+H+TiuxTcmzDiuz1v1be k/luUDK9C0orMJwwPxapdG/NhdsbnKjubX9V8jCAHEJAKiHHdiJEK9D5vxY0QbPh /jb4Iz7KEVt2SHTF0MT4B5zjc83X+sWMupt5PBBPlJgWL+65UxMkD+ZrMcnyY4Wj WhUFCY0sWImtXlN6deYEENxaa/H29FjKmQgNqHHiwNKL4NFwmgC9J6HNxsu3XulS 3mBXDAywjHYqLy8SItqaSW8sEkdRzky0EIc/rtn+smA6y/LfDusMR3iug2P17CJ/ gIdZEhOLPaex/d6e3n6Dx4bvymDrzw== =BPSw -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Aug 20 18:45:14 2020 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 97C843A14FC for ; Thu, 20 Aug 2020 18:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0HHv_Tb1NfZZ for ; Thu, 20 Aug 2020 18:45:11 -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 533323A14FB for ; Thu, 20 Aug 2020 18:45:11 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 07L1j6MS025301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 20 Aug 2020 21:45:09 -0400 Date: Thu, 20 Aug 2020 18:45:05 -0700 From: Benjamin Kaduk To: saag@ietf.org Message-ID: <20200821014505.GR92412@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: [saag] draft SAAG IETF 108 minutes posted 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, 21 Aug 2020 01:45:13 -0000 Hi all, I have uploaded draft minutes at https://datatracker.ietf.org/doc/minutes-108-saag/ ; please take a look and offer any corrections/additions. I would also like to thank the minute taker(s) during the session -- I am not confident that the CodiMD UI shows me everyone who contributed, but I can call out at least Mark Baushke as having helped capture what happened. Thank you Mark! -Ben From nobody Fri Aug 21 01:57:11 2020 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 B66553A08C6 for ; Fri, 21 Aug 2020 01:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.525 X-Spam-Level: X-Spam-Status: No, score=-0.525 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, MALFORMED_FREEMAIL=1.573, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMOHFUL96dMX for ; Fri, 21 Aug 2020 01:57:09 -0700 (PDT) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 54BF63A08C1 for ; Fri, 21 Aug 2020 01:57:09 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id p20so1259417wrf.0 for ; Fri, 21 Aug 2020 01:57:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:message-id:thread-topic:references :in-reply-to:mime-version:content-transfer-encoding; bh=5aLv2fSuuq0m1GeislepLdyk1RXMKBEeijhQF4KLrfk=; b=PwXHhk5XFWogF0gbK5LHqzPFROFNBibCJfckAYS9knOeib/uQ7O/gfBVpCnGcjNnuM LDuRrIJ/wvVgr1JCFi28a/wQQ9Mxze9yKZEBdqNFpma3YFMmaeMK5QFamHMdqt3HAgLW 0ZoJo1cvreDAZOlMvTbsj3R3zmB3savh/Ijj+m8L8L60URnqsLRI9/olrbNYiXOy/szh a7wOEmljWHEeLauuey+fbJw2nBGm1WCC60hc0f79j++0jwi8KiysP2jcZGxQx86CgyME Czts/BUkLcKO1lkOoRiwdaVjLFVJRST5a6/4B4XaxUAPyKXs+ikqpa5h0FLlkuJMXT7R ldHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=5aLv2fSuuq0m1GeislepLdyk1RXMKBEeijhQF4KLrfk=; b=edbcl36lGuQilP+1ZAVxDYWELxABPSyhBkPW1qGsZtIKs8mik3X68s/50QWeCtv8zq 2lmRFfrHpQB7d9RleVlfQ207gvPjZq6z56nEDE2xk6UAINUzcPa2jCOmda4P2QtC91w0 3RbKFT/NlEfAoUYsTIZWQCvxQlHhN4jv61zHjqUNLtb0J/PidO6yiIprr3AYXiIuOnVN pqLCF1Y1jhJ8i5xbCxepzCsbUojrL0UWKomZqHHQASLdplPRJ2vKmGJmk9oLD2itk0Ez eAtxx2dQpMiqL6VxPdc9JFt4ctT8ZWoGJUzipmUT5IR0c9a1Beyt+NlnXmbpjyqBtkjt uI9g== X-Gm-Message-State: AOAM5302zFtk93aG4HqROHpBcBo6JRhaod2k/L/UeIOD59PAwbeadF/C 6Ev7yfjFEiypQ0TKSgQ//Hw= X-Google-Smtp-Source: ABdhPJybmdlJLyOnlNy1ONYXmgyY51dG268XNSSIip9qhbNdleqIjiH4+xsIqqmFxbsa/xJkyh78HA== X-Received: by 2002:a5d:4a41:: with SMTP id v1mr1916512wrs.371.1598000227465; Fri, 21 Aug 2020 01:57:07 -0700 (PDT) Received: from [10.0.0.139] (bzq-79-183-65-175.red.bezeqint.net. [79.183.65.175]) by smtp.gmail.com with ESMTPSA id v7sm3348402wmj.28.2020.08.21.01.57.05 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Aug 2020 01:57:06 -0700 (PDT) User-Agent: Microsoft-MacOutlook/16.40.20081000 Date: Fri, 21 Aug 2020 11:57:05 +0300 From: Yaron Sheffer To: Michael Richardson , Benjamin Kaduk , Message-ID: <429787F2-CF84-493B-8201-4C1EF4AE7FD1@gmail.com> Thread-Topic: [saag] On PKI vs. Pinning (SAAG 108 preview) References: <20200728191331.GV41010@kduck.mit.edu> <25733.1597953420@localhost> In-Reply-To: <25733.1597953420@localhost> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: Re: [saag] On PKI vs. Pinning (SAAG 108 preview) 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, 21 Aug 2020 08:57:11 -0000 On 8/20/20, 22:57, "saag on behalf of Michael Richardson" wrote: Yaron writes: > Exactly! Daniel Migault and I published an RFC [1] on "identity pinning" in > TLS 1.3. This is TOFU pinning seen as a second factor, where the first > factor is PKI. It also happens to be very low maintenance and independent > of certificate (EE and CA certificate) changes. This solution is especially > useful for enterprise use cases, where certificate transparency doesn't do > the job. I think that there are two divergent types of pin, and there were allusions which I missed in the saag meeting as to who is using the term in a different way. Yaron describes pinning as second factor, which assumes that the PKI is minimally valid. It guards, I think, against a different CA issuing a name. The pin is more of a configured name-constraint, I think, but I only browsed that RFC very quickly. The other kind of pinning assumes that the PKI does not reach known root, or rather it configures a new trust anchor for the use of this API. I gave a talk at INTC today about Enterprises and trust anchors, and I think that this is very relevant. Enterprises are mostly lost here. To further clarify: I used the word PKI loosely, and should have said "a preconfigured trust store". The first factor in RFC 8672 is normal TLS cert validation, where the trust store can be the Mozilla set of trust anchors, or that set plus the enterprise CA, or just the enterprise CA. Yes, the main goal is to protect from a different CA mis-issuing a certificate for the same name, but surprisingly, even the same CA is prevented from issuing a stealth cert with the same name for a different TLS server. The pin is an additional constraint but not a configured one. Because of the TOFU behavior, no configuration is required. Thanks, Yaron From nobody Fri Aug 21 18:43:32 2020 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 B65A63A081F for ; Fri, 21 Aug 2020 18:43:30 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3c1d67wUqDB for ; Fri, 21 Aug 2020 18:43:29 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 914FB3A0807 for ; Fri, 21 Aug 2020 18:43:29 -0700 (PDT) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 8656C2C46CC; Fri, 21 Aug 2020 21:43:28 -0400 (EDT) Date: Fri, 21 Aug 2020 21:43:28 -0400 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20200822014328.GI37427@straasha.imrryr.org> Reply-To: saag@ietf.org References: <20200728191331.GV41010@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200728191331.GV41010@kduck.mit.edu> Archived-At: Subject: Re: [saag] On PKI vs. Pinning (SAAG 108 preview) 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, 22 Aug 2020 01:43:31 -0000 On Tue, Jul 28, 2020 at 12:13:31PM -0700, Benjamin Kaduk wrote: > Is there benefit in arranging for a description of the system where > the ability to pin is just a degenerate case of a PKI, with a single > trust anchor and no real hierarchy? FWIW, I should mention that the DANE support in OpenSSL (since 1.1.0) is really just support for verifying a certificate chain against a list of EE and/or TA pins. The pins need not come from DNS, and DNSSEC is not required to use the "DANE" in OpenSSL. How the application obtains the pin values is not OpenSSL's concern. The PKIX-TA and PKIX-EE pins are second factors, while the DANE-TA and DANE-EE pins are bypass verification via the usual root CA store, and use only the pins to validate the chain. Thus, for example, in Postfix the following all use the same underlying "DANE" (really general-purpose pinning) API. - The "fingerprint" security level that verifies the peer against a static locally configured list of acceptable certificate or public key fingerprints. - The "secure" level with a local per-destination "tafile", which pins acceptable (possibly intermediate) issuer certificates or public keys. The chain must be signed by an issuer that matches one of the pins. - The "dane" level, where the "pins" take the form of dynamically obtained DNSSEC-validated TLSA records, which can be a mixture of EE and TA pins. So if an OpenSSL application wants to implement pinning that either replaces or augments WebPKI validation, the code is already there in OpenSSL, in the form of support for "DANE", but perhaps it is not correctly "marketed". It is a really a fairly general framework for validating certificate chains against a list of "pins" ("OR" rather than "AND" semantics, success when any *one* of the pins works out). -- Viktor. From nobody Fri Aug 21 21:52:00 2020 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 AD20B3A0B39 for ; Fri, 21 Aug 2020 21:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 KfjqCVndtu1o for ; Fri, 21 Aug 2020 21:51:56 -0700 (PDT) Received: from anteater.elm.relay.mailchannels.net (anteater.elm.relay.mailchannels.net [23.83.212.3]) (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 010703A0A12 for ; Fri, 21 Aug 2020 21:51:55 -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 0265232127A; Sat, 22 Aug 2020 04:51:55 +0000 (UTC) Received: from pdx1-sub0-mail-a15.g.dreamhost.com (100-96-22-62.trex.outbound.svc.cluster.local [100.96.22.62]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 713EF32136A; Sat, 22 Aug 2020 04:51:54 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a15.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.18.8); Sat, 22 Aug 2020 04:51:54 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Spicy-Lonely: 16c7a8de09f228be_1598071914689_2618560706 X-MC-Loop-Signature: 1598071914689:1178602117 X-MC-Ingress-Time: 1598071914689 Received: from pdx1-sub0-mail-a15.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a15.g.dreamhost.com (Postfix) with ESMTP id 2739D7F702; Fri, 21 Aug 2020 21:51:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to; s=cryptonector.com; bh=xC5z1sD8zTskGr+/gnoV10J0/44 =; b=LXci5gerWMaTEw2cc3s2SrUJTwm8DwKPStnm1O5EVLwEVQBD2NGwFAPllQI JAKI5SREm0G7c0Z/bxsMohkvADpmU3HDHv7Ko8shu3/UGfTp1GJzgM+T33efs7zi JqqADwO747Fs9TWSP5Cwrl5Z8KbcplElO0H0FfUWe05sfc3o= 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-a15.g.dreamhost.com (Postfix) with ESMTPSA id 945657F13F; Fri, 21 Aug 2020 21:51:53 -0700 (PDT) Date: Fri, 21 Aug 2020 23:51:51 -0500 X-DH-BACKEND: pdx1-sub0-mail-a15 From: Nico Williams To: saag@ietf.org Message-ID: <20200822045147.GR3100@localhost> References: <20200728191331.GV41010@kduck.mit.edu> <20200822014328.GI37427@straasha.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200822014328.GI37427@straasha.imrryr.org> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: 0 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduiedruddufedgkeefucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecuggftrfgrthhtvghrnhepffdtkeethfeuteeviefgfeegjeetjedvhfehgfdvtdefueejheelgeeuhffghffgnecukfhppedvgedrvdekrddutdekrddukeefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomh Archived-At: Subject: Re: [saag] On PKI vs. Pinning (SAAG 108 preview) 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, 22 Aug 2020 04:51:58 -0000 On Fri, Aug 21, 2020 at 09:43:28PM -0400, Viktor Dukhovni wrote: > On Tue, Jul 28, 2020 at 12:13:31PM -0700, Benjamin Kaduk wrote: > > Is there benefit in arranging for a description of the system where > > the ability to pin is just a degenerate case of a PKI, with a single > > trust anchor and no real hierarchy? > > [...] Shorter Viktor: TLSA RDATA is a generic data format for specifying pins, and if you have an API that accepts trust-me-they-are-validated TLSA RRsets, then you've got an API that does pinning. That's what OpenSSL has -- its DANE API does no DNSSEC lookups, so it's not _DANE_ as such. I.e., one could use TLSA RDATA as a pin configuration and exchange format! Nico PS: So OpenSSL's DANE API is a no-batteries-included thing. I don't why Viktor is so 'stingy' about it :) putting his DNSSEC code only in Postfix and not in OpenSSL. From nobody Sun Aug 23 13:38:36 2020 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 AA51F3A0E4F for ; Sun, 23 Aug 2020 13:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aOY01FJc5Ig9 for ; Sun, 23 Aug 2020 13:38:32 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B0E03A0B4E for ; Sun, 23 Aug 2020 13:38:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 93F04389D4 for ; Sun, 23 Aug 2020 16:17:34 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id f6nNdI1-uz4h for ; Sun, 23 Aug 2020 16:17:32 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 97D22389CA for ; Sun, 23 Aug 2020 16:17:31 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 258855ED for ; Sun, 23 Aug 2020 16:38:27 -0400 (EDT) From: Michael Richardson To: saag@ietf.org In-Reply-To: <20200822014328.GI37427@straasha.imrryr.org> References: <20200728191331.GV41010@kduck.mit.edu> <20200822014328.GI37427@straasha.imrryr.org> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [saag] On PKI vs. Pinning (SAAG 108 preview) 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: Sun, 23 Aug 2020 20:38:35 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Viktor Dukhovni wrote: >> Is there benefit in arranging for a description of the system where >> the ability to pin is just a degenerate case of a PKI, with a single >> trust anchor and no real hierarchy? > FWIW, I should mention that the DANE support in OpenSSL (since 1.1.0)= is > really just support for verifying a certificate chain against a list = of > EE and/or TA pins. The pins need not come from DNS, and DNSSEC is not > required to use the "DANE" in OpenSSL. How the application obtains t= he > pin values is not OpenSSL's concern. > The PKIX-TA and PKIX-EE pins are second factors, while the DANE-TA > and DANE-EE pins are bypass verification via the usual root CA > store, and use only the pins to validate the chain. There are some terms here that I want to lift up: 1) PKIX-TA 2) PKIX-EE 3) DANE-TA 4) DANE-EE I think that the "DANE" in (3) and (4) are not, (as is pointed out in by Vi= ktor), specifically DNS/DNSEC, but rather the point is that they aren't descending from a *PKIX* trust anchor. That there are four ways to pin seems consistent with other comments on this thread. It seems to me that having a short document that explains the four methods would be a useful thing to do. Are there more than four? Mayb= e. > Thus, for example, in Postfix the following all use the same underlyi= ng > "DANE" (really general-purpose pinning) API. > - The "fingerprint" security level that verifies the peer > against a static locally configured list of acceptable > certificate or public key fingerprints. > - The "secure" level with a local per-destination "tafile", > which pins acceptable (possibly intermediate) issuer > certificates or public keys. The chain must be signed > by an issuer that matches one of the pins. > - The "dane" level, where the "pins" take the form of > dynamically obtained DNSSEC-validated TLSA records, > which can be a mixture of EE and TA pins. These have different security properties, and maybe represent two additional forms of pin. > So if an OpenSSL application wants to implement pinning that > either replaces or augments WebPKI validation, the code is > already there in OpenSSL, in the form of support for "DANE", > but perhaps it is not correctly "marketed". It is a really > a fairly general framework for validating certificate chains > against a list of "pins" ("OR" rather than "AND" semantics, > success when any *one* of the pins works out). Stephen Farrel mentioned the banking app that comes with a pin. I think that such a an app would like to know that it is not getting through due to Enterprise audit-based MITM, or National-Firewall MITM. Of course, it could also be another attacker, and RFC7258 in many ways labe= ls the above as attacks. Someone using that app might want to ask their bank about what kind of pin they are using, and they might like to get back a clear answer. =2D- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl9C08IACgkQgItw+93Q 3WV6jQf/ZYG2ixe6cLzAzTLlpJFdm3taohCSVsvTkl9EbI5UKAZZ4TruglU6YTxT 2tlgftMyoCKHGD6zFCvjrfdnmDoAXCBf6eSYjXEx5kCkkqBYPL9jBX918epZjI7I o0VDUkOTh3brU4AJHYCXJONvO2JmQE6byzx3TqLfVh0SpcJ4qORVsxLEdmqsk6cO Gf8epc9iPBiNQ+OmxNPH0X0PGOAiFoGzjvHmE1C3im0wXFyt6nBcCPfFY/0NboKs loH2bOY/xwTYb10qOuNLDhu5WwfVy6PIzRMpZ495O/8b9h/jJD9CoZekTf6G0xTH qO2+EDrQhagEPTpKPMRWpiMTNRb9Pw== =759e -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Aug 23 15:52:22 2020 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 7255A3A0ED1 for ; Sun, 23 Aug 2020 15:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 4ZSgdXWFy0IS for ; Sun, 23 Aug 2020 15:52:19 -0700 (PDT) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (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 13D153A0ECF for ; Sun, 23 Aug 2020 15:52:19 -0700 (PDT) Received: by mail-pf1-x435.google.com with SMTP id f193so3835934pfa.12 for ; Sun, 23 Aug 2020 15:52:18 -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=6dx9IOLnOZYa1sK7Cv+WP/PCm3X6eyHATKaIwY7BXgI=; b=hi/SH+fIEy2Gju7WHXR7C//lnCnWz+o1pdXYvxhd+QmiUnwqJnctZoreiE/YHAtj6e 9zNcewv/pUbmoWRjdRZyyDqKcvF7jDXniOME6jcRd9sa5Y5QSI8oPar0u5cJeVZLLiGa GLbuNR1y2MP+jPWls2JY0SuA9DMOznL7z6X1NcM9vSRDt9OUcRkOfB8akn0hVcTDR2ZG vFhBsq7xwT7CbhHFjKYIqAzLhp/36D7jmVUcNH4PqcJe+BIZHmSwVp3VRjZPt4sHs2HY Gk4wcJr5IFfHONAPo5vqniq9YmgrefUzyZ4LQtNHcVykZ51Znw3Zg1dvkkViWOkNj5iG 0+0Q== 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=6dx9IOLnOZYa1sK7Cv+WP/PCm3X6eyHATKaIwY7BXgI=; b=TqMRNA2FbK8D2AiR6Iplt3R0Z8ld6grJL5wLnRp9OMzShMTx5XmtNvcPz7gP+xXpXS 538bzG5PsNCiW/0STshjnGsRcjJ18H0xROvd6cuvb1uifTqASBcYMkNsTYZ0OTRrdq54 bRTcUwZfNan3Z/Hq4mHWMWw1caqffA9j8q9JjZ7uX5JLSM2QBTZiwSL9KFHgUlfIVJy+ ztq8GVLvkUkvHS2UOvK1C+H4HKAWrrtQre7eg+gDplHVjxXovokhOYQW2xBw5RWxdB0T p9zhjeAlO2jctCoEIgkIf0+wrJdoD9HA5zEvDyTSVtXXRItvFDK4RkMuZDKskRilCxH1 7ifA== X-Gm-Message-State: AOAM5335CtsCRF3CVAo2bo2VmfCtYCkhefGkj9APGXpd226TIGcNYby2 mbgWpsC735KOc+sub67loO3Jek6kK876BVlusb+ey1vtnU8= X-Google-Smtp-Source: ABdhPJxgp5W2mrpsI8/NC1wybiYwcHQ7BR1Z6XqTu1a8ovy+B8DTb1KiTR8PGTTGXCzgIQsQ2TK7TwWnLYV3GrBTOd8= X-Received: by 2002:aa7:9e1e:: with SMTP id y30mr1971911pfq.120.1598223138160; Sun, 23 Aug 2020 15:52:18 -0700 (PDT) MIME-Version: 1.0 References: <159822293824.906.16043823977991516317@ietfa.amsl.com> In-Reply-To: <159822293824.906.16043823977991516317@ietfa.amsl.com> From: Yakov Shafranovich Date: Sun, 23 Aug 2020 18:51:42 -0400 Message-ID: To: saag@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [saag] Fwd: New Version Notification for draft-foudil-securitytxt-10.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: Sun, 23 Aug 2020 22:52:20 -0000 ---------- Forwarded message --------- From: Date: Sun, Aug 23, 2020 at 6:48 PM Subject: New Version Notification for draft-foudil-securitytxt-10.txt To: Edwin Foudil , Yakov Shafranovich A new version of I-D, draft-foudil-securitytxt-10.txt has been successfully submitted by Yakov Shafranovich and posted to the IETF repository. Name: draft-foudil-securitytxt Revision: 10 Title: A File Format to Aid in Security Vulnerability Disclosure Document date: 2020-08-23 Group: Individual Submission Pages: 26 URL: https://www.ietf.org/internet-drafts/draft-foudil-securitytxt-10.txt Status: https://datatracker.ietf.org/doc/draft-foudil-securitytxt/ Htmlized: https://tools.ietf.org/html/draft-foudil-securitytxt-10 Htmlized: https://datatracker.ietf.org/doc/html/draft-foudil-securitytxt Diff: https://www.ietf.org/rfcdiff?url2=draft-foudil-securitytxt-10 Abstract: When security vulnerabilities are discovered by researchers, proper reporting channels are often lacking. As a result, vulnerabilities may be left unreported. This document defines a format ("security.txt") to help organizations describe their vulnerability disclosure practices to make it easier for researchers to report 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 Sun Aug 23 19:16:10 2020 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 749F13A094A for ; Sun, 23 Aug 2020 19:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 DSSPDSicgflt for ; Sun, 23 Aug 2020 19:16:08 -0700 (PDT) Received: from brown.elm.relay.mailchannels.net (brown.elm.relay.mailchannels.net [23.83.212.23]) (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 120953A0945 for ; Sun, 23 Aug 2020 19:16:07 -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 16DE51E1203; Mon, 24 Aug 2020 02:16:07 +0000 (UTC) Received: from pdx1-sub0-mail-a3.g.dreamhost.com (100-96-22-62.trex.outbound.svc.cluster.local [100.96.22.62]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 9E7991E1024; Mon, 24 Aug 2020 02:16:06 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a3.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.18.8); Mon, 24 Aug 2020 02:16:07 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Thoughtful-Chief: 5a67d0f11b744723_1598235366913_180352608 X-MC-Loop-Signature: 1598235366913:2660186905 X-MC-Ingress-Time: 1598235366912 Received: from pdx1-sub0-mail-a3.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a3.g.dreamhost.com (Postfix) with ESMTP id 364F27F75E; Sun, 23 Aug 2020 19:16:06 -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=ZT28502NqDZURn H7BKwIfutdiZs=; b=XF1U47nH4SsEkbgV1yM+CheU7QllhvOtImMbJSa43I/k7v ppQNp6gtNSM4o4JLmmtionh563lWed10QOfAcUGmQcxWDQKhEU8Sqo7Pdsfmk/hw Hqky/iyu6rDZp6qDhASjKVBoE/0rZqNMy5+1cqfPsI10cJFVXESYdDQQtN8qA= 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-a3.g.dreamhost.com (Postfix) with ESMTPSA id 59C107F755; Sun, 23 Aug 2020 19:16:04 -0700 (PDT) Date: Sun, 23 Aug 2020 21:16:02 -0500 X-DH-BACKEND: pdx1-sub0-mail-a3 From: Nico Williams To: Michael Richardson Cc: saag@ietf.org Message-ID: <20200824021601.GS3100@localhost> References: <20200728191331.GV41010@kduck.mit.edu> <20200822014328.GI37427@straasha.imrryr.org> <32690.1598215107@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <32690.1598215107@localhost> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: 0 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduiedruddujedggeefucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecuggftrfgrthhtvghrnhepffdtkeethfeuteeviefgfeegjeetjedvhfehgfdvtdefueejheelgeeuhffghffgnecukfhppedvgedrvdekrddutdekrddukeefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomh Archived-At: Subject: Re: [saag] On PKI vs. Pinning (SAAG 108 preview) 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, 24 Aug 2020 02:16:09 -0000 On Sun, Aug 23, 2020 at 04:38:27PM -0400, Michael Richardson wrote: > There are some terms here that I want to lift up: > > 1) PKIX-TA > 2) PKIX-EE > 3) DANE-TA > 4) DANE-EE > > I think that the "DANE" in (3) and (4) are not, (as is pointed out in by Viktor), > specifically DNS/DNSEC, but rather the point is that they aren't descending > from a *PKIX* trust anchor. In the first two cases you write the pins down in local storage, and this has significant operational considerations in both, the TA and EE cases, but more so in the EE case. In the other two cases you write the pin down in a distributed storage system called DNS(SEC). The main semantic difference security-wise has to do with trusting all the zones in the chain. (You want QName minimization in order to make it much harder for intermediate zone admins zone to mount an MITM attack.) But "local storage" isn't really, not in most cases. Those local pins come with apps, and the app distribution mechanisms have their own chains of trust. Is there any difference, then, between (1)&(2) and (3)&(4)? In both cases you'll end up with security considerations of both, PKIX and the pin distribution mechanism. The only thing DNSSEC adds to any other existing pin distribution mechanism is authenticated denial of existence, which allows one to have a fairly fast way to switch between DNSSEC and alternative pin distribution mechanisms. See below. > That there are four ways to pin seems consistent with other comments on this > thread. It seems to me that having a short document that explains the > four methods would be a useful thing to do. Are there more than four? Maybe. There's one more. draft-dukhovni-tls-dnssec-chain allows one to have a pin of just support for a TLS extension as opposed to a pin of some credential verifier. Support for the extension means commitment _only_ to providing DNSSEC chains, either authenticating TLS RRset non- existence, or else providing the desired authenticated TLSA RRset. I.e., draft-dukhovni-tls-dnssec-chain is a mechanism for negotiating how you select a trust anchor / pin: DANE or not-DANE. Switching between the two can be done very quickly. The operational semantics of this quite good because DNS has better operational semantics for distributing this sort of metadata than code distribution, and because authenticated denial of existence makes it alternate pin distribution methods quickly. Its security semantics are essentially those of DNSSEC if you're pinning EE certs, or those DNSSEC as a sort of bridge PKI if you're pinning TAs. > Stephen Farrel mentioned the banking app that comes with a pin. I > think that such a an app would like to know that it is not getting > through due to Enterprise audit-based MITM, or National-Firewall MITM. Pinning lets apps detect MITM attacks, but not whether they are tolerable attacks (enterprise proxies). In enterprise environments it's common to allow connection to banking sites through proxies w/o MITMing them. Typically the banking sites allowed are either on some generic list (e.g., supplied by the enterprise proxy vendor), or those that the proxy's operator has reporting agreements with. Financial entities might do the latter, say, because they don't need to know what you're doing in real-time in order to enforce strict compliance with rules about insider trading. (If an employee is using another financial entity with whom the employer has a reporting agreement, then the employer will find out in due time and will be able to discipline you for any violations.) There are strong privacy reasons to exempt certain sites from otherwise-required MITM proxying. Employees know they have no real privacy at work when using their employer's network no matter how convenient that network. But employers don't want to have in their possession any information that only increases their liability, such as employees' banking credentials. The biggest reason to MITM is data loss protection (DLP), but there's no risk of DL when employees engage in online banking, and again, compliance in the case of banking can be enforced asynchronously. Nico -- From nobody Sun Aug 23 22:25:41 2020 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 DF86A3A0A38 for ; Sun, 23 Aug 2020 22:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dga4j7Rhrkzd for ; Sun, 23 Aug 2020 22:25:38 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 D24E13A0A2D for ; Sun, 23 Aug 2020 22:25:38 -0700 (PDT) Received: by straasha.imrryr.org (Postfix, from userid 1001) id A9DBC2C5558; Mon, 24 Aug 2020 01:25:37 -0400 (EDT) Date: Mon, 24 Aug 2020 01:25:37 -0400 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20200824052537.GQ37427@straasha.imrryr.org> Reply-To: saag@ietf.org References: <20200728191331.GV41010@kduck.mit.edu> <20200822014328.GI37427@straasha.imrryr.org> <32690.1598215107@localhost> <20200824021601.GS3100@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200824021601.GS3100@localhost> Archived-At: Subject: Re: [saag] On PKI vs. Pinning (SAAG 108 preview) 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, 24 Aug 2020 05:25:40 -0000 On Sun, Aug 23, 2020 at 09:16:02PM -0500, Nico Williams wrote: > On Sun, Aug 23, 2020 at 04:38:27PM -0400, Michael Richardson wrote: > > There are some terms here that I want to lift up: > > > > 1) PKIX-TA > > 2) PKIX-EE > > 3) DANE-TA > > 4) DANE-EE > > > > I think that the "DANE" in (3) and (4) are not, (as is pointed out in by Viktor), > > specifically DNS/DNSEC, but rather the point is that they aren't descending > > from a *PKIX* trust anchor. Indeed (3) and (4) pin an EE (leaf) or TA (issuer) certificate or public key respectively, where there is no expectation of validation via the the default PKI(X) trust anchors. In the case of DANE-TA, one then still implements essentially PKIX validation, but the trust anchor is the target-specific pin, rather than a trusted-by-default issuer. > In the first two cases you write the pins down in local storage, and > this has significant operational considerations in both, the TA and EE > cases, but more so in the EE case. This description of (1) and (2) is at least misleading. These pins constrain, but do not replace, PKIX validation. Thus the chain must validate under PKIX *and* satisfy the pins. The pins may be from local storage (as could (3) and (4)), or they may be in the form of DANE TLSA records with "certificate usage" PKIX-TA(0) or PKIX-EE(1). All this is defined in RFC6698, but what's interesting is that the basic chain validation algorithm, is independent of and separabel from the DNS aspects of DANE TLSA. Thus OpenSSL implements just the chain validation logic, which one the one hand means "no batteries included", ..., users roll their own DNS glue if they want DNSSEC-validated TLSA records to be the source of the pins. But, on the other hand, it also means that the implementation is more flexible, it can verify semantically compatible pins from any other source (e.g. some day the ISE track dnssec-chain extension). A batteries-included library for doing the DNS lookups and then DANE TLS is not difficult to write, but because MTAs are so specialised in their needs, I've not had cause to write a general-purpose one for the simpler client to server (with no MX indirection, ...) use-case. Perhaps some day. > Is there any difference, then, between (1)&(2) and (3)&(4)? In both > cases you'll end up with security considerations of both, PKIX and the > pin distribution mechanism. Yes, (1) and (2) augment (constrain) PKI(X), while (3) and (4) replace it. Anyone, I hope this digression might be of some use to someone, if some sort of pinning makes sense in their applications and maps reasonably well onto one of the RFC6698 "usages", whether the pin is from DNS(SEC) or not. -- Viktor. From nobody Tue Aug 25 20:14:29 2020 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 7AA7E3A0C15 for ; Tue, 25 Aug 2020 20:14:28 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEnOwIYSzal7 for ; Tue, 25 Aug 2020 20:14:27 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DD0D3A0C18 for ; Tue, 25 Aug 2020 20:14:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id BEA66389A0 for ; Tue, 25 Aug 2020 22:53:27 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id OVAm8nexnALi for ; Tue, 25 Aug 2020 22:53:27 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1B3E13899E for ; Tue, 25 Aug 2020 22:53:27 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B1AD712C1 for ; Tue, 25 Aug 2020 23:14:24 -0400 (EDT) To: saag@ietf.org References: <20200728191331.GV41010@kduck.mit.edu> <20200728194235.GY41010@kduck.mit.edu> From: Michael Richardson Message-ID: <5ac5c357-0eeb-d321-c743-03817684fe22@sandelman.ca> Date: Tue, 25 Aug 2020 23:14:24 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200728194235.GY41010@kduck.mit.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [saag] height of PKI 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, 26 Aug 2020 03:14:28 -0000 On 2020-07-28 3:42 p.m., Benjamin Kaduk wrote: > Sorry for the clumsy description. Basically, if you squint hard, you could > claim that at least some types of pinning are actually a PKI, just a > degenerate PKI. E.g., in a PKI I have to pin at least one trust anchor as > the root of the PKI, and if that pinned trust anchor just happens to also > be the certificate directly used in the protocol, it's still a PKI, just a > tree of height one. I had suggested that a PKI that consisted of ROOT, Intermediate, and EE had a height of "three". Some disagreed, and said that the EE didn't count, and it was a height of "two" Others disagreed: the EE counts, but the root doesn't count, so it's a height of "two" So is your case above a height of "one", or a height of "zero" If there is a definitive answer, I haven't found it yet. From nobody Tue Aug 25 21:35:34 2020 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 393BC3A0C85 for ; Tue, 25 Aug 2020 21:35:33 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugI7M_WW1s3O for ; Tue, 25 Aug 2020 21:35:32 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 303B83A0890 for ; Tue, 25 Aug 2020 21:35:32 -0700 (PDT) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 51A5B2C6FF4; Wed, 26 Aug 2020 00:35:30 -0400 (EDT) Date: Wed, 26 Aug 2020 00:35:30 -0400 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20200826043530.GZ37427@straasha.imrryr.org> Reply-To: saag@ietf.org References: <20200728191331.GV41010@kduck.mit.edu> <20200728194235.GY41010@kduck.mit.edu> <5ac5c357-0eeb-d321-c743-03817684fe22@sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5ac5c357-0eeb-d321-c743-03817684fe22@sandelman.ca> Archived-At: Subject: Re: [saag] height of PKI 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, 26 Aug 2020 04:35:33 -0000 On Tue, Aug 25, 2020 at 11:14:24PM -0400, Michael Richardson wrote: > On 2020-07-28 3:42 p.m., Benjamin Kaduk wrote: > > Sorry for the clumsy description. Basically, if you squint hard, you could > > claim that at least some types of pinning are actually a PKI, just a > > degenerate PKI. E.g., in a PKI I have to pin at least one trust anchor as > > the root of the PKI, and if that pinned trust anchor just happens to also > > be the certificate directly used in the protocol, it's still a PKI, just a > > tree of height one. > > I had suggested that a PKI that consisted of ROOT, Intermediate, and EE > had a height of "three". > Some disagreed, and said that the EE didn't count, and it was a height > of "two" > Others disagreed: the EE counts, but the root doesn't count, so it's a > height of "two" > > So is your case above a height of "one", or a height of "zero" > > If there is a definitive answer, I haven't found it yet. What's "definitive"? And which certificate is at depth 0, the root or the leaf? These questions have no answer (different X.509 libraries answer them differently), just be clear about your notation in context. You could of course go with RFC5280, but its numbering is by no means universally used. -- Viktor. From nobody Wed Aug 26 07:44:03 2020 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 55EA03A1546 for ; Wed, 26 Aug 2020 07:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 7i6quYT3jV-z for ; Wed, 26 Aug 2020 07:44:00 -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 119D33A1545 for ; Wed, 26 Aug 2020 07:44:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 6D599300B06 for ; Wed, 26 Aug 2020 10:43:57 -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 Mlp_b1OeMYoz for ; Wed, 26 Aug 2020 10:43:55 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id B41E8300AB1; Wed, 26 Aug 2020 10:43:55 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) From: Russ Housley In-Reply-To: <5ac5c357-0eeb-d321-c743-03817684fe22@sandelman.ca> Date: Wed, 26 Aug 2020 10:43:57 -0400 Cc: IETF SAAG Content-Transfer-Encoding: quoted-printable Message-Id: <2AA3B4ED-732B-49D4-9441-94EAB3CF31F1@vigilsec.com> References: <20200728191331.GV41010@kduck.mit.edu> <20200728194235.GY41010@kduck.mit.edu> <5ac5c357-0eeb-d321-c743-03817684fe22@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: Re: [saag] height of PKI 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, 26 Aug 2020 14:44:01 -0000 > On Aug 25, 2020, at 11:14 PM, Michael Richardson = wrote: >=20 > On 2020-07-28 3:42 p.m., Benjamin Kaduk wrote: >> Sorry for the clumsy description. Basically, if you squint hard, you = could >> claim that at least some types of pinning are actually a PKI, just a >> degenerate PKI. E.g., in a PKI I have to pin at least one trust = anchor as >> the root of the PKI, and if that pinned trust anchor just happens to = also >> be the certificate directly used in the protocol, it's still a PKI, = just a >> tree of height one. >=20 > I had suggested that a PKI that consisted of ROOT, Intermediate, and = EE > had a height of "three". > Some disagreed, and said that the EE didn't count, and it was a height = of "two" > Others disagreed: the EE counts, but the root doesn't count, so it's a = height of "two" >=20 > So is your case above a height of "one", or a height of "zero" >=20 > If there is a definitive answer, I haven't found it yet. You may find the description of pathLenConstraint in Section 4.2.1.9 of = RFC 5280 helpful. Russ From nobody Wed Aug 26 14:52:37 2020 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 74FDD3A08B0 for ; Wed, 26 Aug 2020 14:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 wk4cCAuxcE_e for ; Wed, 26 Aug 2020 14:52:34 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A215B3A0898 for ; Wed, 26 Aug 2020 14:52:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 9D4653898F for ; Wed, 26 Aug 2020 17:31:33 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id eCzZSE2Xl5DA for ; Wed, 26 Aug 2020 17:31:32 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D14A53897F for ; Wed, 26 Aug 2020 17:31:32 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 278D886 for ; Wed, 26 Aug 2020 17:52:31 -0400 (EDT) From: Michael Richardson To: saag@ietf.org In-Reply-To: <20200826043530.GZ37427@straasha.imrryr.org> References: <20200728191331.GV41010@kduck.mit.edu> <20200728194235.GY41010@kduck.mit.edu> <5ac5c357-0eeb-d321-c743-03817684fe22@sandelman.ca> <20200826043530.GZ37427@straasha.imrryr.org> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [saag] height of PKI 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, 26 Aug 2020 21:52:36 -0000 --=-=-= Content-Type: text/plain Viktor Dukhovni wrote: >> On 2020-07-28 3:42 p.m., Benjamin Kaduk wrote: > Sorry for the clumsy >> description. Basically, if you squint hard, you could > claim that at >> least some types of pinning are actually a PKI, just a > degenerate >> PKI. E.g., in a PKI I have to pin at least one trust anchor as > the >> root of the PKI, and if that pinned trust anchor just happens to also >> > be the certificate directly used in the protocol, it's still a PKI, >> just a > tree of height one. >> >> I had suggested that a PKI that consisted of ROOT, Intermediate, and >> EE had a height of "three". Some disagreed, and said that the EE >> didn't count, and it was a height of "two" Others disagreed: the EE >> counts, but the root doesn't count, so it's a height of "two" >> >> So is your case above a height of "one", or a height of "zero" >> >> If there is a definitive answer, I haven't found it yet. > What's "definitive"? And which certificate is at depth 0, the root or > the leaf? These questions have no answer (different X.509 libraries > answer them differently), just be clear about your notation in context. I would be interested in which libraries do what. > You could of course go with RFC5280, but its numbering is by no means > universally used. Alright. Let me look again there. }6.1. Basic Path Validation }... } To meet this goal, the path validation process verifies, among other } things, that a prospective certification path (a sequence of n } certificates) satisfies the following conditions: } } (a) for all x in {1, ..., n-1}, the subject of certificate x is } the issuer of certificate x+1; } } (b) certificate 1 is issued by the trust anchor; } } (c) certificate n is the certificate to be validated (i.e., the } target certificate); and } } (d) for all x in {1, ..., n}, the certificate was valid at the } time in question. So this means that the trust anchor is at height one. The End-Entity Certificate is to be counted, and it's a height n. So, in my example of root, intermediate-CA and EE, the height is three. Which is what I originally thought. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl9G2Z4ACgkQgItw+93Q 3WXMkQgAkY2Q6o5QyE+z/tLzq5w+p8JJ59PYhuUDwcO2MAhIpm1j52yRnTeUUHz5 Rqc7qBj7uN33A2sczwYawKffu5s3zejGtNwolM5BXuWeRcFOtNw4IIwi4Or/xWZz bQ+FyuAsR0tPVqDlJbH+MkzpPwcX8LfCZy//TawGtfv1tXPnyOA8h67nYhWhdzuU kKQ2IbMjUfcdWdb7Q1mkyjm7dYtI/f4lfPX6vUtfxBaiRSfEi72fbM+U37vkfE0a aEFtZdf2oQp16detLPxDPNstC9d1euQLgJYO/bX7/6laQ4u5zJJogk/PbwgcRMnO aLjf/yxkUjrDdbKY7JbZZvJcysFPMg== =Z1v3 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 26 14:55:05 2020 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 64AF63A08AD for ; Wed, 26 Aug 2020 14:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 vZMi2iyMlpIw for ; Wed, 26 Aug 2020 14:55:01 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7E883A0898 for ; Wed, 26 Aug 2020 14:55:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 8C7913898F; Wed, 26 Aug 2020 17:34:01 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id FUQ8Awv6Iyi0; Wed, 26 Aug 2020 17:34:00 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 62F603897F; Wed, 26 Aug 2020 17:34:00 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id AA45686; Wed, 26 Aug 2020 17:54:58 -0400 (EDT) From: Michael Richardson To: Russ Housley cc: IETF SAAG In-Reply-To: <2AA3B4ED-732B-49D4-9441-94EAB3CF31F1@vigilsec.com> References: <20200728191331.GV41010@kduck.mit.edu> <20200728194235.GY41010@kduck.mit.edu> <5ac5c357-0eeb-d321-c743-03817684fe22@sandelman.ca> <2AA3B4ED-732B-49D4-9441-94EAB3CF31F1@vigilsec.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [saag] height of PKI 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, 26 Aug 2020 21:55:03 -0000 --=-=-= Content-Type: text/plain Russ Housley wrote: >> On 2020-07-28 3:42 p.m., Benjamin Kaduk wrote: >>> Sorry for the clumsy description. Basically, if you squint hard, you >>> could claim that at least some types of pinning are actually a PKI, >>> just a degenerate PKI. E.g., in a PKI I have to pin at least one >>> trust anchor as the root of the PKI, and if that pinned trust anchor >>> just happens to also be the certificate directly used in the >>> protocol, it's still a PKI, just a tree of height one. >> >> I had suggested that a PKI that consisted of ROOT, Intermediate, and >> EE had a height of "three". Some disagreed, and said that the EE >> didn't count, and it was a height of "two" Others disagreed: the EE >> counts, but the root doesn't count, so it's a height of "two" >> >> So is your case above a height of "one", or a height of "zero" >> >> If there is a definitive answer, I haven't found it yet. > You may find the description of pathLenConstraint in Section 4.2.1.9 of > RFC 5280 helpful. That's interesting, but in of itself, it does not establish a zero-indexed or one-index absolute count, as it describes an interval. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl9G2jIACgkQgItw+93Q 3WX72Qf/YRGtxTwAIqxZN5zX+oIGv65fqtMsD6ztrrRVC7XkDSi5aaA6IGKQIpVG N4bePUyZhMtm5oQOxCoFCap/sfbtl9YVPFU5IMVIgavl3YIJKaQ/kLWq5FWo7o0j 6HeWn1dkIVjzDU7AVH+sujgOzYZSXwFCxmEjOOc5x3fYMjspE+Q6cYh3y/NPB/AE hGzQoYkvN2zna0WkxQESECO+NBFGxxscYOhg3fttHhCIa+GtoWTI4iJG8XLhWYW1 dMgtEnFrG+nVNYGUnxOpaazpT0JFP7SXKS+RH/3A+rb0Z2REB/8qGG+rWGpjn0qH N7P3WYm2O6hB0qxsfv9K9ZM/9dBaYQ== =Hh2+ -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 28 12:50:06 2020 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 EAE3A3A0B4D for ; Fri, 28 Aug 2020 12:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 2o97QbwJoCVd for ; Fri, 28 Aug 2020 12:50:03 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB4E63A0B4A for ; Fri, 28 Aug 2020 12:50:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 3F0AD389DA; Fri, 28 Aug 2020 15:29:00 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id gxivaAD9PMCC; Fri, 28 Aug 2020 15:28:59 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 8A463389D9; Fri, 28 Aug 2020 15:28:58 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8154CB3; Fri, 28 Aug 2020 15:49:58 -0400 (EDT) From: Michael Richardson To: Nico Williams cc: saag@ietf.org In-Reply-To: <20200824021601.GS3100@localhost> References: <20200728191331.GV41010@kduck.mit.edu> <20200822014328.GI37427@straasha.imrryr.org> <32690.1598215107@localhost> <20200824021601.GS3100@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [saag] On PKI vs. Pinning (SAAG 108 preview) 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, 28 Aug 2020 19:50:05 -0000 --=-=-= Content-Type: text/plain Nico Williams wrote: > On Sun, Aug 23, 2020 at 04:38:27PM -0400, Michael Richardson wrote: >> There are some terms here that I want to lift up: >> >> 1) PKIX-TA >> 2) PKIX-EE >> 3) DANE-TA >> 4) DANE-EE >> >> I think that the "DANE" in (3) and (4) are not, (as is pointed out in by Viktor), >> specifically DNS/DNSEC, but rather the point is that they aren't descending >> from a *PKIX* trust anchor. > In the first two cases you write the pins down in local storage, and > this has significant operational considerations in both, the TA and EE > cases, but more so in the EE case. In the other two cases you write the > pin down in a distributed storage system called DNS(SEC). The main > semantic difference security-wise has to do with trusting all the zones > in the chain. (You want QName minimization in order to make it much > harder for intermediate zone admins zone to mount an MITM attack.) I agree with your analysis. Do you think we need to capture it into a document? I was picking apart the fact that Viktor had identied two cases where the PKIX part/trust anchor didn't matter. His point was that (3) and (4) just happened to match the DANE use case, and thus provided that name, but it doesn't matter exactly where the storage is. If I were to write a document explaining this, I would use DANE an example, but I wouldn't name it that. > There's one more. draft-dukhovni-tls-dnssec-chain allows one to have a > pin of just support for a TLS extension as opposed to a pin of some > credential verifier. Support for the extension means commitment _only_ > to providing DNSSEC chains, either authenticating TLS RRset non- > existence, or else providing the desired authenticated TLSA RRset. I didn't know that this document exists. To save others the step of learning about it: Abstract This draft describes a new TLS extension for in-band transport of the complete set of DNSSEC validated records needed to perform DANE authentication of a TLS server without the need to perform separate out-of-band DNS lookups. When the requisite DNS records do not exist, the extension conveys a validated denial of existence proof. So, I wanted to do EXACTLY this for IPsec OE (RFC4322). I imagined two entities (Opus and Bill the Cat) sitting in a meadow, doing security of IPv6-LL addresses without any outside connectivity. [You can't expect a dead cat to fetch CRLs..] I guess this is intended for the TLS WG? >> Stephen Farrel mentioned the banking app that comes with a pin. I >> think that such a an app would like to know that it is not getting >> through due to Enterprise audit-based MITM, or National-Firewall MITM. > Pinning lets apps detect MITM attacks, but not whether they are > tolerable attacks (enterprise proxies). Agreed. That would have to come by some attestation statement in the decline. draft-ietf-capport-api-08 is one place I would like to that. > In enterprise environments it's common to allow connection to banking > sites through proxies w/o MITMing them. Typically the banking sites > allowed are either on some generic list (e.g., supplied by the > enterprise proxy vendor), or those that the proxy's operator has > reporting agreements with. Yes. But, generating exceptions to the site administrator to approve/deny might also be a good way to this. MUD/RFC8520 statements from the app would also be interesting as supporting evidence. > There are strong privacy reasons to exempt certain sites from > otherwise-required MITM proxying. Employees know they have no real > privacy at work when using their employer's network no matter how > convenient that network. But employers don't want to have in their > possession any information that only increases their liability, such as > employees' banking credentials. The biggest reason to MITM is data loss > protection (DLP), but there's no risk of DL when employees engage in > online banking, and again, compliance in the case of banking can be > enforced asynchronously. +1 -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl9JX+YACgkQgItw+93Q 3WWT3wgAjgV1DYvBpUlB0zfP1ywLKiN1Em0DbFXrBjwG9EBT389WC4GMJsytyFjO gy9iIC70EtbhqpL48eP8IzTyizW8HN1SMmND8NoStnaMZRPmMFsm+ycZvd7h6jiu fRuq0PVAFb86kN3gbFIWXTgpu3AUuB/GI26WxKSGy5vD5kvm4cMtVfoNY/7CO6Ym K5ND3fiUyZPHhLQ72Sp5AjCdWgolQwC3HcRRnV6sTDpR3A1vn2p7Qsk7T0Lzo3a8 F7FlodUQcI1kUnlAjU+DW1E6T8Q5J8oZCJE7B72vyamL5bo+FLlAcDpAYoFd85Gb GT4BBCpY+fdfo5v37PL9PPYCPX8i1w== =7CCf -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 28 13:19:52 2020 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 F02A13A0B92 for ; Fri, 28 Aug 2020 13:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 gzEv_3d_pMPD for ; Fri, 28 Aug 2020 13:19:49 -0700 (PDT) Received: from dragonfly.birch.relay.mailchannels.net (dragonfly.birch.relay.mailchannels.net [23.83.209.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44FAB3A0B91 for ; Fri, 28 Aug 2020 13:19:48 -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 3C0FD1213B1; Fri, 28 Aug 2020 20:19:48 +0000 (UTC) Received: from pdx1-sub0-mail-a46.g.dreamhost.com (100-96-9-79.trex.outbound.svc.cluster.local [100.96.9.79]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id A6E2D1213F3; Fri, 28 Aug 2020 20:19:47 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a46.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.18.8); Fri, 28 Aug 2020 20:19:48 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Sponge-Cooperative: 6444005b7b003ef1_1598645987950_1069125511 X-MC-Loop-Signature: 1598645987950:2858762568 X-MC-Ingress-Time: 1598645987949 Received: from pdx1-sub0-mail-a46.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a46.g.dreamhost.com (Postfix) with ESMTP id 646C87F062; Fri, 28 Aug 2020 13:19:47 -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=i+h+4R8oKEyh1a uMR3eQP7aaa38=; b=lxSMtydDdnHtIFbltskEm3+QVrTL3JXkDlFz8ymAXZCs9x PhbhvsBgtvN09YJ2pdPUFjfzE10cehzH1KU24cYgcR8TiPzOh2zpiy4SL30Gi+Iu zqahzXSl3ArtmyN1njBJPKcZqFyoUA4bYxEIJfFW0R20mFDePsb+3JKPceZQU= 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-a46.g.dreamhost.com (Postfix) with ESMTPSA id 8E5407F061; Fri, 28 Aug 2020 13:19:46 -0700 (PDT) Date: Fri, 28 Aug 2020 15:19:44 -0500 X-DH-BACKEND: pdx1-sub0-mail-a46 From: Nico Williams To: Michael Richardson Cc: saag@ietf.org Message-ID: <20200828201942.GU3100@localhost> References: <20200728191331.GV41010@kduck.mit.edu> <20200822014328.GI37427@straasha.imrryr.org> <32690.1598215107@localhost> <20200824021601.GS3100@localhost> <17304.1598644198@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17304.1598644198@localhost> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: 0 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduiedruddvkedgfeegucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecuggftrfgrthhtvghrnhepffdtkeethfeuteeviefgfeegjeetjedvhfehgfdvtdefueejheelgeeuhffghffgnecukfhppedvgedrvdekrddutdekrddukeefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomh Archived-At: Subject: Re: [saag] On PKI vs. Pinning (SAAG 108 preview) 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, 28 Aug 2020 20:19:51 -0000 On Fri, Aug 28, 2020 at 03:49:58PM -0400, Michael Richardson wrote: > Nico Williams wrote: > > In the first two cases ... > > I agree with your analysis. I hadn't understood that those were specifically TLSA RR usage values. So I was a bit confused, but still, I think the analysis was right. > Do you think we need to capture it into a document? It might be nice. The realization that DANE is akin to a pin dist. mechanism, that app stores and such are comparable in that sense, seems like something that should be written down somewhere. > > There's one more. draft-dukhovni-tls-dnssec-chain allows ... > > I didn't know that this document exists. To save others the step of learning > about it: > ... > > So, I wanted to do EXACTLY this for IPsec OE (RFC4322). Yeah! > I imagined two entities (Opus and Bill the Cat) sitting in a meadow, doing > security of IPv6-LL addresses without any outside connectivity. > [You can't expect a dead cat to fetch CRLs..] You'd need an IKEv2 extension like Viktor's TLS extension, but which also includes A/AAAA RRsets. > I guess this is intended for the TLS WG? Funny story about that. There had been a TLS WG work item for it that didn't support either the extension pin or the denial of existence chain, and when we pushed for that to be added WG consensus fell apart and the WG dropped the I-D with the agreement that all parties would get to publish their own versions of it on the ISE. > > Pinning lets apps detect MITM attacks, but not whether they are > > tolerable attacks (enterprise proxies). > > Agreed. > That would have to come by some attestation statement in the decline. > draft-ietf-capport-api-08 is one place I would like to that. Tolerable attacks are essentially site-local pins that the app needs to decide are OK or not OK, probably by hardcoding an OK/not-OK policy. > > In enterprise environments it's common to allow connection to banking > > sites through proxies w/o MITMing them. Typically the banking sites > > allowed are either on some generic list (e.g., supplied by the > > enterprise proxy vendor), or those that the proxy's operator has > > reporting agreements with. > > Yes. But, generating exceptions to the site administrator to approve/deny > might also be a good way to this. MUD/RFC8520 statements from the app would > also be interesting as supporting evidence. Yes. Nico -- From nobody Fri Aug 28 14:32:07 2020 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 2D4553A0C99 for ; Fri, 28 Aug 2020 14:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 WAdMWmKgarub for ; Fri, 28 Aug 2020 14:32:03 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D9543A0C90 for ; Fri, 28 Aug 2020 14:32:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 00DFF389F8; Fri, 28 Aug 2020 17:11:02 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id KdIiA-xiZe0J; Fri, 28 Aug 2020 17:11:00 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 78A92389F7; Fri, 28 Aug 2020 17:11:00 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 88F126D2; Fri, 28 Aug 2020 17:32:00 -0400 (EDT) From: Michael Richardson To: Nico Williams cc: saag@ietf.org In-Reply-To: <20200828201942.GU3100@localhost> References: <20200728191331.GV41010@kduck.mit.edu> <20200822014328.GI37427@straasha.imrryr.org> <32690.1598215107@localhost> <20200824021601.GS3100@localhost> <17304.1598644198@localhost> <20200828201942.GU3100@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [saag] On PKI vs. Pinning (SAAG 108 preview) 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, 28 Aug 2020 21:32:05 -0000 --=-=-= Content-Type: text/plain Nico Williams wrote: >> So, I wanted to do EXACTLY this for IPsec OE (RFC4322). > Yeah! >> I imagined two entities (Opus and Bill the Cat) sitting in a meadow, doing >> security of IPv6-LL addresses without any outside connectivity. >> [You can't expect a dead cat to fetch CRLs..] > You'd need an IKEv2 extension like Viktor's TLS extension, but which > also includes A/AAAA RRsets. Yes, exactly. RFC4322 was also going to have a standards track version that depended upon IKEv2, and RFC4025...but. >> I guess this is intended for the TLS WG? > Funny story about that. There had been a TLS WG work item for it that > didn't support either the extension pin or the denial of existence > chain, and when we pushed for that to be added WG consensus fell apart > and the WG dropped the I-D with the agreement that all parties would get > to publish their own versions of it on the ISE. Oh. I feel many beers may be required to understand. Or perhaps to achieve consensus :-) >> > Pinning lets apps detect MITM attacks, but not whether they are >> > tolerable attacks (enterprise proxies). >> >> Agreed. >> That would have to come by some attestation statement in the decline. >> draft-ietf-capport-api-08 is one place I would like to that. > Tolerable attacks are essentially site-local pins that the app needs to > decide are OK or not OK, probably by hardcoding an OK/not-OK policy. Enough that your banking app can say, "Example.COM says you can not connect securely, please try a different network", .. and the user can realize that they are on the example.com guest network. So, okay. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl9Jd9AACgkQgItw+93Q 3WW8IwgAk8At0p/7QMXnHFA5NHkVcNSut6sEOilhhEImYVWd9fp7Q5t/LlaOFMdx l1ozeEBiRkzkEa2AHD/PP3966GjzslxqtLa1Qg8UXLHFL1nl/hA/dFucSs/h/zwc LokAO3d0s/xPspRUrffeq9jGoRXnEtksf7UApRDccFb4ahlm+dO5NCFv/Fb2f2yl 6yVC2k4k/TJgl9P0HdGM3a3KXX7CVrCmI69/xXxe9bCU0cxyG9gVeB4cCpGBEMJ8 Z1AQCy9uqH9jsDDyfOKszc/uNjqzlDsPWA3saFgE9H8xaowm1bLmZMB6gg5NeJhB 03uCLd3H4p9zb6GB0ap/exbN6Najyg== =TGGi -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 28 14:40:15 2020 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 E566F3A0CC6 for ; Fri, 28 Aug 2020 14:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLyLgrOTHugy for ; Fri, 28 Aug 2020 14:40:12 -0700 (PDT) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0F6D3A0CCA for ; Fri, 28 Aug 2020 14:40:11 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id g6so397157ljn.11 for ; Fri, 28 Aug 2020 14:40:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xKBoTmqbhJRAut9BINeItkfCXE8pBrfjC5r9NwsB13A=; b=tx9VeHz3rDDIYfQqZslNVtKld62rU3W8nGfr5Fu5D5RNNOjhjYeGxw0ot67mvnKcZx 9D+Mf/e6gHGw1eGKECrhLJ17FgcQQOdclngNzebkpzCqazmlY1zbPC8XINdd1/prgM/U B+uZ0tnkEweg2IPk8A5xqKkeRIduBbRDdcF5uIdZkWpwFFvSaLrTYUwxbd5feh1gtTrY 3Y49wNRaMQt1EMbkqWyR/jqGmqsBrGOD4OsNEATmmFIIHCZRbbVJ0wbPD4iCBNY09g0j 4MKGqPF5P+cz3juTVTgG7o7vDnbiEvU55N/3z5AFOYZvrZ3m6uTDkzl8b5KCL9rRi4+v 1z7A== 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=xKBoTmqbhJRAut9BINeItkfCXE8pBrfjC5r9NwsB13A=; b=GTBLoOMbiktsUSqyalGKZb1UEysCvD0kQWCvxs7/0H547YzUv5k2NOLdUZAu0o1Sy3 Ar9cB9kQ2otldhloPbFsp/NYQRmtfKPzW5eBcLK/txHD/iozwIuqZvFbmqAPF+tjJwc+ QEDhhDi5/2D7cNfs7R0illsiexeuFjL8D+tIp2inJmiu+xWvlvcWnWJE+1CQEX7TbZui p6l7Sq9XZTYjqnPjbXehE2qFPiZj2afd3w4Ga+uAUiK0XW1dqUgAu2UBwFBdZ296SeLx nwM2fnIUb9Jfh/dR9XZZxSdCoxHEUMlg7pFf6MXqUwqv6U//NLPoUmAqpYSgjhIxXn/0 I6IA== X-Gm-Message-State: AOAM532Op+9vNVqZs9H5drupeOATxEB2cORh3GDey/yvWMMVbfyprNQ1 TuJLbT3p8pFZcSUYoTsI04l+nS4A76NXK7FFcZ2Tjw== X-Google-Smtp-Source: ABdhPJyuPKN6sSGQr2GTmlWcBQaBM7XZCyt+0qAp+UIQVCmPxDLJ/ayE0/4/76i6oHWV05OU3aDKyxAWt1fkH0z8kxw= X-Received: by 2002:a2e:908a:: with SMTP id l10mr300244ljg.409.1598650809694; Fri, 28 Aug 2020 14:40:09 -0700 (PDT) MIME-Version: 1.0 References: <20200728191331.GV41010@kduck.mit.edu> <20200822014328.GI37427@straasha.imrryr.org> <32690.1598215107@localhost> <20200824021601.GS3100@localhost> <17304.1598644198@localhost> <20200828201942.GU3100@localhost> <9251.1598650320@localhost> In-Reply-To: <9251.1598650320@localhost> From: Eric Rescorla Date: Fri, 28 Aug 2020 14:39:33 -0700 Message-ID: To: Michael Richardson Cc: Nico Williams , IETF SAAG Content-Type: multipart/alternative; boundary="000000000000a1d1c905adf6e506" Archived-At: Subject: Re: [saag] On PKI vs. Pinning (SAAG 108 preview) 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, 28 Aug 2020 21:40:14 -0000 --000000000000a1d1c905adf6e506 Content-Type: text/plain; charset="UTF-8" On Fri, Aug 28, 2020 at 2:32 PM Michael Richardson wrote: > > Nico Williams wrote: > > > Tolerable attacks are essentially site-local pins that the app needs > to > > decide are OK or not OK, probably by hardcoding an OK/not-OK policy. > > Enough that your banking app can say, "Example.COM says you can not connect > securely, please try a different network", .. and the user can realize > that > they are on the example.com guest network. So, okay. > Note that this is not how browser clients behave. Rather, they do not enforce pin checks when the certificate chains to a locally installed root. I do not know how apps behave. Does someone have an example of one that enforces pin checks against locally installed roots? -Ekr --000000000000a1d1c905adf6e506 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Aug 28, 2020 at 2:32 PM Micha= el Richardson <mcr+ietf@sande= lman.ca> wrote:

Nico Williams <nico@cryptonector.com> wrote:

=C2=A0 =C2=A0 > Tolerable attacks are essentially site-local pins that t= he app needs to
=C2=A0 =C2=A0 > decide are OK or not OK, probably by hardcoding an OK/no= t-OK policy.

Enough that your banking app can say, "Example.COM says you can not co= nnect
securely, please try a different network",=C2=A0 .. and the user can r= ealize that
they are on the example.com guest network.=C2=A0 So, okay.

Note that this is not how browser clients behave. Rather, = they do not enforce pin checks when the certificate chains to a locally ins= talled root. I do not know how apps behave. Does someone have an example of= one that enforces pin checks against locally installed roots?

-Ekr

--000000000000a1d1c905adf6e506-- From nobody Fri Aug 28 14:57:05 2020 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 8D0BC3A0CDB for ; Fri, 28 Aug 2020 14:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.946 X-Spam-Level: X-Spam-Status: No, score=-2.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.948, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 YVQ_qYBxKh28 for ; Fri, 28 Aug 2020 14:57:01 -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 7F2B43A0CD6 for ; Fri, 28 Aug 2020 14:57:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 47E33BE55; Fri, 28 Aug 2020 22:56:59 +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 qB2uRleo50-s; Fri, 28 Aug 2020 22:56:57 +0100 (IST) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1D032BE4D; Fri, 28 Aug 2020 22:56:57 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1598651817; bh=+WUpkrxsYQ9razJXPC6VnyPcypBn1elG+C9VAuCKhoo=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Fi4SBvPPMRG6mqgi99GfSk5HxYDWUgvlOl5y6pregtOWrhQo1njgNS2nkoYbEwBYC fT+c8RsUYoS2lhddc+1h3HSm2vpKIegLshOYQCl3xKxscuivBci5eNDEw8DWD5ysFv eFXDPUzJjo59wL0F2JIdHFrpPp45yrXQjNk/zIOI= To: Eric Rescorla , Michael Richardson Cc: IETF SAAG References: <20200728191331.GV41010@kduck.mit.edu> <20200822014328.GI37427@straasha.imrryr.org> <32690.1598215107@localhost> <20200824021601.GS3100@localhost> <17304.1598644198@localhost> <20200828201942.GU3100@localhost> <9251.1598650320@localhost> From: Stephen Farrell 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: <77d05b80-5214-6cbe-85f5-560f09296fa1@cs.tcd.ie> Date: Fri, 28 Aug 2020 22:56:56 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------2C20B612152FDE8E030373A2" Content-Language: en-US Archived-At: Subject: Re: [saag] On PKI vs. Pinning (SAAG 108 preview) 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, 28 Aug 2020 21:57:04 -0000 This is a multi-part message in MIME format. --------------2C20B612152FDE8E030373A2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 28/08/2020 22:39, Eric Rescorla wrote: > On Fri, Aug 28, 2020 at 2:32 PM Michael Richardson > wrote: > >> >> Nico Williams wrote: >> >> > Tolerable attacks are essentially site-local pins that the app needs >> to >> > decide are OK or not OK, probably by hardcoding an OK/not-OK policy. >> >> Enough that your banking app can say, "Example.COM says you can not connect >> securely, please try a different network", .. and the user can realize >> that >> they are on the example.com guest network. So, okay. >> > > Note that this is not how browser clients behave. Rather, they do not > enforce pin checks when the certificate chains to a locally installed root. > I do not know how apps behave. Does someone have an example of one that > enforces pin checks against locally installed roots? I'm not quite sure what you're asking but a number of the GAEN covid-tracking apps enforce pins [1], for example the Irish app ships with 5 root CA pins, 4 of which are for the CA service in use today with one from a different CA service that is presumably for insurance. There seem to be two or three libraries that are used by such apps for this kind of pinning. Cheers, S. [1] https://www.scss.tcd.ie/Doug.Leith/pubs/contact_tracing_app_traffic.pdf > > -Ekr > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --------------2C20B612152FDE8E030373A2 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: 7bit 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 =YzQY -----END PGP PUBLIC KEY BLOCK----- --------------2C20B612152FDE8E030373A2-- From nobody Fri Aug 28 16:02:59 2020 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 AA3B23A0D88 for ; Fri, 28 Aug 2020 16:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 gzZCHnKkMMLw for ; Fri, 28 Aug 2020 16:02:56 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3115F3A0D81 for ; Fri, 28 Aug 2020 16:02:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 18507389FE; Fri, 28 Aug 2020 18:41:54 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ZPh4L_gkglTS; Fri, 28 Aug 2020 18:41:53 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 61B5F389FD; Fri, 28 Aug 2020 18:41:53 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 74F7A91C; Fri, 28 Aug 2020 19:02:53 -0400 (EDT) From: Michael Richardson To: Stephen Farrell cc: Eric Rescorla , IETF SAAG In-Reply-To: <77d05b80-5214-6cbe-85f5-560f09296fa1@cs.tcd.ie> References: <20200728191331.GV41010@kduck.mit.edu> <20200822014328.GI37427@straasha.imrryr.org> <32690.1598215107@localhost> <20200824021601.GS3100@localhost> <17304.1598644198@localhost> <20200828201942.GU3100@localhost> <9251.1598650320@localhost> <77d05b80-5214-6cbe-85f5-560f09296fa1@cs.tcd.ie> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [saag] On PKI vs. Pinning (SAAG 108 preview) 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, 28 Aug 2020 23:02:58 -0000 --=-=-= Content-Type: text/plain Stephen Farrell wrote: >> Note that this is not how browser clients behave. Rather, they do not >> enforce pin checks when the certificate chains to a locally installed root. >> I do not know how apps behave. Does someone have an example of one that >> enforces pin checks against locally installed roots? > I'm not quite sure what you're asking but a number of > the GAEN covid-tracking apps enforce pins [1], for > example the Irish app ships with 5 root CA pins, 4 of > which are for the CA service in use today with one from > a different CA service that is presumably for insurance. > There seem to be two or three libraries that are used > by such apps for this kind of pinning. What happens if there is an official MITM installed on the phone, and the phone is in that "Enterprise"? I assume it doesn't work, but what does the app *do*? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl9JjR0ACgkQgItw+93Q 3WU26QgArtKhPSZ0GVUTwxPFA6kpICmxCrfg2D5p0GQEZ11fI7HhB/Ey7czAY7k1 81H227J/q4Rn9TKROotuDQwVoE1ODkJhoMBDhAEtVNjRuoJHjWaR64jI1267j4Y+ glOJx0tfICCpKs4I2stpjiz5WoRrqfrXE0eZAKv1U/LLID7IYcYqwcYgLZ1ydA1l o6F9Y6c1T7QgdIu/sbEDqjEJCC4owQR6YhiP33mAayWGV9bN9a5M9kgv5Yu7S8cv XC2EeG/jJVUUqkFNTKi6ZtZjgW3IhqivKsAUvpHQnVb0hpbqs7AOC+mi9XwlWg8B ZeTKsLZy6QQy5jZcB1zv4K5lmIwpfw== =af53 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 28 16:28:05 2020 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 7ACA73A0DD8 for ; Fri, 28 Aug 2020 16:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.947 X-Spam-Level: X-Spam-Status: No, score=-2.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.948, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 PDsPbAxIj2E1 for ; Fri, 28 Aug 2020 16:28:02 -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 8445F3A0DCB for ; Fri, 28 Aug 2020 16:28:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 31C14BE53; Sat, 29 Aug 2020 00:28:00 +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 FoWavC5wKmtn; Sat, 29 Aug 2020 00:27:58 +0100 (IST) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5A5A3BE4C; Sat, 29 Aug 2020 00:27:58 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1598657278; bh=b4pSd+lh2JKa5kwtfPB+9v+b+FKZPRN5t6UKcnbWckQ=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=y9fe7QQnQ3KLFPXDmz29h753T094zOErtjnc4Kj29+57ydyPjLyg19m+8/12y3PGg tMSQboX+YKb4ogQFXH4oE5uZkMjJpAY+k5FRRxPLHStNxQ/aK5WTbPphrFHHHPbzTj s1vFrnP65207VeupIN7hVAGj3I3dFYPvm1K2XyKY= To: Michael Richardson Cc: Eric Rescorla , IETF SAAG References: <20200728191331.GV41010@kduck.mit.edu> <20200822014328.GI37427@straasha.imrryr.org> <32690.1598215107@localhost> <20200824021601.GS3100@localhost> <17304.1598644198@localhost> <20200828201942.GU3100@localhost> <9251.1598650320@localhost> <77d05b80-5214-6cbe-85f5-560f09296fa1@cs.tcd.ie> <30652.1598655773@localhost> From: Stephen Farrell 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: <16f7e02b-b2bd-a704-8fb4-476bb1befaf4@cs.tcd.ie> Date: Sat, 29 Aug 2020 00:27:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <30652.1598655773@localhost> Content-Type: multipart/mixed; boundary="------------8B14F0A379EB70092E7F6459" Content-Language: en-US Archived-At: Subject: Re: [saag] On PKI vs. Pinning (SAAG 108 preview) 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, 28 Aug 2020 23:28:05 -0000 This is a multi-part message in MIME format. --------------8B14F0A379EB70092E7F6459 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 29/08/2020 00:02, Michael Richardson wrote: > What happens if there is an official MITM installed on the phone, > and the phone is in that "Enterprise"? > I assume it doesn't work, but what does the app *do*? I believe the intent is that an enterprise MITM ought not see that a person has tried to upload keys as a result of a positive COVID test (that being sensitive medical information) and so the app would fail to connect to the public health authority services whilst being MITM'd. I don't know what the UI would display in that case as we didn't do any tests of the upload features, as that could in theory interfere with a live service. For the regular download (every ~2 hours), I'd have to re-do the test to be sure, but IIRC, the app didn't display anything to the user, just the same as if the n/w weren't up at that time. (Pinning for the download isn't as big a deal though as the data retrieved is signed at the application layer so it could be ok if some of the apps don't enforce pins for downloads.) Most of these apps are open-source though so you could figure it out if it mattered. Cheers, S. PS: I know what you meant but "official MITM" is a bit of a yukkie term;-) --------------8B14F0A379EB70092E7F6459 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----- --------------8B14F0A379EB70092E7F6459-- From nobody Sun Aug 30 13:09:52 2020 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 7EC1A3A05AC; Sun, 30 Aug 2020 13:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IeRElhFsTWby; Sun, 30 Aug 2020 13:09:46 -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 447AB3A05DE; Sun, 30 Aug 2020 13:09:45 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 07UK9fll024375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 30 Aug 2020 16:09:44 -0400 Date: Sun, 30 Aug 2020 13:09:41 -0700 From: Benjamin Kaduk To: saag@ietf.org, cfrg@ietf.org Message-ID: <20200830200941.GF16914@kduck.mit.edu> References: <159836219987.32362.11412587430977260446@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <159836219987.32362.11412587430977260446@ietfa.amsl.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: [saag] Fwd: Last Call: (Alternative Elliptic Curve Representations) to Informational RFC 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: Sun, 30 Aug 2020 20:09:48 -0000 Hi all, I think we've seen this draft discussed previously, but just wanted to raise visibility that it has entered IETF Last Call. -Ben On Tue, Aug 25, 2020 at 06:29:59AM -0700, The IESG wrote: > > The IESG has received a request from the Light-Weight Implementation Guidance > WG (lwig) to consider the following document: - 'Alternative Elliptic Curve > Representations' > as Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits final > comments on this action. Please send substantive comments to the > last-call@ietf.org mailing lists by 2020-09-08. Exceptionally, comments may > be sent to iesg@ietf.org instead. In either case, please retain the beginning > of the Subject line to allow automated sorting. > > Abstract > > > This document specifies how to represent Montgomery curves and > (twisted) Edwards curves as curves in short-Weierstrass form and > illustrates how this can be used to carry out elliptic curve > computations using existing implementations of, e.g., ECDSA and ECDH > using NIST prime curves. We also provide extensive background > material that may be useful for implementers of elliptic curve > cryptography. > > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-representations/ > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce