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

[Mark Andrews <[e-mail]>]

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 ....

>  <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