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
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
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
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.
--
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
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
> >
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
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
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,
[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
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
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
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,
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
> >>>
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
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
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
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,
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
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
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
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.
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
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
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
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
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
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
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
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: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
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
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
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
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:
> > >
> > >
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
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
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
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
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
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
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
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.
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
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
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
>>
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
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
> >
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
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
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.
>
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
> >
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
>
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.
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
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
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
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
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?
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
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,
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.
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
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
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
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.
>
>
> *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
*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.
--
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
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
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
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.
> 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
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
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
Hal Murray :
>
> 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
> 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
Hal Murray :
> >>*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.
>
>
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
1 - 100 of 117 matches
Mail list logo
