[TLS] Comments on various things on agenda (Was: Re: TLS Interim - update and agenda)

[Ilari Liusvaara <[e-mail]>]

On Tue, Mar 03, 2015 at 04:06:22PM -0800, Joseph Salowey wrote:
> 
> The agenda for the interim is available here:
> 
> http://www.ietf.org/proceedings/interim/2015/03/10/tls/agenda/agenda-interim-2015-tls-1

Since I won't be participating, here are some comments and thoughts about
items on the agenda:

Backwards compatibility:
------------------------
Is this about what is needed for compatiblity with past TLS versions?

If so, the things that I think need preserving are:
- ClientHello record header, message header and overall format.
- ClientHello being the only mandatory message in its flight.
- ServerHello record header, message header and version field (first two
  bytes).
- Signature TBS must not cause undesirable interactions with signature
  TBS in past versions.
- The first byte of record header needs to remain subprotocol id (for
  muxing TLS with other stuff)
- If finished messages get removed or changed to be just markers,
  deriving replacement TLS-unique value.
- Having drop-in replacement for TLS-Extractor.


The first three are about downnegotiation being possible without delay,
the fourth is about cross-protocol interactions, and the last three
are about application compatiblity.


Other than theses, I don't see much backwards compat concerns. In
practicular, the handshake changes tend to screw everything that isn't
aware of TLS 1.3 but tries to interpret it.


Or is this about dealing with the 1%+ TLS 1.3 intolerance?


0-RTT:
------
Although basic 0-RTT is essentially just strapping AEAD cipher to
IES (asymmetric encryption using DHFs) using parameters preprovisioned
by the server (or just plain AEAD if resuming), there are more subtle
things:

- Can replay protection be realistically provoded?
- If replay protection can't be provoded, authenticating the
  early data is just plain dangerous.
- Authentication here is very easy to get wrong, even if one somehow
  gets replay protection.
- Even without authentication, this could be useful for protocol banner
  exchange, speeding up protocol startup (and replaying protocol
  banners does not seem to be useful for attackers).

Tickets/Resumption/PSK:
-----------------------
- Tickets or resumption should not compomise FS (by storing MS).
- Can resumption be ratcheded even for re-resumptions (so re-resumption
  doesn't put resumed sessions at risk)?
- Tying resumption to PSK might cause issues with PSK identity
  selection.
- PSK identity selection can require 2RTT in some cases supported
  by TLS 1.2 (plus new messages and changes to messages).
- PSK adds a fair chunk of complexity.


OPTLS:
------
OPTLS can be viewed as two-level key scheme.

The usual benefits of two-level key schemes:
1) Potential for speed enhancement by quickly rotating weaker keys
   (weaker crypto is usually faster).
2) Better isolation of higher key.
3) Allowing quick rotation of lower key.

The drawbacks are that now one has a key that can sign quite damaging
things, and this mechanism increases complexity (by having second
certificate mechanism that works in different way).

However, the higher-level key might be more protectable than sole
key (it may be possible to apply more checks). If attacker just steals
the higher key, you are as screwed as currently.

As for revocation of lower key, it should be noted that in present
WebPKI, realistic revocation times are a day or two. Of course, trying
to push validity period down, one runs into issues with clock skew
(no secure time protocol!).

Also, if one tries to enhance performance, OPTLS inherently ties the
lower key strength with encryption strength, so if one uses weak
key, the encryption will also be weak (encryption strength and strength
of upper key are decoupled like with sole keys, in contrast to the usual
myth).

Also, I am not seeing solid peformance advantages (without HECC, which
currently is not usable).


In short, the worst downsides I see are:
- Extra complexity
- Revocation/expiry of lower-level keys.
- More things to potentially go wrong in development.
- Does not seem to provode solid peformance advantages.


Update/Rekey:
-------------
Rekeying needs to be stateless, so not to cause too much extra complexity
to TLS stacks and especially to applications.

In practicular, this means:
- Simultaneous rekeys are handled properly.
- ACKs can be delayed by an arbitrary amount (since no extra flights
  can be added).
- Rekey must not cause race conditions with TLS-Extractor.


Authentiation via update is very hairy due to application-level issues
it can cause (even if restricted to happen only once per connection).


Key hierarchy/derivation:
-------------------------
- Handshake master secret [hMS]
- Application CtS master secret [cMS] (derives from hMS)
- Application StC master secret [sMS] (derives from hMS)
- Extractor master secret [eMS] (derives from hMS)
- Resumption Premaster Secret [rPMS] (derives from hMS)

The earliest possible points of derivation (any earlier
runs into known problems):
- hMS: After Hellos&Shares
- cMS: After Hellos&Shares
- sMS: After Hellos&Shares
- eMS: After EncryptedExtensions
- rPMS: After entiere handshake

However, it might be better to derive cMS and sMS at respective
finished messages (or placeholders thereof), since that is just before
messages with those keys should start appearing (any earlier is an
error).

Signature format/orthogonal negotiation:
----------------------------------------
Is orthogonal negoiation about decoupling encryption, key exchange
and signatures from each other?

If so, recently I have heard of quite nasty comments about inability
of TLS to do that (these choices seem independent enough, to avoid
the "chinese menu problems").


Regarding signature format, isn't the current rule that the key
specifies the signature format (and then there is capability
advertisment)? Any reason that doesn't still work?

OHOH, CFRG might come up with some new signature format (e.g. something
based on EdDSA), should prepare for that.

I think the changes to add new signature format are:
- Codepoint for signature negotiation
- Format identifier for signature+hash combo (OID in case of X.509
  or RPK).


MTI cipher suites:
------------------
I see there being only two realistic AEAD ciphers:

- AES-GCM (if you have hardware support)
- Chacha20-Poly1305-AEAD (no need for hardware support)

Regarding key exchanges:

ECDHE: 
* NIST curves available (but violate crypto best practices)
* Brainpool curves available (but are slow)
* CFRG curves are not yet available (missing details, but
  I would be surprised if one isn't Curve25519 as-is)
DHE:
* Very slow. Scales badly.

Regarding signatures:

ECDSA:
* Quite crappy (behind the times even when invented, for apparently
  classified reasons).
RSA:
* Slow to sign. Scales badly.
<whatever CFRG comes up with>:
* Not yet.



-Ilari