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

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 15 Jul 2015 17:15:23 +0300

Let's review: draft-ietf-tls-tls13-07

This is abridged version of mail I sent earlier, but was too large for
the list due to its sheer size.

(Note: I omitted some stuff I saw recently discussed (e.g. pruning
unused crypto algorithms) or I remember discussed. I didn't explicitly
check issue list when doing this).

Note: The issue list could use some cleanup. It has multiple duplicate
issues (especially about fixing THS) and also some issues that no longer
look applicable.

> Header

Isn't 4346 already obsoleted by 5246, which this document also obsoletes?

4366 seems to be jointly obsoleted by 5246 and 6066.

5246 and 5077 are not in numerical order, whereas the rest are.

> 1. (Introduction)

DSA should be replaced by ECDSA (DSA is pretty much obsolete)?

> 1.2. (Major Differences from TLS 1.2)

Is this meant to be changelog or list of changes? It in current form
looks more like a changelog.

> 4.9.1. (Digital Signing)

I think someone wanted randoms back here in order to support privilege
separation (which I think is important to support, I consider it much
more important than being "HSM friendly")?

Reading what current draft of 4492-bis says, the hash function used is
determined by signature_algorithms (or presumably the corresponding
mechanism in CertificateRequest for client certs).

Also, to my knowledge, there is no mechanism to indicate in ECDSA
certificate what hash algorithms are allowed.

> 4.9.2. (Authenticated Encryption with Additional Data (AEAD))

The example looks like it belongs to section 4.9.1, as it is about
signatures, not AEAD construct.

> 5. (The TLS Record Protocol)

Documenting the security properties of TLS would be useful...

The lack of record length hiding may be problematic in protocols that
have no place for cover traffic (e.g. can DNS requests contain padding,
DPRIVE WG is apparently planning on putting DNS into (D)TLS?).

> 5.2.1. (Fragmentation)

Zero-length fragments of application data are very much visible in
ciphertext (unless record padding is added), so those are not currently
useful as traffic analysis countermeasure.

> 5.2.2. (Record Payload Protection)

There looks to be latter limits that restrict ciphertext size to 2^14
+1024, which is smaller than 2^14+2048 here (but those limits might be
tightened further).

As for amount of expansion needed for length-hiding, I think that being
able to represent 16384-byte record with no padding would be enough
(since record sizes cap at 16384 bytes anyway).

> 6. (The TLS Handshaking Protocols)

Are encryption keys, finished value (tls-unique) and exporter secret
part of session or not?

> 6.1.1. (Closure Alerts)

The semantics of closure alerts seem incompatible with half-closes,
which some protocols actually use.
 
> 6.1.2. (Error Alerts)

Could use another example of warning alert, now that no_renegotiation
is not a warning anymore?
 
> 6.2.1. (Incorrect DHE Share)

EncryptedExtensions is marked optional in Figure 2, but not Figure 1?

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.

> 6.2.2. (Cached Server Configuration)

Issue #184 manifests here too. I think both accepting and provoding
configuration in the same handshake is sensible (key rollover), and
later the draft talks about exactly that case.
 
Also, maybe note that provoding the message does not alter the
configuration hash (even if there is no existing one) could be useful.

> 6.2.3. (Zero-RTT Exchange)

No EncryptedExtensions?

How would the server know when 0-RTT data ended, so it could send its
ServerHello?
 
Also, how is the 0-RTT data bound to session if accepted, or is there
a security analysis for leaving this binding out?

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

> 6.3. (Handshake Protocol)

Missing encrypted_extensions (it is a handshake message, right)?
 
> 6.3.1.1. (Client Hello)

The non-match case gives HelloRetryRequest, not ServerHello, right?

s/should/SHOULD/ in description of session_id?

I don't think client extensions are optional anymore in TLS 1.3 (being
required for successful handshake.

Also, TLS 1.2 servers that care about security (are there actually any?)
already require extensions for successful handshake.

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

Note: Unlike client extensions, I think server extensions might be empty
in TLS 1.3 handshake (since extensions required for GDHE_CERT type key
exchanges are not replied to by server).

> 6.3.1.3. (Hello Retry Request)

server_version and cipher_suite in HRR seem bit dangerous to me. If
HashAlgorithm contained all PRF hashes (currently it does), one could
use that to designate PRF hash.
 
Merging DTLS cookies might be a good idea. However, then group mismatch
wouldn't be the only source of failure (which needs some text adjustment
about the selected_group check).

s/use for/add to/ in description of selected_group?

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.

Heck, I recently heard of servers that only partially(!!!) check client
Finished (or omit the check entierely).

> 6.3.1.4. (Hello Extensions)

supported_groups is 10, right?

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.

The restriction on extensions appearing also holds for
EncryptedExtensions, not just SH or HRR.

It could also be useful to deprecate some extensions (client MAY send
for backwards compat, server MUST NOT select).

Some candidates:
- truncated_hmac: Block modes have been removed.
- encrypt_then_mac: Block modes have been removed.
- extended_master_secret: The THS bug is fixed anyway.
- sessionticket TLS: Session tickets are deprecated.
- renegotiation_info: The renego bug is fixed anyway.

The interaction of some extensions with PSK-based resumption isn't
that clear. This is further complicated by the fact that PSK can also
start a new session.

Reference to "error alerts". Should that be "fatal alerts"?

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.

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

Description of signature refers to 6.3,2, which is about SKS, which does
not seem to have anything to do with signatures (leftover from TLS 1.2?)

Then in description of the extensions there is reference to 6.3.4 and
6.3.2. 6.3.4 looks relevant, 6.3.2. doesn't look so.

Also, making signature_algorithms mandatory would allow dropping the
backward compatiblity special cases from here.

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

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

> 6.3.1.5.1. (Diffie-Hellman Parameters)
> 6.3.1.5.2. (ECDHE Parameters)

Drop the wrappers? Then DHE and ECDHE could be unified (the unification
is currently blocked by different lengths of the length field).
 
The point description might make it more clear that encodings are per-
curve (altough most curves use X9.62).

Does the note about only single point format apply to signatures too
(if so, ec_point_formats could be deprecated).

Regarding CFRG curves, the current draft (for TLS 1.2) specifies use
of the native point format (32/56 octets) as if it was uncompressed.
 
> 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)?

This would imply that one can't resume pure-PSK sessions, but that
does not look to be useful anyway.

Also, could be useful to state that the PSK identity hint from
previous versions has been deprecated.
 
> 6.3.1.5.5. (Early Data Indication)

s/MUST not/MUST NOT/ in description of early_data with client auth?

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

Eeh, the rule for detecting end of 0RTT data, isn't the next client
handshake message from the next flight at least in some cases (and
waiting would obviously deadlock)?

Again, how is binding of early handshake messages done (or security
analysis showing this unnecressary)?

Client receiving rejection knows that auth failed and data failed, it
might try to fix things up in its next flight.

As for what to sign for client auth, the ClientHello and Certificate
(at least)? One thing to note is that if verify contains randoms, then
server_random isn't available.

Regarding finished, isn't Finished in second flight? Or is this another
client Finished?

Regarding cryptographic parameter set, I think one better prepare for
failure (there are multiple causes of server failing to compute keys or
decrypt data).

Also, how does known_configuration interact with PSK (other than
configurations seemingly not being usable with PSK)?

Also, the record protection used for early handshake messages should be
indicated.

I think there are basically two things to signal for 0RTT:
- What key material is used (either by PSK ID or configuration ID)
- What record protection (and KDF to derive keys) is used?

Tying the latter to client offered ciphersuites is probably not wanted.

> 6.3.2. (Server Key Share)

Add that connection will be rekeyed immediately after this message, and
that it MUST be the last message in record it is in?
 
> 6.3.3. (Encrypted Extensions)

Some of the figures have this as mandatory, some optional. Which is it?

Yeah, would be good to have explicit list of what goes to SH, and what
goes to EE.

Also, the list is affected by #184, as some extensions introduce extra
messages (esp. status_request{,_v2} and signed_certificate_timestamp).

> 6.3.4. (Server Certificate)
> 
>       The certificate MUST be appropriate for the negotiated cipher
>       suite's key exchange algorithm and any negotiated extensions.

If signature_algorithms is mandatory, this would then key to that for
signature algorithm, not ciphersuites (and even if it isn't, it would
then key to its fallback default).

Could change example of alternative certificate formats to RFC7250 (it
seems better designed than RFC5081).

Doesn't TLS 1.3 always use the certificate for signing, with indicated
algorithm (which obviously needs to be supported by peer)? Wouldn't it
make more sense to talk about signature algorithms instead of key
exchange algorithms. (Unless some key exchange that uses non-signing
certificates is added).
 
> 6.3.6. (Server Configuration)
 
Use TTL instead of of explicit time for expiration, as broken clocks
are abound (also, just 32-bit field that only goes up to 2106 or so)?

Also, considering the dangers of configuration, it might be appropriate
to have other permission flags (especially client and server auth) too?

Also, Could be useful for client to know what ciphers it can use for
0-RTT data?

> 6.3.7. (Server Certificate Verify)

Should PRF hash designation be added in order to avoid attacks from
weak PRF hashes?

I think note about checking signature algorithm against ciphersuite
should be removed.

Also, with regards to complications of DSA, just dump it? :-)

> 6.3.9. (Client Certificate)
> 
Doesn't CertificateRequest override algorithms anyway (and CR isn't an
extension)?

Again, could use RFC7250 instead of RFC5081 as an example?
 
> 6.3.10. (Client Certificate Verify)

Similar problems as in DSA for server auth. And missing identifier
for PRF too.

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

> 7.2.3. (Elliptic Curve Diffie-Hellman)

Probably needs different description for Curve25519 and Curve448.
Those are functions that take in octet strings and output octet strings
(32 or 56 bytes).

> 11. (IANA Considerations)

Yeah, looks to need a rewrite. Doesn't register the new stuff, and
furthermore has problems like:

- signature_algorithms is already defined by RFC5246.
- SignatureAlgorithm registry is already defined.
- HashAlgorithm registry is already defined.
 
> A.4. (The Cipher Suite)

Probably remove note about 001C and 001D, since lots of ciphersuites are
now reserved to avoid collisions with old ones.

> C.1. (Random Number Generation and Seeding)

Replace SHA-1 with SHA-256?

The example is completely obsolete. Any sort of modern PCs have much
faster timers (some reaching multi-GHz rates) and one really should use
Operating System for (seeding) random numbers.

> C.4. (Implementation Pitfalls)

- Do you handle required handshake messages being missing or handshake
  messages being in wrong order properly (i.e. terminate the connection)?

Also, ECDSA signing operations need timing protection.

s/DSA/ECDSA/ in seeding? And shouldn't k be determinstically generated?

> E.1.1. (Authentication and Key Exchange)

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?

Both have been seen in the wild, so these better be secure ways. This
also goes for "anonymous" key exchange.
 
> E.1.2. (Version Rollback Attacks)

Is the note about PKCS #1 block type 2 about RSA key exchange, which is
deprecated?

-Ilari

---

From: Dave Garrett <[email-masked]>
Date: Wed, 15 Jul 2015 12:27:27 -0400

> Let's review: draft-ietf-tls-tls13-07

Eric obviously does all the heavy lifting here, but I can reply to a
few bits in the areas I've touched.

> check issue list when doing this).

Some of these already do have issues/PRs so I'll cite them here along
with the bits I have fixed in my WIP branch for the discussions we've
been having about alerts and certs.

I have quite a few PRs pending review by ekr, at the moment. Note that
PR 195 is under my name, but is mostly Sean Turner's commits. It's large
and was bitrotted severely over time, so ekr and I had to clean it up.
(the original is PR 152 with bits from 150)

> 5246 and 5077 are not in numerical order, whereas the rest are.

I have a pending PR that fixes this:
https://github.com/tlswg/tls13-spec/pull/198/files

> looks more like a changelog.

It is just a changelog for now. Will definitely need to be replaced by a
summary for final RFC.

> (since record sizes cap at 16384 bytes anyway).

https://github.com/tlswg/tls13-spec/issues/55

> required for successful handshake.

I'll address this in my WIP branch for changes we've been discussing on-list.

> session_id_len, since it comes after server version.

There's a comment in there from ekr asking if we should remove. The answer
is a clear yes, seeing as backwards compatibility is already gone here.

https://tools.ietf.org/html/rfc5246#section-7.4.1.3

The compression field was already dropped, so there's no point in having a
placeholder for this unless a new placeholder is added for that too.

This message does not need to maintain backwards compatibility, though.
It can never be sent to a pre-TLS 1.3 client, as the client has to offer 1.3+
for the server to negotiate it. A note that this structure has changed since
1.2 is probably warranted for servers that want to also know how to send
a proper one for backwards compatibility, but modifying it here isn't helpful.

> - truncated_hmac: Block modes have been removed.
[...]
> - renegotiation_info: The renego bug is fixed anyway.

I have bits for both of these on my WIP branch. (not in any of my PRs pending
ekr's review, yet)

> s/MUST not/MUST NOT/ in description of early_data with client auth?

I fixed that in my WIP for all the alert and certs changes we've been
discussing on list.

> now reserved to avoid collisions with old ones.

I have a pending PR that updates the whole section.
This bit is already dropped.

https://github.com/tlswg/tls13-spec/pull/180/files

> Replace SHA-1 with SHA-256?

Done in my WIP along with rest of SHA-1 deprecation,
as was discussed very recently.

Dave

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 15 Jul 2015 14:29:09 -0700

Ilari,

Thanks for your detailed comments.

> 5246 and 5077 are not in numerical order, whereas the rest are.

This was updated in a recent PR by Dave Garrett.

> DSA should be replaced by ECDSA (DSA is pretty much obsolete)?

Yes, I can do that. I'm happy to remove DSA entirely if the
chairs declare consensus on this.

> looks more like a changelog.

It's just a changelog. I'll eventually make it a real list in the
final version.

> more important than being "HSM friendly")?

I think it was Nikos. Nikos, if you'd like to submit a PR that
we can discuss, that would be great.

> mechanism in CertificateRequest for client certs).

Well, it's negotiated by that, but indicated in the message.

> certificate what hash algorithms are allowed.

I am also unaware of one.

> signatures, not AEAD construct.

Oops. Yeah, I'll fix that.

> Documenting the security properties of TLS would be useful...

Agreed. I intend to rewrite the entire security analysis soon.

> useful as traffic analysis countermeasure.

Agreed. We have PRs for adding padding, but they haven't been merged
yet because I wanted to get key management squared away.

See: https://github.com/tlswg/tls13-spec/pull/147

> (since record sizes cap at 16384 bytes anyway).

Yes. As you can see there is an open issue marker here. If you wanted
to submit a PR, that would be great.

> Are encryption keys, finished value (tls-unique) and exporter secret

I'm planning to remove/rewrite this entire section, as I don't think
it's useful.

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

> is not a warning anymore?

Will see what I can find.

> EncryptedExtensions is marked optional in Figure 2, but not Figure 1?

It's not optional. I just got confused. Thanks.

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

> later the draft talks about exactly that case.

I agree.

> configuration hash (even if there is no existing one) could be useful.

Agreed. Will see what I can do.

> > 6.2.3. (Zero-RTT Exchange)

Pilot error.

> How would the server know when 0-RTT data ended, so it could send its

Is there a reason it needs to know? It needs to be able to distinguish
the 0-RTT from the 1-RTT data, but the Finished allows that.

> a security analysis for leaving this binding out?

Can you say more about what you mean here?

> client or (current) server exchange key).

Will see what I can do.

> Missing encrypted_extensions (it is a handshake message, right)?

Yeah, pilot error.

> The non-match case gives HelloRetryRequest, not ServerHello, right?

Yes.

> already require extensions for successful handshake.

I agree. We should mandate these.

> session_id_len, since it comes after server version.

I'm sold.

> use that to designate PRF hash.

I think we only need the minimum information, so maybe we could skip
these...

> about the selected_group check).

Yes, I can fix this.

> s/use for/add to/ in description of selected_group?

Thanks. Yes.

> and SH/SKS? I expect there be clients that don't check, no matter if it

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?

> supported_groups is 10, right?

Thanks, yes, I'll bring this in.

> free values to temporary squat on for extensions that aren't stable

I agree. Suggest you propose this as a PR.

> EncryptedExtensions, not just SH or HRR.

I wonder if we should relax these.

> - renegotiation_info: The renego bug is fixed anyway.

Agreed.

> that clear. This is further complicated by the fact that PSK can also

Yes, I haven't quite worked this out.

> Reference to "error alerts". Should that be "fatal alerts"?

Yes, thanks.

> authentication like TLS-EXPORTER or TLS-UNIQUE.

We may be beyond that point.

> section how it is actually used).

I think there is still a desire to have anonymous DH cipher suites.

> 6.3.2. 6.3.4 looks relevant, 6.3.2. doesn't look so.

I'll clean these up.

> backward compatiblity special cases from here.

Agreed. Just waiting for the chairs to declare consensus on that :)

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

> signature groups (signature groups when CFRG signatures become

Yep. I think the drafts are now stable for this.

> is currently blocked by different lengths of the length field).

Yes, that looks like it would work. Will try that

> curve (altough most curves use X9.62).

Will see what I can do. Suggested tet would help.

> (if so, ec_point_formats could be deprecated).

Yes, it should.

> of the native point format (32/56 octets) as if it was uncompressed.

That sounds like a good fit then.

> Client SHOULD offer at most two PSK identities (one for DH-PSK,

My sense was just to offer a pile of identities, since they're
untyped anyway.

> previous versions has been deprecated.

Willdo.

> s/MUST not/MUST NOT/ in description of early_data with client auth?

Ack.

> 0-RTT data with 1-RTT auth (for reasons mentioned earlier in the draft).

It is. It's also important for some applications.

> waiting would obviously deadlock)?

I don't believe that the server has to wait for the end of 0-RTT
data before it sends the ServerHello. What is necessary is to
be able to skip ahead through the handshake messages that you
can't read (if you reject).

> analysis showing this unnecressary)?

There are two cases here:

1. The server accepts the 0-RTT, in which case they are bound in
   the usual way.
2. The server rejects the 0-RTT in which case they aren't bound
   but also no data from them is used (though the fact of rejection
   is bound).

We are working on analyzing this now.

> server_random isn't available.

Yeah, it would be 0.

> Regarding finished, isn't Finished in second flight? Or is this another

The client's Finished is in the second flight. Can you clarify this
question.

> failure (there are multiple causes of server failing to compute keys or

Can you say more about this?

> configurations seemingly not being usable with PSK)?

I will have a proposal to fix this which I plan to send shortly.

> Also, the record protection used for early handshake messages should be

Can you expand on that?

> Tying the latter to client offered ciphersuites is probably not wanted.

Yeah, I think we should signal this separately.

> that it MUST be the last message in record it is in?

Thanks. Yes.

> Some of the figures have this as mandatory, some optional. Which is it?

Mandatory. Pilot error.

> Yeah, would be good to have explicit list of what goes to SH, and what

Yes.

> messages (esp. status_request{,_v2} and signed_certificate_timestamp).

Good point.

> then key to its fallback default).

Yep.

> seems better designed than RFC5081).

Ack.

> exchange algorithms. (Unless some key exchange that uses non-signing

Yeah, this is just old text.

> are abound (also, just 32-bit field that only goes up to 2106 or so)?

Here's my argument for explicit time:
We might in the future want to allow some kind of offline signing
(potentially, as Hugo has suggested, with a special bit in the
certificate). In that case, it would be really nice to have
an absolute expiration time for obvious reasons.

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

> Also, Could be useful for client to know what ciphers it can use for

This is a possibility, but I was more thinking that they would reuse
the same ones as were negotiated here. More on this shortly.

> Should PRF hash designation be added in order to avoid attacks from

Could you say more about this?

> I think note about checking signature algorithm against ciphersuite

This seems to interact with the a la carte discussion.

> Also, with regards to complications of DSA, just dump it? :-)

I'm fine with that if the chairs declare consensus on it.

> Doesn't CertificateRequest override algorithms anyway (and CR isn't an

Sorry, I'm not clear on what text you are sad about.

> Again, could use RFC7250 instead of RFC5081 as an example?

Yes.

> Similar problems as in DSA for server auth. And missing identifier

Sorry, can you expand on this.

> is not performed), it can't resume the session?

Good point. This seems like a silly restriction, so let's remove it.

> Those are functions that take in octet strings and output octet strings

Now that those drafts are stable will see if I can incorporate.

> s/DSA/ECDSA/ in seeding? And shouldn't k be determinstically generated?

Thanks for the suggestions. Will edit.

> > E.1.1. (Authentication and Key Exchange)

I plan to rewrite all of E.

> - Signing value from TLS-EXPORTER?

I think we should generate an explicit TLS-channel-binding output
and recommend people use that.

Thanks again,
-Ekr

On Wed, Jul 15, 2015 at 7:15 AM, Ilari Liusvaara <
[email-masked]> wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 16 Jul 2015 18:09:38 +0300

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)?

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

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

> > client or (current) server exchange key).

Well, this was more me being interested on how such attack would
work.
 
> > session_id_len, since it comes after server version.
 
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).

> the server should be picking the same parameters as before, no?

Unless there is attacker interfering...

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

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

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

> It was just to make clear that people shouldn't be adopting this for older

Should it be rephrased in terms of MUST NOT offer unless offering at least
TLS 1.2 or something like that?
 
> 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.

> My sense was just to offer a pile of identities, since they're

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.

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

> The client's Finished is in the second flight. Can you clarify this

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? 

> 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

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

> but why server auth, since once you have the configuration, you

Configs can do both server auth (which can be quite dangerous) and 0-RTT,
which is much less so.
 
> 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).

> This seems to interact with the a la carte discussion.

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

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

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

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

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

> 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

---

From: Hubert Kario <[email-masked]>
Date: Fri, 24 Jul 2015 17:22:08 +0200

> CertificateVerify, as it is just one digital signature in both).

Server Key Exchange for DHE, ADH, SRP, etc. not to mention TLS1.1 vs TLS1.2 

it's not uncommon to have different parsers for "same" message type

> for 0RTT transmission for that server?

And how does the client know that the algorithms came from the server. We 
should have a "client MUST wait for the full handshake to finish before 
recording this information" or we will have a very nice cipher downgrade. Just 
having it signed is likely not a good idea, as they may depend on ciphersuites 
advertised by client.

> small number) valid DSA SSL certs in the entiere public Internet.

that scan uses Mozilla trust roots and reports only trusted servers (to weed 
out unmaintained ones out), Microsoft list is a bit bigger

-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic