Subject: [saag] Martin Stiemerling's No Record on draft-dukhovni-opportunistic-security-04: (with COMMENT)

From: "Martin Stiemerling" <[email-masked]>
Date: Tue, 16 Sep 2014 02:37:01 -0700

Martin Stiemerling has entered the following ballot position for
draft-dukhovni-opportunistic-security-04: No Record

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I am not done with my review, but in the meanwhile I have question: 

How does this draft related to the old Better-Than-Nothing Security
(btns) working group [1] and their output?

[1] http://www.ietf.org/wg/concluded/btns.html

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 16 Sep 2014 11:14:38 +0100

Hi Martin,

> http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/

I think its fair to say this LC discussion involved some of the
same protagonists and some of the same arguments.

Hopefully this RFC would short-circuit a part of the debate
that happened back then (*) but more recently in the httpbis WG.
There was also a bit of that debate in chartering tcpinc.

The debate that this ought short-circuit is the part about
the overall legitimacy of the approach. So this draft should
save time, energy and good-will when an OS approach is proposed
for other protocols - that part of the discussion seems to me
at least to be contentious, so that can be a non-trivial saving.

Functionally, I think one could describe the output from BTNS
as following the OS design pattern, but not that successfully.
(The lack of success conclusion being based on the lack of
deployment, it'd probably not be productive to try analyse
the reasons for that further right now - see below.)

Some of those involved in BTNS have been working on another go
at applying the OS approach to IPsec. That work has not yet
been chartered anywhere but we have had a couple of updates
at saag sessions [2] ([2] btw doesn't use the OS term - it
was done while we were still flailing about with imperfect
term selection;-) If that work got sufficient traction to be
chartered, then this draft should help with that, again by
legitimising the design pattern. The discussion as to why
BTNS wasn't successful, and why some proposed new work might
succeed, would of course still need to be had at chartering
time.

Hope that covers it,
Cheers,
S.

[2] https://www.ietf.org/proceedings/89/slides/slides-89-saag-4.pdf

(*) I wasn't involved in BTNS really, other than to watch the
fireworks from the sidelines. From that perspective, I think that
history probably explains some of the difficulty getting agreement
with this draft.

---

From: Richard Barnes <[email-masked]>
Date: Wed, 17 Sep 2014 22:35:17 -0400

> There was also a bit of that debate in chartering tcpinc.

As long as we're clear that the way this RFC would help is to avoid
terminology confusion -- not to imply that OS is necessarily the only or
preferred option.  Because I don't think there's consensus on the latter.

> the reasons for that further right now - see below.)

My understanding is that BTNS ran up against the major hard problem for OS
-- how do you combine it with real, non-opportunistic security?  (Without
enabling downgrade attacks.)  For better or worse, IPsec was built to
incorporate a very robust access control model, and IIRC the main
difficulty for BTNS was figuring out how to integrate unauthenticated
associations with that model.

The same problem exists in other forms for other protocols, and requires
application-layer help.  In the HTTP context, the client can tell whether
to operate in opportunistic mode based on HTTP information, such as the
scheme of the request ("http:" vs. "https:").  Other protocols will need
other mechanisms.

All of which seems to suggest that BTNS-bis is not all that likely to have
better success, as long as it is restricted to operating at the IPsec layer.

--Richard

---

From: Nico Williams <[email-masked]>
Date: Wed, 17 Sep 2014 23:41:44 -0500

[Sorry to butt in.  I'm responding only to the sub-thread about BTNS, a)
to correct the record, b) because the differences and similarities
between the security model in BTNS and the security model in OS that are
relevant here.  I will butt out immediately after.  -Nico]

> > as following the OS design pattern, but not that successfully.

 - BTNS requires the use of ESP/AH IF the peer is discovered to support
   IPsec.

 - BTNS itself provides no other way of adversiting discovering IPsec
   capabilities of peers than attempting to establish SAs.

   (Of course, additional methods of advertisement/discovery are not
   precluded.)

 - BTNS does not crowd out the standard IPsec model, so that if you must
   authenticate a peer, then you must authenticate it.

In a way BTNS is very much like OS, but the focus was different.
Speaking for myself, my focus was getting IPsec channels that could be
used with channel binding.  Completely missing from this picture was the
idea that external systems like DANE could be used to provide server
authentication to mostly anonymous clients, and that this could be used
to "raise the security floor".  But BTNS is not incompatible with OS.
The problem with BTNS is explained below.

> > the reasons for that further right now - see below.)

If there's a perception that we tried this (this == opportunism) with
BTNS and we failed, then the failure needs to be explained.  Here's my
explanation:

BTNS severely exacerbates an active attack weakness in the IPsec
security model that must be addressed via RFC5660 (connection latching)
or Leap-of-Faith/TOFU learnign of peer {IP address, public key}s.  The
latter not being realistic (because unlike SSH, the binding is to
addresses, not names), only the former could get us out of this bind.
Connection latching by and large didn't get implemented.  This is the
root cause of the real BTNS deployment failure.

Why didn't connection latching get implemented?  Because it requires
upper layers like TCP to interact with IPsec.  This means more
kernel-land code in general purpose OSes, and more interfaces between
layers as well as extensions to PFKEY and similar.  Such work is not
exactly portable, thus the effort needed to implement and use BTNS
securely is larger than the effort needed, say, use TLS more.)

> associations with that model.

Your understanding is not correct.  See above.  Particularly worth
noting is that IPsec does NOT really have a "robust" access control
model because IPsec authenticates IP _packets_ (therefore it provides no
integrity protection to _logical packet flows_) and IP _addresses_
(therefore IPsec access controls are inconvenient at the very least,
requiring massive machinery to produce maintain, distribute, and
synchronize large configurations).

RFC5660 is all about extending IPsec to protect logical packet _flows_
from peer identity changes.

E.g., a peer got renumbers, another node took the old IP address, and
both have certs from the same issuer: why should the new node be able to
insert itself into extant packet flows with the old peer?  what if the
new peer DoSed the old peer of the network and the old peer's address
was dynamically allocated?  IPsec says: whatever, keep going, who cares.
Connection latching says: the new peer can't neither get nor inject
packets into those flows.

> scheme of the request ("http:" vs. "https:").  Other protocols will need

IPsec by and large has no such input from applications, thus IPsec can
only be mandatory (by local policy) or opportunistic.  IPsec normally
only had mandatory policy.  BTNS added opportunistic policy.

> better success, as long as it is restricted to operating at the IPsec layer.

BTNS does not need a -bis.  It could use: a) implementation of RFC5660,
b) standardized socket APIs (like Dan McDonald's IP_SEC_OPT) enabling
applications to request/discover BTNS, c) additional APIs that make it
possible to use DANE with _hostnames_ (as opposed to IP addresses, as in
IPsec OE).  (c) would put IPsec on the same level as SMTP w/ TLS + OS.

Supposing we were serious about end-to-end IPsec (as opposed to VPN and
other tunnelling applications) we would insist on having a way to tie
security to hostnames.  With BTNS _my_ vision was to use channel
binding, but DANE is clearly even mo' betta if we want widespread
adoption.

(For example, apps might supply DANE TLSA RR RDATA to TCP via a socket
option.)

Nico
--

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 18 Sep 2014 09:38:31 +0100

Hi Richard,

> preferred option.  Because I don't think there's consensus on the latter.

I don't believe that anyone proposed that OS is "the only or
preferred option" anywhere at all during the discussion. The
lack of consensus for that non-proposal is therefore just fine:-)

S.

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 18 Sep 2014 13:12:35 +0200

Hi Stephen, 

Thanks for reply. 

I wonder , if any reference to btns would be useful, sort of historical evidence, or not. 

Thanks,

  Martin

> On 16.09.2014, at 12:14, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hi Martin,
>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 18 Sep 2014 12:27:02 +0100

> I wonder , if any reference to btns would be useful, sort of historical evidence, or not. 

Mostly "not" I think:-) One of the reasons we ended up with
Viktor's draft was (I think) that folks were somewhat worried
that a bunch of the historic text in Steve Kent's draft [1]
would bog us down in debate/recriminations/whatever.

The stuff Viktor added about starttls [2] is I think enough
of, and a better, demonstration that OS can be useful. And
we don't need to try enumerate all past cases of OS either.
So on balance I'd argue for not adding such.

Cheers,
S.

PS: That said, I do think that the historic text in Steve's
draft would be useful to publish too somehow. I'm less sure
I'd like another LC on this topic soon though;-)

[1] https://tools.ietf.org/html/draft-kent-opportunistic-security
[2]
https://tools.ietf.org/html/draft-dukhovni-opportunistic-security-04#section-4

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 18 Sep 2014 16:43:24 +0200

> So on balance I'd argue for not adding such.

wfm.

> I'd like another LC on this topic soon though;-)

:)

---

From: Joe Touch <[email-masked]>
Date: Thu, 18 Sep 2014 09:25:37 -0700

OS is about "do the best you can". BTNS was named in the same spirit of 
doing "better than nothing", but is just one of many specific mechanisms 
that might apply.

If that's not coming across in the doc, it points to the clarity failure 
of the doc that others have noted. FWIW, I don't think citing specific 
examples does much to explain the notion of OS.

Joe

On 9/18/2014 7:43 AM, Martin Stiemerling wrote:
>>>>> Please refer to
>>>>> http://www.ietf.org/iesg/statement/discuss-criteria.html
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: Joe Touch <[email-masked]>
Date: Thu, 18 Sep 2014 10:36:22 -0700

On 9/17/2014 7:35 PM, Richard Barnes wrote:
> My understanding is that BTNS ran up against the major hard problem for
> OS -- how do you combine it with real, non-opportunistic security? 
> (Without enabling downgrade attacks.) 

I think there is a lot of confusion between BTNS and OS.

AFAICT (and yes, the doc is not clear on this), OS is about using a
spectrum of solutions, one of which may be BTNS.

BTNS was a specific solution that valued the utility of IPsec using
Diffie-Hellman in the absence of identity validation.

OS is not BTNS, but BTNS can be part of OS. That's just my viewpoint,
but if others agree, then that ought to be made clear (and cited) in the
document. I do think that BTNS is a key part of the OS spectrum and
should be cited.

As to why was BTNS not more widely deployed, there are many potential
reasons, but it's difficult to establish a negative.

I agree with Nico that BTNS with connection latching might have had
better uptake, but I don't think that explains why BTNS without
connection latching didn't.

IMO, BTNS was just too early and there was not enough appreciation at
the time for security without identity authentication.

Joe

---

From: Nico Williams <[email-masked]>
Date: Thu, 18 Sep 2014 14:39:09 -0500

> document. I do think that BTNS is a key part of the OS spectrum and

+1

> connection latching didn't.

That's true, BTNS could have been deployed without connection latching,
and it would have added some value where the alternative was cleartext.
BTNS adds much more value with connection latching in the picture
though.

Thinking about how to apply DANE to IPsec it's clear that a simpler
scheme than connection latching get much the same semantics when both
peers have TLSA RRs, but when at least one of the peers is anonymous
it's difficult to see how to get sane security semantics more simply
than with connection latching.

> the time for security without identity authentication.

Agreed.  At the time I thought of, and dismissed in my mind, the use of
DNSSEC: it seemed too early.  But BTNS was just too early (though IMO
connection latching should have been present from day one of moden
IPsec).

Nico
--