Re: [Cfrg] [secdir] ISE seeks help with some crypto drafts

[Paul Wouters <[e-mail]>]

On Sat, 9 Mar 2019, Tony Arcieri wrote:

> Here is the specific wording he is suggesting:
> 
>  "Phillip Rogaway offers a royalty-free non-exclusive license to all claims of the referenced patents needed to realize a fully compliant
> implementation of any IETF standards-track protocol supporting AES-OCB (RFC 7253)."
> 
> I think he's looking for guidance around how to properly phrase that if anyone has a more concrete suggestion for how to put it in the
> form of an IPR statement.

While this phrasing would solve the issues for some protocols, such as IKE
and IPsec, it is still a request that the IETF publish a cryptographic
standard that cannot be freely used. The IETF normally does not do that
unless there are exceptional reasons to do so. It would be good to see
thse reasons written up for evaluation.

It would be problematic too if someone using an RFC wouldn't realise
their use of this standard would be in violation of Mr. Rogaway's IPR.

I also believe allowing OCB for only TLs in the past was a mistake we
should not repeat in a slightly different form by covering a few more
protocols.

Note also RFC 3979:

https://tools.ietf.org/html/rfc3979#section-8

    Over the last few years the IETF has adopted stricter requirements
    for some security technologies.  It has become common to have a
    mandatory-to-implement security technology in IETF technology
    specifications.  This is to ensure that there will be at least one
    common security technology present in all implementations of such a
    specification that can be used in all cases.  This does not limit the
    specification from including other security technologies, the use of
    which could be negotiated between implementations.  An IETF consensus
    has developed that no mandatory-to-implement security technology can
    be specified in an IETF specification unless it has no known IPR
    claims against it or a royalty-free license is available to
    implementers of the specification unless there is a very good reason
    to do so.

As the IETF has been moving towards reducing the number of algorithms,
it would not make sense to promote a new algorithm that can never become
mandatory-to-implement.

Maybe it would be good to involve the IETF Trust in this matter?

Paul