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

[Matt Caswell]

On 11 March 2017 at 19:28, Ilari Liusvaara  wrote:
> 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 have a preliminary OpenSSL implementation here:

https://github.com/openssl/openssl/pull/2895

I haven't done the latest HRR changes yet, and it also doesn't cover
the Certificate Request changes yet either.

Matt

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ilari Liusvaara]

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

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

[Eric Rescorla]

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.

1. DH Key Reuse Considerations (https://github.com/tlswg/tls13-spec/pull/768
)
I'm not entirely confident of the analysis here and I'm not that excited
about encouraging
people to re-use, so I propose that we simply drop this PR.

2. Short headers (https://github.com/tlswg/tls13-spec/pull/762)
Both the Chrome team and the Firefox team have concerns about the middlebox
compatibility impact of this change, and I believe if necessary we can add
it as
an extension later. Thus, I propose we defer it. We can make this change
directly
in DTLS 1.3, however.

3. The various non-X509 cert RFCs (no PR).
As Ilari points out, there is significant incompatibility between these
RFCs and
TLS 1.3, so we'll probably need new versions of them if people want this
functionality.
Absent objection, I'll pull them out of the "usable with TLS 1.3 list" in S
4.2
and then add some handwaving about how we can support them with new
drafts (though, as Ilari indicates, we may be able to keep cached-info with
some
small text changes here).

In terms of implementation, we will probably try to have something for NSS
by IETF, but I doubt it will be actually in Firefox.

As usual, comments welcome, including anything I missed.
-Ekr


ChangeLog:
   -  Hash context_value input to Exporters (*)

   -  Add an additional Derive-Secret stage to Exporters (*).

   -  Hash ClientHello1 in the transcript when HRR is used.  This
  reduces the state that needs to be carried in cookies. (*)

   -  Restructure CertificateRequest to have the selectors in
  extensions.  This also allowed defining a
  "certificate_authorities" extension which can be used by the
  client instead of trusted_ca_keys (*).

   -  Tighten record framing requirements and require checking of them
  (*).

   -  Consolidate "ticket_early_data_info" and "early_data" into a
  single extension (*).

   -  Change end_of_early_data to be a handshake message (*).

   -  Add pre-extract Derive-Secret stages to key schedule (*).

   -  Remove spurious requirement to implement "pre_shared_key".

   -  Clarify location of "early_data" from server (it goes in EE, as
  indicated by the table in S 10).

   -  Require peer public key validation

   -  Add state machine diagram.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls