Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design

> At a high level, I think that this would be easier if it were more clearly framed as *recommendations*

I'm brand new to the IETF, so please forgive me if I'm totally off base here, but my understanding is that Informational RFCs are explicitly not recommendations (let alone mandates)?

Per https://ietf.org/standards/process/informational-vs-experimental/:

'An "Informational" specification is published for the general information of the Internet community, and does not represent an Internet community consensus or recommendation.'

> On Feb 12, 2020, at 12:46 PM, Martin Thomson <mt@lowentropy.net> wrote:
> 
> On Thu, Feb 13, 2020, at 06:26, Douglas Stebila wrote:
>> We would like to request the working group adopt
>> draft-stebila-tls-hybrid-design, "Hybrid key exchange in TLS 1.3", as
>> a working group item.  We have updated the draft based on feedback
>> we've received over the past few months, including from our
>> presentations at IETF 104 and 105, and think the current version
>> represents the view of the WG to date.
> 
> I agree that we should adopt this.  I think that the draft is broadly in the right shape.
> 
> Skimming through I noticed a few things that I would prefer to see eventually changed, but we can do that in the working group.
> 
> At a high level, I think that this would be easier if it were more clearly framed as *recommendations*, especially when it comes to the format of key shares and the input secret.  One advantage of the macro-level design is that the format is can be specified on a case-by-case basis.  For instance, variable-length values might be length-prefixed; fixed size values don't need to be.  That might avoid having to directly specify a single format. 
> 
> S 3.1 (Negotiation) suggests that a portion of the named group space be reserved for this use.  I think that is a bad idea because it implies semantics where none are necessary.  Picking codepoints as usual should suffice; indeed, random allocation might be ideal.
> 
> The concatenation approach is definitely my preferred approach, but the inconsistency between the design for key shares and secrets is curious.  This design assumes that shares are length-delimited; secrets are not.  The latter implies that the `ss` needs to be fixed length for a given algorithm (both the PQ and classical parts), but `ct`/`pk` does not.  I can guess at why, but when you can avoid the question, then I think you should.  That is, in favour of more generic recommendations on structure.
> 
> To answer some of the open questions:
> 
> Larger public keys and/or ciphertexts - if we need these, we're in serious trouble.  To give you an idea, even at 1k, these will start being much harder to deploy.  Getting close to 64k adds all sorts of complication.  Better to defer support for big messages.  Acknowledging the limitation should suffice.
> 
> Duplication of key shares - not so much an open question as something the draft could acknowledge as a cost.  As previously discussed X25519 is small enough that duplication doesn't hurt enough to care.
> 
> Variable-length shared secrets - see above.
> 
> Resumption - I would be supportive of policy recommendations about the strength of key exchange on resumption, but as we allow straight resumption without PSKs, this cannot be standardized.
> 
> Failures - If this were low enough, I'd be happy to try again.  From our perspective, this isn't technically challenging, it's merely annoying. If this were very low probability (as I would expect), then we might just accept the loss of the occasional connection attempt.
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls