Subject: [ietf-dkim] Today's jabber in about 30 minutes...

From: Stephen Farrell <[email-masked]>
Date: Thu, 18 May 2006 15:34:24 +0100

Agenda:

1. Agenda bashing (1 minute)
2. Review the open issues listed in Eric's email [1] (40-50 minutes)
3. AOB (5 minutes)

[1] http://mipassoc.org/pipermail/ietf-dkim/2006q2/003640.html

See the attachment for our modus operandi (almost the same as last
time fwiw).

Cheers,
Stephen.

0. Formally the NOTE WELL, applies and will be quoted when the meeting is
brought to order by the chairs, otherwise the rules for a face-to-face apply
perhaps modified a bit by the rules for a design team meeting. That'll be
worked out in the fullness of time. This is an experiment aimed at resolving
technical issues, bring any process issues or othter formalities up on the
mailing list and/or the IETF discuss list later.

1. Be patient, polite and give the "floor" to others, just as you would were
you a face-to-face meeting.

2. Say your name into the microphone - in this case that means minimally making
sure we can determine your email address in case we need to correlate some mail
with the jabber logs. Be aware that not all jabber clients cause a  useful name
to appear in the logs.

3. Defer to the chairs, so they can run this as a meeting. If the chairs start
typing, maybe everyone else stop till they're done if they so ask.

4. Make it clear when you're finished a statement, use EOM or something if
necesary, since it might not be clear to all (incl. non-native English
speakers) that you're finished.

5. If the chairs ask for a "hum" say "hum" if you agree, anything intepreted by
the chairs as being positive (yes, yep, yippee, ganz gnau) will count as a hum.

6. It has happened at some face to face meetings that there were too many
people in the room. In that case the chairs might ask for volunteers to leave
and follow the meeting via the logs. (Too much of that and the chairs should
abandon ship.) We should be ok though, I believe the limit's 250.

7. The meeting ends when the agenda items are completed. The chairs declare
which agenda item is being discussed. The chairs may ask for any other business
at the end, or they may not, if time doesn't allow.  The meeting is over when
the chairs declare it over, even if that's early. Participants may of course
continue to chat afterwards.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Tony Hansen <[email-masked]>
Date: Thu, 18 May 2006 12:31:43 -0400

One of the topics from today's jabber session was how to handle DNS
queries with the advent of a DNS RR record in the future. Do we keep the
TXT references in the current document? Do we make references to the DNS
RR record? Do we define in base how to cascade from RR to TXT? It all
boils down to the question of "what does q=dns" mean.

My suggestion in the jabber session was:

   1)	making q=dns mean *only* a DNS TXT lookup,
   2)	define that lookup within base
   3)	when the DNS RR draft comes out, it would also define a new q=
	value, something like dnsrr, that says to do a lookup using new
	DNS RR record.
   4)	given that q= can take a list, the question of handling both RR
	and TXT records could be denoted by using q=dnsrr,dns, rather
	than saying that q=dnsrr should search both.

Specific suggested wording changes from -01 follow.

	Tony Hansen
	[email-masked]

Section 3.5:

OLD: q= A colon-separated list of query methods used to retrieve the
OLD:	public key (plain-text; OPTIONAL, default is "dns").  Each
OLD:	query method is of the form "type[/options]", where the syntax
OLD:	and semantics of the options depends on the type.  If there are
OLD:	multiple query mechanisms listed, the choice of query mechanism
OLD:	MUST NOT change the interpretation of the signature.  Currently
OLD:	the only valid value iis "dns" which defines the DNS lookup
OLD:	algorithm described elsewhere in this document.  No options are
OLD:	defined for the "dns" query type, but the string "dns" MAY have
OLD:	a trailing "/" character.  Verifiers and signers MUST support
OLD:	"dns".
OLD:
OLD:	INFORMATIVE RATIONALE:  Explicitly allowing a trailing "/" on
OLD:	   "dns" allows for the possibility of adding options later and
OLD:	   makes it clear that matching of the query type must terminate
OLD:	   on either "/" or end of string.

NEW: q= A colon-separated list of query methods used to retrieve the
NEW:	public key (plain-text; OPTIONAL, default is "dns").  Each query
NEW:	method is of the form "type[/options]", where the syntax and
NEW:	semantics of the options depends on the type.  If there are
NEW:	multiple query mechanisms listed, the choice of query mechanism
NEW:	MUST NOT change the interpretation of the signature. An
NEW:	implementation MUST use the recognized query mechanisms in the
NEW:	order presented.
NEW:	
NEW:	Currently the only valid value is "dns" which defines the DNS
NEW:	lookup algorithm described elsewhere in this document.

Section 3.6:
OLD:	This document defines a single binding, using DNS to distribute
OLD:	the keys.

NEW:	This document defines a single binding, q=dns, that uses DNS TXT
NEW:	records to distribute the keys. Other bindings may be defined in
NEW:	the future.

Section 3.6.2:

OLD:	3.6.2  DNS binding
OLD:	A binding using DNS as a key service is hereby defined.  All
OLD:	implementations MUST support this binding.

NEW:	3.6.2  DNS Binding for q=dns
NEW:	
NEW:	A binding using DNS TXT records as a key service is hereby
NEW:	defined, q=dns. All implementations MUST support this binding.
NEW:
NEW:	No options are defined for the "dns" query type, but the string
NEW:	"dns" MAY have a trailing "/" character.  Verifiers and signers
NEW:	MUST support "dns".
NEW:	
NEW:	   INFORMATIVE RATIONALE:  Explicitly allowing a trailing "/" on
NEW:	   "dns" allows for the possibility of adding options later and
NEW:	   makes it clear that matching of the query type must terminate
NEW:	   on either "/" or end of string.

Section 3.6.2.1:

OLD:	3.6.2.1  Name Space
NEW:	3.6.2.1  Name Space for q=dns

Section 3.6.2.2:

OLD:	3.6.2.2  Resource Record Types for Key Storage
OLD:
OLD:	[[This section needs to be fleshed out.  ACTUALLY:  will be
OLD:	addressed in another document.]]
OLD:	
OLD:	Two RR types are used:  DKK and TXT.
OLD:	
OLD:	The DKK RR is expected to be a non-text, binary representation
OLD:	intended to allow the largest possible keys to be represented
OLD:	and transmitted in a UDP DNS packet.  Details of this RR are
OLD:	described in [ID-DKIM-RR].
OLD:	
OLD:	TXT records are encoded as described in Section 3.6.1.
OLD:	
OLD:	Verifiers SHOULD search for a DKK RR first, if possible,
OLD:	followed by a TXT RR.  If the verifier is unable to search for a
OLD:	DKK RR or a DKK RR is not found, the verifier MUST search for a
OLD:	TXT RR.

NEW:	3.6.2.2  q=dns Resource Record Types for Key Storage
NEW:
NEW:	q=dns uses the TXT DNS RR type. The TXT records are encoded as
NEW:	described in Section 3.6.1.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Mark Delany <[email-masked]>
Date: Thu, 18 May 2006 17:38:59 +0000

> 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?

I guess by way of example. The MX RR only defines the contents and not
the semantics, so perhaps DKK and TXT should do similar with the
semantics defined in the base?

Mark.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 18 May 2006 10:51:59 -0700

> semantics defined in the base?

exactly. nicely distinguishes semantics from method.

d/

-- 

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

---

From: Eric Allman <[email-masked]>
Date: Thu, 18 May 2006 10:57:11 -0700

Tony, as it turns out I had already edited in some changes --- I'll 
check to make sure they are consistent with what you propose.

One change I made (tentatively) is to use the "options" part to 
indicate the record type --- so base defines "dns/txt" only, with a 
mention that we expect a "dns/dkk" type to appear later.

All: any thoughts on whether this is a good idea?

eric

--On May 18, 2006 12:31:43 PM -0400 Tony Hansen <[email-masked]> wrote:

> queries with the advent of a DNS RR record in the future. Do we
> keep the TXT references in the current document? Do we make
> references to the DNS RR record? Do we define in base how to
> cascade from RR to TXT? It all boils down to the question of "what
> does q=dns" mean.
>
>    4)	given that q= can take a list, the question of handling both
> RR 	and TXT records could be denoted by using q=dnsrr,dns, rather

---

From: Michael Thomas <[email-masked]>
Date: Thu, 18 May 2006 11:24:57 -0700

That's consistent with what I thought was going to happen where q=dns 
defaults
to q=dns/txt;

       Mike

---

From: Tony Hansen <[email-masked]>
Date: Thu, 18 May 2006 14:30:57 -0400

Base section 3.5 currently defines both a set of values expected to be
found by any query mechanism, and a representation of the values when
provided by any textually-formatted query mechanism. The discussion of
q=dns then constrains itself to using the textual format within the TXT
RR record.

Perhaps section 3.5 should be rewritten to make that separation more
explicit:

	3.5.1 name/value pairs returned by any query mechanism
	3.5.2 a textual-format for representing those values

If this were done, I would have no problem with punting the semantics of
the DKK name/value pairs to section 3.5.1. And then the DKK draft would
define exactly two things:

   *	the q= parameter name and/or options
   *	the syntax of the record

This also provides a basic template for any future query mechanisms.

	Tony Hansen
	[email-masked]

---

From: Tony Hansen <[email-masked]>
Date: Thu, 18 May 2006 14:35:25 -0400

Oops, that should have been section 3.6.1, not 3.5 referenced below, and
correspondingly 3.6.1.1 and 3.6.1.2 in my example.

	Tony

---

From: Tony Hansen <[email-masked]>
Date: Thu, 18 May 2006 14:39:59 -0400

I can live with this. But we might want to call the /foo something other
than an option.

Right now section 3.6.1 says:

   q=	... where the syntax and semantics of the options depends on the
	type.

Instead it would need to be:

   q=	... where the syntax and semantics of the options depends on the
	type and specified options.

Tony

Eric Allman wrote:
> One change I made (tentatively) is to use the "options" part to indicate
> the record type --- so base defines "dns/txt" only, with a mention that
> we expect a "dns/dkk" type to appear later.
>

---

From: Michael Thomas <[email-masked]>
Date: Thu, 18 May 2006 11:53:16 -0700

>This also provides a basic template for any future query mechanisms.
Doesn't that presuppose that q= defines just isomorphic semantics with
different transport and/or encoding? Is that really what we want? I'm sort
of thinking that if we in the future wanted to extend dkim, would we always
want, say, TXT to have to be extended too? And especially in some far future
where we wanted bigger records and decided that TCP/not-DNS was a more
appropriate transport?

       Mike

---

From: Michael Thomas <[email-masked]>
Date: Thu, 18 May 2006 11:55:51 -0700

>the TXT and DKK simply be particular representations?
Is there really any reason to force one to be the master of the other? 
What would
that even mean for a receiver? I sort of thought of the 
q=dns/dkk:dns/txt as first
to try order, and that both would at least get you a baseline of the 
same information
as needed in -base.

       Mike

---

From: "william(at)elan.net" <[email-masked]>
Date: Thu, 18 May 2006 12:04:27 -0700 (PDT)

> 	than saying that q=dnsrr should search both.

Please do. Though it would be good if authors listen to suggestions so
the same ones dont have to be brought up year later...

http://www.imc.org/ietf-mailsig/mail-archive/msg01279.html

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Thu, 18 May 2006 12:14:14 -0700

On May 18, 2006, at 10:38 AM, Mark Delany wrote:

> 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?

There could be two drafts, one for the TXT RR and the other for DKK  
RR.  If presented at the same time as the base-draft, these two  
drafts might also be merged.  It seems the base draft will need to  
resolve these issues in tandem anyway.

> I guess by way of example. The MX RR only defines the contents and  
> not the semantics, so perhaps DKK and TXT should do similar with  
> the semantics defined in the base?

One reason for reviewing these two records together would be concerns  
regarding an algorithm transition.  The manner the algorithm is  
represented within the key could be problematic.  If this  
representation is different than the manner used on the TXT record,  
then offering fictitious signatures claiming a new, but fictitious,  
algorithm not supported by the verifier would be an easy exploit  
owing to an inability to confirm what the sender is offering.  The  
verifier would accept the deprecated signature in the belief the  
sender offered a non-deprecated signature together with the  
deprecated, but that it is using an algorithm unknown to the verifier.

-Doug

---

From: Eric Allman <[email-masked]>
Date: Thu, 18 May 2006 12:14:26 -0700

>    q=	... where the syntax and semantics of the options depends on
> the 	type.
>
>    q=	... where the syntax and semantics of the options depends on
> the 	type and specified options.

I guess that's one I thought was too obvious to say, but I'm happy to 
put it in.

eric

---

From: Mark Delany <[email-masked]>
Date: Thu, 18 May 2006 19:25:25 +0000

> 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.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 18 May 2006 12:46:02 -0700

Ah, I understand. Seems to me that we should have TXT in -base as now, 
and just
reference the appropriate sections of -base for the semantics of the 
TLV's in DKK.
Also:  subsequent revisions could choose to extend TXT, DKK or both as 
needed.

       Mike

---

From: Eric Allman <[email-masked]>
Date: Thu, 18 May 2006 12:46:51 -0700

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.

eric

--On May 18, 2006 7:25:25 PM +0000 Mark Delany 
<[email-masked]> wrote:

> 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.

---

From: John Levine <[email-masked]>
Date: 18 May 2006 19:43:55 -0000

>NEW:	If there are

I can live with either of these sentences, but they don't make sense
togther.  If all of the mechanisms will give you the same answer, why
shouldn't I be allowed to send out all the queries at once and take
the one the comes back first?  Or if new ones are supersets of old
ones, prefer the more informative one?

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Thu, 18 May 2006 12:57:49 -0700

>ones, prefer the more informative one?

Right, I think the first sentence is a little bit suspect. We may 
eventually want to
make TXT, say, historic such that it still works in the way that -base 
expected it
to work, but with new extensions for DKK that may well change the 
interpretation
such as giving finer grained ways to assess the signature, etc.

       Mike

---

From: Douglas Otis <[email-masked]>
Date: Thu, 18 May 2006 13:33:17 -0700

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.
>
> 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:
>
> NOTE WELL: This list operates according to http://mipassoc.org/dkim/ 
> ietf-list-rules.html

---

From: Eric Allman <[email-masked]>
Date: Thu, 18 May 2006 13:59:46 -0700

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 
<[email-masked]> wrote:

>> 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.
>>
>>  disaster and after losing at least a year of time they went back
>> to   using C as the definition language.]
>>
>> 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...
>
> ,---
>>>> > So I've circulated the draft DKK to a couple of people to get
>>>> > the roughest edges off.
>>>> >
>>> 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.
>> http://mipassoc.org/dkim/  ietf-list-rules.html
>
>

---

From: "william(at)elan.net" <[email-masked]>
Date: Thu, 18 May 2006 14:09:02 -0700 (PDT)

> ones, prefer the more informative one?

All mechanisms must allow you to actually verify the signature crypto,
but I think the point is that it might not give you the same answer if
one of the mechanisms is more advanced. What would be expected is
that those systems that are using newer versions of software will
know how to use these new mechanisms whilte older systems will just
ignore them and use the ones they know about. As to doing queries
in parallel - if you know two mechanisms give you the same answer
(i.e. one is not more advanced or its advanced features are not
used by particular implimentation), then sure, go ahead.

---

From: Tony Hansen <[email-masked]>
Date: Thu, 18 May 2006 17:56:43 -0400

agreed. Is this better?

NEW:    If there are
NEW:    multiple query mechanisms listed, the choice of query mechanism
NEW:    MUST NOT change the interpretation of the signature. An
NEW:    implementation MAY use recognized query mechanisms in any
NEW:    order.

	Tony Hansen
	[email-masked]

---

From: Michael Thomas <[email-masked]>
Date: Thu, 18 May 2006 15:41:31 -0700

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:

> --On May 18, 2006 1:33:17 PM -0700 Douglas Otis <[email-masked]> 
> wrote:
>
>>

---

From: Douglas Otis <[email-masked]>
Date: Thu, 18 May 2006 15:42:10 -0700

On May 18, 2006, at 1:59 PM, 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.

The critical aspect of the algorithm representation is to ensure  
there is no opportunity for exploitation during a subsequent  
algorithm transition.  Semantics must allow a verifier a method to  
confirm that the signer has offered a key with an unknown algorithm  
that matches the DKIM signature header field with an unknown  
algorithm.  Key algorithm representation == Signature algorithm  
representation.

When the query method indicates q=x, y; there could be conflicts  
where one algorithm's representation in the key is a number, and  
where the other method's representation within the key is a  
mnemonic.  Unknown mnemonic representations can not be mapped to a  
number.

One solution could have future algorithms represented as a number to  
avoid possible conflicts between mnemonic and number representations  
of algorithms.  An exception can be made where known mnemonics can be  
mapped to known numbers.

Of course, the binary key could use a mnemonic to represent the  
algorithm.  This added overhead may reduce how well this key extends  
for other uses, or might be less compliant with other protocols where  
numeric representations for the algorithm are common.  : (

> 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.

The base draft could be explicit and use the q= dns, dnsrr with  
definitions then referencing other drafts for full dependence.  This  
would simplify future updates where when perhaps just the TXT draft  
is obsoleted there is little affect on the base draft, for example.

Not fully sharing your concern, better independence is achieved where  
a token is used as a placeholder such as 1*(query-method-designator).

query-method-designator: see rfc-xxxx and rfc-xxxx.

The TXT draft could become a common template for the binary RR and  
other future drafts.  An abstraction is not required, although it  
should not be difficult to understand.  A place holder seems cleaner  
and would help keep straight which tags are contained in the  
signature and which are in the key.

If the base-draft stays the same, then the issue of algorithm  
representation still needs to be resolved for the TXT and future  
mechanisms.

Is there to be only one query mechanism per algorithm representation?

If all algorithms have a common representation, should this be  
numeric or mnemonic?

Perhaps a=x,y; q=j,k;  where algorithm x goes with query method j,  
and y goes with k.  There are many ways this can be resolved.

> 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.

This mapping must allow for unknown algorithms.  It is not a simple  
matter unless semantics provide a consistent means to confirm what  
algorithm has been offered by the signer, or the transition period  
allows undetected removal of the non-deprecated signature  
algorithms.  A bad actor could simply invent algorithms when pointing  
to a new key, where the verifier is unable to confirm the algorithm  
within the key does not match the algorithm found in the DKIM  
signature header field.  Ensuring this confirmation is always  
possible, thwarts any attempt at a spoofing the offered algorithm.   
This spoof could be detected prior to the verifier being updated and  
seems simple to achieve.

Although splitting the draft seems cleaner, retaining the TXT record  
within the base still needs the minor detail of algorithm  
representation sorted out.  Tagging keys as deprecated should also be  
defined, but this has a lesser impact on future semantic compatibility.

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Thu, 18 May 2006 15:39:09 -0700

>NEW:    implementation MAY use recognized query mechanisms in any

I think this is just opposite of my preference:

NEW: An implementation MUST use the recognized query mechanisms in the
NEW: order presented.

This would allow for upgraded behavior while preserving backward 
compatability.

       Mike

---

From: Douglas Otis <[email-masked]>
Date: Thu, 18 May 2006 15:52:33 -0700

> This would allow for upgraded behavior while preserving backward  

Why make this a must when the initial order can not be confirmed by  
the verifier?

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Thu, 18 May 2006 15:55:47 -0700

> Why make this a must when the initial order can not be confirmed by  

This is ridiculous. Of course it can be confirmed by the receiver if the 
signature
verifies.

       Mike

---

From: Douglas Otis <[email-masked]>
Date: Thu, 18 May 2006 16:04:09 -0700

On May 18, 2006, at 3:55 PM, Michael Thomas wrote:

>> Why make this a must when the initial order can not be confirmed  
>> by  the verifier?
>
> This is ridiculous. Of course it can be confirmed by the receiver  
> if the signature
> verifies.

Sorry, my mistake.  I was still thinking about multiple signatures.

-Doug

---

From: John Levine <[email-masked]>
Date: 19 May 2006 02:46:30 -0000

>>NEW:    If there are multiple query mechanisms listed, the choice of
>>NEW:	  query mechanism MUST NOT change the interpretation of the
>>NEW:	  signature. Animplementation MAY use recognized query mechanisms
>>NEW:	  in any order.

>This would allow for upgraded behavior while preserving backward 

Remember, senders can't force recipients to do anything, and the
implicit assumption that the sender knows better than the recipient
how to handle the queries seems to me utterly unwarranted.

A recipient will know how to handle some set of mechanisms, and I
expect that they will have an opinion about which ones they prefer
because they're faster, cheaper, more informative, or whatever.  If
there's more than one mechanism available for a particular signature,
a recipient will use the one it likes best, and even if a sender says
"hey, use this other one, it's really great", there's no benefit for
recipients to pay any attention, so they won't.

The only rule that's going to get implemented is that receivers can
use any mechanism that's available, and it's a waste of effort to
attempt to mandate anything else.  This will work fine for transitions
since senders do have the control of which mechanisms they offer, so
they can offer both for a while and eventually ditch the old one.

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Thu, 18 May 2006 19:50:59 -0700

>they can offer both for a while and eventually ditch the old one.
I'm fine with this being a SHOULD , fwiw. I was just repeating the original
text that Tony proposed. The key here is that the receiver should know that
the sender prefers one over the other, and hence that's it's an ordered 
list. A
receiver is always at liberty to feign igornance.

       Mike

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 18 May 2006 20:42:28 -0700

At 7:50 PM -0700 5/18/06, Michael Thomas wrote:
>the sender prefers one over the other, and hence that's it's an 
>ordered list. A

I don't see the interoperability or security issue that would make 
this a SHOULD. The order given shows the signer's preference; the 
verifier MAY do whatever it wants.

...which goes to show why having two different formats to say the 
same thing is inherently flawed.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Fri, 19 May 2006 08:43:16 -0700

> verifier MAY do whatever it wants.

This seems to match up with the semantics of SHOULD if you ask me: the 
receiver
should honor the senders wishes unless it has some overriding reason why 
it doesn't
want to do that.

> ...which goes to show why having two different formats to say the same 
> thing is inherently flawed.

That assumes that the two are now and evermore identical. I don't think 
that's
a very good assumption, which is why SHOULD above makes sense.

       Mike

---

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 19 May 2006 09:10:08 -0700 (PDT)

> NEW:    implementation MAY use recognized query mechanisms in any

No. My view is that interpretation of the signature might actually change
if more advanced data is available. Its only base check as to if the
signature data verifies or not that would not change.

As a crude example, one mechanism might provide you with list of valid
sites that are allowed to verify the signature (i.e. sites that are
expected to receive the messages sent) and the other mechanism does 
not have this strange feature. Now using either of the mechanisms you
can tell if the signature data actually verified (i.e. find public key
as per current system), but according to the first mechanisms you must 
consider signature to not have been valid if receiving end is not listed 
i.e. its different interpretation. Now the software that does not want
to support these extra features might choose to still support its syntax 
record but only use it in case its the only mechanism listed as supported
because first mechanism provides records that are generally too large.

Also here different example where data is not the same at all but
interpretation would be. Lets suppose that signature includes public key 
in its header field's optional tags and one of the mechanisms allows to 
get the public key as usual per DK (then you will simply verify that key 
you have in the signature is exactly the same as key you retrieved) where 
as another mechanisms provides fingerprint of the same key. If we assume
that all other data provided by both mechanisms is the same then the 
interpretation would also be the same - so in theory the implementations 
system may choose to retrieve both public key and fingerprint (which does
not make much sense to me to) but the signer could prefer to see them 
retrieve smaller data from fingerprint and as such would list this mechanism
first. On the other hand there may be software that will purposely not try 
fingerprint (unless its the only record) for whatever reasons.

So the choice of what mechanism to use and in which order to try them is all
really up to the verifying software and depends on the list of mechanisms 
and features in those mechanisms that it wants to support. The signature 
may provide a preference in the eyes of the signature creator but I do not 
see that that preference going with anything better then SHOULD in the 
specification (and SHOULD is probably too strong).

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 19 May 2006 09:20:22 -0700

At 8:43 AM -0700 5/19/06, Michael Thomas wrote:
>This seems to match up with the semantics of SHOULD if you ask me: 
>the receiver
>should honor the senders wishes unless it has some overriding reason 
>why it doesn't
>want to do that.

 From RFC 2119:

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
    may exist valid reasons in particular circumstances to ignore a
    particular item, but the full implications must be understood and
    carefully weighed before choosing a different course.
. . .
    Imperatives of the type defined in this memo must be used with care
    and sparingly.  In particular, they MUST only be used where it is
    actually required for interoperation or to limit behavior which has
    potential for causing harm (e.g., limiting retransmisssions)  For
    example, they must not be used to try to impose a particular method
    on implementors where the method is not required for
    interoperability.

That rules out using SHOULD to enforce "senders wishes" unless there 
is an interop or limit behavior that cause harm. If the latter is an 
issue, the signer should not include a way for the verifier to cause 
harm.

>That assumes that the two are now and evermore identical. I don't think that's

Can you give an example of how you think the two might differ in light of:
    If there are
    multiple query mechanisms listed, the choice of query mechanism
    MUST NOT change the interpretation of the signature.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Fri, 19 May 2006 12:20:46 -0700

>    MUST NOT change the interpretation of the signature.

That point is under discussion. It is not decided.

       Mike

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 19 May 2006 20:36:39 +0100

> That point is under discussion. It is not decided.

Yes. In particular, if different mechanisms have different types of
support for key revocation, then you can get different answers
about the signature. Does that count as a change to the interpretation
of the signature or not? Regardless, I doubt that we can insist on
exactly the same outcome regardless of mechanism.

A simple example would be two X.509 based mechanisms, one based on
CRLs and one using OCSP. No matter how you set this up, there will
almost always be a time window where the OSCP response indicates
revocation before the CRL nextUpdate. So, even with intimately
related mechanisms like these, the outcomes can differ.

Stephen.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 19 May 2006 12:52:24 -0700

> exactly the same outcome regardless of mechanism.

Agreed.  Caveat signing domain, the verifier makes the choice.  The  
choice may be based upon best outcome and not order of listing.

-Doug

---

From: Eric Allman <[email-masked]>
Date: Fri, 19 May 2006 15:03:01 -0700

[I chose Paul's message to reply to more or less at random --- it's 
really a response to the thread.]

I'm leaning toward SHOULD, in part because of Paul's quoting of 2119:

> ...

Speaking pragmatically, there are a couple of reasons I can think of 
where the signer might prefer that verifier query in a particular 
order:

* One mechanism might scale better than another, for example, the 
signer might have a big honking http-based server (postulating for a 
moment a future http-based key query algorithm) and a measly little 
DNS server.

* A signer might be in the process of transitioning, and would like 
to measure how many verifiers really need the old mechanism.

* There might be some "information skew" between different sources 
--- for example, one is a cache which lags another source slightly.

* One might be a copy that the signer would prefer be used, but the 
signer is willing to have verifiers use the direct source if the copy 
is down.  In some sense this is the same argument as MX records with 
non-equal weights.

All that said, you can't force the verifier to do anything, hence 
MUST is inappropriate.  SHOULD feels right to me.

(And yes, I realize that the "skew" argument violates the principal 
that the sources should all be equivalent, but pragmatically it's not 
likely that the signer is going to implement a transaction-based 
store across multiple different technologies.  And besides, there's 
skew in DNS, so we can't escape it.)

eric

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 19 May 2006 23:49:51 +0100

Eric Allman wrote:
> (And yes, I realize that the "skew" argument violates the principal that 
> the sources should all be equivalent, but pragmatically it's not likely 
> that the signer is going to implement a transaction-based store across 
> multiple different technologies.  And besides, there's skew in DNS, so 
> we can't escape it.)

There are more issues than just skew. With xkms for example there
are some cases where it would be valid for a responder to return
a public key, even though that same key's certificate MUST be
considered invalid in X.509 terms. For example, if an intermediate
CA cert is revoked so that no path can be constructed, then a
conformant X.509 based source will not return the public key, whereas
an xkms source (or DNS source) can still allow the signature to be
accepted. While these are arguably corner cases, there are a lot
of them so assuming all sources always give the same answer may be
a bit optimistic.

Saying something along the lines that sources should almost always
be equivalent would however be safe enough I'd imagine, though one
could also argue that this is yet another BCP issue.

Stephen.

PS: For those interested in a bunch of similar possibilities:
http://down.dsg.cs.tcd.ie/misc/FarrellKahan-Final-cms.pdf