Re: [ietf-dkim] Today's jabber #1271: Binary algorithms and algorithm spoofing during a transition.
Michael Thomas <mike@mtcc.com> Thu, 18 May 2006 22:43 UTC
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgrDP-0006PC-9s for ietf-dkim-archive@lists.ietf.org; Thu, 18 May 2006 18:43:31 -0400
Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgrDM-0004I1-Nv for ietf-dkim-archive@lists.ietf.org; Thu, 18 May 2006 18:43:31 -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 k4IMgCv1002567; Thu, 18 May 2006 15:42:12 -0700
Received: from fasolt.mtcc.com (adsl-216-102-208-10.dsl.snfc21.pacbell.net [216.102.208.10]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k4IMg7Ic002530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-dkim@mipassoc.org>; Thu, 18 May 2006 15:42:08 -0700
DKIM-Signature: a=rsa-sha1; q=dns; l=5434; t=1147992092; x=1148856092; c=relaxed/simple; s=dicks.drop.kirkwood; h=From:Subject:Content-Type:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:Michael=20Thomas=20<mike@mtcc.com> |Subject: |Sender: |To:Eric=20Allman=20<eric@neophilic.com> |Cc:Douglas=20Otis=20<dotis@mail-abuse.org>, =20=0A=20Mark=20Delany=20<MarkD+ dkim@yahoo-inc.com>,=0A=20=20ietf-dkim@mipassoc.org |Subject:Re=3A=20[ietf-dkim]=20Today's=20jabber=20#1271=3A=20Binary=20algorithms= 20and=09algorithm=0A=20spoofing=20during=20a=20transition. |Content-Type:text/plain=3B=20charset=3DISO-8859-1=3B=20format=3Dflowed |Content-Transfer-Encoding:7bit |MIME-Version:1.0; X=v=3Dcisco.com=3B=20h=3DqXjYbxEMgdwYzDkjOUV3f8qinwQ=3D; b=iA0kGO1O2+QxzNUD0AtV7UL3cdKFWi/dmkZbuNMjS8C/Bak36luhBNCYKko66ODPLkB1el4K VT2yM55bfC1D5wcR2BItBcYdTGrAQZ4t7PLArVTcaHtEPdcgNxKJ3p6S;
Received: from [216.102.208.10] (IDENT:U2FsdGVkX1+BSkecsa7YJbO0g39L5Ib4E/x9V3mYoNo@fasolt.mtcc.com [216.102.208.10] (may be forged)) (authenticated bits=0) by fasolt.mtcc.com (8.13.1/8.13.1) with ESMTP id k4IMfWIW020977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 May 2006 15:41:32 -0700
Message-ID: <446CF81B.6090205@mtcc.com>
Date: Thu, 18 May 2006 15:41:31 -0700
From: Michael Thomas <mike@mtcc.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050720 Thunderbird/1.0.6 Fedora/1.0.6-1.1.fc3 Mnenhy/0.7.2.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Eric Allman <eric@neophilic.com>
Subject: Re: [ietf-dkim] Today's jabber #1271: Binary algorithms and algorithm spoofing during a transition.
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> <FE049B4F1BD1834142A9EFA3@rieux.local>
In-Reply-To: <FE049B4F1BD1834142A9EFA3@rieux.local>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Authentication-Results: fasolt.mtcc.com; header.From=mike@mtcc.com; dkim=pass ( sig from mtcc.com verified; );
X-XIPE-SCORES: dispose=pass; ACD=1.00; CLAM=0.00; COMPLY=0.00; URL=0.00; SA=0.00; HONEY=0.00;
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: 7e439b86d3292ef5adf93b694a43a576
Right. I definitely don't want to have to deal with the union of encodings in any given resource record. Yuck. Mike Eric Allman wrote: > 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 _______________________________________________ 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