Re: [TLS] comments on draft-ietf-tls-tls13-19

[Eric Rescorla <[e-mail]>]

On Tue, Apr 11, 2017 at 2:25 PM, Ilari Liusvaara <[e-mail]>
wrote:

> On Tue, Apr 11, 2017 at 01:47:08PM -0700, Eric Rescorla wrote:
> > Thanks for your comments.
> >
> > > 4.1.2. It is not defined what a server should do if encountered with a
> > > ProtocolVersion of TLS 1.3.
> >
> > https://tlswg.github.io/tls13-spec/#supported-versions says:
> >
> >    If this extension is not present, servers which are compliant with
> >    this specification MUST negotiate TLS 1.2 or prior as specified in
> >    [RFC5246], even if ClientHello.legacy_version is 0x0304 or
> >    later. Servers MAY abort the handshake upon receiving a ClientHello
> >    with legacy_version 0x0304 or later.
>
> I think that MAY abort should be removed. client_version field has
> always been defined to be tolerant to higher values.
>

It seems like we are ossifyng that extension point. Otherwise it's very
hard to interpret. But I'm willing to defer if the WG objects.


> > However, as David Benjamin points out, it's not clear how one would
> > handle this in practice, because HRR is an instruction to the client
> > to do something, so if it can't parse that then the handshake fails.
>
> I think if one wanted to have new mandatory HRR extension, one could
> just have it sent, resulting older clients blowing up. But those would
> not be able to connect anyway.
>

That's what we have now :)



> > > 4.3.2.1. The OID Filters extension on a first look seems quite
> > > independent and unrelated to everything else in this document (seemed
> > > quite a distraction that could have been in an appendix as well).
> >
> > This is a fair point, but it's been in the document a long time,
> > so I think this would require WG Consensus.
>
> Also, I have no idea of exact contents of that extension (maybe some mail
> to this list has those, but that won't do with RFCs), as I can interpret
> the thing in multiple ways.


Hmm.. I did think the text was reasonably clear, but maybe I am in too deep.



> > > 4.4.2.2., 4.4.2.3.
> > > I think the reference to RFC5081 should be replaced with RFC5270 which
> > > obsoletes the former even though not explicitly.
> >
> > Indeed. Also, we are now explicitly prohibiting OpenPGP per discussion
> > in Chicago.
>
> Also, maybe needs some text about possible future Certificate Types
> (or are those akin to DNS classes: heavy objects dropped by bad idea
> fairy? :-) ).
>
> Also, client_certificate_type looks to be still CH,EE, which is not
> good if any future certificate types might get defined (or even if
> just RPK is allowed).
>

Actually, I think this is still right. The reason is that this extension
applies
to the client's entire certificate message, not to each certificate, so it
needs to be negotiated up front.

-Ekr



> > > B.4.
> > > I believe it was discussed before, but I miss the AES-256-CCM
> > > ciphersuites. If only one must be defined, it may be better to only
> > > have the 256-bit variants (at least for the non-mac-truncated version)
> >
> > Open to WG feedback here as well.
>
> Also, who uses those? It seems like CCM is mostly for things, and those
> don't use AES-256, as AES-128 already seems quite much for various IoS.
>
> Also, if one wanted special ciphersuite for things, I think there are
> ones that are implementable in smaller space than AES CCM.
>
>
> -Ilari
>