[TLS] Re: Genart last call review of draft-ietf-tls-svcb-ech-06

[Benjamin Kaduk]

On Mon, Oct 28, 2024 at 09:37:27PM +, Ben Schwartz wrote:
>This Message Is From an External Sender
>This message came from outside your organization.
> 
>On ALPNs - Yes, this is something of an open question.  There are some
>hints about this in draft-ietf-tls-esni, e.g. Section 10.5: "A client that
>treats this context as sensitive SHOULD NOT send context-specific values
>in ClientHelloOuter.".
>I've occasionally wondered if we would define an ECHConfig extension that
>indicates a recommended "wire image" for the outer ClientHello, to
>mask differences between clients, but we don't have anything like that
>yet.
>Interaction with QUIC version is also a fun question, and goes to the ALPN
>vs. transport distinction.  This is also as-yet-undetermined, but might
>involve a new SVCB parameter for supported QUIC versions, and/or perhaps
>some notion of "compatible" and "incompatible" QUIC versions.
>On 1/K anonymity - The upshot of this is "large K is better", i.e. "ECH
>helps more if your service shares hosting with lots of other services
>whose access patterns are similar.".  But that's a decision that must be
>weighed against many other factors, from consolidation pressure to
>infrastructure budget, so it seemed best to just mention the math and let
>the operator choose as they will.

I agree that there's going to be a tradeoff between larger K's privacy benefit 
and other considerations, but it seems to me that even the framing as "1/K" is 
misleading.
When the sites behind a given fronting service are of differingi popularity, 
the attacker can do better than 1/K at guessing.  If I'm fronting for a site 
that gets 900k hits/day and ten that get 10 hits/day, the attacker can just 
guess that all requests are for the popular site and they'll get the right 
answer 99.9% of the time.  I do see the disclaimer about "idealized deployment" 
at the start of the paragraph but I think we could do more to highlight just 
how idealized this portrayal is.

-Ben

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Genart last call review of draft-ietf-tls-svcb-ech-06

[Ben Schwartz]

On ALPNs - Yes, this is something of an open question.  There are some hints 
about this in draft-ietf-tls-esni, e.g. Section 10.5: "A client that treats 
this context as sensitive SHOULD NOT send context-specific values in 
ClientHelloOuter.".

I've occasionally wondered if we would define an ECHConfig extension that 
indicates a recommended "wire image" for the outer ClientHello, to mask 
differences between clients, but we don't have anything like that yet.

Interaction with QUIC version is also a fun question, and goes to the ALPN vs. 
transport distinction.  This is also as-yet-undetermined, but might involve a 
new SVCB parameter for supported QUIC versions, and/or perhaps some notion of 
"compatible" and "incompatible" QUIC versions.

On 1/K anonymity - The upshot of this is "large K is better", i.e. "ECH helps 
more if your service shares hosting with lots of other services whose access 
patterns are similar.".  But that's a decision that must be weighed against 
many other factors, from consolidation pressure to infrastructure budget, so it 
seemed best to just mention the math and let the operator choose as they will.

--Ben

From: Lucas Pardue via Datatracker 
Sent: Saturday, October 26, 2024 4:29 PM
To: gen-...@ietf.org 
Cc: draft-ietf-tls-svcb-ech@ietf.org 
; last-c...@ietf.org 
; tls@ietf.org 
Subject: Genart last call review of draft-ietf-tls-svcb-ech-06

Reviewer: Lucas Pardue
Review result: Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-tls-svcb-ech-06
Reviewer: Lucas Pardue
Review Date: 2024-10-26
IETF LC End Date: 2024-11-15
IESG Telechat date: Not scheduled for a telechat

Summary:

This document defined how TLS Encrypted ClientHello (ECH) connections can be
bootstrapped via the DNS. ECH provides privacy for client by encrypting
information that can identify the service they are connecting to (the SNI) but
furthermore any other information that needs to go in the ClientHello, such as
QUIC transport parameters. ECH is one of the final missing pieces for protocol
designers that want to leverage client-offers without trading off user privacy.
Having the means for clients to discover and correctly configure ECH is
essential. While many mechanisms could work, the DNS offers a widely
distributed and immediately available option.

The document clearly defines the wire format for distributing ECH information
to clients. It also takes care to detail considerations related to complex but
realistic deployments, such as multi CDN, that could cause operational issues
if misconfigured. It is my opinion that this document provides a solution to
the stated problem and is ready to go.

I have 3 comments on the draft that sit somewhere between minor and editorial.
These are just comments, and might reveal my lack of familiarity with the
subject matter more than any issue with the document. If the authors wish to
respond I'd appreciate it but there is no expectation for them to retread
explanation or details that may have already been resolved during the WG phase.

Comment 1 - Section 5.2 ClientHello construction

To paraphrase the text, my read is "when ECH is in use, the HTTPS alpn svcparam
is only used for the inner ClientHello, not the outer". This immediately made
me wonder how the outer ClientHello is constructed. I read Section 10.5 of
draft-ietf-tls-esni-22 but I'm still not sure. For example, if I provide an
HTTP/2 only service and advertise that, the client has to attempt to connect
with ECH containing an ALPN extension of "h2" no? Or should it stick an
"http/1.1" in there, even though it knows it won't do anything, for the purpose
of defeating on-path observers of the outer ECH?

I didn't spend much time thinking about this but I'm having some weird visions
about where this might go if add new QUIC versions and need new ALPNs for
mappings on those. For example, HTTP/X over QUIC version Y, advertised via a
SVCB would necessitate the client connect using QUIC version Y and send an
outer ECH with what ALPNs?

Maybe this is just something we punt on for now, or state that QUIC version
negotation could solve it or something. I'm just left with a feeling of not
being sure what to do here and it feels like a security consideration that
isn't highlighted with a back ref in the security considerations.

Comment 2 - Section 6 Interaction with HTTP Alt-Svc

I had not really considered the interactions of ECH with Alt-Svc. This section
is good. It's beyond the scope of this I-D to comment on, but wonder if this is
another death knell for Alt-Svc b

[TLS] Re: Adoption call for Large Record Sizes for TLS and DTLS

[Sean Turner]

Just a reminder that this adoption call is still on going.

spt

> On Oct 24, 2024, at 22:46, Sean Turner  wrote:
> 
> At the TLS meeting at IETF 119 we discussed the Large Record Sizes for TLS 
> and DTLS I-D; see [0] and [1]. There has been some list discussion; see [2] 
> and [3]. The I-D has been revised a few times since IETF 119 to incorporate 
> list feedback. This message is to judge consensus on whether there is support 
> to adopt this I-D. If you support adoption and are willing to review and 
> contribute text, please send a message to the list. If you do not support 
> adoption of this draft, please send a message to the list and indicate why. 
> This call will close on November 7, 2024. 
> 
> Thanks,
> Deirdre, Joe, and Sean
> 
> [0] 
> https://datatracker.ietf.org/doc/draft-mattsson-tls-super-jumbo-record-limit/ 
> [1] 
> https://datatracker.ietf.org/meeting/119/materials/slides-119-tls-large-record-sizes-for-tls-and-dtls-00
>  
> [2] https://mailarchive.ietf.org/arch/msg/tls/ZnGzqIWOkpm_F6zaqAxxtReHpVg/
> [3] https://mailarchive.ietf.org/arch/msg/tls/cRH9x6nbLeAnkG-fhOS3ASDA3oU/

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: WG Last Call for draft-ietf-tls-rfc8447bis, "IANA Registry Updates for TLS and DTLS”

[Sean Turner]

Thanks Rich. These all look good to me.

spt

> On Oct 16, 2024, at 15:23, Salz, Rich  
> wrote:
> 
> This email starts the working group last call for "IANA Registry Updates for 
> TLS and DTLS” I-D, located here:
> 
> I found a few nits.  Diff at https://github.com/tlswg/rfc8447bis/pull/58/files
>  
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Genart last call review of draft-ietf-tls-svcb-ech-06

[Lucas Pardue]

Hey Ben,

Responding in line:

On Mon, Oct 28, 2024, at 21:37, Ben Schwartz wrote:
> On ALPNs - Yes, this is something of an open question.  There are some hints 
> about this in draft-ietf-tls-esni, e.g. Section 10.5: "A client that treats 
> this context as sensitive SHOULD NOT send context-specific values in 
> ClientHelloOuter.".
> 
> I've occasionally wondered if we would define an ECHConfig extension that 
> indicates a recommended "wire image" for the outer ClientHello, to mask 
> differences between clients, but we don't have anything like that yet.
I guess it's a bit open and up to the client, that's a bit outside my 
wheelhouse so I can't provide much more useful commentary. I'll trust the 
authors have considered things and made the best call for this draft. 
> 
> Interaction with QUIC version is also a fun question, and goes to the ALPN 
> vs. transport distinction.  This is also as-yet-undetermined, but might 
> involve a new SVCB parameter for supported QUIC versions, and/or perhaps some 
> notion of "compatible" and "incompatible" QUIC versions.
Yeah. martin Duke and I put out a draft a while ago for a "quicv" SvcParamKey 
[1]. It's been on ice since there's not been much of a problem to solve and 
around the same time the HTTP WG had been discussing killing Alt-Svc so we 
wanted to see how the wind blew. We could always defrost the work if there's 
problems to solve. I think this draft is fine to proceed in its current state.

> 
> On 1/K anonymity - The upshot of this is "large K is better", i.e. "ECH helps 
> more if your service shares hosting with lots of other services whose access 
> patterns are similar.".  But that's a decision that must be weighed against 
> many other factors, from consolidation pressure to infrastructure budget, so 
> it seemed best to just mention the math and let the operator choose as they 
> will.

That seems OK. I have no inspiration for any additional text you could add.

Cheers
Lucas

[1] - https://datatracker.ietf.org/doc/draft-duke-httpbis-quic-version-alt-svc/
> --Ben
> 
> 
> *From:* Lucas Pardue via Datatracker 
> *Sent:* Saturday, October 26, 2024 4:29 PM
> *To:* gen-...@ietf.org 
> *Cc:* draft-ietf-tls-svcb-ech@ietf.org 
> ; last-c...@ietf.org 
> ; tls@ietf.org 
> *Subject:* Genart last call review of draft-ietf-tls-svcb-ech-06
>  
> 
> 
> Reviewer: Lucas Pardue
> Review result: Ready
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
>   >.
> 
> Document: draft-ietf-tls-svcb-ech-06
> Reviewer: Lucas Pardue
> Review Date: 2024-10-26
> IETF LC End Date: 2024-11-15
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary:
> 
> This document defined how TLS Encrypted ClientHello (ECH) connections can be
> bootstrapped via the DNS. ECH provides privacy for client by encrypting
> information that can identify the service they are connecting to (the SNI) but
> furthermore any other information that needs to go in the ClientHello, such as
> QUIC transport parameters. ECH is one of the final missing pieces for protocol
> designers that want to leverage client-offers without trading off user 
> privacy.
> Having the means for clients to discover and correctly configure ECH is
> essential. While many mechanisms could work, the DNS offers a widely
> distributed and immediately available option.
> 
> The document clearly defines the wire format for distributing ECH information
> to clients. It also takes care to detail considerations related to complex but
> realistic deployments, such as multi CDN, that could cause operational issues
> if misconfigured. It is my opinion that this document provides a solution to
> the stated problem and is ready to go.
> 
> I have 3 comments on the draft that sit somewhere between minor and editorial.
> These are just comments, and might reveal my lack of familiarity with the
> subject matter more than any issue with the document. If the authors wish to
> respond I'd appreciate it but there is no expectation for them to retread
> explanation or details that may have already been resolved during the WG 
> phase.
> 
> Comment 1 - Section 5.2 ClientHello construction
> 
> To paraphrase the text, my read is "when ECH is in use, the HTTPS alpn 
> svcparam
> is only used for the inner ClientHello, not the outer". This immediately made
> me wonder how the outer ClientHello is constructed. I read Section 10.5 of
> draft-ietf-tls-esni-22 but I'm still not sure. For example, if I provide an
> HTTP/2 only service and advertise that, the client has to attempt to connect
> with ECH containing an ALPN extension of "h2" no? Or