Re: [OPSAWG] Fwd: New Version Notification for draft-ietf-opsawg-mud-21.txt

On Fri, May 18, 2018 at 11:56 AM, Eliot Lear <l...@cisco.com> wrote: > Hi EKR, > > > On 18.05.18 19:57, Eric Rescorla wrote: > > Eliot, > > The certificate part seems basically right (I think you > should require specific KeyUsage bits). > It's in there: &

Re: [OPSAWG] Fwd: New Version Notification for draft-ietf-opsawg-mud-21.txt

Eliot, The certificate part seems basically right (I think you should require specific KeyUsage bits). Maybe I missed it, but I didn't see anything about the level of trust you should have in cases where you can't reliably tie the endpoint's transmissions to its certificate. -Ekr On Fri, May

[OPSAWG] Eric Rescorla's No Objection on draft-ietf-opsawg-mud-24: (with COMMENT)

Eric Rescorla has entered the following ballot position for draft-ietf-opsawg-mud-24: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer

[OPSAWG] Eric Rescorla's Discuss on draft-mm-wg-effect-encrypt-17: (with DISCUSS and COMMENT)

Eric Rescorla has entered the following ballot position for draft-mm-wg-effect-encrypt-17: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer

Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-wg-effect-encrypt-17: (with DISCUSS and COMMENT)

Thanks for the updated draft. Some responses below. On Mon, Feb 19, 2018 at 12:11 PM, Kathleen Moriarty < kathleen.moriarty.i...@gmail.com> wrote: > > > > > DISCUSS > >session encryption that deployed more easily instead of no > >encryption. > > > > I think I understand what you are

Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-wg-effect-encrypt-17: (with DISCUSS and COMMENT)

lost the authors names here. On Wed, Mar 14, 2018 at 8:04 AM, Warren Kumari <war...@kumari.net> wrote: > > On Wed, Mar 14, 2018 at 10:12 AM Eric Rescorla <e...@rtfm.com> wrote: > >> Hi Warren, >> >> I am on travel today, but I expect to read this today or

Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-wg-effect-encrypt-17: (with DISCUSS and COMMENT)

n before > the IETF101 meeting unless I hear a clear signal that there is > something that you *cannot* live with. > > Thank you again for your Abstain and all of your comments on the document, > W > > On Mon, Mar 5, 2018 at 10:58 AM, Warren Kumari <war...@kumari.net> wrote: &

[OPSAWG] Eric Rescorla's Discuss on draft-ietf-opsawg-mud-20: (with DISCUSS and COMMENT)

Eric Rescorla has entered the following ballot position for draft-ietf-opsawg-mud-20: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https

[OPSAWG] Eric Rescorla's Discuss on draft-ietf-opsawg-mud-20: (with DISCUSS and COMMENT)

Eric Rescorla has entered the following ballot position for draft-ietf-opsawg-mud-20: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https

Re: [OPSAWG] Eric Rescorla's Discuss on draft-ietf-opsawg-mud-20: (with DISCUSS and COMMENT)

made by that manufacturer. So, I'm actually left wondering how that feature is intended to work. I regret not catching this earlier, but perhaps you could explain? Thanks, -Ekr On Sun, Apr 15, 2018 at 11:27 PM, Eliot Lear <l...@cisco.com> wrote: > Hi Eric, > > Trimming. > &g

Re: [OPSAWG] Eric Rescorla's Discuss on draft-ietf-opsawg-mud-20: (with DISCUSS and COMMENT)

On Sun, Apr 15, 2018 at 10:28 AM, Eliot Lear <l...@cisco.com> wrote: > Hi Eric, > > On 15.04.18 13:32, Eric Rescorla wrote: > > Eric Rescorla has entered the following ballot position for > draft-ietf-opsawg-mud-20: Discuss > > When responding, please keep the subjec

Re: [OPSAWG] Eric Rescorla's Discuss on draft-ietf-opsawg-mud-20: (with DISCUSS and COMMENT)

On Mon, Apr 16, 2018 at 6:55 AM, Eliot Lear <l...@cisco.com> wrote: > Hi Eric, > On 16.04.18 14:25, Eric Rescorla wrote: > > Hi Eliot, > > Thanks for continuing the conversation. My question is how this fits into > the system as a whole. > > ISTM that there are t

Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-wg-effect-encrypt-17: (with DISCUSS and COMMENT)

comments and have been responded to and addressed. > > I requested that the updated version be posted pending approval. > Responses inline. > > On Wed, Mar 14, 2018 at 8:36 PM, Eric Rescorla <e...@rtfm.com> wrote: > > I have reviewed the new version. Thanks for

Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-wg-effect-encrypt-17: (with DISCUSS and COMMENT)

On Tue, Feb 27, 2018 at 11:23 AM, Warren Kumari wrote: > On Mon, Feb 26, 2018 at 3:28 PM, Spencer Dawkins at IETF > wrote: > > Hi, Benoit, > > > > On Mon, Feb 26, 2018 at 2:15 PM, Benoit Claise > wrote: > >> > >> The way I

Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-wg-effect-encrypt-17: (with DISCUSS and COMMENT)

On Tue, Feb 27, 2018 at 11:23 AM, Warren Kumari wrote: > On Mon, Feb 26, 2018 at 3:28 PM, Spencer Dawkins at IETF > wrote: > > Hi, Benoit, > > > > On Mon, Feb 26, 2018 at 2:15 PM, Benoit Claise > wrote: > >> > >> The way I

Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-wg-effect-encrypt-17: (with DISCUSS and COMMENT)

Thank you. -Ekr On Wed, Feb 28, 2018 at 9:06 AM, Warren Kumari <war...@kumari.net> wrote: > On Wed, Feb 28, 2018 at 11:49 AM, Eric Rescorla <e...@rtfm.com> wrote: > > No worries. Looking forward to your thoughts on my comments. > > > > Me too! I've created a r

Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-wg-effect-encrypt-17: (with DISCUSS and COMMENT)

gt; Kathleen > > Sent from my mobile device > > On Feb 28, 2018, at 9:45 AM, Eric Rescorla <e...@rtfm.com> wrote: > > > > On Tue, Feb 27, 2018 at 11:23 AM, Warren Kumari <war...@kumari.net> wrote: > >> On Mon, Feb 26, 2018 at 3:28 PM, Spencer Dawkins

Re: [OPSAWG] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019

On Mon, Nov 4, 2019 at 5:44 PM Peter Gutmann wrote: > I actually think it's a pretty good summary, and delivers exactly what's > promised in the title. OTOH I can also see that it's going to get > bikeshedded > to death, and will probably never be editable into a form where people > won't >

Re: [OPSAWG] [TLS] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls

I tend to agree with Ben Schwartz on this. I have two concerns about this draft: 1. It seems likely that it will lead to ossification. While it is true that devices can in theory update their MUD descriptions, as a practical matter expecting middleboxes to enforce certain properties of the TLS

Re: [OPSAWG] [TLS] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls

On Wed, Sep 23, 2020 at 2:51 AM tirumal reddy wrote: > Hi Ben, > > Please see inline > > On Tue, 22 Sep 2020 at 20:45, Ben Schwartz wrote: > >> I'm not able to understand the new text in Section 6. Are you saying >> that clients MUST include all the listed extensions/features, but MAY also >>

Re: [OPSAWG] [TLS] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls

On Fri, Sep 18, 2020 at 3:12 PM Michael Richardson wrote: > > ekr> Taking a step back from details, ISTM that the whole design of this > ekr> document is antithetical to extensibility: > > I agree. It was my first reaction as well. > I then had another thought: there are dozens of entities out

Re: [OPSAWG] [TLS] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls

On Sat, Sep 19, 2020 at 3:07 PM Michael Richardson wrote: > > Eric Rescorla wrote: > ekr> As a thought example, consider a hypothetical TLS 1.4 which > decided to > ekr> adopt QUIC-style obfuscation of the CH and SH, putting the > obfuscated >

Re: [OPSAWG] [TLS] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls

Taking a step back from details, ISTM that the whole design of this document is antithetical to extensibility: TLS is a protocol with a number of extension points. What this document does is allow an endpoint to restrict its use of a certain set of extension points. However, the language provided