With no dis-respect to Russ or Ralph (but with zero
acceptance/respect for the main concept espoused by this

I request that the WG chairs not waste yet more time on
agenda items dealing with proposals for breaking TLS - a
working group that spends so many f2f hours (yes, hours,
multiplied by a few hundred travelling people in a room)
on ways in which the core purpose of the WG (read the
abstract of the tls1.3 draft if you doubt that) could be
subverted *by the WG itself* seems really really weird to

Enough, already.

Given the (lack of) potential for any of these (IMO bad)
ideas to garner rough consensus, I really think this would
be a *terribly* bad waste of f2f time and participant cycles,
no matter who proposes we waste time in that manner.

If time is regrettably granted for this yet again then I
also request time to propose not breaking TLS. (I don't care
if the presenter for that rebuttal slot is me or someone
else with the same views that the WG charter is clear that
the WG exists to make TLS better and not to break it.)

If a rebuttal slot is not considered appropriate then I
request a slot to help us reach consensus on whether or
not there's value in documenting the reasons to not break
TLS. (I believe the chairs agreed to try figure out if
the WG have consensus that that'd be worthwhile a couple
of meetings ago, but we've not done that so far.)

To be clear: given a choice of (a) not wasting yet more WG
time on this and (b) another bun-fight with an inevitable
outcome - I prefer (a) but will engage in (b) as necessary
(and enthusiastically, whilst grimacing;-)


PS: That Russ requests a few minutes for an update does not
affect the above - I for one do not agree that this draft
ought get any WG time and allocating a few minutes for an
update would IMO normalise what ought be considered entirely
abnormal. The number of "proponent minutes this time" is not
a valid agenda-planning consideration IMO.

On 02/03/18 21:00, Russ Housley wrote:
> A few minutes at the TLS WG session in London have been requested to talk 
> about this draft.
> Russ
>> From: internet-dra...@ietf.org
>> Subject: New Version Notification for draft-rhrd-tls-tls13-visibility-01.txt
>> Date: March 2, 2018 at 3:58:35 PM EST
>> To: "Ralph Droms" <rdroms.i...@gmail.com>, "Russ Housley" 
>> <hous...@vigilsec.com>
>> A new version of I-D, draft-rhrd-tls-tls13-visibility-01.txt
>> has been successfully submitted by Ralph Droms and posted to the
>> IETF repository.
>> Name:                draft-rhrd-tls-tls13-visibility
>> Revision:    01
>> Title:               TLS 1.3 Option for Negotiation of Visibility in the 
>> Datacenter
>> Document date:       2018-03-02
>> Group:               Individual Submission
>> Pages:               11
>> URL:            
>> https://www.ietf.org/internet-drafts/draft-rhrd-tls-tls13-visibility-01.txt
>> Status:         
>> https://datatracker.ietf.org/doc/draft-rhrd-tls-tls13-visibility/
>> Htmlized:       
>> https://tools.ietf.org/html/draft-rhrd-tls-tls13-visibility-01
>> Htmlized:       
>> https://datatracker.ietf.org/doc/html/draft-rhrd-tls-tls13-visibility-01
>> Diff:           
>> https://www.ietf.org/rfcdiff?url2=draft-rhrd-tls-tls13-visibility-01
>> Abstract:
>>   Current drafts of TLS 1.3 do not include the use of the RSA
>>   handshake.  While (EC) Diffie-Hellman is in nearly all ways an
>>   improvement over the TLS RSA handshake, the use of (EC)DH has impacts
>>   certain enterprise network operational requirements.  The TLS
>>   Visibility Extension addresses one of the impacts of (EC)DH through
>>   an opt-in mechanism that allows a TLS client and server to explicitly
>>   grant access to the TLS session plaintext.
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> The IETF Secretariat
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

Attachment: 0x7B172BEA.asc
Description: application/pgp-keys

Attachment: signature.asc
Description: OpenPGP digital signature

TLS mailing list

Reply via email to