mode 6 crypto revison

[James Browning]

On Sat, Jan 11, 2020, at 1:03 AM Hal Murray <hmurray at megapathdsl.net> wrote:
> > The current symmetric auth scheme requires a not-an-extension which is
> > (formerly 10) 20 or 24 bytes of an essentially unidentifiable binary blob. to
> > check for it, you either need a length for the authenticated stream or walk
> > backward in the packet to see if the text matches a symmetric authenticator.
>
> That's not quite the right description.  You don't walk backwards.  You go
> forwards until you get to a reasonable stopping place, then check the length
> of what is left.  20 or 24 bytes are grandfathered (ugly hack) as
> non-extension authentication.

The backward walking was an anti-pattern I picked up somewhere. For
regular time packets, the method is now to read until you get to a
type 0 non-extension. Then ask if it is a valid authenticator.

> > My former proposed scheme requires something which is not-properly-an-extensio
> > n. it has a six-byte header which should be regex searchable in mode 6 and
> > unlikely to occur (no number though) in a regular text stream.
>
> "regex searchable" doesn't sound like the right approach.

I was thinking wrongly that it would have been fewer than eight null
bytes, two bytes of known value for the extension type, two bytes in
a list of known values the former of which is probably 0, four bytes
for key/salt id which has two (or three) 0 bytes. so something like [1].

> Is Eric's mode 6 writeup accurate?  docs/mode6.adoc
> (I haven't checked the code, but it looks good.)
>
> Assuming yes, then the current hack authentication will work and we can switch
> to using real extensions at any time.

It seems reasonably accurate  AFAICT. I am only looking at small
pieces of it and there seems to be some an inconsistent use of
payload/extension in section 4 and I have not recently seen nor
attempted the use of a non-128bit key/salt for anything contrary
to section 7.

> My previous comments about using NTS were bogus.  That lets the client know
> the response came from the correct server (or at least one with the correct
> certificate).  We need the other direction: the server needs to know the
> client is authorized to do restricted operations.  NTS doesn't support that.

Network Time Security could work for that but it would require scope
creep. Thinking back, I now think that would not be not a good thing.
It would not work well with the unlinkability goal of NTS.

[1] /\0{0,7}\x05\x04(\0.)(\0\0..)(.{16,64})$/