ietf
[Top] [All Lists]

RE: Last Call: draft-kucherawy-authres-header-b (Authentication-Results Registration For Differentiating Among Cryptographic Results) to Proposed Standard

2010-05-26 00:29:54
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf