Hi Dave,
Well, its a terminology draft, so I'll comment on one term
you used below in the hope that helps clarify a bit more of
this:-)
On 06/08/14 04:28, Dave Crocker wrote:
Focusing on a "framework that permits decreasing levels of encryption
protection" or similar language resonates with what I've been reading
about this opportunistic thing. (My own view is that cleartext has no
place within that hierarchy, so some sort of minimum encryption needs to
be described.
Hierarchy isn't the right concept here.
There are different states that might result after some
opportunistic security steps are taken in a protocol.
Those include having fallen back to cleartext, encrypting
with zero, one or both endpoints authenticated and many
variations in terms of how endpoints can be authenticated
(DANE, "traditional" x.509-based PKI, TOFU, etc. etc.).
One could also extend to more than two endpoints but let's
omit that for just now.
There are also interactions between all the above and the
particular protocol we're trying to secure, e.g. IMAP/TLS
is quite different from MTA-MTA with STARTTLS and both
differ from the putative MPLS thing Adrian and I have
sketched out.
Its very important to note that there isn't even a partial
order of the various end states on which we can always
generically agree, never mind a full ordering. For example,
would client or server authentication be "better" or
DANE vs. TOFU? In general, we cannot decide. Its not that
we're being lazy, but in this case your mileage really
will vary in ways we cannot decide in the abstract.
So a hierarchy isn't the right way to think about this.
That's one of the things that makes this tricky to
describe, even after we've all understood and agreed on
what we really want to describe.
However, we do believe that each protocol that uses OS
techniques can be analysed so as to produce a sensible
description of which states are ok, which (if any) are
not ok and hopefully at least a partial ordering of the
end states in terms of preference, or perhaps just in
terms of what gets logged. (That last can be more
powerful than one might expect btw.)
Our history is that we mostly didn't allow for OS, either
in protocol design, nor in implementations, although some
protocols that we did design can already support OS if
the implementations want it, e.g. MTA-MTA SMTP over TLS.
This draft legitimises using OS in future protocols or
in current ones where implementations can play the OS
game. From my POV, doing that is important both when
considering BCP188 issues, but also in terms of overall
improvement in deployability of the security mechanisms
we build into protocols.
Hope that helps,
S.
PS: I'm just back from vacation and won't get to reviewing
the last call comments for a day or two. Even though the
IETF last call is officially done, please do continue to
discuss this. (And thanks for both the content and tenor
of the discussion to date!) When I've reviewed all the
comments, I'll come back to the list with what I think is
the right next step - that could be trying to get some
of the folks who've commented into some form of offlist
huddle for a few more days and then returning with that
text for all to check, but as I say, it'll be a couple
of days until I've caught up.