Re: [ietf-dkim] Today's jabber #1271: Binary algorithms and algorithm spoofing during a transition.
Eric Allman <eric@neophilic.com> Thu, 18 May 2006 21:01 UTC
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgpcZ-0001aH-Vp for ietf-dkim-archive@lists.ietf.org; Thu, 18 May 2006 17:01:23 -0400
Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgpcX-0005wD-DS for ietf-dkim-archive@lists.ietf.org; Thu, 18 May 2006 17:01:23 -0400
Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k4IL0XsV021778; Thu, 18 May 2006 14:00:34 -0700
Received: from knecht.neophilic.com (dsl081-247-036.sfo1.dsl.speakeasy.net [64.81.247.36]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k4IL0Tdx021741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-dkim@mipassoc.org>; Thu, 18 May 2006 14:00:30 -0700
Received: from [10.0.2.35] ([10.0.2.35]) by knecht.neophilic.com (8.13.6.Alpha2/8.13.5) with ESMTP id k4IKxrAf094199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 May 2006 13:59:54 -0700 (PDT)
Date: Thu, 18 May 2006 13:59:46 -0700
From: Eric Allman <eric@neophilic.com>
To: Douglas Otis <dotis@mail-abuse.org>
Subject: Re: [ietf-dkim] Today's jabber #1271: Binary algorithms and algorithm spoofing during a transition.
Message-ID: <FE049B4F1BD1834142A9EFA3@rieux.local>
In-Reply-To: <C8548329-2A91-48C2-BBFE-AF1360AA2992@mail-abuse.org>
References: <446C85F0.8090302@cs.tcd.ie> <446CA16F.3050705@att.com> <20060518173859.46403.qmail@snake.corp.yahoo.com> <446CC337.3080502@mtcc.com> <20060518192525.48153.qmail@snake.corp.yahoo.com> <6677AD151581F16B12410C50@rieux.local> <C8548329-2A91-48C2-BBFE-AF1360AA2992@mail-abuse.org>
X-Mailer: Mulberry/4.0.4 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, score=-4.4 required=4.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.1
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on knecht.neophilic.com
X-Songbird: Clean, Clean
Cc: Mark Delany <MarkD+dkim@yahoo-inc.com>, ietf-dkim@mipassoc.org
X-BeenThere: ietf-dkim@mipassoc.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF DKIM Discussion List <ietf-dkim.mipassoc.org>
List-Unsubscribe: <http://mipassoc.org/mailman/listinfo/ietf-dkim>, <mailto:ietf-dkim-request@mipassoc.org?subject=unsubscribe>
List-Archive: <http://mipassoc.org/pipermail/ietf-dkim>
List-Post: <mailto:ietf-dkim@mipassoc.org>
List-Help: <mailto:ietf-dkim-request@mipassoc.org?subject=help>
List-Subscribe: <http://mipassoc.org/mailman/listinfo/ietf-dkim>, <mailto:ietf-dkim-request@mipassoc.org?subject=subscribe>
Sender: ietf-dkim-bounces@mipassoc.org
Errors-To: ietf-dkim-bounces@mipassoc.org
X-SongbirdInformation: support@songbird.com for more information
X-Songbird-From: ietf-dkim-bounces@mipassoc.org
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 200d029292fbb60d25b263122ced50fc
Doug, I think you have assumed that we have accepted your suggestion that all future algorithms will be represented by number. I, at least, have not. You also seem to have missed my point about Posix. Defining an abstract set of semantics and then doing a concrete profile (in this case, for the representation) looks great in theory, but for creating specs there is at least one datum that says the opposite. Just to be clear: my proposal is that we leave -base as is. One part of the DKK spec will be a mapping from the new binary form to the DKK form and vice versa. eric --On May 18, 2006 1:33:17 PM -0700 Douglas Otis <dotis@mail-abuse.org> wrote: > > On May 18, 2006, at 12:46 PM, Eric Allman wrote: > >> I think it's valuable to have the base spec define a "must >> implement" set of semantics. Connecting that to the >> representation will obviously differ depending on many things, >> not the least of which being text vs. binary representations. >> >> Since -base is (now) only defining TXT, it seems to make sense for >> that to remain the definition syntax. [Posix tried to define >> abstract semantics and then binding for each language. This was a >> disaster and after losing at least a year of time they went back >> to using C as the definition language.] >> >> It probably does make sense clarifying that /any/ representation >> has to include these basic values with the same semantics, but >> make it clear that the syntax is specific to TXT records and may >> or may not apply to others. I tried to do that by saying that >> the defined representation SHOULD be used for any text-based >> system, but perhaps I didn't go far enough. > > > If the binary RR uses a binary representation for the algorithm, > then within the base draft... > > ,--- >| a= The algorithm used to generate the signature (plain-text; >| REQUIRED). Verifiers MUST support "rsa-sha1" and "rsa-sha256"; >| signers SHOULD sign using "rsa-sha256". See Section 3.3 for a >| description of algorithms. >| >| ABNF: >| >| sig-a-tag = %x61 [FWS] "=" [FWS] sig-a-tag-alg >| sig-a-tag-alg = "rsa-sha1" / "rsa-sha256" / x-sig-a-tag-alg >| x-sig-a-tag-alg = hyphenated-word ; for later extension > '___ > > > Could change to: > >: a= (plain-text string or decimal positive integer >: representation of an 8-bit algorithm number used to >: generate the signature; REQUIRED). The number is >: defined in the algorithm table that supports the KEY, SIG, >: DNSKEY, RRSIG, DS, and CERT RRs. See RFC3110 and >: draft-ietf-dnsext-dnssec-rsasha256. >: >: Verifiers must support (5) RSA/SHA-1 and (tbd) RSA/SHA-256. >: ABNF: >: >: sig-a-tag = %x61 [FWS] "=" [FWS] sig-a-tag-alg >: sig-a-tag-alg = "rsa-sha1" / "rsasha256" / "5" / "tbd" >: >: Future algorithms will always be specified by number. > > Or to avoid the draft dependency: > >: a= (plain-text string or decimal positive integer >: representation of an 8-bit algorithm number used to >: generate the signature; REQUIRED). When a number is used >: within the key, the same number MUST be used in the >: DKIM-Signature header field. >: >: Verifiers must support rsa-sha-1 and rsasha256. >: >: ABNF: >: >: sig-a-tag = %x61 [FWS] "=" [FWS] sig-a-tag-alg >: sig-a-tag-alg = "rsa-sha1" / "rsasha256" / 1*(DIGIT) >: >: Future algorithms will always be specified by number. > > > -Doug > > > > >> >> --On May 18, 2006 7:25:25 PM +0000 Mark Delany <MarkD+dkim@yahoo- >> inc.com> wrote: >> >>> On Thu, May 18, 2006 at 11:55:51AM -0700, Michael Thomas allegedly >>> wrote: >>>> Mark Delany wrote: >>>> >>>> >> OLD: TXT records are encoded as described in Section 3.6.1. >>>> >> >>>> >> >>>> > >>>> > So I've circulated the draft DKK to a couple of people to get >>>> > the roughest edges off. >>>> > >>>> > One of the big questions asked in that draft relates to the >>>> > relationship between TXT and DKK semantics. Which one is >>>> > authoritative and which one is a mirror? Or should base be >>>> > authoritative and both the TXT and DKK simply be particular >>>> > representations? >>>> > >>>> > >>>> Is there really any reason to force one to be the master of the >>>> other? >>> >>> Simply to avoid duplication of semantics. I was merely asking >>> which text is the source of truth and where should it reside. >>> Also, presumably if a DKK springs into existence, the TXT may >>> well be frozen at some point with new functionality only going >>> into the DKK RR. >>> >>> >>> Mark. >>> _______________________________________________ >>> NOTE WELL: This list operates according to >>> http://mipassoc.org/dkim/ietf-list-rules.html >>> >> >> >> _______________________________________________ >> NOTE WELL: This list operates according to >> http://mipassoc.org/dkim/ ietf-list-rules.html > > _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
- [ietf-dkim] Today's jabber in about 30 minutes... Stephen Farrell
- Re: [ietf-dkim] Today's jabber Tony Hansen
- Re: [ietf-dkim] Today's jabber Mark Delany
- Re: [ietf-dkim] Today's jabber Dave Crocker
- Re: [ietf-dkim] Today's jabber Eric Allman
- Re: [ietf-dkim] Today's jabber Michael Thomas
- Re: [ietf-dkim] Today's jabber Tony Hansen
- Re: [ietf-dkim] Today's jabber Tony Hansen
- Re: [ietf-dkim] Today's jabber Tony Hansen
- Re: [ietf-dkim] Today's jabber Michael Thomas
- Re: [ietf-dkim] Today's jabber Michael Thomas
- Re: [ietf-dkim] Today's jabber william(at)elan.net
- Re: [ietf-dkim] Today's jabber Douglas Otis
- Re: [ietf-dkim] Today's jabber Eric Allman
- Re: [ietf-dkim] Today's jabber Mark Delany
- Re: [ietf-dkim] Today's jabber Michael Thomas
- Re: [ietf-dkim] Today's jabber Eric Allman
- Re: [ietf-dkim] Today's jabber John Levine
- Re: [ietf-dkim] Today's jabber Michael Thomas
- Re: [ietf-dkim] Today's jabber #1271: Binary algo… Douglas Otis
- Re: [ietf-dkim] Today's jabber #1271: Binary algo… Eric Allman
- Re: [ietf-dkim] Today's jabber william(at)elan.net
- Re: [ietf-dkim] Today's jabber Tony Hansen
- Re: [ietf-dkim] Today's jabber #1271: Binary algo… Michael Thomas
- Re: [ietf-dkim] Today's jabber #1271: Binary algo… Douglas Otis
- Re: [ietf-dkim] Today's jabber Michael Thomas
- Re: [ietf-dkim] Today's jabber Douglas Otis
- Re: [ietf-dkim] Today's jabber Michael Thomas
- Re: [ietf-dkim] Today's jabber Douglas Otis
- Re: [ietf-dkim] multiple query mechanisms, was To… John Levine
- Re: [ietf-dkim] multiple query mechanisms, was To… Michael Thomas
- Re: [ietf-dkim] multiple query mechanisms, was To… Paul Hoffman
- Re: [ietf-dkim] multiple query mechanisms, was To… Michael Thomas
- Re: [ietf-dkim] Today's jabber william(at)elan.net
- Re: [ietf-dkim] multiple query mechanisms, was To… Paul Hoffman
- Re: [ietf-dkim] multiple query mechanisms, was To… Michael Thomas
- Re: [ietf-dkim] multiple query mechanisms, was To… Stephen Farrell
- Re: [ietf-dkim] multiple query mechanisms, was To… Douglas Otis
- Re: [ietf-dkim] multiple query mechanisms, was To… Eric Allman
- Re: [ietf-dkim] multiple query mechanisms, was To… Stephen Farrell
- [ietf-dkim] Today's jabber in about 30 minutes... Stephen Farrell