Re: [Tcpcrypt] Initial questions

[Stephen Kent <[e-mail]>]

Sandy,

> ...
>
> Probably today we should go much further. No MD5 or SHA1 since there
> are known problems. No 3DES since newer ciphers are far faster. No
> reliance on the whole X.509 cert infrastructure SLL/TLS uses; that
> also has known problems. I'm not sure what else.
To which X.509 cert infrastructure problems are you referring? Do you
mean the Web PKI or PKI in general? IPsec, for example, does not make
use of the Web PKI. Just curious.
> The draft charter also has:
>
> - The protocol must provide cryptographic algorithm agility.
>
> OK, but there is a balance to be struck. IPsec & TLS both have
> problems from arguably excessive complexity and in general complexity
> is the enemy of security. It makes all of design, implementation,
> testing & auditing much harder. TCPcrypt has a rather narrow niche to
> fill; that can be done with a fairly simple protocol. We really must
> strive to keep it simple.
I'm not sure what your position is re alg agility, based on the 
paragraph above.
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.

> Here's a first cut at what we might support:
>
> Block ciphers: MUST do AES. SHOULD do the other three AES finalists
> with open licenses: Mars, Twofish & Serpent. MAY do compatible ciphers
> which are national standards: Aria for Korea, Camellia for Japan,
> maybe others. Nothing else.
why would one make the other AES finalists SHOULD? They didn't make the cut.
> Key size? I'd mandate 128 bits everywhere to keep it simple.
recall that AES has 256-bit keys as an option as a counter to possible
quantum computing attacks. Why rule out that option?
> 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. There
was a session in the STRINT workshop that addressed a topic very close
to this. It's conclusion was to fail silently (and to use PFS, and ...)
> At an absolute minimum, I think there must be a requirement that any
> fallback action is logged.
And who will check the logs? A log on a user machine will likely go
unread in 99.99% of cases, unless there is a plan to submit the logs
to some central monitoring source. But that would raise a set of
privacy questions, so ...

> Another question is whether we could achieve the goals of this group
> with almost no work just by deploying existing stuff.
Always a good question.
> The now-closed BTNS working group did RFCs 5386 & 5387 on "Better than
> nothing security", which they implemented as an unauthenticated mode
> for IPsec. That sounds much like what we are aiming at. Can we just
> work on getting BTNS deployed, thereby protecting both TCP and other
> protocols?
I think the folks who pursue BTNS are best-equipped to address that
question. Ask Sam Hartman, maybe Joe would like to comment as well.

Steve