Hola On 12/13/20 7:06 PM, Eric Rescorla wrote: > > > On Sun, Dec 13, 2020 at 1:03 PM Iván Arce (Quarkslab) > <iarce@xxxxxxxxxxxxx <mailto:iarce@xxxxxxxxxxxxx>> wrote: > > Hello Eric, Fernando > > On 12/13/20 5:38 AM, Fernando Gont wrote: > > Hello, Eric, > > > > Thanks for your comments! In-line.... > > > > > > On 12/12/20 18:44, Eric Rescorla wrote: > .. > >> > >> At a high level, many of the attacks listed here (especially in TCP) > >> result from the reliance (potentially accidental) on unpredictable > >> identifiers as a countermeasure against various forms of attack. For > >> instance, TCP is subject to a variety of off-path injection attacks > >> which are partly mitigated by randomizing sequence numbers and port > >> numbers. However, the more modern practice is to cryptographically > >> authenticate datagrams, thus preventing injection attacks even if the > >> port and sequence number are predictable. > > > > I don't think the two are mutually-exclusive. Nobody is arguing that > > randomizing numeric IDs is an alternative to cryptographic > authentication. > > 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. What do you mean with "does not engage with that properly". What do you consider proper engagement ? Is acknowledging the use of authenticated encryption and recommending its use as a way to mitigate weaknesses associated to transient IDs proper engagement or do you think there isnt any textual formulation that would engage properly and therefore the document should not move forward? On the specific topic of transient identifiers in authenticated encryption (or "deterministic encryption") we could refer to the work of Bellare et. al. (https://eprint.iacr.org/2019/624.pdf) but I doubt that would be appropriate for a guidance document. But I am much more concerned about providing guidance to authors of protocols that are not using or mandating authenticated encryption. It may be an increasingly common practice but its certainly not a requirement or a universally adopted practice yet. > > >> 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. I dont see any oddity in pointing that authors of drafts are not necessarily aware of nor follow the guidance of other draft an different stages of publication process. They could have or not have read our document, I am not privvy to what they did, but I guess that isnt relevant to our discussion. > 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 don't understand this rationale for not publishing the draft as BCP. Some protocols are about to be published as PS and they do not follow the guidance in our draft therefore the draft should not be published ? On one hand, I think is evident that protocols published before the BCP is published may not follow its guidance, I don't see anything wrong with that, I-D authors aren't constantly monitoring every other I-D to see if they should revisit their draft based on other drafts that will be potentially published. On the other hand, I think that perhaps the authors of said protocols should check the guidance of our draft and figure out if and how it applies to their work. > 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. > I have not looked into the two specific protocols that you brought up, but after a quick glance at the excerpt you quoted from the QUIC document, to me it appears to be insufficient to cover potential security & privacy issues. In fact, in my previous email I wrote that my cursory read of section 5.1 of the QUIC spec indicates me that Connection ID seems sufficiently complex to require more in-depth analysis. .. > The case below is quite similar and even more specific (it hints at a > particular way of implementing it) than the QUIC example and yet it lead > to discovery 8 years later of at least 4 vulnerable implementations > deployed on the Internet, as described by Bock at. al. in > "Nonce-Disrespecting Adversaries: Practical Forgery Attacks on GCM > in TLS" > (https://eprint.iacr.org/2016/475.pdf) > > Note that in the AES-GCM in TLS case the need for a counter was > warranted but not explicitly called for and such underspec'd text lead > to flawed implementations. In other cases, a random nonce/ID is better > than a numeric sequential value, we argue that authors should assess > what is appropriate in their particular case and write their spec and > rationale for it accordingly. > > > 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) > It did not recommend any algorithm, it merely indicated that the nonce MAY be the 64-bit sequence number but did not mandate it. Clearly, that was insufficient to prevent broken implementations. > I would note that the eventual outcome in this case in TLS 1.3 was to > remove the explicit nonce entirely and to replace it with a value > generated from the sequence number. Indeed, which effectively mandated a specific algorithm (section 5.3 of RFC 8446) thus fulfilling requirement #3 of Section 5 of our draft. > > > > > >> 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. > > I'd like to dig deeper into that feedback. In which way do you think it > does not seem helpful. What would you expect it to say to be helpful? > > > See above for a specific example. The specific example I wrote about (AES-GCM in TLS) followed by the correction in TLS 1.3 that you pointed out seem to support the case of the 3 requirements of section 5 of our draft. > > > Baring a more detailed proposal I propose to include text that > explicitly calls out that 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. > > Does that sound like a sensible caveat? > > > Not really, no. I believe substantial rework is needed to address the > role that identifiers work in cryptographic protocols. what is the substantial rework that you would expect for a guidance document ? /ivan -- Iván Arce CTO - Security Analysis Quarkslab -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
