Subject: [manet] New IBS draft, request for WGLC

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 24 Jul 2014 09:05:53 +0000

A new version of the IBS draft should be posted by the time I've finished typing this.

Thanks to Benjamin Smith for verifying the signature - twice, as I had made a small error in M. (Doing it twice, that actually means each of us knows the other did it independently.)

I believe that completes the draft, as it's a small, specific, extension. I therefore request that the chairs issue a WGLC for this with an appropriate duration for comments etc.

--
Christopher Dearlove
Senior Principal Engineer, Information Assurance Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
[email-masked]<mailto:[email-masked]> | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Thomas Clausen <[email-masked]>
Date: Thu, 24 Jul 2014 07:53:55 -0400

Chris, all,

I have reviewed this latest version of the document, and I find it a useful and well-shaped mechanism. I've definite plans to implement it, as it a needed mechanism in many deployments that I care about.

I think that the document is ready to be WGLCed.

I have one minor comment: it "updates RFC 7182" - yet, all I can see it does to 7182 is make assignments from the registries defined therein, is this correct? I.e., it doesn't *modify* the mechanisms specified in 7182?

If so, i.e., if what it does is to make allocations from the 7182 registries, then I wonder if the mechanism is actually "Updates RFC 7182"?

Might be worth figuring out before it gets bounced around by the IESG, specifically the SEC-ADs?

But, by all means, let's have a WGLC started of this document, and prod Adrian for guidance on this point in parallel.

Best,

Thomas

Sent from my iPad

> On 24 Jul 2014, at 05:05, "Dearlove, Christopher (UK)" <[email-masked]> wrote:
> 
> A new version of the IBS draft should be posted by the time I’ve finished typing this.
>  
> Thanks to Benjamin Smith for verifying the signature – twice, as I had made a small error in M. (Doing it twice, that actually means each of us knows the other did it independently.)
>  
> I believe that completes the draft, as it’s a small, specific, extension. I therefore request that the chairs issue a WGLC for this with an appropriate duration for comments etc.
>  
> --
> Christopher Dearlove
> [email-masked] | http://www.baesystems.com
> 
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 24 Jul 2014 12:30:26 +0000

I have to admit to not understanding when updating and not updating. I know we’ve had IESG members disagreeing on that very point (for one of our documents) in the past, so I may not be alone. As for what’s been done with published RFCs, I certainly see things marked as updates that are not much different to this. But likely others not.

But in short, I don’t know, and will take guidance from anyone who does know. Adrian, any comment?

From: Thomas Clausen [mailto:[email-masked]]
Sent: 24 July 2014 12:54
To: Dearlove, Christopher (UK)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [manet] New IBS draft, request for WGLC

*** WARNING ***
This message originates from outside our organisation, either from an external partner or the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
For information regarding Red Flags that you can look out for in emails you receive, click here<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.
If you feel the email is suspicious, please follow this process<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.
Chris, all,

Best,

Thomas

Sent from my iPad

On 24 Jul 2014, at 05:05, "Dearlove, Christopher (UK)" <[email-masked]<mailto:[email-masked]>> wrote:
A new version of the IBS draft should be posted by the time I’ve finished typing this.

[email-masked]<mailto:[email-masked]>

---

From: Thomas Heide Clausen <[email-masked]>
Date: Thu, 24 Jul 2014 08:35:52 -0400

7181 does make allocations from registries created by 5444, but doesn't "Update rfc5444". That was my yardstick since both of those have flown by the iesg. 

-- 
Thomas Heide Clausen
http://www.thomasclausen.org

"Today's scientists have substituted mathematics for 
  experiments, and they wander off through equation 
  after equation, and eventually  build a structure 
  which has no relation to reality."
 - Nikola Tesla, 
    Modern Mechanics and Inventions, July, 1934

> On 24 juil. 2014, at 08:30, Dearlove, Christopher (UK) <[email-masked]> wrote:
> 
> For information regarding Red Flags that you can look out for in emails you receive, click here.
> If you feel the email is suspicious, please follow this process.
> 
> Chris, all,
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 24 Jul 2014 12:44:20 +0000

That’s not a bad example, but I think this is a little more tightly bound, in two or three ways.

First, 7182 says that if you have a crypto and a hash you do crypto(hash(data)) unless your crypto rules say otherwise. 7182 says otherwise for HMAC, this says otherwise for its two functions.

Second, this could be said to redefine the meaning of <key-id> in this case.

A possible third point is I’m not sure if 7182 implies that the way to check an ICV is to recalculate and compare. The concept of truncation depends on that. Here however we don’t verify in that way (it’s inherently impossible) but needs a separate verify process, and truncation is disallowed.

Being a little more tightly bound puts it back in maybe an update, maybe not territory. Personally I think as an update is more useful, but could go either way.

(If we wrote a draft to, say, add SHA-3 as a hash function code point, that would be a simple allocation and not an update, I agree.)

From: Thomas Heide Clausen [mailto:[email-masked]]
Sent: 24 July 2014 13:36
To: Dearlove, Christopher (UK)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [manet] New IBS draft, request for WGLC

*** WARNING ***

On 24 juil. 2014, at 08:30, Dearlove, Christopher (UK) <[email-masked]<mailto:[email-masked]>> wrote:
I have to admit to not understanding when updating and not updating. I know we’ve had IESG members disagreeing on that very point (for one of our documents) in the past, so I may not be alone. As for what’s been done with published RFCs, I certainly see things marked as updates that are not much different to this. But likely others not.

From: Thomas Clausen [mailto:[email-masked]]
Sent: 24 July 2014 12:54
To: Dearlove, Christopher (UK)
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [manet] New IBS draft, request for WGLC

*** WARNING ***

Best,

Thomas

Sent from my iPad

---

From: Thomas Clausen <[email-masked]>
Date: Thu, 24 Jul 2014 10:18:51 -0400

Chris,

> On 24 Jul 2014, at 08:44, "Dearlove, Christopher (UK)" <[email-masked]> wrote:
> 

To me, that actually is *exactly* what 7182 says should happen: "...unless your crypto rules say otherwise" is what allows this document to do what it does without "Updates".

Although, you *could* make this specific point in this document, like we do in 7183 ("As allowed by .... we do ...")?

> (If we wrote a draft to, say, add SHA-3 as a hash function code point, that would be a simple allocation and not an update, I agree.)

To me, what you have said in the above - specifically pointed out how this is already permitted behavior by 7182 -  makes me lean even more to not needing the "Updates" moniker here.

To summarize, my opinion is:

	o	Get a WGLC started sooner, rather than later

	o	Toss in the explanation with the "As allowed by  ..." reference, since
		I think that that'd be valuable for those not having committed this RFC series to
		memory. This can be taken among any other WGLC comments received, it is 
		just for educational purposes.

	o	Remove "Updates 7182"
		(Unless Adrian throws a temper-tantrum if we do)

	o	Ship it to the IESG and the RFC Editor.

Best,

Thomas

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 24 Jul 2014 14:22:31 +0000

Agreed, let’s start the WGLC as soon as possible. Then (and I realise this week may not be the best time) let’s get Adrian to answer the updates or nor question.

From: Thomas Clausen [mailto:[email-masked]]
Sent: 24 July 2014 15:19
To: Dearlove, Christopher (UK)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [manet] New IBS draft, request for WGLC

*** WARNING ***

On 24 Jul 2014, at 08:44, "Dearlove, Christopher (UK)" <[email-masked]<mailto:[email-masked]>> wrote:
That’s not a bad example, but I think this is a little more tightly bound, in two or three ways.

            o          Remove "Updates 7182"

Best,

Thomas

*** WARNING ***

*** WARNING ***

Best,

Thomas

Sent from my iPad

---

From: Thomas Clausen <[email-masked]>
Date: Thu, 24 Jul 2014 10:33:17 -0400

> On 24 Jul 2014, at 10:22, "Dearlove, Christopher (UK)" <[email-masked]> wrote:
> 

Yes, I hear that he's vacationing somewhere in Canada this week, with 1500 of his best buddies ;)

Thomas