Dave CROCKER wrote: > > > Stephen Farrell wrote: >> The putative attack would be to sign with foo-sha256 where foo is some >> algorithm that a verifier supports and such that the foo key encoding >> could >> accept an rsa p= value as input and such that that combination allows the >> attacker to forge signatures. >> >> That's fairly theoretical, but there'd be a bit of work to go check that >> there is in fact no realistic situation where such confusion could >> arise. So >> on the whole, for me, keeping the k= just makes it easier to get >> things right >> now and in future. > > > If out-of-band algorithm/key-type registration like this is not a > regular "protection" mechanism provided in existing, related > crypto-based schemes:
I think it is common mechanism. Normally its in a certificate for PKI based applications or as part of negotiation in e.g. TLS etc. XMLDSIG also includes the same information in its data structures. > 1) Why should it be only in DKIM? So I don't think that this is the case. > > 2) Won't it need expert vetting by the security community to > validate that the threat is real and the protection is sufficient? Well, 4871 got last called, secdir review etc so it got as much security review as most things. I don't think this is the kind of thing where we'd need to get cfrg input. > I have been repeatedly taught by the security community to be extremely > cautious about casual assumptions of what will fix a theoretical > exposure. So, for example, there have been cases where encrypting twice > using the same algorithm reduces protection rather than raising it. > That ain't intuitive. > > Same concern here. Well I guess both concerns are theoretical really. Personally, I think having these fields in the key record reduces the need for security analysis which is a good enough reason for me. Of course, others might disagree, but I've not heard any security concern about including them. > Having this information maintained in the DNS isn't free and isn't > certain to be safe. Fair enough. Though I don't understand the additional expense of k= and h= in key records - I'd have thought it might even help maintaining those records, but since I don't maintain any DNS stuff I may be wrong. I do agree that key records being unsigned in the DNS is a risk, but its one we accepted at the start of the WG. S. > > d/ _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
