Hello, Eric,
On 13/12/20 19:06, Eric Rescorla wrote:
On Sun, Dec 13, 2020 at 1:03 PM Iván Arce (Quarkslab)
<iarce@xxxxxxxxxxxxx <mailto:iarce@xxxxxxxxxxxxx>> wrote:
[....]
Indeed. I would further argue that use of authenticated encryption is
not warranted on all protocol designs so dismissing the need for
security and privacy considerations for transient IDs on the basis that
"we encrypt and authenticate the packets anyway" is not a good stance in
general.
Fortunately, that's not the position I am taking. Rather, I am saying
that authenticated encryption is an increasingly common practice and
that we should not publish a set of recommendations in this area which
does not engage with that properly.
The use of proper IDs is pretty orthogonal to the use of encryption.
That said, I wouldn't mind myself incorporating text like Ivan
suggested, something ala:
"in cases where protocols require cryptographic
algorithms to provide confidentiality and integrity (ie.
authenticated encryption) of the transient identifier fields some of
the inherent weaknesses in transient ID generation may be
mitigated."
And/or, something along the lines of:
"Use of appropriate transient numeric IDs is not a replacement for
cryptographic methods of protecting a transport-protocol. Rather,
the use of appropriate transient numeric identifiers results in data
minimisation [RFC7258] and could, in some cases, increase the
difficulty to perform some attacks"
>> 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.
The intend of the document is not to provide cryptoanalysis guidance to
evaluate specific protocol designs but to provide general guidance on
how to deal with use of transient numeric identifiers in protocol
design.
Indeed, the two protocols that you singled out do not follow our
guidance (they hardly could as the document we are reviewing is not yet
officially published) and assessing if the lack of precision for the
generation of transient IDs weakens the protocols would be a matter for
the respective authors to deal with.
This is an odd argument, as the authors of these documents could certainly
have read your documents and adopted your recommendations. But my
point here is different. As I said to Fernando, we are about to publish
these
protocols as PS and yet they appear to violate the guidance here, which
seems
like a bad situation if we are about to publish this guidance as BCP.
I must say that I find it odd that the argument against publishing
appropriate guidance is "well, we have a document in the pipeline that
does not go along with such guidance", rather than whether the guidance
is appropriate or not. Even more when, at the end of the day, the
recommendations apply to *future* protocol specifications and
implementations.
That said, the guidance in our document is:
When a protocol specifies transient numerical identifiers, it is
critical for the protocol specification to:
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].
A proper spec should always spell the requirements in #1. In fact, the
biggest reason for which we have recurrently screwed up with numeric
identifiers is that most specs fail to spell out the interoperability
requirements for the IDs.
#2 should probably be part of the security considerations anyway. For
the most part, this has not been the case, and I have not checked the
QUIC spec in this respect. But given past issues with numeric I-Ds, and
given the push for data minimization (RFC7258), I'd expect this to be
part of the security considerations.
Then there's #3. which comes as a natural consequence of #2.
I do believe that all protocol implementations should do steps #1-#3
above. It could be the case that if one were to do such exercise against
the QUIC spec, one might find out that some quick implementations might
be unnecessarily leaking information to the remote endpoint.
In such case, the proper outcome would be to publish a protocol update,
rather than to thwart appropriate guidance on the topic.
As above,
I think the problem is that the guidance is not well suited to this type
of protocol,
which means that this document ought to be adjusted. However, if you
have an argument that it is these protocols that should be revised, that
would be very good to know.
The answer to this question comes from following steps #1-#2 above.
I haven't done that for QUIC, specifically. But I have added that to my
TODO list. If it turns out that something is leaking, of course the next
step will be an updating I-D and a vulnerability advisory. Wished I had
done that before -- I just haven't.
[....]
Well I'm certainly not arguing that it's not important to describe good
practices for cryptographic protocols, but: it seems to me that this RFC
did precisely what your document recommends in S 5.
- It specified the interop requirements (none)
- It provided the security and privacy analysis (they must be unique and
it's bad if they're not)
- It recommended an algorithm (the sequence number)
Without having read the referenced paper, it would seem that recomended
a predictable sequence after assessing that "it's bad if the IDs are not
unique" highlights were the flaw is. i.e., they failed in step #3 of our
recommendations.
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
