From nobody Fri May 1 05:10:54 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EFBE43A1125; Fri, 1 May 2020 05:10:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Rifaat Shekh-Yusef via Datatracker To: Cc: captive-portals@ietf.org, draft-ietf-capport-rfc7710bis.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.128.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158833501993.21190.4904257765699741589@ietfa.amsl.com> Reply-To: Rifaat Shekh-Yusef Date: Fri, 01 May 2020 05:10:19 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-capport-rfc7710bis-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2020 12:10:20 -0000 Reviewer: Rifaat Shekh-Yusef Review result: Has Issues Since the use of IP address literal is not forbidden by this document, what if an attacker with the ability to inject DHCP messages or RAs uses this option to force the user to contact an IP address of his choosing? In this case, the use of TLS and presenting the identity in the certificate might not be of much help. I think this case should be discussed in the security consideration section. From nobody Sat May 2 23:39:08 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 791363A161D; Sat, 2 May 2020 23:38:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Valery Smyslov via Datatracker To: Cc: last-call@ietf.org, draft-ietf-secevent-http-push.all@ietf.org, id-event@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.129.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158848793845.30822.14865138131669756772@ietfa.amsl.com> Reply-To: Valery Smyslov Date: Sat, 02 May 2020 23:38:58 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-secevent-http-push-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2020 06:38:59 -0000 Reviewer: Valery Smyslov Review result: Has Issues I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document defines push-based Security Event Tokens (SET) delivery using HTTP transport. I think the document has few issues that are easy to fix. Major issue: 1. Section 5.1: In scenarios where HTTP authorization or TLS mutual authentication are not used or are considered weak, JWS signed SETs SHOULD be used (see [RFC7515] and Section 5 of [RFC8417]). I think this "SHOULD" is inconsistent with RFC8417, which states: Unless integrity of the JWT is ensured by other means, it MUST be signed using JWS [RFC7515] by an issuer that is trusted to do so for the use case so that the SET can be authenticated and validated by the SET recipient. If you believe that there are valid use-cases when unsigned SETs can be transferred over unauthenticated transport (violating MUST from RFC8417), then please describe them. 2. Section 6. I think that Privacy Considerations lack discussion of what information an attacker can learn by analyzing HTTP responses if the HTTP connection is not protected by TLS. In this case even if the SET itself is encrypted, the attacker is able to get some useful information if it can read HTTP responses (e.g. if it is on the path). In particular, it can learn whether the SET is accepted or not and the reason for its rejection. Minor issues: 1. Section 5.1: This [using JWS] enables the SET Recipient to validate that the SET Transmitter is authorized to deliver the SET. I think this sentence is formally wrong, because SET signature allows to identify SET Issuer, but not SET Transmitter. From my reading of the draft they can be different entities. The SET Transmitter in this case remains mostly anonymous. 2. Section 5.2: As stated in Section 2.7.1 of [RFC7230], an HTTP requestor MUST NOT generate the "userinfo" (i.e., username and password) component (and its "@" delimiter) when an "http" URI reference is generated with a message, as they are now disallowed in HTTP. This requirement is already in RFC7230, so is there any need to repeat it? Is it related to security or to interoperability? In the latter case it's better to mention this requirement in Section 2.1. In the former case a few words explaining security implications of this requirement would help. 3. Section 5.4: This may be mitigated by authenticating SET Transmitters with a mechanism with low runtime overhead, such as mutual TLS. I don't think that TLS can be attributed as "a mechanism with low runtime overhead" when you talk about DoS protection. TLS itself may be a target for DoS attacks, because server have to do quite a lot of computations before client presents its authentication information, which may be bogus. So, it has exactly the same problem you described earlier in this para. 4. Section 6. In some cases, subject identifiers themselves may be considered sensitive information, such that their inclusion within a SET may be considered a violation of privacy. SET Transmitters should consider the ramifications of sharing a particular subject identifier with a SET Recipient (e.g., whether doing so could enable correlation and/or de-anonymization of data) and choose appropriate subject identifiers for their use cases. In my understanding of the draft SET Transmitters may be different entities from SET Issuers. I think it is SET Issuers who prepare SETs, not SET Transmitters. In general SET Transmitters don't know what's inside the SET (if JWE is used) and cannot modify it (if JWS is used). 5. (not related to security) Section 2.4: Implementations SHOULD expect that other Error Codes MAY also be received, as the set of Error Codes is extensible via the IANA "Security Event Token Delivery Error Codes" registry established in Section 7.1. I think that the normative "MAY is used improperly here and should be "may" instead. I also think that some words of what implementations should do with unknown error codes would help. Nits: 1. Table 1 is difficult to read due to unusual text formatting within the cells. From nobody Sun May 3 14:58:49 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 074DE3A120A for ; Sun, 3 May 2020 14:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.249 X-Spam-Level: X-Spam-Status: No, score=-9.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=loon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oI_hZa265Xbk for ; Sun, 3 May 2020 14:58:42 -0700 (PDT) Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com [IPv6:2607:f8b0:4864:20::b2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67C703A10EB for ; Sun, 3 May 2020 14:58:42 -0700 (PDT) Received: by mail-yb1-xb2f.google.com with SMTP id v9so2079868ybq.13 for ; Sun, 03 May 2020 14:58:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=loon.com; s=google; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=9t8gzhJxrrhcxOVa+fb/TLAdXyOl1P/+ag6qIYP3y7g=; b=YFVXjbwjHGo3U5BY8s1cIet4NQSiiEY70Cpwa7i6N8fNt133siQpN3NrxYmeFjVp9o iWN8g5KoLxFNIjgaLcMJVaI7U/cVqx3Ib5ZNf5vKFEPqAOWmGKAbDGQTObR1lFQqUSUg QVr9nWeJHom7MA5lijtLMnH6AVJd4ESygzZrs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=9t8gzhJxrrhcxOVa+fb/TLAdXyOl1P/+ag6qIYP3y7g=; b=W0RRPhC7YzU8k+Oefx0KnvM5A5zMUU+qRX2nIEOmenYNbUtcYajWGUOCx/x6vne23r Fbmqa3i2PT7yimLP4pUehHnvQe+dhgvvVwvuCXbTxN3nAb7AkP1OtrScBkNwHuAZ8H3K EjIfCMhTK78U/wlcDKrbtp56BHhrHA3Fx4YdcUntcwtagZ9XBD5e9ML5allKZmnOnF5j PWrvNLi/EdRfXgq6THOwj5PSuS7qPXGhhON87NZoIb1DafgN5v0GVz2s78iLxRUYaGc2 N+l/w18Ha8w67a5OspfTBiswwcXUjsmqW896K3TjvomTOEkTQYOzk/JJUJHEzuwADqtD 5PRQ== X-Gm-Message-State: AGi0PuYXsEQo08+d8XfDJMZfTUItw2LkBbkmlG2X94B3UFmcv/+OZ5z8 kzb7oQZtmX+jj2RK6c38UcgHjgvQAhXwCjpTigPIgw== X-Google-Smtp-Source: APiQypLbLRL0R58TFwZTjo4ilAzy6P0+oKKPL43ZXs2wM8Vua5UoqZZdZMcPYaneHWcSdUe06bQ3oA9ERiFLdYTnX48= X-Received: by 2002:a25:9384:: with SMTP id a4mr2937271ybm.79.1588543121115; Sun, 03 May 2020 14:58:41 -0700 (PDT) MIME-Version: 1.0 References: <158833501993.21190.4904257765699741589@ietfa.amsl.com> In-Reply-To: <158833501993.21190.4904257765699741589@ietfa.amsl.com> Reply-To: ek@loon.com From: Erik Kline Date: Sun, 3 May 2020 14:58:29 -0700 Message-ID: To: Rifaat Shekh-Yusef Cc: secdir@ietf.org, captive-portals , draft-ietf-capport-rfc7710bis.all@ietf.org, last-call@ietf.org Content-Type: multipart/alternative; boundary="0000000000007244f905a4c584e4" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-capport-rfc7710bis-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2020 21:58:44 -0000 --0000000000007244f905a4c584e4 Content-Type: text/plain; charset="UTF-8" Rifaat, Thanks for your reading of the document. The security section has a paragraph that begins: """ An attacker with the ability to inject DHCP messages or RAs could include an option from this document to force users to contact an address of his choosing. As an attacker with this capability could simply list himself as the default gateway (and so intercept all the victim's traffic); this does not provide them with significantly more capabilities, but because this document removes the need for interception, the attacker may have an easier time performing the attack... """ Do you have any specific ideas for what text might be added to clarify vis. your concern? Would a sentence that captures your "the use of TLS and presenting the identity in the certificate might not be of much help" observation suffice? Thanks, -Erik On Fri, 1 May 2020 at 05:10, Rifaat Shekh-Yusef via Datatracker < noreply@ietf.org> wrote: > Reviewer: Rifaat Shekh-Yusef > Review result: Has Issues > > Since the use of IP address literal is not forbidden by this document, > what if > an attacker with the ability to inject DHCP messages or RAs uses this > option > to force the user to contact an IP address of his choosing? In this case, > the use > of TLS and presenting the identity in the certificate might not be of much > help. > > I think this case should be discussed in the security consideration > section. > > > --0000000000007244f905a4c584e4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Rifaat,

Thanks for your reading of the = document.

The security section=C2=A0has a paragrap= h that begins:

"""
=C2=A0= =C2=A0An attacker with the ability to inject DHCP messages or RAs could=C2=A0 =C2=A0include an option from this document to force users to contac= t an
=C2=A0 =C2=A0address of his choosing.=C2=A0 As an attacker with thi= s capability could
=C2=A0 =C2=A0simply list himself as the default gatew= ay (and so intercept all the
=C2=A0 =C2=A0victim's traffic); this do= es not provide them with significantly more
=C2=A0 =C2=A0capabilities, b= ut because this document removes the need for
=C2=A0 =C2=A0interception,= the attacker may have an easier time performing the
=C2=A0 =C2=A0attack= ...
"""

Do you have a= ny specific ideas for what text might be added to clarify vis. your concern= ?=C2=A0 Would a sentence that captures your "the use of TLS and presen= ting the identity in the certificate might not be of much help" observ= ation suffice?

Thanks,
-Erik
=
On Fri= , 1 May 2020 at 05:10, Rifaat Shekh-Yusef via Datatracker <noreply@ietf.org> wrote:
Reviewer: Rifaat Shekh-Yusef
Review result: Has Issues

Since the use of IP address literal is not forbidden by this document, what= if
an attacker with the ability to inject DHCP messages or RAs uses this optio= n
to force the user to contact an IP address of his choosing? In this case, t= he use
of TLS and presenting the identity in the certificate might not be of much = help.

I think this case should be discussed in the security consideration section= .


--0000000000007244f905a4c584e4-- From nobody Tue May 5 16:25:29 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 78F853A0E60; Fri, 1 May 2020 03:35:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1588329304; bh=w3FXcBnbJ4sW28mJBF0/f3jrAKiLcXQtbN3XY9uSce0=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=njx9YGj/lpXT6cVDwfwr0fWobciIzQuiaRb4dY642TdT150/SHf7y30i+ijvPOReV QKFI+/AuD4Xw7fm7tEOELVpcu66II1klyr5V99Z6+JVYi4c8c4IYNqXakgTLFCRMZ0 ll6TPJ9G7ssFbENCS+9MOxieFQUMung20e3wUgKM= X-Mailbox-Line: From new-work-bounces@ietf.org Fri May 1 03:35:03 2020 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 58A1D3A0E55; Fri, 1 May 2020 03:35:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1588329303; bh=w3FXcBnbJ4sW28mJBF0/f3jrAKiLcXQtbN3XY9uSce0=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=uFeAJiHLb/gAWTeMBLUhWe3If3L4s9qK+sKIEMxs6bZzrYKQRAa4VWI2Ksmabh6/Y s8Mg9YcUCigTEn3CuGoGWQSjO6gkMIxGTI8rKtZyX/6QeixLYVgv5/gh51Ka/14cfj +rNePxWlCnoBuvajTfvfLZx5MiYYsYtxRGvEGpqI= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 657C93A0E53 for ; Fri, 1 May 2020 03:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i_XoFhBgxk7o for ; Fri, 1 May 2020 03:34:58 -0700 (PDT) Received: from raoul.w3.org (raoul.w3.org [128.30.52.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2DC03A0E55 for ; Fri, 1 May 2020 03:34:58 -0700 (PDT) Received: from [112.102.246.60] (helo=[192.168.0.100]) by raoul.w3.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jUT0S-0006BX-D0 for new-work@ietf.org; Fri, 01 May 2020 10:34:57 +0000 To: new-work@ietf.org From: xueyuan Message-ID: <6f925024-b4a2-9dc1-c590-5eb3d1752101@w3.org> Date: Fri, 1 May 2020 18:34:50 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 Content-Language: en-US Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Precedence: list Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Tue, 05 May 2020 16:25:27 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Accessibility Education and Outreach Working Group (until 2020-06-11) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2020 10:35:07 -0000 CkhlbGxvLAoKVG9kYXkgVzNDIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZXMgcmVj ZWl2ZWQgYSBQcm9wb3NhbAp0byByZXZpZXcgYSBkcmFmdCBjaGFydGVyIGZvciB0aGUKIMKgIEFj Y2Vzc2liaWxpdHkgRWR1Y2F0aW9uIGFuZCBPdXRyZWFjaCBXb3JraW5nIEdyb3VwOgogwqAgaHR0 cHM6Ly93d3cudzMub3JnL1dBSS9FTy9jaGFydGVyMjAyMAoKQXMgcGFydCBvZiBlbnN1cmluZyB0 aGF0IHRoZSBjb21tdW5pdHkgaXMgYXdhcmUgb2YgcHJvcG9zZWQgd29yawphdCBXM0MsIHRoaXMg ZHJhZnQgY2hhcnRlciBpcyBwdWJsaWMgZHVyaW5nIHRoZSBBZHZpc29yeQpDb21taXR0ZWUgcmV2 aWV3IHBlcmlvZC4KClczQyBpbnZpdGVzIHB1YmxpYyBjb21tZW50cyB0aHJvdWdoIDIwMjAtMDYt MTEgb24gdGhlCnByb3Bvc2VkIGNoYXJ0ZXIuIFBsZWFzZSBzZW5kIGNvbW1lbnRzIHRvCnB1Ymxp Yy1uZXctd29ya0B3My5vcmcsIHdoaWNoIGhhcyBhIHB1YmxpYyBhcmNoaXZlOgogwqAgaHR0cDov L2xpc3RzLnczLm9yZy9BcmNoaXZlcy9QdWJsaWMvcHVibGljLW5ldy13b3JrLwoKT3RoZXIgdGhh biBjb21tZW50cyBzZW50IGluIGZvcm1hbCByZXNwb25zZXMgYnkgVzNDIEFkdmlzb3J5CkNvbW1p dHRlZSBSZXByZXNlbnRhdGl2ZXMsIFczQyBjYW5ub3QgZ3VhcmFudGVlIGEgcmVzcG9uc2UgdG8K Y29tbWVudHMuIElmIHlvdSB3b3JrIGZvciBhIFczQyBNZW1iZXIgWzFdLCBwbGVhc2UgY29vcmRp bmF0ZQp5b3VyIGNvbW1lbnRzIHdpdGggeW91ciBBZHZpc29yeSBDb21taXR0ZWUgUmVwcmVzZW50 YXRpdmUuIEZvcgpleGFtcGxlLCB5b3UgbWF5IHdpc2ggdG8gbWFrZSBwdWJsaWMgY29tbWVudHMg dmlhIHRoaXMgbGlzdCBhbmQKaGF2ZSB5b3VyIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRh dGl2ZSByZWZlciB0byBpdCBmcm9tIGhpcwpvciBoZXIgZm9ybWFsIHJldmlldyBjb21tZW50cy4K CklmIHlvdSBzaG91bGQgaGF2ZSBhbnkgcXVlc3Rpb25zIG9yIG5lZWQgZnVydGhlciBpbmZvcm1h dGlvbiwgcGxlYXNlCmNvbnRhY3QgU2hhd24gTGF3dG9uIEhlbnJ5LCBXM0MgRU9XRyBTdGFmZiBD b250YWN0IDxzaGF3bkB3My5vcmc+LgoKVGhhbmsgeW91LAoKWHVleXVhbiBKaWEsIFczQyBNYXJr ZXRpbmcgJiBDb21tdW5pY2F0aW9ucwoKWzFdIGh0dHA6Ly93d3cudzMub3JnL0NvbnNvcnRpdW0v TWVtYmVyL0xpc3QKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCm5ldy13b3JrIG1haWxpbmcgbGlzdApuZXctd29ya0BpZXRmLm9yZwpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldy13b3JrCg== From nobody Thu May 7 05:49:18 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 786853A053E for ; Thu, 7 May 2020 05:49:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.129.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <158885575605.14501.4369286642821581821@ietfa.amsl.com> Date: Thu, 07 May 2020 05:49:16 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 12:49:17 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2020-05-21 Reviewer LC end Draft Donald Eastlake R2019-11-14 draft-ietf-hip-dex-19 Stefan Santesson 2020-05-04 draft-ietf-httpbis-header-structure-18 Last calls: Reviewer LC end Draft John Bradley 2020-02-28 draft-ietf-regext-data-escrow-08 Alan DeKok 2019-06-04 draft-ietf-netvc-testing-09 Donald Eastlake 2020-02-27 draft-ietf-6tisch-msf-16 Donald Eastlake R2019-11-14 draft-ietf-hip-dex-19 Daniel Franke 2020-03-09 draft-ietf-regext-dnrd-objects-mapping-07 Aanchal Malhotra 2020-03-12 draft-ietf-bess-vpls-multihoming-05 Russ Mundy 2020-01-02 draft-ietf-dprive-bcp-op-09 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-11 Vincent Roca 2020-04-23 draft-ietf-detnet-ip-over-mpls-06 Stefan Santesson 2020-05-04 draft-ietf-httpbis-header-structure-18 Yaron Sheffer None draft-ietf-opsawg-tacacs-yang-03 Melinda Shore 2020-05-13 draft-ietf-secevent-http-poll-09 Tina Tsou 2020-05-08 draft-ietf-httpbis-client-hints-13 Sean Turner 2020-05-19 draft-ietf-dhc-mac-assign-06 Sean Turner 2020-05-06 draft-ietf-opsawg-sdi-02 Dacheng Zhang 2020-03-12 draft-nottingham-how-did-that-get-into-the-repo-01 Dacheng Zhang 2019-11-05 draft-ietf-mpls-ri-rsvp-frr-07 Next in the reviewer rotation: Mališa Vučinić Carl Wallace Samuel Weiler Brian Weis Klaas Wierenga Christopher Wood Paul Wouters Liang Xia Dacheng Zhang Derek Atkins From nobody Thu May 7 08:53:18 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BCFC3A0A63; Thu, 7 May 2020 08:50:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1588866657; bh=LLEz1rqUOIzFOay23m6X8Qx+b+Ti9CZ4m004qv/zNC8=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=h5XEvrkL87w22cEuF3fP+PPsONAqk23UmeLcrZVmpQTtajfhl19za/CHK/ps9j8by g3OmwEP+CqSNUGXa5iu1uyNMbRAJ0qycgs3HSbL+osya0FlPcO1QTt5CJgPx/s36/n HblhZvkO2Z2sHtxMDyXx39C15ZUJLiBbg5Z4cL78= X-Mailbox-Line: From new-work-bounces@ietf.org Thu May 7 08:50:57 2020 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 928B23A0A80; Thu, 7 May 2020 08:50:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1588866656; bh=LLEz1rqUOIzFOay23m6X8Qx+b+Ti9CZ4m004qv/zNC8=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=f09oDkWgWR0/Xzr57UVN4KxW1e/KCjok7x2t9MqymvWHEA7qZwN2jTqGjgOmrIehz ghcHyZfvuBh/BIzbpssalYX9AZ1XaBgNaF2fMOngAGroW3t31bVczdZASBGbZdrnYP t8dfbm/GgDLKkE0hbabtF9NZR3jwD0qR2bkSkcgQ= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9DF93A0A43 for ; Thu, 7 May 2020 08:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2yk0eEJKC1D for ; Thu, 7 May 2020 08:50:50 -0700 (PDT) Received: from raoul.w3.org (raoul.w3.org [128.30.52.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B55733A0A56 for ; Thu, 7 May 2020 08:50:49 -0700 (PDT) Received: from [112.102.246.208] (helo=[192.168.0.101]) by raoul.w3.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jWinP-0001UT-R2 for new-work@ietf.org; Thu, 07 May 2020 15:50:48 +0000 To: new-work@ietf.org From: xueyuan Message-ID: Date: Thu, 7 May 2020 23:50:30 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 Content-Language: en-US Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Precedence: list Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Thu, 07 May 2020 08:53:01 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: JSON-LD Working Group (until 2020-06-18) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 15:50:59 -0000 CkhlbGxvLAoKVG9kYXkgVzNDIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZXMgcmVj ZWl2ZWQgYSBQcm9wb3NhbAp0byByZXZpZXcgYSBkcmFmdCBjaGFydGVyIGZvciB0aGUgSlNPTi1M RCBXb3JraW5nIEdyb3VwOgogwqAgaHR0cHM6Ly93d3cudzMub3JnLzIwMjAvMDUvcHJvcG9zZWQt anNvbi1sZC13Zy1jaGFydGVyLmh0bWwKCkFzIHBhcnQgb2YgZW5zdXJpbmcgdGhhdCB0aGUgY29t bXVuaXR5IGlzIGF3YXJlIG9mIHByb3Bvc2VkIHdvcmsKYXQgVzNDLCB0aGlzIGRyYWZ0IGNoYXJ0 ZXIgaXMgcHVibGljIGR1cmluZyB0aGUgQWR2aXNvcnkKQ29tbWl0dGVlIHJldmlldyBwZXJpb2Qu CgpXM0MgaW52aXRlcyBwdWJsaWMgY29tbWVudHMgdGhyb3VnaCAyMDIwLTA2LTE4IG9uIHRoZQpw cm9wb3NlZCBjaGFydGVyLiBQbGVhc2Ugc2VuZCBjb21tZW50cyB0bwpwdWJsaWMtbmV3LXdvcmtA dzMub3JnLCB3aGljaCBoYXMgYSBwdWJsaWMgYXJjaGl2ZToKIMKgIGh0dHA6Ly9saXN0cy53My5v cmcvQXJjaGl2ZXMvUHVibGljL3B1YmxpYy1uZXctd29yay8KCk90aGVyIHRoYW4gY29tbWVudHMg c2VudCBpbiBmb3JtYWwgcmVzcG9uc2VzIGJ5IFczQyBBZHZpc29yeQpDb21taXR0ZWUgUmVwcmVz ZW50YXRpdmVzLCBXM0MgY2Fubm90IGd1YXJhbnRlZSBhIHJlc3BvbnNlIHRvCmNvbW1lbnRzLiBJ ZiB5b3Ugd29yayBmb3IgYSBXM0MgTWVtYmVyIFsxXSwgcGxlYXNlIGNvb3JkaW5hdGUKeW91ciBj b21tZW50cyB3aXRoIHlvdXIgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0aXZlLiBGb3IK ZXhhbXBsZSwgeW91IG1heSB3aXNoIHRvIG1ha2UgcHVibGljIGNvbW1lbnRzIHZpYSB0aGlzIGxp c3QgYW5kCmhhdmUgeW91ciBBZHZpc29yeSBDb21taXR0ZWUgUmVwcmVzZW50YXRpdmUgcmVmZXIg dG8gaXQgZnJvbSBoaXMKb3IgaGVyIGZvcm1hbCByZXZpZXcgY29tbWVudHMuCgpJZiB5b3Ugc2hv dWxkIGhhdmUgYW55IHF1ZXN0aW9ucyBvciBuZWVkIGZ1cnRoZXIgaW5mb3JtYXRpb24sIHBsZWFz ZQpjb250YWN0IEl2YW4gSGVybWFuLCBKU09OLUxEIFdvcmtpbmcgR3JvdXAgU3RhZmYgQ29udGFj dCwgYXQgPGl2YW5AdzMub3JnPi4KClRoYW5rIHlvdSwKClh1ZXl1YW4gSmlhLCBXM0MgTWFya2V0 aW5nICYgQ29tbXVuaWNhdGlvbnMKClsxXSBodHRwOi8vd3d3LnczLm9yZy9Db25zb3J0aXVtL01l bWJlci9MaXN0CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XwpuZXctd29yayBtYWlsaW5nIGxpc3QKbmV3LXdvcmtAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXctd29yawo= From nobody Thu May 7 20:45:29 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CD8323A0EC2; Thu, 7 May 2020 20:27:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1588908466; bh=ckEEnPnQSQja4JUhpP1Vh4oi1VnHHFcs1hMqjW6bBRU=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=yL7+7TOLTziGxm9/aNcpzJa8k7VZ+zf8H/98N3FNMbxsJSenaPqE6PiHlwoRhrjmT mVT4n1dWGBbtBWKh4mzOaMMGbh3lL3OXvf6FFwspZ3PcDcE94I8HNoDN/edq4Mu7AO g0BmgdiIEouBr+uw4d7Lo7gl3F5jUC0LURRGLIrY= X-Mailbox-Line: From new-work-bounces@ietf.org Thu May 7 20:27:45 2020 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D10143A0EBB; Thu, 7 May 2020 20:27:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1588908465; bh=ckEEnPnQSQja4JUhpP1Vh4oi1VnHHFcs1hMqjW6bBRU=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=Ry6NY4uqVXsmPYKoj1r14gXX5p15W8CXbn3Qk0LnJP49Zq/8/daIwBFw4Fw9RMWHU h/2STL4L69Pl5drX6ouxY0ioxJyMPW5hwqwQJq/KXrRvxB30jUPtmEXIdEgf0hPGO3 tkOkYsxHOZLTQLKKEERBjhZhx9x7iMHB1JXVxbUI= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3103A0EBB for ; Thu, 7 May 2020 20:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LiizY0leqrBD for ; Thu, 7 May 2020 20:27:39 -0700 (PDT) Received: from raoul.w3.org (raoul.w3.org [128.30.52.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 990CA3A0EB8 for ; Thu, 7 May 2020 20:27:39 -0700 (PDT) Received: from [112.102.246.208] (helo=[192.168.0.101]) by raoul.w3.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jWtfl-0008MS-M3 for new-work@ietf.org; Fri, 08 May 2020 03:27:38 +0000 To: new-work@ietf.org From: xueyuan Message-ID: <97caa538-cb71-7799-df81-6d34bf79e282@w3.org> Date: Fri, 8 May 2020 11:27:30 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 Content-Language: en-US Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Precedence: list Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Thu, 07 May 2020 20:45:27 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Devices and Sensors Working Group (until 2020-06-19) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 03:27:48 -0000 SGVsbG8sCgpUb2RheSBXM0MgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0aXZlcyByZWNl aXZlZCBhIFByb3Bvc2FsCnRvIHJldmlldyBhIGRyYWZ0IGNoYXJ0ZXIgZm9yIHRoZSBEZXZpY2Vz IGFuZCBTZW5zb3JzIFdvcmtpbmcgR3JvdXA6CiDCoCBodHRwczovL3d3dy53My5vcmcvMjAyMC8w NS9wcm9wb3NlZC1kYXMtd2ctY2hhcnRlci5odG1sCgpBcyBwYXJ0IG9mIGVuc3VyaW5nIHRoYXQg dGhlIGNvbW11bml0eSBpcyBhd2FyZSBvZiBwcm9wb3NlZCB3b3JrCmF0IFczQywgdGhpcyBkcmFm dCBjaGFydGVyIGlzIHB1YmxpYyBkdXJpbmcgdGhlIEFkdmlzb3J5CkNvbW1pdHRlZSByZXZpZXcg cGVyaW9kLgoKVzNDIGludml0ZXMgcHVibGljIGNvbW1lbnRzIHRocm91Z2ggMjAyMC0wNi0xOSBv biB0aGUKcHJvcG9zZWQgY2hhcnRlci4gUGxlYXNlIHNlbmQgY29tbWVudHMgdG8KcHVibGljLW5l dy13b3JrQHczLm9yZywgd2hpY2ggaGFzIGEgcHVibGljIGFyY2hpdmU6CiDCoCBodHRwOi8vbGlz dHMudzMub3JnL0FyY2hpdmVzL1B1YmxpYy9wdWJsaWMtbmV3LXdvcmsvCgpPdGhlciB0aGFuIGNv bW1lbnRzIHNlbnQgaW4gZm9ybWFsIHJlc3BvbnNlcyBieSBXM0MgQWR2aXNvcnkKQ29tbWl0dGVl IFJlcHJlc2VudGF0aXZlcywgVzNDIGNhbm5vdCBndWFyYW50ZWUgYSByZXNwb25zZSB0bwpjb21t ZW50cy4gSWYgeW91IHdvcmsgZm9yIGEgVzNDIE1lbWJlciBbMV0sIHBsZWFzZSBjb29yZGluYXRl CnlvdXIgY29tbWVudHMgd2l0aCB5b3VyIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2 ZS4gRm9yCmV4YW1wbGUsIHlvdSBtYXkgd2lzaCB0byBtYWtlIHB1YmxpYyBjb21tZW50cyB2aWEg dGhpcyBsaXN0IGFuZApoYXZlIHlvdXIgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0aXZl IHJlZmVyIHRvIGl0IGZyb20gaGlzCm9yIGhlciBmb3JtYWwgcmV2aWV3IGNvbW1lbnRzLgoKSWYg eW91IHNob3VsZCBoYXZlIGFueSBxdWVzdGlvbnMgb3IgbmVlZCBmdXJ0aGVyIGluZm9ybWF0aW9u LCBwbGVhc2UKY29udGFjdCBGdXFpYW8gWHVlLCBEZXZpY2VzIGFuZCBTZW5zb3JzIFdHIFRlYW0g Q29udGFjdCA8eGZxQHczLm9yZz4uCgpUaGFuayB5b3UsCgpYdWV5dWFuIEppYSwgVzNDIE1hcmtl dGluZyAmIENvbW11bmljYXRpb25zCgpbMV0gaHR0cDovL3d3dy53My5vcmcvQ29uc29ydGl1bS9N ZW1iZXIvTGlzdAoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18KbmV3LXdvcmsgbWFpbGluZyBsaXN0Cm5ldy13b3JrQGlldGYub3JnCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV3LXdvcmsK From nobody Fri May 8 10:08:04 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D23733A0B6E; Fri, 8 May 2020 10:08:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yaron Sheffer via Datatracker To: Cc: opsawg@ietf.org, draft-ietf-opsawg-tacacs-yang.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.129.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158895768179.29360.16730920363751251067@ietfa.amsl.com> Reply-To: Yaron Sheffer Date: Fri, 08 May 2020 10:08:01 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-opsawg-tacacs-yang-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 17:08:02 -0000 Reviewer: Yaron Sheffer Review result: Has Nits This document defines a YANG module for the configuration of TACACS+ clients. The document is short and straightforward, and I only have one significant comment. * I am not familiar with common security practices for the devices covered by this protocol. But I am wondering, should the "shared-secret" field be made optional, so that it can be entered "out of band" in applications that prefer not to keep it stored in the YANG configuration store and available to network management tools? * Not a security comment: the YANG module includes a reference to draft-ietf-opsawg-tacacs-18, but I assume that you'll want to replace it with the RFC number for that draft once it is published. Yet I don't see an RFC Editor note mentioning that. * It is confusing that "messages-received" is for messages received by the server, and "errors-received" is for errors received *from* the server. From nobody Fri May 8 13:38:29 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FBD83A0CFB for ; Fri, 8 May 2020 13:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QMA1fYZEin1c for ; Fri, 8 May 2020 13:38:25 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2819D3A0CE5 for ; Fri, 8 May 2020 13:38:23 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 048Kb4cx020073 for ; Fri, 8 May 2020 21:38:23 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=Iz95Zsqwfe6kjQb6eXWjvR6v76y2NdBUuqSXa5ZpMic=; b=AbpK3UNXb2ZLiT1cGgJuDvGAKzHhUj1MAQ9T5HagKA1q5/MMo1DmdsffsyYXq8DZlUHo AAuAPxSNdzqCK+OjUv+DGuh3bxhPS7vj0qu0W5dotOjscgdYSjUKj6IJeRpgmvQOIbEf /JivcQ4qyOAWhy+iL+dWYXSYTMBTbi1GWBLsbfqTtugb2Prs5YrlS7zleQjBUsKj+hZS s3pEFB5mWS+SPZnXp/NjUWZR+IEt7SzGdCZpTqXL1v1hziNfGF17abXS7qrt3jLcwR4y wOwctwz5A43PMldgSljLn7FO73Fjbt5qApCWRViBobUeV69a0TiVCw63+vE5vLaNBdnj AQ== Received: from prod-mail-ppoint7 (a72-247-45-33.deploy.static.akamaitechnologies.com [72.247.45.33] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 30vteqm3r0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 08 May 2020 21:38:23 +0100 Received: from pps.filterd (prod-mail-ppoint7.akamai.com [127.0.0.1]) by prod-mail-ppoint7.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 048KX1jZ021381 for ; Fri, 8 May 2020 16:38:22 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.115]) by prod-mail-ppoint7.akamai.com with ESMTP id 30wd95gktf-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Fri, 08 May 2020 16:38:22 -0400 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.165.121) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.165.121) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 8 May 2020 15:38:22 -0500 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([172.27.165.121]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([172.27.165.121]) with mapi id 15.00.1497.006; Fri, 8 May 2020 15:38:21 -0500 From: "Salz, Rich" To: "secdir@ietf.org" Thread-Topic: AD's acknowledging reviews Thread-Index: AQHWJXicVP7xbz9oNUC5WxAsTkdbEA== Date: Fri, 8 May 2020 20:38:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.37.20050303 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.128] Content-Type: multipart/alternative; boundary="_000_F9C3BBE9D04A482E966F050C2F0A6A97akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.676 definitions=2020-05-08_18:2020-05-08, 2020-05-08 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=674 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2002250000 definitions=main-2005080174 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.676 definitions=2020-05-08_18:2020-05-08, 2020-05-08 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1011 bulkscore=0 mlxlogscore=635 suspectscore=0 phishscore=0 adultscore=0 impostorscore=0 malwarescore=0 mlxscore=0 spamscore=0 priorityscore=1501 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2005080174 Archived-At: Subject: [secdir] AD's acknowledging reviews X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 20:38:27 -0000 --_000_F9C3BBE9D04A482E966F050C2F0A6A97akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBoYXZlIGFza2VkIGFib3V0IHRoaXMgdHdpY2UgYmVmb3JlLCBhbmQgaGF2ZSBuZXZlciByZWNl aXZlZCBhbiBBRCByZXNwb25zZS4gUGVyaGFwcyB0aGlyZCB0aW1l4oCZcyB0aGUgY2hhcm0uDQoN CkFmdGVyIGEgc2VjZGlyIHJldmlldyBpcyBkb25lLCBhbmQgYWZ0ZXIgYW55IGNvbW1lbnQgdGhy ZWFkcyBoYXZlIGRpZWQgZG93biwgaXQgd291bGQgYmUgcG9saXRlIGZvciB0aGUgcmVzcG9uc2li bGUgQUQgdG8gYWNrbm93bGVkZ2UgdGhlIHJldmlldyBhbmQgaW5kaWNhdGUgd2hhdCB0aGV5IGFy ZSBwbGFubmluZyBvbiBkb2luZy4gQWxpc3NhIGRvZXMgdGhpcyBmb3IgZ2VuLWFydCBkaXJlY3Rv cmF0ZSByZXZpZXdzLCBzZWUgaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9s YXN0LWNhbGwvQUtwLWItUzRCX0lUdjhFS2dfVWdEMXdCaDNrLyBmb3IgYW4gZXhhbXBsZS4NCg0K --_000_F9C3BBE9D04A482E966F050C2F0A6A97akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <8B404A1E8D7F3A43AAB731D110293FA3@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEyLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0i Izk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkkgaGF2ZSBhc2tlZCBhYm91dCB0aGlz IHR3aWNlIGJlZm9yZSwgYW5kIGhhdmUgbmV2ZXIgcmVjZWl2ZWQgYW4gQUQgcmVzcG9uc2UuIFBl cmhhcHMgdGhpcmQgdGltZeKAmXMgdGhlIGNoYXJtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+QWZ0ZXIgYSBzZWNkaXIgcmV2aWV3IGlzIGRvbmUsIGFuZCBhZnRl ciBhbnkgY29tbWVudCB0aHJlYWRzIGhhdmUgZGllZCBkb3duLCBpdCB3b3VsZCBiZSBwb2xpdGUg Zm9yIHRoZSByZXNwb25zaWJsZSBBRCB0byBhY2tub3dsZWRnZSB0aGUgcmV2aWV3IGFuZCBpbmRp Y2F0ZSB3aGF0IHRoZXkgYXJlIHBsYW5uaW5nIG9uIGRvaW5nLiBBbGlzc2EgZG9lcyB0aGlzDQog Zm9yIGdlbi1hcnQgZGlyZWN0b3JhdGUgcmV2aWV3cywgc2VlIDxhIGhyZWY9Imh0dHBzOi8vbWFp bGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvbGFzdC1jYWxsL0FLcC1iLVM0Ql9JVHY4RUtnX1Vn RDF3Qmgzay8iPg0KaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9sYXN0LWNh bGwvQUtwLWItUzRCX0lUdjhFS2dfVWdEMXdCaDNrLzwvYT4gZm9yIGFuIGV4YW1wbGUuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_F9C3BBE9D04A482E966F050C2F0A6A97akamaicom_-- From nobody Fri May 8 13:55:13 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4823A0EE7 for ; Fri, 8 May 2020 13:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1RqGsYPhlYMj for ; Fri, 8 May 2020 13:55:08 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD6463A0EE8 for ; Fri, 8 May 2020 13:55:08 -0700 (PDT) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 048KswKD001487; Fri, 8 May 2020 16:54:58 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu 048KswKD001487 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1588971298; bh=nfadeI0Fe5f7hIRRUrVBqJssXc1x/u04DbLhy5o4mtM=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=Ol5vzdK9ap5iuJq224Gl//puX8NhErFB8vpASjuFAQTV8PZYtMRELiAWZhpzM+Lao xEozC5xe1qQYL9t6v5iJRj+hjiDNGLYd22oeXqE3YrZ6XG3kC3OhYHIjeCgAaGiise y3M2iGasp5SOsvvSlrDT0Fkqev05T2Ps14q/+cMI= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 048KsrSY025645; Fri, 8 May 2020 16:54:53 -0400 Received: from MURIEL.ad.sei.cmu.edu (147.72.252.47) by CASCADE.ad.sei.cmu.edu (10.64.28.248) with Microsoft SMTP Server (TLS) id 14.3.487.0; Fri, 8 May 2020 16:54:53 -0400 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MURIEL.ad.sei.cmu.edu (147.72.252.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1847.3; Fri, 8 May 2020 16:54:52 -0400 Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%22]) with mapi id 15.01.1847.007; Fri, 8 May 2020 16:54:52 -0400 From: Roman Danyliw To: "Salz, Rich" CC: "secdir@ietf.org" Thread-Topic: AD's acknowledging reviews Thread-Index: AQHWJXicVP7xbz9oNUC5WxAsTkdbEKiep9tg Date: Fri, 8 May 2020 20:54:52 +0000 Message-ID: <540d995e78114929a3e3fac6902f6fd9@cert.org> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.202.196] Content-Type: multipart/alternative; boundary="_000_540d995e78114929a3e3fac6902f6fd9certorg_" MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] AD's acknowledging reviews X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 20:55:12 -0000 --_000_540d995e78114929a3e3fac6902f6fd9certorg_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUmljaCENCg0KQmVuIGFuZCBJIGRlZmluaXRlbHkgYXBwcmVjaWF0ZSB0aGUgcmV2aWV3cy4g IEnigJl2ZSBiZWVuIChpbmNvbnNpc3RlbnRseSkgcHV0dGluZyBhY2tub3dsZWRnZW1lbnRzIGlu dG8gbXkgYmFsbG90IHRleHQgYnV0IEFsaXNzYeKAmXMgYXBwcm9hY2ggaXMgdGhlIGJldHRlciBt b2RlbC4gIEkgd2lsbCB1cGRhdGUgbXkgdGVsZWNoYXQgcmV2aWV3IHdvcmtmbG93IGJ5IHNlbmRp bmcgYW4gYWNrbm93bGVkZ2VtZW50ICsgYmFsbG90IHN1bW1hcnkgdmlhIGEgdG9wLXBvc3QgdG8g dGhlIHNlY2RpciByZXZpZXcgdGhyZWFkLg0KDQpBZ2FpbiwgdGhlIHJldmlld3MgYXJlIFJFQUxM WSBhcHByZWNpYXRlZCENCg0KUm9tYW4NCg0KRnJvbTogc2VjZGlyIDxzZWNkaXItYm91bmNlc0Bp ZXRmLm9yZz4gT24gQmVoYWxmIE9mIFNhbHosIFJpY2gNClNlbnQ6IEZyaWRheSwgTWF5IDgsIDIw MjAgNDozOCBQTQ0KVG86IHNlY2RpckBpZXRmLm9yZw0KU3ViamVjdDogW3NlY2Rpcl0gQUQncyBh Y2tub3dsZWRnaW5nIHJldmlld3MNCg0KSSBoYXZlIGFza2VkIGFib3V0IHRoaXMgdHdpY2UgYmVm b3JlLCBhbmQgaGF2ZSBuZXZlciByZWNlaXZlZCBhbiBBRCByZXNwb25zZS4gUGVyaGFwcyB0aGly ZCB0aW1l4oCZcyB0aGUgY2hhcm0uDQoNCkFmdGVyIGEgc2VjZGlyIHJldmlldyBpcyBkb25lLCBh bmQgYWZ0ZXIgYW55IGNvbW1lbnQgdGhyZWFkcyBoYXZlIGRpZWQgZG93biwgaXQgd291bGQgYmUg cG9saXRlIGZvciB0aGUgcmVzcG9uc2libGUgQUQgdG8gYWNrbm93bGVkZ2UgdGhlIHJldmlldyBh bmQgaW5kaWNhdGUgd2hhdCB0aGV5IGFyZSBwbGFubmluZyBvbiBkb2luZy4gQWxpc3NhIGRvZXMg dGhpcyBmb3IgZ2VuLWFydCBkaXJlY3RvcmF0ZSByZXZpZXdzLCBzZWUgaHR0cHM6Ly9tYWlsYXJj aGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9sYXN0LWNhbGwvQUtwLWItUzRCX0lUdjhFS2dfVWdEMXdC aDNrLyBmb3IgYW4gZXhhbXBsZS4NCg0K --_000_540d995e78114929a3e3fac6902f6fd9certorg_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5t c29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+SGkgUmljaCE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPkJlbiBhbmQgSSBkZWZpbml0ZWx5IGFwcHJlY2lhdGUgdGhlIHJldmlld3MuJm5ic3A7 IEnigJl2ZSBiZWVuIChpbmNvbnNpc3RlbnRseSkgcHV0dGluZyBhY2tub3dsZWRnZW1lbnRzIGlu dG8gbXkgYmFsbG90IHRleHQgYnV0IEFsaXNzYeKAmXMgYXBwcm9hY2ggaXMgdGhlIGJldHRlciBt b2RlbC4mbmJzcDsgSSB3aWxsIHVwZGF0ZSBteSB0ZWxlY2hhdCByZXZpZXcgd29ya2Zsb3cgYnkN CiBzZW5kaW5nIGFuIGFja25vd2xlZGdlbWVudCAmIzQzOyBiYWxsb3Qgc3VtbWFyeSB2aWEgYSB0 b3AtcG9zdCB0byB0aGUgc2VjZGlyIHJldmlldyB0aHJlYWQuJm5ic3A7DQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkFnYWluLCB0aGUgcmV2aWV3cyBhcmUgUkVB TExZIGFwcHJlY2lhdGVkITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+Um9tYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4gc2VjZGlyICZs dDtzZWNkaXItYm91bmNlc0BpZXRmLm9yZyZndDsNCjxiPk9uIEJlaGFsZiBPZiA8L2I+U2Fseiwg UmljaDxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIE1heSA4LCAyMDIwIDQ6MzggUE08YnI+DQo8 Yj5Ubzo8L2I+IHNlY2RpckBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbc2VjZGlyXSBB RCdzIGFja25vd2xlZGdpbmcgcmV2aWV3czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JIGhhdmUgYXNr ZWQgYWJvdXQgdGhpcyB0d2ljZSBiZWZvcmUsIGFuZCBoYXZlIG5ldmVyIHJlY2VpdmVkIGFuIEFE IHJlc3BvbnNlLiBQZXJoYXBzIHRoaXJkIHRpbWXigJlzIHRoZSBjaGFybS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkFmdGVyIGEgc2VjZGlyIHJldmlldyBpcyBk b25lLCBhbmQgYWZ0ZXIgYW55IGNvbW1lbnQgdGhyZWFkcyBoYXZlIGRpZWQgZG93biwgaXQgd291 bGQgYmUgcG9saXRlIGZvciB0aGUgcmVzcG9uc2libGUgQUQgdG8gYWNrbm93bGVkZ2UgdGhlIHJl dmlldyBhbmQgaW5kaWNhdGUgd2hhdCB0aGV5IGFyZSBwbGFubmluZyBvbiBkb2luZy4gQWxpc3Nh IGRvZXMgdGhpcw0KIGZvciBnZW4tYXJ0IGRpcmVjdG9yYXRlIHJldmlld3MsIHNlZSA8YSBocmVm PSJodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2xhc3QtY2FsbC9BS3AtYi1T NEJfSVR2OEVLZ19VZ0Qxd0JoM2svIj4NCmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJj aC9tc2cvbGFzdC1jYWxsL0FLcC1iLVM0Ql9JVHY4RUtnX1VnRDF3Qmgzay88L2E+IGZvciBhbiBl eGFtcGxlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_540d995e78114929a3e3fac6902f6fd9certorg_-- From nobody Fri May 8 13:56:43 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9003A0EE6 for ; Fri, 8 May 2020 13:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVCzIWri7hpE for ; Fri, 8 May 2020 13:56:40 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D47843A0EE8 for ; Fri, 8 May 2020 13:56:39 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 048KuYeo006010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 8 May 2020 16:56:36 -0400 Date: Fri, 8 May 2020 13:56:33 -0700 From: Benjamin Kaduk To: "Salz, Rich" Cc: "secdir@ietf.org" Message-ID: <20200508205633.GS27494@kduck.mit.edu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [secdir] AD's acknowledging reviews X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 20:56:41 -0000 Hi Rich, Sorry to have left you hanging -- I thought I had replied to one of the previous incarnations of the question. Yes, this is a good thing to do, and I do it sometimes. Arguably not as often as I should, but if I am crunched for time it does not always feel like a strict necessity and can get overlooked. Thanks for bringing it up, Ben On Fri, May 08, 2020 at 08:38:21PM +0000, Salz, Rich wrote: > I have asked about this twice before, and have never received an AD response. Perhaps third time’s the charm. > > After a secdir review is done, and after any comment threads have died down, it would be polite for the responsible AD to acknowledge the review and indicate what they are planning on doing. Alissa does this for gen-art directorate reviews, see https://mailarchive.ietf.org/arch/msg/last-call/AKp-b-S4B_ITv8EKg_UgD1wBh3k/ for an example. > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From nobody Fri May 8 13:58:29 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D0AB3A0EE7 for ; Fri, 8 May 2020 13:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJuNp87Cfa25 for ; Fri, 8 May 2020 13:58:26 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6A7A3A0EE6 for ; Fri, 8 May 2020 13:58:24 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 048KuRhj013437; Fri, 8 May 2020 21:58:22 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=IihkLaGPEcUKapbsQoJXzAkZ+0PKkt7lnnLNYz1rdoU=; b=ePYVjQQeni+gJUi94Q/zLt/KD38vZ5IV0bj3MLDrbspAAHd+stC5xT2f9TvauYEggWXC J4hsLbgBB95xspZCelpMirXKC2ZZ8ZZWbkYYlebbkoV6ReoiwkwMHULYjm8OG+1ksbwf Pu+fScHtADWk9raYmM4SCm8yPaZ8tNBtl0IrHrEhMa1tfasbozHI9jKjJDvCEJvLe26n me6BKhFIgXFjfSiFhyi7z5NYkUE5KfLhyLhnWJWPSiIORQXA40RQNPUDZcenl7FdjFI7 IG7sA/olfKxiELVwml+Suo1GImQzwdngZTk1bP8wOxgbXUSEUURicYSu5hnKrD8XwbiL uA== Received: from prod-mail-ppoint7 (a72-247-45-33.deploy.static.akamaitechnologies.com [72.247.45.33] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 30vtef4k9m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 08 May 2020 21:58:22 +0100 Received: from pps.filterd (prod-mail-ppoint7.akamai.com [127.0.0.1]) by prod-mail-ppoint7.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 048KlaOF007965; Fri, 8 May 2020 16:58:21 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.113]) by prod-mail-ppoint7.akamai.com with ESMTP id 30wd95gra7-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 08 May 2020 16:58:21 -0400 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.165.121) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.165.123) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 8 May 2020 15:58:22 -0500 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([172.27.165.121]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([172.27.165.121]) with mapi id 15.00.1497.006; Fri, 8 May 2020 15:58:21 -0500 From: "Salz, Rich" To: Roman Danyliw CC: "secdir@ietf.org" Thread-Topic: AD's acknowledging reviews Thread-Index: AQHWJXicVP7xbz9oNUC5WxAsTkdbEKiep9tggAAUxgA= Date: Fri, 8 May 2020 20:58:20 +0000 Message-ID: <2176D198-7381-4C8A-B0A4-A3DA357303F6@akamai.com> References: <540d995e78114929a3e3fac6902f6fd9@cert.org> In-Reply-To: <540d995e78114929a3e3fac6902f6fd9@cert.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.37.20050303 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.128] Content-Type: multipart/alternative; boundary="_000_2176D19873814C8AB0A4A3DA357303F6akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.676 definitions=2020-05-08_18:2020-05-08, 2020-05-08 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2002250000 definitions=main-2005080176 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.676 definitions=2020-05-08_18:2020-05-08, 2020-05-08 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 mlxscore=0 malwarescore=0 priorityscore=1501 lowpriorityscore=0 bulkscore=0 spamscore=0 suspectscore=0 mlxlogscore=999 phishscore=0 clxscore=1011 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2005080177 Archived-At: Subject: Re: [secdir] AD's acknowledging reviews X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 20:58:28 -0000 --_000_2176D19873814C8AB0A4A3DA357303F6akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmsgeW91Lg0KDQpGcm9tOiBSb21hbiBEYW55bGl3IDxyZGRAY2VydC5vcmc+DQpEYXRlOiBG cmlkYXksIE1heSA4LCAyMDIwIGF0IDQ6NTUgUE0NClRvOiBSaWNoIFNhbHogPHJzYWx6QGFrYW1h aS5jb20+DQpDYzogInNlY2RpckBpZXRmLm9yZyIgPHNlY2RpckBpZXRmLm9yZz4NClN1YmplY3Q6 IFJFOiBBRCdzIGFja25vd2xlZGdpbmcgcmV2aWV3cw0KDQpIaSBSaWNoIQ0KDQpCZW4gYW5kIEkg ZGVmaW5pdGVseSBhcHByZWNpYXRlIHRoZSByZXZpZXdzLiAgSeKAmXZlIGJlZW4gKGluY29uc2lz dGVudGx5KSBwdXR0aW5nIGFja25vd2xlZGdlbWVudHMgaW50byBteSBiYWxsb3QgdGV4dCBidXQg QWxpc3Nh4oCZcyBhcHByb2FjaCBpcyB0aGUgYmV0dGVyIG1vZGVsLiAgSSB3aWxsIHVwZGF0ZSBt eSB0ZWxlY2hhdCByZXZpZXcgd29ya2Zsb3cgYnkgc2VuZGluZyBhbiBhY2tub3dsZWRnZW1lbnQg KyBiYWxsb3Qgc3VtbWFyeSB2aWEgYSB0b3AtcG9zdCB0byB0aGUgc2VjZGlyIHJldmlldyB0aHJl YWQuDQoNCkFnYWluLCB0aGUgcmV2aWV3cyBhcmUgUkVBTExZIGFwcHJlY2lhdGVkIQ0KDQpSb21h bg0KDQpGcm9tOiBzZWNkaXIgPHNlY2Rpci1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2Yg U2FseiwgUmljaA0KU2VudDogRnJpZGF5LCBNYXkgOCwgMjAyMCA0OjM4IFBNDQpUbzogc2VjZGly QGlldGYub3JnDQpTdWJqZWN0OiBbc2VjZGlyXSBBRCdzIGFja25vd2xlZGdpbmcgcmV2aWV3cw0K DQpJIGhhdmUgYXNrZWQgYWJvdXQgdGhpcyB0d2ljZSBiZWZvcmUsIGFuZCBoYXZlIG5ldmVyIHJl Y2VpdmVkIGFuIEFEIHJlc3BvbnNlLiBQZXJoYXBzIHRoaXJkIHRpbWXigJlzIHRoZSBjaGFybS4N Cg0KQWZ0ZXIgYSBzZWNkaXIgcmV2aWV3IGlzIGRvbmUsIGFuZCBhZnRlciBhbnkgY29tbWVudCB0 aHJlYWRzIGhhdmUgZGllZCBkb3duLCBpdCB3b3VsZCBiZSBwb2xpdGUgZm9yIHRoZSByZXNwb25z aWJsZSBBRCB0byBhY2tub3dsZWRnZSB0aGUgcmV2aWV3IGFuZCBpbmRpY2F0ZSB3aGF0IHRoZXkg YXJlIHBsYW5uaW5nIG9uIGRvaW5nLiBBbGlzc2EgZG9lcyB0aGlzIGZvciBnZW4tYXJ0IGRpcmVj dG9yYXRlIHJldmlld3MsIHNlZSBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNn L2xhc3QtY2FsbC9BS3AtYi1TNEJfSVR2OEVLZ19VZ0Qxd0JoM2svPGh0dHBzOi8vdXJsZGVmZW5z ZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fbWFpbGFyY2hpdmUuaWV0Zi5vcmdf YXJjaF9tc2dfbGFzdC0yRGNhbGxfQUtwLTJEYi0yRFM0Qi01RklUdjhFS2ctNUZVZ0Qxd0JoM2tf JmQ9RHdNR2FRJmM9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZyPTRMTTBHYlIwaDlGdng4NkZ0c0tJ LXcmbT1xWUhuY1k3cnp0WDlkYjJxVDIzbnFfakdyUHZTV3I5TlZ0SjlsZ0dSUkdNJnM9blprMFRZ Mkk1RUtxcENsam5WUmJxcE5PU0g4bUFGMU9QTnp1S1ZtQVcwVSZlPT4gZm9yIGFuIGV4YW1wbGUu DQoNCg== --_000_2176D19873814C8AB0A4A3DA357303F6akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <80E77BF457608A49A1E511344A406AF5@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGlu az0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGFu ayB5b3UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPlJvbWFuIERhbnlsaXcgJmx0O3JkZEBjZXJ0Lm9yZyZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+ RnJpZGF5LCBNYXkgOCwgMjAyMCBhdCA0OjU1IFBNPGJyPg0KPGI+VG86IDwvYj5SaWNoIFNhbHog Jmx0O3JzYWx6QGFrYW1haS5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDtzZWNkaXJAaWV0 Zi5vcmcmcXVvdDsgJmx0O3NlY2RpckBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+ UkU6IEFEJ3MgYWNrbm93bGVkZ2luZyByZXZpZXdzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkhpIFJpY2ghPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5CZW4gYW5kIEkgZGVmaW5pdGVseSBh cHByZWNpYXRlIHRoZSByZXZpZXdzLiZuYnNwOyBJ4oCZdmUgYmVlbiAoaW5jb25zaXN0ZW50bHkp IHB1dHRpbmcgYWNrbm93bGVkZ2VtZW50cyBpbnRvIG15IGJhbGxvdCB0ZXh0IGJ1dCBBbGlzc2Hi gJlzIGFwcHJvYWNoIGlzIHRoZSBiZXR0ZXIgbW9kZWwuJm5ic3A7IEkgd2lsbCB1cGRhdGUgbXkg dGVsZWNoYXQgcmV2aWV3IHdvcmtmbG93IGJ5DQogc2VuZGluZyBhbiBhY2tub3dsZWRnZW1lbnQg JiM0MzsgYmFsbG90IHN1bW1hcnkgdmlhIGEgdG9wLXBvc3QgdG8gdGhlIHNlY2RpciByZXZpZXcg dGhyZWFkLiZuYnNwOw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij5BZ2FpbiwgdGhlIHJldmlld3MgYXJlIFJFQUxMWSBhcHByZWNpYXRlZCE8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlJvbWFuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+IHNlY2RpciAmbHQ7c2VjZGlyLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7 DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlNhbHosIFJpY2g8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5 LCBNYXkgOCwgMjAyMCA0OjM4IFBNPGJyPg0KPGI+VG86PC9iPiBzZWNkaXJAaWV0Zi5vcmc8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gW3NlY2Rpcl0gQUQncyBhY2tub3dsZWRnaW5nIHJldmlld3M8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+SSBoYXZlIGFza2VkIGFib3V0IHRoaXMgdHdpY2UgYmVmb3JlLCBh bmQgaGF2ZSBuZXZlciByZWNlaXZlZCBhbiBBRCByZXNwb25zZS4gUGVyaGFwcyB0aGlyZCB0aW1l 4oCZcyB0aGUgY2hhcm0uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij5BZnRlciBhIHNlY2RpciByZXZpZXcgaXMgZG9uZSwgYW5kIGFmdGVyIGFueSBjb21tZW50IHRo cmVhZHMgaGF2ZSBkaWVkIGRvd24sIGl0IHdvdWxkIGJlIHBvbGl0ZSBmb3IgdGhlIHJlc3BvbnNp YmxlIEFEIHRvIGFja25vd2xlZGdlIHRoZSByZXZpZXcgYW5kIGluZGljYXRlIHdoYXQgdGhleSBh cmUgcGxhbm5pbmcgb24gZG9pbmcuIEFsaXNzYSBkb2VzIHRoaXMNCiBmb3IgZ2VuLWFydCBkaXJl Y3RvcmF0ZSByZXZpZXdzLCBzZWUgPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p bnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19tYWlsYXJjaGl2ZS5pZXRmLm9yZ19hcmNoX21zZ19s YXN0LTJEY2FsbF9BS3AtMkRiLTJEUzRCLTVGSVR2OEVLZy01RlVnRDF3Qmgza18mYW1wO2Q9RHdN R2FRJmFtcDtjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmYW1wO3I9NExNMEdiUjBoOUZ2eDg2RnRz S0ktdyZhbXA7bT1xWUhuY1k3cnp0WDlkYjJxVDIzbnFfakdyUHZTV3I5TlZ0SjlsZ0dSUkdNJmFt cDtzPW5aazBUWTJJNUVLcXBDbGpuVlJicXBOT1NIOG1BRjFPUE56dUtWbUFXMFUmYW1wO2U9Ij4N Cmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvbGFzdC1jYWxsL0FLcC1iLVM0 Ql9JVHY4RUtnX1VnRDF3Qmgzay88L2E+IGZvciBhbiBleGFtcGxlLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_2176D19873814C8AB0A4A3DA357303F6akamaicom_-- From nobody Fri May 8 16:01:43 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E992A3A0F48 for ; Fri, 8 May 2020 16:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QYLBn5sq-sqz for ; Fri, 8 May 2020 16:01:38 -0700 (PDT) Received: from Mail.Yoyodyne.COM (mail.yoyodyne.com [IPv6:2604:4ec0:0:2::d]) by ietfa.amsl.com (Postfix) with SMTP id 8DDB93A0E2C for ; Fri, 8 May 2020 16:01:38 -0700 (PDT) Received: from [IPv6:2603:3024:1767:6000:84fc:5990:cbd4:b803] ([2603:3024:1767:6000:84fc:5990:cbd4:b803]) by Mail.Yoyodyne.COM via Internet for (and others); Fri, 8 May 2020 16:01:37 PDT From: Derrell Piper Message-Id: <87BD6B82-8CDD-4392-B928-C3A9AFD36B87@electric-loft.org> Content-Type: multipart/signed; boundary="Apple-Mail=_8235A314-EC39-478D-9B3C-5316A3C53FEB"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Fri, 8 May 2020 16:01:35 -0700 In-Reply-To: Cc: "secdir@ietf.org" To: "Salz, Rich" References: X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [secdir] AD's acknowledging reviews X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 23:01:41 -0000 --Apple-Mail=_8235A314-EC39-478D-9B3C-5316A3C53FEB Content-Type: multipart/alternative; boundary="Apple-Mail=_77582EE9-466F-4C93-B482-6CFB7F02F2A2" --Apple-Mail=_77582EE9-466F-4C93-B482-6CFB7F02F2A2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 8, 2020, at 1:38 PM, Salz, Rich = wrote: >=20 > I have asked about this twice before, and have never received an AD = response. Perhaps third time=E2=80=99s the charm. > =20 > After a secdir review is done, and after any comment threads have died = down, it would be polite for the responsible AD to acknowledge the = review and indicate what they are planning on doing. Alissa does this = for gen-art directorate reviews, see = https://mailarchive.ietf.org/arch/msg/last-call/AKp-b-S4B_ITv8EKg_UgD1wBh3= k/ = for an example. For threads that have a lot of comments, I wouldn=E2=80=99t want to see = the AD have to ack all reviews. Derrell= --Apple-Mail=_77582EE9-466F-4C93-B482-6CFB7F02F2A2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On May 8, 2020, at 1:38 PM, Salz, Rich <rsalz=3D40akamai.com@dmarc.ietf.org> wrote:

I have asked about this twice = before, and have never received an AD response. Perhaps third time=E2=80=99= s the charm.
 
After a secdir = review is done, and after any comment threads have died down, it would = be polite for the responsible AD to acknowledge the review and indicate = what they are planning on doing. Alissa does this for gen-art = directorate reviews, see https://mailarchive.ietf.org/arch/msg/last-call/AKp-b-S4B_ITv8E= Kg_UgD1wBh3k/ for = an example.

For threads that have a lot of comments, I = wouldn=E2=80=99t want to see the AD have to ack all = reviews.

Derrell
= --Apple-Mail=_77582EE9-466F-4C93-B482-6CFB7F02F2A2-- --Apple-Mail=_8235A314-EC39-478D-9B3C-5316A3C53FEB Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCqUw ggUuMIIEFqADAgECAhBuYWaYcrycMAAAAABR05MeMA0GCSqGSIb3DQEBCwUAMIG+MQswCQYDVQQG EwJVUzEWMBQGA1UEChMNRW50cnVzdCwgSW5jLjEoMCYGA1UECxMfU2VlIHd3dy5lbnRydXN0Lm5l dC9sZWdhbC10ZXJtczE5MDcGA1UECxMwKGMpIDIwMDkgRW50cnVzdCwgSW5jLiAtIGZvciBhdXRo b3JpemVkIHVzZSBvbmx5MTIwMAYDVQQDEylFbnRydXN0IFJvb3QgQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkgLSBHMjAeFw0xOTA0MTYxNTM1NTJaFw0zMDExMTYxNjA1NTJaMIG3MQswCQYDVQQGEwJV UzEWMBQGA1UEChMNRW50cnVzdCwgSW5jLjEoMCYGA1UECxMfU2VlIHd3dy5lbnRydXN0Lm5ldC9s ZWdhbC10ZXJtczE5MDcGA1UECxMwKGMpIDIwMTUgRW50cnVzdCwgSW5jLiAtIGZvciBhdXRob3Jp emVkIHVzZSBvbmx5MSswKQYDVQQDEyJFbnRydXN0IENsYXNzIDEgQ2xpZW50IENBIC0gU0hBMjU2 MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2DmtXj1lwZOXaWXvERtOSP7QMI+Ts82R Qc2etqDeYwctILXqkwsQrZB6YjKa1BQnBmLHxn3cWxKJtqCT7ZP95YVxc0MXjP5ifP9xD/f59jlY d/7SPIxQUjX1+vsV6aY4tTzPiaOu3VHVGbD70si3WdUvJh367CMOU2o0mXi9MwW1fBwMHK99NKgp wpr4QhyT2aZ+os/hGGQLUYmse5Dfshq79eelXyFC1FIrvM0AhAk+T3NKFPmckKwyk30jkFMElSne TR7ganOTMeT1OEqVomyJsMzJugVaMzuSt4vhJFSt/XXRMPcPT9PEx39X78NNkWeTTkL1Ghq9O2We AStQNwIDAQABo4IBKzCCAScwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDsGA1UdIAQ0MDIwMAYEVR0gADAoMCYGCCsGAQUF BwIBFhpodHRwOi8vd3d3LmVudHJ1c3QubmV0L3JwYTAzBggrBgEFBQcBAQQnMCUwIwYIKwYBBQUH MAGGF2h0dHA6Ly9vY3NwLmVudHJ1c3QubmV0MDAGA1UdHwQpMCcwJaAjoCGGH2h0dHA6Ly9jcmwu ZW50cnVzdC5uZXQvZzJjYS5jcmwwHQYDVR0OBBYEFOJJuewl3rcM3uVQGFtIzAyOFfKmMB8GA1Ud IwQYMBaAFGpyJnrQHu995ztpUdRsjZ+QEmarMA0GCSqGSIb3DQEBCwUAA4IBAQBVuaCwN5r85cQp hcyUe+RXqaYyUmVEqTWG/a98UJdX44vkCgzdD/+Cn4o6wbRun7Ak0kdCR3qfFA17/5QOQ8DLOyR5 X37Ytxby24lTLKKehNlc3japM8XQQFaJqLMq3MXXFYhWlFk4UHwXYLcDR7XyA3hYuaL6HU92h+uG SDEcBeV+nXrk4FRgEfGvilHfd+8ozBjSVKOF6L1+fuJNkaFWYvJ4Qi64nlmXDsk6K9f6P4FT8hXA 2Cn6tQGAqCz8t6bn7ljtaxCMJ10LE+omiZDfWXv4PrkvgWnNqZEzQw+E09HwEc7DjV9/fGqUhLR2 AKkjYE/78rlymYPvOf7bmpSYMIIFbzCCBFegAwIBAgIRAI534qzDm7xdAAAAAFVjsOwwDQYJKoZI hvcNAQELBQAwgbcxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1FbnRydXN0LCBJbmMuMSgwJgYDVQQL Ex9TZWUgd3d3LmVudHJ1c3QubmV0L2xlZ2FsLXRlcm1zMTkwNwYDVQQLEzAoYykgMjAxNSBFbnRy dXN0LCBJbmMuIC0gZm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxKzApBgNVBAMTIkVudHJ1c3QgQ2xh c3MgMSBDbGllbnQgQ0EgLSBTSEEyNTYwHhcNMTkwODE1MTgyMDAyWhcNMjAwODE0MTg1MDAwWjCB nzEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQLEy5FbnRydXN0IENsYXNz IDEgSWRlbnRpdHkgQ2VydGlmaWNhdGlvbiBTZXJ2aWNlMR4wHAYDVQQDDBVkZHBAZWxlY3RyaWMt bG9mdC5vcmcxJDAiBgkqhkiG9w0BCQEWFWRkcEBlbGVjdHJpYy1sb2Z0Lm9yZzCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBANBA7jjvZSATUxJEdJNmz6N1fnajqmdDkVHOxA0yllROaJPo MNM03XQFa24aJ7fJ9wQhq9NXHq2w5xO2KK2PBJW8vxw38wuPdE14bHzuxtGKWnDhJ/SIEWtA7pB0 fFMua7OAtgTMvekxx0st8qw6yKufNtdv7Q2U3OWUYCWNdvZudJxHXkqHdCj6WTBE24sGSL/UrGLj H98ebxfANbX8Wfp/Sg34OtbFe305CyXlwNWplILN4UKg+r4EWRKgJ3ZLsxj2WH/tWdn7KU6eK315 F/PjH2NscqzNTSwZbHcwynAYd6239FQiombVk4PGnHRJq1NOi4n5M1lvl8mnrsQLYNkCAwEAAaOC AYowggGGMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQgYD VR0gBDswOTA3BgtghkgBhvpsCgEEATAoMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LmVudHJ1c3Qu bmV0L3JwYTAJBgNVHRMEAjAAMGkGCCsGAQUFBwEBBF0wWzAjBggrBgEFBQcwAYYXaHR0cDovL29j c3AuZW50cnVzdC5uZXQwNAYIKwYBBQUHMAKGKGh0dHA6Ly9haWEuZW50cnVzdC5uZXQvY2xhc3Mx LXNoYTI1Ni5jZXIwOQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5lbnRydXN0Lm5ldC9jbGFz czEtc2hhMjU2LmNybDAgBgNVHREEGTAXgRVkZHBAZWxlY3RyaWMtbG9mdC5vcmcwHwYDVR0jBBgw FoAU4km57CXetwze5VAYW0jMDI4V8qYwHQYDVR0OBBYEFA3/q3e5a+oKODwIaREHDhpaK0YRMA0G CSqGSIb3DQEBCwUAA4IBAQCPmXPwIGtfjvyqW7WFgrG/mBV1KWgorjrzgDYZmZfI466I6zEurSnI 0pLAbkXrhuTfEYkm4lertjRBSkd9W3iRaBUUfOntAdANX8/3onjQI/WEvszc6tPUTfS/CixsR69M mE0/o5UmYzSBcHzF2ff01ceD8IrsPhyzf87xJvfWonFyGB3gt8kN9K5S1eCAj6WdgC1ZrFMXp8fR ezAA2BHiJCbj4T2e3Zg4xDoTH4r4Y9u+czDikS5InJL+Z0iqsNR50d7YgAEAeU3iYQx5GvO7Dqou vM9JajPccnpqDClNXP1sqIOvAE6GHSopTy6mEUB6phLVeWW342rsUvtgUntVMYIEKjCCBCYCAQEw gc0wgbcxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1FbnRydXN0LCBJbmMuMSgwJgYDVQQLEx9TZWUg d3d3LmVudHJ1c3QubmV0L2xlZ2FsLXRlcm1zMTkwNwYDVQQLEzAoYykgMjAxNSBFbnRydXN0LCBJ bmMuIC0gZm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxKzApBgNVBAMTIkVudHJ1c3QgQ2xhc3MgMSBD bGllbnQgQ0EgLSBTSEEyNTYCEQCOd+Ksw5u8XQAAAABVY7DsMA0GCWCGSAFlAwQCAQUAoIICLTAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA1MDgyMzAxMzVaMC8G CSqGSIb3DQEJBDEiBCCWTR+I8Xeo/FuAkvUJW9ELfQaWfRj1B4Sx2xcoF/sazTCB3gYJKwYBBAGC NxAEMYHQMIHNMIG3MQswCQYDVQQGEwJVUzEWMBQGA1UEChMNRW50cnVzdCwgSW5jLjEoMCYGA1UE CxMfU2VlIHd3dy5lbnRydXN0Lm5ldC9sZWdhbC10ZXJtczE5MDcGA1UECxMwKGMpIDIwMTUgRW50 cnVzdCwgSW5jLiAtIGZvciBhdXRob3JpemVkIHVzZSBvbmx5MSswKQYDVQQDEyJFbnRydXN0IENs YXNzIDEgQ2xpZW50IENBIC0gU0hBMjU2AhEAjnfirMObvF0AAAAAVWOw7DCB4AYLKoZIhvcNAQkQ AgsxgdCggc0wgbcxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1FbnRydXN0LCBJbmMuMSgwJgYDVQQL Ex9TZWUgd3d3LmVudHJ1c3QubmV0L2xlZ2FsLXRlcm1zMTkwNwYDVQQLEzAoYykgMjAxNSBFbnRy dXN0LCBJbmMuIC0gZm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxKzApBgNVBAMTIkVudHJ1c3QgQ2xh c3MgMSBDbGllbnQgQ0EgLSBTSEEyNTYCEQCOd+Ksw5u8XQAAAABVY7DsMA0GCSqGSIb3DQEBAQUA BIIBADNr8NagWD8vfvPB7vGBhWlzJ7WPwb3JeX3z0wsmqv9YWg54T0O0ap2x5MsIZwk24IT/7HIV NnyVlgcYxhGNNejs21irtomZfcThY8OQkwTGfMYlCfM+J1suWRk5DWqrdZE8M30UvzeNyW5Y6Wb3 Az5PzNIX4XLqeeOz/WVPR4F8YkX14WcTttQrsiYpH82Tnqfm+vqqkgdTb1DSP4hkJ8wBc90+87RJ 62aWc4mdavntHywCvanNcV29HS5rBSa6H84/pG034a5MNqawWVMhq2thiwZrd6fgkNgS8JuMygGS gLyzA5Mn6S/ChPHrupPo7Pnx4NSzJTHqN4on71+dzNkAAAAAAAA= --Apple-Mail=_8235A314-EC39-478D-9B3C-5316A3C53FEB-- From nobody Fri May 8 16:54:06 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 904473A00E2 for ; Fri, 8 May 2020 16:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXipKRe79-bc for ; Fri, 8 May 2020 16:53:54 -0700 (PDT) Received: from Mail1.Yoyodyne.COM (mail1.yoyodyne.com [IPv6:2604:4ec0:1000::7]) by ietfa.amsl.com (Postfix) with SMTP id 96FA13A00DC for ; Fri, 8 May 2020 16:53:54 -0700 (PDT) Received: from [IPv6:2603:3024:1767:6000:f17b:2f7d:43e6:c1b2] ([2603:3024:1767:6000:f17b:2f7d:43e6:c1b2]) by Mail1.Yoyodyne.COM via Internet for (and others); Fri, 8 May 2020 16:53:27 PDT From: Derrell Piper To: "Salz, Rich" Cc: "secdir@ietf.org" References: <87BD6B82-8CDD-4392-B928-C3A9AFD36B87@electric-loft.org> Message-ID: Date: Fri, 8 May 2020 16:53:48 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <87BD6B82-8CDD-4392-B928-C3A9AFD36B87@electric-loft.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [secdir] AD's acknowledging reviews X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 23:54:00 -0000 I did, I just don't think forcing the AD to generate the ack is useful. If it was anything other than okay or has nits, that might be nice, agreed. Just my 2c. On 5/8/2020 4:01 PM, Derrell Piper wrote: > > >> On May 8, 2020, at 1:38 PM, Salz, Rich >> > > wrote: >> >> I have asked about this twice before, and have never received an AD >> response. Perhaps third time’s the charm. >> After a secdir review is done, and after any comment threads have died >> down, it would be polite for the responsible AD to acknowledge the >> review and indicate what they are planning on doing. Alissa does this >> for gen-art directorate reviews, >> seehttps://mailarchive.ietf.org/arch/msg/last-call/AKp-b-S4B_ITv8EKg_UgD1wBh3k/for >> an example. > > For threads that have a lot of comments, I wouldn’t want to see the AD > have to ack all reviews. > > Derrell > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > From nobody Sun May 10 20:02:29 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B60D83A0437; Sun, 10 May 2020 20:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjvquRjL1Mzq; Sun, 10 May 2020 20:01:28 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 787883A041C; Sun, 10 May 2020 20:01:28 -0700 (PDT) Received: from lhreml713-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id E6B10D5CE06ECD38DF83; Mon, 11 May 2020 04:01:25 +0100 (IST) Received: from dggeme702-chm.china.huawei.com (10.1.199.98) by lhreml713-chm.china.huawei.com (10.201.108.64) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1913.5; Mon, 11 May 2020 04:01:25 +0100 Received: from dggeme752-chm.china.huawei.com (10.3.19.98) by dggeme702-chm.china.huawei.com (10.1.199.98) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Mon, 11 May 2020 11:01:23 +0800 Received: from dggeme752-chm.china.huawei.com ([10.6.80.76]) by dggeme752-chm.china.huawei.com ([10.6.80.76]) with mapi id 15.01.1913.007; Mon, 11 May 2020 11:01:23 +0800 From: "Wubo (lana)" To: Yaron Sheffer , "secdir@ietf.org" CC: "opsawg@ietf.org" , "draft-ietf-opsawg-tacacs-yang.all@ietf.org" , "last-call@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-opsawg-tacacs-yang-03 Thread-Index: AdYlq1cMY6ppYXBtRRaWzpDXQ13f2g== Date: Mon, 11 May 2020 03:01:23 +0000 Message-ID: Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.33.83] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-opsawg-tacacs-yang-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2020 03:01:30 -0000 SGkgWWFyb24sDQoNClRoYW5rcyBmb3IgdGhlIHJldmlldy4gUGxlYXNlIHNlZSBpbmxpbmUuDQoN ClJlZ2FyZHMsDQpCbw0KDQotLS0tLemCruS7tuWOn+S7ti0tLS0tDQrlj5Hku7bkuro6IFlhcm9u IFNoZWZmZXIgdmlhIERhdGF0cmFja2VyIFttYWlsdG86bm9yZXBseUBpZXRmLm9yZ10gDQrlj5Hp gIHml7bpl7Q6IDIwMjDlubQ15pyIOeaXpSAxOjA4DQrmlLbku7bkuro6IHNlY2RpckBpZXRmLm9y Zw0K5oqE6YCBOiBvcHNhd2dAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtb3BzYXdnLXRhY2Fjcy15YW5n LmFsbEBpZXRmLm9yZzsgbGFzdC1jYWxsQGlldGYub3JnDQrkuLvpopg6IFNlY2RpciBsYXN0IGNh bGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtb3BzYXdnLXRhY2Fjcy15YW5nLTAzDQoNClJldmlld2Vy OiBZYXJvbiBTaGVmZmVyDQpSZXZpZXcgcmVzdWx0OiBIYXMgTml0cw0KDQpUaGlzIGRvY3VtZW50 IGRlZmluZXMgYSBZQU5HIG1vZHVsZSBmb3IgdGhlIGNvbmZpZ3VyYXRpb24gb2YgVEFDQUNTKyBj bGllbnRzLg0KDQpUaGUgZG9jdW1lbnQgaXMgc2hvcnQgYW5kIHN0cmFpZ2h0Zm9yd2FyZCwgYW5k IEkgb25seSBoYXZlIG9uZSBzaWduaWZpY2FudCBjb21tZW50Lg0KDQoqIEkgYW0gbm90IGZhbWls aWFyIHdpdGggY29tbW9uIHNlY3VyaXR5IHByYWN0aWNlcyBmb3IgdGhlIGRldmljZXMgY292ZXJl ZCBieSB0aGlzIHByb3RvY29sLiBCdXQgSSBhbSB3b25kZXJpbmcsIHNob3VsZCB0aGUgInNoYXJl ZC1zZWNyZXQiIGZpZWxkIGJlIG1hZGUgb3B0aW9uYWwsIHNvIHRoYXQgaXQgY2FuIGJlIGVudGVy ZWQgIm91dCBvZiBiYW5kIiBpbiBhcHBsaWNhdGlvbnMgdGhhdCBwcmVmZXIgbm90IHRvIGtlZXAg aXQgc3RvcmVkIGluIHRoZSBZQU5HIGNvbmZpZ3VyYXRpb24gc3RvcmUgYW5kIGF2YWlsYWJsZSB0 byBuZXR3b3JrIG1hbmFnZW1lbnQgdG9vbHM/DQpbQm9dIFRoZSAic2hhcmVkLXNlY3JldCIgbm9k ZSBpcyBpbmRlZWQgc2Vuc2l0aXZlLiBCdXQgdGhlcmUgYXJlIHR3byBtYWluIHJlYXNvbnMgZm9y IGRlZmluaW5nIGFzIG1hbmRhdG9yeS4gMSkgVGhlIFRBQ0FDUysgcHJvdG9jb2wgcmVxdWlyZXMg dGhhdCB0aGUgc2VjcmV0IG11c3QgYmUgY29uZmlndXJlZC4gIA0KMikgWUFORyBtb2RlbCBjYW4g dXNlIE5BQ00gKFJGQzgzNDEpIHRvIGVuc3VyZSBub2RlIHNlY3VyaXR5LiBUaGUgInNoYXJlZC1z ZWNyZXQiIGFkZHMgc2VjdXJpdHkgdGFnZ2luZyAibmFjbTpkZWZhdWx0LWRlbnktYWxsIiB0byBy ZXN0cmljdCBvbmx5IGluaXRpYWwgZGV2aWNlIGFjY2VzcyBhbmQgc29tZSByZWNvdmVyeSBzZXNz aW9uLg0KDQpBZGRpdGlvbmFsbHksIHRoZSBkZWZpbml0aW9uIGZvbGxvd3MgdGhlIGN1cnJlbnQg U3lzdGVtIG1vZGVsIChSRkM3MzE3KSAsIGFzIFRBQ0FDUysgbW9kZWwgaXMgYW4gYXVnbWVudGF0 aW9uIG9mIHRoZSBTeXN0ZW0gbW9kZWwuIFRoZSBkZWZpbml0aW9uIG9mIHRoZSAic2hhcmVkLXNl Y3JldCIgaW4gdGhlIFJBRElVUyBhdXRoZW50aWNhdGlvbiBvZiB0aGUgU3lzdGVtIG1vZGVsIGlz IG1hbmRhdG9yeSBhbmQgWUFORyBleHRlbnNpb24gIm5hY206ZGVmYXVsdC1kZW55LWFsbCIgaXMg dXNlZCB0byBwcm90ZWN0LiANCg0KUGVyaGFwcyBzb21lIGFkZGl0aW9uIHRleHQgY291bGQgaGVs cDoNCi9zeXN0ZW0vdGFjYWNzcGx1cy9zZXJ2ZXIvc2hhcmVkLXNlY3JldDogIEFjY2VzcyB0byB0 aGlzIG5vZGUgaXMgY29uc2lkZXJlZCBzZW5zaXRpdmUgYW5kIHRoZXJlZm9yZSBoYXMgYmVlbiBy ZXN0cmljdGVkIHVzaW5nIHRoZSAiZGVmYXVsdC1kZW55LWFsbCIgYWNjZXNzIGNvbnRyb2wgZGVm aW5lZCBpbiBbUkZDODM0MV0uDQoNCg0KKiBOb3QgYSBzZWN1cml0eSBjb21tZW50OiB0aGUgWUFO RyBtb2R1bGUgaW5jbHVkZXMgYSByZWZlcmVuY2UgdG8gZHJhZnQtaWV0Zi1vcHNhd2ctdGFjYWNz LTE4LCBidXQgSSBhc3N1bWUgdGhhdCB5b3UnbGwgd2FudCB0byByZXBsYWNlIGl0IHdpdGggdGhl IFJGQyBudW1iZXIgZm9yIHRoYXQgZHJhZnQgb25jZSBpdCBpcyBwdWJsaXNoZWQuIFlldCBJIGRv bid0IHNlZSBhbiBSRkMgRWRpdG9yIG5vdGUgbWVudGlvbmluZyB0aGF0Lg0KW0JvXSBPSywgd2ls bCBhZGQgaW4gdGhlIG5leHQgcmV2aXNpb24uDQoNCiogSXQgaXMgY29uZnVzaW5nIHRoYXQgIm1l c3NhZ2VzLXJlY2VpdmVkIiBpcyBmb3IgbWVzc2FnZXMgcmVjZWl2ZWQgYnkgdGhlIHNlcnZlciwg YW5kICJlcnJvcnMtcmVjZWl2ZWQiIGlzIGZvciBlcnJvcnMgcmVjZWl2ZWQgKmZyb20qIHRoZSBz ZXJ2ZXIuDQpbQm9dIFRoYW5rcywgd2lsbCBjb3JyZWN0IHRvICJmcm9tIiB0aGUgc2VydmVyIHRv IGtlZXAgY29uc2lzdGVuY3kuIA0KDQo= From nobody Sun May 10 21:52:40 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C883A07AC; Sun, 10 May 2020 21:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.413 X-Spam-Level: X-Spam-Status: No, score=-0.413 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pi6zS7GCjvv; Sun, 10 May 2020 21:51:57 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCD563A07A9; Sun, 10 May 2020 21:51:56 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 04B4ppGc009041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 11 May 2020 00:51:53 -0400 Date: Sun, 10 May 2020 21:51:50 -0700 From: Benjamin Kaduk To: Martin Thomson , Rifaat Shekh-Yusef Cc: Erik Kline , draft-ietf-capport-rfc7710bis.all@ietf.org, captive-portals@ietf.org, secdir@ietf.org Message-ID: <20200511045150.GI27494@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <85873c75-0d4d-4ec5-91a1-a28b92378ec3@www.fastmail.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [secdir] Fwd: [Last-Call] Secdir last call review of draft-ietf-capport-rfc7710bis-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2020 04:52:01 -0000 [adding back some lists] -Ben On Wed, May 06, 2020 at 02:37:39PM +1000, Martin Thomson wrote: > What does "extra cautious" mean? I assume that this is intended to apply to what a human might do, further implying that there is a role for a human decision. > > None of this architecture requires the involvement of a human in this way. Nor do I think that there is any meaningful distinction between an opaque string of characters (that might include confusables) and an opaque string of digits. > > I appreciate the sentiment here, but the fundamental problem is that once you decide that this information is not from the network, it is useless. If it is from the network, it is only of limited use. That use cannot depend on the identity of the server, so there is no value in any sort of caution. > > On Wed, May 6, 2020, at 13:36, Benjamin Kaduk wrote: > > [My unicast reminder got a unicast reply; forwarding to someplace at least > > vaguely useful.] > > > > -Ben > > > > On Tue, May 05, 2020 at 07:57:14PM -0400, Rifaat Shekh-Yusef wrote: > > > Thanks for the reminder Ben. > > > > > > Erik, > > > > > > Since this document allows the use of IP address to represent the portal > > > URI, I think it would important to add some text that explicitly states > > > that the user might be presented with an IP address instead of the hostname > > > of the API, and in that case the user should be extra cautious when this > > > happens. > > > > > > Regards, > > > Rifaat > > > > > > > > > > > > > > > On Tue, May 5, 2020 at 7:30 PM Benjamin Kaduk wrote: > > > > > > > Hi Rifaat, > > > > > > > > I just wanted to follow-up and check that you had received Erik's question. > > > > > > > > Thanks, > > > > > > > > Ben > > > > > > > > On Sun, May 03, 2020 at 02:58:29PM -0700, Erik Kline wrote: > > > > > Rifaat, > > > > > > > > > > Thanks for your reading of the document. > > > > > > > > > > The security section has a paragraph that begins: > > > > > > > > > > """ > > > > > An attacker with the ability to inject DHCP messages or RAs could > > > > > include an option from this document to force users to contact an > > > > > address of his choosing. As an attacker with this capability could > > > > > simply list himself as the default gateway (and so intercept all the > > > > > victim's traffic); this does not provide them with significantly more > > > > > capabilities, but because this document removes the need for > > > > > interception, the attacker may have an easier time performing the > > > > > attack... > > > > > """ > > > > > > > > > > Do you have any specific ideas for what text might be added to clarify > > > > vis. > > > > > your concern? Would a sentence that captures your "the use of TLS and > > > > > presenting the identity in the certificate might not be of much help" > > > > > observation suffice? > > > > > > > > > > Thanks, > > > > > -Erik > > > > > > > > > > On Fri, 1 May 2020 at 05:10, Rifaat Shekh-Yusef via Datatracker < > > > > > noreply@ietf.org> wrote: > > > > > > > > > > > Reviewer: Rifaat Shekh-Yusef > > > > > > Review result: Has Issues > > > > > > > > > > > > Since the use of IP address literal is not forbidden by this document, > > > > > > what if > > > > > > an attacker with the ability to inject DHCP messages or RAs uses this > > > > > > option > > > > > > to force the user to contact an IP address of his choosing? In this > > > > case, > > > > > > the use > > > > > > of TLS and presenting the identity in the certificate might not be of > > > > much > > > > > > help. > > > > > > > > > > > > I think this case should be discussed in the security consideration > > > > > > section. > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > last-call mailing list > > > > > last-call@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/last-call > > > > > > > > > > From nobody Sun May 10 22:08:57 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAFA63A07BB; Sun, 10 May 2020 22:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJpb150E5d8X; Sun, 10 May 2020 22:08:31 -0700 (PDT) Received: from mail-oi1-x242.google.com (mail-oi1-x242.google.com [IPv6:2607:f8b0:4864:20::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1ADF3A07B9; Sun, 10 May 2020 22:08:31 -0700 (PDT) Received: by mail-oi1-x242.google.com with SMTP id a2so13873793oia.11; Sun, 10 May 2020 22:08:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=NYRzPR29M9foaAP4d2cScja7R0VvI2djP1LfIlZ3K8k=; b=WLkMiK7JqoxCKR7cCvIhu6tIbdqQ/f58EazPMe9Jd9PUfYWTXr8EgyPwIsQe/jM1Af w3YhGOVk9OcQdjlK7sRw0bhbqwYSjZGh4OOGRf1PTHOS+CtyDFMB4o0JlKcoYEV6YvKy rXILLTqtchRgfZV5TqZ/kvnVNDBRqDjwiZxx1m9oPe54bA0bpNSA7N/mGpIcfokvibyL RKJ+S4fE9dB6u0/I1MxAtChB2aHpLyeGSABXZEPGpVSfiF9ZqkJTubEiPtfnz0yPZctn c6wua+sROnyziCZRMjN2l+m3J8dwVAwVtj5kH77kbQZ1xx3DkgzM+I5FZwyq04nNpaw6 sY8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=NYRzPR29M9foaAP4d2cScja7R0VvI2djP1LfIlZ3K8k=; b=hR8sltsQM48hDK/tkUzmFYZ10q5BoMtHSHO9Gvya30HnNDOMZOEg7CXV14zgDRtWje 5j9WK24sKDbsKpCVHmgV9e6LqvSYwiNy5NqrAP/FQQK2B8O10yQ9QtWdG+UWAWvNs/tS DeNKReolafxu1JlkMim18xoS6J2Ebz3rmpZ6rgVi+FRVMe46Ov/78J/6pZIdvAo+eCAF UiF5Ul562F0L4bKjJDeBuN4xOpryFNMk8as9+icd21xWjgAGQ50AFMcp10swchD03a+t x1yfN2uYmE+fHp1mN50hiCZaCQ82TWdG1g+tboWYvIujOnY/uymXBUx2i5leUCnFEJ/j USRw== X-Gm-Message-State: AGi0PubAMfrWsEMcUHxDK4e4ny56yyLi0IkPytZsbNSIlXVzuLf9ZzMv jZzy5U8ieoxvhYFQKy7TjGOF4r+Kxu7iksWrzTg= X-Google-Smtp-Source: APiQypK9+IzNaeqBeuZL4SO0sp4nRvTQdBaYAG/EDeW4fiYFm4HWexIlP0zfi48oedWyPU2EU+PmqDBJDebyuqxu00k= X-Received: by 2002:aca:190e:: with SMTP id l14mr18537299oii.77.1589173711058; Sun, 10 May 2020 22:08:31 -0700 (PDT) MIME-Version: 1.0 References: <85873c75-0d4d-4ec5-91a1-a28b92378ec3@www.fastmail.com> <20200511045150.GI27494@kduck.mit.edu> In-Reply-To: <20200511045150.GI27494@kduck.mit.edu> From: Erik Kline Date: Sun, 10 May 2020 22:08:20 -0700 Message-ID: To: Benjamin Kaduk Cc: Martin Thomson , Rifaat Shekh-Yusef , Erik Kline , draft-ietf-capport-rfc7710bis.all@ietf.org, captive-portals , secdir@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [secdir] Fwd: [Last-Call] Secdir last call review of draft-ietf-capport-rfc7710bis-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2020 05:08:35 -0000 For the record: trying to improve text over on https://github.com/capport-wg/7710bis/pull/31 . On Sun, May 10, 2020 at 9:52 PM Benjamin Kaduk wrote: > > [adding back some lists] > > -Ben > > On Wed, May 06, 2020 at 02:37:39PM +1000, Martin Thomson wrote: > > What does "extra cautious" mean? I assume that this is intended to app= ly to what a human might do, further implying that there is a role for a hu= man decision. > > > > None of this architecture requires the involvement of a human in this w= ay. Nor do I think that there is any meaningful distinction between an opaq= ue string of characters (that might include confusables) and an opaque stri= ng of digits. > > > > I appreciate the sentiment here, but the fundamental problem is that on= ce you decide that this information is not from the network, it is useless.= If it is from the network, it is only of limited use. That use cannot depe= nd on the identity of the server, so there is no value in any sort of cauti= on. > > > > On Wed, May 6, 2020, at 13:36, Benjamin Kaduk wrote: > > > [My unicast reminder got a unicast reply; forwarding to someplace at = least > > > vaguely useful.] > > > > > > -Ben > > > > > > On Tue, May 05, 2020 at 07:57:14PM -0400, Rifaat Shekh-Yusef wrote: > > > > Thanks for the reminder Ben. > > > > > > > > Erik, > > > > > > > > Since this document allows the use of IP address to represent the p= ortal > > > > URI, I think it would important to add some text that explicitly st= ates > > > > that the user might be presented with an IP address instead of the = hostname > > > > of the API, and in that case the user should be extra cautious when= this > > > > happens. > > > > > > > > Regards, > > > > Rifaat > > > > > > > > > > > > > > > > > > > > On Tue, May 5, 2020 at 7:30 PM Benjamin Kaduk wrote= : > > > > > > > > > Hi Rifaat, > > > > > > > > > > I just wanted to follow-up and check that you had received Erik's= question. > > > > > > > > > > Thanks, > > > > > > > > > > Ben > > > > > > > > > > On Sun, May 03, 2020 at 02:58:29PM -0700, Erik Kline wrote: > > > > > > Rifaat, > > > > > > > > > > > > Thanks for your reading of the document. > > > > > > > > > > > > The security section has a paragraph that begins: > > > > > > > > > > > > """ > > > > > > An attacker with the ability to inject DHCP messages or RAs = could > > > > > > include an option from this document to force users to conta= ct an > > > > > > address of his choosing. As an attacker with this capabilit= y could > > > > > > simply list himself as the default gateway (and so intercept= all the > > > > > > victim's traffic); this does not provide them with significa= ntly more > > > > > > capabilities, but because this document removes the need for > > > > > > interception, the attacker may have an easier time performin= g the > > > > > > attack... > > > > > > """ > > > > > > > > > > > > Do you have any specific ideas for what text might be added to = clarify > > > > > vis. > > > > > > your concern? Would a sentence that captures your "the use of = TLS and > > > > > > presenting the identity in the certificate might not be of much= help" > > > > > > observation suffice? > > > > > > > > > > > > Thanks, > > > > > > -Erik > > > > > > > > > > > > On Fri, 1 May 2020 at 05:10, Rifaat Shekh-Yusef via Datatracker= < > > > > > > noreply@ietf.org> wrote: > > > > > > > > > > > > > Reviewer: Rifaat Shekh-Yusef > > > > > > > Review result: Has Issues > > > > > > > > > > > > > > Since the use of IP address literal is not forbidden by this = document, > > > > > > > what if > > > > > > > an attacker with the ability to inject DHCP messages or RAs u= ses this > > > > > > > option > > > > > > > to force the user to contact an IP address of his choosing? I= n this > > > > > case, > > > > > > > the use > > > > > > > of TLS and presenting the identity in the certificate might n= ot be of > > > > > much > > > > > > > help. > > > > > > > > > > > > > > I think this case should be discussed in the security conside= ration > > > > > > > section. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > last-call mailing list > > > > > > last-call@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/last-call > > > > > > > > > > > > > From nobody Sun May 10 22:09:43 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED9783A07BB; Sun, 10 May 2020 22:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qIxkTDjtn45R; Sun, 10 May 2020 22:09:36 -0700 (PDT) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ECDA3A07BC; Sun, 10 May 2020 22:09:36 -0700 (PDT) Received: by mail-ot1-x32e.google.com with SMTP id z17so6549988oto.4; Sun, 10 May 2020 22:09:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=CaWcBHXD9T08qISZh/RfGrzUc1HePdortH5TF4KNBAk=; b=Kb6XR8JUGVhDBwqyvCM8QCwB2ZrEC/4d9n4dxMyV7gUwxuXJLlkt2JJkZudlKKCdxH Gt38gz/0bS78qyyP2q+6BENqUTzt9JiNHIEft4vw8t7cy/RbyzyDUOU7GECPjs5nvZss F/EG3noOv6lRmwUxVmz88WbJmxQSjd+KgAtESl/1eENI3T7YnUXN2oTrsXta8dQ5cEGG tAKPxyKTcRNOulJRGtfrlvl3exVNbYCTiNP0B69tCq7akr6IX7nVJy63+NZakr1fjSTh zdvxO+uVNzjGu5NAX3ASyPST0lKFFC4Gwm7BBcARtUaWHgD+WVgldRck/K4dc9g1KRJX MnaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=CaWcBHXD9T08qISZh/RfGrzUc1HePdortH5TF4KNBAk=; b=o5RChLLkYHyuXxgqHPRtt0b6GNUCj9XjuJPLaXyokg6g7j1YRYAs6IznpjTKXT8wUL LcVOrIDRdWGajYV9ta1fuYe7P3NRRjKCfkCCFVIvmcPfM9BiCcWls5yiqfLRzdxFwjCw BF+4bN+6iNSkLOu9eGllKoCCphd92gkMaH7ykQS2O+jdoHSiMPVzYVy4MHRgD+JYyAcS 4y4mid+7LCbLIKuZ5FJdATP2ixxTRwk7hCgAodeKLcUkPY1eKGwJ9qytsUjYF4OhshrF mWPpgnFWBMyL+LtVY2bcSptGJJmdbskWHnLB798by4HYYDk8geNro9ixY9xKuNXYl6mc 4tYA== X-Gm-Message-State: AGi0PuabAI2k6ipMvwoIReslPHIG2WDI7JRvLBsXxmVqYdG+auvWdA0B 4v7uwYYGNCs+8KDQuZ4grc+nXDOGjNZq4yjcqF4= X-Google-Smtp-Source: APiQypLuFPJg7zvYg82uDhFBYk9ysY85v5CXth/LmZ1zPlORU+eWN7fK6EsxCp7LeYtBUuIj5+HXWwl4pVDm5PBukJM= X-Received: by 2002:a9d:7988:: with SMTP id h8mr11595534otm.191.1589173775671; Sun, 10 May 2020 22:09:35 -0700 (PDT) MIME-Version: 1.0 References: <85873c75-0d4d-4ec5-91a1-a28b92378ec3@www.fastmail.com> <20200511045150.GI27494@kduck.mit.edu> In-Reply-To: From: Erik Kline Date: Sun, 10 May 2020 22:09:25 -0700 Message-ID: To: Benjamin Kaduk Cc: Martin Thomson , Rifaat Shekh-Yusef , Erik Kline , draft-ietf-capport-rfc7710bis.all@ietf.org, captive-portals , secdir@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [secdir] Fwd: [Last-Call] Secdir last call review of draft-ietf-capport-rfc7710bis-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2020 05:09:41 -0000 Gah! Sorry, I didn't mean to imply that the conversation should be moved there. Only pointing to text-in-progress for your review. On Sun, May 10, 2020 at 10:08 PM Erik Kline wrote: > > For the record: trying to improve text over on > https://github.com/capport-wg/7710bis/pull/31 . > > On Sun, May 10, 2020 at 9:52 PM Benjamin Kaduk wrote: > > > > [adding back some lists] > > > > -Ben > > > > On Wed, May 06, 2020 at 02:37:39PM +1000, Martin Thomson wrote: > > > What does "extra cautious" mean? I assume that this is intended to a= pply to what a human might do, further implying that there is a role for a = human decision. > > > > > > None of this architecture requires the involvement of a human in this= way. Nor do I think that there is any meaningful distinction between an op= aque string of characters (that might include confusables) and an opaque st= ring of digits. > > > > > > I appreciate the sentiment here, but the fundamental problem is that = once you decide that this information is not from the network, it is useles= s. If it is from the network, it is only of limited use. That use cannot de= pend on the identity of the server, so there is no value in any sort of cau= tion. > > > > > > On Wed, May 6, 2020, at 13:36, Benjamin Kaduk wrote: > > > > [My unicast reminder got a unicast reply; forwarding to someplace a= t least > > > > vaguely useful.] > > > > > > > > -Ben > > > > > > > > On Tue, May 05, 2020 at 07:57:14PM -0400, Rifaat Shekh-Yusef wrote: > > > > > Thanks for the reminder Ben. > > > > > > > > > > Erik, > > > > > > > > > > Since this document allows the use of IP address to represent the= portal > > > > > URI, I think it would important to add some text that explicitly = states > > > > > that the user might be presented with an IP address instead of th= e hostname > > > > > of the API, and in that case the user should be extra cautious wh= en this > > > > > happens. > > > > > > > > > > Regards, > > > > > Rifaat > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, May 5, 2020 at 7:30 PM Benjamin Kaduk wro= te: > > > > > > > > > > > Hi Rifaat, > > > > > > > > > > > > I just wanted to follow-up and check that you had received Erik= 's question. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Ben > > > > > > > > > > > > On Sun, May 03, 2020 at 02:58:29PM -0700, Erik Kline wrote: > > > > > > > Rifaat, > > > > > > > > > > > > > > Thanks for your reading of the document. > > > > > > > > > > > > > > The security section has a paragraph that begins: > > > > > > > > > > > > > > """ > > > > > > > An attacker with the ability to inject DHCP messages or RA= s could > > > > > > > include an option from this document to force users to con= tact an > > > > > > > address of his choosing. As an attacker with this capabil= ity could > > > > > > > simply list himself as the default gateway (and so interce= pt all the > > > > > > > victim's traffic); this does not provide them with signifi= cantly more > > > > > > > capabilities, but because this document removes the need f= or > > > > > > > interception, the attacker may have an easier time perform= ing the > > > > > > > attack... > > > > > > > """ > > > > > > > > > > > > > > Do you have any specific ideas for what text might be added t= o clarify > > > > > > vis. > > > > > > > your concern? Would a sentence that captures your "the use o= f TLS and > > > > > > > presenting the identity in the certificate might not be of mu= ch help" > > > > > > > observation suffice? > > > > > > > > > > > > > > Thanks, > > > > > > > -Erik > > > > > > > > > > > > > > On Fri, 1 May 2020 at 05:10, Rifaat Shekh-Yusef via Datatrack= er < > > > > > > > noreply@ietf.org> wrote: > > > > > > > > > > > > > > > Reviewer: Rifaat Shekh-Yusef > > > > > > > > Review result: Has Issues > > > > > > > > > > > > > > > > Since the use of IP address literal is not forbidden by thi= s document, > > > > > > > > what if > > > > > > > > an attacker with the ability to inject DHCP messages or RAs= uses this > > > > > > > > option > > > > > > > > to force the user to contact an IP address of his choosing?= In this > > > > > > case, > > > > > > > > the use > > > > > > > > of TLS and presenting the identity in the certificate might= not be of > > > > > > much > > > > > > > > help. > > > > > > > > > > > > > > > > I think this case should be discussed in the security consi= deration > > > > > > > > section. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > last-call mailing list > > > > > > > last-call@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/last-call > > > > > > > > > > > > > > > > From nobody Mon May 11 04:12:59 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 276E73A09F0; Mon, 11 May 2020 04:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wIqwKGuV5GKJ; Mon, 11 May 2020 04:12:41 -0700 (PDT) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 305A83A09E8; Mon, 11 May 2020 04:12:41 -0700 (PDT) Received: by mail-wr1-x431.google.com with SMTP id x17so10436975wrt.5; Mon, 11 May 2020 04:12:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=BIj2aVW0Q+l4uirILkL6VAF/PJq5CUGd+sAOOoj4jZg=; b=CQvvt03F609uxl8gqfCqYNHL3kOkihINJD8XhqAzvJdbqHneahM2+SUN58WEE3fPA2 Ee7jz7ZfR0UEy/+BByG2Y0LR4LAKuerpsPg9PCfjA8vzT2vzSrv7pdjjFQKmYIV9uvyl aOzbleAYJvRRT8J5oo9Q7GZQZWiG28XDLsyJpacNVADeyUSh6ERqVWixk66NV+ydFYwB +CdM/OLEg7ekrPjokEeMY4kHbU/oNtgoyfFpFsxVJwQ2GADM3EsQYMXnmO2/DNCOPSN0 MWX4NBfiL09/GO7MOckzPjfk5irRd6C2yoqCzcEi/lQGM622HtktvCxTGKKtfl264gYM 4nww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=BIj2aVW0Q+l4uirILkL6VAF/PJq5CUGd+sAOOoj4jZg=; b=ApWYnTsvi1qMTj0WAWSXa/Wlh32igC5bGV04Nt7AOSt81iczMbzv3diAPjT3nbCzjr SzgEOpC1yKXW9W+hmr5i5YMpFB9IAhnILJADR7E0iB1chVi4/5RI59nXIOmpAx/Q1CUT qJWCrLUjDtF0A94OWbtqwg+6MdQWURV2FDTq9bsP47SaQcwwh8Soug2/Hu/0WreXTfcn UDmaElFmJtDANO9B5zN4J9zbboiCIO89mbheUbHx/Xh9lMWs50Apy9aWYWvZ6458wePr YbxCyAf4FwufHoEh8spfcVMVsIVKqCJfs3vDBN971s41fpC//VXrH4NWUuVRcJ7jzFhT TgKw== X-Gm-Message-State: AGi0Pubr4GfHT7P/HoQxwjf+pBu9HLXQExAKCEiYLKn8mAml8Bt1CGJ8 QcAmRE1wHGSRzg4JoWI+PRc= X-Google-Smtp-Source: APiQypKexmLP7C3frq84M5Zf6o1ud1RqnphpfIQ3pmoGEPTjNAjWaZM3HUbRmWN9O7gFSNLeWfJE8g== X-Received: by 2002:adf:9f48:: with SMTP id f8mr18565992wrg.228.1589195559539; Mon, 11 May 2020 04:12:39 -0700 (PDT) Received: from [10.0.0.139] (bzq-109-65-14-162.red.bezeqint.net. [109.65.14.162]) by smtp.gmail.com with ESMTPSA id a13sm16784017wrv.67.2020.05.11.04.12.37 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 May 2020 04:12:38 -0700 (PDT) User-Agent: Microsoft-MacOutlook/16.36.20041300 Date: Mon, 11 May 2020 14:12:36 +0300 From: Yaron Sheffer To: "Wubo (lana)" , "secdir@ietf.org" CC: "opsawg@ietf.org" , "draft-ietf-opsawg-tacacs-yang.all@ietf.org" , "last-call@ietf.org" Message-ID: Thread-Topic: Secdir last call review of draft-ietf-opsawg-tacacs-yang-03 References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-opsawg-tacacs-yang-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2020 11:12:43 -0000 Hi Bo, Thank you for your quick response. I am OK with the clarifications and the = additional text. Best, Yaron =EF=BB=BFOn 5/11/20, 06:01, "Wubo (lana)" wrote: Hi Yaron, Thanks for the review. Please see inline. Regards, Bo -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: Yaron Sheffer via Datatracker [mailto:noreply@ietf.org]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2020=E5=B9=B45=E6=9C=889=E6=97=A5 1:08 =E6=94=B6=E4=BB=B6=E4=BA=BA: secdir@ietf.org =E6=8A=84=E9=80=81: opsawg@ietf.org; draft-ietf-opsawg-tacacs-yang.all@ietf.org; la= st-call@ietf.org =E4=B8=BB=E9=A2=98: Secdir last call review of draft-ietf-opsawg-tacacs-yang-03 Reviewer: Yaron Sheffer Review result: Has Nits This document defines a YANG module for the configuration of TACACS+ cl= ients. The document is short and straightforward, and I only have one signific= ant comment. * I am not familiar with common security practices for the devices cove= red by this protocol. But I am wondering, should the "shared-secret" field b= e made optional, so that it can be entered "out of band" in applications tha= t prefer not to keep it stored in the YANG configuration store and available= to network management tools? [Bo] The "shared-secret" node is indeed sensitive. But there are two ma= in reasons for defining as mandatory. 1) The TACACS+ protocol requires that = the secret must be configured. =20 2) YANG model can use NACM (RFC8341) to ensure node security. The "shar= ed-secret" adds security tagging "nacm:default-deny-all" to restrict only in= itial device access and some recovery session. Additionally, the definition follows the current System model (RFC7317)= , as TACACS+ model is an augmentation of the System model. The definition o= f the "shared-secret" in the RADIUS authentication of the System model is ma= ndatory and YANG extension "nacm:default-deny-all" is used to protect.=20 Perhaps some addition text could help: /system/tacacsplus/server/shared-secret: Access to this node is consid= ered sensitive and therefore has been restricted using the "default-deny-all= " access control defined in [RFC8341]. * Not a security comment: the YANG module includes a reference to draft= -ietf-opsawg-tacacs-18, but I assume that you'll want to replace it with the= RFC number for that draft once it is published. Yet I don't see an RFC Edit= or note mentioning that. [Bo] OK, will add in the next revision. * It is confusing that "messages-received" is for messages received by = the server, and "errors-received" is for errors received *from* the server. [Bo] Thanks, will correct to "from" the server to keep consistency.=20 From nobody Tue May 12 08:11:56 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC273A0CAE; Tue, 12 May 2020 00:30:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1589268654; bh=hZc5CbXRLpwW9rPV47HsQ15a5Cdvg9qILbWWneDzD24=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=jeRsBmI/kwTd9w2knDryFuAG14kadySxcBsz9kQfaG5ZjP8gdTdle77Dpqw6sX1Rm FC8kapuNGbWGOU/qjVIGnkOp2ffNWP/XiRo0bcqD++Hdz4U+nhspRzDwDtK3RGxx5U X7Loaf9UeM28KEJj1gT146YZPAO/LWCtbWqRGCb8= X-Mailbox-Line: From new-work-bounces@ietf.org Tue May 12 00:30:54 2020 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 419D43A0CA0; Tue, 12 May 2020 00:30:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1589268654; bh=hZc5CbXRLpwW9rPV47HsQ15a5Cdvg9qILbWWneDzD24=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=jeRsBmI/kwTd9w2knDryFuAG14kadySxcBsz9kQfaG5ZjP8gdTdle77Dpqw6sX1Rm FC8kapuNGbWGOU/qjVIGnkOp2ffNWP/XiRo0bcqD++Hdz4U+nhspRzDwDtK3RGxx5U X7Loaf9UeM28KEJj1gT146YZPAO/LWCtbWqRGCb8= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23F8F3A0CA0 for ; Tue, 12 May 2020 00:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcFHoSep47qk for ; Tue, 12 May 2020 00:30:50 -0700 (PDT) Received: from raoul.w3.org (raoul.w3.org [128.30.52.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A84963A0BD5 for ; Tue, 12 May 2020 00:30:50 -0700 (PDT) Received: from [112.102.246.208] (helo=[192.168.0.101]) by raoul.w3.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jYPNI-0005Qu-Mp for new-work@ietf.org; Tue, 12 May 2020 07:30:49 +0000 To: new-work@ietf.org From: xueyuan Message-ID: <9d03cef9-6602-af95-e431-3fb04c6c7e91@w3.org> Date: Tue, 12 May 2020 15:30:43 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 Content-Language: en-US Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Precedence: list Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Tue, 12 May 2020 08:11:55 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Distributed Tracing Working Group (until 2020-06-23) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 07:30:57 -0000 SGVsbG8sCgpUb2RheSBXM0MgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0aXZlcyByZWNl aXZlZCBhIFByb3Bvc2FsCnRvIHJldmlldyBhIGRyYWZ0IGNoYXJ0ZXIgZm9yIHRoZSBEaXN0cmli dXRlZCBUcmFjaW5nIFdvcmtpbmcgR3JvdXA6CiDCoCBodHRwczovL3d3dy53My5vcmcvMjAyMC8w NS9wcm9wb3NlZC1kdC13Zy1jaGFydGVyLmh0bWwKCkFzIHBhcnQgb2YgZW5zdXJpbmcgdGhhdCB0 aGUgY29tbXVuaXR5IGlzIGF3YXJlIG9mIHByb3Bvc2VkIHdvcmsKYXQgVzNDLCB0aGlzIGRyYWZ0 IGNoYXJ0ZXIgaXMgcHVibGljIGR1cmluZyB0aGUgQWR2aXNvcnkKQ29tbWl0dGVlIHJldmlldyBw ZXJpb2QuCgpXM0MgaW52aXRlcyBwdWJsaWMgY29tbWVudHMgdGhyb3VnaCAyMDIwLTA2LTIzIG9u IHRoZQpwcm9wb3NlZCBjaGFydGVyLiBQbGVhc2Ugc2VuZCBjb21tZW50cyB0bwpwdWJsaWMtbmV3 LXdvcmtAdzMub3JnLCB3aGljaCBoYXMgYSBwdWJsaWMgYXJjaGl2ZToKIMKgIGh0dHA6Ly9saXN0 cy53My5vcmcvQXJjaGl2ZXMvUHVibGljL3B1YmxpYy1uZXctd29yay8KCk90aGVyIHRoYW4gY29t bWVudHMgc2VudCBpbiBmb3JtYWwgcmVzcG9uc2VzIGJ5IFczQyBBZHZpc29yeQpDb21taXR0ZWUg UmVwcmVzZW50YXRpdmVzLCBXM0MgY2Fubm90IGd1YXJhbnRlZSBhIHJlc3BvbnNlIHRvCmNvbW1l bnRzLiBJZiB5b3Ugd29yayBmb3IgYSBXM0MgTWVtYmVyIFsxXSwgcGxlYXNlIGNvb3JkaW5hdGUK eW91ciBjb21tZW50cyB3aXRoIHlvdXIgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0aXZl LiBGb3IKZXhhbXBsZSwgeW91IG1heSB3aXNoIHRvIG1ha2UgcHVibGljIGNvbW1lbnRzIHZpYSB0 aGlzIGxpc3QgYW5kCmhhdmUgeW91ciBBZHZpc29yeSBDb21taXR0ZWUgUmVwcmVzZW50YXRpdmUg cmVmZXIgdG8gaXQgZnJvbSBoaXMKb3IgaGVyIGZvcm1hbCByZXZpZXcgY29tbWVudHMuCgpUaGUg V29ya2luZyBHcm91cCdzIGN1cnJlbnQgY2hhcnRlciBbMl0gaXMgaGVyZWJ5IGV4dGVuZGVkCnVu dGlsIDMwIEp1bmUgMjAyMC4KCklmIHlvdSBzaG91bGQgaGF2ZSBhbnkgcXVlc3Rpb25zIG9yIG5l ZWQgZnVydGhlciBpbmZvcm1hdGlvbiwgcGxlYXNlCmNvbnRhY3QgUGhpbGlwcGUgTGUgSGVnYXJl dCwgVzNDIFByb2plY3QgTWFuYWdlbWVudCBMZWFkLCA8cGxoQHczLm9yZz4uCgpUaGFuayB5b3Us CgpYdWV5dWFuIEppYSwgVzNDIE1hcmtldGluZyAmIENvbW11bmljYXRpb25zCgpbMV0gaHR0cDov L3d3dy53My5vcmcvQ29uc29ydGl1bS9NZW1iZXIvTGlzdApbMl0gaHR0cHM6Ly93d3cudzMub3Jn LzIwMTgvMDcvZGlzdHJpYnV0ZWQtdHJhY2luZy5odG1sCgoKX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KbmV3LXdvcmsgbWFpbGluZyBsaXN0Cm5ldy13b3Jr QGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV3LXdvcmsK From nobody Wed May 13 09:29:13 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C41AC3A0E49; Wed, 13 May 2020 09:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YhQ4oAQbLOrS; Wed, 13 May 2020 09:29:06 -0700 (PDT) Received: from mail-il1-f177.google.com (mail-il1-f177.google.com [209.85.166.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E6DE3A0DA4; Wed, 13 May 2020 09:29:03 -0700 (PDT) Received: by mail-il1-f177.google.com with SMTP id e8so252672ilm.7; Wed, 13 May 2020 09:29:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=XjYG4YNM45AW4STTQHldGUEiqmaHvYEYn79pGIbRLhc=; b=HOu6N3S80UxRfGhi8Y2cmGf0HjBLxIYnH4lmsmCBPy3BiZNcZRZwBpXydldBgp4rYe P7yCvid/kW5nYKC5RwEHUL+UYhKLuwCkBF2JqAMCUv6l1NAokMjmIHW1l7QvPlJ8DzxD c/cL2z1ccEURwKxfLxBwcfS9L/TLChhI5319Yjenuscr78uFprv/KWQPip3e0QRUf+LH M4ATMxZ8kJQNDGbhtelGjTKgcCP8jHPHXIplqrdELg43xrkPDJ6XmR2aiI+7PYLhED/6 I7N8WrewDYdvtTqJ34mZ0EVzWQmgNL5SGNCmmWIQkpwQ7e86jkVos9utT682WpOYPODt Mc+Q== X-Gm-Message-State: AOAM530Gmr3TbwBaXaqL29/XGkegYSYeZMnbLjitagcfUmsI5OXEwQF0 53C4B5zSJcLY2xH+P/VW3jDVfh698Wp9+x+w1Ag= X-Google-Smtp-Source: ABdhPJzdlW8NzDY8QTaXE936qRF4fq++h8bEgieOQ+JyhMEMh+VBYIiQFkl6jkY9U43l7DMLFc3a0d8LyZ0+DlfGxxM= X-Received: by 2002:a92:dc0e:: with SMTP id t14mr299573iln.140.1589387342530; Wed, 13 May 2020 09:29:02 -0700 (PDT) MIME-Version: 1.0 References: <85873c75-0d4d-4ec5-91a1-a28b92378ec3@www.fastmail.com> <20200511045150.GI27494@kduck.mit.edu> In-Reply-To: From: Barry Leiba Date: Wed, 13 May 2020 12:28:51 -0400 Message-ID: To: Erik Kline Cc: Benjamin Kaduk , Martin Thomson , Rifaat Shekh-Yusef , Erik Kline , draft-ietf-capport-rfc7710bis.all@ietf.org, captive-portals , IETF SecDir Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [secdir] Fwd: [Last-Call] Secdir last call review of draft-ietf-capport-rfc7710bis-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 16:29:12 -0000 Erik, is there a revised I-D coming for this? Thanks, Barry On Mon, May 11, 2020 at 1:09 AM Erik Kline wrote: > > Gah! Sorry, I didn't mean to imply that the conversation should be > moved there. Only pointing to text-in-progress for your review. > > On Sun, May 10, 2020 at 10:08 PM Erik Kline wrote: > > > > For the record: trying to improve text over on > > https://github.com/capport-wg/7710bis/pull/31 . > > > > On Sun, May 10, 2020 at 9:52 PM Benjamin Kaduk wrote: > > > > > > [adding back some lists] > > > > > > -Ben > > > > > > On Wed, May 06, 2020 at 02:37:39PM +1000, Martin Thomson wrote: > > > > What does "extra cautious" mean? I assume that this is intended to= apply to what a human might do, further implying that there is a role for = a human decision. > > > > > > > > None of this architecture requires the involvement of a human in th= is way. Nor do I think that there is any meaningful distinction between an = opaque string of characters (that might include confusables) and an opaque = string of digits. > > > > > > > > I appreciate the sentiment here, but the fundamental problem is tha= t once you decide that this information is not from the network, it is usel= ess. If it is from the network, it is only of limited use. That use cannot = depend on the identity of the server, so there is no value in any sort of c= aution. > > > > > > > > On Wed, May 6, 2020, at 13:36, Benjamin Kaduk wrote: > > > > > [My unicast reminder got a unicast reply; forwarding to someplace= at least > > > > > vaguely useful.] > > > > > > > > > > -Ben > > > > > > > > > > On Tue, May 05, 2020 at 07:57:14PM -0400, Rifaat Shekh-Yusef wrot= e: > > > > > > Thanks for the reminder Ben. > > > > > > > > > > > > Erik, > > > > > > > > > > > > Since this document allows the use of IP address to represent t= he portal > > > > > > URI, I think it would important to add some text that explicitl= y states > > > > > > that the user might be presented with an IP address instead of = the hostname > > > > > > of the API, and in that case the user should be extra cautious = when this > > > > > > happens. > > > > > > > > > > > > Regards, > > > > > > Rifaat > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, May 5, 2020 at 7:30 PM Benjamin Kaduk w= rote: > > > > > > > > > > > > > Hi Rifaat, > > > > > > > > > > > > > > I just wanted to follow-up and check that you had received Er= ik's question. > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > Ben > > > > > > > > > > > > > > On Sun, May 03, 2020 at 02:58:29PM -0700, Erik Kline wrote: > > > > > > > > Rifaat, > > > > > > > > > > > > > > > > Thanks for your reading of the document. > > > > > > > > > > > > > > > > The security section has a paragraph that begins: > > > > > > > > > > > > > > > > """ > > > > > > > > An attacker with the ability to inject DHCP messages or = RAs could > > > > > > > > include an option from this document to force users to c= ontact an > > > > > > > > address of his choosing. As an attacker with this capab= ility could > > > > > > > > simply list himself as the default gateway (and so inter= cept all the > > > > > > > > victim's traffic); this does not provide them with signi= ficantly more > > > > > > > > capabilities, but because this document removes the need= for > > > > > > > > interception, the attacker may have an easier time perfo= rming the > > > > > > > > attack... > > > > > > > > """ > > > > > > > > > > > > > > > > Do you have any specific ideas for what text might be added= to clarify > > > > > > > vis. > > > > > > > > your concern? Would a sentence that captures your "the use= of TLS and > > > > > > > > presenting the identity in the certificate might not be of = much help" > > > > > > > > observation suffice? > > > > > > > > > > > > > > > > Thanks, > > > > > > > > -Erik > > > > > > > > > > > > > > > > On Fri, 1 May 2020 at 05:10, Rifaat Shekh-Yusef via Datatra= cker < > > > > > > > > noreply@ietf.org> wrote: > > > > > > > > > > > > > > > > > Reviewer: Rifaat Shekh-Yusef > > > > > > > > > Review result: Has Issues > > > > > > > > > > > > > > > > > > Since the use of IP address literal is not forbidden by t= his document, > > > > > > > > > what if > > > > > > > > > an attacker with the ability to inject DHCP messages or R= As uses this > > > > > > > > > option > > > > > > > > > to force the user to contact an IP address of his choosin= g? In this > > > > > > > case, > > > > > > > > > the use > > > > > > > > > of TLS and presenting the identity in the certificate mig= ht not be of > > > > > > > much > > > > > > > > > help. > > > > > > > > > > > > > > > > > > I think this case should be discussed in the security con= sideration > > > > > > > > > section. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > last-call mailing list > > > > > > > > last-call@ietf.org > > > > > > > > https://www.ietf.org/mailman/listinfo/last-call > > > > > > > > > > > > > > > > > > > From nobody Wed May 13 10:29:28 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA1023A0C2A; Wed, 13 May 2020 10:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pyZK2L9kl_AY; Wed, 13 May 2020 10:29:21 -0700 (PDT) Received: from mail-oi1-x241.google.com (mail-oi1-x241.google.com [IPv6:2607:f8b0:4864:20::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DF2E3A0C24; Wed, 13 May 2020 10:29:21 -0700 (PDT) Received: by mail-oi1-x241.google.com with SMTP id o24so22137649oic.0; Wed, 13 May 2020 10:29:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=89A+ZLrRbgJRt6TZZk9gOtuDjqGkDltWX1PRo7k7Ls8=; b=BkL41jSNDVmeMyziEp9AUOA22AnC49v24YA67iKBG7+6XPLX2n7NCDG3tw0GuKsjlc 8NnFMGZL/TTNbaaVD8msR0/er4DTZhtujN/9cGRDaET3blfBEzK6u/QcOeqfmsHS3XEJ xNLtfqztBQj15eGy/ErhjBUeUOlDIfO3NO5i9yQFpZb6SN0YfW3BpvS6I51zvf8Eu6Uc k4fJ/aLru9a3E1v21A3X3GphT/BPQHX4SCMWyinXrxAdPCqz81gg/ufnpGAe4UbRQ195 DmmgDkX6Rn+Vxd3rb71WloqJMVayYQ8k8a99mxtRrPCGCOmKymCnchCIdwJbM+wUYrI0 vXmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=89A+ZLrRbgJRt6TZZk9gOtuDjqGkDltWX1PRo7k7Ls8=; b=f0ZFo7r6nldJDPI1Nf09jWPuaTI7k0nlFyhOoAWbQANLTRXpw5MMGbhclWJtc7m41H UvzxESU6c7oazBqpKhHHLicVtncHkQrdRZG563Yd9E2kwqT8m2EFcmRPgvsrk2Ow8hf9 przTX4jgKJ0Z64o1dyt5A5x1Q1Rs0TN+R7dL3gNIeE0Fq6JjyKfM/JBYh2fcMUkay5lo 1+sMyL3IfYyr0POEZ2EnVLpJpmtmTtb+vryYRiNO6Jv6e7Dc0/ZNNMKQoIbQNfDkYmWb FhcThRVP8jRhlNIHwqQYbEGZX8dr5KrgN1nDUjUnzK3sLFUFIrvuPDgvxUFLvnDH3U/t HtnA== X-Gm-Message-State: AGi0PubtWrMrnNdXcWpO9+TeXJKaVqtsohtxCY/+YOcHwjEeqsWybwyG qZH2KqkRgcxLN3tKsHkuB9hoQ7mSi+Cq9dtS38A= X-Google-Smtp-Source: APiQypLRSuEqgL1vdvVxX5n7O0yC7/apK0NZYBOrkqVV+WSbP0QDswCYN3Fv7EYEiOmuzuePVb0fDlOhshBJV3D0KIM= X-Received: by 2002:aca:190e:: with SMTP id l14mr28000337oii.77.1589390960567; Wed, 13 May 2020 10:29:20 -0700 (PDT) MIME-Version: 1.0 References: <85873c75-0d4d-4ec5-91a1-a28b92378ec3@www.fastmail.com> <20200511045150.GI27494@kduck.mit.edu> In-Reply-To: From: Erik Kline Date: Wed, 13 May 2020 10:29:09 -0700 Message-ID: To: Barry Leiba Cc: Benjamin Kaduk , Martin Thomson , Rifaat Shekh-Yusef , Erik Kline , draft-ietf-capport-rfc7710bis.all@ietf.org, captive-portals , IETF SecDir Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [secdir] Fwd: [Last-Call] Secdir last call review of draft-ietf-capport-rfc7710bis-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 17:29:23 -0000 Forthwith! On Wed, May 13, 2020 at 9:29 AM Barry Leiba wrote= : > > Erik, is there a revised I-D coming for this? > > Thanks, > Barry > > On Mon, May 11, 2020 at 1:09 AM Erik Kline wrote: > > > > Gah! Sorry, I didn't mean to imply that the conversation should be > > moved there. Only pointing to text-in-progress for your review. > > > > On Sun, May 10, 2020 at 10:08 PM Erik Kline wrote: > > > > > > For the record: trying to improve text over on > > > https://github.com/capport-wg/7710bis/pull/31 . > > > > > > On Sun, May 10, 2020 at 9:52 PM Benjamin Kaduk wrote: > > > > > > > > [adding back some lists] > > > > > > > > -Ben > > > > > > > > On Wed, May 06, 2020 at 02:37:39PM +1000, Martin Thomson wrote: > > > > > What does "extra cautious" mean? I assume that this is intended = to apply to what a human might do, further implying that there is a role fo= r a human decision. > > > > > > > > > > None of this architecture requires the involvement of a human in = this way. Nor do I think that there is any meaningful distinction between a= n opaque string of characters (that might include confusables) and an opaqu= e string of digits. > > > > > > > > > > I appreciate the sentiment here, but the fundamental problem is t= hat once you decide that this information is not from the network, it is us= eless. If it is from the network, it is only of limited use. That use canno= t depend on the identity of the server, so there is no value in any sort of= caution. > > > > > > > > > > On Wed, May 6, 2020, at 13:36, Benjamin Kaduk wrote: > > > > > > [My unicast reminder got a unicast reply; forwarding to somepla= ce at least > > > > > > vaguely useful.] > > > > > > > > > > > > -Ben > > > > > > > > > > > > On Tue, May 05, 2020 at 07:57:14PM -0400, Rifaat Shekh-Yusef wr= ote: > > > > > > > Thanks for the reminder Ben. > > > > > > > > > > > > > > Erik, > > > > > > > > > > > > > > Since this document allows the use of IP address to represent= the portal > > > > > > > URI, I think it would important to add some text that explici= tly states > > > > > > > that the user might be presented with an IP address instead o= f the hostname > > > > > > > of the API, and in that case the user should be extra cautiou= s when this > > > > > > > happens. > > > > > > > > > > > > > > Regards, > > > > > > > Rifaat > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, May 5, 2020 at 7:30 PM Benjamin Kaduk = wrote: > > > > > > > > > > > > > > > Hi Rifaat, > > > > > > > > > > > > > > > > I just wanted to follow-up and check that you had received = Erik's question. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > Ben > > > > > > > > > > > > > > > > On Sun, May 03, 2020 at 02:58:29PM -0700, Erik Kline wrote: > > > > > > > > > Rifaat, > > > > > > > > > > > > > > > > > > Thanks for your reading of the document. > > > > > > > > > > > > > > > > > > The security section has a paragraph that begins: > > > > > > > > > > > > > > > > > > """ > > > > > > > > > An attacker with the ability to inject DHCP messages o= r RAs could > > > > > > > > > include an option from this document to force users to= contact an > > > > > > > > > address of his choosing. As an attacker with this cap= ability could > > > > > > > > > simply list himself as the default gateway (and so int= ercept all the > > > > > > > > > victim's traffic); this does not provide them with sig= nificantly more > > > > > > > > > capabilities, but because this document removes the ne= ed for > > > > > > > > > interception, the attacker may have an easier time per= forming the > > > > > > > > > attack... > > > > > > > > > """ > > > > > > > > > > > > > > > > > > Do you have any specific ideas for what text might be add= ed to clarify > > > > > > > > vis. > > > > > > > > > your concern? Would a sentence that captures your "the u= se of TLS and > > > > > > > > > presenting the identity in the certificate might not be o= f much help" > > > > > > > > > observation suffice? > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > -Erik > > > > > > > > > > > > > > > > > > On Fri, 1 May 2020 at 05:10, Rifaat Shekh-Yusef via Datat= racker < > > > > > > > > > noreply@ietf.org> wrote: > > > > > > > > > > > > > > > > > > > Reviewer: Rifaat Shekh-Yusef > > > > > > > > > > Review result: Has Issues > > > > > > > > > > > > > > > > > > > > Since the use of IP address literal is not forbidden by= this document, > > > > > > > > > > what if > > > > > > > > > > an attacker with the ability to inject DHCP messages or= RAs uses this > > > > > > > > > > option > > > > > > > > > > to force the user to contact an IP address of his choos= ing? In this > > > > > > > > case, > > > > > > > > > > the use > > > > > > > > > > of TLS and presenting the identity in the certificate m= ight not be of > > > > > > > > much > > > > > > > > > > help. > > > > > > > > > > > > > > > > > > > > I think this case should be discussed in the security c= onsideration > > > > > > > > > > section. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > last-call mailing list > > > > > > > > > last-call@ietf.org > > > > > > > > > https://www.ietf.org/mailman/listinfo/last-call > > > > > > > > > > > > > > > > > > > > > > From nobody Wed May 13 10:36:20 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 159B73A0C4A; Wed, 13 May 2020 10:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRLnh4_dXScW; Wed, 13 May 2020 10:36:12 -0700 (PDT) Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 049CB3A0C31; Wed, 13 May 2020 10:36:11 -0700 (PDT) Received: by mail-ot1-x32a.google.com with SMTP id k110so75293otc.2; Wed, 13 May 2020 10:36:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=J98nTqzFNnMZax/5VzMQKI30a9ZE9ixWD1qTeTRg9zg=; b=pVWkhZLdx9N0wepWSxZY3Vpw5BriyO29v6j7q9CWUUwT4Km2s89ckBfUKAyPiOG6IO c1VHZXbYOAGnoI6YkvnwE8NYb+/+5JHOZjdP+YT64C9pkMVcnYG6lPJwVeJ/lvVNpPiE WShBpaMAZA1LbgnrkqPyVY4VBqP9V6LuVQWYGU0mMIasE1pVLSsENZhyzlPoEG1kVwJr YzhX6mdAPBoCxTkYaEnvm6iEChPf8eh2shgeLtk/w3EtWiKhLTd3uyF4+1kBG8C+RvxZ W3lBjk5/04tPGE1ACJq8Li3fjPnhcy2lX3bSmCba5JG9qIGJnhvh8eHQ0rxYLx9ZCt4g s/vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=J98nTqzFNnMZax/5VzMQKI30a9ZE9ixWD1qTeTRg9zg=; b=r69EcubqqAEt2l4uJgXkuyJtEFlQR7ey1DAhLOPEJW+/o4RHyV31BfenDBW4mj6S4N Z+is04Q9cryweR/aH6IuipQx9+6kLto9Demf3XIc5m/C9UNwx7aTlEIybpGTzO+MqmD1 iL0S7OFtlG/CQg+7LE4+wrO1dgUF8qrvk6lSrMk6Hzo/uJC9oHkseF/CQaZvOJ6nniq+ J0t8X4x2+DaflctwdFYjL3DtgV7rYo9bpPHio0xVx0Y3uDZ/1NqnerXL4UMTev0HymHb U23Ki2qhhW2zBcTbomFyRKMrn4h3oo8HJCUN+ktisAgKC/0MaCNNvB1+Wl421U+KCa4Q Mf1Q== X-Gm-Message-State: AOAM531A7fo7wlhSKkydqI6b4qTqkviiJOKGyIAQwBHcTMF3hTJVuIDe j6kzZhxpnr7Wad4Gpc5ic4jYGqszG9o5/sZfejM= X-Google-Smtp-Source: ABdhPJxkxb0eL2pFu470rcAUHNQxhPTzXsOsNjCOsXF/8ZcWRmM3XjZH4+3IQh5dNagAwvOJbCPd2JSFg41L1MOdahQ= X-Received: by 2002:a9d:7988:: with SMTP id h8mr423747otm.191.1589391371107; Wed, 13 May 2020 10:36:11 -0700 (PDT) MIME-Version: 1.0 References: <85873c75-0d4d-4ec5-91a1-a28b92378ec3@www.fastmail.com> <20200511045150.GI27494@kduck.mit.edu> In-Reply-To: From: Erik Kline Date: Wed, 13 May 2020 10:36:00 -0700 Message-ID: To: Barry Leiba Cc: Benjamin Kaduk , Martin Thomson , Erik Kline , draft-ietf-capport-rfc7710bis.all@ietf.org, captive-portals , IETF SecDir Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [secdir] Fwd: [Last-Call] Secdir last call review of draft-ietf-capport-rfc7710bis-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 17:36:14 -0000 -05 uploaded, but I see now I need to do an -06 for the IANA comments. On Wed, May 13, 2020 at 10:29 AM Erik Kline wrote: > > Forthwith! > > On Wed, May 13, 2020 at 9:29 AM Barry Leiba wro= te: > > > > Erik, is there a revised I-D coming for this? > > > > Thanks, > > Barry > > > > On Mon, May 11, 2020 at 1:09 AM Erik Kline wrote: > > > > > > Gah! Sorry, I didn't mean to imply that the conversation should be > > > moved there. Only pointing to text-in-progress for your review. > > > > > > On Sun, May 10, 2020 at 10:08 PM Erik Kline wrote= : > > > > > > > > For the record: trying to improve text over on > > > > https://github.com/capport-wg/7710bis/pull/31 . > > > > > > > > On Sun, May 10, 2020 at 9:52 PM Benjamin Kaduk wrot= e: > > > > > > > > > > [adding back some lists] > > > > > > > > > > -Ben > > > > > > > > > > On Wed, May 06, 2020 at 02:37:39PM +1000, Martin Thomson wrote: > > > > > > What does "extra cautious" mean? I assume that this is intende= d to apply to what a human might do, further implying that there is a role = for a human decision. > > > > > > > > > > > > None of this architecture requires the involvement of a human i= n this way. Nor do I think that there is any meaningful distinction between= an opaque string of characters (that might include confusables) and an opa= que string of digits. > > > > > > > > > > > > I appreciate the sentiment here, but the fundamental problem is= that once you decide that this information is not from the network, it is = useless. If it is from the network, it is only of limited use. That use can= not depend on the identity of the server, so there is no value in any sort = of caution. > > > > > > > > > > > > On Wed, May 6, 2020, at 13:36, Benjamin Kaduk wrote: > > > > > > > [My unicast reminder got a unicast reply; forwarding to somep= lace at least > > > > > > > vaguely useful.] > > > > > > > > > > > > > > -Ben > > > > > > > > > > > > > > On Tue, May 05, 2020 at 07:57:14PM -0400, Rifaat Shekh-Yusef = wrote: > > > > > > > > Thanks for the reminder Ben. > > > > > > > > > > > > > > > > Erik, > > > > > > > > > > > > > > > > Since this document allows the use of IP address to represe= nt the portal > > > > > > > > URI, I think it would important to add some text that expli= citly states > > > > > > > > that the user might be presented with an IP address instead= of the hostname > > > > > > > > of the API, and in that case the user should be extra cauti= ous when this > > > > > > > > happens. > > > > > > > > > > > > > > > > Regards, > > > > > > > > Rifaat > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, May 5, 2020 at 7:30 PM Benjamin Kaduk wrote: > > > > > > > > > > > > > > > > > Hi Rifaat, > > > > > > > > > > > > > > > > > > I just wanted to follow-up and check that you had receive= d Erik's question. > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > Ben > > > > > > > > > > > > > > > > > > On Sun, May 03, 2020 at 02:58:29PM -0700, Erik Kline wrot= e: > > > > > > > > > > Rifaat, > > > > > > > > > > > > > > > > > > > > Thanks for your reading of the document. > > > > > > > > > > > > > > > > > > > > The security section has a paragraph that begins: > > > > > > > > > > > > > > > > > > > > """ > > > > > > > > > > An attacker with the ability to inject DHCP messages= or RAs could > > > > > > > > > > include an option from this document to force users = to contact an > > > > > > > > > > address of his choosing. As an attacker with this c= apability could > > > > > > > > > > simply list himself as the default gateway (and so i= ntercept all the > > > > > > > > > > victim's traffic); this does not provide them with s= ignificantly more > > > > > > > > > > capabilities, but because this document removes the = need for > > > > > > > > > > interception, the attacker may have an easier time p= erforming the > > > > > > > > > > attack... > > > > > > > > > > """ > > > > > > > > > > > > > > > > > > > > Do you have any specific ideas for what text might be a= dded to clarify > > > > > > > > > vis. > > > > > > > > > > your concern? Would a sentence that captures your "the= use of TLS and > > > > > > > > > > presenting the identity in the certificate might not be= of much help" > > > > > > > > > > observation suffice? > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > -Erik > > > > > > > > > > > > > > > > > > > > On Fri, 1 May 2020 at 05:10, Rifaat Shekh-Yusef via Dat= atracker < > > > > > > > > > > noreply@ietf.org> wrote: > > > > > > > > > > > > > > > > > > > > > Reviewer: Rifaat Shekh-Yusef > > > > > > > > > > > Review result: Has Issues > > > > > > > > > > > > > > > > > > > > > > Since the use of IP address literal is not forbidden = by this document, > > > > > > > > > > > what if > > > > > > > > > > > an attacker with the ability to inject DHCP messages = or RAs uses this > > > > > > > > > > > option > > > > > > > > > > > to force the user to contact an IP address of his cho= osing? In this > > > > > > > > > case, > > > > > > > > > > > the use > > > > > > > > > > > of TLS and presenting the identity in the certificate= might not be of > > > > > > > > > much > > > > > > > > > > > help. > > > > > > > > > > > > > > > > > > > > > > I think this case should be discussed in the security= consideration > > > > > > > > > > > section. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > last-call mailing list > > > > > > > > > > last-call@ietf.org > > > > > > > > > > https://www.ietf.org/mailman/listinfo/last-call > > > > > > > > > > > > > > > > > > > > > > > > > From nobody Wed May 13 11:50:06 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7133A07A4; Wed, 13 May 2020 11:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhWiHcrhumMR; Wed, 13 May 2020 11:49:58 -0700 (PDT) Received: from mail-io1-f48.google.com (mail-io1-f48.google.com [209.85.166.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BF5E3A07A1; Wed, 13 May 2020 11:49:58 -0700 (PDT) Received: by mail-io1-f48.google.com with SMTP id h10so176389iob.10; Wed, 13 May 2020 11:49:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0J3Ns0ZoEHHl736Awzql7PZKWXS+UBnWqZa2307j0+s=; b=KwP700JffPhyZF94bvux3mRtfb8xBiNVwB37EZapb7WXakrukBD96YWim4kooL1xcn rYXMQQzFlr9o8hVusO40LexxZSvRKKhoJPFkQW+PMmoFA9sPlHsWnEx1qLBsl5AhwhRJ DmkmJSOV/pl3h/dQdO4J2M07SGbqFEg1ni9OdD6n1y/0uhIGx65WkIKUB21fb6hanz+X t/OB/wArCwqYU49V1LLA6Y0KcdOHwH9uK/GCMne3h7MCWpiv4s/S17pwjQNuEfu0XNgM 9ou5oV1tKeVyNU+/ZgfShj7fkn7PY4V6T3tusD2rYdzA6K9dhNULugZqzCctLVQHQoJK eonQ== X-Gm-Message-State: AGi0PubHrJ4DDRXqTXSfusb5jHy1YSfs6OihJvAn3123bxLHdNAXQj1X 0RbQBDwgWnL3mULEJ5EH9oWVfwW9CW7aSKBg1Z0= X-Google-Smtp-Source: APiQypK8+u5RjlN6LO6AA6UdW8SonoiLb7zwcL1+I5uX80u37ealLdd5zchc5BIGpswpfVj+HM4SWDW3ZAkPd48TeDA= X-Received: by 2002:a02:1389:: with SMTP id 131mr922362jaz.70.1589395797195; Wed, 13 May 2020 11:49:57 -0700 (PDT) MIME-Version: 1.0 References: <85873c75-0d4d-4ec5-91a1-a28b92378ec3@www.fastmail.com> <20200511045150.GI27494@kduck.mit.edu> In-Reply-To: From: Barry Leiba Date: Wed, 13 May 2020 14:49:46 -0400 Message-ID: To: Erik Kline Cc: Benjamin Kaduk , Martin Thomson , Erik Kline , draft-ietf-capport-rfc7710bis.all@ietf.org, captive-portals , IETF SecDir Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [secdir] Fwd: [Last-Call] Secdir last call review of draft-ietf-capport-rfc7710bis-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 18:49:59 -0000 > -05 uploaded, but I see now I need to do an -06 for the IANA comments. OK... I'll wait for that. b From nobody Wed May 13 16:51:35 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1317F3A0B9D; Wed, 13 May 2020 16:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.173, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W_YljHIa2ADH; Wed, 13 May 2020 16:50:25 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640125.outbound.protection.outlook.com [40.107.64.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC1D43A09F6; Wed, 13 May 2020 16:50:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iVrHxTq4duPXT/uNMxxXdk0DBbwcqJcDSXke7aCf2QBTZpTAwVpp7SiWXrFBjOwEeRKgFoXEt3xafPIEzp3/TQ7qHIg0SZ4uBtz6Jm132uHwnGXjFPDL+e/3yBf3xN2v/YecYnyDE9Q1M6lus7gfNhLrPMmlWGSFsK3HBK9h3T9DPyB8p8/EZKE4I+aPMiCQTmXXiG+dQSvdo3hYAVy4Zpcl5ICK2XItMCA27ZbMBMVh+ifpetpMG4HdTlPX92W+K/FtaxE9SXfprkWUIkECXWzRhL65DfR4XVxAy/ABF6Aca9GTBrsBtfi8MjMSzXiG/pe5ZkiOr7k3+8LHY60n4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=th8YMG77tzFoYOMjb8M5fUg/kxOaxbjark8vxut+nLY=; b=dfQt6lec5WtG+X6PU5ybsO1EjlV7wDPCsfgWJ1A8LPUoEFNz7HBYVKvyNsEzdUskGrGlto8wAaXDZ7KvNiZaRA8NgqTgWgcQslnbsejy48SLjaqh8lsL+P/zr+BGmBJFIl1CxEQPUYDFjuaXZ3Lzu3UgHRe2RDlihgcQS5xCv7/PTRFbzSUV5K9QO9Jl+aW9WN557HJdigFCPUEf9y6UDBDSJnpJnsJWotcgAWwz7A5MBpVoTft/ZWiPnrmBLIH0QNt0hHmXBW6dIc1N/r5nD7k/zPuPpK050El2lEuxHpQBTe0nCb8fR8JrgzkA7d5KRjInssfGxTeSIB5OXB6wbQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=th8YMG77tzFoYOMjb8M5fUg/kxOaxbjark8vxut+nLY=; b=iY+cwWPQOr079iL+OxQADH0vFQ1mpMUsBwKRxUq8afGlxyH+2W29q8VVNVfLyPqtJuUjABRBwKyx33ycA6Z/EJGHl+VsKkOomuea7dLH9TfHbLugR8M1cbJc14zhpgTr4VJZw6TZlCWgscyIgcNDzinOlTF4okriOafdQmh3rcE= Received: from MN2PR00MB0686.namprd00.prod.outlook.com (10.255.224.141) by MN2PR00MB0608.namprd00.prod.outlook.com (20.179.20.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3035.0; Wed, 13 May 2020 23:50:15 +0000 Received: from MN2PR00MB0686.namprd00.prod.outlook.com ([fe80::68f6:b54c:8d5e:d283]) by MN2PR00MB0686.namprd00.prod.outlook.com ([fe80::68f6:b54c:8d5e:d283%7]) with mapi id 15.20.3035.000; Wed, 13 May 2020 23:50:15 +0000 From: Mike Jones To: Hilarie Orman , "iesg@ietf.org" , "secdir@ietf.org" CC: "draft-hodges-webauthn-registries.all@ietf.org" , Benjamin Kaduk Thread-Topic: Security review of draft-hodges-webauthn-registries-05 Thread-Index: AdYpemVKwnU29etfSlas2pmc9tnnCQ== Date: Wed, 13 May 2020 23:50:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=4b6f976c-4032-46a7-9bc8-0000cbad3e81; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-05-13T23:00:36Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: purplestreak.com; dkim=none (message not signed) header.d=none;purplestreak.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.87.252] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 2b9ae27d-691f-454f-610b-08d7f7986287 x-ms-traffictypediagnostic: MN2PR00MB0608: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0402872DA1 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: qkFVxeUGG9edBvafWsrhxBpY/LIa4N7LvjMOTL0XrQD86MwcFR+KuAtMgsyhUpxycQFiLmrHGQCnUGXrpFNycdDymQl8GCyr7s1AbHwlZlSWOLYwcqcWLOQ5rikE2T07wUSWLhbeVH3ZGgQ7GBjSN81MMZxyOrrVAAIV/c8yJSPpAMjOLd9im8nZ7ekFqTDkByKUvMjKEMrVyuhWy7zxVmR8cHhvxwuosT8Ev1Qj4/cpASyQpJfg58VzjxElCWG+Xv++r+klh8Nh6y9z7IfOfSr1z3cSwVIak40ZGJfQIyNM7nGi2g3xDv14KoiwprOE3a+Nr36VkrDlodw9nC+tGGOS4WjadAZxaV5ZN4MH3sCaXNZfen1VVXxpiWieFpLLJfMDGKZ3957U9h2PTzEiqw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR00MB0686.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(39860400002)(376002)(136003)(396003)(366004)(54906003)(82950400001)(110136005)(6506007)(33656002)(86362001)(53546011)(4326008)(5660300002)(186003)(2906002)(15650500001)(8990500004)(966005)(66556008)(76116006)(7696005)(52536014)(71200400001)(66446008)(64756008)(55016002)(8676002)(66946007)(82960400001)(66476007)(26005)(8936002)(10290500003)(9686003)(316002)(478600001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: Zlph7SQ9CO7JBHTlsGCwGTKvzxJws2ASC7a26QKPIy0mcQ726OciCkg82AczWUoMiIjzmBewGaSrDfc+R+/bCBrolYI3qHoluz+uLwNlH8gXvOOG5FHxfvv6me9O+Pp8zHvzmPbhDyjrnp7+RHuP0P5x77uVKvAlf6Muaqzgek0GnzpFtZX60k5TownMDEAnVTv5ynIz3BupSrBFbBlveIw+Q1cNE5be4i3TzJYSBnKmMJ1jZu3fpka7YYho6XpmcFoHpKKZKiMIOJvJDK5bdlMxw9n//eBZTwCQK1u58tUydwXdqUZ2erspcEd2a/LoNFYecU3YNXHuX7/WHsKR6QyHwn+Gm92ZRqlgm/cqvF9DPVTQiiRjubE1ZvxBAoKsP5nJMxXF2fQyG8IkhDmRBh07h73ggiqdMXrBn+BE14Teiy/IvOtxhzMDabVHYNOPq0q3xM0nVpAYXr3dLzIvv52ES5VFY4uslIJIjMcrhEI= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR00MB0686.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2b9ae27d-691f-454f-610b-08d7f7986287 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 May 2020 23:50:15.4412 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Q1ZBK5n1z2sMjbPINAJz7A7ZIonLgI/PyzrgVxr5umC0ERLmQqMCRNP5idsZ1z0+oEtduWBeHEpAckikdXi+mw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR00MB0608 Archived-At: Subject: Re: [secdir] Security review of draft-hodges-webauthn-registries-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 23:50:33 -0000 Thanks for the review, Hilarie. My replies are inline below, prefixed by "= Mike>". -----Original Message----- From: Hilarie Orman =20 Sent: Monday, April 27, 2020 9:42 PM To: iesg@ietf.org; secdir@ietf.org Cc: draft-hodges-webauthn-registries.all@ietf.org Subject: Security review of draft-hodges-webauthn-registries-05 Security review of Registries for Web Authentication draft-hodges-webauthn-registries-05 Do not be alarmed. I generated this review of this document as part of the= security directorate's ongoing effort to review all IETF documents being p= rocessed by the IESG. These comments were written with the intent of impro= ving security requirements and considerations in IETF drafts. Comments not= addressed in last call may be included in AD reviews during the IESG revie= w. Document editors and WG chairs should treat these comments just like an= y other last call comments. This document establishes two registries required for the W3C Web Authentic= ation system. The registries are for the WebAuthn Attestation Statement Fo= rmat Identifier and the WebAuthn Extension Identifier. When submitted, these entries must be approved by an "expert" based on the = specification that defines the parameters of the entry. This includes "sec= urity considerations", which is good. I don't quite see how submission of = a request for a new entry gets routed to an expert, how experts come into b= eing, etc., but I suppose that is a W3C procedure. A couple of nits. This url is listed twice in the URIs: https://www.iana.org/assignments/webauthn but it does not exist. I expected at least a TBD message, unless the addre= ss itself is a placeholder. Mike> The draft includes this TBD text "[[ Per discussions in an email thre= ad between the authors and IANA ( "[IANA #1154148]" ), it is requested that= the registries be located at . = RFC Editor - please delete this request after the registries have been crea= ted. ]]" before the two occurrences that you cite. In 2.1 "The Experts(s) MAY also designate attestation statement formats as proprietary if they lack complete specifications, and will assign a prefix indicating as such to the identifier." =20 It is not clear what the format of that prefix is or how indicates "as such= ". Is that an indication that it is proprietary or (and?) that it is incom= plete? Mike> The text you cited is unnecessary for the purposes of the specificat= ion and will be deleted. Hilarie Mike> You can see proposed updated source for -06 at https://github.com/w3c= /webauthn/pull/1415. Thanks again, -- Mike From nobody Thu May 14 06:43:57 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 586043A0496 for ; Thu, 14 May 2020 06:43:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.130.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <158946383494.17583.12957567959457559563@ietfa.amsl.com> Date: Thu, 14 May 2020 06:43:55 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 13:43:55 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2020-05-21 Reviewer LC end Draft Stefan Santesson 2020-05-04 draft-ietf-httpbis-header-structure-18 Tina Tsou 2020-05-08 draft-ietf-httpbis-client-hints-13 Sean Turner 2020-05-06 draft-ietf-opsawg-sdi-02 Last calls: Reviewer LC end Draft John Bradley 2020-02-28 draft-ietf-regext-data-escrow-09 Donald Eastlake R2019-11-14 draft-ietf-hip-dex-19 Donald Eastlake 2020-02-27 draft-ietf-6tisch-msf-16 Daniel Franke 2020-03-09 draft-ietf-regext-dnrd-objects-mapping-07 Russ Mundy 2020-01-02 draft-ietf-dprive-bcp-op-09 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-11 Vincent Roca 2020-04-23 draft-ietf-detnet-ip-over-mpls-06 Stefan Santesson 2020-05-04 draft-ietf-httpbis-header-structure-18 Melinda Shore 2020-05-13 draft-ietf-secevent-http-poll-09 Tina Tsou 2020-05-08 draft-ietf-httpbis-client-hints-13 Sean Turner 2020-05-19 draft-ietf-dhc-mac-assign-06 Sean Turner 2020-05-06 draft-ietf-opsawg-sdi-02 Mališa Vučinić 2020-05-27 draft-ietf-emu-eap-session-id-02 Carl Wallace 2020-05-27 draft-ietf-dhc-slap-quadrant-08 Samuel Weiler 2020-05-27 draft-ietf-cose-webauthn-algorithms-06 Brian Weis 2020-05-26 draft-ietf-cose-hash-algs-03 Klaas Wierenga 2020-05-26 draft-ietf-kitten-krb-spake-preauth-07 Christopher Wood 2020-05-25 draft-ietf-dhc-problem-statement-of-mredhcpv6-05 Paul Wouters 2020-05-25 draft-ietf-capport-architecture-08 Dacheng Zhang 2020-03-12 draft-nottingham-how-did-that-get-into-the-repo-01 Dacheng Zhang 2019-11-05 draft-ietf-mpls-ri-rsvp-frr-07 Next in the reviewer rotation: Liang Xia Dacheng Zhang Derek Atkins John Bradley Nancy Cam-Winget Shaun Cooley Alan DeKok Linda Dunbar Donald Eastlake Shawn Emery From nobody Thu May 14 10:26:04 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F5953A0BC5; Thu, 14 May 2020 10:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_BL=0.001, RCVD_IN_MSPIKE_L5=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Iytc1gn32DB; Thu, 14 May 2020 10:25:59 -0700 (PDT) Received: from out03.mta.xmission.com (out03.mta.xmission.com [166.70.13.233]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 503E93A0B66; Thu, 14 May 2020 10:25:59 -0700 (PDT) Received: from in02.mta.xmission.com ([166.70.13.52]) by out03.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jZHcK-0005BU-B7; Thu, 14 May 2020 11:25:56 -0600 Received: from [166.70.232.207] (helo=rumpleteazer.rhmr.com) by in02.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1jZHcF-00064H-6q; Thu, 14 May 2020 11:25:56 -0600 Received: from rumpleteazer.rhmr.com (localhost [127.0.0.1]) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id 04EHMmsT006250; Thu, 14 May 2020 11:22:48 -0600 Received: (from hilarie@localhost) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Submit) id 04EHMmh9006249; Thu, 14 May 2020 11:22:48 -0600 Date: Thu, 14 May 2020 11:22:48 -0600 Message-Id: <202005141722.04EHMmh9006249@rumpleteazer.rhmr.com> From: "Hilarie Orman" Reply-To: "Hilarie Orman" To: Michael.Jones@microsoft.com Cc: secdir@ietf.org, iesg@ietf.org, kaduk@mit.edu, draft-hodges-webauthn-registries.all@ietf.org X-XM-SPF: eid=1jZHcF-00064H-6q; ; ; mid=<202005141722.04EHMmh9006249@rumpleteazer.rhmr.com>; ; ; hst=in02.mta.xmission.com; ; ; ip=166.70.232.207; ; ; frm=hilarie@purplestreak.com; ; ; spf=none X-XM-AID: U2FsdGVkX18gWZ3mLH3TxAPWK/KkpwLD X-SA-Exim-Connect-IP: 166.70.232.207 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: ; sa04 0; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: **;Michael.Jones@microsoft.com X-Spam-Relay-Country: X-Spam-Timing: total 4877 ms - load_scoreonly_sql: 0.15 (0.0%), signal_user_changed: 16 (0.3%), b_tie_ro: 13 (0.3%), parse: 1.96 (0.0%), extract_message_metadata: 34 (0.7%), get_uri_detail_list: 4.4 (0.1%), tests_pri_-1000: 9 (0.2%), tests_pri_-950: 1.92 (0.0%), tests_pri_-900: 1.46 (0.0%), tests_pri_-90: 61 (1.2%), check_bayes: 59 (1.2%), b_tokenize: 11 (0.2%), b_tok_get_all: 8 (0.2%), b_comp_prob: 4.0 (0.1%), b_tok_touch_all: 31 (0.6%), b_finish: 1.28 (0.0%), tests_pri_0: 831 (17.0%), check_dkim_signature: 0.99 (0.0%), check_dkim_adsp: 175 (3.6%), poll_dns_idle: 4026 (82.5%), tests_pri_10: 2.5 (0.1%), tests_pri_500: 3914 (80.3%), rewrite_mail: 0.00 (0.0%) X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Archived-At: Subject: Re: [secdir] Security review of draft-hodges-webauthn-registries-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 17:26:02 -0000 The only nit, then, is that the URI was listed twice in section 6.2. It is listed in entry 6 and entry 9. Hilarie > Thanks for the review, Hilarie. My replies are inline below, prefixed by "Mike>". > -----Original Message----- > From: Hilarie Orman > Sent: Monday, April 27, 2020 9:42 PM > To: iesg@ietf.org; secdir@ietf.org > Cc: draft-hodges-webauthn-registries.all@ietf.org > Subject: Security review of draft-hodges-webauthn-registries-05 > Security review of Registries for Web Authentication > draft-hodges-webauthn-registries-05 > Do not be alarmed. I generated this review of this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving security requirements and considerations in IETF drafts. Comments not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. > This document establishes two registries required for the W3C Web Authentication system. The registries are for the WebAuthn Attestation Statement Format Identifier and the WebAuthn Extension Identifier. > When submitted, these entries must be approved by an "expert" based on the specification that defines the parameters of the entry. This includes "security considerations", which is good. I don't quite see how submission of a request for a new entry gets routed to an expert, how experts come into being, etc., but I suppose that is a W3C procedure. > A couple of nits. > This url is listed twice in the URIs: > https://www.iana.org/assignments/webauthn > but it does not exist. I expected at least a TBD message, unless the address itself is a placeholder. > Mike> The draft includes this TBD text "[[ Per discussions in an email thread between the authors and IANA ( "[IANA #1154148]" ), it is requested that the registries be located at . RFC Editor - please delete this request after the registries have been created. ]]" before the two occurrences that you cite. > In 2.1 > "The Experts(s) MAY also designate attestation > statement formats as proprietary if they lack complete > specifications, and will assign a prefix indicating as such to the > identifier." > It is not clear what the format of that prefix is or how indicates "as such". Is that an indication that it is proprietary or (and?) that it is incomplete? > Mike> The text you cited is unnecessary for the purposes of the specification and will be deleted. > Hilarie > Mike> You can see proposed updated source for -06 at https://github.com/w3c/webauthn/pull/1415 . > Thanks again, > -- Mike From nobody Thu May 14 11:34:20 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2B1F3A0C3D; Thu, 14 May 2020 11:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.173, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qErZj-5T_2mH; Thu, 14 May 2020 11:34:15 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650095.outbound.protection.outlook.com [40.107.65.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A090D3A0C31; Thu, 14 May 2020 11:34:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iF7WnKhVOhjSxnH8pg32QTLMWEsa6neG3ouLBJZykmFOBcaddoRyKgVhQFBzUixHk5bTzdlzBn1IAu3lY3B/wql9MzrMoMAIQhS3Sgvtj1IA6YUFmlFNol1ueAJh9XnpgsmANHaPa8d7N4D4UCUrtlWCqaJS4FAbRKSFVTYNhLeCuGaDTnXZpcPunLzujMNcaHmmJ76aQOQEzQrf3VSuQsYuiDAbw7WgGihZlXgsZ0zmmUyf202oCIKqAQxB53jz+WvJAzMD89p0P2Y2zdMT73PeSdiEvdW2EeYYyY4wLrsGDhbEO5V7Jjv12y44CSZ8bNKWcneLF70zdFax7ToP0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Qw+S3zuiA2CEJRGwyl3MZ4zMGKY9M1R4ic3vQMsCcz4=; b=OfX8Yuuz62BfhN7PZMZSSY9LsF/7Ot24EMesOiJnQha5nVvaeaQ0uGfhCBIOyFj1Fkae8JL00c711ZqpJ/awQGDw37y26WagJmOQpOgCmJGF8mHPsqbiHdd38/eOQdxAHa6Qw6HiFYl1V97ozXT39beb+W+jKYifl8dKTvCEqGS5xtfqvuewsdPm5q2C/igB7Kf+kysEU1dEiFzyuqvN8871JSTJbEk5hTzuBSnUZOmgvP2GO60pSwpGh/bdlNeNktrBhQ1N8s+BQYJx+arwbGvAanBAGxtge2nu5vYD9Z0OJZC9X/F/9fF7UKhhwqvYOJrR5HYCU5WG4mpagc2DgQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Qw+S3zuiA2CEJRGwyl3MZ4zMGKY9M1R4ic3vQMsCcz4=; b=RR+dgoJX7EJgatTvjIEOVu0YnaNr72uctzq91GvHd6MeFJ0s5anChYCzvPdGlQM+L5GvNsExY0/YRbKmQH7TWSI6Hf1XCinGmmSrLcIfJw7CFVhCwepa9X0Yf2itHApa0QBorBO9IJ485lmBeMwyufnRYjubnAmmiaDgoA76y4E= Received: from MN2PR00MB0686.namprd00.prod.outlook.com (2603:10b6:208:15f::13) by MN2PR00MB0686.namprd00.prod.outlook.com (2603:10b6:208:15f::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3035.0; Thu, 14 May 2020 18:34:13 +0000 Received: from MN2PR00MB0686.namprd00.prod.outlook.com ([fe80::68f6:b54c:8d5e:d283]) by MN2PR00MB0686.namprd00.prod.outlook.com ([fe80::68f6:b54c:8d5e:d283%7]) with mapi id 15.20.3035.000; Thu, 14 May 2020 18:34:13 +0000 From: Mike Jones To: Hilarie Orman CC: "secdir@ietf.org" , "iesg@ietf.org" , "kaduk@mit.edu" , "draft-hodges-webauthn-registries.all@ietf.org" Thread-Topic: Security review of draft-hodges-webauthn-registries-05 Thread-Index: AdYqHkFsG2+76g1QSy+zpmiy+F3B4w== Date: Thu, 14 May 2020 18:34:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=d9907e1d-532c-4c51-9840-0000bbb0c4a2; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-05-14T18:32:36Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: purplestreak.com; dkim=none (message not signed) header.d=none;purplestreak.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.87.252] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 8c47fd1e-8a6e-4342-a909-08d7f83566c1 x-ms-traffictypediagnostic: MN2PR00MB0686: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 040359335D x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: AQLv0yISkZY6K9lrP611uDVbiRUtI78K2ezEysQYFYerXOkkqLGBy/BrBP5DjxNcctqUngIUHbJ/nTwS7tAYy58Qjk8uhN3GCvnKsKnLv4pKDcHfkyDmhhwmQtRahydea2ITDkuFiUiTwwGU/+AV+qrfQC1PpRBiJ1mPpOReLc9XTKPSF33MEfkfpQkagIkSqc3U3WpLK8abJ8mSbzV1kPN7y+w15zikDLw2zwW15BOhv0iz9a38UkP78GTFpQXWCcMG9Ed+lC7Fy50Zd6MHtCyYHJ6zFToFCTp/BBveGLDUILIo6xat5ArXiINKZQSCMtlnY0j6fG7VGXtVavrYpShNRiMTQXQaR7Vxh2bxfUUP9rq+1hsiDWNQvKorqLCGrsM+XNbOf8M6/L2go2lOaQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR00MB0686.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(136003)(39860400002)(346002)(376002)(366004)(66556008)(64756008)(186003)(66476007)(15650500001)(316002)(6916009)(9686003)(66946007)(8990500004)(66446008)(55016002)(5660300002)(71200400001)(4326008)(8936002)(33656002)(2906002)(478600001)(10290500003)(54906003)(8676002)(52536014)(82950400001)(966005)(26005)(86362001)(82960400001)(6506007)(53546011)(7696005)(76116006); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: oU6HpGkS2u+akf9LhyyBHxYAXVsbdW4gbYcj9S5bZlbUCvS3oLCMje7D/ToGWr3YF8B5QM9Qe6H7a+2MriNPe96O0EBVAZVx5Uj3SVffgjLi06NInlhqH7IurPb9zdAMvAokefCjT2mAC38VVE/EPORwSXLVl5JzzRAPXOpjcdxE+qrvc6eqC02vFSaJGEoZRdmIABFNwMdkx507OlxnJP6eRroZcq+VjfTkzRAD7xiRWDckhzktwkDJq/RaN80d6lcyR34cuf4ybgDMgIdU93459cfN+ELY/CQ1+BXZ4DtbodWW/pwctEhshSQXT5yQeWzVYRdcK9v4R+I7AavrzBKnqvDa3St+/wXXTYApEFI3KS2xYo10jnBIyto7iInkgxmbrycMWdw8VZOkGdVbPLjUVlwnbCsYAjZDIn4l2msTxyYqOi2UkFGwNSxGdRrNDi63zBtQaPi2I0c3gOks8o8BRhB+R6nS1NMje2KaNKQ= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR00MB0686.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8c47fd1e-8a6e-4342-a909-08d7f83566c1 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 May 2020 18:34:13.6271 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: wGLqIy7TkiUTjZKVERA9/DHMgzq8b77T2nbltQYBV0OwmxXZqjsf8XFrBpphjm7Z0Ijo8DO87A4BkvxjSZAFpw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR00MB0686 Archived-At: Subject: Re: [secdir] Security review of draft-hodges-webauthn-registries-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 18:34:18 -0000 Oh, I see what you mean now. I didn't realize that the tool wouldn't coale= sce multiple instances of the same URI to a single reference. I'll do some= thing to eliminate the duplication now. Thanks again, -- Mike -----Original Message----- From: Hilarie Orman =20 Sent: Thursday, May 14, 2020 10:23 AM To: Mike Jones Cc: secdir@ietf.org; iesg@ietf.org; kaduk@mit.edu; draft-hodges-webauthn-re= gistries.all@ietf.org Subject: RE: Security review of draft-hodges-webauthn-registries-05 The only nit, then, is that the URI was listed twice in section 6.2. It is= listed in entry 6 and entry 9. Hilarie > Thanks for the review, Hilarie. My replies are inline below, prefixed b= y "Mike>". > -----Original Message----- > From: Hilarie Orman > Sent: Monday, April 27, 2020 9:42 PM > To: iesg@ietf.org; secdir@ietf.org > Cc: draft-hodges-webauthn-registries.all@ietf.org > Subject: Security review of draft-hodges-webauthn-registries-05 > Security review of Registries for Web Authentication > draft-hodges-webauthn-registries-05 > Do not be alarmed. I generated this review of this document as part of = the security directorate's ongoing effort to review all IETF documents bein= g processed by the IESG. These comments were written with the intent of im= proving security requirements and considerations in IETF drafts. Comments = not addressed in last call may be included in AD reviews during the IESG re= view. Document editors and WG chairs should treat these comments just like= any other last call comments. > This document establishes two registries required for the W3C Web Authen= tication system. The registries are for the WebAuthn Attestation Statement= Format Identifier and the WebAuthn Extension Identifier. > When submitted, these entries must be approved by an "expert" based on t= he specification that defines the parameters of the entry. This includes "= security considerations", which is good. I don't quite see how submission = of a request for a new entry gets routed to an expert, how experts come int= o being, etc., but I suppose that is a W3C procedure. > A couple of nits. > This url is listed twice in the URIs: > https://www.iana.org/assignments/webauthn > but it does not exist. I expected at least a TBD message, unless the ad= dress itself is a placeholder. > Mike> The draft includes this TBD text "[[ Per discussions in an email t= hread between the authors and IANA ( "[IANA #1154148]" ), it is requested t= hat the registries be located at . RFC Editor - please delete this request after the registries have been c= reated. ]]" before the two occurrences that you cite. > In 2.1 > "The Experts(s) MAY also designate attestation > statement formats as proprietary if they lack complete > specifications, and will assign a prefix indicating as such to the > identifier." =20 > It is not clear what the format of that prefix is or how indicates "as s= uch". Is that an indication that it is proprietary or (and?) that it is in= complete? > Mike> The text you cited is unnecessary for the purposes of the specifi= cation and will be deleted. > Hilarie > Mike> You can see proposed updated source for -06 at https://github.com/= w3c/webauthn/pull/1415 . > Thanks again, > -- Mike From nobody Thu May 14 13:43:49 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2827D3A0D2B; Thu, 14 May 2020 13:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.173, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEZnaNV0oBUf; Thu, 14 May 2020 13:43:31 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640121.outbound.protection.outlook.com [40.107.64.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 525CC3A0D46; Thu, 14 May 2020 13:43:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AW//4bVk9r2760Vr6CviD4vk5f8ImX0IZW4oaaoIKKtINzrKQlfFVbfrm/0+VWvV+mzoEF+whfRFieYx58bRU5ngRC3hBKTx9ywgQrhEftvI/3fnp/69kXweUR7ev3vwsNFddd1LpXPUGGXcfSbbDLVJYiq3zxpG6Ogyys8LDDYoHLxfVT4iN/uDp8AonaeR7zmNWY9nM97lyIhv2re+vx9/X3zybZbTsDbdLN/r77Ua8eqla7J9SLLm5H5oCwnPx/z3K50BRnflKLQY3n9w5UeMzsiw8q68/h/ZPTcDau9QiePCXE88WJzACMkop2WvKnGs8bD+KdxI08MP1wYVCA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oMQdts5wiZks8Tx3sAYL0t7rXP8bIup82xxB/QAKK50=; b=QKeFjNWGItrjNEPq6K4rnOhj9NHjFH6/0j+LrEJ04VHPvPtGLHdQNtL701HGuceKMs/C2vfeQv61YFa0Fzqk1S4gCnRHmnI1L774oRxvY2Us9t8xYdjQCeFINl5aQ0ptEy9gvVGraGa1uFc7r8jyZa+/Ov7VCbIX6gAdwmjOklMMxVhSEST5meB21/6ENqCcW2nn1sO8Bx9oPDgCOV+yhfzy21k8b24Et4QFHb1Cxa8Ugt+/5UoAs6nTKPvCSkoYkxgUFPChxaVTzG/LQdG2+AzlvzWBGsxW0xJA7NgHKePGMcVEwuIBCGsXlmzs77u9Kg7WEvmp4ae7ltbf5bYp/w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oMQdts5wiZks8Tx3sAYL0t7rXP8bIup82xxB/QAKK50=; b=NuANCocQeqy3iABvgv44MxnOrsM+QPpf5Uvn7T4Npc++MoL0YphwuIxmE5p9ovXN7J7j1PIn7cx0zCQTNOpX5wdoUx0xFPHBcDfQgFAR1fCZ2l7d9jZrYR+4UjnRawmpkom9oEuAhx8XGZnhGMNfWTn3fceM+tko1yUYIMgLWxI= Received: from MN2PR00MB0686.namprd00.prod.outlook.com (2603:10b6:208:15f::13) by MN2PR00MB0461.namprd00.prod.outlook.com (2603:10b6:208:c2::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3043.0; Thu, 14 May 2020 20:43:29 +0000 Received: from MN2PR00MB0686.namprd00.prod.outlook.com ([fe80::68f6:b54c:8d5e:d283]) by MN2PR00MB0686.namprd00.prod.outlook.com ([fe80::68f6:b54c:8d5e:d283%7]) with mapi id 15.20.3035.000; Thu, 14 May 2020 20:43:29 +0000 From: Mike Jones To: Hilarie Orman , "kaduk@mit.edu" CC: "secdir@ietf.org" , "iesg@ietf.org" , "draft-hodges-webauthn-registries.all@ietf.org" Thread-Topic: Security review of draft-hodges-webauthn-registries-05 Thread-Index: AdYqHkFsG2+76g1QSy+zpmiy+F3B4wAEYFCw Date: Thu, 14 May 2020 20:43:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=d9907e1d-532c-4c51-9840-0000bbb0c4a2; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-05-14T18:32:36Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: purplestreak.com; dkim=none (message not signed) header.d=none;purplestreak.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.87.252] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 8391ff0e-4c07-4473-4f04-08d7f8477572 x-ms-traffictypediagnostic: MN2PR00MB0461: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 040359335D x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: nTUF7ZywzhJVgZHpkQcWTAf+xzOMZsDqR3vSRvYGYiljSd/PEFRC0ENjtlS/9YvKTd8HP7n9oWkmrXTZW8zMO6tQqL0QiiI7zLl9LqGNnkX+hfPwzesRTsLHKZ70sTroWar8rFaijhtTgy+6m4I2yb1565kqZfdA1aShO6jCtzaN64oL7UNCxYP2rYzMF5m07obgrXFMtPA4KfWs9fRcLFQavdbA+j7iFzYDzuYOiAPtEZ2UE9ak0L9t4V0xRNxzvM5RTU3acZu53wXgZ0RmIC0xZbbqxG10ig545G5LyIq4UikF6tfQP7z8Hd0KxfeYEGB+9v98WWG5/vhiF5WNRIGN/NulUr12R+299gG+58G+BMi5hYizbUS2lTM5U70UPzFTv2uDoVFW3xLVyJWFoA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR00MB0686.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(376002)(366004)(39860400002)(136003)(396003)(7696005)(66556008)(64756008)(66946007)(66446008)(66476007)(54906003)(71200400001)(8936002)(6506007)(53546011)(8676002)(110136005)(316002)(33656002)(4326008)(76116006)(15650500001)(8990500004)(478600001)(55016002)(186003)(966005)(82960400001)(82950400001)(2906002)(9686003)(52536014)(2940100002)(26005)(86362001)(5660300002)(10290500003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: PMNM+Sgn2Fyr4jlPC/QK7gHozof0mwFT/iA/4m+NmF7xkeOqnI7CN7M+sCX2ZbhwoTsoMXYtbJGxHeON9Ao9+ystVGkVrjkxzqBxcpz2OOzXr7x4rhCwLLu3ixI5s1/Yy6sBHEZCKLtoRrU3v7hr4DjMmQUrwUqIhqZ0ItkxM2xofctLzfNq7rnO8q0MV+/s4SKN8NqLXLeBobJU3G+ZpCiCfpEykfZGz25+fFfbULYoFYa1EI8L5cbDXJXfk9AidPF9yJ5haZMIY0jC7s7N1jG+Q725uHPsIDzcyO5PqpFBc+jnYY/UyKKVwEoT1X6RfajFofKstfNGjLx2F/SAPBGY4XwU/tU+1zXS0H3wq1b6Q88fBFqqwQxehMiF4p7+GRHD4JZgFq0ouSPBd/qGtzYm88sgrGOMhP4n0N13b8692wJdLaKN2noN0Ejfe2N/6oVvTV4FVm0mBF5Mxe8GrX1kdv7M3pDyrts9xq+VodA= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR00MB0686.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8391ff0e-4c07-4473-4f04-08d7f8477572 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 May 2020 20:43:29.2170 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: qQ5iOeU83SUSysMDHcVmVfn6hb6oHzt3awykmI3uYCbpv/DJ20smz9Akxo1slFNobCHn2WTVnZ9n6CGVQtQQ2w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR00MB0461 Archived-At: Subject: Re: [secdir] Security review of draft-hodges-webauthn-registries-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 20:43:42 -0000 The duplicate URI has been removed from https://tools.ietf.org/html/draft-h= odges-webauthn-registries-07#section-6.2. We should be good to go now! Thanks again, -- Mike -----Original Message----- From: Mike Jones=20 Sent: Thursday, May 14, 2020 11:34 AM To: Hilarie Orman Cc: secdir@ietf.org; iesg@ietf.org; kaduk@mit.edu; draft-hodges-webauthn-re= gistries.all@ietf.org Subject: RE: Security review of draft-hodges-webauthn-registries-05 Oh, I see what you mean now. I didn't realize that the tool wouldn't coale= sce multiple instances of the same URI to a single reference. I'll do some= thing to eliminate the duplication now. Thanks again, -- Mike -----Original Message----- From: Hilarie Orman =20 Sent: Thursday, May 14, 2020 10:23 AM To: Mike Jones Cc: secdir@ietf.org; iesg@ietf.org; kaduk@mit.edu; draft-hodges-webauthn-re= gistries.all@ietf.org Subject: RE: Security review of draft-hodges-webauthn-registries-05 The only nit, then, is that the URI was listed twice in section 6.2. It is= listed in entry 6 and entry 9. Hilarie > Thanks for the review, Hilarie. My replies are inline below, prefixed b= y "Mike>". > -----Original Message----- > From: Hilarie Orman > Sent: Monday, April 27, 2020 9:42 PM > To: iesg@ietf.org; secdir@ietf.org > Cc: draft-hodges-webauthn-registries.all@ietf.org > Subject: Security review of draft-hodges-webauthn-registries-05 > Security review of Registries for Web Authentication > draft-hodges-webauthn-registries-05 > Do not be alarmed. I generated this review of this document as part of = the security directorate's ongoing effort to review all IETF documents bein= g processed by the IESG. These comments were written with the intent of im= proving security requirements and considerations in IETF drafts. Comments = not addressed in last call may be included in AD reviews during the IESG re= view. Document editors and WG chairs should treat these comments just like= any other last call comments. > This document establishes two registries required for the W3C Web Authen= tication system. The registries are for the WebAuthn Attestation Statement= Format Identifier and the WebAuthn Extension Identifier. > When submitted, these entries must be approved by an "expert" based on t= he specification that defines the parameters of the entry. This includes "= security considerations", which is good. I don't quite see how submission = of a request for a new entry gets routed to an expert, how experts come int= o being, etc., but I suppose that is a W3C procedure. > A couple of nits. > This url is listed twice in the URIs: > https://www.iana.org/assignments/webauthn > but it does not exist. I expected at least a TBD message, unless the ad= dress itself is a placeholder. > Mike> The draft includes this TBD text "[[ Per discussions in an email t= hread between the authors and IANA ( "[IANA #1154148]" ), it is requested t= hat the registries be located at . RFC Editor - please delete this request after the registries have been c= reated. ]]" before the two occurrences that you cite. > In 2.1 > "The Experts(s) MAY also designate attestation > statement formats as proprietary if they lack complete > specifications, and will assign a prefix indicating as such to the > identifier." =20 > It is not clear what the format of that prefix is or how indicates "as s= uch". Is that an indication that it is proprietary or (and?) that it is in= complete? > Mike> The text you cited is unnecessary for the purposes of the specifi= cation and will be deleted. > Hilarie > Mike> You can see proposed updated source for -06 at https://github.com/= w3c/webauthn/pull/1415 . > Thanks again, > -- Mike From nobody Fri May 15 05:47:53 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBB513A09BB for ; Fri, 15 May 2020 05:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMHdn1Q2Huah for ; Fri, 15 May 2020 05:47:50 -0700 (PDT) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0FEF3A09BA for ; Fri, 15 May 2020 05:47:49 -0700 (PDT) Received: by mail-wr1-x431.google.com with SMTP id y3so3446932wrt.1 for ; Fri, 15 May 2020 05:47:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=ldSjzE6+Dsd2nJ/8CBkA7P2kfg4JEv/ZNiQ2LAgt3Ws=; b=tfSENlAHMFKWuyjYzRCLounfbLsKoH6ThBYuS2JlrRI1GTZuv7D0m/K1/mY+0fkXa7 oaIWcelM2kUOaRfdhs3JL6OBpBYGuQNiHfxmDbgEj2BhNg4BKR64mjMA6qmoCqrqal8u YhZKt74PQIeXm5rilVHL+qX4KySOrnpK/+8IjWWGrxTSuLLC4z84mbhWMGuDrZAtGVku BMffh9byBo4mu5YC1t0uO6DFayouU7VljbM21LQXMKVMhDwTVSPpBuKHfiufTBUCouDU Zc+ZokBb2av/HvD0x+h+YMZFc2g7RJpFWJ/xXo/gJD9xL5bVMpV9WRnoN8ShSaRDYNpn mPvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ldSjzE6+Dsd2nJ/8CBkA7P2kfg4JEv/ZNiQ2LAgt3Ws=; b=gR+nub6FuHhHjIGbzKsK+1E6XctdmWwEwGyUMQXw3XgSKxQtKldsEEzVt5olqmnFnt WJjFUKxElKY3JdNxy6gib8eHixA5tyGxahO+bSGRzpwzOUqoY4+fSEFsPE4ARxNE0P2j yqgTkl5AFRcIcqzhJasbdUBvY6WfWIaZZKJ7fvXWyss9g2d2cj7E8ckeNLcwPd4cOOr/ +XeFeNnQQPQUuJSSuCqqZrahjxHeODuXLboV948NMhNMA5Th0vyttMe+1aZah9r9JZ4q WYQZwAdTytr3u9dMbewwbDvh+6LHgVSiSS9CoPYf0W9ahYCyb4RLdX4rZh2nGOwYUnAl lAEw== X-Gm-Message-State: AOAM5301KYMyHhIJDecgC3mtTD4oK47XbFnCFxXs49hzWODW+//sOJkS sZ/XKLVUoX7tzT2uhyJr+Xcnu+3M0jjXNJyxo41f7WwjuLw= X-Google-Smtp-Source: ABdhPJz0HR74OCKKOvVBO3py0Jgmf2rOrJO4FpNkTgk1JLiNT1XtO8v7l043QuZjitVp94RrsVLURipPSQrflgF8FkY= X-Received: by 2002:adf:dc89:: with SMTP id r9mr3909112wrj.138.1589546867686; Fri, 15 May 2020 05:47:47 -0700 (PDT) MIME-Version: 1.0 From: Rifaat Shekh-Yusef Date: Fri, 15 May 2020 08:47:37 -0400 Message-ID: To: secdir@ietf.org Content-Type: multipart/alternative; boundary="00000000000067022305a5af38f6" Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-capport-rfc7710bis-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 12:47:52 -0000 --00000000000067022305a5af38f6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Martin, Sorry, I missed this message as I changed email address because some spammers have been sending spams with my email address as a sender, and as a result I would get angry emails from the spam targets. Here is a quote form the API document: "The hostname of the API SHOULD be displayed to the user in order to indicate the entity which is providing the API service." This seems to suggest that the user is expected to inspect the displayed name and make sure it is make sense in the context of whoever is providing that service. Here is a quote from this document: "An attacker with the ability to inject DHCP messages or RAs could include an option from this document to force users to contact an address of his choosing. As an attacker with this capability could simply list himself as the default gateway (and so intercept all the victim's traffic); this does not provide them with significantly more capabilities, *but because this document removes the need for interception, the attacker may have an easier time performing the attack*." Since this would be an easier attack compared to the interception attack, and IP address is still permitted, then an attacker might force the use of IP address to make it harder for the user to make sense of the displayed name. Regards, Rifaat [adding back some lists] -Ben On Wed, May 06, 2020 at 02:37:39PM +1000, Martin Thomson wrote: > What does "extra cautious" mean? I assume that this is intended to apply= to what a human might do, further implying that there is a role for a huma= n decision. > > None of this architecture requires the involvement of a human in this way= . Nor do I think that there is any meaningful distinction between an opaque= string of characters (that might include confusables) and an opaque string= of digits. > > I appreciate the sentiment here, but the fundamental problem is that once= you decide that this information is not from the network, it is useless. I= f it is from the network, it is only of limited use. That use cannot depend= on the identity of the server, so there is no value in any sort of caution= . > > On Wed, May 6, 2020, at 13:36, Benjamin Kaduk wrote: > > [My unicast reminder got a unicast reply; forwarding to someplace at le= ast > > vaguely useful.] > > > > -Ben > > > > On Tue, May 05, 2020 at 07:57:14PM -0400, Rifaat Shekh-Yusef wrote: > > > Thanks for the reminder Ben. > > > > > > Erik, > > > > > > Since this document allows the use of IP address to represent the por= tal > > > URI, I think it would important to add some text that explicitly stat= es > > > that the user might be presented with an IP address instead of the ho= stname > > > of the API, and in that case the user should be extra cautious when t= his > > > happens. > > > > > > Regards, > > > Rifaat --00000000000067022305a5af38f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0 Martin,

Sorry, = I missed this message as I changed email address because=C2=A0some spammers= have been sending spams with my email address as a sender, and as a result= =C2=A0I would get angry emails from the spam targets.

<= div>

Here is a quote form the API document:
<= div>"The hostname= of the API SHOULD be displayed to the user in order to indicate the entity= which is providing the API=C2=A0service."

This seems to s= uggest that the user is expected to inspect=C2=A0the displayed name and mak= e sure it is make sense in the context of whoever is providing that service= .=C2=A0=C2=A0


Here is a quote f= rom this document:
"An attacker with the ability to inject DHCP messages or RA= s could
   include an option from this document to force users to contact an
   address of his choosing.  As an attacker with this capability could
   simply list himself as the default gateway (and so intercept all the
   victim's traffic); this does not provide them with significantly mor=
e
   capabilities, but because this document removes the need for
   interception, the attacker may have an easier time performing the
   attack."

Since this would be an = easier attack compared to the interception attack, and IP address is still = permitted, then an attacker might force the use of IP address to make it ha= rder for the user to make sense of the displayed name.

Regards,
=C2=A0Rifaat

[adding back some lists]

-Ben

On Wed, May 06, 2020 at 02:37:39PM +1000, Martin Thomson wrote:
> What does "extra cautious" mean?  I assume that this is inte=
nded to apply to what a human might do, further implying that there is a ro=
le for a human decision.=20
>=20
> None of this architecture requires the involvement of a human in this =
way. Nor do I think that there is any meaningful distinction between an opa=
que string of characters (that might include confusables) and an opaque str=
ing of digits.
>=20
> I appreciate the sentiment here, but the fundamental problem is that o=
nce you decide that this information is not from the network, it is useless=
. If it is from the network, it is only of limited use. That use cannot dep=
end on the identity of the server, so there is no value in any sort of caut=
ion.
>=20
> On Wed, May 6, 2020, at 13:36, Benjamin Kaduk wrote:
> > [My unicast reminder got a unicast reply; forwarding to someplace=
 at least
> > vaguely useful.]
> >=20
> > -Ben
> >=20
> > On Tue, May 05, 2020 at 07:57:14PM -0400, Rifaat Shekh-Yusef wrot=
e:
> > > Thanks for the reminder Ben.
> > >=20
> > > Erik,
> > >=20
> > > Since this document allows the use of IP address to represen=
t the portal
> > > URI, I think it would important to add some text that explic=
itly states
> > > that the user might be presented with an IP address instead =
of the hostname
> > > of the API, and in that case the user should be extra cautio=
us when this
> > > happens.
> > >=20
> > > Regards,
> > >  Rifaat


--00000000000067022305a5af38f6-- From nobody Sat May 16 09:50:45 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE1753A0941 for ; Sat, 16 May 2020 09:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsAf0ntk-ZsI for ; Sat, 16 May 2020 09:50:41 -0700 (PDT) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4494A3A0940 for ; Sat, 16 May 2020 09:50:41 -0700 (PDT) Received: by mail-wm1-x32c.google.com with SMTP id m185so915281wme.3 for ; Sat, 16 May 2020 09:50:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=SBfB/vnnqeFl7yKOlhHI9G6bfAfUJRUeHTqIYGqTjgg=; b=b9WDO21SxaFu/ArBXZ+XOE6CTtTtk8/9M5K3V0OTBZ3UgcvZSh7XgLhB4OXcuMWjaJ f2+oepZu9ECcfb3bAJ0r719fBEuFVV6g4/HWrWS5gimWlOjEpKztzBvGllT5c/hsnrx1 07uz+VFKrcNUJzZkDlloIKQMmvdBeFkE3o1nCcHh3Tw8mfYDPccrEFFF/h2uLtPgLBmY 9jqYLp3GtXNRIELtrqWWduecmK120rOn9aziBt8j/WYQ/xlDLvgainZ9Ae893ZbskIDw 52Pdk1duxJuDKQxdUGEaWKRv8UOVQ2kwa3yAuTrL5dhSVi3BLmeDNGF0zSo7CKqiY51r etCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=SBfB/vnnqeFl7yKOlhHI9G6bfAfUJRUeHTqIYGqTjgg=; b=UPtGDtliJWDBAeTJ0vXSpQ83/K7o97UrW0aUpoyM/M4uz5EjRc23SG+IWRv4/OYRAJ 296chxjUwy3ePNoQk0VzGaceXfeWk78bfEvAcJWQ0UCvm7RM5hLbDR/z0rrNc4dmIi+q lY3K6BLrlSL4TtBB/TqSIIGxsWKB1YRpQ7QM52UvNVBkz8vrTzzmInAILdyhEaCA7R5S 1mfvjYc0WFluEFxXzoqC2IG7aTOqqGB9MISCAlR6IMtdYJ/P79U+XtOULce2ebXbWGT8 xwmXmxUg+rA6AVfDR2156zhCBCGnOUYTIanTRZgWvEKWOQhicnN34TOT+NXz5oyudllE 0hsw== X-Gm-Message-State: AOAM53144l8FzPkKREBqYgZy9XtbocL/+ByBFQoVdvef4nYx8bV/c/Cp fje1rv0Mvq36ZL+m7ReTDGmLqEV2Nhj5vdVeXloE+DvY X-Google-Smtp-Source: ABdhPJy+qgO24U0n6H3FDLaRG55eJheXcp5fIhzks2LPbONKyk5BHNnawJyQt+u+HeOjBHKhhmBaNFaEsV/ykAM1mgA= X-Received: by 2002:a05:600c:231a:: with SMTP id 26mr10558872wmo.59.1589647839240; Sat, 16 May 2020 09:50:39 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rifaat Shekh-Yusef Date: Sat, 16 May 2020 12:50:28 -0400 Message-ID: To: secdir@ietf.org, mt@lowentropy.net Content-Type: multipart/alternative; boundary="000000000000c6a63305a5c6ba51" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-capport-rfc7710bis-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2020 16:50:43 -0000 --000000000000c6a63305a5c6ba51 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Adding Martin. On Fri, May 15, 2020 at 8:47 AM Rifaat Shekh-Yusef wrote: > Hi Martin, > > Sorry, I missed this message as I changed email address because some > spammers have been sending spams with my email address as a sender, and a= s > a result I would get angry emails from the spam targets. > > > Here is a quote form the API document: > "The hostname of the API SHOULD be displayed to the user in order to > indicate the entity which is providing the API service." > > This seems to suggest that the user is expected to inspect the displayed > name and make sure it is make sense in the context of whoever is providin= g > that service. > > > Here is a quote from this document: > "An attacker with the ability to inject DHCP messages or RAs could > > include an option from this document to force users to contact an > address of his choosing. As an attacker with this capability could > simply list himself as the default gateway (and so intercept all the > victim's traffic); this does not provide them with significantly more > capabilities, *but because this document removes the need for > interception, the attacker may have an easier time performing the > attack*." > > > Since this would be an easier attack compared to the interception attack, > and IP address is still permitted, then an attacker might force the use o= f > IP address to make it harder for the user to make sense of the displayed > name. > > Regards, > Rifaat > > [adding back some lists] > > -Ben > > On Wed, May 06, 2020 at 02:37:39PM +1000, Martin Thomson wrote: > > What does "extra cautious" mean? I assume that this is intended to app= ly to what a human might do, further implying that there is a role for a hu= man decision. > > > > None of this architecture requires the involvement of a human in this w= ay. Nor do I think that there is any meaningful distinction between an opaq= ue string of characters (that might include confusables) and an opaque stri= ng of digits. > > > > I appreciate the sentiment here, but the fundamental problem is that on= ce you decide that this information is not from the network, it is useless.= If it is from the network, it is only of limited use. That use cannot depe= nd on the identity of the server, so there is no value in any sort of cauti= on. > > > > On Wed, May 6, 2020, at 13:36, Benjamin Kaduk wrote: > > > [My unicast reminder got a unicast reply; forwarding to someplace at = least > > > vaguely useful.] > > > > > > -Ben > > > > > > On Tue, May 05, 2020 at 07:57:14PM -0400, Rifaat Shekh-Yusef wrote: > > > > Thanks for the reminder Ben. > > > > > > > > Erik, > > > > > > > > Since this document allows the use of IP address to represent the p= ortal > > > > URI, I think it would important to add some text that explicitly st= ates > > > > that the user might be presented with an IP address instead of the = hostname > > > > of the API, and in that case the user should be extra cautious when= this > > > > happens. > > > > > > > > Regards, > > > > Rifaat > > > > --000000000000c6a63305a5c6ba51 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Adding Martin.

On Fri, May 15, = 2020 at 8:47 AM Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com> wrote:
Hi=C2=A0 Martin,

Sorry, I missed this message as I changed email addr= ess because=C2=A0some spammers have been sending spams with my email addres= s as a sender, and as a result=C2=A0I would get angry emails from the spam = targets.


Here is a quote= form the API document:
"The hostname of the API SHOULD be displayed to the user i= n order to indicate the entity which is providing the API=C2=A0service."
=
This seems to suggest that the user is expected to inspect= =C2=A0the displayed name and make sure it is make sense in the context of w= hoever is providing that service.=C2=A0=C2=A0

=
Here is a quote from this document:
"An attacker with the abili= ty to inject DHCP messages or RAs could
   include an option from this document to force users to con=
tact an
   address of his choosing.  As an attacker with this capability could
   simply list himself as the default gateway (and so intercept all the
   victim's traffic); this does not provide them with significantly mor=
e
   capabilities, but because this document removes the need for
   interception, the attacker may have an easier time performing the
   attack."

Since this would be an = easier attack compared to the interception attack, and IP address is still = permitted, then an attacker might force the use of IP address to make it ha= rder for the user to make sense of the displayed name.

Regards,
=C2=A0Rifaat

[adding back some lists]

-Ben

On Wed, May 06, 2020 at 02:37:39PM +1000, Martin Thomson wrote:
> What does "extra cautious" mean?  I assume that this is inte=
nded to apply to what a human might do, further implying that there is a ro=
le for a human decision.=20
>=20
> None of this architecture requires the involvement of a human in this =
way. Nor do I think that there is any meaningful distinction between an opa=
que string of characters (that might include confusables) and an opaque str=
ing of digits.
>=20
> I appreciate the sentiment here, but the fundamental problem is that o=
nce you decide that this information is not from the network, it is useless=
. If it is from the network, it is only of limited use. That use cannot dep=
end on the identity of the server, so there is no value in any sort of caut=
ion.
>=20
> On Wed, May 6, 2020, at 13:36, Benjamin Kaduk wrote:
> > [My unicast reminder got a unicast reply; forwarding to someplace=
 at least
> > vaguely useful.]
> >=20
> > -Ben
> >=20
> > On Tue, May 05, 2020 at 07:57:14PM -0400, Rifaat Shekh-Yusef wrot=
e:
> > > Thanks for the reminder Ben.
> > >=20
> > > Erik,
> > >=20
> > > Since this document allows the use of IP address to represen=
t the portal
> > > URI, I think it would important to add some text that explic=
itly states
> > > that the user might be presented with an IP address instead =
of the hostname
> > > of the API, and in that case the user should be extra cautio=
us when this
> > > happens.
> > >=20
> > > Regards,
> > >  Rifaat


--000000000000c6a63305a5c6ba51-- From nobody Sun May 17 18:26:55 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B664D3A0437; Sun, 17 May 2020 18:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=o26GLmiM; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=i2fnnR4G Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CaG3ApcTwN88; Sun, 17 May 2020 18:26:49 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBCA53A0442; Sun, 17 May 2020 18:26:48 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 7085C5C0042; Sun, 17 May 2020 21:26:47 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Sun, 17 May 2020 21:26:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm2; bh=jcPdFnvYWfIVB0/WvFKgu8lHQ0Bp jiBqm2FxX0ZMBSw=; b=o26GLmiMLsDgXmjEcbXJ9Zc5RSuNqA6NEFkATjD6p7Iv xMWotiO+/T6nirUDswtXj0CBUtWRcYJRF0YJbmjKYuOi8yBIt1iCwUOGhUPD8Ge7 RXsiLdK8ookuFuAbRph+Rs97QQRKAXwiD3PHLpWwgh0VFrxayY0yWHtvwjVS1pR0 ZLvslOEjmrm+3fGWbgDkri2IeFljGVhdbGeI5ZxyKeErGQYa3QGOJtJQ112HQDdo x1hw4cpF3KrvcsyTIcvwxP4CSzXQJIWKVAxBXZZX469PAsI+XYgsqCNbBmbt98dB /IyQ9gQtQY1I4Ifuy5Oa8CY4tvQEaPy3Gaf4pn62/A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=jcPdFn vYWfIVB0/WvFKgu8lHQ0BpjiBqm2FxX0ZMBSw=; b=i2fnnR4GMbVpUBLx5ewwu/ vCQCEZzI3cfC7q3a3RSpNbKv5XTX79fh1E+FleN/KupnYEbDasLKHBMg1iM9hD48 SC/sjcOU/r8OoRMfu0uTihmP8pChIvVa0XUKUOC4+U1DtJftmXnWtoCwYulQ2ylt QdnijwXHtzr9wEcagMqHZ2wq1nUiWLcDmYQwitXyMsonyGdwRVPYrWXhHr22wt9d i06a/12aiKBIfr9iSRDGgmHNAVSejtasyvHkZnP84OF2tJGI4vIJ814gX/gXV9Wo Q48ls7Sy9/OuwbFMZIPM8LjKKVLfbwcQMqnGWTgRV0WC2ENV/wmCyQSsQCnrt8vw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddtgedggeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpedtfeekvdfhtddvleegtd fffffgudfgudeftdfhueejuedtleefueevgfeluddtheenucffohhmrghinhepvgigrghm phhlvgdrtghomhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehmtheslhhofigvnhhtrhhophihrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 17814E00B3; Sun, 17 May 2020 21:26:47 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-413-g750b809-fmstable-20200507v1 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 18 May 2020 11:26:29 +1000 From: "Martin Thomson" To: "Rifaat Shekh-Yusef" , secdir@ietf.org Cc: captive-portals@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-capport-rfc7710bis-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2020 01:26:51 -0000 Adding more lists. On Sun, May 17, 2020, at 02:50, Rifaat Shekh-Yusef wrote: > > Here is a quote form the API document: > > "The hostname of the API SHOULD be displayed to the user in order to indicate the entity which is providing the API service." > > > > This seems to suggest that the user is expected to inspect the displayed name and make sure it is make sense in the context of whoever is providing that service. I don't think that is the case. If this were a security mechanism, then it would use "MUST". This is likely for the purpose of enabling some sort of accountability. In other words, this is to offer maximal information about what is going on. > > Since this would be an easier attack compared to the interception attack, and IP address is still permitted, then an attacker might force the use of IP address to make it harder for the user to make sense of the displayed name. I don't think that is materially different than getting a name with confusable characters (or using the prefix hack, example.com..example, in an attempt to confuse). From nobody Mon May 18 14:09:02 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D08AE3A0D3D; Mon, 18 May 2020 14:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BC4dBomdFHo7; Mon, 18 May 2020 14:08:53 -0700 (PDT) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F01ED3A0D19; Mon, 18 May 2020 14:08:52 -0700 (PDT) Received: by mail-wr1-x42c.google.com with SMTP id l17so13485559wrr.4; Mon, 18 May 2020 14:08:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rqXFRgtK92DuLMVpS3lEJZDKdJZZLLxGy+Rd3p8Tt5A=; b=b2XjohYf73s5el9qX8QQ7LsuXQZDen+GVeDATLwZPWMP6S2Jq4AWRFHNVxKF19huzM nDoAinVmc8s/Fkg69RhS2425rQIhlWSJpzLzg8cZsZLVheJn3rxbIPbAMWv0NEx0Nbk1 hoN7dS7EqK8fUGGeOmq+POSliHWOAnkVrNr4LMWynLspW4TVJAFteorjIKk+ULE5ZcG4 DC6RAy53v/lVj6rW+hEyKXUfN70o40SP6rBHW/QXB/WdxfTM6okbyf1zxJNMy6cpDzss BSZbCLhYQ0F1d7Y6unUlccKU+oPovZ5rnPKu2hZFX54OVS//1d3VwOys0DpqkXeaQie7 wfcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rqXFRgtK92DuLMVpS3lEJZDKdJZZLLxGy+Rd3p8Tt5A=; b=jiSblWIlexTRF3TQA3usnMQnGpIHbclO4RhPMwM7qb6XZivnw60gQvYUmTfheeLa0E 1+XDtuXFrnEuYKsDNaxZHYyZ7kxeNTLghxKHbR4/d5qvSbK0aF3X7uTG/d1ad3yOlMAn uFVBtxoicxGTc1dBEyzIjxEFnLbT0SsxmFk7PWUbxbVshWkeih7D9A2FNMLjNxtJ9Mfq cjpvpTRM6fQqpf1D3fRilQ/4xa2z4iJvMMlZCKFcAARGVVZCeXN1DRIL7S81rF9i7j4o S+sKLZ4W+Z1YLGngeUhgBtJdmBFj1tYgqQFQMHSREGKI3vK2d8dbGJGZ6uLR2n2mMk92 aTmw== X-Gm-Message-State: AOAM5314bioUB2Pys5MhUE/FfbFN8hlo4jwbRhUtozFAhkKcElc9qW4d J8tMD2FaeYNQoxX9O5c9qb4cuHDUw5Yk4CScTM8= X-Google-Smtp-Source: ABdhPJymVlOqOB2tD7wZZ3MEOhLWZbf6v6Tkbu+Zp5k7klcDX/oWRXSWL2Fgjo2nw9haJr7mrZcZudRkv9hqypLHqOs= X-Received: by 2002:a5d:6401:: with SMTP id z1mr23179347wru.226.1589836131368; Mon, 18 May 2020 14:08:51 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rifaat Shekh-Yusef Date: Mon, 18 May 2020 17:08:40 -0400 Message-ID: To: Martin Thomson , kaduk@mit.edu Cc: secdir@ietf.org, captive-portals@ietf.org Content-Type: multipart/alternative; boundary="000000000000dc81fe05a5f29172" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-capport-rfc7710bis-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2020 21:08:55 -0000 --000000000000dc81fe05a5f29172 Content-Type: text/plain; charset="UTF-8" Adding Ben. On Sun, May 17, 2020 at 9:26 PM Martin Thomson wrote: > Adding more lists. > > On Sun, May 17, 2020, at 02:50, Rifaat Shekh-Yusef wrote: > > > Here is a quote form the API document: > > > "The hostname of the API SHOULD be displayed to the user in order to > indicate the entity which is providing the API service." > > > > > > This seems to suggest that the user is expected to inspect the > displayed name and make sure it is make sense in the context of whoever is > providing that service. > > I don't think that is the case. If this were a security mechanism, then > it would use "MUST". This is likely for the purpose of enabling some sort > of accountability. In other words, this is to offer maximal information > about what is going on. > > Here is the sentence just before the above quote from the API document: it provides the client of the API an opportunity to authenticate the server that is hosting the API. This authentication is aimed at *allowing a user to be reasonably confident that the entity providing the Captive Portal API has a valid certificate for the hostname in the URI* > > > Since this would be an easier attack compared to the interception > attack, and IP address is still permitted, then an attacker might force the > use of IP address to make it harder for the user to make sense of the > displayed name. > > I don't think that is materially different than getting a name with > confusable characters (or using the prefix hack, example.com..example, > in an attempt to confuse). > An end user should be able to validate that the name is example.com and not any other form of the URI. It would be much more difficult for the end user to make sense and validate an IP address. Regards, Rifaat --000000000000dc81fe05a5f29172 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Adding Ben.


On Sun, May 17,= 2020 at 9:26 PM Martin Thomson <mt= @lowentropy.net> wrote:
Adding more lists.

On Sun, May 17, 2020, at 02:50, Rifaat Shekh-Yusef wrote:
> > Here is a quote form the API document:
> > "The hostname of the API SHOULD be displayed to the user in = order to indicate the entity which is providing the API service."
> >
> > This seems to suggest that the user is expected to inspect the di= splayed name and make sure it is make sense in the context of whoever is pr= oviding that service.

I don't think that is the case.=C2=A0 If this were a security mechanism= , then it would use "MUST".=C2=A0 This is likely for the purpose = of enabling some sort of accountability.=C2=A0 In other words, this is to o= ffer maximal information about what is going on.

Here is the sentence just before the above quote from= the API document:

   it provides the client of the API
   an opportunity to authenticate the server that is hosting the API.
   This authentication is aimed at allowing a user to be reasonably
   confident that the entity providing the Captive Portal API has a
   valid certificate for the hostname in the URI

<= /div>

=C2=A0
> > Since this would be an easier attack compared to the interception= attack, and IP address is still permitted, then an attacker might force th= e use of IP address to make it harder for the user to make sense of the dis= played name.

I don't think that is materially different than getting a name with con= fusable characters (or using the prefix hack, example.com.<some-guid>.ex= ample, in an attempt to confuse).

An en= d user should be able to validate that the name is example.com and not any other form of the URI.
It woul= d be much more difficult for the end user to make sense and validate an IP = address.

Regards,
=C2=A0Rifaat

--000000000000dc81fe05a5f29172-- From nobody Tue May 19 10:56:11 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A085E3A0DCF; Tue, 19 May 2020 10:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8_JXIyYc_WOo; Tue, 19 May 2020 10:56:06 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A2083A0DC9; Tue, 19 May 2020 10:56:05 -0700 (PDT) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 04JHu4eJ005162; Tue, 19 May 2020 13:56:04 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu 04JHu4eJ005162 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1589910964; bh=rm/kOk8u+UFntsZ+81oGMxC4kliB6yyQzuRcb0voq48=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=gR9g0PaV2ssjuPDJfbqrF77HFNvOiAu6V8X//cg9wWeDig6YceiIEQz+0YiYRiSJK ELiz1qoDQZfctvnoZMvhvK6iA6cYU/LnHfg8mXQ3q98nDJYwks6wbC7A5p5E+RF6Pe y9Fuv/fPNT6qgSs+EcTWO4Ey7yYJjSZRgDupJ664= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 04JHtxmq013453; Tue, 19 May 2020 13:55:59 -0400 Received: from MURIEL.ad.sei.cmu.edu (147.72.252.47) by CASSINA.ad.sei.cmu.edu (10.64.28.249) with Microsoft SMTP Server (TLS) id 14.3.487.0; Tue, 19 May 2020 13:55:59 -0400 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MURIEL.ad.sei.cmu.edu (147.72.252.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1847.3; Tue, 19 May 2020 13:55:59 -0400 Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%22]) with mapi id 15.01.1847.007; Tue, 19 May 2020 13:55:58 -0400 From: Roman Danyliw To: Mike Jones , Hilarie Orman CC: "draft-hodges-webauthn-registries.all@ietf.org" , "secdir@ietf.org" Thread-Topic: Security review of draft-hodges-webauthn-registries-05 Thread-Index: AdYqHkFswnU29etfSlas2pmc9tnnCQAM5hyAAO0RE5A= Date: Tue, 19 May 2020 17:55:58 +0000 Message-ID: <775e5075c6a048db865c752ac8fc5506@cert.org> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.202.68] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] Security review of draft-hodges-webauthn-registries-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2020 17:56:10 -0000 Hi Hilarie, thank you for this review. =20 Hi Mike, thank you for incorporating the feedback. =20 I entered a No Objection ballot. Regards, Roman > -----Original Message----- > From: iesg On Behalf Of Mike Jones > Sent: Thursday, May 14, 2020 4:43 PM > To: Hilarie Orman ; kaduk@mit.edu > Cc: draft-hodges-webauthn-registries.all@ietf.org; iesg@ietf.org; > secdir@ietf.org > Subject: RE: Security review of draft-hodges-webauthn-registries-05 >=20 > The duplicate URI has been removed from https://tools.ietf.org/html/draft= - > hodges-webauthn-registries-07#section-6.2. We should be good to go now! >=20 > Thanks again, > -- Mike >=20 > -----Original Message----- > From: Mike Jones > Sent: Thursday, May 14, 2020 11:34 AM > To: Hilarie Orman > Cc: secdir@ietf.org; iesg@ietf.org; kaduk@mit.edu; draft-hodges-webauthn- > registries.all@ietf.org > Subject: RE: Security review of draft-hodges-webauthn-registries-05 >=20 > Oh, I see what you mean now. I didn't realize that the tool wouldn't coa= lesce > multiple instances of the same URI to a single reference. I'll do someth= ing to > eliminate the duplication now. >=20 > Thanks again, > -- Mike >=20 > -----Original Message----- > From: Hilarie Orman > Sent: Thursday, May 14, 2020 10:23 AM > To: Mike Jones > Cc: secdir@ietf.org; iesg@ietf.org; kaduk@mit.edu; draft-hodges-webauthn- > registries.all@ietf.org > Subject: RE: Security review of draft-hodges-webauthn-registries-05 >=20 > The only nit, then, is that the URI was listed twice in section 6.2. It = is listed in > entry 6 and entry 9. >=20 > Hilarie >=20 > > Thanks for the review, Hilarie. My replies are inline below, prefixed= by > "Mike>". >=20 > > -----Original Message----- > > From: Hilarie Orman > > Sent: Monday, April 27, 2020 9:42 PM > > To: iesg@ietf.org; secdir@ietf.org > > Cc: draft-hodges-webauthn-registries.all@ietf.org > > Subject: Security review of draft-hodges-webauthn-registries-05 >=20 > > Security review of Registries for Web Authentication > > draft-hodges-webauthn-registries-05 >=20 > > Do not be alarmed. I generated this review of this document as part o= f the > security directorate's ongoing effort to review all IETF documents being > processed by the IESG. These comments were written with the intent of > improving security requirements and considerations in IETF drafts. Comme= nts > not addressed in last call may be included in AD reviews during the IESG = review. > Document editors and WG chairs should treat these comments just like any > other last call comments. >=20 > > This document establishes two registries required for the W3C Web > Authentication system. The registries are for the WebAuthn Attestation > Statement Format Identifier and the WebAuthn Extension Identifier. >=20 > > When submitted, these entries must be approved by an "expert" based on > the specification that defines the parameters of the entry. This include= s > "security considerations", which is good. I don't quite see how submissi= on of a > request for a new entry gets routed to an expert, how experts come into b= eing, > etc., but I suppose that is a W3C procedure. >=20 > > A couple of nits. >=20 > > This url is listed twice in the URIs: > > https://www.iana.org/assignments/webauthn > > but it does not exist. I expected at least a TBD message, unless the = address > itself is a placeholder. >=20 > > Mike> The draft includes this TBD text "[[ Per discussions in an email= thread > between the authors and IANA ( "[IANA #1154148]" ), it is requested that = the > registries be located at . RFC > Editor - please delete this request after the registries have been create= d. ]]" > before the two occurrences that you cite. >=20 > > In 2.1 > > "The Experts(s) MAY also designate attestation > > statement formats as proprietary if they lack complete > > specifications, and will assign a prefix indicating as such to the > > identifier." > > It is not clear what the format of that prefix is or how indicates "as= such". Is > that an indication that it is proprietary or (and?) that it is incomplete= ? >=20 > > Mike> The text you cited is unnecessary for the purposes of the speci= fication > and will be deleted. >=20 > > Hilarie >=20 > > Mike> You can see proposed updated source for -06 at > https://github.com/w3c/webauthn/pull/1415 . >=20 > > Thanks again, > > -- Mike From nobody Tue May 19 14:47:04 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7DCB3A11A1; Tue, 19 May 2020 14:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHdYTQLikSiG; Tue, 19 May 2020 14:46:54 -0700 (PDT) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 283843A117E; Tue, 19 May 2020 14:46:50 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 04JLkkAb020517; Tue, 19 May 2020 17:46:46 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu 04JLkkAb020517 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1589924806; bh=OitRuiwndc5jQ8tnBiXIta0W93h5a5EtO39PpBCnFXs=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=WQJernGc6P7WUPNpzZGokCho6KXzuozbNmQR4KfC5pDWp9QdTfl7R1JG3fGT/+abW tk8oDO4g1T81/vdbMBCA1EzPOxrtNvVxiRLmReKMX9xXindj9TB8VuscHUD0r20VHi wTfQqgCkBzdEl78gOnOLdI+OlJqzwcB99EO44wL8= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 04JLkfQV017103; Tue, 19 May 2020 17:46:41 -0400 Received: from MURIEL.ad.sei.cmu.edu (147.72.252.47) by CASSINA.ad.sei.cmu.edu (10.64.28.249) with Microsoft SMTP Server (TLS) id 14.3.487.0; Tue, 19 May 2020 17:46:41 -0400 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MURIEL.ad.sei.cmu.edu (147.72.252.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1847.3; Tue, 19 May 2020 17:46:40 -0400 Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%22]) with mapi id 15.01.1847.007; Tue, 19 May 2020 17:46:40 -0400 From: Roman Danyliw To: Francesca Palombini CC: "draft-ietf-rtcweb-sdp.all@ietf.org" , "secdir@ietf.org" Thread-Topic: [secdir] Secdir last call review of draft-ietf-rtcweb-sdp-11 Thread-Index: AQHWGjwr2d66wuNkLkyVqJ4UgqF2nqiwGPvA Date: Tue, 19 May 2020 21:46:40 +0000 Message-ID: References: <158773486767.10860.13207279734771599599@ietfa.amsl.com> In-Reply-To: <158773486767.10860.13207279734771599599@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.202.68] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-rtcweb-sdp-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2020 21:47:03 -0000 Hi Francesca, thank you for this review. I entered a No Objection ballot. Regards, Roman > -----Original Message----- > From: secdir On Behalf Of Francesca Palombini v= ia > Datatracker > Sent: Friday, April 24, 2020 9:28 AM > To: secdir@ietf.org > Cc: draft-ietf-rtcweb-sdp.all@ietf.org; last-call@ietf.org > Subject: [secdir] Secdir last call review of draft-ietf-rtcweb-sdp-11 >=20 > Reviewer: Francesca Palombini > Review result: Ready >=20 > I have reviewed this document as part of the security directorate's ongoi= ng > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area dire= ctors. > Document editors and WG chairs should treat these comments just like any > other last call comments. >=20 > The summary of the review is Ready. >=20 > This document provides an informational reference for examples of the Ses= sion > Description Protocol (SDP) Offer/Answer exchange mechanism, for the most > common Rtcweb use-cases. >=20 > The security considerations section points to documents describing the se= curity > architecture for WebRTC as a whole, which is appropriate for such an > informational document. >=20 >=20 > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From nobody Tue May 19 15:07:00 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA8C3A1192; Tue, 19 May 2020 15:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gff7lrmg2c9O; Tue, 19 May 2020 15:06:55 -0700 (PDT) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB7E23A117D; Tue, 19 May 2020 15:06:55 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 04JM6rOr023490; Tue, 19 May 2020 18:06:53 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu 04JM6rOr023490 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1589926013; bh=L1zrkrP2e+MH1uV30FORsoli4Jn3TEX57tt5USfJaIw=; h=From:To:CC:Subject:Date:From; b=PGT2rlpRbrYjTcKaXvvx6szS3lE/YowdY3n/NFgSDgmL3N14K0+PAKk9/S/fv/GZ4 nTKqcZlGogKYP7PDh/PmLoJJU67NzvMMc6OeT4Us8a/YatsG4qcRoh7leG6eIGV+8J polcaT1nmBPgmEkcynhPyWb75vUpB8cjAyVCghdA= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 04JM6pJh022417; Tue, 19 May 2020 18:06:51 -0400 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by CASCADE.ad.sei.cmu.edu (10.64.28.248) with Microsoft SMTP Server (TLS) id 14.3.487.0; Tue, 19 May 2020 18:06:51 -0400 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MORRIS.ad.sei.cmu.edu (147.72.252.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1847.3; Tue, 19 May 2020 18:06:50 -0400 Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%22]) with mapi id 15.01.1847.007; Tue, 19 May 2020 18:06:50 -0400 From: Roman Danyliw To: Rich Salz CC: "draft-ietf-isis-mpls-elc.all@ietf.org" , "secdir@ietf.org" Thread-Topic: Re: [secdir] Secdir last call review of draft-ietf-isis-mpls-elc-12 Thread-Index: AdYuKZT+kesMRqG8Tt+f69LdYPMj9w== Date: Tue, 19 May 2020 22:06:50 +0000 Message-ID: <622e2c227dc64c2b9f6a876e17016325@cert.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.202.68] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-isis-mpls-elc-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2020 22:06:58 -0000 Hi Rich, thank you for this review. I entered a No Objection ballot. Regards, Roman > -----Original Message----- > From: secdir On Behalf Of Rich Salz=20 > via Datatracker > Sent: Thu, 30 April 2020 18:06 UTC > To: secdir@ietf.org > Cc: last-call@ietf.org, lsr@ietf.org, draft-ietf-isis-mpls-elc.all@ietf.o= rg > Subject: [secdir] Secdir last call review of draft-ietf-isis-mpls-elc-12 > > Reviewer: Rich Salz > Review result: Ready >=20 > I am the SECDIR reviewer for this document; the security directorate trie= s to > review all documents before they go to the IESG. This content is intended > primarily for the SecAD's, anyone else should consider this like other > last-call comments. > > This document is READY. > > This is a short doument. It defines a way for MPLS routers to indicate th= at > they can handle additional meta-data, "entropy labels" and depth of them,= to do > traffic routing. > > The security implications of this are well-discussed. From nobody Tue May 19 16:51:50 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E67363A053F; Tue, 19 May 2020 16:51:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Christopher Wood via Datatracker To: Cc: dhcwg@ietf.org, draft-ietf-dhc-problem-statement-of-mredhcpv6.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.130.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158993226788.7058.12159366851189346862@ietfa.amsl.com> Reply-To: Christopher Wood Date: Tue, 19 May 2020 16:51:07 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-dhc-problem-statement-of-mredhcpv6-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2020 23:51:08 -0000 Reviewer: Christopher Wood Review result: Serious Issues Summary: Series Issues Comments: - Section 1. The introduction needs a lot of work. It seems to be trying to say something, but I cannot tell what that is. It's claimed that many documents attempt to extend DHCPv6, yet no extensions are cited. There's mention of "multi-requirement extension problems," but no example of such a problem. There's reference to the possibility of administrators modifying DHCPv6 code (and possibly breaking things in the process), but that does not seem relevant to or follow from the previous text. Please revise this entire section and make the goal clear. What is the problem being solved, why is it important, and what is the summary of the proposed solution? - Section 3.2. This section seems largely irrelevant. What is its purpose? It mainly documents software support, rather than "extension practices." - Section 4.1. Figure 1 could benefit from some descriptive text to match the diagram. For example, it's clear how "options" are points of extensibility, but how are "message processing functions" points of extensibility? An example might help clarify. - Section 4.2.3. What does "not all DHCPv6 software considers this extension" mean? Does it imply that not all server implements support for this extension, or something else? - Section 5. This seems to be the crux of the document, yet I failed to glean much from its contents. There are some examples of extensions which may require multiple more than one "moving part," such as (1) client identity transmission and (2) server use of those identities for address allocation. Is there guidance that should be followed for specifying this type of multi-requirement extension? If so, what is it? (Is that not the whole point of this document?) Are there considerations administrators or specification writers should be mindful of when designing these extensions? If so, what are they? In general, it seems that if a document is to emphasize considerations for folks, then those considerations out to be clearly articulated. Instead, this document seems to just list some examples (current practices) without any further insight. This makes me question its overall value for the community. Nits: - Section 1. "The IP address plays a significant role in the communication of the Internet." Did this mean to say communication *on* the Internet? - Please remove unnecessary gender terms from the document ("his"). - This text: For example, considering such a requirement that DHCPv6 servers assign IPv6 addresses generated by user identifiers to the clients in a network to hold users accountable, two extensions should be fulfilled to meet this requirement. Could probably be simplified. Also, what does it mean for an extension to be fulfilled? From nobody Wed May 20 04:37:31 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D51EB3A08D5; Wed, 20 May 2020 04:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azKNhlmXAVOL; Wed, 20 May 2020 04:37:27 -0700 (PDT) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 177063A08D4; Wed, 20 May 2020 04:37:26 -0700 (PDT) Received: by mail-wm1-x329.google.com with SMTP id g14so4526677wme.1; Wed, 20 May 2020 04:37:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uHBEg7gix26F6RCMQIpVhhiUWoQP1doHv9jK6id/dKA=; b=WPxdatTNqk4Ok2kloa1jD4DTN1UN7DIrvdqqnZXCzFPn2Dg/pSqZAVd8lol1Jh3uTb xZ3or3VW8FziSeznrxjN4D3bUTLr+1X+kNe16RJVsC1oiE0Rov4HF6sTMYA406AhVs9R Fa6bzmv8TP2QrcNBBZPLxUaEyvDxE+qGbu5AEClDiKdLR5KjRK+XJprb5aBWNX1bN1ss 8Stfj+Ke46Sm1Hiz73P6oleSpiloKHMicf/+n4komSvYCrINQVn1eNNeAiyMM19gR0yW 6ax6t1mWyxCg8QTejEwlBQLEKR65n+spaGxCe0FLWuybeW6z4yYCetZCyPC8xkLF2+ui khVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uHBEg7gix26F6RCMQIpVhhiUWoQP1doHv9jK6id/dKA=; b=HiTfIDlJZPQ89yLTN5+h1lDkin0vOkGeWrpuv1q6VlFF51pLBbiYKmygcEAPBWVVwQ xZhEpDgjA1Wzpp9xJEFUTucIVMbKjzKFsX7fLzN33YiPSp4k0+D73CCxzwATVJwGvUVI YnjqTLcKOCwK3Rql4W9xtp6HUcO95GiLnWEoJprBKW8/LQL4XS1QLU8GHyFUNnX3ynQd OLlULVVQdIpu+NTuky+2J32QTn/BK+goemDBxW27TlkThafzqdvh+cDeziJLS3a6aEU1 L8cdNr3FW/RuGiXfRn8JzmKu5Sp0NoK1UDgD4mioJL0Ip75JNqJ+4I1Qqa9VJd783cI/ hFTA== X-Gm-Message-State: AOAM532v1xGAw2H/19ldUNiVVfj9h7j73pS6kf6aDWnu1GRjDA57FGTL JLRi77jRYimbWz0dnnHFs5VvfJZdLmD0FhBs+Vk= X-Google-Smtp-Source: ABdhPJyTS4uTmmx6oU4l5XZoh5g17wUa+6Cu3gBgj/O+rAhkkUfaE8S3fhyojCc8xltzvXbzpOlUZzlsFCn9gm5vKW8= X-Received: by 2002:a1c:3b87:: with SMTP id i129mr4539753wma.38.1589974645404; Wed, 20 May 2020 04:37:25 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rifaat Shekh-Yusef Date: Wed, 20 May 2020 07:37:14 -0400 Message-ID: To: Martin Thomson , kaduk@mit.edu, barryleiba@computer.org Cc: secdir@ietf.org, captive-portals@ietf.org Content-Type: multipart/alternative; boundary="000000000000f0fb3805a612d1ba" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-capport-rfc7710bis-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2020 11:37:30 -0000 --000000000000f0fb3805a612d1ba Content-Type: text/plain; charset="UTF-8" Adding SecDir back to this thread. >Martin Thomson Tue, 19 May 2020 01:02 UTCShow header > >On Tue, May 19, 2020, at 07:08, Rifaat Shekh-Yusef wrote: >> it provides the client of the API >> an opportunity to authenticate the server that is hosting the API. >> This authentication is aimed at *allowing a user to be reasonably >> confident that the entity providing the Captive Portal API has a >> valid certificate for the hostname in the URI* >[...] >> An end user should be able to validate that the name is example.com and >> not any other form of the URI. >> It would be much more difficult for the end user to make sense and >> validate an IP address. > >I think that you missed the point of my comments. This validation, performed by >a user, has no meaningful security value. The text you cite says that the server >has a certificate for the name it chooses, which is not the same as "has a certificate >for a name the client expects". The difference is important. > This is not the way I read these statements from section 4.1 titled *Server Authentication*. Here is the use case I have in mind when I read this section: If I walk into an airport and I see an ad for a paid Internet service from example.com, then as an end user it is reasonable to expect that I would have some ability to make sense of the name presented to me and make sure it is from example.com if I choose to get such a service. If this is not the case, then yo might want to make it clear that this is not about *Server Authentication* as the title of the section and the text inside that section is suggesting. Regards, Rifaat >In a typical web scenario, a person types a string in and (ignore the case where there >is an extra hop via a search engine) that string determines what is acceptable as a >server identity. The exposure to confusables is limited (under a set of other assumptions, >HSTS, etc...). Here, the network has free reign to do as they choose with homoglyphs and >other such nonsense. Any expectation you might have about this really being a trustworthy >entity is meaningless in this context. > >There are protections against this, but they all lie firmly in the anti-phishing domain. >Most of those rely on having a certificate though, so the requirement for HTTPS is in >service of that, not in terms of ensuring that an untrained human can make a security >critical decision based on poisoned information. On Mon, May 18, 2020 at 5:08 PM Rifaat Shekh-Yusef wrote: > Adding Ben. > > > On Sun, May 17, 2020 at 9:26 PM Martin Thomson wrote: > >> Adding more lists. >> >> On Sun, May 17, 2020, at 02:50, Rifaat Shekh-Yusef wrote: >> > > Here is a quote form the API document: >> > > "The hostname of the API SHOULD be displayed to the user in order to >> indicate the entity which is providing the API service." >> > > >> > > This seems to suggest that the user is expected to inspect the >> displayed name and make sure it is make sense in the context of whoever is >> providing that service. >> >> I don't think that is the case. If this were a security mechanism, then >> it would use "MUST". This is likely for the purpose of enabling some sort >> of accountability. In other words, this is to offer maximal information >> about what is going on. >> >> Here is the sentence just before the above quote from the API document: > > it provides the client of the API > an opportunity to authenticate the server that is hosting the API. > This authentication is aimed at *allowing a user to be reasonably > confident that the entity providing the Captive Portal API has a > valid certificate for the hostname in the URI* > > > > > >> > > Since this would be an easier attack compared to the interception >> attack, and IP address is still permitted, then an attacker might force the >> use of IP address to make it harder for the user to make sense of the >> displayed name. >> >> I don't think that is materially different than getting a name with >> confusable characters (or using the prefix hack, example.com..example, >> in an attempt to confuse). >> > > An end user should be able to validate that the name is example.com and > not any other form of the URI. > It would be much more difficult for the end user to make sense and > validate an IP address. > > Regards, > Rifaat > > --000000000000f0fb3805a612d1ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Adding SecDir back to this=C2=A0thread.

>Martin Thomson <mt@lowentropy.net> Tue, 19 May 2020 01:02 U= TCShow header
>
>On Tue, May 19, 2020, at 07:08, Rifaat Shekh-= Yusef wrote:
>> =C2=A0 =C2=A0it provides the client of the API
= >> =C2=A0 =C2=A0an opportunity to authenticate the server that is hos= ting the API.
>> =C2=A0 =C2=A0This authentication is aimed at *all= owing a user to be reasonably
>> =C2=A0 =C2=A0confident that the e= ntity providing the Captive Portal API has a
>> =C2=A0 =C2=A0valid= certificate for the hostname in the URI*
>[...]
>> An end = user should be able to validate that the name is example.com and
>> not any other form = of the URI.
>> It would be much more difficult for the end user to= make sense and
>> validate an IP address.
>
>I think= that you missed the point of my comments.=C2=A0 This validation, performed= by
>a user, has no meaningful security value.=C2=A0 The text you ci= te says that the server
>has a certificate for the name it chooses, = which is not the same as "has a certificate
>for a name the cli= ent expects".=C2=A0 The difference is important.
>

This is not the way I read these statements from section 4.1 titled= =C2=A0Server Authentication.

Here is the us= e case I have in mind when I read this section:
If I walk into an= airport and I see an ad for a paid Internet service from example.com, then as an=C2=A0
end user it is re= asonable to expect that I would have some ability to make sense of the name= =C2=A0
presented to me and make sure it is from example.com if I choose to get such a service.
=
If this is not the case, then yo might=C2=A0want to make it = clear that this is not about Server Authentication=C2=A0
a= s the title of the section and the text inside that section is suggesting.<= /div>

Regards,
=C2=A0Rifaat



>In a typical web scenario, a person types a s= tring in and (ignore the case where there
>is an extra hop via a sea= rch engine) that string determines what is acceptable as a
>server i= dentity.=C2=A0 The exposure to confusables is limited (under a set of other= assumptions,
>HSTS, etc...).=C2=A0 Here, the network has free reign= to do as they choose with homoglyphs and
>other such nonsense.=C2= =A0 Any expectation you might have about this really being a trustworthy >entity is meaningless in this context.
>
>There are prote= ctions against this, but they all lie firmly in the anti-phishing domain.= =C2=A0
>Most of those rely on having a certificate though, so the re= quirement for HTTPS is in
>service of that, not in terms of ensuring= that an untrained human can make a security
>critical decision base= d on poisoned information.

On Mon, May 18, 2020 at 5:08 PM Rifaat = Shekh-Yusef <rifaat.s.ietf@gmail.com> wrote:
Adding Ben.
=

On Sun, May 17, 2020 at 9:26 PM Martin Thomson <mt@lowentropy.net> wrote:
Adding more lists= .

On Sun, May 17, 2020, at 02:50, Rifaat Shekh-Yusef wrote:
> > Here is a quote form the API document:
> > "The hostname of the API SHOULD be displayed to the user in = order to indicate the entity which is providing the API service."
> >
> > This seems to suggest that the user is expected to inspect the di= splayed name and make sure it is make sense in the context of whoever is pr= oviding that service.

I don't think that is the case.=C2=A0 If this were a security mechanism= , then it would use "MUST".=C2=A0 This is likely for the purpose = of enabling some sort of accountability.=C2=A0 In other words, this is to o= ffer maximal information about what is going on.

Here is the sentence just before the above quote from= the API document:

   =
it provides the client of the API
   an opportunity to authenticate the server that is hosting the API.
   This authentication is aimed at allowing a user to be reasonably
   confident that the entity providing the Captive Portal API has a
   valid certificate for the hostname in the URI

<= /div>

=C2=A0
> > Since this would be an easier attack compared to the interception= attack, and IP address is still permitted, then an attacker might force th= e use of IP address to make it harder for the user to make sense of the dis= played name.

I don't think that is materially different than getting a name with con= fusable characters (or using the prefix hack, example.com.<some-guid>.ex= ample, in an attempt to confuse).

An en= d user should be able to validate that the name is example.com and not any other form of the URI.=
It would be much more difficult for the end user to make sense a= nd validate an IP address.

Regards,
=C2= =A0Rifaat

--000000000000f0fb3805a612d1ba-- From nobody Wed May 20 13:34:08 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFE33A0AD8; Wed, 20 May 2020 13:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvTksn8BeT1B; Wed, 20 May 2020 13:34:04 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1184B3A0AD7; Wed, 20 May 2020 13:34:03 -0700 (PDT) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 04KKY2d9041895; Wed, 20 May 2020 16:34:02 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu 04KKY2d9041895 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1590006842; bh=nyg40m5Hac67M3hbY4dCQX3R2PZjdgKRAbEh//Bs82E=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=Kg32E+PegGzPJ1CdfvCG5FoX7Dg10EEHXnofaRClVEW3f7cidfpHepEF46O4rFZEg KvWhmLcVFDY7zrcXOEVknLZSC5bVGZINXL4/2+KtWc/2yDvdcPVDsqEZDy+pYkdNuU w4TZEeQZFmDi5JIrEqFn3M4wfEFtHeusF9mu29Mk= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 04KKY0Ac029598; Wed, 20 May 2020 16:34:00 -0400 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by CASCADE.ad.sei.cmu.edu (10.64.28.248) with Microsoft SMTP Server (TLS) id 14.3.487.0; Wed, 20 May 2020 16:34:00 -0400 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MORRIS.ad.sei.cmu.edu (147.72.252.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1847.3; Wed, 20 May 2020 16:33:59 -0400 Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%22]) with mapi id 15.01.1847.007; Wed, 20 May 2020 16:33:59 -0400 From: Roman Danyliw To: Joseph Salowey , "secdir@ietf.org" CC: "draft-ietf-ospf-mpls-elc.all@ietf.org" Thread-Topic: [secdir] Secdir last call review of draft-ietf-ospf-mpls-elc-13 Thread-Index: AQHWH3UgmwsWLAh+OEm3oizwEpShJaixjNlw Date: Wed, 20 May 2020 20:33:59 +0000 Message-ID: References: <158830906041.22803.13800308434788640436@ietfa.amsl.com> In-Reply-To: <158830906041.22803.13800308434788640436@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.202.68] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-ospf-mpls-elc-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2020 20:34:06 -0000 Hi Joe, thank you for this review. I entered a No Objection ballot. Regards, Roman > -----Original Message----- > From: secdir On Behalf Of Joseph Salowey via > Datatracker > Sent: Friday, May 1, 2020 12:58 AM > To: secdir@ietf.org > Cc: last-call@ietf.org; draft-ietf-ospf-mpls-elc.all@ietf.org; lsr@ietf.o= rg > Subject: [secdir] Secdir last call review of draft-ietf-ospf-mpls-elc-13 >=20 > Reviewer: Joseph Salowey > Review result: Ready >=20 > I have reviewed this document as part of the security directorate's ongoi= ng > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area dire= ctors. > Document editors and WG chairs should treat these comments just like any > other last call comments. >=20 > The summary of the review is ready from a security perspective. The secu= rity > considerations section is adequate. >=20 >=20 > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From nobody Thu May 21 00:09:14 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC9E43A07DB; Thu, 21 May 2020 00:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRpBhdFrgaKP; Thu, 21 May 2020 00:09:09 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 311113A07D5; Thu, 21 May 2020 00:09:08 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 04L794Cb026775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 21 May 2020 03:09:07 -0400 Date: Thu, 21 May 2020 00:09:04 -0700 From: Benjamin Kaduk To: Joseph Salowey Cc: "secdir@ietf.org" , "draft-ietf-ospf-mpls-elc.all@ietf.org" Message-ID: <20200521070904.GG58497@kduck.mit.edu> References: <158830906041.22803.13800308434788640436@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-ospf-mpls-elc-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2020 07:09:13 -0000 Yes, thanks Joe! I put a Discuss ballot in for a non-directly-security-related issue: I had a question about whether this document had text that was attempting to impose requirements on parties that do not implement this document. -Ben On Wed, May 20, 2020 at 08:33:59PM +0000, Roman Danyliw wrote: > Hi Joe, thank you for this review. I entered a No Objection ballot. > > Regards, > Roman > > > -----Original Message----- > > From: secdir On Behalf Of Joseph Salowey via > > Datatracker > > Sent: Friday, May 1, 2020 12:58 AM > > To: secdir@ietf.org > > Cc: last-call@ietf.org; draft-ietf-ospf-mpls-elc.all@ietf.org; lsr@ietf.org > > Subject: [secdir] Secdir last call review of draft-ietf-ospf-mpls-elc-13 > > > > Reviewer: Joseph Salowey > > Review result: Ready > > > > I have reviewed this document as part of the security directorate's ongoing > > effort to review all IETF documents being processed by the IESG. These > > comments were written primarily for the benefit of the security area directors. > > Document editors and WG chairs should treat these comments just like any > > other last call comments. > > > > The summary of the review is ready from a security perspective. The security > > considerations section is adequate. > > > > > > _______________________________________________ > > secdir mailing list > > secdir@ietf.org > > https://www.ietf.org/mailman/listinfo/secdir > > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From nobody Thu May 21 00:12:08 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 830FD3A0A68; Thu, 21 May 2020 00:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-LMn6RlKFWf; Thu, 21 May 2020 00:12:03 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E4FA3A0A67; Thu, 21 May 2020 00:12:02 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 04L7BuvH027406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 21 May 2020 03:11:59 -0400 Date: Thu, 21 May 2020 00:11:56 -0700 From: Benjamin Kaduk To: Rich Salz Cc: "draft-ietf-isis-mpls-elc.all@ietf.org" , "secdir@ietf.org" Message-ID: <20200521071156.GH58497@kduck.mit.edu> References: <622e2c227dc64c2b9f6a876e17016325@cert.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <622e2c227dc64c2b9f6a876e17016325@cert.org> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-isis-mpls-elc-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2020 07:12:08 -0000 Yes, thanks Rich. Interestingly, though my Discuss on the corresponding OSPF document was in a portion that is fairly OSPF-specific, there was a similar thing in the IS-IS document that also got a Discuss from me. -Ben On Tue, May 19, 2020 at 10:06:50PM +0000, Roman Danyliw wrote: > Hi Rich, thank you for this review. I entered a No Objection ballot. > > Regards, > Roman > > > -----Original Message----- > > From: secdir On Behalf Of Rich Salz > > via Datatracker > > Sent: Thu, 30 April 2020 18:06 UTC > > To: secdir@ietf.org > > Cc: last-call@ietf.org, lsr@ietf.org, draft-ietf-isis-mpls-elc.all@ietf.org > > Subject: [secdir] Secdir last call review of draft-ietf-isis-mpls-elc-12 > > > > Reviewer: Rich Salz > > Review result: Ready > > > > I am the SECDIR reviewer for this document; the security directorate tries to > > review all documents before they go to the IESG. This content is intended > > primarily for the SecAD's, anyone else should consider this like other > > last-call comments. > > > > This document is READY. > > > > This is a short doument. It defines a way for MPLS routers to indicate that > > they can handle additional meta-data, "entropy labels" and depth of them, to do > > traffic routing. > > > > The security implications of this are well-discussed. > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From nobody Thu May 21 00:40:42 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 409A53A0A97; Thu, 21 May 2020 00:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7tJyxDpDJXa; Thu, 21 May 2020 00:40:37 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C8B03A0A9C; Thu, 21 May 2020 00:40:36 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 04L7eUZw032666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 21 May 2020 03:40:33 -0400 Date: Thu, 21 May 2020 00:40:29 -0700 From: Benjamin Kaduk To: Francesca Palombini Cc: "draft-ietf-rtcweb-sdp.all@ietf.org" , "secdir@ietf.org" Message-ID: <20200521074029.GI58497@kduck.mit.edu> References: <158773486767.10860.13207279734771599599@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-rtcweb-sdp-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2020 07:40:41 -0000 Seconded -- it was a long one and the extra eyes appreciated. I spent a little too much time trying to understand the SDP and think I spotted some Discuss-worth inconsistencies. I also suggested that the note early on that some values are shown as shorter/less-random than usual for the purposes of the examples, might be repeated in the security considerations. -Ben On Tue, May 19, 2020 at 09:46:40PM +0000, Roman Danyliw wrote: > Hi Francesca, thank you for this review. I entered a No Objection ballot. > > Regards, > Roman > > > -----Original Message----- > > From: secdir On Behalf Of Francesca Palombini via > > Datatracker > > Sent: Friday, April 24, 2020 9:28 AM > > To: secdir@ietf.org > > Cc: draft-ietf-rtcweb-sdp.all@ietf.org; last-call@ietf.org > > Subject: [secdir] Secdir last call review of draft-ietf-rtcweb-sdp-11 > > > > Reviewer: Francesca Palombini > > Review result: Ready > > > > I have reviewed this document as part of the security directorate's ongoing > > effort to review all IETF documents being processed by the IESG. These > > comments were written primarily for the benefit of the security area directors. > > Document editors and WG chairs should treat these comments just like any > > other last call comments. > > > > The summary of the review is Ready. > > > > This document provides an informational reference for examples of the Session > > Description Protocol (SDP) Offer/Answer exchange mechanism, for the most > > common Rtcweb use-cases. > > > > The security considerations section points to documents describing the security > > architecture for WebRTC as a whole, which is appropriate for such an > > informational document. > > > > > > _______________________________________________ > > secdir mailing list > > secdir@ietf.org > > https://www.ietf.org/mailman/listinfo/secdir > > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From nobody Thu May 21 14:18:18 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE3A3A0BE9 for ; Thu, 21 May 2020 14:18:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.0.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <159009589323.10208.6163122470455636807@ietfa.amsl.com> Date: Thu, 21 May 2020 14:18:14 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2020 21:18:15 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2020-05-21 Reviewer LC end Draft Stefan Santesson 2020-05-04 draft-ietf-httpbis-header-structure-18 Tina Tsou 2020-05-08 draft-ietf-httpbis-client-hints-14 Sean Turner 2020-05-06 draft-ietf-opsawg-sdi-02 Last calls: Reviewer LC end Draft Derek Atkins 2020-05-29 draft-ietf-cose-rfc8152bis-struct-09 John Bradley 2020-02-28 draft-ietf-regext-data-escrow-09 Nancy Cam-Winget 2020-05-29 draft-ietf-cose-rfc8152bis-algs-08 Shaun Cooley 2020-05-29 draft-ietf-ospf-te-link-attr-reuse-12 Alan DeKok 2020-05-29 draft-ietf-isis-te-app-13 Linda Dunbar 2020-05-27 draft-ietf-cose-webauthn-algorithms-06 Donald Eastlake R2019-11-14 draft-ietf-hip-dex-20 Donald Eastlake 2020-02-27 draft-ietf-6tisch-msf-16 Daniel Franke 2020-03-09 draft-ietf-regext-dnrd-objects-mapping-07 Russ Mundy 2020-01-02 draft-ietf-dprive-bcp-op-09 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-11 Vincent Roca 2020-04-23 draft-ietf-detnet-ip-over-mpls-06 Stefan Santesson 2020-05-04 draft-ietf-httpbis-header-structure-18 Melinda Shore 2020-05-13 draft-ietf-secevent-http-poll-09 Tina Tsou 2020-05-08 draft-ietf-httpbis-client-hints-14 Sean Turner 2020-05-19 draft-ietf-dhc-mac-assign-06 Sean Turner 2020-05-06 draft-ietf-opsawg-sdi-02 Mališa Vučinić 2020-05-27 draft-ietf-emu-eap-session-id-03 Carl Wallace 2020-05-27 draft-ietf-dhc-slap-quadrant-08 Samuel Weiler 2020-06-11 draft-ietf-trill-multilevel-single-nickname-09 Brian Weis 2020-05-26 draft-ietf-cose-hash-algs-03 Klaas Wierenga 2020-05-26 draft-ietf-kitten-krb-spake-preauth-08 Paul Wouters 2020-05-25 draft-ietf-capport-architecture-08 Liang Xia 2020-06-01 draft-ietf-tcpm-rto-consider-14 Dacheng Zhang 2020-03-12 draft-nottingham-how-did-that-get-into-the-repo-01 Dacheng Zhang 2019-11-05 draft-ietf-mpls-ri-rsvp-frr-07 Next in the reviewer rotation: Shawn Emery Stephen Farrell Daniel Franke Daniel Gillmor Phillip Hallam-Baker Steve Hanna Dan Harkins Russ Housley Christian Huitema Leif Johansson From nobody Fri May 22 18:30:01 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB6693A0D4B; Fri, 22 May 2020 11:14:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1590171299; bh=7PrmU4QoMVcu9SmGfJ4BRjEou2xIY3l17RUAJrG2Qw8=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To; b=AXHe8YtKfB7dU9bMAOD/DdhvLL2qhiXaH3a11MVqVNF3zJYNvnkU4k7do3H1OcXAh vLr61whPMwRDk57OkB8bJTB3Ewlp7XozilGt7ePRtJrg1lVkDrfn+8tWTDHtp/Pazn Fx24pRTQtsnfo5gswf97z6ET/PXe/EEtv0ve3cXY= X-Mailbox-Line: From new-work-bounces@ietf.org Fri May 22 11:14:52 2020 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 19D4E3A0D44; Fri, 22 May 2020 11:14:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1590171291; bh=7PrmU4QoMVcu9SmGfJ4BRjEou2xIY3l17RUAJrG2Qw8=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To; b=OSIqmSl6AllHdJFgjwS654UqBwgWNb2HpUE3A9ZC3I3mG9Jh9FCzlppka225RQYpE /kEPyjiyU45+6/h92AChLumGhSnLnLZ9PhZXvdmry8//m/EwSTa6BRhj53N5z2/ETb S2VpLE7QnjYdO7Z3M1BUZQlSGhFgH+WUIOEV85V0= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C87C13A0D0B for ; Fri, 22 May 2020 11:14:41 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk MIME-Version: 1.0 Reply_to: Message-ID: <159017128179.9391.3728952311424438613@ietfa.amsl.com> Date: Fri, 22 May 2020 11:14:41 -0700 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Reply-To: iesg@ietf.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 22 May 2020 18:29:59 -0700 Subject: [secdir] [new-work] WG Review: Multiplexed Application Substrate over QUIC Encryption (masque) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2020 18:15:07 -0000 A new IETF WG has been proposed in the Transport Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2020-06-01. Multiplexed Application Substrate over QUIC Encryption (masque) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: Christopher Wood Eric Kinnear Assigned Area Director: Martin Duke Transport Area Directors: Magnus Westerlund Martin Duke Mailing list: Address: masque@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/masque Archive: https://mailarchive.ietf.org/arch/browse/masque/ Group page: https://datatracker.ietf.org/group/masque/ Charter: https://datatracker.ietf.org/doc/charter-ietf-masque/ Many network topologies lead to situations where transport protocol proxying is beneficial. For example, proxying enables endpoints to communicate when end-to-end connectivity is not possible and can apply additional encryption where desirable (such as a VPN). Proxying can also improve client privacy, e.g., by hiding a client's IP address from a target server. Proxying technologies such as SOCKS and HTTP(S) CONNECT exist, albeit with their own shortcomings. For example, SOCKS signalling is not encrypted and HTTP CONNECT is currently limited to TCP. In contrast, HTTP/3 is a viable candidate protocol for proxying arbitrary traffic, as in a single connection it provides secure connectivity, multiplexed streams, migration, and a unified congestion controller. An HTTP/3 datagram construct built on top of QUIC datagram frames would provide for unreliable data transmission and enable transporting UDP and other unreliable flows via a proxy. Moreover, it would not introduce potentially redundant or unnecessary recovery mechanisms. Lastly, HTTP supports an established request/response semantic that can set up and configure flows for different services. The primary goal of this working group is to develop mechanism(s) that allow configuring and concurrently running multiple proxied stream- and datagram-based flows inside an HTTPS connection. These mechanism(s) are collectively called MASQUE. The group will specify HTTP and/or HTTP/3 extensions to enable this functionality. The group will focus on a limited set of client-initiated services: (1) UDP CONNECT and (2) IP proxying. Server-initiated services are out of scope. The working group will first deliver a protocol solution for UDP CONNECT and a requirements document for IP proxying. Once both are complete, the working group will focus on a protocol solution for IP proxying. The working group will consider fallback to versions of HTTPS that operate over TCP as a mitigation to UDP or HTTP/3 blocking. Moreover, the working group will consider implications of tunneling protocols with congestion control and loss recovery over MASQUE, and may issue recommendations accordingly. New congestion control and loss recovery algorithms are out of scope. Multicast support is out of scope. However, the group may specify extension points that would enable future work on multicast. Specifying proxy server discovery mechanisms is also out of scope. However, the group may consider features, such as proxy server identifiers, that aid future discovery mechanisms. Impacts on address migration, NAT rebinding, and future multipath mechanisms of QUIC are not anticipated. However, the working group should document these impacts, or those of any other QUIC developments, if they arise. The group will coordinate closely with other working groups responsible for maintaining relevant protocol extensions, such as HTTPBIS, QUIC, or TLS. It will also coordinate closely with ICCRG and TSVWG on congestion control and loss recovery considerations. Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Sun May 24 00:00:34 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA6583A0BFE; Sun, 24 May 2020 00:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=fSfHu74d; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=I3Jz4CK6 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4lKPZ0Yx-59; Sun, 24 May 2020 00:00:15 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07A5E3A0B05; Sat, 23 May 2020 23:59:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5498; q=dns/txt; s=iport; t=1590303598; x=1591513198; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=PHDRmCVMb1E2HqVbJzoge5zn8lhmhc7OhnOSM66J/6o=; b=fSfHu74dcVPTo+88TsV240Mz6cwpUw4zcZM/+k8L7cfrR4EjAF8C2S3F 2H+wuuiotGv8EzVb188BAMAJu89nR2dYkCe773sEgV0m0rLv70ii5SAN5 IJ9bmhZlOjIeSLD8S47X63O+sGv7j9ghlqnmDVLRVZoEFdXM/VgMivrS4 I=; IronPort-PHdr: =?us-ascii?q?9a23=3AxDIBmRQMgezUyLL+o4/SX8INl9psv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQB9uJ6/9Nk+vQvKrhRXdG55ud4zgOc51JAh?= =?us-ascii?q?kCj8he3wktG9WMBkCzKvn2Jzc7E8JPWB4AnTm7PEFZFdy4awjUpXu/vj4fEw?= =?us-ascii?q?3+MwV/J/juXIjfk5f/2+W74ZaGZQJOiXK0aq9zKxPjqwLXu4EWjIJuJ7x3xA?= =?us-ascii?q?HOpy5Dev9dwiVjIlfAkg=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AaAgAXGspe/4YNJK1cCRsBAQEBAQE?= =?us-ascii?q?BAQUBAQESAQEBAwMBAQFAgUeBVFEHgUcvLIQkg0YDjRsliXqOQoFCgRADVQs?= =?us-ascii?q?BAQEMAQEtAgQBAYFQgnQCF4IGJDgTAgMBAQsBAQUBAQECAQUEbYVWDIVyAQE?= =?us-ascii?q?BAQMSEREMAQE3AQsEAgEIDgMDAQIDAiYCAgIfERQBCAgCBAENBRQHB4MEgkw?= =?us-ascii?q?DLgGgcwKBOYhhdoEygwEBAQWFJw0Lgg4JgQ4qgmSJYBqBQT+BOAwQgk0+gh6?= =?us-ascii?q?BchIUGIMUM4ItjlCDFokjlyQGLUoKglSUAASEWB2CY4kCkh2FJIsqjDqRKAI?= =?us-ascii?q?EAgQFAg4BAQWBaSKBPhEHcBU7KgGCPlAYDZBABwUXg0+KVnQ3AgYBBwEBAwl?= =?us-ascii?q?8jFsBAQ?= X-IronPort-AV: E=Sophos;i="5.73,428,1583193600"; d="scan'208";a="763572237" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 May 2020 06:59:56 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 04O6xuCg015149 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 24 May 2020 06:59:56 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 24 May 2020 01:59:56 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 24 May 2020 01:59:55 -0500 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Sun, 24 May 2020 01:59:55 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lxercVfUd+s6FUOTyq2woc8NzDlM4UCDjx+axyymhhWu2aVgsruj5rFPa69dBGBkKpbpdrlwxUF4Y6IimRKc0yhQnkdXOeOuy7vS4LAMtXf/n4B2oyMx0qv9Jc36GysTFhji2aI4DAgkozeqI2L+uOM985xtca/n4ytt1ZGfvuSMscBJGB5lb0qB92amYw9Ut/g+M3HvgR0158vKsYvBDtT8ZQc6rAyNSMSe4qS9kqKUysgmXhPUoMIKXckvoiMA/D13tMlDHu1fXXHAWnIDox882kDBwjQrjmifoT+8jq2svIDIX/kB7qf+cP9yqVVGuE7JQ1pRLP/VeF4YexEdYQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PHDRmCVMb1E2HqVbJzoge5zn8lhmhc7OhnOSM66J/6o=; b=WSBK8jQH3mNHuxjst9HgRqLDdmpxryB4336mZIRKC5k93DQELt6bZ/nN69zoashgG9wLxFmSwhlTqiO0/JT3v5DgWnwiGkCnklFsCIUY92aNi98fvF5L2VmU4k3i/fLo0Bscvje7wVARXlG0/MxWY5k3KNPDqiOHAKOLyvh7r20+9Jt24bjOaNKRVolMvNBPt/tvJkBrzjcFt3aX/kYqLy/ZkAgngeFYKV8O1VMcU49ZJCSmD/DYgakuDl/MIS5N98Uc++2glVurVK6jJiiqegydSLmhUFi61DdfufVRd1mfXVFAvHVeF+5emIPg3DFGt8GYRGkxUYq3EKBnpLJMIw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PHDRmCVMb1E2HqVbJzoge5zn8lhmhc7OhnOSM66J/6o=; b=I3Jz4CK6BjHJCyFaVt2nT3n1QZYjYs0gkimjgqSThf4sbdkOoAl6F5OA92dUy7yw902MBEbMfZrVH3CkhHjlBnRrOYAAyD5ZCpC8AR13UxWP0IaS1Hgocz5M1X8vMu9MyspQuf8oF0u+zcfFjaCFqLhmMeaM+ZXvfRXr+wLhZtk= Received: from DM5PR11MB1753.namprd11.prod.outlook.com (2603:10b6:3:10d::13) by DM5PR11MB1355.namprd11.prod.outlook.com (2603:10b6:3:b::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.24; Sun, 24 May 2020 06:59:54 +0000 Received: from DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::a14c:59b6:47b0:f630]) by DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::a14c:59b6:47b0:f630%7]) with mapi id 15.20.3021.026; Sun, 24 May 2020 06:59:54 +0000 From: "Eric Vyncke (evyncke)" To: Christopher Wood , "secdir@ietf.org" CC: "dhcwg@ietf.org" , "draft-ietf-dhc-problem-statement-of-mredhcpv6.all@ietf.org" , "last-call@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-dhc-problem-statement-of-mredhcpv6-05 Thread-Index: AQHWLjhsnYfr8j9O0E2/0SzCs2NJvKi29u+A Date: Sun, 24 May 2020 06:59:54 +0000 Message-ID: References: <158993226788.7058.12159366851189346862@ietfa.amsl.com> In-Reply-To: <158993226788.7058.12159366851189346862@ietfa.amsl.com> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.37.20051002 authentication-results: heapingbits.net; dkim=none (message not signed) header.d=none;heapingbits.net; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2001:420:c0c1:36:a4c2:adc:fbc8:9ec6] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5c8572a4-a59d-4d52-0c18-08d7ffb00fe5 x-ms-traffictypediagnostic: DM5PR11MB1355: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0413C9F1ED x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: zozz0Ir78OzcJBgcZOfw2PIO+Nm16Tz/h6X4UsAIFD6A93JjfNmvUvhdkPpTmp46IBu160EDXCjOLcZ4+68YEn0BZs1P1ePzElDoBtBm6pWJNZaQvcGqGbhT6FTZVnspcA5mzXPNIZLoMQMZlOYYmMcoon/UzpWpmLK3/WbwRoyezvGzPbiIAIWqr8AhT2yI7JKKj+tN4TCh6ZSk2ebHS+UCu8fhRGZXtPHHoOuj725IxshCu0kveTW4q8J+78NIYz+oBAlBgM7Zrm+KiJaCe1MLiY/0x5jwS3nFYxhqjl0q/D8Er0cq47Z2h3TQoNwz x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR11MB1753.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(136003)(376002)(396003)(366004)(346002)(316002)(6506007)(53546011)(8936002)(186003)(478600001)(36756003)(86362001)(2906002)(33656002)(4326008)(6512007)(66574014)(64756008)(91956017)(76116006)(66946007)(5660300002)(2616005)(71200400001)(66476007)(66556008)(66446008)(6486002)(54906003)(8676002)(110136005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: ZHbk3QRnUXII7+Z2b1VB/7Rx4tirEsMG4GoXQCf7QS86GDfnENE97WC7ctzjpl11pymG1b6YTLpW5uv0Y/Jia+Ry5+oVpCsh7ChaW1rha48nJuFrUnvWruO8B8KUIdBB0BTsxyKQ7bwwK2R88ImqVxkZKnUeWeNnrNePfdsqMTPyywQ/rEV/jrQRj6hHRYXUuOFlWvgvioBeBaecPsGopkZHuliFfJitYb+0YhNHAJShKBFAq/x3QJvxjx3ZFHT2CHNgUKC57CUpiNRkFCSfMx5S19yk9YGiPsNcHE4bDtNPADW0arn4LAMeh6hwIQP4MK4/YOwkgtKvo8mY7T55f+guiBYZs5PwWcoNQSJbIl6ikZK0mNGdPHBTgg8VAmCmWJ5krU4Bn1Vvcc8wxGWPo77+2JqBe0GKtEZvx6Xgl3co/iJJJIEdEsPvzk68O3y6dlu5VbZ+QLpe2VpgHIe4yqaAiK6wwRhzHnPa/qqx4v9WAdbI4FIEL/vRkcMw6uFZCPiMQ1X9ocsos2clpDWDucpOdngyA3HOiJNyWuK5QaM= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 5c8572a4-a59d-4d52-0c18-08d7ffb00fe5 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 May 2020 06:59:54.1271 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: vSSZii94nouBkIubowpfmD7RpxpMy454gNgp/mq+X0Bz2HqYgOq/HbfzgC+cpUghWn1E7vPF3AZ0HrA8grk6gg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1355 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-dhc-problem-statement-of-mredhcpv6-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 May 2020 07:00:25 -0000 VGhhbmsgeW91IENocmlzIGZvciB5b3VyIHJldmlldy4NCg0KSSB3aWxsIHRha2UgeW91ciBhbmQg UGV0ZSdzIHJldmlld3Mgd2hlbiBjb25zaWRlcmluZyB0aGUgbmV4dCBzdGVwcy4NCg0KUmVnYXJk cw0KDQotw6lyaWMNCg0K77u/LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IENocmlz dG9waGVyIFdvb2QgdmlhIERhdGF0cmFja2VyIDxub3JlcGx5QGlldGYub3JnPg0KUmVwbHktVG86 IENocmlzdG9waGVyIFdvb2QgPGNhd0BoZWFwaW5nYml0cy5uZXQ+DQpEYXRlOiBXZWRuZXNkYXks IDIwIE1heSAyMDIwIGF0IDAxOjUxDQpUbzogInNlY2RpckBpZXRmLm9yZyIgPHNlY2RpckBpZXRm Lm9yZz4NCkNjOiAiZGhjd2dAaWV0Zi5vcmciIDxkaGN3Z0BpZXRmLm9yZz4sICJkcmFmdC1pZXRm LWRoYy1wcm9ibGVtLXN0YXRlbWVudC1vZi1tcmVkaGNwdjYuYWxsQGlldGYub3JnIiA8ZHJhZnQt aWV0Zi1kaGMtcHJvYmxlbS1zdGF0ZW1lbnQtb2YtbXJlZGhjcHY2LmFsbEBpZXRmLm9yZz4sICJs YXN0LWNhbGxAaWV0Zi5vcmciIDxsYXN0LWNhbGxAaWV0Zi5vcmc+DQpTdWJqZWN0OiBTZWNkaXIg bGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLWRoYy1wcm9ibGVtLXN0YXRlbWVudC1vZi1t cmVkaGNwdjYtMDUNClJlc2VudC1Gcm9tOiA8YWxpYXMtYm91bmNlc0BpZXRmLm9yZz4NClJlc2Vu dC1UbzogPHJlbmdhbmdAY2VybmV0LmVkdS5jbj4sIDxoZS1sMTRAbWFpbHMudHNpbmdodWEuZWR1 LmNuPiwgPGxpdXlpbmdAY2VybmV0LmVkdS5jbj4sIDx2b2x6QGNpc2NvLmNvbT4sIDx0b21hc3ou bXJ1Z2Fsc2tpQGdtYWlsLmNvbT4sIEVyaWMgVnluY2tlIDxldnluY2tlQGNpc2NvLmNvbT4sIDxl ay5pZXRmQGdtYWlsLmNvbT4sIEJlcm5pZSBWb2x6IDx2b2x6QGNpc2NvLmNvbT4NClJlc2VudC1E YXRlOiBXZWRuZXNkYXksIDIwIE1heSAyMDIwIGF0IDAxOjUxDQoNCiAgICBSZXZpZXdlcjogQ2hy aXN0b3BoZXIgV29vZA0KICAgIFJldmlldyByZXN1bHQ6IFNlcmlvdXMgSXNzdWVzDQoNCiAgICBT dW1tYXJ5OiBTZXJpZXMgSXNzdWVzDQoNCiAgICBDb21tZW50czoNCg0KICAgIC0gU2VjdGlvbiAx LiBUaGUgaW50cm9kdWN0aW9uIG5lZWRzIGEgbG90IG9mIHdvcmsuIEl0IHNlZW1zIHRvIGJlIHRy eWluZyB0byBzYXkNCiAgICBzb21ldGhpbmcsIGJ1dCBJIGNhbm5vdCB0ZWxsIHdoYXQgdGhhdCBp cy4gSXQncyBjbGFpbWVkIHRoYXQgbWFueSBkb2N1bWVudHMNCiAgICBhdHRlbXB0IHRvIGV4dGVu ZCBESENQdjYsIHlldCBubyBleHRlbnNpb25zIGFyZSBjaXRlZC4gVGhlcmUncyBtZW50aW9uIG9m DQogICAgIm11bHRpLXJlcXVpcmVtZW50IGV4dGVuc2lvbiBwcm9ibGVtcywiIGJ1dCBubyBleGFt cGxlIG9mIHN1Y2ggYSBwcm9ibGVtLg0KICAgIFRoZXJlJ3MgcmVmZXJlbmNlIHRvIHRoZSBwb3Nz aWJpbGl0eSBvZiBhZG1pbmlzdHJhdG9ycyBtb2RpZnlpbmcgREhDUHY2IGNvZGUNCiAgICAoYW5k IHBvc3NpYmx5IGJyZWFraW5nIHRoaW5ncyBpbiB0aGUgcHJvY2VzcyksIGJ1dCB0aGF0IGRvZXMg bm90IHNlZW0gcmVsZXZhbnQNCiAgICB0byBvciBmb2xsb3cgZnJvbSB0aGUgcHJldmlvdXMgdGV4 dC4gUGxlYXNlIHJldmlzZSB0aGlzIGVudGlyZSBzZWN0aW9uIGFuZCBtYWtlDQogICAgdGhlIGdv YWwgY2xlYXIuIFdoYXQgaXMgdGhlIHByb2JsZW0gYmVpbmcgc29sdmVkLCB3aHkgaXMgaXQgaW1w b3J0YW50LCBhbmQgd2hhdA0KICAgIGlzIHRoZSBzdW1tYXJ5IG9mIHRoZSBwcm9wb3NlZCBzb2x1 dGlvbj8NCg0KICAgIC0gU2VjdGlvbiAzLjIuIFRoaXMgc2VjdGlvbiBzZWVtcyBsYXJnZWx5IGly cmVsZXZhbnQuIFdoYXQgaXMgaXRzIHB1cnBvc2U/IEl0DQogICAgbWFpbmx5IGRvY3VtZW50cyBz b2Z0d2FyZSBzdXBwb3J0LCByYXRoZXIgdGhhbiAiZXh0ZW5zaW9uIHByYWN0aWNlcy4iDQoNCiAg ICAtIFNlY3Rpb24gNC4xLiBGaWd1cmUgMSBjb3VsZCBiZW5lZml0IGZyb20gc29tZSBkZXNjcmlw dGl2ZSB0ZXh0IHRvIG1hdGNoIHRoZQ0KICAgIGRpYWdyYW0uIEZvciBleGFtcGxlLCBpdCdzIGNs ZWFyIGhvdyAib3B0aW9ucyIgYXJlIHBvaW50cyBvZiBleHRlbnNpYmlsaXR5LCBidXQNCiAgICBo b3cgYXJlICJtZXNzYWdlIHByb2Nlc3NpbmcgZnVuY3Rpb25zIiBwb2ludHMgb2YgZXh0ZW5zaWJp bGl0eT8gQW4gZXhhbXBsZQ0KICAgIG1pZ2h0IGhlbHAgY2xhcmlmeS4NCg0KICAgIC0gU2VjdGlv biA0LjIuMy4gV2hhdCBkb2VzICJub3QgYWxsIERIQ1B2NiBzb2Z0d2FyZSBjb25zaWRlcnMgdGhp cyBleHRlbnNpb24iDQogICAgbWVhbj8gRG9lcyBpdCBpbXBseSB0aGF0IG5vdCBhbGwgc2VydmVy IGltcGxlbWVudHMgc3VwcG9ydCBmb3IgdGhpcyBleHRlbnNpb24sDQogICAgb3Igc29tZXRoaW5n IGVsc2U/DQoNCiAgICAtIFNlY3Rpb24gNS4gVGhpcyBzZWVtcyB0byBiZSB0aGUgY3J1eCBvZiB0 aGUgZG9jdW1lbnQsIHlldCBJIGZhaWxlZCB0byBnbGVhbg0KICAgIG11Y2ggZnJvbSBpdHMgY29u dGVudHMuIFRoZXJlIGFyZSBzb21lIGV4YW1wbGVzIG9mIGV4dGVuc2lvbnMgd2hpY2ggbWF5IHJl cXVpcmUNCiAgICBtdWx0aXBsZSBtb3JlIHRoYW4gb25lICJtb3ZpbmcgcGFydCwiIHN1Y2ggYXMg KDEpIGNsaWVudCBpZGVudGl0eSB0cmFuc21pc3Npb24NCiAgICBhbmQgKDIpIHNlcnZlciB1c2Ug b2YgdGhvc2UgaWRlbnRpdGllcyBmb3IgYWRkcmVzcyBhbGxvY2F0aW9uLiBJcyB0aGVyZQ0KICAg IGd1aWRhbmNlIHRoYXQgc2hvdWxkIGJlIGZvbGxvd2VkIGZvciBzcGVjaWZ5aW5nIHRoaXMgdHlw ZSBvZiBtdWx0aS1yZXF1aXJlbWVudA0KICAgIGV4dGVuc2lvbj8gSWYgc28sIHdoYXQgaXMgaXQ/ IChJcyB0aGF0IG5vdCB0aGUgd2hvbGUgcG9pbnQgb2YgdGhpcyBkb2N1bWVudD8pDQogICAgQXJl IHRoZXJlIGNvbnNpZGVyYXRpb25zIGFkbWluaXN0cmF0b3JzIG9yIHNwZWNpZmljYXRpb24gd3Jp dGVycyBzaG91bGQgYmUNCiAgICBtaW5kZnVsIG9mIHdoZW4gZGVzaWduaW5nIHRoZXNlIGV4dGVu c2lvbnM/IElmIHNvLCB3aGF0IGFyZSB0aGV5Pw0KDQogICAgSW4gZ2VuZXJhbCwgaXQgc2VlbXMg dGhhdCBpZiBhIGRvY3VtZW50IGlzIHRvIGVtcGhhc2l6ZSBjb25zaWRlcmF0aW9ucyBmb3INCiAg ICBmb2xrcywgdGhlbiB0aG9zZSBjb25zaWRlcmF0aW9ucyBvdXQgdG8gYmUgY2xlYXJseSBhcnRp Y3VsYXRlZC4gSW5zdGVhZCwgdGhpcw0KICAgIGRvY3VtZW50IHNlZW1zIHRvIGp1c3QgbGlzdCBz b21lIGV4YW1wbGVzIChjdXJyZW50IHByYWN0aWNlcykgd2l0aG91dCBhbnkNCiAgICBmdXJ0aGVy IGluc2lnaHQuIFRoaXMgbWFrZXMgbWUgcXVlc3Rpb24gaXRzIG92ZXJhbGwgdmFsdWUgZm9yIHRo ZSBjb21tdW5pdHkuDQoNCiAgICBOaXRzOg0KDQogICAgLSBTZWN0aW9uIDEuICJUaGUgSVAgYWRk cmVzcyBwbGF5cyBhIHNpZ25pZmljYW50IHJvbGUgaW4gdGhlIGNvbW11bmljYXRpb24gb2YNCiAg ICB0aGUgSW50ZXJuZXQuIiBEaWQgdGhpcyBtZWFuIHRvIHNheSBjb21tdW5pY2F0aW9uICpvbiog dGhlIEludGVybmV0Pw0KDQogICAgLSBQbGVhc2UgcmVtb3ZlIHVubmVjZXNzYXJ5IGdlbmRlciB0 ZXJtcyBmcm9tIHRoZSBkb2N1bWVudCAoImhpcyIpLg0KDQogICAgLSBUaGlzIHRleHQ6DQoNCiAg ICAgICBGb3IgZXhhbXBsZSwgY29uc2lkZXJpbmcgc3VjaCBhIHJlcXVpcmVtZW50IHRoYXQNCiAg ICAgICBESENQdjYgc2VydmVycyBhc3NpZ24gSVB2NiBhZGRyZXNzZXMgZ2VuZXJhdGVkIGJ5IHVz ZXIgaWRlbnRpZmllcnMgdG8NCiAgICAgICB0aGUgY2xpZW50cyBpbiBhIG5ldHdvcmsgdG8gaG9s ZCB1c2VycyBhY2NvdW50YWJsZSwgdHdvIGV4dGVuc2lvbnMNCiAgICAgICBzaG91bGQgYmUgZnVs ZmlsbGVkIHRvIG1lZXQgdGhpcyByZXF1aXJlbWVudC4NCg0KICAgIENvdWxkIHByb2JhYmx5IGJl IHNpbXBsaWZpZWQuIEFsc28sIHdoYXQgZG9lcyBpdCBtZWFuIGZvciBhbiBleHRlbnNpb24gdG8g YmUNCiAgICBmdWxmaWxsZWQ/DQoNCg0KDQo= From nobody Sun May 24 16:15:27 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2273B3A0DE8 for ; Sun, 24 May 2020 16:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0YdVHNKGbqn1 for ; Sun, 24 May 2020 16:15:20 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99F993A0DF0 for ; Sun, 24 May 2020 16:15:20 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 04ONFE4r005842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 24 May 2020 19:15:16 -0400 Date: Sun, 24 May 2020 16:15:13 -0700 From: Benjamin Kaduk To: Christopher Wood Cc: secdir@ietf.org Message-ID: <20200524231513.GN58497@kduck.mit.edu> References: <158993226788.7058.12159366851189346862@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <158993226788.7058.12159366851189346862@ietfa.amsl.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-dhc-problem-statement-of-mredhcpv6-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 May 2020 23:15:24 -0000 Thanks for the review, Chris! I skimmed the doc and agree that the main point is not readily apparent; hopefully it will get some edits before it comes to the IESG. -Ben On Tue, May 19, 2020 at 04:51:07PM -0700, Christopher Wood via Datatracker wrote: > Reviewer: Christopher Wood > Review result: Serious Issues > > Summary: Series Issues > > Comments: > > - Section 1. The introduction needs a lot of work. It seems to be trying to say > something, but I cannot tell what that is. It's claimed that many documents > attempt to extend DHCPv6, yet no extensions are cited. There's mention of > "multi-requirement extension problems," but no example of such a problem. > There's reference to the possibility of administrators modifying DHCPv6 code > (and possibly breaking things in the process), but that does not seem relevant > to or follow from the previous text. Please revise this entire section and make > the goal clear. What is the problem being solved, why is it important, and what > is the summary of the proposed solution? > > - Section 3.2. This section seems largely irrelevant. What is its purpose? It > mainly documents software support, rather than "extension practices." > > - Section 4.1. Figure 1 could benefit from some descriptive text to match the > diagram. For example, it's clear how "options" are points of extensibility, but > how are "message processing functions" points of extensibility? An example > might help clarify. > > - Section 4.2.3. What does "not all DHCPv6 software considers this extension" > mean? Does it imply that not all server implements support for this extension, > or something else? > > - Section 5. This seems to be the crux of the document, yet I failed to glean > much from its contents. There are some examples of extensions which may require > multiple more than one "moving part," such as (1) client identity transmission > and (2) server use of those identities for address allocation. Is there > guidance that should be followed for specifying this type of multi-requirement > extension? If so, what is it? (Is that not the whole point of this document?) > Are there considerations administrators or specification writers should be > mindful of when designing these extensions? If so, what are they? > > In general, it seems that if a document is to emphasize considerations for > folks, then those considerations out to be clearly articulated. Instead, this > document seems to just list some examples (current practices) without any > further insight. This makes me question its overall value for the community. > > Nits: > > - Section 1. "The IP address plays a significant role in the communication of > the Internet." Did this mean to say communication *on* the Internet? > > - Please remove unnecessary gender terms from the document ("his"). > > - This text: > > For example, considering such a requirement that > DHCPv6 servers assign IPv6 addresses generated by user identifiers to > the clients in a network to hold users accountable, two extensions > should be fulfilled to meet this requirement. > > Could probably be simplified. Also, what does it mean for an extension to be > fulfilled? > > > -- > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call From nobody Mon May 25 07:05:20 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A85B3A07F5 for ; Mon, 25 May 2020 07:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=QMc5lSDb; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=vIDRSflD Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSs1mxa_hXZ2 for ; Mon, 25 May 2020 07:05:11 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D3683A0C1B for ; Mon, 25 May 2020 07:05:11 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 8E3955C0192; Mon, 25 May 2020 10:05:10 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute1.internal (MEProxy); Mon, 25 May 2020 10:05:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm1; bh=KUtgqLqH3Yzqkm59wjgJrUUbnLFI VJM38Kc6YwopFTY=; b=QMc5lSDbYR4Y6FswwhAzLwo7DHQ8ddIZOI4q28EpK7ih A60sUluZmIqBisUbwY192Wp84qX3Vb1rWd4Np8h5DfalIwdoBerVyb0L6X0lBZYh k+TqFfWnhivY2pTYlhVpdgIN5daqfCrM4xavoudoaGLcYW7zi7SwnwE8ecrzT9d1 f08T74+A2CMvqghcN2IUW/NBiNg6KwdW698WOw4KbffOkfLRAhRe9nYWxz1UBUlu VAbsY2W0PFxAt+JymC8G/wGOvNDVYty1ITIKI1kinSnl/f9fuAgvljroDIzkoWzd w2N8QL1RlIyorUg3DuQA0aBrZ+uId5XQv5nrUaMEOQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=KUtgqL qH3Yzqkm59wjgJrUUbnLFIVJM38Kc6YwopFTY=; b=vIDRSflDdNHlmdA/m7lCNM bCsti6++YYirkcsV/t4ouRyGgglTaajrexZ7vqmBA5zWHC5x6bbw4PVo/l7u2ABU XQi6Wx86lR0sP5fqUS10bmsn39bGp3M03SR8JQBFd/KfnFlHCTdjYqj1ydBbIocQ w3ITGZhnwk5e2ShuD9/7cm0ekOFJsrpgGr6PgYJShQ+ZX5mnEnsLECUMTk+jY9wI th664bpG7tRw1k39BkWUadfSlYRKgn3cFUX6QUxOXM/iN8U3yr6T2alaMR6YOEF8 m7E67UfHP9R7lSiXYGIsLCYF7odDUd6E5SEutaps0fmMNIb8q73C2HZl9TWmtObw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddvtddgjeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreerjeenucfhrhhomhepfdevhhhr ihhsthhophhhvghrucghohhougdfuceotggrfieshhgvrghpihhnghgsihhtshdrnhgvth eqnecuggftrfgrthhtvghrnhepudffteffkeevhfdvueehffegteefgeelveegffefvdev jeehvdeugeekheelvdelnecuffhomhgrihhnpehivghtfhdrohhrghenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrphhinhhg sghithhsrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 360923C00A1; Mon, 25 May 2020 10:05:10 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-488-g9249dd4-fm-20200522.001-g9249dd48 Mime-Version: 1.0 Message-Id: <94c2afbe-c621-424e-8ac3-f7d28f7c80bc@www.fastmail.com> In-Reply-To: <20200524231513.GN58497@kduck.mit.edu> References: <158993226788.7058.12159366851189346862@ietfa.amsl.com> <20200524231513.GN58497@kduck.mit.edu> Date: Mon, 25 May 2020 07:04:49 -0700 From: "Christopher Wood" To: "Benjamin Kaduk" Cc: "secdir@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [secdir] =?utf-8?q?=5BLast-Call=5D_Secdir_last_call_review_of_dr?= =?utf-8?q?aft-ietf-dhc-problem-statement-of-mredhcpv6-05?= X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2020 14:05:18 -0000 My pleasure! I'm happy to take another look at future revisions if needed. Best, Chris On Sun, May 24, 2020, at 4:15 PM, Benjamin Kaduk wrote: > Thanks for the review, Chris! I skimmed the doc and agree that the main > point is not readily apparent; hopefully it will get some edits before it > comes to the IESG. > > -Ben > > On Tue, May 19, 2020 at 04:51:07PM -0700, Christopher Wood via > Datatracker wrote: > > Reviewer: Christopher Wood > > Review result: Serious Issues > > > > Summary: Series Issues > > > > Comments: > > > > - Section 1. The introduction needs a lot of work. It seems to be trying to say > > something, but I cannot tell what that is. It's claimed that many documents > > attempt to extend DHCPv6, yet no extensions are cited. There's mention of > > "multi-requirement extension problems," but no example of such a problem. > > There's reference to the possibility of administrators modifying DHCPv6 code > > (and possibly breaking things in the process), but that does not seem relevant > > to or follow from the previous text. Please revise this entire section and make > > the goal clear. What is the problem being solved, why is it important, and what > > is the summary of the proposed solution? > > > > - Section 3.2. This section seems largely irrelevant. What is its purpose? It > > mainly documents software support, rather than "extension practices." > > > > - Section 4.1. Figure 1 could benefit from some descriptive text to match the > > diagram. For example, it's clear how "options" are points of extensibility, but > > how are "message processing functions" points of extensibility? An example > > might help clarify. > > > > - Section 4.2.3. What does "not all DHCPv6 software considers this extension" > > mean? Does it imply that not all server implements support for this extension, > > or something else? > > > > - Section 5. This seems to be the crux of the document, yet I failed to glean > > much from its contents. There are some examples of extensions which may require > > multiple more than one "moving part," such as (1) client identity transmission > > and (2) server use of those identities for address allocation. Is there > > guidance that should be followed for specifying this type of multi-requirement > > extension? If so, what is it? (Is that not the whole point of this document?) > > Are there considerations administrators or specification writers should be > > mindful of when designing these extensions? If so, what are they? > > > > In general, it seems that if a document is to emphasize considerations for > > folks, then those considerations out to be clearly articulated. Instead, this > > document seems to just list some examples (current practices) without any > > further insight. This makes me question its overall value for the community. > > > > Nits: > > > > - Section 1. "The IP address plays a significant role in the communication of > > the Internet." Did this mean to say communication *on* the Internet? > > > > - Please remove unnecessary gender terms from the document ("his"). > > > > - This text: > > > > For example, considering such a requirement that > > DHCPv6 servers assign IPv6 addresses generated by user identifiers to > > the clients in a network to hold users accountable, two extensions > > should be fulfilled to meet this requirement. > > > > Could probably be simplified. Also, what does it mean for an extension to be > > fulfilled? > > > > > > -- > > last-call mailing list > > last-call@ietf.org > > https://www.ietf.org/mailman/listinfo/last-call > From nobody Mon May 25 17:55:00 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 569423A0891; Mon, 25 May 2020 17:54:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Liang Xia via Datatracker To: Cc: tcpm@ietf.org, last-call@ietf.org, draft-ietf-tcpm-rto-consider.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159045449615.13336.5105636835437605086@ietfa.amsl.com> Reply-To: Liang Xia Date: Mon, 25 May 2020 17:54:56 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-tcpm-rto-consider-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2020 00:54:57 -0000 Reviewer: Liang Xia Review result: Ready This document is good written, and no new security issues as it's a network mechanism requirements BCP document. From nobody Tue May 26 06:53:01 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C57863A0F7C; Tue, 26 May 2020 06:52:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?b?TWFsacWhYSBWdcSNaW5pxIcgdmlhIERhdGF0cmFja2Vy?= To: Cc: last-call@ietf.org, draft-ietf-emu-eap-session-id.all@ietf.org, emu@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159050117661.11337.1336987637854906717@ietfa.amsl.com> Reply-To: =?utf-8?b?TWFsacWhYSBWdcSNaW5pxIc=?= Date: Tue, 26 May 2020 06:52:56 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-emu-eap-session-id-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2020 13:52:59 -0000 Reviewer: Mališa Vučinić Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document updates RFC5247 to specify EAP Session-ID definition in case fast re-authentication is used with EAP-AKA and EAP-SIM. The Session-ID definition is based on a server-generated nonce and a MAC. The document also specifies the Session-ID definition for the PEAP method, following the definition of EAP-TLS. The document is clear and well written. Security considerations section is clear and states no known security issues in the definitions used. A reference to PEAP is missing. Nits: Section 3: s/to not modify/do not modify From nobody Tue May 26 09:46:19 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A01793A0A92 for ; Tue, 26 May 2020 09:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ackl-io.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPKHVMOc6Thq for ; Tue, 26 May 2020 09:46:05 -0700 (PDT) Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90E423A0A7E for ; Tue, 26 May 2020 09:46:05 -0700 (PDT) Received: by mail-il1-x131.google.com with SMTP id r2so9940808ila.4 for ; Tue, 26 May 2020 09:46:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=F9IdecfGG091m5X5fhyHhz5I8QzTQ+cd/EAt3uo+bCE=; b=bmK9mK7LtP4OPTdBW5K1qgQRkOycXfehnzKI4RQHrrPOmex655wITF1VAWN9TYGgTW 9xTlg4nnDfc2Hh7Sq0l2xFYJgWt0MHWLQTWRSqhk3Z9iCB8Nb+oOw21KmXUbgBzfHUXV oQQJP0UMkfx4Hmfry4Qgbup11G5fPsNRrGKbck0KNSCTGx/cspetHuapfF+8WxbicMvf OjtysqxJaQqwzXgT73JqgH7DjJwz0ZFuXKFeI/FY31kze/jfpCJAKxu7yQeo4kb+vZBL X8RR97yLp+DbY6eN2RxD7oQZPWBsZzC0MGi7KMErehhibL05kZIdP96Ew8MfjAND4sKE OJdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=F9IdecfGG091m5X5fhyHhz5I8QzTQ+cd/EAt3uo+bCE=; b=PsG9uK7jiBd2IxLtvbi3P2QObNUgt3/iMg5SulZiR5Y3WPbChn9ka0p8ydoGjJODkh tglrVARJHZ+dMOMRFU/rG9jsOO7CwzLGA+jY/EEqtAgIxqma01Yhk7Z/cZEBT0n6Zf94 DuCTIA2/aO5GuW/0XfNltFtPtlPrNpdkPLIQy4YS1+AheySRmvu16bifWCMeEAwoAxFh ywybFxyWs0KX9mEcL/ZbRf30ZZJnRVKp4aAlwpWUTnAeR2qVyO+KnzKZj+6iKweOMAfc AYSUgzwSs6NrXPdjCW385I05gAQsTbL/oymDG757g35BzJ2oWyDC+NgJj+oInT/y0WWO bRvw== X-Gm-Message-State: AOAM532Gx8UtQ2mRUxVK5Ej/HbHw1UivbAAPTxwGtvEgZYi/RfCL7WjX /0rEhJ7GfrI6Q5/Y+UNXfdymN26hCnoH0x+0xEJgVw== X-Google-Smtp-Source: ABdhPJxBAU/QjsnLwcCbXZcibIuKG2PH+1NIyP4SM2vg64cYaeFacG45pCpJpSf3o7O+ZebggBqRATMlulmHotcleGM= X-Received: by 2002:a92:d6cc:: with SMTP id z12mr1902574ilp.179.1590511564673; Tue, 26 May 2020 09:46:04 -0700 (PDT) MIME-Version: 1.0 References: <158231113340.29033.17150460168186400041@ietfa.amsl.com> <20200221202332.GC53538@kduck.mit.edu> In-Reply-To: <20200221202332.GC53538@kduck.mit.edu> From: Ana Minaburo Date: Tue, 26 May 2020 18:45:38 +0200 Message-ID: To: Benjamin Kaduk Cc: Paul Wouters , secdir@ietf.org, lp-wan , last-call@ietf.org, draft-ietf-lpwan-coap-static-context-hc.all@ietf.org Content-Type: multipart/alternative; boundary="000000000000d2df0505a68fd4c5" Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call partial review of draft-ietf-lpwan-coap-static-context-hc-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2020 16:46:08 -0000 --000000000000d2df0505a68fd4c5 Content-Type: text/plain; charset="UTF-8" Thank you for your review, a new version of the draft has been published today with a new security section. We have discussed this section during the virtual IETF meeting taking your inputs into account. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lpwan-coap-static-context-hc/ Ana On Fri, Feb 21, 2020 at 9:23 PM Benjamin Kaduk wrote: > Hi Paul, > > Thanks for doing the review and raising the potentially serious issues. > > On Fri, Feb 21, 2020 at 10:52:13AM -0800, Paul Wouters via Datatracker > wrote: > > > > Review is partially done. Another assignment may be needed to complete > it. > > > > Reviewer: Paul Wouters > > Review result: Serious Issues > > > > I have reviewed this document as part of the security directorate's > > ongoing effort to review all IETF documents being processed by the > > IESG. These comments were written primarily for the benefit of the > > security area directors. Document editors and WG chairs should treat > > these comments just like any other last call comments. > > > > I agree with the comments raised by the genart review by Theresa > Enghardt. The > > Security Section is just a reference to another document that specifies > in its > > own Security Consideration: > > > > As explained in Section 5, SCHC is expected to be implemented on top > > of LPWAN technologies, which are expected to implement security > > measures. > > > > This document explains that packets are wrapped in CoAP and then this > document > > can be used to compress fields, similar to the references document. But > now > > this is happening in the most outer layer, which the referenced document > > basically states that in its Security Considerations, it assumes the > outer > > layer has some kind of LPWAN based security meassures in place. > > > > It seems these two drafts need some coordination to determine where, how > and > > which Security Considerations are relevant. > > It does seem like it, since CoAP is not guaranteed to be used over a > physical medium with integrated security technologies (though many expected > use cases do). > > > Additionally, I'm a bit worried about multiple layers doing compression. > Can > > this lead to security issues? If not, why not? > > > > Where is it sais that compression states need to be checked for bogus > > instructions? How are these prevented? Think of the ever-decompressing > zip file > > hacks of the past. How are these DoS attacks prevented ? > > I think the "static context" nature of this compression mechanism prevents > issues with near-infinite expansion, at least, though there would of course > still be room for bugs when handling noncompliant input. > > -Ben > > > Other than this issue, I found Section 1 Introducion a bit confusing. It > seems > > to drop a reference to another document and then explain that other > document, > > without really talking about this document? Or if it does, it was not > very > > clear to me. > > > > I did not review this document for nits - my apologies but I ran out of > time. > > > > > > -- > > last-call mailing list > > last-call@ietf.org > > https://www.ietf.org/mailman/listinfo/last-call > --000000000000d2df0505a68fd4c5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you= for your review, a new version of the draft has been published today with = a new security section. We have discussed=C2=A0this section during the virt= ual IETF meeting taking your inputs into account.

The IETF datatracker status page for this draft is= :
https://datatracker.ietf.org= /doc/draft-ietf-lpwan-coap-static-context-hc/

Ana
=
On Fri= , Feb 21, 2020 at 9:23 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
Hi Paul,

Thanks for doing the review and raising the potentially serious issues.

On Fri, Feb 21, 2020 at 10:52:13AM -0800, Paul Wouters via Datatracker wrot= e:
>
> Review is partially done. Another assignment may be needed to complete= it.
>
> Reviewer: Paul Wouters
> Review result: Serious Issues
>
> I have reviewed this document as part of the security directorate'= s
> ongoing effort to review all IETF documents being processed by the
> IESG.=C2=A0 These comments were written primarily for the benefit of t= he
> security area directors.=C2=A0 Document editors and WG chairs should t= reat
> these comments just like any other last call comments.
>
> I agree with the comments raised by the genart review by Theresa Engha= rdt. The
> Security Section is just a reference to another document that specifie= s in its
> own Security Consideration:
>
>=C2=A0 =C2=A0As explained in Section 5, SCHC is expected to be implemen= ted on top
>=C2=A0 =C2=A0 of LPWAN technologies, which are expected to implement se= curity
>=C2=A0 =C2=A0 measures.
>
> This document explains that packets are wrapped in CoAP and then this = document
> can be used to compress fields, similar to the references document. Bu= t now
> this is happening in the most outer layer, which the referenced docume= nt
> basically states that in its Security Considerations, it assumes the o= uter
> layer has some kind of LPWAN based security meassures in place.
>
> It seems these two drafts need some coordination to determine where, h= ow and
> which Security Considerations are relevant.

It does seem like it, since CoAP is not guaranteed to be used over a
physical medium with integrated security technologies (though many expected=
use cases do).

> Additionally, I'm a bit worried about multiple layers doing compre= ssion. Can
> this lead to security issues? If not, why not?
>
> Where is it sais that compression states need to be checked for bogus<= br> > instructions? How are these prevented? Think of the ever-decompressing= zip file
> hacks of the past. How are these DoS attacks prevented ?

I think the "static context" nature of this compression mechanism= prevents
issues with near-infinite expansion, at least, though there would of course=
still be room for bugs when handling noncompliant input.

-Ben

> Other than this issue, I found Section 1 Introducion a bit confusing. = It seems
> to drop a reference to another document and then explain that other do= cument,
> without really talking about this document? Or if it does, it was not = very
> clear to me.
>
> I did not review this document for nits - my apologies but I ran out o= f time.
>
>
> --
> last-call mailing list
> last-call@ietf= .org
> https://www.ietf.org/mailman/listinfo/last-call<= /a>
--000000000000d2df0505a68fd4c5-- From nobody Tue May 26 13:22:29 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DEBB3A0400 for ; Tue, 26 May 2020 13:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3hc52_VEEpA for ; Tue, 26 May 2020 13:22:26 -0700 (PDT) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E3D33A03FE for ; Tue, 26 May 2020 13:22:26 -0700 (PDT) Received: by mail-qk1-x733.google.com with SMTP id n141so9666282qke.2 for ; Tue, 26 May 2020 13:22:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version:content-transfer-encoding; bh=LOhAhEY2jJD4oM8dzYI6G9Y4fgIbi9g5/UkvMEVQaiU=; b=fEvArAJ0BFrGamOpxA4dUNlC+ila/LM1ElmtyPSh1mccs/ddxCPVsgPOT/lkw+glt7 bZp2v1eFI8z7lCeqYXfvfHkA2DHyMXtGPoQ0sXdavkhhYxquuFLnk+wwVin9BDh3VQ2a T1/1hyF9JqJhbI/F84z18HmEcR4O9KV6pSADs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:mime-version:content-transfer-encoding; bh=LOhAhEY2jJD4oM8dzYI6G9Y4fgIbi9g5/UkvMEVQaiU=; b=O24SZH7KfR8btm6cd6oqjhVGxTk+bhfLzCaP2gbwKFT5eTwQQzzqvH/TQGSwRGNvaX Pph/sBqbHjVOj78+D1Tn2zQXS/9+jv3PKPKIlfLSeat/J9pqZfMiDG/xoHrbKTDbpi83 TuwZpPu1If0BOo+5yIQ+oaRwhYLlpsiWDEosxotlmo+BOVyiIsjyHT9GS8xU+MKrLXco UtlUaZ/4ZtyrOeE3KSG7RZMG96MdSvYibFFGyJv65qGS5dCNvtotFMLvZp+k67+eGeGb 8oodbZtCGjCglTGPXiVLk4FIRY/Je8hO+NT5LJjGFaB/OysjFSeSFkTl9NNlT6pHISNu 2eDQ== X-Gm-Message-State: AOAM530ZlJTlcaRWmBWioYbsgBAqLgqLL+EbV2z+2FRetN0uGdASdCiB y2+kYu9jWwDxIpjoR0nro+orQ6N4yMQjdw== X-Google-Smtp-Source: ABdhPJzp7Vi23LV0cMB1vpO9bNckLux2Ahra1/7V2R7OUpQmsm3XvxzlKmP3DpeFCvUFF9eLSGxxBg== X-Received: by 2002:ae9:f811:: with SMTP id x17mr606182qkh.71.1590524544814; Tue, 26 May 2020 13:22:24 -0700 (PDT) Received: from [192.168.2.143] (pool-108-18-106-102.washdc.fios.verizon.net. [108.18.106.102]) by smtp.gmail.com with ESMTPSA id a82sm584382qkb.29.2020.05.26.13.22.23 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 May 2020 13:22:24 -0700 (PDT) User-Agent: Microsoft-MacOutlook/10.10.16.200509 Date: Tue, 26 May 2020 16:22:23 -0400 From: Carl Wallace To: , , Message-ID: <0269AE59-1EBB-4E40-BBD5-E65F0A07E45B@redhoundsoftware.com> Thread-Topic: secdir last call review of draft-ietf-dhc-slap-quadrant-07 Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: [secdir] secdir last call review of draft-ietf-dhc-slap-quadrant-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2020 20:22:28 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document proposes extensions to DHCPv6 protocols to enable a DHCPv6 client or a DHCPv6 relay to indicate a preferred SLAP quadrant to the server, so that the server allocates the MAC address to the given client out of the quadrant requested by relay or client. The document is generally clear but I do have a few comments listed below. That the security considerations were incorporated by reference seems fine. - The document should expand acronyms on first use, for example U/L in first sentence of section 1, instead of leaving these to referenced documents. - Figures 3 and 4 reference a timer expiring but the prose does not. Including verbiage similar to second paragraph in section 4.3 of draft-ietf-dhc-mac-assign-05 may be worth doing. - Section 3 may benefit from providing rationale for the preferences given, i.e., why might ELI/SAI be good, etc. Framing the criteria in terms of the quadrants instead of type of device may be helpful in addition as well, if a best practices type guidance is reasonable. - Also in Section 3, I am not familiar with the IEEE specs that govern the addresses associated with the SAI quadrant, but Section 3 created an impression that a client has a freehand to choose between SAI and other options that wouldn't seem appropriate for a quadrant governed by other standards. From nobody Tue May 26 14:23:18 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 634103A0834; Tue, 26 May 2020 14:23:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Nancy Cam-Winget via Datatracker To: Cc: cose@ietf.org, last-call@ietf.org, draft-ietf-cose-rfc8152bis-algs.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159052818935.17307.5095159295288146706@ietfa.amsl.com> Reply-To: Nancy Cam-Winget Date: Tue, 26 May 2020 14:23:09 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-cose-rfc8152bis-algs-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2020 21:23:10 -0000 Reviewer: Nancy Cam-Winget Review result: Has Nits IOTDIR review of draft-ietf-cose-rfc8152bis-algs-08 Reviewer: Nancy Cam-Winget I have reviewed this document as part of the security directorate'sÊ ongoing effort to review all IETF documents being processed by theÊ IESG.ÊÊThese comments were written primarily for the benefit of theÊ security area directors.ÊÊDocument editors and WG chairs should treatÊ these comments just like any other last call comments. This document describes an initial set of cryptographic algorithms used to protect CBOR, I believe this document is almost ready, barring some editorial nits (I only made a few below). In general, the description of the "initial" set of algorithms used in COSE make sense and it is good to see each section carry their own security section for better mapping of the considerations based on the security algorithm applied. As a reader (like myself) who is not fully versant to the nuances of CBOR it was a little hard to follow as the structures and taxonomy is described in the companion draft (draft-ietf-cose-rfc8152bis-struct). As a whole, I think the document is close to ready, I only noted a few technical and editorial nits for the earlier sections below: Section 2.1: - What field does the ECDSA algorithm value map to? I presume it is the 'alg' field (if present)? But should be made explicit. - It seems that the "should" in the 4th paragraph is normative (e.g. SHOULD) as it is needed for interoperability, and perhaps even a MUST as I'm not seeing negotiation or selection of curve choice. So, if it is to be implicit, then a MUST would be more appropriate. Section 2.2: - The rationaleThere may be some corner case in which there may be a very large (2K?) structure to be protected. It would be better to quantify "extremely large" or perhaps another/additional rationale for the need to ONLY do Pure edDSA is the intent for constrained devices not have enough memory to compute the block updates. Section 4.1.1: - GCM's limitation for one encryption string is 2^39-256 e.g. not "a single key"....so sufficiently large for COSE! However, it does mean that the nonce MUST be unique for every encrypted message (e.g. the bullet before this one is correct). I think the limit for one key using GCM is based on the size of the nonce as it must be unique. Section 4.2: - 'k' is the key size in bits (I presume), would be good to describe that before the table. Editorial nits: Section 1.5 - The second sentence is hard to parse. Is it that the intermediate values used for debugging are represented in both a hex as well as a CBOR diagnostic notation format"? - Third sentence, is it that some examples were designed to fail (e.g. they are "failure test bases")? Section 2.2: - The rationale for why Pure EdDSA is used only (vs. HashEdDSA) may leave more room for questions; as there may be some corner case in which there may be a very large (2K?) structure to be protected. For those that are in the healthcare sector (of IoT), I could see potential for large blocks and may wonder what qualifies as "extremely large". RFC 8032 speaks to HashEdDSA as providing better collision resilience...so am inclined to suggest to either remove this rationale or be more complete in justification. Section 3.1 - 3rd paragraph: "Some recipient algorithms carry the key while others derive a key from secret data"....I think you mean "Some algorithms are used to transmit a key, e.g. key wrapping." "Carry the key", in this sentence leads me to imply it's the same key being used in the HMAC. From nobody Tue May 26 16:51:32 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D29F3A0BE2; Tue, 26 May 2020 16:51:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Linda Dunbar via Datatracker To: Cc: cose@ietf.org, draft-ietf-cose-webauthn-algorithms.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159053708200.16306.10159573848968846851@ietfa.amsl.com> Reply-To: Linda Dunbar Date: Tue, 26 May 2020 16:51:22 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-cose-webauthn-algorithms-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2020 23:51:22 -0000 Reviewer: Linda Dunbar Review result: Not Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document is to list down the COSE&JOSE Algorithms to be registered to IANA. But it seems the description is not complete. In the Section 2: among the 4 algorithms listed under RSASSA-PKCS1-v1_5, three are NOT recommended, one is deprecated. Under the Security Consideration (Section 5), Section 5.2 describes why SHA-2 is "Not Recommended", Section 5.3 describes why SHA-1 is "Deprecated". What about the description on why SHA-512, SHA-384, and SHA-256 are not recommended? Is the missing description intended? Best Regards, Linda Dunbar From nobody Tue May 26 19:57:45 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5824D3A0D63; Tue, 26 May 2020 19:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U52HBRnkKoaH; Tue, 26 May 2020 19:57:41 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ED923A0D62; Tue, 26 May 2020 19:57:41 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 26 May 2020 19:57:33 -0700 From: Jim Schaad To: 'Nancy Cam-Winget' , CC: , , References: <159052818935.17307.5095159295288146706@ietfa.amsl.com> In-Reply-To: <159052818935.17307.5095159295288146706@ietfa.amsl.com> Date: Tue, 26 May 2020 19:57:31 -0700 Message-ID: <037801d633d2$92f189a0$b8d49ce0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQFNVp5fEKHTIFH++NxvYlUu0haDFanM9nMQ X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-cose-rfc8152bis-algs-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2020 02:57:43 -0000 Nancy - one clarification please jim -----Original Message----- From: Nancy Cam-Winget via Datatracker =20 Sent: Tuesday, May 26, 2020 2:23 PM To: secdir@ietf.org Cc: cose@ietf.org; last-call@ietf.org; = draft-ietf-cose-rfc8152bis-algs.all@ietf.org Subject: Secdir last call review of draft-ietf-cose-rfc8152bis-algs-08 Reviewer: Nancy Cam-Winget Review result: Has Nits IOTDIR review of draft-ietf-cose-rfc8152bis-algs-08 Reviewer: Nancy Cam-Winget I have reviewed this document as part of the security = directorate's=C3=8A ongoing effort to review all IETF documents being = processed by the=C3=8A IESG.=C3=8A=C3=8AThese comments were written = primarily for the benefit of the=C3=8A security area = directors.=C3=8A=C3=8ADocument editors and WG chairs should treat=C3=8A = these comments just like any other last call comments. This document describes an initial set of cryptographic algorithms used = to protect CBOR, I believe this document is almost ready, barring some = editorial nits (I only made a few below). In general, the description = of the "initial" set of algorithms used in COSE make sense and it is good to see each = section carry their own security section for better mapping of the = considerations based on the security algorithm applied. As a reader = (like myself) who is not fully versant to the nuances of CBOR it was a = little hard to follow as the structures and taxonomy is described in the = companion draft (draft-ietf-cose-rfc8152bis-struct). As a whole, I think = the document is close to ready, I only noted a few technical and = editorial nits for the earlier sections below: Section 2.1: - What field does the ECDSA algorithm value map to? I presume it is the = 'alg' field (if present)? But should be made explicit. - It seems that the = "should" in the 4th paragraph is normative (e.g. SHOULD) as it is needed for = interoperability, and perhaps even a MUST as I'm not seeing negotiation = or selection of curve choice. So, if it is to be implicit, then a MUST = would be more appropriate. [JLS] I don't think I know which "should" you are talking about. The = word does not exist in that paragraph so I don't know for sure that I = have the same number. Section 2.2: - The rationaleThere may be some corner case in which there may be a = very large (2K?) structure to be protected. It would be better to quantify = "extremely large" or perhaps another/additional rationale for the need = to ONLY do Pure edDSA is the intent for constrained devices not have = enough memory to compute the block updates. Section 4.1.1: - GCM's limitation for one encryption string is 2^39-256 e.g. not "a = single key"....so sufficiently large for COSE! However, it does mean = that the nonce MUST be unique for every encrypted message (e.g. the = bullet before this one is correct). I think the limit for one key using = GCM is based on the size of the nonce as it must be unique. Section 4.2: - 'k' is the key size in bits (I presume), would be good to describe = that before the table. Editorial nits: Section 1.5 - The second sentence is hard to parse. Is it that the intermediate = values used for debugging are represented in both a hex as well as a = CBOR diagnostic notation format"? - Third sentence, is it that some = examples were designed to fail (e.g. they are "failure test bases")? Section 2.2: - The rationale for why Pure EdDSA is used only (vs. HashEdDSA) may = leave more room for questions; as there may be some corner case in which = there may be a very large (2K?) structure to be protected. For those = that are in the healthcare sector (of IoT), I could see potential for = large blocks and may wonder what qualifies as "extremely large". RFC = 8032 speaks to HashEdDSA as providing better collision resilience...so = am inclined to suggest to either remove this rationale or be more = complete in justification. Section 3.1 - 3rd paragraph: "Some recipient algorithms carry the key while others = derive a key from secret data"....I think you mean "Some algorithms are = used to transmit a key, e.g. key wrapping." "Carry the key", in this = sentence leads me to imply it's the same key being used in the HMAC. From nobody Wed May 27 11:20:09 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D731C3A02BE for ; Wed, 27 May 2020 11:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it.uc3m.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTfjIPpoScg0 for ; Wed, 27 May 2020 11:20:06 -0700 (PDT) Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DE383A00B2 for ; Wed, 27 May 2020 11:20:06 -0700 (PDT) Received: by mail-il1-x130.google.com with SMTP id 17so25082931ilj.3 for ; Wed, 27 May 2020 11:20:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it.uc3m.es; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2zC9OdYRirSqjW0Kj/du01aUnDX6ob2t7VwH6R+GEBo=; b=NlIcszUv1i4ibLzcq/uC+rQKn5by6WRG067iQS+awqFzlW+9ikbt42z+vE5uW2M+6G FQXVVR+9LTCn5Wp7IIZy6V4sOsSnqufug8K1/PRzBmKx23zlqYbeifbNeLzCs5INte1I qBhWzHB799pPZcTjUc6Oj59O05z5ZKEcLDEDzJO3NCRyXGKaQGmvYCju9Hw6TVUqgqqK prLQASR7aE8D8PqUk8FzBFMcNL9AqYf0Xn7f/wCRYPxM/y1iS2F0zww8diDSh3EYG3bC 4HvYohGQRk9EhDvqbo3Vcjj0OFnPsV+AAc0Mr2Jhps7MyxzH63c1g8eUgFtde0azyMHd +HHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2zC9OdYRirSqjW0Kj/du01aUnDX6ob2t7VwH6R+GEBo=; b=Mu8ZpxWca7/3WLU9Uej29WSuLv7USv0860iEPmu7JhaowKzQ4do0XXDQXh9WDr1H+V 5CElwl6ztN5m4dIaApy9PFPPU9cBcnZiaL3g3mxt+++AsobOd5BCr+figxQBTDwPiFze umZy0NJ0g/pXpvqv7JJGQ6v9nL/th7Tz5kda5TKQn8jFlcwvfnW6+tznGMyyi0AfJi+/ eJ0sHWSdTHCDrARUdyLTPfqqrxZbXrhW6svFTPq9CLHG3qlVzoa3zHEpXO/wEadMIMCZ sKvMIvahp7P1GWOFTaFNoTP/WbjPgesgJMYNyQJw8phOZOGyod4ORfKEGH57K9FQBwCJ R8BA== X-Gm-Message-State: AOAM533BmoJ5RtF/6i9myuZ//h7BZ4Zc4hPnBSkE6hSbcD9kAkzyqBT8 31T6khzwn8IwOlP37O2I654QfZSjSThRNwRW8a6xrQ== X-Google-Smtp-Source: ABdhPJwxFtZZnujXv0/h8hAp3axf2DrGkImXWbVwokMPnGt54/AiZymmNDNcOSc4+BjiCUHFi7rqiuU72n2qQt7Ou+U= X-Received: by 2002:a92:8318:: with SMTP id f24mr7073581ild.288.1590603605067; Wed, 27 May 2020 11:20:05 -0700 (PDT) MIME-Version: 1.0 References: <0269AE59-1EBB-4E40-BBD5-E65F0A07E45B@redhoundsoftware.com> In-Reply-To: <0269AE59-1EBB-4E40-BBD5-E65F0A07E45B@redhoundsoftware.com> From: CARLOS JESUS BERNARDOS CANO Date: Wed, 27 May 2020 20:19:48 +0200 Message-ID: To: Carl Wallace Cc: secdir , draft-ietf-dhc-slap-quadrant.all@ietf.org, last-call@ietf.org Content-Type: multipart/alternative; boundary="000000000000dbe94b05a6a542fb" Archived-At: Subject: Re: [secdir] secdir last call review of draft-ietf-dhc-slap-quadrant-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2020 18:20:08 -0000 --000000000000dbe94b05a6a542fb Content-Type: text/plain; charset="UTF-8" Hi Carl, Thanks a lot for your review and comments. Please see inline below. On Tue, May 26, 2020 at 10:22 PM Carl Wallace wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security area > directors. Document editors and WG chairs should treat these comments just > like any other last call comments. > > This document proposes extensions to DHCPv6 protocols to enable a DHCPv6 > client or a DHCPv6 relay to indicate a preferred SLAP quadrant to the > server, so that the server allocates the MAC address to the given client > out of the quadrant requested by relay or client. > > The document is generally clear but I do have a few comments listed below. > That the security considerations were incorporated by reference seems fine. > > - The document should expand acronyms on first use, for example U/L in > first sentence of section 1, instead of leaving these to referenced > documents. > [Carlos] Thanks. We've reviewed it and tried to expand them all the first time they appear in version -09. Some of them are a bit tricky, as they are too much "well known and widely used" by the IEEE community. > - Figures 3 and 4 reference a timer expiring but the prose does not. > Including verbiage similar to second paragraph in section 4.3 of > draft-ietf-dhc-mac-assign-05 may be worth doing. > [Carlos] Thanks. Done in future version -09. > - Section 3 may benefit from providing rationale for the preferences > given, i.e., why might ELI/SAI be good, etc. Framing the criteria in terms > of the quadrants instead of type of device may be helpful in addition as > well, if a best practices type guidance is reasonable. > [Carlos] Since the section is meant to be just some examples, we prefer to keep it as is, but I see and acknowledge your points. It's just that the goal is not to provide normative guidance, but just some examples for the need of the SLAP quadrant selection mechanisms. > > - Also in Section 3, I am not familiar with the IEEE specs that govern the > addresses associated with the SAI quadrant, but Section 3 created an > impression that a client has a freehand to choose between SAI and other > options that wouldn't seem appropriate for a quadrant governed by other > standards. > > [Carlos] Multiple protocols can be used, and the idea is that the DHCP extensions specified in this document is one of the possible protocols. As far as I know, discussion is ongoing in IEEE and this draft is part of the discussion as one existing mechanism. Thanks! Carlos --000000000000dbe94b05a6a542fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Carl,

Thanks a lot = for your review and comments. Please see inline below.

On Tue, May 26,= 2020 at 10:22 PM Carl Wallace <carl@redhoundsoftware.com> wrote:
I have reviewed this document as part of the = security directorate's ongoing effort to review all IETF documents bein= g processed by the IESG.=C2=A0 These comments were written primarily for th= e benefit of the security area directors. Document editors and WG chairs sh= ould treat these comments just like any other last call comments.

This document proposes extensions to DHCPv6 protocols to enable a DHCPv6 cl= ient or a DHCPv6 relay to indicate a preferred SLAP quadrant to the server,= so that the server allocates the MAC address to the given client out of th= e quadrant requested by relay or client.

The document is generally clear but I do have a few comments listed below. = That the security considerations were incorporated by reference seems fine.=

- The document should expand acronyms on first use, for example U/L in firs= t sentence of section 1, instead of leaving these to referenced documents. =

[Carlos] Thanks. We've reviewed it= and tried to expand them all the first time they appear in version -09. So= me of them are a bit tricky, as they are too much "well known and wide= ly used" by the IEEE community.


- Figures 3 and 4 reference a timer expiring but the prose does not. Includ= ing verbiage similar to second paragraph in section 4.3 of draft-ietf-dhc-m= ac-assign-05 may be worth doing.

[Carl= os] Thanks. Done in future version -09.


- Section 3 may benefit from providing rationale for the preferences given,= i.e., why might ELI/SAI be good, etc. Framing the criteria in terms of the= quadrants instead of type of device may be helpful in addition as well, if= a best practices type guidance is reasonable.

[Carlos] Since the section is meant to be just some examples, we p= refer to keep it as is, but I see and acknowledge your points. It's jus= t that the goal is not to provide normative guidance, but just some example= s for the need of the SLAP quadrant selection mechanisms.
=C2=A0<= /div>

- Also in Section 3, I am not familiar with the IEEE specs that govern the = addresses associated with the SAI quadrant, but Section 3 created an impres= sion that a client has a freehand to choose between SAI and other options t= hat wouldn't seem appropriate for a quadrant governed by other standard= s.

[Carlos] Multiple protocols can be used, and the idea= is that the DHCP extensions specified in this document is one of the possi= ble protocols. As far as I know, discussion is ongoing in IEEE and this dra= ft is part of the discussion as one existing mechanism.

Thanks!

Carlos
--000000000000dbe94b05a6a542fb-- From nobody Wed May 27 14:55:15 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D723B3A0CC0 for ; Wed, 27 May 2020 14:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outer-planes-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Uqx3qQWZjBu for ; Wed, 27 May 2020 14:55:05 -0700 (PDT) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A59443A0CC7 for ; Wed, 27 May 2020 14:55:05 -0700 (PDT) Received: by mail-ot1-x32e.google.com with SMTP id o13so841080otl.5 for ; Wed, 27 May 2020 14:55:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outer-planes-net.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Q84Y/NGysmFIl1Zlaok4i5hAhEX+NSRZWUttoN3MNcE=; b=Y9qV0q+JMLs9cpm5LdBETtA0fNlXBOwhNSbIigRDejrENHDYgnRRfL/LU/cFNUX7G9 TN0MTfFkImbV829TSxjU21YcuF9i41i7dv6gx5htaY4Irq6Cst3H+OaBJ5bgI9IUqU4e RzT/Kgdgc8VvAMNDXNwb+j1Z3FatrxHiGstw5Czko2Wbww8AdGido+7QgKdmqEtD2U/4 hv1ll+VcqloTCsjOI0Z0dD6t9Iqpik5RaPLOqpyQwVY/YtVq4Id7iq5U2OOR+h9nze3q 1fHoBiuPacnhp9joLqqXgW8Ny+N6IeXSePfKOfye4t6pTy8IsAGNY2LuRDdKHzzWwSRM vt4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=Q84Y/NGysmFIl1Zlaok4i5hAhEX+NSRZWUttoN3MNcE=; b=Cbh6XFgpGu2SaaYCUbtm2prljhZMm4a5cJYZFfJihn36buEhigYAOUekbJhpBmL4C5 rxmumdYS1NmbXl8r0KbGMr+zOBhofhysjqz2PYWkx6lBsBQSfkTLKhjK1ywwod5V88iq EmXtBZqcQhKEaM9Xr+cCWK+joT5iqJM2oXJ7I4wUOlgyBxlr+JXsNvPPJK9xA/Ou8ykL JKETqxPojMOyI0bayZ9v0UB52z6H/32FpI5t0oYCP/rEDyHy/hIAhUg/5fTv/oXWdtQF HWJpGZwy6XjXNX3XdK3xPmulhCLgvG725I9NZoWNXov85LfR8W6JcHSiqd0uhyvKwhTO 16Og== X-Gm-Message-State: AOAM532OMXPXpUa28ON9iLZQUUsVYhCr/TZYfZ3yuVtGBvdFFpj9GIcX n35vnXIWZEZan7XggXA98AKQVA== X-Google-Smtp-Source: ABdhPJwTw1crsPgd/NCnys07B+FdZDWZ0uGepiWGSz0X+ylyBl4vsxHiudOwex8X+wNAb/vDCSY+2w== X-Received: by 2002:a05:6830:210e:: with SMTP id i14mr135014otc.284.1590616503697; Wed, 27 May 2020 14:55:03 -0700 (PDT) Received: from mmiller-44677.local ([2601:280:4f00:14a:3d29:5003:84a:2526]) by smtp.gmail.com with ESMTPSA id d15sm1104839otk.41.2020.05.27.14.55.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 27 May 2020 14:55:02 -0700 (PDT) To: Linda Dunbar , secdir@ietf.org Cc: cose@ietf.org, draft-ietf-cose-webauthn-algorithms.all@ietf.org, last-call@ietf.org References: <159053708200.16306.10159573848968846851@ietfa.amsl.com> From: "Matthew A. Miller" Autocrypt: addr=linuxwolf+ietf@outer-planes.net; prefer-encrypt=mutual; keydata= mQENBFJoAooBCADQmEtpbpY/4wTeKgZIuyG7HkxIFgiUeqOvtiBKj/pCA73d7Q5hCvQdGcKJ 6uZsYz3Il9oKoKFxVt90iEXspbE39g6ek19e6RsB4j0Q10l4QvH+EqeD760gs0H2yf/eYj9i uk9/VY6axdQlPsmid1zoQgCNjSM7X4/K26WGMs03sbXJpKdoonelzIlJSNfzi0q546iplo72 D2cCm9BriMkQvcGnsm4B9eBIBn3GKmVx1tsmPNeNTyun2DvaLnrYxbA0Ivo1DzZReds9NZ25 uROI/+b+lcg9/kmHzhK+q8NMQCFWmqpS/lZRKxVBSijKGpGr5h8VLVf5iURHtwG+B/QxABEB AAG0M01hdHRoZXcgQS4gTWlsbGVyIDxsaW51eHdvbGYraWV0ZkBvdXRlci1wbGFuZXMubmV0 PokBVAQTAQoAPgIbAwULCQgHAwUVCgkICwUWAgMBAAIeAQIXgBYhBDHXWI3skGkNa8yY4Oz0 ck4QngW7BQJeDg4fBQkVMJSlAAoJEOz0ck4QngW7XCcH/RBVW3Nd0ezXtL9XSn5DHJxRTb5q 6ZVIBQgVIMcH2DVzO/aCs3o1ECONHAazVGQ9b6cwHCtPWJpM0ENGx7DERa/Ay4vDeKXc1TEX VuukdGrX2zWOaFHDT/oU1SEg0C+f3JGnaTwYQ7i2KXkFuYNmqROkB+Z0PDaLu4biCYdjhkIm Yu3frzySHhEX2VVMcJA6lcqdBTE3j2+ywQ7icpiWUcvLuhCeuFER1JjTRchcXwtuiOAKPQCZ BM9B70Q73hiKKK4ylNjhLFKGomkWDqsQ6sAENn6YkWyBuXNr5Y66uFxFS0VY938o/ZoXw4tb qUIdBzMnHkHxxiNUUBb6dPkaEGO5AQ0EUmgCigEIAMD+u4fBiVDul2Mljq3CRlwyZ52RA0vq vm00F5CTBWu+K1SMdMoqKmPEHaQSRRmjE+AwjWHv96cOtWUwwyqrpEgnzof7LHXfM0hk0GUl +ZUeAePtNPyylroD+ohxx2IhE2wVW+W8XGkfyxONVsd89h7Ft05HmQellZPNjE3JUtcwrmN6 fQHgr6+NuAUkC+ygt/MtnkHPeRvp2m7FQ3OqEPKGTn9Q9oIgW9lYG2JEqaSo/ASrwbZowmrl nhKvwJGSmgwHbmvEI9LxH4HKIfGmr5TyYq6o9WDUsnNwDuEeaazxoE3qXFKVvIqfMSDwBaCV 37r7GUle7lT9+oMAKVOPmZ8AEQEAAYkBPAQYAQoAJgIbDBYhBDHXWI3skGkNa8yY4Oz0ck4Q ngW7BQJeM+W5BQkPjlg/AAoJEOz0ck4QngW7a+IIANBU7R3t17LKflQo3nSUoqMBLkjxo9/e yzKAb3u0Fjb5md+9ESrFb03w1ZUkKLh/b6leTFq50IJbfxgDlVgkTn/j0XPOmIHpfDtVYPnA /rI5sqMzjb3qFOPFZFX9Til360uv9Zc5mlkJcM57X4aLRl7wSGRXPqh7v356s+JlvLF8rBtZ 7LU5SrCWeoWZu/7NvqW+UNEOOP2xAlOId4BeYWflkpzNcSPkhAkD2Xvw/GmyOm24Im7Ef2O5 scQhEO/dG+3jU4QnSGFtLXHndHpNM20vD6T+uWUpyp5g27KrIHApWq9M3o6KR68pTOLJrMxc th8xmHLOpuWVAKEABNQRDfE= Message-ID: Date: Wed, 27 May 2020 15:55:01 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <159053708200.16306.10159573848968846851@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-cose-webauthn-algorithms-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2020 21:55:07 -0000 Hello Linda, Thanks for the review. Speaking on the author's behalf, SHA-2 is defined as the collection of hash algorithms, including all of those cited (SHA-256, SHA-384, SHA-512). Do you believe it is critical to call this out explicitly? - m&m Matthew A. Miller On 20/05/26 17:51, Linda Dunbar via Datatracker wrote: > Reviewer: Linda Dunbar > Review result: Not Ready > > I have reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area directors. > Document editors and WG chairs should treat these comments just like any other > last call comments. > > This document is to list down the COSE&JOSE Algorithms to be registered to > IANA. But it seems the description is not complete. In the Section 2: among the > 4 algorithms listed under RSASSA-PKCS1-v1_5, three are NOT recommended, one is > deprecated. Under the Security Consideration (Section 5), Section 5.2 describes > why SHA-2 is "Not Recommended", Section 5.3 describes why SHA-1 is > "Deprecated". What about the description on why SHA-512, SHA-384, and SHA-256 > are not recommended? Is the missing description intended? > > Best Regards, > > Linda Dunbar > > > From nobody Wed May 27 17:22:02 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC5903A0D5F; Wed, 27 May 2020 17:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U7tv_aDdduXQ; Wed, 27 May 2020 17:21:54 -0700 (PDT) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2120.outbound.protection.outlook.com [40.107.223.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF80B3A0EB3; Wed, 27 May 2020 17:21:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TMBjRqMW3SlV3mP1F7HZkzFW/rCodRckr5TSH8W/S1pNu3tp/4gMWuYzFPlA+lFojDVQzcivm8686LKpmmhvioEN0nTXjstBxFb/+2aWs+oGZjMX8wIWv/qR0uzMIzAJaCK2miPrUdUh/pP6iQmqzeD0pLfEAIbVnE1cK4IY25CJe91pGLoCx0OyQfJqUdLjVn4yVeHqgk1FR9cxPabtLJScdzFvKBmko7tNFKHSbfrFo/ZfdC403bsRP8xNdQK2A1memGX08A3qvFpwswj+Fegj+FroAm6dhDOtPwJbwZylHvVupwwTEEdZDKfkkYUOhtCFaCKF1UL+/+Mmp6oZvw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4Kgm+iutcMQWm1ddej9y9cdRSFLgi82L0Zh5g1pEs6Q=; b=VDE5gLlMatRdwPmDhKhEWbdO57Zwydtlz8T+tjZD37OvFRVOdcmoSAapedfdJN8GK9FBJSs1lgacDKz6d/o3dfLnqBkhtZxMId2RlyAXyHivdcxoXDbSHv+1kwhnDJiu9alF5qZRWGppBgI9XYnSq/rrWvl6J2Sx9HqV+4m3ECtkrP99oPrdjjdGnA7hh1HjyT4k3cSHBkAy0N7Q0XLzlZ/WDTkBliCMZaS5goSulMrEAOKvudCc30qkA5S5lbHPehCnE4x3B+7/L+Z2Z+d8zGG13HAJWzVxnv3CdxQZ4P1QYpT/A7WDh1MnlwW6gzEJgN8n1R6XPhDBB1A877HZ0g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4Kgm+iutcMQWm1ddej9y9cdRSFLgi82L0Zh5g1pEs6Q=; b=Bd5qr6KVnfmlTIbpV3OjpGhrLwuPD+zbWrbzr0l7AUi0zWwM1cPuT54laN4uewzMGYag07T5Ka2BY3jdAH64GRHzMQAqawGtowxCk9J0Bo8oxG9KjJ68NNVVJX/iOSt9UoL8HkST2MGZUOSgUVPUAh6A+Gye0/5H11aVJeO+WNg= Received: from SN6PR13MB2334.namprd13.prod.outlook.com (2603:10b6:805:55::16) by SN6PR13MB2527.namprd13.prod.outlook.com (2603:10b6:805:58::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.10; Thu, 28 May 2020 00:21:42 +0000 Received: from SN6PR13MB2334.namprd13.prod.outlook.com ([fe80::7813:cef6:bbde:1970]) by SN6PR13MB2334.namprd13.prod.outlook.com ([fe80::7813:cef6:bbde:1970%5]) with mapi id 15.20.3045.013; Thu, 28 May 2020 00:21:42 +0000 From: Linda Dunbar To: "Matthew A. Miller" , "secdir@ietf.org" CC: "cose@ietf.org" , "draft-ietf-cose-webauthn-algorithms.all@ietf.org" , "last-call@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-cose-webauthn-algorithms-06 Thread-Index: AQHWNHF88QTcU9SYR0Gbkbt6ssDowai8okaw Date: Thu, 28 May 2020 00:21:42 +0000 Message-ID: References: <159053708200.16306.10159573848968846851@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: outer-planes.net; dkim=none (message not signed) header.d=none;outer-planes.net; dmarc=none action=none header.from=futurewei.com; x-originating-ip: [72.180.73.64] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cc248342-4212-46c0-b857-08d8029d1917 x-ms-traffictypediagnostic: SN6PR13MB2527: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0417A3FFD2 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 0AZR5L95lR2JcN04Ngcnt1KYYIxakxAqy3cUiA68Bh4m4ZWCNA4q6CTGEM80W6c79x/sOfBMF3aeQzWP0q6UckYT9EcojVS6w4CtDy/8fv+jlVLAsZGHIDiaw9DZ8sHn4bByy5cxp+7Yp95nbPu2AVC7tDi1A8xPIArAjotErvA0jpUcTPGgGTrZ50tygB2s232bo6Gx082fTWXnXfT3x30reWgtdTgpMzqaivwBNJYgw3xqCZZGhFTNx5T7lOgHDh4kdE3wAcDMs2n+9F44HS1eHjyjT8RqjYR+8DDE9Cm4C2+rqsUfVo0a1YwZwnbIPNrcpXAg9ZasK18SpfDU3Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR13MB2334.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(39850400004)(396003)(136003)(346002)(376002)(76116006)(66946007)(55016002)(5660300002)(8936002)(4326008)(9686003)(7696005)(186003)(54906003)(478600001)(83380400001)(86362001)(110136005)(2906002)(8676002)(33656002)(66476007)(53546011)(52536014)(316002)(66446008)(71200400001)(66556008)(64756008)(44832011)(26005)(6506007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 2sUqlZNxhBLTtVMUwZlyJsCfJdHqcUnOoGS6lsud/6gtKC/B7yBjLua+BwPwAt5bw/M6K8wIWKWwrGBoqXRaCu05BzYrswiK9rFtvE/DPSRj9L7G4swY5ld0qJSkSSkaJaBDF+tZCJ8KaCb+2+lQS+SyK/gbIkHEDZWjYQDzwQkkd32YbGEoOyG3FoIX5gkQzmvgv3PKaEoalycQs02xtV8DVp+mS2nIHJDuKxqhpVBzoW1b24ddgN7Jz6OuIaCnzaMlMGc4d2/YCNM9S1L3f7PRmqYNu4n5SxoivHZ7QSGztrWuKqc1wfo27W6xhQO3UzAJpPRN9/OO3B4fh6756IpV2HCTEtNMJp4N5x87B0sBJiGFLP0fGA2AZgCDEemzMsms213vUumfyxpLDEfbe7NASN1zR+Q5HPiz0iMfHROfPUTDBBKTBe+gSvV1ncEiyLkd0VKOKXTcVj+L8rOP5KovieFgqROzJBCbs9T/Sks= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-Network-Message-Id: cc248342-4212-46c0-b857-08d8029d1917 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2020 00:21:42.5242 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Sk5Ykf1R9QK+QK5wiXUzghGrAwUfnr9iZP+IMuCoqfzuS6okFzimxkIPjiiRvFhguXqiH+CIe1hFYIbP1HN6rg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR13MB2527 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-cose-webauthn-algorithms-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2020 00:21:56 -0000 TWF0dGhldywgDQoNClRoYXQgaXMgd2hhdCBJIHdhcyB0aGlua2luZy4gQ2FuIHlvdSBhZGQgYSBz ZW50ZW5jZSBpbiBTZWN0aW9uIDUuMiB0byBzYXkgdGhhdCB0aGlzIGlzIGZvciB0aGUgY29sbGVj dGlvbiBvZiBTSEEtMjU2LCBTSEEtMzg0LCBTSEEtNTEyIGFsZ29yaXRobXM/IA0KT3RoZXJ3aXNl LCB0aGUgdHdvIHNlY3Rpb25zIG9mIHRoZSBkb2N1bWVudCBkb24ndCAgbWF0Y2guIA0KDQpUaGFu ayB5b3UNCkxpbmRhIER1bmJhcg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog TWF0dGhldyBBLiBNaWxsZXIgPGxpbnV4d29sZitpZXRmQG91dGVyLXBsYW5lcy5uZXQ+IA0KU2Vu dDogV2VkbmVzZGF5LCBNYXkgMjcsIDIwMjAgNDo1NSBQTQ0KVG86IExpbmRhIER1bmJhciA8bGlu ZGEuZHVuYmFyQGZ1dHVyZXdlaS5jb20+OyBzZWNkaXJAaWV0Zi5vcmcNCkNjOiBjb3NlQGlldGYu b3JnOyBkcmFmdC1pZXRmLWNvc2Utd2ViYXV0aG4tYWxnb3JpdGhtcy5hbGxAaWV0Zi5vcmc7IGxh c3QtY2FsbEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFNlY2RpciBsYXN0IGNhbGwgcmV2aWV3IG9m IGRyYWZ0LWlldGYtY29zZS13ZWJhdXRobi1hbGdvcml0aG1zLTA2DQoNCkhlbGxvIExpbmRhLA0K DQpUaGFua3MgZm9yIHRoZSByZXZpZXcuICBTcGVha2luZyBvbiB0aGUgYXV0aG9yJ3MgYmVoYWxm LCBTSEEtMiBpcyBkZWZpbmVkIGFzIHRoZSBjb2xsZWN0aW9uIG9mIGhhc2ggYWxnb3JpdGhtcywg aW5jbHVkaW5nIGFsbCBvZiB0aG9zZSBjaXRlZCAoU0hBLTI1NiwgU0hBLTM4NCwgU0hBLTUxMiku ICBEbyB5b3UgYmVsaWV2ZSBpdCBpcyBjcml0aWNhbCB0byBjYWxsIHRoaXMgb3V0IGV4cGxpY2l0 bHk/DQoNCg0KLSBtJm0NCg0KTWF0dGhldyBBLiBNaWxsZXINCk9uIDIwLzA1LzI2IDE3OjUxLCBM aW5kYSBEdW5iYXIgdmlhIERhdGF0cmFja2VyIHdyb3RlOg0KPiBSZXZpZXdlcjogTGluZGEgRHVu YmFyDQo+IFJldmlldyByZXN1bHQ6IE5vdCBSZWFkeQ0KPiANCj4gSSBoYXZlIHJldmlld2VkIHRo aXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUncyANCj4gb25n b2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQg YnkgdGhlIA0KPiBJRVNHLiAgVGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBm b3IgdGhlIGJlbmVmaXQgb2YgdGhlIHNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLg0KPiAgRG9jdW1l bnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0 IGxpa2UgDQo+IGFueSBvdGhlciAgbGFzdCBjYWxsIGNvbW1lbnRzLg0KPiANCj4gVGhpcyBkb2N1 bWVudCBpcyB0byBsaXN0IGRvd24gdGhlIENPU0UmSk9TRSBBbGdvcml0aG1zIHRvIGJlIA0KPiBy ZWdpc3RlcmVkIHRvIElBTkEuIEJ1dCBpdCBzZWVtcyB0aGUgZGVzY3JpcHRpb24gaXMgbm90IGNv bXBsZXRlLiBJbiANCj4gdGhlIFNlY3Rpb24gMjogYW1vbmcgdGhlDQo+IDQgYWxnb3JpdGhtcyBs aXN0ZWQgdW5kZXIgUlNBU1NBLVBLQ1MxLXYxXzUsIHRocmVlIGFyZSBOT1QgDQo+IHJlY29tbWVu ZGVkLCBvbmUgaXMgZGVwcmVjYXRlZC4gVW5kZXIgdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb24g DQo+IChTZWN0aW9uIDUpLCBTZWN0aW9uIDUuMiBkZXNjcmliZXMgd2h5IFNIQS0yIGlzICJOb3Qg UmVjb21tZW5kZWQiLCANCj4gU2VjdGlvbiA1LjMgZGVzY3JpYmVzIHdoeSBTSEEtMSBpcyAiRGVw cmVjYXRlZCIuICBXaGF0IGFib3V0IHRoZSANCj4gZGVzY3JpcHRpb24gb24gd2h5IFNIQS01MTIs ICBTSEEtMzg0LCBhbmQgU0hBLTI1NiBhcmUgbm90IHJlY29tbWVuZGVkPyAgSXMgdGhlIG1pc3Np bmcgZGVzY3JpcHRpb24gaW50ZW5kZWQ/DQo+IA0KPiBCZXN0IFJlZ2FyZHMsDQo+IA0KPiBMaW5k YSBEdW5iYXINCj4gDQo+IA0KPiANCg== From nobody Wed May 27 18:02:56 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 735E23A0819; Wed, 27 May 2020 18:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=heVIqvxI; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=YY4HTU6A Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKSCPrmhHewC; Wed, 27 May 2020 18:02:42 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 318303A082B; Wed, 27 May 2020 18:02:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6402; q=dns/txt; s=iport; t=1590627762; x=1591837362; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=QCi2a5MCj9CO3Iq2iYaKS1taZR+Uo2ZCPlgifmkpENg=; b=heVIqvxIHUd+kf36F73/YyW7IMEZSgNDI2tNbgN2we1/QzlyfK8Wa8WS 6R8/lAhf+yNWmr/i4JPlGjVC5TszgdDmVa/JGMiUTJDsYV5/7l4G2p0oW CdTLI/4mQoNwhm4btqHenxkUXqTncd3RxkPUWDP0C3iwT/1Jw2g49rPjq E=; IronPort-PHdr: =?us-ascii?q?9a23=3A4dSrEhe1g1bN4btr2rcElojFlGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwaSB9fS9v1ZkPbdvqTkUHYbp52GtSNKfJ9NUk?= =?us-ascii?q?oDjsMb10wlDdWeAEL2ZPjtc2QhHctEWVMkmhPzMUVcFMvkIVGHpHq04G0bBx?= =?us-ascii?q?riLhZ+K+DxE5TJyc+w0rP695jaeQ4dgj27bPt7Jwm3qgOEsM4QjO4AYqY8wx?= =?us-ascii?q?fEuD1GYeNTkGhpPlmU2R3745S9?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CgBQCvDM9e/4QNJK1mHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgUqBUCMvB4FHLywKhBuDRgONP5hCglIDVQsBAQEMAQEtAgQ?= =?us-ascii?q?BAYREAheBfwIkOBMCAwEBCwEBBQEBAQIBBgRthVcMhXIBAQEBAxIREQwBATc?= =?us-ascii?q?BCwQCAQYCDgMEAQEDAiYCAgIwFQgIAgQBDQUigwSCTAMuAZN+kGcCgTmIYXa?= =?us-ascii?q?BMoMBAQEFhUMYgg4JgQ4qgmSJQx0aggCBESccgk0+hCaDPDOCLZFnj1yRcAq?= =?us-ascii?q?CVI45hU6EWR2CZIkDkiGQUp1pAgQCBAUCDgEBBYFqIoFWcBVlAYI+UBgNkEC?= =?us-ascii?q?DcopWdDcCBgEHAQEDCXyJdIE0AYEPAQE?= X-IronPort-AV: E=Sophos;i="5.73,443,1583193600"; d="scan'208";a="773261627" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 May 2020 01:02:41 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 04S12fsk006122 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 28 May 2020 01:02:41 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 27 May 2020 20:02:40 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 27 May 2020 20:02:40 -0500 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 27 May 2020 20:02:40 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LfFIGlFaDyFDNK92mBwFcIW5NmX8igSp+BIeGjJ8TlzOL7USf/bZNWP/0jbpS/B5MFtI1iQM7gAmTn/O9MsPRTZjJVBH0Vq/fbSpC81SioF8gfX0EkhCSYB0zUVxbBroOr2ZPc32vGfXQkSulNZXEbgjgDZKLXYG2d4PBRWUfEn6pqHoE/f7am8+jhTxho+vPLGzPIMobXYgSZksy7lS8Z6V2EfA4dryM0pokVYUYSItldAzmXRecfffwI2del0jqLjCUG4KMYwdR6h17sUSgk9M8B9F72bVQZj5spoBDjIuPCi0A1E7+5tdBGgB5JQ0t7V1v1WrEQjqQTJz+Slcqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QCi2a5MCj9CO3Iq2iYaKS1taZR+Uo2ZCPlgifmkpENg=; b=WyKze7V50Xf4SqeJaHldw6WPHPNGevDSTUySIBYA8rNrwhGTl1QKqyRiqR6OQJgzbO5qOlq/mTG+R+5hH7rKnYF0c0y8Q0E2C55QfD9Jdp0zcF89IDOMOLgpgPMu96kVslqbCYRhLXPSUsb41qlCzn7dynwlzl7mDdFxidrMfpklTWjQOyyvhxcvARRFGRYfjWdco7cq4tdIdlrPzLlzp7WmKmyw3IsLQLdXqIXMkVzEQMqq3AAXG/wuKMS7gMCKbcGx4OcEp7fSQq7lVAeEZuwQVEjIvhWSaUfYEWJKtruYHbVBdc3GTZCJ+4h4Z1H+7gs4CbVs+PtlQg6Jy3sYrg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QCi2a5MCj9CO3Iq2iYaKS1taZR+Uo2ZCPlgifmkpENg=; b=YY4HTU6Ac8RhfXz961klY/TvkivEpKaeHEqJMx0zYd14hwwh0S7OyrbiO4Zz/kwsL17ovrBtlIarnzXUtIywSOpf3Hxa5sYcSdmqcBw5PJcCgeRQHgIHBlxcd4uV2RsO3GKrMuN86xffAneEhuK+mtM8RN3hjZoTaJddGPZYzn8= Received: from BY5PR11MB4070.namprd11.prod.outlook.com (2603:10b6:a03:181::16) by BY5PR11MB4291.namprd11.prod.outlook.com (2603:10b6:a03:1c2::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.27; Thu, 28 May 2020 01:02:38 +0000 Received: from BY5PR11MB4070.namprd11.prod.outlook.com ([fe80::101e:db5b:b661:949]) by BY5PR11MB4070.namprd11.prod.outlook.com ([fe80::101e:db5b:b661:949%6]) with mapi id 15.20.3021.030; Thu, 28 May 2020 01:02:38 +0000 From: "Nancy Cam-Winget (ncamwing)" To: Jim Schaad , "secdir@ietf.org" CC: "cose@ietf.org" , "last-call@ietf.org" , "draft-ietf-cose-rfc8152bis-algs.all@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-cose-rfc8152bis-algs-08 Thread-Index: AQHWM9KZeZSj+xDsXECz02YXYKWNB6i8Ol2A Date: Thu, 28 May 2020 01:02:38 +0000 Message-ID: <4853C09B-52BB-495F-B533-E624C55A626B@cisco.com> References: <159052818935.17307.5095159295288146706@ietfa.amsl.com> <037801d633d2$92f189a0$b8d49ce0$@augustcellars.com> In-Reply-To: <037801d633d2$92f189a0$b8d49ce0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.16.200509 authentication-results: augustcellars.com; dkim=none (message not signed) header.d=none;augustcellars.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [73.162.233.180] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e335dee0-8bd8-4f39-b746-08d802a2d0eb x-ms-traffictypediagnostic: BY5PR11MB4291: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0417A3FFD2 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: f5PDTbFQS5HiMUQ1vziKHMUabHu1f71VFy/NX0+OEufCJLkMcxmF6x8Ag3PYg/a3Kd9EZniirDNYC0RirovLp5rTtG3ocHDuO652yUbEJaZiC1Y/4pQP/A3ZipWYEjubKdUg0qatwpeZAqs5+S4QA/iy1lkZcMNX5lQ0VW7fgaQ9i+0HAgQwZgdVnl20+DjHLy06Rpi5uMqVH1A2XjPgE1dBHbzNpe0fU1DAhChFrxmqxfzHML+Mv8zRoqljbJ+yWZtpBwPFfS2cxU2JDSw8l37924M9r2RwyddqbkPzrP/t5bBWW9tAKPOT7wgEfns5bxQprg03e+Myiag85obTjA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4070.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(396003)(346002)(39860400002)(136003)(376002)(2616005)(54906003)(8676002)(2906002)(4326008)(6512007)(316002)(76116006)(186003)(66476007)(36756003)(64756008)(26005)(53546011)(5660300002)(71200400001)(33656002)(478600001)(110136005)(6506007)(66446008)(86362001)(66556008)(83380400001)(8936002)(6486002)(66946007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: FUZdDEStbBdhfC9cB/Og0K6oURhgiesRaw7hPOzrS/UmE3weK8nX6ltCJJ2Knh/rl2Fykji86pOInNlo1DLEeFDpn3vwb2LG5G1LNtkpkxTw1MGoyKfLrg6a15QNJQgnE/h3pMrErJonak1fDWHXLeCUGZ/t8OgKf08ev/SNxuew2y4IF2+utKMZGBQrp9Yjmb8fED6a9svv1nkT1EsJBlpZ/Ro8OHK0QuChko7Hhvurbk3mPZH9pbg44Rr0bos7sGujrWj6c0ywhb5pGZcGtXkjpi2NboKICTv82oDAdA7F5cmdv6VvrMKNnfwx1ikcPE0bzxZK8qhUNWn5YDiARZkzZXq3m2V9oCtNWVIcuxRvzHKeMaKEffLKNRfqYFYJuN82ddClZAvEf7fvkR4ZSr1r4TLFAQ2qX1397ZISWOM5ZXFYaksBrL7dtc8cDK6ARd4f06e4LsITKCYyltuJyeC2GNrgg6xOGpiX0eRiWMNyvF+Dhui1Gi2lyCIMlpjG x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e335dee0-8bd8-4f39-b746-08d802a2d0eb X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2020 01:02:38.4182 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: BFZmROvb6gvBLnlTJU8xWsLzPWYJLNtTj+g/wlUnh9rRnvm7T77XO7HkhjNh+0OwlBxW/TOlfvu6eh5RtfUw+g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB4291 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: alln-core-10.cisco.com Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-cose-rfc8152bis-algs-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2020 01:02:52 -0000 SGkgSmltLA0KQXBvbG9naWVzIGZvciBub3QgYmVpbmcgbW9yZSBjbGVhciwgc2VlIG1vcmUgY29u dGV4dCBiZWxvdzoNCg0K77u/T24gNS8yNi8yMCwgNzo1NyBQTSwgIkppbSBTY2hhYWQiIDxpZXRm QGF1Z3VzdGNlbGxhcnMuY29tPiB3cm90ZToNCg0KICAgIE5hbmN5IC0gb25lIGNsYXJpZmljYXRp b24gcGxlYXNlDQogICAgDQogICAgamltDQogICAgDQogICAgLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCiAgICBGcm9tOiBOYW5jeSBDYW0tV2luZ2V0IHZpYSBEYXRhdHJhY2tlciA8bm9yZXBs eUBpZXRmLm9yZz4gDQogICAgU2VudDogVHVlc2RheSwgTWF5IDI2LCAyMDIwIDI6MjMgUE0NCiAg ICBUbzogc2VjZGlyQGlldGYub3JnDQogICAgQ2M6IGNvc2VAaWV0Zi5vcmc7IGxhc3QtY2FsbEBp ZXRmLm9yZzsgZHJhZnQtaWV0Zi1jb3NlLXJmYzgxNTJiaXMtYWxncy5hbGxAaWV0Zi5vcmcNCiAg ICBTdWJqZWN0OiBTZWNkaXIgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLWNvc2UtcmZj ODE1MmJpcy1hbGdzLTA4DQogICAgDQogICAgUmV2aWV3ZXI6IE5hbmN5IENhbS1XaW5nZXQNCiAg ICBSZXZpZXcgcmVzdWx0OiBIYXMgTml0cw0KICAgIA0KICAgIElPVERJUiByZXZpZXcgb2YgZHJh ZnQtaWV0Zi1jb3NlLXJmYzgxNTJiaXMtYWxncy0wOA0KICAgIA0KICAgIFJldmlld2VyOiBOYW5j eSBDYW0tV2luZ2V0DQogICAgDQogICAgSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMg cGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUnc8OKIG9uZ29pbmcgZWZmb3J0IHRvIHJl dmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZcOKIElFU0cuw4rD ilRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9m IHRoZcOKIHNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLsOKw4pEb2N1bWVudCBlZGl0b3JzIGFuZCBX RyBjaGFpcnMgc2hvdWxkIHRyZWF0w4ogdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhl ciBsYXN0IGNhbGwgY29tbWVudHMuDQogICAgDQogICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMg YW4gaW5pdGlhbCBzZXQgb2YgY3J5cHRvZ3JhcGhpYyBhbGdvcml0aG1zIHVzZWQgdG8gcHJvdGVj dCBDQk9SLCBJIGJlbGlldmUgdGhpcyBkb2N1bWVudCBpcyBhbG1vc3QgcmVhZHksIGJhcnJpbmcg c29tZSBlZGl0b3JpYWwgbml0cyAoSSBvbmx5IG1hZGUgYSBmZXcgYmVsb3cpLiAgSW4gZ2VuZXJh bCwgdGhlIGRlc2NyaXB0aW9uIG9mIHRoZSAiaW5pdGlhbCINCiAgICBzZXQgb2YgYWxnb3JpdGht cyB1c2VkIGluIENPU0UgbWFrZSBzZW5zZSBhbmQgaXQgaXMgZ29vZCB0byBzZWUgZWFjaCBzZWN0 aW9uIGNhcnJ5IHRoZWlyIG93biBzZWN1cml0eSBzZWN0aW9uIGZvciBiZXR0ZXIgbWFwcGluZyBv ZiB0aGUgY29uc2lkZXJhdGlvbnMgYmFzZWQgb24gdGhlIHNlY3VyaXR5IGFsZ29yaXRobSBhcHBs aWVkLiAgQXMgYSByZWFkZXIgKGxpa2UgbXlzZWxmKSB3aG8gaXMgbm90IGZ1bGx5IHZlcnNhbnQg dG8gdGhlIG51YW5jZXMgb2YgQ0JPUiBpdCB3YXMgYSBsaXR0bGUgaGFyZCB0byBmb2xsb3cgYXMg dGhlIHN0cnVjdHVyZXMgYW5kIHRheG9ub215IGlzIGRlc2NyaWJlZCBpbiB0aGUgY29tcGFuaW9u IGRyYWZ0IChkcmFmdC1pZXRmLWNvc2UtcmZjODE1MmJpcy1zdHJ1Y3QpLiBBcyBhIHdob2xlLCBJ IHRoaW5rIHRoZSBkb2N1bWVudCBpcyBjbG9zZSB0byByZWFkeSwgSSBvbmx5IG5vdGVkIGEgZmV3 IHRlY2huaWNhbCBhbmQgZWRpdG9yaWFsIG5pdHMgZm9yIHRoZSBlYXJsaWVyIHNlY3Rpb25zIGJl bG93Og0KICAgIA0KICAgIFNlY3Rpb24gMi4xOg0KICAgIC0gV2hhdCBmaWVsZCBkb2VzIHRoZSBF Q0RTQSBhbGdvcml0aG0gdmFsdWUgbWFwIHRvPyBJIHByZXN1bWUgaXQgaXMgdGhlICdhbGcnDQog ICAgZmllbGQgKGlmIHByZXNlbnQpPyBCdXQgc2hvdWxkIGJlIG1hZGUgZXhwbGljaXQuIC0gSXQg c2VlbXMgdGhhdCB0aGUgInNob3VsZCINCiAgICBpbiB0aGUgNHRoIHBhcmFncmFwaCBpcyBub3Jt YXRpdmUgKGUuZy4gU0hPVUxEKSBhcyBpdCBpcyBuZWVkZWQgZm9yIGludGVyb3BlcmFiaWxpdHks IGFuZCBwZXJoYXBzIGV2ZW4gYSBNVVNUIGFzIEknbSBub3Qgc2VlaW5nIG5lZ290aWF0aW9uIG9y IHNlbGVjdGlvbiBvZiBjdXJ2ZSBjaG9pY2UuICBTbywgaWYgaXQgaXMgdG8gYmUgaW1wbGljaXQs IHRoZW4gYSBNVVNUIHdvdWxkIGJlIG1vcmUgYXBwcm9wcmlhdGUuDQogICAgW0pMU10gSSBkb24n dCB0aGluayBJIGtub3cgd2hpY2ggInNob3VsZCIgeW91IGFyZSB0YWxraW5nIGFib3V0LiAgVGhl IHdvcmQgZG9lcyBub3QgZXhpc3QgaW4gdGhhdCBwYXJhZ3JhcGggc28gSSBkb24ndCBrbm93IGZv ciBzdXJlIHRoYXQgSSBoYXZlIHRoZSBzYW1lIG51bWJlci4NCltOQ1ddIFRoZSBzZW50ZW5jZSBk b2Vzbid0IGhhdmUgYSBTSE9VTEQgdGhvdWdoIEkgdGhpbmsgdGhlIHdvcmQgInN1Z2dlc3RlZCIg c2hvdWxkIGJlIHN0cm9uZ2VyOyBlLmcuICJJbiBvcmRlciB0byBwcm9tb3RlIGludGVyb3BlcmFi aWxpdHksIFNIQS0yNTYgU0hPVUxEIGJlIHVzZWQgd2l0aCBjdXJ2ZSBQLTI1Ni4uLi4iDQogICAg DQogICAgU2VjdGlvbiAyLjI6DQogICAgLSBUaGUgcmF0aW9uYWxlVGhlcmUgbWF5IGJlIHNvbWUg Y29ybmVyIGNhc2UgaW4gd2hpY2ggdGhlcmUgbWF5IGJlIGEgdmVyeSBsYXJnZQ0KICAgICgySz8p IHN0cnVjdHVyZSB0byBiZSBwcm90ZWN0ZWQuICBJdCB3b3VsZCBiZSBiZXR0ZXIgdG8gcXVhbnRp ZnkgImV4dHJlbWVseSBsYXJnZSIgb3IgcGVyaGFwcyBhbm90aGVyL2FkZGl0aW9uYWwgcmF0aW9u YWxlIGZvciB0aGUgbmVlZCB0byBPTkxZIGRvIFB1cmUgZWREU0EgaXMgdGhlIGludGVudCBmb3Ig Y29uc3RyYWluZWQgZGV2aWNlcyBub3QgaGF2ZSBlbm91Z2ggbWVtb3J5IHRvIGNvbXB1dGUgdGhl IGJsb2NrIHVwZGF0ZXMuDQogICAgDQogICAgU2VjdGlvbiA0LjEuMToNCiAgICAtIEdDTSdzIGxp bWl0YXRpb24gZm9yIG9uZSBlbmNyeXB0aW9uIHN0cmluZyBpcyAyXjM5LTI1NiBlLmcuIG5vdCAi YSBzaW5nbGUga2V5Ii4uLi5zbyBzdWZmaWNpZW50bHkgbGFyZ2UgZm9yIENPU0UhICBIb3dldmVy LCBpdCBkb2VzIG1lYW4gdGhhdCB0aGUgbm9uY2UgTVVTVCBiZSB1bmlxdWUgZm9yIGV2ZXJ5IGVu Y3J5cHRlZCBtZXNzYWdlIChlLmcuIHRoZSBidWxsZXQgYmVmb3JlIHRoaXMgb25lIGlzIGNvcnJl Y3QpLiAgSSB0aGluayB0aGUgbGltaXQgZm9yIG9uZSBrZXkgdXNpbmcgR0NNIGlzIGJhc2VkIG9u IHRoZSBzaXplIG9mIHRoZSBub25jZSBhcyBpdCBtdXN0IGJlIHVuaXF1ZS4NCiAgICANCiAgICBT ZWN0aW9uIDQuMjoNCiAgICAtICdrJyBpcyB0aGUga2V5IHNpemUgaW4gYml0cyAoSSBwcmVzdW1l KSwgd291bGQgYmUgZ29vZCB0byBkZXNjcmliZSB0aGF0IGJlZm9yZSB0aGUgdGFibGUuDQogICAg DQogICAgRWRpdG9yaWFsIG5pdHM6DQogICAgU2VjdGlvbiAxLjUNCiAgICAtIFRoZSBzZWNvbmQg c2VudGVuY2UgaXMgaGFyZCB0byBwYXJzZS4gIElzIGl0IHRoYXQgdGhlIGludGVybWVkaWF0ZSB2 YWx1ZXMgdXNlZCBmb3IgZGVidWdnaW5nIGFyZSByZXByZXNlbnRlZCBpbiBib3RoIGEgaGV4IGFz IHdlbGwgYXMgYSBDQk9SIGRpYWdub3N0aWMgbm90YXRpb24gZm9ybWF0Ij8gLSBUaGlyZCBzZW50 ZW5jZSwgaXMgaXQgdGhhdCBzb21lIGV4YW1wbGVzIHdlcmUgZGVzaWduZWQgdG8gZmFpbCAoZS5n LiB0aGV5IGFyZSAiZmFpbHVyZSB0ZXN0IGJhc2VzIik/DQogICAgDQogICAgU2VjdGlvbiAyLjI6 DQogICAgLSBUaGUgcmF0aW9uYWxlIGZvciB3aHkgUHVyZSBFZERTQSBpcyB1c2VkIG9ubHkgKHZz LiBIYXNoRWREU0EpIG1heSBsZWF2ZSBtb3JlIHJvb20gZm9yIHF1ZXN0aW9uczsgYXMgdGhlcmUg bWF5IGJlIHNvbWUgY29ybmVyIGNhc2UgaW4gd2hpY2ggdGhlcmUgbWF5IGJlIGEgdmVyeSBsYXJn ZSAoMks/KSBzdHJ1Y3R1cmUgdG8gYmUgcHJvdGVjdGVkLiAgRm9yIHRob3NlIHRoYXQgYXJlIGlu IHRoZSBoZWFsdGhjYXJlIHNlY3RvciAob2YgSW9UKSwgSSBjb3VsZCBzZWUgcG90ZW50aWFsIGZv ciBsYXJnZSBibG9ja3MgYW5kIG1heSB3b25kZXIgd2hhdCBxdWFsaWZpZXMgYXMgImV4dHJlbWVs eSBsYXJnZSIuICBSRkMgODAzMiBzcGVha3MgdG8gSGFzaEVkRFNBIGFzIHByb3ZpZGluZyBiZXR0 ZXIgY29sbGlzaW9uIHJlc2lsaWVuY2UuLi5zbyBhbSBpbmNsaW5lZCB0byBzdWdnZXN0IHRvIGVp dGhlciByZW1vdmUgdGhpcyByYXRpb25hbGUgb3IgYmUgbW9yZSBjb21wbGV0ZSBpbiBqdXN0aWZp Y2F0aW9uLg0KICAgIA0KICAgIFNlY3Rpb24gMy4xDQogICAgLSAzcmQgcGFyYWdyYXBoOiAiU29t ZSByZWNpcGllbnQgYWxnb3JpdGhtcyBjYXJyeSB0aGUga2V5IHdoaWxlIG90aGVycyBkZXJpdmUg YSBrZXkgZnJvbSBzZWNyZXQgZGF0YSIuLi4uSSB0aGluayB5b3UgbWVhbiAiU29tZSBhbGdvcml0 aG1zIGFyZSB1c2VkIHRvIHRyYW5zbWl0IGEga2V5LCBlLmcuIGtleSB3cmFwcGluZy4iICAiQ2Fy cnkgdGhlIGtleSIsIGluIHRoaXMgc2VudGVuY2UgbGVhZHMgbWUgdG8gaW1wbHkgaXQncyB0aGUg c2FtZSBrZXkgYmVpbmcgdXNlZCBpbiB0aGUgSE1BQy4NCiAgICANCiAgICANCiAgICANCiAgICAN Cg0K From nobody Thu May 28 06:00:20 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 57FC03A0E04 for ; Thu, 28 May 2020 06:00:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <159067081925.27395.6907138861533423102@ietfa.amsl.com> Date: Thu, 28 May 2020 06:00:19 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2020 13:00:19 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2020-06-11 Reviewer LC end Draft Sean Turner 2020-05-19 draft-ietf-dhc-mac-assign-06 Paul Wouters 2020-05-25 draft-ietf-capport-architecture-08 Last calls: Reviewer LC end Draft Derek Atkins 2020-05-29 draft-ietf-cose-rfc8152bis-struct-09 John Bradley 2020-02-28 draft-ietf-regext-data-escrow-09 Shaun Cooley 2020-05-29 draft-ietf-ospf-te-link-attr-reuse-12 Alan DeKok 2020-05-29 draft-ietf-isis-te-app-13 Donald Eastlake R2019-11-14 draft-ietf-hip-dex-20 Donald Eastlake 2020-02-27 draft-ietf-6tisch-msf-16 Daniel Franke 2020-03-09 draft-ietf-regext-dnrd-objects-mapping-07 Russ Mundy 2020-01-02 draft-ietf-dprive-bcp-op-09 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-11 Vincent Roca 2020-04-23 draft-ietf-detnet-ip-over-mpls-06 Stefan Santesson 2020-05-04 draft-ietf-httpbis-header-structure-18 Melinda Shore 2020-05-13 draft-ietf-secevent-http-poll-09 Tina Tsou 2020-05-08 draft-ietf-httpbis-client-hints-14 Sean Turner 2020-05-06 draft-ietf-opsawg-sdi-02 Sean Turner 2020-05-19 draft-ietf-dhc-mac-assign-06 Samuel Weiler 2020-06-11 draft-ietf-trill-multilevel-single-nickname-09 Brian Weis 2020-05-26 draft-ietf-cose-hash-algs-03 Klaas Wierenga 2020-05-26 draft-ietf-kitten-krb-spake-preauth-08 Paul Wouters 2020-05-25 draft-ietf-capport-architecture-08 Dacheng Zhang 2020-03-12 draft-nottingham-how-did-that-get-into-the-repo-01 Dacheng Zhang 2019-11-05 draft-ietf-mpls-ri-rsvp-frr-07 Next in the reviewer rotation: Shawn Emery Stephen Farrell Daniel Franke Daniel Gillmor Phillip Hallam-Baker Steve Hanna Dan Harkins Russ Housley Christian Huitema Leif Johansson From nobody Fri May 29 10:22:14 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24C563A085D; Fri, 29 May 2020 10:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gUXhvpqEoDI; Fri, 29 May 2020 10:22:11 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E41B3A084D; Fri, 29 May 2020 10:22:10 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 29 May 2020 10:22:04 -0700 From: Jim Schaad To: 'Nancy Cam-Winget' , CC: , , References: <159052818935.17307.5095159295288146706@ietfa.amsl.com> In-Reply-To: <159052818935.17307.5095159295288146706@ietfa.amsl.com> Date: Fri, 29 May 2020 10:22:02 -0700 Message-ID: <041f01d635dd$ad489cf0$07d9d6d0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQFNVp5fEKHTIFH++NxvYlUu0haDFanPMq1A X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-cose-rfc8152bis-algs-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2020 17:22:13 -0000 Hi Nancy, Comments inline. Jim -----Original Message----- From: Nancy Cam-Winget via Datatracker =20 Sent: Tuesday, May 26, 2020 2:23 PM To: secdir@ietf.org Cc: cose@ietf.org; last-call@ietf.org; = draft-ietf-cose-rfc8152bis-algs.all@ietf.org Subject: Secdir last call review of draft-ietf-cose-rfc8152bis-algs-08 Reviewer: Nancy Cam-Winget Review result: Has Nits IOTDIR review of draft-ietf-cose-rfc8152bis-algs-08 Reviewer: Nancy Cam-Winget I have reviewed this document as part of the security = directorate's=C3=8A ongoing effort to review all IETF documents being = processed by the=C3=8A IESG.=C3=8A=C3=8AThese comments were written = primarily for the benefit of the=C3=8A security area = directors.=C3=8A=C3=8ADocument editors and WG chairs should treat=C3=8A = these comments just like any other last call comments. This document describes an initial set of cryptographic algorithms used = to protect CBOR, I believe this document is almost ready, barring some = editorial nits (I only made a few below). In general, the description = of the "initial" set of algorithms used in COSE make sense and it is good to see each = section carry their own security section for better mapping of the = considerations based on the security algorithm applied. As a reader = (like myself) who is not fully versant to the nuances of CBOR it was a = little hard to follow as the structures and taxonomy is described in the = companion draft (draft-ietf-cose-rfc8152bis-struct). As a whole, I think = the document is close to ready, I only noted a few technical and = editorial nits for the earlier sections below: Section 2.1: - What field does the ECDSA algorithm value map to? I presume it is the = 'alg' field (if present)? But should be made explicit. - It seems that the = "should" in the 4th paragraph is normative (e.g. SHOULD) as it is needed for = interoperability, and perhaps even a MUST as I'm not seeing negotiation = or selection of curve choice. So, if it is to be implicit, then a MUST = would be more appropriate. [JLS] I have added text to section 1.3 (terminology) to describe the = contents of the tables to make what the value is clearer. [JLS] There is no need to negotiate the curve as this is implicit from = the size of the signature. That is P-256 is going to end up with two = 256-bit values as the signature. One implication is that only a single = curve of any given length can be assigned to ECDSA, thus the effort to = use the Ed25519 curve with ECDSA requires a different identifier so that = there is no confusion on what curve is being used. This means that the = length of the hash algorithm is not part of this selection process. It = is therefore possible to use SHA-256 with P-521 and SHA-512 with P-256 = (the hash value is truncated in this case). The only issue is that if a = piece of hardware supports the P-256 curve then it might only support = SHA-256 and thus would not be able to validate a signature that uses = SHA-512. There is no special security issue here, this is just a = recommendation for making things more likely to succeed. This is the = reason that it is not a 'SHOULD' or 'MUST' but is an 'suggested'. Does = this both make things clearer and reduce the feeling on you part that a = stronger statement is needed? Section 2.2: - The rationaleThere may be some corner case in which there may be a = very large (2K?) structure to be protected. It would be better to quantify = "extremely large" or perhaps another/additional rationale for the need = to ONLY do Pure edDSA is the intent for constrained devices not have = enough memory to compute the block updates. [JLS] I don't know that I would consider a 2K message to be very large, = I would expect a firmware update to be at least that large. The issue = is that EdDSA needs to do two passes over the message, this means that = the entire message needs to be held in memory. That would be limitation = on what I would consider to be "extremely large". The presumption is = that one is not going to try and create and stream the object out as = this would also require a streaming processing on the recipient. If = streaming is removed from the equation then there is no benefit not to = use Pure EdDSA. This means that ones idea of large is going to be very = device specific. I will not be surprised if some firmware packages do = indirect signing, but the manifest description is still going to need to = fit in memory. Section 4.1.1: - GCM's limitation for one encryption string is 2^39-256 e.g. not "a = single key"....so sufficiently large for COSE! However, it does mean = that the nonce MUST be unique for every encrypted message (e.g. the = bullet before this one is correct). I think the limit for one key using = GCM is based on the size of the nonce as it must be unique. [JLS] You are going to make me look this up again. However I think that = this limit may end up being smaller with more modern analysis so going = back and re--checking this is going to be worthwhile. It just will take = a few days. Section 4.2: - 'k' is the key size in bits (I presume), would be good to describe = that before the table. [JLS] I changed the title of the column to 'Key Length' Editorial nits: Section 1.5 - The second sentence is hard to parse. Is it that the intermediate = values used for debugging are represented in both a hex as well as a = CBOR diagnostic notation format"? - Third sentence, is it that some = examples were designed to fail (e.g. they are "failure test bases")? [JLS] I have updated this section. I think that this should solve your = issues. A GitHub project has been created at = <https://github.com/cose-wg/Examples> that contains a set of = testing examples as well.=20 Each example is found in a JSON file that contains the inputs = used to create the example, some of the intermediate values that can be = used for debugging, and the output of the example. The results are encoded using both hexadecimal and CBOR = diagnostic notation format. Some of the examples are designed to test failure case; these = are clearly marked as such in the JSON file.=20 If errors in the examples in this document are found, the = examples on GitHub will be updated, and a note to that effect will be = placed in the JSON file.=20 Section 2.2: - The rationale for why Pure EdDSA is used only (vs. HashEdDSA) may = leave more room for questions; as there may be some corner case in which = there may be a very large (2K?) structure to be protected. For those = that are in the healthcare sector (of IoT), I could see potential for = large blocks and may wonder what qualifies as "extremely large". RFC = 8032 speaks to HashEdDSA as providing better collision resilience...so = am inclined to suggest to either remove this rationale or be more = complete in justification. [JLS] See above. Section 3.1 - 3rd paragraph: "Some recipient algorithms carry the key while others = derive a key from secret data"....I think you mean "Some algorithms are = used to transmit a key, e.g. key wrapping." "Carry the key", in this = sentence leads me to imply it's the same key being used in the HMAC. [JLS] This is the same key that is being used in the HMAC algorithm. I = have changed "carry" to "transport" because I think that is going to be = clearer. From nobody Fri May 29 10:49:00 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7CE3A0E9F; Fri, 29 May 2020 10:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=f9ycjuDK; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=dCgukVFb Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5JTpo1aYiDD; Fri, 29 May 2020 10:48:50 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5EBC3A0EA1; Fri, 29 May 2020 10:48:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11558; q=dns/txt; s=iport; t=1590774530; x=1591984130; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=A0ii+NlApK/PQ0FioT7qJaTz0uTqsQ3XyISgaGdAnao=; b=f9ycjuDKCYmzODpp9wiQGPh7plgxOktIhtYkmHWx++y2Mean+yMI28rn 1sCt3RuXdxiPEUIVNYDSHPLqG1NMyILxToLILm+zlfmqr5CchZwNFw8Hf POWMBVhz/ZJ3IQnaohzK1C0B4a0eu12OlXeLKMWSyKXUCEQTdLKlKbId8 I=; IronPort-PHdr: =?us-ascii?q?9a23=3AkM6JRR2sVNlQogXGsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxWEv6dkkVDURpnQ5vZAgvDN9avnXD9I7ZWAtSUEd5pBH1?= =?us-ascii?q?8AhN4NlgMtSMiCFQXgLfHsYiB7eaYKVFJs83yhd0QAHsH4ag7bv3Kv9iIZFx?= =?us-ascii?q?H7PBBuYO/yH92ag8G+zevn/ZrVbk1Bjya8ZrUnKhKwoGCz/skbiIdvMOA/0B?= =?us-ascii?q?zM93BJYO9Rg2hvIAGe?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DbAQB1StFe/4MNJK1mGwEBAQEBAQE?= =?us-ascii?q?BBQEBARIBAQEDAwEBAUCBSoFQIy8Hb1gvLAqEG4NGA41CmEmBQoEQA1ULAQE?= =?us-ascii?q?BDAEBHw4CBAEBhEQCF4ILAiQ4EwIDAQELAQEFAQEBAgEGBG2FWQyFcgEBAQE?= =?us-ascii?q?DEhERDAEBNwELBAIBBgIOAwQBAQMCJgICAjAVCAgCBAENBSKDBAGCSwMuAQ6?= =?us-ascii?q?UbJBnAoE5iGF2gTKDAQEBBYVHGIIOAwaBDiqCZIlEHRqCAIERJxyCTT6CZwI?= =?us-ascii?q?CgTsOgy4zgi2Rb49hgSEvkCcKglSIMYtfhFsegmaQaYpFkF2BXogVk30CBAI?= =?us-ascii?q?EBQIOAQEFgWoigVZwFRpLAYI+UBcCDZBACxiDT4pWdDcCBgEHAQEDCXyKGAE?= =?us-ascii?q?mB4EGAYEPAQE?= X-IronPort-AV: E=Sophos;i="5.73,449,1583193600"; d="scan'208";a="765689458" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 May 2020 17:48:44 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 04THmi8S023176 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 29 May 2020 17:48:44 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 29 May 2020 12:48:44 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 29 May 2020 12:48:43 -0500 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 29 May 2020 13:48:42 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lOib3tlobB8p9ChPSk0W0HgFurO8YInpYRvjczxt4RpanfeLw1aq36cKY14xA3updYHzcieVIdpQ/OY+12YbP1w1MEGhnxn++o4eTHMHxFeG9ZzH61ifUUnrrBnxK/YE34Fy9z16t1LIBAzaSvacw7AJ/seh0lCbbdfpu9K4Ul0eA5CHOSs+J9vAn9JMRXRo6p0RC6tbU2/o3bLlFqYFwnb9izuyFm3CONNapKLcoG4xkfp76HkYn0HX+LZ0edIHHkvlCvlDzwACtgZU238/egLvLpVR9eXqn7CGmeqzthncDL9TRMFAaBje2H2BXRcAGTrtJKXi+uuhHAIyFwyOrA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=A0ii+NlApK/PQ0FioT7qJaTz0uTqsQ3XyISgaGdAnao=; b=IJ3Ein1OXRGBxLOJlhI8BHhvBi7ddKOP6IALeZBDg1atxwe2IgiO+QFyppFrk2ZPxNiMJSl9IzWDOrnDcmBzZW4w+OfYMt2l7EltAQrQOmWQGM40g5rnFgq+dMxKcI1E18Ab/WBmDHlfsYPLqrko70BUVz36MtN7oPtNKvHqyfYO+C7+1Dx0rztSehcSf0psz04Nomo2j5qcGOoWIwlVNfQElVhngcYsrgefDMG6h6af1UjYDQ6It8SlLTSQrDg76KKVkic+xeW7HHxxEQ84WmO6gJ6Tdb8gegPMWkygri1+CQr65DrHyhJoiH9iolK1+x00JtKi7Fq3MFSQgP/dyQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=A0ii+NlApK/PQ0FioT7qJaTz0uTqsQ3XyISgaGdAnao=; b=dCgukVFb0fPy3vTJIxkzstVpDkc+Oz2i1UiDzc9L0y0O9MAliCCGw35GLagNDyX5+rbOPgKytDeTHcmBOGBac8K7C66eEuzX/tL9rJTDb/94O7PKMTE2AfjMny2s/XG4dyiyRcRooRX4enrTEnzrbaiOMG+4DlTGrrywetUI9z0= Received: from BY5PR11MB4070.namprd11.prod.outlook.com (2603:10b6:a03:181::16) by BY5PR11MB4196.namprd11.prod.outlook.com (2603:10b6:a03:1ce::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.26; Fri, 29 May 2020 17:48:41 +0000 Received: from BY5PR11MB4070.namprd11.prod.outlook.com ([fe80::101e:db5b:b661:949]) by BY5PR11MB4070.namprd11.prod.outlook.com ([fe80::101e:db5b:b661:949%6]) with mapi id 15.20.3045.018; Fri, 29 May 2020 17:48:41 +0000 From: "Nancy Cam-Winget (ncamwing)" To: Jim Schaad , "secdir@ietf.org" CC: "cose@ietf.org" , "last-call@ietf.org" , "draft-ietf-cose-rfc8152bis-algs.all@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-cose-rfc8152bis-algs-08 Thread-Index: AQHWNd21+VD/kmDL3kuB39KUi65/xqi+4bEA Date: Fri, 29 May 2020 17:48:41 +0000 Message-ID: References: <159052818935.17307.5095159295288146706@ietfa.amsl.com> <041f01d635dd$ad489cf0$07d9d6d0$@augustcellars.com> In-Reply-To: <041f01d635dd$ad489cf0$07d9d6d0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.16.200509 authentication-results: augustcellars.com; dkim=none (message not signed) header.d=none;augustcellars.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [73.162.233.180] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4fc9b105-13ae-4584-2c61-08d803f88695 x-ms-traffictypediagnostic: BY5PR11MB4196: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 04180B6720 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ML6RvPDLNrttJoK5Y0MrRRfYC00JE9Siqg0PD5w6r6ZaHrJMcJ8acq/7xeGy29c9SSbEEq+cAWvuCN8Y7YQMIqBqW7zGL5pbzMmnAmhwOtSLg6Y8H2VUhABqd9vJf5q6MjzttL284lQt+jps7VK0RkuUcBP6itdri16alQpIXARxbDJgjI6mFJbYloZE96DNgdjdV3Kg6UPmIRtCGjv5fx2Dv8j03gbgtSEkXT+yXcscWtV9m6yno8OXfwDB5qJq+ZaOfkB2yb98BWpp9xmNy8I4PbpEwc4GrMR8tTjAlmfZJ56sjPXkRuVYmR+impdYFBrWXJpL0hYHXROCTZC+6cLSAK0xUiDH7AaTMpDYEiaUa+WZGl7bzHO4fjSwluaoPLv099BDSG39HaNYvcpWOg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4070.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(376002)(136003)(346002)(39860400002)(396003)(110136005)(316002)(4326008)(54906003)(6506007)(71200400001)(66476007)(64756008)(6512007)(83380400001)(66446008)(36756003)(66556008)(66946007)(76116006)(53546011)(6486002)(2616005)(5660300002)(8676002)(186003)(478600001)(8936002)(33656002)(86362001)(2906002)(26005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: FROM6qHfucXs+JkWytHYJ7OGMFRUD12EzSUc2npniXcgbpTzTy/GXIXjt32omgGgs62EKrtXd+l1M7O2tvQE6/b2MeTILRRnvKWjA9m1jGhWlguRrUoM8Koqs2vgCP32w5lYwpfPdFRtLyFk8zq4eZa2dwVEDpJRXdQFxF7q4V/a0baCtIbMc5k2/RBwyhBkPdzIDugfP72bNDNcAi/tvEK6u5zNgnScOwv0BdRDvlAPljOGjr/4AkMdgwR6g7avdRh7s0cHoikYQVkyKqq8TLULlVhqAE2K0EwmP+QH4d6Aw3t3kWRRvssNoAkprzsXoauY9nqOx+CGP59ojmkR3sOHxrbQJ3gxhkJD1lkLt8IYj2oRoAE5cmY5DIPebRIB67YWJM7taTtaHJe2rvtth+5UrFqrGWlifNcTMmr7XtP/CI4x2VEzo/A0PKp8WTAPg6TM0nl0lPREEINIuRCeKL7OACS+PvLuY2KBV/RmBSNDxOP0ybb5/NkLYch4Mj4z x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <242D2C4DB280D342885E315D6A7360DA@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4fc9b105-13ae-4584-2c61-08d803f88695 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 May 2020 17:48:41.5732 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: AyrAUOJ+WUOcOwfKMiPo/82sZzMKc1f7w1UEUdMqy8ftc/jNcZTtqs0R05nF5KbjTyS6+S5Q39u/zQBcmbqKrg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB4196 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: alln-core-1.cisco.com Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-cose-rfc8152bis-algs-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2020 17:48:52 -0000 SGkgSmltLA0KVGhhbmtzIGZvciBhZGRyZXNzaW5nIHRoZSBjb21tZW50cyEgIEFuc3dlcnMgYmVs b3c6DQoNCu+7v09uIDUvMjkvMjAsIDEwOjIyIEFNLCAiSmltIFNjaGFhZCIgPGlldGZAYXVndXN0 Y2VsbGFycy5jb20+IHdyb3RlOg0KDQogICAgSGkgTmFuY3ksDQogICAgDQogICAgQ29tbWVudHMg aW5saW5lLg0KICAgIA0KICAgIEppbQ0KICAgIA0KICAgIA0KICAgIC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQogICAgRnJvbTogTmFuY3kgQ2FtLVdpbmdldCB2aWEgRGF0YXRyYWNrZXIgPG5v cmVwbHlAaWV0Zi5vcmc+IA0KICAgIFNlbnQ6IFR1ZXNkYXksIE1heSAyNiwgMjAyMCAyOjIzIFBN DQogICAgVG86IHNlY2RpckBpZXRmLm9yZw0KICAgIENjOiBjb3NlQGlldGYub3JnOyBsYXN0LWNh bGxAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtY29zZS1yZmM4MTUyYmlzLWFsZ3MuYWxsQGlldGYub3Jn DQogICAgU3ViamVjdDogU2VjZGlyIGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1jb3Nl LXJmYzgxNTJiaXMtYWxncy0wOA0KICAgIA0KICAgIFJldmlld2VyOiBOYW5jeSBDYW0tV2luZ2V0 DQogICAgUmV2aWV3IHJlc3VsdDogSGFzIE5pdHMNCiAgICANCiAgICBJT1RESVIgcmV2aWV3IG9m IGRyYWZ0LWlldGYtY29zZS1yZmM4MTUyYmlzLWFsZ3MtMDgNCiAgICANCiAgICBSZXZpZXdlcjog TmFuY3kgQ2FtLVdpbmdldA0KICAgIA0KICAgIEkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50 IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3PDiiBvbmdvaW5nIGVmZm9ydCB0 byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGXDiiBJRVNH LsOKw4pUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZp dCBvZiB0aGXDiiBzZWN1cml0eSBhcmVhIGRpcmVjdG9ycy7DisOKRG9jdW1lbnQgZWRpdG9ycyBh bmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdMOKIHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkg b3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KICAgIA0KICAgIFRoaXMgZG9jdW1lbnQgZGVzY3Jp YmVzIGFuIGluaXRpYWwgc2V0IG9mIGNyeXB0b2dyYXBoaWMgYWxnb3JpdGhtcyB1c2VkIHRvIHBy b3RlY3QgQ0JPUiwgSSBiZWxpZXZlIHRoaXMgZG9jdW1lbnQgaXMgYWxtb3N0IHJlYWR5LCBiYXJy aW5nIHNvbWUgZWRpdG9yaWFsIG5pdHMgKEkgb25seSBtYWRlIGEgZmV3IGJlbG93KS4gIEluIGdl bmVyYWwsIHRoZSBkZXNjcmlwdGlvbiBvZiB0aGUgImluaXRpYWwiDQogICAgc2V0IG9mIGFsZ29y aXRobXMgdXNlZCBpbiBDT1NFIG1ha2Ugc2Vuc2UgYW5kIGl0IGlzIGdvb2QgdG8gc2VlIGVhY2gg c2VjdGlvbiBjYXJyeSB0aGVpciBvd24gc2VjdXJpdHkgc2VjdGlvbiBmb3IgYmV0dGVyIG1hcHBp bmcgb2YgdGhlIGNvbnNpZGVyYXRpb25zIGJhc2VkIG9uIHRoZSBzZWN1cml0eSBhbGdvcml0aG0g YXBwbGllZC4gIEFzIGEgcmVhZGVyIChsaWtlIG15c2VsZikgd2hvIGlzIG5vdCBmdWxseSB2ZXJz YW50IHRvIHRoZSBudWFuY2VzIG9mIENCT1IgaXQgd2FzIGEgbGl0dGxlIGhhcmQgdG8gZm9sbG93 IGFzIHRoZSBzdHJ1Y3R1cmVzIGFuZCB0YXhvbm9teSBpcyBkZXNjcmliZWQgaW4gdGhlIGNvbXBh bmlvbiBkcmFmdCAoZHJhZnQtaWV0Zi1jb3NlLXJmYzgxNTJiaXMtc3RydWN0KS4gQXMgYSB3aG9s ZSwgSSB0aGluayB0aGUgZG9jdW1lbnQgaXMgY2xvc2UgdG8gcmVhZHksIEkgb25seSBub3RlZCBh IGZldyB0ZWNobmljYWwgYW5kIGVkaXRvcmlhbCBuaXRzIGZvciB0aGUgZWFybGllciBzZWN0aW9u cyBiZWxvdzoNCiAgICANCiAgICBTZWN0aW9uIDIuMToNCiAgICAtIFdoYXQgZmllbGQgZG9lcyB0 aGUgRUNEU0EgYWxnb3JpdGhtIHZhbHVlIG1hcCB0bz8gSSBwcmVzdW1lIGl0IGlzIHRoZSAnYWxn Jw0KICAgIGZpZWxkIChpZiBwcmVzZW50KT8gQnV0IHNob3VsZCBiZSBtYWRlIGV4cGxpY2l0LiAt IEl0IHNlZW1zIHRoYXQgdGhlICJzaG91bGQiDQogICAgaW4gdGhlIDR0aCBwYXJhZ3JhcGggaXMg bm9ybWF0aXZlIChlLmcuIFNIT1VMRCkgYXMgaXQgaXMgbmVlZGVkIGZvciBpbnRlcm9wZXJhYmls aXR5LCBhbmQgcGVyaGFwcyBldmVuIGEgTVVTVCBhcyBJJ20gbm90IHNlZWluZyBuZWdvdGlhdGlv biBvciBzZWxlY3Rpb24gb2YgY3VydmUgY2hvaWNlLiAgU28sIGlmIGl0IGlzIHRvIGJlIGltcGxp Y2l0LCB0aGVuIGEgTVVTVCB3b3VsZCBiZSBtb3JlIGFwcHJvcHJpYXRlLg0KICAgIFtKTFNdIEkg aGF2ZSBhZGRlZCB0ZXh0IHRvIHNlY3Rpb24gMS4zICh0ZXJtaW5vbG9neSkgdG8gZGVzY3JpYmUg dGhlIGNvbnRlbnRzIG9mIHRoZSB0YWJsZXMgdG8gbWFrZSB3aGF0IHRoZSB2YWx1ZSBpcyBjbGVh cmVyLg0KW05DV10gVGhhbmtzLCB0aGF0IHdpbGwgaGVscC4NCiAgICANCiAgICBbSkxTXSBUaGVy ZSBpcyBubyBuZWVkIHRvIG5lZ290aWF0ZSB0aGUgY3VydmUgYXMgdGhpcyBpcyBpbXBsaWNpdCBm cm9tIHRoZSBzaXplIG9mIHRoZSBzaWduYXR1cmUuICBUaGF0IGlzIFAtMjU2IGlzIGdvaW5nIHRv IGVuZCB1cCB3aXRoIHR3byAyNTYtYml0IHZhbHVlcyBhcyB0aGUgc2lnbmF0dXJlLiAgT25lIGlt cGxpY2F0aW9uIGlzIHRoYXQgb25seSBhIHNpbmdsZSBjdXJ2ZSBvZiBhbnkgZ2l2ZW4gbGVuZ3Ro IGNhbiBiZSBhc3NpZ25lZCB0byBFQ0RTQSwgdGh1cyB0aGUgZWZmb3J0IHRvIHVzZSB0aGUgRWQy NTUxOSBjdXJ2ZSB3aXRoIEVDRFNBIHJlcXVpcmVzIGEgZGlmZmVyZW50IGlkZW50aWZpZXIgc28g dGhhdCB0aGVyZSBpcyBubyBjb25mdXNpb24gb24gd2hhdCBjdXJ2ZSBpcyBiZWluZyB1c2VkLiAg VGhpcyBtZWFucyB0aGF0IHRoZSBsZW5ndGggb2YgdGhlIGhhc2ggYWxnb3JpdGhtIGlzIG5vdCBw YXJ0IG9mIHRoaXMgc2VsZWN0aW9uIHByb2Nlc3MuICBJdCBpcyB0aGVyZWZvcmUgcG9zc2libGUg dG8gdXNlIFNIQS0yNTYgd2l0aCBQLTUyMSBhbmQgU0hBLTUxMiB3aXRoIFAtMjU2ICh0aGUgaGFz aCB2YWx1ZSBpcyB0cnVuY2F0ZWQgaW4gdGhpcyBjYXNlKS4gIFRoZSBvbmx5IGlzc3VlIGlzIHRo YXQgaWYgYSBwaWVjZSBvZiBoYXJkd2FyZSBzdXBwb3J0cyB0aGUgUC0yNTYgY3VydmUgdGhlbiBp dCBtaWdodCBvbmx5IHN1cHBvcnQgU0hBLTI1NiBhbmQgdGh1cyB3b3VsZCBub3QgYmUgYWJsZSB0 byB2YWxpZGF0ZSBhIHNpZ25hdHVyZSB0aGF0IHVzZXMgU0hBLTUxMi4gIFRoZXJlIGlzIG5vIHNw ZWNpYWwgc2VjdXJpdHkgaXNzdWUgaGVyZSwgdGhpcyBpcyBqdXN0IGEgcmVjb21tZW5kYXRpb24g Zm9yIG1ha2luZyB0aGluZ3MgbW9yZSBsaWtlbHkgdG8gc3VjY2VlZC4gVGhpcyBpcyB0aGUgcmVh c29uIHRoYXQgaXQgaXMgbm90IGEgJ1NIT1VMRCcgb3IgJ01VU1QnIGJ1dCBpcyBhbiAnc3VnZ2Vz dGVkJy4gIERvZXMgdGhpcyBib3RoIG1ha2UgdGhpbmdzIGNsZWFyZXIgYW5kIHJlZHVjZSB0aGUg ZmVlbGluZyBvbiB5b3UgcGFydCB0aGF0IGEgc3Ryb25nZXIgc3RhdGVtZW50IGlzIG5lZWRlZD8N CltOQ1ddIEFncmVlIHRoYXQgdGhlcmUgaXMgbm8gc2VjdXJpdHkgaXNzdWUsIGl0IHdhcyBtb3Jl IG9mIGJyZWFraW5nIGludGVyb3BlcmFiaWxpdHkuICBJIGRvbid0IGZlZWwgc3Ryb25nbHkgZWl0 aGVyIHdheSwgaXQgd2FzIGJ5IHRoZSB3YXkgaXQgcmVhZHMuLi4uaWYgeW91IHdhbnQgdG8gZW5z dXJlIGludGVyb3BlcmFiaWxpdHkgdGhlIGl0IHNlZW1zIHRoYXQgc3Ryb25nZXIgbGFuZ3VhZ2Ug d291bGQgYmUgbmVlZGVkIChidXQgdGhhdOKAmXMgbXkgcGVyc29uYWwgYmlhcykuDQogICAgDQog ICAgU2VjdGlvbiAyLjI6DQogICAgLSBUaGUgcmF0aW9uYWxlVGhlcmUgbWF5IGJlIHNvbWUgY29y bmVyIGNhc2UgaW4gd2hpY2ggdGhlcmUgbWF5IGJlIGEgdmVyeSBsYXJnZQ0KICAgICgySz8pIHN0 cnVjdHVyZSB0byBiZSBwcm90ZWN0ZWQuICBJdCB3b3VsZCBiZSBiZXR0ZXIgdG8gcXVhbnRpZnkg ImV4dHJlbWVseSBsYXJnZSIgb3IgcGVyaGFwcyBhbm90aGVyL2FkZGl0aW9uYWwgcmF0aW9uYWxl IGZvciB0aGUgbmVlZCB0byBPTkxZIGRvIFB1cmUgZWREU0EgaXMgdGhlIGludGVudCBmb3IgY29u c3RyYWluZWQgZGV2aWNlcyBub3QgaGF2ZSBlbm91Z2ggbWVtb3J5IHRvIGNvbXB1dGUgdGhlIGJs b2NrIHVwZGF0ZXMuDQogICAgDQogICAgW0pMU10gSSBkb24ndCBrbm93IHRoYXQgSSB3b3VsZCBj b25zaWRlciBhIDJLIG1lc3NhZ2UgdG8gYmUgdmVyeSBsYXJnZSwgSSB3b3VsZCBleHBlY3QgYSBm aXJtd2FyZSB1cGRhdGUgdG8gYmUgYXQgbGVhc3QgdGhhdCBsYXJnZS4gIFRoZSBpc3N1ZSBpcyB0 aGF0IEVkRFNBIG5lZWRzIHRvIGRvIHR3byBwYXNzZXMgb3ZlciB0aGUgbWVzc2FnZSwgdGhpcyBt ZWFucyB0aGF0IHRoZSBlbnRpcmUgbWVzc2FnZSBuZWVkcyB0byBiZSBoZWxkIGluIG1lbW9yeS4g IFRoYXQgd291bGQgYmUgbGltaXRhdGlvbiBvbiB3aGF0IEkgd291bGQgY29uc2lkZXIgdG8gYmUg ImV4dHJlbWVseSBsYXJnZSIuICBUaGUgcHJlc3VtcHRpb24gaXMgdGhhdCBvbmUgaXMgbm90IGdv aW5nIHRvIHRyeSBhbmQgY3JlYXRlIGFuZCBzdHJlYW0gdGhlIG9iamVjdCBvdXQgYXMgdGhpcyB3 b3VsZCBhbHNvIHJlcXVpcmUgYSBzdHJlYW1pbmcgcHJvY2Vzc2luZyBvbiB0aGUgcmVjaXBpZW50 LiAgSWYgc3RyZWFtaW5nIGlzIHJlbW92ZWQgZnJvbSB0aGUgZXF1YXRpb24gdGhlbiB0aGVyZSBp cyBubyBiZW5lZml0IG5vdCB0byB1c2UgUHVyZSBFZERTQS4gICBUaGlzIG1lYW5zIHRoYXQgb25l cyBpZGVhIG9mIGxhcmdlIGlzIGdvaW5nIHRvIGJlIHZlcnkgZGV2aWNlIHNwZWNpZmljLiAgSSB3 aWxsIG5vdCBiZSBzdXJwcmlzZWQgaWYgc29tZSBmaXJtd2FyZSBwYWNrYWdlcyBkbyBpbmRpcmVj dCBzaWduaW5nLCBidXQgdGhlIG1hbmlmZXN0IGRlc2NyaXB0aW9uIGlzIHN0aWxsIGdvaW5nIHRv IG5lZWQgdG8gZml0IGluIG1lbW9yeS4NCltOQ1ddIDJLYnl0ZXMgY2FuIHNlZW0gdmVyeSBsYXJn ZSB0byBzb21lIElvVCBkZXZpY2VzIF9fLiAgQnV0IHlvdXIgcG9pbnQgaXMgd2VsbCB0YWtlbi4u LnNvcnJ5IGlmIEkgd2FzIHRvbyBuaXQtcGlja3kuLi4uYXMgZm9yIGd1aWRhbmNlIEkgcGVyc29u YWxseSBwcmVmZXIgdG8gaGF2ZSBxdWFudGlmaWNhdGlvbiAocmFuZ2VzKS4NCiAgICANCiAgICBT ZWN0aW9uIDQuMS4xOg0KICAgIC0gR0NNJ3MgbGltaXRhdGlvbiBmb3Igb25lIGVuY3J5cHRpb24g c3RyaW5nIGlzIDJeMzktMjU2IGUuZy4gbm90ICJhIHNpbmdsZSBrZXkiLi4uLnNvIHN1ZmZpY2ll bnRseSBsYXJnZSBmb3IgQ09TRSEgIEhvd2V2ZXIsIGl0IGRvZXMgbWVhbiB0aGF0IHRoZSBub25j ZSBNVVNUIGJlIHVuaXF1ZSBmb3IgZXZlcnkgZW5jcnlwdGVkIG1lc3NhZ2UgKGUuZy4gdGhlIGJ1 bGxldCBiZWZvcmUgdGhpcyBvbmUgaXMgY29ycmVjdCkuICBJIHRoaW5rIHRoZSBsaW1pdCBmb3Ig b25lIGtleSB1c2luZyBHQ00gaXMgYmFzZWQgb24gdGhlIHNpemUgb2YgdGhlIG5vbmNlIGFzIGl0 IG11c3QgYmUgdW5pcXVlLg0KICAgIFtKTFNdIFlvdSBhcmUgZ29pbmcgdG8gbWFrZSBtZSBsb29r IHRoaXMgdXAgYWdhaW4uICBIb3dldmVyIEkgdGhpbmsgdGhhdCB0aGlzIGxpbWl0IG1heSBlbmQg dXAgYmVpbmcgc21hbGxlciB3aXRoIG1vcmUgbW9kZXJuIGFuYWx5c2lzIHNvIGdvaW5nIGJhY2sg YW5kIHJlLS1jaGVja2luZyB0aGlzIGlzIGdvaW5nIHRvIGJlIHdvcnRod2hpbGUuICBJdCBqdXN0 IHdpbGwgdGFrZSBhIGZldyBkYXlzLg0KW05DV10gTm8gd29ycmllcywgYXMgYW4gZWFybHkgYWRv cHRlciBvZiBHQ00sIEkgZG8gcmVjYWxsIHRoYXQgbnVtYmVyIGJlaW5nIGZvciBhIHBhY2tldC4u Li4NCiAgICANCiAgICBTZWN0aW9uIDQuMjoNCiAgICAtICdrJyBpcyB0aGUga2V5IHNpemUgaW4g Yml0cyAoSSBwcmVzdW1lKSwgd291bGQgYmUgZ29vZCB0byBkZXNjcmliZSB0aGF0IGJlZm9yZSB0 aGUgdGFibGUuDQogICAgW0pMU10gSSBjaGFuZ2VkIHRoZSB0aXRsZSBvZiB0aGUgY29sdW1uIHRv ICdLZXkgTGVuZ3RoJw0KW05DV10gVGhhbmtzLg0KICAgIA0KICAgIEVkaXRvcmlhbCBuaXRzOg0K ICAgIFNlY3Rpb24gMS41DQogICAgLSBUaGUgc2Vjb25kIHNlbnRlbmNlIGlzIGhhcmQgdG8gcGFy c2UuICBJcyBpdCB0aGF0IHRoZSBpbnRlcm1lZGlhdGUgdmFsdWVzIHVzZWQgZm9yIGRlYnVnZ2lu ZyBhcmUgcmVwcmVzZW50ZWQgaW4gYm90aCBhIGhleCBhcyB3ZWxsIGFzIGEgQ0JPUiBkaWFnbm9z dGljIG5vdGF0aW9uIGZvcm1hdCI/IC0gVGhpcmQgc2VudGVuY2UsIGlzIGl0IHRoYXQgc29tZSBl eGFtcGxlcyB3ZXJlIGRlc2lnbmVkIHRvIGZhaWwgKGUuZy4gdGhleSBhcmUgImZhaWx1cmUgdGVz dCBiYXNlcyIpPw0KICAgIFtKTFNdICBJIGhhdmUgdXBkYXRlZCB0aGlzIHNlY3Rpb24uICBJIHRo aW5rIHRoYXQgdGhpcyBzaG91bGQgc29sdmUgeW91ciBpc3N1ZXMuDQogICAgICAgICAgICA8dD4N CiAgICAgICAgICAgICAgQSBHaXRIdWIgcHJvamVjdCBoYXMgYmVlbiBjcmVhdGVkIGF0ICZsdDto dHRwczovL2dpdGh1Yi5jb20vY29zZS13Zy9FeGFtcGxlcyZndDsgdGhhdCBjb250YWlucyBhIHNl dCBvZiB0ZXN0aW5nIGV4YW1wbGVzIGFzIHdlbGwuIA0KICAgICAgICAgICAgICBFYWNoIGV4YW1w bGUgaXMgZm91bmQgaW4gYSBKU09OIGZpbGUgdGhhdCBjb250YWlucyB0aGUgaW5wdXRzIHVzZWQg dG8gY3JlYXRlIHRoZSBleGFtcGxlLCBzb21lIG9mIHRoZSBpbnRlcm1lZGlhdGUgdmFsdWVzIHRo YXQgY2FuIGJlIHVzZWQgZm9yIGRlYnVnZ2luZywgYW5kIHRoZSBvdXRwdXQgb2YgdGhlIGV4YW1w bGUuDQogICAgICAgICAgICAgIFRoZSByZXN1bHRzIGFyZSBlbmNvZGVkIHVzaW5nIGJvdGggaGV4 YWRlY2ltYWwgYW5kIENCT1IgZGlhZ25vc3RpYyBub3RhdGlvbiBmb3JtYXQuDQogICAgICAgICAg ICA8L3Q+DQogICAgICAgICAgICA8dD4NCiAgICAgICAgICAgICAgU29tZSBvZiB0aGUgZXhhbXBs ZXMgYXJlIGRlc2lnbmVkIHRvIHRlc3QgZmFpbHVyZSBjYXNlOyB0aGVzZSBhcmUgY2xlYXJseSBt YXJrZWQgYXMgc3VjaCBpbiB0aGUgSlNPTiBmaWxlLiANCiAgICAgICAgICAgICAgSWYgZXJyb3Jz IGluIHRoZSBleGFtcGxlcyBpbiB0aGlzIGRvY3VtZW50IGFyZSBmb3VuZCwgdGhlIGV4YW1wbGVz IG9uIEdpdEh1YiB3aWxsIGJlIHVwZGF0ZWQsIGFuZCBhIG5vdGUgdG8gdGhhdCBlZmZlY3Qgd2ls bCBiZSBwbGFjZWQgaW4gdGhlIEpTT04gZmlsZS4gDQogICAgICAgICAgICA8L3Q+DQogICAgW05D V10gVGhhbmsgeW91LCBJIGNhbiBwYXJzZSB0aGlzIGJldHRlci4NCg0KICAgIFNlY3Rpb24gMi4y Og0KICAgIC0gVGhlIHJhdGlvbmFsZSBmb3Igd2h5IFB1cmUgRWREU0EgaXMgdXNlZCBvbmx5ICh2 cy4gSGFzaEVkRFNBKSBtYXkgbGVhdmUgbW9yZSByb29tIGZvciBxdWVzdGlvbnM7IGFzIHRoZXJl IG1heSBiZSBzb21lIGNvcm5lciBjYXNlIGluIHdoaWNoIHRoZXJlIG1heSBiZSBhIHZlcnkgbGFy Z2UgKDJLPykgc3RydWN0dXJlIHRvIGJlIHByb3RlY3RlZC4gIEZvciB0aG9zZSB0aGF0IGFyZSBp biB0aGUgaGVhbHRoY2FyZSBzZWN0b3IgKG9mIElvVCksIEkgY291bGQgc2VlIHBvdGVudGlhbCBm b3IgbGFyZ2UgYmxvY2tzIGFuZCBtYXkgd29uZGVyIHdoYXQgcXVhbGlmaWVzIGFzICJleHRyZW1l bHkgbGFyZ2UiLiAgUkZDIDgwMzIgc3BlYWtzIHRvIEhhc2hFZERTQSBhcyBwcm92aWRpbmcgYmV0 dGVyIGNvbGxpc2lvbiByZXNpbGllbmNlLi4uc28gYW0gaW5jbGluZWQgdG8gc3VnZ2VzdCB0byBl aXRoZXIgcmVtb3ZlIHRoaXMgcmF0aW9uYWxlIG9yIGJlIG1vcmUgY29tcGxldGUgaW4ganVzdGlm aWNhdGlvbi4NCiAgICBbSkxTXSBTZWUgYWJvdmUuDQpbTkNXXSBPSw0KICAgIA0KICAgIFNlY3Rp b24gMy4xDQogICAgLSAzcmQgcGFyYWdyYXBoOiAiU29tZSByZWNpcGllbnQgYWxnb3JpdGhtcyBj YXJyeSB0aGUga2V5IHdoaWxlIG90aGVycyBkZXJpdmUgYSBrZXkgZnJvbSBzZWNyZXQgZGF0YSIu Li4uSSB0aGluayB5b3UgbWVhbiAiU29tZSBhbGdvcml0aG1zIGFyZSB1c2VkIHRvIHRyYW5zbWl0 IGEga2V5LCBlLmcuIGtleSB3cmFwcGluZy4iICAiQ2FycnkgdGhlIGtleSIsIGluIHRoaXMgc2Vu dGVuY2UgbGVhZHMgbWUgdG8gaW1wbHkgaXQncyB0aGUgc2FtZSBrZXkgYmVpbmcgdXNlZCBpbiB0 aGUgSE1BQy4NCiAgICBbSkxTXSAgVGhpcyBpcyB0aGUgc2FtZSBrZXkgdGhhdCBpcyBiZWluZyB1 c2VkIGluIHRoZSBITUFDIGFsZ29yaXRobS4gIEkgaGF2ZSBjaGFuZ2VkICJjYXJyeSIgdG8gInRy YW5zcG9ydCIgYmVjYXVzZSBJIHRoaW5rIHRoYXQgaXMgZ29pbmcgdG8gYmUgY2xlYXJlci4NCltO Q1ddIFllcywgaW5kZWVkLCB0aGF0IG1ha2VzIGl0IGJldHRlci4NCiAgICANCiAgICANCiAgICAN CiAgICANCg0K From nobody Sat May 30 23:07:24 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEC173A1262; Sat, 30 May 2020 23:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S88E2PbEsuzU; Sat, 30 May 2020 23:07:17 -0700 (PDT) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 350503A125F; Sat, 30 May 2020 23:07:17 -0700 (PDT) Received: by mail-ot1-x329.google.com with SMTP id h7so5392198otr.3; Sat, 30 May 2020 23:07:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VBAWVSGSvV+d96OvlnCx/6y0MFAKzcN9bR0fVDs1iMM=; b=Vu2yBE6ubZswJVxHIgwJT5rbVJhClrv2yosiK6yJdjZOgufFSOY63E4Y9yC7hgHcTu 7V2LAunpM/Y1iey1fQXbXbyQ5aky+EMRQlwnYOkmkO1zhUD7yq2V8dCKXA5LqIF8ht4m AsrzVIcDm7QYN5AOC2+CUjtBvghOJJEu/iVM2qpTknr803u6IENSFj8kgUw9ps2OuT56 GbefVM0xXi2SiemHN/xzBjAny31WWHc4pCTS1FARu4MEN0C1HtRNrKklpl+KzqHXcfoq xKYJudhuDTg7hifDyAm/Jk0AJQvfAbdr7fLK4hKaE41BPfIXYuVPpjvNC6At0xvt9BzV j+mQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VBAWVSGSvV+d96OvlnCx/6y0MFAKzcN9bR0fVDs1iMM=; b=hohztl/GPGRg/nNj6xoKI9IZdE6VgRQ9tpoMGmMzWJgHtAzXgGkmVbbkBKiVA8ed0C h5DtWw9HeBy+axOgHLPmBLXuLzUOizViwUQ7Yrsbce372hz43zaRAXErffbXEBhf1msZ KyjSVRF8jsBtpQYDiLRF290jFZuggjN/Af18J9y6tzu0UC4saxupTJOmYmEbPOdiGXWN 4wfR9ebfqAgnuc2o8UXAPi9Lp2jnTL4v+ix8RBCf97MhTv7NWaeViRi5PMMsixYO7xKu x+rb7INyWiXg/G/zWX7slPlw42tT/rp8fqdXfaEBe9+HaMlEj4y8U92xjhe+BIebFbaD JCEA== X-Gm-Message-State: AOAM532jwvOfyUZ5P/7m0gTC2lSvrnNK1T8Oj02eGl8AP0Y4rWpMGxey msRr62CnbENYlZNmuuxb/ARTAVRGXkLNG61SJk8= X-Google-Smtp-Source: ABdhPJyzSVurICrus49JgIMZ+NlkltoxhIiAucbN4+u9bH3Ze7ViWDVi/W12maGrHGxl5Ubp3VlcTzkonCfUyZf6WvQ= X-Received: by 2002:a05:6830:1af4:: with SMTP id c20mr5651003otd.191.1590905236505; Sat, 30 May 2020 23:07:16 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Erik Kline Date: Sat, 30 May 2020 23:07:05 -0700 Message-ID: To: Rifaat Shekh-Yusef Cc: Martin Thomson , Benjamin Kaduk , Barry Leiba , captive-portals , IETF SecDir , Tommy Pauly , d.thakore@cablelabs.com Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [secdir] [Captive-portals] Secdir last call review of draft-ietf-capport-rfc7710bis-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2020 06:07:19 -0000 On Wed, May 20, 2020 at 4:37 AM Rifaat Shekh-Yusef wrote: > > Adding SecDir back to this thread. > > > >Martin Thomson Tue, 19 May 2020 01:02 UTCShow header > > > >On Tue, May 19, 2020, at 07:08, Rifaat Shekh-Yusef wrote: > >> it provides the client of the API > >> an opportunity to authenticate the server that is hosting the API. > >> This authentication is aimed at *allowing a user to be reasonably > >> confident that the entity providing the Captive Portal API has a > >> valid certificate for the hostname in the URI* > >[...] > >> An end user should be able to validate that the name is example.com and > >> not any other form of the URI. > >> It would be much more difficult for the end user to make sense and > >> validate an IP address. > > > >I think that you missed the point of my comments. This validation, performed by > >a user, has no meaningful security value. The text you cite says that the server > >has a certificate for the name it chooses, which is not the same as "has a certificate > >for a name the client expects". The difference is important. > > > > This is not the way I read these statements from section 4.1 titled Server Authentication. > > Here is the use case I have in mind when I read this section: > If I walk into an airport and I see an ad for a paid Internet service from example.com, then as an > end user it is reasonable to expect that I would have some ability to make sense of the name > presented to me and make sure it is from example.com if I choose to get such a service. > > If this is not the case, then yo might want to make it clear that this is not about Server Authentication > as the title of the section and the text inside that section is suggesting. If we changed the API document's section 4.1 title from "Server Authentication" to "API Server Authentication", would that be more clear? I reality, users should never see the API URL. They'll just be connecting to "Cool Cafe" or "Awesome Bookshop" ESSIDs. If anything will only be one or both of the "user-portal-url" or "venue-info-url" URLs that might be visible in the browser that's opened for the user's interaction. -ek > Regards, > Rifaat > > > > >In a typical web scenario, a person types a string in and (ignore the case where there > >is an extra hop via a search engine) that string determines what is acceptable as a > >server identity. The exposure to confusables is limited (under a set of other assumptions, > >HSTS, etc...). Here, the network has free reign to do as they choose with homoglyphs and > >other such nonsense. Any expectation you might have about this really being a trustworthy > >entity is meaningless in this context. > > > >There are protections against this, but they all lie firmly in the anti-phishing domain. > >Most of those rely on having a certificate though, so the requirement for HTTPS is in > >service of that, not in terms of ensuring that an untrained human can make a security > >critical decision based on poisoned information. > > On Mon, May 18, 2020 at 5:08 PM Rifaat Shekh-Yusef wrote: >> >> Adding Ben. >> >> >> On Sun, May 17, 2020 at 9:26 PM Martin Thomson wrote: >>> >>> Adding more lists.. >>> >>> On Sun, May 17, 2020, at 02:50, Rifaat Shekh-Yusef wrote: >>> > > Here is a quote form the API document: >>> > > "The hostname of the API SHOULD be displayed to the user in order to indicate the entity which is providing the API service." >>> > > >>> > > This seems to suggest that the user is expected to inspect the displayed name and make sure it is make sense in the context of whoever is providing that service. >>> >>> I don't think that is the case. If this were a security mechanism, then it would use "MUST". This is likely for the purpose of enabling some sort of accountability. In other words, this is to offer maximal information about what is going on. >>> >> Here is the sentence just before the above quote from the API document: >> >> it provides the client of the API >> an opportunity to authenticate the server that is hosting the API. >> This authentication is aimed at allowing a user to be reasonably >> confident that the entity providing the Captive Portal API has a >> valid certificate for the hostname in the URI >> >> >> >> >>> >>> > > Since this would be an easier attack compared to the interception attack, and IP address is still permitted, then an attacker might force the use of IP address to make it harder for the user to make sense of the displayed name. >>> >>> I don't think that is materially different than getting a name with confusable characters (or using the prefix hack, example.com..example, in an attempt to confuse). >> >> >> An end user should be able to validate that the name is example.com and not any other form of the URI. >> It would be much more difficult for the end user to make sense and validate an IP address. >> >> Regards, >> Rifaat >> > _______________________________________________ > Captive-portals mailing list > Captive-portals@ietf.org > https://www.ietf.org/mailman/listinfo/captive-portals