Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07

2020-11-16 Thread 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;       |  appears on wire
> >    uint64 seq_num; // includes epoch    |
> >    opaque cid[cid_len];                 /
> >    uint16 iv_length;
> >    opaque IV[iv_length];
> >    uint16 enc_content_length;
> >    opaque enc_content[enc_content_length];
> > };
> >
> 
> I failed to understand the reasons behind this proposal.
> 
> 1. Why should the "marker" be added, if the "content_type" is already in
> the MAC, and this special MAC is only applied for tls12_cid records.
> What is the intended benefit of that?

This is another general hygiene item; we are preserving the invariant that
the first byte of the MAC input is the content type -- this is at present
(IIRC) invariant across all TLS versions and MtE/EtM, and not something to
change lightly.

It appears twice so that we keep the entire "bits on wire" together, and
there's not (IMO) much incentive to try to justify deduplicating the two
locations of tls12_cid, since the incremental cost of MACing another byte
is pretty small.

> 2. Why should a "uint16 iv_length" be added?
> 2.a If it should be added, why as "uint16" instead of "uint8"
> 2.b If it should be added, why in the middle? It's not on the wire and
> so I would assume, if at all, to have that at the begin.

(Peter answered the "why have it at all" question.)

I think you are right that putting it before the "appears on wire" bits
makes a bit more sense.

I think it was uint16 out of chance/laziness, as I split the combined
"length of (IV + DTLSCiphertext.enc_content)" and just used the same width
of length field for both IV and enc_content.  Making it uint8 is probably
an improvement.

Thanks for taking a careful look,

Ben

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PR#28: Converting cTLS to QUIC-style varints

2020-11-16 Thread Mohit Sethi M 
+1 for a deterministic (minimal) encoding.

--Mohit

On 11/15/20 10:13 PM, Eric Rescorla wrote:
Trying to close out this discussion, it seems to me like there are three major 
options:

1. The current scheme
2. The current scheme with a deterministic minimal encoding (e.g., the two byte 
version is offset by 127)
3. The QUIC scheme

I don't think that the QUIC scheme with deterministic encoding makes sense, 
because the virtue of the QUIC scheme is commonality with something already 
defined. I'm hearing that people are not as excited about moving to QUIC as I 
had expected and to the best of my knowledge, there is no valid reason to 
encode to > 2^32-1 in TLS. I also don't think using encoding (1) but mandating 
minimal length makes sense, as it's just as easy to do a deterministic minimal 
encoding.

As Christian observes it *is* significantly more painful to do (2): the 
conventional way to encode vectors in TLS with minimal copying is:

- Mark your current place --> X
- Skip forward the length of the length field --> L
- Encode the value
- Encode (current position - (X + L)) at X

But this won't be possible in (2). As MT observes, if you think of this as a 
two-pass system, there is not as much of a problem here [though not necessarily 
no problem]. Also, if you use a separate buffer, there is no problem. As noted 
above by MT and others, cTLS expands the transcript and so having a 
deterministic compression scheme is perhaps not as important, given that 
decompression is deterministic, but it still seems nice to have.

Given the above, I think my preference would be (1) or (2), with, I think, a 
slight preference for (2).

-Ekr









On Tue, Oct 6, 2020 at 5:33 PM Nick Harper 
mailto:nhar...@google.com>> wrote:
I have no strong opinion on how this is formatted. I'd base my decision on what 
the maximum value cTLS needs to encode: If 2^22-1 is sufficient, let's keep it 
as is, otherwise let's change it to the QUIC format (or some other change to 
increase the max value). I do like that the existing scheme, compared to QUIC 
varints, is more efficient for values 64-127 and just as efficient for the rest.

On Mon, Oct 5, 2020 at 8:09 PM Eric Rescorla 
mailto:e...@rtfm.com>> wrote:
I don't have a strong opinion on whether to require a minimal encoding, but if 
we're not going to use QUIC's encoding as-is, then I would rather stick with 
the existing scheme, which has twice as large a range for the 1 byte encoding 
and is thus more compact for a range of common cases.

-Ekr


On Mon, Oct 5, 2020 at 7:31 PM Marten Seemann 
mailto:martenseem...@gmail.com>> wrote:
In that case, why use QUIC's encoding at all? It would just put the burden on 
the receiver to check that the minimal encoding was used.
Would it instead make more sense to modify QUIC's encoding, such that the 
2-byte encoding doesn't encode the numbers from 0 to 16383, but the numbers 
from 64 to (16383 + 64), and equivalently for 4 and 8-byte encodings?

On Tue, Oct 6, 2020 at 9:22 AM Salz, Rich 
mailto:rs...@akamai.com>> wrote:
Can you just say “QUIC rules but use the minimum possible length”?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls



___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] TLS@IETF109: Chair Slides

2020-11-16 Thread Sean Turner 
I uploaded a new version the chair’s slides.

spt
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PR#28: Converting cTLS to QUIC-style varints

2020-11-16 Thread Eric Rescorla 
On Mon, Nov 16, 2020 at 7:09 AM Hannes Tschofenig 
wrote:

> FWIW the current scheme described in
> https://tools.ietf.org/html/draft-ietf-tls-ctls-01 only offers variable
> length encoded integers of one to three bytes. We need more than that.
>

I think that's easy to fix by  making the longest version 4 bytes. TBH I
had forgotten i used 3.


> I am in favor of the “deterministic” version, if deterministic means no
> overlaps in the encoded number ranges.
>

Yes. So for instance 0x8000 would be 128.


Hence, I am in favor of 2 but would leave the details of how we encode it
> open to work in the group. There are various possible designs and none of
> them is rocket science.
>

Yep. If it looks like we are getting consensus I will work up a proposal.

-Ekr


>
> Ciao
>
> Hannes
>
>
>
> *From:* TLS  *On Behalf Of * Eric Rescorla
> *Sent:* Sunday, November 15, 2020 9:13 PM
> *To:* Nick Harper 
> *Cc:*  
> *Subject:* Re: [TLS] PR#28: Converting cTLS to QUIC-style varints
>
>
>
> Trying to close out this discussion, it seems to me like there are three
> major options:
>
>
>
> 1. The current scheme
>
> 2. The current scheme with a deterministic minimal encoding (e.g., the two
> byte version is offset by 127)
>
> 3. The QUIC scheme
>
>
>
> I don't think that the QUIC scheme with deterministic encoding makes
> sense, because the virtue of the QUIC scheme is commonality with something
> already defined. I'm hearing that people are not as excited about moving to
> QUIC as I had expected and to the best of my knowledge, there is no valid
> reason to encode to > 2^32-1 in TLS. I also don't think using encoding (1)
> but mandating minimal length makes sense, as it's just as easy to do a
> deterministic minimal encoding.
>
>
>
> As Christian observes it *is* significantly more painful to do (2): the
> conventional way to encode vectors in TLS with minimal copying is:
>
>
>
> - Mark your current place --> X
>
> - Skip forward the length of the length field --> L
>
> - Encode the value
>
> - Encode (current position - (X + L)) at X
>
>
>
> But this won't be possible in (2). As MT observes, if you think of this as
> a two-pass system, there is not as much of a problem here [though not
> necessarily no problem]. Also, if you use a separate buffer, there is no
> problem. As noted above by MT and others, cTLS expands the transcript and
> so having a deterministic compression scheme is perhaps not as important,
> given that decompression is deterministic, but it still seems nice to have.
>
>
>
> Given the above, I think my preference would be (1) or (2), with, I think,
> a slight preference for (2).
>
>
>
> -Ekr
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Tue, Oct 6, 2020 at 5:33 PM Nick Harper  wrote:
>
> I have no strong opinion on how this is formatted. I'd base my decision on
> what the maximum value cTLS needs to encode: If 2^22-1 is sufficient, let's
> keep it as is, otherwise let's change it to the QUIC format (or some other
> change to increase the max value). I do like that the existing scheme,
> compared to QUIC varints, is more efficient for values 64-127 and just as
> efficient for the rest.
>
>
>
> On Mon, Oct 5, 2020 at 8:09 PM Eric Rescorla  wrote:
>
> I don't have a strong opinion on whether to require a minimal encoding,
> but if we're not going to use QUIC's encoding as-is, then I would rather
> stick with the existing scheme, which has twice as large a range for the 1
> byte encoding and is thus more compact for a range of common cases.
>
>
>
> -Ekr
>
>
>
>
>
> On Mon, Oct 5, 2020 at 7:31 PM Marten Seemann 
> wrote:
>
> In that case, why use QUIC's encoding at all? It would just put the burden
> on the receiver to check that the minimal encoding was used.
>
> Would it instead make more sense to modify QUIC's encoding, such that the
> 2-byte encoding doesn't encode the numbers from 0 to 16383, but the numbers
> from 64 to (16383 + 64), and equivalently for 4 and 8-byte encodings?
>
>
>
> On Tue, Oct 6, 2020 at 9:22 AM Salz, Rich  wrote:
>
> Can you just say “QUIC rules but use the minimum possible length”?
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PR#28: Converting cTLS to QUIC-style varints

2020-11-16 Thread Hannes Tschofenig 
FWIW the current scheme described in 
https://tools.ietf.org/html/draft-ietf-tls-ctls-01 only offers variable length 
encoded integers of one to three bytes. We need more than that.

I am in favor of the “deterministic” version, if deterministic means no 
overlaps in the encoded number ranges.

Hence, I am in favor of 2 but would leave the details of how we encode it open 
to work in the group. There are various possible designs and none of them is 
rocket science.

Ciao
Hannes

From: TLS  On Behalf Of Eric Rescorla
Sent: Sunday, November 15, 2020 9:13 PM
To: Nick Harper 
Cc:  
Subject: Re: [TLS] PR#28: Converting cTLS to QUIC-style varints

Trying to close out this discussion, it seems to me like there are three major 
options:

1. The current scheme
2. The current scheme with a deterministic minimal encoding (e.g., the two byte 
version is offset by 127)
3. The QUIC scheme

I don't think that the QUIC scheme with deterministic encoding makes sense, 
because the virtue of the QUIC scheme is commonality with something already 
defined. I'm hearing that people are not as excited about moving to QUIC as I 
had expected and to the best of my knowledge, there is no valid reason to 
encode to > 2^32-1 in TLS. I also don't think using encoding (1) but mandating 
minimal length makes sense, as it's just as easy to do a deterministic minimal 
encoding.

As Christian observes it *is* significantly more painful to do (2): the 
conventional way to encode vectors in TLS with minimal copying is:

- Mark your current place --> X
- Skip forward the length of the length field --> L
- Encode the value
- Encode (current position - (X + L)) at X

But this won't be possible in (2). As MT observes, if you think of this as a 
two-pass system, there is not as much of a problem here [though not necessarily 
no problem]. Also, if you use a separate buffer, there is no problem. As noted 
above by MT and others, cTLS expands the transcript and so having a 
deterministic compression scheme is perhaps not as important, given that 
decompression is deterministic, but it still seems nice to have.

Given the above, I think my preference would be (1) or (2), with, I think, a 
slight preference for (2).

-Ekr









On Tue, Oct 6, 2020 at 5:33 PM Nick Harper 
mailto:nhar...@google.com>> wrote:
I have no strong opinion on how this is formatted. I'd base my decision on what 
the maximum value cTLS needs to encode: If 2^22-1 is sufficient, let's keep it 
as is, otherwise let's change it to the QUIC format (or some other change to 
increase the max value). I do like that the existing scheme, compared to QUIC 
varints, is more efficient for values 64-127 and just as efficient for the rest.

On Mon, Oct 5, 2020 at 8:09 PM Eric Rescorla 
mailto:e...@rtfm.com>> wrote:
I don't have a strong opinion on whether to require a minimal encoding, but if 
we're not going to use QUIC's encoding as-is, then I would rather stick with 
the existing scheme, which has twice as large a range for the 1 byte encoding 
and is thus more compact for a range of common cases.

-Ekr


On Mon, Oct 5, 2020 at 7:31 PM Marten Seemann 
mailto:martenseem...@gmail.com>> wrote:
In that case, why use QUIC's encoding at all? It would just put the burden on 
the receiver to check that the minimal encoding was used.
Would it instead make more sense to modify QUIC's encoding, such that the 
2-byte encoding doesn't encode the numbers from 0 to 16383, but the numbers 
from 64 to (16383 + 64), and equivalently for 4 and 8-byte encodings?

On Tue, Oct 6, 2020 at 9:22 AM Salz, Rich 
mailto:rs...@akamai.com>> wrote:
Can you just say “QUIC rules but use the minimum possible length”?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls