Re: [OAUTH-WG] Signature crypto

["Infinity Linden (Meadhbh Hamrick)" <[e-mail]>]

selecting a required to implement algorithm is independent of extensibility.
it is always possible to get both.

and yes, you can separate required algorithms from core functionality. so if
RFC XXX0 described OAuth mechanisms, and then RFCXXX1 described SHA1+RSA as
being required while RFCXXX2 described ECDSA as being required, you could
get people talking about supporting "RFCXXX1" or "RFCXXX2" instead of
talking about supporting RFCXXX0.

RTP did a pretty good job of describing core concepts and features in
RFC3550, then added a/v in RFC3551. Secure RTP (or SRTP) was defined in
RFC3771, and mandated a particular set of algorithms. unfortunately, some of
these algorithms were difficult to implement on some handsets. AES, for
instance seemed to eat up a lot of CPU time on some lower end devices. there
was a second scheme that used a lighter-weight algorithm, but i don't think
it ever saw the light of day.

so the moral of the story is that if you don't mandate a required algorithm,
you'll get MOSS.

you _can_ separate the mechanism from the required algorithm, and put the
two in different RFCs. but it doesn't eliminate all risk of
non-interoperability, because as soon as you define your first "profile"
RFC, you're going to find that someone want's to use a second set of
algorithms. experience tends to show that only one of these will be
predominant. at that point, people lose interest in the non-predominant
profile and back the one which is perceived to have more external support.
so at this point the only thing that separating the algorithms out buys you
is you get to defer selection of the "required" algorithm spec.

RFC5280 is probably okay with not specifying a required algorithm because
SHA1+RSA is a de facto standard in this community because Verisign dominated
the industry for so long and only supported SHA1+RSA and *shudder* MD5+RSA.

this doesn't affect organizations that do like using commercial CA's (like
the federal bridge CA) because they already have large organizations (like
NIST, AMX, etc.) describing a collection of acceptable algorithms. in those
communities, vendors generally don't talk about RFC5280 compatibility, but
rather "suitability for use with the federal bridge" or "suitability for use
with the automotive information exchange."

OAuth does _not_ have a pre-existing group which mandates algorithms. thus,
i think that NOT requiring an algorithm somewhere will lead to a bit of
confusion amongst people wishing to implement the spec.

still, it's not like the sky's falling. but i would offer the predictions:

a. if we don't have a required algorithm somewhere, you will find that OAuth
users will select whatever algorithm set they like. many times, they will
choose algorithms that other people don't use. when they start to want to
interoperate with these people, there will be a mild gnashing of teeth as
the two parties make a pairwise agreement over which algorithm they'll use.
it's not the end of the world, but this sort of pairwise algorithm
negotiation will occur all over the place.

b. if you put required algorithms in a second RFC, distinct from the draft
defining OAuth mechanisms, you will quickly see someone write an additional
draft with a new set of required algorithms. you'll then have a mild amount
of confusion over which one should be supported, possibly ending when
everyone decides to support both. in this case, you might as well have
defined both as being REQUIRED.

c. if chaos looms for longer than it takes for a FLOSS developer to
reasonably apply support to PHP, Python/WSGI and Java, then you'll see
whatever algorithm choice that developer makes become the de facto standard
(because it's available everywhere.) if we're unlucky, that developer will
make their algorithm choice based on the 1996 edition of Applied Crypto
which does not have suitable exhortations for developers to eschew MD5.

so... it's probably less about it being absolutely necessary to select a
required algorithm for the spec, and more about what kind of chaos can we
live with?

-cheers
-meadhbh
--
  infinity linden (aka meadhbh hamrick)  *  it's pronounced "maeve"
        http://wiki.secondlife.com/wiki/User:Infinity_Linden


On Wed, Nov 25, 2009 at 08:19, Tschofenig, Hannes (NSN - FI/Espoo) <
[e-mail]> wrote:

> This case is interesting.
>
> Until recently I have also thought that one has to specify a
> mandatory-to-implement algorithm in a security protocol since otherwise
> interoperability would really suffer. When working in KEYPROV I learned
> through Russ Housley that this is actually not true.
>
> He said:
> "
> Some specifications in the security area do not pick a mandatory to
> implement algorithm.  RFC 5280 is one example.  Instead the companion
> specifications tell what algorithm is appropriate for a particular
> environment.
> "
>
> There are a few reasons why you often cannot agree on a specific
> algorithm. Examples are different usage scenarios that demand a certain
> algorithm, certain software packages that may or may not support certain
> algorithms at a specific point in time, different performance/hardware
> requirements, IPR concerns, etc.
>
> In any case it is likely that the chosen algorithm will get replaced in
> a few years from now and one does not want to update the specification
> every time. Hence, having some form of crypto-agility is generally a
> good idea since you might want to negotiate a set of algorithms anyway
> and it is quite likely that an algorithm is found that both parties
> support.
>
> Ciao
> Hannes
>
>
>
> ________________________________
>
>        From: [e-mail] [mailto:[e-mail]] On
> Behalf Of ext Infinity Linden (Meadhbh Hamrick)
>        Sent: 25 November, 2009 16:19
>        To: Stephen Farrell
>         Cc: OAuth WG ([e-mail])
>        Subject: Re: [OAUTH-WG] Signature crypto
>
>
>         +1 to stephen's comment.
>
>        when it comes to algorithm support and selection, i think the
> consensus that's emerged is we should require an algorithm that "looks
> good" at the moment the spec is being drafted, but allow the use of
> other optional algorithms. ("looks good" here means that there are no
> known successful attacks against the math of the algorithm and there's a
> general consensus amongst cryptographers that there won't be one in the
> next 20 years.)
>
>        the rationale behind this may have to do with the experience
> some implementers had with MOSS / MIME Object Security Services (aka
> RFC1848.) MOSS was specified to address issues people had raised with
> PEM (Privacy Enhanced Mail). The problem with MOSS is that it was near
> infinitely flexible and you could create an implementation that strictly
> adhered to the specification, but was non-interoperable if you chose to
> support a different set of optional encipherment algorithms.
>
>        so the concern here is that if you allow all hash algorithms to
> be optional, you'll find some outlier who wants to use HAVAL with Rabin
> Williams to generate signatures and will sell this solution into the
> marketplace, then go out of business. people who bought the solution
> won't think anything's wrong 'til they try to hook it up to someone else
> who's using a more traditional SHA256+RSA or ECDSA solution. a great
> wailing and gnashing of teeth will follow.
>
>        but if we REQUIRE that everyone use SHA256 but allow other hash
> algorithms, then we won't have this problem.
>
>        -cheers
>        -meadhbh
>
>        --
>          infinity linden (aka meadhbh hamrick)  *  it's pronounced
> "maeve"
>                http://wiki.secondlife.com/wiki/User:Infinity_Linden
>
>
>
>        On Wed, Nov 25, 2009 at 05:52, Stephen Farrell
> <[e-mail]> wrote:
>
>
>
>
>                Eran Hammer-Lahav wrote:
>                > I think we have consensus that the spec should not
> mandate a particular hash algorithm. This still leave the issue of
> assigning algorithms short names for the purpose of negotiation and
> declaration. Is there a registry available for such algorithms we can
> use or do we need to create a new one?
>
>
>                Sorry to have missed out on the thread where that was
> discussed, but
>                it'd be odd for an IETF security spec to not mandate
> some algorithms
>                and quite likely to generate comments later in the
> process if there's
>                no well-defined way to ensure interop. Do we have that?
>
>                Ta,
>                S.
>
>
>                _______________________________________________
>                OAuth mailing list
>                [e-mail]
>                https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>