On 10/29/2015 5:18 PM, David Mazieres wrote:
> 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.
TCP-ENO can't protect the SYN headers except if there are already
protections in place (ala TCP-AO). If that's the case, you don't need
TCP-ENO.
> 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.
That's fine, I'm just noting that TCP-ENO isn't really an option for
negotiating TCP security because TCP security includes TCP-AO. That
needs to be made clear.
> 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.
Yes, that's the only possible use of TCP-ENO, and I would like to
explore that.
...
> 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.
Correct - that was what I was raising (I wasn't focused on the ENC-BTNS
mode, but probably should be).
> 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.)
Let's suggest this for us both:
- I update ENC-BTNS to use TCP-ENO
- you update TCP-ENO to use RFC 6994 ;-)
(at least until it becomes a standard)
> 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
I can only negotiate AO-ENC-BTNS, as you note, but that's fine with me.
we'd have to figure out the issue of lengths, but I do already have a
draft in TCPM proposing a way to extend the SYN option space (we're
testing it now).
Joe
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
