[TLS] Re: Artart last call review of draft-ietf-tls-esni-23

[Eric Rescorla]

Thank you for your close review.

I have made a PR in response to these comments:
PR https://github.com/tlswg/draft-ietf-tls-esni/pull/648

Detailed responses below.

## Editorial

> 10.1 »Security and Privacy Goals« starts with definitions
> (active/passive) that aren’t really Security/Privacy goals.
> Since “passive” is then used distinguishingly in only three places, it
> is not clear that this passage is particularly useful.
> It is also puzzling to sort filtering middleboxes under “passive”.

They are passive from the perspective of ECH's threat model;
this is part of why I think this paragraph is useful.

> 10.1: I cannot find a discussion of a “threat model” under this name
> in RFC 8446.

This is a citation for TLS 1.3. I have added a citation for
3552 behind threat model.


> 10.1: This section starts using the term “host” as a noun with a
> distinguishing quality that in this document is probably related to
> server_name, but not explained (“host” as a noun does not occur in RFC
> 8446).

I changed the term "host" to "server name".

>
> 10.2 appears to address integrity only, where the heading might
> suggest some discussion about confidentiality.

The final sentence addresses confidentiality or the lack thereof.


> I don’t understand the last sentence of 10.3 (“servers with high
> load”…).

I rewrote this a bit.


> 11.3: After »A "Y" or "N" value indicating if the extension is TLS WG
recommends
> that the extension be supported.« — can’t parse »Adding a value with a
> value of "Y" requires Standards Action .« -- s/value/registration/ ?

Fixed.


> 10.11: I would have expected a brief discussion on how granularizing
> the padding to 32 byte steps cannot be used by an attacker to extract
> information beyond that granularity (by causing the client to vary the
> size before padding, straddling a step).

The attacker doesn't control CH at all, so I'm not sure why this
would be needed.


> ## Nits
>
> Please do a pass of replacing “which” with “that” where a restrictive
> clause is intended (usually easy to find by the lack of a comma, about
> two dozen occurrences)

This is one of those folklore grammar rules that does not
match actual English usage, like not splitting infinitives.

http://itre.cis.upenn.edu/~myl/languagelog/archives/001484.html


> Thank you for the many section references; two more could be used in
> »Note that, if the cookie includes a key name,
> analogous to Section 4 of« and »RFC8446]) when ECH is negotiated.«

Done.

> There are at least 17 occurrences of ‘bytes’ for counting lengths in
> bytes and 3 of ‘octet’/‘octets’.

I changed these all to "bytes".


> Please expand HRR on first use.

Done.


> Please define “ECH key” (8 occurrences) and “ECH record” (5
> occurrences).

I am replacing ECH record with HTTPS record, which is already
defined. Defined ECH key.


> Please define “application profile” and “application profile standard”
> (10.4 uses “application using (D)TLS” — is that the same?)

I don't believe this is a necessary change. TLS 1.3 already uses
this term without definition in RFC 8446 S 9.1.


> 1: »the SNI remains the primary explicit signal used to determine the
> server's identity.« -- used by whom?

By observers. Addresed.


> Figure 2 uses private.example.com in the second variant where
> private.example.org is used in the first; may want to use .org here as
well

Fixed.



> 5: it is slightly surprising that the definition list explaining
> config_id and cipher_suite does this in an order different from the
> TPL in the figure above

I take your point, but I think this is reflects the difference
between code (avoiding forward references) and text (top down).


> 5.1: The first figure has a cliff-hanger (length_of_padding); maybe
> add a reference to 6.1.3.

Done.


> 5.2: »This value does not include Handshake structure's four-byte
> header in TLS,«

Removed the comma.


> 6.1.1: »Including ClientHelloOuterAAD as the HPKE AAD binds the
> ClientHelloOuter to the ClientHelloInner, this preventing attackers«
> s/this/thus/ ?

Fixed.

> 6.1.3: »through -their length«

Fixed.

> 6.1.3: »that have sensitive-length fields« (hyphen ➔ space)

This appears to be some kind of rendering error. It's fine in
the markdown. I'll trust the RPC to fix it.


> 6.1.6 »yield a tracking vector« — for whom?
> ➔ supply the server with a tracking vector?

I think this is OK as-is.


> 6.1.7: »reference identity« -- define?

Added a reference to RFC 6125.

> 6.1.7: »(e.g. [RFC3986], Section 7.4 and [WHATWG-IPV4])«
> The "and" does not work here

Fixed.

> 6.2.2: »Correctly-implemented client will ignore those extensions.«

Fixed.


> 10.9: could use superscript in place of 2^64
> (This of course only applies to usage in text, which seems to be the
> only one here.)

Markdown again. I'll let the RPC address.

> 10.10.4: »out-of-scope. including, «

Fixed.

> I assume “page” in 11.3 is what is now called “registry group”?

Yes. Fixed.


On Fri, Mar 14, 2025 at 5:35 AM Carsten Borm

[TLS] Re: Genart last call review of draft-ietf-tls-esni-23

[Eric Rescorla]

Stewart,

Thanks for your review.

I have changed all but the last point, which I believe is correct as-is.

The final issue asked if we should replace the reference to RFC 5077
to RFC 8446, but this text is correct because the reference is to part
of the internal example structure in 5077 and 8446 is just agnostic on
token structure. 5077 is being used by way of analogy, not as a part
of the protocol.

-Ekr


On Tue, Mar 18, 2025 at 8:49 AM Stewart Bryant via Datatracker <
nore...@ietf.org> wrote:

> Reviewer: Stewart Bryant
> Review result: Ready with Nits
>
> 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-esni-23
> Reviewer: Stewart Bryant
> Review Date: 2025-03-18
> IETF LC End Date: 2025-03-13
> IESG Telechat date: Not scheduled for a telechat
>
> Summary:A well written document with some minor nits that are easily
> addressed.
>
> Major issues: None
>
> Minor issues: None
>
> Nits/editorial comments:
>
>fields, such as the ALPN list [RFC7301].  Co-located servers with
> SB> ALPN needs expanding on first use.
> 
>
>or they send a GREASE ECH
> SB> I believe that GREASE is an acronym and should be expanded.
> 
>
> (see Section 2 of
>[DNS-TERMS]).
> SB> ID-NITS identifies the following concern:
>   -- Obsolete informational reference (is this intentional?): RFC 8499
> (ref.
>  'DNS-TERMS') (Obsoleted by RFC 9499)
> Should the reference be changed?
> =
>
>Note that, if the cookie includes a key name, analogous to Section 4
>of [RFC5077], this may leak information if different backend servers
>issue cookies with different key names at the time of the connection.
>
> SB> From ID-NITS
>   -- Obsolete informational reference (is this intentional?): RFC 5077
>  (Obsoleted by RFC 8446)
>
> Should the reference be changed?
>
>
>
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Dnsdir last call review of draft-ietf-tls-esni-23

[Eric Rescorla]

Thank you for your review.

I have made a PR in response to these comments:
https://github.com/tlswg/draft-ietf-tls-esni/pull/646

Detailed responses below.

> In section 6.1.7 "Authenticating for the Public Name", this repeats
> the a public_name should not have any ASCII dots in the wrong places
> and that all labels 63 octects.
>
> Nothing is said about the overall length of DNS name? I assume the
> referenced RFC 5890 references older DNS RFCs about this? But if so,
> why call out the ASCII dots and the label lengths?
>
> At the end of that paragraph other limitations are layed out about the
> "numbers" 0-9 and A-F.
>
> "This avoids public_name... interpreted as IPv4 literals"
>
> Seeing A-F also being mentioned this is "IPv4/IPv6 literals"?  (Then
> again IPv6 would be weird, because there should dots in public_name).

This text is generally about trying to mimic existing browser
behavior for identifying things that might be domain names
while excluding IP addresses. I don't believe we need to talk
about v6, because those addresses have colons.

This text was pretty carefully workshopped and perhaps some of the
other WG members who are more DNS experts might want to weigh
in.



> In section 6.1.8, last paragraph,
>
> "...comply with any freshness rules (e.g., DNS TTLs)"
>
> Fair, but how does the application get access to those TTLs? AFAIK the
normal
> resolving stack doesn't not hand out that information.

Many browsers do their own DNS resolution. As you say, if you use
the OS stack you may not get that information, but it will handle
the TTL for you.



> In section 8.1.1.
>
> "...provided the server is authoritative for the public name."
>
> What is meant by this? Because in DNS a nameserver is authoritative for a
zone
> (and thus the names in that zone). Does this mean the DNS name points to
this
> server (via A or )?

This is talking about the TLS server. I rewrote the text as:

  The retry mechanism repairs inconsistencies, provided the TLS server
  has a certificate for the public name.




> Section 10.2
>
> nit: "Resource Records" -> RRs (I saw RRs already being used in the
document)

Done.


> "ECH records"
>
> What are those? Are these the HTTPS record(s), mentioned in the beginning?

Yes. This is version skew. Changed.


>
> Further more,
>
> "... which is 1:1 with the DNS name that was looked up (modulo DNS
> wildcards)."
>
> As a non-native English speaker, I have trouble understanding the "which
is 1:1
> with the DNS name".

Changed to:

replace the IP address, thus blocking client connections, or substitute
a
unique IP address for each DNS name that was looked up (modulo DNS

> Then
>
> "modula DNS wildcards"
>
> Why is this mentioned? Because a DNS server (internally) knows about DNS
> wildcards, but a client does not (well with DNSSEC you can figure it
out), so
> I'm not sure why this is said here, seems not relevant and even a bit
wrong?

I agree. Removed.


> Nit:
>
> "Encrypted DNS"
>
> Maybe put the references to the RFCs here again?

Instead I used the term "encrypted DNS" above.


> Section 10.3
>
> "... can help mitigate this problem by flushing and DNS or ECHConfig
> state..."
>
> "flushing DNS state" is dropping the HTTPS record information that a
client has
> and performing a lookup again? Because I don't see how DNS state can be
flushed
> from, say the local resolving by such client, but I don't think that was
meant.

That is what we mean. As noted above, many clients use their own resolver.
Added.

(this may not be possible if clients use the operating system resolver
rather than doing their own resolution).


> Section 10.10.2
>
> "... further limit sharing different keys using a short TTL"
>
> OK, yes, this will help a bit, put this information is being put in
public DNS,
> so it's as public as can be... which is the opposite of 'limit
sharing'... ?

What is being shared in this case is the private key that the record
contains the public key for. I changed the text to:

   an IP address. Server operators may further limit sharing of private
   keys by publishing different DNS records containing ECHConfig values
   with different public keys using a short TTL.


> Section 10.10.6
>
> "ECH record"

Fixed.

> used again.
>
> "trusted Recursive Resolver"
>
> I'm unaware of a formal definition of "trusted recursive resolver", so you
> might trust the resolver, but as this document also explains that sounds
a bit
> like hoping for the best? Unsure what to make of this. Or is this the
Firefox
> TRR thing? Which implies DoH/DoT querying?

It's referring to the Firefox thing, but I actually think this is too strong
a claim, so I narrowed it to DNSSEC.


-Ekr


On Fri, Mar 7, 2025 at 4:50 AM R. Gieben via Datatracker 
wrote:

> Reviewer: R. Gieben
> Review result: Ready with Nits
>
> Hello,
>
> I'm the designated reviewer from dnsdir and I've reviewed -23.
>
> I have a bunch of nits and minor questions,

[TLS] Re: Secdir last call review of draft-ietf-tls-esni-23

[Eric Rescorla]

Adam,

Thanks for your comments. The WG discussed the question of guidance for
key rotation and came to the conclusion that we didn't have much useful
to say as a consensus matter, so we opted to remain silent.

-Ekr


On Wed, Mar 5, 2025 at 12:45 PM Adam Montville via Datatracker <
nore...@ietf.org> wrote:

> Reviewer: Adam Montville
> Review result: Ready
>
> Based on my review of this draft I would classify it as "ready" for
> publication, with some minor caveats that don’t fundamentally undermine its
> readiness.The draft defines a clear, well-specified mechanism for
> encrypting
> the ClientHello. It leverages established cryptographic primitives and
> preserves existing TLS 1.3 security properties. The threat model is
> thoroughly
> addressed with a formal analysis documented in a reference.
>
> If it is possible (possibly not in this drat) to offer more detailed
> operational guidance on key rotation, that would be helpful. There are some
> points in the document that might allude to implementation-specific
> configuration choices. Implementations would ideally expose these choices
> to
> operators so they can make the best possible choices for their needs.
>
>
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: WG Adoption Call for Post-Quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

[Sean Turner]

> On Mar 15, 2025, at 9:34 PM, Stephen Farrell  
> wrote:
> 
> Signed PGP part
> 
> Hiya,
> 
> On 15/03/2025 10:14, Russ Housley wrote:
>> Stephen:
>> I did write to Yunlei and ask for an IPR disclosure.  
> 
> Yes, and thanks for doing that.
> 
>> As far as I
>> know, Yunlei has never participated in an IETF activity, so he has
>> not promised for follow the NOTE WELL.
>> Dan pointed the LAMPS WG to a message where KCL publicly claimed
>> patents related to ML-KEM (formerly known as Kyber):
>> https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/Fm4cDfsx65s/
>> m/F63mixuWBAAJ
>> In that same mail archive, the following statement was made by the
>> same person regarding these patents:
>> https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/Fm4cDfsx65s/
>> m/2NzgqoTaBAAJ
> 
> I note the following quote from the discussion (dated May 19, 2022,
> 5:03:08 AM) at that last URL: "Yes, certainly we can make such an
> official claims about patents as you suggest. It may formally start the
> work after NIST or other standard organizations show the applicability
> interest." Maybe I'm being optimistic, but if that the and other
> statements about those patents only being intended defensively are
> the case, it'd seem like that set of inventors might be incented to
> make an IETF IPR declaration if asked, e.g. by a set of WG chairs
> and/or ADs.
> 
> Cheers,
> S.
> 
>> Russ
 On 28/02/2025 18:56, Sean Turner wrote:
> In response to the WG adoption call, Dan Bernstein pointed out
> some potential IPR (see [0]), but no IPR disclosure has been
> made in accordance with BCP 79.
 While I don't think the lack of an IPR declaration is fatal here, I do 
 think it'd be great if that uncertainty could be reduced. I think I saw 
 that Russ tried to reach out to one of
 the possible patent holders to ask if they'd be willing to make
 a declaration. I've no idea where that's at, but I'd encourage
 the TLS chairs and SEC ADs to see if they can help get that to
 happen as reducing uncertainty would be good and if we can't,
 then this topic will just keep cropping up and Dan is not the
 only person I've heard express concerns in this regard.
 Cheers, S.
 PS: I do realise we can't force someone to make an IPR declaration.


Stephen,

We are following up with the ADs and other WG chairs to see what can be done.

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