igest as "opaque
record_digest<0..2^16-1>", and defines that field as containing "A
cryptographic hash of the ECHConfig structure from which the ECH key was
obtained". Would it be correct to implement the "optional record digest"
method by just encoding a zero l
On 6/2/2020 5:44 AM, Christopher Wood wrote:
> On Mon, Jun 1, 2020, at 10:06 PM, Christian Huitema wrote:
>> This draft looks really good. I just have two questions of clarification.
>>
>> I am not sure that I understand the point made in appendix B, Total
>> Client He
On 6/2/2020 11:30 AM, Stephen Farrell wrote:
> Hiya,
>
> Sorry if I'm missing a bit of context...
>
> On 02/06/2020 18:28, Christian Huitema wrote:
>>clients prevent server identification by sending
>> an empty record_digest field in the ClientEncr
the feature, and yes
this is a trade-off between privacy and exposure to DDOS. The point of
section 10.3 is precisely to outline that trade-off.
-- Christian Huitema
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
> On Jun 2, 2020, at 2:26 PM, Ben Schwartz wrote:
>
>
>
>
>> On Tue, Jun 2, 2020 at 4:50 PM Christian Huitema wrote:
>> On 6/2/2020 11:44 AM, Salz, Rich wrote:
>>
>> > Trial description scares me. Perhaps that's not a rationale fear -- on
On 6/2/2020 3:35 PM, Christian Huitema wrote:
>
>> On Jun 2, 2020, at 2:26 PM, Ben Schwartz wrote:
>>
>>
>>
>>
>> On Tue, Jun 2, 2020 at 4:50 PM Christian Huitema > <mailto:huit...@huitema.net>> wrote:
>>
>> On 6/2/2020 11:4
TLS carrying initial
packets is not secret in V1, but it might well become so in a future
version.
-- Christian Huitema
signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On 6/26/2020 10:16 AM, Yiannis Yiakoumis wrote:
>
>
>
> On Fri, Jun 26, 2020 at 7:29 AM, Christian Huitema
> mailto:huit...@huitema.net>> wrote:
>
> On 6/25/2020 11:11 PM, Melinda Shore wrote:
>
> On 6/25/20 3:29 PM, Erik Nygren wrote:
>
>
. Well, given
actors like the Great Firewall, one wonders.
-- Christian Huitema
signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_name extension 0xffce (draft-ietf-tls-esni-00
through -06), not the ECH extensions encrypted_client_hello 0xff02,
ech_nonce 0xff03, outer_extension 0xff04 (draft-ietf-tls-esni-07)."
-- Christian Huitema
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
rts, this is not what is
happening here. The researcher's experiments isolate a simple pattern
matching technique applied to the first client flight.
-- Christian Huitema
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
hard. It has been tried in the past,
as in "make me look like Skype" or "make me look like wikipedia". The
idea is to build a target model, then inject enough noise and padding in
your traffic to match the target model. But that way easier to say than
to do!
-- Christian Huitema
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On 8/10/2020 11:49 PM, Christian Huitema wrote:
> On 8/10/2020 11:14 PM, Rob Sayre wrote:
>> On Mon, Aug 10, 2020 at 10:58 PM Peter Gutmann
>> mailto:pgut...@cs.auckland.ac.nz>> wrote:
>>
>> Rob Sayre mailto:say...@gmail.com>> writes:
>>
>>
nced by that
argument, because it smells a lot like "the other side of the boat is
leaking too, why should I plug this particular leak?"
And so, at Chris Wood's request, I am sending this message to the list.
-- Christian Huitema
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
an't prove
it either way. One solution would be to incorporate more elements in the
hash. Another would be to serialize the whole server hello, with a
proforma random, and add to the hint hash the server hello bytes that
follow the "random" part.
-- Christian Huitema
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
the hint. But Karthik is of course right, the
handshake secret itself does not depend on the transcript; that
dependency is only introduced when the label is derived.
Any big issue keeping N=8?
-- Christian Huitema
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
using the outer CH". Implementation laziness could easily lead
to a state in which only the ECH-using connections use the ECH
extensions in the Server Hello. That would fail both (1) and (2).
-- Christian Huitema
On 9/12/2020 9:59 AM, Karthik Bhargavan wrote:
>> Karthik: That app
1994 called. It wanted to talk about distinguished encoding rules.
On 10/5/2020 8:08 PM, Eric Rescorla wrote:
> I don't have a strong opinion on whether to require a minimal
> encoding, but if we're not going to use QUIC's encoding as-is, then I
> would rather stick with the existing scheme, which
is time to verify the signature go back to the original message
and check the signature.
If we do that, then there is no reason to mandate minimal length
encoding. And TLS already does that. For example, we do not reorder
extensions according to some canonical rules before placing
On 10/6/2020 5:23 PM, Martin Thomson wrote:
> On Wed, Oct 7, 2020, at 04:12, Christian Huitema wrote:
>> * Receiver side: receive the message, save it, parse and process, and
>> when it is time to verify the signature go back to the original message
>> and check the signatur
hat the key is what it expects
for the SSID, then remember that for the following connections. In this
scenario, the Wi-Fi server is always entitled to verify the client's
identity and authorization.
I don't think that these scenarios lend themselves easily to "reversing
the ro
can play games with
specific extensions. Tying the signal to the handshake secret provides a
robust defense against such games, and simplifies the analysis of the
security properties. It also has nice 'don't stick out' properties, but
those are not the only r
On 3/18/2021 10:24 AM, Stephen Farrell wrote:
Hiya,
On 18/03/2021 16:55, Christian Huitema wrote:
On 3/18/2021 7:35 AM, Christopher Patton wrote:
I forget, did we need to bind it to the actual handshake secret, or
was
the transcript and ClientHelloInner.random sufficient? That would
ich the client is using the wrong ECH key, or when an
interceptor interfered with the exchange.
-- Christian Huitema
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
e to decrypt the QUIC Handshake
packets sent by the attacker. The attacker will be able to detect that,
and thus distinguish ECH from !ECH.
-- Christian Huitema
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
.
Internationalization?
-- Christian Huitema
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
if the same server was supporting multiple
application protocols with colliding names.
So, maybe, peace and UTF8?
-- Christian Huitema
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Also, it depends whether the application is HTTP or something else. QUIC
makes an explicit reference to version 1.3. AFAIK, several
implementations of QUIC use stacks that just implement 1.3, no attempts
at backward compatibility whatsoever.
-- Christian Huitema
On 8/5/2021 4:15 PM, Richard
and providing a fallback to H2. So I certainly believe
that we will find deployments of TLS over TCP that are only supporting
TLS 1.3. Whether that's a good idea is something that the market will
decide...
-- Christian Huitema
On 8/5/2021 5:14 PM, Toerless Eckert wrote:
RFC900
0-RTT packets can
only be replayed for a short time after being sent by the client. The
shorter the time, the stronger the mitigation.
Hence the question, how short can the delay of the TLS 1.3 freshness
check be?
-- Christian Huitema
___
TLS
tting the time, and possibly performing updates. I say
"possibly" here, because in scenarios like "disaster recovery", the
local network may not have global connectivity. But even so, setting the
time during enrollment seems logical.
-- Christian Huitema
_
On 8/11/2022 1:54 PM, Benjamin Kaduk wrote:
On Thu, Aug 11, 2022 at 12:35:23PM -0700, Christian Huitema wrote:
Isn't the ANIMA WG working on these scenarios? If there is a formal
"enrollment" process for adding a device to a network, that process could
include setting the tim
of the servers that they want to censor.
If you want to deploy servers that evade censorship, they cannot be
isolated. They have to join some kid of pool, and the pool has to be big
enough and important enough that censors cannot just block the IP
address shared by all pool members. And t
r a while, and then it won't. It is probably not a good idea for the
mice to try publish their new trick as an RFC -- the cat would just get
smarter sooner.
-- Christian Huitema
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
than lying, and also consumes fewer
bytes.
-- Christian Huitema
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
If one connects to a proxy, shouldn't the SNI point to the name of the
proxy?
-- Christian Huitema
On 10/18/2022 8:49 PM, Hannes Tschofenig wrote:
Giving someone, other than those managing the endpoints, the ability
to disable a security feature like ECH is problematic.
If I read
So called "transparent" proxies relie on lies. The price of lies is of course
brittleness. Configured proxies could be made robust.
-- Christian Huitema
> On Oct 19, 2022, at 5:55 PM, Safe Browsing wrote:
>
>
> Hi Christian,
>
> For transparent proxies, no.
&
do define this extension, your hardware will
still have to support the existing specification to talk to this
unmodified clients or servers.
-- Christian Huitema
On 2/10/2023 12:21 AM, Boris Pismenny wrote:
Hi Mikkel.
On Thu, Feb 9, 2023 at 8:21 PM Mikkel Fahnøe Jørgensen
mailto:mikke
On 2/13/2023 7:25 AM, Boris Pismenny wrote:
On Mon, Feb 13, 2023 at 7:20 AM Christian Huitema <mailto:huit...@huitema.net>> wrote:
This issue, packet number encryption versus hardware acceleration, was
discussed in quite some depth during the standardization process. The
that requires maybe 40 or 50 bytes of latency. But it could
certainly be done.
-- Christian Huitema
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
an conjure "truncation attacks"...
-- Christian Huitema
On 8/28/2023 7:38 AM, Viktor Dukhovni wrote:
On Mon, Aug 28, 2023 at 04:02:18AM -0700, RFC Errata System wrote:
Both parties need not wait to receive a "close_notify" alert before
closing their read side of the connection,
On 9/2/2023 4:36 AM, Ben Smyth wrote:
Oh, perhaps: Because RFC8446 doesn't mandate half closure,
implementations could either transmit all data and close write, or just
close inbound?
Or, applications should clean or abrupt termination as part of the
application logic.
-- Chri
my weak guess, or confirm it and result in
specific recommendations such as not using the early secret. Plus, the
formal analysis might also find other issues, behind this one.
-- Christian Huitema
On 12/3/2023 2:00 PM, Eric Rescorla wrote:
To respond directly to the call: I think we should
inimum, this kind of consideration should be added to the security
section if we move this RFC to standards track.
-- Christian Huitema
I will be glad to work with someone that already has things set up for TLS 1.3
without this extension to do a more formal analysis.
Russ
On Dec 3, 2023, at 5:
On 12/5/2023 10:56 AM, Russ Housley wrote:
On Dec 5, 2023, at 12:01 PM, Christian Huitema wrote:
On 12/5/2023 8:13 AM, Russ Housley wrote:
At IETF 104, I presented a slide with informal reasoning about TLS 1.3 Security.
Authentication:
The certificate processing is exactly the same. It
of a CRQC, the external PSK needs to be at
least 256 bits.
Does that resolve your concern?
Yes.
-- Christian Huitema
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Your
guess as to whether this is acceptable is as good as mine.
-- Christian Huitema
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
the "inner PSK" to harden
the session key.
Still another day's work, but seems doable -- and keeping with spirit of
8773, using only old tech like PSK and ECDH instead of relying on
post-quantum algorithms.
-- Christian Huitema
___
TLS m
ed_arrival_time
will be before the current time at the server, and the sanity check will
reject the ticket. If the delays are longer, the freshness test will fail.
I am wondering what the proper fix should be.
-- Christian Huitema
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On 1/10/2024 7:00 PM, Martin Thomson wrote:
On Thu, Jan 11, 2024, at 11:07, Christian Huitema wrote:
One first problem with this code is that implementations may or may not
have an estimate of the RTT when they are issuing the ticket. In theory
the server could measure the RTT by comparing
On 1/10/2024 10:20 PM, Martin Thomson wrote:
On Thu, Jan 11, 2024, at 15:45, Christian Huitema wrote:
Good for you. Not all implementations do that. It is hard for me to
blame them, because the 10 seconds recommendation is justified by for
"clients on the Internet", and delays lar
cooperating
with other clients to compare the keys proposed to them by servers.
-- Christian Huitema
--
Christian Huitema
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
t;.
Detection by clients also provides a clear signal to enterprises that
they should really find another way to solve their problem.
In any case, I just submitted PR #1049
(https://github.com/tlswg/tls13-spec/pull/1049).
--
Christian Huitema
signature.asc
Descripti
rresponding code ends in the common libraries, and that
is reason enough to not publish such a text.
-- Christian Huitema
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
rivate [EC]DH keys. So maybe the recommendation should apply there.
Developers could for example mix the output of the crypto RNG with a
locally held secret before generating the private keys.
--
Christian Huitema
signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
cause it is not OS
dependent. If that is not OK, then developers will need lots of explaining.
--
Christian Huitema
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
r.
>
My goal was to list the current state of solutions. The document could
be split with different drafts presenting different solutions, but I
believe there is value in an attempt at unification.
--
Christian Huitema
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On 8/5/2017 9:44 AM, Adam Langley wrote:
> On Fri, Aug 4, 2017 at 8:37 PM, Christian Huitema <mailto:huit...@huitema.net>> wrote:
>
> Clearly, Section 2 could be turned into some kind of 'problem
> statement" draft. I personally don't like splitting
efore sending anything new.
The other often considered scenarios are variations of the "mobile
network". The NAT rebinds because the mobile router moved to a new
connection, but the client does not know. I can't think of a good
heuristic there, but it certainly would be helpfu
enterprises and data centers do not in
fact see encryption as a problem? Maybe they have found ways to manage
their applications and servers without breaking TLS...
--
Christian Huitema
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
lic keys of
server and client in clear text during the initial exchange. That’s a big
privacy issue!
— Christian Huitema
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
R.
Thanks, and sorry I could not join you in Singapore
-- Christian Huitema
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
ight be, but the
common implementation in our mind is a set of servers behind a load
balancer.
-- Christian Huitema
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
eeling GREASE
> won't be enough...
Data sets. Machine learning algorithms are trained with data sets. If we
produce reference data sets showing what TLS 1.4 looks like, the vendors
can retrain their AI and start recognizing the new version for what it
is, rather than some unknown attack.
-
could
run every application over h2...
-- Christian Huitema
Forwarded Message
Subject:New Version Notification for
draft-ietf-tls-sni-encryption-01.txt
Date: Mon, 19 Feb 2018 12:01:18 -0800
From: internet-dra...@ietf.org
To: Christian Huitema , Eric Rescorla
A new
t;
> (5) Ignoring middleboxes, in my opinion the infrastructure required
> for collaboration between fronting servers and hidden servers
> (stateful, shared-key, public-key, or otherwise) would be a practical
> barrier to entry for most server administrators.
>
The way to check that is to try some test deployments. We shall see.
-- Christian Huitema
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
s could provision the clients with a
set of single-use external PSK identities. But then, that looks a lot
like resumption. Or, clients could generate single-use external PSK
identities by encrypting their long term identity and a nonce with the
public key of the server, a design which of course
it be published as RFC,
and publish very soon a draft that defines the 16 bit field as the
pinning time in hours, and presumably explains how to avoid the usual
pitfalls of pinning. Do I understand correctly?
-- Christian Huitema
___
TLS mailing list
TLS
On 5/16/2018 11:14 AM, Viktor Dukhovni wrote:
>
>> On May 16, 2018, at 1:59 PM, Christian Huitema wrote:
>>
>> The way I understand it, your proposal is not so much to "reserve 16
>> bits" but rather to "include a 16 bit field defined as the pinning tim
This new version of the SNI encryption draft implements the changes
discussed in London. It removes the "solution" part of the draft, for
which consensus was elusive, and keeps the "problem statement" part, for
which we apparently have wide consensus.
-- Christian Huitema
O
first ones to develop and use these randomization
techniques will most likely be the malware authors that the tools are
allegedly trying to track.
-- Christian Huitema
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
+1. I support adoption and will review.
-- Christian Huitema
> On Jul 25, 2018, at 6:37 AM, Mike Bishop wrote:
>
> +1 – there are certainly kinks to work out, but this is a worthwhile
> direction.
>
> From: TLS On Behalf Of Patrick McManus
> Sent: Wednesday, July
The problem being that how the client identifies
> the server might not be something it shares with the server.
There is also a privacy issue with the external identifiers. For session
tickets, this is solved by only using a given resume ticket once, but
that's harder with external PSK.
On 10/30/2018 4:07 AM, Russ Housley wrote:
>> On Oct 30, 2018, at 2:26 AM, Christian Huitema wrote:
>>
>> On 10/29/2018 9:56 PM, Martin Thomson wrote:
>>
>>> You should do something more concrete with the label parameter. Keep
>>> in mind that both cl
ge problem. Security conscious implementations of
TLS should detect the use of such "enhancements", and either abort the
session or automatically treat it as insecure.
-- Christian Huitema
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
gt;
Which reinforces the idea that these "enhancements" have no legitimate
reason to be found "in the wild", and hence should be treated as errors
when detected.
-- Christian Huitema
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
definition of a
hidden channel.
Would it be possible to engineer a hidden channel in the TLS 1.3 Hello?
I bet that's quite doable. I am sure that fields like "opaque
Random[32]" or "opaque legacy_session_id<0..32>" could be used
. The
current decision is "no more than 3 times the size of the data sent by
the client", which is enforced to be at least 1200 bytes. Quic does work
if the server flight is longer than that, but then the handshake takes
at least 2*RTT instead of 1*RTT.
That said, yes, there is a pr
Weird. I sent this message this morning, and it did not arrive on the list.
On 5/22/2019 1:09 AM, Christian Huitema wrote:
> On 5/15/2019 6:20 AM, Joseph Salowey wrote:
>> The last call has come and gone without any comment. Please indicate
>> if you have reviewed the draft eve
s extension.
>
> Does that address your comment?
Yes, although "passive observation will help" is somewhat more benign
than what I would have written. If the "government employee" is some
agent in a foreign country, they may want to think twice before using
the proposed option. Or alternatively, you may want a solution in which
the PSK-ID is randomized using some ESNI-like process.
-- Christian Huitema
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
clients using the
old public key, hence the need to refresh the keys reasonably often. But
there is a flip side of that. If the TTL of the ESNI record is small,
clients will need frequent DNS interactions to refresh it, and their
privacy could also be compromised during these operations.
share the same
hidden server, the ESNI record is fetched only once, and can be cached.
At connection time, the client would only need to query the A/
records of the public server, i.e. exactly the same DNS transaction as
an access to the public server.
-- C
Thanks, Barry. I will incorporate your fixes in the next version, due soon.
-- Christian Huitema
On 9/4/2019 8:41 PM, Barry Leiba via Datatracker wrote:
> Barry Leiba has entered the following ballot position for
> draft-ietf-tls-sni-encryption-05: No Objection
>
> When responding,
introduction with a forward reference to
section 3.7.1?
-- Christian Huitema
On 9/9/2019 12:48 PM, Bernard Aboba wrote:
> Document: draft-ietf-tls-sni-encryption
> Reviewer: Bernard Aboba
> Review result: Ready with Nits
>
> This document has been reviewed as part of the transp
know, or
wait a couple of days and address the last comments. I wonder what is
best for the IESG members. Any opinion?
-- Christian Huitema
On 9/17/2019 7:55 PM, Adam Roach via Datatracker wrote:
> Adam Roach has entered the following ballot position for
> draft-ietf-tls-sni-encryption-0
://datatracker.ietf.org/doc/html/draft-ietf-tls-sni-encryption-06
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-sni-encryption-06
I am going to address the pending comments soon.
-- Christian Huitema
On 9/18/2019 11:27 AM, Benjamin Kaduk wrote:
I
t
will. If the clients just identify the hidden server, then malevolent
actors can spoof the fronting server. The fake fronting server can then
relay the requests and keep tabs on which clients access the hidden service.
-- Christian Huitema
/a
On 9/18/19 4:10 PM, Christian Huitema wrote:
elp define SNI encryption, but does not define the SNI
encryption solution, so deployment inevitably happens after this
document is published. Then, the replacement solutions are not deployed
yet. They are best described using conditional future.
-- Christi
Due to my moderately competent use of GitHub, draft-06 does not include
the resolution of Mirja's comments. That will be part of the next draft.
Sorry.
-- Christian Huitema
On 9/18/2019 2:09 PM, Christian Huitema wrote:
OK, I just submitted draft-06. As the automated message says:
The
Thanks for the feedback, Roman. Comments in line.
On 9/18/2019 4:40 AM, Roman Danyliw via Datatracker wrote:
** Section 1. Per “More and more services are colocated on multiplexed
servers, loosening the relation between IP address and web service”, completely
agree. IMO, unpacking “multiplexed
There is also a privacy angle. From a privacy point of view, it is very nice
that PSK cannot be distinguished from session resumption.
-- Christian Huitema
> On Sep 19, 2019, at 5:57 AM, Richard Barnes wrote:
>
> As nice as that requirement would be, I'm not sure it'
onses and the helpful background. Below are a
> number of proposed text block replacements to clarify my intent (instead of
> more questions).
>
> Roman
>
>> -Original Message-
>> From: iesg [mailto:iesg-boun...@ietf.org] On Behalf Of Christian Huitema
>>
eplacing clear text SNI transmission by an encrypted variant will break or
reduce the
efficacy of the operational practices and techniques implemented in
middle-boxes as
described in Section 2.1. As explained in Section 2.3, alternative solutions
will
have to be developed."
>
>> --
gt; consider my comments resolved. Minor comments inline …
>
>
>
> *From:*Christian Huitema [mailto:huit...@huitema.net]
> *Sent:* Thursday, September 26, 2019 6:53 PM
> *To:* Roman Danyliw ; The IESG
> *Cc:* draft-ietf-tls-sni-encrypt...@ietf.org; tls-cha...@ietf.org;
> tls@ie
for all kinds of
exploitation. In what sense is the "selfie" attack different from that
generic threat?
-- Christian Huitema
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
e document.
-- Christian Huitema
On 10/9/2019 7:20 AM, Rob Sayre wrote:
>
>
> On Wed, Oct 9, 2019 at 9:17 PM Paul Yang <mailto:kaishen...@alipay.com>> wrote:
>
>
>
>> On Oct 9, 2019, at 9:46 PM, Rob Sayre > <mailto:say...@gmail.com>> wr
y points. Is that the kind of
work that you have in mind? I am not sure that it would fit easily
within the TLS charter, but there are other working groups...
-- Christian Huitema
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
the padding field optional, but then the syntax would allow to
not have any padding and that opens a can of worms.. Or suppose that you
need exactly one byte of padding, but the length field is two bytes --
you can't just add one byte, you end up always off by one.
-- Christian Huitema
_
ce of better analysis we
should heed DKG's recommendations for now -- and the recommendation of
padding to 260 does that. I would of course be happy to change my
opinion once we have an ESNI specific study.
-- Christian Huitema
signature.asc
Description: OpenPGP digital signature
__
will want to use ESNI without a record digest, at the
cost of course of trial decryption.
-- Christian Huitema
On 11/26/2019 4:37 AM, Rob Sayre wrote:
> You're right, this is all there in the draft. It's just scattered
> around a bit, and "anonymity set" is used only o
1 - 100 of 142 matches
Mail list logo
