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

[denis bider <[e-mail]>]

> There are a range of opinions on how safe it is,
> but in general it seems 0RTT is bad

According to the link provided by Eric, Zero-RTT in TLS is a concept that
does not even exist in SSH. I can see why people would have concerns about
sending data upfront encrypted with a make-do key based only on a
pre-shared secret. That is inherently problematic and needs care.

If SSH had this concept, it would involve bundling some kind of
pre-encrypted data with the client's original KEXINIT. We do not have
anything like that.

EXT_INFO is sent after several round-trips, encrypted after a full,
completed key exchange. I don't see any way that's similar to Zero-RTT.


> What I meant was use the string value "true" for
> boolean true and "false" for boolean false.

In that case I would prefer to go for full strings like "preferred" and
"supported", but that seemed like a waste. :)


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

As-is, the "no-flow-control" extension already dictates there will be no
more than one concurrent channel. What do you have in mind beyond that?

denis



On Fri, Apr 7, 2017 at 9:24 PM, Peter Gutmann <[e-mail]>
wrote:

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