If bind configuration would allow including a file, such as /etc/crypto-policies/back-ends/bind.config, it would be very easy to add that in rawhide.

We would only need strings, which transcribe the current policies for LEGACY, DEFAULT and FUTURE into bind config format.

I could do that part if someone else takes care of the file inclusion part.

(In reply to Nikos Mavrogiannopoulos from comment #1)
> If bind configuration would allow including a file, such as
> /etc/crypto-policies/back-ends/bind.config, it would be very easy to add
> that in rawhide.

It is possible to include a file in BIND configuration.

> We would only need strings, which transcribe the current policies for
> LEGACY, DEFAULT and FUTURE into bind config format.

Those are disable-algorithms statement which has to be used in "options" section.
http://ftp.isc.org/isc/bind9/9.9.7b1/doc/arm/Bv9ARM.ch06.html#options

However I'm not sure how will BIND handle multiple options sections. I'll have to test the possibilities.

> I could do that part if someone else takes care of the file inclusion part.

I'll do some testing and see what works. Since I'm the maintainer, I'll do it.

However we would have to reload BIND in case of policy change, for the configuration to be used. Would it be possible to trigger the daemon reload on a policy change?

(In reply to Tomas Hozza from comment #2)
> (In reply to Nikos Mavrogiannopoulos from comment #1)
> > If bind configuration would allow including a file, such as
> > /etc/crypto-policies/back-ends/bind.config, it would be very easy to add
> > that in rawhide.
> It is possible to include a file in BIND configuration.
> > We would only need strings, which transcribe the current policies for
> > LEGACY, DEFAULT and FUTURE into bind config format.
> Those are disable-algorithms statement which has to be used in "options"
> section.
> http://ftp.isc.org/isc/bind9/9.9.7b1/doc/arm/Bv9ARM.ch06.html#options
> However I'm not sure how will BIND handle multiple options sections. I'll
> have to test the possibilities.

ok. I think for future proof it is better to explicitly enable the allowed, rather than disabling the ones not allowed. That way the risk of missing an insecure algorithm is less.

> > I could do that part if someone else takes care of the file inclusion part.
> I'll do some testing and see what works. Since I'm the maintainer, I'll do
> it.
> However we would have to reload BIND in case of policy change, for the
> configuration to be used. Would it be possible to trigger the daemon reload
> on a policy change?

Yes. Currently everything is monolithic in:
https://github.com/nmav/fedora-crypto-policies/blob/master/update-crypto-policies

So you could add any action you'd like.

(In reply to Nikos Mavrogiannopoulos from comment #3)
> (In reply to Tomas Hozza from comment #2)
> > (In reply to Nikos Mavrogiannopoulos from comment #1)
> > > If bind configuration would allow including a file, such as
> > > /etc/crypto-policies/back-ends/bind.config, it would be very easy to add
> > > that in rawhide.
> > It is possible to include a file in BIND configuration.
> > > We would only need strings, which transcribe the current policies for
> > > LEGACY, DEFAULT and FUTURE into bind config format.
> > Those are disable-algorithms statement which has to be used in "options"
> > section.
> > http://ftp.isc.org/isc/bind9/9.9.7b1/doc/arm/Bv9ARM.ch06.html#options
> > However I'm not sure how will BIND handle multiple options sections. I'll
> > have to test the possibilities.
> 
> ok. I think for future proof it is better to explicitly enable the allowed,
> rather than disabling the ones not allowed. That way the risk of missing an
> insecure algorithm is less.

Generall - I agree. Problem is that BIND allows you only to blacklist algortihms.

> > > I could do that part if someone else takes care of the file inclusion part.
> > I'll do some testing and see what works. Since I'm the maintainer, I'll do
> > it.
> > However we would have to reload BIND in case of policy change, for the
> > configuration to be used. Would it be possible to trigger the daemon reload
> > on a policy change?
> 
> Yes. Currently everything is monolithic in:
> https://github.com/nmav/fedora-crypto-policies/blob/master/update-crypto-
> policies
> 
> So you could add any action you'd like.
I was wondering more about some systemd target which can be restarted/poked to after policy changes and this target could in turn reload services as needed.

So the file with blacklisted algorithms should contain something like:

disable-algorithms "."  {
        RSASHA1;
        <another_alg>;
};

I haven't used the systemd target but seems a nice idea. Would it only require crypto-policies to install a crypto-policies.target file and restart that?

I'm a bit lost with the documentation of supported algorithms in bind. It mentions it but doesn't say what is accepted there. Are there algorithms for TSIG also available? 

Another issue is that one can set the maximum rsa key, but not the minimum for some reason. For our purposes the minimum is what we need. In don't see any option to set the minimum acceptable DH keys as well and rfc2539 only defines 768 and 1024 bit groups, so I remove it completely.

My suggestion is:

LEGACY:
disable-algorithms "." {
RSAMD5;
};

DEFAULT:
disable-algorithms "." {
HMAC-MD5;
RSAMD5;
DH;
};

FUTURE:
disable-algorithms "." {
HMAC-MD5;
RSAMD5;
DSA;
DH;
NSECRSASHA1;
RSASHA1;
}

Unfortunatelly the coverage is not complete. disable-algorithms covers only algos usable for DNSSEC and not HMAC.

Valid algorithm names for disable-algorithms can be found on:
https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=blob;f=lib/dns/rcode.c;h=0b74744d966571689e7c6022369d2f362fae37c8;hb=d1f1f13c7fc1f1515930053508f1645cfafaa478#l101

Hashing algorithms should be disabled similarly using disable-ds-digests option.
https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=blob;f=bin/named/config.c;h=de685e9b04ead3653b1900f7c9cb3dc0dd51505e;hb=d1f1f13c7fc1f1515930053508f1645cfafaa478#l959

One more option related to hashing is "session-keyalg" - it defaults to "hmac-sha256" today.


We certainly can ask ISC to add options to disable HMAC algorithms but I would not wait to it.

(In reply to Petr Spacek from comment #7)
> Unfortunatelly the coverage is not complete. disable-algorithms covers only
> algos usable for DNSSEC and not HMAC.
> 
> Valid algorithm names for disable-algorithms can be found on:
> https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=blob;f=lib/dns/rcode.
> c;h=0b74744d966571689e7c6022369d2f362fae37c8;
> hb=d1f1f13c7fc1f1515930053508f1645cfafaa478#l101

Thanks.

> Hashing algorithms should be disabled similarly using disable-ds-digests
> option.
> https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=blob;f=bin/named/
> config.c;h=de685e9b04ead3653b1900f7c9cb3dc0dd51505e;
> hb=d1f1f13c7fc1f1515930053508f1645cfafaa478#l959
> One more option related to hashing is "session-keyalg" - it defaults to
> "hmac-sha256" today.
> We certainly can ask ISC to add options to disable HMAC algorithms but I
> would not wait to it.

If we could ask them, I think we should ask in addition to allow whitelists, e.g., to specify what is allowed, min-rsa-bits, and min-dh-bits (or at least specify the allowed DH groups).

I've added configuration for bind in:
https://github.com/nmav/fedora-crypto-policies/commit/a5f6e512211f671e8e7a934a7bdfe269c56921af
The bind configuration is placed in /etc/crypto-policies/back-ends/bind.config.
I haven't had time to check for reloading using systemd target.

I have asked about new options in [ISC-Bugs #38315].

I've updated crypto-policies in rawhide to generate:
/etc/crypto-policies/back-ends/bind.config

Is there some command to only test the generated bind configuration?

Nikos, you can use "named-confcheck" command. It will check the whole /etc/named.conf so do not forget to add include to existing options section in named.conf:

options {
    include "/etc/crypto-policies/back-ends/bind.config";
};

I'd prefer that this will be done in the fedora's bind package rather than have crypto policies modify that file. The bind package would only need to depend on crypto-policies and have
options {
    include "/etc/crypto-policies/back-ends/bind.config";
};
on its default configuration file (or something like that).

(and here by 'this' I mean the inclusion of the crypto-policies output file). Thanks for the named-confcheck hint. I'll add it.

Sure, I agree that bind 'distro' conf file should include crypto policy snippet. I just wanted to give you a hint how to use named-checkconf :-)

Nikos, please answer the following questions:

Who will be the owner and owner group of the policy file?

What are the permissions for the generated policy file?

Thank you in advance.

(In reply to Tomas Hozza from comment #17)
> Nikos, please answer the following questions:
> Who will be the owner and owner group of the policy file?

update-crypto-policies is expected to be run by root so the normal owner.group is root.root.

> What are the permissions for the generated policy file?

The generated files will be readable by anybody (update-crypto-policies sets umask to 022).

This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22

(In reply to Nikos Mavrogiannopoulos from comment #14)

> options {
>     include "/etc/crypto-policies/back-ends/bind.config";
> };

Hi,
 Will this be resolved in F22, or should be postponed for F23? In Fedora 22 the policy file for bind is generated.

Implemented in bind-9.10.2-3.fc23