Re: [dnsext] Clarifying the mandatory algorithm rules

[Matthijs Mekking <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I would say you need to check the algorithms signaled in the DS RRset
(the already (in)famous section 2.2 from RFC 4035 implicitly says so).

Now whether the validator SHOULD or MUST check that the algorithms
signalled in the DS-set work: If the working group decides this should
be a SHOULD, validating resolvers will have a choice to fallback to "One
Signature Is Enough". In practice, this would probably be a
configuration knob algorithm-compromise-protection: "yes" or "no".

Although this is local policy, I also think it is bad policy for a
validator to allow algorithm compromises and badly signed zones. Thus, I
would go for a MUST here.

Best regards,

Matthijs






On 11/30/2010 11:43 AM, W.C.A. Wijngaards wrote:
> Hi workgroup,
> 
> The unbound implementation is the way it has been written, and I agree
> that changes have to be made to it.  Now, what is the right way?
> 
> On 11/22/2010 06:33 PM, Paul Vixie wrote:
>>> Date: Mon, 22 Nov 2010 07:58:53 -0500
>>> From: Edward Lewis <[e-mail]>
>>> ...
>>> DNSSEC is designed to protect against cache poisoning.  If there is a chain
>>> of trust to an RRSet, then the set validates, it has proven source
>>> authenticity and data integrity.
>>>
>>> Since time began (for DNS), there is always something wrong somewhere.  The
>>> goal is a robust system, not a tightly correct system.
> 
>> +1.
> 
> It would be good to have some text in bis-updates on this.  (I mean on
> the algorithm topic, the general leniency has been put forward by Alfred
> and others and I wholeheartedly agree with it :-) ).
> 
> It is clear that checking the set of algorithms present in the DNSKEY
> set is not a good idea, and checking the set of algorithms from the DS
> set is the right, more lenient way to go.  (so this is what Mark was
> proposing).  This is what validators use to determine if they can
> support the algorithms present in the zone today (and tomorrow).
> 
> However, there are choices that I see here, that change the security
> properties.
> 
> 
> * One Signature Is Enough
> 
> Check one signature, if it works, it's enough, and the added text is
> 'regardless of the algorithms signalled in the DS-set'.
> + it is lenient.
>   (it would have avoided the operational problems that incited this).
> + if a zone is badly signed, so it includes algorithms in the DS set for
> which proper signatures are not available, the validators that support
> both algorithms approve of this situation.
> - no algorithm-protection (explanation below).
> 
> 
> * Check the Algorithms
> 
> For the algorithms signalled in the DS set, check that there is a valid
> chain of trust for them.  Added text is, the validator SHOULD or MUST
> check (choice here) that the algorithms signalled in the DS-set work
> (but only for algorithms supported by the validator, of course).
> 
> + it is lenient because uses DS-set not DNSKEY-set.
>   (this allows the easier algo rollovers; it would have avoided the
> operational problems that incited this).
> - but not as lenient as 'one signature', this is the case of zones that
> are badly signed but have signalled the algorithm with their DS, so that
> a portion of validators are certain to fail for it.  Validators that
> support the other algo now also fail for it.
> + algorithm protection (explanation below).
>   + if SHOULD, local-policy decides what protection to apply.
> 
> 
> Algorithm compromise protection.
> This is a security property that the validation result can have or not.
>  Security algorithms have different properties, and by checking them you
> receive joined benefits.  Specifically, if one algorithm is 'broken'
> (but you do not yet know which one that will be), then you are protected
> against this because you check the other algorithm.
> 
> For zones that perform a single-DS rollover, this never applies, as the
> single DS makes validators check one algorithm anyway (since this
> minimizes communication with the parent, many zones can be envisioned to
> do this).  Other zones may have multiple DSes (or DLVs) and thus can
> have multiple crypto algorithms checked, at their option (and the
> validator local policy).
> 
> 
> I would like to know what the (seems rough) consensus is, so that I can
> go forward and implement this right.  It is then a good idea that Sam
> puts conclusions in the dnssec-bis-updates draft.
> 
> Best regards,
>    Wouter
_______________________________________________
dnsext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsext
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNAKhsAAoJEA8yVCPsQCW51mwIAKdNkDzTSC0FMU2MftgLq3Js
ZVDhnT4kjwuOCnr002Y04ENgYyR+p9pM97k+Vuoku6c5BwTkH9O1Scv9AeexPDpA
nkC2XSL3fxKtRFWb+ycGUiOfGOsZ0mqTqaW8zXR+VRmNlj/0zPu1Wer7VjHpLYgZ
5SHXzSwWf6HpXjpVblbyvHoyZCrHCT/fGMwFexppIG09DXl4DWqZnJ/almx1ZAXP
8QeWnV8k/Zb0E95IW/im/m53630qhSM8Blxvgu/vLEyBWO1+1nl/1SFsMholFZBX
l0i5oTqdJReYwTmLHROCEqc7isSvVSjtmEtJxjDrjSO0DA1ZsLSNYjMIVRaagLY=
=ddHZ
-----END PGP SIGNATURE-----