Subject: Re: [dane] DNSSEC Optionality (was: New Version Notification for draft-ietf-dane-use-cases-03.txt)

From: =JeffH <[email-masked]>
Date: Wed, 15 Jun 2011 22:26:18 -0700

>> 1) Use of DANE without DNSSEC
 >
 > I added the paragraph you note to more correctly describe the impact of
 > using DANE without DNSSEC, as you, Jim, and Jeff all noted:
 > Wouters: http://www.ietf.org/mail-archive/web/dane/current/msg02559.html
 > Schaad: http://www.ietf.org/mail-archive/web/dane/current/msg02564.html
 > Hodges: http://www.ietf.org/mail-archive/web/dane/current/msg02579.html
 >
 > Can we agree that the current draft accurately describes the (admittedly
 > minor) effect of using DANE without DNSSEC?

I think it (the two new paras in S 3.1 CA Constraints) gets somewhat closer to 
accurate, though it's tough to read and puzzle out what it actually means. 
(yes, it's also tough to write about this gnarly stuff). (no time right now to 
word smith it though)

there's this key paragraph in S 3.1 sandwiched between the two new paragraphs...

 >    Because these constraints do not increase the scope of PKIX-based
 >    assertions about domains, there is not a strict requirement for
 >    DNSSEC.  Deletion of records removes the protection provided by this
 >    constraint, but the client is still protected by CA practices (as
 >    now).  Injected or modified false records are not useful unless the
 >    attacker can also obtain a certificate for the target domain.  In the
 >    worst case, tampering with these constraints increases the risk of
 >    false authentication to the level that is now standard.

I think part of our concerns is the first sentence..

 >    Because these constraints do not increase the scope of PKIX-based
 >    assertions about domains, there is not a strict requirement for
 >    DNSSEC.

..which is essentially stating a requirement. As I pointed out in my prior msg 
you cite above...

   I ... note that the security analysis of the S3.1 CA Constraints
   use case could be updated to not state a requirement (DNSSEC
   optionality), and to more thoroughly analyze the case (as they
   [PaulW & JimS] both have done).

I suggest finding a way to simply discuss, there in S3.1's analysis (or perhaps 
in a proper Security Considerations section), the pros and cons of whether 
DNSSEC is operationally employed or not. And not make a requirement statement 
on DNSSEC optionality.

Also, the last sentence in the above quoted para..

 >                                                                  In the
 >    worst case, tampering with these constraints increases the risk of
 >    false authentication to the level that is now standard.

..appears problematic in that not everyone believes that the level of "risk of 
false authentication" today is acceptable, which is sort of implied (it seems 
to me). Would be good to find a way to re-word this too.

Note as well that _until_ we can securely convey valid DNSSEC-signed DNS 
results directly to the application service component running on the end system 
(the so-called "DNSSEC last-mile problem"), use of DANE mechanisms even with 
DNSSEC will provide additional security ranging from "more" to "minimal/none" 
depending on all sorts of situational factors. This should be noted in security 
requirements.

=JeffH

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 16 Jun 2011 08:49:42 -0400

I agree, no need to make DNSSEC a MUST. I think that would be exceptionally
bad for deployment.

Just set out the consequences of not having DNSSEC in the Security
Considerations and in the introductory material.

On Thu, Jun 16, 2011 at 1:26 AM, =JeffH <[email-masked]>wrote:

> I think it (the two new paras in S 3.1 CA Constraints) gets somewhat closer
> to accurate, though it's tough to read and puzzle out what it actually
> means. (yes, it's also tough to write about this gnarly stuff). (no time
> right now to word smith it though)
>
> ..which is essentially stating a requirement. As I pointed out in my prior
> msg you cite above...
>
> I suggest finding a way to simply discuss, there in S3.1's analysis (or
> perhaps in a proper Security Considerations section), the pros and cons of
> whether DNSSEC is operationally employed or not. And not make a requirement
> statement on DNSSEC optionality.
>
> ..appears problematic in that not everyone believes that the level of "risk
> of false authentication" today is acceptable, which is sort of implied (it
> seems to me). Would be good to find a way to re-word this too.
>
> results directly to the application service component running on the end
> system (the so-called "DNSSEC last-mile problem"), use of DANE mechanisms
> even with DNSSEC will provide additional security ranging from "more" to
> "minimal/none" depending on all sorts of situational factors. This should be
> noted in security requirements.
>
> =JeffH
>
>
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

-- 
Website: http://hallambaker.com/

---

From: Paul Wouters <[email-masked]>
Date: Thu, 16 Jun 2011 10:50:53 -0400 (EDT)

> noted in security requirements.

Note that it seems that currently, browsers will be the first app to take
DNSSEC processing with them to the user, due to the lack of guarantee
for DNSSEC in the OS.

I think for the browser case, the majority of TLS, no one will ever use
non-DNSSEC secured DANE records, whether we allow these to go into the
user-case document or not. It's just not worth the potential risks.

I really hope the use-cases can make a simple a clear statement to
application developers to not use DANE without DNSSEC protection. Writing
up convoluted marginalised use cases where it could theoretically be
useful would cause more damage by badly written implementations that
got it wrong.

Keep it simple. If you are using cryptographic material to base decisions
on, you must be able to make a minimum assertion of trust on it.

Paul

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 20 Jun 2011 10:54:25 -0400

On 16/06/2011 1:26 AM, =JeffH wrote:
> I think it (the two new paras in S 3.1 CA Constraints) gets somewhat
> closer to accurate, though it's tough to read and puzzle out what it
> actually means. (yes, it's also tough to write about this gnarly stuff).
> (no time right now to word smith it though)
>

When reading the above text I can not determine which one of the 
following two is the guidance:
a) the zone publishing the DANE record does not need to be signed
b) the DANE record does not need to be DNSSEC validated.

	Olafur