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

[Mohan Parthasarathy <[e-mail]>]

On Wed, Feb 8, 2012 at 3:05 PM, Mark Andrews <[e-mail]> wrote:
>
> In message <CACU5sDk8zGPF-w5BpBG21tNW1s0mpCEUP=[e-mail]>,
>  Mohan Parthasarathy writes:
>> On Wed, Feb 8, 2012 at 12:30 AM, W.C.A. Wijngaards <[e-mail]> wr=
>> ote:
>> > -----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. =A0There 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]> wrot=
>> e:
>> >>> At 16:34 +0100 2/7/12, W.C.A. Wijngaards wrote:
>> >>>
>> >>>> insecure, or bogus. =A0Note 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". =A0For the global public Internet, t=
>> he DNS
>> >>> in common use does have a trust anchor for it's root zone so the assert=
>> ion
>> >>> holds for the majority of cases, but then again only for recursive serv=
>> ers
>> >>> that have the trust anchor.
>> >>>
>> >>> There are other inter-networks that use the DNS protocol. =A0In at leas=
>> t one
>> >>> of these, DNSSEC has not been deployed.
>> >>>
>> >>> And, you can stretch this to the case of a recursive server, on the glo=
>> bal
>> >>> public Internet, that does not have the root anchor configured - and may
>> >>> have another anchor. =A0To such a server, validating some DNS data is
>> >>> impossible (incalculable).
>> >>>
>> >>> The protocol cannot be defined assuming one particular mode of operatio=
>> n.
>> >>>
>> >> 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. =A0This
>> > 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. =A0And the results are bogus, bogus, secure. =A0If you find an insecu=
>> re
>> > delegation it is insecure. =A0If 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.
>
> Absolutely wrong.
>
> Step 1 of validation.
> Is there a potential covering trust anchor?
>        Yes.  Goto step 2.
>        No.  Mark as insecure.
>
> Step 2 ....
>
>From RFC 4033:

Insecure: The validating resolver has a trust anchor, a chain of
      trust, and, at some delegation point, signed proof of the
      non-existence of a DS record.  This indicates that subsequent
      branches in the tree are provably insecure.  A validating resolver
      may have a local policy to mark parts of the domain space as
      insecure.

So, I don't understand what you mean.

-mohan



>>  <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. =A0And 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. =A0Data that
>> > is secure and data that is not DNSSEC signed is what it wants. =A0Because
>> > 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. =A0This 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. =A0But 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. =A0This 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,
>> > =A0 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
>> > =3DdpSm
>> > -----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
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: [phone]                 INTERNET: [e-mail]
_______________________________________________
dnsext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsext