er random" marker but
>> otherwise not care too much about whether it received it internally (shared
>> mode) or somewhere over the network.
>
> FWIW: same here.
What happens if a client establishes a direct TCP connection with a BE server
and adds an E
er to study a way to "reconnect to the same application
context". Cooperation of load balancers would help, but this can also be
done by servers recognizing the reconnection request and appropriately
redirecting the connection. I could see work on a QUIC extension to d
ords are keyed by domain name +
scheme. The scheme depends on the application, and thus from the ALPN.
If I want to refresh the data about the client facing server, I need to
know for what scheme I am doing that.
-- Christian Huitema
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
extension.
Regards,
Raghu Saxena
On 6/7/25 8:32 AM, Christian Huitema wrote:
I am implementing the ECH draft, and there is something a little
unclear.
Suppose a backend server "backend.example.com" implementing the
application protocol "example" (i.e., not H3). Before
t;, but should that request be for the SVCB record
corresponding to the "example" service, or for the HTTPS record
corresponding to H3?
Obviously, the practical answer is "connect to `facing.example.com` port
number to 443 setting the outer
to install the debug version of `browser.exe` or whatever is
way too much bother. Hence the feedback loop, with the backdoor enabled
everywhere.
Some things should not be standardized.
-- Christian Huitema
On 2/21/2025 6:43 AM, Andrei Popov wrote:
I agree with Stephen and Tomas on this one. Addition
reuse by a peer? -- Christian Huitema On Dec 12, 2024, at 10:11 AM, Andrei Popov wrote:
+1 in favor of option1.
Cheers,
Andrei
From: Russ Housley
Sent: Thursday, December 12, 2024 9:43 AM
To: Joe Salowey
Cc: IETF TLS
Subject: [EXTERNAL] [TLS] Re: Disallowing reuse of ephemeral keys
e?:-)
+1
-- Christian Huitema
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
ce of that happening yet.
-- Christian Huitema
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
f you look at the work in the
transport area, you will see a lot of activity on TCP and on QUIC, and
very rarely hear about TLS. That chimes with David Benjamin's analysis
about the "whole mess of transport-related concerns that just don't
apply to TLS". The expertise for that
if the Server Hello is larger than 12,000 bytes.
If would be very nice to have PQC variants that fit inside that budget.
-- Christian Huitema
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
aft-ietf-tls-keylogfile.
As for exporting the ECH key, there is a much simpler solution. If the
problem is "get a PCAP for debugging", just turning of ECH for the
debugging session would suffice. And it would also make the trade-off
be
option, and it should be hard to use, by design.
-- Christian Huitema
On 7/25/2024 11:01 AM, Andrei Popov wrote:
* The ultimate goal is to simplify adoption of ECH for both developers
of TLS software and implementers
Understood; I do not question the goals of the authors.
* Wit
ll known" trust store, probably from a short list. I
am concerned that such mechanisms reinforce ongoing centralization of
the web.
-- Christian Huitema
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
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
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
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
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
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
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
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
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:
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
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
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,
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
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
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
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.
&
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
than lying, and also consumes fewer
bytes.
-- Christian Huitema
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
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
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
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
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
_
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
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
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
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
.
Internationalization?
-- 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
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
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
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
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
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
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
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
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
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
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
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
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:
>>
>>
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
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
_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
. 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
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:
>
>
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/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
> 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
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 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
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
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
at. Greasing is one. Actually
using the extension even for sites that have just one SNI, but want to
hide usage of multiple ALPN. In the case of QUIC, using the extension to
negotiate a secret and protect the Initial packets. If everybody does
it, the c
pointing to this comment is section 5.
We can observe that ECHO already sticks out, because of the presence of
an unexpected encrypted field in the Client Hello. So in practice ECHO
deployment already relies on achieve large scale deployment, and
possibly greasing the encrypted parameter.
-- Chr
extensions. If the extensions are encrypted in the ESNI, they
cannot do that. And then, we have extensions that reveal a lot about the
app, like for example the QUIC parameters extension. Those are just as
sensitive as the ALPN.
-- Christian Huitema
signature.asc
Description: OpenPG
On 12/6/2019 12:42 AM, Alessandro Ghedini wrote:
> On Thu, Nov 28, 2019 at 05:01:37PM -0800, Christian Huitema via Datatracker
> wrote:
>> Reviewer: Christian Huitema
>> Review result: Has Issues
>>
>> I have reviewed draft-ietf-tls-certificate-compression
Reviewer: Christian Huitema
Review result: Has Issues
I have reviewed draft-ietf-tls-certificate-compression-07 as part of the
security directorate's ongoing effort to review all IETF documents being
processed by the IESG. These comments were written primarily for the benefit of
the security
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
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
__
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
_
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
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
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
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
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."
>
>> --
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
>>
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'
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
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
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
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:
://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
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
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
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,
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
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.
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
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
. 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
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
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
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
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
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.
+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
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 - 100 of 153 matches
Mail list logo
