Subject: [TLS] I-D Action: draft-ietf-tls-tls13-05.txt

From: [email-masked]
Date: Mon, 09 Mar 2015 13:00:17 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Transport Layer Security Working Group of the IETF.

        Title           : The Transport Layer Security (TLS) Protocol Version 1.3
        Author          : Eric Rescorla
	Filename        : draft-ietf-tls-tls13-05.txt
	Pages           : 92
	Date            : 2015-03-09

Abstract:
   This document specifies Version 1.3 of the Transport Layer Security
   (TLS) protocol.  The TLS protocol provides communications security
   over the Internet.  The protocol allows client/server applications to
   communicate in a way that is designed to prevent eavesdropping,
   tampering, or message forgery.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tls-tls13-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-tls13-05

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 10 Mar 2015 12:54:23 +0200

Looked over the diff, some comments:

> [[OPEN ISSUE: This needs to be revised.  See
> https://github.com/tlswg/tls13-spec/issues/5]]

I get a bad feeling about this...

Also, I don't know a reason the problem (as far as I understand it) can't
be fixed by just by internally changing the encryption primitives a bit in
fully wire-compatible way (no protocol change required).

I.e. treat initial "IVs" as sensitive as keying material, and have the
encryptor/decryptor (which is obviously highly trusted due to having primary
keys) internally expand the nonces (which is deterministic process).

NamedGroup list:

I would like weak groups (1-5 and 15-19) to be deprecated (MNU). Those
look quite a bit weaker than anything else (with exception of MD5[1]).

Additionally, the private-use block could be named private_use or
somesuch (so it stands out from other reserved identifiers).

Key derivation:

The spec uses hMS for TLS-Extractor. I think this is cryptographically
suspect, and TE should have its own MS, derived from hMS after
EncryptedExtensions (but before ServerFinished).

Also, if MS for data in both directions are split from each other
(needed for update-rekey), I think keys for directions should be derived
at respective Finished messages.

- Allow server to send early data, even with pending authentication[2]
  (note: The client is _unidentified_, not just unauthenticated)[3]
- Not having "not yet" keys around to potentially abuse[4].

Handshake protocol:

Looks still to be SMACK-trap (duplicating information endpoint already
needs to know and now also check).

And yes, I think that recent events have shown that "what stupid things
one can easily do with this?" is quite legimate concern (whitness 
multiple TLS implementations with the same types of issues as soon
as anybody goes looking).[5]

[1] I think MD5 should be deprecated (MNU) from HashAlgorithm and
SHA-256 be promoted to default (AFAIK, currently SHA-1).

[2] Useful for protocol banners and such (ALPN does not scale!)

[3] Unidentified peer seemingly makes it quite a bit harder to do
anything stupid than unauthenticated.

[4] Deriving just before finished does create such "not yet" keys.

[5] Also update-auth, even allowed just once can be accidentially
used in very bad ways in certain kinds of protocols and environments.

-Ilari