NTS keys as I understand them

[Gary E. Miller]

Yo Hal!

On Tue, 15 Jan 2019 01:45:58 -0800
Hal Murray via devel <devel at ntpsec.org> wrote:

> Gary said:
> > I'm perfectly happy with that, just not to the exclusion of other
> > ways to interpret the Proposed RFC.   
> 
> I don't understand that.  How many ways to interpret it are there?

Well, the reply that you cut specified one of the: NTS-KE only returns
one cookie.

> Page 18 says:
>   To protect the client's privacy, the client SHOULD avoid reusing a
>   cookie. If the client does not have any cookies that it has not
>   already sent, it SHOULD initiate a re-run the NTS-KE protocol. The
>   client MAY reuse cookies in order to prioritize resilience over
>   unlinkability. Which of the two that should be prioritized in any
>   particular case is dependent on the application and the user's
>   preference. Section 10.1 describes the privacy considerations of
>   this in further detail.

Yeah, that is two ways.

> I'm not a language lawyer, but that seems clear to me.  It doesn't
> say you can use a single cookie to simplify your code.

SHOULD is not a MUST.  Some will ignore that SHOULD if they are lazy.

> This whole discussion is a waste of time.  If we had code that did
> everything else but reused a cookie it got from the NTS-KE step, I
> could fix it to use new cookies in an evening.  (Maybe weekend, I'm
> crappy about time estimates.)

Postels Law: "Be liberal in what you accept and conservative in what
you send."

I keep talking about what we should accept.  You keep talking about
what we should send.  No conflict.  So I agree this is a waste, after
you realize the difference between the two.


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/20190115/477ae7a1/attachment-0001.bin>