Re: [TLS] draft-davidben-tls-grease-01

[David Benjamin <[e-mail]>]

On Mon, Sep 5, 2016 at 10:59 AM Hubert Kario <[e-mail]> wrote:

> On Monday, 5 September 2016 14:48:55 CEST David Benjamin wrote:
> > On Mon, Sep 5, 2016 at 7:07 AM Hubert Kario <[e-mail]> 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