Re: [TLS] draft-ietf-tls-tls13-19 posted

[Ilari Liusvaara <[e-mail]>]

On Fri, Mar 10, 2017 at 03:34:39PM -0800, Eric Rescorla wrote:
> I just posted draft-19 at:
> 
>   https://tools.ietf.org/html/draft-ietf-tls-tls13-19
> 
> This draft includes all the outstanding wire format changes that I believe
> we are going
> to make before publication (changelog below). There are three remaining
> issues that
> we need to address somehow. I've listed them and proposed resolutions.

Did a preliminary implementation. Need to wait for other implementations
in order to interop-test. Of course, doesn't imlplement most besides
the basics (especially most of the subtler stuff is not implemented).


I did a review, lookinge especially for text (other than the known
issues) that:

- I think is technically unworkable.
- I am not entierley sure of proper interpretation.
- I think is problematic w.r.t. security or interop.
- I think is internally inconsistent.
- I think references something that should not be referenced in that
  context, due to problematic interpretations of applying whatever
  is referenced there, or reference going seemingly to nowhere.
- I think is some potential process mumbo-jumbo.

------------------------------------------------------------------------
Header:

- Do you also need to update RFC6962? The data transport for it is
  redefined.

Section 2.3:

- If client TLS library does not get explicit ACK from client
  application to exit 0-RTT mode, you have a race condition that can
  cause 0-RTT data to appear as 1-RTT data. Attacker may be able
  to affect this race, and key changes do not help.

Section 4.2.3:

- This section talks about dsa_sha1 and ecdsa_sha1, but does not define
  either in listing of values it has.

Section 4.2.3.1:

- What is the exact payload of  DistinguishedName? ASN.1 DER encoding
  of Name structure from RFC5280, bit-to-bit identical as it appears
  in the certificate subject, including the top-level SEQUENCE header
  and length?

Section 4.3.2.1:

- What is the format of OIDs in oid filters? Does it include the
  leading 0x06 and length byte (or two length bytes)?
- What is the format of values? DER encoding of whatever structure goes
  into value of extnValue field, including whatever top-level header
  (usually SEQUENCE, but e.g. KeyUsage has BIT STRING) it happens to
  have?

One idea would be to make the match data abstract, and define that
the match data for KeyUsage is ASN.1 DER encoding of KeyUsage structure
from RFC5280, including the BIT STRING header, and match data for
ExtendedKeyUsage is ASN.1 DER encoding of ExtendedKeyUsage structure
from RFC5280, including the SEQUENCE header.

Also, matcher for SubjectAlternativeName could be useful. Could e.g.
carry DER encoding of RFC5280 SubjectAlternativeName structure,
and match certificates that match all the listed names (including
via wildcard match).

  
Section 4.4.2.2:

- RFC5081 is quite bad example, given that it does not work with
  TLS 1.3, and likely nothing like that ever will, given that there
  is no interest in OpenPGP certs for TLS.
- Should EdDSA added to list of authentication algorithms (alongside
  RSA and ECDSA)?

Section 4.4.2.3:

- Again uses RFC5081 as an example.

Section 4.4.2.4:

- This section does talks about any certificate using MD5 or SHA-1,
  when it probably should talk about any non-self-signed certificate
  using MD5 or SHA-1. There are enormous amount of CA certs with SHA-1
  self-sigs.

Section 4.4.3:

- There is exception allowing unsupported algorithms if no chain can be
  produced. This can't work at all. The CertificateVerify must be
  verfied and it for sure can't be if the algorithm is unsupported.
  Exceptions might work with certificate chains (the chain might end in
  trust anchor before problematic signature is reached), but not here.

Section 5.1:

- There is funky corner-case in initial enabling of encryption: If
  client chokes on ServerHello, the alert it sends will be unencrypted,
  despite next data from ServerHello being encrypted. And if client
  chokes on any other server handshake message, the alert will be
  encrypted.

Section C.6:

- Talks about RFC7250, despite that not going to work.
- This section essentially has a FIXME regarding channel bindings.
------------------------------------------------------------------------
.

-Ilari