Subject: [tcpinc] A few nits about draft-rescorla-tcpinc-tls-option-04

From: Yoav Nir <[email-masked]>
Date: Sun, 18 Oct 2015 18:59:50 +0300

Hi

Two things that bothered me that I think have not been mentioned by either Mirja or David:

Section 2 says: "If the TLS handshake fails for non-cryptographic reasons … endpoints SHOULD behave as if the the TCP-TLS option was not present.”
I’m missing what counts as “cryptographic” vs not. So there is one example: no matching ciphers, but we need a bit more: What about an unsupported public key on the server? What about an invalid signature? What about a bad Finished message? What about an unrecognized record type? An unrecognized handshake message?

Second thing I’m missing is about how we get from the state of negotiating TLS to the state of behaving as if the TCP-TLS option was not present. Obviously with a fatal error (or “cryptographic reason”) the side that detected the failure closes the TCP connection. That’s the easy part. But what if we have a non-fatal (in the sense of tcpinc) issue? Does the detecting side send an alert? Does the other side begin transmitting plaintext immediately following the alert? 

Suppose the Client processes the Server’s ServerHello and is not happy (maybe there’s a missing extension). It sends an Alert, but the server is still sending the other messages (key share, How do we know at which point the server can abort sending records and start sending plaintext? I think the synchronization mechanism should be explained.

HTH

Yoav

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 18 Oct 2015 16:59:13 -0700

On Sun, Oct 18, 2015 at 8:59 AM, Yoav Nir <[email-masked]> wrote:

> Section 2 says: "If the TLS handshake fails for non-cryptographic reasons
> … endpoints SHOULD behave as if the the TCP-TLS option was not present.”
> I’m missing what counts as “cryptographic” vs not. So there is one
> example: no matching ciphers, but we need a bit more: What about an
> unsupported public key on the server? What about an invalid signature? What
> about a bad Finished message? What about an unrecognized record type? An
> unrecognized handshake message?
>
> Second thing I’m missing is about how we get from the state of negotiating
> TLS to the state of behaving as if the TCP-TLS option was not present.
> Obviously with a fatal error (or “cryptographic reason”) the side that
> detected the failure closes the TCP connection. That’s the easy part. But
> what if we have a non-fatal (in the sense of tcpinc) issue? Does the
> detecting side send an alert? Does the other side begin transmitting
> plaintext immediately following the alert?
>
> Suppose the Client processes the Server’s ServerHello and is not happy
> (maybe there’s a missing extension). It sends an Alert, but the server is
> still sending the other messages (key share, How do we know at which point
> the server can abort sending records and start sending plaintext? I think
> the synchronization mechanism should be explained.
>

Yeah, I am starting to think I was getting too clever here and it would be
better
to just say "tear down the connection"

-Ekr

> HTH
>
> Yoav
>
>
> _______________________________________________
> Tcpinc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpinc

---

From: Martin Thomson <[email-masked]>
Date: Sun, 18 Oct 2015 20:24:22 -0700

> to just say "tear down the connection"

I can't think of any situation in which a compliant, valid ServerHello
would induce that behaviour.  It would have to be busted somehow, I
guess.

---

From: Yoav Nir <[email-masked]>
Date: Mon, 19 Oct 2015 07:31:32 +0300

> On 19 Oct 2015, at 6:24 AM, Martin Thomson <[email-masked]> wrote:
> 

I was thinking some extension missing from the ServerHello that the client isn’t willing to do without, but I can’t think of any that makes sense. A ServerKeyExchange might have a key or a signature that fails some standard. I guess the “western” client with the GOST server is solved by the server returning an alert instead of a ServerHello.  In this case they could continue with the connection but it’s still a matter of classifying all the fatal vs non-fatal conditions. That and coming up with an alternate term that does not confuse with the fatal and non-fatal alerts of TLS.

Yoav

---

From: Martin Thomson <[email-masked]>
Date: Sun, 18 Oct 2015 21:49:39 -0700

On Oct 18, 2015 9:31 PM, "Yoav Nir" <[email-masked]> wrote:
> I was thinking some extension missing from the ServerHello that the
client isn’t willing to do without, but I can’t think of any that makes
sense. A ServerKeyExchange might have a key or a signature that fails some
standard. I guess the “western” client with the GOST server is solved by
the server returning an alert instead of a ServerHello.  In this case they
could continue with the connection but it’s still a matter of classifying
all the fatal vs non-fatal conditions. That and coming up with an alternate
term that does not confuse with the fatal and non-fatal alerts of TLS.

My point was that there would be mandatory to use cipher suites for tcpinc,
thereby eliminating that sort of error scenario. If you wanted to negotiate
something else, like GOST, that would have to be mutually supported,
otherwise you would always have a good fallback that should work. The
handshake would never fall in that case, though it would be impossible to
build an implementation that relied on "special" ciphers only (in other
words, that would not be tcpinc and using the tcpusetls tcpeno option would
not be valid for such an implementation).