[TLS] I-D Action: draft-ietf-tls-exported-authenticator-14.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : Exported Authenticators in TLS Author : Nick Sullivan Filename: draft-ietf-tls-exported-authenticator-14.txt Pages : 14 Date: 2021-01-25 Abstract: This document describes a mechanism in Transport Layer Security (TLS) for peers to provide a proof of ownership of an identity, such as an X.509 certificate. This proof can be exported by one peer, transmitted out-of-band to the other peer, and verified by the receiving peer. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-exported-authenticator-14 https://datatracker.ietf.org/doc/html/draft-ietf-tls-exported-authenticator-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-exported-authenticator-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Flags extension and announcing support
OK. I think we have as much consensus as we’re likely to get. I’ve updated the patch branch and PR to reflect this. Yoav > On 22 Jan 2021, at 7:45, Martin Thomson wrote: > > On Fri, Jan 22, 2021, at 16:16, Yoav Nir wrote: >> See this PR: https://github.com/tlswg/tls-flags/pull/5 > > It looks like there is lots of disagreement there. I'm going to disagree > with others too. > >> All except the first are Server-side. > > Certificate is client-side too. > >> The controversy is about unsolicited flags. An unsolicited flag is a >> flag that is set in a Flags extension in a server-side message without >> having been first declared in the ClientHello extension. > > So I think that you need to separate requests from responses. Because > Certificate contains response to ClientHello or CertificateRequest, my view > is that CertificateRequest can contain any flag (provided that the definition > of that flag permits it or you don't know whether it does) and Certificate > can only contain flags that CertificateRequest did. > > This is part of what Ekr seems to have objected to, and I agree with him > there. A server should be able to use any flag in NewSessionTicket or > CertificateRequest because those are the messages that initiate an exchange > (NST doesn't generate any response, so it's an exchange with one flight, but > that's immaterial). > > To review: > ClientHello is answered by HelloRetryRequest, ServerHello, > EncryptedExtensions, and (server) Certificate. > CertificateRequest is answered by (client) Certificate. > NewSessionTicket is not answered (which is totally fine). > > Those three first messages above can include new flags. They can contain the > extension or not at the discretion of the entity that sends the message. > Those messages that are in response can only contain the extension if the > initiating message contained the extension. Furthermore, the extension can > only contain a specific flag if the initiating message contained that flag. > > In other words, each flag is treated just like an empty extension: you can > initiate an exchange with it, but you can only answer with it if it was > initiated with it. > > This differs a little from Chris who suggests that only NewSessionTicket can > include a flag that was previously not indicated. > > ___ > 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] Protocol Action: 'Deprecating TLSv1.0 and TLSv1.1' to Best Current Practice (draft-ietf-tls-oldversions-deprecate-12.txt)
The IESG has approved the following document: - 'Deprecating TLSv1.0 and TLSv1.1' (draft-ietf-tls-oldversions-deprecate-12.txt) as Best Current Practice This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Benjamin Kaduk and Roman Danyliw. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/ Technical Summary This document formally deprecates Transport Layer Security (TLS) versions 1.0 [RFC2246], TLS 1.1 [RFC4346], and DTLS 1.0 [RFC4347]. It moves these documents to the historic state. The draft is intended for BCP because it updates 7525 and hence should be part of BCP195. Working Group Summary When this draft was first presented at IETF 102, there was discussion about waiting to request publication until the TLSv1.0 and TLSv1.1 use rates to drop to an “acceptable” level. There were others that felt that there was no need to wait and that the IETF should do what it thinks is right with its protocols. The WG, obviously, settled on progressing this draft. Note this draft was further discussed at IETF 103 and 104 to resolve comments received. There was also some discomfort from enterprise users who were concerned about the time and expense needed to transition to newer versions. It should be noted that library support typically continues for years beyond the publication date of the RFC, e.g., OpenSSL released in Fall 2018 will support TLSv1.0 and TLSv1.1 for roughly another 4 years. The WGLC [0] did produce some fireworks. One participant very strongly believes that “Disabling TLSv1.0 will only result in lots of interop failures and pain, but no improvement in security”. The assertion was that the use of (RSA,MD) and (RSA,SHA-1) is allowed in TLS 1.2. This comment resulted in draft-lvelvindron-tls-md5-sha1-deprecate, which deprecates the use of MD5 and SHA1 in TLS1.2. The chairs determined that this draft could proceed without the MD5/SHA1 deprecation text as it is contained in another draft [1]. IETF LC also added two RFCs to the updates list and more importantly a section was added to address operational considerations. [0] Link to WGLC thread: https://mailarchive.ietf.org/arch/msg/tls/cupb-OgiSK1ulpRANAbihPHc7zI [1] Link to chair msg: https://mailarchive.ietf.org/arch/msg/tls/xyMXqKQUZeztD5WupvI0uBp4OLA Document Quality The document got a great deal of review from many people. The list of documents updated was produced mechanically with a script and is believed to be accurate and complete. Implementations have started picking up the guidance to greater and lesser extent, but the only interoperability considerations are expected to be those listed in the operational considerations section of the document, since the change is just to remove support (whether entirely or by default) for the older protocol versions. Personnel The document shepherd is Sean Turner. The Area Director is Benjamin Kaduk. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] I-D Action: draft-ietf-tls-subcerts-10.txt
I have reviewed the recent update, and I notice one inconsistency. Section 2 says: In the absence of an application profile standard specifying otherwise, the maximum validity period is set to 7 days. Section 4.1.3 says: 1. Validate that DelegatedCredential.cred.valid_time is no more than 7 days. I think that Section 2 is trying to say that an application profile can make it even shorter than 7 days, but on my first reading I got the opposite. Russ > On Jan 24, 2021, at 6:03 PM, internet-dra...@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Transport Layer Security WG of the IETF. > >Title : Delegated Credentials for TLS >Authors : Richard Barnes > Subodh Iyengar > Nick Sullivan > Eric Rescorla > Filename: draft-ietf-tls-subcerts-10.txt > Pages : 19 > Date: 2021-01-24 > > Abstract: > The organizational separation between the operator of a TLS endpoint > and the certification authority can create limitations. For example, > the lifetime of certificates, how they may be used, and the > algorithms they support are ultimately determined by the > certification authority. This document describes a mechanism by > which operators may delegate their own credentials for use in TLS, > without breaking compatibility with peers that do not support this > specification. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tls-subcerts-10 > https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-10 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-subcerts-10 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > ___ > 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
