Re: [dnsext] resolving IESG comments on draft-ietf-dnsext-dnssec-bis-updates

On Jul 11, 2012, at 12:06 AM, Patrik Fältström wrote:

> 
> On 10 jul 2012, at 16:50, Paul Hoffman wrote:
> 
>> The amount of differing opinions about the four states *even among DNSSEC-knowledgeable people* in that thread and others was significant.
> 
> The big difference is between people that do think it is a good thing that people in X.509 world themselves can "click" on "continue anyways" on a validation failure.

That is *not* where the difference of opinions about DNSSEC were. The differences were about what specific events constitute bogus versus indeterminate or insecure. There were good reasons for the WG to differentiate between bogus and indeterminate/insecure, but the DNSSEC documents had places of unclarity, including two different definitions of "bogus".

> I think personally it is *feature* that with DNSSEC a validator by default do not return anything if validation fails for some reasons, and the end user can not do anything at all about it (part from running its own resolver etc etc).
> 
> But I do understand other people do have other views.

Exactly. The "other views" from different people who the community thinks understand DNSSEC made it hard for us to know what to put in our document. Thus, the request for clarity in *this* document.

> Because of this, for me, a no-response in DANE is the same as failed validation, and such a failure that the end user/application should not continue. At all. No "continue anyway" etc.

This view ignores the fact that PKIX has its own protections to which DANE is adding value. It is fine if this WG wants to say in dnssec-bis-updates that other protocols that want to add value with DNSSEC should fail to less than the protocol if DNSSEC does not return "secure", and it is fine if this WG wants to say that "we aren't going to specify what other protocols will do", but the current DNSSEC documents do neither.

> Giving the ability "to continue" opens the door for denial of service attacks as a way to circumvent DANE security.
> 
> So to me there are three states only.
> 
> - No DANE in use
> - DANE in use, validation succeeds
> - All other cases

If you want to change DANE, please so do in the DANE WG. The thread here is about making the DNSSEC document clearer for other WGs who will want to use DNSSEC. If the DNSSEC spec had been clearer on what bogus means and what the expectation of the IETF is for why there is a difference between insecure and indeterminate, the DANE WG discussion would have gone *much* better.

--Paul Hoffman

_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext