Re: What ASN.1 got right

Michael Thomas <mike@mtcc.com> Wed, 03 March 2021 00:18 UTC

Return-Path: <mike@fresheez.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E82BA3A14FB for <ietf@ietfa.amsl.com>; Tue, 2 Mar 2021 16:18:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=mtcc.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 QQ1-rTV62GeP for <ietf@ietfa.amsl.com>; Tue, 2 Mar 2021 16:17:59 -0800 (PST)
Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (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 572053A1693 for <ietf@ietf.org>; Tue, 2 Mar 2021 16:17:33 -0800 (PST)
Received: by mail-pl1-x62d.google.com with SMTP id z7so13011058plk.7 for <ietf@ietf.org>; Tue, 02 Mar 2021 16:17:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=efmH7mq7yeIeDO+lEdIkYxnKQhLRwkDb/QxWr9PLWfo=; b=f4SIi96jlwb8Qqd3gyoJf5GK30HTNs08lUhoGji2m0PeXXlTsIf6FHRgTqeNZ/6+cW edXxN1AJdzGPrwg6cyuNZ693JmBIoQp+o6mxzCF1oTDfkAAUFphgOAFTdIpAlW78mQmz sgWlXyuakAwIFX9LpBDO7uB5mod9j2iUw7Vqouj3gXmkTA+qQDWHYbcZjtKmcWbcSE8S RnCxGU6xIQc334aBYVHacyHiZPs1vi3eGQtI43Cp1xRtdd/ZT+rpAd4WcppbOKnzPJDv 6/ovnuu65tkh8L5H3IE8upAjHy71gptr8CpPKyqskW49+oCu34LtOdDiHbRGht0OoVDe vCog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=efmH7mq7yeIeDO+lEdIkYxnKQhLRwkDb/QxWr9PLWfo=; b=YJi1hsOPc5pmmwFIDXFM6EdYGK0MvYLeheQl9aEla5iUl5PH014jmNSoMs5L2Gu342 uTONTSuU2PgHZAJGwZg2sO0PoBXhezpChtNw8CiBi6B79YyTa/nB2Ym4dmWMUAFLdIZ2 nFm57yDRXUiFamyuKu4U2/p8/0v3TXdH3h18PER/5Ya+OzFDKxOPqzvYYZEUOOlxJSBh qD0qHCyor+BqhjNF1ZfStFHqe6TGy7JbJP2zPn/TVFMxtHgAAcPqDtU2WCrWax3HuIqw 0hYjXQMV8ZsKi8dIH7PUI7aqC3HSSG+lg6KAtjeZcbT8EaqGg4GlP1omRe9/4P5x8xG1 f+mg==
X-Gm-Message-State: AOAM531zTkAQKyl9jqt5J2PVtkFRfDqZQd9CBC0YhG9JMoj1+hVELzJW pMqAypHfjNFy5bJNVDtlujOzWu5oxQBB7g==
X-Google-Smtp-Source: ABdhPJz0YGYhDGvtTJpuqi2Xq56E36mSZ1BKgp5rd/pCa8iiMzcemrIak/hHIuvQbNBE24wiS0awIQ==
X-Received: by 2002:a17:902:c789:b029:e3:dcbd:843b with SMTP id w9-20020a170902c789b02900e3dcbd843bmr459097pla.61.1614730650855; Tue, 02 Mar 2021 16:17:30 -0800 (PST)
Received: from mike-mac.lan ([206.107.197.192]) by smtp.gmail.com with ESMTPSA id 1sm10021689pfh.90.2021.03.02.16.17.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Mar 2021 16:17:30 -0800 (PST)
Subject: Re: What ASN.1 got right
To: Nico Williams <nico@cryptonector.com>
Cc: Phillip Hallam-Baker <phill@hallambaker.com>, IETF Discussion Mailing List <ietf@ietf.org>
References: <0632b948-9ed1-f2bd-96da-9922ebb2aa60@mtcc.com> <006750D4-B70D-44F8-A01A-BD3AB136D9D3@webweaving.org> <a584ff73-34ae-1c9e-e746-ce98749461d7@mtcc.com> <20210302183901.GV30153@localhost> <CAMm+Lwj8QwuqaA3f625Ui8arc0TxY3uLXbG-PKToWGdtq8az6w@mail.gmail.com> <613072c6-5518-91e3-41b9-3b7590ee2346@mtcc.com> <CAMm+LwiEqL3bMg09e5NBNZwkPJ90DmQgLTy=SQNEN0q=vp=wrQ@mail.gmail.com> <ed6830b3-e650-d3fa-b253-9f53e01f9615@mtcc.com> <CAMm+LwifpPg-Sg9cXLpWvjmExt8KfuYq6oRZd4D1L0ZBR3nRFg@mail.gmail.com> <1631e20d-9d8a-b8c2-9d5e-6c7f4defa72d@mtcc.com> <20210302234928.GX30153@localhost>
From: Michael Thomas <mike@mtcc.com>
Message-ID: <cb4960e2-05a1-9d28-f17b-9f610ac378c9@mtcc.com>
Date: Tue, 2 Mar 2021 16:17:28 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.8.0
MIME-Version: 1.0
In-Reply-To: <20210302234928.GX30153@localhost>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/M4BbHVAaSkN8l2pFMtEnwYusW_s>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Mar 2021 00:18:01 -0000

On 3/2/21 3:49 PM, Nico Williams wrote:
> On Tue, Mar 02, 2021 at 03:23:24PM -0800, Michael Thomas wrote:
>> So I just looked up ssh certificates which I think somebody mentioned. This
>> is a prime example of throwing needless complexity at a problem. If you just
>> added the user's public keys to, say, an LDAP repo, you get the scaling they
> In the 80s the naive assumption was made that we'd have "white pages" --
> directories -- where we could do such lookups.  I think that's what you
> have in mind since you refer to an "LDAP repo".
>
> That did not work, and cannot work because it has privacy issues, at
> least when you do lookups _by name_.
>
> Now, maybe you have something different in mind.

I'm talking about the server side sshd just fetching the associated ssh 
keys with the user trying to log in, maybe with some authz sprinkled in 
for finer granularity. It could be LDAP, it could whatever you want. I 
don't know how configurable sshd is, so that might limit your choices.


>
> The authenticating party presents a directory name, a public key, and a
> signature, and the RP looks up the key in the directory to get a name?
>
> That might not have privacy issues, but it still requires online infra
> that someone has to pay for, and that RPs need to contact (so they need
> to do async I/O, naturally).  More things to break.
>
> And, of course, LDAP is insanely complex and brings X.500 naming right
> back into the picture completely unnecessarily (along with ASN.1,
> naturally).

I'm just using LDAP as an example of a well known corpro directory. It 
could be anything. It just needs to be something online that can store 
the name public key(s) binding so that the sshd can see if they should 
allow that user/key to log in.

>> claim to be solving for, and avoid all of the needless complexity of issuing
>> certs and installing them on the client. The client ssh doesn't need to do
>> anything different as bonus. With LDAP you get the added bonus that it can
> The client is also a relying party though, since it has to authenticate
> the server.
If you care about that, I suppose. I think most people do the leap of 
faith and known_hosts ignores the problem.
>> dish out attributes for things like roles and permissions, which would be a
>> giant headache if it had to be done with reissued certs every time your role
>> or permission changed.
> Certificates are infinitely easier.  Now, you mention "the needless
> complexity of issuing certs and installing them on the [authenticating
> party]".  But that's not so complex.  You can run an online CA that
> issues short-lived client certificates based on a longer-lived
> credential, and that and "installing" the certificates (and private
> keys) are purely internal details that users shouldn't need to know.
> That works for corporate networks, but it should work for a home network
> too.  For a Mesh-like scheme you're really going to need long-lived
> (forever) device public keys and revoke them only in the sense of
> removing the public keys from Alice's other devices, and there is a
> directory in Mesh case, but it's purely local (just Alice's devices,
> which should be few enough that the whole thing scales fine).

I don't see how doing nothing at all on the client can be "infinitely 
easier" than doing a lot of something else. Every company large enough 
to care about scaling authorized_keys is going to have some sort of 
employee directory system, so that complexity is baked in. And a 
directory based system doesn't suffer from the revocation problem 
either: if I lose my phone, I can just go and delete it as one of my 
devices.  On the server side it's six of one, half dozen of the other: 
it's just configuration that is baked with chef or puppet when it's 
brought up.


>
>> I'm trying to think of major things that use public key authentication.
>> There's TLS with certs, DKIM using raw public keys, and SSH mainly using raw
>> public keys. Am I missing anything else that is widely deployed? DNSsec and
>> BGP are still pretty skimpy from what I can tell.
> Kerberos, with PKINIT.  Mosh?  But note that SSH, TLS, and Kerberos (or,
> rather, GSS-API) covers... a lot of protocols -- practically all
> Internet protocols.

Is anybody using PKINIT?

Mike