Re: Last Call: draft-kucherawy-authres-header-b (Authentication-Results Registration For Differentiating Among Cryptographic Results) to Proposed Standard
On 2010-05-26, at 07:18, SM wrote: I see that in some published RFCs, but I didn't see how to create a non-appendix section after the appendices using xml2rfc. section title=Acknowledgements should work. I think you would need to create the section at the back of the front section, and not in the back section. section elements that are children of back are rendered in text with appendix-style numbers. Or just include a note that you would like the section not to be numbered as an appendix, and trust the RFC editor to deal with it in due course :-) Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-kucherawy-authres-header-b (Authentication-Results Registration For Differentiating Among Cryptographic Results) to Proposed Standard
At 13:26 03-05-10, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Authentication-Results Registration For Differentiating Among Cryptographic Results ' draft-kucherawy-authres-header-b-01.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-05-31. Exceptionally, I read this draft and I support it as I am using it in an implementation. In Section 4: The value associated with this item in the header field MUST be at least the first eight characters of the digital signature (the b= tag from a DKIM-Signature or DomainKey-Signature header field) for which a result is being relayed, and MUST be long enough to be unique among the results being reported. As DomainKeys (RFC 4870) is historic since the last three years, it would be better to drop it from this specification. Where the signature of a future method is fewer than eight characters, the entire signature MUST be included. Would it be possible to ensure the unambiguous association then? Going over the MUSTs, the value associated with this item in the header field MUST be at least the first eight characters of the digital signature. We then have Where the signature of a future method is fewer than eight characters, the entire signature MUST be included. I suggest keeping the first requirement for at least eight characters. A future method with less than eight characters cannot use header.b then. In Section 6.2: An attacker could copy a valid signature and add it to a message in transit, modifying some portion of it. This could cause two results to be provided for the same header.b value even if the entire b= string is used in an attempt to differentiate the results. This attack would neutralize any benefit given to a pass result that would have otherwise occurred, possibly impacting the delivery of valid messages. Shouldn't valid signature be valid DKIM-Signature header field (or DomainKey-Signature header field)? If I understood this section, the aim is to get two identical header.b values (the first eight characters). One of them (the copied one) would generate a verification failure. That doesn't negate the (pass) result if the focus is on what has been successfully verified. As an editorial nit, Acknowledgements is generally in a section instead of an Appendix. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-kucherawy-authres-header-b (Authentication-Results Registration For Differentiating Among Cryptographic Results) to Proposed Standard
-Original Message- From: SM [mailto:s...@resistor.net] Sent: Tuesday, May 25, 2010 5:21 PM To: ietf@ietf.org Cc: Murray S. Kucherawy Subject: Re: Last Call: draft-kucherawy-authres-header-b (Authentication-Results Registration For Differentiating Among Cryptographic Results) to Proposed Standard Hi SM, I read this draft and I support it as I am using it in an implementation. Thanks for the review! In Section 4: The value associated with this item in the header field MUST be at least the first eight characters of the digital signature (the b= tag from a DKIM-Signature or DomainKey-Signature header field) for which a result is being relayed, and MUST be long enough to be unique among the results being reported. As DomainKeys (RFC 4870) is historic since the last three years, it would be better to drop it from this specification. I'd be fine with that if the IESG or general consensus feels that's appropriate. RFC5451 included support for DomainKeys in observance of its wide deployment even though it's got Historic status so I also included it here, but I don't have particularly strong feelings about continuing to do so. Where the signature of a future method is fewer than eight characters, the entire signature MUST be included. Would it be possible to ensure the unambiguous association then? One would have to register another mechanism for making an unambiguous reference if it's reasonably possible that a collision can occur. Going over the MUSTs, the value associated with this item in the header field MUST be at least the first eight characters of the digital signature. We then have Where the signature of a future method is fewer than eight characters, the entire signature MUST be included. I suggest keeping the first requirement for at least eight characters. A future method with less than eight characters cannot use header.b then. It still could, if the signature product is somehow shorter than eight characters. I'm not sure I understand what's gained by removing the second part. In Section 6.2: An attacker could copy a valid signature and add it to a message in transit, modifying some portion of it. This could cause two results to be provided for the same header.b value even if the entire b= string is used in an attempt to differentiate the results. This attack would neutralize any benefit given to a pass result that would have otherwise occurred, possibly impacting the delivery of valid messages. Shouldn't valid signature be valid DKIM-Signature header field (or DomainKey-Signature header field)? I could be explicit there, but I thought it was clear enough that those are the two mechanisms being referenced. I don't mind naming them here though if it improves clarity. If I understood this section, the aim is to get two identical header.b values (the first eight characters). One of them (the copied one) would generate a verification failure. That doesn't negate the (pass) result if the focus is on what has been successfully verified. That's true, the attack creates the appearance of a false negative while it's (in theory) impossible to create a false positive. Knowing that, one could perhaps disregard it. The specification could spell that out, but it's useful I think to point out that the attack at least creates a confusing result. As an editorial nit, Acknowledgements is generally in a section instead of an Appendix. I see that in some published RFCs, but I didn't see how to create a non-appendix section after the appendices using xml2rfc. -MSK ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-kucherawy-authres-header-b (Authentication-Results Registration For Differentiating Among Cryptographic Results) to Proposed Standard
On 5/25/2010 8:54 PM, Murray S. Kucherawy wrote: As DomainKeys (RFC 4870) is historic since the last three years, it would be better to drop it from this specification. I'd be fine with that if the IESG or general consensus feels that's appropriate. RFC5451 included support for DomainKeys in observance of its wide deployment even though it's got Historic status so I also included it here, but I don't have particularly strong feelings about continuing to do so. The goal of pressing to have DomainKeys declared Historic was/is to press for adoption of DKIM. That's aided by removing support elsewhere, especially in /new/ standards. The removal also makes the authres spec that much simpler. Simpler is better. One would have to register another mechanism for making an unambiguous reference if it's reasonably possible that a collision can occur. Going over the MUSTs, the value associated with this item in the header field MUST be at least the first eight characters of the digital signature. We then have Where the signature of a future method is fewer than eight characters, the entire signature MUST be included. I suggest keeping the first requirement for at least eight characters. A future method with less than eight characters cannot use header.b then. I also suggest avoided repeating normative text. As an editorial nit, Acknowledgements is generally in a section instead of an Appendix. I see that in some published RFCs, but I didn't see how to create a non-appendix section after the appendices using xml2rfc. Last couple of docs I've worked on have Security, IANA and Acknowledgements as the last 3 sections of middle/middle. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-kucherawy-authres-header-b (Authentication-Results Registration For Differentiating Among Cryptographic Results) to Proposed Standard
Hi Murray, At 20:54 25-05-10, Murray S. Kucherawy wrote: I'd be fine with that if the IESG or general consensus feels that's appropriate. RFC5451 included support for DomainKeys in observance of its wide deployment even though it's got Historic status so I also included it here, but I don't have particularly strong feelings about continuing to do so. There is a normative reference to RFC 4871 (it obsoletes RFC 4870) and an informative reference for RFC 4870. You can drop the second reference then. Section 5 (registry) would have to be adjusted accordingly. It made sense for RFC 5451 to include support for DomainKeys as that specification was written around the same time as DKIM. Dropping RFC 4870 is a way to say we encourage you to stop using software which is no longer maintained. :-) It still could, if the signature product is somehow shorter than eight characters. I'm not sure I understand what's gained by removing the second part. There was a comment about eight bytes a large amount of pseudo-random data ( http://mipassoc.org/pipermail/mail-vet-discuss/2010q1/000591.html ). If the second part is removed, the minimum becomes eight characters. The first MUST mention unique; the second doesn't mention unique. I could be explicit there, but I thought it was clear enough that those are the two mechanisms being referenced. I don't mind naming them here though if it improves clarity. It would be clearer for attackers reading this specification if you were explicit. :-) That's true, the attack creates the appearance of a false negative while it's (in theory) impossible to create a false positive. Knowing that, one could perhaps disregard it. The specification could spell that out, but it's useful I think to point out that the attack at least creates a confusing result. I was thinking of disregarding such data (implementation detail). I agree that the attack could create a confusing result. I see that in some published RFCs, but I didn't see how to create a non-appendix section after the appendices using xml2rfc. section title=Acknowledgements should work. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-kucherawy-authres-header-b (Authentication-Results Registration For Differentiating Among Cryptographic Results) to Proposed Standard
On 03/May/10 22:26, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Authentication-Results Registration For Differentiating Among Cryptographic Results ' draft-kucherawy-authres-header-b-01.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-05-31. The I-D identifies a possible result forgery (section 6.2). Although I haven't fully grasped the reasons why such attack would be attempted, I think that condition is a case where the spoofed signature SHOULD be removed by the verifier. I'm not sure the latter spec would be an update of rfc 4871, since it says /Signers/ SHOULD NOT remove any DKIM-Signature header field [emphasis added]. (Other cases where signatures might be removed --mailing lists-- are currently being discussed on ietf-dkim.) For a minor point, the example (A.1) the I-D makes does not illustrate the reason for introducing header.b. The exemplified signatures can already be distinguished by their header.i values. By setting that attribute also in this case, the example conveys the impression that header.b should not be omitted, even when it is unnecessary. If that's the intended meaning, it should be stated more explicitly, IMHO. OTOH, the example shows a case where a signature had been validated before being broken (discussed on ietf-dkim and [1]). However, that is apparently the only part of the I-D discussing such topic. -- [1] http://mipassoc.org/pipermail/mail-vet-discuss/2010q2/000602.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-kucherawy-authres-header-b (Authentication-Results Registration For Differentiating Among Cryptographic Results) to Proposed Standard
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Alessandro Vesely Sent: Tuesday, May 04, 2010 2:46 AM To: ietf@ietf.org Subject: Re: Last Call: draft-kucherawy-authres-header-b (Authentication-Results Registration For Differentiating Among Cryptographic Results) to Proposed Standard For a minor point, the example (A.1) the I-D makes does not illustrate the reason for introducing header.b. The exemplified signatures can already be distinguished by their header.i values. By setting that attribute also in this case, the example conveys the impression that header.b should not be omitted, even when it is unnecessary. If that's the intended meaning, it should be stated more explicitly, IMHO. Thanks, that was an oversight on my part. I'll correct it in the next version. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-kucherawy-authres-header-b (Authentication-Results Registration For Differentiating Among Cryptographic Results) to Proposed Standard
The IESG has received a request from an individual submitter to consider the following document: - 'Authentication-Results Registration For Differentiating Among Cryptographic Results ' draft-kucherawy-authres-header-b-01.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2010-05-31. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-kucherawy-authres-header-b-01.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=19889rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
