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

["W.C.A. Wijngaards" <[e-mail]>]

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

At any step, if the algorithm, that is validating the chain of trust
from a trust anchor to the data, knows that it must have DNSSEC data,
but this is not available, the result becomes bogus.  Why the data is
not available does not matter.  The algorithm knows if DNSSEC data must
be available, because this is what NSEC and DS records tell at
delegation points.

DNSSEC has the interesting property that it can tell if a zone is signed
or not.  And it can do so securely.  This is very nice for backwards
compatibility.  And it solves all of the things you ask for.

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

> Some RRSet needs to be validated. The RRSet was fetched with the DO bit set.
> 
> - We are able to get the RRSIGs back for the RRset. But unable to
> validate completely because we are not able to get the DNSKEY RRSET or
> not able to fetch the DS record. Going by 4035, this is Insecure. Two

No, it is bogus.  If you cannot get the DS and DNSKEY records, the
result is bogus.

> problems here. First, it is also possible that you talked to the
> DNSSEC-unaware server which does not know how to fetch the DS record.
> Secondly, this could be a fake signature for which you can never
> establish the trust. Do we want to declare Insecure in both these
> cases ?

It is not important if the upstream server is DNSSEC unaware or if it is
lying.  If you cannot get the proper DNSSEC data the result is bogus.

> - We are able to get the RRSIGs back for the RRSet. But unable to
> validate the signatures because it is expired. This is Bogus as per
> 4035.

Yes, expired is bogus.

> - We are unable to get the RRSIGs back, but we got some response from
> the server i.e., the main RRSet itself. Missing signatures. As per
> 4035, this is Bogus. But then this could be a bad CPE. Do we want to
> declare this Bogus ?

Yes it is bogus.

I understand the definition of Indeterminate is wrong in 4035; but no,
downgrade attacks by the removal of DNSSEC data result in bogus.  There
are no excuses (i.e. being a CPE, being old, or being unaware) that
would make the result non-bogus.

> We can create more examples, but it looks to me that there are only
> two error cases.
> 
> 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).

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