Re: [Curdle] Comments on draft-ietf-curdle-ssh-ext-info

[Peter Gutmann <[e-mail]>]

denis bider <[e-mail]> writes:

>Can you link to any resources where this was discussed? Whether for TLS, or
>in any other context?

It's difficult providing a useful link because it's been discussed on and off
in various threads on the TLS WG list for quite some time.  There are a range
of opinions on how safe it is, but in general it seems 0RTT is bad and 0.5RTT
is iffy.  That is, you can do 0RTT if you're incredibly careful (I talked to a
dev at a large content provider and he said their analysis showed they'd have
to implement nonzero-RTT at the application layer in order to deal with 0RTT
at the TLS layer, which kinda defeats the point), but if anyone ever tries it
I foresee a range of Black Hat/Defcon talks and conference papers on how to
exploit it following shortly afterwards.

>Yes if you could choose the type. But you can't choose the type, because all
>extensions have to use the same type. That type is a string.

What I meant was use the string value "true" for boolean true and "false" for
boolean false.  It seemed pretty intuitive :-).

>OK. I added the following sub-section to my current working copy:

Thanks, that helps to document existing practice and alert implementers.

Incidentally, the places where I've found this is typically embedded, where
there's no chance of every transferring anywhere near ~0 bytes, so it's not a
problem.  OTOH the second issue is real, you can force a reboot of one
vendor's carrier-grade routers by opening an SSH connection to it with a
window size of ~0.

Speaking of embedded, would there be any interest in adding an extension to
say that an implementation only supports one channel, and for the other side
to not try anything fancy beyond treating it as an encrypted telnet?  This is
also fairly common in embedded, where you're emulating encrypted telnet and
nothing more.  scp/SFTP is handled by moving the binary data over the
encrypted-telnet channel, with various degrees of hackery.

Peter.