[Ssh] Re: chacha20 update

[Fabian Bäumer <[e-mail]>]

> Full-transcript signing is basic hygiene today.  It would be nice to
> start exploring ways to get there.  Can we achieve it without a
> full-blown SSH protocol version increment?
There are certainly ways to implement full-transcript signing as a 
protocol extension rather than a new protocol iteration. We actually 
described a possible approach in section 6.1 of our paper "Finding SSH 
Strict Key Exchange Violations by State Learning". However, the question 
remains whether yet another extension should be introduced. Not to 
mention that this is out of scope of the charta of this WG at the moment.

- Fabian

M. Sc. Fabian Bäumer

Chair for Network and Data Security
Ruhr University Bochum
Universitätsstr. 150, Building MC 4/145
44780 Bochum
Germany

Am 13.11.2025 um 08:49 schrieb Simon Josefsson:
> Mouse <[e-mail]> writes:
>
>>>> Can someone remind me if there are any non-STRICT-KEX solutions
>>>> around to the chacha20 security problem?
>> Sure there are.  Perhaps the most obvious is "don't use
>> chacha20-poly1305, at least not as integrated into ssh that way".  More
>> generally, "don't use crypto that's been integrated into ssh wrong".
>> As the Terrapin paper says, "[n]ote that the fault is not with
>> ChaCha20-Poly1305 as an AEAD encryption scheme, but with its
>> integration into the SSH secure channel construciton".
> Is there interest in specifying (and implementing/deploying) a different
> way to use chacha20 and poly1305 in SSH?
>
> How should this be integrated into SSH more securely?
>
> I still think chacha20 with poly1305 is state-of-the-art authenticated
> stream cipher, or are there other alternatives to consider?  We should
> consider using RFC 7539/8439 now, but possible use the original 64-bit
> counter because a 256GB limit is problematic.
>
> I still think it is an improvement to document strict-kex and
> chacha20-poly1305 in RFCs because they are widely deployed.  I can
> sympathise with the argument that we should not mislead readers, and we
> are good at discussing normative language levels and Informational vs
> StandardsTrack so I suppose we play that game here too.
>
> But I think there is a greater danger with having specifications for
> widely deployed protocols circulated as folklore compared to publishing
> a RFC and saying "this protocol comes with concern X".  It is the old
> de-facto vs de-jure discussion again, or perhaps; if by acting as
> gate-keeper to what documents are published, the IETF should try to act
> as a Internet police/dictator.  I think the trend is towards using IETF
> as a policy instrument rather than publisher of what's running on the
> Internet, but I retain some hope there is room to publish specifications
> of running code.
>
>> Another possible solution - which as far as I know has never been
>> implemented - would be for each end to sign over the entire _actual_
>> kex conversation and exchange those signatures early in the encrypted
>> session, before doing anything of import: basically, make up for ssh's
>> choice to sign over only certain pieces of kex.
> Full-transcript signing is basic hygiene today.  It would be nice to
> start exploring ways to get there.  Can we achieve it without a
> full-blown SSH protocol version increment?
>
> /Simon
>
> _______________________________________________
> Ssh mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]