Re: 'monotonic increasing'
"Tom.Petch" <sisyphus@dial.pipex.com> Fri, 17 February 2006 22:10 UTC
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FADnu-00053z-3t; Fri, 17 Feb 2006 17:10:18 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FADnr-00053V-Jn for ietf@megatron.ietf.org; Fri, 17 Feb 2006 17:10:15 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18320 for <ietf@ietf.org>; Fri, 17 Feb 2006 17:08:26 -0500 (EST)
Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAE2M-0005W7-Rm for ietf@ietf.org; Fri, 17 Feb 2006 17:25:15 -0500
Received: from pc6 (1Cust226.tnt106.lnd4.gbr.da.uu.net [213.116.60.226]) by galaxy.systems.pipex.net (Postfix) with SMTP id 9B855E0000D6; Fri, 17 Feb 2006 22:10:02 +0000 (GMT)
Message-ID: <008d01c63406$5e734aa0$0601a8c0@pc6>
From: "Tom.Petch" <sisyphus@dial.pipex.com>
To: Elwyn Davies <elwynd@dial.pipex.com>
References: <200601301716.JAA16888@gra.isi.edu> <002501c628af$62188600$0601a8c0@pc6> <014601c633dd$82948bc0$0601a8c0@pc6> <43F621B7.3090207@dial.pipex.com> <021d01c633f2$7ab014a0$0601a8c0@pc6> <43F63719.3020402@dial.pipex.com>
Date: Fri, 17 Feb 2006 22:06:30 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c
Content-Transfer-Encoding: quoted-printable
Cc: ietf <ietf@ietf.org>
Subject: Re: 'monotonic increasing'
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Tom.Petch" <sisyphus@dial.pipex.com>
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
I agree that there is no clear cut case where security will be compromised, but as long as RFC eg RFC1510 (kerberos) tie the concept of nonce to a monotonic increasing sequence, I think the risk is there and could easily be avoided if we started using the term 'strictly increasing' instead. Of the RFC I have looked at, RFC3412 (SNMP) is probably the one I would most question, since it suggests that a monotonically increasing integer will avoid a reuse of outstanding values; for me, this is a clear case of 'strictly increasing'. Tom Petch ----- Original Message ----- From: "Elwyn Davies" <elwynd@dial.pipex.com> To: "Tom.Petch" <sisyphus@dial.pipex.com> Cc: "ietf" <ietf@ietf.org> Sent: Friday, February 17, 2006 9:50 PM Subject: Re: 'monotonic increasing' > Hmm! I don't think I see your problem with any of the usages in the > RFCs mentioned. In all cases monotonically is used to express that the > sequence is non-decreasing which is in line both with the mathematical > definition and the Merriam-Webster online dictionary #2 sense. In some > of the cases the sequence required is actually strictly monotonically > increasing but the other words make this clear, and since strictly > monotonic sequences are also monotonic, it is not wrong. The only one > where there could be (IMO) a soupçon of doubt is RFC2679 where it isn't > absolutely clear whether or not T in the (n+1)-th pair needs to be > strictly greater than T in the nth pair, and I suspect it doesn't > matter in this case - it certainly wouldn't break interoperability. > > Regards, > Elwyn > > Tom.Petch wrote: > > Elwyn > > > > To be more concrete, I have some 1800 RFC readily available and find monotonic > > in 54 of them from RFC677 (1975) to RFC4303. > > > > Plucking a few at random, RFC3412 (SNMP) suggests that monotonic increasing > > would avoid reuse while RFC2406 (IPsec) suggests monotonic increasing can be > > used in the context of replay attacks. (I accept that in the latter, as in many > > cases, understanding the context, the whole document or set of RFC, does imply > > that the sequence should be strictly increasing). RFC2679 (IPPM) is more > > mathematical in its approach, where I would expect the term to be informed by > > its use in mathematical textbooks, but it appears not to be > > > > Tom Petch > > > > ----- Original Message ----- > > From: "Elwyn Davies" <elwynd@dial.pipex.com> > > To: "Tom.Petch" <sisyphus@dial.pipex.com> > > Cc: "ietf" <ietf@ietf.org> > > Sent: Friday, February 17, 2006 8:19 PM > > Subject: Re: 'monotonic increasing' > > > > > > > >> Hi. > >> > >> Tom.Petch wrote: > >> > >>> The phrase 'monotonic increasing' seems to be a Humpty-Dumpty one, used with > >>> > > a > > > >>> different sense within RFC to that which I see defined elsewhere; and this > >>> could lead to a reduction in security. > >>> > >>> Elsewhere - dictionaries, encyclopaedia, text books - I see it > >>> defined so that when applied to a sequence of numbers, then each number is > >>> > > not > > > >>> less than its predecessor, so that > >>> 1 1 1 1 1 1 1 1 1 1 > >>> 1 1 2 3 5 8 13 > >>> 1 2.71828 3.14159 4.18 42 > >>> are all monotonic increasing sequences whereas > >>> 1 2 3 4 5 6 7 9 8 10 > >>> is not. > >>> > >>> > >> On the definition of monotonic increasing: I just checked my memory with > >> my copy of Apostol (Mathematical Analysis, vintage 1968 or so) and > >> monotonic increasing implies element (n+1) greater than or equal to > >> element n for all n. 'Strictly monotonic increasing' implies greater > >> than. On line > >> http://www-history.mcs.st-and.ac.uk/~john/analysis/Lectures/L8.html > >> confirms this. > >> > >>> Within RFC, mostly those related to security or network management, the > >>> > > context > > > >>> of its use implies, in addition, one or more of > >>> a) each number in the sequence is different (as in number used once) > >>> b) each number is an integer > >>> c) each number is one greater than its predecessor (as in message > >>> > > sequencing) . > > > >>> Most likely, an implementation that conforms to the rest of the world > >>> > > definition > > > >>> would interwork with one that conforms to the RFC one, but with some loss of > >>> security, since numbers that are intended to be used only once could be > >>> > > reused. > > > >>> Q1) Can anyone point me to an authoritative source that endorses the RFC > >>> > > usage? > > > >>> Q2) Even so, since the rest of the world usage seems to be so widely > >>> > > defined, > > > >>> should we change our terminology, eg specifying seqences to be strictly > >>> increasing when that is what is needed? > >>> > >>> > >>> > >> I just did a full text search of all the RFCs using the zvon repository > >> which covers up to RFC3999. the fragment 'monotonic' (including > >> 'monotonically') appears in RFCs 1323, 1379, 1644, 1889, 2326, 2681, > >> 3571 and 3550. All these cases (either about timestamps or TCP sequence > >> numbers) appear to use monotonically increasing in line with the > >> mathematical definition although it is possible that a couple of them > >> (e.g., RFC3571, s4) ought to use strictly monotonic, although the usage > >> is clear from the additional words. > >> > >> In many cases the phraseology is explicitly used because the sequence > >> (of tiimestamps used, for example) does not have every possible integer > >> represented. > >> > >> Do you have a concrete example of your problem? > >> > >> Regards, > >> Elwyn > >> > >>> Tom Petch > >>> > >>> > >>> _______________________________________________ > >>> Ietf mailing list > >>> Ietf@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/ietf > >>> > >>> > > > > > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
- RE: IETF65 hotel location Ed Juskevicius
- Re: IETF65 hotel location David Kessens
- IETF65 hotel location Pekka Savola
- Re: IETF65 hotel location Brian E Carpenter
- Re: IETF65 hotel location Pekka Savola
- Re: IETF65 hotel location Joel Jaeggli
- Re: IETF65 hotel location Dave Crocker
- Re: IETF65 hotel location John Levine
- RE: IETF65 hotel location Hallam-Baker, Phillip
- Re: IETF65 hotel location Dave Crocker
- Re: IETF65 hotel location John Levine
- Re: IETF65 hotel location Michael Thomas
- Re: IETF65 hotel location Spencer Dawkins
- RE: IETF65 hotel location Robin Uyeshiro
- Re: IETF65 hotel location Jeffrey Hutzelman
- Re: IETF65 hotel location Marshall Eubanks
- RE: IETF65 hotel location David B Harrington
- RE: IETF65 hotel location Jeffrey Hutzelman
- Re: IETF65 hotel location lconroy
- Re: IETF65 hotel location Ole Jacobsen
- Re: IETF65 hotel location Brian E Carpenter
- Re: IETF65 hotel location Dave Crocker
- Re: IETF65 hotel location Marshall Eubanks
- RE: IETF65 hotel location Gray, Eric
- Re: IETF65 hotel location Bob Braden
- Re: IETF65 hotel location John Levine
- Re: IETF65 hotel location Dave Crocker
- Re: IETF65 hotel location Daniel Senie
- Re: IETF65 hotel location Joel Jaeggli
- Re: IETF65 hotel location JORDI PALET MARTINEZ
- Re: IETF65 hotel location Keith Moore
- Re: IETF65 hotel location Tom.Petch
- Re: 'monotonic increasing' Tom.Petch
- 'monotonic increasing' Tom.Petch
- Re: 'monotonic increasing' Ken Raeburn
- Re: 'monotonic increasing' Frank Ellermann
- Re: 'monotonic increasing' Henrik Levkowetz
- Re: 'monotonic increasing' Elwyn Davies
- Re: 'monotonic increasing' Francis Dupont
- Re: 'monotonic increasing' Elwyn Davies
- Re: 'monotonic increasing' Tom.Petch
- Re: 'monotonic increasing' Ken Raeburn
- Re: 'monotonic increasing' Joe Touch
- Re: IETF65 hotel location Stephen Sprunk