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

From: Joseph Salowey <[email-masked]>
Date: Fri, 23 Jan 2015 11:29:34 -0800

This is a working group last call for draft-ietf-tls-sslv3-diediedie-00.
Please reply to the TLS working group list with an indication of whether or
not the draft is ready for publication and any other comments you may
have.  Please respond by February 16, 2015.

Thanks,

S & J

---

From: Andrei Popov <[email-masked]>
Date: Fri, 23 Jan 2015 19:42:58 +0000

I’m in full support, let’s get rid of SSL.

Cheers,

Andrei

From: TLS [mailto:[email-masked]] On Behalf Of Joseph Salowey
Sent: Friday, January 23, 2015 11:30 AM
To: [email-masked]
Subject: [TLS] Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00

This is a working group last call for draft-ietf-tls-sslv3-diediedie-00.  Please reply to the TLS working group list with an indication of whether or not the draft is ready for publication and any other comments you may have.  Please respond by February 16, 2015.

Thanks,

S & J

---

From: Geoffrey Keating <[email-masked]>
Date: 23 Jan 2015 14:40:46 -0800

> have.  Please respond by February 16, 2015.

I believe this draft is ready to publish in the current form.

---

From: Stephen Checkoway <[email-masked]>
Date: Tue, 27 Jan 2015 13:23:47 -0500

> I’m in full support, let’s get rid of SSL.

+1

-- 
Stephen Checkoway

---

From: Aaron Zauner <[email-masked]>
Date: Tue, 27 Jan 2015 21:11:50 +0100

Joseph Salowey wrote:
> This is a working group last call
> for draft-ietf-tls-sslv3-diediedie-00.  Please reply to the TLS working
> group list with an indication of whether or not the draft is ready for
> publication and any other comments you may have.  Please respond by
> February 16, 2015.  
> 

Read a while ago. Just re-read the draft; nothing to add there. +1.

A short comment:
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.

Aaron

---

From: Martin Thomson <[email-masked]>
Date: Tue, 27 Jan 2015 12:44:36 -0800

> document should exist for TLS 1.0. Yes I'm aware of the implications on

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.

---

From: Dave Garrett <[email-masked]>
Date: Tue, 27 Jan 2015 18:15:22 -0500

> 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.

Dave

---

From: Yuhong Bao <[email-masked]>
Date: Tue, 27 Jan 2015 15:25:01 -0800

> catastrophic vulnerability that warrants a diediedie RFC.

The timeframe would probably have to be in years, given that Windows Server 2008 R1 for example ends support in 2020.

Yuhong Bao

---

From: Hanno Böck <[email-masked]>
Date: Wed, 28 Jan 2015 00:33:56 +0100

On Tue, 27 Jan 2015 18:15:22 -0500
Dave Garrett <[email-masked]> wrote:

> 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.

I think if the deprecation of SSLv3 shows one thing it is that we need
to start now if we want to deprecate it in several years.

There are products on the market developed as late as 2011 that only
support SSLv3. I think a crucial thing would be to identify and stop
people from deploying TLS 1.0-only solutions today - so we won't have
them tomorrow when we really need to deprecate TLS 1.0.

It's a topic I've been discussing with a number of people lately. Ideas
welcome. I thought about adding something to webpages that will warn
users if they connect with anything != TLS 1.2. That could at least
make people aware if they surf with deprecated technology.

P.S.: +1 from me for the sslv3-die-draft. The sooner this gets out the
better.

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: [email-masked]
GPG: BBB51E42

---

From: Aaron Zauner <[email-masked]>
Date: Wed, 28 Jan 2015 00:43:15 +0100

> to start now if we want to deprecate it in several years.

I cannot agree more.

> make people aware if they surf with deprecated technology.

It's been pointed out earlier, but as not many people from TLS-WG
have been active at UTA I just want to reference those two documents
(currently WGLC and submitted for publication):

Recommendations for Secure Use of TLS and DTLS:
https://datatracker.ietf.org/doc/draft-ietf-uta-tls-bcp/

Summarizing Known Attacks on TLS and DTLS:
https://datatracker.ietf.org/doc/draft-ietf-uta-tls-attacks/

Aaron

---

From: Dave Garrett <[email-masked]>
Date: Tue, 27 Jan 2015 18:46:57 -0500

On Tuesday, January 27, 2015 06:25:01 pm Yuhong Bao wrote:
> The timeframe would probably have to be in years, given that Windows Server
> 2008 R1 for example ends support in 2020.

I was thinking in the order of X=12 & Y=18, so yes, > 1 year.

The EOL date for implementations is not a barrier, however. Rather, it could be helpful. Servers could recommended to offer to comply within the "SHOULD NOT" timeframe in some minor update. If some longer "MUST NOT" timeframe could be agreed upon, it could be disabled automatically. (unless overridden by admin against the RFC, of course) This is of course the sort of thing that sounds great to some people but horrific to others. ;)

> them tomorrow when we really need to deprecate TLS 1.0.

If there is some way to define a "new" deployment, we could state separate expectations for existing and new deployments.

This sort of thing leaves a lot up to vendors, but the point of such a proposal is to get the ball rolling rather than wait until the last second.

Dave

---

From: Michael Clark <[email-masked]>
Date: Wed, 28 Jan 2015 09:56:51 +0800

> 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.

---

From: Joe Hall <[email-masked]>
Date: Wed, 28 Jan 2015 22:39:50 -0500

+1

hear hear

-- 
Joseph Lorenzo Hall
Chief Technologist
Center for Democracy & Technology
1634 I ST NW STE 1100
Washington DC 20006-4011
(p) 202-407-8825
(f) 202-637-0968
[email-masked]
PGP: https://josephhall.org/gpg-key
fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871