DANE and DLV

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

DANE and DLV

Jean Bruenn
Hello,

I have a few questions not directly related to Postfix
and hope it is fine to ask here. I'd like to use
DANE but since my registrar has no support for
DNSSEC stuff yet (they're working on that) I am
using DLV (dlv.isc.org) for now.

Now I'd like to use that with Postfix and for
that to work I assume that other sites needs to
use DLV verification as well. What happens if
they don't? Verification will fail and the
mail is rejected? Basically I want to know if
it is safe to implement DANE with DLV.

Thanks in advance,
Jean
Reply | Threaded
Open this post in threaded view
|

Re: DANE and DLV

Viktor Dukhovni
On Tue, Jan 06, 2015 at 11:36:08PM +0100, Jean Bruenn wrote:

> I'd like to use DANE but since my registrar has no support for DNSSEC
> stuff yet (they're working on that) I am using DLV (dlv.isc.org) for now.
> Now I'd like to use that with Postfix and for that to work I assume that
> other sites needs to use DLV verification as well.

Correct.  DANE support is a client-side only matter. SMTP clients
sending email to your domain will only make use of DANE if they
support DLV.  My email server, for example, specifically does not
support the ISC DLV.  With the root zone and most TLDs signed, I
don't think it makes sense to use it anymore.

> What happens if they don't?

They'll send email to your domain without DNSSEC or DANE.

> Verification will fail and the mail is rejected?

Of course not.  All that happens is that email transmission to your
domain is more vulnerable to MiTM attacks.

> Basically I want to know if it is safe to implement DANE with
> DLV.

Safe, but largely pointless.  By the time enough domains enable
client-side DANE support for this to matter to you, the ISC DLV
may be substantially obsolete.

While DLV is enabled in typical configurations of BIND and unbound
with DNSSEC, I personally make the effort to disable it.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: DANE and DLV

Jean Bruenn


> Am 07.01.2015 um 00:18 schrieb Viktor Dukhovni <[hidden email]>:
>
>> On Tue, Jan 06, 2015 at 11:36:08PM +0100, Jean Bruenn wrote:
>>
>> I'd like to use DANE but since my registrar has no support for DNSSEC
>> stuff yet (they're working on that) I am using DLV (dlv.isc.org) for now.
>> Now I'd like to use that with Postfix and for that to work I assume that
>> other sites needs to use DLV verification as well.
>
> Correct.  DANE support is a client-side only matter. SMTP clients
> sending email to your domain will only make use of DANE if they
> support DLV.  My email server, for example, specifically does not
> support the ISC DLV.  With the root zone and most TLDs signed, I
> don't think it makes sense to use it anymore.
>

What happens if I send an email to your Mailserver if there is
no DS-record for my domain in eu (which is why I use dlv - I added
the dnskey of a .eu testdomain there) the same as explained
below (no mail loss)?

>> What happens if they don't?
>
> They'll send email to your domain without DNSSEC or DANE.
>
>> Verification will fail and the mail is rejected?
>
> Of course not.  All that happens is that email transmission to your
> domain is more vulnerable to MiTM attacks.
>
>> Basically I want to know if it is safe to implement DANE with
>> DLV.
>
> Safe, but largely pointless.  By the time enough domains enable
> client-side DANE support for this to matter to you, the ISC DLV
> may be substantially obsolete.

I see. If I understand correctly it does help in cases like mine if
the registrar for example has no dnssec support yet?

Jean
Reply | Threaded
Open this post in threaded view
|

Re: DANE and DLV

Viktor Dukhovni
On Wed, Jan 07, 2015 at 12:45:53AM +0100, Jean Bruenn wrote:

> What happens if I send an email to your Mailserver if there is
> no DS-record for my domain in eu (which is why I use dlv - I added
> the dnskey of a .eu testdomain there) the same as explained
> below (no mail loss)?

DANE plays no role in inbound mail.  The receiving server does not
do any DANE lookups.  DANE TLSA is a client-side technology.

The .eu TLD is signed, there are many .eu DNSSEC domains.

For example: debian.eu

    debian.eu. IN MX 10 mailly.debian.org. ; NOERROR AD=1
    debian.eu. IN MX 10 muffat.debian.org. ; NOERROR AD=1

The TLSA records of the (shared with debian.org) MX hosts are also
present and DNSSEC validated.

> >> What happens if they don't?
> >
> > They'll send email to your domain without DNSSEC or DANE.
> >
> >> Verification will fail and the mail is rejected?
> >
> > Of course not.  All that happens is that email transmission to your
> > domain is more vulnerable to MiTM attacks.
> >
> >> Basically I want to know if it is safe to implement DANE with
> >> DLV.
> >
> > Safe, but largely pointless.  By the time enough domains enable
> > client-side DANE support for this to matter to you, the ISC DLV
> > may be substantially obsolete.
>
> I see. If I understand correctly it does help in cases like mine if
> the registrar for example has no dnssec support yet?

There is no pressing need to run out and implement DANE for your
domain, certainly not as a fashion statement or out of concern that
mail delivery will suffer if you don't.

At this stage, I'd like to see DANE implemented *only* by people
who know what exactly what they're getting into.

    * DO NOT enable DNSSEC if you've not reliably automated timely
      resigning of your zone files.  Too many sites neglect this
      and disappear from the Internet for days until someone notices
      that validating resolvers are dropping all responses for the domain.

    * DO NOT publish DANE TLSA records for SMTP unless you've understood
      that you should only publish records of one the forms:

        ; Use "3 1 1", the other three are OK, but "3 1 1" is better.
        _25._tcp.mx.example.com. IN TLSA 3 1 1 <sha2-256 digest of DER leaf public key in X.509 SPKI format>
        _25._tcp.mx.example.com. IN TLSA 3 0 1 <sha2-256 digest of DER leaf cert>
        _25._tcp.mx.example.com. IN TLSA 3 1 2 <sha2-512 digest of DER leaf public key in X.509 SPKI format>
        _25._tcp.mx.example.com. IN TLSA 3 0 2 <sha2-512 digest of DER leaf cert>

        ; Use "2 0 1", the other three are OK, but "2 0 1" is better.
        _25._tcp.mx.example.com. IN TLSA 2 0 1 <sha2-256 digest of DER CA certificate>
        _25._tcp.mx.example.com. IN TLSA 2 1 1 <sha2-256 digest of DER CA public key in X.509 SPKI format>
        _25._tcp.mx.example.com. IN TLSA 2 0 2 <sha2-512 digest of DER CA certificate>
        _25._tcp.mx.example.com. IN TLSA 2 1 2 <sha2-512 digest of DER CA public key in X.509 SPKI format>

        The use of SHA2-512 just bloats the DNS packet sizes with
        no tangible security benefit, the 2nd-preimage resistance
        of SHA2-256, let alone SHA2-512 dwarfs the security level
        of the typical RSA-1024 zone signing keys at the root and
        TLD domains.

        The DANE-TA(2) certificate usage REQUIRES that the trust-anchor
        certificate be part of the server's certificate chain file.
        Too many people get this wrong from time to time.  Stick
        to DANE-EE(3) unless you have the attention to detail of
        a clinically diagnosed OCD patient who never makes mistakes.
        With DANE-EE(3) you are also not subject to "unplanned"
        certificate expiration outages, or hostname mismatch issues.

    * Deploy a "3 1 1" separate certificate for each server, avoid
      the temptation to "share".  With "shared" certificates, a
      mistake in key rotation takes out all the servers.

    * Do understand how to coordinate DANE TLSA record updates with
      key rotation, and never forget to update DANE TLSA records
      as part of that process.

    * Do monitor your DANE deployment, and promptly fix any problems.
      Have a working "postmaster" mailbox that is read by human.
      Publish an working "hostmaster" address in the "RNAME"
      field of the domain's SOA record that is also read by a human.
      From RFC 1035, Section 3.3.13:

        RNAME           A <domain-name> which specifies the mailbox of the
                        person responsible for this zone.

      Know how to encode email addresses with dots in the localpart as
      SOA RNAMEs (see SOA of disa.mil for example).

I am hoping at present to discourage the use of DANE either as a
fashion statement or by inexperienced server operators.

I am also trying to encourage the use of DANE by seasoned administrators
who know what they are getting into, and how to make it work
reliably.

Of the approximately 800 domains that I found to have published
DANE TLSA records for SMTP to date, too many had various problems.

We'll announce a testing site soon that will help detect problems
early, but it won't prevent them if the site's administrator is
not sufficiently disciplined about ongoing operational requirements.

If you understand DNS and email well, are ready to implement DNSSEC
and are good at not losing track of details, please implement DANE,
otherwise, please wait, or use a professionally operated hosting
service that will do it for you.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: DANE and DLV

Jim Reid
In reply to this post by Viktor Dukhovni

On 6 Jan 2015, at 23:18, Viktor Dukhovni <[hidden email]> wrote:

> My email server, for example, specifically does not support the ISC DLV.

Yay!

> With the root zone and most TLDs signed, I don't think it makes sense to use it anymore.

+1000.

DLV has always been a *remarkably* bad idea. It actually hinders DNSSEC deployment. It adds too many extra moving parts which makes DNSSEC validation even more brittle and complex to maintain/debug. Best avoid DLV at all costs.

BTW, it's particularly unwise to adopt DLV to kludge around TLD registries or registrars who can't/won't support DNSSEC properly. This was the OP's rationale for going down that path. IMO the OP should switch to another registrar and let the slacker registrar know why they've lost the OP's business. This will be far less painful than jumping into DLV and then trying to figure out how to undo that or migrate away from it.

DLV looks to be going away too. ISC is mumbling about switching it off by the end of 2016. There was some discussion about this on the dnssec-deployment mailing list a couple of weeks ago. The list archives are currently off-line but here's the relevant posting:

> From: Michael Richardson <[hidden email]>
> Date: Tue, 23 Dec 2014 10:02:06 -0500
> Message-ID: <[hidden email]>
>
> Let me tell you, as [hidden email], and the person who takes care of DLV now,
> that DLV doesn't support any ECDSA algorithms.  There is some significant
> conflict between making DLV all-singing and all-dancing, and just shutting it
> down, because it's a crutch now.
>
> At this point, the plan is that DLV will shutdown by the end of 2016.
> Our plan is to find polite ways to tell detect zones whose parent is signed,
> to go do that, and then figure out what's left; and then report that here.

Anyone planning to start depending on DLV needs to think very carefully about adopting something that probably has no future apart from a long overdue burial. The fact DLV's maintainer is not extending it to support/provision the newest DNSSEC crypto algorithms is a fairly clear sign of where DLV is headed.
Reply | Threaded
Open this post in threaded view
|

Re: DANE and DLV

John Allen
In reply to this post by Viktor Dukhovni
I assume this list is "best" to "worst"

> ; Use "3 1 1", the other three are OK, but "3 1 1" is better.
> _25._tcp.mx.example.com. IN TLSA 3 1 1 <sha2-256 digest of DER leaf public key in X.509 SPKI format>
> _25._tcp.mx.example.com. IN TLSA 3 0 1 <sha2-256 digest of DER leaf cert>
> _25._tcp.mx.example.com. IN TLSA 3 1 2 <sha2-512 digest of DER leaf public key in X.509 SPKI format>
> _25._tcp.mx.example.com. IN TLSA 3 0 2 <sha2-512 digest of DER leaf cert>
>
> ; Use "2 0 1", the other three are OK, but "2 0 1" is better.
> _25._tcp.mx.example.com. IN TLSA 2 0 1 <sha2-256 digest of DER CA certificate>
> _25._tcp.mx.example.com. IN TLSA 2 1 1 <sha2-256 digest of DER CA public key in X.509 SPKI format>
> _25._tcp.mx.example.com. IN TLSA 2 0 2 <sha2-512 digest of DER CA certificate>
> _25._tcp.mx.example.com. IN TLSA 2 1 2 <sha2-512 digest of DER CA public key in X.509 SPKI format>
I am not sure I understand this. Why are you linking the two?
>      * Do understand how to coordinate DANE TLSA record updates with
>        key rotation, and never forget to update DANE TLSA records
>        as part of that process.
Has anybody published any recommendations as to timing for the life
cycle of a ZSK  (and KSK for that matter)? So far the only
recommendation I have seen was a footnote in a paper on DNSSEC. It
recommended 1yr for KSK and 4Yrs for KSKs. I think these number are
unrealistic for a couple of reasons 1) with the growth of hacker nets i
do not think keys can survive that long. 2) on a much more mundane level
- with staff turn over etc., rollover is  liable to slip between the cracks.

Are there any know tools to automate rollover? I have not found any and
have been writing my own script but being a lazy s.. i would prefer to
use somebody elses work!

Victor - I have a question and a suggestion which I would like to
explore offline. May I contact you at IETF, or at any other address you
like, you may contact me a [hidden email].

--
John Allen
KLaM
------------------------------------------
You are off the edge of the map, mate. Here there be monsters!
Reply | Threaded
Open this post in threaded view
|

Re: DANE and DLV

Viktor Dukhovni
On Wed, Jan 07, 2015 at 01:00:10PM -0500, John wrote:

> I assume this list is "best" to "worst"

Roughly speaking yes, though none are a disaster.  Pick usage "3"
in most cases, but if you known what you're doing, want to operate
an internal CA and have lots of hosts to secure, usage 2 might be
right for you.

> > ; Use "3 1 1", the other three are OK, but "3 1 1" is better.
> > _25._tcp.mx.example.com. IN TLSA 3 1 1 <sha2-256 digest of DER leaf public key in X.509 SPKI format>
> > _25._tcp.mx.example.com. IN TLSA 3 0 1 <sha2-256 digest of DER leaf cert>
> > _25._tcp.mx.example.com. IN TLSA 3 1 2 <sha2-512 digest of DER leaf public key in X.509 SPKI format>
> > _25._tcp.mx.example.com. IN TLSA 3 0 2 <sha2-512 digest of DER leaf cert>
> >
> > ; Use "2 0 1", the other three are OK, but "2 0 1" is better.
> > _25._tcp.mx.example.com. IN TLSA 2 0 1 <sha2-256 digest of DER CA certificate>
> > _25._tcp.mx.example.com. IN TLSA 2 1 1 <sha2-256 digest of DER CA public key in X.509 SPKI format>
> > _25._tcp.mx.example.com. IN TLSA 2 0 2 <sha2-512 digest of DER CA certificate>
> > _25._tcp.mx.example.com. IN TLSA 2 1 2 <sha2-512 digest of DER CA public key in X.509 SPKI format>
>
> I am not sure I understand this. Why are you linking the two?

I am not linking anything.

> >     * Do understand how to coordinate DANE TLSA record updates with
> >       key rotation, and never forget to update DANE TLSA records
> >       as part of that process.
>
> Has anybody published any recommendations as to timing for the life cycle of
> a ZSK  (and KSK for that matter)? So far the only recommendation I have seen
> was a footnote in a paper on DNSSEC. It recommended 1yr for KSK and 4Yrs for
> KSKs. I think these number are unrealistic for a couple of reasons 1) with
> the growth of hacker nets i do not think keys can survive that long. 2) on a
> much more mundane level - with staff turn over etc., rollover is  liable to
> slip between the cracks.

I'll leave DNSSEC ops for others to describe,  I'm relatively new to that.

> Victor - I have a question and a suggestion which I would like to explore
> offline. May I contact you at IETF, or at any other address you like, you
> may contact me a [hidden email].

OK.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: DANE and DLV

John Allen
On 1/7/2015 1:22 PM, Viktor Dukhovni wrote:
> I am not sure I understand this. Why are you linking the two?
> I am not linking anything.
I am not sure what TLSA updates has to do with key rotation, other than
they might be a good idea to do them at the same time. May be its my odd
ball way of reading it.
>>>      * Do understand how to coordinate DANE TLSA record updates with
>>>        key rotation, and never forget to update DANE TLSA records
>>>        as part of that process.
>>

--
John Allen
KLaM
------------------------------------------
A day without sunshine is like, night?
Reply | Threaded
Open this post in threaded view
|

Re: DANE and DLV

Jean Bruenn
In reply to this post by Jim Reid

On 07/01/15 02:07, Jim Reid wrote:
> BTW, it's particularly unwise to adopt DLV to kludge around TLD
> registries or registrars who can't/won't support DNSSEC properly. This
> was the OP's rationale for going down that path. IMO the OP should
> switch to another registrar and let the slacker registrar know why
> they've lost the OP's business.

I don't want to go offtopic but there seem to be still "many"
registrars which do not support dnssec. I for example asked
three different registrars in germany and got the same
answer - they're working on it, due to the little demand
they haven't implemented anything for that now. I am
sure that I'll be able to find a registrar in germany with the
same prices, a similar realtime API and dnssec support.
Still I would not like to switch after 10+ years without any
trouble, to another registrar - call me lazy if you want.

Currently I am testing and "playing around" with dnssec,
dane and such stuff to learn more about it - I am not in pressure
to implement it neither do I need it cuz' its cool or something.
When implementing DNSSEC in my own nameservers I
noticed (due to forwarders I was using) that three different
(one of them is quite big) datacenters in germany don't
support dnssec - the public orsn nameserver does not,
neither. 3 is not a representative number, might be that
I picked the 3 that cannot while the other 97 can.

Would be pretty interesting to see some country-statistic
about dnssec usage. Actually the only public dns that
supports dnssec I found at a first glance was google and
I'd rather not use that (I am not using forwarders anymore
anyway) :^)
Reply | Threaded
Open this post in threaded view
|

Re: DANE and DLV

Jean Bruenn
In reply to this post by Viktor Dukhovni

On 07/01/15 02:01, Viktor Dukhovni wrote:

> Of the approximately 800 domains that I found to have published
> DANE TLSA records for SMTP to date, too many had various problems.
>
> We'll announce a testing site soon that will help detect problems
> early, but it won't prevent them if the site's administrator is
> not sufficiently disciplined about ongoing operational requirements.
>
> If you understand DNS and email well, are ready to implement DNSSEC
> and are good at not losing track of details, please implement DANE,
> otherwise, please wait, or use a professionally operated hosting
> service that will do it for you.
>

Thanks a lot for all information that was pretty helpful. I'd be
glad to hear from you once that testing page is ready to be
used.

I will continue to read about that topic and continue to try
in a test-environment.

Jean
Reply | Threaded
Open this post in threaded view
|

Re: DANE and DLV

Viktor Dukhovni
In reply to this post by John Allen
On Wed, Jan 07, 2015 at 01:47:06PM -0500, John wrote:

> >I am not sure I understand this. Why are you linking the two?
> >I am not linking anything.
>
> I am not sure what TLSA updates has to do with key rotation, other than they
> might be a good idea to do them at the same time. May be its my odd ball way
> of reading it.

I am talking about SMTP server TLS key/cert rotation, not DNSSEC
key rotation.  

And not at the same time, the TLSA RRs for new certs/keys need to
be published before the keys are deployed concurrently with the
live keys.  Let the combination age a few TTLs, then deploy the
new keys.

    https://tools.ietf.org/html/draft-ietf-dane-ops-07#section-8.1
    https://tools.ietf.org/html/draft-ietf-dane-ops-07#section-8.4

With DNSSEC it is the other way around.  Publish old and new DNSKEY
records first, let that bake in for a few TTLs, then publish new
DS RRs.  When removing keys, drop corresponding DS RR first, let
than RRset age a bit, then remove the keys.

    Invariants:

        DNSSEC:  For each not yet expired (TTL) DS RRset there is
        always a corresponding DNSKEY published at the zone apex.

        DANE:  At all times the server's live certificate chain
        matches at least one TLSA record in every not yet expired
        (TTL) TLSA RRset.

Key rotation must maintain these invariants.

    No extant DS RRsets that contain records with no matching DNSKEY.

    No TLS certificate chains that fail to match some record in
    every extant TLSA RRset.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: DANE and DLV

Thomas Leuxner
In reply to this post by Jean Bruenn
* Jean Bruenn <[hidden email]> 2015.01.07 19:54:

> I don't want to go offtopic but there seem to be still "many"
> registrars which do not support dnssec. I for example asked
> three different registrars in germany and got the same
> answer - they're working on it, due to the little demand
> they haven't implemented anything for that now.

They actually DO exist. I can make recommendations off-list if you are still searching...

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: DANE and DLV

Jean Bruenn

On 07/01/15 20:09, Thomas Leuxner wrote:
> * Jean Bruenn <[hidden email]> 2015.01.07 19:54:
>
>> I don't want to go offtopic but there seem to be still "many"
>> registrars which do not support dnssec. I for example asked
>> three different registrars in germany and got the same
>> answer - they're working on it, due to the little demand
>> they haven't implemented anything for that now.
> They actually DO exist. I can make recommendations off-list if you are still searching...

Feel free to do so.
Reply | Threaded
Open this post in threaded view
|

Re: DANE and DLV

Viktor Dukhovni
In reply to this post by Jean Bruenn
On Wed, Jan 07, 2015 at 07:54:03PM +0100, Jean Bruenn wrote:

> I am
> sure that I'll be able to find a registrar in germany with the
> same prices, a similar realtime API and dnssec support.
> Still I would not like to switch after 10+ years without any
> trouble, to another registrar - call me lazy if you want.

You're lazy. :-)  Take your time, no need to rush.

> Currently I am testing and "playing around" with dnssec,
> dane and such stuff to learn more about it - I am not in pressure
> to implement it neither do I need it cuz' its cool or something.

That's what I'm looking for, people who take the time to do it
right, rather than rush into it half-baked as a fashion statement.

> Would be pretty interesting to see some country-statistic
> about dnssec usage.

The SMTP DANE adoption by TLD breakdown is:

     794 TOTAL
     ---------
     231 de
     132 net
      96 com
      80 org
      29 eu
      25 ch
      21 nl
      21 cz
      12 me
      12 dk
      11 uk
      11 fr
      10 io
       9 se
       9 info
       9 be
       8 email
       6 at
       5 is
       4 us
     ...

And many of the .net/.com/.org/.eu domains are really German domains
"in disguise".  So despite the registrar barriers, .DE is by far
the biggest early adopter.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: DANE and DLV

James B. Byrne
In reply to this post by Jean Bruenn

On Wed, January 7, 2015 13:54, Jean Bruenn wrote:

>
> On 07/01/15 02:07, Jim Reid wrote:
>> BTW, it's particularly unwise to adopt DLV to kludge around TLD
>> registries or registrars who can't/won't support DNSSEC properly.
>> This was the OP's rationale for going down that path. IMO the
>> OP should switch to another registrar and let the slacker
>> registrar know why they've lost the OP's business.
>
> I don't want to go offtopic but there seem to be still "many"
> registrars which do not support dnssec. I for example asked
> three different registrars in germany and got the same
> answer - they're working on it, due to the little demand
> they haven't implemented anything for that now. I am
> sure that I'll be able to find a registrar in germany with the
> same prices, a similar realtime API and dnssec support.
> Still I would not like to switch after 10+ years without any
> trouble, to another registrar - call me lazy if you want.
>

This is exactly our situation.  We presently use DLV.  I can get our
upstream registrar to manually add DS RRs for our .com, .net; and I
believe our .org tlds. But they will not do so for our principal tlds
that belong to .ca. Nonetheless, as we have many domains registered
with them, and have been using them since 2000 March 26, we are
reluctant to change providers.

CIRA's answer is to change registrars. That is the easy out, for them.
The difficulty being the administrative and financial costs of doing
so for us.

So, we await developments and in the meantime employ DLV.

--
***          E-Mail is NOT a SECURE channel          ***
James B. Byrne                mailto:[hidden email]
Harte & Lyne Limited          http://www.harte-lyne.ca
9 Brockley Drive              vox: +1 905 561 1241
Hamilton, Ontario             fax: +1 905 561 0757
Canada  L8E 3C3

Reply | Threaded
Open this post in threaded view
|

Re: DANE and DLV

Viktor Dukhovni
On Wed, Jan 07, 2015 at 02:44:11PM -0500, James B. Byrne wrote:

> This is exactly our situation.  We presently use DLV.  I can get our
> upstream registrar to manually add DS RRs for our .com, .net; and I
> believe our .org tlds. But they will not do so for our principal tlds
> that belong to .ca.

Paul Wouters has a perfectly good DNSSEC .ca domain:

    nohats.ca. IN MX 10 mx.nohats.ca. ; NOERROR AD=1
    _25._tcp.mx.nohats.ca. IN TLSA 3 1 1 462573195c86e861abab8eccfbc7f0486958efdff9449ac10729b3a0f906f388 ; passed

    Domain name:           nohats.ca
    Domain status:         registered
    Creation date:         2011/11/28
    Expiry date:           2015/11/28
    Updated date:          2014/10/30
    DNSSEC:                Signed

    Registrar:
        Name:              Tucows.com Co.

> Nonetheless, as we have many domains registered
> with them, and have been using them since 2000 March 26, we are
> reluctant to change providers.
>
> CIRA's answer is to change registrars. That is the easy out, for them.
> The difficulty being the administrative and financial costs of doing
> so for us.
>
> So, we await developments and in the meantime employ DLV.

The "value" of DLV is rather limited, I personally would not bother.
If you actually want DNSSEC, switch registrars.  Otherwise, wait for
yours to get on-board.

Anyway, this is somewhat off-topic for Postfix, so we should delve
into too deeply.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: DANE and DLV

John Hascall
In reply to this post by Viktor Dukhovni
I've been watching this thread with interest.

Assume I have a domain with DNSSEC and inbound mail servers behind a (load-balanced) MX which support TLS.

If I've been following along correctly, if I publish a DNS record of the form:

  _25._tcp.mx.mydomain.org. IN TLSA 3 1 1 <sha2-256 digest of DER leaf public key in X.509 SPKI format>

this will make some (currently smallish?) set of mail servers sending to me have a better assurance they are really talking to me.

Is this correct?

And does "leaf public key" refer to the public key associated with the cert used for STARTTLS or ...something else...?


Thanks,
John



--
John Hascall <[hidden email]>
Team Lead, Network Infrastructure, Authentication, & Directory Services
IT Services, The Iowa State University of Science and Technology

On Wed, Jan 7, 2015 at 1:12 PM, Viktor Dukhovni <[hidden email]> wrote:
On Wed, Jan 07, 2015 at 07:54:03PM +0100, Jean Bruenn wrote:

> I am
> sure that I'll be able to find a registrar in germany with the
> same prices, a similar realtime API and dnssec support.
> Still I would not like to switch after 10+ years without any
> trouble, to another registrar - call me lazy if you want.

You're lazy. :-)  Take your time, no need to rush.

> Currently I am testing and "playing around" with dnssec,
> dane and such stuff to learn more about it - I am not in pressure
> to implement it neither do I need it cuz' its cool or something.

That's what I'm looking for, people who take the time to do it
right, rather than rush into it half-baked as a fashion statement.

> Would be pretty interesting to see some country-statistic
> about dnssec usage.

The SMTP DANE adoption by TLD breakdown is:

     794 TOTAL
     ---------
     231 de
     132 net
      96 com
      80 org
      29 eu
      25 ch
      21 nl
      21 cz
      12 me
      12 dk
      11 uk
      11 fr
      10 io
       9 se
       9 info
       9 be
       8 email
       6 at
       5 is
       4 us
     ...

And many of the .net/.com/.org/.eu domains are really German domains
"in disguise".  So despite the registrar barriers, .DE is by far
the biggest early adopter.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: DANE and DLV

Viktor Dukhovni
On Wed, Jan 07, 2015 at 02:07:25PM -0600, John Hascall wrote:

> Assume I have a domain with DNSSEC and inbound mail servers behind a
> (load-balanced) MX which support TLS.

With All of the MX hosts having the same private key and certificate:

> If I've been following along correctly, if I publish a DNS record of the
> form:
>
>   _25._tcp.mx.example.org. IN TLSA 3 1 1 *<sha2-256 digest of DER leaf public key in X.509 SPKI format>*

Or else multiple such TLSA RRs one per real MX host behind the load-balancer,
if the number of back-end hosts is reasonably small.

> this will make some (currently smallish?) set of mail servers sending to me
> have a better assurance they are really talking to me.
> Is this correct?

Yes, and definitely smallish.  Basically folks running Postfix 2.11 with:

    smtp_dns_support_level = dnssec
    smtp_tls_security_level = dane

and a validating resolver on 127.0.0.1 as the only entry in /etc/resolv.conf

I have no count of sites that implement client-side DANE, I can
only survey the domains that publish TLSA RRs for such sites to
use.

> And does "*leaf public key" *refer to the public key associated with the
> cert used for STARTTLS or ...something else...?

The former:

    printf '_25._tcp.%s. IN TLSA 3 1 1 %s\n' \
        $(uname -n) \
        $(openssl x509 -in cert.pem -noout -pubkey |
            openssl pkey -pubin -outform DER |
            openssl dgst -sha256 -binary |
            hexdump -ve '/1 "%02x"')

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: DANE and DLV

John Hascall
Thanks. very helpful.

One more question, though.  You say:

With All of the MX hosts having the same private key and certificate:
(this is true for us)
...
Or else multiple such TLSA RRs one per real MX host behind the load-balancer,
if the number of back-end hosts is reasonably small.

(this number is currently 9 for us)

On what what basis would we decide between a single TLSA record for the MX vs. individual TLSA records for each actual host?  Is it that there some intrinsic advantage in having individual records vs. the effort of creating N records?  Or is it something else?

Thanks again,
John



--
John Hascall <[hidden email]>
Team Lead, Network Infrastructure, Authentication, & Directory Services
IT Services, The Iowa State University of Science and Technology

On Wed, Jan 7, 2015 at 2:16 PM, Viktor Dukhovni <[hidden email]> wrote:
On Wed, Jan 07, 2015 at 02:07:25PM -0600, John Hascall wrote:

> Assume I have a domain with DNSSEC and inbound mail servers behind a
> (load-balanced) MX which support TLS.

With All of the MX hosts having the same private key and certificate:

> If I've been following along correctly, if I publish a DNS record of the
> form:
>
>   _25._tcp.mx.example.org. IN TLSA 3 1 1 *<sha2-256 digest of DER leaf public key in X.509 SPKI format>*

Or else multiple such TLSA RRs one per real MX host behind the load-balancer,
if the number of back-end hosts is reasonably small.

> this will make some (currently smallish?) set of mail servers sending to me
> have a better assurance they are really talking to me.
> Is this correct?

Yes, and definitely smallish.  Basically folks running Postfix 2.11 with:

    smtp_dns_support_level = dnssec
    smtp_tls_security_level = dane

and a validating resolver on 127.0.0.1 as the only entry in /etc/resolv.conf

I have no count of sites that implement client-side DANE, I can
only survey the domains that publish TLSA RRs for such sites to
use.

> And does "*leaf public key" *refer to the public key associated with the
> cert used for STARTTLS or ...something else...?

The former:

    printf '_25._tcp.%s. IN TLSA 3 1 1 %s\n' \
        $(uname -n) \
        $(openssl x509 -in cert.pem -noout -pubkey |
            openssl pkey -pubin -outform DER |
            openssl dgst -sha256 -binary |
            hexdump -ve '/1 "%02x"')

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: DANE and DLV

Viktor Dukhovni
On Wed, Jan 07, 2015 at 02:29:51PM -0600, John Hascall wrote:

> On what what basis would we decide between a single TLSA record for the MX
> vs. individual TLSA records for each actual host?

Frankly, I don't see much point in load-balancers in front of
inbound port 25 MX hosts.  So I'd publish a multi-host MX RRset,
and use the load-balancer for some other protocol that needs it.

        example.com. IN MX 0 mx1.example.com.
        mx1.example.com. IN A 192.0.2.1
        _25._tcp.mx1.example.com. IN TLSA 3 1 1 <digest of mx1's public key>
        ;
        example.com. IN MX 0 mx2.example.com.
        mx2.example.com. IN A 192.0.2.2
        _25._tcp.mx2.example.com. IN TLSA 3 1 1 <digest of mx2's public key>
        ;
        ...
        ;
        example.com. IN MX 0 mx9.example.com.
        mx9.example.com. IN A 192.0.2.9
        _25._tcp.mx9.example.com. IN TLSA 3 1 1 <digest of mx9's public key>

> Is it that there some
> intrinsic advantage in having individual records vs. the effort of creating
> N records?  Or is it something else?

With a single key and TLSA RRset for all the MX hosts, a single
mistake breaks them all.  The load-balancer won't help.  With
separate records for each MX, and decoupled key rotation cycles,
you're much less likely to break all the MX hosts in a single
negligent act.

There is no single right answer, you consider the pros and cons.

--
        Viktor.
12