Re: [TLS] MTI extensions?

[Ilari Liusvaara <[e-mail]>]

On Sun, Mar 15, 2015 at 11:08:23AM -0700, Martin Thomson wrote:
> On 13 March 2015 at 23:12, Dave Garrett <[e-mail]> wrote:
> > 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.

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