Subject: Re: [TLS] TLS@IETF100: Agenda Requests

From: Sean Turner <[email-masked]>
Date: Thu, 2 Nov 2017 12:37:33 -0400

All,

Due to some unforeseen circumstances neither author of draft-rhrd-tls-tls13-visibility is able to attend IETF 100.  As a result, they’ve withdrawn their request for agenda time.

Based on agenda requests received to date, we also believe that we will only need the 2.5 hour session on Wednesday.  We will shortly submit a request to the secretariat to cancel that session to allow others to claim that time.

J&S

> On Oct 24, 2017, at 12:32, Sean Turner <[email-masked]> wrote:
> 
> All,
> 
> You will have seen that the chairs requested two sessions for IETF 100 TLS (on 20170929) and you will have also seen the that our request was granted (on 20171020).  The sessions are currently scheduled as follows:
> 
>  tls Session 1 (2:30:00)
>  Thursday, Morning Session I 0930-1200
>  Room Name: Canning size: 250
>  ---------------------------------------------
>  tls Session 2 (1:00:00)
>  Monday, Afternoon Session III 1740-1840
>  Room Name: Padang size: 300
>  ---------------------------------------------
> 
> We would like to get a sense of who wants to request agenda time so please send in your requests by 20171029; this will give the chairs time to upload a draft agenda due on 20171030.  Along with your request please let us know how long you would like.
> 
> NOTE: Those that have already submitted requests need not do so again.
> 
> J&S

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 2 Nov 2017 16:40:15 +0000

➢ Due to some unforeseen circumstances neither author of draft-rhrd-tls-tls13-visibility is able to attend IETF 100.  As a result, they’ve withdrawn their request for agenda time.
    
I think it would still be worthwhile to have time for the WG to see if it can come to consensus on whether or not to do anything in this area at this time.

---

From: Melinda Shore <[email-masked]>
Date: Sat, 4 Nov 2017 22:29:58 -0800

On 11/2/17 8:40 AM, Salz, Rich wrote:
>> Due to some unforeseen circumstances neither author of
>> draft-rhrd-tls-tls13-visibility is able to attend IETF 100.  As a
>> result, they’ve withdrawn their request for agenda time.

> I think it would still be worthwhile to have time for the WG to see
> if it can come to consensus on whether or not to do anything in this
> area at this time.

Well ...  Decisions are made on the mailing list, not at meetings.
Either way, I don't think that it makes sense to try to come to a
decision on this without its advocates present.  I don't like this
proposal, and few other people seem to, and it seems to me that a
bunch of us sitting around telling each other that we don't like it
is probably not a very good use of meeting time.

Melinda

-- 
Software longa, hardware brevis

PGP fingerprint: 795A 714B CD08 F996 AEFE
                 AB36 FE18 57E9 6B9D A293

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 5 Nov 2017 13:03:32 +0000

So if the only people in favor of it are the draft authors, then we have consensus, right?

---

From: Ted Lemon <[email-masked]>
Date: Sun, 5 Nov 2017 08:09:39 -0500

Consensus isn't about number of votes. However, I think we can say that
although there seems to be some interest in making sure this use case is
addressed, there are known ways of addressing it, and little interest in
inventing a new way that weakens a new feature of tls 1.3

On Nov 5, 2017 14:03, "Salz, Rich" <[email-masked]> wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 5 Nov 2017 14:13:19 +0000

Hiya,

> inventing a new way that weakens a new feature of tls 1.3

Don't disagree. In addition there's always been folks in the
rough when it comes to any security BCP or similar and ISTM
that the breaking-TLS case is no different - there'll always
be people who (mistakenly IMO) perceive that it'd be better
to break TLS (and prioritise their particular concern) than
it is do our best to improve Internet security and privacy
overall. (That's one reason the chairs' question in Prague
wasn't a good one - it will always be the case that there are
IETFers who do want to break TLS and similar - we learned
nothing from that hum at all.)

As a meta-comment, I think it's really a pity that most or
all such break-TLS proposals appear to be accompanied (not
necessarily from draft authors) by bad argument, overstatement
and ignoring the existence of downsides. (*) IMO that is yet
another indicator that those arguing to break TLS know that
they're likely to end up in the rough and hence at tempted
to attempt the "hard-sell" (as you Ted I think called it,
perhaps too generously) which is I think disruptive to WG
progress.

So I'd argue to not bother discussing this bad idea again at
IETF-100 - it's consumed enough cycles already and we won't
learn anything at all if we do waste time in that way yet
again.

S.

(*) I fully admit to meeting such bad argument with robust
argument and will continue doing so:-)

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 5 Nov 2017 16:09:20 +0000

*   Consensus isn't about number of votes. However, I think we can say that although there seems to be some interest in making sure this use case is addressed, there are known ways of addressing it, and little interest in inventing a new way that weakens a new feature of tls 1.3

I didn’t say votes.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 5 Nov 2017 17:14:42 +0100

> I didn’t say votes.

Sure, but you did say "only the authors are interested" which to me seems to imply a comparison of numbers.   Sometimes everybody who's interested in an idea is an author; that doesn't mean it's a bad idea.   There have been cases when very good ideas have been squashed because the working group chair believed that a document needed more than just the authors to support it.   So over the years I guess I will admit to having developed a bit of a knee-jerk reaction to this argument—sorry about that!

My point here is that that's not the reason to reject the document.   The reason in this case is that there already exist better ways to solve the problem, and the proposal would clearly make TLS 1.3 worse, even though there is disagreement about how much worse it would make it.

---

From: Melinda Shore <[email-masked]>
Date: Sun, 5 Nov 2017 10:02:12 -0900

On 11/5/17 7:14 AM, Ted Lemon wrote:
> My point here is that that's not the reason to reject the document.  
> The reason in this case is that there already exist better ways to solve
> the problem, and the proposal would clearly make TLS 1.3 worse, even
> though there is disagreement about how /much/ worse it would make it.

Right, the question is about the technical merits of the proposal.
If I'm recalling correctly the widespread view of STUN when it was
first brought in was that it was revolting.  That may continue to
be the most widely-held view, but unlike the rhrd draft there was no
other workable solution at the time to an extremely pressing problem.
Anyway there's precedent for something most people don't like moving
forward and eventually being published as a standard if the technical
arguments are sound.

At any rate, the discussion of the proposal, if there is to be one,
belongs on the mailing list.  Having the discussion and coming to
a conclusion 1) during a meeting 2) where none of the proponents
is present seems like an abuse of process to me (not to mention a
waste of meeting time).  Furthermore it seems like the technical
merits of the rhrd proposal are thin enough that it's unlikely to
progress, anyway.

Melinda

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 5 Nov 2017 19:04:55 +0000

➢ At any rate, the discussion of the proposal, if there is to be one,
    belongs on the mailing list.  Having the discussion and coming to
    a conclusion 1) during a meeting 2) where none of the proponents
    is present seems like an abuse of process to me

I asked for time so that we could discuss it.  Of course, all decisions are confirmed on the mailing list and I never meant otherwise.  Sorry for assuming everyone understood.