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

[Ilari Liusvaara <[e-mail]>]

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.
 
> 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.
 
> > 4.2.7. There is no guidance on the use of max_early_data_size.
> > I'd find it natural to have a recommended minimum value for application
> > protocols layered on TLS to take into account. E.g., text like servers
> > supporting early_data SHOULD allow at least 1024 bytes of data
> > (arbitrary number). Is the 32-bit upper limit intentional?
> 
> I think it's just a result of the way the PDU is formatted. I
> would be interested in seeing a PR with guidance...

The max_early_data_size looks kinda iffy. I understand the justification
is about buffering for verification, but that kind of buffering AFAICT
destroys the benefits of 0-RTT, so I would just skip 0-RTT if I knew
such buffering would take place.
 
> > The text recommends: "a server SHOULD measure the round trip time prior
> > to sending the NewSessionTicket message". I see two issues here. (1) it
> > doesn't mention how to do this measurement --my guess is that this can
> > be done in the context of TLS--, and (2) it assumes that round-trips
> > are fixed over time. About (1), I ask because the obvious measurement
> > time between [server Application Data*] and client [Certificate*] would
> > include the processing of the application data by the client.
> > On (2), this check will not work as is for mobile clients which will
> > have variable round-trips.

The thresholds seem so loose anyway, that I don't see much need to even
try to measure the RTT, one can seemingly just ignore them.

> > 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. 
 
> > 4.4.2.1.  OCSP Status and SCT Extensions
> > This is a very nice addition to TLS 1.3. Something that I miss as an
> > implementer is guidelines on how to determine the (time) validity of an
> > OCSP stapled response. Here my point is that OCSP responses have
> > several fields optional (e.g., nextUpdate), which make a validation to
> > be hand-wavy. It would be nice to have a profile of OCSP responses that
> > would be recommended for use in TLS, as well or a recommendation of
> > what constitutes a "fresh" response for use in TLS.
> 
> Do you have any thoughts on what text we should insert here? I admit
> to being not that familiar with the practical matters of OCSP stapling.

Well, my implementation considers OCSP responses valid to NextUpdate,
and fails handshake if it is absent but OCSP staple is sent.

> > 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).
 
> > 4.4.3. "RSA signatures MUST use an RSASSA-PSS algorithm". What should a
> > client or server do when encounters an non RSA-PSS signature in TLS

Well, my implementation just aborts. I have actually seen an TLS 1.3
draft implementation sign with RSA PKCS#1 (it did so if one sent a
ClientHello that only had that and ECDSA and EdDSAs).

> > 4.6.3. My comment on this section, is that leaving up to the
> > implementer to decide the re-key, would most probably result in the
> > implementer delegating that decision to the application. In my
> > experience that would mean no re-key in practice for the majority of
> > applications. I'd have preferred a one-size fits all approach, where
> > re-key is done on decided points.
> 
> I can understand that, but we did litigate this extensively, so I think
> any change would require WG consensus at this point.

Might be a good idea to have suggestion to send one fairly early in the
connection.
 
> > 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