Subject: [Acme] FW: [ietf-wg-acme/acme] Add a meta flag to indicate when GET requests for certificates are allowed (#462)

From: "Salz, Rich" <[email-masked]>
Date: Sun, 7 Oct 2018 23:37:23 +0000

WG, this PR adds a new optional indicator that GET can be used to fetch certificates.

If you opposed please speak up now.

From: Richard Barnes <[email-masked]>
Reply-To: ietf-wg-acme/acme <reply+006fe294e1a4ec2f9470[email-masked]>
Date: Sunday, October 7, 2018 at 3:47 PM
To: ietf-wg-acme/acme <[email-masked]>
Cc: Subscribed <[email-masked]>
Subject: [ietf-wg-acme/acme] Add a meta flag to indicate when GET requests for certificates are allowed (#462)

This avoids the need for the client to guess. Assumes that #459<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_459&d=DwMCaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=zJkImRuZ93rmhcDQ-zHtt5LOUgwqtl2aszwdEpSC0-w&s=6yfRh9z504d7dO7AZHfqVaLK67f8VZUhbutg4HyibIs&e=> will not be merged.

________________________________
You can view, comment on, or merge this pull request online at:

  https://github.com/ietf-wg-acme/acme/pull/462<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_462&d=DwMCaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=zJkImRuZ93rmhcDQ-zHtt5LOUgwqtl2aszwdEpSC0-w&s=zCXMvIeBxWA73LLbBDMobFZR09mkRMCUrP9bM5v_ylk&e=>

Commit Summary

  *   Add a meta flag to indicate when GET requests for certificates are allowed

File Changes

  *   M draft-ietf-acme-acme.md<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_462_files-23diff-2D0&d=DwMCaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=zJkImRuZ93rmhcDQ-zHtt5LOUgwqtl2aszwdEpSC0-w&s=3-t1zAmt-HqR18SwnxsCgquqZyRAmp77GPE5ARp-XPg&e=> (4)

Patch Links:

  *   https://github.com/ietf-wg-acme/acme/pull/462.patch<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_462.patch&d=DwMCaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=zJkImRuZ93rmhcDQ-zHtt5LOUgwqtl2aszwdEpSC0-w&s=iLEjv5GNBU4uXvONa0gllnpyj3HovrLyy5nqQK-zvYo&e=>
  *   https://github.com/ietf-wg-acme/acme/pull/462.diff<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_462.diff&d=DwMCaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=zJkImRuZ93rmhcDQ-zHtt5LOUgwqtl2aszwdEpSC0-w&s=8CNiNAnFkQae97gch-t0HidpnAqkaBJQ8su695zMYX0&e=>

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_462&d=DwMCaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=zJkImRuZ93rmhcDQ-zHtt5LOUgwqtl2aszwdEpSC0-w&s=zCXMvIeBxWA73LLbBDMobFZR09mkRMCUrP9bM5v_ylk&e=>, or mute the thread<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AG-5FilACJeDnYH-2DFetofUArLOJQvAVdpKks5uilpMgaJpZM4XMAP2&d=DwMCaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=zJkImRuZ93rmhcDQ-zHtt5LOUgwqtl2aszwdEpSC0-w&s=r8HeHSMQ1w62iouWigror9a1ItZfkYtv9oNryK1PXMo&e=>.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 8 Oct 2018 06:23:41 -0700

Speaking as an individual.

Just to be clear, this change would be expected to coexist with the
existing capabilities text? Richard, does it require that we retain that
text?

-Ekr

On Sun, Oct 7, 2018 at 4:37 PM Salz, Rich <[email-masked]> wrote:

> *From: *Richard Barnes <[email-masked]>
> *Reply-To: *ietf-wg-acme/acme <
> reply+006fe294e1a4ec2f9470[email-masked]
> >
> *Date: *Sunday, October 7, 2018 at 3:47 PM
> *To: *ietf-wg-acme/acme <[email-masked]>
> *Cc: *Subscribed <[email-masked]>
> *Subject: *[ietf-wg-acme/acme] Add a meta flag to indicate when GET
> requests for certificates are allowed (#462)
>
>
>
> This avoids the need for the client to guess. Assumes that #459
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_459&d=DwMCaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=zJkImRuZ93rmhcDQ-zHtt5LOUgwqtl2aszwdEpSC0-w&s=6yfRh9z504d7dO7AZHfqVaLK67f8VZUhbutg4HyibIs&e=>
> will not be merged.
> ------------------------------
>   https://github.com/ietf-wg-acme/acme/pull/462
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_462&d=DwMCaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=zJkImRuZ93rmhcDQ-zHtt5LOUgwqtl2aszwdEpSC0-w&s=zCXMvIeBxWA73LLbBDMobFZR09mkRMCUrP9bM5v_ylk&e=>
> Commit Summary
>
>    - Add a meta flag to indicate when GET requests for certificates are
>    allowed
>
> File Changes
>
>    - *M* draft-ietf-acme-acme.md
>    <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_462_files-23diff-2D0&d=DwMCaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=zJkImRuZ93rmhcDQ-zHtt5LOUgwqtl2aszwdEpSC0-w&s=3-t1zAmt-HqR18SwnxsCgquqZyRAmp77GPE5ARp-XPg&e=>
>    (4)
>
> Patch Links:
>
>    - https://github.com/ietf-wg-acme/acme/pull/462.patch
>    <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_462.patch&d=DwMCaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=zJkImRuZ93rmhcDQ-zHtt5LOUgwqtl2aszwdEpSC0-w&s=iLEjv5GNBU4uXvONa0gllnpyj3HovrLyy5nqQK-zvYo&e=>
>    - https://github.com/ietf-wg-acme/acme/pull/462.diff
>    <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_462.diff&d=DwMCaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=zJkImRuZ93rmhcDQ-zHtt5LOUgwqtl2aszwdEpSC0-w&s=8CNiNAnFkQae97gch-t0HidpnAqkaBJQ8su695zMYX0&e=>
>
> —
> Reply to this email directly, view it on GitHub
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_462&d=DwMCaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=zJkImRuZ93rmhcDQ-zHtt5LOUgwqtl2aszwdEpSC0-w&s=zCXMvIeBxWA73LLbBDMobFZR09mkRMCUrP9bM5v_ylk&e=>,
> or mute the thread
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AG-5FilACJeDnYH-2DFetofUArLOJQvAVdpKks5uilpMgaJpZM4XMAP2&d=DwMCaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=zJkImRuZ93rmhcDQ-zHtt5LOUgwqtl2aszwdEpSC0-w&s=r8HeHSMQ1w62iouWigror9a1ItZfkYtv9oNryK1PXMo&e=>
> .[image:
> https://github.com/notifications/beacon/AG_ilMuU3qzikm4v1_8wAF3QiJ0pjULGks5uilpMgaJpZM4XMAP2.gif]
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 8 Oct 2018 09:31:10 -0400

Not sure which existing text you're referring to.  No conflict comes to
mind.

In particular, this seems compatible with the stuff in #post-as-get about
how the server indicates that it doesn't allow GET.  The model I have in
mind is that this flag indicates that it's reasonable for the client to try
GET, but the server may still deny in some cases.  Maybe that could be
clarified.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 8 Oct 2018 09:42:56 -0700

My question is whether you would remove the text that JSHA was objecting to
about capabilities URLs.

---

From: Richard Barnes <[email-masked]>
Date: Mon, 8 Oct 2018 12:45:48 -0400

No, because GET+capability > GET.  If you're going to have GET at all, you
should have GET+capability.

On Mon, Oct 8, 2018 at 12:43 PM Eric Rescorla <[email-masked]> wrote:

> My question is whether you would remove the text that JSHA was objecting
> to about capabilities URLs.
>
>>>>    - Add a meta flag to indicate when GET requests for certificates
>>>>    are allowed
>>>>
>>>> File Changes
>>>>

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 8 Oct 2018 17:58:23 +0000

*   No, because GET+capability > GET.  If you're going to have GET at all, you should have GET+capability

And more importantly, you do not HAVE to do it; the text just has pointers on how to do it if desired.

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Mon, 8 Oct 2018 12:27:25 -0700

I'm opposed to this change. It's better for STAR to just extend the 
Order object with a new "gettableCert" URL field. Less complex.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 8 Oct 2018 13:40:01 -0700

Thanks for clarifying.

On Mon, Oct 8, 2018 at 10:58 AM Salz, Rich <[email-masked]> wrote:

>
>    - No, because GET+capability > GET.  If you're going to have GET at
>    all, you should have GET+capability
>
>
>

---

From: Daniel McCarney <[email-masked]>
Date: Tue, 9 Oct 2018 10:31:45 -0400

I am also opposed to this change. I think it is a clunky solution and there
hasn't been convincing justification of why the base ACME draft needs to
carry this complexity instead of having STAR add the extensions it
requires.

On Mon, Oct 8, 2018 at 3:27 PM Jacob Hoffman-Andrews <[email-masked]> wrote:

> I'm opposed to this change. It's better for STAR to just extend the Order
> object with a new "gettableCert" URL field. Less complex.

---

From: Richard Barnes <[email-masked]>
Date: Tue, 9 Oct 2018 10:45:40 -0400

So here's the compromise I would propose:

1. Remove GET for certificates.  I think this is a mistake, but I can grant
that it's clunky as-is, and it will be straightforward to re-add it later
if it's needed.

2. Keep the security considerations about capability URLs and the
randomized examples.  Those are needed for the correlation concerns
regardless of GET.

In units of PRs, I think that means:
- Merge #459 (remove GET for certificates)
- Merge #460 (randomize URLs)
- Close #462 (meta flag for GET; obsoleted by #459)
- Close #457 (remove recommendation for capability URLs; obsoleted by #459)

Jacob, Daniel: How does that strike you?

--Richard

On Tue, Oct 9, 2018 at 10:32 AM Daniel McCarney <[email-masked]> wrote:

> I am also opposed to this change. I think it is a clunky solution and
> there hasn't been convincing justification of why the base ACME draft needs
> to carry this complexity instead of having STAR add the extensions it
> requires.
>

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Tue, 9 Oct 2018 11:53:40 -0700

On 10/09/2018 07:45 AM, Richard Barnes wrote:
> 1. Remove GET for certificates.  I think this is a mistake, but I can 
> grant that it's clunky as-is, and it will be straightforward to re-add 
> it later if it's needed.

Great.

Ah, I had missed this. The relevant text:

 > In order to avoid leaking these correlations, servers SHOULD assign
 > capability URLs for dynamically-created resources
 > {{?W3C.WD-capability-urls-20140218}}.  These URLs incorporate large
 > unpredictable components to prevent third parties from guessing
 > them.  These URLs SHOULD NOT have a structure that would enable a
 > third party to infer correlations between resources.

This is not really the correct use of the term "capability URL," since 
knowledge of a URL doesn't grant access to a resource. I would instead 
just say "URLs with unpredictable components" (as the second sentence uses).

Also, I would add a caveat that this type of URL design is only 
necessary for properties that the CA considers secret. For instance, 
Let's Encrypt does not consider its number of accounts secret, and 
assigns serially incrementing IDs to account URLs.

I'll send a PR later today tweaking this section. I'll also review #460 
in more detail. In principle I'm not opposed to randomizing some of the 
entity URLs where it helps demonstrate the concepts from the security 
considerations section.

That said, I'd just like to reiterate: Capability URLs are *bad*. The 
second sentence in https://www.w3.org/TR/capability-urls/ is:

"There are times when this is useful, for example one-shot password 
reset URLs, but overuse can be problematic as URLs cannot generally be 
kept secret."

I hope no one walks away from this conversation thinking "I'd like to 
incorporate capability URLs into my next project!"

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Tue, 9 Oct 2018 12:20:00 -0700

On 10/09/2018 11:53 AM, Jacob Hoffman-Andrews wrote:
> I'll send a PR later today tweaking this section.

Here's a PR improving the correlations section of security concerns: 
https://github.com/ietf-wg-acme/acme/pull/463

---

From: Richard Barnes <[email-masked]>
Date: Tue, 9 Oct 2018 15:27:53 -0400

Thanks for the PR.

My only issue is with the changes in there that slim down the example.
ISTM that we should be encouraging unguessable URLs as widely as possible;
guessable URLs should be a justified exception (as you noted in your
description of what LE does).

If you could slim this down to just killing the "Capability URL" reference,
I would be +1

---

From: "Diego R. Lopez" <[email-masked]>
Date: Tue, 9 Oct 2018 22:28:41 +0000

If I understood this compromise proposal, that implies to put STAR out of play… Or am I missing something?

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
https://www.linkedin.com/in/dr2lopez/

e-mail: [email-masked]<mailto:[email-masked]>
Tel:         +34 913 129 041
Mobile:  +34 682 051 091
----------------------------------

On 09/10/2018, 16:46, "Acme on behalf of Richard Barnes" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

1. Remove GET for certificates.  I think this is a mistake, but I can grant that it's clunky as-is, and it will be straightforward to re-add it later if it's needed.

2. Keep the security considerations about capability URLs and the randomized examples.  Those are needed for the correlation concerns regardless of GET.

--Richard

On Tue, Oct 9, 2018 at 10:32 AM Daniel McCarney <[email-masked]<mailto:[email-masked]>> wrote:
I am also opposed to this change. I think it is a clunky solution and there hasn't been convincing justification of why the base ACME draft needs to carry this complexity instead of having STAR add the extensions it requires.

>   https://github.com/ietf-wg-acme/acme/pull/462<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_462&d=DwMCaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86Fts…

I'm opposed to this change. It's better for STAR to just extend the Order object with a new "gettableCert" URL field. Less complex.
_______________________________________________
Acme mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/acme
_______________________________________________
Acme mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/acme

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Tue, 9 Oct 2018 16:39:58 -0700

> of play… Or am I missing something?
Not at all, it just means that STAR needs to define a new field on the 
Order resource that specifies a polling URL for frequently-updating 
certificates. This is probably a good thing anyhow, since the semantics 
of STAR are different than the normal semantics of baseline ACME. In 
baseline ACME, the contents of the certificate URL generally don't 
change after issuance, but in STAR, the goal is to have some URL whose 
contents are expected to change periodically to contain the most 
recently issued certificate for the relevant names.

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Tue, 9 Oct 2018 16:49:15 -0700

I'll revise this to include examples from the other URLs. One of my 
goals is to switch away from the "counting accounts" or "counting 
authzs" examples (which I think we can't effectively mitigate) to more 
specific examples of correlations. However, I think I can make that 
point with examples from across all the different resource types.

On 10/09/2018 12:27 PM, Richard Barnes wrote:
> Thanks for the PR.
>
> My only issue is with the changes in there that slim down the 
> example.  ISTM that we should be encouraging unguessable URLs as 
> widely as possible; guessable URLs should be a justified exception (as 
> you noted in your description of what LE does).
>
> If you could slim this down to just killing the "Capability URL" 
> reference, I would be +1
>
> On Tue, Oct 9, 2018 at 3:20 PM Jacob Hoffman-Andrews <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     [email-masked] <mailto:[email-masked]>

---

From: Richard Barnes <[email-masked]>
Date: Tue, 9 Oct 2018 20:18:46 -0400

You seem to be trying to approach this point-by-point.  What Adam and I
have been saying is that randomizing everything, you don't have to do the
analysis case by case.  That's why that's the desired recommendation --
it's conservative.

If you want to do the analysis, go ahead.  The URL plan is 100% up to the
server operator.  But the recommendation in the spec should be the
conservative one.

--Richard

On Tue, Oct 9, 2018 at 7:49 PM Jacob Hoffman-Andrews <[email-masked]> wrote:

> I'll revise this to include examples from the other URLs. One of my goals
> is to switch away from the "counting accounts" or "counting authzs"
> examples (which I think we can't effectively mitigate) to more specific
> examples of correlations. However, I think I can make that point with
> examples from across all the different resource types.
>

---

From: Tim Hollebeek <[email-masked]>
Date: Wed, 10 Oct 2018 19:16:35 +0000

I suspect that the guessable account numbers is something the LE folks will eventually regret for one reason or another.

It’s poor security design to make something public and/or guessable if it doesn’t need to be.

-Tim

From: Acme <[email-masked]> On Behalf Of Richard Barnes
Sent: Tuesday, October 9, 2018 8:19 PM
To: Jacob Hoffman-Andrews <[email-masked]>
Cc: IETF ACME <[email-masked]>
Subject: Re: [Acme] FW: [ietf-wg-acme/acme] Add a meta flag to indicate when GET requests for certificates are allowed (#462)

You seem to be trying to approach this point-by-point..  What Adam and I have been saying is that randomizing everything, you don't have to do the analysis case by case.  That's why that's the desired recommendation -- it's conservative.

If you want to do the analysis, go ahead.  The URL plan is 100% up to the server operator.  But the recommendation in the spec should be the conservative one.

--Richard

On Tue, Oct 9, 2018 at 7:49 PM Jacob Hoffman-Andrews <[email-masked] <mailto:[email-masked]> > wrote:

I'll revise this to include examples from the other URLs. One of my goals is to switch away from the "counting accounts" or "counting authzs" examples (which I think we can't effectively mitigate) to more specific examples of correlations. However, I think I can make that point with examples from across all the different resource types.

Thanks for the PR.  

My only issue is with the changes in there that slim down the example.  ISTM that we should be encouraging unguessable URLs as widely as possible; guessable URLs should be a justified exception (as you noted in your description of what LE does).  

If you could slim this down to just killing the "Capability URL" reference, I would be +1

On Tue, Oct 9, 2018 at 3:20 PM Jacob Hoffman-Andrews <[email-masked] <mailto:[email-masked]> > wrote:

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Wed, 10 Oct 2018 14:06:24 -0700

Updated to include Orders and Authorizations in the example as you 
requested. https://github.com/ietf-wg-acme/acme/pull/463/files

On 10/09/2018 04:49 PM, Jacob Hoffman-Andrews wrote:
>> widely as possible; guessable URLs should be a justified exception 
>> (as you noted in your description of what LE does).
>>

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Wed, 10 Oct 2018 14:23:35 -0700

Pushed some more changes.

On 10/10/2018 02:06 PM, Jacob Hoffman-Andrews wrote:
>> authzs" examples (which I think we can't effectively mitigate) to 
>> more specific examples of correlations. However, I think I can make 
>> that point with examples from across all the different resource types.
>>
>>

---

From: Richard Barnes <[email-masked]>
Date: Wed, 10 Oct 2018 17:30:48 -0400

Chairs: It looks like there's consensus among the author team to close out
this discussoin by merging #459, #460, and #463.  Is that all right with
you?

On Wed, Oct 10, 2018 at 5:23 PM Jacob Hoffman-Andrews <[email-masked]> wrote:

> Acme mailing [email-masked]://www.ietf.org/mailman/listinfo/acme
>
>
>
>
> Acme mailing [email-masked]://www.ietf.org/mailman/listinfo/acme
>
>
>

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 11 Oct 2018 14:44:44 +0000

*   Chairs: It looks like there's consensus among the author team to close out this discussoin by merging #459, #460, and #463.  Is that all right with you?

Yes.

Thanks for everyone working so hard on this at the last minute, and coming to agreement.

If anyone on the WG objects to the changes in the PR, please speak up now.  Discussion has gone on for some time, and this addresses IESG review.  We’re not going to redo WGLC, but expect the next draft to be “it”