Re: [tcpm] Comments on TCP-AO Draft

inline...

At 12:06 PM 11/17/2008, Eddy, Wesley M. (GRC-RCN0)[VZ] wrote:
> >-----Original Message-----
> >From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On
> >Behalf Of LANGE Andrew
> >Sent: Monday, November 17, 2008 1:51 PM
> >To: tcpm@ietf.org
> >Subject: [tcpm] Comments on TCP-AO Draft
> >
> >
>
>
>There are a lot of good comments here that will strengthen
>the document.  One of them that concerns the wire-format rather
>than text additions, clarifications, and changes that are
>needed, which we should address quickly is:
>
>
> >1.4.1: " IETF-72 topic" sections "No current consensus was
> >reached on this topic, so no change was made."  This is a real
> >problem -- the logic is deeply flawed.  Allow me to restate:
> >One author of this document has appointed themselves the
> >arbiter of consensus.  This author disagrees with other
> >people, and therefore no "consensus" can ever be reached, so
> >the default case this author has chosen is to keep things they
> >way they like it.
> >
> > ...
> >
> >"..omit an explicit algorithm ID..." -- I've said this before,
> >this is a BAD IDEA^tm. The protocol utility of doing this is
> >minimal (1-bit increase in search space), and the operational
> >complexity goes up.  Not to mention, it makes it operationally
> >incompatible with existing implementations.
>
>
>There was logic given to support each side of the argument.  My
>understanding of the summary for each position is:
>
>(position 1 - "include") Including information like algorithm ID
>and k-bit is BAD because it aids in debugging of implementations
>and of configurations.

Wes, did you mean to say "GOOD" instead of "BAD" in this paragraph? 
I'll assume yes.

>(position 2 - "don't include") Including this information is BAD
>because it can expose information about the security parameters.
>It doesn't aid in debugging of configuration because operators still
>have to call each other in order to read off and verify keys.
>
>There seemed to be more people around position 2 than position 1,
>but we should flag this and ask during the meeting, as well as
>open this up on the mailing list to see what people prefer.  We
>need to pick one and move on.

I concur with your recollection about the two positions above. I also 
concur with your recollection that there was more people (not 100% 
consensus, but more) around Position 2 than 1. The argument I made 
went something like this, and was based on lots of years of debugging 
interop issues in both IKEv1/ESP and IKEv2/ESP:
  - there is only the case where the connection will be discussed out 
of band by system admins before a first connection is made. At that 
point, there will be some agreement about config choices.
  - if the connection doesn't work, you double check your config 
matches your agreement of config choices.
  - if the config matches the agreement, then you can try the other 
algo, just in case you misheard that part.
  - if it doesn't work, then you have to pick up the phone and call 
the other guy to double check config parameters.
  Conclusion: having the bits on the wire about the config elements 
doesn't help practically, and contradicts the basic security 
principle of hiding as much about the SA as possible.

So I am also support Position 2.

Gregory.

>As an individual, and not a co-chair, I'm in the position 2 "don't
>include" camp.
>
>
>_______________________________________________
>tcpm mailing list
>tcpm@ietf.org
>https://www.ietf.org/mailman/listinfo/tcpm

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm