Update to DNSSEC design document.

Update to DNSSEC design document.

[Carlos O'Donell]

This is not for 2.23, but I wanted to mention this update:

https://sourceware.org/glibc/wiki/DNSSEC

I have spent significant amounts of time with the Fedora
and RHEL distribution teams talking about potential solutions.

The most relevant change is that in order to support truly
fail-safe configurations we're going to suggest the solution
clean the AD-bit in responses by default, with the distribution
being in charge to setup a validating resolver configuration
(various distribution-level choices including a fixed nscd) after
which an option is set in /etc/resolv.conf. From that point on
the AD-bit is forwarded to applications. This makes creating a
fail-safe configuration very flexible and distributions can
choose exactly how they accomplish ensuring there is trust for
the entries in /etc/resolv.conf.

I believe I have a conversation thread with Zack Weinberg that
I still have to finish.

Cheers,
Carlos.

Re: Update to DNSSEC design document.

[Rich Felker]

On Wed, Jan 27, 2016 at 12:30:28PM -0500, Carlos O'Donell wrote:
> This is not for 2.23, but I wanted to mention this update:
> 
> https://sourceware.org/glibc/wiki/DNSSEC
> 
> I have spent significant amounts of time with the Fedora
> and RHEL distribution teams talking about potential solutions.
> 
> The most relevant change is that in order to support truly
> fail-safe configurations we're going to suggest the solution
> clean the AD-bit in responses by default, with the distribution
> being in charge to setup a validating resolver configuration
> (various distribution-level choices including a fixed nscd) after
> which an option is set in /etc/resolv.conf. From that point on
> the AD-bit is forwarded to applications. This makes creating a
> fail-safe configuration very flexible and distributions can
> choose exactly how they accomplish ensuring there is trust for
> the entries in /etc/resolv.conf.
> 
> I believe I have a conversation thread with Zack Weinberg that
> I still have to finish.

I think the policy around AD bit needs serious reconsideration. The
main/only use of AD bit in applications makes clearing it fail-open
rather than fail-safe. In particular, for DANE, which is really the
only situation where you need to distinguish insecure vs authenticated
zone rather than just trusting the nameserver not to give you forged
data for authenticated zones, AD bit set means "honor DANE records for
this domain" and AD bit clear means "ignore DANE records for this
domain". By stripping AD, glibc is making policy more permissive, and
making applications silently fail to honor an essential security
property.

Rich

Re: Update to DNSSEC design document.

[Rich Felker]

On Wed, May 20, 2020 at 01:36:43PM -0400, Rich Felker wrote:
> On Wed, Jan 27, 2016 at 12:30:28PM -0500, Carlos O'Donell wrote:
> > This is not for 2.23, but I wanted to mention this update:
> > 
> > https://sourceware.org/glibc/wiki/DNSSEC
> > 
> > I have spent significant amounts of time with the Fedora
> > and RHEL distribution teams talking about potential solutions.
> > 
> > The most relevant change is that in order to support truly
> > fail-safe configurations we're going to suggest the solution
> > clean the AD-bit in responses by default, with the distribution
> > being in charge to setup a validating resolver configuration
> > (various distribution-level choices including a fixed nscd) after
> > which an option is set in /etc/resolv.conf. From that point on
> > the AD-bit is forwarded to applications. This makes creating a
> > fail-safe configuration very flexible and distributions can
> > choose exactly how they accomplish ensuring there is trust for
> > the entries in /etc/resolv.conf.
> > 
> > I believe I have a conversation thread with Zack Weinberg that
> > I still have to finish.
> 
> I think the policy around AD bit needs serious reconsideration. The
> main/only use of AD bit in applications makes clearing it fail-open
> rather than fail-safe. In particular, for DANE, which is really the
> only situation where you need to distinguish insecure vs authenticated
> zone rather than just trusting the nameserver not to give you forged
> data for authenticated zones, AD bit set means "honor DANE records for
> this domain" and AD bit clear means "ignore DANE records for this
> domain". By stripping AD, glibc is making policy more permissive, and
> making applications silently fail to honor an essential security
> property.

Uhg sorry, I don't know how I managed to make this a reply to such an
old thread. I thought I was replying to something newer. In any case,
the topic is relevant once again...

Rich

Re: Update to DNSSEC design document.

[Petr Špaček]

On 20. 05. 20 19:36, Rich Felker wrote:
> On Wed, Jan 27, 2016 at 12:30:28PM -0500, Carlos O'Donell wrote:
>> This is not for 2.23, but I wanted to mention this update:
>>
>> https://sourceware.org/glibc/wiki/DNSSEC
>>
>> I have spent significant amounts of time with the Fedora
>> and RHEL distribution teams talking about potential solutions.
>>
>> The most relevant change is that in order to support truly
>> fail-safe configurations we're going to suggest the solution
>> clean the AD-bit in responses by default, with the distribution
>> being in charge to setup a validating resolver configuration
>> (various distribution-level choices including a fixed nscd) after
>> which an option is set in /etc/resolv.conf. From that point on
>> the AD-bit is forwarded to applications. This makes creating a
>> fail-safe configuration very flexible and distributions can
>> choose exactly how they accomplish ensuring there is trust for
>> the entries in /etc/resolv.conf.
>>
>> I believe I have a conversation thread with Zack Weinberg that
>> I still have to finish.
> 
> I think the policy around AD bit needs serious reconsideration. The
> main/only use of AD bit in applications makes clearing it fail-open
> rather than fail-safe. In particular, for DANE, which is really the
> only situation where you need to distinguish insecure vs authenticated
> zone rather than just trusting the nameserver not to give you forged
> data for authenticated zones, AD bit set means "honor DANE records for
> this domain" and AD bit clear means "ignore DANE records for this
> domain". By stripping AD, glibc is making policy more permissive, and
> making applications silently fail to honor an essential security
> property.

I do not agree with this view.

In my optinion:
- AD bit stripping ensures the application can trust the answer (which is exactly tu purpose of AD bit).
- Without AD bit stripping the application is potentially exposed to any attacker who can spoof DNS answers.

E-mail example *without* AD bit stripping:
1. Attacker spoofs IP address of target e-mail server. Now e-mail is being delivered to attacker's IP address.
2. Attacker spoofs TLSA answer for target domain with AD=1. Now client e-mail software was fooled to think that attacker-provided cert in the fake TLSA record is valid for target domain.

In other words not stripping AD bit means that attacker can spoof everything making it undetectable in client application.

I really cannot see how it is better than stripping by default, which allows the application to detect that something in DNSSEC validation chain is not configured properly. (Possibly misconfigured resolv.conf.)

What is you counterproposal?

-- 
Petr Špaček  @  CZ.NIC

Re: Update to DNSSEC design document.

[Alexander Monakov]

On Thu, 21 May 2020, Petr Špaček wrote:

> In my optinion:
> - AD bit stripping ensures the application can trust the answer (which is
> exactly tu purpose of AD bit).

I don't see how absence of AD bit implies that the application can trust the
answer, and I think you and Rich are talking from different standpoints here.

I apologize if I misunderstand something, but let me summarize in simpler
terms what I imagine is being said:

I think your position is that if the applications sees the AD bit,
then there is some code (in the resolver library, probably) that has already
verified the answer, and would clear the AD bit if it could not be verified.

I think Rich is talking from the standpoint that if the application sees the AD
bit, then an authoritative server has set the AD bit in accordance to RFC 3655
section 2.2 and is thus requesting the recipients to verify it. After seeing the
AD bit, the application should honor the request and verify the answer. Not sure
what API could be used for this purpose.

Again, I am probably missing some very essential details here, and even might be
misrepresenting what either of you said. I think your standpoints are so
different though, it helps to clarify the overall idea before arguing the
details.

Alexander

Re: Update to DNSSEC design document.

[Petr Špaček]

On 21. 05. 20 10:27, Alexander Monakov wrote:
> On Thu, 21 May 2020, Petr Špaček wrote:
> 
>> In my optinion:
>> - AD bit stripping ensures the application can trust the answer (which is
>> exactly tu purpose of AD bit).
> 
> I don't see how absence of AD bit implies that the application can trust the
> answer, and I think you and Rich are talking from different standpoints here.

No, this is misunderstandig. It is exactly the opposite, see below.


> I apologize if I misunderstand something, but let me summarize in simpler
> terms what I imagine is being said:
> 
> I think your position is that if the applications sees the AD bit,
> then there is some code (in the resolver library, probably) that has already
> verified the answer, and would clear the AD bit if it could not be verified.

Yes, this is how DNSSEC is defined _in 2020_, see below.


> I think Rich is talking from the standpoint that if the application sees the AD
> bit, then an authoritative server has set the AD bit in accordance to RFC 3655
> section 2.2 and is thus requesting the recipients to verify it. After seeing the
> AD bit, the application should honor the request and verify the answer. Not sure
> what API could be used for this purpose.

RFC 3655 is obsolete for 15 years now, forgot about it. It was replaced in 2005 by RFCs 4033-4035. AD bit meaning is defined in https://tools.ietf.org/html/rfc4035#section-3.2.3:

3.2.3.  The AD Bit

   The name server side of a security-aware recursive name server MUST
   NOT set the AD bit in a response unless the name server considers all
   RRsets in the Answer and Authority sections of the response to be
   authentic. ...

It was later clarified (but not changed since 2005) in https://tools.ietf.org/html/rfc6840#section-5.8 but that does not change its meaning on receiving side.


> Again, I am probably missing some very essential details here, and even might be
> misrepresenting what either of you said. I think your standpoints are so
> different though, it helps to clarify the overall idea before arguing the
> details.

I'm trying to say that DNSSEC-enabled resolver determies the bit and application can rely on it _as long as it can be sure it was set by a trusted DNSSEC-validating resolver and not modified in transit_. And this is exactly the purpose of AD bit stripping.

Does it clarify my view?

-- 
Petr Špaček  @  CZ.NIC

Re: Update to DNSSEC design document.

[Carlos O'Donell]

On 5/21/20 4:48 AM, Petr Špaček wrote:
> On 21. 05. 20 10:27, Alexander Monakov wrote:
>> On Thu, 21 May 2020, Petr Špaček wrote:
>>
>>> In my optinion:
>>> - AD bit stripping ensures the application can trust the answer (which is
>>> exactly tu purpose of AD bit).
>>
>> I don't see how absence of AD bit implies that the application can trust the
>> answer, and I think you and Rich are talking from different standpoints here.
> 
> No, this is misunderstandig. It is exactly the opposite, see below.

I've updated the wiki to indicate the RES_TRUSTAD feature was released
in glibc 2.31 on 2020-02-01.

We should start a distinct thread to discuss specific issues.

Such discussions should start from first principles, point out relevant
standards (as are pointed out in this discussion, thank you Petr), and
why the glibc implementation has a particular failing, and what an
alternative solution would look like.

Thanks.

-- 
Cheers,
Carlos.

Re: Update to DNSSEC design document.

[Rich Felker]

On Thu, May 21, 2020 at 11:23:43AM -0400, Carlos O'Donell via Libc-alpha wrote:
> On 5/21/20 4:48 AM, Petr Špaček wrote:
> > On 21. 05. 20 10:27, Alexander Monakov wrote:
> >> On Thu, 21 May 2020, Petr Špaček wrote:
> >>
> >>> In my optinion:
> >>> - AD bit stripping ensures the application can trust the answer (which is
> >>> exactly tu purpose of AD bit).
> >>
> >> I don't see how absence of AD bit implies that the application can trust the
> >> answer, and I think you and Rich are talking from different standpoints here.
> > 
> > No, this is misunderstandig. It is exactly the opposite, see below.
> 
> I've updated the wiki to indicate the RES_TRUSTAD feature was released
> in glibc 2.31 on 2020-02-01.
> 
> We should start a distinct thread to discuss specific issues.
> 
> Such discussions should start from first principles, point out relevant
> standards (as are pointed out in this discussion, thank you Petr), and
> why the glibc implementation has a particular failing, and what an
> alternative solution would look like.

Indeed, I feel like a much deeper introduction to the topic is
necessary to discuss this because nobody is on the same page about the
basics of how DNSSEC works, how the AD bit is specified to work, and
what the intended (and actual) roles of stub resolver, trusted local
resolver, and untrusted resolver are. In particular I think my concern
was not well-received because of serious misconceptions about what the
AD bit is useful for in applications that make DNS queries via the
stub resolver.

Rich

Re: Update to DNSSEC design document.

[Rich Felker]

On Thu, May 21, 2020 at 09:33:21AM +0200, Petr Špaček wrote:
> On 20. 05. 20 19:36, Rich Felker wrote:
> > On Wed, Jan 27, 2016 at 12:30:28PM -0500, Carlos O'Donell wrote:
> >> This is not for 2.23, but I wanted to mention this update:
> >>
> >> https://sourceware.org/glibc/wiki/DNSSEC
> >>
> >> I have spent significant amounts of time with the Fedora
> >> and RHEL distribution teams talking about potential solutions.
> >>
> >> The most relevant change is that in order to support truly
> >> fail-safe configurations we're going to suggest the solution
> >> clean the AD-bit in responses by default, with the distribution
> >> being in charge to setup a validating resolver configuration
> >> (various distribution-level choices including a fixed nscd) after
> >> which an option is set in /etc/resolv.conf. From that point on
> >> the AD-bit is forwarded to applications. This makes creating a
> >> fail-safe configuration very flexible and distributions can
> >> choose exactly how they accomplish ensuring there is trust for
> >> the entries in /etc/resolv.conf.
> >>
> >> I believe I have a conversation thread with Zack Weinberg that
> >> I still have to finish.
> > 
> > I think the policy around AD bit needs serious reconsideration. The
> > main/only use of AD bit in applications makes clearing it fail-open
> > rather than fail-safe. In particular, for DANE, which is really the
> > only situation where you need to distinguish insecure vs authenticated
> > zone rather than just trusting the nameserver not to give you forged
> > data for authenticated zones, AD bit set means "honor DANE records for
> > this domain" and AD bit clear means "ignore DANE records for this
> > domain". By stripping AD, glibc is making policy more permissive, and
> > making applications silently fail to honor an essential security
> > property.
> 
> I do not agree with this view.
> 
> In my optinion:
> - AD bit stripping ensures the application can trust the answer
> (which is exactly tu purpose of AD bit).

With or without AD stripping, the application can trust the answer
precisely to the extent that the configured nameserver is trusted. AD
stripping has no bearing on that whatsoever.

> - Without AD bit stripping the application is potentially exposed to
> any attacker who can spoof DNS answers.

This is false, or at least misleading by not specifying *at what
point* in the flow the attacker can spoof.

If they can spoof between the stub resolver (glibc) and the configured
nameserver, the application is exposed to forged replies *regardless*
of AD stripping.

If they can only spoof between the configured nameserver and upstream
internet, then they can forge only insecure zones (insecure means
provably-insecure).

In your examples, it looks like you're assuming they can spoof between
stub and configured nameserver:

> E-mail example *without* AD bit stripping:
> 1. Attacker spoofs IP address of target e-mail server. Now e-mail is
> being delivered to attacker's IP address.
> 2. Attacker spoofs TLSA answer for target domain with AD=1. Now
> client e-mail software was fooled to think that attacker-provided
> cert in the fake TLSA record is valid for target domain.

With AD stripping it's even easier: TLSA will not be checked at all.
The attacker doesn't even need to spoof it.

Your misconception here is that lack of AD bit will prevent delivery.
That couldn't be further from the truth. Instead, lack of AD bit tells
the client "the operator of this domain does not care; you can happily
deliver in cleartest".

> In other words not stripping AD bit means that attacker can spoof
> everything making it undetectable in client application.

No, stripping AD means that.

> I really cannot see how it is better than stripping by default,
> which allows the application to detect that something in DNSSEC
> validation chain is not configured properly. (Possibly misconfigured
> resolv.conf.)

Lack of AD bit does not mean that something in the DNSSEC validation
chain was misconfigured. It means that the queried zone was insecure
(not protected by DNSSEC).

> What is you counterproposal?

Stop stripping AD. It's strictly harmful. There is no case where it
improves security. Document that, to prevent forgery, you need to
trust the configured nameserver and the route to it and that the
recommended usage is to run a DNSSEC-validating nameserver on
localhost.

Rich

Re: Update to DNSSEC design document.

[Aurelien Jarno]

On 2020-05-22 11:21, Rich Felker wrote:
> > - Without AD bit stripping the application is potentially exposed to
> > any attacker who can spoof DNS answers.
> 
> This is false, or at least misleading by not specifying *at what
> point* in the flow the attacker can spoof.
> 
> If they can spoof between the stub resolver (glibc) and the configured
> nameserver, the application is exposed to forged replies *regardless*
> of AD stripping.
> 
> If they can only spoof between the configured nameserver and upstream
> internet, then they can forge only insecure zones (insecure means
> provably-insecure).
> 
> In your examples, it looks like you're assuming they can spoof between
> stub and configured nameserver:
> 
> > E-mail example *without* AD bit stripping:
> > 1. Attacker spoofs IP address of target e-mail server. Now e-mail is
> > being delivered to attacker's IP address.
> > 2. Attacker spoofs TLSA answer for target domain with AD=1. Now
> > client e-mail software was fooled to think that attacker-provided
> > cert in the fake TLSA record is valid for target domain.
> 
> With AD stripping it's even easier: TLSA will not be checked at all.
> The attacker doesn't even need to spoof it.
> 
> Your misconception here is that lack of AD bit will prevent delivery.
> That couldn't be further from the truth. Instead, lack of AD bit tells
> the client "the operator of this domain does not care; you can happily
> deliver in cleartest".

I fully agree that stripping the AD bit is harmful in case of an SMTP
server using DANE.

Now this is not the only DNSSEC usage. For example DNSSEC can be used to
secure SSHFP keys when the VerifyHostKeyDNS option is enabled. When the
AD bit is not set, either because the domain doesn't use DNSSEC or
because it has been stripped, ssh falls back to another verification
method (usually asking the user). In that case keeping the AD bit set
even for an untrusted recursive resolver, *is* harmful as it means the
SSHFP keys are accepted without further check. Stripping it means that
ssh will ask the user for confirmation.

Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net