Re: 9.2.2 Cipher fallback and FF<->Jetty interop problem

Brian,

On Sep 5, 2014, at 6:29 PM, Brian Smith <brian@briansmith.org> wrote:
> ...
>> The prohibition for compression probably only belongs in the Security Considerations.  I notice that compression is already a SHOULD NOT in the current version of TLS-BCP, and I think it is OK to make it a MUST NOT and cite the BREACH attacks.
> 
> I think it is better to put all the TLS requirements in one place. I
> think it is good to mention *why* TLS compression is prohibited in the
> security considerations, but the statement that it is prohibited is
> best left where it is, to reduce the chances of it being overlooked.
> Note that BREACH is one issue, but the overall problem that is being
> avoided is more general than BREACH.

My concern is that none of the security considerations for those TLS requirements are currently documented in the security considerations section of the document.  And FWIW section 9.2 could have all of the requirements with references to section 10.x that talks about the TLS security considerations driving those requirements.

Put another way, if you don't know why something is required or forbidden, your implementation could be technically conforming while doing so insecurely because you  support a different TLS extension that has the same problems as renegotiation or compression or the "bad" cipher suites you are trying to avoid...

(and no, you can't protect against everything, but you *can* document your reasoning for the "important" stuff to guide implementors and future editors...)

>> The prohibition for renegotiation needs to be considered carefully - this is an area of intense discussion in the TLS WG and I expect there will be some form of renegotiation/rekeying in TLS 1.3 to address long-lived connections (at least).  You *could* prohibit renegotiation to obtain client credentials, but even then I would make it a SHOULD NOT and cite interoperability and potential security concerns, and any SHOULD NOT/MUST NOT for security reasons belongs in section 10 (security considerations)...
> 
> Renegotiation doesn't compose properly with HTTP/2 connection
> coalescing, and that's why it is prohibited in HTTP/2.

I understand why we don't want renegotiation-for-getting-client-credentials with HTTP/2. But the other use of renegotiation (re-keying) is still valid in this case and probably more relevant since a coalescing proxy will need re-keying more often than a direct connection...

In any case, the current text doesn't say why renegotiation is not allowed in the general case or why it is OK to allow initially (which would seem to have the same problems with coalesced connections and creates more interop problems when proxies are involved...)

> ...
>> I am VERY uncomfortable with Section 9.2.2 as currently written.  Basically it makes it impossible to use a TLS/1.2 [RFC5246] implementation since you are prohibiting the only required TLS/1.2 cipher suite (TLS_RSA_WITH_AES_128_CBC_SHA).  I would be much more comfortable requiring base TLS/1.2 (TLS_RSA_WITH_AES_128_CBC_SHA) and recommending the rest.
> 
> It was a mistake for the TLS 1.2 specification to say
> TLS_RSA_WITH_AES_128_CBC_SHA is mandatory-to-implement at all, for the
> reason that you and I both gave. But, that is in the past. And, note
> that the TLS 1.2 specification allows an application profile of TLS to
> override that requirement.

I must have missed that - everything I see in there says it is unconditionally required in order for TLS/1.2 implementations to interoperate.

And even if an application profile *can* override the requirement, I wouldn't want to create a profile that does not guarantee that any two conforming implementations can work with each other.  And that would mean naming one or more required cipher suites, and IMHO *if* that is the path chosen then it should happen in a separate document defining just the TLS/1.2 profile so that it can be updated independent of HTTP/2 (and used by other protocols if it turns out to be generally useful...)

> Although I disagree with mandating any particular cipher suite, the
> more general HTTP/2 requirement that a forward-secret cipher suite be
> used is appropriate.
> 
>> Finally, there is nothing in section 10 about the TLS-BCP recommendations; in addition to the two prohibitions from section 9.2.1, you could throw in the "MUST NOT negotiate RC4" and highlight other important stuff concerning TLS and HTTPS.
> 
> It is likely HTTP/2 will get finished before TLS-BCP is finished.
> Let's not create process problems by trying to cite the TLS-BCP
> document. Also, IIUC, the TLS-BCP RFC can update the HTTP/2 RFC to
> improve it after HTTP/2 is published, if there ends up being some
> unforeseen conflict.

I thought informative references to I-Ds were allowed?

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

Received on Friday, 5 September 2014 23:02:48 UTC