Subject: [TLS] MTI extensions?

From: Dave Garrett <[email-masked]>
Date: Sat, 14 Mar 2015 02:12:52 -0400

Idea: Add a small section after MTI cipher suites for MTI extensions.

After enumerating the extensions that are part of the TLS 1.3 spec itself, I think it would be helpful to list a few other extensions that are reasonable to expect of all implementations. In particular, SNI & ALPN should ideally be available everywhere. (not all deployments would need them, but they should always be available) These are the two HTTP/2 needs to work, so just stating that as a requirement in the TLS 1.3 spec would ensure that all TLS 1.3 implementations are HTTP/2 ready without further consideration.

Dave

---

From: Martin Thomson <[email-masked]>
Date: Sun, 15 Mar 2015 11:08:23 -0700

> Idea: Add a small section after MTI cipher suites for MTI extensions.

I think that's fine.  Signature algorithms was made mandatory in 1.2,
here, we are going to make ClientKeyShare mandatory.  I think that
there is good justification for SNI too.

> After enumerating the extensions that are part of the TLS 1.3 spec itself, I think it would be helpful to list a few other extensions that are reasonable to expect of all implementations. In particular, SNI & ALPN should ideally be available everywhere.

I don't see any point in making ALPN mandatory.  If you need it, you
need it; if you don't, that's all there is to say.

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 15 Mar 2015 18:21:20 +0000

Agree with mt: SNI yes, ALPN not mandatory.

--  
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 15 Mar 2015 20:25:29 +0200

On Sun, Mar 15, 2015 at 11:08:23AM -0700, Martin Thomson wrote:
> > After enumerating the extensions that are part of the TLS 1.3 spec
> itself, I think it would be helpful to list a few other extensions
> that are reasonable to expect of all implementations. In particular,
> SNI & ALPN should ideally be available everywhere.
> 

Also, regarding ALPN... It occurs to me ALPN interacts with early client 
data (if doing that). E.g. One certainly does not want earlydata for
HTTP/2 to be played upon HTTP/1.1 (or vice versa).

Also, regarding ALPN, if ALPN is mandated, what API capabilities should
it have? The simplest (set proposed/supported list, get selected protocol)
or something more complicated?

Also, there are extensions one doesn't want to appear in TLS 1.3
(however proposing is possible for backward compat.). Some candidates
are:

- truncated_hmac (does nothing [block ciphers only])
- srp (if SRP is not supported).
- encrypt_then_mac (does nothing [block ciphers only])
- extended_master_secret (can't do anything sane besides no-op)
- renegotiation_info (no renegotiation is possible).

-Ilari

---

From: Martin Thomson <[email-masked]>
Date: Sun, 15 Mar 2015 11:27:41 -0700

On 15 March 2015 at 11:25, Ilari Liusvaara <[email-masked]> wrote:
> One certainly does not want earlydata for

In this case, 0RTT is -  in many senses - just resumption.  I think
that it would be OK to send ALPN with a single value here - the value
from last time.

---

From: Martin Thomson <[email-masked]>
Date: Sun, 15 Mar 2015 11:28:11 -0700

---

From: Dave Garrett <[email-masked]>
Date: Sun, 15 Mar 2015 16:59:01 -0400

On 13 March 2015 at 23:12, Dave Garrett <[email-masked]> wrote:
> In particular, SNI & ALPN should ideally be available everywhere.

> Agree with mt: SNI yes, ALPN not mandatory.

Fair enough.

It might still be worth mentioning in the spec, but with no requirements placed on it.

Dave

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 15 Mar 2015 14:13:14 -0700

SNI might be plausible as a MUST implement but there are plenty of cases
where it's not sensible to be MUST send, as in where there is no server
hostname. E.g., WebRTC.

-Ekr

On Sun, Mar 15, 2015 at 1:59 PM, Dave Garrett <[email-masked]>
wrote:

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

---

From: Dave Garrett <[email-masked]>
Date: Sun, 15 Mar 2015 17:18:50 -0400

> where it's not sensible to be MUST send, as in where there is no server

Yes, I acknowledged that when I started the thread, but with email threading being what it is, it got cut out of quotes. ;)

> Idea: Add a small section after MTI cipher suites for MTI extensions.
[...]
> (not all deployments would need them, but they should always be available)

Dave

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 15 Mar 2015 14:20:21 -0700

Sounds like we're in violent agreement, then.

On Sun, Mar 15, 2015 at 2:18 PM, Dave Garrett <[email-masked]>
wrote:

> Yes, I acknowledged that when I started the thread, but with email
> threading being what it is, it got cut out of quotes. ;)
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 15 Mar 2015 21:28:43 +0000

> where it's not sensible to be MUST send, as in where there is no server

Furthermore, even when SNI is sent, a server should generally NOT
abort the handshake when it does not find a match for the requested
name.

Rather, it is better for the server to choose *some* other (often
default) certificate, and leave it up to the client to decide
whether that one is also acceptable.

This is a signficant consideration for SMTP with DANE, because
clients use the TLSA base domain (typically MX host name) in the
SNI message, but will also accept other names (typically the
recipient domain for which the server is an MX host).  The server
may have just one "UCC" certificate for the recipient domain, and
MUST NOT abort the connection just because the client seems to want
something else.

-- 
	Viktor.

---

From: Jeffrey Walton <[email-masked]>
Date: Sun, 15 Mar 2015 17:52:12 -0400

> This is a significant consideration for SMTP with DANE, because

I think cases like this should be considered further. There's too many
open questions surrounding use cases like this.

Jeff

---

From: [email-masked] (Martin Rex)
Date: Mon, 16 Mar 2015 21:28:58 +0100 (CET)

Martin Thomson wrote:
> Dave Garrett <[email-masked]> wrote:
>>

You may have missed it, but Signature algorithms support in TLSv1.2 is only
mandatory for the *SERVER*.  It is an implementor option for the client.

-Martin

---

From: Martin Thomson <[email-masked]>
Date: Mon, 16 Mar 2015 15:42:56 -0700

> mandatory for the *SERVER*.  It is an implementor option for the client.

Quite right: I consider a default value to be semantically equivalent.