Re: [secdir] secdir review of draft-kucherawy-authres-header-b-02

["Murray S. Kucherawy" <[e-mail]>]

Hi Stephen, thanks for the review!

> -----Original Message-----
> From: Stephen Farrell [mailto:[e-mail]]
> Sent: Wednesday, June 09, 2010 4:25 PM
> To: Murray S. Kucherawy; [e-mail]
> Subject: secdir review of draft-kucherawy-authres-header-b-02
> 
> 1. What if someone defines a MACing scheme for DKIM with
>    a teensy-weensy MAC? There might be no way to get 8
>    characters then. Suggest allowing the full authenticator
>    in that case if its <8 bytes long. Very unlikely but
>    maybe worth a sentence.

I had that in originally, but a LC reviewer suggested it be removed on the grounds that such a signature method is collision-prone, and thus this spec should try not to support it.  Instead, I think I'll add it back in with a new subsection in Security Considerations making this concern clear and reminding consumers that collisions must be ignored.

> 2. Apppendix A says:
> 
>   "Presumably due to a change in one of the five header fields covered
>    by the two signatures, the former signature failed to verify while
>    the latter passed."
> 
>    I think that could only happen if they use different c14n, if
>    so maybe say so. Or could be better to say the results may
>    differ due for key mgmt reasons (e.g. an inaccessible public key)
>    or because the signature values have been corrupted. Reason to
>    prefer those is that they're more likely. (Or am I missing
>    something?)

An inaccessible key produces a result of "neutral" or "temperror" (I forget which) so a "fail" would only be the former case of one c14n surviving while the other didn't.  I'll add a little more explanatory text to point that out.

Cheers,
-MSK