The one concrete one that I remember (and can't attribute to the HTMLized
version dropping stuff) is RFC 7030 only in the header.
I guess we can check what we want to do to DTLS as well, as RFC 6347 is listed
as Updates:-ed but that's the DTLS 1.2 spec. (6347 itself confusingly claims
in the
A few things I noticed while reading the draft to prepare for today’s session:
We talk in a couple places about datagram protocols being “vulnerable” or
“susceptible” to DoS attacks, which leads me to at least partially read that as
meaning that the protocol’s own service will be disrupted; as
Getting these in email before my printout with red markings gets buried in a
pile.
We mentioned adding a NUL byte separator in the signature on the
DelegatedCredential (as well as some other potential tweaks to normalize the
context strings elsewhere and here).
Do we want to leave the valid
I support adopting this document and am willing to review it.
-Ben
On 3/22/17, 17:50, "Sean Turner" wrote:
All,
-00 of draft-rescorla-tls-dtls13 [0][1] was discussed at IETF 97 [2]. It’s
now at version -01 and GH issues are slowly rolling in. It’s also on our
On 3/13/17, 12:30, "Sean Turner" wrote:
This is a working group last call announcement for draft-ietf-tls-tls13-19,
to run through March 27. Please send your reviews to the list as soon as
possible so we can prepare for any discussion of open issues at IETF 98 in
Chicago.
the length represents, since it is not really helping
anything; the specification for the AEAD in use will specify the ciphertext
length.
On 11/14/16, 10:44, "Eric Rescorla" <e...@rtfm.com> wrote:
On Mon, Nov 14, 2016 at 8:54 AM, Kaduk, Ben
<bka...@akama
On 4/2/16, 14:53, "Karthik Bhargavan" wrote:
>
>Here is a proposal that would avoid trial decryption.
>When the client sends 0-RTT application data, it currently
>ends this flight of messages with an encrypted end_of_early data warning alert.
>How about: if the