Subject: [Dcrup] Hashed Key Records

From: Scott Kitterman <[email-masked]>
Date: Thu, 22 Jun 2017 19:17:13 -0400

It seemed like the hashed RSA variant ought to be easy enough to implement, so 
I decided to give it a go.  I almost immediately ran into a question.  For 
terminology, I'm using what openssl says [1]

I am assuming that "SHA-256 hash of the public key, stored in base64" means 
use the output of the digest in binary form (--binary) option and encode it in 
base 64.  Is that correct?

So if my signing key were (I know, but just to make sure I understand the 
tranformations):

'Hello World'

Then the the p tag in DNS would be:

p=pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=

Am I understanding it correctly?

A python one liner:

>>> base64.b64encode(hashlib.sha256(b'Hello World').digest())
'pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4='

Scott K

[1] https://www.openssl.org/docs/man1.1.0/apps/sha256.html

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 22 Jun 2017 19:44:54 -0400

I would really like to get to a point where we could use one fingerprint
format everywhere. This would then allow fingerprints to be cut and pasted
from one place to another.

When I suggest we do something of this sort, people say 'write a draft'.
Once I write a draft they say I am peddling my proposal. So pretend that I
don't have a draft yet. These are the features I think are needed:

1) Use Base32 encoding.

DNS labels are case insensitive. Using fingerprints in DNS labels is very
powerful. It allows DANE like effects without the need for DANE records or
DNSSEC.

2) Incorporate the algorithm identifier into the fingerprint, do so in a
way that ensures a Base32 fingerprint will never be confused with a PGP
fingerprint.

3) Include a description of the content type in the target of the
fingerprint. This prevents semantic substitution attacks.

4) Allow for optional grouping of characters to encourage readability.

On Thu, Jun 22, 2017 at 7:17 PM, Scott Kitterman <[email-masked]>
wrote:

> _______________________________________________
> Dcrup mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dcrup
>

---

From: Steve Atkins <[email-masked]>
Date: Thu, 22 Jun 2017 16:51:52 -0700

> On Jun 22, 2017, at 4:44 PM, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> I would really like to get to a point where we could use one fingerprint format everywhere. This would then allow fingerprints to be cut and pasted from one place to another.

+1.

> 
> When I suggest we do something of this sort, people say 'write a draft'. Once I write a draft they say I am peddling my proposal. So pretend that I don't have a draft yet. These are the features I think are needed:
> 
> 1) Use Base32 encoding. 
> 
> DNS labels are case insensitive. Using fingerprints in DNS labels is very powerful. It allows DANE like effects without the need for DANE records or DNSSEC.
> 
> 2) Incorporate the algorithm identifier into the fingerprint, do so in a way that ensures a Base32 fingerprint will never be confused with a PGP fingerprint.
> 
> 3) Include a description of the content type in the target of the fingerprint. This prevents semantic substitution attacks.
> 

(and maybe be specific about what embedded whitespace means)

These all seem good features..

I'm reminded of the $1$... style password hashes. Immediately recognizable in
general, but including enough embedded information that you know which
spec to follow.

Cheers,
  Steve

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 22 Jun 2017 20:01:28 -0400

> general, but including enough embedded information that you know which

​The other thing I would like is the ability to truncate fingerprints to
arbitrary lengths by truncating the string specifying the fingerprint. In
all but a few applications, a fingerprint with a workfactor of 2^118 is
sufficient to prevent most attacks.​ That is 25 characters in my proposal
(since there is a one byte algorithm identifier prefix).

There are also some hacks that can be used for compressing the fingerprint
but I don't think these would be relevant here.

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 22 Jun 2017 20:07:18 -0400

> but I don't think these would be relevant here.

I'm probably just grumpy because it's been a long day in a long week, but if 
you are going to not answer my question and go off in a completely different 
direction (in case you missed it, my question was about what's in the draft 
now, not an invitation to imagine what should be in the draft), would you 
please at least start your own thread so others are less likely to assume I 
already got my answer somewhere in what seems likely to be a long thread 
spiraling off into some new ocean that wants boiling?

Thanks,

Scott K

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 22 Jun 2017 20:20:01 -0400

This draft describes all the requirements etc and the current proposal.

https://tools.ietf.org/html/draft-hallambaker-udf-05

The reference implementation is actually rather shorter than the draft
describing the requirements. Basically it is little more than a wrapper
around SHA-2-512.

On Thu, Jun 22, 2017 at 8:07 PM, Scott Kitterman <[email-masked]>
wrote:

> > > I'm reminded of the $1$... style password hashes. Immediately
> recognizable
> > > in

---

From: "John Levine" <[email-masked]>
Date: 23 Jun 2017 01:18:31 -0000

>Am I understanding it correctly?

Yes.

For us oldthinkers who use shell scripts:

$ echo -n 'Hello World'|openssl sha256 -binary|base64
pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=

R's,
John

PS: In the interest of not inventing anything new, since every
existing DKIM key record has a base64 version of the data, these do
too.

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 23 Jun 2017 01:39:53 +0000

>existing DKIM key record has a base64 version of the data, these do

Thanks.  I'm working my way through implementing the new options and that seemed like a reasonable place to start.  The dkimpy trunk version of dknewkey.py [1] can make rsafp records now.

It may take awhile as I'm short on available time.

Scott K

[1] http://bazaar.launchpad.net/~dkimpy-hackers/dkimpy/trunk/files

---

From: denis bider <[email-masked]>
Date: Fri, 23 Jun 2017 07:34:27 -0600

I propose that the best fingerprint encoding designed so far is the
Bubble-Babble encoding by Antti Huima. Example:

xedec-nypul-taboz-mugaz-supak-nekyc-bibec-busek-fegon-gekug-loxix

It is easy to compare words both visually, and on the phone. Users like it.

I found the spec preserved here:

http://wiki.yak.net/589/Bubble_Babble_Encoding.txt

It was intended to be standardized as part of SSH, but somehow didn't make
it to RFC.

A number of implementations implemented Bubble Babble, and still have it.
However, open source implementations (you know who you are!) went with
hexadecimal (MD5) and now Base64 (SHA-256), and now we're stuck with that.

If we want to standardize a universal fingerprint format, Base32 is
certainly better than either hex or Base64. However, I'd suggest checking
out Bubble Babble.

denis

On Thu, Jun 22, 2017 at 5:44 PM, Phillip Hallam-Baker <[email-masked]

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 23 Jun 2017 16:52:32 +0000

Sounds similar to the dictionary scheme used in S/Key, https://tools.ietf.org/html/rfc2289 

> http://wiki.yak.net/589/Bubble_Babble_Encoding.txt

Perhaps someone would consider writing an individual draft, AD sponsored.

--  
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: [email-masked] Twitter: RichSalz

---

From: "John Levine" <[email-masked]>
Date: 23 Jun 2017 17:41:53 -0000

In article <CADPMZDD+1vG8=sMEPz=[email-masked]> you write:
>Bubble-Babble encoding by Antti Huima. ....

No doubt, but we're talking about the one in
draft-ietf-dcrup-dkim-crypto-02, in which I tried to make the minimum
perturbation to existing DKIM implementations.

If you're aware of reasons why that one can't be implemented, or has
horribly security problems, or otherwise won't interoperate, now's the
time to tell us about it.

R's,
John

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 23 Jun 2017 17:42:58 +0000

> No doubt, but we're talking about the one in draft-ietf-dcrup-dkim-crypto-
> 02, in which I tried to make the minimum perturbation to existing DKIM
> implementations.

I agree.  I was just trying to move that off to a separate track.

---

From: denis bider <[email-masked]>
Date: Fri, 23 Jun 2017 13:03:49 -0600

Certainly, did not mean to suggest that one was not fit for purpose. I was
responding specifically with respect to "one fingerprint everywhere". That
seems like a good idea to me, if only we could gather interest from
implementers of multiple protocols to adopt in the future. It would not
work as a DKIM-specific endeavor.