Re: [Secdispatch] IETF I-D submission - please review draft-sandowicz-httpbis-httpa2

Reading introduction at https://www.ietf.org/archive/id/draft-sandowicz-httpbis-httpa2-00.html <https://www.ietf.org/archive/id/draft-sandowicz-httpbis-httpa2-00.html> which discusses how load balancers / CDN are insufficiently trusted to see content, I wonder if the current proposal for encrypted client hello (https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ <https://datatracker.ietf.org/doc/draft-ietf-tls-esni/>), which essentially does TLS-over-TLS would solve the problem described in the introduction.  The inner-most TLS could be terminated within the client's TEE and the server's TEE, the outer TLS could be terminated on the load balancer / CDN (if there is one) or in the web server (nginx/apache, etc.).

However, as I skimmed through the rest of the draft, I got the sense there are other motivations for the design.  Those motivations are not clear.  For example, I am confused by the abstract that finishes with "without dependence on TLS" yet Section 3.2 says "In HTTPA/2, the key exchange process follows TLS 1.3 [RFC8446]".  Perhaps what is meant is that HTTPA2 doesn't expect TLS to provide TEE-to-TEE encryption; rather, the new protocol of Section 2 provides the TEE-to-TEE protection and doesn't rely on TLS (in fact, the document seems to assume the load balancer / CDN is an attacker.  Which is fine).  Is there a history of the protocol described in Section 2 and 3, like is this the protocol used to communicate from the TEE across, say, a PCI bus (or PCI-like bus) to other hardware components?  It feels that JWE would be an IETF answer to moving encrypted objects between TEEs (https://en.wikipedia.org/wiki/JSON_Web_Encryption <https://en.wikipedia.org/wiki/JSON_Web_Encryption>).

In Section 4.2 (Replay Protection) the client and the server need to remember the sequence number associated with prior communications to each peer TEE.  This is impossible to store within the TEE for much scale of peer TEEs so implementations would kick that to an outside database (necessary for load balancing amongst a bunch of TEE servers, anyway, I expect).

-d

> On Oct 13, 2022, at 4:38 AM, Sandowicz, Krzysztof <krzysztof.sandowicz@intel.com> wrote:
> 
> Hi,
> In the name of group of people working on an extension to HTTP protocol with attestation called: “The Hypertext Transfer Protocol Attestable (HTTPA)” I submitted our Internet-Draft to IETF HTTPBIS.
> Please find it on: https://datatracker.ietf.org/submit/status/ <https://datatracker.ietf.org/submit/status/> using our I-D name: draft-sandowicz-httpbis-httpa2
>  
> I received information from IETF HTTPBIS WG that I should also ask SECDISPATCH and DISPATCH Working Groups for review in order to set up to answer your questions (in the ART and SEC areas).
> Can you please let me know what is a process for that. Do you review it offline or I should ask you to reserve some time for review during a call?
>  
> Regards,
> Krzysztof Sandowicz
>  
> =============================================================================
> Cloud Software Architect, Intel Product Assurance & Security / Security Software and Services
> Direct (Poland): +48 (58) 766 1619, iNET: 8-348-1619
> =============================================================================
>  
> 
> Intel Technology Poland sp. z o.o.
> ul. Słowackiego 173 | 80-298 Gdańsk | Sąd Rejonowy Gdańsk Północ | VII Wydział Gospodarczy Krajowego Rejestru Sądowego - KRS 101882 | NIP 957-07-52-316 | Kapitał zakładowy 200.000 PLN.
> Spółka oświadcza, że posiada status dużego przedsiębiorcy w rozumieniu ustawy z dnia 8 marca 2013 r. o przeciwdziałaniu nadmiernym opóźnieniom w transakcjach handlowych.
> 
> Ta wiadomość wraz z załącznikami jest przeznaczona dla określonego adresata i może zawierać informacje poufne. W razie przypadkowego otrzymania tej wiadomości, prosimy o powiadomienie nadawcy oraz trwałe jej usunięcie; jakiekolwiek przeglądanie lub rozpowszechnianie jest zabronione.
> This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by others is strictly prohibited.
> 
> _______________________________________________
> Secdispatch mailing list
> Secdispatch@ietf.org <mailto:Secdispatch@ietf.org>
> https://www.ietf.org/mailman/listinfo/secdispatch <https://www.ietf.org/mailman/listinfo/secdispatch>