[noise] rev34 draft

[Nadim Kobeissi]

Hi everyone,

I've been reading through rev33, and I wanted to send in the following
minor comments which I hope will lead to improvements in rev34:

1. I think it would be a good idea to expand 7.1.2 to mention that no token
may occur twice in the same message flight.

2. Section 9 seems oddly isolated and describes a single token in a way
that seems artificially distinct from the other tokens. It can likely be
(and should be) merged into Section 5, which already contains statements
describing the methodical parsing of every other token that's not a psk
token.

3. Probably my least favorite thing about rev33 is the isolation of certain
validity rules. Since 7.1 already describes validity rules with one being
necessary to avoid "catastrophic" errors, it makes a lot of sense to also
merge the "catastrophe"-avoiding validity rules in 9.3 (and perhaps even
11.5) into the same section.


Nadim Kobeissi
Symbolic Software • https://symbolic.software
Sent from office

On Tue, Apr 10, 2018 at 7:29 AM, Trevor Perrin <trevp at trevp.net> wrote:

> On Mon, Apr 9, 2018 at 8:13 PM, Justin Cormack
> <justin at specialbusservice.com> wrote:
> >
> > A brief changelog alongside the spec would be helpful.
>
> I'll add that when I find the time.
>
>
> > Its marked official/stable in the html and pdf outputs.
>
> Fixed.
>
>
> One small change I forgot to mention:  I removed the reference to KEA+
> as originating the idea of hashing identity information into session
> keys.  I did a little research (prompted by Douglas Stebila) and
> realized the idea of hashing identifiers into session keys for UKS
> resistance was well-known substantially before KEA+, e.g. from Colin
> Boyd's 2003 book:
>
>  "A general method to ensure that unknown key-share attacks do not
> apply is to include both principal identities within the key
> derivation function."
>
> Or from the original paper on UKS by Blake-Wilson and Menezes in 1999:
>
> "Instead of including the identities of the entities in the signed
> message, one could include them in the key derivation function".
>
>
> Trevor
> _______________________________________________
> Noise mailing list
> Noise at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/noise
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20180418/3cbee318/attachment.html>