Re: [Taps] Lars Eggert's Discuss on draft-ietf-taps-interface-22: (with DISCUSS and COMMENT)

Tommy Pauly <tpauly@apple.com> Thu, 14 December 2023 17:55 UTC

Return-Path: <tpauly@apple.com>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE647C14F5F6 for <taps@ietfa.amsl.com>; Thu, 14 Dec 2023 09:55:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.103
X-Spam-Level:
X-Spam-Status: No, score=-2.103 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, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
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 PMT4MlDMEGH9 for <taps@ietfa.amsl.com>; Thu, 14 Dec 2023 09:55:07 -0800 (PST)
Received: from ma-mailsvcp-mx-lapp02.apple.com (ma-mailsvcp-mx-lapp02.apple.com [17.32.222.23]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 10698C14F60B for <taps@ietf.org>; Thu, 14 Dec 2023 09:55:06 -0800 (PST)
Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by ma-mailsvcp-mx-lapp02.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) with ESMTPS id <0S5O00MQS4FMUA10@ma-mailsvcp-mx-lapp02.apple.com> for taps@ietf.org; Thu, 14 Dec 2023 09:55:00 -0800 (PST)
X-Proofpoint-ORIG-GUID: lFENGpJ5ogq67KOaj8ngNYFX047xg6vo
X-Proofpoint-GUID: lFENGpJ5ogq67KOaj8ngNYFX047xg6vo
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.619, 18.0.997 definitions=2023-12-14_12:2023-12-14, 2023-12-14 signatures=0
X-Proofpoint-Spam-Details: rule=interactive_user_notspam policy=interactive_user score=0 phishscore=0 suspectscore=0 malwarescore=0 mlxlogscore=764 adultscore=0 spamscore=0 mlxscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2311290000 definitions=main-2312140127
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=PnABl30cBOErWXDwgu+V/dBX6hTMvIZE5OhcrpYIFvU=; b=HDSwSSNo/W3RZq9gefvKQZ6xxqHU4wFKmN0XvcOivyRouDbn47bufAU0I981Ps53LDxg CcGFEn8+1e+ZZi7df5DGw7k2yrkWKiIiyrEn4EngoNrnP3KbvrzpYotUjYCOeyq05+qC d58sIfd0Rp5PFXNKg3w53ZkzoXZjaZYhHhhEVZVPjgCMAwKt42fGwl7AfH7Pk9EvXmjG ugJnDfZkqNr9kColvIJqMebjvQF+eLv/Ugc/mwmTxYtiKsJYwKywdF0ptFMQCsMFKwDG K87IgsXM+AtRP0sFidl6RMP+ooYMCUsuqIoIpZS0PYvFBISlflxOD7S4gR/T+GXPpLWx 7w==
Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) with ESMTPS id <0S5O009E24FJHSP0@rn-mailsvcp-mta-lapp01.rno.apple.com>; Thu, 14 Dec 2023 09:54:55 -0800 (PST)
Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) id <0S5O00Z003W53800@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Thu, 14 Dec 2023 09:54:55 -0800 (PST)
X-Va-A:
X-Va-T-CD: e52bc99798a6b8983ba7b5634300aea3
X-Va-E-CD: 131c43a3a6412cc28a5b861b2a311273
X-Va-R-CD: c06fad883c61093726cf88396f321272
X-Va-ID: 6d277670-d5a6-4cc8-8a8c-f2ca271f601a
X-Va-CD: 0
X-V-A:
X-V-T-CD: e52bc99798a6b8983ba7b5634300aea3
X-V-E-CD: 131c43a3a6412cc28a5b861b2a311273
X-V-R-CD: c06fad883c61093726cf88396f321272
X-V-ID: 5abab0fd-4fe3-41d2-b87b-0fb2c6aa0c31
X-V-CD: 0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.619, 18.0.997 definitions=2023-12-14_11:2023-12-14, 2023-12-14 signatures=0
Received: from smtpclient.apple ([17.234.55.157]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) with ESMTPSA id <0S5O011QQ4FI2Q10@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Thu, 14 Dec 2023 09:54:54 -0800 (PST)
From: Tommy Pauly <tpauly@apple.com>
Message-id: <48768A5A-61F9-49E7-9010-6A6C1993AF08@apple.com>
Content-type: multipart/alternative; boundary="Apple-Mail=_B3FC7D90-F327-4FD8-AA7A-085D01D45C9D"
MIME-version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\))
Date: Thu, 14 Dec 2023 09:54:44 -0800
In-reply-to: <BE8110AC-5CBB-4A78-B9BE-93B8313AE126@apple.com>
Cc: Brian Trammell <ietf@trammell.ch>, Michael Welzl <michawe@ifi.uio.no>, The IESG <iesg@ietf.org>, draft-ietf-taps-interface@ietf.org, taps-chairs@ietf.org, taps@ietf.org, Anna Brunström <anna.brunstrom@kau.se>
To: Lars Eggert <lars@eggert.org>
References: <F16F27A0-AC25-498F-AE25-F04B9421712D@eggert.org> <14B9DBDA-6DF6-419F-89C4-72503503A443@apple.com> <C5C89CED-A4A7-4A73-AC04-FBB2423D2909@eggert.org> <BE8110AC-5CBB-4A78-B9BE-93B8313AE126@apple.com>
X-Mailer: Apple Mail (2.3774.300.61.1.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/sQfGGufur7zncZBuka1JXfentUM>
Subject: Re: [Taps] Lars Eggert's Discuss on draft-ietf-taps-interface-22: (with DISCUSS and COMMENT)
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IETF Transport Services \(TAPS\) Working Group" <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Dec 2023 17:55:10 -0000

As a note, we just pushed draft-ietf-taps-interface-24 to address the SHOULD->MUST.

Thanks,
Tommy

> On Dec 14, 2023, at 8:22 AM, Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org> wrote:
> 
> 
> 
> 
>> On Dec 14, 2023, at 6:27 AM, Lars Eggert <lars@eggert.org> wrote:
>> 
>> Hi,
>> 
>> On Dec 14, 2023, at 16:13, Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org> wrote:
>>>>>> 
>>>>>> How would a developer know what the default endpoint was?
>>>>> 
>>>>> The “default” endpoint is the one that the application developer themselves provided that didn’t include a protocol-specific binding. In the example above, that’s the port 443 endpoint, while there’s a protocol-bound endpoint that uses port 8443.
>>>> 
>>>> OK, but where in the example does it set that the default it TCP/TLS? The only thing specified for the "default" is port 443 - is something inferring TCP/TLS based on the port?
>>> 
>>> The default isn’t explicitly set to TCP/TLS there—it’s the endpoint address/host/port details that are set as default. So it’s saying “use this default endpoint for any protocol that’s used, except if quic is chosen because I know it uses a different port”. Theoretically if the stack could choose TLS/TCP, QUIC, and something else like SCTP, that default would apply to everything other than QUIC.
>> 
>> so *any* protocol other than QUIC would be OK on port 443? SCTP, DCCP, TCP with TLS and without?
> 
> Of the protocols that could be automatically selected, yes. However, there would not be a case where you’d be using TCP with and without TLS for one connection — the requirements for a transport security protocol aren’t optional or added or removed like that.
> 
> The most common case here is that there isn’t any protocol override, and you’re accessing the same endpoint that might be over TLS+TCP or QUIC. Note that the stack itself can learn about different ports from SVCB records, etc, as it discovers alternative transports/ALPNs as well. This is exactly what we’ve been doing in our Network.framework and it has not been a problem for developers in practice.
> 
> Thanks,
> Tommy
> 
>> 
>> This exchange - which we don't need to continue, I think we're beyond the point where progress is being made - reinforces my belief that either I don't understand something fundamental about TAPS, or it's simply not really making the developer experience clearer or easier.
>> 
>> Thanks,
>> Lars
>> 
> 
> _______________________________________________
> Taps mailing list
> Taps@ietf.org <mailto:Taps@ietf.org>
> https://www.ietf.org/mailman/listinfo/taps