Hal Murray via devel :
> Are we interested in client certificates? If so, why?
>
> struct ntsconfig_t has:
> /* Configuration data for an NTS server or client instance */
> char *ca; /* site default */
> char *cert; /* site default */
>
> I assume that c
Yo Hal!
On Wed, 13 Feb 2019 15:18:17 -0800
Hal Murray via devel wrote:
> >> I'm calling that "cert and other certs" a chain.
> > Except that is not the definition of a cert full chain file.
> > Please don't make up new terms for long standing, well settled,
> > concepts.
>
> I didn't call i
>> I'm calling that "cert and other certs" a chain.
> Except that is not the definition of a cert full chain file.
> Please don't make up new terms for long standing, well settled, concepts.
I didn't call it a "full" chain file.
I pulled the term "chain file" from the API. If you have a URL fo
Yo Hal!
On Wed, 13 Feb 2019 13:27:09 -0800
Hal Murray via devel wrote:
> That's sufficiently complicated that I'm not going to think about it
> now. If somebody thinks it is interesting enough, they should put it
> on the list. Maybe an issue, but Eric likes to delete those rather
> then use th
Thanks.
Gary said:
>> Unless somebody objects or has a better idea, I'll implement Richard
>> Laager suggestion to disable the NTS-KE server if it can't read the
>> certificate and key.
> I can't think of any other option. Is there?
Sure. Run without a certificate. That won't get very far if
Yo Hal!
On Tue, 12 Feb 2019 23:14:47 -0800
Hal Murray via devel wrote:
> Gary said:
> >> The server reads the certificate chain from /etc/ntp/cert-chain.pem
> >> The server reads the private key from /etc/ntp/key.pem
> > Which will, eventually, need to be configurable. Plus, when
> > needed,
Gary said:
>> The server reads the certificate chain from /etc/ntp/cert-chain.pem
>> The server reads the private key from /etc/ntp/key.pem
> Which will, eventually, need to be configurable. Plus, when needed, the key
> to the kep.pem file, somewhere.
The code to configure file names is in the
Yo Hal!
On Mon, 11 Feb 2019 21:49:46 -0800
Hal Murray via devel wrote:
> There is the start of the NTS-KE client and server. The client does
> the TLS handshake, saves the cookies, sets up C2S and S2C, then
> ignores them. The server returns fake cookies.
Cool. Nice start.
> They are using
On 2/11/19 11:49 PM, Hal Murray via devel wrote:
> OpenSSL has separate slots for root-cert dir and file. How should I tell
> which? Should we have separate config options?
It's not absolutely necessary to support both. One or the other is
sufficient. If you're only going to support one, the fi
There is the start of the NTS-KE client and server. The client does the TLS
handshake, saves the cookies, sets up C2S and S2C, then ignores them. The
server returns fake cookies.
They are using TCP port 123.
It's the minimal I could get away with and get this far. It doesn't pay
attention
I'm putting together a new system.
ntpq dies with:
ntpq: can't find Python NTP library -- check PYTHONPATH.
No module named util
Note is says "util", not "ntp.util". I've got ntpsec.pth and it works well
enough to fix the initial can't find error.
The build directory contains util.py and util
Hal Murray :
>
> I remove the SO_BINTIME mode. It's only supported by FreeBSD and they don't
> support it for IPv6. They do support SO_TIMESTAMP.
>
> The downside of that is reduced resolution on the time stamps. BINTIME gives
> 32 bit fractions of a second while TIMESTAMP gives microseconds
I remove the SO_BINTIME mode. It's only supported by FreeBSD and they don't
support it for IPv6. They do support SO_TIMESTAMP.
The downside of that is reduced resolution on the time stamps. BINTIME gives
32 bit fractions of a second while TIMESTAMP gives microseconds (roughly 20
bits). We
Kurt Roeckx writes:
> So as one of the OpenSSL people, it seems unrealistic to even have
> a compile time option to remove MD5 and SHA-1 at this time. Both
> are needed for TLS 1.0. It seems unrealistic that we can drop
> support for that in the next 5 years. We still support SSLv3, but
> it's disa
While I cannot speak specifically to NTP, SHA (without any suffix) has been
used on other contexts to mean SHA-1. I've also never encountered SHA-0
being used in any standard. So, if NTP is actually using it and it's not
just a misunderstanding, that would be a first for me. I suspect it is
SHA-1 t
Matthew Selsky :
> Where do we get SHA-0, aka "sha", keytype support from if we remove the
> in-tree public domain version?
To my knowledge the only SHA we have in tree is SHA-1. I think you can only
get SHA-0 via OpenSSL.
--
http://www.catb.org/~esr/";>Eric S. Raymond
_
Yo Matthew!
On Fri, 27 Jan 2017 21:19:55 -0500
Matthew Selsky wrote:
> > I can only find SHA1 in ntpsec. what am I missing?
> See NID_sha in tests/libntp/ssl_init.c
I just removed a bunch of unused SSL stuff. There is still a ton
of tests for things ntpd never does.
I see no other use of N
On Fri, Jan 27, 2017 at 05:20:48PM -0800, Gary E. Miller wrote:
> Yo Matthew!
>
> On Fri, 27 Jan 2017 20:05:14 -0500
> Matthew Selsky wrote:
>
> > LibreSSL dropped support for SHA-0 in 2.4.2, and that breaks the
> > build on OpenBSD 6.0
>
> I can only find SHA1 in ntpsec. what am I missing?
H
Yo Matthew!
On Fri, 27 Jan 2017 20:05:14 -0500
Matthew Selsky wrote:
> LibreSSL dropped support for SHA-0 in 2.4.2, and that breaks the
> build on OpenBSD 6.0
I can only find SHA1 in ntpsec. what am I missing?
RGDS
GARY
-
On Fri, Jan 27, 2017 at 03:57:36PM -0500, Daniel Franke wrote:
> On 1/27/17, Eric S. Raymond wrote:
> > Daniel Franke :
> >> Where is this notion coming from that OpenSSL is going to drop MD5 or
> >> SHA1
> >> support any time soon? That's inconceivable to me.
> >
> > I think it was either Achim G
On Fri, Jan 27, 2017 at 03:42:09PM -0500, Eric S. Raymond wrote:
> Daniel Franke :
> > Where is this notion coming from that OpenSSL is going to drop MD5 or SHA1
> > support any time soon? That's inconceivable to me.
>
> I think it was either Achim Gratz or Kurt Roecx (I can't easily search to fin
Daniel Franke :
> I just checked with an OpenSSL dev to make certain: dropping MD5 and
> SHA1 from libcrypto is not even remotely under consideration.
All right. I'm off to Friday night gaming, but given what Mark has said I'm
going to take this as my cue to remove the local copies when I get bac
On 1/27/17, Mark Atwood wrote:
> Daniel, if we make OpenSSL a requirement, can we drop libsodium?
Yes.
> Daniel, which rev of OpenSSL should we require? (Not 0.9.x et al)
1.0.1 and prior are no longer supported upstream so I'm not going to
make any effort to support them either. I don't think
On 1/27/17, Eric S. Raymond wrote:
> Daniel Franke :
>> Where is this notion coming from that OpenSSL is going to drop MD5 or
>> SHA1
>> support any time soon? That's inconceivable to me.
>
> I think it was either Achim Gratz or Kurt Roecx (I can't easily search to
> find
> out right now). Somebod
Daniel Franke :
> Where is this notion coming from that OpenSSL is going to drop MD5 or SHA1
> support any time soon? That's inconceivable to me.
I think it was either Achim Gratz or Kurt Roecx (I can't easily search to find
out right now). Somebody serious, anyway.
This is not an area in which I
OpenSSL is not going to drop them anytime soon. if/when they do, we can
add back inline support in better understood ways.
Daniel, if we make OpenSSL a requirement, can we drop libsodium?
Daniel, which rev of OpenSSL should we require? (Not 0.9.x et al)
If/when we encounter a target without Op
Where is this notion coming from that OpenSSL is going to drop MD5 or SHA1
support any time soon? That's inconceivable to me.
On Jan 27, 2017 3:21 PM, "Eric S. Raymond" wrote:
> Mark Atwood :
> > We do need to get wacking on the weeds on removing more of this thicket.
>
> Here are our constraint
Mark Atwood :
> We do need to get wacking on the weeds on removing more of this thicket.
Here are our constraints:
* Daniel has stated that he prefers the OpenSSL implementations of MD5 and
SHA-1. He's our crypto expert, so he gets to make that call and I would
have no grounds to even argue w
Yo Eric!
On Fri, 27 Jan 2017 14:42:16 -0500
"Eric S. Raymond" wrote:
> Gary E. Miller :
> > And, don't forget, libisc is still in the tree with its own copies
> > of md5 and sha1. Nuke it!
>
> Er, we can't do tha id we wabt the OpenSSL deoendency to be optional.
So why does openssl need to
Gary E. Miller :
> And, don't forget, libisc is still in the tree with its own copies of
> md5 and sha1. Nuke it!
Er, we can't do tha id we wabt the OpenSSL deoendency to be optional.
Otherwise, I'd be happy to get rid of that code.
--
http://www.catb.org/~esr/";>Eric S. Raymond
WolfSSL has a "we are compatible with any OSI approved license" codecil to
their license. I can get a formal signed commitment and document from the
CEO reinforcing it.
We do need to get wacking on the weeds on removing more of this thicket.
..m
On Fri, Jan 27, 2017 at 10:38 AM Gary E. Miller
Yo Mark!
On Fri, 27 Jan 2017 18:14:15 +
Mark Atwood wrote:
> If we are going to have an SSL dependency, I have a pretty strong
> preference towards WolfSSL
It may be the best, but it is not in Gentoo. I suspect few distros have
it. As we see from the libsodium mess, using non standard lib
On 1/27/17, Mark Atwood wrote:
> If we are going to have an SSL dependency, I have a pretty strong
> preference towards WolfSSL
WolfSSL is full GPLv2 with no or-any-lrater-version provision. Are you
comfortable with having a dependency licensed under those terms?
Possibly more importantly, Wolf
If we are going to have an SSL dependency, I have a pretty strong
preference towards WolfSSL
if we are going to have an OpenSSL dependency, it needs to be to the latest
stable OpenSSL release.
What would be using an SSL library for, that libsodium does not already
provide?
What all are we using
Eric S. Raymond :
> Daniel Franke :
> > If SHA-0 has ever been used in NTP that's news to me. It was broken pretty
> > quickly after publication and never saw much use. Pretty sure any
> > documentation which refers to it is confused.
>
> There were repeated references to "SHA and SHA-1". I don't
Daniel Franke :
> If SHA-0 has ever been used in NTP that's news to me. It was broken pretty
> quickly after publication and never saw much use. Pretty sure any
> documentation which refers to it is confused.
There were repeated references to "SHA and SHA-1". I don't see how that
could reasonablt
If SHA-0 has ever been used in NTP that's news to me. It was broken pretty
quickly after publication and never saw much use. Pretty sure any
documentation which refers to it is confused.
I would prefer that OpenSSL implementations of primitives get used when
available, for performance reasons whic
Mark: Heads up! PR issue.
Matthew Selsky :
> On Wed, Jan 25, 2017 at 11:47:01PM -0800, Hal Murray wrote:
> >
> > [From gitlab]
> > > It uses SHA1 but not SHA0 - SHA1 is an option for packet MACs. There
> > > should
> > > be no problem with using the ISC version unconditionally.
>
> https://do
Hal Murray :
>
> [From gitlab]
> > It uses SHA1 but not SHA0 - SHA1 is an option for packet MACs. There should
> > be no problem with using the ISC version unconditionally.
>
> I though I saw something about getting rid of --enable-crypto
It's gone. It actually turned out to be a no-op - I thi
On Wed, Jan 25, 2017 at 11:47:01PM -0800, Hal Murray wrote:
>
> [From gitlab]
> > It uses SHA1 but not SHA0 - SHA1 is an option for packet MACs. There should
> > be no problem with using the ISC version unconditionally.
https://docs.ntpsec.org/latest/ntpq.html's keytype lists "SHA". Does that m
Yo Hal!
On Wed, 25 Jan 2017 23:47:01 -0800
Hal Murray wrote:
> [From gitlab]
> > It uses SHA1 but not SHA0 - SHA1 is an option for packet MACs.
> > There should be no problem with using the ISC version
> > unconditionally.
>
> I though I saw something about getting rid of --enable-crypto
Ye
[From gitlab]
> It uses SHA1 but not SHA0 - SHA1 is an option for packet MACs. There should
> be no problem with using the ISC version unconditionally.
I though I saw something about getting rid of --enable-crypto
We currently require libsodium. Do we require libssl? If so, we can drop
the I
42 matches
Mail list logo
