Re: 'monotonic increasing'

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxx>
To: "Tom.Petch" <sisyphus@xxxxxxxxxxxxxx>
Cc: "ietf" <ietf@xxxxxxxx>
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@xxxxxxxxxxxxxx>
> > To: "Tom.Petch" <sisyphus@xxxxxxxxxxxxxx>
> > Cc: "ietf" <ietf@xxxxxxxx>
> > 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@xxxxxxxx
> >>> https://www1.ietf.org/mailman/listinfo/ietf
> >>>
> >>>
> >
> >
>


_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]