Re: [Mathmesh] UDF Design notes

Phillip Hallam-Baker <phill@hallambaker.com> Thu, 15 August 2019 17:09 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: mathmesh@ietfa.amsl.com
Delivered-To: mathmesh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F091200C1 for <mathmesh@ietfa.amsl.com>; Thu, 15 Aug 2019 10:09:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.398
X-Spam-Level:
X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxFAwXTTEHpu for <mathmesh@ietfa.amsl.com>; Thu, 15 Aug 2019 10:09:20 -0700 (PDT)
Received: from mail-ot1-f51.google.com (mail-ot1-f51.google.com [209.85.210.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 186E7120074 for <mathmesh@ietf.org>; Thu, 15 Aug 2019 10:09:20 -0700 (PDT)
Received: by mail-ot1-f51.google.com with SMTP id w4so7014796ote.11 for <mathmesh@ietf.org>; Thu, 15 Aug 2019 10:09:20 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bdF33XyAuCU/4AI08CnFonpIzGvQADVpC7fUrV/gj4A=; b=TBOtSnmQxev0AbQ2JD5Ug7Z4wm3susZvmC+t+1B9VeryrARv2GVwQA5uqusuMCi/zj nWAuL1xJjcGLJI056TtyFQjCzBxd21TgSf3XIvYCa3gSpBZfpCl8sS77z9Ine2TQD7pu h3RaH1D9tq+gYj/bSmq5y7lpZO4H6xKLyE0FAVVTfVMiHp7P3l8gnMmTaZwwuMIb8rab kwA3Csr4uZh9aaA2Njxq2sKraVe0D1dOixg6z8yqJWPEumEc5U+FlnxTOiGGf1IfLMfh OWnZFzVcpAQS0ibTk4vNbum7v9/zw6MOAnRI+mIIRygCS74Ns0Vfpt0hrFI6NDpQ8uvm HX9Q==
X-Gm-Message-State: APjAAAX3qf0m8KCdgwzU0+7p8I5am2gvIvGLLYqgbgtRZLyUSv3qqSNu jXhwn9vFGzKb+kiCDfUZc/9GYFh9r6crx0cVsYg=
X-Google-Smtp-Source: APXvYqy06J0McJa4qmuSmdh80JekFtI7Uh2vvvoQl7qRlj/UX6PmEb7a790GnBL0gENTKi6E3kJf8Sns/myj9YeChJ8=
X-Received: by 2002:a05:6830:1e0f:: with SMTP id s15mr4586018otr.231.1565888959345; Thu, 15 Aug 2019 10:09:19 -0700 (PDT)
MIME-Version: 1.0
References: <CAMm+LwgqiUNNqR73uO6=iuK0VUPEBWdVLVp7H=KxiB-O8_y+hQ@mail.gmail.com> <30023.1565826313@localhost>
In-Reply-To: <30023.1565826313@localhost>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Thu, 15 Aug 2019 13:09:08 -0400
Message-ID: <CAMm+LwizfcbMAayv_=cX7c+-Y5VXRBT4_y=w_Eac7_KWo-fZ7Q@mail.gmail.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: mathmesh@ietf.org
Content-Type: multipart/alternative; boundary="0000000000002dfbe705902aef42"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mathmesh/SzV7lBNSyA5fctFHcglIOtkAsNg>
Subject: Re: [Mathmesh] UDF Design notes
X-BeenThere: mathmesh@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <mathmesh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mathmesh>, <mailto:mathmesh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mathmesh/>
List-Post: <mailto:mathmesh@ietf.org>
List-Help: <mailto:mathmesh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mathmesh>, <mailto:mathmesh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Aug 2019 17:09:22 -0000

On Wed, Aug 14, 2019 at 7:45 PM Michael Richardson <mcr+ietf@sandelman.ca>;
wrote:

>
> Phillip Hallam-Baker <phill@hallambaker.com>; wrote:
>     > The original starting point was the need for a 'better PGP
> fingerprint'. In
>     > particular, I wanted a digest representation that was:
>
>     > * Reasonably compact in both printed and voiced form.
>     > * Supported use of SHA2
>     > * Could be expressed at varying precision as the application needs
> demanded
>     > * Could be upgraded to make use of new algorithms if absolutely
> necessary
>     > * Could be input via a keyboard
>     > * Could be compared for equality
>     > * Could be used to create a fingerprint of any type of data (not
> just keys)
>     > * Support use in QR codes, DNS labels, etc.
>
> I think that this was a rather ambitious set of requirements :-)
>

Unless the requirements actually conflict, I would much rather make a
decision for a reason even if it is not a very strong one than flip a coin.

I don't have strong feelings on whether we should group the characters in
blocks of 4, 5 or 3/5 or whatever.




>     > The choice of Base32 comes from the observation that fingerprints are
>     > frequently read out aloud and having to distinguish case makes the
> process
>     > tedious and error prone. So it cant be Base64 but Base32 gives us
> five bits
>     > per char instead of four.
>
> I agree with your use.
> I wonder if we can train people not to need to mention the case as they
> compare.  I should look again if you specify upper-case only.
>

I am aiming for case insensitive because case is lost in a lot of contexts.
The QR code spec specifies upper case (I think) but the tools almost
invariably convert to lower.



>     > The Type Identifiers for SHA-2 and SHA-3 are chosen so as to cause
> the
>     > first letter of a SHA-2 digest to always be an M (for Merkle-Damgard
> and to
>     > remind us of the Rivest/MD5 legacy) and tthe first letter of a SHA-3
> digest
>     > will always be a K for Keccak.
>
> This was very cute.
>

The design constraint was that the fingerprints must not start with a hex
digit so that UDF and PGP fingerprints remain distinct.

>
>     > The two use cases that I am most tempted to add are representations
> for
>     > public and private key literals.
>
>     > PRO: One spec fits all.
>     > CON: Even 25519 keys are long do we read them out over the phone?
> Perhaps
>     > we should consider Base64?
>
> No, but being able to scan QR codes with public keys is important.
> DPP needs/uses this already.
>

If you want QR codes of the public keys, that would probably mean we should
go for Base32. I would have to actually try it out but I think it turns out
that Base32  maps onto the supported QR code encodings more efficiently
than Base64.

I don't think that reading base64 over the phone will ever be a thing.
> Validating (visually) that a QR scan worked right will be a thing.
> I prefer to keep it all in base32.
>

That is certainly my preference. I will add it into the draft once I have
the sync bug I am chasing sorted. Given the existing code, I think I can
probably hammer it out in a few hours because the code I use to take
fingerprints of public keys is already using the PKIX keyinfo format.

Lets break this out into a separate thread. Can you suggest the data flow?
I am assuming here that this is so I can make a secure connection to a
device over WiFi without Internet connectivity so the connection mechanism
described in the doc isn't exactly going to work :).