[PATCH 38/43] secnet.8: Describe capability negotiation in its own section. [and 1 more messages] [and 2 more messages]

Ian Jackson ijackson at chiark.greenend.org.uk
Mon May 1 11:47:58 BST 2017

I still think my scheme works just fine.

Mark Wooding writes ("Re: [PATCH 38/43] secnet.8: Describe capability negotiation in its own section. [and 1 more messages]"):
> Suppose Alice is configured to use X25519 and trad-DH, and Serpent-EAX.
> She will set cap bits 15, 11, 10, 9 (EXPLICIT, X25519, TRADZP), and view
> 15, 11, 10 as early.

She will set 15 (EXPLICIT), 11 (X25519), 10 (TRADZP), 9.  But she will
view only X25519 as early.

(EXPLICIT and TRADZP are not early, by (my) definition.  Only new DH
groups, and perhaps other future things, are early.)

> Suppose Bob is configured to use trad-DH, Serpent-EAX, Serpent256-CBC,
> and ChaCha20/Poly1305 because he's from the future.  He'll set cap bit 8
> (Serpent256-CBC), 9 (Serpent-EAX), 16 (ChaCha20/Poly1305), and 15
> (because he wants his peer to notice cap bit 16), but won't view any of
> them as early (because he has a chance of interoperating with an ancient
> Secnet).

He will send 16 (CHACHA20POLY1305), 15 (EXPLICIT), 10 (TRADZP), 9, 8.

He will send 15 not because "he wants his peer to notice 16" but
because he always sends 15.  Sending EXPLICIT is not dependent on

Bob won't view any of them as early because none of them is a new DH
algorithm (or some other new kind of new early thing yet to be

> It so happens that Bob opens this exchange.  He has no early caps to
> send, so he sends a backwards-compatible MSG1.  Alice responds with her
> caps in MSG2.  Bob decides on Serpent-EAX and trad-DH, and sends those
> back as MSG3TER.  Alice receives this -- and then rejects it because it
> has bits 15 and 11 set, and in her mind these are early bits that Bob
> should have sent in MSG1 but didn't.

Alice's MSG2 advertises all of her caps, because at least one of them
is early (see below).  Bob selects MSG3TER because he thinks,
correctly, that EXPLICIT has been negotiated.  Bob's MSG3TER contains
16,15,10,9,8 and nominates TRADZP, EAXSERPENT.

Why do you think Bob's MSG3TER has 11 (X25519) set ?  Bob is
configured not to offer X25519 (for old client compatibility, you
say).  If Bob did advertise X25519 then Alice would presumably want to
pick it.  (This would depend on alice's preference order, but it seems

Mark Wooding writes ("Re: [PATCH 42/43] Introduce negotiation for Diffie--Hellman groups."):
> EXPLICIT and TRADZP need to be early /if/ they're accompanying
> non-default DH group caps.

No, they are never early.  OTOH if any early caps are sent then
EXPLICIT will be sent with them, along with TRADZP if applicable.

>  The caps sent in MSG1 are the early caps and
> anything else that may be convenient.  But, for correct DH-group
> negotiation, if I'm sending a non-default group, I /must/ also send
> EXPLICIT, and -- if it's a group I permit -- TRADZP.  So those bits are
> early in this context.

Currently the spec says

  If MSG3 or MSG4 advertise any "early" capability bits,
  MSG1 or MSG3 (as applicable) must have advertised them too.

but the code sends all capability bits if there are any early ones.
I'm proposing formalising this, at least for non-TRADZP DH groups.

Mark Wooding writes ("Re: [PATCH 38/43] secnet.8: Describe capability negotiation in its own section. [and 1 more messages]"):
> Other, more complicated plan.  Alice can just about reverse-engineer
> Bob's thought process.  She can tell that the only overlapping DH group
> she shares with Bob is TRADZP, and that therefore his motivation for
> setting EXPLICIT was to include CHACHA20POLY1305, so therefore neither
> TRADZP nor EXPLICIT needed to be sent early.
> The general case:
> This does seem awfully fiddly, and prone to break in some future
> version.  I loathe it with a rare passion.

Good grief.  I agree we don't want anything like that.


Ian Jackson <ijackson at chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

More information about the sgo-software-discuss mailing list