Re: [TLS] Implementing https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt

[David-Sarah Hopwood <[e-mail]>]

Dr Stephen Henson wrote:
> [e-mail] 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.

It's rare for typical RFCs, but this is a very simple extension. The
discussion so far has been about when clients and servers MUST or SHOULD
send the extension; not about changes to its contents or meaning that
would affect interoperability. If no such changes in fact occur, then I
would hope that the existing extension number (0xFF01) could be assigned,
rather than assigning a new number for the sake of it.

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

I don't see any advantage of that over using a different extension number,
*if* the format changes.

In any case, the current draft is -00, and no changes that would not
be interoperable have yet been proposed. So let's avoid prematurely
adding complication where it may not be needed.

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

Adding a new extension would have the same effect.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com