Subject: [secdir] ISE seeks help with some crypto drafts

From: "RFC ISE (Adrian Farrel)" <[email-masked]>
Date: Fri, 8 Mar 2019 09:20:16 -0800

Hi CFRG and SecDir,

Ted Krovetz has asked for publication of ...

https://datatracker.ietf.org/doc/draft-krovetz-ocb-wideblock/
...and...
https://datatracker.ietf.org/doc/draft-krovetz-rc6-rc5-vectors/

...in the Independent Stream.

These are both currently in expired state, but available in the archive.

At this stage I am looking to know whether anyone feels that publication
would be a bad thing:
- at this stage
- ever

Please send me your opinions direct (I am not subscribed to this list, but
will check the archives).

Please also let me know if you would be willing to be a detailed reviewer
of this work.

Thanks,
Adrian
-- 
Adrian Farrel (ISE),
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Fri, 8 Mar 2019 12:52:26 -0500 (EST)

On Fri, 8 Mar 2019, RFC ISE (Adrian Farrel) wrote:

> ....and...
> ....in the Independent Stream.
>

I have strong reservations about the ocb draft. Rogaway has patents
on OCB, and has put constrains on its use and there is no generic IPR
statement that the IETF normally likes to see for work published as
RFC. Until such a time, I do not think publishing RFC's with OCB is
advised. A few years ago I asked the TLS OCB authors about extending
their allowed usage to IKE/IPsec and they told me this use was not
covered by Rogaway's license to them. While this has since changed a bit,
and there is no longer a specific TLS-only license, other constrains are
still in place.  Specifying OCB documents that cannot be implemented or
deployed indiscriminatory is troublesome.

Patents:
http://www.cs.ucdavis.edu/~rogaway/ocb/ocb-faq.htm#patent:phil

 	"I license OCB under fair, reasonable, and non-discriminatory terms,
 	 with licensees paying a modest one-time fee."

 	"I freely license OCB for most (but not all) settings."

And just before that, discriminatory terms are cited for current use:

 	"there is one license grant for open-source software; one for
 	 non-military software; and a third done just for OpenSSL."

See also http://web.cs.ucdavis.edu/~rogaway/ocb/offer.htm

Second, I'm not a cryptographer, but it seems OCB has recently seen some
attacks that might impact the security of OCB:

Cryptanalysis of OCB2
https://eprint.iacr.org/2018/1040

Breaking the confidentiality of OCB2
https://eprint.iacr.org/2018/1087

Plaintext Recovery Attack of OCB2
https://eprint.iacr.org/2018/1090

Note these publications are newer than the publication date of the
draft, so it would be good to discuss this with the draft author or
with CFRG to see how applicable these attacks are to the draft document.

I have no specific remarks about the rc5-rc6 document. It seems useful
to have test vectors, but I am not aware of any IETF protocol using
RC5 or RC6, in which case it might not make sense for the IETF to publish
these test vectors and another standards body might be more appropriate.

Paul

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 8 Mar 2019 17:56:08 +0000

I would rather see this rewritten to completely replace 7523 (and include its test vectors of course)  Would review.

I don't see a compelling need for this, but I am not strongly opposed either.

---

From: David Wong <[email-masked]>
Date: Fri, 8 Mar 2019 10:10:54 -0800

Note that OCB was chose as a finalist in the CAESAR competition. Knowing that, it sounds like a good idea to standardize it.

On the other hand, if I understand correctly you need to pay a one-time fee to use the algorithm in a commercial product? I think that’s a big no-no considering we want everybody to use good open source libraries.

David

> On Mar 8, 2019, at 9:56 AM, Salz, Rich <[email-masked]> wrote:
> 
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg

---

From: Tony Arcieri <[email-masked]>
Date: Fri, 8 Mar 2019 10:45:36 -0800

> deployed indiscriminatory is troublesome.

I would agree the IPR story for OCB is presently bad.

Rogaway had previously voiced interest in completely resolving the patent
situation (i.e. disavowing the patents, with an attorney's assistance)
however sadly it seems he never completed this work. Perhaps I can attempt
to get the ball rolling on that again...

> https://eprint.iacr.org/2018/1090

There are three variants of OCB: OCB1, OCB2, and OCB3.

These attacks apply to OCB2. They do not apply to OCB1 or OCB3.

OCB3 is realistically what we should be using provided the IPR story can be
cleared up.

-- 
Tony Arcieri

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Fri, 8 Mar 2019 18:51:08 +0000

+1 to Tony, and I am for publishing OCB3. 

Also, I didn't keep track of the OCB IPR, but I think it improved in the last few years. Anyway, let's get the ball rolling.

Regards,
Uri

Sent from my iPhone

> On Mar 8, 2019, at 13:46, Tony Arcieri <[email-masked]> wrote:
> 
> Rogaway had previously voiced interest in completely resolving the patent situation (i.e. disavowing the patents, with an attorney's assistance) however sadly it seems he never completed this work. Perhaps I can attempt to get the ball rolling on that again...
> 
> OCB3 is realistically what we should be using provided the IPR story can be cleared up.
>  
> -- 
> Tony Arcieri

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 8 Mar 2019 19:14:56 +0000

FWIW, I'd prefer have fewer and not more modes of operation
documented. I'm not aware of a need for what this draft
appears to specify (based on reading just the abstract). I
also agree the OCB IPR situation isn't clear (IIRC more than
just Rogaway's IPR was involved).

I also don't see a need to document rc5/6 test vectors in
an RFC as they're not really used in Internet protocols
afaik. (If that last was wrong my position on that one could
change.)

For those reasons I'd suggest that the world would be better
if the ISE decided not to publish either.

I'd also argue that the IETF will be generally better off if
we route crypto algorithm/mode and related RFCs via CFRG. That
way we can be more confident of the level of scrutiny and
openness associated with the set of such RFCs. That is a change
from what we (the IETF) used do, which was to send such stuff
to the ISE.

I think it'd be great if we(*) came to consensus that via-CFRG
is a better route for all/almost-all such RFCs than via-ISE.

Cheers,
S.

(*) "we" would I guess need to include the ISE, sec-ads and CFRG.

---

From: Tony Arcieri <[email-masked]>
Date: Fri, 8 Mar 2019 12:33:53 -0800

> just Rogaway's IPR was involved).

Rogaway has a pretty detailed description of the IPR situation on the OCB
site:

http://web.cs.ucdavis.edu/~rogaway/ocb/ocb-back.htm

— snip —
Does Phil have a patent on OCB? Yes, I did file patent applications
covering the new techniques used in OCB. There was a filing on 12 October
2000, and a filing on 9 February 2001. If you want to use OCB in a
commercial product, you'll need to get a license from me. But I'll license
this IP under fair, reasonable, and non-discriminatory terms. All companies
will be offered the same license agreement. I expect licensees to pay a
modest, one-time fee.

Here is a patent-assurance letter
<http://web.cs.ucdavis.edu/~rogaway/ocb/ieee.pdf> I wrote for the IEEE,
which mandates OCB in a *draft*802.11 (Wireless LAN) standard, as part of
the WEP ("Wired Equivalent Privacy") protocol.
How much will a license cost? Not much. I intend that no solvent company
should find licensing from me to be a significant issue in their cost of
doing business. Here is an offer letter
<http://web.cs.ucdavis.edu/~rogaway/ocb/offer.pdf> indicating how I am
licensing OCB.Has OCB already been licensed? Yes, it has. But,
unfortunately, I am not at liberty to say more.Will anyone else come to
have a valid patent that covers OCB? Unfortunately, this question is
impossible to answer at this point. IBM has indicated that it has a patent
filing that covers Jutla's authenticated-encryption work. They indicate
that this was filed on 14 April 2000. Gligor has indicated that he has
three patent filings that cover his authenticated-encryption and
parallelizable MAC work. He indicates that these were filed on 31 January
2000, 31 March 2000, and 24 August 2000. All of these filings were
provisional patent filings.

One can only conjecture who will have what enforceable rights. As for
Jutla/IBM, I have been clear all along that OCB retains similarities to
Jutla's IAPM. Intellectually, OCB owes much to Jutla's work. But whether or
not IBM's patent covers OCB may depend on how broadly IBM's claims were
crafted.

As for Gligor/VDG, I am unaware of any idea from [Gligor, Donescu; 18
August 2000] that I used in OCB. I believe that any utility patent filed
after Jutla's work and my work appeared but based on a provisional patent
filed before Jutla's work and my work appeared will need to be examined
with care, comparing the contents of the utility patent to the contents of
the provisional patent, and paying attention to what was published in the
interval. Such an exercise is currently impossible, because provisional
patents are not made available before utility patents issue.

I start to think that I have been too talkative and too concerned about
what IP other parties could come to hold. In truth, nobody ever knows the
answer to this question.
-- 
Tony Arcieri

---

From: John Mattsson <[email-masked]>
Date: Sat, 9 Mar 2019 00:11:03 +0000

Given that CFRG has already published OCB3 in RFC 7253, which was recently included in the CEASAR final portfolio, I would like to see the OCB3 wideblock draft published somewhere. I agree with Rich that it would be better to replace RFC 7523.

Reading RFC 7523 again, it does not feel optimal that the two slightly different modes defined in RFC 7523 and the FSE 2011 paper are both called OCB3.

The OCB wideblock document seems to meet the requirements in RFC 4846.

/John

-----Original Message-----
From: Cfrg <[email-masked]> on behalf of David Wong <[email-masked]>
Date: Friday, 8 March 2019 at 19:11
To: "Salz, Rich" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Cfrg] ISE seeks help with some crypto drafts

David

---

From: Tony Arcieri <[email-masked]>
Date: Fri, 8 Mar 2019 17:32:36 -0800

Given this, and perhaps temporarily suspending discussion of the Jutla and
Grigor patents, I'm curious what kind of IPR statement would be needed from
Rogaway to alleviate concerns about his specific patents.

On Fri, Mar 8, 2019 at 4:11 PM John Mattsson <[email-masked]>
wrote:

> Given that CFRG has already published OCB3 in RFC 7253, which was recently
> included in the CEASAR final portfolio, I would like to see the OCB3
> wideblock draft published somewhere. I agree with Rich that it would be
> better to replace RFC 7523.
>
> Reading RFC 7523 again, it does not feel optimal that the two slightly
> different modes defined in RFC 7523 and the FSE 2011 paper are both called
> OCB3.
>
> Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>,
> "[email-masked]" <[email-masked]>, "[email-masked]" <
> [email-masked]>
> Note that OCB was chose as a finalist in the CAESAR competition. Knowing
> that, it sounds like a good idea to standardize it.
>
> On the other hand, if I understand correctly you need to pay a one-time
> fee to use the algorithm in a commercial product? I think that’s a big
> no-no considering we want everybody to use good open source libraries.
>
> David
>
> > I would rather see this rewritten to completely replace 7523 (and
> include its test vectors of course)  Would review.
> >

-- 
Tony Arcieri

---

From: Aaron Zauner <[email-masked]>
Date: Sat, 9 Mar 2019 12:36:01 +0100

Hi,

I see some really misinformed comments in this thread.

There’s a general IPR exemption for OCB(3) for IETF by Rogaway and the IBM Corporation (Jutla), which is everything that’s necessary to go ahead and stanardize and use that mode. I’ve previously spent quite some time cultivating a AES-OCB ciphersuite draft* for TLS 1.2 (not necessary for 1.3 IMO) as an alternative to GCM. Unfortunately back very few people really seemed to understand why I’m working on this and only a handful were really interested with the whole standardidzation of TLS 1.3 going on and lots of custom $vendor extensions being discussed. I was thinking to pick this up again as it’d make sense  for TLS 1.2 still and as OCB3 is a CEASAR finalist there’s something new to add to the paper (and the security section w.r.t. OCB2 attacks - where I agree with Tony - have nothing to do with OCB3 from what I could tell reading them), anyway. The IPR exemptions are over here: https://datatracker.ietf.org/ipr/search/?id=draft-zauner-tls-aes-ocb&submit=draft

It took IBM lawyers quite a while working this out but after I contacted Rogaway he was very forthcoming and came up with that exemption within a few weeks of initially talking to him about the topic in general, as was Jutla once contacted by Rogaway (working at IBM, he had to contact legal and go through all kinds of bureaucracy from what I understood).

Hope that helps to clear things up a bit.

Greetings,
Aaron 

* https://datatracker.ietf.org/doc/draft-zauner-tls-aes-ocb/

---

From: Aaron Zauner <[email-masked]>
Date: Sat, 9 Mar 2019 12:59:27 +0100

Hi,

PS: I forgot to mention that OCB3 is standardized within IETF in RFC7253 (https://tools.ietf.org/html/rfc7253).

Aaron

---

From: Aaron Zauner <[email-masked]>
Date: Sat, 9 Mar 2019 13:53:48 +0100

> On 09.03.2019, at 02:32, Tony Arcieri <[email-masked]> wrote:
> 
> Given this, and perhaps temporarily suspending discussion of the Jutla and Grigor patents, I'm curious what kind of IPR statement would be needed from Rogaway to alleviate concerns about his specific patents.

As far as I can remember the Grigor patents were only very very vaguely related to OCB with Rogaway filing a similar patent even before they did. So that’s something patent lawyers would have to fight over and work out, Rogaway told me back then that he isn’t worried about these patents. Also they expire in 2021.

Aaron

---

From: mcgrew <[email-masked]>
Date: Sat, 9 Mar 2019 08:25:26 -0500

Hi Aaron,

The IPR statements for your draft seem to only cover the use of OCB in TLS, and not its use outside that context.   I am not a lawyer, but that is how I would understand the phrase “a royalty-free non-exclusive license to all claims of the referenced patents needed to realize a fully compliant implementation of TLS (Transport Layer Security) supporting AES-OCB (RFC 7253)”.   This point might not matter to the implementers of your draft, but it might matter a lot to other people.  

For anyone researching the IPR status of RFC 7253, please note that Phil submitted several IPR statements IPR statements related to (the draft version of) that specification, which can be found with this search: https://datatracker.ietf.org/ipr/search/?draft=&rfc=7253&submit=rfc&doctitle=&group=&holder=&iprtitle=&patent=    

Aaron, let me also take the time to thank you for working with the patent holders to get the IPR statements issued for your draft (and thanks are due to the patent holders as well).   

Best,

David

> On Mar 9, 2019, at 6:36 AM, Aaron Zauner <[email-masked]> wrote:
> 
> Hi,
>

---

From: Aaron Zauner <[email-masked]>
Date: Sat, 9 Mar 2019 16:25:47 +0100

Hi David,

> On 09.03.2019, at 14:25, mcgrew <[email-masked]> wrote:
> 
> Hi Aaron,
> 

That’s correct. My bad, the initial text was supposed to say "general IPR exemption for OCB(3) in TLS for IETF”. I wrote & edited that mail right after getting up and must have removed that editing this message and moving sentences around in an attempt to make it more coherent :)

> For anyone researching the IPR status of RFC 7253, please note that Phil submitted several IPR statements IPR statements related to (the draft version of) that specification, which can be found wit…

Yes, you can find all of Rogaway’s IPR claims pertaining IETF documents via: https://datatracker.ietf.org/ipr/search/?draft=&rfc=&doctitle=&group=&holder=Phillip+Rogaway&submit=holder&iprtitle=&patent=

> Aaron, let me also take the time to thank you for working with the patent holders to get the IPR statements issued for your draft (and thanks are due to the patent holders as well).   

It was quite an interesting experience and I hope that writing it up can serve others in the future. My impression is that it’s not difficult to get an IPR exemption if the people behind the original work are intrested in it being used. I think Rogaway had just the best intentions at heart with the original licensing, but may have missed that it’ll cause issues with standardization processes in the future/real world that may have an adverse impact on the use of OCB3. He’s granted free licenses to Open-source implementations and other projects and organizations since. OCB3 (and my draft) were also implemented in various libraries, among them OpenSSL (C), Botan (C++) and BouncyCastle (Java). Back when they optimized it OCB even beat GCM w.r.t. performance in OpenSSL on Haswell Intel x86_64 processors and has since kept up pretty well consindering AESNI is aimed at GCM/GHASH (see head comment on performance in https://github.com/openssl/openssl/blob/master/crypto/aes/asm/aesni-x86_64.pl).

```
  *) Added support for OCB mode. OpenSSL has been granted a patent license
     compatible with the OpenSSL license for use of OCB. Details are available
     at https://www.openssl.org/source/OCB-patent-grant-OpenSSL.pdf. Support
     for OCB can be removed by calling config with no-ocb.
     [Matt Caswell]
``` — https://www.openssl.org/news/cl111.txt (in "Changes between 1.0.2h and 1.1.0  [25 Aug 2016]”)

Aaron

---

From: Tony Arcieri <[email-masked]>
Date: Sat, 9 Mar 2019 10:26:17 -0800

On Sat, Mar 9, 2019 at 7:25 AM Aaron Zauner <[email-masked]> wrote:

> > The IPR statements for your draft seem to only cover the use of OCB in
> TLS, and not its use outside that context.   I am not a lawyer, but that is
> how I would understand the phrase “a royalty-free non-exclusive license to
> all claims of the referenced patents needed to realize a fully compliant
> implementation of TLS (Transport Layer Security) supporting AES-OCB (RFC
> 7253)”.   This point might not matter to the implementers of your draft,
> but it might matter a lot to other people.
>
> That’s correct. My bad, the initial text was supposed to say "general IPR
> exemption for OCB(3) in TLS for IETF”. I wrote & edited that mail right
> after getting up and must have removed that editing this message and moving
> sentences around in an attempt to make it more coherent :)

I asked Rogaway about this...

How would people feel if he extended this IPR exemption to any standards
track protocol developed by the IETF? Would that be sufficient?

---

From: Ted Krovetz <[email-masked]>
Date: Sat, 9 Mar 2019 13:05:46 -0800

> On Mar 8, 2019, at 4:11 PM, John Mattsson <[email-masked]> wrote:
> 

> I don't see a compelling need for this, but I am not strongly opposed either.

I would be happy to merge the wideblock modifications into RFC 7253. I was unaware that such changes were allowed for RFCs after publication, but if it is allowed it seems like a sensible approach. I am currently half-way through a busy semester so would not be able to get to it until May though.

As for the RC5/RC6 draft, I introduced it so that I would have a simple example block cipher for generating test vectors of different lengths. If it's not useful as a stand alone RFC, I could fold it into an appendix of a revised RFC 7253 or take suggestions for other applicable block ciphers with stable normative references. A more compact alternative to using a real block cipher for test vectors is to use a toy stand-in such as E(k,x) = x*k over GF(2^n).

Thank you for all of your feedback,
Ted

---

From: "Paul Hoffman" <[email-masked]>
Date: Sun, 10 Mar 2019 07:07:58 +0900

On 9 Mar 2019, at 20:59, Aaron Zauner wrote:

> PS: I forgot to mention that OCB3 is standardized within IETF in 
> RFC7253 (https://tools.ietf.org/html/rfc7253).

RFC 7253 is not a standard: it is an Informational document. This is not 
just another "that's just semantics" statement because Tony Arcieri then 
followed with:

> How would people feel if he extended this IPR exemption to any 
> standards track protocol developed by the IETF? Would that be 
> sufficient?

The answer to "is TLS 1.3 (a standard) using OCB3 (no a standard) a 
standards-track protocol" is not obvious. Well, some people would say it 
is obvious, but would disagree on the value of the boolean response.

--Paul Hoffman

---

From: Tony Arcieri <[email-masked]>
Date: Sat, 9 Mar 2019 14:17:45 -0800

> is obvious, but would disagree on the value of the boolean response.

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.

-- 
Tony Arcieri

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Sun, 10 Mar 2019 02:17:31 +0000

I would be OK with that statement.

--

Regards,

Uri 

From: Cfrg <[email-masked]> on behalf of Tony Arcieri <[email-masked]>
Date: Saturday, March 9, 201910 at 17:18
To: Paul Hoffman <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, CFRG <[email-masked]>, "RFC ISE (Adrian Farrel)" <[email-masked]>, secdir <[email-masked]>
Subject: Re: [Cfrg] ISE seeks help with some crypto drafts

 "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.

-- 

Tony Arcieri

---

From: Paul Wouters <[email-masked]>
Date: Sat, 9 Mar 2019 21:47:02 -0500 (EST)

On Sat, 9 Mar 2019, Tony Arcieri wrote:

>  "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)."
> 

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

---

From: Watson Ladd <[email-masked]>
Date: Sat, 9 Mar 2019 18:55:58 -0800

On Sat, Mar 9, 2019, 6:47 PM Paul Wouters <[email-masked]> wrote:

> >  "Phillip Rogaway offers a royalty-free non-exclusive license to all
> claims of the referenced patents needed to realize a fully compliant
> anyone has a more concrete suggestion for how to put it in the
> > form of an IPR statement.
>

I read the above differently: the specification it refers to is not of OCB
but the IETF protocol which the IP statement clearly permits royalty free
usage and hence OCB is acceptable.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Sun, 10 Mar 2019 02:59:23 +0000

It *can* be "freely used". That's the point of updating the IPR to make sure it is so.

What happens to OCB use *outside* of the IETF standards is a separate question, which I don't care to entertain here and now.
--
Regards,
Uri
<Standard Disclaimer>

---

From: Paul Wouters <[email-masked]>
Date: Sat, 9 Mar 2019 22:39:32 -0500 (EST)

> What happens to OCB use *outside* of the IETF standards is a separate question, which I don't care to entertain here and now.

But what does "outside the IETF" mean with respect to draft-krovetz-ocb-wideblock ?

It defines a cryptographic blockcipher method, not an internet protocol.

Does this mean this cryptographic blockcipher method used in a proprietary
or non-IETF standards or IETF experiments falls within or outside the
IETF for the purpose of licensing?

note I just realised Rich wasn't to blame when pointing me to RFC 7523,
instead of 7253, as the actual draft-krovetz-ocb-wideblock-00 makes that
mistake)

Paul

---

From: "Paul Hoffman" <[email-masked]>
Date: Sun, 10 Mar 2019 14:53:26 +0900

On 10 Mar 2019, at 11:47, Paul Wouters wrote:

> standard that cannot be freely used.

That's a fine request, but not really relevant to a thread that is a 
request from the ISE.

--Paul Hoffman

---

From: S Moonesamy <[email-masked]>
Date: Sat, 09 Mar 2019 22:08:49 -0800

Hi Paul,
>IETF for the purpose of licensing?

draft-krovetz-ocb-wideblock-00 extends RFC 7253.  Both documents are 
not (IETF) standards.

>instead of 7253, as the actual draft-krovetz-ocb-wideblock-00 makes that

The draft should reference RFC 7253 instead of RFC 7523.

Regards,
S. Moonesamy

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 10 Mar 2019 13:29:35 -0500

> just Rogaway's IPR was involved).

My reading also failed to find a great deal of motivation for needing the
new modes.

I also found it interesting that the "wideblock" draft also specifies
narrow blocks, and that we've had some contentious discussions in the I*TF
in the past about narrow-block ciphers.

We always need to balance the flexibility of having specifications for new
modes against the risk to interoperability of having too many modes.  Given
what's in these documents at present, my personal sense is that the
tradeoff weighs slightly against publishing, but there are many things that
could shift that balance.

-Ben

---

From: Uri Blumenthal <[email-masked]>
Date: Sun, 10 Mar 2019 18:33:07 +0000

For practical use blocks wider than 128 (and probably wider than 256) bits are necessary. For analytical work, narrow blocks are needed.

Sent from my test iPhone

> On Mar 10, 2019, at 14:29, Benjamin Kaduk <[email-masked]> wrote:
> 
> secdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

---

From: Ted Krovetz <[email-masked]>
Date: Sun, 10 Mar 2019 12:05:23 -0700

> On Mar 10, 2019, at 11:29 AM, Benjamin Kaduk <[email-masked]> wrote:
> 
> failed to find a great deal of motivation for needing the new modes

I would like to remind everyone that OCB is not a "new mode". It is specified in RFC 7253. This work generalizes the specification -- without changing the 128-bit block case -- to allow other block cipher block lengths.

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 10 Mar 2019 14:10:27 -0500

> I would like to remind everyone that OCB is not a "new mode". It is specified in RFC 7253. This work generalizes the specification -- without changing the 128-bit block case -- to allow other block…

It's still a "distinct choice that a protocol designer (or user) picking a
cipher has available to choose from", which is where the perceived downside
of new things comes from.  My apologies for conflating the technical term
with the generic.

-Ben

---

From: Tony Arcieri <[email-masked]>
Date: Sun, 10 Mar 2019 13:57:53 -0700

On Sun, Mar 10, 2019 at 12:10 PM Benjamin Kaduk <[email-masked]> wrote:

> > I would like to remind everyone that OCB is not a "new mode". It is
> specified in RFC 7253. This work generalizes the specification -- without
> changing the 128-bit block case -- to allow other block cipher block
> lengths.
>

I think there are significant compelling reasons to prefer OCB mode over
pretty much all other existing modes:

- Recent CAESAR winner (one of many in the portfolio, but)
- Fast anywhere AES is fast. No CLMUL required (good for embedded)
- Well-studied: IMO OCB is more likely than not be covered in
classes/textbooks on symmetric cryptography

I think the IPR concerns are the main reason it has not seen more
widespread adoption.

If you were to ask me "Is it better than AES-GCM?", my answer is yes. OCB
hits the sweet spot of being a construction which is "fast everywhere", as
opposed to the split between AES-GCM and AES-CCM we see between
desktops/servers/high-end mobile vs embedded devices.

The wide block modes are a different question. I think they're potentially
interesting in use cases I'm not particularly familiar with (e.g. mixnets).
I'm not going to be the one to champion those through the CFRG, though.

That said, the inability to use OCB mode in IETF protocols (due to IPR
concerns) is a travesty, and hopefully one we can clear up.

--
Tony Arcieri

---

From: Uri Blumenthal <[email-masked]>
Date: Sun, 10 Mar 2019 21:41:52 +0000

Completely agree with your OCB points. It looks like the IPR issues would be resolved fairly quickly.

As for the wideblock mods - I'm perfectly willing to champion it at CFRG, if a champion is needed.  As I said, while it's not likely to apply to, e g., TLS  1.4 - there are use cases today, and I expect to see more in the future.

Sent from my test iPhone

> On Mar 10, 2019, at 16:58, Tony Arcieri <[email-masked]> wrote:
> 
> I think there are significant compelling reasons to prefer OCB mode over pretty much all other existing modes:
> 
> - Well-studied: IMO OCB is more likely than not be covered in classes/textbooks on symmetric cryptography
> 
> I think the IPR concerns are the main reason it has not seen more widespread adoption.
> 
> If you were to ask me "Is it better than AES-GCM?", my answer is yes. OCB hits the sweet spot of being a construction which is "fast everywhere", as opposed to the split between AES-GCM and AES-CCM we see between desktops/servers/high-end mobile vs embedded devices.
> 
> The wide block modes are a different question. I think they're potentially interesting in use cases I'm not particularly familiar with (e.g. mixnets). I'm not going to be the one to champion those through the CFRG, though.
> 
> That said, the inability to use OCB mode in IETF protocols (due to IPR concerns) is a travesty, and hopefully one we can clear up.
> 
> --
> Tony Arcieri

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 10 Mar 2019 21:47:22 +0000

Hiya,

On 10/03/2019 20:57, Tony Arcieri wrote:
> 
> I think there are significant compelling reasons to prefer OCB mode 
> over pretty much all other existing modes:

FWIW, I don't, because we're not dealing with a clean slate.

In the IETF context, whether or not OCB is a bit better
then currently deployed modes is not an interesting
question.

One interesting question might be: is OCB so much better
that it could we displace uses of some existing mode with
OCB. That seems unlikely to me for the widely used modes.

Another interesting question might be: is OCB so much
better that we want to deploy it alongside current modes.
I don't see the overall benefit of that myself.

So even though I'm happy to accept that OCB has better
properties than e.g. GCM, I don't think it's so much
better that RFCs for it are that useful.

That said, if the RFC for such a thing said "this is nice
for brand new stuff (although library support will be less
comprehensive) but is not worth the costs associated
with adding it to existing protocols" then I'd be less
against such RFCs being produced. Understandably enough,
that kind of statement doesn't get added to such RFCs;-)

S.

PS: In case the ISE is still listening, the above is a
reason why I think having CFRG produce this kind of RFC
(instead of routing 'em via the ISE) would be a better
plan. CFRG could (I think) likely reach better informed
judgements (in the open) as to whether or not some crypto
technique is really worth documenting in an RFC.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Sun, 10 Mar 2019 22:30:17 +0000

Stephen,

I think the answer to all of your "interesting questions" is yes, IMHO. 

IMHO, the main reason it did not fly high back then was it's IPR - but that's been addressed for some protocols (e.g., TLS), and is being addressed now for wider IETF adoption.

Regards,
Uri

Sent from my iPhone

> On Mar 10, 2019, at 17:48, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 
> <0x5AB2FAF17B172BEA.asc>

---

From: Tony Arcieri <[email-masked]>
Date: Sun, 10 Mar 2019 15:31:12 -0700

> better that RFCs for it are that useful.

Let me provide some context here with a survey of existing modes and
explain why OCB is interesting:

- AES-GCM: exceedingly common on desktop/laptop/server-class computers and
high-end mobile phones. Provides performance roughly equivalent to the
underlying AES function on these devices, provided they have a superscalar
architecture and have (P)CLMUL(QDQ) units which can be used in parallel
with the units that perform AES
- AES-CCM: exceedingly common in the embedded space. This is due in part to
two things: FIPS regulations and the number of embedded devices they apply
to (smartcards and other security tokens, as well as things like HSMs), but
also because embedded CPUs/uCs generally will perform quite poorly at
AES-GCM
- ChaCha20+Poly1305: extremely simple authenticated encryption based in a
tiny core ARX primitive for encryption and universal hashing for
authentication. Extremely fast in software, but slower than hardware
accelerated primitives

These modes have a sort of triangle of tradeoffs:

- AES-GCM is fast if and only if you have a superscalar CPU with both
hardware AES and CLMUL
- AES-CCM is fast (faster than ChaCha20Poly1305) if you have hardware
accelerated AES, but runs the AES encryption twice as many times as
AES-GCM, and has a non-parallelizable encryption function
- ChaCha20Poly1305 is faster than AES-GCM on devices that do not have CLMUL
support, but slower than AES-CCM on devices which have hardware AES support

Hardware AES support has been steadfastly improving over many years and is
available in all but the cheapest microcontrollers (i.e. even where there
are cheap uCs without it, there is often a "crypto accelerator" model of
the same uC which does).

When hardware AES is available, OCB "squares the triangle" so to speak, and
provides a sort of force multiplier where the other modes have tradeoffs.

For new protocols which are shooting for "ubiquitous deployment", i.e.
targeting servers/laptops/desktops, mobile phones, *and* the embedded
space, and want one mode that "works well everywhere", this makes OCB an
ideal candidate.

It'd be good to handle the cases that hardware AES isn't available, and
also have a "fallback cipher" on the outside chance some horrible
cryptanalysis disaster befalls OCB, so you'd still want to pair it with
ChaCha20+Poly1305 as a backup cipher. That said, for those protocols who
would rather simplify cipher selection rather than having a backup card in
their pocket, OCB is a particularly attractive mode for "One True
Ciphersuite" (a.k.a. 1TCS) protocols.

---

From: "StJohns, Michael" <[email-masked]>
Date: Sun, 10 Mar 2019 18:45:08 -0400

I’ve been wondering for a while now whether it’s time to move the CFRG over
to the IETF as a working group.  Stephen’s comment on routing stuff
directly to the CFRG suggests to me that it’s probably time or RSN.

   In recent years, the CFRG has produced documents that are for lack of a
better phrase de facto standards.  The rate of document production of the
CFRG mimics more closely that of a WG than the other extant RGs AFAICT.
As an RG the CFRG isn’t permitted to publish standards track documents, nor
is the IESG or the ISE permitted or constrained to require a conflict
review on the documents the CFRG does produce.  [the latter comment is my
understanding of the rules of the research stream - it may be flawed, but
the purpose of RGs is supposed to be looking at futures and that by
definition shouldn’t be conflicting with the nows].

An alternative might be to charter a crypto standards WG and try to keep
the CFRG focused on years out - say how the heck do we deal with the
quantum apocalypse?

Or keep the math in CFRG and the on the wire specs for using in a WG.

Discuss!

Mike

---

From: Tony Arcieri <[email-masked]>
Date: Sun, 10 Mar 2019 16:20:01 -0700

> definition shouldn’t be conflicting with the nows].

An interesting datapoint on this is Dragonfly key exchange, published as
RFC 7664, has now been incorporated into the Wifi Alliance's WPA3 standard:

https://sarwiki.informatik.hu-berlin.de/WPA3_Dragonfly_Handshake

I will preface the following statement by saying that my criticisms of
Dragonfly on the CFRG list at the time were misinformed and due to a lack
of understanding, and would now call it "okay" (and many of my concerns
were assuaged after it received a security proof). However, I think it's
fair to say that as a non-standards document, it has something of a sordid
history:

https://arstechnica.com/information-technology/2013/12/critics-nsa-agent-co-chairing-key-crypto-standards-body-should-be-removed/

I think if there were a WG chartered specifically with a standards-track
document for what the next generation key exchange to be used for use cases
similar to and including, but not limited to WiFi were, my best guess is we
could've done better than Dragonfly. I'm not sure why the Wifi Alliance
chose it specifically, but it seems the CFRG was treated at least in part
as a bar the algorithm must pass for incorporation into their standards,
and for a standard of such importance I guess what I'm saying is I wish
that bar were higher.

-- 
Tony Arcieri

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Sun, 10 Mar 2019 23:38:29 +0000

I do not think CFRG should move to become a part of the IETF. 

While (some of) the CFRG-produced documents may be de-facto standards, they aren't of the kind that IETF is expected to define, and deal with somewhat different things.

Regards,
Uri

Sent from my iPhone

> On Mar 10, 2019, at 18:46, StJohns, Michael <[email-masked]> wrote:
> 
> I’ve been wondering for a while now whether it’s time to move the CFRG over to the IETF as a working group.  Stephen’s comment on routing stuff directly to the CFRG suggests to me that it’s probably time or RSN. 
> 
>    In recent years, the CFRG has produced documents that are for lack of a better phrase de facto standards.  The rate of document production of the CFRG mimics more closely that of a WG than the other extant RGs AFAICT.   As an RG the CFRG isn’t permitted to publish standards track documents, nor is the IESG or the ISE permitted or constrained to require a conflict review on the documents the CFRG does produce.  [the latter comment is my understanding of the rules of the research stream - it may be flawed, but the purpose of RGs is supposed to be looking at futures and that by definition shouldn’t be conflicting with the nows].  
> 
> An alternative might be to charter a crypto standards WG and try to keep the CFRG focused on years out - say how the heck do we deal with the quantum apocalypse?
> 
>> On Sun, Mar 10, 2019 at 17:48 Stephen Farrell <[email-masked]> wrote:
>> 
>> Hiya,
>>

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 11 Mar 2019 00:07:57 +0000

Tony Arcieri <[email-masked]> writes:

>"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)."

That's still not going to work, for two reasons.  This first is that it
misunderstands how an implementation of, say, TLS works.  Virtually all TLS
implementations aren't a monolithic TLS-only code block but are built on top
of a general-purpose crypto library, for Windows CryptoAPI, for everything
else OpenSSL, Crypto++, mbedTLS, PKCS #11, my own cryptlib, etc. Taking the
vendor-neutral PKCS #11 as an example, what the above is requiring is an
implementation of Maxwell's demon in software, that a PKCS #11 library be able
to tell whether the handle from C_CreateObject( &handle, { CKA_KEY_TYPE, key,
CKK_AES_OCB } ) will be used to encrypt TLS data (OK) or non-TLS data (not
OK).

The second is legal.  Any commercial user of whatever the crypto library is is
going to get their lawyers to look at that requirement and have a fit, not
even because of the above very technical problem but just from the knowledge
that they'll be running code that, at the slightest glitch, will potentially
expose them to a patent lawsuit.  I've seen companies spend 1-2 years debating
whether using generic permissive BSD-licensed code is safe, and now they'll be
asked to decide whether the risk in the above is worthwhile because blah blah
geekspeak geekspeak, for which the answer will most likely be "no".

I'd love to use OCB, it's a really nice, elegant mode, but unfortunately
unless the usage conditions are "freely available without restrictions" I
can't.  And that's not from rabid freetardism, it's from pragmatism, it's too
risky legally.

Peter.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 11 Mar 2019 01:38:10 +0000

Any codepoints for those ciphers will got an "N" in the recommended  column, because the definitions are part of a standards-track RFC.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 11 Mar 2019 01:40:42 +0000

I think the IESG should ask our legal counsel for wording advice.

---

From: John Mattsson <[email-masked]>
Date: Mon, 11 Mar 2019 07:07:24 +0000

I think it is much more important that CFRG stays a Research Group, than it is that CFRG can produce standards track documents. CFRG is unique and fills a very important roll. The fact that CFRG documents are used so much indicates to me that CFRG is working very well. I would be very hesitant in changing something that works.

Cheers,
John

From: Cfrg <[email-masked]> on behalf of "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Monday, 11 March 2019 at 00:39
To: "StJohns, Michael" <[email-masked]>
Cc: secdir <[email-masked]>, CFRG <[email-masked]>, "RFC ISE (Adrian Farrel)" <[email-masked]>
Subject: Re: [Cfrg] Time to recharter CFRG as a working group? Was: Re: [secdir] ISE seeks help with some crypto drafts

Sent from my iPhone

On Mar 10, 2019, at 18:46, StJohns, Michael <[email-masked]<mailto:[email-masked]>> wrote:
I’ve been wondering for a while now whether it’s time to move the CFRG over to the IETF as a working group.  Stephen’s comment on routing stuff directly to the CFRG suggests to me that it’s probably time or RSN.

Discuss!

Mike

On Sun, Mar 10, 2019 at 17:48 Stephen Farrell <[email-masked]<mailto:[email-masked]>> wrote:

Hiya,

S.

_______________________________________________
Cfrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/cfrg
_______________________________________________
Cfrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/cfrg

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 11 Mar 2019 11:07:22 +0300

Hi Ben,

> > I would like to remind everyone that OCB is not a "new mode". It is specified in RFC 7253. This work
> generalizes the specification -- without changing the 128-bit block case -- to allow other block cipher block
> lengths.
> 

I agree that having more options generally complicates protocol designer's life.
Unless the choices have really different properties (it terms of security, performance, 
resources consumption etc.) which are clearly explained, so that 
the designer can make a conscious choice.

Regards,
Valery.

---

From: Mathy Vanhoef <[email-masked]>
Date: Mon, 11 Mar 2019 13:27:21 +0400

Regarding the Dragonfly datapoint: this protocol already got added to the
802.11 standard in 2011 under the 802.11s amendment. As far as I know, I
only got discussed by the CFRG after this.

On Mon, Mar 11, 2019 at 3:20 AM Tony Arcieri <[email-masked]> wrote:

> were assuaged after it received a security proof).. However, I think it's

---

From: Michael StJohns <[email-masked]>
Date: Tue, 12 Mar 2019 14:11:30 -0400

On 3/10/2019 7:38 PM, Blumenthal, Uri - 0553 - MITLL wrote:
> While (some of) the CFRG-produced documents may be de-facto standards, 
> they aren't of the kind that IETF is expected to define, and deal with 
> somewhat different things.

My point is that the CFRG is behaving more like a WG and should be 
following WG rules and not RG rules.    The charter for the CFRG 
basically says it can bring stuff that's been published elsewhere ("... 
via Informational RFCs (in the tradition of, e.g., RFC 1321 (MD5) and 
RFC 2104 (HMAC)."), but has become the first publisher for a few things 
that weren't mere republications but involved setting on-the-wire/on 
disk formats (e.g., Curve25519 and related) that have been accepted as 
de-facto standards.  Then there's the requirements setting documents.  
If these were just math publications with the bits and bytes formats 
published in the IETF, that would be fine - but that doesn't appear to 
be what's happening.

Now Stephen is suggesting that the CFRG become the filter through which 
all crypto related things are brought to the IETF or independent 
stream.  Two things - CFRG is not in the IETF, and that's not the 
general purpose of a research group.   Rechartering the CFRG (or part of 
it) as a WG following WG rules would at least fix that problem.

A third possibility (the first was rechartering, the second was 
splitting into a IETF WG and an IRTF RG), is dual chartering the CFRG as 
both a RG and a WG. It would allow/require the group to produce actual 
standards, but also to keep on with it's more researchy tasks.

The fourth possibility is doing a better job of referring the less 
research/more practical bit and byte on the wire documents to the IETF 
rather than keeping them and also leave the filtering to the IETF groups 
such as secdispatch or saag.

Later, Mike

>> I’ve been wondering for a while now whether it’s time to move the 
>> CFRG over to the IETF as a working group.  Stephen’s comment on 
>> routing stuff directly to the CFRG suggests to me that it’s probably 
>> time or RSN.
>>
>>    In recent years, the CFRG has produced documents that are for lack 
>> of a better phrase de facto standards.  The rate of document 
>> production of the CFRG mimics more closely that of a WG than the 
>> other extant RGs AFAICT.   As an RG the CFRG isn’t permitted to 
>> publish standards track documents, nor is the IESG or the ISE 
>> permitted or constrained to require a conflict review on the 
>> documents the CFRG does produce.  [the latter comment is my 
>> understanding of the rules of the research stream - it may be flawed, 
>> but the purpose of RGs is supposed to be looking at futures and that 
>> by definition shouldn’t be conflicting with the nows].
>>
>> An alternative might be to charter a crypto standards WG and try to 
>> keep the CFRG focused on years out - say how the heck do we deal with 
>> the quantum apocalypse?
>>
>> On Sun, Mar 10, 2019 at 17:48 Stephen Farrell 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>
>>

---

From: Richard Barnes <[email-masked]>
Date: Tue, 12 Mar 2019 14:56:38 -0400

Big +1 here.  It's not broke, so let's not fix it, especially for purely
process-wonk reasons.

On Mon, Mar 11, 2019 at 3:08 AM John Mattsson <[email-masked]>
wrote:

> I think it is much more important that CFRG stays a Research Group, than
> it is that CFRG can produce standards track documents. CFRG is unique and
> fills a very important roll. The fact that CFRG documents are used so much
> indicates to me that CFRG is working very well. I would be very hesitant in
> changing something that works.
>
>
>
> Cheers,
>
> John
>
>
>
> *From: *Cfrg <[email-masked]> on behalf of "Blumenthal, Uri - 0553
> - MITLL" <[email-masked]>
> *Date: *Monday, 11 March 2019 at 00:39
> *To: *"StJohns, Michael" <[email-masked]>
> *Cc: *secdir <[email-masked]>, CFRG <[email-masked]>, "RFC ISE (Adrian
> Farrel)" <[email-masked]>
> *Subject: *Re: [Cfrg] Time to recharter CFRG as a working group? Was: Re:
> [secdir] ISE seeks help with some crypto drafts
>
>
>
> I’ve been wondering for a while now whether it’s time to move the CFRG
> over to the IETF as a working group.  Stephen’s comment on routing stuff

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 12 Mar 2019 19:02:17 +0000

*   Big +1 here.  It's not broke, so let's not fix it, especially for purely process-wonk reasons.

Super-singular-isogeny-strong agreement.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 12 Mar 2019 20:31:33 +0000

> Super-singular-isogeny-strong agreement.

FWIW, I also agree. CFRG's doing well. I see no need for it to
be a WG and I think there are advantages in it being an RG, e.g.
it may smooth interaction with academic cryptographers a bit.
(If there were a groundswell for such a change I'd not object
but it doesn't look like it so far.)

I would still like to see almost all crypto mechanism related RFCs
come via CFRG though and not the ISE. (There'll always be the
potential for exceptions so I think "almost all" is about right.)
The kind of review one can reasonably expect for ISE publications
is no longer sufficient given that we now actually use and depend
on this crypto stuff to a far greater extent than say 10 years ago.
No disrespect to the ISE, nor the folks who volunteer to help the
ISE review stuff, but I'd be happier if we had a more open and
transparent process with broader/deeper expertise available for
reviewing. (And in fact CFRG does have such a process already.)

S.

---

From: Michael StJohns <[email-masked]>
Date: Tue, 12 Mar 2019 16:43:04 -0400

On 3/12/2019 2:56 PM, Richard Barnes wrote:
> Big +1 here.  It's not broke, so let's not fix it, especially for 
> purely process-wonk reasons.

Except its not quite just for process-wonk reasons.  The last couple of 
discussions have been about the IPR related to OCB and whether the CFRG 
should work on it because of that.   That's a perfectly fine set of 
discussions for a standards WG especially when considering which modes 
to include under recommended and mandatory to implement, but is probably 
out of place for an RG.     The RG ought to be answering the question 
"does this proposal have security flaws" and not "has the patent expired 
on this" but we seem to be getting far past the "discussing and 
analyzing" part of the CFRG charter?

> Our goal is to provide a forum for discussing and analyzing general
> cryptographic aspects of security protocols, and to offer guidance on the use
> of emerging mechanisms and new uses of existing mechanisms.

I'd really like the CFRG to continue to be a place where anything 
cryptographic can be brought to be evaluated on its merits - but that - 
IMHO - doesn't seem to be the recent trend.

I note that the CFRG has already published RFC7253 on OCB and the IETF 
published an RFC on MD5 many many years ago, so unless there are new 
security flaws in this set of documents, the answer to the ISE should be 
a no brainer of "we don't see any problems with the publication".    And 
at some point the patents *will* expire even if its not the 1-2 years 
that one poster suggested.

In any event, I'm not going to push for this at this time, but I'm still 
confused about what would have to change if the charter were turned into 
a WG charter.

Later, Mike

>
> On Mon, Mar 11, 2019 at 3:08 AM John Mattsson 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     I think it is much more important that CFRG stays a Research
>     Group, than it is that CFRG can produce standards track documents.
>     CFRG is unique and fills a very important roll. The fact that CFRG
>     documents are used so much indicates to me that CFRG is working
>     very well. I would be very hesitant in changing something that works.
>
>     Cheers,
>
>     John
>

---

From: denis bider <[email-masked]>
Date: Tue, 12 Mar 2019 20:36:52 -0500

For what it's worth, I think the counterpoint to "don't fix it if it isn't
broken" is "it's going to have to break before it's fixed".

It is not generally advisable to wait with fixing bridges until they're
actually broken, for example.

I think Michael is raising a legitimate issue and intuitively, it sounds
like the proper answer might be a dual charter as WG + RG. Perhaps this is
unusual, but it is an unusual group. I think it would be appropriate for
this group.

denis

On Tue, Mar 12, 2019 at 3:43 PM Michael StJohns <[email-masked]>
wrote:

> discussions for a standards WG especially when considering which modes to
> include under recommended and mandatory to implement, but is probably out
> of place for an RG.     The RG ought to be answering the question "does
> this proposal have security flaws" and not "has the patent expired on this"
> but we seem to be getting far past the "discussing and analyzing" part of
> the CFRG charter?
>
> security flaws in this set of documents, the answer to the ISE should be a
> no brainer of "we don't see any problems with the publication".    And at
> some point the patents *will* expire even if its not the 1-2 years that one
> poster suggested.
>
> confused about what would have to change if the charter were turned into a
> WG charter.
>
> Later, Mike
>
>
>

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 13 Mar 2019 01:45:09 +0000

Again, I respectfully disagree. 

I see the charters of IETF WG and of IRTF RG different enough, with different goals, different milestones and measurements of success, so that molding one into the other IMHO would be counterproductive and won’t make sense (I’ve been with IETF since 1992, and co-chaired an RG group for a couple of years – so I think I have at least some practical appreciation for the differences).

Feel free to create another group – say, Crypto WG in IETF, draft a charter for it, and see where people would prefer to participate. Let one of the two wither, and the other one prosper. 😉

--

Regards,

Uri 

From: Cfrg <[email-masked]> on behalf of denis bider <[email-masked]>
Date: Tuesday, March 12, 201911 at 21:38
To: Michael StJohns <[email-masked]>
Cc: secdir <[email-masked]>, CFRG <[email-masked]>, "RFC ISE (Adrian Farrel)" <[email-masked]>
Subject: Re: [Cfrg] Time to recharter CFRG as a working group? Was: Re: [secdir] ISE seeks help with some crypto drafts

For what it's worth, I think the counterpoint to "don't fix it if it isn't broken" is "it's going to have to break before it's fixed".

It is not generally advisable to wait with fixing bridges until they're actually broken, for example.

I think Michael is raising a legitimate issue and intuitively, it sounds like the proper answer might be a dual charter as WG + RG. Perhaps this is unusual, but it is an unusual group. I think it would be appropriate for this group.

denis

On Tue, Mar 12, 2019 at 3:43 PM Michael StJohns <[email-masked]> wrote:

Big +1 here.  It's not broke, so let's not fix it, especially for purely process-wonk reasons.

Except its not quite just for process-wonk reasons.  The last couple of discussions have been about the IPR related to OCB and whether the CFRG should work on it because of that.   That's a perfectly fine set of discussions for a standards WG especially when considering which modes to include under recommended and mandatory to implement, but is probably out of place for an RG.     The RG ought to be answering the question "does this proposal have security flaws" and not "has the patent expired on this" but we seem to be getting far past the "discussing and analyzing" part of the CFRG charter?
Our goal is to provide a forum for discussing and analyzing general
cryptographic aspects of security protocols, and to offer guidance on the use
of emerging mechanisms and new uses of existing mechanisms.

I'd really like the CFRG to continue to be a place where anything cryptographic can be brought to be evaluated on its merits - but that - IMHO - doesn't seem to be the recent trend.

I note that the CFRG has already published RFC7253 on OCB and the IETF published an RFC on MD5 many many years ago, so unless there are new security flaws in this set of documents, the answer to the ISE should be a no brainer of "we don't see any problems with the publication".    And at some point the patents *will* expire even if its not the 1-2 years that one poster suggested.

In any event, I'm not going to push for this at this time, but I'm still confused about what would have to change if the charter were turned into a WG charter.

Later, Mike

On Mon, Mar 11, 2019 at 3:08 AM John Mattsson <[email-masked]> wrote:

Cheers,

John

---

From: Richard Barnes <[email-masked]>
Date: Wed, 13 Mar 2019 07:32:15 -0400

Mike, are your concerns here primarily IPR related?  If that's so, then
maybe that's the level at which we should address them, as opposed to
flipping the bigger RG->WG switch.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 14 Mar 2019 09:58:32 -0400

On Tue 2019-03-12 16:43:04 -0400, Michael StJohns wrote:
> The last couple of discussions have been about the IPR related to OCB
> and whether the CFRG should work on it because of that.  That's a
> perfectly fine set of discussions for a standards WG especially when
> considering which modes to include under recommended and mandatory to
> implement, but is probably out of place for an RG.  The RG ought to be
> answering the question "does this proposal have security flaws" and
> not "has the patent expired on this" but we seem to be getting far
> past the "discussing and analyzing" part of the CFRG charter?

I'm not convinced by this line of argument.

This group answers not only "does this proposal have security flaws?"
but also "can it/will it be deployed effectively, with the security
properties we want?"  See Tony Arcieri's excellent analysis of the
tradeoffs between different modes earlier in this thread for an example.
That kind of question is not out of place for a research group -- that's
exactly the kind of practical, useful analysis we'd like to see, and i
wish all research groups were so productive.

Sadly, we live in a world where "IPR" concerns also have an impact on
this latter question, and the CFRG happens to have a pool of people with
a significant amount of knowledge about the history of cryptographic
development and deployment, some of which is occasionally useful in
analyzing IPR issues, frustrating though they may be.  It's not out of
place for the CFRG to include that aspect in its analysis.

The CFRG is working well, and has had a significant, positive impact on
the IETF over the last several years.  If adding the ability to make
"standards track" documents would help the CFRG further help the IETF,
or could encourage additional useful participation in the CFRG, let's
discuss how to do that, but i there's no need to make a constitutional
change to the CFRG just because IPR issues come up occasionally here.

       --dkg

---

From: Michael StJohns <[email-masked]>
Date: Fri, 15 Mar 2019 14:52:40 -0400

On 3/13/2019 7:32 AM, Richard Barnes wrote:
> Mike, are your concerns here primarily IPR related?  If that's so, 
> then maybe that's the level at which we should address them, as 
> opposed to flipping the bigger RG->WG switch.
>

Hi Richard -

Like I said, I'm not going to push this at this time.  But I think its 
more than just IPR - avoiding technology because of IPR is more a 
symptom (and in fact is IETF guidance rather than IRTF policy).

The CFRG has a unique position in that - unlike ANY other RG as far as I 
can tell - it's looked at as an immediate feeder for technology for the 
IETF.  If it were agnostically evaluating the crypto properties of any 
offered technology, I'd say we're good and I'd move on.  But, with the 
publication of Curve25519 and its related ... standards ..., the CFRG 
has moved from evaluation and re-publication of cryptographic standards 
developed and produced elsewhere into being the first publisher of what 
could only be characterized as standards, even if published as an 
Informational RFC in the IRTF stream.

Ultimately, I think it comes down to fairness and transparency. As an 
RG, the publications of the RG are not subject to the standards appeals 
process.  In an WG, the decision not to work on an IPR encumbered 
technology (or others such as national cryptography) MAY be appealed and 
overturned (or might not) or sponsored by an AD if there's no applicable 
or agreeable WG. There's a process for showing such decisions were made 
transparently, and with a broader audience than just the CFRG having a say.

Later, Mike

Ps - hmm... Note that the CFRG charter only mentions the IETF and not 
the IRTF....

---

From: "Paterson Kenneth" <[email-masked]>
Date: Sat, 16 Mar 2019 11:30:00 +0000

Dear Mike,

Thanks for sparking this discussion (and thanks to everyone else for engaging). The chairs have been following with interest, and have welcomed the opportunity for questions about the future constitution of CFRG to be aired.

The rough consensus of those who joined the discussion is that we should leave the status of CFRG as it is for now. 

Of course, this kind of question can and should be revisited in future. Triggers for that might include: the workload of the RG increases significantly; a spate of IPR issues arises;  the nature of the work being done in the RG changes further. (This list is intended to be illustrative rather than exhaustive.) At such a point, we can discuss again and invoke the formal procedures of the IRTF and IETF to effect changes.

Regards,

Kenny (for the chairs)

-----Original Message-----
From: Cfrg <[email-masked]> on behalf of Michael StJohns <[email-masked]>
Date: Friday, 15 March 2019 at 18:53
To: Richard Barnes <[email-masked]>
Cc: secdir <[email-masked]>, "[email-masked]" <[email-masked]>, "RFC ISE (Adrian Farrel)" <[email-masked]>
Subject: Re: [Cfrg] Time to recharter CFRG as a working group? Was: Re: [secdir] ISE seeks help with some crypto drafts

    Hi Richard -

    

    Later, Mike

---

From: Paul Wouters <[email-masked]>
Date: Sun, 17 Mar 2019 10:25:19 +0100

> On Mar 16, 2019, at 12:30, Paterson Kenneth <[email-masked]> wrote:

> The rough consensus of those who joined the discussion is that we should leave the status of CFRG as it is for now. 

I wasn’t aware we were gathering consensus already and thought we were just having a discussion. So seeing this cut short all of a sudden with a tally seems wrong to me.

So for consensus, I think that what CFRG is doing matches a WG more than an RG, and it would be more formally correct to change it.

Paul

---

From: Uri Blumenthal <[email-masked]>
Date: Sun, 17 Mar 2019 12:10:40 +0000

If CFRG is doing what a WG is supposed to - what's the product is supposed to produce, what are the milestones, and when is it supposed to wind down, as any normal WG should when it's done the job it was chartered for?

Sent from my test iPhone

> On Mar 17, 2019, at 05:25, Paul Wouters <[email-masked]> wrote:
> 
>

---

From: Tony Arcieri <[email-masked]>
Date: Sun, 17 Mar 2019 06:39:04 -0700

On Sun, Mar 17, 2019 at 2:25 AM Paul Wouters <[email-masked]> wrote:

> So for consensus, I think that what CFRG is doing matches a WG more than
> an RG, and it would be more formally correct to change it.

I think the CFRG is doing certain activities which would better fall under
a WG, but the question is a bit of a false dichotomy to begin with.

I think it would make sense to form perhaps 1 or 2 WGs for the biggest
questions that keep coming up over and over. Some form of "lightweight key
exchange" seems to be a popular one (see also my previous references to
Dragonfly).

This is definitely an interest area of mine, and something I'd like to
participate in, but alas something I lack to motivation and time to
spearhead myself...

---

From: Tony Arcieri <[email-masked]>
Date: Sun, 17 Mar 2019 06:40:20 -0700

> a WG, but the question is a bit of a false dichotomy to begin with.

...and sorry, to complete this thought, other than these repeat topics that
have major engineering implications for standards, I think the CFRG is fine
as an RG.

---

From: "Paterson Kenneth" <[email-masked]>
Date: Sun, 17 Mar 2019 14:29:18 +0000

Hi Paul,

I wasn't using "consensus" in any formal IRTF process sense, sorry; I should have picked a different word to avoid giving that impression. 

What I saw was a discussion that had gone on for a period of time and where the initiator had said he was not going to push the issue any further. That felt like a good time to step in, summarise what I'd seen, and suggest we move on to other issues. Apologies if my timing was bad or this seemed heavy-handed. 

Cheers,

Kenny

-----Original Message-----
From: Paul Wouters <[email-masked]>
Date: Sunday, 17 March 2019 at 09:26
To: Paterson  Kenneth <[email-masked]>
Cc: Michael StJohns <[email-masked]>, Richard Barnes <[email-masked]>, "[email-masked]" <[email-masked]>, "RFC ISE (Adrian Farrel)" <[email-masked]>, secdir <[email-masked]>
Subject: Re: [secdir] [Cfrg] Time to recharter CFRG as a working group? Was: Re: ISE seeks help with some crypto drafts

    

    Paul

---

From: denis bider <[email-masked]>
Date: Sun, 17 Mar 2019 20:28:24 -0500

With regard to shutting down - I think that policy is doing an incredible
disservice to the internet, to both developers and users of protocols.

The IETF needs the concept of permanent working groups and a bunch of
protocols need them.

The way it works right now is, a group forms around standardizing a
protocol, the RFCs are done and the group disbands. Just like that, an
entire community that formed around that protocol disappears. When people
want to introduce extensions, there's no longer anywhere to turn to. So
development of extensions happens haphazardly, without discussion, without
feedback, without coordination.

I think this policy (of shutting down WGs) is braindead, personally.
Working groups should shut down only for things that are actually dead. Not
when there's a temporary hiatus before the next version.

On Sun, Mar 17, 2019 at 7:11 AM Uri Blumenthal <[email-masked]> wrote:

> If CFRG is doing what a WG is supposed to - what's the product is supposed
> to produce, what are the milestones, and when is it supposed to wind down,
> as any normal WG should when it's done the job it was chartered for?
>
> Sent from my test iPhone
>
> >> The rough consensus of those who joined the discussion is that we
> should leave the status of CFRG as it is for now.
> >
> > I wasn’t aware we were gathering consensus already and thought we were
> just having a discussion. So seeing this cut short all of a sudden with a
> tally seems wrong to me.
> >

---

From: Watson Ladd <[email-masked]>
Date: Sun, 17 Mar 2019 18:34:16 -0700

And the issues the CFRG deals with a perennial.

On Sun, Mar 17, 2019, 6:29 PM denis bider <[email-masked]> wrote:

>> If CFRG is doing what a WG is supposed to - what's the product is
>> supposed to produce, what are the milestones, and when is it supposed to
>> wind down, as any normal WG should when it's done the job it was chartered
>> for?
>>
>> Sent from my test iPhone
>>
>> > So for consensus, I think that what CFRG is doing matches a WG more
>> than an RG, and it would be more formally correct to change it.
>> >
>> > Paul
>> >
>> >

---

From: Melinda Shore <[email-masked]>
Date: Sun, 17 Mar 2019 17:53:06 -0800

On 3/17/19 5:28 PM, denis bider wrote:
> When
> people want to introduce extensions, there's no longer anywhere to turn
> to. So development of extensions happens haphazardly, without
> discussion, without feedback, without coordination.

That's actually not what happens - new work on old
protocols has to go through the chartering process, which
is, in practice, more rigorous than rechartering and tends,
in my experience, to produce more focused results.  The
IETF produces a pretty good number of -bis documents and
extensions through the working group process.  (Currently
we've got groups like lamps, curdle, kitten, and so on
updating old standards.)

At any rate, I'd like to see CFRG remain where it is, in
part because of structural reasons but mostly because it's
been productive and useful and it's not clear that there's
any practical advantage to changing it to an IETF working
group, while there are several clear disadvantages (I think
that potentially removing incentives for participation by
academics is a huge deal, myself).

Melinda

-- 
Melinda Shore
[email-masked]

Software longa, hardware brevis

---

From: Uri Blumenthal <[email-masked]>
Date: Mon, 18 Mar 2019 03:00:51 +0000

+1 to Melinda.

Sent from my test iPhone

> On Mar 17, 2019, at 21:53, Melinda Shore <[email-masked]> wrote:
>

---

From: denis bider <[email-masked]>
Date: Sun, 17 Mar 2019 22:11:06 -0500

> protocols has to go through the chartering process,
> which is, in practice, more rigorous than rechartering
> and tends, in my experience, to produce more focused
> results.  The IETF produces a pretty good number of
> -bis documents and extensions through the working
> group process.

You are pointing out the lucky situations where that happens, I'm pointing
out the unlucky ones where it doesn't.

SSH is full of underdocumented, partly functional custom extensions (to
cryptography, compression, SFTP, port forwarding, host key synchronization,
VPN, and more), most of which *could* be better designed, better documented
and standardized - if only there was a continuing forum and people did not
have to go through this "rigorous" chartering process.

You point out the handful of documents produced as a success. I point out a
mountain of documents NOT produced, problems NOT solved, discussions NOT
had as a failure.

This same situation now arises in the context of CFRG, which would make
sense as a permanent WG. But nope, that option has to not be available.

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 18 Mar 2019 06:23:43 +0000

denis bider <[email-masked]> writes:

>VPN, and more), most of which could be better designed, better documented and
>standardized

+1.  Mind you given the hassle in setting up a WG for it and getting things
through the IETF, it might be easier to just set up a Github repository for
documentation on what does what and how and rely on Google to point people to
it.

Peter.

---

From: Melinda Shore <[email-masked]>
Date: Sun, 17 Mar 2019 22:53:28 -0800

> documentation on what does what and how and rely on Google to point people to

I think this may be closer to the core issue ("the hassle in
setting up a WG").  Moving something from the IRTF to the IETF
is likely to slow down the publication process, frankly.  IRTF
RFCs do require review by the IRSG and the IESG but they are
not IETF consensus documents (see RFC 5743 for details on the
IRTF document stream process).  Second, note that CFRG does not
typically work on protocols, per se, and when it does it's
limited to things like specific key exchange mechanisms rather
than all-the-things-missing-from-pgp.

I agree there's a broader problem here but I don't see how it
would be addressed by moving CFRG, which doesn't work on most of
the problem areas mentioned, anyway, to a body with weightier
process requirements and slower processes.

I'll note that we haven't seen that many drafts addressing these
proposed ssh extensions and given that we're a document-driven
organization that also makes progress difficult.  I'm personally
very interested in lowering barriers to contribution.  That's
a tough one to address because tautology, but seems related to
your concerns.

Melinda

-- 
Melinda Shore
[email-masked]

---

From: mcgrew <[email-masked]>
Date: Mon, 18 Mar 2019 09:26:47 -0400

Hi Mike,

Let me add few data points from a CFRG-historical perspective.  CFRG has been the first publisher of a number of specifications (for instance, XMSS, Poly1305, and HBS are in this category -  https://datatracker.ietf.org/rg/cfrg/documents/) and has done essential review for some ISE-published crypto like UMAC (RFC 4418).   For UMAC, it is worth noting that the ISE reviewers asked for changes around IPR language, and CFRG reviewers made important improvements to the technical content as well (https://datatracker.ietf.org/doc/rfc4418/history/ and CFRG mail threads from fall 2005).  So the issues we are dealing with today are not really new.  

You have started a good, healthy discussion with the points that you have raised.  My thinking is that CFRG (including Kenny, Alexy, and the many contributors) is doing really good, really important work, and the IRTF and IETF should avoid changes that would disrupt it.   

Best,

David

> On Mar 15, 2019, at 2:52 PM, Michael StJohns <[email-masked]> wrote:
> 
>> Mike, are your concerns here primarily IPR related?  If that's so, then maybe that's the level at which we should address them, as opposed to flipping the bigger RG->WG switch.
>> 
> 
> Hi Richard -
> 
> Like I said, I'm not going to push this at this time.  But I think its more than just IPR - avoiding technology because of IPR is more a symptom (and in fact is IETF guidance rather than IRTF policy).
> 
> The CFRG has a unique position in that - unlike ANY other RG as far as I can tell - it's looked at as an immediate feeder for technology for the IETF.  If it were agnostically evaluating the crypto properties of any offered technology, I'd say we're good and I'd move on.  But, with the publication of Curve25519 and its related ... standards ..., the CFRG has moved from evaluation and re-publication of cryptographic standards developed and produced elsewhere into being the first publisher of what could only be characterized as standards, even if published as an Informational RFC in the IRTF stream.
> 
> Ultimately, I think it comes down to fairness and transparency. As an RG, the publications of the RG are not subject to the standards appeals process.  In an WG, the decision not to work on an IPR encumbered technology (or others such as national cryptography) MAY be appealed and overturned (or might not) or sponsored by an AD if there's no applicable or agreeable WG. There's a process for showing such decisions were made transparently, and with a broader audience than just the CFRG having a say.
> 
> 
> Later, Mike
> 
> Ps - hmm... Note that the CFRG charter only mentions the IETF and not the IRTF....
>

---

From: denis bider <[email-masked]>
Date: Mon, 18 Mar 2019 10:51:20 -0500

(removed CFRG from CC since not directly relevant)

Exactly. Currently, the direction of SSH is dictated by OpenSSH, which is
the de facto standard (in a loose alliance with other open source
implementations like libssh and PuTTY).

I'm not sure about the personal circumstances of each individual involved
with these projects, but the requirements of IETF's "rigorous" processes
are "rigorous"; and the motivation for volunteers to participate is
approximately none. Yet these volunteers, as a group, determine the
protocol's direction.

As a standards organization, IETF is not competing with ISO (which requires
anyone who wants to achieve something to travel to places like Hawaii), it
is competing with GitHub. When OpenSSH wants to do something, they don't
start a WG, they just publish stuff in their PROTOCOL file:

https://github.com/openssh/openssh-portable/blob/master/PROTOCOL

Currently:

- The dominant encryption mechanism in SSH is not specified by IETF. It is "
[email-masked]" and "[email-masked]", documented in that
PROTOCOL file.

- Encrypt-then-MAC in SSH is not specified by IETF. It is vaguely
documented in that PROTOCOL file.

- Host key synchronization (an extremely useful feature) is not specified
by IETF - it's in that PROTOCOL file.

This is just the tip of the iceberg. The PROTOCOL file contains a bunch of
other things that are underspecified and under-standardized, but
IMPLEMENTED, because no one wants to follow the IETF's "rigorous" process
to charter a WG for every change.

What makes this tragic is that it's unnecessary. SSH version 2 was
standardized as an IETF WG. Then, because of the IETF rules, the WG
disbanded.

The IETF is literally handing off standardization to be done half-assedly
at GitHub, and treating this as a success.

---

From: Watson Ladd <[email-masked]>
Date: Mon, 18 Mar 2019 09:07:16 -0700

On Mon, Mar 18, 2019, 8:51 AM denis bider <[email-masked]> wrote:

> As a standards organization, IETF is not competing with ISO (which
> requires anyone who wants to achieve something to travel to places like
> Hawaii), it is competing with GitHub. When OpenSSH wants to do something,
> they don't start a WG, they just publish stuff in their PROTOCOL file:
>
> - The dominant encryption mechanism in SSH is not specified by IETF. It is
> "[email-masked]" and "[email-masked]", documented in that
> PROTOCOL file.
>

Forgive me for thinking this represents running code and rough consensus.
What is the benefit of turning  these enhancements into RFCs to the OpenSSH
project?

Also other streams then the IETF one exist. So what actually is the problem
that needs solving with SSH?

>> denis bider <[email-masked] <[email-masked]>>
>> writes:
>>

---

From: Paul Wouters <[email-masked]>
Date: Mon, 18 Mar 2019 18:20:16 +0100

> On Mar 18, 2019, at 17:07, Watson Ladd <[email-masked]> wrote:
> 
> 
> 
> 

Consensus is not “vague stuff from the PROTOCOLS file”

> What is the benefit of turning  these enhancements into RFCs to the OpenSSH project?

Improved interoperability, more eyes looking at the protocols, facilitating an open internet without implicit vendor lock.

> Also other streams then the IETF one exist. So what actually is the problem that needs solving with SSH?

The standard should not be “bug compatible with the dominant implementation”

Paul

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 18 Mar 2019 13:50:02 -0400

On Sun, Mar 17, 2019 at 9:29 PM denis bider <[email-masked]> wrote:
>
> With regard to shutting down - I think that policy is doing an incredible disservice to the internet, to both developers and users of protocols.

There can also be inactive WGs that stop meeting (if they were having
meetings) and don't have any active milestones they are working on but
are still around. Or a WG's charter could be changed so that all it
has to do it review related documents that come up. For example, for a
while, PPPEXT was such a WG that existed just to review new documents
that came along related to PPP.

> ...
> The way it works right now is, a group forms around standardizing a protocol, the RFCs are done and the group disbands. Just like that, an entire community that formed around that protocol disappears. When people want to introduce extensions, there's no longer anywhere to turn to. So development of extensions happens haphazardly, without discussion, without feedback, without coordination.

The real community in the IETF is the mailing list which is normally
continued when a WG terminates. So, in the cases I am familiar with,
the community is still around. Although the PPPEXT WG was eventually
terminated, the [email-masked] mailing list still exists with PPP
experts on it.

> I think this policy (of shutting down WGs) is braindead, personally. Working groups should shut down only for things that are actually dead. Not when there's a temporary hiatus before the next version.

What makes something "actually dead"?

In any case, the IETF is what it is. It evolves slowly. There are
always protocol/technical areas moving into the IETF and others moving
out of the IETF. There are usually around 150 WGs these days.
Presumably you would prefer this number to be much larger but that
would imply more than changing philosophy on WG termination, such
changes in management structure and funding.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 [email-masked]

---

From: Michael StJohns <[email-masked]>
Date: Mon, 18 Mar 2019 16:43:53 -0400

I don't understand - usually when I say "I'm fine with the status quo 
for now" people stop arguing with me.   Oh well.

And thanks David for making some points for me.  See below.

On 3/18/2019 9:26 AM, mcgrew wrote:
> Hi Mike,
>
> Let me add few data points from a CFRG-historical perspective.  CFRG has been the first publisher of a number of specifications (for instance, XMSS, Poly1305, and HBS are in this category -  https://datatracker.ietf.org/rg/cfrg/documents/) and has done essential review for some ISE-published crypto like UMAC (RFC 4418).

My point was that becoming a first publisher puts the CFRG into the 
position of being the standardizer.  XMSS, Poly1305 and HBS (not yet 
published) are all 2018 and 2019 documents.  EDDSA was 2017.  In fact 
the set of documents currently attributed to the CFRG only goes back to 
2014 while the CFRG has been around a lot longer than that.  Something 
changed and now we're getting standards-like production out of the 
CFRG.  Note that I don't think its a bad thing per se, just that you 
need to be following different rules than those that are applicable to RGs.

For example, why does an informational document in the research stream 
need a registry?  (e.g. RFC8391)   That's about as obvious a 
standardization requirement as any I've seen in CFRG documents.

>   For UMAC, it is worth noting that the ISE reviewers asked for changes around IPR language,

I don't think I even recall seeing anything that wants to use UMAC - I 
may have missed a protocol or two though.  In any event, the request was 
to REMOVE claims about IPR language from the document and direct the 
authors to make a normal IPR disclosure. Again - pretty consistent with 
what we do with standards and IETF stream documents.

> and CFRG reviewers made important improvements to the technical content as well (https://datatracker.ietf.org/doc/rfc4418/history/ and CFRG mail threads from fall 2005).  So the issues we are dealing with today are not really new.

But again, that's normal for any document that comes in through any 
stream - specifically - people review it and usually irrespective of 
association with a specific WG/RG/directorate, etc.  The fact that the 
document author, the ISE and the IESG reached out the the CFRG is pretty 
much an example of looking for the experts in a pile of experts.  I'm 
not sure why this wouldn't happen if the CFRG were chartered as a WG?

> You have started a good, healthy discussion with the points that you have raised.  My thinking is that CFRG (including Kenny, Alexy, and the many contributors) is doing really good, really importan…

I don't want to change the people, I don't even want to change the work 
flow (much - except that moving it to a WG would actually remove the 
IRTF from the approval process for an RFC), I just want this to be 
appropriately categorized and managed as a WG and subject to the same 
rules as any other WG.   I think its gone well past the normal rules for 
an RG at this point.

Again - I've indicated my concerns and I'm happy the discussion is 
happening.  Unfortunately what I keep hearing is "we like it the way it 
is, now go and leave us alone" rather than "we're really a RG because we 
do things X, Y and Z so we really don't need to be a WG".  I'd really 
like to hear more commentary on that latter - especially how the CFRG in 
fact differs from the behavior of a WG.

Thanks - Mike

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 19 Mar 2019 01:08:07 +0000

>The standard should not be “bug compatible with the dominant implementation”

Just an additional note to this, the standard currently literally is "bug
compatible with the dominant implementation".  If you implement SSH as per the
core RFCs, sticking to all the MUSTs and whatnot, it won't talk to OpenSSH,
which means it de facto won't work.

Also, expanding on Denis' comment about the PROTOOCOL doc:

  Note that OpenSSH's sftp and sftp-server implement revision 3 of the SSH
  filexfer protocol described in:

  https://www.openssh.com/txt/draft-ietf-secsh-filexfer-02.txt

  Newer versions of the draft will not be supported, though some features
  are individually implemented as extensions described below.

I don't know if much, or even anything, supports any of draft-ietf-secsh-
filexfer-03.txt through to draft-ietf-secsh-filexfer-13.txt.  So the standard
in this case is "use a 17-year-old expired draft, but not any newer version of
the same document".

Peter.

---

From: mcgrew <[email-masked]>
Date: Tue, 19 Mar 2019 09:23:03 -0400

Hi Mike,

Please see inline:

> On Mar 18, 2019, at 4:43 PM, Michael StJohns <[email-masked]> wrote:
> 
> I don't understand - usually when I say "I'm fine with the status quo for now" people stop arguing with me.   Oh well.
> 
> My point was that becoming a first publisher puts the CFRG into the position of being the standardizer.  XMSS, Poly1305 and HBS (not yet published) are all 2018 and 2019 documents.  EDDSA was 2017.  In fact the set of documents currently attributed to the CFRG only goes back to 2014 while the CFRG has been around a lot longer than that.  Something changed

The RG shifted from discussing and reviewing independent documents towards producing its own documents.  

> and now we're getting standards-like production out of the CFRG.  Note that I don't think its a bad thing per se, just that you need to be following different rules than those that are applicable to RGs.
> 
> For example, why does an informational document in the research stream need a registry?  (e.g. RFC8391)   That's about as obvious a standardization requirement as any I've seen in CFRG documents.

The registry and the interface and extensibility it provides is essential to making a crypto specification future-proof. That is clearly best practice in cryptography, and as such is totally appropriate for the output of an IRTF RG document.   Some independent documents that were reviewed by CFRG also had registries. 

David

> I don't think I even recall seeing anything that wants to use UMAC - I may have missed a protocol or two though.  In any event, the request was to REMOVE claims about IPR language from the document and direct the authors to make a normal IPR disclosure. Again - pretty consistent with what we do with standards and IETF stream documents.
> 
> But again, that's normal for any document that comes in through any stream - specifically - people review it and usually irrespective of association with a specific WG/RG/directorate, etc.  The fact that the document author, the ISE and the IESG reached out the the CFRG is pretty much an example of looking for the experts in a pile of experts.  I'm not sure why this wouldn't happen if the CFRG were chartered as a WG?
> 
> 
>> 
> I don't want to change the people, I don't even want to change the work flow (much - except that moving it to a WG would actually remove the IRTF from the approval process for an RFC), I just want this to be appropriately categorized and managed as a WG and subject to the same rules as any other WG.   I think its gone well past the normal rules for an RG at this point.
> 
> Again - I've indicated my concerns and I'm happy the discussion is happening.  Unfortunately what I keep hearing is "we like it the way it is, now go and leave us alone" rather than "we're really a RG because we do things X, Y and Z so we really don't need to be a WG".  I'd really like to hear more commentary on that latter - especially how the CFRG in fact differs from the behavior of a WG.
> 
> Thanks - Mike
> 
> 
> 
>> 
>> Best,
>> 
>> David
>>

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 20 Mar 2019 16:15:51 +0200

> in this case is "use a 17-year-old expired draft, but not any newer version of

Secsh WG was active between 1997-2006. The filexfer-02 was published
in 2001 and final filexfer-13 was published in 2006, i.e., the -13
version is what the working group was working on. My understanding was
that the issue was that openssh did not want to implement what was
specified in the working group because of the issues with trademarks,
personalities and things not at all relevant to the actual protocol
development or IETF work. Those things practically killed the group
and there was not that much work ongoing after that.

This does not mean that IETF working groups do not work, it just mean
that one group did fail.

In the IPsec we had similar situation where we did finish the base
specifications closed up the working at 2005. Created a new working
group IPsecME (IP Security Maintenance and Extensions) in 2008 to
create place for working extensions and fixes for IPsec protocol
suite. We have rechartered several times since, every time checking
out our current set of extensions proposed for us and taken those
which had enough interest.

So I do not think that forming working group raises the bar too high,
or makes things too difficult, the issues with secsh was (and I think
is) not related to IETF processes.

Jan  9  2001 draft-ietf-secsh-filexfer-00.txt
Mar  5  2001 draft-ietf-secsh-filexfer-01.txt
Nov 21  2001 draft-ietf-secsh-filexfer-02.txt
Oct 17  2002 draft-ietf-secsh-filexfer-03.txt
Dec 20  2002 draft-ietf-secsh-filexfer-04.txt
Feb 12  2004 draft-ietf-secsh-filexfer-05.txt
Oct 27  2004 draft-ietf-secsh-filexfer-06.txt
Mar 25  2005 draft-ietf-secsh-filexfer-07.txt
Apr  6  2005 draft-ietf-secsh-filexfer-08.txt
Jun 13  2005 draft-ietf-secsh-filexfer-09.txt
Oct  6  2005 draft-ietf-secsh-filexfer-10.txt
Jan 18  2006 draft-ietf-secsh-filexfer-11.txt
Jan 26  2006 draft-ietf-secsh-filexfer-12.txt
Jul 18  2006 draft-ietf-secsh-filexfer-13.txt
-- 
[email-masked]

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 20 Mar 2019 14:39:47 +0000

Tero Kivinen <[email-masked]> writes:

>Secsh WG was active between 1997-2006. The filexfer-02 was published in 2001
>and final filexfer-13 was published in 2006, i.e., the -13 version is what
>the working group was working on. My understanding was that the issue was
>that openssh did not want to implement what was specified in the working
>group because of the issues with trademarks, personalities and things not at
>all relevant to the actual protocol development or IETF work.

I think it was more than just that, if you look at what you'd need to do for
an -02 client, so "General Packet Format" to the end of "Requests From the
Client to the Server" that's fifteen pages.  In -13 the same thing is forty-
two pages (!!), and also draws in chunks of NFSv4 by reference.  It's gone
from being a means of getting a file from A to B to trying to reinvent NFS,
with all the attendant complexity.

I can see why an implementer would want to stop at -02, which is exactly what
I did when I had to do an SFTP implementation, -13 had reached the point where
it was growing without bounds with little to no benefit from the massive
complexity being added to it.

Peter.

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 22 Mar 2019 23:09:18 +0200

> with all the attendant complexity.

All this work and changes was done in the secsh wg and did nt require
any rechartering or wg forming. Different people do have different
opinions who things should be done, and it seems the new editors of
the draft added quite a lot of stuff, most likely by the request of
the working group.

> complexity being added to it.

And most likely the issue there was that the implementors did not
want to come to the WG meetings anymore because of the personal
conflicts between people. I did hear some people saying to me that
they do not want to go to the secsh wg meetings at all because going
there will cause them to get shitstorm destined to you and they did
not want to receive such things.

So in the end there was not enough people working on the protocol and
thats why it got where it ended up.

None of this is failure is because of "hassle in setting up WG", or
"rigorous rechartering" issues. There was existing working group that
was workin on the document, it was just failure of people working in
the existing wg and failure to reach consensus on filexfer draft. It
was not setting up wg would be too hard, or that the ietf process
would be broken in general.
-- 
[email-masked]

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 23 Mar 2019 05:01:23 +0000

Tero Kivinen <[email-masked]> writes:

>Different people do have different opinions who things should be done, and it
>seems the new editors of the draft added quite a lot of stuff, most likely by
>the request of the working group.

It'd be interesting to get comments from people involved as to why all the new
stuff was added, it's far enough in the past that I don't think it matters any
more if people comment on it.  The two major client and server
implementations, OpenSSH and Putty, don't do the stuff from the newer drafts,
and I know of several other implementations that also don't do it, so who/what
was driving it?

>I did hear some people saying to me that they do not want to go to the secsh
>wg meetings at all because going there will cause them to get shitstorm
>destined to you and they did not want to receive such things.

Hmm, interesting, hadn't heard that about the SSH WG specifically, although
I've heard it about one or two others.  So the SFTP work stopped because of
infighting, not because people lost interest/V3 was good enough?

Peter.

---

From: "StJohns, Michael" <[email-masked]>
Date: Sun, 24 Mar 2019 11:02:24 +0100

Sorry for the top post - it’s hard to get a coherent edit using an iPad.

Basically, you’ve confirmed what I said - that the CFRG is doing standards
like stuff, and that it just chose to do so.  I note that the change in
behavior was not accompanied by a change in the charter.  I’d expect that
going through a recharterng exercise to bring in line the documentation
with the group behavior would lend more credence to the idea that the
charter should be written for a WG.

WRT the registry - registries are usually created as a result of a
standards action and I was quite surprised to find that this one had been
created.  You used the phrase “make the specification future proof” which
again is more IETF than IRTF IMHOand suggests that the IETF should have
change control.

Later, Mike

On Tue, Mar 19, 2019 at 14:23 mcgrew <[email-masked]> wrote:

> >> Let me add few data points from a CFRG-historical perspective.  CFRG
> has been the first publisher of a number of specifications (for instance,
> XMSS, Poly1305, and HBS are in this category -
> https://datatracker.ietf.org/rg/cfrg/documents/) and has done essential
> review for some ISE-published crypto like UMAC (RFC 4418).
> >
> published) are all 2018 and 2019 documents.  EDDSA was 2017.  In fact the
> set of documents currently attributed to the CFRG only goes back to 2014
> while the CFRG has been around a lot longer than that.  Something changed
>
> > and now we're getting standards-like production out of the CFRG.  Note
> that I don't think its a bad thing per se, just that you need to be
> following different rules than those that are applicable to RGs.
> >
> The registry and the interface and extensibility it provides is essential
> to making a crypto specification future-proof. That is clearly best
> practice in cryptography, and as such is totally appropriate for the output
> of an IRTF RG document.   Some independent documents that were reviewed by
> CFRG also had registries.
>
> David
>
> >
> may have missed a protocol or two though.  In any event, the request was to
> REMOVE claims about IPR language from the document and direct the authors
> to make a normal IPR disclosure. Again - pretty consistent with what we do
> with standards and IETF stream documents.
> >
> >> and CFRG reviewers made important improvements to the technical content
> as well (https://datatracker.ietf.org/doc/rfc4418/history/ and CFRG mail
> threads from fall 2005).  So the issues we are dealing with today are not
> really new.
> >
> much an example of looking for the experts in a pile of experts.  I'm not
> sure why this wouldn't happen if the CFRG were chartered as a WG?
> >
> >
> >>
> >> You have started a good, healthy discussion with the points that you
> have raised.  My thinking is that CFRG (including Kenny, Alexy, and the
> many contributors) is doing really good, really important work, and the
> IRTF and IETF should avoid changes that would disrupt it.
> >
> flow (much - except that moving it to a WG would actually remove the IRTF
> from the approval process for an RFC), I just want this to be appropriately
> categorized and managed as a WG and subject to the same rules as any other
> WG.   I think its gone well past the normal rules for an RG at this point.
> >
> happening.  Unfortunately what I keep hearing is "we like it the way it is,
> now go and leave us alone" rather than "we're really a RG because we do
> things X, Y and Z so we really don't need to be a WG".  I'd really like to
> hear more commentary on that latter - especially how the CFRG in fact
> differs from the behavior of a WG.
> >
> > Thanks - Mike
> >
> >
> >
> >>
> >> Best,
> >>
> >> David
> >>
> then maybe that's the level at which we should address them, as opposed to
> more than just IPR - avoiding technology because of IPR is more a symptom
> (and in fact is IETF guidance rather than IRTF policy).
> >>>
> >>> The CFRG has a unique position in that - unlike ANY other RG as far as
> I can tell - it's looked at as an immediate feeder for technology for the
> publication of Curve25519 and its related ... standards ..., the CFRG has
> moved from evaluation and re-publication of cryptographic standards
> overturned (or might not) or sponsored by an AD if there's no applicable or
> agreeable WG. There's a process for showing such decisions were made

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 24 Mar 2019 14:49:53 +0000

Hiya,

On 24/03/2019 10:02, StJohns, Michael wrote:
>  I’d expect that

I'm not at all convinced that that'd be worthwhile TBH. ISTM that cfrg
is functioning well, so a re-charter seems like it'd not be so useful,
and possibly worse (being distracting). cfrg's credibility comes from
it's output, not it's charter, for me at least.

S.