Hi Donald, On 06/07/16 18:58, Donald Eastlake wrote: > Hi Stephen, > > Thanks for your comments. See below. > > On Wed, Jul 6, 2016 at 11:37 AM, Stephen Farrell > <[email protected]>\ wrote: >> Stephen Farrell has entered the following ballot position for >> draft-ietf-trill-channel-tunnel-10: No Objection >> >> ... >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> - The write up for this and the other trill docs on this >> telechat talks about "directory services" but that's not >> mentioned in any of the drafts. Pointers to RFC7067 would >> probably have saved me a few minutes:-) > > Yes, the main directory services draft is > draft-ietf-trill-directory-assist-mechanisms which is a fairly large > draft and, in my estimation, almost but not quite ready for IETF LC. > However, the security facility in the trill-channel-tunnel draft is > pretty general and is referenced (usually Informatively) by RFC 7783, > draft-ietf-trill-p2mp-bfd, draft-ietf-trill-address-flush, and > draft-ietf-trill-rfc6439bis as well as by the > trill-directory-assist-mechanisms draft. > > How about adding a sentence at the end of the Introduction, something > like: > > It is anticipated that these facilities will be used in support of > TRILL Pull Directory messages ([RFC7067], [DirectoryMechanisms]) > and to secure a variety of RBridge Channel messages including those > describedmin [AddressFlush], [p2mpBFD], and [rfc6439bis].
That'd be fine, but isn't needed if the intended reader (!= me;-) would know it already. > >> - That RFC5869 is not in the downref registry is odd. I'd >> say we should just add it there. It's true though that I >> think this seems to be the first stds track doc with it as >> normative [1] but I figure it's safe to add with no new LC >> stuff. >> >> [1] http://www.arkko.com/tools/allstats/citations-rfc5869.html >> >> (Apologies that there's no TLS for [1] :-) > > Thanks. > >> - 4.3: Can the verifier deterministically tell from the >> context that the keyid here refers to the derived key as >> defined in 4.1 and not to (what I guess is) a "bare" key as >> per RFC5310? Do you need to say that? > > The document should probably say that for Extended RBridge Channel use > it always refers to a derived key. Tend to agree. > >> - 4.4 or section 7: Do we know that there are no issues with >> DTLS packets exceeding the MTU but where implementations >> won't work, perhaps with a cert chain. DTLS does support >> that, but do implementations that are likely to be used >> here? If not, maybe a warning is needed. Or, do you need to >> warn against cert based ciphersuites on the basis that >> nobody knows what to put in certs for trill? Given that you >> are (wisely) punting on group communication, maybe you could >> also say that only PSK ciphersuites are to be used here for >> now, and then also address cert based ciphersuites when you >> get around to figuring out group keying? > > I don't know if there will be issues. I feel uncomfortable requiring > that only pre-shared key be used -- that seems very limiting. Fair point. > It is > true that certificates for this use in TRILL are likely to be part of > some proprietary/enterprise hierarchy within a data center or the > like... It seems reasonable to state explicitly that specification of > appropriate Certificate contents is out of scope for this document and > perhaps also say that it is anticipated that it will be covered in a > future document. If you don't de-scope cert based schemes here then I think that does create a need for some guidance about certs. That might be something also needed for DTLS uses in IoT though, so good to check with those folks (e.g. Hannes or Carsten) before/as doing that. (And we may need an OtherName for a MAC address if there's not already one, which I forget;-) So yeah for now saying something like you suggest seems good. > >> - section 7, 3rd para: I do worry a bit about that, but >> you've called out the risk I guess. If it were possible to >> add more guidance as to how to defend in depth that'd be >> good I guess. > > Well, other than making the wording a bit stronger, I'm not sure there > is much to do. Yep. Cheers, S. > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > [email protected] >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ trill mailing list [email protected] https://www.ietf.org/mailman/listinfo/trill
