Re: [TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-grease-03: (with COMMENT)

[Mirja Kuehlewind <[e-mail]>]

Hi Ben,

See line.

> On 15. Aug 2019, at 17:24, Benjamin Kaduk <[e-mail]> wrote:
> 
> On Thu, Aug 15, 2019 at 08:14:12AM -0700, Mirja Kühlewind via Datatracker wrote:
>> Mirja Kühlewind has entered the following ballot position for
>> draft-ietf-tls-grease-03: No Objection
>> 
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>> 
>> 
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>> 
>> 
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-tls-grease/
>> 
>> 
>> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>> One comment/question: I think I didn't quite understand what a client is
>> supposed to do if the connection fails with use of greasing values...? The
>> security considerations seems to indicate that you should not try to re-connect
>> without use of grease but rather just fail completely...? Also should you cache
>> the information that greasing failed maybe?
> 
> I'll let the authors chime in, but I think the sense of the security
> considerations is more that we are preventing the fallback from being
> needed "in production due to "real" negotiation failures.  Falling back on
> GREASE failure is not as bad, provided that you follow-up with the failing
> peer out of band to try to get it fixed.
> I don't know how much value there would be in caching the grease-intolerate
> status; ideally it would almost-never happen.

Okay, then I think it would be nice to say something more in the document, about fallback at least.

> 
>> And a note on normative language:
>> 
>> "Implementations sending multiple
>>   GREASE extensions in a single block thus must ensure the same value
>>   is not selected twice."
>> Should this be a "MUST"?
> 
> I asked for this to be changed away from a "MUST" -- RFC 8466 already has
> this prohibition on duplicated values; we're just calling it out again here
> since randomly picking values (with replacement, which is the easy way to
> code it) can result in collisions, that are forbidden by 8446.

Ah okay, that’s fine. Didn’t check 8446.
> 
>> Also this is an interesting MUST:
>> "... MUST correctly ignore unknown values..."
>> While this is the whole point of the document, I assume this is already
>> normatively specified in RFC8446 and therefore it could make sense to use
>> non-formative language here...
> 
> I think you are correct, but I personally do not mind the extra normative
> force in this case.

I just found this actually particularly weird because of the “correctly”. To me it reads like “please, please finally follow normative specification we do in RFCs”… anyway… I after all don't really mind if you pick on or the other.

Mirja

 

> 
> -Ben
> 
>