Re: [Uta] WGLC for draft-ietf-uta-rfc6125bis-06

Peter Saint-Andre <stpeter@stpeter.im> Thu, 07 July 2022 19:54 UTC

Return-Path: <stpeter@stpeter.im>
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3B8AC13CF99; Thu, 7 Jul 2022 12:54:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.983
X-Spam-Level:
X-Spam-Status: No, score=-8.983 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, NICE_REPLY_A=-1.876, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=LavoCS/R; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=jKZ3Ghey
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XsF2TjeQlgKD; Thu, 7 Jul 2022 12:53:58 -0700 (PDT)
Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BBCEC13CF78; Thu, 7 Jul 2022 12:53:10 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 0D62E320095B; Thu, 7 Jul 2022 15:53:07 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Thu, 07 Jul 2022 15:53:08 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm1; t=1657223587; x= 1657309987; bh=nhb72Kqzqm7ADpLzdAu468LrVkV/fYJ7IpjY4jFbx9c=; b=L avoCS/R0DjTELJwvFjAuufaLRRmnvONr1K0C2U4Ja/t6nTd/W53oXmRqHSfRgw8A V/vYjiRVCHmENO3C66q7F6Wm6ZyXb0HcUXoYFBFPs7/YNwcmjCbbMNkXYjms8n4U rXPx7LSF2UW7YBs9kClcYPjcXbvO6Rp/7A6iKLZeoHwEj0Kmw01AFhQXO7LU3AW3 1+gMybik4+u9ByBzJS86dI6iA7nFGB1RKCysutJkzx0Cwccogupqhw9Oq1x/ayw6 qZf6z29SVEDTG3rrEhD2oPLPXCOPw+0W1jH/fy6KaSrcPs9maQRZXD5onMFtcbSR 4a/U5CFv7LCB2xEy9sTGg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1657223587; x= 1657309987; bh=nhb72Kqzqm7ADpLzdAu468LrVkV/fYJ7IpjY4jFbx9c=; b=j KZ3GheyLzafDWPJMhHXlCS3O/K3ax/geSFQJ3rSlou7Z/teX0dqxaPquXh5BsVTc V8ZKq1XRDPPkVHVwjMdwUgSzAx1r8xbVPKoO1s4lB1Gd35rOtZYQam656/6luIul J0V4v9ZPoGlAwmWfZuFuiexQAVTji7aOixRE44jp18fhLz3o4y/avciLUBr2M7q3 8spZSAs5OS5hgY3uDaJClN4yhBQgUIZ14UYbRO7SiBZ0pFGPYmZ7iKcY4Pk5Al55 3HPl4550xYdZl2Pba53wY3xvswQI0j2Rg3KsIjgX62fSuC95i5Vg9kePKm9Pw0ax siFGD/ny5gzR+qrK3I7Ow==
X-ME-Sender: <xms:oznHYoijMCVPdJyXy6MDn6DOoKLgJwFBPNuvAcJ0j41pbPAW9DkQ2g> <xme:oznHYhDt94HE_A4HRrc59Jv8ykzIGYO1lNuGTHFXgVXrcmrbu3Sx9Qiw4_85hpUvk l7X0CxnQZpaOud_wQ>
X-ME-Received: <xmr:oznHYgGorHev36RzGOOp8uCHeP2Kk8apebGGd8ViYFehFZW55tMaOHUzgSyB>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrudeihedgudegfecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthekredttdefjeenucfhrhhomheprfgv thgvrhcuufgrihhnthdqtehnughrvgcuoehsthhpvghtvghrsehsthhpvghtvghrrdhimh eqnecuggftrfgrthhtvghrnheptefhtdelkeefhefhveeufeetuddvheekuefghffhfefh udeggeelhffgieejveetnecuffhomhgrihhnpehhthhtphhrfhgtrghsrgguvhhishgvfh horhhprhhothhotgholhhsthhhrghtshhuphhpohhrthhiphgruggurhgvshhsvghsrdhi shdpghhithhhuhgsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomhepshhtphgvthgvrhesshhtphgvthgvrhdrihhm
X-ME-Proxy: <xmx:oznHYpTaQxeTReZpvbrxqaX_SFYl_pM0eIZyWS7u7oTVU8aXhFGbyQ> <xmx:oznHYlzN-PIliva64H5hawLlctC_LzrwnnoCx1YkUnUBdCh6zU5lCA> <xmx:oznHYn60JpaXRC7JGDrT4D5o2RSlbs6oqDRYWn_g_8oNIrpFlHzAuQ> <xmx:oznHYntnxwDqo08wmeRDy3as78SfRjYdGu8L0R2Rhw2a3v7Dy9lnHQ>
Feedback-ID: i24394279:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 7 Jul 2022 15:53:06 -0400 (EDT)
Message-ID: <0cd6a906-1f49-b08e-1434-eabc32e331f2@stpeter.im>
Date: Thu, 07 Jul 2022 13:53:05 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.11.0
Content-Language: en-US
To: tom petch <daedulus@btconnect.com>, Valery Smyslov <valery@smyslov.net>, 'Martin Thomson' <mt@lowentropy.net>, uta@ietf.org
Cc: uta-chairs@ietf.org
References: <002e01d87e9c$78a002e0$69e008a0$@smyslov.net> <152a5c9d-3142-419e-81dd-aa19bc2c8a02@beta.fastmail.com> <A8121C94-7881-4BA1-8A3D-C70291020FA6@akamai.com> <53fb3bb0-6414-3e1b-5ef5-2204522528f8@stpeter.im> <ED51AE33-23D2-4D40-91CD-155877E0ABAC@akamai.com> <03e601d88d54$65876150$309623f0$@gmail.com> <617eb543-e898-4716-8bda-77000e6d55b7@beta.fastmail.com> <05ce01d89103$6718fd50$354af7f0$@smyslov.net> <6afa428d-271d-43be-3652-9c9729ce110c@stpeter.im> <064701d89142$c0751fc0$415f5f40$@smyslov.net> <62C6A9F5.4030608@btconnect.com>
From: Peter Saint-Andre <stpeter@stpeter.im>
In-Reply-To: <62C6A9F5.4030608@btconnect.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/6oAzp0nNPGgk0qTb4vqjd-szQGQ>
Subject: Re: [Uta] WGLC for draft-ietf-uta-rfc6125bis-06
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: UTA working group mailing list <uta.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uta>, <mailto:uta-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/uta/>
List-Post: <mailto:uta@ietf.org>
List-Help: <mailto:uta-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uta>, <mailto:uta-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Jul 2022 19:54:02 -0000

On 7/7/22 3:40 AM, tom petch wrote:
> On 06/07/2022 15:14, Valery Smyslov wrote:
>> Hi Peter,
>>
>>> On 7/6/22 12:41 AM, Valery Smyslov wrote:
>>>> Hi Martin,
>>>>
>>>>>> The chairs think that the rough consensus is to limit the scope of 
>>>>>> the
>>>>>> draft to domain names
>>>>>> (with the pointer to the HTTP RFC as advise for protocols that 
>>>>>> support
>>>>>> IP addresses).
>>>>>
>>>>> Is this the consensus of the chairs, or was there some discussion 
>>>>> that I missed?
>>>>
>>>> We discussed this with Leif going back to the history of RFC 6125.
>>>> The text explicitly limiting the scope of the document to domain names
>>>> first appeared in draft-saintandre-tls-server-id-check-05 back in 2010
>>>> and was kept in RFC 6125. At the time the 6125bis draft was adopted
>>>> there was no intention to widen the scope of RFC 6125.
>>>>
>>>>> I agree that there is no consensus to include changes, but I don't 
>>>>> see any input other than from Rich
>>> (and
>>>>> I guess now yourself).
>>>>
>>>> Peter also participated in the discussion and from our point of view 
>>>> he supported Rich's position.
>>>> We also waited a bit for others to chime in.
>>>
>>> I'm actually not opposed to adding support for IP addresses - my only
>>> concern was performing major surgery on the document, so I wanted to
>>> think about what changes we would need to make. At the time that Jeff
>>> and I worked on RFC 6125, we were not aware of widespread use of IP
>>> addresses in PKIX certificates. If the deployment situation has changed
>>> (as indicated by RFC 9110), then I am open to adding IP-IDs to 6125bis.
>>
>> OK, sorry for misinterpreting your response.
>>
>>>> Just to reiterate the chairs' position. We think that describing the 
>>>> handling of non-domain based names
>>>> (like IP-ID) is a good idea, but at the same time we think that it 
>>>> would require quite a lot
>>>> of changes to the current document,
>>>
>>> Martin sketched that out here:
>>>
>>> https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/54/files
>>>
>>> I don't think it's *too* bad.
>>>
>>>> that would slow down its progress.
>>>
>>> What's the hurry? It's been 10+ years since we published RFC 6125, I
>>> don't think a few more weeks will make a big difference.
>>
>> Then, we'd like to hear from WG members:
>> whether the scope of rfc6125bis draft should be broaden
>> to include non-domain names, like IP addresses
>> (at the cost of delaying its publication) or this issue
>> should be addressed in a separate document.
> 
> Separate document for IP addresses.  RFC6125 was based on a 
> comprehensive survey of what IETF protocols were doing in this space and 
> I have not seen much change there.  Security moves relentlessly on and 
> so an up-to-date guide is worthwhile.
> 
> IP addresses do get used but probably not on the large Internet web 
> servers, rather in Enterprise.  (I wondered if the Internet of Things 
> will go down that route).
> 
> Whatever, a different use case, a different environment, a different RFC 
> IMHO.

That seems like a valid approach. I'm not wedded to including this 
content in 6125bis, although I'm open to doing so if that's the sense of 
the WG. I'd also be happy to co-author the separate document for IP 
addresses (it should be relatively short), with the understanding that 
perhaps the two documents would be merged whenever the IETF works on 
6125ter.

Peter