Re: [Rum] Roman Danyliw's Discuss on draft-ietf-rum-rue-09: (with DISCUSS and COMMENT)
Roman Danyliw <rdd@cert.org> Mon, 07 February 2022 21:13 UTC
Return-Path: <rdd@cert.org>
X-Original-To: rum@ietfa.amsl.com
Delivered-To: rum@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A62F3A0B08; Mon, 7 Feb 2022 13:13:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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=seicmu.onmicrosoft.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 ugWaeEv9-drF; Mon, 7 Feb 2022 13:12:57 -0800 (PST)
Received: from USG02-CY1-obe.outbound.protection.office365.us (mail-cy1usg02on0107.outbound.protection.office365.us [23.103.209.107]) (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 8A05A3A0AA2; Mon, 7 Feb 2022 13:12:47 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector5401; d=microsoft.com; cv=none; b=rG9lSdCp9skY3PJjizD8MKBJLd7IvhyHbgit6/wg7L83FRQkH9Zq6esRtqWxzqILBwQV7EIvRyOtIRsc2RSSUBJ1eaE5aotgkshBAOlddky+p5+9o9QGZsyxRHuoVZzDkWe2V1kn5mHIhBCdV+QFq3O2+LhQnG4C9UGLNP7KqXCLDvKrpXdW1fuG/XTP+0piIX7Kp6bxP9Rr9KChuuIXEz7rCZ1L+O7SOlTjSaQwppXI3d+RXr5MF1/3c4ckz0hJUgE9fqcyHLaBorumLdRfBXg0B8JH8CKONXBsPoEh9JEAFZ/6DalIhNTgf7PJvsP1zhHJ0j3Si7DKYbI5fAGv7w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector5401; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=+k7bt5sNQahlR6662cv3Xh/PIayAHVa6u2g+5n5A3c4=; b=b9E8o9/cfv9Peiz8vCNwmJUUB5Q6ObqbUI+6fm0oZBZZXxDAi91mYNsQuGIfQp5XnCAQKE1YUwYsxXzw6waVTbbALnqaltmnGwLFXQQZyh/GPtd4JPFQ/lFx8cd2l+Npdi0WiD35SR0eZkK+ydqtpdIX+uXedt0PnDAurDAeuZTWesUCXanvVLgntAPCZk5m5AFUKJK/CnhLOEbMQxHRd47ZXJdmv57h5/Q8ST2ab3dY7eAXOWIhzXay6huaw7SuzBqTVYbpFYCDPBPvVmUrdY3ceBGPT0y/OHnjE8AzDbAL2LiuOxAq1icD0tWaN7NjJ73KW2b4XUDm+zmiCjWlrA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cert.org; dmarc=pass action=none header.from=cert.org; dkim=pass header.d=cert.org; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=seicmu.onmicrosoft.com; s=selector1-seicmu-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+k7bt5sNQahlR6662cv3Xh/PIayAHVa6u2g+5n5A3c4=; b=JK5A1ygPuyLWi3+AYwV9OW3r7Fq73ZKgYZ84wGePzK4FaWF4X1sBtOhVjLPSuouYLHrge1AekiQ2BczE554CAgwtEX0A2Mrv4LtQKzF4kydZUp8FM6yadXCxmxhAujXSXXsUlkfznVl19csf6C8pO3pEXXi0VQhKU64henR3g+A=
Received: from BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM (2001:489a:200:168::11) by BN2P110MB1012.NAMP110.PROD.OUTLOOK.COM (2001:489a:200:169::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4951.14; Mon, 7 Feb 2022 21:12:42 +0000
Received: from BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM ([fe80::45f0:b470:9c74:ef6e]) by BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM ([fe80::45f0:b470:9c74:ef6e%3]) with mapi id 15.20.4951.018; Mon, 7 Feb 2022 21:12:42 +0000
From: Roman Danyliw <rdd@cert.org>
To: Brian Rosen <br@brianrosen.net>
CC: The IESG <iesg@ietf.org>, "draft-ietf-rum-rue@ietf.org" <draft-ietf-rum-rue@ietf.org>, "rum-chairs@ietf.org" <rum-chairs@ietf.org>, "rum@ietf.org" <rum@ietf.org>, Paul Kyzivat <pkyzivat@alum.mit.edu>
Thread-Topic: Roman Danyliw's Discuss on draft-ietf-rum-rue-09: (with DISCUSS and COMMENT)
Thread-Index: AQHX8gAyUNHxI5VCxUKb021sqRYDNaxAq70AgCuLUQCAHLL34A==
Date: Mon, 07 Feb 2022 21:12:42 +0000
Message-ID: <BN2P110MB1107825D772061A4AD883E8DDC2C9@BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM>
References: <163960605716.22037.6925953082119136922@ietfa.amsl.com> <64AD6B8B-9D35-4269-AD74-FD8755F21F2D@brianrosen.net> <ECF95B5B-AF48-4C9F-A0E9-F52D602BE604@brianrosen.net>
In-Reply-To: <ECF95B5B-AF48-4C9F-A0E9-F52D602BE604@brianrosen.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cert.org;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d25b9ad5-2e6b-469f-7e28-08d9ea7e948e
x-ms-traffictypediagnostic: BN2P110MB1012:EE_
x-microsoft-antispam-prvs: <BN2P110MB10126C39D96D65AD39950F9DDC2C9@BN2P110MB1012.NAMP110.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 7fcG9EoU4ETPx+AKoriF29G/bmGDR/6GztyIMtmKTQZAuYt5T25g6bfgj2hnSdQlTJfsJun9NfvEQphTle1c1UZsR0giEund0/brwxtdErDsusRckoq5s4PINbHECz8QsAVX3NM3FON4AKe/A6mV85HZKpf4WS7weM6/5bhxyDYc86sqdkuEwXChxnhPOJHjI82Hmzo9XM2t+Lr8CqYdGGMmkfR4LGaQy7dvo7Yv+TpMDft1G+uTzYR+MjP8nkgipRRvLCxwyve3eSN1QM4H265bZHdMXl/CpdLmwTatsygvM2EFinE+lYXBsBLceDAWY+NO3wcwT7tbWkvjf40Kzak9tZfsqY7Ye09zHjndjrgHYT8Z/T8EcFwrDpSEuZ9CG/r84Fodp9A+PowdXrewADdqKjk4hlReNrPgx4PszCQ8YG826DG8sBE656eP2lRS4yHzTYk0DwZPlJFDf034KnRCBu5kcfnUfoKpNOiSB6a30Tv7BtQPlF3RfGzk2CcBgngrILewWibecce+JG1vWZeVwl7/oVICMeHBxD3UtM+udkbEn3juu9b4ekiVi+ZSLfCS1O1MxuS9owddUTOXCtB20oOI5rRq/c+bP39JSxGbESEzHx0JcAZ2n1kTviCQNOAcq1ROsK7Lklpjq0dzZJnvRjpJLzE5RM9+0JpzIzZ+Yold//dlUo27ISzy+Aq5OjGxF9WJdLWupKZPKff4EQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230001)(366004)(55016003)(6916009)(38070700005)(5660300002)(54906003)(52536014)(9686003)(186003)(26005)(83380400001)(966005)(76116006)(64756008)(8676002)(66556008)(66946007)(8936002)(66446008)(66476007)(6506007)(53546011)(7696005)(122000001)(498600001)(166002)(86362001)(82960400001)(33656002)(4326008)(2906002)(38100700002)(71200400001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: XtLMHqAWXHvdl7lH7coJjjysXR7SJln4tb01qnstxarUIyxxqTqA6zd2Sd5AEezvV5maazcwPT8yOBnhManMIxAU7tMjiGJNy9GKnixaQUMBxPLZGuIA4zH3aGjbD6Pb3LQbD6uqLzNUGUi0cPxJ7Q==
Content-Type: multipart/alternative; boundary="_000_BN2P110MB1107825D772061A4AD883E8DDC2C9BN2P110MB1107NAMP_"
MIME-Version: 1.0
X-OriginatorOrg: cert.org
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: d25b9ad5-2e6b-469f-7e28-08d9ea7e948e
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Feb 2022 21:12:42.8468 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 95a9dce2-04f2-4043-995d-1ec3861911c6
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN2P110MB1012
Archived-At: <https://mailarchive.ietf.org/arch/msg/rum/V4xFO5tQxtTs2x8C9UulIvXyNIU>
Subject: Re: [Rum] Roman Danyliw's Discuss on draft-ietf-rum-rue-09: (with DISCUSS and COMMENT)
X-BeenThere: rum@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Relay User Machine <rum.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rum>, <mailto:rum-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rum/>
List-Post: <mailto:rum@ietf.org>
List-Help: <mailto:rum-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rum>, <mailto:rum-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Feb 2022 21:13:04 -0000
Hi Brian! Apologies for the delay. Thank you for the edits in -10. They address my feedback. I’ve cleared my ballot. I missed the very clear text that was already at the start of Section 4 (in -09) which answered my second DISCUSS point about TLS. Roman From: Brian Rosen <br@brianrosen.net> Sent: Thursday, January 20, 2022 9:54 AM To: Roman Danyliw <rdd@cert.org> Cc: The IESG <iesg@ietf.org>; draft-ietf-rum-rue@ietf.org; rum-chairs@ietf.org; rum@ietf.org; Paul Kyzivat <pkyzivat@alum.mit.edu> Subject: Re: Roman Danyliw's Discuss on draft-ietf-rum-rue-09: (with DISCUSS and COMMENT) Roman Does the -10 version I submitted address your issues? Brian On Dec 23, 2021, at 4:56 PM, Brian Rosen <br@brianrosen.net<mailto:br@brianrosen.net>> wrote: Thank you for your comments. Responses inline On Dec 15, 2021, at 5:07 PM, Roman Danyliw via Datatracker <noreply@ietf.org<mailto:noreply@ietf.org>> wrote: Roman Danyliw has entered the following ballot position for draft-ietf-rum-rue-09: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-rum-rue/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- ** Is there a reason that credential re-use is being suggested as a fall back. It seems risky to reuse the credentials across services. This is really how sip services commonly work and I’m reluctant to disallow what is widely implemented This fall-back also appears to contradict the guidance in Section 5.1. which says “This username/password combination SHOULD NOT be the same as that used for other purposes, such as retrieving the RUE configuration”. I will change this to add "except as expressly described below” The configuration service is new, and thus we can say don’t reuse credentials for that. See: -- Section 7.1. Per access to the CardDAV server, “[i]f no matching credentials are configured, the RUE MUST use the SIP credentials from the configuration.” -- Section 9.2.2. sip-password says “If it was never supplied, the password used to authenticate to the configuration service is used for SIP, STUN and TURN.” -- Section 9.2.2. carddav field says that “If username or password are not supplied, the main account credentials are used. “ ** Is there a reason that a minimum transport requirements of using HTTPS is not defined for accessing the SIP-supporting elements of this architecture. I’m confused by this. HTTPS and SIP are mutually exclusive. Did you mean TLS instead of HTTPS? But you said “minimum transport” and not “security” so I’m even more confused. Sorry. We specify RFC7525 and 8446 in General Requirements for TLS. -- Section 7.1. Access to the CardDAV service? Does the guidance in Section 7.2 (The RUE stores/retrieves the contact list (address book) by issuing an HTTPS POST or GET request.) imply that? There are two services: a contact list import and a CardDAV service, which is a contact sync. Both are subject to the TLS requirements -- Section 9. Using the overall API? Does the guidance in Section 9.2 (A RUE device may retrieve a provider configuration the using a simple HTTPs web service) imply that? Again it’s an HTTPS service, so subject to the General Requirements TLS specs -- Section 9.2.1. For the URI configuration options noted in this section (e.g., the uri in signup)? Same ** Section 11. There are more than 10 20 normative SIP protocol references in this document. Which of their security considerations apply? All of them. That’s pretty normal sip stuff. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you to Russ Mundy for the SECDIR review. ** Section 2. Thanks for defining all of this terminology up front. As many of these are components in the architecture, I would have benefit from a diagram early in the document showing how these components integrate. ** I am diagram challenged, but I will see what I can do. Section 5.1. The paragraph starting with “The registrar MAY authenticate using SIP digest authentication …”, should likely say that the technique for provisioning the credentials is out of scope for this profile. Actually, they come in the configuration service. ** Section 8. Typo. s/mechansism/mechanism/ Fixed ** Section 9.1 IANA has established a registry that contains a two letter country code and an entry point string. Recommend adding a forward reference to Section 10.1. Added ** Section 9.1. For example, if the entryPoint is "example.com<http://example.com/>", the provider list would be obtained from https://example.com/rum/V1/Providers. This example doesn’t match the syntax of Section 9.3. “V1” here and “v1” in Section 9.3. Fixed ** Section 9.2. It would be helpful in this narrative text for the input values names to match the actual field names used in the API in Section 9.3. Specifically, “API Key” is “apiKey”, and “instance identifier” is “instanceId” Fixed. ** Section 9.2.1. Per the language value in the signup configuration option, please provide a reference to the IAN language subtag registry (https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry). I put it inline as a link. Should it be an actual reference? ** Section 9.2.2. sendLocationWithRegistation is listed as a stand-alone field here, but in Section 9.3, it is shown to be part of the carddav object. Which is correct? Ho, that’s an actual error. It should be a separate field. Fixed ** Section 9.2.3. Figure 4. This example is not conformance to the previously described syntax. All of the values of the “uri” fields should be a URI, but all of them are missing a scheme. Fixed ** Section 9.3. [OpenAPI] needs to be a normative reference as its syntax is needed to understand this section. Reluctantly fixed. We have too many normative references :)
- [Rum] Roman Danyliw's Discuss on draft-ietf-rum-r… Roman Danyliw via Datatracker
- Re: [Rum] Roman Danyliw's Discuss on draft-ietf-r… Brian Rosen
- Re: [Rum] Roman Danyliw's Discuss on draft-ietf-r… Brian Rosen
- Re: [Rum] Roman Danyliw's Discuss on draft-ietf-r… Roman Danyliw