headers
Frank Cusack | 3 Apr 2003 10:52

Re: IESG feedback on core drafts.

On Mon, Mar 31, 2003 at 08:08:59AM -0800, Chris Lonvick wrote:
>    The "none" cipher is provided for debugging and should never be used
>    except for that purpose.  It's cryptographic properties are
>    sufficiently described in RFC 2410.

I believe the "none" cipher has legitimate uses besides debugging.  You
may want the authentication mechanisms provided by SSH, but not the data
confidentiality.  EG: you are copying already encrypted data between
machines that have such low CPU power that encryption is a significant
overhead.  Even if you disagree, *it goes without saying* that you
wouldn't use the "none" cipher where integrity/privacy matters.

If you /were/ to keep this text, shouldn't 'should' be in caps?

RFC 2410 seems too humorous to be referenced in a security considerations
section.  Maybe I'm just in a bad mood though.

/fc
Permalink | Reply | 6 comments |
headers
David Wagner | 3 Apr 2003 11:04
Picon

Re: IESG feedback on core drafts.

Frank Cusack  wrote:
>On Mon, Mar 31, 2003 at 08:08:59AM -0800, Chris Lonvick wrote:
>>    The "none" cipher is provided for debugging and should never be used
>>    except for that purpose.  It's cryptographic properties are
>>    sufficiently described in RFC 2410.
>
>I believe the "none" cipher has legitimate uses besides debugging.  You
>may want the authentication mechanisms provided by SSH, but not the data
>confidentiality.  EG: you are copying already encrypted data between
>machines that have such low CPU power that encryption is a significant
>overhead.

Do you really think there is any real-world case where this will come up?
Remember, to use SSH you have to be able to do a public-key operation.
I'm hard-pressed to imagine any scenario where the public-key operation
is feasible but there is no symmetric-key encryption that will be.

Allowing people to use the none cipher is asking for trouble.  Many people
expect the (symmetric-key) crypto to be much more expensive than it really
is.  The ``SHOULD NOT use "none" cipher'' language seems reasonable.
Permalink | Reply | 2 comments |
headers
Frank Cusack | 3 Apr 2003 12:14

Re: IESG feedback on core drafts.

Some more comments.  BTW, thanks for taking the time to collect and
compose this text.

On Mon, Mar 31, 2003 at 08:08:59AM -0800, Chris Lonvick wrote:
>    twofish, serpent and blowfish.  AES has been accepted by cryptographic
>    experts as being stronger than most of the other ciphers in use today

It has?  I don't think DES had that property and I'm not sure (ie, I don't
know either way) that AES has that property.  eg, one of the considerations
for selection was a design that allows for efficient implementation in
software (unlike DES).
http://csrc.nist.gov/CryptoToolkit/aes/pre-round1/aes_9709.html#sec4

Certainly, AES is strong.  Is it stronger than MOST of the other ciphers
in use today?  What ciphers are in use today?

I might just be being too picky.

>    and it is being implemented in other security protocols as it is within
                                                             ^^^^^^^^

"as well as", maybe?

>    SSH.  As always, implementors and users should check current literature
>    to ensure that no recent vulnerabilities have been found in ciphers used
>    within products.  Implementors should also check to see which ciphers
>    are considered to be relatively stronger than others and should
>    recommend their use to users over relatively weaker ciphers.  It would
>    be considered good form for an implementation to politely and
>    unobtrusively notify a user that a stronger cipher is available and
(Continue reading)

Permalink | Reply | 0 comments |
headers
Frank Cusack | 3 Apr 2003 12:43

Re: IESG feedback on core drafts.

On Thu, Apr 03, 2003 at 09:04:04AM +0000, David Wagner wrote:
> Frank Cusack  wrote:
> >On Mon, Mar 31, 2003 at 08:08:59AM -0800, Chris Lonvick wrote:
> >>    The "none" cipher is provided for debugging and should never be used
> >>    except for that purpose.  It's cryptographic properties are
> >>    sufficiently described in RFC 2410.
> >
> >I believe the "none" cipher has legitimate uses besides debugging.  You
> >may want the authentication mechanisms provided by SSH, but not the data
> >confidentiality.  EG: you are copying already encrypted data between
> >machines that have such low CPU power that encryption is a significant
> >overhead.
> 
> Do you really think there is any real-world case where this will come up?

Sure, I regularly copy terabytes of data around, data that is not
encrypted but also not worth protecting.  The time cost of encryption
is visible to me, partly for billing reasons.

/fc
Permalink | Reply | 1 comment |
headers
Frank Cusack | 3 Apr 2003 12:51

Re: IESG feedback on core drafts.

On Thu, Apr 03, 2003 at 02:43:11AM -0800, Frank Cusack wrote:
> On Thu, Apr 03, 2003 at 09:04:04AM +0000, David Wagner wrote:
> > 
> > Do you really think there is any real-world case where this will come up?
> 
> Sure, I regularly copy terabytes of data around, data that is not
> encrypted but also not worth protecting.  The time cost of encryption
> is visible to me, partly for billing reasons.

Then again, anyone who is going to use 'none' is going to have really
good reasons for it.  There's no harm in discouraging it.  Part of my
argument was that it seems damn obvious that you shouldn't use "none".

/fc
Permalink | Reply | 0 comments |
headers
Markus Friedl | 3 Apr 2003 13:28
Picon
Favicon

Re: IESG feedback on core drafts.

On Thu, Apr 03, 2003 at 12:52:37AM -0800, Frank Cusack wrote:
> On Mon, Mar 31, 2003 at 08:08:59AM -0800, Chris Lonvick wrote:
> >    The "none" cipher is provided for debugging and should never be used
> >    except for that purpose.  It's cryptographic properties are
> >    sufficiently described in RFC 2410.
> 
> I believe the "none" cipher has legitimate uses besides debugging.  You
> may want the authentication mechanisms provided by SSH, but not the data
> confidentiality. 

in this case you can use arcfour, i think.

-m
Permalink | Reply | 0 comments |
headers
Tero Kivinen | 3 Apr 2003 15:48
Picon
Picon
Favicon

Re: IESG feedback on core drafts.

> > >    In addition, the CBC mode attack can be mitigated by
> > >    ensuring the an SSH_MSG_IGNORE packet preceeds any real
> > >    data at the start of a TCP packet.
> > A TCP packet? How is the TCP mapping relevant?

To the attack to work, the attacker needs to know the IV of the next
block that is going to be encrypted. In CBC that is the output of the
encryption of the previous block. If the attacker does not have any
way to see the packet yet (i.e it is in the internal buffers of the
ssh implementation or even in the kernel) then he cannot use this
attack. If the last packet has been sent out to the network (i.e
attacker will know it) then he can use the attack.

In optimal case we would need to add extra packet only if the packet
has been sent out to network, and there is no other packets waiting in
any buffers. Unfortunately it is not normally easy to see if there are
unsent packets in the kernel, thus for example ssh's secsh checks if
there is any data in its own buffers, and if not then it will add
extra packet. 

If we add new packet to stream every time the attacker knows the IV
that is supposed to be used for next packet, we will always cause the
attacker to guess wrong IV, thus his attack will never be successfull.

>    Additionally, the CBC mode attack may be mitigated through the
>    insertion of packets containing SSH_MSG_IGNORE.  This technique may be
>    used to obfuscate the relative positions of the enciphered message and
>    its use is encouraged.

It is not to obfuscate the relative positions, it is to change the IV
(Continue reading)

Permalink | Reply | 12 comments |
headers
Eric Rescorla | 3 Apr 2003 17:01

Re: IESG feedback on core drafts.

Tero Kivinen <kivinen <at> iki.fi> writes:

> > > >    In addition, the CBC mode attack can be mitigated by
> > > >    ensuring the an SSH_MSG_IGNORE packet preceeds any real
> > > >    data at the start of a TCP packet.
> > > A TCP packet? How is the TCP mapping relevant?
> 
> To the attack to work, the attacker needs to know the IV of the next
> block that is going to be encrypted. In CBC that is the output of the
> encryption of the previous block. If the attacker does not have any
> way to see the packet yet (i.e it is in the internal buffers of the
> ssh implementation or even in the kernel) then he cannot use this
> attack. If the last packet has been sent out to the network (i.e
> attacker will know it) then he can use the attack.
>
> In optimal case we would need to add extra packet only if the packet
> has been sent out to network, and there is no other packets waiting in
> any buffers. Unfortunately it is not normally easy to see if there are
> unsent packets in the kernel, thus for example ssh's secsh checks if
> there is any data in its own buffers, and if not then it will add
> extra packet. 
Yes, I'm familiar with the Rogaway attack, but it's a mistake to
get fixated on TCP mapping.

For instance, Consider the following case:

Client                                                  Server
------                                                  ------
TCP(seq=x, len=500)           ->
   contains Record 1
(Continue reading)

Permalink | Reply | 11 comments |
headers
Phillip Remaker | 3 Apr 2003 19:37
Picon
Favicon

Re: Please publish attached draft-ietf-secsh-break-01

> This looks good - I've had a few requests for this functionality in
> PuTTY. Are any server maintainers planning to implement it soon? I'd
> certainly like to have it in the next PuTTY release, but I'd also
> quite like the documentation not to have to confess `actually no
> servers support this so it's a bit useless' :-)

I am pushing to get it in Cisco, and I am trying to also get it on
Cyclades's roadmap.

Do you have any other vendors that we should hassle?
Permalink | Reply | 0 comments |
headers
Tero Kivinen | 3 Apr 2003 21:43
Picon
Picon
Favicon

Re: IESG feedback on core drafts.

Eric Rescorla writes:
> > In optimal case we would need to add extra packet only if the packet
> > has been sent out to network, and there is no other packets waiting in
> > any buffers. Unfortunately it is not normally easy to see if there are
> > unsent packets in the kernel, thus for example ssh's secsh checks if
> > there is any data in its own buffers, and if not then it will add
> > extra packet. 
> Yes, I'm familiar with the Rogaway attack, but it's a mistake to
> get fixated on TCP mapping.
... 
> (3) Yet, the attack is possible because Record 1 has already
>     been seen.

Yes, as I say above the important thing is if it has been ever sent
out to network.

> As this example indicates, it's totally unsafe to use the existence
> of unflushed data in the TCP buffers proper as a guide to whether
> you need an empty packet, since when you do the second write(),
> the buffers will contain the un-ACKed Record 1.

It is safe, if and only if you get the information from the TCP stack
if that data at the end of the TCP buffers have ever been sent out to
network. If it has never ever been sent out to network, then we do not
need the extra packet, if it has already been sent out, then you do
need extra packet. 

> The point is that you can't safely talk about TCP packets. If you want
> to talk about conditional empty packet insertion you should talk about
> the data being "written" "delivered to the network"
(Continue reading)

Permalink | Reply | 10 comments |

Gmane