Re: [TLS] Confirming consensus about one draft-ietf-tls-renegotiation detail
"Joseph Salowey (jsalowey)" <jsalowey@cisco.com> Tue, 26 January 2010 17:18 UTC
Return-Path: <jsalowey@cisco.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F3F53A67C0 for <tls@core3.amsl.com>; Tue, 26 Jan 2010 09:18:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.399
X-Spam-Level:
X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kg4Q9MRcN88A for <tls@core3.amsl.com>; Tue, 26 Jan 2010 09:18:01 -0800 (PST)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 3819B3A67B6 for <tls@ietf.org>; Tue, 26 Jan 2010 09:18:01 -0800 (PST)
Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAJeyXkurRN+K/2dsb2JhbADDY5cjhDkE
X-IronPort-AV: E=Sophos;i="4.49,347,1262563200"; d="scan'208";a="140238408"
Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 26 Jan 2010 17:18:11 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o0QHIBlW003235; Tue, 26 Jan 2010 17:18:11 GMT
Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 09:18:11 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 26 Jan 2010 09:18:09 -0800
Message-ID: <AC1CFD94F59A264488DC2BEC3E890DE5098037E8@xmb-sjc-225.amer.cisco.com>
In-Reply-To: <D28848FB278CE54FB6A302F413ECF7300592698471@DEWDFECCR07.wdf.sap.corp>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] Confirming consensus about one draft-ietf-tls-renegotiation detail
Thread-Index: AcqeZGsopZGN9hXbTp+VH8GNHSiFbwAK55bgAAayJEA=
References: <808FD6E27AD4884E94820BC333B2DB775841199A56@NOK-EUMSG-01.mgdnok.nokia.com> <D28848FB278CE54FB6A302F413ECF7300592698471@DEWDFECCR07.wdf.sap.corp>
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: "Rex, Martin" <martin.rex@sap.com>, tls@ietf.org
X-OriginalArrivalTime: 26 Jan 2010 17:18:11.0074 (UTC) FILETIME=[89215620:01CA9EAB]
Subject: Re: [TLS] Confirming consensus about one draft-ietf-tls-renegotiation detail
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jan 2010 17:18:03 -0000
This message is raising separate issues than the consensus call, please conduct any discussion of this message on a separate thread with a different subject line. Thanks, Joe > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Rex, > Martin > Sent: Tuesday, January 26, 2010 9:01 AM > To: tls@ietf.org > Subject: Re: [TLS] Confirming consensus about one draft-ietf-tls- > renegotiation detail > > (resent without attachment) > > Dear TLS, > > I have raised concerns to a few changes in the -03 document > that went totally unreviewd, and to issues of SCSV semantics > (the addition of two explicit MUST NOTs) that do not reflect > WG consensus. > > I did not and do not want to "reopen" discussion! > (I explictly urged Pasi to get the SCSV semantics clarified > on Dec-16th, but unfortunately, he declined to touch this > issue in any way. Which is bad because there exist no two > documents of the draft with the same semantics). > > > I also think there are significant editorial (concerning > comprehensiveness) issues with sections that were newly > added to -03 and approved without any kind of review. > > For simplicity, I have provided my _suggestions_ to fix > these issues in form of an updated draft document. > > For ease of access and comparision, you can look at > the differences with the IETF tools > > http://tools.ietf.org/rfcdiff > > -03 document http://tools.ietf.org/html/draft-ietf-tls-renegotiation-03 > my suggesstions ftp://ftp.sap.com/pub/ietf-work/tls/draft-ietf-tls- > renegotiation-04-suggestions-2.txt > > Differences: > > http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/id/draft-ietf- > tls-renegotiation-03.txt&url2=ftp://ftp.sap.com/pub/ietf-work/tls/draft- > ietf-tls-renegotiation-04-suggestions-2.txt > > Attached is a suggestion for a document change that > would resolve my concerns (technically and editorial) > > > During all the WG discussion I was disappointed about > the mediocre document quality of the WG document. > The final -03 document is the first document that comes > close to the expection that the IETF has for a proposal > targeting Proposed Standard. > > http://tools.ietf.org/html/rfc2026#section-4.1.1 > > > The installed base of (apps using) TLS is in the > ballpark of one billion. The optimistic hope of the > TLS WG is that we get this patch adopteb by 50% in the > first 6 month, and around 80% in 12 month. > > That is an optimistic goal, and considering the normal > "progress" of IETF proposed standards, the "adoption" > we are looking at is something that normally applies > to "draft standards", not "proposed standards". > > > In addition to that, I assume there exist >100 independent > implementations of TLS, and only a small fraction of > the implementors (1/4 maybe) is actively participating > the IETF. So it would be good if the document was readable > especially for those, who have the task of implementing > this update still ahead of them. > > > In the spirit of "The Tao of IETF", I have compiled > a list of relevant discussion of the WG concerning > specific SCSV semantics from "those who cared" when > it was discussed. > > http://tools.ietf.org/html/rfc4677#section-5.2 > > and I didn't find a consensus for the two MUST NOTs > that unexplicably popped up in the -03 document. > > > -Martin > > > Here is a WG summery I compiled from my personal EMail > archive. I believe it to contain all relevant postings > (I searched for keywords "cipher" and "MCSV"). > I would appreciate pointers to significant postings > that I may have missed (persons I've missed or > different/new technical aspects I've missed): > > > ******************************************************** > * WG Consensus Call on draft-ietf-tls-renegotiation-00 * > ******************************************************** > > 20-Nov-2009 -- Working group consensus call based on the -00 document > (containing a brief description of resonable SCSV semantics). > http://www.ietf.org/mail-archive/web/tls/current/msg04571.html > > prompting me to commit on publishing my I-D on Monday 23rd > _myself_ http://www.ietf.org/mail- > archive/web/tls/current/msg04576.html > > Support for reasonable/simpler SCSV "I'm updated" semantics during > the WG consensus call: > > _myself_ http://www.ietf.org/mail- > archive/web/tls/current/msg04234.html > http://www.ietf.org/mail- > archive/web/tls/current/msg04791.html > > Nasko Oskov http://www.ietf.org/mail- > archive/web/tls/current/msg04590.html > Wan-Teh Chang http://www.ietf.org/mail- > archive/web/tls/current/msg04585.html > Mike D'Errico http://www.ietf.org/mail- > archive/web/tls/current/msg04594.html > Peter Gutmann http://www.ietf.org/mail- > archive/web/tls/current/msg04651.html > Yoav Nir http://www.ietf.org/mail- > archive/web/tls/current/msg04746.html > Stefan S. http://www.ietf.org/mail- > archive/web/tls/current/msg04747.html > Marsh Ray http://www.ietf.org/mail- > archive/web/tls/current/msg04790.html > David-Sarah H. http://www.ietf.org/mail- > archive/web/tls/current/msg04827.html > > 23-Nov Pasi Eronen (not wearing any hat) on the correct/resonable SCSV in > -00 > Pasi Eronen http://www.ietf.org/mail- > archive/web/tls/current/msg04667.html > > Confirmation of adding SCSV (no explicit or clear semantics expressed): > > Florian Weimer http://www.ietf.org/mail- > archive/web/tls/current/msg04599.html > Stephen Henson http://www.ietf.org/mail- > archive/web/tls/current/msg04207.html > http://www.ietf.org/mail- > archive/web/tls/current/msg04601.html > Simon J. http://www.ietf.org/mail- > archive/web/tls/current/msg04665.html > Kyle Hamilton http://www.ietf.org/mail- > archive/web/tls/current/msg04727.html > Eric Rescorla http://www.ietf.org/mail- > archive/web/tls/current/msg04794.html > http://www.ietf.org/mail- > archive/web/tls/current/msg04798.html > > > Objects to SCSV in general: > > Robert Relyea http://www.ietf.org/mail- > archive/web/tls/current/msg04794.html > Geoffrey K. http://www.ietf.org/mail- > archive/web/tls/current/msg04946.html > > > The first version of my I-D is quite confusing > > 23-Nov-2009 draft-mrex-tls-secure-renegotiation-00 > http://www.ietf.org/mail-archive/web/tls/current/msg04674.html > > > 25-Nov-2009 cleanup draft-mrex-tls-secure-renegotiation-01 > http://www.ietf.org/mail-archive/web/tls/current/msg04817.html > > > Proposal to entirely substitute "empty RI" in initial ClientHello > with > TLS_RENEGO_PROTECTION_REQUEST > Eric Rescorla http://www.ietf.org/mail- > archive/web/tls/current/msg04794.html > > well appreciated: > Stefan S. http://www.ietf.org/mail- > archive/web/tls/current/msg04797.html > Stephen H. http://www.ietf.org/mail- > archive/web/tls/current/msg04799.html > Peter Robinson http://www.ietf.org/mail- > archive/web/tls/current/msg04818.html > > acceptable: > AD Pasi Eronen http://www.ietf.org/mail- > archive/web/tls/current/msg04834.html > Yngve P. http://www.ietf.org/mail- > archive/web/tls/current/msg04812.html > > could live with it, but would like it to be limited to SSLv3: > Robert Relyea http://www.ietf.org/mail- > archive/web/tls/current/msg04803.html > > > Eric annouces this change for the next document update: > Eric Rescorla http://www.ietf.org/mail- > archive/web/tls/current/msg04848.html > > =================================== > = draft-ietf-tls-renegotiation-01 = > =================================== > > 26-Nov-2009 draft-ietf-tls-renegotiation-01.txt > http://www.ietf.org/mail-archive/web/tls/current/msg04847.html > > http://tools.ietf.org/html/draft-ietf-tls-renegotiation-01#section-4 > > > 3 Surprises in Document update: > > 1.) Eric adopts the label "TLS_RENEGO_PROTECTION_REQUEST" from > draft-mrex-tls-secure-renegotiation-01 > > 2.) -01 changes SCSV semantics quite different from what was > discussed. Instead of obsoleting empty RI on initial ClientHello, > there is now an "either empty RI" or "SCSV". > > 3.) for renegotiation ClientHello, the document says > "only renegotiation_info" may be used. > > The RI architecture requires that the verify_data is sent > from Client to Server for renegotiation, which makes it obvious > that the use of SCSV (alone) is insufficient. > > This wording, however, is *NOT* equivalent to "MUST NOT include" > and in particular *NOT* equivalent to a requirement for the > Server "MUST abort if both are present". > > The unexpected (2) change prompts disagreement: > Stefan S. http://www.ietf.org/mail- > archive/web/tls/current/msg04855.html > > > Chris Newman calls for action to kill interop with extensions-intolerant > Server (SSLv3 and TLS), Nelson Bolyard joins in: > Chris Newman http://www.ietf.org/mail- > archive/web/tls/current/msg04856.html > Nelson Bolyard http://www.ietf.org/mail- > archive/web/tls/current/msg04886.html > > > *************************************************************** > * IETF Last Call requested on draft-ietf-tls-renegotiation-01 * > *************************************************************** > > 27-Nov-2009 IETF Last Call requested for -01 document by AD (Pasi) > http://www.ietf.org/mail-archive/web/tls/current/msg04928.html > > to which some WG participants immediately respond that IETF last call > is premature: > Stefan S. http://www.ietf.org/mail- > archive/web/tls/current/msg04931.html > http://www.ietf.org/mail- > archive/web/tls/current/msg04961.html > David-Sarah http://www.ietf.org/mail- > archive/web/tls/current/msg04934.html > Yoav Nir http://www.ietf.org/mail- > archive/web/tls/current/msg05009.html > > I did _not_ complain about the early IETF last call (assuming that > it was possible to get the document fixed before the spec was finalized). > > > The IETF Last Call was only about the document in general, it was > definitely not meant to confirm specific details on semantics, > e.g. like the exact SCSV semantics. > > Even though Stefan Santesson has helped me authoring > draft-mrex-tls-secure-renegotiation and did complain that the -01 WG I-D > provides two different signals on initial ClientHellio in disagreement > to what was discussed, he does not distinguish this semantics > detail in the further discussion, because the IETF Last Call is > made to confirm whether or not using RI, and not about details > of the RI document (of which there are little anyway). > > Stefan S. (http://www.ietf.org/mail- > archive/web/tls/current/msg04855.html) > http://www.ietf.org/mail- > archive/web/tls/current/msg04904.html > http://www.ietf.org/mail- > archive/web/tls/current/msg04991.html > > "Both proposals agree on the same initial signaling (cipher suite > for C->S and empty RI for S->C)" > > The use of the same label "TLS_RENEGO_PROTECTION_REQUEST" but different > semantics makes it quite difficult for the discussion to differentiate > them. > > > 30-Nov-2009 Official IETF Last Call announcement: > http://www.ietf.org/mail-archive/web/tls/current/msg04962.html > > Further WG discussion questioning the changed SCSV semantics in -01 > > 1) quotes -01 text, makes no clear argument > Ben Laurie http://www.ietf.org/mail- > archive/web/tls/current/msg04955.html > > 2) questions "either SCSV or empty RI" for initial ClientHello > and prefers to allow both, but dislikes MUST send SCSV > Marsh Ray http://www.ietf.org/mail- > archive/web/tls/current/msg04963.html > http://www.ietf.org/mail- > archive/web/tls/current/msg04980.html > http://www.ietf.org/mail- > archive/web/tls/current/msg05032.html > http://www.ietf.org/mail- > archive/web/tls/current/msg05042.html > http://www.ietf.org/mail- > archive/web/tls/current/msg05050.html > http://www.ietf.org/mail- > archive/web/tls/current/msg05058.html > http://www.ietf.org/mail- > archive/web/tls/current/msg05096.html > http://www.ietf.org/mail- > archive/web/tls/current/msg05179.html > http://www.ietf.org/mail- > archive/web/tls/current/msg05257.html > > 3) asking for "either one or the other or both" and > for consistent presence of SCSV for initial and renegotiation > ClientHello > Kyle Hamilton http://www.ietf.org/mail- > archive/web/tls/current/msg04974.html > > 4) rather remove SCSV entirely than undecisive "either SCSV or empty RI" > Stephen F. http://www.ietf.org/mail- > archive/web/tls/current/msg05010.html > > 5) indication that he considers the exact semantics a matter of taste > Eric Rescorla http://www.ietf.org/mail- > archive/web/tls/current/msg05048.html > > 6) clear technical(!) preference for easy&clean SCSV semantics > _myself_ http://www.ietf.org/mail- > archive/web/tls/current/msg05030.html > http://www.ietf.org/mail- > archive/web/tls/current/msg05302.html > Mike D'Errico http://www.ietf.org/mail- > archive/web/tls/current/msg05049.html > David-Sarah H. http://www.ietf.org/mail- > archive/web/tls/current/msg05071.html > http://www.ietf.org/mail- > archive/web/tls/current/msg05085.html > http://www.ietf.org/mail- > archive/web/tls/current/msg05273.html > http://www.ietf.org/mail- > archive/web/tls/current/msg05305.html > Mick Gray http://www.ietf.org/mail- > archive/web/tls/current/msg05080.html > http://www.ietf.org/mail- > archive/web/tls/current/msg05169.html > http://www.ietf.org/mail- > archive/web/tls/current/msg05263.html > http://www.ietf.org/mail- > archive/web/tls/current/msg05303.html > http://www.ietf.org/mail- > archive/web/tls/current/msg05306.html > James Manger http://www.ietf.org/mail- > archive/web/tls/current/msg05246.html > Dieter Bratko http://www.ietf.org/mail- > archive/web/tls/current/msg05247.html > Yoav Nir http://www.ietf.org/mail- > archive/web/tls/current/msg05180.html > http://www.ietf.org/mail- > archive/web/tls/current/msg05248.html > > > 7) firmly against "MUST send SCSV" and confirming "either SCSV or empty > RI" > Chris Newman http://www.ietf.org/mail- > archive/web/tls/current/msg05033.html > http://www.ietf.org/mail- > archive/web/tls/current/msg05041.html > http://www.ietf.org/mail- > archive/web/tls/current/msg05170.html > or dropping SCSV entirely: > http://www.ietf.org/mail- > archive/web/tls/current/msg05087.html > > 8) firmly against "MUST send SCSV", but OK with sending both > Robert Relya http://www.ietf.org/mail- > archive/web/tls/current/msg05264.html > Nelson Bolyard http://www.ietf.org/mail- > archive/web/tls/current/msg05066.html > http://www.ietf.org/mail- > archive/web/tls/current/msg05076.html > http://www.ietf.org/mail- > archive/web/tls/current/msg05181.html > http://www.ietf.org/mail- > archive/web/tls/current/msg05266.html > > 9) likes to send both SCSV+RI on initial ClientHello > Stephen Henson http://www.ietf.org/mail- > archive/web/tls/current/msg05220.html > > > 10) Eric trying to close some of the issues under discussion > Eric Rescorla http://www.ietf.org/mail- > archive/web/tls/current/msg05196.html > SCSV (MCSV)-related feedback to this: > Michael Gray http://www.ietf.org/mail- > archive/web/tls/current/msg05227.html > > 11) suggests spec to be explicit, prefer use of SCSV only for applicable > initial client hellos, OK with MAY send SCSV in every handshake, > could live with MUST use SCSV in every initial ClientHello > Yngve P. http://www.ietf.org/mail- > archive/web/tls/current/msg05296.html > http://www.ietf.org/mail- > archive/web/tls/current/msg05309.html > http://www.ietf.org/mail- > archive/web/tls/current/msg05313.html > > ************************** > * IETF Last Call summary * > ************************** > > > 16-Dec-2009 IETF Last Call Summary by Pasi Eronen: > Pasi Eronen http://www.ietf.org/mail- > archive/web/tls/current/msg05357.html > > > Discontent with process-related issues: > _myself_ http://www.ietf.org/mail- > archive/web/tls/current/msg05373.html > Nico Williams http://www.ietf.org/mail- > archive/web/tls/current/msg05377.html > > AD reply: > Pasi Eronen http://www.ietf.org/mail- > archive/web/tls/current/msg05394.html > > > Discussion about SCSV semantics contine: > > Pro sensible SCSV semantics: > _myself_ http://www.ietf.org/mail- > archive/web/tls/current/msg05359.html > http://www.ietf.org/mail- > archive/web/tls/current/msg05365.html > http://www.ietf.org/mail- > archive/web/tls/current/msg05372.html > Mike D'Errico http://www.ietf.org/mail- > archive/web/tls/current/msg05364.html > Kyle Hamilton http://www.ietf.org/mail- > archive/web/tls/current/msg05415.html > > > Explicitly allow both (SCSV and RI) on initial ClientHello: > David Kemp http://www.ietf.org/mail- > archive/web/tls/current/msg05370.html > > > > Lengthy Email exchange with a particular point about MCSV semantics and > proposed new text for the upcoming document update (-02, after LastCall): > Marsh Ray http://www.ietf.org/mail- > archive/web/tls/current/msg05261.html > _myself_ http://www.ietf.org/mail- > archive/web/tls/current/msg05265.html > Marsh Ray http://www.ietf.org/mail- > archive/web/tls/current/msg05366.html > _myself_ http://www.ietf.org/mail- > archive/web/tls/current/msg05379.html > > Other squabbles about the use of terminology: > Marsh Ray http://www.ietf.org/mail- > archive/web/tls/current/msg05361.html > > > =================================== > = draft-ietf-tls-renegotiation-02 = > =================================== > > > 16-Dec-2009 draft-ietf-tls-renegotiation-02.txt > http://www.ietf.org/mail-archive/web/tls/current/msg05378.html > > > ************************************************************************ > * Further WG discussions about SCSV semantics, converging to consensus * > ************************************************************************ > > Relaxed sensible SCSV semantics (MAY everywhere, no MUSTs, not MUST NOTs): > Mike D'Errico http://www.ietf.org/mail- > archive/web/tls/current/msg05398.html > http://www.ietf.org/mail- > archive/web/tls/current/msg05449.html > http://www.ietf.org/mail- > archive/web/tls/current/msg05456.html > http://www.ietf.org/mail- > archive/web/tls/current/msg05464.html > http://www.ietf.org/mail- > archive/web/tls/current/msg05496.html > Robert Dugal http://www.ietf.org/mail- > archive/web/tls/current/msg05441.html > _myself_ http://www.ietf.org/mail- > archive/web/tls/current/msg05452.html > http://www.ietf.org/mail- > archive/web/tls/current/msg05498.html > http://www.ietf.org/mail- > archive/web/tls/current/msg05458.html > http://www.ietf.org/mail- > archive/web/tls/current/msg05466.html > Eric Rescorla http://www.ietf.org/mail- > archive/web/tls/current/msg05445.html > Uri Blumenthal http://www.ietf.org/mail- > archive/web/tls/current/msg05472.html > http://www.ietf.org/mail- > archive/web/tls/current/msg05493.html > http://www.ietf.org/mail- > archive/web/tls/current/msg05519.html > http://www.ietf.org/mail- > archive/web/tls/current/msg05546.html > Pasi Eronen http://www.ietf.org/mail- > archive/web/tls/current/msg05490.html > Yoav Nir http://www.ietf.org/mail- > archive/web/tls/current/msg05491.html > http://www.ietf.org/mail- > archive/web/tls/current/msg05521.html > Stephen Henson http://www.ietf.org/mail- > archive/web/tls/current/msg05497.html > Marsh Ray http://www.ietf.org/mail- > archive/web/tls/current/msg05500.html > http://www.ietf.org/mail- > archive/web/tls/current/msg05511.html > Nasko Oskov http://www.ietf.org/mail- > archive/web/tls/current/msg05501.html > > Nelson Bolyard http://www.ietf.org/mail- > archive/web/tls/current/msg05559.html > > > =================================== > = draft-ietf-tls-renegotiation-03 = > =================================== > > 05-Jan-2010 draft-ietf-tls-renegotiation-03.txt > http://www.ietf.org/mail-archive/web/tls/current/msg05560.html > > 07-Jan-2010 Protocol Action: Document approved by IESG > http://www.ietf.org/mail-archive/web/tls/current/msg05560.html > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls
- Re: [TLS] Confirming consensus about one Martin Rex
- Re: [TLS] Chatter on consensus Martin Rex
- [TLS] Confirming consensus about one draft-ietf-t… Pasi.Eronen
- Re: [TLS] Confirming consensus about one draft-ie… Robert Dugal
- Re: [TLS] Confirming consensus about one draft-ie… Dr Stephen Henson
- Re: [TLS] Confirming consensus about one draft-ie… Kemp, David P.
- Re: [TLS] Confirming consensus about one draft-ie… Paul Hoffman
- Re: [TLS] Confirming consensus about one draft-ie… Michael D'Errico
- Re: [TLS] Confirming consensus about one draft-ie… Rex, Martin
- Re: [TLS] Confirming consensus about one draft-ie… Joseph Salowey (jsalowey)
- Re: [TLS] Confirming consensus about one draft-ie… Martin Rex
- [TLS] Metadiscussion on changes in draft-ietf-tls… Paul Hoffman
- Re: [TLS] Confirming consensus about one draft-ie… Marsh Ray
- Re: [TLS] Metadiscussion on changes in draft-ietf… Martin Rex
- Re: [TLS] Confirming consensus about one draft-ie… Hovav Shacham
- Re: [TLS] Confirming consensus about one Martin Rex
- Re: [TLS] Confirming consensus about one Kemp, David P.
- Re: [TLS] Confirming consensus about one draft-ie… Nikos Mavrogiannopoulos
- Re: [TLS] Confirming consensus about one Yoav Nir
- Re: [TLS] Confirming consensus about one draft-ie… Yngve Nysaeter Pettersen
- [TLS] Chatter on consensus Kemp, David P.
- Re: [TLS] Chatter on consensus Martin Rex
- Re: [TLS] Confirming consensus about one Martin Rex
- Re: [TLS] Confirming consensus about one Nelson B Bolyard
- Re: [TLS] Confirming consensus about one Martin Rex
- Re: [TLS] Metadiscussion on changes in draft-ietf… Bob Braden
- Re: [TLS] Confirming consensus about one Michael D'Errico
- Re: [TLS] Chatter on consensus Kemp, David P.
- Re: [TLS] Confirming consensus about one Marsh Ray
- Re: [TLS] Confirming consensus about one draft-ie… Robert Relyea
- Re: [TLS] Metadiscussion on changes in draft-ietf… Martin Rex
- Re: [TLS] Metadiscussion on changes in draft-ietf… Paul Hoffman
- [TLS] interoperability and security guarantees [w… Daniel Kahn Gillmor
- Re: [TLS] Chatter on consensus Kemp, David P.
- Re: [TLS] Chatter on consensus Michael D'Errico
- Re: [TLS] Chatter on consensus Martin Rex
- Re: [TLS] Confirming consensus about one Yoav Nir
- Re: [TLS] Metadiscussion on changes in draft-ietf… Pasi.Eronen
- Re: [TLS] Metadiscussion on changes in draft-ietf… Martin Rex
- Re: [TLS] Chatter on consensus Kemp, David P.
- Re: [TLS] Confirming consensus about one Martin Rex
- Re: [TLS] Confirming consensus about one Martin Rex
- Re: [TLS] Chatter on consensus Nikos Mavrogiannopoulos
- Re: [TLS] Metadiscussion on changes in draft-ietf… Pasi.Eronen
- Re: [TLS] Metadiscussion on changes in draft-ietf… Martin Rex
- Re: [TLS] Confirming consensus about one draft-ie… Paul Hoffman
- Re: [TLS] Confirming consensus about one draft-ie… Martin Rex
- Re: [TLS] Chatter on consensus Martin Rex
- Re: [TLS] Confirming consensus about one draft-ie… Bill Frantz
- Re: [TLS] Confirming consensus about one draft-ie… tom.petch
- Re: [TLS] Confirming consensus about one draft-ie… Joseph Salowey (jsalowey)