Re: Terrapin

Mouse <[email protected]> Thu, 21 Dec 2023 20:43:23 -0500 (EST)
Newsgroups gmane.ietf.secsh
Message-ID <[email protected]>
>> 	[...] requires an analysis of the SSH protocol at the
>> 	application layer.

>> 	Historically, the first messages exchanged are SERVICE_REQUEST
>> 	and SERVICE_ACCEPT.  [...]

> Technically, SERVICE_REQUEST and SERVICE_ACCEPT are *not* application
> layer, they're clearly transport layer [...]

I suspect the paper is using "application layer" to mean "everything
above the BPP", rather than in its SSH technical sense.

> But I find no hint in RFC 4253 that they may have cryptographic
> significance.

I think their only cryptographic significance is that they are
typically the first messages after the first NEWKEYS, ie, the ones that
would be affected by prefix truncation.

> I'm not that familiar with EXT_INFO (never had a reason to implement
> it), is there a good reason for the practice of squeezing those
> messages in between NEWKEYS and the SERVICE messages?

I'm not sure (I haven't implemented  EXT_INFO either, nor did I
particiatpe in designing it).  I _think_ the reasoning is that
extensions may have semantics that may affect processing of
SERVICE_{REQUEST,ACCEPT}.

But I think it is a bad idea for the security of the BPP to depend on
the details of what is layered atop it.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email protected]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B