Hi TLS,
This is a minor editorial revision to address review comments from the IESG.
--Ben Schwartz
From: internet-dra...@ietf.org
Sent: Monday, June 16, 2025 10:02 AM
To: i-d-annou...@ietf.org
Cc: tls@ietf.org
Subject: [TLS] I-D Action: draft-ietf-tls-svcb
From: Christian Huitema
Sent: Monday, June 9, 2025 1:13 PM
...
> On 6/9/2025 12:35 AM, Martin Thomson wrote:
...
>> The purpose of the ALPN parameter in SVCB is not so much to change what the
>> client offers in the ClientHello, but to allow the client to filte
This sounds a bit like draft-ietf-dance-client-auth.
--Ben Schwartz
From: Phillip Hallam-Baker
Sent: Tuesday, May 20, 2025 10:44 PM
To: tls
Subject: [TLS] Transparent TLS Client Auth (t2CA)
I have floated parts of this scheme in OAUTH and DANE. As we all know
or
TLS, so ECH would not affect them.
There is a draft in the TLS working group for logging of session keys,
specifically including ECH keys [1]. That seems potentially relevant to any
use of ECH, not only uses that rely on DNS as discussed in this draft, so I
don't see the need for a re
te is about avoiding user-visible failures.
> Is there
> a reason why one spec uses SHOULD while the other uses a MUST?
Taken together, these quotes mean "deployments SHOULD avoid using the recovery
flow, and MUST NOT create an arrangement that will fail to connect".
--Ben Sc
From: Orie Steele via Datatracker
> I'm not an expert on TLS or ECH, so I found myself wondering if servers
> SHOULD/MUST support a protocol version that is compatible with ECH,
> specifically to avoid degrading gracefully.
This is an interesting question. The
Thanks, Roman. I've included that correction in
https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/24.
--Ben Schwartz
From: Roman Danyliw via Datatracker
Sent: Friday, May 2, 2025 11:00 AM
To: The IESG
Cc: draft-ietf-tls-svcb-...@ietf.org ;
tl
From: Éric Vyncke via Datatracker
...
> --
> COMMENT:
> --
...
> Titles of sections 4 and 5 should include "TLS" to remove any
From: Gunter Van de Velde via Datatracker
> 107
> ech="AEj+DQBEAQAgACAdd+scUi0IYFsXnUIU7ko2Nd9+F8M26pAGZVpz/KrWPgAEAAEAAWQ
> 108 VZWNoLXNpdGVzLmV4YW1wbGUubmV0AAA="
> GV> I used some tooling to decode this Base64 blob. It seems to decode into
> hex
>
From: Mohamed Boucadair via Datatracker
Sent: Wednesday, April 30, 2025 10:57 AM
...
--
DISCUSS:
--
...
> # Write-up
> The w
From: Linda Dunbar via Datatracker
Sent: Wednesday, April 9, 2025 3:58 PM
To: ops-...@ietf.org
Cc: draft-ietf-tls-svcb-ech@ietf.org
; last-c...@ietf.org
; tls@ietf.org
Subject: Opsdir ietf last call review of draft-ietf-tls-svcb-ech-07
...
> Mixed SVCB
rpa" (or perhaps omitted
entirely).
--Ben Schwartz
* We can discuss if this raises concerns about forward secrecy, given the
actual distribution of lagging ECHConfig lifetimes.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
e properties to their users.
4. I've opened a PR to add a reference:
https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/23
5. This seems like a topic that is related to ECH generally, not specific to
the "ech" SVCB parameter, so I don't think it should be covered
Hi Ben,
I've proposed a text change to strengthen the warning in that paragraph:
https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/20
--Ben Schwartz
From: Benjamin Kaduk
Sent: Monday, October 28, 2024 6:26 PM
To: Ben Schwartz
Cc: Lucas Pardue ; draft
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 ECHC
Thanks for noticing the example.net error. Fixed! [1].
I think we made that a SHOULD for contrast with the requirement that the server
prove authority for public_name. If the server isn't authoritative for
public_name, the connection will fail completely, so that's a MUST. If the
server has
OK. Erik, Mike, Paul: Let me know if you have any further comments on #18.
--Ben
From: Sean Turner
Sent: Wednesday, October 16, 2024 3:06 PM
To: draft-ietf-tls-svcb-ech.auth...@ietf.org
Cc: dn...@ietf.org WG ; TLS List
Subject: Re: [TLS] [DNSOP] Re: Re: Re: Re
ensus
for.
--Ben
From: Eric Rescorla
Sent: Friday, October 4, 2024 8:07 AM
To: Salz, Rich
Cc: Arnaud Taddei ; Ben Schwartz ;
Paul Vixie ; Paul Wouters ;
draft-ietf-tls-svcb-ech.auth...@ietf.org
; TLS@ietf.org ;
dn...@ietf.org WG
Subject: Re: [DNSOP] Re: [TLS]
ble.
These requirements are entirely compatible with "protective DNS". I'm happy to
adjust the proposed text as needed to make that clear.
--Ben
From: Arnaud Taddei
Sent: Wednesday, October 2, 2024 9:54 AM
To: Paul Vixie
Cc: Deirdre Connolly ; Ben Schw
OK, done: https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/16
From: Salz, Rich
Sent: Monday, September 30, 2024 1:29 PM
To: Ben Schwartz ; Eric Rescorla ; Paul Wouters
Cc: draft-ietf-tls-svcb-ech.auth...@ietf.org
; ;
dn...@ietf.org WG
Subject: Re: [TLS
I don't see any reason why an enterprise, family, or personal filter would
filter SVCB responses based on the "ech" SvcParam described in this draft. The
SNI data concealed by ECH is just the SVCB and QNAME. Any DNS-modifying
entity that could implement RDATA-based response policies could
I've written up adjusted references based on Paul's recommendations [1]. (I
haven't deleted the reference to RFC 1034, as I believe it remains the
authoritative RFC on what DNS is all about.)
Regarding Section 3.1 of SVCB (RFC 9460) [2], we imagine the client uses DoT to
issue and SVCB qu
also includes some slight
configuration changes that were made in support of that formal analysis.
--Ben Schwartz
[1] https://eprint.iacr.org/2023/1390
A new version of Internet-Draft draft-ietf-tls-ctls-09.txt has been
successfully submitted by Benjamin Schwart
On Thu, Jan 5, 2023 at 9:37 AM Eric Rescorla wrote:
...
> On Wed, 4 Jan 2023 at 17:10, Eric Rescorla wrote:
>> > When would this actually happen?
>>
>> Assuming this could happen, then the RFC should surely mention the
>> possibility, and perhaps be reworked to avoid raising an error.
>>
>
> Per
gt; On 4 Jan 2023, at 17:10, Eric Rescorla wrote:
>
>
>
> On Wed, Jan 4, 2023 at 6:30 AM Ben Schwartz 40google@dmarc.ietf.org> wrote:
>
>> On Wed, Jan 4, 2023 at 7:50 AM Kristijan Sedlak
>> wrote:
>>
>>> Hey,
>>>
>>> The record la
ontents, so we can use that in
addition to the null profile and "long" custom profiles.
>
> Thanks.
>
> K
>
>
> On 4 Jan 2023, at 15:07, Ben Schwartz wrote:
>
> Coalescing threads.
>
> On Wed, Jan 4, 2023 at 6:09 AM Kristijan Sedlak
> wrote:
>
On Wed, Jan 4, 2023 at 7:50 AM Kristijan Sedlak
wrote:
> Hey,
>
> The record layer of the cTLS skips the "profile_id" in the
> CTLSServerPlaintext. I wonder how will an endpoint correctly distinguish
> between multiple, CID-ext-based CTLSClientPlaintext requests and
> CTLSServerPlaintext response
Coalescing threads.
On Wed, Jan 4, 2023 at 6:09 AM Kristijan Sedlak
wrote:
> CTLS looks interesting.
>
> 1. Is it too early for us developers to start working on implementations?
Now is a great time to start on an implementation!
2. Is this the way where UDP-based TLS is going in general or i
possible.
Regards,
Ben Schwartz
[1]
https://datatracker.ietf.org/meeting/114/materials/slides-114-tls-ctls-06-00
On Tue, Jan 3, 2023 at 11:58 AM wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Transport La
y any TLS server.
On the topic of the "anonymity trilemma": this claim does not apply. ECH
is not an "anonymous communication protocol" as defined in this paper (or
otherwise), as it does not attempt to conceal the user's intended
destination from the ECH operato
On Thu, Oct 13, 2022 at 8:58 AM Marwan Fayed wrote:
...
> There are really only two ways to populate the outer-SNI. One way is a
> fixed name that easily identifies the content operator, e.g.
> ‘operator-ech.com’. In that case, the number of packets with the fixed
> outer SNI is sufficiently extr
I noticed some confusion today about the topic of ambiguous transcripts in
cTLS. My claim was not that any single cTLS profile has an ambiguous
transcript. If such a thing were true, I believe that would be a bug in
the cTLS specification.
Instead, I was trying to highlight the concern of "profi
I am supportive of this effort, but I am not convinced that the proposed
mechanism is right.
In ECH, there are two essential deployment topologies: "shared" and
"split". In "shared" mode there is operationally only one TLS server
(processing inner and outer ClientHellos); in "split" mode there ar
ption, and will be
implementable once the open issues in the cTLS draft are addressed. Please
review.
Thanks,
Ben Schwartz
-- Forwarded message -
From:
Date: Sun, Apr 10, 2022 at 8:40 PM
Subject: New Version Notification for draft-cpbs-pseudorandom-ctls-01.txt
To: Be
On Tue, Feb 22, 2022 at 4:23 PM David Benjamin
wrote:
> On Tue, Feb 22, 2022 at 3:58 PM Ben Schwartz 40google@dmarc.ietf.org> wrote:
>
>> I continue to support this draft.
>>
>> I am puzzled by the requirement that "A server MUST omit any compatible
I continue to support this draft.
I am puzzled by the requirement that "A server MUST omit any compatible
protocols from this extension". Including them seems harmless, and
omitting them seems to impose an unstated requirement that (1) both parties
also include the ALPN extension and (2) the impl
connection
IDs in cTLS/TCP. Move profile_id into ClientHello. Always include the
connection ID and sequence number in the first record of a cTLS/UDP
datagram, and never in subsequent records.
Thanks,
Ben Schwartz, Chris Patton
smime.p7s
Description: S/MIME Cryptographic Signature
Feature request for cTLS: NAT Slipstream defense.
In the NAT Slipstream attack [1], the server causes the client to emit TCP
data that confuses a middlebox. This attack is possible because, in
insecure HTTP, the server can largely control the TCP contents of
client->server communication (after th
On Thu, May 20, 2021 at 6:30 AM Salz, Rich wrote:
> Look at RFC 701, it says: the precise set of octet values that identifies
> the protocol. This could be the UTF-8 encoding of the protocol name.
>
> So I changed my mind and think it's okay to leave as-is but wouldn't mind
> if it became less ge
This seems like a reasonable suggestion to me, so long as the value is
purely a "hint", as you seem to be proposing. I would suggest structuring
it as an ECHConfig extension. This would avoid the need for multiple
points of integration between TLS and DNS, support the use of HRR hints in
other EC
Maybe tag the git revision that you intend to publish as -10?
On Wed, Feb 24, 2021 at 4:39 PM Stephen Farrell
wrote:
>
>
> On 24/02/2021 21:30, Christopher Patton wrote:
> > Hey Stephen, I'd imagine the CF server will stay at ECH-10 through
> > IETF 110.
>
> Great. If I don't get it working by t
I find the language around "optional" configuration identifiers confusing
here. Both of these proposals require ECHConfig to specify an identifier,
and both of them require the client to transmit one, so it doesn't seem
very "optional". I think the point is that special case usage profiles are
pe
yptographic algorithms used", which are separate considerations.)
On Mon, Feb 8, 2021 at 7:41 PM Peter Gutmann
wrote:
> Ben Schwartz writes:
>
> >If you are updating the text, I would recommend removing the claim about
> >performance. In general, the ciphersuites speci
If you are updating the text, I would recommend removing the claim about
performance. In general, the ciphersuites specified in the text are likely
to be slower than popular AEAD ciphersuites like AES-GCM.
On Fri, Feb 5, 2021 at 5:38 PM Jack Visoky wrote:
> Hi Ben,
>
>
>
> Thanks for the feedba
I'm not able to understand the new text in Section 6. Are you saying that
clients MUST include all the listed extensions/features, but MAY also
include extensions/features not listed in the MUD profile? So the MUD
profile only acts as a "minimum" set of features?
On Tue, Sep 22, 2020 at 7:34 AM
On Wed, Jul 15, 2020 at 2:25 AM Martin Thomson wrote:
> you need to configure discovery methods and your TLS stacks with the same
> information (though your TLS configuration can be more conservative in
> terms of advertising a subset of what can be discovered, so that
> deployments can be s
I am supportive of this draft. I don't think it's needed now, but
eventually I would like to live in a world where we don't have to tolerate
these kinds of downgrades, and I don't think it's too early to be drawing
up the mechanism to prevent them.
For ease of deployment, I wonder whether the con
Thanks for this draft. I believe this is an important problem for HTTP
extensibility, and I'm glad to see work on a solution.
It occurs to me that this solution requires pretty tight integration
between the TLS termination and the HTTP backend. Some TLS load balancers
already support ALPN, but t
> E. Multiple Ticket Reuse: Client want separate tickets for concurrent
connections, that are later reused
> Viktor described a case in which a client is split across multiple
processes, so could be convenient to have independent tickets that are all
retrieved from an initial connection that reques
I support adoption.
In the spirit of Ted Hardie's comment on dividing the work into pieces, I'd
like to suggest putting the handshake compression into a separate draft
from the certificate compression. Certificate compression could be made
into an extension that is usable in standard TLS. cTLS ca
* Added a certificate padding procedure
* Added a replay defense
Please review.
There were several requests in Montreal for a proper security analysis of
the authentication procedure in this draft, so I would especially
appreciate reviews or referrals on that front.
Thanks,
Ben Schwartz
--
On Mon, Oct 21, 2019 at 3:24 PM Stephen Farrell
wrote:
>
>
>
> On 21/10/2019 20:14, Rob Sayre wrote:
> > I have seen MTUs under 1500 many times, but nothing under 1200. Is there
> > data on this? (I honestly haven't seen any)
>
> My assumption is that maybe 90% of names are <60 octets.
> That mean
Normally, virtual-hosted TLS servers are known to a client by their domain
name, and the client uses DNS to find an IP address corresponding to this
domain name. The ESNI drafts are largely written in reference to this
configuration.
I think Rob is describing the case where a TLS client is contac
might have less latency overhead
than an oracle. Alternatively, we could imagine a "push oracle", at the
cost of potentially severe implementation complexity to handle reorderings,
failures, etc.
On Sat, Jun 29, 2019, at 02:52, Ben Schwartz wrote:
> > Hi TLS,
> >
> >
On Tue, Dec 18, 2018 at 4:14 PM Ilari Liusvaara
wrote:
> On Tue, Dec 18, 2018 at 12:29:56PM -0500, Ben Schwartz wrote:
> > I'd like to propose a solution to the ESNI + Multi-CDN problem (which has
> > been discussed a lot on this list already). My suggestion is that we
>
On Tue, Dec 18, 2018 at 2:56 PM Salz, Rich wrote:
>
>- I'd like to propose a solution to the ESNI + Multi-CDN problem
>(which has been discussed a lot on this list already). My suggestion is
>that we define the ESNI DNS record format as optionally including "stapled"
>A/ reco
o implement the rare case properly.
--Ben Schwartz, Jigsaw
smime.p7s
Description: S/MIME Cryptographic Signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
gt; absolutely addressed in a way that's appropriate and sincere. I saw the
> same with requests to re-insert RSA Kx late last year. The PATIENT
> folks have gotten a fair hearing.
>
> My architectural concerns have been heard, somewhat less eagerly. Some
> participants, includi
ctive
intermediary in your HTTP session. If so, then this wouldn't seem to
protect the user against the threat.
>
>
> --Richard
>
>
> On Mon, Oct 30, 2017 at 6:43 PM, Ben Schwartz wrote:
>
>> I don't understand why ATLS allows the app to be less "aware
59 matches
Mail list logo
