Re: [tcpinc] Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpcrypt-09: (with DISCUSS and COMMENT)

[Eric Rescorla <[e-mail]>]

On Thu, Nov 1, 2018 at 9:57 PM David Mazieres <
[e-mail]> wrote:

> Eric Rescorla <[e-mail]> writes:
>
> >    When a frame is received, tcpcrypt reconstructs the associated data
> >    and frame ID values (the former contains only data sent in the clear,
> >    and the latter is implicit in the TCP stream), computes the nonce "N"
> >    as above, and provides these and the ciphertext value to the AEAD
> >    decryption operation.  The output of this operation is either a
> >    plaintext value "P" or the special symbol FAIL.  In the latter case,
> >    the implementation SHOULD abort the connection and raise an error
> >    condition distinct from the end-of-file condition.  But if none of
> >    the TCP segment(s) containing the frame have been acknowledged and
> >    retransmission could potentially result in a valid frame, an
> >    implementation MAY instead drop these segments (and "renege" if they
> >    have been SACKed, according to [RFC2018] Section 8).
> >
> > Looking through this again, why is this the right guidance? It seems
> > like:
> >
> > 1. You shouldn't ACK data that you can't verify, because it's confusing
> > to the other side. This seems like one of the arguments for tcpcrypt
> > rather than protocols that run over top of TCP.
>
> This obviously isn't how the original tcpcrypt worked, but the working
> group decided that for middlebox robustness, tcpcrypt should not protect
> the integrity of the TCP header (including ACK bits).  As it is, nothing
> requires TCP segments to align with tcpcrypt frames.  If the recipient
> lucks out and hasn't ACKed any of the corrupt data, then maybe hope a
> retransmission is better, although middleboxes might prevent sequence
> numbers from being overwritten anyway.  Since that's a rather fringe
> case, if you only do one thing it needs to be aborting the connection.
>
> > 2. You would get better resistance to connection failure if you instead
> > decrypted packets and then ACKed.
>
> Not especially, because tcpcrypt doesn't protect the header, so an
> active attacker can just inject bad packets and desynchronize the TCP
> connection.  There does exist a protocol that does better--namely the
> original version of tcpcrypt, but for various reasons the working group
> ultimately rejected this design (over my objections), and it's too late
> to revisit the decision at this point.
>
> > Is the situation that sometimes you have to ACK? I haven't thought
> > this through. Perhaps you should recommend against ACKing if you
> > don't have to.
>
> The ACKing is effectively dictated by RFC793 (+SACK).
>

OK, I'm persuaded I'm wrong about this.



> > I also notice you don't require checking that the result of the
> > X25519 function is nonzero. We hve been requiring this in other
> > IETF protocols.
>
> Seems like a vanishingly low-probability event, but I see no problem to
> adding such a requirement.  Do you have some language to suggest?  Maybe
> we could cut and paste out of another RFC with already approved
> language?
>

It's a lot probability event with a correctly-behaving counterparty, but
it's easy for
the other side to force the output to 0. Here is some text:

https://tools.ietf.org/rfcmarkup?doc=8446#section-7.4.2

"

   For these curves, implementations SHOULD use the approach specified
   in [RFC7748 <https://tools.ietf.org/rfcmarkup?rfc=7748>] to
calculate the Diffie-Hellman shared secret.
   Implementations MUST check whether the computed Diffie-Hellman shared
   secret is the all-zero value and abort if so, as described in
   Section 6 of [RFC7748]
<https://tools.ietf.org/rfcmarkup?rfc=7748#section-6>.  If
implementors use an alternative
   implementation of these elliptic curves, they SHOULD perform the
   additional checks specified in Section 7 of [RFC7748]
<https://tools.ietf.org/rfcmarkup?rfc=7748#section-7>.

"


> >    the number of past connections that are vulnerable.  Of course,
> >    placing private keys in persistent storage introduces severe risks
> >    that they will not be destroyed reliably and in a timely fashion, and
> >    SHOULD be avoided at all costs.
> >
> > This seems a bit over the top. Either it's this serious and you need
> > a MUST, or it's not this serious, and you should tone it down.
>
> It is serious, especially with SSDs.  The reason not to make it a MUST
> is that some implementations may be unable to avoid it--like a virtual
> machine that gets transparently paged to disk.  That could still be okay
> if, say, the swap partition is encrypted with an ephemeral key.
>

Well, then the text should say this. But "SHOULD at all costs" is silly.


> >    To meet that ideal, it might appear natural to also mandate ECDHE
> >    using P-256, as this scheme is well-studied, widely implemented, and
> >    sufficiently different from the Curve25519-based scheme that it is
> >    unlikely they will both suffer from a single (non-quantum)
> >    cryptanalytic advance.
> >
> > I'm not sure how persuasive this argument is. Wouldn't an efficient
> > discrete log algorithm in generic groups affect both of these functions.
> > As far as I know, it's not known that no such algorithm exists.
>
> In fact, there are lower bounds on generic-group discrete-log attacks.
> See, for example, this recent Eurocrypt paper:
>
>
> https://www.henrycg.com/files/academic/papers/eurocrypt18discrete.pdf
>
> But it sounds like you actually agree with us that we don't need to
> mandate P-256, so I'm not sure what you are suggesting here.
>

I'm suggesting you remove the justificatory text. Other WGs have just
mandated one group without justification

-Ekr


> David
>