On Mon, Sep 5, 2016 at 10:59 AM Hubert Kario <hka...@redhat.com> wrote:
> On Monday, 5 September 2016 14:48:55 CEST David Benjamin wrote: > > On Mon, Sep 5, 2016 at 7:07 AM Hubert Kario <hka...@redhat.com> wrote: > > > On Friday, 2 September 2016 18:53:45 CEST David Benjamin wrote: > > > > I've finally gotten to uploading > > > > https://tools.ietf.org/html/draft-davidben-tls-grease-01 which > hopefully > > > > resolves the procedural issues (thanks again!). I've also revised the > > > > Clients MUST reject GREASE values when negotiated by the server. > > > When processing a ServerHello containing a GREASE value in the > > > ServerHello.cipher_suite or ServerHello.extensions fields, the > client > > > MUST fail the connection. When processing an ECParameters structure > > > with a GREASE value in the ECParameter.namedcurve field, the client > > > MUST fail the connection. > > > > > > Note that this requires no special processing on the client. > Clients > > > are already required to reject unknown values selected by the > server. > > > > > > Don't the other RFCs just say that clients should reject values not > > > advertised > > > by client? Since GREASE values are advertised by clients, I don't think > > > the > > > "no special processing" applies. As such, handling how connections in > > > which > > > server selects GREASE values should be specified precisely. > > > (I haven't checked the RFCs for that so I may be mistaken, but still > is a > > > bit > > > dicey to say that programmers don't need to check error handling in > their > > > code...) > > > > Right. That's why this one says "no special processing" rather than > > "restatements or corollaries of existing [client] requirements" as in the > > server section. In the implementation I've tossed together, this never > > makes it into the list of values the client believes it has advertised. > The > > serialization code just adds some u16s without remembering them anywhere. > > As a result, all the existing logic works just fine. > > On the other hand, the implementation I work on keeps the sent Client > Hello on > hand and checks the server response against the exact values it sent. > > So for it, server selecting GREASE value would be fine, it would fail at > key > exchange processing time. > > Keeping the Client Hello in case server asks for certificate verification > is > not entirely unheard of either. > > So I think it's best to keep the specification implementation agnostic, > without any assumptions about how the code is written, and describe just > the > externally visible behaviour. But describe it fully. > The document does that, no? Or are you simply asking that I remove the "no special processing sentence. Happy to do that. (I'm assuming your implementation then handles the renegotiate_info SCSV and FALLBACK_SCSV similarly special? It's the same story with those two.) David
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
