A Transport Layer Security (TLS) ClientHello Padding Extension
RFC 7685

Note: This ballot was opened for revision 02 and is now closed.

(Stephen Farrell) Yes

(Jari Arkko) No Objection

Deborah Brungard No Objection

(Ben Campbell) No Objection

Comment (2015-09-02 for -03)
No email
send info
-- Abstract:
More in the abstract would be nice. Why'd would one want to do this?

-- 1, first paragraph, last sentence:
Can you elaborate on this? The motivation seems weak without a bit more. When would you choose to use this at all? Wouldn't it make more sense to fix the bug?

-- 5, last sentence:
Do you expect anyone to implement this MAY? It seems like this either needs to be stronger, or removed as a "why bother"?

-- 6:
I'm not sure I understand the meaning of  "permanently assign the early code point for the padding extension in its ExtensionType registry". 
Does this mean that an early allocation was done for this? If so, it seems like the IANA section should still describe the code point being registered, or perhaps give a pointer to or description of the early allocation.

(Benoît Claise) No Objection

Comment (2015-09-03 for -03)
No email
send info
Like Ben:
-- 5, last sentence:
Do you expect anyone to implement this MAY? It seems like this either
needs to be stronger, or removed as a "why bother"?

In my spec, I usually write this way: 
   Servers SHOULD verify that the extension
   is either empty or contains only zero bytes and log the exceptions.

Alissa Cooper No Objection

Comment (2015-08-31 for -02)
No email
send info
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).

(Spencer Dawkins) No Objection

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

Barry Leiba No Objection

(Kathleen Moriarty) No Objection

Alvaro Retana No Objection

Comment (2015-09-01 for -02)
No email
send info
As Alissa, I was wondering why it wasn’t easier to fix the one implementation instead.  

The shepherd wrote: "Since then it has been found that this extension can server (sic) to alleviate issues with issues in several vendor's products.  There was good consensus to move forward with this document as it may find further applicability in the future.”  So it looks like the problem is not just one implementation…

If the WG now thinks that this extension may be valuable for other things besides fixing bugs, then it might be nice to reword some of the document to not focus on what seems to be one bug and just present the extension for what it is: padding.