On Sat, Oct 10, 2015 at 11:00:30PM -0400, Dave Garrett wrote:
> On Saturday, October 10, 2015 10:35:16 pm Viktor Dukhovni wrote:
> > This is not difficult, it just requires not forgetting that there's
> > more than one way to do (or not do) authentication, and that the
> > TLS protocol needs to remain largely agnostic of the authentication
> > model. Just deliver the available credentials to the peer, and
> > let the peer decide what to do.
>
> It's the "or not do" that's the issue, not the other ways to do
> authentication that I'm concerned about.
Concern is appropriate and healthy, and nevertheless the requirement
to not focus too narrowly remains. For example a client doing
GSSAPI with channel-binding and ignoring TLS certificates is
essentially opportunistic viewed narrowly at the TLS layer, since
it may well accept (and ignore) whatever certificate chain is sent
its way.
> As I said, it looks like we can word this properly in a way that works
> for everyone. I just feel like the best way to cover the OE case fully is
> to address it in a separate section, explicitly, rather than (just) tweak
> wording to accommodate it.
Separate (and thus possibly conflicting) language only as a last
resort when a single specification is simply not possible. Most
of TLS is trust model agnostic, so these differences should not
matter in most or perhaps the entire specification.
> Even TOFU is more straightforward than OE, because at least with that it
> always follows basically the same pattern.
Not when TOFU pins just the public key in the leaf cert. Nothing
about the chain is then relevant, and the same SHA-1 questions are
out of scope.
> OE requires you take what would normally be a blatant catastrophic error,
> but wave a wand and say it's OK for this separate use case. That may be
> true, but that doesn't make it any less of a blatant catastrophic error
> when that's not the case. I'm worried about having these not be completely
> distinct for the same reason you don't put a self-destruct button next to
> a light switch, no matter how well labeled. ;)
TLS is silent on the trust model. It makes Web PKI, DANE, TOFU
and OS/OE all equally possible. The peer gets the TLS credentials,
the rest is up to the peer.
> Also, I want the spec to anticipate some peers being incredibly stupid
> and avoid making it easy to mess things up.
Web PKI authentication is specified in other IETF specifications
(RFC5280, RFC6125, ...). TLS just sends the rockets up, and it is
not the job of TLS to care where they come down. :-)
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
