Hi,
I have a question regarding records in DTLS 1.2. RFC6347 says: "Multiple DTLS
records may be placed in a single datagram. They are simply encoded
consecutively".
However, what happens if one UDP datagram contains multiple records of type
application? Which way should an implementation ha
Generally, the spec doesn't prescribe API behavior, but #2 seems like the
right one because otherwise an attacker could coalesce/split such records.
-Ekr
On Sun, Dec 11, 2016 at 10:53 PM, Grehl Felix (ETAS-PSC/ECE1) <
felix.gr...@escrypt.com> wrote:
> Hi,
>
>
>
> I have a question regarding rec
https://github.com/tlswg/tls13-spec/pull/812
David Benjamin pointed out to me that end_of_early_data is the only place
where we transition keys on an alert and this would be cleaner if it was a
handshake message. This PR does that. It's encrypted under the same
keys, so this is largely an aestheti
On 12/12/2016 07:09 PM, Eric Rescorla wrote:
> It's encrypted under the same
> keys, so this is largely an aesthetic issue, but I think a good one.
Agreed on both counts.
-Ben
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On 13 December 2016 at 12:09, Eric Rescorla wrote:
> David Benjamin pointed out to me that end_of_early_data is the only place
> where we transition keys on an alert and this would be cleaner if it was a
> handshake message. This PR does that. It's encrypted under the same
> keys, so this is large
On Mon, Dec 12, 2016 at 5:23 PM, Martin Thomson
wrote:
> On 13 December 2016 at 12:09, Eric Rescorla wrote:
> > David Benjamin pointed out to me that end_of_early_data is the only place
> > where we transition keys on an alert and this would be cleaner if it was
> a
> > handshake message. This P
On Mon, Dec 12, 2016 at 5:32 PM, Eric Rescorla wrote:
>
>
> On Mon, Dec 12, 2016 at 5:23 PM, Martin Thomson
> wrote:
>
>> On 13 December 2016 at 12:09, Eric Rescorla wrote:
>> > David Benjamin pointed out to me that end_of_early_data is the only
>> place
>> > where we transition keys on an aler
On 13 December 2016 at 12:43, Nick Harper wrote:
> Right now, I believe it's legal for a client to send ClientHello, early
> data, and end_of_early_data alert without reading any messages from the
> server. This change would require a client to wait for the ServerHello
> before sending (or not) En
On Mon, Dec 12, 2016 at 5:45 PM, Martin Thomson
wrote:
> On 13 December 2016 at 12:43, Nick Harper wrote:
> > Right now, I believe it's legal for a client to send ClientHello, early
> > data, and end_of_early_data alert without reading any messages from the
> > server. This change would require
2016-12-13 10:45 GMT+09:00 Martin Thomson :
> On 13 December 2016 at 12:43, Nick Harper wrote:
>> Right now, I believe it's legal for a client to send ClientHello, early
>> data, and end_of_early_data alert without reading any messages from the
>> server. This change would require a client to wait
On Mon, Dec 12, 2016 at 8:45 PM Martin Thomson
wrote:
> On 13 December 2016 at 12:43, Nick Harper wrote:
> > Right now, I believe it's legal for a client to send ClientHello, early
> > data, and end_of_early_data alert without reading any messages from the
> > server. This change would require a
On Mon, Dec 12, 2016 at 5:54 PM, David Benjamin
wrote:
> On Mon, Dec 12, 2016 at 8:45 PM Martin Thomson
> wrote:
>
>> On 13 December 2016 at 12:43, Nick Harper wrote:
>> > Right now, I believe it's legal for a client to send ClientHello, early
>> > data, and end_of_early_data alert without read
12 matches
Mail list logo
