Re: [TLS] Implementing https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [TLS] Implementing https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt
Pasi.Eronen at nokia.com wrote:
> Eric Rescorla wrote:
>
>> I don't think the problem here is really the code point assignment.
>>
>> I would imagine the IESG and IANA to be pretty good about doing
>> advance assignments once the WG has converged on the exact contents
>> of the extension. I know we had pretty good consensus within a
>> smaller group, but if when we run it by some cryptographers they say
>> it's insecure we'll need to change it, at which point it won't
>> really help to have deployed code with the "early" code point.
>
> <wearing area director hat>
>
> I think this is one of those cases where an exception to the usual
> procedures might be in order, but the "once the WG has converged on
> the exact contents" is an important point here. It's relatively rare
> that the -00 version of some internet draft and the final RFC are
> actually interoperable.
>
> Using the same extension number for multiple incompatible versions of
> the draft is probably not a good idea (and probably not very secure,
> either -- if the handshake fails, you don't know if it's due to an
> attack or just interoperability problem, and the latter might be much
> more likely), and I'd like to avoid allocating multiple extension
> numbers for different versions of the draft, too.
>
Would including a version number in the extension help? Then if the format does
change implementations can indicate that it is a version they don't support or
decide they are willing to support an older version.
This would also cover the case where some cryptographic attack is found against
the current form later. We keep the extension number but bump up the version.
Steve.
--
Dr Stephen N. Henson.
Core developer of the OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: shenson at drh-consultancy.co.uk, PGP key: via homepage.
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.