Subject: Re: [saag] OS features/requirements analysis

From: Stephen Kent <[email-masked]>
Date: Fri, 18 Apr 2014 20:11:52 -0400

I completed a point-by-point response to Viktor's message, but the 
result is very
long and probably not something most folks want to read. So, I'm posting 
a reply that
tries to focus the discussion, and provides only summary responses to 
Viktor.

If we're to make progress, a good approach is to review the 
criteria/features and
rationales I offered and respond to each one. The response could be OK 
for both,
a proposed rewording of the criteria/feature, possibly with comments re 
the rational,
or a NO, with a thorough explanation of why the cited rationale is off 
base.

Viktor's message repeatedly said my characterization of OS was too 
narrow, but failed to
cite specific issues. He also repeatedly cited just one example of what 
OS "MUST"
encompass, which just happens to be his I-D in DANE. To me, this 
approach makes his view
of OS seem to be narrow.

I think OS should encompass a range of protocols, including TLS 1.3 
(based on the goals
set forth by EKR), maybe TCPcrypt (still in WG charter stage), a variant 
of IPsec (maybe
what Paul or Yoav are proposing), etc. Despite assertions to the 
contrary, I have never
suggested that OS should be defined in a way such that only one protocol 
meets the criteria.

I do believe that we can craft a good, broad definition of OS, but I 
reject the notion
that OS needs to be so broad that nothing is excluded. Such a definition 
seems worthless
to me, unless we're looking to create a "brand."

I do believe Viktor has identified a couple points where there is real 
disagreement, and
thus the IETF, startinfg with SAAG,  has to decide what it wants. The 
STRINT workshop
breakout session participants were convinced that a human user should 
not (MUST NOT?)
be informed about the invocation of OS, nor its failure to achieve its 
basic goal
(an encrypted session) or the optional goals of an authenticated session 
or MiTM exclusion.
This is a legitimate tipic for  discussion. Maybe that statement should 
be tempered to
refer to human users (vs. apps w.o such users) or maybe it should be 
stated as a SHOULD,
vs. a MUST. But Viktor is, IMHO, out of line, when he insists that a 
specific set of
OS features MUST be included/excluded. (A lot of security experts and 
IETF leaders
participated in the breakout session and Viktor has no standing to 
dismiss their
views peremptorily.)

There were several inconsistent aspects of Viktor's comments that merit 
responses.
For example, he agreed that OS is not an app protocol, but then 
questioned how a
peer might not support it. Need we discuss the many examples of peer not 
supporting
the same version of TLS as an obvious counterexample? His 
characterization of
"mis-configuration" (in response to my question) was:

    Misconfigured means unable to speak the application protocol
    correctly, which includes, as a special case, unable to deliver on
    the advertised security parameters.

If security parameters are mandatory to implement, then an instance of a 
protocol
that does not support the parameters is non-compliant, not 
mis-configured. If security
parameters are not MTI, then it's also not a config error, it's an 
incompatibility due
to one entity requesting an optional feature that is not supported by 
the other. I
mention this because it shows that terms being bandied by Viktor about 
are not well
defined and represent a very narrow perspective.

Viktor also explained what he meant by "discovered", in response to my 
question:

    Discovered, means dynamically determined via interaction with
    external information sources.

This does not indicate which of the words used are central to the 
definition.
Is "dynamic" a critical feature, is the use of an "external" source 
important, ...?

    Opportunistic here means that authentication applies when the
    relevant capabilities are discovered.

What if a protocol works by sending credentials over an encrypted channel
to effect authentication, as TLS 1.3 may do?  That doesn't appear to be
discovery based on Viktor's definition, yet it seems very reasonable to me.

I mention these examples because Viktor seems to revert to his one 
favorite example,
his DANE-enabled TLS for SMTP I-D, and thus his explanations of ambiguous
terms appear to be very narrow. This is in  contrast to his complaint 
that my
criteria are too narrow, without citing specific text to support this 
assertion.

The anti-PM statement that Stephen Farrell created, and that will soon 
become an RFC,
seems to identify the primary goal of our efforts as developing 
protocols that remove
impediments to very widespread use of encryption, with or without 
authentication. So,
Viktor and I disagree on whether this provides us with a primary focus 
for the OS
definition, based on the IESG-approved doc. I suggest Stephen needs to 
weigh in on this
issue.

In his messages on Wednesday and Thursday, Viktor attributes specific 
mindsets to
STRINT attendees, and uses his perceptions to justify dismissing the 
consensus of
the breakout session in question. This is the highest form of hubris. 
Nobody should
presume to know what others are thinking when they reach a conclusion, 
and for someone
who didn't even attend the workshop to do so is absurd (and insulting).

I suggest that Viktor, and others, address the suggested OS 
criteria/features and
rationales as a constructive way to progress this work.

I ask that both Sec ADs, and others who participated in the breakout 
session, comment
on the criteria and rationale, both in terms of whether I accurately 
conveyed the
sense of the session, and whether they still support the criteria.

I'm off on vacation now. When I return, I'll make changes to the OS I-D 
based on
directions I receive from the Sec ADs, since they are the nominal chairs 
of SAAG.

Steve

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 19 Apr 2014 03:02:51 +0000

On Fri, Apr 18, 2014 at 08:11:52PM -0400, Stephen Kent wrote:

> criteria/features and rationales I offered and respond to each one.
> The response could be OK for both, a proposed rewording of the
> criteria/feature, possibly with comments re the rationale,
> or a NO, with a thorough explanation of why the cited rationale is off base.

That's fine, but this leaves no room for higher level structural
feedback, such as an over-arching definition of O/S as an approach
to communications security in terms of the overall approach rather
than specific behavioural features.

Such an over-arching definition would then make it possible to
evaluate the specific proposed behaviours in light of a unifying
set of principles.

The key proposal that you seem to be resisting is that "opportunistic
security" is a broader term, that should cover more than just the
core STRINT response to pervasive monitoring.  My I-D is just one
example of the need for a more expansive term.

> Viktor's message repeatedly said my characterization of OS was too narrow,
> but failed to cite specific issues.

The current language presumes that opportunistic security is
necessarily a silent best-effort upgrade from cleartext, and that
all failures to do better are silently ignored, and any success to
do better is not signaled to the user as better security than
cleartext.

The requirement to fail silently was highlighted as a problem a
number of times.  Likewise the requirement to not perform real-time
MiTM detection, and so on.

> He also repeatedly cited just one example of what OS "MUST"
> encompass, which just happens to be his I-D in DANE. To me, this approach
> makes his view of OS seem to be narrow.

Sorry, arguing for an increased scope of the definition, is not
a "narrow" view no matter how one might try to spin it.

> I think OS should encompass a range of protocols, including TLS 1.3 (based
> on the goals set forth by EKR), maybe TCPcrypt (still in WG charter stage),
> a variant of IPsec (maybe what Paul or Yoav are proposing), etc.

Indeed, but the specific protocols are not the point.  The point
is opportunistic behaviour:

    - Interoperate with the broad base of installed peers, at whatever
      least common denominator security level is applicable.  (The
      universal interoperability approach).  That is don't set the
      bar too high.

    - That said, raise the bar as high as possible on a case by case basis,
      based on the capabilities of the peer.  Sometimes that includes
      mandatory authentication, if suitable parameters are securely
      published (and thus discovered) for the peer.

    - Encrypt whenever possible, authenticate when a downgrade-resistant
      mechanism is enabled by the application that makes it possible to know
      when and how to do so.

And in fact nothing about TLS 1.[0123] is fundamentally "opportunistic
security" or not, just like nother AES-256-CBC nor SHA2-256 are neither
"opportunistic" nor not "opportunistic security".

It is how applications *use* TLS that makes the application behaviour
meet a definition of "opportunistic security".

> I do believe that we can craft a good, broad definition of OS, but I reject
> the notion
> that OS needs to be so broad that nothing is excluded.

Do not exclude opportunistic security protocols, such as "opportunistic
DANE TLS", which meets the above reasonable high level criteria
for what it means to be "opportunistic security".

Once the big picture is in place, the specific behaviours you list
can be tweaked to refine flesh out the various specific properties
one might want from opportunistic protocols.

> Such a definition seems worthless to me, unless we're looking to create
> a "brand."

You've succeeded in knocking down a straw-man unrelated to the points
raised in my objections.  I agree that the straw-man is down.
> 
> The STRINT workshop breakout session participants were convinced that a
> human user should not (MUST NOT?) be informed about the invocation of OS,

They were not asked to define "opportunistic security", which is
not purely a response to pervasive monitoring.  Rather "opportunistic
security" is a way of building security into protocols that that
emphasizes interoperability first, and as much security as reasonably
possible second.  This means broad deployment first and foremost,
and gradual herd immunity as peer capabilities improve.

> nor its failure to achieve its basic goal (an encrypted session) or the
> optional goals of an authenticated session or MiTM exclusion.  This is a
> legitimate topic for  discussion. Maybe that statement should be tempered
> to refer to human users (vs. apps w.o such users) or maybe it should be
> stated as a SHOULD, vs. a MUST.

The question is I think moot.  Why should "opportunistic security"
dictate a user interface.  That's for application developers to
decide in the context of the principles "interoperate first" be
"as secure as possible".  If low security with some peers is normal,
perhaps indeed nothing to make a fuss about.  If on the other hand,
with some peers more security is expected and not available, perhaps
a user notice of some kind is right.  Or when strong security is
available, perhaps let the user know, ...

Why should STRINT, you or I tell application's whose threat model
we've not seen how to interact with a user?

> But Viktor is, IMHO, out of line, when he
> insists that a specific set of OS features MUST be included/excluded.

Not MUST be included, rather must not be excluded!  The definition
need not specifically endorse or even mention opportunistic DANE
TLS, but should not be so narrow as to exclude it.  Again I contend
(as you claim to agree) that we're defining an umbrella term for
a set of current and future protocols that share a common core of
principles.  Let's clearly state those principles, list examples
of properties that might be shared by protocols that share the
principles, ... but not make the definition to narrow.

> (A lot of security experts and IETF leaders participated in the breakout
> session and Viktor has no standing to dismiss their views peremptorily.)

Now that we're squarely ad-hominem:

I have at least as much standing as anyone else, present at STRINT
or not.  I've been implementing and operating (as postmaster of a
large site with many TLS peer relationships) opportunistic security
for over a decade.  The non-SMTP world is just starting to play
catch-up.

I've been shipping code that does opportunistic security for nearly
a decade, and helped Microsoft design TLS support for Exchange in
2007.  The evolution of opportunistic TLS in Postfix to add DANE
support is just the most recent icing on the cake.  I am not just
an I-D author with a spec nobody will implement.

The opportunistic DANE TLS protocol for SMTP is implemented in a
shipping product and is planned to also be implemented in Exim, I
and am working with the OpenSSL team to implement DANE support in
the OpenSSL toolkit and expect to bring other MTAs on board over
the next few years.  The protocol is opportunistic security with
scalable downgrade resistance, because lots of SMTP users want
stronger than mere passive eavesdropping resistance, but have not
had any good options to get there in a scalable way.

How exactly is using DANE TLSA when available, and otherwise
falling back to unauthenticated STARTTLS, and failing even that
to cleartext, so that mail delivery proceeds at the best available
security level, NOT "opportunistic security".

Just because STRINT did not consider this type of protocol does
not mean it magically goes away.

I do know more about opportunistic security than most of the authors
of papers submitted to STRINT, which in at least some cases read
like opportunistic job security ("publish or perish").  I admit I
was not at the break-out session, and I'll take your word as
sufficient evidence that the discussion there was better grounded
in deploying real world systems.  Be that as it may, just because
the break-out focused on one aspect of opportunistic security to
address one problem does not mean that everything else is out of
scope.

-- 
	Viktor.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 25 Apr 2014 18:41:31 +0100

(Sorry that this mail was slow coming, I've been away/offline
for a few days but I wanted to respond to one part of this
exchange. I'll follow up later with what I think about the
technical issues.)

On 04/19/2014 04:02 AM, Viktor Dukhovni wrote:
> or not.  

Steve - Viktor is entirely correct here and your statement
about him not having "standing" is really out of order, as
you should know well, having as much experience in the IETF
as you do.

>> I'm off on vacation now. When I return, I'll make changes
>> to the OS I-D based on directions I receive from the Sec ADs,
>> since they are the nominal chairs of SAAG.

So I hope you had a good vacation, and will have the good
grace to retract the "no standing" statement above on your
return.

And I don't want you to do edits based on AD "direction" nor
based on any other argument-from-authority but rather based
on the consensus of the list. That gets much harder to evaluate
if people are put off contributing by the kind of personal
attack above, so I really hope that you can see and acknowledge
that you were out of line there and we can move on to getting
the right text into the I-D and then get that to be an RFC.

Thanks,
Stephen.

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 27 Apr 2014 01:18:16 +0100

Hi Steve,

Just trying to give my answers to questions asked. I hope
others do too. I'll send a separate message with my
comments on the -01 draft and a bit of suggested text.

On 19/04/14 01:11, Stephen Kent wrote:
> (based on the goals set forth by EKR), maybe TCPcrypt (still in WG
> charter stage), a variant of IPsec (maybe what Paul or Yoav are
> proposing), etc. Despite assertions to the contrary, I have never 
> suggested that OS should be defined in a way such that only one
> protocol meets the criteria.

Good. On that I think we're all agreed.

> reject the notion that OS needs to be so broad that nothing is
> excluded. Such a definition seems worthless to me, unless we're
> looking to create a "brand."

That's fair. Of course it doesn't mean we won't all argue
about the definition. Most people on here are clever enough
to find a way to argue about such things for about as long
as they want to continue arguing:-)

> 
> I do believe Viktor has identified a couple points where there is
> real disagreement, and thus the IETF, startinfg with SAAG,  has to
> decide what it wants. The STRINT workshop breakout session
> participants were convinced that a human user should not (MUST NOT?) 
> be informed about the invocation of OS, nor its failure to achieve
> its basic goal (an encrypted session) or the optional goals of an
> authenticated session or MiTM exclusion. This is a legitimate tipic
> for  discussion. Maybe that statement should be tempered to refer to
> human users (vs. apps w.o such users) or maybe it should be stated as
> a SHOULD, vs. a MUST.

I think that we should only refer to human users when we really have
to, and should otherwise always talk about what BGP calls protocol
speakers. (But not use BGP terminology.)

As for the should vs must in the above, I think should is right - in
general "OS should not result in user visible signals" seems about
right.

> Viktor also explained what he meant by "discovered", in response to
> my question:
> 
> definition. Is "dynamic" a critical feature, is the use of an
> "external" source important, ...?
> 

Personally, I don't see any significant point in the above so
I must be missing it. (Or maybe that part is just a result of
you two arguing? Not sure.)

FWIW, I don't think the terms dynamic or external or discover
are needed in how we define OS.

> The anti-PM statement that Stephen Farrell created, and that will
> soon become an RFC, seems to identify the primary goal of our efforts
> as developing protocols that remove impediments to very widespread
> use of encryption, with or without authentication. So, Viktor and I
> disagree on whether this provides us with a primary focus for the OS 
> definition, based on the IESG-approved doc. I suggest Stephen needs
> to weigh in on this issue.

Sure. That I can do. I think that PM is the main motivator for
what's getting people moving. However in what we do we should
be aiming for more than just countering PM. As the title of
STRINT implied we want to strengthen the Internet.

So I think of PM as the motivator, but OS as being more broadly
applicable. I don't think the only goal of OS is to counter PM.
Another one, for me, is to ease deployment of crypto so that it
spreads easier/sooner/more.

> session, comment on the criteria and rationale, both in terms of
> whether I accurately conveyed the sense of the session, and whether
> they still support the criteria.

I think your characterisation is quite accurate but I don't
think that that session resulted in quite such certainty or
as precise an agreement as you seem to imply. (Mind you I had
to leave early so I might not be the best person to ask.)

Cheers,
S.