ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

2009-06-11 12:21:31


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

<Prev in Thread] Current Thread [Next in Thread>