Re: Finding source of illegal address from localhost
On 2014-02-24 john wrote: > I have the following log entry: > (Slightly modified to protect the innocent, changed actual name to > user and domain to example) > > " 2014-02-24T16:45:12.836244+11:00 penguin postfix/smtpd[6520]: > warning: Illegal address syntax from localhost[127.0.0.1] in MAIL > command: <-timeshare.escape.artist-user=example@atcturbo.com> " The leading hyphen is what makes the address illegal. To allow addresses starting with a hyphen set "allow_min_user = yes" in main.cf. http://www.postfix.org/postconf.5.html#allow_min_user Regards Ansgar Wiechers -- "Abstractions save us time working, but they don't save us time learning." --Joel Spolsky
Re: TLS client logging PATCH
On Mon, 24 Feb 2014, Viktor Dukhovni wrote: I know that there are many side-effects and things which don't work, but that does not mean that one can at least try? Sorry, no half-assed solutions that work only sometimes and break unpredictably. Yes, the same story again. When it does not work everywhere then we don't do it at all. Oh yes - DNSSEC. When will it come? In hundred years? Available today. Two of my domains are signed, the third will be shortly. And you're complaining about people being complacent and stuck in the past. I don't want to have a perfection box which can't communicate with the rest of the world, but something which helps with todays internet. 3) with a known cert Replace "known" with "valid trust chain", and Postfix logs this as "Trusted". As you already pointed out "Any known cert" is nearly as meaningless as "unchecked". 4) with a trusted cert matching the hostname This is meaningless. The MX host is insecure. Many MX hosts have certs that don't match their name. And there are hosts where everything matches. Why not show it for these? 5) with a trusted cert matching the hostname + hostname == reverse DNS This is even more meaningless. It is an additional level of security. Only a very small bit, yes, but it needs another thing an attacker needs to fix. Couldn't postfix give something like a score for TLS security: - 0% if unencrypted - +5% when encrypted - +5% if proper algorithm - +5% if PFS is used - +5% when cert is trusted - +5% when cert also matches the MX - ... - 95% for DANE. Yes, we stay below 30% for current setup, but at least you could evaluate individual connections. What harm does it to call some checks and output the results? They are already in the code, but only used in the perfect environments. I took a lot of time to figure out how to properly setup certificates including ca chain, but actually I could have saved that time, because it makes no difference. I'm doing a lot in spamfiltering and there these score systems are a big benefit. 6) DNSSEC whatever else there is... Postfix 2.11 supports DANE, DANE actually scales, because policy for each domain is published by that domain. DANE removes the panoply of ~600 widely used CAs from the picture. If you want secure SMTP transport, direct your efforts at DNSSEC, and then publish TLSA records for your domain. Oh, I'll try, but I doubt I will get this done in the next 2 years. My Registrar said today: "Sorry, currently it is not possible to use DNSSec for domains registered here." But if I understand it right even if I do all perfect and hope that more systems support that secure approach - I need to configure each system supporting this individually by hand without any automatic aid in my own system? And then I need to hope that users start to use that information, because all this work is completely useless until 100% deployed. My 100 years guess aren't so bad I think. Very unlikely, that this approach will work. Ciao -- http://www.dstoecker.eu/ (PGP key available)
Heuristics are not security (was: TLS client logging PATCH)
Dirk St?cker: > >> 5) with a trusted cert matching the hostname + hostname == reverse DNS > > > > This is even more meaningless. > > It is an additional level of security. Only a very small bit, yes, but it PLEASE DO NOT call this "security". This stuff is weaker than spam filter heuristics, and no competent person calls THAT security. At best these observations can provide a record of how mail is being handled over time. Postfix can log some of that information. The absence of observed variation does not mean nothing of relevance has changed, and the presence of benign observed changes drowns out the malicious ones, assuming that the malicious party is stupid enough to reveal itself. This is not a sound basis for automatic policy enforcement or claims about "email security level" except at perhaps trivial scales. Wietse
Re: TLS client logging PATCH
On Mon, Feb 24, 2014 at 12:26:42PM +0100, Dirk St?cker wrote: > > >Oh yes - DNSSEC. When will it come? In hundred years? > > > >Available today. Two of my domains are signed, the third will be > >shortly. And you're complaining about people being complacent and > >stuck in the past. > > I don't want to have a perfection box which can't communicate with > the rest of the world, but something which helps with todays > internet. Nonsense. Patrick Koetter's .de domain is DNSSEC signed. His mailserver has TLSA records. Enabling DNSSEC does not prevent you from communicating with the rest of the world. Furthermore, you can enable DNSSEC validation in your resolver before your own domain is signed. The two are independent. > >If you want secure SMTP transport, direct your efforts at DNSSEC, > >and then publish TLSA records for your domain. > > Oh, I'll try, but I doubt I will get this done in the next 2 years. It only takes a few minutes to configure a validating recursive resolver. Install unbound and make sure it performs automatic tracking of the root zone DNSKEY. > My Registrar said today: > "Sorry, currently it is not possible to use DNSSec for domains > registered here." Vote with your feet. I'm transferring my domains to a registrar with better DNSSEC support (and incidentally lower price). > But if I understand it right even if I do all perfect and hope that > more systems support that secure approach - I need to configure each > system supporting this individually by hand without any automatic > aid in my own system? No. DANE does not require per-destination configuration. That's the point. > And then I need to hope that users start to use that information, > because all this work is completely useless until 100% deployed. My > 100 years guess aren't so bad I think. Very unlikely, that this > approach will work. No, DANE secures SMTP transport between publishing servers and validating clients regardless of what everyone else is doing. The adoption model is incremental. -- Viktor.
reject_unverified_recipient with .forward file
Hello, I am using reject_unverified_recipient to reject undeliverable addresses on our hosts. We are using postfix with cyrus as imap server. I have a question regarding the reject_unverified_recipient setting for local over quota addresses in combination with a .forward file. Clients on the host can use a procmail filter, the .forward file forwards the message to procmail. After procmail processes the message it in turn uses the cyrdeliver binary to deliver the message to the local mailbox. The postfix verify probe caches "forward via file: /path/to/dir/.forward" in the verify_cache.db. When a client's mailbox is over quota, cyrdeliver returns a tempfail with exitcode 75 to postfix. Postfix then has a deferred message in its queue with a defer message of "Program failure (75) of "/usr/sbin/cyrdeliver" and additional messages for this mailbox are queued in this same manner. How can I ensure that verify probes get the over quota status of local mailboxes that have a .forward file set. Do I have to use an access map or policy service or is there a different way using just reject_unverified_recipient?
Re: reject_unverified_recipient with .forward file
Michael van Es: > Hello, > > Clients on the host can use a procmail filter, the .forward file > forwards the message to procmail [which gives the mail to Cyrus]. [how can Postfix "verify" find out that the Cyrus mailbox is over-quota] It can't, not even when Postfix gives the mail directly to Cyrus. Instead, you need to populate an access map or transport map based on a periodic scan (or real-time query) of Cyrus quota. access map: u...@example.com450 4.2.2 Mailbox is full transport map: u...@example.comerror: 4.2.2 Mailbox is full Wietse
Re: reject_unverified_recipient with .forward file
Wietse Venema: > Michael van Es: > > Hello, > > > > Clients on the host can use a procmail filter, the .forward file > > forwards the message to procmail [which gives the mail to Cyrus]. > > [how can Postfix "verify" find out that the Cyrus mailbox is over-quota] > > It can't, not even when Postfix gives the mail directly to Cyrus. > > Instead, you need to populate an access map or transport map based > on a periodic scan (or real-time query) of Cyrus quota. > > access map: > > u...@example.com450 4.2.2 Mailbox is full > > transport map: > > u...@example.com error: 4.2.2 Mailbox is full Forget about the transport map solution. The "error" results in a hard reject. That should be "retry", but unfortunately the Postfix SMTP server doesn't know that the "retry" transport rejects mail, so it would accept the mail and that is not what you want. Wietse
Re: reject_unverified_recipient with .forward file
On Mon, Feb 24, 2014 at 10:21:59AM -0500, Wietse Venema wrote: > Wietse Venema: > > Michael van Es: > > > Hello, > > > > > > Clients on the host can use a procmail filter, the .forward file > > > forwards the message to procmail [which gives the mail to Cyrus]. > > > > [how can Postfix "verify" find out that the Cyrus mailbox is over-quota] > > > > It can't, not even when Postfix gives the mail directly to Cyrus. > > > > Instead, you need to populate an access map or transport map based > > on a periodic scan (or real-time query) of Cyrus quota. > > > > access map: > > > > u...@example.com450 4.2.2 Mailbox is full > > > > transport map: > > > > u...@example.comerror: 4.2.2 Mailbox is full > > Forget about the transport map solution. The "error" results in a > hard reject. That should be "retry", but unfortunately the Postfix > SMTP server doesn't know that the "retry" transport rejects mail, > so it would accept the mail and that is not what you want. > > Wietse Ah, thanks. I had just begun writing a test for the transport map solution. I will focus on the access map. -- Michael
Re: Heuristics are not security
On Mon, 24 Feb 2014, Wietse Venema wrote: The absence of observed variation does not mean nothing of relevance has changed, and the presence of benign observed changes drowns out the malicious ones, assuming that the malicious party is stupid enough to reveal itself. Well, if the only output of the software is what it is now, the bad guys don't actually need to do anything to hide. So what's bad about requesting that the checks which are required for more secure connections are also executed for the less secure ones and positive results are reported? That's all I request. This is not a sound basis for automatic policy enforcement or claims about "email security level" except at perhaps trivial scales. Well, we have plain unencrypted SMTP for now. So yes, we are on a trivial scale. Larger providers here in Germany did a lot marketing that they now use TLS at all. So it's a long way to go. DNSSEC is like building a fortress. Current SMTP is like leaving the door open. Until the fortress stage is reached there are many steps like closing the door, using a key, ... Why it's in the internet world usually an all or nothing. There ARE steps in between. Maybe small ones, but most people choose the open door when the other option is to build a fortress. E.G. Refering to the other mail: I wont change my domain provider to enable a functionality which allows me to do extreme secure communication with only a handful of mail servers I never contacted before. Ciao -- http://www.dstoecker.eu/ (PGP key available)
THREAD CLOSED: Heuristics are not security
On Mon, Feb 24, 2014 at 06:35:43PM +0100, Dirk St?cker wrote: > >The absence of observed variation does not mean nothing of relevance > >has changed, and the presence of benign observed changes drowns out > >the malicious ones, assuming that the malicious party is stupid > >enough to reveal itself. > > Well, if the only output of the software is what it is now, the bad > guys don't actually need to do anything to hide. Postfix already offers protection against passive eavesdropping in the form of opportunistic TLS. Protection against MITM requires the ability to distinguish between connections to the right server from connections to the wrong server. For pre-DANE SMTP, over insecure DNS this is not generally possible. Pretending that we've plausibly verified absense of MITM when we've in fact done nothing of the sort is not something the maintainers of Postfix are in the habit of doing. We will likely continue to adopt sensible security features as they mature, but we'll do our best to not misrepresent reality. This is the last comment in this thread. -- Viktor.
Re: TLS client logging PATCH
On Mon, 24 Feb 2014, Viktor Dukhovni wrote: I don't want to have a perfection box which can't communicate with the rest of the world, but something which helps with todays internet. Nonsense. Patrick Koetter's .de domain is DNSSEC signed. His mailserver has TLSA records. Enabling DNSSEC does not prevent you from communicating with the rest of the world. Furthermore, you can enable DNSSEC validation in your resolver before your own domain is signed. The two are independent. So what do you think really - How long will it take until 10% of all mail hosts use DANE/TLSA? Wouldn't it be a good idea to at least increase security (even a little bit) for what we have now? I'd be happy when a higher percentage would support TLS at all. But you din't answer my question: What harm would it do, when the checks implemented already to verify certs and domain names and maybe TLS protocol quality are also executed for "Opportunistic TLS" and the results printed in the log? Would it really be bad when the line Feb 24 18:56:04 merkur postfix/smtp[7701]: Trusted TLS connection established to mail.stoecker.eu[2a01:4f8:d13:3800::1:5]:25: TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits) contains a note that the server certificate of the connection actually also matched the domain name written there. My Registrar said today: "Sorry, currently it is not possible to use DNSSec for domains registered here." Vote with your feet. I'm transferring my domains to a registrar with better DNSSEC support (and incidentally lower price). I live in the "hightech country" Germany. Here a 16/1MB DSL line is extreme highspeed internet, IPV4 is state of the art. I can only dream of finding providers for more reliable Internet. DNSSEC is actually the lowest of my problems. And then I need to hope that users start to use that information, because all this work is completely useless until 100% deployed. My 100 years guess aren't so bad I think. Very unlikely, that this approach will work. No, DANE secures SMTP transport between publishing servers and validating clients regardless of what everyone else is doing. The adoption model is incremental. Is there a test server I can use to verify correct function? It does not sound like a good idea to send some test mails to a server without a permission to do so. Even if it seems I can't get more security for my own server or get better information out of postfix to evaluate the "low quality TLS" connections it at least would be interesting to setup that support for sending. Maybe in the next year there even will be an email to one of these servers. Ciao -- http://www.dstoecker.eu/ (PGP key available)
Re: TLS client logging PATCH
Am 24.02.2014 19:03, schrieb Dirk Stöcker: > On Mon, 24 Feb 2014, Viktor Dukhovni wrote: > >>> I don't want to have a perfection box which can't communicate with >>> the rest of the world, but something which helps with todays >>> internet. >> >> Nonsense. Patrick Koetter's .de domain is DNSSEC signed. His >> mailserver has TLSA records. Enabling DNSSEC does not prevent you >> from communicating with the rest of the world. Furthermore, you >> can enable DNSSEC validation in your resolver before your own domain >> is signed. The two are independent. > > So what do you think really - How long will it take until 10% of all > mail hosts use DANE/TLSA? Wouldn't it be a good idea to at least > increase security (even a little bit) for what we have now? I'd be happy > when a higher percentage would support TLS at all. > > But you din't answer my question: What harm would it do, when the checks > implemented already to verify certs and domain names and maybe TLS > protocol quality are also executed for "Opportunistic TLS" and the > results printed in the log? > > Would it really be bad when the line > > Feb 24 18:56:04 merkur postfix/smtp[7701]: Trusted TLS connection > established to mail.stoecker.eu[2a01:4f8:d13:3800::1:5]:25: TLSv1 with > cipher ECDHE-RSA-AES256-SHA (256/256 bits) > > contains a note that the server certificate of the connection actually > also matched the domain name written there. > >>> My Registrar said today: >>> "Sorry, currently it is not possible to use DNSSec for domains >>> registered here." >> >> Vote with your feet. I'm transferring my domains to a registrar >> with better DNSSEC support (and incidentally lower price). > > I live in the "hightech country" Germany. Here a 16/1MB DSL line is > extreme highspeed internet, IPV4 is state of the art. I can only dream > of finding providers for more reliable Internet. DNSSEC is actually the > lowest of my problems. > >>> And then I need to hope that users start to use that information, >>> because all this work is completely useless until 100% deployed. My >>> 100 years guess aren't so bad I think. Very unlikely, that this >>> approach will work. >> >> No, DANE secures SMTP transport between publishing servers and >> validating clients regardless of what everyone else is doing. The >> adoption model is incremental. > > Is there a test server I can use to verify correct function? It does not > sound like a good idea to send some test mails to a server without a > permission to do so. > > Even if it seems I can't get more security for my own server or get > better information out of postfix to evaluate the "low quality TLS" > connections it at least would be interesting to setup that support for > sending. Maybe in the next year there even will be an email to one of > these servers. > > Ciao Hi Dirk Be sure dnssec will spread fast at some point if massive attacks on dns servers will rise more and more. see https://sys4.de/de/blog/2013/10/14/dns-fragment-angriffe-zeit-fur-dnssec/ Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: Heuristics are not security
Dirk St?cker: > On Mon, 24 Feb 2014, Wietse Venema wrote: > > > The absence of observed variation does not mean nothing of relevance > > has changed, and the presence of benign observed changes drowns out > > the malicious ones, assuming that the malicious party is stupid > > enough to reveal itself. > > Well, if the only output of the software is what it is now, the bad guys > don't actually need to do anything to hide. Postfix already logs enough to expose bad guys that don't try to hide. For example, the Postfix SMTP client logs the recipient domain, the remote server IP address and hostname, as well as the connection setup time, data transfer time, etcetera. Just collect data over a longer time and look for anomalous changes. Postfix could log some more information about TLS, and we're looking into that. Postfix can provide you with more information to shoot yourself into the foot, but it does not have to provide the weapon. Wietse
Re: TLS client logging PATCH
On Mon, Feb 24, 2014 at 07:03:21PM +0100, Dirk St?cker wrote:
> >Nonsense. Patrick Koetter's .de domain is DNSSEC signed. His
> >mailserver has TLSA records. Enabling DNSSEC does not prevent you
> >from communicating with the rest of the world. Furthermore, you
> >can enable DNSSEC validation in your resolver before your own domain
> >is signed. The two are independent.
>
> So what do you think really - How long will it take until 10% of all
> mail hosts use DANE/TLSA? Wouldn't it be a good idea to at least
> increase security (even a little bit) for what we have now? I'd be
> happy when a higher percentage would support TLS at all.
With a bit of luck roughly 5 years. Exim has not implemented DANE
yet, and the RFC for DANE TLS for SMTP has not yet been ratified
by the IETF. The first Postfix release with DANE just came out
last month, and is not in most O/S distributions.
We should see the RFC adopted in the next few months, and Exim
implementing this year. Getting a major provider like Gmail, Yahoo,
AOL, ... would be nice, this will take a bit longer, but will make
a big impact when it does.
I'm working with the OpenSSL team to add DANE support to OpenSSL
so that other applications can adopt DANE without doing all the
hard work from the ground up.
Changing the infrastructure on Internet scale takes time.
> But you din't answer my question: What harm would it do, when the
> checks implemented already to verify certs and domain names and
> maybe TLS protocol quality are also executed for "Opportunistic TLS"
> and the results printed in the log?
You're asking for a verification status that would indicate
conditional MITM protection:
- False negative: MITM protection is illusory when the MX
hostname is compromised through DNS record forgery.
- False positive: No claim of MITM protection when the MX
host's certificate does not match what was expected, even
though it is the right MX host.
- False negative: Your root CA list contains a rogue CA, or
an intermediate CA signed by a trusted CA is rogue.
- False positive: Your root CA list contains too few CAs.
Most Postfix users would be ill-served by such a confusing signal.
> >No, DANE secures SMTP transport between publishing servers and
> >validating clients regardless of what everyone else is doing. The
> >adoption model is incremental.
>
> Is there a test server I can use to verify correct function? It does
> not sound like a good idea to send some test mails to a server
> without a permission to do so.
Testing is possible without sending email. You just need to complete
a TLS handshake.
Since with DANE we know what an authenticated connection means, we
can and likely will soon add a setting which allows DANE to optionally
fall back to an MITM vulnerable mode ("encrypt" or "may") after
logging a warning, when authentication fails or TLS is unavailable
on the server. That will allow more cautious users to pilot DANE
without worrying about denial of service.
--
Viktor.
DNSSEC, was Re: TLS client logging PATCH
On Mon, Feb 24, 2014 at 01:16:39AM +0100, Dirk Stöcker wrote: > On Sun, 23 Feb 2014, Viktor Dukhovni wrote: > >If you want scalable security for SMTP, become an early adopter > >of DANE TLS, available in Postfix 2.11. Today, you'll be able > >to opportunistically authenticate the handful of DNSSEC signed > >domains that publish TLSA records for SMTP. Over time, I hope > >that handful will grow to a decent fraction of SMTP sites. > > Oh yes - DNSSEC. When will it come? In hundred years? Dirk, do you mind explaining this? Are you having trouble finding DNSSEC-enabled DNS hosting? It's true that most of the numerous free DNS providers are not DNSSEC-enabled, but I found a few: http://www.frankb.us/dns/ Beware the services which do not support notify. When zones are signed and automatically maintained, new signatures are published as needed. With notify, slave NS hosts will pull the new data as soon as it is available. Self-hosting of DNS is not that difficult; in fact I think to set up and maintain a Postfix MTA is much more challenging than BIND named. But as with self-hosting mail, you get exposure to attacks and the need to watch for security issues and patches. I can suggest a cost effective way for SMBs with a moderately-capable GNU/Linux admin on board to get unlimited DNSSEC-signed zones for US$20/month: Linode.com. Run BIND named on your own VPS, then have Linode's nameservers slave it. There may be other VPS providers offering similar services, but I specifically mention Linode because I know they support both notify and DNSSEC. If you need enterprise-class hosting you are able and should be willing to pay for it. Linode is low-end to be called "enterprise", but I think they offer the geographic and network diversity that DNS needs. Of course there is no shortage of enterprise-class DNS hosting out there, priced accordingly. My own employer is in that line, so I'll avoid ethical questions by leaving off any specific mention of such services. > Sorry, probably this is not the right place to complain, but I hear > the same arguments for so many years now and there is no progress. > The algorithms get better and better, but no progress in adopting > useful methods to use them. And seeing the big-money certificate > system for SSL which gives trust away to some uncontrollable > companies and governments also does not help a lot (probably even > trying to prevent any wide adoption of DNS based certs, because > they will kill their model to earn money). Yep, I think DNSSEC and DANE will cheer you up quite well. :) -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: TLS client logging PATCH
On Mon, 24 Feb 2014, Viktor Dukhovni wrote:
With a bit of luck roughly 5 years. Exim has not implemented DANE
yet, and the RFC for DANE TLS for SMTP has not yet been ratified
by the IETF. The first Postfix release with DANE just came out
last month, and is not in most O/S distributions.
You're optimistic. Let's hope you're right, but I doubt it.
But you din't answer my question: What harm would it do, when the
checks implemented already to verify certs and domain names and
maybe TLS protocol quality are also executed for "Opportunistic TLS"
and the results printed in the log?
You're asking for a verification status that would indicate
conditional MITM protection:
- False negative: MITM protection is illusory when the MX
hostname is compromised through DNS record forgery.
- False positive: No claim of MITM protection when the MX
host's certificate does not match what was expected, even
though it is the right MX host.
- False negative: Your root CA list contains a rogue CA, or
an intermediate CA signed by a trusted CA is rogue.
- False positive: Your root CA list contains too few CAs.
Hmm, point 1,3,4 are already true for the current output. Adding the info
that Cert and hostname matched wont add additional drawbacks. Point 2 can
be addressed by the text. Don't write "VERIFIED", write "cert-match" or
whatever is suggesting less MITM protection level. Don't add any text,
when not matching or write the (first) certificate domain as reference.
If e.g. Google mail suddenly is sent to the mail.badguy.de it is much more
obvious in the log then if gmail-smtp-in.l.google.com gets a different IP.
Such an output would help to find second case easily.
Is there a test server I can use to verify correct function? It does
not sound like a good idea to send some test mails to a server
without a permission to do so.
Testing is possible without sending email. You just need to complete
a TLS handshake.
My setup should now be correct (at least according to docs). DNS responses
seem to be verified (positive and negative), so I assume it works.
But I have no idea how to use the postfix tools to start a TLS connection
to such an server without sending an email. This requires too much
internal knowledge I fear. Last time I tried to call smtp tool by hand it
told me not to do so and I took that advice.
I can use mail(x) or telnet or openssl, but this does not tell me if the
postfix settings are right.
Since with DANE we know what an authenticated connection means, we
can and likely will soon add a setting which allows DANE to optionally
fall back to an MITM vulnerable mode ("encrypt" or "may") after
logging a warning, when authentication fails or TLS is unavailable
on the server. That will allow more cautious users to pilot DANE
without worrying about denial of service.
This affects receiving servers with wrong configured TLSA/DNSSEC settings?
Actually I thought that stopping mail delivery in case DANE is detected
and defective is a very good idea.
Shouldn't that case be obvious in the "broken" server log - connection
aborts after the TLS phase?
Ciao
--
http://www.dstoecker.eu/ (PGP key available)
Re: DNSSEC
On Mon, 24 Feb 2014, /dev/rob0 wrote: Oh yes - DNSSEC. When will it come? In hundred years? Dirk, do you mind explaining this? Are you having trouble finding DNSSEC-enabled DNS hosting? Reading about it for years - always with "Delayed" as main information (same like for IPv6). But OTOH during my current tests I detected that my mobile phone dialin provider offered me a nameserver supporting DNSSEC (whether I'll trust them to verify the entries for me is another matter, but at least they do). Maybe there really is progress. I'll again ask my DNS provider for their time-frame. Let's see if there will be movement this year. Self-hosting of DNS is not that difficult; in fact I think to set up and maintain a Postfix MTA is much more challenging than BIND named. But as with self-hosting mail, you get exposure to attacks and the need to watch for security issues and patches. I also run bind, but only for Dyn-DNS service. I'm not ready to risk all my services with my own DNS server installation - Only non-critical infrastructure (i.e. NOT the mail servers). Yep, I think DNSSEC and DANE will cheer you up quite well. :) Yes, it sounds fine. I'm waiting for it. But since the first time I heard about DNS based certificate some time is gone and I'm still waiting... Ciao -- http://www.dstoecker.eu/ (PGP key available)
Re: TLS client logging PATCH
On 24 Feb 2014, at 06:09 , Viktor Dukhovni wrote: > On Mon, Feb 24, 2014 at 12:26:42PM +0100, Dirk St?cker wrote: > > Nonsense. Patrick Koetter's .de domain is DNSSEC signed. His > mailserver has TLSA records. Enabling DNSSEC does not prevent you > from communicating with the rest of the world. Furthermore, you > can enable DNSSEC validation in your resolver before your own domain > is signed. The two are independent. Wait, what? You can? Hmmm... Hover.com is still not supporting DNSSEC, but I can still validate my domains? That's not exactly what you said, is it? > It only takes a few minutes to configure a validating recursive > resolver. Install unbound and make sure it performs automatic > tracking of the root zone DNSKEY. unbound is better than bind for this sort of thing? (I noticed freeBSD 10 has switched from bind to unbound, I expect they have good reason). >> My Registrar said today: >> "Sorry, currently it is not possible to use DNSSec for domains >> registered here." > > Vote with your feet. I'm transferring my domains to a registrar > with better DNSSEC support (and incidentally lower price). Yes, well, in general registrars kind of suck, and hover doesn't suck. But yes, they need to get DNSSEC sorted. >> But if I understand it right even if I do all perfect and hope that >> more systems support that secure approach - I need to configure each >> system supporting this individually by hand without any automatic >> aid in my own system? > > No. DANE does not require per-destination configuration. That's the > point. DANE sounds nifty! >> And then I need to hope that users start to use that information, >> because all this work is completely useless until 100% deployed. My >> 100 years guess aren't so bad I think. Very unlikely, that this >> approach will work. > > No, DANE secures SMTP transport between publishing servers and > validating clients regardless of what everyone else is doing. The > adoption model is incremental. Ibid. -- Oh, he's just like any other man, only more so.
Re: TLS client logging PATCH
On Mon, Feb 24, 2014 at 10:15:48PM +0100, Dirk St?cker wrote: > >You're asking for a verification status that would indicate > >conditional MITM protection: > > > > - False negative: MITM protection is illusory when the MX > > hostname is compromised through DNS record forgery. > > > > - False positive: No claim of MITM protection when the MX > > host's certificate does not match what was expected, even > > though it is the right MX host. > > > > - False negative: Your root CA list contains a rogue CA, or > > an intermediate CA signed by a trusted CA is rogue. > > > > - False positive: Your root CA list contains too few CAs. > > Hmm, point 1,3,4 are already true for the current output. Actually, no. By default Postfix trusts no CAs, even when these are bundled with the system. And Postfix does not use the insecure MX hostname by default, it uses the nexthop domain. The intent is to log "Anonymous" or "Untrusted" for all opportunistic connections. If you add every CA on the planet to your trusted CA list, and expect the result to mean something for connections to any random receiving domain, that's your business. Only for destinations where you have explicit policy that makes secure-channels possible, should you get "Trusted" or "Verified", relative to your carefully selected small set of CAs. [ No follow-ups to the above. Thanks. ] > But I have no idea how to use the postfix tools to start a TLS > connection to such an server without sending an email. This requires > too much internal knowledge I fear. Last time I tried to call smtp > tool by hand it told me not to do so and I took that advice. /usr/sbin/sendmail -f $(id -nu) -bv 'postmas...@example.com' or via the "posttls-finger" utility from Postfix 2.11 source tarball. > >That will allow more cautious users to pilot DANE > >without worrying about denial of service. > > This affects receiving servers with wrong configured TLSA/DNSSEC > settings? Actually I thought that stopping mail delivery in case > DANE is detected and defective is a very good idea. When you first turn on DANE as a default policy, you have no way to estimate the impact on your users in terms of deferred mail to misconfigured sites they want to send to. Having a setting that allows users to test-drive DANE without enforcement is probably a good idea. I would prefer if users did not use DANE that way indefinitely, rather it is a migration aid. -- Viktor.
DANE and DNSSEC adoption
On Mon, Feb 24, 2014 at 02:36:46PM -0700, LuKreme wrote: > > Furthermore, you > > can enable DNSSEC validation in your resolver before your own domain > > is signed. The two are independent. > > Wait, what? You can? Sure, you can validate other people's domains even if your own domain is not signed. These are independent. > > It only takes a few minutes to configure a validating recursive > > resolver. Install unbound and make sure it performs automatic > > tracking of the root zone DNSKEY. > > unbound is better than bind for this sort of thing? (I noticed freeBSD 10 has > switched from bind to unbound, I expect they have good reason). BIND is fine too, but I've not looked at how it is packaged on various systems. I know that the unbound package typically includes scripts to automatically handle root zone key rollover. Perhaps modern BIND packages do that also. -- Viktor.
Re: DANE and DNSSEC adoption
* Viktor Dukhovni : > On Mon, Feb 24, 2014 at 02:36:46PM -0700, LuKreme wrote: > > > > Furthermore, you > > > can enable DNSSEC validation in your resolver before your own domain > > > is signed. The two are independent. > > > > Wait, what? You can? > > Sure, you can validate other people's domains even if your own > domain is not signed. These are independent. > > > > It only takes a few minutes to configure a validating recursive > > > resolver. Install unbound and make sure it performs automatic > > > tracking of the root zone DNSKEY. > > > > unbound is better than bind for this sort of thing? (I noticed freeBSD 10 > > has switched from bind to unbound, I expect they have good reason). > > BIND is fine too, but I've not looked at how it is packaged on > various systems. I know that the unbound package typically includes > scripts to automatically handle root zone key rollover. Perhaps > modern BIND packages do that also. Unbound is *said* to be factor 10 times faster. If you are searching for resolver only, you are fine with unbound. Be sure to run unbound-control-setup the first time and to let it create some keys or you will not be able to control your unbound resolver via command line: unbound-control flush example.com will flush the cache for example.com. Useful when you setup a DNSSEC domain or TLSA or ... and you don't get it right the first time. It so happened here ... ;) p@rick -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: DANE and DNSSEC adoption
On 24 Feb 2014, at 14:43 , Viktor Dukhovni wrote: > Sure, you can validate other people's domains even if your own > domain is not signed. These are independent. Oh, right. Yes. OTHER people's domains. Never mind. :) -- Sometimes the only thing you could do for people was to be there. --Soul Music
Re: TLS client logging PATCH
On Mon, Feb 24, 2014 at 02:36:46PM -0700, LuKreme wrote:
> On 24 Feb 2014, at 06:09 , Viktor Dukhovni
> wrote:
> > On Mon, Feb 24, 2014 at 12:26:42PM +0100, Dirk St?cker wrote:
> >
> > Nonsense. Patrick Koetter's .de domain is DNSSEC signed. His
> > mailserver has TLSA records. Enabling DNSSEC does not prevent
> > you from communicating with the rest of the world. Furthermore,
> > you can enable DNSSEC validation in your resolver before your
> > own domain is signed. The two are independent.
>
> Wait, what? You can?
My zone "nodns4.us" is signed. You can set up your resolver to verify
these signatures. Later on you might want to sign "kreme.com", and
indeed, this has nothing to do with your local resolver.
> Hmmm... Hover.com is still not supporting DNSSEC, but I can still
> validate my domains?
>
> That's not exactly what you said, is it?
Does your domain registrar control (or even ask to control) what you
list in your /etc/resolv.conf file? Mine doesn't. And my resolv.conf
points to "nameserver 127.0.0.1", my own local resolver, which does
perform DNSSEC validation.
> > It only takes a few minutes to configure a validating recursive
> > resolver. Install unbound and make sure it performs automatic
> > tracking of the root zone DNSKEY.
>
> unbound is better than bind for this sort of thing? (I noticed
"Better" is subjective. I doubt it. It is trivial to enable DNSSEC
validation in BIND. In fact it almost works out of the box. There's
only one thing to set, in the named.conf(5) options stanza, to wit:
options {
[ ... ]
dnssec-validation auto;
};
(Offer void where taxed or prohibited, or if your BIND version is
unsupported/EOL. Right now that means BIND 9.7 and earlier -- now
including the recently retired 9.6-ESV branch.)
> freeBSD 10 has switched from bind to unbound, I expect they have
> good reason).
And the FreeBSD BIND package has defined empty zones for years,
despite the BIND empty zones feature which has existed all along.
Perhaps their reasons are rooted in misunderstandings of BIND?
I can't say anything good or bad about unbound, never having used
anything other than BIND. I've had no reason to change.
> >> My Registrar said today:
> >> "Sorry, currently it is not possible to use DNSSec for domains
> >> registered here."
> >
> > Vote with your feet. I'm transferring my domains to a registrar
> > with better DNSSEC support (and incidentally lower price).
>
> Yes, well, in general registrars kind of suck, and hover doesn't
> suck. But yes, they need to get DNSSEC sorted.
I'd call lack of DNSSEC support a serious drawback. I'm on Godaddy
for now, but I'm probably going to jump ship to GKG.net. They make
the claim to be DNSSEC-friendly. It sounds like you can run your
master nameserver and sign your zone, and they will provide slave
(secondary) name service for free (included with the domain
registration cost.)
--
http://rob0.nodns4.us/
Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: DANE and DNSSEC adoption
On Mon, Feb 24, 2014 at 10:50:24PM +0100, Patrick Ben Koetter wrote: > * Viktor Dukhovni : > > On Mon, Feb 24, 2014 at 02:36:46PM -0700, LuKreme wrote: > > > unbound is better than bind for this sort of thing? (I noticed > > > freeBSD 10 has switched from bind to unbound, I expect they > > > have good reason). > > > > BIND is fine too, but I've not looked at how it is packaged on > > various systems. I know that the unbound package typically includes > > scripts to automatically handle root zone key rollover. Perhaps > > modern BIND packages do that also. As I said in reply to this in the other thread, it is simple. The "dnssec-validation auto;" setting initializes the managed-keys database using the compiled-in root key. A new root ZSK rollover happens automatically. > Unbound is *said* to be factor 10 times faster. Yes, I have heard things like this also, but I have not been shown the actual tests, so I remain skeptical. :) I recently addressed this on the dnsmasq mailing list, where I pointed out that a user's perception of DNS speed is dependent on many different things, most of which are external and beyond your control. It might be possible to design a reasonable speed comparison, but will it be relevant to the real world? > If you are searching for > resolver only, you are fine with unbound. Yes, and the unbound folks also have NSD for authoritative name service. BIND, OTOH, is an all-in-one DNS implementation, with a caveat: you really should not have authoritative and recursive service in the same named instance, in general. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: TLS client logging PATCH
On Mon, Feb 24, 2014 at 04:38:12PM -0600, /dev/rob0 wrote:
> On Mon, Feb 24, 2014 at 02:36:46PM -0700, LuKreme wrote:
> > On 24 Feb 2014, at 06:09 , Viktor Dukhovni
> > wrote:
> > > On Mon, Feb 24, 2014 at 12:26:42PM +0100, Dirk St?cker wrote:
> > >
> > > Nonsense. Patrick Koetter's .de domain is DNSSEC signed. His
> > > mailserver has TLSA records. Enabling DNSSEC does not prevent
> > > you from communicating with the rest of the world. Furthermore,
> > > you can enable DNSSEC validation in your resolver before your
> > > own domain is signed. The two are independent.
> >
> > Wait, what? You can?
>
> My zone "nodns4.us" is signed. You can set up your resolver to verify
> these signatures. Later on you might want to sign "kreme.com", and
> indeed, this has nothing to do with your local resolver.
>
> > Hmmm... Hover.com is still not supporting DNSSEC, but I can still
> > validate my domains?
> >
> > That's not exactly what you said, is it?
>
> Does your domain registrar control (or even ask to control) what you
> list in your /etc/resolv.conf file? Mine doesn't. And my resolv.conf
> points to "nameserver 127.0.0.1", my own local resolver, which does
> perform DNSSEC validation.
>
> > > It only takes a few minutes to configure a validating recursive
> > > resolver. Install unbound and make sure it performs automatic
> > > tracking of the root zone DNSKEY.
> >
> > unbound is better than bind for this sort of thing? (I noticed
>
> "Better" is subjective. I doubt it. It is trivial to enable DNSSEC
> validation in BIND. In fact it almost works out of the box. There's
> only one thing to set, in the named.conf(5) options stanza, to wit:
> options {
> [ ... ]
> dnssec-validation auto;
> };
> (Offer void where taxed or prohibited, or if your BIND version is
> unsupported/EOL. Right now that means BIND 9.7 and earlier -- now
> including the recently retired 9.6-ESV branch.)
>
> > freeBSD 10 has switched from bind to unbound, I expect they have
> > good reason).
>
> And the FreeBSD BIND package has defined empty zones for years,
> despite the BIND empty zones feature which has existed all along.
> Perhaps their reasons are rooted in misunderstandings of BIND?
FreeBSD changed to unbound as a local resolver not as a replacement for
the DNS server BIND. It is explicitly stated in their release notes that
the change to unbound as a local resolver, not as a replacement for
providing the DNS service.
>
> I can't say anything good or bad about unbound, never having used
> anything other than BIND. I've had no reason to change.
>
> > >> My Registrar said today:
> > >> "Sorry, currently it is not possible to use DNSSec for domains
> > >> registered here."
> > >
> > > Vote with your feet. I'm transferring my domains to a registrar
> > > with better DNSSEC support (and incidentally lower price).
> >
> > Yes, well, in general registrars kind of suck, and hover doesn't
> > suck. But yes, they need to get DNSSEC sorted.
>
> I'd call lack of DNSSEC support a serious drawback. I'm on Godaddy
> for now, but I'm probably going to jump ship to GKG.net. They make
> the claim to be DNSSEC-friendly. It sounds like you can run your
> master nameserver and sign your zone, and they will provide slave
> (secondary) name service for free (included with the domain
> registration cost.)
> --
> http://rob0.nodns4.us/
> Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
