Re: [TLS] Adoption call for draft-davidben-tls13-pkcs1

On Mon, Nov 11, 2019 at 11:33 AM Christopher Wood wrote: > The adoption call is now (belatedly) finished. At this time, there's not > enough interest to take this on as a WG item. We encourage further > discussion on the list, perhaps based on subsequent draft updates, and will > revisit

Re: [TLS] TLS Flags extension - not sure it makes sense

On Tue, Jul 23, 2019 at 3:09 PM Chris Inacio wrote: > I really want the savings on the wire that TLS flags extension provides – and > so I think it’s really good for the future cTLS but I’m not sure when I get > to use it in TLS 1.3 negotiation. It goes in the clientHello message, but > how

Re: [TLS] Question about draft-thomson-tls-sic

On Tue, Jul 23, 2019 at 5:23 PM Watson Ladd wrote: > Suppose the following sequence of events happen: > > 1: A CA uses a new intermediate for reasons (no longer cross-signing, etc.) > 2: A site gets a certificate from the new intermediate. > 3: An older firefox version connects and thinks it

[TLS] Yet more TLS 1.3 deployment updates

AGL -- Adam Langley a...@imperialviolet.org https://www.imperialviolet.org ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Further TLS 1.3 deployment updates

ents getting established in the mean time. We are painfully aware that limiting our server-side deployment allowed this bug to become established and, while we did it to ease middlebox issues, it may have been a mistake. Cheers AGL -- Adam Langley a...@imperialviolet.org https://www.imperi

Re: [TLS] Broken browser behaviour with SCADA TLS

m in the client as the CA/BF rules suffice for the vast, vast majority of users. Cheers AGL -- Adam Langley a...@imperialviolet.org https://www.imperialviolet.org ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.txt)

ues with concurrent applications and I offer 0xbb31 as a high-quality, random number. Since we had a triple collision in this case, random-assignment's virtues are currently particularly clear.) -- Adam Langley a...@imperialviolet.org https://www.imperialviolet.org

Re: [TLS] early code points assigned (was Re: early code point assignment for draft-ietf-tls-certificate-compression)

dom value until assigned? -- Adam Langley a...@imperialviolet.org https://www.imperialviolet.org ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] early code points assigned (was Re: early code point assignment for draft-ietf-tls-certificate-compression)

en offering TLS 1.3, which presumably LTS clients would not, so maybe there's something you could use there. Cheers AGL -- Adam Langley a...@imperialviolet.org https://www.imperialviolet.org ___ TLS mailing list TLS@ietf.org https://www.ietf.org/m

Re: [TLS] extended headers for (D)TLS (and their use with connection-id)

ecord header in it. With TLS, the kernel might keep retransmitting some part of the half-connection's data that doesn't include the connection id at all.) Cheers AGL -- Adam Langley a...@imperialviolet.org https://www.imperialviolet.org ___ TLS mailing list TLS@ie

Re: [TLS] extended headers for (D)TLS (and their use with connection-id)

though, and the cited motivation (https://tools.ietf.org/html/draft-ietf-tls-dtls-connection-id-00) is DTLS-only. Probably this draft needs to be too. Cheers AGL -- Adam Langley a...@imperialviolet.org https://www.imperialviolet.org ___ TLS mailing li

Re: [TLS] Additional TLS 1.3 results from Chrome

On Tue, Dec 19, 2017 at 5:07 AM, Stephen Farrell wrote: > I'm not sure I agree renumbering is the right reaction, > though I don't object to that. This could be a case where > it's overall better that those specific devices suffer > breakage, and hopefully then do get

Re: [TLS] Update on TLS 1.3 Middlebox Issues

ing that is needed, but that we need to go further. Cheers AGL -- Adam Langley a...@imperialviolet.org https://www.imperialviolet.org ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WG adoption call: draft-thomson-tls-record-limit

on of the draft > and are willing to review/comment on the draft before 20170818. If you > object to its adoption, please let us know why. > I support adoption. Cheers AGL -- Adam Langley a...@imperialviolet.org https://www.imperialviolet.org

Re: [TLS] WG adoption call: SNI Encryption

ly we have to pick one, right? I feel that drafts are generally more opinionated before a call for adoption, although the chairs might well feel that the design-space span is this document is focused enough already. Cheers AGL -- Adam Langley a...@imperialviolet.org https://www.imperialviolet.

Re: [TLS] WG adoption call: SNI Encryption

On Fri, Aug 4, 2017 at 11:03 AM, Tony Arcieri <basc...@gmail.com> wrote: > On Fri, Aug 4, 2017 at 10:39 AM, Adam Langley <a...@imperialviolet.org> > wrote: > >> If it wants to be a technical document, then the draft includes two very >> different designs with a no

Re: [TLS] WG adoption call: SNI Encryption

chosen at some point. So which are we talking about adopting? While drafts evolve during the WG process, there's a big gap between the two ideas and I'd support one but not the other. Thus I'm not sure that the draft is ready for an adoption call at this time. Cheers AGL -- Adam Langley a...@

Re: [TLS] Improved nonce generation method for TLS 1.3

, seq number in rcx: leaq maskOffset(%rax), %rbx ; xorq (%rbx), %rcx ; movbeq %rcx, 4(%rdi) Cheers AGL -- Adam Langley a...@imperialviolet.org https://www.imperialviolet.org ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS 1.3 Record Layer Format

ncountered so far, but I hope to do so in the coming weeks.) Cheers AGL -- Adam Langley a...@imperialviolet.org https://www.imperialviolet.org ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PSS and TLS 1.3

On Fri, Jan 20, 2017 at 11:29 AM, Brian Smith wrote: > RSA PSS with a zero-length salt is a deterministic, > subliminal-channel-free signature scheme. It is one of the few > signature schemes that structurally prevent an HSM from directly > leaking (parts of) the private key

Re: [TLS] [SUSPECTED URL!]Re: Requiring that (EC)DHE public values be fresh

On Mon, Jan 2, 2017 at 3:57 PM, Adam Langley <a...@imperialviolet.org> wrote: > I don't expect that those who want to intercept TLS connections will > see a MUST NOT and go do something else. Rather I think they should > understand that TLS isn't supposed to be intercepted an

Re: [TLS] [SUSPECTED URL!]Re: Requiring that (EC)DHE public values be fresh

On Mon, Jan 2, 2017 at 11:43 AM, Yoav Nir wrote: > I’m assuming that the server generates private keys and saves them to a file > along with the time period that they were used, and another machine in a > different part of the network records traffic. It’s not so much that

Re: [TLS] Requiring that (EC)DHE public values be fresh

I much prefer people who are going to backdoor their TLS to use DH as the mechanism rather than something less detectable. I don't expect a MUST NOT will slow them down at all. I just want to ensure that this doesn't accidently carry into 1.3, and that any unofficial backdoor mechanism needed by some org

Re: [TLS] cross-domain cache sharing and 0rtt (was: Re: Requiring that (EC)DHE public values be fresh)

On Thu, Dec 29, 2016 at 11:08 AM, Eric Rescorla wrote: >> >> As an individual, I'd be in favour of this change but reading >> >> over [1], section 5, I wondered if we'd analysed the effects of >> >> 0rtt/replayable-data with that kind of cross-domain re-use in mind? >> >> The

Re: [TLS] Requiring that (EC)DHE public values be fresh

On Thu, Dec 29, 2016 at 11:28 AM, Martin Rex wrote: > First of all, forward secrecy is equally defeated by TLS session caching > (traditional as well as session tickets), and the effect of rfc5077 > TLS session tickets is likely at least a magnitude worse--and cannot > be "fixed" by

[TLS] Requiring that (EC)DHE public values be fresh

-tls-static-dh-in-tls13/ Cheers AGL -- Adam Langley a...@imperialviolet.org https://www.imperialviolet.org ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WG adoption call: draft-davidben-tls-grease

On Thu, Dec 8, 2016 at 10:56 AM, Eric Rescorla <e...@rtfm.com> wrote: > +1 > I'm not sure whether I could as an independent voice on this topic, but I strongly support adoption of this draft. Cheers AGL -- Adam Langley a...@imperialviolet.org https://www.imperi

Re: [TLS] Confirming consensus: TLS1.3->TLS*

On Fri, Nov 18, 2016 at 7:49 AM, Will Serumgard wrote: > At this point it is a little late to change. I say stay with TLS1.3. As > some others pointed out maybe we can make a jump in the next version. > Renumbering SSL 3.1 as TLS 1.0 was a mistake in the first place, but

Re: [TLS] draft-ietf-tls-tls13-16

pe that a default would work for the vast majority of TLS 1.3 users. Cheers AGL -- Adam Langley a...@imperialviolet.org https://www.imperialviolet.org ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] KeyUpdate and unbounded write obligations

standing, > but these cannot be used to produce the write keys. However, this probably > isn't simpler than just running two ladders if we think this is important. That works but I agree that splitting the ladders is nicer and I think that we should do that. Cheers AGL -- Adam

Re: [TLS] KeyUpdate and unbounded write obligations

to get more fodder for Matthew Garrett ( https://mjg59.dreamwidth.org/43486.html). I would still tend towards not including the generation because I don't believe that it's going to be used. But if, in a blaze of optimism, people think it will, I'm not going to be too upset. Cheers AGL -- Adam Langley a...@imperialviolet.org https://www.imperialviolet.org ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Keeping TLS extension points working

g that led to the padding extension (RFC 7685). On the other hand, we've seen what's happened to the version field, which is moving too slowly to resist rusting. Cheers AGL -- Adam Langley a...@imperialviolet.org https://www.imperialviolet.org ___

Re: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2?

On Wed, Mar 16, 2016 at 6:14 PM, Paterson, Kenny wrote: >>provokes me to bring it up. Here's the crux of it; is it really a >>security win to recommend the AEAD cipher suites for TLS 1.2 users? I'm skeptical about the benefit of padding to 16 bytes. While it does

Re: [TLS] Accepting that other SNI name types will never work.

On Thu, Mar 3, 2016 at 10:56 AM, Eric Rescorla <e...@rtfm.com> wrote: > Note: it's already the case that it's forbidden to send >1 of any given type > of name. NSS does not presently enforce this rule but will do so soon. (We have enforced that for a while without issues.) Cheers

[TLS] Accepting that other SNI name types will never work.

/OpenSSL_1_0_1-stable/ssl/t1_lib.c#L1066 – note that the data pointer is not updated. [3] https://tools.ietf.org/html/rfc4366#section-3.1 Cheers AGL -- Adam Langley a...@imperialviolet.org https://www.imperialviolet.org ___ TLS mailing list TLS@ietf.org

Re: [TLS] Remove 0-RTT client auth

n confusion attacks[2] etc.) Cheers AGL [1] https://tools.ietf.org/html/draft-ietf-tokbind-protocol-04 [2] http://antoine.delignat-lavaud.fr/doc/www15.pdf -- Adam Langley a...@imperialviolet.org https://www.imperialviolet.org ___ TLS mailing list

Re: [TLS] Require deterministic ECDSA

probably do their thing no matter what the standard says, so I wouldn't have an objection to putting a "SHOULD" in the spec for RFC 6979. I suspect that adherence would be poor, however. As for using that RFC over what I came up with or anything else: at least RFC 6979 has been written do

Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful?

On Wed, Dec 30, 2015 at 4:03 PM, Brian Smith wrote: > I think it is a good idea to implement the session hash extension, in > general. However, I think it is a bad idea to prescribe it as the solution > for this particular problem because: > > 1. draft-irtf-cfrg-curves-11,

Re: [TLS] draft-ietf-tls-curve25519-01 and the X25519 significant bit.

, even achievable for a spec). So at this point I'd like to nail down the existing behaviour with tests, try to make it uniform across most implementations, and try to avoid other specs interpreting the byte strings. [1] http://cr.yp.to/ecdh/curve25519-20060209.pdf Cheers AGL -- Ad

Re: [TLS] draft-ietf-tls-curve25519-01 and the X25519 significant bit.

t things like this. I think TLS should handle the byte strings opaquely so that we have uniform behaviour for X25519/X448 and only a single place where it needs to be tested. The behaviour of X25519/X448 for non-reduced values is also specified in the CFRG document. Cheers AGL -- Adam Langley a.

Re: [TLS] PRF digest function for ChaCha20-Poly1305 cipher suites

r suites, I'm not sure that a slower, software implementation of SHA-256 would be a big problem. Cheers AGL -- Adam Langley a...@imperialviolet.org https://www.imperialviolet.org ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Early code point assignment request for curve25519 and curve448

gnment while the signature code points are not since the signature work in CFRG is ongoing. I'll leave that to the chairs. (While we would use early code-point assignments for X25519/X448 we don't have plans for using the signature code points at this time.) Cheers AGL -- Adam Langley a...@imperi

Re: [TLS] Review of https://tools.ietf.org/html/draft-ietf-tls-chacha20-poly1305-00

"bit" and "byte" in -01 and changed one key length to bits, but otherwise I think each use is about right. Cheers AGL -- Adam Langley a...@imperialviolet.org https://www.imperialviolet.org ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Application data during renegotiation handshake

values)? SPDY, at one point of development, supported this via the CREDENTIAL frame. That also avoided a confused deputy problem: with connection pooling over HTTP/2, there seems to be a risk of confusion about which requests are authenticated with which client certificate. Cheer

Re: [TLS] I-D Action: draft-ietf-tls-chacha20-poly1305-01.txt

next revision: "The 64-bit record sequence number is serialized as an 8-byte, big-endian value and padded on the left with four 0x00 bytes." Cheers AGL -- Adam Langley a...@imperialviolet.org https://www.imperialviolet.org ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Version in record MAC

d into AEADs, would have to authenticate their nonces internally. RFC 5297 basically says that already (https://tools.ietf.org/html/rfc5297#section-3). That might mean that the nonce is prepended to the AD inside the AEAD abstraction, but that wouldn't be TLS's concern. Cheers AGL --

Re: [TLS] Version in record MAC

t that I deeply care either way.) Cheers AGL -- Adam Langley a...@imperialviolet.org https://www.imperialviolet.org ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] '15 TLS Fall Interim Minutes

; limited by 1RTT maximum there). I think we quite possibly didn't understand the concern here. Could you spell it out at more length? Cheers AGL -- Adam Langley a...@imperialviolet.org https://www.imperialviolet.org ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] sect571r1

On Wed, Jul 15, 2015 at 1:58 PM, Deirdre Connolly durumcrustu...@gmail.com wrote: So, should it stay or should it go now? Opinions? +1 that sect571r1 be removed. I also believe that it should be removed. Cheers AGL -- Adam Langley a...@imperialviolet.org https://www.imperialviolet.org