On 26/04/2020, 15:49, "Christopher Wood" wrote:
> To clarify (as the request was about prohibiting implicit CIDs and not
> more generally about what's included in the AAD), you'd prefer we
> allow implicit CIDs, correct?
Hi Chris, correct.
IMPORTANT NOTICE: The contents of this email and any at
On Sun, Apr 26, 2020, at 2:37 AM, Thomas Fossati wrote:
> On 25/04/2020, 11:43, "Thomas Fossati" wrote:
> > On 25/04/2020, 11:11, "Thomas Fossati" wrote:
> > > On 25/04/2020, 01:30, "Christopher Wood"
> > > wrote:
> > > > On Thu, Apr 23, 2020, at 2:17 PM, Eric Rescorla wrote:
> > > > > 1. Allowi
On 25/04/2020, 11:43, "Thomas Fossati" wrote:
> On 25/04/2020, 11:11, "Thomas Fossati" wrote:
> > On 25/04/2020, 01:30, "Christopher Wood"
> > wrote:
> > > On Thu, Apr 23, 2020, at 2:17 PM, Eric Rescorla wrote:
> > > > 1. Allowing implicit CIDs is very recent (it was introduced in
> > > > -34)
>
On 25/04/2020, 11:11, "Thomas Fossati" wrote:
> On 25/04/2020, 01:30, "Christopher Wood" wrote:
> > On Thu, Apr 23, 2020, at 2:17 PM, Eric Rescorla wrote:
> > > 1. Allowing implicit CIDs is very recent (it was introduced in
> > > -34)
> > > 2. The CID specification explicitly prohibits it for DTL
On 25/04/2020, 01:30, "Christopher Wood" wrote:
> On Thu, Apr 23, 2020, at 2:17 PM, Eric Rescorla wrote:
> > 1. Allowing implicit CIDs is very recent (it was introduced in -34)
> > 2. The CID specification explicitly prohibits it for DTLS 1.2. 3. I
> > haven't really heard a very compelling argum
On Thu, Apr 23, 2020, at 2:17 PM, Eric Rescorla wrote:
> On Thu, Apr 23, 2020 at 12:40 AM Martin Thomson wrote:
> > On Thu, Apr 23, 2020, at 11:49, Eric Rescorla wrote:
> > > OK but we would expect the peer to process CID-less records if they are
> > > coalesced?
> >
> > I guess so. If we all
On Thu, Apr 23, 2020 at 12:40 AM Martin Thomson wrote:
> On Thu, Apr 23, 2020, at 11:49, Eric Rescorla wrote:
> > OK but we would expect the peer to process CID-less records if they are
> > coalesced?
>
> I guess so. If we allowed them to drop them, then we're close to saying
> MUST NOT omit.
>
Just one comment.
On 23/04/2020, 00:54, "Martin Thomson" wrote:
> But Hanno's proposal is a terrible thing to have to implement. You
> have to assume that there is some way to recover which CID to use in
> decrypting any record. You might save some datagram-local state, but
> that's awkward. S
On Thu, Apr 23, 2020, at 18:11, Hanno Becker wrote:
> You criticize that an implicit CID which is still included in the AAD
> requires state on the receiver when processing multiple records within
> a single datagram, which is true. I'm saying that the same holds for
> the PR 143 which adds the
Hi Martin,
On Thu, Apr 23, 2020, at 16:43, Hanno Becker wrote:
> > But Hanno's proposal is a terrible thing to have to implement. You
> have to assume that there is some way to recover which CID to use in
> decrypting any record. You might save some datagram-local state, but
> that's awkward. Sta
On Thu, Apr 23, 2020, at 11:49, Eric Rescorla wrote:
> OK but we would expect the peer to process CID-less records if they are
> coalesced?
I guess so. If we allowed them to drop them, then we're close to saying MUST
NOT omit.
On Thu, Apr 23, 2020, at 16:43, Hanno Becker wrote:
> > But Hanno'
n-the-wire AAD.
What are your reservations towards this?
Cheers,
Hanno
From: TLS on behalf of Eric Rescorla
Sent: Thursday, April 23, 2020 2:49 AM
To: Martin Thomson
Cc:
Subject: Re: [TLS] DTLS 1.3 AEAD additional data
OK but we would expect the peer to process CID-less records if they
OK but we would expect the peer to process CID-less records if they are
coalesced?
-Ekr
On Wed, Apr 22, 2020 at 6:39 PM Martin Thomson wrote:
>
>
> On Thu, Apr 23, 2020, at 11:24, Eric Rescorla wrote:
> > On Wed, Apr 22, 2020 at 4:54 PM Martin Thomson
> wrote:
> > > I prefer Ekr's solution, b
On Thu, Apr 23, 2020, at 11:24, Eric Rescorla wrote:
> On Wed, Apr 22, 2020 at 4:54 PM Martin Thomson wrote:
> > I prefer Ekr's solution, but I would go with that being a recommendation
> > (SHOULD) as opposed to a requirement (MUST).
>
> Can you clarify where you think we should say SHOULD?
security analysis of TLS
> > 1.3. This decoupling
> > doesn't hold for the current DTLS 1.3 draft, and we seem to agree that
> > in the case of CIDs,
> > it has already led to one missing cryptographic binding.
> >
> > Anyway, let's wait for more opinions
tls13-spec/pull/143
> > >>>
> > >>> This seems to be a mixture of logical and on-the-wire representation,
> > >>> which
> > >>> moreover duplicates the CID in case it is explicitly present in the
> > >>> header.
> > &
raft, and we seem to agree that
> in the case of CIDs,
> it has already led to one missing cryptographic binding.
>
> Anyway, let's wait for more opinions.
>
> Best,
> Hanno
>
> *From:* Eric Rescorla
> *Sent:* Wednesday, April 22, 2020 3:47 PM
> *To
has already led to one missing cryptographic binding.
Anyway, let's wait for more opinions.
Best,
Hanno
From: Eric Rescorla
Sent: Wednesday, April 22, 2020 3:47 PM
To: Hanno Becker
Cc: tls@ietf.org
Subject: Re: [TLS] DTLS 1.3 AEAD additional data
On Wed,
> to?
>
I don't recall making that argument.
-Ekr
> Best,
> Hanno
>
>
> Looking forward to hearing other WG member's views,
> Hanno
> ----------
> *From:* Eric Rescorla
> *Sent:* Wednesday, April 22, 2020 2:23 AM
> *To:* Hanno Becker
> *Cc:* tls@ietf.org
>
Cc: tls@ietf.org<mailto:tls@ietf.org> mailto:tls@ietf.org>>
Subject: Re: [TLS] DTLS 1.3 AEAD additional data
I think there are two potential resolutions to your CID issue:
1. Cryptographically protect it as in
https://github.com/tlswg/dtls13-spec/pull/143
2. Forbid implicit CIDs (my prefe
cover what is
actually on the wire. I would be strongly opposed to going back on that.
-Ekr
-Ekr
Looking forward to hearing other WG member's views,
> Hanno
> --
> *From:* Eric Rescorla
> *Sent:* Wednesday, April 22, 2020 2:23 AM
> *To:* Hanno Be
27;s views,
Hanno
From: Eric Rescorla
Sent: Wednesday, April 22, 2020 2:23 AM
To: Hanno Becker
Cc: tls@ietf.org
Subject: Re: [TLS] DTLS 1.3 AEAD additional data
I think there are two potential resolutions to your CID issue:
1. Cryptographically protect it as in
https://github
I think there are two potential resolutions to your CID issue:
1. Cryptographically protect it as in
https://github.com/tlswg/dtls13-spec/pull/143
2. Forbid implicit CIDs (my preference) see:
https://github.com/tlswg/dtls13-spec/issues/144
Would like to hear what others in the WG think.
-Ekr
O
On Tue, Apr 21, 2020 at 8:39 AM Hanno Becker wrote:
> Hi all,
>
> To my understanding, DTLS 1.3 defines AEAD additional data for record
> protection
> as the record header as seen on the wire. Quoting Draft 37, Section 4:
>
> ```
>The entire header value shown in Figure 4 (but prior to record
24 matches
Mail list logo
