Re: [saag] post-X509 cryptographic identities

Nico Williams <nico@cryptonector.com> Fri, 14 February 2020 20:33 UTC

Return-Path: <nico@cryptonector.com>
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 4958A1201AA for <saag@ietfa.amsl.com>; Fri, 14 Feb 2020 12:33:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 vU2eGWil03L6 for <saag@ietfa.amsl.com>; Fri, 14 Feb 2020 12:33:30 -0800 (PST)
Received: from basenji.birch.relay.mailchannels.net (basenji.birch.relay.mailchannels.net [23.83.209.12]) (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 B3A0F1201DE for <saag@ietf.org>; Fri, 14 Feb 2020 12:33:17 -0800 (PST)
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 AC1B25025CC; Fri, 14 Feb 2020 20:33:16 +0000 (UTC)
Received: from pdx1-sub0-mail-a88.g.dreamhost.com (100-96-217-4.trex.outbound.svc.cluster.local [100.96.217.4]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 0282F502583; Fri, 14 Feb 2020 20:33:16 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a88.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Fri, 14 Feb 2020 20:33:16 +0000
X-MC-Relay: Junk
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Scare-Stupid: 02296a8b2ef2e153_1581712396464_3400858473
X-MC-Loop-Signature: 1581712396464:236097024
X-MC-Ingress-Time: 1581712396464
Received: from pdx1-sub0-mail-a88.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a88.g.dreamhost.com (Postfix) with ESMTP id 3EDB8A466D; Fri, 14 Feb 2020 12:33:11 -0800 (PST)
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=NZ1kRUioBhGLZn dpCH++ypI2Z98=; b=pYrB48FAifDltfg24nW7GAOVBP8Rxr0xCy2+6DzmmY8Uij O5uPLDHLngoQ7kz62+FwAuMEeZNKinZHFmSk9ebapDT4T3BB52kOfmCMDbk+hCyu 6RPMeAA+OFQ46krZG3AnUBlZv66rj/F8eevrs3INUJrUz1sKnePnvUN9RBmLQ=
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-a88.g.dreamhost.com (Postfix) with ESMTPSA id 30090A466B; Fri, 14 Feb 2020 12:33:09 -0800 (PST)
Date: Fri, 14 Feb 2020 14:33:07 -0600
X-DH-BACKEND: pdx1-sub0-mail-a88
From: Nico Williams <nico@cryptonector.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: saag@ietf.org
Message-ID: <20200214203306.GW18021@localhost>
References: <ac360994-e747-6913-fdc3-19b7db2e00c3@netmagic.com> <3854.1581431519@dooku> <20200213174617.GQ18021@localhost> <18044.1581688781@dooku>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <18044.1581688781@dooku>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-VR-OUT-STATUS: OK
X-VR-OUT-SCORE: 0
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedugedrjedtgddugedtucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecuffhomhgrihhnpegtrhihphhtohhnvggtthhorhdrtghomhdptghrhihpthhnvggtthhorhdrtghomhdpvgigrghmphhlvgdrtghomhdprghmrgiiohhnrdgtohhmpdhthhgvihhrrdgtohhmpdhkihhllhdrtghomhenucfkphepvdegrddvkedruddtkedrudekfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhm
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/v97E3DaF1aNjM0ADgjmh4P0RRyA>
Subject: Re: [saag] post-X509 cryptographic identities
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Feb 2020 20:33:34 -0000

On Fri, Feb 14, 2020 at 02:59:41PM +0100, Michael Richardson wrote:
> Nico Williams <nico@cryptonector.com> wrote:
>     > It seems like a miracle that we have DNS at all.
> 
>     > And when you talk about x.509 naming, it really does seem to mean that
>     > you're referring to dNSName SANs, so, DNS.
> 
>     > It seems unlikely to me that we could replace a global system we have
>     > (DNS) with a non-global system.  That's a lot of value to leave behind!
> 
> SPKI permitted things like:
>      DNS's www.cryptonector.com
> or:  Nico's second-floor bathroom

And for the first it's no different than PKIX.  And it'd better have
name constraints or it's worth diddly squat.

(It's hard to come up with a generic syntax for the second name form
that is amenable to name constraints, of course.  Name constraints in
that case have to be relying-party-side configuration.  That's OK for
simple name forms that are not meant to scale to Internet scale.)

> and in particular it would permit:
> or:  Russia's nameservice cryptnector.com        (national DNS root)
> or:  employer.example.com's www.amazon.com       (forced corporate proxy)

Sure, but PKIX let's you have this too: it's just an alternate issuer
(root).

What would SPKI have given us, really?

>     >> Typical PKI implementations just makes it really hard for end users to
>     >> actually manage their trust anchors, because it pretends that the
>     >> local trust anchors were a pronouncement from god.
> 
>     > Yes.  But that's not a fault of PKIX, or DNS, or anything other than
>     > the
> 
> I agree, it's not inheirently the result of PKIX, but then we got meaningless
> junk like CPS which makes it really hard for people (even lawyers) to have
> their own.

CPS is useless lipstick on a pig (WebPKI), so don't use it.

>     > So I take the opposite view: a single global namespace IS fine.  It may
>     > well be the single biggest key to the Internet's success.  WebPKI is
>     > busted.  ISTM incorrect to conclude that because WebPKI is busted, and
>     > that because the "I" in it wanted it to be a single global namespace,
>     > that then it must be that a global namespace is bad.
> 
> In the SPKI days I wanted no DNSSEC root.
> I wanted 158 national roots with k-of-n cross-signatures.

Cross-signing roots ~= a root anyways.

Every country could run its own roots with mostly or entirely the same
contents as all the others.  From a relying party's point of view,
there's a single root, and _that_ is what matters.

(A relying party might need to change root trust anchors when traveling
if they are forced to or want to change roots.)

I.e., DNS and DNSSEC are no as strongly single-rooted as they are made
out to be, we can continue to have interop with multiple mostly-the-same
national roots, and still avoid the mess of WebPKI because for every RP
there will always only be one root.  This can only introp well provided
that the alternate roots keep the same public keys for all the TLDs,
naturally, but it's feasible and workable and radically different from
WebPKI.

> Countries would recognize (in the political/legal, UN sense) each other by
> signing each other's ccTLD trust anchors.
> 
> Everyone in Canada would be obligated by law to use the "CA" trust anchors,
> and to get to "amazon.DE", I'd have to go "CA-cross->DE->amazon".

Sure.  We could still have this, but people sure like their .com
domains.  Without legal requirements to use ccTLDs, they won't be.

> Which definitely lets my government spoof me, which they already say they
> have the right to do under certain circumstances, but it doesn't let them
> spoof you.   Would we have to kill ".com", etc. and all the ICANN zoo?  
> Maybe. It's not a big loss to me, but others would object.  And we don't need
> to do it overnight.

Yes.  But if governments won't force you to do this, I don't mind.  That
is, we can have a single-root PKI (or a cross-signed root if you
prefer) in all cases.  And we can have mandatory or optional use of
ccTLDs.  It's all good.

> It also means that my government is assuming liability if I get spoofed,
> which also seems reasonable. 

Sovereigns always immunize themselves.  You will not be able to sue your
government over attacks on you resulting from your country's ccTLD
private keys being compromised.  At best some may be able to avoid some
losses when their counter-party is also operating in the same country,
but only entities other than their government will be taking the losses.

>     >> learn this practice as infants.  In the family environment names work
>     >> as identifiers, even today.  What we learn as infants is especially
>     >> difficult to re-learn later in life.  Therefore, it is natural for
>     >> people to translate the need to know who the keyholder is into a need
>     >> to know the keyholder's name.
> 
>     > Locality in naming usage does not imply that a global namespace is bad.
> 
> So, we see this in things like maps where national authorities inform
> google/bing/etc. what the official name of a conquored place is, in
> contradiction to what name the locals, (and possibly, the world) use.
> I don't know which name is global and which name is local, but I can do all
> of that with relative (SPKI) names.

Names relative to global names are still global names.

Names relative to name-less issuers are truly local names: local to RPs
that trust those issuers.  But RPs cannot trust very many such issuers,
so PKI for local names is not very interesting.

Nico
--