Subject: [TLS] WGLC: draft-ietf-tls-tls13-19

From: Sean Turner <[email-masked]>
Date: Mon, 13 Mar 2017 13:30:44 -0400

This is a working group last call announcement for draft-ietf-tls-tls13-19, to run through March 27.  Please send your reviews to the list as soon as possible so we can prepare for any discussion of open issues at IETF 98 in Chicago.  

Thanks,
J&S

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 13 Mar 2017 10:34:48 -0700

Note to Ilari: I have already taken your email as WGLC comments, so no need
to
re-send.

-Ekr

On Mon, Mar 13, 2017 at 10:30 AM, Sean Turner <[email-masked]> wrote:

> This is a working group last call announcement for
> draft-ietf-tls-tls13-19, to run through March 27.  Please send your reviews
> to the list as soon as possible so we can prepare for any discussion of
> open issues at IETF 98 in Chicago.
>
> Thanks,
> J&S
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Yoav Nir <[email-masked]>
Date: Tue, 14 Mar 2017 11:31:18 +0200

Hi.

I will give the entire document a more thorough read, but I wanted to comment on section 1.2 earlier. Its title is “Major differences from TLS 1.2”, but the content is a change-log. The kind of change-log that usually gets deleted by the RFC editor.

I hope we don’t plan to publish with sentences like “Allow cookies to be longer”.  OTOH I think it will be useful to have an actual “major differences from TLS 1.2” section, but AFAICT it’s not yet written.

Yoav

> On 13 Mar 2017, at 19:30, Sean Turner <[email-masked]> wrote:
>

---

From: Dave Garrett <[email-masked]>
Date: Sun, 19 Mar 2017 22:54:27 -0400

Yes, a proper "differences from TLS 1.2" section needs to be written to replace the draft changelog.

Dave

---

From: Olivier Levillain <[email-masked]>
Date: Mon, 27 Mar 2017 09:47:33 +0200

Hi list,

I think there is at least another issue that still needs to be
discussed: how to properly handle post-handshake handshake messages.

The subject has also been raised several times on GitHub
(https://github.com/tlswg/tls13-spec/pull/680,
https://github.com/tlswg/tls13-spec/pull/676,
https://github.com/tlswg/tls13-spec/issues/572) and on the mailing list
(https://www.ietf.org/mail-archive/web/tls/current/msg22038.html).

Bottom line is:
- handling client late authentication requires a lot of state in the
client stack
- currently, handling client late authentication is mandatory

For a longer version, post-handshake records of type Handshake can be of
three kinds:
- NewSessionTicket (sent by the server, and that can safely be ignored
entirely by clients)
- KeyUpdate (sent by either party, requiring only a bit of state)
- CertificateRequest (sent by the server, an arbirary number of times,
and requring the client to keep some state *for each request*)

Of course, this last item makes the post-handshake client state machine
explode, whereas the first two items can ben implemented in a trivial
way. The client can not indeed ignore all this state to answer, since it
is supposed to answer at least with a Finished message, which will cover
the CertificateRequest message. Moreover, since each of these Finished
messages must cover the initial handshake and the current
CertificateRequest message, it requires a forkable hash implementation,
which requires more memory.

A client _could_ ignore CertificateRequest and never answer them, but
this would not really be conformant, and it would be problematic as soon
as the parties need to send Handshake messages.

Thus, I believe the current text is inadequate. Different solutions are
possible :
- remove client late authentication entirely (this would have my
preference, since it introduces other issues*)
- make client late authentication optional (compatible clients would
signal it as an extension)
- rethink the client late authentication, as was done with KeyUpdate,
to limit the state required on the client side.

Best regards,
Olivier Levillain

* One of these issues is that requiring Client Authentication upon an
applicative request may lead a client to have to write records on a
SSL_read call :
1) client and server complete the handshake
2) client sends a request (SSL_write)
3) server reads the request, decides an authentication is required, and
sends a CR
4) client reads the response (SSL_read), but has first to comply with
the CR (that is write packets) to get the response

This violation of the network layers can be dealt with (and has been,
since Apache allows eactly this kind of flow) but it introduces
complexity in the code, which I belive we should remove altogether : an
application request should not trigger an SSL authentication request.
What was done with KeyUpdate sanitized a similar situation.

---

From: "Kaduk, Ben" <[email-masked]>
Date: Tue, 28 Mar 2017 06:23:33 +0000

On 3/13/17, 12:30, "Sean Turner" <[email-masked]> wrote:

As the price of running the WGLC right during the meeting lead-up, my review comes in at the last minute.

Generally, it is in good shape.  I think I still owe some text about what we aim for and expect to achieve with respect to side channel resistance, though at this point it may be too late to get that text in :(

The following is basically a laundry list of the minor issues; I will send editorial notes under separate cover, probably as a pull request.

It was already mentioned that the “major differences from TLS 1.2” section should not be a changelog, but I agree with that.

Should Figure 4 (“message flow for a zero round trip handshake”) include a “+ early_data” for the server’s flight?  (The legend for Figure 4 also lacks the explanation for the ‘+’ symbol.)

The language on page 30 is perhaps unclear:

   Because TLS 1.3 forbids renegotiation, if a server receives a
   ClientHello at any other time, it MUST terminate the connection.

Is that any TLS server, or just one that has negotiated and is using TLS 1.3?

In the description of legacy_compression_methods on page 31, we make restrictions on “every TLS 1.3 ClientHello”, but do not say how such things are identified.  (Hmm, maybe we also do so elsewhere in the document, too, now that I search for where)  we explicitly define what a client “considered to be attempting to negotiate using this specification (i.e., a TLS 1.3 ClientHEello) on page 87, as supported_versions including 1.3.  Which, is maybe not the most future-proof thing.

The description of version negotiation (to populate ServerHello.version) on page 32 seems to leave undefined what the server should do when receiving a ClientHello that does not contain a supported_versions extension.  (Also, I don’t think “ClientHello.supported_versions extension” is a well-defined syntax.)

When covering the server_random version downgrade sentinels, we do not mention what is to be done when downgrading to TLS 1.0, which I thought was still a permitted version by this spec.

It’s a little odd that we list in enum ExtensionType on page 35 a strict subset of the extensions enumerated in the table on the following pages.

Do we want to add some commentary about the extant SHA1 collisions when we say that {rsa_pkcs1,dsa,ecdsa}_sha1 are only SHOULD NOT?

I’ll note that we define 256 private use ECDHE group code points but only four such FFDHE group code points.  Probably fine, but a bit surprising.

Should we forbid duplicate entries in PreSharedKeyExtension.identities?

Conversely, we might want to explicitly say that duplicate OIDFilter.certificate_extension_oid fields should be expected in OIDFilterExtensions, to enable the case where multiple values must be present.  Or is that supposed to work by concatenating(?) the multiple values’ DER encodings in the certificate_extension_values field?

I’ll call out for Russ’s attention at the end of Section 4.4.3 where we say that “implementations MUST NOT combine external PSKs with certificate-based authentication.”  Is there any reason not to qualify that as some sort of “don’t’ do it until it’s defined”?

Should Alert.level be Alert.legacy_level?

The editors copy has already removed the reference to RFC 4507, which is obsoleted by RFC 5077 (and was not cited anywhere, anyway).

Appendix B has a claim that “values listed as _RESERVED were used in previous versions of TLS and are listed here for completeness”, though that is not exactly true, e.g., for ContentType.invalid_RESERVED(0)

Section C.3 notes that “Certificates should always be verified to ensure proper signing by a trusted Certificate Authority”, which does not use RFC 2119 language, but might be seen as in conflict with opportunistic encryption in some circumstances.  I don’t object to this text, but it seems worth mentioning.

Page 113 still has the “[[NOTE: TLS 1.3 needs a new channel binding definition that has not yet been defined.]]”, which should not make it into the final spec!

-Ben

---

From: Dave Garrett <[email-masked]>
Date: Tue, 28 Mar 2017 16:42:48 -0400

> Should Alert.level be Alert.legacy_level?

Yep. Trivial to fix, so quick PR filed for it.

Dave

---

From: Kyle Nekritz <[email-masked]>
Date: Wed, 29 Mar 2017 03:33:11 +0000

I raised this before in PR #693 (https://www.ietf.org/mail-archive/web/tls/current/msg21600.html).

I'm not sure it makes sense to rename this to legacy while other parts of the document still refer to it. But I'm definitely in favor of deprecating it.

From: TLS <[email-masked]> on behalf of Dave Garrett <[email-masked]>
Sent: Tuesday, March 28, 2017 4:42 PM
To: [email-masked]
Subject: Re: [TLS] WGLC: draft-ietf-tls-tls13-19

Dave

_______________________________________________
TLS mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=l2j4BjkO0Lc3u4CH2z7jPw&m=ix39YzN5D9ZIP69oc6EpeIHky4mBDPr78L-0dRI3acY&s=wDljuAs_X9UuW_4VC-TwYR9TkDPrKiVZz7oRdOmL3aA&e=

---

From: Olivier Levillain <[email-masked]>
Date: Fri, 31 Mar 2017 13:57:15 +0200

Hi,

> - currently, handling client late authentication is mandatory

[...]

> to limit the state required on the client side.

Martin Thomson proposed a PR (thank you) corresponding to the second
point, using a simple extension in the ClientHello :
https://github.com/tlswg/tls13-spec/pull/921/

I believe this proposal is a good trade-off allowing simpler
implementation designs when late client authentication is not needed.

Best regards,
Olivier Levillain

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 31 Mar 2017 07:08:11 -0500

Yes, we discussed this at IETF 98 and had rough consensus. I'll be merging
this PR this
week

-Ekr

---

From: Hubert Kario <[email-masked]>
Date: Fri, 31 Mar 2017 15:40:35 +0200

On Tuesday, 28 March 2017 08:23:33 CEST Kaduk, Ben wrote:
> Do we want to add some commentary about the extant SHA1 collisions when we
> say that {rsa_pkcs1,dsa,ecdsa}_sha1 are only SHOULD NOT?
 
There still are non-insignificant number of Internet facing servers that 
require SHA-1 being advertised for connection to be successful.
SHOULD NOT is a good compromise for it.
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Dr Stephen Henson <[email-masked]>
Date: Fri, 31 Mar 2017 15:12:25 +0100

> which requires more memory.

To me allowing the server to send multiple certificate request messages and the
client being permitted to respond to them in arbitrary order adds quite a bit of
complexity.

Is there a usage scenario for this? Would permitting only one outstanding
Certificate Request be too limiting?

On a related note in 4.6.2:

   Note: Because client authentication may require prompting the user,
   servers MUST be prepared for some delay, including receiving an
   arbitrary number of other messages between sending the
   CertificateRequest and receiving a response.

I'm assuming that once the client has responded with a Certificate message it
MUST send CertificateVerify and Finished afterwards and nothing else is
permissible? That is it can't send application data or respond to other
outstanding CertificateRequest messages?

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 31 Mar 2017 09:20:11 -0500

> Certificate Request be too limiting?

Yeah, with H2 it puts a lot of complexity at the HTTP layer. I think we
already
had consensus to allow this.

> outstanding CertificateRequest messages?

I think that was our intention but I agree the text ended up a bit unclear.
Absent some
argument, i'll update the text to require it.

-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Fri, 31 Mar 2017 11:11:14 -0500

> argument, i'll update the text to require it.

This is a great idea.  I don't think that our code would enforce this
constraint, but I don't really want to see interleaving here.  We
don't have interleaving anywhere else.