[noise] certificate chains

[Arvid Picciani]

> I was assuming that "s" will be used repeatedly by the client

no, only by the server for 0-RTT.
the s sent in message 1 (cleartext) is not reused.
The fact that it exists at all is me not understanding the handshake hash well.
Its safety properties are not well documented in the spec.  I.e. when
is it safe to sign it in which pattern?


in NX for example (which would just leave out the client static key),
is this safe?

NX(rs):
  -> e
  <- e, ee, s, es  [u(h)]
  -> [u, u(h)]

the docs say that handshakehash is safe when the handskae completed,
but is the handshake complete from the responders perspective in 2?
also what about replay?  the first e was sent in cleartext, so just
repeating the e will make the server sign the same session again which
could be useful to extract timings?



On Tue, Jul 3, 2018 at 6:10 AM, Trevor Perrin <trevp at trevp.net> wrote:
> On Mon, Jul 2, 2018 at 3:27 PM, Arvid Picciani <aep at exys.org> wrote:
>>> I interpret the additional fields as [..]  payload
>>
>> yes. do we have a better way to write this?
>
> Nothing official, but I've done things like this before, to set off
> the payload from the rest of the pattern:
>
>   -> e, s
>   <- e, ee, se, s, es [u(s)]
>   -> [u, u(s)]
>
>
>>> Since client-authentication isn't completed until the 3rd message
>>> [..] client identity-hiding
>>
>> i'm confused. client identity is sent in message 3, which should be
>> completely confidential according to:
>>
>> http://noiseprotocol.org/noise.html#payload-security-properties
>
> I was assuming that "s" will be used repeatedly by the client, so
> sending "s" in the clear in the first message will leak information
> about the client's identity to eavesdroppers (at minimum,
> eavesdroppers will see which connections belong to the same client).
>
> (If "s" is not used repeatedly by the client, then "s" is no different
> from "e", and there's no reason to have an "s").
>
> Switching to XX would move the transmission of "s" into the 3rd
> message along with the client's u and u(s) values, for better
> identity-hiding.  See the "Identity hiding" section in the spec which
> discusses identity-hiding of the static public keys.
>
> Trevor