Re: [TLS] Let's review: draft-ietf-tls-tls13-07 (abridged)

[Ilari Liusvaara <[e-mail]>]

On Wed, Jul 15, 2015 at 02:29:09PM -0700, Eric Rescorla wrote:

Firstly, the 0-RTT binding and how does server know it ended thing:

Assume that if 0-RTT is accepted, the contents affect crypto keys,
channel binding values, finished messages, etc...

>From this it follows that server needs to receive the entiere 0RTT
data before sending its own Finished. But the server would need
a non-0RTT message from client to know it has ended. Unfortunately,
the next client message after 0RTT is client Finished, and that is
waiting on server Finished. Which is obvious deadlock.

In contrast, assume the assumption is not true, that is, contents
of accepted 0-RTT do not affect crypto keys, etc. Where is the
security analysis for that (e.g. with regards to modifying 0-RTT
data)?


> > > 6.1.1. (Closure Alerts)
> >
> > The semantics of closure alerts seem incompatible with half-closes,
> > which some protocols actually use.
> 
> True, but this has been in TLS since the beginning, so there presumably
> should not be any TLS-using apps which depend on it. Do you think this
> is a feature which we should add.
 
Maybe not, the protocols using half-closes are pretty obscure (I think
I have run into only one).

(I did run such over TLS, possibly due to TLS library allowing breaking
of TLS specifications here, but it sucked for various reasons, and I
eventually ended up replacing the encryption layer. This was years
ago).

But there's also "stunnel" which is intended for tuneling protocols
over TLS (I did try that too, it sucked even worse). And if protocol
uses half-closes, those better work there.

> > The relationship between session hash and handshake restarts seems
> > like a hairy problem.
> >
> > Also, I figured out a downgrade attack that works against careless
> > _server_ (not requiring client to do anything else than have weak
> > crypto enabled). Continuing hashes looks to block that attack.
> >
> > It involves attacker sending ClientHello with arbitrary parameters
> > that triggers a retry (very easy to trigger a retry), eating the
> > reply, followed by sending client's original ClientHello. That
> > could trigger crypto downgrade in some badly made servers.
> 
> Do you think you could walk through this in more detail? I'm having
> trouble understanding the issue.

Assume server is bit poorly coded: It latches cryptographic parameters
(ciphersuite, exchange group, etc...) on first ClientHello.

Then attacker sending its own ClientHello that elicts HelloRetryRequest,
eating that and then forwarding real ClientHello might result the
server choosing weaker algorithms than if real ClientHello got sent
directly.

And unless handshake hash covers earlier tries, the handshake hash
would still match on both sides (since the attacker-sent message and
reply to it have been reset away from hash on server side, and
client side never knows about the attacker), despite the fact that
connection has been downgraded.

> > Can anyone expand on the note about impersonation with compromised
> > server key? I can't offhand figure out how attacker can calculate
> > server-side ES (without having also compromised (possibly former)
> > client or (current) server exchange key).
> 
> Will see what I can do.

Well, this was more me being interested on how such attack would
work.
 
> > > 6.3.1.2. (Server Hello)
> >
> > Well, at least it wouldn't be backward compatiblity hazard to remove
> > session_id_len, since it comes after server version.
> 
> I'm sold.
 
However, that would change ServerHello parsing.

Thinking about it, if one decides to be careful with message parsing, one
needs to assign all new/modified TLS 1.3 handshake messages new IDs.

Currently there is only one offending message type w.r.t. that: 14, which
is server_configuration in 1.3 and server_hello_done in 1.2.

Some other messages share IDs, but I think those are compatible (even
CertificateVerify, as it is just one digital signature in both).

> > What happens if Ciphersuite and NamedGroup don't match between HRR
> > and SH/SKS? I expect there be clients that don't check, no matter if it
> > is MUST or not.
> 
> Depends on if we continue the hash. If not, I would imagine that the
> handshake
> succeeds. With that said, this is intended to be a client-side enforcement
> of correct server behavior. Since the client's offered parameters are
> the same as the ones it offered before (with just a new key in
> ClientKeyShare)
> the server should be picking the same parameters as before, no?

Unless there is attacker interfering...

> > Also, for matter of protocol testing, could be useful to give some
> > free values to temporary squat on for extensions that aren't stable
> > yet.
> 
> I agree. Suggest you propose this as a PR.

Might be good idea to stay good bit away from existing registrations,
at least in forward direction, in case a new extension comes along.

Maybe starting from 13000? And maybe something like:

"early_data(TBD), //For testing: 13000", and similarly for others
(except supported_groups, as that already has a codepoint).

(The language might need some improvement).

> > The restriction on extensions appearing also holds for
> > EncryptedExtensions, not just SH or HRR.
> 
> I wonder if we should relax these.

Well, extensions that don't respect the client advertisment restriction
seem to fall into two classes:

- Truly advisory extensions. Can't change key computations nor introduce
  messages. These are obvious candidates for EncryptedExtensions.
- Extended fatal alerts: Extensions that contain additional data about
  rejected connection, since fatal alerts themselves can't seem to
  contain extra data, and sending such thing to client not supporting
  one isn't bad, since the connection already can't work. Obviously
  go to ServerHello.

Can't produce examples of first. Crazy idea for second would be
"captive portal" indication (note, some captive portals have whitelist
of HTTPS sites they allow access to).
 
> > The part about being careful with extensions modifying handshake
> > presumably also goes for functions that are sometimes used for
> > authentication like TLS-EXPORTER or TLS-UNIQUE.
> 
> We may be beyond that point.

I don't think there are any extensions currently that affect those
directly (and even the indirect ones are to be deprecated anyway).

> > > 6.3.1.4.1. (Signature Algorithms)
> >
> > Anonymous should be removed. It is apparently not used (there is reference
> > to another section saying that section uses it, but I can't find in that
> > section how it is actually used).
> 
> I think there is still a desire to have anonymous DH cipher suites.

Anonymous is meant for program-internal placeholder for DH_anon? I
can't find any place it is used on the wire.

And sharing ciphersuites for DH_CERT and DH_ANON is kinda dangerous.

> > There is text that talks about "offering prior versions". Does that
> > refer to insecure version downgrade (I don't suppose TLS 1.1 maximum
> > client would care about what TLS 1.3 spec says).
> 
> It was just to make clear that people shouldn't be adopting this for older
> versions.

Should it be rephrased in terms of MUST NOT offer unless offering at least
TLS 1.2 or something like that?
 
> > > 6.3.1.4.2. (Negotiated Groups)
> >
> > One chould add Curve25519 and Curve448, and the corresponding
> > signature groups (signature groups when CFRG signatures become
> > stable).
> 
> Yep. I think the drafts are now stable for this.

There was brief exchange (not finished) if ECDH and ECSIG grops should
be the same or not.

> > > 6.3.1.5.4. (Pre-Shared Key Extension)
> >
> > Client SHOULD offer at most two PSK identities (one for DH-PSK,
> > the other for pure-PSK)?
> 
> My sense was just to offer a pile of identities, since they're
> untyped anyway.

Well, I think offering more than two identities (potential resumption
of DH-PSK case) is pretty exotic.

But there might be cases where more than two is usable.

> > Also, I would say that 0-RTT data with 0-RTT auth is more dangerous than
> > 0-RTT data with 1-RTT auth (for reasons mentioned earlier in the draft).
> 
> It is. It's also important for some applications.

That was in reference to restriction that if client auth is desried
with 0-RTT data, it has to be 0-RTT too. 

And the danger is from acting on "authenticated" data (it is replayable
after all).

> > Regarding finished, isn't Finished in second flight? Or is this another
> > client Finished?
> 
> The client's Finished is in the second flight. Can you clarify this
> question.

It was regarding this:

"    -  Whether we really want the Finished to not include the server's
        data at all."

The diagram has Finished be in 2nd flight, so it should include
server's data? 

> 
> > Regarding cryptographic parameter set, I think one better prepare for
> > failure (there are multiple causes of server failing to compute keys or
> > decrypt data).
> 
> Can you say more about this?

Well:
- Client expecting resumption, which doesn't pan out.
- Server having ECC certificate, and wanting to save bit of CPU under
  load (ECDH + sign is cheaper than 2xECDH.).
- Client using configuration that has been revoked by server for
  some reason.
- Client trying to use ciphersuite server does not support.
- Client request being routed to new server that doesn't have the
  config keys.

All those cause decrypt failure. Some are pretty unlikely, some are
less so.

> > Also, the record protection used for early handshake messages should be
> > indicated.
> 
> Can you expand on that?

How does the client know what record protection algorithms are valid
for 0RTT transmission for that server?

 
> > Also, considering the dangers of configuration, it might be appropriate
> > to have other permission flags (especially client and server auth) too?
> 
> I could see client auth, as in "I will want you to do client auth"
> but why server auth, since once you have the configuration, you
> have continuing auth.

Configs can do both server auth (which can be quite dangerous) and 0-RTT,
which is much less so.
 
> > > 6.3.7. (Server Certificate Verify)
> >
> > Should PRF hash designation be added in order to avoid attacks from
> > weak PRF hashes?
> 
> Could you say more about this?

If server or client supports some very weak PRF algorithm (they shouldn't,
but we know how practice looks like), could it be possible to forge
signatures by causing the weak hash value collide with one from strong
hash peer accepts?

Also known as "hash firewalling" (too bad most firewall schemes in
signatures are broken).

> > I think note about checking signature algorithm against ciphersuite
> > should be removed.
> 
> This seems to interact with the a la carte discussion.

And also EdDSA / CFRG-whatever. Reusing ciphersuites seems to
assume explicit signaling overrides ciphersuites.

> > Also, with regards to complications of DSA, just dump it? :-)
> 
> I'm fine with that if the chairs declare consensus on it.

As datapoint, either the scan that was used as basis of that curve
pruning doesn't support DSA, or there are no servers that even have
DSA certs.

I think I heard some time back that there are only 4 (or some other very
small number) valid DSA SSL certs in the entiere public Internet.

> 
> > > 6.3.9. (Client Certificate)
> > >
> > Doesn't CertificateRequest override algorithms anyway (and CR isn't an
> > extension)?
> 
> Sorry, I'm not clear on what text you are sad about.

" 6.3.9.  Client Certificate
 
       This message conveys the client's certificate chain to the server;
       the server will use it when verifying the CertificateVerify
       message (when the client authentication is based on signing).  The
       certificate MUST be appropriate for the negotiated cipher suite's
       key exchange algorithm, and any negotiated extensions."

I thought what algorithms are valid for client certificate is dictated
by CertificateRequest, and the same for every ciphersuite that allows
client certificates at all. And CertificateRequest is not an extension
nor message negotiated by extension.

> > > 6.3.10. (Client Certificate Verify)
> >
> > Similar problems as in DSA for server auth. And missing identifier
> > for PRF too.
> 
> Sorry, can you expand on this.

The same as for server certificate verify:
- DSA hash algorithms edge cases.
- Signing hash without indicating what hash it is from.

> > > 6.3.11. (New Session Ticket Message)
> >
> > Eh, if server starts transmitting immediately without waiting for
> > client Finished (as is permitted for case where 1-RTT client auth
> > is not performed), it can't resume the session?
> 
> Good point. This seems like a silly restriction, so let's remove it.

Note that server needs to wait for client Finished before issuing
the ticket, or resumption can get screwy (even just with random network
failures).

> > Would be useful to list what can be used to authenticate peers, in
> > practicular, are the following valid:
> >
> > - Signing TLS-Unique value?
> > - Signing value from TLS-EXPORTER?
> 
> I think we should generate an explicit TLS-channel-binding output
> and recommend people use that.

Due to backward compatiblity, I think that value should be given as
TLS-Unique (i.e. change the definition for TLS 1.3).

TLS spec can freely change how it is is defined provoded that:
- Both sides agree about computation.
- It is auth-critical, so one needs to be careful not to allow
  attacker to screw things by causing mismatched extensions or
  somesuch.


-Ilari