[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    Re: [TLS] SCSV vs RI when both specified - consensus?
From:       Yoav Nir <ynir () checkpoint ! com>
Date:       2009-12-22 8:23:11
Message-ID: BDC527E4-2951-4E57-9F10-102C470054BA () checkpoint ! com
[Download RAW message or body]

On Dec 21, 2009, at 8:01 PM, Marsh Ray wrote:

> Michael D'Errico wrote:
> > I agree we need to publish ASAP, but if consensus is (1), then I need
> > to change my (running) code since it currently does (2).
> 
> 
> Is everybody OK with this wording? (it's the more lenient choice):
> 
> > Clients MUST NOT put multiple occurrences of an RI extension in the
> > same Client Hello message. A client MAY specify the SCSV in the same
> > Client Hello message as an RI extension (the SCSV will be effectively
> > ignored).
> > 
> > A server receiving a Client Hello containing multiple RI extensions
> > MUST generate a fatal "decode_error" alert and terminate the
> > connection. A server receiving a Client Hello containing the SCSV
> > and an RI extension is to interpret the RI as usual and ignore the
> > SCSV.

I like that (with or without Nasko's suggestion)

> We'll have to fix the conflict with the current:
> > This SCSV is not a true cipher suite and cannot be negotiated. It
> > merely has exactly the same semantics as an empty "renegotiation_info"
> > extension.
> 
> to something like:
> > This SCSV is not a true cipher suite and cannot be negotiated, it
> > has similar semantics as an empty "renegotiation_info" extension.

We might want to specify what a client should do if the server chooses the SCSV \
cipher suite.  Obviously, close the connection, but with what alert?


[prev in list] [next in list] [prev in thread] [next in thread]