[noise] rev32b (Release Candidate)

[Jason A. Donenfeld]

On Sun, May 14, 2017 at 1:24 AM, Alex <alex at centromere.net> wrote:
> I think there is a huge mindset difference in how you and I are
> approaching the spec.
> WireGuard weaves together the Noise logic and the application logic,

I was thinking about my experiences playing with noise-go and
snow/screech, actually. Both of these are full fledged libraries. The
design of these made this all fairly easy to implement. Haskell might
be a different beast, or perhaps your particular design choices pose
unique challenges, but I've seen from experience that this is not an
impossible design to implement in a flexible API.

> The psk is not necessarily known at the time the handshake pattern is
> defined and delivered to the library. It's only after the Noise
> exchange begins (and tokens are consumed) that the psk becomes known,
> and it's chosen by application logic, not Noise logic.

No matter how you approach it -- who provides the data and at what
time -- both implementation strategies seem totally viable.

> I've literally created a domain specific language to describe handshake
> patterns. There is a *single data structure* that is used to represent
> all possible handshake patterns along with an interpreter to provide
> the implementation. Both the initiator *and* responder are running off
> the same "script". I find this to be a valuable abstraction, and I'm
> willing to put in considerable effort to make it work.

Creating a domain specific language is a neat way of approaching
things. Haskell people always seem to have interesting ways of
thinking about stuff.

> When I see you write "look into it at that time", I hear, "kick the can
> down the road".

No, not really.

> The psk changes in rev32b alone require large breaking API changes
> because my abstractions are based on the assumption that *all*
> handshake parameters (such as the psk from previous revisions, as well
> as the ephemeral key) are known to the library before the handshake
> begins. As a result, the entire handshake can be thought of as a "pure
> computation" whose output is solely dependent on its input. But if the
> application can arbitrarily choose a psk half-way through the
> computation, all purity is lost.

These seems to be the crux of the problem you're facing. I think I
understand the outcry now.

You can either continue to treat PSKs that way -- known ahead of time
-- or you can work on making your library logic more flexible for more
interesting uses. If you think your future users will want the latter,
do that. If you think your future users will only ever need the
former, stick with what you currently have.

> API design is by no means trivial, and I will not half-ass it.

Certainly you shouldn't half-ass anything! I never meant to suggest
such a thing. In the case of my Qt example, I think those developers
are pretty crazy about doing API reviews on -everything-.

Anyway, it sounds to me like you're feeling that there will be
interesting programming challenges and design challenges associated
with these recent changes. That's okay. I don't think these are
unreasonable things to ask of an API, and there are a variety of ways
to support it.

Jason