Re: [TLS] Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00

[Michael Clark <[e-mail]>]

On 28/1/15 7:15 am, Dave Garrett wrote:
> On Tuesday, January 27, 2015 03:44:36 pm Martin Thomson wrote:
>> On 27 January 2015 at 12:11, Aaron Zauner <[e-mail]> wrote:
>>> TLS 1.0 is only marginally different from SSLv3. I think a similar
>>> document should exist for TLS 1.0. Yes I'm aware of the implications on
>>> clients/servers.
>>
>> I think that TLS 1.0 is nearing that point too.  But I'm not that
>> enthusiastic about being the hitman there.  Well, not yet.
> 
> Is it at all practical to publish an TLS RFC stating intent to deprecate
> TLS 1.0/1.1 within some fixed timeframe? I think everyone would rather
> phase it out then have to "be the hitman" each time.
> 
> A straw man proposal would be something like:
> 
> 1) TLS 1.0 & 1.1 SHOULD NOT be supported by servers, effective immediately.
> 2) TLS 1.0 & 1.1 MUST NOT be supported by servers after X months.
> 3) TLS 1.0 & 1.1 SHOULD NOT be supported by clients after Y months.
> 
> I know the UTA BCP I-D deals with this area too, but a specific RFC from the
> TLS WG might have more impact at reducing numbers before the inevitable
> catastrophic vulnerability that warrants a diediedie RFC.


+1x ;-) Support draft-ietf-tls-sslv3-diediedie-00


I wholeheartedly agree with the text "(including {03,00}) as the record
layer version number for ClientHello, but they MUST NOT negotiate SSLv3."

   Historically, TLS specifications were not clear on what the record
   layer version number (TLSPlaintext.version) could contain when
   sending ClientHello.  Appendix E of [RFC5246] notes that
   TLSPlaintext.version could be selected to maximize interoperability,
   though no definitive value is identified as ideal.  That guidance is
   still applicable; therefore, TLS servers MUST accept any value
   {03,XX} (including {03,00}) as the record layer version number for
   ClientHello, but they MUST NOT negotiate SSLv3.



Still considering these two drafts neutrally (having arrived at
essentially the same ideas independently before seeing these drafts)
however I have some comments in light of changes in TLSv1.3:


https://tools.ietf.org/html/draft-mavrogiannopoulos-tls-more-extensions-00
   https://tools.ietf.org/html/draft-ietf-tls-encrypt-then-mac-03


1) "Supported Protocol Versions"

"Supported Protocol Versions" could be unbundled from the draft and
taken piecemeal and/or added to the TLSv1.3 draft as a well-considered
SCSV alternative. Bundling with MACSecurityParameters makes it harder to
swallow as one piece. It's useful now for TLSv1.2, but "MAC Security
Parameter" is pork so to speak.


After consideration I would support fixing { 3, 0 } at the "record
layer" and support advertising versions via extension:

    "Supported Protocol Versions": [ { 3, 1 }, { 3, 2 }, { 3, 3 } ]

Later there can be a config change to deprecate TLS 1.0, TLS 1.1 upon
future advisories. Config changes are better than code changes:

    "Supported Protocol Versions": [ { 3, 3 }, { 3, 4 } ]

With this reasoning that the record layer can essentially be fixed at
the major wire version lower bound (which is not verified, so fixing it
makes sense). It is a good solution as it achieves version range tamper
resistance while allowing forwards and backwards compatibility. e.g.
avoiding the downgrades in the case where a client decides it still
wants to support TLS 1.0, when current practice differs from the spec.



2) "Supported MAC Security Parameter" somehow in light of TLSv1.3

    "Supported MAC Security Parameter": [ 128, 192, 256, 384 ]

This spec attempts to addresses verify_data_length issue and allows >=
128 bit tags and addresses this text (given recent cipher suites don't
seem to override verify_data_length):

      In previous versions of TLS, the verify_data was always 12 octets
      long.  In the current version of TLS, it depends on the cipher
      suite.  Any cipher suite which does not explicitly specify
      verify_data_length has a verify_data_length equal to 12.  This
      includes all existing cipher suites.  Note that this
      representation has the same encoding as with previous versions.
      Future cipher suites MAY specify other lengths but such length
      MUST be at least 12 bytes.

with

     Note: TLS 1.2 allows ciphersuites to specify individually the
     "verify_data_length".  Implementations conforming to this document
     MUST ignore the ciphersuite "verify_data_length" if a
     "MACSecurityParameter" has been selected by the server.

However see 4) where I note the undocumented implication of increasing
verify_data_length which has to be done in consideration of the
protection bits of the asymmetric encryption. Is this correct?



3) "Supported Encrypt-then-MAC" somehow in light of TLSv1.3

Changed in light of AEAD and in concert with "MAC Security Parameter"
and in concert with MAC-then-Encrypt removal.

This would require a modified version of Encrypt-then-MAC that rewords
renegotiation and mention of MAC-then-Encrypt for TLSv1.3 compatibility
and considers MAC Security Parameter.

    AEAD tag length + HMAC length = MACSecurityParameter

    ETM-AEAD[aead_cipher,hmac]

This would give you a very firm tamper-resistant handshake supporting
backwards compat to TLSv1.2 along with stronger messages authentication
tags for AEAD ciphers.



4) "Support increasing verify_data_length" somehow

The mechanism in
https://tools.ietf.org/html/draft-mavrogiannopoulos-tls-more-extensions-00
needs to consider the constraint on the asymmetric cipher or PSK
protection bits? It needs to tie the lower bound constraint of the MAC
security parameter to a constraint on the asymmetric algorithm and key
size and the security bits offered?

* We need 3072-bit RSA keys to protect 128 bit verify_data
* We need to use ECC to protect 192 or 256 bit verify_data
  (given a 15360-bit RSA key is required to protect 256 bits)
* We don't want the MAC Security mechanism to leak asymmetric key bits



We're going to need a tiny constraints solver. This is a SAT problem.