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