Joe Touch <[email protected]> writes:
>> AO is an authentication option rather than an encryption spec.
>> AO-encrypt in ENC-BTNS mode probably doesn't meet the security
>> requirements of ENO (the 16-byte ECDH limit could be problematic at a
>> time when even 32-byte curves are starting to be deprecated, at least
>> for top secret data).
>>
>> That said, if you actually wanted AO-encrypt to work work with ENO, we
>> could make it happen.
>
> That could never protect the SYN itself, which is something TCP-AO-ENC
> was intended to do. The AO variants protect the TCP header, which TCPINC
> decided not to do. That's still (IMO) going to be important.
>
> I.e., I see ENO as severely limited in this regard, and that needs to be
> noted in the ENO doc.
I think you are conflating several issues here. The working group
decided TCPINC will not protect the headers. I wasn't necessarily in
favor of that decision, but I don't see any point in relitigating it,
either. That means the working group will produce a TCPINC protocol
that does not protect TCP headers. Fine.
However, the fact that TCPINC does not protect headers does not mean
that TCP-ENO cannot be used to negotiate protocols other than TCPINC
that do protect the header. Indeed, one of the motivations for TCP-ENO
was that we felt the working group was letting the perfect become the
enemy of the good, and we wanted to be able to do something good without
closing the door to negotiating something better later on.
If it turns out that, independent of TCPINC, the TLS working group has
some use for TCP-ENO, then great. Similarly, it would be nice if
AO-encrypt's ENC-BTNS mode could benefit from TCP-ENO. I'm a bit
confused as to why you are talking about protecting the SYN header, when
your draft-touch-tcp-ao-encrypt-04 says:
Initial SYN and SYN-ACK. The initial SYN (SYN and not ACK) and
SYN-ACK segments are not encrypted or authenticated. Instead,
their HMAC field contains the Diffie-Hellman nonce in network-
standard byte order.
Correct me if I'm wrong, but I believe ENC-BTNS is the only mode that
could benefit from negotiation, since ENC-AUTH mode is configured out of
band. So ENC-BTNS would seem a fine fit for TCP-ENO if you were willing
to modify your draft. On the other hand, given that you already
officially own option 29, maybe you have no use for a protocol that is
illegally squatting on option 69. (You've made your opinion on
squatting quite clear, no need to repeat it.) But if you wanted to be
able to negotiate AO-encrypt alongside tcpcrypt and TLS, there's no
reason you couldn't participate in ENO.
David
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
