Re: [Tcpcrypt] New version of the charter text

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.
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 because 
the upperlayer may knwo better, for instance, it is building its onw 
security.

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.

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.

Regards, marcelo

>
> That said, I think that the argument for null ciphers could
> still be made later (which might be one way to deal with the
> wish expressed above), and I'm sure someone will inevitably
> make the argument for that for debugging purposes so since
> we know it'll happen we don't really need to argue about
> whether that's ok or not now:-) As I've also said before,
> I'd need to be convinced that those are worthwhile myself
> so as of now I'd say not defining 'em is the right thing.
>
> S.
>
> _______________________________________________
> Tcpcrypt mailing list
> Tcpcrypt@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpcrypt
>