Subject: [TLS] TLS 1.3 comments

From: Yaron Sheffer <[email-masked]>
Date: Mon, 17 Aug 2015 06:22:04 -0400

Below a long list of comments, generally minor. The document is
already very good - we're making great progress!

The record length field is limited by encrypted-length+2048.
Shouldn't it be 1024? - "Each AEAD cipher MUST NOT produce an
expansion of greater than 1024 bytes".

6: the definition of session contents should also contain
identities. The client's identity, if authenticated by cert, or
the peers' PSK identity.

"Access denied" alert: the description starts with "a valid
certificate was received", but it may also apply to PSK.

Handshake_failure alert seems to be synonymous with
insufficient_security (and Sec. 6.2.1 proves it...). Can we
clarify the difference, or deprecate one of them?

Typo: "via a certificates".

Server Configuration: how does the client know to whom the
configuration applies? For example if I connected to
"*.example.com" (a wildcard cert) and now I connect to
"srv.example.com", should I use the stored configuration?

6.2.2: typo: has complete.

6.3.2.3.2: it's time we specified that the recipient (in this
case, the server) MUST verify the received ECDHE public key (see
RFC 6989). This is mentioned in Appendix D but only for modular
DH.

6.3.2.4: "identifier" should read "identity".

6.3.4: "Perhaps have a whitelist of which extensions can be
unencrypted and everything else MUST be encrypted." - this
doesn't work, because we might come up in the future with an
extension that needs to be unprotected. Maybe we can say
"SHOULD" instead.

6.3.7: expiration_date: there's no reason to force/assume time
synchronization between client and server. This can just as well
be relative time (number of seconds since negotiation), like
ticket_lifetime_hint.

6.3.10: "If the client does not send any certificates, the
server MAY at its discretion either continue the handshake
without client authentication ... Also, if some aspect of the
certificate chain was unacceptable ... the server MAY at its
discretion either continue the handshake (considering the client
unauthenticated) or send a fatal alert." This is strange. There
is no way for the client to understand that the server considers
it unauthenticated and modify its behavior accordingly. A
warning alert would be appropriate here, even if in general we
don't like warning alerts.

Typo: main-in-the-middle

"Note that using non-anonymous key exchange without actually
verifying the key exchange is essentially equivalent to
anonymous key exchange, and the same precautions apply. " This
is not precisely true, because the other peer may not know that
you're not verifying the exchange, and so it might behave
differently.

D.1.2: do we really need to worry about version rollback to
SSLv2? I suggest to remove this section.

Thanks,

Yaron

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 17 Aug 2015 15:02:46 +0300

On Mon, Aug 17, 2015 at 06:22:04AM -0400, Yaron Sheffer wrote:
>     already very good - we're making great progress!<br>

>         expansion of greater than 1024 bytes".

Actually, I think both should be 256 (256-byte expansion from AEAD
is already quite much).

(This was proposed a while back).

>         identities. The client's identity, if authenticated by cert, or

There is lots more missing as well, like symmetric crypto keys,
TLS-Exporter secret and TLS-Unique value.

IIRC the answer when I brought that up was that the whole thing
should be removed.

>         certificate was received", but it may also apply to PSK.

Agreed. Authorization failure.

>From my reading, the difference would be that if some negotiating
some required algorithm failed because none of the options is supported
at all, it is handshake_failure. If some algorithms would have been
supported but are disabled, it is insufficient_security.

Not sure if that makes any actual sense.

>         "srv.example.com", should I use the stored configuration?

It actually gets more interesting when one has multiple potentially
applicable configurations and needs to tiebreak.

If there is only one config known, not much problem in trying that.

>         RFC 6989). This is mentioned in Appendix D but only for modular

There is actually two kinds of verification:
- Validating received point is on curve.
- Validating that the received point is high-order.

CFRG Curve25519 and Curve448 specify the needed checks here.

As for Weierstrass stuff, some ECC libs have surprising presentations
for infinity (which is order-1) and allow importing invalid points, so
one has to be careful even with h=1.

>         extension that needs to be unprotected. Maybe we can say

The registration procedure is "IETF consensus", so RFC updates: might
not work.

Also, it is unclear if extensions that introduce new messages or
otherwise modify the handshake after EncrpytedExtensions are to be in
ServerHello or EncryptedExtensions.

>         be relative time (number of seconds since negotiation), like

IIRC, the reason why it was that was was publishing configurations off-band.

Also, I don't like that field being 32-bit if it is absolute time (even
if it isn't signed).

>         SSLv2? I suggest to remove this section.

Well, it is not possible to even try to negotiate TLS 1.3 using SSLv2
compat. hello, since that can't transmit extensions, but at least one
extension is REQUIRED in order to successfully negotiate TLS 1.3.

And the second paragraph seems to be about RSA key exchange, which
isn't supported anymore in TLS 1.3.

Yes, the section looks like it could be removed.

But that isn't the only way rollback attacks can occur, also some
clients can be coaxed to downgrade by selectively blocking connections.
Unfortunately the intolerance to TLS 1.3 is so bad that many clients
will likely be willing to perform unauthenticated downgrade to TLS
1.2 (and FALLBACK_SCSV is useless here).

-Ilari

---

From: Hubert Kario <[email-masked]>
Date: Mon, 17 Aug 2015 16:43:41 +0200

> (This was proposed a while back).

I don't think this adds anything while introducing requirement of adding 
additional "if" to implementations that support also TLS1.2 and lower

> Yes, the section looks like it could be removed.

OTOH, TLS1.3 is not a superset of TLS1.2 so we need to think about downgrade 
to TLS1.2. 

> 1.2 (and FALLBACK_SCSV is useless here).

how is it useless?

A server which support at most TLS1.2 that receives a TLS1.2 client hello with 
FALLBACK_SCSV MUST continue the connection with TLS1.2
-- 
Regards,
Hubert Kario
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: Martin Thomson <[email-masked]>
Date: Mon, 17 Aug 2015 10:37:24 -0700

> Actually, I think both should be 256 (256-byte expansion from AEAD

Pull request or it didn't happen ;)

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 17 Aug 2015 12:01:11 -0700

My original mail had some 15 comments, some trivial, some not. Do you 
expect 15 PRs?

Thanks,
	Yaron

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 17 Aug 2015 19:07:16 +0000

On Mon, Aug 17, 2015 at 06:22:04AM -0400, Yaron Sheffer wrote:

>      * Server Configuration: how does the client know to whom the

Clients don't "connect to *.example.com", they connect to a specific
server, one of whose "presented identities" might be "*.example.com".

Since clients don't a priori know which certificates correspond to
which reference identities, they can't apply a configuration to
anything other than the exact peer for which it was obtained.

Section 6.2.2 speaks of "the server", and I think this needs to be
taken literally.  Not some set of servers, but "the server".  Of
course load-balancers might hide multiple servers behind a single
transport end-point, in which case the client may not be able to
distinguish between them, and it is then up to the server administrators
to ensure that any configurations are sufficiently "portable"
between the servers in the pool.

This is similar to the question of when to reuse cached sessions.
Postfix, for example, does not reuse a session established to one
IP address for a multi-homed host, to communicate with "the same"
host on another IP address (which might not in fact be the same
host).  [ Even further, Postfix avoids re-using sessions when the
SMTP conversation prior to STARTTLS shows a different server name
in the EHLO reply. ]

So I think the current language is largely fine, with "the server"
meaning whatever the client uses to identify a single peer as best
it can.

-- 
	Viktor.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 17 Aug 2015 12:30:20 -0700

Expect? No. That you sent an email is already highly useful.

A PR makes feedback even more useful.  For truly trivial stuff, rolling
them up into a single PR is probably even more so.

---

From: Dave Garrett <[email-masked]>
Date: Mon, 17 Aug 2015 20:00:35 -0400

On Monday, August 17, 2015 06:22:04 am Yaron Sheffer wrote:
> The record length field is limited by encrypted-length+2048. Shouldn't it be 1024? - "Each AEAD cipher MUST NOT produce an expansion of greater than 1024 bytes".

See: https://github.com/tlswg/tls13-spec/issues/55

> Handshake_failure alert seems to be synonymous with insufficient_security (and Sec. 6.2.1 proves it...). Can we clarify the difference, or deprecate one of them?

See: https://github.com/tlswg/tls13-spec/pull/201/commits

A PR for the typos would be appreciated. I'd suggest having the typos in a separate PR from any other proposed changes.

Dave

PS
I recommend against citing sections by number. The numbers can change; the sections can change completely. Cite by draft number & section, or preferably via a link to a section in a page. Also note that there are a few different things that can be considered the "latest" draft, so always specify which one to be clear. (e.g. numbered draft, GitHub current draft, PR drafts, WIP branch drafts, etc.)