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 5:23 PM, Eric Rescorla wrote:
>
>
> On Thu, Apr 23, 2020 at 4:58 PM Martin Thomson wrote:
> > What makes this case interesting is the non-machine time that might exist
> > between receiving CertificateRequest and sending Certificate.
> >
> > In most of the exchanges,
On Thu, Apr 23, 2020, at 8:10 AM, Hollenbeck, Scott wrote:
> > -Original Message-
> > From: TLS On Behalf Of Christopher Wood
> > Sent: Tuesday, April 21, 2020 9:57 PM
> > To: TLS@ietf.org
> > Subject: [EXTERNAL] Re: [TLS] Comments on draft-ietf-tls-external-psk-
> > importer-04
> >
> > Th
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.
Title : TLS Ticket Requests
Authors : Tommy Pauly
David Schinazi
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
On Fri, Apr 24, 2020 at 11:17 AM Hanno Becker wrote:
> Hi Chris and Ekr,
>
> > I'm not sure if it's straightforward, but I would note that in TLS 1.3,
> we did *implicitly* authenticate the length because AEAD provides that, but
> nevertheless one of Chris's recommendations was to include it in t
On Thu, Apr 23, 2020 at 4:31 PM Christopher Wood
wrote:
>
> Is this PR ready to go? If not, why not? What would you change, and why?
> (Concrete suggestions are highly encouraged!) Note also that this is
> currently only a recommended padding algorithm. Implementations are
> therefore free to do
Hi Chris and Ekr,
> I'm not sure if it's straightforward, but I would note that in TLS 1.3, we
> did *implicitly* authenticate the length because AEAD provides that, but
> nevertheless one of Chris's recommendations was to include it in the AAD.
I don't know if this recommendation still holds f
> 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
On Fri, Apr 24, 2020 at 9:20 AM Hanno Becker wrote:
> Hi Chris,
>
> Just a note on the comparison with TLS 1.3.
>
> > I'd like to point to some related work that could shed light on this
> question.
> > The decision for TLS 1.3 was to authenticate all data that is written to
> the wire,
>
> It do
Hi Chris,
Just a note on the comparison with TLS 1.3.
> I'd like to point to some related work that could shed light on this question.
> The decision for TLS 1.3 was to authenticate all data that is written to the
> wire,
It doesn't seem straightforward to extrapolate from that case since the
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
Hiya,
On 24/04/2020 00:37, Stephen Farrell wrote:
>
> Sorry - I have one more I wanted to raise as an issue. Will
> do that tomorrow and send a mail,
>
I've done that now. [1] We did have some list mails on this
earlier but it kinda tailed off rather than got resolved.
Cheers,
S.
[1] https:/
Hi Achim,
My point is that we made decisions based on the best of our knowledge (and
personal preferences) but I am wondering whether formal methods can tell us
whether there is a preferred way.
Ciao
Hannes
-Original Message-
From: Achim Kraus
Sent: Friday, April 24, 2020 3:07 PM
To:
Hi Martin,
> So this depends on either concurrent use of the two CIDs,
with that and the "routing based on cid", I would raise the question, if
the usage of the cid turns into a swiss-army-knife?
Therefore it may get larger, and so it gets attractive,
to use it only on the first record, but leav
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
Hi Hannes,
Let me see if I can clarify then :)
On Fri, Apr 24, 2020, at 18:31, Hannes Tschofenig wrote:
> > Say that a connection spans two network paths. CID A is used on path
> A; CID B is used on path B.
> I guess you are considering a scenario where a device, of the lifetime
> of the commu
The following errata report has been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6128
--
Type: Editorial
Re
The following errata report has been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6127
--
Type: Editorial
Re
The following errata report has been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6126
--
Type: Editorial
Re
The following errata report has been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6125
--
Type: Editorial
Re
The following errata report has been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6124
--
Type: Editorial
Re
The following errata report has been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6123
--
Type: Technical
Re
The following errata report has been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6122
--
Type: Editorial
Re
The following errata report has been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6121
--
Type: Editorial
Re
The following errata report has been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6120
--
Type: Editorial
Re
Hi Martin,
I have a few questions regarding the attack you mentioned below.
I would like to understand whether it relates to the topic of how the
additional data is constructed and what is included.
> Say that a connection spans two network paths. CID A is used on path A; CID
> B is used on pa
34 matches
Mail list logo
