I raised this before in PR #693
(https://www.ietf.org/mail-archive/web/tls/current/msg21600.html).
I'm not sure it makes sense to rename this to legacy while other parts of the
document still refer to it. But I'm definitely in favor of deprecating it.
From: TLS on behalf of Dave Garrett
Sent
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 w
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 Si
Hi,
Thank you Jim for the update. Here is the version resulting from the discussion
we had during the WG meeting yesterday. Please review the document and provide
your feed backs by April 4 so we can move the draft to the IESG.
Yours,
Daniel
-Original Message-
From: Curdle [mailto:
On Tuesday, March 28, 2017 02:23:33 am Kaduk, Ben wrote:
> Should Alert.level be Alert.legacy_level?
Yep. Trivial to fix, so quick PR filed for it.
Dave
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On Tuesday, March 28, 2017 11:31:56 am Short, Todd wrote:
> I didn’t bring this up in the meeting this morning, but I’d like to see
> section 1.2 “Major Differences from TLS 1.2” cleaned up. We don’t need to
> list the changes at each draft. Instead, only the major difference from RFC
> 5246, et
On Tuesday, March 28, 2017 01:37:29 pm Mark Dunn wrote:
> should the text that reads
> ClientHellos will contain at least two extensions,
> “supported_versions” and either “key_share” or “pre_shared_key”.
> be changed to
> ClientHellos will always contain extensions.
>
> Both "key_share
should the text that reads
ClientHellos will contain at least two extensions,
“supported_versions” and either “key_share” or “pre_shared_key”.
be changed to
ClientHellos will always contain extensions.
Both "key_share" and "pre_shared_key" require other extensions, so "at
least two ext
On 28 March 2017 at 10:57, Scott Fluhrer (sfluhrer) wrote:
> Sorry, I wasn't aware that unlinkability was a requirement...
Yeah, it's the only hard requirement. :)
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Sorry, I wasn't aware that unlinkability was a requirement...
> -Original Message-
> From: Martin Thomson [mailto:martin.thom...@gmail.com]
> Sent: Tuesday, March 28, 2017 11:51 AM
> To: Scott Fluhrer (sfluhrer)
> Cc:
> Subject: Re: [TLS] The alternative idea I had for token buckets.
>
>
On 28 March 2017 at 10:48, Scott Fluhrer (sfluhrer) wrote:
> The server recovers E_K(R) because the client sent it (along with i and the
> protected message). It recovers R because it also knows K.
So E_K(R) is sent directly? That would link packets.
__
> -Original Message-
> From: Martin Thomson [mailto:martin.thom...@gmail.com]
> Sent: Tuesday, March 28, 2017 11:46 AM
> To: Scott Fluhrer (sfluhrer)
> Cc:
> Subject: Re: [TLS] The alternative idea I had for token buckets.
>
> On 28 March 2017 at 10:41, Scott Fluhrer (sfluhrer)
> wrote:
On 28 March 2017 at 10:41, Scott Fluhrer (sfluhrer) wrote:
> E_K(R); that is, R is encrypted with the server's long term key.
>
> (I meant to specify that...)
OK, so how does the server recover E_K(R)? The point here is that it
doesn't know R.
___
TL
E_K(R); that is, R is encrypted with the server's long term key.
(I meant to specify that...)
> -Original Message-
> From: Martin Thomson [mailto:martin.thom...@gmail.com]
> Sent: Tuesday, March 28, 2017 11:37 AM
> To: Scott Fluhrer (sfluhrer)
> Cc:
> Subject: Re: [TLS] The alternative i
I'm sorry, but I don't understand this proposal. I'm losing you when
you say E(R) without specifying the key that you are using.
On 28 March 2017 at 10:21, Scott Fluhrer (sfluhrer) wrote:
> Here’s how it would work:
>
>
>
> - The server has a long term secret key K, which it never gives
Hi List:
I didn’t bring this up in the meeting this morning, but I’d like to see section
1.2 “Major Differences from TLS 1.2” cleaned up. We don’t need to list the
changes at each draft. Instead, only the major difference from RFC 5246, et
al., should be included. It’s difficult to wade through
Here's how it would work:
- The server has a long term secret key K, which it never gives out
- When the server wants to give a token to a client, it picks a random
value R, and securely gives the client the values R and E_K(R)
- When the client wants to use the toke
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
agenda again at IE
On Tue, Mar 28, 2017 at 06:35:24AM -0500, Martin Thomson wrote:
> I just submitted a version of the draft we've discussed a little on
> the list.
>
> I don't think we concluded the discussion about what to do about block
> cipher padding.
I don't have strong preferences on this, but I would incli
On Wed, Mar 22, 2017 at 4:50 PM, Viktor Dukhovni
wrote:
>
> > On Mar 22, 2017, at 10:56 AM, Melinda Shore <
> melinda.sh...@nomountain.net> wrote:
> >
> > The draft could definitely benefit from
> > additional review.
>
> I find it ironic that section 4 includes:
>
>The components of the auth
On Thu, Mar 23, 2017 at 12:28 AM, Viktor Dukhovni
wrote:
>
> > On Mar 22, 2017, at 10:56 AM, Melinda Shore <
> melinda.sh...@nomountain.net> wrote:
> >
> > The draft could definitely benefit from additional review.
>
> A more complete walk through:
>
> > 2. Introduction
> >
> >This draft des
I just submitted a version of the draft we've discussed a little on the list.
I don't think we concluded the discussion about what to do about block
cipher padding.
...
A new version of I-D, draft-thomson-tls-record-limit-00.txt
has been successfully submitted by Martin Thomson and posted to the
22 matches
Mail list logo