e...@thyrsus.com said:
> Don't you think it makes sense to very our client code against a known-good
> implementation first, though?
Maybe. Maybe not.
If we had a known-good server and somebody who was sitting next to me knew all
about it and was prepared to help debug, sure that would be a
e...@thyrsus.com said:
> I think we'd best completely avoid writing an NTS-KE server until we have
> tested our client side against one of the two existing server
> implementations.
Then we have to learn how to drive the existing implementations, and learn
enough about how they operate so we
> Please open an issue. It's not something I can give priority to at the
> moment.
Done.
> In fact, it's not strictly speeking something we need to fix until we're
> worrieed about using a C library other than glibc. It does some weird things
> under the hood to make stdio operations
Thanks.
Please make sure this gets on your list. Do you have a list for NTS or should
I make an issue for it?
I haven't looked at the code recently. This seems like a good opportunity for
a review and cleanup and/or the addition of a good comment discussing the
thread area.
I think the
Eric:
> I plan to post a detailed analysis and task list later today. I'm working on
> that now.
I have hack code that makes a TLS connection and verifies certificates.
If/when things calm down, I'll start folding it in.
ntpd/ntpd.c has a main() in it.
Is the plan to have NTS-KE-server
> I plan to post a detailed analysis and task list later today. I'm working on
> that now.
One thing that would be very nice is for msyslog to be thread safe.
If we use a lock, we need to be able to recover in case we crash within
msyslog while the lock is held.
I'm not enough of a Unix
> Now, if it doesn't meet our accuracy thresholds, that's another story.
Do we have any accuracy standards?
Given the screwups that can happen with bufferbloat, I'll bet it works much
better than some network connections.
It would be interesting to measure the delays on dial up lines. I
> My instinct in situations like this is to try to find a way to reduce the
> combinatorial complexity of the problem. Which is why I'm attracted to
> disqualifying any time source that truncates years.
What's wrong with just adding 2000 to 2 digit years? We are in the 2000s now
so we don't
Richard said:
> That said, on a Pi, if you write the time to a file on shutdown, then you
> will be accurate enough for certificate checks to pass on reboots and outages
> shorter than a couple months.
Eric said:
> Thanks, it's important to know the order of magnitude of the slack there.
At
Another complication with getting started after a building/site wide power
loss is that getting time needs DNS and the local caching DNS server may be
waiting for valid time.
We may need a local cache - /etc/hosts? and a cron job to keep it up to date.
--
These are my opinions. I hate
> (I thought the RasPi stored a timestamp on a clean shutdown, then reads it
> back at boot time, so time is usually not actually zeroed. But I don't know
> that, and no such fallback is mentioned aty that link.)
You can check that by looking at your syslog and/or ntp log files.
The details
We'll need documentation to help people setup things to use NTS. I think the
client side will be simple, a sentence or two.
The server side is more complicated. I think we'll want HOWTO level docs.
Probably one using Lets Encrypt and maybe others for when you already have a
certificate
> The
> "enclair"
> option is intended to disable crypto negotiation so certificates are not
> required and traffic in sent en clair.
Please verify with a TLS wizard that you can do what you are describing with
OpenSSL.
Gary said:
> The whole point is that the client knows the C2S and S2C. Otherwise he can
> not key a session to the NTPD server. That is the plaintext. And he has the
> cookie, with the algorithm use to make it. That is the ciphertext.
So if the client knows the C2S and S2C, what is he
Gary said:
> Nothing says that a single cookie could not be used by a farm of clients to
> push the cookies per second into the thousands.
> Then add that this is millions of know plaintext and known ciphertext pairs
> That is not what the key reuse calculations assume.
I'm missing a step.
If so, how can we improve things?
The signal to noise on the mailing list has been pretty low recently. In
hindsight, I'm sure I've contributed more noise than I would like.
Note that even Eric is pushing code with warnings.
---
One thing that I find helpful is to scan the rest of my
Gary said:
> Remember, the cipher sets are runtime dynamic. They can change under you in
> an instant. So replace startup time with runtime.
How does that work? Once a program is running, it's linked to a specific
libsss and libcrypto. You can update the installed versions on disk but the
Gary said:
> Really? So unlimmited numbers of packets with identical C2S, S2S and master
> key, differing only int ehnonce is not a problem?
> Pretty much every crypto algorithm I know of has a recommended maximum number
> of uses. Allowing these two to be used unlimited times is violating
James Browning said:
> IIRC the previous key is kept for a rotation. Unless you are using something
> like poll 14+ it shouldn't be a problem.
Correct. That's for K, the key the server uses to encrypt/decrypt part of a
cookie. The client doesn't know anything about that key.
But there is
> Yes, you'd need implausible to impossible lifetimes of the client/server
> pairing for these to ever become a problem. But again, when key rollover
> gets implemented as indicated in the RFC, those will stop being useful on the
> second rollover.
What stops being useful when K rolls over is
> *tlsport XXX* Contact the NTS-KE server on TCP port XXX.
> *ntpport YYY* Request an NTPD server on UDP port YYY.
> Can anyone explain to me a case in which these are not equivalent to expcit
> port prefixes on a server, ask, re require address?
We've survived for a long time without being able
Eric:
> I'm not seeing anything in that 'graph which would ever *require* you to
> disable down-version TLS. The last normative is a MAY, not a MUST.
It starts with:
> Implementations MUST NOT negotiate TLS versions earlier than 1.2,
so we have to do something.
Me:
>> I assume the default
Eric said:
> So tell me: can we conform by *discovering* the cipher set at startup time
> and shipping that list to NTS-KE? Because if the RFCs don't for some insane
> reason *forbid* that behavior, it's clearly the right thing.
I don't know how to do that with a clean/simple API. I'm far
> I think this discussion really needs to take into account that the NTS-KE
> communication happens inside a TLS session, which is a layered communication
> channel w/ internal state. Possible solutions can be implemented at several
> of these layers. Taken at face value the current RFC would
># 1, the packet is a crypto-NAK; if 3, the packet is
># authenticated with DES; if 5, the packet is authenticated
The DES stuff is news to me.
NTP classic had stand alone code for MD5 and SHA1. We carried that along
until we decided to require libcrypto.
> I don't know how
>> If you ever do that, don't forget to merge in the fudge stuff.
> Sorry, I didn't understand that.
Your description of server/refclock/pool skipped over a wart. The grammar for
setting up refclocks has a side door for more options, the fudge command.
--
These are my opinions. I hate
Eric said:
> Can we toss out these cipher config options in favor of a mechanism that
> *discovers* what the available cipher are and does the right thing?
I believe that
server ntp.example.com nts
should work in many/most cases.
We'll have to provide sensible defaults for all of the
> Sorry, this is plain nonsense. You will not create enough messages for this
> to ever be a problem even on a terabit link. And the RFC already asks you to
> do a key rollover on a ~day timescale, so you have even less chance to
> produce so many messages.
Different keys. The rollover
Gary said:
> As a practical matter, in the current world where TLS 1.3 does not really
> exist, a max of 1.2 makes sense. Gonna be a long time before 1.3 works.
I assume that "max" is a typo for min.
1.3 is available in the latest versions of Fedora and FreeBSD. It's not in
the previous
Eric said:
> The docs still talk about MD5 and SHA-1, but the comments in ntpkeygen
> reference something called AES-128 which doesn't seem to be referenced at all
> in the docs or the NTP RFCs.
AES-128 is the replacement for SHA1. If there isn't an RFC, there is a
ready-to-publish draft.
>>*tls1.2* Allow TLS1.2 connection.
>>*tls1.3* Allow TLS1.3 connection.
> Second, why would you ever want one of these allow bits off? I want to hear
> a good story here not just to convince me that they're worth the complexity
> but so it can go in the documentation.
>From the draft:
> The only way to avoid this would be for me to go out of my way to create
> distinct grammar branches for *each declaration type*.
If you ever do that, don't forget to merge in the fudge stuff.
[Specifying nonsense options, like refid for a server.]
> Considering that we're talking
Gary said:
>>> *tls1.3* Allow TLS1.3 connection.
>> This does not feel scalable as new versions of TLS get created.
> Yeah. You prolly guessed I stole of lot of the options from elsewhere. This
> one also bugged me.
The API for SSL has way to set the min protocol version.
Eric said:
> I have added a note about MD-5 and SHA-1 being rather broken at this point,
> and a warning that MAC authentication may be removed in a future release.
What's wrong with MAC authentication when used with a good algorithm? Is the
security any worse than NTS?
I think we should
If I start with a name, translate that to an IP Address, make a TLS connection
to that system, I expect to get a certificate that matches the name. But that
translation step adds another layer of security considerations.
Is it practical to bypass the DNS lookup and use a certificate for the
Gary said:
> *ask [address]...
> *require [address]...
...
> More to come, but I'd rather not get too far ahead, as what I had thought was
> consensus has disappeared.
Thanks.
Those are all interesting, but I was more interested in the
nts foo
vs
server foo nts
part of the discussion.
Gary said:
> No. There are at least 5 new options for the nts.
> Worse, some of the options mean different things for server and nts.
Would you please write up a summary in a new thread. There has been a lot of
discussion in this area and I haven't seen anything that makes it obvious that
Gary said:
> But then how do I say I want 2 from this pool and 2 from that pool?
With the current code, you can't.
I don't think we should tangle that discussion with NTS.
>> If you need more, it does another DNS lookup.
> And, of course, that DNS thing is problematic with NTS...
I think
Gary said:
> Maybe expanded to ask for 3 pool servers:
> nts nts-ke.example.com pool 3
The current pool code doesn't work that way. Maybe it should, but it doesn't.
There is no way to specify how many servers you get.
There is a global variable specifying how many servers to get, Individual
Gary said:
> To refresh your memory, the python module version checks are new.
> That broke casual multiple python side-by-side installs.
It also exposed a potential bug. If you change the API to a module and forget
to install the other version you can get confusion.
--
These are my
Gary said:
> Not really. If you have a fixed public hostname, then Lets Encrypt is easy
> and quick. If you do not have a fixed public hostname, then game over.
Let's encrypt says you need a domain rather than just a public hostname.
> In order to get a certificate for your website's domain
Eric said:
> If there's another revision in process, I want to object to the binary
> request format. Raises endianness issues for no good reason. Better to use
> something like Motorola S-records for this.
I don't see how hex encoding helps anything. You still have the problem of
are
> No, re-keyed -- you specifically want to avoid the TLS renegotiation or even
> worse, reconnection. The session itself stays open. You could conceivably
> just open another connection inside the same session as far as TLS is
> concerned. I don't know which of the two options is more
> Are there any big chunks I didn't mention?
Getting libaes_siv to build on NetBSD.
Eric: Please be sure this gets on your list as must-happen-before you add code
that uses it. (An alternative is to add a build time option for NTS.)
--
These are my opinions. I hate spam.
Or does anybody know if that path has been tested? If so, when?
In case you don't recognize the term, it's when you get with --enable-mssntp
ntpd calls out to a Microsoft server to authenticate a response packet.
--
These are my opinions. I hate spam.
The Internet is big endian. Intel is little endian. When I say byte swap
below, I'm assuming they turn into no-ops on a big endian system.
We have to byte swap integers and floats. We don't swap arrays of bytes --
text or binary blobs like cookies.
On transmit, we have to do the byte
I think we should step back and look at the big picture.
Eric started working on the bits but got sidetracked on some cleanups.
I think we need to think hard about how/where/when we do the byte swapping.
More in another message. This isn't specific to NTS, but NTS is the first
time we have
Gary said:
> The ntpsec ebuild for Gentoo installs multiple python modules. I wonder if
> this recent change broke that?
I don't remember any recent changes in the install area.
The change was to add version checking. It has pointed out a real problem
with separate locations for python2 and
Gary said:
> I installed for Python 2.7, then I installed for Python 3.6. Then I ran with
> python3.6, but my PYTHONPAATH was still for 2.7.
Do typical installations run mixed python 2 and 3 like that, or is that only
used for testing?
---
I think the mixed case can be made to work
Gary said:
> Great, the python library mismatch code works:
> Library/Binary version mismatch
> Binary: ntpsec-1.1.3+ 2019-01-30T21:25:37Z (git rev ab0ea27cf)
> Library: ntpsec-1.1.3+ 2019-01-30T21:20:27Z (git rev ab0ea27cf)
What did you do to get that?
The version strings come
>> Also, Python 3.6.7 on FreeBSD
> Context? Is that a pass or a fail?
Fail. Somebody was looking for a test case.
It (and the previous one on NetBSD) both work from my normal script which
tee-s the output to a log file. Both fail when ssh-ed to that box and run
./waf without the tee.
Also, Python 3.6.7 on FreeBSD
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
> Btw, I tried to reproduce this failure with 3.5.6, 3.6.7, and 3.7.1, without
> success. Do you have any tips for reproducing? Input/output redirection?
> Environment variables?
I can get it on NetBSD 8.0 with a simple ./waf configure build
That's over ssh
Python 3.7.0 (default, Sep 26 2018,
Would some CI wizard please add running tests/option-tester.sh
on the most convenient OS/distro. Or maybe once per OS.
-
[64/93] Compiling ntpd/ntp_proto.c
../../ntpd/ntp_proto.c: In function âfast_xmitâ:
../../ntpd/ntp_proto.c:2267:15: error: assignment to expression with
Gary said:
>> https://secure-web.cisco.com/...
> That is NOT the link I sent! Someone's email is messing with links!
> Why would something called "secure-web" be doing non-secure things???
It's not uncommon for malware/spam filters to do things like that. They don't
touch the links
Gary said:
> Update:
> Works: 2.7, 3.7
> Fails: 3.5, 3.6
It was working a week or two ago.
Did we change anything? (I don't think so.)
Did something in Python change?
--
These are my opinions. I hate spam.
___
devel mailing list
Gary said:
>> How about:
>>server ntp.example.com nts 1.2.3.4
>> or
>>server ntp.example.com nts bob.example.com
> Why do we need ntp.example.com at all? Aren't we supposed to use the NTPD
> server returned from bob.example.com?
The intent was to do the NTS-KE dance with
> I'd suggest using a new keyword for that and leaving the existing ones
> behijnd for NTP w/o encryption.
Then we'll need 2 new keywords. We want NTS to work on pool sites too.
--
These are my opinions. I hate spam.
___
devel mailing list
e...@thyrsus.com said:
>> Your "empty cookie string as a sentinel" doesn't work unless you allocate
>> space for the extra slot.
> Eh? We know what the maximum number of cookies is. I think all we have to do
> is notice which cookies are empty (have initial NUL). But I might be wrong
> about
> +#define NTS_COOKIELEN128 /* placeholder - see RFC 6 */
Again, that should be MAX, and we need lengths.
Our client talking to another server implementation may get a different length.
--
These are my opinions. I hate spam.
___
devel
How should we tell the system we want to use NTS when talking to a server?
The catch is that we potentially need two names/addresses.
I think the simple case is just:
server ntp.example.com nts
That will do a NTS-KE exchange with the system at ntp.example.com and use the
IP Address it
Eric said:
>> They are mostly binary blobs: cookies, keys, nonces, ...
>> It might be worth packaging blob and length into a struct.
> OK. That's inside-NTS work - do as you like there. I need to concentrate
> elsewhere for a bit.
How about packaging the blob of bits with a 4 byte header: 2
Gary said:
> Something odd with ntmn today. See attached. I expec this cut/paste gets
> mangled in email:
How recent is your git pull? Eric was working on refids recently.
--
These are my opinions. I hate spam.
___
devel mailing list
> Are there any features in waf 2.x that you were looking forward to? Or do
> you just want us to avoid getting too far behind?
Just trying to avoid getting too far behind.
If nothing else, I'd like their online documentation to correspond to the
version I'm trying to debug.
-
I
e...@thyrsus.com said:
>> Do we want to store cookies and passwords and such in a fixed max-size
array
>> or as heap allocated blobs? In any case, we need to remember the lengths.
> Depends - if they're textual we can assume a '\0' sentinel. I'd prefer to do
> that if possible, it would
Matt: Thanks.
Eric: That was an example of why we might want an option for NTS work.
Did the CI pipeline work for you? Or did you overlook the failed message or
were you away from email, or ...
If so, how did my pthread change trigger this problem?
--
These are my opinions. I hate spam.
You have a couple of trailing spaces.
We should start collecting max/min/required lengths and references to where
that number comes from.
Do we want to store cookies and passwords and such in a fixed max-size array
or as heap allocated blobs? In any case, we need to remember the lengths.
Does NTS refer to an NTP system that supports the new draft, thus leaving NTP
to refer to old NTP systems that don't support it? Or does NTS refer to just
the new draft and we can assume (from context) that NTP refers to either the
old pre-draft systems or the new post-draft systems that do
https://gitlab.com/NTPsec/ntpsec/-/jobs/151892721
Can somebody give me some help with this. This is after my pthread cleanup,
but I don't think I changed that area which probably means that I'm missing
something interesting.
[54/87] Compiling ntpd/ntp_io.c
In file included from
It's up to version 2.0.14, Dev 2018, about a year since the version we are
using.
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
I'd like to get rid of wafhelpers/check_pthread.py
There may have been some PTHREAD conditionals in our code ages ago, but they
are all gone.
The main thing check_pthread is doing is setting up to use libthr rather than
libpthread.
FreeBSD uses libthr.so rather than libpthread.so. But it
e...@thyrsus.com said:
> I do. But I'm not worried that introducing NTS code will destablized non-NTS
> code, either.
It wouldn't surprise me if we used a routine that wasn't in older versions of
libssl.
--
These are my opinions. I hate spam.
Eric said:
> What would a build option gain us? Is there some specific prerequisite
> you're worried about?
It seemed like good insurance. If we want to fix a bug, you seem to prefer to
release the current git head rather than making a branch.
There is a specific example. Daniel's
To answer the question in the subject...
I think we will want it in the short term in order to keep builds working on
all current platforms until we get things sorted out.
--
These are my opinions. I hate spam.
___
devel mailing list
> I think we covered this in https://gitlab.com/NTPsec/ntpsec/issues/421
I think that's a different issue. OpenBSD doesn't support that API at all.
The STA_NANO case I'm interested in is several ifdef-s in ntp_loopcontrol No
big deal, just some clutter we might be able to remove.
The
Gary said:
> That one failure is on Gentoo stable. Oddly I have many other Gentoo stable
> that do not show the same problm.
That's consistent with what I'm seeing.
> I'm guessing it is more an environment setting than distro dependent.
Could be, but I can't think of anything I've changed
e...@thyrsus.com said:
>> Perhaps we should review this area. What will we want to see
>> when NTS is deployed.
> You and Achim are probably the best judges of that we have. So write a
> strawman and put it in nts.adoc.
I don't plan to put anything related to this into nts.adoc
ntp_control
> So, lockclock is not known as a system variable of course.
I just pushed a fix for that.
$ ntpq
ntpq> rv 0 lockclock
lockclock=0
ntpq>
ntp_control really needs a big cleanup. There are several tables that must be
kept in sync by hand. I added issue #539 for that. (It may be a duplicate,
Gary said:
> I'm getting an odd build error on one of my hosts. Ideas?
I asked about the same quirk yesterday evening. No responses.
What OS/Distro are you using?
I've seen it on NetBSD and FreeBSD. I thought I had one on Linux, but didn't
have an example handy when I typed things in.
> James, you are correct. Privileged ntpq functions require the crypto.
Not quite.
Privileged operations require a password, but it is sent in the clear. There
is no crypto on that path. The packet format doesn't support it. We could
fix that at the cost of breaking compatibility.
The
Achim said:
> Well, it turns out ntpq has regressed from classic and doesn't understand at
> least some of that syntax anymore:
> NTPsec~> ntpq -c 'rv 0 offset'
> server=0 status=0415 leap_none, sync_uhf_radio, 1 event, clock_sync,
> version="ntpd ntpsec-1.1.3+ 2019-01-21T16:51:20Z (git rev
I'm thinking of updating INSTALL and/or devel/hacking.adoc to say something
about pthreads and OpenSSL.
If we did away with shared key authentication, we could potentially do away
with needing libcrypto. Aside from authentication, we also use RAND_bytes()
so we would need to substitute
e...@thyrsus.com said:
> In particular, some of our targets (some BSDs, I don't remember which) have
> only microsecond, not nanosecond resolution in the clock-adjustment calls.
NetBSD and FreeBSD have NANO.
Matthew Selsky suggested Solaris. Can anybody confirm that?
Anybody know of others?
> The C code has no #ifdefs for HAVE_PTHREAD or HAVE_PTHREAD_H, so we're only
> talking about cleaning up some waf python code, correct?
Yes, or eliminating it.
Simplifying "little" things like this often allows simplification in some
other area.
> libthr is a FreeBSD thing...
Anybody recognize this? I've seen it on NetBSD and FreeBSD
I haven't figure out what I'm doing to make it happen.
Waf: Leaving directory `/home/murray/ntpsec/foo/build/main'
Traceback (most recent call last):
File "/home/murray/ntpsec/foo/.waf3-1.9.15-7481b2b5d90177d4bb747dbff06bef90/w
We have various cruft associated with threads. Can we add POSIX threads to
our list of requirements? Or is it already included in POSIX.1-2001 and
ISO/IEC 9899:1999 (C99)?
The idea is to remove HAVE_PTHREAD_H and HAVE_PTHREAD from config.h and remove
most of wafhelpers/check_pthread.py
Eric said:
> It's never been an an *ntpq* "system variable" that can be queried through
> that interface, I meant.
It's easy to add new variables. Old ntpq may not show them in any of its
packaged printout like peers or kerninfo, but you can get them by asking
explicityly.
There are also 2
> Alas, it's not a system variable.
Looks like it is:
include/ntpd.h:extern bool lockclock; /* lock to the system
clock? */
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
> Before I forget: I really don't care about when I've configured the project.
> Can that date please be the date of the corresponding commit (if it's there
> at all) and the version string something that git describe puts out, like
> NTPsec_1_1_3-35-g6c029ef4c (which is way more helpful to me
ntpq gets pll offset via ntp_control using CS_K_OFFSET which gets it from
ntx.offset
ntx comes from ntp_adjtime which is only updated if a big conditional which is
all local and looks good. But check for MODE6 errors in the log file.
There is nothing lockclock in that local area.
So my
Eric said:
> Therefore...would you please take a hard look at the change and see if you
> can repair it? I hate to slough off my mistakes on anybody, but the fix
> needs to be applied by somebody who can test it.
Alternatively, this is a good opportunity for you to learn more about how ntpd
Looks good on a modern browser. The diagram doesn't render on a very old
browser which can show the stand-alone diagram. Is there something tricky
about the include-it recipe?
I think we should keep the plain text version around for a while. How
complicated is the conversion process?
--
I moved the comments about configuration away from the packet processing area
to a new block on configuration. There are probably rough edges.
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
> So enforcing key rollover isn't a concern. The recommended server key
> rotation is primarily about forward secrecy then, I presume.
Draft says:
Erasing old keys provides for forward
secrecy, limiting the scope of what old information can be stolen if
a master
> My thought about how to enable NTS for the pool would involve requiring a SRV
> record lookup for NTS-KE
That SRV lookup could return multiple names. Each would point to a separate
NTS-KE server.
An alternative approach would be to extend the NTS-KE protocol to support
multiple answers.
> Imagine a server that uses the suggested cookie approach and simply never
> rolls over K. As long as the client daemon is running, its cookies will be
> valid and keep getting renewed. C2S and S2C will never get rolled over.
> Should the client track an expiration limit in memory, and when
> The NTS-KE servers would have to share NTS master keys (and cookie formats!)
> with volunteer NTP servers.
If you are interested in security, sharing a master key with many servers
seems like a bad idea - too many opportunities for a leak. With something
like the pool where anybody can
Richard Laager said:
> * Is NTPsec going to use the suggested cookie format?
Sure, but it isn't a detailed spec.
>* Is NTPsec going to force C2S/S2C key rollover (e.g. by adding an
> expiration time to its cookie format) or leave expiration to clients?
Maybe, but not initially. We need a
Eric said:
> I alsop haven't seen anything yet that that relieves my worries about our
> draft-conformant NTS failing to interop with someone else's draft-conformant
> BTS due to varting cooke formats.
Not a problem.
The cookie format is private. Neither client box needs to know anything
Gary said:
>> The question is where to C2S and S2C come from.
> Nope. Section 5.1, they come from RFC 5706 using the PRF() function.
> The question is where the master key used by PRF() comes from.
"Master key" is the wrong term. PRF uses the TLS session keying material.
--
These are my
901 - 1000 of 2328 matches
Mail list logo
