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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
