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 Schwartz
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.
>>
>
>
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 layer of the cTLS skips the
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
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
be
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
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 operator.
--Ben
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
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
G adoption, 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: Benjami
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
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
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
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
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
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
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
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
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
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
> 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
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
.
* 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
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
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/
t 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
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, including our colleagues who are vendors t
versary who is an active
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 <bem...@google.com> wrote:
>
>> I don't understand why ATLS allows the app to
33 matches
Mail list logo
