[Taps] Paul Wouters' Yes on draft-ietf-taps-arch-18: (with COMMENT)

[Paul Wouters via Datatracker <[e-mail]>]

Paul Wouters has entered the following ballot position for
draft-ietf-taps-arch-18: Yes

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/about/groups/iesg/statements/handling-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-taps-arch/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for this document. It seems like a good successor to "named sockets"
which we sadly don't even have for Linux/POSIX :) I look forward to being
able to open a secure connection based on just a DNS name, and letting
the TAPS system figure out wether to use TLS, QUIC, IPsec, DANE, WebPKI, etc.

I support Éric Vyncke's DISCUSS on that this document seems to be rather
Informational than Standards Track. I also agree it is a bit strange to
see normative BCP14 terms.



        Security Parameters are primarily associated with a Preconnection object,

Wouldn't these apply equally to the Listener objects? It is after all what both need
to agree on.


        RFC-EDITOR: Please remove this section before publication.

I would leave in the empty IANA Section - it is preferred over omitting it.


        As described above in Section 3.3, if a Transport Services
        implementation races between two different Protocol Stacks, both
        need to use the same security protocols and options. However,
        a Transport Services implementation can race different security
        protocols, e.g., if the application explicitly specifies that
        it considers them equivalent.

I am not sure this is a very clear distinction. Is IPsec with PolyChacha
different from WireGuard with PolyChacha? How about TLS 1.2 with AES-GCM
and TLS 1.3 with PolyChacha?  How about TLS 1.2 with AES-CBC and TLS
1.2 with AES-GCM ? Or TLS 1.3 vs QUIC? And TLS 1.2 vs
QUIC? Or TLS vs DTLS?

Some of these might not have fully known properties beforehand? Eg
what about TLS 1.2 where the server insists on PSK and rejects PFS?
Or IKEv2/IPsec with ECDSA versus IKEv2/IPsec with RSA?

It's a very gradient flow between Protocol Stacks. I am not sure the
defined distinction between Transport Services and Protocol Stacks is
that clear in practise.

How does DNS fit into this? Eg is it assumed that the application that can
request a minimum encryption can also request DNS resolving properties?
Eg insist on DoH/DoT, or insist on not using ADD, or insist on not using
the famous Quad DNS servers? Or insisting on DNSSEC validated answers only?

How does Remote Access VPN fit into this? Not at all? Or could an
application request "only through VPN connection X" ? Or is this
completely out of scope?  Either way, it could be clarified.

Was MPTCP left out on purpose in all the examples?