[noise] "have one joint and keep it oiled"

[David Wong]

> Handshake payloads are (often) encrypted, so making them extensible is
> maybe less about middleboxes and more about not painting yourself into
> a corner where you'd like to extend your protocol but can't.

This related comment on SSHv2 is interesting as well:
https://www.reddit.com/r/crypto/comments/7mii6w/why_tls_13_isnt_in_browsers_yet/drubr3j/

> Similar rusting has happened in SSH v2 and has required "innovative
approaches" (e.g. using a field not originally intended for this purpose)
to add an extension mechanism
<https://tools.ietf.org/html/draft-ietf-curdle-ssh-ext-info-15>. The
original extension field in SSH_MSG_KEXINIT cannot be used because even
though the spec defined it this way
<https://tools.ietf.org/html/rfc4253#section-7.1>:

> uint32       0 (reserved for future extension)

> ... some implementations misinterpreted this and are not only sending a
0, but also *checking* that they receive a 0 (mighty support for "future
extension"!). Another doesn't make an explicit check but assumes it's 0 and
miscalculates the key exchange if it's not.

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20171229/9c4f179d/attachment.html>