Re: [dmarc-ietf] key sizes, was Section [5.2.1] of the ARC draft

2017-01-25 Thread John R Levine
Signing one seems wrong, ie if the arc-seal only signs a single arc-message-signature at a given hop, then the other signature can't be verified, and if I can't handle the algorithm of the one that's covered, then I can't verify the chain. Currently away on a trip, I'll take a closer look when

Re: [dmarc-ietf] key sizes, was Section [5.2.1] of the ARC draft

2017-01-25 Thread John R Levine
I see a rabbit hole here... So you're transitioning, so you sign twice (one with your old, one with your new) before you send to me and hey, I'm not the end point either, so I need to forward it along, but I'm also transitioning, so I sign both of yours, twice? I would kind of have to,

Re: [dmarc-ietf] key sizes, was Section [5.2.1] of the ARC draft

2017-01-24 Thread John R Levine
On Tue, 24 Jan 2017, Brandon Long wrote: I'm not opposed to requiring support for different encryption algorithms, but we really need to clean up and understand exactly how we handle migration to a new algorithm, probably with a section in the draft specific to it with an example. Fortunately,

Re: [dmarc-ietf] key sizes, was Section [5.2.1] of the ARC draft

2017-01-23 Thread John Levine
>It's been awhile since I've seen this, so it may not be a problem anymore. >There is no obviously correct >thing that someone won't screw up. > >It's probably better to specify how to put multiple strings together. RFC >7208 has words that can probably be >reused without modification. Might

Re: [dmarc-ietf] key sizes, was Section [5.2.1] of the ARC draft

2017-01-23 Thread Scott Kitterman
On January 23, 2017 10:52:06 AM EST, John Levine wrote: >>As I recall there are issues using keys bigger than 1024 bits because >>construction and/or correct interpretation of TXT records that contain >keys >>of that size or bigger has been problematic due to DNS provisioning

Re: [dmarc-ietf] key sizes, was Section [5.2.1] of the ARC draft

2017-01-23 Thread John Levine
>As I recall there are issues using keys bigger than 1024 bits because >construction and/or correct interpretation of TXT records that contain keys >of that size or bigger has been problematic due to DNS provisioning >software that does the former wrong and DKIM verifiers that do the latter