Re: [Tcpcrypt] Initial questions

[ianG <[e-mail]>]

On 24/06/2014 15:45 pm, Stephen Kent wrote:
> Sandy,
...

>> The draft charter also has:
>>
>> - The protocol must provide cryptographic algorithm agility.
...

This bit:

> I can say that failure to accommodate alg agility will almost certainly
> cause
> the IESG to reject this as a standard, based on precedents for some time.


Interesting point!  Probably worth reaching out to those folk and asking
whether they are serious about enforced alg agility.

And why they care so much in the context of TCPcrypt, which is
opportunistic anyway, and as such provides not much of a guarantee.


...
>> Key size? I'd mandate 128 bits everywhere to keep it simple.


(In the charter, we shouldn't mandate any size.  Just let the proponents
walk the gauntlet with their choices.)


> recall that AES has 256-bit keys as an option as a counter to possible
> quantum computing attacks. Why rule out that option?


Because this is TCPcrypt.  The enemy is the unavailability of any
encryption at at all, not the QC bogeyman.

If we deploy TCPcrypt to 99% of all nodes, and they're all vulnerable to
QC, we still win.

(Because, to spell it out, we can always upgrade later on when the
bogeyman starts deploying QC in the mega-scale, and meanwhile we won
against everyone else.)


>> The draft also has:
>>
>> - Must gracefully fall-back to TCP if the remote peer does not support
>> the
>>    proposed extensions
>>
>> Aren't there a set of policy questions there? Some users might prefer
>> to drop the connection rather than communicate insecurely. Perhaps
>> they need a mechansim to set policy, globally and/or on a
>> per-connection basis. FreeS/WAN had something like this for IPsec over
>> a decade ago:
>> http://www.freeswan.org/freeswan_trees/freeswan-2.06/doc/policygroups.html
>>
> This is a different context. I believe the goal is to try to negotiate
> use of encryption silently, and thus failing silently makes sense.


(concur.)



iang