[Seat] Re: FW: New Version Notification for draft-reddy-seat-expat-transport-00.txt

[tirumal reddy <[e-mail]>]

Hi Markus,

Thanks for the review. please see inline

On Thu, 30 Jul 2026 at 16:16, Markus Rudy <[e-mail]> wrote:

> Hi authors,
>
> Thanks for closing this gap! I have a couple of remarks.
>
> 1. Is there a reason why you decided to use HTTP2 capsules instead of the
> standard HTTP authorization flow [1]? The latter would be compatible with
> HTTP1.1, which is still widely used. Server auth could then use secondary
> server certs.
>

ALTEA needs bidirectional attestation, re-attestation, and capability
negotiation, which complements existing authentication. The HTTP auth flow
is client→server only; secondary server certs are unidirectional with no
re-attestation path.

Extended CONNECT is supported by HTTP/2 and HTTP/3, which are becoming the
preferred protocols for new HTTP deployments. If the draft is adopted, it
will be reviewed by the HTTP Directorate, is likely to undergo further
changes, and will take some time to reach a stable state suitable for early
deployment. Given this, we do not believe that defining an HTTP/1.1
solution is a worthwhile investment.


>
> 2. The shim mode magic looks a bit like an HTTP verb. Did you consider
> using non-letter bytes here to prevent confusion?
>

Good point, updated on Github, see
https://github.com/tireddy2/expat-transport/pull/15.


>
> 3. Do you think the shim protocol should get an ALPN registration, should
> itself support selecting a next protocol, and convey that to the
> application somehow?
>

No. Capsule-based protocols do not register a separate ALPN. Protocol
negotiation is performed using the :protocol header defined for Extended
CONNECT


>
> 4. Might be just me, but I did not immediately understand that the shim
> protocol is sent over the just established TLS session, not the underlying
> transport. It would help if that was explicit.
>

Yes, it runs over the established TLS session, after the handshake and
before app data.


>
> 5. How does reauthentication in capsule mode interact with parallel HTTP
> requests? Are these blocked before receiving and validating an
> AuthenticatorResponse? What if the peer never responds (especially to a
> re-auth request)?
>

ALTEA runs on its own Extended CONNECT stream, so it doesn't block other
streams carrying non-critical traffic that does not require attestation;
whether a message in those streams waits for a validated
AuthenticatorResponse is application policy. If the peer never responds,
the initiator times out and may close the connection. Updated on GitHub.


>
> 6. If the HTTP library ought to hold back requests until the first
> validated AuthenticatorResponse, wouldn't it be easier to use the shim mode
> directly?
>

It allows non-critical traffic that does not require attestation to proceed
in parallel and enables re-attestation, neither of which Shim Mode offers.

Cheers,
-Tiru


>
> Cheers, Markus
>
> [1]: https://www.rfc-editor.org/info/rfc9110/#name-challenge-and-response
>
> ________________________________________
> From: tirumal reddy <[e-mail]>
> Sent: Friday, June 26, 2026 11:41 AM
> To: [e-mail] <[e-mail]>
> Subject: [Seat] FW: New Version Notification for
> draft-reddy-seat-expat-transport-00.txt
>
> Hi all,
> We have posted a new draft, "Application-Layer Transport for Exported
> Authenticators and Attestation" (ALTEA):
> https://datatracker.ietf.org/doc/draft-reddy-seat-expat-transport/
> RFC 9261 defines the Exported Authenticator (EA) mechanism but not how
> requests, responses, and errors are signaled between peers; each
> application has to roll its own. draft-fossati-seat-expat has the same gap
> for attestation Evidence/Attestation Results. This draft fills the gap: it
> defines a binary, generic application-layer transport for EA messages over
> TLS 1.3, with no changes to the TLS layer. Primarily motivated by
> attestation, but usable for any EA exchange.
> Review and comments welcome.
> Best Regards,
> -Tiru & Hannes
>
> -----Original Message-----
> From: [e-mail] <[e-mail]>
> Sent: Tuesday, June 23, 2026 5:46 PM
> To: K Tirumaleswar Reddy (Nokia) <[e-mail]>; Hannes
> Tschofenig <[e-mail]>; Hannes Tschofenig <
> [e-mail]>; K Tirumaleswar Reddy (Nokia) <
> [e-mail]>
> Subject: New Version Notification for
> draft-reddy-seat-expat-transport-00.txt
>
>
> CAUTION: This is an external email. Please be very careful when clicking
> links or opening attachments. See the URL nok.it/ext for additional
> information.
>
>
>
> A new version of Internet-Draft draft-reddy-seat-expat-transport-00.txt
> has been successfully submitted by Tirumaleswar Reddy and posted to the
> IETF repository.
>
> Name:     draft-reddy-seat-expat-transport
> Revision: 00
> Title:    Application-Layer Transport for Exported Authenticators and
> Attestation
> Date:     2026-06-23
> Group:    Individual Submission
> Pages:    23
> URL:
> https://www.ietf.org/archive/id/draft-reddy-seat-expat-transport-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-reddy-seat-expat-transport/
> HTML:
> https://www.ietf.org/archive/id/draft-reddy-seat-expat-transport-00.html
> HTMLized:
> https://datatracker.ietf.org/doc/html/draft-reddy-seat-expat-transport
>
>
> Abstract:
>
>    This document defines a binary, application-layer transport protocol
>    for exchanging Exported Authenticator messages between two peers over
>    TLS.  It provides the signaling required to initiate and complete
>    post-handshake authentication exchanges at the application layer,
>    without requiring modifications to the TLS layer itself.
>
>    While primarily intended to support attestation exchange, the
>    transport is generic and can be used independently for any Exported
>    Authenticator exchange.
>
>    The document further specifies how protocol messages are conveyed as
>    Capsules over an HTTP connection established using the Extended
>    CONNECT method, with support for both HTTP/2 and HTTP/3.  In
>    addition, it defines how the protocol can operate directly over TLS
>    or DTLS 1.3 without an HTTP binding, using a so-called "Shim Mode".
>
>
>
> The IETF Secretariat
>
>