Hal, does Daniel have any comment on the suitability of the new
AES-GCM-SIV for cookies and/or NTP packets?
Upon further research, even setting aside the message count topic,
AES-GCM is probably inappropriate for the cookie encryption.
The AES-GCM RFC (RFC 5116) says (page 13):
The inad
On 2/2/19 9:09 PM, Gary E. Miller via devel wrote:
>> In the context of
>> attacks on C2S/S2C, if the client willingly shares C2S/S2C in
>> plaintext with someone else (other than the server), the client has
>> already compromised C2S/S2C by its own actions. There is nothing in
>> the protocol whic
Richard Laager via devel :
> And the question would be how to deal with a request for a port only.
> There seem like two ways to allow that:
>
> 8: ask 10123
> 9: ask :10123
>
> #9 is not ambiguous with anything, but looks weird and is almost
> ambiguous with #5, as ::10123 is an IPv6 address (al
Richard Laager :
> So given that tlsversions OR (tlsmin AND tlsmax) cover all the scenarios
> of forcetls, but the reverse is not true, I think you should pick one of
> those options instead of forcetls.
Done. I'll implement mintls and maxtls - that change is easy.
--
http://www.
On 2/2/19 9:11 PM, Gary E. Miller via devel wrote:
>> tlsversions "1.2 1.3"
> Which would have broken when SSL became TLS, and will break when TLS
> becomes XXX.
Not really. Roll back the world to SSLv3 being the latest:
I would be proposing this:
sslversions "2 3"
Then the IETF changes the nam
Yo Richard!
On Sat, 2 Feb 2019 20:52:33 -0600
Richard Laager via devel wrote:
> On 2/2/19 7:25 PM, Richard Laager via devel wrote:
> > # Requiring a bounded set of audited TLS versions
> > # (the DOD STIG scenario, unverified as to actual requirement)
> > tlsmin 1.2 tlsmax 1.3
> > OR
> > tlsvers
Yo Richard!
On Sat, 2 Feb 2019 20:50:15 -0600
Richard Laager via devel wrote:
> [I have re-ordered the quoted text to fit my response ordering.]
>
> On 2/2/19 7:13 PM, Gary E. Miller via devel wrote:
> >> Hal's comments and the quote from Daniel are about whether it is
> >> necessary to require
Yo James!
On Sat, 2 Feb 2019 18:39:56 -0800
James Browning via devel wrote:
> > I assume you mane this:
>
> Yep, this is it.
Good, we're getting on the same page.
> > Good. More correct to say stop using the same C2S/S2C
>
> Sometime after I wrote that I have the idea of using an MJD nu
On 2/2/19 7:25 PM, Richard Laager via devel wrote:
> # Requiring a bounded set of audited TLS versions
> # (the DOD STIG scenario, unverified as to actual requirement)
> tlsmin 1.2 tlsmax 1.3
> OR
> tlsversions "1.3"
This should be:
tlsmin 1.2 tlsmax 1.3
OR
tlsversions "1.2 1.3"
> # Notably, for
[I have re-ordered the quoted text to fit my response ordering.]
On 2/2/19 7:13 PM, Gary E. Miller via devel wrote:
>> Hal's comments and the quote from Daniel are about whether it is
>> necessary to require rotation of C2S/S2C, not K.
>
> Yes.
This discussion was originally about why it is not
On 2/2/19 6:39 PM, Gary E. Miller via devel wrote:
> Yo Richard!
>
> On Sat, 2 Feb 2019 17:52:57 -0600
> Richard Laager via devel wrote:
>
>> On 2/2/19 7:22 AM, Achim Gratz via devel wrote:
>>> Eric S. Raymond via devel writes:
*tlsport XXX* Contact the NTS-KE server on TCP port XXX.
On 2/2/19, Gary E. Miller via devel wrote:
> Yo James!
>
> On Sat, 2 Feb 2019 13:44:12 -0800
> James Browning via devel wrote:
>
>> >> What you almost need is a cookie extension to trigger a rekeying
>> >> periodically.
>> >
>> > Yes. Sad the Proposed RFC is silent on the subject. Seems a gapin
On 2/2/19 6:55 PM, Eric S. Raymond wrote:
> Richard Laager via devel :
> Can anyone explain to me a case in which these are not
> equivalent to expcit port prefixes on a server, ask, re require
> address?
Because the Proposed RFC says you can ask for an ntpport without
as
Yo James!
On Sat, 2 Feb 2019 13:44:12 -0800
James Browning via devel wrote:
> >> What you almost need is a cookie extension to trigger a rekeying
> >> periodically.
> >
> > Yes. Sad the Proposed RFC is silent on the subject. Seems a gaping
> > hole to me.
> >
> >> You might want to look at
On 2/2/19 7:11 PM, Eric S. Raymond wrote:
> Richard Laager via devel :
>> On 2/2/19 4:52 PM, Eric S. Raymond via devel wrote:
>>> Gary E. Miller via devel :
On Sat, 2 Feb 2019 06:16:45 -0500 (EST)
"Eric S. Raymond via devel" wrote:
>>
The list of allowed versions, and even names, w
Yo Hal!
On Sat, 02 Feb 2019 17:00:46 -0800
Hal Murray via devel wrote:
> 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.
Yo Richard!
On Sat, 2 Feb 2019 18:42:52 -0600
Richard Laager via devel wrote:
> On 2/2/19 6:25 PM, Gary E. Miller via devel wrote:
> > On Sat, 02 Feb 2019 16:15:49 -0800
> > Hal Murray wrote:
> >
> >> Gary said:
> >>> Nothing says that a single cookie could not be used by a farm of
> >>> c
Richard Laager via devel :
> On 2/2/19 4:52 PM, Eric S. Raymond via devel wrote:
> > Gary E. Miller via devel :
> >> On Sat, 2 Feb 2019 06:16:45 -0500 (EST)
> >> "Eric S. Raymond via devel" wrote:
>
> >> The list of allowed versions, and even names, will change. Sometimes
> >> overnight as we h
Richard Laager :
> On 2/2/19 1:59 AM, Eric S. Raymond via devel wrote:
> > What I *am* clear on is that we have a job to do to convince Cisco to
> > keep funding us. I want to impress them with quality and *speed* and that
> > means I am not going to go on any yak-shaving expeditions and you
> > sh
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 trying
Richard Laager via devel :
> >>> Can anyone explain to me a case in which these are not
> >>> equivalent to expcit port prefixes on a server, ask, re require
> >>> address?
> >>
> >> Because the Proposed RFC says you can ask for an ntpport without
> >> asking for a ntpd address.
> >
> > Cite? I w
On 2/2/19 6:25 PM, Gary E. Miller via devel wrote:
> On Sat, 02 Feb 2019 16:15:49 -0800
> Hal Murray wrote:
>
>> 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 o
Yo Richard!
On Sat, 2 Feb 2019 17:52:57 -0600
Richard Laager via devel wrote:
> On 2/2/19 7:22 AM, Achim Gratz via devel wrote:
> > Eric S. Raymond via devel writes:
> >> *tlsport XXX* Contact the NTS-KE server on TCP port XXX.
> >>
> >> *ntpport YYY* Request an NTPD server on UDP port YYY.
>
Yo Richard!
On Sat, 2 Feb 2019 17:55:22 -0600
Richard Laager via devel wrote:
> On 2/2/19 3:06 PM, Gary E. Miller via devel wrote:
> >>
> >> We have a min option.
> > As previously discussed her. A min options was tried by others in
> > the past, and failed. When SSL 2 gave way to TLS 1, the
On 2/2/19 4:52 PM, Eric S. Raymond via devel wrote:
> Gary E. Miller via devel :
>> On Sat, 2 Feb 2019 06:16:45 -0500 (EST)
>> "Eric S. Raymond via devel" wrote:
>> The list of allowed versions, and even names, will change. Sometimes
>> overnight as we have seen many times.
>
> Of course it wi
Yo Hal!
On Sat, 02 Feb 2019 16:15:49 -0800
Hal Murray wrote:
> 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 T
Yo Richard!
On Sat, 2 Feb 2019 18:17:17 -0600
Richard Laager via devel wrote:
> On 2/2/19 5:45 PM, Hal Murray via devel wrote:
> > Another thing that might help is to keep the time scale in mind.
> > What do we need for first ship? What can wait? How much do we
> > need to think about issues t
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. Ho
Yo Richard!
On Sat, 2 Feb 2019 17:57:12 -0600
Richard Laager via devel wrote:
> On 2/2/19 3:29 PM, Gary E. Miller via devel wrote:
> > Nothing says that a single cookie could not be used by a farm of
> > clients to push the cookies per second into the thousands.
>
> The cookie, or more import
On 2/2/19 5:45 PM, Hal Murray via devel wrote:
> Another thing that might help is to keep the time scale in mind. What do we
> need for first ship? What can wait? How much do we need to think about
> issues that can wait to make sure we don't paint ourselves into a corner?
For first ship on t
On 2/2/19 3:08 AM, Achim Gratz via devel wrote:
> Changing the OpenSSL ciphersuites is typically done on system-level,
> application-level is not unheard of, but I haven't personally seen a
> per-server configuration.
I strongly disagree. This is absolutely, 100% commonly done at the
application l
On 2/2/19 1:59 AM, Eric S. Raymond via devel wrote:
> What I *am* clear on is that we have a job to do to convince Cisco to
> keep funding us. I want to impress them with quality and *speed* and that
> means I am not going to go on any yak-shaving expeditions and you
> shouldn't either.
Avoiding y
On 2/2/19 5:16 AM, Eric S. Raymond via devel wrote:
> NEVER CONFIGURE WHAT YOU CAN DISCOVER
>
> These are from nts.adoc:
>
> *tls1.2* Allow TLS1.2 connection.
>
> *tls1.3* Allow TLS1.3 connection.
>
> We don't need these because in this 'graph
>
> Implementations MUST NOT negoti
On 2/2/19 4:21 PM, Eric S. Raymond via devel wrote:
> Gary E. Miller via devel :
>> I assumed to start it would be just config files.
>
> Every time you assume a config file something beautiful dies.
>
> The right question to ask is not "how must we configure this", it's
> "how do we query our en
On 2/2/19 4:28 PM, Eric S. Raymond via devel wrote:
> Gary E. Miller via devel :
>>> *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 pr
On 2/2/19 4:10 PM, Eric S. Raymond via devel wrote:
> Gary E. Miller via devel :
>> As previously discussed her. A min options was tried by others in the
>> past, and failed. When SSL 2 gave way to TLS 1, the min broke.
>
> Well, of *course* any minssl option stopped being useful when there was
On 2/2/19 4:01 PM, Gary E. Miller via devel wrote:
> Very common in the Apache, nginc, postfix and sendmail communities.
>
> For example. you set one virtual server for cell phone clients, using
> less strong ciphers, and another for admin clients with the strongest
> ciphers. So the cell phones
On 2/2/19 3:38 PM, Gary E. Miller via devel wrote:
> Except 1.3 not working yet.
Why not? I mean, it's not widespread in released distros, but it's
finalized and OpenSSL supports it, right? SSL Lab's tester seems to
support it.
If you're just saying that not everyone has it yet, then I fully agre
On 2/2/19 3:29 PM, Gary E. Miller via devel wrote:
> Nothing says that a single cookie could not be used by a farm of
> clients to push the cookies per second into the thousands.
The cookie, or more importantly the C2S and S2C inside of it, which is
what we are discussing here, comes from a single
On 2/2/19 3:06 PM, Gary E. Miller via devel wrote:
>>
>> We have a min option.
> As previously discussed her. A min options was tried by others in the
> past, and failed. When SSL 2 gave way to TLS 1, the min broke.
Huh? What's the problem here? The epoch in renumbering from SSL 2 & 3 to
TLS 1.0
On 2/2/19 7:22 AM, Achim Gratz via devel wrote:
> Eric S. Raymond via devel writes:
>> *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 prefi
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 in
On Sat, Feb 02, 2019 at 05:52:25PM -0500, Eric S. Raymond via devel wrote:
> Gary E. Miller via devel :
> > On Sat, 2 Feb 2019 06:16:45 -0500 (EST)
> > "Eric S. Raymond via devel" wrote:
> >
> > > NEVER CONFIGURE WHAT YOU CAN DISCOVER
> > >
> > > These are from nts.adoc:
> > >
> > > *tls1
Gary E. Miller via devel :
> > 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?
>
> No. Required for testing. Required for crypto emergencies. The
> history of Apache, nginx, postfix and sendmail
Gary E. Miller via devel :
> On Sat, 2 Feb 2019 06:16:45 -0500 (EST)
> "Eric S. Raymond via devel" wrote:
>
> > NEVER CONFIGURE WHAT YOU CAN DISCOVER
> >
> > These are from nts.adoc:
> >
> > *tls1.2* Allow TLS1.2 connection.
> >
> > *tls1.3* Allow TLS1.3 connection.
> >
> > We don'
Gary E. Miller via devel :
> > *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?
>
Gary E. Miller via devel :
> Yo Eric!
>
> On Sat, 2 Feb 2019 03:01:13 -0500
> "Eric S. Raymond" wrote:
>
> > Gary E. Miller via devel :
> > > Please read my long email to Richard so I do not have to repeat
> > > myself.
> > > > If nobody has a convincing story, they stay out until we get an
> >
Gary E. Miller via devel :
> I assumed to start it would be just config files.
Every time you assume a config file something beautiful dies.
The right question to ask is not "how must we configure this", it's
"how do we query our environment to find out the right thing to do".
You should only thi
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
Yo Eric!
On Sat, 2 Feb 2019 02:59:32 -0500
"Eric S. Raymond" wrote:
> Gary E. Miller via devel :
> > Right, a bad thing.
>
> I'm not going to argue with you about the way configuration is now
> implemented. There are some problems with it, there are some
> advantages; I'm certainly not marri
Yo Eric!
On Sat, 2 Feb 2019 03:01:13 -0500
"Eric S. Raymond" wrote:
> Gary E. Miller via devel :
> > Please read my long email to Richard so I do not have to repeat
> > myself.
> > > If nobody has a convincing story, they stay out until we get an
> > > RFE from a real user. KISS principle.
>
Yo Eric!
On Sat, 2 Feb 2019 03:06:23 -0500
"Eric S. Raymond" wrote:
> Gary E. Miller via devel :
> > > Would somebody dig me up lists of the cipher names?
> >
> > openssl ciphers -v | fgerp TLS
> >
> > Which is incomplete since Gentoo, like almost all distros, does not
> > implement TLS
Gary E. Miller via devel :
> As previously discussed her. A min options was tried by others in the
> past, and failed. When SSL 2 gave way to TLS 1, the min broke.
Well, of *course* any minssl option stopped being useful when there was a major
interoperability break! That's an out-of-context ch
Yo Achim!
On Sat, 02 Feb 2019 09:32:34 +0100
Achim Gratz via devel wrote:
> Gary E. Miller via devel writes:
> >> I think there is a reasonable parallel between get another server
> >> via DNS and get another server via NTS-KE.
> >
> > Yes, except the protocol, as defined in the Proposed RFC,
Yo Hal!
On Sat, 02 Feb 2019 00:49:48 -0800
Hal Murray via devel wrote:
> 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 bugge
Yo Achim!
On Sat, 02 Feb 2019 10:08:17 +0100
Achim Gratz via devel wrote:
> Gary E. Miller via devel writes:
> >> >*tls1.3ciphers [list]* List of TLS 1.3 ciphers to negotiate, in
> >> >prefered order. TLS 1.2 and 1.3 ciphers are different and must be
> >> >specified separately as OpenSSL needs
Yo Eric!
On Sat, 2 Feb 2019 04:18:26 -0500
"Eric S. Raymond via devel" wrote:
> Achim Gratz via devel :
> > The RFC says the client needs to tell the NTS-KE all supported
> > ciphers. It doesn't say it must support different ciphers for
> > different servers.
Small correction: cipher sets. M
Gary E. Miller via devel :
> Yo Eric!
>
> On Sat, 2 Feb 2019 05:11:54 -0500
> "Eric S. Raymond via devel" wrote:
>
> > Hal Murray :
> > > Implementations MUST NOT negotiate TLS versions earlier than 1.2,
> > > SHOULD negotiate TLS 1.3 [RFC8446] or later when possible, and MAY
> > > refuse to neg
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 abs
On 2/2/19, Gary E. Miller via devel wrote:
> Yo James!
>
> On Sat, 2 Feb 2019 13:04:25 -0800
> James Browning via devel wrote:
>
>> > > But if no packets are lost, C2S and S2C will be used forever.
>> >
>> > Yeah, bad.
>>
>>
>> What you almost need is a cookie extension to trigger a rekeying
>> p
Yo Eric!
On Sat, 2 Feb 2019 04:25:51 -0500
"Eric S. Raymond via devel" wrote:
> > Just because the current pool is untrustworthy doesn't mean that
> > somebody couldn't run a trusted pool.
Without crupto? No. Bad idea.
> > Keep in mind that pool+nts isn't well specified yet. Do we want to
>
Yo Achim!
On Sat, 02 Feb 2019 10:43:33 +0100
Achim Gratz via devel wrote:
> Hal Murray via devel writes:
> >> You might be right, but I'm not going to design on the assumption
> >> that you are because the payoff matrix is too asymmetrical.
> >
> > Just because the current pool is untrustwort
Yo Hal!
On Sat, 02 Feb 2019 01:44:31 -0800
Hal Murray via devel wrote:
> >>*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
> > wor
Yo Hal!
On Sat, 02 Feb 2019 02:07:03 -0800
Hal Murray wrote:
> 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.
A typo for 'def
Yo Eric!
On Sat, 2 Feb 2019 05:11:54 -0500
"Eric S. Raymond via devel" wrote:
> Hal Murray :
> > Implementations MUST NOT negotiate TLS versions earlier than 1.2,
> > SHOULD negotiate TLS 1.3 [RFC8446] or later when possible, and MAY
> > refuse to negotiate any TLS version which has been superse
Yo Hal!
On Sat, 02 Feb 2019 02:33:56 -0800
Hal Murray via devel wrote:
> The per client-server pair of keys, C2S and S2C don't roll over as
> long as the connection works reasonably well. I asked about key
> lifetime on the NTP list and Daniel said we don't have to worry about
> it.
> https://m
Gary E. Miller via devel :
> Yo James!
>
> On Sat, 2 Feb 2019 13:04:25 -0800
> James Browning via devel wrote:
>
> > > > But if no packets are lost, C2S and S2C will be used forever.
> > >
> > > Yeah, bad.
> >
> >
> > What you almost need is a cookie extension to trigger a rekeying
> > per
Yo Hal!
On Sat, 02 Feb 2019 02:53:18 -0800
Hal Murray via devel wrote:
> 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
> sho
Yo Eric!
On Sat, 2 Feb 2019 06:16:45 -0500 (EST)
"Eric S. Raymond via devel" wrote:
> NEVER CONFIGURE WHAT YOU CAN DISCOVER
>
> These are from nts.adoc:
>
> *tls1.2* Allow TLS1.2 connection.
>
> *tls1.3* Allow TLS1.3 connection.
>
> We don't need these because in this 'graph
>
>
Gary E. Miller via devel :
> > Then we'll have to do the full autodiscovery thing. Would you
> > look into how openssl-ciphers does it?
>
> I've been objecting to so many things I lost context on which one this it.
Getting a list of the ciphers your TLS library supports. It must be possible.
ope
Yo Eric!
On Sat, 2 Feb 2019 07:14:23 -0500
"Eric S. Raymond via devel" wrote:
> > We need to setup a mechanism to review the defaults occasionally.
> > Maybe with each release. Maybe on Mark's birthday. The idea is to
> > track progress in the crypto community. If the default today is to
> >
On Sat, Feb 2, 2019, 12:46 PM Gary E. Miller via devel Yo Hal!
>
> On Sat, 02 Feb 2019 12:36:10 -0800
> Hal Murray via devel wrote:
>
> > But there is another pair of keys: C2S and S2C. They are used to
> > authenticate and encrypt traffic between client and server. There is
> > no explicit mec
Yo James!
On Sat, 2 Feb 2019 13:04:25 -0800
James Browning via devel wrote:
> > > But if no packets are lost, C2S and S2C will be used forever.
> >
> > Yeah, bad.
>
>
> What you almost need is a cookie extension to trigger a rekeying
> periodically.
Yes. Sad the Proposed RFC is silent on
Yo Eric!
On Sat, 2 Feb 2019 15:57:30 -0500
"Eric S. Raymond" wrote:
> Gary E. Miller via devel :
> > This goes against all existing practice. Bad idea.
>
> Then we'll have to do the full autodiscovery thing. Would you
> look into how openssl-ciphers does it?
I've been objecting to so many
Yo Eric!
On Sat, 2 Feb 2019 08:02:16 -0500 (EST)
"Eric S. Raymond via devel" wrote:
> *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 prefi
Gary E. Miller via devel :
> This goes against all existing practice. Bad idea.
Then we'll have to do the full autodiscovery thing. Would you
look into how openssl-ciphers does it?
--
http://www.catb.org/~esr/";>Eric S. Raymond
My work is funded by the Internet Civil Engineerin
Yo Hal!
On Sat, 02 Feb 2019 12:36:10 -0800
Hal Murray via devel wrote:
> But there is another pair of keys: C2S and S2C. They are used to
> authenticate and encrypt traffic between client and server. There is
> no explicit mechanism to roll them over - nor is there a need for one.
Really? So
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 an
Yo Eric!
char *server; /* if NUL, use the peer itself (normal case)
*/
+char *ca; /* if NUL, use the system default (normal
case) */
+char *cert;/* if NUL, use the system default
NULL, not NUL.
RGDS
GARY
-
Yo Eric!
On Sat, 02 Feb 2019 20:12:32 +
"Eric S. Raymond via vc" wrote:
>
> +To avoid having to hand-configure ciphers offered to the remote, we
> +can initially have a list of common known-good ones wired in.
> +Eventually, look into how openssl-ciphers does this and
> autoconfigure. +
>
Achim Gratz via devel :
> Eric S. Raymond via devel writes:
> > *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, a
Hal Murray :
>
> 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.
Sor
Hal Murray :
> I think there are command line tools or man pages that list them all. We
> could look at the source for the command line tool - or ask on their mailing
> list.
>
> My straw man would be to pick a small handful of good ones and check that
> they
> are supported. That gets us of
On Sat, Feb 2, 2019, 5:27 AM Hal Murray via devel
> > 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
> > secon
Hal Murray via devel writes:
> Good sugestions, thanks, but it's all an implementation of get a batch of
> answers from one NTS-KE server. I think it would be simpler to fix the
> NTS-KE
> protocol and probably a good idea to stay away from non-mainline uses of TLS.
Multiplexing over a single
> 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 o
Eric S. Raymond via devel writes:
> *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?
I think you
Hal Murray via devel writes:
>> 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.
>
> D
> *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 wou
*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?
I think these can go.
--
http://www.catb
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 fro
Hal Murray via devel :
> I think we should put pool stuff on the back burner.
Agreed. Until we demonstrate TLS interop to Cisco that is where I
think everybody needs to be concentrating.
--
http://www.catb.org/~esr/";>Eric S. Raymond
My work is funded by the Internet Civil Engin
Hal Murray :
>
> >> 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.
Ah, that's t
Hal Murray :
> I believe that
> server ntp.example.com nts
> should work in many/most cases.
That was my design goal, yes.
> We'll have to provide sensible defaults for all of the options.
>
> We need to setup a mechanism to review the defaults occasionally. Maybe with
> each release. Maybe
> 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 i
># 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 th
>> 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 spa
NEVER CONFIGURE WHAT YOU CAN DISCOVER
These are from nts.adoc:
*tls1.2* Allow TLS1.2 connection.
*tls1.3* Allow TLS1.3 connection.
We don't need these because in this 'graph
Implementations MUST NOT negotiate TLS versions earlier than 1.2,
SHOULD negotiate TLS 1.3 [RFC8446]
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 options
1 - 100 of 121 matches
Mail list logo
