On Thu, Oct 8, 2015 at 11:14 PM, Watson Ladd <watsonbl...@gmail.com> wrote:
> On Thu, Oct 8, 2015 at 5:03 PM, Stephen Kent <k...@bbn.com> wrote:
> > Watson,
> >
> >> 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.
> >
> > 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?
>
> Then the sentence containing that phrase should say as in RFC wxyz.
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.
> >
> > 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
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
>
>
> > 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
> >
> >
> > _______________________________________________
> > Tcpinc mailing list
> > Tcpinc@ietf.org
> > https://www.ietf.org/mailman/listinfo/tcpinc
>
>
>
> --
> "Man is born free, but everywhere he is in chains".
> --Rousseau.
>
> _______________________________________________
> Tcpinc mailing list
> Tcpinc@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpinc
>
_______________________________________________
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcpinc
