Re: [TLS] WGLC: draft-ietf-tls-tls13-19

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

[TLS] review comments on draft-rescorla-tls-dtls13-01

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

[TLS] review comments on draft-rescorla-tls-subcerts-01

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

Re: [TLS] WGLC: draft-ietf-tls-tls13-19

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

Re: [TLS] draft-ietf-tls-tls13-19 section 1.2 cleanup

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,

Re: [TLS] 4.1.2 Client Hello ammendment

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

[TLS] 4.1.2 Client Hello ammendment

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

Re: [TLS] The alternative idea I had for token buckets.

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

Re: [TLS] The alternative idea I had for token buckets.

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

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.

Re: [TLS] The alternative idea I had for token buckets.

> -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

Re: [TLS] The alternative idea I had for token buckets.

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.

Re: [TLS] The alternative idea I had for token buckets.

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]

Re: [TLS] The alternative idea I had for token buckets.

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,

[TLS] draft-ietf-tls-tls13-19 section 1.2 cleanup

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

[TLS] The alternative idea I had for token buckets.

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

Re: [TLS] WG Call for adoption of draft-rescorla-tls-dtls13

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

Re: [TLS] draft-thomson-tls-record-limit-00

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

Re: [TLS] A few comments on draft-ietf-tls-dnssec-chain-extension-02.txt

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: > >

Re: [TLS] A few comments on draft-ietf-tls-dnssec-chain-extension-02.txt

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

[TLS] draft-thomson-tls-record-limit-00

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

Re: [TLS] WGLC: draft-ietf-tls-tls13-19

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.