Re: [secdir] secdir review of draft-ietf-uta-tls-bcp-08

[Peter Saint-Andre - &yet <[e-mail]>]

Hi Dave, thanks for the review.

On 2/9/15 6:55 PM, Waltermire, David A. wrote:
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.
>
> Summary: This proposed BCP outlines a number of security issues related
> to use of various revisions of TLS and DTLS. It details a number of
> attacks against various versions of TLS, cipher suites, and modes of
> operation; and provides recommendations to avoid these attacks in a way
> that is applicable to the majority of use cases for these protocols.
>
> This document is generally well-written and clear in its content. I find
> this document to be ready with nits.
>
> My only nit is a minor ambiguity in the text in section 4.2.1. Two of
> the “SHOULD” statements seem to be in conflict (#2 and #3) by my read:
>
> #1 Clients SHOULD include TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as the
>
>     first proposal to any server, unless they have prior knowledge that
>
>     the server cannot respond to a TLS 1.2 client_hello message
>
> #2 Servers SHOULD prefer this cipher suite whenever it is proposed, even
>
>     if it is not the first proposal.
>
> #3 Clients are of course free to offer stronger cipher suites, e.g.,
>
>     using AES-256; when they do, the server SHOULD prefer the stronger
>
>     cipher suite unless there are compelling reasons (e.g., seriously
>
>     degraded performance) to choose otherwise.
>
> The way I read it, if statement #2 is honored, then statement #3 would
> not be honored, even if the stronger cipher suite is ordered before the
> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. I don’t think this is the intent!
>
> It would be better to qualify statement #2 with regards to weaker cipher
> suites to avoid weaker proposals, while allowing stronger proposals.

That's a good catch. #2 needs say "Servers SHOULD prefer this cipher 
suite over weaker cipher suites..." We'll fix that in a revised I-D that 
we plan to submit tomorrow morning (after IETF LC ends).

Peter