Re: [dnsext] Issues in WGLC of dnssec-bis-updates

[Mohan Parthasarathy <[e-mail]>]

On Wed, Feb 8, 2012 at 12:30 AM, W.C.A. Wijngaards <[e-mail]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Mohan,
>
> The definition of indeterminate was wrong in RFC4035, and you now seem
> to think DNSSEC is riddled with downgrade.  There is no downgrade,
> because the security-states are the outcome of the chain-of-trust
> algorithm, not implemented from its definitions in RFC4035.
>
Okay, after reading your response and re-reading 4035 and 4033, I
think 4033 definitions for Bogus, Insecure and Indeterminate capture
the discussion below more clearly.

 <snip>

> On 02/07/2012 08:51 PM, Mohan Parthasarathy wrote:
>> On Tue, Feb 7, 2012 at 9:14 AM, Edward Lewis <[e-mail]> wrote:
>>> At 16:34 +0100 2/7/12, W.C.A. Wijngaards wrote:
>>>
>>>> insecure, or bogus.  Note that with the root trust anchor the
>>>> indeterminate state no longer occurs, since we know everything is
>>>> covered by that trust anchor.
>>>
>>>
>>> I disagree with that.
>>>
>>> The Internet that we usually think about as being the only one is what I
>>> call the "global public Internet".  For the global public Internet, the DNS
>>> in common use does have a trust anchor for it's root zone so the assertion
>>> holds for the majority of cases, but then again only for recursive servers
>>> that have the trust anchor.
>>>
>>> There are other inter-networks that use the DNS protocol.  In at least one
>>> of these, DNSSEC has not been deployed.
>>>
>>> And, you can stretch this to the case of a recursive server, on the global
>>> public Internet, that does not have the root anchor configured - and may
>>> have another anchor.  To such a server, validating some DNS data is
>>> impossible (incalculable).
>>>
>>> The protocol cannot be defined assuming one particular mode of operation.
>>>
>> Before getting to define this precisely, we should try to understand
>> the different cases that can occur and see whether we all agree on the
>> error status for the different cases.
>
> Why data cannot be fetched is not a factor in the end result.  This
> simplifies the cases to: cannot get the proper DNSSEC data, can get
> proper DNSSEC data but it's invalid, can get proper DNSSEC data and it's
> ok.  And the results are bogus, bogus, secure.  If you find an insecure
> delegation it is insecure.  If there is no applicable trust anchor, the
> result is indeterminate (that is effectively just like insecure).
>

Ok, Bogus, Secure and Insecure applies only when there is an
applicable trust anchor. When it is absent, it is indeterminate. That
simplifies a lot.

 <snip>
>>
>> 1) We get some DNSSEC RRs back but can't validate. Just being able to
>> partially validate without tracing back to the trust anchor is equally
>> bad as not being able to validate the signatures.
>
> Yes, that is bogus in today's implementations.
>
>> 2) We get no DNSSEC RRs back. This could be a problem in the path or
>> the zone is not signed. We can't tell the difference without some
>> extra configuration.
>
> You can tell the difference because the chain-of-trust is signed itself,
> and this extends from the trust anchor to the data you just got, and
> thus you know if this zone is signed or not.  And thus in your question,
> the unsigned zone is ok(insecure), and the signed-zone-missing-DNSSEC
> RRs is not ok(bogus).
>
>> How does it help the application to make this more fine grained ?
>
> No, the application just wants all bogus data to be removed.  Data that
> is secure and data that is not DNSSEC signed is what it wants.  Because
> of the chain-of-trust the validator knows which parts of the space below
> a trust anchor is signed (and must have DNSSEC available) and which part
> is unsigned.  This property could be the cause that made insecure and
> indeterminate terms exist, as indeterminate is not really processed but
> simply the absence of a covering trust anchor, just like in the case
> where you had no trust anchors at all.  But then insecure needs
> processing: you have to validate the chain of trust from the trust
> anchor to the insecure-delegation point, and only then can you conclude
> that the data is insecure.  This is something internal to the DNSSEC
> validator, and not particularly impressive to the application, that
> likely just wants to know if the data was DNSSEC-signed (if so: secure
> or bogus) or if the data was not DNSSEC-signed (as determined with the
> configured set of trust anchors).
>
That was very useful discussion.

regards
mohan

> Best regards,
>   Wouter
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.15 (GNU/Linux)
> Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/
>
> iQIcBAEBAgAGBQJPMjK2AAoJEJ9vHC1+BF+NxVUQAIyQ4nPk7Syogn9uh4z890yJ
> kmPxslbpvHru47OxKd0tYvozldnP32z1+JToGSZR8qRU+w9SAQLutnFkqCU28x95
> QUAot8G157kxZT95zhdjVqpbyUYDYwKKUY4jqplq4IuyIm1ewEOcwAS8Sak1o9Gr
> 17Xs4aCpl55QmTCZAlP+r6SwCDY738Py9I51BJhifAB9HdkT6XK1+bsbMSiFhG+o
> koICUhKaLDthmFvBrHBVCiW4xD5uk8ww2jlMNXv2LaRT05tfVjLC0EfboFn3kEkg
> +c39M8Bm4GlkQvB1Wr37AEPn/m0PYbsC2lOEQL/04QRGiAcDTtjo4bzzsKb6yFFi
> cWg8mUsldcSikZB+YFVS0RRLGcKCWhOVHxxMqKlA/IdzBU02JiGaYqZU9SKaakkc
> 8AEFJkQdUYerh4BPeiwlzpy4uS3kiJU7A8hKnQSIuRR1xo7r28NKuvrxLnw5b3es
> kExf4pyb5zitBPx6c0ERQ1SJrw9VU3DipJb6dY/QW5uceHvfJlYQiXN6nGGKUkvw
> FlupnGef8TvHvgnHieiD9t3WRh+7WNKdMCs627U/Ym8VC0gcTXK3WORMdwrAVq7j
> I7wEkXH4ms9sJD09ZGysNjlRylKvMzHlxxIjl3kpFmvGwus//BxMq8GCT+08cJ9Z
> 5AOnYo5AWqWqa8nipilZ
> =dpSm
> -----END PGP SIGNATURE-----
> _______________________________________________
> dnsext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsext
_______________________________________________
dnsext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsext