Subject: [perpass] Violating end-to-end principle: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 14 Jan 2014 12:23:52 -0000

> > >It helps against some attacks, but it doesn't help for others, right?
> > >After all, if you are a US national, you might not trust that the
> > >Chinese Telecom won't pass your traffic to the MSS.  (Or if you are a
> > >German national, that AT&T won't decrypto your traffic and then pass
> > >it off to the NSA...)
> > yep. IPsec, under the control of a subscriber, offers more protection,
> > in princple.
> 
> Or put another way, MPLS-mediated encryption violates the end-to-end
> principle.  It also allows ISP's to violate net neutrality principles
> as well (i.e., by allowing them to do deep packet inspection and then
> prioritizing some traffic over others).

Two things here (probably wandering into a minefield, but that's my ball that
rolled in):

1. "Allows" the ISP to do DPI? Nothing allows DPI apart from regulators, morals,
or encryption of the pieces that might be deeply inspected.
You might as well say that not shooting elephants allows ISPs to do DPI!
So, I think what you are saying is that not doing IPsec on your (IP) traffic
allows the ISP to do DPI.
But doing MPLS encryption also stops transit nodes from doing DPI, but it does
not stop edge (i.e., MPLS end) nodes from doing DPI.
In some deployments (carrier's carrier, MPLS-based enterprise over ISP) the
traffic may already be MPLS, and so MPLS encryption might be what is available.

2. I think the end-to-end principle may already have been somewhat diluted by
the introduction of edges, and the deployment of tunnels. I am guessing that you
mean that the responsibility for securing traffic lies with the
originator/consumer of the traffic. And that is largely fine, but again runs
into VPN type discussions.

Adrian

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 16 Jan 2014 09:57:07 -0500

> into VPN type discussions.

People should read the end-to-end paper before they recite it as holy lore.

End to end is an argument about the consequences of where a design places
complexity. It only considers the end and the center of the network. The
edge is not really acknowledged as an option because it didn't exist when
the paper was written.

Mail has not been end-to-end for at least 20 years. It turned into an
end-to-edge-to-end protocol in the mid 90s and it has been an edge-to-edge
affair since SUBMIT and IMAP became the norm.

The end to end argument is useful but end-to-end ideology is positively
harmful.

End to end ideology in security is particularly harmful because there are
some security controls that are simply not compatible with end-to-end
approaches. You cannot protect against traffic or meta-data analysis
end-to-end.

Rather than contrast S/MIME and PGP being 'end-to-end' protocols against
STARTTLS being transport, it is rather more useful to recognize that S/MIME
and PGP are data level security rather than transport layer.

S/MIME provides end-to-end security but not metadata security. But people
seem to have largely missed the fact that S/MIME is actually capable of
providing data level security as a superset of end-to-end.

Why don't Word and Excel etc. just save all their documents in encrypted
CMS envelopes by default? Shouldn't this be a priority now we are moving to
the cloud?

-- 
Website: http://hallambaker.com/

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Thu, 16 Jan 2014 11:38:50 -0500

On 1/16/14, 9:57 AM, Phillip Hallam-Baker wrote:
> Rather than contrast S/MIME and PGP being 'end-to-end' protocols
> against STARTTLS being transport, it is rather more useful to
> recognize that S/MIME and PGP are data level security rather than
> transport layer.

I like how the recent Barnes et al. draft refers to this as "object
encryption." best, joe

---

From: Theodore Ts'o <[email-masked]>
Date: Thu, 16 Jan 2014 14:23:20 -0500

> approaches. You cannot protect against traffic or meta-data analysis

That may be true, but the alternative of edge-to-edge security is even
worse.  Edge-to-edge security also doesn't protect against traffic or
meta-data analysis, and upon receipt of a National Security Letter to
your IMAP provider, doesn't protect the contents of your e-mail,
either.

So I don't see how claiming that striving for end-to-end security is
"harmful".

Best,

		    	     	     	     - Ted

---

From: Dave Crocker <[email-masked]>
Date: Thu, 16 Jan 2014 12:28:23 -0800

> I like how the recent Barnes et al. draft refers to this as "object

Indeed, channel vs. object protection is long-standing terminology for 
the distinction.

Separately, note that "end-to-end" can refer to different end-points. 
The gateway to an end-users administrative network is a reasonable 
example of an end, for some considerations.

Equally, a mailbox isn't necessary and end-point, when talking about 
applications that interact via email, since the application might have 
additional transit, beyond email.  (That's not hypothetical.  Electronic 
Data Interchange [EDI] demonstrated this point.)

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 16 Jan 2014 21:30:16 +0000

Hi Ted,

On 01/16/2014 07:23 PM, Theodore Ts'o wrote:
> worse.

I'm fairly sure you don't mean it that way, but just in case...

We'll really be better off not to be talking as if end-to-end
(or object) and hop-by-hop (channel) security were mutually
exclusive - "the alternative" sort of implies that.

And there are different hops or channels as well, e.g. if I
run IMAP/TLS whilst on an IPsec VPN etc etc. Or see the
discussion between Adrian and Steve Kent on our draft. So
those are also options and not mutually exclusive.

One take away from a lot of the snowdonia stuff is that we
should have well defined interoperable and ideally easy to
deploy ways to do security at *every* level since every single
option will work best for someone somewhere.

For example, when the tcpcrypt folks turned up at the IETF a
couple of years ago I was against it really. That was mostly
because I figured we already had TLS so why would we want
another thing that's so similar but partly because they were
selling it as "better" than TLS. I've now concluded that I
was wrong about that and am encouraging them as I can.

And our draft is meant to be the same - another tool for the
tool-box. (Well, assuming it turns out to be a useful tool,
which is still not yet known.)

Cheers,
S.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 16 Jan 2014 17:19:32 -0500

> So I don't see how claiming that striving for end-to-end security is

Arguing for end to end security at the exclusion of transport models is
harmful.

Looking at NSLs as the attack paradigm is unwise as we don't currently have
any IETF countermeasure. Not PGP, not S/MIME, not STARTTLS. You are free to
propose one but it certainly won't be an end to end security solution
because the internet infrastructure that is routing packets and messages
needs to know the direction to send them in.

PGP and S/MIME are both unable to protect meta-data against an attacker
with intercept capability.

STARTTLS is unable to protect content against attack by a corrupt system
administrator.

To have comprehensive security we need both the End 2 End security to
protect the data at rest and the transport layer security to protect the
metadata in motion.

---

From: "Christian Huitema" <[email-masked]>
Date: Thu, 16 Jan 2014 22:22:47 -0800

> PGP and S/MIME are both unable to protect meta-data against an attacker with intercept capability.  
>
> STARTTLS is unable to protect content against attack by a corrupt system administrator.
>
> To have comprehensive security we need both the End 2 End security to protect the data at rest
> and the transport layer security to protect the metadata in motion.

Well, yes, of course. But we also have to start somewhere. STARTTLS is reasonably easy to deploy, and many mail services are either already deploying it or are in the process of deploying it. The channel protection with STARTTLS will not protect against compromised servers, and will not prevent providers to comply with national security letters and other subpoenas. But it will prevent the bulk collection of message headers by tapping links, and that's a very good first step.

- -- Christian Huitema

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 17 Jan 2014 07:50:56 -0500

On Fri, Jan 17, 2014 at 1:22 AM, Christian Huitema <[email-masked]>wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> protect the data at rest
> Well, yes, of course. But we also have to start somewhere. STARTTLS is
> reasonably easy to deploy, and many mail services are either already
> deploying it or are in the process of deploying it. The channel protection
> with STARTTLS will not protect against compromised servers, and will not
> prevent providers to comply with national security letters and other
> subpoenas. But it will prevent the bulk collection of message headers by
> tapping links, and that's a very good first step.
>

Which was my argument.

Except that there is nothing STARTTLS or PGP or S/MIME can do against a
national security letter demanding metadata from a server. So it is fine to
use NSLs as an argument for doing more than STARTTLS, it is not an argument
for doing PGP or S/MIME instead.

The law authorizing NSLs does limit them to metadata in theory but we don't
have any evidence to suggest that they are not widely abused and used for
content and there are plenty of reasons to distrust agencies of a
government that was engaged in torture under the previous administration.

The SMTP SEND, RCPT (and to a lesser degree RFC822 header) data has to be
public for the system to work.

I think I have a scheme that sorts out the usability catastrophe and trust
model limitations of the End to End model. What I was saying is that doing
that does not eliminate the need for STARTTLS.

We can discuss mechanisms for dealing with NSLs but I don't think that is
productive until we have the E2E issue solved in practice rather than a
large scale science project. A million users is not enough on a network
with a billion users.

My PPE scheme does provide a hole where someone can wire in a scheme that
protects metadata and has protection against traffic analysis. But that
isn't something I would make a priority at this stage.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 20 Jan 2014 10:11:38 -0500

Stephen,
> those are also options and not mutually exclusive.
no, they are not, but having a plethora of security options
available does not mean that, on a pairwise basis, one will
be able to invoke any of them. (Assuming that we are sticking
with mandatory to implement, not mandatory to use).
> option will work best for someone somewhere.
maybe.
> was wrong about that and am encouraging them as I can.
I wish you wouldn't encourage them. I can easily see confusion
and non-interoperability arising because of the need to choose
between TLS and tcpcrypt.

Steve

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 20 Jan 2014 15:19:00 +0000

> between TLS and tcpcrypt.

I think its fair to say that the question of when tcpcrypt
might be a better tool to use than TLS is an open one, and
one where it'd be good to have some deployment experience
before making recommendations.

Speculating, I'd expect that if tcpcrypt were implemented in
some kernels then it'd be useful in places where you can't
feasibly use TLS. But that's me speculating and I'm sure
the proponents of tcpcrypt can give you a better answer.

S.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 20 Jan 2014 07:27:07 -0800

On 1/20/2014 7:19 AM, Stephen Farrell wrote:
> I'd expect that if tcpcrypt were implemented in
> feasibly use TLS.

what are some examples of when this could occur?

as long as there is speculation about this as a legitimate alternative, 
it would help to have the speculation include plausible examples.

d/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 21 Jan 2014 09:31:23 -0500

On Mon, Jan 20, 2014 at 10:27 AM, Dave Crocker <[email-masked]> wrote:

> as long as there is speculation about this as a legitimate alternative, it
> would help to have the speculation include plausible examples.

tcpcrypt looks more like an alternative to IPSEC than TLS to me.

Given that IPSEC has been a flop, working on an alternative twenty years
later seems fine to me.

The types of use case where I see problems with our current infrastructure
are for applications such as wireless networking where WiFi security is
still a usability disaster and remote access (aka dialup but we don't
dialup any more).

One major design limit in IPSEC and TLS is that both view the key exchange
as being integral to the security layer rather than a separate service. I
would like to separate out consideration of how chunks of data passing over
the net are tagged and bagged for encryption and authentication from the
question of key setup.

There is no logical reason why the key negotiation for TLS, IPSEC and
tcpcrypt cant be shared.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 21 Jan 2014 10:25:40 -0500

PHB,
...
>
> One major design limit in IPSEC and TLS is that both view the key 
> exchange as being integral to the security layer rather than a 
> separate service. I would like to separate out consideration of how 
> chunks of data passing over the net are tagged and bagged for 
> encryption and authentication from the question of key setup.
IKE is separate from ESP and AH. ESP and AH can be used independently of 
IKE, although manual keying
is obviously not attractive in most cases. TLS is a different matter, in 
that the handshake that
puts keys in place is integral to the data security protocol. However, 
DTLS is used with SRTP
to secure VoIP, showing that the key exchange there can be used to 
support other protocols.
> There is no logical reason why the key negotiation for TLS, IPSEC and 
yes, it could be, despite the erroneous assertions above ;-)

Steve

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 21 Jan 2014 11:05:13 -0500

On Tue, Jan 21, 2014 at 10:25 AM, Stephen Kent <[email-masked]> wrote:

>> exchange as being integral to the security layer rather than a separate
>> service. I would like to separate out consideration of how chunks of data
>> passing over the net are tagged and bagged for encryption and
>> authentication from the question of key setup.
>>
> to secure VoIP, showing that the key exchange there can be used to support
> other protocols.
>
>

Please do not confuse your misunderstanding of my post with my knowledge of
the circumstances.

IKE is certainly not currently packaged up for use an independent service.
Saying that this could be done is not the same as it having been done.

The current IKE document begins as follows:

Kaufman, et al.              Standards Track                    [Page 4]

  <http://tools.ietf.org/html/rfc5996#page-5>RFC 5996
<http://tools.ietf.org/html/rfc5996>                        IKEv2bis
               September 2010

1 <http://tools.ietf.org/html/rfc5996#section-1>.  Introduction

   IP Security (IPsec) provides confidentiality, data integrity, access
   control, and data source authentication to IP datagrams.

That is not how I expect a document describing an independent crypto
protocol designed for use in other schemes to begin.

Suggesting that the IETF adopt a practice of requiring re-use of such
schemes in the security area is actually suggesting quite a major change in
our approach. i.e. instead of having PGP and S/MIME sit in separate rooms
defining two different message formats for secure email, require them to
agree on one message format that can be used with both trust
infrastructures.

The idea that key exchange can be implemented as an independent Web Service
is not something I expect to see in the IPSEC docs since the originals were
written several years before the term was coined.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 21 Jan 2014 11:30:55 -0500

PHB,

...
> Please do not confuse your misunderstanding of my post with my 
> knowledge of the circumstances.
read what I wrote, as opposed to your misunderstanding ...

> IKE is certainly not currently packaged up for use an independent 
> service. Saying that this could be done is not the same as it having 
> been done.
>     <http://tools.ietf.org/html/rfc5996#page-5>
> RFC 5996  <http://tools.ietf.org/html/rfc5996>                         IKEv2bis                  September 2010
>
>
I said that IKE is _separate_ from ESP and AH and that _AH and ESP can 
be used without IKE_.

It is true that IKE is a version of ISAKMP that has been tailored to 
support IPsec, but it
is still independent of ESP and AH; IKE uses its own mechanisms to 
protect its SAs, not ESP.
> schemes in the security area is actually suggesting quite a major 
> change in our approach. i.e. instead of having PGP and S/MIME sit in 
> separate rooms defining two different message formats for secure 
> email, require them to agree on one message format that can be used 
> with both trust infrastructures.
(O)PGP and S/MIME are different in more ways than the assumed "trust 
infrastructure."

I think no one is requiring re-use of IKE in contexts where it is not 
appropriate. However, given
the complexity of developing good key management protocols, Security ADs 
usually advise against
creating a new one unless it is necessary.
> The idea that key exchange can be implemented as an independent Web 
> Service is not something I expect to see in the IPSEC docs since the 
> originals were written several years before the term was coined.
Ah, so your (previously hidden) agenda is a push for a Web Service for 
key management. Well, at least that's
on the table now, sitting next to OmniBroker.

Steve

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 21 Jan 2014 19:35:39 -0500

Steve

If you are going to state that someone got their post wrong then all that
actually matters is what they said because that is the case you are arguing
against. You can't redefine my motion and then complain that I didn't
understand it.

If you are going to say I got things wrong and then followup with a
completely unrelated post then you are a confused bunny.

And I split the key agreement out of Omnibroker into WSConnect, oh, six
months ago. Precisely because it is a feature that we now need at the Web
Service layer. So hardly a 'hidden agenda'.

While we are at it we could reinstate photuris.

On Tue, Jan 21, 2014 at 11:30 AM, Stephen Kent <[email-masked]> wrote:

> service. Saying that this could be done is not the same as it having been
> done.
>
>   <http://tools.ietf.org/html/rfc5996#page-5>RFC 5996 <http://tools.ietf.org/html/rfc5996>                        IKEv2bis                  September 2010
>
>   I said that IKE is *separate* from ESP and AH and that *AH and ESP can
> be used without IKE*.
>
> is still independent of ESP and AH; IKE uses its own mechanisms to protect
> its SAs, not ESP.
>
> Ah, so your (previously hidden) agenda is a push for a Web Service for key
> management. Well, at least that's

---

From: Stephen Kent <[email-masked]>
Date: Wed, 22 Jan 2014 09:47:31 -0500

PHB,

I'd respond to your comments if they were directly tied to specific 
statements
I made. But, for the most part, they are so vague ...

WRT Omnibroker, my comment was not based on key agreement being part of 
Omnibroker;
it was an observation that your recent proposals all tend to focus on 
technologies that
fit nicely into a model where you current employer could generate a 
revenue stream,
as an extension of its current Web PKI CA model. I have not tracked the 
evolution
of Omnibroker, as it is an individual submission. Since such submissions are
not vetted, it's not generally worth my time to track them.

Steve

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 22 Jan 2014 11:40:46 -0500

I find it rather interesting that someone who takes great offense when it
is pointed out that he works under contract to the NSA goes after people
for having a 'hidden' agenda.

If you want to start questioning people's ulterior or bought motives you
are sawing off a mighty fine branch there and its the one you are standing
on.

Is the reason that you are arguing against Omnibroker so hard because
someone in Fort Meade is getting nervous? Maybe they should, they had three
people come to see my first public talk on PRISM-PROOF email. Or is it
impolite for me to ask such questions because you are the only person
allowed to call people's motives into question?

I have made absolutely no secret of the fact that Omnibroker provides a
business model for CA like companies. In fact that is the basis on which I
have presented it to Symantec and McAfee and other anti-virus companies
precisely to solicit support. As far as I am aware, they are not
communists. Neither is my employer.

Changing the Internet is hard. You can't change it unless your scheme is
actually free or backed by a business model that covers the costs. I can't
remember at this stage whether I talk about the business model in part 1 or
2, I haven't got round to editing part 2 yet:

http://www.youtube.com/watch?v=PTKrt471vTU

I talk about business models because I understand that I can't change the
infrastructure alone. I need the help of Microsoft and Google and Apple and
Mozilla. And they are not likely to be interested in a business model that
only fits one provider.

What we need to get away from is the clueless business models of the past.
CAs add real value in the WebPKI but not very much to the MailPKI currently
which is why there isn't one, or rather isn't very much of one. A model
that makes CAs toll booth collectors before the road is built does not work.

But CAs can certainly add value to a MailPKI infrastructure once it reaches
critical mass. Today maybe 0.01% of Internet users know enough about crypto
to configure their systems securely themselves. That may rise to 5% or so
with training etc. That leaves a huge market for CAs. If a billion people
want to use crypto to protect themselves against the panicking generals
that run the NSA, we will find ways to make money.

The Open Source model works fine for many software products. Red Hat does
pretty well.

But we are taking a risk here. Comodo group has 155,000 paid, non expired
S/MIME certs right now. So changing the model could backfire on us. But
thats a risk we have decided to take.

---

From: Leif Johansson <[email-masked]>
Date: Wed, 22 Jan 2014 21:19:24 +0100

Are we there yet?

---

From: Scott Brim <[email-masked]>
Date: Wed, 22 Jan 2014 15:32:00 -0500

> Are we there yet?

I deny that I am monitoring your location.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 29 Jan 2014 14:35:00 -0500

On 1/22/14 11:40 AM, Phillip Hallam-Baker wrote:
> I find it rather interesting that someone who takes great offense when 
> it is pointed out that he works under contract to the NSA goes after 
> people for having a 'hidden' agenda.
>
> If you want to start questioning people's ulterior or bought motives 
> you are sawing off a mighty fine branch there and its the one you are 
> standing on.
>
> someone in Fort Meade is getting nervous? Maybe they should, they had 
> three people come to see my first public talk on PRISM-PROOF email. Or 
> is it impolite for me to ask such questions because you are the only 
> person allowed to call people's motives into question?

PHB,

I'm pretty sure communism didn't enter into my comments on your 
proposals :-).

I also have no idea whether anyone at NSA has any interest in Omnibroker. To
the extent that it represents an opportunity for centralizing and 
outsourcing
trust services, I can imagine some there might even find it attractive :-).

I have absolutely no desire to watch any YouTube videos you have produced.

I'd like to think that, during over 30 years of participation in 
Internet standards, my agenda has never been hidden. Yes, I am a 
government contractor. I have received funding from various parts of the 
DoD (including DARPA, DCA, Army, Navy, etc.) the DHS, and 
otherorganizations. In most cases, and for all of my recent funding 
(say, over the past 20ish years) the work I do is the result of what I 
have proposed to funding organizations, because I think it is useful for 
improving Internet security. I don't tend to bid on BAAs or RFPs from 
funding agencies; instead, I approach them, describe security problems I 
think are important and where I think I can help, and ask for money to 
do the work. Sometimes I get funds, sometimes not. But my agenda is 
overt. Sometimes IETF participants have asked why I participate in the 
IETF, since I am do not work for a product company or a service 
provider, and I've explained, as above.

For example, my work on IPsec was motivated by years of experience with 
layer 3 security technology. When I began working at BBN, in the later 
70's, we had an ARPA (now DARPA) project to build the first packet 
network encryption system, using a KDC. I worked on that project, 
extending the architecture to accommodate multiple KDCs (for robustness) 
and to enable establishing security associations across administrative 
domains. The hardware we used (inline hardware crypto, built by another 
government contractor) employed the first DES chips certified by NBS 
(now NIST). BBN wrote the software, which worked with early versions of 
TCP and IP. This work was completed, including performance testing, 
several years before MIT initiated Project Athena, and developed Kerberos.

In the latter 80's and early 90's I was a participant in the SDNS 
(Secure Data Network Systems) program (which was sponsored by NSA) to 
develop network layer crypto systems for protecting DoD classified data. 
That program developed SP3, a precursor to IPsec, and MSP, some aspects 
of which appear in S/MIME. The MSP work leveraged my experience leading 
work on PEM, the first e-mail Internet standard security protocol. (PEM 
was initially developed initially in the Privacy and Security Research 
Group, then in the PEM WG, both of which I chaired.) This showed that 
DoD-sponsored work canbenefit from work performed in the "outside" world.

In the late 90's and through 2005, I contributed to, and eventually 
became responsible for, the IPsec RFCs, bringing to that effort some of 
the experience I gained in the SDNS program. (BTW, all of the SDNS 
protocol specs were unclassified, because NSA wanted vendors to use them 
in buildingsystems to protect unclassified, as well as classified, 
data.) So, in this case, experience flowed from government work to the 
public standards sector.

At one time NSA bought into what the big telecom providers were saying, 
and created network layer crypto that worked only with ATM. This was 
brought to my attention by a router vendor, who was hoping to sell 
products to DoD clients, who could not use the routers because they were 
not compatible with the latest, fastest crypto available for protecting 
classified data. When I because aware of this I urged NSA to revisit 
IP-based network crypto. They had been told that IP-based crypto systems 
would be slow, compared to the ATM-based systems they were fielding. So, 
some colleagues at BBN and I designed a 10Gb/s IP crypto device (that 
used DoD algorithms approved to protect classified data), to demonstrate 
that IP crypto could be fast. That effort (yes, we were paid!) led to a 
significant program change, so that when ATM stopped being the "next big 
thing" and fast IP routers were available, there were network layer 
crypto devices that would work with them. The resulting products were 
called HAIPEs (High Assurance IP Encryptors). I wasn't pleased with all 
aspects of those products, but at least we avoided the ATM dead end J.

I chaired PKIX for about 18 years; part of the funding for my 
participation came from the DoD. They were making a big investment in 
PKI and were willing to help support work that advanced PKI standards. 
They became a big user of OCSP (not my personal, favorite protocol, but 
...) and thus benefitted from the existence of an IETF WG that offered a 
forum for developing PKI standards. My co-chairs over this time included 
folks from the PKI industry, NIST, and Microsoft.

Since the last 90's I have worked on architectures to improve 
inter-domain routing security. This work was sponsored initially by 
DARPA, and later received DHS funds, in part because the principal 
sponsor moved from DARPA to DHS! My work in SIDR, on the RPKI and 
BGPSEC, has been paid for by DHS and DoD, because they see the need for 
better routing security. Nothing mysterious there.

Overall, I am pretty proud of the work I have done in the IETF, the 22 
(soon to be 23) RFCs that I've published, my time on the IAB, chairing 
the PSRG, PEM and PKIX WGs, serving on four Nomcoms, and my 
contributions to other WGs. In all of the years that I have worked on 
Internet standards the only RFC that recall writing in response to a 
request from the DoD was my first, RFC 1108. That RFC (published in 
1991) described the IPv4 basic and extended security options, as 
implemented in a DoD network crypto system (BLACKER) of the 80's. I 
don't think that work, or anything I have done since, makes me an agent 
provocateur.

Steve