Florian Weimer:
> > I exposed these two options in Postfix configuration using the
> > existing names and semantics, so that users would not need to learn
> > different names with different semantics. Humans have better things
> > to do than riding bikes with a reversed steering mechanism.
>
>
* Wietse Venema:
>> This is an interesting data point because the interaction between
>> RES_DEFNAMES, RES_DNSRCH, and the ndots and no-tld-query options are
>> far from obvious. Even the exact impact of RES_DEFNAMES and
>> RES_DNSRCH probably varies between code written from scratch and the
>>
Florian Weimer:
> * Wietse Venema:
>
> > Florian Weimer:
> >> * Wietse Venema:
> >>
> >> > Florian Weimer:
> >> >> * Wietse Venema:
> >> >>
> >> >> > Florian Weimer:
> >> >> >> * Rich Felker:
> >> >> >>
> >> >> >> > A solution that would work with existing and future versions of
> >> >> >> >
* Wietse Venema:
> Florian Weimer:
>> * Wietse Venema:
>>
>> > Florian Weimer:
>> >> * Wietse Venema:
>> >>
>> >> > Florian Weimer:
>> >> >> * Rich Felker:
>> >> >>
>> >> >> > A solution that would work with existing and future versions of musl
>> >> >> > as well as glibc, and would (I think)
Florian Weimer:
> * Wietse Venema:
>
> > Florian Weimer:
> >> * Wietse Venema:
> >>
> >> > Florian Weimer:
> >> >> * Rich Felker:
> >> >>
> >> >> > A solution that would work with existing and future versions of musl
> >> >> > as well as glibc, and would (I think) avoid the need to poke at _res
* Wietse Venema:
> Florian Weimer:
>> * Wietse Venema:
>>
>> > Florian Weimer:
>> >> * Rich Felker:
>> >>
>> >> > A solution that would work with existing and future versions of musl
>> >> > as well as glibc, and would (I think) avoid the need to poke at _res
>> >> > to set the glibc trustad
Florian Weimer:
> * Wietse Venema:
>
> > Florian Weimer:
> >> * Rich Felker:
> >>
> >> > A solution that would work with existing and future versions of musl
> >> > as well as glibc, and would (I think) avoid the need to poke at _res
> >> > to set the glibc trustad flag, would be replacing the
* Wietse Venema:
> Florian Weimer:
>> * Rich Felker:
>>
>> > A solution that would work with existing and future versions of musl
>> > as well as glibc, and would (I think) avoid the need to poke at _res
>> > to set the glibc trustad flag, would be replacing the call to
>> > res_query with
Florian Weimer:
> * Rich Felker:
>
> > A solution that would work with existing and future versions of musl
> > as well as glibc, and would (I think) avoid the need to poke at _res
> > to set the glibc trustad flag, would be replacing the call to
> > res_query with res_mkquery, |='ing the AD bit
* Rich Felker:
> A solution that would work with existing and future versions of musl
> as well as glibc, and would (I think) avoid the need to poke at _res
> to set the glibc trustad flag, would be replacing the call to
> res_query with res_mkquery, |='ing the AD bit into place, then
> res_send.
On Sun, Apr 19, 2020 at 02:16:01PM -0400, Viktor Dukhovni wrote:
> On Sun, Apr 19, 2020 at 08:02:41PM +0200, Matus UHLAR - fantomas wrote:
>
> > On 19.04.20 13:11, Wietse Venema wrote:
> >
> > >Warning: libc-musl breaks DANE/TLSA security.
> > >Use a glibc-based Linux distribution instead.
> >
Matus UHLAR - fantomas:
> >Wietse Venema:
> >> Rich Felker:
> >> > > It would be a mistake to use TLSA records from an unsigned domain.
> >> > > That would be no more secure than accepting a random server
> >> > > certificate. All the pain of doing TLSA and none of the gain, just
> >> > > security
On 19 Apr 2020, at 12:16, @lbutlr wrote:
> It is secure
Sorry, I thought this was Opportunistic TLS.
--
I mistook thee for thy better Hamlet Act III scene 4
On 18 Apr 2020, at 11:04, Rich Felker wrote:
> It's not security theater because nobody's claiming it's secure.
> Rather it's a fairly weak form of hardening that increases the
> required capabilities an attacker needs to exploit a known-insecure
> system.
It is secure in the sense that the
On Sun, Apr 19, 2020 at 08:02:41PM +0200, Matus UHLAR - fantomas wrote:
> On 19.04.20 13:11, Wietse Venema wrote:
>
> >Warning: libc-musl breaks DANE/TLSA security.
> >Use a glibc-based Linux distribution instead.
> >Remove this test to build unsupported Postfix.
> >make: *** [Makefile:79:
Wietse Venema:
Rich Felker:
> > It would be a mistake to use TLSA records from an unsigned domain.
> > That would be no more secure than accepting a random server
> > certificate. All the pain of doing TLSA and none of the gain, just
> > security theatre.
>
> It's not security theater. It (1)
Wietse Venema:
> Rich Felker:
> > > It would be a mistake to use TLSA records from an unsigned domain.
> > > That would be no more secure than accepting a random server
> > > certificate. All the pain of doing TLSA and none of the gain, just
> > > security theatre.
> >
> > It's not security
On Sat, Apr 18, 2020 at 03:01:08PM -0400, Viktor Dukhovni wrote:
> On Sat, Apr 18, 2020 at 01:04:58PM -0400, Rich Felker wrote:
>
> > > You can consider libc-musl as unsupported from now on.
> >
> > I am really not appreciating the hostility and utterly petty
> > vindictiveness of folks from
On Sat, Apr 18, 2020 at 01:04:58PM -0400, Rich Felker wrote:
> It's not security theater because nobody's claiming it's secure.
> Rather it's a fairly weak form of hardening that increases the
> required capabilities an attacker needs to exploit a known-insecure
> system.
FWIW, Postfix in fact
On Sat, Apr 18, 2020 at 10:59:51AM -0400, Wietse Venema wrote:
> Rich Felker:
> > > It would be a mistake to use TLSA records from an unsigned domain.
> > > That would be no more secure than accepting a random server
> > > certificate. All the pain of doing TLSA and none of the gain, just
> > >
Rich Felker:
> > It would be a mistake to use TLSA records from an unsigned domain.
> > That would be no more secure than accepting a random server
> > certificate. All the pain of doing TLSA and none of the gain, just
> > security theatre.
>
> It's not security theater. It (1) ensures that you
On Fri, Apr 17, 2020 at 06:59:53PM -0400, Wietse Venema wrote:
> Rich Felker:
> > I can see where it could be desirable to log whether delivery was made
> > based on a TLSA record in a signed domain vs an unsigned one, and this
> > necessitates being able to see the AD bit or equivalent. But it
On Fri, Apr 17, 2020 at 07:27:58PM -0400, Rich Felker wrote:
> > No, I have not. Read my message again, then try:
> >
> > dig -t mx nist.gov
> > dig -t tlsa [_25._tcp.]nist-gov.mail.protection.outlook.com
>
> Missing the _25._tcp.
Yes.
> but either way it seems to be a misconfigured
On Fri, Apr 17, 2020 at 07:01:26PM -0400, Viktor Dukhovni wrote:
> On Fri, Apr 17, 2020 at 06:52:48PM -0400, Rich Felker wrote:
>
> > > There are (unsigned) domains where any attempt to look up TLSA records
> > > times out or otherwise fails. If DANE is to be downgrade-resistant, and
> > > if
Viktor Dukhovni:
> On Fri, Apr 17, 2020 at 06:46:27PM -0400, Wietse Venema wrote:
>
> > 1) Infrastructure mail server. DNS configuration is not supposed
> > to change. People who care about TLSA/DANE will provision a secure
> > and stable DNS resolver.
> >
> > 2) Personal laptop, roaming between
On Fri, Apr 17, 2020 at 06:52:48PM -0400, Rich Felker wrote:
> > There are (unsigned) domains where any attempt to look up TLSA records
> > times out or otherwise fails. If DANE is to be downgrade-resistant, and
> > if logging of DANE-verified connections is to mean anything in terms of
> >
Rich Felker:
> I can see where it could be desirable to log whether delivery was made
> based on a TLSA record in a signed domain vs an unsigned one, and this
> necessitates being able to see the AD bit or equivalent. But it does
> not justify dropping all protections if you can't see it, just
>
On Fri, Apr 17, 2020 at 06:46:27PM -0400, Wietse Venema wrote:
> 1) Infrastructure mail server. DNS configuration is not supposed
> to change. People who care about TLSA/DANE will provision a secure
> and stable DNS resolver.
>
> 2) Personal laptop, roaming between trusted and untrusted
On Fri, Apr 17, 2020 at 06:27:27PM -0400, Viktor Dukhovni wrote:
> On Fri, Apr 17, 2020 at 06:19:18PM -0400, Rich Felker wrote:
>
> > This reasoning is why I consider it harmful to limit use of DANE
> > records to situations where the DNS lookup is "trusted" to have been
> > validated -- it just
Viktor Dukhovni:
> > On Apr 17, 2020, at 5:21 PM, Wietse Venema wrote:
> >
> > Possibly, but rest assured that all such features will remain disabled
> > by default for at least one year after there is wide deployment of
> > code that manages the new resolv.conf flag, and there is a documented
On Fri, Apr 17, 2020 at 06:19:18PM -0400, Rich Felker wrote:
> This reasoning is why I consider it harmful to limit use of DANE
> records to situations where the DNS lookup is "trusted" to have been
> validated -- it just encourages flipping a switch to "trust" servers
> that shouldn't be
On Fri, Apr 17, 2020 at 08:13:52PM +0200, Florian Weimer wrote:
> * Wietse Venema:
>
> > Florian Weimer:
> >> * Wietse Venema:
> >>
> >> > Vladimir Lomov:
> >> >> I'm a bit bewildered. Does this mean that all is Ok with glibc 2.31 with
> >> >> 'options trust-ad' and postfix 3.5.0 or it is depend
> On Apr 17, 2020, at 5:21 PM, Wietse Venema wrote:
>
> Possibly, but rest assured that all such features will remain disabled
> by default for at least one year after there is wide deployment of
> code that manages the new resolv.conf flag, and there is a documented
> record of the new failure
Florian Weimer:
> If the administrator has enabled DANE, you could check whether
> RES_TRUSTAD is enabled, and if not, complain loudly that the
> configured name servers are not marked as trusted (and may not even
> support DNSSEC validation). This why we expose the RES_TRUSTAD flag
> via
On Fri, Apr 17, 2020 at 10:17:47PM +0200, Florian Weimer wrote:
> > With the Glibc change as the first step, we have no choice but to
> > restore the status quo ante.
>
> True, but there are different approaches.
>
> If the administrator has enabled DANE, you could check whether
> RES_TRUSTAD
* Viktor Dukhovni:
> The RFC requirement is more than optional, it is unrealistic. Doing
> DNSSEC-validation in each application is not practical, there is no
> broadly deployed (on all the BSDs, Linux, Solaris, ...) library that
> does this, and each application would potentially need its own
>
> On Apr 17, 2020, at 3:59 PM, Florian Weimer wrote:
>
> I don't think it's a gaping security hole. The scope of the flags
> change in dns_query is really small, so it affects that one query
> only. If some library used by Postfix depends on RES_TRUSTAD in its
> intended meaning, it will not
* Wietse Venema:
> Florian Weimer:
>> > My patch does not make security any worse than it was prior to
>> > GLIBC 2.31. This is all I can do for stable Postfix releases:
>> > ensure that shit does not stop working after an OS update.
>> >
>> > Any 'improvements' in Postfix DNSSEC support will
On Fri, Apr 17, 2020 at 08:13:52PM +0200, Florian Weimer wrote:
> > Correct. Until now, Postfix asserts RES_USE_DNSSEC to request
> > validation in a resolver.
>
> RES_USE_DNSSEC is unfortunately misnamed. [...]
Thanks, but neither Wietse nor I need a refresher on DNSSEC.
> > The sysadmin has
Florian Weimer:
> > My patch does not make security any worse than it was prior to
> > GLIBC 2.31. This is all I can do for stable Postfix releases:
> > ensure that shit does not stop working after an OS update.
> >
> > Any 'improvements' in Postfix DNSSEC support will have to be developed
> > in
* Wietse Venema:
> Florian Weimer:
>> * Wietse Venema:
>>
>> > Vladimir Lomov:
>> >> I'm a bit bewildered. Does this mean that all is Ok with glibc 2.31 with
>> >> 'options trust-ad' and postfix 3.5.0 or it is depend strongly on used
>> >> 'options'?
>> >
>> > This patch avoids the need to add
Scott Kitterman:
> On Thursday, April 16, 2020 10:31:56 AM EDT Wietse Venema wrote:
> > With the minnimal patch below, it looks like Postfix DANE support
> > will continue to work after a breaking change in Glibc 2.31. Tested
> > on Fedora 32 beta.
> >
> > This patch also deals with the 'multiple
On Thursday, April 16, 2020 10:31:56 AM EDT Wietse Venema wrote:
> With the minnimal patch below, it looks like Postfix DANE support
> will continue to work after a breaking change in Glibc 2.31. Tested
> on Fedora 32 beta.
>
> This patch also deals with the 'multiple definition' errors caused
>
@lbutlr:
> On 16 Apr 2020, at 13:27, Wietse Venema wrote:
> > Any 'improvements' in Postfix DNSSEC support will have to be developed
> > in the Postfix 3.6 release cycle. The results from those =
> 'improvements'
> > will never be merged back into Postfix 3.5 and earlier.
>
> Is this planned for
On 16 Apr 2020, at 13:27, Wietse Venema wrote:
> Any 'improvements' in Postfix DNSSEC support will have to be developed
> in the Postfix 3.6 release cycle. The results from those 'improvements'
> will never be merged back into Postfix 3.5 and earlier.
Is this planned for 3.6, or are you speaking
Florian Weimer:
> * Wietse Venema:
>
> > Vladimir Lomov:
> >> I'm a bit bewildered. Does this mean that all is Ok with glibc 2.31 with
> >> 'options trust-ad' and postfix 3.5.0 or it is depend strongly on used
> >> 'options'?
> >
> > This patch avoids the need to add options to resolv.conf.
>
>
* Wietse Venema:
> Vladimir Lomov:
>> I'm a bit bewildered. Does this mean that all is Ok with glibc 2.31 with
>> 'options trust-ad' and postfix 3.5.0 or it is depend strongly on used
>> 'options'?
>
> This patch avoids the need to add options to resolv.conf.
Does Postfix perform its own DNSSEC
Vladimir Lomov:
> I'm a bit bewildered. Does this mean that all is Ok with glibc 2.31 with
> 'options trust-ad' and postfix 3.5.0 or it is depend strongly on used
> 'options'?
This patch avoids the need to add options to resolv.conf.
Wietse
Hello,
** Wietse Venema [2020-04-16 10:31:56 -0400]:
> With the minnimal patch below, it looks like Postfix DANE support
> will continue to work after a breaking change in Glibc 2.31. Tested
> on Fedora 32 beta.
> This patch also deals with the 'multiple definition' errors caused
> by a
With the minnimal patch below, it looks like Postfix DANE support
will continue to work after a breaking change in Glibc 2.31. Tested
on Fedora 32 beta.
This patch also deals with the 'multiple definition' errors caused
by a breaking change in GCC 10. Also tested on Fedora 32 beta.
Plan is to
50 matches
Mail list logo
