[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    Re: [TLS] Update on Origin-Bound Certificates: Now called "Channel ID"
From:       mrex () sap ! com (Martin Rex)
Date:       2012-11-20 21:09:45
Message-ID: 20121120210945.994CA1A397 () ld9781 ! wdf ! sap ! corp
[Download RAW message or body]

Chris Richardson wrote:
>
> Adam Langley <agl@google.com> wrote:
>>
>> Chris Richardson <chris@randomnonce.org> wrote:
>>>
>>> Perhaps I'm being picky, section 4 requires an illegal_parameter alert
>>> if the cipher suite is insufficiently strong.  Doesn't
>>> handshake_failure make more sense here?
>>
>> Does it? From RFC 5246:
>>
>> illegal_parameter
>>       A field in the handshake was out of range or inconsistent with
>>       other fields.  This message is always fatal.
>>
>> Seems to make sense, no?
>
> If I was looking at a packet capture and wanted to figure out what
> exactly went wrong and how to make the connection succeed,
> illegal_parameter would lead me to incorrect conclusions.
> handshake_failure ("unable to negotiate an acceptable set of security
> parameters") would lead me in the right direction.
> insufficient_security would be ideal, but it is only supposed to be
> sent from server to client.
 
Are you refering to this (*) text:

  http://tools.ietf.org/html/draft-balfanz-tls-channelid-00#section-4

   A new handshake message type ("encrypted_extensions(TBD)") is
   defined.  If the server included a "channel_id" extension in its
   "ServerHello" message, the client MUST verify that the selected
*  cipher suite is sufficiently strong.  If the cipher suite provides <
*  80-bits of security, the client MUST abort the handshake with a fatal
*  "illegal_parameter" alert.  Otherwise, the client MUST send an
   "EncryptedExtensions" message after its "ChangeCipherSpec" and before
   its "Finished" message.


rfc5246 defines for the alert "insufficient security" like this.

  http://tools.ietf.org/html/rfc5246#page-33

   insufficient_security
      Returned instead of handshake_failure when a negotiation has
      failed specifically because the server requires ciphers more
      secure than those supported by the client.  This message is always
      fatal.

The second sentence "This message is always fatal" should to be interpreted
as a requirement.  The first sentence describes the purpose for which
rfc5246 uses this alert, it can not be interpreted to limit its usage
for server->client signaling.


However, in a TLS handshake, the client *MUST* include the list of
cipher suites acceptable to the client in ClientHello.  If a cipher
suite is not acceptable to the client, it should not appear in the
ClientHello in the first place.  If it appears, it MUST be acceptable
to the client if the server chooses it.

The suggexted "illegal_parameter" is probably meant for the situation
where the server chooses a cipher suite that the client never offered
(which _might_ be the result of an Man-in-the-Middle attacker).

To me, it is difficult to conceive a usage scenario where the alert
"insufficient_security" would be the appropriate response, rather than
an indication that the client is goofing the list of acceptable
cipher suites in ClientHello.


A client that did _not_ offer AES256_CBC-SHA1 (due to configuration)
should also abort with an illegal_parameter alert if the server chooses
that cipher suite, even though I'm not aware of any security concerns
about that cipher suite (pre-TLS1.1 IVs is a different issue).


-Martin

[prev in list] [next in list] [prev in thread] [next in thread]