Hi,
On 2020-05-17 07:35 +0200, Hanno Becker wrote:
> So, we're here at the moment:
> (1) Only the CID issue really _needs_ fixing somehow.
> (2) Other header fields are currently authenticated through a mixture of
> AAD, nonce, and implicit properties of the AEAD,
> and proof complexity doesn't s
Hi,
On 2020-05-06 08:00 +0200, Hanno Becker wrote:
>> The latter, to me, suggests that authenticating the pseudo-header alone
>> may not be sufficient. It would at least allow on-path modifications to
>> the on-the-wire header, which I don't expect is intended.
>
> Can we go a bit into this? As
of security towards the (purely) pseudo-header
AAD?
Cheers,
Hanno
From: TLS on behalf of Eric Rescorla
Sent: Friday, May 15, 2020 9:04 PM
To: Felix Günther
Cc:
Subject: Re: [TLS] Choice of Additional Data Computation
On Tue, May 5, 2020 at 1
Hi,
On 2020-05-15 22:04 +0200, Eric Rescorla wrote:
> Actually, the full epoch is included in the overall sequence number and
> hence used to generate the nonce.
>
> https://tools.ietf.org/html/draft-ietf-tls-dtls13-37#section-4
>
> Does that help?
Sorry, I forgot about reading this difference
On Tue, May 5, 2020 at 10:55 AM Felix Günther
wrote:
> 4) I slightly disagree with "epochs determine the key" (true) as, what
> I understand is, an argument that "the full epoch is implicitly
> authenticated by using the right key", at least in its absoluteness. My
> *guess* would be that, due
Hi Felix,
Thanks for chiming in!
> First of all, let me make sure I correctly understand that
> * "on-the-wire header" is what's exemplified in Fig. 4 of the draft
> * "pseudo-header" would be a superset, esp. including full epoch, full
> sequence number, length, connection ID, ... -- what else
Hi,
Sorry for chiming in with delay (thanks @Chris for pinging me); I'm not
following the list very closely, feel free to additionally CC me in case.
First of all, let me make sure I correctly understand that
* "on-the-wire header" is what's exemplified in Fig. 4 of the draft
* "pseudo-header"
> > (*): Even if we optimize the CID away with cTLS the question about the
> > security implications will surface again.
> I think that cTLS is the answer to the size issue. But there, the rule tends
> to be that removing from the wire doesn't also remove from the canonical
> value that is pro
On Mon, Apr 27, 2020, at 17:06, Hannes Tschofenig wrote:
> (*): Even if we optimize the CID away with cTLS the question about the
> security implications will surface again.
I think that cTLS is the answer to the size issue. But there, the rule tends
to be that removing from the wire doesn't a
Hi Ekr,
* And I am proposing removing implicit CIDs
That would be a bit unfortunate. When we put multiple DTLS records in a single
UDP datagram then the CID in all but the first datagram is redundant*.
Ciao
Hannes
(*): Even if we optimize the CID away with cTLS the question about the secu
On Sat, Apr 25, 2020, at 01:56, chris - wrote:
> However, the formal
> models of [1,2] assume reliable transport (i.e., TCP): failure to
> deliver packets in order is deemed an attack. Therefore, the
> definitions would need to be changed in order to account for the case
> of DTLS. (I'm not sur
thoughts.
>
> Best,
> Hanno
> --
> *From:* chris -
> *Sent:* Saturday, April 25, 2020 6:58 PM
> *To:* Hanno Becker
> *Cc:* Eric Rescorla ; Hannes Tschofenig <
> hannes.tschofe...@arm.com>; tls@ietf.org
> *Subject:* Re: [TLS] Choic
some more people from the protocol verification community
will join in here and give their thoughts.
Best,
Hanno
From: chris -
Sent: Saturday, April 25, 2020 6:58 PM
To: Hanno Becker
Cc: Eric Rescorla ; Hannes Tschofenig
; tls@ietf.org
Subject: Re: [TLS] Choice of
> So far I fail to understand, on an intuitive level, why it easier to
> analyze the protocol when the AAD can take multiple forms potentially
> truncating or omitting the underlying data, but then I don't know the
> details and you're the expert here. If you have time though to explain a
> bit mor
On 24/04/2020, 22:35, "Eric Rescorla" wrote:
> On Fri, Apr 24, 2020 at 2:29 PM chris - wrote:
> > I would need to study the specs in order to provide an intelligent
> > answer here. Off the hip, it would seem to depend on how the
> > boundaries between record headers and ciphertexts are determine
Hi,
Thanks for your input Chris, this is very helpful.
Yes, this is the way I see it. I think you can get by with implicitly
authenticating things, but when you start doing this, the details of how to
decode the data on the wire begin to really matter for the proof (and
potentially for an atta
On Fri, Apr 24, 2020 at 2:29 PM chris - wrote:
> But I'd like to hear Chris weigh in on whether he thinks we should have
>> them explicitly in the AD (and whether that should be true in QUIC too).
>>
>
> I would need to study the specs in order to provide an intelligent answer
> here. Off the hip
>
> But I'd like to hear Chris weigh in on whether he thinks we should have
> them explicitly in the AD (and whether that should be true in QUIC too).
>
I would need to study the specs in order to provide an intelligent answer
here. Off the hip, it would seem to depend on how the boundaries betwee
On Fri, Apr 24, 2020 at 12:56 PM Thomas Fossati
wrote:
> On 24/04/2020, 19:53, "chris -" wrote:
> > [...] the details of how to decode the data on the wire begin to
> > really matter for the proof (and potentially for an attacker).
>
> I have zero experience with formal security proofs, so I nee
On 24/04/2020, 19:53, "chris -" wrote:
> [...] the details of how to decode the data on the wire begin to
> really matter for the proof (and potentially for an attacker).
I have zero experience with formal security proofs, so I need to trust
your assessment here, which looks like the crux of the
On Fri, Apr 24, 2020 at 11:51 AM chris - wrote:
>
> I don't think that's at all obvious. Again, the problem with the
>> pseudo-header is you are authenticating some abstract information, *not*
>> what is actually on the wire, and that allows the attacker to manipulate
>> what's on the wire undete
> I don't think that's at all obvious. Again, the problem with the
> pseudo-header is you are authenticating some abstract information, *not*
> what is actually on the wire, and that allows the attacker to manipulate
> what's on the wire undetected. We have no analysis for the impact of that.
>
Ye
; *Sent:* Friday, April 24, 2020 6:57 PM
> *To:* Eric Rescorla
> *Cc:* Hanno Becker ; Hannes Tschofenig <
> hannes.tschofe...@arm.com>; tls@ietf.org
> *Subject:* Re: [TLS] Choice of Additional Data Computation
>
>
> It doesn't seem straightforward to extrapolate from tha
___
From: chris -
Sent: Friday, April 24, 2020 6:57 PM
To: Eric Rescorla
Cc: Hanno Becker ; Hannes Tschofenig
; tls@ietf.org
Subject: Re: [TLS] Choice of Additional Data Computation
It doesn't seem straightforward to extrapolate from that case since the
'pseudo-hea
> It doesn't seem straightforward to extrapolate from that case since the
> 'pseudo-header'
> and on-the-wire header are the same here, as TLS 1.3 doesn't have any
> header
> data which is shortened or omitted on the wire. In DTLS 1.3, in contrast,
> various
> fields can be dropped or shortened, su
vertheless one of Chris's recommendations was to include it in the AAD.
-Ekr
> Best,
> Hanno
> --
> *From:* TLS on behalf of chris - <
> chrispat...@gmail.com>
> *Sent:* Friday, April 24, 2020 4:56 PM
> *To:* Hannes Tschofenig
> *Cc:* tls@ietf.org
sequence number, CID.
Best,
Hanno
From: TLS on behalf of chris -
Sent: Friday, April 24, 2020 4:56 PM
To: Hannes Tschofenig
Cc: tls@ietf.org
Subject: Re: [TLS] Choice of Additional Data Computation
Hi all,
> 1. Generic question: Should the construction of the additional data be
>
Hi all,
> 1. Generic question: Should the construction of the additional data be
> dependent on what is transmitted over the wire or should it be based
> on a "pseudo header"? DTLS 1.2 uses a pseudo header and DTLS 1.3 the
> data transmitted over the wire in the additional data calcu
: Hannes Tschofenig ; tls@ietf.org
Subject: Re: [TLS] Choice of Additional Data Computation
Hi Hannes,
Hi list,
as input for the discussion:
https://github.com/tlswg/dtls-conn-id/issues/25
A longer "comment-flow", the conclusion was, the CID is on the wire, so it's in
Hi Hannes,
Hi list,
as input for the discussion:
https://github.com/tlswg/dtls-conn-id/issues/25
A longer "comment-flow", the conclusion was, the CID is on the wire, so
it's in the MAC.
(ekr: "authenticating the whole header is just good practice.")
My arguments was, that the CID is always inc
Hi all,
the thread on the AEAD commutation in DTLS 1.3 and the construction of the
additional data raised two interesting questions. I believe those would benefit
from a formal analysis or at least a security investigation.
Here are the questions:
1. Generic question: Should the constructi
31 matches
Mail list logo
