Re: [Lake] LAKE next steps

[Benjamin Kaduk <[e-mail]>]

[secdispatch@ again to bcc]

Hi Rene,

On Mon, Aug 26, 2019 at 11:21:06PM -0400, Rene Struik wrote:
> On 8/26/2019 4:24 PM, Benjamin Kaduk wrote:
> > On Tue, Aug 20, 2019 at 12:13:18PM -0400, Rene Struik wrote:
> >> Hi Ben:
> >>
> >>   From the discussion at the LAKE BoF, it seemed there was strong support
> >> [1] for also tackling the broader scenario (triggered by David Thaler's
> >> suggested dichotomy at the microphone).
> >>
> >> I have some trouble seeing suggested next steps on tackling this broader
> >> problem in you email below. If you could elaborate on how you see this
> >> broader topic ("general purpose lightweight AKE") find a home in terms
> >> of next steps, that would be great. (In my mind, this is not simply "TLS
> >> with compressed representation".)
> > I think we also heard, in addition to the generic "broader problem" hum,
> > several explicit statements at the mic about how a reduced-encoding
> > "compact TLS" was a good thing, and that having the LAKE discussions may
> > have been the trigger needed to make that happen.  So yes, my thinking was
> > mostly "TLS with compressed representation" and possibly some additional
> > tweaks that are TBD.  Could you elaborate on your thinking for how the
> > general-purpose lightweight AKE would differ from "TLS with compressed
> > representation"?
> 
> RS>> (Procedural.) I reread the draft minutes of the LAKE BoF and found 
> 15-17 hands for OSCORE and 10-11 for the general case (i.e., both have 
> sufficient critical mass). Enthusiasm for other options was not polled 
> in the room; hence, my question. You seem to quote Carsten Bormann's 
> remark at the mic (according to minutes), but there were many other 
> remarks as well, and - arguably - one can cherry-pick any set of remarks 
> to arrive at different conclusions. The chartering discussion itself, 
> though, did focus on the "narrow" vs. "general" notion David Thaler 
> brought to the table and which was discussed in the latter part of the 
> BoF meeting. BTW - I still do not understand how TLS with a compressed 
> encoding scheme could be considered general. <<RS

I fear I'm still confused or don't understand your point, or perhaps what
you mean by "general".  Would you disagree if I said that "TLS is the de
facto general-purpose communications security protocol for the Web"?  What
about if I replaced "Web" with "Internet"?  If the core protocol is
general-purpose, does it not remain general-purpose if the encoding is
compressed?  The best way I can find to interpret your remark is that the
"general-purpose constrained use case" has different requirements than an
Internet-wide general-purpose communications protocol, but (1) I'm not very
confident that's what you mean, and (2) even if that is what you mean, I
don't know that anyone has tried to do a survey for what those specific
requirements would be and how they might differ from the Internet case.

> RS>> (Technical.) It would be prudent for IETF not to put too many eggs 
> in the same basket and, thereby, not have most protocols share the same 
> crypto design philosophy, protocol flow framework, and instantiation. 
> While arguably convenient, this is contrary to algorithm agility 
> requirements (since results in in-tandem vulnerabilities and easily 
> ossified code). Hence, my case for not loosing sight of addressing the 
> more general problem, with an open mind. I am willing to contribute to 
> this and so are 10 others (according to the hum). Arguably, this general 
> case cannot presume the Client/Server model, nor semi-infinite resources 
> on one of the entities. This being said, this is not a blank slate area 
> and closure on fundamental design can be reached in a reasonable, 
> limited time frame by experienced people. <<RS

I actually do not take it as a given that, when working with a fixed set of
resources, diversity of design/implementation is always the most optimal
approach, regarding "eggs in the same basket" -- there are tradeoffs to be
made and the analysis may produce different results in different
situations.

With respect to your request to not lose sight of addressing the more
general problem, I note that the current charter under discussion is
explicitly targetting just the OSCORE use case, with intent to ask the TLS
WG to consider cTLS.  If you feel that this is not adequately addressing
what you see as the "more general problem", then please suggest an
alternate course of action, whether that is an edit to the proposed LAKE
charter, a draft charter for a separate WG, or some other proposal.  As it
is, I have to guess what you want to see happen, and my track record for
guessing is not great.

Thanks,

Ben