Re: Terrapin

[Niels Möller <nisse%lysator.liu.se@localhost>]

Alexandre Becoulet <alexandre.becoulet%free.fr@localhost> writes:

> Niels Möller wrote:

>> I see some value in the original seqno that is continuously incremented
>> through out the connection, in that it makes it a little easier to think
>> about correct packet order attacks regardless of the key exchange
>> boundaries.
>
> Yes, keeping the original sequence number as a unique packet identifier
> looks like a good idea too me as well.

I'm somewhat undecided. To me, that seems reasonable if and only if we
can arrange so that it is cryptographically protected. We don't want an
attack that deletes or inserts packets during the handshake to result in
a state where the connection succeeds (using independent sequence
numbers for the crypto), but the two parties have a different view on
the sequence numbers to go into UNIMPLEMENTED replies. That opens for
subtle problems that I don't want to have to think about.

So if we want to keep continuous sequence numbers, we need a properly
authenticated packet which implicitly or explicitly makes the claim "the
sequence number of my NEWKEYS packet was xxx". And this is strictly
needed only for the initial key exchange, not key reexchange.

Sam Hartman <hartmans-ietf%mit.edu@localhost> writes:

> So, I think what you are saying is that  if msg_unimplemented is sent
> under a different key (and thus sequence number space if we reset) than
> the unimplemented message, then  there is ambiguity.
>
> I.E.
>
> client: some unknown message
> client: newkeys
> server: newkeys
> server: msg_unimplemented
>
> But why not just flush the pipeline of any unimplemented messages prior
> to sending newkeys on the server side?
> I.E. an msg_unimplemented needs to be sent under the key that the
> unknown message was sent under?

I think that could work; my point is that the details need to spelled
out in a spec that specifies reset (or any other kind of discontinuity)
of sequence numbers).

With your proposal, I don't think one can reliably send an unimplemented
response to packets occuring between the peer's last keyexchange packet,
and the peer's newkeys packet (since you may or may not have already
sent your own newkeys packet when processing the unimplemented packet).
But I think that's a reasonable limitation, as long as it is documented
that implementations should disconnect if this case happens. That's
really not a good place in the protocol to introduce new packets.

On the merits of the UNIMPLEMENTED mechanism itself. My view:

Pro: It looks like a reasonble and simple way to enable gradual
     improvements of the low-level transport protocol, without bumping
     the version number. In theory, the process would be to define new
     messages, that must have some form of ACK when supported, and let
     implementations use them opportunistically, using unimplemented
     responses to disable usage. At some point, define a ssh 2.1
     protocol that makes support for some of the new messages mandatory.

Cons: I'm not aware of any actual usage during the last few decades of
      ssh. It could have been used for MSG_EXT_INFO, but for reasons I'm
      don't remember (or maybe never was familiar with), RFC 8308
      defines magic symbols for the key exchange methods list instead.

Cons: If one implementation wants to unilaterally deploy an extension,
      this mechanism doesn't help much, since message numbers require
      "standards action" registeration with iana, and that's a small
      space. The "reserved" and "local" message numbers are fine for
      experiments and development, but *not* for features to be deployed
      across the Internet.

Regards,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.