Subject: Re: [cicm] Use of Bypass

From: "Novikov, Lev" <[email-masked]>
Date: Fri, 2 Jul 2010 13:21:33 -0400

On 2010-06-25 at 13:55 John Davidson wrote:
> [...] Internally, the function would also have to be proven to represent a wall with 
> no leaks besides the cryptographic transform.
> [...] there is any logical way to support any amount of bypass securely, so I would 
> suggest we consider declining to support bypass.  I would argue that bypass simply 
> punches un-mitigatable holes (leaks) in our otherwise secure wall, and if someone 
> thinks they need bypass, let them punch their own holes in somebody else's wall.
> [...] I view bypass (like header bypass) as a symptom of an IA architectural 
> problem that should have been solved outside the "crypto."

John,

As you mention, this is a bold claim. The role of CICM is to provide a standard API
to existing and future high assurance devices.
If:
  - Those devices have bypass capabilities, and
  - People write software that uses those capabilities,
Then:
  - We'd like them to do it in a standard way.

I believe that these are the current conditions, and, if I understand you correctly,
you believe that we should not--in principle--provide bypass capabilities in a crypto.

I should note that our section on Conformance (Section 4; 
see: http://tools.ietf.org/html/draft-lanz-cicm-00#section-4) addresses this issue
by allowing implementers to choose which pieces of CICM they want to implement (with
some minor restrictions). The reporting requirement (see "Implementation Conformance Statement")
should help identify when things like bypass (header or full) have been implemented
and/or are being used.

* Folks: What do you think? What are reasons to keep/discard the bypass APIs?

Lev

---

From: "Cottrell Jr., James R." <[email-masked]>
Date: Mon, 12 Jul 2010 09:31:22 -0400

John,

There are times when communication, even in the clear, is important.  If devices haven't been correctly keyed, allowing communications in life or death situations is needed.

In emerging software controlled systems, where wires and signals from plaintext-to-ciphertext and ciphertext-to-plaintext sides of a crypto are replaced by software "messages/signals", the need for supporting the bypassing of encryption/decryption is even more important.  The crypto device design may limit the amount or rate of bypassed data, may analyze the content to ensure it is "OK" to bypass and can audit the use of bypass.

Jim C.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Novikov, Lev
Sent: Friday, July 02, 2010 1:22 PM
To: CICM Discussion List
Subject: Re: [cicm] Use of Bypass

John,

Lev
_______________________________________________
cicm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cicm

---

From: "Cottrell Jr., James R." <[email-masked]>
Date: Mon, 12 Jul 2010 10:20:53 -0400

Folks,

Just back from vacation and reading my emails, oldest to newest.  Didn't realize that discussion on this topic had been put to bed.

Sorry for the email.

Jim C.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Cottrell Jr., James R.
Sent: Monday, July 12, 2010 9:31 AM
To: CICM Discussion List
Subject: Re: [cicm] Use of Bypass

John,

Jim C.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Novikov, Lev
Sent: Friday, July 02, 2010 1:22 PM
To: CICM Discussion List
Subject: Re: [cicm] Use of Bypass

John,

Lev

---

From: "Linn, Charles" <[email-masked]>
Date: Tue, 27 Jul 2010 12:44:46 -0400

FWIW, keep the bypass APIs.  At the risk of being blunt, this is where
practical meets academic (or at least academic at the current moment).
This same topic has been debated in the JTRS arena, and while there are
a few differing opinions, I think it would be accurate to say broad
opinion says bypass is here for at quite a while longer.

Put another way - make the API such that it can work with no bypass, but
for heaven's sake support bypass.  20 years from now, when we don't even
remember what the word was because it saves so much cost to construct
sets that are inherently bypass free, we'll deprecate the feature.

Chuck

---

From: "Davidson, John A." <[email-masked]>
Date: Tue, 27 Jul 2010 10:43:25 -0700

Chuck, 

Would it satisfy your practical concern to support a bypass API in a separate function that is not part of the crypto?  

I agree, as a practical matter some implementers will inevitably use bypass and may expect API support for that.  I just recommend we consider not making bypass a part of the crypto because it corrupts the crypto too much.   If it is part of the crypto standard, designers will implement it unaware of the unintended consequences.  Once we open that hole (IN THE CRYPTO) no filter/guard can securely close it; but I don't see the bandwidth or interest in this venue in pulling that thread on why this is true.  

Consider, too, that bypass really has nothing to do with encryption.  

John

-----Original Message-----
From: [email-masked] on behalf of Linn, Charles
Sent: Tue 7/27/2010 9:44 AM
To: CICM Discussion List
Subject: Re: [cicm] Use of Bypass

Chuck

---

From: "Blumenthal, Uri - 0668 - MITLL" <[email-masked]>
Date: Tue, 27 Jul 2010 15:29:01 -0400

I would probably keep Bypass API with the Crypto API because it is closely related.

What would be the reasons not to?
--
Regards,
Uri          [email-masked]<mailto:[email-masked]>

On Jul 27, 2010, at 13:43 PM, Davidson, John A. wrote:

Chuck,

John

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> on behalf of Linn, Charles
Sent: Tue 7/27/2010 9:44 AM
To: CICM Discussion List
Subject: Re: [cicm] Use of Bypass

Chuck
_______________________________________________
cicm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/cicm

<ATT00001..txt>

---

From: "Davidson, John A." <[email-masked]>
Date: Tue, 27 Jul 2010 19:19:01 -0700

WARNING: contains banned part

Subject: RE: [cicm] Use of Bypass
From: "Davidson, John A." <[email-masked]>
To: "CICM Discussion List" <[email-masked]>
Date: Tue, 27 Jul 2010 19:19:01 -0700

Uri, to answer your question, the reason not to is that, as I mentioned, it corrupts the strength of the crypto's operating environment too much.  I understand that the majority is firmly convinced bypass is necessary to make SDRs work, but that doesn't make it true.  Although I can prove all this, it would take more discussion and I feel I should get Lev's view on continuing this discussion.  

I would like hear about the close relation you mentioned.  

Lev

-----Original Message-----
From: [email-masked] on behalf of Blumenthal, Uri - 0668 - MITLL
Sent: Tue 7/27/2010 12:29 PM
To: CICM Discussion List
Subject: Re: [cicm] Use of Bypass

--
Regards,
Uri          [email-masked]

	Chuck,

	
	
	John

	-----Original Message-----
	From: [email-masked] on behalf of Linn, Charles
	Sent: Tue 7/27/2010 9:44 AM
	To: CICM Discussion List
	Subject: Re: [cicm] Use of Bypass

	
	Chuck

	<ATT00001..txt>

---

From: "Davidson, John A." <[email-masked]>
Date: Wed, 28 Jul 2010 06:18:26 -0700

The previous response (below) was unintentionally truncated; it ended in 

"Lev"

and appeared to be from Lev.  It was not.  It should have ended in:

"Lev?  

Thanks, 
John"

My apologies for the confusion, 
John

-----Original Message-----
From: Davidson, John A.
Sent: Tue 7/27/2010 7:19 PM
To: CICM Discussion List
Subject: RE: [cicm] Use of Bypass

Lev

-----Original Message-----
From: [email-masked] on behalf of Blumenthal, Uri - 0668 - MITLL
Sent: Tue 7/27/2010 12:29 PM
To: CICM Discussion List
Subject: Re: [cicm] Use of Bypass

--
Regards,
Uri          [email-masked]

	Chuck,

	
	
	John

	-----Original Message-----
	From: [email-masked] on behalf of Linn, Charles
	Sent: Tue 7/27/2010 9:44 AM
	To: CICM Discussion List
	Subject: Re: [cicm] Use of Bypass

	
	Chuck

	<ATT00001..txt>