[PATCH 38/43] secnet.8: Describe capability negotiation in its own section. [and 1 more messages]
mdw at distorted.org.uk
Mon May 1 02:11:22 BST 2017
Ian Jackson <ijackson at chiark.greenend.org.uk> writes:
> Capability bits can be made early at the time they are assigned; this
> assignment does not need to be static (although the #define
> CAPAB_EARLY contemplated that it would be). If a bit means the saem
> at both ends, then both ends will know whether it is early. If a bit
> is assigned only at one end, and that end thinks it is early, then
> this is quite fine, since the other end doesn't need to advertise it.
> (Using the same bit for different purposes at different ends is going
> to Go Wrong anyway.)
There's a nasty little problem here.
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.
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
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.
(I'm not clever enough to have thought of this precise scenario --
though I pondered briefly if something like this could cause trouble.
But it just came up in my testing.)
> So overall I think the way to deal with key-exchange-affecting capab
> bits is to simply treat whatever such bits as we locally think exist,
> as early.
I rather agree, but this seems not to be compatible with both the picky
checking and interoperating with old versions. Earliness is not a
property of a cap that you can necessarily discern by looking at it in
isolation: it depends on the other caps around it, particularly for caps
10 and 15. I think the picky checking has to go. Do you agree?
More information about the sgo-software-discuss