Re: [TLS] TLS 1.3 comments

[Ilari Liusvaara <[e-mail]>]

On Mon, Aug 17, 2015 at 06:22:04AM -0400, Yaron Sheffer wrote:
> 
>     Below a long list of comments, generally minor. The document is
>     already very good - we're making great progress!<br>

>       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".

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

(This was proposed a while back).

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

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.

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

Agreed. Authorization failure.

>       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?

>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.

>       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?

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.

>       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.

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.

>       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.

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.

>       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.

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).

>       D.1.2: do we really need to worry about version rollback to
>         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