Subject: Re: [tcpinc] [saag] Anyone up to review draft-rescorla-tcpinc-tls-option-04 in the next week or so?

From: Watson Ladd <[email-masked]>
Date: Tue, 6 Oct 2015 17:42:34 -0400

I have two major comments. The draft recapitulates bits and pieces of
the TLS 1.3 draft, but it's not clear why this is done instead of
citing that draft. I also don't understand what it means to support a
bare public key: what exactly is to be done with this key, how is it
distinguished from the case of X509 certificate, is there are RFC
already defining this feature in TLS 1.2, etc. Similar questions apply
to TOFU.

There is also an interesting consideration: suppose a server
implements this draft by signaling to applications they should
negotiate TLS, and a client is on a system which just does it. The
client is unmodified, but itself wishes to use TLS by sending a
ClientHello etc. Now the two try to connect, and the server receives a
ClientHello it wasn't expecting.

Sincerely,
Watson Ladd

On Tue, Oct 6, 2015 at 5:24 PM, Stephen Farrell
<[email-masked]> wrote:
>
> Hiya,
>
> The TCPINC WG have been having a hard time in picking an approach
> to take with two reasonable proposals on the table. [1,2]
>
> The tcpcrypt draft [2] has been around for a while and has had a
> good bit of review so its content is fairly well understood.
>
> The idea of the TLS approach has also been around for a while, but
> the nitty-gritty details are really only documented in [1] in
> the current revision.
>
> The chair of TCPINC intends to try again to poll the WG about
> adopting drafts in the relatively near future and has asked if we
> can get some security folks to review [1] in the next week or so.
>
> What's being asked for here is a review of the content of [1] and
> *not an analysis of [1] vs. [2]*. The WG have probably seen all of
> the arguments there already, so the ask now is really just to get
> some more eyeballs on the content of [1] before the WG consider
> adopting a draft (again;-).
>
> So, if one or two of you could please do a review of [1] in the
> next week or so and post that to the TCPINC mailing list (which
> believe it or not is [email-masked]:-), that'd be great. If you
> know TLS (esp the ongoing work on TLS1.3) and TCP it ought not be
> much work to do that.
>
> Aside from that, fresh voices or arguments in the [1] vs. [2] debate
> are of course also always welcome on the WG list, but please do
> check the WG archive to see if an argument is really fresh - most of
> the pros and cons have already been aired I think.
>
> Thanks in advance,
> S.
>
> [1] https://tools.ietf.org/html/draft-rescorla-tcpinc-tls-option-04
> [2] https://tools.ietf.org/html/draft-bittau-tcpinc-tcpcrypt-03
>
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 7 Oct 2015 10:38:27 +0200

On Tue, Oct 6, 2015 at 11:42 PM, Watson Ladd <[email-masked]> wrote:

> citing that draft.

I was explicitly asked to by the WG. Personally, I agree with you that it
would
be better to cite the TLS 1.3 draft.

> I also don't understand what it means to support a
> already defining this feature in TLS 1.2, etc.

Yes. It's in RFC 7250. I'm just citing that.

> Similar questions apply

I don't think the

> ClientHello it wasn't expecting.

I'm not sure I follow the use case, but if I understand correctly, generally
it's not safe to send ClientHello to people who aren't expecting it.

-Ekr

Sincerely,
> Tcpinc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpinc
>

---

From: Stephen Kent <[email-masked]>
Date: Thu, 8 Oct 2015 17:03:13 -0400

Watson,

> already defining this feature in TLS 1.2, etc. Similar questions apply
The phrase "bare public key" (or raw public key) refers to a public key
not embedded in a cert. The term has been used in several IPsec RFCs, 
e.g., 5386
and 6701. The  intent is to define a standard way to convey a public key
w/o any implied authentication. Are you asking for additional clarification
for how such keys are used in 1.3?

You can look at RFCs 7435 and 7469 for discussions of TOFU.

I have not read TLS 1.3 yet, but I would anticipate that the two cases 
you cite
are explicitly intended to accommodate non-cert based key management, 
e.g., in support
of OS.

Steve

---

From: Watson Ladd <[email-masked]>
Date: Thu, 8 Oct 2015 17:14:20 -0400

On Thu, Oct 8, 2015 at 5:03 PM, Stephen Kent <[email-masked]> wrote:
> not embedded in a cert. The term has been used in several IPsec RFCs, e.g.,
> 5386

Then the sentence containing that phrase should say as in RFC wxyz.

> You can look at RFCs 7435 and 7469 for discussions of TOFU.

I know what TOFU is, but are we going to require host keys to remain
the same eternally to support it? This implication should be drawn
out. Likewise, are we going to disconnect when keys change, or require
a signal to the application, etc.

>
> I have not read TLS 1.3 yet, but I would anticipate that the two cases you
> cite
> are explicitly intended to accommodate non-cert based key management, e.g.,
> in support
> of OS.
>
> Steve
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 9 Oct 2015 03:32:41 +0200

On Thu, Oct 8, 2015 at 11:14 PM, Watson Ladd <[email-masked]> wrote:

> e.g.,

I did try to do this. The current text says:

"The client MUST also include a ServerCertTypeExtension containing
   type "Raw Public Key" [RFC7250], "

And then later
"The server's certificate.  If the client offered a "Raw Public
      Key" type in ServerCertTypeExtension this message SHALL contain a
      SubjectPublicKeyInfo value for the server's key as specified in
      [RFC7250]."

But maybe it's not explicit enough. I'll try to make it clearer in a future
version. If you have a wording suggestion, that might help.

> a signal to the application, etc

This is a good question. I don't really have an answer to this, actually.
Generally, TCPINC is intended to work in an unauthenticated setting
with authentication left out of scope. At present, as defined in TCP-ENO,
there is a "session id" which you can bind externally, but there's no
definition of how, and this represents another option for something
you could bind externally.

I wonder if the WG needs to have some non-normative discussion about
ways to bootstrap up from unauthenticated modes to authentication.

-Ekr

> you
> e.g.,

---

From: Stephen Kent <[email-masked]>
Date: Fri, 9 Oct 2015 17:03:15 -0400

Watson,

> Then the sentence containing that phrase should say as in RFC wxyz.
agreed, a cite would be appropriate.
> a signal to the application, etc.
Unless TOFU is the only option (which doesn't seem to be the case based
on your comments), then EKR is not requiring host keys to be static,
just offering another option to raw public keys.

Steve

---

From: David Mazieres <[email-masked]>
Date: Sun, 18 Oct 2015 11:33:46 -0700

> ways to bootstrap up from unauthenticated modes to authentication.

I think the informational API document should include examples of this.
We made a preliminary stab at it here:

        https://datatracker.ietf.org/doc/draft-bittau-tcpinc-api/

Have a look at section 4.

David