Skip to main content

A Transport Layer Security (TLS) ClientHello Padding Extension
draft-ietf-tls-padding-04

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.

Stephen Farrell Former IESG member
Yes
Yes (for -02) Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (2015-08-31 for -02) Unknown
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).
Alvaro Retana Former IESG member
No Objection
No Objection (2015-09-01 for -02) Unknown
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.
Barry Leiba Former IESG member
No Objection
No Objection (for -02) Unknown

                            
Ben Campbell Former IESG member
No Objection
No Objection (2015-09-02 for -03) Unknown
-- 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 IESG member
No Objection
No Objection (2015-09-03 for -03) Unknown
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 IESG member
No Objection
No Objection (for -02) Unknown

                            
Deborah Brungard Former IESG member
No Objection
No Objection (for -03) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -03) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (for -03) Unknown

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection (for -02) Unknown

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (for -03) Unknown