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
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:* Wednesda
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
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 number
encryption) is used as as the additional data value for t
25 matches
Mail list logo
