On Tue, Oct 8, 2019, at 11:51 AM, Christian Huitema wrote:
>
> On 10/8/2019 9:46 AM, Christopher Wood wrote:
>
> > On Tue, Oct 8, 2019, at 2:55 AM, Mohit Sethi M wrote:
> >>
> Hi Chris,
>
> For the benefit of the list, let me summarize that the selfie attack is
> only relevant where
Hi Christian,
It was my poor attempt at explaining the attack. The attack can happen as long
as a node sends outbound connections (as a TLS client) and accepts inbound
connections (as a TLS server) with the same external PSK and identity. This is
likely to happen in some form of group
On 10/8/2019 9:46 AM, Christopher Wood wrote:
> On Tue, Oct 8, 2019, at 2:55 AM, Mohit Sethi M wrote:
>>
>> Hi Chris,
>>
>> For the benefit of the list, let me summarize that the selfie attack is
>> only relevant where multiple parties share the same PSK and use the
>> same PSK for outgoing
* One issue not covered in this document is SNI encryption from CDNs to
Origin servers.
I think deliberately so. User-agent to origin (where sometimes the origin is a
CDN or other intermediary) is the main case.
Akamai, for example, is not planning on doing ESNI to customer so far.
On Tue, Oct 8, 2019, at 2:55 AM, Mohit Sethi M wrote:
>
> Hi Chris,
>
> For the benefit of the list, let me summarize that the selfie attack is
> only relevant where multiple parties share the same PSK and use the
> same PSK for outgoing and incoming connections. These situations are
>
On Tuesday, 8 October 2019 16:04:18 CEST Daniel Migault wrote:
> If we suppose all tickets are sent by the server at once, I am wondering if
> we have any case where the server will send more tickets that the number
> provided by the hint.
long lasting connection and a ticket encryption key
If we suppose all tickets are sent by the server at once, I am wondering if
we have any case where the server will send more tickets that the number
provided by the hint.
Yours,
Daniel
On Mon, Oct 7, 2019 at 10:46 AM Hubert Kario wrote:
> On Saturday, 5 October 2019 14:08:45 CEST Christopher
> Issues and Requirements for SNI Encryption in TLS
One issue not covered in this document is SNI encryption from CDNs to
Origin servers.
For example, if I use ESNI to make a request to Cloudflare, how does
Cloudflare then encrypt the SNI to the origin server?
It seems like this use case could
On Tue, Oct 8, 2019 at 7:05 PM Benjamin Kaduk wrote:
> it's largely up to the sponsoring AD.
>
Is that true? I'm not sure which procedure you're describing.
At any rate, I think one issue is with the abstract
of draft-ietf-tls-oldversions-deprecate:
"This document also deprecates Datagram TLS
Hi,
For clarity to the WG I am summarizing the discussion of the "lesson learnt
from deprecation" thread.
There is in my opinion a consensus that the current text does not emphasize
enough that TLS 1.3 is the current version of TLS. There is also a
consensus that the current draft limits the
Hi John,
On 10/8/19 1:14 PM, John Mattsson wrote:
Hi Mohit, that are good points.
> The reality however is that in most group PSK scenarios, the nodes don't have
> any strong identities that can be verified.
I assume blocking all identities that are not the nodes own identity would
mitigate
On Mon, Oct 07, 2019 at 09:12:44PM +0100, Stephen Farrell wrote:
>
> Hiya,
>
> On 07/10/2019 18:29, Rob Sayre wrote:
> > On Tue, Oct 1, 2019 at 7:34 PM Stephen Farrell
> > wrote:
> >> we can't "UPDATE" an I-D.
> >
> > Not true. If you need to refer to something that's been IESG-approved but
> >
On 08/10/2019 11:28, John Mattsson wrote:
> I do not think the TLS WG should ask the WebRTC working group for
> permission, the BCP updates a huge number of RFCs from a lot of
> different groups. These groups were not asked.
IETF last call and IESG evaluation is when each of those
will ll turn
The way I see it, the upcoming BCP applies to WebRTC irrespectively of whether
it formally updates the document or not. The formal updates are important so
people easily find the BCP, but not critical. Companies can anyway choose to
implement WebRTC without implementing the BCP.
I do not think
Hi Mohit, that are good points.
> The reality however is that in most group PSK scenarios, the nodes don't have
> any strong identities that can be verified.
I assume blocking all identities that are not the nodes own identity would
mitigate the attacks, but lead to availability problems as two
Hi Chris,
For the benefit of the list, let me summarize that the selfie attack is only
relevant where multiple parties share the same PSK and use the same PSK for
outgoing and incoming connections. These situations are rather rare, but I
accept that TLS is widely used (and sometimes misused)
16 matches
Mail list logo
