Re: [TLS] Confirming consensus about one draft-ietf-tls-renegotiation detail
"Rex, Martin" <martin.rex@sap.com> Tue, 26 January 2010 17:00 UTC
Return-Path: <martin.rex@sap.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 C135C3A67F4 for <tls@core3.amsl.com>; Tue, 26 Jan 2010 09:00:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.199
X-Spam-Level:
X-Spam-Status: No, score=-9.199 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 tt3DGAllHLWn for <tls@core3.amsl.com>; Tue, 26 Jan 2010 09:00:32 -0800 (PST)
Received: from smtpgw.sap-ag.de (smtpgw02.sap-ag.de [155.56.66.97]) by core3.amsl.com (Postfix) with ESMTP id 4433A3A686C for <tls@ietf.org>; Tue, 26 Jan 2010 09:00:31 -0800 (PST)
From: "Rex, Martin" <martin.rex@sap.com>
To: "tls@ietf.org" <tls@ietf.org>
Date: Tue, 26 Jan 2010 18:00:31 +0100
Thread-Topic: Confirming consensus about one draft-ietf-tls-renegotiation detail
Thread-Index: AcqeZGsopZGN9hXbTp+VH8GNHSiFbwAK55bg
Message-ID: <D28848FB278CE54FB6A302F413ECF7300592698471@DEWDFECCR07.wdf.sap.corp>
References: <808FD6E27AD4884E94820BC333B2DB775841199A56@NOK-EUMSG-01.mgdnok.nokia.com>
In-Reply-To: <808FD6E27AD4884E94820BC333B2DB775841199A56@NOK-EUMSG-01.mgdnok.nokia.com>
Accept-Language: en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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:00:34 -0000
(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
- 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)