On Monday, 5 September 2016 15:55:49 CEST David Benjamin wrote: > On Mon, Sep 5, 2016 at 10:59 AM Hubert Kario <hka...@redhat.com> wrote: > > 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
