Re: [TLS] draft-davidben-tls-grease-01
On Monday, 5 September 2016 15:55:49 CEST David Benjamin wrote: > On Mon, Sep 5, 2016 at 10:59 AM Hubert Kariowrote: > > 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.) yes, it handles them specially, but that's actually by a happy coincidence: client needs to verify that the ciphersuite can be negotiated with a TLS version selected by server and you can't negotiate those two ciphers with any version (in other words, this is a result of self-consistency check on server hello, not explicit check against them) -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-davidben-tls-grease-01
On Mon, Sep 5, 2016 at 10:59 AM Hubert Kariowrote: > On Monday, 5 September 2016 14:48:55 CEST David Benjamin wrote: > > On Mon, Sep 5, 2016 at 7:07 AM Hubert Kario 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
Re: [TLS] draft-davidben-tls-grease-01
On Monday, 5 September 2016 14:48:55 CEST David Benjamin wrote: > On Mon, Sep 5, 2016 at 7:07 AM Hubert Kariowrote: > > 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. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-davidben-tls-grease-01
On Mon, Sep 5, 2016 at 7:07 AM Hubert Kariowrote: > 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 > text > > slightly after some off-list feedback about the risks of > non-deterministic > > failures. > > >Clients SHOULD balance diversity in GREASE advertisements with >determinism. For example, a client which randomly varies GREASE >value positions for each connection may only fail against a broken >server with some probability. This risks the failure being masked by >automatic retries. A client which positions GREASE values >deterministically over a period of time (such as a single software >release) stresses fewer cases but is more likely to detect bugs from >those cases. > > How about adding "In particular, it is RECOMMENDED that for a given > browsing > session, used GREASE values for a given server are constant."? > So, at least the naive way of doing that gives a blatant tracking vector, which is pretty bad. Hence the example of varying over software versions. We already assume those are distinguishable because everyone offers different things and we keep tweaking them. (Apart from clients which try to mimic other software's ClientHello, but those weren't going to play this game anyway.) I guess this is an obvious thing to toss into security considerations. Will add it to the next iteration. I think it's actually fine to vary the values per connection. I want it to be immediately obvious that ClientHellos are allowed to vary so do not special-case the one GREASE value we picked. This was meant to be a replacement for the old text. I'd previously envisioned going at the front or back with 50% probability which I'm not sure would work well? I dunno. One can just freely toy around with dumb ideas and see what works. :-) Spec-wise, the only thing of substance in this document is burning a bunch of values. >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. David ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls