Subject: Re: applying AES-GCM to secure shell: proposed "tweak"

From: Nicolas Williams <[email-masked]>
Date: Tue, 2 Jun 2009 13:36:55 -0500

On Fri, Apr 10, 2009 at 01:48:01AM -0400, der Mouse wrote:
> > Given that key exchange is not retriable I think the best thing to do
> > is to ignore [the currently-0 last field of SSH_MSG_KEXNIIT] and
> > always place a zero there until we define its meaning.  That will
> > allow us to use it to negotiate new features when both the client and
> > server advertise them (non-zero values).
> 
> Not without breaking interoperability with existing implementations
> that check that the field is zero.
> 
> Or do you maintain that there are no such?  Or that interoperability
> with them doesn't matter?  I find the latter severely busted and the
> former unlikely, especially since the spec does not even suggest, much
> less specify, behaviour for an implementation which encounters a value
> for that field that it doesn't understand.

I believe that we can get to a day when implementations do the right
thing with that reserved field, and in the meantime there's the hated
compat bug database.

Nico
--

---

From: Tim Polk <[email-masked]>
Date: Wed, 3 Jun 2009 14:54:17 -0400

Folks,

I have decided to move forward with publication of draft-igoe-secsh- 
aes-gcm, "AES Galois Counter Mode for the Secure Shell Transport Layer  
Protocol", as an Informational RFC.  I have been very pleased by the  
strong interest on this concluded wg list, and encourage people to  
continue discussing a general solution.  If this moves from the  
discussion stage to draft development, I would be delighted to sponsor  
publication of such a draft.

However, I have also concluded based on that discussion that draft- 
igoe-secsh-aes-gcm - in its current form - fills an immediate need.  I  
also do not believe it is the authors' responsibility to develop a  
generic solution (e.g., negotiating whether the length should be  
encrypted).    That said, I will refocus my near term efforts on  
clearing the remaining discuss so that the draft can be published.  I  
do not believe this should impact any long term efforts that result  
from this discussion, and reiterate my support for publication of a  
generic solution.

Thanks,

Tim Polk