Top posting since the quoting seems hopelessly confused. Here is a specific proposal (unified diff and rfcdiff attached). I liberally borrowed text from RFC 6376 to minimize the novelty of the proposal. The ARC draft already references RFC 6376, section 3.6, so I don't think we need another reference specifically to 3.6.2.2 to talk about how to concatenate TXT strings.
I did not attempt to cover algorithm agility or define an additional algorithm beyond SHA 256. Whatever the next algorithm is, I think it needs to apply to both DKIM and ARC, so it's out of scope. I think the issues associated with ARC chains using different algorithms should be addressed, but I'm hoping the clearer proposal that John Levine mentioned[1] will address that. Scott K [1] <[email protected]> On Saturday, January 21, 2017 08:09:59 PM Brandon Long wrote: > On Jan 20, 2017 4:08 PM, "Peter Goldstein" <[email protected]> wrote: > > I think Scott's point about operational options is well taken. Google ran > into some operational issues with some DNS vendors when they attempted to > make all new G Suite DKIM keys 2048 - they rolled back to making 2048 bit > keys the default, but allowing 1024 bit keys as an option. > > > Yeah, it turns out virtually all DNS registrars with website editors fail > to handle long TXT records as of about 6 months ago. > > Brandon > > > The MUST/SHOULD language suggested makes sense. And we definitely don't > need to roll out new protocols using SHA-1. > > I would suggest some related language for verifiers. Something like what's > found in the DKIM spec, but with updated bit sizes: > > Verifiers MUST be able to validate signatures with > keys ranging from 1024 bits to 4096 bits, and they MAY be able to > validate signatures with larger keys. > > At a minimum I think we should require verifiers to be able to support 4096 > bit keys (and potentially 8192 bit). There's no reason verifiers shouldn't > be able to support longer key sizes, and this adds some future proofing to > the specification. > > Best, > > Peter > > On Fri, Jan 20, 2017 at 3:41 PM, Scott Kitterman <[email protected]> > > wrote: > > On Friday, January 20, 2017 03:30:58 PM Scott Kitterman wrote: > > > On Friday, January 20, 2017 you wrote: > > > > On 01/20/2017 11:23, Scott Kitterman wrote: > > > > > I'm not on the ARC list, so I'll pile on this thread here... > > > > > > > > This is the right place for anything constructive regarding the > > > > specification, so no problem regarding any other lists. > > > > > > > > > I understand the minimum key size in the draft is 512 bits. I'm not > > > > > planning > > > > > on releasing any software that supports key sizes less than 1024, so > > > > I > > > > > > > guarantee you interoperability problems for small keys. > > > > > > > > +1 -- no need for weak keys. > > > > > > > > 1) Do we have a normative reference within the RFC framework for key > > > > lengths for different crypto systems, and can we simply invoke that > > > > reference rather than including a hard figure in this spec? > > > > > > > > 2) Does such a reference still consider 1k keys as acceptable at this > > > > time? Is there a schedule for periodic review? > > > > > > > > --S. > > > > > > > > +++1 wrt Scott's comment about 512 bit keys. We inherit this > > > > requirement > > > > > > from the DKIM spec, but imho it is not reasonable. If this is worth > > > > discussing, perhaps we should move it to another thread? > > > > > > > > Regards, > > > > =Gene > > > > > > OK, Since I wasn't off topic after all, here's a new thread... > > > > > > I believe we've looked for such a reference before and not found a good > > > > one. > > > > > The IETF BCP is from 2004: https://tools.ietf.org/html/rfc3766 > > > > > > Operationally, 1024 is the minimum key size recommendation I generally > > > > see > > > > > for DKIM today. NIST recommends 2048 bits, SHA-256 only for US > > > goverment > > > use [1]. > > > > > > > > > Scott K > > > [1] http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST. > > > > SP.800-177.pdf > > > > Moving John Levine's reply into this thread and then replying further: > > > > On Friday, January 20, 2017 10:17:02 PM John Levine wrote: > > > >1) Do we have a normative reference within the RFC framework for key > > > >lengths for different crypto systems, and can we simply invoke that > > > >reference rather than including a hard figure in this spec? > > > > > > There's RFC 3766, but it's over a decade old and has rules for how to > > > figure out how long a key you need, not the actual sizes. > > > > > > This NIST publication seems relevant: > > > > > > http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST. > > > > SP.800-57pt1r4.pdf > > > > > The tables on pages 52 and 53 suggest that we use 2K keys and sha256 > > > > hashes. > > > > > >2) Does such a reference still consider 1k keys as acceptable at this > > > >time? Is there a schedule for periodic review? > > > > > > No. See the document. > > > > > > R's, > > > John > > > > Large keys like 2048 present other potential operational problems. Here's > > a > > 2048 bit, sha-256 key record: > > > > default._domainkey IN TXT ( "v=DKIM1; h=sha-256; k=rsa; " > > > > "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAy5nzBQiwX1l4Q > > > > DoE1glqw+93aMMp9hVVg8KYP3z43GTNScXda0mLAPoScWc1EHnm37TCdWj57 > > F0CYjZhvsX0EnkRpibYCEX/AZ2xLmwE7XcMXWWYjlUCK/BfFhuCUOEDbokjR > > CJ/ULbVUZfC8I8QZFdhqno987m26UhayLT3iNboj+v4mqUdYkVg6FmNRZRdDhxJYDSosT9j2Y" > > > > "2eaSVsQ5Pvyt2ZzOjHJ9eXujw6/DKR2WGVEIIX+3sKqeH7tDbeXulzv102H > > > > P1fmoE6sKgPRevIHKoMfFagNyXXkqxmyRY/jV+yZGGz7RZEpNApv7pyBtfG0 > > bz7cTwVX4QvP/8MUQIDAQAB" > > ) > > > > I'm sure that will get line wrapped into illegibility, so I'll make the > > actual > > point: It's longer than will fit in a single TXT string. While there is > > nothing wrong with that from a DNS standards or even a core DNS > > operational > > perspective, it is not rare that DNS provisioning systems don't support > > this. > > I don't want to make it so secure it's deployability is severely hampered. > > > > I would suggest MUST at least 1024 bit, SHOULD 2048 bits. I think MUST > > sha-256 is also a good idea. Approximately the last thing we should be > > doing > > now is rolling out new protocols using sha-1. > > > > Scott K > > > > _______________________________________________ > > dmarc mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/dmarcTitle: Diff: arc.old - arc.new
| arc.old | arc.new | |||
|---|---|---|---|---|
| skipping to change at page 2, line 33 | skipping to change at page 2, line 33 | |||
| 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 5. Definition . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 5. Definition . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 5.1. Description of the New Header Fields . . . . . . . . . . 6 | 5.1. Description of the New Header Fields . . . . . . . . . . 6 | |||
| 5.1.1. ARC-Seal . . . . . . . . . . . . . . . . . . . . . . 6 | 5.1.1. ARC-Seal . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 5.1.2. ARC-Message-Signature . . . . . . . . . . . . . . . . 9 | 5.1.2. ARC-Message-Signature . . . . . . . . . . . . . . . . 9 | |||
| 5.1.3. ARC-Authentication-Results . . . . . . . . . . . . . 10 | 5.1.3. ARC-Authentication-Results . . . . . . . . . . . . . 10 | |||
| 5.2. Constructing the ARC-Seal Set . . . . . . . . . . . . . . 11 | 5.2. Constructing the ARC-Seal Set . . . . . . . . . . . . . . 11 | |||
| 5.2.1. Handling Violations in the ARC Sets . . . . . . . . . 12 | 5.2.1. Handling Violations in the ARC Sets . . . . . . . . . 12 | |||
| 5.3. Key Management and Binding . . . . . . . . . . . . . . . 12 | 5.3. Key Management and Binding . . . . . . . . . . . . . . . 12 | |||
| 5.3.1. Namespace . . . . . . . . . . . . . . . . . . . . . . 12 | 5.3.1. Namespace . . . . . . . . . . . . . . . . . . . . . . 12 | |||
| 5.3.2. Key Sizes . . . . . . . . . . . . . . . . . . . . . . 13 | ||||
| 6. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 | 6. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
| 6.1. Participation . . . . . . . . . . . . . . . . . . . . . . 13 | 6.1. Participation . . . . . . . . . . . . . . . . . . . . . . 13 | |||
| 6.2. Relationship between DKIM Signatures and ARC Headers . . 13 | 6.2. Relationship between DKIM Signatures and ARC Headers . . 13 | |||
| 6.3. Validating the ARC Set of Header Fields . . . . . . . . . 13 | 6.3. Validating the ARC Set of Header Fields . . . . . . . . . 13 | |||
| 6.4. ARC Set Validity . . . . . . . . . . . . . . . . . . . . 13 | 6.4. ARC Set Validity . . . . . . . . . . . . . . . . . . . . 13 | |||
| 6.4.1. Assessing Chain Validity Violations . . . . . . . . . 13 | 6.4.1. Assessing Chain Validity Violations . . . . . . . . . 13 | |||
| 6.4.2. Responding to ARC Validity Violations . . . . . . . . 14 | 6.4.2. Responding to ARC Validity Violations . . . . . . . . 14 | |||
| 6.4.3. Recording the Results of ARC Evaluation . . . . . . . 14 | 6.4.3. Recording the Results of ARC Evaluation . . . . . . . 14 | |||
| 6.4.4. Output Data Points from ARC Evaluation . . . . . . . 14 | 6.4.4. Output Data Points from ARC Evaluation . . . . . . . 14 | |||
| 6.4.5. Reporting ARC Effects for DMARC Local Policy . . . . 14 | 6.4.5. Reporting ARC Effects for DMARC Local Policy . . . . 14 | |||
| skipping to change at page 6, line 50 | skipping to change at page 6, line 50 | |||
| The ARC-Seal header field includes a digital signature of all | The ARC-Seal header field includes a digital signature of all | |||
| preceding ARC message header fields on the message. | preceding ARC message header fields on the message. | |||
| 5.1.1.1. Tags in the ARC-Seal Header Field Value | 5.1.1.1. Tags in the ARC-Seal Header Field Value | |||
| The following tags are the only supported tags for an ARC-Seal field. | The following tags are the only supported tags for an ARC-Seal field. | |||
| All of them MUST be present. Unknown tags MUST be ignored and do not | All of them MUST be present. Unknown tags MUST be ignored and do not | |||
| affect the validity of the header. | affect the validity of the header. | |||
| o a = hash algorithm; syntax is the same as the "a=" tag defined in | o a = hash algorithm; syntax is the same as the "a=" tag defined in | |||
| Section 3.5 of [RFC6376]; | Section 3.5 of [RFC6376], but only the only valid algorithm is | |||
| currently defined for ARC is "rsa-sha256"; | ||||
| o b = digital signature; syntax is the same as the "b=" tag defined | o b = digital signature; syntax is the same as the "b=" tag defined | |||
| in Section 3.5 of [RFC6376]; | in Section 3.5 of [RFC6376]; | |||
| o cv = chain validation status: valid values: | o cv = chain validation status: valid values: | |||
| * 'none' = no pre-existing chain; | * 'none' = no pre-existing chain; | |||
| * 'fail' = the chain as received does not validate; or | * 'fail' = the chain as received does not validate; or | |||
| skipping to change at page 13, line 9 | skipping to change at page 13, line 9 | |||
| 5.3.1. Namespace | 5.3.1. Namespace | |||
| All ARC-related keys are stored in the same namespace as DKIM keys | All ARC-related keys are stored in the same namespace as DKIM keys | |||
| [RFC6376]: "_domainkey" specifically by adding the "._domainkey" | [RFC6376]: "_domainkey" specifically by adding the "._domainkey" | |||
| suffix to the name of the key (the "selector"). For example, given | suffix to the name of the key (the "selector"). For example, given | |||
| an ARC-Seal (or ARC-Message-Signature) field of a "d=" tag value of | an ARC-Seal (or ARC-Message-Signature) field of a "d=" tag value of | |||
| "example.com" and an "s=" value of "foo.bar", the DNS query seeking | "example.com" and an "s=" value of "foo.bar", the DNS query seeking | |||
| the public key will a query at the name | the public key will a query at the name | |||
| "foo.bar._domainkey.example.com". | "foo.bar._domainkey.example.com". | |||
| 5.3.2. Key Sizes | ||||
| Selecting appropriate key sizes is a trade-off between cost, | ||||
| performance, and risk. Since short RSA keys more easily succumb to | ||||
| off-line attacks, Signers MUST use RSA keys of at least 1024 bits. Verifiers | ||||
| MUST be able to validate signatures with keys ranging from 1024 bits to 4096 | ||||
| bits, and they MAY be able to validate signatures with larger keys. Verifier | ||||
| policies may use the length of the signing key as one metric for determining | ||||
| whether a signature is acceptable. | ||||
| Factors that should influence the key size choice include the | ||||
| following: | ||||
| o The practical constraint that large (e.g., 4096-bit) keys might | ||||
| not fit within a 512-byte DNS UDP response packet | ||||
| o Larger keys impose higher CPU costs to verify and sign email | ||||
| o Keys can be replaced on a regular basis; thus, their lifetime can | ||||
| be relatively short | ||||
| o The security goals of this specification are modest compared to | ||||
| typical goals of other systems that employ digital signatures | ||||
| See [RFC3766] for further discussion on selecting key sizes. | ||||
| 6. Usage | 6. Usage | |||
| For a more thorough treatment of the recommended usage of the ARC | For a more thorough treatment of the recommended usage of the ARC | |||
| header fields for both intermediaries and end receivers, please | header fields for both intermediaries and end receivers, please | |||
| consult [ARC-USAGE]. | consult [ARC-USAGE]. | |||
| 6.1. Participation | 6.1. Participation | |||
| The inclusion of additional ARC sets is to be done whenever a trust | The inclusion of additional ARC sets is to be done whenever a trust | |||
| boundary is crossed, and especially when prior DKIM-Signatures might | boundary is crossed, and especially when prior DKIM-Signatures might | |||
| skipping to change at page 23, line 5 | skipping to change at page 23, line 5 | |||
| Andersen, "Interoperability Issues Between DMARC and | Andersen, "Interoperability Issues Between DMARC and | |||
| Indirect Email Flows", June 2016, | Indirect Email Flows", June 2016, | |||
| <https://tools.ietf.org/html/draft-ietf-dmarc- | <https://tools.ietf.org/html/draft-ietf-dmarc- | |||
| interoperability-17>. | interoperability-17>. | |||
| [ENHANCED-STATUS] | [ENHANCED-STATUS] | |||
| "IANA SMTP Enhanced Status Codes", n.d., | "IANA SMTP Enhanced Status Codes", n.d., | |||
| <http://www.iana.org/assignments/smtp-enhanced-status- | <http://www.iana.org/assignments/smtp-enhanced-status- | |||
| codes/smtp-enhanced-status-codes.xhtml>. | codes/smtp-enhanced-status-codes.xhtml>. | |||
| [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For | ||||
| Public Keys Used For Exchanging Symmetric Keys", BCP 86, | ||||
| RFC 3766, April 2004. | ||||
| [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running | [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running | |||
| Code: The Implementation Status Section", RFC 6982, | Code: The Implementation Status Section", RFC 6982, | |||
| DOI 10.17487/RFC6982, July 2013, | DOI 10.17487/RFC6982, July 2013, | |||
| <http://www.rfc-editor.org/info/rfc6982>. | <http://www.rfc-editor.org/info/rfc6982>. | |||
| [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based | [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based | |||
| Message Authentication, Reporting, and Conformance | Message Authentication, Reporting, and Conformance | |||
| (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, | (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, | |||
| <http://www.rfc-editor.org/info/rfc7489>. | <http://www.rfc-editor.org/info/rfc7489>. | |||
| End of changes. 4 change blocks. | ||||
| 1 lines changed or deleted | 33 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||
--- arc.old 2017-02-03 13:13:41.096992188 -0500
+++ arc.new 2017-02-03 13:30:46.897018539 -0500
@@ -86,6 +86,7 @@
5.2.1. Handling Violations in the ARC Sets . . . . . . . . . 12
5.3. Key Management and Binding . . . . . . . . . . . . . . . 12
5.3.1. Namespace . . . . . . . . . . . . . . . . . . . . . . 12
+ 5.3.2. Key Sizes . . . . . . . . . . . . . . . . . . . . . . 13
6. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Participation . . . . . . . . . . . . . . . . . . . . . . 13
6.2. Relationship between DKIM Signatures and ARC Headers . . 13
@@ -327,7 +328,8 @@
affect the validity of the header.
o a = hash algorithm; syntax is the same as the "a=" tag defined in
- Section 3.5 of [RFC6376];
+ Section 3.5 of [RFC6376], but only the only valid algorithm is
+ currently defined for ARC is "rsa-sha256";
@@ -679,6 +681,33 @@
the public key will a query at the name
"foo.bar._domainkey.example.com".
+5.3.2. Key Sizes
+
+
+ Selecting appropriate key sizes is a trade-off between cost,
+ performance, and risk. Since short RSA keys more easily succumb to
+ off-line attacks, Signers MUST use RSA keys of at least 1024 bits. Verifiers
+ MUST be able to validate signatures with keys ranging from 1024 bits to 4096
+ bits, and they MAY be able to validate signatures with larger keys. Verifier
+ policies may use the length of the signing key as one metric for determining
+ whether a signature is acceptable.
+
+ Factors that should influence the key size choice include the
+ following:
+
+ o The practical constraint that large (e.g., 4096-bit) keys might
+ not fit within a 512-byte DNS UDP response packet
+
+ o Larger keys impose higher CPU costs to verify and sign email
+
+ o Keys can be replaced on a regular basis; thus, their lifetime can
+ be relatively short
+
+ o The security goals of this specification are modest compared to
+ typical goals of other systems that employ digital signatures
+
+ See [RFC3766] for further discussion on selecting key sizes.
+
6. Usage
For a more thorough treatment of the recommended usage of the ARC
@@ -1234,6 +1263,10 @@
Internet-Draft ARC-Protocol December 2016
+ [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
+ Public Keys Used For Exchanging Symmetric Keys", BCP 86,
+ RFC 3766, April 2004.
+
[RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", RFC 6982,
DOI 10.17487/RFC6982, July 2013,
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
