Hello, Eric,
On 13/12/20 18:52, Eric Rescorla wrote:
On Sun, Dec 13, 2020 at 12:40 AM Fernando Gont <fgont@xxxxxxxxxxxxxxx
<mailto:fgont@xxxxxxxxxxxxxxx>> wrote:
[....]
> Turning to specific examples, Section 4 lists a number of practices
> that are described as "common flaws". Out of these, QUIC and
> DTLS both arguably do the following:
>
> o Employing trivial algorithms (e.g. global counters) that
result in
> predictable identifiers
>
> o Initializing counters or timers to constant values, when such
> initialization is not required
>
> And potentially:
>
> o Employing the same increment space across different contexts
>
> However, due to their design, QUIC and DTLS are intended to be
> resistant to attacks based on these choices. In particular, they:
>
> 1. Cryptographically authenticate datagrams in order to prevent
> injection attacks.
>
> 2. Encrypt the packet/sequence numbers so that they are not
exposed on
> the wire (QUIC all the time and DTLS 1.3).
>
> Of course, it might be the case that these defenses are insufficient
> (that would be useful to know!) but this document does not provide
> much assistance in making that evaluation.
I'd argue the other way around.
For example, if you don't need the ID to share the same increment
space,
then, when you are sharing the same increment space, you're potentially
leaking information (resulting from the increments) from one context to
the other, without any requirement to do so.
And my question would be: why do it, when you don't need to? If this
information turned out to be of use for an attacker, would the argument
be "Well, we knew we were unnecessarily leaking information, but even
when we had choices not to, we did it anyways, because we thought it
was
harmless"?
Let's take the specific case of QUIC and DTLS packet/sequence numbers.
In both cases, the packet/sequence numbers start from zero and increment
monotonically (arguably violating the first two points) and regardless
of path
(violating the second two points).
This is what our document says:
1. Clearly specify the interoperability requirements for the
aforementioned identifiers (e.g., required properties such as
uniqueness, along with the failure severity if such properties
are not met).
2. Provide a security and privacy analysis of the aforementioned
identifiers.
3. Recommend an algorithm for generating the aforementioned
identifiers that mitigates security and privacy issues, such as
those discussed in [I-D.irtf-pearg-numeric-ids-generation].
I'm not sure how what you describe is violating points #1 and #2,
because #1 is essentially what a proper specification should have anyway
(interoperability requirements) and you might argue that you should be
doing #2 anyway (most implementations don't, but should).
Now, either this is an OK practice
because
of header encryption (the position that both QUIC and DTLS take) or it is
a bad practice (the position that this draft seems to take). But we
shouldn't
be simultaneously publishing documents which take both positions.
To address your substantive point: I don't think this is leaking
information to
the attacker because the headers are encrypted, and having some other
structure would be more complicated in a number of ways.
The attacker could certainly be the remote endpoint you are
communicating with -- it need not be an off-path or on-path attacker.
*If* employing such identifiers was leaking information about other
network activities you're performing, would allow for tracking, or any
variation of this, that'd still be information leakage in by book.
[...]
I believe that not recommending a good/safe choice for generating IDs
has been proved to be problematic. If a protocol is successful enough,
it's very likely that you will see multiple independent implementations
(from folks that are not involved in the protocol design, etc.), and
that bad choices will be made if there is no recommendation.
As noted above, QUIC connection identifiers are opaque and indeed are
specifically not intended to be interpreted by the other side. Thus if
the structure of those identifiers is relevant, something has gone wrong.
Nobody argued about structure in the connection IDs, but generating them
in a way that they are unpredictable.
e.g., what if connection-ids were generated from a global counter?
According to the QUIC spec, that'd be one possible implementation.
> I'm not saying that cryptographic protocols don't need to take
care in
> identifer selection, but the guidance in this document does not seem
> very helpful in that respect. It's no doubt the case that the IETF
> will in the future design some non-cryptographic protocols where this
> kind of guidance will be on-point, but I don't think that in 2020
> we should publish a document as BCP which ignores so much of current
> practice.
Could you please elaborate?
We did evaluate what has happened to multiple protocols from different
layers. And the findings seem to converge for all of them.
I don't think you can claim that what has been done in one specific
protocol from one specific layer is "current practice".
My position is that modern practice is to design protocols that have
encryption
(this is strongly encouraged by RFC 7258 and also is just what we're doing)
and this document neither (a) engages with that nor (b) provides
particularly
helpful guidance for encrypted protocols.
You seem to be referring to mitigating data injection attacks, or to
provide confidentiality to the data stream via crypto. Nobody is arguing
against that.
In that context, what we are arguing is that even if you encrypt, if you
use improper identifiers you could leak information to the other
endpoint -- which can read and analyze the identifiers, because its the
intended destination of your packets.
You also seem to focus on the particular case of data injection against
transport protocols. I'd note that there are identifiers such as IPv6
Fragment Identifiers, transport protocol ephemeral ports, IPv6 Interface
Identifiers, and others, where use of crypto as for the specific case
and protocol that you're referring to does not apply.
Almost four years have passed. I wished we could do something to
prevent
these issues from continuing to happen in our protocols and their
corresponding implementations. And I'd certainly prefer not to try to
boil the ocean once more.
As I noted, such an effort is already underway, so this work could feed
into it. As your documents are already out there and available in the
drafts repo, I don't feel that there is any rush to have this in RFC form.
We seem to disagree in this respect.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fgont@xxxxxxxxxxxxxxx
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
