On Sat, Oct 10, 2015 at 06:46:47PM -0400, Dave Garrett wrote:
> > Unfortunately requirements in the base TLS document end up "set in
> > stone" in software implementations, and then break opportunistic
> > TLS in ways application software can't work around.
>
> I do agree with rewording the text in question to deal with this better,
> but honestly, OE & AE are directly opposed concepts. I'd much rather write
> almost everything assuming the goal is properly authenticated encryption,
> and have a separate section dedicated to opportunistic encryption stating
> that its implementation requires ignoring many of the hard requirements
> TLS has with regard to authentication.
Sorry that works for the UTA BCP, but *cannot* work the TLS protocol
specification. The TLS protocol cannot and SHOULD NOT make any
assumption about the client's security model, which can be:
* PKIX with Web PKI public CAs
* DANE-TA(2) with private CAs trusted via DNS
* DANE-EE(3) (if you like server-side pinning via DNS).
* RFC7250 bare public keys with DANE "3 1 1" bindings.
* RFC7250 bare public keys with some other out-of-band keying
* Trust on first use with leaf certificate pinning.
* GSSAPI with channel binding
* Unauthenticated opportunistic TLS.
* ...
It is not appropriate for this WG to be narrowly focused on just
the first security model, which is certainly important, but not
to the exclusion of the rest.
> Trying to subtlety allow for AE &
> OE in all the same text might give us a more fragile specification where
> accidentally screwing up authentication is easier. OE can be useful, but
> it's the exception, not the rule; giving AE too much wiggle-room could be
> dangerous. (when it's explicitly requested, e.g. TOFU with raw public
> keys, that's a different discussion)
There is no subtlety getting in the way of not deprecating trust
in SHA-1, with a tiny bit of care it can be done generally without
breaking any of the use cases.
If the base protocol is bifurcated into many different use-cases,
implementations won't handle all the cases correctly.
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.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
