Re: [Dcrup] Review of draft-ietf-dcrup-dkim-crypto-03

Peter Goldstein <peter@valimail.com> Sat, 08 July 2017 17:52 UTC

Return-Path: <peter@valimail.com>
X-Original-To: dcrup@ietfa.amsl.com
Delivered-To: dcrup@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B598312F3D0 for <dcrup@ietfa.amsl.com>; Sat, 8 Jul 2017 10:52:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.019
X-Spam-Level:
X-Spam-Status: No, score=-1.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.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 HjBmsA82uyyH for <dcrup@ietfa.amsl.com>; Sat, 8 Jul 2017 10:52:02 -0700 (PDT)
Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 0501A12F287 for <dcrup@ietf.org>; Sat, 8 Jul 2017 10:52:01 -0700 (PDT)
Received: by mail-qt0-x233.google.com with SMTP id r30so48021235qtc.0 for <dcrup@ietf.org>; Sat, 08 Jul 2017 10:52:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tt8eqj7UVYVzQv2+akEUMJT4PCpxMdTUzQBSF0HOgvI=; b=Z0K3pDWUN0P+m8vc0y4W8j4RyU4xAF22v53eU9ptThdYey0zeGNpnn1SJc26+o2iN6 P7XSM3VUbJBcmfzGTNYdKHq+DBI4cghl5zLp8drRp/ezluY2ElOGy6xCN4ZreiJRCNu/ v+bj+D8vYEHe6vzplUMcHSZSFtvLsrKJ6uwFlNt5MD+KWWCsqo02pvYLpGz9oVDNa0Nr 4ASFLve7TpSfUNJnLOx/gxzHO1qU6zx/3u6ixNrhDTMBR7L32hLYme5HXtVm92QqBkSL qL+xMA75ZnmkdpBx7Qg2A2KzWhvvFk34ZIMAmAM4MGCsfjJRizNYeiPnX/6bkm66TBY3 jmLg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tt8eqj7UVYVzQv2+akEUMJT4PCpxMdTUzQBSF0HOgvI=; b=qm+O22ws+Yd0uayG+CDMkspNcPNs/6RNg46RvhVDq+H5Tlgm2pgaXMMdpXLjoQMtPh 33D444GVHtIFC0fwrXt1rnXykVVTCl9OKVmLtGot6TXmczaP1qpqPK1lYwbN6a9XnN+y nzEC03m7cYIQzsSxmeaAQPnsLRTt9O7QstjxI2m3Fnb6Gwy0AU1gMnKHYx8z77gxYUR6 JGetMEbQpyLRKWR6YrNoTbFl/nP7eGqrn0Wi02jARIYDGwvWAduKNvns8gP2/fwSu84m tRFmhgkKFT4GxhII7kjNits6daiIBoyelMuK5ezxkiYT2BqNald3jHTS0j+8gieiChaj WA+w==
X-Gm-Message-State: AIVw112aX63UFWrmUwSzxZ3EstKcHyhCVEr8T1bvDvxg1Po6WXuMU9BV tnsutRx7l9Q09d/2BFnWrzjP1hg79kEdlzU=
X-Received: by 10.237.47.39 with SMTP id l36mr24162384qtd.181.1499536320995; Sat, 08 Jul 2017 10:52:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.12.185.157 with HTTP; Sat, 8 Jul 2017 10:52:00 -0700 (PDT)
In-Reply-To: <1C19FCE7-6AA3-4339-8BDE-F75C810505F2@kitterman.com>
References: <CABkgnnW8nnoRGKoJQ4STAcT6CXdWFRCpz0h20hw+ksfw1x0PGg@mail.gmail.com> <6d4b76c9b42848f1b18c42ba22895993@usma1ex-dag1mb1.msg.corp.akamai.com> <CABcZeBM-qh+iW_+Br2URpdjHsLZ_L1xqZWUVirW-8-E7k4cvzg@mail.gmail.com> <564f297f17424f34b4ba1e118ab6f62c@usma1ex-dag1mb1.msg.corp.akamai.com> <D4D564D0-73C6-45CA-9962-33106229DE02@bluepopcorn.net> <220DB06A-E06D-4DAF-ADE6-7536B6E43630@callas.org> <aeee2c9019114d9789a2cd768f0b15e1@usma1ex-dag1mb1.msg.corp.akamai.com> <5F68DFD3-9F87-4CE1-87C2-AA08B0A62338@callas.org> <1C19FCE7-6AA3-4339-8BDE-F75C810505F2@kitterman.com>
From: Peter Goldstein <peter@valimail.com>
Date: Sat, 08 Jul 2017 10:52:00 -0700
Message-ID: <CAOj=BA1LDz4x0EHdcpZKTBtNiSV4JznqpSHTcGg-H90kX-rx8g@mail.gmail.com>
To: Scott Kitterman <sklist@kitterman.com>
Cc: dcrup@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c0d03babdb7ca0553d2014e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dcrup/PN0FFP4k1_UFkJNQifJfh3Qi_yw>
Subject: Re: [Dcrup] Review of draft-ietf-dcrup-dkim-crypto-03
X-BeenThere: dcrup@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DKIM Crypto Update <dcrup.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dcrup>, <mailto:dcrup-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dcrup/>
List-Post: <mailto:dcrup@ietf.org>
List-Help: <mailto:dcrup-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dcrup>, <mailto:dcrup-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 08 Jul 2017 17:52:09 -0000

I agree with Scott.  I'm not sure what all this talk about future proofing
is about.  In this case hashing is a hack to work around DNS crudware that
doesn't properly support strings in excess of 255 bytes.

Unless I'm misreading RFC 8032 (certainly possible), the base 64 encoded
public key itself for Ed25519 is going to be just 64 characters.  Throw in
the version string and a couple of other tags and we'll be lucky to hit a
max size of 90 octets for the record.  That's well below the 255 byte limit
imposed by DNS crudware.  Even if future signature algorithms had 2x or 3x
bytes in the key, we'd still come in under the 255 byte limit.

Using a fingerprinted representation for Ed25519 just creates more work
with absolutely no benefit.  With fingerprinting the key itself needs to be
included in every single email message (consuming space) and the
fingerprint check needs to be done on each DKIM check (consuming
time/CPU).  And the whole verification process is just more complex.

We might, at some point in the future, have a non-RSA algorithm that
requires records that exceed 255 bytes.  But that's by no means a given, or
even a likelihood.  And per Scott's email, in that case we're still going
to need to define a new RFC, write new code, etc.

Best,

Peter

On Sat, Jul 8, 2017 at 3:00 AM, Scott Kitterman <sklist@kitterman.com>
wrote:

>
>
> On July 8, 2017 3:40:50 AM EDT, Jon Callas <jon@callas.org> wrote:
> >
> >> On Jul 7, 2017, at 7:24 PM, Salz, Rich <rsalz@akamai.com> wrote:
> >>
> >>> For what it's worth, I agree with Jim and Ekr. Hashing is just fine.
> >>
> >> Is it fine, or is it a required or just good?
> >
> >Fine. Into just good.
> >
> >>
> >> Nobody is saying there is anything wrong with hashing.  Several are
> >saying that, given the limitations of some DNS deployments, it is
> >useful to avoid the indirection and just put the key when we can.
> >
> >Yeah, I know. They've mentioned the limitations of some DNS
> >implementations going back to the original DKIM work. It's true, but I
> >tend to be on the side of just sucking it up and doing a big DNS query
> >over TCP or whatever.
> >
> >I'm also with Jim Fenton that I think the fingerprints make things more
> >future-proof, and I'd make some trivial encoding to put the algorithm
> >along with it for even more future-proofing.
>
> Let's imagine we go down the path of hashing everything.  When we want to
> add another new algorithm, how does having hashed the ECC key record help?
>
> It will still need a new RFC to define the new algorithm usage.
>
> It will still need new code to use the new algorithm.
>
> What future proofing does it buy?
>
> Also, you don't need to futz with the DNS record format to specify the
> algorithm.  That's already in the signature, so the verifier has that
> information before they even do the DNS lookup.
>
> Scott K
>
> _______________________________________________
> Dcrup mailing list
> Dcrup@ietf.org
> https://www.ietf.org/mailman/listinfo/dcrup
>



-- 


[image: logo for sig file.png]

Bringing Trust to Email

Peter Goldstein | CTO & Co-Founder

peter@valimail.com
+1.415.793.5783