ECDH, early capabilities, etc.

[Ian Jackson]

Mark Wooding writes ("Re: ECDH, early capabilities, etc."):
> Ian Jackson <ijackson at chiark.greenend.org.uk> writes:
> > (We don't need a capability flag for the existing Zp group (or
> > manually-configured different Zp group), since that should always be
> > the least-preferred option.  We presume that everyone supports it if
> > we do.)
> 
> I can see a use-case where someone wants to arrange a smooth upgrade
> from some tiny trad-DH group to a big trad-DH group.  If they end up
> sharing a cap slot then the negotiation protocol won't be able to
> distinguish between them.

Yes.

> Left to my own devices, I'd probably redesignate the existing `transport
> number' cap bits as crypto algorithm cap bits, and add an optional
> argument to `diffie-hellman' to override the default cap choice.  But I
> can't bring myself to be very concerned about this.

That would be fine by me.

> These bits seem to have been intended for advertising actual bulk-crypto
> transforms rather than any other kind of thing.  Respecting this intent
> would lead me to allocate an additional range of cap bits for DH groups:
> I want at least two, and there should probably be at least some left
> over for the future.

I think we can redesignate all of these bits, including the
user-reserved ones, for "new crypto of some kind" (although as we
discussed the other day, public key signature algorithms come out of
band and can't be negotiated, so don't show up here).

How about this:

 #define CAPAB_EXPLICIT_TRANSFORM_DH      0x00001000
 #define CAPAB_INEXPLICIT_TRANSFORM_MASK  0x0000ffff

 s/TRANSFORMNUM/BIT/g
 #define CAPAB_BIT_TRADZP           10
 #define CAPAB_BIT_X448             11
 #define CAPAB_BIT_X25519           12

EXPLICIT_TRANSFORM_DH means that all supported key agreement schemes
and transforms are explicitly advertised by a capability bit
somewhere, and abolishes the MASK.

Rules for interpreting the field:

  EXPLICIT  MASK

       0     0000        ANCIENT + TRADZP only

       0     nonzero     specified transforms; TRADZP only for DH

       1     irrelevant  specified transforms and DH groups only
                         (mediumly-old clients will think this means
                         specified transforms but just TRADZP for DH)

If we run out of bits in the old MASK, we can now extend it because
EXPLICIT means we don't have to keep to the bottom 15.

Or do you think that's all too fiddly ?

>   * At MSG3 time: select MSG3BIS if the remote site sent either
>     transport or DH cap bits.  If both our MSG1 and their MSG2
>     advertised DH caps then send an extra byte after the chosen
>     transform number naming the selected group, which is the first in
>     our list which is either trad-DH or which was explicitly advertised
>     in MSG2; we fail if no group was acceptable.  The DH group byte may
>     end up as 0xff if we settled on trad-DH (e.g., I want X25519 or
>     trad, you want X448 or trad).  The hex-encoded DH public value then
>     holds a public element from the stated group.

The dh public value could be not hex for the new groups.

> I don't like the MSG3BIS plan.  In particular, including extra bytes
> based on context from other packets makes protocol dissector writers
> sad.  On the other hand:
> 
>   * The extra information needs to go somewhere.  The responder has no
>     way of discerning the initiator's DH group preference order.
> 
>   * I don't want to add another MSG3 variant because that doesn't seem
>     to be heading in a good direction.

The message type code field is 32 bits.  I see nothing wrong with
#define LABEL_MSG3TER 0x23030323.

> The current `dh_if' interface seems pretty clean, actually.  I hadn't
> planned on messing with it.  The new curves have well-defined interfaces
> in terms of fixed-length byte strings, which I intend to use (so
> there'll be a little tedious messing about with hex strings), but I
> think it'll fit in just fine.

The hexification could be moved to the trad Zp group code.

> I've noticed that the old CBCMAC transform will be incompatible with
> these new groups: it requires 76 bytes of key material, and they'll
> provide 32 or 56 bytes unless I apply expansion.  I don't propose to do
> much about this other than shrugging my shoulders.

SGTM.

> There's currently no default.  If no DH closure named `dh' can be found
> in the arguments to `site' then a fatal error is reported and you lose.
> (While investigating this, I noticed that `find_cl_if' (`conffile.c'
> line 657) can't possibly work if its `fail_if_invalid' argument is
> false -- which it never actually is.)

We discussed this on IRC.  I had misunderstood.

> >  * Add the new algorithms.
> 
> Hmm.  I'd originally planned to do this first, so that the new
> negotiation machinery actually had some extra DH groups to talk about.
> But then the post-negotiation version won't be able to communicate with
> the pre-negotiation version if both are configured to use the same new
> group (the newer version will assume the older one wants to use trad
> DH).
> 
> I'll probably do this anyway, make the thing work, and then reorder the
> patches so that the finished history doesn't contain a compatibility
> break.

Thanks.  I think that would be best.

> This morning I finished the work I wanted to do on factoring out the
> common portions of X25519 and X448, and both are working well in a
> branch of my library.  They have few tendrils other than the testing
> machinery, but I can hack those off easily enough.  The test handling
> will take a bit more effort.

Sounds like good progress!

Thanks,
Ian.

-- 
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.