On Mon, Nov 05, 2018 at 09:00:29AM -0500, Viktor Dukhovni wrote:
> > On Nov 5, 2018, at 8:01 AM, Benjamin Kaduk wrote:
> >
> > Once we start talking about pinning of any sort, we move from this
> > extension just being "transport some DNS records" into conveying some
> > sort of additional semant
My question would be "what will the HTTP community do if they find this
whole process unwieldy and long"?
Answer They will come up with a solution that does nothing with DANE.
is that an excuse to do something less than perfect for the better good, or
do we live in the world of smug satisfaction
On Tue, Nov 06, 2018 at 10:05:14AM -0600, Benjamin Kaduk wrote:
> Of course! But if we don't precisely specify those semantics, we expect
> to get DISCUSS positions at IESG evaluation (as "not interoperably
> implementable").
Yes, that's why the draft once updated will need to explain the
semant
We've had a couple of conference calls to discuss the I-D.
One call ended up causing the consensus on the I-D to collapse.
The second call ended too soon, but it was not unproductive. Indeed, I
think at that call and in the subsequent off-list threads we identified
the concerns with pinning:
-
On Tue, 6 Nov 2018, Benjamin Kaduk wrote:
I think I'm confused about what you mean by "the downgrade-resistance
that DNSSEC gives automatically".
You cannot filter DNSSEC without the target being aware of being
filtered (where filtering == downgrading)
Paul
__
On Wed, 7 Nov 2018, Tim Wicinski wrote:
My question would be "what will the HTTP community do if they find this whole
process unwieldy and long"? Answer They will come up with a
solution that does nothing with DANE.
They dont need to do anything to not have DANE. They already not have it.
[ Quoted text slightly reordered to put the RSA issue first, as that's
the main thing I'm trying to get clarity on, and enabling keyUsage
enforcement is causing some interoperability issues now... ]
> On Nov 5, 2018, at 11:11 PM, Geoffrey Keating wrote:
>
>> TL;DR: Should TLS client abort D
The TLS WG has placed draft-wood-tls-ticketrequests in state
Candidate for WG Adoption (entered by Sean Turner)
The document is available at
https://datatracker.ietf.org/doc/draft-wood-tls-ticketrequests/
___
TLS mailing list
TLS@ietf.org
https://www.
This is the working group last call for the "Exported Authenticators
in TLS" draft available at
https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/.
Please review the document and send your comments to the list by 2359
UTC on 30 November 2018.
Thanks,
Chris, Joe, and Sean
This is the working group last call for the "The Datagram Transport
Layer Security (DTLS) Protocol Version 1.3" draft available at
https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/. Please
review the document and send your comments to the list by 2359 UTC on
30 November 2018.
Thanks,
Chris,
This is the working group last call for the "Connection Identifiers for
DTLS 1.2" draft available at
https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/. Please
review the document and send your comments to the list by 2359 UTC on 30
November 2018.
Thanks,
Chris, Joe, and Sean
At TLS@IETF103, there was consensus in the room to adopt
draft-wood-tls-ticketrequests. This message is to confirm that consensus. If
you do not support adoption of draft-wood-tls-ticketrequests as WG item please
say so by 2359UTC on 30 November 2018 (and say why).
Thanks,
Joe and Sean
__
Thanks, Rich!
On Mon, Nov 5, 2018 at 4:16 PM Salz, Rich wrote:
>
> Draft minutes attached; please post corrections to the list.
>
>
>
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
___
13 matches
Mail list logo
