Send inn-workers mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/inn-workers
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of inn-workers digest..."
Today's Topics:
1. Re: Discussion about Cancel-Lock support (Julien ?LIE)
2. Security in Cancel-Lock password handling (secrets.conf)
(Julien ?LIE)
3. Re: Security in Cancel-Lock password handling (secrets.conf)
(Richard Kettlewell)
4. Re: Security in Cancel-Lock password handling (secrets.conf)
(Julien ?LIE)
5. Re: Security in Cancel-Lock password handling (secrets.conf)
(Russ Allbery)
6. Re: Security in Cancel-Lock password handling (secrets.conf)
(Perry E. Metzger)
7. Re: Security in Cancel-Lock password handling (secrets.conf)
(Russ Allbery)
----------------------------------------------------------------------
Message: 1
Date: Mon, 4 Oct 2021 21:00:56 +0200
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: Discussion about Cancel-Lock support
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Russ, hi all,
> One of my past regrets was when I was looking at configuration file
> formats, I probably shouldn't have hand-rolled a parser and instead
> figured out how to use YAML. In my defense, at the time it was far from
> obvious that YAML would win the configuration language wars (and I guess
> it hasn't entirely won them even now), and there were a lot of other
> possibilities. But now I kind of wish all the INN configuration files
> were just in YAML. The popularity of Kubernetes among other things has
> made YAML fairly universal, with great editor, linting, and schema
> support. Ah well. Maybe a project for some future day when someone is
> feeling wildly ambitious. :)
>
> (And yes, I know YAML is hideously, absurdly complicated and there are a
> lot of language features you probably don't want to use. But it's still
> the most readable and writable configuration language for humans IMO, even
> with its strange quirks and aggressive interpretation of words as
> booleans.)
It may be the right moment to do the most appropriate thing as for
configuration files.
We currently have only 1 file (inn.conf) that uses the internal new
parser. All the other files have various different parsers.
For the new secrets.conf file, we can:
- either directly use YAML for it, and then plan on migrating other
configuration files to YAML, including inn.conf;
- or make the parser generic for several files, and then re-use it for
new config files. It normally suits our needs.
As far as I see, inn.conf has already a YAML-like syntax except for
vectors. We still haven't used group tags, and I doubt people use
several parameters in the same line separated with semicolons.
Therefore switching it to YAML should not be too much difficult unless
of course we do at the same time a deeper refactoring and urbanization
of all the configuration variables present in inn.conf, and that's more
challenging.
The drawbacks I would see for YAML is that we add a library dependency
to libyaml, hoping it is available in all the platforms we support
(libyaml seems more wide-spread than libfyaml). And naturally that it
would make the current inn.conf parser useless after migrated to YAML.
Which is a loss of a great deal of hard work. And personally I like its
way to write lists ([a b c]) more than YAML does (multi-lines).
--
Julien ?LIE
??Roma tibi subito motibus ibit amor.??
------------------------------
Message: 2
Date: Mon, 4 Oct 2021 21:55:22 +0200
From: Julien ?LIE <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Security in Cancel-Lock password handling (secrets.conf)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi all,
Two questions about security and what's the best thing to do with the
upcoming secrets.conf file containing:
cancels {
canlockuser: [ password anotherpassword ]
canlockadmin: [ adminpassword anotheradminpassword ]
}
1/ Can secrets.conf remain in memory (in a struct) or should it be
loaded, used, erased with explicit_bzero() and freed for each article
injection?
2/ For interoperability reasons, we need to send both sha1 and sha256
hashes. Yet RFC 8315 has the following MUST:
If multiple <c-lock> elements are added to the Cancel-Lock header
field by a single agent, each <c-lock> element MUST use a unique
key "K" to improve security.
The rationale is that "a preimage attack on the different hash
algorithms may be easier if the attacker knows that the output of those
hash algorithms was created with the same input" (sha1 and sha256).
Which means that we MUST NOT use "adminpassword" for both sha1 and sha256.
Would the use of "sha1adminpassword" and "sha256adminpassword" for
instance with prepending the password by a (publicly known) prefix be
good? (At least, it complies with the MUST.)
Otherwise, what would you suggest?
cancels {
canlockuser: [ password anotherpassword ]
canlockadmin: [ adminpassword anotheradminpassword ]
canlocksalt: XYZ
}
which would use "adminpassword" for sha1 and "XYZadminpassword" for
sha256? XYZ would not be publicly known, but we have secrets sharing
the same suffix "adminpassword".
Or:
cancels {
canlockuser: [ password anotherpassword ]
canlockadmin: [ adminpassword anotheradminpassword ]
canlockuser2: [ passwordXX ]
canlockadmin2: [ adminpasswordZZ anotheradminpasswordTT ]
}
Maybe overkill... And more complex for the user.
This would permit having 2 different passwords though! (And yes, we can
have 2 passwords for sha1 and only 1 for sha256 in canlockuser2...)
Or a permutation? For instance "password" for sha1 and "cnffjbeq" for
sha256 (a ROT13 permutation).
--
Julien ?LIE
??A man who is not married is incomplete; a man who is married is
finished.??
------------------------------
Message: 3
Date: Mon, 4 Oct 2021 21:37:39 +0100
From: Richard Kettlewell <[email protected]>
To: [email protected]
Subject: Re: Security in Cancel-Lock password handling (secrets.conf)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
On 04/10/2021 20:55, Julien ?LIE wrote:
> Hi all,
>
> Two questions about security and what's the best thing to do with the
> upcoming secrets.conf file containing:
>
> cancels {
> ??? canlockuser: [ password anotherpassword ]
> ??? canlockadmin: [ adminpassword anotheradminpassword ]
> }
>
>
> 1/ Can secrets.conf remain in memory (in a struct) or should it be
> loaded, used, erased with explicit_bzero() and freed for each article
> injection?
nnrpd is network-facing so destroying secrets when not in use seems like
a good strategy. Recall that part of what made Heartbleed so bad was
that it could be used to exfiltrate long-term secret keys from the
victim server.
> 2/ For interoperability reasons, we need to send both sha1 and sha256
> hashes.? Yet RFC 8315 has the following MUST:
>
> ?? If multiple <c-lock> elements are added to the Cancel-Lock header
> ?? field by a single agent, each <c-lock> element MUST use a unique
> ?? key "K" to improve security.
>
> The rationale is that "a preimage attack on the different hash
> algorithms may be easier if the attacker knows that the output of those
> hash algorithms was created with the same input" (sha1 and sha256).
>
> Which means that we MUST NOT use "adminpassword" for both sha1 and sha256.
The RFC8315 s4 example for calculating K will produce distinct K for
distinct hashes, _assuming_ that the HMAC is parameterized by the same
hash function as will be used to compute the c-lock-string. (IMO it
would be perverse to violate this assumption.)
i.e.
K1 = HMAC-SHA1(adminpassword, uid+mid)
c-lock-string#1 = Base64(SHA-1(Base64(K1))
K2 = HMAC-SHA256(adminpassword, uid+mid)
c-lock-string#2 = Base64(SHA-256(Base64(K2))
K1 and K2 won't even be the same length.
Also, preimage attacks are wildly unrealistic at present l-)
ttfn/rjk
------------------------------
Message: 4
Date: Mon, 4 Oct 2021 22:57:42 +0200
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: Security in Cancel-Lock password handling (secrets.conf)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Richard,
>> 1/ Can secrets.conf remain in memory (in a struct) or should it be
>> loaded, used, erased with explicit_bzero() and freed for each article
>> injection?
>
> nnrpd is network-facing so destroying secrets when not in use seems like
> a good strategy. Recall that part of what made Heartbleed so bad was
> that it could be used to exfiltrate long-term secret keys from the
> victim server.
OK, seems reasonable to destroy secrets after their use.
>> 2/ For interoperability reasons, we need to send both sha1 and sha256
>> hashes.? Yet RFC 8315 has the following MUST:
>>
>> ??? If multiple <c-lock> elements are added to the Cancel-Lock header
>> ??? field by a single agent, each <c-lock> element MUST use a unique
>> ??? key "K" to improve security.
>>
>> The rationale is that "a preimage attack on the different hash
>> algorithms may be easier if the attacker knows that the output of
>> those hash algorithms was created with the same input" (sha1 and sha256).
>>
>> Which means that we MUST NOT use "adminpassword" for both sha1 and
>> sha256.
>
> The RFC8315 s4 example for calculating K will produce distinct K for
> distinct hashes, _assuming_ that the HMAC is parameterized by the same
> hash function as will be used to compute the c-lock-string. (IMO it
> would be perverse to violate this assumption.)
As this is not a requirement, it may happen...
Note that the hash algorithm used as the base for the HMAC operation
is not required to be the same as that specified by <scheme>.
> i.e.
> ?K1 = HMAC-SHA1(adminpassword, uid+mid)
> ?c-lock-string#1 = Base64(SHA-1(Base64(K1))
> ?K2 = HMAC-SHA256(adminpassword, uid+mid)
> ?c-lock-string#2 = Base64(SHA-256(Base64(K2))
>
> K1 and K2 won't even be the same length.
Hmm, yes you're right, K1 and K2 are different.
It is indeed the case with Michael's libcanlock, which we'll use for
INN. The HMAC is parameterized by the same hash function.
That's perfect! Thanks for your answers.
--
Julien ?LIE
??Une fois rien, c'est rien?; deux fois rien, c'est pas beaucoup, mais
pour trois fois rien, on peut d?j? acheter quelque chose, et pour pas
cher.?? (Raymond Devos)
------------------------------
Message: 5
Date: Mon, 04 Oct 2021 14:25:39 -0700
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: Security in Cancel-Lock password handling (secrets.conf)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Julien ?LIE <[email protected]> writes:
> 1/ Can secrets.conf remain in memory (in a struct) or should it be
> loaded, used, erased with explicit_bzero() and freed for each article
> injection?
In general I'm dubious of the utility of trying to wipe secrets from
memory and Cryptography Engineering generally recommends against bothering
because there are so many ways to fail, but if it's easy enough to do, I
suppose it can't hurt. (That was the same principle under which I added
the explicit_bzero calls to my pam-krb5 module.)
--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.
------------------------------
Message: 6
Date: Mon, 4 Oct 2021 21:56:50 -0400
From: "Perry E. Metzger" <[email protected]>
To: [email protected]
Subject: Re: Security in Cancel-Lock password handling (secrets.conf)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 10/4/21 17:25, Russ Allbery wrote:
> Julien ?LIE <[email protected]> writes:
>
>> 1/ Can secrets.conf remain in memory (in a struct) or should it be
>> loaded, used, erased with explicit_bzero() and freed for each article
>> injection?
> In general I'm dubious of the utility of trying to wipe secrets from
> memory and Cryptography Engineering generally recommends against bothering
> because there are so many ways to fail, but if it's easy enough to do, I
> suppose it can't hurt. (That was the same principle under which I added
> the explicit_bzero calls to my pam-krb5 module.)
>
I'm a big believer in not adding mitigations that don't actually fit a
particular well defined security model.
Perry
------------------------------
Message: 7
Date: Mon, 04 Oct 2021 19:16:21 -0700
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: Security in Cancel-Lock password handling (secrets.conf)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
"Perry E. Metzger" <[email protected]> writes:
> On 10/4/21 17:25, Russ Allbery wrote:
>> Julien ?LIE <[email protected]> writes:
>>> 1/ Can secrets.conf remain in memory (in a struct) or should it be
>>> loaded, used, erased with explicit_bzero() and freed for each article
>>> injection?
>> In general I'm dubious of the utility of trying to wipe secrets from
>> memory and Cryptography Engineering generally recommends against
>> bothering because there are so many ways to fail, but if it's easy
>> enough to do, I suppose it can't hurt. (That was the same principle
>> under which I added the explicit_bzero calls to my pam-krb5 module.)
> I'm a big believer in not adding mitigations that don't actually fit a
> particular well defined security model.
Yeah, that's my reluctance too. In pam-krb5 I was freeing the memory
anyway so adding a one-line call to explicit_bzero() before the free was
essentially zero effort. But since Julien is talking about changing the
internal structure and doing extra work including disk reads on every
post, I'm not sure it's worth it.
This isn't sufficiently high-security that it's worth designing an
explicit security model, which probably means it's not worth going out of
our way to do things that feel like security mitigations but might not
matter.
--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.
------------------------------
Subject: Digest Footer
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
------------------------------
End of inn-workers Digest, Vol 134, Issue 3
*******************************************
