On Mon, Aug 20, 2018 at 1:48 PM, Nancy Cam-Winget (ncamwing) <
ncamwing=40cisco@dmarc.ietf.org> wrote:
> All,
>
> A couple IoT consortiums are trying to embrace the improvements made to
> TLS 1.3 and as they define their new security constructs would like to
> adopt the latest protocols, in th
ation | 1 Allen-Bradley Drive | Mayfield Heights, OH 44124
>
>
>
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Eric Rescorla
> Sent: Monday, August 20, 2018 4:58 PM
> To: Nancy Cam-Winget (ncamwing)
> Cc: tls@ietf.org
> Subject: EXTERNAL: Re: [TLS] integrity o
On Tue, Aug 21, 2018 at 11:11 AM, Viktor Dukhovni
wrote:
>
>
> > On Aug 21, 2018, at 1:29 PM, Ted Lemon wrote:
> >
> > You're going to have to change what you do anyway—rather than arguing
> with us why not bypass us entirely?
>
> TLS is not just a WWW protocol. Other transport security use-c
On Tue, Aug 21, 2018 at 11:33 AM, Viktor Dukhovni
wrote:
>
>
> > On Aug 21, 2018, at 2:18 PM, Eric Rescorla wrote:
> >
> >> As for TLS 1.3, it is indeed missing both null encryption and null
> >> authentication ciphers.
> >
> > If by "null
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D12108
Leonie,
Can you say more about your intended outcome here? You don't need to
have an RFC in order to register these code points.
Are you hoping for WG acceptance, or are you just planning to register
on the basis of
On Mon, Sep 3, 2018 at 4:18 AM, Hubert Kario wrote:
> On Sunday, 2 September 2018 15:30:45 CEST Bruckert, Leonie wrote:
> > Htmlized:
> > https://tools.ietf.org/html/draft-bruckert-brainpool-for-tls13-00
> >
> > Abstract:
> >
> >This document specifies the use of several ECC Brainpool curves
On Mon, Sep 3, 2018 at 7:28 AM, Hubert Kario wrote:
> On Monday, 3 September 2018 16:01:22 CEST Eric Rescorla wrote:
> > On Mon, Sep 3, 2018 at 4:18 AM, Hubert Kario wrote:
> > > On Sunday, 2 September 2018 15:30:45 CEST Bruckert, Leonie wrote:
> > > > Htmlized:
On Mon, Sep 3, 2018 at 8:20 AM, Hubert Kario wrote:
> On Monday, 3 September 2018 17:15:24 CEST Eric Rescorla wrote:
> > On Mon, Sep 3, 2018 at 7:28 AM, Hubert Kario wrote:
> > > On Monday, 3 September 2018 16:01:22 CEST Eric Rescorla wrote:
> > > > On Mon, Sep 3,
On Mon, Sep 3, 2018 at 12:19 PM, Hubert Kario wrote:
> On Monday, 3 September 2018 17:30:15 CEST Eric Rescorla wrote:
> > On Mon, Sep 3, 2018 at 8:20 AM, Hubert Kario wrote:
> > > On Monday, 3 September 2018 17:15:24 CEST Eric Rescorla wrote:
> > > > On Mon, Sep 3,
On Tue, Sep 4, 2018 at 5:46 AM, Hubert Kario wrote:
> On Monday, 3 September 2018 21:26:06 CEST Eric Rescorla wrote:
> > On Mon, Sep 3, 2018 at 12:19 PM, Hubert Kario wrote:
> > > On Monday, 3 September 2018 17:30:15 CEST Eric Rescorla wrote:
> > > > On Mon, Sep 3,
On Fri, Sep 14, 2018 at 8:33 AM, Viktor Dukhovni
wrote:
> I'm afraid the below is a strawman hypothetical. Please stop.
>
> DNSSEC lookups either return the truth or explicitly
> *FAIL*, they don't just return "neutral" results.
>
In theory perhaps, but as a practical matter, no browser client,
Still doesn't work for mel
On Fri, Sep 14, 2018 at 10:13 AM, Joseph Salowey wrote:
> It should be working now.
>
> On Fri, Sep 14, 2018 at 10:05 AM, Daniel Kahn Gillmor <
> d...@fifthhorseman.net> wrote:
>
>> On Wed 2018-09-12 07:58:43 -0700, Christopher Wood wrote:
>> > https://ietf.webex.com/i
On Sun, Oct 14, 2018 at 1:38 AM Hanno Böck wrote:
> Hi,
>
> Thanks for that interesting explanation.
>
> I just learned about another TLS 1.3 "intolerance" issue that people
> deploying it should be aware of: It seems some servers don't consider
> TLS 1.3 cipher suites as "safe" for HTTP/2 and th
Hi Simon,
I don't think we specified a concrete recommendation, but I think the
answer is probably no. The reason is that:
(a) a resumed handshake is very cheap, so it's not really saving CPU
(b) the server's first flight is small in resumption, so amplification
isn't much of an issue.
Maybe I'm
I'm responding to Ben here, because I think it's worth adding some clarity.
However, I want to flag that I'm going to be rather short on time for the
next
few week and not able to spend a lot of time replying to traffic on this
topic. Even more than usual, non-response to some point does not
necess
On Wed, Oct 17, 2018 at 7:40 AM Benjamin Kaduk wrote:
> On Wed, Oct 17, 2018 at 06:18:27AM -0700, Eric Rescorla wrote:
> > I'm responding to Ben here, because I think it's worth adding some
> clarity.
> > However, I want to flag that I'm going to be rather short
On Wed, Oct 17, 2018 at 10:03 AM Martin Rex wrote:
> Sean Turner wrote:
> >
> > This is the working group last call for the
> > "Issues and Requirements for SNI Encryption in TLS"
> > draft available at
> > http://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/.
> > Please review the doc
On Wed, Oct 17, 2018 at 4:41 PM Martin Rex wrote:
> Eric Rescorla wrote:
> > Martin Rex wrote:
> >
> > > Sean Turner wrote:
> > > >
> > > > This is the working group last call for the
> > > > "Issues and Requirements f
I have submitted draft-ietf-tls-dtls-connection-id-02, which includes the
changes to content type we discussed in Montreal.
Chairs, I think this is the last open issue and we are ready for WGLC.
-Ekr
___
TLS mailing list
TLS@ietf.org
https://www.ietf.or
Hi Ryan,
Thanks for your comments.
On Thu, Nov 8, 2018 at 12:44 AM Ryan Carboni wrote:
> Hmm. TLS has gotten too complex. How does one create a new protocol? Maybe
> we should ask Google.
>
> The SSHFP DNS record exists. DNSSEC exists.
>
> This might be a radical proposal, but maybe the certifi
On Thu, Nov 8, 2018 at 6:31 PM Ryan Carboni wrote:
> On Thursday, November 8, 2018, Eric Rescorla wrote:
>
>> It's also worth noting that in practice, many sites are served on
>> multiple CDNs which do not share keying material.
>>
>>
> Encrypting common
On Fri, Nov 9, 2018 at 10:20 AM Ryan Carboni wrote:
> Okay, a modern browser connecting to a server owned by billion dollar
> corporations are able to implement the latest version of TLS, I’ll concede
> that. Regardless, I can only underline one point: any new protocol needs to
> break both compa
On Tue, Nov 20, 2018 at 1:46 PM Stephen Farrell
wrote:
>
> Hiya,
>
> I've started to try code up an openssl version of this. [1]
> (Don't be scared though, it'll likely be taken over by a
> student in the new year:-)
>
Thanks for your comments. Responses below.
>From doing that I think the ESNI
On Tue, Nov 20, 2018 at 4:36 PM Stephen Farrell
wrote:
>
> Hiya,
>
> On 20/11/2018 23:30, Eric Rescorla wrote:
> > On Tue, Nov 20, 2018 at 1:46 PM Stephen Farrell <
> stephen.farr...@cs.tcd.ie>
> > wrote:
> >
> >>
> >> Hiya,
> >&g
On Tue, Nov 20, 2018 at 6:04 PM Salz, Rich wrote:
> >Sure a list of ciphersuites isn't bad. But the current
> design has a set of keys and a set of ciphersuites and a
> set of extensions and a set of Rdata values in the RRset.
>
> Since this is defined for TLS 1.3 with all known-good
On Tue, Nov 20, 2018 at 7:40 PM Salz, Rich wrote:
>
>- No, I don't think so. The server might choose to not support one of
>the TLS 1.3 ciphers, for instance. And even if that weren't true, how would
>we add new ciphers?
>
>
>
> Standard TLS negotiation. I don’t see that we need to sp
On Tue, Nov 20, 2018 at 11:28 PM Paul Wouters wrote:
> Although, if I am correct, the epectation is that all of this data
> will be used without mandating DNSSEC validation, so all these
> security parameters could be modified by any DNS party in transit
> to try and break the protocol or privacy
On Wed, Nov 21, 2018 at 1:50 PM Martin Thomson
wrote:
> In attempting to fix a bug related to this, a question came up about
> what the semantics of an empty value is here. Some implementations
> seem to infer that empty means {*,SHA1}, which effectively assumes
> that an empty value is equivale
On Mon, Nov 26, 2018 at 1:36 PM Nick Lamb wrote:
> In section 7.1 the -02 draft says:
>
>Clearly, DNSSEC (if the client validates and hard fails) is a defense
>against this form of attack, but DoH/DPRIVE are also defenses against
>DNS attacks by attackers on the local network, which i
On Mon, Nov 26, 2018 at 2:08 PM Stephen Farrell
wrote:
>
>
> On 25/11/2018 17:18, Nick Lamb wrote:
> > In section 7.1 the -02 draft says:
> >
> >Clearly, DNSSEC (if the client validates and hard fails) is a defense
> >against this form of attack, but DoH/DPRIVE are also defenses against
>
Currently, the record has a checksum at the front which would allow
rejection of malformed records.
However, I think it is likely we will stop using TXT.
-Ekr
On Mon, Dec 3, 2018 at 12:24 PM Viktor Dukhovni
wrote:
> On Mon, Oct 22, 2018 at 10:19:54AM -0700, internet-dra...@ietf.org wrote:
>
>
On Thu, Dec 6, 2018 at 12:19 AM Kraus Achim (INST/ECS4) <
achim.kr...@bosch-si.com> wrote:
> Hi List,
>
>
>
> I put some comments and question on the github page,
>
>
>
> https://github.com/tlswg/dtls-conn-id/issues/15
>
This is IANA considerations. I will fix.
> https://github.com/tlswg/dtls-
The Security ADs sent the following liaison statement to ETSI on this topic:
https://datatracker.ietf.org/liaison/1616/
On Sat, Dec 1, 2018 at 1:11 AM Dmitry Belyavsky wrote:
> Dear All,
>
> JFYI. Via Feisti Duck nerwsletter.
>
>
> https://www..etsi.org/news-events/news/1358-2018-11-press-etsi-r
On Thu, Dec 13, 2018 at 5:10 AM Stephen Farrell
wrote:
>
> Hiya,
>
> Was just adding code for this and I noticed that the draft says
> a server: "SHOULD pad the Certificate message, via padding at
> the record layer, such that its length equals the size of the
> largest possible Certificate (mess
On Thu, Dec 13, 2018 at 7:28 AM Viktor Dukhovni
wrote:
> > On Dec 13, 2018, at 8:10 AM, Stephen Farrell
> wrote:
> >
> > Was just adding code for this and I noticed that the draft says
> > a server: "SHOULD pad the Certificate message, via padding at
> > the record layer, such that its length eq
On Thu, Dec 13, 2018 at 8:03 AM Viktor Dukhovni
wrote:
> On Thu, Dec 13, 2018 at 07:51:17AM -0800, Eric Rescorla wrote:
>
> > Random padding does poorly with repeated trials. So, for instance,
> > if I get to observe a large number of requests from the same client
> > to
On Fri, Dec 14, 2018 at 6:54 PM Nico Williams wrote:
> OpenSSL extracts and uses SNI from session resumption tickets.
>
> This gave Viktor Dukhovni and Matt Caswell an idea that I'll relay here
> on their behalf.
>
> Also, while we're at it, I'd like to note that SNI is not the only thing
> requi
On Fri, Dec 14, 2018 at 9:48 PM Nico Williams wrote:
> On Fri, Dec 14, 2018 at 08:01:35PM -0800, Eric Rescorla wrote:
> > On Fri, Dec 14, 2018 at 6:54 PM Nico Williams
> wrote:
> > > OpenSSL extracts and uses SNI from session resumption tickets.
> > > This gave Vi
On Sat, Dec 15, 2018 at 12:41 PM Stephen Farrell
wrote:
> If browsers found one of the schemes attractive and the other
> not, that'd I think be a winning argument - unfortunately, but
> realistically, that'd win all arguments about trade-offs in
> terms of potential for privacy improvement.
>
I
On Sat, Dec 15, 2018 at 12:01 PM Viktor Dukhovni
wrote:
>
>
> > On Dec 15, 2018, at 8:08 AM, Stephen Farrell
> wrote:
> >
> > I don't see any point in considering the variant with the easy
> > active attack though;
>
> For the record the easy MiTM attack requires on-path TCP termination,
> only
On Sun, Dec 16, 2018 at 11:45 AM Paul Wouters wrote:
> On Fri, 14 Dec 2018, Eric Rescorla wrote:
>
> > However, in a large number of cases (e.g., an attacker on your local
> network,
> > there are non-DNSSEC ways of obtaining this property, such as using DoH.
>
> Data
On Tue, Dec 18, 2018 at 10:54 AM Kathleen Moriarty <
kathleen.moriarty.i...@gmail.com> wrote:
> Just a clarifying question inline
> On Sun, Dec 16, 2018 at 3:30 PM Eric Rescorla wrote:
>
>>
>>
>> On Sun, Dec 16, 2018 at 11:45 AM Paul Wouters wrote:
>>
I am shepherding the conflict review for this document. I propose to say:
The IESG has concluded that this work is related to IETF work done in
LAMPS, TLS, and IPSECME, but this relationship does not prevent publishing.
-Ekr
___
TLS mailing list
TLS@iet
Hi folks
Please take a look at
https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-30#section-6.5
which defines a new "ct_compliant" cached info extension. This sort of
overloads the cached info mechanism (one might say "abuses"), so needs
review by the TLS WG.
-Ekr
_
+ trans
On Sun, Dec 30, 2018 at 10:06 PM Martin Thomson wrote:
>
> On Fri, Dec 28, 2018, at 04:58, Eric Rescorla wrote:
> > Please take a look at
> > https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-30#section-6.5
>
> At a minimum, this would seem to update cach
I'd like to hear from some people who plan to implement and deploy this.
Absent that, I'm not sure we should adopt it. Code points are free, so it
doesn't need to be a TLS WG item unless the TLS WG and community are going
to do substantial work on it.
-Ekr
On Fri, Jan 25, 2019 at 10:12 AM Christ
I concur with what I take to be MT's position here:
1. The client is clearly prohibited from changing most elements of the CH
(except for listed exceptions).
2. It's reasonable to check for and fail the handshake on any spec
violation except those where checking is explicitly forbidden (e.g., Must
On Wed, Feb 13, 2019 at 4:12 AM Hubert Kario wrote:
> On Wednesday, 13 February 2019 01:31:41 CET Eric Rescorla wrote:
> > I concur with what I take to be MT's position here:
> >
> > 1. The client is clearly prohibited from changing most elements of the CH
> &g
On Wed, Feb 13, 2019 at 7:39 AM Hubert Kario wrote:
> On Wednesday, 13 February 2019 15:39:03 CET Eric Rescorla wrote:
> > On Wed, Feb 13, 2019 at 4:12 AM Hubert Kario wrote:
> > > On Wednesday, 13 February 2019 01:31:41 CET Eric Rescorla wrote:
> > > > I conc
On Wed, Feb 13, 2019 at 10:23 AM Hubert Kario wrote:
> On Wednesday, 13 February 2019 17:31:52 CET Eric Rescorla wrote:
> > On Wed, Feb 13, 2019 at 7:39 AM Hubert Kario wrote:
> > > On Wednesday, 13 February 2019 15:39:03 CET Eric Rescorla wrote:
> > > > I'n
On Wed, Feb 13, 2019 at 11:37 AM Hubert Kario wrote:
> On Wednesday, 13 February 2019 20:01:10 CET Eric Rescorla wrote:
> > On Wed, Feb 13, 2019 at 10:23 AM Hubert Kario wrote:
> > > On Wednesday, 13 February 2019 17:31:52 CET Eric Rescorla wrote:
> > > > On Wed,
e commenting on it
> until EKR started this thread.
>
> I propose to remove this cached-info mechanism from 6962-bis, if nobody
> objects. (It could of course be revisited in some future document, if
> there's interest).
>
>
> [1] https://trac.ietf.org/trac/trans/t
On Tue, Feb 26, 2019 at 12:54 PM Jack Visoky
wrote:
> TLS Colleagues,
>
> If you recall we discussed a draft for authentication only ciphersuites
> over email back in August of 2018. We've since made some updates to that
> draft. We also have gotten IANA assignments to the authentication only
>
On Wed, Feb 27, 2019 at 5:24 PM Stephen Farrell
wrote:
>
> Hiya,
>
> First, I think both are wrong:-)
>
> If there are really different ESNI private value holders,
> then each of those should provide separate ESNIKeys RR value
> instances
Yes, this is the idea
and the set of all of those shou
On Wed, Feb 27, 2019 at 5:56 PM Stephen Farrell
wrote:
>
> Hiya,
>
> On 28/02/2019 01:41, Eric Rescorla wrote:
> > I think you're misunderstanding the scenario here: we have two CDNs A and
> > B, and some switching service in front, so that when you lookup
> examp
On Thu, Feb 28, 2019 at 2:50 AM Stephen Farrell
wrote:
>
> Hiya,
>
> On 28/02/2019 02:40, Eric Rescorla wrote:
> > On Wed, Feb 27, 2019 at 5:56 PM Stephen Farrell <
> stephen.farr...@cs.tcd.ie>
> > wrote:
> >
> >>
> >> Hiya,
> >
it independent shepherding from a chair or AD to get to the
> goal of an Information RFC with Not Recommended status.
>
>
>
> Also, I apologize if I’ve misunderstood or misstated anything, I’m new to
> the IETF processes so certainly could have made a mistake.
>
>
>
> Tha
On Thu, Feb 28, 2019 at 5:51 AM Stephen Farrell
wrote:
>
> Hiya,
>
> On 28/02/2019 13:12, Eric Rescorla wrote:
> >> That's what leads me to think that we'd be better off
> >> to have multi-valued answers when a browser looks up
> >> the
On Fri, Mar 1, 2019 at 6:39 PM Nick Sullivan wrote:
>
>
> On Fri, Mar 1, 2019 at 6:27 PM Christopher Wood <
> christopherwoo...@gmail.com> wrote:
>
>> On Fri, Mar 1, 2019 at 3:19 PM Mike Bishop wrote:
>> >
>> > Stephen, there are a couple complicating factors here where I think we
>> all have va
g the CNAME from
> the host, it depends on how often two queries for two different RRTypes on
> the same hostname follow different CNAME chains. We have a ready-made way
> to test that – A and . I have an idea where we can get some data on
> that.
>
Great. I would be interested
I have taken an initial look at this draft [0]. Comments follow.
First the motivation for this technique appears rather
weak. Primarily, you argue that a PKI is complicated to implement and
this is simpler. However, there are a number of factors to consider.
First, I believe the design you have s
On Thu, Mar 21, 2019 at 9:22 PM Urmas Vanem wrote:
> Hi!
>
>
>
> I try to find authoritative explanation for some aspects in RFC 5246 (TLS
> 1.2). I hope this is right place to ask.
>
>
>
> Background: Company A has client/browser and company B has web server.
> Server has certificate and it also
ents from experts in this area.
>
> --
> *From:* Eric Rescorla [e...@rtfm.com]
> *Sent:* Thursday, 21 March, 2019 9:46:07 PM
> *To:* Wang Haiguang
> *Cc:* tls@ietf.org
> *Subject:* Re: [TLS] draft-wang-tls-raw-public-key-with-ibc-10
>
> I have
y?
>
I don't understand this question.
-Ekr
> Regards.
>
> Haiguang
>
> ------
> *From:* Eric Rescorla [e...@rtfm.com]
> *Sent:* Saturday, 23 March, 2019 1:13:03 AM
> *To:* Wang Haiguang
> *Cc:* tls@ietf.org
> *Subject:* Re: [TLS] dr
with
parameters, is then used as input to some function which produces a public
key. This is especially obvious when you include stuff like validity
windows.
Fundamentally, IBC is an alternate type of PKI much more than it's like a
raw public key.
-Ekr
> Thanks very much.
>
> Haiguan
Of course, at some point it starts to make sense to do RLE.
-Ekr
On Wed, Mar 27, 2019 at 6:43 AM Martin Thomson wrote:
> Why not go all in - make this a byte string and start from 0x80 in the
> first byte. When we define the 9th flag, we add another byte. Then you
> have up to 2040 flags (th
MT: why do you not think "confirmed"?
-Ekr
On Thu, May 2, 2019 at 6:56 PM Martin Thomson wrote:
> Two fixes required, but then I think HFDU is appropriate:
>
> 1. Misspelling of names.
>
> 2. The pre_shared_key extension requires the use of the
> psk_key_exchange_modes extension.
>
> On Fri, M
On Fri, May 3, 2019 at 10:31 AM Peter Gutmann
wrote:
> Having said that, given an RFC saying MUST NOT 1.0 and 1.1 which is what
> the
> original discussion was about, why not also add MUST NOT MD5 and SHA1 in
> TLS
> 1.2 to the text?
>
This seems like a reasonable proposal.
-Ekr
> Peter.
>
>
Unless I am confused, this has no content, so I think probably we should
reject it.
On Fri, May 17, 2019 at 2:06 PM RFC Errata System
wrote:
> The following errata report has been submitted for RFC5246,
> "The Transport Layer Security (TLS) Protocol Version 1.2".
>
>
On Wed, Jun 19, 2019 at 3:34 PM Stephen Farrell
wrote:
>
> Hiya,
>
> TL;DR: I think we ought remove the ESNIKeys.padded_length field,
> define a purely algorithmic padding scheme with no configuration
> needed and RECOMMEND that people using ESNI don't use names that
> are exceptionally long.
>
>
On Thu, Jun 20, 2019 at 1:20 AM Stephen Farrell
wrote:
>
> Hiya,
>
> On 20/06/2019 02:17, Eric Rescorla wrote:
> > I am not in favor of these changes. They reduce protocol flexibility for
> > servers
>
> I don't see being asked to configure a new thing that ha
On Sun, Jun 23, 2019 at 7:51 PM Yishuai Li wrote:
> Dear TLS working group,
>
> Here’s a duplicate of GitHub issue tlswg/tls13-rfc#21 I opened today,
> which somehow disappeared:
>
I closed it. The RFC has been published, so filing issues on that repo
isn't useful.
Supported Versions are defin
Nancy,
Not sure what you're asking for here. This doesn't appear to be a WG
document, so that question would be prior to asking for publication in the
WG. Or are you planning to ask the AD to sponsor it and this is just an FYI
to the WG?
-Ekr
On Sun, Jul 21, 2019 at 6:51 AM Nancy Cam-Winget (nc
Document: draft-camwinget-tls-use-cases-05.txt
I have some technical comments on the current draft.
S 2.2.1.
Note that even _if_ the SNI is provided by the client, there is no
guarantee that the actual server responding is the one indicated in
the SNI from the client. SNI alone, withou
I am in favor of adopting this.
On Wed, Jul 24, 2019 at 5:47 AM Christopher Wood
wrote:
> At TLS@IETF105, there was interest in the room to adopt
> draft-nir-tls-tlsflags as a WG item. The draft can be found here:
>
>https://datatracker.ietf.org/doc/draft-nir-tls-tlsflags/
>
> This email sta
I am in favor of adopting this document.
On Wed, Jul 24, 2019 at 5:49 AM Christopher Wood
wrote:
> At TLS@IETF105, there was interest in the room to adopt
> draft-lvelvindron-tls-md5-sha1-deprecate as a WG item. The draft can be
> found here:
>
>
> https://datatracker.ietf.org/doc/draft-lvelvind
On Thu, Jul 25, 2019 at 9:04 AM Thomas Fossati
wrote:
> Thanks for presenting this work. I really like this and I think
>
> it'd be really useful for the use cases we have (IoT, M2M).
>
>
>
> One comment: from a quick skimming of the draft, I'm not sure I
>
> understand what the stated expectati
I do not think this needs to be a PS specification. The code points here do
not require a standards track RFC.
Note that advancing this at PS would require a new IETF LC.
-Ekr
On Sun, Aug 18, 2019 at 1:07 AM Benjamin Kaduk wrote:
> On Fri, Aug 16, 2019 at 09:35:09AM +0200, Mirja Kuehlewind w
The intent of the "Specification Required" requirement for registration is
that sufficient public information be available to allow an interoperable
implementation. Specifically, the text says:
https://tools.ietf.org/html/rfc8126#section-4.6
For the Specification Required policy, review and ap
On Mon, Aug 19, 2019 at 7:32 AM Paul Yang wrote:
>
>
> On Aug 18, 2019, at 9:47 PM, Eric Rescorla wrote:
>
> The intent of the "Specification Required" requirement for registration is
> that sufficient public information be available to allow an interoperable
> im
On Sun, Sep 1, 2019 at 4:59 PM Benjamin Kaduk wrote:
> On Sat, Aug 31, 2019 at 12:25:02AM +0100, Stephen Farrell wrote:
> >
> > Hiya,
> >
> > On 30/08/2019 23:24, Benjamin Kaduk wrote:
> > > Hi all,
> > >
> > > New values for core types like TLS HandshakeType and ContentType don't
> > > happen ve
Perhaps we could rewrite this text so that it reflects that we think this
is non-ideal.?
On Fri, Sep 27, 2019 at 9:16 AM Salz, Rich wrote:
>
>
> On 9/26/19, 11:51 PM, "Martin Thomson" wrote:
>
> On Fri, Sep 27, 2019, at 10:52, Stephen Farrell wrote:
> > >> """The expectation is that
On Tue, Oct 1, 2019 at 5:27 AM John Mattsson wrote:
> Dan Brown wrote:
>
> > ANSI X9.62-2005 was withdrawn in 2015
>
> Ok, that TLS 1.3 is relying on a withdrawn publication that used to be
> behind a paywall is even worse.
>
Ugh.
> > Also, I expect FIPS 186-5 is nearly ready, and will speci
On Tue, Oct 1, 2019 at 1:04 AM John Mattsson wrote:
> Hi,
>
> I think draft-ietf-tls-oldversions-deprecate needs to update
> draft-ietf-rtcweb-security-arch as well.
>
> draft-ietf-rtcweb-security-arch-20 uses DTLS and even talks about support
> of DTLS 1.0.
>
> "Earlier drafts of this specific
Hi folks,
As discussed in Montreal, I've prepared a PR to give us DTLS/TLS key
separation.
See:
https://github.com/tlswg/dtls13-spec/pull/99
Sadly. we didn't have enough space for "dtls13 " so I went for "dtls13"
-Ekr
___
TLS mailing list
TLS@ietf.org
On Fri, Oct 4, 2019 at 7:43 AM Rob Sayre wrote:
> On Fri, Oct 4, 2019 at 9:08 PM Cullen Jennings wrote:
>
>>
>> I do not think you have consensus for that change to WebRTC - it was
>> discussed extensively. ...
>>
>
> While that may be true, readers of this list might want to read a
> rationale
On Fri, Oct 4, 2019 at 7:58 AM Rob Sayre wrote:
>
>
> On Fri, Oct 4, 2019 at 9:48 PM Eric Rescorla wrote:
>
>>
>>
>> On Fri, Oct 4, 2019 at 7:43 AM Rob Sayre wrote:
>>
>>> On Fri, Oct 4, 2019 at 9:08 PM Cullen Jennings wrote:
>>>
>>
On Sun, Oct 6, 2019 at 9:42 AM Benjamin Kaduk wrote:
> On Fri, Oct 04, 2019 at 09:57:53PM +0700, Rob Sayre wrote:
> > On Fri, Oct 4, 2019 at 9:48 PM Eric Rescorla wrote:
> >
> > >
> > >
> > > On Fri, Oct 4, 2019 at 7:43 AM Rob Sayre wrote:
> >
On Mon, Oct 7, 2019 at 10:29 AM Rob Sayre wrote:
> On Mon, Oct 7, 2019 at 1:25 AM Eric Rescorla wrote:
>
>>
>>>>> It seems strange to put DTLS 1.0 (based on TLS 1.1) into new documents.
>>>>>
>>>>
>>>> A few points.
>>&g
On Wed, Oct 9, 2019 at 5:20 AM Eric Rescorla wrote:
>
>
> On Mon, Oct 7, 2019 at 10:29 AM Rob Sayre wrote:
>
>> On Mon, Oct 7, 2019 at 1:25 AM Eric Rescorla wrote:
>>
>>>
>>>>>> It seems strange to put DTLS 1.0 (based on TLS 1.1) into ne
On Wed, Oct 9, 2019 at 5:47 AM Rob Sayre wrote:
>
>
> On Wed, Oct 9, 2019 at 7:31 PM Salz, Rich wrote:
>
>>
>>- A link from CDN to Origin is just a particularly easy-to-deploy use
>>case, since client certificates are already in wide use and IPv6 tends to
>>work flawlessly.
>>
>>
>>
On Wed, Oct 9, 2019 at 5:28 AM Rob Sayre wrote:
> On Wed, Oct 9, 2019 at 7:20 PM Eric Rescorla wrote:
>
>>
>>> 1) it doesn't seem like a particularly valid claim to say that the
>>> document "doesn't pull" in DTLS 1.0 when the rationale for tha
On Wed, Oct 9, 2019 at 6:04 AM Rob Sayre wrote:
> On Wed, Oct 9, 2019 at 7:59 PM Salz, Rich wrote:
>
>>
>>- But, if I have Cloudflare (or any CDN) configured for a domain, and
>>the origin is only available via IPv6, the need for a disambiguating SNI
>> in
>>the ClientHello from CDN
On Wed, Oct 9, 2019 at 8:00 PM Rob Sayre wrote:
> On Wed, Oct 9, 2019 at 8:04 PM Eric Rescorla wrote:
>
>> So, 6347 was totally reasonable at the time and I expect the guidance in
>> this document to override 6347 which all seems quite normal.
>>
>
> Right, tha
a context for those
> cases we use "c ap traffic". Those will always spill over into the next
> iteration as Context is 32 bytes. So for those cases, we have a whole 32
> bytes extra to play with. The only cases with an empty Context are
> "derived" and "res
Well, DTLS is one of the primary consumers of exporters
https://tools.ietf.org/rfcmarkup?doc=5764, so as a practical matter I think
we've accepted that. I'm not aware of a practical problem with exporters
and DTLS, but if there is one, we should document it and address it.
-Ekr
On Thu, Oct 10, 2
On Wed, Oct 9, 2019 at 10:16 PM Rob Sayre wrote:
> On Wed, Oct 9, 2019 at 8:06 PM Eric Rescorla wrote:
>
>>
>>> I don't think that's quite what I'm proposing. I'm proposing
>>> (optionally) sending the SNI with a client certificate.
>>
On Thu, Oct 10, 2019 at 11:19 AM Rob Sayre wrote:
>
>
> On Fri, Oct 11, 2019 at 1:08 AM Eric Rescorla wrote:
>
>>
>>
>> On Wed, Oct 9, 2019 at 10:16 PM Rob Sayre wrote:
>>
>>> On Wed, Oct 9, 2019 at 8:06 PM Eric Rescorla wrote:
>>>
>>
On Thu, Oct 10, 2019 at 11:59 AM Rob Sayre wrote:
> On Fri, Oct 11, 2019 at 1:45 AM Eric Rescorla wrote:
>
>>
>> OK, I think we've now reached where we are talking past each other.
>>
>> At a very high level, here's the TLS 1.3 handshake:
>>
>&g
On Thu, Oct 10, 2019 at 8:12 PM Rob Sayre wrote:
> On Fri, Oct 11, 2019 at 5:37 AM Martin Thomson wrote:
>
>> On Fri, Oct 11, 2019, at 07:57, Ben Schwartz wrote:
>> > The obvious solution is for the TLS client (i.e. the CDN) to support
>> > direct entry of ESNI public keys alongside the IP addre
701 - 800 of 1635 matches
Mail list logo
