From nobody Sun Dec 13 14:07:22 2020 Return-Path: X-Original-To: last-call@ietfa.amsl.com Delivered-To: last-call@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA96F3A0B22 for ; Sun, 13 Dec 2020 14:07:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.004 X-Spam-Level: X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wn2W_LvY5KmN for ; Sun, 13 Dec 2020 14:07:17 -0800 (PST) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68C353A0B1D for ; Sun, 13 Dec 2020 14:07:17 -0800 (PST) Received: by mail-lf1-x136.google.com with SMTP id r24so25375361lfm.8 for ; Sun, 13 Dec 2020 14:07:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oEPIOuCqt33m8W8RdG9lHtRxzulKTeHTn3uCFcTFRZk=; b=jnQm0SrIomt+uh+xNCYvPHhF5aLovfHUOIoteQIfc6S0wW2Y/jQMUYd0pE9+JhjriS PJfCCyIGlOGGH5sQYTls7HeCbTVF0TgZqZWXlbwHe64NXhm0PC3Hr/l1VmtWqW+HkrsW xgVuNxdwTqpx0Ta38NsXwMN+0Y0fderkt8HyCasILFzqfRnJqA4hEB5rWPcdNcJjyHnE XYzUmd9IYF7ok4EKEefNd6LHF6c7WqKmD6OS2MrHsR25zZeTQgmQZpOf77Fy4Y80kwUD BhA/wnUQgquidrmerdgaHCGMaVzMDZgt5kflKq52BRjsNC0Rz2d4S2s7PTywOMsDImXa zcHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oEPIOuCqt33m8W8RdG9lHtRxzulKTeHTn3uCFcTFRZk=; b=LkxZbyirSEVDIvT//h2j7uP3oBvo1J5AUx1C+oQ6A2+0BscJnCCZTnch2ETBBSkEp5 wsh0qEfspOC+/8LsYIolLSNZBcydna+DXfePjXKhj8X0NyhrFcqnMaemMkWfJmipFEmz n9G8A7lY4t/R1cFZBmrCGgk3K2iXHhggUWlfmZZOpAQK6We/pPWdbx8fZJW0Moi0+oHc +ALQt3O0pQihHoi1oFX2Kx5HxZkXVG0anM24u1ADSE1zBlg+naBz16RfDq+eDDx18kh4 BTyCZERkdSbZF3BWf3Z1XAb8CyGdMgYyZWuYHmBZLLmatZxm0wYAHlOf4amswJlPEuSt ZcAA== X-Gm-Message-State: AOAM532h/00ZosKjyV0iH3gJgdglSyMI/YFmqkic55xmAxMdI7zAHJ+G 3qULbsBz03ZFu7qqFCgnN+REPsQU99T3IieVY/Qdo1z0Qzvpiw== X-Google-Smtp-Source: ABdhPJz1Zb2R60mPJEDpJKNMPMkyv23klIc4N1Rnl0ngJWPS+LdBLY5vasqqKJZdGIraSJbtOgXOcMr7SefwQtcB6Mg= X-Received: by 2002:a05:6512:38ab:: with SMTP id o11mr4659466lft.132.1607897235501; Sun, 13 Dec 2020 14:07:15 -0800 (PST) MIME-Version: 1.0 References: <160735373732.25981.15176977559155786235@ietfa.amsl.com> <891c40bd-091d-bb36-a754-3c84a70ac0aa@si6networks.com> <357c76b4-2b64-abdc-8052-eb367e39599f@quarkslab.com> In-Reply-To: <357c76b4-2b64-abdc-8052-eb367e39599f@quarkslab.com> From: Eric Rescorla Date: Sun, 13 Dec 2020 14:06:39 -0800 Message-ID: To: =?UTF-8?Q?Iv=C3=A1n_Arce_=28Quarkslab=29?= Cc: Fernando Gont , last-call@ietf.org, draft-gont-numeric-ids-sec-considerations@ietf.org Content-Type: multipart/alternative; boundary="0000000000008ec50d05b65fbf99" Archived-At: Subject: Re: [Last-Call] Last Call: (Security Considerations for Transient Numeric Identifiers Employed in Network Protocols) to Best Current Practice X-BeenThere: last-call@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Last Calls List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2020 22:07:21 -0000 --0000000000008ec50d05b65fbf99 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Dec 13, 2020 at 1:03 PM Iv=C3=A1n Arce (Quarkslab) 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. > >> 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. 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. > >> Connection IDs MUST NOT contain any information that can be used b= y > >> an external observer (that is, one that does not cooperate with th= e > >> issuer) to correlate them with other connection IDs for the same > >> connection. As a trivial example, this means the same connection = ID > >> MUST NOT be issued more than once on the same connection. > > > > I believe that not recommending a good/safe choice for generating IDs > > has been proved to be problematic. > > Indeed, that has been the case even in documents that describe the use > of cryptographic algorithms in protocols. > > See, for example, the case of "RFC 25288 - AES Galois Counter Mode (GCM) > Cipher Suites for TLS" which in section 3 states: > (https://tools.ietf.org/html/rfc5288#section-3) > > The nonce_explicit is the "explicit" part of the nonce. It is chosen > by the sender and is carried in each TLS record in the > GenericAEADCipher.nonce_explicit field. The nonce_explicit length > (SecurityParameters.record_iv_length) is 8 octets. > > Each value of the nonce_explicit MUST be distinct for each distinct > invocation of the GCM encrypt function for any fixed key. Failure to > meet this uniqueness requirement can significantly degrade security. > The nonce_explicit MAY be the 64-bit sequence number. > > 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) 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. > > >> 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. 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. -Ekr --0000000000008ec50d05b65fbf99 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Dec 13, 2020 at 1:03 PM Iv=C3= =A1n Arce (Quarkslab) <iarce@quarkslab.com> 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 TC= P)
>> result from the reliance (potentially accidental) on unpredictable=
>> identifiers as a countermeasure against various forms of attack. F= or
>> instance, TCP is subject to a variety of off-path injection attack= s
>> which are partly mitigated by randomizing sequence numbers and por= t
>> 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 th= at
> randomizing numeric IDs is an alternative to cryptographic authenticat= ion.

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 st= ance in
general.

Fortunately, that's not th= e position I am taking. Rather, I am saying that authenticated encryption i= s an increasingly common practice and that we should not publish a set of r= ecommendations in this area which does not engage with that properly.
=



>> Of course, it might be the case that these defenses are insufficie= nt
>> (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.

Th= is 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 pu= blish these
protocols as PS and yet they appear to violate the gu= idance here, which seems
like a bad situation if we are about to = publish this guidance as BCP. As above,
I think the problem is th= at the guidance is not well suited to this type of protocol,
whic= h means that this document ought to be adjusted. However, if you
= have an argument that it is these protocols that should be revised, that wo= uld
be very good to know.


>> =C2=A0=C2=A0 =C2=A0Connection IDs MUST NOT contain any information= that can be used by
>> =C2=A0=C2=A0 =C2=A0an external observer (that is, one that does no= t cooperate with the
>> =C2=A0=C2=A0 =C2=A0issuer) to correlate them with other connection= IDs for the same
>> =C2=A0=C2=A0 =C2=A0connection.=C2=A0 As a trivial example, this me= ans the same connection ID
>> =C2=A0=C2=A0 =C2=A0MUST NOT be issued more than once on the same c= onnection.
>
> I believe that not recommending a good/safe choice for generating IDs<= br> > has been proved to be problematic.

Indeed, that has been the case even in documents that describe the use
of cryptographic algorithms in protocols.

See, for example, the case of "RFC 25288 - AES Galois Counter Mode (GC= M)
Cipher Suites for TLS" which in section 3 states:
(https://tools.ietf.org/html/rfc5288#section-3)

=C2=A0 =C2=A0The nonce_explicit is the "explicit" part of the non= ce.=C2=A0 It is chosen
=C2=A0 =C2=A0by the sender and is carried in each TLS record in the
=C2=A0 =C2=A0GenericAEADCipher.nonce_explicit field.=C2=A0 The nonce_explic= it length
=C2=A0 =C2=A0(SecurityParameters.record_iv_length) is 8 octets.

=C2=A0 =C2=A0Each value of the nonce_explicit MUST be distinct for each dis= tinct
=C2=A0 =C2=A0invocation of the GCM encrypt function for any fixed key.=C2= =A0 Failure to
=C2=A0 =C2=A0meet this uniqueness requirement can significantly degrade sec= urity.
=C2=A0 =C2=A0The nonce_explicit MAY be the 64-bit sequence number.

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<= br> 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= 9;m certainly not arguing that it's not important to describe good prac= tices for cryptographic protocols, but: it seems to me that this RFC did pr= ecisely what your document recommends in S 5.

- It= specified the interop requirements (none)
- It provided the secu= rity and privacy analysis (they must be unique and it's bad if they'= ;re not)
- It recommended an algorithm (the sequence number)

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.

>
>> I'm not saying that cryptographic protocols don't need to = take care in
>> identifer selection, but the guidance in this document does not se= em
>> 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.
=


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.

= -Ekr

--0000000000008ec50d05b65fbf99--