Re: RIM patents using a mime body in a message (and ignores IETF IPR rules)

[Arnt Gulbrandsen]

Simon Josefsson writes:

Arnt Gulbrandsen  writes:

 Simon Josefsson writes:
 There is no requirement in the IETF process for organizations to 
 disclose patents as far as I can see. The current approach of only 
 having people participate, and disclose patents, in the IETF is 
 easy to work around by having two persons in an organization doing 
 different things: one works on specifying and standardizing 
 technology, and the other is working on patenting the technology.


 How can you practically avoid the first person knowing about it?


Make sure (through confidentiality agreements) that the second one do 
not talk with the first? Putting them in different continents helps.


The patent submitter has to be the inventor, so the person who works on 
standardisation has to not talk to the inventor at all for this scheme 
to work. This seems rather far-fetched to me. Not one of my greatest 
worries.


Arnt
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer Security (TLS) Renegotiation Indication Extension) to Proposed Standard

[Yoav Nir]

On Nov 30, 2009, at 5:37 PM, The IESG wrote:

> The IESG has received a request from the Transport Layer Security WG 
> (tls) to consider the following document:
> 
> - 'Transport Layer Security (TLS) Renegotiation Indication Extension '
>as a Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to the
> ietf@ietf.org mailing lists by 2009-12-14. Exceptionally, 
> comments may be sent to i...@ietf.org instead. In either case, please 
> retain the beginning of the Subject line to allow automated sorting.

I oppose publishing the current draft. 

There are two unresolved issues still being discussed on the TLS mailing list: 
 1. non-extension signaling for older versions (SSLv3 and maybe TLS 1.0)
 2. explicit vs implicit addition of old verify_data to the PRF (also known as 
fail-unsafe vs fail-safe)

I think the WG is converging, and that a couple of more weeks of discussion may 
lead to consensus. 

I agree with David-Sarah Hopwood that a last call (WG or IETF) is still 
premature.

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: RIM patents using a mime body in a message (and ignores IETF IPR rules)

[Tobias Gondrom]

Arnt Gulbrandsen wrote:
> Simon Josefsson writes:
>> Arnt Gulbrandsen  writes:
>>>  Simon Josefsson writes:
  There is no requirement in the IETF process for organizations to
  disclose patents as far as I can see. The current approach of only
  having people participate, and disclose patents, in the IETF is
  easy to work around by having two persons in an organization doing
  different things: one works on specifying and standardizing
  technology, and the other is working on patenting the technology.
>>>
>>>  How can you practically avoid the first person knowing about it?
>>
>> Make sure (through confidentiality agreements) that the second one do
>> not talk with the first? Putting them in different continents helps.
>
> The patent submitter has to be the inventor, so the person who works
> on standardisation has to not talk to the inventor at all for this
> scheme to work. This seems rather far-fetched to me. Not one of my
> greatest worries.

absolutely. And actually at least a few years back, the process was that
you have to obtain acknowledgement from all inventors (by signature) so
it would be virtually impossible to be named on a patent in the US
without knowing it.
Anyway, all not relevant as this case is pretty straight forward.

Tobias



> Arnt
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>
>

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: RIM patents using a mime body in a message (and ignores IETF IPR rules)

[Simon Josefsson]

Scott Brim  writes:

> Simon Josefsson allegedly wrote on 11/30/2009 10:11 AM:
>> There is no requirement in the IETF process for organizations to
>> disclose patents as far as I can see.  The current approach of only
>> having people participate, and disclose patents, in the IETF is easy to
>> work around by having two persons in an organization doing different
>> things: one works on specifying and standardizing technology, and the
>> other is working on patenting the technology.
>
> Simon, from rfc3979:
>
>l. "Reasonably and personally known": means something an individual
>   knows personally or, because of the job the individual holds,
>   would reasonably be expected to know.  This wording is used to
>   indicate that an organization cannot purposely keep an individual
>   in the dark about patents or patent applications just to avoid the
>   disclosure requirement.  But this requirement should not be
>   interpreted as requiring the IETF Contributor or participant (or
>   his or her represented organization, if any) to perform a patent
>   search to find applicable IPR.

I don't see how this modifies anything?  The legal obligation is on the
IETF participant, not on the organization.  The organization is not
bound by this text.

/Simon
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer Security (TLS) Renegotiation Indication Extension) to Proposed Standard

[Stephen Farrell]

Yoav Nir wrote:
> On Nov 30, 2009, at 5:37 PM, The IESG wrote:
> 
>> The IESG has received a request from the Transport Layer Security WG 
>> (tls) to consider the following document:
>>
>> - 'Transport Layer Security (TLS) Renegotiation Indication Extension '
>>as a Proposed Standard
>>
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action.  Please send substantive comments to the
>> ietf@ietf.org mailing lists by 2009-12-14. Exceptionally, 
>> comments may be sent to i...@ietf.org instead. In either case, please 
>> retain the beginning of the Subject line to allow automated sorting.
> 
> I oppose publishing the current draft. 

I strongly support it.

I don't buy the claims that extension handling as required here
is so hard to implement and all clients & servers need modification
in any case. (Not that its really relevant, but writing that code
would be much easier that reading the recent TLS list traffic;-)

I also don't see any concrete benefit in not sending the verify
data over the wire, but I do see more possibility for error in
terms of how to incorporate that data if its not sent.

My comments on -01 are below. While I'd like to see these addressed
of course, I think progressing this document speedily is more
important than resolving my comments. I think the same applies
to all other comments that I've seen, both during IETF LC and
on the TLS list since this problem was announced.

Regards,
Stephen.


1. The reference for the HTTP splicing attack is still a
placeholder. "[REF]"

2. I don't see any particular reason why the ServerHello RI value
contains both client and server values. I think it'd be marginally
better if the server just sent its value since the current approach
makes it easier for a server to mess up the ordering.

3. (Crossing page 5/6) It says the both "MUST verify" that the
values are correct, but doesn't explicitly say how to verify
the values, but just "as specified below" - where below?
It might be good to be extra-clear here, and add e.g. "A correct
value is one that was the verify_data of the Finished message
from the previous TLS session, or else the "empty" value given
above."  or something like that.

4. I'm slightly concerned that middleboxes might barf on the
new ciphersuite. Be good if someone had tested that in the wild,
but I've not seen a mail that says that that's happened. (The test
I mean is inclusion of a totally new ciphersuite value, not the
inclusion of a previously-allocated-but-mostly-unused value.)

5. (Similar to above.) It'd be great if we had data to allow
us to recommend either the RI in the initial handshake or else
recommend the ciphersuite. I can see implementers not knowing
what to do there, leading to a 50-50 split in terms of who
does what, possibly leading to lack of interop. If it were up
to me, I'd remove the ciphersuite and just go with the RI.

6. Is there an explicit statement somewhere that servers MUST
support both the RI extension and the ciphersuite? If so, I
skipped over it, so maybe highlighting it somehow would be
good. If not, please add, so that someone generating tests
from the RFC's "MUST" statements generates one for that.

7. 6.2 says: "If servers wish to <> they MUST
NOT <>" Isn't that equivalent to servers SHOULD
NOT? I think a SHOULD NOT is better. (And that's the form
used in section 7.)

8. I would be for removing the new requirement that the
identity not change. This spec is in response to one thing
and should only fix that thing. Any other considerations
should not get the "emergency" treatment being applied
here especially since there could be unforseen side-effects
of the additional change. (E.g. some deployed application
making use of an id-change.)

9. The security considerations and the introduction
should include a statement that another mitigation that's
useful in many cases is for a server to simply disallow
all renegotiation and encourage implementers to allow
deployments to control that.





___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer Security (TLS) Renegotiation Indication Extension) to Proposed Standard

[Bodo Moeller]

On Nov 30, 2009, at 4:37 PM, The IESG wrote:


The IESG has received a request from the Transport Layer Security WG
(tls) to consider the following document:

- 'Transport Layer Security (TLS) Renegotiation Indication Extension '
   as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to  
the

ietf@ietf.org mailing lists by 2009-12-14.


I support the move, contingent to two clean-ups to specified behavior:


1. Section 3 specifies "For ClientHellos which are renegotiating, this  
field contains the verify_data from the Finished message sent by the  
client on the immediately previous handshake", and "For ServerHellos  
which are renegotiating, this field contains the concatenation of the  
verify_data values sent by the client and the server (in that order)  
on the immediately previous handshake."


There is no good reason for this asymmetry of having just the client's  
verify_data in the client's message, but both the client's and the  
server's verify_data in the server's message -- the latter is pure  
overhead, both in the specification and in the on-the-wire protocol.   
To remove the overhead from both, the second sentence should be  
saying, "For ServerHellos which are renegotiating, this field contains  
the verify_data sent by the server on the immediately previous  
handshake" (according changes to dependent parts of the specification  
then should be made).


For earlier Internet Drafts in the series preceding draft-ietf-tls- 
renegotiation-01.txt (draft-rescorla-tls-renegotiation.00.txt, etc.),  
a reason to keep the current text would have been to maintain  
compatibility with early implementations of those Internet Drafts.   
However, draft-ietf-tls-renegotiation-01 has a newer  
TLS_RENEGO_PROTECTION_REQUEST cipher suite and thus breaks  
compatibility with those early implementations anyway.


(This means that now, changing the ServerHello extension definition as  
suggested above gives the beneficial side-effect of exposing premature  
implementations, besides merely avoiding overhead.  Those incomplete  
implementations will be more obviously incompatible because they'd  
still be using the protocol variant with overhead, instead of just  
differing subtly in the behavior if faced with  
TLS_RENEGO_PROTECTION_REQUEST.)



2. The Security Considerations section of draft-ietf-tls- 
renegotiation-01.txt (section 7) includes language that unnecessarily  
restricts the flexibility that the TLS protocol specifically provides  
for, regulating areas that the TLS standard intentionally does not  
specify (RFC 5246 section 1) -- the current Internet Draft says:


"By default, TLS implementations conforming to this document MUST  
verify that once the peer has been identified and authenticated within  
the TLS handshake, the identity does not change on subsequent  
renegotiations. For certificate based cipher suites, this means  
bitwise equality of the end-entity certificate. If the other end  
attempts to authenticate with a different identity, the renegotiation  
MUST fail. If the server_name extension is used, it MUST NOT change  
when doing renegotiation."


There is no security reason for this restriction.  This sounds like a  
bad and incomplete workaround for certain problems with TLS that the  
updated protocol does not need a workaround for at all, because the  
protocol update is all about properly *solving* those problems.


Keeping this language in the specification would have the weird  
implication that applications that *need* the flexibility provided by  
the TLS protocol (e.g., to allow renegotiation handshakes to switch to  
a different ciphersuite, which may require a different certificate)  
would have to to *skip* implementing the protocol update, and thus  
stay vulnerable.


The new restriction that draft-ietf-tls-renegotiation-01.txt tries to  
sneak in thus seems harmful both for interoperability and for  
security.  I haven't seen any signs of working group consensus on  
including this new restriction.



Bodo




___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer Security (TLS) Renegotiation Indication Extension) to Proposed Standard

[David-Sarah Hopwood]

The IESG wrote:
> The IESG has received a request from the Transport Layer Security WG 
> (tls) to consider the following document:
> 
> - 'Transport Layer Security (TLS) Renegotiation Indication Extension '
> as a Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to the
> ietf@ietf.org mailing lists by 2009-12-14. Exceptionally, 
> comments may be sent to i...@ietf.org instead. In either case, please 
> retain the beginning of the Subject line to allow automated sorting.
> 
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-tls-renegotiation-01.txt

I believe the decision to take this draft to Last Call was premature, and
that further discussion in the WG is necessary before deciding whether to
adopt draft-ietf-tls-renegotiation or an alternative.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com



signature.asc
Description: OpenPGP digital signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Maximum Packet Size Parameter -- Re: [NSIS] Last Call: draft-ietf-nsis-qspec (QoS NSLP QSPEC Template) to Informational RFC

[Gerald Ash]

All,
 
Al Morton has recently raised concerns RE taking the Maximum Packet Size  
parameter out of the QSPEC document.  Based on his comments (given below, along 
with other background), it appears that the  parameter should be put back 
into the QSPEC.
 

Please comment on whether the  parameter should be put back into the QSPEC.
 
Thanks,
Jerry
 
Background:
 
The Maximum Packet Size Parameter  was taken out back in July 2005 in QSPEC 
version 5, with the following explanation in the change history:


 
"   Version -05:

   - discarded QSPEC parameter  (Maximum packet size) since MTU
 discovery is expected to be handled by procedure currently defined
 by PMTUD WG"
 
Some further explanation for removing the parameter  is given in a message 
posted by Cornelia Kappler on the IETF web-site at 
http://www.ietf.org/mail-archive/web/nsis/current/msg07923.html:
 
"AW: [NSIS] smallest path MTU - Maximum Packet Size [M]




To: "ext Bernd Schloer" ,  
Subject: AW: [NSIS] smallest path MTU - Maximum Packet Size [M] 
From: "Kappler, Cornelia"  
Date: Fri, 1 Jun 2007 09:53:50 +0200 
Cc: 
In-reply-to: <465c9bae.1050...@cs.uni-goettingen.de> 
List-help:  
List-id: Next Steps in Signaling  
List-post:  
List-subscribe: , 
 
List-unsubscribe: , 
 
References: <465c9bae.1050...@cs.uni-goettingen.de> 
Thread-index: AceiOM3OwdCeaEOuS267eWNZJzBL6QB6Qufg 
Thread-topic: [NSIS] smallest path MTU - Maximum Packet Size [M] 

Hi all, 

at the Interim meeting in May 2005 we decided to drop the MTU, see  
http://www.ietf-nsis.org/nsis/Munich_Interim_Meeting/MeetingMinutes.html 

Cornelia 

> -Ursprüngliche Nachricht-
> Von: ext Bernd Schloer [mailto:bschloer at cs.uni-goettingen.de] 
> Gesendet: Dienstag, 29. Mai 2007 23:31
> An: nsis at ietf.org
> Betreff: [NSIS] smallest path MTU - Maximum Packet Size [M]
> 
> Hi,
> 
> in version 13 of the QSPEC-draft the Maximum Packet Size [M] 
> was removed from the
> TMOD parameter (former Traffic parameter).
> 
> RFC2211 mentions, that links are not permitted to fragment 
> packets which receive
> the controlled-load service and packets larger than the MTU 
> of the link are treated
> as non-conformant to the TSPEC.
> 
> What was the reason to omit this parameter?
> 
> Best regards,
> Bernd"
Hannes Tschofenig kindly provided links to the Munich Interim Meeting Minutes at

http://www.tschofenig.priv.at/nsis/munich/MeetingMinutes.html
 
It appears that the discussion of MTU discovery somehow led to a conclusion 
that the maximum packet size parameter  should be eliminated as well, as 
documented in this portion of the minutes:
 
"A QoS Model for Signaling IntServ Controlled-Load Service with NSIS
===

http://www.ietf.org/internet-drafts/draft-kappler-nsis-qosmodel-controlledload-01.txt
 
Slides: 
http://www.ietf-nsis.org/nsis/Munich_Interim_Meeting/Ctrld_Load_QOSM_Interim_Munich.ppt

Cornelia Kappler presents and she starts with an overview of IntServ.

What is IntServ Controlled-Load service?
-IntServ Controlled Load Service is (in NSIS terms) a QoS Model
-RFC 2210 specifies how to signal for Controled load using RSVP
-This ID specifies how to signal for Controled Load using NSIS
-Controlled-Load Service (RFC 2211)
-Provides approximatively service of an unloaded best-effort network
-QoS parameters signaled are Token Bucket and MTU
-Implemented per "network element", i.e. per-router or per-subnet
Can be used for 
Reserving resources per-flow per-router
Admission control at edge of Diffserv domains
Admission control into MPLS clouds

How to signal for Controlled Load service with NSIS
-Role of QNEs
-One or more QNR per "network element"
-Stateless QNEs?
-Provide approximatively service of an uiloaded best-effort network may also be 
possible with stateless QNEs

Discussion started about MTU insertion in the QoS NSLP since not all routers 
would be supporting the NSIS Qos NSLP it was decided to remove the MTU 
discovery from controlled load and Qos-NSLP draft. If required MTU discovery 
would be using mechanisms out of scope of NSIS (PMTUD or other)"
 
Bernd Schloer raised the concern of eliminating  in his message referenced 
above:
 
"In version 13 of the QSPEC-draft the Maximum Packet Size [M] was removed from 
the TMOD parameter (former Traffic parameter).

RFC2211 mentions, that links are not permitted to fragment packets which 
receive the controlled-load service and packets larger than the MTU of the link 
are treated as non-conformant to the TSPEC.

What was the reason to omit this parameter?"
 
Al Morton raised the same and additional concerns in a recent discussion:
 
"It seems to me that  several points were missed
by citing the Packetization Layer Path MT

Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC

[Phillip Hallam-Baker]

I am not so sure that immediately going to PS is the best approach
considering the overall objective. My goal here would be to encourage
the widest possible adoption of the spec by equipment manufacturers.

The weakness I see in both the Microsoft and the Apple attempts to
simplify ease of net device configuration is that the use cases are
centered on the consumer with only minor consideration being given to
enterprise use. This is a poor adoption strategy as consumers do not
in general issue RFPs and thus attract rather little notice in
marketing departments. I somehow doubt that even educated consumers
will think to ask for UPnP support in a focus group.

The features that are being supported are features that are equally
important to the cost conscious enterprise. Configuration of network
devices costs far too much and is far too error prone.

90% of this proposal is equally relevant to the enterprise case. But
the multicast part is not. I have managed networks with tens, hundreds
of thousands of devices. There is no way that I am ever going to turn
on any protocol that involves broadcast or multicast as a
configuration mechanism. Rather too much of my network bandwidth is
consumed by idle chatter between machines as it is.


On the question of 'hijacking' of .local, I don't see any problem.
There is no way on earth that ICANN could possibly sell that TLD if
they tried, far too much relies on it not being routed.

I would see a problem if there was a likelihood here that we would end
up with different semantics for .local names. I don't think that is
likely to happen.

.local was set aside years ago for something of this nature, I don't
see a problem with using it here.


On Mon, Nov 30, 2009 at 1:39 PM, Stuart Cheshire  wrote:
> On 23 Nov, 2009, at 09:11, Cullen Jennings wrote:
>
>> Pretty much all the emails I have received on this have suggested we
>> should just go publish it now. To be clear, I was not talking about forming
>> a WG to go do a standards track version of this. I was talking about
>> clicking one flag in the data tracker and changing it from information to
>> standards track and publishing the draft "as is" as standards track.
>
>
> I support this, with one modification: I don't think we need to commit to
> publishing this draft literally "as is".
>
> People like Dave Cridland have pointed out legitimate style criticisms,
> which I'm happy to fix in the next couple of weeks.
>
> As I'm sure you know (but others may not) a Standards-Track RFC doesn't need
> a Working Group. It's possible to have an Individual Submission
> Standards-Track RFC, subject to the IETF community reviewing it and finding
> it to be worthwhile, and this would not be the first time I've done that.
> Last year we published RFC 5227, "IPv4 Address Conflict Detection", as an
> Individual Submission Standards-Track RFC.
>
> I think Multicast DNS easily meets criteria for Proposed Standard. In fact,
> in terms of stability, maturity, deployment, number of independent
> implementations, etc., it easily meets criteria that for other protocols
> would qualify them for Draft Standard status.
>
> When other Standards-Track RFCs and other standards bodies (ECMA, WiFi
> alliance, ISO/IEC, XMPP, etc.) need to reference Multicast DNS, having a
> Standards-Track document to reference helps avoid procedural objections.
>
> Stuart Cheshire 
> * Wizard Without Portfolio, Apple Inc.
> * Internet Architecture Board
> * www.stuartcheshire.org
>
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>



-- 
-- 
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer Security (TLS) Renegotiation Indication Extension) to Proposed Standard

[Marsh Ray]

Bodo Moeller wrote:
> 
> There is no good reason for this asymmetry of having just the client's
> verify_data in the client's message, but both the client's and the
> server's verify_data in the server's message -- the latter is pure
> overhead, both in the specification and in the on-the-wire protocol.  To
> remove the overhead from both, the second sentence should be saying,
> "For ServerHellos which are renegotiating, this field contains the
> verify_data sent by the server on the immediately previous handshake"
> (according changes to dependent parts of the specification then should
> be made).

Good point.

> For earlier Internet Drafts in the series preceding
> draft-ietf-tls-renegotiation-01.txt
> (draft-rescorla-tls-renegotiation.00.txt, etc.), a reason to keep the
> current text would have been to maintain compatibility with early
> implementations of those Internet Drafts.  However,
> draft-ietf-tls-renegotiation-01 has a newer
> TLS_RENEGO_PROTECTION_REQUEST cipher suite and thus breaks compatibility
> with those early implementations anyway.
> 
> (This means that now, changing the ServerHello extension definition as
> suggested above gives the beneficial side-effect of exposing premature
> implementations, besides merely avoiding overhead.  Those incomplete
> implementations will be more obviously incompatible because they'd still
> be using the protocol variant with overhead, instead of just differing
> subtly in the behavior if faced with TLS_RENEGO_PROTECTION_REQUEST.)

I don't think any of those implementations have shipped, and I don't
think anyone has advertised that code as anything but experimental.

It might not hurt for the IANA to assign a different number to the
extension than what was used for testing.

> 2. The Security Considerations section of
> draft-ietf-tls-renegotiation-01.txt (section 7) includes language that
> unnecessarily restricts the flexibility that the TLS protocol
> specifically provides for, regulating areas that the TLS standard
> intentionally does not specify (RFC 5246 section 1) -- the current
> Internet Draft says:
> 
> "By default, TLS implementations conforming to this document MUST verify
> that once the peer has been identified and authenticated within the TLS
> handshake, the identity does not change on subsequent renegotiations.
> For certificate based cipher suites, this means bitwise equality of the
> end-entity certificate. If the other end attempts to authenticate with a
> different identity, the renegotiation MUST fail. If the server_name
> extension is used, it MUST NOT change when doing renegotiation."
> 
> There is no security reason for this restriction.

+1 Agree

> This sounds like a
> bad and incomplete workaround for certain problems with TLS that the
> updated protocol does not need a workaround for at all, because the
> protocol update is all about properly *solving* those problems.
> 
> Keeping this language in the specification would have the weird
> implication that applications that *need* the flexibility provided by
> the TLS protocol (e.g., to allow renegotiation handshakes to switch to a
> different ciphersuite, which may require a different certificate) would
> have to to *skip* implementing the protocol update, and thus stay
> vulnerable.

Excellent point.

Although the sentence after the one you quoted seems to say that
implementations are allowed to do it anyway if they choose. Which raises
the question as to what this language actually means for the wire
protocol, anyway.

> The new restriction that draft-ietf-tls-renegotiation-01.txt tries to
> sneak in thus seems harmful both for interoperability and for security. 
> I haven't seen any signs of working group consensus on including this
> new restriction.

Details about which certificates endpoints should be allowed or
forbidden to negotiate is outside the scope of this bugfix.

We should remove it.

- Marsh

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer Security (TLS) Renegotiation Indication Extension) to Proposed Standard

[Nasko Oskov]

Bodo Moeller wrote:
>On Nov 30, 2009, at 4:37 PM, The IESG wrote:
>
>> The IESG has received a request from the Transport Layer Security WG
>> (tls) to consider the following document:
>>
>> - 'Transport Layer Security (TLS) Renegotiation Indication Extension '
>>as a Proposed Standard
>>
>> The IESG plans to make a decision in the next few weeks, and solicits 
>> final comments on this action.  Please send substantive comments to 
>> the ietf@ietf.org mailing lists by 2009-12-14.
>
>I support the move, contingent to two clean-ups to specified behavior:

I support the 01 version of the draft, assuming we address this point:

>2. The Security Considerations section of draft-ietf-tls-
>renegotiation-01.txt (section 7) includes language that unnecessarily
>restricts the flexibility that the TLS protocol specifically provides for,
>regulating areas that the TLS standard intentionally does not specify (RFC
>5246 section 1) -- the current Internet Draft says:
>
>"By default, TLS implementations conforming to this document MUST verify
>that once the peer has been identified and authenticated within the TLS
>handshake, the identity does not change on subsequent renegotiations. For
>certificate based cipher suites, this means bitwise equality of the
>end-entity certificate. If the other end attempts to authenticate with a
>different identity, the renegotiation MUST fail. If the server_name
>extension is used, it MUST NOT change when doing renegotiation."
>
>There is no security reason for this restriction.  This sounds like a bad
>and incomplete workaround for certain problems with TLS that the updated
>protocol does not need a workaround for at all, because the protocol update
>is all about properly *solving* those problems.

I agree that this restriction is not necessary for solving the current
problem. If the section should stay, I would vote for making it a SHOULD and
definitely not a MUST.

>Keeping this language in the specification would have the weird implication
>that applications that *need* the flexibility provided by the TLS protocol
>(e.g., to allow renegotiation handshakes to switch to a different
>ciphersuite, which may require a different certificate) would have to to
>*skip* implementing the protocol update, and thus stay vulnerable.

What about certificate renewal? Once a cert is renewed, it is different when
it comes to bitwise comparison, yet it is the same identity. I do not think
doing bitwise comparisons and dealing with identity at the TLS layer should
be part of this draft.

Nasko
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport LayerSecurity (TLS) Renegotiation Indication Extension) toProposed Standard

[Rob P Williams]

I support this draft.

-Original Message-
From: tls-boun...@ietf.org [mailto:tls-boun...@ietf.org] On Behalf Of
The IESG
Sent: Monday, November 30, 2009 10:38 AM
To: IETF-Announce
Cc: t...@ietf.org
Subject: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport
LayerSecurity (TLS) Renegotiation Indication Extension) toProposed
Standard

The IESG has received a request from the Transport Layer Security WG 
(tls) to consider the following document:

- 'Transport Layer Security (TLS) Renegotiation Indication Extension '
as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf@ietf.org mailing lists by 2009-12-14. Exceptionally, 
comments may be sent to i...@ietf.org instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-tls-renegotiation-01.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=
19412&rfc_flag=0

___
TLS mailing list
t...@ietf.org
https://www.ietf.org/mailman/listinfo/tls

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport LayerSecurity (TLS) Renegotiation Indication Extension) to Proposed Standard

[Joseph Salowey (jsalowey)]

I disagree that the last call is premature.  I realize that not everyone
is happy with all aspects of the current document but a clear majority
of people on the TLS list have voiced their support for it.  I do not
see any consensus that the existing approach is flawed, nor do I see
evidence of an emerging consensus on an alternative approach. 

This document fixes a serious security hole in TLS and so it is
important to finish it in a timely manner. While a minority of the WG
may feel that it this draft isn't exactly the way it would like, it does
address the relevant security issue. I don't feel that waiting several
more weeks to see if consensus forms around some other approach is
likely to be useful.

Joe
(Speaking as TLS Working Group Co-Chair)

> -Original Message-
> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On 
> Behalf Of Yoav Nir
> Sent: Tuesday, December 01, 2009 2:06 AM
> To: ietf@ietf.org
> Cc: t...@ietf.org Group
> Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation 
> (Transport LayerSecurity (TLS) Renegotiation Indication 
> Extension) to Proposed Standard
> 
> 
> On Nov 30, 2009, at 5:37 PM, The IESG wrote:
> 
> > The IESG has received a request from the Transport Layer Security WG
> > (tls) to consider the following document:
> > 
> > - 'Transport Layer Security (TLS) Renegotiation Indication 
> Extension '
> >as a Proposed Standard
> > 
> > The IESG plans to make a decision in the next few weeks, 
> and solicits 
> > final comments on this action.  Please send substantive comments to 
> > the ietf@ietf.org mailing lists by 2009-12-14. 
> Exceptionally, comments 
> > may be sent to i...@ietf.org instead. In either case, please retain 
> > the beginning of the Subject line to allow automated sorting.
> 
> I oppose publishing the current draft. 
> 
> There are two unresolved issues still being discussed on the 
> TLS mailing list: 
>  1. non-extension signaling for older versions (SSLv3 and 
> maybe TLS 1.0)  2. explicit vs implicit addition of old 
> verify_data to the PRF (also known as fail-unsafe vs fail-safe)
> 
> I think the WG is converging, and that a couple of more weeks 
> of discussion may lead to consensus. 
> 
> I agree with David-Sarah Hopwood that a last call (WG or 
> IETF) is still premature.
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
> 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer Security (TLS) Renegotiation Indication Extension) to Proposed Standard

[Stefan Santesson]

On 09-12-01 12:19 AM, "David-Sarah Hopwood" 
wrote:

> The IESG wrote:
>> The IESG has received a request from the Transport Layer Security WG
>> (tls) to consider the following document:
>> 
>> - 'Transport Layer Security (TLS) Renegotiation Indication Extension '
>> as a Proposed Standard
>> 
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action.  Please send substantive comments to the
>> ietf@ietf.org mailing lists by 2009-12-14. Exceptionally,
>> comments may be sent to i...@ietf.org instead. In either case, please
>> retain the beginning of the Subject line to allow automated sorting.
>> 
>> The file can be obtained via
>> http://www.ietf.org/internet-drafts/draft-ietf-tls-renegotiation-01.txt
> 
> I believe the decision to take this draft to Last Call was premature, and
> that further discussion in the WG is necessary before deciding whether to
> adopt draft-ietf-tls-renegotiation or an alternative.

I agree to this.

I will support the current draft-ietf-tls-renegotiation-01 if that is choice
of direction in the end of this last call.

However, the TLS working group has also been working hard to evaluate
whether an alternative solution could provide better integration with legacy
deployments and provide better security properties.

This last call was initiated before the WG members had any real chance to
express their choice of direction.

For the sake of completeness, the alternative approach was updated and
posted today and is available from:
http://tools.ietf.org/html/draft-mrex-tls-secure-renegotiation-02

It is my opinion that this draft offers two noticeable advantages over
draft-ietf-tls-renegotiation-01

1) By not sending verify data over the wire, this draft allows peers to
fail-safe as a result of implementation errors in cases where a
corresponding implementation error of draft-ietf-tls-renegotiation-01 leads
to a fail-unsafe situation.

2) It offers a solution where servers never have to parse data from TLS
extensions. This offers advantages when deploying the fix for legacy
implementations.


I would support if the choice of draft-mrex-tls-secure-renegotiation-02 as
the selected solution to the problem, or an update of
draft-ietf-tls-renegotiation-01 which incorporate the updated handshake
message hash calculation of draft-mrex-tls-secure-renegotiation-02 as an
alternative to sending verify data in the RI extensions.

/Stefan
 


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

'3GPP QoS Model for Networks Using 3GPP QoS Classes

[Karthik Balaguru]

Hi,
I find only the draft version of draft-jeong-nsis-3gpp-qosm-02.txt .
What is the latest development w.r.t '3GPP QoS Model for Networks Using 3GPP
QoS Classes'.
Any other related/alternative RFC available for this ?

Thx in advans,
Karthik Balaguru
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: RIM patents using a mime body in a message (and ignores IETF IPR rules)

[Brian E Carpenter]

On 2009-12-01 23:57, Simon Josefsson wrote:
> Scott Brim  writes:
> 
>> Simon Josefsson allegedly wrote on 11/30/2009 10:11 AM:
>>> There is no requirement in the IETF process for organizations to
>>> disclose patents as far as I can see.  The current approach of only
>>> having people participate, and disclose patents, in the IETF is easy to
>>> work around by having two persons in an organization doing different
>>> things: one works on specifying and standardizing technology, and the
>>> other is working on patenting the technology.
>> Simon, from rfc3979:
>>
>>l. "Reasonably and personally known": means something an individual
>>   knows personally or, because of the job the individual holds,
>>   would reasonably be expected to know.  This wording is used to
>>   indicate that an organization cannot purposely keep an individual
>>   in the dark about patents or patent applications just to avoid the
>>   disclosure requirement.  But this requirement should not be
>>   interpreted as requiring the IETF Contributor or participant (or
>>   his or her represented organization, if any) to perform a patent
>>   search to find applicable IPR.
> 
> I don't see how this modifies anything?  The legal obligation is on the
> IETF participant, not on the organization.  The organization is not
> bound by this text.

IANAL. But if the participant is acting as an agent of the employer,
it seems to me that the employer is bound. In any case, you'd have to be
a brave or reckless employee not to assume that to be the case. You'd also
have to be a very obtuse employer to fund your employees to participate
if you didn't like the IETF's rules.

At least, that's how it's worked for the last 12 or 13 years.

Brian

Brian


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC

[Andrew Sullivan]

Dear colleagues,

I have read draft-cheshire-dnsext-multicastdns-08.  I have some
comments.  This is not an exhaustive or complete review, although I
have shared some previous observations with the authors of the
document.

First, I must emphasise that, while I currently serve as one of the
chairs of the DNS Extensions Working Group, I make my comments as an
individual and not as Chair.  Neither do I in any way speak for the
community or the Working Group.  I also want to emphasise that I was
not involved in the early history of this draft, and had no official
responsibilities of any sort to the DNSEXT WG when this draft came
under discussion there some years ago.

Given the long and painful history of the draft, and that the protocol
it documents is manifestly successful and in wide use, I think it
would be a disservice to interoperability if we did not publish it.
If for no other reason, I support its publication (under the terms of
the question put to us) as an Informational RFC.

I think there are sections of the text that could be cleaned up.
Leaving aside others' complaints about the number of Apple references
in the document, there is a querulousness to the text that is a little
jarring.  Sentences like "It is easy for those of us in the IETF
community who run our own name servers at home to forget that the
majority of computer users do not run their own name server and have
no easy way to create their own host names," despite their evident
truth and probable justification in light of some past comment on a
mailing list, just aren't needed in a protocol document.  If it were
up to me, I'd take that sort of thing out.  That said, I do not
withold my support on this basis.

The IANA Considerations section is a little coy in the way it notes
that the document reserves .local.  Moreover, the action is not merely
to IANA, but strictly to ICANN, and I worry about the procedural rules
for such an action.  If there is a strong reason to put this document
on the standards track, the use of .local is surely it.

I like the way the document emphasises that, in a multicast
environment, many of the assumptions one might make about uniqueness
are wrong.  I think this is quite right, and I hope clients and
implementers will take heed.  

The discussion of port 5353 vs. 53 is comprehensive without rehashing
the entire history of that debate.  (Contrast this with my previous
comment about querulous bits of the text.  One can outline the
background without sounding annoyed by snipers.)

I am unwilling right now to make an argument in favour or against
moving this document to the standards track.  I think there are
arguments to be constructed in both directions, but when I consider
the value to interoperability, it seems to me that getting something
published, even in a flawed way, is more important than picking
exactly the right document stream.

Best regards,

A
-- 
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC

[SM]

At 14:29 01-12-2009, Andrew Sullivan wrote:

The IANA Considerations section is a little coy in the way it notes
that the document reserves .local.  Moreover, the action is not merely
to IANA, but strictly to ICANN, and I worry about the procedural rules
for such an action.  If there is a strong reason to put this document
on the standards track, the use of .local is surely it.


Quoting Section 3.1:

  "Note that this use of the ".local." suffix falls under IETF/IANA
  jurisdiction, not ICANN jurisdiction."

This draft mentions that the IETF has the authority to instruct IANA 
to reserve pseudo-TLDs as required for protocol design 
purposes.  There is no action requested from IANA for ".local" in the 
IANA Considerations section.


  "In contrast, private uses of the DNS protocol on isolated private
   networks are not governed by ICANN. Since this change is a change
   to the core DNS protocol rules, it affects everyone, not just those
   machines using the ICANN-governed Internet."

Is any other use of the DNS protocol governed by ICANN?

Could the authors please drop the reference to the ICANN-governed 
Internet?  I suggest dropping Section 3.1 as it is not the type of 
content generally discussed in an Informational document.


In Section 6.3:

  "iTunes users are accustomed to seeing a list of shared network music
   libraries in the sidebar of the iTunes window. There is no "refresh"
   button for the user to click because the list is expected to be
   always accurate, always reflecting the currently available libraries,
   without the user having to take any manual action to keep it that
   way. When a new library becomes available it promptly appears in the
   list, and when a library becomes unavailable it promptly disappears.
   It is vitally important that this responsive user interface be
   achieved without naive polling that would place an unreasonable
   burden on the network."

The above is superfluous.

In Section 15:

  "A host SHOULD defend its host name (FQDN) on all active interfaces on
   which it is answering Multicast DNS queries."

What does that mean?

In Section 17:

 "Set-top boxes (e.g. Apple's "Apple TV") connected to a television
  can play music, photographic slide shows, and movies stored on the
  user's desktop computer (e.g. an iMac running iTunes) -- but only
  if that desktop computer is not asleep."

  "Services like Apple's "Back to My Mac" allow users to access data
  on their home computers from remote locations, using screen
  sharing or file sharing -- but only if their computer at home
  is not asleep."

Could the authors please remove such references?

Regards,
-sm 


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

NOT RECOMMENDED (was: Re: [TLS] Last Call: draft-ietf-tls-renegotiation)

[Peter Saint-Andre]

On 12/1/09 7:49 PM, Martin Rex wrote:
> Stephen Farrell wrote:
>> 7. 6.2 says: "If servers wish to <> they MUST
>> NOT <>" Isn't that equivalent to servers SHOULD
>> NOT? I think a SHOULD NOT is better. (And that's the form
>> used in section 7.)
> 
> 
> This might be confusion with ISO terminology.
> 
>MUST   ==  SHALL
>MUST NOT   ==  SHALL NOT
>SHOULD ==  RECOMMENDED
>SHOULD NOT ==  NOT RECOMMENDED
> 
> 
>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>document are to be interpreted as described in RFC 2119 [RFC2119].

It's always puzzled me why the boilerplate quoted above does not include
the phrase "NOT RECOMMENDED", given that RFC 2119 mentions it a mere
five paragraphs later:

   4. SHOULD NOT  This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.

Is this a spec bug in RFC 2119?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/




smime.p7s
Description: S/MIME Cryptographic Signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: NOT RECOMMENDED (was: Re: [TLS] Last Call:draft-ietf-tls-renegotiation)

[Dan Wing]

 

> -Original Message-
> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On 
> Behalf Of Peter Saint-Andre
> Sent: Tuesday, December 01, 2009 7:06 PM
> To: m...@sap.com
> Cc: ietf@ietf.org
> Subject: NOT RECOMMENDED (was: Re: [TLS] Last 
> Call:draft-ietf-tls-renegotiation)
> 
> On 12/1/09 7:49 PM, Martin Rex wrote:
> > Stephen Farrell wrote:
> >> 7. 6.2 says: "If servers wish to <> they MUST
> >> NOT <>" Isn't that equivalent to servers SHOULD
> >> NOT? I think a SHOULD NOT is better. (And that's the form
> >> used in section 7.)
> > 
> > 
> > This might be confusion with ISO terminology.
> > 
> >MUST   ==  SHALL
> >MUST NOT   ==  SHALL NOT
> >SHOULD ==  RECOMMENDED
> >SHOULD NOT ==  NOT RECOMMENDED
> > 
> > 
> >The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 
> "SHALL NOT",
> >"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 
> "OPTIONAL" in this
> >document are to be interpreted as described in RFC 2119 
> [RFC2119].
> 
> It's always puzzled me why the boilerplate quoted above does 
> not include
> the phrase "NOT RECOMMENDED", given that RFC 2119 mentions it a mere
> five paragraphs later:
> 
>4. SHOULD NOT  This phrase, or the phrase "NOT 
> RECOMMENDED" mean that
>there may exist valid reasons in particular circumstances when the
>particular behavior is acceptable or even useful, but the full
>implications should be understood and the case carefully weighed
>before implementing any behavior described with this label.
> 
> Is this a spec bug in RFC 2119?

Probably.

According to
http://www.rfc-editor.org/errata_search.php?rfc=2119
it was reported as Errata ID 499 by Anders Langmyr on 2006-01-09.

-d


> Peter
> 
> -- 
> Peter Saint-Andre
> https://stpeter.im/
> 
> 
> 

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-tls-renegotiation (Transport Layer Security (TLS) Renegotiation Indication Extension) to Proposed Standard

[Chris Newman]

I strongly support publishing this draft either in its present form or with 
any modification that does not impact the protocol's security analysis.


This the most time-sensitive and security-critical IETF draft with respect 
to impact on the Internet community that I have seen in 17 years of IETF 
participation.  As such, I strongly support the decision to start IETF last 
call early as permitted by RFC 2418 section 7.4.  I also encourage the IESG 
to move this document to the front of the queue for all support 
organizations (Secretariat, IANA, RFC editor) when processing occurs and to 
avoid holding a blocking DISCUSS after the telechat unless that blocking 
issue is more serious than the ongoing presence of this TLS security 
vulnerability on the Internet.



===
Three changes to draft-ietf-tls-renegotiation-01 I consider important (but 
not blocking):


* The header should explicitly state it Updates RFC 5246, 4346, 4366, 2246. 
This
 gets forward pointers in the RFC index to increase chances implementers 
of those
 specs will also find this one.  This is also necessary for RFC 5246 as 
this creates

 an exception to a MUST NOT.

* There is an error-of-fact in the introduction; this is incorrect:
"   If certificate-based client authentication is used, the server will
  believe that the initial traffic corresponds to the authenticated
  client identity."
This statement is true only for application protocols with a badly designed 
state transition from unauthenticated to authenticated state.  That is 
primarily limited to HTTPS and protocols based on HTTPS.  It is not true 
for most other IETF application protocols including SMTP, POP, IMAP, LDAP, 
NNTP, BEEP and XMPP (however, I suspect all of these are impacted by the 
TLS vulnerability in other ways).  Changing "is used" to "is used with 
HTTPS" would correct the error.


* Nomenclature: when discussing TLS_RENEGO_PROTECTION_REQUEST, the term 
"cipher suite value" needs to be used instead of "cipher suite", and the 
text needs to explicitly state that TLS_RENEGO_PROTECTION_REQUEST is not a 
cipher suite (it is not sufficient to say it can't be negotiated).  This is 
important for evaluating implementations against government standards that 
dictate which cipher suites an implementation may advertise.


Evaluation relative to draft-mrex-tls-secure-renegotiation-03:

Kudos to Martin Rex for producing such a good alternate proposal.  The 
introductory text up to and including section 4.1 is very good and would 
improve draft-ietf-tls-renegotiation.  While I would support a consensus to 
publish the mrex document as the solution, I presently prefer 
draft-ietf-tls-renegotiation-01 for four reasons:
1. Running code: multiple implementations and interop testing was performed 
on an

  earlier version of draft-ietf-tls-renegotiation.
2. Impact to core protocol handshake: The mrex proposal alters the 
handshake to include
  data that is not exchanged in-protocol.  If this impacts PKCS#11 
hardware tokens or
  other SSL accelerators (an issue mentioned by Dr Stephen Henson on the 
TLS list on
  Nov 26, 2009 19:24:55 +) that could severely impact deployment.  I 
do not know
  if that concern applies to the mrex proposal, but I know it does not 
apply to the
  draft-ietf-tls-renegotiation.  The point being the mrex proposal 
requires more analysis
  to verify impact.  As we're in a hurry, I prefer to easier to analyze 
proposal.
3. Extensibility.  In my experience one of the protocol design features 
most important to
  get right is extensibility.  SSL/TLS didn't really get that right until 
v1.2 (which is
  causing problems now).  As draft-ietf-tls-renegotiation uses the TLS 
extension
  facility more extensively, it will help future-proof more 
implementations.
4. The mrex proposal requires use of TLS_RENEGO_PROTECTION_REQUEST in some 
circumstances.
  That approach is untested in the field and I have concerns it will 
negatively impact
  middleboxes.  As draft-ietf-tls-renegotiation allows use of either the 
cipher suite
  value or the extension for C->S signaling, that mitigates the concern -- 
the field

  can choose the mechanism that works best.

My take on some controversial issues:

* There may not be a sufficient number of "extension intolerant" SSL/TLS 
servers in operation to justify the added complexity of 
TLS_RENEGO_PROTECTION_REQUEST.  However, I do not object to inclusion as 
it's possibly helpful for some alleged extension intolerant servers 
compliant with early drafts of SSLv3 and it helped move closer to WG 
consensus.


* I believe Bodo Moeller's proposal to exclude client's verify_data from 
ServerHello improves the protocol, but I do not find it a blocking or 
compelling issue.


* I find the present text in security considerations on identity change 
mid-stream acceptable from my perspective as an application developer. 
However, I do not care if that text is included or excluded from the 
approved version as it is ancillary to the