Subject: Re: [TLS] A la carte handshake negotiation

From: Dave Garrett <[email-masked]>
Date: Fri, 12 Jun 2015 21:45:13 -0400

Based on the discussions today, I've significantly revised the text of this proposal. This new draft goes into more detail for the PSK & anon cipher suites.

Of note, I've added a table to state what's available to negotiate with what. It's longer than it should be because both DHE_PSK and DH_anon should be dropped from there, but for now I've included them because ECDHE_PSK and ECDH_anon AEAD cipher suites have yet to be standardized. There's expired drafts for these and if PSK and anon are to be considered fully compatible with TLS 1.3, then these really should be defined. Merging them together into one I-D for AEAD ECDHE cipher suite assignments seems like the simplest route.

I'd also rather plain (symmetric-only) PSK be relegated to its own specifications and not included here, but I've included it in the table for now. ECDHE_PSK should ideally be the only supported PSK handshake. Plain PSK has no FS and it was generally agreed that TLS 1.3+ should be FS only.

New draft text:
https://github.com/davegarrett/tls13-spec/blob/alacarte/draft-ietf-tls-tls13.md#cipher-suites
Diff with master:
https://github.com/tlswg/tls13-spec/compare/master...davegarrett:alacarte

I think there might've been some discussion on this list in the past about potentially adding PSK to the SignatureAlgorithm enum for the "signature_algorithms" extension. This could obsolete all ECDHE_PSK and DHE_PSK cipher suites and allow PSK negotiation via normal ECDHE_ECDSA cipher suites and the extension. I'm not sure if this would be desired or not. I'm not proposing this currently, but I'm not against also doing this, though.

To reiterate from the anon discussion, the "signature_algorithms" extension already defines `anonymous(0)` and has an explicit prohibition on it ever being included. Obsoleting ECDH_anon and DH_anon and switching to this extension for negotiation would require either hacking in a second anonymous value to replace it (bad idea, IMO) or changing the extension spec to allow the existing value, which might break things expecting otherwise. Personally, I think anon should have its own cipher suite and not be negotiated via the signatures extension, as it is not a valid option for normal use-cases. (paranoid exploit worry: a bad implementation could muck up extension handling and negotiate anon when it shouldn't; safer to just keep it separate) Arguably, PSK isn't a valid option most of the time either, but it can't be negotiated without a pre-shared key actually being pre-shared, so using the extension for it might be viable. If ECDH_anon suites are defined, anon will be able to negotiate DHE/ECDHE via the "supported_groups" extension, so it would only be one anon suite per symmetric cipher.

Also note that non-standards-track ciphers are still listed in there, but may be dropped prior to merge. Promoting ECDHE AES-CCM from informational to standards track would be a good idea if we only want to include standards track ciphers here. AES-OCB will be added whenever its draft has a temporary codepoint to include.

Dave

---

From: Hubert Kario <[email-masked]>
Date: Mon, 15 Jun 2015 12:10:39 +0200

On Friday 12 June 2015 21:45:13 Dave Garrett wrote:
> Based on the discussions today, I've significantly revised the text of this
> proposal. This new draft goes into more detail for the PSK & anon cipher
> suites.
> 
> Of note, I've added a table to state what's available to negotiate with
> what. It's longer than it should be because both DHE_PSK and DH_anon should
> be dropped from there, but for now I've included them because ECDHE_PSK and
> ECDH_anon AEAD cipher suites have yet to be standardized. There's expired
> drafts for these and if PSK and anon are to be considered fully compatible
> with TLS 1.3, then these really should be defined. Merging them together
> into one I-D for AEAD ECDHE cipher suite assignments seems like the
> simplest route.
> 
> I'd also rather plain (symmetric-only) PSK be relegated to its own
> specifications and not included here, but I've included it in the table for
> now. ECDHE_PSK should ideally be the only supported PSK handshake. Plain
> PSK has no FS and it was generally agreed that TLS 1.3+ should be FS only.
> 
> New draft text:
> https://github.com/davegarrett/tls13-spec/blob/alacarte/draft-ietf-tls-tls13
> .md#cipher-suites Diff with master:

How will the client know which parser it should use to deserialize the Server 
Key Exchange?

Especially when we're close to having DHE, ECDHE, DHE+PSK (and DHE+PSK+RSA?), 
ECDHE+PSK (and ECDHE+PSK+ECDSA, ECDHE+PSK+ECDSA?), ADH and AECDH in a single 
ciphersuite...

Especially with the case of overloading the ECDHE to handle the ECDH_anon, it 
makes it possible that many implementations will reintroduce state machine 
bugs...
-- 
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

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 15 Jun 2015 16:23:53 +0300

> makes it possible that many implementations will reintroduce state machine 

Well, the server key exchange message is presumably the same for all GDHE
key exchanges, so one parser could parse those all (and pure-PSK would be
separate, which doesn't even have server key exchange).

However, if we were serious about eliminating state machine bugs (and TLS
1.3 state machine is totally different from TLS 1.2), we would eliminate
all optional messages (different from context-sensitive messages, like
Server key exchange message), and then eliminate handshake message types
(except for those which have to have type numbers for backward
compatiblity).

That way, any state machine bugs just cause handshake failures, not
security failures.

Regarding the PSK integration work EKR has been doing in the WIP branch:

1) Doesn't support identity hints. Now, these might be something nobody
uses and can be deprecated.

2) GDHE_PSK ciphers can't seemingly be safely resumed: Because resumption
is PSK, it eats the PSK slot, not leaving space for the primary identity.

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 15 Jun 2015 06:34:58 -0700

> uses and can be deprecated.

My sense was that it was sufficiently rare that we could deprecate it.
It's a bad match for the state machine.

> is PSK, it eats the PSK slot, not leaving space for the primary identity.

And your concern here is that you might want to resume GDHE_PSK as ordinary
PSK for performance reasons? If this seems really important, we could
presumably
have multiple PSK slots.

-Ekr

---

From: Hubert Kario <[email-masked]>
Date: Mon, 15 Jun 2015 15:36:44 +0200

On Monday 15 June 2015 16:23:53 Ilari Liusvaara wrote:
> > > https://github.com/davegarrett/tls13-spec/blob/alacarte/draft-ietf-tls-t
> > > ls13 .md#cipher-suites Diff with master:
> > How will the client know which parser it should use to deserialize the
> > Server Key Exchange?
> > 
> > Especially when we're close to having DHE, ECDHE, DHE+PSK (and
> > DHE+PSK+RSA?), ECDHE+PSK (and ECDHE+PSK+ECDSA, ECDHE+PSK+ECDSA?), ADH and
> > AECDH in a single ciphersuite...
> > 
> > Especially with the case of overloading the ECDHE to handle the ECDH_anon,
> > it makes it possible that many implementations will reintroduce state
> > machine bugs...
> 
> key exchanges, so one parser could parse those all

there's still the difference between signed vs not-signed

> (and pure-PSK would be

pure PSK is outside TLSv1.3 as it doesn't provide PFS, ECDHE-PSK and DHE-PSK 
though doesn't use signature on server key share

> (except for those which have to have type numbers for backward

there's a difference between having messages which are optional from protocol 
standpoint but are mandatory for given ciphersuite and messages which are 
optional always

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 15 Jun 2015 16:50:23 +0300

> there's still the difference between signed vs not-signed

The signature or not comes much later than key exchange message (TLS 1.2 had
those in the same message, TLS 1.3 does not).

> though doesn't use signature on server key share

Well, none of the key exchanges planned for TLS 1.3 have signature in server
key share (signature is its own message if it appears).
 
> standpoint but are mandatory for given ciphersuite and messages which are 

Well, the former are what I called "context-sensitive". And presence or
absence of those can be inferred from the past handshake.

-Ilari

---

From: Hubert Kario <[email-masked]>
Date: Mon, 15 Jun 2015 16:30:16 +0200

On Monday 15 June 2015 16:50:23 Ilari Liusvaara wrote:
> > there's a difference between having messages which are optional from
> > protocol standpoint but are mandatory for given ciphersuite and messages
> > which are optional always
> 

yes, and I'm saying we should be careful not to introduce ones which can not 
be inferred from previous messages

putting ECDH_anon or ECDHE_PSK behind ECDHE_ECDSA_* ciphersuites makes this 
likely
-- 
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

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 15 Jun 2015 18:21:45 +0300

> putting ECDH_anon or ECDHE_PSK behind ECDHE_ECDSA_* ciphersuites makes this 

Unfortunately, things get nasty when considering extensions that introduce
new handshake messages. Especially if you have multiple such things trying
to put messages in the same "slot":

Scanning TLS registeries and relevant RFCs, I found 7:

client_certificate_url(2) uses certificate_url(21)

This extension is somewhat dangerous.

status_request(5) uses certificate_status(22)

Obsoleted by status_request_v2

user_mapping(6) uses supplemental_data(23)

Dunno about this.

client_authz(7) uses supplemental_data(23)

Infamous.

server_authz(8) -> supplemental_data(23)

Infamous.

status_request_v2(17) -> certificate_status(22)

This one looks to be in actual use.

SessionTicket TLS(35) -> NewSessionTicket(4)

Related to resumption in TLS 1.0-1.2

The slots these messages go is (apparently):

certificate_url: Replaces certificate
certificate_status: Immediately after certificate
supplemental_data: Immediately before certificate
NewSessionTicket: Immediately before server CCS.

-Ilari

---

From: Dave Garrett <[email-masked]>
Date: Mon, 15 Jun 2015 11:40:23 -0400

> putting ECDH_anon or ECDHE_PSK behind ECDHE_ECDSA_* ciphersuites makes this 

I do agree that there is a risk of implementations introducing bugs. It's a matter of which new system with the potential for bugs we think has a lesser risk in comparison to the combinatorial exploded mess we have now.

The compromise between the current line of discussion (ECDHE_ECDSA for everything) vs. what is currently in my proposal on GitHub (ECDHE_ECDSA | ECDHE_PSK | ECDH_anon) could be to only merge all the certificate authentication under ECDHE_ECDSA and merge PSK and anon under ECDHE_PSK. This would have certificate based suites and non-certificate based suites as fundamentally separate, but still notably reduce the number of suites that have to be worried about in the specs. (anon just becomes a special case of PSK)

Dave