Skip to main content

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

Yes

(Stephen Farrell)

No Objection

(Barry Leiba)
(Brian Haberman)
(Deborah Brungard)
(Jari Arkko)
(Joel Jaeggli)
(Kathleen Moriarty)
(Spencer Dawkins)

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

Alvaro Retana No Objection

Comment (2015-09-01 for -02)
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.

(Stephen Farrell; former steering group member) Yes

Yes (for -02)

                            

(Alissa Cooper; former steering group member) No Objection

No Objection (2015-08-31 for -02)
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).

(Barry Leiba; former steering group member) No Objection

No Objection (for -02)

                            

(Ben Campbell; former steering group member) No Objection

No Objection (2015-09-02 for -03)
-- 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; former steering group member) No Objection

No Objection (2015-09-03 for -03)
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.

(Brian Haberman; former steering group member) No Objection

No Objection (for -02)

                            

(Deborah Brungard; former steering group member) No Objection

No Objection (for -03)

                            

(Jari Arkko; former steering group member) No Objection

No Objection (for -03)

                            

(Joel Jaeggli; former steering group member) No Objection

No Objection (for -03)

                            

(Kathleen Moriarty; former steering group member) No Objection

No Objection (for -02)

                            

(Spencer Dawkins; former steering group member) No Objection

No Objection (for -03)