Re: [dmarc-ietf] Algorithm rotation, New drafts of ARC protocol (10) & usage (03) posted

2017-12-21 Thread John Levine
In article <13429029.WxFjRkil8E@kitterma-e6430> you write: >> Stall ARC for a few more months until we can get ed25519 into the >> libraries, then adjust the document to make it MUST verify both. > >I doubt you'll see it in OpenARC until after OpenSSL has a release that >supports ed25519. That ma

Re: [dmarc-ietf] Algorithm rotation, New drafts of ARC protocol (10) & usage (03) posted

2017-12-21 Thread Seth Blank
That is also what I remember, and why I proposed the Experimental Considerstions as part of the primary draft and not the usage guide. Kurt had some strong opinions on why they belonged in the usage guide, which I suggest we revisit in another thread. On Thu, Dec 21, 2017 at 15:11 Dave Crocker w

Re: [dmarc-ietf] Algorithm rotation, New drafts of ARC protocol (10) & usage (03) posted

2017-12-21 Thread Dave Crocker
On 12/21/2017 9:29 AM, Brandon Long wrote: I would have preferred not to defer it when arc was on standards track, but now that it's experimental, I recall an extended discussion that produced agreement on experiment. I don't recall seeing a discussion to reverse that, nor a change in circum

Re: [dmarc-ietf] Algorithm rotation, New drafts of ARC protocol (10) & usage (03) posted

2017-12-21 Thread Scott Kitterman
On Thursday, December 21, 2017 11:57:44 AM John Levine wrote: > In article <1513857489.3531319.1212273208.18fe8...@webmail.messagingengine.com> you write: > >I certainly concur with Brandon here - changing ARC algorithm looks like > >a very messy proposition, I expect you'd pretty much have to do

Re: [dmarc-ietf] Algorithm rotation, New drafts of ARC protocol (10) & usage (03) posted

2017-12-21 Thread Kurt Andersen (b)
On Thu, Dec 21, 2017 at 5:29 PM, Brandon Long wrote: > > > . . .when arc was on standards track, but now that it's experimental . . . > It's not experimental - that was a proposal in Prague when we were considering pushing for WGLC before Singapore. Since we are continuing to iterate and clean up

Re: [dmarc-ietf] Algorithm rotation, New drafts of ARC protocol (10) & usage (03) posted

2017-12-21 Thread Seth Blank
Now from my personal email. On Thu, Dec 21, 2017 at 09:30 Brandon Long wrote: > I would have preferred not to defer it when arc was on standards track, > but now that it's experimental, > I could see deferring it. I'm also fine with John's approach to wait for > dcrup, though I don't know many

Re: [dmarc-ietf] Algorithm rotation, New drafts of ARC protocol (10) & usage (03) posted

2017-12-21 Thread Brandon Long
On Thu, Dec 21, 2017 at 9:23 AM Seth Blank wrote: > On Thu, Dec 21, 2017 at 8:57 AM, John Levine wrote: > >> Simple administrative approach: >> >> Stall ARC for a few more months until we can get ed25519 into the >> libraries, then adjust the document to make it MUST verify both. >> > > Is there

Re: [dmarc-ietf] Algorithm rotation, New drafts of ARC protocol (10) & usage (03) posted

2017-12-21 Thread Seth Blank
On Thu, Dec 21, 2017 at 8:57 AM, John Levine wrote: > Simple administrative approach: > > Stall ARC for a few more months until we can get ed25519 into the > libraries, then adjust the document to make it MUST verify both. > Is there any appetite in the group to handle rotation in a separate doc

Re: [dmarc-ietf] Algorithm rotation, New drafts of ARC protocol (10) & usage (03) posted

2017-12-21 Thread John Levine
In article <1513857489.3531319.1212273208.18fe8...@webmail.messagingengine.com> you write: >I certainly concur with Brandon here - changing ARC algorithm looks like >a very messy proposition, I expect you'd pretty much have to do a window >where both the old and new algorithm were supported - with

Re: [dmarc-ietf] New drafts of ARC protocol (10) & usage (03) posted

2017-12-21 Thread Bron Gondwana
On Thu, 21 Dec 2017, at 17:12, Murray S. Kucherawy wrote: > On Wed, Dec 20, 2017 at 4:39 PM, Brandon Long > wrote:>> >> I think algorithm rotation is more challenging for ARC than it is for >> DKIM, since with DKIM you can just sign with both... but for ARC, >> there's a chain of signers and the