Subject: [ietf-dkim] weekly jabbering?

From: Stephen Farrell <[email-masked]>
Date: Sat, 20 May 2006 22:23:29 +0100

Arguing that it seems like a good way to more quickly close out
issues that have been raised on the list, a couple of people have
asked that we try have weekly jabber sessions between now and
whenever we get base into WG last call.

I guess were we to go ahead with this, we'd stick to the same
1500 UTC, Thursday timeslot, starting next Thursday or the
following.

Thoughts?
Stephen.

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: John Levine <[email-masked]>
Date: 21 May 2006 02:22:00 -0000

>whenever we get base into WG last call.

Let's try it for two weeks, then decide whether it's worth it.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"More Wiener schnitzel, please", said Tom, revealingly.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave Crocker <[email-masked]>
Date: Sat, 20 May 2006 20:06:35 -0700

> Let's try it for two weeks, then decide whether it's worth it.

+1

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Jim Fenton <[email-masked]>
Date: Sun, 21 May 2006 16:32:26 -0700

> 1500 UTC, Thursday timeslot, starting next Thursday or the
I'm one of the "couple of people", so (obviously) I think this is a
great idea.

-Jim

---

From: Michael Thomas <[email-masked]>
Date: Sun, 21 May 2006 19:02:50 -0700

Jim Fenton wrote:

>I'm one of the "couple of people"
>

+1

>, so (obviously) I think this is a great idea.
>  
>
+1

= +2? :)

       Mike

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 22 May 2006 23:28:54 +0100

So 4:0 for trying this for a few weeks. Barring a change in
that I guess we should go for it, starting this Thursday
at 1500 UTC (1600 Dublin, 1100 New York etc.) for 90 minutes.

Agenda is a continuation of issue processing. Will try to
update list beforehand.

Stephen.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 22 May 2006 16:25:52 -0700

> Agenda is a continuation of issue processing. Will try to

It could be helpful for details related to the algorithm's  
representation in the binary key be posted for review.  Resolving the  
method of representation should allay some possible concerns.

The review of a strategy for using a key deprecation flag should also  
be possible.  Once there is an assured method to confirm an unknown  
algorithm is currently offered by a signing domain, detecting removal  
of a non-deprecated signature during a transition is possible.  A  
signed message must contain at least one non-deprecated signature  
where the algorithm, even though unsupported by the verifier, must  
still be confirmed as supported by the signing domain in the  
referenced key.  Without such a strategy, an opportunity to exploit a  
deprecated algorithm continues over the entire duration for a  
complete transition to occur, even in cases where both the signing  
and the verifying domains supported a newer non-exploited algorithm.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 23 May 2006 07:49:04 +0100

Doug,

Douglas Otis wrote:

> The review of a strategy for using a key deprecation flag should also be 
> possible.  Once there is an assured method to confirm an unknown 
> algorithm is currently offered by a signing domain, detecting removal of 
> a non-deprecated signature during a transition is possible.  A signed 
> message must contain at least one non-deprecated signature where the 
> algorithm, even though unsupported by the verifier, must still be 
> confirmed as supported by the signing domain in the referenced key.  
> Without such a strategy, an opportunity to exploit a deprecated 
> algorithm continues over the entire duration for a complete transition 
> to occur, even in cases where both the signing and the verifying domains 
> supported a newer non-exploited algorithm.

If you have a new technical issue, then create a new thread as discussed
previously. If its already in Eliot's list, then reference the number.

Technical comment in a thread about jabbering will be missed later.

Stephen.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 23 May 2006 15:42:50 -0700

On May 22, 2006, at 4:25 PM, Douglas Otis wrote:
> representation in the binary key be posted for review.  Resolving  
> the method of representation should allay some possible concerns.
>
> The review of a strategy for using a key deprecation flag should  
> also be possible.  Once there is an assured method to confirm an  
> unknown algorithm is currently offered by a signing domain,  
> detecting removal of a non-deprecated signature during a transition  
> is possible.  A signed message must contain at least one non- 
> deprecated signature where the algorithm, even though unsupported  
> by the verifier, must still be confirmed as supported by the  
> signing domain in the referenced key.  Without such a strategy, an  
> opportunity to exploit a deprecated algorithm continues over the  
> entire duration for a complete transition to occur, even in cases  
> where both the signing and the verifying domains supported a newer  
> non-exploited algorithm.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 24 May 2006 00:26:48 +0100

>> method of representation should allay some possible concerns.

That's too vague to handle. Suggest you raise whatever issues you
see whenever a binary format spec is published.

>> deprecated algorithm continues over the entire duration for a complete 
>> transition to occur, even in cases where both the signing and the 
>> verifying domains supported a newer non-exploited algorithm.

Does anyone else see this as a serious issue? On the last jabber [1]
I think it wasn't seen as such and 1184 & 1196 were marked for
closure/rejection (to be confirmed on the list of course).

S.

[1] http://www.ietf.org/meetings/ietf-logs/dkim/2006-05-18.html

---

From: Douglas Otis <[email-masked]>
Date: Tue, 23 May 2006 17:12:09 -0700

> see whenever a binary format spec is published.

There still should be a strategy defined in the base draft to ensure  
an unknown algorithm can be confirmed.

This requires consensus on whether:

  - A binary assertion of an algorithm can be made in the future.
  - A list of query mechanisms can return keys expressing the  
algorithm in different formats.

>>> detecting removal of a non-deprecated signature during a  
>>> transition is possible.  A signed message must contain at least  
>>> one non-deprecated signature where the algorithm, even though  
>>> unsupported by the verifier, must still be confirmed as supported  
>>> by the signing domain in the referenced key.  Without such a  
>>> strategy, an opportunity to exploit a deprecated algorithm  
>>> continues over the entire duration for a complete transition to  
>>> occur, even in cases where both the signing and the verifying  
>>> domains supported a newer non-exploited algorithm.
>

Without a strategy devised within the base draft, if there is a  
weakness discovered, an exploit can not be fully prevented until it  
becomes practical not to use an algorithm that might be the subject  
of some exploit.

With a relatively simple deprecation flag, and a requirement that a  
message must include a non-deprecated signature from the signing  
domain, once both the signing and verifying domain upgrade, inclusion  
of a deprecated signature will not introduce an additional risk.   
This is a genuine security concern, as email does not offer a means  
to negotiate and a transition period may take years, hence offering a  
deprecated signature must not permit an exploit beyond where both  
signing and verifying domains handle the non-deprecated signature.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Tue, 23 May 2006 19:16:32 -0700

On May 23, 2006, at 5:46 PM, Paul Hoffman wrote:

> At 5:12 PM -0700 5/23/06, Douglas Otis wrote:
>> There still should be a strategy defined in the base draft to  
>> ensure an unknown algorithm can be confirmed.
>
> Could you define "confirmed"?

An unknown algorithm noted within the signature must be confirmed as  
being the _same_ algorithm used in the associated key offered by the  
signing domain, or a bad actor could introduce any algorithm to  
exploit a deprecated signature.  Without an ensured means to always  
make this confirmation in the base draft, an inability to compare an  
algorithm indicated in the signature might be viewed as the  
introduction of a new method of representation.  In other words,  
going from an mnemonic to numeric either must be excluded between  
query methods per the base draft, or specify a list of algorithm  
representations (mnemonic, numeric), in addition to query methods.

>> weakness discovered, an exploit can not be fully prevented until  
>> it becomes practical not to use an algorithm that might be the  
>> subject of some exploit.
>
> Of course. So?

The window of opportunity would rapidly close as major players  
upgraded their servers, only when there is an ability to ensure a  
deprecated signature could not be exploited in the case where both  
the signing and verifying domains now handle the non-deprecated  
signature.  Without being able to exclude the deprecated signature in  
this case, the window of the exploit continues until it becomes  
practical to not offer the deprecated signature.  With an ability to  
exclude the use of deprecated signatures, the difference in the  
threat window for a majority of recipients could be measured in  
weeks, instead of months or years.

>> With a relatively simple deprecation flag, and a requirement that  
>> a message must include a non-deprecated signature from the signing  
>> domain, once both the signing and verifying domain upgrade,  
>> inclusion of a deprecated signature will not introduce an  
>> additional risk.
>
> It doesn't anyway: the verifier simply doesn't use the signature  
> that uses the now-bad algorithm.

A verifier may not have been upgraded to handle a new, more secure  
algorithm.  There is no means to negotiate algorithms, which will  
likely mean multiple signatures (deprecated/non-deprecated) will be  
needed for some (perhaps extended) period of time.  Even an abrupt  
transition in algorithms may permit an exploit where a bad actor  
offers an unknown algorithm purportedly from some domain.  To prevent  
this type of spoofed algorithm exploit, there MUST be an iron-clad  
method available to confirm the sending domain actually offers a key  
using the algorithm indicated within the signature.  With that  
absolutely essential confirmation ability, adding a deprecated key  
flag then also allows a safe multi-signature transition, where an  
exploit of a weaker algorithm can be curtailed as soon as possible.

>> This is a genuine security concern, as email does not offer a  
>> means to negotiate and a transition period may take years, hence  
>> offering a deprecated signature must not permit an exploit beyond  
>> where both signing and verifying domains handle the non-deprecated  
>> signature.
>
> How is the DKIM case any different than in S/MIME and OpenPGP? Or  
> are you claiming that they too need to be fixed with your "simple  
> deprecation flag" as well? The value of DKIM signatures is orders  
> of magnitude less than the value of these other signature formats,  
> and yet those IETF WGs (which have been around for a decade) have  
> not found a need to solve this "genuine security concern".

Both S/MIME and OpenPGP exist at different places in the channel.   
DKIM is designed to work in conjunction with the MTA.  Unlike these  
protocols, DKIM is better positioned to achieve a higher level of  
deployment.  With DKIM perhaps soon providing protection from now  
common and highly criminal activity, it would be reasonable to expect  
significant resources will be arrayed against this DKIM scheme.   
DKIM's survival from an initial setback may largely depend upon a  
strategy that permits a smooth and safe transition when reacting to  
such a possible setback.  Ensuring the confirmation of the key  
algorithm, and a means to mark a key deprecated does not seem  
unreasonable.  Just the opposite.

-Doug

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 23 May 2006 17:46:41 -0700

Of course. So?

>inclusion of a deprecated signature will not introduce an additional 
>risk.

It doesn't anyway: the verifier simply doesn't use the signature that 
uses the now-bad algorithm.

>to negotiate and a transition period may take years, hence offering 
>a deprecated signature must not permit an exploit beyond where both 

How is the DKIM case any different than in S/MIME and OpenPGP? Or are 
you claiming that they too need to be fixed with your "simple 
deprectation flag" as well? The value of DKIM signatures is orders of 
magnitude less than the value of these other signature formats, and 
yet those IETF WGs (which have been around for a decade) have not 
found a need to solve this "genuine security concern".

At 12:26 AM +0100 5/24/06, Stephen Farrell wrote:
>Does anyone else see this as a serious issue?

Not I.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 24 May 2006 09:48:52 +0100

Doug,

I've read your mails on this and the more I read the less I've
an idea what you're on about.

Please consider those issues (1184 and 1196) closed. We'll get to
consider 1271 when we get there (maybe tomorrow, maybe a bit later).

Stephen.