Re: [TLS] Issue 49: Finished.verify length

[Eric Rescorla <ekr at networkresonance.com>]

At Sun, 16 Sep 2007 11:36:20 +0300,
<Pasi.Eronen at nokia.com> wrote:
> 
> Eric Rescorla wrote:
> 
> > OK, I see where you're going with this, but I'm not sure it
> > requires us to do anything now. If we're confronted with such a
> > cipher suite, we can just have the document Update TLS 1.2, since
> > it would only be applicable to that new cipher suite. I don't
> > think this needs a version revision.
> > 
> > Unless you're proposing making this a variable length vector,
> > whcih seems like a bad idea, since it should be defined in the
> > cipher suite.
> 
> Yes, the length should be defined by the cipher suite, but I'd like
> to avoid the "Updates: TLS 1.2" part (in general, ciphersuites
> shouldn't need that). And we could avoid that by changing the wire 
> encoding to a variable-length vector now, i.e. change
> 
>    struct {
>        opaque verify_data[12];
>    } Finished;
> 
> to 
> 
>    struct {
>        opaque verify_data<0..255>;
>    } Finished;
> 
> (And say that the verify_data length is 12 octets unless explicitly
> specified otherwise by the ciphersuite)

Well, I don't think changing the encoding is needed. The
verify_data is the only thing in the Finished message so it's
already implicitly encoded. If we want to allow this to change
length without doing an Update, then why not change it to:

   struct {
       opaque verify_data[SecurityParameters.finished_length];
   } Finished;

This leaves a hole but doesn't require changing the wire encoding.

That said, I'd sort of like to discourage changing the length without
good reason, so I'd actually like the first cipher suite to do
this to have to Update: TLS 1.2. However, using the technique above,
we could make this cahnge later without having to impact 
implemenations that didn't support the new cipher suite.

-Ekr





_______________________________________________
TLS mailing list
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls