Gary E. Miller
gem at rellim.com
Mon Apr 1 23:32:22 UTC 2019
On Mon, 01 Apr 2019 15:23:58 -0700
Hal Murray <hmurray at megapathdsl.net> wrote:
> > Sad. Seems we've been around this May Pole way too many times
> > already... You have nothing new to say below, and my answers are
> > also not new.
> Richard's summary matches my understanding.
Then you are learning, much more to go.
> > Agreed, sort of. This assumes fixes that do not exist. So
> > "assuming a canopener". It also assumes that less than perfect
> > security is no security.
> The problem with pseudo security is that people might think it really
> is secure.
Yup. But nothing is totally secure, sometimes you know what you
are compromising, sommetimes you do not.
Sometimes you have no choice. Such as earlier this year when the
NIST certs were broken, yet people were legally required to
maintain NIST traceable time.
> If it's not (real) secure, I think we should make a lot of noise
> about using it.
100 agree. Flash the room in red light, sound the klaxons, spin the
disks up and down so the server shakes.
> > Part of the rationale for NTS is that since the cookies change
> > every request, then the user can not be tracked. "noval" does not
> > remove that feature, or some other goodness.
> Why are you bringing up tracking? Is it related to security? To
I bring it up because it is part of the RFC. The RFC writers think is
important, so I do too. I suggest you ask them if you want to know why
they feel it is a key part of NTS.
Just because the initial contact, exchanging the first cookies, is not
100% perfect, does not mean there is no significant value remaining to
address other concerns. I'll avoid repeating recent emails on the
NTP mailing list on the subject.
> > Agreed, sort of. The "ca", which is an "assumed can opener", does
> > not solve many very similar cases.
> My plan is to implement the per-server "ca" as soon as I can. The
> API I want isn't available, but I think I see a reasonable way to
> implement it.
Good. another small piece of the puzzle. Personnaly, I'd rather
see pinning before "ca". I sent you the code to do it. It solves
more problems than simple "ca". Such as the "*.google.com" one.
But, order is up to you, eventually it all needs to get done.
> That will solve the problem of self-certified certificates. How many
> of your "many very similar" cases are interesting?
Well, "*.google.com" seemed to get peoples attention. Ditto for
NIST earlier this year.
> > Personally, I'd rather have DANE type pinning before "ca". And
> > once "ca" is implemented would like to do both.
> Are you trying to use DANE as a substitute for normal certificate
> checking or as a supplement?
Around the May Pole again...
Neither. DANE is a very well thought out, well deployed, and
comprehensive approach for certificate pinning using DNS. We don't
need (yet) the DNS part, but the other 90% is on point for any
application doing pinning. Don't reinvent a good wheel.
> I don't fully understand DANE yet.
Very few fully understand DANE. Not required.
I think Matt Selsky will agree it took us much of a year to get it
"right" for ntpsec.org.
> A good example might help.
Look at the ntpsec.org DNS for a good example.
Or, just use the pinning code I sent you.
Basically: hash one of the certs or public keys you get from a server,
store the hash algorithm and the hash. Next time you see the cert
and/or key, compare the hash.
> there a HOWTO type web page telling me how to set things up? ...
Many, just google "DANE TLSA". That is why I keep bring up DANE over
the many other similar ways to do cert pinning: it is so well documented
> Is it widely deployed? Does my browser use it?
You use ntpsec.org, so you use pinning. Do not get too hung up on DANE
and DNS. Just look at the part that calculates all the dozens of ways
that pinning can be computed. Then pick one, or four.
Similarly HPKP also does pinning, inside HTTP. So your browser uses
HPKP, few browsers use DANE, but the actual pin concept is the same.
The transfer mechanisms are different, but the core concept of pinning
is the same.
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem at rellim.com Tel:+1 541 382 8588
Veritas liberabit vos. -- Quid est veritas?
"If you can’t measure it, you can’t improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 851 bytes
Desc: OpenPGP digital signature
More information about the devel