Re: [TLS] Comments on draft-rescorla-tls-renegotiate, and a new proposal

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

Nicolas Williams wrote:
> On Sat, Nov 14, 2009 at 07:04:19AM +0000, David-Sarah Hopwood wrote:
>> Still, that's no worse than the situation with the current
>> draft-rescorla-tls-renegotiate. So I think that what I suggested:
>>
>>> [...] only use an extension
>>> as an advisory of patched status (i.e. say that an empty extension SHOULD
>>> be sent if patched), but add the verify_data into the Finished hashes
>>> unconditionally (i.e. as a MUST) for renegotiating handshakes. Then, the
>>> concerns about extensions potentially breaking some servers, and the
>>> concerns about lack of an extension potentially resulting in a security
>>> weakness (due to a client being unable to tell whether a server is patched),
>>> would only arise in mutually exclusive sets of cases.
>> is still an overall improvement.
> 
> I think that adding to my proposed fix an _optional_ signal in the
> client's hello (and, correspondingly, in the server hello), would be
> just fine.  I don't believe it's necessary.

So we differ on whether sending signals in the hello messages is a "MAY"
or a "SHOULD". Here are the key-word definitions from RFC 2119:

# 1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
#    definition is an absolute requirement of the specification.

# 3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
#    may exist valid reasons in particular circumstances to ignore a
#    particular item, but the full implications must be understood and
#    carefully weighed before choosing a different course.

# 5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
#    truly optional.  One vendor may choose to include the item because a
#    particular marketplace requires it or because the vendor feels that
#    it enhances the product while another vendor may omit the same item.
#    An implementation which does not include a particular option MUST be
#    prepared to interoperate with another implementation which does
#    include the option, though perhaps with reduced functionality. In the
#    same vein an implementation which does include a particular option
#    MUST be prepared to interoperate with another implementation which
#    does not include the option (except, of course, for the feature the
#    option provides.)

Since this can affect security and not just functionality, I think that
SHOULD is clearly appropriate here (but MUST is not).

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