Re: [TLS] Extensibility in SCVP draft
Hi,
Doesn’t it depend on whether it would be easier to do this select* or deal
with multiple validations in the same message? No one’s said that exactly
afaik, but I haven’t watched the meeting yet.
thanks,
Rob
* in the recent past, the stuff I’ve worked on has made this easy, but I
agree they’re a bit annoying.
On Mon, Jul 25, 2022 at 13:25 Russ Housley wrote:
> I was thinking the same thing during the presentation. An extension for
> SCVP seems fine to me. Then in the future, if another validation comes
> along some day, a new extension can be assigned for that protocol.
>
> Russ
>
> > On Jul 25, 2022, at 4:13 PM, Martin Thomson wrote:
> >
> > Take this:
> >
> > struct {
> > PathValidationType path_validation_type;
> > select (path_validation_type) {
> > case scvp: SCVPValidationRequest;
> > } request;
> > } PathValidationRequest;
> > enum { scvp(1), (255) } PathValidationType;
> >
> > This adds a layer of extensibility that doesn't do a lot. Please
> consider making this less generic. If we want a different validation
> design, then another extension can be defined. We have a poor track record
> of being able to use these nested extension points and it will be more
> efficient to just put the SCVP pieces in their own extension.
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
[TLS] Draft minutes
Draft minutes at https://notes.ietf.org/notes-ietf-114-tls?edit And attached. # TLS at IETF 114 ## Administrivia (5 minutes) - Blue sheets; log into the "local" meetecho tool - Minute-taker: Rich Salz with help from Nick Doty - Jabber Scribe - NOTE WELL - Agenda revision; "TLS flags" document moved to end - Doc updates; see chair slides ## Working Group Drafts (85 minutes) ### cTLS (Ben Schwartz) - Recently joined as co-author - Major changes: - Profile ID's are registratable bytestrings if under four bytes (IANA); if more than four bytes, only significant within a significant deployment - No longer a "compression" layer; was layer betwween TLS and its transport. Consensus is that this was not very simpler, prefer to have cTLS authenticated its own transcripts (without TLS). That's ambiguous so you prepend template identifier as a synthetic message. Template was JSON, is now a binary format roundtrippable to/from JSON. - New handshaking framing option since most handshake are expecte to be small; `handshake_framing=false` - Open/interesting questions: compressed EC points, compressed certs, versioning, etc. - Expect some analysis, but also expect that this will map exactly to the TLS 1.3 guarantees. ### A well-known URI for publishing ECHConfigList values (Stephen Farrell) - New co-authors (Rich Salz, Ben Schwartz) to cover some use-cases - Sample code (this is a work in progress) available; see slides. - Breeze through technical details - Should we make this more generic (everything a web server would want, like ALPN etc). Prefer to be ECH-specific. - Add ALPN? Yes probably. - Think about what other, if any, inner CH content to add. - think about what parts of SVCB to support. - Other open questions/issue that were raised. - EKR: conflicting lifetimes? Ben/Stephen: not the intent to replace generic HTTPS RR, only origin/DNS-server information to add RR data. - Ted Hardie: If there are other use-cases, think about caching infrastructure. Maybe register a provisional, write an experimental RFC, see if it's worth doing. - Ben Kaduk: if you want to limit to origin/dns, then don't register a url. Stephen: it's a reasonable argument. ### IANA Registry Updates for TLS and DTLS (Sean) - SAAG suggested adding "D" for deprecated/disrecommended. - Tough because new registrations have happened since TLS 1.3 RFC. - Short-sighted to not include Recommended column in HashAlgorithm, SignatureAlgorithm, ClientCertificateType - Table of changes; see slides. - Martin: if there's no RFC that says "this is bad" then it should be "N" - Discussion of some of the N or D ratings - Revision planned, seeking reviews, hopefully then WGLC ### Deprecating Obsolete Key Exchange Methods in TLS (Nimrov Aviram) - TL;DR: Remove RSA keyx, static FFDH, FFDHE only when >2048 and a safe well-known group, no static FFDHE - Open issues: what are safe FFDHE groups? What shoud client do if it can't/won't verify group structure? - Ben Kaduk: create a registry for "safe" named groups? Would that work? - DKG: we should address why the pen-testing tools are wrong to complain in some cases. - Nimrod: Will summarize the points made and bring it to the list. ## Individual Drafts and Presentations (30 minutes) ### TLS Extension: Validation Request (Rob Segers and Ashley Kopman) - Global aviation uses SCVP (RFC 5055). - Interop is key, states are sovereign, need standards. Moving to IP (as opposed to OSI). - 5.5K entitites, 25K aircraft; trust anchor distribution issues. - Block diagram; see slides for details. - Extension to ClientHello message, TLS server does SCVP query, extension to CertMessage that includes the scvp response. - Uri Blumenthal: appropriate for constrained devices; Hannes: yup, works fine. - Response to question from EKR: plan is to get Boeing, Airbus, etc., national aviation authorities; seem to have good representation. Server-side needs changes, but that global count of them is manageable. ### Using Attestation in TLS and DTLS (Hannes Tschofenig) - See also HotRFC presentation - Doing prototyping/experiments. - Works with RATS models; supports client- and server-side, usable with different attestation formats, TEE agnostic - Need a nonce, so just using the "obvious" certificate_type is harder. - Intent is to use for both client- and server-side attestations. - Monty Wiseman: Need to be able to specify what kinds of things you want to attest. This is a lot of work, happy to be involved. - Nick Doty: why is this a TLS protocol, not an application protocol? Hannes: good question. Want some guidance. Nick: serious privacy risks that should be addressed earlier rather than later. - Henk Birkholz: meaning of evidence is unclear. Yes I know this is a 00 draft. Don't use attestation term. Hannes: yes, I will use the "Henk brush" for next version. ### NIST PQC Announcement (Sofà Celi and Thom Wiggers) - See also CFRG notes. - Parked draft ietf-tls-hybrid-design is the way to go - Certificate-based authentication -
[TLS] client attestation type in draft-fossati-tls-attestation
Hi all, First of all, I think this document is very interesting and useful in scenarios like communication between TEE and client. In my point of view, I think the protocol could support other customized attestation formats for a wide range of use. For example, maybe a integrity measurement result or HASH value, etc. BR. Penglin ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Extensibility in SCVP draft
I was thinking the same thing during the presentation. An extension for SCVP
seems fine to me. Then in the future, if another validation comes along some
day, a new extension can be assigned for that protocol.
Russ
> On Jul 25, 2022, at 4:13 PM, Martin Thomson wrote:
>
> Take this:
>
> struct {
> PathValidationType path_validation_type;
> select (path_validation_type) {
> case scvp: SCVPValidationRequest;
> } request;
> } PathValidationRequest;
> enum { scvp(1), (255) } PathValidationType;
>
> This adds a layer of extensibility that doesn't do a lot. Please consider
> making this less generic. If we want a different validation design, then
> another extension can be defined. We have a poor track record of being able
> to use these nested extension points and it will be more efficient to just
> put the SCVP pieces in their own extension.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Extensibility in SCVP draft
> We have a poor track record of being able to use these nested extension > points and it will be more efficient to just put the SCVP pieces in their own > extension. Yes! For example, the "SNI hostname" is such a nested construct, nobody uses anything other than "a hostname string." Wrapping in substructs requires pre-compute, buffering, etc. Just say what you mean :) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Extensibility in SCVP draft
Take this:
struct {
PathValidationType path_validation_type;
select (path_validation_type) {
case scvp: SCVPValidationRequest;
} request;
} PathValidationRequest;
enum { scvp(1), (255) } PathValidationType;
This adds a layer of extensibility that doesn't do a lot. Please consider
making this less generic. If we want a different validation design, then
another extension can be defined. We have a poor track record of being able to
use these nested extension points and it will be more efficient to just put the
SCVP pieces in their own extension.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
[TLS] RFC 9258 on Importing External Pre-Shared Keys (PSKs) for TLS 1.3
A new Request for Comments is now available in online RFC libraries. RFC 9258 Title: Importing External Pre-Shared Keys (PSKs) for TLS 1.3 Author: D. Benjamin, C. A. Wood Status: Standards Track Stream: IETF Date: July 2022 Mailbox:david...@google.com, c...@heapingbits.net Pages: 11 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-tls-external-psk-importer-08.txt URL:https://www.rfc-editor.org/info/rfc9258 DOI:10.17487/RFC9258 This document describes an interface for importing external Pre-Shared Keys (PSKs) into TLS 1.3. This document is a product of the Transport Layer Security Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] RFC 9257 on Guidance for External Pre-Shared Key (PSK) Usage in TLS
A new Request for Comments is now available in online RFC libraries. RFC 9257 Title: Guidance for External Pre-Shared Key (PSK) Usage in TLS Author: R. Housley, J. Hoyland, M. Sethi, C. A. Wood Status: Informational Stream: IETF Date: July 2022 Mailbox:hous...@vigilsec.com, jonathan.hoyl...@gmail.com, mo...@iki.fi, c...@heapingbits.net Pages: 13 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-tls-external-psk-guidance-06.txt URL:https://www.rfc-editor.org/info/rfc9257 DOI:10.17487/RFC9257 This document provides usage guidance for external Pre-Shared Keys (PSKs) in Transport Layer Security (TLS) 1.3 as defined in RFC 8446. It lists TLS security properties provided by PSKs under certain assumptions, then it demonstrates how violations of these assumptions lead to attacks. Advice for applications to help meet these assumptions is provided. This document also discusses PSK use cases and provisioning processes. Finally, it lists the privacy and security properties that are not provided by TLS 1.3 when external PSKs are used. This document is a product of the Transport Layer Security Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
