Subject: [Curdle] AD Review: draft-ietf-curdle-cms-ecdh-new-curves-04.txt

From: Eric Rescorla <[email-masked]>
Date: Fri, 5 May 2017 13:06:48 -0700

OVERALL
I see a bunch of quasi-normative text here, e.g.,

   [CURVES].  Those other curves are not deprecated, but support for
   curve25519 and curve448 is encouraged.

Can you use RFC 2119 language here?

TECHNICAL
S 2.
   X25519 is described in Section 6.1 of [CURVES], and X448 is described
   in Section 6.2 of [CURVES].  Since curve25519 and curve448 have
   cofactors of 8 and 4, respectively, an input point of small order
   will eliminate any contribution from the other party’s private key.
   As described in Section 7 of [CURVES], implementations SHOULD detect
   this situation by checking for the all-zero output.

Why are you not requiring this check? SSH and TLS both do.

   The ECC-CMS-SharedInfo keyInfo field contains the object identifier
   of the key-encryption algorithm and associated parameters.  This
   algorithm will be used to wrap the content-encryption key.  For
   example, the AES Key Wrap algorithm [AESKW] does not need parameters,
   so the algorithm identifier parameters are absent.

It's important that this be clear. Is it required to be absent? Must
I check?

   The ECC-CMS-SharedInfo entityUInfo field optionally contains
   additional keying material supplied by the sending agent.  Note that
   [CMS] requires implementations to accept a KeyAgreeRecipientInfo
   SEQUENCE that includes the ukm field.  If the ukm field is present,
   the ukm is placed in the entityUInfo field.  The ukm value need not
   be longer than the key-encryption key that will be produced by the
   KDF.

Need not? Please clarify what the purpose is here. It seems like
it's to generate a unique KEK. In that case, the security bounds
are what, uniqueness?

S 2.2.
  if ukm is provided, then salt = ukm, else salt = zero

zero in this case is "all zeros"? In any case, HKDF already
knows how to deal with salt not provided, to that would be
easier to specify.

S 8.
Don't forget to fill in these values. I assume you will do
so once IANA registers your code points?

S 9.
This section is kinda diffident about whether the sender's
ephemeral is truly ephemeral. Is this a MUST? If so, please
say so.

Appendix:
How many people have checked this ASN.1 module?

EDITORIAL
S 2.
Please put KEK in parentheses in your first use.

S 3.
It would be easier to put this above the key derivation stage.

Please provide some sort of reference or cross-reference for
"kari"

   KeyAgreeRecipientInfo ukm is optional.  Note that [CMS] requires
   implementations to accept a KeyAgreeRecipientInfo SEQUENCE that
   includes the ukm field.  If present, the ukm is placed in the
   entityUInfo field of the ECC-CMS-SharedInfo as input to the KDF.  The
   ukm value need not be longer than the key-encryption key produced by
   the KDF.

This seems to be duplicated.

S 5.
This also seems to be largely duplicated. Can you refactor out
the common stuff.

-Ekr

---

From: Russ Housley <[email-masked]>
Date: Sat, 6 May 2017 17:27:17 -0400

> Can you use RFC 2119 language here?

The text says that other curves are not deprecated, but it is encouraging support for X25519 and X448.  We know that there are some communities that are not ready to embrace the CFRG curves over the NIST curves.  So, I’d rather drop the second half of the sentence than change it to RFC 2119 language.

> Why are you not requiring this check? SSH and TLS both do.

RFC 7748 [CURVES] says:

   Protocol designers using Diffie-Hellman over the curves defined in
   this document must not assume "contributory behaviour".  Specially,
   contributory behaviour means that both parties' private keys
   contribute to the resulting shared key.  Since curve25519 and
   curve448 have cofactors of 8 and 4 (respectively), an input point of
   small order will eliminate any contribution from the other party's
   private key.  This situation can be detected by checking for the all-
   zero output, which implementations MAY do, as specified in Section 6.
   However, a large number of existing implementations do not do this.

We upgraded the MAY to a SHOULD.  We are being told that some implementations will not perform this check, so it seemed wrong to go all the way to MUST.

> It's important that this be clear. Is it required to be absent? Must

The parameters can be present or absent depending on the key-encryption algorithm that is used.  This document does not specify a particular algorithm; they are specified in other documents.

> it's to generate a unique KEK. In that case, the security bounds

I suggest this wording:

   … There is no security benefit to using a ukm value that is
   longer than the key-encryption key that will be produced by
   the KDF.

> knows how to deal with salt not provided, to that would be

Good suggestion.  This leads to two changes in the text:

   The ECC-CMS-SharedInfo structure optionally includes
   the ukm.  If the ukm is present, the ukm is also used as
   the HKDF salt.  HKDF uses an appropriate number of
   zero octets when no salt is provided.

      if ukm is provided, then salt = ukm, else salt is not provided
     PRK = HKDF-Extract(salt, K)

     KEK = HKDF-Expand(PRK, DER(ECC-CMS-SharedInfo), SizeInOctets(KEK))

> so once IANA registers your code points?

Correct.  The IANA assignments are needed to fill in the values.

> ephemeral is truly ephemeral. Is this a MUST? If so, please

Section 2 already explains that the originator uses an ephemeral key pair.

> How many people have checked this ASN.1 module?

At least two people have compiled it with different toolsets.

> Please put KEK in parentheses in your first use.

In most places, it is spelled out.  I added (KEK) to the first place, and left it in the other places.

> It would be easier to put this above the key derivation stage.

I followed the outline used in other specifications.  I figures that the implementers were fine with the previous outline.

> “kari"

The kari is defined in [CMS] as one of the choices in RecipientInfo.  I think that is clear from the sentence.

> This seems to be duplicated.

Yes.  I rewrote the text in Section 3.2 to point back to the earlier text.

> This also seems to be largely duplicated. Can you refactor out

Because the content type is different, I think I already reduced it to the minimum.

Russ

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 8 May 2017 17:12:00 -0700

On Sat, May 6, 2017 at 2:27 PM, Russ Housley <[email-masked]> wrote:

> The text says that other curves are not deprecated, but it is encouraging
> support for X25519 and X448.  We know that there are some communities that
> are not ready to embrace the CFRG curves over the NIST curves.  So, I’d
> rather drop the second half of the sentence than change it to RFC 2119
> language.
>

OK.

> We upgraded the MAY to a SHOULD.  We are being told that some
> implementations will not perform this check, so it seemed wrong to go all
> the way to MUST.
>

I'd like to push on this some, because I'm having trouble seeing why
different IETF protocols have different needs. When you say "you are being
told" is that an S/MIME specific point or merely the the text above?

>    longer than the key-encryption key that will be produced by

Hmm... I believe that this statement is true, but it also seems to be
incomplete. I may be reasoning about this incorrectly, but it seems
to me that the minimal security requirement is that the UKM be
unique, but that can be achieved with a value much smaller than
the KEK. For instance, it seems like if you have a 256-bit KEK,
then you would still be OK with a randomly-generated 128-bit
UKM. And if we're concerned about random collisions, then the
usefulness bound is actually min(|KEK|, |hash compression function size|).

> Section 2 already explains that the originator uses an ephemeral key pair.

Yes, but it doesn't have any normative language (see above on this topic).

> left it in the other places.

SGTM.

> I followed the outline used in other specifications.  I figures that the
> implementers were fine with the previous outline.
>

Yeah, I didn't find it super-clear. How about quoting it.

-Ekr

---

From: Russ Housley <[email-masked]>
Date: Tue, 9 May 2017 12:03:44 -0400

I dropped the parts that have been resolved.

> I'd like to push on this some, because I'm having trouble seeing why different IETF protocols have different needs. When you say "you are being told" is that an S/MIME specific point or merely the the text above?

The text above, which I gather is about some existing implementations, probably libraries.  I do not know what protocols use those implementations, but if they are libraries they will get used with many different protocols.

> usefulness bound is actually min(|KEK|, |hash compression function size|).

Yes. The umm value needs to be different for each invocation of the KDF, otherwise it does not provide the assurance that different keying material will be produced.  Of course, an implementation will generate the umm value using random number generator, not track the values that are used.  Several years ago, there was a discussion about the size of the ukm needed.  Some people were suggesting crazy large values, and the point was made that anything beyond the SIZEOF(KEK) did not improve security.

Are you asking for a sentence saying that the ukm, if present, MUST be at least 128 bits?

> Yes, but it doesn't have any normative language (see above on this topic).

I see.  I’ll reword the text in Section 2 to use MUST.

How about:

   The originator MUST use an ephemeral public/private key pair that is
   generated on the same elliptic curve as the public key of the
   recipient.  The ephemeral key pair MUST be used for a single CMS
   protected content type, and then it MUST be discarded.  The
   originator obtains the recipient's static public key from the
   recipient's certificate [PROFILE].

> Yeah, I didn't find it super-clear. How about quoting it.

Okay.  I suggest:

   The enveloped-data content type is ASN.1 encoded using the
   EnvelopedData syntax.  The fields of the EnvelopedData syntax MUST be
   populated as described in Section 6 of [CMS].  The RecipientInfo
   choice is described in Section 6.2 of [CMS], and repeated here for
   convenience.

      RecipientInfo ::= CHOICE {
        ktri KeyTransRecipientInfo,
        kari [1] KeyAgreeRecipientInfo,
        kekri [2] KEKRecipientInfo,
        pwri [3] PasswordRecipientinfo,
        ori [4] OtherRecipientInfo }

   For the recipients that use X25519 or X448 the RecipientInfo kari
   choice MUST be used.

Russ

---

From: Jim Schaad <[email-masked]>
Date: Tue, 9 May 2017 10:47:33 -0700

See inline.

From: Curdle [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Tuesday, May 9, 2017 9:04 AM
To: Eric Rescorla <[email-masked]>
Cc: curdle <[email-masked]>
Subject: Re: [Curdle] AD Review: draft-ietf-curdle-cms-ecdh-new-curves-04.txt

RFC 7748 [CURVES] says:

[JLS] As I have stated in the past – I am with EKR on this.

I suggest this wording:

[JLS] I would disagree that the value has to be random, a counter will work as well.  (An encrypted counter is better.)  I not be happy with a fixed size requirement on this easier.  There is no reason to make such a requirement that I can think of.  A 64-bit counter is just as rational.  It might make more sense to change this statement into something along the lines of 

* Any pair of static keys MUST NOT be used more times than the size of the key.  I.e. if 128-bit KEKs may be used, then there is a 2^128 limit on the number of times the key pair can be used.

* The size of the KEK is normally not longer than the length of the resulting KEK as that is the limit of unique values that can be generated in any event.

Jim

How about:

Okay.  I suggest:

   convenience.

   choice MUST be used.

Russ

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 9 May 2017 10:50:52 -0700

On Tue, May 9, 2017 at 9:03 AM, Russ Housley <[email-masked]> wrote:

> The text above, which I gather is about some existing implementations,
> probably libraries.  I do not know what protocols use those
> implementations, but if they are libraries they will get used with many
> different protocols.
>

Sure, but other protocols are requiring it and it seems like S/MIME could
also do so, in
the worst case at the point where Z is handed off to S/MIME.

> Yes. The umm value needs to be different for each invocation of the KDF,
> otherwise it does not provide the assurance that different keying material
> will be produced.  Of course, an implementation will generate the umm value
> using random number generator, not track the values that are used.  Several
> years ago, there was a discussion about the size of the ukm needed.  Some
> people were suggesting crazy large values, and the point was made that
> anything beyond the SIZEOF(KEK) did not improve security.
>

Sorry, I was trying to talk it over, but I'm not sure how helpful I am
being. It seems like the basic requirement is that it be unique and that if
we want to give guidance it should be on the collision probability. Do we
believe that 128 bits is enough (I do!), in which case we can just say "if
you are generating it randomly, then N bits is enough"

>    recipient's certificate [PROFILE].

LGTM.

>    For the recipients that use X25519 or X448 the RecipientInfo kari

This would be fine.

-Ekr

---

From: Russ Housley <[email-masked]>
Date: Tue, 9 May 2017 15:36:26 -0400

> On May 9, 2017, at 1:47 PM, Jim Schaad <[email-masked]> wrote:
> 
> See inline.
>  
> From: Curdle [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Russ Housley
> To: Eric Rescorla <[email-masked] <mailto:[email-masked]>>
> Cc: curdle <[email-masked] <mailto:[email-masked]>>

Previously, only Jim had posted in support for this check.  I will change the SHOULD to a MUST.

> * The size of the KEK is normally not longer than the length of the resulting KEK as that is the limit of unique values that can be generated in any event.

Section 2 already says that the ephemeral key MUST be used for only one message.  Thus, a UKM is not really needed.  However, the CMS requires support for a UKM if the sender include it.  For this reason, the document says how to handle it in the KDF if it is present.

You are correct that a counter, encrypted counter, or random value will work, even if the originator uses the same ephemeral key for many messages.  The text does not limit the choices in any way.

The text already says that there is no security reason for a UKM value that is longer than the KEK.  I think that EKR is asking for guidance on the minimum size too.

Russ

---

From: Russ Housley <[email-masked]>
Date: Tue, 9 May 2017 16:06:45 -0400

> On May 9, 2017, at 1:50 PM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Tue, May 9, 2017 at 9:03 AM, Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:
> Sure, but other protocols are requiring it and it seems like S/MIME could also do so, in

I suggest:

   X25519 is described in Section 6.1 of [CURVES], and X448 is described
   in Section 6.2 of [CURVES].  As described in Section 7 of [CURVES],
   curve25519 and curve448 have cofactors of 8 and 4, respectively, and
   so an input point of small order will eliminate any contribution from
   the other party's private key.  Conforming implementations MUST check
   for the all-zero output to prevent this situation.

> Sorry, I was trying to talk it over, but I'm not sure how helpful I am being. It seems like the basic requirement is that it be unique and that if we want to give guidance it should be on the collision probability. Do we believe that 128 bits is enough (I do!), in which case we can just say "if you are generating it randomly, then N bits is enough”

Jim is correct that counters, encrypted counters, linear feedback shift registers, and other techniques will work here too.

Since Section 2 already says that the ephemeral key MUST be used for only one message, a UKM is not really needed.  However, the CMS requires support for a UKM if the sender include it.  For this reason, the document says how to handle it in the KDF if it is present.

The text already says that there is no security reason for a UKM value that is longer than the KEK.  I think that you are asking for guidance on the minimum size too.  Based on Jim’s point, I’d like to say that it MUST be at least 8 octets.

Russ

---

From: Jim Schaad <[email-masked]>
Date: Tue, 9 May 2017 13:18:03 -0700

From: Russ Housley [mailto:[email-masked]] 
Sent: Tuesday, May 9, 2017 12:36 PM
To: Jim Schaad <[email-masked]>
Cc: Eric Rescorla <[email-masked]>; curdle <[email-masked]>
Subject: Re: [Curdle] AD Review: draft-ietf-curdle-cms-ecdh-new-curves-04.txt

On May 9, 2017, at 1:47 PM, Jim Schaad <[email-masked] <mailto:[email-masked]> > wrote:

See inline.

From: Curdle [ <mailto:[email-masked]> mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Tuesday, May 9, 2017 9:04 AM
To: Eric Rescorla < <mailto:[email-masked]> [email-masked]>
Cc: curdle < <mailto:[email-masked]> [email-masked]>
Subject: Re: [Curdle] AD Review: draft-ietf-curdle-cms-ecdh-new-curves-04.txt

RFC 7748 [CURVES] says:

I suggest this wording:

[JLS] It’s kind of a stupid thing to do, but the minimum size would be one bit.  Although this is not legal from an ASN.1 standpoint – so the minimum would be one byte. 

A single byte with all bits zero and two bytes with all bits zero are different ukm values because of the way that they are used in the ECC-CMS-SharedInfo structure.  Note that this would not be the case if the ukm value was only used as a salt value to HKDF.  I do not see any reason to specify a minimum length of this value.  The only thing that is required is uniqueness, EKR is correct about saying this. 

Russ

---

From: Russ Housley <[email-masked]>
Date: Tue, 9 May 2017 16:25:45 -0400

I suggest:

   The ECC-CMS-SharedInfo entityUInfo field optionally contains
   additional keying material supplied by the sending agent.  Note that
   [CMS] requires implementations to accept a KeyAgreeRecipientInfo
   SEQUENCE that includes the ukm field.  If the ukm field is present,
   the ukm is placed in the entityUInfo field.  When present, the ukm
   ensures that a different key-encryption key is generated, even when
   the originator ephemeral private key is improperly used more than
   once.  Therefore, if the ukm field is present, it MUST be selected in
   a manner that ensures a unique KDF output; however, there is no
   security benefit to using a ukm value that is longer than the key-
   encryption key that will be produced by the KDF.

Russ

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 9 May 2017 14:16:57 -0700

On Tue, May 9, 2017 at 1:25 PM, Russ Housley <[email-masked]> wrote:

> [JLS] I would disagree that the value has to be random, a counter will
> work as well.  (An encrypted counter is better.)  I not be happy with a
> fixed size requirement on this easier.  There is no reason to make such a
> requirement that I can think of.  A 64-bit counter is just as rational.  It
> might make more sense to change this statement into something along the
> lines of
>
> * Any pair of static keys MUST NOT be used more times than the size of the
> key.  I.e. if 128-bit KEKs may be used, then there is a 2^128 limit on the
> number of times the key pair can be used.
> * The size of the KEK is normally not longer than the length of the
> resulting KEK as that is the limit of unique values that can be generated
> in any event.
>
>
> Section 2 already says that the ephemeral key MUST be used for only one
> message.  Thus, a UKM is not really needed.  However, the CMS requires
> support for a UKM if the sender include it.  For this reason, the document
> says how to handle it in the KDF if it is present.
>
> You are correct that a counter, encrypted counter, or random value will
> work, even if the originator uses the same ephemeral key for many
> messages.  The text does not limit the choices in any way.
>
> The text already says that there is no security reason for a UKM value
> that is longer than the KEK.  I think that EKR is asking for guidance on
> the minimum size too.
>
> [JLS] It’s kind of a stupid thing to do, but the minimum size would be one
> bit.  Although this is not legal from an ASN.1 standpoint – so the minimum
> would be one byte.
>
> A single byte with all bits zero and two bytes with all bits zero are
> different ukm values because of the way that they are used in the
> ECC-CMS-SharedInfo structure.  Note that this would not be the case if the
> ukm value was only used as a salt value to HKDF.  I do not see any reason
> to specify a minimum length of this value.  The only thing that is required
> is uniqueness, EKR is correct about saying this.
>
>
> I suggest:
>
>    a manner that ensures a unique KDF output;
>

Is this actually possible? The KDF is basically a PRF, so there is some
chance that 0*128 and 1*128 produce the same output.

-Ekr

however, there is no

---

From: Jim Schaad <[email-masked]>
Date: Tue, 9 May 2017 14:26:12 -0700

From: Russ Housley [mailto:[email-masked]] 
Sent: Tuesday, May 9, 2017 1:26 PM
To: Jim Schaad <[email-masked]>; Eric Rescorla <[email-masked]>
Cc: curdle <[email-masked]>
Subject: Re: [Curdle] AD Review: draft-ietf-curdle-cms-ecdh-new-curves-04.txt

I suggest this wording:

I suggest:

[JLS] Looks good to me

Russ

---

From: Russ Housley <[email-masked]>
Date: Tue, 9 May 2017 18:35:42 -0400

> On May 9, 2017, at 5:16 PM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> On Tue, May 9, 2017 at 1:25 PM, Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:

s/ensure/will with very high probability produce/

Russ

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 9 May 2017 16:59:41 -0700

I guess I would focus on the uniqueness of the input, because the output's
uniqueness is largely a function of:

1. Input uniqueness
2. The number of discrete inputs.

So, I think I would say:

"it MUST be selected in a manner that ensures it is unique with high
probability"

-Ekr

On Tue, May 9, 2017 at 3:35 PM, Russ Housley <[email-masked]> wrote:

>> * Any pair of static keys MUST NOT be used more times than the size of
>> the key.  I.e. if 128-bit KEKs may be used, then there is a 2^128 limit on
>> the number of times the key pair can be used.
>> [JLS] It’s kind of a stupid thing to do, but the minimum size would be
>> one bit.  Although this is not legal from an ASN.1 standpoint – so the
>> minimum would be one byte.
>>

---

From: Russ Housley <[email-masked]>
Date: Wed, 10 May 2017 09:50:08 -0400

Yes, that works for me.  I’ll post an updated I-D later today.

Russ

> On May 9, 2017, at 7:59 PM, Eric Rescorla <[email-masked]> wrote:
> 
> I guess I would focus on the uniqueness of the input, because the output's uniqueness is largely a function of:
> 
> 1. Input uniqueness
> "it MUST be selected in a manner that ensures it is unique with high probability"
> 
> -Ekr
> 
> 
> 
> On Tue, May 9, 2017 at 3:35 PM, Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> On May 9, 2017, at 5:16 PM, Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 10 May 2017 15:06:52 -0700

I apologize but I just took a look at the language around invalid points. I
would suggest
you use the same language as TLS here:

   For X25519 and X448, implementations SHOULD use the approach
   specified in [RFC7748] to calculate the Diffie-Hellman shared secret.
   Implementations MUST check whether the computed Diffie-Hellman shared
   secret is the all-zero value and abort if so, as described in
   Section 6 of [RFC7748].  If implementers use an alternative
   implementation of these elliptic curves, they SHOULD perform the
   additional checks specified in Section 7 of [RFC7748].

LMK what you think.

Best,
-Ekr

---

From: Russ Housley <[email-masked]>
Date: Thu, 11 May 2017 12:15:47 -0400

To make it flow with the text that is already there, I suggest:

   X25519 is described in Section 6.1 of [CURVES], and X448 is described
   in Section 6.2 of [CURVES].  Conforming implementations MUST check
   whether the computed Diffie-Hellman shared secret is the all-zero
   value, and abort if so, as described in Section 6 of [CURVES].  If an
   alternative implementation of these elliptic curves is employed, then
   the additional checks specified in Section 7 of [CURVES] SHOULD be
   performed.

Russ

> On May 10, 2017, at 6:06 PM, Eric Rescorla <[email-masked]> wrote:
> 
> I apologize but I just took a look at the language around invalid points. I would suggest
> On Wed, May 10, 2017 at 6:50 AM, Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:
>> On May 9, 2017, at 7:59 PM, Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
>> 
> _______________________________________________
> Curdle mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/curdle

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 11 May 2017 11:13:09 -0700

Nit, I think you should specify alternative to what.

  If an
   alternative implementation of these elliptic curves to that documented
   in [RFC7748 Section 6] is employed, then
   the additional checks specified in Section 7 of [CURVES] SHOULD be
   performed.

On Thu, May 11, 2017 at 9:15 AM, Russ Housley <[email-masked]> wrote:

>> I guess I would focus on the uniqueness of the input, because the
>> output's uniqueness is largely a function of:
>>
>> 1. Input uniqueness
>>>> Yes. The umm value needs to be different for each invocation of the
>>>> KDF, otherwise it does not provide the assurance that different keying
>>>> material will be produced.  Of course, an implementation will generate the
>>>> umm value using random number generator, not track the values that are
>>>> used.  Several years ago, there was a discussion about the size of the ukm
>>>> needed.  Some people were suggesting crazy large values, and the point was
>>>> made that anything beyond the SIZEOF(KEK) did not improve security.
>>>>

---

From: Russ Housley <[email-masked]>
Date: Thu, 11 May 2017 15:44:19 -0400

Yes, that is more clear.  I just posted draft-ietf-curdle-cms-ecdh-new-curves-07 with that update.

Russ

> On May 11, 2017, at 2:13 PM, Eric Rescorla <[email-masked]> wrote:
> 
> On Thu, May 11, 2017 at 9:15 AM, Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:
>> On May 10, 2017, at 6:06 PM, Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/curdle <https://www.ietf.org/mailman/listinfo/curdle>
> 
>