Re: [Tcpcrypt] New version of the charter text

[ianG <[e-mail]>]

On 28/04/2014 06:31 am, marcelo bagnulo braun wrote:
> El 27/04/14 23:29, Stephen Farrell escribió:
>> Hi Marcelo,
>>
>> On 27/04/14 21:43, marcelo bagnulo braun wrote:
>>> - Hooks for allowing upper layers to disable encryption must be made
>>> available.
>>>     The protocol may try to avoid redundant encryption when it is
>>> possible
>>> e.g.
>>>     by detecting encryption performed by upper layers (notably, when TLS
>>> is used).
>> Based on all the discussion on this so far, I'd also suggest
>> deleting this bit. I agree with Ian that the reasons for
>> including this stated so far are arm-wavy. And "detecting"
>> that higher layers are encrypting vs. compressing seems unlikely
>> in the general case too. If something is using TLS then the
>> TLS code (which normally calls the socket API I think) can
>> presumably determine if TCP Inc. would be on by default and
>> do the right thing so there's no need for TCP Inc. to do
>> anything for that case even if someone concludes that double
>> wrapping isn't what they want.
>>
>> So count me as another -1 on inclusion of the above.
> 
> mmm, I guess i misread the previous discussion or i didnt managed to
> explain what i had in mind.
> 
> Let me try to explain myself (not trying to push for this, just want to
> clarify).
> 
> What i had in mind was _not_ about allowing the upper layer to disable
> the encryption in the middle of a connection.

Well, yes, I don't think anyone had that in mind.

> What i had in mind was to allow the upper layer to say: "please for this
> connection, dont use TCP-INC, just use plain old TCP".

This is understood.  I believe this will exist in implementations,
regardless, for development purposes.  I also believe the smart
implementors will realise they don't need it, and nor do their users,
and that they will solve some problems by getting rid of it (which
realisation will also infect thinking about ciphersuites).

> This is because
> the upperlayer may knwo better, for instance, it is building its onw
> security.


If the upper layer truly knew better, it wouldn't be using TCP.

Or, you might be saying, the upper layer is TLS.  In which case the
developers are going to be really annoyed by the dual layers basically
duplicating the same thing (if tcp-crypt is any guide) and is thus shear
waste.  But the users won't know any different?

And why can't the developers spend that time turning it off (with
uncertain knowledge of whether the implementation is even there) by
instead working with the TCP-crypt layer instead of against it?


> If we dont provide this hook, then it is always encrypted if both ends
> support and there is nothing the upper layer can do in order to avoid it.


Yes.  But what is the problem with that?

Obviously performance spring to mind, but many claim that is no longer
an issue.  Without getting dragged into mindless academic foodfights
about citations, the point is here that performance isn't the reason it
was in 1994, when they broke HTTPS and put half the website in the
clear.  I can't recall the last time I had to tweak SSH to use a faster
cipher for huge backups, it was probably late 1990s.

Latency could be an issue with say TLS over TCP-crypt over TCP-startup.

Secondly, you bring up dual security.  Now, the nature of security is
that a security layer cannot interfere with the data being transported,
and indeed that's reflected in the charter.  So it is not as if there
are going to be artifacts of interference in a proper implementation.

Finally, it might be worth noting that it is a general NSA
recommendation that systems should be dual-encrypted where the systems
are sufficiently independent of each other.  e.g., IPSec at the
point-to-point and PGP or SSH above that.  FWIW.

Point being, there is no clear MUST nor SHOULD here, this again is a
property that can and will emerge from the experimentation.


> Please also note that this does not allow for the peer to downgrade the
> connection or terminate encryption, as this has no impact in the wire,
> it is only at the begining of the connection.
> 
> Does this clarify things? What do you think?
> 
> That being said, I am perfectly fine with removing it from the charter.


That's what is being asked.



iang