Argh, Good catch. I'll revise the proposal in light of this point.
-Ekr
On Tue, Nov 17, 2020 at 1:09 AM Achim Kraus wrote:
> Hi Ben,
>
> Am 17.11.20 um 07:07 schrieb Benjamin Kaduk:
> > On Fri, Oct 30, 2020 at 01:28:12PM +0100, Achim Kraus wrote:
> >> Hi Ekr,
> >>
> >>> As for EtM
> >>>
> >>>
On Tue, Nov 17, 2020 at 10:09:34AM +0100, Achim Kraus wrote:
> Hi Ben,
>
> Am 17.11.20 um 07:07 schrieb Benjamin Kaduk:
> > On Fri, Oct 30, 2020 at 01:28:12PM +0100, Achim Kraus wrote:
> >> Hi Ekr,
> >>
> >>> As for EtM
> >>>
> >>> Encrypt-then-MAC:
> >>> struct {
> >>> uint8 marker =
Hi Ben,
Am 17.11.20 um 07:07 schrieb Benjamin Kaduk:
On Fri, Oct 30, 2020 at 01:28:12PM +0100, Achim Kraus wrote:
Hi Ekr,
As for EtM
Encrypt-then-MAC:
struct {
uint8 marker = tls12_cid;
uint8 cid_len;
uint8 content_type = tls12_cid; \
uint16 DTLSCiphertext.version;
On Fri, Oct 30, 2020 at 01:28:12PM +0100, Achim Kraus wrote:
> Hi Ekr,
>
> > As for EtM
> >
> > Encrypt-then-MAC:
> > struct {
> > uint8 marker = tls12_cid;
> > uint8 cid_len;
> > uint8 content_type = tls12_cid; \
> > uint16 DTLSCiphertext.version; | appears on wire
> >
Hi Peter,
thanks!
> It precedes the IV, i.e. the field that it describes.
In other contributions, it's said, that it is also important to keep the
header bytes as they are. With that, the "iv_length" should be ahead
before the header bytes starts.
And I'm still curious about the "uint16"
Achim Kraus writes:
>2. Why should a "uint16 iv_length" be added?
To make it explicit which of the bits being hashed is the IV. This is one of
the flaws of things like OAEP, there are a large number of implicitly-sized
fields controlled by external, unauthenticated parameters, so you can make
Hi Ekr,
As for EtM
Encrypt-then-MAC:
struct {
uint8 marker = tls12_cid;
uint8 cid_len;
uint8 content_type = tls12_cid; \
uint16 DTLSCiphertext.version; | appears on wire
uint64 seq_num; // includes epoch |
opaque cid[cid_len]; /
uint16
On Mon, Oct 26, 2020 at 06:07:07PM -0700, Eric Rescorla wrote:
> On Mon, Oct 26, 2020 at 6:00 PM Benjamin Kaduk wrote:
>
> > On Mon, Oct 26, 2020 at 05:38:33PM -0700, Eric Rescorla wrote:
> > > On Fri, Oct 23, 2020 at 7:13 PM Benjamin Kaduk wrote:
> > >
> > > > Hi Ekr,
> > > >
> > > > Thanks
On Mon, Oct 26, 2020 at 6:00 PM Benjamin Kaduk wrote:
> On Mon, Oct 26, 2020 at 05:38:33PM -0700, Eric Rescorla wrote:
> > On Fri, Oct 23, 2020 at 7:13 PM Benjamin Kaduk wrote:
> >
> > > Hi Ekr,
> > >
> > > Thanks for chiming in.
> > >
> > > On Thu, Oct 15, 2020 at 08:59:43AM -0700, Eric
On Mon, Oct 26, 2020 at 05:38:33PM -0700, Eric Rescorla wrote:
> On Fri, Oct 23, 2020 at 7:13 PM Benjamin Kaduk wrote:
>
> > Hi Ekr,
> >
> > Thanks for chiming in.
> >
> > On Thu, Oct 15, 2020 at 08:59:43AM -0700, Eric Rescorla wrote:
> > >
> > > - I agree with Ben that the current construction
On Fri, Oct 23, 2020 at 7:13 PM Benjamin Kaduk wrote:
> Hi Ekr,
>
> Thanks for chiming in.
>
> On Thu, Oct 15, 2020 at 08:59:43AM -0700, Eric Rescorla wrote:
> >
> > - I agree with Ben that the current construction has some awkward
> > properties and that prefixing the length field would remedy
Hi Ben,
at least at your point (from the e-mail before)
> and not have to change it again.
I agree :-).
That will naturally become true, if the RFC gets released.
best regards
Achim
Am 26.10.20 um 17:56 schrieb Benjamin Kaduk:
Hi Achim,
On Sat, Oct 24, 2020 at 08:56:08AM +0200, Achim
Hi Achim,
On Sat, Oct 24, 2020 at 08:56:08AM +0200, Achim Kraus wrote:
> Hi Ben,
>
> >> Because each party sends the value in the "connection_id" extension
> >> it wants to receive as a CID in encrypted records, it is possible for
> >> an endpoint to use a globally constant length
Hi Ben,
Because each party sends the value in the "connection_id" extension
it wants to receive as a CID in encrypted records, it is possible for
an endpoint to use a globally constant length for such connection
identifiers. This can in turn ease parsing and connection lookup,
Hi Ekr,
Thanks for chiming in.
On Thu, Oct 15, 2020 at 08:59:43AM -0700, Eric Rescorla wrote:
> I would like to make several points here:
>
> - In terms of operational practice, in order for a server to
> function correctly, the CID must either be fixed-length for all
> clients that might need
I would like to make several points here:
- In terms of operational practice, in order for a server to
function correctly, the CID must either be fixed-length for all
clients that might need to be demuxed *or*
self-describing. Otherwise, the server will not be able to determine
the correct CID. I
Hi Ben,
The attack does not require that both are valid for the same peer at the
same time -- the attack can still occur when the party producing the MAC is
induced to use the "wrong" (invalid CID) interpretation of the byte stream
but then the version with valid CID is presented to the party
On Tue, Oct 13, 2020 at 06:41:50AM +0200, Achim Kraus wrote:
> Hi Ben,
>
> >
> >> Just as forecast:
> >> Without agreement, that the CIDs must be encoded using deterministic
> >> interpretation, which in my opinion obsoletes these "number games",
> >> next Summer either Raccoon or Kenny will
On Tue, Oct 13, 2020 at 06:50:52AM +0200, Achim Kraus wrote:
> Hi Ben,
>
> > Sure, there's pretty standard common-knowledge guidance, though I'm not
> > sure it's documented anyplace particularly discoverable:
> >
> > - include in the MAC as much application/protocol context and protocol
> >
Hi Ben,
Sure, there's pretty standard common-knowledge guidance, though I'm not
sure it's documented anyplace particularly discoverable:
- include in the MAC as much application/protocol context and protocol
fields as you can without breaking operation of the procotol
- ensure that the
Hi Ben,
Just as forecast:
Without agreement, that the CIDs must be encoded using deterministic
interpretation, which in my opinion obsoletes these "number games",
next Summer either Raccoon or Kenny will write up their next
"time side channel attack" on this.
(The ambiguity will end up in try
On Sat, Oct 10, 2020 at 09:13:51AM +0200, Achim Kraus wrote:
> Hi Ben,
>
> >
> > To be frank, I'm actually surprised that this is even seen as a matter for
> > discussion.
>
> As developer, I'm surprised, that this discussion now spans a couple of
> years, starting on summer 2018 with:
>
>
Hi Achim,
On Sun, Oct 11, 2020 at 07:43:14PM +0200, Achim Kraus wrote:
> Hi Watson,
>
> > The doubt is because of where it appears not that it appears. If every
> > value was preceded by its length the encoding would obviously be
> > injective.
>
> I hope, this is just a "typo" or "mistake".
>
Hi Mike,
On Sat, Oct 10, 2020 at 01:29:13PM -0400, Michael D'Errico wrote:
> On Fri, Oct 9, 2020, at 17:22, Benjamin Kaduk wrote:
> > [...] The behavior we should demand from our cryptographic
> > constructions is that the cryptography itself correctly returns
> > "valid" or "invalid" based on
Ladd
Sent: dimanche 11 octobre 2020 08:50
To: Achim Kraus
Cc: draft-ietf-tls-dtls-connection...@ietf.org; tls@ietf.org; Benjamin Kaduk
Subject: Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07
On Sat, Oct 10, 2020 at 11:27 PM Achim Kraus wrote:
Hi Joe,
> [Joe] It'
The argument for the security is based on the parser synthetizer combinator, which
takes a parser p for type t1 and an injective function f:t1->t2 and returns a
parser p' for the type p2.
TLS, I don't even know you anymore
Mike
___
TLS
enjamin Kaduk
Subject: Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07
On Sat, Oct 10, 2020 at 11:27 PM Achim Kraus wrote:
>
> Hi Joe,
>
> > [Joe] It's unfortunate to find issues that require breaking change
> at > the end of the review cycle, esp
review of draft-ietf-tls-dtls-connection-id-07
On Sat, Oct 10, 2020 at 11:27 PM Achim Kraus wrote:
>
> Hi Joe,
>
> > [Joe] It's unfortunate to find issues that require breaking change
> at > the end of the review cycle, especially for a draft that has taken a
>
Hi Wadson,
my bad, I mislead in understanding "injective".
It's not related to "injection".
best regards
Achim Kraus
Hi Wadson,
The doubt is because of where it appears not that it appears. If every
value was preceded by its length the encoding would obviously be
injective.
I hope, this
Hi,
I do not understand how a CID is supposed to be parsed by a recipient
when the length can change and the length field is not encoded, but
perhaps I'm misreading the intent of the [] notation in the record
layer of the draft.
I created an issue on github to discus the requirements for
Hi Ilari,
The problem is the follows:
Take the following input to the MAC (MtE case):
19 FE FD 63 01 00 05 04 00 02 FF 17
There is no way to tell from that input if it is:
- Application record on CID 63 containing 04 00 02 FF, or
- Application record on CID 63 01 00 05 containing FF.
Hi Wadson,
The doubt is because of where it appears not that it appears. If every
value was preceded by its length the encoding would obviously be
injective.
I hope, this is just a "typo" or "mistake".
Prepending the length is the change, Ben want to use to protect against
injection. You now
On Sun, Oct 11, 2020 at 08:26:47AM +0200, Achim Kraus wrote:
> Hi Joe,
>
> > [Joe] It's unfortunate to find issues that require breaking change at
> > the end of the review cycle, especially for a draft that has taken a
> > long path to get here. If there is an issue that is exploitable, even
On Sat, Oct 10, 2020 at 11:27 PM Achim Kraus wrote:
>
> Hi Joe,
>
> > [Joe] It's unfortunate to find issues that require breaking change at
> > the end of the review cycle, especially for a draft that has taken a
> > long path to get here. If there is an issue that is exploitable, even
> >
Hi Joe,
> [Joe] It's unfortunate to find issues that require breaking change at
> the end of the review cycle, especially for a draft that has taken a
> long path to get here. If there is an issue that is exploitable, even
> in a corner case, someone will develop an attack, clever name, logo
On Sat, Oct 10, 2020 at 12:14 AM Achim Kraus wrote:
> Hi Ben,
>
> >
> > To be frank, I'm actually surprised that this is even seen as a matter
> for
> > discussion.
>
> As developer, I'm surprised, that this discussion now spans a couple of
> years, starting on summer 2018 with:
>
>
Hi Mike,
> in C:
>
> if (complex_value_a = complex_value_b) {
> // we're in trouble
> }
That's a pitfall of C ('=' is not '=='). You will be almost in trouble,
if the complex value is not 0.
But the discussion here is more about how often somethings should be
adapted
On Fri, Oct 9, 2020, at 17:22, Benjamin Kaduk wrote:
> [...] The behavior we should demand from our cryptographic
> constructions is that the cryptography itself correctly returns
> "valid" or "invalid" based on the input message, provided that
> the application inputs the correct key material.
Hi Ben,
To be frank, I'm actually surprised that this is even seen as a matter for
discussion.
As developer, I'm surprised, that this discussion now spans a couple of
years, starting on summer 2018 with:
https://github.com/tlswg/dtls-conn-id/issues/8
There are many (proposed) changes since
Hi Achim,
On Fri, Oct 09, 2020 at 07:56:00AM +0200, Achim Kraus wrote:
> Hi Ben,
>
> >> If that is going to be changed, the early adopters run into trouble with
> >> their deployments!
> >
> > I'm not sure I follow. Are you saying that if there is a theoretical
> > problem with the
Hi Ben,
>> If that is going to be changed, the early adopters run into trouble with
>> their deployments!
>
> I'm not sure I follow. Are you saying that if there is a theoretical
> problem with the construction it would have been exposed by
implementation
> testing?
No, I don't say that.
Hi Achim,
Sorry for the long silence on this front; my attention had cycled elsewhere
and I was just overall operating slowly for a couple weeks (sick, maybe,
but no clear symptoms).
My primary concern is not actually about a specific situation where
injection occurs, but rather for
Hi Ben,
any progress on the cid-length / calculate MAC topic?
As I wrote, though the cid-length itself is not "on the wire" (it's only
the cid), I can't see, that the cid-length could be injected.
Do I oversee soemthing?
best regrads
Achim Kraus
Weitergeleitete Nachricht
43 matches
Mail list logo
