Re: [Tcpcrypt] New version of the charter text

ok, given that we are talking about the same thing, i guess it is clear 
that there is no clear consensus to keep this in, so i will remove it 
from the charter and leave it for WG discussion


El 28/04/14 12:42, ianG escribió:
> 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
>
> _______________________________________________
> Tcpcrypt mailing list
> Tcpcrypt@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpcrypt
>