The translation of the AEEF ciphertext into corresponding plaintext is
given by the negotiated AEAD algorithm; for AES-SIV, by RFC 5297. The
structure of the plaintext is defined in the draft, as a concatenation of
RFC 7822 extension fields.
On Sun, Jun 23, 2019, 16:42 Ian Bruene via devel wrote:
Option 2. If the manufacturer won't support the product any more, we
shouldn't either.
On Thu, Aug 8, 2019 at 8:36 AM Eric S. Raymond via devel
wrote:
>
> Issue #608, "Future need for oncore GPS driver", foregrounds a product
> strategy question we need to make a decision about.
>
> In the early
On Mon, Sep 16, 2019, 22:50 Hal Murray via devel wrote:
>
> The disadvantage of SHM is that there is no way to wake up a reader when
> new
> data is available. Readers have to poll.
>
This is exactly what futexes are for.
>
___
devel mailing list
dev
This is a security bug and needs a point release and a CVE.
On Tue, Oct 29, 2019, 05:06 Hal Murray via devel wrote:
>
> Announcement below.
>
> It triggered a bug. When copying the hostname out of the NTS-KE server
> response, I forgot to add a NUL. I assume we tested that code. I guess
> we
On Sun, Dec 8, 2019 at 7:58 AM Hal Murray via devel wrote:
> The current code now requires ALPN if using TLSv1.3. ***
Why only TLS 1.3? The spec makes it mandatory for all versions.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/m
On Sun, Dec 8, 2019 at 9:15 AM Hal Murray wrote:
> Because ALPN is not supported by TLSv1.2
Nonsense. ALPN predates TLS 1.3 by several years and RFC 7301 doesn't
even restrict it to TLS 1.2 and up; it even can support 1.0.
___
devel mailing list
devel@n
I've forwarded your message to Watson Ladd.
On Mon, Dec 9, 2019, 17:38 Paul Theodoropoulos via devel
wrote:
> I just noticed that Cloudflare's documentation for NTS -
>
> https://developers.cloudflare.com/time-services/nts/usage/
>
> links to the NTPsec quickstart page -
>
> https://docs.ntpsec.
Hal,
Yes, we'll be getting a new port number, but the more important item
for IANA is the NTP extension registry. I know NTPsec and several
other NTS implementations are all squatting on a set of EF type
numbers and we probably don't want these to change. You and other
maintainers should coordinat
There's nothing to fix. It's the just optimizer telling you it'd rather not
inline a function that was declared inline. Which is fine, it doesn't
affect correctness.
On Wed, Apr 29, 2020 at 8:32 PM Hal Murray wrote:
>
> What's the right fix for this?
> gcc (GCC) 10.0.1 20200328 (Red Hat 10.0.1-0
It's present on Linux, FreeBSD, NetBSD, and Darwin. It's absent on
Solaris and IllumOS.
On Tue, Aug 25, 2020 at 8:03 PM Hal Murray via devel wrote:
>
>
> When was clock_gettime and struct timespec introduced?
>
> We can cleanup some cruft if we assume it exists.
>
> --
> These are my opinions. I
clock_gettime is. Adjtimex isn't in any standard except for an obscure RFC
that nobody follows.
On Tue, Aug 25, 2020, 20:47 Eric S. Raymond via devel
wrote:
> Hal Murray via devel :
> >
> > When was clock_gettime and struct timespec introduced?
> >
> > We can cleanup some cruft if we assume it e
The normative content of the RFC is not going to change. There's no
reason to hold back any release while waiting for publication.
On Fri, Sep 18, 2020 at 11:43 AM Hal Murray via devel wrote:
>
>
> Maybe we should get 1.2 out now/soon so it will be ready when the RFC comes
> out rather than short
I've already said yes, but the yes was contingent on IANA fixing an
error in a descriptive field so the change in the datatracker is
waiting on that happening.
On Tue, Sep 22, 2020 at 7:35 PM Hal Murray via devel wrote:
>
> Subject: Re: Coordinating some blog posts celebrating the publication of
Rust uses cfg attributes for most such things.
https://doc.rust-lang.org/rust-by-example/attribute/cfg.html
On Sun, Jun 20, 2021, 21:12 Hal Murray via devel wrote:
>
> How do Rust and/or Go handle the cruft that C coders use #ifdefs for?
>
> Does that just get pushed down to a C library?
>
>
>
On Tue, Jul 6, 2021 at 1:40 PM Richard Laager via devel
wrote:
>
> On 7/5/21 8:38 AM, Eric S. Raymond via devel wrote:
> >> There is a close-to-RFC to handle this area. "Interleave" is the
> >> buzzword. I
> >> haven't studied it. The idea is to grab a transmit time stamp, then tweak
> >> the
If we're aiming for a September 28 release then I propose we should
have a dev freeze by September 1. Bug fixes only during that month;
anything that's mere polishing goes on a branch.
I don't want to release 1.0 without having
https://tools.ietf.org/html/draft-ietf-ntp-data-minimization-01
implem
There aren't many deficiencies in NTPv4 which can't be fixed by adding
extension fields. A change big enough to make a version bump
worthwhile would incorporate at least most of the following:
1. Drop everything other than client/server mode. Replace mode 6 with
something that runs over HTTPS on t
On 8/26/17, Hal Murray wrote:
> Is there a good high-level writeup of NTS?
https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp-09#section-1.2
> Why encrypt stuff? (as compared to verify)
NTS authenticates everything and encrypts as much as possible without
breaking backward compatibi
CVE-2018-7182 only.
On Tue, Mar 6, 2018 at 3:10 PM, Richard Laager via devel
wrote:
> I tried this to security-discuss, but I'm not sure if it went through:
>
> The Debian security team has asked me which of the February 2018
> ntp-4.2.8p11 vulnerabilities apply to NTPsec:
>
> http://support.ntp.
You probably don't want to auto-pull the latest HEAD every time it gets an
update; only releases get the full battery of QA. Note I'll probably be
stamping a release this weekend since the last release from two years ago
has a build issue with more recent OpenSSL versions.
On Thu, Feb 14, 2019, 17
Release tags match v.., so just check the tag list for
the most recent v1.y.z. Don't automatically go to 2.anything since releases
are semantically versioned and that would indicate backward-incompatibility.
On Thu, Feb 14, 2019, 17:24 Eric S. Raymond Daniel Franke :
> > You probably don't want t
On Thu, Feb 14, 2019 at 9:15 PM Hal Murray via devel wrote:
> How do I tell it that I don't want the doc?
> (I don't have a2x on that system.)
You shouldn't have to tell it anything. All the manpage
target-generation directives are wrapped in if(A2X). If a2x isn't
found, those targets won't be
This looks like namespace pollution of some kind -- perhaps one of
NetBSD's standard C headers defining a bswap64 macro that conflicts
with my definition. Can you send me what aes_siv.c looks like on your
system after preprocessing?
I'm not going to support CMake 2, but CentOS has CMake 3 availabl
It's exactly like I suspected: a system header is #defining bswap64 as
a macro, causing a syntax error in my local definition. This is a
upstream bug twice over. First, nothing should be giving you
if you don't ask for it. Second, the manpage clearly
states that bswap64 is a function, so it's unac
Hal, try putting
#define _ANSI_SOURCE 1
#define _ISOC99_SOURCE 1
at the very top of aes_siv.c and let me know if that fixes the build error.
Looks like the way is getting in is via
via via via
. But guards it with
#if defined(_NETBSD_SOURCE)
#include /* for quad_t, etc. */
#endif
while
Excellent. I just pushed the fix to HEAD.
On Fri, Feb 15, 2019 at 5:54 PM Hal Murray wrote:
>
>
> dfoxfra...@gmail.com said:
> > Hal, try putting
> > #define _ANSI_SOURCE 1
> > #define _ISOC99_SOURCE 1
>
> ...
> [100%] Linking C executable demo
> [100%] Built target demo
> -bash-4.4$ make test
>
This is on Linux? Make sure /usr/local/lib is in your /etc/ld.so.conf
and then run ldconfig.
On Sat, Feb 16, 2019 at 9:46 AM Hal Murray wrote:
>
>
> I'm getting closer to actually using it.
>
> Of course, it didn't work or you wouldn't be reading this message.
>
> The symptom is that it links but
His problem had nothing to do with waf or ntpd. ld.so.conf is magic
used by the ELF loader to locate the libraries it needs -- at runtime,
not at link time.
On Sat, Feb 16, 2019 at 10:09 AM Eric S. Raymond wrote:
>
> Hal Murray via devel :
> > The symptom is that it links but doesn't run. At run
The BSDs work the same way Linux does except on FreeBSD the
configuration file is called /etc/ld-elf.so.conf and you run 'ldconfig
-elf' after you've changed it.
Your distribution owns /usr and packages not installed through your
distribution's packaging system shouldn't touch it and should defaul
The current HEAD of libaes_siv is a release candidate. Whether or not
it becomes the release depends on what I decide to do about the CentOS
6 issue, which in turn depends on the OpenSSL team getting back to me.
I'm also waiting on Hal to run it through his build farm again to let
me know if last-m
Try the new HEAD (3562205). I changed ANSI to POSIX.1-2001 which
should hopefully make FreeBSD happy again while still suppressing the
colliding symbols on NetBSD.
What version of OpenSSL are you building against on FreeBSD? I want to
go through sources to figure out exactly why it fails.
On Mon,
You can assume it's a verification failure because "failure in
underlying machinery" shouldn't be possible. The call doesn't allocate
memory and doesn't make any system calls. There's nothing that can
fail.
On Mon, Feb 18, 2019 at 3:53 PM Hal Murray wrote:
>
>
> There is a rough edge that I don't
Okay, not surprised that's where the breakage was introduced, since
OpenSSL 1.1.0 rearchitected how it handles threading:
https://www.openssl.org/blog/blog/2017/02/21/threads/
Did my commit switching _ANSI_SOURCE to _POSIX_SOURCE resolve the build failure?
On Mon, Feb 18, 2019 at 11:53 PM Hal Mur
On Wed, Feb 20, 2019 at 12:48 AM Hal Murray via devel wrote:
> The K and I used to encrypt cookies is a hack constant so old cookies work
> over server reboots.
I assume this is temporary while you work on this code, right?
Obviously if K is a hardcoded constant you have no security.
> With the
On Fri, Mar 1, 2019 at 7:01 PM Gary E. Miller via devel
wrote:
> "noval" is not mostly for debugging. It is essential for off
> network operation.
There's no point in doing NTS if you're not doing certificate
validation. The result isn't any more secure than unauthenticated NTP.
Which ones do you intend to relax? And in any case you don't need a whole
CA, you can pin a self-signed cert and still do full validation on it.
On Fri, Mar 1, 2019, 23:41 Gary E. Miller via devel
wrote:
> Yo Daniel!
>
> On Fri, 1 Mar 2019 21:26:15 -0500
> Daniel Franke wrote:
>
> > On Fri, Mar
On Fri, Mar 1, 2019 at 11:39 PM Gary E. Miller via devel
wrote:
> Not complete security, but at least encryption. And there are
> levels of validation. If you are off net, you can't completely
> validate the cert, but you can partially validate it. Maybe you
> would want to pin it.
Encryption
On Sat, Mar 2, 2019 at 12:36 PM Gary E. Miller via devel
wrote:
> Yes, but you seriously reduce the attack time window. Instead of
> a possible MitM every few seconds, you need to grab the one time the
> cookies are shared.
No you don't, because a MitM who appears at any time can drop time
packe
On Sun, Mar 3, 2019 at 8:45 AM Kurt Roeckx via devel wrote:
> On Sun, Mar 03, 2019 at 05:23:31AM -0800, Hal Murray wrote:
> >
> > k...@roeckx.be said:
> > > If this is something you're worried about, this can be solved with the
> > > interleave mode, which was removed.
> >
> > How well does it wor
If you try to measure the cost of the authentication code using log
messages you're going to get total noise, because the cost of logging
a message is higher than the cost of doing the authentication. Each
invocation of AES-SIV should take, in round numbers, 250 CPU cycles,
and processing a typical
On Sun, Mar 3, 2019 at 9:44 PM Eric S. Raymond wrote:
> (Also, it turns out not to be important at post-Y2K machine speeds to
> get those arrival timestamps from the UDP layer ASAP, rather than
> looking at packet read time in userspace. The cost of the latter,
> naive approach is
One thing to keep in mind is that if the client is using SO_TIMESTAMP
but the server isn't, or vice versa, you're going to introduce a
persistent inaccuracy on the order of a microsecond, due to the
resulting asymmetry in the point at which the timestamp is captured.
On Mon, Mar 4, 2019 at 8:36 AM
Yes, if you go back that far then there's been significant change.
Nonetheless, that change isn't relevant. The current granularity of
1ms is still coarse enough that it would be obvious if it were a
factor. Multicore processors are the reason it isn't.
On Mon, Mar 4, 2019 at 9:25 AM Eric S. Raymo
On Mon, Mar 4, 2019 at 9:25 AM Eric S. Raymond wrote:
> The NTP packet-stamp code dates from the before time, when sampling lag
> due to timeslice granularity was an order of magnitude or more worse
> than it is now. From some of its details I'd guess it was written about
> '87 or '88.
I just ch
The intended design for running NTS with pool servers is that only the
pool operator runs an NTS-KE server. The NTS-KE server then picks an
NTS-enabled NTP server out of the pool and serves you an appropriate
NTPv4 Server Negotiation Record. Individual server operators, on a
one-time basis, establi
On Mon, Mar 4, 2019 at 4:28 PM Gary E. Miller via devel
wrote:
> The name in ntp.conf MUST match the name in the cert. Unless you
> override it ("noval", pin, etc.).
>
> > The normal getaddrinfo and friends automatically follow CNAMEs.
> > Thus my comment about needing some DNS code.
>
> Which o
I'll post a rebuttal sometime later this week. As for IETF processes,
though, you're years late. The WG already had a consensus call in 2016
on what NTS-KE's framing format should look like, and it was
unanimous. You can still comment during IETF Last Call and try to
convince the IESG to block the
On Tue, Mar 5, 2019 at 7:21 AM Eric S. Raymond wrote:
> You yourself advocated that Mode 6 ought to be replaced by an HTTP
> service on TCP port 123. I think that's a good idea, if we can do
> it. The problem is than NTS-KE *also* wants to have TCP 123.
Like Hal pointed out, ALPN makes this a non
On Tue, Mar 5, 2019 at 1:52 PM Eric S. Raymond wrote:
> If you end up going with a non-123 port number, I requst that the RFC
> allow use on other ports when and if ALPN is available and specify
> the ALPN tag to be used.
The spec already mandates that ALPN always be used and allocates a tag
with
On Tue, Mar 5, 2019 at 2:28 PM Eric S. Raymond wrote:
> Thanks. I didn't see that in the RFC draft. Did I simply miss it or is
> it in a registry that is entirely separate?
Last sentence of section 3, first sentence of section 4, and section 7.2.
___
On Tue, Mar 5, 2019 at 4:10 PM Hal Murray wrote:
> How does that work in practice? 443 is for HTTPS. Does Apache have a call
> out mode? Is there a standard utility that does ALPN dispatching? What
> fraction of clients send ALPN info?
I've never tried it myself, but I think Nginx can handle
Still accurate.
OTOH, OS X finally got clock_gettime() in 10.12.
On Tue, Mar 5, 2019 at 4:28 PM Hal Murray via devel wrote:
>
>
> wscript says MacOS doesn't have it.
>
> timer_create seems pretty basic. Is that still accurate? Or perhaps leftover
> from an old version that is no longer support
On Wed, Mar 6, 2019, 03:33 Hal Murray wrote:
>
> dfoxfra...@gmail.com said:
> > The intended design for running NTS with pool servers is that only the
> pool
> > operator runs an NTS-KE server. The NTS-KE server then picks an
> NTS-enabled
> > NTP server out of the pool and serves you an appropri
A different RFC, eventually. But I'm not in a rush. Let people managing
large scale deployments figure out what works for them and then standardize
around it later.
On Wed, Mar 6, 2019, 13:25 Achim Gratz via devel wrote:
> Daniel Franke via devel writes:
> > That's correc
On Thu, Mar 7, 2019 at 3:10 PM Gary E. Miller via devel
wrote:
> My idiosyncratic read of the FHS would, by default, put the master keys
> in /usr/local/var/lib:
>
> "State information. Persistent data modified by programs as they run,
> e.g., databases, packaging system metadata, etc. "
I have n
On Thu, Mar 7, 2019 at 5:14 PM Gary E. Miller via devel
wrote:
> Wikipedia makes no mention, even sideways, of /var/local.
>
> Nor does the base document, FHS 3.0:
> https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.pdf
>
> See section 5. "The /var Hierarchy".
It's specified in the tab
On Tue, Mar 5, 2019 at 2:37 AM Daniel Franke wrote:
>
> I'll post a rebuttal sometime later this week. As for IETF processes,
> though, you're years late. The WG already had a consensus call in 2016
> on what NTS-KE's framing format should look like, and it was
> unanimous. You can still comment d
I recommend having no default at all for the trust store location and
forcing to be set in the config file. Too much risk otherwise of
finding something that looks like a store but isn't actually
trustworthy and entering an insecure state without the user realizing
it. Leave it up to packagers to p
Everything about init scripts should be assumed distro-specific and
'make install' should not be attempting to touch them. Leave that up
to distro packagers.
On Wed, Mar 20, 2019 at 2:57 PM Gary E. Miller via devel
wrote:
>
> Yo Hal!
>
> On Tue, 19 Mar 2019 22:07:26 -0700
> Hal Murray via devel
59 matches
Mail list logo
