Re: [TLS] [Gen-art] Genart last call review of draft-ietf-tls-oldversions-deprecate-09

[Alissa Cooper]

Mohit, thanks for your review. Stephen, thanks for your response. I entered a 
Yes ballot.

Alissa

> On Nov 25, 2020, at 6:47 AM, Stephen Farrell  
> wrote:
> 
> 
> 
> On 25/11/2020 11:46, Mohit Sethi via Datatracker wrote:
>> Reviewer: Mohit Sethi
>> Review result: Ready
> 
> Thanks. Will look at those nits when next editing.
> 
> Cheers,
> S.
> 
>> I am the assigned Gen-ART reviewer for this draft. The General Area
>> Review Team (Gen-ART) reviews all IETF documents being processed
>> by the IESG for the IETF Chair.  Please treat these comments just
>> like any other last call comments.
>> For more information, please see the FAQ at
>> .
>> Document: draft-ietf-tls-oldversions-deprecate-09
>> Reviewer: Mohit Sethi
>> Review Date: 2020-11-25
>> IETF LC End Date: 2020-11-30
>> IESG Telechat date: Not scheduled for a telechat
>> Summary: This document deprecates older versions of TLS and DTLS. It also
>> updates many RFCs that normatively refer to the older TLS/DTLS versions.
>> Major issues: None
>> Minor issues: None
>> Nits/editorial comments: In section 1.1, typo in "waas defined to detect".
>> Most references to RFCs are of the form "[RFC7507]". Can we change "RFC 7457
>> [RFC7457]" to "[RFC7457]" for uniformity. Similarly, perhaps you could change
>> "RFC5246 [RFC5246]" and "RFC4346 [RFC4346]" to "[RFC5246]" and "[RFC4346]".
>> In section 2 "NIST for example have provided " should be "..has provided...".
>> In section 6 "this document is called out specifically to update text
>> implementing the deprecation  recommendations of this document." I was
>> initially confused with the repeated usage of "this". Perhaps it would help 
>> to
>> be more explicit.
> ___
> Gen-art mailing list
> gen-...@ietf.org 
> https://www.ietf.org/mailman/listinfo/gen-art 
> 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Gen-art] Genart last call review of draft-ietf-tls-ticketrequests-06

[Alissa Cooper]

Dale, thanks for your review. Chris, thanks for addressing Dale’s comments. I 
entered a No Objection ballot.

Alissa


> On Dec 3, 2020, at 10:22 PM, Christopher Wood  wrote:
> 
> Thanks for the feedback, Dale! We addressed your comments and updated the 
> draft. The diff is available here:
> 
>   
> https://tools.ietf.org/rfcdiff?difftype=--hwdiff=draft-ietf-tls-ticketrequests-07.txt
> 
> Best,
> Chris
> 
> On Fri, Nov 27, 2020, at 7:54 PM, Dale Worley via Datatracker wrote:
>> Reviewer: Dale Worley
>> Review result: Ready
>> 
>> I am the assigned Gen-ART reviewer for this draft. The General Area
>> Review Team (Gen-ART) reviews all IETF documents being processed
>> by the IESG for the IETF Chair.  Please treat these comments just
>> like any other last call comments.
>> 
>> For more information, please see the FAQ at
>> 
>> .
>> 
>> Document:  draft-ietf-tls-ticketrequests-06
>> Reviewer:  Dale R. Worley
>> Review Date:  2020-11-27
>> IETF LC End Date:  2020-12-03
>> IESG Telechat date:  Not known
>> 
>> Summary:
>> 
>>This draft is ready for publication as a Standards Track RFC.
>> 
>> Editorial comments:
>> 
>> 2.  Use Cases
>> 
>>   *  Parallel HTTP connections: To minimize ticket reuse while still
>>  improving performance, it may be useful to use multiple, distinct
>>  tickets when opening parallel connections.
>> 
>> To the naive reader, the ordering of the phrases doesn't seem to match
>> the logical ordering of the concepts.  Perhaps
>> 
>>   *  Parallel HTTP connections: To improve performance, a client
>>  may open parallel connections.  To avoid ticket reuse, the client
>>  may use multiple, distinct tickets on each connection.
>> 
>> --
>> 
>>   *  Decline resumption: Clients can indicate they have no intention of
>>  resuming connections by sending a ticket request with count of
>>  zero.
>> 
>> "have no intention" seems to me to suggest a decision that will not
>> change.  Since the future cannot be guaranteed, perhaps better wording
>> is "do not intend to resume", suggesting a current state that might
>> possibly change in the future.
>> 
>>   new_session_count  The number of tickets desired by the client when
>>  the server chooses to negotiate a new connection.
>> 
>>   resumption_count  The number of tickets desired by the client when
>>  the server is willing to resume using a ticket presented in this
>>  ClientHello.
>> 
>> If I understand the processing which is suggested correctly, when the
>> client sends a ClientHello, the server can choose to either negotiate
>> a new connection, or (if a ticket is present in the ClientHello) the
>> server can choose to resume the previous connection represented by the
>> ticket.  These two parameters provide the requested ticket count for
>> the two situations.
>> 
>> Assuming the above is correct, I would recommend changing the wording
>> slightly, as "when" suggests a fact which is true over an extended
>> period of time, whereas the provided counts are applicable in just this
>> one instance:
>> 
>>   new_session_count  The number of tickets desired by the client if
>>  the server chooses to negotiate a new connection.
>> 
>>   resumption_count  The number of tickets desired by the client if
>>  the server chooses to resume (using the ticket presented in this
>>  ClientHello).
>> 
>> (Change "the" to "a" in the last sentence if the ClientHello can
>> present more than one ticket among which the server can choose.)
>> 
>> [END]
>> 
>> 
>> 
>> 
> 
> ___
> Gen-art mailing list
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

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

[TLS] Alissa Cooper's No Objection on charter-ietf-tls-05-03: (with COMMENT)

[Alissa Cooper via Datatracker]

Alissa Cooper has entered the following ballot position for
charter-ietf-tls-05-03: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-tls/



--
COMMENT:
--

Would be nice to see milestones.



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

Re: [TLS] Alissa Cooper's No Objection on draft-ietf-tls-tls13-cert-with-extern-psk-04: (with COMMENT)

[Alissa Cooper]

Hi Russ,

> On Dec 19, 2019, at 10:08 AM, Russ Housley  wrote:
> 
> Alissa:
> 
>> --
>> COMMENT:
>> --
>> 
>> Building on a point Barry made, I think it would be useful to distinguish in
>> the document whether this spec is experimental because we are waiting for
>> quantum computers to materialize, or whether it is experimental because 
>> current
>> implementors want to gain more experience with it before standardization. 
>> That
>> way if it does come back at some future point on the standards track the
>> context for why it was experimental in the first place will be there.
> 
> There was a lot of discussion in the TLS WG, and several implementors wanted 
> to gain more experience with the specification before producing a 
> standards-track RFC.  I am not sure that really helps if this document comes 
> back in the future.

I’m quite sure that it would, given that most of the time when the IESG reviews 
a document that is being promoted from experimental to standards track there is 
some discussion about why that is happening. The more that can be done to 
explain the context for the original classification, the better, because then 
readers do not have to guess. Asking future reviewers to re-read the TLS 
mailing list from X number of years ago is suboptimal compared to having one 
sentence in the document that explains this. As currently written, I think 
people could conclude that this document is experimental because large-scale 
quantum computers do not yet exist.

Best,
Alissa

> 
>> Please respond to the Gen-ART reviewer.
> 
> I have done so.
> 
> Russ
> 

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

Re: [TLS] [Gen-art] Genart last call review of draft-ietf-tls-tls13-cert-with-extern-psk-03

[Alissa Cooper]

Ines, thanks for your review. I entered a No Objection ballot.

Alissa


> On Dec 2, 2019, at 6:59 PM, Ines Robles via Datatracker  
> wrote:
> 
> Reviewer: Ines Robles
> Review result: Ready
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-tls-tls13-cert-with-extern-psk-??
> Reviewer: Ines Robles
> Review Date: 2019-12-02
> IETF LC End Date: 2019-12-02
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary:
> 
> The document is well written.
> 
> This document specifies a TLS 1.3 extension permitting certificate-based 
> server
> authentication to be combined with an external PSK as an input to the TLS 1.3
> key schedule.
> 
> Major issues: Not found
> 
> Minor issues: Not found
> 
> Nits/editorial comments:
> 
> I think that would be nice to add in IANA Considerations a table specifying 
> the
> fields of the TLS ExtensionType Values indicated in
> https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml
> 
> Thank you for this document,
> 
> Ines.
> 
> 
> ___
> Gen-art mailing list
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

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

[TLS] Alissa Cooper's No Objection on draft-ietf-tls-tls13-cert-with-extern-psk-04: (with COMMENT)

[Alissa Cooper via Datatracker]

Alissa Cooper has entered the following ballot position for
draft-ietf-tls-tls13-cert-with-extern-psk-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk/



--
COMMENT:
--

Building on a point Barry made, I think it would be useful to distinguish in
the document whether this spec is experimental because we are waiting for
quantum computers to materialize, or whether it is experimental because current
implementors want to gain more experience with it before standardization. That
way if it does come back at some future point on the standards track the
context for why it was experimental in the first place will be there.

Please respond to the Gen-ART reviewer.


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

Re: [TLS] [Gen-art] Genart last call review of draft-ietf-tls-certificate-compression-07

[Alissa Cooper]

Peter, thanks for your review. I entered a No Objection ballot.

Alissa


> On Dec 9, 2019, at 5:10 PM, Peter Yee via Datatracker  
> wrote:
> 
> Reviewer: Peter Yee
> Review result: Ready
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-tls-certificate-compression-07
> Reviewer: Peter Yee
> Review Date: 2019-12-09
> IETF LC End Date: 2019-12-09
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: This draft specifies a means to negotiate and carry a compressed
> certificate chain for use in TLS 1.3.  The document is clear and 
> well-written. 
> It's ready for publication as a Standards Track RFC, although the Secdir 
> review
> raises interesting points that ought to be considered before moving forward. 
>> From a general perspective, this draft appears to be useful extension to TLS
> 1.3. [Ready]
> 
> Major issues: None
> 
> Minor issues: None
> 
> Nits/editorial comments: None
> 
> 
> ___
> Gen-art mailing list
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

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

[TLS] Alissa Cooper's No Objection on draft-ietf-tls-certificate-compression-08: (with COMMENT)

[Alissa Cooper via Datatracker]

Alissa Cooper has entered the following ballot position for
draft-ietf-tls-certificate-compression-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-certificate-compression/



--
COMMENT:
--

Section 3: Please add RFC citations for TLS 1.3 and TLS 1.2 on first use.


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

[TLS] Alissa Cooper's No Objection on draft-ietf-tls-sni-encryption-05: (with COMMENT)

[Alissa Cooper via Datatracker]

Alissa Cooper has entered the following ballot position for
draft-ietf-tls-sni-encryption-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/



--
COMMENT:
--

Section 1:

s/servers rely on the Service Name Information (SNI) TLS extension/servers rely
on the Server Name Indication (SNI) TLS extension [RFC 6066]/

Section 2.1:

Why is parental controls in quotes?

Section 2.2:

s/Encrypting the SNI now will complete this push/Encrypting the SNI completes
this push/

(for timelessness)

Section 2.3:

In the first paragraph I would suggest trying to use the present tense more so
that this still makes sense far in the future.

s/At the moment/At the time of this writing/


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

Re: [TLS] [Gen-art] Genart last call review of draft-ietf-tls-iana-registry-updates-04

[Alissa Cooper]

Stewart, thanks for your review. Sean, thanks for the updates. I have entered a 
No Objection ballot.

Alissa

> On Feb 27, 2018, at 2:22 PM, Sean Turner  wrote:
> 
> 
> 
>> On Feb 27, 2018, at 11:21, Russ Housley  wrote:
>> 
>> 
 Minor issues:
 
 I think convention is to list the documents being updated in the Abstract, 
 but
 cannot find any formal guidance.
>>> 
>>> You’re right that is the convention, but it’s not required.  
>>> draft-flanagan-7322bis is attempting to make including updates in the 
>>> abstract a must, but it’s not been through any kind of LC yet.  There is a 
>>> sentence there saying that a lot of RFCs are updated and to see the updates 
>>> header so I think under the 7322 to balance concise and to not include 
>>> references I’m thinking this is okay.
>>> 
>> 
>> If another update top the document is needed, then it does not seem hard to 
>> comply with the coming convention.
> 
> Just an FYI I plan to object to the coming convention :)
> 
>> ==
 
 If an item is marked as not recommended it does not necessarily mean
 SB> Do you mean "marked as not recommended" or "not marked as recommended”.
>>> 
>>> There are two states for the Recommended column: YES and NO.  I can go 
>>> either way on whether
>>> marked as not recommended = NO
>>> not marked as recommended = NO
>>> 
>>> WG - thoughts?
>> 
>> I think the second wording is more clear.
> 
> fixed
> 
 ===
 SB>  I am worried about the semantics of Recommended = no.
 SB> Presumably there are three states: recommended, not recommended,
 SB> and silent/don't know/don't care/not yet. Which of these
 SB> states does Recommended = no represent?
>>> 
>>> There are two states and a draft that specifies a value in a registry that 
>>> has a Recommended column needs to state which it is.  I’m not too concerned 
>>> because we can change the column value later if it turns out a NO should 
>>> have been a YES.
>> 
>> It would be more clear is Section 6 said that each parameter will have 
>> either "yes" or "no" in the new recommended column.
> 
> Can do:
> 
> OLD:
> 
>  The instructions in this document add a Recommended column to many of the
>  TLS registries
> 
> NEW:
> 
>  The instructions in this document add a Recommended column with a value
>  of YES or NO to many of the (D)TLS registries
> 
> PR: https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/63
> ___
> Gen-art mailing list
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

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

[TLS] Alissa Cooper's Yes on draft-ietf-tls-tls13-26: (with COMMENT)

[Alissa Cooper]

Alissa Cooper has entered the following ballot position for
draft-ietf-tls-tls13-26: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/



--
COMMENT:
--

I found this document to be clear despite its length and complexity. The
Gen-ART reviewer wrote a lengthy review that I encourage the author/WG to look
at. Many of his comments relate to stylistic preferences in the text and some
of them might have been more actionable earlier in the process (e.g., the
suggestion for a minor error code, which I like but wouldn't hold this up
over), but they are worth reviewing. For example, I was also confused about the
use of "fatal alert" versus "error alert," and I also found the invocation of
the SNI check in 4.6.1 to be introduced abruptly.


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

Re: [TLS] [Gen-art] Genart telechat review of draft-ietf-tls-dnssec-chain-extension-06

[Alissa Cooper]

Matt, thanks for your review. Shumon, thanks for your response. I have entered 
a No Objection ballot.

Alissa

> On Feb 6, 2018, at 11:31 PM, Shumon Huque  wrote:
> 
> On Tue, Feb 6, 2018 at 8:25 PM, Matthew Miller 
> > 
> wrote:
> Reviewer: Matthew Miller
> Review result: Ready with Nits
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair. Please wait for direction from your
> document shepherd or AD before posting a new version of the draft.
> 
> For more information, please see the FAQ at
> 
>  >.
> 
> Document: draft-ietf-tls-dnssec-chain-extension-06
> Reviewer: Matthew A. Miller
> Review Date: 2018-02-06
> IETF LC End Date: 2018-02-07
> IESG Telechat date: 2018-02-08
> 
> Summary:
> 
> This document is ready, with one issue that I think could benefit
> from some clarification.
> 
> Major issues:
> 
> NONE
> 
> Minor issue:
> 
> This is more a question, that might warrant some clarification:
> In 7. Verification, the last paragraph discusses client-side
> caching of the RRsets. If a client has cached the full RRset chain
> from TLSA to root RRSIG (and that cache is still viable), is the
> client still expected to specify the "dnssec_chain" extension?
> 
> In my reading, that does not seem necessary, and I think it might
> be worth noting if that is true.
> 
> Yes, if the client has cached either the validated TLSA RRset or the 
> full chain, then it doesn't need to send the dnssec_chain for subsequent
> connections.
> 
> If it has only cached other portions of the chain, then it needs to. 
> 
> We can clarify this.
> 
> Shumon Huque
> 
> ___
> Gen-art mailing list
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

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

Re: [TLS] [Gen-art] Genart telechat review of draft-ietf-tls-ecdhe-psk-aead-04

[Alissa Cooper]

Dan, thank you for your reviews of this document and thanks to the authors for 
providing clarifications. I have balloted No Objection.

Alissa

> On May 19, 2017, at 6:43 PM, Dan Romascanu  wrote:
> 
> Reviewer: Dan Romascanu
> Review result: Ready
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair. Please wait for direction from your
> document shepherd or AD before posting a new version of the draft.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-tls-ecdhe-psk-aead-??
> Reviewer: Dan Romascanu
> Review Date: 2017-05-19
> IETF LC End Date: 2017-05-18
> IESG Telechat date: 2017-05-25
> 
> Summary:
> 
> This is a straight-forward and clear document that defines several new
> cipher suites for the Transport Layer Security (TLS) protocol version
> 1.2 and higher, based on the Ephemeral Elliptic Curve Diffie-Hellman
> with Pre-Shared Key (ECDHE_PSK) key exchange together with the
> Authenticated Encryption with Associated Data (AEAD) algorithms
> AES-GCM and AES-CCM. The document is well written and I appreciate the
> effort to clarify in the Introduction the context, what was missing,
> and why the document is necessary. One issue raised in my initial
> review for draft-03 was addressed, discussed and draft-04 includes
> useful clarification text. 
> 
> The document is Ready
> 
> Major issues:
> 
> Minor issues:
> 
> Nits/editorial comments: 
> 
> 
> ___
> Gen-art mailing list
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

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

Re: [TLS] Alissa Cooper's No Objection on draft-ietf-tls-padding-02: (with COMMENT)

[Alissa Cooper]

> On Sep 2, 2015, at 7:09 AM, Sean Turner <s...@sn3rd.com> wrote:
> 
> On Sep 02, 2015, at 02:26, Yoav Nir <ynir.i...@gmail.com> wrote:
> 
>> 
>>> On Aug 31, 2015, at 11:36 PM, Alissa Cooper <ali...@cooperw.in> wrote:
>>> 
>>> Alissa Cooper has entered the following ballot position for
>>> draft-ietf-tls-padding-02: No Objection
>>> 
>>> --
>>> COMMENT:
>>> --
>>> 
>>> Would be nice to include a reference to something that explains or at
>>> least identifies the implementation that hangs when receiving
>>> ClientHellos of a certain size.
>> 
>> RFCs are forever. I don’t see much value in a “F5 had a bug in 2011” 
>> sentence in an RFC. OTOH such perpetual bad publicity (much like the 
>> “NETSCAPE_BUG” and “MICROSOFT_BUG” constants in OpenSSL code) may in the 
>> future discourage vendors from being as forthcoming with relevant 
>> information as F5 were in this case.
>> 
>>> Otherwise one wonders why it's easier to
>>> define this extension than it is to just fix that one implementation
>>> (assuming it is only one).
>> 
>> The implementation has been fixed for years. Many of their customers had not 
>> upgraded their firmware when discussion of this extension began.
>> 
>> This is similar to how a vulnerability in home router firmware that was 
>> patched in 2004 was still present in new home routers sold in 2014 that were 
>> vulnerable to Shellshock. Unfortunately not every vendor can push upgrades 
>> to all customers the way browser vendors do.
>> 
>> Yoav
> 
> I agree with Yoav.  
> 
> By way of additional background: The extension fixes an issue that Brian 
> Smith brought to the WG’s attention [0].  It’s related to ALPN deployment; he 
> was running into failures when handshakes were larger than 255 bytes.  Brian 
> got some numbers from Kurt Roeckx, who relayed them from Ivan Ristic, and 
> these numbers showed that around 2.9% of the web servers surveyed on the 
> Internet had this problem.  That number kind of got the WG’s attention 
> because yeah the implementer can fix their code in a patch, but they can’t 
> really force that patch to be deployed everywhere.

Thanks, this is the kind of helpful context I was going for. I would suggest 
adding something like this at the end of the first paragraph in section 1:

"This is desirable given that fully comprehensive patching of affected 
implementations is difficult to achieve.”

Alissa

> 
> spt
> 
> [0] https://mailarchive.ietf.org/arch/msg/tls/v7tEam3Wi5GjpEXxF_71qPY0Ojo

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

[TLS] Alissa Cooper's No Objection on draft-ietf-tls-padding-02: (with COMMENT)

[Alissa Cooper]

Alissa Cooper has entered the following ballot position for
draft-ietf-tls-padding-02: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-padding/



--
COMMENT:
--

Would be nice to include a reference to something that explains or at
least identifies the implementation that hangs when receiving
ClientHellos of a certain size. Otherwise one wonders why it's easier to
define this extension than it is to just fix that one implementation
(assuming it is only one).


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