Cert pinning

Gary E. Miller gem at rellim.com
Tue Apr 2 02:26:07 UTC 2019


Yo Richard!

On Mon, 1 Apr 2019 21:06:05 -0500
Richard Laager via devel <devel at ntpsec.org> wrote:

> On 4/1/19 3:25 PM, Gary E. Miller via devel wrote:
> >> 2) Since "noval" disables the security, using "noval" means one is
> >> essentially falling back to non-NTS. Therefore, "noval" doesn't
> >> make any sense for long-term production use. A user contemplating
> >> using "noval" indefinitely in production should either fix the
> >> validation so NTS is actually providing some security benefit, or
> >> just use plain NTP if they don't care about the security benefits
> >> of NTS.  
> > 
> > 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.  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.  
> 
> Changing the cookies is important so that NTS is not _worse_ than
> plain NTP. (That is, if the cookies didn't change, the cookies would
> provide a new way to link the client across networks.) The cookies
> don't make NTS any better than plain NTP in regards to unlinkability,
> whether the TLS for NTS is properly secured or not.
> 
> The NTS draft, section 10.1 says:
>    NTS's unlinkability objective is merely to not leak any additional
>    data that could be used to link a device's network address.  NTS
> does not rectify legacy linkability issues that are already present in
>    NTP.  Thus, a client that requires unlinkability must also minimize
>    information transmitted in a client query (mode 3) packet as
>    described in the draft [I-D.ietf-ntp-data-minimization].

Yes, that is my understanding as well.

> Can you point to some other security benefit that NTS with
> unauthenticated TLS would provide over plain NTP?

Yes, see the Proposed RFC Section 1.1. Objectives:

   o  Confidentiality: Although basic time synchronization data is
      considered non-confidential and sent in the clear, NTS includes
      support for encrypting NTP extension fields.

   o  Replay prevention: Client implementations may detect when a
      received time synchronization packet is a replay of a previous
      packet.

   o  Request-response consistency: Client implementations may verify
      that a time synchronization packet received from a server was sent
      in response to a particular request from the client.

 
> I'm not seeing any benefit, and more importantly, Daniel Franke has
> already weighed in to that effect:
>    There's no point in doing NTS if you're not doing certificate
>    validation. The result isn't any more secure than unauthenticated
>    NTP.
>    -- https://lists.ntpsec.org/pipermail/devel/2019-March/007804.html

Well, Section 1.1 disagrees.  Remeber, I;'m not advocating for
insecurity, just for all the security I can get under bad conditions.


> > Agreed, sort of.  The "ca", which is an "assumed can opener", does
> > not solve many very similar cases.  
> 
> It solves the case it is intended to solve. Other cases need to be
> considered separately.

Wow, that is circular.  We've not agreeed on the the case intended to
solve.  But, please don't bother to add that distraction.  We already
agreed "ca' is sometimes good to have.

> >> 4B) If ntpd implements pinning, it should be in addition to the
> >> usual certificate validation, not instead of.  
> 
> >> - If validation is succeeding, there is no problem.  
> > 
> > No.  Rememeber when Comodo issued the cert "*.google.com" to bad
> > guys?  
> 
> The context here is whether pinning applies in addition to validation
> or instead of normal certificate validation. If normal certificate
> validation is already passing in a particular scenario, then there is
> "no problem" with pinning being "in addition to", as opposed to
> "instead of", normal validation.

I can't tell who you are arguing against.  Certainly not me.  Can't imagine
why I need to keep agreeing with things already stipulated.  What we have
here is a failure to converge.

So I'll stop going around the May Pole right now.  Let Hal work it out.

[...]

RGDS
GARY
---------------------------------------------------------------------------
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
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20190401/12cb8a30/attachment.bin>


More information about the devel mailing list