headers
Hector Santos | 1 Mar 2007 01:14

Re: 1365 yes/no

-1 == KEEP REQUIREMENT

Stephen Farrell wrote:
> 
> issue #1365 calls for eliminating requirement
> 6.3.2 which says:
> 
> "   [PROVISIONAL] The Protocol MUST be able to publish a Practice
>         which is indicative that domain doesn't send mail."
> 
> If you want to eliminate that requirement say: +1
> If you want to keep that requirement say: -1
> 
> Remember: wordsmithing is for later.
> 
> Stephen.
> 
> _______________________________________________
> NOTE WELL: This list operates according to 
> http://mipassoc.org/dkim/ietf-list-rules.html
> 
>
Permalink | Reply | 0 comments |
headers
Arvel Hathcock | 1 Mar 2007 01:25
Favicon

Re: Deployment Scenario 7: Cryptographic Upgrade and Downgrade Attacks

 > The problem is that UNLESS you have the ability to tell people that
 > your signing practices are transitional the policy language will be
 > insufficiently expressive to provide any value.

Seems to me signers will just sign with both algorithms for a period of 
time.  Regardless of what is expressed in policy, that can't help the 
sender know the level of deployment of a new verifier capable of 
handling the new algorithm.

Arvel
Permalink | Reply | 0 comments |
headers
Arvel Hathcock | 1 Mar 2007 01:31
Favicon

Re: Deployment Scenario 7: Cryptographic Upgrade and Downgrade Attacks

Mike, this is what I was trying to say in a previous post.  You are 
exactly right.  We have already faced this situation and it has proven 
itself in the field to work just fine.

Arvel

Michael Thomas wrote:
> I'm still not seeing what the problem is with things as they stand now.
> We've already been through a transition with sha1 and sha256. The
> solution was to make both signatures in the transition and set the
> h=sha1|sha256; in the selector. All you do when you're ready to
> completely transition is only sign with the new algorithm and set
> h=sha256; in the selector. This is exactly the kind of case we wanted
> to get right for -base and as far as I can tell it worked exactly as
> intended.
> 
> I'm honestly not trying to be obtuse here.
Permalink | Reply | 7 comments |
headers
Hallam-Baker, Phillip | 1 Mar 2007 01:37
Picon
Favicon

RE: Issue 1386 and downgrade attacks

We are not proposing infrastructure to deal with a catastrophic failure. Dave has again missed the point.

The purpose here is to allow an orderly transition to a new algorithm over the space of five years or more.

Without it no transition is practical and the only option would be to wait for the catastrophic failure.  

> -----Original Message-----
> From: Eric Allman [mailto:eric+dkim <at> sendmail.org] 
> Sent: Wednesday, February 28, 2007 4:29 PM
> To: Hallam-Baker, Phillip
> Cc: dcrocker <at> bbiw.net; IETF DKIM WG
> Subject: RE: [ietf-dkim] Issue 1386 and downgrade attacks
> 
> I'm not seeing Dave saying that at all.  So far as I can 
> tell, he and everyone else believes in gradual transitions 
> such as the one you cite.
> 
> I think he *is* saying that we have no experience with a 
> nightmare scenario where some basic algorithm such as RSA is 
> cracked --- not theoretically or in unlikely cases, such as 
> with SHA-1 --- but really really dead in the water cracked.  
> If we had to switch from 40-bit to 128-bit in a matter of a 
> couple of days it wouldn't go smoothly.  And I agree that 
> building in something to handle this sort of scenario almost 
> certainly isn't worth it.
> 
> eric
> 
> 
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hallam-Baker, Phillip | 1 Mar 2007 01:40
Picon
Favicon

RE: 1365 yes/no


> Subject: Re: [ietf-dkim] 1365 yes/no
> 
> 
> On Feb 28, 2007, at 2:23 PM, Stephen Farrell wrote:
> 
> >
> > issue #1365 calls for eliminating requirement
> > 6.3.2 which says:
> >
> > "   [PROVISIONAL] The Protocol MUST be able to publish a Practice
> >         which is indicative that domain doesn't send mail."
> >
> > If you want to eliminate that requirement say: +1 If you 
> want to keep 
> > that requirement say: -1

+1 its out of charter scope
Permalink | Reply | 3 comments |
headers
Arvel Hathcock | 1 Mar 2007 01:41
Favicon

Re: 1368 straw-poll : (was: Re: Deployment Non-Scenario 7: Cryptographic Upgrade and Downgrade Attacks)

 > This protection depends upon a means for the signer to assert which
 > algorithm is deprecated, and what shiny new algorithm is being
 > offered.

That doesn't follow at all.  The *receiver* will decide what algorithms 
are and are not sufficient and when to act on that decision.  And 
besides, the means by which a *sender* can assert which algorithm they 
like is to just stop signing with the one(s) they don't.  Whether and 
when to do that is a decision the sender will have to make.  I don't see 
how policy plays a role in any of this.

I'm starting to think that I'm completely missing something fundamental. 
  I might need some education in Prague if folk have time.

Arvel
Permalink | Reply | 1 comment |
headers
Scott Kitterman | 1 Mar 2007 01:44

Re: 1365 yes/no

On Wed, 28 Feb 2007 22:23:53 +0000 Stephen Farrell 
<stephen.farrell <at> cs.tcd.ie> wrote:
>
>issue #1365 calls for eliminating requirement
>6.3.2 which says:
>
>"   [PROVISIONAL] The Protocol MUST be able to publish a Practice
>         which is indicative that domain doesn't send mail."
>
I  want to eliminate that requirement: +1

Scott K
Permalink | Reply | 0 comments |
headers
Hallam-Baker, Phillip | 1 Mar 2007 01:49
Picon
Favicon

RE: Deployment Scenario 7: Cryptographic Upgrade andDowngrade Attacks

We all agree on the transition strategy here.

The question is purely what the policy is capable of expressing. If the transition strategy means that you
are always going to sign twice once with a key selector of each type then that is what the policy must be
capable of expressing.

> -----Original Message-----
> From: ietf-dkim-bounces <at> mipassoc.org 
> [mailto:ietf-dkim-bounces <at> mipassoc.org] On Behalf Of Arvel Hathcock
> Sent: Wednesday, February 28, 2007 7:31 PM
> To: ietf-dkim <at> mipassoc.org
> Subject: Re: [ietf-dkim] Deployment Scenario 7: Cryptographic 
> Upgrade andDowngrade Attacks
> 
> Mike, this is what I was trying to say in a previous post.  
> You are exactly right.  We have already faced this situation 
> and it has proven itself in the field to work just fine.
> 
> Arvel
> 
> Michael Thomas wrote:
> > I'm still not seeing what the problem is with things as 
> they stand now.
> > We've already been through a transition with sha1 and sha256. The 
> > solution was to make both signatures in the transition and set the 
> > h=sha1|sha256; in the selector. All you do when you're ready to 
> > completely transition is only sign with the new algorithm and set 
> > h=sha256; in the selector. This is exactly the kind of case 
> we wanted 
> > to get right for -base and as far as I can tell it worked
(Continue reading)

Permalink | Reply | 1 comment |
headers
Arvel Hathcock | 1 Mar 2007 02:03
Favicon

Re: 1365 yes/no

+1 - ditch this fluff.

I have had some sympathy for this in the past but now I have to ask: Are 
we creating "Sender *SIGNING* Practices" or "Sender Practices In 
General"?  Besides, there are already at least two other ways with more 
traction to achieve this particular goal.

Arvel

Stephen Farrell wrote:
> 
> issue #1365 calls for eliminating requirement
> 6.3.2 which says:
>  
> "   [PROVISIONAL] The Protocol MUST be able to publish a Practice
>         which is indicative that domain doesn't send mail."
> 
> If you want to eliminate that requirement say: +1
> If you want to keep that requirement say: -1
> 
> Remember: wordsmithing is for later.
Permalink | Reply | 0 comments |
headers
Michael Thomas | 1 Mar 2007 02:08
Favicon

Re: Deployment Scenario 7: Cryptographic Upgrade andDowngrade Attacks

Hallam-Baker, Phillip wrote:
> We all agree on the transition strategy here.
> 
> The question is purely what the policy is capable of expressing. If the transition strategy means that you
are always going to sign twice once with a key selector of each type then that is what the policy must be
capable of expressing.

So would a requirement that "the protocol must be capable of expressing 
everything it implements" satisfy you?

		Mike
> 
> 
> 
>> -----Original Message-----
>> From: ietf-dkim-bounces <at> mipassoc.org 
>> [mailto:ietf-dkim-bounces <at> mipassoc.org] On Behalf Of Arvel Hathcock
>> Sent: Wednesday, February 28, 2007 7:31 PM
>> To: ietf-dkim <at> mipassoc.org
>> Subject: Re: [ietf-dkim] Deployment Scenario 7: Cryptographic 
>> Upgrade andDowngrade Attacks
>>
>> Mike, this is what I was trying to say in a previous post.  
>> You are exactly right.  We have already faced this situation 
>> and it has proven itself in the field to work just fine.
>>
>> Arvel
>>
>> Michael Thomas wrote:
>>> I'm still not seeing what the problem is with things as
(Continue reading)

Permalink | Reply | 0 comments |

Gmane