Subject: [TLS] A la carte handshake negotiation

From: Dave Garrett <[email-masked]>
Date: Thu, 11 Jun 2015 15:58:21 -0400

Here is a branch with a rough draft of an a la carte handshake algorithm negotiation scheme for TLS 1.3, based on discussions on this list.

https://github.com/davegarrett/tls13-spec/compare/updateciphersuites...davegarrett:alacarte

TL:DR:
* Deprecate all suites with any of: DH, DHE, ECDH, RSA, DSS
* Deployments may continue to offer deprecated suites for TLS 1.0-1.2 negotiation.
* TLS 1.3 would only negotiate suites prefixed with ECDHE_ECDSA or ECDHE_PSK.
* TLS 1.3 implementations negotiate ECDHE/DHE & RSA/DSS/ECDSA solely via the "supported_groups" & "signature_algorithms" extensions.
* No change to bulk cipher negotiation.

To be clear, this would mean a connection could negotiate usage of a ECDHE_ECDSA suite and negotiate ECDHE+RSA. It doesn't say anything about DHE+ECDSA yet, but I think that combination is fine if negotiated.

Benefits:
1) Old DH(E) suites are replaced by a system which only negotiates strong FFDHE groups.
2) The combinatorial explosion of suites that need to be offered in a ClientHello is reduced.
3) Accidental interop failure due to a missing combination is avoided.
4) All TLS 1.3 implementations are expected to be able to handle ECC, but are not required to offer or negotiate it. (at least, here)
5) EdDSA can easily be added to the list as a variation of ECDSA without new suites.
6) No more confusing double negotiation of signature algorithms. Just extensions, instead of many suites and extensions.
7) The default usage of SHA1 for the "signature_algorithms" extension can be removed, as all TLS 1.3 clients would be required to send it.

The branch is a WIP to resume discussion on this topic. Probably needs some significant additional changes.

Dave

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 12 Jun 2015 11:31:53 +0300

> https://github.com/davegarrett/tls13-spec/compare/updateciphersuites...davegarrett:alacarte

Interesting...
 
> To be clear, this would mean a connection could negotiate usage of a ECDHE_ECDSA suite and negotiate ECDHE+RSA. It doesn't say anything about DHE+ECDSA yet, but I think that combination is fine if…
 
AFAICT, In TLS 1.2, DHE+ECDSA is legal, if client signals support for
both DHE (via ciphersuites) and ECDSA (via (possibly implicit default)
signature_algorithms).

(In TLS 1.1 and earlier, there is seemingly no way to use DHE+ECDSA)

The main pitfall I see for unifying DH is that ECDHE nested length
byte (which is insufficient for DHE). One would have to either expand
that to 2 bytes, or better yet, dump it entierely (as it is seemingly
useless).

> 7) The default usage of SHA1 for the "signature_algorithms" extension can be removed, as all TLS 1.3 clients would be required to send it.

Also, there is no "double negotiation" in TLS 1.2 either. TLS 1.2 is
quite clear about interaction of signature algorithms in ciphersuites
and explicit signature negotiation (explicit negotiation always takes
percedence).

Of course, I wouldn't be surprised if there was fair bit of software
that got those rules wrong...

-Ilari

---

From: Hubert Kario <[email-masked]>
Date: Fri, 12 Jun 2015 16:51:35 +0200

On Thursday 11 June 2015 15:58:21 Dave Garrett wrote:
> Here is a branch with a rough draft of an a la carte handshake algorithm
> negotiation scheme for TLS 1.3, based on discussions on this list.
> 
> * TLS 1.3 implementations negotiate ECDHE/DHE &
> RSA/DSS/ECDSA solely via the "supported_groups" & "signature_algorithms"
> extensions. 
> To be clear, this would mean a connection could negotiate usage of a
> ECDHE_ECDSA suite and negotiate ECDHE+RSA. It doesn't say anything about
> DHE+ECDSA yet, but I think that combination is fine if negotiated.

that would require definition of
TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256
TLS_ECDHE_PSK_WITH_256_GCM_SHA384

to keep parity with already existing TLS_DHE_PSK_*

-- 
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: Viktor Dukhovni <[email-masked]>
Date: Fri, 12 Jun 2015 14:58:20 +0000

> * TLS 1.3 would only negotiate suites prefixed with ECDHE_ECDSA or ECDHE_PSK.

Where are anonymous (ADH and AECDH) suites?

> * TLS 1.3 implementations negotiate ECDHE/DHE & RSA/DSS/ECDSA solely via
> the "supported_groups" & "signature_algorithms" extensions.

Why include DSS?  It seems rather obsolete, and little used, at this
time.

-- 
	Viktor.

---

From: Dave Garrett <[email-masked]>
Date: Fri, 12 Jun 2015 11:14:47 -0400

> Where are anonymous (ADH and AECDH) suites?

Still in the spec. I currently have usage of ECDHE_ECDSA or ECDHE_PSK as a "SHOULD", with "MUST NOT" for the explicitly deprecated bits. Anon is effectively a "SHOULD NOT". I don't think we can have an absolute mandate for only certain prefixes with a "MUST", as that would exclude new ones in the future. (e.g. a post-quantum key exchange will likely want to be negotiated with a separate cipher suite)

> Why include DSS?  It seems rather obsolete, and little used, at this

It's in there because there's no reason to explicitly cut it out completely. This proposal gets rid of all of the DSS cipher suites, however the extension already has DSS/DSA in there. This shifts signature negotiation to the extension; it doesn't actually change the extension. (though, it's possible a change of some kind will be needed) Removing support entirely is outside of the scope of this proposed change. I'm not against restricting/prohibiting its use, if that's the consensus.

Dave

---

From: Dave Garrett <[email-masked]>
Date: Fri, 12 Jun 2015 11:20:15 -0400

> to keep parity with already existing TLS_DHE_PSK_*

Yes, all PSK would need ECDHE suites specified to be used with TLS 1.3+ under this proposal, as-is. I think that would in general already be desired for PSK use-cases.

Dave

---

From: Dave Garrett <[email-masked]>
Date: Fri, 12 Jun 2015 11:23:00 -0400

> and explicit signature negotiation (explicit negotiation always takes

One of the two takes precedence, yes, but there's still two.

> that got those rules wrong...

I'd be surprised if there wasn't. :/

Dave

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 12 Jun 2015 11:23:06 -0400

On Fri, Jun 12, 2015 at 11:20 AM, Dave Garrett <[email-masked]>
wrote:

> Yes, all PSK would need ECDHE suites specified to be used with TLS 1.3+
> under this proposal, as-is. I think that would in general already be
> desired for PSK use-cases.

Sorry, do you mean that you couldn't use PSK without a public key key
exchange?
If so that's not going to work.

-Ekr

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 12 Jun 2015 15:38:05 +0000

On Fri, Jun 12, 2015 at 11:14:47AM -0400, Dave Garrett wrote:

> Still in the spec. I currently have usage of ECDHE_ECDSA or ECDHE_PSK as
> a "SHOULD", with "MUST NOT" for the explicitly deprecated bits. Anon is
> effectively a "SHOULD NOT". I don't think we can have an absolute mandate
> for only certain prefixes with a "MUST", as that would exclude new ones
> in the future. (e.g. a post-quantum key exchange will likely want to be
> negotiated with a separate cipher suite)

Just to confirm, it will be possible to negotiate AECDH and ADH
key exchange ala carte, separately from the bulk cipher, right?

-- 
	Viktor.

---

From: Dave Garrett <[email-masked]>
Date: Fri, 12 Jun 2015 11:40:04 -0400

On Friday, June 12, 2015 11:23:06 am Eric Rescorla wrote:
> exchange? If so that's not going to work.

There's nothing explicitly prohibiting that in my proposal. TLS_DHE_PSK would need a TLS_ECDHE_PSK, but plain TLS_PSK is a separate issue. It's be effectively a "SHOULD NOT", though there was discussion of a separate application profile for IoT and the like which could say otherwise.

Dave

---

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

> key exchange ala carte, separately from the bulk cipher, right?

Sure, no reason why it couldn't be negotiated via the extension for anon. It's not addressed in my draft for this proposal, but that seems like it should be the case. Applying the same logic, only ECDH_anon would be valid as a suite for TLS 1.3+, but EC/FF would be negotiated via the extension.

Dave

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 12 Jun 2015 15:53:12 +0000

On Fri, Jun 12, 2015 at 11:45:38AM -0400, Dave Garrett wrote:

> Sure, no reason why it couldn't be negotiated via the extension for anon.
> It's not addressed in my draft for this proposal, but that seems like it
> should be the case. Applying the same logic, only ECDH_anon would be valid
> as a suite for TLS 1.3+, but EC/FF would be negotiated via the extension.

That would be great.  Please add it to the draft if/when possible.
Right now, there are many "missing" combinations of AECDH with more
modern bulk ciphers.  If AECDH/ADH key exchange becomes ala carte,
then the problem is solved (for TLS 1.3).

-- 
	Viktor.

---

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

> * TLS 1.3 would only negotiate suites prefixed with ECDHE_ECDSA or ECDHE_PSK.

The wording in my summary appears to have been not precise enough.

Quoting what's in the full draft, at the moment:
==============================
In TLS 1.3, the semantics of the handshake portion of cipher suites SHALL be interpreted as indicative of the newest standardized algorithm which is supported, rather than indicative of an exact combination which is offered. All implementations of this specification SHOULD only negotiate the usage of cipher suites with a handshake portion of "ECDHE_ECDSA" or "ECDHE_PSK". Implementations MUST NOT negotiate the usage of cipher suites with a "KEA" of "DHE", "DH", or "ECDH". Implementations MUST NOT negotiate the usage of cipher suites with a "SIGN" of "RSA" or "DSS", including cipher suites which do not have separate "KEA" and "SIGN" components.
==============================

"KEA", "SIGN", and "handshake portion" are defined in the same section as part of a generalized description of the de facto suite naming convention. This draft is based on PR #180, which doesn't change any spec/policy; just updates the section. A link to the current draft of this in full, rather than just the changes:

https://github.com/davegarrett/tls13-spec/blob/alacarte/draft-ietf-tls-tls13.md#cipher-suites

So, to be more clear (repeating what I clarified in replies to specific questions):

in cipher suites:
ECDHE_ECDSA or ECDHE_PSK  ->  SHOULD (not proposing a MUST, here)
DHE, DH, ECDH, RSA, DSS  ->  MUST NOT

this does not preclude the allowance of:
plain PSK
anon
anything fundamentally new (e.g. post-quantum key exchange)
something else obscure, but not generally recommended

The goal here is to collapse the zoo of older suites under a small set of valid ones for TLS 1.3, and use the existing extensions to negotiate those capabilities instead. Actually dropping capabilities is not part of this, so even if doing so might be warranted, it would be part of another changeset and not this.

As separately replied to Viktor, yes, the anon issue needs updating in the draft. It might even be warranted to use only DH_anon suites instead of ECDH_anon due to its more widespread use. This would allow usage of ECC without having to specify any new ECDH_anon suites for those lacking them but already having DH_anon suites.

Dave

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 12 Jun 2015 16:22:37 +0000

On Fri, Jun 12, 2015 at 12:13:02PM -0400, Dave Garrett wrote:

> It might even be warranted to use only DH_anon suites instead
> of ECDH_anon due to its more widespread use. This would allow usage of
> ECC without having to specify any new ECDH_anon suites for those lacking
> them but already having DH_anon suites.

I'm afraid I don't understand the above.  Also AECDH (ECDH_anon)
is not particularly rare:

    Jun 12 15:48:16 mournblade postfix/smtpd[25717]: Anonymous TLS connection established from xmpp.openssl.org[194.97.150.230]: TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)
    Jun 12 15:49:59 mournblade postfix/smtpd[10257]: Anonymous TLS connection established from xmpp.openssl.org[194.97.150.230]: TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)
    Jun 12 15:53:13 mournblade postfix/smtp[4626]: Anonymous TLS connection established to mail.ietf.org[4.31.198.44]:25: TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)
    Jun 12 15:53:17 mournblade postfix/smtpd[29043]: Anonymous TLS connection established from mail.ietf.org[4.31.198.44]: TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)
    Jun 12 16:01:15 mournblade postfix/smtpd[7342]: Anonymous TLS connection established from xmpp.openssl.org[194.97.150.230]: TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)
    Jun 12 16:05:29 mournblade postfix/smtpd[21581]: Anonymous TLS connection established from xmpp.openssl.org[194.97.150.230]: TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)
    Jun 12 16:07:14 mournblade postfix/smtpd[23383]: Anonymous TLS connection established from xmpp.openssl.org[194.97.150.230]: TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)
    Jun 12 16:08:56 mournblade postfix/smtpd[23383]: Anonymous TLS connection established from xmpp.openssl.org[194.97.150.230]: TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)
    Jun 12 16:09:47 mournblade postfix/smtpd[23383]: Anonymous TLS connection established from xmpp.openssl.org[194.97.150.230]: TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)
    Jun 12 16:13:08 mournblade postfix/smtpd[27271]: Anonymous TLS connection established from mail.ietf.org[4.31.198.44]: TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)

-- 
	Viktor.

---

From: Dave Garrett <[email-masked]>
Date: Fri, 12 Jun 2015 12:36:17 -0400

>     Jun 12 15:48:16 mournblade postfix/smtpd[25717]: Anonymous TLS connection established from xmpp.openssl.org[194.97.150.230]: TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)

Your quote is usage of:
TLS_ECDH_anon_WITH_AES_256_CBC_SHA

AES CBC already cannot be used with TLS 1.3+, as it now requires AEAD ciphers only.

TLS_DH_anon_WITH_AES_256_GCM_SHA384 is in:
https://tools.ietf.org/html/rfc5288

TLS_ECDH_anon_WITH_AES_256_GCM_SHA384 is in this expired draft:
https://tools.ietf.org/html/draft-williams-tls-anon-ecdh-modern-cipher-01

The current proposal requires all suites for TLS 1.3+ to be the ECC variants, which is not currently doable for anon AES-GCM. What I'm saying is that we could use "DH_anon" suites instead of "ECDH_anon" suites in this scheme. Just properly publishing a "ECDH_anon" RFC would be preferable, however.

Dave

---

From: Aaron Zauner <[email-masked]>
Date: Fri, 12 Jun 2015 18:43:21 +0200

> https://github.com/davegarrett/tls13-spec/compare/updateciphersuites...davegarrett:alacarte

I'm supportive in general, let's see how this turns out. Not surprising
though will be that I noticed additional CCM cipher-suites, as I
currently have a draft on OCB mode I'm not really supportive of that.
There should be a block-cipher mode that also offers considerable
performance for non-AESNI architectures - CCM was introduced because of
patents on OCB, we seem to have resolved this issue by now. At least for
TLS.

DSS should be dropped. And I figure that a PSK handshake (TLS_PSK_*)
will be required by the embedded/IoT world, as noted by others before.

Aaron

---

From: Dave Garrett <[email-masked]>
Date: Fri, 12 Jun 2015 12:46:35 -0400

To preemptively answer a simple alternate idea for anon negotiation, no, it can't be negotiated via the extension. It needs its own cipher suites.

TLS 1.2 spec section 7.4.1.4.1: Signature Algorithms
https://tools.ietf.org/html/rfc5246#section-7.4.1.4.1
> The "anonymous" value is meaningless in this context but used in
> Section 7.4.3.  It MUST NOT appear in this extension.

As this extension must be sent from clients to servers of unknown versions, changing this requirement is probably a bad idea.

Dave

---

From: Aaron Zauner <[email-masked]>
Date: Fri, 12 Jun 2015 18:50:20 +0200

> patents on OCB, we seem to have resolved this issue by now. At least for

..also why include both the cipher-suite with the 8-bit auth. tag and
the 16-bit tag? I found this particularly confusing with the CCM draft,
which is why I decided not to go for two different tag sizes.

Aaron

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 12 Jun 2015 16:55:59 +0000

> AES CBC already cannot be used with TLS 1.3+, as it now requires AEAD ciphers only.

Indeed, there are at present no ciphersuite codepoints for AECDH
with AEAD.  That's why I'd like to see improvement in this space.
If the bulk cipher were negotiated separately, I'd expect that I'd
get the missing combinations "for free".

    $ openssl version
    OpenSSL 1.0.2a-dev xx XXX xxxx

    $ openssl ciphers -v AESGCM+kEDH
    DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=DSS  Enc=AESGCM(256) Mac=AEAD
    DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(256) Mac=AEAD
    ADH-AES256-GCM-SHA384   TLSv1.2 Kx=DH       Au=None Enc=AESGCM(256) Mac=AEAD
    DHE-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH       Au=DSS  Enc=AESGCM(128) Mac=AEAD
    DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(128) Mac=AEAD
    ADH-AES128-GCM-SHA256   TLSv1.2 Kx=DH       Au=None Enc=AESGCM(128) Mac=AEAD

    $ openssl ciphers -v AESGCM+kECDHE
    ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
    ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(256) Mac=AEAD
    ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(128) Mac=AEAD
    ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(128) Mac=AEAD

The DH AEAD ciphersuite set includes two DH_anon members.  For ECDH
AEAD there are none.

> https://tools.ietf.org/html/draft-williams-tls-anon-ecdh-modern-cipher-01

Yes, I asked Nico to help fill the gap.  I guess this did not go
very far.

> The current proposal requires all suites for TLS 1.3+ to be the ECC
> variants, which is not currently doable for anon AES-GCM. What I'm saying
> is that we could use "DH_anon" suites instead of "ECDH_anon" suites in
> this scheme. Just properly publishing a "ECDH_anon" RFC would be preferable,
> however.

I still don't understand preclude as a matter of principle negotiation
of ECDH_anon with AEAD if DH_anon with the same bulk cipher would
be allowed.  Once we have separate negotiation of the key exchange,
surely ECDH_anon can be one of the supported key exchange variants,
and then take advantage of all the available bulk ciphersuites.

Or does this proposal simply compress the client HELLO message,
but the server is still ultimately selecting the same all-in-one
ciphersuite (thus requiring Nico's new code points for ECDH_anon
with AEAD)?

-- 
	Viktor.

---

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

> patents on OCB, we seem to have resolved this issue by now. At least for

The only reason OCB isn't in this draft is because I left it out of PR #180 because it doesn't have any codepoints yet. (again, this draft proposal uses that as a base)
https://github.com/tlswg/tls13-spec/pull/180/files

As soon as it progresses to WG adoption and codepoint assignment, then it certainly belongs in the TLS 1.3 draft.

As far as I'm aware, even non-MTI suites listed in the spec need to be normative references and thus must be finalized before the full TLS 1.3 spec can be published. Just referencing the existence of others, which might be desired for the non-standards-track ones might be ok as informative, but I'm not sure on the specifics of the requirements there. Eric had said that we may want only ST listed at all, but that means that ECDHE CCM would be out but DHE CCM would be in, which is a problem. (it should probably just be promoted to ST) PR #180 just lists everything, at the moment.

> which is why I decided not to go for two different tag sizes.

They exist, so they're included. If the WG can get consensus to mandate a one-true-tag-size, then we can prohibit the other for TLS 1.3+, but I have no opinion on the topic.

Dave

---

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

> and then take advantage of all the available bulk ciphersuites.

EC/FF may be negotiated separately, but a suite still needs to be selected. Anon cannot be negotiated via an ECDHE_ECDSA suite, as the signatures extension explicitly prohibits proposing anon alongside actual signatures. One way or another, anon needs its own suites to be used.

> ciphersuite (thus requiring Nico's new code points for ECDH_anon

The server still needs to select a suite. If it selects an ECDHE_ECDSA suite, then it can negotiate EC/FF and RSA,DSA,ECDSA with extensions. It cannot negotiate anon. To do so would require either an ECDH_anon or DH_anon suite be negotiated. Yes, the preferred route is to require Nico's ECDH_anon codepoints for AEAD ciphers. With an ECDH_anon suite, the groups extension can be used to negotiate EC/FF. What I was stating earlier is that we could theoretically do so with DH_anon if we wanted to, but I would much rather the ECDH_anon draft be resurrected and passed as it would avoid confusion and the appearance of contradiction.

Dave

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 12 Jun 2015 17:22:00 +0000

On Fri, Jun 12, 2015 at 01:09:26PM -0400, Dave Garrett wrote:

> EC/FF may be negotiated separately, but a suite still needs to be selected.
> Anon cannot be negotiated via an ECDHE_ECDSA suite, as the signatures
> extension explicitly prohibits proposing anon alongside actual signatures.
> One way or another, anon needs its own suites to be used.

The extension definition can presumably be updated in a way that
allows peers that support additional code-points to treat one of
those as being "anon".  Is the current definition really a serious
obstacle to solving the problem in a properly orthogonal way.

> The server still needs to select a suite. If it selects an ECDHE_ECDSA
> suite, then it can negotiate EC/FF and RSA,DSA,ECDSA with extensions. It
> cannot negotiate anon. To do so would require either an ECDH_anon or
> DH_anon suite be negotiated. Yes, the preferred route is to require Nico's
> ECDH_anon codepoints for AEAD ciphers. With an ECDH_anon suite, the groups
> extension can be used to negotiate EC/FF. What I was stating earlier is
> that we could theoretically do so with DH_anon if we wanted to, but I
> would much rather the ECDH_anon draft be resurrected and passed as it
> would avoid confusion and the appearance of contradiction.

So be it I guess.  I wish it were simpler...

-- 
	Viktor.

---

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

On Friday, June 12, 2015 01:22:00 pm Viktor Dukhovni wrote:
> obstacle to solving the problem in a properly orthogonal way[?]

Technically, the extension could be hacked to work like that by adding an `anonymous_real(4)` in addition to the existing `anonymous(0)`, but that feels like the wrong way to go about this. I generally agree that anon and authenticated should be kept separate, so I don't want to do that.

The whole point of this negotiation proposal is to use _existing_ extensions to do this negotiation, rather than overhaul everything. The groups extension is already being modified to add FFDH groups alongside ECDH curves, but modifying the signatures extension to do anon would be more than just an addition; it'd overrule the previous behavior.

The best route for integrating anon into this scheme for TLS 1.3+ really does seem to be to publish new ECDH_anon suites for ciphers that lack them and require those be used with EC/FF being negotiated via the extension. TLS 1.2 would benefit from adding them, anyway.

Dave

---

From: Dave Garrett <[email-masked]>
Date: Fri, 12 Jun 2015 14:37:57 -0400

> > AES CBC already cannot be used with TLS 1.3+, as it now requires AEAD ciphers only.
[...]
> Yes, I asked Nico to help fill the gap.  I guess this did not go
[...]
> > Just properly publishing a "ECDH_anon" RFC would be preferable,
> > however.

Resurrecting this draft seems like a good idea, regardless of TLS 1.3.

https://tools.ietf.org/id/draft-williams-tls-anon-ecdh-modern-cipher-01.html

It defines:
==============================
TLS_ECDH_anon_WITH_AES_128_GCM_SHA256
    This is anonymous key agreement with ephemeral ECDH keys, with AES-128 in GCM mode, and SHA256 as the hash function for the TLS PRF.
TLS_ECDH_anon_WITH_AES_128_CCM_SHA256
    This is anonymous key agreement with ephemeral ECDH keys, with AES-128 in CCM mode, and SHA256 as the hash function for the TLS PRF.
TLS_ECDH_anon_WITH_AES_256_GCM_SHA384
    This is anonymous key agreement with ephemeral ECDH keys, with AES-256 in GCM mode, and SHA384 as the hash function for the TLS PRF.
TLS_ECDH_anon_WITH_AES_256_CCM_SHA384
    This is anonymous key agreement with ephemeral ECDH keys, with AES-256 in CCM mode, and SHA384 as the hash function for the TLS PRF.
==============================

If we're to update this draft, I think we should really change the "ECDH" to "ECDHE" here. It would make specifying which suite prefixes are permitted a lot simpler and less prone to confusion, as the current naming is inconsistent. All ephemeral should have the 'E' on the end, regardless of how it's provided.

Also, adding new ECC anon versions for other ciphers in the same document, like ARIA-GCM [RFC6209] and CAMELLIA-GCM [RFC6367], might be warranted.

Dave

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 13 Jun 2015 13:24:34 +0300

> The current proposal requires all suites for TLS 1.3+ to be the ECC variants, which is not currently doable for anon AES-GCM. What I'm saying is that we could use "DH_anon" suites instead of "ECDH_…

Assembling the list of ciphersuites (with some renaming):

C02B	TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
C02C	TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
C0AC	TLS_ECDHE_ECDSA_WITH_AES_128_CCM_SHA256
C0AD	TLS_ECDHE_ECDSA_WITH_AES_256_CCM_SHA256
C0AE	TLS_ECDHE_ECDSA_WITH_AES_128_CCM8_SHA256
C0AF	TLS_ECDHE_ECDSA_WITH_AES_256_CCM8_SHA256
C05C	TLS_ECDHE_ECDSA_WITH_ARIA_128_GCM_SHA256
C05D	TLS_ECDHE_ECDSA_WITH_ARIA_256_GCM_SHA384
C086	TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_GCM_SHA256
C087	TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_GCM_SHA384
CCA2?	TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
????	TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256
????	TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384
????	TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256
????	TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA256
????	TLS_ECDHE_PSK_WITH_AES_128_CCM8_SHA256
????	TLS_ECDHE_PSK_WITH_AES_256_CCM8_SHA256
????	TLS_ECDHE_PSK_WITH_ARIA_128_GCM_SHA256
????	TLS_ECDHE_PSK_WITH_ARIA_256_GCM_SHA384
????	TLS_ECDHE_PSK_WITH_CAMELLIA_128_GCM_SHA256
????	TLS_ECDHE_PSK_WITH_CAMELLIA_256_GCM_SHA384
CCA6?	TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256
????	TLS_ECDHE_anon_WITH_AES_128_GCM_SHA256
????	TLS_ECDHE_anon_WITH_AES_256_GCM_SHA384
????	TLS_ECDHE_anon_WITH_AES_128_CCM_SHA256
????	TLS_ECDHE_anon_WITH_AES_256_CCM_SHA256
????	TLS_ECDHE_anon_WITH_AES_128_CCM8_SHA256
????	TLS_ECDHE_anon_WITH_AES_256_CCM8_SHA256
????	TLS_ECDHE_anon_WITH_ARIA_128_GCM_SHA256
????	TLS_ECDHE_anon_WITH_ARIA_256_GCM_SHA384
????	TLS_ECDHE_anon_WITH_CAMELLIA_128_GCM_SHA256
????	TLS_ECDHE_anon_WITH_CAMELLIA_256_GCM_SHA384
????	TLS_ECDHE_anon_WITH_CHACHA20_POLY1305_SHA256
00A8	TLS_PSK_WITH_AES_128_GCM_SHA256
00A9	TLS_PSK_WITH_AES_256_GCM_SHA384
C0A4	TLS_PSK_WITH_AES_128_CCM_SHA256
C0A5	TLS_PSK_WITH_AES_256_CCM_SHA256
C0A8	TLS_PSK_WITH_AES_128_CCM8_SHA256
C0A9	TLS_PSK_WITH_AES_256_CCM8_SHA256
C06A	TLS_PSK_WITH_ARIA_128_GCM_SHA256
C06B	TLS_PSK_WITH_ARIA_256_GCM_SHA384
C08E	TLS_PSK_WITH_CAMELLIA_128_GCM_SHA256
C08F	TLS_PSK_WITH_CAMELLIA_256_GCM_SHA384
CCA5?	TLS_PSK_WITH_CHACHA20_POLY1305_SHA256
	
yyyy => Assigned ciphersuite ID	(20)
yyyy? => Proposed ciphersuite ID in I-D (3)
???? => No current I-D (21)

Looking at how this would look with orthogoal negotiation:

17 codepoints:
TLS13_KEX_GDHE_CERT
TLS13_KEX_GDHE_PSK
TLS13_KEX_GDHE_anon
TLS13_KEX_PSK
TLS13_PROT_AES_128_GCM
TLS13_PROT_AES_256_GCM
TLS13_PROT_AES_128_CCM
TLS13_PROT_AES_256_CCM
TLS13_PROT_AES_128_CCM8
TLS13_PROT_AES_256_CCM8
TLS13_PROT_ARIA_128_GCM
TLS13_PROT_ARIA_256_GCM
TLS13_PROT_CAMELLIA_128_GCM
TLS13_PROT_CAMELLIA_256_GCM
TLS13_PROT_CHACHA20_POLY1305
TLS13_PRF_SHA256
TLS13_PRF_SHA384

(select one KEX, one PROT and one PRF)

- Would be much easier if SHA-2 ever gets broken[1]...
- All TLS stacks should already separate key exchange, record protection
  and PRF[2].
- GDHE is the unfication of DHE and ECDHE (some other things might unify
  with it as well[3]).
- I didn't separate GDHE from cert/psk/anon, because I can't get clean
  split there[4], and unclean splits are asking for trouble.
- Certificate part (other than existence thereof) in TLS 1.2 is already
  ignored in ServerHello (and only sets overrideable defaults in
  ClientHello[5]).

[1] Nominally, security rests on PRF-hash being CR (but exploiting
collision doesn't look to be easy). So if SHA-256 ever gets broken CR,
one needs to replace it (which would be 32 new ciphersuites, instead
of just one PRF, and if whole SHA-2 goes, need 44 new ones, instead
of just 2).

[2] There are tables of ciphersuite properties (what key exchange, what
record protection, what PRF (unless PRF is hardcoded to SHA256)).

[3] Including one or two potential PQ key exchanges.

[4] The problem is that PSK itself is quite different from GDHE_PSK,
which is quite different from GDHE_CERT.

[5] If signature_algorithms is sent, then similar ignore also applies
to ClientHello cipher list.

-Ilari

---

From: Dave Garrett <[email-masked]>
Date: Sat, 13 Jun 2015 12:07:26 -0400

> ????	TLS_ECDHE_anon_WITH_CAMELLIA_256_GCM_SHA384

I think a single new "AEAD ECDHE PSK and anonymous cipher suites for TLS" I-D could cover the above.

I found two expired drafts that this would be replacing, in addition to new definitions:
https://tools.ietf.org/html/draft-williams-tls-anon-ecdh-modern-cipher-01 (AES-GCM&CCM anon)
https://tools.ietf.org/html/draft-schmertmann-dice-ccm-psk-pfs-01 (AES-CCM PSK)

Alternatively, if we just want to focus on standards track, a new I-D for just ECDHE AES AEAD cipher suites could cover:

TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256
TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384
TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256
TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA256
TLS_ECDHE_PSK_WITH_AES_128_CCM8_SHA256
TLS_ECDHE_PSK_WITH_AES_256_CCM8_SHA256
TLS_ECDHE_anon_WITH_AES_128_GCM_SHA256
TLS_ECDHE_anon_WITH_AES_256_GCM_SHA384
TLS_ECDHE_anon_WITH_AES_128_CCM_SHA256
TLS_ECDHE_anon_WITH_AES_256_CCM_SHA256
TLS_ECDHE_anon_WITH_AES_128_CCM8_SHA256
TLS_ECDHE_anon_WITH_AES_256_CCM8_SHA256

Plus, it could promote the RFC 7251 suites to standards track:

TLS_ECDHE_ECDSA_WITH_AES_128_CCM = {0xC0,0xAC}
TLS_ECDHE_ECDSA_WITH_AES_256_CCM = {0xC0,0xAD}
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 = {0xC0,0xAE}
TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 = {0xC0,0xAF}

At the moment, CCM is in the odd situation where DHE CCM is standards track but ECDHE CCM is informational.

> ????	TLS_ECDHE_anon_WITH_CHACHA20_POLY1305_SHA256

This could just get added to the current ChaChaPoly draft.

Dave

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 13 Jun 2015 16:12:32 +0000

I think this is headed in the wrong direction.

We want to minimize the number of ciphers and cipher-suites, not allow for a mind-boggling combinatorial explosion that will cripple interop.

---

From: Dave Garrett <[email-masked]>
Date: Sat, 13 Jun 2015 12:30:03 -0400

> We want to minimize the number of ciphers and cipher-suites, not allow for a mind-boggling combinatorial explosion that will cripple interop.

It's mostly just the ECDHE AEAD PSK & anon suites that never got defined for one reason or another.

With this a la carte proposal, TLS 1.3 would only use ECDHE suites and be able to negotiate DHE or ECDHE using it. The number of suites would go down, overall; it'd just have these new ones for PSK & anon.

The normal RSA/ECDSA suites that would be needed would drop in quantity far more drastically.

The idea is to just move to all suites being to defined for just ECDHE_{ECDSA|PSK|anon} and drop all {DH|DHE|ECDH}_* and ECDHE_{RSA|DSS}.

Technically, we could allow DHE_anon & DHE_PSK to negotiate ECDHE or DHE via the extension, but we'd like to deprecate all the old DHE suites to avoid even the possibility of negotiating weak groups. It would also make the valid TLS 1.3+ suites all start with ECDHE (with the exception of plain PSK, if that has to be kept around).

Note that the list of AES AEAD suites could be pruned down notably if CCM8 was dropped in favor of CCM16 only (or vice versa).

Dave

---

From: David Benjamin <[email-masked]>
Date: Sat, 13 Jun 2015 18:28:06 +0000

On Thu, Jun 11, 2015 at 3:58 PM Dave Garrett <[email-masked]> wrote:

> 4) All TLS 1.3 implementations are expected to be able to handle ECC, but
> are not required to offer or negotiate it. (at least, here)
>

Are you sure this proposal completely achieves that? I believe, by using
ECDHE_ECDSA as the representative key exchange, this effectively requires
all clients to offer the ECDHE_ECDSA variant of every bulk cipher.

ECDSA is negotiable pre-TLS-1.2, so you can't rely on an ECDSA-less
signature_algorithms to disable things on TLS 1.1 servers (though hopefully
ECDSA deployments all speak 1.2). Plus, if I'm reading this code right,
OpenSSL didn't disable cipher suites based on signature_algorithms until
1.0.2. I haven't tested this, however. (It's hard to be sure of the
behavior. RSA+ECDSA deployments probably aren't that common. Those that
exist probably do custom things in callbacks, so who knows what they check.
The built-in mechanism is slightly odd.)

On the ECDHE side of things, OpenSSL 1.0.1 has two APIs for configuring
ECDHE groups. The saner one (SSL_CTX_set_tmp_ecdh) has you just pick a
group, and that seems to honor supported_curves fine. But there's
also SSL_CTX_set_tmp_ecdh_callback. That callback is called very late, so I
believe OpenSSL won't fall back to a different cipher suite. (OpenSSL will
also treat missing supported_curves as "pick anything", not "don't do ECC".)

At a glance, I wasn't able to find any popular server software that used
SSL_CTX_set_tmp_ecdh_callback (it's kind of a weird API...). Though
apparently Android's SSLServerSocket API does.

Personally, mandatory ECDHE seems just fine. Still, something to be aware
of. ECDSA might be more of a nuisance. At least as things stand currently,
Chrome does not offer ECDSA suites on Windows XP because the system
certificate verifier can't handle it.

In general, I wouldn't expect filtering out cipher suites based on
signature_algorithms/supported_curves to be a well-tested path in servers.
You could easily mess it up and never notice. It's partially redundant with
the cipher list and my unscientific impression is there's not much
variance. (I expect most everyone supports and uses P-256.)

Wouldn't it be simpler to just add a supported_aeads extension and make the
cipher suite list meaningless for 1.3? With all the obsolete ciphers gone,
most clients would probably only offer 2-3 of them. The interop risks of a
bad compatibility cipher suite list seem simple enough. Ensure that:

  {legacy cipher list} ∩ {all 1.3 combos} ⊆ {key ex.} × {sig alg.} × {aeads}

But I haven't thought about this very hard and haven't been following the
topic, so that may be opening a huge can of worms.

David

---

From: Dave Garrett <[email-masked]>
Date: Sat, 13 Jun 2015 14:59:31 -0400

> all clients to offer the ECDHE_ECDSA variant of every bulk cipher.

Yes, for TLS 1.3 negotiation, offering the ECDHE_ECDSA would be required under this proposal.

[snip]
> certificate verifier can't handle it.

At some point, clients that want to continue supporting EOL OSes forever are going to have to roll their own implementations of modern crypto instead of attempting to rely on the OS. Either that, or drop support.

[snip]
> topic, so that may be opening a huge can of worms.

That's essentially the nuke it all from orbit, just to be sure, solution. ;)

I'm not against it. It would trade one form of complexity (reduced suites + existing extensions) for a new form of complexity (existing extensions + a new extension), but that could be worth it and simpler overall. If we want to make absolutely sure TLS 1.2 backwards compatibility and TLS 1.3 support are separate, this is the way to do it.

The largest benefit of this approach might actually just be dropping the need to define the missing ECDHE_* suites to fill in the gaps that got overlooked (e.g. expired drafts). The whole extension and its initial codepoint assignments could be defined in the TLS 1.3 spec.

It wouldn't be quite as simple as you propose, though, because we'd definitely have to add a new way to declare anon or PSK support via extensions, but that's doable.

That said, there was push back against full a la carte in previous discussion on this list. The reason for ending up at this proposal was the desire to use _existing_ systems (ciphers + existing extensions) in a consistent manner to negotiate things with fewer suites, rather than overhaul everything. 

I'm perfectly willing to throw out my draft proposal and switch to this strategy if we agree it is worth implementing. Obsoleting the entire cipher suite system would be opening a can of worms, but it might be a smaller can of worms than we currently have to deal with.

Dave

---

From: David Benjamin <[email-masked]>
Date: Sat, 13 Jun 2015 19:19:20 +0000

> Yes, for TLS 1.3 negotiation, offering the ECDHE_ECDSA would be required

Perhaps I'm misunderstanding your goals here then. My read of (4) above was
that this was intended to use the ECDHE_ECDSA representative of, say,
AES_128_GCM as the spelling of AES_128_GCM (so effectively repurposing the
cipher list as the list of AEADs[*]), and that this wouldn't actually
translate to offering ECDHE_ECDSA due to that really being negotiated by
the other two extensions.

But this doesn't seem to be completely the case because the ClientHello is
interpreted by both TLS 1.3 servers and existing servers. And so we need to
consider the effects on both to avoid interop. issues.

[*] As you say below, not quite because you still premultiply the really
exotic things like PSK and anon. But setting those aside for the sake of
discussion.

David

> At some point, clients that want to continue supporting EOL OSes forever
> are going to have to roll their own implementations of modern crypto
> instead of attempting to rely on the OS. Either that, or drop support.
>
> [snip]
> I'm not against it. It would trade one form of complexity (reduced suites
> + existing extensions) for a new form of complexity (existing extensions +
> a new extension), but that could be worth it and simpler overall. If we
> want to make absolutely sure TLS 1.2 backwards compatibility and TLS 1.3
> support are separate, this is the way to do it.
>
> The largest benefit of this approach might actually just be dropping the
> need to define the missing ECDHE_* suites to fill in the gaps that got
> overlooked (e.g. expired drafts). The whole extension and its initial
> codepoint assignments could be defined in the TLS 1.3 spec.
>
> It wouldn't be quite as simple as you propose, though, because we'd
> definitely have to add a new way to declare anon or PSK support via
> extensions, but that's doable.
>
> That said, there was push back against full a la carte in previous
> discussion on this list. The reason for ending up at this proposal was the
> desire to use _existing_ systems (ciphers + existing extensions) in a
> consistent manner to negotiate things with fewer suites, rather than
> overhaul everything.
>
> I'm perfectly willing to throw out my draft proposal and switch to this
> strategy if we agree it is worth implementing. Obsoleting the entire cipher
> suite system would be opening a can of worms, but it might be a smaller can
> of worms than we currently have to deal with.
>
>
> Dave
>

---

From: Dave Garrett <[email-masked]>
Date: Sat, 13 Jun 2015 15:47:29 -0400

> consider the effects on both to avoid interop. issues.

This proposal could be extended to allow any cipher to negotiate any handshake based on the extensions, but that leaves us with a din of cipher suites. TLS 1.3 implementations would have to allow:

negotiate DHE/ECDHE + RSA/DSS/ECDSA from all suites with any of the following:
DHE_RSA, DHE_DSS, DHE_ECDSA, ECDHE_RSA, ECDHE_DSS, ECDHE_ECDSA (some of these combos don't exist, though)

negotiate DHE/ECDHE + PSK from all suites with any of the following:
DHE_PSK, ECDHE_PSK

negotiate DHE/ECDHE +anon from all suites with any of the following:
DH_anon, ECDH_anon (or named as: DHE_anon, ECDHE_anon)

We could do this, but it's more to keep track of.

By restricting TLS 1.3 suites to just those prefixed with ECDHE_ECDSA/PSK/anon, this means all others can be completely ignored for TLS 1.3+ and DHE suites can be deprecated in general.

DHE weak param negotiation is a problem, but negotiation via the extension uses strong groups. Requiring ECDHE prefixed suites also prevents negotiation of DHE with weak params with older implementations, as it's not even offered.

> exotic things like PSK and anon. But setting those aside for the sake of

I set them aside for the sake of discussion for the first draft of this proposal and most of the discussion ended up on being how to deal with them. They complicate things, but they need to be taken into account from the start regardless of which path we pick.

Dave

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 13 Jun 2015 20:43:18 +0000

> extensions, but that's doable.

Or we don't support those features in 1.3.  Something we should think about?

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 13 Jun 2015 21:44:46 +0000

> Or we don't support those features in 1.3.  Something we should think about?

I don't see any reason to kill them they don't add to the combinatorial
bloat of the client HELLO.  Most clients won't offer either in the
handshake, but those that need them, benefit from having a protocol
definition for them.  Especially if these are negotiated separately
from the bulk cipher-suite, they are easy to support.

-- 
	Viktor.

---

From: Dave Garrett <[email-masked]>
Date: Sat, 13 Jun 2015 18:20:08 -0400

> Or we don't support those features in 1.3.  Something we should think about?

Completely dropping support for PSK & anon is not likely to get consensus.

Dave

---

From: Dave Garrett <[email-masked]>
Date: Sat, 13 Jun 2015 20:44:47 -0400

On Saturday, June 13, 2015 06:29:31 pm Eric Rescorla wrote:
> On Sat, Jun 13, 2015 at 6:20 PM, Dave Garrett <[email-masked]> wrote:
> Certainly not PSK.

Anon could be replaced relatively easily, though: it's essentially just null PSK.

Define the null PSK identity to use a null key, and then all (EC)DHE_PSK suites can be used similarly to (EC)DH_anon. You just need to have the client propose the PSK identity in the ClientHello via an extension, which is already on the table in ekr's current WIP branch.

PSK suites could be replaced with a PSK SignatureAlgorithm codepoint in “signature_algorithms” extension. (this was suggested by someone at some point on this list, but I don't remember where that discussion was, offhand)

With the above, ECDHE_ECDSA becomes the one-true-prefix. TLS 1.3 would only negotiate cipher suites of that prefix, and cipher suites would be solely for negotiating the symmetric cipher. All (EC)DH(E)_PSK & (EC)DH_anon suites would be deprecated, in addition to the older suites currently proposed to be deprecated (DHE, DH, ECDH, RSA, DSS).

This would simplify the current proposal without the need to create a new AEAD cipher negotiation extension as suggested by David Benjamin.

The only caveat is plain PSK, which has three options:
1) Define NamedGroup=null(0) for it to be negotiated via the “named_groups” extension.
2) Drop it and only use (EC)DHE_PSK.
3) Keep TLS_PSK_WITH_* suites around just for this.

Frankly, anything so constrained that it can't use an ECDHE exchange with PSK probably has no incentive to upgrade to TLS 1.3, or possibly even to an AEAD cipher. I would prefer simply mandating (EC)DHE usage with PSK and anything that can't even use the fastest ECDHE curve can stick with TLS 1.0-1.2 forever.

Dave

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 13 Jun 2015 20:54:10 -0400

On Sat, Jun 13, 2015 at 8:44 PM, Dave Garrett <[email-masked]>
wrote:

> Define the null PSK identity to use a null key, and then all (EC)DHE_PSK
> suites can be used similarly to (EC)DH_anon. You just need to have the
> client propose the PSK identity in the ClientHello via an extension, which
> is already on the table in ekr's current WIP branch.
>
> PSK suites could be replaced with a PSK SignatureAlgorithm codepoint in
> “signature_algorithms” extension. (this was suggested by someone at some
> point on this list, but I don't remember where that discussion was, offhand
>

I don't see how this is going to work. All of the PSK cipher suites use the
PSK
as a source of keying material

> With the above, ECDHE_ECDSA becomes the one-true-prefix.

Maybe I'm misunderstanding what you're saying here, but I don't understand
this point. Certainly I don't see any significant support whatsoever for
deprecating RSA
signatures, and given that we just standardized FFDHE, I don't see much
evidence
of consensus for deprecating DHE either.

> Frankly, anything so constrained that it can't use an ECDHE exchange with
> PSK probably has no incentive to upgrade to TLS 1.3, or possibly even to an
> AEAD cipher. I would prefer simply mandating (EC)DHE usage with PSK and
> anything that can't even use the fastest ECDHE curve can stick with TLS
> 1.0-1.2 forever.

I do not support this position. There are plenty of devices which want to
use PSK
only, and we want everyone to upgrade to TLS 1.3.

-Ekr

---

From: Dave Garrett <[email-masked]>
Date: Sat, 13 Jun 2015 21:15:35 -0400

On Saturday, June 13, 2015 08:54:10 pm Eric Rescorla wrote:
> PSK as a source of keying material

A client proposing the PSK SignatureAlgorithm codepoint and a PSK identity would be offering to negotiate PSK using that key.

Anon would be proposed the same way, just with a null PSK identity. All security comes from the FS from (EC)DHE. (just like (EC)DH_anon)

The server could simply state acceptance of negotiation by echoing back the same PSK extension.

> deprecating RSA signatures, and given that we just standardized FFDHE, I don't see much
> evidence of consensus for deprecating DHE either.

This is all in the context of the proposal discussed in this thread. RSA signatures would be negotiated using the "signatures_algorithms" extension. DHE would be negotiated via the "named_groups" extension. (pick an FFDH group for FFDHE or an ECDH curve for ECDHE) The point is to negotiate any of the following via those two extensions and the ECDHE_ECDSA prefix:
DHE, ECDHE, RSA, DSS/DSA, ECDSA (or EdDSA), PSK (or anon)

This would give us fewer suites with no new extensions beyond those already proposed. Just need to use the already proposed extension additions and add a codepoint for PSK/anon.

Dave

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 13 Jun 2015 22:04:46 -0400

On Sat, Jun 13, 2015 at 9:15 PM, Dave Garrett <[email-masked]>
wrote:

> A client proposing the PSK SignatureAlgorithm codepoint and a PSK identity
> would be offering to negotiate PSK using that key.
>

But again, PSKs in TLS use it as a source of keying material, not just
authentication. So, using that as a SignatureAlgorithm seems... weird.

-Ekr

Anon would be proposed the same way, just with a null PSK identity. All
> security comes from the FS from (EC)DHE. (just like (EC)DH_anon)
>
> This is all in the context of the proposal discussed in this thread. RSA
> signatures would be negotiated using the "signatures_algorithms" extension.
> DHE would be negotiated via the "named_groups" extension. (pick an FFDH
> group for FFDHE or an ECDH curve for ECDHE) The point is to negotiate any
> of the following via those two extensions and the ECDHE_ECDSA prefix:
> This would give us fewer suites with no new extensions beyond those
> already proposed. Just need to use the already proposed extension additions
> and add a codepoint for PSK/anon.
>
>
> Dave
>

---

From: Dave Garrett <[email-masked]>
Date: Sat, 13 Jun 2015 23:36:08 -0400

On Saturday, June 13, 2015 10:04:46 pm Eric Rescorla wrote:
> On Sat, Jun 13, 2015 at 9:15 PM, Dave Garrett <[email-masked]> wrote:
> > > On Sat, Jun 13, 2015 at 8:44 PM, Dave Garrett <[email-masked]> wrote:

It already has a non-cert value in there for anonymous (that can't be used, which is also weird), but I agree with your point.

We could instead have no PSK sig point and just have the PSK identity extension be the only thing to negotiate PSK. We don't really need both. In fact, PSK-only clients wouldn't need to bother with the signatures extension at all. Plain PSK would be as simple as just not offering the groups extension, either.

So:
NamedGroup select FF group or EC curve -> FFDHE / ECDHE
SignatureAndHashAlgorithm list -> RSA / DSA / ECDSA / EdDSA
PSK_identity -> select key by id / null for anon

All cipher suites used would be ECDHE_ECDSA, but these extensions would be able to negotiate from any of the above. Cipher suite negotiation would be only for selecting the symmetric cipher (+hash to go with it). The extensions would do the rest.

To reiterate the rationale for considering this:
* DHE suites need retiring because of weak param negotiation and old Java choking on mitigations.
* Endpoints won't be able to fail a handshake anymore just because the admin missed one of the possible combinations of cipher suite components, even though they should be compatible. Also, more subtly, they won't accidentally negotiate a suite that's only in there for backwards compatibility as easily. (e.g. I've seen instances where one client gets an old cipher because its new cipher combo is low in the list, as the server admin probably only tested with another client that picks a slightly different combo higher in the list.)
* Simpler config overall; now a list of yes/no that can be individually prioritized, instead of having to prioritize all arbitrary combos.
* Less ClientHello size bloat from adding lots of suites. Large hellos can cause interop failure due to bugs.
* Easier to amend. There was discussion of hand-waving EdDSA~ECDSA. With this, it can have its own signature algorithm point and nothing else special is really needed (beyond using the frozen suite prefix, like everything else does). A future completely different algorithm could be added without having to muck around with cipher suite combinations anymore. (e.g. post-quantum algorithms will be needed, eventually; once defined with a sig point in the extension, all symmetric ciphers could use them right away)
* Anon or PSK can be used with any symmetric cipher without having to standardize suite values anymore.

Dave

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 14 Jun 2015 09:33:42 +0300

> The server could simply state acceptance of negotiation by echoing back

IMO, the problem here is that all the following have quite different
key exchange:
- GDHE_CERT
- GDHE_PSK
- GDHE_anon
- PSK

(PRF and symmetric cipher don't affect key exchange).

PSK is not signature algorithm. It works by mixing its key material into
secrets.

Trick of using empty cert and HMAC(PSK, ...) as authentication to unify
GDHE_CERT and GDHE_PSK won't work if one is to remain compatible with
TLS 1.2 DHE_PSK (or at least, requires further tricks).

The problem is that in TLS 1.2, there is thing called PSK hint, which
is optionally sent from server to client. Then client will chose its
final PSK identity. In TLS 1.3, that sort of thing would need 1RTT
miss, followed by extra message from the client to select the final
PSK identity (and possibly also sending a missing group key if in
GDHE_PSK).

And I think optional handshake messages are a bad idea, being souce
of nasty bugs (situation-dependent is different thing).

Trying to map GDHE_anon to GDHE_PSK doesn't at least run into
bad problems with messages, but I wouldn't use null identity, as
that can be very much used in real world.

Then the pure-PSK is totally different from anything else. There
the only source of keying is the psk, which has to act as direct
input to hMS.

-Ilari

---

From: Dave Garrett <[email-masked]>
Date: Sun, 14 Jun 2015 11:55:02 -0400

> PSK identity (and possibly also sending a missing group key if in

https://www.ietf.org/mail-archive/web/tls/current/msg16748.html

ekr is currently considering adding a PSK identity extension for the ClientHello. (it's in his current WIP branch, atm) It's just a simple extension to have the client send the id it wants. This is what I was saying would be all that was needed for PSK. The entire signatures extension wouldn't be needed; just send the PSK id (anon=null) and the supported groups extension. Selected NamedGroup selects FF/EC DHE; for plain PSK, don't send this extension either.

> of nasty bugs (situation-dependent is different thing).

Yes, that sort of thing is a risk. This has PSK & CERT largely separate, so within each use-case, not much is optional.

From an alternate perspective, this could be viewed as kicking PSK/anon out of TLS 1.3 proper and moving it entirely to a dedicated extension (though, defined in the same document).

Dave

---

From: Nico Williams <[email-masked]>
Date: Tue, 16 Jun 2015 18:31:12 -0500

On Thu, Jun 11, 2015 at 03:58:21PM -0400, Dave Garrett wrote:
> Here is a branch with a rough draft of an a la carte handshake
> algorithm negotiation scheme for TLS 1.3, based on discussions on this
> list.

> https://github.com/davegarrett/tls13-spec/compare/updateciphersuites...davegarrett:alacarte

 - Yes!  This.

 - IMO the hash should be associated with the "handshake portion" of a
   cipher suite, not the bulk side.

   Ideally it'd be:

      Hash_Algs x KE_groups x Server_auth_algs x Bulk_cipher_and_mode

   That's four registries instead of one or two.

   I'll settle for your proposal though!

 - It'd be nice if instead of always thinking of authentication as
   "signatures" we just thought of it as authentication.

   Consider authentication by using a DH cert...  If that's selected
   then the handshake won't be the usual one that we're all used to, but
   it would be workable.

 - Anon ciphersuites...

   I'd much rather that the WG did NOT deprecate these!

   For opportunistic security and channel binding applications anon
   ciphersuites are just fine, and the alternatives are wasteful (e.g.,
   doing signatures that aren't needed).

   Recommending against the use of anon ciphersuites is and should be a
   job for UTA.

Nico
--

---

From: Dave Garrett <[email-masked]>
Date: Tue, 16 Jun 2015 20:29:17 -0400

>    cipher suite, not the bulk side.

The bulk cipher and hash are often directly correlated. (e.g. SHA384 paired with AES-256) The signature algorithms extension lists hashes for each certificate type.

>    ciphersuites are just fine

The alternatives in the current draft proposal are raw keys with trust after anon connect and fully anon via PSK. The reason for wanting to deprecate these suites is that this feature is under-maintained in the spec. There are currently no ECDHE AEAD anon suites. We'll want to publish an RFC to define new codepoints for ECDHE PSK suites to match existing DHE versions, but having to double that for anon is a bit of a mess (and some are against it). Folding anon into PSK as a special case simplifies things and makes cipher support not as much a side issue / afterthought.

Logically, anon is a globally pre-shared null key, so it makes sense.

> the alternatives are wasteful (e.g., doing signatures that aren't needed).

The currently proposed anon PSK has no overhead. Anon PSK is just id="anonymous" and a NULL key. (EC)DHE is used as normal. The only difference in computation is that the pre-master secret with anon PSK is DHresult + 0x00010 (where `+` is concat). Tacking 5 bytes onto the end of the DH result, once a handshake, is essentially zero overhead.

Dave

---

From: Nico Williams <[email-masked]>
Date: Tue, 16 Jun 2015 22:59:52 -0500

On Tue, Jun 16, 2015 at 08:29:17PM -0400, Dave Garrett wrote:
> The bulk cipher and hash are often directly correlated. (e.g. SHA384
> paired with AES-256) The signature algorithms extension lists hashes
> for each certificate type.

Ah, OK.

> The alternatives in the current draft proposal are raw keys with trust
> after anon connect and fully anon via PSK. The reason for wanting to

Raw (or certificated but unable to chain to any trust anchor of the
relying party's) works, but it's a waste of resources.

PSK with a fixed key is a pointless complexity.  We already have an
unauthenticated mode; there's no need to replace it with another more
complicated one.

> deprecate these suites is that this feature is under-maintained in the
> spec. There are currently no ECDHE AEAD anon suites. [...]

We've noted this and asked for them to be registered.  The missing
assignments does not mean that the feature is unmaintained as
implemented (it's in use), as as to the spec: we're maintaining it now,
and a la carte negotiation effectively fixes the missing cipher suite
assignment issue.

> Logically, anon is a globally pre-shared null key, so it makes sense.

Logically anon (really, unauthenticated) is just... not authenticated.

> The currently proposed anon PSK has no overhead. Anon PSK is just
> id="anonymous" and a NULL key. (EC)DHE is used as normal. The only
> difference in computation is that the pre-master secret with anon PSK
> is DHresult + 0x00010 (where `+` is concat). Tacking 5 bytes onto the
> end of the DH result, once a handshake, is essentially zero overhead.

Why do even that?

Nico
--

---

From: Dave Garrett <[email-masked]>
Date: Wed, 17 Jun 2015 00:41:30 -0400

> and a la carte negotiation effectively fixes the missing cipher suite

I'm trying to reduce the number of valid prefixes. The anon options are essentially:

1) Merge (EC)DH_anon into ECDHE_PSK & drop all (EC)DH_anon
2) Define all ECDHE_anon & drop all DH_anon

I moved towards #1 in the last revision of the draft because some seemed interested in dropping the feature to reduce overall spec complexity. There's notable disagreement on this list over whether or not the anon suites are worthwhile, so I wrote up what would be needed for it. (e.g. wasn't sure if ChaChaPoly would get an anon assignment)

> Why do even that?

The idea was to get rid of an entire class of suites as a simplification. There seemed to be a desire on list for dropping them. (was brought up by a few)

I think I'll set the anon deprecation part aside and go back to #2, if defining the new suites isn't an issue. I still think they should be actively discouraged in favor of trust on first use.

I'll change the WIP in a bit.

Dave

---

From: Dave Garrett <[email-masked]>
Date: Wed, 17 Jun 2015 01:31:16 -0400

[snip]
>    I'd much rather that the WG did NOT deprecate these!

Ok, I revised the drafts and forked the anon deprecation changeset.

Main draft proposal:
https://github.com/davegarrett/tls13-spec/blob/alacarte/draft-ietf-tls-tls13.md#cipher-suites-in-tls-13

Version with deprecated anon suites:
https://github.com/davegarrett/tls13-spec/blob/alacarte-noanonsuites/draft-ietf-tls-tls13.md#anonymous-key-exchange

Note that both totally deprecate all DH(E) suites, as that's one of the goals here. (due to weak DH params, old Java choking, & etc.) Thus, all suites must be ECDHE prefixed for TLS 1.3 support under these proposals (with the exception of plain PSK). All ECDHE suites would be capable of negotiating either ECDHE or DHE using string groups via the extension.

PSK & anon will need a litany of new ECDHE suites to be defined. There is currently no ECDHE AEAD anon suite, thus none supporting TLS 1.3 (among the reasons I pursued the idea of merging it into PSK).

I'm fine with relegating the anon deprecation idea to the bin if we agree to define all the new suites we need to maintain support. Getting ECDHE_anon into the ChaChaPoly draft would be a start.

Dave

---

From: Dave Garrett <[email-masked]>
Date: Wed, 17 Jun 2015 01:35:52 -0400

On Wednesday, June 17, 2015 01:31:16 am Dave Garrett wrote:
> All ECDHE suites would be capable of negotiating either ECDHE or DHE using string groups via the extension.

Ugh. Bad enough typo to warrant a quick correction:

"string groups" -> "strong groups"

https://tlswg.github.io/tls13-spec/#negotiated-groups

Dave

---

From: Nico Williams <[email-masked]>
Date: Fri, 26 Jun 2015 15:47:32 -0500

On Fri, Jun 26, 2015 at 07:02:32PM +0000, David Benjamin wrote:
> On Wed, Jun 17, 2015 at 1:31 AM Dave Garrett <[email-masked]> wrote:
> >
> 
> I have the same concerns with this version as before. I don’t believe it
> lowers the risk of accidental interop failure---if anything, it makes it
> worse.
> 
> This scheme is still a problem for Chrome on Windows XP. This proposal
> effectively makes ECDSA (and ECDHE) MTI for any clients doing the standard
> PKI-based handshake. Whether or not this is desirable, it certainly should
> be spelled out clearly in the spec.
> 
> Imagine how implementations look. Most allow configuring the cipher suite
> list. This now interacts subtly with configuring 1.3 ciphers, and we have
> the same interop risks of a parallel extension. What if the consumer, for
> whatever reason, omitted the ECDHE_ECDSA variant of some AEAD but included
> ECDHE_RSA? Now 1.2 servers work, 1.3 ones don’t. Alright, so what if we
> internally checked for consistency? That’s fine, but we could just as
> easily have checked for consistency between 1.2 cipher suites and a new 1.3
> mechanism.

This can be fixed by having signalling cipher suite assignments for
negotiating a cartesian product of them (in addition to any actual
cipher suites offered).  This allows for a) compression of negotiation,
b) fallback support for 1.2, 1.1, and 1.0, and c) expression of
preference for specific cipher suites ahead of (or after) the cartesian
product cipher suites.

We'd still end up with a cartesian product in the registry, but missing
registrations implied by the negotiation signalling cipher suites could
still work.

> If the worry is state-machine bugs due to PKI and PSK key exchanges being
> different, we won’t guard against them by separating
> ECDHE_PSK_WITH_AES_128_GCM_SHA256 from ECDHE_ECDSA_WITH_AES_128_GCM_SHA256.
> No one would make ECDHE_PSK_WITH_AES_128_GCM_SHA256 use a codepath from
> ECDHE_PSK_WITH_CHACHA20_POLY1305, so sufficiently similar cipher suites
> will be funneled together anyway.

+1

---

From: David Benjamin <[email-masked]>
Date: Fri, 26 Jun 2015 20:56:14 +0000

[Oops. I sent this from the wrong address the first time so it didn't get
through to the broader list. Apologies for messing up the threading.]

On Fri, Jun 26, 2015 at 3:02 PM David Benjamin <[email-masked]> wrote:

>> Note that both totally deprecate all DH(E) suites, as that's one of the
>> goals here. (due to weak DH params, old Java choking, & etc.) Thus, all
>> suites must be ECDHE prefixed for TLS 1.3 support under these proposals
>> (with the exception of plain PSK). All ECDHE suites would be capable of
>> negotiating either ECDHE or DHE using string groups via the extension.
>>
>> PSK & anon will need a litany of new ECDHE suites to be defined. There is
>> currently no ECDHE AEAD anon suite, thus none supporting TLS 1.3 (among the
>> reasons I pursued the idea of merging it into PSK).
>>
>> I'm fine with relegating the anon deprecation idea to the bin if we agree
>> to define all the new suites we need to maintain support. Getting
>> ECDHE_anon into the ChaChaPoly draft would be a start.
>>
>
> A separate extension avoids any mixing of semantics and gives a clean
> break from the old pre-multiplied scheme.
>
> As for what this extension contains, I don’t have strong opinions over
> whether we go a la carte---pruning down to the GCMs and CHACHA would also
> address the explosion---but if we bother, it seems a list of AEAD or
> AEAD+PRF is correct. The key exchange is already consistently separated
> from the bulk cipher in TLS. It's a waste to ignore the one clear boundary
> that we actually have.
>

---

From: David Benjamin <[email-masked]>
Date: Fri, 26 Jun 2015 21:12:43 +0000

> registrations implied by the negotiation signalling cipher suites could

Hrm. I might not understanding you right, isn't that roughly the same as
defining new values:

  TLS_ECDHE_CERT_WITH_AES_128_GCM_SHA256
  TLS_ECDHE_CERT_WITH_CHACHA20_POLY1305
  etc.
  ("CERT" being an unopinionated placeholder for the result of the
inevitable bikeshedding over the name. :-) )

and saying that TLS 1.3 uses those rather than either ECDHE_RSA or
ECDHE_ECDSA, but they share a namespace with the pre-1.3 cipher suite list
for convenience and avoiding a new extension? That seems reasonable to me
actually. If we avoid weird pre-1.3 interactions, I don't have opinions on
new extension vs camping out in the old namespace.

Or is the goal that, by accepting both ECDHE_CERT and ECDHE_ECDSA, the
common case can send a slightly shorter ClientHello? (For Chrome I think
it'd be four bytes because we only do two AEADs.)

David

---

From: Nico Williams <[email-masked]>
Date: Fri, 26 Jun 2015 17:14:57 -0500

On Fri, Jun 26, 2015 at 09:12:43PM +0000, David Benjamin wrote:
> > cipher suites offered).  [...]
> 

Yes, they'd share the same cipher suite number (and name) namespace.

Pre-1.3 implementations would ignore these "new" cipher suites, which is
why still sending some old ones is important for interop.

Using an extension loses the ability to express old vs. new cipher suite
relative priorities.  That might not be a problem (with 1.3<->1.3 using
only the new thing), and if no one cares, then I wouldn't either.

> it'd be four bytes because we only do two AEADs.)

There's two different goals here:

1) "Compress" the ClientHello;
2) (maybe!) reduce the amount of bookkeeping to do in the cipher suite
   registry.

(2) is easier if we go with an extension instead of camping on the
cipher suite namespace.

We've failed to register useful cipher suites before.  We can probably
fix this anyways by writing tools for IANA to do the cartesian product
so that it's never again a manual process for RFC authors nor for IANA.

Elegance would also be a goal, except that it's too late for that.

Nico
--

---

From: David Benjamin <[email-masked]>
Date: Fri, 26 Jun 2015 22:40:15 +0000

> only the new thing), and if no one cares, then I wouldn't either.

I was assuming there would never be a reason to order 1.3 and 1.2's
mechanisms, yeah. If it's a new extension, only use that new extension and
we just ignore the 1.2 cipher suite list once 1.3 is set. If it's camping
out in the cipher suite list, anything not in 1.3 should be ignored once
1.3 is set.

(Amusingly, if we use the same namespace but use completely non-overlapping
values, it might be safer to put the 1.3 ciphers *after* the 1.2 ones. I've
gotten a bug report about a server that only pays attention to the second
byte of every cipher suite value. Or perhaps it thought cipher suites were
one byte. Anyway, I don't actually think this is worth bothering about,
just a funny/sad story. It's only been the one report and I declined to do
anything for it.)

David

---

From: Dave Garrett <[email-masked]>
Date: Fri, 26 Jun 2015 19:18:47 -0400

> be spelled out clearly in the spec.

In the current draft proposal, ECDSA cipher suites are mandatory for TLS 1.3, but endpoints are not required to support ECDSA (extension does negotiation). Support expectation is clear: "SHOULD offer at least one ECDHE group and SHOULD offer support for ECDSA".

Clients on EOL OSes without ECC that don't have their own ECC implementations are broken. We shouldn't even consider trying to compensate for this in the spec. To implement the new spec, you have to write a new implementation, so no, relying on an old EOL OS implementation for a part of it into your implementation is not guaranteed to be enough. Vendors still doing this will need to either decide to actually implement things themselves or only support capable OSes.

> A separate extension avoids any mixing of semantics and gives a clean break
> from the old pre-multiplied scheme.

Indeed. Again, I do not oppose this route. If we can agree on this, I have no problem with dropping my current approach to switch to it.

It is, however, a total break from cipher suites, which could make assessing configurations with mixed TLS version support a bit more complicated. Keeping bulk cipher negotiation in suites makes keeping track of server bulk cipher support a little easier.

> AEAD+PRF is correct.

I think the best way to do this would be one byte for selecting the AEAD cipher and a second byte for selecting a key+hash size combination. This could be very helpful in the future when SHA3 and future new hashes get deployed, as anything would be capable of negotiating it if an appropriate size is available. Separating these two would give us full a la carte, which could be very helpful, but is also of course more complex.

Dave

---

From: Dave Garrett <[email-masked]>
Date: Fri, 26 Jun 2015 19:24:24 -0400

On Friday, June 26, 2015 06:40:15 pm David Benjamin wrote:
> Amusingly, if we use the same namespace but use completely non-overlapping
> values, it might be safer to put the 1.3 ciphers *after* the 1.2 ones.

This is sort of a variation of one of the ideas much earlier in the discussion. The idea was to create new cipher suites for TLS 1.3+ and cut off support for old suites in new versions. This would let us name them in a less confusing manner, e.g.:
TLS2_E_CERT_WITH_AES_128_GCM_SHA256
TLS2_E_ANON_WITH_AES_128_GCM_SHA256
TLS2_E_PSK_WITH_AES_128_GCM_SHA256
TLS2_S_PSK_WITH_AES_128_GCM_SHA256
(where 'E' indicates ephemeral and 'S' indicates static or symmetric-only)

Not a bad route, but requires defining a pile of new suites.

Dave

---

From: Nico Williams <[email-masked]>
Date: Fri, 26 Jun 2015 20:40:35 -0500

On Fri, Jun 26, 2015 at 07:24:24PM -0400, Dave Garrett wrote:
> This is sort of a variation of one of the ideas much earlier in the
> discussion. The idea was to create new cipher suites for TLS 1.3+ and
> cut off support for old suites in new versions. This would let us name
> them in a less confusing manner, e.g.:

We could do even better: stop cartesian products altogether.

  TLS_SRV_AUTH_NONE (anon)
  TLS_SRV_AUTH_PKIX (certs)
  TLS_SRV_AUTH_PSK  (also authenticates the client)

  TLS_KEX_DH
  TLS_KEX_ECDH
  TLS_KEX_KEY_TRANSPORT (encryption to the server's RSA pubkey)

  TLS_ENC_AES_128_GCM_SHA256 (the hash is for the handshake, but has to
                              match the symmetric encryption suite's
                              strength)
  TLS_ENC_AES_256_GCM_SHA512
  ...

Key exchange, authentication, bulk+hash.

> Not a bad route, but requires defining a pile of new suites.

We wouldn't change any of the details of the symmetric parts of the
cipher suites.  It'd be easier to keep track of things if we do this.

Nico
--

---

From: Dave Garrett <[email-masked]>
Date: Fri, 26 Jun 2015 21:51:47 -0400

>   TLS_SRV_AUTH_PSK  (also authenticates the client)

What's "SRV" in this context, short for "server"?

> cipher suites.  It'd be easier to keep track of things if we do this.

I don't really like this variation. It adds a lot more stuff in the existing cipher suite codespace and makes it a lot more complicated. I'd rather either go for less change or maximal change, i.e. current draft proposal or deprecate suites in favor of a new extension. I don't think this sort of middle-ground is worth it. I suggested something somewhat similar to this in prior discussion, but we ended up moving towards the current proposal.

Dave

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 27 Jun 2015 11:09:28 +0300

> Key exchange, authentication, bulk+hash.

One can't really decouple authentication and key exchange cleanly,
especially because of PSK (KEX+Auth sets key exchange shape).

Also, DH and ECDH (and perhaps some other things) do unify to GDH.

Also, one way to do PRF-hash replacement would be to define sets of
PRF-hashes, and have the symmetric algorithm pick algorithm from
that set.

E.g. SHA-2: SHA-256/SHA-384/SHA-512
     BLAKE2B: BLAKE2B-256/BLAKE2B-384/BLAKE2B-512

Then YYY_HASH256 + SHA2 -> SHA-256, YYY_HASH384 + SHA2 -> SHA-384,
YYY_HASH256 + BLAKE2B -> BLAKE2B-256, YYY_HASH384 + BLAKE2B-384
And so on.

-Ilari

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sat, 27 Jun 2015 16:12:35 -0400

> What's "SRV" in this context, short for "server"?

Yeah, the in-fixed term here is "SRV_AUTH", not just "SRV".  They're
"server authentication" mechanisms (with the caveat Nico mentions above
that "PSK" also authenticates the client).

         --dkg

---

From: Nico Williams <[email-masked]>
Date: Sun, 28 Jun 2015 00:06:09 -0500

> especially because of PSK (KEX+Auth sets key exchange shape).

But I think it simplifies things if we separate them and note that some
mechanisms of one kind have a "twin" of the other kind.

Imagine that TLS 1.3 clients offer / servers select mechanisms for key
exchange and authentication separately but either may contribute to the
other.  Thus to do PSK without PFS the client would offer PSK for key
exchange, and PSK again for authentication.  If the client offers ECDH
for key exchange and PSK for both (and no others), then the server can
pick either PSK only, or PSK + ECDH; if the client offers ECDH for key
exchange and PSK for authentication (and no others) then the server must
do that (or fail).

Some combinations would be non-sensical, such as RSA key transport for
key exchange but PSK for authentication.  The server must not pick them,
but with the client only offering sets of mechanisms from which the
server picks, that's fine.  If there's no sane combination that could be
picked, then the client screwed up and the connection fails.

> Also, DH and ECDH (and perhaps some other things) do unify to GDH.

Yes.  Preferably all DH-like key agreement protocols should be unified,
especially when they can work with standard groups.

> PRF-hashes, and have the symmetric algorithm pick algorithm from

Sure.  I tend to think of the PRF as part of the handshake, so it's a
bit strange to associate it with the bulk cipher, but since we want to
match their strengths, it makes some sense.  We also have to match key
exchange and authentication strengths, but we want to succeed with a
mismatch provided we don't fall to realtime downgrade attacks -- the one
thing we can always match is the hashed and the bulk ciphers.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Sun, 28 Jun 2015 00:09:46 -0500

> What's "SRV" in this context, short for "server"?

Yes.

> > [...]
> 
> I don't really like this variation. It adds a lot more stuff in the
> existing cipher suite codespace and makes it a lot more complicated.

It would reduce the number of new cipher suite allocations.

> I'd rather either go for less change or maximal change, i.e. current
> draft proposal or deprecate suites in favor of a new extension. I

I didn't necessarily mean that these are all in one namespace.  I was
ambiguous on purpose.  I'd be ecstatic with any solution that gets us
past the cartesian product registry and pessimized negotiation.

> don't think this sort of middle-ground is worth it. I suggested
> something somewhat similar to this in prior discussion, but we ended
> up moving towards the current proposal.

Fully dropping the pre-1.3 pre-registered cartesian products and having
N sets of negotiable things instead *is* the maximal change.  Whether we
use a new extension (sure, that seems cleanest) or not is a detail.

Nico
--

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 28 Jun 2015 10:44:03 +0300

> picked, then the client screwed up and the connection fails.

"Chinese menus" with coupled choices are classical source of interop
problems.

Also, out of 6 points for kex/aux (after unifying DH, adding PSK and
renaming PKIX to CERT), only 4 seem sane:

GDH+CERT
GDH+PSK
GDH+ANON
PSK+PSK

KEY_TRANSPORT doesn't lead to anything sane without greatly different
key exchange.

If new PAKE KEX would be added, it would add 2 combinations
fooPAKE+CERT and fooPAKE+ANON (6 for 7).

> especially when they can work with standard groups.

Things that I think might be able to unify are SIDH and RLWE (but I'm
not sure, especially of the latter). Which would be nice, given that
both are allegedly PQ, and together with PQ signatures would make
PQ protocol.

The requirements for unification are:
- Capability to work with fixed public parameters
- Only one message per side.
- The messages can be in either order (even if client always goes
  first).
- Message size <64kB for both.

> thing we can always match is the hashed and the bulk ciphers.

The reason to have a plan for PRF replacement is that formally TLS 1.3
requires CR prf-hash (even if reality may be a lot less harsh). So if
SHA-2 ever breaks, there might be a lot of new ciphers....

(SHA-2 breaking would also cause problems with signatures, but that
is a separate matter and only partially solvable at TLS level).

-Ilari

---

From: David Benjamin <[email-masked]>
Date: Fri, 26 Jun 2015 19:02:32 +0000

David

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sun, 28 Jun 2015 18:38:28 -0400

On Sun 2015-06-28 03:44:03 -0400, Ilari Liusvaara wrote:
> Also, out of 6 points for kex/aux

I think you mean kex/auth here, right?  i'm just asking for the sake of
clarity; this conversation has lots of slightly divergent shorthand
notation thrown around.

> (after unifying DH, adding PSK and renaming PKIX to CERT), only 4 seem
> sane:
>
> GDH+CERT
> GDH+PSK
> GDH+ANON
> PSK+PSK
>

Doesn't PAKE provide authentication mechanism as well?  shouldn't at
least one of these be fooPAKE+fooPAKE ?

      --dkg

---

From: Nico Williams <[email-masked]>
Date: Mon, 29 Jun 2015 00:50:24 -0500

> "Chinese menus" with coupled choices are classical source of interop

It's worked for SSHv2.

> KEY_TRANSPORT doesn't lead to anything sane without greatly different

Key transport is its own authentication (like PSK).  It can be combined
with key agreement, but it's much easier to combine key agreement with
signatures instead.

If we unify all the key agreement protocols, then I agree that we have
few enough key exchange + server authentication mechanisms for now, but
see below.

> fooPAKE+CERT and fooPAKE+ANON (6 for 7).

We added GSS support to SSHv2, and I suppose we could add all sorts of
server authentication options to TLS eventually.

And if we don't unify some key agreement protocols, then we've still got
a largish cartesian product.  Still, much smaller (and manageable) than
with the bulk cipher suites thrown in.

> SHA-2 ever breaks, there might be a lot of new ciphers....

Why not use HMAC?

> is a separate matter and only partially solvable at TLS level).

I agree that we should deal with each case separately and try to
minimize future pain.

Nico
--

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 29 Jun 2015 09:26:59 +0300

> clarity; this conversation has lots of slightly divergent shorthand

Yeah, a typo.
 
> least one of these be fooPAKE+fooPAKE ?

Well, at least for SRP there are both cert (server authentication) and
no cert (verify possession of verifier) variants.

-Ilari

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 29 Jun 2015 09:47:26 +0300

> > "Chinese menus" with coupled choices are classical source of interop

Also, the way SSHv2 key exchange and authentication is constructed,
the coupling in SSHv2 is much smaller than it seems. Also, errorneus
pairs can be easily recovered from.

> with the bulk cipher suites thrown in.

I don't think it is that large...

And also, different kex/auth pairs change the handshake in pretty
fundamential ways.

GDH+GSS would presumably be very different from both GDH+CERT and
GSS+GSS or whatever.

Also, I think it is quite major undertaking to add a new kex/auth
pair (especially if it does something "odd" with respect to what's
current).

> > SHA-2 ever breaks, there might be a lot of new ciphers....

Transcripts use hashes. And if raw hash can be collided, HMAC can be
collided as well.

As said, one might need more powerful attacks against hash than
collision to actually break things, but security analysis breaks with
just CR failure.

> I agree that we should deal with each case separately and try to

The "partially solvable" meant adding indicator of prf-hash into
CertficateVerify TBS.

The signatures themselves can't be helped.

-Ilari

---

From: Nico Williams <[email-masked]>
Date: Mon, 29 Jun 2015 02:26:31 -0500

> Transcripts use hashes. And if raw hash can be collided, HMAC can be

Ay, pardon the braino.

Nico
--

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 29 Jun 2015 08:58:11 +0000

>>"Chinese menus" with coupled choices are classical source of interop

It worked for SSH because implementations use algorithm groups in highly 
stereotyped ways, so you have a de facto interop profile. Try negotiating 
e.g. RC4+SHA in one direction and AES+SHA2 in the other and see how quickly 
the wheels fall off.

Peter.

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 29 Jun 2015 12:06:04 +0300

> e.g. RC4+SHA in one direction and AES+SHA2 in the other and see how quickly

Also, regarding kex+auth in SSH2, the authentication is interactive, so
choosing something bad most likely just gives an error and client trying
something else. Definitely not the case in TLS.

And record protections in different directions aren't even coupled choice
(all pairs should technically work).

-Ilari

---

From: Nico Williams <[email-masked]>
Date: Mon, 29 Jun 2015 07:55:40 -0500

On Mon, Jun 29, 2015 at 08:58:11AM +0000, Peter Gutmann wrote:
> It worked for SSH because implementations use algorithm groups in
> highly stereotyped ways, so you have a de facto interop profile. Try
> negotiating e.g. RC4+SHA in one direction and AES+SHA2 in the other
> and see how quickly the wheels fall off.

That was an idiotic mistake that nobody takes advantage of.

---

From: Nico Williams <[email-masked]>
Date: Mon, 29 Jun 2015 07:57:53 -0500

> something else. Definitely not the case in TLS.

Not so.  _User_ authentication in SSHv2 is retriable, but the key
exchange part of the protocol (which includes server authentication) is
not.

> (all pairs should technically work).

Again, that was a mistake that nobody takes advantage of.  I don't
understand how it came to be.