[getting started]
> How do certificates make this more complicated?
Checking certificates depends on time.
It may be a non problem if your system has a RTC/TOY clock. But they break.
Raspberry Pis don't have them, ...
--
These are my opinions. I hate spam.
__
On 2/3/19 4:49 PM, Hal Murray via devel wrote:
> 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 ma
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 inf
On 2/3/19 3:31 PM, Kurt Roeckx wrote:
> Note that by default that doesn't work.
Thanks! I was not aware of OpenSSL's security level concept, the
@SECLEVEL=0 syntax in a cipher string, the -s option to ciphers, or the
concept of an unusable cipher. That was a lot of good information packed
into one
On Sun, Feb 03, 2019 at 03:15:55PM -0600, Richard Laager via devel wrote:
> On 2/3/19 1:01 PM, Eric S. Raymond wrote:
> > I guess it will have to be an empty string that disables encryption.
>
> I'm not sure if you wrote this before the recent messages on the NULL
> ciphers. But you said you were
On 2/3/19 11:40 AM, Achim Gratz via devel wrote:
> Richard Laager via devel writes:
>> 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 con
Richard Laager :
> On 2/3/19 1:01 PM, Eric S. Raymond wrote:
> > I guess it will have to be an empty string that disables encryption.
>
> I'm not sure if you wrote this before the recent messages on the NULL
> ciphers. But you said you were going to use that, so...
>
> It's not an empty string...
On 2/3/19 1:39 PM, Sanjeev Gupta wrote:
> The Google resolver checks for valid DNSSEC, and sets the bit.
and does not return a result if DNSSEC fails.
$ dig dnssec.fail @8.8.8.8 | grep status
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 35621
$ dig dnssec-failed.org @8.8.8.8 | grep status
On 2/3/19 1:01 PM, Eric S. Raymond wrote:
> I guess it will have to be an empty string that disables encryption.
I'm not sure if you wrote this before the recent messages on the NULL
ciphers. But you said you were going to use that, so...
It's not an empty string... the NULL ciphers have specific
On Sat, Feb 2, 2019 at 8:57 AM Richard Laager via devel
wrote:
>
> About 19% of the world is doing DNSSEC validation, in large part because
> apparently 15% of the world is using Google's recursive DNS service.
>
Actually,things are much worse.
The Google resolver checks for valid DNSSEC, and s
Richard Laager :
> If "cipher" is for TLS:
OK, that was the idea.
> Rename cipher to ciphers (plural) and add a second one named
> ciphersuites. You'll need two for testing anyway, as OpenSSL takes TLS
> 1.2 and 1.3 cipher specifications separately.
>
> Then those are just done for the final sce
Achim Gratz via devel :
> Eric S. Raymond via devel writes:
> > Hal Murray :
> >> Please verify with a TLS wizard that you can do what you are describing
> >> with
> >> OpenSSL. I've poked around a bit and don't know how to do that.
>
> https://crypto.stackexchange.com/questions/8964/sending-tl
Richard Laager :
> This enclair option will only be useful for very early testing (and can
> then be removed).
OK. It was easy to add and will be easy to remove.
On a related note, the fixed complexity cost of the "crypto" command was
a bit annoying, but now that I've done it...
...the increment
Eric S. Raymond via devel writes:
> Hal Murray :
>> Please verify with a TLS wizard that you can do what you are describing with
>> OpenSSL. I've poked around a bit and don't know how to do that.
https://crypto.stackexchange.com/questions/8964/sending-tls-messages-with-out-encryption-using-opens
Richard Laager via devel writes:
> 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
Gary E. Miller via devel writes:
>> No, in fact my expectation is that the ntpsec implementation should
>> support an NTS pool.
>
> Which does not exist, and will take years for an RFC to create.
Well, you tell me why it absolutely needs another (or changed) RFC. As
I said before, while changes a
Gary E. Miller via devel writes:
>> > > 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 the subject. Seems a gaping
> hole to
Gary E. Miller via devel writes:
>> Again, it supports it exactly the same way as the pool is currently
>> working with DNS: You want another server, you ask another time.
>
> Exactly why it is broken. No crypto. Unless you mean having an NTS-KE
> server manage a pool. in chich case there is zero
On 2/3/19 8:17 AM, Eric S. Raymond via devel wrote:
> Hal Murray :
>> Please verify with a TLS wizard that you can do what you are describing with
>> OpenSSL. I've poked around a bit and don't know how to do that.
>
> My plan is to brute-force the problem. Rather than trying to beat TLS into
> t
On 2/3/19 12:34 AM, Richard Laager wrote:
> For the server to client direction, we would have to store the counter
> state in the cookie. Given that cookies are preallocated, this would
> take _two_ numbers: the current counter value to use with that cookie
> and the maximum counter valued issued.
Hal Murray :
> Please verify with a TLS wizard that you can do what you are describing with
> OpenSSL. I've poked around a bit and don't know how to do that.
My plan is to brute-force the problem. Rather than trying to beat TLS into
talking en clair, I'll make 'enclair' change the socket-fu so T
> 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.
Typo "addresa" -> "address"
numeric address, an IPv6 numeric addresa (in square brackets).
If cipher is for NTP, I think you should rename it to ntpcipher (or
ntpciphers). Or just drop it, since you're almost certainly only going
to implement AES-SIV-CMAC for first ship. (And possibly that'll b
I have implemented and fully documented a new 'crypto' configuration
with options mintls, maxtls, and enclair. They set globals in
ntpd/nts.c.
The mintls and maxtls options are as discussed on this list. The
"enclair" option is intended to disable crypto negotiation so
certificates are not requir
24 matches
Mail list logo
