Tuesday 2020-07-28 14:10 UTC

Meeting Information

Meetecho (a/v and chat):

Audio (only):

Jabber (chat):


Agenda bash: Benajmin Kaduk: time for oldversions-deprecate? Response: Yes Draft status DTLS is next on slate in queue: ticket requests

Sean: People are anxious to get DTLS out the door, but ok with order



TLS Subcerts


Slides: Delegated Credentials

Presenter: Nick Sullivan


TLS Flags


Slides:TLS Flags

Presenter: Yoav Nir


Martin Thompson: concrete use in SH? Wouldn't want feature negotiation in clear Simpler if only in EncryptedExtensions

Eric Rescorla: NST has immediate use-case: cross-name SNI. Wouldn't need an empty registry

Benjamin Kaduk: If don't say you can put it in NST, locking out forever. Would need new flags. Hard to implement for SH, consider define to be in SH, but will need good excuse

Nick Harper: Are we locked out of putting it in SH? Specify that flag can be in SH

Ben Schwartz: not all flag bits are equally good. (Lower number higher value) Better to have different extensions--one for EncryptedExtension, another for other flags

Joseph Saloway: resolve on the list about where this can appear

TLS 1.3 Extended Key Schedule


Slides: TLS Extended Key Schedule

Presenter: Jonathan Hoyland


Eric Rescorla: sad about particular way of injecting. Important not to avoid ambiguity, but two Derive-Secrets is goofy

Jonathan: if draft-stebila is better, sure

Eric Rescorla: How modify key schedule, how glue inputs together. XOR thing seems ok but hard to reason about

Jonathan: XOR thing comes with a 40-page proof, but not intuitive

Eric: seems like an argument against it

Richard Barnes: chaining with derive-secret: why not just HKDF?

Jonathan: Proof for HKDFs relies on expand-extract pattern. If other proofs for extract-extract, whatever is secure

Richard Barnes: this seems like a conservative option

Chris Wood: In context of MLS, use concat and extract rather than XOR (lines up with Douglas)

Martin: want to understand the different between this and stebila. Reasonable support for this. Unspecified rumblings about what's in that draft. Is this supplementary?

Jonathan: I took one of the designs from that that I liked and made it generic. Supposed to supercede Stebila.


No one stated why they were against adoption

Cross-SNI Resumption


Slides: Cross-SNI Resumption

Presenter: Victor Vasiliev


Ben Schwartz: I support this; thought about case where one server is capable of responding for the whole cert, but other servers aren't? Question about whether it's safe for a server to do this. Needs to know about all servers in the world that can respond to any name in cert.

Victor: If you have the cert, you have the authority to speak for all servers that have it. Connection attempt would result in failure

Ian Swett: support this. Wouldn't anticipate that the handshake will fail.

Victor: No, it wouldn't fail

Daniel Gillmor: DNS lookups?

Victor: This doesn't bypass DNS checks; you're establishing a new connection.


TLS Application Protocol Settings (ALPS)


Slides: ALPS

Presenter: Victor Vasiliev


Martin Thompson: Don't find that arguments in favor of new adventure are justified here - Just making half-RTT work is superior. Don't want to put this in TLS 1.2. Wait for 0.5 RTT settings, it's do-able.

Eric Rescorla: When adding new message to third leg of handshake, looked into this and no one had use for it. Add generic solution rather than go through it twice.

David Ben: halfRTT data, connection properties are stable. For first connection, want to be able to send settings early. That's more complicated. Server has requested client certs, need to let them write. Weird deadlocks can happen. Server thinks data is part of handshake but client doesn't. Intentionally punted this.

Victor: NSS doesn't implement this for client certs

Martin: I have not, intentionally.

Ben Schwartz: QUIC wouldn't use this? Thought this was for QUIC

Martin: QUIC the transport protocol wouldn't use this.

Ben Schwartz: arguments for half-RTT are persuasive enough if this can be done without new handshake alert

Martin: most compelling argument is QUIC

Daniel Gillmor: I'm torn because these sound like two different things. How TLS is going to be used by implementers (security dust). Just for H2 settings? Doesn't matter for client certs?

Martin: Reasoning about what's safe to send in 0-RTT is hard

Chris Wood: Proposal (KEMTLS) for removing ability to do half-RTT data. This would be useful in that context.

Joseph Salowey: Sounds like there should be more discussion before we decide on adoption



Slides: SNIP

Presenter: Martin Thomson


Ben Schwartz: a problem worth solving. Doesn't apply today, but problem we can care about.

Martin: biggest question: mechanism that enables client to fail? Or try to write out a mechanism that enables an upgrade? Assertion that this isn't needed: if you got a QUIC connection to a number of sites, but make a different decision about using it.

Ben Schwartz: SVCB draft hazy on this point. Encourage clients to fall back within list of endpoints made available. Client could demand availability.

Martin: DNS provider can always deny access to the service

Eric Rescorla: More bake time before considering

Martin: Need more clear-cut example? E.g. IMAP2 to 3 is more motivating. Rat hole about different name style for things? Just go all in on SVCB? TLS gives a minumum strength on security.

David Schinazi: supportive of this; yes to 4 first questions. Don't need right away because fallback considered ok. But this is a simple way to solve this problem

Carrick Bartle: What's the security risk from downgrading?

Martin: Just don't want attacker to be able to downgrade your service

Carrick Bartle: What should the client do if it discovers that it's been downgraded? Should it just try again with the protocol it wanted?

Martin: Shut down the connection, don't talk to that server.

Daniel Gillmor: One security risk: less protection from metadata in TLS than QUIC what should the user do with this info? network operator might be interfering with getting the strongest security rating QUIC: designed so that if it doesn't work, we'll fall back to TLS HSTS: model for ridiculous process; worked across time. Used in network diagnostic reports? How does this fix the problem? What problem is this fixing?

Martin: Concrete example: specific servers that have QUIC blocked. Can make a decision, make this as strong as we can make it

Joseph Salowey: Needs more discussion

Benjamin Kaduk

DES: Ciphers removed from 1.2 (essentially don't exist anymore)

RFC 7507 - downgrade attack doesn't make sense if 1.0/1.1 aren't used anymore

Same deprecation document?

Sean: The old ciphers are dead as doornails

"You MUST implement TLS 1.0/1.1"; suggested another sentence saying don't do that; additional details about the updates

Sean Turner: seems reasonable

Don't have to go into detail; overall summary

OAuth docs: yes, TLS 1.2 is the current version, but 1.0 is more widespread.

Sean Turner: They just said that to get through the process

Ben: Suggested some language.

10 or so docs: mandatory to implement cipher. Not saying anything about ciphers in this doc; seems correct. If people aren't picking bad MTI ciphers, don't do anything.

Sean Turner: if changing base protocol with MTI, natural progression, don't have to specify cipher

Ben: Some of them specify MTI cipher in TLS 1.0; not super great writing.

Joseph Salowey: could be errata in other specs

Filed errata about FTPS spec, which requires TLS 1.0 even though 1.1 exists